التوجيه القائم على العتبات لقواعد الموافقة

لماذا تنهار قواعد الموافقة المضمّنة في الكود

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

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

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

الاستثناءات المخفية تزيد الطين بلة. مع مرور الوقت، يضيف الفرق قواعد لمرة واحدة مثل "إذا كان المبلغ أكثر من 5,000 والقسم مبيعات، أرسله إلى المدير أ" أو "إذا جاء الطلب من أوروبا، تجاوز هذه الخطوة." عندما تعيش تلك القواعد داخل منطق سير العمل، قلة فقط يمكنهم رؤيتها.

ثم تصبح الأسئلة البسيطة صعبة الإجابة:

• من يوافق على المشتريات فوق مبلغ معين؟
• هل يتبع التسويق نفس سياسة العمليات؟
• ماذا يحدث في منطقة أخرى؟
• أي استثناء أُضيف في الربع الماضي؟

عندما لا يستطيع أحد رؤية مجموعة القواعد كاملة، تتبعها الأخطاء. يعتقد شخص أنه يتبع السياسة بينما التطبيق لا يزال يستخدم قاعدة قديمة. يصل مدير جديد بطلبات لا يجب أن يراها، بينما المُوافق الحقيقي مستبعد.

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

تخيل سياسة مصروفات بسيطة. الطلبات تحت 1,000 تذهب إلى قائد الفريق، الطلبات من 1,000 إلى 10,000 تذهب إلى رئيس القسم، وأي مبلغ أعلى يذهب إلى المالية. إذا تغيرت تلك الحدود الشهر القادم، لا يجب أن يحتاج العمل إلى مطور لمجرد استمرار حركة الموافقات.

البرمجة الصلبة تحوّل تحديثات السياسة العادية إلى مشاريع برمجية. هذا هو التكلفة الحقيقية.

ماذا يعني التوجيه القائم على العتبات

التوجيه القائم على العتبات يعني أن مسار الموافقة يتغير بناءً على قيم تحددها مسبقًا. العتبة ببساطة هي حد مثل مبلغ أكثر من $1,000، طلب من قسم المالية، أو عملية شراء تمت في أوروبا.

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

إعداد أساسي قد يبدو هكذا:

• الطلبات تحت $500 تذهب إلى قائد الفريق.
• الطلبات من $500 إلى $5,000 تذهب إلى مدير القسم.
• الطلبات فوق $5,000 تذهب إلى مدير.
• طلبات الموارد البشرية تتبع مسارًا، بينما طلبات تكنولوجيا المعلومات تتبع مسارًا آخر.
• أمريكا الشمالية وEMEA يمكن أن يكون لهما موافقون مختلفون.

تظل العملية نفسها، لكن القيم التي تتحكم بها يمكن أن تتغير.

فصل المنطق عن السياسة

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

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

على سبيل المثال، إذا احتاجت المبيعات في APAC الآن موافقة المدير لمبالغ فوق $3,000 بدلًا من $5,000، تحدث إدخالًا واحدًا في الجدول. لا تعيد بناء عملية الموافقة بأكملها.

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

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

ماذا يجب أن يحتوي جدول القواعد

جدول قواعد جيد يجب أن يجيب على سؤال بسيط: عندما يطابق الطلب هذه الشروط، من يحتاج الموافقة؟

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

عادةً ما يبدأ جدول عملي بالقيم التي تصف الطلب:

• المبلغ
• العملة
• القسم
• المنطقة
• نوع الطلب
• دور المُوافق

المبلغ والعملات مهمان لأن نفس الرقم قد يعني أشياء مختلفة حسب الميزانيات أو البلدان. طلب بمبلغ 5,000 USD قد يتبع مسارًا، بينما 5,000 EUR أو 500,000 JPY قد يحتاج مسارًا مختلفًا.

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

نوع الطلب مرشح مفيد آخر. السفر، مشتريات البرمجيات، دفعات الموردين، والموافقة على الخصومات قد تحتاج مراجعين مختلفين. بدون هذا الحقل، قد تستخدم طلبات غير مرتبطة نفس القاعدة.

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

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

حقل الأسبقية جدير بالإضافة أيضًا. قاعدة مثل "EU + Finance + أكثر من 10,000" يجب أن تفوز عادةً على قاعدة أوسع مثل "كل الأقسام + أكثر من 10,000." أولوية واضحة تحافظ على توقعات التوجيه.

كيف تبني هيكل الجدول

حافظ على الهيكل بسيطًا: صف واحد يجب أن يساوي قاعدة موافقة واحدة.

إذا كانت مصروفات التسويق فوق $2,000 في أوروبا تحتاج مديرًا إقليميًا، يجب أن تكون تلك في سجل واحد. عندما يكون لكل صف معنى واضح، يصبح الإعداد أسهل للتحديث والاختبار والمراجعة.

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

تخطيط عملي

جدول نظيف غالبًا ما يتضمن هذه الحقول:

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

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

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

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

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

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

كيف تبدؤوا الإعداد

ابدأ بالقرار، لا بالجدول. اكتب بالضبط الأسئلة التي يحتاج سير العمل للإجابة عليها. هل شراء فوق $5,000 يحتاج موافقة مدير؟ هل المالية تراجع أي شيء من المبيعات؟ هل طلبات منطقة معينة تتبع مسارًا مختلفًا؟

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

إعداد بسيط عادةً يتبع خمس خطوات.

أولًا، أنشئ جدول قواعد الموافقة بالحقول التي تؤثر على التوجيه. الأعمدة الشائعة تشمل amount_min، amount_max، department، region، approver_role، priority، وactive_status.

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

ثالثًا، أضف القواعد من الأكثر تحديدًا إلى الأكثر عمومية. قاعدة مثل "مبيعات + أوروبا + أكثر من 10,000" يجب فحصها قبل قاعدة عامة مثل "أي قسم + أي منطقة + أكثر من 10,000."

رابعًا، اختبر بأمثلة حقيقية قبل الإطلاق. استخدم حالات حافة مثل بالضبط $5,000، بيانات قسم مفقودة، أو منطقة بلا قاعدة مخصصة.

خامسًا، حدّ من يملك صلاحية تعديل الجدول. تغيير السياسة يجب أن يكون سهلًا، لكنه لا ينبغي أن يكون مفتوحًا للجميع.

هنا مثال بسيط. طلب بمبلغ $12,000 من الموارد البشرية في أمريكا الشمالية قد يطابق أولًا قاعدة "الموارد البشرية فوق $10,000"، مما يرسله إلى مدير الموارد البشرية. إذا لم توجد قاعدة خاصة بالموارد البشرية، يمكن للنظام أن يعود إلى قاعدة أوسع مثل "أي قسم فوق $10,000"، التي ترسل إلى المالية.

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

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

مثال بسيط عمليًا

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

افترض أن للشركة قسميْن، التسويق وتكنولوجيا المعلومات. كلاهما قد يقدّم طلبًا بمبلغ $4,000، لكن مسار الموافقة لا يجب أن يكون نفسه.

قارن الآن طلبين بالمبلغ نفسه. طلب تسويق بقيمة $4,000 في الولايات المتحدة يذهب إلى مدير التسويق. طلب تكنولوجيا معلومات بقيمة $4,000 في الولايات المتحدة يتجاوز مدير تكنولوجيا المعلومات ويذهب إلى CTO، لأن عتبة تكنولوجيا المعلومات أقل.

يمكن للمنطقة أيضًا تغيير النتيجة. طلب تسويق بقيمة $2,500 في الولايات المتحدة يذهب إلى مدير التسويق، لكن نفس الطلب في الاتحاد الأوروبي يذهب إلى القائد الإقليمي للتسويق. النموذج يبقى نفسه. فقط القاعدة المطابقة تتغير.

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

إذا حدّثت الشركة سياستها الشهر القادم، لا تحتاج لإعادة بناء العملية بأكملها. إذا قررت IT أن الطلبات فوق $2,000 تذهب الآن إلى CTO، تعدل صفًا واحدًا:

• القاعدة القديمة: IT، US، $3,001+، CTO
• القاعدة الجديدة: IT، US، $2,001+، CTO

كل شيء آخر يستمر في العمل. الطلبات الجديدة تتبع السياسة الجديدة فورًا بينما بنية التطبيق تبقى دون تغيير.

أخطاء شائعة تجنبها

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

خطأ شائع هو وجود قواعد متداخلة دون أولوية واضحة. قد تكون لديك قاعدة ترسل كل طلبات التسويق فوق $3,000 إلى رئيس القسم وأخرى ترسل أي طلب فوق $5,000 إلى المالية. طلب تسويق بقيمة $6,000 يطابق الاثنتين، لذلك يحتاج النظام إلى فائز واضح. ضع تلك الأسبقية في جدول القواعد، لا في منطق مخفي في سير العمل.

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

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

الاستثناءات الإقليمية نقطة ضعف أخرى. سياسة تعمل في بلد واحد قد لا تنطبق في آخر بسبب حدود إنفاق محلية أو قواعد ضريبية أو متطلبات تقارير. إذا اختبرت منطقة واحدة فقط، قد تفوت حالات حيث يجب أن تتبع طلبات الاتحاد الأوروبي أو الولايات المتحدة أو APAC مسارات مختلفة.

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

فحوصات نهائية قبل الإطلاق

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

اجعل المراجعة النهائية بسيطة.

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

تأكد من وجود مسار احتياطي. الأقسام المفقودة، المناطق الجديدة، أو المبالغ الغريبة يجب أن تذهب إلى مكان آمن.

أكد أن تحديثات السياسة يمكن أن تحدث دون مطور. إذا احتاجت المالية أو العمليات لتغيير الحدود أو التواريخ أو المُوافقين، يجب أن يتمكنوا من تحرير السجلات في جدول بدل طلب تغيير كود.

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

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

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

الخطوات التالية

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

هذا النهج يجعل نموذج التوجيه أسهل للاعتماد. يمكن للناس رؤية كيف تعمل القواعد، أين تظهر الاستثناءات، وماذا يجب تغييره قبل أن يكبر الإعداد.

يجب أن يجيب العرض الأول على أربعة أسئلة أساسية:

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

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

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

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

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

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