كيف يساعد نظام التذاكر في تطبيق ممارسات ITIL؟

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

الفهم الأصح: ITIL مجموعة أنماط مجرّبة لمشكلات شائعة. اقرأه كصندوق أدوات — خذ منه ما يعالج مشكلة تعاني منها فعلًا، واترك الباقي حتى تحتاجه. الأداة الجيدة تسهّل ذلك؛ لكنها لا تقرّر عنك.

ما هو ITIL وما ليس هو

الفرق العملي مهم لمدير التقنية: حين يسألك مديرك «هل نحن متوافقون مع ITIL؟» فالسؤال نفسه مبني على فهم خاطئ. الإجابة الصحيحة ليست نعم أو لا، بل: «تبنّينا ممارسات إدارة الحوادث والطلبات لأننا كنا نعاني من كذا، ولم نتبنّ إدارة التغيير الرسمية بعد لأن بيئتنا لا تستدعيها.» هذا كلام مدير يعرف ما يفعل — لا كلام من يقيس نفسه بقائمة.

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

من أين تبدأ؟ ترتيب الممارسات بالعائد

ليست كل الممارسات متساوية في العائد ولا في التكلفة. الترتيب أدناه يعكس ما يفيد أغلب المؤسسات المتوسطة — لا حكمًا مطلقًا:

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

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

ماذا يفعل نظام التذاكر فعلًا؟

النظام لا «يطبّق ITIL». ما يفعله أنه يجعل قرارات نظّمتها أنت قابلة للتنفيذ باتساق — ويمنع الانحراف عنها تحت الضغط. والفرق بين الاثنين هو الفرق بين أداة تخدم ممارسة وأداة تُنتظر منها معجزة:

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

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

مسار تبنٍّ لا يفشل

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

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

الأسئلة الشائعة