راهکارهای اجرای صحیح و بهبود مدیریت مشکل
خیلی از سازمان ها و کسب و کارها به تعداد نیروهای پشتیبانی می نازند و خیلی ها به تعداد پاسخ هایی که به کاربر/مشتری ارایه میدهند، برخی شاخص های عملکرد را بر اساس تعداد و حجم درخواست ها و ظرفیت و گنجایش هر کارشناس واحد انفورماتیک می دانند و برخی سرعت در پاسخ به خرابی ها را در کارنامه خود در بوق و کرنا می دمند، اینکه بسیاری از سازمانها در مدیریت حوادث بسیار خوب عمل میکنند، خبر خوبی است اما نه همیشه! مشکل اینجاست که افراد آنقدر مشغول برخورد با حوادث روزمره می شوند که وقت لازم را برای جلوگیری و ایستادن جلوی وقوع چنین حوادثی را ندارند.
درست متوجه شدید حلقه ای از زنجیره ارزش خدمات اینجا مفقود است! و آن مدیریت مشکل است!
اغلب سازمان هایی که من با آنها کار کرده ام، تلاش میکنند تا کمی مدیریت مشکل را امتحان کنند. اما در میانه راه از تلاش باز می مانند و اغلب کل فعالیت مدیریتی خود را به انجام چند کار معمول برای یافتن علت اصلی بروز حوادث بزرگ محدود می کنند و بیشتر تمایل دارند سریع قال قضیه را بکنند و اثرات محدود آن مشکل را کاهش بدهند. پس با حل و فصل حوادث و رفع مقطعی، شاید بظاهر کار مطلوبی کرده اند اما در کل این رویکرد در مدیریت مشکل هیچ ارزش بلند مدتی برای سازمان خلق نمی کند مهمترین دلیل این ناامیدی را ترافیک شدید کار و عدم همراهی مدیریت و سایر همکاران می دانند!
اگر حمایت مدیریت ارشد پشت اجرای صحیح فرایندهای ITIL باشد با یک فرآیند مدیریت خوب مشکل می توان تعداد خرابی سرویس های ارایه شده به مشتریان را به شدت کاهش داد و این مهم باعث می شود تا راهکارهایی را پیش از وقوع حوادث ارایه کرد و با محدود کردن تأثیر خرابی ها در زمان وقوع، ارزش عظیمی را برای سازمان رقم زد. اما این تمام ماجرا نیست در بحث مفصل زیر خواهید دانست که واقعا:
برای شروع و درک بهتر موضوع تصور کنید که مشتری شما چگونه به مکالمه زیر واکنش نشان می دهد.
تعداد خرابی ها و حل و فصل سریع آن نه تنها هیچ ارزشی برای شما و مشتری خلق نمی کند بلکه سبب اتلاف هزاران ساعت زمان ارزشمند می شود. این سخت کوشی شما را می رساند نه هوشمندی شما را!
کافیست تصور کنید اگر یک مشکل مثلا کندی سرور نرم افزار حسابداری هر روز منجر به تولید ۱۰ حادثه اعم از عدم ورود به نرم افزار، عدم تولید گزارشات مالی، عدم امکان چاپ اسناد و… شود و اگر برای رفع دائم آن هیچ کاری جدی انجام نشود تکرار این ۱۰ حادثه را در ۳۵۶ روز هر سال به عناوین محتلف مشاهده خواهید کرد! و این یعنی فاجعه در ارایه خدمت!
مدیریت مشکل، همان کارکردن هوشمندی شماست که ضروری تر، مهمتر و ارزشمندتر از مدیریت حادثه است، اما نه به تنهایی!
انفورماتیک سازمان ها، منابع زیادی را در مدیریت حوادث سرمایه گذاری می کنند. اما غافلند هرچه در مدیریت حادثه نیز خوب باشند، مدیریت موفقیت آمیز حادثه به تنهایی هرگز نمی تواند برای مشتریان شما کافی باشد.
هنگامی که یک خدمت ارایه میکنید هر حادثه ای که در ارتباط با آن رخ می دهد تأثیر منفی در کسب و کار سازمان دارد، بنابراین فرقی نمی کند که چقدر سریع آن را برطرف میکنید. زیرا حتی اگر واقعاً خیلی سریع حوادث را برطرف کنید، اهمیت زیادی ندارد شاید فقط آنها فکر کنند که چه پشتیبانی سریعی دارید! اما اگر در وهله اول هیچ حادثه ای اتفاق نیفتد، چیزی که خواهند گفت این است که چه سرویس کامل و بی نقصی! مدیریت حوادث و مدیریت مشکل مکمل هم اند، پیشگیری از وقوع حوادث، سرعت رسیدگی در صورت وقوع و جلوگیری از تکرار دوباره یک چرخه صحیح است که به باور همه می فهماند که فناوری اطلاعات سازمان یک نظام مهندسی شده در ارایه خدمت در پیش گرفته و مشتریان هنوز هم آن را ترجیح می دهند.
شما باید خوب بدانید که آنچه مشتریان شما در نهایت به نحوه ارایه خدمت و فرایند پشتیبانی شما نمره می دهند، حل و فصل حوادث نیست. آنچه آنها برای آنها ارزش قائل هستند، توانایی انجام کارهایشان است بدون اینکه تحت تأثیر حوادث قرار بگیرند و این همان جایی است که مدیریت مشکل وارد می شود.
مدیریت مشکل دارای دو هدف اصلی است:
مدیریت مشکل تجربه کاربر/مشتری را بهبود خواهد داد و علاوه بر کاهش هزینه های برای تجارت با او، سطح دسترسی به خدمات و در نهایت رضایت او را افزایش خواهد داد و نیل به این اهداف مقوله شعارگونه نیست مدیریت مشکل منجر به کاهش عمده تأثیر حوادث بر کسب و کار و در نتیجه کاهش تعداد حوادث و همچنین بهبود توانایی در رسیدگی به حوادث آینده را بهمراه خواهد آورد بنابراین ارائه دهنده خدمات نیازی به کنترل حجم عظیمی از حوادث ورودی و تلاش برای بستن و رسیدگی به آنها نخواهد داشت. همین امر یعنی کاهش هزینه IT که خود منجر به آزاد سازی افراد فنی متخصص می شود که هم اکنون از آنها میتوان بر فعالیت های پیشرو و ارایه راهکارها و پروژه های جدید متمرکز کرد و این یعنی یک بازی سراسر بُرد! زیرا هم مشتری برنده است، هم فناوری اطلاعات سازمان و هم سرمایه های انسانی!
مدیریت مشکل هرگز نمی تواند تمام حوادث را از بین ببرد، اما در صورت سرمایه گذاری زمان و تلاش لازم می تواند تفاوت بسیار بزرگی ایجاد کند. این یکی از مهمترین حوزه های مدیریت خدمات فناوری اطلاعات است که در آن یک سود حاصل از این سرمایه گذاری اولیه در درازمدت عاید همگان خواهد شد.
که البته من به شخصه اینها را دلیل نمی دانم بلکه تماما بهانه هایی است برای عدم رعایت و انجام درست و صحیح کار قلمداد می کنم تا به نوعی از زیر بار انجام صحیح کار شانه خالی کنیم در ادامه به بررسی گامهایی برای مدیریت مشکل و انجام صحیح کارها می پردازم:
اولین قدم به سمت مدیریت مشکل، بسیار ساده است. مرجع داده ای خوبی ایجاد کنید. اگر مشکلات را وارد (ثبت) نکنید، دیگر نمی توانید آنها را مدیریت کنید. با ثبت مشکلات ولو اینکه کاری روی آنها هم انجام نداده باشید در هر حالت، سبب بهره مندی سازمان از یک بانک مشکل خواهد شد، بانک مشکل، محل ذخیره سازی مسائلی است که شما تشخصی داده اید که حوادث قبلی، فعلی و آتی ناشی از وجود آنهاست این یعنی شما مشکلات را نادیده نگرفته اید، وجود آنها را انکار نکرده اید و این یعنی شما دارای ذهنی تحلیلگر هستید و مشکلات را توانسته اید بخوبی شناسایی کنید و این چیز کمی نیست!
هدف غایی ما بهبود مستمر خدمات در فناوری اطلاعات است این یعنی:
پس باید:
برای هر حوادث بزرگی! که رخ می دهد، مشکلی را وارد کنید. دقت کنید حوادث بزرگ لزوما به معنای تعداد آنها نیست گاهی یک حادثه به اندازه صدها حادثه دیگر بر کسب و کار سازمان تاثیرگذار است. بنابراین اثرگذاری و دامنه افراد و سرویسهای متاثر از حوادث می تواند نمایانگر گستردگی و بزرگی آن حادثه باشد.
تعریف مشکلات در فناوری اطلاعات باعث می شود تا در آینده بتوانید آنها را کنترل و در نهایت وضعیت را بهبود دهید. از این ثبت مشکلات برای بررسی آنچه اتفاق افتاده استفاده نمایید
اطمینان حاصل کنید که همه چیز را بخوبی تعریف میکنید این تعریف مشکل می تواند براساس دایره تاثیر آن، برای عدم تکرار آن و یا برای از بین بردن حس بد آن باشد، حتی اگر ظاهراً ناچیز به نظر برسد بنابراین مشکلات را ثبت کنید.
خیلی ها باور دارند که “مشکل” هست اما آنرا ثبت نمی کنند، این به خودی خود کمکی به ما نمی کند ثبت مشکل یعنی درک و اشراف شما بر معایب قبل، هنگام و بعد از ارایه یک خدمت.
ثبت مشکل فقط طرح موضوع نیست یک مشکل باید طبق بر اساس سک تمرین صحیح ثبت شود، که مهمترین آنها: عنوان مشکل، اولویت مشکل، تاثیرگذاری آن، حوادث ناشی از وجود این مشکل است.
قرار نیست همین که وارد سیستم شدید هر روز نسبت به مشکلاتی که ثبت کردید بخواهید تا همه آنها را بررسی و حل کنید. میزان تلاشی که برای یک مشکل اختصاص داده اید بستگی به اولویت بندی آن دارد. در این گام، حل مشکل مد نظر نیست بلکه شناسایی و ثبت آن اهمیت دارد اما ثبت اطلاعات نادرست و غیرواقعی هم کمک شایانی نخواهد کرد بی شک می دانید وقتی مشکلات خود را ثبت می کنید، می توانید آنرا با حوادث قبلی و حتی حوادث جدید مطابقت و مرتبط کنید. این به شما امکان می دهد تا برای هر مشکلی که شناسایی می کنید بفهمید که مشکل مربوط به چه حوادثی است و چه تاثیری بهمراه دارد. این داده ها به شما کمک خواهد کرد تا مشکلات خود را به درستی اولویت بندی کنید، به این ترتیب می توانید کار مدیریت مشکل خود را بطور حرفه ای و بر اساس تحقیق و حل مشکلاتی که بیشترین تأثیر را بر روی کسب و کار دارند را آغاز کنید.
برای آنکه بدرستی میزان اولویت یک مشکل را در هنگام ثبت آن مشخص کنید بدانید که رتبه اولویت برای یک مشکل باید به این موارد بستگی داشته باشد:
بسیاری از سازمان ها هرماه گزارشی تحت عنوان”۱۰ مشکل مهم” را تهیه می کنند و مشکلاتی را که می خواهند روی آنها تمرکز کنند را مشخص می کنند. این یعنی اهمیت مشکلات بر اساس اولویت تعیین شده در موارد بالاست که کمک می کند تا ماهانه و یا طبق بازه های زمانی دلخواه یک لیست مشخص و معین از مشکلات اثرگذار و کلیدی را بررسی و رفع رجوع نمایید.
من به یکی از مدیران انفورماتیک یک سازمانی که من با او کار می کردم و بسیار پیگیر مدیریت بهینه فرایندها بود روشی را پیشنهاد دادم که با استقبال شدید او مواجه شد و آن اینکه: “هر حادثه، با یک مشکل یا یک خطای شناخته شده همراه است! بنابراین طوری کارشناسان فناوری میزخدمت را باید آموزش داد که بتوانند حوادث جدید را با مشکلات موجود و خطاهای شناخته شده مطابقت دهند و هرگاه لازم شد مشکل جدید را وارد کنند. این تضمین می کند که تأثیر هر مشکل به خوبی درک شده و دسترسی به سطح بسیار بالایی از داده های باکیفیت را برای داده کاوی و ارایه راهکارهای مناسب، سهیل می شود!
هر سازمانی برای رسیدن به چنین رویکردی و اجرای این روش، باید سطح بالایی از بلوغ فرآیند را داشته باشد و این سیاست برای هر فناوری هر سازمانی مناسب نیست!
بله قبول دارم که هر مشکلی علت ریشه ای خاصی دارد و یافت علت ریشه ای سبب حل و فصل سریع آن می شود، اما علل ریشه ای چیزی نیست که تمرکز خود را روی آن بگذارید! بسیاری از مردم فکر می کنند که هدف از مدیریت مشکل فقط یافتن علت اصلی آنهاست. پیدا کردن دلیل اصلی یک مشکل هیچ ارزشی برای شما یا مشتریان شما خلق نخواهد کرد، یافت علت ریشه مشکلات فقط آگاهی و درک ما را از منشا وقوع و سرچشمه مشکلات افزایش می دهد، کاری اصلی ما در مدیریت مشکل یک هدف واقعی است و آن از بین بردن مشکل یا کاهش تأثیر آن است.
به این موضوع فکر کنید شما الان سرما خورده اید، آیا اهمیت دارد که اکنون و فقط اکنون چرا سرما خورده اید!؟ اینکه شب جلوی کولر خوابیده اید، یا با دوستتان رو بوسی کرده اید و یا پس از دوش گرفتن، سریع بیرون رفته اید کمکی به بهبود و سلامتی شما نخواهد کرد، تنها چیزی الان مهم است بهبودی سلامت جسمی شماست باید سریعا دنبال پزشک باشید تا با قرص و آمپول شما را درمان کند.
در ماجرایی، من درگیر کمک به حل و فصل تعدادی از حوادث بزرگ شده بودم جایی که افراد فنی هفته ها در تلاش بودند تا علت اصلی یکی از مشکلات پیچیده را درک کنند، این تلاش تا آنجا پیش رفت که هر بار که کاربری را می دیدم از اینکه فناوری اطلاعات نمی فهمد مشکل چیست و چرا برای آن کاری نمی کند به شدت گله مند بود و از عملکرد آنها ناامید شده بودند و آن این بود که کاربران در مروگر فایرفاکس که مروگر سازمانی آنجا بود قادر به ورود به “نرم افزار شکایات مشتری” نبودند! و هر بار که آنها مرورگر را باز میکردند با این موضوع مواجه و بلافاصله یک تیکت ثبت می کردند!
پاسخ کارکنان فناوری اطلاعات و فروشنده نرم افزار هم به آنها این بود:”متاسفانه علت این مشکل در دست بررسی است و در حال یافتن علت وقوع آن هستیم از شکیبایی شما سپاسگزاریم.” اما همین موضوع نارضایتی و ناراحتی بسیار زیادی بوجود آورده بود از طرفی تلاش کارکنان فناوری برای ریشه یابی علل وقع این مسئله زمان زیادی داشت از آنها می گرفت.
به کارکنان فناوری اطلاعات پیشنهاداتی دادم بعنوان راه حل موقت برای جلوگیری از افزایش درخواست های مشابه :
و چند راهکار دائمی که قویا منجر به تغییر هم می شد:
یکی از راه های بسیار مؤثر برای کمک به این سازمان ها برای پیشرفت، این بود که افراد برتر فنی بتوانند روی ابداع و مستند سازی یک راه حل خوب تمرکز کنند و تنها پس از عملی شدن این کار، به تحلیل های خود برگردند. در یکی از پروژه ها، ما فقط با ابداع یک راه حل مؤثر، توانستیم بیش از ۹۷٪ خرابی ناشی از یک مشکل مکرر را کاهش دهیم. این امر نه تنها هزینه را برای کسب و کار کاهش داد بلکه فشار ترافیک و استرس عصبی واحد فناوری اطلاعات را نیز از بین برد و به آنها این امکان را داد تا رویکرد آرامتری را برای تحلیل مسئله انجام دهند زیرا دیگر نیازی به مقابله با جریان شکایات مکرر و رشد تیکت های تکراری نبودند.
به این فکر نکنید که چه شد از کار افتاد!؟ به این بیندیشید که چه باید بکنید تا کار کند و چکار باید کرد تا مجدد از کار نیفتد!
برای ایجاد یک راه حل مؤثر، باید بدانید که چه کاری باید انجام شود و به طور مهم، چه موقع باید این کار را انجام دهید. بنابراین یک راه حل باید چند بخش داشته باشد.
حل مشکلات معمولا زمانبر هستند و تا حل آن باید کاری کرد که از سرازیر شدن سیل شکایات جلوگیری کرد اطلاع رسانی و یا راهکار موقت پیشنهادی به کاربر معمولا بهترین روش برای جلوگیری از افزایش ترافیک درخواست های ناخواسته است! اطلاع رسانی باعث می شود فرصت و زمان کافی برای رسیدگی و تمرکز بر حل مشکلات را بدست بیاورید.
یک یا چند راه حل تستی ایجاد و از آن برای یک حادثه جدید استفاده کنید تا ببینید آیا با این موارد مسئله حادث شده حل می شود یا خیر؟ آیا این مسئله با مشکل خاصی مطابقت دارد آیا قبلاً برای آن مشکل ایجاد شده یا خیر. این امر خیلی ضروری است تا بتوانید تشخیص دهید که آیا تست ها و راه حلهای شما واقعاً در این مورد خاص مفید خواهد بود یا خیر. اگر می توانید تست ها را خودکار کنید که عالی است، در غیر این صورت باید اطمینان حاصل کنید که کارکنان سرویس دسک دقیقاً می دانند که هنگام وقوع این حوادث چه چیزی را جستجو کنند.
هر بار که از راه حل استفاده می شود، باید به کارکنان سرویس دسک فرصتی داده شود تا بازخورد خود را در مورد چگونگی عملکرد تست ها و چگونگی عملکرد بهبودی ارائه دهد. اگر هیچ یک از این موارد به خوبی کار نکند، شما باید افراد فنی خود را مجبور به تحقیق در مورد مشکل کنید تا در مدت طولانی بهبود کار حاصل شود تا پاسخگوی نیاز کاربران باشید.
همچنان که هر مشکلی علتی دارد پس در نتیجه مقصری هم پشت این علت هست اما بجای مقصریابی تمرکز خود را بر روی فرصتهای بهبود بگذارید نه بازخواست و سرزنش این و آن. بی تردید جملاتی نظیر اینها را به وفور شنیده اید:” سازمان، بها نمی دهد، مدیر ارشد سیاست های ما را نادیده می گیرند، مدیر انفورماتیک زورش به مدیران دیگر نمی رسد، انفورماتیک همیشه مظلوم است، همکاران همراهی نمیکند، کاربران بی سواد هستند، فلان سرپرست باعث چنین پیامدی شده، اگر فلان مدیر نبود این اتفاق نمی افتاد، همه این اتفاقات مال تصمیمات مدیرقبلی است، روالهای واحد امنیت احمقانه و دست و پاگیر هستند و.. ” اینها نمونه هایی از صدها چیزی است که ما در سازمان اغلب برای انداختن تقصیر به گردن دیگران از آنها استفاده می کنیم اما به واقع در مدیریت مشکل، مقصر جلوه دادن دیگران هیچ کمکی جز اتلاف وقت نمی کند.
وقتی مشکلی را تجزیه و تحلیل می کنید، واقعاً مهم است که به تمام اطلاعات موجود در مورد هرگونه حوادث مرتبط با مشکل دسترسی داشته باشید. اگر مشکل مربوط به یک حادثه بزرگ باشد که تأثیر بسزایی در سازمان داشته باشد، ممکن است ناشی از تصمیم و یا اقدام فلان شخص باشد اما فهم این موضوع هیچ کمکی به حل مشکل نمی کند.
اگر نادانی سنگی به چاه افکنده عاقل نباید به دنبال آن نادان بگردد تا تقصیر را به گردنش بیندازد و او را تفهیم کند، مشکل فعلی درآوردن سنگ از چاه است که یک عاقل باید بتواند آنرا دربیاورد!
مردم از اینکه در هر حادثه ای مقصر نشان داده شوند بیزارند و اگر انگشت اتهام را به سمت آنها نشانه روید چیزی جز انکار در بهترین حالت نصیبتان نخواهد شد بی شک می دانید که همیشه دیوار حاشا بلند است! اینکه بفهمید که مقصر حادثه کیست پس در نتیجه می توان فهمید که دقیقاً چه اتفاقی افتاده است، ذهنیت غلطی است، زیرا هیچ کسی تمایلی به افشای چیزهایی ندارد که آنها را به شکلی منفی نشان می دهد. به همین دلیل نگه داشتن “گذشتهای بی شرمانه” پس از وقایع مهم، بسیار مهم است تا افراد هرگز علناً آنچه را که اتفاق افتاده است به اشتراک نگذارند و یا تاریخ نگاری غلطی ارایه کنند که خلاف واقع است. باید جوی ارایه کرد که افراد براحتی تصمیمات و اقداماتشان را جدای از غلط یا درست بودن و به دور از هرگونه سرزنشی مطرح کنند.
مقصر جلوه دادن یک فرد در بروز یک مشکل ساده ترین کاری است که می توان کرد اما اگر سازمانی به این مفهوم مبنی بر اینکه مشکلات یک “علت اصلی” ندارند بلکه همیشه علل مختلفی وجود دارد. بهتر با آن برخورد خواهند. در نظر گرفتن علل بیشتر باعث می شود تا دلایل کمک کننده ی بیشتری هم برای تجزیه و تحلیل بهتر مشکلات داشته باشیم.
مثلا: در همان مثال فوق (عدم ورود کاربران به نرم افزار شکایات مشتری در مرورگر فایرفاکس) تجزیه و تحلیل این حادثه ممکن است دلایل کمک کننده زیر را نشان دهد.
در هر کدام از موارد فوق یک مقصر وجود دارد و آسان ترین نتیجه گیری از تجزیه و تحلیل بالا، این است که برنامه نویس نرم افزار را سرزنش کنید، زیرا اوست که نرم افزاری تولید نکرده که با تمام تنظیمات امنیتی همراه باشد حتی اگر مروگر آپدیت نباشد! بنابراین بجای مقصریابی می توانید خیلی منصفانه بگویید که رفع این مشکل نیاز به اصلاح کد دارد که به طور صحیح با تمامی مرورگرها همگام سازی شود. این بیان، فرصت های بسیاری برای بهبود به همراه خواهد آورد.
داشتن کادر فنی متخصص، افراد توانمند با سطح سواد بالا، تجربه بیشتر و یا مدرک دانشگاهی آنها مفهوم تحلیلگر را به ما نشان نمی دهد و لزوما این افرد بخوبی قادر به تجزیه و تحلیل مشکلات نخواهد شد، تحلیلگر بودن مشکلات، خود یک تخصص ویژه است اما احتمالاً افرادی را می شناسید که بدون تخصص بالایی در استفاده از فناوری مناسب بسیار حرفه ای هستند، اغلب این افراد برای تجزیه و تحلیل مشکلات، از فناوری ها و ابزارهای کمک کننده ای که تولید شده استفاده میکنند که کمک بسزایی می کند تا یاد بگیرند که چگونه مشکلات را تحلیل کنند. این مهارت ذاتی نیست که افراد خود به خود به آن دست پیدا کرده باشند، تحلیل مشکل، یک مهارت اکتسابی و قابل یادگیری است اگرچه دستیابی به آن نیاز به تلاش دارد.
دوره های آموزشی در برخی از تکنیک های تحلیل وجود دارد، اما احتمالاً مهمترین کاری که می توانید انجام دهید این است که فرصت هایی را برای افراد فراهم می کند که بتوانند از آنها راهنمایی بگیرند. از کارمندان ارشد خود مطلع شوید تا کارمندان جوان را با جنبه های کارشان درگیر کنند. این امر می تواند به کارمندان ارشد کمک کند ، و همچنین با مشاهده چگونگی دست شخص با تجربه بیشتر ، می تواند با رعایت اینکه دست اول با تجربه بیشتر در مورد تجزیه و تحلیل مشکلات پیچیده است ، مهارت خود را توسعه دهند. فرصتی را برای افراد فراهم کنید تا در صورت نیاز به کمک به تجزیه و تحلیل مشکل ، دسترسی پیدا کنند ، ممکن است برخی از کارهای تحلیل مشکل را بعد از اتمام آن بررسی کنید تا ببینید که آیا فرصت های یادگیری برای افراد درگیر وجود دارد یا خیر. اگر در حال حاضر به دلیل کمبود مهارت یا منابع خود مدیریت زیادی را انجام نمی دهید ، ممکن است ایده خوبی باشد که برای مشاوره گرفتن تا برخی از کارهای اولیه مدیریت مشکل را انجام داده و به افراد خود راهنمایی کنید تا بتوانند به عنوان مشکل بر سر کار بیایند.
تکنیک های مختلف زیادی برای تجزیه و تحلیل مشکل وجود دارد که می توانید به کمک آنها به تحلیل مسائل پرداخت نظیر: Timeline Analysis و Kepner-Tregoe Problem Solutions وBrainstorming ، Fault Tree Analysis یا نمودار استخوان ماهی ایشیکاوا که بی شک قدرت تفکر شما را در حل مسائل تقویت میکند.
مانند بسیاری از حوزه های دیگر مدیریت خدمات فناوری اطلاعات، مدیریت موثر مشکل شدیدا به نگرش، رفتار و فرهنگ افراد وابسته است. اگر افرادی با مهارت های خوب دارید که واقعاً به مدیریت مشکل اهمیت می دهند، احتمالاً کار را به نحو احسن انجام خواهید داد. مطمئناً اجرای یک فرایند رسمی می تواند کمک کند، اما جود نگرش، رفتار و فرهنگ افراد بسیار مهمتر است. لذا برای تغییر نگرش، انجام رفتار صحیح و اصلاح فرهنگ افراد باید معیارهایی را در مدیریت مشکل تدوین و بر اساس آن اندازه گیری کنیم. کسب و کار شامل: کارکنان، مشتریان و خدمات و محصولات است. باید بخوبی درک کرد که یک مشکل در کسب و کار چه تاثیری میگذارد؟ دامنه و شدت آن چقدر گسترده است و آیا معیاری برای سنجش آن هست!؟
معیارها و اندازه گیری در مدیریت مشکل برای چندین هدف قابل استفاده است از جمله اینکه:
البته تاکید مجدد من بر این نکته را نادیده نگیرد هدف از اندازه گیری، بهبود است نه اعمال فشار بر کارکنان و ارایه دهندگان خدمت.
بنابراین مهم است که هنگام تعیین معیارها، درباره همه چیز بخوبی بیندیشید برخی از معیارهای مدیریت مشکل وحشتناک اند که نه تنها هیچ رهاوردی ندارد می تواند بطور اخص روی رفتار افراد تاثیر بسیار وخیم و بدی بگذارند.
یک متریک یا شاخص اندازه گیری که بسیار مورد استفاده قرار می گیرد، بر مدت زمان لازم برای شناسایی علت اصلی مشکلات تمرکز دارد. این متریک از آن شاخص های به ویژه بد است زیرا:
بنابراین چه نوع معیارهایی بجای معیار شناسایی علت ریشه مشکلات بهترند؟ در مرحله اول باید اهداف را بفهمید. اهداف معمولی برای مدیریت مشکل عبارتند از:
بنابراین برای رسیدن به اهداف فوق لازم است به طور منظم گزارشاتی را ایجاد و به نتایج و اندازه گیری های زیر نایل شوید:
مشکلات خود را همواره ثبت و درج کنید: اطمینان حاصل کنید که برای حوادث تکراری و برای حوادث مهم، مشکلات را وارد کرده اید. گزارش های مشکل “۵ یا ۱۰ مشکل برتر” را ایجاد کنید تا روی بالاترین مشکلات بااولویت توجه کنید.
روی راه حل های کار تمرکز کنید، نه دلایل اصلی بروز مشکل: هفته ها را صرف تجزیه و تحلیل دلایل اصلی مسکل صرف نکنید در حالی که کسب و کار و مشتریان در حال رنج هستند. تلاشهای اولیه را بر شناسایی حوادث مربوط به مشکل و اقدامات بهبودی متمرکز کنید.
روی فرصت های بهبود تمرکز کنید ، نه مقصر: هر مشکلی چندین دلیل مشترک دارد و نه یک دلیل اصلی. هر یک از این دلایل می تواند فرصتی برای پیشرفت داشته باشد. مردم هرگز علت اصلی یک حادثه نیستند.
با یکی از تکنیک های تجزیه و تحلیل آشنا باشید و آنرا به کارکنان فناوری آموزش دهید: افراد فنی باید یاد بگیرند که چگونه مشکلات را تحلیل کنند. این به طور خودکار با تجربه و دانش فنی آنها حاصل نمی شود لازم است فرصتهایی برای دریافت آموزش رسمی و آشنایی آنها با تکنیک ها و روشهای حل مسئله مهیا کنید تا مهارتهای آنها افزایش یابد.
معیارهای مدیریت مشکل در کسب و کار را تعریف کنید: معیارها باید رفتار مورد نیاز افرادتان را در جهت درست هدایت کند و همچنین به شما در درک چگونگی عملکرد فرآیند مشکل و برآورده کردن نیازهای تجاری کمک کند. زمان ریشه یابی یک معیار بسیار بد برای مدیریت مسئله است. مواردی را که برای مشتریان مهم است اندازه گیری کنید.
[…] مطلب مرتبط: چرا مدیریت مشکل، مشکل است؟ […]
[…] چرا مدیریت مشکل، مشکل است؟ […]
[…] چرا مدیریت مشکل، مشکل است؟ […]