في نظرية الألعاب، تُعد لعبة المحصلة الصفرية بسيطة: ربح طرف يعني خسارة طرف آخر. تبقى القيمة الإجمالية كما هي. وبعبارة أخرى، هناك رابح وخاسر.
وللأسف، هذه هي بالضبط الطريقة التي لا تزال تعمل بها معظم مؤسسات الإنشاءات—داخلياً وخارجياً.
وهذا هو السبب الحقيقي لتجاوز المشاريع للميزانيات وتبخر الهوامش. ونتيجةً لذلك، تلوم الشركات أنظمة ERP على مشكلات لم تُصمم هذه الأنظمة قط لحلها.
التفكير الصفري المحصلة هو القاتل الصامت لربحية الإنشاءات
نظرياً، تهدف شركات الإنشاءات إلى زيادة الهوامش، وتحسين الإنتاجية، وتحقيق القدرة على التنبؤ. عملياً، تعمل بهذه الطريقة:
- التقدير يفوز بالعطاءات بخفض الأسعار → التنفيذ يرث ميزانيات مستحيلة
- المشتريات توفر المال في أسعار الوحدات → الموقع يدفع لاحقاً في التأخيرات وإعادة العمل
- المالية تفرض ضوابط صارمة → العمليات تتجاوز النظام
- المشاريع تتنافس على الموارد نفسها → ينهار أداء المحفظة
في الإنشاءات ذات المحصلة الصفرية، فإن كل «ربح» يخلق بالتالي «خسارة» مقابلة في مكان آخر.
هذا ليس تعاوناً. بل هو منظمة ذات محصلة صفرية.
لماذا الإنشاءات معرضة بشكل خاص لألعاب المحصلة الصفرية
الإنشاءات هي العاصفة المثالية لسلوك المحصلة الصفرية، لأن العمل:
- ذو سعر ثابت أو هامش منخفض بطبيعته
- شديد التجزؤ (مكتب، موقع، مورّدون، مقاولو باطن)
- محكوم بالوقت وكثيف التغيير
- يعتمد على معلومات متأخرة أو غير مكتملة أو مشوهة
عندما تكون الزمن والتكلفة والنطاق غير مترابطة، يصبح كل تعديل تفاوضاً:
«إذا تحملتُ هذه الكلفة، فمن سيدفع عنها؟»
وبالتالي، بحلول الوقت الذي ترى فيه الإدارة المشكلة، تكون الخسارة قد ثبتت بالفعل.
معظم أنظمة ERP تُرقمن المشكلة — لكنها لا تحلها
لنكن صرحاء.
على سبيل المثال، أنظمة ERP التقليدية:
- تعامل المشاريع كحاويات محاسبية
- تلتقط التكاليف بعد حدوثها
- تفرض الضوابط بأثر رجعي
- وتبقي التخطيط والتنفيذ والمشتريات مترابطة بشكل ضعيف
عملياً، ما تفعله حقاً هو رقمنة سلوك المحصلة الصفرية:
- الأقسام تحمي نفسها
- تصبح البيانات سياسية
- تتوقف القرارات
- يحل اللوم محل التحكم
ونتيجةً لذلك، يصبح النظام حكماً، لا نظام تشغيل.
كيف يكسر ProjectVIEW ERP نموذج المحصلة الصفرية
وعلى النقيض، بنت DANAOS Projects نظام ProjectVIEW ERP على فرضية مختلفة:
ربحية الإنشاءات ليست مشكلة تفاوض. إنها مشكلة مواءمة.
BoQ وWBS وأكواد التكلفة — مواءمة مستمرة
يعمل ProjectVIEW على مواءمة:
- BoQ (ما الذي بعته)،
- WBS (متى تنفذ)،
- أكواد التكلفة (كيف تتحرك الأموال فعلياً)،
في الوقت الفعلي.
وهذا يعني أن:
- الفرق تكتشف الانحرافات مبكراً، لا بعد وقوع الضرر
- المفاضلات تصبح مرئية ومقيسة
- المديرون يقررون قبل أن تتفاقم الخسائر
وبدلاً من نقل الخسائر بين الأقسام، يساعد النظام على منعها بالكامل.
باختصار، هكذا تنتقل من المحصلة الصفرية إلى تنفيذ موجب المحصلة.
ضبط التكلفة من دون رابحين وخاسرين
- يقع ضبط التكلفة داخل العمليات اليومية
- الموافقات سياقية، سريعة، وقابلة للتتبع
- تعمل المالية والعمليات على نفس الواقع، وفي الوقت نفسه
وبالتالي، لا توجد رقابة قسرية، ولا نظام موازٍ، ولا مفاجآت متأخرة.
لذلك، عندما يرى الجميع الحقيقة نفسها، لا يحتاج أحد إلى “الانتصار” داخليًا.
أصبحت المشتريات تتوقف عن كونها معركة سكاكين
أما منطق المشتريات التقليدي، فهو في المقابل منطق صفري:
يفوز أقل سعر — ثم يتحمل طرف آخر المخاطر لاحقًا.
بدلًا من ذلك، يربط ProjectVIEW المشتريات مباشرةً بما يلي:
- كميات BoQ
- توقيت WBS
- الطلب الفعلي في الموقع
- التجميع على مستوى المحفظة
والنتيجة:
- أسعار أفضل وت توافر أفضل
- هدر أقل، وتسريع أقل، وإطفاء حرائق أقل
- يصبح الموردون شركاء لا خصومًا
هذا ليس مجرد نظرية. بل ميزة هيكلية.
من ثقافة اللوم إلى المرونة المنضبطة
عندما تكون الأنظمة عمياء، يتلاعب الناس بها. وبالمثل، عندما يصل الواقع متأخرًا، يتبعه الذعر.
يفرض ProjectVIEW مراجعة مستمرة للواقع:
- الفعلي مقابل الميزانية
- المخطط مقابل المنفذ
- المعتمد مقابل المنحرف
وبالتالي، يتغير هيكل الحوافز:
- إخفاء المشكلات لا يجدي
- معالجتها مبكرًا يجدي
وفي النهاية، هكذا تعمل مؤسسات البناء الناضجة.
الخلاصة
معظم شركات الإنشاءات لا تفشل لأنها تفتقر إلى الجهد، بل لأنها تعمل داخل أنظمة صفرية الصفر.
غير أن معظم أنظمة ERP تعزز هذا السلوك. ويزيل ProjectVIEW ERP ذلك بطبيعته.
هو لا يعد بالمعجزات. بل يفرض الواقع، مبكرًا وباستمرار وعلى مستوى المؤسسة بأكملها.
وهكذا يعمل البناء المربح بالفعل.
