تم إطلاق خدمة برمجية (SaaS) مساء يوم الجمعة. وبحلول صباح السبت، تعذر على العملاء تسجيل الدخول، وتكدست طلبات الدعم الفني، وأشارت صفحة حالة الخدمة لدى المورّد إلى وجود انقطاع جزئي؛ وهنا يتساءل الراعي (صاحب المشروع) عن سبب عدم رصد إدارة المخاطر لهذا الأمر مسبقاً.
قبل تحديث سجل المخاطر، يتعين عليك الإجابة عن سؤال أكثر صعوبة: هل كانت هناك إشارة خطر حقيقية كان بإمكانك التصرف بناءً عليها، أم أنك تحوّل قراءة الأحداث بأثر رجعي إلى وسيلة لتوجيه اللوم؟ يطرح هذا الدرس منهجية جاهزة لنظام الحوكمة تتيح التمييز بين الإشارات القابلة للرصد والمفاجآت الحقيقية، وتصنيف النتائج، وتحديد المجالات التي يمكن للذكاء الاصطناعي المساعدة فيها دون السماح له بأن يصبح هو صاحب القرار.
للبدء، انظر إلى الحادثة باعتبارها تسلسلاً زمنياً للأحداث، وليس مجرد نتيجة نهائية؛ وحدد المعلومات التي كانت متاحة في ذلك الوقت، ومن كان يمتلكها، وما الذي كان بإمكان مدير مشروع يتمتع بالكفاءة والمنطق فعله بتلك المعلومات.
من الأخطاء الشائعة اعتبار كل نتيجة سلبية أمراً يمكن التنبؤ به. ورغم أن هذا التصرف قد يوحي بالمسؤولية، إلا أنه يدفع الفرق إلى الإفراط في توثيق المخاطر قليلة الأهمية وتجاهل المؤشرات القليلة الجوهرية.
أثناء انقطاع الخدمة، غالباً ما تتداخل أربعة أنواع مختلفة من البيانات، كما أن مخرجات الذكاء الاصطناعي ستمزج بينها ما لم تفرض قواعد محددة.
المخاطرة (Risk): حدث مستقبلي غير مؤكد، يؤثر على الأهداف في حال وقوعه. مثال: قيود معدل الاستخدام (rate limits) في خدمة المصادقة الخاصة بالمورد أثناء ذروة الضغط في عطلة نهاية الأسبوع المخصصة للإطلاق.
المشكلة (Issue): خلل حالي قد وقع بالفعل. مثال: يتلقى المستخدمون حالياً أخطاء من النوع “500” عند محاولة تسجيل الدخول.
الافتراض (Assumption): أمر تتعامل معه كحقيقة لأغراض التخطيط، رغم احتمالية كونه غير صحيح. مثال: سيحافظ المورد على مستويات السعة الحالية طوال الربع السنوي.
الاعتمادية (Dependency): مخرجات خارجية أو شرط يحتاجه مشروعك. مثال: إتمام المورد لفترة الصيانة المخطط لها قبل موعد الانتقال للنظام الجديد (cutover).
سؤال للتنبؤ: أي خطأ في التصنيف يتسبب في أسوأ تأخير لعملية التصعيد (escalation) أثناء انقطاع الخدمة؟
تدرب الآن على تطبيق هذه التصنيفات بدقة، حيث تعتمد عملية الحوكمة لديك على اتساق التصنيف قبل الانتقال لمرحلة تحديد الأولويات.
من الأخطاء الشائعة الميل إلى تصنيف كل شيء على أنه “مخاطرة” لمجرد إبقاء الخيارات مفتوحة؛ وتتمثل النتيجة في عدم تولي أي جهة مسؤولية معالجة المشكلات الحقيقية وحلها، فضلاً عن عدم التحقق من صحة الافتراضات أبداً.
لكي تصمد ممارسات إدارة المخاطر لديك أمام عمليات التدقيق، لا يمكنك الاعتماد على قائمة غير رسمية ضمن محادثة؛ بل تحتاج إلى وثائق وسجلات تعكس نهجاً متسقاً وسجلاً لتاريخ اتخاذ القرارات.
يُقصد بتصنيف المخاطر (Risk Taxonomy) مجموعة منظمة من الفئات المستخدمة لتجميع المخاطر، مما يضمن اتساق التقارير عبر المشاريع المختلفة. ويساعد هذا التصنيف في الحد من المشكلات الناجمة عن تباين المصطلحات—مثل قيام مدير مشروع بتسجيل “مخاطر الموردين” بينما يسجل آخر “موثوقية الطرف الثالث”—مما يحول دون القدرة على تجميع الاتجاهات وتحليلها.
أما سجل المخاطر (Risk Register) فهو القائمة الخاضعة للرقابة التي تضم المخاطر المحددة وبيانات إدارتها. وعادةً ما تتطلب معايير الحوكمة وجود حقول محددة، مثل: معرف المخاطرة، بيان المخاطرة، السبب، الحدث، الأثر، الاحتمالية، درجة الأثر، مستوى التعرض للمخاطرة، مالك المخاطرة، استراتيجية الاستجابة، إجراءات الاستجابة، التاريخ المستهدف، الحالة، المحفزات، وتاريخ آخر مراجعة. ويتحقق مسار التدقيق (Audit Trail) من خلال توضيح التغييرات التي طرأت، وتوقيت حدوثها، والجهة التي اعتمدتها.
سؤال استنتاجي: ما هو الحقل المفقود في السجل الذي يجعل من الصعب إثبات أنك قمت بإدارة المخاطرة فعلياً، وليس مجرد تسجيلها؟
قارن بين ما تعجز القائمة غير الرسمية عن إثباته وبين ما يمكن للسجل الخاضع للحوكمة إثباته.