وكلاء الذكاء الاصطناعي وأنظمة ERP: ما يحتاج مشغّلو الخليج معرفته

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

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

ما هي وكلاء الذكاء الاصطناعي فعلاً — وما ليسوا عليه

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

تلك الجملة الأخيرة هي مصدر الإثارة. وهي أيضاً مصدر المخاطرة.

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

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

لماذا يُغيّر منظّم المهام المفتوح من Google منحنى التكلفة دون أن يُغيّر معادلة الجاهزية

منصة AX من Google (agentexecutor.io) بنية تحتية مفيدة فعلاً ^[1]. تعزل مهام الوكلاء، وتدير إعداد بيئة العمل، وتفرض سياسات الشبكة، وتتيح للمشغّلين تشغيل المهام على نطاق واسع — مليارات المهام لكل مجموعة حواسيب وفقاً لوثائق المشروع. إنها مفتوحة المصدر، تحتضنها شركة تمتلك الموارد اللازمة لإبقائها حية، وتخفّض تكلفة بناء البنية التحتية للوكلاء بشكل ملموس ^[2].

ما لا تفعله: لا تُصلح بياناتك. لا تحدد مساراتك. لا تُوفّق بين الأوراق الإلكترونية السبعة عشر التي يستخدمها فريق اللوجستيك لتتبع مواعيد الشحن في رمضان. لا تردم الهوة بين سلسلة موافقات WhatsApp وهرمية أوامر الشراء الرسمية في ERP.

يعكس النقاش على Hacker News حول إطلاق AX الحالة الصادقة للمنظومة البيئية بدقة: يُشير الممارسون إلى غياب أي تقارب حقيقي حتى الآن، وأن "كل شخص وجارته كتب إطار عمل جديداً للوكلاء"، وأن الأدوات تتضاعف أسرع من الجاهزية التشغيلية لاستخدامها ^[2]. البنية التحتية الأرخص شرط ضروري لاعتماد الوكلاء. لكنها بعيدة كل البعد عن الكفاية.

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

شروط ERP الثلاثة التي يحتاجها الوكيل قبل أن يعمل بشكل موثوق

يُحدد تحليل McKinsey — المستشهد به في أبحاث التكامل لدى OpenText — المشكلة الجوهرية مباشرةً: الطموحات المتعلقة بالذكاء الاصطناعي تتسارع بوتيرة أعلى من الأسس التشغيلية المفترض أن تدعمها ^[3]. تتكاثر المشاريع التجريبية؛ بينما يظل التأثير التجاري المستدام محدوداً وغير متكافئ. السبب ليس جودة النماذج. السبب أن العمليات المؤسسية الأساسية مجزأة، وحوكمتها متضاربة، وتغييرها عسير ^[3].

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

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

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

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

الهوة في مجال التكامل بمنطقة الشرق الأوسط وشمال أفريقيا موثقة جيداً. تُشكّل الشركات الصغيرة والمتوسطة 80 إلى 90% من شركات القطاع الخاص في المنطقة، ولا تزال معظمها تفتقر إلى خبرة التكامل ^[4]. تُقدَّر إنفاقات تقنية المعلومات في المنطقة بـ 169 مليار دولار في 2026 ^[4]، لكن الاستثمار في أنظمة جديدة دون خطة لربطها يخلق مزيداً من الصوامع لا أقل. كل أداة تُضاف دون استراتيجية تكامل تجعل تشغيل العمل أصعب — ونشر وكيل دون جاهزية تكامل ليس سوى النسخة الأغلى ثمناً من هذا الخطأ.

أين تُحقق الوكلاء نتائج فعلية في عمليات الخليج — وأين تفشل

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

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

إعادة طلب المخزون في التوزيع مع تغذيات حية من نظام إدارة المستودعات. حيث يُغذّي نظام إدارة المستودعات (WMS) الـ ERP في الوقت الفعلي وتُحدَّد منطق إعادة الطلب حسب رمز المخزون (SKU)، يستطيع الوكيل رفع طلبات شراء مسودة وإخطار المشترين دون لمس جدول إلكتروني واحد. الشرط المسبق هو أن يكون تكامل WMS مع Business Central حياً ومرتبطاً بالأحداث.

توجيه سير العمل لسلاسل الموافقة المنظمة. حيث تكون هرميات الموافقة مُقنَّنة في ERP أو طبقة BPM متصلة به، يستطيع الوكيل توجيه المستندات، ومتابعة أصحاب الصلاحية، والتصعيد بشكل صحيح. حيث تسكن الموافقات في WhatsApp، ينهار الوكيل عند أول استثناء.

أين تفشل الوكلاء باستمرار في السياق الخليجي:

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

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

12% فقط من الرؤساء التنفيذيين على مستوى العالم يقولون إن الذكاء الاصطناعي حقق لهم فوائد على صعيدي التكلفة والإيراد معاً ^[4]. هذا الرقم ليس إدانةً للذكاء الاصطناعي. إنه إدانة لنشر الذكاء الاصطناعي قبل أن تكون طبقة التكامل جاهزة.

رأي تارسين: أجرِ مراجعة التكامل قبل التجربة الأولى للوكيل

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

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

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

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

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

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

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

موردو الوكلاء لن يخبروك بالجزء الثاني. نحن نتقاضى الأجر ذاته في الحالتين.