Skip to main content

**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

BegriffBedeutung
OwnershipVerantwortlich für den gesamten Incident
BearbeitungFührt aktuell technische Arbeiten aus
ZuständigkeitFachliche 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 EskalationHierarchische Eskalation
fehlendes FachwissenManagement-Unterstützung erforderlich
Spezialisten notwendigEntscheidungen notwendig
technischer Fokusorganisatorischer 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.

Back to top