سير عمل الموافقات في جوهره مسألة توجيه ترتدي زيّ السياسة. جُلّ ما تفعله السلسلة هو الإجابة عن سؤالين: هل هذا الطلب مسموح به بموجب سياسة الإنفاق، ومن الشخص المناسب للتوقيع عليه. يتولى الذكاء الاصطناعي كليهما ببراعة، طالما أبقيتَه بعيداً عن الفعل الوحيد الذي يجب ألا يقوم به أبداً: الموافقة على الإنفاق. النموذج يقرأ ويُوجّه؛ أما الالتزام فيتخذه إنسانٌ محدد بالاسم.
هذا التمييز هو التصميم بأكمله. حين يُقدّم أحدهم طلب شراء، ثمة سلسلة من القرارات يجب أن تُتخذ قبل أن يصل الطلب إلى صندوق وارد أحدهم. ما فئة هذا الطلب؟ هل يتجاوز حدّاً يستدعي مُوافِقاً ثانياً؟ هل تبقّت ميزانية في مركز التكلفة؟ هل المورّد مُعتمد وليس على قائمة تعليق؟ هل يملك مُقدّم الطلب أصلاً صلاحية مُفوَّضة لرفعه؟ تُجيب الفرق عن هذه الأسئلة يدوياً اليوم، ولهذا قد يظل طلب شراء حاسوب محمول بقيمة 4,000 يورو عالقاً ستة أيام في انتظار شخص لم يكن المُوافِق الصحيح من الأساس.
أين تكمن الضوابط فعلياً
ضوابط الإنفاق ليست قاعدة واحدة. هي مجموعة مُتراكبة من الطبقات، ولكل طبقة مالكٌ مختلف ونمط إخفاقٍ مختلف. قبل أتمتة أي شيء، نفصل بينها، لأن دمجها في استدعاء نموذج واحد هو الطريق إلى نظام لا يستطيع أحدٌ تدقيقه.
- الأهلية: هل يحق لمُقدّم الطلب رفع هذا النوع من الطلبات. هذا هو تفويض الصلاحيات (delegation of authority)، ومحله مصفوفة مُفهرسة بالدور ومركز التكلفة وشريحة المبلغ.
- التصنيف: ما الذي يُشترى. هذا يقود كل ما يليه، وهو الطبقة التي يُثبت فيها النموذج جدارته لأن طلبات الشراء المكتوبة بنص حر تكون فوضوية.
- الحدود والتصعيد: كم توقيعاً مطلوباً، ومن أصحابه. تجديد اشتراك برمجيات بقيمة 900 يورو وآخر بقيمة 90,000 يورو يسلكان مسارين مختلفين حتى وإن كانت الفئة متطابقة.
- الميزانية والالتزام: هل تبقّى مالٌ فعلاً، مع احتساب أوامر الشراء المفتوحة الملتزَم بها بالفعل مقابل البند، لا الأرصدة المُقيّدة فقط.
- حالة المورّد والامتثال: مُعتمد، ومُصدّق ضريبياً، وليس خاضعاً لعقوبات، وليس على قائمة تعليق دفع.
يلامس النموذج التصنيف بكثافة، والأهلية والحدود بخفة، أما الميزانية وحالة المورّد فلا يلامسهما إطلاقاً. هاتان الأخيرتان استعلامان حتميّان (deterministic) مقابل نظام ERP وسجل المورّدين الرئيسي. أنت لا تريد نموذجاً لغوياً يُقدّر الميزانية المتبقية بالتخمين. تريده أن يقرأ طلب الشراء، ويقرر الفئة وشريحة المبلغ المرجّحة، ثم يترك للاستعلامات الصارمة أن تتولى الحساب.
توجيه يقرأ من بيانات ذات إصدارات
الطريقة القديمة لبناء سلسلة موافقات هي مُخطّط انسيابي (flowchart) مُبرمَج بصلابة داخل أداة المشتريات. يعمل حتى تتغير المؤسسة، ثم يبدأ بالتعفّن. يغادر أحدهم، ويتحرك حدٌّ ما، ويُفعَّل كيانٌ قانوني جديد، فيكذب المخطط الانسيابي ثلاثة أسابيع قبل أن يلاحظ أحدٌ طابوراً عالقاً.
نحن ننمذج التوجيه بوصفه بيانات بدلاً من ذلك. مصفوفة تفويض الصلاحيات، وخطوط التبعية، وجدول الحدود، كلها سجلات ذات إصدارات (versioned) وتواريخ سريان. يقرأ المُوجّه الإصدار الذي كان سارياً وقت رفع الطلب ويثبّت عليه. هذا مهم لصحة اللحظة الزمنية (point-in-time correctness): موافقة جرت في مارس يجب أن تكون قابلة للتفسير مقابل سياسة مارس، لا سياسة يوليو. حين يسأل مُدقّق عن سبب ذهاب طلبٍ إلى نائب رئيس بعينه، يكون الجواب إصدار مصفوفة وصفاً محدداً، لا تخميناً لما فعله الكود ذلك اليوم.
يقف نموذج التصنيف أمام هذا كله. يقرأ نص طلب الشراء، وأي عرض سعر مرفق، وسياق مُقدّم الطلب، ثم يُنتج فئة، وشريحة مبلغ، ودرجة ثقة. الثقة المنخفضة لا تفشل نحو السماح (fail open). بل تُوجّه إلى المسار الأكثر صرامة وتُعلَّم للمراجعة، لأن كلفة موافقة ثانية غير ضرورية هي دقائق، بينما كلفة موافقة فائتة هي ثغرة في الضوابط. هذه ميزانية إيجابيات كاذبة (false positives) مقصودة: نقبل بعض التصعيد الزائد لنُبقي التصعيد الناقص قريباً من الصفر.
بضعة أمور نُصرّ عليها في طبقة التوجيه:
- كل قرار يكتب سجلاً كاملاً: المُدخل، وإصدار المصفوفة، والفئة، ودرجة الثقة، والمُوافِق المختار، والسبب. هذا هو سجل التدقيق، ويُكتب قبل خروج الإشعار، لا يُعاد تركيبه لاحقاً.
- تعمل تسوية الكيانات (entity resolution) على هوية مُقدّم الطلب والمُوافِق كي لا تؤدي إعادة هيكلة أو تشابه أسماء إلى توجيه خاطئ. الناس ينتقلون بين الفرق؛ والمُوجّه يعتمد على مُعرّفات ثابتة، لا على الأسماء المعروضة.
- الطلبات قيد التنفيذ تحتفظ بإصدار المصفوفة الخاص بها. تغيير السياسة يجب ألا يُعيد توجيه شيء يتحرك في السلسلة فعلاً دون إشعار.
الفرض دون تعطيل العمل
الإخفاق الذي تصطدم به معظم مشاريع ضبط الإنفاق ليس ضعف الضوابط. بل ضوابط صارمة إلى حدٍّ يجعل العمل يلتفّ حولها، وهذا أسوأ من عدم وجودها، لأن العملية الموازية باتت الآن غير مرئية. الغاية من أتمتة التوجيه هي أن يكون المسار المُمتثِل هو المسار الأسرع.
المعالجة المباشرة الكاملة (straight-through processing) هي الهدف بالنسبة للغالبية منخفضة المخاطر. طلبٌ دون الحدّ، ضمن الميزانية، من مُقدّم مؤهل، مقابل مورّد مُعتمد، في فئة نظيفة، لا يحتاج إلى أن يقرأه إنسان أصلاً بما يتجاوز التوقيع الواحد المطلوب. نقيس نسبة ما يمرّ دون طابور ونعامل ذلك الرقم بوصفه مؤشر صحة النظام. حين ينخفض، فذلك يعني أن شيئاً أعلى المجرى انحرف: فئة بدأ النموذج يُسيء معالجتها، أو سجل مورّدين تقادم، أو حدّ مضبوط أضيق مما يقتضيه الإنفاق المعتاد لفريق ما.
عندئذٍ يتركّز الفرض على تركيز الانتباه البشري حيث ينبغي. الاستثناءات التي تطفو هي تلك التي تحتاج فعلاً إلى حُكم بشري: مورّد خارج التعاقد، مبلغ قفز بين الشرائح متأخراً في مسار الموافقة، تجزئة تبدو وكأنها تتهرب من حدٍّ ما. نراقب هذا الأخير تحديداً. أمرا شراء بقيمة 9,000 يورو لكلٍّ منهما لنفس المورّد في نفس الأسبوع، حين يكون الحدّ 10,000 يورو، نمطٌ يستطيع المُوجّه الإشارة إليه رغم أن كل طلب نظيفٌ على حِدة. كشفه يتطلب تاريخ الالتزامات، لا الطلب المنفرد، ولهذا يقرأ التوجيه الحالة بدل أن يعامل كل طلب شراء وكأنه معزول.
لا شيء من هذا يُلغي المُوافِق. إنما يُلغي الأيام الستة التي يقضيها الطلب عالقاً في المكان الخطأ. الشخص الذي يُوقّع لا يزال يُوقّع، ولا يزال يملك القرار، لكنه الآن يفعل ذلك مقابل طلبٍ وصل مُصنّفاً بشكل صحيح، ومُوجّهاً بشكل صحيح، وقد فُحصت الميزانية وحالة المورّد سلفاً، وخلفه سجل بكل خطوة قُطعت.
الأسئلة الشائعة
كيف تمنعون مُوجِّه الذكاء الاصطناعي من الموافقة على إنفاق كان ينبغي تصعيده؟
النموذج لا يُوافق إطلاقاً. هو يُصنّف الطلب، ويحدد المُوافِق الصحيح من مصفوفة تفويض الصلاحيات (delegation of authority)، ثم يُوجّه الطلب. تبقى الموافقة فعلاً بشرياً مُسجّلاً باسم شخص محدد، وأي تصنيف منخفض الثقة يتخذ افتراضياً المسار الأكثر صرامة.
ماذا يحدث حين يتغير الهيكل التنظيمي أو مصفوفة تفويض الصلاحيات في منتصف الربع؟
يقرأ التوجيه مصفوفة الصلاحيات وخطوط التبعية بوصفها بيانات ذات إصدارات (versioned) وتواريخ سريان، لا منطقاً مُضمّناً داخل النموذج. إعادة الهيكلة أو رفع حدٍّ ما هي تغييرٌ في البيانات يسري في تاريخه المُحدد، والطلبات قيد التنفيذ تحتفظ بإصدار المصفوفة الذي بدأت في ظله.
هل يمكن تشغيل هذا دون استبدال نظام تخطيط موارد المؤسسة (ERP) أو أداة المشتريات لدينا؟
نعم. يعمل المُوجّه إلى جانب نظام السجل (system of record) ويكتب القرارات إليه عبر واجهته البرمجية (API) أو خطافات الموافقة (approval hooks). يبقى نظام ERP هو الدفتر المرجعي لأمر الشراء (PO) وسجل التدقيق؛ بينما تتولى طبقة الذكاء الاصطناعي التصنيف والتوجيه فوقه.