Was ist Problem Management?

Problem, Known Error, Workaround

Drei Begriffe tragen die ganze Praktik. Wer sie sauber auseinanderhält, versteht auch, warum Problem Management mehr ist als ein zweiter Name für Störungsbearbeitung.

• Problem

  Die Ursache oder mögliche Ursache eines oder mehrerer Incidents. Ein Problem kann schon existieren, bevor überhaupt eine Störung aufgetreten ist.

• Known Error

  Ein Problem, das analysiert, aber noch nicht behoben ist. Die Ursache ist verstanden, die dauerhafte Lösung steht noch aus.

• Workaround

  Eine Lösung, die die Auswirkung eines Incidents oder Problems verringert oder beseitigt, solange keine dauerhafte Lösung verfügbar ist, etwa ein Neustart, eine geänderte Einstellung oder ein alternativer Arbeitsweg.

Der Wert eines Workarounds 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, der ein Team davor bewahrt, dieselbe Analyse dreimal zu machen.

Der Ablauf in drei Phasen

ITIL 4 spricht von einer Praktik, nicht mehr von einem Prozess, beschreibt aber drei Phasen, die ein Problem typischerweise durchläuft. Jedes Problem bekommt dafür einen eigenen Datensatz, den Problem Record, mit Verantwortung, Priorität und Status.

1. 1

   Problem Identification

   Kandidaten finden: aus Häufungen im Incident-Verlauf, aus der Nachbereitung von Major Incidents, aus Hinweisen von Herstellern und aus Auffälligkeiten im Monitoring.

2. 2

   Problem Control

   Analysieren, nach Risiko priorisieren und, wo möglich, mit einem Workaround entschärfen. Ist die Ursache verstanden, wird das Problem als Known Error dokumentiert.

3. 3

   Error Control

   Known Errors im Blick behalten: prüfen, ob der Workaround noch trägt und ob eine dauerhafte Lösung inzwischen wirtschaftlich ist. Umgesetzt wird sie dann über das Change Enablement.

Reaktives und proaktives Problem Management

Reaktiv heißt: Ein Problem wird angelegt, weil Störungen bereits aufgetreten sind, etwa nach einem Major Incident oder weil dieselbe Störung zum fünften Mal gemeldet wurde. Das ist der häufigste Fall und der leichteste Einstieg, weil der Anlass sichtbar ist.

Proaktiv heißt: Ein Problem wird erkannt, bevor es Nutzer trifft. Quellen sind Trendauswertungen im Monitoring, etwa ein langsam volllaufender Speicher, Sicherheitshinweise von Herstellern, bekannte Fehler in einer Softwareversion, die bald eingespielt wird, oder Erkenntnisse aus Tests. Proaktive Arbeit ist wertvoller, aber auch schwerer zu begründen, weil der vermiedene Ausfall nie sichtbar wird.

Methoden der Ursachenanalyse

ITIL schreibt keine Methode vor. Welche passt, hängt davon ab, ob die Ursache eher in einer Kette von Ereignissen, in mehreren zusammenwirkenden Faktoren oder in einer technischen Abweichung liegt.

• Fünf-Warum-Methode

  So lange nach dem Warum fragen, bis man bei einer Ursache ankommt, die sich beheben lässt. Schnell, aber anfällig dafür, bei der ersten plausiblen Antwort stehen zu bleiben.

• Ursache-Wirkungs-Diagramm (Ishikawa)

  Mögliche Ursachen nach Kategorien wie Technik, Prozess, Mensch und Umgebung sammeln. Hilft, wenn mehrere Faktoren zusammenwirken.

• Zeitliche Rekonstruktion

  Die Ereignisse vor einer Störung minutengenau aus Logs, Changes und Meldungen zusammensetzen. Oft der schnellste Weg zum auslösenden Change.

• Kepner-Tregoe-Problemanalyse

  Systematisch vergleichen, wo, wann und in welchem Umfang der Fehler auftritt und wo nicht. Eignet sich für hartnäckige technische Fehler.

Wichtiger als die Wahl der Methode ist, dass die Analyse nachvollziehbar im Problem Record steht, denn sie wird beim nächsten ähnlichen Fall wieder gebraucht.