kalshaer.me

Writing ·

لماذا تفشل مشاريع أنظمة تخطيط الموارد؟ السبب في العملية لا في البرنامج

بعد اثني عشر عامًا داخل الإدارات المالية في أبوظبي، النمط واضح: البرنامج نادرًا ما يكون سبب الفشل.

عملتُ على جانبي مشاريع تخطيط موارد المؤسسات. في البداية كمحاسب مضطر للتعايش مع النتيجة، ثم كمن يكتب البرمجة نفسها. وكل جانب منهما يفسّر الآخر.

النمط الذي أراه يتكرر: البرنامج يعمل، أما العملية المحيطة به فلا.

مشكلة الترجمة

في أي مشروع تطبيق نظام هناك مجموعتان في الغرفة. مجموعة تعرف كيف تعمل المؤسسة فعليًا — أي الموافقات شكلية، ولماذا توجد تسوية معينة بسبب حادثة وقعت قبل سنوات. ومجموعة تعرف ما الذي يستطيع النظام فعله.

لا تتحدث أي منهما لغة الأخرى، فيُكتب مستند لسدّ الفجوة: متطلبات تُوثَّق وتُعتمد وتُسلَّم. وفي هذا التسليم تضيع الأمور المهمة، لأنها لم تُكتب أصلًا — فهي بالنسبة للفريق المالي أوضح من أن تُذكر، والمستشار لم يكن يعرف أنه ينبغي أن يسأل عنها.

وبعد ستة أشهر يصبح لديك نظام لا يثق به أحد، وجدول بيانات موازٍ يقوم بالعمل الحقيقي.

ماذا تعني “العملية أولًا” عمليًا

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

التنفيذ الصحيح يبدو هكذا:

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

وثّق العملية الحالية دون حكم. الهدف ليس البحث عن الأخطاء، بل إنتاج وصف يعترف الفريق بأنه صحيح. إذا قرأوه وقالوا “ليس تمامًا هكذا”، فأنت لم تنتهِ بعد.

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

احصل على موافقة المالية والعمليات معًا. في الغرفة نفسها، لا بالتتابع. أغلب الخلافات حول العمليات هي في حقيقتها خلاف حول من يتحمّل الإزعاج، وهذا لا يُحسم إلا وجهًا لوجه.

بعد ذلك فقط يتحوّل الأمر إلى إعداد النظام.

لماذا ينبغي أن يكون المحاسب داخل عملية البناء

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

الأسئلة التي تحدد نجاح التطبيق ليست أسئلة تقنية:

  • هل يكون هذا مركز تكلفة منفصلًا أم بُعدًا ضمن المشروع؟
  • ماذا يحدث فعليًا حين يطالب المقاول بأعمال لم تجتز الفحص؟
  • هل تُحتجز المحتجزات لكل فاتورة أم لكل عقد، ومن يفرج عنها؟
  • عند تجاوز الموازنة، هل يمنع النظام الحركة أم يكتفي بالتنبيه؟

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

الخلاصة غير المريحة

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

انظر إلى العملية أولًا. في تجربتي، النظام ينفّذ تمامًا ما طُلب منه، والمشكلة أن أحدًا لم يتحقق مما إذا كان ذلك هو ما تحتاجه المؤسسة.

هذه ليست إجابة مريحة، لأنها تعني أن الحل بطيء وإنساني ويتطلب الجلوس مع الناس. لكنها الإجابة التي تنجح.

Next step

Facing this in your own business?

A free 30-minute process review is the fastest way to find out what it would take to fix it.