Wanneer er iets misgaat in een proces, is de verleiding groot om meteen de eerste schuldige aan te pakken. Lean leert ons het tegenovergestelde: zoek eerst de grondoorzaak, anders blijft het probleem terugkomen. Twee tools werken hiervoor uitstekend samen: het Ishikawa-diagram en 5×waarom.

Het Ishikawa-diagram staat ook bekend als het visgraatdiagram, omdat de tekening op een visgraat lijkt. Helemaal rechts, in de "kop" van de vis, schrijf je het probleem dat je wilt oplossen. De grote "graten" die schuin van de ruggengraat aftakken, zijn categorieën waarin mogelijke oorzaken worden gegroepeerd. In een productie- of dienstverleningsomgeving gebruiken we hiervoor vaak de 6 M's:

• Man (kennis, training, alertheid), Methode (werkwijze, procedures), Machine (apparatuur, software), Materiaal (grondstoffen, onderdelen), Meting (data, controles) en Milieu (omgeving, werkplek).

Door per categorie te brainstormen, voorkom je dat het team blijft hangen bij één vermoede oorzaak. Je krijgt een breed, gestructureerd overzicht van alles wat aan het probleem kan bijdragen.

Maar een lijst met mogelijke oorzaken is nog geen oplossing. Combineer daarvoor het visgraatdiagram met 5×waarom: je kiest een waarschijnlijke oorzaak en blijft "waarom?" vragen (vuistregel: ongeveer vijf keer) totdat je bij de echte grondoorzaak uitkomt en niet slechts bij een symptoom.

Een voorbeeld dat veel MKB- en IT-medewerkers herkennen: facturen worden structureel te laat verstuurd. In het visgraatdiagram komen oorzaken naar boven onder Man (te weinig mensen), Methode (geen vaste dag) en Machine (de boekhoudsoftware is traag). Je pakt "factuur gaat te laat de deur uit" en vraagt: Waarom? De medewerker begint pas op vrijdag. Waarom? Hij krijgt zijn uren te laat door. Waarom? Projectmanagers leveren ze niet op tijd aan. Waarom? Er is geen reminder ingesteld. Waarom? Niemand is verantwoordelijk gemaakt voor dat moment. De grondoorzaak is dus niet een luie medewerker of trage software, maar een ontbrekende afspraak over verantwoordelijkheid. Zodra je dit aanpakt en een afspraak maakt, verdwijnt het probleem permanent. Behandel je alleen het symptoom (sneller typen), dan komt de vertraging volgende maand terug.

De 6 M's zijn een startpunt, geen wet van Meden en Perzen: pas ze aan op jouw situatie. Voor een dienstverlenend MKB-bedrijf werkt het vaak beter om categorieën te gebruiken als Mensen, Proces, Systemen, Klantinput, Communicatie en Externe partijen. Belangrijk is niet de exacte naam van elke tak, maar dat je systematisch verschillende invalshoeken langsloopt in plaats van meteen op de eerste verklaring te springen.

Een tweede praktijkvoorbeeld, gericht op klantcommunicatie: een webshop krijgt klachten dat retourzendingen "nooit" worden teruggestort. In het Ishikawa-diagram komen oorzaken naar voren onder Meting (geen overzicht van openstaande retouren), Methode (geen vaste verwerkingsdag) en Man (niemand voelt zich eigenaar). Met 5×waarom kom je uit bij: er is geen koppeling tussen het retourproces en de financiële administratie, waardoor retouren fysiek wel binnenkomen maar administratief onzichtbaar blijven. De grondoorzaak zit dus in een ontbrekende systeemkoppeling, niet in onwil van medewerkers. Deze inzichten voed je vervolgens weer terug in de Analyze-fase van DMAIC (les 6): 5×waarom en het Ishikawa-diagram zijn precies de tools die je daar gebruikt om van symptoom naar oorzaak te komen.

Doe deze analyse waar mogelijk niet alleen achter je bureau, maar samen met de mensen die het werk daadwerkelijk uitvoeren. Zij kennen de praktische obstakels die op een organigram of procesbeschrijving niet zichtbaar zijn — bijvoorbeeld dat een goedkeuringsformulier in de praktijk nooit binnen een dag wordt ondertekend omdat de betreffende manager structureel op locatie bij klanten is. Een grondoorzaakanalyse die alleen op papier wordt gedaan, mist vaak precies dit soort operationele realiteit.

Een valkuil bij 5×waarom is stoppen bij de eerste "menselijke" verklaring, zoals "de medewerker was onoplettend." Vraag in dat geval door: waarom kon onoplettendheid tot dit probleem leiden? Vaak ontdek je dat het systeem geen vangnet had voor menselijke fouten (denk aan Poka Yoke uit les 9) — en dat is een structureel probleem dat je kunt oplossen, in tegenstelling tot "wees voortaan opletttender," wat geen duurzame oplossing is.

Samenvatting: Het Ishikawa-diagram brengt structuur in het zoeken naar mogelijke oorzaken via categorieën als de 6 M's; 5×waarom graaft van symptoom naar grondoorzaak. Samen voorkomen ze dat je tijd steekt in het bestrijden van symptomen die telkens terugkeren.

Een laatste tip: schrijf oorzaken op als feitelijke observaties, niet als beschuldigingen. "De medewerker maakt fouten" leidt tot verdediging en weerstand in een team; "het formulier heeft geen verplichte velden voor kritieke gegevens" leidt tot een oplossing waar iedereen achter kan staan. Deze toon maakt grondoorzaakanalyse een constructief teamproces in plaats van een zoektocht naar een schuldige, en dat verschil bepaalt vaak of een team de tool blijft gebruiken of na één sessie weer laat liggen.

Verder lezen: zoek op "Ishikawa diagram template" voor invulbare voorbeelden, en op "Pareto-analyse" om te leren welke oorzaken de meeste impact hebben wanneer er meerdere kandidaten zijn.