Het spreekwoord “voorkomen is beter dan genezen” geldt ook voor software. Veel software fouten zijn niet nodig; veel problemen kunnen voorkomen worden. Een techniek die helpt om te leren van fouten, en ze te voorkomen, is Root Cause Analysis.
In een Root Cause Analysis wordt een fout of probleem stapsgewijs geanalyseerd, om terug te gaan tot de grondoorzaken waardoor het veroorzaakt is. Mbv een oorzaak-gevolg diagram worden de oorzaken in kaart gebracht. Pas als een goed beeld is gevormd van de grondoorzaken, kunnen acties afgesproken worden om de grondoorzaken aan te pakken. Deze acties voorkomen dan vergelijkbare problemen in de toekomst.
Een techniek om een grondoorzaak te vinden is “5 times why”. Bij een gevolg vraag je waardoor het veroorzaakt is. De oorzaak die je vind is een gevolg van iets, dus vraag je wederom waardoor dat veroorzaakt is. Na zo’n 5 keer doorvragen kom je bij de grondoorzaken. Dit zijn de oorzaken die je aan kunt pakken, om soortgelijke problemen te voorkomen.
Deze grondoorzaken hebben vaak meerdere problemen tot gevolg, en daardoor is het aanpakken van de grondoorzaken meestal zeer lonend. In de jaren dat ik Root Cause Analysis toepas is een voor mij herkenbaar patroon van grondoorzaken ontstaan. Veel voorkomende grondoorzaken zijn gebrekkige communicatie, onderlinge tegenstrijdige belangen, en onvoldoende kennis en vaardigheden.
Te weinig middelen is vrijwel nooit een grondoorzaak, vaak zijn er diepere redenen te vinden waarom er geen middelen zijn. Er is bv. onvoldoende duidelijk gemaakt waarom de middelen nodig zijn (communicatie), er word geen tijdige beslissing genomen om middelen beschikbaar te stellen (belangen/vaardigheden) of de middelen zijn er wel maar zijn niet benut (communicatie). De kunst van Root Cause Analysis is om door te vragen tot je grondoorzaken gevonden hebt die je aan kunt pakken.
Root Cause Analysis wordt vaak gebruikt binnen Lean en Six Sigma. Het is een techniek om veel voorkomende fouten (waste!) te analyseren en de oorzaken aan te pakken, en daarmee structureel de performance van een proces aan te pakken, met blijvende verbetering van de bedrijfsresultaten. Wat minder bekend is, is dat Root Cause Analysis ook prima past in Agile. Bijvoorbeeld door in een retrospective een analyze te doen van een probleem, en acties te definiëren die in een volgende Scrum sprint direct tot verbetering leiden. De kennis er ervaring van het team wordt op die manier optimaal benut om de product kwaliteit te verbeteren.
Meer informatie over Root Cause Analysis is te vinden in:
- Root Cause Analysis Process en Checklist
- Root Cause Analysis blogs
- Artikel The Business Benefit of Root Cause Analysis (SM/ASM 2003)
- Presentation Experiences using Root Cause Analysis for Improvement (ESEPG 2002)
- Presentation Continuous Quality Improvement using Root Cause Analysis
- Boek Apollo Root Cause Analysis, Dean L. Gano.
- LinkedIn group Root Cause Analysis
- Forum Root Cause Live: http://www.rootcauselive.com/
- CMMI Process area Causal Analysis & Resolution http://www.sei.cmu.edu/cmmi/index.html
Heb je ook ervaringen met het gebruik van Root Cause Analysis? Deel ze dan met de lezers van deze website. We horen graag van je!
Hoi Ben,
Op zich is RCA wel nuttig, maar ik krijg wel steeds meer het gevoel dat RCA ervan uit gaat dat de wereld deterministisch is. Dezelfde gevolgen hebben altijd dezelfde oorzaken. Als deze aanname juist is, dan is RCA nuttig. Je kunt dan de root cause wegnemen en bent voor eens en altijd van de gevolgen af.
Echter, volgens mij is die aanname onjuist. De aanname plaatst onze problemen in het simple of complicated kwadrant van het Cynefin framework. En volgens mij liggen de meeste problemen waar we mee te maken hebben in het Complex kwadrant. En daar geldt helaas niet dat dezelfde oorzaken altijd dezelfde gevolgen hebben.
Hoe denk jij hierover?
Beste Andre,
Ik ben het met je eens dat de de meeste software systemen die we tegenwoordig ontwikkelen in het Complex of zelfs in het Chaotic kwadrant zitten. De eenvoudige systemen zijn al lang gebouwd. Echter, de grondoorzaken die je met een goede Root Cause Analysis zichtbaar maakt hebben nu juist te maken met kwaliteiten die nodig zijn om complexe systemen te ontwikkelen!
B.v. goed communicatie is van cruciaal belang om complexe systemen te ontwikkelen. Goede (agile) teams, waarin professionals continue hun kennis en vaardigheden aanscherpen zijn in staat om complexe problemen te doorgronden, en oplossingen te bedenken.
Overigens heb ik in alle jaren nog nooit een Root Cause Analysis sessie gehad waarin het proces of de procedure de Root Cause was. Er was altijd een diepere oorzaak te vinden. Het standaardiseren van de werkwijze met nieuwe of verbeterde processen is dan ook geen oplossing om de Root Causes aan te pakken…
Groeten,
Ben Linders
Een extra optie is het ontwerp zo maken dat fouten minder impact hebben. Ik merk dat techneuten (incl myself) de neiging hebben een waterdichte oplossing te bouwen. Je kan als alternatief ook een goede afwatering bouwen, vergelijkbaar met hardware designs met fail-over, parity bits etc.
Beste Machiel,
De ontwerptechnieken die je noemt zijn nieuw voor mij, klinkt interessant. Heb je ergens meer informatie hierover?
Ik pas vergelijkbare technieken al wel toe met ontwikkelteams, b.v. door focused reviews, spikes, pairen, en risk based testing. Daarbij gebruik makend van de feedback uit Root Cause Analysis, wat voor soort fouten komen veel voor en hoe kun je die eerder vinden (en dus defect slippage verminderen).
Ben, nice to have Apollo method listed. We apply that in our domain. Looks like the link is broken though
You’re right! I updated the link, but it seems that the book went out of print. Amazon only provides some new and used copies. Which is a shame, because it’s a great method!