راهنمای تخصصی
مدیریت تغییر ITIL
مدیریت تغییر برای کنترل ریسک تغییرات زیرساخت، نرم‌افزار و سرویس‌هاست تا تغییر با برنامه، تأیید، ارزیابی اثر و بازگشت‌پذیری انجام شود.
مدیریت تغییر ITIL چیست و کجا استفاده می‌شود؟
مدیریت تغییر برای کنترل ریسک تغییرات زیرساخت، نرم‌افزار و سرویس‌هاست تا تغییر با برنامه، تأیید، ارزیابی اثر و بازگشت‌پذیری انجام شود.
بخش مهمی از اختلالات سازمانی از تغییرات بدون برنامه، بدون اطلاع‌رسانی یا بدون ارزیابی اثر ایجاد می‌شوند.
مدانت این محتوا را برای تصمیم‌گیری اجرایی آماده کرده است؛ یعنی کاربر فقط با تعریف اصطلاح روبه‌رو نیست، بلکه می‌بیند این موضوع در سرویس دسک پلاس فارسی چگونه طراحی، تنظیم، آموزش و پایش می‌شود.
اجزای اصلی و سناریوهای اجرایی
این بخش موضوع را به چند محور عملیاتی تقسیم می‌کند تا مشخص شود در زمان پیاده‌سازی چه چیزهایی باید طراحی یا تنظیم شوند.
ثبت درخواست تغییر
هر تغییر باید هدف، دامنه، ریسک، اثر، برنامه اجرا و برنامه بازگشت داشته باشد.
ارزیابی و تأیید
CAB یا نقش‌های مسئول باید بر اساس نوع تغییر، ریسک و زمان اجرا تصمیم بگیرند.
اجرا و بازبینی
پس از اجرا، نتیجه تغییر و اثر آن بر رخدادها و خدمات بررسی می‌شود.
چه زمانی به این موضوع نیاز دارید؟
- وقتی سازمان می‌خواهد درخواست‌ها، فعالیت‌ها و خروجی‌ها از مسیرهای پراکنده به یک مسیر قابل پیگیری منتقل شوند.
- وقتی مدیر IT نیاز دارد وضعیت خدمت، هزینه، حجم درخواست، کیفیت پاسخ و نقاط پرتکرار را با داده واقعی ببیند.
- وقتی تیم پشتیبانی می‌خواهد به جای پاسخ‌های موردی، از فرم، SLA، پایگاه دانش و اتوماسیون استفاده کند.
- وقتی قرار است تجربه کاربران داخلی یا مشتریان بیرونی شفاف‌تر، سریع‌تر و قابل اندازه‌گیری‌تر شود.
قبل از اجرا چه چیزهایی آماده شود؟
- نوع تغییر: استاندارد، عادی، اضطراری
- ماتریس ریسک
- تقویم تغییر
- برنامه rollback
- گزارش PIR
از مفهوم تا بهره‌برداری واقعی
در این مدل، صفحه فقط یک متن آموزشی نیست؛ به مسیر اجرا در سرویس دسک پلاس فارسی وصل می‌شود و برای راهبران، کارشناسان و مدیران خروجی قابل استفاده ایجاد می‌کند.
- جلسه شناخت: بررسی وضعیت فعلی، ابزارهای موجود، کانال‌های درخواست و انتظارات مدیریتی.
- طراحی اجرایی: تبدیل موضوع به فرم، نقش، SLA، گردشکار، گزارش، دسترسی و داده‌های مورد نیاز.
- پیاده‌سازی در سرویس دسک پلاس فارسی: تنظیم بخش‌های مرتبط، ساخت الگو‌ها، قوانین، اعلان‌ها و گزارش‌ها.
- آموزش و تحویل: آموزش راهبران و کاربران کلیدی، مستندسازی سناریوها و آماده‌سازی بهره‌برداری.
- بازبینی پس از اجرا: تحلیل داده‌های واقعی و اصلاح فرایند برای افزایش پذیرش و کاهش کارهای دستی.
چطور نتیجه را بسنجیم؟
- نرخ موفقیت تغییر
- تغییرات اضطراری
- تغییرات منجر به رخداد
- زمان تأیید تغییر
- تغییرات لغوشده
چه چیزهایی پروژه را ضعیف می‌کند؟
- شروع از تنظیمات نرم‌افزار بدون توافق روی فرایند و مالکیت.
- استفاده از اصطلاحات فنی در پورتال کاربر به جای زبان ساده و قابل فهم.
- نداشتن KPI روشن و در نتیجه ناتوانی در اثبات ارزش اجرا.
- بی‌توجهی به آموزش و پذیرش کاربران پس از راه‌اندازی.
- ساخت گزارش‌های زیاد اما بدون تصمیم مدیریتی مشخص.
مدانت چه چیزی تحویل می‌دهد؟
هدف این است که موضوع به نتیجه قابل استفاده تبدیل شود: تنظیمات، مستندات، گزارش و آموزش.
- فرایند Change Enablement
- تقویم تغییر
- فرم تغییر
- گزارش ارزیابی پس از اجرا
مطالب مرتبط
برای تکمیل مسیر، این بخش‌ها را هم ببینید.
