Issue Tracking System: Popis a využití připomínkovacího systému
Issue Tracking Systems (ITS) nebo-li připomínkovací systémy slouží ke sledování vývoje v řešení předem definovaného úkolu. Tento úkol se může týkat čehokoliv od běžných dotazů zákazníků až po odstraňování chyb či zpracování podrobných technických zpráv. Článek přináší základní popis takového softwarového produktu a ukázku jeho praktického využití. 1. Připomínkovací systémy, jejich výhody a nevýhody Připomínkovací systémy (ITS - Issue Tracking Systems) plní podobnou funkci jako běžné lepící lístky, na něž píšeme důležité připomínky, vzkazy či úkoly. Ty pak umisťujeme na viditelné místo, nebo je předáme člověku, který je odpovědný za řešení daného úkolu. Lístek má tedy nějaký obsah, autora a osobu zodpovědnou za vyřešení definovaného problému. Celý proces končí splněním úkolu a vyhozením lístku. V ITS se tyto lístky nazývají jako "tickets" (dále tedy budeme užívat pojem ticket). Připomínkovací systémy samozřejmě nabízejí uživatelům mnohem více funkcí, než jen řízení životního cyklu definovaných úkolů. Mnoho organizací využívá ITS, které v sobě zahrnují softwarový vývoj, výrobu, IT podporu a další služby (1). Jedním z úkolů pro ITS je sdílení úkolů napříč celým týmem. ITS také umí uchovávat historii všech řešených úkolů, což znamená, že jeho uživatelé mohou vyhledat ticket s podobnou nebo stejnou problematikou a celou záležitost za jeho pomocí rychle vyřešit. Hlavní vlastností ITS je bezesporu přehlednost, neboť každý problém je řešen individuálně na příslušném ticketu, který je jedinečně identifikovatelný. Při správném využití je schopen ITS nabídnout tyto přínosy: ITS využívá řada společností ke sledování určitých chyb např. ve spojení s monitorovacím systémem Nagios, k zákaznické podpoře, při realizaci pracovních toků (workflow), při změnovém řízení apod. (2) K nejvyužívanějším ITS patří systémy Bugzilla, IBM Rational ClearQuest nebo Request Tracker. V našem článku jsme se rozhodli pro praktickou demonstraci funkčnosti ITS využít produktu SNOW (ServiceNow), s nímž jsme měli možnost se seznámit ve společnosti, která jej využívá pro servisní podporu (Service Desk). Její název stejně jako konkrétní údaje z rozhraní systému nebudeme pro jejich citlivost uvádět. 2. Systém SNOW a jeho praktické využití 2.1 Uživatelé systému Jednotlivým uživatelům jsou přiřazeny konkrétní role, dle jejich pracovní náplně či postavení. Tyto role jsou následující: Každá z výše zmíněných rolí má v sobě zahrnutou roli "uživatel", tzn. každý, kdo má do systému přístup, může tvořit požadavky/incidenty. 2.2 První pohled Uživatel vstupuje do systému prostřednictvím webového prohlížeče. Následující obrázek ukazuje úvodní stránku systému z pohledu operátora. Zákazník má přístup pouze do záložky "Self-Service". Obr. 1 – Domovská stránka SNOW (Zdroj: vlastní)
Dle navigačních kategorií zákazník zařazuje vytvářené tickety. Každá z kategorií pak obsahuje podrobnější rozdělení, aby bylo možné tickety lépe třídit a následně efektivněji distribuovat k řešitelským týmům, což je ovšem možné pouze u činností, které se opakují, např. příchozí/odchozí zaměstnanec, různé přístupy, objednávky vybavení apod. 2.3 Moduly systému Samotný systém se skládá z několika modulů, které se v grafickém rozhraní nachází vlevo a jsou upořádané do pásu. Aplikované moduly budou znázorněny a krátce popsány níže. Obr. 2 – Modul Self-Service (Zdroj: vlastní)
V tomto modulu zákazníci zadávají požadavky a incidenty. Můžou zde sledovat také tickety, které jsou příbuzné k jeho skupině. Tento modul je přístupný všem uživatelům systému SNOW a zároveň je jediným modulem, který je určen k přímým interakcím zákazníka. Obr. 3 – Modul Incident (Zdroj: vlastní)
Tento modul zobrazuje evidované incidenty. I zde můžeme sledovat nové, probíhající, lokální, globální, uzavřené incidenty apod. Obr. 4 – Modul Service Catalog (Zdroj: vlastní)
Modul Service Catalog funguje podobně jako modul Incident, pouze je zaměřen na požadavky a jejich plnění. Obr. 5 – Modul Change (Zdroj: vlastní)
Tento modul slouží k podpoře realizace navržených změn. Může se jednat např. o stěhování serverů, pořizovaní nového hardwaru, optimalizaci podnikových procesů apod. Obr. 6 – Modul Reports (Zdroj: vlastní)
Tento modul slouží pro generování reportů a údajů určených pro podporu manažerského rozhodování. Může se jednat např. o plošné zhodnocení dodržování SLA, počet vyřešených ticketů jednotlivými operátory a další podobné sestavy a ukazatele. Obr. 7 – Modul Knowledge Base (Zdroj: vlastní)
Modul Knowledge Base obsahuje různé návody a postupy, které byly nashromážděny zaměstnanci společnosti. Tyto poznatky slouží nejen k zaškolování nových pracovníků, ale i jako nápověda při běžné pracovní činnosti. Všechny moduly SNOW lze dle potřeb upravovat, aktualizovat či různě obměňovat. O tuto činnost se starají integrátoři systému. 2.4 Ticket Základním elementem celého systému je ticket. Ten sám o sobě nic neobsahuje, pouze jsou k němu připojeny požadavky (requests), které již obsahují informace o problému a jeho řešení. Ticket se tedy skládá minimálně ze dvou těchto požadavků, a to ze splnění zadaní (fulfillment) a vyrozumění zákazníka (user confirmation). Každý ticket musí mít také svého vlastníka (ticket owner). Ten je manažerem ticketu a je zodpovědný za jeho vyřešení a distribuci k zodpovědným týmům. Dále pak obsahuje samotného řešitele (assignee), kterého si určuje každý tým zvlášť, pokud zákazník nežádá někoho konkrétního. Každý z požadavků má rovněž svůj status, který je určený aktuálním stavem. Statusy jsou následující:
Typický ticket se skládá ze dvou částí. Ty představují samotné splnění (fulfillment) a vyrozumění zákazníka (resolved – user confirmation) - viz následující obrázek. Obr. 8 – Rozložení požadavku na jednotlivé tickety (Zdroj: vlastní)
Existují ovšem i výjimky, např. požadavky na přístupy do různých systémů pro nově příchozí zaměstnance nebo analogicky zrušení přístupů zaměstnanců, kteří již ve společnosti nepracují. To znázorňuje obrázek níže. Obr. 9 – Požadavek přístupů rozložený na jednotlivé úlohy (tasky) (Zdroj: vlastní)
Pokud není úloha uzavřena (task - closed), je možné se vracet k jakémukoliv stavu dle potřeby, což stává zejména v případech, kdy zákazník není s řešením úkolu spokojen. 2.4.1 Priority a Service Level Agreement Zákazník nastavuje prioritu každému ticketu dle závažnosti řešeného problému či úkolu, od níž se pak odvíjí SLA. Priority se řídí dle dopadu na lokální, regionální, globální a požadované doby reakce a vyřešení. Přehled těchto veličin znázorňuje následující tabulka. Tab. 1 – Přehled SLA a incidentů (Zdroj: vlastní)
V tabulce je znázorněn souhrn priorit incidentů a s nimi korespondujících SLA, od nichž se odvíjí doby reakce a vyřešení. V případě kritické priority je automatem telefonicky kontaktován člen Service Desku, který drží pohotovost. Všechny doby kromě kritických se počítají v rámci pracovní doby (business hours), která zahrnuje pracovní dny od 9:00 do 17:00. Na obrázku níže vidíme SLA u incidentů v rámci systému. Obr. 10 – SLA u incidentů ve SNOW (Zdroj: vlastní)
V případě požadavků mají všechny společné pouze dobu vyřešení nastavenou na 8 hodin. Obdobně jako v předchozím případě na následujícím obrázku. Obr. 11 – SLA u požadavků ve SNOW (Zdroj: vlastní)
2.4.2 Požadavek Požadavek vyjadřuje určitou potřebu po nějaké činnosti. Konkrétně jde tedy o žádosti týkající se různých přístupů, služeb či úkonů. Následující obrázek znázorňuje frontu těchto požadavků. Obr. 12 – Fronta požadavků (Zdroj: vlastní)
Na obrázku můžeme vidět frontu nových požadavků, které operátoři dále distribuují k řešitelským skupinám. 2.4.3 Incident Incident vyjadřuje určitou událost, která se odlišuje od požadovaného stavu. Jedná se tedy o různé výpadky, bugy, chyby apod. Následující obrázek zobrazuje frontu incidentů, konkrétně těch, které již byly vyřešeny. Obr. 13 – Fronta požadavků (Zdroj: vlastní)
2.4.4 Komunikace s řešitelem a zákazníkem Komunikace mezi všemi účastníky procesu řešení probíhá vně ticketu, a to vzhledem k případnému auditu, a také kvůli možnosti nahlédnout do již řešených a zavřených ticketů. Komunikace probíhá prostřednictvím textových polí (work notes). Tyto poznámky vidí pouze operátor a řešitel. Dále se komunikuje pomocí komentářů (additional comments), které jsou viditelné pro všechny, tedy i pro zadavatele ticketu. Vše znázorněno v následujícím obrázku. Obr. 14 – Komunikační kanály vně ticketu (Zdroj: vlastní)
2.5 Systém z pohledu zákazníka Následující kapitola pojednává o roli zákazníka, v níž si vytváří vlastní ticket. Následující obrázek znázorňuje přehled takto vytvořených ticketů z pohledu zákazníka. U každého ticketu můžeme sledovat jeho stav a po rozkliknutí přidávat nebo získávat nové informace. Obr. 15 – Přehled ticketů zadaných zákazníkem (Zdroj: vlastní)
Další obrázek znázorňuje detail konkrétního ticketu zadaného zákazníkem. Je zde popsané rozložení na jednotlivé úlohy, dále pak zadání, data, stav, komentáře a další. Obr. 16 – Detail konkrétního ticketu (Zdroj: vlastní)
Použitá literatura 11.03.2015 - Lukáš Fuxa, Tomáš Šejna
(Klikněte na obrázek pro zvětšení)
(Klikněte na obrázek pro zvětšení)
(Klikněte na obrázek pro zvětšení)
(Klikněte na obrázek pro zvětšení)
(Klikněte na obrázek pro zvětšení)
(Klikněte na obrázek pro zvětšení)
(Klikněte na obrázek pro zvětšení)
(Klikněte na obrázek pro zvětšení)
(Klikněte na obrázek pro zvětšení)
(Klikněte na obrázek pro zvětšení)
(Klikněte na obrázek pro zvětšení)
(Klikněte na obrázek pro zvětšení)
(Klikněte na obrázek pro zvětšení)
(Klikněte na obrázek pro zvětšení)
(Klikněte na obrázek pro zvětšení)
(Klikněte na obrázek pro zvětšení)
(Klikněte na obrázek pro zvětšení)