إعداد أم تخصيص: قرار أودو الذي يحدّد سنواتك الخمس القادمة

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

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

الشركتان اشترتا البرنامج نفسه.

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

وإن كنت في مرحلة أبكر من هذه، فـما يجيده أودو وما لا يجيده في الإمارات هو الصورة الأوسع، وهذه الصفحة هي قلبها التقني.

ليست إجابتين. بل خمس.

صياغة "الإعداد مقابل التخصيص" خشنة أكثر مما ينبغي. في الواقع العملي يقع كل متطلب في واحدة من خمس خانات، وتكلفتها متباعدة، ومخاطرها مختلفة، وسلوكها عند الترقية مختلف.

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

أين يقع الخط فعلًا

القاعدة القابلة للاستعمال ليست عن الصعوبة، بل عن من يملك السلوك بعد ذلك.

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

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

ويقع Odoo Studio في منتصف غير مريح، ويُوصف روتينيًا بأنه بديل آمن للتطوير، وهذا نصف صحيح فقط.

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

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

عطل ستوديو المميّز ليس انهيارًا. هو نظام يشيخ فيه مئتا حقل مضاف ولا أحد يستطيع أن يقول أي عشرين منها مستخدم، ولا ما الذي ينكسر إن حُذف أي منها.

فلا يُحذف شيء أبدًا، ويُبنى كل تغيير لاحق فوق الترسّبات.

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

لماذا يكلّفك الكود عند كل إصدار، تحديدًا

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

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

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

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

وليس كل الكود يشيخ سواء، والفارق انضباط هندسي لا حظ:

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

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

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

---

كيف تميّز فجوة حقيقية من رفض التغيير

معظم المتطلبات التي تبدو محتاجة إلى كود لا تحتاجه. هي تحتاج من يقول بصوت مسموع إن العملية الحالية قائمة لسبب لم يعد قائمًا.

هذا تسلسل ينفع. يستغرق نحو عشر دقائق للمتطلب الواحد، وهي أعلى عشر دقائق عائدًا في المشروع كله.

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

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

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

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

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

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

الحكم ليس "تجنّب الكود". الحكم أن تنفقه حيث يختلف عملك فعلًا عن كل عمل آخر، ولا مكان سواه.

كيف تكتب المتطلب حتى لا تُختار الإجابة عنك بهدوء

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

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

اطلب تصنيفًا مكتوبًا مقابل كل متطلب، قبل العقد. صف واحد لكل متطلب، وقيمة واحدة من خمس:

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

الوثيقة التي تحمل هذا أثمن من السعر المكتوب على غلاف العرض. وهي أيضًا، بحسب خبرتنا، أكثر ما يغيب عن عروض أودو في هذا السوق.

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

اسأل السؤال المعكوس في العرض الحيّ. لا "هل يستطيع أودو فعل هذا" — فمع كود كافٍ تكون الإجابة نعم دائمًا. بل: "أرني هذا يعمل في نظام قياسي اليوم، وإن كان يحتاج بناءً فقُل ذلك الآن." وسرعة الفريق في الإجابة ودقتها هي أوضح قراءة متاحة له، وهي واحدة من الأسئلة التي تفصل شريكًا عاش القطاع عن شريك قرأ عنه.

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

واشترط أن يسكن الكود المخصص في مستودع تستطيع قراءته اليوم، مع نقل الملكية الفكرية في العقد. لا "الشيفرة عند الطلب" — بل وصول الآن.

كود موجود على خادم مورّد فقط ليس أصلًا تملكه؛ هو علاقة لا تستطيع الخروج منها.

الترتيب الذي تعمل به

التسلسل التالي ليس تفضيلًا. هو ترتيب بالتكلفة، وكل خطوة تتخطّاها تضاعف ما بعدها.

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

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

وثمة نسخة أوسع من هذا الحكم — أتشتري منتجًا أصلًا أم تكتب برنامجًا لعملية هي لك حقًا — وهي حكم آخر يستحق وقفة على حدة. والنسخة الخاصة بأودو أضيق وأقسى: داخل منتج يصدر سنويًا، كل سطر تكتبه مستأجر لا مملوك.

---

ما يفعله هذا القرار ببقية مشروعك

موقف "الإعداد أولًا" ليس تحفّظًا، وليس ادّعاءً بأن الكود المخصص سيئ. هو ملاحظة عن التراكم.

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

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

واختيار النسخة والاستضافة يقع تحت هذا كله، لأن أحد خيارات الاستضافة يغلق باب الكود المخصص تمامًا وهو لذلك أقوى ضابط حوكمة متاح — والمقايضات مبسوطة في الفرق الحقيقي بين Community وEnterprise.

وإن احتاجت فجوة حقيقية بناءً، فابنِها كما ينبغي: مضيفة، ومختبَرة، ومملوكة لك، ومكتوبة لتُنقل إلى الأمام. هكذا ينبغي أن يُسلَّم برنامج مكتوب لك خصيصًا أيًّا كانت المنصة.

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