قبل جدول RACI: من يملك القرار فعلًا؟

المشكلة ليست في غياب الجدول وحده

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

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

ما السبب الجذري لتضارب المسؤوليات؟

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

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

اختبر القرار قبل رسم RACI

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

مصدر الصورة: Pexels.

• من يوصي بالقرار ومن يعتمده؟
• ما حدّ الصلاحية ومتى يتغير؟
• ما الدليل الذي يجب تسجيله بعد القرار؟

مرتبط بهذه الفكرة: SharePoint مش مجرد فولدرات: نظّم ملفات الشركة وملكيتها

ابدأ بنطاق صغير قابل للاختبار

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

جرّب القاعدة أسبوعين على عملية واحدة، وراجع القرارات التي عادت للإدارة رغم التفويض.

مثال افتراضي: خصم يظل معلقًا

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

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

كيف نعرف أن توزيع القرار نجح؟

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

• لكل قرار صاحب واضح وحدّ صلاحية معتمد.
• يوجد سجل مختصر للقرار والاستثناء.
• تراجع أسبوعي يكتشف القواعد التي لم تعمل.

سجل قرارات قبل رسم RACI

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

بعد أسبوعين، قِس عدد القرارات التي توقفت عند الإدارة من غير داعٍ. مصفوفة الأدوار تكون مفيدة فقط عندما تعكس سلطة فعلية.

الخطوة التالية: صمّم التشغيل قبل الأداة

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

Digital Business Foundation مناسب عندما تحتاج الشركة تحويل هذه القواعد إلى تشغيل موثق وأدوات رقمية متسقة.

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