ניתוח מערכות מידע - מקצוע מפוספס?

אם צריך לשים את האצבע על אחד התפקידים, שההשפעתו על פתרונות מערכתיים בארגון היא משמעותית ביותר, זה יהיה ניתוח המערכות מידע.

תפקידו הוא תרגום. כן, פשוט תרגום מהשפה העסקית לשפה הטכנולוגית ולהיפך.

אולם באופן מפתיע, למיטב ידיעתי, אין תואר אקדמי כזה, אלא תוכניות העשרה בלבד, באופן מפתיע קשה גם למצא הסכמה לגבי תכונות ויכולות הנדרשות ממנתח מערכות מוצלח ולא תמיד יש הסכמה לגבי תחומי האחריות.

מסתבר שהבנת ההשפעה הגדולה של המקצוע/המיומנות המאפשר תרגום נכון של בעיה עסקית לפתרון מערכתי אינה נחלת רבים ואפילו בתוך עולמות הפיתוח אין קונצנזוס לגבי הגישה.

לעיתים מבלבלים את ניתוח המערכות עם ניהול פרויקטים, במקרים אחרים עם פיתוח או ניהול צוות פיתוח, עם תכנון ממשק משתמש, עם ארכיטקט מערכת וכיוצ'. לעיתים אפשר אפילו לפגוש מנתחי מערכות שסתם שמו אותם ב"פוזיציה", לא מתוך ידע, אלא כדי שמישהו ממערכות מידע "ידבר" עם המשתמשים. הזוי.

בפוסט זה נדון בתפקיד החשוב הזה וננסה להגדיר את תפקיד המנתח, יחד עם קווים להכשרתו, בתקווה שמישהו באקדמיה ירים את הכפפה, ושמנמר"ים ידייקו בשילוב מיומנות זו ובכך לסייע בבניית הכוח של מערכות מידע באופן מדויק יותר.

תיחום וחידוד

יש לעשות הפרדה בין גופי מערכות מידע בתוך ארגונים, הנותנים שירות לארגון עצמו ובמידה מסוימת (כחלק משימוש באותן מערכות) ללקוחותיו, לבין מערכות המהוות מוצר ונמכרות ללקוחות או מספקות שירות SaaS. בפוסט זה אתמקד בתפקיד מנתח המערכות פנים ארגוני.

הגדרת המשימה של מנתח המערכות

ניתן להגדיר זאת באופן הבא: מנתח המערכות הוא האיש באגף מערכות המידע, הנדרש לפתרון בעיה עסקית. באמצעות כלים ומתודולוגיות מתחום מערכות המידע עליו ללמוד בשיטתיות את הצורך ולתרגם את הדרישה העסקית לדרישה טכנית, אשר אותה, אנשי הטכנולוגיה יודעים לממש.

אל חשש, הוא לא צריך לעשות זאת לבדו, מאחר שכשהוא מגדיר את הצורך העסקי, הוא עושה זאת יחד עם נציגי הצורך העסקי/המשתמשים. כאשר הוא צריך לתרגם את הצורך העסקי לפתרון הוא עושה זאת יחד עם אנשי המקצוע הטכניים. משימתו היא להגדיר במדויק ובאופן מתודולוגי את המשימה, תוך שיתוף והסכמה עם הצד העסקי. לאחר מכן, את המשימה הוא מתרגם למרכיבים כמו: נתונים, חוקים, פעולות, מסכים, תהליכים, אוטומטים, ממשקים, דוחות וכיוצ' אשר צירופם פותר את המשימה. יחד עם זאת רשימת המרכיבים חייבת להיות ברורה וברת ביצוע לאנשי הטכנולוגיה.

אז לסיכום, משימתו מתחלקת לשתיים:

1. ללמוד את הצורך/בעיה, על כל צדדיה ומצביה, להכיר את המשתמשים ותהליכיהם. לדייק את הבעיה ולמסמך הסכם עם המשתמשים על הבעיה ופתרונה (בד"כ – מסמך האפיון או מסמך הגדרת הדרישות)

2. להתייעץ עם כל הגורמים להם חלק בבניית הפתרון ולהסכים איתם על פתרון העונה על הצורך ולמסמך את הפתרון המוסכם במסמך טכני.

מחיר הטעות בניתוח מערכת

ניתן לראות בעין בלתי מזויינת את המחיר של ניתוח מערכות שנע בטווח שבין ניתוח חסר ברק (שלא לומר לא מקצועי) לבין היעדר תהליך ניתוח:

הארגון לא מצליח להדביק את מתחריו בשוק או את צרכי לקוחותיו מאחר ו:

• יש מעגל לא נגמר בין "פתרון בעיה עסקית" לבין חזרה לשולחן העבודה (Rework).

• קיים פער ציפיות בין צרכני הפתרון לבין מערכות מידע.

• ישנה ירידה עקבית בשימוש במערכות החברה (ללא קשר לגיל המערכת וליכולותיה) ועליה עקבית ב Shadow IT.

• משתמשים "חזקים" בארגון פונים בעצמם לספקים חיצוניים.

• עלות הבעלות של מערכות מידע עף לשמיים.

כשל השוק

רבים ממקבלי ההחלטות בארגונים לא מודעים לתהליך הנכון של "מחזור חיי תוכנה" המתחיל מהבנת הצורך, קרי: ניתוח מערכת. גם כשמודעים לצורך, לא תמיד מבינים את היקף ההשלכות לחוסר המקצועיות של מנתחי המערכות.

בחלק מהארגונים, יש נטייה לאמץ מודל, בו מפתחים בכירים מבצעים את ניתוח המערכת. מודל זה סובל מכשל לוגי בסיסי: הכישורים של מפתחים טובים, שונים ממה שנדרש בכדי להיות מנתח מערכות טוב (על זה נאמר לא פעם – "למי שיש CPU חזק, בד"כ מגיע ללא כרטיס תקשורת").

בארגונים אחרים, ממנים לתפקיד המנתח אנשים שהגיע ממקצועות שאינם מדעי המחשב. גם כאן יש בעיה: שהרי אם מנתח המערכות מבין את הצד העסקי היטב, אבל לא מבין את העולם הטכני, כיצד יתרגם?

ובמקרים אחרים את מקצוע מנתח המערכות מחליפים מנהלים "שיודעים מה צריך". כאןף כנראה הזק הוא הגדול ביותר.

אז מה כן? כנראה שהאידיאל למנתח מערכות טוב, הוא מישהו שבא ממדעי המחשב, שאפילו צבר ניסיון מינימלי בעבודת פיתוח טכנית, אולם נטייתו היא לעבוד יותר עם אנשים ופחות עם מכונות. להכשיר אדם כזה כמנתח מערכות זה כבר קל. כל שעליו ללמוד הוא את המתודולוגיות של איסוף ו"פיצוח" דרישות המשתמשים יחד עם מתודולוגיות ניהול מחזור חיי תוכנה.

איפה הכשל?: בכמה מקומות:

1. עלות של מנתח מערכות כזה תהיה גבוהה מאד.

2. למיטב ידיעתי, אין בארץ מסלול אקדמי שמאתרג את ניתוח המערכות. אלא בעיקר מסלולי הכשרה נפרדים שלא מיועדים לבוגרי מדעי המחשב אלא פתוחים לכל. ולעניות דעתי, האמירות המתפשרות שמי שלמד א' יכול לעשות גם ב' נפגשות איתנו במחיר הטעות.

3. התובנה של עד כמה קריטית משימתו של המנתח בקיום הארגון, אינה נחלת רבים.

4. ישנן מתודולוגיות פיתוח המדלגות על מנתח המערכות ומחברות את המשתמש עם המפתח. למרות הייתרונות הברורים - יש לזה מחיר.

מה נדרש ממנתח מערכות טוב?

ניתוח מערכות = תרגום

מאפיינים עיקריים של מנתח מערכות טוב:

1. ראשית, מדובר באופי: איש שמבין אנשים ומתקשר היטב. אינטלגנציה רגשית המאפשרת להבחין בין מה המשתמש/לקוח אומר, לבין מה הוא רוצה (ולא תמיד אומר) ולזכך מה באמת צריך (ולא תמיד מכוון לשם).

2. רקע טכני (מדעי מחשב או מערכות מידע) עשיר והיכרות קרובה עם "מחזור חיי האפליקציה" (ALM) הרלוונטי לארגון.

3. הכרת המתודולוגיות המסייעות לחידוד המסרים הרבים וזיקוקם להגדרת הבעיה/המשימה.

4. הבנה עמוקה של התהליכים העסקיים בארגון, מתוך היכרות וניסיון במתודולוגיות ארגון ושיטות.

5. יכולת ביטוי וכתיבה טובים.

6. יכולת פישוט והוצאת העיקר מהטפל.

לפי רשימה זו, ניתן להבין עד כמה עמוקה ההכשרה של מנתח מערכות טוב. את סעיפים 2 ו 3 היינו רוצים שהאקדמיה תציע מסלולים שאלה הקווים המנחים שלה.

סעיף 4 היא הכשרה פנים ארגונית. הכשרה זו לא חייבת להיות ארוכה, מאחר ומנתח המערכות הוא זה שאמור ללמוד מערכות ותהליכים במהירות. הרי הוא בקיא במתודולוגיות החקירה, איסוף וניתוח תהליכים בארגון.

סעיפים 1, 5 ו 6 תלויים באדם. לכן אפשר לצפות שהאקדמיה תכווין את האנשים הרלוונטים למסלול זה וכמובן בעת קבלת מנתח מערכות לארגון, יש לתהות על יכולותיו בתחומים אלה.

הערה: האמור לעיל אינו תורה מסיני, שהרי אפשר להתפשר. אולם – לכל פשרה יש מחיר וחייבים לכמת אותו בטרם מתפשרים.

כיצד משלבים את מנתח המערכות בארגון

נתאר על קצה המזלג את עבודת המנתח: על כל "יחידת פיתוח" או פתרון ארגוני, למנתח המערכות יש 5 פרקים לביצוע:

1. הגדרת הדרישות מול המשתמשים + כתיבת המסמך.

2. תרגום הדרישות לפתרון טכני, יחד עם אנשי המקצוע הטכניים + כתיבת מסמך.

3. ליווי תהליך הפיתוח בכל הדילמות שצצות במהלכו.

4. להיות אחראי על איכות התוצר והתאמתו לדרישות באמצעות בדיקה אישית, ליווי צוות הבדיקות וליווי תהליך בדיקות הקבלה של המשתמשים.

5. להטמיע את השינוי/פתרון ע"י הדרכות והתמודדות עם בעיות הצצות בתהליך.

המשמעות היא שידיו מלאות בעבודה, על כן כמה מנתחי מערכות צריך? ובכן זה תלוי מן הסתם בשני פרמטרים:

• צד המשתמשים: תלוי בכמה תהליכים חדשים או עדכונים/התאמות צריך לעשות ביחידת זמן. כמובן שזה נגזר מגודל הארגון, כמות המערכות בארגון, כמות המשתמשים לכל תהליך/פתרון.

• צד הפיתוח: כמה צוותי פיתוח יש בארגון (פנימיים או חיצוניים), כמה טכנולוגיות יש להכיר בכדי לאפיין נכון פתרון, כמה צוותי בדיקות מושקעים באיכות הפתרון.

לאחר הבנת המשימה של המנתח, נבין טוב יותר כיצד לשלב.

למיקום הארגוני של מנתחי המערכות ישנן מספר גישות:

גישת "המשתמש שולט": בארגונים כאלה, שהם בד"כ גדולים כגון בנקים, חברות ביטוח וכד' מוגדר אדם (לעיתים מחלקה) המקשרת בין מערכות מידע לעסק פר אגף בארגון והתפקיד נקרא BRM( Businness Relation Man.) . במקרה כזה, כל משימות הניתוח והתרגום בין הצורך העסקי ליחידות הביצוע במערכות מידע באחריותו.

גישת "הטכנולוגיה שולטת": נפוצה בארגונים שהמוצר שלהם נשען בכבדות על טכנולוגיה (עדיין הפוסט מדבר על מערכות המידע הפנים ארגוניות ולא על המוצר ללקוח). עד כדי כך שכל הארגון דובר את שפת הטכנולוגיה. בארגונים כאלה, בדרך כלל מנתח המערכות עובד בכפוף ל או בצמוד למנהל צוות טכנולוגי בכדי לאפשר להובלה הטכנולוגית לשמור על חוט שדרה טכנולוגי.

גישת ה "PMO": גישה שהלו"ז והתפוקה הם בראש מעינינו וכך, מי שמרכז את הפרויקטים בארגון מנהל גם את מנתחי המערכות שלמעשה הם המוציאים והמביאים בכל הפרויקטים. במצב זה כנראה שמנתחי המערכות יהיו במחלקה נפרדת אולם עדיין, בכדי לשפר תפוקות, הם יפתחו התמחות ארגונית וכנראה שיעבדו בצמידות לצוות פיתוח המתמחה באותו תחום.

האם המתודולוגיות והכלים שבשימוש חברות המנהלות ומוכרות מוצר טכנולוגי רלוונטיות למערכות מידע ארגוניות?

הכוונה לכלים ה"תופרים" את ניהול המשימה מהשיווק, עד לפיתוח וחזרה, כגון Gira, Slack, Teams, והמון אחרים.

התשובה היא "כן ולא". מצד אחד, אני לא רואה שבכדי לשפר את הניהול והתפוקה של צוותי פיתוח בארגון, משתמשי הקצה יעבדו על סט כלים ייעודי, שאינו ממלא פונקציונאליות במשימתם בעבודה, אלא אצל ספק השירות שלהם, קרי: מערכות מידע. מצד שני יש בחברות המוצר המון ידע נצבר וכלים שיכולים לסייע. על כן בארגון שאינו קטן (נזרוק מספר: 500 עובדים ומעלה) יש כלים שהייתי שוקל ליישם.

האם יש בכלים ומתודולוגיות בניהול המוצר תחליף למנתח המערכות בארגון – לא !

לסיכום - מה לקחת מהפוסט על: "ניתוח מערכות - מקצוע מפוספס?"

• משימת מנתח המערכות היא קריטית לארגון מבוסס מערכות מידע (איזה ארגון הוא לא?).

• יש כשל שוק ביצירת מנתחי מערכות טובים וישנם לא מעט פרקטיקות גרועות להשמות האנשים הלא נכונים לתפקיד זה, לשם כך שמתי כאן את המרכיבים המאפשרים לארגון לעבוד נכון.

• שילוב מנתחי המערכות בארגון אינו שרירותי. צריך שתהיה חשיבה נכונה ויד מכוונת בכדי לשפר את התוצאות.

בהצלחה...