בנינו פותר צוות מהיר יותר לחברות תעופה. הוא פשוט נכשל מהר יותר.
בפעם הראשונה שישבתי במרכז בקרת תפעול של חברת תעופה במהלך מפולת אמיתית, השעה הייתה מעט אחרי 3 לפנות בוקר וסופת חורף סגרה תחנה מרכזית שעות קודם לכן. קיר הווידאו לאורך חזית החדר התמלא באדום — ביטול אחר ביטול — והדבר שאני זוכר יותר מכול הוא שאיש לא השתמש בפותר שיבוץ הצוותים ששווה מיליוני דולרים שחברת התעופה שילמה עבורו. הדיספצ'רים הזיזו את המקלדות שלהם הצידה ועבדו ידנית על צימודי צוות שבורים, על גיליונות אלקטרוניים ולוח מחיק, בדיוק ברגע שבו התוכנה הייתה אמורה להצדיק את קיומה.
התמונה הזו היא מה שהוביל אותנו בסופו של דבר לבנות בינה מלאכותית לשיבוץ צוותי טיסה של חברות תעופה להתאוששות IROPS — אבל לא באופן שציפיתי, ולא לפני שתמכתי בתיקון השגוי וצפיתי בו נכשל. IROPS, אם מעולם לא זכיתם לעונג, היא המילה של הענף עבור תפעול לא סדיר: הסופות, הסגירות, הבלגן המתגלגל כשלוח זמנים מתפרק. זה עולה לתעשיית התעופה בהערכה של 60 מיליארד דולר בשנה, בערך 8% מהכנסות חברות התעופה בעולם, לפי IATA. כאחת מכל חמש טיסות ברחבי העולם מושפעת מכך. והסוד המלוכלך שלמדתי באותו לילה הוא שתוכנת האופטימיזציה המתוחכמת ביותר בתעופה מתוכננת למעשה להיות חסרת תועלת בדיוק במהלך האירועים שעולים הכי הרבה.
הפותר ביצע אופטימיזציה לחברת תעופה שכבר לא הייתה קיימת
כדאי לדעת מה פותרי הצוות הישנים באמת עושים. הם מריצים ייצור עמודות (column generation) — טכניקת אופטימיזציה מסוג branch-and-price שהיא באמת מבריקה במציאת הדרך החוקית הזולה ביותר לאייש לוח זמנים ידוע. המלכוד טמון במילה ידוע. הפותר לוקח תצלום מצב של הרשת, מקפיא את הזמן, ומחשב את שיבוץ הצוות האופטימלי לאותו עולם קפוא. הוא פועל במחזורי אצווה, בדרך כלל כל 30 עד 60 דקות.
במהלך תפעול רגיל, זה בסדר. העולם בקושי זז בין מחזורים. אבל במהלך מפולת, מצב הרשת משתנה כל כמה דקות. צוותים זזים. חיבורים נשברים. מטוסים נתקעים. עד שהפותר מחזיר פתרון, הקלטים שניתנו לו כבר שגויים — כך שהתשובה היא תוכנית מושלמת עבור חברת תעופה שכבר לא קיימת.
התחלתי לקרוא לזה פער האופטימיזציה-ביצוע: המרחק בין העולם שהפותר הניח לבין העולם שקיים בפועל שם בחוץ על המסלול. הפער אינו מזיק במהלך עיכוב מבודד. במהלך מפולת, הוא קטלני, מכיוון שהפותר נבנה עבור יעילות — לוח הזמנים הזול ביותר בעולם ידוע — ומה שאתם זקוקים לו נואשות ב-3 לפנות בוקר הוא חוסן: לוח זמנים שניתן לשרוד איתו בעולם לא ידוע.
החלק האכזרי ביותר בפותר צוות ישן הוא שבמהלך התמוטטות הוא ממשיך לעבוד — ומגיש לך בשלווה תוכנית ללא רבב עבור רשת שהתפרקה בזמן שהוא חישב.
למה לא יכולנו פשוט להפוך את הפותר למהיר יותר?
זה החלק שאני לא גאה בו, וזה החלק שבאמת חשוב.
כשהצוות שלי בחן לראשונה את הבעיה, האבחנה שלנו הייתה האבחנה המהנדסית המובנת מאליה: הפותר איטי מדי. העולם משתנה כל חמש דקות והאופטימייזר לוקח שלושים דקות עד שעה, אז סגרו את הפער — הפכו אותו למהיר יותר. השקענו זמן ממשי בבניית מנוע התאוששות מהיר יותר, בהסתמך על היוריסטיקות זולות יותר כדי לקבל תשובה ישימה בתוך חלון ההחלטה התפעולי במקום להמתין לתשובה אופטימלית מוכחת.
וזה עבד, במובן הצר שהוא החזיר תשובות מהר יותר. ואז בדקנו אותו מול נתוני שיבוש אמיתיים וצפיתי בו מייצר בביטחון תוכניות התאוששות שכבר היו לא תקפות, פשוט מוקדם יותר. בנינו מכונה שביצעה אופטימיזציה לחברת תעופה רפאים במהירות גבוהה יותר.
הטעות הייתה להתייחס למהירות כצוואר הבקבוק. היא לא הייתה. צוואר הבקבוק היה שהקלטים היו בדיה. הפותר — כולל שלנו — זקוק לעובדות מוצקות: "קפטן סמית' נמצא בשער B7 בדנוור." אבל במהלך מפולת, קפטן סמית' עשוי להיות במלון, עשוי להיות בהסעת העובדים, ייתכן ששכר רכב ונמצא באמצע הדרך לקולורדו ספרינגס. המצב הכן של העולם הוא "כנראה בדנוור," ופותר ייצור עמודות אינו יכול לעשות דבר עם כנראה. חידדנו את התשובה לשאלה שהנתונים שלה היו זבל.
הכישלון הזה הוא הסיבה שהמוצר קיים. אם היינו משחררים את הפותר המהיר, היינו מוכרים לחברות תעופה דרך מהירה יותר לעשות את אותה טעות יקרה.
חור הנתונים השחור בשווי 1.2 מיליארד דולר
אם אתם רוצים לראות את הכישלון המדויק הזה בקנה מידה מלא, הביטו במה שקרה ל-Southwest בדצמבר 2022. ההתמוטטות עלתה לחברת התעופה בערך 1.2 מיליארד דולר, ביטלה כ-16,900 טיסות, והותירה תקועים קרוב לשני מיליון נוסעים במהלך חופשות החג.
הסיפור הפופולרי הוא "תוכנה ישנה." הסיפור האמיתי ספציפי יותר ושימושי יותר. מערכת שיבוץ הצוותים של Southwest, SkySolver, נתקלה בפיצוץ קומבינטורי שלא הצליחה לחשב אותו עד הסוף. אבל מתחת לכל זה, חברת התעופה איבדה את המעקב אחר המיקום הפיזי של הטייסים ודיילי האוויר שלה עצמה. הדיווח על מיקום הצוותים התנהל בעיקר דרך טלפונים — צוותים שנתקעו בתחנות משנה והתקשרו למרכז שיבוץ שבו זמני ההמתנה טיפסו לשעות. ההשהיה הזו יצרה את מה שאני חושב עליו כחור שחור של נתונים: המערכת ייצרה לוחות זמנים עבור צוותים שלא היו במקום שבו חשבה שהם נמצאים. היא ביצעה אופטימיזציה לרשת רפאים, ומבנה המסלולים מנקודה-לנקודה משמעותו שלא היו "נקודות התחדשות" במרכזי תעופה שבהן צוותים ומטוסים מתכנסים מחדש באופן טבעי, כך שרדיוס הפגיעה פשוט המשיך להתפשט מתחנה לתחנה.
זו אינה היסטוריה עתיקה שכולם כבר תיקנו מאז. ביולי 2024, מערכת השיבוץ של Spirit יצרה שיבוצים סותרים עבור 43% מצוותי הטיסה הזמינים שלה, אירוע שהוערך ב-50–100 מיליון דולר, מכיוון שלמערכת חסרה הגמישות לשבץ מחדש צוותים בצורה נקייה במהלך השיבוש. הדפוס חוזר על עצמו מכיוון שהארכיטקטורה הבסיסית — לבצע אופטימיזציה לתצלום מצב קפוא, לדרוש קלטים ודאיים — זהה בכל רחבי הענף.
Southwest, לזכותם, הגיבו בכך שהוציאו כסף: כ-1.7 מיליארד דולר על טכנולוגיה בשנת 2024 כחלק מתוכנית רב-שנתית גדולה יותר, הגירה ל-AWS שצמצמה באופן דרמטי את טביעת הרגל של מרכז הנתונים שלהם, ואלגוריתם שיבוץ מהיר יותר בכ-30%. זהו האינסטינקט הנכון. אבל גרסה מהירה יותר של אותה ארכיטקטורה — שהיא המלכודת שכמעט נפלנו לתוכה בעצמנו — סוגרת את פער המהירות בעוד היא מותירה את פער ודאות הנתונים פתוח לרווחה.
מה קורה עכשיו כשעיכוב חוצה את רף שלוש השעות?
לאורך רוב ההיסטוריה של התעופה, התאוששות איטית עלתה לך במוניטין. נוסעים כועסים, כיסוי תקשורתי רע, כמה שוברים. החשבון הזה השתנה ב-28 באוקטובר 2024.
אז נכנס לתוקף כלל ההחזר האוטומטי של משרד התחבורה האמריקאי — דרישת ההחזר האוטומטי הראשונה אי פעם המחייבת. כל עיכוב פנים-ארצי מעל שלוש שעות (שש לטיסות בינלאומיות) מפעיל כעת החזר במזומן, המשולם בתוך שבעה ימי עסקים, מבלי שהנוסע אפילו יבקש. לא שובר. לא הזמנה מחדש. מזומן.
עשו את החשבון עבור מוביל בינוני שמפעיל 300 המראות ביום. ביום גרוע באמת, אם אפילו שישית מהן — 50 טיסות — חורגות מרף שלוש השעות, בערך כרטיס ממוצע של $280 ו-150 נוסעים לטיסה, אתם מסתכלים על בערך 2.1 מיליון דולר של חשיפה להחזרים מחייבים מיום אחד בלבד. התאוששות IROPS איטית נהגה להיות בעיה תדמיתית. עכשיו זה סעיף בדוח שפוגע באותו שבוע.
כעת יש מונה שרץ על כל שעה שבה ההתאוששות שלך מפגרת, ומאז אוקטובר האחרון הוא משלם במזומן, אוטומטית, לכל נוסע שהוא נוגע בו.
זה החלק שמסגר מחדש עבורי את כל השיחה. העלות של פער האופטימיזציה-ביצוע כבר אינה מופשטת. היא מצטברת, בדולרים, מול שעון שהתחיל לתקתק ברגע שהסופה התחילה.
הרחיבו את הפותר, אל תחליפו אותו
הנה ההחלטה שמגדירה את הגישה שלנו, והיא כזו שבמכוון אינה מסעירה: אנחנו לא מחליפים את הפותר שלכם.
הפותרים הקיימים מקודדים עשרות שנים של ידע תחומי ספציפי לחברות תעופה, והתחום סביבם מתגבש, לא קורס. Jeppesen — סטנדרט הענף, עם יותר ממאה לקוחות חברות תעופה — נמכרה על ידי Boeing ל-Thoma Bravo תמורת 10.55 מיליארד דולר באפריל 2025, אחת ממכירות הטכנולוגיה הגדולות ביותר בהיסטוריה של התעופה והחלל, ומאז השיקה את Stratosphere, שכבת בינה מלאכותית לניהול חיזוי שיבושים. פלטפורמת iFlight של IBS Software זוכה בפריסות מודרניות מבוססות-ענן — Korean Air עלתה לאוויר בתחילת 2026, כשגם חברות כמו Aeroitalia וחברות התעופה של Groupe Dubreuil עוברות אליה — נתמכת בהסדר הנדסה משותפת עם AWS. CrewSolver של Optym מספק הפחתה מתועדת של 3–7% בעלות הצוות בצד התכנון.
אף אחד מהם אינו האויב. אבל שימו לב במה כל אחד מהם חזק: אופטימיזציה בשלב התכנון וניתוח חיזוי — העולם הידוע, מחושב להפליא. בעיית ההתאוששות בזמן אמת עם קלט לא ודאי היא הפער שנשאר פתוח. החלפת פלטפורמה מלאה היא גם פרויקט של 12 עד 18 חודשים, ואף מנהל תפעול לא רוצה לעקור את המערכת שעובדת 350 ימים בשנה כדי לתקן את 15 הימים שבהם היא לא. עבור ה-CIO שבאמת חותם על החוזה, החשבון גרוע יותר מהלוח שנה: לעקור מערכת עם עשרות שנים של לוגיקת CBA ספציפית למוביל המקודדת בתוכה — בדיוק ברגע שהבעלות על Jeppesen עצמה זה עתה החליפה ידיים תמורת 10.55 מיליארד דולר ומפת הדרכים ארוכת הטווח שלה היא שאלה פתוחה — היא הימור שרוב ארגוני הטכנולוגיה לא יעשו. לשבת לצד ההתקנה הקיימת, לצרוך את הפידים שלה במקום להחליף את הסכמה שלה, היא האינטגרציה היחידה שהם יאשרו.
אז בנינו מנוע התאוששות IROPS מונע-ML שיושב לצד התקנה קיימת של Jeppesen או IBS ומטפל בדבר שהפותר המרכזי אינו יכול: שיבושים מתגלגלים עם מיקומי צוות לא ודאיים, ניתוח רדיוס פגיעה ברמת הרשת כולה, ותוכניות התאוששות המופקות בדקות במקום 4 עד 12 השעות שהתאוששות ידנית לוקחת בדרך כלל. נתוני מקרה אזוריים מרמזים שאוטומציה יכולה לקצר את זמן ההתאוששות הזה בכ-78%. הנקודה אינה להיות חכם יותר מהמערכת הקיימת. היא להיות שימושי בדיוק בתנאים שעבורם המערכת הקיימת מעולם לא תוכננה.
ללמד מודל לעבוד עם "כנראה בדנוור"
ברגע שהפסקנו לנסות להפוך את הפותר למהיר יותר, בעיית ההנדסה האמיתית התחדדה: לבנות משהו שמשגשג על אי-ודאות במקום להיחנק ממנה.
החלק הראשון הוא מודיעין מיקום צוותים. במקום לדרוש מיקום ודאי, אנו מזינים למודל מיקומים הסתברותיים — ממזגים כל אות בזמן אמת שקיים עם התנהגות היסטורית, כך שהמערכת מסיקה לגבי היכן צוות ככל הנראה נמצא במקום להמתין לשיחת טלפון שתקועה ארבע שעות עמוק בתור המתנה. השינוי היחיד הזה — מ"ודאי או כלום" ל"התפלגות הסתברות" — הוא מה שמאפשר לתוכנית התאוששות לשרוד מגע עם מפולת אמיתית.
החלק השני הוא להתייחס לרשת כאל גרף ולנתח היכן כשלים יתפשטו לפני שהם עושים זאת — רדיוס הפגיעה, ממופה למבנה המסלולים של חברת התעופה הספציפית הזו, כך שתוכלו לראות איזו סגירת תחנה מבטלת בשקט שש טיסות במורד הזרם בעוד שעתיים.
החלק השלישי הוא סימולטור תרחישים, למעשה תאום דיגיטלי של התפעול, כך שצוות תפעול יכול לתרגל תרחיש של סופת חורף מראש ולבחון אסטרטגיות התאוששות כשאין סופה ממשית ואין שעון ממשי. התעופה כבר סומכת על תאומים דיגיטליים היכן שהנתונים עשירים — פלטפורמת AVIATAR של Lufthansa קולטת 23.7 טרה-בייט ביום על פני 34 אינטגרציות של חברות תעופה ומגיעה לדיוק של 93.6% בחיזוי כשלי תחזוקה. תאומי צוות ושיבוץ עדיין בחיתוליהם, וזה בדיוק המקום שבו נמצאת ההזדמנות.
ומה שעובר דרך כל זה הוא מנוע האילוצים. כל המלצה חייבת להיות חוקית תחת כללי העייפות של FAA Part 117 — מגבלות זמן הטיסה של 8 עד 9 שעות, תקופות המשמרת של 9 עד 14 שעות — ותחת חוזה האיגוד המקצועי של חברת התעופה, שלעיתים קרובות הוא יותר מגביל מהתקנה. רוב הספקים מתייחסים לכללים האלה כאל "תצורה." אנחנו מתייחסים לקידוד הסכם העבודה הקיבוצי הספציפי של המוביל, לפי צי ולפי בסיס, כאל הנדסת ליבה, מכיוון שתוכנית התאוששות שמפרה סעיף CBA אינה תוכנית — היא תלונה רשמית.
למה אנחנו פועלים תחילה במצב צל
אנשים בענף הזה צודקים כשהם לא בוטחים בקופסה שחורה שאומרת להם איך להזיז טייסים ב-3 לפנות בוקר. אז אספר לכם על ההתנגדות שאני שומע הכי הרבה, כי היא הייתה לי בעצמי.
סמנכ"ל תפעול אמר לנו בשלב מוקדם, פחות או יותר, שהם בדיוק רכשו רישיון לתוסף שיבושי הבינה המלאכותית מהספק הקיים שלהם ולא הבינו למה הם צריכים אותנו. הוגן. ואז הגיעה הסופה הבאה, התוסף נתן להם תחזיות ולא התאוששות צוות ניתנת לביצוע, והדיספצ'רים חזרו ללוח המחיק. ההבחנה שאותה שיחה לימדה אותי: יש הבדל עצום בין בינה מלאכותית אג'נטית לצ'אט מול נוסעים — מילת הבאזז של מעגל הכנסים של 2026 — לבין בינה מלאכותית שמקבלת החלטות תפעוליות לגבי צוותים ומטוסים. צ'אטבוט שמסדר מחדש נוסע הוא דבר טוב. זו אינה אותה בעיה הנדסית כמו שחזור רשת.
לכן בפעם הראשונה שחברת תעופה כלשהי מריצה את המנוע שלנו, הוא לא נוגע בתפעול. הוא פועל במצב צל: ההמלצה של המודל שלנו יושבת לצד ההחלטה בפועל של הדיספצ'ר האנושי, ואנו מודדים את הפער, יום אחר יום, על השיבושים של חברת התעופה עצמה. אמון אינו נטען במצגת מכירות. הוא נרכש בגיליון השוואה, ללא סיכון תפעולי, עד שצוות התפעול מחליט בעצמו שההמלצות טובות יותר מהלוח המחיק.
אתם לא זוכים בזכות לנתב מחדש את הטייסים של מישהו באמצעות מדד ביצועים. אתם זוכים בה על ידי כך שאתם צודקים, בשקט, לצד אדם, במשך שבועות, לפני שמישהו חייב להאמין לכם.
האמת הכנה היא שצפייה במצב צל היא הרגע שבו הבנתי מה אנחנו באמת מוכרים. לא אופטימייזר. לא מהירות. מכרנו דרך למנהל תפעול להאמין למכונה בלילה הגרוע ביותר של השנה שלו — ואמון חייב להיבנות לפני הסופה, לא במהלכה.
מה 15 הימים באמת שווים
אם אתם מנהלים את התפעול של חברת תעופה בינונית, פותר הצוות שלכם עובד מצוין 350 ימים בשנה. אני לא כאן כדי לטעון אחרת. השאלה היא מה קורה ב-15 הימים שבהם הוא לא — ואלה הימים שמייצרים את הכותרות בשווי מיליארד דולר, את ביקורות ה-43%-מהצוותים-משובצים-לא-נכון, וכעת, מאז אוקטובר האחרון, את החזרי המזומן האוטומטיים הנמדדים לפי השעה.
הטעות שכל הענף ממשיך לעשות — הטעות שאני עשיתי ראשון, עם הפותר המהיר שלי עצמי — היא להתייחס ל-15 הימים האלה כבעיית מהירות שיש לפתור על ידי חישוב חזק יותר. הם לא. הם בעיית ודאות, ואתם לא פותרים בעיית ודאות על ידי דרישה ליותר ודאות מעולם שמתפרק באופן פעיל. אתם פותרים אותה על ידי בניית משהו שמסיק תחת אי-ודאות, מתרגל את האסון לפני שהוא מגיע, ומוכיח את עצמו בצללים לפני שאי פעם בוטחים בו באור. זהו המנוע שבנינו, והוא מתואר במלואו בפתרון הבינה המלאכותית לשיבוץ צוותי טיסה.
אי-שם הלילה יש מרכז בקרת תפעול שבו קיר הווידאו רגוע וירוק, ופותר צוות מזמזם דרך מחזור האצווה שלו בדיוק כפי שתוכנן. העבודה שאנחנו עושים היא עבור הלילה שבו החדר הזה הופך לאדום — כשהטלפונים נסתמים, הצימודים נשברים מהר יותר משמישהו יכול לרשום אותם, ודיספצ'ר מושיט יד ללוח מחיק מכיוון שהוודאות שהתוכנה דורשת עזבה בשקט את הבניין. כל העניין הוא לוודא שבאותו לילה, המכונה עדיין מסיקה בכנות לגבי חברת תעופה שהיא כבר לא יכולה לראות במלואה.
