IncidentLiveLinie 4 steht. Das Telefon klingelt.
Jede Störung bringt eine zweite mit:
die ständige Nachfragerei.
Der Support braucht eine Aussage für die Kunden, die Werksleitung eine Uhrzeit, und das Produktteam will wissen, was alles betroffen ist. Jede dieser Fragen ist berechtigt. Und jede kostet Zeit, die eigentlich in die Lösung gehört.
Was sag ich dem Kunden, der gerade angerufen hat?
SupportBetrifft das nur Linie 4 oder auch die anderen Hallen?
Product OwnerGibt’s schon eine Ahnung, wann es wieder läuft?
Werksleitung
Mit IncidentLive schauen sie einfach selbst nach, im Browser oder direkt in Microsoft Teams. Die Antwort kommt aus dem, was das Team tatsächlich dokumentiert hat.
Störung in IncidentLive angelegt
Vom ersten Alarm bis zum fertigen Bericht
Tickets, Alarme, Notizen, Dateien und Meldungen von Agents landen in einer gemeinsamen Zeitleiste, in der Reihenfolge, in der sie passiert sind, und lassen sich nachträglich nicht verändern. Ganz oben steht in wenigen Sätzen, was los ist und was noch offen ist. Alles Weitere baut auf dieser Zeitleiste auf.
Claude Code meldet eine Hypothese, als nicht bestätigt markiert
Deine Coding-Agents schreiben das Protokoll gleich mit
Eine Entwicklerin verbindet ihre Agent-Sitzung mit der Störung. Ab dann melden Claude Code, GitHub Copilot, Codex oder Cursor Fortschritte und Erkenntnisse direkt in die Zeitleiste. Nebenher Statusmeldungen tippen muss niemand mehr.
- Jede Erkenntnis ist als Beobachtung, Hypothese oder bestätigt gekennzeichnet
- Beendet ein Agent seine Sitzung, bleibt die Störung trotzdem offen
Drei Fragen beantwortet. Niemand hat das Team unterbrochen.
Antworten, die jeder nachprüfen kann
Jede Aussage verweist auf die Einträge in der Zeitleiste, aus denen sie stammt. Blind vertrauen muss also niemand. Und was nicht in der Zeitleiste steht, wird auch nicht behauptet.
- Keine erfundenen Zeitangaben, und nichts heißt bestätigt, was es nicht ist
- Jede Person bekommt nur Antworten aus Einträgen, die sie sehen darf
Ursache von Rita bestätigt. Der 8D-Entwurf beginnt.
Der 8D-Bericht schreibt sich fast von selbst. Den letzten Schliff gibt dein Team.
Nach der Störung füllt IncidentLive D1 bis D8 des 8D-Berichts, des Problemlösungsberichts in acht Schritten aus dem Qualitätsmanagement, aus der Zeitleiste vor, mit Quellen. Dein Team prüft, kommentiert, gibt den Entwurf zurück oder frei.
- Die Freigabe ist immer ein eigener, bewusster Schritt
- Der freigegebene Bericht ist ein PDF, aus dem hervorgeht, wer ihn freigegeben hat
Folgeaufgaben aus der Zeitleiste vorgeschlagen
Was einmal geholfen hat, ist beim nächsten Mal gleich zur Hand
Zu jeder Störung zeigt IncidentLive ähnliche frühere Fälle, samt Ursache und dem, was damals geholfen hat. Nach der Störung schlägt es Folgeaufgaben aus der Zeitleiste vor. Was davon umgesetzt wird, entscheidet dein Team und macht daraus Jira- oder GitHub-Issues.
- Frühere Fälle zeigen, warum sie ähnlich sind und welche Ursache bestätigt wurde
- Ein Issue entsteht erst, wenn jemand aus deinem Team den Vorschlag bestätigt
Willst du das mit deinen eigenen Störungen sehen?
Pilotprojekt anfragen8D-Bericht von Alice freigegeben. Störung abgeschlossen.
Linie 4 läuft wieder. Der Bericht ist freigegeben.
Dieselbe Störung, einen Tag später: Die Ursache ist von einem Menschen bestätigt, der 8D-Bericht freigegeben, die Folgeaufgaben stehen in Jira. Jeder Schritt dahin verweist auf die Zeitleiste, und niemand musste dem Team hinterhertelefonieren.
Verpackungslinie 4 steht
- Offen
- In Analyse
- Eingedämmt
- Gelöst
Linie 4 läuft wieder 10:05. Rita hat die Ursache bestätigt: Das Treiberupdate vom Montag hat das Zeitlimit für Druckaufträge verkürzt 10:20.