Nach der Störung beginnt die eigentliche Servicearbeit

Eine IT-Störung endet nicht in dem Moment, in dem der Dienst wieder läuft. Für Nutzer ist der sichtbare Ausfall dann vorbei. Für das Service Management beginnt aber die entscheidende Frage: Was muss sich ändern, damit die nächste Störung schneller, klarer oder ganz anders behandelt wird?

Ein Postmortem ist eine Nachbesprechung nach einem Vorfall. Im IT-Betrieb geht es dabei nicht um Schuldsuche, sondern um eine verständliche Auswertung von Ablauf, Entscheidungen, Kommunikation und technischen Ursachen. Google beschreibt in seiner Site-Reliability-Engineering-Praxis besonders die blameless culture, also eine Kultur ohne persönliche Schuldzuweisung. Für ITSM-Generalisten ist daran wichtig: Der Bericht ist kein Technikarchiv, sondern ein Arbeitsauftrag für bessere Services.

Der Bericht darf nicht beim Zeitstrahl stehen bleiben

Viele Störungsberichte erzählen nur, wann ein Alarm kam, wann jemand reagierte und wann der Dienst wieder verfügbar war. Dieser Zeitstrahl ist wichtig, aber er reicht nicht. Er zeigt, was passiert ist. Er erklärt noch nicht, warum bestimmte Entscheidungen getroffen wurden, wer welche Information hatte und wo der Serviceprozess zu langsam oder zu unklar war.

Ein brauchbarer Bericht verbindet deshalb technische Fakten mit Betriebsfragen. Welche Nutzer waren betroffen? Welche Abhängigkeit wurde zuerst übersehen? Welche Meldung kam zu spät beim Service Desk an? Welche Eskalation funktionierte, welche nicht? Aus solchen Fragen entsteht Nutzwert für den nächsten Vorfall. Ohne sie bleibt der Bericht eine Chronik, die niemand öffnet, wenn es ernst wird.

Schuldsuche macht die nächste Störung wahrscheinlicher

Wenn eine Nachbesprechung vor allem klären soll, wer den Fehler gemacht hat, lernen Teams die falsche Lektion. Menschen werden vorsichtiger mit Informationen, Probleme werden beschönigt und kleine Warnsignale bleiben beim nächsten Mal eher unsichtbar. Eine blameless Nachbesprechung heißt nicht, dass Verantwortung verschwindet. Sie trennt persönliche Schuld von systemischer Verbesserung.

Der Unterschied ist praktisch. Statt zu fragen, warum eine Person falsch reagiert hat, fragt der Betrieb, welche Information gefehlt hat, welche Anleitung unklar war oder welche Entscheidung zu schwer an einer einzelnen Rolle hing. So entstehen bessere Alarmregeln, bessere Notfallpläne, klarere Zuständigkeiten und realistischere Trainings. Genau das macht den nächsten Service stabiler.

Service Desk und Kommunikation gehören in den Befund

Bei Störungen wird oft zuerst auf Technik geschaut. Für Nutzer zählt aber auch, ob sie früh genug informiert wurden, ob die Statusseite verständlich war und ob der Service Desk wusste, was er sagen durfte. Atlassian und PagerDuty betonen in ihren Incident-Management-Materialien, dass Postmortems Ursachen, Wirkung, Kommunikation und Folgemaßnahmen zusammenführen sollen. Das ist ein wichtiger Punkt für ITSM.

Ein Vorfall kann technisch sauber gelöst sein und kommunikativ trotzdem Schaden hinterlassen. Wenn der Service Desk keine klare Lage hatte, entsteht Unsicherheit. Wenn Fachbereiche unterschiedliche Aussagen bekommen, verliert der Betrieb Vertrauen. Wenn Statusmeldungen nur aus technischen Kürzeln bestehen, verstehen betroffene Nutzer nicht, ob sie warten, ausweichen oder selbst aktiv werden sollen.

Maßnahmen brauchen Eigentümer und Fristen

Der schwächste Teil vieler Nachbesprechungen ist die Maßnahmenliste. Dort stehen oft gute Absichten: Monitoring verbessern, Dokumentation aktualisieren, Prozess prüfen. Operativ hilft das erst, wenn jede Maßnahme einen Eigentümer, eine Frist und eine überprüfbare Wirkung bekommt. Sonst wird aus Lernen nur ein weiterer Eintrag im Aufgabenstapel.

ITIL stellt kontinuierliche Verbesserung als wiederkehrende Praxis dar, nicht als einmalige Reparatur. Genau so sollten Störungsberichte gelesen werden. Jede Maßnahme muss zeigen, welches Serviceproblem sie reduziert. Geht es um kürzere Erkennungszeit? Um bessere Nutzerinformation? Um weniger manuelle Übergaben? Um eine klarere Rückfallroute? Ohne diese Verbindung bleibt die Maßnahme abstrakt.

Ein guter Bericht zeigt auch, was gut funktioniert hat

Nach einem Ausfall wird verständlicherweise auf Fehler geschaut. Dennoch sollte der Bericht ausdrücklich festhalten, welche Teile des Betriebs geholfen haben. Vielleicht war die Rufbereitschaft schnell. Vielleicht war ein alter Notfallplan doch nützlich. Vielleicht hat eine Fachabteilung früh eine entscheidende Beobachtung geliefert. Solche Punkte sind keine Schönfärberei. Sie zeigen, welche Fähigkeiten bewahrt und ausgebaut werden sollten.

Gerade für Führungskräfte ist diese Balance wichtig. Wenn Postmortems nur Defizite zeigen, wirken sie wie Strafberichte. Wenn sie aber gute Reaktionen, Engpässe und nächste Verbesserungen nebeneinanderstellen, werden sie zu einem Instrument für Priorisierung. Dann lässt sich besser entscheiden, ob Geld in Monitoring, Dokumentation, Schulung, Automatisierung oder Lieferantensteuerung fließen muss.

Prüffragen für bessere Nachbesprechungen

• Welche Nutzerwirkung war zuerst sichtbar und wer hat sie erkannt?
• Welche Information fehlte dem Service Desk während der Störung?
• Welche Entscheidung hat die Wiederherstellung beschleunigt oder verzögert?
• Welche Abhängigkeit war nicht ausreichend dokumentiert?
• Welche Maßnahme hat einen konkreten Eigentümer und eine überprüfbare Wirkung?
• Welche gute Reaktion sollte beim nächsten Vorfall bewusst wiederholt werden?

Störungen lassen sich nicht vollständig vermeiden. Der Unterschied liegt darin, ob der Betrieb aus ihnen nur ein abgeschlossenes Ereignis macht oder eine konkrete Serviceverbesserung ableitet. Ein Postmortem ist dann stark, wenn es die Geschichte des Ausfalls in bessere Entscheidungen übersetzt. Genau dort beginnt nach der technischen Wiederherstellung die eigentliche Servicearbeit.

Quellen und Einordnung: Google SRE Book zu Postmortem-Kultur, Atlassian Incident Management zu Postmortems, PagerDuty Postmortem Process, AXELOS zu ITIL Continual Improvement. Stand der Quellenprüfung: 26.06.2026.