Problem Management: Root Cause Analysis

Während Incident Management den Service so schnell wie möglich wiederherstellt, geht es bei Problem Management darum, die Ursache herauszufinden – damit der gleiche Vorfall nicht wiederkommt. „Workaround" reicht nicht; gefragt ist die Root Cause. Ein Beispiel: dreimal in zwei Wochen sind die Druckdienste hängengeblieben, jedes Mal hat das 1st Level den Spooler-Dienst neugestartet (Workaround). Incident Management ist zufrieden – schnell behoben. Problem Management dagegen fragt: warum bleibt der Spooler stecken? Antwort am Ende: ein bestimmter PCL-Druckjob aus der Buchhaltung verursacht den Hänger. Lösung: Druckertreiber tauschen, Problem ist weg. Diese Lektion zeigt dir den Problem-Management-Prozess, die zwei wichtigen Methoden 5-Whys und Ishikawa-Diagramm und wie Problem Management mit Incident Management, KEDB und Change Management zusammenarbeitet.

1) Incident vs. Problem – zwei Konzepte, ein Vorfall

Wichtig: Incidents werden geschlossen, sobald der Workaround läuft. Probleme bleiben offen, bis die Ursache beseitigt ist. Beide Tickets können parallel im System sein.

2) Reaktives und proaktives Problem Management

Es gibt zwei Modi, in denen Probleme entstehen:

• Reaktives Problem Management: ausgelöst durch konkrete Incidents. Trigger: ein Major Incident, oder eine Häufung gleichartiger Vorfälle, oder ein wiederholter Workaround.
• Proaktives Problem Management: Analyse von Trends, ohne konkreten Auslöser. „Wir sehen seit Wochen, dass die Login-Antwortzeiten steigen – was steckt dahinter?" Bevor es zum Major Incident wird. Eng verzahnt mit Kapazitätsplanung und Monitoring.

3) Der Problem-Management-Prozess

Schritt 5 ist entscheidend – ein erkanntes Problem ohne Workaround-Dokumentation hilft niemandem. Sobald die Ursache klar ist, muss ein Workaround in der KEDB stehen, damit folgende Vorfälle schneller behoben werden. Schritt 6 (Solution) führt typisch zu einem Change Request (RFC) – Problem Management findet die Ursache, Change Management umsetzt die Lösung.

4) RCA-Methode #1 – Die 5-Whys

Die einfachste und überraschend wirkungsvolle Methode aus dem Toyota Production System: frage fünfmal warum, bis du nicht mehr ein Symptom, sondern die wirkliche Ursache erreicht hast. Klick „nächste Frage", um eine reale Kette durchzugehen:

5) RCA-Methode #2 – Das Ishikawa-Diagramm

Auch Fischgrät-Diagramm genannt, weil seine Struktur aussieht wie ein Fischskelett. Ursprünglich aus dem Qualitätsmanagement (Kaoru Ishikawa, 1960er). Du nennst das Problem an der Spitze und sammelst alle möglichen Ursachen in sechs Kategorien (klassische „6M"). Klick die Kategorien an, um zu sehen, was für IT-Probleme jeweils typisch ist:

6) Known Errors – das Zwischen­ergebnis

Ein Known Error ist ein Problem, dessen Ursache bekannt ist, aber für das es noch keine endgültige Lösung gibt – nur einen Workaround. Diese Kombination wird in der KEDB verewigt. Dadurch:

• 1st Level kann bei wiederkehrenden Symptomen den Workaround in Sekunden anwenden.
• Die Ticket-Bearbeitungszeit für gleichartige Vorfälle sinkt drastisch.
• Das Wissen geht nicht verloren, wenn der ursprüngliche Bearbeiter weg ist.

Beispiel: ein Bug im DB-Connection-Pool, der erst bei einer bestimmten Konfiguration auftritt. Ursache klar, Hersteller-Patch in Arbeit – bis dahin „Restart des Pools" als Workaround. Das ist ein klassischer Known Error.

7) Weitere RCA-Methoden

8) Antipatterns

• Workaround als Lösung. Spooler-Restart wird zur „Lösung" deklariert, das Problem-Ticket geschlossen. Sechs Wochen später kommt der gleiche Vorfall wieder.
• Schuldzuweisung statt Ursachenanalyse. „Wer hat das verbockt?" verhindert ehrliche RCA. Lösung: Blameless Post-Mortems.
• Bei Why #2 stehenbleiben. Die ersten zwei Whys liefern Symptome, nicht Ursachen. Hartnäckig weiterfragen.
• RCA ohne Datenbasis. Vermutungen statt Logs. Lösung: Logs, Monitoring-Historie, CMDB konsultieren.
• Findings in der Schublade. RCA-Ergebnisse stehen in einem Word-Dokument, das niemand findet. Lösung: RFC + KEDB-Eintrag obligatorisch.
• Politische Ursachen ausklammern. Die echte Ursache ist „wir haben kein Patch-Management" – aber das anzusprechen kostet niemanden seine Komfortzone. Lösung: Mut zur unbequemen Wahrheit.

Zusammenfassung

Problem Management sucht und beseitigt die Ursache wiederkehrender oder schwerwiegender Vorfälle – im Gegensatz zum Wiederherstellungsfokus des Incident Management. Reaktiv (durch konkrete Incidents ausgelöst) oder proaktiv (durch Trends, ohne aktuellen Anlass). Prozess: Identify → Log → Investigate → RCA → Workaround/KEDB → Solution (RFC) → Close/Review. Wichtigste Methoden: 5-Whys (einfache iterative Frage-Kette bis zur eigentlichen Ursache) und Ishikawa-Diagramm (Fischgrät mit den 6M-Kategorien Mensch/Maschine/Material/Methode/Messung/Umgebung). Weitere Methoden: Kepner-Tregoe, Pareto, FTA. Ergebnis: ein Known Error (Ursache bekannt, Workaround dokumentiert) in der KEDB + ein RFC für die nachhaltige Lösung über Change Management. Antipatterns: Workaround als Endlösung, Schuldzuweisung, frühes Stoppen der 5-Whys, RCA ohne Daten, Findings ohne Umsetzung.

Verwandte Lektionen: KEDB · Incident Management · Change Management · und mehrWeitere relevante LektionenSystematische FehlersucheLog-AnalyseKapazitätsplanungKnowledge BasePDCA-ZyklusPatch-ManagementCMDB