بنينا برنامج حل أسرع لجدولة أطقم الطيران، ففشل بشكل أسرع فحسب
أول مرة جلست فيها في مركز التحكم بعمليات إحدى شركات الطيران أثناء تسلسل انهياري حقيقي، كانت الساعة تتجاوز الثالثة فجرًا بقليل، وكانت عاصفة شتوية قد أغلقت محطة رئيسية قبل ساعات. جدار الشاشات الممتد على واجهة الغرفة كان يمتلئ باللون الأحمر — إلغاء بعد إلغاء — وأكثر ما أتذكره هو أن لا أحد كان يستخدم برنامج حل جدولة الأطقم الذي كلّف ملايين الدولارات والذي دفعت الشركة ثمنه. كان الموزّعون قد نحّوا لوحات مفاتيحهم جانبًا وعملوا على إصلاح ارتباطات الأطقم المكسورة يدويًا، على جداول بيانات ولوحة بيضاء، في اللحظة ذاتها التي كان يُفترض بالبرنامج أن يُثبت فيها جدواه.
تلك الصورة هي ما قادنا في نهاية المطاف إلى بناء ذكاء اصطناعي لجدولة أطقم الطيران من أجل التعافي من الاضطرابات التشغيلية — لكن ليس بالطريقة التي توقّعتها، وليس قبل أن أراهن على الإصلاح الخاطئ وأشاهده يفشل. الاضطرابات التشغيلية (IROPS)، إن لم تحظَ يومًا بمتعتها، هي مصطلح الصناعة الذي يعني العمليات غير المنتظمة: العواصف والإغلاقات والفوضى المتسلسلة عندما ينهار الجدول الزمني. وهي تكلّف صناعة الطيران ما يُقدَّر بنحو 60 مليار دولار سنويًا، أي ما يقارب 8% من إيرادات شركات الطيران العالمية، وفقًا للاتحاد الدولي للنقل الجوي (IATA). وتتأثر بها نحو رحلة واحدة من كل خمس رحلات حول العالم. والسر القذر الذي تعلّمته تلك الليلة هو أن أكثر برامج التحسين تطورًا في الطيران مصمَّمة عمليًا لتكون عديمة الفائدة أثناء الأحداث ذاتها التي تكلّف أكثر من غيرها.
برنامج الحل كان يُحسّن شركة طيران لم تعد موجودة
من المفيد أن نعرف ما تفعله برامج حل الأطقم القديمة فعليًا. إنها تُشغّل توليد الأعمدة (column generation) — وهي تقنية تحسين قائمة على التفريع والتسعير (branch-and-price) بارعة حقًا في إيجاد أرخص طريقة قانونية لتزويد جدول معروف بالطاقم. والمشكلة تكمن في كلمة معروف. يأخذ برنامج الحل لقطة للشبكة، ويُجمّد الزمن، ويحسب التوزيع الأمثل للأطقم في ذلك العالم المجمّد. وهو يعمل على دورات دُفعية، عادةً كل 30 إلى 60 دقيقة.
أثناء العمليات الطبيعية، لا بأس بذلك. فالعالم لا يكاد يتحرك بين دورة وأخرى. لكن أثناء التسلسل الانهياري، تتغير حالة الشبكة كل بضع دقائق. الأطقم تتنقل. الارتباطات تنكسر. الطائرات تعلق. وبحلول الوقت الذي يُعيد فيه برنامج الحل حلًّا، تكون المدخلات التي أُعطيت له خاطئة بالفعل — فيكون الجواب خطة مثالية لشركة طيران لم تعد موجودة.
بدأت أسمّي هذا فجوة التحسين-التنفيذ: المسافة بين العالم الذي افترضه برنامج الحل والعالم الموجود فعليًا على أرض المطار. الفجوة غير ضارة أثناء تأخير معزول. أما أثناء التسلسل الانهياري فهي قاتلة، لأن برنامج الحل بُني من أجل الكفاءة — أرخص جدول في عالم معروف — وما تحتاجه بشدة في الثالثة فجرًا هو المرونة: جدول قابل للبقاء في عالم مجهول.
أقسى ما في برنامج حل الأطقم القديم أنه أثناء الانهيار يظل يعمل — مسلّمًا إياك بهدوء خطة لا تشوبها شائبة لشبكة تفككت بينما كان يحسب.
لماذا لم نستطع ببساطة جعل برنامج الحل أسرع؟
هذا هو الجزء الذي لا أفخر به، وهو الجزء الذي يهمّ فعلًا.
حين نظر فريقي إلى المشكلة أول مرة، كان تشخيصنا هو تشخيص المهندس البديهي: برنامج الحل بطيء جدًا. العالم يتغير كل خمس دقائق والمُحسِّن يستغرق من ثلاثين دقيقة إلى ساعة، فلنُغلق الفجوة — لنجعله أسرع. أمضينا وقتًا حقيقيًا في بناء محرك تعافٍ أسرع، معتمدين على أساليب تقريبية (heuristics) أرخص للحصول على إجابة قابلة للتنفيذ داخل نافذة القرار التشغيلي بدلًا من انتظار إجابة مثبتة الأمثلية.
وقد نجح، بالمعنى الضيق أنه أعاد الإجابات بسرعة أكبر. ثم اختبرناه على بيانات اضطراب حقيقية وشاهدته يُنتج بثقة خطط تعافٍ كانت باطلة بالفعل، لكن بشكل أسرع فحسب. لقد بنينا آلة تُحسّن شركة طيران وهمية بسرعة أعلى.
كان الخطأ هو معاملة السرعة على أنها عنق الزجاجة. لم تكن كذلك. عنق الزجاجة كان أن المدخلات كانت خيالًا. برنامج الحل — بما فيه برنامجنا — يحتاج إلى حقائق صلبة: "الكابتن سميث عند البوابة B7 في دنفر." لكن أثناء التسلسل الانهياري، قد يكون الكابتن سميث في الفندق، وقد يكون في حافلة نقل الموظفين، وقد يكون قد استأجر سيارة وقطع نصف الطريق إلى كولورادو سبرينغز. الحالة الصادقة للعالم هي "على الأرجح في دنفر"، وبرنامج الحل القائم على توليد الأعمدة لا يستطيع فعل أي شيء بـ على الأرجح. لقد كنا نصقل الإجابة على سؤال بياناته كانت هراءً.
ذلك الفشل هو سبب وجود المنتج. لو أننا أطلقنا برنامج الحل السريع، لكنّا قد بعنا شركات الطيران طريقة أسرع لارتكاب الخطأ المكلف نفسه.
الثقب الأسود للبيانات بقيمة 1.2 مليار دولار
إن أردت أن ترى هذا الفشل بالذات على أكمل وجه، فانظر إلى ما حدث لشركة ساوث ويست في ديسمبر 2022. كلّف الانهيار الشركة نحو 1.2 مليار دولار، وألغى نحو 16,900 رحلة، وترك ما يقارب مليوني مسافر عالقين خلال العطلات.
الرواية الشائعة هي "برمجيات قديمة." أما الرواية الحقيقية فأكثر تحديدًا وأكثر فائدة. نظام جدولة الأطقم لدى ساوث ويست، SkySolver، اصطدم بانفجار توافقي لم يستطع الحساب من خلاله. لكن تحت ذلك، فقدت الشركة تتبّع المكان الذي كان فيه طيّاروها ومضيفوها فعليًا. كان الإبلاغ عن مواقع الأطقم يجري إلى حد كبير عبر الهاتف — أطقم عالقة في محطات خارجية تتصل بمركز جدولة تسلّقت فيه أوقات الانتظار إلى ساعات. أوجد ذلك التأخّر ما أعتبره ثقبًا أسود للبيانات: كان النظام يُولّد جداول لأطقم لم يكونوا حيث ظنّ أنهم كانوا. كان يُحسّن شبكة وهمية، وكانت بنية المسارات من نقطة إلى نقطة تعني عدم وجود "نقاط تجدّد" محورية تلتقي فيها الأطقم والطائرات طبيعيًا من جديد، فظل نطاق الانفجار يتّسع من محطة إلى أخرى.
هذا ليس تاريخًا قديمًا أصلحه الجميع منذئذٍ. في يوليو 2024، أنشأ نظام جدولة شركة سبيريت تعيينات متضاربة لـ 43% من أطقم الطيران المتاحة لديها، وهو حدث قُدِّر بـ 50–100 مليون دولار، لأن النظام كان يفتقر إلى المرونة اللازمة لإعادة تعيين الأطقم بشكل سلس أثناء الاضطراب. ويتكرر النمط لأن البنية الأساسية — تحسين لقطة مجمّدة، والمطالبة بمدخلات مؤكدة — واحدة عبر الصناعة كلها.
ساوث ويست، وهذا يُحسب لها، استجابت بالإنفاق: نحو 1.7 مليار دولار على التقنية في عام 2024 كجزء من برنامج أكبر متعدد السنوات، وترحيل إلى AWS قلّص بصمة مراكز بياناتها بشكل كبير، وخوارزمية جدولة أسرع بنحو 30%. هذا هو الحدس الصحيح. لكن نسخة أسرع من البنية نفسها — وهي الفخّ الذي كدنا نقع فيه نحن أنفسنا — تُغلق فجوة السرعة بينما تترك فجوة يقين البيانات مفتوحة على مصراعيها.
ماذا يحدث الآن حين يتجاوز التأخير ثلاث ساعات؟
على مدى معظم تاريخ الطيران، كان التعافي البطيء يكلّفك حسن النية. مسافرون غاضبون، وتغطية صحفية سيئة، وبعض القسائم. تغيّر هذا الحساب في 28 أكتوبر 2024.
حينها دخلت قاعدة الاسترداد التلقائي الصادرة عن وزارة النقل الأمريكية حيّز التنفيذ — وهي أول اشتراط إلزامي للاسترداد التلقائي على الإطلاق. أي تأخير داخلي يتجاوز ثلاث ساعات (ست ساعات للرحلات الدولية) يُطلِق الآن استردادًا نقديًا، يُدفع خلال سبعة أيام عمل، دون أن يطلبه المسافر حتى. لا قسيمة. لا إعادة حجز. نقدًا.
احسب الأرقام لشركة طيران متوسطة الحجم تُسيّر 300 رحلة مغادرة في اليوم. في يوم سيئ حقًا، إذا تجاوز حتى سُدسها — 50 رحلة — علامة الساعات الثلاث، بمتوسط قيمة تذكرة يبلغ 280 دولارًا و150 مسافرًا في الرحلة، فإنك تنظر إلى نحو 2.1 مليون دولار من التعرّض للاسترداد الإلزامي في يوم واحد. كان التعافي البطيء من الاضطرابات التشغيلية مشكلة سمعة. أما الآن فهو بند محاسبي يضرب في الأسبوع نفسه.
هناك الآن عدّاد يعمل على كل ساعة يتأخر فيها تعافيك، ومنذ أكتوبر الماضي أصبح يدفع نقدًا، تلقائيًا، لكل مسافر يمسّه.
هذا هو الجزء الذي أعاد صياغة الحديث كله بالنسبة لي. لم تعد تكلفة فجوة التحسين-التنفيذ مجرّدة. إنها تتراكم، بالدولارات، مقابل ساعة بدأت في اللحظة التي بدأت فيها العاصفة.
عزّز برنامج الحل، لا تستبدله
إليك القرار الذي يُحدّد نهجنا، وهو قرار غير مثير عن قصد: نحن لا نستبدل برنامج الحل الخاص بك.
تُرمّز برامج الحل القائمة عقودًا من المعرفة المتخصصة الخاصة بشركات الطيران، والمجال المحيط بها يتوحّد لا ينهار. Jeppesen — المعيار الصناعي، وله أكثر من مئة عميل من شركات الطيران — باعته بوينغ لشركة Thoma Bravo مقابل 10.55 مليار دولار في أبريل 2025، في واحدة من أكبر عمليات التخارج التقني في تاريخ صناعة الطيران والفضاء، وأطلقت منذ ذلك الحين Stratosphere، وهي طبقة ذكاء اصطناعي لإدارة الاضطرابات التنبؤية. وتفوز منصة iFlight من IBS Software بعمليات نشر حديثة أصيلة السحابة — انطلقت Korean Air مطلع 2026، مع انتقال شركات مثل Aeroitalia وشركات طيران Groupe Dubreuil إليها أيضًا — مدعومة بترتيب هندسة مشتركة مع AWS. ويقدّم CrewSolver من Optym خفضًا موثّقًا في تكلفة الأطقم بنسبة 3–7% في جانب التخطيط.
لا أحد من هؤلاء هو العدو. لكن لاحظ ما يبرع فيه كلٌّ منهم: تحسين مرحلة التخطيط والتحليلات التنبؤية — العالم المعروف، محسوبًا بشكل جميل. أما مشكلة التعافي الفوري ذات المدخلات غير المؤكدة فهي الفجوة التي تبقى مفتوحة. كما أن الاستبدال الكامل للمنصة مشروع يمتد من 12 إلى 18 شهرًا، ولا يريد أي قائد عمليات اقتلاع النظام الذي يعمل 350 يومًا في السنة لإصلاح الأيام الخمسة عشر التي لا يعمل فيها. أما بالنسبة لمدير المعلومات (CIO) الذي يوقّع العقد فعليًا، فالحساب أسوأ من الروزنامة: اقتلاع نظام تُرمَّز فيه عقود من منطق اتفاقيات المفاوضة الجماعية (CBA) الخاصة بالناقل — في اللحظة ذاتها التي انتقلت فيها ملكية Jeppesen للتوّ مقابل 10.55 مليار دولار وخارطة طريقها بعيدة المدى سؤال مفتوح — رهانٌ لن تقدم عليه معظم المؤسسات التقنية. والجلوس جنبًا إلى جنب مع التثبيت القائم، واستهلاك تدفقاته بدلًا من استبدال مخططه، هو التكامل الوحيد الذي سيوافقون عليه.
لذا بنينا محرك تعافٍ من الاضطرابات التشغيلية مدعومًا بالتعلم الآلي يجلس جنبًا إلى جنب مع تثبيت قائم من Jeppesen أو IBS ويتولى ما لا يستطيع برنامج الحل الأساسي فعله: الاضطرابات المتسلسلة مع مواقع أطقم غير مؤكدة، وتحليل نطاق الانفجار على مستوى الشبكة كلها، وخطط تعافٍ تُنتَج في دقائق بدلًا من الساعات الأربع إلى الاثنتي عشرة التي يستغرقها التعافي اليدوي عادةً. وتشير بيانات حالات إقليمية إلى أن الأتمتة يمكن أن تقلّص زمن التعافي هذا بنحو 78%. الهدف ليس أن نكون أذكى من النظام القائم. بل أن نكون مفيدين في الظروف ذاتها التي لم يُصمَّم لها النظام القائم قط.
تعليم نموذج أن يعمل مع "على الأرجح في دنفر"
بمجرد أن توقّفنا عن محاولة جعل برنامج الحل أسرع، اتضحت مشكلة الهندسة الحقيقية: بناء شيء يزدهر مع عدم اليقين بدلًا من أن يختنق به.
القطعة الأولى هي ذكاء مواقع الأطقم. فبدلًا من المطالبة بموقع مؤكد، نُغذّي النموذج بمواقع احتمالية — دامجين أي إشارات آنية موجودة مع السلوك التاريخي، بحيث يستدل النظام على أين يُرجّح أن يكون الطاقم بدلًا من انتظار مكالمة هاتفية غارقة أربع ساعات في طابور الانتظار. ذلك التحول الواحد — من "مؤكد أو لا شيء" إلى "توزيع احتمالي" — هو ما يسمح لخطة التعافي بالنجاة من التماس مع تسلسل انهياري حقيقي.
القطعة الثانية هي معاملة الشبكة كرسم بياني (graph) وتحليل أين ستنتشر الأعطال قبل أن تنتشر — نطاق الانفجار، مُسقَطًا على بنية مسارات هذه الشركة تحديدًا، بحيث ترى أي إغلاق محطة يُلغي بهدوء ست رحلات لاحقة بعد ساعتين من الآن.
القطعة الثالثة هي محاكي سيناريوهات، وهو عمليًا توأم رقمي للعملية، بحيث يستطيع فريق العمليات التدرّب على سيناريو عاصفة شتوية مسبقًا واختبار استراتيجيات التعافي حين لا توجد عاصفة فعلية ولا ساعة فعلية. الطيران يثق بالفعل بالتوائم الرقمية حيث تكون البيانات غنية — منصة AVIATAR من Lufthansa تستوعب 23.7 تيرابايت يوميًا عبر 34 تكاملًا مع شركات طيران وتبلغ دقة 93.6% في التنبؤ بأعطال الصيانة. أما توائم الأطقم والجدولة فلا تزال ناشئة، وهذا بالضبط حيث تكمن الفرصة.
ويتخلل كل ذلك محرك القيود. كل توصية يجب أن تكون قانونية بموجب قواعد الإجهاد FAA Part 117 — حدود وقت الطيران من 8 إلى 9 ساعات، وفترات العمل من 9 إلى 14 ساعة — وبموجب عقد نقابة شركة الطيران، الذي غالبًا ما يكون أكثر تقييدًا من اللائحة التنظيمية. معظم الموردين يعاملون تلك القواعد على أنها "إعدادات." أما نحن فنعامل ترميز اتفاقية المفاوضة الجماعية المحددة الخاصة بالناقل، بحسب الأسطول وبحسب مقر الإقامة، على أنه هندسة جوهرية، لأن خطة التعافي التي تنتهك بندًا من اتفاقية المفاوضة الجماعية ليست خطة — بل هي تظلّم.
لماذا نعمل في وضع الظل أولًا
أهل هذه الصناعة محقّون في عدم الثقة بصندوق أسود يُملي عليهم كيف يُحرّكون الطيارين في الثالثة فجرًا. لذا سأخبرك بالاعتراض الذي أسمعه أكثر من غيره، لأنه كان لديّ أنا نفسي.
أخبرنا نائب رئيس للعمليات في وقت مبكر، بمعنى ما، أنهم رخّصوا للتوّ إضافة الذكاء الاصطناعي لإدارة الاضطراب من مورّدهم القائم ولم يروا لماذا يحتاجون إلينا. عادل. ثم جاءت العاصفة التالية، وأعطتهم الإضافة تنبؤات لا تعافي أطقم قابلًا للتنفيذ، وعاد الموزّعون إلى اللوحة البيضاء. الفرق الذي علّمني إياه ذلك الحديث: هناك فرق شاسع بين ذكاء اصطناعي وكيلي (agentic AI) للدردشة الموجّهة للمسافرين — الكلمة الرنّانة في دوائر المؤتمرات لعام 2026 — والذكاء الاصطناعي الذي يتخذ قرارات تشغيلية بشأن الأطقم والطائرات. روبوت دردشة يُعيد استيعاب مسافر أمر جيد. لكنه ليس مشكلة الهندسة ذاتها التي هي التعافي من انهيار شبكة.
لهذا السبب، في أول مرة تُشغّل فيها أي شركة طيران محركنا، لا يمسّ العمليات. إنه يعمل في وضع الظل: توصية نموذجنا تجلس بجانب القرار الفعلي للموزّع البشري، ونقيس الفجوة، يومًا بعد يوم، على اضطرابات الشركة نفسها. الثقة لا تُدّعى في عرض مبيعات. بل تُكتسب على ورقة مقارنة، دون أي مخاطرة تشغيلية، إلى أن يقرّر فريق العمليات بنفسه أن التوصيات أفضل من اللوحة البيضاء.
أنت لا تكتسب حق إعادة توجيه طياري أحدهم بمقياس أداء. بل تكتسبه بأن تكون على صواب، بهدوء، بجانب إنسان، لأسابيع، قبل أن يضطر أحد إلى تصديقك.
الحقيقة الصادقة أن مشاهدة وضع الظل هي اللحظة التي فهمت فيها ما كنا نبيعه فعلًا. ليس مُحسِّنًا. ولا سرعة. كنا نبيع وسيلة تجعل قائد العمليات يثق بآلة في أسوأ ليلة في عامه — والثقة يجب أن تُبنى قبل العاصفة، لا أثناءها.
ما تُساويه الأيام الخمسة عشر حقًا
إن كنت تدير عمليات شركة طيران متوسطة الحجم، فإن برنامج حل الأطقم لديك يعمل بشكل جيد 350 يومًا في السنة. لست هنا لأجادل في عكس ذلك. السؤال هو ما يحدث في الأيام الخمسة عشر التي لا يعمل فيها — وهي الأيام التي تُنتج العناوين بمليارات الدولارات، وعمليات التدقيق التي تكشف سوء تعيين 43% من الأطقم، والآن، منذ أكتوبر الماضي، عمليات الاسترداد النقدي التلقائي المحسوبة بالساعة.
الخطأ الذي تظل الصناعة كلها ترتكبه — الخطأ الذي ارتكبته أنا أولًا، ببرنامج حلي الأسرع — هو معاملة تلك الأيام الخمسة عشر كمشكلة سرعة تُحلّ بحساب أشد. إنها ليست كذلك. إنها مشكلة يقين، ولا تحلّ مشكلة يقين بالمطالبة بمزيد من اليقين من عالم يتفكك بنشاط. بل تحلّها ببناء شيء يستدل في ظل عدم اليقين، ويتدرّب على الكارثة قبل وصولها، ويُثبت نفسه في الظلال قبل أن يُوثَق به في النور. ذلك هو المحرك الذي بنيناه، وهو موصوف بالكامل في حل الذكاء الاصطناعي لجدولة أطقم الطيران.
في مكان ما الليلة هناك مركز تحكم بالعمليات حيث جدار الشاشات هادئ وأخضر، وبرنامج حل أطقم يطنّ خلال دورته الدُّفعية تمامًا كما صُمِّم. العمل الذي نقوم به هو من أجل الليلة التي تتحول فيها تلك الغرفة إلى الأحمر — حين تتكدّس المكالمات الهاتفية، وتنكسر ارتباطات الأطقم أسرع مما يستطيع أحد تدوينه، ويمدّ موزّع يده إلى لوحة بيضاء لأن اليقين الذي يطلبه البرنامج غادر المبنى بهدوء. الهدف كله هو التأكد من أن الآلة، في تلك الليلة، لا تزال تستدل بصدق عن شركة طيران لم تعد تراها بالكامل.
