مسارات الموافقة للعمليات المالية

ماذا ستخرج به من هذا المقال؟

بناء مسار موافقة مرن وآمن: محفّزات، مستويات بصلاحيات، متسلسل أو موازٍ، تصعيد، وأثر قرار كامل. سنبني الفكرة من المشكلة إلى القرار ثم إلى تطبيق يمكن نقله إلى مشروع حقيقي، مع مخطط بصري ومثال عملي وقائمة تحقق في النهاية.

في شركة متوسطة، أراد المدير المالي تحويل 800,000 ريال لدفع فاتورة مزود خلال ساعتين. لو كانت الصلاحية بيد موظف واحد، لتُرك قرار بحجم خطأه فادح يمر بلا مراجعة، ولو طُلبت موافقات متسلسلة بلا قواعد لتعطل التحويل وأوقف مورداً مهماً. بين هذين الطرفين يقف مسار الموافقة (Approval workflow): بنية تحدد من يسمح بشيء، وكم يسمح به، ومتى يجب سؤال من فوق، وكيف يبقى كل قرار مسجلاً.

المشكلة الحقيقية ليست "كيف نضيف زر موافقة" بل كيف نصمم رقابة لا تعطل العمليات: محفّزات تفتح المسار عند الحاجة فقط، مستويات صلاحيات مرتبطة بالسقوف والمخاطر، تصعيداً تلقائياً يمنع التعليق، وأثراً كاملاً يجعل أي قرار قابل للمساءلة. هذا المقال يشرح بناء مسار موافقة مرن وآمن للعمليات المالية بأمثلة عملية وحالات حافة حقيقية — من فصل المهام (maker-checker) إلى الإجازات والنيابات وقابلية تعديل القواعد دون نشر كود.

لماذا نحتاج مسارات موافقة؟

الموافقات ليست بيروقراطية زائدة؛ إنها حاجز مصمم بعناية ضد الخطأ والتلاعب في أنظمة تمرّ عبرها أموال حقيقية باستمرار. أهمية مصممها تظهر في قائمة الحاجات التالية:

• مبلغ كبير بلا موافقة يخاطر بالأموال: عملية بملايين تمرّ بضغطة موظف منفرد تفتح الباب لخطأ غير مقصود أو لخداع مقصود، وثمن أي منهما قد يقارب رأسمال المؤسسة ذاتها.


• صلاحية واحدة مفرطة تفتح باب التلاعب: موظف يملك حق إنشاء الطلب وموافقته وتنفيذه يستطيع صنع عملية مالية كاملة بنفسه؛ لهذا يفرض المنظمون في القطاعات المالية مبدأ فصل المهام (Maker-Checker) الذي يفصل منشئ العملية عن المصادق عليها.


• لا أثر لمن وافق ومتى: عند النزاع أو المراجعة الخارجية، السؤال ليس "هل وُوفق؟" بل "من وافق ومتى ولماذا؟" وغياب الأثر يجعل المساءلة الفعلية مستحيلة.


• بطء يدوي يوقف العمليات العاجلة: سلسلة موافقات بالبريد أو الانتظار حتى يجتمع المديرون تجمد التحويلات العاجلة؛ النظام الآلي يوقيت التصعيد ويمنع أن يكون الضابط هو من يفرض الالتزام بمواعيده الحياتية.


• صعوبة تغيير القواعد حسب السياسة: حين تكون سقوف الموافقة مخزونة في ثوابت برمجية، كل تغيير في السياسة — رفع سقف أو إضافة مستوى — يستلزم إصدار شيفرة جديدة، فيتحول التعديل من دقائق إلى مشروع.

المفاهيم الأساسية

• المحفّز (Trigger): القاعدة التي تحدد متى يفتح المسار أصلاً: تجاوز سقف مبلغ، تصنيف العملية، عميل أو مستفيد جديد، أو درجة مخاطرة مرتفعة. المحفّز الجيد يمنع الاحتكاك غير الضروري ولا يسمح بالتحايل على المراجعة.


• المستوى (Level): خطوة موافقة محددة بصلاحية ومسؤولية، مثل: مدير، ثم رئيس إدارة، ثم لجنة. المسار يبنى من ترتيب هذه المستويات حسب القيمة والخطورة.


• الصلاحية (Authority): سقف المبلغ أو نوع القرار الذي يحق لموافق البتّ فيه دون تجاوزه. الصلاحية ليست رتبة فخرية إنما أدنى تحقق تنفذه النواة نفسها قبل قبول أي موافقة.


• الموازي/المتسلسل: التفعيل المتزامن لعدة قرارات مستقلة (مثل مالي وقانوني) مقابل الترتيب الإجباري للقرارات المعتمدة على بعضها. اختيار النمط الخطأ يبطئ كل شيء أو يسمح بقرار قبل قيده الحاسم.


• التصعيد (Escalation): آلية زمنية تنقل الطلب تلقائياً إلى مستوى أعلى عند انتهاء مهلة دون رد. التصعيد هو الفرق بين مسار يعلق وآخر يتحرك دائماً.


• الأثر: تسجيل كل قرار بقيمة: الموافق، والمستوى، والقرار، والوقت، والسبب. الأثر هو لسان المسار أمام أي تحقيق أو مراجعة تنظيمية.


• فصل المهام (Maker-Checker): منشئ العملية شخص والمصادق عليها شخص آخر محتمل، كي لا توجد يد واحدة تسيطر على دورة كاملة من المال.

رحلة الموافقة

طلب -> يقيّم المحفّز -> مستويات حسب المبلغ -> موافقات -> تصعيد عند اللزوم -> تنفيذ أو رفض.

خطوة بخطوة: بناء المسار

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

الخطوة 1: حدّد محفّزات بسيطة

ابدأ بأقل عدد ممكن من المحفّزات المفهومة: سقف مبلغ، تصنيف عملية، أو مستفيد جديد. اختبر المحفّز بمصفوفة من العمليات الحقيقية: كم عملية كانت ستمر دون مسار، وكم كانت ستدخل مساراً؟ هدف المعايرة ألا تفرك العمليات الصغيرة ولا يتسلل الكبير من تحت الرادار.

if amount > 10000 or new_beneficiary -> start the path

النتيجة: لا موافقة على الصغير بلا داعٍ، ولا كبير يمرّ بدون مراجعة.

الخطوة 2: عرّف مستويات بصلاحيات

ارسم سقوفاً لكل مستوى بحيث يقع كل مبلغ في المستوى الأدنى الموجب للمراجعة، ثم أعلاه، وهكذا حتى السقف الذي يتطلب لجنة. راجع السقوف بما يطابق مسؤولية الأدوار لا أقدمية الأفراد، وأجرِ تحقق الرصيد الآلي على مستواها.

L1: حتى 50k؛ L2: حتى 200k؛ L3: لجنة فوق 200k

النتيجة: موافق مناسب لكل مبلغ، وقرار بصلاحية سليمة لا يفوق سقفه.

الخطوة 3: اجعل الموافقات متسلسلة أو موازية

قرارات مستقلة مثل "مالي" و"قانوني" تسير موازية وتجمع عند نقطة واحدة؛ القرارات المتلاحقة مثل "مدير ثم رئيس الإدارة" تتسلسل. اجعل النمط جزءاً من تعريف المرحلة نفسها لا منطقاً مبعثراً في أماكن عدة، فالتعديل لاحقاً يصبح إعادة تعريف لقاعدة واحدة.

L1 ثم L2 متسلسل؛ L2a وL2b موازٍ (مالي + قانوني)

النتيجة: توازن بين رقابة وسرعة، وقرارات مستقلة لا تنتظر بعضها عبثاً.

الخطوة 4: أضف تصعيداً عند المهلة

لكل مستوى مهلة معقولة: ساعة للمبالغ العاجلة، يوم عمل لما دون ذلك. عند انتهائها، ينقل النظام الطلب تلقائياً للمستوى الأعلى ويخطر الموافق الأصلي. عند غياب الجميع — إجازة أو مغادر— أعد توجيه النيابة المعلنة مسبقاً إن وُجدت.

if no response in 24h -> escalate to next level

النتيجة: لا طلبات عالقة للأبد، والعاجل لا يمرّ بالبريد انتظاراً لردّ يطول.

الخطوة 5: سجّل كل قرار

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

audit: approver, level, decision, at, reason, tx_id

النتيجة: مساءلة كاملة، وأرضية صلبة لأي تدقيق خارجي أو نزاع لاحق.

الخطوة 6: اجعل القواعد قابلة للتغيير

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

rules in versioned config -> apply without code deploy

النتيجة: سياسة تتغير بسهولة، وتاريخها محفوظ، وتطبيقها لا ينتظر دور نشر الشيفرة.

مثال عملي كامل: تحويل شركة

شركة تدفع فاتورة تجهيزات بـ 180,000. المحفّز يفتح المسار لأن المبلغ فوق 10,000 والمستفيد جديد أيضاً. يُوجّه الطلب إلى المستوى الأول (حتى 50,000) لكنه يتجاوزه، فينتقل تلقائياً إلى المستوى الثاني (حتى 200,000). المدير المالي وافق، غير أن قاعدة "المستفيد الجديد" تطلبت مصادقة القسم القانوني موازية، فكانت الموافقتان متوازيتين وتجمعتا عند المشرف المالي.

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

مقارنة: موافقة صلبة مقابل مرنة

الفرق الجوهري ليس في وجود نظام موافقات، بل في قابلية هذا النظام للتكيف مع السياسة المتغيرة والظروف الإنسانية (إجازات، أغيار، مستويات جديدة) بدون تسليم الشيفرة:

أخطاء شائعة

قائمة تحقق سريعة

• محفّزات بسيطة بحدود واضحة مبنية على المبلغ والتصنيف.


• سقوف صلاحيات ترتبط بالدور والمسؤولية لا بالأقدمية.


• فصل صريح بين منشئ العملية والموافق عليها.


• اختيار دقيق بين التسلسل والتوازي لكل مرحلة.


• مهلات زمنية لكل مستوى مع تصعيد تلقائي.


• نيابات معلنة للموافقين الغائبين.


• أثر كامل لكل قرار: من ومتى ولماذا.


• قواعد بإصدارات وتواريخ سريان قابلة للتعديل.


• منع تعديل مبالغ العمليات بعد الموافقة.


• مراجعة دورية للصلاحيات والوكالات عند التغييرات.

الأسئلة الشائعة

متى أستخدم موازياً؟

عندما يكون القراران مستقلين — مثل تجاوز سقف مالي مع مصادقة قانونية — فلا داعي لأن ينتظر أحدهما الآخر. أما القرارات المتلاحقة، كمستوى يعلو سقف مستوى سابق، فتسير متسلسلة لأن الثاني يبني على الأول؛ وخلط النمطين يولّد انتظاراً زائداً أو قراراً ناقص الأساس.

كيف أمنع تعطيل العاجل؟

بثلاث ركائز: مهلات قصيرة للتصعيد التلقائي في العمليات العاجلة، ومسارات سريعة للمبالغ المحدودة تكتفي بمستوى واحد، ونيابات معلنة تغطي غياب الموافق الأساسي. بهذا يبقى الطلب يتحرك دائماً، والرقابة لا تسقط بل تُنقل ممن هو أولى.

هل يكفي موافق واحد للكبير؟

لا. للمبالغ العالية تُلزم مؤسسات بأكثر من مستوى تسلسلي أو لجنة موافقة. الموافق المنفرد، مهما كانت رتبته، يمثل نقطة تركيز للمخاطرة والخطأ، والرقابة الجماعية هي التي توازن السقوف المرتفعة عبر توزيع المسؤولية.

كيف أتعامل مع إجازات الموافقين؟

بتصعيد زمني لا ينتظر أحداً، ونظام نيابات صريح: يعلن الموافق نائباً عنه مسبقاً بحد صلاحية أدنى، وينتقل الطلب لنائبه أو للمستوى الأعلى عند انتهاء المهلة. التصعيد الممطول بدون نائب يترك الحركة متوقفة؛ والتقاعس عن إعداد النيابات هو ما يحول الإجازات إلى حوادث عمل.

الخلاصة

الخطوة التالية

لأمن القنوات الرقمية، راجع "أمن البنك الرقمي: OTP وأجهزة الجلسات".

كيف تستخدم هذا المقال في عمل حقيقي؟

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

flowchart LR

    A["القناة المصرفية"]

    B["التحقق والهوية"]

    C["قواعد الأعمال"]

    D["النظام البنكي"]

    E["التسجيل والتسوية"]

    A --> B

    B --> C

    C --> D

    D --> E