כשאתם מזמינים טיסה בסמארטפון בשנת 2026, הבקשה שלכם עוברת דרך שכבות מרובות של טכנולוגיה מודרנית, אפליקציה סלולרית, שירות אינטרנט, מעבד תשלומים, לפני שהיא מגיעה למערכת ששומרת בפועל את המושב שלכם. מערכת זו, ברוב המקרים, היא תוכנה ששורשיה בשנות ה-1960, הפועלת על תשתית שתעשיית התיירות מנסה להחליף במשך עשרות שנים מבלי שהצליחה לעשות זאת במלואה. סייבר, אמדאוס וטרוולפורט יחד מטפלות כמעט בכל הזמנת טיסה על פני כדור הארץ. ביניהן הן מעבדות מיליארדי עסקאות מדי שנה במאות חברות תעופה, אלפי סוכנויות נסיעות ומלאי בזמן אמת המשתרע על פני מיליוני שילובי מושבים. הוותיק שבהן מקורו במעבד מרכזי של IBM משנת 1964 שזמני ההזמנה נעים בין 90 דקות לשניות בלבד ושינה את התעופה המסחרית לצמיתות.
הסיפור על הסיבה שבגללה מערכות אלו נשארות היכן שהן אינו סיפור של אינרציה ארגונית או שמרנות הנדסית. זהו סיפור על מה שקורה כאשר תוכנה מוטמעת עמוק כל כך בתהליך תפעולי קריטי למשימה, עד כי העלות והסיכון הכרוכים בהחלפתה אינם ניתנים להצדקה על פי ציר זמן ריאלי, וכיצד התעשייה הגיבה על ידי מודרניזציה סביב הליבה במקום ניסיון להחליף אותה. עבור כל מי שעובד על מודרניזציה רחבת היקף של מערכות מדור קודם, מערכות הזמנות חברות תעופה הן מקרה המבחן הברור ביותר שקיים לגבי מה המשמעות של "חשוב מכדי להיכשל" בפועל.
עבוד פנימה. דע את גרף התלות.
SMART TS XL מחלץ כללי עסקיים, מפות תלויות וקוד מת על פני COBOL ותוכניות מדור קודם.
גלו עוד…המקור: מדוע מחשבי מיינפריים ניצחו בבעיית חברות התעופה
סביבת המחקר העסקית החצי-אוטומטית (SABRE) המקורית לא הייתה מוצר, אלא פתרון מותאם אישית למשבר תפעולי ספציפי. בסוף שנות ה-1950, אמריקן איירליינס צמחה מהר יותר ממה שמערכת ההזמנות הידנית שלה יכלה להתמודד איתה. הזמנת מושב דרשה שיחת טלפון, בדיקה ידנית של כרטיס מלאי פיזי, המתנה, שיחה חוזרת ותיעוד נייר, תהליך שאורכו בממוצע 90 דקות להזמנה ולא הצליח להתרחב.
כאשר SABRE נכנסה לפעילות מלאה בשנת 1964, כשהיא נבנתה על שני מחשבי IBM 7090 ומחוברת ל-1,500 מסופים ברחבי ארצות הברית וקנדה, היא יכלה לעבד 7,500 הזמנות בשעה עם שיעורי שגיאות כמעט אפס. לראשונה, חברת תעופה יכלה לתחזק מלאי מושבים בזמן אמת, לאחסן רישומי נוסעים מלאים ולאפשר הזמנות מיידיות בכל רחבי הרשת שלה. זמני ההזמנות ירדו מ-90 דקות לשניות.
הבחירה הארכיטקטונית שאפשרה זאת, עיבוד טרנזקציות מרכזי על גבי חומרת מיינפריים, לא נבחרה מסיבות פילוסופיות. היא נבחרה משום שזו הייתה הארכיטקטורה היחידה הזמינה בשנת 1964 שיכלה לעמוד בדרישות ההשהיה, האמינות והגישה המקבילה של ניהול מלאי בזמן אמת של חברות תעופה. והיא עבדה כל כך טוב שהיא הפכה לתבנית הארכיטקטונית שעליה נבנתה כל מערכת הזמנות חברות תעופה לאחר מכן.
מתקן עיבוד העסקאות (TPF) של יבמ, שתוכנן במקור עבור SABRE, הפך לסביבת התפעול עבור כל הקטגוריה. כמעט כל הבנקים, חברות הביטוח, הקמעונאים וחברות התעופה הגדולות ביותר עדיין משתמשים בו, על פי יבמ. כאשר אמדאוס נוסדה בשנת 1987, היא בנתה על TPF. כאשר גלילאו (כיום Travelport) השיקה את GDS שלה, היא בנתה על TPF. שלושה דורות של מערכות שירות נוסעים קיימים כיום במקביל בתעופה המסחרית, ורבים עדיין פועלים על מחשבי TPF מרכזיים, לא משום שהטכנולוגיה מעולם לא הועמדה בספק, אלא משום שתפוקת העסקאות, האמינות וסבילות הכשל ש-TPF מספקת על חומרת מחשב מרכזי הוכחו כקשים באמת לשכפול בקנה מידה שווה ערך בארכיטקטורות חלופיות.
מה המערכות האלה עושות בפועל בקנה מידה גדול
קנה המידה שבו מערכות הזמנות חברות תעופה פועלות אינו ניתן להבנה אינטואיטיבית מנקודת מבט של הנדסת תוכנה. מערכת הפצה גלובלית מטפלת לא רק בזמינות מושבים, אלא גם בבעיית מלאי קומבינטורית בעלת מורכבות מדהימה.
לטיסה טרנס-אטלנטית אחת יש מאות קטגוריות תעריפים. לכל קטגוריה יש כללים ספציפיים: דרישות רכישה מראש, מינימום שהייה, תאריכי ביטול, דמי שינוי, עצירות ביניים מותרות או לא, הסכמי קוד שייר עם חברות תעופה שותפות. הזמנה הכוללת שתי חברות תעופה, חיבור וטיסה הלוך ושוב יוצרת מטריצה של אלפי שילובי תעריפים תקפים שיש לבדוק, לתמחר ולהחזיק מול מלאי בזמן אמת לפני שמתקבלת תגובה, בדרך כלל תוך פחות משנייה.
בתקופות שיא בהזמנות, סייבר ואמדאוס מעבדות יחד עשרות אלפי עסקאות בשנייה. לא לדקה. בשנייה. כל עסקה כרוכה בבדיקת מלאי בזמן אמת, הערכת כללי תעריפים, יצירה או שינוי של רשומת PNR (רשומת שם נוסע), ותיאום עם בקרת יציאות, מערכות הנוסע המתמיד ומערכות שירותים נלווים. זמן התגובה המובטח נמדד במילישניות, מכיוון שסוכן נסיעות או מנוע הזמנות שמחכים יותר מכמה שניות לבדיקת תעריף יסתיים בזמן וינסו שוב או ינטשו את העסקה.
TPF בחומרת מיינפריים מספק תפוקה זו עם שיעור כשל שאנשי IT מתעשיות אחרות מתקשים להאמין. עמידות התקלות של המיינפריים, המעבדים העודפים, הרכיבים הניתנים להחלפה חמה ועשרות שנים של קוד מערכת הפעלה קשוח, מייצרים זמינות של חמש-תשע כפרמטר תפעולי סטנדרטי, ולא כיעד שאפתני. שכפול זה בעלות שווה ערך בתשתית ענן היה האתגר הטכני המרכזי של כל תוכנית מודרניזציה של IT של תעופה שנוסתה מאז שנות ה-1990.
ניסיונות המודרניזציה: מה באמת מצאו התוכניות בנות העשור
ההיסטוריה של מודרניזציה של מערכות הזמנות חברות תעופה היא היסטוריה של תוכניות שמטרתן להחליף את הליבה, והגיעו, שנים לאחר מכן, למערכת היברידית שעטפה את הליבה.
פרויקט Jetstream של אמריקן איירליינס, שהושק בשנות ה-2000 במטרה מפורשת להחליף את מערכת ה-PSS המרכזית של סייבר, הסתיים באימוץ מוצר סייבר חדש במקום בניית מערכת חלופית. ההנחה הראשונית של בנייה לעומת קנייה, שבניית מערכת חלופית באופן עצמאי תייצר מערכת טובה יותר מהר יותר, נתקלה באותה מציאות שבה נתקלת כמעט כל תוכנית החלפה גדולה מדור קודם: המערכת הקיימת הכילה דרישות שאף אחד לא ידע עליהן עד שהמערכת החלופית לא עמדה בהן.
אנחנו צריכים להיכנס עמוק יותר לתוך המערכת, לשנות את מנוע הליבה ולנתק את הכללים כדי שנוכל לשנות אותם במהירות. הצהרה זו, מצד הנהלת ה-IT של אמריקן איירליינס במהלך תוכנית Jetstream, מתארת את הבעיה במדויק. הכללים המוטמעים במערכת הישנה, לוגיקת בניית התעריפים, יישום הסכמי קוד-שיתוף, חישובי תאימות רגולטורית, אינטגרציות ניהול הכנסות, הצטברו במשך עשרות שנים של שינוי עסקי ולא תועדו בשום צורה שאפשרה לחלץ אותם מבלי להפעיל את המערכת הקיימת ולצפות בהתנהגותה.
תוכנית המודרניזציה של סייבר, שהחלה ברצינות בשנות ה-2010, ארכה יותר מעשור ועלתה מיליארדי דולרים כדי להעביר את רוב הקוד שלה מתשתיות המיינפריים המקומיות. נכון לשנת 2019, כ-11 אחוזים מהקוד של סייבר עדיין רץ במרכזי נתונים מקומיים, כאשר השאר הועבר. בפברואר 2026, סייבר חידשה את הסכם ה-PSS ארוך הטווח שלה עם WestJet, והדגימה שגם לאחר עשור של מאמצי מודרניזציה ומיליארדי השקעות, ה-PSS נותר הבסיס המסחרי של העסק.
אמדאוס השיגה הוצאה משימוש מלאה יותר של מחשבי המיינפריים, והגיעה לאבן דרך של הוצאת המחשבים המרכזיים האחרונים שלה משימוש לטובת תשתית ענן. אך הגישה של אמדאוס, שהחליפה הדרגתית של רכיבים פונקציונליים תוך שמירה על מודל הנתונים המרכזי וארכיטקטורת העסקאות, שימרה ביעילות את ההחלטות הארכיטקטוניות שמקורן במיינפריים גם כאשר החומרה השתנתה. סמנטיקה של העסקאות, מבנה ה-PNR, לוגיקת ניהול המלאי: אלה עברו לתשתית מודרנית תוך שמירה על העיצוב הבסיסי שלהם.
למה החלפה קשה יותר ממה שזה נראה: המורכבות הנסתרת
ההסבר הסטנדרטי מדוע מערכות הזמנות חברות תעופה ממשיכות להתקיים על גבי מחשבים מרכזיים הוא עלות וסיכון. שניהם אמיתיים. אך הם תסמינים של מציאות טכנית עמוקה יותר שכדאי להבין במדויק, משום שהיא חלה על כל תוכנית מודרניזציה של מערכות מדור קודם קריטיות למשימה.
כללי עסקים שקיימים רק בקוד. הלוגיקה של בניית תעריפים במערכת הפצה עולמית מייצגת עשרות שנים של דרישות רגולטוריות, הסכמי חברות תעופה דו-צדדיים, תיקוני תקני IATA ושינויים בכללי עסקים, שאף אחד מהם אינו מתועד בצורה כלשהי שאינה תלויה בקוד המיישם אותם. המפרט הוא היישום. החלפת היישום ללא המפרט פירושה התבוננות ממצה מספיק בהתנהגות המערכת הקיימת כדי לשחזר את מה שהמפרט היה אומר, תהליך שלוקח שנים ולעולם אינו שלם, מכיוון שכיסוי התצפיות לעולם אינו יכול להיות מקיף מספיק כדי לתפוס כל מקרה קצה.
סמנטיקה של עסקאות שארכיטקטורות מודרניות מתקשות לשכפל. TPF מספק עיבוד עסקאות סינכרוני ואטומי עם עקביות מובטחת על פני כל ה-PNR, הזמנה למושב, עדכון רישום נוסעים, אישור תשלום ורישום אישור, כולם מבוצעים כיחידה אטומית אחת או לא מבוצעים כלל. שכפול זה על ארכיטקטורות מיקרו-שירותים מבוזרות דורש תזמור זהיר, פיצוי על עסקאות וניהול נעילה מבוזר, שהוא גם מורכב וגם איטי יותר באופן פוטנציאלי מהמקבילה הסינכרונית של מערכת המרכזית. הניסיון של תעשיית התעופה הוא ש"עקביות בסופו של דבר" אינה מאפיין נסבל עבור מלאי מושבים, טיסה שנמכרה יתר על המידה היא כשל קונקרטי וקטסטרופלי מבחינה תפעולית, לא חוסר עקביות זמני שיש לפתור בהמשך.
משטח האינטגרציה. מערכת בקרת יציאה (PSS) בוגרת של חברת תעופה מחוברת למאות מערכות חיצוניות: בקרת יציאות, ניהול הכנסות, נוסעים מתמידים, מערכות שדה תעופה, חיבורי GDS של צד שלישי, שותפי קוד-שיתוף, דיווח רגולטורי ועוד. לכל חיבור יש חוזי ממשק ספציפיים, פורמטי הודעות, דרישות תזמון, התנהגויות טיפול בשגיאות, שהמערכת הקיימת יישמה ושסביבם נבנתה כל מערכת תלויה. החלפת מערכת בקרת היציאה (PSS) דורשת תחזוקה בו זמנית של כל חוזי הממשק הקיימים (מה שמגביל את הארכיטקטורה החלופית) או תיאום שינויים עם כל מערכת תלויה (מה שמרחיב את ההיקף מעבר למה שכל תוכנית בודדת יכולה לנהל).
בעיית הנתונים בזמן אמת. הזמנות טיסה הן נתונים בזמן אמת, הזמנות שבוצעו חודשים מראש וחייבות להישמר בדיוק כפי שהוזמנו. אין נקודת מעבר נקייה שבה ניתן להשאיר את נתוני המערכת הישנה. ההעברה חייבת להעביר כל PNR בזמן אמת מהמערכת הישנה למערכת החדשה, כאשר כל כלל, תעריף, הגבלה ושירות נלווה נלווים תקינים. העברת PNR בקנה מידה עולמי, עם אפס אובדן נתונים והבטחת התנהגות זהה, הוכחה כאחת הבעיות הטכניות הקשות ביותר במודרניזציה של ארגונים.
התגובה האדריכלית: מודרניזציה סביב הליבה
הגישה שהצליחה בפועל, באמדאוס, בסייבר, בחברות תעופה בודדות, אינה החלפה אלא עטיפה אסטרטגית והפקעה הדרגתית.
עטיפת API חושפת את פונקציות ההזמנה המרכזיות כ-API מודרניים של REST או SOAP, מה שמאפשר ליישומים חדשים לתקשר עם המערכת הישנה דרך ממשק מודרני מבלי לגעת בלוגיקת העסקאות המרכזית. חברות תעופה בנו אפליקציות מובייל, מנועי הזמנות באינטרנט וכלי שירות לקוחות על גבי שכבות API, אשר מתרגמות בקשות מודרניות לקריאות עסקאות TPF ומחזירות תגובות מובנות. מסוף המסך הירוק מוחלף בממשק משתמש גרפי מודרני; עיבוד העסקאות הבסיסי נותר ללא שינוי.
איור חונק עבור פונקציות שאינן ליבה. פונקציות הסמוכות לליבה, ניהול הכנסות, ניהול תוכניות נאמנות, דיווח וניתוח, ותזמון צוות, מופקות אחת בכל פעם ומוטמעות מחדש על תשתית מודרנית. כל חילוץ מפחית את טביעת הרגל של המערכת הישנה מבלי לגעת בליבת העסקאות בעלת הסיכון הגבוה ביותר. במשך עשור של חילוץ הדרגתי, תפקידה של המערכת הישנה מצטמצם מפלטפורמת יישומים מקיפה למנוע עסקאות ממוקד.
תשתית ענן עם ארכיטקטורה משומרת. הוצאת המחשבים המרכזיים של אמדאוס מהמחשבים העבירה עומסי עבודה לתשתית ענן תוך שמירה על ארכיטקטורת העסקאות שמקורה במחשב המרכזי. החומרה השתנתה; עיצוב התוכנה, מודל הנתונים, סמנטיקת העסקאות, מבנה ה-PNR, שימרו את ההחלטות הארכיטקטוניות שהוכחו כנכונות במשך עשרות שנים.
ניהול הצעות והזמנות חדש לצד מערכת PNR מדור קודם. תקן IATA ONE Order, המחליף רשומות מבוססות PNR במודל ניהול הזמנות מודרני, מיושם על ידי חברות תעופה כשכבה לצד המערכת הקיימת מבוססת PNR. טכנולוגיות הדור הבא של הצעות והזמנות של Sabre, שאליה התייחסו בחידוש WestJet בשנת 2026, מציבות זאת כנתיב קדימה, לא תחליף ל-PSS, אלא תוספת של שכבה מסחרית מודרנית שבסופו של דבר תגדל ותטפל בחלק הולך וגדל של הזמנות בעוד שליבת ה-PNR מטפלת ביתר.
מה המשמעות של זה עבור כל מודרניזציה של מבנים מדור קודם קריטיים למשימה
סיפור מערכת ההזמנות של חברות תעופה אינו ייחודי לתעופה. זוהי הדוגמה הבולטת ביותר לדפוס המופיע במערכות ליבה בנקאיות, ניהול פוליסות ביטוח, חיוב טלקומוניקציה ועיבוד הטבות ממשלתיות: תוכנה שהופכת למפרט הסמכותי של כללי עסקים, משמשת כמרכז אינטגרציה לעשרות מערכות תלויות, ופועלת בקנה מידה ובדרישות אמינות שהופכות את החלפת המפץ הגדול לבלתי אפשרית באמת.
הלקחים עקביים בכל התעשיות:
חילוץ כללי עסקיים מהקוד, לפני תחילת כל מודרניזציה, אינו אופציונלי. תוכניות COBOL ו-TPF המיישמות בניית תעריפים, לוגיקת הסכמי קוד-שיתוף וכללי תאימות רגולטוריים הן התיעוד היחיד ששרד של כללים אלה. מודרניזציה שאינה מחלצת ומאמתת תחילה לוגיקה זו אינה יכולה לייצר תחליף שמתנהג נכון בכל המקרים, מכיוון שאינה יכולה לדעת את כל המקרים מבלי לנתח את כל הקוד.
מפת התלות קובעת את רצף המעבר. אף חברת תעופה לא החליפה בהצלחה את מערכת ה-PSS שלה על ידי התחלה עם הרכיב הקריטי והמשולב ביותר. כל מודרניזציה מוצלחת התחילה בקצוות, במערכות הדיווח, בשירותים הנלווים, בפונקציות המנהליות הלא קריטיות, ועבדה פנימה בהדרגה. רצף זה נגזר מגרף התלות: אילו רכיבים בעלי התלות הנכנסות הנמוכות ביותר הם הבטוחים ביותר לטפל בהם תחילה.
אימות תפעולי בכל שלב אינו נתון למשא ומתן. גישת האימות הדו-רציף, הפעלת המערכת החדשה במקביל לישנה, השוואת תפוקות ואימות שקילות לפני העברת כל תעבורה, היא הגישה היחידה שעומדת בדרישות האמינות של מערכות בהן לכשלים יש השלכות פיזיות, פיננסיות ורגולטוריות.
איך SMART TS XL חל על ניתוח מדור קודם של חברות תעופה סמוכים
חברות תעופה המפעילות את Sabre או Amadeus PSS לצד תוכניות COBOL משלהן, מערכות חישוב תעריפים, חשבונאות הכנסות, חישוב נקודות נאמנות ודיווח רגולטורי, ניצבות בפני אותו אתגר אנליטי שכל תוכנית מודרניזציה של מיינפריים ארגוניים מתמודדת איתו: הבנת מה הקוד מכיל בפועל לפני שמחליטים מה לעשות איתו.
SMART TS XL"S ניתוח קוד סטטי מחלץ את לוגיקת הכללים העסקיים המוטמעת בתוכניות COBOL, כללי אימות התעריפים, חישובי חשבונאות ההכנסות, לוגיקת הזכאות לרמת הנאמנות, שאינה קיימת בשום מקום מלבד בקוד התוכנית. עבור חברות תעופה המתכננות לחדש מערכות סמוכות מבלי לגעת בליבת ה-PSS, חילוץ זה מייצר את המפרט שההחלפה חייבת להתאים לו.
מיפוי תלות האפליקציה בונה את גרף התלות שקובע את רצף ההגירה: אילו תוכניות בצד חברת התעופה תלויות באילו הזנות נתונים מה-PSS, אילו תוכניות דיווח תלויות באילו פלטי COBOL, אילו מערכות במורד הזרם יש לעדכן כאשר רכיב כלשהו משתנה. גרף התלות הוא מה שמאפשר מודרניזציה הדרגתית ובטוחה, אותה גישה בה השתמשו Sabre ו-Amadeus עבור מערכות הליבה, כשהיא מיושמת על הקוד בצד חברת התעופה המקיף אותן.
יכולת ניתוח ההשפעה עונה על השאלה שלפני כל החלטה בנושא מודרניזציה: אם תוכנית זו תשתנה, מה עוד יושפע? עבור מערכות תעופה שבהן שינוי חישוב בתוכנית חשבונאות הכנסות עשוי להשפיע בו זמנית על דיווח רגולטורי, יישוב שותפים ואיחוד פיננסי, הכרת היקף ההשפעה לפני ביצוע כל שינוי היא תנאי מוקדם לבקרת שינויים העומדת בדרישות האמינות של חברת התעופה.
ניתוח המודרניזציה של קוד מדור קודם מספק את המלאי המלא שלפני המודרניזציה: כל תוכנית בהיקפה, מורכבותה, התלות שלה, אחוז הקוד המת שלה וסיווג סיכוני ההגירה שלה. הלקח של כל תוכנית מודרניזציה של חברת תעופה - להתחיל בקצוות, לעבוד פנימה, לאמת בכל שלב - דורש לדעת היכן נמצאים הקצוות ואיך נראה מבנה התלות. ידע זה נובע מניתוח מבני של הקוד בפועל, ולא מתיעוד שנכתב לפני שהקוד התפתח ממנו.
השכבות הגיאולוגיות של תוכנה קריטית למשימה
כשאתם מזמינים טיסה בסמארטפון בשנת 2026, אתם נוגעים בתוכנה עם מספר רבדים גיאולוגיים נפרדים. הממשק המודרני על פני השטח. שכבת ה-API שמתחתיה. מנוע העסקאות PSS שמתחתיה, הפועל על תשתית שהשתנתה באופן מהותי מאז שנות ה-1960 אך שומרת על סמנטיקה של עסקאות ומודלים של נתונים שהיו נכונים כשהם תוכננו והוכחו כאמינים מכדי לנטוש אותם.
מערכת ההזמנות של חברות תעופה אינה כישלון של מודרניזציה. היא תוצאה של שישה עשורים של החלטות רציונליות של מהנדסים ומנהלים שהבינו, בכל פעם שהוצעה חלופה, שהסיכון לטעות עולה על העלות של שימור מה שעבד. המערכות ששורדות כל כך הרבה זמן עושות זאת משום שהן מרוויחות את זה, עסקה אחר עסקה, טיסה אחר טיסה, עונת הזמנות אחר עונת הזמנות.
הלקח המעשי לכל צוות מודרניזציה אינו שאין להחליף מערכות ישנות לעולם. אלא שההחלטה להחליף אותן צריכה להתקבל עם ידע מלא של מה שהן מכילות, מה תלוי בהן, ומהו היקף השינוי המלא בפועל, ולא עם הערכות אופטימיות שנעשו לפני שנמדדה המורכבות. תעשיית התעופה למדה זאת בדרך היקרה. כלי הניתוח המייצרים ידע מבני מלא לפני שנכתבת השורה הראשונה של קוד חדש הם אלה שמאפשרים ללמוד אותו בדרך הזולה יותר.
