Der Vorfall ist seit zwei Stunden behoben, und im Chat herrscht bereits wieder Alltag. Eine Nachbereitung findet nicht statt, weil niemand Lust hat, öffentlich zu erklären, wer welchen Fehler gemacht hat. Genau diese Vermeidung sorgt dafür, dass sich derselbe Fehler in einigen Monaten wiederholt.

Ein Postmortem ohne Schuldzuweisung löst dieses Dilemma nicht durch Verschweigen, sondern durch eine klare Struktur: Rollen während der Störung, Kommunikation nach außen, und eine Nachbereitung, die Ursachen benennt, ohne Personen an den Pranger zu stellen.

Dieser Text beschreibt diese Struktur mit einer Vorlage für den Bericht und der Regel, dass jede Maßnahme am Ende einen Verantwortlichen und ein Datum bekommt, ohne die gehört keine Maßnahme als abgeschlossen gilt.

Der Ablauf in Kürze

• Während der Störung: eine Person führt, eine kommuniziert, der Rest behebt.
• Nachbereitung: innerhalb von zwei bis drei Werktagen, nicht Wochen später.
• Sprache: Ursache statt Schuld, System statt Person.
• Vorlage: sechs Felder, immer in derselben Reihenfolge.
• Maßnahmen: jede mit Name und Datum, sonst zählt sie nicht.
• Teilnehmerkreis: alle direkt Beteiligten, keine Zuschauer.
• Nachverfolgung: ein fester Termin, an dem offene Maßnahmen erneut geprüft werden.

Warum die meisten Postmortems ihren Zweck verfehlen

Ein Postmortem soll aus einem Vorfall lernen, nicht ihn wiederholen. In der Praxis scheitert das an zwei gegensätzlichen Fehlern: entweder wird niemand konkret benannt, und das Dokument bleibt so vage, dass niemand etwas daraus lernt, oder es wird zu einer Suche nach der schuldigen Person, die künftige Berichte unehrlicher macht.

Beide Fehler haben dieselbe Wurzel: die fehlende Trennung zwischen der Ursache eines Fehlers und der Person, die ihn ausgelöst hat. Ein System, das einen einzelnen Fehltritt zu einer Störung eskalieren lässt, hat ein strukturelles Problem, unabhängig davon, wer konkret geklickt hat.

Grundlagen einer Umgebung, in der Fehler offen benannt werden können, beschreibt der Überblick zur Fehlerkultur. Ohne eine solche Grundhaltung bleibt jede noch so gute Vorlage wirkungslos.

Ein dritter, seltener genannter Fehler ist das vollständige Fehlen jeder Nachbereitung, meist aus Zeitmangel im laufenden Betrieb. Dieser Fehler ist der teuerste von allen, weil er nicht nur den Lerneffekt verhindert, sondern signalisiert, dass Störungen als Normalzustand hingenommen werden.

Rollen während einer Störung: wer tut was

Sobald eine Störung erkannt ist, sollte eine Person die Führung übernehmen, ohne selbst an der Behebung zu arbeiten. Diese Person koordiniert, priorisiert und behält den Überblick, während andere konkret am Problem arbeiten.

Eine zweite Rolle kümmert sich ausschließlich um Kommunikation, intern wie extern. Diese Trennung verhindert, dass die Person, die gerade am Problem arbeitet, gleichzeitig Statusanfragen beantworten muss und dabei den Fokus verliert.

In einem kleinen Team übernimmt eine Person mitunter beide Rollen gleichzeitig, sofern der Vorfall überschaubar bleibt. Bei größeren Störungen sollte diese Aufteilung jedoch von Anfang an klar zugewiesen sein, nicht erst mitten im Vorfall improvisiert werden.

Wie sich Systembeobachtung so aufbauen lässt, dass eine Störung überhaupt rechtzeitig auffällt, bevor diese Rollen gebraucht werden, ist eine vorgelagerte Frage, die eng mit der hier beschriebenen Nachbereitung zusammenhängt. Wie technische Prioritäten insgesamt gesetzt werden, beschreibt der Beitrag über Technologie in der Produktentwicklung.

Kommunikation nach außen während des Vorfalls

Kunden und Nutzer sollten früh informiert werden, auch wenn die Ursache noch unklar ist. Eine kurze Meldung, dass ein Problem bekannt ist und daran gearbeitet wird, wirkt vertrauensbildender als Schweigen bis zur vollständigen Klärung.

Updates während des Vorfalls sollten in regelmäßigen Abständen erfolgen, auch wenn der Inhalt lautet, dass sich der Stand nicht verändert hat. Ein ausbleibendes Update wird häufiger als schlechtes Zeichen gewertet als ein Update ohne neuen Fortschritt.

Nach der Behebung gehört eine abschließende Meldung dazu, die kurz beschreibt, was passiert ist und dass an einer dauerhaften Lösung gearbeitet wird. Details zur Ursache gehören in dieser Phase noch nicht zwingend hinein, das ausführliche Postmortem folgt separat.

Vertraglich zugesicherte Reaktionszeiten sollten in dieser Phase im Blick behalten werden, auch wenn die endgültige Bewertung solcher Zusagen in eine vertragliche Prüfung gehört. Für die Kommunikation selbst zählt vor allem Verlässlichkeit im Rhythmus der Updates, nicht die juristische Feinheit der Formulierung.

Postmortem Vorlage: der Aufbau in sechs Feldern

1. Zeitleiste. Wann begann die Störung, wann wurde sie bemerkt, wann behoben.
2. Auswirkung. Wer war betroffen, in welchem Umfang, wie lange.
3. Ursache. Was hat technisch oder organisatorisch zur Störung geführt.
4. Was gut lief. Welche Reaktion hat funktioniert und sollte beibehalten werden.
5. Maßnahmen. Was wird konkret geändert, mit Namen und Datum.
6. Offene Fragen. Was ist noch unklar und wird weiter untersucht.

Diese sechs Felder in fester Reihenfolge sorgen dafür, dass kein Bericht vorschnell bei der Ursache endet, ohne konkrete Maßnahmen und Verantwortliche zu benennen.

Feld eins: Zeitleiste der Ereignisse

Die Zeitleiste hält fest, wann welches Ereignis eintrat, in möglichst genauen Zeitangaben. Sie beginnt mit dem ersten technischen Anzeichen, nicht erst mit dem Moment, in dem jemand es bemerkt hat.

Diese Unterscheidung ist wichtig, weil die Lücke zwischen dem tatsächlichen Beginn und dem Bemerken oft die aufschlussreichste Stelle des ganzen Berichts ist. Eine lange Lücke zeigt eine Schwäche in der Beobachtung, unabhängig von der eigentlichen Ursache der Störung.

Die Zeitleiste endet mit der vollständigen Behebung, nicht mit dem ersten Anzeichen der Besserung. Zwischen beiden Punkten liegt häufig noch relevante Zeit, die im Bericht sonst verloren geht.

Feld zwei: Auswirkung in konkreten Zahlen

Die Auswirkung sollte so konkret wie möglich beschrieben werden: betroffene Funktion, ungefährer Anteil betroffener Nutzer, Dauer der Beeinträchtigung. Vage Formulierungen wie „einige Nutzer waren betroffen“ liefern keine brauchbare Grundlage für die spätere Priorisierung von Maßnahmen.

Wo genaue Zahlen fehlen, genügt eine ehrliche Schätzung mit Angabe der Unsicherheit. Eine geschätzte Zahl mit klarer Kennzeichnung ist nützlicher als eine präzise wirkende Zahl, die in Wahrheit geraten ist.

Dieses Feld dient auch dazu, den Vorfall im Rückblick richtig einzuordnen. Ein Vorfall mit geringer tatsächlicher Auswirkung sollte nicht dieselbe Aufmerksamkeit binden wie einer mit erheblicher Auswirkung, auch wenn beide subjektiv gleich stressig erlebt wurden.

Feld drei: Ursache, nicht Schuld

Die Ursache wird als Kette von Bedingungen beschrieben, nicht als Handlung einer einzelnen Person. Statt „Person X hat eine falsche Einstellung gesetzt“ steht im Bericht, welche Prüfung fehlte, die diese Einstellung hätte auffangen können.

Diese Formulierung ist kein Euphemismus, sondern eine andere Blickrichtung: Eine einzelne Handlung führt fast nie allein zu einer Störung. Erst das Fehlen einer Prüfung, einer Warnung oder einer zweiten Freigabe lässt aus einem kleinen Fehler eine sichtbare Störung werden.

Der Überblick zur Ursachenanalyse beschreibt Verfahren, mit denen sich mehrere Ursachenebenen systematisch auseinanderhalten lassen, von der unmittelbaren Auslösung bis zur eigentlichen strukturellen Lücke.

Wer bei der ersten genannten Ursache stehen bleibt, findet meist eine Person. Wer eine Ebene tiefer fragt, findet meist ein fehlendes System. Diese zweite Ebene ist die, die ein Postmortem tatsächlich beheben sollte.

Feld vier: was gut funktioniert hat

Ein Postmortem, das ausschließlich Probleme auflistet, wirkt entmutigend und verzerrt zudem das Bild. Fast jede Störung enthält auch Punkte, die funktioniert haben: eine schnelle Erkennung, eine klare Kommunikation, eine funktionierende Rückfallebene.

Diese Punkte zu benennen, hat einen praktischen Nutzen: Sie zeigen, welche bestehenden Maßnahmen sich bewährt haben und deshalb beibehalten oder sogar ausgeweitet werden sollten, statt bei der nächsten Überarbeitung versehentlich gestrichen zu werden.

Dieses Feld wirkt außerdem auf die Bereitschaft, ehrlich über Fehler zu sprechen. Ein Bericht, der auch Erfolge benennt, wird als fairer empfunden als einer, der ausschließlich Kritik enthält.

Feld fünf: Maßnahmen mit Namen und Datum

Jede Maßnahme im Bericht braucht eine Person, die sie umsetzt, und ein Datum, bis wann sie umgesetzt sein soll. Eine Maßnahme ohne beides ist in der Praxis keine Maßnahme, sondern eine Absichtserklärung, die selten Bestand hat.

Maßnahmen sollten konkret und überprüfbar formuliert sein. „Die Überwachung verbessern“ lässt sich nicht überprüfen. „Eine Warnung einrichten, die bei Überschreiten von X auslöst, bis Datum Y, verantwortlich Person Z“ lässt sich eindeutig als erledigt oder offen einstufen.

Nicht jede denkbare Maßnahme muss umgesetzt werden. Eine bewusste Entscheidung, eine Maßnahme aus Aufwandsgründen nicht umzusetzen, ist eine legitime Option, sollte aber ebenfalls dokumentiert werden, damit sie nicht in der nächsten Störung erneut diskutiert werden muss.

Beispielvorlage im Überblick

Feld	Leitfrage	Typischer Umfang
Zeitleiste	Was geschah wann	fünf bis zehn Zeilen
Auswirkung	Wer war wie stark betroffen	ein Absatz
Ursache	Welche Bedingungen führten zur Störung	ein bis zwei Absätze
Was gut lief	Welche Reaktion hat funktioniert	wenige Zeilen
Maßnahmen	Was ändert sich, mit wem, bis wann	Liste mit klaren Punkten

Diese Vorlage passt auf ein bis zwei Seiten. Ein längerer Bericht wird seltener vollständig gelesen und verfehlt damit einen Teil seines Zwecks.

Warum Schuldzuweisung das Verfahren zerstört

Sobald ein Postmortem einmal dazu geführt hat, dass eine Person öffentlich für einen Fehler verantwortlich gemacht wurde, ändert sich das Verhalten im gesamten Team. Zukünftige Berichte werden vorsichtiger formuliert, unangenehme Details werden weggelassen, und die Ursachenanalyse verliert an Tiefe.

Dieser Effekt tritt schnell ein und lässt sich nur langsam wieder rückgängig machen. Ein einziger schlecht geführter Bericht kann die Ehrlichkeit vieler künftiger Berichte beschädigen, weit über den ursprünglichen Vorfall hinaus.

Die Verantwortung für diese Kultur liegt bei der Person, die den Termin moderiert. Sie sollte konsequent auf System- statt Personenformulierungen achten und Abweichungen davon im Termin selbst korrigieren, nicht erst im Nachhinein.

Auch außerhalb des Termins wirkt diese Haltung nach: Wer weiß, dass ein ehrlich zugegebener Fehler zu einer sachlichen Verbesserung führt statt zu einer öffentlichen Bloßstellung, meldet kleinere Probleme künftig früher, bevor sie zu einer größeren Störung anwachsen.

Der Termin selbst: Ablauf und Teilnehmerkreis

Der Termin findet innerhalb von zwei bis drei Werktagen nach dem Vorfall statt, solange die Details noch frisch sind. Ein zu später Termin verliert Genauigkeit, weil sich Erinnerungen an technische Details schnell verflüchtigen.

Teilnehmen sollten alle direkt an der Behebung beteiligten Personen, nicht das gesamte Unternehmen. Ein zu großer Teilnehmerkreis erschwert offene Gespräche über Fehler und verlangsamt den Termin unnötig.

Der Termin selbst sollte anhand der Vorlage strukturiert ablaufen, Feld für Feld, mit einer Person, die den Ablauf hält und darauf achtet, dass die Diskussion nicht vorzeitig bei der Ursache steckenbleibt, ohne zu Maßnahmen zu kommen.

Nachverfolgung: was aus den Maßnahmen wird

Ein Postmortem ohne Nachverfolgung ist ein Dokument ohne Wirkung. Ein fester Termin, etwa alle zwei Wochen, prüft den Stand offener Maßnahmen aus vergangenen Berichten und macht sichtbar, welche liegen geblieben sind.

Maßnahmen, die wiederholt verschoben werden, verdienen eine ehrliche Entscheidung: entweder Priorität erhöhen und tatsächlich umsetzen, oder bewusst als nicht umsetzbar einstufen und aus der Liste nehmen. Ein dauerhaftes Verschieben ohne Entscheidung ist die schlechteste aller Optionen.

Wie sich solche wiederkehrenden Prüftermine sinnvoll in den Kalender einbauen lassen, ohne selbst zur Belastung zu werden, beschreibt der Beitrag über das Dokumentieren von Abläufen. Dieselbe Disziplin gilt auch für offene Maßnahmen aus Postmortems.

Ein Bericht, dessen Maßnahmen zuverlässig abgearbeitet werden, wird im Team schnell ernst genommen. Ein Bericht, dessen Maßnahmen regelmäßig versanden, verliert diese Ernsthaftigkeit ebenso schnell, und mit ihr die Bereitschaft, künftige Berichte gründlich auszuarbeiten.

Häufige Fragen

Braucht jede Störung ein vollständiges Postmortem?

Kleinere Vorfälle mit geringer Auswirkung können mit einer verkürzten Version auskommen. Ein vollständiger Bericht lohnt sich vor allem bei Störungen mit spürbarer Auswirkung oder wiederkehrendem Muster.

Wer sollte den Termin moderieren?

Am besten eine Person, die nicht selbst unmittelbar für die Ursache verantwortlich war. Diese Distanz erleichtert eine sachliche Führung des Gesprächs.

Sollte der Bericht öffentlich im Unternehmen geteilt werden?

In den meisten kleinen Teams ja, weil der Lerneffekt größer ist als das Risiko. Bei sensiblen Kundendaten kann eine gekürzte Fassung für die breitere Belegschaft sinnvoll sein.

Was, wenn die Ursache menschliches Versagen war?

Auch dann liegt der Fokus auf der fehlenden Absicherung, die diesen Fehler hätte abfangen können. Menschliches Versagen ist eine Konstante, ein System, das dagegen keine Schutzschicht hat, ist die eigentliche Lücke.

Wie geht man mit externen Dienstleistern als Ursache um?

Die interne Vorlage bleibt gleich, ergänzt um die Frage, welche eigene Abhängigkeit von diesem Dienstleister bestand und ob sie reduziert werden sollte.

Wie lange sollten Postmortems aufbewahrt werden?

Dauerhaft, in einer durchsuchbaren Ablage. Wiederkehrende Ursachenmuster lassen sich nur erkennen, wenn frühere Berichte tatsächlich wieder auffindbar sind.

Was, wenn im Team Unsicherheit über die eigene Fehlerkultur besteht?

Ein guter Test ist die letzte Nachbereitung: Wurde dort offen über die eigentliche Ursache gesprochen, oder blieb das Gespräch bei Andeutungen stehen? Die Antwort zeigt zuverlässiger, wo ein Team steht, als jede Selbsteinschätzung.

Ein Postmortem ohne Schuldzuweisung ist kein milderes Verfahren, sondern ein wirksameres. Wer Ursachen statt Personen benennt und jede Maßnahme mit Namen und Datum versieht, lernt aus einer Störung tatsächlich etwas, statt sie nur zu überstehen.