گروه فناوری پرندگروه فناوری پرند
  • صفحه اصلی
  • وبلاگ پرند
  • مقاله
  • ویدئو
  • اینفوگرافیک
  • اخبار و اطلاعیه
با ما تماس بگیرید
  • صفحه اصلی
  • وبلاگ پرند
  • مقالات
  • هفت گناه کبیره در فرآیند مدیریت تغییر

وبلاگ گروه فناوری پرند

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

توسط شیما فکار / سه شنبه, 29 بهمن 1398 / منتشر شده در مقالات, مقاله کاربردی
فرآیند مدیریت تغییر زمان تقریبی مطالعه: 5 دقیقه

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

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

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

۱. اطمینان از طرح‌ریزی مناسب، بازنگری، هماهنگی و تعاملات در هر تغییر.

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

۲. محافظت از خدماتی که تولیدشان از پیش شروع شده است.

یک تغییر نباید بر خدماتی که پیشتر در محیط زیرنظر مدیریت وجود داشته‌اند، تأثیر منفی بگذارد.

۳. اطمینان از اینکه یک تغییر ما را به نتیجه‌ی موردنظرمان می‌رساند.

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

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

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

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

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

۱. ارسال هر درخواست تغییر (RFC)، پیش از موعد، برای کمیته راهبری تغییر (CAB).

از بین همه‌ی این گناهان، این یکی خیلی رایج است و در فرآیند مدیریت تغییر زیاد مرتکبش می‌شویم. ازآنجاکه الگوهای تغییر و معیارهای ارزیابی تعریف نشده‌اند، «هر» درخواست تغییری ـ صرف‌نظر از پیچیدگی، نیازمندی‌های منابع، یا تأثیرش ـ برای کمیته‌ی راهبری تغییر فرستاده می‌شود.

۲. نبود حمایت مدیریتیِ مناسب.

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

۳. درخواست تغییر، درست تا پیش از پیاده‌سازی، مطرح نمی‌شود.

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

۴. هیچ‌کس، جز مدیر تغییر، هیچ مسئولیتی در قبال موفقیت‌آمیز بودن فرآیند ندارد.

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

۵. منتشر نشدن طرح تغییر در خارج از چارچوب IT (گاهی حتی داخل چارچوب IT هم منتشر نمی‌شود!).

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

۶. کمیته‌ راهبری تغییر اعضای مناسب و شایسته‌ای ندارد.

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

۷. جلو زدن فرآیند از مهندسی.

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

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

۷ راهکار برای رفع موانع در فرآیند مدیریت تغییر

۱. مدل‌های تغییر را تعریف کنید.

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

۲. وظایف مالک تغییر را تعیین و اجرا کنید.

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

۳. معیارهای ارزیابی را تعیین کنید.

لازم نیست همه‌ی درخواست‌های تغییر را برای بررسی و دریافت مجوز به کمیته‌ راهبری تغییر ارجاع بدهید. درواقع، در فرآیند مدیریت تغییری که درست تعریف شده باشد، بیشترِ درخواست‌های تغییر باید به شخص دیگری، جز اعضای کمیته راهبری تغییر، ارجاع داده شوند. تعیین معیارهای ارزیابی کمک می‌کند که مطمئن شویم درخواست‌های «درست» به افراد «درست» ارجاع داده می‌شوند.

۴. ماتریس اختیار تغییر (نقش‌ها و مسئولیت‌ها) را مشخص کنید.

ماتریس اختیار تغییر نشان می‌دهد که فرد «درست» برای بررسی و پاسخ‌گویی به درخواست‌ها چه کسی است؟ نظر، تأیید و تعهد مدیر ارشدتان را در مورد ماتریس اختیار جلب کنید ـ این موضوع به مسئولیت‌پذیری و پاسخ‌گویی کمک می‌کند.

۵. طرح تغییر را «برای همه» منتشر کنید.

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

۶. معیارهایی را ایجاد و اعلام کنید که مناسب کسب‌وکار شما باشد.

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

۷. هر کاری را که ارزش افروزده‌ای خلق نمی‌کند حذف کنید و اجرای فرآیند را به تعویق نیندازید.

مثلاً چرا به صورت قراردادی، باید جلسات کمیته راهبری تغییر را هفتگی برگزار کنید؟ می‌توانید یک کار دیگر بکنید! از جلسات سرپاییِ روزانه برای جلسات کمیته راهبری تغییر استفاده کنید.

 

منبع: https://www.sysaid.com

برای مطالعه‌ی بیشتر در مورد فرآیند مدیریت تغییر و نحوه‌ی صحیح اجرای آن در سازمان برچسب «مدیریت تغییر» را دنبال کنید.

برچسب ها: مدیریت تغییر

درباره شیما فکار

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

دیدگاهتان را بنویسید لغو پاسخ

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

آخرین مطالب

  • علیرضا بزرگمهری مشاور هیات مدیره گروه فناوری پرند

    رهنمون هایی برای همه کشورها حتی ایران، همسویی ITIL با بهروش ها

  • صنعت فین‌تک در دنیای پس از کرونا

  • هشت قابلیت که برای انتخاب ابزار ITSM سازمان خود باید در نظر بگیرید

  • وضعیت مدیریت خدمات در سال ٢٠٢١

  • داستان پذیرش ITIL توسط بانک مرکانتیل / از ایجاد نقش ITIL بپرهیزید، مگر آنکه واقعاً به آن نیاز باشد

  • چهار ویژگی ضروری انتخاب راهکار ITSM

    چهار ویژگی ضروری ابزار ITSM

  • اتوماسیون پیشخوان خدمت

    آیا توفان اتوماسیون در حال نزدیک‌شدن به پیشخوان خدمت است؟

  • وضعیت خدمات سلف سرویس

    وضعیت موفقیت خدمات سلف‌سرویس فناوری اطلاعات

برچسب های مطالب

B2B BRM CRM GDPR IT ITIL ITIL4 ITSM VeriSM Wendia استاندارد ایزو استراتژی خدمت امنیت اینفوگرافیک بانکداری بهبود مستمر خدمت تحلیل تأثیر بر کسب و کار تحول دیجیتال خودکارسازی دواپس راه پرداخت صنعت پرداخت عصر تراکنش فرآیند انجام درخواست فروش مدیریت انتشار و استقرار مدیریت تداوم خدمات فناوری اطلاعات مدیریت تغییر مدیریت خدمات سازمانی مدیریت دارایی و پیکربندی مدیریت دانش مدیریت دسترس پذیری مدیریت رخداد مدیریت رویداد مدیریت ریسک مدیریت سطح خدمت مدیریت ظرفیت مدیریت مالی مدیریت مشکل مدیریت پرداخت مدیریت پروژه نرم افزار POB پیشخوان خدمت چابک کارکردهای حیاتی کسب و کار

بی‌خبر نمانید!

آدرس ایمیل خود را وارد کنید تا پربازدیدترین محتواهای وبلاگ گروه فناوری پرند را در ایمیل خود دریافت کنید.

گروه فناوری پرند

  • چرا پرند؟
  • همان پرند هستیم
  • وبلاگ پرند
  • ارتباط با گروه فناوری پرند
  • مشتریان ما
  • داستان موفقیت مشتری
  • درخواست جلسه دموی اختصاصی
  • فرصت‌های شغلی

صفحات پر بازدید

  • آشنایی با نرم‌افزار Wendia POB G6
  • مدیریت پیشخوان خدمات
  • مدیریت دارایی و پیکربندی
  • مدیریت تغییر و پروژه
  • مدیریت انبار و خرید
  • مدیریت سطح خدمات
  • مدیریت زمان و منابع
  • مدیریت صورتحساب و امور مالی
  • یکپارچگی با نرم‌افزارها
  • راهکار Bank On
  • راهکار شرکت‌های پرداخت
  • راهکار صنعت بانکداری
  • راهکار صنعت مخابرات
  • راهکار صنعت رایانه و فناوری‌های وابسته
  • گواهینامه‌های بین‌المللی پشتیبانی از ITIL
  • کارکردهای نرم‌افزار در حوزه ESM و ITSM

ارتباط با ما

  • نشانی: تهران، خیابان سهروردی، خیابان خرمشهر، خیابان عربعلی، کوچه دوم، پلاک ۲۱، واحد ۴
  • تلفن: ۸۸۵۰۱۳۵۷
  • فکس: ۸۸۵۰۱۳۵۸
  • پست الکترونیک: info[at]parand.ir
ارائه‌دهنده راهکارهای مدیریتی مبتنی بر ITIL

ایده شکل‌گیری «گروه فناوری پرند» با گردهم آمدن افکاری جوان و متخصص در حوزه فناوری اطلاعات و با هدف ارائه راهکارهای نوین مدیریت فناوری اطلاعات، پرورش یافت. و در مرداد ماه ۱۳۸۴، با کسب مجوز از شورای عالی انفورماتیک، گروه فناوری پرند تأسیس شد. و به عضویت سازمان نظام صنفی رایانه‌ای درآمد. بهبود فرآیندهای مدیریت فناوری اطلاعات در کشور، از اولین اهدافی بود که با پیوست جوانان متخصص به این گروه، پیگیری شد. و همکاری با سازمان‌هایی نظیر مرکز داده سامانه هوشمند سوخت، بانک انصار، بیمه سامان، شرکت توزیع برق مشهد، شرکت برق منطقه‌ای تهران و... از دستاوردهای دهه اول فعالیت بود.
در دهه دوم فعالیت با تمرکز فعالیت‌های شرکت بر راهکارهای مدیریتی مبتنی بر ITIL و ارائه راهکاری بومی‌سازی شده و مبتنی بر استانداردهای جهانی، منجر شد تا همکاری با سازمان‌هایی نظیر بانک ملی ایران، بانک ملت، بانک مسکن، بانک آینده، سازمان برنامه و بودجه کشور، شرکت خدمات انفورماتیک، شرکت توسن تکنو، شرکت بهسازان ملت، شرکت مخابرات ایران، شرکت به پرداخت ملت و... نیز به افتخارات گروه فناوری پرند افزوده شود.

  • حقوق محتوای تمام صفحات (متون، تصاویر، فایل‌های ویدئویی) محفوظ است و کپی‌برداری از آنها بدون ذکر نام «گروه فناوری پرند» مجاز نیست.
بالا