Home / Blog / Een blameless post-mortem uitvoeren

Operaties

Hoe voer je een blameless post-mortem uit? Een praktische gids

Een praktische gids voor een blameless post-mortem na een operationele storing: wanneer je het houdt, de agenda, de tijdlijn, de 5 keer waarom, actiepunten met eigenaren en opvolging.

1 oktober 2026 · 6 min lezen

Een post-mortem is een gestructureerde evaluatie die je houdt nadat er iets is misgegaan — een gemiste levering, een systeemstoring, een bijna-ongeval, een mislukte omschakeling. Een blameless post-mortem (zonder schuldvraag) voegt één regel toe: het doel is te begrijpen hoe de storing mogelijk werd, niet te bepalen wie je straft. Mensen nemen redelijke beslissingen met de informatie en de druk die ze op dat moment hadden. Als ze bang zijn voor beschuldigingen, verzwijgen ze details, en de volgende storing komt met dezelfde oorzaken.

Wat „blameless” echt betekent

Het betekent niet zonder gevolgen of zonder verantwoordelijkheid. Het betekent dat je leren en disciplinaire maatregelen scheidt. Individuen blijven verantwoordelijk voor het oplossen en opvolgen; de evaluatie zelf kijkt naar systemen, processen, hulpmiddelen, overdrachten en prikkels. Vraag dus niet „Wie maakte de fout?”, maar „Wat maakte deze fout makkelijk te maken en moeilijk te ontdekken?”

Wanneer houd je er een?

Houd een post-mortem wanneer de impact een vooraf afgesproken drempel overschrijdt. Typische aanleidingen:

• Gevolgen voor de klant, zoals een te late of verkeerde bestelling of downtime
• Aanzienlijke financiële schade, herstelwerk of verspilling
• Een veiligheidsincident of ernstig bijna-ongeval
• Dataverlies, een compliance-overtreding of een beveiligingsincident
• Een storing die terugkeert, ook als elk geval klein is

Streef naar een bijeenkomst binnen twee tot vijf werkdagen: vroeg genoeg dat de herinneringen vers zijn, laat genoeg dat het team heeft kunnen uitrusten en de acute brand geblust is.

Voorbereiding vóór de bijeenkomst

Wijs een neutrale gespreksleider aan — bij voorkeur iemand die er niet direct bij betrokken was — en een notulist. Verzamel eerst het ruwe bewijs: logs, berichten, tickets, dienstnotities, foto’s. Vraag deelnemers om vooraf in hun eigen woorden op te schrijven wat ze zagen en deden, zodat de eerste sprekers niemand anders beïnvloeden. Nodig de mensen uit die dicht bij het voorval stonden, plus een of twee uit aanpalende teams; houd de groep klein genoeg om te praten, meestal minder dan tien.

Een eenvoudige agenda (60–90 minuten)

• Spelregels (5 min): maak duidelijk dat de evaluatie blameless is, dat het om leren gaat en dat feiten vóór meningen komen.
• Samenvatting van de impact (5 min): wat er gebeurde, wie geraakt werd, hoe lang het duurde.
• Tijdlijn (20 min): reconstrueer de gebeurtenissen op volgorde.
• Bijdragende factoren en grondoorzaak (25 min): graaf dieper in het waarom.
• Wat goed ging (5 min): noteer de reddingen, noodoplossingen en goede keuzes die herhaling verdienen.
• Actiepunten (15 min): spreek concrete verbeteringen, eigenaren en data af.
• Afsluiting (5 min): bevestig wie de samenvatting schrijft en verspreidt.

Bouw de tijdlijn op

Begin alleen met tijdstippen en feiten: wat er gebeurde, wat op dat moment bekend was, welke actie werd ondernomen en wat het resultaat was. Weersta in deze fase de neiging tot interpreteren. Een gedeelde tijdlijn brengt meestal verrassingen aan het licht — een vertraagde melding, een onduidelijke overdracht, een stap waarvan niemand wist dat die handmatig was. Markeer de punten waarop een andere beslissing mogelijk was en vraag welke informatie de persoon toen had, niet wat wij nu weten. Achteraf lijkt alles vanzelfsprekend.

Vind de grondoorzaak met de 5 keer waarom

Bij de 5-keer-waarom-methode vraag je steeds „waarom?” tot je van het symptoom bij een systemische oorzaak komt. Vijf is een richtlijn, geen regel; stop wanneer je iets bereikt wat je echt kunt veranderen. Een kort voorbeeld:

• De zending vertrok te laat. Waarom? De bestelling was met het verkeerde artikel ingepakt en moest opnieuw worden gepickt.
• Waarom werd het verkeerde artikel gepickt? De twee producten hebben bijna identieke etiketten.
• Waarom werd dat niet gecontroleerd? De scanstap wordt overgeslagen als de wachtrij lang is.
• Waarom wordt die overgeslagen? De scanner is traag en het team wordt afgerekend op doorvoer.
• Waarom is doorvoer de enige maatstaf? Het dashboard toont geen foutpercentages.

Merk op dat het antwoord niet is „de picker was slordig”. Echte storingen hebben meestal meerdere bijdragende oorzaken, dus forceer geen enkele „wortel”. Als de waarom-keten zich vertakt, volg dan elke tak.

Maak van bevindingen actiepunten met eigenaren

Een post-mortem zonder acties is slechts een gesprek. Goede actiepunten zijn concreet, klein genoeg om af te ronden en gekoppeld aan een geïdentificeerde oorzaak. Leg bij elk vast:

• Wat: een concrete verandering, zoals „een verplichte scanstap met visuele waarschuwing bij een afwijking toevoegen”
• Eigenaar: één persoon met naam, geen team
• Deadline: realistisch, met een prioriteit
• Hoe we weten dat het werkte: een meetbare controle

Geef de voorkeur aan oplossingen die het systeem veranderen — automatisering, checklists, betere standaardinstellingen, duidelijkere meldingen — boven „laten we iedereen eraan herinneren voorzichtiger te zijn”. Beperk de lijst tot wat het team echt kan opleveren: vijf afgeronde punten zijn beter dan vijftien vergeten punten.

Volg op, zodat het beklijft

Publiceer binnen enkele dagen een korte schriftelijke samenvatting: impact, tijdlijn, oorzaken en acties met eigenaren. Bewaar die op een doorzoekbare plek zodat toekomstige teams ervan kunnen leren. Loop openstaande acties in een vast overleg door tot elke actie is afgerond en controleer na enkele weken of de oplossing het probleem daadwerkelijk heeft verkleind. Deel de lessen buiten het directe team wanneer ze ook elders gelden.

Veelgemaakte fouten

• Op zoek gaan naar een schuldige en eindigen met „menselijke fout”.
• De bijeenkomst overslaan omdat het incident klein was of al is verholpen.
• Vage acties zonder eigenaar of deadline.
• Leidinggevenden die het gesprek domineren en jongere collega’s het zwijgen opleggen.
• Geen opvolging, waardoor het document wordt opgeborgen en vergeten.

De aanpak werkt alleen als acties net zo zorgvuldig worden gevolgd als het incident is geëvalueerd. In FulcrumGrid Command Center kun je het incident vastleggen, elke corrigerende actie aan een eigenaar met deadline toewijzen en teamoverstijgend zien wat er nog openstaat, zodat opvolging niet afhangt van iemands geheugen. Een eenvoudige gedeelde spreadsheet werkt ook, zolang iemand hem bijhoudt.

Veelgestelde vragen

Wat is een blameless post-mortem?

Een gestructureerde evaluatie na een operationele storing die zich richt op hoe systeem, processen en omstandigheden de storing mogelijk maakten, niet op wie de schuld krijgt. Mensen blijven verantwoordelijk voor opvolgacties, maar de evaluatie zelf is gericht op leren.

Wanneer moet je een post-mortem houden?

Telkens wanneer de impact een vooraf afgesproken drempel overschrijdt, zoals problemen voor klanten, hoge kosten, veiligheidsincidenten, dataverlies of compliancekwesties, of herhaalde kleine storingen. Kom binnen enkele werkdagen bijeen, zolang de herinneringen vers zijn.

Hoe werken de 5 keer waarom?

Je vraagt herhaaldelijk „waarom?”, uitgaande van het probleem, tot je een systemische oorzaak bereikt die je kunt veranderen. Vijf is een richtlijn; vertakken de antwoorden zich, volg dan elke tak in plaats van één grondoorzaak te forceren.

Wat maakt een actiepunt goed?

Het is concreet, gekoppeld aan een geïdentificeerde oorzaak, klein genoeg om af te ronden en heeft één eigenaar met naam, een deadline en een manier om te controleren of het werkte. Verander liever het systeem dan dat je eraan herinnert voorzichtiger te zijn.

Hoe volg je een post-mortem op?

Verspreid een korte schriftelijke samenvatting, volg elke actie tot afronding in een vast overleg en controleer na enkele weken of de oplossing het probleem heeft verkleind. Bewaar het document waar anderen het kunnen vinden.

← Terug naar de blog