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,
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 arbeitet, ist automatisch 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 beantworten,
den Benutzer informieren,
Fortschritte überwachen,
notwendige Eskalationen auslösen.

Zuständigkeit und Ownership unterscheiden

Begriff	Bedeutung
Ownership	Verantwortlich für den gesamten Incident
Bearbeitung	Führt aktuell technische Arbeiten aus
Zuständigkeit	Fachliche Verantwortung für einen Bereich

Mehrere Personen können gleichzeitig bearbeiten.

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

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
Abschluss prüfen

Er muss nicht jede technische Aufgabe selbst durchführen.

Ownership während einer 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.

Ownership übertragen

In manchen Organisationen wechselt Ownership.

Beispiele:

Service Desk → Netzwerkteam
Netzwerkteam → Incident Manager
Incident Manager → Major Incident Manager

Dabei sollte immer dokumentiert werden:

Zeitpunkt
neuer Owner
Grund der Übergabe

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?

Funktionale und hierarchische Eskalation

Diese beiden Begriffe werden häufig verwechselt.

Funktionale Eskalation	Hierarchische Eskalation
fehlendes Fachwissen	Management-Unterstützung erforderlich
Spezialisten notwendig	Entscheidungen notwendig
technischer Fokus	organisatorischer Fokus

Funktionale Eskalation

Bereits in Kapitel 3.6 behandelt.

Beispiele:

Netzwerkteam
Serverteam
Datenbankteam
Cloud-Team
Hersteller

Ziel:

Die richtigen Spezialisten bearbeiten den Incident.

Hierarchische Eskalation

Hier wird nicht weiteres Fachwissen benötigt.

Benötigt werden beispielsweise:

Entscheidungen
Ressourcen
Priorisierung
Budget
Management-Unterstützung

Beispiele einer hierarchischen Eskalation

SLA wird voraussichtlich verletzt
mehrere Fachbereiche betroffen
Management muss informiert werden
externer Kunde eskaliert
Lieferant reagiert nicht
erheblicher Imageschaden möglich

Wann sollte eskaliert werden?

Nicht erst wenn:

SLA verletzt wurde
Benutzer mehrfach anruft
Management sich beschwert

Sondern bereits dann, wenn erkennbar wird:

Ziel wird wahrscheinlich verfehlt
weitere Unterstützung wird benötigt
Risiken steigen

Eskalation bedeutet keine Schuld

Eine Eskalation ist keine Kritik an Mitarbeitern.

Sie dient dazu,

Hindernisse zu beseitigen,
Entscheidungen schneller zu treffen,
Ressourcen bereitzustellen.

Kommunikationseskalation

Manchmal funktioniert die technische Bearbeitung gut.

Problematisch wird jedoch die Kommunikation.

Beispiele:

Benutzer erhält keine Rückmeldung
Management verlangt Statusberichte
mehrere Standorte müssen informiert werden

Auch hierfür kann eine Eskalation notwendig sein.

Major Incident

Ein Major Incident ist ein besonders schwerwiegender Incident.

Er besitzt normalerweise:

hohe Auswirkungen
hohe Dringlichkeit
viele betroffene Benutzer
große geschäftliche Folgen

ITIL schreibt keine feste Definition vor.

Jede Organisation legt ihre Kriterien selbst fest.

Mögliche Kriterien

Beispiele:

gesamte Produktion steht
mehrere Standorte betroffen
kritische Cloud-Dienste ausgefallen
Sicherheitsvorfall
erheblicher Kundenimpact
keine Zwischenlösung verfügbar

Major Incident ≠ P1

Viele Organisationen setzen:

P1 = Major Incident

Dies ist jedoch keine ITIL-Vorgabe.

Ein P1 kann ein Major Incident sein.

Muss er aber nicht.

Ziele eines Major Incidents

Bei normalen Incidents liegt der Fokus häufig auf der technischen Lösung.

Bei Major Incidents kommen weitere Aufgaben hinzu:

Koordination
Kommunikation
Priorisierung
Ressourcensteuerung
Management-Unterstützung

Major Incident Manager

Viele Organisationen benennen hierfür einen eigenen Major Incident Manager.

Er repariert normalerweise nichts selbst.

Seine Aufgaben:

Teams koordinieren
Status sammeln
Entscheidungen vorbereiten
Kommunikation abstimmen
Prioritäten überwachen

Typischer Ablauf

Incident erkannt
        │
        ▼
Bewertung
        │
        ▼
Major Incident?
        │
   ┌────┴────┐
   │         │
 Nein       Ja
   │         │
Normaler   Major Incident
Ablauf      aktivieren

Sofortmaßnahmen

Bei einem Major Incident sollte zunächst geklärt werden:

Was ist betroffen?
Welche Services?
Welche Standorte?
Welche Benutzer?
Welche Auswirkungen?
Gibt es einen Workaround?

Erst danach beginnt die tiefere Analyse.

Rollen bei Major Incidents

Typische Rollen:

Service Desk
Incident Manager
Major Incident Manager
technische Spezialisten
Service Owner
Kommunikationsverantwortliche
Management
Hersteller

Nicht jede Organisation benötigt alle Rollen.

Kommunikation wird wichtiger

Je größer der Incident,

desto wichtiger wird eine regelmäßige Kommunikation.

Stakeholder möchten wissen:

Was ist passiert?
Welche Auswirkungen bestehen?
Was wird aktuell getan?
Wann gibt es neue Informationen?

Auch wenn noch keine Lösung vorliegt.

Statusintervalle

Beispiel:

P1 / Major Incident

alle 30 Minuten Status

Nicht:

"Wir melden uns wenn alles wieder funktioniert."

Regelmäßige Informationen schaffen Vertrauen.

Merksätze

Jeder Incident besitzt genau einen Owner.

Ownership endet nicht mit einer Eskalation.

Funktionale Eskalation bringt Fachwissen.

Hierarchische Eskalation bringt Entscheidungen.

Major Incidents benötigen vor allem Koordination und Kommunikation.