مبانی ITSM: چگونگی تشخیص و مقابله با SLA های هندوانه ای

سالها پیش در یکی از شرکت های خودرویی در بخش پشتیبانی کاربران بر پایه استفاده از سیستم های مدیریت خدمات انفورماتیک، انجام وظیفه می کردیم ما تحت نظر معاونت فناوری اطلاعاتی کار می کردیم که به شدت بر روی رعایت SLA و عدم نقض و خروج از توافق ارایه خدمات تاکید بسیاری داشت به نحوی که آمارهای پاسخگویی حتی ۵% را هرگز قبول نمی کرد و علاوه بر تعیین جریمه های نقدی و گفتاری، مدیران زیر مجموعه را ملزم به ارایه گزارش دلایل عدم رعایت SLA می کرد آنزمان شدت نارضایتی نیروهای زیرمجموعه ایشان به شدت بالا رفت  به واسطه معیار SLA همگی تلاش می کردند تا از مواخذه شدن فرار کنند اما شدت استرس های ناشی از این مورد به حدی بود که طاقت ادامه فعالیت در حوزه های پشتیبانی و تولید برای بسیاری داشت از بین می رفت. شعار ایشان: به صفر رساندن تعداد تماس ها یا تیکت های بی پاسخ بود! یعنی فقط ۲% نقض پذیرفته می شد و ۹۸% باید همه چیز روی اصول تعیین شده پیش میرفت!

این یعنی افزایش رضایتمندی کاربر نهایی یا مشتری! اما این تعیین معیار SLA اشکالات زیادی داشت! چراکه علیرغم آمارهای ارایه شده سطح رضایتمندی کاربران نهایی ۹۸% نبود و این درصد حاصل شده آسیب شدیدی به کارشناسان و مدیران سرویس دهنده خدمات فناوری اطلاعات نیز وارد می کرد.

مهم این است که، به عنوان یک حرفه ای در مدیریت فناوری اطلاعات (ITSM) در ازای کیفیت خدمات فناوری اطلاعات که به مشتریان خود را ارائه می دهیم، پاسخگو باشیم. توافق نامه های سطح خدمات (SLAs) یک راه برای انجام این کار هستند که باید به خوبی انجام شود، آنها می توانند تفاوت های زیادی را در سطح خدمات و میزان شادی مشتریان ایجاد کنند. آیا کسی هست که شادی کاربران نهایی/ مشتریان را نمی خواهد؟ شادی کاربر نهایی /مشتری رهاورد افزایش سطح رضاتمندی و بهبود مدوام خدمات است و می دانید که کسب و کار بدون رضایت آنها عملا هیچ است!

با این همه، مشتریان با یک SLA هندوانه ای باقی می مانند – و این هندوانه حاوی یک هدف متریک (قابل اندازه گیری) است که در هنگام ارزیابی و مواجه شدن با مشتریان ناراضی می گوید که همه چیز خوب است!

یعنی آمار چیزی دیگر می گویند و سطح نارضایتی مشتری چیز دیگر!

در مورد این موضوع فکر کنید - آیا تا به حال در جلسه بررسی سرویس بوده اید که ارائه دهنده خدمات همه چیز را در مورد اهداف خود گزارش کرده باشد!؟ در حقیقت شما با خرابی برنامه ریزی نشده، عملکرد ضعیف یا شکایت های کاربر نهایی روبرو شده اید؟

این هندوانه SLA بیرون اش سبز است اما در داخل قرمز! یا شبیه یک سیب قرمز که از داخل کرم خورده! چه باید کرد تا کیفیت تظاهری و آماری نباشد!؟ لطفا برای راهنمایی در مورد چگونگی تشخیص و رفع آن، به آنها مراجعه کنید.

خطرات SLA های "بد"

بدیهی است که SLA ها همه ما را تحت تاثیر قرار می دهند – چه مشتریان و چه ارائه دهندگان به طور یکسان. از دیدگاه مشتری، SLA های طراحی شده ضعیف می توانند مسائل زیر را ایجاد کنند:

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

از دیدگاه ارائه دهندگان سرویس، وجود موافقتنامه های ضعیف SLA می تواند سبب:

• تمرکز بر موارد اشتباه، به عنوان مثال تمرکز بر سرعت بجای کیفیت
• درک متفاوت از اینکه چه برنامه ای یا چه خدماتی واقعا برای کسب و کار حیاتی است
• عدم درک تاثیر کسب و کار
• از کنترل خارج شدن مسائل و نگرانی های کوچک
• رتبه بندی رضایتمندی ضعیف
• تمرکز و مقابله و آتش سوزی ها روزانه با افزایش شکایت
• جلسات بررسی مجدد خدمات، با یک طرف احساس دفاعی و دیگر تجربه سطح پایین خدمات

ادامه مطلب در صفحه بعد...