كيفية جمع متطلبات نظام الموافقات الإلكترونية
جمع متطلبات نظام الموافقات يعني توثيق ما يحتاجه كل إجراء فعلًا قبل شراء أي أداة: من يقدّم الطلب، ما بياناته، من يعتمده وبأي ترتيب وعند أي حد مالي، وما الاستثناءات. تُجمع هذه المتطلبات عبر مقابلات منظّمة مع أصحاب المصلحة، وتُوثَّق في قائمة واضحة تفصل الوظيفي عن غير الوظيفي، فيصبح البناء تنفيذًا لقرار محسوم لا تجريبًا.
لماذا تفشل المشاريع بلا متطلبات
أكثر أسباب فشل مشاريع الموافقات ليس ضعف النظام، بل بناء الإجراء الخطأ بإتقان. تُهيَّأ المسارات بناءً على افتراضات، ثم يُكتشف بعد الإطلاق أن الحد المالي مختلف، أو أن هناك معتمدًا رابعًا نُسي، أو أن قسمًا كاملًا له استثناء لم يُسأل عنه أحد.
تكلفة الخطأ ترتفع مع تأخّر اكتشافه. متطلب مفقود في جلسة المقابلة يُصلَح بدقائق؛ نفسه بعد الإطلاق يعني إعادة تصميم المسار وإرباك الموظفين. جمع المتطلبات ليس بيروقراطية — إنه أرخص مرحلة لاكتشاف الأخطاء في المشروع كله.
المتطلب الذي يُقال في اجتماع ولا يُدوَّن يُنسى أو يُفهم على وجهين. اكتب كل متطلب بجملة قابلة للاختبار: «طلب الشراء فوق 50,000 ريال يمرّ بالمدير المالي» — لا «الطلبات الكبيرة تحتاج اعتمادًا أعلى».
من تقابل ولماذا
المتطلبات موزّعة على أشخاص مختلفين، ولكل منهم زاوية لا يراها غيره. مقابلة طرف واحد تعطيك نصف الصورة:
- من يقدّم الطلب: يعرف البيانات الحقيقية والحقول التي تُربكه اليوم وأسباب تكرار الرفض.
- من يعتمد الطلب: يعرف ما يحتاجه ليقرّر، والمعلومات الناقصة التي تجعله يعيد الطلب.
- مالك الإجراء: يعرف القواعد والحدود المالية والاستثناءات غير المكتوبة في أي مكان.
- المالية والأنظمة: يعرفان القيود: مراكز التكلفة، الربط بالموارد البشرية، متطلبات الأرشفة.
رسم الإجراء الحالي مع هؤلاء قبل المقابلات يوفّر وقتًا كبيرًا؛ ابدأ بـرسم الإجراءات الحالية قبل أتمتتها ليكون النقاش أمام صورة واحدة يراها الجميع بدل أوصاف متضاربة.
انتبه إلى تعارض المصالح الطبيعي بين هذه الأطراف: من يقدّم الطلب يريد نموذجًا قصيرًا، ومن يعتمده يريد بيانات أوفى ليقرّر بلا أسئلة. مهمتك ليست إرضاء طرف على حساب آخر، بل الوصول إلى الحد الأدنى من الحقول الذي يكفي المعتمد دون أن يُرهق مقدّم الطلب. هذا التوازن لا يُكتشف إلا حين تسمع الطرفين معًا، لا أحدهما.
كيف تدير المقابلة
المقابلة العشوائية تنتج متطلبات ناقصة. اتبع ترتيبًا ثابتًا يكشف الإجراء كاملًا بما فيه ما لا يقوله الناس تلقائيًا:
- اطلب أن يصف الشخص آخر طلب مرّ به فعلًا، بالأسماء والتواريخ، لا الإجراء «النظري».
- اسأل عند كل خطوة: من الذي يفعلها؟ ما البيانات التي يحتاجها؟ كم تستغرق عادة؟
- اسأل عن الاستثناءات صراحة: ماذا يحدث لو غاب المعتمد؟ لو تجاوز المبلغ الحد؟ لو رُفض الطلب؟
- اسأل عن الألم: أين يتعطّل الطلب غالبًا؟ ما أكثر سبب لإعادته؟ ماذا يتمنى لو تغيّر؟
- أعد صياغة ما فهمته بصوت مسموع، ودوّن موافقته أو تصحيحه قبل الانتقال.
الناس يصفون الحالة المثالية تلقائيًا، والأخطاء تسكن في الاستثناءات. جملة «وماذا يحدث لو…» هي أثمن سؤال في المقابلة، لأنها تكشف التفويض عند الغياب، وتجاوز الحدود، والمسارات البديلة التي لا يذكرها أحد حتى تُسأل عنها مباشرة.
قائمة المتطلبات
لكل إجراء، اجمع الإجابات في قائمة موحّدة. هذه العناصر السبعة تغطّي معظم ما ستحتاجه في البناء:
- المُطلِق: من يبدأ الطلب، وهل يقدّمه عن نفسه أم نيابة عن غيره.
- الحقول: بيانات النموذج، الإلزامي منها والاختياري، والمرفقات المطلوبة.
- المسار: ترتيب المعتمدين، ونقاط التفرّع حسب المبلغ أو النوع أو الإدارة.
- الحدود: القيم المالية التي تغيّر المسار، ومهلة كل خطوة قبل التصعيد.
- الصلاحيات: من يرى الطلب، ومن يعتمد، ومن ينوب عند الغياب.
- التكاملات: الأنظمة التي يقرأ منها أو يكتب إليها الطلب.
- المخرجات: ما يحدث بعد الاعتماد الأخير: إشعار، أرشفة، تحديث نظام آخر.
حقول النموذج تحديدًا تستحق عناية؛ الحقل الزائد يُتعب المستخدم والناقص يعطّل المعتمد. راجع مبادئ تصميم النماذج الإلكترونية السهلة قبل تثبيت قائمة الحقول النهائية.
الوظيفي وغير الوظيفي
المتطلبات نوعان، وإهمال أحدهما يورّط المشروع لاحقًا. الوظيفي يجيب «ماذا يفعل النظام»، وغير الوظيفي يجيب «كيف يجب أن يكون».
| البُعد | متطلب وظيفي | متطلب غير وظيفي |
|---|---|---|
| المثال | يوجّه الطلب فوق 50 ألفًا للمدير المالي | يفتح الطلب خلال ثانيتين على الجوال |
| السؤال | ماذا يفعل النظام؟ | كيف يؤدّي ما يفعله؟ |
| أمثلة أخرى | تفويض، تصعيد، إشعار، أرشفة | الأداء، الأمان، سهولة الاستخدام، السجل |
الخطأ الشائع التركيز على الوظيفي وحده، فيخرج نظام يفعل كل شيء لكنه بطيء أو معقّد فيُهجَر. اسأل مبكرًا عن غير الوظيفي: من أين سيُستخدم، على أي جهاز، ومن يجب ألّا يرى الطلب أصلًا.
من المتطلبات غير الوظيفية التي تُنسى دائمًا سرّية البيانات. طلب مثل مكافأة موظف أو تقييم أداء لا يجوز أن يراه غير أطرافه، حتى لو كان مدير النظام نفسه. اسأل صراحة عن كل نوع طلب: من يجب أن يُحجب عنه؟ وهل سجل التدقيق قابل للتعديل من أحد؟ توثيق هذه القيود مبكرًا يجنّبك إعادة بناء الصلاحيات بعد أول شكوى.
مدخلات مصفوفة الصلاحيات
قلب متطلبات أي نظام موافقات هو الإجابة عن سؤال واحد: من يعتمد ماذا، وعند أي حد؟ هذه الإجابة تُوثَّق في مصفوفة الصلاحيات، وجمع مدخلاتها أثناء المقابلات يوفّر أطول تأخير في المشروع.
- لكل نوع طلب، اكتب المستويات المالية التي تغيّر المعتمد المطلوب.
- لكل مستوى، حدّد المعتمد الأصيل، وبديله عند الغياب، وحد صلاحيته الأعلى.
- وثّق حالات التجاوز: من يملك اعتماد ما يفوق الحد الطبيعي، وبأي مبرر.
- راجع المصفوفة مع المالية والإدارة العليا معًا لحسم أي تعارض قبل البناء.
انتبه إلى الفرق بين الصلاحية المرتبطة بالشخص والصلاحية المرتبطة بالمنصب. توثيق «المدير المالي يعتمد» أمتن من «الأستاذ خالد يعتمد»، لأن الأشخاص يتغيّرون والمناصب تبقى. اربط كل مستوى في المصفوفة بالمنصب، ثم عيّن الشخص الحالي له، فيصبح تغيّر الموظفين مجرد تحديث اسم لا إعادة تصميم للمسار كله.
بناء المصفوفة علم قائم بذاته يستحق التفصيل في مصفوفة الصلاحيات وكيف تبنيها، ونتيجتها المباشرة هي مدخل تصميم المسار كما في تصميم مسار الاعتماد خطوة بخطوة. حسمها مبكرًا يعني بناءً بلا انتظار.
مثال تطبيقي: جهة تعليمية
إدارة مدارس أهلية أرادت أتمتة اعتماد الأنشطة الطلابية. جمع الفريق المتطلبات في ثلاث مقابلات: منسّق نشاط، مدير مدرسة، والمالية. المقابلات كشفت متطلبًا لم يكن في الذهن: النشاط الذي تتجاوز ميزانيته حدًا معيّنًا يحتاج رصدًا ماليًا مسبقًا قبل الاعتماد النهائي. المسار الناتج:
لولا سؤال «وماذا يحدث لو تجاوزت الميزانية الحد؟» لبُني مسار ناقص يُعتمد فيه النشاط ثم تُفاجأ المالية بالتكلفة. المتطلب المكتشف في المقابلة صار خطوة في المسار قبل أن يُشغّل أي شيء — وهذا بالضبط الفرق بين بناء يستند إلى متطلبات وبناء يستند إلى افتراضات.
الأسئلة الشائعة
كم مقابلة أحتاج لجمع متطلبات إجراء واحد؟
غالبًا من ثلاث إلى خمس مقابلات قصيرة تكفي لإجراء متوسط: من يقدّم الطلب، من يعتمده، مالك الإجراء، وطرف من المالية أو الأنظمة. الأهم ليس العدد بل التنوّع؛ مقابلة أربعة أشخاص بزوايا مختلفة أنفع من مقابلة عشرة يكرّرون الزاوية نفسها. توقّف حين تتوقف المقابلات عن كشف متطلبات جديدة.
ما الفرق بين المتطلب الوظيفي وغير الوظيفي؟
الوظيفي يصف ما يفعله النظام: يوجّه الطلب فوق حد معيّن للمدير المالي، أو يصعّد الطلب المتأخر تلقائيًا. غير الوظيفي يصف كيف يؤدّي ذلك: السرعة، والأمان، وسهولة الاستخدام على الجوال، ودقة السجل. إهمال غير الوظيفي ينتج نظامًا يفعل كل شيء لكنه بطيء أو معقّد فيهجره الموظفون بعد أسابيع.
متى أجمع مدخلات مصفوفة الصلاحيات؟
أثناء المقابلات نفسها، لا كمرحلة منفصلة لاحقة. مصفوفة الصلاحيات — من يعتمد ماذا وعند أي حد مالي — هي أطول قرار تأخيرًا في أي مشروع. توثيق حدودها وبدائلها عند الغياب أثناء جمع المتطلبات يعني أن البناء لاحقًا سيكون تنفيذًا مباشرًا بلا انتظار قرارات إدارية معلّقة.
كيف أتأكد أنني لم أنسَ متطلبًا مهمًا؟
اسأل عن الاستثناءات صراحة عند كل خطوة بجملة «وماذا يحدث لو…»: لو غاب المعتمد، لو تجاوز المبلغ الحد، لو رُفض الطلب. الناس يصفون الحالة المثالية تلقائيًا، والمتطلبات المنسية تسكن في الاستثناءات. كذلك أعد صياغة ما فهمته أمام صاحب المصلحة ودوّن تصحيحه، فالمتطلب المؤكَّد شفهيًا يختلف كثيرًا عن المكتوب المتفق عليه.
هل أوثّق المتطلبات أم يكفي فهمها؟
التوثيق ضروري لا رفاهية. المتطلب الشفهي يُنسى أو يُفهم على وجهين مختلفين بين من ذكره ومن سينفّذه. اكتب كل متطلب بجملة قابلة للاختبار تحدّد الشرط والنتيجة بدقة، لا بوصف عام. القائمة المكتوبة تصبح مرجعًا يحسم أي خلاف لاحق، وأساسًا لاختبار النظام والتأكد أنه يفعل ما اتُّفق عليه فعلًا.
ملخص سريع
جمع متطلبات نظام الموافقات هو أرخص مرحلة لاكتشاف الأخطاء وأهمها. قابل من يقدّم الطلب ومن يعتمده ومالك الإجراء والمالية، أدر المقابلة بترتيب يكشف الاستثناءات، ووثّق كل متطلب بجملة قابلة للاختبار تفصل الوظيفي عن غير الوظيفي. احسم مدخلات مصفوفة الصلاحيات مبكرًا، فيتحوّل البناء من تجريب مكلف إلى تنفيذ لقرار محسوم.
أين تتوقف طلباتك اليوم؟
احصل على تقييم مجاني لإجراءاتك الحالية: نرسم معك مسار أحد إجراءاتك ونحدد أين يضيع الوقت فعلًا.