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