مخطط انسيابي لعملية إدارة التغيير (ITIL)
مخطط انسيابي لعملية إدارة التغيير وفق ITIL يغطي استلام طلب التغيير وفرزه إلى قياسي وعادي وطارئ، واعتماد لجنة CAB، والجدولة، والتنفيذ، وخطة التراجع.
ما هي مخطط انسيابي لعملية إدارة التغيير (itil)؟
إدارة التغيير في هذا القالب تعني إدارة تغيير خدمات تقنية المعلومات: العملية الدائمة التي يمرّ بها كل تغيير على خدمة قائمة، من رفع طلب التغيير حتى إغلاق سجله. وهي ليست إدارة التغيير المؤسسي، أي الجانب البشري المرتبط بنماذج مثل ADKAR أو خطوات كوتر الثماني، رغم أن الاثنتين تُسمّيان عادةً «عملية إدارة التغيير». والنسخة المرسومة هنا هي النسخة التشغيلية بأسلوب ITIL، التي يديرها مدير التغيير ولجنة مراجعة التغيير باستمرار.
معظم القيمة تكمن في قرار واحد قرب البداية: ما نوع هذا التغيير؟ فتمرير كل شيء عبر التقييم الكامل نفسه واجتماع اللجنة الأسبوعي نفسه يصنع طابوراً، والطابور هو ما يدفع الناس إلى إجراء التغييرات خارج العملية. لذلك يفرز هذا المخطط مرة واحدة ومبكراً. التغييرات القياسية معتمدة مسبقاً مقابل نموذج تغيير موثّق وتذهب مباشرةً إلى الجدولة. والتغييرات العادية تخضع لتقييم المخاطر والأثر ثم تُعرض على اللجنة. والتغييرات الطارئة تحصل على اعتماد مُعجَّل من لجنة الطوارئ ثم تعود إلى المسار نفسه في الجدولة والتنفيذ والمراجعة، فلا يكون الإصلاح العاجل إصلاحاً بلا سجل.
والأمر الآخر الذي يحسمه المخطط هو الملكية، ولهذا رُسم كمسارات: مقدّم الطلب، ومدير التغيير، ولجنة CAB، وفريق التنفيذ، ومالك الخدمة. ولمالك الخدمة مسار خاص لأن التحقق هو الخطوة التي تغفلها الفرق أكثر من غيرها. فقولك «تم النشر» وقولك «الخدمة تعمل» ادعاءان مختلفان، والفارق بينهما هو سبب وجود مسار التراجع أصلاً. في هذا المخطط يُفعّل التحقق المخفق خطة التراجع، ويصل التغيير الناجح والتغيير المتراجَع عنه كلاهما إلى المراجعة اللاحقة للتنفيذ ثم الإغلاق.
ما الذي يغطيه هذا المخطط
في هذا القالب
- الاستلام عبر مساري مقدّم الطلب ومدير التغيير: رفع طلب تغيير، وتسجيله في سجل التغييرات، ثم مرشّح الاكتمال عند «الطلب مكتمل وضمن النطاق؟» الذي يعيد الطلبات الناقصة إلى مقدّمها لاستكمال التفاصيل قبل دخول الفحص نفسه من جديد
- الفرز الثلاثي عند «نوع التغيير؟» الذي يرسل التغييرات القياسية مباشرةً إلى تقويم التغييرات، والعادية إلى تقييم المخاطر وأثر الخدمة، والطارئة إلى اعتماد لجنة ECAB
- التقييم والاعتماد: تقييم المخاطر وأثر الخدمة، وتوثيق التقييم وخطة التراجع في سجل واحد بدل سلسلة تعليقات، ثم مراجعة لجنة CAB وقرار الاعتماد أو الرفض، على أن ينتهي التغيير المرفوض عند نقطة «رفض التغيير وإغلاقه» في مسار مقدّم الطلب
- الجدولة، حيث تلتقي المسارات المعتمدة والطارئة والقياسية عند تقويم التغييرات وتمرّ بفحص تعارض مع التغييرات المجدولة الأخرى يعيد الحالات المتعارضة إلى إعادة الجدولة
- البناء والتنفيذ في مسار فريق التنفيذ: بناء التغيير واختباره، ثم تنفيذه ضمن النافذة المعتمدة
- التحقق والإغلاق: يتحقق مالك الخدمة من الخدمة ويجيب عن «هل نجح التغيير؟»، والإخفاق يشغّل خطة التراجع، ويلتقي المساران عند المراجعة اللاحقة للتنفيذ ثم إغلاق سجل التغيير
متى تستخدم هذا القالب
- كتابة إجراء إدارة التغيير بأسلوب ITIL أو تحديثه لفريق مكتب خدمة أو منصة أو بنية تحتية يعمل حالياً بالعادة وسلاسل الرسائل
- الاتفاق على ما يُعدّ قياسياً وعادياً وطارئاً قبل ضبط أنواع التغيير في ServiceNow أو Jira Service Management أو Freshservice، لتعكس الأداة قراراً اتخذته بالفعل بدل أن تخترع واحداً
- تأهيل مديري تغيير جدد أو أعضاء لجنة أو مهندسي مناوبة يحتاجون معرفة أي التغييرات يلزمها اعتماد ومن يمنحه وما يحدث خارج أوقات العمل
- توثيق كيفية تقييم التغييرات واعتمادها واختبارها والتراجع عنها أمام مدقّق أو عميل، مثلاً مقابل المعيار CC8.1 في SOC 2 أو الضابط A.8.32 في ISO/IEC 27001:2022. المخطط يوثّق الإجراء، أما الدليل فهو سجلات التغيير التي ينتجها
- خفض معدل التغييرات المخفقة بعد ربع سنة سيئ، حين تحتاج أن ترى بالضبط أين يقع التحقق والتراجع ومن يملكهما
كيف تعمل
أعد تسمية المسارات لتطابق أدوارك الحقيقية
استبدل مقدّم الطلب ومدير التغيير ولجنة CAB وفريق التنفيذ ومالك الخدمة بوظائفك الفعلية. في مؤسسات كثيرة يكون شخص واحد مدير التغيير ورئيس اللجنة معاً، والفرق الأصغر لا تملك فريق تنفيذ مستقلاً أصلاً. ادمج تلك المسارات بدل رسم هيكل لا وجود له، وأبقِ العدد عند خمسة مسارات أو أقل وإلا توقف المخطط عن كونه مقروءاً بنظرة واحدة.
عرّف أنواع التغيير الثلاثة عند قرار الفرز
اكتب ما ينطبق عليه القياسي والعادي والطارئ بجوار قرار «نوع التغيير؟»، واضبط الحدود بحسب المخاطر ونطاق التأثير لا بحسب الجهد أو حجم التذكرة. وأبقِ قائمة التغييرات القياسية المعتمدة مسبقاً قصيرة بما يكفي ليتولى أحدهم صيانتها فعلاً، وامنح كل تغيير قياسي نموذج تغيير موثّقاً يلتزم به.
سمِّ جهة صلاحية التغيير ووتيرتها ومقابلها الطارئ
عند خطوة مراجعة اللجنة، دوّن من هم المعتمِدون، وكم مرة يجتمعون، وموعد إقفال جدول الأعمال. وعرّف لجنة الطوارئ بشكل منفصل: فمن يستطيع اعتماد إصلاح خارج أوقات العمل نادراً ما يكون اللجنة كاملة. والقاعدة التي تستقر عليها معظم الفرق هي الاعتماد شفوياً خلال دقائق، وكتابة السجل في اليوم نفسه، ومراجعته في اجتماع اللجنة التالي.
حدّد ما يجب أن يحتويه سجل التقييم
حوّل «توثيق التقييم وخطة التراجع» إلى قائمة تحقق حقيقية: الخدمات والمستخدمون المتأثرون، وتصنيف المخاطر، والاعتماديات، ونافذة التوقف، ومنهج الاختبار، وخطوات التراجع ومن ينفّذها. فقرار اللجنة لا يجود إلا بقدر جودة هذا السجل، وهو المستند الذي سيطلبه المدقّق بعد أشهر.
اجعل قواعد الجدولة والتعارض صريحة
بيّن فترات التجميد والحد الأدنى لمهلة الإشعار ومن يملك تقويم التغييرات. وفحص التعارض في هذا المخطط قرار عن قصد لا إجراء شكلي، لأن معظم التصادمات هي فريقان يمسّان اعتمادية مشتركة لا النظام نفسه. واحسم مسبقاً هل يعني التعارض إعادة جدولة أم تصعيداً.
عرّف النجاح ثم انشر الإجراء واضبط إصداراته
حدّد ما يعنيه «هل نجح التغيير؟» عندك: أي اختبارات تحقق سريعة، وكم يراقب مالك الخدمة، وما الذي يُطلق قرار التراجع. ثم شارك المخطط حيث يجري العمل، بجوار نموذج طلب التغيير أو في دليل التشغيل، ووثّق اعتماد المذكورين فيه، واحتفظ بالنسخ السابقة لتُظهر متى تغيّر الإجراء ولماذا.
الأسئلة الشائعة
هل هذه إدارة تغيير تقنية المعلومات أم إدارة التغيير المؤسسي؟
إنها إدارة تغيير تقنية المعلومات. الاثنتان تشتركان في الاسم ولا تشتركان في شيء آخر تقريباً. هذا المخطط هو العملية التشغيلية بأسلوب ITIL للتغييرات على الخدمات القائمة: يُرفع طلب التغيير ويُفرز ويُقيَّم ويُعتمد ويُجدول ويُنفَّذ ويُتحقق منه ويُغلق. أما إدارة التغيير المؤسسي فهي الجانب البشري لمساعدة الموظفين على تبنّي أسلوب عمل جديد، وتُبنى عادةً على نماذج مثل ADKAR أو خطوات كوتر الثماني، ولا لجنة CAB فيها ولا تقويم تغييرات ولا خطة تراجع. فإن كنت تبحث عن تحليل الأطراف المعنية وخطة التواصل، فهذا ليس المخطط المناسب.
ما الفرق بين التغيير القياسي والعادي والطارئ؟
التغيير القياسي منخفض المخاطر ويُنفَّذ كثيراً ومعتمد مسبقاً مقابل نموذج تغيير موثّق، فلا يحتاج اعتماداً فردياً ويذهب مباشرةً إلى الجدولة. والتغيير العادي هو كل ما يجب تقييمه واعتماده بحسب حالته، وهو المسار المارّ بتقييم المخاطر والأثر ثم اللجنة. والتغيير الطارئ هو الذي يسبّب انتظار اجتماع اللجنة التالي فيه ضرراً أكبر من التغيير نفسه، فيحصل على اعتماد مُعجَّل من لجنة الطوارئ. وفي هذا المخطط تلتقي المسارات الثلاثة عند تقويم التغييرات والتنفيذ والمراجعة نفسها، لأن التصنيف يغيّر مسار الاعتماد لا السجل.
هل يجب أن يمرّ كل تغيير على لجنة CAB؟
لا، وإرسال كل شيء إليها هو أسرع طريق لدفع الناس إلى الالتفاف على العملية. وجود اللجنة لمراجعة التغييرات التي لم تُفهم مخاطرها بعد. فمتى نُفّذ نوع من التغيير مرات كافية ليصبح له إجراء موثوق ونمط إخفاق معروف، ارفعه إلى تغيير قياسي بنموذج موثّق وأخرجه من جدول الأعمال. فاللجنة التي تقضي اجتماعها في ختم أعمال روتينية لا تراجع شيئاً، والطابور الذي تصنعه يدفع التغييرات الخطرة فعلاً نحو المسار الطارئ.
ماذا يجب أن يحدث حين يخفق التغيير؟
يتبع المسار نفسه حتى الإغلاق كالتغيير الناجح. في هذا المخطط يُفعّل التحقق المخفق عند «هل نجح التغيير؟» خطة التراجع في مسار فريق التنفيذ، ثم يمضي التغيير المتراجَع عنه إلى المراجعة اللاحقة للتنفيذ ثم الإغلاق تماماً كالتغيير الناجح. وأمران يجعلان ذلك ناجحاً عملياً: أن تكون خطة التراجع مكتوبة ومعتمدة قبل تنفيذ التغيير لا مرتجلة أثناء العطل، وأن تسأل المراجعة عمّا إذا كان تصنيف التغيير صحيحاً لا عمّا إذا كان التغيير قد نجح فقط. أما المحاولة الثانية فهي طلب تغيير جديد، ليحتفظ الإخفاق بسجله الخاص.