تصميم مسارات الاستثناء: خطط الرفض قبل الموافقات

لماذا المسار المثالي لا يكفي

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

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

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

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

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

مخطط موافقة أساسي سهل الرسم:

• تقديم الطلب
• مراجعة الطلب
• الموافقة على الطلب

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

لهذا السبب يستحق تصميم مسارات الاستثناء اهتماماً قبل رسم الشاشات وتسميات الحالات. يعرّف مسار الاستثناء ما يحدث عندما تقاطع الواقع الخطة، والواقع يفعل ذلك كثيراً.

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

المسار المثالي يظهر النية. مسارات الاستثناء تُظهر ما إذا كانت العملية ستصمد في الاستخدام الحقيقي.

كيف يبدو مسار الاستثناء

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

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

معظم سير العمل يتعطل بعدة طرق متوقعة:

• تم رفض الطلب لسبب واضح
• أحد الحقول أو المستندات المطلوبة مفقود
• تمت الموافقة على جزء من الطلب فقط
• الطلب بلا مالك أو بلا خطوة تالية محددة

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

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

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

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

مثال بسيط لموافقة

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

ذلك التدفق نظيف، لكنه غير مكتمل.

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

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

أضف الآن مشكلة ثانية. المدير يوافق على السفر لكنه ليس بالمبلغ الكامل. يوافق على الطيران وليلة فندق واحدة، لكنه يرفض رسوم ورشة العمل والليلة الثانية في الفندق.

هنا يكتشف كثير من الفرق أنها لا تملك عملية موافقة جزئية فعلاً.

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

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

• الطيران: موافق
• الفندق: موافق لليلة واحدة
• إضافة الورشة: غير موافق
• الإجمالي المطلوب: $1,450
• الإجمالي الموافق عليه: $980

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

صمّم الاستثناءات قبل الشاشات

طريقة جيدة لتحسين سير العمل هي افتراض أن الطلب لن يمر نظيفاً. هذا التحول الواحد يغير جودة التصميم بسرعة.

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

• الرفض
• المعلومات المفقودة
• الموافقة الجزئية

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

اعمل بهذا الترتيب.

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

بعدها، قرّر ما الذي يحدث في كل حالة. لكل استثناء، أجب عن أربعة أسئلة بسيطة:

• من الذي يُخطر
• ما الحالة التي يظهرها الطلب
• ماذا يجب أن يفعل المستخدم تالياً
• متى يتحرك الطلب مرة أخرى

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

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

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

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

حدد القواعد قبل الواجهة

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

الترتيب الأفضل بسيط: عرّف الحالات، التسليمات، المهل الزمنية، والادلة المطلوبة للتحرك قدمًا. ثم ابنِ الشاشات حول ذلك.

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

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

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

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

مجموعة قواعد عملية يجب أن تجيب عن أربعة أسئلة:

• ما أسماء الحالات القليلة التي سيستخدمها الجميع كل يوم؟
• من يتصرف تالياً في كل حالة؟
• كم من الوقت يمكن أن يبقى العنصر هناك قبل أن يتصاعد أو ينتهي أو يغلق؟
• ما الحقول أو الملفات أو الفحوص المطلوبة قبل أن يتحرك؟

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

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

اكتب رسائل يمكن للناس تنفيذها

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

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

خذ مثال الموافقة على مورد. يقدّم المستخدم استمارة بمستند ضريبي، بيانات بنكية، وإثبات تأمين. البيانات البنكية جيدة، المستند الضريبي قديم، وإثبات التأمين مفقود. إذا عرض النظام فقط "لم تُوافق الطلب"، لا يملك المستخدم خطوة تالياً واضحة.

رسالة أفضل قد تقول: "بياناتك البنكية تمت الموافقة عليها. نحتاج بعدُ مستند ضريبي محدث وإثبات تأمين قبل الموافقة النهائية." تلك الجملة الواحدة توفر وقتاً لأنها تفصل ما تم عن ما لا يزال مطلوباً.

الرسائل الجيدة عادةً تجيب عن أربعة أسئلة صغيرة:

• أي جزء رُفض أو مفقود أو لا يزال قيد المراجعة؟
• أي جزء قُبل بالفعل؟
• ماذا يحتاج الشخص رفعه أو تغييره أو تأكيده؟
• ماذا يحدث بعد إعادة الإرسال؟

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

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

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

• موافق: مستند الهوية
• يحتاج تحديث: النموذج الضريبي
• مفقود: شهادة التأمين

الآن يمكن للمستخدم إصلاح ما يهم فقط. لا يحتاج للبدء من جديد.

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

الرسائل الجيدة تقلل تذاكر الدعم، تسرّع الموافقات، وتجعل العملية تبدو عادلة. يمكن للناس قبول الرفض عندما يفهمونه.

الأخطاء التي تخلق إعادة العمل

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

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

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

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

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

عندما تُضم الموافقة الجزئية مع الرفض، يعيد الناس تقديم الطلب كله، يكرّرون المستندات، ويبدؤون مراجعات أُنجزت بالفعل. هذه إعادة عمل محضة.

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

فحوص سريعة قبل البناء

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

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

استخدم هذه الفحصات السريعة على كل استثناء في عمليتك:

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

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

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

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

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