I mitt senaste inlägg på berättade jag om de grundläggande mätvärdena för flödet (cykeltid, genomströmning och WIP) och berättade vilka data du behöver samla in för att komma igång. Nu när du har data - hur omvandlar du dem till meningsfulla flödesmått? Du behöver bara lära dig några enkla Kanban-beräkningar. I det här inlägget berättar jag hur du beräknar cykeltiden med hjälp av start- och sluttider för arbetsmoment.
Hur man beräknar cykeltid
En av de enklaste Kanban-beräkningarna att förstå är hur man beräknar cykeltiden. En enkel definition av cykeltid är: Den totala tid som förflyter mellan när ett objekt startar och när ett objekt avslutas. En ännu bättre definition av cykeltid är: Den totala tid som ett objekt tillbringar som pågående arbete (WIP) - men mer om det i ett senare inlägg.
Observera att termen "förfluten tid" ingår i båda definitionerna. När det gäller cykeltid registrerar vi inte bara den tid som någon aktivt arbetat med ett objekt, och vi begränsar inte heller Kanban-beräkningen till normal arbetstid (t.ex. genom att ignorera nätter, helger och helgdagar - läs mer om varför här).
Kom ihåg att vi beräknar flödesmått från kundens perspektiv. Vad våra kunder bryr sig om är den totala förflutna tiden. Med denna definition är Kanban-beräkningen av cykeltiden mycket enkel:
Cykeltid = slutdatum - startdatum + 1
Du kanske undrar var "+ 1" kommer ifrån i Kanban-beräkningen ovan, det är för att ta hänsyn till objekt som börjar och slutar på samma dag. Här är ett exempel: Om du började arbeta den 1 december 15 och avslutade arbetet samma dag, är 15 - 15 = 0. Men du skulle aldrig säga att en produkt har en cykeltid på noll, eller hur? Det skulle din kund säkert aldrig säga. Logiskt sett tog det arbetet en dag att slutföra - inte noll dagar.
Men hur är det med objekt som inte börjar och slutar på samma dag? Låt oss till exempel säga att ett ärende började den 1 första januari och avslutades den 2 andra januari. Ovanstående beräkning skulle ge en cykeltid på två dagar (2 - 1 + 1 = 2). Detta är ett rimligt och realistiskt resultat som är meningsfullt ur ett kundperspektiv: Om vi meddelar att vi har en genomloppstid på en dag kan kunden förvänta sig att få sin vara samma dag. Om vi säger två dagar har de en realistisk förväntan om att de kommer att få sin vara nästa dag osv. Detta är bara ett sätt som Kanban-kalkyler kan hjälpa dig att kommunicera med dina kunder.
Cykeltid: Kanban-beräkningsexempel
För att illustrera Kanban-beräkningen ovan kan vi återgå till de exempel som fanns i mitt tidigare inlägg och nu lägga till den beräknade cykeltiden:
| ArbetsuppgiftID | Ankomst | Avgår | Cykeltid (dagar) |
| 1 | 01/01/2016 | 01/03/2016 | 3 |
| 2 | 02/02/2016 | 03/03/2016 | 31 |
| 3 | 01/02/2016 | 03/04/2016 | 63 |
Om du gör ovanstående beräkningar själv bör du få samma svar som jag. Jag försökte faktiskt först räkna i huvudet (vilket aldrig är en bra idé för mig) och fick fel på det andra och tredje svaret när jag kontrollerade med Excel. Jag hade glömt att 2016 var ett skottår!
Du kanske är orolig för att ovanstående sätt att beräkna cykeltid är fördomsfritt och att cykeltiden mäts i dagar. I verkligheten kan du ersätta dagar med vilket begrepp om "tid" som helst som är relevant i ditt sammanhang. Kanske är det veckor, timmar eller till och med sprintar. (Om du vill mäta cykeltiden i termer av sprintar för ett Scrum-team skulle beräkningen vara slutsprint - startsprint + 1.) Poängen här är att denna Kanban-kalkyl är fantastiskt generisk och passar i alla sammanhang.
Fördelar med att mäta cykeltid
Fördelarna med Kanban-beräkningen av cykeltiden kan inte nog betonas. Här är några skäl till varför det kan vara bra för Kanban-team att lära sig beräkna cykeltiden:
- Cykeltiden mäts ur kundens perspektiv, vilket ger dig ett gemensamt språk för att tala om när en produkt är klar.
- Det är lätt att börja lära sig hur man beräknar cykeltiden (du har förmodligen redan alla uppgifter du behöver).
- Själva cykeltidsberäkningen är mycket enkel och okomplicerad och ger oss en mängd information om processens övergripande prestanda.
- Beräknad cykeltid ger oss möjlighet att göra meningsfulla förutsägelser om sluttiden för enskilda objekt (jag förklarar detta närmare i ett senare inlägg).
Den sista punkten bör förtydligas lite. Det är bra att använda cykeltid för att göra förutsägelser om slutförandet av enskilda arbetsmoment, men vad händer om vi vill göra förutsägelser om slutförandet av flera arbetsmoment? Vad händer om vi har 100 objekt i vår backlog och vi vill veta när alla 100 objekt kommer att vara klara? För att besvara den frågan måste vi använda ett helt annat flödesmått, vars beräkning får vänta till nästa gång. Vad heter den mätaren? Genomströmning.
Som alltid kan du lära dig mer om hur du beräknar cykeltid och andra Kanban-beräkningar i min bok Actionable Agile Metrics for Predictability.
Tack för att du läste!
Rekommenderad läsning
Om du vill veta mer om Kanban-beräkningar kan du läsa de här resurserna:
