الأدوار الجديدة في المؤسسة العاملة بالوكلاء

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

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

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

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

لماذا هناك حاجة إلى أدوار جديدة

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

بعبارة أخرى، لا يلغي الوكيل الحاجة إلى التنظيم. بل يغير الوكيل شكل الحاجة إلى التنظيم.

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

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

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

مالك منتج الوكيل: مالك القيمة، وليس مجرد مالك الميزة

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

مالك منتج الوكيل ليس مجرد منسق لمشروع ذكاء اصطناعي. يجب أن يمتلك أربعة أشياء رئيسية. أولاً، فرضية القيمة (Value Thesis). يجب أن يكون قادراً على الإجابة عن المشكلة التجارية التي يحلها الوكيل، وما هي النتائج المتوقعة، ولماذا تستحق حالة الاستخدام هذه الأولوية. مثال في الإغلاق المالي: الوكيل لم يُبنَ فقط "لمساعدة المراقب المالي"، بل لتقليل وقت جمع الأدلة، وتسريع فرز الاستثناءات، وزيادة اتساق مسودات التعليقات. مثال في المشتريات: الوكيل ليس مجرد روبوت محادثة للاستقبال، بل أداة لتقليل زمن دورة الطلب، وزيادة الامتثال لمسارات التوريد، وتقليل إعادة العمل للمشتري.

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

ثالثاً، التبني والملاءمة التشغيلية (Adoption and Operating Fit). الوكيل الجيد تقنياً ليس بالضرورة أن يُستخدم. يجب على مالك المنتج التأكد من أن الوكيل يتناسب مع إيقاع العمل الفعلي: هل مخرجاته قابلة للاستخدام، هل التسليم إلى البشر واضح، هل المشرف غير مثقل بالمراجعة المفرطة، هل يثق المستخدمون في الأدلة المعروضة. هذا مهم جداً لأن العديد من الوكلاء يفشلون ليس بسبب سوء النموذج، ولكن بسبب عدم ملاءمة تصميم العمل اليومي.

رابعاً، دورة الحياة وملكية المقاييس (Lifecycle and Metric Ownership). يجب على مالك منتج الوكيل معاملة الوكيل كمنتج له دورة حياة: تجريبي، إنتاج محدود، توسيع النطاق، تحسين، أو تقاعد. يجب عليه أيضاً أن يمسك بالمقاييس ذات الصلة، مثل معدل التبني، ومعدل القبول، ومعدل التصحيح، ومعدل التصعيد، وتأثير زمن الدورة، والنتيجة التجارية لكل سير عمل.

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

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

مشرف الوكيل ومالك المخاطر: الإنتاجية لا ينبغي أن تضحي بالثقة

بمجرد أن يبدأ الوكيل في العمل ضمن العمليات، تحتاج الشركات إلى دورين غالباً ما يُساء فهمهما على أنهما شيء واحد، بينما هما مختلفان: مشرف الوكيل (Agent Supervisor) ومالك مخاطر الوكيل (Agent Risk Owner). يجب أن يعمل الاثنان بشكل وثيق جداً، لكن صلاحياتهما ليست متطابقة.

مشرف الوكيل: المشرف على العمل اليومي للوكيل

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

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

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

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

مالك مخاطر الوكيل: مالك حدود الثقة

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

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

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

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

مهندس المنصة ومنسق المعرفة: الأساس التقني والسياق التجاري

تركز العديد من المؤسسات بشكل مفرط على النموذج والمطالبة (prompt)، ثم تنسى أن الوكيل في المؤسسة لن يكون أفضل من المنصة التي يعمل عليها والسياق التجاري الذي يفهمه. لذلك، هناك دورين مهمين للغاية: مهندس منصة الوكيل (Agent Platform Engineer) ومنسق المعرفة (Knowledge Curator).

مهندس منصة الوكيل: بناء طبقة تنفيذ يمكن الوثوق بها

مهندس منصة الوكيل مسؤول عن الأساس التقني الذي يجعل الوكيل قادراً على العمل بشكل آمن وقابل للتوسع وقابل للتشغيل. تشمل صلاحياته عادةً وقت التشغيل والتنسيق (runtime and orchestration)، وسجل الأدوات وتنفيذها، وإدارة الهوية والوصول (IAM) والتحكم في الوصول، وقابلية المراقبة والتتبع (observability and tracing)، وخط أنابيب النشر، وإدارة البيئة، والتحكم في التراجع والإصدار، والتكامل مع أنظمة ERP و CRM و HRIS و ITSM والأنظمة الأساسية الأخرى.

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

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

منسق المعرفة: ضمان فهم الوكيل للأعمال بشكل صحيح

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

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

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

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

تصميم تنظيم إنساني-وكيل معقول

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

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

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

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

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

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

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

الآثار العملية

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

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

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