تكاد منصات الموارد البشرية كلها تتشابه في نقطة البداية: قائمة قصيرة من الأدوار الجاهزة، كمسؤول النظام والمدير والموظف، وقد يُضاف إليها دور أو دوران. تبدو القائمة للوهلة الأولى محكمة التنظيم، غير أنها أول ما يتصدّع حين تحاول منشأة فعلية أن توزّع موظفيها على هذه الأدوار؛ إذ سرعان ما يتبيّن أن واقع العمل أوسع من هذه القوالب وأعقد.
وواقع العمل نفسه يبين لنا بوضوح الفرق المتعددة ضمن إطار الموارد البشرية؛ فستجد فريقاً يصبّ تركيزه على أطر الجدارات، وفريقاً آخر يهتم بإدارة تقييمات الأداء ومعايرة النتائج. ونجد فريق التدريب والتطوير منغمساً في بناء المحتوى التدريبي والمسارات التطويرية من جهة، وتحليل معدلات الإنجاز والتفاعل من جهة أخرى، إلى جانب قسم الرواتب والمزايا، وعمليات الموارد البشرية، وصولاً إلى رئيس الموارد البشرية الذي يحتاج إلى رؤية استراتيجية شاملة.
ولا تعد هذه المسميات تفرعات لوظيفة واحدة؛ بل كل مسمى ذكرناه هو دور وظيفي متكامل بذاته؛ فكل فريق يتعامل مع بيانات مختلفة، ويواجه ضغوطاً متباينة، وتختلف بينهم تبعات ومخاطر إمكانية وصولهم لبيانات لا تخصهم.
فحين تمنح جميع هؤلاء صلاحية موحدة تحت مسمى «مسؤول النظام» (HR Admin)، فأنت تقع في خطأين في آنٍ واحد: فالخطأ الأول هو أنك سمحت لمنسّق التدريب بالاطلاع على بيانات الرواتب وتقييمات الأداء دون أي حاجة وظيفية لذلك، وأما الخطأ الثاني فإنّك أعطيت صلاحية تعديل إطار الجدارات لمسؤول الأداء في حين أن دوره يتطلب الاطلاع فقط.
يمسّ الخطأ الأول الاحترازات الأمنية وخصوصية البيانات، ويخل الخطأ الثاني بسلاسة سير العمل وكفاءته. ويظل أساس كلا الخللين واحداً: تصميم صلاحيات الدخول بناءً على «اسم القسم»، لا على «المهام الفعلية» التي يمارسها الموظف.
كيف تخذلنا الصلاحيات العامّة؟
تُطلق أدبيات «إدارة الصلاحيات والوصول» مسميات تقنية لما يحدث بعد ذلك، وهي نواتج تلمسها فرق الموارد البشرية وتتأثر سلبًا بشكل عملي.
النتيجة الأولى هي «الإفراط في منح الصلاحيات» (Over-provisioning)، وهو التعبير اللطيف لمنح الموظف صلاحيات تتجاوز بكثير احتياج وظيفته الفعلية. فعندما يستطيع مسؤول تقييم الأداء الاطلاع على بيانات الجدارات، وسجلات التدريب، وإجابات الاستبيانات وتعديلها، فهو يمتلك صلاحيات هو في غنى عنها لا تمتّ لعمله بصلة.
ولا يتطلب الأمر وقوع حادثة سيئة لنعتبر هذا الوضع خطراً أو عبئاً أمنياً؛ بل هو خطَر قائم بحد ذاته، منذ لحظة منح هذه الصلاحيات، وذلك لأن «نطاق الضرر» التابع لأي خطأ غير مقصود أو اختراق ذلك الحساب لن يقتصر على زاوية واحدة من المنظومة، بل سيمتد ليطال المنصة بأكملها.
أمّا النتيجة الثانية فهي «تراكم الصلاحيات» (Privilege Creep)، وهو مسارٌ أبطأ أثراً ولكنه أعمق تآكلاً وخلقاً للمخاطر.
فالأدوار تتغير والموظفون ينتقلون؛ فقد يتولى أخصائي التدريب إدارة دورة تقييم الأداء لربع سنوي واحد، ويُمنح الصلاحيات اللازمة لذلك، لكنها تظل بحوزته حتى بعد انتهاء تكليفه بوقت طويل. أو يحصل أخصائي عام في الموارد البشرية على استثناء لمرة واحدة للاطلاع على سلم الرواتب خلال فترة مراجعة، ولا تُسحب منه تلك الصلاحية أبداً!
ومع مرور السنين، يكون النظام قد فقد "نظامه"، فنجد كل الأدوار تمتلك الصلاحيات العامة ذاتها، من دون أن يُعرف السبب وراء ذلك. إنَّ المعلومات المحفوظة في أنظمة الموارد البشرية لا تقل حساسية وأهمية عن المعلومات المالية، وهي ذاتها المعلومات التي تصبح لدى الجميع بسبب فقدان التحكم في الصلاحيات.
التصميم التقليدي للصلاحيات يعجز عن مجاراة الزمن؛ إذ يخلّف كل انتقالٍ للموظف ذيولاً من صلاحياتٍ تسربت دون قصد.
يظل المرجع لأي صلاحية هو نشاطات الموظف، لا مسماه الوظيفي.
لا يكون الحل في استحداث المزيد من الأدوار؛ فإن الاستمرار في إضافة أدوار جديدة لتغطية كل مزيج أو احتمال ممكن يُدخلك في مأزق «تضخم الأدوار» (Role Explosion). وهو المأزق الذي تنتهي فيه أي منصة باحتواء مائتي دور شبه متطابق لا تختلف عن بعضها سوى بصلاحية واحدة، لتتحول إدارة الصلاحيات نفسها إلى كابوس تنظيمي!
يتطلب الحل الحقيقي التوقف عن التفكير بمنطق المسميات الوظيفية، والبدء في التفكير بسؤالين أكثر بساطة، يحددان معاً الصلاحيات اللازمة لكل دور مع وجود سبب واضح.
- ما يحتاج الموظف إلى فعلهيتعلق السؤال الأول بما يحتاج الموظف إلى فعله تحديداً داخل النظام. فلا نستفيد أي شيء بمعرفتنا انتماء موظف ما إلى فريق الأداء، بل يتوجب علينا معرفة ما هو دوره في دورة التقييم، سواء أكان الاطلاع عليها، أم إنشاءها، أم تعديلها، أو حذفها. فهذه تعد أربع صلاحيات مستقلة، لا صلاحية واحدة، ونادراً ما تحتاجها وظيفة واحدة في آنٍ واحد. لو نظرنا إلى منسق التدريب: يقتضي عمله في بناء المسارات التطويرية إنشاء المحتوى وتعديله، فقد يستند إلى إطار الجدارات، أما حذف هذا الإطار فخارج عن نطاق مهامه. وكذلك مسؤول الأداء؛ فإدارة دورة التقييم تتطلب منه إنشاء التقييمات والإشراف عليها، في حين يكفيه الاطلاع على بيانات الجدارات التي تُبنى عليها هذه التقييمات، دون أن يمتد وصوله إلى تعديلها.
- حدود البيانات التي يحق له الوصول إليهاويتعلق السؤال الثاني بحدود البيانات التي يحق للموظف الوصول إليها. فقائد الفريق مثلاً تقتصر حاجته، عند تقييم أداء موظفيه، على نتائج فريقه دون سواه. أما مدير التدريب والتطوير، فقد يستدعي قياس أثر برامجه اطلاعه على معدلات الإنجاز على مستوى المنشأة كلها، شرط أن يقتصر وصوله على الأرقام الإجمالية، فتُحجب عنه إجابات الموظفين الفردية على الاستبيانات. وبهذا المنطق، لا يُعدّ «الاطلاع على الأداء» صلاحيةً واحدة؛ فبين «الاطلاع على أداء فريقي» و«الاطلاع على أداء الجميع» اختلاف شاسع في درجة الحساسية، ويتعامل النموذج الرصين معهما بوصفهما صلاحيتين منفصلتين.
وبالجمع بين السؤالين، أي طبيعة الإجراء ونطاق البيانات، يمكن تحديد ما يحق لكل موظف فعله بدقة، دون اللجوء إلى مسمى وظيفي فضفاض. إن هذا التحول هو ذاته الشوط الذي قطعته البرمجيات الحديثة عالمياً؛ بالانتقال من «الأدوار الجاهزة» التي تُجمع فيها كافة الصلاحيات، إلى «الصلاحيات الدقيقة» التي تتشكل بمرونة ودرجة عالية من الحوكمة. وقد حان الوقت لتطبيق هذا المفهوم في أنظمة الموارد البشرية بالذات، نظراً لحساسية بياناتها وكونها تستحق هذا المستوى من التحكم والحماية.
لماذا تفرض معظم الأنظمة قيوداً خفية تحدّ من مرونة منشأتك؟
ثمة جانب تمرّ عليه العروض التوضيحية عادةً مرور الكرام: فغالبية منصات الموارد البشرية وإدارة المواهب في السوق تعرض عليك شاشة «إدارة الصلاحيات» بكل بساطة، غير أن معظمها يعاني من قيود جوهرية تنحصر في نوعين رئيسين، وكثيراً ما يجتمعان. ويكفي أن تستوعب هذه القيود لتدرك مدى أهمية هذه المسألة وخطورتها على كفاءة العمل.
يتمثّل القيد الأول في قائمة ثابتة من الأدوار: مسؤول النظام، والمدير، والموظف، وربما مسؤول الموارد البشرية، وتنتهي القائمة بذلك. على الرغم من قدرتك على تفعيل بعض الخيارات أو تعطيلها ضمن كل دور، إلا أنك لا تستطيع أن تنشئ ملف صلاحيات جديداً، يُفصَّل على مقاس وظيفة لم يتوقعها مزوّد المنصة.
فإذا احتاج الشخص المسؤول عن الجدارات ومسؤول التدريب والتطوير إلى صلاحيات لا تنطبق على أيٍّ من هذه القوالب الأربعة، ينتهي بك المطاف إلى «الإفراط في منح الصلاحيات». فيحصل كلٌّ منهما على أقرب دور يغطي احتياجه، ويحصل معه على فائضٍ من الصلاحيات التي لا شأن له بها؛ إذ لم تترك لك الأداة أي وسيلة لرسم الحدود بدقة أكبر. وبذلك يكون المنتج نفسه من فرض هذا الإفراط.
أما القيد الثاني فأخفى أثراً، وأضراره متعددة الأوجه؛ إذ تتيح لك بعض المنصات إنشاء أدوار مخصصة، دون إمكانية تحديد نطاق الوصول إلى البيانات، لتغدو الصلاحية إما شاملة للمنشأة كلها أو معدومة. وعندها يعني «الاطلاع على الأداء» الاطلاع على أداء الجميع، ولا مجال لخيار «الاطلاع على أداء فريق الموهبة فقط».
وهكذا يصبح قائد الفريق، الذي يُفترض ألا يتجاوز اطلاعه ستة موظفين، قادراً على رؤية بيانات ستة آلاف موظف، وذلك لأن النموذج يعجز عن توفير صلاحية ذات نطاق أضيق. وحين تبلغ الصلاحية هذا الحد من العمومية، تجد نفسك أمام خيارين أحلاهما مرّ: إما أن تعطل الصلاحية كلياً فيتعطل سير العمل، أو أن تمنحها كاملة فتُنتهك خصوصية بيانات الموظفين.
وهذه القيود تفرض على العملاء اللجوء إلى الحل الخاطئ. فعندما تعجز الأداة ذات الأدوار الثابتة عن تلبية ما تحتاج إليه، غالباً ما يكون حل مزوّد الخدمة هو «إضافة دور جديد»، ثم دور آخر، فآخر، حتى تجد نفسك تنظر إلى عشرات الأدوار شبه المتطابقة التي لا يفرّق بينها سوى خيار واحد.
وهذا هو مأزق «تضخم الأدوار» (Role Explosion)؛ ولا يُعدّ ذلك دليلاً على المرونة، بل هو بمثابة "الندوب التنظيمية" الناجمة عن إجبار نموذج صلب على التمدد ليغطي واقعاً لم يُصمم له في الأصل. كل دور من هذه الأدوار يحتاج إلى صيانة ومراجعة وتدقيق مستمر، ولن يمضي عام واحد حتى يعجز أي شخص في المنشأة عن معرفة الفرق بين دور «مدير» ودور «مدير 2» دون فتح شاشة الإعدادات للمقارنة بينهما!
المنصة التي تُعالج كل احتياج جديد بإضافة دور جديد لا توفّر لك المرونة؛ بل تُحمّلك عبئاً تشغيلياً مُتنكراً في صورة ميزة.
ولهذه المشكلات الثلاث مخرجٌ واحد، يعود إلى البنية التحتية للنظام لا المظاهر الخارجية. فبدلاً من أن يكون الدور هو الوحدة التي تُبنى عليها الصلاحيات، تتحول هذه الوحدة لتبنى على أساس «الخصائص» (Capabilities) و«النطاقات» (Scopes)، ويُترك للمنشأة أن تُشكّل منها ما تحتاج إليه. وهو الأساس الذي اخترناه في منهجية بناء نظام لوموفاي (Lumofy).
من الفكرة إلى المنتج
يُعبّر هذا المنظور عن الفلسفة التي استندنا إليها عند بناء وحدة الصلاحيات الجديدة في لوموفاي (Lumofy)، ونفضّل أن نستعرض هذا الحل عملياً بدلاً من الاكتفاء بوصفه؛ فالخيارات التصميمية التي اتُّخذت هي خير برهان على الفارق. فبدلاً من الانحصار في قوالب معدودة لأدوار ثابتة، تُتيح لك هذه الوحدة تشكيل «ملف الصلاحيات» (Permission Profile) قسماً تلو الآخر في المنصة بأكملها، نزولاً إلى مستوى كل إجراء بعينه.
يُبنى ملف الصلاحيات قسماً تلو الآخر؛ فلكل خاصية مفتاح تفعيل خاص بها، سواء أكانت الاطلاع على «خريطة ذكاء القوى العاملة»، أم إدارة المستخدمين، أم تعديل إطار الجدارات، أم إدارة دورة الأداء، ولكلٍّ منها نطاق بيانات محدد. ويظهر هنا ملف صلاحيات لدور «مدير» يقتصر نطاقه على «فريق الموهبة فقط» (Own Team Only)، لا على المنشأة كلها.
وفي هذه الشاشة أمران تفوق أهميتهما ما يبدوان عليه للوهلة الأولى. أولهما «محدد النطاق» المجاور لكل خاصية، أي خيار «فريق الموهبة فقط» (Own Team Only)؛ فبهذا الاختيار وحده يتحدد الفرق بين مدير يرى خريطة فريقه، ومسؤول نظام يرى خريطة المنشأة كلها.
فالخاصية ذاتها، أي الاطلاع على «خريطة ذكاء القوى العاملة»، تتحول إلى صلاحية مختلفة كلياً بحسب النطاق المرتبط بها؛ إذ يتعامل النظام مع هذا النطاق بوصفه ركناً أساسياً في منح الصلاحية، بعيداً عن كونه إضافة ثانوية على نظام صلب في أساسه.
أما الأمر الثاني فقد لا تكتشفه من النظرة الأولى، وهو في نظرنا يُعدّ نقطة قوة: فالنظام يدرك متى يكون مزيج الصلاحيات غير منطقي، ويرفض بناءه من الأساس. فإذا حصرت نطاق المدير في الاطلاع على فريقه فقط، فلن تسمح لك المنصة بأن تمنحه أيضاً صلاحية إضافة مستخدمين جدد على مستوى المنشأة، وستوضح لك السبب بعبارة واضحة.
فمنح الصلاحيات المتناقضة ليس مجرد ممارسة «غير مستحسنة»، بل هو أمر يمنعه النظام، وهي النقطة ذاتها التي توصي بها كافة أدلة حوكمة أمن البيانات والتحكم بالوصول، في الوقت الذي لا تكاد منصة موارد بشرية واحدة تطبّقه فيه.
صلاحيات تُحاكي واقع مهام الموارد البشرية
تكمن الفائدة العملية لهذا النهج في قدرتك على بناء ملفات صلاحيات تعكس صورة فريق الموارد البشرية كما هو في الواقع، بدلاً من تقييد الفريق في ثلاثة أدوار عامة. ولتوضيح ذلك نستعرض ثلاثة أمثلة عملية تمثّل أكثر ملفات الصلاحيات طلباً واستخداماً لدى عملائنا:
- الملف المخصص لإدارة الجدارات: مُصمَّم لمن يتولى إطار الجدارات و«خريطة ذكاء القوى العاملة». يستطيع صاحبه الاطلاع على الإطار وتعديله، ورؤية خريطة الجدارات على مستوى المنشأة، وإدارة تقييمات الجدارات. في المقابل، لا يمكنه الوصول إلى درجات تقييم الأداء أو بيانات الرواتب والمزايا، لأن عمله لا يتقاطع معها أصلاً؛ ويرسم النظام هذا الفصل بوضوح.
- الملف المخصص لإدارة الأداء: مُصمَّم لمن يدير دورات التقييم. يستطيع صاحبه إنشاء دورات الأداء وجدولتها وإدارتها، والاطلاع على بيانات الجدارات التي يستند إليها التقييم العادل، لكنه يطَّلع على هذه البيانات فحسب، فلا يمكنه تعديل إطار الجدارات الأساسي. ويتحدد نطاقه بحسب مستواه الوظيفي، فإما أن يقتصر على فريقه أو يشمل المنشأة كلها؛ وبذلك يعمل قائد الفريق وشريك الأعمال في الموارد البشرية (HRBP) بالخاصية نفسها، كلٌّ ضمن النطاق المناسب لحاجته.
- الملف المخصص لإدارة التدريب والتطوير: مُصمَّم لمن يبني المسارات التطويرية والمحتوى التدريبي. يستطيع صاحبه إنشاء الدورات التدريبية والمسارات والأدلة وسائر مكتبة المحتوى وتعديلها، وتسجيل الموهوبين فيها، والتحكم في ما يظهر لهم منها. كما يتيح له الملف متابعة معدلات التفاعل والإنجاز لقياس أثر التدريب، لكنه يبقى بمعزل عن بيانات الأداء والرواتب الفردية التي من شأنها أن تحوّل أداة التطوير إلى أداة مراقبة.
وهذه الملفات الثلاثة ليست سوى نقطة انطلاق؛ فوحدة الصلاحيات لا تضع حداً أقصى لعدد الملفات التي يمكنك إنشاؤها، لأن هذه الملفات ليست قائمة جاهزة نتولى نحن صيانتها، بل تشكيلات تبنيها أنت بنفسك وفق متطلبات عملك. فإذا احتاجت منشأتك إلى ملف صلاحيات مخصص للانتقال أو الحراك الوظيفي يطّلع على خريطة الجدارات وبيانات التعاقب الوظيفي دون المساس بأي عنصر آخر، فيمكنك بناؤه بسهولة. وفي حال اشترطت عليك لوائح حماية البيانات الإقليمية أو الهيئات التنظيمية ملفاً لا يمكنه رؤية نتائج استبيانات التفاعل إلا في صورتها الإجمالية، مع حجب الإجابات الفردية، فيمكنك بناء ذلك أيضاً.
أما مدقق الامتثال (Compliance Auditor) فيحتاج إلى الاطلاع على كل البيانات من دون تعديل أي شيء؛ وتشكيل ملفه لن يستغرق منك سوى دقيقتين، ولا يتطلب فتح طلب دعم عند مزوّد المنصة. فعدد الملفات التي يمكنك إنشاؤها لم يُصمَّم ليكون معياراً للترقية بين باقات الاشتراك أو قيداً بحدٍ أقصى، بل ليواكب عدد الوظائف المختلفة التي يؤديها موظفوك فعلاً.
وهنا يكمن الفارق الذي يتضاعف أثره مع الوقت. فالأداة القائمة على أدوار ثابتة تجبرك على تغيير طريقة عمل منشأتك وفق افتراضاتها، فيتحول كل تعارض بين النظام والواقع إما إلى منح صلاحيات زائدة عن الحاجة أو إلى حلول غير عملية ومؤقتة. أما النموذج القائم على المرونة في تصميم الصلاحيات فيبدأ من المهام التي ينجزها هذا الشخص تحديداً، ومن البيانات التي يحتاج إليها، ومنها يتكون لديك الملف الخاص بهذا الدور وبهذا المستوى خصيصاً لمنشأتك، مهما تعددت هذه الأدوار ومستوياتها.
ومع النمو، سواء عند إضافة وظائف جديدة، أم عند التوسع إلى أسواقٍ تتطلب قواعد خصوصية مختلفة، أم حتى عند إعادة هيكلة الفرق في المنشأة، فلن تضطر إلى طلب ميزات جديدة من المزوِّد والانتظار؛ بل ستبني ملف الصلاحيات الذي تحتاج إليه وتواصل سير العمل الطبيعي.
تعرض الشاشة «الأدوار الأساسية» (Primary Roles) لتغطية الاحتياجات المعتادة في الشركات والمؤسسات، و«مجموعات الصلاحيات» (Permission Sets) للملفات التي تبنيها بنفسك؛ والقصد لا ينحصر في الدورين الظاهرين، بل في أنك لن تكون مقيّداً بهما.
لماذا تُعدّ الصلاحيات ركيزةً للثقة، وليست مجرد صفحة إعدادات؟
قد يتراءى للبعض أن كل ما سبق يقع ضمن المهام الإدارية الإجرائية، مجرد شاشة إعدادات تُضبط مرة واحدة ثم تُنسى. غير أننا نرى العكس تماماً.
ففي منصة تحتفظ ببيانات الجدارات والأداء والتدريب والتفاعل لكل موظف، يمثّل نموذج الصلاحيات أصدق تعبير عن مدى ثقة المنشأة بالنظام وقدرته على حماية بيانات موظفيها. فكل خاصية نبنيها تفترض أن الشخص المناسب يطّلع على البيانات المناسبة، وتتكفّل وحدة الصلاحيات بتحويل هذا الافتراض إلى حقيقة.
لكن حين يُساء تصميم هذا النموذج، لا تبقى العواقب نظرية: فيطّلع على تقييم الأداء من لا شأن له به، ويصل إلى نطاق الأجور من لم يكن ينبغي له أن يراه، ويستطيع أخصائي التدريب، ومن دون أن يلحظ أحد، أن يعدّل إطار الجدارات الذي تُقاس به المنشأة بأكملها. كل حالة من هذه الحالات تُحدث شرخاً في الثقة لا يمكن لأكثر التحليلات والتقارير تقدماً في المنصة ترميمه. وفي المقابل، عندما تُضبط الصلاحيات بإحكام، يحدث أمر قد يمر مرور الكرام، لكنه بالغ الأثر: فيكفّ الناس عن القلق من النظام ويبدؤون في استخدامه، لشعورهم التام بأنه لا يعرض لكل فرد إلا ما يحق له رؤيته.
لقد تجاوزت الموارد البشرية منذ زمن بعيد كونها وظيفة واحدة، لتصبح منظومة من التخصصات المتمايزة: إدارة الجدارات، والأداء، والتدريب، والتفاعل، ولكلٍّ منها بياناته وأمانته تجاه أصحابها. غير أن البرمجيات التي تخدمها ظلت متأخرة عن مواكبة هذا التطور.
وكان منح هذه التخصصات كلها صلاحية موحدة حلاً وسطاً، يُتعايش معه بحكم الضرورة لأن البديل كان إما قائمة جامدة من الأدوار، وإما «تضخماً في الأدوار» يصعب ضبطه. أما اليوم، فلم يعد ذلك هو الحال.
فحين تستطيع تشكيل الصلاحيات انطلاقاً مما يؤديه الشخص من مهام ونشاطات، واستناداً للبيانات التي يحتاج إليها، تزول الحلول المؤقتة، ويتحول نموذج الصلاحيات من الحلقة الأضعف في المنصة إلى الركيزة التي تكتسب هيبة المنظومة وثقتها بفضل قدرتها على حماية البيانات كافة. وهذا هو المعيار الذي نلتزم به في بناء نموذج الصلاحيات في لوموفاي (Lumofy)؛ وإذا كان فريق الموارد البشرية لديك قد تجاوز حدود الأدوار العامة الثلاثة، فهذه دعوة لاستكشاف ما يمكن أن يقدمه هذا النموذج لمنشأتك عن قرب.
FAQ
يربط التحكم في الوصول القائم على الأدوار (RBAC) الصلاحيات بأدوار محددة، ويحصل كل موظف على صلاحياته من خلال الدور المسند إليه. وتنجح هذه الطريقة في أنظمة الموارد البشرية حين يعكس الدور المهام الفعلية للموظف ونطاق البيانات الذي يحتاج إليه، إذ يمنح الدور المبني على اسم القسم في الغالب صلاحيات تتجاوز حاجة الوظيفة.
هو منح الموظف صلاحيات تتجاوز احتياج وظيفته، كأن يستطيع مسؤول تقييم الأداء تعديل بيانات الجدارات وسجلات التدريب وإجابات الاستبيانات. ويُعد ذلك خطراً منذ لحظة منح الصلاحية، لأن أي خطأ أو اختراق للحساب قد يمتد أثره إلى المنصة بأكملها.
هو تراكم الصلاحيات لدى الموظف مع تنقله بين المهام والفرق. فتُمنح صلاحية لتكليف مؤقت أو لاستثناء لمرة واحدة ثم لا تُسحب، حتى يصبح الموظفون قادرين على رؤية بيانات لا يتذكر أحد متى مُنحت لهم.
يحدث تضخم الأدوار حين تعالج المنصة كل احتياج جديد بإضافة دور جديد، حتى تمتلئ بعشرات الأدوار شبه المتطابقة التي لا يفرّق بينها سوى خيار واحد. ويحتاج كل دور منها إلى صيانة ومراجعة مستمرة، فتتحول إدارة الصلاحيات نفسها إلى عبء تشغيلي.
بتحديد الوصول وفق أمرين: الإجراءات التي يحتاجها الموظف (الاطلاع، والإنشاء، والتعديل، والحذف)، ونطاق البيانات الذي يحتاج إليه (فريقه فقط أو المنشأة كلها). ويكفي الجمع بين الأمرين لوصف أي صلاحية مشروعة دون إنشاء دور جديد لكل حالة.
