Ursachenanalyse im Servicebetrieb

Was ist Problem Management?

Problem Management ist die ITIL-Praktik, die den Ursachen von Störungen nachgeht und die Wahrscheinlichkeit künftiger Ausfälle senkt. Ein Problem ist dabei die tatsächliche oder mögliche Ursache eines oder mehrerer Incidents.

Wenn dieselbe Störung jeden Monat wiederkommt und jedes Mal neu bearbeitet wird, fehlt die Praktik, die hinter die Symptome schaut, statt sie schneller wegzuräumen.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Gegenstand
Die Ursache eines oder mehrerer Incidents
Drei Phasen
Identifikation, Problemkontrolle, Fehlerkontrolle
Zwischenstand
Known Error mit dokumentiertem Workaround
Nicht dasselbe
Incident Management

Die drei Phasen

In der Problem Identification entstehen die Kandidaten: aus Häufungen im Incident-Verlauf, aus der Nachbereitung von Major Incidents, aus Hinweisen von Lieferanten und aus Auffälligkeiten im Monitoring. In der Problem Control werden sie analysiert, nach Risiko priorisiert und, wo möglich, mit einem Workaround entschärft. Ist die Ursache verstanden, aber noch nicht beseitigt, wird daraus ein Known Error.

Die Error Control hält diese Known Errors im Blick: Dort wird regelmäßig geprüft, ob sich die Lage geändert hat, ob der Workaround noch trägt und ob eine dauerhafte Lösung inzwischen wirtschaftlich ist. Umgesetzt wird sie dann über das Change Enablement.

Known Error und Workaround

Ein Workaround stellt den Betrieb wieder her, ohne die Ursache zu beseitigen, etwa durch einen Neustart, eine geänderte Einstellung oder einen alternativen Arbeitsweg. Sein Wert hängt davon ab, ob der Service Desk ihn im entscheidenden Moment findet. Deshalb gehört er in die Wissensbasis, verknüpft mit den Symptomen, unter denen jemand danach suchen würde.

Der Known Error ist der dokumentierte Zwischenstand: bekannte Ursache, bekannter Umgang, offene Lösung. Er ist kein Eingeständnis von Versagen, sondern das, was ein Team davor bewahrt, dieselbe Analyse dreimal zu machen.

Nach Risiko priorisieren, nicht nach Lautstärke

Nicht jedes Problem muss gelöst werden. Wenn eine Störung selten auftritt, geringe Auswirkung hat und ein billiger Workaround existiert, kann der dokumentierte Known Error die wirtschaftlich richtige Antwort sein. Diese Entscheidung sollte bewusst fallen und festgehalten werden, sonst wird sie später als Versäumnis gelesen.

Die Priorisierung folgt dem Risiko: Wie oft tritt die Störung auf, wen trifft sie, was kostet ein Ausfall, wie aufwendig ist die Behebung? Häufigkeit allein ist ein schlechter Maßstab, weil sie kleine Ärgernisse über große Risiken stellt.

Warum diese Praktik als Erste ausfällt

Problemarbeit hat keinen Melder, der nachfragt, und keinen Zeitdruck von außen. Gegen die aktuelle Störung verliert sie deshalb jeden Konflikt. Wo sie funktioniert, gibt es drei Dinge: geschützte Analysezeit, eine benannte Verantwortung je Problem Record und einen festen Termin, an dem der Bestand gesichtet wird.

Ein weiterer Fallstrick ist die Vermischung mit dem Incident Management. Wenn dasselbe Team im selben Werkzeug beides bearbeitet, gewinnt immer das Ticket mit der laufenden Uhr. Getrennte Zuständigkeit für die Analyse ist wirksamer als jede Vorgabe, wie viele Problem Records offen sein dürfen.

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

Problem Management und was oft damit gleichgesetzt wird

Problem Management gegen Incident Management

Das Incident Management bringt den Service zurück, so schnell es geht. Das Problem Management fragt, warum er weg war, und arbeitet an einer Lösung, die den nächsten Ausfall verhindert.

Problem Management gegen Change Enablement

Die dauerhafte Behebung eines Known Error ist eine Änderung und läuft über die Freigabe im Change Enablement. Das Problem Management liefert die Begründung, nicht die Autorisierung.

Problem Management gegen Continual Improvement

Problem Management beseitigt Fehlerursachen. Continual Improvement kümmert sich auch um das, was fehlerfrei läuft, aber zu langsam, zu teuer oder am Bedarf vorbei ist.

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

Die Praktik fällt als Erste aus, weil sie nie dringend ist

Problem Management konkurriert mit dem Tagesgeschäft um dieselben Stunden, und das Tagesgeschäft gewinnt jeden einzelnen Tag. Es funktioniert deshalb nur mit fest eingeplanter Zeit und einer Auswahl nach Risiko: Was verursacht die meiste Ausfallzeit, was trifft die kritischsten Services, was wiederholt sich mit hoher Wahrscheinlichkeit. Nicht: worüber wurde zuletzt am lautesten geklagt.

Ein Known Error ist ein Problem mit bekannter Ursache oder bekanntem Workaround, das noch nicht behoben ist. Der Wert steckt in der Dokumentation: Der Service Desk findet den Workaround und stellt den Betrieb in Minuten wieder her, statt jedes Mal neu zu suchen. Ohne diese Verbindung zwischen Analyse und täglicher Störungsbearbeitung bleibt die Untersuchung folgenlos.

Nicht jedes Problem wird behoben. Manche Ursachen sitzen in einem System, das ohnehin abgelöst wird, bei anderen kostet die Behebung mehr als der Schaden. Diese Entscheidung bewusst zu treffen, festzuhalten und den Workaround stattdessen sauber zu pflegen, gehört zur Praktik dazu und ist kein Scheitern.

Problem Management lernen

Wie du Ursachenarbeit neben dem Tagesgeschäft verankerst, ist Thema der Schulungen im IT-Service-Management .

Die Praktik im Zusammenhang mit Incident- und Change-Themen behandeln die deutschsprachigen ITIL-4-Module .

Wissen prüfen

Sitzt Problem 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

Wie viele Probleme sollte ein Team gleichzeitig bearbeiten?
Weniger, als es Kandidaten gibt. Analyse braucht ungeteilte Zeit, und parallel geöffnete Records ohne Fortschritt kosten Pflegeaufwand und erzeugen den Eindruck, es passiere etwas.
Ist ein Workaround eine Lösung?
Er ist eine legitime Zwischenlösung und manchmal die endgültige. Entscheidend ist, dass er dokumentiert, auffindbar und regelmäßig überprüft wird, sonst wird aus der Zwischenlösung ein stiller Dauerzustand, den niemand mehr versteht.
Braucht Problem Management eine formale Ursachenanalyse?
Eine Methode hilft, sei es die Fünf-Warum-Methode, ein Ursache-Wirkungs-Diagramm oder eine zeitliche Rekonstruktion. Wichtiger als die Wahl der Methode ist, dass die Analyse nachvollziehbar aufgeschrieben wird, denn sie wird beim nächsten ähnlichen Fall wieder gebraucht.

Passt thematisch dazu

Solange jede Störung in derselben Warteschlange landet, sucht niemand nach der Ursache, und die Trennlinie zwischen schnellem Wiederherstellen und Ursachensuche entscheidet darüber, wer wann übernimmt.

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.

Problem Management im Kurs statt im Lexikon

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