خطة إكمال «بكة مباشر» خدمةً متكاملة لشركات الحج

تقرير المجلس الاستشاري (7 خبراء) · 14 نوفمبر 2026 · مقاس على 1000 موظف و20,000 حاج · لمحمود أبوعون والمهندس حازم · المرجع: مستودع hib-platform (91 commit حتى طلب الدمج 33)، ومراجعة موسم 1447 لإكرام الضيف، وقواعد 1448

الخلاصة في ثلاثة أسطر

المنصة اليوم قوية جداً قبل وصول الحاج: الباقات والتسعير وملفات نسك وسجل الحجاج والمرشدون والتسكين، وتطبّق أغلب دروس 1447 (لا حذف للحاج، كشف تبديل الجواز، الملغى يوصف ولا يُحذف).

لكنها ليست جاهزة بعد لشركات خارجية: عزل بيانات الشركات غير موثّق ولم يُختبر، ولا يوجد ميدان (مغادرة، مشاعر، تطبيق الحاج) ولا إغلاق مالي.

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

والبنية نفسها لا تتحمل ERP بحجم 1000 موظف و20,000 حاج: كل شاشة تجمع الواجهة وقواعد العمل والاتصال بالقاعدة في ملف واحد، فتغيير قاعدة واحدة يمس عدة ملفات، وإضافة قسم تمس 8 ملفات. وشاشة الحجاج ستحتاج نحو دقيقة لتفتح عند 20,000 حاج، وبعض القوائم تتوقف عند 1,000 صف دون رسالة، ومنها قيود المحاسبة.

تقدير النواقص 150–200 يوم عمل، والمتاح حتى 25 ديسمبر نحو 29 يوماً. التوصية: لا إعادة كتابة. نصلح الأساس أولاً (فصل الطبقات، والقاعدة في المستودع، وسلامة البيانات)، ثم نبني كل قسم جديد على النمط الصحيح، ونقسّم التسليم حسب موعد حاجة الموسم.

المجلس

خبير البرمجة والأمانالعزل بين الشركات، حماية الجوازات، متانة البنية
خبير إدارة المشاريعالأقسام مقابل دورة الموسم، الجدول، الجاهزية التجارية
خبير العمليات والماليةمسار البيانات من العقد إلى الحاج، والإغلاق المالي
خبير مشاريع الحجمقارنة بدورة الموسم الفعلية ودروس 1447
خبير المراجعة البرمجيةجودة الكود، وعمل موظفين من عدة شركات وأقسام في وقت واحد
المهندس المعماريالطبقات وحدود الأقسام، والبنية المستهدفة لنظام ERP كبير
خبير قواعد البيانات والأداءنموذج البيانات وسلامتها، وما يتعطل عند 20,000 حاج و1000 موظف

أين تقف المنصة من دورة الموسم

المرحلةالحالةملاحظة
الباقات والتسعير واعتمادها في نسكموجودلقطة سعر ثابتة عند الاعتماد، وصفحة عامة بالعربية والإنجليزية
عقود نسك (سكن، نقل، طيران)موجودعقود المشاعر (النوع 2) تُرفض عند الاستيراد
سجل الحجاج والهويةموجودالمفتاح هو رقم نسك التسلسلي، ولا معرّف داخلي مستقل
المرشدون والتسكين في الفنادقموجود48 حاجاً لكل فرعي مكتوبة في الكود
البيع: B2C ووكلاء B2Bجزئيلا وكلاء ولا حصص ولا تحصيل
النقل والمغادرةجزئيتوزيع عقود فقط؛ لا كشوف باصات ولا قاعدة 3.5 ساعة
المشاعر (التصعيد، النفرة، المخيمات)غير موجودأخطر أيام الموسم
تطبيق الحاج، شاشة الفندق، الحقائب، البلاغاتغير موجودشاشة المرشد «حجاجي» فقط
لوحة صحة البياناتجزئيتنبيهات جيدة لكنها موزعة داخل كل شاشة
المالية الفعلية والإغلاقغير موجودالموجود موازنة تقديرية تُكتب يدوياً، وعهد ومشتريات لهوليداي إن فقط
تسجيل شركة جديدة وتهيئتهاجزئياختيار الشركة موجود؛ لا شاشة لإضافة شركة، والهوية من اسم الرابط

أخطر ما وجده المجلس

الخطورةالمشكلةلماذا يهمالدليل
حرجعزل بيانات الشركات يعتمد على ترويسة يرسلها المتصفح، وقواعد القاعدة (RLS) غير مكتوبة في أي مكان يُراجَعإن كانت القاعدة تثق بالترويسة وحدها، يقرأ موظف شركة جوازات حجاج شركة منافسةco.js، طلب الدمج 31 بلا نص SQL
حرجأوامر القاعدة تُذكر بأرقامها فقط (38، 48 … 67) دون نصهالا إعادة بناء بعد كارثة، ولا بيئة تجربة، ولا مراجعة. خطر 1447 نفسه: «شخص واحد يفهم النظام»أوصاف طلبات الدمج 1–33
حرجشخص واحد كتب 89 من 91 تعديلاً، ويدمج طلباته بلا مراجعة، وكل دمج يصل الإنتاج فوراً للموقعينغياب حازم أسبوعاً في أبريل يوقف المنصة لكل الشركاتgit log، مراجعات الطلبات = 0
حرجلا ميدان ولا مشاعر ولا مغادرةفيها وقعت أغلب حوادث 1447قائمة الأقسام في perms.js
عالٍفشل صامت: إذا فشل تحميل السكن أو النقل أو المرشدين يُصدَّر الكشف بأعمدة فارغة دون تحذيرعائلة «الكشف الفارغ بدل الفشل الصريح» من 1447op/pilgrims.js:63-70
عالٍملفات نسك لا تُحفظ كما وصلت، والأعمدة الجديدة تسقط بصمتيخالف قاعدة «كل ملف يُحفظ كما وصل»، ولا مرجع عند نزاع مع نسك أو موردop/pilgrims.js (يُحفظ اسم الملف فقط)
عالٍاسم هوليداي إن مكتوب داخل طلبات عروض الطيران والتقاريرطلب عروض يخرج باسم شركة أخرى أمام شركات الطيرانws/rfq.html:402، ws/index.html، ws/train.html
عالٍأقسام الموظفين والشؤون الإدارية مخفية من القائمة فقط في رابط إعمار، وجداولها على الأرجح بلا عمود شركةتسرّب رواتب وهويات موظفين بين الشركات إن مُنحت صلاحية خطأًgate.js:48-50
عالٍحماية المتصفح (CSP) غائبة عن صفحة الدخول والموظفين والتوظيف، ومكتبة Excel قديمة فيها ثغراتبيانات جوازات؛ نظام حماية البيانات الشخصية يطلب تدابير مناسبة_headers، hr/ (xlsx 0.18.5)
عالٍلا نسخ احتياطي موثق ولا تجربة استعادة، وموسم التجربة 1447 داخل القاعدة الحيةركيزة المتانة من ركائز 1448غير متحقق في Supabase
متوسطقواعد تشغيل ثابتة في الكود: 48 لكل مرشد، مطارا جدة والمدينة فقط، بقايا Firebase وبريد شخصي في الإعداداتشركة أخرى تحتاج إعداداتها دون تعديل برمجيop/guides.js، op/transport.js:9-12، config.js

جودة الكود

الكود يعمل وفيه أفكار جيدة (حماية التعارض في الورشة، رفع الحجاج على مراحل)، لكنه مكتوب لشخص واحد يحفظه في رأسه. مطوّر ثانٍ يحتاج 2–3 أسابيع قبل أن يعدّل فيه بثقة.

الجانبالتقييمما وُجد
القراءة والصيانة3/10أسطر يصل طولها إلى 1,900 حرف، ومتغيرات بحرف أو حرفين (P، X، HS)، و40 دالة في شاشة سجل الحجاج وحدها
التكرار3/10دالة الحماية من الرموز منسوخة في 15 ملفاً، ورسائل التنبيه في 13 بتسع صيغ، والاتصال بالقاعدة يُفتح في 20 ملفاً. إصلاح رسالة خطأ واحدة يتكرر في نحو 11 مكاناً
معالجة الأخطاء4/10170 موضعاً يبتلع الخطأ بصمت؛ أخطرها في سجل الحجاج حيث يختفي عمود السكن دون تنبيه إذا تعثرت الشبكة
البنية4/10كل شيء معلّق على متغيرات عامة، ويعمل بشرط ترتيب تحميل الملفات، و11 رقم إصدار يُحدَّث يدوياً، ولا اختبارات
إضافة قسم جديد3/10تعديل في نحو 9 أماكن؛ نسيان واحد منها لا يظهر، بل يقفل القسم أو يفتحه بصمت

عمل موظفين من عدة شركات وأقسام في وقت واحد

الخطورةما يحدث في يوم عملالسببالإصلاح
حرجموظفة تعمل لإكرام ورفاد فتحت تبويبين، وحوّلت أحدهما إلى رفاد. التبويب الآخر ما زال يعرض حجاج إكرام، لكن كل ما تحفظه فيه يذهب إلى رفاد. لو رفعت ملف Booking Details لإكرام دخل 6,800 حاج في رفاد، ونافذة المراجعة لا تذكر اسم الشركةالشركة تُقرأ من ذاكرة المتصفح المشتركة عند كل طلب، ولا شيء يخبر التبويب الآخر بالتغيير (co.js:49-51)1.5 يوم
عالٍمنسقان يفتحان بطاقة المرشد نفسه؛ الأول يصحح الجوال والثاني يغيّر الفرعي. يحفظ الثاني فيضيع تصحيح الأول دون أن يعلم أحدالحفظ يكتب الصف كاملاً بلا فحص تعارض في المرشدين وربط عقود نسك والمستخدمين والموظفين ومقاعد الطيران (op/guides.js:77)2 يوم
عالٍمشرف تسكين يرى غرفة فارغة لأن زميله نقل إليها حاجين قبل ربع ساعة، فيسكّن فيها آخرينشاشات العمليات والورشة لا تتحدث تلقائياً ولا تنبّه بأن البيانات تغيّرت2 يوم
عالٍتظهر للموظف «حُفظ» والتعديل لم يُحفظ فعلاًبعض التعديلات لا تتحقق من عدد الصفوف التي تغيّرت0.5 يوم
عالٍكشف يتكرر فيه حاج أو يسقط منه حاج عند حد كل 1,000 صفالقراءة على صفحات بترتيب غير فريد (السكن والنقل والأسرّة)0.5 يوم
عالٍلا يُعرف من حذف باقة أو عرض طيران أو مساراً، ولا من غيّر صلاحيات موظفسجل التدقيق موجود للحجاج والغرف فقط2 يوم
عالٍلا يمكن أن يكون الموظف «تعديل» في إكرام و«عرض» في رفاد، والصلاحية المسحوبة تبقى ظاهرة حتى إعادة التحميلصلاحية واحدة لكل الشركات، تُحمَّل مرة واحدة3 أيام
متوسطموظفان يرفعان ملف الموسم نفسه معاً، ولا تمنعهما الواجهةلا قفل على الرفع (والفحص في القاعدة غير متحقق)0.5 يوم
متوسطفتح سجل الحجاج على جوال في الميدان قد يأخذ 20–30 ثانية، والبوابة تقفل الصفحة بعد 15 ثانيةنحو 60–70 طلباً متتالياً لتحميل كل الحجاج في المتصفح2 يوم
متوسطبعد نشر تعديل يرى الموظف رسالة إنجليزية غامضة في تبويب مفتوح منذ الصباحلا تنبيه بوجود نسخة جديدة1 يوم
متوسطيضيع نموذج مفتوح إذا سجّل الموظف خروجه من تبويب آخر، وإعادة الحفظ بعد انقطاع الشبكة تكرر السجللا تحذير قبل المغادرة ولا منع للتكرار1.5 يوم

البنية والطبقات

النظام اليوم بلا طبقة وسطى: كل شاشة ترسم، وتحسب قواعد العمل، وتكلّم القاعدة بنفسها. لذلك يمس أي تغيير ملفات لا علاقة لها به. هذا ما يلزم تعديله اليوم لثلاثة تغييرات عادية:

التغييراليومبعد الفصل
إضافة حالة جديدة للحاج (مثل «ملغى ومسترد»)لا يوجد حقل حالة أصلاً. الحالة مستنتجة في نحو 25 موضعاً في 3 ملفات، ونحو 6 دوال في القاعدة، بلا اختبارقيمة جديدة في جدول الحالات، ودالة انتقال واحدة
تغيير معادلة تسعير الباقة7 دوال في شاشة الورشة، والسعر يُحسب في متصفح الموظف ويُحفظ كما هو، والموازنة لا تتأثرملف تسعير واحد تستعمله الشاشة والخادم معاً، ويُعاد الحساب عند الاعتماد
إضافة قسم جديد (مثل الحقائب)8 ملفات ونحو 12 موضعاً قبل سطر واحد من منطق القسمملف أو ملفان

السبب الأعمق: الأقسام مقسّمة حسب الإدارة ومرحلة العمل (ورشة ثم عمليات ثم مالية)، لا حسب الشيء الذي تديره. فالباقة والعقد والرحلة موجودة مرتين بحالات مختلفة. التقسيم الصحيح 11 وحدة، كل وحدة تملك جداولها ولا يكتب فيها غيرها:

المنصة المشتركةالشركات، المستخدمون، الصلاحيات، التدقيق، المواسم
العقود والموردونالفنادق، النقل، الإعاشة، المخيمات، عقود نسك والطيران
الباقات والتسعيروحدها تملك معادلة السعر
الحجاج والهويةالسجل الأم وحالات الحاج ورفع ملفات نسك
التسكينالغرف والأسرّة وشاشة الفندق
النقل والطيرانالرحلات وتنسيق المغادرة
الميدانالمرشدون والحقائب والمشاعر
المالية والإغلاقالموازنة والقيود والتسويات والمستردات
المشتريات والإداريةوالموارد البشرية والمهام: ثلاث وحدات مستقلة

البنية المستهدفة (بلا إعادة كتابة): القاعدة مصدر الحقيقة وأوامرها محفوظة في المستودع؛ كل كتابة حساسة عبر دالة في القاعدة؛ مكتبة مشتركة وطبقة بيانات لكل وحدة في الواجهة، وممنوع على أي شاشة جديدة أن تكلّم القاعدة مباشرة؛ وخادم صغير (Edge Functions) فقط لاعتماد السعر والربط الخارجي وتطبيق الحاج والمستردات. الوحدات تتواصل عبر دوال منشورة وجدول أحداث («حاج أُلغي»، «باقة اعتُمدت»)، فيقرأ الإغلاق المالي الأحداث لا جداول غيره. هذا يكمل النمط الجيد الموجود في قسم العمليات op/.

قاعدة البيانات عند الحجم الحقيقي

الخطورةما يحدثالدليل
حرجقيود المحاسبة محفوظة كقيم داخل جدول الإعدادات، وتُحذف نهائياً، ولا يمكن للقاعدة أن تفرض توازن المدين والدائنhr/index.html:4547
حرجقوائم تتوقف عند 1,000 صف دون أي رسالة: الموظفون، المسيّرات، القيود المالية، الإعدادات ومعها دفتر القيودhr/index.html:4527، adm/index.html:241
حرجفتح شاشة الحجاج لشركة فيها 20,000 حاج: نحو 220 طلباً و40 ميغابايت، أي نحو دقيقة. ومع 200 موظف في الذروة نحو 44,000 طلب (تقدير)op/pilgrims.js:59-72
عالٍحذف نهائي للقيود المالية والمسيّرات والعقود، خلافاً لقاعدة «الملغى لا يُحذف بل يوصف»adm/index.html:539
عالٍحجز مقاعد الطيران للباقة يُحفظ رحلة رحلة؛ انقطاع في المنتصف يترك التوزيع نصف محفوظws/pkgflt.js:79-85
عالٍلا بيئة اختبار منفصلة، ولا بيانات تجريبية، ولم يُجرَ أي اختبار حمل. موسم التجربة يعيش في قاعدة الإنتاجغير متحقق في Supabase
عالٍ1000 موظف يعني 1000–2000 اتصال لحظي، وسقف خطة Supabase غير معروف. وقسم المهام يعيد تحميل كل شيء عند كل تعديل لكل من فتحهindex.html:312، ops-db.js:54
متوسطحد صلب 20,000 حاج في ملف الرفع الواحدop/pilgrims.js:281

خط الإصلاح والإكمال

كل مرحلة تُبنى في bakkah-work ويراجعها حازم وينقلها، حسب القاعدة المعتمدة. الأيام تقديرية بأيام عمل مطوّر واحد. التوثيق جزء من كل مرحلة: لا يُسلَّم قسم دون توثيقه للمطورين ودليله للموظفين (الفهرس في docs/README.md).

المرحلة 0: الاتفاق، والقاعدة في المستودع

16 – 22 نوفمبر 2026 · 5–8 أيام
  • اتفاق مكتوب مع حازم: مهلة مراجعة 48 ساعة، وتعريف «الجاهز»، واعتماد البنية المستهدفة وقواعد الكود الجديد.
  • استخراج هيكل القاعدة كاملاً (الجداول، صلاحيات الصفوف، الدوال، المخازن) إلى supabase/migrations/، وكل تعديل لاحق ملف مرقّم يُراجع مع طلب الدمج.
  • تفعيل النسخ الاحتياطي والاستعادة لنقطة زمنية، وتجربة استعادة فعلية موثقة، ومعرفة سقف خطة Supabase.
  • مشروع قاعدة منفصل للتجربة تتصل به روابط المعاينة، ونقل موسم 1447 إليه.
  • مراجعة إلزامية لكل طلب دمج من شخص غير صاحبه، وحماية فرع main.
  • التوثيق يبدأ هنا: البنية ونموذج البيانات (مكتوبان في docs/)، ودليل الطوارئ.

البوابة: لا يبدأ أي بناء جديد قبل أن تكون القاعدة في المستودع وبيئة التجربة جاهزة.

المرحلة 1: الأساس المعماري، والعزل، وسلامة البيانات

23 نوفمبر – 25 ديسمبر 2026 · 35–45 يوماً
  • فصل الطبقات أولاً (نحو 5 أيام): مكتبة مشتركة واحدة، وسجل واحد للأقسام بدل 6 مواضع، وطبقة بيانات لكل وحدة، وفحص آلي يرفض أي شاشة جديدة تكلّم القاعدة مباشرة. بعدها يُطبَّق كل إصلاح مرة واحدة.
  • حالات الحاج: حقل حالة بقيم محددة ودالة انتقال واحدة تسجّل كل تغيير. شرط للإلغاء والمستردات وتطبيق الحاج والإغلاق.
  • العزل بين الشركات: تثبيت الشركة لكل نافذة، ومراجعة صلاحيات الصفوف جدولاً جدولاً وللمخازن، وعمود شركة إلزامي، واختبار آلي بحسابين من شركتين يُشغَّل مع كل تعديل.
  • إيقاف ضياع البيانات الصامت: ترقيم كل قائمة تقف عند 1,000 صف، وترتيب فريد للصفحات، والتحقق أن الحفظ تمّ فعلاً، وحماية التعارض في كل التعديلات، وشريط أحمر ومنع التصدير عند فشل أي تحميل.
  • قيود في القاعدة لا في المتصفح: منع الحذف النهائي للسجلات المالية والحجاج («ملغى» مع السبب)، ومفاتيح فريدة وأجنبية، ومعرّفات تولّدها القاعدة، وحجز مقاعد الطيران في عملية واحدة.
  • مراقبة الأخطاء: كل خطأ في متصفح أي موظف يُسجَّل، وتنبيه يومي بعددها.
  • حفظ كل ملف نسك كما وصل، ومعرّف داخلي ثابت للحاج، وإخراج اسم هوليداي إن والقواعد الثابتة إلى إعدادات كل شركة، وحماية CSP لكل الصفحات.
  • أدلة الموظفين للأقسام الموجودة (الدخول والصلاحيات، الورشة، العمليات) قبل أن يبدأ موظفو إكرام ورفاد.

البوابة: إكرام الضيف ورفاد يبدآن العمل الفعلي بعد نجاح اختبار العزل، وتثبيت الشركة لكل نافذة، وحماية التعارض، وإيقاف الضياع الصامت. الحجم يفوق 29 يوماً متاحة: بمطوّر ثانٍ من ديسمبر تكتمل، وبدونه تنتقل الإعدادات لكل شركة وCSP إلى يناير.

المرحلة 2: الأقسام الجديدة على النمط الصحيح

يناير – فبراير 2027 · 45–55 يوماً
  • قاعدة لكل قسم جديد: وحدة تملك جداولها، وكتابة عبر دوال القاعدة فقط، وقراءة من الوحدات الأخرى عبر دوال منشورة، وتوثيق ودليل موظف يُسلَّمان مع القسم.
  • جدول الأحداث بين الوحدات («حاج أُلغي»، «باقة اعتُمدت»)، وأول من يستعمله الإغلاق المالي.
  • التسعير في ملف واحد، ويُعاد حسابه في الخادم عند الاعتماد بدل الثقة بسعر المتصفح، مع حالات اختبار من ملف Excel المعتمد.
  • شاشة الحجاج بالبحث والصفحات من القاعدة بدل تحميل 20,000 حاج في كل متصفح، ودالة إحصاءات واحدة للرئيسية بدل 25 استعلاماً.
  • تنسيق المغادرة والنقل: الباص = الإقلاع − 3.5 ساعة، وتجميع 90 دقيقة في الذروة، وإعادة الحساب فور تغيّر الرحلة، ولا يُستبعد أحد من كشف المغادرة.
  • المشاعر: عقود النوع 2، وتسكين المخيمات، والتفويج. يحتاج جلسة تفصيلية مع محمود.
  • تطبيق الحاج على الويب بدخول منفصل عن الموظفين لا يكشف إلا بياناته، ومعه شاشة الفندق.
  • وكلاء B2B: السجل، والحصص، والعمولة، وكشف الحساب. وربط الموازنة بالباقات المعتمدة والحجاج الفعليين.

البوابة: كل ما في هذه المرحلة جاهز قبل 1 مارس 2027.

المرحلة 3: الحجم الحقيقي، والبروفة، والشركات الخارجية

مارس 2027 · 35–45 يوماً
  • اختبار حمل ببيانات تجريبية: 20,000 حاج × 3 شركات، و300–1000 موظف وهمي، على بيئة التجربة. ثم الفهارس المطلوبة وإثباتها بالقياس.
  • الاتصالات اللحظية: قناة واحدة لكل موظف بدل قناتين، وإصلاح قسم المهام الذي يعيد تحميل كل شيء، ورفع سقف الخطة إن لزم.
  • نقل قيود المحاسبة من جدول الإعدادات إلى جدول حقيقي بقيود التوازن والترقيم، قبل أن يبدأ الإغلاق المالي.
  • سجل تدقيق عام لكل الجداول، وصلاحيات لكل شركة تتحدث أثناء الجلسة، وتنبيه بوجود نسخة جديدة، ومنع تكرار الحفظ.
  • تتبع الحقائب، والبلاغات، والإعاشة الفعلية. وبروفة كاملة للموسم ببيانات 1447 على بيئة التجربة.
  • تسجيل شركة جديدة من الواجهة، والحزمة التجارية (اتفاقية الخدمة، واتفاقية معالجة البيانات، والأدلة المصوّرة، والتدريب)، وتأهيل مطوّر ثانٍ.

البوابة: تجميد التغييرات من 1 أبريل 2027 إلا إصلاح الأعطال. الشركات الخارجية تُقبل فقط بعد نجاح اختبار الحمل، والعزل المختبَر، والنسخ الاحتياطي المجرَّب، والمطوّر الثاني، والحزمة التجارية.

المرحلة 4: تشغيل الموسم

أبريل – مايو 2027
  • وصول الحجاج من بداية أبريل تقريباً، وعرفة نحو 15 مايو، والمغادرة بعد 18 مايو تقريباً.
  • مراقبة يومية للوحة صحة البيانات، وإصلاح الأعطال فقط.

المرحلة 5: الإغلاق المالي

يُبنى يناير – أبريل · يُشغَّل يونيو – أغسطس 2027 · 25–40 يوماً
  • تسوية نسك والوزارة: مبالغ الفواتير والتحصيل ومحفظة نسك (يُتحقق أولاً هل يصدّر نسك المبالغ).
  • تسوية الموردين: المتعاقد مقابل المستهلك فعلاً (من التسكين والتوزيع المعتمدين) مقابل المدفوع.
  • تسوية الوكلاء: المبيع والعمولات والمتبقي.
  • المستردات والتعويضات وغرامات الإلغاء.
  • إقفال الموسم: قفل التعديل، وتقرير الربحية لكل باقة ولكل حاج، وأرشفة الموسم.
  • يُبنى على جدول الأحداث وجدول القيود الحقيقي، لا على قراءة جداول الوحدات الأخرى. ومعه دليل موظفي المالية.

قرارات مطلوبة من محمود

1. اعتماد التقسيم الزمني: الأساس والعزل قبل 25 ديسمبر، والميدان قبل 1 مارس، والإغلاق المالي يُشغَّل بعد الحج، بدل «كل شيء قبل 31 ديسمبر».
2. مطوّر ثانٍ من ديسمبر، لا من مارس: المرحلة 1 وحدها 35–45 يوماً مقابل 29 متاحة، والاعتماد على شخص واحد هو أكبر خطر تكرر من 1447.
3. اعتماد البنية المستهدفة مع حازم: لا إعادة كتابة؛ فصل الطبقات تدريجياً، وكل قسم جديد على النمط الجديد، وممنوع على أي شاشة جديدة الاتصال بالقاعدة مباشرة.
4. بوابة الشركات الخارجية: لا تُقبل أي شركة من خارج إعمار قبل العزل المختبَر والنسخ الاحتياطي المجرَّب والحزمة التجارية.
5. أقسام الموظفين والإدارية: هل تدخل في الخدمة المباعة لشركات الحج، أم تبقى داخلية لهوليداي إن؟

يحتاج تحقق قبل البناء