Nyligen pratade jag och en grupp av mina Planview AgilePlace-medarbetare om Kanban. Den urgamla debatten om definitionerna av ledtid och cykeltid kom upp och vi rullade alla lite med ögonen. Lean-communityt har redan diskuterat detta ämne en miljon gånger, men det verkar som om vi fortfarande inte kan nå enighet. Ämnet kan vara förvirrande för dem som är nya i Kanban och frustrerar alltid erfarna utövare. I det här inlägget förklarar jag varför dessa definitioner ofta debatteras. Jag förklarar också hur en enkel definition kan hjälpa dig att få ut det mesta av dessa Lean-mått.
När börjar klockan?
Debatten om ledtid och cykeltid handlar i huvudsak om följande: När börjar klockan?
Personer som inte känner till Kanban tror ofta att ledtid är tiden mellan det att en arbetsuppgift begärs och det att arbetet faktiskt påbörjas.
Den mer allmänt accepterade idén är att ledtiden börjar med en begäran från en kund och slutar när värdet levereras till kunden.
Men vad är en begäran? I traditionell Lean-tillverkning representerar en begäran en kundorder för en fysisk produkt.
I kunskapsarbete kan en begäran vara mycket mer immateriell: För att använda ett exempel från programvaruutveckling kan det vara en obekräftad idé till en funktion. Den idén kan behöva gå igenom en prioriteringsprocess innan den ens hamnar i teamets backlog. Frågan blir då: Började klockan ticka - när vi fick idén eller när den lades till i backloggen?
Det är då som definitionen av ledtid och cykeltid kan bli knepig. Termerna används ofta synonymt. När detta sker förlorar de bakomliggande mätvärdena sin betydelse.
Därför har vissa människor ersatt termen ledtid med mer specifika termer: kundledtid, till exempel, eller systemledtid. Detta klargör exakt vad som mäts och för vem.
Istället för att brottas med dessa skillnader bör du börja med grunderna. Fråga dig själv: Vilket problem försöker jag lösa med dessa mätvärden?
Med alla mätvärden ska du först fråga "varför?".
Jag ställde den här frågan till mina medarbetare under vårt samtal. En av dem sa: "Vi behöver veta cykeltiden så att vi vet hur snabbt vi kan producera något."
"Okej", sa jag, "varför?"
Detta gav upphov till flera förvirrade blickar, men jag fortsatte: "Oavsett hur man definierar dem är ledtid och cykeltid mått. Vi slösar tid på att diskutera vad exakt de mäter.
Låt oss ta ett steg tillbaka och fråga oss varför vi vill veta den här informationen överhuvudtaget."
Den diskussion som följde var mycket mer produktiv. Vi var alla överens om att vi ville ha denna information för att kunna göra bättre förutsägelser om vårt arbete.
Ett exempel
Låt oss säga att en begäran om en ny produktfunktion kommer in från försäljningen. Logiskt sett är den första frågan som säljare ställer: "När kan jag förvänta mig att den här funktionen ska vara klar?".
Du kan uppskatta att funktionen kan ta ungefär 10 dagar. Men ska försäljningen förvänta sig att se funktionen om 10 dagar? Nej.
Varför? Eftersom deras begäran prioriteras tillsammans med alla andra aktuella begäranden.
Varför? Deras begäran prioriteras tillsammans med alla andra aktuella begäranden. Om vår genomsnittliga tid från begäran till leverans (ledtid) är 10 dagar, och det finns 4 artiklar i kön före denna nya begäran från försäljningen, kan vi förutse att begäran sannolikt kommer att levereras inom 50 dagar. (10 dagar per funktion, gånger fem.)
Observera: Vi måste vara försiktiga med dessa typer av prognoser eftersom ett genomsnitt inte alltid återspeglar den variation som är vanlig i kunskapsarbete.
Hur vi definierar ledtider och cykeltider
Lead Time
På Planview AgilePlace definierar vi ledtid som den tid som förflyter från det att en begäran görs till dess att den levereras till kunden. Vi använder ofta termen "kundledtid" för att påminna oss själva om att mätningen sker ur kundens perspektiv.
Naturligtvis kan vi inte börja med alla arbeten så fort vi får en begäran. Det skulle vara ohållbart, för att inte tala om oklokt. När en förfrågan görs, tillbringar den vanligtvis en tid i backloggen innan något arbete utförs på den. För att optimera vårt arbete måste vi titta på en mer detaljerad mätning. Därför är det värdefullt att mäta både ledtid, som beskrivs ovan, och cykeltid.
Cycle Time
Cykeltid är den tid som förflyter från det att arbetet med en begäran påbörjas till dess att den levereras till slutkunden. Cykeltiden mäter all aktiv (värdehöjande) arbetstid samt väntetiderna mellan de aktiva arbetstiderna. Det är bra att mäta cykeltiden för att få en förståelse för hur effektivt ditt system fungerar. Daniel Vacanti har just publicerat ett utmärkt inlägg på om hur man beräknar cykeltiden.
Processcykeltider
För att få ännu mer detaljerade uppgifter kan det vara bra att även analysera cykeltiden för enskilda processer. Om du till exempel vill veta hur effektivt ditt team tar sig igenom steget "design" kan du mäta designcykeltiden. När det gäller cykeltid för konstruktion skulle klockan börja när arbetet kom in i konstruktionsfilen och sluta när det gick vidare till nästa fil. Genom att mäta designcykeltiden för flera arbetsmoment kan du få en uppfattning om hur lång tid det tar för arbetet att gå igenom designsteget.
Om du optimerar varje steg så mycket som möjligt och den totala cykeltiden fortfarande är långsam kan det finnas en enkel förklaring: Överlämningar. I de flesta system ligger den största delen av avfallet i väntetiderna mellan stegen - inte i själva stegen. Genom att mäta individuella cykeltider kan du identifiera långsamma överlämningar och andra hinder för flödet.
Att använda mätvärden på ett klokt sätt
Ledtid och cykeltid kan hjälpa oss att förutse när objekt i våra backlogs kan komma att slutföras. Detta hjälper oss att kommunicera effektivare med våra intressenter.
Genom att undersöka processens cykeltider kan vi identifiera möjligheter att förbättra flödet. Kortare cykeltider innebär bättre flöden, vilket innebär att vi kan leverera snabbare till våra kunder.
Vi måste vara försiktiga så att våra ansträngningar för att minska ledtiden och cykeltiden inte leder till negativa effekter i andra delar av verksamheten (produktkvalitet, kundnöjdhet osv.). Hur snabbt artiklar flödar genom vår process är bara en indikator på hur väl vi levererar och bör balanseras på lämpligt sätt med andra viktiga mätvärden. Läs mer om farorna med vanity metrics på i detta inlägg.
När vi inte längre diskuterar termer utan ser varför dessa mått är viktiga kan vi börja använda dem effektivt i våra team. Om vi kan ändra konversationen från "vad" till "varför" kan vi börja fokusera på det som verkligen är viktigt: att förbättra leveransen av värde till våra kunder.
