Lean för mjukvara på 10 minuter

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn
Lean handlar om att bli snabb genom att sluta göra onödiga saker.

Lean ser det som vi producerar som ett arbetsflöde. Ett arbetsflöde startar med en idé som en kund vill ha gjort, och slutar med leverans till kunden, från Concept to Cash. Lean strävar efter att ta bort allt onödigt som sinkar och stör detta arbetsflöde så att tiden det tar från beställning till leverans är så kort som möjligt.


Lean handlar om att minimera tiden från att vi har en idé/beställning till vi har producerat det som någon är beredd att betala för.
Cykeltiden är hur lång tid det tar från det att en kund kommer med ett önskemål, tills dess att hon fått det levererat (och är beredd att betala för det).

För att kunna optimera cykeltiden kikar man på vilka flaskhalsar och köer som finns i arbetsflödena i en organisation.

Ett enkelt sätt att hitta de flaskhalsar man har är att kika på var vi har saker på hög, var är våra köer? En kö bildas alltid före en flaskhals.

Efter en kö finns det alltid en flaskhals.


Var någonstans ligger halvfärdiga saker på hög? Ligger de i bugghanteringssystem, orderhanteringssystem, otestad mjukvara eller i kravspecifikationer? Vilken flaskhals är det som kommer direkt efter denna hög?

Lean handlar om att identifiera dessa flaskhalsar, se till att de försvinner och skapa ett jämt flöde. Ett flöde som därigenom på kortast möjliga tid och med minsta möjliga resursåtgång levererar det kunden vill ha.

Lean värdesätter det som levereras och inte det som påbörjas. Att få saker ur händerna istället för att jobba hårt.

Många företag arbetar enligt filosofin att hela företaget går bra om alla delar arbetar effektivt och hårt. Lean optimerar istället på helheten och mäter cykeltiden, from concept to cash, vilket inte nödvändigtvis är samma sak. Låt oss ta ett exempel. Här nedan är en ögonblicksbild av ett arbetsflöde.

Vi har tre stationer. Vid varje station arbetar man optimalt och hårt. Trots det ligger saker i kö. Vi har station A där det i genomsnitt tar 1,5h att genomföra en sak, och där det för närvarande ligger 3 saker i kö och väntar. Station B där man är två som arbetar och är överbemannad och därför inte har någon kö, och det tar i genomsnitt 1/2h att göra en sak. Station C där det tar 2h att göra en sak i snitt och det ligger 3 saker i kö.

Låt oss säga att alla arbetar heltid. Då har vi en arbetstid på 160h i veckan (4 personer á 40 h). Vi slutför 20 saker i veckan eftersom sista stationen C levererar en sak varannan timme. I genomsnitt tar det 14,5h från start till mål att utföra en sak (summan av hur länge en sak ligger i kö + göra tid). Antal saker som vi samtidigt arbetar med är 9 vilket är alla saker vi arbetar med plus de saker som ligger halvfärdiga i olika köer (4+1+4).

Arbetstid 160 h
Tid genom systemet 14,5 h
Levererade saker i veckan 20 st
Antal saker på gång samtidigt 9 st

Låt oss nu begränsa mängden som vi arbetar genom att anpassa oss efter flaskhalsen, station C. Vi tillåter helt enkelt inte att A och B producerar så länge det finns en kö i C utan tvingar dem till att vila.

Vi har nu den totala arbetstiden fortfarande 160h, men utav den vilar vi i stationerna A och B totalt 70h (10h + 2*30h) per vecka  och vi producerar fortfarande 20 saker i veckan. Däremot har vi färre saker i systemet, nu endast 3 saker åt gången (inga köer). Tiden det tar från att vi börjar med något tills det är klart för leverans har sjunkit från 14,5h till 4.

Med köer Utan köer
Arbetstid 160 h 160 h
Tid genom systemet 14,5h  4 h (mer än tre gånger så fort)
Levererade saker i veckan 20 st 20 st
Antal saker på gång samtidigt 9 3 (en tredjedel)

Om vi låter flaskhalsen styra hur mycket var och en ska producera får vi alltså

  • Lika mycket levererat
  • Leverans till kunden tre gånger så fort
  • Färre saker att hålla reda på

Pausa lite här och reflektera, detta är inte intuitivt: Genom att jobba mindre levererar vi snabbare!

Men vi slutar inte med detta, låt oss optimera flödet. Vi har ju två personer på station B som inte behöver vara fler än en. Vi flyttar en av dem till flaskhalsen C och ser vad vi får för resultat.

Nu har vi fortfarande 160 timmars arbetstid men tiden att inte göra något gäller nu B och C medan A går för fullt. A är alltså den nya flaskhalsen som bestämmer hur mycket som produceras. Då den blir klar med en sak på 1,5h så blir antal levererade saker per vecka 40/1,5 = 27. Tid genom systemet är 3,5 timme och antal saker som man arbetar på är fortfarande 3.

Med köer Utan köer Optimerat utan köer
Arbetstid 160 h 160 h 160 h
Tid genom systemet 14,5h 4 h (tre gånger så fort) 3,5h (ytterligare lite snabbare)
Levererade saker i veckan 20 20 27 (35 % förbättring)
Antal saker igång samtidigt 9 3 (mindre än hälften) 3 (oförändrat)

Efter att ha identifierat flaskhalsen och åtgärdat den har vi alltså ökat det vi levererar med 35% och jämfört med vårt utgångspunkt levererar vi fyra gånger så fort.

För att sammanfatta strategin ovan

  1. Begränsa arbetet som var och en gör så att igen producerar mer saker än vad som behövs i det totala flödet (limit work to capacity).
  2. Identifiera flaskhalsen.
  3. Åtgärda flaskhalsen

Lean handlar om att få detta att fungera.

Exemplet ovan är taget från typiskt fabriksarbete, men om man ser sakerna som för sig i flödet som en funktion som ska läggas till i en mjukvara, där station A kan vara någon form av krav analys, station B kodning och C testning så stämmer resonemanget även inom andra områden. Om du vill se ett sådant flöde i praktiken, gå in på en lunchrestaurang i rusning, till exempel Subway.

Leave a Reply

Your email address will not be published. Required fields are marked *