وكلاء Copilot في Dynamics 365: الحدود الحقيقية في 2025

يعرض أحد شركاء Microsoft عرضاً توضيحياً لوكيل الذمم الدائنة في Business Central. تتطابق الفواتير تلقائياً، وتظهر الاستثناءات في لوحة جانبية، ويكتفي المعتمِد بنقرة واحدة. يُومئ الحضور بالموافقة. ثم يسأل أحدهم: "ماذا يحدث حين يرسل مورّدنا ملف PDF بالعربية يحتوي على حقل مخصص أضافه فريق المالية لدينا قبل ثلاث سنوات؟" ينتهي العرض. ويبدأ المشروع الحقيقي.

تلك الهوّة بين العرض التوضيحي المصقول وواقع العمليات الفعلي هي ما يكلّف مشغّلي منطقة الخليج أشهراً وميزانيات في 2025. تُرسم في هذا المقال حدود القدرة الفعلية لوكلاء Dynamics 365 الأصليين من Microsoft، ويُفحص فيه ما يقدّمه خادم MCP وCopilot Studio من قيمة حقيقية، مع أربعة أسئلة ينبغي طرحها قبل الرهان على أيٍّ منها في سير عملٍ بعينه.

ما تفعله وكلاء Business Central من Microsoft فعلياً خارج الصندوق

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

تتولى وكلاء أصليون آخرون إعداد ملخصات الحسابات، وتلخيص حالات خدمة العملاء، ومطابقة الذمم الدائنة داخل Business Central. والكلمة المفتاحية هي "قياسي." يجب أن ينال الوكلاء الأصليون الأولوية في المراجعة حين يقع الطلب بالكامل داخل سير عمل وحدة المبيعات أو خدمة العملاء أو المالية أو أي وحدة ذات صلة مدعومة ^[1]. فهم ليسوا محركات استدلال للأغراض العامة، بل يعملون داخل حدود معرَّفة يضعها Microsoft لا أنت.

تُعمّق موجة الإصدار الثانية لعام 2025، المخطط لها بين أكتوبر 2025 ومارس 2026، تكامل Azure AI Foundry عبر هؤلاء الوكلاء، وتُطلق ميزة "Create with Copilot" لبناء رحلات العملاء — وهي ميزة يصفها Microsoft نفسه بأنها الأنسب لسير العمل الأبسط في هذه المرحلة ^[2]. خريطة الطريق تتقدم بسرعة. أما مساحة الإنتاج الجاهزة فلا تزال ضيّقة.

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

أين تصطدم بجدار التوسعة: الذمم الدائنة وMCP وواقع Copilot Studio

قصة التوسعة أكثر تفاؤلاً على الورق منها على أرض الواقع. تتيح منصة المالية والعمليات من Microsoft إنشاء أدوات ذكاء اصطناعي تمتد قدرات الوكلاء — فئات X++ مزيّنة بسمات محددة يمكن للوكيل اكتشافها واستدعاؤها عبر خادم Model Context Protocol ^[3]. يُتيح خادم MCP بعد ذلك تلك الفئات من خلال أدوات find_actions وinvoke_action تلقائياً، بمجرد نشر الفئة وتهيئة عنصر قائمة الأمان ^[3].

هذه بنية مفيدة فعلاً. لكن اقرأ التفاصيل بعناية. كل توسعة مخصصة تستلزم: مطوراً يكتب كود X++ في البيئة، وتهيئة أمان مناسبة لعنصر إجراء القائمة المرتبط، وفي حال عدم استخدام مسار خادم MCP، كائنات Dataverse منفصلة وتوصيلات Copilot Studio مبنية بشكل موازٍ ^[3]. لا شيء من ذلك يتم بنقر وتحديد. ولا شيء منه سريع.

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

ثلاث طبقات للذكاء الاصطناعي موجودة في منظومة Microsoft، وتنطلق كلٌّ منها من نقطة مختلفة ^[1]: وكلاء D365 الأصليون ينطلقون من سيناريو عمل مدعوم؛ وCopilot Cowork ينطلق من عمل يريد المستخدم تفويضه عبر Microsoft 365 وD365؛ وCopilot Studio ينطلق من عملية تحتاج المنظمة إلى تصميمها أو توسيعها. اختيار الطبقة الخاطئة لا يعني مجرد إعادة العمل. بل يشكّل الحوكمة والترخيص والدعم والبنية المخصصة المستمرة التي يجب على فريقك امتلاكها.

إعداد Copilot Studio: الجهد والترخيص وما لا تزال لا تتحكم فيه

Copilot Studio هو الوجهة التي يصل إليها النقاش عادةً حين تُخفق الوكلاء الأصليون. إنه الأداة المناسبة للتنسيق متعدد الأنظمة — سلسلة اعتماد تلمس D365 ورسالة Teams وERP خارجي وبوابة مورّد في آنٍ واحد. لكن "الأداة المناسبة" لا تعني "السهلة" أو "الرخيصة."

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

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

ما لا تزال لا تتحكم فيه من خلال Copilot Studio: تحديثات نموذج Microsoft، والتوافر الإقليمي للقدرات المحددة، وحوكمة البيانات الأساسية لما يراه الوكيل ويخزّنه. بالنسبة لمشغّلي الخليج الذين لديهم متطلبات إقامة البيانات — الإمارات والمملكة العربية السعودية — هذه ليست مخاوف نظرية. إنها قيود امتثال تتطلب إجابات قبل النشر لا بعده.

أربعة أسئلة تطرحها قبل الرهان على وكيل D365 أصلي في سير عمل

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

1. هل يعيش سير العمل هذا بالكامل داخل وحدة D365 مدعومة واحدة؟ إن لمست العملية نظاماً خارجياً — بوابة لوجستية لجهة خارجية، أو ERP خاص بالمورّد، أو بوابة دفع مصرف إقليمي — فالوكيل الأصلي لا يستطيع إغلاق الحلقة. ارسم كل تسليم بيانات قبل تقييم تغطية الوكيل.

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

3. هل تُعدّ إقامة البيانات أو السيادة عليها مهمة لهذه العملية؟ يتفاوت توافر القدرات الإقليمية لوكلاء D365 ^[1]. إن كان يجب أن تبقى بيانات مالياتك داخل البلاد وفقاً للمتطلبات التنظيمية الإماراتية أو السعودية، فأنت بحاجة إلى تأكيد خطي بشأن التعامل مع البيانات — لا ضمان شفهياً من مهندس ما قبل البيع.

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

مقارنة الطبقات الثلاث للذكاء الاصطناعي: مرجع عملي

| الطبقة | الأنسب لـ | يستلزم | القيد الرئيسي | |---|---|---|---| | وكيل D365 الأصلي | سير العمل القياسي داخل الوحدة | ترخيص + تفعيل | نطاق سيناريو ثابت | | Copilot Cowork | التفويض على مستوى المستخدم عبر M365 + D365 | ترخيص M365 Copilot | لا منطق عملية مخصص | | Copilot Studio | التنسيق المخصص متعدد الأنظمة | تصميم وبناء وصيانة | تكلفة لكل رسالة + ملكية مستمرة |

القرار ليس أي الطبقات أفضل من الناحية المجردة — بل أيها يطابق ما تتطلبه عمليتك تحديداً. معظم تقييمات ERP في الخليج التي نراها تتخطى هذه المقارنة كلياً وتقفز مباشرةً إلى عرض توضيحي من المورّد. هذا هو الشكل المكلف من منحنى التعلم. للاطلاع على مقارنة أشمل لأداء D365 Copilot مقابل ما تعد به العروض التوضيحية، انظر تحليلنا الواقعي لـ Copilot لـ Dynamics 365.

رأي تارسين: الوكلاء الأصليون نقطة بداية لا خط نهاية

وكلاء D365 الأصليون من Microsoft مفيدون فعلاً للسيناريوهات التي يغطّونها. لسنا نجادل في مواجهتهم. نجادل في مواجهة الافتراض القائل إن "لدينا D365 وقد أطلق Microsoft وكيلاً" يعني أن سير العمل قد حُلَّ.

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

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

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

إن أردت أن تفهم أين تقع سير عمل D365 لديك على طيف الأصلي إلى المخصص — وما يكلّفه ذلك واقعياً لسدّ الفجوة — ابدأ بالتدقيق. جدار التوسعة ليس سبباً لتجنب وكلاء Microsoft. إنه سبب لمعرفة موضعه بالضبط قبل أن تبني نحوه.

لمشغّلي الخليج الذين يقيّمون أيضاً كيف تتمايز Dynamics عن SAP وOdoo في قدرات الذكاء الاصطناعي، يتناول تحليلنا لميزات الذكاء الاصطناعي في Odoo مقابل SAP النهجَ ذاته القائم على السقف الصادق عبر المنصات المنافسة. وإن كنت تواجه ضغطاً نحو ترحيل المنصة لإتاحة ميزات الذكاء الاصطناعي، فإن مقال FOMO الخاص بـ SAP RISE AI قراءة لازمة قبل أن تتعمق تلك المحادثة.

العرض التوضيحي سيبدو دائماً نظيفاً. العملية لا تكون كذلك أبداً.

— Mohammed Z