لماذا تفشل مشاريع ERP — الأسباب الحقيقية لا المعلنة

حين يفشل مشروع ERP يُقال إن النظام لم يناسب الشركة.

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

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

السبعة، وعلامة كل واحد

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

وأربعة من السبعة قرارات إدارية بحتة لا علاقة للبرنامج بها.

الأول: مالك المشروع

والفرق بين مشروع بمالك ومشروع بلا مالك يظهر عند أول تعارض: قسم يريد شيئاً وقسم آخر يريد نقيضه.

فبلا مالك يذهب القرار إلى التأجيل، ويتحوّل النظام إلى نسخة عن الفوضى القائمة.

والمالك ليس مدير تقنية المعلومات. هو شخص من التشغيل يملك سلطة تغيير طريقة العمل — ومن لا يملكها لا يملك المشروع مهما كان مسمّاه.

الثاني: النطاق الذي يتمدّد بلا قرار

ولا يتمدّد بقفزة؛ يتمدّد بطلبات صغيرة معقولة كلٌّ منها على حدة.

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

ولا يهمّ أي الثلاثة يُختار — يهمّ ألّا يدخل شيء بلا واحد منها.

الثالث: البيانات

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

ومفصَّل في ترحيل البيانات، والخلاصة أن التنظيف عمل لا يحتاج نظاماً — فمن أخّره حتى وصول المورّد اشترى تأخيراً بلا سبب.

الرابع: التخصيص بدل تغيير العمل

وليست القاعدة أن التخصيص خطأ؛ بعضه ضرورة تنافسية.

والقاعدة أن يُسأل عن كل طلب سؤال واحد: هل هذه الطريقة ميزة تنافسية لنا، أم عادة ورثناها من قيد النظام القديم؟

والأكثرية تقع في الثاني. وكل تخصيص غير ضروري يُدفع ثمنه مرّتين: مرّة عند كتابته، ومرّة مع كل ترقية بعدها — والثانية هي التي لا تُحسب في الميزانية.

الخامس: التدريب

والفرق بين تدريب ناجح وفاشل ليس عدد الساعات؛ هو ما يُدرَّب عليه.

فمن دُرِّب على تسلسل نقرات ينهار عند أول انحراف: مرتجع، أو استلام جزئي، أو خطأ يحتاج تصحيحاً. ومن دُرِّب على الدورة يعرف أين هو ولماذا، فيتصرّف في ما لم يُدرَّب عليه.

والاختبار العملي: اطلب من المستخدم أن يشرح ماذا يحدث في النظام بعد ضغطه الزرّ. ومن لا يعرف لم يُدرَّب؛ حُفِّظ.

السادس: الإطلاق دفعة واحدة

ويبدو أوفر على الورق، وأثره أن كل عيب في أي وحدة يوقف الإطلاق كلّه.

والبديل موجتان: الأساسيات أولاً، ثم البقيّة بعد إقفال شهرين ناجحين — وتفصيله في وحدات نظام ERP.

السابع: لا مقياس للنجاح

والسؤال الذي يكشفه: ما الذي يجعل هذا المشروع ناجحاً بعد سنة؟

والجواب الشائع «أن يعمل النظام» ليس مقياساً؛ لا أحد يستطيع أن يثبته أو ينفيه، فيبقى الحكم انطباعاً وتُقاس النتيجة بمزاج آخر اجتماع.

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

القاسم المشترك بين السبعة

كلها قرارات تُتَّخذ قبل أن تُفتح الشاشة الأولى.

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

ما تفعله اليوم

• اكتب اسم مالك المشروع، وتأكّد أنه يملك تغيير طريقة العمل لا وصفها فقط.
• أعلن قاعدة النطاق في الجلسة الأولى، مكتوبة.
• ابدأ تنظيف بياناتك قبل أي شيء آخر.
• قِس أربعة مقاييس اليوم، واحتفظ بها ورقة مؤرَّخة.

وأين تذهب من هنا

السبب الثالث مفصَّل في ترحيل البيانات، والسادس في وحدات نظام ERP، وأسلوب كشف الوعود قبل التوقيع في قراءة العرض التقديمي — وليلة الانتقال نفسها في ليلة الإطلاق.

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