إنتقل إلى المحتوى الرئيسي

خارطة طريق 90 يوماً لبناء نموذج تجريبي لمؤسسة وكيلة (Agentic Enterprise Pilot)

رسم بياني: خارطة طريق 90 يوماً لبناء نموذج تجريبي لمؤسسة وكيلة

لقد تجاوزت العديد من الشركات مرحلة الفضول تجاه الذكاء الاصطناعي. تم تجربة الأدوات، واستخدام المساعدين الرقميين (copilots)، وتقديم العديد من نماذج الإثبات (proofs of concept). لكن السؤال الأكثر أهمية الآن لم يعد "هل الذكاء الاصطناعي الوكيل (agentic AI) مثير للاهتمام؟" بل: كيف نبني نموذجاً تجريبياً (pilot) واقعياً بما يكفي لإثبات القيمة، وآمناً بما يكفي للتشغيل، ومنضبطاً بما يكفي ليكون أساساً للتوسع؟

هنا تتعثر العديد من المؤسسات. فهي إما تبني نماذج أولية (demos) بسرعة كبيرة دون خط أساس (baseline)، أو على العكس، تطيل أمد وضع الاستراتيجيات لدرجة أنها لا تصل أبداً إلى سير عمل (workflow) حقيقي. والحقيقة أن التحول الوكيل (agentic transformation) لن يولد من العروض التقديمية. إنه يولد من نموذج تجريبي تشغيلي محدد جيداً، ومُقاس بدقة، ومُراجع بأمانة.

تختتم هذه المقالة سلسلة النقاشات حول نموذج التشغيل (operating model)، والقوى العاملة (workforce)، والمقاييس (metrics)، والحوكمة (governance) بهدف عملي واحد: تقديم خطة مدتها 90 يوماً لبناء نموذج تجريبي لمؤسسة وكيلة قابل للقياس وآمن.

مبدأها الأساسي بسيط: ابدأ بمجال واحد ذي قيمة، وحدد النطاق (scope) للسيطرة على المخاطر، وصمم الوكيل (agent) وعناصر التحكم (controls) بشكل صريح، واختبر على سير عمل حقيقي وليس فقط على مطالبات (prompts)، ثم اتخذ قرار التوسع (scale)، أو إعادة التصميم (redesign)، أو الإيقاف (stop) بناءً على الأدلة.

خارطة الطريق هذه ليست وصفة عالمية. إنها الأنسب للشركات التي لديها بالفعل عمليات أساسية مستقرة بما فيه الكفاية، وراعي أعمال (business sponsor) واضح، واستعداد أدنى في مجالات البيانات والتكامل والحوكمة. إذا لم تكن هذه الأسس موجودة بعد، فإن الـ 90 يوماً تظل مفيدة - ولكن النتيجة قد لا تكون نموذجاً تجريبياً حياً، بل قراراً واعياً بأن الشركة تحتاج إلى تحسين أسسها أولاً.

لماذا 90 يوماً هي الأفق الزمني المناسب​

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

في غضون 90 يوماً، يجب أن تكون الشركة قادرة على الإجابة عن خمسة أسئلة جوهرية. أولاً، هل سير العمل المختار يمتلك بالفعل مجموعة قيمة (value pool) حقيقية؟ ثانياً، هل يمكن للوكيل العمل ضمن حدود الاستقلالية (autonomy) الآمنة؟ ثالثاً، هل المستخدمون يستفيدون حقاً، وليس فقط منبهرين؟ رابعاً، هل عناصر التحكم، وسجل التدقيق (audit trail)، والمراقبة (monitoring) كافية للإنتاج المحدود؟ خامساً، هل الجدوى الاقتصادية (economics) وملاءمة التشغيل (operating fit) قوية بما يكفي للتوسع؟

إذا لم يكن بالإمكان الإجابة عن هذه الأسئلة الخمسة، فإن المؤسسة لا تملك بعد أساساً سليماً لتوسيع النموذج الوكيل إلى مجالات أخرى.

الأيام 1–15: اختر المجال المناسب وابنِ خط الأساس​

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

المجال الجيد للنموذج التجريبي عادة ما يتميز بالخصائص التالية: سير العمل متكرر بما فيه الكفاية، وهناك اختناق (bottleneck) أو تراكم عمل (backlog) حقيقي، والعديد من عمليات التسليم اليدوية (handoffs) أو معالجة الاستثناءات (exception handling)، وأنظمة المصدر والبيانات يمكن الوصول إليها نسبياً، ومالك العملية (process owner) واضح، وفشل النموذج التجريبي لا يخلق مباشرة مخاطر جوهرية لا يمكن السيطرة عليها.

من الأمثلة التي غالباً ما تكون منطقية: دعم إقفال الحسابات المالية (finance close support) لجمع الأدلة، وفرز التباينات (variance triage)، وكتابة التعليقات الأولية (draft commentary)؛ وإدارة طلبات المشتريات (procurement intake) لتصنيف الطلبات، والتحقق من السياسات، والتوجيه (routing)؛ وعمليات العملاء (customer operations) لتلخيص الحالات، وصياغة الردود، وفرز التصعيد (escalation triage)؛ وعمليات تقنية المعلومات (IT operations) لفرز الحوادث (incident triage)، والتوصية بدليل التشغيل (runbook recommendation)، والتحقق من جاهزية التغيير (change readiness check)؛ ومعالجة استثناءات سلسلة التوريد (supply chain exception handling) لاكتشاف الاستثناءات، وتجميع السياق، وتقديم توصيات التخفيف الأولية؛ بالإضافة إلى الخدمات المشتركة (shared services) أو مراكز الخدمات المشتركة (GCC) التي تتميز بحجم كبير، وعمليات موحدة نسبياً، وحوكمة أسهل للتمركز.

على العكس من ذلك، تجنب في البداية المجالات التي لا تزال عملياتها الأساسية فوضوية، أو سياساتها غير موثقة، أو بياناتها مبعثرة بدون مالك، أو تلك التي تمس قرارات جوهرية ليس لها حواجز حماية (guardrails) واضحة.

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

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

في الإقفال المالي، الأرقام موجودة بالفعل في نظام ERP أو أداة الدمج (consolidation tool)، لكن الفريق لا يزال يتعين عليه ملاحقة المدخلات، وجمع الأدلة، ووضع علامات على التباينات، وصياغة شرح أولي. قد لا يحتاج الوكيل إلى إقفال الدفاتر، لكنه قد يكون مفيداً جداً في التنسيق (orchestration) والفرز (triage).

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

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

الأيام 16–35: تصميم الوكيل، حدود الاستقلالية، وعناصر التحكم​

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

يجب أن يكون لكل نموذج تجريبي بطاقة وكيل (agent card) - وهي وثيقة موجزة تصف الهوية التشغيلية للوكيل. يجب أن تتضمن على الأقل: الهدف أو النتيجة المرجوة، والنطاق أو الحالات التي يُسمح للوكيل ولا يُسمح له بمعالجتها، والأدوات (tools) مثل واجهات برمجة التطبيقات (APIs)، أو الأنظمة، أو محرك سير العمل (workflow engine) التي يُسمح باستدعائها، ومصادر البيانات (data sources) مثل قاعدة المعرفة (knowledge base)، أو نظام ERP، أو CRM، أو نظام التذاكر (ticketing)، أو وثائق السياسات، والمالك (owner) الذي يشمل مالك الأعمال، ومالك المنتج أو الوكيل، ومالك المخاطر، ومستوى المخاطرة (risk tier) منخفض أو متوسط أو مرتفع حسب التأثير، بالإضافة إلى معايير النجاح (success criteria) المتمثلة في مقاييس القيمة والجودة والتبني والمخاطر.

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

أحد أهم القرارات في أول 90 يوماً هو إلى أي مدى يُسمح للوكيل بالتصرف. التسلسل الصحي عادة ما يبدأ من القراءة أو المراقبة (read/monitor) حيث يقرأ الوكيل البيانات فقط ويقدم رؤى (insights). ثم المسودة أو التوصية (draft/recommend) حيث يعد الوكيل ملخصات أو توصيات أو إجراءات مقترحة. ثم التنفيذ بعد الاعتماد (execute with approval) حيث ينفذ الوكيل الإجراء بعد موافقة بشرية. وأخيراً التنفيذ مع المراقبة (execute with monitoring) وهو فقط للإجراءات منخفضة المخاطر وذات الحدود الواضحة جداً.

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

النموذج التجريبي الوكيل الصحي لديه دائماً إجابات واضحة لثلاثة أسئلة: متى يجب على الإنسان الموافقة؟ ومتى يجب تصعيد الحالة؟ وما الذي يجب تسجيله للتدقيق؟ يمكن أن تستند عتبة الاعتماد (approval threshold) إلى قيمة المعاملة، أو ثقة الوكيل، أو نوع الحالة، أو حساسية البيانات، أو التأثير التشغيلي. يجب أن يشير مسار التصعيد (escalation path) إلى دور حقيقي، وليس صندوقاً تنظيمياً مجرداً، مثل مشرف الحسابات الدائنة (AP supervisor)، أو المراقب الإقليمي (regional controller)، أو قائد عمليات المشتريات (procurement operations lead)، أو مدير الحوادث (incident manager)، أو مخطط سلسلة التوريد المناوب (supply chain planner on duty). تشمل متطلبات التدقيق (audit requirements) الدنيا عادةً: مصدر البيانات المستخدم، والأداة أو API التي تم استدعاؤها، والسياسة أو المعرفة التي تم الرجوع إليها، ومخرجات الوكيل، والقرار البشري، والنتيجة النهائية.

تفشل العديد من النماذج التجريبية ليس بسبب سوء النموذج، بل لأن الأسس التشغيلية لم تكن جاهزة بعد. هناك أربعة مكونات دنيا يجب أن تكون موجودة: قاعدة المعرفة (knowledge base)، والوصول إلى واجهات برمجة التطبيقات (API access)، وسجل الأدوات (tool registry)، وبيئة الاختبار المعزولة (sandbox environment).

تحتوي قاعدة المعرفة على وثائق إجراءات التشغيل القياسية (SOPs)، والسياسات، والأسئلة الشائعة (FAQ)، وأدلة التشغيل (runbooks)، أو تاريخ الحالات الذي تم تنظيفه بشكل كافٍ. لا تتوقع أن يعمل الاسترجاع (retrieval) بشكل جيد إذا كانت المعرفة لا تزال فوضوية. يجب أن يكون الوصول إلى API للأنظمة الأساسية محدوداً ووفقاً للحاجة. لا يحتاج النموذج التجريبي إلى جميع التكاملات، فقط تلك التي تحدد النتيجة حقاً. سجل الأدوات هو قائمة بالأدوات التي يُسمح للوكيل باستدعائها، مع حقوق الوصول وحدود الاستخدام. هذا مهم لمنع انتشار الأدوات (tool sprawl) ومخاطر الوصول غير المنضبط. بيئة الاختبار المعزولة هي بيئة اختبار واقعية بما يكفي لتجربة سير العمل دون لمس الإنتاج بتهور.

المقايضة (trade-off) في هذه المرحلة واضحة: كلما أراد الفريق الانتقال إلى الإنتاج المباشر (live) بشكل أسرع، زاد إغراء تقليص تصميم عناصر التحكم. وهذا يكاد يكون دائماً ديناً مكلفاً في الأسابيع التالية.

الأيام 36–65: بناء الحد الأدنى من المنتج القابل للتطبيق (MVP) والاختبار الجاد​

المرحلة الثالثة هي عندما تشعر العديد من المؤسسات بأنها قد أنجزت المهمة بسرعة كبيرة جداً. في حين أن MVP الوكيل ليس روبوت محادثة (chatbot) يمكنه الإجابة. MVP هو سير عمل ضيق يعمل حقاً على حالات حقيقية.

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

قبل تشغيل النموذج التجريبي المباشر، يجب اختبار الوكيل على حالات تاريخية. هذا مهم لأن البيانات التاريخية تظهر واقع الاستثناءات والضوضاء والغموض التي لا تظهر في العروض التوضيحية. استخدم عدة أنواع من الاختبارات. اختبار الحالات التاريخية (Historical case testing) لمعرفة ما إذا كان الوكيل يقدم مخرجات قابلة للاستخدام في الحالات التي حدثت بالفعل. السيناريوهات العدائية (Adversarial scenarios) لمعرفة ما يحدث إذا كانت المستندات غير مكتملة، أو البيانات متضاربة، أو المطالبات (prompts) غامضة، أو حاول المستخدم إجبار الوكيل على الخروج من النطاق. فحوصات السياسات (Policy checks) للتأكد من أن الوكيل يظل ملتزماً بالعتبات وقواعد الاعتماد وحدود الوصول. المراجعة البشرية (Human review) لتقييم ما إذا كانت مخرجات الوكيل تساعد المراجع حقاً أم تزيد من عبء العمل.

في الممارسة العملية، يدور تكرار النموذج التجريبي عادةً حول أربعة مجالات. أولاً، تصميم المطالبات والتعليمات (prompt and instruction design): هل يفهم الوكيل الهدف، وتنسيق المخرجات، وحدود أفعاله؟ ثانياً، الاسترجاع (retrieval): هل المعرفة المسترجعة ذات صلة، وحديثة، ومحددة بما فيه الكفاية؟ ثالثاً، مخطط الأداة (tool schema): هل معلمات API، وهيكل الإدخال والإخراج، ومعالجة الأخطاء واضحة بما فيه الكفاية؟ رابعاً، حواجز الحماية (guardrails): هل يعرف الوكيل متى يتوقف، أو يطلب الموافقة، أو يصعد الأمر؟

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

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

الأيام 66–90: تشغيل النموذج التجريبي المحدود، المراقبة الدقيقة، واتخاذ القرار​

المرحلة الأخيرة هي لحظة الإثبات. لم تعد في المختبر، بل في عملية تشغيلية محدودة.

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

أثناء تشغيل النموذج التجريبي المباشر، قم بقياس خمسة أبعاد على الأقل. القيمة (Value): هل تحسن زمن الدورة، أو التراكم، أو الإنتاجية (throughput) مقارنة بخط الأساس؟ الجودة (Quality): ما هو معدل التصحيح، ومعدل القبول، وجودة المخرجات القابلة للاستخدام حقاً؟ المخاطرة (Risk): هل هناك أي انحراف عن السياسات، أو وصول غير مناسب، أو قرارات كان ينبغي ألا يتخذها الوكيل؟ التبني (Adoption): هل يستخدم المستخدمون الوكيل حقاً ويشعرون أنهم استفادوا؟ التكلفة (Cost): ما هي التكلفة لكل نتيجة ناجحة، وهل الجدوى الاقتصادية معقولة للتوسع؟

هنا تصبح المقالات السابقة حول المقاييس ونموذج التشغيل القائم على النتائج (outcome-based operating model) ذات صلة كبيرة: لا ينبغي تقييم النموذج التجريبي فقط من خلال عمل الوكيل أو إعجاب المستخدم به. يجب تقييمه كجزء من نموذج التشغيل.

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

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

ما الذي يتسبب غالباً في فشل النموذج التجريبي لمدة 90 يوماً​

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

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

عادةً ما تكون الشركات الأكثر فعالية في التحرك ليست الأكثر عدوانية، بل الأكثر انضباطاً في ربط سير العمل، وعناصر التحكم، والمقاييس، والقرارات.

قائمة مراجعة عملية​

القرارات التي يجب اتخاذها الآن​

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

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

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

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

حدد بوابة المرحلة (stage-gate) في اليوم التسعين. منذ البداية، اتفق على أن النموذج التجريبي يجب أن ينتهي بقرار: التوسع، أو إعادة التصميم، أو الإيقاف.

قائمة مراجعة الجاهزية المختصرة​

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

إشارات الخطر التي تشير إلى أن النموذج التجريبي ليس جاهزاً للتوسع​

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

أسئلة تأملية لمديري تقنية المعلومات (CIO)، والعمليات (COO)، والموارد البشرية (CHRO)، وقادة التحول​

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

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