قرار CMDB الذي يحسم مصير برنامج ITSM لديك

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

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

هذه أشيع الطرق التي يفشل بها برنامج ITSM وهو يبدو ناجحًا.

لماذا يكون سير العمل هو الجزء السهل

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

أما قاعدة بيانات إدارة التهيئة (CMDB) فتختلف في ثلاثة أوجه مهمة:

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

النقطة الأخيرة هي الأخطر. الفرق لا تفقد ثقتها في CMDB لأنها تعطلت. تفقدها لأن أحدهم راجع أخيرًا تقييم أثر يدويًا فوجد أنه فاته نصف الأنظمة المتأثرة.

القرار، بوضوح

كم من بيانات التهيئة تبني قبل الإطلاق؟

نمطا الفشل متناظران، وكلاهما شائع.

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

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

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

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

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

اختبار انتماء الفئة إلى النطاق بسيط، ويستحق أن يُطبَّق بصدق: سمِّ سير العمل الذي سيقرأ هذه البيانات الشهر القادم. إن لم تستطع، فالفئة ليست جاهزة للتعبئة. وستصبح جاهزة حين يعتمد عليها شيء ما — وتعبئتها حينها أرخص، لأن سير العمل الذي يستهلكها هو نفسه ما يختبرها، وهذا ما يُبقي البيانات دقيقة.

نمذجة الخدمات قرار منفصل

رسم خرائط الخدمات (Service Mapping) هو ما يحوّل CMDB من جرد إلى شيء يستطيع الإجابة عن أسئلة الأعمال. وهو أيضًا أغلى ما في معظم برامج ITOM وITSM، وتكلفته ليست موزعة بالتساوي.

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

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

السؤال التنظيمي المختبئ داخل السؤال التقني

كل نقاش حول CMDB يصل في النهاية إلى الملكية: من يملك عنصر التهيئة (CI) حين لا يريده أي فريق؟

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

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

ماذا يعني هذا إن كنت تحدد نطاق برنامج الآن

ثلاثة أسئلة تستحق أن تطرحها على شريك التنفيذ لديك، أيًّا كان:

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

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