10 أخطاء في تطبيق أنظمة تخطيط موارد المؤسسات (ERP) تُطيح بالمشاريع.

كل تشريح لأسباب فشل مشروع نظام تخطيط موارد المؤسسات (ERP) يُلقي باللوم على متهم مختلف — البرنامج، أو الميزانية، أو الجدول الزمني — وكلها تقريباً مخطئة بالطريقة نفسها. فكّك مشروع SAP متعثراً، أو مشروع Dynamics شُطب بهدوء، أو تطبيق أودو عاد تدريجياً إلى جداول البيانات، وستجد أن التقنية نادراً ما تكون السبب الفعلي. فالأسباب تتكرر من مشروع إلى آخر، ومن مورّد إلى آخر، وتتعلق كلها تقريباً بطريقة حوكمة المشروع، لا بالنظام الذي بُني عليه.

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

أخطاء في الأساسات، قبل أن يبدأ الإعداد أصلاً

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

• 1. شراء البرنامج قبل رسم خريطة العمليات. العَرَض: ترخيص موقّع وموعد تشغيل فعلي متفق عليه في الاجتماع نفسه الذي تُذكر فيه كلمة «العمليات» لأول مرة. وبعد أشهر، يجد الفريق نفسه يطوّع النظام ليتوافق مع سير عمل لم يوثّقه أحد، لأن أحداً لم يدرس كيف تعمل الشركة فعلاً قبل اختيار النظام الذي سيديرها. والعلاج ليس براقاً لكنه غير قابل للتفاوض: دراسة موثقة للعمليات قبل توقيع العقد، ليُقاس ما يُبنى على واقع الأعمال، لا العكس.
• 2. غياب مالك داخلي واحد يملك صلاحية قرار حقيقية. يظهر العَرَض في كل اجتماع للجنة التوجيهية: يُطرح السؤال نفسه ثلاث مرات لأن من أجاب عنه في المرة السابقة لم يتمكن من تثبيت إجابته. تتنقل القرارات بين الإدارات، ويُعاد فتحها بعد حسمها، وينتهي الأمر بالشريك إلى إدارة السياسات الداخلية بدلاً من بناء النظام. والعلاج: تعيين مالك واحد من الإدارة العليا قبل انطلاق المشروع، يملك صلاحية القرار والمكانة التي تجعل قراره نافذاً.
• 3. ترحيل بيانات غير نظيفة ثم الوثوق بها رغم ذلك. عملاء مكررون، وأرصدة مخزون كانت خاطئة قبل الترحيل وتبقى خاطئة بعده، وبنود في دليل الحسابات لا يستطيع أحد تفسيرها. كان التحذير القديم يقول «مدخلات رديئة، مخرجات رديئة»، لكن نظام تخطيط موارد المؤسسات (ERP) يزيد الأمر سوءاً: مدخلات رديئة، ومخرجات تُصدَّق بلا نقاش، لأن الرقم يبدو صحيحاً بمجرد ظهوره على لوحة معلومات أنيقة. والعلاج: مرحلة تنقية ومطابقة جادة قبل الانتقال إلى النظام الجديد، يصادق فيها مسؤولو الأقسام، لا فريق تقنية المعلومات وحده، على أن البيانات المرحّلة صحيحة فعلاً.

أخطاء في البناء، أثناء الإعداد والتشغيل الفعلي

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

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

أخطاء في الشراكة، يُدفع ثمنها بعد التشغيل الفعلي

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

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

فقدان السيطرة بعد انطلاق المشروع

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

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

كيف تنظّم Knova عملها لتفادي كل منها

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

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

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