بدانید که:

چیزی که در ITIL4 و اندکی پس از انتشار، نویسندگان آن را به چالش وا داشت تغییر نامگذاری فرایند مدیریت تغییر به تمرین "کنترل تغییر" بود و چالشی که پیش آمد: کلمه‌ی "کنترل" بود. بخصوص آنکه کافی بود که حامیان DevOps این کلمه را بشنوند! و البته اینچنین هم شد. بار منفی کلمه‌ی نظارت و "کنترل" در ذهن آنها مشکل‌ساز شد. از این رو سیل انتقادات به واژه‌ی "کنترل" آنقدر بالا گرفت که نه تنها DevOps-ها بلکه اغلب مدیران و تمرین‌کنندگان ITIL نیز از "کنترل تغییر" به"کنترل میزان تغییرات" و یا "تیم‌های کنترل‌کننده" متمرکز شد‌ند همین منجر به بروز برداشت‌های نادرست و سوتفاهمات بسیاری از ترکیب"کنترل تغییر" گردید. زیرا حتی خود کلمه‌ی "کنترل" برای بسیاری از تیم‌های فناوری اطلاعات واژه‌ای سمی و استرس‌زا تلقی می‌شد در نتیجه، پس از آن نویسندگان ITIL، پیشنهاداتی را مطرح کردند از جمله بازگشت به همان "مدیریت تغییر" اما در نهایت تصمیم گرفتند بجای استفاده از "کنترل تغییر" از ترکیب "قابلیت تغییر" استفاده کنند.
"مدیریت تغییر" یک پیامد ظریف دارد که تمرکز آن بر مدیریت هر نوع تغییری است. از طرفی، کنترل تغییر به دنبال کنترل شرایط توسعه‌ی تغییرات سازگار با انتظارات مورد دلخواه سازمان از نتیجه‌ی تغییر است. به عبارت دیگر، کنترل(قابلیت) تغییر بر نحوه تولید تغییرات - در جریان ارزش - نظارت و حاکمیت ایجاد می‌کند.
بنابراین در تاریخ ۳۱ اکتبر، Axelos در مقاله‌ای آنلاین تأیید کرد که به‌روش ITIL 4 از فرایند مدیریت تغییر به عنوان "Change Enablement" "قابلیت تغییر" یاد می‌کند که این عبارت بهتری نسبت به کنترل تغییر است.

ITIL #ServiceDesk

www.Servicedeskplus.ir