مدیریت تغییرات در ITIL

هر رویکرد فناوری اطلاعات باید با گذشت زمان تغییر کند. مادامی که راه حل های موجود برای کنترل تقاضاها نیاز به ارتقاء دارند، فناوری های قدیمی باید جایگزین شوند. درنهایت نیاز است تا فناوری اطلاعات، راه حل ‌های جدید برای تامین نیازهای کسب و کار معرفی و ارائه کند. همانطور که عصر دیجیتال بسیاری از صنایع را تغییر می دهد، نرخ تغییرات نیز همواره در حال افزایش بوده و در صورت عدم آمادگی، مدیریت تغییرات در ITIL دشوار خواهد بود.

کتابخانه زیرساخت فناوری اطلاعات (ITIL) مجموعه ای از best practiceها برای مدیریت تغییرات ارائه می‌کند تا بدین وسیله روند معرفی تغییرات و اولویت بندی کردن آنها را برای متخصصان IT ساده تر کند، بدون آنکه تاثیر منفی بر مشتریان یا توافق نامه سطح سرویس داشته باشد. برای حفظ رقابت و اجتناب از استرس ناشی از اجرای تغییرات بدون جهت، درک این دستورالعمل ها بسیار مهم است. توجه داشته باشید ITIL در مورد چگونگی پیاده سازی فرآیندهای ITIL زیاد سخت گیرانه رفتار نمی‌کند. بسیاری از شرکت‌ها best practiceهای ITIL را با سیاست‌ها و فرآیندهای خودشان بهبود بخشیده که تداعی کننده درک و تفسیر آنها از چارچوب ITIL است. این بطور خاص در فرآیند مدیریت تغییرات در ITIL صدق می‌کند. ممکن است برخی از این فرآیند و سیاست‌ها از چارچوب‌ها یا قوانین سایر best practiceها استفاده کنند.

 

مدیریت تغییرات change management در ITIL چیست؟

ITIL change management فرآیندی است که برای درک و به حداقل رساندن ریسک‌ها در هنگام تغییر فناوری اطلاعات طراحی شده است. کسب و کارها دو انتظار عمده از سرویس‌های ارائه شده توسط فناوری اطلاعات دارند:

Change management یک فرآیند رسمی را برای انجام تغییرات بکار گرفته و در نتیجه گاهی اوقات با افزودن تشریفات اداری، ایجاد تغییرات را سخت تر می‌کند. اما یک فرآیند change management که به درستی اجرا شده، می‌تواند حجم بالایی از تغییرات مفید را در مقایسه با زمانی که این فرآیند به درستی اجرا نشده، ایجاد کند. اینکار با روش‌های زیر انجام می‌شود:

• اطمینان از اینکه همه تغییرات پیشنهاد شده از لحاظ مزایا و ریسک‌هایشان مورد ارزیابی قرار گرفته اند و همه تاثیرات آنها نیز در نظر گرفته شده است.
• اولویت بندی تغییرات به طوری که منابع محدود به آن تغییرات تخصیص داده می شود و بیشترین سود را بر اساس نیاز کسب و کار تولید می‌کند.
• با در نظر گرفتن این که همه تغییرات به طور کامل مورد تست قرار گرفته اند و در صورت استقرار ناموفق، یک برنامه back-out برای بازگرداندن وضعیت محیط در هر استقرار لحاظ شود.
• اطمینان از آپدیت بودن سیستم مدیریت پیکربندی جهت نشان دادن تاثیر هر تغییر.

مدیر تغییرات باید همیشه از فرصت‌ها باخبر باشد تا فرآیند مدیریت تغییر را کارآمدتر کند. دو ابزار مهم برای اینکار وجود دارد:

• مدل‌های تغییر. بسیار بعید است که تغییر پیشنهاد شده شبیه تغییراتی که در گذشته انجام شده، نباشد. مدیر تغییر می‌تواند یک مدل تغییر برای استانداردسازی فرآیند پیاده سازی یک نوع تغییر خاص ارائه کند. اینکار روند اجرای فرآیند را بهبود بخشیده و ریسک تغییر را کاهش می‌دهد.
• تغییرات استاندارد. یک تغییر استاندارد یک مدل خاص از مدل تغییر است و برای تغییرات معمولی که شامل ریسک‌های کمی هستند، استفاده می‌شود.. تغییرات استاندارد از قبل تایید شده هستند، بدین معنا که آنها نباید توسط مدیر تغییر بازبینی شوند و معمولا به عنوان درخواست‌های سرویس در service desk در نظر گرفته می‌شوند.

مدیر تغییر می‌تواند با کمک کمیته تغییر (CAB)، که شامل متخصصان فناوری اطلاعات، مالی و کسب و کار هستند، در مورد صدور مجوز تغییرات تصمیم گیری کند.

 

ITIL change management

ITIL مجموعه ای از best practice ها را معرفی کرده و سازمان های فناوری اطلاعات می‌توانند برای ارائه ارزش به مشتریان از طریق مفهوم “خدمات” از آنها استفاده کنند. متخصصان فناوری اطلاعات و شرکت‌هایی که از ITIL استفاده می‌کنند، می‌توانند روش برنامه ریزی، ارائه و پشتیبانی سرویس‌های فناوری اطلاعات را برای مشتریان داخلی و خارجی خود استاندارد کنند. یکی از مزایای استفاده از یک چارچوب best-practice استاندارد شده این است که اطمینان حاصل شود کارکنان، نقش و فرآیندهایی را که آنها باید برای ارائه سرویس‌ها و فراهم سازی سطح بالایی از پشتیبانی مشتری دنبال کنند، درک می‌کنند. با استفاده از ITIL، دانش و عملکرد کارکنان بهبود یافته و رضایت مشتری نیز در زمانی که آنها بدانند چه انتظاراتی از سرویس دارند، بیشتر خواهد شد.

چارچوب ITIL بدنبال آن است که ارائه دهندگان خدمات پشتیبانی IT، نقش‌های تعاملی بیشتری در کسب و کارها داشته باشند. همچنین دپارتمان‌های IT که از این چارچوب استفاده می‌کنند، بجای ارائه پشتیبانی تنها در پشت صحنه، در ساختار کلی کسب و کار نیز می‌توانند فعالیت کنند.

 

ماموریت IT change management

ماموریت فرآیند IT change management بدین صورت است که ضمن اینکه تغییرات را در کارآمدترین حالت ممکن انجام می‌دهد، تاثیر منفی حاصل از انجام تغییرات را بر روی مشتریان به حداقل می‌رساند.

شاخص های کلیدی عملکرد (KPIs) برای پیگیری وضعیت پیشرفت فرآیند IT change management عبارتند از:

• تغییرات موفق (Successful changes): تعداد تغییراتی که با موفقیت انجام شده اند در مقایسه با تعداد کل تغییرات انجام شده. هرچه درصد تغییرات موفق بیشتر باشد، بهتر است.
• عملیات‌های ناتمام تغییرات (Backlog of changes): تعداد تغییراتی که تا این لحظه بطور کامل انجام نشده اند. از آنجا که این تعداد مطلق به اندازه سازمان بستگی دارد، نباید در طول زمان افزایش یابد.
• تغییرات اضطراری (Emergency changes): تعداد تغییرات اضطراری که بطور کامل انجام شده اند. این تعداد مطلق به اندازه سازمان بستگی دارد و نباید در طول زمان افزایش یابد.

 

دامنه مدیریت تغییرات (Change Management Scope)

دامنه فرایند مدیریت تغییرات در ITIL محدود به پیاده سازی تغییرات است که باعث می‌شود:

• سرویس‌ها در ساعات خدمات رسانی در دسترس نبوده یا دچار خرابی شوند.
• عملکرد سرویس تغییر کند.
• CMDB به ارتقاء نیاز دشته باشد.

سایر تغییرات معمولا به formal change management نیاز نداشته و می‌توانند به عنوان فعالیت‌های استاندارد IT در نظر گرفته شوند.

 

روش‌های مدیریت تغییرات در ITIL، فناوری اطلاعات (IT Change Management Procedures)

فرآیند IT change management process شامل پروسه های متفاوتی است:

• درخواست برای بازبینی تغییر: هماهنگ کنندگان تغییر در هنگام مواجهه با درخواست‌های تغییر از این روش استفاده می‌کنند.
• برنامه ریزی تغییر: هماهنگ کنندگان تغییر و کارشناسان از این روش برای تهیه طرح های اجرای تغییرات استفاده می‌کنند.
• تاییدیه تغییر: مدیر تغییر و تاییدکنندگان (کارشناسان مشتری و صاحبان سرویس) از این روش برای تایید تغییرات برنامه ریزی شده استفاده می‌کنند.
• اجرای تغییر: کارشناسان از این روش برای اجرای تغییرات زیرساختی استفاده می‌کنند.
• بستن تغییر: کارشناسان از این روش در زمان اجرای تست تولید پس از اجرا شدن تغییرات استفاده کرده و هماهنگ کنندگان تغییر نیز در زمان بستن تغییرات از این روش استفاده می‌کنند.

این روش‌ها برای انواع مختلف تغییرات IT و سطوح ریسک، کمی متفاوت است. سازمان‌های فناوری اطلاعات مییابیست هرجا که امکان پذیر است، روش پردازش درخواست‌ها را خودکارسازی و استاندارد کنند.

 

انواع تغییرات فناوری اطلاعات

انواع مختلفی از درخواست‌های تغییر یا کلاس‌های تغییر وجود دارد که معمولا به شیوه های متفاوتی مدیریت می‌شوند:

• تغییرات استاندارد به تغییرات اعمال شده بر روی سرویس یا زیرساخت گفته میشود که در آن فرآیند پیاده سازی تغییرات و ریسک‌های آن از پیش مشخص هستند. این تغییرات با توجه به سیاست‌هایی که در حال حاضر در سازمان فناوری اطلاعات اجرا می‌شود، مدیریت می‌شوند. از آنجاییکه این تغییرات به سیاست ها و پروسه های ایجاد شده بستگی دارد، اولویت بندی و پیاده سازی آنها به ساده ترین شیوه انجام شده و اغلب از دید مدیریت ریسک، به تایید نیاز ندارند.
• تغییرات نرمال تغییراتی هستند که باید پیش از تایید و اجرا، از فرآیند تغییر عبور کنند. اگر مشخص شود که این تغییرات ریسک بالایی دارند، کمیته تغییر باید در خصوص اجرا یا عدم اجرای آنها تصمیم گیری کند.
• تغییرات اضطراری زمانی رخ می دهد که یک خطا یا تهدید غیرمنتظره اتفاق می افتد، مثلا زمانی که یک نقص در زیرساخت های مرتبط با سرویس‌ها رخ می‌دهد و باید فورا مورد توجه قرار گیرد. یک تهدید امنیتی نمونه دیگری از یک موقعیت اضطراری است که نیاز به تغییر فوری دارد.

 

نقش‌های مدیریت تغییر

قبل از شروع به استفاده از فرآیندهای ITIL، شما باید نقش های زیر را به تیم خود تخصیص دهید:

• آغاز کننده تغییر، نیازها را برای تغییر شناسایی می‌کند. آغاز کننده تغییر میبایست شخصی باشد که مستقیما با ابزارهای پشتیبانی سرویس کار می‌کند. اعضای تیم شما که خدمات پشتیبانی ارائه می‌کنند ممکن است بدلیل تعاملات مکرری که با سیستم دارند، برای این جایگاه بسیار مناسب باشند.
• هماهنگ کننده تغییر درخواست‌های تغییری که از سوی مدیریت رخداد، مدیریت مشکل، مدیریت نسخه و مدیریت استمرار می‌آید را ارزیابی می‌کند. هماهنگ کننده تغییر، تغییرات را در صورت لزوم ثبت می‌کند تا بتواند درخواست‌های تغییر را مدیریت کرده یا درخواست‌های تغییر را از سایر آغازکننده های تغییر، دریافت کند. تاثیر و ریسک تغییرات درخواست شده را مشخص کند. از طریق ایجاد task ها برنامه های اجرایی ایجاد کند. میزان پیشرفت تغییرات را کنترل و نظارت کند.
• مدیر تغییر عموما در سازمان‌های بزرگ و متوسط مورد نیاز است. اگر بخش IT شما بخشی از یک شرکت بزرگتر باشد، لازم است تا شما یک یا چندین نفر را برای ایفای نقش مدیر تغییر انتخاب کنید. این افراد مسئول مدیریت فرآیندهای تغییر، دریافت و اولویت بندی درخواست‌های تغییر، ارزیابی سطح ریسک درخواست‌ها و نگهداری رکوردهای کامل مربوط به نتایج هر تغییر، هستند.
• کمیته تغییر (Change advisory board) مسئول صدور مجوز برای تغییرات و ارزیابی بیشتر درخواست‌ها در زمانیکه مدیر تغییر تشخیص می‌دهد این درخواست‌ها ریسک بالایی دارند، می‌باشد. کمیته تغییر تاثیری را که تغییرات درخواست شده ممکن است در تمام طرف‌های متأثر از آن داشته باشند، در نظر می‌گیرد.
• تاییدکنندگان در خصوص تایید یا عدم تایید تغییرات تصمیم گیری می‌کنند.
• تیم اجرای تغییر متشکل از متخصصان تیم شما هستند که مسئول تغییرات واقعی هستند. شما احتمالا بخشی از این تیم هستید و ممکن است مسئولیت اجرای تغییرات به کارکنانی که مستقیماً در زیرمجموعه شما هستند، تخصیص داده شود. شما اغلب به عنوان یک مدیر IT مسئول نظارت بر تغییرات هستید.

فرآیند مدیریت تغییرات در ITIL

در این بخش به بازنگری پروسه های مختلفی که بخشی از فرآیند مدیریت تغییرات در ITIL محسوب می‌شوند، پرداخته می‌شود. پس از یادگیری این مبحث، شما قادر خواهید بود تا فرآیند را بدون نیاز به وقفه جهت شناخت آنچه که در آینده می‌آید، ادامه دهید.

 

1. ایجاد درخواست برای تغییر

در صورت ایجاد درخواست تغییر ، شما مسئول مستندسازی جزئیاتی هستید که به دیگران کمک خواهد کرد تا درک کنند چه تغییری باید انجام شود و چرا این درخواست را ایجاد می‌کنید. ارسال درخواست تغییر اولیه اغلب شامل جزئیاتی در مورد ریسک و مراحل پیاده سازی است، اگر آغازکننده این اطلاعات را بداند. با این حال، این اطلاعات در این زمان مورد نیاز نیست.

جزئیاتی که ممکن است در یک درخواست تغییر یافت شوند عبارتند از:

• رخدادهایی که انجام تغییر را ملزم می‌دارند.
• توصیف چگونگی اجرای تغییر.
• تاثیری که ممکن است یک تغییر بر روی همه سیستم‌های مربوطه داشته باشد.
• ارزیابی ریسک.
• اطلاعات تماس برای هر فردی که در تغییر حضور دارد.
• یک تصویر کلی از تمام افرادی که باید تغییر را تایید کنند.
• یک برنامه بکاپ گیری برای شرایطی که تغییر با شکست مواجه می‌شود.

 

2. بازبینی و ارزیابی درخواست تغییر

اگر شما مسئول بازبینی درخواست تغییر هستید، باید درخواست را بر اساس کاربرد و اولویت آن ارزیابی کنید. وظیفه شما این است که تعیین کنید آیا درخواست منطقی است یا خیر و همچنین بازخورد مربوط به درخواست را بدهید. اگر درخواست ها مربوط به مشكلاتي باشد كه قبلا به آنها پرداخته شده است و يا مربوط به درخواست‌هایی که اجراي آنها مفيد نيست، در اینصورت این درخواست‌ها کنار گذاشته خواهند شد.

درخواست‌های مفید و کاربردی بر اساس موارد زیر ارزیابی خواهند شد:

• ایجاد کننده درخواست
• تاثیری که این تغییر ممکن است بر روی شرکت داشته باشد
• بازگشت هرگونه سرمایه ای که در رابطه با این درخواست تخمین زده شده است
• منابع مورد نیاز برای اجرای درخواست

شما همچنین مسئول اجرای درخواست و توانایی پیاده سازان جهت تخصیص زمان برای ایجاد تغییر را مشخص خواهید کرد.

 

3. برنامه ریزی تغییر

هنگامی که یک درخواست تغییر ایجاد می‌شود، شما باید تغییر را به گونه ای برنامه ریزی کنید که گویی اتفاق می افتد. یک برنامه تغییر (یا طرح تغییر) مسیر اجرای تغییر، منابعی که برای تکمیل تغییر مورد نیاز هستند و یک جدول زمانبندی را برای تغییر مشخص می‌کند.

 

4. تست تغییر

اگر یک تغییر مربوط به رفع خطاهای نرم افزاری یا تغییر یک سیستم باشد، ممکن است نیاز باشد تا شما این تغییر را پیش از آنکه تایید شود، تست کنید. تست کردن در مقیاس کوچک ، بعلاوه تست تغییر این فرصت را برای شما فراهم می‌آورد تا هرگونه مشکلی را که در روش‌های توسعه شما وجود دارد، حل کنید.

 

5. ایجاد طرح پیشنهادی تغییر

طرح پیشنهادی تغییر، نوع تغییر، اولویت مرتبط با یک درخواست و نتایج حاصل از عدم ایجاد درخواست تغییر را مشخص می‌کند. طرح شما به افرادی که مسئول صدور مجوز تغییر هستند، داده خواهد شد، در نتیجه بسیار اهمیت دارد که شما توضیح کاملی از علت نیاز به ایجاد تغییر را ارائه دهید. برای مثال، یک تغییر با اولویت بالا که ممکن است باعث بروز خرابی هایی شود که بر مشتریان تاثیر گذاشته و منجر به هدر رفتن سرمایه شود. درصورتیکه که شما کاری انجام ندهید، افرادی که مجوز تغییرات را صادر می‌کنند، باید از شدت تاثیر آنها آگاهی داشته باشند.

 

6. پیاده سازی تغییرات

پیاده سازی تغییر، فرآیند ساده ای نیست. تغییر باید در طول فرآیند برنامه ریزی ایجاد شود و پیاده سازی تنها یک مرحله از فرآیند مدیریت تغییر (change management process) است. هنگامی که تغییری ایجاد می‌شود، باید تست‌هایی انجام شود تا تعیین شود که آیا نتایج مورد نظر به دست آمده است یا خیر. اگر تغییر موفقیت آمیز نباشد، مممکن است یکسری روش های اصلاحی جهت مشخص شدن اشتباهی که رخ داده و اجرای برنامه پشتیبان گیری برای رفع مسائلی که درخواست تغییر را ضروری می سازد، مورد استفاده قرار دهد.

 

7. بازبینی عملکرد تغییر

بازبینی بعد از پیاده سازی بخش مهمی از فرآیند مدیریت تغییر است. شما به عنوان یک کارشناس IT می‌خواهید بدانید که آیا روال‌های تغییر شما آنچنان که انتظار می‌رود‌، کار می‌کنند. این شامل بازبینی رکوردها برای تعیین اینکه آیا تغییر موفقیت آمیز بوده یا شکست خورده است و ذخیره جزئیات در خصوص زمان و هزینه تغییر برای تعیین صحت تخمین‌هایی که پیش از انجام تغییر . بازبینی عملکرد تغییر به شما این امکان را می‌دهد که فرآیند مدیریت تغییر خود را برای کسب نتایج بهتر در آینده، بهینه سازی کنید.

 

8. بستن فرآیند

پس از تکمیل فرآیند تغییر، باید اطمینان حاصل کنید که کل فرآیند مدیریت تغییرات در ITIL در داخل پایگاه داده ثبت شده است و همه ذینفعان می‌توانند به آن دسترسی داشته باشند. هنگامی که این مستندات تکمیل شدند، فرآیند بسته می‌شود.