التكلفة الملتزم بها مقابل التكلفة الفعلية: لماذا لا يمكن لعملية ضبط المشروع انتظار الفواتير

من أخطر المفاهيم الخاطئة في التحكم في مشروعات التشييد أن تفترض الشركة أن التكلفة الفعلية توضح ما إذا كان المشروع تحت السيطرة المالية.

 

في الواقع، هذا غير صحيح.

 

إذ توضح التكلفة الفعلية ما اعترفت به الشركة بالفعل باعتباره تكلفة متكبدة.

 

لكن التحكم في المشروع يحتاج إلى الإجابة عن سؤال أكثر أهمية بكثير:

 

ما حجم الالتزامات والتعرض المالي القائم بالفعل قبل أن تتحول التكلفة إلى فاتورة؟

 

وبالتالي، تصبح هنا التكلفة الملتزم بها (Committed Cost) عنصرًا بالغ الأهمية.

 

التكلفة الفعلية تنظر إلى الماضي، بينما التكلفة الملتزم بها تنظر إلى المستقبل

 

على سبيل المثال، لنفترض أن لدى مقاول ميزانية معتمدة بقيمة 10 ملايين درهم إماراتي لحزمة أعمال.

 

حتى الآن، سجّل المقاول تكلفة فعلية بقيمة 2 مليون درهم فقط.

 

للوهلة الأولى، قد يبدو أن المشروع في وضع مريح.

 

لكن ماذا لو أسند المقاول بالفعل 5 ملايين درهم إضافية من خلال أوامر شراء وعقود مقاولين من الباطن؟

 

بالإضافة إلى ذلك، ماذا لو كانت هناك حاجة إلى 4 ملايين درهم أخرى لاستكمال الأعمال المتبقية؟

 

نتيجة لذلك، لم يعد التعرض المالي الحقيقي للمشروع يقتصر على مليوني درهم.

 

بل قد يكون المشروع بالفعل متجهًا نحو تجاوز الميزانية.

 

ولهذا السبب لا يمكن أن يعتمد التحكم في تكاليف مشروعات التشييد على المعاملات المحاسبية المسجلة فقط.

 

بدلاً من ذلك، يتطلب التحكم السليم في المشروع الربط بين:

 

التكلفة الفعلية + الالتزامات المتبقية + التكلفة غير الملتزم بها لاستكمال الأعمال = التكلفة المتوقعة عند إتمام المشروع

 

كما يتوافق ذلك بصورة وثيقة مع مفهوم التكلفة التقديرية عند الإتمام (Estimate at Completion) المستخدم في التحكم بالمشروعات.

 

ما هي التكلفة الملتزم بها؟

 

تمثل التكلفة الملتزم بها النفقات التي سبق أن اعتمدها المقاول من خلال آليات رسمية مثل:

• • أوامر الشراء

 

• • عقود المقاولين من الباطن

 

• • التعديلات المعتمدة على العقود

 

• • اتفاقيات تأجير المعدات

 

• الالتزامات الأخرى التي أسندها المقاول رسميًا

 

لكن هناك تمييز مهم يجب الانتباه إليه.

 

بعبارة أخرى، إن إجمالي القيمة الملتزم بها لأمر الشراء لا يمثل بالضرورة قيمة الالتزام المتبقية.

 

على سبيل المثال، قد يكون المورد قد ورّد جزءًا من أمر الشراء بالفعل، أو استهلكه الفريق، أو اعترفت به الشركة باعتباره تكلفة فعلية.

 

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

 

لهذا السبب، يجب أن يميز نظام ERP المتخصص في مشروعات التشييد بين:

• • إجمالي القيمة المسندة

 

• • التكلفة المتكبدة بالفعل

 

• • التكلفة الملتزم بها المتبقية

 

• التكلفة غير الملتزم بها لاستكمال الأعمال

 

ويميز Oracle نفسه بين فئات الالتزامات المختلفة وحالات المعاملات في وثائقه الخاصة بتكاليف المشروعات.

 

باختصار، الدرس هنا بسيط:

 

لا يكفي أن نطلق على الرقم اسم «التكلفة الملتزم بها». بل يجب أن نفهم بدقة ما الذي يتضمنه هذا الرقم.

 

لماذا قد تصل البيانات المحاسبية متأخرة عن احتياجات التحكم في المشروع؟

 

ومع ذلك، هذا لا يعني أن الأنظمة المحاسبية غير قادرة على الاعتراف بالتكاليف قبل وصول الفاتورة.

 

بل يمكنها ذلك.

 

فمن خلال المحاسبة على أساس الاستحقاق، تستطيع الشركات الاعتراف بالالتزامات المتعلقة بالسلع أو الخدمات التي استلمتها بالفعل ولكن لم يرسل المورد فاتورتها بعد.

 

راجع معالجة المستحقات والحسابات الدائنة وفق معايير IFRS.

 

كما توثق Oracle أيضًا استحقاقات الاستلام غير المفوترة.

 

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

 

فعندما تصل فاتورة المورد إلى الإدارة المالية، قد تكون عدة أمور قد حدثت بالفعل:

 

أولاً، أنشأ فريق الموقع طلب المواد.

 

ثم اعتمد المقاول أمر الشراء.

 

بعد ذلك، اختار فريق المشتريات المورد.

 

ثم سلّم المورد المواد.

 

وربما استهلك الفريق المادة بالفعل.

 

وربما تقدم العمل بالفعل.

 

بعبارة أخرى، كان التعرض التجاري والمالي قائمًا قبل ظهور الفاتورة بوقت طويل.

 

لذلك، يجب أن يبدأ التحكم في المشروع في مرحلة أبكر من ذلك.

 

التحكم في تكاليف التشييد يبدأ قبل الفاتورة

 

يجب على المقاول متابعة الأثر المالي للمعاملة منذ اللحظة التي ينشأ فيها الاحتياج.

 

على سبيل المثال، يمكن أن يكون التسلسل النموذجي:

 

الاحتياج → طلب الشراء → الاعتماد → أمر الشراء → التسليم → الاستهلاك → الاعتراف بالتكلفة → الفاتورة → السداد

 

في الواقع، تجيب كل مرحلة عن سؤال مختلف.

 

أولاً، يوضح طلب الشراء الاحتياج.

 

ثم يوضح أمر الشراء الالتزام التجاري.

 

بعد ذلك، يوضح التسليم الاستلام.

 

كما يوضح استهلاك المواد الاستخدام الفعلي.

 

في المقابل، تنشئ الفاتورة التزامًا ماليًا.

 

أخيراً، يوضح السداد حركة النقد.

 

لذلك، لا ينبغي التعامل مع هذه الأحداث باعتبارها متطابقة أو قابلة للاستبدال.

 

وبالتالي، هذه إحدى الأفكار الأساسية وراء المشتريات القائمة على المشروع في ProjectVIEW ERP.

 

إذ إن الهدف ليس مجرد رقمنة عملية المشتريات.

 

بل ربط قرارات الشراء بالميزانية والاحتياج التشغيلي للمشروع اللذين نشأت عنهما هذه القرارات.

 

أكبر خطأ: العد المزدوج للتكاليف

 

على سبيل المثال، لنفترض وجود عقد مقاول من الباطن بقيمة إجمالية مسندة تبلغ 6 ملايين درهم.

 

نفّذ المقاول من الباطن أعمالاً بقيمة 2 مليون درهم بالفعل، وسجّلتها الشركة باعتبارها تكلفة فعلية.

 

وبالتالي، تبلغ قيمة الالتزام المتبقي نحو 4 ملايين درهم، بافتراض عدم وجود تعديلات أخرى.

 

إذا قامت الإدارة بالحساب التالي:

 

2 مليون درهم تكلفة فعلية + 6 ملايين درهم تكلفة ملتزم بها

 

فستصبح التكلفة المتوقعة 8 ملايين درهم.

 

لكن جزءًا من الالتزام البالغ 6 ملايين درهم مدرج بالفعل ضمن التكلفة الفعلية البالغة مليوني درهم.

 

وبذلك تكون الإدارة قد احتسبت العمل نفسه مرتين فعليًا.

 

لذلك، المنطق الصحيح هو:

 

التكلفة الفعلية + الالتزام المتبقي

 

بالإضافة إلى ذلك، تزداد أهمية هذا الأمر عند وجود المستحقات المحاسبية (Accruals).

 

فإذا سجّلت الشركة تكلفة مستحقة بالفعل، ثم وصلت فاتورة المورد لاحقًا، فيجب تسوية الاستحقاق أو استبداله، وليس احتسابه مرة أخرى.

 

كما توثق Oracle صراحةً هذا النوع من منطق عكس الاستحقاقات (Reversal Logic).

 

لماذا لا تخبرنا التكلفة الملتزم بها بكل شيء؟

 

حتى التكلفة الملتزم بها وحدها ليست كافية.

 

فقد لا يزال لدى المقاول قدر كبير من الأعمال التي لم يشترها بعد أو يسندها إلى مقاولين من الباطن.

 

ومن ذلك:

• • احتياجات العمالة المستقبلية

 

• • استخدام المعدات

 

• • الوقود

 

• • الأعمال المؤقتة

 

• • الإشراف على الموقع

 

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

 

• • تمديد مدة المشروع

 

• حزم أعمال المقاولين من الباطن التي لم يسندها المقاول بعد

 

في الواقع، قد لا تظهر هذه التكاليف بعد في صورة أوامر شراء.

 

لكنها تظل جزءًا من التكلفة المستقبلية اللازمة لاستكمال المشروع.

 

لذلك، فإن السؤال الحقيقي للتحكم في المشروع ليس:

 

«كم أنفقنا؟»

 

ولا هو:

 

«كم التزمنا به؟»

 

بل هو:

 

«ما التكلفة التي نتوقع الآن أن يصل إليها المشروع عند الإتمام؟»

 

لماذا يجب ربط النطاق والجدول الزمني والتكلفة؟

 

للإجابة عن هذا السؤال بصورة صحيحة، لا يمكن أن توجد التكاليف بمعزل عن سياقها.

 

في DANAOS Projects، ننظّم ذلك من خلال العلاقة بين:

 

BoQ ↔ WBS ↔ Cost Codes

 

أولاً، تحدد قائمة الكميات (BoQ) نطاق الأعمال التجاري والقابل للقياس.

 

ثم يربط هيكل تقسيم العمل (WBS) هذا النطاق بالتنفيذ والوقت.

 

أخيراً، تتيح أكواد التكاليف (Cost Codes) تصنيف التكاليف والموارد بصورة متسقة.

 

وقد تناولنا هذه العلاقة بالتفصيل هنا:

 

BoQ وWBS وأكواد التكاليف: كيف تربط شركات المقاولات بين نطاق الأعمال والجدول الزمني والتكلفة

 

نتيجة لذلك، تتيح هذه العلاقة للإدارة طرح أسئلة أكثر أهمية، مثل:

 

إلى أي نطاق من نطاقات الأعمال يرتبط هذا الالتزام؟

 

ما النشاط المتأثر؟

 

وكم تبلغ الكمية المتبقية؟

 

ما الموارد التي لا تزال مطلوبة؟

 

وكم تبلغ الميزانية المتبقية؟

 

ما التكلفة النهائية المتوقعة؟

 

ومن دون هذا الهيكل، قد تعرف الشركة مقدار ما أنفقته، لكنها لن تفهم بالضرورة لماذا أنفقته.

 

بيانات الموقع لا تقل أهمية

 

يعتمد التحكم في تكاليف المشروع أيضًا على ما يحدث فعليًا في الموقع.

 

على سبيل المثال، قد يوضح أمر الشراء ما اشتراه المقاول.

 

لكنه لا يخبرك ما إذا كان الفريق قد استخدم المورد بكفاءة.

 

بعبارة أخرى، المادة التي سلّمها المورد ليست بالضرورة مادة استهلكها الفريق.

 

كذلك، العمالة الموجودة في الموقع ليست بالضرورة عمالة منتجة.

 

والمعدات المتاحة ليست بالضرورة معدات منتجة.

 

كما أن التقدم المسجل محاسبيًا لا يعكس تلقائيًا التقدم الفعلي للأعمال.

 

لذلك، فإن جمع بيانات الموقع يمثل عنصرًا أساسيًا في التحكم الحديث في تكاليف مشروعات التشييد.

 

باختصار، الهدف هو ربط التعرض المالي بالواقع التشغيلي للمشروع.

 

كيف يتعامل ProjectVIEW ERP مع هذه المشكلة؟

 

يربط ProjectVIEW ERP بين المشتريات، وعمليات الموقع، والمقاولين من الباطن، والميزانية، والتحكم في التكاليف ضمن بيئة تشغيل واحدة مخصصة للمشروع.

 

• • وحدة التحكم في التكاليف في ProjectVIEW ERP

 

• وحدة المشتريات والتوريد

 

كما نشرح البنية المتكاملة بصورة أوسع هنا: كيف يحقق ProjectVIEW ERP تحكمًا حقيقيًا في التكاليف؟

 

في الواقع، الهدف ليس مجرد إنشاء تقرير آخر عن التكاليف.

 

بل تمكين فرق المشروع من فهم التعرض المالي للتكلفة في الوقت الذي لا يزال فيه هناك مجال لاتخاذ إجراء.

 

الخلاصة

 

صحيح أن المحاسبة أمر أساسي.

 

لكن المحاسبة والتحكم في المشروع يخدمان أغراضًا مختلفة.

 

إذ توضح المحاسبة ما اعترفت به المؤسسة ماليًا.

 

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

 

لذلك، بالنسبة لشركات المقاولات، فإن السؤال الأهم ليس:

 

«كم أنفقنا حتى الآن؟»

 

بل:

 

«ما حجم تعرضنا المالي القائم بالفعل، وما التكلفة الواقعية المتوقعة لهذا المشروع عند اكتماله؟»

 

باختصار، هذا هو الفرق بين تسجيل التكلفة والتحكم في التكلفة.