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