ما تخصّصه الشركات الإماراتية فعلاً في Odoo — تحليل لـ 140 وحدة في 10 عمليات تطبيق

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

أبرز النتائج

1. معظم الوحدات كانت عملاً هندسياً لا مجرّد تثبيت. فقد بُنيت 111 وحدة من أصل 140 (79%) داخلياً أو عُدّلت، ولم يُترك على حاله سوى 29 وحدة.
2. المحاسبة هي أكثر المجالات تخصيصاً. توسّع 48 وحدة من أصل 140 تطبيق المحاسبة account في Odoo، أي 34%، وهذا أكثر من ضعف أقرب التطبيقات إليه.
3. خُمس التخصيص موجود للإجابة عن الأسئلة. التقارير ولوحات المعلومات: 29 وحدة، أي 20%.
4. الرواتب هي أقل المجالات تخصيصاً. الموارد البشرية والرواتب: 3 وحدات، أي 2%، وهو أصغر المحاور.

لماذا أجريتُ هذا البحث

اسأل مورّد البرنامج عن حجم التخصيص الذي يحتاجه نظام تخطيط موارد المؤسسات (ERP) فستسمع جواباً، واسأل شريك التطبيق فستسمع نقيضه، وكلاهما تسويق. أما الدليل فكان موجوداً أصلاً في عشرة مستودعات git، والشيفرة البرمجية ليس لها موقف تجاري تدافع عنه: فملف manifest يسجّل التطبيق الذي توسّعه الوحدة، وسجل git يسجّل مقدار العمل الذي جرى على أي تطبيق من جهة خارجية بعد تثبيته.

كيف استُخلصت البيانات

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

• مبنية من الصفر (63 وحدة): كُتبت داخلياً، وتُعرف من حقل المؤلف في ملف manifest ومن اصطلاح التسمية المعتمد لدينا.
• معدَّلة داخلياً (48 وحدة): تطبيق من جهة خارجية مسّه أكثر من إيداع (commit) واحد في سجل git، أي عمل لاحق لاستيراده، يُقرأ من سجل الإيداعات ولا يُكتفى بادّعائه.
• مثبّتة كما هي (29 وحدة): موجودة دون أي إيداع لاحق للاستيراد.

تُستمد أعداد الوحدات التي توسّع التطبيقات من قائمة depends في ملف manifest الخاص بكل وحدة، وأعداد المحاور من تصنيف بالكلمات المفتاحية لاسم الوحدة واسمها في ملف manifest وملخّصها. والوحدة الواحدة تعتمد عادةً على عدة تطبيقات وقد تحمل أكثر من محور (فتقرير نقاط البيع، مثلاً، يُحتسب في المحورين معاً: نقاط البيع والتقارير)، ولذلك لا يبلغ مجموع نسب التطبيقات ولا مجموع نسب المحاور 100%. وكل نسبة في هذه الصفحة هي حصة من الوحدات نفسها البالغ عددها 140، وليست حصة من الفئة التي ترد فيها. ولا يُذكر اسم أي عميل: فعمليات التطبيق مرموز إليها من impl-A إلى impl-J، ولا يُحدَّد أي تطبيق من جهة خارجية ولا أي مورّد.

حدود هذه الدراسة

هذه دراسة صغيرة، والأفضل أن تعرف حدودها من أن تكتشفها بنفسك:

• حجم العيّنة (n = 10). تكشف عشر عمليات تطبيق عن ملامح نمط، لكنها لا تثبت توزيعاً إحصائياً.
• العيّنة مأخوذة من محفظة مشاريع شركة استشارية واحدة، وقد تشكّلت بحسب العملاء الذين تعاقدوا معنا لا بسحب عيّنة من السوق. وهي ليست عيّنة ممثّلة لسوق Odoo في الإمارات.
• عدد الوحدات مؤشر تقريبي للجهد وليس مقياساً له. فقد تكون الوحدة الواحدة تعديلاً على حقلين، وقد تستغرق أخرى ربع سنة من العمل الهندسي. ولا شيء هنا يقدّر التكلفة أو الوقت.
• العيّنة غير متوازنة. فقد تراوح عدد الوحدات في عملية التطبيق الواحدة بين 1 و34 وحدة، بوسيط قدره 8، ولذلك تتحكّم في الإجماليات قلّة من المشاريع الكبيرة.
• «المعدَّلة» تعريف آلي. فالتطبيق الذي جرت تهيئته بكثافة، عبر Odoo Studio بدلاً من التطوير المخصّص مثلاً، دون أن تُعدَّل شيفرته قط، يُحتسب مثبّتاً كما هو، لأن git لا يرى التهيئة.
• هذا عمل فريق. فأنا رئيس المشاريع: هذه عمليات تطبيق توليتُ قيادتها، وكتب شيفرتها فريق من المهندسين لا أنا وحدي.

النتيجة الأولى: دفتر الأستاذ يستوعب أكبر قدر من التخصيص

تُعلن 48 وحدة من أصل 140، أي 34%، اعتمادها على account، وهو تطبيق المحاسبة في Odoo، وهذا أكثر من ضعف أقرب التطبيقات إليه: point_of_sale بواقع 22 وحدة (15%).

المصدر: قوائم depends المستخرجة من ملفات manifest الخاصة بالوحدات الـ 140. وتعتمد الوحدة عادةً على عدة تطبيقات.

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

وهناك بندان آخران يستحقان وقفة ثانية. فبلوغ point_of_sale 22 وحدة رقم مرتفع لتطبيق لا يشغّله أصلاً سوى بعض هذه الشركات، لكن الشركة التي تشغّل نقطة بيع تخصّصها تخصيصاً كثيفاً، وهو النمط الذي يقف خلف عملنا في نقاط البيع لقطاع التجزئة في الإمارات. أما mail بواقع 17 وحدة (12%) فلا يعني المراسلة، وإنما الموافقات والإشعارات.

النتيجة الثانية: خُمس التخصيص كله موجود للإجابة عن الأسئلة

وإذا نظرنا بحسب المحور لا بحسب التطبيق، تتصدّر المحاسبة والمالية بواقع 36 وحدة (25%). أما المحور الذي يليها فهو الأكثر إثارة للاهتمام: التقارير ولوحات المعلومات، بواقع 29 وحدة، أي 20%.

المصدر: تصنيف بالكلمات المفتاحية لاسم الوحدة واسمها في ملف manifest وملخّصها. والمحاور متداخلة.

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

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

النتيجة الثالثة: معظم الوحدات المشتراة احتاجت إلى عمل بعد تثبيتها

48 وحدة من أصل 140 كانت تطبيقات من جهات خارجية اضطرّ فريقنا إلى تعديلها بعد تثبيتها، إذ مسّ كلاً منها أكثر من إيداع واحد في سجل الإيداعات. ولم يمرّ دون مساس سوى 29 وحدة، أي أن عدد الوحدات المشتراة التي جرى تعديلها في هذه المستودعات فاق عدد الوحدات التي بقيت على حالها. أما الوحدات الثلاث الأكثر اشتغالاً فحملت 41 و23 و20 إيداعاً، وحملت كل واحدة من الوحدتين التاليتين 13 إيداعاً.

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

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

النتيجة الرابعة: الرواتب وغيابها اللافت

الموارد البشرية والرواتب هي أصغر المحاور: 3 وحدات، أي 2%، وهي الأخيرة بين المحاور العشرة. وكنت أتوقع رقماً أكبر، فالرواتب في الإمارات ترتبط بالتزامات محلية حقيقية، ويطرح العملاء بشأنها أسئلة يشوبها القلق.

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

ما يعنيه هذا إذا كنت تشتري Odoo

• ضع ميزانية دفتر الأستاذ أولاً. فقد تصدّرت المحاسبة بحسب التطبيق (48 وحدة) وبحسب المحور (36 وحدة)، وهذا هو الموضع الذي تتركّز فيه عادةً تكلفة التطبيق في الإمارات.
• اسأل عمّا تعنيه «التقارير» قبل أن توقّع. فقد كان خُمس العمل هنا تقارير، وعبارة «التقارير القياسية» تتحوّل غالباً إلى طلب تغيير لاحقاً.
• سعّر التطبيقات الخارجية بوصفها مكوّنات. فقد احتاجت 48 وحدة منها إلى عمل بعد شرائها، وحملت الوحدة الأكثر اشتغالاً عليها 41 إيداعاً. واسأل من صاحب المسؤولية عن النسخة المعدَّلة عند الترقية.
• توقّع أن يكون المشروع الصغير صغيراً فعلاً. فقد تراوحت المشاريع هنا بين 1 و34 وحدة، بوسيط قدره 8، أي أن المشروع المعتاد يضم أقل من 10 وحدات.
• لا تعدّ التخصيص دليل فشل. فبناء 111 وحدة من أصل 140 أو تعديلها هو ما وُجدت المنصّات من أجله، والسؤال هو: هل تستحق كل وحدة كلفة صيانتها؟

الاستشهاد بهذا البحث

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