وكلاء الذكاء الاصطناعي في Dynamics 365: تحوّل حقيقي أم مجرد ضجيج؟

مدير المشتريات في إحدى شركات التداول بجبل علي يوقّع على تجديد ترخيص Copilot. نسخته من Dynamics 365 تعمل منذ أربع سنوات — انتقلت إلى السحابة عام 2021، وخضعت لتخصيص مكثّف على يد شريك تنفيذي استُبدل منذ ذلك الحين، ويدعمها فريق يدير ثلاث سلاسل موافقات متوازية عبر WhatsApp والبريد الإلكتروني والنظام نفسه. الوكلاء (Agents) على وشك الانطلاق. والبيانات التي سيعملون عليها لم تخضع لأي مراجعة حتى اللحظة.

هذا هو الواقع في عدد مفاجئ من مؤسسات منطقة الخليج اليوم. الحديث عن وكلاء الذكاء الاصطناعي في Microsoft Dynamics 365 صاخب. أما الحديث عن مدى استعداد هذه المؤسسات لهم، فيكاد يكون معدوماً.

ما الذي تغيّر فعلاً حين انتقل Dynamics إلى السحابة — وما الذي لم يتغيّر

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

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

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

ما يستطيع وكلاء الذكاء الاصطناعي داخل Dynamics 365 فعله وما لا يستطيعون اليوم

تمتد قدرات Microsoft الحالية للوكلاء عبر ERP وCRM: Dynamics 365 Finance وSupply Chain Management وSales وCustomer Service وField Service، وكلها تحمل مزيجاً من تجارب Copilot وإجراءات الوكلاء المستقلة. ^[1] تتولى طبقة Copilot التلخيص والاقتراحات والإرشاد السياقي. أما طبقة الوكلاء فتذهب أبعد — إذ تنفّذ إجراءات في النظام، لا تكتفي بالإبلاغ عنها.

بروتوكول سياق النموذج (Model Context Protocol - MCP)، الذي أُدرج مؤخراً في D365 Finance & Supply Chain Management، يوسّع توسيعاً ملحوظاً ما يمكن للوكلاء فعله داخل المنصة. ^[2] أصبح بإمكان الوكلاء الآن التفاعل مع نطاق أوسع من وظائف النظام مقارنةً بإصدارات Copilot السابقة.

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

الشروط الثلاثة للتنفيذ التي تحدد ما إذا كان الوكلاء مفيدين أم ضارين

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

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

2. أمن الأدوار مُطبَّق مع انعدام تعارضات الفصل بين المهام. هذا هو الشرط الأقل فحصاً. الوكلاء يرثون حالياً صلاحيات المستخدم الذي يستدعيهم. ^[2] المستخدم الذي مُنح صلاحيات زائدة — وهو أمر يحدث باستمرار حين يعاني قسم تقنية المعلومات من نقص الكوادر وتكون "أعطهم وصولاً كاملاً" هي مسار المقاومة الأدنى — يمنح تلك الصلاحيات الزائدة للوكيل. ما كان إنساناً يتخذ قراراً خاطئاً واحداً يومياً يصبح وكيلاً يتخذ خمسين قراراً خاطئاً. Microsoft صريحة في هذا: ينبغي أن يُحكم على الوكلاء كما يُحكم على المستخدمين، لا أن يُعاملوا كميزات في الخلفية. ^[2]

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

لا يتطلب أيٌّ من هذه الشروط برامج جديدة. يتطلب انضباطاً في التنفيذ — وهو أصعب، ويستغرق وقتاً أطول، وأقل إثارةً تجارياً من شراء ترخيص Copilot.

كيف يختبر المشغّلون في الخليج جاهزيتهم قبل تفعيل Copilot

يجب أن تسبق محادثة الجاهزية محادثة الترخيص، لا أن تأتي بعدها. إليك تسلسلاً عملياً:

ابدأ بمراجعة أمنية لأدوار المستخدمين والصلاحيات. رسّم خريطة بكل دور مستخدم نشط في نسخة Dynamics لديك. حدّد الحسابات التي تتمتع بصلاحيات زائدة، والتعارضات في الفصل بين المهام، والأدوار الموجودة لأن أحداً لم يرد التعامل مع طلب إزالة الوصول. هذا العمل بلا بريق — لكنه أساسي. سجلات الوكلاء، حين تُفعّلها، ستخبرك بالصفحات والإجراءات التي وصل إليها الوكيل — استخدم ذلك لاحقاً لتشديد الصلاحيات. لكن أجرِ المراجعة أولاً. ^[2]

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

وثّق العملية التي من المفترض أن يتبّعها الوكيل. اكتبها. إن لم تستطع كتابتها لأنها تتغيّر بحسب من في المكتب أو من يطلب، فأنت لا تمتلك عملية — بل لديك عادة. الوكلاء يتّبعون العمليات، لا العادات.

اختبر في بيئة غير إنتاجية ببيانات تمثيلية. لا تُجرب الوكلاء على مجموعة بيانات تجريبية مُعقَّمة. استخدم نسخة من بياناتك الحقيقية، مجهّلة عند الضرورة، وراقب ما يفعله الوكيل فعلاً. المفاجآت ستكون مفيدة.

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

الوكلاء مضاعِف لا حلّ — رأي تارسين

تستحق قياس السحابة أن نُكمله. حين انتقل Dynamics إلى السحابة، كانت المخاطر الرئيسية تشغيلية: هل يمكنك ضمان التشغيل المستمر، وإدارة التحديثات، وضمان الاتصال؟ كانت مخاطر حقيقية، وتعاملت معها معظم المؤسسات. أما الخلل الكامن في البيانات والعمليات فقد ظلّ خفياً إلى حدٍّ بعيد، لأن السحابة لم تتفاعل معه — كانت تستضيفه فحسب.

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

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

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

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

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

السحابة غيّرت أين يعمل Dynamics. الوكلاء يغيّرون ما يقرره. هذا تحوّل أكبر — لكن فقط إن كانت قاعدتك مستعدة لتحمّل الثقل.