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

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

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

כך תתכוננו למסע לדיגיטל

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

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

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

הטייה זו כלפי ״עליונות מדומה״ לא ייחודית עבור ה-IT, אלא היא נטייה אנושית כללית ותופעה פסיכולוגית מתועדת היטב. לעתים היא נקראת Lake Wobegon Effect או, בצורה טכנית יותר, Dunning-Kruger effect. דוגמה לכך היא ניסוי שבו נשאלו סטודנטים כיצד הם מעריכים את האינטליגנציה ואת יכולות החשיבה הלוגית שלהם. התוצאות הראו שגם הסטודנטים בעלי הציונים הנמוכים העריכו את עצמם בצורה גבוהה.

הבעיות – והדרכים לפתרון

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

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

●    להמיר בסיס פרויקט לבסיס מוצר ממוקד יכולת עסקית.
●    להכפיף את קצב שיפור הדילוור למענה לצורך  (Fit for purpose) ולערך העסקי.

ומנקודת מבט טכנית:

●    ליצור סביבות סטייג׳ינג וירטואליות ״כמו בחיים״, כמו של מערכת יעד של אספקה רציפה.
●    לאמץ בדיקות אוטומטיות, אבל להבין את המגבלות שלהן. מדובר במהלך ראשון להבטחת איכות העבודה.
●    לתרגם דרישות לבדיקות קבלה של משתמש ועסק – בהתחלה כסקריפטים ידניים, שלאורך זמן יתפתחו לסקריפטים אוטומטיים. מדובר במהלך שני להבטחת איכות העבודה, שידרוש הבטחת איכות קרובה יותר לעסק.
●    לבנות בדיקות קבלת משתמש לתוך תהליך פיתוח תוכנה זמיש על ידי הפיכת בדיקות משתמש למטרת העל של הספרינטים והכפפת קריטריונים אחרים לבחירה לכך. הכוונה היא לבדיקות משתמש בפועל – בתוך הסביבה הווירטואלית. לא Demos, לא בדיקות בעל המוצר, לא בדיקות הבטחת איכות ובטח שלא פיתוח יעשו את זה בשביל הארגון.
●    למדוד את שביעות הרצון של המשתמש ב-KPI בסביבות סטייג׳ינג וייצור, וליצור kpi של ערך עסקי בסביבות ייצור.