Feature Articles

Thema-artikelen By: Michael Ballé

Desperately Seeking Kaizen

Desperately-seeking-kaizen-at-Toyota

 

Thema-artikel -- Na een bezoek aan een Toyota-leverancier in Japan reflecteren de auteurs op de aard van kaizen. Ze leggen uit waarom we er misschien op de verkeerde plek naar zoeken.

 

Tekst: Michael Ballé, Benoît Charles-Lavauzelle en Régis Médina.

Een paar maanden geleden stonden we op de werkvloer van een stansfabriek van een Toyota-leverancier in Japan. We hadden de halve wereld over gereisd op zoek naar kaizen.

Een van ons, Benoît, had voor Lean gekozen als schaalvergrotingsmethode voor zijn snelgroeiende softwarebedrijf Theodo. Samen met Régis, agile coach en Lean IT-expert, probeerde hij kaizen van de grond te krijgen in zijn coderingsteams. Het plan was om de zesstappenmethode van Isao Kato en Art Smalley te gebruiken: 1. Ontdek verbeterpotentieel, 2. Analyseer de huidige methode, 3. Genereer originele ideeën, 4. Ontwikkel een implementatieplan, 5. Implementeer het plan, 6. Evalueer de nieuwe methode (uit Isao Kato & Art Smalley, Toyota Kaizen Methods, Productivity Press).

De leverancier van Toyota was indrukwekkend Lean; alle machines draaiden en er was bijna geen verspilling te vinden, mensen voegden waarde toe op hun werkplek, de kwaliteit werd individueel gevolgd, er was geen centimeter ongebruikte ruimte in de fabriek. Bovendien leek alles wat operators nodig hadden voor hun gestandaardiseerde werk op zijn plaats en beschikbaar. Vrachtwagens van Toyota pikten elk half uur kleine hoeveelheden van elk onderdeel op. We zagen zelfs het hoshin kanri-bord, met een gedetailleerde uitwerking van de uitdagingen en doelstellingen van het bedrijf en van de manier waarop die in functionele afdelingen werden geïntegreerd. Maar van gestructureerde kaizen was er geen spoor.

Na nog wat langer rondkijken realiseerden we ons dat niet alleen alle persen continu draaiden, maar dat ze ook in heel kleine batches werkten om te voldoen aan Toyota's behoefte aan kleine hoeveelheden van elk onderdeel in elke vrachtwagen. We observeerden een omstelling: een team operators wisselde tegelijkertijd de matrijzen van meerdere persen van een lijn en had ze binnen enkele minuten opnieuw aan de praat (het duurde minder dan tien minuten, terwijl dit in een normale fabriek enkele uren kan duren). Het eerste deel kwam er meteen goed uit. Nog verbazingwekkender was dat de productie na de omstelling weer begon zonder de gebruikelijke controles en onderdelenchecks: de operators vertrouwden er gewoon op dat het eerste onderdeel kwalitatief in orde was.

We vroegen opnieuw naar kaizen, maar men keek ons vreemd aan. ‘Kaizen is overal en altijd,’ zei de directeur van het bedrijf uiteindelijk.

Toen we bespraken wat we hadden gezien, beseften we dat dit inderdaad het geval was. Het was gewoon niet mogelijk om een fabriek zo goed te laten draaien zonder constante kaizen. Een van ons (Michael) bevestigde dat hij door de jaren heen verschillende persfabrieken bezocht had en dat hij nog nooit zo’n hoge kwaliteit, flexibiliteit en kapitaalintensiteit had gezien. Blijkbaar lukt het niet om dat met brute kracht te bereiken – daar is kaizen voor nodig.

Waarom is dit van belang voor een app-ontwikkelaar?

Eenmaal terug op zijn eigen gemba dacht Benoît veel na over wat hij in Japan had gezien. Plotseling kreeg hij een inzicht: app-gebruikers willen zo snel mogelijk van de ene pagina naar de andere en recht op hun doel af (informatie, een dienst, een product enzovoort). Zo bekeken is de laadtijd van een pagina in de ogen van de gebruiker pure verspilling. Hoe relevant zou het zijn om kaizen op die laadtijd toe te passen? Daarmee zou je de belangrijkste vorm van verspilling aanpakken, die rechtstreeks van invloed is op de eindgebruiker. In onze ogen leek dit erg relevant.

Toen Régis en Benoît dit bespraken met Nicolas Goutay, een van de teamleiders van Theodo, gaf die ons onmiddellijk gelijk. Volgens hem klagen gebruikers inderdaad over pagina's die te langzaam worden geladen. In een project waaraan hij had gewerkt, duurde het laden van bepaalde belangrijke pagina's wel zes seconden. Uit een kort onderzoek bleek hoe groot dit probleem was (zie een artikel van Kit Eaton, https://www.fastcompany.com/1825005/how-one-second-could-cost-amazon-16-billion-sales). Volgens dit onderzoek verlaat één op de vier bezoekers een pagina als het meer dan vier seconden duurt om die pagina te laden. Amazon schat dat het hun wel $1.6 miljard omzet per jaar kan kosten als een pagina slechts één seconde langzamer laadt. Dat zijn indrukwekkende bedragen.

Régis en Nicolas besloten dit probleem in een specifiek project aan te pakken en stelden voor de laadtijd een target vast van maximaal drie seconden -- in echte omstandigheden, wat betekent dat de internetsnelheid van de gebruikers in het probleem wordt meegenomen. Vervolgens onderzochten ze wat technologiereuzen als Twitter, Google, Facebook en The New York Times deden en verzamelden ze mogelijke verbeterideeën. In samenwerking met Antoine Kahn, Alexandre Chaintreuil en de rest van het ontwikkelteam gingen ze het probleem vervolgens stukje bij beetje te lijf:

  • Er werden 2 seconden bespaard door bestanden te comprimeren voordat ze naar de navigator van de gebruiker werden verzonden;
  • Er werd 0,6 seconde bespaard door onnodige verzoeken aan servers te elimineren;
  • Er werd 0,4 seconde bespaard door content zodanig te prioriteren dat het belangrijkste voor gebruikers als eerste werd geladen;
  • Er werd 1 seconde bespaard door de backend-code te optimaliseren door het pad en de markeertijd in kaart te brengen om beter inzicht te krijgen in waar precies tijd in ging zitten bij het uitvoeren van de code.

Deze laatste exercitie bleek met name interessant, omdat het team zo de code beter kon bestuderen, hypotheses over de efficiëntie kon formuleren en die hypotheses kon toetsen. Twee van deze hypotheses hebben hun vruchten afgeworpen en hebben het proces met een extra seconde weten te versnellen.

Tijdens deze verbeterinspanningen is een aantal dingen duidelijk geworden. Allereerst bleek de zesstappenmethode voor kaizen heel nuttig als vertrekpunt en als springplank voor een concreet doel. De aanpak kan ook helpen bij het opstellen van hypotheses en bij het creëren van een omgeving waarin Benoît als CEO en Régis als Lean coach het team verder kunnen uitdagen en gefocust kunnen houden op verder verkennen en begrijpen in plaats van de voor de hand liggende problemen op te lossen en weer verder te gaan.

Ten tweede, toen het team besefte wat het probleem was, werd de formele structuur van kaizen minder relevant en werd het eigenlijke Lean denken over ‘het bestuderen en elimineren van verspilling’ belangrijker. Het team boog zich over elke fractie van een seconde aan ‘verspilling’ voor de gebruiker en verdiepte zich in de oorzaken, formuleerde en toetste hypotheses en kwam met tegenmaatregelen -- met andere woorden: kaizen.

Ten derde was het zeer waardevol voor de CEO, die mogelijkheden zag om deze manier van denken ook in de rest van zijn bedrijf te introduceren en er een echte onderscheidende factor van te maken voor de apps die het ontwikkelt. Dit is Lean denken in de Toyota-traditie: ‘Eerst aan de klant denken, als tweede aan de dealer en als derde aan de fabrikant.’ Bij Theodo keek Benoît dus eerst naar de gebruiker, als tweede naar de klant en als derde naar de codeurs. De pogingen van de coderingsteams om seconden van de laadtijd af te schaven zouden allereerst ten goede komen aan de klanten, en daarnaast de individuele codeervaardigheden van elke ontwikkelaar (en het algemene vermogen van Theodo om betere apps te creëren) verbeteren.

Je zou dus kunnen zeggen dat we naar Japan waren gegaan op zoek naar een kaizen ‘methode’, maar dat we niet hadden gevonden wat we zochten. Wat we wél vonden was inzicht. We realiseren ons nu dat de formele structuur van kaizen niet de kaizen zelf is -- de kaart is niet het territorium.

We hebben geleerd dat we, willen we echte kaizen in stand houden, beter moeten worden in:

1. Verduidelijking van de beoogde voordelen: de directeur van de Japanse Toyota-leverancier was heel duidelijk over de concrete voordelen die hij van kaizen verwachtte en over waar die voordelen nog meer konden worden benut. Toen Benoît besefte hoeveel winst een snellere paginalaadtijd op bedrijfsniveau zou kunnen opleveren, gaf dit betekenis aan de hele inspanning en werd het ook de codeurs duidelijk wat hun gevraagd werd te verbeteren.

2. Het bestuderen van verspilling, met metingen om te achterhalen wat er werkelijk gebeurt. Naast het oplossen van de eerste voor de hand liggende problemen moest het team vooral een methode zien te ontwikkelen om tijd te markeren in de uitvoering van de code en bestuderen hoe code zich qua tijd gedroeg. Dat leidde tot de formulering van hypotheses en tot meer kennis over code en codering.

3. Voor kaizen is teamwork nodig: het gedeelde belang van de CEO, de Lean coach, de teamleider en de teamleden was de motor achter de inspanningen op de momenten dat het moeilijk werd (het regel voor regel bestuderen van code). Dat gedeelde belang is ook wat alles uiteindelijk de moeite waard maakte. Dankzij de verschillende invalshoeken die werden aangeboord om een technisch probleem aan te pakken kon het team naar nieuwe oplossingen zoeken.

Te veel kaizen-inspanningen blijven hangen op het formele organisatieniveau: de stappen worden doorlopen, het probleemoplossende sjabloon wordt ingevuld, soms wordt het ‘proces’ veranderd. Maar vaak dringt kaizen niet door tot het echte technische procespunt, daar waar de gebruiker het product of de dienst gebruikt, waar het gereedschap het onderdeel raakt, waar het ontwerp zijn daadwerkelijke functie vervult. Voor echte kaizen is allereerst leiderschap nodig om te begrijpen welke typische problemen -- die dingen die moeilijk uitvoerbaar zijn -- een voorsprong kunnen opleveren op de concurrentie. Dit moet vervolgens worden gecommuniceerd aan de teams; hun talenten en passie moeten worden betrokken bij het vinden van creatieve manieren om dingen beter te doen. Kaizen kan niet programmatisch zijn. Het moet beginnen bij het topmanagement, dat echt iets wil verbeteren voor gebruikers en klanten, en dat teams ondersteunt bij het bestuderen van hun eigen werkwijzen en van de verspilling die uit de technische processen kan worden gehaald. Zo komt een team tot echte verbetering. Zo innoveert een bedrijf.

Meta-omschrijving: Kaizen kan niet programmatisch zijn. Na terugkomst uit Japan reflecteren de auteurs op de betekenis van kaizen en op waarom er vaak op de verkeerde plekken naar wordt gezocht.

De Auteurs

Michael-Balle

 

Michael Ballé is co-founder of the Institut Lean France. Michael is a best-selling author and an engaging speaker, and managing partner of ESG Consultants.

He also works as a lean executive coach in various sectors. His latest book, The Lean Strategy (co-authored with Dan Jones, Jacques Chaize and Orry Fiume) is available here.

Benoit-Charles-Lavauzelle

Benoît Charles-Lavauzelle (left) is Co-Founder and CEO of Theodo.

Regis Medina photograph

 

Régis Medina is a Lean IT Coach at Institut Lean France, in France.

Back to Top
   Comment