מודרניזציה למערכות Legacy: איך בונים הצדקה עסקית שההנהלה תאשר

בקצרה: להחזיק מערכות ישנות באוויר עולה הרבה כסף. הממשל הפדרלי בארה״ב, למשל, מוציא כ-80% מתקציב ה-IT שלו על תפעול ותחזוקה של מערכות קיימות (GAO, 2019). העלויות הגדולות באמת לא מופיעות בשום סעיף: שעות פיתוח שהולכות על עקיפות, פיצ׳רים שאי אפשר לבנות ופרצות אבטחה שמצטברות. כדי שהמודרניזציה תאושר, תנו לסמנכ״ל הכספים מסגרת עלויות שהוא יכול לבדוק בעצמו. במאמר הזה תמצאו אותה.

"המערכת ישנה" זה לא נימוק לתקציב

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

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

התחזוקה כבר אוכלת את רוב תקציבי ה-IT. ב-2019 דיווח משרד מבקר המדינה האמריקאי (GAO) שכ-80% מתוך יותר מ-90 מיליארד דולר שתוכננו להוצאות IT פדרליות הלכו לתפעול ולתחזוקה של מערכות קיימות, כולל מערכות Legacy מזדקנות.

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

שבעה סימנים שהמערכת עולה לכם יותר משכתוב

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

1. התחזוקה אוכלת 70% או יותר מתקציב הפיתוח. ספרו הכול: את הקבלנים ש"פשוט יודעים איך זה עובד", את הצוות שמטפל בתקלות של הלילה ואת השעות שהמהנדסים שורפים על עקיפות.
2. אי אפשר לגייס אנשים לטכנולוגיה שלכם. COBOL,‏ PowerBuilder או Framework פנימי מ-2008 הופכים כל גיוס לחיפוש מחט בערימת שחת, והמומחים הבודדים שנשארו גובים תעריפים של יועצים.
3. פיצ׳ר פשוט לוקח שבועות. שדה חדש בטופס נוגע ב-15 נקודות אינטגרציה, ואף אחד לא בטוח מה עוד יישבר בדרך.
4. זמן ההתאוששות מתארך. עקבו אחרי הזמן הממוצע להתאוששות מתקלה (MTTR), משנה לשנה. במערכת בריאה, תקלה ב-Production נפתרת בפחות משעה. אם אתם כבר ב-4 שעות והמספר ממשיך לעלות, המערכת מנסה להגיד לכם משהו.
5. שירותים מודרניים לא מתחברים. כל חיבור חדש ל-CRM, לסליקה או לענן הופך לפרויקט Middleware נפרד, שמתחיל ב-150,000 ש״ח, יכול להגיע ל-300,000 ש״ח ולוקח חודשים.
6. עדכוני האבטחה נגמרו. תוכנה שהגיעה לסוף חייה, כמו Windows Server 2012 או Java 7, כבר לא מקבלת תיקונים. בפיננסים, בבריאות ובממשלה, תוכנה בלי עדכוני אבטחה היא גם הפרה של דרישות הרגולציה.
7. המתחרים משחררים מהר יותר. כשהם משחררים גרסה כל חודש ואתם כל רבעון, הפער מצטבר, והלקוחות מרגישים אותו.

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

שלב 1: כמה המערכת באמת עולה לכם

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

העלויות שלא רואים

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

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

גיוס ושימור. מפתחים צעירים ומפתחים ברמת ביניים לא ירצו לעבוד עם COBOL,‏ ASP קלאסי או גרסאות Framework בנות עשור. בכירים יסכימו, תמורת שכר גבוה יותר. אם התחלופה אצלכם גבוהה מ-20% ובראיונות העזיבה מזכירים את הטכנולוגיה, זו עלות ישירה של ה-Legacy. וכל מחליף עולה לכם עמלת השמה וחודשים של קליטה.

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

המחשבון

כשהרצנו את התרגיל הזה עם לקוחות, הסכום הסופי הפתיע כמעט תמיד את כל מי שישב בחדר. חברות שמוציאות בין 1.5 ל-3 מיליון ש״ח בשנה על "תחזוקה" של מערכת Legacy מוציאות בפועל בין 6 ל-15 מיליון ש״ח, כשסופרים גם את העלויות הנסתרות.

שלב 2: מה בדיוק אומרת "מודרניזציה"

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

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

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

שלב 3: מודל ה-ROI

החיסכון השנתי אחרי המודרניזציה

תרחיש טיפוסי: מס Legacy שנתי של 6 מיליון ש״ח. השקעה של 1.5 מיליון ש״ח במודרניזציה. תחזוקה של 600,000 ש״ח בשנה למערכת החדשה. ההשקעה מחזירה את עצמה תוך 3 עד 4 חודשים מסיום הפרויקט, ומהשנה השנייה ואילך החיסכון עומד על כ-4 מיליון ש״ח בשנה.

שלב 4: ענו על החששות לפני שמישהו מעלה אותם

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

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

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

המצגת שסמנכ״ל הכספים צריך לראות

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

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

ממשיכים לשחרר פיצ׳רים, ובמקביל מחזירים חוב

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

קודם מודדים. עקבו אחרי זמן המחזור (מה-Commit ועד Production), צפיפות הבאגים (באגים לכל פיצ׳ר) ושביעות הרצון של המפתחים. יחד, שלושת המדדים מראים איפה החוב כואב הכי הרבה.

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

תעדפו לפי סוג החוב:

שיפורים בתשתית ובקוד מראים תוצאות בדרך כלל תוך 2 עד 3 חודשים. עבודה על הארכיטקטורה לוקחת 6 עד 12 חודשים, ומביאה את הרווח הגדול ביותר לטווח הארוך.

שאלות נפוצות

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

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

כמה זמן לוקחת מודרניזציה של מערכות Legacy בארגון? שלב 1 (המערכת עם ההשפעה הגדולה ביותר): 3 עד 6 חודשים. מודרניזציה מלאה של מערכות הליבה: 12 עד 24 חודשים, בשלבים. חברות שמנסות לעשות הכול בבת אחת תוך חצי שנה מוצאות את עצמן אחרי 24 חודשים, עם פי 3 מהתקציב.

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