V ideálním světě vše funguje dokonale, nedochází k žádným výpadkům, uživatelé jsou spokojení a na Service Desk nikdo nevolá. Realita však bývá poněkud jiná a často velmi dynamická. V této situaci je nutné zaměřit se na několik klíčových faktorů.

Rychlé řešení výpadků neboli incidentů

V první řadě je nutné minimalizovat dopad případných výpadků na vlastní byznys organizace. V tom nám pomůže jednoduchý graf, který nám ukáže, co se aktuálně děje. Jde o sledování trendu, zda dochází, či nedochází k výpadkům neboli incidentům a zda jejich počet narůstá, nebo klesá. Některá IT oddělení mají v tomto grafu smíchané incidenty a žádosti. V takovém případě ale graf ztrácí vypovídací hodnotu. 

Obr. 1: Zdravý graf vývoje incidentů

Zdravě vypadající graf má klesající tendenci všech otevřených incidentů. To také znamená, že je vyvážený počet podaných a vyřešených incidentů. Spojnice trendu (v grafu tečkovaně) v budoucnu protne nulu. To znamená, že tým má situaci pod kontrolou. Graf může být různě modifikovaný. Například může být rozdělený podle IT služeb. 

Obr. 2: Nemocný graf vývoje incidentů

Pokud ale graf není zdravý, pak se počet incidentů stále zvyšuje. Spojnice trendu neprotíná v budoucnosti nulu. Graf nám ukazuje, že tým tedy bude stále více zatížen a je pravděpodobné, že dříve nebo později přestane situaci zvládat.

Při hodnocení trendů je nutné vždy zohledňovat konkrétní situaci a životní cyklus infrastruktury. Zátěž infrastruktury může v různých obdobích kolísat. Pokud podnik obměňuje polovinu HW vybavení, dá se očekávat větší počet incidentů, stejně jako při nasazení nového ERP. Vždy je potřeba rozumět příslušnému kontextu. V situaci, kdy incidenty rostou rychlejším tempem, než je příslušný tým stačí řešit, bychom se měli nejprve zaměřit na okamžité zlepšení a odpovědět si na otázky:

• Věnuje se tým ještě jiným činnostem, které je možné pozastavit (např. řešení běžných žádostí, nebo profylaxi)?
• Můžeme přesunout nějaké jiné členy IT týmu, aby pomohli na Service Desku?
• Můžeme využít externí kapacity nebo je jinak posílit?

Takto se pokusíme situaci rychle uvést do rovnováhy a snížit dopady na vlastní byznys. Může jít o rychlé rozhodnutí na pondělní poradě týmu. Jakmile je vyřešen samotný incident a okolnosti zaznamenány, můžeme přejít k hledání příčin problémů. Budeme si klást otázky, které půjdou více do hloubky a identifikují problém. Provedeme důkladnější analýzu (například 5whys root cause analýzu), ptáme se například na následující:

• Čeho se tyto incidenty týkají? Jaké služby? Jaké technologie?
• Byl spuštěn nějaký nový systém, nebo provedena nějaká změna?

Analýza příčin incidentů je nutná k dalšímu rozvoji služby a řešení problémů. Jejich odstranění má následně pozitivní vliv na trendový graf ve větším časovém horizontu. Nicméně neustále je třeba mít na zřeteli, že v krizi je potřeba soustředit se na obnovení služby. Dále je nutné, aby šéf Service Desku sledoval, o jak vážné incidenty se jedná. Zde nám může pomoci dělení podle priority nebo SLA, které je na incidentech nastaveno.

Obr. 3: Sledování dodržování dohodnutého SLA by mělo být samozřejmostí.

Samozřejmostí je sledování dodržování dohodnutého SLA. V případě, že dochází k porušování SLA, je potřeba zjistit, z jakého je to důvodu. Zda skutečně nebylo možné SLA splnit například z kapacitních důvodů, zda jsou požadavky správně seřazené ve frontě, zda řešitelský tým vidí, že se blíží termín narušení SLA, atp. Pomoci týmu lépe rozpoznat priority.

Pokud se stává, že dochází k porušení kritického SLA a přitom jiná SLA jsou v pořádku, je opět na místě analyzovat, z jakého důvodu. Proto je dobré, aby graf ukazoval, jaké SLA bylo porušeno. Je například možné, že se kritické incidenty předávají jednomu řešiteli, který pak funguje jako úzké hrdlo.

Někteří zákazníci také sledují, zda se podařilo incidenty vyřešit bez dopadu na byznys. K tomu může pomoci oddělit od sebe interně hlášené incidenty od těch, které hlásí uživatelé. Často se rovněž zaznamenává čas, kdy daná služba skutečně měla dopad na byznys.

„O tom, jestli je nedostupná nějaká služba, přesněji vypovídá spíše monitoring, který je schopen přesně zaznamenat výpadek a opětovné zprovoznění, nezávisle na žadateli (byznys uživateli) a také řešiteli (služba už může být v provozu, ale řešitel ještě několik hodin po incidentu pracuje na požadavku, než ho uzavře). Jenže zde bývá problematické zajistit kvalitu a důvěryhodnost dat,“ otevírá teoretickou úvahu k incidentům Michal Paseka, vedoucí provozního úseku, Alta, a. s.

Plnění žádostí v dohodnutých termínech

Druhá důležitá role Service Desku je plnění žádosti uživatelů v dohodnutých termínech. Jak už jsme psali, je potřeba od sebe zcela oddělit incidenty a žádosti. Protože žádosti budou mít často jiný režim. Bývají schvalovány. Tlak na SLA bývá často výrazně odlišný.

Principiálně jde o stejné grafy jako u Incidentů. Rozdílné ale bude použití a reakce na tyto grafy. V případě trendového grafu celkového objemu žádostí při rostoucí tendenci není vždy akutně nutné rychle reagovat, ale je možné situaci řídit v rámci dohodnuté úrovně SLA. Někdy může jít o záměrné zpomalení realizace žádostí, například z důvodu významného releasu nebo nějaké jiné větší změny. IT tým soustředí všechny kapacity na tyto události a řešení žádostí může „jít stranou“. Nicméně je nutné tuto situaci komunikovat s uživateli a dohodnout se na změně termínu realizace. Samozřejmě pokud již dochází k výraznému porušování SLA a může dojít k dopadům na byznys, bude nutné zvážit nějaký zásah. Může jít o posílení kapacity jak interně, nebo externím nákupem.

Užitečné jsou také jednoduché grafy ukazující, jak jsou žádosti, případně i incidenty distribuovány do týmu. Může to pomoci identifikovat interní nesrovnalosti.

Obr. 4: Graf odpovídá na otázku, jak je tým aktuálně zatížen.


Obr. 5: Graf odpovídá na otázku, který řešitel nejrychleji likviduje požadavky.

Samozřejmě grafy ukazující pouze počty požadavků jsou zavádějící, protože nereflektují náročnost úkolů. Pomoci může alespoň priorita nebo rozdělení požadavků podle typu. Stále častěji se ale objevují reporty podle skutečně odvedené práce na požadavcích.

Spokojenost především

Měření spokojenosti je samozřejmě nejzásadnějším ukazatelem. Zde se často sleduje spokojenost s řešením incidentu nebo žádosti. Toto měření má ale svá úskalí. Měříme pouze uživatele, kteří byli v obtížné situaci anebo o něco žádali. Toto měření je spíše orientační a o celkové spokojenosti nám příliš neříká. Nicméně určitě má svůj smysl. Umožňuje uživateli snadno zaslat pochvalu nebo stížnost. V obou případech jde o užitečnou informaci, kterou je ale dobré číst v kontextu času a rozpoložení uživatele.

Mnohem důležitější je sledovat celkovou spokojenost se službami, které dodáváme. Je dobré provádět kampaňovité měření. Často se provádí jednou ročně. Nemusí být nutně na všechny zaměstnance, obzvláště pokud jde o větší organizace. Zde bývá dotazník komplexnější a pro dnešní díl vybereme otázky týkající se Service Desku. Otázky se často týkají kvality práce řešitelů, jejich schopnosti pomoci, ochoty apod. Součástí dotazníků mohou být i otázky na jednotlivé dodávané IT služby a spokojenost se službou nebo inovativnost dané služby. Určitě je nutné sledovat také meziroční vývoj těchto ukazatelů, což vyžaduje používat otázky, které budou mít víceletou platnost.

Je potřeba dávat pozor na systém známkování, který může být v multikulturních organizacích jinak chápán. Mnohem lepší je vybavit formuláře populárními smajlíky, které jsou univerzální. Určitě je dobré sledovat podíl odeslaných a zodpovězených dotazníků. I to do určité míry ukazuje, jaký vztah mají uživatelé k IT.

„Je potřeba si uvědomit, že uživatel není schopen hodnotit pouze Service Desk jako část IT – splývají mu jednotlivé funkce a organizační útvary v rámci IT. Vyjádření spokojenosti uživatelů bych doporučoval vždy řešit ve vztahu k jednotlivým IT službám a nikoliv dle organizačních celků. Dále se ukazuje, že hodnocení není objektivní – uživatel si to nechce rozházet s lidmi, kteří mu zajišťují servisní podporu,“ doplňuje zkušenosti z praxe Radovan Fikr, IT manažer, HARTMANN-RICO, a. s.

„Měření spokojenosti provádíme dotazníkem zhruba jednou za 5 let. Jinak na spokojenost nebo nespokojenost se vyptávám při pravidelných osobních návštěvách na klinikách,“ doplňuje Tomáš Gregor, manažer IT služeb FNO.

	Filip Pražák Autor článku je konzultantem ve společnosti ALVAO a současně studentem oboru Service, Science, Management and Engineering na Masarykově univerzitě.
	Ing. Aleš Studený Autor článku je ředitelem služeb ve společnosti ALVAO. Jeho tým konzultantů zlepšuje IT v českých i zahraničních firmách. Je aktivní v publikaci odborných článků na téma řízení IT (ITSM) a tuto problematiku přednáší na vysokých školách.