Der Ausfall ist passiert. Der Dienstleister hat irgendwas repariert, die Leute sind zurück an der Arbeit, alle atmen auf. Drei Wochen später — dasselbe Drehbuch, andere Maske, gleiche Ursache. Das ist vermeidbar, aber nur, wenn zwischen einem Feuer und dem nächsten eine Stunde für das übrig bleibt, was Konzerne Post-mortem nennen und was ein KMU meistens gar nicht nennt.
In einem großen Unternehmen ist ein Postmortem ein formalisiertes Verfahren mit Vorlage, Moderator und Ticket in Jira. In einem 10- bis 30-Personen-Betrieb bekommst du dasselbe Ergebnis an einem Tisch, auf einem Blatt Papier, in einer Stunde. Es geht nicht um Dokumentation. Es geht darum, dass dasselbe Kabel nicht zweimal im selben Monat rausfällt.
Warum das im KMU nicht von allein passiert
In einem KMU endet ein Ausfall in der Regel so: der IT-Mensch (oder der Dienstleister) sagt „das war das RAID / die Platte / die USV / der Strom", hakt das Ticket ab und geht weiter. Niemand fragt, warum keiner bemerkt hat, dass die Platte seit einer Woche Fehler wirft. Niemand prüft, warum das Backup, das die Lage retten sollte, plötzlich 11 Tage alt war. Das Gespräch bleibt kurz, denn ein langes Gespräch bedeutet Schuldsuche — und die will jeder vermeiden.
Und genau da liegt die Falle. Wenn ein Postmortem dazu dient, Schuld zuzuweisen, sagt niemand die Wahrheit, und in einem Monat bekommst du denselben Ausfall aus einer anderen Ecke. Wenn ein Postmortem dazu dient, den Prozess zu reparieren, sagen die Leute, was sie gesehen haben — weil sie wissen, dass niemand sie dafür rauswirft.
Ein konkretes Beispiel — ein 12-Personen-Planungsbüro
Bei einem unserer Kunden lief es so. Ein 12-Personen-Planungsbüro (Elektroplanung), ein Dateiserver im Schrank an der Rezeption, das ERP Comarch Optima gehostet beim Partner. Montagmorgen kann niemand die Zeichnungen öffnen — die NAS-Platte ist am Wochenende gestorben, der RAID-Controller gleich mit, ein Teil der Arbeit der letzten drei Tage ist weg.
Der IT-Dienstleister kam, tauschte das NAS, stellte die Daten aus einem 4 Tage alten Backup wieder her. Schaden: 22 Stunden Arbeit von zwei Planern, die Schemata neu gezeichnet haben, ein verschobener Termin von einer Woche, der Kunde hat mit dem Chef in einem Ton gesprochen, den der Chef lieber nicht noch einmal hören möchte. Materieller Schaden — einfach zu rechnen — rund 6 500 PLN. Reputationsschaden — hat niemand gerechnet.
Statt das Ticket zu schließen, haben wir ein einstündiges Postmortem gemacht. Es kamen fünf Dinge dabei heraus:
- Die S.M.A.R.T.-Warnungen der Platte gingen an das Postfach des IT-Mitarbeiters, der eine Woche im Urlaub war. Niemand sonst hat sie je gesehen.
- Das Backup lief täglich, aber es kopierte auf eine zweite Partition desselben NAS. Als der Controller starb, war auch das Backup weg.
- Die Offsite-Kopie lief einmal pro Woche, freitags abends. Zwischen Freitag 15:00 und dem Absturz waren 4 Tage Arbeit angefallen, die niemand mehr zurückholen konnte.
- Niemand wusste, dass das NAS 6 Jahre alt war. Es gab kein Hardware-Register mit Kaufdaten.
- Der „Notfallplan" existierte im Kopf des IT-Mitarbeiters. Ohne ihn wusste niemand einmal, wo der Schlüssel zum Serverschrank liegt.
Nichts davon brauchte neues Budget. Es brauchte einen halben Tag Aufräumen. Ein Jahr später, bei einem ähnlichen „Knacks" (dieses Mal eine SSD in einem anderen Server), dauerte die Wiederherstellung 90 Minuten aus einem Offsite-Backup von der Nacht davor. Der Ausfall hat sich wiederholt — die Folgen nicht.
Eine Ein-Stunden-Vorlage, die funktioniert
Du brauchst kein Tool. Ein DIN-A4-Blatt, ein Kugelschreiber, eine Stunde, alle, die im Ausfall irgendetwas gemacht haben (auch der Dienstleister, per Video ist okay). Vier Blöcke:
Timeline — was passiert ist, der Reihe nach. Nicht „was jemand glaubt, dass passiert ist", sondern was wir beobachtet haben: Uhrzeit der ersten Meldung eines Users, Uhrzeit der ersten IT-Reaktion, Uhrzeit des Fixes, Uhrzeit der vollständigen Wiederherstellung. Trockene Zahlen. Meist zeigt schon dieser Block, dass „der Ausfall dauerte 2 Stunden" Fiktion ist — die User standen seit 8:00 still, die Meldung ging um 10:15 raus, und die IT hat es erst um 11:30 erfahren.
Impact — was er tatsächlich gekostet hat. Wie viele Arbeitsstunden? Wie viele Transaktionen sind nicht durchgegangen? Wie viele Anrufe von Kunden? Welcher Termin ist verrutscht? Ohne das wird niemand auch nur 500 PLN in Vorbeugung stecken wollen, denn „es ist ja nichts passiert".
Root cause — warum, fünfmal hintereinander. Klassische „5 Whys". Warum ist das NAS gestorben? — Der Controller ist überhitzt. — Warum? — Der Lüfter hat nicht gedreht. — Warum nicht? — Er war seit einem halben Jahr staubverstopft. — Warum hat niemand gereinigt? — Niemand hat das im Kalender. — Warum? — Wir haben keinen Wartungsplan für Hardware. Und plötzlich weißt du, was wirklich zu reparieren ist — nicht der Controller, sondern der fehlende Plan.
Action items — wer, was, bis wann. Maximal 5 Punkte. Jeder mit Namen und Datum. Ohne das ist ein Postmortem Gruppentherapie, keine Veränderung.
Was ein Postmortem von einer Hexenjagd unterscheidet
Ein Satz, den man am Anfang der Sitzung laut sagen sollte: „Wir nehmen an, dass jeder mit dem Wissen, das er damals hatte, sein Bestes gegeben hat." Klingt wie eine Predigt, aber ohne diesen Satz wird niemand zugeben, dass er vor einem Jahr die NAS-Warnungen stumm geschaltet hat, weil sie zu viel Lärm gemacht haben. Und das ist genau die Information, wegen der es das Postmortem gibt.
Der Schuldige repariert den Prozess nicht. Der Schuldige geht oder fängt an zu lügen. Beides hilft dir nicht. Ein Postmortem sucht eine Lücke im System, nicht eine Lücke im Menschen. Menschen machen Fehler meist an denselben Stellen — wenn in deinem Prozess ein teurer Fehler ohne Sicherheitsnetz durchgehen kann, ist das ein Prozessproblem.
Wann durchziehen, wann sparen
Nicht jeder Ausfall verdient eine Stunde Sitzung. Eine einfache Regel: Postmortem, wenn der Ausfall länger als eine Stunde gedauert hat, mehr als eine Person betroffen war oder er Geld gekostet hat (verlorene Stunden, verschobener Termin, Anruf vom Kunden). Alles darunter — eine Zeile in einem einfachen Log (Datum, was, wie lange, wer hat es behoben) reicht.
Ein Log der letzten 12 Monate ist für sich schon überraschend lehrreich. Wenn du plötzlich siehst, dass es in einem Jahr sieben kleine Ausfälle rund um denselben Netzwerk-Switch gab, muss dir kein Dienstleister mehr sagen, dass es Zeit ist, ihn zu tauschen.
Wie geht es weiter
Ein Postmortem kostet kein Geld. Es kostet eine Stunde Disziplin einmal pro Quartal oder nach einem längeren Ausfall. Es rentiert sich mit einer einzigen vermiedenen Wiederholung — in der Praxis meist mit deutlich mehr.
Wenn sich in deinem Unternehmen nach dem letzten Ausfall niemand an den Tisch gesetzt und „warum war das überhaupt möglich?" gefragt hat — dann ist genau das die Stelle, an der du anfangen kannst. Wir helfen dir, einen konkreten Vorfall in seine Bestandteile zu zerlegen und eine Vorlage zu bauen, die bei dir bleibt.
Ein Ausfall ist kein Versagen. Ein wiederholter Ausfall — das schon.