Agile Lifecycle Management

Implementing practises that increase agility in collaborations is most often a good thing. However, there are two problems with the most popular approaches of today:

1. they focus on only one category of services: services that are based around an IT asset,
2. they focus on only one part of the service lifecycle: the development.

This is understandable since IT solutions are complex, especially when developing them. During IT development new insights are constantly being made, so a collaboration framework that facilitates rapid knowledge sharing, restructuring, and replanning (such as Scrum and the like) is a valuable tool. It is just that this could be said about all kind of services, and it could be said about other parts of the lifecycle, like deployment or operation, as well.

Lifecycle management frameworks like ITIL aims to point out not only what is needed during development but during other parts too. In them, there are elements one recognize from the lean and agile family of practises such as continuous improvement and cross functional collaboration. But when trying to implement them in a lean and agile fashion, there are always many "BUT" you need to say:

— "Yes, there is a CSF/KPI there that says that reducing the number of change requests is a good thing BUT if you think about it: a good change request is really a new insight about how we could be better at attending people's needs, so we should in fact increase the flow of change request instead while improving our capability to deal with them!"

— "Yes, there are descriptions there that separates the group that makes strategic decisions from the group that makes more tactical or operational decisions BUT that doesn't mean that it can't be the same people in them! Or that the mandate to make the decisions can't be delegated!"

— "Yes, there are requirements that there should be a document for each request BUT please note that a small sticky note on a whiteboard is a document that can meet all the formal requirements. Yes, the processes must be documented, BUT don't you agree that a hand-drawn poster on the wall explaining how you do things is a document even though it doesn't sit in a binder on a shelf (where no one sees it)?"

The number of "BUT"s is above any reasonable limit. Both I and other lean and agile guides have come to the conclusion that it is time for expressing what lifecycle management means when doing it the agile way. We need to have a set of organisational patterns we can point at, without having to tweak models that come from a fundamentally different management tradition.

It needs to be a pattern collection. Organisational patterns works just as design patterns: they aren't blue prints or rules but suggestions on how to organize things, given that things already are in a certain way. What suits your organisation is situational. The correct answer is always: "It depends!" and patterns aim to explain on what.

It needs to be free. People should be allowed to use, reuse, teach, and build upon the patterns. No trademark, no proprietary control, no over-prices certifications, manuals, or consultants.

It needs to have a name, maybe even from a clever acronym. I propose ALMA: Agile Lifecycle Management Anatomy. "Anatomy" since organisations are organic, and "Alma" since it is a name that means something along the lines of "sweet and soft soul".

Stay tuned, I will soon post some of my favourite ALMA patterns.

Utveckling är bara en liten del

Tjänsteperspektivet handlar om tjänsters (till exempel IT-tjänsters) hela livscykel. Alltså från att man designar tjänsten till att man driftsätter den, har den i bruk, förändrar den under resans gång, och slutligen avvecklar den. Det här helhetsperspektivet är något som ibland glöms bort, vilket kostar enorma summor och orsakar många sura miner.

Agila metoder uppkom bland systemutvecklare och används ofta i systemutveckling, vilket har gjort att ramverken har en slagsida åt just utvecklings- och förbättringsdelen i livscykeln. Men förbättring utgör kanske bara en tiondel av tjänstens hela livscykel. Att skapa agilitet i själva utvecklingssteget (som Scrum, LeSS, SAFe med flera ramverk försöker göra) är en bra början, men om man inte ser till hela livscykeln blir det suboptimering.

Det har troligen att göra med att tjänstedesign (som ju systemutveckling i grund och botten är) är så osäkert och komplext. Tidigt försökte man hantera komplexiteten och osäkerheten med projektmodeller, och det innebar att man började se på utveckling som en aktivitet avskiljd från andra aktiviteter. Utvecklingen sågs som det svåra problemet, och även om agila metoder (=iterativ utveckling i små steg med ständig omplanering) börjat ersätta projektmetoderna (=sekventiell utveckling i stora steg utifrån låsta planer) så har man ofta behållit avgränsningen att problemet gäller systemutveckling och inget annat.

Men att utveckling är svårt beror till stor del på att det är svårt eller omöjligt att förutse hur en viss lösning kommer att bete sig i verkligheten, när den väl är driftsatt. Kunskapen om hur de olika aktörerna påverkas av den framtida lösningen är som sämst när man behöver den som bäst, i början av en utvecklingscykel.

Det är alltså i drift som vi får reda på vad som krävs av lösningen. Det är i drift som lösningen kostar och skapar värde, hindrar och möjliggör. Den process i livscykeln vi bör optimera på är alltså den process som i drift snabbt och smidigt identifierar en förbättringsmöjlighet, designar en förändring som antas förverkliga möjligheten, driftsätter den, och utvärderar om antagandet var rätt.

Designsteget är viktigt, men bör inte vara så komplicerat. Så länge som vi i projektmodellerna vill hantera stora sjok av förbättringar som driftsätts sällan, så sker hypotesprövningen ute i verkligheten alldeles för sällan. De agila metoderna är mer anpassade för korta cykler med små och täta uppdateringar, men så länge som vi använder de agila metoderna enbart som en komponent inom projektcentriska styrmodeller kommer vi ändå inte att få ett agilare samspel och bättre lösningar snabbare.

Förvaltningsmodeller som PM3 och ITIL har ett livscykelperspektiv (till den grad att de ofta får en slagsida åt drift och produktion). De agila teknikerna har stor potential att passa inom förvaltningsmodeller. Tyvärr tenderar dagens förvaltningsmodeller ha stora element av projekttänkande i sin syn på utveckling/design, och dessutom tillämpas de ofta på ett alldeles för byråkratiskt sätt.

Jag tror att det som behövs är en ny formulering av förvaltningsmodellerna, där man behåller och förfinar det som fungerar smidigt, medan man låter bli det trögrörliga. Jag tror att vi behöver formulera agil tjänsteförvaltning.

Agil organisationsfilosofi i tre punkter

Kan väl göra tre reflektioner runt den agila organisationen också, som komplement till tankarna om ledarskapet:

Attityden

Det agila manifestet börjar med att tala om att människor och deras samspel är det centrala. Inte våra processer, verktyg, eller organisationskartor. En organisationskarta kan dra upp linjer mellan människor som berättar för oss hur dessa människors formella maktförhållanden ser ut. Men den berättar inte om hur de skapar värde tillsammans. Säger inget om hur de faktiskt interagerar.

När man tittar på hur folk faktiskt samspelar med varandra blir bilden mer komplex. Det sker kommunikation åt alla håll. I en agil organisation, en som snabbt och flexibelt kan anpassa sig efter ändrade förutsättningar, där måste kommunikationen och samspelet vara gott och präglat av lyhördhet.

Vi förväntar oss vissa attityder av varandra, och vi försöker undvika andra attityder. Lite förenklat kan man säga att vi i agila organisationer förväntar oss attityder som hjälper våra hjärnor att komma i "approach"-läge: vi gör oss öppna, lugna, nyfikna, engagerade, utforskande, empatiskt lyssnande, bekräftande, inkluderande. Vi undviker attityder och uttryck som försätter våra hjärnor i "avoid"-läge: rädsla, hot, svartvitt tänkande, aggression, bortkoppling, undvikande, exklusion.

Värdeströmmen

En organisationskarta tittar på avdelningar och maktförhållande. Men värdet i en organisation skapas oftast inte inom en avdelning utan i ett samspel som skär på tvärs genom alla avdelningsgränser och maktnivåer. Sådana samspel som resulterar i ett värde för en kund eller annan mottagare kallar vi "värdeströmmar".

I alla organisationer som sysslar med lean i någon form så organiserar man sig runt värdeströmmarna. Det är inte våra avdelningar och andra småpåvedömen i organisationen som är de viktiga. Mottagaren av det vi skapar bryr sig inte om dem. Mottagaren bryr sig om att vi levererar ett gott värde. Därför är det värdeströmmarna som är de viktigaste. Allt annat är bara en struktur för att underlätta värdeskapandet.

Många lean-organisationer sysslar med produktion där värdeströmmarna är ganska rigida och fasta. Det som utmärker den agila (=lättrörliga) organisationen är att folk är duktiga på att snabbt formera sig runt nya värdeströmmar: designa och driftsätta dem snabbt och snabbt komma in produktionen. Detta åstadkommer vi genom att ha ett ständigt pågående förbättringsarbete som tränar oss i att hantera förändring, genom att vara duktiga på att kommunicera så att vi snabbt kan svärma runt nya värdeströmmar, och genom att vi alla har stor beslutsmakt och förmåga att hantera de besluten.

Inre och yttre gruppkontrakt

Som jag skrev i den förra posten handlar mycket om gruppen och gruppens ansvar och förmågor. När vi tittar på värdeströmmen ser vi att delar av den löper inom en grupp, och att den ofta också löper mellan grupper. Den agila organisationen hanterar bägge fallen.

Den agila gruppen har ett ständigt pågående samtal om hur de själva arbetar och vad de förväntar sig av varandra. Ofta formaliserar de delar av dessa förväntningar (och om organisationen arbetar med känsliga saker där kraven på spårbarhet är höga så är de noga med versionshanteringa av dessa kontrakt, alla ska veta vad som gällde vid en viss tidpunkt).

Agila grupper som samarbetar om värdeflöden har också ett ständigt pågående samtal om sina förväntningar sinsemellan. Ofta försöker man undvika hårda överlämningar mellan grupperna och istället undersöka hur medlemmar av bägge grupper kan samarbeta om arbetspaketen i värdeflödet i en mjuk överlämning. Även här gäller att kontrakten mellan grupperna mycket väl kan formaliseras på olika sätt. Kom bara ihåg att vi formaliserar mål och delmål hellre än aktiviteter och arbetsuppgifter.

Detta att bara titta på hur man arbetar inom gruppen och mellan grupper, det gör att agil organisationsfilosofi inte har någon preferens för hur organisationen ska se ut. Vi kan lika gärna tänka oss en klassisk pyramidorganisation som olika typer av cirkelorganisationer, till exempel sociokratiska eller holakratiska. Organisationsstrukturen handlar om hur mandaten fördelas. Vi är mer intresserade av att konstatera att mandaten har fördelats, och så arbetar vi utifrån det.

Agil ledarfilosofi i tre punkter

Skriver ett material som berör agil ledarfilosofi och kommer på tre saker som är typiska för agilt ledarskap:

Ansvar formuleras som mål

Mål (goals/targets) är förväntade sluttillstånd, medan aktiviteter och uppgifter är steg på vägen dit.

För att värdeflödena mellan delar av en organisation ska vara smidiga krävs det att varje del gör sin bit. Att materialet i flödet har vissa egenskaper innan det kan föras vidare till nästa steg. Men för värdeflödet är det oftast inte intressant exakt hur materialet fick sina egenskaper. Bara att det har det.

Är ni ansvariga för en del av värdeflödet som innebär överlämning, så är det en viktig fråga att ta reda på vilka kraven är på materialet som ni drar till er, och vilka kraven är på materialet andra drar ifrån er. Fokus ligger först och främst på utgångsläget och måltillståndet för er del. Det utforskar ni tillsammans med dem som ni har överlämningar till och ifrån.

Sedan blir det intressant med vilka aktiviteter ni behöver utföra för att uppnå målet. I en agil organisation har ni stora friheter att experimentera er fram i utförandet. Ert ansvar är oftast inte att exakt utföra olika handlingar, utan att uppnå vissa resultat.

Ansvar tilldelas breda grupper

Att tilldela ansvar åt enskilda personer eller individuella roller skapar bräckliga organisationer. Tillhör ansvaret en enskild individ faller det när den enskilda individen fallerar. Tillhör ansvaret en individuell roll kan ett bemanningsschema se till att rollen inte fallerar, men det gör det fortfarande svårt att förbättra organisationen lokalt eller att smidigt dela på ansvaren mellan olika personer i takt med att belastningen varierar.

Det agila alternativet är att tilldela ansvar åt en grupp människor. Inte för stor grupp, för då får man ansvarsutspädning där allas ansvar blir ingens ansvar. En dryg handfull människor är lagom. Eftersom en grupp har större sammanlagd kompetens än en individ leder också det till att gruppen kan ta ett bredare ansvar än vad någon enskild skulle kunna. Det leder till plattare organisationer. Ju bredare grupp desto större ansvar, och desto bättre kvalitet på besluten.

Sedan är det smart att inom gruppen formulera både roller och bemanningsscheman som säkerställer att rollerna alltid fungerar. Det är ju ett beprövat sätt att se till att saker inte glöms bort eller att ansvar inte späs ut i en grupp. Men eftersom det är gruppen själv som äger frågan om hur de ska kunna ta ansvar, så kan gruppen ta fram ett sätt som passar, och enkelt förfina detta allt eftersom.

Grupper är fria att delegera vidare

Det ansvar man fördelar i en agil organisation är det som kallas för "accountability". Gruppen är sedan fri att delegera ansvaret ytterligare, inom sig eller åt andra, utan att kontraktet med omvärlden bryts. Men märk att det enda ansvar de kan delegera är det som på engelska kallas "responsibility". Är jag "responsible" att utföra något medan du är "accountable" och jag misslyckas, så kommer ändå omvärlden att fråga sig varför du misslyckades.

Det här ger gruppen, och flera grupper i samverkan, stora möjligheter att experimentera med arbetsformerna, utan att riskera att leveransen från systemet blir sämre. Men det är en frihet under ansvar. Det vill till att gruppen alltid har förmåga att ta sitt ansvar, att den ständigt utökar sin förmåga, och att den är i konstant dialog med sin omvärld om sina förväntningar och förmågor.

Sammanfattning

Man kan sammanfatta det ännu kortare: Bort från individuella roller, fram för ansvar åt grupper! och: Bort från arbetsbeskrivningar som del av överenskommelser med organisationens olika delar, fram för överenskomna måltillstånd! och: Gå försiktigt men hela tiden framåt!

Tjänsteperspektivet

Ännu ett vanligt chefsmisstag vid införandet av lean och agila metoder: tron att det bara handlar om att förbättra det befintliga arbetssättet på golvet. Att man inte ser behovet av ett grundläggande perspektivskifte i hela organisationen.

Det finns flera sådana grundläggande skiften i synsätt som brukar behöva äga rum, där synen på ledarskap och styrning är en av de viktigare. Men ett annat skifte som jag lite för sällan ser nämnas gäller synen på vad leveransen är. Att lean och agila metoder betydligt bättre harmonierar med en syn på leveransen som en tjänst. Jag kallar det för att organisationen måste inta ett "tjänsteperspektiv", och med det menar jag ungefär detta:

Helhetstänkande. En produkt är en produkt, en säljavdelning är en säljavdelning, och en servicetekniker är en servicetekniker. Organiserar vi oss funktionellt placerar vi produktutvecklarna i en avdelning för att de ska bedriva produktutveckling, och låter säljarna sitta i sitt hörn och fundera över säljprocesserna, medan de stackars serviceteknikerna försöker avhjälpa att produkten inte fungerar som säljarna sagt eftersom utvecklarna lagt sin energi på att göra andra aspekter av produkten bra.

Tjänsteperspektivet ser på tjänsten som en helhet. Tjänsten består visserligen av tekniska komponenter, till exempel en app eller en webb, men värdet av den sitter i den totala samverkan mellan alla delarna. Det är därför som agila metoder har de tvärfunktionella teamen som en nyckelkomponent. Det gäller att blanda perspektiven och expertiserna så att helheten blir så bra och möjligt. Tjänsteperspektivet kräver att vi utvecklar säljprocessen, serviceprocessen och även själva produkten samtidigt och i samverkan.

Upplevelse och behov. Tjänsteperspektivet utgår från människan och hennes behov och subjektiva upplevelse. Vi formulerar inte processer utifrån organisationens synvinkel utan utifrån den vi betjänar. Vi beskriver inte den tekniska komponenten utifrån tekniska skallkrav utan utifrån användningsfall och brukarberättelser. Och vi värderar vår process efter hur bra den faktiskt möter mänskliga behov, inte efter andra mer arbiträra nyckeltal.

Livscykelansvar. De agila metoderna växte fram inom systemutvecklingen. Scrum, SAFe, LeSS, XP, DSDM och de andra metodramverken har just systemutveckling i fokus. Men utveckling, att man tillför och förbättrar funktionerna, utgör bara en liten del av tjänstens livscykel. Drift, service, införsäljning, införande och avveckling, bemanning och så vidare är lika viktiga eller viktigare för helhetsupplevelsen. Agila metoder sådana de är formulerade idag tenderar att suboptimera på utveckling. På samma sätt suboptimerar man ofta lean production på tjänstedrift och man glömmer utvecklingen.

Om driftsättningsprocessen, där nyutvecklade förändringar i tjänsten ska tas i bruk, dessutom är osmidig leder det till att man driftsätter nyheter för sällan, vilket leder till för stora batchar av funktioner i varje driftsättning, vilket leder till för långa ledtider och svag feedback, vilket leder till tjänster som inte möter folks behov. Kombinera detta med planeringsverktyg som inte klarar av högt förändringstryck, och du tappar möjligheten att styra tjänsten på strategisk nivå.

Inom IT finns det ett ramverk som hanterar alla dessa aspekter av tjänster (strategisk styrning, utveckling, införande och utfasning, produktion, och även ständig förbättring). Ramverket kallas ITIL och är sorgligt underutnyttjat, för det kan användas för att livscykelhantera tjänster även om de inte har en gnutta IT i sig. ITIL är också ofta sorgligt överbyråkratiserat. Det gör att organisationer börjar tillämpa ITIL på en alldeles för liten del av sin verksamhet, tar i från tårna, men drunknar i krångelbördan och slutar använda det.

Man kan istället se ITIL för vad det är: ett ramverk som hjälper organisationer att behålla tjänsteperspektivet (helhet, behov, livscykel), och så använder man precis det lilla fåtal komponenter i verktygslådan som krävs för att bygga en minimal struktur. I ramverket inför man sedan de verktyg från de smidiga verktygslådorna som man faktiskt känner att man behöver för stunden, och är snabb på att kasta ut det som inte krävs.

På så sätt blir man som organisation mycket bättre på att möta folks verkliga behov, även när de behoven växlar snabbt (som de ju gör i dagens föränderliga värld). Intag tjänsteperspektivet!

Deras flödestavla är inte din

Här ett vanligt chefsmisstag vid införandet av lean och agila metoder: att chefer tror att en flödestavla (till exempel en scrumtavla eller kanbantavla) är till för deras eller för organisationens behov. Men flödestavlan är till för synkronisering inom gruppen som behöver självorganisera sig runt sitt eget arbete. Eller grupper som behöver koordinera arbetet mellan sig. Den är inget rapporteringsverktyg.

Det finns till exempel chefer som kräver att alla processteg i arbetet ska analyseras och bli särskilda kolumner på tavlan. Chefen ska då kunna titta på tavlan och förstå var i processen arbetet är. Men gruppen själv kanske bara ser behov av tre kolumner: arbete som ska göras, eller är på gång att göras, eller är färdigt. Att formalisera arbetet som chefen vill kanske inte är så enkelt. Eller så är det inte nödvändigt eftersom var och en som befinner sig på golvet vet vad arbetet innebär.

Folk som har ett särskilt ansvar för helheter, vilket många chefer har, de behöver naturligtvis olika sorters rapporter. Att få indikation på när saker blir klara till exempel.

— "Ja, men det kan jag ju få om gruppen bara flyttar lapparna för arbetspaketen mellan kolumnerna. Då kan jag ju räkna ut prognosen för när ett visst arbetspaket blir klart!"

— "Visst, men gruppen är säkert mycket bättre än du på att räkna ut det. De sitter ju närmare informationen. Att de ska ta sig tid att transportera den informationen ut till dig för att du ska göra beräkningen är både ett slöseri (transport) och en stor risk eftersom information inte kan förflyttas utan att den tappar i värde."

— "Nä, gruppen kan faktiskt inte göra prognoser!"

— "Varför har du inte lärt dem det?"

På mina utbildningar brukar jag säga att det finns tre olika sorters informationsspridare: de som sprider information från någon annan till en grupp (till exempel budskap från ledningen till gruppen; de som sprider information från en grupp till någon annan (till exempel rapporteringstavlor som andra, till exempel ledningar, ska titta på); och så spridare som sprider information inom en grupp människor så att de kan synka sitt gemensamma arbete (och hit hör flödestavlorna).

Man måste vara mycket noga och försiktig när man designar spridare som arbetar enkelriktat över gruppgränser (till exempel ledningsbudskap och rapporteringstavlor). Risken för förvrängningar i informationen är stor eftersom spridningen sker enkelriktat, ofta enbart genom spridaren, och om det finns en maktskillnad mellan sändare och mottagare förvrängs betydelsen ytterligare.

Spridare som används för synkronisering inom en grupp av hyfsat jämbördiga individer är inte lika känsliga. Människorna svärmar kontinuerligt runt informationen, det sker ett utbyte, och spridaren är inte den enda informationskällan. Informationsutbytet via en synktavla består framförallt i de mänskliga möten man har framför den. Missuppfattningar korrigeras, och man är alla ense om vad saker på tavlan betyder. Vid behov ändrar man snabbt på tavlans utformning.

Är du chef ska du akta dig för frestelsen att blanda ihop dessa olika sorters informationsspridare. Försöker du i det tysta utläsa saker ur ett synkroniseringsverktyg är risken mycket stor att du läser fel. Deras tavla är till för att de ska kunna synka sitt eget arbete, inte för att du ska övervaka dem.

Om du känner ett behov av att övervaka deras arbete kanske du kan fundera på om du inte istället skulle kunna komma överens med dem om att de på något sätt rapporterar avvikelserna till dig (jidokaprincipen). På så sätt behöver du inte bry dig så länge som den ordinarie processen fungerar bra. Att övervaka det som fungerar är ett slöseri med tid.

Om du känner ett behov av att utläsa information ur andra människors informationsverktyg kanske du kan fundera på om det inte är så att du istället har ett kommunikationsbehov med dessa människor. Försök istället få till sätt där ni kommunicerar ansikte mot ansikte, kanske framför en informationsspridare som ni har gemensamt.

Workplace Management - Taiichi Ohno (kap 21-24)

Kapitel 21: Att rationalisera är att göra det som är rationellt

Att styra genom flera chefsnivåer skapar en visklek där chefens tankar blir förvanskade på vägen till golvet. Ohno föredrog därför att gå förbi så många nivåer som möjligt och prata direkt med golvet när han drev igenom "Ohnosystemet". (Fast Ohno menar första linjens chefer: förmännen, när han pratar om att gå "direkt till golvet"). Detta kringående ogillades av mellancheferna som väl såg sig onödiggjorda. Därför kom Ohnosystemet att handla om att utbilda alla nivåer: uppifrån och ner och nerifrån och upp.

Nyckeln till Ohnosystemet var det prövande förhållningssättet. Ingen visste om Ohnos ideer fungerade. Därför var de tvungna att prova det ena den ena dagen, och det andra den andra dagen. Ohno var tvungen att påminna folk om att "de visa bättrar sig" (se kapitel 1). Att det är smart att pröva, se, och förändra sig vid behov.

På den här tiden lärde sig fabriker av varandra. Ohno minns hur studiebesöken på Nissan ledde till att Toyotafolk försökte kopiera Nissan istället för att själva uppfinna förbättringar. Det blev inte så bra. Man försökte ofta kopiera det spektakulära, t ex att Nissan använde så många maskiner och automatiska processer man fått från USA. Ohno gör reflektionen att ju mer spektakulärt något är, desto lättare har vi att tro att det är fantastiskt. Men på en produktionsanläggning är det ofta tvärtom: det som för den yttre betraktaren verkar vara självklart ickespektakulärt eftersom det är så rationellt, det är ofta bra och rationellt. Har du inga wow-upplevelser vid ett studiebesök så är det ofta ett tecken på en verksamhet som fungerar ypperligt.

En wow-upplevelse kan till exempel vara hur man i en fabrik transporterar material mellan stationerna, eller hur man hanterar en stor mängd samtidigt arbete. Men istället borde fabriken förenkla bort själva behovet av en massa transporter, och göra sig av med det samtidiga arbetet. Vi har så lätt att fascineras av "transportation" och så svårt att uppskatta "work".

Kapitel 22: Stäng av maskinerna!

Här fortsätter Ohno reflektionen om Jidoka från kapitel 16. Skillnaden mellan "transportation" och "work" (arbete utan respektive med nytta) består i att det japanska tecknet för "work" har med tecknet för "människa" - the human touch. Jidokaprincipen handlar om att processer måste vara beredda att stänga av sig själva om något går snett, eftersom kvalitet och säkerhet alltid ska sättas i första rummet. Och eftersom människan på golvet ser andra saker än en sensor i en maskin måste även människorna på golvet ha möjlighet att stänga av processen ("stoppa bandet") om något verkar gå dåligt.

På frågan om det inte är väldigt dyrt att stoppa bandet svarar Ohno att: jo, men att producera defekter är ännu dyrare. När vi stoppar bandet gör vi ständig förbättring (kaizen) för att göra oss av med rotorsaken till nödstoppet. Insikten om att defekter är dyra hade man redan 1955: när de gick in i ett besparingsprogram var det just antalet defekter de försökte hålla nere.

Kapitel 23: Hur man producerar till lägre kostnad

När Toyota började bygga bilar fick man kritik, t ex av regeringen, för att bilarna var för dyra. Man försökte sig på att få ner kostnaderna på amerikanskt vis med massproduktion, men eftersom man inte hade kundunderlaget så gjorde man stora förluster. Att bygga 1000 bilar i månaden är inte bra om man inte får sålt dem. 1949-1950 var Toyota konkursmässigt.

Under Koreakriget fick Toyota beställningar från USA:s krigsmakt. Det innebar låga men stabila volymer. Utmaningen blev att övertyga folk om att inte bygga fler fordon än så bara för att man hade tid och material. Få dem att förstå att överproduktion i slutändan kostar mer. Få folk att förstå hur kanban och just-in-time ska förhindra överproduktion (se kapitel 19).

Men folk måste också få in en kostnadsmedvetenhet i detta. Hur ska vi sänka kostnaden per enhet utan att överproducera genom stora serier?

Först under oljekrisen i början på 70-talet förstod flera människor finessen med Toyotas approach. Ohno tänker att utan den och andra kriser hade Toyotasystemet utvecklats till ytterligare ett i raden av massproduktionssystem.

Kapitel 24: Bekämpa robotmodeflugan!

Peter Drucker sa att inget är så värdelöst som att försöka förbättra den process som inte bör utföras alls. I det här kapitlet är Ohno inne på samma linje när det gäller robotiseringen. Blir det verkligen billigare med robotar? Är inte det en effektivisering som bara fungerar vid ökade volymer? Hur blir det vid små volymer? Efterfrågan kan inte hela tiden öka. Särskilt inte vid råvarukriser som oljekrisen, eller när handelshinder stoppar exporten.

Den viktiga frågan är hur man ska arbeta och sätta upp logistiken för att minska kostnaderna per enhet även vid små serier. Sedan kan man automatisera, om det verkligen hjälper. Man ska inte hoppa på robotiseringståget "bara för att". Absolut inte för att alla andra gör det.

Om en automatisering verkligen leder till en kostnadssänkning är det ett bra skäl att använda robotar. Likaså om roboten tar över farliga arbeten. Men vi måste se hur automatiseringen påverkar samhället. "It is very bad to ignore the human aspect."