لماذا تفشل عمليات تطبيق Odoo، ونادراً ما يكون السبب هو البرنامج

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

نادراً ما تكون المنصة هي السبب

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

الأنماط السبعة الكامنة وراء كل مشروع فاشل تقريباً

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

1. غياب الراعي التنفيذي

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

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

2. نطاق غير واضح وتوسّع غير منضبط فيه

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

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

3. بيانات غير منقّاة تُرحَّل بالجملة

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

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

4. اختزال التدريب في يوم واحد

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

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

5. غياب مسؤول محدّد لكل عملية

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

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

6. تخصيص النظام لمجاراة عملية معيبة

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

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

7. الإطلاق الفعلي في موعد يصادف إقفال الشهر أو التدقيق

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

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

لماذا يتأخر ظهور الضرر كل هذا الوقت

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

ما الذي يمنع ذلك فعلاً

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

الأسئلة الشائعة

قراءات ذات صلة

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