تحليل المتطلبات قبل تطبيق أودو: الأسئلة التي يجب أن تجيب عنها

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

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

لماذا يبدأ نجاح المشروع من تحليل المتطلبات قبل تطبيق أودو؟

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

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

من يحضر ورش العمل وكيف تُدار؟

ورشة العمل جلسة مخصصة لقسم واحد، تستغرق عادة ساعتين إلى ثلاث، ويحضرها:

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

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

واطلب من كل قسم أن يحضر معه نماذج فعلية: فاتورة، وأمر شراء، وسند استلام، وملفات الإكسل التي يعتمد عليها، والتقارير التي يرسلها للإدارة.

رسم الدورات الحالية خطوة بخطوة

الدورة هي سلسلة الخطوات من بداية العملية إلى نهايتها، مثل دورة «من الطلب إلى التحصيل» أو «من الحاجة إلى سداد المورد». لرسم كل دورة:

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

لا تحتاج برنامجًا معقدًا للرسم؛ سبورة أو ورقة كبيرة تكفي، ثم يُنقل الرسم إلى الوثيقة.

الأسئلة التي يجب أن تجيب عنها كل إدارة

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

من الاحتياجات إلى قائمة متطلبات مرتّبة

بعد الورش ستجد لديك عشرات الطلبات، وليست كلها بنفس الأهمية. صنّف كل متطلب في واحدة من ثلاث درجات:

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

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

والمتطلب الجيد يُكتب بحيث يمكن اختباره لاحقًا. قارن بين صيغتين:

• صيغة ضعيفة: «نريد التحكم في المشتريات».
• صيغة جيدة: «أي أمر شراء يتجاوز حدًا محددًا يحتاج اعتماد المدير المالي قبل إرساله للمورد، ويظهر للمدير في قائمة طلبات تنتظر اعتماده».

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

ماذا تحتوي وثيقة المتطلبات؟

1. النطاق: التطبيقات المشمولة في المرحلة الأولى، وما هو مؤجَّل صراحة.
2. الهيكل التنظيمي: الشركات والفروع والمستودعات والأقسام.
3. الدورات الحالية مرسومة، مع نقاط الألم في كل منها.
4. قائمة المتطلبات مرقّمة، وكل متطلب بقسمه ودرجة أولويته.
5. التقارير والنماذج المطبوعة المطلوبة، مع نسخة من الشكل الحالي لكل منها.
6. التكاملات: أجهزة البصمة، أو بوابة الدفع، أو المتجر الإلكتروني، أو أي نظام آخر.
7. البيانات المطلوب ترحيلها ومصدر كل منها ومن المسؤول عنها.
8. الصلاحيات: من يرى ماذا، ومن يعتمد ماذا.
9. القرارات المعلّقة ومن يحسم كل قرار وموعده.

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

أخطاء شائعة في تحليل المتطلبات

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

الخلاصة

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

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