در این مقاله می‌خوانید:

• جانمای مدیریت تغییر در خدمات فناوری اطلاعات
• رابطه مدیریت تغییر با سایر تمرینات
• مدیریت تغییر و مدیریت حادثه
• مدیریت تغییر و مدیریت درخواست
• مدیریت تغییر و مدیریت مشکل
• مدیریت تغییر و مدیریت پیکربندی CMDB
• مدیریت تغییر و مدیریت انتشار
• مدیریت تغییر و مدیریت پروژه
• سوالات متداول FAQs

مدیریت تغییر تنها با تکمیل یک تغییر پایان نمی‌یابد. توانایی مدیریت تغییر برای اجرای مؤثر تغییرات می‌تواند تا حد زیادی از اطلاعات جمع‌آوری‌شده در سایر فرایندهای ITSM بهره‌مند شود و بالعکس. داشتن توانایی برای مرتبط کردن حوادث با تغییراتی که باعث ایجاد آن شده، یا منجر به‌روزرسانی CMDB بر اساس تغییرات زیرساختی فناوری اطلاعات شده مهمترین قسمت از مدیریت تغییر است که آغازگر ایجاد یک ITSM  سالم و کاربردی است برای کمک به مدیریت کاروکسب شما.

در اینجا باید بدانید که چگونه مدیریت تغییر می‌تواند با سایر فرایندهای ITSM شما کار کند:

فرایند مدیریت تغییر با مدیریت حادثه، مدیریت درخواست، مدیریت انتشار، مدیریت پیکربندی CMDB و مدیریت پروژه ارتباط تنگاتنگی دارد.

مدیریت تغییر و مدیریت حادثه:

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

 مدیریت تغییر و مدیریت درخواست تکمیل یا درخواست خدمت:

مهم است که از تغییرات برای درخواست خدمات با تأثیر بالا استفاده کنید تا زیرساخت‌های فناوری اطلاعات خود را به‌روز نگه‌دارید. بدون تغییر، درخواست سرویس برای ارتقاء سرور یا درخواست ارتقاء فضای ذخیره‌سازی Azure با سرویس به پایان می‌رسد تحویل داده می‌شود. اما هنگامی‌که از یک تغییر برای اجرای درخواست خدمات استفاده می‌کنید، می‌توانید اطلاعات بیشتری مانند دلیل تغییر و برنامه پیاده‌سازی را جمع‌آوری کنید، تأییدیه‌های لازم را از همه ذینفعان دریافت کنید. و CMDB را با اطلاعات جدید به‌روز کنید.

توجه: برای تکمیل درخواست خدماتی با تأثیر بالا و هر درخواست خدماتی که نیاز به تغییر در CMDB  دارد، بهتر از تغییر استفاده کنید. همچنین هر نیازی که منجر به آپدیت یا به‌روزرسانی CMDB ، شود نیاز به تغییر دارد!

 مدیریت تغییر و مدیریت مشکل:

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

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

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

تسلط بر مدیریت تغییر: نکاتی برای غلبه بر مقاومت در برابر تغییر

ممکن است ارزش مدیریت تغییر موثر را در دستیابی به موفقیت سازمانی ندانید. در محیط کسب و کار سریع و دائماً در حال تحول امروز، تغییر برای تسلط بر مدیریت تغییر اجتناب ناپذیر و ضروری است:

نکاتی برای غلبه بر مقاومت در برابر تغییر

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

مقدمه ای بر مدیریت تغییر

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

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

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

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

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

انواع تغییر

فارغ از حجم و اندازه‌ی تغییر، از بعد کلی تغییرات چند نوعند و چندین نوع تغییر وجود دارد که سازمان ها ممکن است نیاز به مدیریت داشته باشند. این شامل:

تغییر فرآیند: این تغییر در روش انجام کار است، مانند پیاده سازی یک سیستم نرم افزاری جدید یا تغییر فرآیند تولید.

تغییر ساختاری: این تغییر در ساختار سازمانی است، مانند سازماندهی مجدد یا ادغام.

تغییر فناوری: این تغییر در فناوری مورد استفاده سازمان است، مانند پیاده سازی یک پلت فرم جدید یا ارتقاء سخت افزار.

تغییر استراتژیک: این تغییر در استراتژی کلی سازمان، مانند ورود به یک بازار جدید یا تغییر تمرکز کسب و کار است.

فرآیند مدیریت تغییر

مدیریت تغییر موثر شامل یک فرآیند ساختاریافته است که شامل چندین مرحله است. این مراحل عبارتند از:

1. ارزیابی نیاز به تغییر: این شامل شناسایی نیاز به تغییر و تعیین دامنه تغییر است.
2. برنامه ریزی برای تغییر: این شامل تدوین یک برنامه دقیق برای اجرای تغییر، شامل جدول زمانی، منابع و مسئولیت ها است.
3. اجرای تغییر: این شامل اجرای برنامه، از جمله ارتباطات، آموزش و آموزش برای کارکنان است.
4. نظارت و ارزیابی تغییر: این شامل ردیابی پیشرفت تغییر و انجام تنظیمات در صورت نیاز است.

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

نوشته <strong>تسلط بر مدیریت تغییر: نکاتی برای غلبه بر مقاومت در برابر تغییر</strong> اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.

نقش کارکنان فناوری اطلاعات در افزایش نرخ حوادث کاربران

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

مشکل کجاست؟

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

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

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

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

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

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

پاسخ، بله چون آتش در حال پیشرفت است!

نتیجه: سوختن اکثر درختان، آسیب دیدن حافظان طبیعت

اما پیش از این چه باید می‌کردیم که به این روز نیافتیم؟

باید ببینم چه کسی و چه چیزی این آتش را به راه انداخته و چرا!؟

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

خُب علل طبیعی در جنگل فناوری امری قابل درک است. ممکن است هر اتفاقی منجر به از کار افتادن سرویس شود. برخی از آنها بطور پیشگیرانه قابل حل‌اند و برخی منفعلانه. بحث مهم ITIL در زمینه‌ی مدیریت حادثه نیز برای همین دسته از خرابی‌های طبیعی است.

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

مثال‌هایی از علل وقوع خرابی‌های طبیعی در فناوری اطلاعات می‌تواند مواردی نظیر: سوخته شدن پاور یک سیستم، کنده شدن سوکت کابل شبکه، هنگ کردن سرور، اتمام کارتریج پرینتر، عدم آموزش کاربر و … باشد

و علل عمدی می‌تواند شامل: تغییر پورت وب یک نرم‌افزار تحت وب، تغییر دسترسی به نرم‌افزار، انجام پالیسی‌های امنیتی جدید، تغییر منابع سخت‌افزاری یک سرور، تغییر روش ورود به فلان نرم‌افزار، تغییر سناریو پرینت سرور و….

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

در ITIL تمرین مدیریت حادثه یا Incident Management برای رفع رجوع همین موارد مطرح شده. هدف آن ثبت و رسیدگی به حوادث و به حالت نرمال درآوردن تغییر وضعیت یک سرویس معیوب به یک سرویس سالم است. اما باید دقت داشت که اگرچه این تمرین برای هر نوع علت خرابی اعم از عمدی یا طبیعی می‌تواند به کار گرفته شود اما ماهیت درست آن رسیدگی به علل طبیعی خرابی سرویس‌هاست.

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

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

فراموش نکنید هیچ تغییری را کوچک نشمرید! یک تغییر به‌ظاهر کوچک می‌تواند منجر به فاجعه شود! همچنان که یک ته‌سیگار می‌تواند جنگلی را به آتش بکشد!

هادی احمدی

نوشته باعث بیشتر خرابی‌ها خودِ واحد فناوری اطلاعات است! اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.

هیات مشاورین تغییر یا CAB در مدیریت تغییر

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

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

هدف ۱: ارائه‌ی خدمات قابل اعتماد با ثبات که مشتریان می‌توانند به آن اعتماد کنند.

هدف ۲: ارائه‌ی خدمات انعطاف‌پذیر است که می‌تواند به سرعت با نیازهای مشتری تغییر کند.

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

 نکته: اگرچه تیم CAB قادر به ارایه‌ی مشاوره، اثرگذاری، ارزیابی و تصدیق فرایند پیاده‌سازی یک  مرحله و یا مراحلی از تغییر هستند. اما تصمیم‌گیرنده‌ی نهایی برای اجرای/عدم اجرای یک تغییر نیستند. بلکه در نهایت خود مدیر تغییر، مسئول تأیید/ رد تغییرات است.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

آندون در مدیریت فناوری اطلاعات

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

مثلاً شرکت تویوتا از این مفهوم در کلیه‌ی ایستگاه‌های خط تولید خود استفاده کرد این یعنی در دسترس هر کارگری یک فانوس آندون هست که هرکسی می‌تواند ریسمان آندون Andon Cord را بکشد (یا دکمه‌ای را فشار دهد) و خط تولید را متوقف کند اینکار برای نشان‌دادن این است مشکلی حادث شده و یک سری اقدامات درمانی و اصلاحی باید صورت گیرد و این امکان را می‌دهد تا پیش از شروع مجدد تولید، مشکل حل شود. با آندون، اگر چیزی نادرست باشد، نیازی به کسب تکلیف و یا دریافت فرمان سلسه‌مراتبی نیست و هر کارگر در خط تولید، با هر تجربه و سطح دستمزدی که داشته باشد، حق دارد ریسمان را بکشد. ریسمان آندون به عنوان یکی از عناصر روش کیفیت Jidoka توسعه یافته و با کمک آن تویوتا و سیستم تولید تویوتا، به کارگران این امکان را می‌دهد تا به همکاران و مدیریت مشکلات کیفیت و فرآیند در سراسر مونتاژ اطلاع دهند و حتی تولید را متوقف کنند.

شبیه کشیدن ترمز یک قطار مترو با اینکه راننده قطار کسی دیگر است و اختیار هدایت قطار را دارد اما هر مسافری در شرایط خاص قادر است این ترمز را بکشد.

آندون نشان‌دهنده‌ی درجه‌ای از استقلال فردی در یک سیستم است برای جلوگیری از پیامدهای ناخوشایندتر! این مفهوم امروزه از کنوانسیون‌های صنعتی فراتر رفته. این استقلال یکی از بلوک‌های ساختاری فرهنگی تولید ناب است. در دنیای فناوری اطلاعات نیز افرادی که به‌دنبال درک چارچوب‌های ITIL،   Lean IT و یا DevOps باشند، مهم است که این موضوع را بشناسد.

همچنان که آندون یکی از نمادهای صنعتی در تولید ناب است، جلسه‌ی هیئت مشاورین تغییر ITIL (CAB) برای بسیاری از افراد در DevOps نیز نمادی قدرتمند برای ITSM است.

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

با این وجود، داشتن درخواست بررسی CAB در مورد ریسک ناشناخته، هنگامی که افراد و ذینفعان بیشتری ممکن است تحت تأثیر این تغییر قرار بگیرند، اهمیت و ضرورت پیدا می‌کند این یعنی بسته به ریسک تغییر، مفهوم کاربردی آن بیشتر به‌چشم می‌آید.

در فرایند مدیریت نشر که تغییری در روند توسعه نرم‌افزاری است، لزوم استفاده از تغییراتی که نیازی به طی کردن روند تایید نداشته باشد مهم است اما باید بسته به تاثیر این تغییر و ریسک آن دسترسی کشیدن ریسمان آندون (انجام تغییر بدون کسب تکلیف و تایید) در دسترس کارکنان فناوری اطلاعات قرار گیرد.

بیاید کمی بازترش کنیم. مفهوم Andon Cord شامل استفاده از سیگنال‌ها و هشدارها برای نشان‌دادن این است که یک ایستگاه در خط مونتاژ، مشکل دارد. هشدارها توسط کارگران با کشیدن ریسمان آندون یا به طور خودکار توسط خود تجهیزات فعال می‌شوند.

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

بسیاری استدلال می‌کنند که استفاده از مفاهیم مدیریت ناب مانند ریسمان آندون در فناوری اطلاعات و مهندسی نرم‌افزار چالش برانگیزتر است. بخصوص در تولید نرم‌افزار و فرایند مدیریت نشر در ITIL.

معمولاً تنها فرصتی که برای آزمایش و بررسی وجود نقص در نرم‌افزار هست پس از تولید نرم‌افزار است که در اواخر چرخه‌ی تولید و توسعه رخ می‌دهد. که صد البته این خیلی دیر است زیرا در واقع، این مشتریان خواهند بود که با ثبت اعلام خرابی، اکثر آزمایشات را انجام می‌دهند.

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

پس در هنگام داشتن خط تولید و نشر نرم‌افزار توقف تولید برای جلوگیری از نقص، مشکلات امنیتی در طی فرآیند توسعه واقعی، روال کاملی دارد که با استفاده از مفهوم آندون می‌تواند بهتر ارایه شود، اما چگونه؟

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

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

نوشته کاربرد ریسمان آندون در مدیریت خدمات فناوری اطلاعات اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.

جای خالی نبودن مدیریت تغییر در تصمیمات کشور

داشتن تفکر ITIL چگونه می توانست اثرات مخرب تغییر افزایش قیمت بنزین را کاهش دهد!؟

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

شروع داستان:

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

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

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

1. کمک به قشر ضعیف و آسیب پذیر جامعه
2. جلوگیری از قاچاق سوخت
3. همسازی سازی و واقعی کردن قیمت ها به نسبت کشورهای همسایه
4. مقاومت در برابر تحریم های شدید

اما جدای از اهداف باطنی و ظاهری کار، چه شد به یکباره تغییر قیمت بنزین اینهمه آشوب بر پا کرد!؟

کجای کار اشکال داشت؟ اگر دولت می گوید برای مردم و کمک به قشر آسیب پذیر است پس چرا مورد اقبال همان قشر آسیب پذیر واقع نشد!؟ اگر برای جلوگیری از قاچاق است چرا اینقدر با مقاومت شدید مردم مواجه شد!؟ اگر مردم به تحریم ها و وخامت اوضاع و کارشکنی ترامپ در برجام آگاهند چرا اینهمه خشمناک و عصبی شدند؟ با اینکه رویکرد رابین هودی (از پولدار گرفتن و به فقیر عطا کردن) بود چرا قشر متوسط و مرفه شکایتی نداشت!؟

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

نوشته جای خالی نبودن مدیریت تغییر در تصمیمات بزرگ کشور اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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