أتمتة العمليات الروبوتية (RPA) بتُطرح كحل سحري لأي شي متكرر، وهالسمعة بتظلمها. الـ RPA، بالممارسة، هي برنامج بيضغط وبيكتب وبيقرا وبينسخ بيانات بين واجهات زي ما بيعمل الإنسان بالظبط، باستخدام أدوات متل UiPath لتسجيل وبرمجة هالسلوك. مش ذكاء اصطناعي، وما بيفهم شو عم يعمل. بيعيد تنفيذ إجراء معيّن بالظبط، وهاد بالضبط اللي بيخليه قوي بالمهمة الصح وهش بالمهمة الغلط.
أول اختبار بعمله قبل ما أنصح بـ RPA هو اختبار الحجم والتكرار. مهمة بتصير مرتين بالشهر، مهما كانت مملة، غالباً بتكلف أتمتتها وصيانتها أكتر من إنك تعملها يدوياً وخلص. أما مهمة بتصير خمسين مرة باليوم، بنفس الخطوات كل مرة، فهاي قصة تانية تماماً. الحساب المهم هو: (الدقائق الموفرة بكل تشغيلة) × (عدد التشغيلات بالفترة) مقابل الساعات المصروفة ببناء البوت، والأهم صيانته، لأنو أي أتمتة بتحتاج متابعة بين فترة وفترة لما النظام أو الموقع المستهدف يحدّث واجهته.
الاختبار الثاني هو الاستقرار. بوتات الـ RPA بتتعامل مع الواجهات باستخدام "selectors"، يعني بطريقة تقنية بتلاقي الأزرار والحقول حسب شكل بناء الصفحة أو التطبيق، مش حسب الهدف من المهمة. إذا تصميم النظام المستهدف بيتغير كتير، البوت المبني عليه بينكسر كتير، والعميل اللي عم يدفع مقابل "أتمتة" ما بدو تذكرة دعم فني كل ما مزود الخدمة يعيد تصميم لوحة التحكم. العملية اللي بتشتغل على نظام مستقر ونادراً ما يتغير مرشح أتمتة أأمن بكتير من عملية بتشتغل على تطبيق بيتحدث باستمرار.
مثال ملموس من شغلي الشخصي: عميل بمجال التجزئة احتاج استخراج قوائم منتجات من موقع مصدر ورفعها لمتجر WooCommerce الخاص فيه، مهمة كانت غير هيك بتعني حدا بينسخ يدوياً الأسماء والأسعار والأوصاف والصور، منتج منتج، لكتالوج بيوصل لمئات الأصناف. هاي حالة RPA كتابية بامتياز. حجم عالي، متكررة، قائمة على قواعد ثابتة، وبنية المصدر كانت مستقرة لدرجة كافية حتى البوت المبني عليها يضل يشتغل بثبات. نفس المنطق بينطبق على مزامنة بيانات بين نظامين ما بيحكوا مع بعض، أو سحب قوائم منظمة لمنصة على جدول زمني.
المكان اللي بوجّه فيه العملاء بعيد عن الـ RPA هو أي مكان بيحتاج فعلاً قرار بشري حالة بحالة، وين "القواعد" هي بالحقيقة استثناءات متنكرة بشكل قواعد. إذا كل حالة ثالثة بتحتاج قرار بشري ما ينرد لشرط if/then بسيط، البوت رح يحتاج منطق معالجة استثناءات أكتر من قيمة المهمة اللي عم تتمتت من الأساس. كمان بوجّه الناس بعيد عن الـ RPA لما يكون فيه تكامل API مناسب موجود أو ممكن، لأنو استدعاء API أسرع وأوثق ومحصّن ضد إعادة تصميم الواجهة بشكل ما رح يوصله بوت عم يضغط جوا متصفح. الـ RPA غالباً هو الأداة الصح تحديداً لأنو مافي API متاح، مش لأنو أفضل منه بطبيعته.
النصيحة الصادقة، لما عميل يسأل "هل أتمت هاد الشي؟"، هي ترسم العملية الفعلية الأول: قديش بتصير بالتكرار، قديش كل تشغيلة متكررة فعلاً، قديش الأنظمة المعنية بتتغير، وهل فيه API أصلاً. لما الإجابات بتترتب صح، الـ RPA بترجع تكلفتها خلال أسابيع وبتضل ترجّع كل أسبوع بعدها. ولما ما بترتب، الاستثمار الأفضل غالباً يكون مسار عمل يدوي أنظف، أو أداة داخلية بسيطة، أو تكامل حقيقي، مش بوت ملفوف حول مشكلة ما كانت أصلاً عن التكرار.
