موافقات داخل Teams وصلاحيات على مستوى العنصر

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

المتطلب الحقيقي

الموظف يقدم طلبه ولا يرى غير طلباته. المدير يطلع على طلبات فريقه، والموارد البشرية ترى كل شيء.

الخطأ الشائع

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

ما أفعله بدلا من ذلك

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

أما المعلومات الحساسة فأعزلها في قائمة أو موقع منفصل بصلاحيات واضحة، وتسلم بذلك القائمة الرئيسية من كسر الصلاحيات على آلاف العناصر.

تدفق الموافقة

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

المدير يحسم القرار بضغطة واحدة، والنظام يكتب النتيجة في الصف نفسه: من وافق ومتى.

المصيدة

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

المؤشر الذي يقول إن النظام نجح

توقف وصول الطلبات في واتساب. ما دام أحد يرسل طلبه في محادثة، فالناس لم يتبنوا النظام بعد، والسبب في الغالب أن تقديم الطلب فيه أثقل من كتابة رسالة، وقلما يكون السبب نقصا في المزايا.

اقرأ أيضا