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

بررسی چالش ها و راهکارها در مدیریت موثر تغییر

نداشتن فرایند مدیریت تغییر[۱] یک چیز است و پیاده سازی غلط آن یک چیز دیگر!

واحد فناوری اطلاعات و ارتباطات بیش از ۹۰٪ از سازمان های کشور، فاقد مدیریت تغییر هستند و کارشناسان زیرساخت، برنامه نویسان، سرپرستان و مدیران انفورماتیک همه و همه طبق تحربیات قبلی، علاقمندی شخصی، نظرات فردی و یا صرفا بر اساس اجرای بی چون و چرا دستورات مافوق خود، تغییراتی را در شبکه، نرم افزارهای سازمانی و یا سخت افزارها و حتی در روال های و فرایندهای انجام کار، اعمال میکنند غافل از اینکه با این کار بظاهر خوب! چه بار ترافیکی ناخواسته ای را به سمت کارشناسان واحد پشتیبانی سرازیر میکنند!

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

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

بنابراین مدیریت غلط تغییر، علاوه بر سرخوردگی تمامی ذینفعان، خود، تبدیل به یک کار بیهوده مازاد و فاقد ارزش می شود که نه تنها حجم کار کارشناسان و مدیران فناوری را زیاد خواهد کرد بلکه رهاوردی جز اتلاف وقت و انرژی نخواهد داشت و علاوه بر آنها، کاربران و کل سازمان نیز ار اجرای تغییرات مایوس خواهند کرد؛ آنگونه که اعتماد کاربران برای انجام هرگونه تغییری ولو اندک توسط انفورماتیک یک “داستان دیگر!” تلقی خواهد شد و افزایش نارضایتی و بی اعتمادی دست از سر IT برنخواهد داشت!

لذا باید ابتدا بدقت ببینم هدف ما از مدیریت تغییر چیست با درک درست از سوبرداشت ها جلوگیری می شود ضمن اینکه میتوان مدیریت موثری پیاده سازی نمود تا بعنوان ارزش گذار هموار مطرح گردد….

هدف از مدیریت تغییر چیست؟

فرایند مدیریت تغییر سه هدف اصلی دارد:

نخست) اطمینان از برنامه ریزی مناسب، بررسی، هماهنگی و ارتباط تغییر.

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

دوم) حفظ آنچه که در حال حاضر، محافظت شده است.

یک تغییر، همیشه برای بهبود است بنابراین نباید بر خدماتی که از قبل مدیریت شده، تاثیری منفی بگذارد اگر تغییری سبب بروز وقایع ناخوشایند می شود و تأثیر منفی بر خدمات مدیریت شده فعلی می گذارد این معنی را القا می کند که مدیریت صحیح این تغییر بدرستی انجام نشده است!

سوم) اطمینان از این که خروجی تغییر، نتیجه مورد نظر را فراهم می کند.

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

بنابراین اگر در خروجی مورد نظر از یک تغییر، آن نتیجه ای که انتظار داشته اید را به دست نیاوردید حتما یک جایی از کار اساسی می لنگد و حاصل این بی نتیجه بود چیزی جز ناامیدی، ناراحتی و سردرد نخواهد بود بنابراین اگر صدای زنگ این چالش به گوشتان آشناست دلایل ناموفق بودن یک تغییر را که شبیه گناهان مرگبار است بخوانید.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

هفت ثواب برای از بین بردن گناه

اگر روند مدیریت تغییر شما و همکاران را در فناوری اطلاعات رنج می دهد، در اینجا هفت مورد ذکر شده که می توانید برای از بین بردن گناهان خود انجام دهید:

1. تعریف الگوهای تغییر[۵].

برای اجرای یک تغییر ،یک مدل تغییر را به سادگی می توان از پیش تعریف کرد. اجرای مراحل در یک مدل تغییر اغلب سریعترین راه برای پیاده سازی تغییر است. بنابراین صرفا به تعریف یک مدل (الگو) تغییر بسنده نکنید و برای مقاصد مختلف و بر اساس ۳ حالت تغییر (تغییر جزئی، تغییر استاندارد و تغییر عمده)، الگوهای متفاوتی از قبل طراحی کنید.

• تعریف و تحقق مسئولیت های مالک تغییر.

فقط مالک تغییر[۶]، برای موفقیت آمیز بودن یا نبودن تغییر باید پاسخگو باشد، نه مدیر تغییر[۷].

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

• تعریف معیارهای ارزیابی.

تمامی درخواست های تغییر یا RFCها، پیش از اجرا نیازی به تایید و بازبینی کمیته CAB ندارند. در حقیقت، در یک فرایند مدیریت تغییر تعریف شده خوب، اکثر RFCها را می توان توسط شخص دیگری به غیر از کمیتهCAB به تایید و بازبینی رساند. تعریف معیارهای ارزیابی کمک می کند تا اطمینان حاصل شود که برای RFCهای “صحیح”، افراد “مناسب” نیز تعیین شده است.

• تعریف یک ماتریس مجوز تغییر.

تعریف و پیروی از یک ماتریس تغییر، مشخص می کند کدام افراد “حق” بررسی و تأیید RFCها را دارند. آیا مدیریت ارشد، امکان بررسی و تأیید تغییرات را دارد؟ این موضوع کمک می کند تا نظارت های و حدود دسترسی بهتر مشخص گردد در نتیجه تعامل و تعهد مدیریت نیز افزایش خواهد یافت.

• جدول زمانبندی تغییر را برای همه منتشر کنید.

انتشار برنامه زمانبندی تغییرات دقیقا شبیه جدول زمانبندی پروازها در فرودگاه است که نه تنها سبب بهبود مدیریت اطلاع رسانی و قدرت ارتباطات در فناوری اطلاعات را بهبود می بخشد، بلکه مسیری عالی برای نشان دادن کارایی و عملکرد اجرایی واحد IT نیز هست.

• تولید و انتشار معیارهایی که برای کسب و کار مناسب است.

در حالی که انتشار تعدادی از تغییرات اجرا شده در یک دوره زمانی خوب است لازمست بدانید، اندازه گیری و انتشار پیشرفت های کسب و کار در نتیجه پیاده سازی تغییرات نیز بسیار معنی دار خواهد بود. به عنوان مثال، اگر یک تغییر برای “کاهش زمان رسیدگی به درخواست ها” یا سفارشات اجرا شده است، معیارها و نتایج حاصله که سبب بهبود عملکرد سازمان شده را منتشر نمایید تا نتایج برای همه ملموس باشد و اثرگذاری این تغییر در کسب و کار بخوبی احساس شود.

• کارهای غیر ارزش افزوده را حذف و زمان انتظار را بین ببرید.

خروجی کار اهمیتی ندارد، نتیجه کار مهم است! بر طبق مفاهیم ITIL4 لزوم خلق ارزش در هر کاری معیار صحیح انجام آن کار است بنابراین نتیجه گرا باشید زیرا صرفا تولید کارهای فاقد ارزش افزوده و ایجاد بروکراسی و زمان انتظار برای برگزاری جلسات بیشتر هیچ دستاوردی بهمراه نمی آورد!

به عنوان مثال، چرا خودسرانه جلسات CAB را به صورت هفتگی برگزار می کنید؟ یک صفحه از Agile را بیرون بیاورید و از جلسه روزانه ایستاده مانند “جلسه CAB” استفاده کنید. بیشترین حجم ساعات هدر رفته مدیران و کارکنان حضور در جلسات با کمترین نتیجه است!

بنابراین اگر فرایند مدیریت تغییر، همان نتایجی که سازمان نیاز دارد، را تولید نمی کند؟ و حتی بدتر، اگر خود فرآیند مدیریت تغییر، هنوز در راه ایجاد تغییرات است؟ تسلیم نشوید – این هفت اقدام فوق را بکار بگیرید تا مطمئن شوید که فرایند مدیریت تغییر را از “مانع[۸]” به “ارزش گذار[۹]” تبدیل کنید!

هادی احمدی

[۱] Change Management

[۲] Change Advisor Board

[۳] Request for Change

[۴] Change manager

[۵] Change Template

[۶] Change Owner

[۷] Change Manager

[۸] Barrier

[۹] Value enabler