Snižte ztráty prioritizací incidentů

25.01.2016

Prioritizace činností a jejich plánování je předpokladem úspěchu každé organizace. Zvládnutí tohoto procesu v rámci jednotlivých týmů je pak zodpovědností příslušného manažera. V řadě případů stačí nepsaná pravidla a správné rozhodování všech zúčastněných. V tomto článku se zamyslíme nad složitější situací, v níž vystupuje více zúčastněných subjektů, které řeší desítky a stovky jednotlivých požadavků. Půjde nám hlavně o incidenty (tedy neplánované výpadky služeb), se kterými jsou přímo či nepřímo spojeny finanční ztráty. Pokud stanovíme jasná pravidla určující, do kdy by incidenty měly být vyřešeny, můžeme ztráty v situacích, kdy k incidentům dojde, minimalizovat.

Protože máme na mysli IT procesy, měli bychom začít tím, jak danou věc řeší ITIL v3. ITIL se zabývá IT procesy, ale jeho principy jsou platné i pro obdobné procesy mimo IT. Stejně tak myšlenky z tohoto článku mohou být inspirací i pro týmy či organizace řešící procesy nejrůznějších požadavků, objednávek, příkazů či zakázek.

ITIL v3 - Service Operation chápe prioritu jako funkci urgentnosti (jak rychle business potřebuje řešení) a dopadu na business (typicky podle počtu uživatelů a jejich významu). Urgentnost si lépe představíme jako míru potřeby řešení situace, pokud má incident tendenci narůstat na vážnosti (pak musíme reagovat rychleji) nebo jeho vážnost naopak klesá (pak k jeho řešení můžeme přistoupit později než obvykle). Dopad je pak mírou finančních ztrát, poklesu reputace nebo jiných škod.

Níže uvedená tabulka ukazuje výpočet kódu priority jako kombinace dopadu a urgentnosti.

Pak již stačí jednotlivé stavy priority kvantifikovat, tj. přidělit kódům lhůty na vyřešení jako například v tabulce níže.

Prioritě incidentu také odpovídá čas, do kdy by řešitel měl potvrdit akceptaci incidentu do řešení. Nás však zajímá lhůta na vyřešení a kalkulace cílového času vyřešení. Ten závisí na počátečním čase, lhůtě k řešení a tomu, kdy nám běží čas. Pojďme si tyto tři vlivy rozebrat. Nejde o triviální otázky a je třeba provést správnou volbu odpovídající vaší organizaci. Pravidla, která si v organizaci nastavíme, bychom totiž měli být schopni dodržet a měla by tedy být v souladu se schopnostmi organizace. Tak jako všechny cíle i cíle v oblasti procesu řešení incidentů by měly být realistické či dosažitelné (viz koncept SMART cílů).

1. Počáteční čas lze chápat jako čas vzniku incidentu, to je čas výpadku služby, poruchy prvku informačního systému atd. V praxi však není lehké zajistit okamžitou identifikaci takového problému. Jako počátek volíme proto raději čas zaregistrování - nahlášení incidentu.
2. Lhůta k řešení ve výše uvedeném příkladu závisí na urgentnosti a dopadu. Zvláště v menších organizacích se můžeme rozhodnout pracovat jen s jedním faktorem (dopadem na business), protože skutečné rozdíly v urgentnosti se mohou vyskytnout jen zřídka. Stále však bude třeba jasně stanovit podle čeho dopad určit. Některé organizace rozlišují množství postižených uživatelů (jednotlivec, tým, pobočka, celá organizace). V praxi je ale velký rozdíl mezi konkrétními službami. Výpadek systému pro evidenci docházky nebo školení zaměstnanců asi nemá takový dopad jako výpad systému pro online sjednávání obchodů, kdy se dá poměrně jednoduše vyčíslit, o kolik peněz společnost přijde například za jednu hodinu. Podobně výpadek v týmu pracovníků podpůrných týmů back office nemusí znamenat okamžitý výpadek tržeb jako u pracovníků front office sjednávajících obchody. Při posuzování bychom tedy měli brát v úvahu obchodní ztráty či jiné kvantifikovatelné nepříznivé dopady. Lhůty na vyřešení je pak třeba přizpůsobit reálným možnostem řešitelských týmů, počtu pracovníků a tomu, co si společnosti přeje zajistit. Vyšší úroveň služeb bývá spojena s vyššímu náklady na jejich zajištění.
3. Kdy nám běží čas při řešení incidentu. Čas běží stále. Z pohledu usilí vynakládaného na řešení tomu ale tak být nemusí. Představte si, že v pátek večer krátce před odchodem pracovníků je zjištěn incident s nízkou prioritou - ve výše uvedeném příkladu k vyřešení do 16 hodin. Přes víkend uživatelé nepracují a ani IT tým nedrží služby. Pokud ale nikdo incident nezačne řešit, během víkendu vyprší lhůta na jeho vyřešení. Jak se má IT manažer rozhodnout? Při nastavování procesu je třeba stanovit, kdy běží čas na vyřešení incidentu. Mělo by to být v době, kdy se mu může někdo věnovat - řešitelské týmy drží službu nebo jsou na pohotovosti a IT manažer může nařídit přesčasovou práci. Oba přístupy lze samozřejmě kombinovat a říci, že pro incidenty s vysokou prioritou (kód 1 a 2) čas běží stále a pro méně důležité jen v době, kdy mají řešitelé službu. Různé řešitelské týmy navíc mohou mít různou pracovní dobu. Například infrastrukturní tým zajišťující běh zásadních systémů jako například Active Directory musí být schopen reagovat okamžitě (v noci i přes svátky), tým zajišťující kritickou aplikaci funguje do pozdních večerních hodin a částečně i přes víkend a tým pro méně důležitý systém může mít běžnou pracovní dobu včetně pauzy na oběd.

Jak se s těmito požadavky v praxi vypořádat? Především se důkladně informujte na možnosti systému, jehož pořízení zvažujete. Jinak běžně můžete narazit na to, že určité věci Váš incident management software prostě nebude schopen naplnit. Kromě možnosti jednoduché definice různých kalendářů (pracovních dob) pro různé týmy dejte také pozor například na schopnost systému změnit cílový čas vyřešení, pokud během řešení incidentu zjistíte, že jeho priorita by se měla zvýšit či snížit.

A co nabízí v této oblasti ObjectGears? Kromě výše uvedené matice priorit nebo naopak jednofaktorové prioritizace (pouze obchodní dopad, ne urgentnost), je to například:

• označení incidentů jako VIP (porucha notebooku běžného uživatele versus porucha u generálního ředitele)
• jednoduchá definice kalendářů pracovní doby zohledňující pravidelné i nepravidelné výjimky jako státní svátky, pracovní soboty, mimořádné směny atd. tak, aby cílový čas plánovaného vyřešení požadavku odpovídal všem možným specifikám dané organizace
• jednotná fronta úkolů řešitele. Řešitel incidentu často řeší i jiné požadavky (úkoly, jejichž termín je dohodnut s nadřízeným nebo projektovým manažerem, katalogové požadavky s časem na vyřešení dle typu požadavku, případy k otestování, vady nahlášené z testů atd.). Prioritizovat je tak třeba nejen v rámci incidentů ale mnohem širšího spektra typů úkolů. ObjectGears nabízí různou logiku kalkulace těchto časů a zároveň všechny typy požadavků reflektuje v jednotné frontě řešitele.
• notifikace před blížícím se termínem vypršení času. Cílem každého týmu řešícího incidenty nebo jiné úkoly by mělo být vyřešit je v čas, v dohodnuté lhůtě. Notifikace umožní identifikovat incidenty, kde se ten čas již blíží a upozornit přiřazeného řešitele nebo nadřízeného o potřebě jednat.