רציונליזציה של תיק השקעות לאחר מיזוגים ורכישות

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

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

מדוע מיזוגים ורכישות יוצרים את צו הרציונליזציה של תיק ההשקעות

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

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

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

היקף הבעיה מחמיר עם כל רכישה חוזרת. ארגון שצמח באמצעות רכישות סדרתיות ללא אינטגרציה קפדנית של תיק העבודות לאחר מיזוג, נושא בחוב הטכני המצטבר של כל עסקה שלא עיכלה במלואה. ארגון גדול ממוצע מפעיל מעל 370 יישומי SaaS. בין 25 ל-30 אחוזים מהרישיונות הללו אינם בשימוש או אינם מנוצלים במלואה באופן משמעותי. ארגונים משאירים על השולחן כ-19.8 מיליון דולר ברישיונות שאינם בשימוש מדי שנה. הוסיפו את שכבת היישומים מדור קודם, תוכנות COBOL, התאמות אישיות ERP קנייניות ומערכות אצווה של מיינפריים שאינן מופיעות בביקורות רישיונות SaaS, ותיק העבודות שהרציונליזציה חייבת לטפל בו גדול משמעותית ממה שמציע מלאי ה-SaaS.

שלושת הפערים שגורמים לכשלונות רציונליזציה

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

פער 1: מטרה מוצהרת לעומת מטרה אמיתית

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

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

פער 2: תלויות לא מוצהרות

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

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

פער 3: הערכת חסר של היקף העברת הנתונים

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

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

חמש החלטות הרציונליזציה

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

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

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

תנאי מוקדם לניתוח מבני

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

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

ארבעה תוצאות ניתוח מבני הנדרשות לקבלת החלטות רציונליזציה:

מלאי לוגיקה עסקית. אילו כללים האפליקציה מקודדת? לא התיאור הפונקציונלי שמספק בעליה, אלא החישובים הספציפיים, הענפים המותנים, כללי האימות ולוגיקת הטרנספורמציה המיושמים בקוד התוכנית. עבור תוכניות COBOL, משמעות הדבר היא ניתוח חלוקת ה-PROCEDURE DIVISION כדי לחלץ את לוגיקת IF/EVALUATE, את משפטי COMPUTE ואת נתיבי העיבוד המותנים המיישמים את כללי העסק. מלאי זה הוא המפרט שכל מערכת חלופית או מאחדת חייבת להתאים לו.

ניתוח Fan-in. כמה יישומים, תוכניות או תהליכים אחרים תלויים בפלט של יישום זה? Fan-in הוא המנבא העיקרי לסיכון פרישה: יישום עם אפס fan-in יכול לצאת משימוש בבטחה; יישום עם חמישים fan-in נושא את הסיכון שפרישה תשבור חמישים דברים אחרים. בסביבות מדור קודם, fan-in כולל לא רק קריאות API ישירות אלא תלויות בהזנת נתונים, צרכני קבצי VSAM משותפים, זרמי משימות JCL המפעילים את התוכנית ותהליכי אצווה במורד הזרם שקוראים את מערכי הנתונים של הפלט שלה.

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

מורכבות העברת נתונים. מהו מבנה פריסת הרשומות של כל מערך נתונים שהאפליקציה מנהלת? כמה גרסאות REDEFINES קיימות? אילו שדות COMP-3 דורשים מיפוי סוג יעד לשמירה מדויקת? אילו כללי עסקיים שולטים בנתונים שעליהם תלויים צרכני האפליקציה? התשובות קובעות האם העברת הנתונים היא המרת סכימה פשוטה או תוכנית טרנספורמציה של נתונים בת מספר חודשים.

ציר הזמן של 100 הימים: כאשר מהירות מתנגשת עם יסודיות

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

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

הפתרון שפיתחו רוכשים בוגרים אינו לדחוס את הניתוח אלא לסדר את ההחלטות:

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

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

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

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

משיכת נכסים: הבעיה ההפוכה

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

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

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

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

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

קוד מדור קודם במיזוגים ורכישות: המימד שאף אחד לא מתחשב בו

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

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

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

אילו תוכניות הן תשתית משותפת לעומת תוכניות ספציפיות ליחידה עסקית? תוכנית שירות JCL הנקראת על ידי ארבעים תוכניות ברחבי הארגון המשולב היא תשתית משותפת. שגרת חישוב COBOL הנקראת על ידי שלוש תוכניות המשרתות יחידה עסקית אחת היא ספציפית ליחידה עסקית. ניתוח Fan-in על פני מלאי התוכניות המשולב מייצר סיווג זה באופן אוטומטי.

קובול

      *> Target company's tax calculation -- 40 years of jurisdiction rules
      *> 63 countries, 847 tax rule conditions, embedded in this program
      *> Not documented anywhere except in this PROCEDURE DIVISION
       CALCULATE-TAX.
           EVALUATE WS-COUNTRY-CD
               WHEN 'US' PERFORM US-TAX-CALC
               WHEN 'UK' PERFORM UK-VAT-CALC
               WHEN 'DE' PERFORM GERMAN-MWST-CALC
               WHEN 'FR' PERFORM FRENCH-TVA-CALC
               *> ... 59 more WHEN clauses
               WHEN OTHER PERFORM DEFAULT-TAX-CALC
           END-EVALUATE.

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

מהו היקף העברת הנתונים עבור כל יישום? הנתונים המשויכים ליישום COBOL מדור קודם מוגדרים בערכי FD ובספרי עותקים שעשויים לצבור מספר גרסאות REDEFINES, שדות COMP-3 הדורשים מיפוי מודע לדיוק ואילוצי תוקף מוטמעים שנלכדו בשמות תנאים בני 88 רמות. העברת נתונים שנמדדה כנגד התיעוד ולא כנגד הסכימה בפועל יוצרת את כשל Gap 3.

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

רשימת בדיקה להחלטות בקשה לצורך רציונליזציה של תיקי M&A

עבור כל בקשה הנכללת בהיקף, נדרשות הראיות הבאות לפני שניתן יהיה לקבל החלטה רציונלית בביטחון:

הערכת לוגיקה עסקית

• האם התפקוד בפועל של האפליקציה אומתה באמצעות ניתוח קוד, ולא רק באמצעות ראיון עם הבעלים?
• האם כל כללי העסק מוטמעים בקוד מתועדים בצורה שקוד תחליף חייב להתאים לה?
• עבור תוכניות COBOL: האם כל ענפי EVALUATE, תנאי IF ומשפטי COMPUTE נרשמו?

הערכת תלות

• האם נמדדה רמת המאוורר (fan-in) מבחינה מבנית (לא הוערכה על ידי בעל האפליקציה)?
• האם כל התלויות של הזנת הנתונים, ברמת JCL, ברמת הקובץ וברמת מסד הנתונים, ממוספרות?
• האם אותרו תלויות CALL דינמיות, ולא רק קצוות גרף קריאות סטטיות?

הערכת העברת נתונים

• האם פריסת הרשומה המלאה חולצה מערכי FD ומחברי COPY?
• האם זוהו כל גרסאות ה-REDEFINES ותועדו התנאים המבחינים שלהן?
• האם כל השדות COMP-3 והבינאריים מופו לסוגי יעד המתאימים לדיוק?

הערכת קוד מת

• האם זוהה קוד מת והוצא מהערכות היקף ההעברה?
• האם החלטות פרישה מאושרות על ידי ניתוח קוד מת (אפס fan-in מנתיבי ביצוע בייצור)?

סיווג סיכונים

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

איך SMART TS XL תומך ברציונליזציה של תיקי השקעות במיזוגים ורכישות

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

יכולת ניתוח הקוד הסטטי מחלצת את מלאי הלוגיקה העסקית מ-COBOL, JCL, Java, Python וכל שפה אחרת בתיקי העבודות של שני הארגונים, ומייצרת תמונה מלאה של מה שכל יישום עושה בפועל, ולא רק מה שהתווית שלו אומרת. עבור תוכניות COBOL כמו דוגמת חישוב המס לעיל, ניתוח זה מונה כל תחום שיפוט, כל תנאי כלל וכל ענף חישוב שאפליקציה חלופית חייבת ליישם כדי להפיק תוצאות שוות ערך.

מיפוי תלות היישומים מספק ניתוח של fan-in ו-fan-out שקובע את סיכון הפרישה ואת רצף הקונסולידציה. עבור תיקי העבודות של שני הארגונים המנותחים בו זמנית, מפת התלות מראה אילו תוכניות הן באמת עצמאיות, אילו משולבות עמוק בתשתית משותפת, ואילו נושאות את התלות הנסתרות במורד הזרם שמהן מורכבים כשלים ב-Gap 2.

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

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

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

עבור ארגונים המבצעים רציונליזציה תחת לחץ של לוחות זמנים, SMART TS XLהניתוח של דוחס את ציר הזמן של הניתוח המבני: ניתן לייצר את מפת התלות המלאה, מלאי הלוגיקה העסקית וניקוד המורכבות עבור תיק עבודות משולב תוך ימים במקום שבועות או חודשים שסקירת קוד ידנית הייתה דורשת. דחיסה זו היא שהופכת את גישת הריצוף של גל 1 / גל 2 / גל 3 לברת-קיימא, ניתן להשלים את הניתוח המבני הממוקד עבור יישומי גל 2 בתוך חלון 90 הימים שציר הזמן מאפשר.

ההחלטה שאתה מקבל טובה רק כמו הראיות שמאחוריה

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

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

רציונליזציה של תיק השקעות שמצליחה אינה המהירה ביותר. היא זו שיודעת מה היא רציונליזציה.