ما هو نموذج التشغيل الوكيل (Agentic Operating Model)

تخيل فريقًا ماليًا بدأ في استخدام وكيل (agent) للمساعدة في عملية إغلاق الدفاتر الشهرية. يمكن للوكيل سحب البيانات من نظام ERP، ومطابقة الفواتير، وإعداد مسودات القيود اليومية، ومتابعة الاستثناءات. على الجانب الآخر، لدى فريق عمليات العملاء أيضًا وكيل يرد على استفسارات العملاء، ويغير العناوين، أو يتحقق من حالة الطلبات. وفي الوقت نفسه، يقوم فريق تقنية المعلومات بإنشاء وكيل للتشخيص الأولي للحوادث.

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

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

هنا يصبح مفهوم نموذج التشغيل الوكيل (Agentic Operating Model) ذا صلة.

عندما تبدأ الافتراضات القديمة في الانهيار

لعقود من الزمن، بُني نموذج تشغيل الشركات على افتراض واحد بسيط: الإنسان هو المنفذ الرئيسي للعمل. البرنامج موجود للمساعدة – تسجيل المعاملات في ERP، وإدارة التفاعلات في CRM، وتوجيه الموافقات عبر سير العمل (workflow)، أو عرض البيانات في لوحات المعلومات. لكن في النهاية، الإنسان هو من يبدأ ويقيّم ويقرر ويُنهي العمل.

بدأ الذكاء الاصطناعي الوكيل (Agentic AI) في تغيير هذا الافتراض.

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

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

المشكلة الثانية هي غموض المساءلة. عندما يصنف الوكيل فاتورة بشكل خاطئ، من المسؤول؟ فريق علوم البيانات؟ مالك عملية الحسابات الدائنة؟ مزود المنصة؟ بدون تعريف واضح، يتحول كل حادث إلى نقاش عبر الوظائف.

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

لهذا السبب، لا يمكن إدارة الذكاء الاصطناعي الوكيل فقط كمشروع تقني. إنه طبقة تنفيذ جديدة تتطلب انضباطًا تشغيليًا جديدًا.

ستة عناصر يجب تعريفها منذ البداية

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

1. حدود صلاحية واضحة

يجب أن يعرف كل وكيل بالضبط الإجراءات التي يمكنه القيام بها دون موافقة، والإجراءات التي تتطلب موافقة بشرية، والإجراءات التي يجب أن تكون مجرد توصيات. هذا ليس مجرد قول "الوكيل يساعد في عملية المشتريات". المطلوب هو تعريف تشغيلي.

في المشتريات، على سبيل المثال، يمكن للوكيل تصنيف طلبات الاستلام واقتراح مسار الشراء. يمكنه التحقق من اكتمال تأهيل الموردين. يمكنه التعامل مع عدم تطابق الفواتير البسيط ضمن حدود سياسة التسامح. لكن لا يمكنه الموافقة على مورد جديد عالي المخاطر أو تغيير البيانات الأساسية للمورد دون موافقة.

في عمليات تقنية المعلومات، يمكن للوكيل إجراء التشخيص الأولي والمعالجة منخفضة المخاطر وفقًا لدليل الإجراءات (runbook). لكن لا يمكنه إجراء تغييرات في التكوين الإنتاجي ذات تأثير واسع دون موافقة مدير الحوادث.

بدون حدود صلاحية واضحة، سيكون الوكيل إما مقيدًا جدًا بحيث لا يكون ذا قيمة، أو حرًا جدًا بحيث لا يكون آمنًا.

2. ثلاثة مالكين لكل وكيل

أحد أهم المبادئ في نموذج التشغيل الوكيل هو أن كل وكيل يجب أن يكون له ثلاثة مالكين.

أولاً، مالك الأعمال (business owner). عادةً ما يكون مالك نتيجة العملية. يحدد أهداف العمل للوكيل، ومستوى الخدمة (SLA)، وأولويات حالات الاستخدام، والمفاضلة بين السرعة والجودة وتجربة المستخدم. على سبيل المثال، رئيس الحسابات الدائنة لوكيل استثناءات الفواتير، أو المراقب المالي لوكيل تنسيق الإغلاق.

ثانيًا، المالك التقني (technical owner). مسؤول عن التكامل، والموثوقية، وقابلية المراقبة (observability)، ودورة الحياة التقنية للوكيل. يمكن أن يكون هذا ضمن فريق المنصة أو هندسة الذكاء الاصطناعي.

ثالثًا، مالك المخاطر (risk owner). يحدد القيود الواقية (guardrails)، وعتبات الموافقة، وضوابط الامتثال، وشروط الإيقاف. في بعض المجالات، يمكن أن يأتي مالك المخاطر من الامتثال أو الرقابة الداخلية أو الشؤون القانونية.

بدون هذه الملكيات الثلاث، سيبدو الوكيل مملوكًا بشكل مشترك، لكنه في الواقع لن يكون مملوكًا لأحد حقًا.

3. مسار تصعيد واضح

نموذج التشغيل الناضج لا يسعى إلى أقصى درجة من الاستقلالية. إنه يسعى إلى الاستقلالية المناسبة. لذلك، يجب أن يكون لكل وكيل مسار تصعيد واضح: متى يجب عليه رفع الأمر إلى الإنسان.

يمكن أن يحدث هذا عندما تكون الثقة منخفضة، أو البيانات غير كاملة، أو تعارض في السياسات، أو استثناء خارج النمط الطبيعي، أو تجاوز قيمة المعاملة للحد المسموح به، أو عندما يكون تأثير السمعة مرتفعًا جدًا.

في عمليات العملاء، يمكن للوكيل حل طلبات تغيير العنوان بشكل مستقل، لكن يجب عليه تصعيد المبالغ المستردة الكبيرة أو الحالات التي قد تتحول إلى نزاعات. في سجل الدفاتر (record-to-report)، يمكن للوكيل إعداد مسودات القيود اليومية، لكن يجب عليه تصعيد القيود الجوهرية أو الحسابات الحساسة.

مسار التصعيد الجيد ليس مجرد "رمي الأمر للإنسان". يجب أن يحدد من يتلقى، وفي غضون مهلة زمنية (SLA) محددة، وبأي سياق، حتى لا يضطر الإنسان إلى إعادة العمل من الصفر.

4. ثلاثة أوضاع تشغيل

تحتاج الشركة إلى تحديد ثلاثة أوضاع تشغيل بسيطة ولكنها حازمة.

الوضع الأول هو التوصية فقط (recommendation only). يقوم الوكيل بالتحليل أو التلخيص أو اقتراح الإجراءات، لكن الإنسان يظل هو المنفذ. مناسب للمجالات الجديدة أو عالية المخاطر أو التي لا تملك بيانات وضوابط ناضجة بما فيه الكفاية.

الوضع الثاني هو الإنسان في الحلقة (human-in-the-loop). يقوم الوكيل بإعداد الإجراء ويمكنه تنفيذ بعض الخطوات، لكن القرار النهائي لا يزال يتطلب موافقة بشرية. غالبًا ما يكون هذا هو الوضع الأكثر واقعية للموجة الأولى في المالية والمشتريات والموارد البشرية وعمليات العملاء.

الوضع الثالث هو الاستقلالية المقيدة (bounded autonomy). يمكن للوكيل التصرف بشكل مستقل ضمن نطاق محدد، مع قيود واقية وتسجيل (logging) وآليات تراجع (fallback) واضحة. مناسب للأعمال ذات الحجم الكبير والقواعد الواضحة نسبيًا، مثل فرز التذاكر أو معالجة حوادث تقنية المعلومات منخفضة المخاطر.

المهم: لا ينبغي أن تحدد هذه الأوضاع من قبل فريق التقنية وحده. يجب الاتفاق عليها من قبل الأعمال والمخاطر والعمليات.

5. قياس النتائج، وليس النشاط

غالبًا ما يركز نموذج التشغيل القديم بشكل مفرط على النشاط والقدرة البشرية: عدد التذاكر التي تمت معالجتها، عدد الموظفين المكافئين بدوام كامل (FTE)، أو الأعمال المتراكمة لكل مشرف. في النموذج الوكيل، يجب أن يتحول التركيز إلى نتائج نظام العمل.

المقاييس الأكثر صلة تشمل وقت الدورة (cycle time)، ومعدل الاستثناءات، ومعدل الأتمتة، والتكلفة لكل معاملة، وجودة القرار، ومعدل إعادة العمل، وتحقيق مستوى الخدمة (SLA). في الإغلاق المالي، لم يعد السؤال الرئيسي هو كم عدد المحللين الذين يعملون لساعات إضافية، بل هل أصبح الإغلاق أسرع، وهل يتم حل الاستثناءات بشكل أسرع، وهل يثق المدقق الداخلي أكثر في مسار الرقابة.

6. إعادة تصميم الأدوار البشرية

هذا هو الجزء الذي غالبًا ما يتم الاستهانة به. نموذج التشغيل الوكيل لا يقتصر فقط على إضافة وكلاء إلى الفرق القديمة. إنه يغير تصميم العمل.

في العديد من العمليات، سينتقل الإنسان من تنفيذ المعاملات ونقل البيانات ومتابعة المتابعات، إلى التعامل مع الاستثناءات، والإشراف على جودة القرارات، وتحسين سير العمل، وإدارة السياسات، وتدريب النظام من خلال التغذية الراجعة التشغيلية.

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

يمكن للشركات الحصول على قدرة وسرعة أعلى، ولكن فقط إذا كانت على استعداد لإعادة تصميم الأدوار والمهارات وهياكل الفرق. إذا لم تفعل ذلك، فسيتم فقط إضافة الوكلاء فوق التنظيم القديم.

من الإدارة القائمة على الدور إلى الإدارة القائمة على النتيجة

أحد أكبر الآثار المترتبة على نموذج التشغيل الوكيل هو التحول من الإدارة القائمة على الدور إلى الإدارة القائمة على النتيجة.

في النموذج القديم، تميل المؤسسات إلى إدارة العمل بناءً على المربعات التنظيمية: من يفعل ماذا، وكم عدد الأشخاص في كل فريق، وكيف يتم التسليم بين الأدوار. هذا النهج منطقي عندما يكون الإنسان هو المنفذ الرئيسي. ولكن عندما يشارك الوكيل في التنفيذ، فإن وحدة التحليل الأكثر أهمية لم تعد الدور، بل النتيجة من البداية إلى النهاية (end-to-end outcome).

الوكيل لا يهتم بالحدود الوظيفية مثل التنظيم البشري. يمكنه سحب البيانات من CRM، والتحقق من السياسات في قاعدة المعرفة، وإنشاء تذكرة في ITSM، وتحديث ERP في تدفق واحد. لذلك، تحتاج الشركات إلى البدء في التساؤل: ما هي النتيجة التي نريد تحقيقها؟ ما هي الخطوات التي تحتاج حقًا إلى إنسان؟ ما هي نقاط القرار التي يجب الحفاظ عليها؟ وما هو الجزء الذي يجب تنفيذه بواسطة العمالة الرقمية؟

في دورة "من العميل إلى التحصيل" (lead-to-cash)، على سبيل المثال، بدلاً من تحسين الإنتاجية المنفصلة بين عمليات المبيعات وإدارة الطلبات والفوترة والتحصيل، يمكن للشركة إعادة تصميم نتيجة "طلب صالح وقابل للتحصيل بسرعة" باستخدام وكيل ينسق التحقق من الطلب والتحقق من العقد ومتابعة التحصيل الأولية.

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

من يجب أن يقود

بمجرد أن تأخذ الشركة الأمر بجدية وتجعل الوكيل جزءًا من التنفيذ، يجب أن يتغير هيكل الإدارة وفقًا لذلك.

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

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

الأهم من ذلك، نموذج التشغيل الوكيل ليس مجرد أجندة تقنية. يجب أن يشارك كبير مسؤولي العمليات (COO) لأن التغيير الرئيسي يحدث في تصميم العملية واقتصاديات العمليات. يجب أن يشارك كبير مسؤولي الموارد البشرية (CHRO) لأن التأثير مباشر على تصميم الوظائف والمهارات وإدارة الأداء. يجب أيضًا أن يكون المدير المالي (CFO) وقادة المخاطر نشطين لأن الوكيل يمس الرقابة وقابلية المراجعة والمساءلة.

علامات تدل على أن الشركة غير مستعدة

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

إذا كانت بعض هذه الأعراض واضحة بالفعل، فإن الأولوية ليست إضافة حالات استخدام جديدة، بل تعزيز الانضباط التشغيلي أولاً.

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