هادی احمدی (سروش):

SLA های هندوانه ای

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

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

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

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

به چه چیزی بد نگاه می کنید؟

بد نیست فکر کنید که اندازه گیری SLA چیزی جدید نیست. نمونه های بسیاری در دنیای بهترین تجربیات وجود دارد که چگونه اندازه گیری ها می توانند نتایج اشتباه را هدایت کنند، دو مورد در اینجا هستند که جزو مهم ترین قوانین کمپبل و گودر است، که به ترتیب یک روانشناس / دانشمند علوم اجتماعی و اقتصاد هستند. در دنیای علوم اجتماعی، قانون کمپبل بیان میکند:
هنگامی که یک متریک به عنوان شاخص اولیه موفقیت شناخته شود، توانایی آن برای اندازه گیری دقیق موفقیت، به خطر می افتد.
یک قانون مشابه در حوزه اقتصاد وجود دارد؛ قانون گودرث می گوید:
وقتی اندازه گیری یک هدف است، توقف آن، بهترین اندازه گیری است.
به طور خلاصه، مهم نیست که محیط شما چیست یا در چه صنعتی و یا چه بخشی از آن هستید، اغلب شرکت ها از SLA بعنوان یک جعبه تمرینی استفاده می کنند. خطر این رویکرد این است که تمرکز همه چیز در مورد اهداف به طور بالقوه خودسرانه به جای کیفیت کلی خدمات است. معیارهای ضعیف نیز ممکن است سبب تقویت رفتار اشتباه شود. به عنوان مثال، نرخ حوادث بیش از حد سریع، ریسک از دست دادن اطلاعات حیاتی را افزایش می دهد و یا سبب عدم استفاده از راه حل مشکلات موجود و خطاهای شناخته شده می شود. اگر کارشناسان پشتیبانی و سرویس دهندگان فقط روی سرعت تمرکز کند، چیزهایی مانند خلاقیت، اضافه کردن یادداشت های مناسب، بررسی پایگاه دانش، ایجاد راهکار، شناسایی علت حادثه، ریشه یابی و واگذاری حادثه به یک مشکل و یا حتی تخصیص چند ثانیه اضافی برای تلاش و اصلاح حادثه در همان بار نخست از بین می رود و این همان داخل قرمز هندوانه است! ضمن اینکه با گذشت زمان، این امر منجر به کاهش کیفیت خدمات عمومی و افزایش زمان صرف شده برای بازگرداندن حوادثی می شود که در نهایت هیچکدام خوب نیست. تازه فقط این نیست شما از تکنسین های پشتیبانی و سرویس دهندگان تعدادی رباط-تکنسین خط تولید می سازید که انگیزه های شغلی آنها را در حاکمیت مطلق SLA های فاقد معیار از بین می رود و نتیجه ابتکار، خلاقیت، پویایی و ارایه راهکارهای بهینه برای همیشه از بین می رود چراکه بر اساس مفاهیم ITSM هدف از اجرای تمامی فرایندها، بهبود مستمر است.

اجتناب از SLA های هندوانه

اگر شما در مورد اثر SLA هندوانه نگران هستید -  امیدوارم که شما را به اندازه کافی متقاعد کرده باشیم در اینجا برخی از چیزهای کلیدی که باید به دنبال داشته باشید:
  1. اهدافی که مبهم یا قابل اجرا نیستند را دنبال نکنید.
  2. اندازه گیری هایی که قابل دستیابی نیستند را معیار قرار ندهید.
  3. اطلاعات بیشتری درباره حساسیت یا تاثیر تجاری کسب و کار به دست بیاورید
  4. بیش از حد مجازات برای اقدامات تعیین نکنید.
  5. اصطلاحات فنی را پیش از تخطی و نقض SLAها از قبل مرتفع کنید.
  6. SLA هایی که زمان بندی های مورد توافق را ندارند را تعیین نکنید.
  7. رضایت مشتریان و رضایت سرویس دهندگان را باهم در نظر بگیرید.
  8. جلسات منظم بیشتری برای ارایه خدمات منطبق با حساسیت های کسب و کار و عملکرد و توانایی واحد پشتیبانی بازبینی
  9. روابط انسانی را فراموش نکنید.
سپس فعالیت های پشتیبانی روز افزون فناوری اطلاعات وجود دارد که ما می توانیم بهتر انجام دهیم - چه با نتایجی که ما از طریق معیارهای مورد نظر (در SLA ها) هدف قرار می دهیم یا خیر - چرا که بیش از همه، مشتریان ما سزاوار بهترین ها هستند! اما به خاطر داشته باشید که نباید هدف ما از اینها فقط کسب موقعیت بالاتر، افزایش درآمد و تمدید مشتری برای حفظ کسب و کار باشد. میز کار و تیم پشتیبانی ما نیز به همان اندازه، شایسته است که بهترین باشد. IT باید توانمند باشد تا بهترین خدمات ممکن را ارائه دهد، نه اینکه توسط SLA محدود شود. و مرتبا عملکرد آنها ممیزی گردد از طرفی هر کسی که خدماتی را که ارائه می دهد، باید بهترین تجربه ممکن را داشته باشد؛ چرا که، به عنوان متخصصان فناوری اطلاعات، کارشناسان پشتیبانی ویترین سازمان هستند و پرچم داران اولین درگاه پاسخ و مرکز کمی و کیفی خدمات فناوری هستند. تاکید می کنم که پدر علم مدیریت نوین، پیتر دراکر می گوید: "هر چیزی که اندازه گیری نشود قابل مدیریت نیست" اما این را هم به یاد بیاورید که صرفا بر اعداد و آمار تمرکز نکنید، چیزی است که همه ما می بینیم، اعداد است نه تجربه کاربر نهایی. به عنوان مثال، SLA برای درخواست حقوق و دستمزد شما ممکن است هدف دسترس پذیری ۹۹٫۵٪ باشد. آیا شما این هدف را برآورده می کنید؟ آیا همه چیز درست است؟ قطعا پاسخ نه است! اگر ۰٫۵٪ از خرابی در پایان ماه، مورد پردازش قرار نگیرد. شاید اتفاق بی بازگشتی رخ نداده باشد! در عوض باید همه چیز در مورد تجربه کاربر نهایی باشد و ما باید پارادایم را از اندازه گیری ها و معیارها به تاثیرات تجاری تغییر دهیم. در مثال پرداخت حقوق، اهداف SLA ممکن است کاملا برآورده شده باشد، اما آیا تیم های مالی و حقوق و دستمزد در مورد استفاده از سرویس احساس خوبی دارند؟ و در مورد کاربران نهایی (کارکنان) که ممکن است تاخیر یا اشتباه در دستمزد خود را تجربه کرده اند، SLA های هندوانه به ما آسیب برسانند. آیا شما SLA های هندوانه را در عمل دیدید؟ چگونه آنها بر سازمان شما تاثیر گذاشتند؟ لطفا در کامنت ها مرا در جریان بگذارید! با تشکر: هادی احمدی


0 0 رای
امتیازت به این مطلب؟
عضویت در سایت
اطلاع رسانی
guest

0 نظر
بازخورد (Feedback) های اینلاین
مشاهده همه دیدگاه ها
error: لینک های همرسانی مطلب در سمت چپ صفحه هست دوست داشتی به اشتراک بگذار!
0
نظرت مهمه حتماً بنویس!x