יישומי ליבה עסקיים

החלפה. מודרניזציה. אינטגרציה. הגירה.

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

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

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

להתחיל מהעסק שהפלטפורמה אמורה לשרת

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

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

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

להבין מה קיים לפני שמחליטים מה יחליף אותו

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

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

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

למפות את המערכת האקולוגית סביב הליבה

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

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

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

להחליף, למדרן או לפתח בהדרגה?

זו ההחלטה שלמענה קיים הדף הזה, ויש לה שלוש תשובות כנות ולא אחת אופנתית:

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

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

איך ההחלטה מתקבלת בפועל

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

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

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

לתרגם צרכים עסקיים לדרישות שאפשר לבחור לפיהן

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

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

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

הדרישות הלא פונקציונליות קובעות איך זה מתנהג בייצור

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

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

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

לבחור את הפלטפורמה — לא את מצגת המכירות הטובה ביותר

בחירה היא דיסציפלינה, ואיכות ההדגמה היא ראיה חלשה. VODIS יכולה לתמוך ב:

• סריקת שוק, רשימה ארוכה ורשימה קצרה
• הכנת RFI ו־RFP וניקוד מובנה
• שאלוני ספקים ומסגרת הערכה
• תרחישי הדגמה הבנויים על המקרים העסקיים של הארגון עצמו
• תרחישי הוכחת היתכנות
• גישה לבדיקת ממליצים ששואלת שאלות מועילות
• סקירת ארכיטקטורה ובדיקת נאותות טכנית
• השוואה מסחרית וניתוח עלות כוללת (TCO)

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

הערכה בלתי תלויה בספקים

ההערכה מביטה מעבר לרשימת הפיצ’רים, אל מה שיקבע את עשר השנים הבאות:

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

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

טרנספורמציה של מערכות ליבה בנקאיות

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

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

לא נטען לכיסוי כברירת מחדל של כל מוצר בנקאי או כל תחום שיפוט; ההיקף נקבע לכל התקשרות. כהמחשה של השוק ולא כרשימה קצרה, הנוף הרלוונטי כולל פלטפורמות ותיקות כגון Temenos Transact, Oracle FLEXCUBE, Infosys Finacle ו־TCS BaNCS לצד שחקנים שנולדו בענן כגון Mambu ו־Thought Machine Vault Core. שמות אלה הם דוגמאות בלבד: הם אינם מדורגים, אינם מומלצים, ול-VODIS אין כל שיוך, שותפות או יחסי שיווק מחדש עם מי מהם. הרשימה הקצרה המתאימה תלויה בדרישות העסקיות, הארכיטקטוניות, הרגולטוריות, התפעוליות וההגירה של הארגון — ולכן דף זה אינו כולל שום דירוג ספקים ואינו מצטט שום עמדה של חברת ניתוח.

מעבר למערכות ליבה בנקאיות

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

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

היכן שההמחשה מסייעת, הנוף הארגוני כולל פלטפורמות כגון SAP S/4HANA, Oracle Fusion Cloud ERP ו־Microsoft Dynamics 365 בתחום ה־ERP והכספים, ו־Salesforce ו־Microsoft Dynamics 365 בתחום ה־CRM — גם כאן כדוגמאות שוק, בלי להביע העדפה ובלי לטעון ליכולת יישום עבור מוצר נקוב כלשהו. לא נרמז על מומחיות בכל מוצר בשוק, והיכן שקטגוריה מוזכרת כרלוונטית היא מוזכרת כקטגוריה ולא כיכולת שכבר הוכחה.

לבחור את הארכיטקטורה ומודל האירוח יחד עם הפלטפורמה

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

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

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

לבחור את הפתרון — ואז להפוך את החוזה לבר-יישום

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

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

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

מוכנות ליישום לפני יום ראשון

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

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

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

הגירה היא תוכנית, לא העתקת נתונים

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

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

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

הליבה היא חלק ממערכת אקולוגית

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

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

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

בדיקות, מעבר לייצור וייצוב

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

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

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

כאשר החלפת הפלטפורמה אינה האפשרות היחידה

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

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

הדבר חשוב במיוחד במערכות ליבה ותיקות, שבהן כללים קריטיים שורדים לעתים קרובות רק בקוד, בהגדרות, בעיבודי אצווה, בפרוצדורות מאוחסנות, בנהלים תפעוליים ובזיכרונם של מעטים. בינה מלאכותית יכולה לסייע לחשוף את הכללים האלה; מומחי העסק והתחום חייבים לאמת אותם. לא נטען להבנה אוטומטית מושלמת, וזו הנדסה בסיוע בינה מלאכותית ולא המרה אוטומטית של מערכות. היכן שקוד המקור או הנתונים רגישים, אפשר לתכנן את העבודה סביב בינה מלאכותית ארגונית מאושרת, ענן מבוקר, סביבות פרטיות או הרצת מודלים מקומית, בכפוף למדיניות האבטחה של הלקוח, לסיווג הנתונים ולארכיטקטורה — אם כי לא כל פרויקט משתמש בבינה מלאכותית פרטית או זקוק לה. מסלול זה מתחבר באופן טבעי ל־Legacy Core Modernisation, שם ההבנה העמוקה של יישום קריטי קיים היא הנושא עצמו, ול-Product Innovation & Application Development, שם נבנים רכיבים חדשים באמת.

האחריות האנושית אינה עוברת

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

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

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

איך VODIS עובדת, ומה אתם עשויים לקבל

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

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

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

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

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