ينجح عرض الأتمتة في تمرير طلب مكتمل، ثم يصل أول طلب ناقص في يوم العمل الحقيقي فيبقى معلقًا لا يعرف أحد مكانه. المشكلة هنا ليست بالضرورة أن الأداة تعطلت؛ قد يكون مسار الاستثناء لم يدخل أصلًا ضمن نطاق التنفيذ. اسأل الشركة عمن يستلم الحالة عندما تعجز الأتمتة عن إكمالها.
لا تطلب وعدًا بأن كل الحالات ستعالج آليًا. اطلب اتفاقًا يميز ما يعاد تقنيًا، وما يعود لصاحب الطلب، وما يحتاج قرارًا أو معالجة بشرية. ويجب أن تتضمن الإجابة مكان ظهور الحالة ومسؤولها والدليل الذي يسمح باستئنافها أو إغلاقها.
ليس كل توقف عطلًا تقنيًا
في مثال افتراضي لأتمتة طلب شراء أدوات مكتبية، يصل الطلب إلى المراجعة ثم إعداد الإجراء التالي. قد يُرفض لأن الصنف غير معتمد، أو ينقصه وصف، أو يتعذر الوصول إلى نظام المورد. الحالات الثلاث توقف المسار المعتاد، لكنها لا تحتاج الاستجابة نفسها. المثال يوضح التصميم، ولا يصف نظام عميل أو عملية شراء فعلية.
الرفض قرار مفهوم من العملية، فلا معنى لإعادته تقنيًا حتى يتحول إلى قبول. نقص الوصف يحتاج صاحب الطلب، بينما تعذر خدمة قد يستحق محاولة أخرى وفق حدود مناسبة. ابدأ بسؤال «ماذا نفعل الآن؟» بدل الاكتفاء بتسمية كل الحالات أخطاء ووضعها في قائمة واحدة.
مصفوفة استثناءات داخل العرض
| الحالة في المثال | الاستجابة المقترحة للنقاش | دليل الاستلام |
|---|---|---|
| بيان لازم غير مكتمل. | إعادة للطالب مع شرح النقص وحفظ المرجع. | المستخدم يعرف ما يصحح وكيف يعيد الطلب. |
| رفض من صاحب الصلاحية. | إنهاء المسار أو فتح تعديل جديد وفق السياسة. | سبب مفهوم دون استمرار تنفيذ غير معتمد. |
| خدمة غير متاحة مؤقتًا. | محاولات بحد وعدد وانتظار مناسبين ثم تصعيد. | سجل نتيجة ومسؤول عند نفاد المحاولات. |
| حالة تحتاج تحققًا يدويًا. | توقف ظاهر لموظف مخول قبل استئناف الخطوات. | قرار مسجل وما الذي استؤنف بعده. |
المصفوفة اقتراح تحريري وليست إعدادًا جاهزًا لكل نشاط. أضف الحالات الخاصة بعمليتك، وحدد كيف يختار الحل الاستجابة. إن لم يستطيع التمييز بين حالتين، ينبغي أن يظهر القيد ومسار المراجعة في العرض بدل الإيحاء بأنه يحسم قرارًا لا يملك بياناته.
التسليم اليدوي عملية لها صاحب
عبارة «سيصل تنبيه» تترك أسئلة مهمة: أين يرى الموظف الطلب، وما المعلومات الضرورية، ومن ينوب عنه عند الغياب؟ وهل يستطيع تعديل البيانات أم إعادة المحاولة فقط؟ حدد حدود التصرف، وما يحتاج اعتمادًا منفصلًا، وما يراه صاحب الطلب أثناء الانتظار.
اطلب شاشة أو سجلًا يمكن منه ربط الحالة بالطلب الأصلي وسبب التعليق وآخر إجراء والمسؤول الحالي. اجعل التفاصيل الحساسة متاحة للمخولين فقط، ولا تحول رسالة التنبيه إلى نسخة كاملة من ملفات الطلب. المهم أن يستطيع الموظف الوصول للمعلومة اللازمة لاتخاذ الإجراء المسموح.
الإعادة التلقائية لا تحل كل شيء
تشرح إرشادات Microsoft مسارات تنفذ بعد الفشل أو انتهاء المهلة، وسياسات إعادة للمشكلات المؤقتة. ويركز دليل Camunda على الفرق بين استجابة تقنية واستجابة تغير مسار العملية أو تسلمها لإنسان. نستخدم المفهومين لقراءة العرض؛ وجودهما في منتج لا يثبت إعداد خطة معالجة لمشروعك.
اسأل عما يحدث عند انتهاء الصلاحية أو تغير بيانات الطلب أو انتهاء المحاولات. لا تجعل حلقة انتظار مفتوحة بديلًا عن مسؤول متابعة. وإذا كانت النتيجة لدى نظام آخر غير معلومة، فراجع اختبارات إعادة المحاولة والتسوية؛ هذا سؤال مختلف عن مجرد إعادة خطوة فاشلة.
اختبار الاستثناء على يد مستخدم التشغيل
قبل التفعيل، جهز حالة ناقصة وأخرى مرفوضة وتعذرًا مرتبًا في بيئة اختبار. ليشرح الموظف ماذا يرى وما الذي يفعله، ثم يراجع المشرف أين أصبحت الحالة بعد المعالجة. لا يكفي أن يعرض المطور علامة خضراء؛ المطلوب إثبات أن الإجراء لم يختف أو يتجاوز قرارًا ضروريًا.
اسأل كيف ستراجعون تكرار أسباب التعليق دون افتراض نسب توفير لم تقاس. قد يكشف تكرار النقص حاجة إلى تحسين النموذج، بينما تشير أعطال الوصول إلى مهمة صيانة مختلفة. سجل نسخة القواعد ومن يعتمد تغييرها وحدود الدعم؛ فإضافة حالة أعمال جديدة تختلف عن إصلاح خلل في حالة متفق عليها.
تساعد حزمة تجهيز العملية على وصف الوضع الحالي. أرفق بعدها مصفوفة الاستثناءات عند طلب أتمتة العمليات من نكست ويف، حتى يشمل النقاش اليوم الذي لا تسير فيه الخطوات كما رسمها العرض التجريبي.
مصادر وحدود الخطة
فُتحت إرشادات Microsoft لمعالجة الأخطاء ومعالجة الاستثناءات في Camunda في 4 نوفمبر 2026. المثال والمصفوفة تحريريّان دون التزام بمنتج أو مدد دعم. أُعد النص بمساعدة الذكاء الاصطناعي مع مراجعة المعنى والترجمة.
