Az előző posztban láthattuk, hogy a két cégnek (aki kiszervezi az IT-t és az IT-t üzemeltető külső cég (Sandbox és ITS)) mások az érdekei. Az elsőnek ugye az, hogy a szolgáltatás színvonala legalább olyan jó legyen, mint a kiszervezés előtt, a másiknak pedig az, hogy minden hónapban megkapja a szerződésben foglalt pénzösszeget (és lehetőleg minél kevesebb kiadása legyen).

Ugye az világos, hogy a Sandbox szeretne valamiféle kimutatást/mérőszámot arról, hogy milyen az ITS szolgáltatása, mennyire mennek rendben a dolgok. Erre az egyik módszer a hibajegy rendszer használata, amibe (elvileg) minden eset bekerül, amit az ITS végez. Erről aztán mindenféle riportokat lehet készíteni, hogy hány százalékát sikerült megoldani a hibajegyeknek, a jegyek hány százaléka zárult le időben, stb. Jó módszer, ugye? Akkor nézzük meg, hogy ez hogyan működik a valóságban.

Egy ideális világban a következő módon működne a hibajegyes rendszer:

1. Az ügyfélnek (jelen esetben Sandbox alkalmazott, mivel az ITS-nek ő az ügyfele) akad egy problémája, mondjuk nem működik egy céges szoftver, minden induláskor hibaüzenetet ad. Nyit egy hibajegyet az esetről, és türelmesen várja a megoldást.
2. A hibajegy az adott szoftverrel foglalkozó ITS-es csapathoz kerül, akik megvizsgálják a problémát, megoldják, majd amikor az ügyfél megerősíti, hogy valóban megoldódott a probléma, lezárják a jegyet, az SLA-ban megfogalmazott 3 napon belül.
3. Mindenki boldog.

A valóság ezzel szemben így néz ki:

1. Ügyfél megnyitja a hibajegyet, és türelmesen vár.
2. A hibajegy némi várakozás után odakerül a megfelelő ITS-es csoporthoz.
3. Mivel globális szinten sok hibajegy nyílik, az adott csoportban pedig nem dolgozik elég ember, ezért eltelik 1-2 nap, mire eljutnak oda, hogy ránézzenek.
4. Szerencsés esetben meg is tudják oldani az ügyet, azonban ha 2 kattintásnál, és az előre leírt megoldás-paneleknél bonyolultabb az ügy, akkor nem tudják megoldani. Vagy legalábbis elég sok időbe kerül.
5. Éééés most jön a trükk! Mivel az SLA-ban foglalt 3 nap lassan letelik, küldenek egy üzenetet az ügyfélnek, hogy lezárják ezt a hibajegyet, és ha még mindig fennáll a probléma, akkor szóljon, és nyitnak neki egy újat.
6. Az ügyfél csak néz bután, de nem igazán tud mit tenni, beleegyezik.
7. Az ITS így is tesz, lezárja a hibajegyet, "Megoldva" státusszal, mivel egy hibajegyet csak így lehet lezárni. Egyszerűen így írták meg a rendszert, hogy egy esetet csak a problémát megoldó csapat tud lezárni (az ügyfél nem), és csak és kizárólag "Megoldva" státusszal. Olyan, hogy "Lezárva megoldás nélkül" nincs. Minek is lenne? Az csak rontaná a statisztikát, nem?
8. Ha a probléma továbbra is fennáll (miért ne állna, az ITS semmit nem csinált), udvariasan nyitnak egy új jegyet, és keződik az egész úja a 3. pontról. Ezt akár 4-5-ször is megcsinálják, mire megoldják a problémát, vagy az megoldódik magától, vagy az ügyfél megunja, és megoldja másképp (pl. megkér valakit, hogy csinálja meg helyette).

Nézzük, hogy mit lát ebből a Sandbox vezetése, amikor a hó végén megnézi az összesített riportot egy olyan esetben, amikor mondjuk már 4-szer újranyitották a jegyet:

5 db hibajegy nyílt, abból négyet lezártak az SLA-nak megfelelően, 1 pedig még nyitott, de az is 1-2 napos. Ez legrosszabb esetben is 80%-os eredmény, úgyhogy az ITS megérdemli a pénzét, mivel mindent fantasztikusan csinál.

És mi a helyzet valójában? Van egy problémánk, ami hetek óta nincs megoldva.

Így nem nehéz jó mutatókat adni a megbízó cégnek, ugye?