2.8 Lean-värdeflödesmätetal

Översikt och motivation

Varje mätetal den här delen har täckt hittills, flödestid, flödesbelastning, cykeltid, utnyttjande, härstammar från en mycket äldre verktygslåda: de fem baslinjemätningarna av klassisk Lean-värdeflödeskartläggning, utvecklad på Toyota och generaliserad över tillverkning, verksamhet, och tjänsteleverans långt innan mjukvara antog dem. Ledtid (LT) är den totala klocktiden från att arbete begärs till att det levereras. Processtid (PT) är den faktiska aktiva tiden spenderad på att arbeta med en enskild enhet. Cykeltid (CT) är den genomsnittliga tiden som krävs för att slutföra en enskild nod eller fas inom strömmen. Andel komplett och korrekt (%K/K) är procentandelen enheter ett nedströmsteam kan bearbeta utan att behöva omarbete. Takttid är den maximala acceptabla tiden att slutföra en enhet för att rent matcha kundens efterfrågan.

Det här ämnet finns eftersom mjukvaruteknik inte uppfann de här idéerna, den lånade dem, och lånet återanvände ibland samma ord för något lite olika. Den här bokens egen cykeltid (ämne 2.6) mäter en ändrings ingenjörssteg specifikt, kodning, granskning, test, driftsättning, medan Leans klassiska CT är den mer generella “genomsnittlig tid per nod” tillämpad på vilken process som helst. Flödestid (ämne 2.4) är den här bokens namn för vad Lean kallar ledtid. Att känna till kartläggningen betyder något eftersom en läsare som kommer från en Lean Six Sigma-bakgrund, vanlig inom tillverkning, logistik, sjukvård, och myndighetsverksamhet, kommer använda exakt de här termerna med sina ursprungliga betydelser, och ett mjukvaruteam som inte talar samma språk förverkar en enkel, evidensbaserad bro till kollegor utanför ingenjörsavdelningen.

För stora team är %K/K det här ämnets mest underanvända mätetal. Det fångar något flödesmätetalen i ämnen 2.3 och 2.4 inte gör: hur mycket av vad ett steg producerar som faktiskt är användbart av nästa steg utan att skickas tillbaka. Summerat över ett flerstegsvärdeflöde, ett koncept tillverkning kallar rullande genomströmningsutbyte, avslöjar %K/K hur omarbete förstärks osynligt över överlämningar, ett mönster stora företag med långa, flerteampipelines och myndighetsprogram med flera godkännandegrindar är särskilt benägna till och sällan mäter direkt.

Nyckelprinciper

De här fem mätetalen föregår mjukvara och generaliserar bortom den. De är det gemensamma vokabulär en Lean Six Sigma-utbildad intressent, vanlig inom stora företag och myndighetsverksamhet, redan talar flytande.
Terminologikrock är verklig och värd att namnge explicit. Den här bokens cykeltid (ämne 2.6) och Leans klassiska CT är relaterade men inte identiska; dokumentera kartläggningen så att tvärfunktionella konversationer inte tyst talar förbi varandra.
%K/K måste rullas upp över varje steg, inte mätas en gång i slutet. Omarbete introducerat tidigt i en ström och fångat sent är osynligt för ett mätetal mätt bara vid slutlig leverans.
Takttid omformulerar kapacitetsplanering kring efterfrågan, inte ansträngning. Frågan skiftar från “hur snabbt kan vi gå” till “hur snabbt behöver vi gå,” vilket kopplar direkt till utnyttjande (ämne 2.7) och flödesbelastning (ämne 2.4).
De här är diagnostiska mätetal, inte skenmått. Vart och ett existerar för att besvara en specifik operativ fråga, inte för att producera ett imponerande tal för en instrumentpanel.

Rekommendationer

Kartlägg ert värdeflöde med alla fem Lean-mätetal innan ni antar ett mjukvaruspecifikt ramverk

Beräkna ledtid, processtid, cykeltid, %K/K, och takttid för ett representativt urval av arbete som rör sig genom ert värdeflöde innan ni lägger på Flow Frameworks egna mätetal (ämnen 2.3 och 2.4) ovanpå. Det här ger er en baslinje vilken Lean Six Sigma-litterat intressent som helst omedelbart kan förstå, och det avslöjar ofta samma väntetidsdominans ämne 2.5 beskriver, uttryckt i ett vokabulär som föregår och överlever vilket specifikt mjukvaruramverk som helst.

Rulla upp andel komplett och korrekt multiplikativt över varje steg

Mät %K/K vid varje steg individuellt, multiplicera sedan stegnivåprocentandelarna tillsammans för att få värdeflödets rullande genomströmningsutbyte. Tre steg som var och en individuellt körs vid 90 % komplett och korrekt summeras till ungefär 73 % totalt, ett tal som inte ser ut som något enskilt stegs egen rapport och vanligtvis är det mer ärliga. Den här enda beräkningen är det snabbaste sättet att avslöja hur mycket omarbete en flerstegspipeline genuint absorberar.

Sätt takttid explicit från verklig kundefterfrågansdata, inte från kapacitet

Beräkna takttid som tillgänglig arbetstid delat med kundefterfrågan över den perioden, medvetet oberoende av hur snabbt ert team råkar kunna arbeta idag. Jämför er uppmätta processtid och cykeltid mot det här talet: en processtid bekvämt under takttid indikerar sund marginal, medan en cykeltid som överstiger takttid är konkret, kvantifierat bevis på en kapacitetsbrist, inte bara en känsla att saker ligger efter.

Dokumentera kartläggningen mellan Lean-termer och den här bokens eget vokabulär

Där er organisation redan driver ett Lean Six Sigma-program utanför mjukvara, eller där ingenjörsavdelningen rapporterar till ledning flytande i det vokabuläret, skriv ner kartläggningen explicit i er metrikstadga (ämne 1.4): den här bokens flödestid är Leans ledtid, den här bokens cykeltid (ämne 2.6) är en specifik tillämpning av Leans mer generella CT, och den här bokens aktiva tid (ämne 2.5) är Leans processtid. Det här enda dokumentet förhindrar ett återkommande, lågvärdigt argument om vems tal som är “verkliga.”

Använd %K/K som ett skydd vid sidan av flödeshastighet, inte som ett substitut för den

Para rullande genomströmningsutbyte med flödeshastighet (ämne 2.3) på samma sätt den här boken parar varje hastighetsmätetal med ett stabilitetsskydd. Ett stigande objektantal med ett fallande rullande %K/K betyder att värdeflödet levererar fler enheter som alltmer behöver omarbete senare, exakt den sortens hastighet-utan-kvalitet-mönster ämne 1.2 varnar varje mätetalsfamilj att skydda mot.

Avvägningar: fördelar och nackdelar

Tillvägagångssätt	Fördelar	Nackdelar
Bara klassiska Lean-mätetal (LT, PT, CT, %K/K, takttid)	Universellt vokabulär; fungerar över mjukvaru- och icke-mjukvaruteam lika	Inte mjukvaruspecifikt; behöver översättning för ingenjörsspecifika steg
Bara Flow Framework-mätetal (ämnen 2.3, 2.4)	Specialbyggt för mjukvaruvärdeflöden och objekttypssynlighet	Obekant för Lean Six Sigma-utbildade intressenter utanför ingenjörsavdelningen
Båda, med en explicit dokumenterad kartläggning	Talar båda vokabulären; starkaste tvärfunktionella bro	Kräver den initiala disciplinen att skriva ner kartläggningen och hålla den aktuell
%K/K mätt bara vid slutlig leverans	Enkelt, ett tal	Döljer omarbete introducerat och fångat tidigare i strömmen

Den centrala spänningen är universalitet kontra specificitet. Klassiska Lean-mätetal är omedelbart läsbara för alla med tillverknings-, verksamhets-, eller Six Sigma-erfarenhet, men de var inte designade med mjukvarans specifika steg, kodgranskning, automatiserad testning, driftsättningsgodkännande, i åtanke. Lös spänningen genom att använda Lean-mätetalen som den delade baslinjevokabulär för tvärfunktionella och ledningskonversationer, och Flow Frameworks egna mätetal (ämnen 2.3 och 2.4) för det mjukvaruspecifika diagnostiska arbetet ingenjörsteam gör dagligen.

Frågor att diskutera med ditt team

Skulle vi kunna beräkna alla fem klassiska Lean-mätetal för vårt värdeflöde idag, eller har vi bara några av dem? De flesta mjukvaruteam har flödestids- och cykeltidsekvivalenter men har aldrig beräknat processtid, %K/K, eller takttid explicit. Identifiera vilka av de fem som genuint saknas innan ni antar att glappet är litet.
Har vi någonsin rullat upp %K/K över varje steg i vårt värdeflöde, eller bara mätt det vid slutlig leverans? En enda mätning i slutet av strömmen döljer exakt det förstärkande omarbete det här ämnets rullande genomströmningsutbyte-beräkning är designad för att avslöja. Försök upprullningsberäkningen med verklig data.
Vet vi vår takttid, beräknad från faktisk kundefterfrågan, och hur jämförs vår uppmätta cykeltid mot den? De flesta team har aldrig gjort den här jämförelsen explicit, vilket betyder att kapacitetskonversationer förblir anekdotiska snarare än kvantifierade.
Om en Lean Six Sigma-utbildad intressent utanför ingenjörsavdelningen frågade om vår cykeltid, skulle vi vara säkra på att vi menar samma sak som de gör? Den här bokens cykeltid (ämne 2.6) och Leans klassiska CT är relaterade men inte identiska. Diskutera om den distinktionen någonsin orsakat ett verkligt missförstånd i er organisation.
Har vårt rullande genomströmningsutbyte någonsin varit meningsfullt lägre än något enskilt stegs egen rapporterade %K/K? Om ni aldrig har beräknat upprullningen, diskutera vad ni skulle förvänta er att finna och kontrollera det sedan mot verklig data.
Driver vår organisation redan ett Lean- eller Six Sigma-program utanför mjukvara vi skulle kunna anpassa oss till istället för att underhålla ett separat, frikopplat vokabulär? Många stora företag och myndigheter har redan den här infrastrukturen; kontrollera om ingenjörsavdelningen någonsin faktiskt har kopplat till den.

Sektorperspektiv

Startup. Full Lean-värdeflödeskartläggning är sällan värd ceremonin på den här skalan, men takttid är värd att förstå informellt: att veta ungefär hur snabbt teamet genuint behöver röra sig för att matcha verklig kundefterfrågan, snarare än ett godtyckligt internt tempo, förhindrar både att bygga kapacitet för tidigt och att underbygga den när tillväxt anländer.

Litet företag. %K/K är det mest omedelbart användbara av de fem mätetalen här, eftersom det direkt besvarar “hur mycket av vad vi levererar behöver göras om,” en fråga ägare och små team känner akut utan att alltid ha ett tal kopplat till det. Spåra det informellt för er en eller två kritiska processer innan ni investerar i något mer utarbetat.

Stort företag. Det här är där det klassiska Lean-vokabuläret tjänar sin plats, eftersom stora företag mycket ofta redan driver ett Lean Six Sigma-program inom verksamhet, tillverkningsnärliggande divisioner, eller delade tjänster, och en ingenjörsavdelning som talar samma språk vinner en omedelbar, trovärdig bro till de funktionerna snarare än att behöva motivera en separat, bara-mjukvaru-mätetalsuppsättning från grunden.

Myndighet. Myndigheter, särskilt de med rötter inom regulatoriska, tillverkningsnärliggande, eller logistikfunktioner, har frekvent befintliga Lean- eller processförbättringsmandat. Att formulera en digital tjänsts värdeflöde i samma klassiska termer, ledtid, processtid, %K/K, takttid, som ett myndighetskontors processförbättringskontor redan använder är ofta det snabbaste sättet att säkra genuint institutionellt stöd för en mjukvarumoderniseringsinsats.

Exempel

Stort företag. Ett tillverkningsbolags interna mjukvarudivision hade kämpat i åratal för att få sina ingenjörsmätetal tagna på allvar av en verksamhetsledningsgrupp flytande i Lean Six Sigma från fabriksgolvet. Att omformulera divisionens leveranspipeline med samma fem klassiska mätetal, att beräkna ledtid, processtid, cykeltid, %K/K, och takttid för dess mjukvaruvärdeflöde, gjorde omedelbart divisionens tal läsbara för verksamhetsledningen för första gången. En rullande genomströmningsutbyte-beräkning över pipelinens fyra steg avslöjade en faktisk %K/K på 61 %, långt under något enskilt stegs egen rapporterade tal, vilket blev bevisgrunden för ett omarbetsreduktionsinitiativ verksamhetsledningen finansierade inom samma kvartal.

Myndighet. Ett delstatligt transportdepartements digitala tillståndsteam, som rapporterade till en myndighet med ett långvarigt Lean-processförbättringskontor, hade aldrig engagerat det kontoret eftersom dess egna mätetal använde mjukvaruspecifikt språk kontoret inte kände igen. Efter att ha översatt tillståndsvärdeflödet till ledtid, processtid, och %K/K, identifierade processförbättringskontoret att teamets verkliga begränsning inte var ingenjörshastighet utan ett nedströms juridiskt granskningssteg som kördes långt under sin egen effektiva takttid relativt tillståndsefterfrågan, ett fynd kontoret var utrustat att agera på omedelbart eftersom det var formulerat i bekanta termer.

Verksamhetsnytta: motiv, ROI och TCO

Avkastningen på att anta klassiskt Lean-vokabulär vid sidan av den här bokens mjukvaruspecifika mätetal är en trovärdig, omedelbar bro till processförbättringsexpertis och finansiering som ofta redan existerar någon annanstans i en stor organisation. Tillverkningsbolagsexemplet ovan, att säkra omarbetsreduktionsfinansiering samma kvartal omformuleringen gjorde fallet läsbart, är mönstret det här ämnets tillvägagångssätt tillförlitligt producerar: insikten var inte ny, men vokabulären som gjorde den handlingsbar för rätt publik var det.

Den totala ägandekostnaden är låg: de här fem mätetalen kräver ingen ny instrumentering utöver vad ämnen 2.4 till 2.6 redan samlar in, plus en %K/K-omarbetsklassificering som vanligtvis är en enkel tillägg till befintlig defekt- och flödesobjektsspårning (ämne 2.2). Den huvudsakliga investeringen är översättning, att skriva ner kartläggningen mellan den här bokens termer och Leans klassiska, vilket betalar för sig själv första gången det förhindrar ett tvärfunktionellt missförstånd.

Antimönster och fallgropar

Att mäta %K/K bara vid slutlig leverans: manipuleringsvektorn i hjärtat av det här ämnet. Ett team kan rapportera en hög slutstegs-%K/K medan tidigare steg tyst producerar omarbete som fixas innan någon mäter det, vilket får hela värdeflödet att se sundare ut än det är. Skyddet är att rulla upp %K/K multiplikativt över varje steg, den rullande genomströmningsutbyte-beräkningen, och granska varje stegs definition av “komplett och korrekt” periodiskt så att den inte kan smalna tyst över tid.
Att anta att den här bokens cykeltid och Leans klassiska CT betyder exakt samma sak: producerar verklig tvärfunktionell förvirring när de två vokabulären möts utan en dokumenterad kartläggning.
Att sätta takttid från nuvarande kapacitet istället för verklig kundefterfrågan: besegrar syftet med mätetalet, vilket är att avslöja ett gap mellan efterfrågan och kapacitet, inte att bekräfta vilket tempo som helst som redan existerar.
Att behandla klassiska Lean-mätetal som föråldrade när ett mjukvaruspecifikt ramverk antagits: kastar bort en trovärdig, evidensbaserad bro till processförbättringsexpertis som kan redan existera i organisationen.
Att ignorera ett befintligt Lean Six Sigma-program någon annanstans i organisationen: förverkar finansiering, expertis, och institutionell trovärdighet som omformulering av leveransmätetal i delat språk kunde låsa upp.
Att rapportera %K/K utan att para det mot flödeshastighet: tillåter ett stigande genomströmningstal att dölja en fallande omarbetsfrekvens, samma skyddsgap den här boken varnar mot tvärsigenom.

Mognadsmodell

Nivå 1, Initiera: Inget av de fem klassiska Lean-mätetalen beräknas; leverans diskuteras utan referens till ledtid, processtid, eller %K/K.
Nivå 2, Utveckla: Ledtid och cykeltid spåras informellt, men processtid, %K/K, och takttid beräknas inte, och ingen kartläggning till den här bokens eget vokabulär existerar.
Nivå 3, Standardisera: Alla fem klassiska mätetal beräknas konsekvent, och kartläggningen till den här bokens flödes- och cykeltidsvokabulär dokumenteras i en delad metrikstadga.
Nivå 4, Hantera: Rullande genomströmningsutbyte beräknas över varje steg i värdeflödet, och takttid jämförs mot uppmätt cykeltid för att kvantifiera kapacitetsgap explicit.
Nivå 5, Orkestrera: Organisationen har kopplat sina mjukvaruleveransmätetal till ett befintligt Lean- eller Six Sigma-program någon annanstans i verksamheten, och kan peka på specifika investerings- eller processbeslut fattade eftersom det delade vokabulären gjorde en insikt handlingsbar för en icke-ingenjörspublik.

Diskussionsidéer

Skulle vi kunna beräkna ledtid, processtid, cykeltid, %K/K, och takttid för vårt värdeflöde idag?
Vad skulle vårt rullande genomströmningsutbyte vara om vi multiplicerade varje stegs %K/K tillsammans?
Driver vår organisation redan ett Lean- eller Six Sigma-program vi aldrig kopplat ingenjörsmätetal till?
Hur jämförs vår uppmätta cykeltid mot vår takttid, beräknad från verklig kundefterfrågan?

Viktiga slutsatser

De fem klassiska Lean-mätetalen, ledtid, processtid, cykeltid, andel komplett och korrekt, och takttid, föregår mjukvara och förblir det gemensamma vokabulär hos Lean Six Sigma-utbildade intressenter.
Den här bokens egen flödestid och cykeltid kartlägger till, men är inte identiska med, Leans ledtid och klassiska CT; dokumentera kartläggningen explicit för att undvika tvärfunktionell förvirring.
Ämnets centrala manipuleringsvektor är att mäta %K/K bara vid slutlig leverans; skyddet är att rulla upp det multiplikativt över varje steg som rullande genomströmningsutbyte.
Takttid omformulerar kapacitet kring verklig kundefterfrågan, inte befintligt tempo, och paras direkt med utnyttjande (ämne 2.7) och flödesbelastning (ämne 2.4).
Att omformulera mjukvaruleverans i klassiska Lean-termer är ofta det snabbaste sättet att koppla till befintlig processförbättringsexpertis och finansiering redan närvarande i en stor organisation.

Källor och vidare läsning

Rother, Mike, and John Shook. Learning to See: Value Stream Mapping to Create Value and Eliminate Muda. Lean Enterprise Institute, 1999.
Womack, James P., and Daniel T. Jones. Lean Thinking: Banish Waste and Create Wealth in Your Corporation. Free Press, 1996.
Womack, James P., Daniel T. Jones, and Daniel Roos. The Machine That Changed the World. Free Press, 1990.
George, Michael L. Lean Six Sigma for Service: How to Use Lean Speed and Six Sigma Quality to Improve Services and Transactions. McGraw-Hill, 2003.
Ohno, Taiichi. Toyota Production System: Beyond Large-Scale Production. Productivity Press, 1988.