כל ארגון חייב לעשות ניתוח מערכות

יום ד', 6 בדצמבר 2017
מאת יצחק בן עוזר*
 
 
לא כל ארגון חייב להעסיק מנתח מערכות אבל כל ארגון חייב לעשות ניתוח מערכות
 
ניתוח מערכות נתפש בעיני רבים כאחד המרכיבים החשובים בתהליך הפיתוח של מערכות מידע ממוחשבות. ברצוני להבהיר שניתן להשתמש בדיסציפלינה זו או בחלקים ממנה גם כאשר התוצר הסופי אינו מערכת מידע ממוחשבת.
 
דוגמאות לכך אפשר למצוא בשיפור תהליכי עבודה בארגונים,
שינויים במבנה ארגוני והתאמתו לצרכי הארגון,אחזקת מידע במערך ידני או בחירה בין חלופות שונות
בנקודות החלטה שונות.כדי להמחיש עובדה זו אשתמש בדוגמא מנסיוני האישי באחד מהארגונים בהם עבדתי. במחצית השנייה של שנות ה-70 במאה הקודמת עבדתי כמתכנת ומנתח מערכות  בראשית דרכו באחת מחברות הביטוח המובילות בארץ.
 
הייתי בצוות שעסק בביטוח אלמנטרי ולעתים עסקתי גם בפרויקטים שעסקו בהתחשבנות מול סוכני הביטוח. באחד הימים נקראתי למשרדה של האחראית
למשאבי אנוש. באותה חברה ביטוח היה נהוג שהעובד מגלה באופן מפתיע ביום הולדתו על שולחנו מעטפה עם ברכה שהוצמדו לה שני כרטיסים להצגת תיאטרון.  האחראית על משאבי אנוש ביקשה להיעזר בשרותי המחשוב של החברה לצורך תפעול התהליך הנ"ל. הדו"ח שהיא דרשה היה פשוט למדי
רשימה שמית של עובדים שיש להם יום הולדת בחודש מסוים כאשר ניתן יהיה להפיק את הדו"ח חודשיים קודם וכך להתארגן לרכישת כרטיסי התיאטרון מבעוד מועד. 
 
אני שלא הייתי בקי במידע שניתן היה להפיק במערכת כח האדם שאלתי לתומי אם יש לה צרכי מידע נוספים והיא השיבה שהיא מסתפקת בדו"ח הזה. הבטחתי לה תשובה תוך כמה ימים וחזרתי לחדרי. בחברה עבדו באותה תקופה 114 עובדים ומאחר ומרבית העובדים עבדו תחת הסכם קיבוצי שהבטיח להם יציבות תעסוקתית שיעור הניידות של העובדים (עזיבות וקליטת חדשים) היה נמוך למדי.
 
לפתע נזכרתי שבקומת הכניסה לבנין יש חנות של המשביר לצרכן. ירדתי במעלית ממרומי קומה 13 לחנות ורכשתי מכספי שלי מחברת 12 דף. עליתי עם המחברת לחדרי ורשמתי בכל דף שם של חודש אחר (בראשון ינואר ובאחרון דצמבר) ולאחר שהמשימה הושלמה צעדתי עם המחברת לחדרה של הממונה על משאבי אנוש.
 
הסברתי לה שמאחר ויום ההולדת הוא נתון קשיח למדי (למעט טעויות בהקלדה ראשונית אין כל סיבה בעולם לשנותו במשך הזמן).  מאחר וחלוקה של מספר העובדים בחברה ל-12 תביא לתוצאה ממוצעת של 10 עובדים בכל חודש ובמחברת משני צידיו של כל דף ניתן לרשום עד 60 שמות ותאריכים הרי שהמחברת לאחר שיירשמו בה כל העובדים תהווה מאגר מידע זול,נוח ונגיש וגם היחס בין מספר העדכונים למספר השליפות יהיה סביר ביותר. מי שמודאג מנושא הגיבוי יכול להשתחרר מהדאגה מאחר והמחברת ניתנת לצילום אחת לתקופה כשהעותק המצולם נשמר במקום אחר.
 
האחראית על משאבי אנוש היתה מופתעת מהפתרון ה-"ידני" אך תוך מספר שניות התעשתה וקיבלה אותו בחיוך. 
אני מודה שמבחינה סטטיסטית במרבית המקרים שבהם מתבצע ניתוח מערכות תהליך זה מתחבר
לבדיקה של מערכת מידע קיימת או לפיתוח מערכת מידע חדשה. לא כל הארגונים מבצעים תהליך שכזה בעת פיתוח מערכת מידע/רכישת חבילת תוכנה קיימת  וזאת מטעמי חסכון במשאבים וקיצור לוח הזמנים עד ליישום הפתרון.
 
אין ספק שניתוח מערכות צורך זמן ועולה כסף אבל אם חושבים לטווח הארוך (מערכת מידע "חיה" בדרך כלל בין 7 ל-15 שנים) הרי שהחסכון בטווח הקצר קטן בהרבה מהנזקים בהמשך. אם צריך להשוות את הסיטואציה הזאת לתחום אחר הרי שבניית וילה היא דוגמא טובה. הלקוח שבונה את ביתו אינו חייב להעסיק ארכיטקט והוא יכול להסתפק במהנדס בנין וקבלן אך התוצאה הסופית תהא בדרך כלל נחותה וכעבור מספר שנים יתחיל להיחשף לבעיות הרבות שחלקן היה נחסך לו היה נעזר בשירותיו של הארכיטקט.  
 
כשלים של מערכת מידע שלא נותחה  (לידיעתכם חלק לא מבוטל ממערכות מידע שפותחו נזרקו לפח האשפה בחודש הראשון להפעלתן) יכולים להתייחס למגוון של נושאים:
 
 
01. אמינות נמוכה (העדר בדיקות לוגיות שהיו יכולות לשפר את איכות הנתונים)
02. העדר שליטה ובקרה
03. מערכת פרוצה 
04. חוסר אפשרות להפיק דיווחים שלא תוכננו מראש (חסרים נתונים בבסיס הנתונים)
05. העדר דיווחים והתראות לדרג הניהולי
06. בסיס נתונים שנבנה בצורה לקויה שאינו מתאים לדרישות מהמערכת (זמן תגובה גבוה,סרבול
               בגישה לנתונים,מחסור במפתחות גישה)
07. תפעול מסורבל ויקר
08. תחזוקה שוטפת יקרה
09. זמן תגובה איטי
10. העדר מימשקים למערכות מידע אחרות בארגון או למערכות מידע של ארגונים שעמם הארגון
בקשרים עסקיים חזקים
11. המערכת לא מכסה תחומים משיקים (מערכת ניהול מלאי שאינה מחוברת למערכת הפיננסית)
12. כפילות נתונים
13. אין התבססות על תקנים קהילתיים ואין שימוש בערכים של נתונים המקובלים בקהיליה הרלבנטית (משתמשים בטבלאות פנימיות לארגון שמחייבות הסבה כשמעבירים נתונים לארגונים אחרים)
14. נפילות של המערכת לעתים קרובות
15. רמת מידור לוקה בחסר
16. העדר גמישות
17. תיעוד לא קיים/לא מעודכן
 
הרשימה אינה מלאה אבל די מייצגת ואם רוצים לסווג את הבעיות אזי ניתן לחלקן ל-4 קבוצות עיקריות:
א. בעיות בתהליך
ב. בעיות בנתונים
ג. בעיות במידע
ד. בעיות בטכנולוגיה
 
האם ניתוח מערכת יכול למנוע את כל הבעיות שאוזכרו לעיל ?
התשובה כמו במקרים רבים אחרים היא שהשקעה נכונה בניתוח המערכת תצמצם את ספקטרום הבעיות אולם לא תעלים אותן לחלוטין.
שתי שאלות שמנתח המערכות חייב לשאול את עצמו כל הזמן:
למה ?
מה יקרה אם...................?
אם תשאלו את עצמכם בכל צעד שאתם עושים את שתי השאלות הללו תגלו שחסכתם לעצמכם נפילה לבור שרבים אחרים נופלים לתוכו.
מה נדרש ממנתח מערכות ?
בהרבה הזדמנויות נשאלתי מיהו מנתח מערכות שיוכל לבצע את המשימה כיאות.
בעבר היו שתי אסכולות שולטות האחת גרסה שהוא צריך להיות מתכנת שצבר נסיון והפך לאחר מספר שנים למנתח מערכות בעוד השנייה גרסה שמנתח מערכות צריך ראייה רחבה יותר ולכן אין הכרח שהוא התנסה מספר שנים בכתיבת תוכנה. 
 
קורסים של ניתוח מערכות מספקים כלים טכניים (מתעדכנים כל הזמן) אבל מנתח המערכות נזקק לידע ממספר דיסציפלינות ומראייה רחבה ולא ממוקדת של התהליכים.
 
הדיסציפלינות הרלבנטיות הן מתימטיקה,סטטיסטיקה,תעשייה וניהול,מערכות מידע,מחשבים,מנהל עסקים,שיווק,הדרכה. הובלת פרויקט של מערכות מידע שנעשיית בד"כ ע"י מנהל פרויקט שהוא מנתח מערכות דורשת ידע ונסיון הרבה מעבר להיבט הטכני של ניתוח מערכות. מאחר וקשה למצוא אדם שסיים לימודים אקדמיים בכל התחומים שאוזכרו אז כמובן שמתפשרים לגבי הרקע האקדמי אבל יש להתעקש על שתי תכונות נסיון (רצוי מוצלח) במערכות עסקיות וכושר לימוד של עולם מושגים חדש.
 
יצחק בן עוזר: פרופיל
 
יצחק בן עוזר, שימש כמנהל פיתוח מערכות מידע ברשות הנמלים (לאחר מכן חנ"י) בין השנים 1978 ל-2005. בוגר תואר ראשון בכימיה מהאוניברסיטה העברית, בעל תואר ראשון בכלכלה, תואר שני במנהל עסקים-מימון (1981) ו- Post Graduate במערכות מידע (1987) מאוניברסיטת ת"א. מאז הפרישה מחנ"י פועל כפרילאנסר בפרויקטים של  אפיוני תהליכים ומערכות מידע בקהיליית הסחר הימי (חנ"י, מסוף קונטרם ובחברות הנמל אשדוד,חיפה ואילת). בנוסף מעביר קורסים והרצאות בנושאים של הסחר הימי לעובדים והנהלות של השותפים העסקיים שבקהיליה