الخلاصة: أمر التغيير لا يبدأ عندما تصل فاتورة إضافية من المقاول الباطن، ولا عندما يكتشف المحاسب أن تكلفة المشروع ارتفعت. يبدأ من لحظة ظهور تغيير في الموقع: تعليمات من العميل، اختلاف في المخططات، ظرف غير متوقع، أو طلب تعديل في النطاق. عندها يجب تسجيله، وتقدير أثره، واعتماده، ثم ربطه بالمشتريات والتكلفة والمطالبة أو الإيراد.
في كثير من مشاريع المقاولات، تُنفذ الأعمال بسرعة بينما تبقى الموافقات موزعة بين البريد وواتساب ومحاضر الاجتماعات. بعد أسابيع يبدأ السؤال: من طلب العمل؟ هل اعتمده العميل؟ كم كلفنا؟ وهل تمت المطالبة بقيمته؟ هنا تظهر فائدة Odoo، ليس كزر موافقة فقط، بل كسجل يربط القرار بأثره المالي والتشغيلي.
الموافقة جزء من الدورة وليست الدورة كاملة
الموافقة تخبرنا بمن سمح بالقرار. أما إدارة أمر التغيير فتحتاج إجابات إضافية: ما الذي تغير بالضبط؟ ما المستند المؤيد؟ هل العمل داخل نطاق العقد أم خارجه؟ كم سيكلف؟ هل يؤثر في مدة المشروع؟ وكم نتوقع أن يعتمد العميل؟
ومن المهم عدم الخلط بين أوامر تغيير مشاريع المقاولات وبين Engineering Change Orders في تطبيق PLM. أوامر PLM مخصصة لتغييرات المنتجات وقوائم المواد ومسارات التصنيع. أما تغيير نطاق عقد إنشائي فيحتاج دورة مرتبطة بالمشروع والعقد والتكلفة والمطالبة.
ما المعلومات التي يجب أن يجمعها سجل التغيير؟
يفضل أن يكون لكل تغيير رقم مرجعي واحد يظهر في جميع المستندات اللاحقة، وأن يرتبط بالمشروع والعقد والعميل والفرع. ويشمل على الأقل:
- سبب التغيير ومصدر التعليمات وتاريخها.
- وصف النطاق قبل التعديل وبعده، مع الصور والمخططات والمراسلات.
- التكلفة المتوقعة، وأثر الوقت، وأهم الافتراضات المستخدمة.
- قيمة المطالبة المقترحة وقيمة اعتماد العميل عند صدورها.
- حالة الطلب: داخلي، مقدم، تحت التفاوض، معتمد، مرفوض، أو متنازع عليه.
- المسؤول الحالي والموعد المطلوب وسجل القرارات.
الفكرة بسيطة: عندما يسأل المدير عن تغيير معين، يصل إلى القصة كاملة من سجل واحد بدلاً من جمعها من خمسة أشخاص.
دورة عملية لأمر التغيير
1. سجل الإشعار فور ظهوره
لا تنتظر التسعير النهائي. يسجل مهندس الموقع أو مدير المشروع الحدث، وموقعه، ومصدر التعليمات، والمرفقات المتاحة. القيمة قد تتغير لاحقاً، لكن تاريخ الإشعار والدليل الأولي لا ينبغي أن يضيعا.
2. راجع النطاق والمسؤولية
يراجع الفريق التجاري العقد والمراسلات: هل العمل جديد فعلاً؟ من أصدر التعليمات؟ هل توجد مهلة لإرسال الإشعار؟ هذه مراجعة مهنية داخل الشركة، ولا ينبغي للنظام أن يصدر حكماً تعاقدياً من تلقاء نفسه.
3. قدّر التكلفة والمدة
اربط التقدير ببنود الكميات والعمالة والمواد والمعدات والموردين والمقاولين الباطنين. اكتب مصدر الأسعار والافتراضات. وافصل بين تكلفة التنفيذ المتوقعة والقيمة التي ستطالب بها الشركة؛ فالرقمان لا يؤديان الغرض نفسه.
4. مرر الاعتماد الداخلي المناسب
التغيير الصغير لا يحتاج بالضرورة المسار نفسه لتغيير قد يؤثر في هامش المشروع أو مدته. ابنوا مصفوفة اعتماد بحسب القيمة ونوع الأثر، مع بديل للمعتمد ومسار تصعيد واضح. وفي القيم المؤثرة، لا يكون الشخص الذي أعد التسعير هو المعتمد الوحيد.
5. وثّق التقديم ورد العميل
احتفظ بنسخة كل إصدار وتاريخ تقديمه والجهة المستلمة والرد. قد تقدم الشركة مطالبة بمليون ريال ويعتمد العميل 800 ألف؛ لا تستبدل الرقم الأول بالثاني. احتفظ بالقيمتين وسبب الفرق، حتى تظهر جودة التسعير والتفاوض بوضوح.
6. اربط المستندات الناتجة بالتغيير
بعد الحصول على الصلاحية المناسبة، تُحدّث الميزانية أو التوقع، وتصدر أوامر الشراء أو عقود المقاولين الباطنين، وتُجهز المطالبة أو المستخلص. ضع رقم أمر التغيير في كل مستند حتى تستطيع الإدارة معرفة التكلفة والالتزام والإيراد المرتبط به.
7. لا تغلقه قبل المطابقة
توقيع الاعتماد ليس نهاية العمل. قبل الإقفال، تأكد من صدور الالتزامات، وظهور التكلفة الفعلية، ومعالجة الإيراد أو المطالبة، واكتمال المستندات، وتحديث أي أثر زمني.
أين يفيد Odoo القياسي وأين قد نحتاج تطويراً؟
| الحاجة | نقطة البداية | متى نحتاج تصميماً إضافياً؟ |
|---|---|---|
| المرفقات والمناقشات والمتابعة | السجلات وChatter والأنشطة | عند الحاجة إلى بوابة عميل أو تبادل رسمي منظم |
| الموافقات | قواعد موافقة أو إجراءات مؤتمتة، بحسب البيئة | عند وجود صلاحيات متعددة أو تفويض ومصفوفات معقدة |
| المشتريات والتكلفة | المشتريات والمشاريع والحسابات التحليلية | عند الحاجة إلى ربط تفصيلي ببنود الكميات أو التزامات متعددة المستويات |
| المطالبة والإيراد | المبيعات والفوترة والتحليلات | عند وجود مستخلصات واحتجاز وقياس إنجاز خاص بالعقد |
ابدأوا دائماً بعرض السيناريو على Odoo القياسي، ثم وثّقوا الفجوة. لا تصفوا شاشة مخصصة بأنها وظيفة قياسية، ولا تبدأوا التطوير قبل اعتماد دورة العمل ومعايير قبولها.
ضوابط تقلل التسرب المالي
- لا يصدر التزام إضافي من دون مشروع ومرجع تغيير عندما تستدعي الدورة ذلك.
- تُحفظ التكلفة المتوقعة وقيمة المطالبة وقيمة اعتماد العميل في حقول منفصلة.
- تظهر الأعمال المنفذة قبل الاعتماد كتعرّض تجاري يحتاج متابعة.
- كل تعديل في النطاق أو القيمة يحتفظ بالسبب والمستخدم والتاريخ.
- تصل تنبيهات قبل انتهاء مهلة الإشعار أو عند تأخر الرد.
- تُراجع التغييرات المفتوحة دورياً بحسب المشروع والعميل والعمر والقيمة.
ما الذي تحتاج الإدارة إلى رؤيته؟
لوحة المتابعة المفيدة تعرض عدد وقيمة التغييرات بحسب الحالة، والمدة من التسجيل إلى التقديم، والمدة حتى قرار العميل، والتكلفة التي نُفذت قبل الاعتماد، والفرق بين المطالبة والاعتماد، والالتزامات غير المغطاة. والأهم أن يستطيع المدير فتح السجل والمستندات خلف كل رقم.
أسئلة شائعة
هل تطبيق Approvals وحده يكفي؟
قد يناسب طلباً بسيطاً، لكنه لا يضمن وحده ربط التغيير بالعقد والميزانية والمشتريات والتكلفة والإيراد. الحل يعتمد على حجم المشاريع ومستوى الرقابة المطلوب.
هل ننتظر موافقة العميل قبل تسجيل التغيير؟
لا. سجلوا الإشعار والتعرّض مبكراً، مع توضيح أن الحالة والقيمة لم تعتمدا بعد. التأخير يخفي المخاطر ويضعف المستندات المؤيدة.
ماذا عن الأعمال العاجلة في الموقع؟
خصصوا مساراً استثنائياً يوضح من يسمح بالبدء، وحدود القيمة، والمستندات المطلوبة، والمهلة لإكمال الاعتماد. العمل العاجل يحتاج مرونة، لكنه لا يحتاج إلغاء الرقابة.
تستطيع نيار للحلول مراجعة دورة أوامر التغيير لديكم وتحويلها إلى نموذج واضح في Odoo يربط طلب الموقع بالقرار والتكلفة والمطالبة، مع توضيح ما هو قياسي وما يحتاج إعداداً أو تطويراً. يمكنكم أيضاً قراءة دليل طلبات الموقع والموافقات والمشتريات والتعرف على خدمات Odoo لشركات المقاولات.
