# 3.7 Ownership, hierarchische Eskalation und Major Incidents (Teil 1/2) > **Kurz erklärt** > > Jeder Incident muss jederzeit einen eindeutig verantwortlichen Bearbeiter oder eine verantwortliche Gruppe besitzen. > > ITIL bezeichnet dies als **Ownership**. > > Ownership bedeutet nicht zwingend, dass diese Person den Fehler selbst behebt. Sie trägt jedoch die Verantwortung dafür, dass der Incident aktiv verfolgt, koordiniert und bis zum Abschluss begleitet wird. --- **Was bedeutet Ownership?** Ownership beantwortet die Frage: > **Wer kümmert sich aktuell um diesen Incident?** Der Owner sorgt dafür, dass: - der Incident aktiv bearbeitet wird, - keine unnötigen Wartezeiten entstehen, - Eskalationen rechtzeitig erfolgen, - Benutzer informiert werden, - der nächste Schritt bekannt ist, - und der Vorgang sauber abgeschlossen wird. Ownership bleibt bestehen – auch wenn andere Teams beteiligt werden. --- **Ownership ist nicht gleich Bearbeitung** Ein häufiger Irrtum: > Wer gerade technisch arbeitet, ist automatisch für den gesamten Incident verantwortlich. Das stimmt nicht. Beispiel: Der Service Desk erstellt ein Ticket und eskaliert es an das Netzwerkteam. Während das Netzwerkteam analysiert, kann der Service Desk weiterhin Owner bleiben und: - Rückfragen koordinieren, - den Benutzer informieren, - Fortschritte überwachen, - Zielzeiten prüfen, - und notwendige Eskalationen auslösen. Der technische Bearbeiter führt also eine konkrete Aufgabe aus. Der Owner sorgt dafür, dass der Incident insgesamt gesteuert wird. --- **Zuständigkeit, Bearbeitung und Ownership unterscheiden** | Begriff | Bedeutung | |---|---| | **Ownership** | Verantwortung für den gesamten Incident bis zum Abschluss | | **Bearbeitung** | Durchführung aktueller technischer oder organisatorischer Maßnahmen | | **Zuständigkeit** | fachliche Verantwortung für einen bestimmten Service, Bereich oder eine Komponente | | **Kommunikationsverantwortung** | Verantwortung für Statusmeldungen an Benutzer und Stakeholder | | **Entscheidungsverantwortung** | Befugnis, Prioritäten, Ressourcen oder Vorgehen festzulegen | Mehrere Personen oder Teams können gleichzeitig an einem Incident arbeiten. Der Owner sollte jedoch eindeutig festgelegt sein. --- **Warum Ownership wichtig ist** Ohne klaren Owner entstehen häufig: - doppelte Arbeiten, - lange Wartezeiten, - vergessene Tickets, - fehlende Kommunikation, - unklare Verantwortlichkeiten, - Ticket-Pingpong, - verspätete Eskalationen, - und unklare Abschlüsse. Typische Aussage: > Ich dachte, das andere Team kümmert sich darum. Genau solche Situationen soll Ownership verhindern. --- **Aufgaben des Owners** Der Owner überwacht den gesamten Incident. Typische Aufgaben: - Ticket kontrollieren, - Bearbeitung verfolgen, - Priorität prüfen, - Eskalationen auslösen, - Benutzer informieren, - Rückmeldungen koordinieren, - beteiligte Teams abstimmen, - Zielzeiten überwachen, - Workaround oder Lösung nachverfolgen, - Abschluss prüfen. Der Owner muss nicht jede technische Aufgabe selbst durchführen. Er muss aber sicherstellen, dass der Incident nicht stehen bleibt. --- **Ownership während einer funktionalen Eskalation** Auch nach einer funktionalen Eskalation bleibt Ownership bestehen. Beispiel: Benutzer ↓ Service Desk (Owner) ↓ Netzwerkteam ↓ Hersteller Das Netzwerkteam untersucht den Fehler. Der Service Desk sorgt weiterhin dafür, dass: - Statusmeldungen erfolgen, - der Benutzer informiert wird, - Fristen eingehalten werden, - offene Rückfragen geklärt werden, - und der Vorgang bis zur Wiederherstellung verfolgt wird. Eine Eskalation bedeutet also nicht automatisch, dass die Gesamtverantwortung verschwindet. --- **Ownership übertragen** In manchen Organisationen kann Ownership wechseln. Beispiele: - Service Desk → Netzwerkteam - Netzwerkteam → Incident Manager - Incident Manager → Major Incident Manager - Service Desk → Produktteam - internes Team → externer Provider mit interner Koordination Dabei sollte immer dokumentiert werden: - Zeitpunkt, - bisheriger Owner, - neuer Owner, - Grund der Übergabe, - aktueller Status, - nächster Schritt, - und Kommunikationsverantwortung. Eine Übergabe ist nur dann sinnvoll, wenn die neue Verantwortung eindeutig akzeptiert wurde. --- **Ein Ticket darf niemals besitzerlos sein** Ein Incident ohne Owner ist eines der größten Risiken im Support. Jeder Incident sollte jederzeit erkennen lassen: - Wer ist verantwortlich? - Wer arbeitet aktuell? - Wer informiert den Benutzer? - Wer entscheidet über Eskalationen? - Wer verfolgt Zielzeiten? - Wer prüft die Wiederherstellung? - Wer schließt den Vorgang ab? > **Merke** > > Ein zugewiesenes Ticket ist nicht automatisch ein aktiv gesteuerter Incident. --- **Funktionale und hierarchische Eskalation unterscheiden** Diese beiden Begriffe werden häufig verwechselt. | Funktionale Eskalation | Hierarchische Eskalation | |---|---| | fehlendes Fachwissen oder fehlende Berechtigung | Management-Unterstützung oder Entscheidung erforderlich | | Spezialisten notwendig | Priorisierung, Ressourcen oder Risikoentscheidung notwendig | | technischer Fokus | organisatorischer oder geschäftlicher Fokus | | Beispiel: Netzwerkteam einbinden | Beispiel: Service Owner oder Management informieren | | Ziel: richtige Fähigkeit einbinden | Ziel: Hindernisse, Risiken oder Entscheidungen klären | --- **Funktionale Eskalation** Die funktionale Eskalation wurde bereits in **3.6 Erstdiagnose, Lösung und funktionale Eskalation** behandelt. Beispiele: - Service Desk → Netzwerkteam - Service Desk → Serverteam - Service Desk → Datenbankteam - Service Desk → Cloud-Team - internes Team → Hersteller oder Lieferant Ziel: Die richtigen Spezialisten bearbeiten den Incident. Eine funktionale Eskalation ist keine Schuldzuweisung. Sie bedeutet nur, dass zusätzliche Fähigkeiten, Werkzeuge oder Berechtigungen benötigt werden. --- **Hierarchische Eskalation** Bei einer hierarchischen Eskalation wird nicht primär weiteres Fachwissen benötigt. Benötigt werden beispielsweise: - Entscheidungen, - Ressourcen, - Priorisierung, - Budget, - Management-Unterstützung, - Freigaben, - Konfliktlösung, - oder Kommunikation auf höherer Ebene. Beispiele: - SLA wird voraussichtlich verletzt. - Mehrere Fachbereiche sind betroffen. - Management muss informiert werden. - Ein externer Kunde eskaliert. - Ein Lieferant reagiert nicht. - Zusätzliche Ressourcen werden benötigt. - Ein Risiko kann nicht auf operativer Ebene entschieden werden. - Erheblicher Imageschaden ist möglich. --- **Wann sollte eskaliert werden?** Nicht erst, wenn: - ein SLA bereits verletzt wurde, - der Benutzer mehrfach angerufen hat, - Management sich beschwert, - oder ein Incident längere Zeit unbeachtet blieb. Sondern bereits dann, wenn erkennbar wird: - ein Ziel wird wahrscheinlich verfehlt, - weitere Unterstützung wird benötigt, - Risiken steigen, - Ressourcen nicht ausreichen, - Entscheidungen fehlen, - die Kommunikation nicht mehr ausreicht, - oder der Incident eine besondere geschäftliche Bedeutung bekommt. > **Merke** > > Gute Eskalation ist rechtzeitig, begründet und handlungsorientiert. --- **Eskalation bedeutet keine Schuld** Eine Eskalation ist keine Kritik an einzelnen Mitarbeitern. Sie dient dazu: - Hindernisse zu beseitigen, - Entscheidungen schneller zu treffen, - zusätzliche Ressourcen bereitzustellen, - Risiken sichtbar zu machen, - Kommunikation zu verbessern, - und den Service schneller wiederherzustellen. Ungeeignet: > Wir eskalieren, weil das Team es nicht schafft. Besser: > Wir eskalieren, weil die Zielzeit gefährdet ist und zusätzliche Entscheidungskompetenz benötigt wird. --- **Kommunikationseskalation** Manchmal funktioniert die technische Bearbeitung, aber die Kommunikation reicht nicht aus. Beispiele: - Benutzer erhält keine Rückmeldung. - Management verlangt Statusberichte. - Mehrere Standorte müssen informiert werden. - Es gibt widersprüchliche Aussagen. - Ein Kunde benötigt eine abgestimmte externe Meldung. - Der Service Desk besitzt keine freigegebene Kommunikationslinie. Auch hierfür kann eine Eskalation notwendig sein. Die technische Lösung und die Kommunikation müssen beide gesteuert werden. --- **Major Incident** Ein **Major Incident** ist ein besonders schwerwiegender Incident. Er besitzt normalerweise: - hohe Auswirkungen, - hohe Dringlichkeit, - viele betroffene Benutzer, - kritische betroffene Services, - erhebliche geschäftliche Folgen, - erhöhten Kommunikationsbedarf, - oder besondere Risiken. ITIL schreibt keine universelle feste Definition vor. Jede Organisation muss eigene Kriterien festlegen. --- **Mögliche Kriterien für einen Major Incident** Beispiele: - gesamte Produktion steht, - mehrere Standorte sind betroffen, - ein geschäftskritischer Service ist ausgefallen, - zentrale Anmeldung funktioniert nicht, - kritische Cloud-Dienste sind nicht verfügbar, - ein Sicherheitsvorfall wird vermutet, - externer Kundenimpact ist erheblich, - keine geeignete Zwischenlösung ist verfügbar, - gesetzliche oder vertragliche Fristen sind gefährdet, - Management- oder Krisenkommunikation ist notwendig. Die Kriterien sollten dokumentiert und regelmäßig überprüft werden. --- **Major Incident ist nicht automatisch P1** Viele Organisationen setzen: > P1 = Major Incident Dies ist jedoch keine allgemeine ITIL-Vorgabe. Ein P1-Incident kann ein Major Incident sein. Er muss es aber nicht in jeder Organisation automatisch sein. | P1 | Major Incident | |---|---| | beschreibt häufig die höchste operative Priorität | beschreibt einen besonders schwerwiegenden Incident mit besonderer Koordination | | steuert Zielzeiten und Bearbeitungsreihenfolge | aktiviert zusätzliche Rollen, Kommunikation und Steuerung | | kann durch normale Supportstruktur bearbeitet werden | benötigt häufig besondere Koordination | | wird meist aus Auswirkung und Dringlichkeit bestimmt | kann zusätzliche Kriterien enthalten | > **Merke** > > Priorität und Major-Incident-Status sollten bewusst unterschieden oder eindeutig gemeinsam definiert werden. --- **Ziele eines Major-Incident-Verfahrens** Bei normalen Incidents liegt der Fokus häufig auf der technischen Wiederherstellung. Bei Major Incidents kommen zusätzliche Aufgaben hinzu: - Koordination mehrerer Teams, - schnelle Entscheidungsfindung, - klare Kommunikation, - Priorisierung von Ressourcen, - Management-Unterstützung, - Lieferantensteuerung, - Risikoüberwachung, - Dokumentation unter Zeitdruck, - und spätere Nachbereitung. Das Ziel bleibt die Wiederherstellung des Services. Der Weg dorthin benötigt jedoch mehr Steuerung. --- **Major Incident Manager** Viele Organisationen benennen für Major Incidents einen eigenen **Major Incident Manager**. Diese Person repariert normalerweise nichts selbst. Typische Aufgaben: - Teams koordinieren, - Status sammeln, - Entscheidungen vorbereiten, - Kommunikationsfreigaben abstimmen, - Prioritäten überwachen, - Eskalationen auslösen, - War Room steuern, - Statusintervalle einhalten, - und die Nachbereitung vorbereiten. Der Major Incident Manager sorgt dafür, dass Spezialisten arbeiten können, ohne die Gesamtkoordination nebenbei leisten zu müssen. --- **Typischer Ablauf eines Major Incidents** Incident erkannt ↓ erste Bewertung ↓ Major-Incident-Kriterien prüfen ↓ Major Incident bestätigen oder ablehnen ↓ Owner und Major Incident Manager festlegen ↓ Fachteams und Lieferanten einbinden ↓ Kommunikation starten ↓ Workaround oder Wiederherstellung umsetzen ↓ Service stabilisieren ↓ Abschluss und Nachbereitung Nicht jede Organisation verwendet exakt diesen Ablauf. Entscheidend ist eine klare Koordination. --- **Sofortmaßnahmen bei Major Incidents** Zu Beginn sollte schnell geklärt werden: - Was ist betroffen? - Welche Services sind betroffen? - Welche Standorte sind betroffen? - Welche Benutzer oder Kunden sind betroffen? - Welche geschäftlichen Auswirkungen bestehen? - Seit wann besteht die Störung? - Gibt es einen sicheren Workaround? - Welche Teams werden benötigt? - Gibt es Hinweise auf einen Sicherheitsvorfall? - Wer kommuniziert offiziell? - Wann erfolgt die nächste Statusmeldung? Erst danach beginnt die tiefere technische Analyse. --- **Rollen bei Major Incidents** Typische Rollen können sein: - Service Desk, - Incident Manager, - Major Incident Manager, - technische Spezialisten, - Service Owner, - Kommunikationsverantwortliche, - Management, - Informationssicherheit, - Lieferanten, - Fachbereich, - Problem Manager. Nicht jede Organisation benötigt alle Rollen. Wichtig ist, dass Zuständigkeiten und Entscheidungswege bekannt sind. --- **War Room** Bei kritischen Incidents wird häufig ein gemeinsamer Kommunikationskanal eingerichtet. Beispiele: - Telefonkonferenz, - Videokonferenz, - Microsoft Teams, - Slack, - spezieller Incident-Kanal, - Statusboard. Vorteile: - schnellere Abstimmung, - weniger Rückfragen, - keine parallelen Einzelgespräche, - gemeinsame Faktenlage, - bessere Koordination. Ein War Room benötigt klare Regeln. Sonst entsteht schnell Unübersichtlichkeit. --- **Regeln im War Room** Sinnvolle Regeln: - eine Person koordiniert, - Fakten werden von Vermutungen getrennt, - Maßnahmen werden vor Ausführung abgestimmt, - Ergebnisse werden dokumentiert, - Kommunikation nach außen erfolgt abgestimmt, - Nebenunterhaltungen werden begrenzt, - Entscheidungen werden festgehalten, - nächste Schritte werden eindeutig zugewiesen. Ungeeignet: > Alle diskutieren gleichzeitig technische Vermutungen ohne Dokumentation. Besser: > Hypothesen werden gesammelt, priorisiert, getestet und mit Ergebnis dokumentiert. --- **Kommunikation wird wichtiger** Je größer der Incident, desto wichtiger wird regelmäßige Kommunikation. Stakeholder möchten wissen: - Was ist passiert? - Welche Auswirkungen bestehen? - Was wird aktuell getan? - Gibt es einen Workaround? - Was sollen Benutzer tun oder nicht tun? - Wann gibt es neue Informationen? Auch wenn noch keine Lösung vorliegt, ist eine Statusmeldung sinnvoll. Beispiel: > Die Ursache ist noch nicht bestätigt. Netzwerk- und Identitätsdienste werden geprüft. Ein sicherer Workaround ist derzeit nicht verfügbar. Die nächste Statusmeldung erfolgt um 11:30 Uhr. --- **Statusintervalle** Für kritische Incidents sollten Statusintervalle festgelegt werden. Beispiel: - alle 30 Minuten bei Major Incident, - alle 60 Minuten bei hoher Priorität, - nach wesentlichen Änderungen bei normaler Priorität. Die konkreten Zeiten legt die Organisation selbst fest. Nicht geeignet: > Wir melden uns, wenn alles wieder funktioniert. Besser: > Die nächste Statusmeldung erfolgt spätestens um 10:30 Uhr, auch wenn bis dahin noch keine vollständige Lösung vorliegt. --- **Single Point of Communication** Bei großen Incidents sollte möglichst eine abgestimmte Kommunikationsquelle verwendet werden. Beispiele: - Incident Manager, - Kommunikationsverantwortlicher, - Statusseite, - Service Desk mit freigegebenem Text, - zentrale E-Mail oder Portalnachricht. Dadurch werden widersprüchliche Aussagen vermieden. Technische Detaildiskussionen gehören nicht ungefiltert in Benutzerkommunikation. --- **Stakeholder zielgruppengerecht informieren** | Zielgruppe | Benötigte Informationen | |---|---| | **Benutzer** | Auswirkungen, Workaround, nächste Statusmeldung | | **Service Desk** | freigegebene Formulierung, bekannte Symptome, Ticketverknüpfung | | **technische Teams** | Logs, Hypothesen, Messergebnisse, Maßnahmen | | **Management** | geschäftliche Auswirkungen, Risiken, erwartete Entscheidungen | | **Kunden** | Serviceverfügbarkeit, Einschränkungen, nächstes Update | | **Lieferanten** | technische Nachweise, Versionen, Priorität, gewünschte Unterstützung | | **Informationssicherheit** | Sicherheitsbezug, Beweise, Risiko, Schutzmaßnahmen | Nicht jeder Empfänger benötigt dieselbe Detailtiefe. --- **Ressourcen koordinieren** Bei Major Incidents arbeiten oft mehrere Teams gleichzeitig. Der Major Incident Manager oder Incident Coordinator achtet darauf, dass: - Aufgaben verteilt werden, - Doppelarbeit vermieden wird, - Ergebnisse zusammengeführt werden, - blockierende Entscheidungen eskaliert werden, - Lieferanten eingebunden werden, - und niemand ohne Abstimmung riskante Änderungen durchführt. --- **Dokumentation während eines Major Incidents** Auch unter Zeitdruck muss dokumentiert werden. Mindestens festhalten: - Zeitpunkt, - Beobachtung, - Maßnahme, - Ergebnis, - Entscheidung, - Verantwortlicher, - nächster Schritt, - Kommunikationszeitpunkt. Diese Informationen werden später benötigt für: - Review, - Problem Management, - Audits, - Lessons Learned, - und Continual Improvement. --- **Nach der Wiederherstellung** Mit der technischen Wiederherstellung endet die Arbeit häufig noch nicht. Es folgen möglicherweise: - Stabilitätsüberwachung, - Benutzerinformation, - Abschlusskommunikation, - Ursachenanalyse, - Problem Record, - Review, - Verbesserung der Dokumentation, - Monitoring-Anpassung, - Aktualisierung von Runbooks, - und Bewertung der Kommunikation. --- **Major Incident Review** Nach Abschluss sollte geprüft werden: - Was ist passiert? - Wann begann die Störung? - Wann wurde sie erkannt? - Wann wurde eskaliert? - Welche Maßnahmen waren wirksam? - Wo gab es Verzögerungen? - War die Kommunikation ausreichend? - Waren Rollen und Verantwortlichkeiten klar? - Hat der Workaround funktioniert? - Welche Verbesserungen sind notwendig? Ziel ist Lernen, nicht Schuldzuweisung. --- **Lessons Learned** Typische Ergebnisse können sein: - bessere Dokumentation, - neue Checklisten, - Monitoring erweitern, - Alarmgrenzen anpassen, - Runbooks verbessern, - Schulungen durchführen, - Automatisierungen ergänzen, - Serviceabhängigkeiten in der CMDB korrigieren, - Lieferanteneskalation verbessern, - Kommunikationsvorlagen überarbeiten. Lessons Learned haben nur dann Wert, wenn daraus konkrete Maßnahmen entstehen. --- **Problem Management einbeziehen** Ein Major Incident führt häufig zu einem Problem Record. Dadurch kann später untersucht werden: - eigentliche Ursache, - beitragende Faktoren, - bekannte Fehler, - Workaround, - dauerhafte Lösung, - notwendiger Change, - Verbesserungsmaßnahmen. Incident Management stellt den Service wieder her. Problem Management sorgt dafür, dass die Ursache verstanden und zukünftige Wiederholungen möglichst vermieden werden. --- **Typische Fehler** **Fehler 1: Kein eindeutiger Owner** Niemand verfolgt den Incident Ende zu Ende. **Fehler 2: Ownership geht bei Eskalation verloren** Das Ticket wird weitergegeben, aber niemand koordiniert mehr. **Fehler 3: Zu späte Eskalation** Erst nach SLA-Verletzung oder Managementbeschwerde wird reagiert. **Fehler 4: Funktionale und hierarchische Eskalation werden verwechselt** Es wird ein Spezialist benötigt, aber Management informiert – oder umgekehrt. **Fehler 5: Major Incident wird nicht aktiviert** Kriterien sind unklar oder niemand entscheidet. **Fehler 6: Jeder kommuniziert etwas anderes** Es fehlt ein Single Point of Communication. **Fehler 7: Technische Vermutungen werden als Fakten veröffentlicht** Vertrauen geht verloren, wenn Aussagen später korrigiert werden müssen. **Fehler 8: Keine Dokumentation während der Störung** Nachbereitung und Ursachenanalyse werden erschwert. **Fehler 9: War Room ohne Koordination** Viele Personen diskutieren, aber wenige Maßnahmen werden entschieden. **Fehler 10: Nach Wiederherstellung keine Nachbereitung** Die Organisation lernt nicht aus dem Incident. **Fehler 11: Lessons Learned bleiben unverbindlich** Verbesserungen werden beschlossen, aber nicht umgesetzt. **Fehler 12: Problem Management wird nicht gestartet** Die eigentliche Ursache bleibt unbekannt oder unbehandelt. --- **Praxisbeispiel** **08:15 Uhr** Mehrere Standorte melden Ausfälle der zentralen Anmeldung. **08:20 Uhr** Incident wird als Major Incident bewertet. **08:25 Uhr** Major Incident Manager übernimmt die Koordination. **08:30 Uhr** Erste Statusmeldung wird veröffentlicht. **08:40 Uhr** Identity-, Netzwerk- und Cloud-Team arbeiten gemeinsam im War Room. **09:05 Uhr** Ein sicherer Workaround ist verfügbar. **09:40 Uhr** Service ist technisch wiederhergestellt. **10:00 Uhr** Abschlussmeldung wird veröffentlicht. **10:30 Uhr** Review-Termin und Problem Record werden erstellt. --- **Checkliste Ownership** - [ ] Owner eindeutig festgelegt - [ ] Bearbeiter und Owner unterschieden - [ ] Kommunikationsverantwortung geklärt - [ ] Zielzeiten werden überwacht - [ ] nächste Schritte sind dokumentiert - [ ] Eskalationen werden verfolgt - [ ] Abschluss wird geprüft --- **Checkliste Eskalation** - [ ] Eskalationsart korrekt gewählt - [ ] funktionale Eskalation bei fehlendem Fachwissen - [ ] hierarchische Eskalation bei Entscheidungs- oder Ressourcenbedarf - [ ] relevante Informationen vollständig - [ ] richtige Ansprechpartner beteiligt - [ ] Grund der Eskalation dokumentiert - [ ] Benutzerkommunikation geregelt - [ ] Ownership bleibt klar --- **Checkliste Major Incident** - [ ] Major-Incident-Kriterien geprüft - [ ] Major Incident bestätigt oder abgelehnt - [ ] Owner festgelegt - [ ] Major Incident Manager benannt - [ ] War Room oder gemeinsamer Kanal eingerichtet - [ ] beteiligte Teams informiert - [ ] Lieferanten bei Bedarf eingebunden - [ ] Kommunikationsverantwortung festgelegt - [ ] erste Statusmeldung veröffentlicht - [ ] Statusintervalle festgelegt - [ ] Workaround geprüft - [ ] Maßnahmen dokumentiert - [ ] Wiederherstellung bestätigt - [ ] Abschlusskommunikation erfolgt - [ ] Review geplant - [ ] Problem Record erstellt, falls erforderlich --- **Bedeutung für Fachinformatiker für Systemintegration** Auch wenn Fachinformatiker nicht immer selbst Incident Manager sind, sind sie häufig maßgeblich an der technischen Analyse und Wiederherstellung beteiligt. Im Arbeitsalltag bedeutet das: - strukturiert arbeiten, - Ergebnisse sauber dokumentieren, - technische Vermutungen von Fakten trennen, - Änderungen nachvollziehbar durchführen, - rechtzeitig eskalieren, - andere Teams aktiv unterstützen, - und verständlich kommunizieren. Gerade bei größeren Störungen entscheidet oft nicht nur technisches Wissen, sondern auch Zusammenarbeit, Ownership und Koordination über die Dauer des Ausfalls. --- **Zusammenfassung** > Incident übernehmen > ↓ > Owner eindeutig festlegen > ↓ > Bearbeitung koordinieren > ↓ > falls notwendig funktional oder hierarchisch eskalieren > ↓ > Major Incident aktivieren, wenn Kriterien erfüllt sind > ↓ > Rollen, Kommunikation und Statusintervalle festlegen > ↓ > Teams und Lieferanten koordinieren > ↓ > Service wiederherstellen > ↓ > Ergebnis stabilisieren und kommunizieren > ↓ > Review durchführen > ↓ > Erkenntnisse in Problem Management, Knowledge Management und Continual Improvement übernehmen --- **Verwandte Seiten** - 3.5 Auswirkungen, Dringlichkeit und Priorität - 3.6 Erstdiagnose, Lösung und funktionale Eskalation - 3.8 Self-Service, Wissensnutzung und Automatisierung - Problem Management - Knowledge Management - Continual Improvement - Service Level Management - Supplier Management --- **Quellen und Versionsstand** **Offizielle Grundlagen** - PeopleCert – ITIL Practice Guide: Incident Management - PeopleCert – ITIL Practice Guide: Service Desk - PeopleCert – ITIL Practice Guide: Problem Management - PeopleCert – ITIL Practice Guide: Service Level Management - ITIL Foundation – Version 5 **Einordnung** Die dargestellten: - Rollen, - Eskalationswege, - Major-Incident-Kriterien, - Statusintervalle, - War-Room-Regeln, - Checklisten, - und Praxisbeispiele sind herstellerneutrale Praxisempfehlungen. ITIL schreibt keine universelle: - Major-Incident-Definition, - Eskalationsmatrix, - Supportstufenstruktur, - Statusintervallvorgabe, - War-Room-Struktur, - oder konkrete Rollenbesetzung für alle Organisationen vor. Die konkrete Ausgestaltung muss an: - Services, - Risiken, - Service Levels, - Organisation, - Lieferanten, - Kommunikationswege, - Sicherheitsanforderungen, - und Entscheidungsbefugnisse angepasst werden. **Behandelter Framework-Stand:** ITIL Version 5 **Zusätzlich berücksichtigt:** aktuelle ITIL-4-Practice-Guidance **Fachlicher Stand:** August 2026