Nach der Störung: Wo ist die Zeit geblieben?

Dieser Beitrag wurde mit dem KI-Assistenten Claude erstellt und von Peter Hoenig veröffentlicht.

Nach einer größeren Störung gibt es meistens eine Besprechung, und in dieser Besprechung wird meistens die falsche Frage gestellt. Sie lautet: Wer war schuld? Die richtige lautet: Wo ist die Zeit geblieben?

Der Unterschied ist nicht moralisch, sondern praktisch. Die erste Frage liefert einen Namen und sonst nichts. Die zweite liefert eine Zahl, über die man etwas entscheiden kann.

Die sieben Schritte

1. eingetreten – Wann hat es tatsächlich begonnen?
2. bemerkt – Wann hat es jemand oder etwas gemerkt?
3. gemeldet – Wann war es an der richtigen Stelle?
4. Arbeit begonnen – Wann hat jemand angefangen, daran zu arbeiten?
5. Ursache gefunden – Wann war klar, woran es lag?
6. behoben – Wann lief es wieder?
7. bestätigt – Wann war bestätigt, dass es wirklich läuft?

Der erste Punkt ist der, den fast alle überspringen – und der am meisten verrät. Ein Ticketsystem kennt ihn nicht: Es weiß, wann gemeldet wurde, nicht, wann es angefangen hat. Dazwischen liegt oft der größere Teil der Ausfallzeit.

Die Zahl, auf die es ankommt

Aus den Zeitpunkten rechnet das Werkzeug die Spannen, darunter die Ausfalldauer (im IT-Betrieb meist MTTR genannt, mean time to repair). Am aufschlussreichsten ist aber ein Verhältnis: der Anteil der Erkennungszeit an der Gesamtdauer.

Ein Beispiel – frei erfunden, aber typisch: Eine Datenbank beendet sich nachts um 04:50 nach einem automatischen Update. Bemerkt wird es um 07:05 durch die Frühschicht, gemeldet um 07:20, behoben um 09:30. Ausfalldauer: 4 Stunden 40 Minuten. Davon entfielen 2 Stunden 15 Minuten darauf, dass es überhaupt niemandem auffiel – fast die Hälfte.

Wer in dieser Lage über schnellere Behebung nachdenkt, optimiert die kleinere Hälfte. Der Hebel liegt bei der Erkennung, und er ist meistens auch der billigere: eine Überwachung der wichtigsten Dienste und eine Meldung, die beim Bereitschaftsdienst ankommt. Das Werkzeug weist darauf hin, sobald die Erkennungszeit über 40 Prozent liegt.

Warum schuldfrei keine Höflichkeit ist

Die Nachbetrachtung soll zu Verbesserungen führen. Sobald es um Personen geht, hört sie auf, das zu tun – und zwar dauerhaft. Wer einmal erlebt hat, dass sein Name in einem Protokoll stand, meldet beim nächsten Mal später, formuliert vorsichtiger und erwähnt die eigene Beobachtung lieber nicht. Dann fehlt genau das Wissen, das man braucht.

Deshalb arbeitet das Werkzeug mit Rollen und Systemen statt Namen („Service Desk“, „Bereitschaft“, „Überwachung“) und merkt Formulierungen an, die auf eine Person zeigen. Das ist keine Sprachpolizei – es ist die Voraussetzung dafür, dass die nächste Nachbetrachtung noch etwas liefert.

Die unterschätzte dritte Art von Lernpunkt

Lernpunkte gibt es in drei Arten: hat geholfen, so nicht wieder – und ist gut gegangen, war aber Zufall.

Die dritte wird fast überall vergessen und ist oft die wertvollste. „Es war kein Monatsabschluss.“ „Die Sicherung war zufällig von gestern.“ „Der Kollege, der das System kennt, war da.“ Solche Sätze beschreiben Beinahe-Schäden. Sie sagen mehr über das Risiko aus als der Schaden selbst, weil sie zeigen, was beim nächsten Mal nicht mehr stimmen wird.

Woher die Daten kommen und wohin sie gehen

Aus dem ITSM-Werkzeug lässt sich eine Störung samt Verlauf übernehmen; „eingetreten“ und „bemerkt“ ergänzen Sie in der Besprechung, denn die kennt ein Ticketsystem nicht.

Geht es weiter in die Tiefe, übergibt das Werkzeug den Vorfall an das Fünf-mal-Warum. Und die fertige Nachbetrachtung mit ihren Maßnahmen wird ein Eintrag in der Lösungsdatenbank – damit beim nächsten ähnlichen Fall jemand findet, was hier gelernt wurde.

Der Vorfall-Zeitstrahl ist kostenlos und steht als freie Software unter der GPL zur Verfügung: Vorfall-Zeitstrahl öffnen. Wenn Sie nach Störungen zu einer Besprechungskultur kommen möchten, in der man offen redet, unterstütze ich Sie gern – melden Sie sich zum kostenfreien Erstgespräch.