14 ثانية لكل تغيير بوابة
لماذا تراجعت كل شركة طيران كبرى حاولت استبدال Oracle Forms في مركز عملياتها عن البديل؟ تُشغّل شركة طيران أوروبية رائدة من بين أكبر خمس شركات 96 شاشة Forms في مركز التحكم في عملياتها وتُكمل إعادة تعيينات البوابات في 14 ثانية، من ضغطة المفتاح إلى النشر. ثلاثة أنظمة بديلة منذ عام 2018. لم يصل أي منها إلى الرقم. كلها سُحبت بهدوء.
هذه هي مفارقة تحديث شركات الطيران. الشاشات الخضراء قبيحة. وهي أيضاً أسرع من أي شيء تقريباً استبدلها.
لماذا فازت Forms بمركز العمليات
عمليات الطيران هي إدخال بيانات مكثف تحت ضغط الوقت. يقوم مُنسّق ينسّق تحويل رحلة بتحديث الطاقم والطائرة والبوابة والتموين والوقود في أقل من دقيقة. صُمم Oracle Forms لهذا بالضبط: يعمل باستخدام لوحة المفاتيح أولاً، مع فهرسة التبويبات، والتحقق من جانب الخادم، وصفر استخدام للفأرة.
عندما حاولت شركات الطيران استبدالها ببوابات الويب في العقد الثاني من الألفية الثالثة، ارتفع زمن الاستجابة من 80 مللي ثانية إلى 900. حلّت أهداف النقر محل اختصارات لوحة المفاتيح. فقد المتحكمون الذين حفظوا مفاتيح الوظائف لمدة 15 عاماً 30% من إنتاجيتهم في الأسبوع الأول. ماتت المشاريع ليس لأن التكنولوجيا كانت خاطئة، بل لأن نموذج التفاعل كان كذلك.
ما يوجد تحت الغطاء
يُشغّل مُشغّل طائرات ضيقة البدن نموذجي من 60 إلى 150 شاشة Forms تتعلق بالعمليات. اقتران الطواقم، الامتثال لـ FDP بموجب FAA Part 117 أو EASA FTL، توجيه الطائرات، تتبع MEL — معظمها يعيش في حزم PL/SQL مُوسَّعة باستمرار منذ أواخر التسعينيات. راجعنا وحدة جدولة طاقم إحدى شركات الطيران: 2,340 مُشغّلاً، 88 منها يُرمّز بنود اتفاقيات نقابية من سبعة عقود عمل مختلفة. تقاعد مؤلفوها بين عامَي 2019 و2023.
يتطلب كل من EASA Part-145 وFAA Part 43 سجلات صيانة قابلة للتتبع لكل إجراء على طائرة. سجل الحقيقة في معظم شركات الطيران القديمة هو شاشة Forms تكتب إلى مخطط لم يمسه أحد منذ عقد. المخاطر التنظيمية ليست افتراضية — رأينا توجيهَين صلاحية للطيران في السنوات الثلاث الماضية يُشيران إلى تتبع الصيانة المعتمد على البرمجيات كمجال مثير للقلق.
لماذا تتعثر عمليات الترحيل إلى IFS وAMOS
أنفقت شركات الطيران مئات الملايين لنقل الصيانة والعمليات إلى IFS أو AMOS أو Sabre. تعمل البدائل للوظائف الرئيسية. لكنها لا تغطي تقريباً أبداً الشاشات الـ 40 أو 50 الحافة من Forms التي تتعامل مع أمتعة النقل بين شركات الطيران، أو استرداد العمليات غير المنتظمة، أو عقود المناولة الأرضية المحددة.
تبقى تلك الشاشات. وينتهي الأمر بشركة الطيران إلى تشغيل النظام الجديد و Oracle Forms بالتوازي، بشكل دائم. نسمي هذا ترحيل الـ 90%. إنه الأسوأ في العالمَين.
البديل القائم على الاستخراج
المسار الأرخص يعامل مخزون Forms كمصدر للحقيقة، لا كمشكلة للتخلص منها. يُحلل الاستخراج الآلي كل ملف .fmb إلى واصف JSON يلتقط الكتل والمُشغّلات ومنطق التحقق وارتباطات البيانات. تحلّ واجهات TypeScript محل وقت تشغيل Forms مع الحفاظ على نموذج التفاعل القائم على لوحة المفاتيح.
يحافظ المتحكمون على 14 ثانية الخاصة بهم. تحصل شركة الطيران على نظام يعمل في متصفح، ويشحن على الأجهزة المحمولة، ويتكامل مع واجهات برمجة التطبيقات الحديثة. يبقى منطق عقود النقابات سليماً لأن الواصف يلتقطه حرفياً.
الفوائد من الدرجة الثانية أهم من الشاشات نفسها. تبثّ طبقة عمليات TypeScript الأحداث إلى Kafka، وتُغذي نماذج تعلّم الآلة للتنبؤ بالتأخير، وتكشف REST APIs لشركات الطيران الشريكة بموجب IATA NDC. لا شيء من ذلك ممكن عندما يكون المنطق محبوساً في وقت تشغيل Forms لا يتحدث إلا إلى قاعدة بيانات Oracle وحيدة. قُسنا انخفاضاً بنسبة 22% في زمن استرداد العمليات غير المنتظمة في إحدى شركات الطيران بعد انتقال مركز العمليات من Forms.
ينفد الدعم الممتد لـ Oracle لـ Forms 12c. وترقيع WebLogic متأخر بالفعل. شركات الطيران التي تبدأ الاستخراج الآن ستكون خارج Forms قبل التجديد الرئيسي التالي للأسطول. وتلك التي تنتظر ستشرح للمنظمين لماذا لا يزال وقت تشغيل من عام 1997 يتعامل مع بيانات الصلاحية للطيران.