أنظمة أبنيها
نظام حجز وإصدار تذاكر الطيران للوكالات
نظام حجز الطيران بين الأعمال هو المنصّة التي تعمل وكالة السفر داخلها: تبحث في المتاح لدى المورّدين الذين تربطها بهم عقود، وتطبّق هامش الوكالة، وتحجز، وتُصدر التذاكر، وتُسوّي النتيجة مقابل خطّ ائتمان تلك الوكالة. وما يجعله نظاماً مالياً لا أداة بحث هو الطبقة التي تحته — أسعار تنتهي صلاحيتها بين العرض والدفع، وخطوة إصدار لا يمكن التراجع عنها، وسقف ائتمان على المنصّة أن تتحقّق منه قبل أن تأذن بأي شيء. بنيت واحداً من هذه، من آلة حالات الحجز مروراً بتكامل المورّدين وصولاً إلى التسوية.
منصّة حجز وإصدار لوكالات السفر — بحث في مخزون المورّدين، وأسعار تنتهي صلاحيتها، وإصدار لا رجعة فيه، ورصيد الوكالة وهامشها، في نظام واحد.
من يحتاج نظام حجز وإصدار تذاكر للوكالات؟
تحتاج نظام حجز بين الأعمال حين يكون يوم وكالتك سلسلة من عروض الأسعار ويجري التسعير عبر بوّابات مورّدين في تبويبات منفصلة. يسأل زبون عن مسار، فيتفقّد أحدهم الخيارات عبر المورّدين، وينسخ الأسعار إلى جدول بيانات، ويطبّق الهامش يدوياً، ويُصدر عبر البوّابة التي احتضنت الحجز. وهو بطيء، ومعرّض للخطأ بطريقة تكلّف مالاً مباشرةً، ولا يستطيع أحد بيان انكشاف الوكالة في أي لحظة.
هذه الصفحة لـ:
- وكالة سفر تجاوزت بوّابات المورّدين والتسعير اليدوي.
- مجمّع أو تاجر جملة يبيع لوكالات فرعية، حيث يكون ائتمان الوكالة وهامشها والتسوية هي المنتج فعلاً.
- نشاط سفر لديه نظام قائم ومشكلاته تحت الخصائص — صلاحية الأسعار، أو إخفاقات الإصدار، أو تسوية لا تتوازن إلا بعد أن يقضي أحدهم يوماً عليها.
والشكل نفسه يظهر خارج السفر. أي نظام يقف بين الزبائن وعرضٍ من طرف ثالث — لوجستيات، أو تأمين، أو بيع بالجملة — لديه مخزون خارجي لا يتحكّم به، وأسعار تنتهي صلاحيتها، وخطوة تنفيذ لا رجعة فيها، وائتمان أو هامش فوق ذلك. إن كان هذا يصف نظامك، فهذه الصفحة عن مشكلتك وإن اختلف القطاع.
ما الذي يشمله بناء منصّة الحجز والإصدار؟
يغطّي بناء منصّة الحجز والإصدار دورة الحياة كاملة: تحليل الأعمال وتخطيط المنتج، والمعمارية وتصميم الأنظمة، والتطوير والتسليم، والنشر السحابي والتوسّع، وإصدارات متاجر التطبيقات حين يكون هناك سطح جوّال. وفي منصّة كهذه تحديداً، الجوهر هو:
- آلة حالات الحجز — كل حالة وكل انتقال، بما فيها التي يختلف فيها المورّد والمنصّة على ما جرى.
- البحث لدى عدّة مورّدين بتمثيل داخلي مشترك، يبقى سريع الاستجابة تحت زمن الاستجابة الخارجي ويتدهور بشكل معقول حين يتعطّل مورّد.
- معالجة صلاحية الأسعار — الفرق بين سعرٍ عُرض، وسعرٍ ما زال قابلاً للحجز، وسعرٍ يجب التحقّق منه قبل تحريك المال، مُمثَّلاً في النموذج ومشروحاً في الواجهة.
- قواعد الهامش — كيف يُعرَّف هامش الوكالة ويُطبَّق ويُتجاوز، كإعدادات لا كشيفرة.
- إصدار التذاكر، معامَلاً كنقطة اللاعودة: نداءات لا يتضاعف أثرها، ومعالجة صريحة لحالة انتهاء المهلة بعد التنفيذ، وتسوية مقابل المورّد.
- ائتمان الوكالة وانكشافها — سقوف يُتحقَّق منها قبل الإذن، وأرصدة تُصان، وانكشاف كلّي مرئي لا مُستخرَج في نهاية الشهر.
- التسوية والمطابقة عبر أجرة المورّد والهامش والائتمان والدفع.
- القابلية للمراقبة عبر كل نداء خارجي، ليكون البحث البطيء سؤالاً له جواب.
- أدوات المكتب الخلفي للتصحيحات والإلغاءات والاستثناءات التي ستقع في الأسبوع الأول.
كيف يجري بناء منصّة الحجز والإصدار؟
في منصّة الحجز والإصدار تسبق آلة الحالات أي شاشة. كل خاصية في منصّة كهذه عرضٌ على تلك الآلة، فتُحدَّد حالاتها وانتقالاتها أولاً — بما فيها القبيحة — ويُتّفق عليها مع العمل التجاري قبل أن يُبنى فوقها شيء.
ثم:
- تحليل الأعمال وتخطيط المنتج — أي المورّدين تربطك بهم عقود، وكيف يُحدَّد الهامش، وكيف يُمنح الائتمان ويُسوّى، وماذا تفعل العملية اليدوية اليوم فعلاً، بما في ذلك ما لم يكتبه أحد.
- المعمارية وتصميم الأنظمة — آلة الحالات، وحدّ تكامل واحد لكل مورّد، ونموذج المال، وضمانات عدم تضاعف الأثر حول كل خطوة لا رجعة فيها.
- التطوير والتسليم — نواة أحادية معيارية افتراضاً، بالبحث والحجز والإصدار والائتمان والتسوية كوحدات منفصلة خلف واجهات واضحة.
- النشر السحابي والتوسّع — البيئات إضافةً إلى التتبّع من الشريحة الأولى، لأن زمن النداءات الخارجية هو سؤال الأداء المهيمن هنا.
- إصدارات متاجر التطبيقات حيث يعمل الموظّفون من الهاتف.
وسبب نجاح هذا ليس معرفة تفاصيل قطاع السفر. بل أن صلاحية الأسعار وسقوف الائتمان والهامش والتسوية قواعدُ عملٍ أولاً وشيفرةٌ ثانياً. المطوّر الذي يُسلَّم قائمة خصائص سيبني القائمة بإتقان ومع ذلك يُنتج نظاماً يأذن بحجز لا تستطيع الوكالة تغطيته، لأن ذلك السؤال لم يُطرح قط. وفهم النظام التقني والعمل التجاري الذي يخدمه هو بالضبط ما يمنع حدوث ذلك — وعلى منصّة من هذا النوع، هو الفرق بين أداة حجز ونظام يثق به الجانب المالي.
أسئلة عن هذا العمل
ما الفرق بين نظام حجز بين الأعمال وموقع حجز للمستهلكين؟
موقع المستهلك يبيع مقعداً لشخص يدفع فوراً. أمّا النظام بين الأعمال فيبيع عبر وكالات، وهذا يغيّر ثلاثة أشياء بنيوياً. الهامش هامش الوكالة، يُطبَّق فوق أجرة المورّد وقابل للضبط لا ثابتاً. والدفع عادةً بالائتمان لا بالبطاقة، فعلى المنصّة أن تعرف هل تستطيع الوكالة تغطية الحجز قبل أن تأذن به. ومالك المنصّة يحمل انكشافاً عبر كل الوكالات في آنٍ واحد، ويجب أن يكون مرئياً في أي لحظة لا أن يُعاد تركيبه في نهاية الشهر. لهذا هو نظام مالي عليه واجهة بحث، لا العكس.
ماذا يحدث حين تنتهي صلاحية السعر والزبون ما زال يفكّر؟
على النظام أن يميّز بين ثلاثة أشياء تبدو متطابقة على الشاشة: سعرٌ عرضه، وسعرٌ ما زال قابلاً للحجز، وسعرٌ يجب التحقّق منه قبل تحريك المال. ومعاملتها كرقم واحد هي حيث تخسر الوكالات مالاً حقيقياً. والنصف الأصعب هو الواجهة: الموظّف في منتصف محادثة مع زبون، فيجب شرح الفرق بطريقة صالحة للاستخدام في تلك اللحظة لا مدفونة في حقل حالة. صلاحية السعر تُصمَّم داخل آلة حالات الحجز لا تُعالَج كحالة خطأ.
ماذا يحدث إن انتهت مهلة المورّد بعد أن يكون قد أصدر التذكرة فعلاً؟
هذه هي الحالة التي وُجد من أجلها تصميم المعاملات كلّه. كل ما يسبق الإصدار قابل للتراجع والإصدار ليس كذلك، لذا لا يتضاعف أثر نداء الإصدار عند التكرار، ولآلة حالات الحجز حالات صريحة لِـ«المورّد ونحن نختلف على ما جرى»، والتسوية مقابل المورّد جزء من النظام لا مهمّة تنظيف يدوية. إعادة المحاولة حركة مرور عادية حين تنادي أنظمة خارجية عبر شبكات غير موثوقة. وإصدار تذكرة مرّتين ليس عيباً تُصلحه في الإصدار التالي.
هل يمكن إضافة مورّدين لاحقاً، أم أن الأول مدموج في النظام؟
يمكن لاحقاً، إن بُني الأمر بشكل صحيح من المرّة الأولى. كل مورّد يحصل على حدّ تكامل واحد يترجم إلى تمثيل داخلي مشترك، فلا يتغيّر شكل نموذج المجال حين يتغيّر مورّد. وتصير إضافة مورّد تنفيذَ واجهة لا تعديلَ مسار البحث. المورّدون يغيّرون واجهاتهم البرمجية ودلالات أخطائهم وأحياناً تصوّرهم لما تعنيه الأجرة؛ وجدوى ذلك الحدّ أن تبقى تلك التغيّرات محصورة.
كيف يتعامل النظام مع سقوف ائتمان الوكالات؟
يُتحقَّق من الائتمان قبل الإذن بالحجز لا يُسوّى بعده، وهو القرار الذي يحوّل أداة الحجز إلى نظام مالي. أجرة المورّد وهامش الوكالة وسقف ائتمانها والتسوية أربعة اهتمامات منفصلة يجب أن تتصالح جميعاً، وعلى المنصّة أن تكون قادرة على بيان انكشاف وكالة — والمجموع عبر الوكالات — في أي لحظة. وقواعد التسوية قواعد عمل: يُتّفق عليها معك صراحةً وتُنمذَج، لا تُستنتج من سلوك جدول البيانات السابق.
ماذا يحدث للبحث حين يكون أحد المورّدين بطيئاً أو متوقّفاً؟
يتدهور ولا يفشل. يبقى البحث سريع الاستجابة بينما يُستعلم من عدّة أنظمة خارجية لكلٍّ منها زمن استجابته ودلالات أخطائه، والمورّد غير المتاح يسحب نتائجه هو بدل أن يُفشل البحث كلّه. وجعل ذلك السلوك قابلاً للتشخيص يحتاج قابلية للمراقبة من الشريحة الأولى: مع هذا الكمّ من النداءات الخارجية، لا تخبرك عبارة «النظام بطيء» بشيء ما لم تعرف أي مورّد، على أي مسار، في أي خطوة. يدخل التتبّع مع أول خاصية لا بعد أول عطل.
نظام حجز وإصدار تذاكر الطيران للوكالات — أخبرني بما لديك الآن.
ابدأ محادثة