Incident management: jeden nástroj lepší než druhý

Pojďme se společně zamyslet nad tím, jaké vlastnosti by měl splňovat nástroj na incident management.

A nezapomínejme přitom na to, že jsou minimálně dvě skupiny uživatelů tohoto nástroje, ti co incidenty hlásí a ti co je řeší. Incident může být uživatelem nahlášen telefonicky, mailem nebo přes webové rozhraní, což je z pohledu řešitele ta nejlepší varianta a z pohledu uživatele mnohdy ta nejhorší, bohužel. Bez ohledu na to, jakým způsobem je incident nahlášen, vždy by měl být spuštěn proces, jehož výsledkem by mělo být vyřešení daného incidentu. Proto také incident management zavádíme. 

Životní cyklus incidentu

Incident se během svého životního cyklu obvykle nachází v jednom z níže uvedených stavů. Vzhledem k tomu, že nástrojů na incident management je mnoho (a jeden je lepší než druhý), jsou tyto stavy pojmenovány různě, a proto musíme provést určité zobecnění.

  • Detected – incident je někým nebo něčím detekován. V tomto stavu incident existuje mimo systém a ještě nebyl nahlášen na helpdesk.
  • Registered – incident je v nástroji něčím nebo někým zaevidován
  • Assigned – helpdesk incident vyhodnotil a přidělil ho k řešení konkrétní osobě nebo řešitelskému týmu
  • Confirmed – pokud bylo přidělení incidentu helpdeskem správné, daná osoba nebo řešitelský tým incident přijetí incidentu potvrzuje
  • Refused – pokud bylo přidělení incidentu helpdeskem chybné a daná osoba nebo řešitelský tým není kompetentní k řešení incidentu daného typu, tak incident odmítá. Incident se v takovém případě buď vrací na helpdesk, který musí provést nové přiřazení nebo ho může sama řešitelská skupina poslat na jinou z jejich pohledu vhodnější skupinu.
  • Analyzed – incident je řešitelským týmem analyzován a je hledáno to nejrychlejší možné řešení. Cílem je, aby co nejvíce incidentů vyřešila první úroveň podpory a na další úrovně podpory se dostávalo incidentů co nejméně.
  • Suspended – někdy řešitelský tým potřebuje doplnit od uživatele určité informace a po tuto dobu, co se čeká na informace od uživatele, se incident nachází v tomto stavu
  • Solved – v okamžiku, kdy řešitelská skupina najde řešení daného incidentu, označuje incident za vyřešený
  • Accepted – řešení je uživatelem akceptováno
  • Rejected – řešení je uživatelem odmítnuto
  • Closed – poté, co je řešení uživatelem akceptováno, může být incident uzavřen.

U všech stavů by mělo být definováno, jak dlouho se může incident v daném stavu nacházet. A u jednotlivých incidentů by mělo být možné tuto dobu změnit. Minimálně by měla být stanovena maximální doba řešení incidentu, resp. kdy nejpozději by měl incident přejít do stavu Closed. Je otázka, zda v okamžiku, kdy byl již incident jednou uzavřen, umožnit jeho znovuotevření, anebo založit incident nový s odkazem na ten původní. V okamžiku, kdy je čas řešení incidentu překročen, měl by na to být příslušný pracovník upozorněn.

Intuitivní rozhraní

Jestliže chcete, aby vám uživatelé hlásili incidenty prostřednictvím webového formuláře, musí být takovéto rozhraní naprosto intuitivní. Pokud uživatelské rozhraní (GUI) nebude intuitivní, nebude takovýto systém uživateli přijat a budou ho odmítat. A vězte, že ke zlepšení situace nepomůže ani sebelepší školení. Uvědomte si, že vzhledem k tomu, že uživatel obvykle nehlásí incident každý den, musí ihned pochopit, co a kam má přesně zapsat. Pokud chcete, aby uživatelé váš nástroj používali, nemělo by být k jeho použití nutné absolvovat nějaké školení nebo studovat dlouhý manuál. Jinými slovy, nástroj sám by měl uživatele vést a upozorňovat ho na to, co a kam má zapsat. Dovoluji si tvrdit, že drtivá většina uživatelů, kteří vám budou incident tímto způsobem hlásit, s počítačem běžně pracuje a je zvyklá, že určité věci fungují ve většině aplikací stejně a očekávají, že nejinak tomu bude i ve vaší aplikaci. Ovládací prvky by proto měly být na obvyklých místech. Bohužel nezřídka se ta stává, že nejen uživatelé, ale i řešitelské týmy mají problémy s danou aplikací pracovat. 

Efektivní workflow

Nástroj by měl umožňovat snadné předávání incidentu mezi jednotlivými řešitelskými skupinami. Přeposlání incidentu na další řešitelskou skupinu musí být stejně jednoduché, jako když přeposíláte e-mail. Krátce po nasazení nástroje na incident management je třeba počítat s tím, že první úroveň podpory bude některé incidenty směrovat na špatné řešitelské skupiny. Pokud helpdesk neanalyzuje, kdo nakonec incident daného typu řešil, může se stát, že bude incident přiřazovat pořád špatně. V opačném případě by se měl počet chybně přiřazených incidentů v delším časovém horizontu postupně snižovat. Předpokladem však je, že vybraný nástroj umí budovat databází znalostí (knowledgebase) a efektivně v ní vyhledávat již jednou řešené incidenty. Vždy by měla být stanovena osoba dohlížející na vyřešení incidentů v rozumném čase. Pokud není stav řešení incidentů v systému nikým monitorován, hrozí, že jednotlivé řešitelské skupiny budou jim přidělené incidenty odmítat nebo si ho budou mezi sebou přeposílat jako „horký brambor“. 

Komunikace s uživatelem

Incident by měl být v systému evidován pod jedním číslem, pouze by se měl měnit jeho status a řešitelská skupina. Uživatel, který incident nahlásil, by měl mít možnost sledovat, v jakém stavu se incident nachází. Měl by proto dostat e-mail obsahující číslo incidentu a odkaz, na kterém může stav řešení incidentu sledovat. V okamžiku, kdy se incident dostane do stavu Vyřešeno (Solved), měl by uživatel dostat e-mail s požadavkem na akceptování daného řešení. Poté, co je řešení uživatelem odsouhlaseno (Accepted) měl by incident přejít do stavu uzavřen (Closed) a uživateli by měl být zaslán informativní mail o uzavření incidentu. 

E-mailová notifikace řešitelů

Nástroj by měl umět zaslat notifikaci o tom, že řešitelské skupině byl přiřazen incident. Není možné počítat s tím, že člen řešitelského týmu se bude celý den sledovat frontu, jestli se tam náhodou něco neobjevilo. Možnost zasílání této informace by měla být zpřístupněna všem uživatelům vybraného nástroje, a měli by mít možnost si to sami nastavit. Je zřejmé, že tým, který je plně alokován na řešení incidentů a přijde mu jich několik za hodinu asi žádnou e-mailovou notifikaci potřebovat nebude, protože by ho jen vyrušovala. Avšak tým, kterému chodí jeden incident za den nebo za týden ano, protože jinak nebude reagovat v požadovaném čase. Notifikace nemusí být jen mail, může se jednat i o ikonu v tray, která se změní svůj status nebo popup okno, které se objeví v okamžiku, kdy je incident dané řešitelské skupině přidělen.

Vyhledávání

Dalším velice častým problémem některých nástrojů je, že se v nich velice špatně vyhledává. Víte, že podobný incident jste již jednou řešili, ale pochopitelně si již nepamatujete jeho číslo. Nástroj by tedy měl umožnit sestavit takový dotaz, aby bylo možné zadat klíčové slovo, jméno řešitele nebo řešitelské skupiny a případně období, kdy jste incident řešili.

Závěr: Uvědomte si prosím, že uživateli je jedno, kolik řešitelských týmu na řešení jeho incidentu spolupracuje a jak je řešení jeho incidentu náročné. Uživatel svou povinnost splnil v okamžiku, kdy vám incident nahlásil a to způsobem, který ho stál určité úsilí. Přiznejme si, že pro většinu uživatelů je mnohem jednodušší a pohodlnější zvednout telefon a incident nahlásit tímto způsobem. Vyplňování jakéhokoliv formuláře uživatele obtěžuje. Když už vám uživatel incident prostřednictvím webové aplikace nahlásil, řešte ho. Nevracejte mu incident s tím, že tam něco špatně vyplnil. Vůbec nejhorší je, když řešitelský tým vrátí incident uživateli v nejzazším možném termínu s tím, že něco špatně vyplnil. Když víte, že uživatel něco špatně vyplnil – opravte si to a neobtěžujte ho s tím. S největší pravděpodobností uživatel podobný problém v nejbližší době stejně hlásit nebude, takže argumentovat tím, že to děláte proto, aby to uživatel vyplnil příště správně, je nesmysl. Když už máte potřebu uživatele poučovat, udělejte to v okamžiku, kdy je jím nahlášený incident vyřešen.

Pro citování tohoto článku ve své vlastní práci můžete použít následující odkaz:
ČERMÁK, Miroslav. Incident management: jeden nástroj lepší než druhý. Online. Clever and Smart. 2010. ISSN 2694-9830. Dostupné z: https://www.cleverandsmart.cz/incident-management-jeden-nastroj-lepsi-nez-druhy/. [cit. 2025-02-10].

Pokud vás tento článek zaujal, můžete odkaz na něj sdílet.

Štítky:


K článku “Incident management: jeden nástroj lepší než druhý” se zde nenachází žádný komentář - buďte první.

Diskuse na tomto webu je moderována. Pod článkem budou zobrazovány jen takové komentáře, které nebudou sloužit k propagaci konkrétní firmy, produktu nebo služby. V případě, že chcete, aby z těchto stránek vedl odkaz na váš web, kontaktujte nás, známe efektivnější způsoby propagace.

Přihlášeným uživatelům se tento formulář nezobrazuje - zaregistrujte se.

Jméno:(požadováno)
E-mail:(požadováno - nebude zobrazen)
Web:

Text vaší reakce: