Systém Kanban začal svou cestu v 50. letech na výrobních linkách Toyota, odkud se přenesl do kanceláří a stal se důležitým nástrojem pro projektové manažery.
Neomezená flexibilita této metody a její schopnost se samostatně organizovat umožnila efektivitu tam, kde ostatní přístupy nefungovaly. To je případ, kdy se vizitka systému stala samotnou kartou — etablovala se jako interní měna v organizacích, které Kanban implementovaly.
Původ
Stejně jako koncept Lean manufacturing byl systém Kanban vyvinut manažery Toyoty. Autorem systému, japonským inženýrem Taiichim Ohno, byl inspirován provozními principy amerických supermarketů, kde si zákazníci vybírali potřebné produkty sami. Úlohu “supermarketu” plnil v Toyotě sklad.Tam si pracovníci vyměňovali signální karty — což je to, co „kanban“ doslovně překládá z japonštiny — kteří manuálně regulovali výrobní proces.Karty byly připevněny k bednám s díly. Takové štítky uváděly informace o čísle části a množství, který oddělení je posílalo a kam měly dorazit.
Pracovník přímo zapojený do montáže strojů (“downstream”) by si vzal díly z bedny, k níž byla připevněna “kanban” požadující doplnění. Karte byla odstraněna a předána spolu s prázdnou bednou dopravci do skladu. Tam další pracovník připravil novou bednu s náhradními díly, k níž byla připevněna výrobní “kanban” — štítek s informacemi o vyrobených náhradních dílech.
Výrobní “kanban” byla nahrazena “kanban” požadující doplnění a poslána na výrobní linku náhradních dílů — “upstream”. Takto byla vyrobena přesně ta množství dílů, která byla uvedena na kartě. Bedna s novými náhradními díly byla transportéry umístěna na montážní linku.
Principy Kanban
Manažeři Toyoty vyjádřili 6 pravidel utvářejících systém:
- Pracovníci z “downstream” odebírají přesně tolik dílů z inventáře, kolik je uvedeno na kanbanu
- Pracovníci z “upstream” také dodávají díly striktně podle karet
- Nic se nevyrábí ani nepohne bez kanbanu
- Kanban musí být vždy připevněn k dílům
- Defektní díly se v systému nepoužívají
- Snížení počtu kanban karet činí řízení citlivějším na změny. Ale bez extrémní nezbytnosti není doporučeno měnit stanovený počet karet.
Kanban je “pull” systém. Vytváří rovnováhu mezi konstantním tokem, který eliminuje náklady na čekání, a minimálním množstvím práce v procesu (WIP), což snižuje rizika nadvýroby. WIP je regulováno pomocí karet: jejich počet je fixní a pokyny v nich vedou pracovníky “downstream”.
Limit WIP spočívá v poměru k množství kanban karet, které je vypočítáno na základě úrovně prodeje a statistické variability v aktuálních procesech. Maximální počet štítků — “energie” v systému — zabezpečuje horní úroveň WIP v daném okamžiku. WIP je také omezen principem tažení: rychlost výroby “upstream” závisí na pracovní rychlosti “downstream”.
Graf ukazuje, že jedním z základních prvků systému je kultura Kaizen. Autonomní procesy a standardní variabilita osvobozují management od trvalého dohledu, což mu umožňuje zaměřit se na zlepšení výkonnosti zaměstnanců.
Aplikace Kanban v IT
Systém Kanban, který nadále přináší výhody na výrobních liniích, pronikl do oblasti softwaru.
Jedině karty, které obsahují informace o termínech, popisech nebo číslech procesů a jméně vykonavatele, jsou nyní připevněny nikoli k bednám s náhradními díly, ale k tabulím se rozdělenými sloupci:
- Backlog — úkoly k dokončení
- Úkoly, které se aktuálně rozvíjejí
- Úkoly dokončené, ale dosud nepředané testerům
- Úkoly připravené k předání zkušebnímu oddělení
- Úkoly podléhající kontrole projektového manažera (PM)
- Dokončené úkoly
Číslo se obvykle píše nad sloupci — limit, který označuje maximální počet procesů v něm. Limit backlogu se vypočítává v závislosti na době realizace. Pokud je v systému 5 pracovních procesů a průměrná doba dokončení každého je 1 den, může být backlog omezen na 5.
Struktura výše není přísná — v závislosti na specifikách projektu mohou být přidány improvizované sloupce. Kanban systém může často mít potřebu definovat kritéria připravenosti úkolu před jeho provedením. V takovém případě se objevují dva sloupce, které se v angličtině nazývají specify (upřesňující parametry) a execute (převzetí práce).
- Druhý sloupec s prioritní frontou může být přidán. Když se vykonavatel uvolní, musí nejprve vyčistit tento sloupec úkolů, než se ujme dalších.
- Úkoly, které nebyly dokončeny, se buď vrátí do backlogu, nebo se škrtají ze schématu.
- Kanban nepodporuje multitasking, což omezuje počet procesů pro každého vykonavatele.
- Dokončená práce je lepší než několik zahájených úkolů.
- Druhou práci je možné převzít, pokud je první blokována.
- Čas na provedení úkolu musí být vyvážen. Příliš krátký termín může ovlivnit kvalitu. Příliš dlouhý limit vyčerpává zdroje týmu a zvyšuje náklady na procesy.
Proč je Kanban tabule používána všude místo například tabletů nebo velkých monitorů? Zastánci systému odpovídají na tuto otázku tím, že běžná tabule má dvě výhody: je jednoduchá a poskytuje vizuální kontrolu. Je snadné na ní provádět úpravy a podporuje taktilní a sociální interakci mezi členy týmu.
Výhody a nevýhody Kanban
Kanban má následující výhody:
- Flexibilita v plánování. Tým se zaměřuje pouze na aktuální práci, přičemž prioritu úkolů stanovuje manažer.
- Vysoká angažovanost týmu v procesu vývoje. Díky pravidelným schůzkám, transparentnosti procesů a příležitostem k seberealizaci se zaměstnanci spojují a projevují opravdový zájem.
- Kratší doba cyklu. Pokud potřebné dovednosti mají více lidí, trvání se zkracuje; pokud je pouze jeden člověk má, vzniká úzké místo. Zaměstnanci by proto měli sdílet znalosti a tím optimalizovat dobu cyklu. To umožňuje celému týmu pracovat na ustrnulých úkolech a obnovit plynulý tok.
- Méně úzkých míst. Limity WIP umožňují rychlou identifikaci úzkých míst a problematických oblastí vyplývajících z nedostatečné koncentrace, pracovních sil nebo dovedností.
- Viditelnost. Když mají všichni vykonavatelé přístup k datům, je snadnější odhalit úzká místa. Kanban týmy, kromě samotných karet, obvykle využívají dva běžné reporty: kontrolní diagramy a akumulativní tok.
V praxi systém vykazuje skvělé výsledky v oblastech mimo jádro výroby:
- skupiny podpory softwaru nebo help desky.
- Kanban dobře funguje při řízení startupů bez jasného plánu, ale kde dochází k aktivnímu vývoji.
Kanban má také nevýhody:
- systém špatně funguje s týmy o více než 5 lidech
- není určen pro dlouhodobé plánování.
Rozdíly od Scrum
Scrum, stejně jako agilní Kanban, je flexibilní metodologie, která se také často používá sféře IT. Rozdíly mezi nimi na první pohled nejsou zřejmé. Existuje mnoho podobností, například přítomnost backlogu v obou přístupech.
Scrum | Kanban | |
Tempo | Opakované sprinty s pevnou délkou | Kontinuální proces |
Výstup verze | Na konci každého sprintu po schválení projektovým manažerem (vlastníkem produktu) | Tok pokračuje nepřerušovaně nebo podle uvážení týmu |
Role | Vlastník produktu, Scrum master, vývojový tým | Tým vedený PM; v některých případech jsou zapojeni agilní koučové Kanban |
Klíčové metriky | Rychlost týmu | Doba realizace |
Pokud jde o přijatelnost změn | Během sprintu jsou změny nežádoucí, protože mohou vést k nesprávnému výpočtu úkolů | Změny mohou nastat kdykoli |
Příklady aplikace v IT
Přímo od Microsoftu: Debut Kanban v softwarovém vývoji
Použití principů Kanban v informačních technologiích začalo před více než 10 lety. David Anderson, jeden z hlavních propagátorů Kanban pro vývojáře softwaru, konzultoval s Microsoftem v roce 2005. Nebyli spokojeni s výkonem svého oddělení — XIT Sustained Engineering, které opravovalo chyby v interních aplikacích. Na začátku reportingového roku bylo toto oddělení nejhorší ve své divizi. Backlog překročil přijatelné rozměry pětkrát a doba zpracování jednoho požadavku byla typicky pět měsíců.
Nový PM, po konzultacích s Andersonem, zvýšil produktivitu problematického oddělení o 155% za devět měsíců. Doba zpracování byla nyní pět týdnů, backlog se vrátil na normální velikost a včasné dokončení úkolu se stabilizovalo na 90%. Všechny tyto výsledky byly dosaženy s minimálním onboardováním nových zaměstnanců; personál pokračoval v opravě chyb stejným způsobem — pouze přístupy k organizaci práce se změnily.
Zajímavý fakt: programový manažer Dragos Dumitriu, který se vydal na to, aby otočil situaci v XIT, byl uchvácen Andersonovou knihou. K jeho překvapení se setkal s ideologem programu Kanban v samotném Microsoftu, kde nastoupil právě den předtím. Dumitriu požádal Andersona o pomoc při jeho úkolu a ten souhlasil s tím, že principy své knihy uvede do praxe.Dumitriu se setkal s oddělením skládajícím se ze tří vývojářů a tří testerů, které mělo v backlogu 80 požadavků. PM byl dočasně jmenován, protože požadavky na práci zahrnovaly odborné znalosti v technologiích ASP, správě SQL Server a znalostech MS Project Server. Management představoval “techieho”, který mohl kódovat, připravit zprávy a předpovídat zátěž backlogu v této pozici. Jak se v té době věřilo, problém oddělení by se odhalil, pokud by byla shromážděna velká část dat. Dumitriu nebyl takovým “techie”.
Nicméně, když začal analyzovat operace XIT společně s Andersonem, rychle identifikoval klíčové faktory negativně ovlivňující rychlost oddělení:
- Předpověď důsledků (ROM) splnění požadavku zabralo spoustu času. Jak vývojář, tak tester musel strávit celý pracovní den provedením nezbytných výpočtů, kontrolou kódu a dokončením dokumentace. Průměrně přicházel jeden požadavek každý den. Podle výpočtů PM šlo 40% produktivity oddělení na ROM;
- Priorita byla poskytována požadavkům s vyšší hodnotou. XIT byl financován na základě hodnoty objednávky. Prioritizace požadavků byla projednávána měsíčně na schůzkách manažerů oddělení s klienty — manažery z jiných oddělení. S rostoucím backlogem při současné rychlosti, kdy bylo zpracováváno pouze 6 – 7 požadavků měsíčně, se priority dalších požadavků neustále měnily s uplynutím času. Mnoho z nich bylo odloženo na významné “později”, dokonce ani né na další měsíc.
- Ve fázi ROM bylo polovina požadavků filtrovaná. Některé byly příliš velké a přequalifikovány jako projekty k převedení do jiných oddělení, jiné byly příliš nákladné a jednoduše zrušeny. Některé požadavky nebyly brány do vývoje, protože jejich realizace by trvala příliš dlouho. Takže 40% produktivity oddělení bylo vynaloženo na analýzu požadavků, z nichž 50% bylo odmítnuto. Asi 15 – 20% pracovních zdrojů bylo zbytečně ztraceno.
- Přípravná práce na požadavcích mohla trvat měsíce před realizací. Výpočty ve fázi ROM se mohly během této doby ztratit nebo zapomenout. Zejména, pokud se realizace prováděla jiným vývojářem, než který zahájil analýzu.
Kanban řešení pro problémové oddělení Microsoftu
Na konci roku 2005 se produktivita oddělení zvýšila o 155%. Pro další zlepšení práce XIT byli přivedeni dva zaměstnanci: jeden vývojář a jeden tester. Počet požadavků v backlogu klesl na 10 a jeden vývojář pravidelně zpracovával 11 požadavků za čtvrtletí. Průměrně bylo za čtvrtletí dokončeno 56 požadavků ve srovnání s 11 dříve. Náklady na požadavky klesly ze $7500 na $2900.
Aplikace v Corbis
Po dosažení úspěchu v Microsoftu začal Anderson v roce 2006 řešit nový složitý úkol. Nyní pracoval v Corbis — další společnosti Billa Gatese, která ještě neopustila MS. Jedna z činností Corbis byla licencování fotografií. V té době to byla druhá největší knihovna stock fotografií na světě s databází asi 3,5 tisíce obrázků.
Andersonovým úkolem bylo zrychlit hlavní vydání společnosti. Interval mezi jejich vydáními byl tři měsíce a mohl se ještě prodloužit. Jen projednání plánu vydání trvalo vedení dva týdny. Bylo nutné stanovit vydání sekundárních vydání nebo aktualizací každé dva týdny. Zároveň musely být klíčové zdroje směřovány na hlavní projekt.
Na tabuli Kanban se objevila v kanceláři Corbis, kde Anderson každodenně mluvil s týmem. Cílem PM bylo zlepšit vizuální kontrolu nad procesy, podpořit seberealizaci a větší osobní odpovědnost mezi vykonavateli. Systém Kanban byl také zaměřen na snížení dohledu manažera a zvýšení produktivity.
Kromě barevných karet a grafů se na tabuli objevil také “koš na odpadky” — do kterého byly zasílány úkoly, které byly příliš velké.
Foto z oficiální prezentace
Systém Kanban pro udržovací inženýrství na softwarových systémech od Davida J Andersona
Systém Kanban objasnil, kdy tok přestává být plynulý a kde dochází k zpožděním, tzv. úzký bod. Rychlé diskuse s týmem pomohly identifikovat aktuální problémy. Například testování trvalo 3 dny, což negativně ovlivnilo plán vydání. Tři zaměstnanci se sešli a našli způsob, jak zkrátit čas na jeden den.
Úzký bod je část schématu nebo algoritmu operací společnosti, kde omezení produktivity zdrojů nebo lidí ostře snižují průchodnost toku úkolů. Nedostatek pracovních sil, špatný internet nebo ředitel na dovolené blokuje nebo zpomaluje provádění úkolů.
Limity pro kanban karty byly stanoveny empiricky dvakrát. V „připraveno pro vývoj“ byly limity zvýšeny. Také se objevil nový sloupec — „připraveno k testování“. Mnoho požadavků pro “downstream” bylo nesprávně formulováno, což způsobovalo zbytečné časové výdaje. Proto PM zkoumal operace horního toku a našel chyby.
Procedura kontroly požadavků mohla trvat 100 dní, ale vydání začala vznikat každé dva týdny, jak bylo naplánováno. Rozhodnutí o obsahu vydání byla činěna 5 dní před publikací. Praxe počítání, jak v případě oddělení XIT v Microsoftu, byla opuštěna ve prospěch produktivity. Priority úkolů byly stanoveny podle „nákladů na zpoždění“ nebo připravenosti zdrojů.
Systém Kanban nejen pomohl Andersonovi dosáhnout stanoveného cíle, ale také zlepšil morálku v týmu. Díky kolektivním diskusím a viditelnosti procesů si zaměstnanci vybudovali důvěru jednoho v druhého. Personál také přijal Kaizen, tedy praxi nepřetržitého zlepšování.
Programy a aplikace pro KANBAN
Trello
Populární systém Kanban pro správu úkolů. Vyznačuje se vizuální přitažlivostí a uživatelsky přívětivým rozhraním. Uživatelé zdůrazňují jeho super flexibilitu.
Kanbantool
Zdarma deska pro dva uživatele. Podpora API a dotykové rozhraní.
Lean Kit Kanban
Zdarma deska pro pět uživatelů s dobrými funkcemi spolupráce. Podpora API a možnosti importu/exportu, rozsáhlá statistika.
Kanbanize
Kompletně zdarma služba s příjemnou funkcionalitou. Její majitelé zaručují 300% nárůst produktivity při používání jejich produktu.
Worksection
Ukrajinská SaaS — aplikace pro rychlé sledování a řízení projektů. V současnosti, kromě účetnictví financí a termínů, existuje Ganttův diagram. V příštích měsících vývojáři přidají Kanban desku s možnostmi přizpůsobení, což službu učiní ještě vhodnější pro Kanban.
Závěr
Kanban je praktikou, která pomáhá dosáhnout úspěchu, zatímco použití pouze agilních metod není povinné. Významné změny jsou dosahovány odstraňováním zbytečného času, řízením úzkých míst a snižováním variability.
Ale úspěšné změny vyžadují čas. Nastávají postupně, zatímco odpor týmu vůči inovacím je minimální. Systém Kanban motivuje personál k zlepšení bez změn v inženýrských metodách.
Knihy pro článek poskytuje kniga.biz.ua