لماذا تتعثر مشاريع تطبيق ERP وكيف تتجنب ذلك؟

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

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

1. المراحل الأساسية لتطبيق نظام ERP

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

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

وتجاوز أي مرحلة أو اختصارها تحت ضغط الوقت يؤجل المشكلة ولا يلغيها.

2. غموض النطاق وتضخمه أثناء المشروع

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

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

3. غياب الراعي الإداري وصاحب القرار

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

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

وغياب هؤلاء يجعل المزوّد يتخذ قرارات تخص عمليات الشركة دون أن يعرفها كما يعرفها أهلها.

4. الإفراط في التخصيص بدل مراجعة الإجراءات

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

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

5. الاستهانة بالبيانات والاختبار

يُعامَل ترحيل البيانات والاختبار أحيانًا كأنهما مهمتان فنيتان تُنجزان في الأيام الأخيرة، مع أنهما من أكثر المراحل تأثيرًا في نجاح الإطلاق.

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

ولذلك يحسن أن تبدأ أعمال البيانات مبكرًا بالتوازي مع الإعداد، لا بعده.

6. ضعف التدريب وإدارة التغيير

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

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

الخلاصة

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