Projektmanagement & ITIL

Problem Management

Overview

Ein Problem ist nach ITIL die Ursache oder mögliche Ursache eines oder mehrerer Incidents. Problem Management analysiert diese Ursachen, dokumentiert sie als Known Error mit Workaround und stößt eine dauerhafte Behebung an, meist über einen Change.

Reaktives Problem Management startet nach einer Häufung oder einem Major Incident. Proaktives Problem Management sucht Schwachstellen vorher, etwa durch Auswertung von Monitoring-Daten, Herstellerhinweisen oder Trendanalysen der Tickets.

Abgrenzung: Incident Management stellt den Betrieb schnell wieder her, auch mit Notlösungen. Problem Management darf länger dauern und fragt nach dem Warum. Das Post-Mortem ist ein Werkzeug, das in beiden Practices genutzt wird.

How it works

ITIL 4 gliedert Problem Management in drei Phasen:

  1. Problem Identification: Häufungen, Trends oder schwere Incidents werden als Problem erfasst.
  2. Problem Control: Analyse der Ursache, z. B. mit 5-Why, Ishikawa-Diagramm, Fehlerbaumanalyse oder Zeitachsen, und Dokumentation eines Workarounds.
  3. Error Control: Bewertung, ob und wie der Known Error dauerhaft behoben wird, und Übergabe an Change Enablement.

Known Errors mit Workarounds landen in einer Known Error Database (KEDB) oder in der Wissensdatenbank, damit der Service Desk gleichartige Incidents schneller löst.

Benefits

  • Weniger Tickets auf Dauer, weil die Ursache behoben wird statt immer wieder das Symptom.
  • Schnellere Incident-Lösung durch dokumentierte Workarounds, die der First Level direkt anwenden kann.
  • Bessere Entscheidungen über Investitionen, da Problem-Datensätze zeigen, welche Systeme wiederholt Kosten verursachen.
  • Lernende Organisation: Ursachenanalysen decken auch Prozess- und Dokumentationslücken auf, nicht allein technische Fehler.

Practical example

Ein Steuerberatungsbüro mit 80 Mitarbeitenden meldet seit Wochen sporadische Abbrüche der Remote-Desktop-Sitzungen. Die IT legt ein Problem an, verknüpft 35 Incidents und wertet die Zeitpunkte aus. Die Analyse zeigt eine Korrelation mit dem nächtlichen Snapshot des Hypervisors, der sich durch längere Laufzeit bis in die Arbeitszeit zieht. Ein Change verschiebt das Backup-Fenster, der Workaround (neu verbinden) steht bis dahin in der Wissensdatenbank.

Things to keep in mind

  • Lege nicht für jeden Incident ein Problem an, sondern definiere Auslöser, etwa drei gleichartige Incidents pro Woche oder jeder Major Incident.
  • Gib jedem Problem einen Verantwortlichen mit Zeitbudget, sonst bleibt die Analyse im Tagesgeschäft liegen.
  • Nutze die Techniken 5-Why und Ishikawa als Einstieg, ergänze sie aber mit Daten aus Logs und Monitoring, weil diese Methoden allein oft zu oberflächlich bleiben.
  • Schließe ein Problem erst, wenn der Change umgesetzt ist und keine neuen Incidents mehr auftreten.

Conclusion

Problem Management macht aus Feuerwehr-Einsätzen nachhaltige Verbesserungen. Schon ein schlanker Ablauf mit klaren Auslösern und KEDB senkt das Ticketvolumen spürbar.

Further reading

Related articles