لماذا تفشل مشاريع ERP في الشركات العربية؟

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

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

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

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

غياب مالك داخلي: أول أسباب فشل تطبيق ERP

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

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

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

الإجراء المضاد: اجعل إدارة مشروع ERP مسؤولية شخص واحد من داخل الشركة، بتفويض مكتوب يمنحه حق الحسم في العمليات، وفرّغه من 30% على الأقل من مهامه اليومية. يجب أن يفهم العمل، لا البرمجيات فقط.

معالجة نقل البيانات كخطوة أخيرة

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

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

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

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

اعتبار التدريب بنداً في الميزانية لا مرحلة في المشروع

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

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

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

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

تخصيص النظام ليحافظ على عمليات معطوبة

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

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

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

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

تاريخ إطلاق يفرضه العقد لا الجاهزية

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

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

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

عدم قياس أي شيء بعد الإطلاق

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

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

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

اختيار النظام قبل تشخيص المشكلة

كثير من المشاريع تفشل قبل توقيع العقد. الشركة تقرر أنها «تحتاج ERP» بناءً على توصية أو عرض مقنع، دون أن تحدد أي مشكلة تحلها. وحين لا تكون المشكلة محددة، لا يمكن قياس الحل.

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

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

أسئلة شائعة

كم يستغرق تطبيق نظام ERP؟

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

ماذا أفعل إذا فشل مشروع ERP بالفعل؟

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

كيف أعرف أن شركتي جاهزة أصلاً لنظام ERP؟

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

الخلاصة

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

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

مشروع ERP متعثر؟ اطّلع على المشاريع أو تواصل معنا.

مقالات ذات صلة

• ما الفرق بين أنظمة ERP وأنظمة CRM
• لماذا تفشل مشاريع تطبيق ERP في الإمارات (بالإنجليزية)
• من هو خالد عرفة