لماذا تفشل مشاريع ERP وCRM — والقرارات الخمسة التي تمنع ذلك
مشاريع أنظمة المؤسسات لا تفشل تقريبًا لأن البرمجية لم تستطع أداء المهمة. تفشل لأن أحدًا ذا صلاحية لم يملك النتيجة، أو لأن العملية لم يُتفق عليها قبل أتمتتها، أو لأن المؤسسة طُلب منها استيعاب التغيير كله في يوم أحد واحد. وكل واحد من هذه يُقرَّر في الشهر الأول، قبل أن يكتب أحد سطر شيفرة — وهذا خبر جيد، لأنه يعني أن النتيجة في يدك إلى حد بعيد.
أبرز النقاط
- التقنية نادرًا ما تكون السبب. الملكية، ووضوح العملية، وجودة البيانات، وترتيب الإطلاق هي ما يحسم النتيجة.
- عيّن مالكًا داخليًا واحدًا بصلاحية حقيقية. اللجنة التوجيهية ليست مالكًا.
- اتفق على العملية قبل أتمتتها. أتمتة عملية معطوبة تنتج نتائج معطوبة بسرعة أكبر فقط.
- رحّل بيانات أقل مما تظن. نقل كل شيء يستورد سنوات من الفوضى المتراكمة إلى نظام نظيف.
- الفشل صامت عادةً: يُطلق النظام، ويستمر الناس في استخدام الجدول القديم، ولا يقول أحد ذلك.
كيف يبدو الفشل فعلًا
الانهيارات الدرامية تصنع دراسات حالة جيدة لكنها نادرة. الفشل الشائع صامت. يُطلق النظام في موعده تقريبًا. ويتبنّاه قسمان. ويحتفظ قسم ثالث بجدوله «مؤقتًا حتى تستقر الأمور». وبعد ستة أشهر يظل الجدول هو المرجع، وتُعرف التقارير المستخرجة من النظام الجديد بأنها خاطئة، ولا يقول أحد ذلك بصوت عالٍ لأن مالًا كثيرًا أُنفق.
لا يُعلن رسميًا عن أي فشل. المؤسسة ببساطة صارت تصون نظامين ولا تثق بأي منهما. وهذه هي النتيجة التي صُممت القرارات الخمسة أدناه لمنعها.
القرار الأول: عيّن مالكًا داخليًا واحدًا بصلاحية حقيقية
أقوى مؤشر منفرد على النجاح هو وجود شخص واحد محدد بالاسم داخل مؤسستك يملك النتيجة، وله صلاحية حسم الخلافات بين الأقسام، ومُنح وقتًا بأن أُزيل شيء آخر من عبء عمله.
اللجنة التوجيهية ليست مالكًا. اللجان جيدة في الاعتماد وسيئة في الحسم، ومشاريع المؤسسات تولّد تدفقًا مستمرًا من القرارات الصغيرة التي يجب حسمها خلال أيام. وحين يختلف قسم المبيعات مع المالية حول ما يُحتسب طلبًا مؤكدًا، لا بد أن يختار أحد. وإن انتظر ذلك القرار اجتماعًا شهريًا، فالجدول الزمني قد ضاع أصلًا.
ونمط الفشل هنا هو تعيين مالك دون تفريغ وقته. فمن يؤدي هذا فوق وظيفة كاملة سيؤديه خارج الدوام، وبشكل رديء، وسيتحول إلى عنق الزجاجة الذي عُيّن ليمنعه.
القرار الثاني: اتفق على العملية قبل أن تؤتمتها
البرمجيات تفرض الدقة. الجدول يحتمل أن يستخدم ثلاثة أشخاص تعريفات مختلفة قليلًا لكلمة «مُسلَّم»؛ والنظام لا يحتمل ذلك. وهذه الدقة هي الفائدة الأساسية من هذه المشاريع ومصدر ألمها الأساسي.
كل مؤسسة تكتشف أثناء التنفيذ أن عمليتها الموثّقة تختلف عن عمليتها الفعلية، وأن قسمين ظلا يعملان بنسختين متعارضتين من الحقيقة لسنوات بهدوء. هذا الاكتشاف قيّم. لكن حدوثه أثناء اختبار قبول المستخدم قبل ثلاثة أسابيع من الإطلاق ليس كذلك.
ارسم العملية الحقيقية أولًا — التي يتبعها الناس فعلًا لا التي في الدليل. ثم قرّر ما ينبغي أن تكون عليه. فأتمتة عملية لم تتفق عليها إنما توزّع الخلاف بسرعة أكبر وبسلطة أكبر.
القرار الثالث: رحّل بيانات أقل مما تظن
الغريزة تدفعك لنقل كل شيء. قاومها.
كل سجل ترحّله يجب فهمه وتنظيفه وربطه والتحقق منه. والبيانات التاريخية بصيغ غير متسقة وعملاء مكررين وأكواد منتجات مهجورة ستستهلك من مشروعك أكثر مما توقع أحد، وستستورد سنوات من الفوضى المتراكمة إلى نظام قيمته كلها في كونه جديرًا بالثقة.
خيار افتراضي أفضل: رحّل المعاملات المفتوحة، والبيانات الرئيسية الحالية، والحد الأدنى من التاريخ الذي تُلزمك به القوانين أو العمليات. وأرشف الباقي في مكان قابل للقراءة. ونادرًا ما ستندم على ذلك، بينما ستندم على العكس خلال أسابيع.
القرار الرابع: أطلق على مراحل
تبديل كل شيء دفعة واحدة يركّز كل المجهول في عطلة أسبوع واحدة. وإن حدث خطأ فلن تعرف أي تغيير سبّبه، ولن يكون لديك بديل عامل لأن النظام القديم أُطفئ يوم الجمعة.
الإطلاق المرحلي — قسم واحد، أو فرع واحد، أو وحدة واحدة في كل مرة — يكلّف جهدًا أكبر بقليل ومخاطرة أقل بكثير. ويمنحك مجتمع مستخدمين حقيقيًا يكتشف مشكلات حقيقية بينما تظل المخاطر محتملة، ويتيح للمجموعة الثانية التعلم من الأولى.
التحوّل الشامل دفعة واحدة قد يكون حتميًا أحيانًا، عادةً بسبب حدود السنة المالية أو انتهاء ترخيص. وحين يكون مفروضًا فعلًا، خصّص ميزانية لفترة تشغيل متوازٍ واقبل عبء الإدخال المزدوج لأسابيع. أما حين يكون مجرد خيار مريح، فلا.
القرار الخامس: خصّص ميزانية للانخفاض
الإنتاجية تنخفض بعد الإطلاق. دائمًا. فالموظفون الخبراء يتحولون إلى مبتدئين بطيئين داخل نظام غير مألوف بينما تبقى أهدافهم كما هي.
المشاريع التي تخطط لذلك تتعافى خلال أسابيع. أما التي تتظاهر بغير ذلك فتحصل على مشكلة ثانية أسوأ: يعود الناس إلى الطريقة القديمة تحت الضغط، بشكل غير رسمي أولًا ثم بشكل دائم، ولا يحدث التبني أبدًا. وقد وجدت دراسة Panorama Consulting لعام 2026 حول أنظمة ERP أن أكثر من ربع المؤسسات تجاوزت ميزانيات مشاريعها، وأن الاحتياجات التقنية غير المخطط لها تصدّرت الأسباب — ونمط التخطيط المتفائل ذاته يظهر في الجانب البشري من الجدول الزمني.
خطّط لإنتاجية منخفضة لفترة محددة. وأعلن ذلك، حتى لا يضطر أحد لإخفائه. وضع الدعم قريبًا جسديًا من مستخدمي النظام في الأسابيع الأولى.
إن كان مشروعك ينحرف بالفعل
معظم المشاريع المتعثرة تُظهر الأعراض الثلاثة نفسها: تأجيل موعد الإطلاق مرتين دون تغيير النطاق، وقائمة طلبات تغيير أطول من المواصفات الأصلية، وبدء المستخدمين بقول «سنستمر بالطريقة القديمة في الوقت الحالي».
والتعافي غير مريح لكنه بسيط. أوقف إضافة النطاق تمامًا. واختر مسار العمل الواحد الذي سيحقق أكبر قيمة بذاته وأنجزه فعليًا وحقّق تبنّيه، ولو انتظر كل ما عداه. وأعد ضبط خط الأساس للخطة بصدق بدل الدفاع عن الموعد الأصلي. فالمشروع الذي يسلّم مسار عمل واحدًا بجودة قابل للإنقاذ؛ والمشروع الذي يسلّم ستة مسارات بنسبة ثمانين بالمئة ليس كذلك، لأن ثمانين بالمئة من عملية عمل تساوي صفر بالمئة منها.
أسئلة شائعة
هل الأفضل أن نفشل سريعًا ونبدأ من جديد؟ نادرًا. فإعادة البدء تعيد إنتاج الظروف التنظيمية نفسها ببرمجية جديدة. أصلح الملكية والعملية أولًا — فإن كانتا السبب، ستكلفك البداية الجديدة الضعف دون إصلاحهما.
كم من التدريب يكفي؟ ما يكفي ليتمكن الناس من إنجاز مهامهم اليومية دون سؤال. والتدريب المخصص لكل دور أفضل من تدريب عام على النظام، والتدريب القريب من موعد الإطلاق أفضل من تدريب يُقدَّم قبل ثلاثة أشهر ثم يُنسى.
هل نوظّف مدير مشروع متفرغًا؟ إن امتد المشروع لأكثر من قسمين، نعم. لكن مدير المشروع ليس بديلًا عن مالك داخلي بصلاحية — فهو ينسّق العمل، ولا يستطيع حسم خلاف بين مدير مبيعاتك ومدير ماليتك.
هل اختيار مورّد أكبر يقلّل المخاطر؟ يغيّر المخاطر لا يزيلها. المورّدون الأكبر يجلبون نضجًا وهيكلة، ويجلبون أيضًا عمليات معيارية قد يُطلب منك تبنيها. والقرارات الواردة في هذا المقال تنطبق مهما كان حجم المورّد.
الخطوة التالية
قبل بدء مشروع المؤسسة التالي، أجب عن ثلاثة أسئلة كتابةً: من يملك هذا وما الذي أُزيل عن كاهله، وأي عملية سنتفق عليها قبل الأتمتة، وما أقل قدر من البيانات يمكننا الاكتفاء بترحيله. فإن كانت لهذه الثلاثة إجابات واضحة، تكون قد أغلقت معظم أنماط الفشل الشائعة.
تخطط لمشروع نظام مؤسسي أو تحاول إنقاذ واحد؟ اطلب مكالمة مع ZAWAT — نبني ونربط أنظمة الأعمال لشركات في عُمان ودول الخليج، ونفضّل أن نخبرك بالأمور المزعجة مبكرًا. وإن كنت ما تزال تختار المقاربة، فابدأ من أتبني نظام ERP أم تشتريه.