Why Your BPO's RPA Bots Keep Breaking (And What Actually Replaces Them)

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

لماذا تنجح برمجيات RPA في العروض التوضيحية وتفشل في مرحلة الإنتاج الفعلي؟

تظهر برمجيات RPA بشكل رائع في العروض التوضيحية. تسجل نفسك وأنت تقوم بمهمة ما لمرة واحدة، فيقوم الروبوت بتكرارها، ثم تُكتب شريحة تحديد عائد الاستثمار (ROI) تلقائياً. ولكن يتغير كل ذلك بمجرد أن يواجه عملية حقيقية على أرض الواقع.

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

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

تتكون المكاتب الخلفية لشركات BPO غالباً من المهام التي تعجز برمجيات RPA عن أدائها

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

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

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

ما الذي يغيره "الوكيل القادر على التفكير والتحليل" فعلياً؟

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

إليك كيف يبدو ذلك في الإنتاج الفعلي، وليس في مجرد عرض توضيحي:

في أحد مراكز BPO الأوروبية لتحصيل الديون، يقوم الوكلاء بقراءة ملفات القضايا والملفات القانونية وتصنيفها واستخراج حوالي 300 حقل لكل ملف. انخفض وقت المعالجة من 3 إلى 5 دقائق إلى حوالي دقيقة واحدة فقط، وتُصنف قضايا الإعسار بدقة تصل إلى 96%، وتعمل المنظومة على أكثر من 100 مليون ملف سنوياً مع معدل تراجع يقل عن 2%. لا يمكن لروبوت مسجل مسبقاً قراءة وثيقة قانونية لم يرها من قبل، في حين يمكن للوكيل القيام بذلك.

وفي شركة تأمين عالمية، يدير الوكلاء حسابات القبض في 26 دولة بدقة مهام تصل إلى 93%، واختصروا وقت معالجة الفواتير من 30 إلى 60 دقيقة إلى دقائق معدودة، ووفروا ما يعادل 200 موظف بدوام كامل (FTEs) للتركيز على أعمال ذات قيمة أعلى. هذا هو العمل المليء بالاستثناءات ومتعدد التنسيقات الذي يعطل الروبوتات، ولكنه يعمل هنا كعملية مستقرة ومستمرة.

هذا ليس تغييراً جذرياً شاملاً (Rip-and-replace)

الهدف ليس التخلص من برمجيات RPA نهائياً، بل التوقف عن استخدامها في المهام التي تعجز عن أدائها.

يعمل الوكلاء فوق الأنظمة التي تشغلها بالفعل، لذا لا داعي لإلغاء أي شيء. احتفظ ببرمجيات RPA للمسارات المستقرة، عالية الحجم، والمنظمة التي تكون فعالة فيها. وانقل الأعمال التي تتطلب الكثير من القرارات التقديرية، وتكثر فيها الاستثناءات والمستندات - والتي تستمر في التعطل - إلى الوكلاء، مع إشراف موظفيك على الاستثناءات فقط. تصل معظم الفرق إلى تشغيل وكيل تفاعلي في غضون 4 إلى 6 أسابيع، مقارنة بفترة تتراوح بين 9 إلى 12 شهراً يستغرقها التطوير الداخلي وبمعدل نجاح يبلغ 22% فقط لمشاريع بناء الذكاء الاصطناعي داخلياً بالكامل.

كيف تعرف أي من عملياتك ستستمر في التعطل؟

يمكنك التنبؤ بالتعطل. قم بتقييم كل عملية مؤتمتة من خلال ثلاثة أسئلة:

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

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

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

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

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