فرایند میز خدمت(Service Desk) در استاندارد ITIL: مدیریت حادثه کارآمد!
فرایند میز خدمت(Service Desk) در استاندارد ITIL: مدیریت حادثه کارآمد!

فرایند میز خدمت(Service Desk) در استاندارد ITIL: مدیریت حادثه کارآمد!

فهرست مطالب :

جریان فرایند میز خدمت(Service Desk) در استاندارد ITIL: مدیریت حادثه کارآمد!

قبل از بحث پیرامون جریان فرایند میز خدمت در استاندارد ITIL، می‌بایست پیرامون چیستی استاندارد ITIL بحث شود.

کتابخانه زیرساخت فناوری اطلاعات (ITIL) یک طرح ابتکاری توسط دولت بریتانیا در دهه 1980 بود که در ابتدا با هدف مستندسازی همه متون، پرونده‌ها و بهترین تجارب مربوط به مدیریت فرایند فناوری اطلاعات، مورد استفاده قرار گرفت.

این پروژه چنان موفقیت‌آمیز بود که به یک مرجع در سراسر جهان تبدیل شد!

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

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

جریان فرایند میز خدمت ITIL: جریان کار به طور دقیق!

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

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

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

در نهایت، کاربر(سوال‌کننده) راه‌حل را تأیید می‌کند و تماس به پایان می‌رسد.

نگاهی به روند کامل مدیریت میز خدمت بیاندازید: جریان فرایند میز سرویس ITIL

جریان فرایند میز سرویس ITIL به سه نقش کار(lane) در یک محدوده کاری(Pool) تقسیم می‌شود: ( برای خواندن مقاله lane و pool کلیک کنید ) 

۱. کاربر: فردی که خدمات IT مربوط را فراخوانی می‌کند.

۲. کارشناس سطح اول پشتیبانی: این سطح برای راه‌حل‌های پایه و ساده بوده و اولین نقطه تماس با کاربر است.

۳. کارشناس سطح دوم پشتیبانی: یک تحلیلگر متخصص فناوری اطلاعات که می‌بایست پایگاه دانش به‌روزی برای هر پرسشی از سطح اول داشته باشد. او فردی است که مسئله‌های دارای بالاترین سطح پیچیدگی را حل می‌کند.

حال هر مرحله از روند کار میز خدمت ITIL بررسی شده است:

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

تطبیق دادن جریان کار با واقعیت کسب‌وکار شما

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

شرایط می‌تواند حتی پیچیده‌تر هم باشد. برای مثال اگر لازم باشد که خرید مالکیت سخت‌افزار هم درنظر گرفته شود، احتمالاً لازم خواهد بود که نقش کاری (Pool) دیگری برای ناحیه خرید درنظر گرفته شود.  

eBPM در شبکه های اجتماعی