لماذا تفشل مشاريع ERP وكيف تتجنب ذلك؟ دليل عملي قبل التعاقد وبعد التشغيلالأسباب العشرة الأكثر تكراراً، وإشارات الإنذار المبكر، ومراحل التطبيق التي تحمي المشروع من التعثر

قد يعمل نظام ERP تقنياً بينما يفشل المشروع تجارياً: الفواتير تخرج من النظام، لكن الفريق يعود إلى جداول Excel لمتابعة عمله الحقيقي؛ والمخزون ظاهر على الشاشة، لكن لا أحد يثق بالكميات فيعدّون يدوياً قبل كل شحنة؛ والتقرير متاح، لكنه لا يجيب عن سؤال الربحية الذي طرحه المدير. لذلك لا يكفي سؤال «هل اشتغل النظام؟» عند تحليل فشل مشاريع ERP. ينبغي الاتفاق منذ البداية على نتيجة الأعمال المطلوبة، والبيانات، والمستخدمين، والوقت والتكلفة المقبولين.

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

نجاح مشروع ERP يُقاس في الاستخدام اليومي والنتيجة التشغيلية، لا في تسليم الترخيص

ماذا نعني بفشل مشروع ERP؟

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

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

الأسباب العشرة الأكثر تكراراً لفشل مشاريع ERP

1. هدف تجاري غير محدد

«نريد التحول الرقمي» لا يكفي. حدد مثلاً: إقفال الشهر في خمسة أيام بدل خمسة عشر، أو خفض فروق الجرد إلى أقل من 1%، أو معرفة تكلفة المشروع أسبوعياً بدل ربع سنوي. ضع الوضع الحالي لكل مؤشر، ومن يقيسه، وموعد القياس بعد التشغيل. المشروع الذي لا يملك هذه الأرقام لا يمكن أن ينجح ولا أن يفشل؛ يمكن فقط أن ينتهي.

2. نطاق يتوسع بلا قرار

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

3. نقل الإجراءات القديمة إلى النظام حرفياً

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

4. بيانات غير جاهزة

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

5. غياب مالك قرار من الشركة

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

أغلب أسباب فشل مشاريع ERP تبدأ من غياب فريق مشترك: مالكو العمليات يقررون، والمنفذون يهيئون ويختبرون

6. التخصيص المبكر

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

7. ربط الأنظمة في نهاية المشروع

إذا كانت المبيعات تأتي من متجر إلكتروني أو منصة، والفواتير تمر بمنصة فاتورة لدى زاتكا (راجع الموجة 25 من الفاتورة الإلكترونية)، والبنك يوفر كشفاً آلياً، فهذه ليست إضافات تجميلية تُترك للأسبوع الأخير. صمم من بداية التحليل: مصدر الحقيقة لكل بيان، وتوقيت المزامنة، ومعالجة التكرار، وسيناريو الانقطاع وإعادة الإرسال.

8. اختبارات سطحية

نجاح فتح الشاشة لا يثبت صحة القيد أو تقرير الربحية. نفّذ حالات كاملة: بيع ثم مرتجع، شراء ثم استلام جزئي، حركة مخزون بين مستودعين، دفع بعملة أجنبية، إقفال فترة. قارن النتيجة بمستندات وأرصدة مرجعية من النظام القديم، وسجّل من قبِل كل حالة ومتى.

9. تدريب على القوائم بدل مهام الوظيفة

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

10. اعتبار يوم الإطلاق نهاية المشروع

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

إشارات إنذار مبكر قبل فوات الموعد

مراحل تطبيق ERP بصورة قابلة للقبول

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

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

تجنب فشل مشاريع ERP يعتمد على قرارات الشركة قبل قدرات النظام، لأن المشروع جزء من تحول رقمي أوسع

من يفعل ماذا؟ توزيع الأدوار بين الشركة والشريك

كثير من حالات التعثر في تنفيذ نظام ERP تبدأ من افتراض غير معلن: الشركة تظن أن الشريك «سيتولى كل شيء»، والشريك يظن أن الشركة «ستوفر البيانات والقرارات في وقتها». الجدول التالي يوضح التوزيع الذي يحمي المشروع من أشهر أسباب فشل مشاريع ERP، ويستحق أن يُلحق بالعقد.

مثال نموذجي: مشروع تعثر ثم أُنقذ

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

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

كم المدة الواقعية لتطبيق ERP؟

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

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

قبل التعاقد: سبعة بنود في عرض التنفيذ

1. النطاق: الوظائف والكيانات والمواقع والمستخدمين المشمولين، وما هو خارج النطاق صراحة.
2. القياسي مقابل الخاص: الوظائف القياسية مقابل التطوير الخاص والتكاملات، بتكلفة كل منها.
3. البيانات: ما يُنقل، وطريقة المطابقة، والمسؤول عن التنظيف من كل طرف.
4. القبول: سيناريوهات محددة بنتيجة قابلة للتحقق لكل مرحلة.
5. المسؤوليات: جدول بمسؤوليات الشركة والشريك وموعد كل قرار مطلوب من الشركة.
6. التغيير: آلية طلبات التغيير والتأخير والتصعيد وأثرها على الموعد والتكلفة.
7. ما بعد الإطلاق: خطة الدعم ومدتها ومستوى الاستجابة، وما لا يشمله العرض.

أثناء المشروع وبعده

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

تعمل كريفي سوفت في تحليل وتطبيق أودو وOracle NetSuite ضمن نهج التحول الرقمي المؤسسي. يمكن بدء النقاش بعرض عملية واحدة متعثرة وبياناتها ومؤشر النجاح المطلوب، ثم تحديد نطاق تنفيذ واقعي بمعايير قبول واضحة. وإذا كنت ما زلت تتساءل هل تحتاج ERP أصلاً، فابدأ بمقالنا برنامج محاسبة أم نظام ERP؟

أسئلة شائعة عن فشل مشاريع ERP

هل توجد نسبة مؤكدة لفشل مشاريع ERP؟

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

هل السبب عادةً النظام أم الشريك؟

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

هل يمكن إصلاح مشروع ERP تعثر؟

نعم في أغلب الحالات. ابدأ بتدقيق العمليات والبيانات والتخصيصات والتقارير والقرارات المعلقة، ثم خطة إنقاذ بقبول مرحلي واضح، وأحياناً بتقليص النطاق مؤقتاً.

ما أهم اختبار قبل الإطلاق؟

رحلات كاملة من مستند البداية إلى القيد والتقرير مع حالات استثناء، يوقّع عليها المستخدمون الرئيسيون بأنفسهم.

هل كثرة التخصيصات مؤشر فشل؟

ليست وحدها؛ المشكلة تخصيص بلا قيمة محددة أو توثيق أو خطة اختبار وترقية.

من يملك البيانات في المشروع؟

المنشأة مسؤولة عن تحديد الصحيح وما يجب تنظيفه واعتماده؛ الشريك ينفّذ قواعد الترحيل والاختبارات المتفق عليها.

هل ينتهي المشروع عند Go-live؟

لا؛ راقب الاستقرار والتبني والنتائج لثلاثة أشهر على الأقل، ثم خطط للتحسين والمرحلة التالية.

ما أول خطوة لمن يفكر في تطبيق ERP؟

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

خلاصة

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

المراجع

• Odoo: ترقية قاعدة بيانات مخصصة
• Odoo: دليل الترقية
• Oracle NetSuite: OneWorld Overview