Hogyan csökkentettük az átlagos megoldási időt 60%-kal a ServiceNow-val (esettanulmány)

Mit mér valójában az MTTR, és miért fontos

Az átlagos megoldási idő (Mean Time to Resolution, MTTR) az átlagos idő egy incidens bejelentése és teljes megoldása között. Nem a válaszadási, nem a visszaigazolási átlagidő – ez a teljes óra a „valami elromlott”-tól a „minden újra működik”-ig.

A legtöbb nagyvállalati IT-szervezetnél az MTTR az az egyetlen mutató, amely a legjobban tükrözi az operatív hatékonyságot. A magas MTTR azt jelenti, hogy a felhasználók várnak, az üzleti folyamatok megakadtak, és a támogatói csapat tüzet olt ahelyett, hogy szolgáltatásokat fejlesztene. Minden órányi MTTR a havi több száz incidensen át közvetlenül elveszített produktivitásként és bevételként jelentkezik.

Az ügyfél helyzete a kezdetekkor

Egy 12 000 alkalmazottat foglalkoztató európai gyártócég, érett ServiceNow ITSM-bevezetéssel, problémával fordult hozzánk: az átlagos MTTR-jük az elmúlt év során 4,2 órára emelkedett a tizennyolc hónappal korábbi 2,8 óráról. A vezetőség frusztrált volt, az IT-ügyfélszolgálat pedig túlterhelt.

A tünetek ismerősek voltak. Az incidenseket rossz csoportokhoz rendelték hozzá elsőre. Tudásbáziscikkek léteztek, de nem jelentek meg az incidensek létrehozásakor. Az SLA-időzítők futottak, de senki nem reagált a megsértési figyelmeztetésekre. És az ügyfélszolgálat felvette azt a szokást, hogy mindent L2-re és L3-ra eszkalál, mert a triage-folyamat törött volt.

A gyökérok nem emberi probléma volt – az analitikusok kompetensek és motiváltak voltak. Konfigurációs probléma volt. A ServiceNow nem segítette őket a hatékony munkában; útjukban állt.

Mit konfiguráltunk a probléma megoldására

Intelligens hozzárendelési szabályok

A meglévő hozzárendelési szabályok kizárólag a kategórián és alkategórián alapultak, ami azt jelentette, hogy a széles csoportok, mint a „Hálózati támogatás”, VPN-problémáktól a központi router-hibákig minden incidenst megkaptak. Újraépítettük a hozzárendelési logikát kategória, konfigurációs elem, helyszín és prioritás kombinációjával. Az éles szervereken jelentkező kritikus incidensek most közvetlenül a senior infrastruktúra-csapathoz kerülnek. A rutinszerű jelszó-visszaállítások az önkiszolgáló portálra mennek, teljesen megkerülve az ügyfélszolgálatot.

Készség-alapú irányítást is bevezettünk a ServiceNow Agent Intelligence (gépi tanulás) segítségével. A modell betanítása 18 hónap incidens-előzményi adatain után 87%-os pontossággal találta el a megfelelő hozzárendelési csoportot az első hozzárendelésnél – kiküszöbölve a ping-pong-hatást, amelynek során az incidensek három-négy csoport között pattognak, mielőtt a megfelelő csapathoz érnek.

SLA-időzítő újrakonfigurálása

Az ügyfélnek voltak SLA-definíciói, de nem volt operatív válasz rájuk. A megsértési figyelmeztetéseket e-mailek formájában küldték, amelyek elvesztek a forgalmas postaládákban. Az e-mailes értesítéseket valós idejű dashboard-riasztásokra és mobilos push-értesítésekre cseréltük csapatvezetők számára. Hozzáadtunk egy „75% letelt” figyelmeztetési szintet – ha egy incidens eléri az SLA-ablakának 75%-át státuszfrissítés nélkül, a hozzárendelt analitikus és a vezetője is riasztást kap.

Még fontosabb: automatikus eszkalációt állítottunk be SLA-megsértés esetére. Ha egy incidens megsérti a megoldási SLA-ját, automatikusan a következő szintre eszkalálódik kötelező vezetői felülvizsgálattal. Ez elszámoltathatóságot teremtett kézi terhelés hozzáadása nélkül.

Tudásbázis-integráció az incidens létrehozásakor

A tudásbázis 2 400 cikket tartalmazott, de a keresés rosszul volt beállítva. Az analitikusok 5-10 percet töltöttek egy ismert megoldás keresésével, nem találták meg, majd emlékezetből oldották meg a problémát – soha nem kötötték vissza a megoldást a tudásbázishoz. Újrakonfiguráltuk a tudásbázis-keresést, hogy automatikusan aktiválódjon az incidens rövid leírása és kategóriája alapján. A releváns cikkek most egy oldalsó panelben jelennek meg az incidens létrehozása során, egy kattintással használható „Megoldás alkalmazása” funkcióval.

Visszacsatolási hurkot is bevezettünk: amikor egy analitikus megold egy incidenst, megkérdezzük tőle, hogy egy tudásbáziscikk segített-e, megjelölheti a cikket elavultnak, vagy újat hozhat létre, ha nem létezett. 60 napon belül a tudásbázis statikus tárolóból aktívan karbantartott eszközzé vált.

Automatikus irányítás gyakori problémákra

Az incidensadatok elemzése feltárta, hogy az összes incidens 34%-a 12 előre jelezhető mintába esik – jelszó-visszaállítások, VPN-kapcsolódás, nyomtatóproblémák, szoftvertelepítési kérések és hasonló ismétlődő tételek. Minden mintára automatizált megoldási flow-kat hoztunk létre: a felhasználó beküldi az incidenst a szolgáltatási portálon, egy Flow Designer-automatizálás végrehajtja a javítást (vagy előre kitöltött feladatot hoz létre az analitikusnak), és az incidens emberi triage nélkül megoldódik.

Az incidensek 34%-ára, amelyek automatikusan megoldhatók vagy automatikusan irányíthatók voltak, az átlagos megoldási idő 4,2 óráról 15 perc alá esett.

Az eredmények

90 napos működés után az új konfigurációval:

• Az MTTR 4,2 óráról 1,7 órára csökkent – 60%-os csökkenés
• Az első érintéses megoldási arány 42%-ról 68%-ra emelkedett
• Az incidens-újrahozzárendelési arány 3,1 átlagos pattanásról 1,3-ra csökkent
• Az SLA-megsértési arány 23%-ról 4%-ra csökkent
• A felhasználói elégedettségi pontszám 3,2-ről 4,1-re javult (5-ből)

Az ügyfélszolgálati csapat ugyanazt az incidensmennyiséget 20%-kal kevesebb L2- és L3-eszkalációval tudta kezelni, felszabadítva a senior mérnököket arra, hogy tűzoltás helyett proaktív fejlesztésekre összpontosítsanak.

Fő tanulságok

A technológia már ott volt. A ServiceNow gyári állapotban rendelkezik minden képességgel ezekhez az eredményekhez. A hézag a konfigurációban volt – a platform alapfunkcionalitásra volt beállítva, de nem operatív hatékonyságra optimalizálva. Az intelligens hozzárendelési szabályok, a proaktív SLA-menedzsment, az integrált tudásbázis és a célzott automatizálás a ServiceNow-t jegy-naplózó rendszerből intelligens operatív platformmá alakította.

A 60%-os MTTR-csökkenés nem egyszeri javulás volt. Mivel minden komponensbe visszacsatolási hurkokat építettünk, a rendszer folyamatosan javul, miközben több adatot dolgoz fel és nő a tudásbázis.

Hasonló eredményeket szeretne?

Ha az MTTR-je emelkedik és az ügyfélszolgálata túlterhelt, a probléma szinte biztosan a konfiguráció, nem az emberek. A Milic Media olyan nagyvállalatok ITSM-optimalizálására specializálódott, amelyek kinőtték a kezdeti ServiceNow-beállításukat.

Foglaljon ingyenes ITSM-felmérést, és egy 30 perces hívás során azonosítjuk a top három MTTR-csökkentési lehetőségét.