.webp)
في هذا العدد، يتناول بن وايمارك الأسئلة الصعبة المتعلقة بالتسليم القائم على الطلبات: كيفية إدارة حالات دورة حياة الخدمة، وحل النزاعات بين الأنظمة، والتعامل مع الاضطرابات دون طوابير عصر PNR، وما يلزم لتشغيل اليوم الأول في بيئة طيران هجينة.
في الأعداد الثلاثة الأولى من سلسلة الأسئلة الشائعة حول تقديم الخدمات، تناولنا التحول من العمليات القائمة على PNR إلى تقديم الخدمات القائم على الطلبات، واستكشفنا ما يعنيه "التسليم بالطلبات" في الممارسة العملية ولماذا يعتبر أفضل من الأساليب القديمة. ونظرنا في كيفية بدء شركات الطيران هذا التحول حتى مع وجود أنظمة PSS قديمة، وكيفية انتقال حالة "جاهز للطيران" من DCS إلى الطلبات، وكيفية نقل الخدمات إلى الأنظمة التشغيلية. لقد درسنا معالجة الأمتعة، والترابط المخصص، والوسائط الغنية في تدفقات التسوق ، والفوائد العملية التي تراها شركات الطيران بالفعل، من تحسين خدمة العملاء إلى الرؤية في الوقت الفعلي وزيادة المبيعات الإضافية بشكل أسرع. كما استكشفنا كيفية تعامل شركات الطيران مع حالة تقديم الخدمة عبر الرحلات المشتركة، مما يضمن رؤية متسقة دون الحاجة إلى تكامل مباشر بين أنظمة شركات الطيران.
الآن نحن نتناول الأسئلة الأصعب: كيف تحافظ على السيطرة عندما تسوء الأمور؟ كيف تعرف الحقيقة عندما تتعارض الأنظمة؟ وما الذي يتطلبه الأمر فعليًا لتنفيذ التسليم القائم على النظام من اليوم الأول؟
ما هو دورة حياة التسليم لكل عنصر من عناصر الطلب، وما هي التحولات غير القابلة للتفاوض في الحالة؟
كل بند من بنود الطلب له خدمة (رحلة طيران، مقعد، حقيبة، وجبة، إلخ) تتبع دورة حياة تسليم محددة. يتم تتبع دورة الحياة هذه من خلال تحديثات الحالة المتبادلة بين نظام إدارة الطلبات (OMS) ونظام إدارة التسليم (DMS) – نظام مراقبة المغادرة (DCS) هو إحدى وظائف نظام إدارة التسليم – ومقدمي خدمات التسليم. نحتاج إلى نموذج حالة عملي يغطي جميع المراحل الحاسمة – تسجيل الوصول، الصعود إلى الطائرة، التسليم، فشل التسليم، الاستبدال، الاسترداد، التعويض، والوفاء الجزئي.
في الوقت الحالي، لم يتم تحديد ذلك بشكل واضح من قبل الاتحاد الدولي للنقل الجوي (IATA)، ولكن من الناحية المثالية، نحتاج إلى التحرك نحو شيء مثل هذا:
تم الإنشاء: تم حجز الحق في الطلب ولكن لم يتم التسليم بعد.
جاهز للتسليم: العميل مؤهل للاستفادة من الخدمة (على سبيل المثال، يمكنه تسجيل الوصول أو تسليم حقيبته).
تسجيل الوصول: تؤكد مراقبة المغادرة تسجيل الوصول. يتم تخصيص المقعد وقبول الأمتعة وما إلى ذلك.
الصعود: يصعد الراكب فعليًا وتبدأ الخدمة (مثل الرحلة الجوية).
تم التسليم: تم استهلاك الخدمة. سافر الراكب، ونقلت الحقيبة، وقدمت الوجبة.
فشل التسليم: لم يتم تسليم الخدمة (على سبيل المثال، عدم الحضور، مشكلة فنية، رفض الحقيبة).
استبدال: تم استبدال الخدمة الأصلية بخدمة أخرى (مثل نوع مقعد جديد، أو تغيير مسار الرحلة).
المبلغ المسترد: يتم إلغاء الخدمة غير المقدمّة واسترداد المبلغ المدفوع.
التعويض: يتم منح تعويض مالي أو خدمي في حالة فشل الخدمة.
تم الوفاء جزئيًا: تم تقديم جزء من الخدمة (على سبيل المثال، إكمال جزء من الرحلة، أو تحميل حقيبة واحدة فقط من حقيبتين).
يجب أن تنعكس هذه التحولات في رسائل ServiceStatusChangeNotif وأن يتم تسجيلها في سجل تدقيق الطلب. يدعم هذا النموذج معالجة الاضطرابات بشكل مكثف دون الحاجة إلى إعادة إصدار المنتج.
من يملك الحقيقة عندما يختلف كل من قسم التسليم وإدارة الطلبات والشركاء؟
عندما يتعلق الأمر بأنظمة متعددة، فإن التضارب أمر لا مفر منه. لذا، علينا أن نكون واضحين بشأن النظام الذي ينشأ عنه كل حدث، وكيفية حل التضارب، وشكل سجل التدقيق.
في النموذج القائم على الطلبات:
- OMS هو نظام تسجيل الاستحقاقات وحالتها. وهو يحدد ما تم تقديمه أو تأكيده أو إلغاؤه أو استبداله أو استرداده.
- ينشئ نظام إدارة الرحلات/مراقبة المغادرة أحداثًا تشغيلية مثل تسجيل الوصول والصعود إلى الطائرة وحالة التحميل. ويتم إرسال هذه الأحداث عبر ServiceStatusChangeNotif.
- كما يساهم مقدمو خدمات التسليم (مثل شركات الخدمات الأرضية) في تحديثات الحالة، على سبيل المثال، الوصول إلى الصالة أو تأكيد وزن الأمتعة.
- سيوفر نظام إدارة التسليم (DMS) وظائف مراقبة المغادرة إلى جانب حالات مزودي خدمات التسليم هذه.
تتبع عملية حل النزاعات التسلسل الهرمي التالي:
- إذا لم يتم وضع علامة على الخدمة على أنها تم تسليمها في نظام إدارة العمليات (OMS)، فإنها تعتبر غير مسلمة، بغض النظر عما تذكره سجلات مراقبة المغادرة (DC/DCS).
- إذا تلقى OMS تحديثًا للحالة من مصدر موثوق (DC أو شريك)، فإن ذلك يصبح الحقيقة المعيارية.
- يتم تسجيل التباينات ووضع علامات عليها من أجل سير عمل يدوي أو آلي لحلها.
يتم تجميع سجل التدقيق في النظام ويحتوي على جميع تحديثات الحالة مع نظام المصدر والطابع الزمني وتفاصيل الحدث. وهذا يتيح إمكانية التتبع الكامل وإدارة النزاعات.
كيف تعمل إدارة الاضطرابات في نموذج التسليم القائم على الطلبات بدون قوائم الانتظار في عصر PNR؟
دعونا نستعرض سيناريو كامل من البداية إلى النهاية لنرى كيف يعمل في الواقع. سنغطي حالة عدم التوصيل مع تعقيدات الأمتعة، وإعادة الترتيب، وإعادة تخصيص المقاعد، ونقل الخدمات الإضافية، وإرسال الرسائل إلى العملاء، مع تتبع التحديثات في كل خطوة.
- خطأ في التوصيل: يصل الراكب متأخراً ويفوت رحلته المتصلة. يرسل DC إشعار ServiceStatusChangeNotif إلى OMS يقول: لم يتم الصعود إلى الطائرة.
- إعادة الحجز: تقوم OMS بتشغيل عملية إعادة الحجز عبر OrderReshop لتقديم خيارات مسارات جديدة. يختار العميل رحلته الجديدة.
- إعادة تخصيص المقاعد: المقعد الجديد هو جزء من عرض إعادة الترتيب ويتم تحديثه في الطلب عبر OrderChange.
- ترحيل الملحقات: يتم إعادة تخصيص الملحقات الصالحة (مثل الوجبات المدفوعة مسبقًا) أو استرداد قيمتها بناءً على منطق التعيين.
- الأمتعة: تم تحميل الحقيبة بالفعل على الرحلة الأصلية. يقوم نظام تتبع الأمتعة بتحديث نظام إدارة العمليات (OMS)، الذي يشير إلى عدم التطابق.
- رسائل العملاء: يبدأ نظام إدارة الطلبات (OMS) إرسال الرسائل عبر الإشعارات الفورية أو سير عمل الوكيل، حيث يرسل خط سير الرحلة الجديد والتحديثات.
- التعويض (إذا لزم الأمر): إذا قام العميل بتخفيض مستوى الخدمة أو فقدها، فإن OrderChange أو OrderQuote تعكس التعديل، ويتم إصدار استرداد أو قسيمة.
تنعكس جميع التحديثات في الطلب في الوقت الفعلي. لا حاجة إلى الانتظار في طابور أو المزامنة اليدوية بين أنظمة إصدار التذاكر أو الحجز أو المخزون.
كيف نتعامل مع التسليم الجزئي واستبدال الخدمة والتعويض دون إعادة إنشاء التذاكر و EMDs؟
السؤال الأساسي هنا هو كيف يمكنك تمثيل الإنجاز والفشل والعلاج مباشرة في الأمر دون العودة إلى إنشاء عناصر جديدة تحت اسم مختلف.
لا داعي لإعادة إنشاء التذاكر أو EMDs. سجل الطلبات يتولى كل شيء:
- التسليم الجزئي: لكل عنصر من عناصر الطلب حالة تسليم خاصة به. إذا تم نقل جزء من الرحلة جواً أو تم استهلاك جزء فقط من الخدمة، يتم تسجيل ذلك بشكل منفصل.
- الاستبدال: يوضح الطلب الخدمة التي تم استبدالها وما تم استبدالها به. على سبيل المثال: تم استبدال المقعد 12A بالمقعد 14C، مع إصدار استرداد مالي في حالة اختلاف القيمة.
- التعويض: ينعكس هذا كعنصر جديد في الطلب (مثل قسيمة)، أو تعديل على المبلغ الإجمالي المدفوع، أو قيمة مخزنة مرفقة بالطلب.
يتم تسجيل جميع الأحداث مع تحديثات الحالة (ServiceStatusChangeNotif) وإدخالات سجل التدقيق وإجراءات OrderChange، حيثما ينطبق ذلك. يتم تضمين عمليات الاسترداد أو الغرامات أو الإجراءات التقديرية مباشرة في الطلب؛ دون الحاجة إلى نسخ مكررة.
ما هي الحد الأدنى من عمليات الدمج والضوابط اللازمة لتشغيل التسليم القائم على الطلبات في شركة طيران مختلطة؟
بالنسبة لشركة طيران تعمل بنموذج هجين (واجهة أمامية قائمة على الطلبات مع أنظمة قديمة في الخلفية)، تحتاج إلى تحديد الحد الأدنى من الواجهات والضوابط القابلة للتطبيق. ويشمل ذلك استيعاب الأحداث، والتحقق من الاستحقاقات، ومعالجة الاستثناءات، ودلالات "الجاهزية للطيران" المشتركة.
وهذا ما يبدو عليه الأمر:
استيعاب الأحداث: يجب أن يتلقى نظام إدارة العمليات (OMS) الخاص بك الأحداث من أنظمة التحكم في الدفع (DCS) وأنظمة الأمتعة والصالات والتموين وتسجيل الوصول عبر ServiceStatusChangeNotif.
فحص الاستحقاق: يجب أن تستعلم أنظمة التسليم من نظام إدارة الطلبات (OMS) (أو تتلقى رسائل ServiceDeliveryNotif ) للتحقق مما يجب تسليمه.
معالجة الاستثناءات: يجب أن يتعامل نظام إدارة الطلبات (OMS) الخاص بك مع استجابات الأخطاء وعلامات التعارض (مثل عندما يتم تسليم حقيبة ولكن الطلب قد تم إلغاؤه).
دلالات مشتركة "جاهزة للتنفيذ": يجب أن تتوافق جميع أنظمة التسليم مع التعريفات المحددة في الطلبات لـ "تسجيل الوصول" و"الصعود إلى الطائرة" و"التسليم".
عملية الاحتياطية: تحتاج إلى القدرة على تسجيل الحالة أو تجاوزها يدويًا عبر أدوات الوكيل، مع الحفاظ على سلامة تدقيق الطلبات.
يتيح لك هذا الإعداد دعم NDC و ONE Order على البنية التحتية القديمة، مع الفصل التدريجي عن تبعيات PSS.
المؤلف
