برای ایجاد یک راه حل مؤثر، باید بدانید که چه کاری باید انجام شود و به طور مهم، چه موقع باید این کار را انجام دهید. بنابراین یک راه حل باید چند بخش داشته باشد.
- اطلاع رسانی کنید.
حل مشکلات معمولا زمانبر هستند و تا حل آن باید کاری کرد که از سرازیر شدن سیل شکایات جلوگیری کرد اطلاع رسانی و یا راهکار موقت پیشنهادی به کاربر معمولا بهترین روش برای جلوگیری از افزایش ترافیک درخواست های ناخواسته است! اطلاع رسانی باعث می شود فرصت و زمان کافی برای رسیدگی و تمرکز بر حل مشکلات را بدست بیاورید.
- تست عملیاتی انجام دهید.
یک یا چند راه حل تستی ایجاد و از آن برای یک حادثه جدید استفاده کنید تا ببینید آیا با این موارد مسئله حادث شده حل می شود یا خیر؟ آیا این مسئله با مشکل خاصی مطابقت دارد آیا قبلاً برای آن مشکل ایجاد شده یا خیر. این امر خیلی ضروری است تا بتوانید تشخیص دهید که آیا تست ها و راه حلهای شما واقعاً در این مورد خاص مفید خواهد بود یا خیر. اگر می توانید تست ها را خودکار کنید که عالی است، در غیر این صورت باید اطمینان حاصل کنید که کارکنان سرویس دسک دقیقاً می دانند که هنگام وقوع این حوادث چه چیزی را جستجو کنند.
- نرمال سازی کنید.
این توصیف کاملی از مراحل مورد نیاز برای بهبودی
از حادثه در هنگام وقوع است. باز هم، اگر راه حل شما سبب حل مسئله می شود می
توانید آنرا بعنوان یک عملکرد بهبودی و نرمال سازی در نظر بگیرید بنابراین فرایند
نرمال سازی را سعی کنید بطور خودکار انجام گیرد که واقعاً عالی می شود اما اگر به
مراحل دستی نیاز دارد لازم است که اطمینان
حاصل کنید که کارکنان سرویس دسک مراحل را درک کرده و قادر به اجرای آنها هستند.
هر بار که از راه حل استفاده می شود، باید به کارکنان سرویس دسک فرصتی داده شود تا بازخورد خود را در مورد چگونگی عملکرد تست ها و چگونگی عملکرد بهبودی ارائه دهد. اگر هیچ یک از این موارد به خوبی کار نکند، شما باید افراد فنی خود را مجبور به تحقیق در مورد مشکل کنید تا در مدت طولانی بهبود کار حاصل شود تا پاسخگوی نیاز کاربران باشید.
گام سوم: دنبال مقصر نباشید!
همچنان که هر مشکلی علتی دارد پس در نتیجه مقصری هم پشت این علت هست اما بجای مقصریابی تمرکز خود را بر روی فرصتهای بهبود بگذارید نه بازخواست و سرزنش این و آن. بی تردید جملاتی نظیر اینها را به وفور شنیده اید:" سازمان، بها نمی دهد، مدیر ارشد سیاست های ما را نادیده می گیرند، مدیر انفورماتیک زورش به مدیران دیگر نمی رسد، انفورماتیک همیشه مظلوم است، همکاران همراهی نمیکند، کاربران بی سواد هستند، فلان سرپرست باعث چنین پیامدی شده، اگر فلان مدیر نبود این اتفاق نمی افتاد، همه این اتفاقات مال تصمیمات مدیرقبلی است، روالهای واحد امنیت احمقانه و دست و پاگیر هستند و.. " اینها نمونه هایی از صدها چیزی است که ما در سازمان اغلب برای انداختن تقصیر به گردن دیگران از آنها استفاده می کنیم اما به واقع در مدیریت مشکل، مقصر جلوه دادن دیگران هیچ کمکی جز اتلاف وقت نمی کند.
وقتی مشکلی را تجزیه و تحلیل می کنید، واقعاً مهم است که به تمام اطلاعات موجود در مورد هرگونه حوادث مرتبط با مشکل دسترسی داشته باشید. اگر مشکل مربوط به یک حادثه بزرگ باشد که تأثیر بسزایی در سازمان داشته باشد، ممکن است ناشی از تصمیم و یا اقدام فلان شخص باشد اما فهم این موضوع هیچ کمکی به حل مشکل نمی کند.
اگر نادانی سنگی به چاه افکنده عاقل نباید به دنبال آن نادان بگردد تا تقصیر را به گردنش بیندازد و او را تفهیم کند، مشکل فعلی درآوردن سنگ از چاه است که یک عاقل باید بتواند آنرا دربیاورد!
مردم از اینکه در هر حادثه ای مقصر نشان داده شوند بیزارند و اگر انگشت اتهام را به سمت آنها نشانه روید چیزی جز انکار در بهترین حالت نصیبتان نخواهد شد بی شک می دانید که همیشه دیوار حاشا بلند است! اینکه بفهمید که مقصر حادثه کیست پس در نتیجه می توان فهمید که دقیقاً چه اتفاقی افتاده است، ذهنیت غلطی است، زیرا هیچ کسی تمایلی به افشای چیزهایی ندارد که آنها را به شکلی منفی نشان می دهد. به همین دلیل نگه داشتن "گذشتهای بی شرمانه" پس از وقایع مهم، بسیار مهم است تا افراد هرگز علناً آنچه را که اتفاق افتاده است به اشتراک نگذارند و یا تاریخ نگاری غلطی ارایه کنند که خلاف واقع است. باید جوی ارایه کرد که افراد براحتی تصمیمات و اقداماتشان را جدای از غلط یا درست بودن و به دور از هرگونه سرزنشی مطرح کنند.
مقصر جلوه دادن یک فرد در بروز یک مشکل ساده ترین کاری است که می توان کرد اما اگر سازمانی به این مفهوم مبنی بر اینکه مشکلات یک "علت اصلی" ندارند بلکه همیشه علل مختلفی وجود دارد. بهتر با آن برخورد خواهند. در نظر گرفتن علل بیشتر باعث می شود تا دلایل کمک کننده ی بیشتری هم برای تجزیه و تحلیل بهتر مشکلات داشته باشیم.
مثلا: در همان مثال فوق (عدم ورود کاربران به نرم افزار شکایات مشتری در مرورگر فایرفاکس) تجزیه و تحلیل این حادثه ممکن است دلایل کمک کننده زیر را نشان دهد.
- تنظیمات امنیتی فایرفاکس سبب عدم ورود کاربران به نرم افزار می شود.
- کاربران در مرورگرهای دیگر چنین مشکلی را ندارند.
- نرم افزار مورد نظر با تمامی مرورگرها سازگار نیست.
- تست وقوع چنین خطای قبلا توسط تولیدکننده در نرم افزار کشف نشده است
- مرورگر کاربران آپدیت نیست.
- نگهداری تنظیمات امنیتی برای سازمان حیاتی است و نمی توان آنها را غیرفعال کرد
- پشتیبانی فنی افرادی که این حادثه را تحلیل می کردند، به ابزارهای صحیحی دسترسی نداشتند تا به آنها در درک ماهیت خرابی و یا رفع آن کمک کنند.
در هر کدام از موارد فوق یک مقصر وجود دارد و آسان ترین نتیجه گیری از تجزیه و تحلیل بالا، این است که برنامه نویس نرم افزار را سرزنش کنید، زیرا اوست که نرم افزاری تولید نکرده که با تمام تنظیمات امنیتی همراه باشد حتی اگر مروگر آپدیت نباشد! بنابراین بجای مقصریابی می توانید خیلی منصفانه بگویید که رفع این مشکل نیاز به اصلاح کد دارد که به طور صحیح با تمامی مرورگرها همگام سازی شود. این بیان، فرصت های بسیاری برای بهبود به همراه خواهد آورد.
ادامه مطلب در صفحه بعد…
[…] مطلب مرتبط: چرا مدیریت مشکل، مشکل است؟ […]
[…] چرا مدیریت مشکل، مشکل است؟ […]
[…] چرا مدیریت مشکل، مشکل است؟ […]