Directeur / eigenaar
De kracht van Kaizen
De kracht van Kaizen is de optelsom van alle kleine verbeteringen door de dagen, weken en jaren heen. Hoe minder tijd je besteedt aan verspilling (= iets wat wel tijd kost, maar geen waarde toevoegt), hoe meer tijd je kunt besteden aan dingen die waarde toevoegen. Of je kunt die tijd besteden aan de volgende stap van het verminderen van verspilling. Dat werkt net zoals rente-op-rente. En daar ga je het verschil maken.
Een rekenvoorbeeld
Oké. Tijd voor een rekenvoorbeeld. Want, hoeveel tijd mag je dan besteden aan iets verbeteren? Want: meten = weten. Stel, je hebt na een eerste analyse van je werkweek gezien dat je inderdaad best vaak een document opent (zie het voorbeeld uit vorige artikel) en dat je 2 keer per week 7 minuten besteedt aan het maken van een rapportage. Hier moet je data van verschillende bronnen verzamelen, bewerken en samenvoegen in een Excel-bestand. Je schat in dat je hier wel 5 minuten kunt besparen als je bepaalde taken kunt automatiseren. Maar ja, 5 minuten, hoeveel winst is dat nou eigenlijk? En waarom die moeite doen. Dat ga ik je laten zien.
Laten we ervan uitgaan dat we een terugverdientijd van 1 jaar redelijk vinden. Uit het vorige rekenvoorbeeld weten we dat we in één jaar 4,5 uur kunnen besparen als we onszelf aanleren om documenten te openen met sneltoetsen. Dus je mag 4,5 uur besteden aan het jezelf aanleren van deze sneltoetsen. Ik denk dat dat sneller kan :-). Stel dat je 1,5 uur nodig hebt om het onder de knie te krijgen. Dan blijft er dus 3 uur over die je kunt besteden aan het verbeteren van je rapportage. Als je 2 keer per week 5 minuten bespaart, is dat bijna een hele dag aan het einde van het jaar. In het 2e jaar heb je 12 uur gewonnen! En die 12 uur kun je weer inzetten voor de volgende stap.
In de sport wordt eenzelfde methode gehanteerd die Marginal Gains wordt genoemd. Elke 0.1% verbetering is weinig. Maar 10 van die verbeteringen is al een verbetering van 1%. Dat is in de topsport enorm en maakt het verschil aan de finish.
De gevaren die Kaizen bedreigen
Eerder schreef ik over de twee grootste uitdagingen van Kaizen: continu en iedereen doet mee. Maar als je dan continu met z’n allen aan de slag bent, dreigen er twee gevaren die roet in het eten kunnen gooien:
- De verbetering is te groot waardoor je niet binnen redelijke tijd een stap kunt maken.
- De verbetering is te klein en dus niet de moeite waard.
De verbetering te groot maken
Als je de 5 keer waarom-analyse hebt gedaan heb je een berg aan mogelijke verbeteringen. En zeker als je dat met een team doet, dan beginnen de mogelijke verbeteringen te stromen. De lijst van verbeteringen wordt dan enorm. Het gevaar is dat je dan alles wilt gaan aanpakken. “Als we dan toch bezig zijn….” en “Ik wil al heel lang … aanpakken” of “Ja, maar dan moet dit en dit ook”. Hierdoor wordt de verbetering te groot, waardoor je het in de planning moet zetten, met alle gevaren van dien. Maak het kleiner. Elke stap voorwaarts levert winst op. Probeer de oplossing zo klein mogelijk te maken en doe hem meteen. Omdat het continu is, komen de andere verbeteringen vanzelf aan bod.
De verbetering te klein vinden
Hier verwijs ik naar het rekenvoorbeeld: een verbetering van 10 seconden of 5 minuten kan al enorm zijn en over een jaar gezien leiden tot een winst van 12 uur.
Hoe maken we Kaizen concreet
Omdat het echte werk in de teams gebeurt, vinden wij het belangrijk dat iedereen in het team de vrijheid heeft om zelf met verbeteringen te komen. Of het over zijn eigen proces gaat, over het proces van het team of hoe we bij Insyde werken.
Wij hanteren de volgende 3 stappen.
- Signaleren van verbeteringen (in plaats van klagen dat het allemaal *** is)
- Aandragen van de oplossing
- Uitvoeren van de oplossing
Deze drie stappen kun je continu doorlopen. We vinden het zo belangrijk dat we het ook meenemen in de beoordeling van onze collega’s. Aan de ene kant is het dus een “verplichting” en aan de andere kant is het een vrijheid. Je mag zelf aan de slag om fijner, beter, slimmer te kunnen werken.
Voorbeelden uit onze praktijk
Hieronder volgen een paar voorbeelden uit de praktijk. Omdat we elke dag streven naar verbeteringen klein of groot kan deze lijst eindeloos zijn. Ik heb een paar opvallende voorbeelden uitgelicht.
Invoering van Scrum
Jaren geleden toen we nog met de watervalmethode werkten liepen we tegen een barrière aan in kwaliteit en snelheid. Projecten hadden relatief veel bugs en changes na de livegang. Projecten liepen ook vaker uit dan gewenst. Toen Job met de suggestie kwam dat Scrum wel eens een oplossing kon zijn, hebben we ons hier snel in verdiept, met mensen gepraat die hier al wat ervaring mee hadden. Binnen 3 weken namen we de beslissing om te gaan proefdraaien met Scrum. Typisch een voorbeeld van een transformatieproject geleid door het management.
Bugs, changes, functionele ontwerpen, wireframes. Allemaal tussenproducten, waste en tijdsverspilling. Hoe minder je daarvan hebt, hoe beter. Met de invoering van Scrum hebben we heel veel van deze verspilling weggesneden. Maken we mooiere en betere projecten. De kwaliteit is hoger. De doorlooptijden korter. En de klant en de teams gelukkiger.
Pair programming
Pair programming is een veelgebruikte methode in de Agile softwareontwikkeling. Wij zetten hem soms anders in. Eén van de senior developers kijkt mee met de junior en medior developers. Het doel is observatie van hoe iemand werkt, welke handelingen voert iemand uit, welke dingen doet hij vaak en kosten veel tijd. Vragen naar zijn of haar gedachtepatroon. Uit deze observaties komen altijd veel inzichten waar en wat we kunnen verbeteren. Zowel de developer zelf (als onderdeel van doelbewust oefenen) als de processen en manier van programmeren. Met die verbeteringen gaan we dan in de slag, meestal in de vorm van code generation.
Code generation
Code generation is dé manier om enorme slagen te maken in je programmeersnelheid. Zijn er vaste onderdelen of stappen die een developer uitvoert? Vraag je dan af of je die code automatisch kunt laten genereren. Maak eerst een duidelijk stappenplan zodat je weet welke stappen de developer precies uitvoert. Deze kun je vervolgens automatiseren.
Zo heeft Job het opstarten van een project, dat een 29-stappenplan is, met een halve dag programmeren geautomatiseerd. Het grote voordeel is niet alleen tijdswinst, maar ook het verminderen van fouten.
Automatiseren van de livegang
Sinds begin 2016 hebben wij continuous delivery ingevoerd. Dit is een enorme stap voorwaarts geweest. Dit is een managementkeuze geweest, gedreven door het team, om hierin te investeren. Nu kunnen we ons niet meer voorstellen dat we het ooit anders deden.
En nog 1000 kleine verbeteringen
Naast deze wat grotere en zichtbare verbeteringen voeren we dagelijks kleine aanpassingen door in onze werkwijze waardoor we het leven wat makkelijker, efficiënter en daardoor leuker maken.
