Bildquelle: Bildquelle: Pexels / Foto-ID 3183183 / https://www.pexels.com/photo/3183183/ / CC0-Lizenz
Ein schwerer Ausfall ist kein normales Ticket mit mehr Aufmerksamkeit. Sobald ein zentraler Dienst nicht verfügbar ist, Kundenzusagen kippen oder mehrere Fachbereiche betroffen sind, braucht der Betrieb eine andere Arbeitsform. Der Major Incident Prozess entscheidet dann, wer führt, wer kommuniziert, wer technische Entscheidungen trifft und wie das Lagebild aktuell bleibt.
Major Incident bedeutet in diesem Beitrag: eine IT-Störung mit hoher geschäftlicher Wirkung, die schneller, sichtbarer und koordinierter bearbeitet werden muss als ein Standard-Incident. Es geht nicht um ein besonders lautes Ticket, sondern um einen geregelten Betriebsmodus. Für ITSM-Generalisten ist wichtig, dass der Prozess die erste halbe Stunde ordnet, bevor sich parallele Chats, Einzelrückfragen und Management-Updates verselbständigen.
Ein Major Incident Prozess ist ein vereinbarter Ablauf für besonders kritische Störungen. Er legt fest, wann eine Störung hochgestuft wird, wer die Lage führt, wie technische Arbeit und Kommunikation getrennt werden und wie Entscheidungen dokumentiert werden. Der Zweck ist nicht Bürokratie, sondern Tempo durch klare Zuständigkeit.
Der Startpunkt darf nicht vom lautesten Ruf abhängen
In der Praxis beginnt ein kritischer Ausfall oft unsauber. Das Monitoring meldet Fehler, der Service Desk bekommt Anrufe, ein Fachbereich schreibt direkt an die IT-Leitung und ein Provider prüft bereits eigene Systeme. Wenn niemand den Major Incident formell startet, arbeitet jeder aus seiner Perspektive. Genau dadurch entstehen widersprüchliche Prioritäten.
Ein guter Startpunkt ist deshalb eine einfache Aktivierungsregel. Sie muss so klar sein, dass der Service Desk oder der Bereitschaftsdienst sie ohne lange Diskussion anwenden kann. Typische Auslöser sind ein kompletter Ausfall eines geschäftskritischen Service, eine betroffene Kundengruppe mit hoher Wirkung, Sicherheitsverdacht mit Betriebsfolge oder ein Providerproblem ohne belastbare Rückmeldefrist. Der Start muss nicht perfekt sein. Er muss schnell genug sein, damit Führung entsteht.
Eine Rolle führt die Lage, nicht jede technische Spur
Der wichtigste Fehler im Major Incident ist die Vermischung von Leitung und Fehlersuche. Die technisch stärkste Person ist nicht automatisch die beste Lageführung. Der Incident Lead hält den Ablauf zusammen: Status, Priorität, nächste Entscheidung, Kommunikationsrhythmus und Eskalationsbedarf. Diese Rolle fragt nicht jedes Detail ab, sondern sorgt dafür, dass relevante Details in eine gemeinsame Lage übersetzt werden.
Die technische Analyse braucht weiterhin Fachpersonen. Datenbank, Netzwerk, Identitätsdienst, Anwendung und Provider können parallel prüfen. Aber der Major Incident Prozess muss festlegen, wie Ergebnisse zusammenlaufen. Ohne diesen Sammelpunkt entstehen mehrere Wahrheiten. Ein Team meldet Entwarnung für seine Komponente, während der Service Desk weiter Kundenauswirkungen sieht. Der Incident Lead verhindert, dass solche Teilstände als Gesamtstatus missverstanden werden.
Die erste Lagekarte braucht wenige Pflichtfelder
Ein Major Incident Prozess wird langsam, wenn er zu viele Felder verlangt. In den ersten Minuten zählen wenige Angaben: betroffener Service, sichtbare Auswirkung, betroffene Nutzergruppe, Startzeit, vermutete Ursache, aktuelle Gegenmaßnahme, nächster Prüfpunkt, Kommunikationsstatus und verantwortliche Rollen. Diese Lagekarte kann im Ticket, in einem vorbereiteten Formular oder in einem Krisenkanal gepflegt werden. Entscheidend ist, dass sie als führende Arbeitsfläche anerkannt ist.
Der Service Desk profitiert besonders von dieser Klarheit. Ein gut geführtes Lagebild hilft, Kunden nicht mit technischen Einzelständen zu überfrachten. Gleichzeitig verhindert es zu frühe Entwarnung. Wenn noch Jobs nachlaufen, Daten geprüft werden oder ein Provider nur eine Teilverbesserung meldet, bleibt der Status sichtbar eingeschränkt. Das passt zu den jüngsten ITSM.news-Artikeln über Statusseite und Ticket im Ausfall sowie über Provider-Aufgaben mit Rückmeldefrist.
Kommunikation beginnt vor der Ursachenanalyse
Ein häufiger Irrtum lautet: Erst die Ursache finden, dann kommunizieren. Bei einem Major Incident ist das zu spät. Betroffene Nutzer brauchen früh eine belastbare Aussage, auch wenn die Ursache noch offen ist. Diese Aussage muss keine technische Lösung versprechen. Sie muss sagen, welcher Dienst betroffen ist, welche Wirkung sichtbar ist, dass die Bearbeitung läuft, wann die nächste Aktualisierung kommt und über welchen Kanal Updates erscheinen.
Atlassian beschreibt Incident-Kommunikation als laufenden Bestandteil des Incident Managements, nicht als letzten Pressetext. PagerDuty ordnet Incident-Management-Arbeit ebenfalls über Rollen, Abläufe und Reaktionsfähigkeit ein. Für ITSM-Teams folgt daraus eine praktische Regel: Die Kommunikationsrolle muss nicht selbst reparieren. Sie muss aus der Lagekarte eine verständliche, freigegebene Aussage machen und Rückfragen an die Lageführung zurückspielen.
Entscheidungen gehören ins Log, nicht nur in den Chat
Während eines kritischen Ausfalls entstehen Entscheidungen im Minutentakt. Wird ein Rollback gestartet? Wird ein Feature abgeschaltet? Wird ein Provider eskaliert? Wird eine Teilentwarnung veröffentlicht? Solche Entscheidungen verschwinden leicht in Chats oder Telefonaten. Später fehlt dann der Nachweis, warum ein Weg gewählt wurde und welche Annahme dahinterstand.
Der Major Incident Prozess braucht deshalb ein Entscheidungslog. Es muss nicht lang sein. Zeitpunkt, Entscheidung, Begründung, Entscheider, betroffene Services und erwarteter nächster Kontrollpunkt reichen oft aus. Dieses Log hilft beim Schichtwechsel, bei Management-Rückfragen und bei der Nachanalyse. Es passt auch zum Bestandsartikel über Änderungsnachweise im Ticket, weil schnelle technische Maßnahmen später erklärbar bleiben müssen.
So sieht ein brauchbarer Startablauf aus
- Aktivierungskriterium prüfen: geschäftskritischer Service, breite Nutzerwirkung, Sicherheitsverdacht oder Providerblocker.
- Incident Lead benennen und sichtbar im Ticket oder Krisenkanal eintragen.
- Technische Arbeitsstränge trennen: Anwendung, Infrastruktur, Identität, Netzwerk, Daten, Provider.
- Kommunikationsrolle festlegen und Update-Rhythmus setzen, etwa alle 30 Minuten oder bei relevanter Lageänderung.
- Erste Lagekarte füllen: Service, Wirkung, Startzeit, Nutzergruppe, aktueller Stand, nächste Prüfung.
- Entscheidungslog starten und jede Freigabe, Teilentwarnung oder Eskalation kurz dokumentieren.
- Service Desk mit einer freigegebenen Antwort versorgen, statt ihn aus technischen Kommentaren ableiten zu lassen.
- Nach Abschluss eine kurze Nachanalyse planen: Ursache, Erkennung, Kommunikation, Entscheidungsqualität und Prävention.
Die Nacharbeit entscheidet über den nächsten Ausfall
Ein Major Incident Prozess endet nicht mit grünen Monitoringwerten. Der Betrieb muss prüfen, was beim nächsten Mal früher erkennbar, klarer führbar oder besser vorbereitet sein soll. Dazu gehören Alarmqualität, Eskalationswege, Providerkontakte, Runbooks, Kommunikationsvorlagen, Statusseiten-Komponenten und Servicekatalog-Daten.
Die Nacharbeit sollte nicht als Schuldfrage laufen. Sie soll die Betriebsfähigkeit verbessern. Eine gute Nachanalyse trennt technische Ursache, Prozesslücke und Kommunikationswirkung. Vielleicht war die Ursache ein Datenbankfehler, die Prozesslücke aber eine unklare Entwarnungsfreigabe. Vielleicht funktionierte die technische Reparatur schnell, aber die Kundenaussage blieb zu lange unklar. Genau diese Trennung macht den nächsten Major Incident besser steuerbar.
Ein führbarer Ausfall ist kein Zufall
Der beste Major Incident Prozess ist im Ernstfall einfach genug, um wirklich genutzt zu werden. Er braucht klare Auslöser, wenige Startfelder, eine sichtbare Lageführung, getrennte technische Arbeitsstränge, frühe Kommunikation und ein Entscheidungslog. Mehr Struktur ist nur dann hilfreich, wenn sie Tempo schafft.
Für ITSM-Verantwortliche ist die Kernfrage deshalb nicht, ob es irgendwo ein Dokument zum Major Incident gibt. Entscheidend ist, ob der Betrieb in den ersten Minuten weiß, wer die Lage führt, welche Aussage der Service Desk nutzen darf und wann die nächste Entscheidung fällt. Erst dann wird aus einem kritischen Ausfall ein führbarer Prozess.
Hilfreich ist eine kurze Trockenübung außerhalb des Ernstfalls. Dabei zeigt sich schnell, ob Kontaktlisten aktuell sind, ob Stellvertretungen bekannt sind, ob Kommunikationsvorlagen funktionieren und ob die erste Lagekarte für den Service Desk wirklich verständlich genug ist.
FAQ zum Major Incident Prozess
Wann sollte ein Major Incident gestartet werden?
Wenn ein geschäftskritischer Service deutlich eingeschränkt ist, viele Nutzer betroffen sind, eine Sicherheitslage Betriebsfolgen hat oder ein Providerproblem ohne klare Rückmeldefrist entsteht. Die Aktivierung sollte lieber früh überprüft als zu spät entschieden werden.
Wer sollte den Major Incident führen?
Eine klar benannte Rolle mit Überblick über Ablauf, Kommunikation und Entscheidungen. Das muss nicht die tiefste technische Fachperson sein. Technische Teams reparieren, die Lageführung koordiniert.
Was gehört in die erste Lagekarte?
Betroffener Service, sichtbare Auswirkung, Nutzergruppe, Startzeit, aktueller Stand, nächste Prüfung, Kommunikationsstatus, Incident Lead und offene Entscheidungen.
Quellen und Stand: Quellenprüfung am 29.07.2026. Einordnung zu Incident-Kommunikation nach Atlassian Incident Communication, zu Incident-Management-Rollen und Reaktionsfähigkeit nach PagerDuty Incident Management und zu ITIL Incident Management nach AXELOS ITIL Incident Management.
Bildquelle: Pexels / Foto-ID 3183183 / https://www.pexels.com/photo/3183183/ / CC0-Lizenz
