4.1 Problem Management – Ziele, Begriffe und Abgrenzung
Kurz erklärt
Problem Management beschäftigt sich mit den Ursachen von Incidents.
Während Incident Management vor allem den Service schnell wiederherstellen soll, untersucht Problem Management, warum Incidents entstehen und wie Wiederholungen vermieden werden können.
Ziel ist nicht nur die schnelle Reparatur, sondern eine nachhaltige Verbesserung der Servicequalität.
Warum Problem Management wichtig ist
Viele Störungen treten nicht nur einmal auf.
Beispiele:
- VPN bricht regelmäßig ab.
- Druckerwarteschlangen blockieren immer wieder.
- Benutzer melden wiederholt Anmeldeprobleme.
- Ein Dienst muss regelmäßig neu gestartet werden.
- Nach Updates entstehen ähnliche Fehler.
- Ein Speicherbereich läuft immer wieder voll.
Wenn solche Fälle nur einzeln gelöst werden, bleibt die eigentliche Ursache bestehen.
Problem Management hilft dabei:
- wiederkehrende Incidents zu erkennen,
- Ursachen systematisch zu untersuchen,
- Workarounds bereitzustellen,
- dauerhafte Lösungen vorzubereiten,
- bekannte Fehler zu dokumentieren,
- und zukünftige Incidents zu vermeiden.
Incident und Problem unterscheiden
| Incident | Problem |
|---|---|
| ungeplante Unterbrechung oder Qualitätsminderung eines Service | Ursache oder mögliche Ursache eines oder mehrerer Incidents |
| Fokus auf schnelle Wiederherstellung | Fokus auf Ursachenverständnis und Vermeidung |
| kurzfristige Bearbeitung | häufig längerfristige Analyse |
| Workaround kann ausreichen | dauerhafte Lösung wird angestrebt |
| Ziel: Service wieder nutzbar machen | Ziel: Wiederholung verhindern oder Auswirkungen reduzieren |
Beispiel:
Incident
Benutzer können sich nicht am VPN anmelden.
Problem
Die Ursache liegt in einer fehlerhaften Zertifikatsverteilung, die regelmäßig zu abgelaufenen Client-Zertifikaten führt.
Problem Management ist nicht nur Fehlerbehebung
Problem Management bedeutet nicht nur:
Jemand sucht den technischen Fehler.
Es umfasst auch:
- Muster erkennen,
- Daten auswerten,
- Risiken bewerten,
- bekannte Fehler dokumentieren,
- Workarounds bereitstellen,
- Änderungen vorbereiten,
- Wissen nutzbar machen,
- und Verbesserungen nachverfolgen.
Ein Problem kann auch dann angelegt werden, wenn noch keine endgültige Ursache bekannt ist.
Problem, Known Error und Workaround unterscheiden
| Begriff | Bedeutung |
|---|---|
| Problem | Ursache oder mögliche Ursache eines oder mehrerer Incidents |
| Known Error | Problem mit bekannter Ursache oder bekanntem Fehlerzustand |
| Workaround | vorübergehende Möglichkeit, Auswirkungen zu umgehen oder zu reduzieren |
| dauerhafte Lösung | Maßnahme, die die Ursache beseitigt oder das Risiko nachhaltig reduziert |
Beispiel:
Problem
Mehrere Clients verlieren nach dem Ruhezustand die VPN-Verbindung.
Known Error
Bestimmte Client-Version verursacht nach dem Ruhezustand fehlerhafte Tunnelzustände.
Workaround
VPN-Client vollständig beenden und neu starten.
Dauerhafte Lösung
Client-Version aktualisieren oder Konfiguration ändern.
Problem Management und Incident Management arbeiten zusammen
Incident Management liefert wichtige Informationen für Problem Management.
Dazu gehören:
- betroffene Services,
- Symptome,
- Zeitpunkte,
- Häufigkeit,
- betroffene Benutzer,
- Workarounds,
- technische Maßnahmen,
- Logs,
- und wiederkehrende Muster.
Problem Management liefert zurück:
- Known Errors,
- Workarounds,
- Ursacheninformationen,
- Empfehlungen,
- Knowledge-Artikel,
- und Change-Vorschläge.
Dadurch werden zukünftige Incidents schneller lösbar oder vollständig vermieden.
Reaktives Problem Management
Reaktives Problem Management beginnt nach Incidents.
Auslöser können sein:
- wiederkehrende Incidents,
- Major Incidents,
- hohe Auswirkungen,
- unbekannte Ursache,
- viele gleichartige Meldungen,
- häufige Workarounds,
- auffällige Eskalationen,
- oder wiederholte SLA-Gefährdung.
Beispiel:
Nach einem Major Incident wird untersucht, warum ein zentraler Dienst ausgefallen ist und warum Monitoring nicht früher gewarnt hat.
Proaktives Problem Management
Proaktives Problem Management sucht nach Problemen, bevor größere Incidents entstehen.
Informationsquellen können sein:
- Trends,
- Monitoringdaten,
- Kapazitätsdaten,
- Loganalysen,
- Service Reviews,
- Sicherheitsmeldungen,
- Benutzerfeedback,
- wiederkehrende kleine Störungen,
- technische Schulden,
- und Lieferanteninformationen.
Beispiel:
Monitoring zeigt, dass Speicherplatz auf mehreren Servern regelmäßig kritisch wird.
Noch ist kein Ausfall eingetreten.
Problem Management kann trotzdem prüfen, warum Kapazitätsplanung, Alarmierung oder Bereinigung nicht ausreichen.
Typische Auslöser für einen Problem Record
Ein Problem Record kann sinnvoll sein, wenn:
- mehrere ähnliche Incidents auftreten,
- ein Major Incident stattgefunden hat,
- die Ursache eines wichtigen Incidents unbekannt bleibt,
- ein Workaround häufig genutzt werden muss,
- ein Service wiederholt instabil ist,
- ein technisches Risiko erkennbar wird,
- ein Lieferant einen bekannten Fehler bestätigt,
- ein Sicherheitsrisiko vermutet wird,
- oder ein Trend auf zukünftige Störungen hindeutet.
Nicht jeder einzelne Incident benötigt automatisch einen Problem Record.
Problem Record
Ein Problem Record dokumentiert die Bearbeitung eines Problems.
Typische Inhalte:
- Beschreibung des Problems,
- betroffener Service,
- betroffene Configuration Items,
- zugehörige Incidents,
- Auswirkungen,
- Priorität,
- bekannte Symptome,
- Hypothesen,
- Untersuchungsergebnisse,
- Ursache, falls bekannt,
- Workaround,
- Known-Error-Status,
- empfohlene dauerhafte Lösung,
- erforderlicher Change,
- Verantwortlicher,
- Status,
- Lessons Learned.
Das konkrete Format hängt vom verwendeten ITSM-System und der Organisation ab.
Priorisierung von Problems
Problems sollten priorisiert werden.
Kriterien können sein:
- Anzahl betroffener Incidents,
- Auswirkung auf Services,
- geschäftliche Kritikalität,
- Sicherheitsrisiko,
- Häufigkeit,
- Kosten,
- Aufwand,
- Risiko einer Wiederholung,
- Verfügbarkeit eines Workarounds,
- und Nutzen einer dauerhaften Lösung.
Ein Problem mit wenigen Incidents kann trotzdem hohe Priorität besitzen, wenn es einen kritischen Service oder ein hohes Sicherheitsrisiko betrifft.
Problem Management und Change Enablement
Dauerhafte Lösungen erfordern häufig Änderungen.
Beispiele:
- Softwareupdate,
- Konfigurationsänderung,
- Austausch defekter Hardware,
- Änderung einer Firewall-Regel,
- Anpassung eines Prozesses,
- neues Monitoring,
- Änderung eines Deployments,
- Architekturverbesserung.
Solche Maßnahmen sollten nicht unkontrolliert umgesetzt werden.
Sie müssen entsprechend Risiko, Auswirkung und Organisationsregeln über Change Enablement gesteuert werden.
Problem Management und Knowledge Management
Problem Management erzeugt wertvolles Wissen.
Dieses Wissen sollte nutzbar gemacht werden für:
- Service Desk,
- Fachgruppen,
- Benutzer,
- Major-Incident-Bearbeitung,
- Self-Service,
- Runbooks,
- Known-Error-Datenbank,
- und Continual Improvement.
Beispiele:
- bekannter Fehler mit Workaround,
- Diagnosehinweise,
- Eskalationskriterien,
- betroffene Versionen,
- Abbruchkriterien,
- dauerhafte Lösung nach Change.
Wissen darf nicht nur im Kopf einzelner Spezialisten bleiben.
Problem Management und Service Configuration Management
Für Ursachenanalysen sind Service- und CI-Informationen wichtig.
Hilfreich sind:
- betroffene Configuration Items,
- Abhängigkeiten zwischen Services,
- installierte Versionen,
- letzte Änderungen,
- Standorte,
- Verantwortliche,
- Lieferanten,
- und technische Beziehungen.
Ohne diese Informationen wird Ursachenanalyse oft langsam und ungenau.
Beispiel:
Mehrere Anwendungen fallen aus.
Erst durch die CI-Beziehungen wird erkennbar, dass alle vom gleichen Datenbankcluster abhängig sind.
Problem Management und Continual Improvement
Problem Management ist eng mit kontinuierlicher Verbesserung verbunden.
Aus Problems können entstehen:
- Verbesserungsmaßnahmen,
- neue Standards,
- bessere Überwachung,
- aktualisierte Runbooks,
- Knowledge-Artikel,
- Schulungen,
- Automatisierungen,
- Architekturänderungen,
- oder Prozessanpassungen.
Ein gelöstes Problem sollte deshalb nicht nur abgeschlossen werden.
Es sollte geprüft werden, welche Erkenntnisse für zukünftige Arbeit nutzbar sind.
Problem Management und Risiko
Nicht jede Ursache kann sofort beseitigt werden.
Manchmal ist eine dauerhafte Lösung:
- zu teuer,
- zu riskant,
- technisch noch nicht verfügbar,
- abhängig von einem Lieferanten,
- nur in einem Wartungsfenster möglich,
- oder organisatorisch noch nicht entschieden.
Dann muss das verbleibende Risiko bewusst bewertet und dokumentiert werden.
Mögliche Maßnahmen:
- Workaround bereitstellen,
- Monitoring verbessern,
- Benutzer informieren,
- Risiko akzeptieren,
- Change später planen,
- Lieferant einbinden,
- oder Service-Level-Erwartungen anpassen.
Workaround als wichtiger Zwischenschritt
Ein Workaround ist keine endgültige Lösung, kann aber sehr wertvoll sein.
Er hilft dabei:
- Incidents schneller zu lösen,
- Auswirkungen zu reduzieren,
- Benutzer arbeitsfähig zu halten,
- Zeit für Ursachenanalyse zu gewinnen,
- Service Desk zu unterstützen.
Ein Workaround sollte dokumentiert werden mit:
- Anwendungsbereich,
- Voraussetzungen,
- Arbeitsschritten,
- Risiken,
- Einschränkungen,
- Gültigkeitsdauer,
- und Eskalationshinweisen.
Dauerhafte Lösung
Eine dauerhafte Lösung soll die Ursache beseitigen oder das Risiko wesentlich reduzieren.
Beispiele:
- fehlerhafte Softwareversion aktualisieren,
- Zertifikatsüberwachung einführen,
- Kapazität erweitern,
- defekte Hardware austauschen,
- Berechtigungskonzept korrigieren,
- Prozesslücke schließen,
- Monitoring verbessern,
- automatisierte Prüfung einführen,
- Schulung durchführen.
Nicht jede dauerhafte Lösung ist rein technisch.
Auch Prozesse, Kommunikation und Verantwortlichkeiten können Ursachen sein.
Technische Ursache und organisatorische Ursache
Ein Problem kann mehrere Ursachenebenen besitzen.
Beispiel:
Ein Zertifikat läuft ab.
Technische Ursache
Zertifikat ist nicht mehr gültig.
Organisatorische Ursache
Es gab keinen verantwortlichen Owner für Zertifikatsüberwachung.
Prozessursache
Es gab keinen geregelten Ablauf für rechtzeitige Erneuerung.
Verbesserung
Monitoring, Verantwortlichkeit und Erneuerungsprozess werden eingeführt.
Merke
Die technische Ursache ist oft nur ein Teil der Gesamtursache.
Problem Management ist keine Schuldsuche
Problem Management soll nicht klären, wer schuld ist.
Ziel ist:
- verstehen,
- lernen,
- verbessern,
- Wiederholungen vermeiden,
- Risiken reduzieren,
- Servicequalität erhöhen.
Eine Schuldzuweisung führt häufig dazu, dass Informationen zurückgehalten werden.
Eine lernorientierte Analyse führt zu besseren Ergebnissen.
Praxisbeispiel: Wiederkehrende VPN-Störungen
Ausgangslage
Mehrere Benutzer melden regelmäßig VPN-Abbrüche.
Incident Management stellt den Zugang jeweils durch Neustart des Clients wieder her.
Problem Management
Die Incidents werden gemeinsam ausgewertet.
Auffällig ist:
- gleiche Client-Version,
- gleiche Fehlermeldung,
- besonders häufig nach Ruhezustand,
- Workaround immer identisch.
Ergebnis
Ein Known Error wird dokumentiert.
Ein Workaround wird für den Service Desk bereitgestellt.
Ein Change zur Aktualisierung des VPN-Clients wird geplant.
Praxisbeispiel: Druckerwarteschlange blockiert
Ausgangslage
Ein Etikettendrucker im Versand blockiert mehrfach pro Woche.
Incident Management entfernt jeweils den fehlerhaften Druckauftrag.
Problem Management
Die Analyse zeigt:
- bestimmte PDF-Dateien verursachen den Fehler,
- Treiber ist veraltet,
- Workaround ist bekannt,
- Versand ist regelmäßig betroffen.
Dauerhafte Lösung
Treiber wird getestet und über Change Enablement aktualisiert.
Zusätzlich wird ein Knowledge-Artikel für den Service Desk erstellt.
Praxisbeispiel: Speicher läuft voll
Ausgangslage
Ein Server erzeugt regelmäßig Incidents wegen vollem Speicher.
Incident Management löscht temporäre Dateien.
Problem Management
Die Untersuchung zeigt:
- Logrotation funktioniert nicht korrekt,
- Monitoring warnt zu spät,
- Verantwortlichkeit für Logwachstum war unklar.
Verbesserung
- Logrotation korrigieren,
- Monitoring-Grenzwerte anpassen,
- Verantwortlichen festlegen,
- Runbook aktualisieren.
Typische Fehler
Fehler 1
Jeder Incident wird einzeln bearbeitet, ohne Muster zu erkennen.
Fehler 2
Problem Management wird erst nach sehr großen Störungen genutzt.
Fehler 3
Workarounds werden nicht dokumentiert.
Fehler 4
Known Errors bleiben nur einzelnen Spezialisten bekannt.
Fehler 5
Die technische Ursache wird gefunden, aber organisatorische Ursachen werden ignoriert.
Fehler 6
Dauerhafte Lösungen werden ohne Change-Bewertung umgesetzt.
Fehler 7
Problems werden eröffnet, aber nicht aktiv verfolgt.
Fehler 8
Priorisierung fehlt.
Fehler 9
Problem Management wird als Schuldsuche verstanden.
Fehler 10
Lessons Learned werden nicht in Knowledge, Monitoring oder Prozesse übernommen.
Checkliste Problem erfassen
- Wiederkehrende oder schwerwiegende Incidents geprüft
- betroffener Service beschrieben
- zugehörige Incidents verknüpft
- Auswirkungen dokumentiert
- Symptome zusammengefasst
- erste Hypothesen dokumentiert
- Priorität bewertet
- Verantwortlicher benannt
- Workaround geprüft
- Knowledge-Bedarf erkannt
Checkliste Problem bearbeiten
- relevante Daten gesammelt
- Incidents verglichen
- Changes geprüft
- Logs und Monitoringdaten ausgewertet
- betroffene CIs geprüft
- Ursachenhypothesen getestet
- Workaround dokumentiert
- Known Error bewertet
- dauerhafte Lösung vorgeschlagen
- Change-Bedarf geprüft
- Risiko dokumentiert
- Stakeholder informiert
Checkliste Problem abschließen
- Ursache ausreichend verstanden oder Risiko bewertet
- Workaround dokumentiert
- Known Error aktualisiert
- dauerhafte Lösung umgesetzt oder bewusst geplant
- zugehörige Incidents berücksichtigt
- Knowledge-Artikel erstellt oder aktualisiert
- Monitoring oder Runbooks angepasst
- Lessons Learned dokumentiert
- Verbesserungsmaßnahmen verfolgt
- Rest Risiko bekannt und akzeptiert
Bedeutung für Fachinformatiker für Systemintegration
Fachinformatiker für Systemintegration liefern häufig die wichtigsten technischen Informationen für Problem Management.
Dazu gehören:
- Logs,
- Messwerte,
- Konfigurationen,
- Versionsstände,
- Abhängigkeiten,
- Change-Historie,
- Workarounds,
- Fehlerhäufigkeit,
- und technische Hypothesen.
Wichtig ist nicht nur, einen Incident schnell zu beheben.
Wichtig ist auch, wiederkehrende Ursachen zu erkennen und die Umgebung dauerhaft stabiler zu machen.
Zusammenfassung
Incidents treten auf
↓
Muster oder schwere Auswirkungen werden erkannt
↓
Problem Record wird erstellt
↓
Ursache oder mögliche Ursache wird untersucht
↓
Workaround wird dokumentiert
↓
Known Error wird bei Bedarf erfasst
↓
dauerhafte Lösung wird geplant
↓
Change, Knowledge und Improvement werden eingebunden
↓
zukünftige Incidents werden reduziert oder schneller lösbar
Merksätze
Incident Management stellt den Service wieder her.
Problem Management versteht und reduziert Ursachen.
Ein Workaround ist hilfreich, aber keine dauerhafte Lösung.
Ein Known Error muss nutzbar dokumentiert sein.
Problem Management ist Lernen, nicht Schuldsuche.
Gute Problem Records machen Services langfristig stabiler.
Verwandte Seiten
- 3.6 Erstdiagnose, Lösung und funktionale Eskalation
- 3.7 Ownership, hierarchische Eskalation und Major Incidents
- 3.9 Kennzahlen, Qualität und Continual Improvement im Service Desk
- 4.2 Ursachenanalyse
- 4.3 Workarounds und Known Errors
- 4.4 Trendanalyse und proaktives Problem Management
- Change Enablement
- Knowledge Management
- Service Configuration Management
- Continual Improvement
Quellen und Versionsstand
Offizielle Grundlagen
- PeopleCert – ITIL Practice Guide: Problem Management
- PeopleCert – ITIL Practice Guide: Incident Management
- PeopleCert – ITIL Practice Guide: Knowledge Management
- PeopleCert – ITIL Practice Guide: Change Enablement
- PeopleCert – ITIL Practice Guide: Service Configuration Management
- ITIL Foundation – Version 5
Einordnung
Die dargestellten:
- Problem-Record-Inhalte,
- Beispiele,
- Checklisten,
- Priorisierungskriterien,
- Workaround-Hinweise,
- und Praxisabläufe
sind herstellerneutrale Praxisempfehlungen.
ITIL schreibt keine universelle:
- Problem-Record-Vorlage,
- RCA-Methode,
- Prioritätsmatrix,
- Workaround-Struktur,
- Review-Vorgabe,
- oder konkrete Toolauswahl
für alle Organisationen vor.
Die konkrete Umsetzung muss an:
- Services,
- Risiken,
- Organisation,
- Datenqualität,
- Supportmodell,
- Lieferanten,
- Service Levels,
- und verfügbare Fähigkeiten
angepasst werden.
Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance
Fachlicher Stand: August 2026