چه چیزی تغییر است چه چیزی نیست!؟
گفتیم که توسعه‌دهندگان و کاربران با تغییرات میانه‌ی خوبی ندارند و آنرا بروکراسی دست و پا گیر قلمداد می‌کنند یکی از مهمترین دلایل این برداشت عدم تفکیک درست نوع اقدام برای نامیدن آن بعنوان تغییر است پیش از انجام هر اقدامی، این سوال کلیدی را پاسخ دهید:" آیا این، تغییر است یا نه؟" هر چیزی را در لوای تغییر فرو نبرید با این کار باز هم جبهه‌ی مقاومت افراد را خواهید دید. دامنه‌ی مدیریت تغییر باید روشن باشد. به نظرم، تعریف دقیق یک تغییر یعنی:"افزودن، اصلاح یا حذف هر چیزی که می‌تواند تأثیر مستقیم یا غیرمستقیم بر خدمات داشته باشد." بنابراین این تعریف برای هر اقدامی قابل تفسیر نیست.
بدانید که هدف این است که هر نوع تغییر غیرعملیاتی در سرویس را مدیریت کنید. وظایف عملیاتی روزمره که برای ادامه‌ی ارائه خدمات مورد نیاز است بی‌شک تحت پوشش مدیریت تغییر نخواهد بود. تغییرات، فعالیت‌هایی هستند که نحوه‌ی ارائه خدمات را تغییر می‌دهند بنابراین از آنها برای فعالیت‌های لازم برای ارائه خدمات استفاده نباید کرد.
در کاتالوگ خدمات، خدمات به گونه‌ای تعریف شوند که شامل درخواست‌های خدمت در دسترس کاربر نهایی باشد. این درخواست‌ها برای انتخاب از طریق فهرست درخواست خدمات آنلاین به کاربر نهایی ارائه می‌شود. مطمئن باشید پس خدمات تغییر و خدمات عملیات روزمره را با هم اشتباه نگیرید. وقتی کاربر نهایی درخواستی را انتخاب می‌کند و درخواست پردازش می‌شود، این بخشی از نحوه‌ی ارائه‌ی خدمات است بنابراین این نوع درخواست‌های خدماتی تغییر در سرویس نیست و وقتی تغییر نیست پس نباید از طریق روش مدیریت تغییر نیز مدیریت شود.
در کلامی ساده‌تر، یک تغییر برای تغییر سرویس از یک حالت به حالت دیگر اعمال می‌شود، بدون اینکه قصد بازگشت به حالت اصلی(اولیه) به عنوان بخشی از تغییر را داشته باشد. پس اقدامی که منجر به تغییر وضعیت یک سرویس نمی‌شود تغییر نیست! مدیریت تغییر به سازندگان تغییر در تحقق ایجاد یا بهبود سرویس‌های جدید، با حداقل منابع و ریسک کمک می‌کند بنابراین شناخت اینکه آن اقدام تغییر است یا نه؟ اینکه آیا سرویسی در حال تغییر حالت است یا خیر چیزهایی است که باید بخوبی مشخص گردد.
نمونه‌هایی که تغییر محسوب می‌شوند:
- اجرای کد جدید در یک نرم‌افزار سازمانی
- اصلاح زیرساخت شبکه
- تغییر سرویس رسیدگی به درخواست‌های مشتریان.
- ارتقای نرم‌افزار اتوماسیون اداری به نسخه‌ی بالاتر
نمونه‌هایی که تغییر محسوب نمی‌شوند:
- راه‌اندازی مجدد سرور برای بازیابی در یک حادثه
- بازنشانی گذرواژه
- بازکردن یا بستن پورت‌های سوییچ
- تغییر رمز ادمین سرورها
داشتن یک تعریف روشن، ساده و توافق شده از آنچه که تغییر است، یا نیست سبب می‌شود از تلاش بیهوده برای فعالیت‌های پردازشی که نیازی به مدیریت تغییر ندارند، جلوگیری کنید.
دامنه‌ی تغییر
پرسش دیگری که باید به آن پاسخ روشنی بدهید اینست که دامنه ی این تغییر چقدر است!؟ من دیده‌ام که سازمان‌ها برای مدیریت روند تغییر، روش مدیریت تغییر را آنقدر پیچیده کرده‌اند که اصلاً کار نمی‌کند. پس ساده‌کردن آن روند مدیریت را نیز تسهیل و تسریع خواهد کرد.
ساده‌سازی تغییر یعنی تعیین دامنه‌ی تغییر. و این در هزینه و اجرای مناسب آن صرفه‌جویی زیادی خواهد کرد به خاطر داشته باشید که هر تغییری یک پروژه است به‌همین خاطر در ITIL مدیریت پروژه بعنوان فرایند پشتیبان مدیریت تغییر قرار گرفته پس تعیین دامنه‌ی واقعی یک تغییر منجر به مدیریت ساده‌ی منابع می‌شود!
باید در نظر داشته باشید که تغییرات کوچک، پروژههای کوچکی است و تغییرات بزرگ، پروژههای بزرگ؛ پس یک تغییر کامل باید تمام جنبه‌های مدیریت پروژه پیچیده را در نظر داشته باشد. غفلت از هر مولفه‌ای احتمال موفقیت آنرا به شدت کاهش خواهد داد. درست مانند هر پروژه‌ی بزرگی، در هر تغییر نیز باید همیشه تأثیرات احتمالی عوامل خارجی نیز در نظر گرفته شود. نظیر: لجستیک، کارکنان عملیات، هزینه‌های جاری، محیط کاری، درک مشتری، آیین‌نامه‌ها و ...
به عبارت ساده، فاکتورهای خارجی محتمل بر هر تغییر را در نظر بگیرید. در بیشتر اوقات، چنین ملاحظاتی مختصر و واضح است، اما حداقل باید مدتی را به آن اختصاص داد.
تغییرات یک چرخه‌ی حیات دارند، درست مثل پروژههای برادر بزرگترشان. بخشی از این چرخه‌ی حیات برنامه‌ی ارتباطی است که جزئیات لازم را به ذینفعان، که این تغییر باید در چه زمانی و به چه روشی اجرا شود را بیان کند. همچنین در این چرخه باید مشخص کرد که طرح تحویل و مدیریت منابع چگونه خواهد بود؟ چه کسی و چه زمانی باید آنرا انجام دهد؟ این تغییر در کدام ترتیب کاری انجام می‌شود (WBS)؟ -ساختار شکست کار- و در نهایت چگونه با حداقل تأثیر بر خدمات تولید و محیط کسب و کار اجرا می‌شود؟
ملاحظات یکسانی برای هر پروژه‌ی بزرگ باید در نظر گرفته شود تا اطمینان حاصل شود که دامنه و تأثیر کامل تغییر درک شده است. اگر با هر تغییری به عنوان یک پروژه‌ی کوچک رفتار کنید احتمال اینکه چیزهایی را از دست بدهید کمتر است.
ادامه مطلب در صفحه بعد…
[…] تمرین قابلیت/کنترل تغییر […]
[…] تمرین قابلیت/کنترل تغییر […]
[…] صفر تا صد قابلیت تغییر […]
[…] تمرین قابلیت تغییر در ITIL […]