מערכת הליבה כבר לא מפחידה: איך AI הופך את החלפת מערכות הליבה מסיכון להזדמנות

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

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

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

למה כולם פחדו לגעת במערכת הליבה

הפחד לא היה דמיוני. הוא נשען על מספרים:

• המערכות ישנות מאוד. לפי מקינזי, עד 70% מהתוכנה שבשימוש בחברות Fortune 500 פותחה לפני 20 שנה ויותר.
• רוב התקציב הולך לתחזוקה. לפי משרד מבקר המדינה האמריקאי (GAO), כ-80% מהוצאות ה-IT של הממשל האמריקאי, יותר מ-100 מיליארד דולר בשנה, הולכות לתפעול ותחזוקה של מערכות קיימות. מתוך 11 המערכות הקריטיות שהדוח סימן כדחופות להחלפה, 8 כתובות בשפות מיושנות ו-7 עם חולשות אבטחה ידועות.
• הידע נעלם. לפי פוסט של Anthropic, שפת COBOL מטפלת לפי הערכה בכ-95% מעסקאות הכספומט בארצות הברית, אבל מלמדים אותה רק בקומץ אוניברסיטאות, והמפתחים המקוריים פרשו.

מעבר לזה, מי שניסה וכשל הפך לסיפור אזהרה. בנק TSB הבריטי העביר ב-2018 את הלקוחות שלו לפלטפורמה חדשה. הנתונים עברו, אבל המערכת קרסה מיד: מיליוני לקוחות נשארו בלי גישה לחשבונות, חלק מהבעיות נמשכו חודשים, הבנק העריך את העלות בכ-330 מיליון ליש"ט, והרגולטורים בבריטניה הטילו עליו קנס של 48.65 מיליון ליש"ט. ובצד של הפרויקטים שהצליחו, החלפת מערכת הליבה של קומונוולת' בנק האוסטרלי תוכננה לארבע שנים ו-580 מיליון דולר אוסטרלי, והגיעה בסוף לכ-1.1 מיליארד.

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

מה השתנה: AI שמבין קוד ישן

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

• מורגן סטנלי פיתחה כלי פנימי בשם DevGen.AI שעבר על יותר מ-9 מיליון שורות קוד ישן, ולפי הבנק חסך כ-280 אלף שעות עבודה בתוך חצי שנה. הכלי לא משכתב את הקוד בעצמו, אלא מתרגם אותו למסמכי אפיון באנגלית פשוטה, שמהם המפתחים כותבים את הגרסה החדשה.
• אמזון העבירה 30 אלף אפליקציות פנימיות מגרסאות Java ישנות לגרסה 17 בעזרת סוכן AI. החברה מעריכה שהמהלך חסך יותר מ-4,500 שנות עבודה, ו-260 מיליון דולר בשנה בעלויות שרתים, בזכות הביצועים הטובים יותר של הגרסה החדשה.
• Anthropic פרסמה בפברואר 2026 מתודולוגיה להחלפת מערכות COBOL בעזרת Claude Code. ביום הפרסום מניית IBM, שמייצרת את רוב המחשבים המרכזיים שמריצים COBOL, צנחה ב-13%. המשקיעים הבינו מהר מה זה אומר.
• מקינזי מדווחת שבפרויקטים שליוותה, שימוש מתוזמר ב-AI קיצר את לוחות הזמנים של מודרניזציה ב-40% עד 50%, והוריד ב-40% את העלויות שנובעות מחוב טכנולוגי.
• AWS מדווחת ש-BMW קיצרה ב-75% את זמן הבדיקות בפרויקט המודרניזציה של המחשב המרכזי שלה. כדאי לזכור שזה נתון של הספק עצמו.

כשאפילו Word ופוטושופ הופכים לחינמיים, הגבולות נשברו

אם צריך הוכחה לכמה רחוק זה הגיע, היא הגיעה החודש. המפתח ברנדון תומאס, שעומד מאחורי ArtCraft, פרסם בקוד פתוח תחליפים חינמיים לפוטושופ, לפרימייר ולאילוסטרייטור, ואחריהם גם ל-Word, ל-Excel ול-PowerPoint, שכתובים מאפס בשפת Rust בעזרת Claude Opus 5.5. מדובר בגרסאות ראשוניות, ולפי הדיווחים הן מכסות עדיין רק חלק מהיכולות, אבל עצם הקיום שלהן מדהים: תוכנות שאלפי מהנדסים מהטובים בעולם בנו במשך עשורים, משוחזרות בידי מפתח אחד עם AI.

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

הדרך הנכונה: מתודולוגיה בשבעה שלבים

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

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

הסכנות: מה יכול להשתבש

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

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

והבונוס: מערכות בטוחות יותר

יש טענה שכדאי לשמוע: דווקא המערכת הישנה, ש"עובדת ולא נוגעים בה", היא לא פעם החוליה החלשה באבטחה. רשות הסייבר האמריקאית (CISA) מגדירה שימוש בתוכנה שהספק הפסיק לתמוך בה כאחד ה"נהלים הרעים" המסוכנים במיוחד, כי חולשות חדשות פשוט לא מתוקנות. ובדוח של GAO, 7 מתוך 11 המערכות הקריטיות היו עם חולשות ידועות. מערכת שנבנית היום, עם הצפנה, ניהול הרשאות מודרני, ניטור ועדכונים שוטפים, היא בדרך כלל מערכת שקשה יותר לפרוץ אליה, בתנאי שהאבטחה נבנית בה מהיום הראשון.

הדרך הישנה מול הדרך החדשה

מה זה אומר לארגון שלכם

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

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

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

ליאור אברהם, מייסד ארגון ה-AI הישראלי

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