سير موافقات مفوّضة مع مسارات تصعيد OOO واضحة

لماذا تصبح الموافقات المفوضة فوضوية

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

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

إليك الأعراض الشائعة عندما لا يكون سير الموافقات المفوضة محددًا بشكل جيد:

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

الجزء الفوضوي ليس التفويض نفسه، بل غياب المسؤولية الواضحة. عندما لا يعرف الناس من هو المسؤول، يتباطأون لحماية أنفسهم، أو يسرعون على أمل أن الأمور ستكون على ما يرام.

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

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

حدّد الأدوار لتبقى الملكية واضحة

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

إليك مجموعة بسيطة تغطي معظم الفرق:

• طالب الطلب (Requestor): ينشئ الطلب ويقدّم التفاصيل والمرفقات اللازمة للقرار.
• الموافق (المالك): الشخص المسؤول عن القرار. يجب أن يكون اسمه هو الذي يمكن الإشارة إليه لاحقًا إذا ظهر سؤال.
• المفوّض (Delegate): يمكنه اتخاذ إجراء نيابة عن المالك خلال نافذة زمنية محددة، لكن فقط ضمن حدود متفق عليها.
• المراجع (Reviewer): فحص موضوعي اختياري (أمن، قانون، تكنولوجيا). يقدم مشورة، لكنه لا يملك القرار النهائي.
• المالية أو الموارد البشرية: فحص مطلوب عندما يؤثر الطلب على الميزانية أو الرواتب أو التوظيف أو السياسة. يمكنهم الحظر أو الإرجاع وفقًا للقواعد.

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

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

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

ضع حدودًا: ما الذي يمكن الموافقة عليه نيابة عن الآخرين

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

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

اكتب الحدود بطريقة يمكن للناس تطبيقها في ثوانٍ:

• النطاق: لأي قسم أو فريق أو مركز تكلفة يمكن للمفوّض أن يتصرّف نيابة عنه
• الحدود: نطاقات الميزانية (مثال، حتى 1,000$) وما يحدث فوق الحد
• أنواع الطلبات: الفئات المسموحة (أوامر شراء، إجازات، استردادات) وما الممنوع
• النافذة الزمنية: لحظات البدء والانتهاء مع منطقة زمنية واضحة (مثال: "تبدأ 09:00 بالتوقيت المحلي يوم الاثنين، وتنتهي 18:00 بالتوقيت المحلي يوم الجمعة")
• الإثبات: ما يجب إرفاقه أو التحقق منه (مطابقة السياسة، المورد في القائمة المعتمدة، الحقول المطلوبة مكتملة)

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

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

قواعد خارج المكتب لا تفاجئ الناس

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

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

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

• إعادة التوجيه إلى مفوّض مسمّى فورًا (سريع، لكن يحتاج حدود صارمة)
• الإيقاف حتى عودة المالك، ثم التصعيد تلقائيًا بعد مهلة زمنية (آمن، لكن أبطأ)
• التصعيد فورًا إلى موافق احتياطي أعلى (آمن، لكن قد يرهق الاحتياط)

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

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

• الصباح فقط: أعد توجيه الطلبات الجديدة إلى المفوّض بعد 12:00
• أيام السفر: السماح فقط بالموافقات منخفضة المخاطر، وتصعيد الباقي
• عطلات نهاية الأسبوع: لا تعيد التوجيه عادة إلى الموافق الأساسي، استخدم المفوّض أو أوقف
• العطلات الرسمية: عاملها كتعطيل كامل ما لم يختر الشخص المشاركة

مثال صغير وواقعي: إذا كان المدير في إجازة لكن مصنّف "صباحًا فقط"، فيمكن توجيه تجديد برنامج بقيمة 200$ إليه عند 9:00، لكن عملية شراء بقيمة 5,000$ يجب أن تذهب إلى المفوّض مع إعلام المدير.

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

خطوة بخطوة: سير قابل للصيانة للموافقة نيابة عن الآخر

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

إليك سيرًا عمليًا يمكنك نمذجته في أي نظام تقريبًا:

• التقاط الطلب مع الحقول المطلوبة. اجمع الحد الأدنى الذي يمنع العودة للمعلومات: طالب الطلب، العنصر أو الإجراء، المبلغ أو التأثير، السبب التجاري، تاريخ الاستحقاق، ومركز التكلفة أو الفريق. إذا دعمت المرفقات، اجعلها اختيارية لكن مرئية.
• إعادة التوجيه إلى المالك أولاً، ثم التحقق من حالة OOO. حاول دائمًا المالك الأساسي قبل التفويض. إذا كان المالك مصنّفًا OOO، سجّل نافذة OOO (البدء والنهاية) والمفوّض المختار لتلك الفترة.
• إعادة التوجيه إلى المفوّض مع وسم "بالنيابة عن" واضح. يجب أن يرى المفوّض: "الموافقة نيابة عن Jordan (المالك)" مع السبب (OOO)، الطلب الأصلي، وحدود السياسة. يجب أن يخزن سجل التدقيق كلا الاسمين، لا اسم المفوّض فقط.
• تطبيق مؤقتات التصعيد والتذكير. ضع تذكيرًا أو اثنين زمنيين (مثال، تذكير بعد 24 ساعة، تصعيد بعد 48). اجعل هدف التصعيد صريحًا، مثل مدير المالك أو قائمة موافقات مشتركة.
• إنهاء القرار وإخطار كل من يحتاج أن يعرف. أرسل النتيجة إلى طالب الطلب، المالك، المفوّض، وأي فرق لاحقة (المالية، الشراء). ضمّن ما تمت الموافقة عليه، ومن قام بذلك، وتفاصيل "بالنيابة عن".

إذا بنيت هذا في AppMaster، اجعل نموذج البيانات صغيرًا (Request, Approval, DelegateRule) وضع منطق التوجيه في Business Process واحد حتى تبقى التغييرات في مكان واحد مع تطور الفرق أو السياسات.

مسارات تصعيد تعمل حقًا

مسار التصعيد هو شبكة الأمان. بدونها، تظل الطلبات معلقة، يطارِد الناس بعضهم البعض في المحادثات، وتصبح الاستثناءات هي "العملية الحقيقية".

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

المفوّض: شخص واحد أم مجموعة؟

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

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

• من يرد أولًا يكون الفائز مع ملاحظة في السجل
• أو التعيين بالدور (round-robin)
• أو التعيين حسب مركز التكلفة أو نوع المورد

سلم تصعيد عملي

لسير الموافقات المفوضة، يحافظ سلم بسيط على وضوح الملكية:

• المفوّض (أو تجمع المفوّضين)
• مدير صاحب الطلب
• رئيس القسم
• المالية (أو موافق مالي مُعيّن)

عرّف التوقيت حتى يتحرك الطلب بشكل متوقع، مثلاً: للمفوّض 8 ساعات عمل، للمدير يوم عمل واحد، ثم يعاد التصعيد.

خطط لأسوأ الحالات: في حال غياب المالك والمفوّض معًا. لا تعتمد على "شخص ما سيلاحظ". أضف قاعدة تفحص التوافر، ثم تقفز مباشرة إلى المدير (أو التجمع). في أدوات مثل AppMaster، يمكن نمذجة ذلك كمؤقت حالة مع فحص "OOO" في Business Process، مع تسجيل كل تمرير.

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

سيناريو نموذجي: الموافقة على شراء أثناء الإجازة

يحتاج فريق الدعم إلى حاسوب محمول جديد لموظف جديد. يقدّم الطالب طلب شراء بقيمة 1,200$، الذي عادة ما يذهب إلى مديرهم، بريا، للموافقة. بريا في إجازة لمدة أسبوع، لذا حسابها يعني أنها خارج المكتب.

لبريا مفوّض مسمّى، ماركوس، بقاعدة واضحة: يمكنه الموافقة على مشتريات حتى 1,000$ نيابة عنها. أي شيء فوق ذلك يجب أن يذهب إلى الموافق التالي، رئيس القسم، مع إبقاء ماركوس في الحلقة. هذا الحد الواحد يبقي العملية متوقعة وسهلة الشرح.

هكذا يتحرك الطلب مع رؤية الجميع للقصة نفسها في الإشعارات:

• 09:05: تم تقديم الطلب. يتلقى الطالب رسالة: "بريا خارج المكتب. ماركوس هو المفوّض وسيقوم بالمراجعة."
• 09:06: يُسند ماركوس ويرى السياق الكامل، بما في ذلك حد موافقته ووقت التصعيد.
• 09:20: يراجع ماركوس ولا يمكنه الموافقة بالكامل لأن المبلغ 1,200$. ينقر "الموافقة نيابة عن" لحد 1,000$ (أو يعلّم "يوصي بالموافقة") ويعلّم ال200$ المتبقية كحاجة لتصعيد.
• 09:21: يُعيَّن رئيس القسم تلقائيًا مع ملاحظة: "فوق حد المفوّض. المفوّض راجع ويُوصي بالموافقة."
• +24 ساعة: إذا لم يتصرف رئيس القسم، يتصاعد السير إلى موافق احتياطي أو مجموعة المناوبة، ويُخبر الطالب بما تغيّر ولماذا.

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

إذا بنيت هذا في أداة مثل AppMaster، عامل القواعد كبيانات (من هو OOO، من المفوّض، ما الحد، ما هدف التصعيد بعد 24 ساعة). هذا يجعل تحديث السياسة لاحقًا سهلًا دون إعادة كتابة سير العمل بأكمله.

الأخطاء الشائعة والفخوخ

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

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

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

إليك الأخطاء الأكثر إضرارًا:

• تفويضات بلا تاريخ انتهاء (أو بلا مراجعة)، خاصة للموافقات عالية القيمة.
• تفويض لشخص بدون سلطة ميزانية أو سياق كافٍ للحكم على المخاطر.
• لا وجود لسجل يوضح "تمت الموافقة بواسطة المفوّض لصالح المالك" في سجل الموافقات النهائي.
• حلقات تصعيد حيث تقفز العناصر بين نفس الشخصين عندما يكون أحدهما غائبًا.
• الكثير من قواعد الحالة الخاصة التي يفهمها شخص واحد فقط (ولا يجرؤ أحد على تعديلها).

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

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

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

قائمة تحقق سريعة قبل الإطلاق

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

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

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

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

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

الحفاظ على قابلية الصيانة مع الزمن

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

ابدأ بجمع القواعد في مكان واحد. استخدم سجلًا واحدًا لأنواع الطلبات (مثل "شراء تحت 5k$" أو "وصول لبيانات العملاء"), واحتفظ بالأسماء متسقة عبر النماذج، الإشعارات، والتقارير. الأسماء المتسقة تسهّل التدقيق، تدريب المديرين الجدد، وتجنّب مسارات مكررة تقوم بنفس الشيء.

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

بعض العادات الخفيفة تمنع 90% من الانحراف طويل الأمد:

• عيّن مالك عملية لكل نوع طلب (ليس لكل أداة)
• استخدم نمط تسمية واضح للقواعد ونقاط القرار
• اشترط تاريخ انتهاء على كل تفويض OOO
• احتفظ بالاستثناءات المؤقتة محددة زمنياً وموثقة
• أزل المسارات القديمة عندما يحلّ مكانها مسار جديد

تتبّع بيانات كافية لاكتشاف المشاكل مبكرًا. لست بحاجة لتحليلات معقّدة، لكن تحتاج إشارات بأن شيئًا ينزلق:

• زمن الموافقة (الوسيط والأسوأ)
• عدد حالات التصعيد
• معدل إعادة العمل (الرجوع لطلب معلومات مفقودة)
• التفويضات النشطة بعد تاريخ انتهائها

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

الخطوات التالية: التنفيذ والاختبار بتجربة صغيرة

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

قرّر البيانات التي تحتاجها من اليوم الأول، لأنها تؤثر على التوجيه وسجل التدقيق لاحقًا. يندم معظم الفرق على عدم تسجيل "لماذا" وراء القرار أو التسليم الدقيق الذي حدث أثناء تغطية OOO.

مجموعة بيانات بسيطة للتجربة عادةً تشمل:

• طالب الطلب، مركز التكلفة (أو الفريق)، والمبلغ
• المراجع الأساسي والمفوّض (إن وُجد)
• حالة OOO وتواريخ البدء/الانتهاء
• القرار، الطابع الزمني، وعلم "الموافقة نيابة عن"
• السبب/التعليق ومرجع الملحق (إن لزم)

إذا أردت بناء ذلك بدون برمجة ثقيلة، يمكنك نمذجة الموافقات، قواعد OOO، والتصعيدات في AppMaster باستخدام Data Designer (لتعريف المراجعين، الحدود، ونوافذ OOO) وBusiness Process Editor (لتوجيه الطلبات، تشغيل المؤقتات، وتسجيل كل قرار). اجعل النسخة الأولى صارمة ومقروءة، حتى لو كان ذلك يعني حالات أقل خاصة.

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

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

• كم مرة يحدث التفويض ولماذا
• أين تتعطل الطلبات (ولكم من الوقت)
• هل التصعيدات تذهب إلى الشخص الصحيح
• كم من الموافقات طُعن فيها أو عُكست لاحقًا

بعد التجربة، عدّل الأدوار والحدود والمؤقتات، ثم وسّع إلى سير العمل التالي. إن لم تستطع شرح التدفق في دقيقتين لمدير جديد، بسطه قبل التوسع.