تبدأ خلافات كثيرة بين المؤسسة ومورّد البرمجيات بمتطلب فهمه كل طرف بطريقة مختلفة. تطلب المؤسسة نظامًا يتعامل مع الاعتمادات، فيبني المطوّر خطوة اعتماد واحدة، بينما يتضمن الإجراء الفعلي ثلاث خطوات واستثناءات حسب المبلغ والفرع. وتظهر الفجوة أثناء الاختبار، حين يصبح التعديل بطيئًا ومكلفًا، ويختلف الطرفان على ما اتُّفق عليه.
تنفّذ Kemlat تحليل الأعمال قبل أن يبدأ أحد بالبناء أو الشراء. نتحدث مع من يؤدون العمل، ونوثّق ما يجب أن يفعله النظام لكل دور، ونتفق على ما يدخل في الإصدار الأول، ونكتب معايير قبول تبين كيف سيُتحقق من كل متطلب. والنتيجة وثيقة متطلبات أعمال (BRD) يستطيع فريقك والمورّد والإدارة قراءتها واعتمادها.
كيف نعمل
- 01
مقابلة من يؤدون العمل
نعقد ورش عمل ومقابلات فردية مع كل إدارة معنية، ونراجع النماذج والتقارير وشاشات الأنظمة الحالية. ونسجّل كيف يُنجز العمل اليوم، بما في ذلك الاستثناءات التي تُعالج يدويًا.
- 02
تحديد الأدوار والمتطلبات
نحدد كل دور من أدوار المستخدمين، ونكتب كل متطلب بلغة واضحة: من يحتاج إلى فعل ماذا، ولماذا. وتُوثَّق القواعد مثل حدود الاعتماد والحسابات والتنبيهات بأمثلة توضيحية.
- 03
الاتفاق على الأولويات
نصنّف المتطلبات إلى أساسية ومهمة ومؤجلة، ونحسم التعارض بين الإدارات في جلسة مشتركة. وإذا بقي الخلاف، يقرر المسؤول الذي يتبنى المشروع من الإدارة.
- 04
تحديد النطاق ومعايير القبول
نكتب لكل متطلب داخل النطاق معايير قبول، أي الفحوص المحددة التي تثبت أنه يعمل. وتُدرج الافتراضات والأسئلة المفتوحة والبنود خارج النطاق في قوائم منفصلة.
- 05
المراجعة والاعتماد
نراجع الوثيقة مع المسؤولين في الإدارات المعنية، ومع المورّد التقني إن كان قد اختير. ثم تُعالج الملاحظات وتُعتمد الوثيقة مرجعًا للبناء أو للمناقصة.
ما الذي تستلمه
متطلبات الأعمال وأدوار المستخدمين
قائمة منظمة بالمتطلبات مجمّعة حسب الإجراء والدور، مع قواعد العمل والأمثلة.
خرائط الإجراءات الحالية والمستهدفة
رسوم مبسطة تبين كيف يسير العمل اليوم، وكيف يجب أن يسير في النظام الجديد.
نطاق المنتج وأولوياته
محتوى الإصدار الأول وما يأتي بعده، مع سبب كل أولوية.
معايير القبول
شروط قابلة للاختبار لكل متطلب، يستخدمها فريقك لقبول النظام المُسلَّم أو رفضه.
الافتراضات والأسئلة المفتوحة
ما يعتمد عليه النطاق وما يحتاج إلى قرار، ولكل بند مسؤول.
ما الذي يتغير لديك
- يعتمد فريقك والموردون على الوصف المكتوب نفسه في تقديم العروض والبناء والاختبار.
- تقل الخلافات أثناء الاختبار، لأن معنى اكتمال كل متطلب حُدد مسبقًا.
- تتفق الإدارات على أولوياتها قبل الالتزام بأي إنفاق.
- تُكتب المعرفة التي كانت لدى قلة من الأشخاص وتصبح متاحة للجميع.
موقع الخدمة في منهجية KEMLAT
النطاق: تنتج هذه الخدمة المتطلبات والنطاق، لا النظام نفسه. ويمكن استخدام الوثيقة المعتمدة لتكليف Kemlat أو مورّد آخر، أو لطرح مناقصة رسمية.
أسئلة يطرحها العملاء
هل تحتاج المشاريع الكبيرة فقط إلى BRD؟
لا. حتى النظام الصغير يستفيد من وثيقة قصيرة تحدد الأدوار والقواعد ومعايير القبول. ونضبط عمق الوثيقة بحسب حجم المشروع ومخاطره.
من يجب أن يشارك من جهتنا؟
مسؤول من الإدارة يتبنى المشروع ويستطيع حسم الأولويات، وأشخاص من كل إدارة يعرفون العمل اليومي واستثناءاته. ويُطلب وقتهم أساسًا في المقابلات وجلسات المراجعة.
هل يمكن كتابة المتطلبات لنظام اخترناه مسبقًا؟
نعم. وفي هذه الحالة نوضح أيضًا أين يلبي المنتج المختار المتطلب كما هو، وأين يحتاج إلى إعداد، وأين لا يناسب.
بأي صيغة تكون الوثيقة؟
وثيقة Word أو PDF مع رسوم للإجراءات، وقائمة متطلبات في Excel إذا فضّل المورّد متابعة كل بند على حدة. ويمكن كتابتها بالعربية أو الإنجليزية أو باللغتين.
خدمات مرتبطة
كل الخدماتابدأ بمحادثة
أخبرنا أين تقف اليوم، وسنقترح عليك الخطوة الأولى المناسبة دون أي التزام.