ربط وكلاء الذكاء الاصطناعي بأنظمة ERP وCRM وHRIS والأنظمة الأساسية

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

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

هذه ليست مسألة تتعلق بنموذج ذكاء اصطناعي غير متطور أو حالة استخدام غير جذابة. العديد من برامج الذكاء الاصطناعي العاملة بالوكلاء تتباطأ على وجه التحديد لأن الأنظمة الأساسية يصعب الوصول إليها، أو بطيئة، أو غير متسقة، أو غير آمنة للتفاعل شبه المستقل. يرى مديرو تقنية المعلومات (CIO) هذه مشكلة معمارية. ويرى مديرو العمليات (COO) هذه مشكلة في تصميم العمليات. ويرى المديرون الماليون (CFO) ومديرو الموارد البشرية (CHRO) هذه مشكلة في التحكم والمساءلة.

لماذا غالبًا ما تشكل الأنظمة الأساسية عائقًا

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

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

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

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

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

نمط التكامل الأكثر منطقية: اقرأ، أوصِ، نفّذ

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

المرحلة 1: اقرأ — الوكيل يفهم حالة الأعمال دون تغييرها

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

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

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

المرحلة 2: أوصِ — الوكيل يجهز الإجراء، والبشر يوافقون

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

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

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

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

المرحلة 3: نفّذ — الوكيل ينفذ إجراءات محدودة ضمن حدود واضحة

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

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

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

لا ينبغي للوكيل أن ينتظر حتى يُسأل

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

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

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

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

هناك نمطان شائعان غالبًا ما يكونان ذوي صلة: ناقل الأحداث (Event Bus)، حيث تنشر أنظمة المؤسسة الأحداث التشغيلية إلى منصة مشتركة ويشترك الوكيل في الأحداث ذات الصلة، وتقنية التقاط بيانات التغيير (Change Data Capture - CDC)، والتي تساعد في التقاط التغييرات على بيانات المعاملات إذا لم يكن لدى النظام الأساسي أحداث أصلية جيدة بعد.

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

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

لا تنتظر حتى تصبح جميع الأنظمة مثالية

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

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

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

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

الآثار المترتبة على النموذج التشغيلي والحوكمة

ربط الوكيل بالأنظمة الأساسية ليس مجرد مشروع وسيط (middleware). بمجرد أن يلمس الوكيل ERP أو CRM أو HRIS، تظهر بعض الآثار المترتبة على الحوكمة مباشرة.

يجب أن يكون لكل اتصال بنظام أساسي مالك تجاري ومالك تقني. لا يكفي أن "فريق التكامل هو المسؤول". يجب أن يكون واضحًا من هو مالك القدرة التجارية التي يتم فتحها للوكيل.

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

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

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

لا تسمح لتكاملات الوكلاء بالنمو بشكل عشوائي لكل وظيفة. إذا قامت كل وظيفة ببناء اتصال خاص بها مع ERP أو CRM دون معايير مشتركة، فستخلق الشركة ديونًا تقنية جديدة في شكل انتشار فوضوي لتكاملات الوكلاء (agent integration sprawl).

أسئلة تأملية

بالنسبة لمدير تقنية المعلومات (CIO)، السؤال هو ما إذا كان النواة الرقمية للشركة جاهزة حقًا لتصبح منصة تنفيذ للوكلاء، أم أنها لا تزال مجرد نظام تسجيل يصعب الوصول إليه بشكل آمن.

بالنسبة لمدير العمليات (COO)، السؤال هو في أي عملية يكون الاختناق الأكبر ليس في الأشخاص، بل في تأخير الوصول إلى حالة الأعمال من الأنظمة الأساسية.

بالنسبة لمدير الموارد البشرية (CHRO)، إذا بدأ الوكيل في القراءة وتشغيل سير العمل في HRIS، فما هي الأدوار التي ستتحول من الإدارة إلى الإشراف وإدارة الاستثناءات.

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

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