De AI 5 Waarom Analist skill voor Claude

De methode wordt algemeen toegeschreven aan Sakichi Toyoda, de oprichter van Toyota Industries. Taiichi Ohno maakte haar bekend als vast onderdeel van het Toyota Production System en beschreef haar in zijn boek over dat systeem uit 1978. De redenering erachter is simpel: elk zichtbaar probleem is het gevolg van iets dat dieper ligt, en die diepere oorzaak raak je pas als je een paar lagen doorzakt. Vijf is daarbij geen heilig getal. Het is een vuistregel die zegt dat je er waarschijnlijk nog niet bent bij de eerste plausibele verklaring.

De AI 5 Waarom Analist vertaalt die methode naar een vaste werkwijze voor Claude. Een skill is een instructiebestand, SKILL.md, dat een AI-assistent een vaste aanpak meegeeft voor een taak. Geen software die je installeert, geen abonnement, geen koppeling met je systemen: een tekstbestand van 2.189 woorden dat Claude vertelt hoe een oorzaakanalyse in elkaar hoort te zitten, wat hij eerst moet uitvragen, hoe hij per laag de zekerheid markeert en wat hij onder geen beding zelf mag verzinnen. Je downloadt de zip bovenaan deze pagina, zet hem in je Claude-omgeving, en vanaf dat moment gaat elke oorzaakvraag via deze logica.

Wat de skill anders maakt dan zelf vijf keer waarom vragen, zit in drie dingen. Ten eerste dwingt hij je het probleem eerst meetbaar te maken. Voordat er ook maar een waarom valt, herschrijft hij je klacht tot een feitelijke zin met plaats, tijd en omvang. Ten tweede labelt hij elke laag op bewijs, zodat je aan het eind ziet welk deel van je analyse rust op data en welk deel op een verhaal dat toevallig klopt. Ten derde scheidt hij de pleister van de ingreep: de directe fix die het symptoom deze week stopt staat los van de structurele maatregel die de oorzaak wegneemt, elk met een eigenaar en een termijn.

Het bestand hoort bij de skill-bibliotheek van TheSEO, waarin 100 skills gratis te downloaden zijn, en komt voort uit de dienst AI en automatisatie. Ben je nieuw met dit soort bestanden, begin dan bij wat Claude skills zijn: daar staat in gewone taal wat een skill wel en niet is.

De ketting wijst naar personen. Dit is de bekendste valkuil, en Eric Ries gaf er in The Lean Startup uit 2011 een naam aan: Five Blames. Elke laag komt uit bij iemand die iets vergat, iets niet doorgaf of niet oplette. Het voelt bevredigend, want er is een dader. Maar je kunt een systeem repareren en je kunt een mens niet repareren, dus zo'n analyse eindigt altijd in een gesprek en nooit in een maatregel. Een persoon als worteloorzaak aanwijzen weigert hij botweg, en de oorzaken schrijft hij juist passief op om de schuldvraag weg te nemen. Niet Jan vergat de check, maar de check werd overgeslagen omdat er geen verplicht veld was.

De ketting herformuleert in plaats van te verklaren. Laag drie zegt in andere woorden hetzelfde als laag twee. De offertes duren lang omdat de doorlooptijd hoog is: dat lijkt een stap dieper, maar je staat nog op dezelfde plek. In de beoordelingsmodus van de skill is dit het eerste controlepunt, en het bestand noemt herformuleringen letterlijk de meest voorkomende fout.

De ketting stopt in de technische laag. De SKILL.md onderscheidt drie soorten lagen die je meestal tegenkomt: de technische laag, waar iets misging in een handeling, een instelling of een stuk code; de procesmatige laag, waar het proces die fout toeliet of zelfs uitlokte; en de systeemlaag, waar niemand eigenaar was, de prikkels verkeerd stonden of een eerdere beslissing dit onbedoeld veroorzaakte. Een goede analyse eindigt zelden in de technische laag. Daar zit de snelle fix, niet de structurele oplossing.

Of de ketting doet alsof alles zeker is. Vijf antwoorden onder elkaar lezen als vijf feiten, ook als er drie van gegokt zijn. Daarom krijgt elke laag in de output een regel met Zekerheid, met een van drie waarden: bevestigd door data, aannemelijk maar onbewezen, of pure hypothese. In FIG.01 staan twee lagen op hypothese, en die twee komen aan het eind terug in een apart blok met wat je nog moet uitzoeken. Dat blok is de eerlijkste sectie van de hele output.

In diff-vorm, met een ketting die zichzelf naar een persoon toe redeneert tegenover dezelfde ketting die naar het systeem doorloopt:

Daarna volgt een hoofdstuk over de theorie: Toyoda en Ohno, de drie lagen technisch, procesmatig en systeem, en vier varianten die de skill mag gebruiken als de context erom vraagt. De vertakte ketting voor als een laag meerdere geldige oorzaken heeft. De combinatie met het Ishikawa-diagram voor als niemand nog weet waar het probleem zit. Five whys plus how, waarbij je na de worteloorzaak de ketting terug omhoog loopt met de vraag hoe je elke laag afschermt. En de lean startup variant van Eric Ries, waarbij je per laag een investering doet die in verhouding staat tot de ernst van het probleem.

De kern is een lijst van zeven dingen die de skill altijd doet. Hij herformuleert het probleem tot een feitelijke, meetbare zin met plaats, tijd en omvang voordat er een waarom valt. Hij stelt de vijf vragen een voor een en beantwoordt ze op basis van wat jij hebt aangeleverd, niet op basis van aanname. Hij markeert per laag hoe zeker het antwoord is. Hij splitst de ketting zichtbaar in takken zodra een laag meerdere geldige oorzaken heeft, en volgt de tak met de grootste impact door.

Hij benoemt de worteloorzaak in een zin, geformuleerd als systeem of proces. Hij levert de directe fix en de structurele maatregel apart, elk met eigenaar en termijn. En hij sluit af met een verificatiestap.

Voordat er iets wordt geanalyseerd, loopt de skill een verplichte inputchecklist na van zes punten: het probleem in jouw eigen woorden, wanneer het speelt en hoe vaak, wie of wat er last van heeft, wat er al is geprobeerd en waarom dat niet hielp, welke feiten of cijfers beschikbaar zijn, en wat je wel en niet kunt veranderen aan budget, mandaat en invloed op andere afdelingen. Hij vraagt alleen na wat ontbreekt en stopt daarna met vragen. Weet je iets niet, dan gaat hij door en markeert hij die laag als onbewezen. Je krijgt dus geen formulier, hooguit twee of drie gerichte vragen.

Opvallend veel regels gaan over taal. Helder Nederlands, je-vorm, geen streepjes in lopende tekst, AI in hoofdletters, geen rijtjes van precies drie, concreet boven abstract, cijfer boven bijvoeglijk naamwoord, en korte zinnen afgewisseld met lange. Er staat zelfs een lijst met woorden en wendingen die verboden zijn omdat ze naar AI ruiken. En er is een schrijfregel die inhoudelijk is in plaats van cosmetisch: schrijf oorzaken passief waar dat de schuldvraag wegneemt. Wil je begrijpen hoe zulke regels in een skill-bestand terechtkomen, dan legt een SKILL.md schrijven de opbouw stap voor stap uit.

De output ligt vast in zeven blokken in vaste volgorde: probleemstelling, de waaromketting, worteloorzaak, directe fix, structurele maatregel, verificatie, en wat je nog moet uitzoeken. Daarnaast bevat het bestand een aparte beoordelingsmodus voor bestaande analyses, een lijst met zeven dingen die de skill nooit doet, en een bronnenlijst van vijf titels. Die laatste twee krijgen verderop op deze pagina hun eigen sectie.

De methode zelf komt van Toyoda en Ohno. Taiichi Ohno beschreef het Toyota Production System in 1978, met de Engelse uitgave in 1988, en schrijft de vijf waaromvragen daarin toe aan Sakichi Toyoda. Wat vaak wordt overgeslagen is de context: bij Toyota was doorvragen geen vergadertechniek maar een gewoonte op de werkvloer, dicht bij de machine, met de mensen die het werk deden. Dat verklaart waarom de skill zo hamert op feiten en op wat je zelf kunt waarnemen.

Het voorportaal komt van Kaoru Ishikawa. Zijn Guide to Quality Control uit 1968 bevat het oorzaak en gevolg diagram dat in de praktijk vrijwel altijd samen met de 5 waarom methode wordt gebruikt. De rolverdeling is helder: het visgraatdiagram verbreedt, de waaromketting verdiept. Wie eerst wil verbreden en dan pas kiezen, kan ook terecht bij de MECE Probleem Structuur Coach skill, die een probleem opdeelt in vakjes die elkaar niet overlappen en samen alles dekken.

De valkuil komt van Eric Ries. The Lean Startup uit 2011 beschrijft de 5 waarom methode in productontwikkeling en introduceert de term Five Blames voor de ketting die elke laag naar een persoon wijst. Ries koppelde er ook een investeringsregel aan: de moeite die je in een maatregel steekt moet in verhouding staan tot de ernst van het probleem, zodat je niet na een klein incident een halfjaarsproject start.

De coachingskant komt van Mike Rother. Toyota Kata uit 2009 gaat over de manier waarop verbeteren en coachen binnen Toyota gestructureerd worden. Dat is relevant omdat een oorzaakanalyse zelden een eenmalige actie is: als je dezelfde vraagroutine elke week draait, wordt doorvragen een gewoonte in plaats van een incidentele oefening.

De waarschuwing komt van Sidney Dekker. The Field Guide to Understanding Human Error uit 2006 legt uit waarom oorzaakanalyses die bij een persoon eindigen onbruikbaar zijn. Menselijke fout is geen verklaring maar het punt waarop je moet gaan zoeken. Deze bron is de reden dat het schuldverbod in de skill geen beleefdheidsregel is maar een analysemiddel: zolang de ketting bij een naam eindigt, heb je de vraag nog niet beantwoord.

Ook zonder de skill te installeren kun je met deze principes je eigen analyses verbeteren: maak het probleem eerst meetbaar, label per laag hoe zeker je bent, en dwing jezelf de laatste laag als proces te formuleren in plaats van als persoon.

Daarna is het gebruik simpel: beschrijf het probleem zoals je het ervaart, met wat je aan cijfers of logs hebt. Hoe rauwer, hoe beter, zolang er maar echte informatie in zit. Hij vraagt zelf na wat er nog ontbreekt en gaat verder met wat er wel is. Loopt het installeren ergens vast, dan staat de volledige uitleg per omgeving in Claude skills installeren, inclusief de veelvoorkomende fouten met mappen en rechten. En wil je breder leren werken met AI, dan vind je in de kennisbank de achtergrondartikelen.

Twee bijstellingen die het bestand zelf noemt, en die veel mensen missen. Je mag eerder stoppen dan vijf lagen als je al bij een oorzaak zit waar je invloed op hebt, mits je zegt dat je stopt en waarom. En je mag verder gaan dan vijf lagen als de vijfde laag nog steeds een symptoom is. Bij incidenten met veiligheids of financiele impact voegt de skill bovendien een extra laag toe die niet over de oorzaak gaat maar over detectie: waarom werd dit niet eerder opgemerkt. Die vraag levert vaak een tweede maatregel op die los staat van de eerste.

Er zijn ook situaties waarin je hem beter laat liggen, en de skill zegt dat zelf in zijn frontmatter. Niet tijdens een lopend incident: dan blus je eerst en analyseer je daarna, want een analyse tijdens een storing kost aandacht die je nodig hebt om hem te stoppen. Bij brainstormsessies waarin je juist opties wilt verbreden werkt hij averechts, want deze methode brengt terug in plaats van uit te waaieren. Teksten schrijven doet hij ook niet. En niet voor meerdere problemen tegelijk.

Nog een eerlijke grens die niet in het bestand staat maar wel in de praktijk telt: de skill maakt je analyse beter, niet je organisatie. Als de worteloorzaak ligt bij een beslissing die iemand boven je heeft genomen en niet wil terugdraaien, dan heb je een scherpe analyse en nog steeds hetzelfde probleem. Wat de skill dan wel doet, is dat scherp op papier zetten, met een verificatiestap eronder, zodat het gesprek over feiten gaat in plaats van over indrukken. Wil je van een oorzaak naar prioriteit, dan is de Pareto Analist skill de logische volgende stap: die bepaalt welke oorzaken het grootste deel van het probleem verklaren.

Zit het probleem dat je onderzoekt aan de voorkant, bij te weinig aanvragen in plaats van bij de doorlooptijd erna, dan begint het werk ergens anders: bij gevonden worden door de mensen die je zoeken. De gratis SEO scan laat in enkele seconden zien waar je site staat. En wil je doorpraten over wat AI verder voor je bedrijf kan doen, van losse skills tot volledige automatisering, dan doen we dat gewoon in een gesprek.