Publikováno: 11. 12. 2012
Narážíme opakovaně na problém, kdy nejběžnější proces (Incident nebo Žádost) má v nejjednodušší variantě tyto stavy:
A) Verze „IT Outsourcingová firma“ Nový -> Řešení -> Vyřešeno -> Uzavřeno
B) Verze „Interní IT“ Nový -> Řešení -> Uzavřeno
Rozdíly jsou dle mého názoru dány kulturně:
A) „IT Outsourcingová firma“
- Slabší vyjednávací pozice vůči zákazníkovi: Win-Lose
- Tlak na SLA, -měření a sankce při neplnění
- Zákazník požaduje vyjádření se k řešení nebo odůvodnění vzniku incidentu (Tuto činnost dodavatel nepočítá do SLA „Čas do vyřešení“, proto vzniká nový stav „Vyřešeno“ -> k němu se pak počítá SLA „Čas do vyřešení“)
B) „Interní IT“
- Interní IT má silnou vyjednávací pozici: Win-Win
- Tlak na efektivitu a minimalizují se administrativní úkony – všechny požadavky se ihned uzavírají, ale zůstává možnost je následně otevřít ze strany žadatele k dořešení (může být omezeno časově např. 14 dní)
- SLA je měřeno –> sankce však nejsou obvyklé
- Interní odběratel nemá zájem o analyzování každého incidentu (to je starost IT)
U obou variant je zachována možnost vyjádření se k řešení ze strany žadatele. Obě varianty jsou podobné, ale z pohledu programátora aplikace jde o velký rozdíl. Obzvláště pokud chceme, aby aplikace byla maximálně automatizovaná a přesně podporovala chování pracovníka. (notifikace, měření SLA, rychlé volby atd.)
Jakou byste navrhli standardní variantu, která by měla být po instalaci v aplikaci k dispozici?
ODPOVĚĎ
Odpověď Jiřího Skály
V současnosti je nejpoužívanějším způsobem zaslání notifikace předkladateli při vyřešení tiketu (tj. status Vyřešeno), čímž začíná běžet lhůta, během níž může předkladatel reklamovat způsob vyřešení tiketu. Současně se tím přerušuje počítání času řešení tiketu.
Pak mohou nastat 3 situace:
- Pokud uživatel během této doby nereaguje, je po jejím uplynutí automaticky nastaven status Uzavřeno, a tiket již nejde nikdy otevřít. Pokud si uživatel vzpomene až po uplynutí této doby, že NENÍ spokojen, musí tedy založit nový tiket, samozřejmě s odkazem na tiket původní, ale novému tiketu běží čas řešení znovu od nuly.
- Pokud uživatel během této doby odpoví, že JE spokojen, je automaticky nastaven status Uzavřeno, a tiket již nejde nikdy otevřít.
- Pokud uživatel během této doby odpoví, že NENÍ spokojen, je automaticky nastaven nějaký pracovní status (podrobnosti viz další odstavec) a opět se spustí počítání času (to počítání pokračuje od hodnoty, ve které bylo přerušeno odesláním notifikace předkladateli). Současně je vhodné, aby automaticky došlo k odeslání notifikace tomu, kdo se bude tiketem dále zabývat, protože poskytovateli služeb opět běží čas započítávaný do SLA.
Administrátorsky by mělo být možné v nástroji SD definovat:
- Způsob notifikace uživateli při nastavení statusu Vyřešeno. Nejobvyklejší je e-mail s uvedením URL do SD aplikace, kde se může k řešení vyjádřit, ale používá se i SMS. Není příliš vhodné telefonické volání, i když i to se používá (například v O2, ale mně osobně se to moc nelíbí).
- Délku lhůty pro vyjádření uživatele. Obvykle se používá 3-5 pracovních dní.
- Do jakého místa procesu se má tiket vrátit, když uživatel během této doby odpoví, že NENÍ spokojen. Například to může jít na SD, který to následně někomu přidělí, nebo např. poslednímu řešiteli, který nastavil ten status Vyřešeno.
Výše uvedený způsob jsem já i mí kolegové použili na všech implementacích incident managementu a service desku v posledních 5 letech, a ani žádný zákazník po nás během těch 5 let nepožadoval jiný způsob ošetření uzavírání tiketů.
Odpověď Vladimíra Váni
Pokud se bavíme o standardu pro proces „Incident and service request management“ – může jím být pouze ISO/IEC 20000-1:2011. Tato norma vyžaduje dokumentování:
- zaznamenání
- stanovení priority
- klasifikaci
- aktualizaci záznamů
- eskalaci
- vyřešení
- uzavření
Z toho vyplývají i mandatorní požadavky na stavy záznamu.
Z hlediska praktické implementace ale bývá stavů podstatně více, než uvádíte v uvedených dvou příkladech. Stanovení stavů je závislé zejména na požadavcích Service Reportingu pro všechny strany, které potřebují výstupy z procesu Incident and service request managementu. Nejvíce požadavků vyplývá z procesu SLM. Tedy – který čas se má počítat do garantovaného Fix time.
Jedná se typicky například o:
- měření doby práce subdodavatele
- čekání na součinnost zákazníka
- pozastavení řešení z jiných důvodů
- měří se čas trvání incidentu od:
- přijetí telefonátu
- zadání do systému
- klasifikace záznamu pracovníkem service desku
- převzetí požadavku k řešení prvním řešitelem
- čas trvání incidentu se měří do:
- vyřešení
- akceptace zákazníkem
- uzavření
- jak se započítává reklamace v případě „reopen“
Pokud se podaří se zákazníkem – interním nebo externím – dohodnout na výše uvedených pravidlech, může být navržen proces včetně jeho stavů. Univerzálně použitelný model nelze jednoznačně stanovit. Základ může v každém případě vycházet z návrhu procesu uvedeného v ITIL – Service Operation, ale ještě jsem se nesetkal s praktickou implementací přesně kopírující tento obecný návrh.
Odpověď Vladimíra Kufnera
Souhlasím, jen bych doplnil:
- ITIL neřeší stavové diagramy ani datové modely, je to Best practise či guidance
- doporučuji držet se doporučení ISO20K
Činnost v rámci podřízení procesu IM pod SLA/SLM resp. reportování zpravidla povede k tomu, že se „rozroste“ workflow a tudíž i adekvátně stavový diagram (i když čistě technicky se dá řešit pouze na základě historie a auditu tohoto záznamu, pro reportování to není vždy praktické).
Není možné najít „zlaté“ řešení, je možné nalézt „optimální řešení vůči něčemu“ – s ohledem na trend komoditizace ServiceDeskových nástrojů bych doporučil tento přístup:
- respektovat ITIL workflow pro IM nebo ReqF procesy, z toho vyplyne i stavový diagram
- pokud má vámi použité řešení předdefinovaný stavový diagram/WF, které jen trochu odpovídá požadavkům zákazníka, tak jej nechat OOTB a nedělat customizaci. Výjimkou může být pouze situace, kdy nabízená verze vyžaduje znatelné a zbytečné zvýšení pracnosti.
Štítky: Jiří Skála, Vladimír Kufner, Vladimír Váňa
Autor:: Kateřina Mrkvičková