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 / hardwaruNespá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 Příspěvek Kaizen, ITIL, plýtvání a zmetky pochází z Jiří Polášek
Možná jsme už o kaizenu slyšeli. Tenhle pojem se občas mihne v různých přednáškách, školeních, něco málo se dozvíte na internetu a z wikipedie, něco se dá načíst z diplomových prací, existuje pár knih a někdo se s touto aktivitou potkal v továrně. Boh
projít na článekDnes, prakticky o kaizenu v IT … Minule jsem psal o tom, že oblasti kaizenu (plýtvání, zmetky, dodavatel, taktování linky…) lze použít i v oblasti IT nebo dokonce soukromého života a dnes mám reálnou praktickou ukázku z IT. Vezměme si provoz web
projít na článekPři studiu kaizenu narazíte v teorii určitě i na kapitolu, která srovnává kaizen a inovace a staví je proti sobě jako odlišné přístupy. Zároveň se oba přístupy nevylučují. Zjednodušeně inovace přinášejí revoluční změny technologií, za cenu vysokých pořiz
projít na článekHlavním principem kaizenu jsou drobné změny a drobná vylepšení, nikoli revoluční inovace. Při ladění výrobní linky tedy přidáváme třeba jednoduchá mechanická udělátka, která práci ulehčí, zrychlí a zajistí neprodukování zmetků. Rozhodně se nekupují po
projít na článekAxalta Irus Mix Míchací zařízení Axalta Irus je plně automatizované, což zajišťuje maximální ziskovost a poskytuje udržitelné výhody při lakování v autoopravnách. Tento stroj je rychlý, účinný a přesn
projít na článek