طلب التغيير: الأسئلة الـ 7 الحاسمة للنجاح

إدارة التغيير هي عملية تشكل جزءاً من مرحلة انتقال خدمة ITIL من دورة حياة خدمة ITIL. عملية إدارة التغيير في ITIL هي أيضاً ميزة مهمة في اختبار شهادة ITIL. تحدد الدورات التدريبية عبر الإنترنت في ITIL أن هناك سبعة أسئلة مهمة تبدأ بحرف R فيما يتعلق بطلب التغيير في عملية إدارة التغيير في تكنولوجيا المعلومات. سنتناول كل سؤال من هذه الأسئلة السبعة في هذه المقالة. ستقطع الإجابة على أسئلة 7R هذه شوطًا طويلاً لضمان التنفيذ الناجح لعملية إدارة التغيير.
7R من طلب التغيير رقم 1: RAISED
من الذي رفع أو اقترح طلب التغيير؟ غالبًا ما تعمل الأعمال بطريقة “منعزلة” حيث تعمل الأقسام المختلفة بشكل مستقل. وهذا يمكن أن يجعل من الصعب تتبع من طلب ماذا. قد تكون هناك فرصة عمل جديدة لذا قد يكون العمل هو من طلب التغيير، أو قد يكون هناك تسرب أمني في النظام لذا يمكن لمزود خدمة تكنولوجيا المعلومات نفسه أن يبادر بطلب التغيير في هذه الحالة أيضاً. لذا، فإن السؤال المتعلق بالشخص الذي اقترح التغيير مهم في إدارة التغيير و 7R مهم. قد يكون لدى الشخص الذي أثار التغيير أو اقترحه بعض الأفكار أو الأدلة لتقديمها إلى مجلس الإدارة التي تدعم قرار بدء طلب التغيير. إن وجود نظام مركزي يسجل جميع التغييرات سيضمن أن يعرف الجميع أي قسم كان مسؤولاً عن رفع طلب التغيير. سيكون هذا النظام الوحيد للسجلات مفيدًا أيضًا أثناء عمليات التدقيق.
7R #2: السبب
لماذا هذا التغيير مطلوب؟ يمكن أن تكون زيادة السعة أو زيادة التوافر هي السبب وراء طلب التغيير أو يمكن أن يكون تقليل المخاطر الأمنية هو السبب أيضًا. يجب تقديم دليل أو حجة مقنعة بشأن سبب طلب التغيير المقترح لمساعدة مجلس الإدارة على اتخاذ قرار بشأن الموافقة على الطلب. وبهذه الطريقة، سيتم تجنب تقديم خطر في شكل طلب دون تقديم أي فائدة للأعمال. يجب أن تتماشى التغييرات مع الأعمال والأهداف الاستراتيجية لتكنولوجيا المعلومات. سيؤدي تقييم ما إذا كان التغيير متوافقًا مع استراتيجية الشركة إلى تجنب إنفاق الموارد على تغيير غير استراتيجي.
7R #3 العائد
ماذا ستكون النتيجة عند تنفيذ طلب التغيير؟ على سبيل المثال، بعد تنفيذ التغيير، ستزداد السعة بنسبة 10%، أو سيزداد التوافر بنسبة تصل إلى 99%، أو سيتم إصلاح التسرب الأمني. هذه أمثلة على عوائد طلب التغيير ويمكن استخدامها كأسباب مقنعة للموافقة على طلب التغيير. إذا كان العائد منخفضًا، فقد يتم رفض طلب التغيير. لذلك، من الأهمية بمكان أن يتضمن أي طلب الفوائد المادية وغير المادية التي يمكن أن تتوقع الشركة رؤيتها عند تنفيذ التغيير.
7R #4: المخاطر
ما هي المخاطر التي ينطوي عليها طلب التغيير؟ تنطوي جميع التغييرات على مخاطر. على سبيل المثال، يمكن أن تتضمن ترقية نظام التشغيل على الخادم مخاطر فقدان الخادم بالكامل إذا حدثت مشكلة أثناء الترقية. السؤال هو: ما مقدار المخاطرة؟ بعض المخاطر يمكن تجنبها من خلال خطة معالجة ITIL وبعضها يجب قبولها. كما يجب أن تؤخذ شدة المخاطر المحتملة في الاعتبار. يجب توثيق المخاطر المرتبطة بالترقية إلى جانب خطة التخفيف من المخاطر وتقدير لمدى احتمال حدوث الخطر.
7ص رقم 5: الموارد
كم العدد المطلوب؟ هناك حاجة إلى كل من الأشخاص وأصول تكنولوجيا المعلومات في مزود خدمة تكنولوجيا المعلومات ولا يمكن أن يحدث أي تغيير دون وجود عدد كافٍ من الأشخاص أو ما يكفي من أصول تكنولوجيا المعلومات. إذا كان الطلب يتطلب زيادة في السعة أو التوافر، على سبيل المثال، يحتاج المرء إلى معرفة عدد الخوادم أو المسؤولين الجدد المطلوبين لدعم الخدمات. إذا تم طلب ميزة جديدة، فكم من الوقت سيستغرق فريق التطوير لتطوير الميزة المطلوبة؟ هذه أسئلة مهمة يجب طرحها أثناء التخطيط للجدول الزمني لتنفيذ التغيير. إذا لم تكن هناك موارد كافية متوفرة ولا يمكن تأمين موارد جديدة، فقد يتم رفض طلب التغيير. يجب أيضًا مراعاة تأثير متطلبات طلب التغيير من الموارد على المشاريع الأخرى. هل سيتعين إعادة تخصيص الأشخاص أو الأصول لمعالجة هذا التغيير؟ قد يكون له تأثير على مشاريع أخرى مهمة بالنسبة لاستراتيجية الشركة، وهذا بدوره قد يكون له تأثير على التكلفة.
7R من طلب التغيير رقم 6: المسؤول
من المسؤول عن الإعداد والاختبار والتنفيذ؟ على سبيل المثال، يمكن أن يقوم فريق تطوير البرمجيات بتطوير طلب التغيير، ويمكن أن يقوم فريق الاختبار بإجراء الاختبار. بعد نجاح تطوير واختبار طلب التغيير المطور يمكن أن يتم التنفيذ من قبل فريق الإصدار والنشر. من المهم في إدارة التغيير تحديد المسؤوليات الواضحة من حيث من سيقوم بماذا. تعد مصفوفة RACI أداة مفيدة لتحديد من يجب أن يكون مسؤولاً ومسؤولاً عن المهام.
مع حدوث العديد من التغييرات بشكل متزامن في بيئات تكنولوجيا المعلومات المعقدة، قد يكون من الصعب الإجابة على هذا السؤال. يجب تحديد علاقات التغيير من داخل الحدود الوظيفية وعبرها. سيؤدي الفشل في القيام بذلك إلى فترات أطول من التوقف المخطط له بسبب، على سبيل المثال، تسلسل التغيير غير الصحيح أو دون المستوى الأمثل. يمكن أن تساعد الجدولة المشتركة للتغييرات المخطط لها هنا، كما يمكن أن يساعد تحليل تأثير التغيير وتخطيط العلاقات من قاعدة بيانات إدارة التكوين المتكاملة
7R من طلب التغيير رقم 7: العلاقة
ما هي العلاقات مع التغييرات الأخرى؟ يمكن أن يكون هناك العديد من التغييرات التي يجريها مزود خدمة تكنولوجيا المعلومات. يجب تنسيق هذه التغييرات بشكل صحيح. إذا كان طلب التغيير شرطًا مسبقًا لطلب تغيير آخر، فيجب التخطيط لذلك وفقًا لذلك. على سبيل المثال، إذا كان هناك طلبا تغيير لنظام التعرف على العملاء في ماكينة الصراف الآلي لأحد البنوك: برنامج التعرف على بصمات الأصابع وجهاز الكشف عن بصمات الأصابع. أولاً، يجب تنفيذ نظام الكشف عن بصمات الأصابع في أجهزة الصراف الآلي قبل تنفيذ برنامج التعرف على بصمات الأصابع لاكتشاف ومعالجة صور بصمات الأصابع للعملاء. يجب تحديد هذه الأنواع من العلاقات السابقة واللاحقة في طلب التغيير. إذا لم يتم ذلك، فقد يكون لها نتائج كارثية بمجرد تنفيذ التغييرات على الخدمة. يجب تحديد علاقات التغيير داخل الحدود الوظيفية وعبرها. قد يؤدي عدم القيام بذلك إلى فترات تعطل أطول.
فوائد الـ 7 R’s لطلب التغيير
توفر الإجابة على هذه الأسئلة السبعة المتعلقة بطلب التغيير العديد من الفوائد. تسمح بإعداد مقاييس يمكن للمؤسسة من خلالها قياس مخاطر التغيير. وهذا يساعد كثيرًا على جعل الخدمات أكثر موثوقية ومتاحة للعملاء. كما يساعد أيضًا على تقييم مدى توافق عملية إدارة التغيير في الشركة مع المتطلبات الحالية وتحديد الثغرات التي يمكن سدها. ولضمان التوافق المتسق مع المتطلبات، يلزم إجراء تدقيق لإدارة التغيير من خلال طرح هذه الأسئلة السبعة والإجابة عليها.