مجلة أوبريون
«النظام معقد». «نحتاج تقريراً أفضل». «الفاتورة تأخذ وقتاً طويلاً». «نريد أن يكون مثل النظام القديم». هذه عبارات يسمعها كل فريق تنفيذ ERP. وكل واحدة منها تحمل مشكلة حقيقية، لكنها ليست متطلباً يمكن تنفيذه. فإذا نُفذت كما هي، تتحول إلى تخصيصات عشوائية تزيد التعقيد بدلاً من حله.
المهارة الحقيقية في مشاريع ERP ليست في البرمجة، بل في تحويل الشكوى إلى متطلب: وصف دقيق للحاجة، وسببها، ومن يحتاجها، وكيف نعرف أنها تحققت. في هذا المقال نقدم منهجية عملية لذلك، تصلح للمرحلة الأولى من التنفيذ وللتحسين المستمر بعد التشغيل.
لماذا لا تصلح الشكوى متطلباً؟
| الشكوى | ما ينقصها | خطر تنفيذها كما هي |
|---|---|---|
| النظام معقد | أي شاشة؟ أي خطوة؟ لأي مستخدم؟ | تبسيط عشوائي يحذف ضوابط مهمة |
| نحتاج تقريراً | لأي قرار؟ بأي تفاصيل؟ كم مرة؟ | تقرير يُبنى ولا يُستخدم |
| الفاتورة بطيئة | بطيئة في الأداء أم في الخطوات؟ | معالجة الشيء الخطأ |
| نريده مثل القديم | ما الهدف من الطريقة القديمة؟ | نسخ قيود النظام القديم |
المنهجية: خمس خطوات من الشكوى إلى المتطلب
1. اسمع الشكوى كما هي ووثّقها
لا تجادل ولا تشرح لماذا النظام صحيح. سجل الشكوى بكلمات صاحبها، ومن قالها، ودوره، والسياق. الشكوى نقطة بداية مهمة لأنها تكشف ألماً حقيقياً.
2. اطلب مثالاً حقيقياً
اسأل: «أرني آخر مرة حدث فيها ذلك». المثال الحقيقي يكشف التفاصيل: أي مستند، وأي حقول، وكم خطوة، وأين توقف المستخدم. كثير من الشكاوى العامة تتحول عند المثال إلى مشكلة محددة صغيرة.
3. ابحث عن الهدف لا عن الحل المقترح
غالباً يأتي المستخدم بحل جاهز: «نريد زراً هنا». اسأل «لماذا؟» حتى تصل إلى الهدف: «حتى لا أعيد كتابة بيانات العميل في كل فاتورة». والهدف قد يكون له حل أبسط في الإعدادات القياسية.
4. اكتب المتطلب بصيغة واضحة
صيغة بسيطة وفعالة: بصفتي [الدور]، أحتاج إلى [القدرة]، حتى [الفائدة]. ثم أضف معايير القبول: كيف نعرف أن المتطلب تحقق؟
5. صنّف المتطلب وقرر
هل يُحل بالإعدادات القياسية؟ أم بالتدريب؟ أم بتعديل في دورة العمل؟ أم يحتاج تطويراً؟ وما أولويته مقارنة بغيره؟ هذا التصنيف يمنع أن يتحول كل طلب إلى برمجة.
مثال كامل: من «الفاتورة تأخذ وقتاً طويلاً» إلى متطلب
| المرحلة | المحتوى |
|---|---|
| الشكوى | المحاسب: «إصدار الفاتورة يأخذ وقتاً طويلاً» |
| المثال | فاتورة لعميل جملة بخمسين صنفاً، يُدخل الأصناف يدوياً من أمر البيع الورقي |
| الهدف | عدم إعادة إدخال أصناف موجودة بالفعل في أمر البيع |
| المتطلب | بصفتي محاسب مبيعات، أحتاج إلى إنشاء الفاتورة من أمر البيع المعتمد مباشرة، حتى لا أعيد إدخال الأصناف والأسعار |
| معايير القبول | إنشاء الفاتورة من أمر البيع بضغطة، مع نقل الأصناف والكميات والأسعار والضرائب، وإمكانية الفوترة الجزئية |
| التصنيف | إعدادات قياسية وتدريب: إدخال أوامر البيع في النظام بدلاً من الورق |
لاحظ أن الحل لم يكن تطويراً، بل تغييراً في طريقة العمل: أمر البيع يُسجل في النظام، والفاتورة تُنشأ منه. هذا هو الفرق بين معالجة العرَض ومعالجة السبب.
أنواع الحلول بالترتيب المفضل
- استخدام ميزة موجودة: كثير من الشكاوى سببها عدم معرفة ميزة قياسية.
- إعدادات: قيم افتراضية، أو قوائم أسعار، أو صلاحيات، أو حقول إلزامية.
- دورة عمل أو إشعار: كما في بناء Workflow واضح.
- تقرير أو لوحة متابعة: مبنية على بيانات موجودة.
- تخصيص بسيط: حقل إضافي أو نموذج طباعة.
- تطوير: فقط عندما لا تكفي الخيارات السابقة، وبتوثيق واضح.
كيف تنظم المتطلبات في المشروع؟
- سجل واحد لكل المتطلبات بدلاً من رسائل متفرقة، ويمكن إدارته في النظام نفسه كمهام أو تذاكر.
- لكل متطلب صاحب من فريق العمل يعتمده.
- أولوية واضحة: ضروري للتشغيل، أو مهم، أو تحسين لاحق.
- ربط كل متطلب بالسيناريو الذي يخدمه.
- مراجعة دورية مع المستخدمين الرئيسيين.
أخطاء شائعة
- تنفيذ الحل الذي يقترحه المستخدم دون فهم الهدف.
- قبول متطلبات بلا معايير قبول، فلا يُعرف متى تنتهي.
- تحويل كل شكوى إلى تطوير مخصص.
- تجاهل الشكاوى لأنها «غير واضحة»، فتتحول إلى مقاومة.
وهذه المهارة من أقوى أدوات معالجة مقاومة التغيير، لأن الموظف يرى أن شكواه سُمعت وتحولت إلى نتيجة. وتتضمن منهجية أوبريون مرحلة تحليل منظمة على هذا الأساس. تحدث معنا.
أسئلة شائعة
ما الفرق بين الشكوى والمتطلب؟
الشكوى تعبر عن ألم عام، والمتطلب يصف حاجة محددة لدور محدد مع فائدتها ومعايير قبولها.
ما صيغة كتابة المتطلب؟
بصفتي [الدور]، أحتاج إلى [القدرة]، حتى [الفائدة]، مع معايير قبول قابلة للاختبار.
هل كل متطلب يحتاج تطويراً؟
لا، كثير منها يُحل بميزة قياسية أو إعدادات أو تدريب أو دورة عمل.
من يعتمد المتطلبات؟
المستخدم الرئيسي للقسم وصاحب القرار في المشروع، بعد تصنيفها وتحديد أولويتها.
