Major Incident

Ein Major Incident ist die schwerste Form eines Incidents. Der Mailserver eines ganzen Unternehmens fällt aus, der Onlineshop nimmt keine Bestellungen mehr an, ein Kunde kann nicht produzieren. In solchen Fällen reicht der normale Ablauf nicht: Es braucht ein eigenes Verfahren, damit alle in dieselbe Richtung arbeiten.

Woran man einen Major Incident erkennt

Die Kriterien legt jedes Unternehmen vorab fest. Typisch sind:

• sehr viele Nutzer*innen oder Kund*innen gleichzeitig betroffen
• ein geschäftskritischer Service fällt ganz oder größtenteils aus
• erheblicher finanzieller Schaden oder Reputationsrisiko
• Gefahr für Sicherheit oder Datenschutz

Wichtig: Die Entscheidung „Das ist ein Major Incident“ muss schnell fallen dürfen. Lieber einmal zu früh ausrufen und zurückstufen als eine Stunde zu spät.

Typischer Ablauf

1. Ausrufen: Eine festgelegte Rolle erklärt den Major Incident.
2. Koordination übernehmen: Eine Person (oft Major Incident Manager genannt) steuert, verteilt Aufgaben und hält den Überblick. Sie repariert nicht selbst.
3. Team zusammenrufen: die nötigen Fachleute, unabhängig von der üblichen Support-Level-Kette.
4. Kommunizieren: Betroffene in festen Abständen informieren, auch wenn es nichts Neues gibt.
5. Wiederherstellen: oft zunächst mit einem Workaround.
6. Nachbetrachten: Ursachenanalyse und Maßnahmen, damit es nicht wieder passiert.

Kommunikation: der unterschätzte Teil

Während eines Major Incidents gehen beim Support viele gleichlautende Anfragen ein. Bewährt hat sich:

• ein Haupt-Ticket für die Störung, mit dem die einzelnen Meldungen verknüpft werden
• ein vorbereiteter Textbaustein mit dem aktuellen Stand
• feste Aktualisierungszeiten („nächste Information um 11:00 Uhr“)
• eine Statusmeldung an zentraler Stelle, etwa im Kundenportal oder auf der Website

Beispiel

Um 8:40 Uhr melden in zehn Minuten 25 Mitarbeitende der Beispiel Werke GmbH, dass sie keine Dateien öffnen können. Der Servicedesk ruft einen Major Incident aus. Die Koordinatorin holt Netzwerk und Speicher-Team zusammen, der First Level beantwortet alle Meldungen mit demselben Textbaustein und verweist auf das nächste Update um 9:15 Uhr. Um 9:30 Uhr läuft der Dateiserver wieder; ein defekter Speicher-Controller wird am Nachmittag getauscht. Zwei Tage später folgt die Nachbetrachtung – und ein Eintrag im Problem Management.

Die Nachbetrachtung

Nach dem Major Incident wird festgehalten: Was ist passiert, wie wurde es bemerkt, was hat gut funktioniert, was nicht, und welche Maßnahmen folgen? Ziel ist Lernen, nicht Schuldsuche. Methoden dafür beschreibt der Eintrag Root-Cause-Analyse. Wie man eskaliert, steht im Ratgeber Eskalationsmanagement.

Vorbereitung

Ein Major Incident ist der falsche Moment, um Zuständigkeiten zu klären. Vorab festgelegt sein sollten: Kriterien, Rollen mit Vertretung, Kontaktwege außerhalb der betroffenen Systeme und vorbereitete Textbausteine.

Nach dem Ende des Major Incidents sollten alle Betroffenen eine abschließende Nachricht erhalten: Was ist passiert, ist alles wieder in Ordnung, und was wird getan, damit es nicht erneut geschieht? Diese letzte Nachricht wird oft vergessen, prägt aber den Eindruck stark.

So hilft rapidFOX

In rapidFOX holst du über den internen Chat mit Audio- und Videoanruf samt Bildschirmfreigabe schnell die nötigen Leute zusammen. Mehrere Tickets lassen sich auf einmal zuweisen, und Textbausteine stehen im Antwortfeld per Kürzel bereit. Ein eigenes Major-Incident-Verfahren mit Statusseite bietet rapidFOX nicht. Mehr unter Team-Chat.