كيف تعمل خدمة تقديم الخدمات فعليًا عندما يكون كلا النموذجين قيد التشغيل
لدينا مشكلة جديدة تواجه فرق شركات الطيران التي تعيش في حالة من الفوضى. لا تزال معظم شركات الطيران تستخدم سجل الحجز التقليدي (سجل اسم الراكب أو PNR) بينما تبدأ في النظر في البيع والتسليم باستخدام الطلبات.
"نحن نعلم أن الطلبات قادمة، لكننا ما زلنا ندير عملياتنا على أساس سجلات الحجز وتذاكر السفر. ما الذي يتغير فعليًا في تقديم الخدمة؟"
في يوم العملية، يتم استخدام كلا النموذجين. يجب أن تأخذ خدمات تقديم الخدمات هذه الحقيقة في الاعتبار.
تقدم هذه الطبعة ثلاثة أشياء: إجابات على بعض أسئلتكم، وبنيات ملموسة مع شركاء تظهر العروض والطلبات والتسليم معًا، وبعض النقاط التي يمكن إضافتها إلى خارطة الطريق الخاصة بكم.
دعونا نغوص في الموضوع.
الأسئلة الشائعة حول تقديم الخدمة: من PNRs إلى الطلبات
قمنا بتحويل الأسئلة التي كنا نسمعها باستمرار من فرق شركات الطيران إلى قائمة أسئلة وأجوبة موجزة. وبعبارات بسيطة، تغطي هذه القائمة ما يلي:
- كيف يختلف التسليم باستخدام الأوامر عن التسليم باستخدام أرقام الحجز وتذاكر السفر
- ماذا يعني اختيار "مصدر الحقيقة" لرحلة ما عندما يتواجد كلا النموذجين
- حيث لا تزال الوثائق القديمة مهمة، وحيث يمكن إنتاجها عند الطلب
- كيفية قياس التقدم المحرز من خلال وقت التعافي والوعود التي تم الوفاء بها، بدلاً من عدد الشاشات
اقرأ: الأسئلة الشائعة حول تقديم الخدمة – من PNRs إلى الطلبات
كيف تعمل العروض والطلبات والتسليم معًا
طرح اتحاد شركات الطيران التابع للاتحاد الدولي للنقل الجوي (IATA) سؤالاً بسيطاً: هل يمكن تنفيذ العروض والطلبات عبر عدة مزودين في أنظمة حقيقية، في حين أن شركات الطيران لا تزال تستخدم سجلات الحجز (PNR)؟ نقل برنامج "المرونة في العمل" هذا السؤال من الشرائح إلى تكامل الأنظمة العاملة.
ضمن هذه المبادرة، هناك بعض الأمثلة المهمة إذا كنت مسؤولاً عن تقديم الخدمات.
من العرض إلى التسليم بدون PSS – Ink، Datalex، PROS
في هذا النموذج التجريبي، تتولى Datalex إنشاء العروض وإدارة الطلبات، بينما توفر PROS الأسعار، وتقوم Ink بتنفيذ التسليم في المطار.
- يتم إعداد العروض وتحديد أسعارها في طبقة البيع بالتجزئة
- الطلبات تحتفظ بما تم بيعه، مع حقوق واضحة
- يقوم التسليم بقراءة نفس الطلب، وتنفيذ تسجيل الوصول والوفاء بالالتزامات الإضافية، ثم إعادة كتابة الحالة
نظام خدمة الركاب التقليدي لا يحرك التدفق. وهذا يتيح لشركة الطيران حرية إضافة أو تغيير المكونات دون إعادة تشغيل المجموعة بأكملها، ويبقي الطريق مفتوحًا لتشغيل سجلات الحجز (PNR) والأوامر جنبًا إلى جنب أثناء الانتقال.
الطلبات المباشرة التي تصل إلى المطار – Ink و FLYR
إثبات مفهوم أن Ink و FLYR يعملان على الحفاظ على سلاسة التدفقات:
- FLYR تتولى العروض والطلبات: التسوق، التسعير، إنشاء الطلبات ودورة الحياة
- تتولى Ink عمليات التسليم: إجراءات المطار، والخدمات الإضافية، وحالة التسليم.
كيف يعمل. المسافرون يتسوقون ويشترون؛ FLYR تنشئ الطلب. ثم يصبح هذا الطلب متاحًا لـ Ink في المطار. يقوم الوكلاء بإعداد الرحلة، وتغيير المقاعد، وإضافة خدمات إضافية، وتؤدي هذه الإجراءات إلى تحديث سجل الطلب نفسه في الوقت الفعلي. لا توجد "نسخة مطار" منفصلة عن الحقيقة.
ثلاثة نقاط جديرة بالملاحظة:
- التسليم هو أكثر من مجرد مراقبة المغادرة. لا تقصر عملية التسليم على نظام مطار واحد.
- إدارة الطلبات هي جزء من مراقبة المغادرة. يحتاج كلا الفريقين إلى اتفاق واضح بشأن من يقوم بتحديث الحالات ومتى.
- ستتأخر العمليات حتى يتم إزالة العمل، وليس مجرد نقله. يجب أن يسهل البناء يومهم.
الخطوط الجوية الرياضية: تسليم مشاريع جديدة في عالم هجين
رياد إير هي شركة طيران جديدة، وليست شركة طيران قديمة تعمل من خلال عملية تحويل. منذ اليوم الأول، يجب أن تعمل طبقة التسليم الخاصة بها في عالم لا يزال فيه الشركاء والمطارات والهيئات التنظيمية يتحدثون "لغات" قديمة (PNRs، التذاكر، الرسائل التقليدية).
تم تصميم إدارة توصيل الحبر لتكون في الوسط: فهي تدعم نموذج الرياض للطيران الذي يركز على الطلبات، مع الاستمرار في التواصل بشكل واضح مع الأنظمة القديمة عند الحاجة. والنتيجة ليست "شركة طيران في مرحلة انتقالية"، بل عملية جديدة مصممة للعمل في كلا جانبي الصناعة طالما استمرت هذه الحقيقة الهجينة.
اقرأ: تمكين العروض والطلبات من خلال النمطية
ماذا يعني ذلك بالنسبة لخارطة طريقك
أنت لا تحتاج إلى مفهوم آخر. أنت بحاجة إلى بعض الخيارات الواضحة.
- ابدأ من الرحلات، وليس من الأنظمة. بالنسبة لكل تدفق، حدد السجل الذي يمثل المرجع التشغيلي. إذا كان هناك طلب، فليكن هو المصدر الأساسي للاستحقاقات والحالة.
- حافظ على قابلية استخدام كلا المعرفين. يجب أن يتمكن الموظفون من الاسترجاع باستخدام مرجع على غرار PNR أو معرف الطلب دون تشغيل عمليتين منفصلتين.
- تعامل مع المستندات القديمة على أنها مخرجات. لا يزال العديد من الشركاء والسلطات بحاجة إليها، ولكن لا يجب أن يمليوا عليك كيفية إدارة عمليات التسليم.*
- صمم لخدمة أكثر من مزود واحد. افترض أن العرض والطلب والتسليم قد لا تكون جميعها موجودة على نفس المنصة. استخدم واجهات واضحة حتى تتمكن من تغيير عنصر واحد دون الحاجة إلى إعادة توصيل كل شيء.
*هناك، مع ذلك، سؤال واحد يجب طرحه.
في OOSD (تسوية طلب العرض والتسليم)، يجب أن يتضمن كل طلب معرف طلب، ويمكن أن يتضمن اختيارياً معرف حجز مكون من ستة أحرف أبجدية رقمية، والذي يمكن استخدامه بدلاً من PNR التقليدي. على الرغم من أن معرف الحجز هذا يعمل بشكل مشابه لرقم الحجز (PNR)، إلا أنه ليس رقم حجز في حد ذاته، لأنه لا يخضع للقيود الهيكلية التي تنطبق عادةً على أرقام الحجز (PNR)؛ ومع ذلك، فإنه لا يزال يوفر مرجع حجز متوافقًا مع لوائح APIS التي تفرضها العديد من الحكومات، بالإضافة إلى BSM ومعايير المراسلة الأخرى التي تعتمد على معرف مكون من ستة أحرف. تتطلب معظم الرحلات الجوية، وخاصة الخدمات الدولية، مثل هذا المرجع. ومع ذلك، لا يزال هناك سؤال مفتوح حول ما إذا كان يجب أن تتبع معرّفات الحجز هذه في النهاية قواعد PNR التقليدية، مثل ضمان أن جميع الركاب يشتركون في نفس درجة السفر أو نفس نقطة الانطلاق والوجهة، من أجل تجنب المشاكل أو العلامات التي تثيرها الأنظمة النهائية.
سنشارك المزيد من الأفكار حول القضايا التالية.
المؤلف
