قبل أن توقّع عقد أودو: أنت لا تشتري نظاماً، أنت تعيد تصميم شركتك

تقول مؤسسة غارتنر إن أكثر من 70% من مشاريع تطبيق أنظمة تخطيط الموارد (ERP) التي انطلقت حديثاً لن تصل، بحلول 2027، إلى الأهداف التي بُنيت عليها في الأصل.

رقمٌ كهذا يستحق أن يتوقّف عنده كل من يوشك على توقيع عقد تطبيق.

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

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

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

الشهادة تفتح الباب، لكنها لا تكفي

تصنيف الشريك لدى Odoo مؤشّر مفيد للتصفية الأولى؛ يخبرك عن اعتماده وخبرته ومراجعه وحضوره في السوق. لكنه لا يجيب عن السؤال الحقيقي، السؤال الذي يهمّ صاحب القرار:

هل يفهم هذا الفريق كيف تكسب شركتي مالها فعلاً، ثم يبني النظام حول هذا الواقع — لا حول ما في الكتيّبات؟

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

الشريك قد يكون معتمَداً تماماً، ويبقى مع ذلك الخيار الخطأ لشركتك.

أول حديث ينبغي أن يكون عن عملك، لا عن التطبيقات

حين يبادرك الشريك بسؤال “أي وحدات Odoo تريد؟”، فاعلم أنه بدأ من النهاية.

السؤال الأجدر أن يُطرح أولاً: كيف يجري العمل داخل شركتك حقاً؟

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

المستندات تحكي لك كيف يُفترض أن تسير الأمور. أما من يعملون على الأرض فيُرونك كيف تسير بالفعل. والفارق بينهما هو حيث تُدفن معظم المشاريع.

النظام الجيّد لا يرقمن صورة مثالية لا وجود لها؛ بل يُظهِر مواطن الاحتكاك، ويقطع التعقيد الزائد، ويسند الناس في ما يحتاجون إنجازه فعلاً.

كل تعديل برمجي قرارٌ له كلفة على المدى الطويل

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

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

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

الشريك الذي تثق به لا يكتفي بالجواب “نعم، نستطيع بناء ذلك” — فالبناء ممكن دائماً. بل يسألك أولاً: “وهل نحتاجه أصلاً؟” ألا يكفي Odoo القياسي؟ أما يمكن تبسيط العملية بدل تعقيدها؟ وهل ستبقى هذه العملية نفسها منطقية بعد عامين؟

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

العرض التوضيحي ليس برهاناً

رأيتُ عروضاً بديعة تتهاوى لحظة اصطدامها بالتشغيل الحقيقي. العرض يُريك “الطريق الأمثل”، بينما تعيش الشركات على الاستثناءات لا على الطريق الأمثل.

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

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

اجلب أهل الميدان إلى الطاولة

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

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

أفضل الشركاء من يترجمون بين لغة البرمجيات ولغة نتائج العمل. وذلك تحديداً هو الفرق بين أن “تُشغّل نظاماً” وأن “تجعل شركتك أفضل”.

سؤال واحد قبل أن توقّع

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

فقبل أن تختار من سيطبّق Odoo لديك، اسأل سؤالاً واحداً:

هل جاء هذا الفريق ليُثبّت لي برنامجاً، أم ليساعدني على أن أدير شركتي بطريقة أنظف وأكثر قدرة على النمو؟