هدف متخصصان سرویس دسک فناوری اطلاعات این است که تجربه‌ای فوق‌العاده را به کاربران ارائه دهند. اگرچه آنها می‌توانند با استفاده از فرایند مدیریت رخداد، رخدادها را مدیریت کرده و خدمات را در اسرع وقت بازیابی کنند، اما هدف اصلی این است که هیچ رخدادی به وجود نیاید. بنابراین، مبحث مهمی به نام مدیریت مشکل مطرح می‌شود که به متخصصان و سازمان کمک می‌کند به این هدف دست یابند.
هدف اصلی مدیریت مشکل، جلوگیری از وقوع رخدادها است و در صورت وقوع نیز مانع از جلوگیری مجدد آنها شود. آیا ممکن است که یک ارائه‌دهنده خدمات فقط به رخدادهایی که به طور مداوم تکرار می‌شوند و هرگز واقعا حل نمی‌شوند، واکنش نشان دهد؟ آیا می‌توان تصور کرد که حل و فصل رخدادهای مشابه بارها و بارها به یک کار روتین تبدیل شود؟
با گذشت زمان تعداد رخدادها افزایش می‌یابد، هزینه مدیریت رخدادها افزایش می‌یابد، رضایت مشتری و کاربر کاهش می‌یابد، اعتبار سرویس دسک آسیب می‌بیند، ابتکارات غیرمجاز IT به یک مسئله عادی تبدیل می‌شود و در نتیجه، بر توانایی کسب‌وکار برای ادامه راه تاثیر مخربی می‌گذارد.
بسیاری از سازمان‌ها به دلیل عدم استفاده از یک فرایند موثر برای مدیریت مشکل، با چالش‌های مختلفی روبرو می‌شوند. اغلب اوقات، این امر به این دلیل است که تیم‌های فناوری اطلاعات، مدیریت مشکلات را با مدیریت رخدادها اشتباه می‌گیرند و ارتباط آن را با مدیریت تغییر به‌طور کامل درک نمی‌کنند.
در حالی که این فرایندها کاملا هماهنگ با یکدیگر کار می‌کنند. در واقع هدف مدیریت مشکلات، پشتیبانی از مدیریت رخدادها است که در وهله اول با جلوگیری از وقوع رخدادها از طریق بهره‌گیری از فرایند مدیریت تغییر انجام می‌شود.
مدیریت مشکل در ITIL چیست؟
مدیریت مشکل یک فرایند مدیریت خدمات فناوری اطلاعات است که وظیفه مدیریت چرخه حیات (مشکلات) زیربنایی را برعهده دارد. موفقیت با تشخیص سریع و ارائه راه‌حل‌ها یا راه‌حل‌های جایگزین برای مشکلات به منظور به حداقل رساندن تاثیر بر سازمان و جلوگیری از تکرار آن حاصل می‌شود.
مدیریت مشکل همچنین تلاش می‌کند تا خطایی را در زیرساخت فناوری اطلاعات که باعث ایجاد مشکل شده و در بروز رخدادهایی که کاربران ممکن است تجربه کنند نقش دارد، پیدا کند. کتابخانه زیرساخت فناوری اطلاعات (ITIL) تعاریف زیر را بری استفاده در این فرایند ارائه می‌دهد:
- مشکل: «علت یک یا چند رخداد. علت معمولا در زمان ایجاد یک رکورد مشکل مشخص نیست.»
- خطا: «یک نقض یا نقص طراحی که باعث خرابی یک یا چند سرویس فناوری اطلاعات یا سایر آیتم‌های پیکربندی می‌شود.»
- خطای شناخته شده: «مشکلی که علت ریشه‌ای و راه‌حل مستند دارد.»
- علت ریشه‌ای: «علت اصلی یا زیربنایی یک رخداد یا مشکل.»
مدیریت مشکل پیشگیرانه در مقابل مدیریت مشکل واکنشی
مدیریت مشکل می‌تواند با دو رویکرد واکنشی یا پیشگیرانه انجام شود.
در رویکرد واکنشی، واکنشی برای حل مسئله هنگام بروز یک یا چند رخداد رخ می‌دهد. اما در رویکرد پیشگیرانه با شناسایی و حل مشکلات پیش از وقوع هرگونه رخداد سروکار داریم. این فعالیت با بهبود مستمر خدمات (CSI) مرتبط است.
ارزش مدیریت مشکل برای کسب‌وکار
فرایند مدیریت مشکل در ارتباط با مدیریت رخدادها و تغییرات، به شیوه‌های مختلف برای کسب‌وکار ارزش ایجاد می‌کند. هدف اصلی مدیریت مشکل، به حداقل رساندن تاثیر مشکلات بر کسب‌وکار و جلوگیری از تکرار آنهاست. در صورت موفقیت، زمان خرابی خدمات و اختلالات کاهش می‌یابد. این فرایند مزایای دیگری نیز دارد:
- افزایش دسترسی به خدمات
- بهبود کیفیت خدمات
- کاهش زمان حل مشکل
- کاهش تعداد رخدادها
- افزایش بهره‌وری
- کاهش هزینه‌ها
- بهبود رضایت مشتری
پذیرش و پیاده‌سازی فرایندها و فناوری ITIL، هرج و مرجی را که ممکن است سازمان‌های IT در چشم‌انداز به سرعت در حال تغییر کنونی تجربه کنند، به حداقل می‌رساند. اگرچه مدیریت مشکل فرایندی مستقل است، اما به یک فرایند مدیریت رخداد موثر و ابزارهای مناسب وابسته است. این ابزارها شامل یک رابط مشترک، دسترسی به دانش موجود، اطلاعات مدیریت پیکربندی و تعامل با سایر فرایندهای مرتبط ITIL می‌شود.
این امر تضمین می‌کند که مشکلات شناسایی می‌شوند، حاوی جزئیات مرتبط هستند و در اسرع وقت روی آنها کار می‌شود. ITIL روش دقیقی برای پذیرش مدیریت مشکل در اختیار سازمان‌ها قرار نمی‌دهد، بلکه یک چارچوب ساختاریافته است که باید متناسب با نیازها و محدودیت‌های هر کسب‌وکار تنظیم شود. تنظیمات منظم در این فرایندهای داخلی ITIL در نهایت از چابکی پشتیبانی می‌کند، ارزش تجاری را مشخص می‌سازد و به سازمان‌ها کمک می‌کند تا در فضای موجود در بازار خود رقابت کنند.
جریان فرایند مدیریت مشکل
مدیریت مشکل چگونه کار می‌کند؟ مدیریت مشکل در ITIL چیزی بیش از حل و فصل رخدادها است؛ این فرایند کل چرخه حیات یک مشکل را در نظر می‌گیرد. جریان فرایند چرخه حیات مدیریت مشکل می‌تواند به گونه‌ای ساختاربندی شود که مشکلاتی را که در ابتدا توسط کاربران یا تکنسین‌های سرویس دسک از طریق پورتال سلف سرویس، از طریق تلفن، ایمیل، حضوری یا مشکلات بالقوه‌ای که به‌طور خودکار توسط پرسنل ITSM پیش از وقوع هرگونه رخدادی شناسایی می‌شوند، به عنوان رخداد گزارش کند. دامنه جریان فرایند مدیریت مشکل شامل موارد زیر است:
تشخیص مشکل
مشکلات را می‌توان به روش‌های مختلفی شناسایی کرد، از جمله در نتیجه گزارش رخداد، تجزیه و تحلیل مداوم رخداد و تشخیص خودکار توسط یک ابزار مدیریت رخداد یا اطلاع‌رسانی به تامین‌کننده. یک مشکل معمولا زمانی شناسایی می‌شود که علت یک یا چند رخداد گزارش شده به سرویس دسک ناشناخته باشد.
ممکن است سرویس دسک رخداد را حل و فصل کرده باشد و ممکن است دوباره رخ دهد اما آنها از علت اصلی آن مطمئن نیستند و بنابراین یک رکورد مشکل ایجاد می‌کنند. در موارد دیگر، ممکن است برای سرویس دسک مشخص باشد که یک رخداد گزارش شده با یک مشکل مرتبط است. این مشکل ممکن است قبلا ثبت شده باشد (مشکل شناخته شده) و در این صورت می‌توان رخداد را به رکورد مشکل موجود پیوند داد. اگر مشکل ثبت نشده باشد، باید فورا یک رکورد مشکل ایجاد شود تا به تضمین عملکرد سرویس کمک کند.
ثبت مشکل
برای حفظ یک رکورد تاریخی کامل، همه مشکلات، صرف‌نظر از روشی که برای شناسایی و گزارش به سرویس دسک استفاده می‌شود، باید با تمام جزئیات مربوطه، از جمله تاریخ/زمان، اطلاعات کاربر، توضیحات، آیتم پیکربندی مرتبط از CMDB، رخدادهای مرتبط، جزئیات راه‌حل و اطلاعات خاتمه مشکل ثبت شوند.
دسته‌بندی) پس از ثبت، باید همه دسته‌های مناسب انتخاب شوند تا دفعات تکرار و روند مشکلات به درستی تعیین، تشدید و رصد شوند.
اولویت‌بندی) تعیین اولویت در تعیین نحوه و زمان رسیدگی به مشکل توسط کارکنان بسیار مهم است. این امر با تاثیر (تعداد رخدادهای مرتبط که می‌تواند بینشی در مورد تعداد کاربران تحت تاثیر یا تاثیر آن بر کسب‌وکار ارائه دهد) تعیین می‌شود. علاوه بر این، فوریت مشکل (اینکه حل و فصل آن با چه سرعتی باید انجام شود) برای تعریف اولویت در نظر گرفته می‌شود.
بررسی و تشخیص
بررسی علت ریشه‌ای مشکل براساس تاثیر، شدت و فوریت مشکل موردنظر انجام خواهد شد. تکنیک‌های رایج بررسی شامل بررسی پایگاه داده خطاهای شناخته شده (KEDB) به منظور یافتن مشکلات و راه‌حل‌های منطبق یا بازسازی مشکل برای تشخیص علت اصلی است.
راه‌حل
در برخی شرایط، می‌توان یک راه‌حل موقت یا راه‌حل جایگزین برای کاربری که با رخداد مربوط به مشکل مواجه شده است، ارائه داد. با این حال، جستجوی یک راه‌حل دائمی برای خطای اساسی شناسایی شده توسط مدیریت مشکل بسیار مهم است.
ایجاد رکورد خطای شناخته شده
پس از اتمام بررسی و تشخیص، ایجاد یک رکورد خطای شناخته شده مهم است. در صورت بروز رخدادها یا مشکلات در آینده، تکنسین سرویس دسک که وظیفه بررسی را برعهده دارد، با استفاده از پایگاه داده خطاهای شناخته شده و راه‌حل‌های مرتبط، سریع‌تر آنها را شناسایی و حل و فصل خواهد کرد.
حل مسئله
پس از حل مسئله، می‌توان راه‌حل را با استفاده از رویه استاندارد تغییر پیاده‌سازی و برای تایید بازیابی خدمات آزمایش کرد. با این حال، اگر نیاز به تغییر عادی باشد، قبل از اعمال راه‌حل برای مشکل، یک درخواست تغییر (RFC) مرتبط مطرح و تایید می‌شود.
خاتمه
پس از تایید حل و فصل شدن خطا، مشکل و هرگونه رخداد مرتبط می‌توانند بسته شوند. تکنسین سرویس دسک باید مطمئن شود که جزئیات طبقه‌بندی اولیه برای ارجاع و گزارش‌دهی در آینده دقیق هستند.
بررسی مشکل اصلی) مشکلات اصلی توسط تجزیه و تحلیل تاثیر تجاری (BIA) و ارزیابی ریسک (RA) یک سازمان تعریف می‌شوند تا پاسخ و اولویت (تاثیر، فوریت و شدت مشکل) تعیین شود.
هدف از بررسی مشکل اصلی، بهبود مستمر فرایند مدیریت مشکل برای پاسخگویی به مسائل اصلی کسب‌وکار است. یک فرایند بررسی ممکن است کارهایی را که به درستی انجام شده‌اند، کارهایی را که به اشتباه انجام شده‌اند، آنچه را که می‌توان بهبود بخشید، خطرات اضافی، نحوه جلوگیری از تکرار و ماهیت هرگونه مسئولیت شخص ثالث را شناسایی کند.
این بررسی نباید در یک محیط جداگانه باشد؛ بلکه باید به عنوان بخشی از جلسات آموزشی و آگاهی‌بخشی با اعضای تیم به اشتراک گذاشته شود.
کنترل مشکل و کنترل خطا) در برخی شرایط، اصطلاحات کنترل مشکل و کنترل خطا ممکن است در طول چرخه عمر مدیریت مشکل استفاده شوند. کنترل مشکل می‌تواند در مرحله بررسی با هدف یافتن علت اصلی مشکل و تبدیل آن به یک خطای شناخته شده گنجانده شود. این امر به تکنسین سرویس دسک کمک می‌کند تا راه‌حل‌های موقت را به کاربر ارائه دهد. از سوی دیگر، کنترل خطا بخشی از مرحله حل مسئله است که هدف آن تبدیل خطاهای شناخته شده به راه‌حل‌ها و حذف آنها از پایگاه داده خطای شناخته شده (KEDB) در صورت لزوم است.
فرایندهای مرتبط ITIL: مدیریت رخداد و تغییر
فرایندهای ITIL در طول چرخه عمر ارائه خدمات با یکدیگر در ارتباط هستند. مدیریت مشکل و مدیریت رخداد ارتباط نزدیکی با مدیریت مشکل دارند، اما یکسان نیستند. در حالی که هر دو فرایندی هستند که توسط دپارتمان فناوری اطلاعات انجام می‌شوند، اما هر کدام اهداف متفاوتی را دنبال می‌کنند. مدیریت مشکل با یافتن علت اصلی، بر پیشگیری یا به حداقل رساندن تاثیر یک یا چند رخداد تمرکز دارد.
مدیریت رخداد به دنبال حل و فصل سریع یک رخداد و بازیابی به موقع سرویس کاربران است. بازیابی سرویس در مدیریت رخداد لزوما به این معنی نیست که رخداد دوباره اتفاق نخواهد افتاد. اکثر مشکلات به عنوان واکنشی به یک یا چند رخداد ایجاد می‌شوند، اما در برخی شرایط، مشکلات زمانی ایجاد می‌شوند که تسترها در حال آزمایش سرویس یک نسخه هستند، مانند زمانی که از فرایند اعتبارسنجی و آزمایش سرویس استفاده می‌کنند یا تامین‌کنندگان در محصولات یا سرویس‌های خود نقص پیدا می‌کنند.
اگرچه عملیات سرویس برای دستیابی به ثبات تلاش می‌کند، مواردی وجود دارد که تغییر ضروری است. به همین دلیل، مدیریت تغییر نیز ارتباط نزدیکی با مدیریت مشکل دارد. تغییرات می‌توانند از قبل تایید شده یا نیاز به تایید داشته باشند. در هر دو حالت، یک RFC برای مستندسازی تغییر مورد نیاز ایجاد می‌شود. در صورت نیاز به سخت‌افزار، نرم‌افزار، فرایندها یا زیرساخت جدید، بهبودیافته یا ارتقایافته برای حل یک مشکل، اغلب در طول چرخه عمر مدیریت مشکل، درخواست تغییر (RFC) ایجاد می‌شود.
سایر روابط کلیدی فرایند ITIL:
- مدیریت پیکربندی
- مدیریت سطح خدمات
- مدیریت دسترسی
- مدیریت ظرفیت
- مدیریت رویداد
- اعتبارسنجی و آزمایش خدمات
نقش‌ها و مسئولیت‌های مدیریت مشکل
نقش‌ها و مسئولیت‌های به خوبی تعریف شده برای پیاده‌سازی موثر یک فرایند مدیریت مشکل موفق بسیار مهم هستند. تیم مدیریت مشکل از موارد زیر تشکیل شده است:
مدیر مشکل
مدیر مشکل، شخصی تعیین شده است که ممکن است مسئول سایر نقش‌های سازمانی باشد یا نباشد. این مالک فرایند مدیریت مشکل، مسئول تمام جنبه‌های هماهنگی آن، از جمله موارد زیر است:
- نقش‌آفرینی به عنوان رابط در میان پرسنل مسئول حل مشکل
- اطمینان از حل مشکلات در چارچوب SLA آنها
- مالکیت و مدیریت پایگاه داده خطاهای شناخته شده (KEDB)
- بسته شدن مشکلات
- هماهنگی بررسی مشکلات عمده
توجه: به دلیل اختلافات احتمالی در شیوه پیاده‌سازی، مدیر مشکل و مدیر رخداد نباید یک نفر باشد.
تیم حل مشکل
حل مشکلات ممکن است توسط اعضای تیم پشتیبانی فنی داخلی یا تامین‌کنندگان یا فروشندگان خارجی انجام شود. در شرایطی که یک مشکل جدی یا بزرگ رخ می‌دهد، مدیر مشکل ممکن است یک تیم مدیریت مشکل اختصاصی تشکیل دهد که از منابعی با تخصص خاص تشکیل شده باشد.
چک‌لیست ویژگی‌های نرم‌افزار مدیریت مشکل
برای سازمان‌های فناوری اطلاعات که خرید نرم‌افزار مدیریت مشکل یا مجموعه‌های مدیریت خدمات فناوری اطلاعات را که از قابلیت‌های مدیریت مشکل بهره می‌برند، ارزیابی می‌کنند، ویژگی‌های زیر برای پشتیبانی موثر از فرایندهای کلیدی، اگر نگوییم حیاتی، بسیار مهم هستند.
یک نرم‌افزار مدیریت مشکل حداقل باید مدیران را برای انجام وظایف زیر توانمند کند:
- پیکربندی فرایندهای مشکل
- پیکربندی دسته‌بندی رخدادها
- ایجاد، اصلاح، حل و فصل و بستن رکوردهای مشکل
- پیاده‌سازی ITIL یا سایر چارچوب‌های مربوط به بهروش‌های شناخته شده در صنعت به علاوه به‌روزرسانی خودکار وضعیت یا بستن تمام رخدادهای مرتبط پس از به‌روزرسانی/بستن مشکل
- پیوند مشکلات به آیتم‌های پیکربندی، رخدادها و درخواست‌های تغییر
- تعیین میزان تاثیر و فوریت برای هر مشکل
- تمایز قائل شدن بین مشکلات و خطاهای شناخته شده
- خودکارسازی یا تخصیص دستی وظایف به افراد یا تیم‌ها
- خودکارسازی ثبت داده‌های تاریخی در یک گزارش حسابرسی
- ایجاد شماره رکورد منحصربه‌فرد مرتبط با هر رکورد مشکل
- ادغام با مدیریت رخداد، تغییر، پیکربندی و دانش
- خودکارسازی ایجاد مشکل براساس قوانین کسب‌وکار و SLAها
- مستندسازی و مدیریت پایگاه دانش مرتبط با مشکلات و خطاهای شناخته شده
- مشاهده آیتم‌های پیکربندی تحت تاثیر از درون یک رکورد مشکل
- پیگیری زمان
- پیوند با پایگاه دانش ثالث
- استفاده از پیکربندی‌های انعطاف‌پذیر برای فیلدها مانند متن آزاد، منوی کشویی، تاریخ/زمان، پیوست‌ها و ضبط صفحه‌نمایش