هفت گناه مرگبار در مدیریت تغییر

هفت گناه مرگبار در مدیریت تغییر

• هر درخواست تغییری باید یک هیئت مشاورین تغییر (CAB) داشته باشد.

ایراد اساسی که به غلط تفسیر شده این است که هر درخواست تغییری باید یک کمیته [۲]CAB برای تایید داشته باشد و از آنجایی که متاسفانه، مدلهای تغییر و معیارهای ارزیابی آن تعریف نشده است، برای هر درخواست تغییری یک کمیته CAB‌ در نظرگرفته شده است بی آنکه برای پیچیدگی تغییر یا نیازمندی به منابع یا تاثیر آن، کمیته ای در نظر گرفته شود. این یعنی درگیر کردن هر کمیته ای برای هر تغییری در حالیکه اکثر تغییرات (جزئی) نیازی به فرایند تایید و کمیته CAB ندارند!

• هیچ حمایت مدیریتی وجود ندارد.

این دومین مسئله در پیاده سازی مدیریت تغییر است. من معتقدم مدیریت - به خصوص مدیریت ارشد - باید حمایت تمام قد خود را برای تأمین فرآیند مدیریت تغییرات موثر ارائه نماید. اما آنچه من اغلب در هنگام اجرای سیاست ها و حمایت از روند می بینم این است که مدیران ارشد (بدلیل کمبود وقت- مشکلات کلان! و..) نمی خواهند (به ظاهر) سیاست ها و فرایندهایی را که از آنها درخواست شده، را بدرستی پاسخ دهند. علت آنهم اینست که آنها درک درستی از اهمیت مدیریت تغییرات موثر را ندارند.

• تا قبل از پیاده سازی، هیچ درخواست تغییری(RFC[3]) مطرح نشده است.

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

• فقط مدیر تغییر[۴]، مسئولیت موفقیت آمیز بودن تغییر است.

تصور غلطی که اغلب در مورد نقش مدیر تغییر هست این است که زمانیکه یک بار RFC ثبت شد، مدیر تغییر، مسئول هماهنگی همه فعالیت های مرتبط با تغییر است. اما واقعیت این است که مدیر تغییر صرفا برای اجرای عملیاتی فرایند تغییر، پاسخگو است و این نقش برای این مورد تعیین شده تا اطمینان حاصل کند که فرایند RFC مربوط به او، طبق روال پیش می رود یا نه! بنابراین او هیچ نقش و دخل و تصرفی در طراحی، ساخت، آزمایش و اجرای یک تغییر ندارد. پس در خصوص موفقیت آمیز بودن یا شکست یک تغییر هم قطعاً پاسخگو نخواهد بود! - البته بماند در مواردی که یک نفر تمامی نقش های تغییر را بازی می کند! 🙂 -

• برنامه زمانبندی تغییر برای خارج از IT ارایه نمی شود – حتی گاهی اوقات، در داخل IT هم ارایه نمی شود.

جدول برنامه زمانبندی تغییرات با هدف ترویج ارتباطات و شفافیت انفورماتیک با سایر دپارتمان های سازمان تنظیم و تدوین شده که نه تنها در رابطه با فرایند مدیریت تغییر، بلکه در مورد تقاضا و حجم کاری درون فناوری اطلاعات، سند و چشم اندازی برای برنامه جامع تغییرات موثر انفورماتیک در سازمان است. اما متاسفانه بسیاری از وجود آن بی اطلاعند!

• CABها اعضای مناسبی ندارند.

کمیته های CAB اغلب فقط از پرسنل فناوری اطلاعات تشکیل شده اند و اثری از مشارکت پیمانکاران و همکاران تجاری در امر تغییرات نیست! همین موضوع باعث می شود تا نرخ ریسک اجرای یک پروژه را نتوانید به وضوح تعیین کنید!

• فرایند مهندسی

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

بنابراین جای تعجب نیست که شرکای تجاری ناامید شده شوند و فناوری اطلاعات ناامیدتر از اجرای تغییر!

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