אריה עמית | יועץ אסטרטגי, חבר נשיאות הלשכה
מנמ"רים מתמודדים עם יישום מגה פרויקטים ותוכניות טכנולוגיות גדולות. למעשה, שתיים מתוך שלוש תוכניות גדולות חורגות באופן קבוע מהתקציבים הראשוניים, מפספסות את הערכות לוח הזמנים ואינן משיגות את היעדים והיתרונות העסקיים המצופים.
מחקרינו שנערכו בעבר מצאו כי 25 עד 40 אחוז מהתוכניות חורגות מהתקציב או מלוחות הזמנים שלהם ביותר מ -50 אחוזים. שיעור כישלונות זה פוגע בעסק מכיוון שלתוכניות גדולות יש בדרך כלל חשיבות קריטית עבורו.
שיעור כישלונות זה לא חייב להיות הנורמה. מספר שיטות וטכנולוגיות דיגיטליות חדשות שהופיעו בשנים האחרונות יכולות לשפר באופן דרסטי את יישומי התוכניות הגדולות. בשילוב עם פרקטיקות ניהוליות וכישרונות אישיים ניתן להתמודד ביעילות עם המורכבות העצומה של תוכניות טכנולוגיות גדולות, אחוזי ההצלחה יכולים אף להגיע עד 90 אחוזים ומעלה
מה מניע את שיעורי הכישלון?
תשובות המנמ"רים לכך שונות ומגוונות, החל מיעדים לא ברורים וכלה בניהול שינויים לא יעיל, יכולות צוות לקויות או ליקויים אצל הספק. יש שיאמרו התאמה אישית מוגזמת (Over Specification או Over Design), החלטה שגויה בבחירת הפלטפורמה או קבלת החלטות לא יעילה. במובנים רבים, זה נכון ומשקף מציאות של תוכניות יישום טכנולוגיות גדולות: הן מורכבות ביותר. אמנם זה לא אמור להפתיע, מנמ"רים ממעיטים ללא הרף בהיקף ובעומק המורכבות הזו. מסיבה זו, ישנה להם נטייה טבעית להשתמש בתיקונים פשוטים או על ידי מציאת מוצרי מדף נכונים וסיוע של אינטגרטור, כדי לפתור את הרוב המכריע של הבעיות בתוכניות הגדולות שלהם.
למרבה הצער, הצלחה יכולה להתרחש רק כאשר מנמ"רים מכירים מספיק במורכבות. בפועל, פירוש הדבר לנהוג בביצוע מעולה על פני עשרה תחומים שבתרשים. כל אחד מתחומים אלה הנו נושא משמעותי בפני עצמו, הדורש ממיומנויות ויכולות צולבות לביצוע יעיל.
מקור: McKinsey Digital
הגרף שלעיל מציג שילוב של שלושה מהלכים לאורך חיי הפרויקט שיכולים להגדיל את הסיכויים להצלחתו:
· תיכנון – חזון ואסטרטגיה, עלויות וערך מוסף, מפת דרכים ליישומים ומוצרים, חוויית לקוח, ארכיטקטורת נתונים ופלטפורמה, העבודה עם הספקים
· ביצוע - ניהול פרויקטים מתודולוגי ומשילות ( Governance), ניהול יכולות וכישורים, המעבר למודל התפעולי החדש
· ניהול השינוי – תרבות, הפקת לקחים ושיפור מתמיד
חשוב לשים לב לחלוקת הזמן השווה בין התכנון והביצוע לאורך הפרויקט ומידת החפיפה ביניהם. ניהול השינוי מתבצע באופן קבוע לכל אורך הפרויקט.
אך השיקול העיקרי הוא כיצד לאזן בין המורכבות העצומה של התוכנית לבין הצורך המעשי להתקדם. הניסיון מלמד כי, פגיעה במאזן זה בהצלחה מחייבת ארגונים לתעדף בין חמישה לעשרה גורמי הצלחה לכל אחד מעשרת התחומים ולפתח יכולות ניהול תוכניות גדולות בהתאם. ניהול פרויקטים מסורתי פשוט אינו תלוי במורכבות של ניהול מספר רב של זרמי עבודה תלויים זה בזה, הצורך בשליטה טכנית בתחומים רבים, והחשיבות בהתאמת משתנים תלויים רבים במהלך הנסיגות והאתגרים הבלתי נמנעים של תוכנית בקנה מידה כזה.
לדוגמא, הכשרה של מנהלי פרויקטים מסורתיים מלמדת מנהלים לפתח ציר זמן רציף ומדויק של פעולות מתחילת הפרויקט ועד סופו ואז להתנהל בקפדנות מול פעולות אלה. עבור תוכניות גדולות ומורכבות זו הופכת במהירות למשימה בלתי אפשרית, וכמות העבודה והעיבוד הדרושים ליצירת רמת פירוט זו אינם שווים את המאמץ. בעוד שתוכניות גדולות עדיין זקוקות ללוחות זמנים משולבים, הן לא יכולות להניח שהכל מהסתדר מראש. בגלל יחסי הגומלין והתלות בין תחומים, ניתן לנהל את המורכבות ביעילות רק על ידי עבודה דרך התחומים באופן איטרטיבי ובמקביל, לא על ידי הנחת כל צעד אפשרי מראש.
הניסיון בעבודה על תוכניות יישום טכנולוגיות גדולות, מלמד כי הסיכויים לביצוע מוצלח משתפרים אם ננקוט בשש פעולות ספציפיות, ארבע מהן משתמשות ביכולות דיגיטליות חדשות ושתיים בגישות ותיקות אך לעתים קרובות מוזנחות
1. שימוש בשיטות Agile ב"מחזור חיי" התוכנית.
"מחזור החיים" של תוכניות רבות מתבסס על שיטת "מפל המים" Waterfallהקלאסית והמסורתית המבחינה בין שלבים מוגדרים של ייזום, אפיון, עיצוב, פיתוח ויישום, בדיקות, עד להטמעה והדרכה שעורכת זמן רב.
הערך חשוב בעולם פיתוח המערכות המודרני, לצד התאמה מרבית לצרכי הארגון, הינו ה- Time to Market של יישומים חדשים שיאפשרו לארגון ערך ויכולות חדשות ומהר. כמענה לצורך הארגונים עוברים לפיתוח בשיטות זריזות וגמישות - Agile, שביסודן עומדות איטרציות קצרות בהן שותפים כל הנוגעים בדבר: מנתחי מערכות, מפתחים ונציגי המשתמשים המגדירים משימות ועומדים בהם ומציגים ערך בלוחות זמנים קצרים.
ה- Agile היא מתודולוגיה לפיתוח מהיר ויעיל, המאפשרת פיתוח בצעדים קטנים ומאוד מהירים. אם נמצאה טעות התיקון מבוצע באופן מהיר ביותר. המתודולוגיה הזו מסייעות למנהלי הטכנולוגיה ולעמיתיהם ביחידות העסקיות להבין טוב יותר את הפונקציונאליות של הפרויקטים שיש לבצע – וגם מה לא ניתן וצריך לעשות.
השיטה מבוססת על ההנחה כי לא ניתן להגדיר צרכים במלואם וכי טעויות מתרחשות תמיד ולפיכך מתמקדת ביכולת הצוות לספק תוצרים במהירות ולהגיב לדרישות העולות תוך כדי פיתוח. הדיאלוג בין הלקוח, המפתחים וההנהלה מודגש מאד בשיטה זו. הלקוחות מקבלים תוצרים בין פרקי זמן קצרים יחסית ויכולים לבצע שינויים תוך כדי תנועה. יתרונות השיטה: הקטנת סיכונים, גמישות בדרישות, חדשנות, קבלת תוצרים "נראים" בתוך פרקי זמן סבירים, מעקב ובקרה שוטפים ואפשרות להפסקת ההתקשרות ביתר קלות.
2. בסס את העבודה על חשיבה עיצובית.
תוכניות גדולות רבות עשויות לעמוד בדרישות אך לא תמיד מתאימות לצרכי המשתמשים. תוכניות גדולות מצליחות משתמשות בחשיבה עיצובית - שיטה לפתרון בעיות המעוגנת בצרכי משתמשי הקצה - כדי לטפל בבעיה זו. החשיבה העיצובית עוזרת לספק מוצרים ושירותים שמשתמשים רוצים וזקוקים להם ולכן הם נוטים יותר להשתמש בהם. יתרון נוסף הוא חיסכון, מכיוון שהצוותים מפתחים רק את התכונות הדרושות.
עבור תוכניות גדולות, חשיבה עיצובית מתחילה עם חשיפת צרכי המשתמש כבר בהתחלה, בדרך כלל באמצעות שילוב של מחקר כמותי ואיכותי. מאמצים אלה מפיקים תמונה ברורה על האופן שבו אנשים משתמשים בשירות או במוצר, ובצרכים שלא קיבלו מענה. מעורבות משתמשים קבועה ומשקיפה לאורך כל מסירת התוכניות - למשל, באבות טיפוס ובבדיקת משתמשים - ואז מבטיחה שהתוכנית שומרת על התאמה לצרכי המשתמש לאורך זמן.
3. השתמש בשירותים מבוססי ענן.
רוב המנהלים הבכירים עדיין נוטים להפחית את היתרונות של ענן ליעילות סביב ניהול תשתיות. היכולות, הרכיבים והשירותים שמציעים ספקי שירותי ענן רבים (CSP) ,לעומת זאת, מאפשרים לחברות המנהלות יישומים בתכניות גדולות לחדש הרבה יותר מהר ולהגיע לשוק מהר יותר באמצעות מתן סביבה מהירה ודרכים פשוטות יותר לאבות טיפוס או לבחינת פתרונות חדשים.
עבור תוכניות גדולות, על המנמ"רים להעריך באופן שיטתי כיצד לנצל את הענן בצורה הטובה ביותר. בחירת פיתרון תוכנה כשירות (SaaS), למשל, יכולה להימנע ממאמץ של בנייה מותאמת אישית ויכולה לגרום לפיתרון הטוב ביותר שקל יותר לתחזק אותו. או מינוף של פתרון פלטפורמה כשירות (PaaS) יכול לאפשר פרודוקטיביות רבה יותר של מפתחים וגישה למערכת אקולוגית של אלפי שירותים חדשניים.
4. השתמש בארכיטקטורה מודולרית להגברת הגמישות ותחרות הספקים.
ארגונים רבים עוברים לארכיטקטורות גמישות יותר, כגון מיקרו-שירותים. מהלך זה לא רק יוצר יישומים ארוכי טווח ויותר "עמידים לעתיד" אלא גם מאפשר לחברות להשתמש באסטרטגיית מקור רב-ספקית ובכך לפתור את אחד האתגרים הארוכים ביותר עם הצגת תוכניות גדולות: שמירה על תמריצים של ספקים.
בפתרונות של ספק יחיד, כמעט בלתי אפשרי להפעיל לחץ עלות קבוע, מכיוון שלעתים קרובות פרמיית הסיכון בחוזה במחיר קבוע משמעותית והזמנות שינוי נפוצות. לחלופין, חוזי זמן וחומרים יוצרים תמריצים לספקים להרחיב ולהרחיב תוכניות וכך להגדיל את זרם ההכנסות שלהם.
במקום זאת, ארכיטקטורות מודולריות מאפשרות לחברות לעבוד עם מספר ספקים שניתנים להחלפה לפי הצורך, והשגת ל\תוצאות טובות משמעותית.
5. השג אנשים עם ניסיון רב-תכניתי.
בהתחשב במורכבות יישומי התוכניות הגדולים, חיוני שיהיו אנשים שכבר עשו אותם, או משהו דומה. פשוט אין תחליף לסוג כזה של חוויה ו"זיהוי תבניות ". בלעדיה סביר להניח שכישלון. כפי שניתן היה לצפות, קשה למצוא אנשים אלה, במיוחד מכיוון שרוב הארגונים מחפשים אותם.
המנמ"רים מנסים לטפל בבעיה זו באופן טבעי על ידי איסוף צוות של האנשים הטובים ביותר שהם יכולים למצוא. אך כדי להבטיח שצוות זה יטפל בפערי הכישרון שלהם נדרשת הערכה כנה של הכישרון הקיים של הצוות ונכונות להביא את האנשים הנכונים, בין אם באמצעות העסקתם ובין אם התקשרות עם שותפים עיסקיים. זה יכול לקחת זמן רב, אבל זה הכרחי.
שכירת אינטגרטור מערכות למילוי החורים החסרים לרוב לא תעבוד, מכיוון שיש לו תמריצים אחרים - זחילה בהיקף או עיכובים מגדילים את הכנסותיו.
6. היו אגרסיביים לגבי התיקונים והשינויים הנחוצים.
כל תוכנית בסדר גודל זה עומדת להיתקל בבעיות. כאשר זה קורה, המנהלים וצוותי העבודה מנתחים את הבעיה וממליצים על תיקון. אך התערבויות אלו לרוב אינן אגרסיביות מספיק בכדי להגיע לשורש הבעיה. זה מובן, מכיוון שהתוכניות האלה מורכבות כל כך. המערכות המרובות שלהם תלויות זו בזו יכולות להקשות הן על איתור מקור הנושאים והן על גיוס המאמץ המשמעותי לרוב הדרוש בכדי לתקן את התיקון.
