Jednou z osmi forem plýtvání v rámci kaizenu jsou defekty nebo ještě lépe – zmetky.
V továrně jsou to pokažené, nepřesné výrobky, nedostatečná kvalita apod.
Co však představují
zmetky v oblasti IT, kde nevytváříme fyzické výrobky ?
Vzhledem k tomu, že pracujeme s informacemi, pak každá „nepovedená“,
„nepřesná“, „nekvalitní“ nebo špatně předaná informace je
zmetek a analogie s výrobou už je zřetelnější.
Pokud navíc ve firmě používáme ITIL, tak si zmetky můžeme jednoduše představit ve formě tiketů, ať už se jedná o service requesty, incidenty, problém tikety apod.
Když totiž IT odděleními proplouvá špatně zpracovaný tiket, jedná se o podobné plýtvání jako když linka chrlí zmetky.
U tiketů v IT oblasti se nejčastěji můžeme setkat s tím, že už na začátku („linky“) je tiket nesprávně zadán, buď samotným uživatelem nebo lidmi z helpdesku. Další vrstvy IT pak dodají špatná řešení nebo návody k řešení chyby. Ta koncovému uživateli nepomáhají, takže se „zmetek “ vrací do výroby (tiket se znovu otevírá) a informace k tiketu se teprve začínají upřesňovat. Občas se tím řešení více a více komplikuje, přibývá (nepřesných) informací, tiket si mezi sebou „pingají“ jednotlivé vrstvy IT.
Řešení se protahuje na několik dní, protože zdržení mezi jednotlivými IT oddělení se neustále zvětšuje.
Typickými situacemi kdy vznikají špatné tikety jsou:
- Nicneříkající popis chyby: „nefunguje mi notebook“
- Nepřesné, neúplné informace o incidentu – chybějící popis, kdy a jak se chyba projevuje, přesná chybová hláška, typ zařízení, verze programu, chybějící screenshoty apod.
- Chybějící nebo nepřesné informace v LOGu incidentu – ty mohou vést k tomu, že různá IT oddělení provádějí stejnou investigaci, kterou už provedl někdo jiný, nebo vycházejí ze špatných výstupů
- Předávání tiketů na různá IT oddělení bez jakéhokoli komentáře s pozdějším vysvětlením „to se nás netýká, to není záležitost sítě / operačního systému / hardwaru“
- Nespárování incidentů k problém tiketům – vedoucí k tomu, že na stejných věcech pracuje více řešitelů aniž by o sobě věděli
Další případy defektů/zmetků v IT:
- Nepřesné emailové požadavky s nejasnou zodpovědností, mnoha příjemci – ty pak bloudí po firmě, aniž by bylo jasné jak s nimi pracovat a jak na ně reagovat.
- Nesprávně nainstalovaná zařízení. Je fajn, když dostanete nový výkonný notebook, ale pokud musíte strávit několik hodin doinstalováním různých aktualizací a softwarů, které se ve firmě běžně používají, tak ztrácíte produktivní čas (nebylo by lepší dostat plně funkční, ihned použitelný notebook?)
- Nesprávná dokumentace (případně neúplná nebo neexistující) – schopní uživatelé, kteří mohou leccos vyřešit vlastními silami neznají postup a volají support, zakládají tikety apod. V případě zastaralých dokumentací (třeba k staršímu typu zařízení) hledají příliš dlouho způsob jak situaci vyřešit, aby se po hodině zkoušení dozvěděli rychlým dotazem, že u nového typu zařízení je nutno „zakliknout“ jedno zatržítko navíc, které ve staré dokumentaci není
- Nesprávně vyladěné alarmy z monitorovacího systému, které zbytečně nutí techniky zkoumat něco, co není relevantní
- Defekty ve vývoji SW (… samostatná oblast v rámci vývoje SW)
Jak se na zmetky dívá Kaizen ?
Kaizen doporučuje „nepustit zmetek dál“ a to dokonce tak, že se zastaví celá linka. Je to logické, protože pokud cokoli způsobí nepřesné výrobky a vy to neopravíte, tak jich budete mít za chvíli na výstupu hromadu. Proto mívají operátoři tak velkou pravomoc, že linku mohou zastavit a okamžitě začít pátrat po příčině chybovosti.
Analogicky to může fungovat v IT.
Pokud kdokoli zjistí, že je v tiketu nedostatek detailů – nepustí jej „po lince dál“ a zajistí jejich doplnění (protože je jasné, že bez screenshotu chyby s tiketem nikdo nepohne …)
Klidně můžeme i „zastavit linku“. Konkrétně to může vypadat tak, že architekt, který má na starosti CRM systém dá helpdesku povel „vyskytují se potíže s CRM, ale neposílejte nám tikety bez upřesnění typu počítače a jeho MAC adresy“.
Následujícím krokem může být i úprava šablony pro tiket, kde je MAC adresa povinným údajem formuláře.
V praxi ale IT oddělení fungují trochu jinak 🙁
Nesprávné tikety se většinou projeví až při eskalaci uživatelem, nebo při měsíčním hodnocení SLA tiketů. Jako příčina dlouhých časů řešení a znovuotevření tiketů bývá zmíněn nedostatek dodaných informací mezi jednotlivými IT odděleními nebo uživateli, ale je to spíše takový povzdech, který ne vždy vede k nějaké nápravné akci.
Dalším problémem bývá to, že IT oddělení na řešení pracují odděleně a berou si zodpovědnost pouze za část investigace, a tak dochází k tomu že někteří specialisté místo rychlého telefonátu s uživatelem, raději posílají tikety zpět na předchozí vrstvu nebo helpdesk a tím se řešení prodlouží několikanásobně.
Kaizen to vidí jinak
– pokud je v mých silách jakkoli v danou chvíli pomoci, tak to udělám –
informace zjistím a kolegy informuju o nutnosti dodávat potřebné detaily…
Kaizen totiž staví na spolupráci a zapojení všech kolegů ve firmě.
Posledním IT nešvarem je situace, kdy odmítnu zmetek, ale nenásleduje žádná akce. Typicky – dorazil tiket s nedostatkem informací, tak jej prostě zavírám s řešením „nedostatek informací“. Ano, nepustil jsem „zmetek“ dále, ale koncového uživatele takové IT „řešení“ pouze popudí a plýtvání se zvětší tím, že je nutné tiket zadat znovu a znovu proplouvá napříč IT.
Závěr: propojení ITIL a Kaizen pohledu
V článku popisuji činnosti, které velmi dobře řeší ITIL. I když používáme doporučené postupy, přesto lze vysledovat značná plýtvání. Pokud přidáme ještě pohled typu „Kaizen-plýtvání-zmetky“, tak můžeme zefektivnit práci tím, že zmetky nepustíme dál, „zastavíme linku“ a zabráníme vzniku dalších zmetků.
Příběh odjinud …
Se státní správou jsem řešil žádost o dotaci (nedigitálně, papírově 🙂
Celá akce zahrnovala vyplnění několika formulářů, dodání dokumentů a jednání s úředníky. Těsně před schválením dotace však poslední (důsledný) úředník zjistil, že na základě prvotních údajů, je nutno přiložit další dokument. To znamenalo další odsun jednání, časovou prodlevu, zbytečné cestování (+benzín), čas na dodání dokumentu – no prostě hned několik druhů plýtvání, jen proto, že dva úředníci v řadě poslali „zmetek“ po lince dál 🙂