تنفيذ حل خدمات الطيران القائم على ERPNext

مقدمة

يتطلب تنفيذ نظام عمليات طيران متكامل الخدمات على ERPNext (أحدث إصدار، v15) كلاً من التخصيص الفني والمعرفة الوظيفية بالمجال. يوفر إطار عمل Frappe مفتوح المصدر في ERPNext قاعدة قوية من وحدات تخطيط موارد المؤسسات (e.g. accounting, HR, inventory)، والتي يمكن تصميمها لتلبية الاحتياجات المعقدة لإدارة شركات الطيران. يوضح هذا التقرير بنية حل شاملة وخارطة طريق لمنصة خدمات طيران قائمة على ERPNext قادرة على خدمة شركة طيران واحدة أو عدة شركات طيران بشكل مركزي. نغطي تخصيصات النظام الأساسية، وتطبيقات الجوال/الويب المتكاملة، والاتصالات متعددة القنوات، والمجالات المتخصصة من حجز الرحلات إلى الصيانة. يتم التركيز على أفضل الممارسات المتعلقة بالأمان والامتثال والنشر لضمان أن يكون النظام موثوقًا وقابلاً للتطوير ومتاحًا عالميًا. الهدف هو منصة مركزية مدفوعة بـ ERPNext تبسط جميع عمليات شركات الطيران - من مبيعات التذاكر وتسجيل الوصول إلى صيانة الأسطول والمحاسبة المالية - مع الحفاظ على المرونة للاستخدام متعدد الشركات أو متعدد المستأجرين.

تنفيذ النظام الأساسي (تخصيص ERPNext)

لإدارة جميع جوانب عمليات شركات الطيران، يجب تخصيص نظام ERPNext الأساسي على نطاق واسع. سيتم تكييف وحدات ERPNext الحالية وإنشاء وحدات جديدة للتعامل مع البيانات وسير العمل الخاصة بالطيران:

1. وحدة عمليات الطيران (مخصصة): تطوير تطبيق جديد (using bench new-app) لعمليات شركات الطيران، وإدخال أنواع مستندات (DocTypes) مثل Flight (flight number, schedule, aircraft, crew)، وRoute (origin, destination, standard times)، وReservation/PNR (passenger booking record). ترتبط هذه الوحدة بـ ERPNext ولكنها تحتوي على المنطق الخاص بشركات الطيران. على سبيل المثال، يمكن أن يحتوي مستند Flight على جداول فرعية لمخزون المقاعد أو الحجوزات، وحالات (Scheduled, Departed, etc.). يسمح إنشاء تطبيق Frappe مخصص بإضافة مثل هذه الأنواع من المستندات ومنطق العمل دون تغيير جوهر ERPNext، ويمكن مشاركة هذه التخصيصات عبر الشركات أو المواقع[1].
2. مبيعات التذاكر والحجز (وحدة البيع المعدلة): الاستفادة من وحدة البيع في ERPNext للتعامل مع معاملات التذاكر. النهج العملي (inspired by a travel agency solution) هو استخدام أصناف غير مخزنية لخدمات التذاكر (e.g. an item “Air Ticket”) واستخدام أمر المبيعات/الفاتورة (Sales Order/Invoice) كتأكيد للحجز، مع إثرائه بحقول مخصصة لتفاصيل الرحلة[2]. على سبيل المثال، يمكن إضافة حقول مخصصة مثل Airline، وFlight Number، وOrigin، وDestination، وDeparture/Arrival Time إلى فاتورة المبيعات أو نوع مستند Ticket Booking مخصص، وتعبئتها عند إجراء الحجز[2]. يمكن تخزين رقم سجل اسم الراكب (PNR) أو رقم التذكرة الإلكترونية الفريد لكل تذكرة كرقم تسلسلي (Serial No) في ERPNext بحيث تكون معلومات الرحلة المحددة مرتبطة بهذا السجل التسلسلي (as was done in a travel agency use-case)[2][2]. هذا يضمن ربط كل عملية بيع برحلة ومقعد معين، مما يتيح تتبع الإشغال والإيرادات لكل رحلة. ستقوم البرامج النصية المخصصة بأتمتة التدفق: على سبيل المثال، عند إنشاء فاتورة حجز، يتم كتابة تفاصيل الرحلة في سجل الرقم التسلسلي (PNR)، والعكس صحيح، يتم جلب هذه التفاصيل عند الحاجة إليها في الفواتير أو بطاقات الصعود إلى الطائرة[2].
3. سجلات الركاب (توسيع وحدة إدارة علاقات العملاء): استخدام نوع مستند العميل (Customer) في ERPNext أو نوع مستند Passenger مخصص للحفاظ على ملفات تعريف المسافرين. وهذا يشمل المعلومات الشخصية، تفاصيل الاتصال، معلومات جواز السفر والتأشيرة (passport and visa information)، وحالة المسافر الدائم، وما إلى ذلك. يمكن إضافة حقول إضافية لتسجيل الجنسية وتفاصيل المستندات لدعم الامتثال للسفر الدولي. إطار عمل DocType في ERPNext يجعل من السهل توسيع نموذج البيانات بمثل هذه الحقول[2]. من خلال معاملة الركاب بشكل مشابه لـ "العملاء" (customers) في نظام تخطيط موارد المؤسسات، يمكننا ربطهم بالحجوزات والفواتير والاتصالات في النظام.
4. المخزون والأصول (مكيفة للأسطول وقطع الغيار): سيتم إعادة توظيف وحدات المخزون والأصول لإدارة الموارد المادية:
5. الطائرات كأصول: تسجيل كل رقم تسجيل طائرة كـ أصل (Asset) في ERPNext. تمييزها على أنها تتطلب صيانة حتى نتمكن من جدولة وتسجيل الصيانة[3]. سيحتوي سجل الأصول على تفاصيل مثل نوع الطائرة، السعة، معلومات الملكية/الإيجار، وربطه بسجلات الصيانة.
6. قطع الغيار والمعدات: استخدام وحدة المخزون (Stock) للحفاظ على مخزون قطع الغيار في مستودعات مختلفة (e.g. airport stores, maintenance facilities). تحديد المستودعات لكل مطار أو قاعدة صيانة. يمكن تتبع قطع غيار الطائرات الحيوية بأرقام تسلسلية/دفعات، واستخدام ميزات المخزون في ERPNext (مستويات إعادة الطلب، إلخ) لضمان توفر قطع الغيار.
7. إمدادات التموين: التعامل مع أصناف التموين (meals, beverages, onboard sales stock) كأصناف مخزون لها مستودعاتها الخاصة (e.g. catering kitchen, or even the aircraft trolley as a transient warehouse). هذا يسمح باستخدام مستندات نقل المخزون لتحميل/تفريغ الرحلات بإمدادات التموين، وتسجيل الاستهلاك بعد الرحلات.
8. تخصيص وحدة الموارد البشرية: سيتم توسيع وحدة الموارد البشرية الحالية لاستيعاب أدوار موظفي شركات الطيران وجدولتهم (detailed in a later section). للإعداد الأساسي، قم بتكوين الشركات (Companies) في ERPNext لتمثيل كل شركة طيران (if multiple) أو الشركات التابعة، مما يتيح الفصل المالي مع مشاركة نفس النظام. يدعم ERPNext بشكل أساسي إعدادات الشركات المتعددة على موقع واحد[1] - يمكن مشاركة البيانات مثل دليل الحسابات أو قوائم الأصناف الرئيسية أو عزلها حسب الحاجة. إذا كنت تخدم عدة شركات طيران متميزة كعملاء منفصلين، فيمكن اختيار نهج متعدد المستأجرين (مواقع منفصلة لكل منها) لعزل البيانات بالكامل[1]. في كلتا الحالتين، يتم تثبيت التطبيقات والوحدات المخصصة المطورة (flights, bookings, etc.) لجميع الشركات أو المواقع، مما يوفر قاعدة شفرة موحدة مع بيانات منفصلة.
9. سير العمل والأذونات: تكوين سير العمل (Workflows) في ERPNext للعمليات الحيوية (e.g. an approval flow for flight schedule changes or large refunds). تعيين أذونات قائمة على الأدوار (role-based permissions) دقيقة: على سبيل المثال، يمكن لوكلاء المبيعات إنشاء حجوزات ولكن لا يمكنهم إلغاء الرحلات، ويمكن للموظفين الأرضيين تحديث حالة الرحلة، ويمكن لمهندسي الصيانة تسجيل الإصلاحات، وما إلى ذلك. سيفرض مدير أذونات الأدوار في ERPNext هذه الضوابط لضمان أن المستخدمين المصرح لهم فقط هم من يقومون بإجراءات معينة.

بشكل عام، يتضمن التنفيذ الأساسي تكييف نموذج بيانات ومنطق ERPNext لمجال شركات الطيران. تعني مرونة Frappe أنه يمكننا إدخال أنواع مستندات وحقول جديدة بسهولة، واستخدام برامج نصية للخادم أو كود Python مخصص (في تطبيق Frappe) لتنفيذ قواعد العمل (such as preventing overbooking, validating crew work hours, etc.). مع هذا الأساس، يتم التعامل مع جميع العمليات الأساسية - جدولة الرحلات، بيع التذاكر، إدارة الركاب، تنسيق الطاقم، تتبع الشؤون المالية - داخل قاعدة بيانات ERPNext، مما يضمن وجود مصدر وحيد للحقيقة لشركة الطيران.

البرامج الإضافية: تطبيقات الجوال وبوابات الويب

بينما سيقوم ERPNext بتشغيل الواجهة الخلفية الأساسية، هناك حاجة إلى تطبيقات واجهة أمامية إضافية لمجموعات المستخدمين المختلفة. سيتم تطوير هذه الإضافات (native mobile apps, web portals, and third-party integrations) كمشاريع منفصلة تتفاعل مع ERPNext عبر واجهات برمجة التطبيقات (interface with ERPNext via APIs). هذا النهج المنفصل يستفيد من قدرات التكامل في ERPNext لتوفير تجارب مستخدم متخصصة:

1. تطبيق الجوال للركاب (Flutter): يوفر تطبيق جوال متعدد المنصات للركاب ميزات مريحة مثل البحث عن الرحلات، الحجز، تسجيل الوصول عبر الجوال، بطاقات الصعود إلى الطائرة، حالة الرحلة في الوقت الفعلي، وإشعارات السفر. يعد Flutter خيارًا مثاليًا لقاعدة شفرة واحدة تستهدف كلاً من iOS وAndroid. سيستخدم التطبيق واجهة برمجة تطبيقات REST (REST API) الخاصة بـ ERPNext لاسترداد الرحلات المتاحة، مخزون المقاعد، الأسعار، وإنشاء أو تعديل الحجوزات. يوفر ERPNext واجهة برمجة تطبيقات REST قوية تتيح الاتصال السلس وتبادل البيانات مع التطبيقات الخارجية[4]. على سبيل المثال، عندما يبحث مستخدم عن رحلات في التطبيق، تقوم مكالمة API إلى نقطة نهاية مخصصة (or direct DocType API) في ERPNext بجلب الرحلات التي تطابق المعايير؛ ويؤدي تأكيد الحجز في التطبيق إلى تشغيل طلب POST API لإنشاء حجز/فاتورة في ERPNext. يمكن للتطبيق أيضًا تخزين ملف تعريف الراكب (أو جلبه من سجلات الركاب في ERPNext) لإجراء حجوزات أسرع. يمكن دفع التحديثات في الوقت الفعلي (gate change, delay, etc.) إلى التطبيق عبر خدمة إشعارات أو من خلال التكامل مع نظام الدردشة/الإشعارات (ClefinCode Chat, described later).
2. تطبيق الجوال للموظفين: تطبيق Flutter آخر (أو قسم داخل نفس التطبيق مع وصول قائم على الأدوار) سيخدم موظفي شركات الطيران. لدى الموظفين المختلفين احتياجات مختلفة:
3. طاقم الطائرة والطيارون: عرض جدولهم (الرحلات المعينة)، الإبلاغ عن التوافر أو التبادلات، التحقق من تفاصيل الرحلة وبيان الركاب، واستلام الإشعارات (e.g. last-minute schedule changes). يمكنهم أيضًا استخدام التطبيق لأداء مهام على متن الطائرة مثل إحصاء عدد الركاب أو الإبلاغ عن الحوادث.
4. موظفو العمليات الأرضية: تلقي قوائم المهام للرحلات (معلومات بوابة الصعود، تعليمات المناولة الخاصة)، القدرة على مسح بطاقات الصعود (متكاملة مع أجهزة كاميرا الجهاز) لتمييز الركاب على أنهم صعدوا، والإبلاغ عن الحوادث (مثل مشاكل الأمتعة أو التأخير).
5. مهندسو الصيانة: الوصول إلى معلومات الطائرات، رؤية مهام الصيانة المجدولة، تسجيل إكمال الفحوصات، أو الإبلاغ عن العيوب أثناء التنقل.
6. ترتبط كل من هذه الوظائف بسجلات ERPNext (الجداول، حالة الصعود، سجلات الصيانة) عبر مكالمات API آمنة. باستخدام Flutter، نضمن واجهة مستخدم/تجربة مستخدم متسقة ويمكننا إعادة استخدام المكونات (مثل عرض قائمة الرحلات) عبر أدوار الموظفين المختلفة مع اختلافات طفيفة.
7. بوابة الحجز عبر الويب: بالإضافة إلى الجوال، تعد بوابة الويب سريعة الاستجابة ضرورية (for passengers who prefer desktop or agencies who book on behalf of travelers). يمكن تنفيذ ذلك بلغة Python (Flask/Django) أو واجهة أمامية JavaScript (Vue.js, Next.js, etc.) مع ERPNext كواجهة خلفية. أحد الأساليب هو استخدام وحدة موقع الويب المدمجة في ERPNext - يمكن لـ ERPNext تقديم صفحات ويب ونماذج، ويمكن أن تستضيف صفحة حجز رحلات مصممة خصيصًا. ومع ذلك، للحصول على مرونة كاملة، قد يكون تطبيق ويب منفصل يستهلك واجهة برمجة تطبيقات ERPNext أفضل:
8. الخيار الأول: صفحات ويب ERPNext - تطوير نماذج ويب مخصصة داخل ERPNext (using Jinja/HTML and the Frappe framework) للبحث عن الرحلات وإدخال تفاصيل الركاب. تتفاعل هذه النماذج مع Python من جانب الخادم (via form actions or REST calls) لإنشاء حجوزات في ERPNext. هذا يبقي كل شيء في نظام واحد ولكنه يتطلب تطوير واجهة أمامية في Frappe.
9. الخيار الثاني: تطبيق ويب خارجي - (e.g. a Vue.js or React single-page app) لموقع شركة الطيران الذي يستدعي واجهة برمجة تطبيقات REST الخاصة بـ ERPNext. هذا يفصل بين الاهتمامات: يمكن استضافة موقع الويب على شبكة توصيل المحتوى، ويتواصل مع ERPNext عبر HTTPS للعمليات الديناميكية. على سبيل المثال، على بوابة الويب، يختار المستخدم الرحلات ويدخل معلومات الركاب؛ عند الدفع، يستدعي تطبيق الويب نقطة نهاية API في ERPNext لإنشاء الحجز ثم يوجه المستخدم إلى الدفع.
10. في كلتا الحالتين، يعد الأمان أمرًا بالغ الأهمية - استخدم مفاتيح API/OAuth لتطبيق الويب للمصادقة على ERPNext، وتأكد من تحديد المعدل والتحقق من صحة الإدخال لحماية الواجهة الخلفية.
11. بوابات الإدارة والوكلاء: إلى جانب الواجهات التي تواجه العملاء، يمكننا نشر بوابات ويب للاستخدام الداخلي أو للشركاء:
12. بوابة العمليات (possibly just using ERPNext Desk UI for internal staff) لإدارة الرحلات والجداول والعمليات غير المنتظمة. هذه هي في الأساس واجهة مكتب ERPNext مع الأذونات المناسبة، وربما مع بعض عروض لوحة المعلومات المخصصة للتحكم في العمليات (e.g. a Gantt chart of flights or a real-time summary of delays).
13. بوابة وكيل السفر: إذا كانت شركة الطيران تعمل مع وكالات سفر تابعة لجهات خارجية أو عملاء من الشركات مباشرة، فقم بتزويدهم بواجهة ويب مقيدة لإجراء الحجوزات وإدارة الحجوزات. يمكن تحقيق ذلك باستخدام ميزة البوابة (Portal) في ERPNext حيث يمكن للمستخدمين الخارجيين (with portal user roles) الحصول على عرض محدود لإنشاء وعرض الحجوزات المرتبطة بهم. بدلاً من ذلك، تطبيق ويب خارجي مبسط للوكلاء مع بيانات اعتماد تسجيل الدخول التي تستدعي واجهة برمجة تطبيقات ERPNext (على غرار موقع الحجز الرئيسي، ولكن مع ميزات إضافية مثل الأسعار المتفاوض عليها، الحجز بالدين، إلخ).
14. بوابة الخدمة الذاتية للموظفين: الاستفادة من بوابة الويب المدمجة في ERPNext للموظفين لتقديم طلبات الإجازات، عرض كشوف المرتبات، تقديم النفقات، وما إلى ذلك. تأتي صفحات البوابة لهذه الأمور في الغالب مدمجة مع وحدة الموارد البشرية في ERPNext (بمجرد أن يكون لدى الموظف حساب مستخدم ودور مناسب).
15. تكاملات أنظمة الجهات الخارجية: قد يتم تقديم بعض الوظائف بواسطة أنظمة خارجية متخصصة أو خدمات مصغرة (microservices)، والتي ندمجها حسب الحاجة:
16. إذا كنت تستخدم نظام إدارة إيرادات (Revenue Management System) منفصل للعائد (yield (dynamic pricing)) أو نظام جدولة طاقم (Crew Scheduling system) متخصص، فيمكننا تطوير موصلات تزامن البيانات بين ERPNext وتلك الأنظمة (على سبيل المثال، تصدير بيانات الرحلات والحجوزات إلى أداة إدارة الإيرادات، أو استيراد نتائج جدول الطاقم إلى موارد بشرية ERPNext). يمكن أن تكون هذه الموصلات عبارة عن برامج نصية Python صغيرة أو خدمات Node.js تستخدم واجهات برمجة التطبيقات على كلا الجانبين. من أجل الصيانة، ستكون مشاريع منفصلة ولكنها تشترك في نفس قاعدة البيانات أو تتواصل من خلال webhooks/API.
17. يجب تحديد مشاريع التكامل بوضوح (مع مستودع الشفرة الخاص بها) واستخدام خطافات ERPNext المقدمة حيثما أمكن ذلك. على سبيل المثال، يدعم ERPNext webhooks - يمكننا تكوين ERPNext لإرسال حدث webhook كلما تم إجراء حجز أو تغيير حالة الرحلة[4]. يمكن لخدمة استماع (منشورة خارجيًا) التقاطها ثم تنفيذ إجراءات مثل إخطار نظام خارجي أو تحديث ذاكرة التخزين المؤقت على موقع الويب.

باختصار، سيعمل ERPNext كـ "العقل" الخلفي (backend “brain”) بينما توفر البرامج الإضافية واجهات سهلة الاستخدام ومعالجة متخصصة. بفضل التصميم الذي يركز على واجهة برمجة التطبيقات (API-first design) في ERPNext، يكون التكامل مباشرًا: يمكن للمطورين إجراء عمليات CRUD على أي DocType عبر استدعاءات REST واستخدام المصادقة القائمة على الرموز للأمان[4]. تضمن هذه البنية أن التحسينات على تطبيقات الواجهة الأمامية لا تتطلب تغيير جوهر ERPNext، ويمكن أن تعمل واجهات أمامية متعددة (mobile, web, third-parties) بالتوازي مع نفس البيانات المركزية. من خلال تطوير هذه الوحدات/التطبيقات بشكل منفصل، نحافظ على فصل واضح بين الاهتمامات، مما يجعل النظام أكثر قابلية للتطوير والصيانة.

التواصل متعدد القنوات: دمج ClefinCode Chat

لتوفير اتصالات موحدة في الوقت الفعلي للركاب والموظفين، سنقوم بدمج ClefinCode Chat كمنصة متعددة القنوات. ClefinCode Chat هو حل دردشة أعمال قائم على Frappe/ERPNext يقدم رسائل وسائط متعددة وتكاملًا سلسًا مع ERPNext[5][5]. كتطبيق مستضاف ذاتيًا يمكن تثبيته على منصة ERPNext، سيعمل كمركز مراسلة مركزي:

1. منصة مراسلة موحدة: يدعم ClefinCode Chat الرسائل المباشرة والمحادثات الجماعية (direct messages and group conversations)، ومشاركة الملفات (images, videos, documents)، وحتى المقاطع الصوتية (voice clips)[5]. هذا يعني أنه سواء كان طيارًا يحتاج إلى الإبلاغ عن مشكلة للصيانة، أو راكبًا يرسل استفسارًا للدعم، يمكن التعامل مع كل ذلك داخل نظام دردشة واحد. سنقوم بإعداد قنوات مثل:
2. دردشة دعم الركاب: يمكن للعملاء بدء الدردشة من تطبيق الجوال أو موقع الويب (أداة دردشة مدمجة) للمساعدة في الحجوزات أو معلومات الرحلة. ستظهر هذه المحادثات لوكلاء دعم شركة الطيران في قناة دعم ClefinCode Chat، ربما باستخدام ميزة "مراسلة الضيوف عبر بوابة الويب" (guest messaging via website portal)[5]. يمكن للوكلاء الرد في الوقت الفعلي، وحتى مشاركة بطاقات الصعود إلى الطائرة أو الإيصالات من خلال دعم الوسائط المتعددة.
3. دردشة الفريق الداخلية: إنشاء قنوات جماعية للفرق التشغيلية (e.g. a flight’s crew group, or all ground staff at an airport). يمكن لمديري العمليات نشر التحديثات الهامة (مثل “Flight XX123 diverted to alternate airport”) وستصل فورًا إلى جميع أعضاء المجموعة على أجهزتهم.
4. إشعارات البث: بدلاً من الرسائل النصية القصيرة أو رسائل البريد الإلكتروني التقليدية، يمكن إرسال إشعارات بتغييرات الجدول الزمني، أو تخصيصات البوابات، أو تنبيهات الطوارئ عبر ClefinCode Chat إلى المستخدمين المعنيين. على سبيل المثال، يمكن دفع إشعار تأخير كرسالة دردشة لجميع ركاب تلك الرحلة (يمكن لتطبيق الدردشة إرسال إشعارات فورية إلى هواتف المستخدمين)، مع النشر في نفس الوقت في قناة داخلية لتوعية الموظفين.
5. تكامل متعدد القنوات: يوفر ClefinCode Chat التكامل مع قنوات خارجية مثل WhatsApp لتوسيع نطاق الوصول[6]. يمكننا تكوين ملفات تعريف WhatsApp (على سبيل المثال، رقم WhatsApp للأعمال للدعم) بحيث:
6. يمكن للركاب اختيار تلقي التحديثات على WhatsApp - سيقوم النظام بإعادة توجيه رسائل الدردشة (مثل تذكيرات الصعود أو تغييرات الجدول الزمني) إلى WhatsApp الخاص بهم عبر الملف الشخصي المدمج[6].
7. يمكن لوكلاء الدعم الرد على استفسارات WhatsApp من داخل واجهة الدردشة في ERPNext، مما يوحد الاتصالات. هذا يلغي الحاجة إلى التعامل المنفصل مع WhatsApp web أو الهاتف - جميع الرسائل الواردة/الصادرة مركزية.
8. يمكن توصيل قنوات أخرى مثل الرسائل النصية القصيرة أو البريد الإلكتروني عن طريق كتابة محولات صغيرة أو استخدام قابلية توسيع ClefinCode Chat. على سبيل المثال، يمكن أن يؤدي تنبيه أمني عاجل إلى قيام الدردشة بإرسال رسالة نصية قصيرة إلى الأمن المناوب إذا كانوا غير متصلين بالإنترنت.
9. تكامل ERPNext: نظرًا لأن ClefinCode Chat مبني على إطار عمل Frappe ومصمم خصيصًا للتكامل مع ERPNext، فيمكنه الارتباط بأحداث ERP. على سبيل المثال، عند تسجيل تأخير رحلة في ERPNext (تغيير نوع مستند حالة الرحلة)، يمكن لبرنامج نصي خادم مخصص إنشاء رسالة تلقائيًا في قناة دردشة الركاب لتلك الرحلة، مما يضمن النشر الفوري للتحديث. وعلى العكس من ذلك، يمكن للمحادثات تشغيل إجراءات ERPNext - على سبيل المثال، (e.g. if a passenger sends “Cancel my booking” in chat)، يمكن للوكيل أن يكون لديه أمر اختصار يؤدي إلى تشغيل سير عمل الإلغاء في ERPNext. الواجهة الخلفية لـ ClefinCode مفتوحة وقابلة للتخصيص، مما يسمح بمثل هذا التكامل العميق[5]. إنه يعمل بشكل فعال كملحق لـ ERPNext: يتم تثبيت تطبيق الدردشة على نفس الخادم، ويشارك قاعدة البيانات أو لديه مجموعات مرتبطة، مما يتيح المراسلة المدركة للسياق (مثل الإشارة إلى سجل حجز في محادثة دردشة).
10. الإشعارات والتعاون في الوقت الفعلي: باستخدام ClefinCode Chat، نوفر تعاونًا في الوقت الفعلي (real-time collaboration) عبر شركة الطيران. يمكن للطيارين مشاركة صور لمشكلة صيانة مع الهندسة، ويمكن للموظفين الأرضيين التنسيق عبر الدردشة الجماعية أثناء العمليات غير المنتظمة، ويمكن للإدارة الحصول على نظرة عامة على المحادثات الرئيسية. تقلل الواجهة البديهية من جهد التدريب للتبني[5]. علاوة على ذلك، يقدم ClefinCode Chat تطبيقات جوال (mobile apps) على Google Play و App Store[5]، بحيث يمكن لجميع المستخدمين البقاء على اتصال أثناء التنقل. هذا يعني أن مضيفة الطيران يمكنها تلقي إشعار فوري حول تغيير البوابة أثناء وجودها في حافلة المطار، أو يحصل الراكب على تنبيه حول معلومات حزام الأمتعة كرسالة دردشة عند الهبوط.
11. الأمان والخصوصية: سنقوم بتكوين إعدادات الخصوصية المناسبة في الدردشة - تظل المجموعات الداخلية سرية، وتسمح محادثات الضيوف (الركاب) (guest (passenger) chats) لهم فقط برؤية محادثاتهم الخاصة. يدعم ClefinCode Chat إدارة الخصوصية وحدود التعاون[5]. جميع الاتصالات على خوادمنا (since it’s self-hosted)، وهو أمر مهم لحماية البيانات. نتجنب استخدام تطبيقات المستهلكين بشكل منفصل وبالتالي نحتفظ بالسيطرة وسجلات الاتصالات.

يضمن استخدام ClefinCode Chat كحل متعدد القنوات اتصالات متسقة عبر جميع القنوات وأصحاب المصلحة. إنه يحل محل أو يدمج البريد الإلكتروني والرسائل النصية القصيرة و WhatsApp والمراسلة داخل التطبيق بنظام واحد متماسك. والنتيجة هي أن الركاب يختبرون تحديثات في الوقت المناسب على الوسيط المفضل لديهم، ويتعاون الموظفون بكفاءة، ويتم تسجيل جميع التفاعلات في نظام ERPNext للمساءلة. هذا يحسن الاستجابة وجودة الخدمة بشكل كبير، ويحول الاتصالات إلى أصل مُدار بدلاً من عملية مخصصة.

الحجز والإلغاء والتغيير وتسجيل صعود الركاب

تعد إدارة رحلة الراكب - من الحجز الأولي إلى الصعود إلى الطائرة (onboarding) - في صميم حل ERPNext لشركات الطيران. يتطلب هذا تصميمًا دقيقًا لسير العمل داخل ERPNext والتكامل مع الخدمات الخارجية (مثل أنظمة التوزيع العالمية وبوابات الدفع) لمحاكاة قدرات أنظمة خدمات الركاب التجارية (PSS). العمليات الرئيسية وكيفية تنفيذها موضحة أدناه:

1. سير عمل البحث عن الرحلات والحجز: يبحث الركاب (أو الوكلاء) عن الرحلات حسب التاريخ والمسار وما إلى ذلك، ويختارون رحلة، ويختارون المقاعد، ويدفعون ثمن التذاكر. في ERPNext، سيتم الاستعلام عن جداول الرحلات (من نوع مستند Flight المخصص) عبر تطبيقات الويب/الجوال الخاصة بنا. بمجرد إجراء الاختيار:
2. إنشاء الحجز: يقوم النظام بإنشاء سجل حجز (booking record) (إما أمر مبيعات أو نوع مستند Reservation مخصص) يلتقط تفاصيل الرحلة والراكب والمقعد والسعر. يحتفظ هذا الحجز المؤقت بالمخزون (المقاعد) لفترة قصيرة أثناء اكتمال الدفع. قد ننفذ انتهاء صلاحية قصيرًا (PNR time limit) إذا لم يكن الدفع فوريًا.
3. تكامل الدفع: تكامل بوابة الدفع أمر بالغ الأهمية لتجربة حجز سلسة. يمكن لـ ERPNext التكامل مع بوابات الدفع الشائعة مثل Stripe، PayPal، Braintree، Razorpay، إلخ، من خلال تطبيقات التكامل الحالية[7]. سنقوم بتكوين بوابة دفع (أو عدة بوابات، حسب المناطق) بحيث عندما ينقر الراكب على "ادفع"، يقوم النظام إما بإعادة التوجيه إلى صفحة الدفع المستضافة للبوابة أو يستخدم واجهة برمجة تطبيقات لشحن البطاقة. عند الدفع الناجح، سيقوم رد الاتصال من البوابة (webhook) بإعلام ERPNext، أو سيؤكد التطبيق الحالة عبر واجهة برمجة التطبيقات[7]. يتم بعد ذلك تأكيد سجل الحجز في ERPNext (يتم تقديم أمر المبيعات وتحويله إلى فاتورة مبيعات تمثل تذكرة مدفوعة). يتم تسجيل إدخالات الدفع وربطها بالفاتورة تلقائيًا عن طريق التكامل.
4. إصدار التذكرة: بمجرد الدفع، يصدر النظام تذكرة إلكترونية/سجل اسم راكب (PNR). يمكن القيام بذلك عن طريق إنشاء رمز PNR فريد (e.g. 6-digit alphanumeric) وتحديث سجل الحجز بحالة التذكرة. إذا كان هناك تكامل مع نظام توزيع عالمي (GDS)، فسيؤكد النظام في هذه المرحلة أيضًا الحجز في GDS. ومع ذلك، إذا كان ERPNext هو نظام السجل الأساسي، فسيقوم بإنشاء خط سير الرحلة والإيصال. يمكن إرسال بريد إلكتروني (ورسالة دردشة) مع التذكرة الإلكترونية (PDF أو التفاصيل) إلى الراكب، وهو ما يمكن لـ ERPNext القيام به عبر ميزات الإشعارات/تنبيهات البريد الإلكتروني الخاصة به.
5. تكامل نظام التوزيع العالمي (GDS): عادةً ما تعرض شركات الطيران متكاملة الخدمات مخزونها على أنظمة التوزيع العالمية (GDS) مثل Amadeus أو Sabre أو Travelport حتى يتمكن وكلاء السفر ووكالات السفر عبر الإنترنت (OTAs) من حجز رحلاتهم[8][8]. لدعم هذا:
6. تنفيذ برنامج وسيط للتكامل (integration middleware) يتواصل بين ERPNext و GDS. على سبيل المثال، عند إنشاء جدول رحلات جديد أو تحديثه في ERPNext، يمكن إرسال رسالة API أو رسالة مستندة إلى ملف إلى GDS لتحديث المخزون. وبالمثل، يجب أن تتدفق الحجوزات التي تتم على GDS مرة أخرى إلى ERPNext بحيث يظهر PNR في نظامنا.
7. تستخدم العديد من GDS بروتوكولات موحدة (some use SOAP/XML, others REST/JSON). قد نستخدم مكتبة طرف ثالث أو واجهة برمجة تطبيقات مباشرة مقدمة من GDS (like Amadeus Web Services, Sabre APIs) للتفاعل. يمكن القيام بذلك عبر تطبيق تكامل مخصص يستمع إلى أحداث ERPNext (مثل إنشاء الرحلة) ويستدعي واجهة برمجة تطبيقات GDS وفقًا لذلك.
8. على العكس من ذلك، قم بإعداد نقاط نهاية webhook (webhook endpoints) في نظامنا لتلقي إشعارات الحجز من GDS (أو الاستقصاء بشكل دوري). على سبيل المثال، إذا حجز وكيل من خلال Amadeus، يتلقى نظامنا تفاصيل PNR وينشئ سجل حجز مقابل داخليًا، مما يقلل من مخزون المقاعد.
9. تعقيد التكامل ليس بسيطًا - ولكنه يضمن أن يظل نظام ERPNext هو التحكم المركزي في المخزون (يعمل بشكل فعال كـ CRS - Computer Reservation System - لشركة الطيران - والذي يستقصيه GDS). الحد الأدنى من البيانات للمزامنة يشمل الرحلات والجداول والأسعار وتوافر المقاعد[8]. سيدير ERPNext هذه الأمور، ويصبح GDS عرضًا خارجيًا. من خلال ربط ERPNext بـ GDS، تستفيد شركة الطيران من توزيع أوسع دون تشغيل أنظمة مخزون منفصلة.
10. تعديل الحجز (Changes): كثيرًا ما يحتاج الركاب إلى تغيير خط سير رحلتهم (date, flight) أو الإلغاء:
11. سنسمح بـ تغيير الرحلات من خلال خدمة العملاء أو الخدمة الذاتية (إذا سمحت القواعد). في ERPNext، يتضمن التغيير تحديث سجل الحجز: على سبيل المثال، تغيير الرحلة المرتبطة وربما فرق السعر. سيعيد منطق العمل حساب السعر/الضرائب، وإما أن ينشئ فاتورة إضافية أو استردادًا. سنفرض قواعد الأسعار (المخزنة في جدول قواعد الأسعار أو قواعد الأجرة) لحساب رسوم التغيير أو القيود.
12. إذا كان الحجز في الأصل عبر GDS، فمن الأفضل إجراء مثل هذه التغييرات من خلال GDS للحفاظ على كل شيء متزامنًا. قد يرسل نظامنا رسالة تعديل إلى GDS وينتظر التأكيد. للحجوزات المباشرة، يتولى ERPNext الأمر وحده.
13. يجب تأريخ جميع التغييرات - ستحتفظ ميزة الإصدار (Version) في ERPNext على المستندات بمسار تدقيق للتعديلات (أو نسجل التغييرات في نوع مستند منفصل)، حتى يكون لدينا سجل بالتفاصيل الأصلية مقابل تفاصيل السفر الجديدة.
14. إعادة الإصدار: بعد تأكيد التغيير (وأخذ أي دفعة إضافية أو إصدار استرداد)، يعيد النظام إصدار التذكرة الإلكترونية ويخطر الراكب.
15. الإلغاءات والاستردادات: عندما يلغي راكب:
16. فرض سياسات الإلغاء الخاصة بشركة الطيران (ربما لا يوجد استرداد على أسعار معينة، أو استرداد محسوب مطروحًا منه الرسوم). يمكن لـ ERPNext تخزين شروط الأسعار لكل تذكرة، والتي يمكن لبرنامج نصي للخادم استخدامها لحساب مبلغ الاسترداد والإطار الزمني للأهلية.
17. تنفيذ سير عمل الإلغاء (cancellation workflow): على سبيل المثال، يطلب الراكب الإلغاء عبر البوابة أو يتصل بالدعم، ويقوم وكيل بتعيين حالة الحجز على "طلب الإلغاء". ثم يقوم النظام بتشغيل أي موافقة مطلوبة (قد لا تكون ضرورية للحالات البسيطة) ويعالج استردادًا من خلال واجهة برمجة تطبيقات بوابة الدفع (إذا كان ضمن الوقت المسموح به). سيتم إجراء إدخال الدفع في ERPNext للاسترداد، ويمكن تعديل فاتورة المبيعات أو إصدار إشعار دائن لموازنة الحسابات.
18. إذا تم إلغاء رحلة من قبل شركة الطيران (إلغاء تشغيلي)، فقد نقوم بإلغاء جميع الحجوزات على تلك الرحلة دفعة واحدة. في مثل هذه الحالات، يمكن لسير العمل الإضافي مساعدة الوكلاء في إعادة حجز الركاب على رحلات بديلة أو إصدار قسائم. سيقوم النظام بتمييز تلك التذاكر على أنها ملغاة وتتبع حالة التعويض أو إعادة الحجز لكل راكب.
19. تسجيل الوصول والصعود إلى الطائرة: يشير الصعود إلى الطائرة (Onboarding) هنا إلى العملية من تسجيل الوصول إلى الصعود إلى الطائرة (from check-in to boarding the aircraft):
20. تسجيل الوصول: سنقوم بتنفيذ وحدة تسجيل وصول إما كجزء من ERPNext أو تطبيق خارجي خفيف الوزن يغذي ERPNext. عندما يقوم راكب بتسجيل الوصول (عبر تطبيق الجوال أو في الكاونتر)، يجب على النظام تمييز سجل اسم الراكب (PNR) على أنه تم تسجيل وصوله وتعيين مقعد (إذا لم يتم اختياره مسبقًا). يمكن إنشاء بطاقة صعود (Boarding Pass) - تحتوي على معلومات الرحلة، والمقعد، والبوابة/وقت الصعود، ورمز شريطي/رمز استجابة سريعة (barcode/QR code). يمكننا إنشاء هذا كملف PDF أو صورة؛ يمكن لـ ERPNext إنتاج تقارير PDF، لذا يمكن إنشاء تنسيق طباعة مخصص لبطاقة الصعود وإرسالها بالبريد الإلكتروني إلى الراكب أو إتاحتها في التطبيق.
21. إذا تم استخدام أكشاك أو كاونتر لتسجيل الوصول، يمكن للموظفين استخدام واجهة مكتب ERPNext أو نموذج ويب مبسط لاسترداد الحجز (by PNR or passenger name) وتشغيل تسجيل الوصول. يمكن أن يغير هذا حالة في نوع مستند الحجز وينتج إخراج بطاقة الصعود.
22. سيسمح تطبيق الجوال للركاب بتسجيل وصولهم بأنفسهم للرحلات المؤهلة: استدعاء واجهة برمجة تطبيقات تحدد حالة تسجيل الوصول وتعيد بطاقة صعود (ربما كصورة base64 أو رابط PDF).
23. تسليم الأمتعة وبطاقات الأمتعة: أثناء تسجيل الوصول، إذا كان سيتم فحص الأمتعة، يمكن للنظام تسجيل عدد الحقائب والوزن في سجل اسم الراكب (PNR). قد نتكامل مع طابعة بطاقات الأمتعة لطباعة الملصقات - يمكن أن ينتج هذا ببساطة رقم ملصق يدخله الموظفون في نظام أمتعة المطار، ما لم تستخدم شركة الطيران نظامها الخاص لتتبع الأمتعة (سيتم تناوله لاحقًا تحت عنوان الخدمات اللوجستية).
24. الصعود إلى الطائرة: عند البوابة، سيقوم الموظفون بمسح بطاقة الصعود (يمكن إجراء مسح الرمز الشريطي/رمز الاستجابة السريعة (barcode/QR scanning) عبر تطبيق الجوال للموظفين أو واجهة ويب مع ماسح ضوئي محمول). سيؤدي مسح الرمز إلى البحث عن سجل تسجيل وصول الراكب في ERPNext وتمييزه على أنه "صعد إلى الطائرة" (“Boarded”). سنضمن التحديث في الوقت الفعلي حتى لا يتمكن الراكب من استخدام نفس البطاقة مرتين أو بطاقة ملغاة.
25. إذا لزم الأمر، التكامل مع نظام الصعود إلى الطائرة في المطار: بعض المطارات لديها نظامها المركزي الخاص لمطابقة الصعود. يمكننا تصدير قائمة ركاب الرحلة مع حالة تسجيل الوصول إلى نظام المطار، أو ببساطة استخدام نظامنا بشكل مستقل إذا كانت عملية أصغر.
26. التخلف عن الحضور: بعد المغادرة، أي راكب لم يتم تمييزه على أنه صعد إلى الطائرة يعتبر "متخلفًا عن الحضور". يمكن لسجل ERPNext التقاط ذلك (يمكنه تعيين الركاب الذين سجلوا وصولهم ولكن لم يصعدوا إلى الطائرة تلقائيًا إلى حالة التخلف عن الحضور). تغذي هذه البيانات التقارير للمحاسبة عن الإيرادات (الإيرادات المفقودة، إمكانية استرداد الضرائب، إلخ، نظرًا لأن تذاكر المتخلفين عن الحضور قد يكون لها معاملة محاسبية معينة).
27. الخدمات على متن الطائرة: كجزء من الصعود إلى الطائرة، ضع في اعتبارك دمج أي مهام صعود إلى الطائرة أثناء الرحلة - على سبيل المثال، إذا تم استخدام بوابات إلكترونية للصعود، فقد تكون هذه خارج النطاق. ولكن يمكن للمرء التكامل مع نظام أثناء الرحلة لإرسال بيان نهائي من ERPNext بمجرد إغلاق الرحلة.
28. الحالات الخاصة: يجب أن يتعامل النظام مع سيناريوهات مختلفة مثل:
29. حجوزات الخطوط المشتركة أو المشاركة بالرمز: إذا كانت شركة الطيران لديها رحلات شريكة، فقد تتضمن الحجوزات مقاطع على شركات طيران أخرى. في ERPNext، لا يزال بإمكاننا تخزينها كجزء من سجل اسم راكب (PNR) واحد ولكن تمييزها على أنها مقاطع خارجية تحتاج إلى إرسالها إلى نظام شركة الطيران الشريكة. من المحتمل أن يتطلب هذا مراسلة قياسية (like IATA PADIS messages or use of GDS) - ذكر هذا كنقطة تكامل مستقبلية.
30. الترقيات: إدارة الترقيات (المدفوعة أو المجانية). يمكن تنفيذ ترقية راكب إلى درجة رجال الأعمال عن طريق تغيير المقعد/الدرجة في الحجز وإصدار فاتورة بالفرق. يجب على النظام بعد ذلك إخطار التموين والأنظمة الأخرى بتغيير درجة الخدمة.
31. الاستعداد والتحكم في البوابة: يمكن للمنصة الحفاظ على قائمة انتظار للرحلات الممتلئة والسماح لموظفي العمليات باستيعاب الركاب الاحتياطيين. يمكن أن يكون لدى ERPNext نوع مستند بسيط لطلبات الاستعداد مرتبط برحلة، والذي يتم تأكيده في الدقائق الأخيرة إذا توفرت مقاعد.

عند تصميم هذه العمليات، نضمن الاتساق وإمكانية التتبع (consistency and traceability) في ERPNext. لكل حجز دورة حياة من الإنشاء، التعديلات، إلى الإكمال/الإلغاء، ويسجل النظام كل خطوة. من خلال التكامل مع أنظمة التوزيع العالمية (GDS) وأنظمة الدفع، نغطي نقاط الاتصال الخارجية اللازمة لشركة طيران متكاملة الخدمات. ومن خلال بناء عمليات تسجيل الوصول والصعود إلى الطائرة، نوسع ERPNext إلى ما وراء المكتب الخلفي إلى العمليات في الوقت الفعلي في المطار - وهو أمر غير معتاد لنظام تخطيط موارد مؤسسات قياسي، ولكنه قابل للتحقيق مع الوحدات والتطبيقات المخصصة. في النهاية، يختبر الركاب رحلة سلسة (search -> book -> pay -> check-in -> board) مدعومة بنظام ERPNext الذي ينسق في الخلفية.

إدارة الركاب والامتثال التنظيمي

ينطوي السفر الجوي على إدارة صارمة لبيانات الركاب والوفاء باللوائح الدولية المختلفة. سيتضمن حل ERPNext ميزات للتعامل مع تحديد هوية الركاب، والتحقق من المستندات، والامتثال للقوانين الإقليمية (passenger identification, document verification, and compliance with regional laws):

1. ملفات تعريف الركاب الشاملة: كما ذكرنا، سيكون لكل راكب (أو عميل) في نظام ERPNext ملف تعريف يخزن التفاصيل الشخصية ووثائق السفر. وهذا يشمل:
2. معلومات جواز السفر: رقم جواز السفر، بلد الإصدار، تاريخ انتهاء الصلاحية. يمكن تكوين النظام للتنبيه إذا اقترب جواز السفر من انتهاء الصلاحية (مفيد لوكلاء تسجيل الوصول أو حتى إخطار المسافرين الدائمين). يمكننا أيضًا إرفاق نسخة ممسوحة ضوئيًا كمرجع، مخزنة بشكل آمن.
3. التأشيرات ووثائق السفر: بالنسبة لمسارات معينة، قم بتسجيل أرقام التأشيرات أو تصاريح السفر الإلكترونية. على سبيل المثال، إذا كان راكب يسافر إلى الولايات المتحدة الأمريكية، قم بتخزين تفاصيل ESTA أو التأشيرة الخاصة به (ESTA or visa details). إذا كان يسافر إلى بلد يتطلب موافقة مسبقة (مثل ETA الكندي أو ETA الأسترالي)، فقم بتمييز ذلك في سجله.
4. بيانات APIS: تفرض العديد من البلدان إرسال بيانات نظام معلومات الركاب المسبق (APIS) قبل الوصول، والذي يتضمن تفاصيل مثل الاسم الكامل، تاريخ الميلاد، الجنس، الجنسية، معلومات جواز السفر، وعنوان الوجهة لكل مسافر. سيكون نظامنا قادرًا على إنشاء ملف بيان APIS من سجلات الركاب والرحلات لكل رحلة دولية. يمكننا جدولة تقرير آلي أو استخدام برنامج نصي مخصص لتجميع بيانات APIS بعد إغلاق تسجيل الوصول، ثم إرسالها إما عبر تكامل آمن (تقبل بعض البلدان عمليات نقل API، والبعض الآخر عبر البريد الإلكتروني أو بوابة الويب).
5. فحص الرحلات الآمنة وقوائم المراقبة: بالنسبة للرحلات من/إلى بلدان معينة (مثل الولايات المتحدة)، يجب جمع معلومات إضافية مثل بيانات رحلة TSA الآمنة (TSA Secure Flight data (redress number, Known Traveler ID)). سنقوم بتضمين حقول لهذه في الحجز أو ملف تعريف الراكب كما هو مطلوب. على الرغم من أن مطابقة قوائم المراقبة الفعلية قد يتم التعامل معها من قبل الحكومات، يجب أن يكون النظام قادرًا على إرسال البيانات المطلوبة. إذا كانت شركة الطيران تقوم بفحوصات قوائم المراقبة الداخلية، فيمكننا التكامل مع خدمة أو قاعدة بيانات لفحص أسماء الركاب مقابل قوائم معروفة عند الحجز.
6. قواعد العمل الخاصة بالجنسية: ستفرض المنصة قواعد اعتمادًا على جنسية الراكب أو إقامته:
7. على سبيل المثال، إذا حاول راكب يحمل الجنسية X حجز رحلة إلى البلد Y، يمكن للنظام التحقق مما إذا كانت هناك حاجة إلى تأشيرة أو وثيقة خاصة (using IATA’s Timatic database if integrated). في حين أن دمج Timatic (IATA’s travel requirements database) مباشرة قد يكون معقدًا، يمكننا الاشتراك في أداة الويب أو واجهة برمجة تطبيقات Timatic[9]. يمكن أن يسمح هذا لمحرك الحجز أو وحدة تسجيل الوصول لدينا بالتحقق تلقائيًا من متطلبات السفر بناءً على الجنسية والوجهة ونقاط العبور، وإبلاغ الوكلاء إذا كانت المستندات مفقودة[9].
8. قد تكون بعض الجنسيات مقيدة على مسارات معينة؛ يمكن للنظام وضع علامة على مثل هذه الحالات لمنع إصدار التذاكر دون مزيد من الفحوصات.
9. أثناء الحجز أو تسجيل الوصول، قم بدمج التحقق من صحة أرقام المستندات (مثل تنسيق جواز السفر حسب البلد، أو المجاميع الاختبارية لبطاقة الهوية) لتقليل أخطاء الإدخال.
10. الامتثال الإقليمي لخصوصية البيانات: تخزين البيانات الشخصية (PII) يعني أن قوانين مثل GDPR وما شابهها تدخل حيز التنفيذ. يسمح ERPNext بتصدير البيانات وحذفها للامتثال. سنقوم بما يلي:
11. الحصول على موافقة من المستخدمين لتخزين بياناتهم (يمكن أن تتضمن شروط الحجز موافقة الخصوصية).
12. تنفيذ قواعد الاحتفاظ بالبيانات - على سبيل المثال، قد يتم حذف معلومات التعريف الشخصية للراكب أو إخفاء هويتها بعد فترة معينة بعد السفر إذا لم تكن هناك حاجة إليها (تخضع للقوانين المحلية أو سياسة شركة الطيران). يمكن برمجة ERPNext لإخفاء هوية السجلات التي يبلغ عمرها، على سبيل المثال، 7 سنوات (الاحتفاظ الشائع لبيانات السفر بسبب المتطلبات القانونية).
13. التأكد من أن بنية النشر (التي تمت مناقشتها لاحقًا) تأخذ في الاعتبار إقامة البيانات - (e.g. EU customer data stored in EU servers if needed).
14. استخدام أذونات الأدوار في ERPNext لتقييد الوصول إلى البيانات الحساسة فقط لأولئك الذين يحتاجون إليها (على سبيل المثال، يمكن لضباط الأمن فقط رؤية أرقام جوازات السفر، وليس كل موظف).
15. الامتثال الصحي والسلامة: في عالم ما بعد الجائحة، قد تكون هناك وثائق صحية (like vaccination certificates) للتعامل معها. يمكننا إضافة حقول لهذه (مثل حالة التطعيم ضد COVID-19 أو نتائج الاختبار) في قوائم التحقق الخاصة بالركاب، مما يضمن أن عملية تسجيل الوصول تتحقق من المستندات الصحية المطلوبة لمسارات معينة.
16. الإقرارات الحكومية/الجمارك: تحتاج بعض المناطق إلى أن تقدم شركات الطيران بيانات الركاب إلى وكالات الهجرة أو الجمارك (apart from APIS). يجب أن يكون نظامنا مرنًا لإنتاج هذه التقارير. على سبيل المثال، قد يتطلب بلد في الاتحاد الأوروبي نقل بيانات سجل اسم الراكب (PNR) قبل 48 ساعة من الرحلة (EU PNR directive)، والذي يتضمن حتى بيانات الحجز. يمكننا إنشاء تقارير PNR هذه من ERPNext نظرًا لأن جميع الحجوزات موجودة في قاعدة البيانات (قد يكون هذا مهمة دفعية تقوم بتنسيق البيانات بالتنسيق المطلوب XML/EDI).
17. الامتثال القانوني للعمليات: بالإضافة إلى بيانات الركاب، تأكد من سير عمل الامتثال:
18. على سبيل المثال، تتطلب لائحة الاتحاد الأوروبي EC261 تعويض الركاب عن تأخيرات/إلغاءات معينة. يمكن للنظام تحديد الحالات المؤهلة (بناءً على طول التأخير والمسافة) وتشغيل مهمة لفريق رعاية العملاء لمعالجة التعويض. على الرغم من أنها ليست ميزة جاهزة، يمكننا دمج منطق العمل هذا في التقارير أو التنبيهات المخصصة.
19. إذا كانت شركة الطيران تعمل في مناطق ذات لوائح فريدة (like Indian DGCA rules, U.S. DOT rules, etc.)، فإننا ندرجها في إجراءات التشغيل القياسية - على سبيل المثال، التأكد تلقائيًا من عدم وجود أكثر من N ساعة على مدرج المطار (DOT rule) عن طريق تشغيل تنبيهات للمديرين إذا تأخرت المغادرة عن الحد المسموح به.
20. التدقيق وإعداد التقارير: الحفاظ على مسار تدقيق لجميع التغييرات على سجلات الركاب والحجوزات (من أدخل معلومات جواز السفر، من غير حجزًا، إلخ)، وهو ما يفعله ERPNext عبر إصدار المستندات. للاستفسارات التنظيمية أو عمليات التدقيق الداخلية، يجب أن نكون قادرين على إنتاج سجل كامل لسجل اسم الراكب (PNR) أو الراكب. أيضًا، توفير تقارير قياسية مثل:
21. بيان الركاب (Passenger Manifest) لكل رحلة (قائمة بجميع الركاب مع الجنسية، جواز السفر، إلخ) - للموظفين الأرضيين وإذا لزم الأمر للسلطات.
22. تقارير مبيعات التذاكر (Ticket Sales Reports) حسب بلد البيع (لأغراض الضرائب/التقارير).
23. التقارير الأمنية (Security Reports): على سبيل المثال، قائمة بجميع الركاب الذين تم إزالتهم أو منعهم من الصعود إلى الطائرة (في حال طلبتها وكالات أمن الطيران).

من خلال معالجة هذه الجوانب، لن يقوم نظام ERPNext بإدارة البيانات التشغيلية فحسب، بل سيعمل أيضًا كأداة امتثال. إن الطبيعة الدولية لعمليات شركات الطيران مدمجة (international nature of airline operations is built-in): يتم دعم واجهات متعددة اللغات للموظفين والركاب، والمعاملات متعددة العملات، والالتزام بلوائح السفر. بشكل عام، تم تصميم إدارة الركاب في حل ERPNext الخاص بنا ليكون شاملاً وآمنًا (holistic and secure) - من التقاط البيانات الصحيحة، وتوجيه الموظفين من خلال فحوصات الامتثال، إلى حماية تلك البيانات ومشاركتها فقط مع المستلمين المعتمدين.

تخصيص الموارد البشرية وخدمات الموظفين

تتطلب إدارة الموارد البشرية في شركات الطيران متطلبات فريدة، تتراوح من جدولة الطاقم إلى تتبع الشهادات. سيتم تخصيص وتوسيع وحدة الموارد البشرية في ERPNext لتلبية هذه الاحتياجات الخاصة بالطيران:

1. ملفات تعريف الموظفين والمؤهلات: بالإضافة إلى معلومات الموظف القياسية (التفاصيل الشخصية، الاتصال، إلخ)، أضف حقولًا/أنواع مستندات مخصصة لتتبع:
2. الشهادات والتدريب: بالنسبة للطيارين والطاقم، سجل تفاصيل التراخيص (pilot licenses with type ratings, medical certificates, crew attestation for cabin crew) مع تواريخ الإصدار/الانتهاء. يجب أن يرسل النظام تنبيهات عند استحقاق التجديدات. سجل أيضًا إكمال التدريب الإلزامي (تدريب السلامة، خدمة العملاء، إلخ). يمكننا استخدام وحدة التدريب في ERPNext أو إنشاء نوع مستند للشهادات (ERPNext’s Training module or create a Certification doctype) مرتبط بالموظف.
3. جواز السفر/التأشيرة للطاقم: نظرًا لأن الطاقم يسافر دوليًا، قم بتخزين جوازات سفرهم وأي تأشيرات أو تصاريح عمل. يرتبط هذا بالجدولة (على سبيل المثال، لا تقم بجدولة طاقم إلى بلد لا تكون فيه تأشيرته صالحة). يمكن تنفيذ عمليات فحص آلية للتحذير إذا كانت مستندات أحد أفراد الطاقم ستكون غير صالحة في رحلة مخططة.
4. سجلات صحة وسلامة الطاقم: تتبع أشياء مثل عدد ساعات الطيران في الفترات الأخيرة (للامتثال لقيود وقت الطيران)، وأي تورط في حادث/حادثة (لمتابعة قسم السلامة). يمكن أن تكون هذه حقولًا بسيطة أو مرتبطة بوحدة الإبلاغ عن الحوادث.
5. جدولة الطاقم وتوزيع المهام: ربما يكون الجانب الأكثر أهمية في الموارد البشرية لشركات الطيران هو بناء جداول الطاقم التي تفي بمتطلبات الراحة القانونية وتغطي الرحلات:
6. إنشاء أداة جدول أو تعيين مناوبات (Roster or Shift Assignment) داخل ERPNext. يحتوي ERPNext على ميزة جدول المناوبات التي يمكننا تكييفها: تحديد "واجب الطيران" كنوع مناوبة. سنقوم بإنشاء تعيينات مناوبات لكل فرد من أفراد الطاقم تتوافق مع الرحلات التي يقومون بتشغيلها. قد نحتاج إلى واجهة مستخدم أو تقرير مخصص لتصور الجداول (like a calendar or Gantt chart per crew). يمكن أن تكون هذه صفحة مخصصة في تطبيق Frappe الخاص بنا.
7. تنفيذ القواعد: التأكد من أن الطيارين وطاقم الطائرة لديهم راحة كافية بين الواجبات (على سبيل المثال، 12 ساعة بين الواجبات، أو حسب اللوائح) - يجب على النظام الإبلاغ عن الانتهاكات إذا حاول المجدول تعيين شخص في تعارض. تحقق أيضًا من الساعات التراكمية (على سبيل المثال، لا تتجاوز 100 ساعة في 28 يومًا للطيارين، إلخ، حسب اللوائح).
8. ضع في اعتبارك دمج محرك تحسين أو خوارزمية لبناء جداول شهرية. في المراحل الأولية، قد يتم استخدام الجدولة اليدوية أو شبه اليدوية عبر ERPNext، مع فرض النظام للقواعد. في المستقبل، يمكن أن يؤدي التكامل مع نظام جدولة طاقم متخصص أو استخدام مكتبة حل القيود إلى أتمتة إنشاء الجداول التي تغذي بعد ذلك ERPNext.
9. إدارة التبادل/التغيير: توفير سير عمل للطاقم لطلب تبادل المناوبات أو التخلي عنها. على سبيل المثال، يمكن لاثنين من أفراد الطاقم طلب تبادل يذهب إلى مدير للموافقة عليه في ERPNext. إذا تمت الموافقة، يتم تحديث تعيينات الجدول وفقًا لذلك.
10. الإشعارات: يحصل الطاقم على جدولهم من خلال تطبيق الجوال للموظفين (أو عبر البريد الإلكتروني من ERPNext). أي تغييرات في الجدول تدفع الإشعارات (عبر ClefinCode Chat أو البريد الإلكتروني). إذا تأخرت رحلة بشكل كبير أو ألغيت، يجب تنبيه الطاقم حتى لا يظهروا دون داعٍ أو يمكن إعادة تعيينهم.
11. عمليات الموارد البشرية للموظفين الأرضيين: ليس فقط طاقم الطيران، ولكن يمكن أيضًا إدارة الموظفين الأرضيين (وكلاء تسجيل الوصول، موظفو البوابة، عمال تحميل المنحدرات). يعمل الكثير منهم في مناوبات. يمكننا استخدام نوع المناوبة (Shift Type) وتعيين المناوبة (Shift Assignment) في ERPNext لهذه الأدوار. يمكن للنظام إنشاء جداول مناوبات يومية لموظفي المطار والسماح للمديرين بإجراء تعديلات. من خلال وجود هذا في ERPNext، يمكن ربط كشوف المرتبات والحضور مباشرة (انظر أدناه). سنقوم بتكييف وحدة الحضور إذا كان الموظفون يستخدمون أنظمة القياسات الحيوية أو التمرير عن طريق استيراد تلك البيانات.
12. الإجازات والحضور: تحتوي الموارد البشرية في ERPNext على إدارة الإجازات - سيتم استخدامها لجميع الموظفين. سنقوم بإنشاء أنواع إجازات محددة (إجازة سنوية، إجازة مرضية، مبيت/راحة إذا لزم الأمر لتسجيل فترات الراحة). غالبًا ما يكون لدى الطاقم جداول سفر معقدة، لذا فإن تسجيل وقت واجبهم الفعلي مقابل وقت الراحة مهم. من الممكن التكامل مع بيانات الرحلة بحيث أنه بعد إغلاق الرحلة، يتم تسجيل فترة الواجب تلقائيًا على أنها "ساعات عمل" لهؤلاء الطاقم، والتي يمكن أن تغذي حسابات العمل الإضافي أو فقط للسجلات.
13. استخدام وحدة الحضور (Attendance) إما مع وضع علامات يدوية من قبل الطاقم عبر الخدمة الذاتية أو الاستيراد من نظام تسجيل الوصول. نظرًا لأن الطاقم قد لا "يسجل الدخول/الخروج" تقليديًا، فإن أوقات مغادرة/وصول الرحلة تحدد بشكل أساسي ساعات عملهم - يمكننا إنشاء إدخالات حضور تلقائيًا بناءً على الرحلات التي تم تشغيلها.
14. كشوف المرتبات والمصروفات: لدى شركات الطيران هياكل أجور متنوعة (flying hours pay, per diem allowances, etc.):
15. سنقوم بتكوين هياكل الرواتب (Salary Structures) في ERPNext لكل دور. بالنسبة للطيارين وطاقم الطائرة، قم بتضمين مكونات لأجر ساعة الطيران (والتي يمكن حسابها من الرحلات التي قاموا بتشغيلها - ربما باستخدام حسابات رواتب إضافية عبر برنامج نصي كل شهر). يسمح ERPNext بصيغ كشوف رواتب مخصصة، لذا يمكننا جلب إجمالي ساعات الطيران من بيانات الجدول إلى معالجة كشوف المرتبات.
16. تضمين البدلات اليومية (Per Diems): لكل رحلة أو مبيت، قد يحصل الطاقم على بدلات. يمكننا إدارة ذلك عبر مطالبة المصروفات أو دمجها في كشوف المرتبات عن طريق حساب البدلات بناءً على سجلات سفر الواجب. يمكن استخدام مطالبة المصروفات في ERPNext إذا قدم الطاقم مطالبات للوجبات أو النقل أثناء السفر، مع سير عمل الموافقة المناسب.
17. كشوف المرتبات متعددة البلدان: إذا كانت شركة الطيران لديها قواعد في بلدان متعددة، فسيكون لكل منها قواعد ضريبية مختلفة. يمكن لـ ERPNext التعامل مع تكوينات كشوف رواتب متعددة وحتى عملات متعددة للراتب إذا لزم الأمر (للموظفين المحليين في بلدان مختلفة).
18. سلفة الموظف وحجز السفر: تحتوي الموارد البشرية في ERPNext على ميزات طلب السفر والسلفة - على سبيل المثال، إذا سافر الموظفون الأرضيون للتدريب، فيمكنهم طلب ذلك من خلال ERPNext ويمكن أن يرتبط بالنظام لحجز سفرهم بالفعل (على سبيل المثال، حتى الرحلات على شركة الطيران الخاصة بهم يمكن حجزها داخليًا بتكلفة صفرية عبر عملية داخلية).
19. الخدمة الذاتية للموظفين: تمكين بوابة الموظفين (Employee Portal) حتى يتمكن الموظفون من تسجيل الدخول لرؤية كشوف المرتبات، وتقديم طلبات الإجازات، وما إلى ذلك. هذا يقلل من العبء الإداري على قسم الموارد البشرية. سنقوم بتخصيص صفحات البوابة لتشمل أشياء مثل جدول عضو الطاقم القادم، أو رابط لأخبار الشركة، إلى جانب خيارات الخدمة الذاتية القياسية.
20. التدريب والامتثال: يجب على شركات الطيران التأكد من أن جميع الموظفين لديهم تدريب محدث (safety refreshers, customer service, etc.) وأحيانًا اختبارات تنظيمية.
21. استخدام وحدة التدريب (Training module) في ERPNext لجدولة الدورات التدريبية (e.g., annual safety recurrent training for cabin crew). تسجيل الموظفين وتتبع إكمالهم للدورات.
22. الحفاظ على مصفوفة توضح من يحتاج إلى أي تدريب وحالتهم (this could be a custom report or Doctype).
23. بالنسبة لعمليات التدقيق التنظيمية، يمكن إنتاج تقارير تظهر الامتثال بسهولة (e.g. “100% of pilots have done their simulator check in the last 6 months”).
24. التنسيق التشغيلي: يمكن لنظام الموارد البشرية أيضًا تسهيل التنسيق مع الاضطرابات التشغيلية. على سبيل المثال، إذا تأخرت رحلة أو أبلغ أحد أفراد الطاقم عن مرضه، يجب أن يسمح النظام بإعادة التعيين السريع. يمكننا دمج ميزة للعثور على طاقم احتياطي متاح. يمكن أن يحتوي سجل الموظف الرئيسي على علامة "واجب احتياطي" (“Reserve Duty”) لأيام معينة، بحيث يمكن للعمليات البحث عن من هو في الخدمة الاحتياطية وإرسال إشعارات لهم عبر الدردشة إذا لزم الأمر. يمكن لنظام التصفية ووضع العلامات في ERPNext المساعدة هنا (e.g., tag some employees as #reserve on a date).

من خلال تخصيص الموارد البشرية في ERPNext بهذه الطرق، نضمن أن الموارد البشرية والعمليات متكاملة بإحكام. تغذي جدولة الطاقم وعمليات الطيران قسم الموارد البشرية لكشوف المرتبات والامتثال، وتغذي بيانات الموارد البشرية (like certifications or availability) العمليات مرة أخرى لاتخاذ قرارات الجدولة. يسمح مخطط ERPNext المفتوح بكل هذه الروابط (e.g., linking an Employee to a Flight as part of crew assignment) دون الإخلال بالنظام. ينتج عن هذا النهج المتكامل الكفاءة - عدد أقل من الأنظمة المستقلة وجداول البيانات - ويضمن إدارة موظفي شركة الطيران بنفس الدقة التي تدار بها شؤونها المالية.

المحاسبة والإدارة المالية

تعتبر الإدارة المالية لشركة طيران معقدة، حيث تشمل تدفقات إيرادات متعددة، ومعاملات كبيرة الحجم، وعمليات متعددة العملات. سيتم تكوين وتوسيع وحدة المحاسبة في ERPNext لتلبية هذه الاحتياجات، مما يضمن الامتثال للمعايير المحاسبية وتوفير الوضوح بشأن الربحية:

1. تخصيص دليل الحسابات: تصميم دليل حسابات مصمم خصيصًا لعمليات شركات الطيران. وهذا يشمل:
2. حسابات الإيرادات لتدفقات مختلفة: إيرادات تذاكر الركاب (Passenger Ticket Revenue)، إيرادات الشحن (Cargo Revenue)، رسوم الأمتعة (Baggage Fees)، المبيعات على متن الطائرة (Onboard Sales)، وما إلى ذلك، مما يسمح بتقارير مالية مفصلة. قد نقوم بتقسيم إيرادات الركاب بشكل أكبر حسب الدرجة (Economy, Business) باستخدام رؤوس الحسابات أو الأبعاد.
3. حسابات المصروفات لفئات التكلفة الرئيسية: الوقود (Fuel)، رواتب الطاقم (Crew Salaries)، تأجير الطائرات (Aircraft Leasing)، الصيانة (Maintenance)، التموين (Catering)، رسوم المطار (Airport Fees)، تكاليف المبيعات/التوزيع (Sales/Distribution Costs (including commissions to agents or GDS fees))، إلخ.
4. الإيرادات غير المكتسبة (الإيرادات المؤجلة): يجب الاحتفاظ بالتذاكر المباعة للسفر المستقبلي في الميزانية العمومية كالتزام حتى تحدث الرحلة بالفعل (ثم يتم الاعتراف بها كإيرادات). يمكن لـ ERPNext التعامل مع هذا عن طريق ترحيل مبيعات التذاكر في البداية إلى حساب التزام "الإيرادات غير المكتسبة" (Unearned Revenue) (instead of P&L) ثم عبر قيد يومية أو برنامج نصي آلي، يتم تحويل المبلغ إلى إيرادات في تاريخ مغادرة الرحلة. يمكننا أتمتة الاعتراف بالإيرادات عن طريق كتابة برنامج نصي للخادم يتم تشغيله عند تمييز نوع مستند الرحلة على أنه "غادرت" (“Departed”) لنقل فواتير التذاكر المرتبطة من الإيرادات غير المكتسبة إلى الإيرادات المكتسبة.
5. التزام المسافر الدائم: إذا تم تنفيذ برنامج ولاء، فإن النقاط أو الأميال المكتسبة تترجم إلى التزام (تكلفة مؤجلة للسفر المجاني المستقبلي). سنقوم بتضمين حسابات "التزام أميال برنامج المسافر الدائم" (“FFP Miles Liability”) وتسجيل القيود عند اكتساب الأميال وعند استبدالها (مما يقلل من الالتزام ويعترف بالمصروف).
6. هيكل متعدد الشركات: إذا تم إدارة عدة شركات طيران أو شركات تابعة، فسيكون لكل منها مساحة اسم دليل حسابات خاصة بها (يدعم ERPNext المحاسبة لكل شركة). يمكن إجراء التوحيد (if needed) عبر البيانات المالية التي تجمع بين الشركات (إذا كانت بنفس العملة) أو التوحيد الخارجي إذا كانت عملات الأساس مختلفة.
7. المعاملات متعددة العملات: تبيع شركات الطيران بالعديد من العملات. يدعم ERPNext المبيعات والمشتريات متعددة العملات بشكل أساسي: يمكن أن تكون كل فاتورة بعملة أجنبية وسيقوم النظام بتسجيل كل من عملة المعاملة وما يعادلها بعملة الشركة الأساسية. سنقوم بتمكين تغذيات أسعار الصرف اليومية (via an integration or manual entry) حتى تكون التحويلات محدثة. يمكن للنظام تحويل جميع المعاملات إلى العملة الأساسية لإعداد التقارير الموحدة بسهولة[10]. على سبيل المثال، إذا كانت العملة الأساسية هي الدولار الأمريكي ولكن يتم بيع التذاكر باليورو، فسيقوم ERPNext بتخزين مبالغ اليورو وإظهار ما يعادلها بالدولار الأمريكي، ويمكن عرض بياناتنا المالية بالدولار الأمريكي بأرقام مجمعة. يمكن إدارة المكاسب/الخسائر غير المحققة لتقلبات العملة (إذا احتفظنا بأموال بعملات متعددة) عبر قيود المحاسبة في ERPNext لإعادة التقييم، إذا لزم الأمر، في نهاية الفترة. بالإضافة إلى ذلك، يمكن الاحتفاظ بالحسابات المصرفية بعملات مختلفة في ERPNext، وسيتم مطابقة المدفوعات وفقًا لذلك.
8. المحاسبة المعقدة للإيرادات: سنستخدم مراكز التكلفة (Cost Centers) أو الأبعاد (Dimensions) في ERPNext لتحليل الربحية المفصل:
9. تحديد مراكز التكلفة لكل مسار رحلة أو لكل وحدة عمل (Passenger Ops, Cargo Ops, etc.). يمكن ربط الإيرادات والتكاليف المباشرة بهذه المراكز. على سبيل المثال، يمكن أن تُعزى إيرادات التذاكر وبعض التكاليف الخاصة بالرحلة (الوقود لتلك الرحلة، رسوم الهبوط، التموين على تلك الرحلة) إلى "مركز تكلفة الرحلة XY123". يتيح هذا تحليل ربحية المسار عن طريق جمع بيان الدخل والخسارة حسب مركز التكلفة.
10. استخدام أبعاد المحاسبة (Accounting Dimensions) (a feature in later ERPNext versions) لإضافة أبعاد مخصصة مثل "الرحلة" أو "الطائرة" على المعاملات. هذا يعني أنه عند تسجيل مصروف، يمكننا ربطه بالطائرة أو الرحلة التي يتعلق بها. قد يكون لدينا بُعد "القسم" لفصل تكاليف العمليات الأرضية مقابل تكاليف عمليات الطيران مقابل التكاليف الإدارية.
11. المعاملات بين الشركات: إذا كان النظام يتعامل مع عدة شركات طيران، فربما تكون هناك فواتير بين الشركات (مثل شركة تابعة تقدم المناولة الأرضية لشركة أخرى). يدعم ERPNext قيود اليومية والفواتير بين الشركات لتبسيط المحاسبة بين الشركات دون تكرار.
12. بوابات الدفع وتسوية المبيعات: تحتاج جميع المدفوعات القادمة من قنوات مختلفة (الموقع الإلكتروني، الوكلاء، شركاء المشاركة بالرمز) إلى تسوية:
13. ستقوم عمليات تكامل بوابات الدفع بإنشاء إدخالات الدفع (Payment Entries) تلقائيًا في ERPNext للمدفوعات الناجحة[7]. سنقوم بتكوين النظام لتمييز الفواتير على أنها مدفوعة عند استلام تأكيد البوابة. بشكل دوري، يمكن للقسم المالي تسوية سجلات ERPNext مع تقارير البوابة لضمان عدم وجود تناقضات.
14. بالنسبة لمبيعات الوكالات عبر GDS، عادةً ما يتم إصدار فواتير لها عبر BSP/ARC (clearing houses). سيتعين علينا استيراد تقارير المبيعات من هذه الأنظمة وتسويتها مع سجلات الحجز الخاصة بنا في ERPNext. من الممكن إنشاء فواتير لكل وكيل أو GDS حسب الحاجة.
15. الذمم المدينة/الدائنة: إدارة الذمم المدينة من عملاء الشركات أو عملاء الطيران العارض من خلال وحدة الذمم المدينة في ERPNext. إدارة الذمم الدائنة مثل بائعي الوقود، رسوم المطار، المؤجرين، وما إلى ذلك، باستخدام فواتير الشراء وسير عمل الموافقة المناسب لفواتير الموردين.
16. الامتثال المالي وإعداد التقارير: التأكد من أن النظام يمكنه إنتاج البيانات المالية المطلوبة (بيان الدخل، الميزانية العمومية، التدفقات النقدية) والتقارير التنظيمية الأخرى:
17. يمكن لـ ERPNext إنشاء هذه التقارير بشكل أساسي لكل شركة. سنقوم بتخصيص التقارير لتتوافق مع معايير صناعة الطيران إذا لزم الأمر (على سبيل المثال، فصل تكاليف التشغيل المباشرة مقابل التكاليف غير المباشرة).
18. الامتثال الضريبي: إذا كانت شركة الطيران تعمل على مستوى العالم، فتعامل مع أنظمة ضريبية متعددة. وحدة الضرائب في ERPNext مرنة لتحديد قواعد الضرائب (VAT, GST, sales tax) لكل بلد[10]. على سبيل المثال، تحديد ضريبة السلع والخدمات للتذاكر المباعة في الإمارات العربية المتحدة مقابل ضريبة القيمة المضافة لمبيعات الاتحاد الأوروبي، وما إلى ذلك، وربطها بالحسابات الصحيحة. يمكن للنظام إنشاء تقارير ضريبية لكل ولاية قضائية حسب الاقتضاء.
19. إذا كان يجب على شركة الطيران الامتثال لمعايير محاسبية محددة (like IFRS or local GAAP)، فقم بتكوين الدليل والقيود المحاسبية وفقًا لذلك. على سبيل المثال، محاسبة الإيجار وفقًا لمعيار IFRS16 لعقود إيجار الطائرات: يمكننا استخدام قيود الأصول والالتزامات للتعامل مع أصول حق الاستخدام والتزامات الإيجار، على الرغم من أنه قد يتم تتبع ذلك خارج النظام وإجراء قيود تسوية في ERPNext.
20. التدقيق: توفير وصول للقراءة فقط للمدققين أو تصدير البيانات للتدقيق. تعمل سجلات دفتر الأستاذ العام (GL Entry) في ERPNext كدفتر يومية، وكل فاتورة أو معاملة قابلة للتتبع للمستخدم والطابع الزمني، مما يساعد في عمليات التدقيق.
21. إدارة التكاليف: تنفيذ أدوات في ERPNext لتتبع التكاليف والتحكم فيها:
22. الميزانية: استخدام ميزة الميزانية (Budget) في ERPNext لتعيين ميزانيات لمراكز التكلفة (e.g., maintenance cost budget for the year) ومراقبة الفروق.
23. إدارة الوقود: الوقود يمثل تكلفة ضخمة لشركات الطيران. يمكننا دمج بيانات شراء وتعبئة الوقود. على سبيل المثال، عند تعبئة الوقود لرحلة، يتم تسجيل الكمية والسعر (ربما عبر تكامل مع أنظمة التزويد بالوقود أو إدخال يدوي من قبل العمليات الأرضية)، ثم يتم ترحيل قيد يومية تلقائيًا يخصص هذه التكلفة لمركز تكلفة الرحلة. يوفر هذا تكلفة وقود شبه فورية لكل رحلة في النظام.
24. تكاليف الصيانة: إذا تم إجراء صيانة ثقيلة من قبل أطراف ثالثة، فيمكن ربط فواتيرهم بأصل الطائرة المحدد. يمكننا الحفاظ على دفتر تكاليف حسب الأصل (asset-wise cost ledger) باستخدام مرجع الأصل في فواتير الشراء، وهو ما يدعمه ERPNext لمحاسبة الأصول (على الرغم من أنه في المقام الأول للإهلاك). بدلاً من ذلك، تعامل مع أحداث الصيانة الثقيلة كمشاريع وجمع التكاليف - ولكن الطريقة الأبسط هي ربط التكاليف بالطائرة عبر بُعد أو مركز تكلفة.
25. التكاليف متعددة العملات: إذا حدثت المصروفات بعملات مختلفة (شائع في الطيران، على سبيل المثال، دفع ثمن الوقود بالعملة المحلية لكل بلد)، فسيقوم ERPNext بتسجيلها وترجمتها إلى العملة الأساسية. يمكننا تحديث أسعار الصرف أو حتى دمج تغذية حية، بحيث تعكس التقارير المالية قيمًا دقيقة.
26. إدارة الإيرادات والتسعير الديناميكي: بينما غالبًا ما يكون التسعير الديناميكي (إدارة العائد) خارج نظام تخطيط موارد المؤسسات، يمكننا استخدام ميزة قاعدة التسعير (Pricing Rule) في ERPNext أو وحدة تسعير ديناميكي مخصصة لتنفيذ إدارة العائد الأساسية:
27. يمكن لـ ERPNext إنشاء قواعد تسعير بناءً على شروط (e.g., customer group, quantity, date range). بالنسبة للرحلات، يمكننا برمجة قاعدة بحيث يرتفع سعر المقاعد المتبقية مع بيع المقاعد في فئة سعر معينة. بدلاً من ذلك، التكامل مع أداة إدارة عائد خارجية تحسب الأسعار المثلى وتحدث سعر الصنف في ERPNext أو جدول أسعار مخصص عبر واجهة برمجة التطبيقات.
28. يمكن أيضًا معالجة مسألة التسعير الديناميكي من خلال الإشارة إلى قدرة ERPNext على التعامل مع استراتيجيات التسعير المعقدة. في الواقع، لوحظ أن ERPNext لديه وحدة إدارة تسعير ديناميكي في بعض السياقات[11]، والتي تسمح بتخصيص قواعد التسعير والاستجابة للبيانات في الوقت الفعلي. يمكننا أن نذكر أن النظام يمكنه ضبط استراتيجيات التسعير بدقة من خلال قواعد وخصومات وعروض ترويجية قابلة للتخصيص، والاستفادة من البيانات في الوقت الفعلي للقدرة على المنافسة[11]. من الناحية العملية، بالنسبة لنظامنا، هذا يعني أنه يمكننا تعديل أسعار التذاكر بناءً على نافذة الحجز (الحجز المبكر مقابل اللحظة الأخيرة)، الطلب (عوامل الحمولة)، أو العوامل الخارجية (أسعار الوقود).
29. يجب تسجيل جميع تغييرات الأسعار والموافقة عليها بشكل مثالي وفقًا لسياسة داخلية (ربما تتطلب موافقة مدير الإيرادات بعد عتبات معينة - يمكن القيام بذلك عن طريق تقييد من يمكنه تحديث السعر في ERPNext).
30. التحليل المالي: يمكن لفريق المالية استخدام أدوات التحليل المدمجة في ERPNext لتتبع الأداء:
31. إعداد مخططات لوحة المعلومات (dashboard charts) للمقاييس الرئيسية: الحجوزات اليومية، الإيرادات لكل رحلة، النقد المتاح، إلخ.
32. الاستفادة من تكامل ERPNext مع أدوات ذكاء الأعمال[12][12] (أو Frappe Insights) للتحليل المتقدم مثل التنبؤ بالاتجاهات أو التحليل متعدد الأبعاد. على سبيل المثال، تحليل الربحية حسب المسار حسب الشهر لإبلاغ القرارات الاستراتيجية (أي المسارات يجب توسيعها أو إسقاطها).
33. يمكن إجراء التنبؤ الموسمي عن طريق تصدير البيانات إلى جدول بيانات أو دفتر Jupyter (يمكن جلب بيانات ERPNext عبر واجهة برمجة التطبيقات للتحليل الخارجي). ولكن كما ذكرنا سابقًا، يتطور ERPNext بقدرات ذكاء الأعمال بما في ذلك رؤية البيانات في الوقت الفعلي وحتى التحليلات التنبؤية من خلال تحليل البيانات التاريخية[12]. هذا يعني أنه في المستقبل قد ندمج وحدة للتنبؤ بالإيرادات للمواسم القادمة بناءً على البيانات السابقة في ERPNext.

من خلال تخصيص المحاسبة في ERPNext على النحو الوارد أعلاه، تكتسب شركة الطيران نظامًا ماليًا شفافًا وصارمًا. تتدفق بيانات جميع الأقسام إلى المحاسبة تلقائيًا (المبيعات من الحجوزات، المصروفات من العمليات)، مما يقلل من التسوية اليدوية. يتم التعامل مع العمليات متعددة العملات والكيانات المتعددة بسلاسة بواسطة ERPNext[10]، ويتم تحقيق الاحتياجات الخاصة بالصناعة مثل الإيرادات المؤجلة وتتبع التكاليف لكل رحلة من خلال البرامج النصية المخصصة والاستخدام المنظم لمراكز التكلفة/الأبعاد. مع وجود ضوابط محاسبية قوية وتقارير ثاقبة، يمكن للإدارة الوثوق بالأرقام والتركيز على التخطيط المالي الاستراتيجي.

التموين والخدمات على متن الطائرة

تضمن إدارة التموين والخدمات على متن الطائرة دعم تجربة الركاب على متن الطائرة بشكل جيد (الوجبات والمشروبات ووسائل الراحة)، وأن تعمل الخدمات اللوجستية الخلفية لتلك الخدمات بسلاسة. سنستخدم ميزات المخزون والمشتريات في ERPNext، مع ملحقات مخصصة، للتعامل مع سلسلة توريد التموين الشاملة (end-to-end catering supply chain) وإدارة المنتجات على متن الطائرة:

1. تخطيط القائمة وإعداد المخزون: نمذجة كل وجبة أو صنف كـ صنف (Item) في ERPNext:
2. تحديد قائمة المواد (Bill of Materials (BOM)) للوجبات إذا كانت شركة الطيران تعدها. على سبيل المثال، تتكون قائمة مواد "صينية وجبة الدجاج" من حصة واحدة من الدجاج، وحلوى واحدة، ومشروب واحد، وما إلى ذلك. يساعد هذا إذا كانت شركة الطيران بحاجة إلى شراء المكونات وتجميع الوجبات - يمكن استخدام قائمة المواد لتخطيط متطلبات المكونات بناءً على عدد الوجبات المطلوبة.
3. إذا تم الاستعانة بمصادر خارجية للتموين، يمكن أن تكون "الوجبة" مجرد صنف شراء من مورد التموين، مع تخطي قائمة المواد.
4. قم أيضًا بإنشاء أصناف للمنتجات الأخرى على متن الطائرة: المشروبات، الوجبات الخفيفة، الوسائد، سماعات الرأس، السلع المعفاة من الرسوم الجمركية، إلخ. قم بتنظيمها حسب مجموعات الأصناف (للتمييز بين الطعام والسلع المعفاة من الرسوم الجمركية والمعدات).
5. إدارة المستودعات للتموين: إنشاء مستودعات (warehouses) في ERPNext لكل موقع تموين (على سبيل المثال، مطبخ في مركز دبي، وآخر في مركز ثانوي، بالإضافة إلى مستودع يمثل "على متن الطائرة").
6. قد يكون مفهوم التعامل مع كل طائرة أو رحلة كمستودع مفيدًا لتتبع المخزون المحمل. يمكننا إنشاء مستودع مؤقت لكل رحلة أو ببساطة الحفاظ على مستودع "قيد النقل" حيث يتم نقل البضائع المحملة على الطائرات حتى يتم إعادتها أو استهلاكها.
7. سير العمل: قبل الرحلة، سيقوم موظفو التموين باختيار وتعبئة الأصناف المطلوبة. في ERPNext، يمكننا إنشاء إدخال مخزون (Stock Entry (Material Transfer)) من مستودع المطبخ إلى مستودع "طائرة [رقم الرحلة]" للكمية الدقيقة من الوجبات والمشروبات وما إلى ذلك، وفقًا لعدد الركاب ومعايير الخدمة لتلك الرحلة. يعمل هذا كـ بيان تحميل. بعد الرحلة، يسجلون ما تم استهلاكه مقابل ما تم إعادته: على سبيل المثال، إذا لم يتم استخدام بعض الوجبات، فقد يتم إهدارها أو إعادتها (حسب اللوائح). يمكن لـ تسوية المخزون (Stock Reconciliation) أو إدخال مخزون آخر تعديل مستودع "الطائرة" مرة أخرى إلى الصفر ويعكس الاستهلاك إما كمصروف أو العودة إلى المخزون إذا كان قابلاً للإنقاذ.
8. الحفاظ على مستويات مخزون دنيا للأصناف المستخدمة بشكل متكرر في كل موقع. يمكن لـ ERPNext تشغيل طلبات المواد (Material Requests) لإعادة التخزين عندما تنخفض المستويات عن الحد الأدنى (على سبيل المثال، إذا كان أحد مطابخ التموين يعاني من نقص في المشروبات، فقم بإنشاء طلب لشراء المزيد أو النقل من التخزين الرئيسي).
9. طلبات التموين لكل رحلة: إنشاء نوع مستند مخصص، على سبيل المثال طلب تموين الرحلة (Flight Catering Request)، والذي يتم إنشاؤه لكل رحلة قبل ساعات معينة من المغادرة:
10. سيقوم هذا المستند بسرد جميع الأصناف المطلوبة في تلك الرحلة، محسوبة بناءً على حمولة الركاب والدرجات (على سبيل المثال، 100 راكب في الدرجة السياحية -> 100 وجبة في الدرجة السياحية + 10 إضافية، 10 ركاب في درجة رجال الأعمال -> 10 وجبات في درجة رجال الأعمال + 2 إضافية، إلخ، بالإضافة إلى وجبات الطاقم، الوجبات الخاصة). يمكن للنظام تعبئة هذا تلقائيًا باستخدام القوالب وبيانات الحجز الفعلية (يتم تسجيل طلبات الوجبات الخاصة في سجلات اسم الراكب).
11. يستخدم موظفو التموين هذا المستند لتعبئة الأصناف. يمكن أن يكون للمستند حالة (معلق، تم التحميل، إلخ) وبمجرد تلبيته، يمكنه إنشاء إدخال المخزون تلقائيًا للخصم من المخزون.
12. يوفر هذا النهج سجلًا واضحًا لما تم التخطيط له مقابل ما تم تحميله بالفعل.
13. الوجبات الخاصة والتفضيلات: التأكد من أن أي طلبات وجبات خاصة (vegetarian, halal, gluten-free, etc.) التي قدمها الركاب أثناء تدفق الحجز يتم تخزينها في ERPNext (كجزء من تفاصيل الحجز أو جدول فرعي لطلبات الخدمة الخاصة – SSRs – Special Service Requests). سيشمل طلب تموين الرحلة تلك الأعداد المحددة لكل رحلة. على سبيل المثال، "5 وجبات نباتية، 2 خالية من الغلوتين" للرحلة X إذا تم طلبها. يضمن هذا أن يقوم فريق التموين بتحميل الوجبات المناسبة وأن هذه الطلبات لا تفلت من الانتباه.
14. المشتريات وإدارة الموردين: ستقوم وحدة الشراء في ERPNext بإدارة موردي التموين:
15. إدارة العقود (contracts) مع شركات التموين (إذا تم الاستعانة بمصادر خارجية للتموين في محطات معينة). قد يتضمن ذلك إعدادهم كموردين واستخدام أوامر الشراء للوجبات التي يتم تسليمها لكل رحلة أو لكل يوم.
16. بالنسبة للتموين الداخلي، سيتم تتبع شراء المواد الخام (مكونات الطعام، التغليف). استخدم دورة طلب المواد -> أمر الشراء -> إيصال الشراء -> فاتورة الشراء (Material Request -> Purchase Order -> Purchase Receipt -> Purchase Invoice) للتعامل مع شراء هذه البضائع. اربطها بمركز تكلفة التموين لتجميع تكاليف التموين لتحليل الربحية.
17. مراقبة الجودة وانتهاء الصلاحية: الاستفادة من أرقام الدفعات للبضائع القابلة للتلف. يمكن لـ ERPNext تتبع انتهاء صلاحية الدفعة، لذلك بالنسبة للمكونات أو الأطعمة المحضرة ذات العمر الافتراضي، نضمن عدم استخدام الأصناف منتهية الصلاحية. (على الرغم من أن الوجبات عادة ما تكون طازجة يوميًا، إلا أن بعض الوجبات الخفيفة المعبأة قد يكون لها عمر افتراضي أطول وتحتاج إلى مراقبة).
18. المبيعات على متن الطائرة (معفاة من الرسوم الجمركية): بالنسبة لشركات الطيران التي تبيع منتجات معفاة من الرسوم الجمركية على متن الطائرة:
19. الحفاظ على مخزون معفى من الرسوم الجمركية (Duty-Free inventory) (ربما مستودع "عربة معفاة من الرسوم الجمركية"). قبل الرحلة، قم بتحميل العربة بمخزون محدد (مرة أخرى عبر إدخال المخزون). بعد الرحلة، يتم حساب المبيعات والتحقق من المخزون المتبقي.
20. يمكن للطاقم استخدام واجهة بسيطة (ربما على تطبيق الطاقم) لتسجيل مبيعات الأصناف المعفاة من الرسوم الجمركية لكل رحلة، مما سيؤدي إلى إنشاء فواتير مبيعات (Sales Invoices) أو سجل مبيعات موجز في ERPNext. عادة ما تكون هذه الفواتير مبيعات نقدية أو بالبطاقة على متن الطائرة. قد ندمج واجهة نقطة بيع على الجهاز اللوحي للطاقم، والتي يمكنها حتى معالجة بطاقات الائتمان (على الرغم من أنه قد تكون هناك حاجة إلى معالجة دون اتصال بالإنترنت إذا لم يكن هناك اتصال في الجو - بدلاً من ذلك، قم بذلك بعد الرحلة).
21. يمكن توسيع وحدة نقطة البيع (Point of Sale module) في ERPNext للاستخدام دون اتصال بالإنترنت على جهاز لتسجيل المبيعات، ثم المزامنة عند العودة إلى الإنترنت.
22. بعد الرحلة، يجب على النظام تسوية المخزون المتوقع مقابل الفعلي وإنتاج تقارير فروق إذا كان هناك أي تناقضات (والتي يمكن أن تشير إلى سرقة أو خطأ).
23. لوجستيات التموين ودورة العمل: لكل رحلة، الوقت حاسم. يمكننا استخدام مهام ERPNext أو جدولة خفيفة لتتبع إرسال شاحنة التموين إلى الطائرة، وما إلى ذلك. من المحتمل أن يكون التكامل الكامل مبالغًا فيه، ولكن على الأقل تأكد من أن النظام يمكنه تسجيل وقت تحميل التموين، وإذا كان هناك تأخير، فقد يرتبط ذلك بتتبع الاستعداد العام للمغادرة.
24. إذا لزم الأمر، يمكن إجراء تكامل مع أنظمة المطار (airport systems) للتموين، ولكن من المحتمل أن تكون الإدارة الداخلية كافية.
25. النفايات والتحكم في التكاليف: استخدم البيانات التي تم جمعها لتحليل أداء التموين: على سبيل المثال، متوسط الوجبات المهدرة لكل رحلة، المخزون الزائد المحمول، وما إلى ذلك، لتحسين التحميل في المستقبل. يمكن لتقارير ERPNext جمع عدد كل نوع وجبة لم يتم استهلاكه وربما تعديل صيغة رفع التموين. هذا يقلل من التكلفة بمرور الوقت.
26. إدارة خدمة الطاقم على متن الطائرة: على الرغم من أنها ليست مباشرة في ERP، يمكننا دمج ميزات تطبيق الجوال للطاقم مثل التقاط ملاحظات الركاب أو الحوادث (مثل إذا كان لدى راكب مشكلة مع وجبة، فقم بتسجيلها وربما إنشاء مشكلة عميل في ERPNext للمتابعة). يرتبط هذا بإدارة جودة الخدمة.

بشكل عام، من خلال التعامل مع التموين ومستلزمات الخدمة على متن الطائرة كـ سلسلة توريد رأسية داخل ERPNext (vertical supply chain within ERPNext)، نضمن أن ما يحدث في الجو مدعوم على الأرض بلوجستيات فعالة. تمنع دقة المخزون النقص (لا مزيد من "نفدت وجبات الدجاج في الصف 20") ويساعد تتبع التكاليف في تحديد المدخرات (مثل تقليل الإفراط في التموين). يصبح نظام ERPNext، مع بعض المستندات المخصصة ووظائف المخزون القياسية، نظام إدارة تموين يربط بين عمليات الطيران (من خلال أعداد الركاب والطلبات الخاصة) والمالية (من خلال ترحيل تكاليف مستلزمات التموين إلى الرحلات).

إدارة الصيانة والسلامة

يعد ضمان صلاحية الطائرات للطيران وسلامة العمليات أمرًا غير قابل للتفاوض بالنسبة لشركة طيران. سنقوم بدمج جدولة الصيانة وتتبعها وإدارة السلامة في نظام ERPNext باستخدام وحدة الأصول والتحسينات المخصصة:

1. جدولة صيانة الطائرات: سيكون لكل طائرة (أصل) جدول صيانة (maintenance schedule). تسمح ميزات صيانة الأصول في ERPNext بجدولة المهام حسب التاريخ أو الاستخدام[13]:
2. تحديد خطط (plans) صيانة لكل طائرة: على سبيل المثال، فحص A-Check كل 500 ساعة طيران أو 3 أشهر (أيهما أولاً)، وفحص B-Check كل 6 أشهر، وفحص C-Check كل عامين، وما إلى ذلك، والفحوصات اليومية. قد نحتاج إلى توسيع ERPNext للتعامل مع مشغلات الصيانة القائمة على الاستخدام (ساعات الطيران، الدورات). أحد الأساليب هو تسجيل ساعات الطيران/الدورات لكل رحلة في حقل مخصص في نوع مستند الرحلة وتجميعها لكل طائرة.
3. استخدام جدول الصيانة (Maintenance Schedule) (أو نوع مستند مخصص) لسرد الفحوصات المطلوبة القادمة. يمكن تكوين ERPNext لإنشاء مهام صيانة على أساس تقويمي[3]. بالنسبة للاستخدام، يمكننا إعداد وظيفة cron أو برنامج نصي يتحقق مما إذا كانت الساعات منذ آخر فحص تتجاوز الحد الأدنى ثم جدولة مهمة.
4. عندما تستحق مهمة صيانة، قم بإنشاء زيارة/سجل صيانة (Maintenance Visit/Log) (مثل سجل صيانة الأصول في ERPNext[3]). سيقوم هذا المستند بتفصيل العمل المنجز، والأجزاء التي تم تغييرها، وأي نتائج. يمكن أن يحتوي على جداول فرعية للأجزاء المستخدمة (مرتبطة بإصدار المخزون) ولبنود قائمة فحص التفتيش.
5. تعيين كل مهمة صيانة للمهندسين المسؤولين (يمكن لـ ERPNext استخدام ميزة التعيين أو إنشاء "مهمة" (“ToDo”) للمهندس).
6. الإبلاغ عن العيوب وأوامر العمل: في التشغيل اليومي، قد تنشأ مشاكل (على سبيل المثال، يبلغ طيار عن عطل في جهاز). قم بتنفيذ نوع مستند تقرير عيب (Defect Report) أو طلب صيانة (Maintenance Request):
7. يمكن للطاقم أو موظفي الصيانة إنشاء تقرير عن مشكلة، مرتبط بأصل الطائرة واختياريًا برحلة أو معدات معينة.
8. تحديد أولويته (AOG – Aircraft on Ground urgent, or minor deferred defect).
9. تحويل هذه إلى أوامر عمل لفريق الصيانة. يمكن استخدام المشروع/المهمة في ERPNext، أو ببساطة التعامل مع كل عيب مفتوح كمهمة معينة لمهندس.
10. تتبع الحالة: مفتوح، قيد التقدم، مؤجل (يمكن تأجيل بعض العيوب بموجب قائمة الحد الأدنى من المعدات – MEL – Minimum Equipment List – إذا لم تكن حرجة؛ قد ندرج مرجع MEL لمعرفة المدة التي يمكن تأجيلها).
11. بمجرد إصلاحه، سجل الحل وقم بتمييز العيب على أنه مغلق في النظام.
12. قطع الغيار والمخزون للصيانة: ربط سجلات الصيانة بمخزون قطع الغيار:
13. عند استبدال الأجزاء، سيختار المهندس أجزاء من المخزون (ربما عبر تطبيق الجوال بمسح الرمز الشريطي للجزء). يؤدي هذا إلى تشغيل إصدار مخزون (Stock Issue (Material Issue stock entry)) من مستودع قطع الغيار إلى مركز تكلفة الصيانة أو مباشرة إلى أصل الطائرة.
14. إذا كان الجزء مسلسلاً (مثل محرك أو وحدة إلكترونيات طيران)، فسيسجل تتبع الرقم التسلسلي (Serial No) في ERPNext الرقم التسلسلي للجزء المثبت ويمكنه الحفاظ على سجل للأجزاء التسلسلية الموجودة على أي طائرة (عن طريق تسجيله في سجل الصيانة). هذا أمر بالغ الأهمية لإمكانية التتبع والامتثال.
15. الحفاظ على مستويات المخزون في مواقع الصيانة وإعادة الطلب حسب الحاجة. غالبًا ما يكون لقطع الغيار أوقات تسليم، لذا استخدم طلب المواد (Material Request) لتخطيط المشتريات عندما يكون المخزون منخفضًا أو تحتاج الفحوصات القادمة إلى مجموعات محددة.
16. من الممكن التكامل مع الموردين لشراء قطع الغيار (قد تكون بعض الأجزاء في برامج تبادل - يمكن ملاحظة تفاصيل تلك العقود في النظام أيضًا).
17. الامتثال التنظيمي والتوثيق: تتطلب سلطات الطيران سجلات مفصلة:
18. استخدام ERPNext لتخزين سجلات الصيانة (maintenance records) واستردادها بسهولة أثناء عمليات التدقيق. سيعمل سجل صيانة الأصول جنبًا إلى جنب مع المرفقات (مثل شهادات الامتثال، وقوائم الفحص الممسوحة ضوئيًا) كسجل رقمي. سنقوم بتصنيفها حسب نوع الصيانة والتاريخ.
19. تتبع AD/SB: توجيهات الصلاحية للطيران (ADs) ونشرات الخدمة (SBs) هي إشعارات من الشركة المصنعة أو السلطة تتطلب عمليات تفتيش أو تعديلات. يمكننا إنشاء نوع مستند لإدارة امتثال AD/SB - سرد جميع ADs المطبقة لكل طائرة وحالتها (تم الامتثال أم لا). اربطها بمهام الصيانة. هذا يضمن عدم تفويت أي AD.
20. المعايرة: إذا كانت شركة الطيران تستخدم أدوات أو معدات أرضية تحتاج إلى معايرة (e.g., torque wrenches, avionics testing tools)، فيمكن أيضًا إدارتها كأصول مع جداول صيانة في ERPNext للتذكير بموعد استحقاق المعايرة.
21. إدارة السلامة والحوادث: بالإضافة إلى الصيانة الميكانيكية، تشمل السلامة الحوادث المتعلقة بالعمليات:
22. تنفيذ وحدة تقرير الحوادث (Incident Report) (يمكن أن تكون مخصصة أو تستخدم وحدة المشكلات في ERPNext مع بعض التخصيص). هذا مخصص لأحداث مثل اصطدام الطيور، تحويل مسار الرحلات، إصابات الركاب، الحوادث الأمنية، إلخ. يمكن إنشاء هذه التقارير من قبل الموظفين المعنيين (الطيارون، طاقم الطائرة، الأمن) إما عبر نموذج في التطبيق أو بعد وقوع الحادث.
23. تسجيل التفاصيل: نوع الحادث، رقم الرحلة، التاريخ، الوصف، الإجراءات المتخذة (e.g. emergency landing, first aid given)، والمتابعة المطلوبة.
24. تعيين هذه التقارير لفريق ضباط السلامة للتحقيق. الحفاظ على الحالة (مفتوح، قيد التحقيق، مغلق) وتوثيق النتائج والإجراءات التصحيحية.
25. يتماشى هذا مع متطلبات نظام إدارة السلامة (SMS) في الطيران - وجود سجل للحوادث وكيفية حلها لمنع تكرارها.
26. تحليل بيانات الحوادث في ERPNext لاكتشاف الاتجاهات (e.g., frequent bird strikes at a location – then initiate mitigation).
27. التنسيق مع المطارات والصيانة الخارجية: في بعض الأحيان يتم إجراء صيانة ثقيلة من قبل منظمات صيانة وإصلاح وعمرة تابعة لجهات خارجية، أو يجب تنسيق العمل مع سلطات المطار:
28. استخدام التكامل أو تبادل البيانات (integration or data exchange) إذا لزم الأمر: على سبيل المثال، إذا تم الاستعانة بمصادر خارجية لفحص صيانة ثقيل، فقد تقدم منظمة الصيانة والإصلاح والعمرة تقرير PDF - نقوم بإرفاقه بسجل الصيانة وربما تحليل المعلومات الرئيسية في بيانات منظمة.
29. بالنسبة لصيانة الخطوط في المحطات الخارجية، ربما يتم منح وصول محدود للبوابة للمهندسين المتعاقدين لتحديثها عند أداء العمل (أو يرسلون أوراقًا يقوم موظفونا بإدخالها).
30. يمكن إدارة التنسيق مع المطار لأشياء مثل مساحة الحظيرة أو القطر عن طريق المهام أو ببساطة عن طريق الاتصال (وتسجيله إذا لزم الأمر).
31. إذا كانت تأخيرات الرحلات بسبب الصيانة، فقم بربط سجل الصيانة بحادث التأخير هذا حتى يتمكن التحليل اللاحق من تحديد التأخيرات المتعلقة بالصيانة.
32. مقاييس وقت التوقف والموثوقية: استخدام بيانات ERPNext لحساب مؤشرات الأداء الرئيسية لموثوقية الأسطول:
33. وقت توقف الطائرة على الأرض (AOG)، موثوقية الإرسال (نسبة الرحلات التي تغادر دون تأخير صيانة)، متوسط الوقت بين الأعطال، إلخ. يمكننا استخلاص هذه من سجلاتنا (بيانات الرحلات مقابل بيانات الصيانة).
34. يمكن لمنشئ التقارير في ERPNext أو البرامج النصية المخصصة حساب هذه المقاييس. على سبيل المثال، حساب عدد الرحلات التي تأخرت بسبب مشاكل الصيانة مقابل إجمالي الرحلات للحصول على نسبة مئوية.
35. التكامل مع عمليات الطيران: يجب أن تغذي حالة الصيانة العمليات: إذا كانت طائرة معطلة للصيانة غير المجدولة، فقم بتمييزها على هذا النحو في النظام حتى لا يتم تعيينها لرحلة. يمكننا تضمين "حالة الطائرة" (“Aircraft Status” (Active, In Maintenance, etc.)) في سجل الأصول. إذا تم تعيينها على "في الصيانة"، يمكن لوحدة تعيين الرحلات التحذير أو منع جدولة تلك الطائرة. بالإضافة إلى ذلك، إذا تجاوزت الصيانة الوقت المحدد، يمكن إخطار مراقبي العمليات من خلال النظام (على سبيل المثال، تنبيه أو رسالة دردشة) لتبديل الطائرة.

من خلال تضمين الصيانة والسلامة في ERPNext، نقوم بإنشاء استمرارية للبيانات من الحظيرة إلى مكتب المالية (continuum of data from the hangar to the finance office). ستؤدي إجراءات الصيانة تلقائيًا إلى تكبد قيود تكلفة، ويكون وقت توقف الطائرة مرئيًا للمجدولين، مما يضمن عدم وجود صوامع. علاوة على ذلك، فإن وجود سجلات رقمية في نظام واحد يحسن الامتثال التنظيمي، حيث يمكن منح المفتشين تقارير شاملة عن جميع سجلات الصيانة والحوادث دون الحاجة إلى غربلة الملفات. إن استخدام ERPNext في هذا المجال يحوله بشكل أساسي إلى نظام إدارة صيانة محوسب أساسي (CMMS) متكامل مع بقية نظام تخطيط موارد المؤسسات لشركة الطيران.

التعامل مع التأخير والتنسيق الأمني

حتماً، تواجه الرحلات تأخيرات أو اضطرابات، ويجب على شركات الطيران تنسيق الاستجابات التي تشمل كل من رعاية العملاء والوكالات الأمنية عند الضرورة. سيشتمل نظامنا القائم على ERPNext على أدوات سير عمل واتصالات لإدارة العمليات غير المنتظمة (IROPs)، مما يضمن التعامل المنظم مع مثل هذه الأحداث:

1. سير عمل حوادث التأخير: عندما تتأخر رحلة أو تُلغى، يكون الوقت من ذهب:
2. يمكن لفريق مراقبة العمليات (Operations Control) (أو أي مستخدم مصرح له مثل مدير المحطة) إنشاء تقرير مخالفة رحلة (Flight Irregularity Report) في ERPNext بمجرد معرفة أن تأخيرًا أو إلغاءً سيحدث. يمكن أن يكون هذا جدولًا فرعيًا مخصصًا تحت الرحلة أو نوع مستند منفصل مرتبط بالرحلة، يلتقط السبب (technical, weather, crew, ATC, etc.)، والوقت المقدر الجديد، والإجراءات التي يجب اتخاذها (e.g. “arrange hotel for pax”).
3. يمكن أن يؤدي تغيير حالة الرحلة إلى "مؤجلة" أو "ملغاة" في نوع مستند الرحلة إلى تشغيل العمليات النهائية تلقائيًا. من خلال البرامج النصية للخادم أو قواعد الإشعارات (Server Scripts or Notification Rules)، نقوم بإعداد:
4. إشعارات الركاب: يتلقى جميع الركاب في تلك الرحلة رسالة فورية عبر ClefinCode Chat (إشعار تطبيق أو WhatsApp) تبلغهم بالتأخير وأي تعليمات (【the multi-channel notifications previously discussed】). إذا كان التأخير كبيرًا، يمكن أن تقدم متابعة خيارات إعادة الحجز أو معلومات التعويض.
5. تنبيهات الموظفين: يتم تنبيه الفرق الداخلية ذات الصلة. يرى موظفو البوابة التأخير على لوحة معلوماتهم، ويتلقى قسم خدمة العملاء مهمة لإعداد إعادة الإقامة، وتعرف جدولة الطاقم أن الطاقم سيتجاوز وقت الواجب ربما. من الناحية العملية، يمكننا دفع رسالة إلى دردشة جماعية لموظفي تلك الرحلة أو إنشاء مهام "للقيام بها" للأقسام (e.g., “Arrange meal vouchers for Flight X passengers” assigned to ground services).
6. تسجيل رموز التأخير: تستخدم شركات الطيران رموز تأخير IATA القياسية. يمكن أن يكون لدينا حقل لرمز التأخير والدقائق المتأخرة. يساعد هذا في إعداد التقارير لاحقًا عن التأخيرات حسب السبب.
7. المساعدة في إعادة الحجز: إذا تم إلغاء الرحلة أو تسبب التأخير في فقدان الاتصال، يمكن للنظام المساعدة في العثور على بدائل. في حين أن محرك إعادة الحجز الآلي قد يكون خارج نطاق ERPNext، يمكننا تسهيل ذلك عن طريق:
8. إظهار المقاعد المتاحة على الرحلات القادمة (من بيانات جدول رحلاتنا).
9. السماح بإنشاء حجز جديد سريع للركاب المتأثرين دون دفع (نظرًا لأن التذكرة الأصلية لا تزال قائمة، فهذا تبادل). يمكن للوكيل سحب قائمة سجلات اسم الراكب المتأثرة (تقرير ERPNext لجميع الحجوزات على تلك الرحلة) ولكل منها، يقوم بتغيير الرحلة (كما هو موضح في عملية تغيير الحجز). قد نميزه على أنه تغيير غير طوعي، مع التنازل عن الرسوم.
10. تتبع أي من الركاب تم إعادة حجزهم، أو استرداد أموالهم، أو تم تزويدهم بتعويضات عبر الحالات أو العلامات على الحجز.
11. خدمة العملاء والتعويضات: بالنسبة للتأخيرات الطويلة، قد تكون شركات الطيران مدينة بتقديم خدمات (meals, hotel) أو تعويضات:
12. يمكن لـ ERPNext تسجيل أي من الركاب تلقى أي خدمة. على سبيل المثال، إنشاء مستند قسيمة خدمة للوجبات/الإقامة المقدمة. يمكن تسوية هذا لاحقًا مع فواتير الموردين (مثل فواتير الفنادق).
13. إذا كان التعويض (like EU261 cash compensation) ينطبق، فيمكننا إنشاء إشعار دائن (Credit Note) أو إدخال دفعة للعميل، أو على الأقل حالة للقسم المالي لمعالجتها. احتفظ بهذه الروابط مع تقرير حادث الرحلة كمرجع.
14. يمكن أن تكون هذه العمليات شبه آلية بواسطة القواعد: على سبيل المثال، (e.g., if delay > 3 hours and route in EU, create a Compensation Case entry for each pax in that flight with suggested compensation amount).
15. التنسيق الأمني: تتضمن بعض الاضطرابات الأمن أو إنفاذ القانون (unruly passenger, medical emergency requiring police/ambulance, bomb threat, etc.):
16. يغطي نظام الإبلاغ عن الحوادث (من قسم السلامة) التسجيل الداخلي، ولكن قد يتضمن التنسيق إخطار السلطات الخارجية. في حين أن التكامل المباشر للنظام مع أنظمة الشرطة غير محتمل، يمكننا توحيد المعلومات التي يجب مشاركتها:
17. عندما يقوم الموظفون بإنشاء تقرير حادث أمني (Security Incident Report) في ERPNext (ربما نوع فرعي من الحوادث)، يمكنهم ملء حقول مثل "تم إخطار السلطة" والشخص المسؤول عن الاتصال. يمكن للنظام إنشاء بريد إلكتروني منسق بتفاصيل الحادث لإرساله إلى الشرطة أو أمن المطار إذا كان ذلك مناسبًا (بنقرة واحدة).
18. الحفاظ على دليل لجهات الاتصال المهمة (e.g., airport security office number, local police station) في ERPNext (perhaps a custom doctype or simply a Contact list with a Role “Security”) حتى يعرف الموظفون بمن يتصلون. هذا ليس أتمتة ولكنه مستودع للمعلومات.
19. الأمتعة المفقودة أو المشبوهة: يمكن تسجيل هذه الحوادث الأمنية (الأمتعة المفقودة أو غرض مشبوه) وربطها بالراكب والرحلة. إذا فقدت حقيبة، فقم بإنشاء سجل يربط بمتابعة مناولة الأمتعة (ربما متكامل مع وحدة الأمتعة).
20. إذا تطلب حادث ما إفادات أو وثائق إضافية، فيمكن إرفاق الملفات (like scanned witness statements, etc.) بسجل الحادث في ERPNext للحفاظ عليها بأمان.
21. التعاون والتتبع: استخدم ميزات التعاون في ERPNext:
22. يمكن للتعليقات على مستندات الرحلة أو الحادث تسجيل الجدول الزمني للإجراءات المتخذة (“18:30: Decision to cancel, ATC informed; 18:45: Buses arranged to hotel”). يؤدي هذا إلى إنشاء جدول زمني واحد يمكن مراجعته لاحقًا.
23. إذا كان متكاملاً مع الدردشة، يمكن نشر بعض هذه التحديثات تلقائيًا إلى مجموعة الدردشة ذات الصلة (للاتصالات الداخلية) أيضًا.
24. استئناف العمليات العادية: بعد التأخير، تأكد من أن النظام يقوم بتحديث أوقات المغادرة/الوصول الفعلية للرحلة في نوع مستند الرحلة. سيغذي ذلك تقارير الالتزام بالمواعيد.
25. إذا تأخرت رحلة بشكل كبير، فقد يؤثر ذلك على واجب الطاقم (ينتهي وقتهم) - اربط ذلك بجدولة الطاقم لتعيين طاقم جديد إذا لزم الأمر. يمكن للنظام الإبلاغ إذا كان الطاقم الحالي سيتجاوز الساعات بسبب التأخير، مما يدفع مراقبة الطاقم إلى إيجاد بدائل (كانت وحدة الموارد البشرية تحتوي على معلومات توفر الطاقم الاحتياطي).
26. تعديل جداول الصيانة إذا كانت هناك صيانة مخطط لها بعد تلك الرحلة، إلخ. قد تكون هذه التعديلات النهائية يدوية ولكن البيانات مرئية.
27. التحليل بعد الحادث: يمكن تحليل كل تأخير أو حدث أمني من خلال التقارير. يمكن لـ ERPNext إنشاء:
28. تقارير الأداء في الوقت المحدد (% flights on-time, average delay minutes per route, etc.).
29. تحليل سبب التأخير (المجموعة حسب رمز التأخير، انظر كم عدد الدقائق/السنة التي ساهم بها كل سبب).
30. الحوادث حسب النوع (كم عدد حوادث الركاب المشاغبين، إلخ) لتغذية مجلس السلامة.

من خلال التعامل مع التأخيرات والحوادث بطريقة منظمة في ERPNext، يمكن لشركة الطيران الاستجابة بشكل أسرع والاحتفاظ بسجلات أفضل. يتم إبقاء الركاب على اطلاع بشكل استباقي (مما يحسن الرضا بشكل كبير حتى في المواقف السيئة)، وتنسق الفرق الداخلية عبر النظام بدلاً من المكالمات الهاتفية الفوضوية. علاوة على ذلك، بعد وقوع الحادث، يساعد وجود كل هذه البيانات في نظام واحد في تحسين المرونة التشغيلية والوفاء بأي متطلبات إبلاغ قانونية (مثل تقديم تقارير الحوادث إلى السلطات). بشكل أساسي، يعمل ERPNext كمركز مركزي لمراقبة العمليات غير المنتظمة (irregular operations control)، ويربط بين العمليات وخدمة العملاء والأمن.

دعم متعدد العملات ومتعدد اللغات

يجب على شركة طيران تعمل على مستوى العالم دعم العملاء والموظفين بلغات متعددة والتعامل مع المعاملات المالية بعملات متعددة. سيتم استخدام ميزات ERPNext المدمجة لضمان عولمة (globalization) واجهات النظام وبياناته:

1. المعاملات متعددة العملات: يسمح ERPNext بشكل أساسي بتحديد وإجراء المعاملات بالعديد من العملات[10]. سنقوم بتكوين جميع العملات المطلوبة (USD, EUR, AED, etc.) في النظام وإعداد تغذيات أسعار الصرف اليومية. على سبيل المثال، إذا كانت العملة الأساسية للشركة هي الدرهم الإماراتي ولكننا نبيع التذاكر بالدولار الأمريكي واليورو، فسيقوم ERPNext تلقائيًا بتحويل المعاملات إلى الدرهم الإماراتي للمحاسبة مع الحفاظ على مبالغ العملة الأصلية. يمكن للنظام حتى توحيد التقارير المالية عن طريق تحويل جميع الإدخالات إلى العملة الأساسية للحصول على صورة مالية عالمية واضحة[10].
2. ستحمل كل فاتورة مبيعات (بيع تذكرة) عملة البيع؛ وسيكون إدخال الدفع أيضًا بتلك العملة إذا تمت تسويته بها. سيسجل ERPNext كل من العملة وسعر التحويل المستخدم.
3. تحديثات العملة في الوقت الفعلي: قد نتكامل مع واجهة برمجة تطبيقات لأسعار الصرف (like fixer.io or currencylayer) أو نستخدم ميزة ERPNext المدمجة لسحب الأسعار. يضمن هذا أسعار صرف دقيقة للمبيعات وأي تقارير متعددة العملات.
4. التسعير متعدد العملات: الحفاظ على قوائم أسعار منفصلة بعملات مختلفة إذا لزم الأمر (يدعم ERPNext قوائم الأسعار حسب العملة). على سبيل المثال، قد يتم تحديد سعر الأجرة بـ 100 دولار أمريكي و 90 يورو في القوائم الخاصة بكل منهما، مع ضبط دقيق بدلاً من التحويل المباشر لمراعاة اختلافات السوق.
5. يدعم النظام أيضًا تنسيق العملة والتقريب (currency formatting and rounding) حسب الإعدادات المحلية، والتي سيتم تكوينها (مثل تنسيقات عشرية مختلفة أو رموز عملات).
6. واجهة مستخدم متعددة اللغات: يحتوي ERPNext على إطار عمل للترجمة ويدعم تبديل لغة واجهة المستخدم لكل مستخدم. سنقوم بتمكين اللغات ذات الصلة بعملياتنا (e.g., English, Arabic, French, Chinese, etc. depending on markets).
7. يمكن للموظفين اختيار لغتهم المفضلة لواجهة مكتب ERPNext. تغطي الترجمات المتاحة معظم تسميات ERPNext القياسية بعشرات اللغات[10]. بالنسبة لأي أنواع مستندات وحقول مخصصة نضيفها (مثل الرحلة، إلخ)، سنوفر ترجمات عبر أداة الترجمة بحيث تظهر بلغة المستخدم أيضًا.
8. ستكون بوابة العملاء وتطبيق الجوال متعددة اللغات. بالنسبة لتطبيق الجوال، سنقوم بتنفيذ التوطين باستخدام دعم Flutter لـ i18n - بشكل أساسي وجود ملفات لغة لسلاسل التطبيق. يمكن للتطبيق اكتشاف لغة الجهاز أو السماح للمستخدم بالتبديل. قد تحتاج الرسائل القادمة من ERPNext (مثل أخطاء التحقق أو الإشعارات) إلى توطينها أيضًا؛ يمكننا التعامل مع بعضها عن طريق إرسال رسائل مترجمة مسبقًا أو الترجمة على جانب التطبيق للسلاسل المعروفة.
9. محتوى المستند: إذا احتجنا إلى إرسال تذاكر إلكترونية أو إشعارات ثنائية اللغة، فيمكننا تصميم تنسيقات طباعة بلغات متعددة. بدلاً من ذلك، يمكننا الحصول على قوالب بكل لغة والاختيار بناءً على تفضيل العميل.
10. البيانات متعددة اللغات: يدعم ERPNext تخزين ترجمات لسجلات معينة (مثل أسماء الأصناف أو المصطلحات)[10]. على سبيل المثال، يمكننا تخزين اسم مطار باللغة الإنجليزية واللغة المحلية. قد نحافظ على حقول مخصصة منفصلة أو جدول فرعي للنصوص متعددة اللغات إذا لزم الأمر (مثل الأوصاف على موقع الويب بلغات متعددة).
11. توطين التنسيقات: إعداد كل مستخدم (أو كل شركة) لاستخدام تنسيقات التاريخ والأرقام وأحجام الورق المناسبة عبر إعدادات النظام[14]. على سبيل المثال، (e.g., US-based users might prefer MM-DD-YYYY dates, whereas others DD-MM-YYYY); يسمح ERPNext بإعدادات المنطقة الزمنية والتنسيق على مستوى المستخدم. سنتأكد من تكوينها بشكل صحيح بحيث يرى محاسب في المقر الرئيسي، على سبيل المثال، التواريخ بالتنسيق القياسي ولكن يمكن لمدير محطة في منطقة أخرى رؤيتها حسب العرف المحلي إذا لزم الأمر.
12. محتوى الدعم متعدد اللغات: باستخدام ClefinCode Chat أو قنوات أخرى، يمكننا الرد على الركاب بلغتهم. من الممكن تعيين وكلاء دعم لديهم مهارات لغوية لمحادثات معينة. لا يترجم النظام تلقائيًا، ولكن وجود ردود جاهزة بلغات متعددة يمكن أن يساعد الوكلاء. يمكننا دمج واجهة برمجة تطبيقات للترجمة للترجمة الفورية للدردشة إذا أردنا أن نكون متقدمين (ليس مطلبًا أساسيًا، ولكن فكرة لتحسين الدعم).
13. وثائق الموظفين: قد تحتاج سياسات الموارد البشرية، والكتيبات، وكتيبات السلامة، وما إلى ذلك، إلى لغات متعددة. يمكننا تخزين هذه المستندات في قاعدة المعرفة أو كمرفقات في ERPNext، مصنفة حسب اللغة.
14. العولمة مقابل التوطين: تجدر الإشارة إلى أن الامتثال القانوني الإقليمي غالبًا ما يرتبط باللغة - على سبيل المثال، تتطلب بعض البلدان أن تكون المستندات (مثل التذاكر أو الفواتير) بلغة محلية. يمكن لنظامنا استيعاب ذلك عن طريق إنتاج، على سبيل المثال، فاتورة باللغتين الإنجليزية والصينية لتذكرة تم بيعها في الصين. إذا لزم الأمر، نحافظ على قوالب متعددة اللغات لمثل هذه المستندات.

من خلال الاستفادة من إمكانيات ERPNext متعددة العملات ومتعددة اللغات، سيكون نظامنا جاهزًا للعالمية بشكل أساسي. يمكن للمستخدمين في جميع أنحاء العالم التفاعل بلغة وتنسيق مألوفين، وتتجمع البيانات المالية من مختلف العملات بسلاسة للإدارة[10][10]. يزيل هذا الحواجز أمام التبني عبر الفرق متعددة الجنسيات ويعزز راحة العملاء عند استخدام أدوات الخدمة الذاتية لشركة الطيران بلغتهم الأم.

المنطقة الزمنية والامتثال الإقليمي

عند العمل عبر مناطق زمنية وولايات قضائية مختلفة، يجب أن يحترم النظام الأوقات والقوانين المحلية في وظائفه:

1. إدارة المنطقة الزمنية: أوقات الرحلات حساسة للمنطقة الزمنية بطبيعتها. سنقوم بتخزين جميع أوقات جداول الرحلات بتنسيق متسق (likely UTC internally) إلى جانب المنطقة الزمنية المحلية لكل مطار. في نوع مستند الرحلة، يمكن عرض حقول المغادرة/الوصول بالوقت المحلي مع حقل منطقة زمنية مصاحب (e.g., “Departure: 10:00 [Asia/Dubai]”). داخليًا، قد نحفظ أيضًا طابعًا زمنيًا بتوقيت UTC للحسابات (مثل مدة الرحلة).
2. يمكن لخادم ERPNext العمل في منطقة زمنية افتراضية واحدة، ولكن يمكن للمستخدمين الفرديين تعيين تفضيلات المنطقة الزمنية الخاصة بهم. على سبيل المثال، يرى مستخدم في دبي الأوقات بتوقيت الخليج القياسي، بينما يمكن لمستخدم في نيويورك رؤيتها بتوقيت شرق الولايات المتحدة إذا تم تكوين النظام للتكيف حسب المنطقة الزمنية للمستخدم[15]. ومع ذلك، من أجل الاتساق، يجب عادةً تقديم أوقات الرحلات بالوقت المحلي للمطار بغض النظر عن المستخدم. من المحتمل أن نعرض كل من الوقت المحلي وربما توقيت UTC للوضوح.
3. الجدولة والتقويم: إذا قمنا بدمج أي عروض تقويم أو مخططات جانت للرحلات، فيجب مراعاة عبور منتصف الليل أو مشاكل خط التاريخ. من الممكن استخدام مكتبة خارجية أو منطق خادم دقيق للتعامل مع هذه التحويلات.
4. لتخزين البيانات، ضع في اعتبارك تخزين الأوقات بتوقيت UTC وحقل إزاحة أو منطقة زمنية منفصل لإعادة بناء الوقت المحلي. بهذه الطريقة تكون الحسابات (like time differences) أسهل في توقيت UTC. سيقوم النظام بعد ذلك بالتنسيق للإخراج.
5. الطابع الزمني لإجراءات المستخدم: تستخدم سجلات ERPNext وقت الخادم (which we might keep in UTC or in head office time). ستظهر أنشطة المستخدمين في مناطق زمنية مختلفة في ذلك الوقت المرجعي. لتجنب الالتباس، قد نعرض الأوقات المحلية للمستخدم في السجل أو نستخدم الأوقات النسبية ("قبل 5 دقائق") في واجهة المستخدم.
6. قواعد العمل الحساسة للمنطقة: تكوين منطق شرطي في ERPNext لفرض أو التكيف مع القوانين الإقليمية:
7. القواعد التشغيلية: على سبيل المثال، لدى بعض البلدان حظر تجول (no flights at night). يمكن أن تتضمن وحدة الجدولة قاعدة أنه إذا كان مطار المغادرة في مثل هذه المنطقة، فلا تسمح بالرحلات في الساعات المحظورة. يمكن أن يكون هذا تحققًا في نوع مستند الرحلة (التحقق من وقت المغادرة مقابل ساعات حظر التجول في المطار المخزنة في نوع مستند رئيسي للمطار).
8. قوانين العمل: كما تم التطرق إليه في الموارد البشرية، قد تختلف حدود واجب الطاقم حسب المنطقة أو السلطة الحاكمة لشركة الطيران (FAA vs EASA). نجعل هذه القواعد قابلة للتكوين. على سبيل المثال، تحديد نوع مستند تكوين "لوائح واجب الطيران" مع حقول للحد الأقصى للساعات في اليوم، في الأسبوع، وما إلى ذلك، اعتمادًا على المنطقة، وربط كل طاقم بمجموعة اللوائح التي تنطبق (إذا كانت شركة الطيران تعمل بمجموعات قواعد مختلفة لقواعد مختلفة). يستخدم مدقق تعارض الجدولة بعد ذلك القاعدة الصحيحة لكل طاقم.
9. العطلات المحلية: تتطلب بعض الولايات القضائية دفع أجر إضافي في العطلات الرسمية أو تقييد عمليات معينة في العطلات. يمكننا الحفاظ على قائمة عطلات لكل منطقة (يحتوي ERPNext على ميزة قائمة العطلات) وربط ذلك بالشروط، على سبيل المثال، التنبيه إذا تم جدولة رحلة في عطلة رئيسية حيث قد ينطبق تعويض إضافي للطاقم.
10. الامتثال القانوني والتوطين:
11. اختلافات قانون الضرائب: على سبيل المثال، إذا كانت شركة الطيران تبيع تذاكر في بلدان تنطبق فيها ضريبة القيمة المضافة/ضريبة السلع والخدمات، فيجب على النظام تطبيق الضريبة الصحيحة. سنقوم بربط قواعد الضرائب بأصل البيع أو موقع نقطة البيع. يمكن لقوالب الضرائب المرنة في ERPNext التعامل مع الضرائب الخاصة بالمنطقة (بما في ذلك الإعفاءات للنقل الدولي إن أمكن). على سبيل المثال، قد تتضمن تذاكر الرحلات الداخلية في البلد "أ" ضريبة قيمة مضافة بنسبة 5%، في حين أن التذاكر الدولية ذات معدل صفري. يمكن للنظام تحديد ذلك من بيانات المسار وتطبيق فئة الضريبة ذات الصلة.
12. إقامة البيانات والخصوصية: لقد تناولنا اللائحة العامة لحماية البيانات؛ علاوة على ذلك، تتطلب بعض البلدان تخزين بيانات العملاء داخل البلد (e.g., China or Russia have laws about citizen data). بالنسبة للعديد من شركات الطيران المستضافة مركزيًا، إذا كانت إحداها تعمل في مثل هذه الولاية القضائية، فقد نختار نشرًا هجينًا حيث يقوم خادم محلي بتخزين معلومات التعريف الشخصية الحساسة، مع مزامنة البيانات المعقمة مع ERPNext المركزي، أو استضافة موقع تلك الشركة على خادم في تلك المنطقة.
13. المحاسبة الإقليمية: إذا كان على شركة الطيران الإبلاغ عن البيانات المالية بمعايير مختلفة (like local GAAP vs IFRS)، فقد نحافظ على حسابات متوازية أو نستخدم تقارير البيانات المالية (Financial Statement reports) في ERPNext مع تخصيصها لتنسيقات مختلفة. قد يكون هذا عملًا يدويًا من قبل القسم المالي باستخدام بيانات ERPNext بدلاً من الأتمتة، ولكن البيانات يمكن الوصول إليها.
14. الآثار المترتبة على المنطقة الزمنية في العمليات: نظرًا لأن الرحلات تعبر مناطق زمنية، تأكد من أن الحسابات مثل مدة الرحلة أو واجب الطاقم تأخذ ذلك في الاعتبار. عادةً ما يحل حساب الفرق في توقيت UTC المشكلة. ولكن ضع في اعتبارك أيضًا تغييرات التوقيت الصيفي - حافظ على قاعدة بيانات محدثة للمناطق الزمنية للمطارات بحيث إذا حدث تغيير في التوقيت الصيفي، يتم تعديل أوقات الرحلات بشكل صحيح. (We might have to update airport time zone offsets manually if not coding a full tz integration. Possibly rely on Python’s pytz if available to calculate local times.)
15. يمكننا تخزين المطارات بسلسلة منطقة زمنية IANA واستخدامها في أي حسابات Python من جانب الخادم للأوقات المحلية.
16. أتمتة فحوصات الامتثال: قد تكون هناك فحوصات خاصة بالمنطقة مثل:
17. قبل المغادرة إلى البلد X، تأكد من إرسال APIS (يمكننا تمييز ذلك على أنه تم في النظام).
18. بالنسبة لمسارات معينة، تأكد من تقديم خطة طيران تشغيلية (إذا تم دمج تخطيط الرحلات، فقد يكون ذلك خارج النطاق).
19. حتى الحدود القانونية على التسعير في بعض الأسواق (e.g., some countries regulate ticket price ranges) - قم بدمج مثل هذه القواعد في منطق التسعير لتلك الأسواق.

من خلال دمج الوعي بالمنطقة الزمنية والقواعد الإقليمية في تصميم النظام، نمنع فئة كاملة من الأخطاء (مثل إظهار أوقات خاطئة أو انتهاك قانون محلي عن غير قصد). سيكون النظام مدركًا للسياق (context-aware): إنه يعرف أين يعمل ويتكيف سلوكه وفقًا لذلك. يمنح هذا شركة الطيران الثقة للتوسع في أسواق جديدة، مع العلم أن منصة ERPNext يمكنها استيعاب المتطلبات المحلية الجديدة بالتكوين أو تعديلات طفيفة بدلاً من إصلاح شامل.

الخدمات والتكاملات الإضافية

بالإضافة إلى العمليات الأساسية، سيشمل حل ERPNext الخاص بنا أو يتكامل مع العديد من الخدمات ذات القيمة المضافة (value-added services) لتعزيز قدرات شركة الطيران وتدفقات إيراداتها:

1. تتبع الرحلات في الوقت الفعلي (تكامل الرادار/نظام تحديد المواقع العالمي): يعد توفير حالة وموقع الرحلة المباشر ميزة قيمة لكل من الفرق الداخلية وراحة بال الركاب. سنتكامل مع خدمة تتبع الرحلات أو تغذية:
2. استخدام واجهات برمجة التطبيقات من مزودين مثل Flightradar24 أو ADS-B Exchange التي تقدم بيانات موقع الطائرات في الوقت الفعلي[16]. من خلال توفير معرفات رحلاتنا (رقم الذيل أو رقم الرحلة)، يمكننا استرداد خط العرض وخط الطول والارتفاع والأوقات المقدرة.
3. بالنسبة للعمليات الداخلية، يمكن لهذه البيانات أن تغذي ERPNext لتحديث حالة الرحلة تلقائيًا (e.g., “Departed”, “Landed” times when detected) ولعرض خريطة لجميع الرحلات الجوية على لوحة القيادة. يمكن أن يكون لدينا صفحة مخصصة في ERPNext مع خريطة (using Google Maps or OpenSky data) ترسم أسطولنا. هناك حتى ذكر لتكامل ERPNext مع الخرائط لرحلات التوصيل[17]، مما يشير إلى أنه يمكننا تضمين خريطة للرحلات أيضًا.
4. بالنسبة للركاب، يمكن أن يدمج تطبيق الجوال عرض خريطة للطائرة أثناء الطيران. يمكننا إما استخدام نفس واجهة برمجة التطبيقات مباشرة في التطبيق أو توجيهها من خلال ERPNext.
5. إذا كانت الخصوصية أو التكلفة مصدر قلق، فإن البديل هو التكامل مع نظام ACARS أو ADS-B لطائراتنا إذا كان لدينا أجهزة استقبال - ولكن استخدام واجهة برمجة تطبيقات موثوقة أبسط. يمكن أن يكون التكامل مهمة مجدولة تقوم بتحديث المواقع بشكل دوري.
6. الفوائد: يمكن لمراقبة العمليات مراقبة ما إذا كانت الرحلة تنحرف أو تتأخر في الوقت الفعلي. يحصل الركاب على أوقات وصول تقديرية دقيقة. كما أنه يفتح إمكانية الإشعارات الفورية مثل "رحلتك تحلق الآن فوق مدينة X".
7. تكامل خدمات الحجز من طرف ثالث: لتعظيم المبيعات، يجب أن يستوعب النظام الموزعين الخارجيين:
8. وكالات السفر عبر الإنترنت (OTAs): تتصل العديد من وكالات السفر عبر الإنترنت عبر GDS (تم تغطيتها بالفعل). ولكن بعض وكالات السفر عبر الإنترنت الأصغر أو أدوات حجز الشركات قد تفضل واجهة برمجة تطبيقات مباشرة. يمكننا كشف واجهة برمجة تطبيقات REST لمخزون رحلاتنا. على سبيل المثال، تطوير نقطة نهاية API تعيد الرحلات/المقاعد المتاحة بالنظر إلى الأصل والوجهة والتاريخ - بشكل أساسي كشف وظيفة البحث. ونقطة نهاية أخرى لإنشاء حجز (مع بعض المصادقة أو مفتاح API للشركاء). سيكون هذا هو تنفيذنا الخاص لمفهوم NDC (New Distribution Capability) الخاص بـ IATA، وهو واجهة برمجة تطبيقات XML/JSON حديثة لشركات الطيران لتقديمها للشركاء.
9. المشاركة بالرمز والخطوط المشتركة: إذا كنا نشارك مع شركات طيران أخرى، فقد نحتاج إلى تبادل الحجوزات. يتم ذلك عادةً عبر معايير الصناعة (EDI messages or IATA protocols) بدلاً من واجهات برمجة تطبيقات ERPNext. ومع ذلك، يمكننا إدارة مخزون رحلات الشركاء في نظامنا إذا لزم الأمر (مثل إذا كنا نبيع مقاعد على رحلات الشركاء).
10. البحث الوصفي: قد يتطلب التكامل مع محركات البحث الوصفي (Google Flights, Skyscanner) توفير تغذيات بيانات. يمكننا إنشاء تغذية في الوقت الفعلي أو مجدولة لرحلاتنا وأسعارنا (ربما بتنسيق XML أو JSON) لدفعها إلى تلك القنوات.
11. الدفع والتسوية مع الشركاء: إذا قامت أطراف ثالثة بالحجز، فنحن بحاجة إلى إدارة كيفية التعامل مع الدفع (ربما عبر مقاصة BSP أو إصدار فواتير للشريك بشكل دوري). يمكن لـ ERPNext التعامل مع ذلك عن طريق التعامل مع تلك الحجوزات كمبيعات ائتمانية للشريك ثم توقع الدفع لاحقًا.
12. توفير وثائق المطورين لواجهة برمجة التطبيقات الخاصة بنا (خارج نطاق ERPNext ولكن شيء يجب التخطيط له) حتى تجد الأطراف الثالثة أنه من السهل التكامل.
13. وحدة عمليات الشحن: غالبًا ما يكون نقل البضائع مصدر إيرادات كبير:
14. إنشاء نوع مستند شحنة بضائع (Cargo Shipment) لفواتير الشحن الجوي (AWB). سيلتقط الشاحن، المرسل إليه، الأصل، الوجهة، الوزن/الحجم، المحتويات، وما إلى ذلك، ويربط بواحدة أو أكثر من الرحلات (مباشرة أو متعددة المحطات). لا يزال من الممكن استخدام أمر المبيعات/الفاتورة في ERPNext لإصدار فواتير لهذه الشحنات، ولكن قد تكون هناك حاجة إلى واجهة مستخدم مخصصة لحجز البضائع.
15. إدارة سعة الشحن على الرحلات: دمج حقل في الرحلة لوزن الشحن المتاح. عند تعيين الشحنات لرحلة، قم بتجميع وزنها لضمان عدم تجاوز السعة (مع مراعاة أمتعة الركاب أيضًا).
16. التتبع: توفير تحديثات التتبع. يمكننا دمج مسح البضائع عند التحميل/التفريغ عبر تطبيق الجوال (مسح الرموز الشريطية لفاتورة الشحن الجوي لتمييزها على أنها محملة على الرحلة X، تم تفريغها في الوجهة). يمكن لـ ERPNext تحديث حالة الشحنة (“In Transit”, “Arrived at hub”, “Out for delivery” etc.). من المحتمل كشف بوابة عملاء لعملاء الشحن لتتبع حالة شحناتهم عن طريق رقم فاتورة الشحن الجوي (على غرار كيفية تتبعهم عبر FedEx وما إلى ذلك).
17. الجمارك والمستندات: إرفاق مستندات التخليص الجمركي أو إنشائها (مثل البيان، إعلان البضائع الخطرة إن أمكن) للشحنات.
18. ستعمل وحدة الشحن هذه بالتوازي مع وحدات الركاب ولكنها تشترك في الموارد (الرحلات، وربما بعض المخزون المشترك إذا كان البريد/الشحن يستخدم نفس المخازن). يمكن تطويرها كتطبيق ملحق أو داخل نفس التطبيق المخصص.
19. مناولة وتتبع الأمتعة: بينما تتعامل المطارات إلى حد كبير مع أنظمة الأمتعة، يمكن لشركة الطيران الاستفادة من ERPNext لبعض خدمات الأمتعة:
20. تتبع الأمتعة: إذا قمنا بدمج مسح الأمتعة، فيمكننا تسجيل أعداد الأمتعة المحملة مقابل المفرغة لكل رحلة. نهج بسيط هو ملاحظة إجمالي الحقائب المحملة في سجل الرحلة. نهج أكثر تقدمًا: تعامل مع كل بطاقة أمتعة كمعرف وقم بمسحها ضوئيًا، وتسجيلها في جدول الأمتعة. قد يكون هذا مفصلاً للغاية، ولكنه يمكن أن يساعد في حالة المخالفات.
21. المفقودات والموجودات: تنفيذ نوع مستند تتبع الأمتعة المفقودة. عندما يبلغ راكب عن أمتعة مفقودة، سجل التفاصيل (الاسم، رقم البطاقة، الوصف، الرحلة، الاتصال). يمكن لفريق الأمتعة تحديث هذه الحالة أثناء تتبع الحقيبة (تم العثور عليها/لم يتم العثور عليها، تم تسليمها للراكب، تم تقديم تعويض إذا فقدت). يمكن تكييف تتبع المشكلات في ERPNext لهذا الغرض، مع بعض الحقول الإضافية. إبقاؤه في ERP يعني أن خدمة العملاء يمكنها أيضًا التحقق من الحالة عندما يتصل الراكب.
22. الخطوط المشتركة للأمتعة: إذا كانت الرحلات متعددة المحطات، يمكن أن تكون عمليات نقل الأمتعة نقاط فشل. قد لا يتتبع النظام الحقيبة جسديًا، ولكن على الأقل إذا حدث فقدان للاتصال، فلدينا بيانات عن أي حقائب كانت على أي رحلة.
23. محاسبة وزن الأمتعة: قد نرغب في تسجيل إجمالي وزن الأمتعة لكل رحلة (لتخطيط الحمولة وأيضًا لفرض رسوم على الوزن الزائد). يمكن أن تتضمن عملية تسجيل الوصول تسجيل وزن الأمتعة لكل راكب ووضع علامة على رسوم الأمتعة الزائدة، والتي يمكننا إصدار فاتورة بها على الفور (نقطة بيع ERPNext أو رابط دفع عبر التطبيق).
24. التكامل مع نظام مناولة الأمتعة في المطار (BHS (Baggage Handling System)) معقد وغالبًا ما يكون غير مفتوح، ولكن يمكننا ربما استيراد بعض البيانات (مثل ملف مسح بطاقات الأمتعة) إذا تم توفيرها.
25. التنبؤ وتكامل التحليلات: (على الرغم من أن لدينا قسمًا منفصلاً عن التنبؤ، نذكر هنا أفكارًا إضافية مثل تخطيط المسار الموسمي أو الذكاء الاصطناعي.)
26. استخدام البيانات التاريخية من ERPNext لتشغيل نماذج تنبؤية (ربما خارج ERPNext باستخدام دفاتر Python أو أداة ذكاء الأعمال) لأشياء مثل التنبؤ بالطلب، واستراتيجية التسعير المثلى، والتنبؤ بالصيانة (كما ذكرنا).
27. ضع في اعتبارك التكامل مع منصة ذكاء أعمال أو استخدام Frappe Insights لاستكشاف أعمق للبيانات[18]. على سبيل المثال، يمكننا توصيل أداة مثل Power BI أو Metabase بقاعدة بيانات ERPNext للقراءة فقط لإنشاء تصورات مخصصة (إذا لم تكن مخططات ERPNext المدمجة كافية لبعض أصحاب المصلحة).
28. خدمات عملاء إضافية:
29. برنامج المسافر الدائم: لقد تطرقنا إلى نقاط الولاء في المحاسبة، ولكن من منظور الخدمة، قد ندمج نظام إدارة الولاء (loyalty management system). يمكن أن يكون هذا تطبيق ERPNext مخصص لتتبع تراكم الأميال، وحالة الفئة (Silver, Gold etc.)، والاستبدال. يمكننا السماح للعملاء باستبدال النقاط بتذاكر في تدفق الحجز (خصم النقاط وإصدار فاتورة بقيمة نقدية صفرية). يضيف هذا قيمة استراتيجية من خلال تشجيع الأعمال المتكررة.
30. تكامل بطاقات الائتمان ذات العلامة التجارية المشتركة: إذا كانت شركة الطيران لديها بطاقة ذات علامة تجارية مشتركة، فتكامل مع البنك لإيداع النقاط في وحدة الولاء في ERPNext أو التعامل مع الخصومات على التذاكر من خلال منطق بوابة دفع خاص (مثل خصم 10% عند استخدام بطاقتنا).
31. إدارة الإيرادات الإضافية: بيع الخدمات الإضافية مثل اختيار المقاعد، والأمتعة الإضافية، والصعود ذي الأولوية. يمكن لـ ERPNext إدراج هذه "كأصناف" إضافية مرفقة بفاتورة حجز. سيقدم تطبيق الجوال والبوابة هذه للشراء أثناء الحجز أو بعد الحجز. يحتاج هذا إلى امتداد بسيط للتعامل مع الحجز كحزمة من الخدمات (تذكرة + إضافات).
32. الملاحظات والاستطلاعات: بعد الرحلات، قم بتشغيل رسائل بريد إلكتروني أو دردشة آلية مع استطلاع ملاحظات. يمكن لـ ERPNext تخزين نتائج الملاحظات المرتبطة بالرحلات. هذا أقرب إلى إدارة علاقات العملاء، ولكنه يغلق الحلقة المتعلقة بجودة الخدمة. يمكن أن تؤدي التقييمات المنخفضة إلى إنشاء مشكلة لمتابعة خدمة العملاء.

كل من هذه الميزات والتكاملات الإضافية تجلب قيمة استراتيجية إما عن طريق توليد المزيد من الإيرادات، أو تحسين الكفاءة التشغيلية، أو تعزيز رضا العملاء. نظرًا لأن ERPNext مفتوح وقابل للتوسيع، يمكننا دمج هذه الأفكار بشكل تدريجي: على سبيل المثال، البدء بتسجيل الأمتعة الأساسي، ثم إضافة تتبع كامل لاحقًا؛ أو البدء بتعديلات نقاط الولاء اليدوية، ثم تنفيذ محرك نقاط كامل لاحقًا. تدعم البنية مثل هذا النمو دون تغييرات أساسية، حيث تميل هذه إلى أن تكون إما وحدات مخصصة جديدة أو توصيلات خدمة خارجية يمكن توصيلها بمنصتنا المركزية ERPNext.

نظرة عامة على البنية التقنية

بنية عالية المستوى لحل الطيران القائم على ERPNext. جوهر النظام هو خادم ERPNext (المبني على إطار عمل Frappe) الذي يضم جميع منطق العمل ونماذج قواعد البيانات وسير العمل لشركة الطيران. تعمل هذه النسخة المركزية من ERPNext (أو مجموعة لموازنة التحميل) على خادم تطبيقات Python مع قاعدة بيانات MariaDB، باتباع بنية ERPNext ثلاثية الطبقات (قاعدة البيانات - الخادم - واجهة الويب الأمامية)[19]. يحيط بهذا الجوهر مكونات وواجهات متكاملة مختلفة:

1. تطبيقات الجوال (Flutter) للركاب والموظفين تتصل بـ ERPNext عبر نقاط نهاية واجهة برمجة تطبيقات REST الخاصة به[4]. تتم جميع عمليات تبادل البيانات (البحث عن الرحلات، الحجوزات، جلب الجداول، إلخ) من خلال استدعاءات API آمنة (HTTPS, using API keys or token auth). وبالتالي تعمل تطبيقات الجوال كعملاء للواجهة الأمامية بينما يكون ERPNext هو الواجهة الخلفية. وبالمثل، تتواصل أي بوابات ويب (سواء كان موقعًا مستضافًا على ERPNext أو تطبيق ويب خارجي في Vue/Python) عبر نفس واجهة برمجة التطبيقات. يضمن هذا الفصل إمكانية تطوير واجهة المستخدم/تجربة المستخدم بشكل مستقل أو توسيعها، بينما يظل ERPNext هو المصدر الوحيد للحقيقة للبيانات.
2. تم دمج ClefinCode Chat كـ تطبيق Frappe وخدمة خارجية (Frappe app and external service). يتفاعل مع ERPNext مباشرة (مثبت على نفس المنصة) لاسترداد سياق المستخدم وإرسال/استقبال الرسائل. كما يتصل بقنوات خارجية مثل WhatsApp للمراسلة متعددة القنوات[6]. في الرسم التخطيطي، يعمل ClefinCode Chat كخدمة جانبية (sidecar service): يدفع ERPNext الإشعارات (على سبيل المثال، تنبيهات تأخير الرحلات) إلى خادم الدردشة، والذي يقوم بعد ذلك بنشرها على أجهزة المستخدمين أو القنوات. تطبيق الدردشة، كونه مفتوح المصدر ومدعومًا بـ ERPNext[5]، يشارك قاعدة البيانات أو لديه رابط محسن لها، مما يتيح تكاملًا عميقًا (مثل الإشارة إلى حجز في دردشة).
3. الأنظمة الخارجية وواجهات برمجة التطبيقات: تم تصوير العديد من عمليات التكامل الخارجية، كل منها عبر واجهة برمجة تطبيقات آمنة أو خدمة موصل:
4. أنظمة التوزيع العالمية (GDS) – (e.g., Amadeus, Sabre) – يتم توصيلها من خلال طبقة تكامل. قد يكون هذا خادمًا وسيطًا يترجم بيانات ERPNext إلى تنسيق GDS والعكس صحيح. على سبيل المثال، عند إجراء حجز في GDS، يستخدم الوسيط واجهة برمجة تطبيقات ERPNext لإنشائه في نظامنا[8]. عند تحديث الرحلات في ERPNext، يرسل الوسيط تحديثات إلى GDS. يضمن هذا مزامنة المخزون بين قنواتنا الأساسية والتوزيع.
5. بوابات الدفع – يتكامل ERPNext إما مباشرة عبر التطبيق أو من خلال خدمة وسيطة مع بوابات مثل Stripe و PayPal وما إلى ذلك. في الرسم التخطيطي، يتواصل ERPNext مع بوابة الدفع لطلبات الشحن ويتلقى تأكيدات (webhooks) مرة أخرى، محدثًا حالة الدفع[7].
6. تتبع الرحلات (Radar/GPS API): تغذية من خدمة تتبع الرحلات تدخل بيانات الموقع/الحالة في الوقت الفعلي إلى ERPNext (ربما عبر خدمة صغيرة تستدعي واجهة برمجة التطبيقات ثم تقوم بتحديث حالات نوع مستند الرحلة لدينا). في الرسم التخطيطي، هذا مصدر بيانات وارد يسمى "Radar/GPS"، يوضح كيفية تدفق البيانات الخارجية (إحداثيات الطائرة، تحديثات وقت الوصول المقدر) إلى نظام تخطيط موارد المؤسسات.
7. أنظمة الصيانة الخارجية: إذا كان لدينا أي أنظمة لمقدمي خدمات الصيانة من طرف ثالث أو تغذيات إنترنت الأشياء (مثل مراقبة صحة المحرك)، فيمكن أن تتكامل هذه الأنظمة عبر واجهات برمجة التطبيقات أيضًا. على سبيل المثال، يمكن لنظام خارجي إرسال تنبيه إلى ERPNext عند اكتشاف خطأ في منتصف الرحلة، مما يؤدي إلى إنشاء طلب صيانة. على العكس من ذلك، يمكن لـ ERPNext إرسال أوامر عمل أو طلبات شراء إلى نظام MRO خارجي. يضمن هذا السهم ذو الاتجاهين في البنية مشاركة معلومات الصيانة.
8. أنظمة المطار (الأمن/الشرطة): في حين أن التكامل المباشر قد يكون محدودًا، من الناحية النظرية، سيحدث أي تبادل للبيانات مع أنظمة سلطة المطار (مثل إرسال بيانات الركاب، أو تلقي التصاريح الأمنية) من خلال نقل ملفات آمن أو واجهة برمجة تطبيقات. يظهر هذا ككيان خارجي (أنظمة المطار) مع واجهة لـ ERPNext لإرسال التنبيهات (مثل إشعار لأمن المطار حول راكب أو حادث معين) وتلقي البيانات (مثل حالة الأمان المحدثة).
9. قاعدة البيانات والبنية التحتية: تدور كل هذه المكونات حول قاعدة البيانات المركزية. إذا تم خدمة عدة شركات طيران (متعددة المستأجرين)، فإما أن تحصل كل منها على قاعدة بيانات منفصلة (في إعداد متعدد المواقع) أو تشترك في واحدة مع فصل الشركات. سيظهر الرسم التخطيطي في حالة متعددة المستأجرين عدة مثيلات لمواقع ERPNext تتصل إما بقواعد بيانات منفصلة أو بيئة قاعدة بيانات واحدة مقسمة، ولكنها تشترك في خدمات التكامل. من المحتمل أن نختار قواعد بيانات منفصلة لكل مستأجر لعزل البيانات[1]، وطبقة تكامل مشتركة توجه إلى الموقع الصحيح.
10. التوسع وإدارة الأحمال: يمكن توسيع طبقة تطبيق ERPNext أفقيًا (عدة عمال gunicorn خلف موازن تحميل) ويمكن أن تكون قاعدة البيانات مجموعة (Master-Slave or Cluster for high availability). تدعم البنية النشر السحابي حيث تعمل هذه الخدمات على أجهزة افتراضية أو حاويات. للحصول على إنتاجية عالية (مثل التعامل مع العديد من استدعاءات واجهة برمجة التطبيقات من تطبيقات الجوال)، يعد تمكين التخزين المؤقت (Redis) والعمال غير المتزامنين (للوظائف الخلفية مثل إرسال الإشعارات أو التقارير الثقيلة) جزءًا من بنية إطار عمل Frappe[19].
11. طبقات الأمان: تستخدم جميع الاتصالات التشفير (HTTPS, VPN for on-prem systems to cloud, etc.). سيتعامل الوسيط التكاملي مع المصادقة لواجهات برمجة التطبيقات الخارجية ويحمي واجهة برمجة تطبيقات ERPNext بالمفاتيح. كما نستخدم قواعد جدار الحماية وربما بوابة واجهة برمجة تطبيقات لتنظيم وتأمين الوصول الخارجي إلى ERPNext.

باختصار، البنية هي نموذج المحور والأذرع (hub-and-spoke model) مع ERPNext في المحور. ينسق مختلف الأذرع: التطبيقات التي تواجه المستخدم، وخدمات الاتصال، وتكاملات الأنظمة الخارجية. يضمن هذا التصميم المعياري أنه إذا احتاج أحد المكونات (لنقل تطبيق الجوال أو خادم الدردشة) إلى التحديث أو الاستبدال، فيمكن القيام بذلك دون تعطيل الآخرين، طالما ظلت عقود واجهة برمجة التطبيقات متسقة. يؤكد الرسم التخطيطي على كيفية تدفق البيانات من وإلى ERPNext، مما يعزز أنه المنصة المركزية لجميع عمليات شركات الطيران وإدارة البيانات.

بنية النشر ومقارنة النماذج

يتطلب نشر نظام تخطيط موارد المؤسسات لشركة طيران اختيار نموذج البنية التحتية المناسب لتحقيق التوازن بين الموثوقية والتكلفة والتحكم والامتثال. نحن نأخذ في الاعتبار النشر السحابي مقابل المحلي مقابل الهجين (Cloud vs On-Premises vs Hybrid)، بالإضافة إلى كيفية هيكلة استضافة شركات طيران متعددة. فيما يلي مقارنة لنماذج النشر:

اعتبارات متعددة المستأجرين مقابل متعددة الشركات: إذا كنا نخدم عدة شركات طيران على منصة واحدة، فلدينا استراتيجيتان:

1. متعددة الشركات (مستأجر واحد): موقع ERPNext واحد، عدة شركات[1]. أسهل في صيانة مثيل واحد؛ يمكن للشركات مشاركة التكوين (إذا كان مقصودًا) والبيانات الرئيسية إذا لزم الأمر (اختياريًا). لكن البيانات مختلطة في قاعدة بيانات واحدة (مع فصل الشركات)، لذا فإن خطأ في الإذن يمكن أن يكشف البيانات بين شركات الطيران - يلزم الحذر الشديد. أيضًا، يمكن أن يؤثر الحمل الثقيل من قبل شركة طيران واحدة على الآخرين لأن الموارد مشتركة.
2. متعددة المستأجرين (مواقع معزولة): موقع ERPNext منفصل (وقاعدة بيانات) لكل شركة طيران[1]. يوفر هذا عزلًا قويًا للبيانات ومرونة - يمكن إيقاف شركة طيران واحدة للصيانة دون التأثير على الآخرين. أيضًا أسهل في تخصيص موقع واحد بشكل مختلف قليلاً إذا لزم الأمر. لا يزال بإمكاننا استضافة هذه على نفس الخوادم (منصة مع مواقع متعددة) أو حاويات/أجهزة افتراضية منفصلة لمزيد من العزل. هذا هو النهج الموصى به إذا كنا نقدم خدمة لشركات طيران غير مرتبطة.

بالنظر إلى هدف وجود منصة مركزية لشركات طيران متعددة، فإن النشر السحابي متعدد المستأجرين جذاب: على سبيل المثال، استخدام Kubernetes أو Docker لاستضافة حاويات مواقع ERPNext متعددة، كل منها بقاعدة بيانات خاصة به، خلف بوابة مشتركة. يمكن للخدمات المشتركة مثل خادم الدردشة أو بوابة واجهة برمجة التطبيقات خدمة الجميع، ولكن تطبيق كل موقع وقاعدة بياناته منفصلان. بهذه الطريقة، عندما نضيف عملاء طيران جدد، نقوم بتشغيل حاوية جديدة بالتكوين القياسي - مما يجعل التوسع خطيًا.

الأمن والامتثال في النشر: بغض النظر عن النموذج، يجب علينا تنفيذ أفضل الممارسات:

1. نسخ احتياطية منتظمة (آلية ليلية، مع تخزين خارج الموقع للتعافي من الكوارث). إذا كان سحابيًا، فاستخدم خدمة النسخ الاحتياطي للمزود؛ إذا كان محليًا، فاحصل على نسخ احتياطية عن بعد ربما إلى التخزين السحابي.
2. التشفير: ضمان SSL لجميع حركة مرور الويب (ربما باستخدام CDN أو إنهائه عند موازن التحميل). قم بتشفير البيانات في حالة السكون إن أمكن (غالبًا ما تفعل خدمات قواعد البيانات السحابية ذلك، يمكن للنشر المحلي استخدام تشفير القرص).
3. التحكم في الوصول: حدد من (خاصة البائعين الخارجيين أو المسؤولين) يمكنه الوصول إلى الخوادم. استخدم شبكات VPN ومربعات القفز الآمنة للوصول الإداري.
4. المراقبة: إعداد المراقبة لوقت التشغيل والأداء (تحتوي السحابة على أدوات مثل CloudWatch، يمكن للنشر المحلي استخدام أدوات مفتوحة المصدر مثل Zabbix أو Grafana). تنبيهات لأي وقت توقف أو حالات شاذة لفريق الدعم.

في الختام، توصيتنا يمكن أن تكون استخدام النشر السحابي لقابليته للتوسع وانخفاض عبء الإدارة، ما لم تملي ظروف معينة النشر المحلي (مثل شركة طيران مملوكة للحكومة لديها سياسات ضد السحابة). قد يتم استخدام نهج هجين في المرحلة المؤقتة (على سبيل المثال، الاحتفاظ بالبيانات الحساسة على قاعدة بيانات محلية تتكاثر إلى خوادم التطبيقات السحابية). سيتم تفصيل النموذج المختار في خطة تنفيذ، لكن المقارنة أعلاه توفر إرشادات بشأن المقايضات لقيادة شركة الطيران لاتخاذ قرار.

خارطة طريق التنفيذ

سيكون تنفيذ هذا النظام الشامل مشروعًا كبيرًا. يضمن النهج التدريجي إمكانية الإدارة ويسمح بالتسليم التدريجي للقدرات. فيما يلي خارطة طريق عالية المستوى مع مراحل:

1. الاكتشاف والتخطيط (الشهر 0-1): جمع المتطلبات التفصيلية من جميع أصحاب المصلحة - الحجوزات، مراقبة العمليات، الموارد البشرية، الصيانة، المالية، إلخ. توثيق تدفقات العمليات وتحديد أي أنظمة خارجية حرجة. تحديد نطاق المشروع ومعايير النجاح. تشكيل فريق التنفيذ (خبراء ERPNext، مطورون، خبراء المجال). أيضًا، وضع اللمسات الأخيرة على بنية النشر (اختيار سحابي/محلي، تحديد متعدد المستأجرين مقابل مستأجر واحد، إلخ) وشراء البنية التحتية أو الحسابات اللازمة.
2. إعداد النظام الأساسي (الشهر 1-2): تثبيت ERPNext (أحدث إصدار) في البيئة المختارة. إعداد الهيكل الأساسي: إنشاء الشركات (لكل شركة طيران أو كيان)، تكوين العملات الأساسية، تمكين المجالات (مثل الموارد البشرية، الحسابات). استيراد البيانات الرئيسية مثل المطارات، الطائرات (الأصول)، قالب دليل الحسابات الأساسي، والبيانات الرئيسية للموارد البشرية (الموظفون، الأدوار). خلال هذه المرحلة، قم أيضًا بتطوير هيكل تطبيق الطيران المخصص مع أنواع المستندات الأولية: الرحلة، المسار، الحجز، إلخ، دون وظائف كاملة بعد. تحقق من أن ERPNext القياسي يعمل للوحدات القياسية (المبيعات، المشتريات، الموارد البشرية) كخط أساس.
3. تطوير الوحدة المخصصة (الشهر 2-4): تطوير واختبار كل وظيفة مخصصة رئيسية بشكل تكراري:
4. جدولة الرحلات والمخزون: بناء نوع مستند الرحلة، وعرض قائمة الرحلات، ومنطق مخزون المقاعد. إنشاء ربط الحجوزات بالرحلات.
5. سير عمل الحجز: تنفيذ منطق واجهة المستخدم للحجز (يمكن البدء بنموذج ويب بسيط للاختبار الداخلي)، وآلية التسعير، وإنشاء الفواتير. دمج بوابة دفع اختبارية (like sandbox of Stripe) لضمان التدفق من البداية إلى النهاية.
6. التكاملات - المرحلة الأولى: على الأقل قم بإعداد تكاملات وهمية أو تدفقات أساسية. على سبيل المثال، صمم كيفية عمل تكامل GDS (ربما قم بتنفيذ برنامج نصي صغير لمحاكاة حجز وارد من GDS للاختبار). أيضًا، قم بدمج ClefinCode Chat مبكرًا حتى يتمكن أعضاء الفريق من استخدامه أثناء UAT للاتصالات ونتأكد من أنه يعمل في بيئتنا.
7. تخصيص الموارد البشرية: أدخل بيانات موظفين عينية، واختبر ميزات الجدولة (ربما قم بعمل جدول أولي لأسبوع واحد من الرحلات)، وقم بتعديل نماذج وحدة الموارد البشرية.
8. وحدة الصيانة: قم بإعداد طائرة واحدة بجدول صيانة وقم بإنشاء سجل صيانة وهمي لضمان أن تدفقات صيانة الأصول منطقية.
9. استخدام نهج رشيق: كل أسبوعين إلى ثلاثة أسابيع، ركز على مجموعة من الميزات وقم بعرضها على المستخدمين الرئيسيين للحصول على ملاحظات، بدلاً من بناء كل شيء دفعة واحدة.
10. الاختبار والتكرار (الشهر 4-6): إجراء اختبار شامل:
11. اختبار الوحدة: يكتب المطورون حالات اختبار للكود المخصص الحرج (like pricing calculations, booking confirmation, etc.).
12. اختبار التكامل: محاكاة سيناريوهات حقيقية: قم بإجراء حجوزات عبر تطبيق الجوال (أو واجهة اختبار إذا لم يكن التطبيق جاهزًا)، وتأكد من أن سجلات ERPNext صحيحة؛ قم بمحاكاة تأخير رحلة وشاهد الإشعارات تخرج؛ قم بتشغيل دورة كشوف رواتب مع بيانات الجدول؛ إلخ.
13. اختبار الأداء: مع أحجام بيانات واقعية (import e.g. 1000 flights, 100k dummy bookings)، شاهد كيف يعمل النظام. قم بتحسين الاستعلامات أو إضافة فهارس حسب الحاجة.
14. في هذه المرحلة، من المحتمل وجود تكرارات متعددة: ابحث عن الأخطاء، أصلحها، وحسن سير العمل من أجل سهولة الاستخدام. تأكد أيضًا من أن الأذونات تم تعيينها بشكل صحيح (على سبيل المثال، لا يمكن لمستخدم شركة طيران رؤية بيانات شركة أخرى إذا كان النظام متعدد المستأجرين).
15. إشراك المستخدمين النهائيين الفعليين (مثل وكلاء الحجز، والمحاسبين، ومجدولي الطاقم) في UAT (User Acceptance Testing) مع بيئة اختبار وسيناريوهات عينية. ستعمل ملاحظاتهم على تحسين واجهة المستخدم والعملية (ربما ندرك أننا بحاجة إلى زر إعادة حجز سريع، أو تقرير إضافي).
16. ترحيل البيانات (الشهر 6-7): إذا تم استبدال الأنظمة القديمة، قم بترحيل البيانات التاريخية اللازمة:
17. استيراد جدول الرحلات القادمة من النظام القديم (بحيث تكون جميع الرحلات المستقبلية موجودة في ERPNext).
18. ترحيل الحجوزات الحالية (أو على الأقل الحجوزات المفتوحة) إلى تنسيق ERPNext، بما في ذلك أرقام سجلات الركاب، والمدفوعات، وتعيينات المقاعد.
19. ترحيل البيانات الرئيسية مثل حسابات المسافر الدائم، إن وجدت.
20. البيانات المالية: تحديد تاريخ الانتقال للحسابات. من المحتمل البدء من جديد في فترة مالية وإحضار الأرصدة الافتتاحية إلى ERPNext.
21. التحقق من صحة البيانات المرحّلة عن كثب مع أصحاب المصلحة (على سبيل المثال، هل تتطابق المجاميع في المالية، هل تبدو عينة عشوائية من الحجوزات صحيحة).
22. التدريب وتطوير إجراءات التشغيل القياسية (الشهر 7): تدريب مجموعات مستخدمين مختلفة:
23. استخدام نهج تدريب المدربين أو التدريب المباشر حسب حجم المنظمة. توفير جلسات عملية لوكلاء الحجز، وموظفي تسجيل الوصول، ومستخدمي المالية، وما إلى ذلك، باستخدام النظام شبه النهائي.
24. إنشاء إجراءات تشغيل قياسية (SOPs) وأدلة مرجعية سريعة مصممة لمهام المستخدم (how to create a group booking, how to issue a refund, how to update a maintenance record, etc.). استغل دليل ERPNext إذا كان متاحًا للأجزاء العامة، ولكن استكمله بخطوات خاصة بشركة الطيران.
25. ربما قم بإجراء محاكاة أو تدريبات (على سبيل المثال، محاكاة سيناريو تأخير كبير مع الفريق للتدرب على استخدام النظام للتعامل معه).
26. إطلاق التشغيل (الشهر 8): اختيار استراتيجية إطلاق التشغيل:
27. الانفجار الكبير: تحويل جميع الوظائف إلى النظام الجديد في تاريخ محدد. من الممكن القيام بذلك في بداية موسم أو ربع عندما تتغير جداول الرحلات.
28. التدريجي: تشغيل وحدات معينة واحدة تلو الأخرى. على سبيل المثال، ابدأ باستخدام ERPNext للمحاسبة والموارد البشرية في المكتب الخلفي أولاً مع الاستمرار في تشغيل نظام خدمة الركاب القديم للحجوزات، ثم قم بالتحويل لاحقًا للحجوزات. أو قم بتشغيل الرحلات الداخلية على النظام الجديد أولاً، ثم الدولية لاحقًا. ومع ذلك، يمكن أن يكون التدريجي معقدًا بسبب نقاط التكامل.
29. ضمان وجود دعم (فريق تكنولوجيا المعلومات وفريق التنفيذ) أثناء الانتقال والأيام الأولى من التشغيل لحل المشكلات بسرعة.
30. التشغيل الموازي (إذا كان ممكنًا): يستخدم أحيانًا للمالية - تشغيل الأنظمة القديمة والجديدة بالتزامن لفترة للتحقق من تطابق المخرجات. بالنسبة للحجوزات، التشغيل الموازي غير عملي خارج بيئة الاختبار.
31. الدعم بعد التشغيل والتحسينات (الشهر 9 فصاعدًا): بعد التشغيل، ستكون هناك فترة استقرار:
32. مراقبة استخدام النظام، والأداء، وأي أخطاء. إصلاح الأخطاء على الفور. ربما عقد اجتماعات تحقق يومية مع فريق العمليات للأسبوع الأول لاكتشاف أي نقاط ضعف.
33. توفير دعم مكتب مساعدة إضافي للمستخدمين أثناء تكيفهم.
34. جمع طلبات التحسين: مع استخدام المستخدمين للنظام بالكامل، ستظهر أفكار أو احتياجات جديدة (e.g., “We need a report that wasn’t identified before” or “Can we integrate X tool as well?”).
35. تخطيط تحديثات تدريجية أو مرحلة ثانية لتنفيذ الميزات الجيدة التي كانت خارج النطاق الأولي أو التحسينات الطفيفة (مثل المزيد من الأتمتة، ولوحات معلومات التحليلات المتقدمة، أو إضافة تلك الميزات الاستراتيجية الإضافية مثل روبوتات الدردشة أو تكاملات الشركاء الجديدة).
36. إجراء مراجعة بعد التنفيذ مع أصحاب المصلحة الرئيسيين لتوثيق الدروس المستفادة والتأكد من تحقيق جميع الأهداف.

خلال خارطة الطريق، تعد إدارة المشروع حاسمة: جداول زمنية واضحة، ومسؤوليات، وتحديثات حالة منتظمة للقيادة. يجب إجراء إدارة المخاطر (e.g., what if a critical integration isn’t ready – have a workaround plan) في التخطيط. تأكد أيضًا من الموافقات التنظيمية إذا لزم الأمر (قد تحتاج بعض سلطات الطيران المدني إلى الموافقة على أنظمة جديدة لأشياء مثل سجلات الصيانة أو وظائف DCS؛ تواصل معهم مبكرًا إذا لزم الأمر).

باتباع خارطة الطريق هذه، يتم تقسيم المشروع إلى أجزاء يمكن التحكم فيها مع إشراك مستمر للمستخدمين النهائيين، مما يزيد بشكل كبير من فرصة التنفيذ الناجح الذي يلبي جميع المتطلبات الوظيفية والتقنية.

ملخص الوحدات الوظيفية

يتطلب تنفيذ حل شركات الطيران مزيجًا من وحدات ERPNext الأساسية، والوحدات المطورة خصيصًا، ومكونات التكامل. فيما يلي قائمة موجزة بـ الوحدات/المكونات الوظيفية الرئيسية (key functional modules/components) والغرض منها، مع الإشارة إلى أيها قياسي مقابل مخصص:

1. عمليات الطيران (وحدة مخصصة): الغرض: إدارة جداول الرحلات، وتعيين الطائرات، ومخزون المقاعد. تشمل: نوع مستند رئيسي للرحلة (أوقات الجدول، الطائرة، المسار، الحالة)، نوع مستند رئيسي للمسار، قوالب تكوين المقاعد، وربما عرض جانت للجداول. النوع: تطبيق مخصص (Custom App) – مصمم خصيصًا لعمليات شركات الطيران، ويرتبط بالأساس (e.g., linking to Asset for aircraft).
2. الحجز والتذاكر (مزيج مخصص وأساسي): الغرض: التعامل مع حجوزات الطيران، وإصدار التذاكر، والتعديلات، والإلغاءات. تشمل: نوع مستند للحجز أو استخدام أمر المبيعات/الفاتورة مع حقول مخصصة واسعة لتفاصيل الرحلة[2]، منطق تكامل الدفع، آلية ترقيم التذاكر/سجلات الركاب، ومعالجة استرداد الأموال. النوع: مخصص (لمنطق سجل الركاب وواجهة المستخدم) بالإضافة إلى وحدة البيع في ERPNext لأمر المبيعات/الفاتورة الأساسي وإدخالات الدفع.
3. إدارة الركاب (وحدة إدارة علاقات العملاء الأساسية موسعة): الغرض: الحفاظ على بيانات الركاب وطلبات الخدمة الخاصة. تشمل: نوع مستند العميل/الراكب مع ملحقات (معلومات جواز السفر، معرف الولاء)، وجدول فرعي لكل حجز (أو رابط من الحجز إلى العميل). قد يشمل أيضًا وحدة فرعية لبرنامج المسافر الدائم إذا تم تنفيذه (tracking points). النوع: وحدة إدارة علاقات العملاء الأساسية مع حقول/أنواع مستندات مخصصة لمعلومات إضافية.
4. تسجيل الوصول والصعود (وحدة مخصصة): الغرض: دعم عملية التحكم في المغادرة (DCS). تشمل: نوع مستند لتسجيل الوصول (أو استخدام حالة مستند الحجز) لتمييز المقاعد على أنها تم تسجيل وصولها، وإنشاء تنسيق طباعة بطاقة الصعود، ونوع مستند للصعود لمسح وتسجيل الركاب الذين صعدوا، وحقول مناولة الأمتعة. النوع: مخصص، متكامل مع الحجوزات الأساسية.
5. التموين والخدمات على متن الطائرة (امتداد مخصص للمخزون): الغرض: إدارة سلسلة توريد التموين والمبيعات على متن الطائرة. تشمل: نوع مستند لطلب تموين الرحلة، ومخزون على متن الطائرة (يمكن استخدام مستندات إدخال المخزون)، وأصناف للتموين والأسواق الحرة، وربما واجهة نقطة بيع للمبيعات على متن الطائرة. النوع: وحدة المخزون في ERPNext بالإضافة إلى تخصيص لتخطيط التموين.
6. وحدة الشحن والأمتعة (مخصصة اختيارية): الغرض: إدارة شحنات الشحن الجوي وتتبع حوادث الأمتعة. تشمل: نوع مستند للشحنة/فاتورة الشحن الجوي، والتكامل مع الرحلات (تخصيص مساحة الشحن)، وتتبع حوادث الأمتعة. النوع: مخصص، يمكن تنفيذه في مرحلة لاحقة (اختياري إذا كانت شركة الطيران تقوم بالشحن).
7. الموارد البشرية وإدارة الطاقم (وحدة الموارد البشرية الأساسية موسعة): الغرض: الإشراف على الموظفين، وخاصة جداول الطاقم وكشوف المرتبات. تشمل: نوع مستند الموظف موسع للتراخيص/التدريب، واجهة جدولة المناوبات/الجداول (واجهة مستخدم مخصصة تستفيد من الموارد البشرية في ERPNext)، وإدارة الإجازات للطاقم، وسجلات التدريب. يغطي أيضًا جدولة الموظفين الأرضيين. النوع: وحدة الموارد البشرية في ERPNext مع برامج نصية/أنواع مستندات مخصصة (e.g., Crew Roster doctype).
8. مراقبة العمليات والعمليات غير المنتظمة (سير عمل مخصص): الغرض: إدارة التأخيرات والإلغاءات والحوادث. تشمل: نوع مستند لتقرير المخالفة/التأخير، وإشعارات آلية، وتعيينات مهام للتعامل مع الاضطرابات، ونوع مستند لتقرير الحادث/السلامة. النوع: مخصص (على الرغم من أنه يمكن إعادة استخدام أنواع مستندات المشكلة/المهمة في ERPNext مع تخصيص).
9. الصيانة والهندسة (وحدة الأصول الأساسية موسعة): الغرض: تتبع صيانة الطائرات، وتصحيح العيوب، والامتثال. تشمل: سجلات الأصول (الطائرات)، ونوع مستند لجدول الصيانة (مخصص أو باستخدام صيانة الأصول في ERPNext)[3]، وسجل الصيانة، واستخدام مخزون قطع الغيار (رابط إلى المخزون)، ونوع مستند لتتبع AD/SB. النوع: وحدة إدارة الأصول في ERPNext بالإضافة إلى تحسينات مخصصة للجدولة وتتبع الصيانة القائمة على الاستخدام.
10. المحاسبة والمالية (وحدة المحاسبة الأساسية مع قواعد مخصصة): الغرض: التعامل مع جميع المعاملات المالية، والعملات المتعددة، وإعداد التقارير. تشمل: دليل حسابات مصمم لشركة الطيران، وأتمتة قيود اليومية للاعتراف بالإيرادات، وإعداد مركز التكلفة حسب الرحلة أو المسار، والفواتير والمدفوعات متعددة العملات[10]، والتكامل مع الأنظمة المالية الخارجية إن وجدت. يغطي أيضًا الفوترة من خلال BSP إذا لزم الأمر (يمكن أن تكون عملية يدوية خارج ERPNext ولكن يتم تسجيل النتائج في ERPNext). النوع: وحدة الحسابات في ERPNext (مكوّنة على نطاق واسع، ولكن استخدام الوحدة القياسية؛ بعض البرامج النصية المخصصة لقيود اليومية الآلية والتقارير المتخصصة).
11. الاتصالات ودعم العملاء (تطبيق متكامل): الغرض: توفير اتصالات قائمة على الدردشة للدعم والتعاون الداخلي. تشمل: تطبيق ClefinCode Chat متكامل[5] – قنوات للدعم، والاتصالات الداخلية، وتكامل WhatsApp، وربما نظام مكتب مساعدة/تذاكر (يحتوي ERPNext على وحدة دعم مع مشكلات يمكننا استخدامها لشكاوى العملاء التي ليست دردشة مباشرة). النوع: تطبيق Frappe من طرف ثالث (ClefinCode) بالإضافة إلى وحدة الدعم في ERPNext إذا لزم الأمر.
12. التحليلات وإعداد التقارير (أساسي مع ملحقات): الغرض: إنشاء تقارير تشغيلية واستراتيجية. تشمل: تقارير قياسية (بيانات مالية، مستويات المخزون، تقارير الموارد البشرية) وتقارير مخصصة: الأداء في الوقت المحدد، عامل الحمولة لكل رحلة، الإيرادات لكل مسار، تكلفة الصيانة لكل طائرة، إلخ. ربما لوحات معلومات تجمع البيانات (مخططات لوحة المعلومات في ERPNext أو تكامل ذكاء الأعمال). النوع: وحدة التقارير الأساسية في ERPNext (استعلامات مخصصة، تقارير نصية) واختياريًا تكامل ذكاء الأعمال للتحليلات المتقدمة[12].
13. خدمات التكامل (موصلات خارجية): الغرض: ربط ERPNext بالأنظمة الخارجية. تشمل: خدمة تكامل GDS (يمكن أن تكون تطبيقًا وسيطًا مستقلاً)، وموصلات بوابة الدفع (سنستخدم الموجودة حيثما أمكن[7])، وبرنامج نصي لتكامل تغذية بيانات الرحلات، وكشف واجهة برمجة التطبيقات للأطراف الثالثة. النوع: مشاريع خارجية (من المحتمل أن تكون خدمات مصغرة بلغة Python/Node) تستخدم واجهة برمجة تطبيقات REST الخاصة بـ ERPNext وواجهات برمجة التطبيقات الخارجية لمزامنة البيانات.

كل من هذه الوحدات إما مطلوب للتشغيل الأساسي أو اختياري/إضافي:

1. الوحدات الأساسية المطلوبة: عمليات الطيران، الحجز/التذاكر، إدارة الركاب، الموارد البشرية/الطاقم، الصيانة، المحاسبة، الاتصالات - هذه ضرورية لتشغيل شركة طيران أساسية على المنصة.
2. الوحدات الاختيارية/الإضافية: الشحن، تحليلات ذكاء الأعمال المتقدمة، برنامج الولاء، إلخ، والتي تضيف قيمة استراتيجية ولكن يمكن للنظام العمل بدونها في البداية.

من خلال هيكلة الحل في هذه الوحدات، نحافظ على الوضوح في التطوير والصيانة المستقبلية. يمكن لكل فريق (أو فريق فرعي) تولي مسؤولية وحدات معينة (على سبيل المثال، يركز فريق من المطورين وخبراء الأعمال على وحدة الصيانة بينما يركز آخر على الحجوزات). يساعد هذا التقسيم المعياري أيضًا في الاختبار والتشغيل - على سبيل المثال، يمكننا نشر نظام التذاكر الأساسي أولاً، ثم إدخال وحدة الشحن لاحقًا دون إزعاج الأساس.

أفضل الممارسات والأمن والامتثال

يتطلب بناء وتشغيل نظام طيران قائم على ERPNext الالتزام بأفضل الممارسات لضمان الأمن والموثوقية والامتثال لمعايير الصناعة:

1. أمن البيانات: يجب حماية جميع البيانات الحساسة (المعلومات الشخصية، تفاصيل الدفع، إلخ):
2. استخدام تشفير HTTPS لجميع اتصالات العميل والخادم. فرض تكوينات TLS قوية على الخوادم.
3. التحكم في الوصول: تنفيذ أذونات قائمة على الأدوار في ERPNext بدقة حتى يتمكن المستخدمون فقط من الوصول إلى ما يحتاجون إليه. على سبيل المثال، لا ينبغي لموظفي المالية رؤية تفاصيل جوازات سفر الركاب، ولا ينبغي لوكلاء تسجيل الوصول الوصول إلى سجلات المحاسبة. استغل مدير الأذونات في ERPNext لتقييد رؤية أنواع المستندات حسب الدور وحتى على مستوى الحقل للحقول الحساسة بشكل خاص.
4. المصادقة الثنائية (2FA): تمكين المصادقة الثنائية لتسجيلات دخول المستخدمين على ERPNext، خاصة للمستخدمين المتميزين (المسؤولون، المديرون الماليون). يحتوي ERPNext على خيار مصادقة ثنائية مدمج (كلمة مرور لمرة واحدة عبر البريد الإلكتروني/التطبيق).
5. سياسات كلمة المرور: ضمان متطلبات كلمة مرور قوية وربما دمج تسجيل الدخول الأحادي (SSO) مع مزود هوية الشركة إذا كان متاحًا لإدارة المستخدمين المركزية.
6. التشفير في حالة السكون: على الرغم من أنه يمكن تشفير MySQL/MariaDB على مستوى نظام الملفات أو الجدول، فإن النهج الأسهل إذا كان على السحابة هو استخدام وحدات تخزين مشفرة يوفرها مقدمو الخدمات السحابية. قم أيضًا بتشفير النسخ الاحتياطية.
7. أمن الشبكة: إذا كان على السحابة، فاستخدم إعدادات السحابة الخاصة الافتراضية (VPC) - لا ينبغي أن يكون خادم قاعدة البيانات مفتوحًا للإنترنت، فقط تطبيق ERPNext. استخدم مجموعات الأمان أو قواعد جدار الحماية للسماح فقط بحركة المرور الضرورية (على سبيل المثال، فتح نقاط نهاية واجهة برمجة التطبيقات فقط لعناوين IP المعروفة لتكامل GDS، إلخ). في النشر المحلي، تأكد من وجود جدار حماية مناسب بين خوادم ERP وأي شبكات خارجية.
8. التوافر العالي والتعافي من الكوارث: تعمل شركات الطيران على مدار الساعة طوال أيام الأسبوع، لذا يجب أن يكون النظام مرنًا:
9. التخطيط للتكرار: على سبيل المثال، خوادم تطبيقات أولية وثانوية (متوازنة التحميل) بحيث إذا فشل أحدها، يستمر الآخر في العمل. وبالمثل، تكرار قاعدة البيانات (master-slave or clustering) لتجنب فقدان البيانات إذا فشلت قاعدة البيانات الأولية.
10. النسخ الاحتياطية المنتظمة: أتمتة النسخ الاحتياطية الليلية (أو الأكثر تكرارًا التزايدية) لقاعدة البيانات والملفات المحملة. قم بتخزين النسخ الاحتياطية خارج الموقع (إذا كان محليًا، فربما إلى التخزين السحابي؛ إذا كان على السحابة، فربما إلى منطقة مختلفة أو إلى النشر المحلي). اختبر إجراءات الاستعادة بشكل دوري لضمان صلاحية النسخ الاحتياطية.
11. تدريب التعافي من الكوارث: تحديد أهداف RTO (Recovery Time Objective) و RPO (Recovery Point Objective). على سبيل المثال، قد يعني RPO أقل من ساعة واحدة تمكين النسخ المتماثل أو شحن سجلات التغيير بشكل متكرر جدًا. يجب أن يعرف الفريق خطوات تشغيل النظام في موقع التعافي من الكوارث إذا فشل الموقع الأساسي (خاصة إذا كان محليًا - لديك موقع تعافي من الكوارث سحابي أو العكس).
12. إذا كنت تستخدم السحابة عبر المناطق: احتفظ بنسخة احتياطية دافئة في منطقة أخرى أو على الأقل نسخة احتياطية في منطقة أخرى يمكن تشغيلها.
13. الامتثال والمعايير:
14. PCI DSS: نظرًا لأننا نتعامل مع مدفوعات بطاقات الائتمان عبر النظام، حتى لو قمنا إلى حد كبير بالترميز عبر بوابات، يجب أن تكون أجزاء النظام التي تتعامل مع نماذج الدفع آمنة. من الناحية المثالية، استخدم صفحات الدفع المستضافة على البوابة حتى لا تلمس بيانات بطاقات الائتمان خوادمنا أبدًا (أبسط طريقة لتقليل نطاق PCI). إذا تم تخزين أي بيانات دفع (مثل آخر 4 أرقام أو رموز)، فهذا جيد، ولكن لا تقم أبدًا بتخزين أرقام البطاقات الكاملة غير مشفرة. الامتثال لـ PCI DSS من خلال التقييم الذاتي السنوي، وما إلى ذلك، حسب الحاجة.
15. GDPR وخصوصية البيانات: لقد قمنا بدمج الخصوصية حسب التصميم - يجب أن يسمح النظام بتلبية طلبات حذف البيانات. إذا طلب راكب حذف بياناته (وكان ذلك مسموحًا به قانونيًا)، فيجب أن نكون قادرين على إخفاء هوية سجله (بافتراض عدم وجود حجوزات نشطة). أيضًا، قم بتسمية البيانات التي نجمعها بوضوح في سياسة الخصوصية. من الممكن تنفيذ إخفاء البيانات في واجهة المستخدم لأدوار معينة (على سبيل المثال، إظهار آخر 4 أرقام فقط من جواز السفر ما لم ينقر المستخدم للكشف مع مصادقة إضافية).
16. لوائح الطيران: تأكد من أن سجلات وعمليات الصيانة تتماشى مع متطلبات سلطة الطيران (FAA، EASA أو هيئات الطيران المدني المحلية). على سبيل المثال، التوقيعات الرقمية على إذن الصيانة - قد نقوم بتنفيذ خطوة موافقة حيث يعمل تسجيل دخول مهندس مرخص كتوقيع. احتفظ بسجلات لتلك التوقيعات.
17. إذا احتاجت السلطة إلى تدقيق النظام، فكن مستعدًا بوثائق توضح كيفية عمل النظام، وربما الحصول على شهادة إذا لزم الأمر لوظائف معينة (في بعض الأحيان، يحتاج استخدام السجلات الفنية الإلكترونية أو ما شابه ذلك إلى موافقة).
18. مسارات التدقيق: يقوم ERPNext تلقائيًا بتسجيل سجل الإصدارات لتغييرات المستندات - تأكد من تشغيل هذا لأنواع المستندات الحرجة (يتم تشغيله افتراضيًا لمعظمها). بالإضافة إلى ذلك، يجب الاحتفاظ بسجلات الخادم وسجلات تسجيل دخول المستخدم. يساعد هذا أثناء أي تحقيق في الوصول غير المصرح به أو تغييرات البيانات.
19. الأداء والتحسين:
20. اتبع أفضل ممارسات الترميز في Frappe: استخدم التصفح من جانب الخادم للاستعلامات الكبيرة، وتجنب الحسابات الثقيلة في دورة الطلب (قم بنقلها إلى وظائف الخلفية إذا لزم الأمر، على سبيل المثال، إرسال 1000 بريد إلكتروني).
21. استخدم التخزين المؤقت حيثما كان ذلك مناسبًا - على سبيل المثال، إذا كان هناك حساب مكلف (مثل تحميل قائمة رحلات ضخمة) مطلوبًا بشكل متكرر، ففكر في تخزين النتائج مؤقتًا في Redis أو في الذاكرة وتحديثها عند تغيير البيانات الأساسية.
22. مراقبة أداء قاعدة البيانات: أضف فهارس لحقول أنواع المستندات المخصصة التي يتم تصفيتها كثيرًا (مثل رقم الرحلة أو التاريخ). راقب خطة الاستعلام لأي استعلامات بطيئة (قم بتمكين سجل الاستعلام البطيء).
23. إذا كان من المتوقع وجود تزامن عالٍ (مثل آلاف المستخدمين على موقع الحجز)، ففكر في التوسع مع عدة عمال واستخدام قائمة Redis لوظائف الخلفية للحفاظ على تفاعلات المستخدم سريعة.
24. قابلية الصيانة:
25. توثيق جميع التخصيصات (الحقول، البرامج النصية، بنية الوحدة) للمطورين المستقبليين. حافظ أيضًا على التحكم في الإصدار (git) للتطبيق المخصص والتكوين ككود حيثما أمكن (ربما باستخدام bench migrate and fixtures للحقول المخصصة).
26. قم بإعداد بيئة اختبار لاختبار التحديثات أو الميزات الجديدة قبل تطبيقها على الإنتاج. نظرًا لأن ERPNext سيكون له تحديثات دورية، خطط لكيفية دمجها دون كسر الكود المخصص. أفضل ممارسة هي البقاء على اطلاع نسبيًا بإصدارات ERPNext (للاستفادة من تصحيحات الأمان والتحسينات)، واختبار كل تحديث في بيئة الاختبار.
27. استخدم الترميز المعياري - على سبيل المثال، إذا كان هناك حاجة إلى منطق تكامل ثقيل، فربما ضعه في خدمة مصغرة منفصلة بدلاً من برامج نصية خادم معقدة للغاية - أسهل في الصيانة ولا تحمل النظام الرئيسي.
28. أفضل ممارسات المستخدم والتدريب:
29. فرض سياسة تشغيلية مفادها أنه إذا لم يتم تسجيل شيء ما في النظام، فإنه لم يحدث. سيؤدي هذا إلى التبني - على سبيل المثال، يجب على مهندسي الصيانة تسجيل كل تغيير في الأجزاء في ERPNext، ويجب على وكلاء البوابة تحديث أسباب تأخير الرحلات، إلخ. ادعم ذلك بدعم من الإدارة.
30. توفير تدريب تحديثي دوري أو تحديثات عند إضافة ميزات جديدة أو إذا حدث أي حادث بسبب سوء الاستخدام (حوله إلى فرصة للتعلم).
31. شجع على استخدام أدوات الاتصال المدمجة بدلاً من تكنولوجيا المعلومات الظلية (مثل WhatsApp خارج النظام) للاتصالات الرسمية، للحفاظ على سجل. مع دمج الدردشة، هذا ممكن.

من خلال الالتزام بأفضل الممارسات هذه، يمكن لشركة الطيران أن تثق في أن النظام آمن ومتوافق وقوي. المخاطر عالية - يمكن أن تكون الاضطرابات التشغيلية أو خروقات البيانات مدمرة - لذا فإننا نخفف من تلك المخاطر بشكل منهجي. يبني هذا أيضًا الثقة بين العملاء (الذين يأتمنون على بياناتهم الشخصية)، والموظفين (الذين يعتمدون على النظام في العمل اليومي)، والمنظمين (الذين يشرفون على السلامة والخصوصية). في نهاية المطاف، لا يمنع النظام الآمن والمحكوم جيدًا المشاكل فحسب، بل يحسن أيضًا الكفاءة (وقت توقف أقل، تدخل يدوي أقل) ويصبح أصلاً تنافسيًا لشركة الطيران.

الميزات الاستراتيجية الإضافية

بالنظر إلى ما هو أبعد من المتطلبات الفورية، هناك العديد من التحسينات والتكاملات التي يمكن أن تضيف قيمة استراتيجية كبيرة لمنصة ERPNext القائمة على شركة الطيران في المستقبل:

1. التنبؤ بالطلب المدعوم بالذكاء الاصطناعي: استغل التعلم الآلي على البيانات التاريخية المخزنة في ERPNext لتحسين التنبؤ. على سبيل المثال، استخدم نموذج ذكاء اصطناعي للتنبؤ بطلب الركاب على كل مسار لكل فترة مستقبلية، مع مراعاة الاتجاهات والعطلات والمنافسة، وما إلى ذلك. يمكن أن يساعد هذا في تخطيط المسارات وتعديل ترددات الرحلات. يمكن تصدير بيانات ERPNext إلى منصة ذكاء اصطناعي (أو استخدام مكتبات مع Frappe) لتوليد هذه التنبؤات، والتي يمكن بعد ذلك إعادتها إلى عملية التخطيط[18]. تؤدي التنبؤات المحسنة إلى استخدام أفضل للسعة وتخطيط الطاقم/الموارد.
2. تحسين التسعير الديناميكي: بينما يمكن للنظام التعامل مع قواعد التسعير الديناميكي الآن، فإن دمج خوارزمية إدارة إيرادات أكثر تقدمًا يمكن أن يؤدي إلى نتائج أفضل. على سبيل المثال، قم بتنفيذ وحدة تحلل باستمرار سرعة الحجز والسعة المتبقية وتعدل توفر فئات الأسعار/الأسعار ضمن النطاقات المسموح بها. قد يكون هذا خدمة خارجية (بعض نماذج الذكاء الاصطناعي أو أبحاث العمليات) تقوم بتحديث قواعد التسعير في ERPNext في الوقت الفعلي بما يتجاوز القواعد الثابتة الأولية[11]. يؤدي هذا إلى زيادة العائد (على غرار كيفية تعظيم شركات الطيران الكبيرة للإيرادات لكل رحلة).
3. تحسينات تجربة العملاء:
4. روبوتات الدردشة لخدمة العملاء: دمج روبوت دردشة (باستخدام خدمات معالجة اللغة الطبيعية بالذكاء الاصطناعي) مع ClefinCode Chat للتعامل مع الاستفسارات الشائعة تلقائيًا (حالة الرحلة، بدل الأمتعة، إلخ). يمكن أن يقلل هذا من العبء على الوكلاء البشريين ويقدم إجابات فورية على مدار الساعة طوال أيام الأسبوع. يمكن تدريب الروبوت على الأسئلة الشائعة وحتى إجراء معاملات بسيطة (مثل التحقق من حالة الرحلة عن طريق سجل اسم الراكب).
5. التخصيص: استخدم البيانات في ERPNext (الرحلات السابقة، التفضيلات) لتخصيص العروض. على سبيل المثال، يمكن لبوابة الحجز أن توصي بخدمات إضافية أو تعرض تحية شخصية ("مرحبًا بعودتك، لديك 10000 ميل، يمكنك الترقية إلى درجة رجال الأعمال في هذه الرحلة مقابل X دولار").
6. تكامل برنامج الولاء: كما ذكرنا، فإن بناء برنامج للمسافر الدائم في ERPNext (أو التكامل مع برنامج موجود) سيكون استراتيجيًا. يشجع هذا على تكرار الأعمال. سنتتبع الأميال، وحالة الفئة، وندمج خيارات الاستبدال في تدفق الحجز. أيضًا، ربما الشراكة مع شركات طيران أو تحالفات أخرى - يجب أن يكون نظامنا قادرًا على إضافة/تسجيل أميال الشركاء أو قبول تذاكر المكافآت من الشركاء (مما يتضمن تبادل البيانات مع أنظمة التحالف).
7. التحليلات التشغيلية ولوحات المعلومات: تقديم لوحة معلومات للتحكم التشغيلي تجمع المعلومات الرئيسية في الوقت الفعلي: الرحلات الجوية، التأخيرات، أي مشاكل صيانة حرجة، إلخ، باستخدام مؤشرات مرئية (ربما خريطة، وجداول للمشكلات). في حين أن بعض هذا مدمج في قوائم، يمكن أن تساعد لوحة معلومات مخصصة المديرين على تقييم الموقف بسرعة كل ساعة. من الممكن دمج التنبيهات - إذا انخفض مؤشر أداء رئيسي (مثل انخفاض أداء الالتزام بالمواعيد إلى ما دون X٪)، فقم بتشغيل تنبيه للإدارة.
8. التكامل مع الابتكار الخارجي:
9. المطارات الذكية: إذا كانت المطارات تدعم تبادل البيانات، فقم بدمج التحكم في المغادرة مع أنظمة المطار. على سبيل المثال، توفر بعض المطارات أجهزة وبرامج بوابات الصعود - يمكننا التكامل بحيث عندما يقوم وكيلنا بمسح بطاقة صعود في البوابة، يتم تحديث كل من ERPNext الخاص بنا وشاشة معلومات الرحلة في المطار في وقت واحد.
10. الصعود بالتعرف على الوجه: في بعض عمليات النشر الحديثة، يتم استخدام التعرف على الوجه للصعود (الصعود بدون ورق). إذا سلكت شركة الطيران هذا الطريق، فيمكن لنظامنا التكامل مع ذلك المزود - بشكل أساسي تلقي تأكيد بأن الراكب X (تم التحقق منه عن طريق الوجه) قد صعد وتحديث سجل ERPNext لحالة الصعود.
11. إنترنت الأشياء للصيانة: ربما تزويد الطائرات بأجهزة استشعار إنترنت الأشياء التي تغذي البيانات (مثل معلمات صحة المحرك أو درجة حرارة المقصورة، إلخ). في حين أن هذه قد تذهب إلى أنظمة متخصصة، يمكننا تسجيل تنبيهات موجزة في ERPNext (على سبيل المثال، يشغل مستشعر "ضغط الإطارات منخفض" - قم بإنشاء مهمة صيانة تلقائيًا). سيدفع هذا شركة الطيران نحو الصيانة التنبؤية بدلاً من المجدولة فقط.
12. خدمات الشركاء الموسعة: يمكن توسيع المنصة إلى نظام بيئي صغير:
13. تقديم تكامل الفنادق وتأجير السيارات على بوابة الحجز (لبيع حزمة سفر كاملة). يمكننا التكامل عبر واجهات برمجة التطبيقات مع أنظمة حجز الفنادق (أو ببساطة الربط التابع) وعلى الأقل تضمين ذلك في خط سير الرحلة للراحة.
14. ميزات دعم شركات طيران متعددة: إذا كان نظامنا يستضيف عدة شركات طيران، ففكر في إضافة ميزات للمشاركة بالرمز بينها بسهولة إذا اختاروا (مثل مشاركة المخزون أو تسجيل الوصول المباشر إذا كانوا يتشاركون في الخطوط). يمكن تعديل نهجنا متعدد المستأجرين للسماح بمشاركة البيانات بطريقة مضبوطة إذا وافقت شركتا طيران (هذا متقدم، ولكن على سبيل المثال إذا أرادت شركة الطيران A و B على المنصة بيع رحلات بعضهما البعض، فيمكن تسهيل ذلك).
15. توفير خدمات مدارة: على سبيل المثال، قد لا يكون لدى شركة طيران صغيرة مركز تحكم في العمليات على مدار الساعة طوال أيام الأسبوع - يمكن لمنصتنا التكامل مع خدمة مركز تحكم في العمليات من طرف ثالث تحصل على وصول إلى النظام لإدارة عملياتها طوال الليل. يمتد هذا إلى ما هو أبعد من البرامج إلى الخدمة، ولكن يمكن أن تكون المنصة التي تتيح التعاون عن بعد بأمان نقطة بيع.
16. التحسين المستمر عبر حلقات التغذية الراجعة: استخدم البيانات التي تم جمعها للتحسين المستمر:
17. تنفيذ آلية لجمع ملاحظات الموظفين حول استخدام النظام (زر "ملاحظات" للموظفين). يمكن أن يساعد هذا في تحديد احتياجات التدريب أو المجالات التي تحتاج إلى تبسيط إضافي.
18. مراقبة تذاكر الدعم من الركاب وتحديد ما إذا كان أي منها يرجع إلى عملية النظام (على سبيل المثال، إذا سأل الكثيرون "لم أتلق تأكيدًا بالبريد الإلكتروني"، فربما قم بتحسين سير العمل أو الاتصال هذا).
19. الطبيعة الرشيقة للمنصة تعني أنه يمكن طرح ميزات جديدة بشكل متكرر - على سبيل المثال، تحسينات شهرية. تبقي هذه العقلية شركة الطيران في طليعة التكنولوجيا مقارنة بشركات الطيران التقليدية العالقة في نظام خدمة الركاب القديم.

من خلال النظر في هذه الميزات الإضافية وتنفيذها تدريجيًا، يمكن لشركة الطيران أن تميز نفسها بخدمة وكفاءة فائقة مدعومة بالتكنولوجيا. يكمن جمال البناء على ERPNext في أننا لسنا مقيدين بدورة إصدار البائع - يمكننا الابتكار داخليًا. يجب تقييم كل إضافة استراتيجية من حيث عائد الاستثمار (e.g., will a chatbot reduce cost or improve NPS? Will dynamic pricing boost revenue enough to justify complexity?). يمكن إعطاء الأولوية لتلك التي لها فوائد واضحة. بمرور الوقت، تتراكم هذه التحسينات لتمنح شركة الطيران منصة متكاملة ومتطورة تدعم ليس فقط الاحتياجات الحالية ولكن أيضًا النمو والابتكار المستقبلي في صناعة الطيران.

الخاتمة

في الختام، يعد الاستفادة من ERPNext كعمود فقري لمنصة عمليات طيران متكاملة الخدمات أمرًا ممكنًا ومفيدًا. تغطي بنية النظام التي أوضحناها مجموعة كاملة من وظائف شركات الطيران - من مبيعات التذاكر وخدمة الركاب إلى عمليات الطيران والصيانة والمالية - ضمن إطار عمل موحد ومتكامل. من خلال التخصيص الدقيق لوحدات ERPNext وتطوير التطبيقات التكميلية (الجوال، الويب، الدردشة)، نحقق حلاً مصممًا خصيصًا لمتطلبات صناعة الطيران الفريدة مع الحفاظ على نقاط قوة أساس نظام تخطيط موارد المؤسسات المثبت (اتساق البيانات، التصميم المعياري، والمحاسبة القوية).

يدعم هذا التصميم الشامل تشغيل عدة شركات طيران مركزيًا، مما يوفر قابلية التوسع لمجموعة أو نموذج مزود خدمة. يمكن عزل بيانات كل شركة طيران ومع ذلك يمكن للفريق المركزي الإشراف على الجميع عبر منصة مشتركة، مما يتيح وفورات الحجم. من خلال تنفيذ أفضل ممارسات الصناعة في الأمن والامتثال، يكون النظام مرنًا ضد التهديدات ومتوافقًا مع المتطلبات التنظيمية، وهو أمر حاسم في الطيران. يمكن اختيار استراتيجية النشر (سحابي، محلي، أو هجين) لتلبية احتياجات شركة الطيران بشكل أفضل من حيث التحكم والموثوقية، مع فهم واضح للمقايضات[1][1].

بشكل حاسم، يضع هذا التقرير خارطة طريق للتنفيذ تخفف من المخاطر من خلال التطوير التدريجي والاختبار الذي يركز على المستخدم، مما يضمن أنه عندما يبدأ تشغيل النظام فإنه يعزز العمليات حقًا بدلاً من تعطيلها. بعد التنفيذ، ستمتلك شركة الطيران ليس فقط نظام تخطيط موارد المؤسسات، ولكن أصلًا استراتيجيًا - منصة قادرة على التطور المستمر. ستعمل ميزات مثل التحليلات في الوقت الفعلي، وتحسينات الذكاء الاصطناعي للتسعير والتنبؤ، والتفاعل مع العملاء عبر قنوات متعددة من الدرجة الأولى على تمكين شركة الطيران من اتخاذ قرارات تستند إلى البيانات وتقديم خدمة استثنائية.

من خلال تبني هذا الحل القائم على ERPNext، ستحقق شركة الطيران زيادة في الكفاءة (من خلال الأتمتة والتكامل)، وخفض التكاليف (عبر التحكم المركزي والقضاء على الأنظمة القديمة المتباينة)، وتحسين الإيرادات (عبر إدارة أفضل للسعة ومبيعات الخدمات الإضافية). علاوة على ذلك، تسمح رشاقة المنصة لشركة الطيران بالتكيف بسرعة في سوق الطيران الديناميكي - سواء كان ذلك بإضافة تكاملات شركاء جديدة، أو الامتثال لتغيير تنظيمي مفاجئ، أو توسيع نطاق العمليات إلى محاور وأساطيل جديدة.

باختصار، يضع هذا الحل الشامل شركة الطيران في موقع التميز التشغيلي والابتكار. إنه يوفق بين التكنولوجيا واستراتيجية الأعمال، مما يضمن أنه مع تحليق شركة الطيران إلى آفاق جديدة، تكون أنظمتها على الأرض قوية وذكية وجاهزة لدعم كل خطوة من الرحلة.

المصادر: تعتمد نهج التنفيذ والميزات الموصوفة على القدرات الرسمية لـ ERPNext وأفضل ممارسات المجتمع، بالإضافة إلى معايير الصناعة لعمليات شركات الطيران. تشمل المراجع الرئيسية وثائق ومنتديات ERPNext لإرشادات التخصيص[2][4]، وأدوات التكامل وتطبيقات الطرف الثالث مثل ClefinCode Chat للاتصال[5][5]، ومعرفة مجال الطيران مثل متطلبات تكامل GDS[8] واستراتيجيات التسعير الديناميكي[11]. تتحقق هذه المصادر من جدوى التصميم المقترح ضمن كل من الإطار الفني لـ ERPNext والسياق الواقعي لإدارة شركات الطيران.