تمرین قابلیت تغییر در ITIL4

قابلیت تغییر در ITIL4

خوشبختانه بنیاد سازندگان  ITIL 4 به اندازه کافی آزاد بودند تا بتوانند برخی از یادگیری‌های مهم جنبش DevOps را با چارچوب ITIL تطبیق دهند و از درگیری بیشتر بین توسعه‌دهندگان واحد نرم‌افزار و ارایه دهندگان خدمات جلوگیری کند. ITIL4  در حالی که بطور خطی تمام خصوصیات نسخه‌های قبلی را حفظ کرده، تلاش نموده تا جریان "برنامه‌ریزی، ساخت، اجرا" را در مفهوم چرخه‌ی سرویس خود قرار دهد و اینچنین شد که در نسخه ۴ به طور قابل توجهی این مدل را با یک مدل جریان ارزش تکرار شونده جایگزین کرد تا مباحث DevOps را نیز بخوبی پوشش ‌دهد. تغییر رویکرد از "فرایندها" به "تمرینات" و قرارگیری زنجیره‌ی ارزش خدمات شاید مهمترین تغییراتی باشد که در ITIL4 باید مورد توجه قرار گیرد این مهم که توسط Axelos برای واکاوی بیشتر بارها مورد بحث قرار گرفته به نوبه‌ی خود بطور قابل توجهی نیز مورد ستایش واقع شده. امروز توسعه‌دهندگان نرم‌افزار و حامیان DevOps نیز به این نتیجه رسیده‌اند که ITIL ورای رویکرد چرخه‌ی حیات خدمت است و بازآفرینی هر چیزی که منجر به خلق ارزش شود نیازمند این چارچوب محبوب است. لذا هواداران DevOps‌ باید بدانند که:  ITIL برای خدمات پشتیبانی نیست، ITIL دست و پا گیر نیست، ITIL بروکراسی ایجاد نمی‌کند و ITIL‌ برای تمام ارکان‌های فناوری اطلاعات و ارایه‌دهندگان خدمت در سراسر جهان است!

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

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

ادامه مطلب در صفحه بعد…