Een team ziet een probleem, bedenkt een oplossing en bouwt die. Klinkt logisch, en toch gaat het zo vaak mis. De oplossing pakt een symptoom aan, het echte probleem blijft, en een half jaar later staat iedereen weer op dezelfde plek.
DMAIC is gemaakt om die valkuil te vermijden. Het is een verbetercyclus die je dwingt eerst te begrijpen vóór je oplost.
Voor een Customer Journey Expert is DMAIC waardevol omdat het de discipline geeft om niet op het eerste idee te springen, maar de oorzaak echt te vinden.
DMAIC staat voor Define, Measure, Analyze, Improve en Control: de vijf fasen van gestructureerd verbeteren binnen Lean Six Sigma. De methode dwingt je eerst het probleem en de data scherp te krijgen vóór je een oplossing bedenkt, zodat je de oorzaak raakt in plaats van het symptoom. Voor een CJE is DMAIC het tegengif tegen de neiging om meteen naar een oplossing te springen.
Wat DMAIC betekent
DMAIC is de kernmethode van Lean Six Sigma, de gecombineerde aanpak voor het wegnemen van verspilling (Lean) en variatie (Six Sigma).
De volgorde is geen suggestie maar een wet: je slaat geen fase over. Juist die discipline maakt het verschil met losse brainstorms.
De vijf fasen van DMAIC
- Define, wat is precies het probleem, voor wie, en wat is het doel?
- Measure, hoe groot is het probleem in cijfers? Eerst de nulmeting;
- Analyze, wat is de werkelijke oorzaak, niet de aanname?
- Improve, welke oplossing pakt die oorzaak aan, en werkt dat?
- Control, hoe houden we de verbetering vast als de aandacht verslapt?
De eerste drie fasen gaan volledig over begrijpen. Pas in Improve komt de oplossing, een verhouding die de meeste teams precies omdraaien.
Waarom DMAIC de oorzaak raakt
De analyse-fase is het hart. Hier scheidt DMAIC symptoom van oorzaak met technieken als de "vijf keer waarom": je blijft doorvragen tot je niet langer bij een gevolg uitkomt maar bij een grondoorzaak.
Dit sluit direct aan op journeywerk. Een dieptepunt op een customer journey map is een symptoom; DMAIC is de manier om de oorzaak eronder boven tafel te krijgen, vaak met behulp van value stream mapping in de meet-fase.
De fase die iedereen overslaat
Control is de meest verwaarloosde fase, en daardoor de reden dat verbeteringen verdampen. Een proces dat je verbetert maar niet borgt, glijdt langzaam terug naar de oude situatie zodra niemand meer kijkt. Borgen betekent: een meting die blijft lopen, een eigenaar die zich verantwoordelijk voelt, en een signaal als het misgaat.
Voor een CJE is dit cruciaal. Een verbetering die je niet kunt aantonen over tijd, telt in de praktijk niet mee.
Een voorbeeld: vijf keer waarom
Een team ziet dat aanvragen vaak te laat worden afgehandeld. De reflex: "we hebben meer mensen nodig". Maar in de analyze-fase van DMAIC stelt een CJE vijf keer de vraag waarom.
Waarom te laat? Omdat dossiers blijven liggen. Waarom blijven ze liggen? Omdat ze wachten op een ontbrekend document. Waarom ontbreekt dat? Omdat het pas laat in het proces wordt opgevraagd. Waarom pas laat? Omdat het formulier er niet om vraagt. Waarom niet? Omdat niemand het formulier ooit heeft herzien.
De grondoorzaak is dus niet "te weinig mensen", maar "een formulier dat te laat om informatie vraagt". De oplossing, dat document meteen opvragen, kost niets en lost het probleem bij de wortel op. Vijf simpele vragen voorkwamen een dure, verkeerde investering in extra capaciteit.
Het gereedschap per fase
Elke DMAIC-fase heeft zijn eigen gereedschap. In Define gebruik je een SIPOC om de scope en de klant scherp te krijgen. In Measure leun je op een nulmeting en op value stream mapping om de doorlooptijd hard te maken.
In Analyze zijn de vijf keer waarom en het visgraatdiagram je vrienden, het laatste clustert mogelijke oorzaken langs categorieën als mens, methode, machine en materiaal. In Improve bouw en test je de oplossing, het liefst klein, met een pilot.
En in Control borg je met een dashboard, een standaard werkwijze en een eigenaar. Dat gereedschap maakt DMAIC concreet: het is geen abstract stappenplan, maar een gevulde gereedschapskist waarin elke fase precies de juiste tang heeft.
DMAIC versus PDCA
Wie zich in verbetermethodes verdiept, stuit naast DMAIC al snel op PDCA: Plan, Do, Check, Act. Beide zijn verbetercycli, en ze worden vaak door elkaar gehaald. Het verschil bepaalt wanneer je welke pakt.
PDCA is licht en snel. Je bedenkt een verbetering (Plan), voert hem klein uit (Do), kijkt of het werkte (Check) en besluit of je het breder uitrolt of bijstelt (Act). Het is ideaal voor kleine, snelle experimenten waarbij de oorzaak al redelijk duidelijk is. De cyclus draait in dagen of weken en nodigt uit tot herhalen.
DMAIC is zwaarder en grondiger. Door de aparte Measure- en Analyze-fasen dwingt het je de oorzaak echt te bewijzen vóór je iets verandert. Dat maakt het de betere keuze voor hardnekkige, complexe problemen waar de oorzaak níet vanzelfsprekend is en een verkeerde gok duur uitpakt.
Een handige vuistregel: gebruik PDCA voor de kleine, dagelijkse verbeteringen en DMAIC voor de grote, taaie vraagstukken waar je je oplossing hard moet kunnen onderbouwen. Ze sluiten elkaar niet uit, sterker nog, binnen de Improve-fase van DMAIC draai je vaak een paar snelle PDCA-rondjes om je oplossing te verfijnen. De methodes zijn lagen van hetzelfde idee: verbeter op basis van bewijs, niet op onderbuik.
De valkuil: de oplossing al klaar hebben
De grootste vijand van DMAIC is de oplossing die al klaarligt voordat de cyclus begint. "We weten heus wel wat het probleem is, laten we gewoon X bouwen." Het klinkt daadkrachtig, maar het ondermijnt de hele methode.
Want als je de uitkomst al hebt bepaald, worden Measure en Analyze een vinkje in plaats van onderzoek. Je meet selectief wat je vermoeden bevestigt en negeert wat het tegenspreekt, de bevestigingsvalkuil in volle werking. De data wordt versiering bij een besluit dat al genomen was.
De discipline van DMAIC is juist om die zekerheid even op te schorten. Behandel je vermoeden als één hypothese onder meerdere, en laat de data uitwijzen of je gelijk had. Verrassend vaak blijkt de echte oorzaak een andere dan de voor de hand liggende, en dan had die kant-en-klare oplossing het probleem nooit opgelost.
Voor een CJE is dit een houding, geen techniek. Het vergt de moed om "ik weet het nog niet" te zeggen in een kamer vol mensen die snelheid willen. Maar precies die terughoudendheid, dat eerst bewijzen vóór bouwen, is wat een verbetering laat slagen waar een gok zou falen. Zoals de vuistregel luidt: een oplossing bedacht vóór de analyse is een gok met een dasje om.
Wat dit betekent voor de CJE
DMAIC geeft een CJE structuur en geloofwaardigheid. Je laat zien dat je verbetert op basis van bewijs, niet op onderbuik, en dat je je resultaat kunt vasthouden. Hoe je deze methodische kant ontwikkelt, lees je in Customer Journey Expert worden.