10 أسباب لفشل مشاريع ERP وكيف تتجنبها

نادرًا ما يفشل مشروع ERP لأن البرنامج سيئ. فالأنظمة المعروفة، ومنها أودو (Odoo)، تعمل بنجاح في شركات كثيرة من مختلف الأحجام والقطاعات. وأسباب فشل مشاريع ERP تبدأ غالبًا قبل كتابة أول إعداد: في قرار غائب، أو فريق مشغول، أو توقعات غير واقعية. ويأخذ أشكالًا مختلفة؛ مشروع لا ينتهي، أو نظام يعمل على الورق بينما الشركة تُدار من الإكسل، أو تكلفة تتضاعف دون نتيجة.

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

الأسباب الإدارية لفشل مشاريع ERP

1. غياب صاحب قرار يتبنى المشروع

حين يُسلَّم المشروع لقسم تقنية المعلومات أو للمحاسب وحده، تبقى القرارات الكبرى معلّقة: من يوحّد طريقة العمل بين الأقسام؟ ومن يُلزم المدير المتردد؟

الحل: صاحب قرار من الإدارة العليا يحضر اجتماعات المتابعة الأساسية، ويحسم الخلافات بين الأقسام في أيام لا أسابيع.

2. أهداف غامضة ونطاق يتمدد

«نريد نظامًا متكاملًا» ليس هدفًا. ومع غياب هدف محدد يضاف كل أسبوع طلب جديد، فيتأخر الإطلاق شهرًا بعد شهر.

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

3. فريق داخلي بلا وقت مخصص

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

الحل: ساعات أسبوعية ثابتة للمشروع في جدولهم، وتخفيف جزء من أعمالهم المعتادة خلال فترة التنفيذ.

4. اعتبار الإطلاق خط النهاية

تنتهي الميزانية والاهتمام يوم الإطلاق، بينما أصعب الأسابيع تأتي بعده: أول إقفال، وأول جرد، وأول ضغط عمل حقيقي على النظام.

الحل: خطة دعم لما بعد الإطلاق ضمن العقد من البداية، تمتد على الأقل حتى أول إقفال شهري ناجح.

الأسباب الفنية

5. التخصيص المفرط

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

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

6. بيانات غير نظيفة

أصناف مكررة، وأرصدة غير مطابقة، وعملاء بلا بيانات ضريبية. فيرى الموظف في أول يوم أرقامًا لا يثق بها، ويعود إلى ملفاته.

الحل: تنظيف البيانات يبدأ مع بداية المشروع لا في أسبوعه الأخير، ولكل ملف مالك مسؤول عنه، ولا إطلاق قبل مطابقة موقّعة للأرصدة.

7. اختبار سطحي

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

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

8. اختيار غير مناسب للنسخة أو الاستضافة أو المنفّذ

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

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

الأسباب البشرية

9. مقاومة التغيير

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

الحل: إشراك الموظفين من ورش التحليل الأولى، وشرح ما سيكسبه كل منهم تحديدًا، ورسالة واضحة من الإدارة بأن النظام قرار نهائي لا تجربة.

10. تدريب ضعيف وتسامح مع الإكسل الموازي

جلسة تدريب عامة واحدة، ثم يُسمح للموظف بأن «يكمل على الإكسل حتى يتعود». والنتيجة أنه لا يتعود أبدًا.

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

علامات الإنذار المبكر: جدول مراجعة سريع

إن لاحظت إحدى هذه العلامات في مشروعك، فتعامل معها فورًا:

قبل أن تبدأ: خمسة أسئلة لتقييم جاهزية شركتك

أغلب الأسباب العشرة يمكن اكتشافها قبل توقيع العقد. أجب عن هذه الأسئلة بصراحة:

1. هل يوجد شخص في الإدارة العليا سيخصص وقتًا أسبوعيًا للمشروع، ويملك صلاحية الحسم بين الأقسام؟
2. هل تستطيع أن تكتب في ثلاثة أسطر ما الذي يجب أن يتغير في شركتك بعد ستة أشهر من التشغيل؟
3. هل حددت مستخدمًا رئيسيًا لكل قسم، ووافق مديره على تفريغه جزئيًا؟
4. هل بياناتك الأساسية من أصناف وعملاء وأرصدة في مكان معروف، ولكل منها مسؤول؟
5. هل تشمل ميزانيتك التدريب والدعم بعد الإطلاق، لا التنفيذ وحده؟

إن كانت الإجابة «لا» عن سؤالين أو أكثر، فعالج ذلك قبل التعاقد؛ فإصلاحه الآن أسهل وأرخص بكثير من إصلاحه في منتصف المشروع.

الخلاصة

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

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