ما هي هندسة المؤسسات العاملة بالوكلاء

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

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

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

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

لماذا هذا ليس مجرد روبوت محادثة أكثر ذكاءً

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

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

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

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

ثلاثة أشياء تميز الوكيل عن روبوت المحادثة

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

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

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

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

إذن، هندسة المؤسسات العاملة بالوكلاء لا تتعلق ببناء وكيل خارق واحد يعرف كل شيء. الهدف هو بناء نظام بيئي من الوكلاء يمكن التحكم فيه، وهو معياري (modular)، وقابل للتوسع.

الطبقات الثلاث التي تشكل الهندسة

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

طبقة الوكيل: من يفعل ماذا

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

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

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

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

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

فصل الأدوار بهذه الطريقة مهم لأنه يسهل تصميم الضوابط والاختبار وتحديد المسؤولية (ownership).

طبقة السياق: كيف يفهم الوكيل عالم الشركة

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

تبدأ العديد من المؤسسات بـ (Retrieval-Augmented Generation) RAG لإعطاء الوكيل وصولًا إلى المستندات، وإجراءات التشغيل القياسية (SOPs)، والسياسات، والأدلة، أو قواعد المعرفة. هذه خطوة أولى معقولة، خاصة لحالات الاستخدام كثيفة المعرفة مثل مكتب خدمة العملاء، أو العمليات القانونية، أو دعم السياسات. لكن RAG وحده غالبًا لا يكفي للعمليات المؤسسية المعقدة.

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

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

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

طبقة التحكم: كيف تبقى الشركة مسيطرة

كلما انتقل الوكيل من الإجابة إلى التصرف، زادت أهمية طبقة التحكم. هذه ليست إضافة امتثالية (compliance accessory). إنها جوهر الهندسة.

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

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

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

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

مبادئ التصميم التي تميز الهندسة الصحية عن الهشة

بعد فهم المكونات، السؤال التالي هو: ما هي مبادئ التصميم التي تميز الهندسة الصحية عن الهشة؟

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

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

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

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

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

أمثلة على التطبيق في سير عمل المؤسسة

لن يكون الأمر مجردًا جدًا، دعنا نلقي نظرة على بعض الأمثلة السريعة.

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

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

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

الأخطاء الشائعة التي تحدث غالبًا

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

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

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

ليست كل العمليات تحتاج إلى وكيل. بالنسبة للعمليات شديدة الحتمية (highly deterministic)، يمكن أن يكون سير العمل العادي أو الأتمتة التقليدية أرخص وأسرع وأكثر قابلية للتنبؤ. نمط الوكيل (Agentic pattern) هو الأنسب عندما يكون هناك مزيج من السياق الديناميكي، والاستثناءات العالية، والحاجة إلى التنسيق عبر الأنظمة.

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

الآثار المترتبة على كبار مسؤولي المعلومات (CIO)، وكبار مسؤولي العمليات (COO)، وقادة التحول

بالنسبة لـ CIO، يعني هذا الموضوع أن هندسة المؤسسة لم يعد بإمكانها الاكتفاء بالحديث عن التطبيقات والبيانات والتكامل. الآن، يجب أن يكون هناك منظور صريح حول طبقة العمل الرقمي (digital labor layer): نوع الوكيل، هويته، صلاحيات وصوله، ودورة حياته.

بالنسبة لـ COO، هذا يعني أن إعادة تصميم العملية لا يمكن أن تتوقف عند تبسيط سير العمل. السؤال يتغير إلى: أي جزء من تدفق القيمة (value stream) سينفذه البشر، وأي جزء سينفذه الوكيل، وما هي نقاط التحكم التي يجب الحفاظ عليها.

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

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

أسئلة يجب أن تأخذها معك

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

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