الحوكمة ليست بيروقراطية. الحوكمة الضعيفة هي البيروقراطية.

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

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

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

ما الغاية الحقيقية من الحوكمة

إذا جرّدتها من المصطلحات، تجيب حوكمة تقنية المعلومات عن ثلاثة أسئلة:

1. من يقرر؟ صلاحيات القرار: للإنفاق، وللتغيير، ولقبول المخاطر، وللأولويات.
2. كيف يبدو الأداء الجيد؟ مستويات الخدمة والضوابط والنتائج التي اتفقنا عليها.
3. كيف نعرف؟ الأدلة والتقارير التي تبيّن هل يتحقق ذلك.

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

سؤال $2.5M الذي لم يطرحه أحد

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

لم يجرِ ذلك. كان خلل في توافق VPN كامنًا في تلك الفجوة. ورصده قبل الاعتماد النهائي حال دون أثر متوقع على الأعمال بقيمة $2.5M.

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

خمس علامات على أن حوكمتك تحولت إلى بيروقراطية

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

تصميم حوكمة تسرّع العمل

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

دوّن صلاحيات القرار كتابةً. مصفوفة RACI من صفحة واحدة لقراراتك الرئيسية تزيل من الاحتكاك أكثر مما تزيله أي أداة.

صمّم اتفاقيات SLA انطلاقًا من الأعمال. ابدأ بما يحتاجه المتجر أو المصنع أو السفينة فعلًا، ثم ضع الأهداف واتفاقيات OLA التي تدعمه. هكذا يصبح الامتثال لـ SLA ذا معنى لا شكليًا.

اجعل حوكمة الموردين روتينًا لا عملية إنقاذ. مراجعات خدمة شهرية مقابل العقد، مع مسارات تصعيد واضحة، تمنع تحوّل تعثرات الموردين إلى حوادث. فتوحيد الموردين المنضبط وحوكمة دورة حياة الأصول هما ما ساعدني على خفض تكاليف تقنية المعلومات الإقليمية بنسبة 15% (AED 5.5M)، لا بالتهاون، بل بمعرفة ما يُدفع مقابله بالضبط.

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

الاختبار

إليك اختبارًا بسيطًا لأي إجراء حوكمة: لو ألغيته غدًا، ما الذي سيسوء، وبأي سرعة سيلاحظ أحد ذلك؟

إن كان الجواب "لا شيء"، فألغِه. وإن كان الجواب "سيصل خلل بقيمة $2.5M إلى الإنتاج"، فتلك حوكمة تؤدي عملها، وتستحق الحماية.

الحوكمة ليست بيروقراطية. الحوكمة الضعيفة هي البيروقراطية. والفارق هو هل صُمّمت عن قصد.