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

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

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

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

למה החדר שותק: האנטומיה של שנאת הסיכון הבנקאית

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

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

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

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

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

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

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

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

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

חשוב להדגיש: מודל השותף המשלים אינו הצהרת כוונות בלבד. הוא צריך להיות מעוגן בפועל בתשתית הטכנית ובתהליכי העבודה. הכלי חייב לפעול בסביבת רשת סגורה, ללא גישה חופשית לאינטרנט, עם לוגים מלאים של כל פעולה, ועם מנגנון שמחייב אישור אנושי מפורש (שלב שנקרא לעיתים "Human in the Loop") לפני כל commit לסביבת קוד משותפת. כשמהנדס רואה שהמערכת בנויה כך שהוא, ורק הוא, מחזיק בזכות ההחלטה הסופית, החשד מתחיל להתמוסס, לא בגלל הבטחה מילולית, אלא בגלל עדות מוחשית.

מקרה בוחן: כיצד בנק גדול קיצר 40% מזמן ניתוח התלויות

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

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

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

ניהול השיח הראשון: מילים שבונות אמון מול מילים שהורסות אותו

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

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

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

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

הדגמה מעשית: מסביבת ארגז חול לתוכנית קובול אמיתית

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

התהליך המומלץ נראה כך:

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

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

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

מה קורה בחדר של שרון עכשיו

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

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

אמנת עבודה: הבסיס לכל מה שיבוא אחרי

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

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

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

צ'ק ליסט לפגישת הפתיחה של הסקוואד

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

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

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