أين تسوء الأتمتة: 6 أنماط فشل وكيفية التصميم حولها

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

لماذا تفشل مشاريع الأتمتة كثيرًا؟

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

ما هي أنماط الفشل الستة وكيف يمكنك تصميم كل منها؟

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

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

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

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

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

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

كيف يمكنك معرفة ما إذا كان التشغيل الآلي قد تم تصميمه جيدًا قبل إنشائه؟

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

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

الإجابة على هذه الأسئلة قبل كتابة أي سطر من التعليمات البرمجية هي مرحلة التدقيق في عملنا في أتمتة العملية.

##الوجبات العملية

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