כיצד ניתן למנוע כישלונות בפרויקטי IT?

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

ישראל אינה ייחודית בנושא הזה. חברת הייעוץ בוסטון מצאה במחקר שנערך על ידה, כי 70% מהטרנספורמציות הדיגיטליות אינן ממלאות את הייעוד שהציבו לעצמן. דו"ח אחר שפרסם אתר החדשות CIO העלה, כי נכון לסוף שנת 2020, כ-74% מהארגונים שהחלו בפרויקט מודרניזציה לא סיימו אותו. ממצאים אלה תואמים מחקר גדול של חברת הייעוץ מקינזי, גם הוא נכון לסוף שנה קודמת, ש-70% מהפרויקטים אינם מסתיימים לפי התכנון.

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

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

ניהול שינויים

תחום אחר שתורם לכישלון או לעצירה של פרויקטים נמצא בעולם ניהול השינויים, שהוא אתגר ניהולי מורכב בכל מצב ולא קשור רק לטכנולוגיה. יועצים שעוסקים בהטמעת מערכות ועובדים עם ארגונים בעולם מדווחים, כי לא תמיד צוותי ההנהלה מחויבים באמת למשמעות של התהליכים הטכנולוגיים, ובפועל מתחברים למתנגדים לשינוי ובכך מייצרים ציפיות לא נכונות מהפרויקט. כדי שזה לא יקרה מומלץ גם להימנע מלתת תחושה מצד המנמ"רים, שנוהגים לומר: "יש לי תוכנית מושלמת ב-100%". מובן שזה לא ישים. די אם מנמ"ר יתכנן תוכנית עם 60% אחוז ודאות וישאיר 40% לגמישות, לשינויים בלתי צפויים ולדרישות חדשות.

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

הגורם האנושי

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

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