Störungsbehebung im IT-Betrieb

Was ist Incident Management?

Incident Management ist die ITIL-Praktik, die Störungen aufnimmt, priorisiert und den vereinbarten Servicebetrieb so schnell wie möglich wiederherstellt. Ein Incident ist dabei jede ungeplante Unterbrechung eines Service oder eine Minderung seiner Qualität.

Wenn eine Anwendung steht, entscheidet nicht die Ursachenanalyse über den Schaden, sondern wie schnell jemand die Arbeitsfähigkeit wiederherstellt, und dafür gibt es diese Praktik.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Ziel
Betrieb wiederherstellen, nicht Ursache klären
Gehört zu
ITIL 4, Service-Management-Praktiken
Steuergröße
Priorität aus Auswirkung und Dringlichkeit
Nicht dasselbe
Problem Management

Vom Ticket zur Wiederherstellung

Der Ablauf ist immer derselbe: erfassen, kategorisieren, priorisieren, lösen oder mit einem Workaround überbrücken, abschließen. Den Abschluss nehmen die meisten Teams am wenigsten ernst, denn er verlangt eine Bestätigung der meldenden Person und eine Dokumentation dessen, was tatsächlich geholfen hat.

Wiederherstellung heißt nicht Ursachenbeseitigung. Wenn ein Neustart den Service zurückbringt, ist der Incident erledigt, auch wenn niemand weiß, warum der Dienst stehen geblieben ist. Genau an dieser Stelle setzt später das Problem Management an.

Priorität, Eskalation und Major Incidents

Die Priorität ergibt sich aus Auswirkung und Dringlichkeit, üblicherweise über eine vorab abgestimmte Matrix. Reicht das Wissen im ersten Level nicht, greift die funktionale Eskalation an spezialisierte Teams, bei Entscheidungsbedarf die hierarchische Eskalation an die Leitung. Manche Organisationen ersetzen die starre Stufenfolge durch Swarming, also durch gemeinsames Arbeiten mehrerer Fachleute am selben Fall.

Für Major Incidents lohnt ein eigenes, vorher geübtes Verfahren mit benannter Leitung, festen Kommunikationswegen und einem Zeittakt für Statusmeldungen. Wer das erst im Ernstfall erfindet, verliert die erste Stunde mit Abstimmung.

Wo die Praktik andockt

Der Service Desk ist der Einstiegspunkt und hält den Kontakt zu den Betroffenen. Dokumentierte Workarounds aus dem Problem Management verkürzen die Bearbeitung, dauerhafte Behebungen laufen über Change Enablement, und Service Level Agreements geben die Zielzeiten vor, an denen gemessen wird.

Der häufigste Messfehler

Wenn geschlossene Tickets die zentrale Kennzahl sind, optimiert das Team auf Schließen statt auf Wirkung. Typische Folgen: Vorgänge werden früh geschlossen und kurz darauf neu eröffnet, Serviceanfragen laufen als Incidents mit und blähen die Zahlen auf, und Häufungen bleiben unentdeckt, weil niemand wiederkehrende Störungen zu einem Problem Record zusammenführt.

Aussagekräftiger sind wenige Kennzahlen mit Bezug zur Auswirkung: Zeit bis zur Wiederherstellung bei hoher Priorität, Anteil der Wiedereröffnungen und der Anteil der Incidents, für die bereits ein dokumentierter Workaround vorlag.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Nicht verwechseln

Incident Management und was oft damit gleichgesetzt wird

Incident Management gegen Problem Management

Incident Management stellt den Betrieb wieder her, Problem Management sucht die Ursache. Beides läuft parallel: Der Incident wird geschlossen, sobald der Service läuft, der Problem Record bleibt offen.

Incident Management gegen Service Request Management

Eine Serviceanfrage ist ein normaler Wunsch nach etwas Vorgesehenem, etwa ein Zugang oder ein Gerät. Eine solche Anfrage ist keine Störung und gehört in einen eigenen Ablauf, sonst verfälscht sie jede Auswertung.

Incident Management gegen Event

Ein Event ist eine Zustandsänderung, die das Monitoring meldet. Erst wenn daraus eine Beeinträchtigung des Service wird oder droht, entsteht ein Incident.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
In der Praxis

Ein Workaround, der läuft, schlägt eine Analyse, die noch dauert

Die meiste Reibung entsteht bei der Priorisierung. Die Priorität ergibt sich aus Auswirkung und Dringlichkeit, nicht aus der Lautstärke der meldenden Person. Ohne verabredete Matrix vergibt der Erstkontakt die Stufe nach Gefühl, und die zugesagten Zeiten laufen ins Leere, weil plötzlich alles hoch priorisiert ist.

Der zweite Punkt ist die Trennung von Störung und Anfrage. Ein neuer Zugang ist keine Störung, sondern ein Service Request, auch wenn beides über dasselbe Ticketsystem hereinkommt. Werden sie vermischt, wird die Auswertung unbrauchbar: Die durchschnittliche Lösungszeit sinkt, weil viele kleine Anfragen darin stecken, und die echten Ausfälle verschwinden im Mittelwert.

Genau dieser Mittelwert ist der häufigste Messfehler. Wer Störungen steuern will, schaut auf die Verteilung und auf die Einhaltung je Prioritätsstufe, nicht auf einen Durchschnitt über alle Tickets. Und ein Ticket ist gelöst, wenn die Nutzung wieder möglich ist, nicht wenn ein Techniker verstanden hat, woran es lag. Alles Weitere gehört ins Problem Management.

Incident Management lernen

Wie Praktiken, Service Value Chain und Zertifizierungsstufen zusammenhängen, zeigen die ITIL- und PRINCE2-Kurse im Überblick .

Wer die Störungsbearbeitung im eigenen Team umbauen will, findet den passenden Stoff in den Praktiken-Modulen der ITIL-4-Zertifizierung .

Wissen prüfen

Sitzt Incident Management schon?

Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.

Häufige Fragen

Ist ein langsames System schon eine Störung?
Ja, wenn die vereinbarte Servicequalität unterschritten wird. ITIL zählt nicht nur den Totalausfall, sondern auch die Minderung der Qualität zum Incident. Deshalb gehören messbare Schwellen in die Vereinbarung, sonst wird darüber im Einzelfall gestritten.
Wann entsteht neben einem Incident ein Problem Record?
Wenn die Ursache unklar bleibt, dieselbe Störung wiederkehrt oder ein Major Incident nachbereitet wird. Aus dem Incident selbst wird dabei kein Problem, der Problem Record entsteht zusätzlich. Der Incident wird geschlossen, sobald der Service wieder läuft; die Ursachenarbeit läuft daneben im Problem Management weiter.
Wer priorisiert, wenn alles dringend ist?
Die Priorität ergibt sich aus Auswirkung und Dringlichkeit, nicht aus der Lautstärke der meldenden Person. Eine vorab abgestimmte Matrix nimmt diese Diskussion aus dem Einzelfall heraus.

Passt thematisch dazu

Wann die schnelle Wiederherstellung nicht mehr reicht und stattdessen die Ursachensuche übernimmt, klärt die Abgrenzung von Incident und Problem .

Persönlich für dich da

Deine Ansprechpartner

Du willst das Thema nicht nur nachschlagen, sondern anwenden können? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Ordnet mit dir ein, welcher Kurs zu deinem Vorwissen passt.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant Inhouse-Trainings, die an euren eigenen Daten und Abläufen ansetzen.

Incident Management im Kurs statt im Lexikon

Nachschlagen bringt dich bis zum Verstehen. Anwenden lernst du an echten Aufgaben.