قابلیت تغییر در 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 به  تمرین”قابلیت تغییر” تغییر نام داده است البته فقط صرفاً‌ تغییر نام نیست بلکه برای پیشبرد موفق‌تر تمریناتی شبیه این، اصول راهنمای بهتر و شفاف‌تری را ارایه کرده تا سازگارپذیر بودن و اجرایی شدن آن، بیشتر نمود پیدا بکند. فرایند مدیریت تغییر یا تمرین قابلیت تغییر از آن دست تمرینات شیرین است اما برعکس! به تلخی از آن یاد می‌شود مدیران و کارکنان فناوری نیز دلایل موجه خود را دارند و اکثراً این فرایند را به معنای واقعی بکار نمی‌گیرند.  چیزی که مرتباً از آنها می‌شنوم اینست که مدیریت تغییر:

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

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

نوشته تمرین قابلیت تغییر در ITIL4 اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.

سرعت تغییرات نباید آنقدر زیاد باشد که هر چیزی پیش از آنکه استقرار پیدا کند، کنار گذاشته شود! مدیریت تغییر قادر است به مدیریت ریسک و محافظت از خدمات فناوری اطلاعاتی که شما ارائه می‌دهید کمک بسزایی ‌کند و از اشتباهات غیر ضروری جلوگیری ‌کند زیرا حفظ سیستم‌های تجاری قابل اعتماد برای بقای هر سازمانی در فضای بازار رقابتی امروز امری ضروری است. هرگونه تغییر و تحولی در عناصر زیرساخت فناوری اطلاعات می‌تواند ارزش خدمات را مختل کند و تاثیر منفی بر بهره‌وری داشته باشد. تغییرات ساخته‌یافته و برنامه‌ریزی شده به کاهش خطر بالقوه‌ای منتج از اجرای تغییرات کمک می‌کند. یک فرایند مدیریت تغییر قادر است با مزایا و منافع تجاری قابل توجهی همراه شود که برخی از منافع حاصل از مدیریت تغییر عبارتند از:
· بهبود IT برای هماهنگی در کسب و کار
· کاهش اثرات نامطلوب بر عملیات تجاری
· بهبود چشم‌انداز در تغییرات فناوری اطلاعات
· واکنش اولویتی برای تغییر
· پیوستن به استانداردها و سایر مقررات انطباق
· بهبود مدیریت ریسک
· کاهش خسارت خدمات و خرابی سیستم
· افزایش بهره‌وری کارکنان
· پیاده‌سازی سریعتر تغییرات
www.Servicedeskplus.ir

نوشته مدیریت تغییر در ITIL اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.

هفت R در مدیریت تغییر

درک تمام المان‌هایی که می‌تواند ریسک مربوط به تغییر را ارزیابی کند و سبب اثربخشی روند مدیریت تغییر شود در پیاده‌سازی موفق تغییرات بسیار مهم است.

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

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

۱. چه کسی تغییر را ایجاد[۱] کرده است؟

آفت مزرعه انفورماتیک، ملخ نیست! بلکه سیل تغییر غیرمجاز آفت فناوری اطلاعات است. متاسفانه بسیاری از مدیران انفورماتیک، کارشناسان و تکنسین‌ها حسب درخواست‌های کاربران و یا در جهت اصلاح یک سری خدمات اقدام به انجام تغییرات خودسرانه می‌کنند بی‌آنکه آنرا جایی ثبت و ضبط کنند این تغییر غیرمجاز که روند صحیح مدیریت تغییر را در خود ندارد علاوه بر افزایش بار ترافیکی ناخواسته، سبب کاهش کیفیت ارایه‌ی خدمات می‌شود بنابراین در مدیریت تغییر لازم‌است که یک تغییر ابتداً ثبت شود زیرا با وجود بسیاری از نقاط ورود، ذینفعان، تنوع سرویس‌ها و منابع سرازیر شدن سیل تغییرات امری اجتناب ناپذیر است پس جای تعجب نیست که این پدیده، خود منجر به بروز مشکلات فراوانی خواهد شد. یکی از راه‌های اجرا و رسیدگی به تغییرات مجاز، ایجاد سیستمی و متمرکز تمام تغییرات است. چنین سیستمی باید کنترل‌های مناسبی را برای حل تغییرات در مناطق عملیاتی در اختیار داشته باشد. این “سیستم ثبت” ویژه و منفرد، در هنگام ممیزی‌ها بسیار مفید است. در نتیجه اولین R کلیدی در مدیریت تغییر، ثبت تغییر توسط درخواست‌کننده‌ی آن است.

۲. دلیل[۲] تغییر چیست؟

دلیل تغییر[۳] بیانگر هدف نهایی از ایجاد یک درخواست تغییر است. به‌عنوان مثال، اگر یک چاپگر در سازمان شما به دلیل آسیب‌دیدگی یا اتمام کارتریج کار نکند، دلیل تغییر می‌تواند کار نکردن پرینتر باشد بنابراین درخواست تغییر ایجاد شده، می‌تواند کارتریج چاپگر را تغییر دهد. به همین ترتیب، می‌توانید بیشترین دلایل آغاز درخواست تغییر را در همه‌ی زمینه‌های ارایه‌ی خدمت، ثبت کنید. این به مدیریت فناوری اطلاعات کمک می‌کند تا گزارش‌هایی را در مورد دلایل ایجاد تغییر در سازمان بدست آورد و ارزیابی بهتری نسبت به حجم و دلایل تغییرات را داشته باشد. ثبت و درک دلیل تغییر، سبب می‌شود در میان‌مدت علت نیاز به تغییرات را کاهش دهید…و گامی در جهت بهبود مستمر و کاهش نرخ تغییرات تکراری بردارید. از طرفی با شناخت علت تغییر از ریسک‌هایی که این تغییر ممکن است ایجاد کند می‌توانید جلوگیری کنید. در حقیقت، بدون پاسخ روشنی به این پرسش که علت تغییر چیست، نوآوری‌های استراتژیک به راحتی در سیل بی‌وقفه‌ی تغییرات تاکتیکی قرار می‌گیرد و چشم‌انداز و هدف‌گذاری اثربخشی تغییرات را از بین می برد بخصوص آنکه از آن‌جایی که تا حدود ۷۵ درصد بودجه فناوری اطلاعات  به حفظ زیرساخت‌های قدیمی اختصاص دارد. صرف‌نظر از نوع تغییر‌، هر تغییر عمده باید بر اساس معیارهای تجزیه و تحلیل نمونه کارها مورد توافق‌شده، ارزیابی شود. این ارزیابی، اولویت‌بندی مناسب تغییرات را تضمین می‌کند و قبل از هدر دادن منابع، ناهماهنگی بالقوه و ناخالص را آشکار می‌کند. در نتیجه دومین R کلیدی در مدیریت تغییر، ثبت علت تغییر توسط درخواست‌کننده‌ی آن است.

۳. چه بازگشتی[۴] از تغییر مورد نیاز است؟

نتیجه‌ی کسب شده از تغییر به‌ویژه در بازگشت هزینه‌های مالی‌ کمک می‌کند تا اولویت تغییرات استراتژیک و پروژه محور را به‌خوبی درک کنید. ITIL دو ورودی کلیدی را در روند مدیریت تغییر (مشکلات و نوآوری) می‌شناسد‌، اگرچه راهنمایی خوبی در مورد چگونگی تنظیم نوآوری ارایه نمی‌کند اما “مدیریت مالی ITIL برای خدمات فناوری اطلاعات” می‌تواند اطلاعات مفید مربوط به هزینه را ارائه دهد هرچند برای سنجش عینی تأثیر واقعی هزینه‌های مالی تغییر باید آن تغییر را بر اساس معیارهای مبتنی بر ارزش تکمیل کرد. به‌عبارتی دیگر توجیه مالی اجرای یک تغییر باید موجه باشد و در راستای بازگشت هزینه‌ها و یا کنترل هزینه‌ی تغییرات باشد وگرنه پرداختن به هر تغییری بدون بررسی آورده‌ی مالی و ارزش ریالی آن در درازمدت بار مالی هنگفتی بر دوش سازمان می‌گذارد که توجیه‌پذیر نخواهد بود. در نتیجه سومین R کلیدی در مدیریت تغییر، درک بازگشت هزینه‌های مورد انتظار است.

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

نوشته هفت R در مدیریت تغییر اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.