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:

• zvýšení spokojenosti uživatelů a zákazníků,
• zajištění odpovědnosti za řešení úkolů,
• zlepšení a zkvalitnění komunikace v pracovním týmu a také se zákazníky,
• zvýšení produktivity práce,
• snížení nákladů (2).

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í:

• Zákazník – uživatel, který zadává požadavek nebo incident.
• Operátor – zpravidla zaměstnanec Service Desku, oproti zákazníkovi může ticket přiřazovat jednotlivým řešitelským skupinám.
• Řešitel – oproti zákazníkovi může měnit statusy, dle stavu, v jakém se ticket nachází.
• Admin – správci a integrátoři samotného systému.

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í)
(Klikněte na obrázek pro zvětšení)



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í)
(Klikněte na obrázek pro zvětšení)



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í)
(Klikněte na obrázek pro zvětšení)



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í)
(Klikněte na obrázek pro zvětšení)



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í)
(Klikněte na obrázek pro zvětšení)



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í)
(Klikněte na obrázek pro zvětšení)



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í)
(Klikněte na obrázek pro zvětšení)



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í:

• New – nový bez vlastníka nebo řešitele,
• In Progress – v řešení,
• Waiting for Feedback – čeká se na zpětnou vazbu do zákazníka, např. z důvodu nedostatečných informací nebo špatné specifikace,
• Waiting for External – čeká se na externí entitu, např. oprava bugu,
• Waiting for Approval – čeká na povolení, např. přístup do testovacího prostředí,
• Fixed – chyba je opravena,
• Resolved – požadavek je vyřešen, zákazník má týden na to se odvolat, pokud má námitky,
• Closed – celkové uzavření.

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í)
(Klikněte na obrázek pro zvětšení)



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í)
(Klikněte na obrázek pro zvětšení)



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í)
(Klikněte na obrázek pro zvětšení)



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í)
(Klikněte na obrázek pro zvětšení)



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í)
(Klikněte na obrázek pro zvětšení)



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í)
(Klikněte na obrázek pro zvětšení)



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í)
(Klikněte na obrázek pro zvětšení)



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í)
(Klikněte na obrázek pro zvětšení)



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í)
(Klikněte na obrázek pro zvětšení)



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í)
(Klikněte na obrázek pro zvětšení)



Použitá literatura

1. ROUSE, Margaret. What is issue tracking system (ITS)? [online]. 2007.
2. JANÁK, Jiří. Issue Tracking Systems. Brno, 2009. Diplomová práce. Masarykova univerzita, Fakulta informatiky.

11.03.2015 - Lukáš Fuxa, Tomáš Šejna - četlo 29915 čtenářů.

Tento článek ješte není ohodnocen.

Hodnocení článku: nejlepší [ 1 | 2 | 3 | 4 | 5 ] nejhorší

Diskusní fórum ke článku
Jméno
E-mail
Opište kód :
Text *)