4. Problem Management
- 4.1 Problem Management – Ziele, Begriffe und Abgrenzung
- 4.2 Ursachenanalyse (Root Cause Analysis – RCA)
- 4.3 Workarounds und Known Errors
- 4.4 Trendanalyse und proaktives Problem Management
- 4.5 Problem Management im Zusammenspiel mit Incident, Change und Knowledge Management
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
4.2 Ursachenanalyse (Root Cause Analysis – RCA)
Kurz erklärt
Ursachenanalyse bedeutet, systematisch zu untersuchen, warum ein Incident oder Problem entstanden ist.
Ziel ist nicht, möglichst schnell einen Schuldigen zu finden.
Ziel ist, die tatsächlichen technischen, organisatorischen oder prozessualen Ursachen zu verstehen, damit Wiederholungen verhindert oder Auswirkungen reduziert werden können.
Warum Ursachenanalyse wichtig ist
Ohne Ursachenanalyse werden Incidents häufig nur kurzfristig behoben.
Beispiele:
- Dienst wird immer wieder neu gestartet.
- Speicher wird regelmäßig manuell bereinigt.
- Benutzerkonten werden mehrfach entsperrt.
- VPN-Client wird immer wieder neu installiert.
- Druckwarteschlange wird regelmäßig geleert.
- Zertifikate werden erst nach Ablauf erneuert.
Solche Maßnahmen können kurzfristig helfen.
Sie beantworten aber nicht die Frage:
Warum tritt der Fehler immer wieder auf?
Ursachenanalyse hilft dabei:
- wiederkehrende Störungen zu vermeiden,
- Risiken sichtbar zu machen,
- dauerhafte Lösungen vorzubereiten,
- Workarounds gezielt zu dokumentieren,
- Verbesserungen abzuleiten,
- und technische sowie organisatorische Schwachstellen zu erkennen.
Incident-Lösung und Ursachenanalyse unterscheiden
| Incident Management | Problem Management / RCA |
|---|---|
| Service schnell wiederherstellen | Ursache verstehen |
| kurzfristiger Fokus | nachhaltiger Fokus |
| Workaround kann genügen | dauerhafte Lösung wird vorbereitet |
| Ziel: Benutzer wieder arbeitsfähig machen | Ziel: Wiederholung verhindern oder Risiko senken |
| Zeitdruck häufig hoch | Analyse kann länger dauern |
Beispiel:
Ein Webservice ist nicht erreichbar.
Incident Management
- Dienststatus prüfen
- Dienst kontrolliert neu starten
- Erreichbarkeit testen
- Benutzer informieren
Ursachenanalyse
- Warum ist der Dienst abgestürzt?
- Warum wurde es nicht früher erkannt?
- Warum gab es keinen automatischen Neustart?
- Warum war kein Monitoring vorhanden?
- Warum trat der Fehler nach einem bestimmten Deployment auf?
Merke
Eine schnelle Wiederherstellung ist wichtig.
Sie ersetzt aber keine Ursachenanalyse, wenn der Fehler wiederkehren kann.
Symptom, Ursache und Grundursache unterscheiden
| Begriff | Bedeutung | Beispiel |
|---|---|---|
| Symptom | sichtbares Fehlverhalten | Benutzer kann sich nicht anmelden |
| direkte Ursache | unmittelbarer technischer Auslöser | Zertifikat ist abgelaufen |
| Grundursache | tiefer liegende Ursache | kein Prozess zur Zertifikatsüberwachung |
| beitragender Faktor | Umstand, der den Fehler begünstigt | Warnung wurde nicht an das richtige Team gesendet |
| Auswirkung | Folge für Benutzer oder Geschäft | Fachanwendung nicht nutzbar |
Ein Problem besitzt häufig nicht nur eine Ursache.
Oft wirken mehrere Faktoren zusammen.
Beispiel:
Ein Server fällt aus, weil der Speicher voll ist.
Mögliche Ursachenebenen:
- Logdateien wachsen stark.
- Logrotation funktioniert nicht.
- Monitoring warnt zu spät.
- Alarm wird an eine nicht mehr gepflegte Verteilerliste gesendet.
- Verantwortlichkeit für den Server ist unklar.
Nur die Aussage „Speicher voll“ beschreibt noch nicht die vollständige Ursache.
Ursachenanalyse ist keine Schuldzuweisung
Ursachenanalyse soll nicht klären:
Wer hat den Fehler gemacht?
Sondern:
Welche Bedingungen haben dazu geführt, dass dieser Fehler entstehen oder unentdeckt bleiben konnte?
Eine schuldorientierte Kultur führt häufig dazu, dass:
- Informationen zurückgehalten werden,
- Fehler verschwiegen werden,
- Symptome beschönigt werden,
- Mitarbeitende defensiv reagieren,
- und echte Ursachen verborgen bleiben.
Eine lernorientierte Analyse fragt stattdessen:
- Welche Annahmen waren falsch?
- Welche Kontrolle hat gefehlt?
- Welche Information war nicht verfügbar?
- Welcher Prozess war unklar?
- Welche technische Schutzmaßnahme hätte geholfen?
- Welche Dokumentation war unvollständig?
- Welche Automatisierung hätte den Fehler verhindert?
Grundprinzip einer guten Ursachenanalyse
Eine gute Ursachenanalyse ist:
- faktenbasiert,
- nachvollziehbar,
- strukturiert,
- frei von vorschnellen Schuldzuweisungen,
- offen für mehrere Ursachen,
- mit Daten belegbar,
- und auf Verbesserungen ausgerichtet.
Sie trennt:
- Beobachtungen,
- Vermutungen,
- Hypothesen,
- bestätigte Fakten,
- Schlussfolgerungen,
- und Maßnahmen.
Beobachtung und Hypothese trennen
Ungeeignet:
Die Firewall war schuld.
Besser:
Verbindungen zur Anwendung auf Port 443 schlugen vom Standort Süd fehl. Eine Firewall-Regel ist eine mögliche Ursache und wird geprüft.
Ungeeignet:
Der Benutzer hat etwas falsch gemacht.
Besser:
Der Fehler trat nach einer Änderung der Berechtigungsgruppe auf. Die Auswirkungen der Gruppenänderung werden geprüft.
Ungeeignet:
Das Update hat alles kaputt gemacht.
Besser:
Der Incident begann 20 Minuten nach dem Update. Ein Zusammenhang ist möglich, aber noch nicht bestätigt.
Merke
Zeitlicher Zusammenhang ist ein Hinweis.
Er ist noch kein Beweis.
Typischer Ablauf einer Ursachenanalyse
Ein möglicher Ablauf:
Problem beschreiben
↓
Fakten sammeln
↓
Zeitlinie erstellen
↓
Umfang und Auswirkungen bestimmen
↓
Hypothesen bilden
↓
Hypothesen prüfen
↓
Ursache und beitragende Faktoren bestimmen
↓
Workaround dokumentieren
↓
dauerhafte Lösung oder Verbesserungen ableiten
↓
Maßnahmen priorisieren und verfolgen
Nicht jede Organisation nutzt exakt diesen Ablauf.
Wichtig ist, dass die Analyse nachvollziehbar bleibt.
Problem klar beschreiben
Am Anfang sollte das Problem eindeutig beschrieben werden.
Eine gute Problembeschreibung enthält:
- betroffenen Service,
- beobachtetes Symptom,
- Zeitraum,
- betroffene Benutzer oder Standorte,
- Auswirkung,
- Häufigkeit,
- bekannte Auslöser,
- und aktuellen Workaround.
Ungeeignet:
VPN macht Probleme.
Besser:
Seit dem Client-Update vom 12.08.2026 verlieren mehrere Benutzer nach dem Ruhezustand die VPN-Verbindung. Betroffen sind Windows-Notebooks mit Client-Version 5.8. Der Workaround ist ein vollständiger Neustart des VPN-Clients.
Fakten sammeln
Geeignete Informationsquellen:
- Incident Records,
- Problem Records,
- Change Records,
- Monitoringdaten,
- Logdateien,
- Fehlermeldungen,
- Zeitstempel,
- Benutzerfeedback,
- Konfigurationsdaten,
- CMDB-Informationen,
- Herstellerhinweise,
- Netzwerkdaten,
- Backup- und Restore-Informationen,
- Sicherheitsmeldungen,
- Service-Statusmeldungen.
Wichtig ist, die Daten nicht nur zu sammeln, sondern sie fachlich einzuordnen.
Nicht jede Logmeldung ist relevant.
Nicht jeder Benutzerbericht beschreibt die technische Ursache.
Zeitlinie erstellen
Eine Zeitlinie hilft, Ereignisse in die richtige Reihenfolge zu bringen.
Beispiel:
| Zeitpunkt | Ereignis |
|---|---|
| 08:00 Uhr | Deployment abgeschlossen |
| 08:20 Uhr | erste Fehlermeldung im Monitoring |
| 08:25 Uhr | erste Benutzermeldung |
| 08:35 Uhr | Incident als P1 bewertet |
| 08:45 Uhr | Rollback vorbereitet |
| 09:05 Uhr | Workaround aktiv |
| 09:30 Uhr | Service stabil |
Eine Zeitlinie hilft bei Fragen wie:
- Was geschah vor dem Incident?
- Wann begann die Auswirkung?
- Welche Änderung war zeitlich relevant?
- Wann wurde der Incident erkannt?
- Wann wurde eskaliert?
- Welche Maßnahme hatte welchen Effekt?
- Wo entstanden Verzögerungen?
Umfang bestimmen
Zu prüfen ist:
- Sind einzelne Benutzer betroffen?
- Ist ein Team betroffen?
- Ist ein Standort betroffen?
- Sind mehrere Standorte betroffen?
- Sind externe Kunden betroffen?
- Sind alle Funktionen betroffen oder nur einzelne?
- Sind bestimmte Versionen betroffen?
- Sind bestimmte Geräte betroffen?
- Sind bestimmte Netzwerkpfade betroffen?
- Sind nur neue Sitzungen betroffen oder auch bestehende?
Der Umfang hilft, mögliche Ursachen einzugrenzen.
Beispiel:
Wenn nur ein Standort betroffen ist, sind zentrale Anwendung und Benutzerkonto möglicherweise weniger wahrscheinlich als Standortnetz, Routing, DNS oder lokale Firewall.
Änderungen prüfen
Viele Probleme stehen im Zusammenhang mit Änderungen.
Zu prüfen sind:
- Softwareupdates,
- Konfigurationsänderungen,
- Firewall-Regeln,
- DNS-Änderungen,
- Zertifikatswechsel,
- Gruppenrichtlinien,
- neue Berechtigungen,
- neue Versionen,
- Datenbankänderungen,
- Netzwerkumbauten,
- Lieferantenänderungen,
- Cloud-Konfigurationsänderungen.
Wichtig:
Ein Change ist nicht automatisch die Ursache.
Er ist zunächst ein relevanter Untersuchungsgegenstand.
5-Why-Methode
Die 5-Why-Methode fragt mehrfach „Warum?“, um von einem Symptom zu tiefer liegenden Ursachen zu gelangen.
Beispiel:
Problem
Ein Webservice war nicht erreichbar.
Warum 1
Warum war der Webservice nicht erreichbar?
Der Dienst war abgestürzt.
Warum 2
Warum ist der Dienst abgestürzt?
Der Speicher war vollständig belegt.
Warum 3
Warum war der Speicher vollständig belegt?
Logdateien sind stark angewachsen.
Warum 4
Warum wurden Logdateien nicht bereinigt?
Die Logrotation war fehlerhaft konfiguriert.
Warum 5
Warum wurde die fehlerhafte Logrotation nicht erkannt?
Es gab kein Monitoring für Logwachstum und keine regelmäßige Prüfung.
Mögliche Maßnahmen:
- Logrotation korrigieren,
- Monitoring ergänzen,
- Alarmgrenzen definieren,
- Runbook aktualisieren,
- Verantwortlichkeit festlegen.
Grenzen der 5-Why-Methode
Die 5-Why-Methode ist einfach und nützlich.
Sie hat aber Grenzen.
Risiken:
- zu lineares Denken,
- nur eine Ursache wird betrachtet,
- komplexe Zusammenhänge werden vereinfacht,
- Antworten hängen stark von der Perspektive ab,
- Schuldzuweisungen können entstehen,
- organisatorische Faktoren werden übersehen.
Deshalb sollte sie bei komplexen Incidents mit anderen Methoden kombiniert werden.
Ishikawa-Diagramm
Das Ishikawa-Diagramm wird auch Ursache-Wirkungs-Diagramm oder Fischgräten-Diagramm genannt.
Es hilft, mögliche Ursachen nach Kategorien zu sortieren.
Mögliche Kategorien in der IT:
- Mensch,
- Prozess,
- Technik,
- Umgebung,
- Organisation,
- Lieferant,
- Dokumentation,
- Daten,
- Sicherheit.
Beispiel:
Problem:
Wiederkehrende VPN-Abbrüche.
Mögliche Ursachen:
| Kategorie | Beispiele |
|---|---|
| Mensch | Benutzer versetzen Notebook in Ruhezustand |
| Prozess | Clientupdates werden nicht getestet |
| Technik | fehlerhafte VPN-Client-Version |
| Umgebung | instabile WLAN-Verbindung |
| Organisation | kein Owner für Clientstandard |
| Lieferant | bekannter Fehler in Version |
| Dokumentation | Workaround fehlt in Knowledge Base |
| Sicherheit | Zertifikatsprüfung schlägt fehl |
Das Diagramm zwingt dazu, nicht nur eine technische Ursache zu betrachten.
Pareto-Analyse
Die Pareto-Analyse hilft, die wichtigsten Ursachen oder Kategorien zu erkennen.
Grundidee:
Ein kleiner Teil der Ursachen erzeugt häufig einen großen Teil der Auswirkungen.
Beispiel:
| Kategorie | Anzahl Incidents pro Monat |
|---|---|
| Passwort und MFA | 120 |
| VPN | 75 |
| Drucker | 40 |
| Softwareinstallation | 25 |
| Sonstiges | 20 |
Wenn Passwort/MFA und VPN den größten Anteil ausmachen, können Verbesserungen dort besonders viel Wirkung entfalten.
Die Pareto-Analyse ersetzt keine Ursachenanalyse.
Sie hilft bei der Priorisierung.
Kepner-Tregoe-Ansatz
Ein strukturierter Ansatz kann sein, zu unterscheiden:
- Was ist betroffen?
- Was ist nicht betroffen?
- Wo tritt es auf?
- Wo tritt es nicht auf?
- Seit wann tritt es auf?
- Seit wann nicht?
- Wie stark ist die Auswirkung?
- Welche Veränderung passt dazu?
Beispiel:
| Frage | Antwort |
|---|---|
| Was ist betroffen? | VPN-Verbindung nach Ruhezustand |
| Was ist nicht betroffen? | VPN nach Neustart |
| Wo tritt es auf? | Windows-Notebooks |
| Wo nicht? | macOS-Geräte |
| Seit wann? | seit Client-Version 5.8 |
| Veränderung | Clientupdate am Vortag |
Diese Gegenüberstellung hilft, Hypothesen gezielt einzugrenzen.
Fehlerbaum und Abhängigkeiten
Bei komplexen Services kann eine Abhängigkeitsanalyse helfen.
Zu prüfen sind:
- Anwendungen,
- Datenbanken,
- Identitätsdienste,
- Netzwerkverbindungen,
- DNS,
- Zertifikate,
- Firewalls,
- Load Balancer,
- Storage,
- Cloud-Dienste,
- externe APIs,
- Lieferantenservices.
Beispiel:
Eine Anwendung ist nicht erreichbar.
Mögliche Abhängigkeiten:
Benutzer
↓
Netzwerk
↓
DNS
↓
Load Balancer
↓
Webserver
↓
Anwendung
↓
Datenbank
↓
Storage
Wenn mehrere Anwendungen betroffen sind, kann eine gemeinsame Abhängigkeit wahrscheinlicher sein.
Datenqualität beachten
Ursachenanalyse ist nur so gut wie die verfügbaren Daten.
Probleme entstehen durch:
- fehlende Logs,
- falsche Zeitstempel,
- unterschiedliche Zeitzonen,
- unvollständige Tickets,
- veraltete CMDB,
- fehlende Change-Dokumentation,
- unklare Serviceabhängigkeiten,
- fehlende Monitoringdaten,
- nicht dokumentierte manuelle Eingriffe.
Eine wichtige Verbesserung kann daher sein:
Die Datenbasis für zukünftige Analysen verbessern.
Korrelation und Kausalität unterscheiden
Nur weil zwei Ereignisse zeitlich zusammen auftreten, bedeutet das nicht, dass eines das andere verursacht hat.
Beispiel:
Ein Incident beginnt kurz nach einem Windows-Update.
Mögliche Schlussfolgerungen:
- Das Update ist die Ursache.
- Das Update hat nur eine bestehende Schwäche sichtbar gemacht.
- Ein anderer Change trat gleichzeitig auf.
- Der Incident wäre unabhängig davon eingetreten.
Deshalb müssen Hypothesen geprüft werden.
Hypothesen testen
Eine Hypothese sollte überprüfbar sein.
Beispiel:
Hypothese
VPN-Abbrüche entstehen durch Client-Version 5.8.
Test
- betroffene Geräteversionen vergleichen,
- nicht betroffene Geräte prüfen,
- bekannte Herstellerhinweise suchen,
- Testgerät mit älterer Version prüfen,
- kontrolliertes Update durchführen,
- Logs auswerten.
Ergebnis
Wenn nur Version 5.8 betroffen ist und ein Downgrade den Fehler beseitigt, wird die Hypothese stärker.
Trotzdem muss geprüft werden, ob weitere Faktoren beteiligt sind.
Kontrollierte Tests
Tests sollten möglichst kontrolliert durchgeführt werden.
Wichtig:
- nicht mehrere Änderungen gleichzeitig,
- Testumgebung nutzen, wenn möglich,
- Risiko bewerten,
- Messwerte vorher und nachher vergleichen,
- Ergebnisse dokumentieren,
- Rollback planen,
- Change-Vorgaben beachten.
Ungeeignet:
Wir ändern DNS, Firewall, Zertifikat und Clientversion gleichzeitig.
Besser:
Wir testen zuerst die Clientversion auf einem betroffenen Gerät und dokumentieren das Ergebnis.
RCA bei Major Incidents
Nach Major Incidents ist eine Ursachenanalyse besonders wichtig.
Zu betrachten sind nicht nur technische Ursachen.
Auch zu prüfen:
- Wurde der Incident rechtzeitig erkannt?
- Waren die Alarme verständlich?
- Wurde richtig priorisiert?
- War Ownership klar?
- Wurde rechtzeitig eskaliert?
- War Kommunikation ausreichend?
- Gab es einen Workaround?
- Waren Abhängigkeiten bekannt?
- Waren Lieferanten erreichbar?
- Wurde der Service stabil wiederhergestellt?
Ein Major Incident Review sollte nicht nur fragen:
Warum ist das System ausgefallen?
Sondern auch:
Warum waren die Auswirkungen so groß?
Technische Ursachen
Mögliche technische Ursachen:
- Softwarefehler,
- Hardwaredefekt,
- fehlerhafte Konfiguration,
- abgelaufenes Zertifikat,
- Netzwerkausfall,
- DNS-Fehler,
- Speicher voll,
- Datenbankproblem,
- fehlgeschlagenes Backup,
- Überlastung,
- falsche Berechtigungen,
- inkompatible Versionen.
Technische Ursachen sind oft sichtbar.
Sie sind aber nicht immer die tiefste Ursache.
Prozessuale Ursachen
Mögliche prozessuale Ursachen:
- Change wurde nicht ausreichend geprüft,
- Monitoring wurde nicht aktualisiert,
- Dokumentation war veraltet,
- Genehmigungsweg war unklar,
- Eskalationsweg fehlte,
- Runbook war unvollständig,
- Backup-Wiederherstellung wurde nie getestet,
- Serviceübergabe war unvollständig,
- Verantwortlichkeit war nicht festgelegt.
Prozessuale Ursachen erklären häufig, warum ein technischer Fehler nicht verhindert oder früher erkannt wurde.
Organisatorische Ursachen
Mögliche organisatorische Ursachen:
- unklare Ownership,
- fehlende Ressourcen,
- fehlende Schulung,
- unklare Prioritäten,
- fehlende Abstimmung zwischen Teams,
- ungeeignete Lieferantensteuerung,
- fehlende Vertretung,
- Silodenken,
- unklare Entscheidungskompetenz.
Diese Ursachen sind oft unangenehm, aber wichtig.
Wenn sie ignoriert werden, treten ähnliche Probleme wieder auf.
Menschliche Faktoren
Menschen machen Fehler.
Gute Ursachenanalyse fragt deshalb nicht nur:
Warum hat jemand falsch gehandelt?
Sondern:
Warum war dieser Fehler möglich oder wahrscheinlich?
Zu prüfen sind:
- unklare Oberfläche,
- fehlende Warnung,
- Zeitdruck,
- unvollständige Anleitung,
- fehlende Schulung,
- zu viele manuelle Schritte,
- ungünstige Berechtigungen,
- fehlende Prüfung,
- widersprüchliche Informationen.
Ziel ist, Systeme und Prozesse robuster zu machen.
Beitragende Faktoren dokumentieren
Nicht jede Ursache ist allein verantwortlich.
Beispiel:
Ein Datenbankserver fällt aus.
Beitragende Faktoren:
- Speicherplatz war knapp.
- Monitoringgrenze war zu hoch gesetzt.
- Alarm ging an falschen Verteiler.
- Bereinigungsskript war deaktiviert.
- Dokumentation war veraltet.
- Bereitschaft war nicht informiert.
Die Kombination führte zur Störung.
Deshalb sollten mehrere Faktoren dokumentiert werden.
Maßnahmen ableiten
Aus der Ursachenanalyse sollten konkrete Maßnahmen entstehen.
Gute Maßnahmen sind:
- eindeutig beschrieben,
- einer verantwortlichen Person oder Gruppe zugewiesen,
- terminiert,
- risikobewertet,
- überprüfbar,
- und nachverfolgbar.
Beispiele:
| Ursache | Maßnahme |
|---|---|
| Zertifikatsablauf wurde nicht überwacht | Monitoring für Zertifikatsgültigkeit einführen |
| Logrotation war fehlerhaft | Konfiguration korrigieren und Test ergänzen |
| Workaround war unbekannt | Knowledge-Artikel erstellen |
| Eskalation erfolgte zu spät | Eskalationskriterien überarbeiten |
| Serviceabhängigkeit war unbekannt | CMDB-Beziehung ergänzen |
| Lieferant reagierte zu langsam | Lieferanteneskalationsweg prüfen |
Maßnahmen priorisieren
Nicht jede Maßnahme kann sofort umgesetzt werden.
Zu bewerten sind:
- Nutzen,
- Aufwand,
- Risiko,
- Kosten,
- Sicherheitsrelevanz,
- Häufigkeit des Problems,
- Kritikalität des betroffenen Service,
- Verfügbarkeit eines Workarounds,
- Abhängigkeit von Lieferanten,
- notwendige Changes.
Eine Maßnahme mit hoher Risikoreduktion kann wichtiger sein als eine einfache technische Optimierung.
Wirksamkeit prüfen
Nach Umsetzung einer Maßnahme sollte geprüft werden:
- Tritt der Incident erneut auf?
- Sind ähnliche Incidents zurückgegangen?
- Funktioniert der Workaround?
- Hat Monitoring früher gewarnt?
- Sind Tickets vollständiger?
- Wurde die Eskalation schneller?
- Hat sich die Benutzererfahrung verbessert?
- Gab es neue Nebenwirkungen?
Ursachenanalyse ist erst dann wirklich abgeschlossen, wenn die Verbesserung überprüft wurde oder ein verbleibendes Risiko bewusst akzeptiert ist.
RCA-Ergebnis dokumentieren
Eine Abschlussdokumentation kann enthalten:
- Problemzusammenfassung,
- betroffene Services,
- Zeitraum,
- Auswirkungen,
- zugehörige Incidents,
- erkannte Ursachen,
- beitragende Faktoren,
- durchgeführte Tests,
- bestätigter Workaround,
- dauerhafte Lösung,
- offene Risiken,
- Maßnahmen,
- Verantwortliche,
- Lessons Learned,
- benötigte Changes,
- aktualisierte Knowledge-Artikel.
Die Dokumentation muss nicht übermäßig lang sein.
Sie muss nachvollziehbar und nützlich sein.
Praxisbeispiel: Zertifikat abgelaufen
Incident
Benutzer können sich nicht an einer Anwendung anmelden.
Direkte Ursache
Das Zertifikat des Anmeldedienstes ist abgelaufen.
Grundursache
Es gab keinen Prozess zur rechtzeitigen Zertifikatserneuerung.
Beitragende Faktoren
- kein Monitoring auf Zertifikatsablauf,
- keine verantwortliche Rolle,
- keine Erinnerungsfristen,
- keine Dokumentation im Betriebshandbuch.
Maßnahmen
- Zertifikatsmonitoring einführen,
- Owner festlegen,
- Ablaufdatum in Wartungskalender aufnehmen,
- Runbook zur Erneuerung erstellen,
- Knowledge-Artikel für Symptome aktualisieren.
Praxisbeispiel: Speicher läuft voll
Incident
Ein Dateiserver ist nicht mehr beschreibbar.
Workaround
Temporäre Dateien werden kontrolliert entfernt.
Ursachenanalyse
- Logdateien wachsen ungewöhnlich stark.
- Logrotation greift nicht.
- Monitoring warnt erst bei 98 Prozent.
- Verantwortlicher erhält keine Benachrichtigung.
Maßnahmen
- Logrotation korrigieren,
- Monitoringgrenzen anpassen,
- Alarmempfänger aktualisieren,
- Kapazitätsbericht ergänzen,
- Runbook für Speicherwarnungen erstellen.
Praxisbeispiel: Wiederkehrende VPN-Abbrüche
Problem
Mehrere Benutzer verlieren nach dem Ruhezustand die VPN-Verbindung.
Fakten
- nur Windows-Notebooks betroffen,
- nur Client-Version 5.8 betroffen,
- Fehler tritt nach Ruhezustand auf,
- Neustart des Clients hilft kurzfristig,
- Hersteller bestätigt bekannten Fehler.
Known Error
Client-Version 5.8 verursacht nach Ruhezustand fehlerhafte Tunnelzustände.
Workaround
VPN-Client vollständig beenden und neu starten.
Dauerhafte Lösung
Test und Ausrollen einer korrigierten Client-Version über Change Enablement.
Typische Fehler
Fehler 1
Symptom wird als Grundursache dokumentiert.
Fehler 2
Die erste Vermutung wird nicht mehr überprüft.
Fehler 3
Nur technische Ursachen werden betrachtet.
Fehler 4
Organisatorische und prozessuale Faktoren werden ignoriert.
Fehler 5
Zeitlicher Zusammenhang wird als Beweis behandelt.
Fehler 6
Mehrere Änderungen werden gleichzeitig getestet.
Fehler 7
RCA wird zur Schuldzuweisung verwendet.
Fehler 8
Workaround wird nicht dokumentiert.
Fehler 9
Maßnahmen werden beschlossen, aber nicht verfolgt.
Fehler 10
Lessons Learned werden nicht in Knowledge, Monitoring oder Prozesse übernommen.
Fehler 11
CMDB- und Serviceabhängigkeiten werden nicht genutzt.
Fehler 12
Wirksamkeit der Maßnahmen wird nicht geprüft.
Checkliste Ursachenanalyse starten
- Problem eindeutig beschrieben
- betroffene Services bekannt
- zugehörige Incidents verknüpft
- Auswirkungen dokumentiert
- Zeitlinie begonnen
- relevante Changes geprüft
- Monitoringdaten gesichert
- Logs gesichert
- Workaround bekannt oder gesucht
- Verantwortlicher für Analyse benannt
Checkliste Ursachen untersuchen
- Symptome von Ursachen getrennt
- Hypothesen dokumentiert
- Hypothesen überprüfbar formuliert
- Fakten und Vermutungen getrennt
- Umfang geprüft
- betroffene und nicht betroffene Bereiche verglichen
- technische Ursachen geprüft
- Prozessursachen geprüft
- organisatorische Faktoren geprüft
- menschliche Faktoren berücksichtigt
- beitragende Faktoren dokumentiert
Checkliste Maßnahmen ableiten
- Workaround dokumentiert
- Known Error bewertet
- dauerhafte Lösung beschrieben
- notwendiger Change geprüft
- Risiken bewertet
- Maßnahmen priorisiert
- Verantwortliche benannt
- Termine festgelegt
- Knowledge-Artikel aktualisiert
- Monitoring oder Runbook angepasst
- Wirksamkeitsprüfung geplant
Bedeutung für Fachinformatiker für Systemintegration
Für Fachinformatiker ist Ursachenanalyse eine zentrale Fähigkeit.
Im Arbeitsalltag bedeutet das:
- nicht bei der ersten Vermutung stehen bleiben,
- technische Beobachtungen sauber dokumentieren,
- Logs und Messwerte sinnvoll auswerten,
- Änderungen und Abhängigkeiten prüfen,
- wiederkehrende Muster erkennen,
- Workarounds nutzbar dokumentieren,
- Risiken einschätzen,
- und Verbesserungen anstoßen.
Gute Ursachenanalyse macht Systeme nicht nur wieder lauffähig.
Sie macht sie langfristig stabiler.
Zusammenfassung
Symptom erkennen
↓
Problem beschreiben
↓
Fakten sammeln
↓
Zeitlinie und Umfang prüfen
↓
Hypothesen bilden
↓
Hypothesen testen
↓
technische, prozessuale und organisatorische Ursachen betrachten
↓
Workaround und Known Error dokumentieren
↓
dauerhafte Maßnahmen ableiten
↓
Wirksamkeit prüfen
↓
Wissen und Verbesserungen übernehmen
Merksätze
Die erste Erklärung ist nicht immer die richtige Ursache.
Ein Symptom ist noch keine Grundursache.
Ursachenanalyse ist Lernen, nicht Schuldzuweisung.
Viele IT-Probleme haben technische und organisatorische Ursachen.
Workarounds helfen kurzfristig, ersetzen aber keine dauerhafte Lösung.
Eine RCA ist nur wertvoll, wenn daraus konkrete Verbesserungen entstehen.
Verwandte Seiten
- 4.1 Problem Management – Ziele, Begriffe und Abgrenzung
- 4.3 Workarounds und Known Errors
- 4.4 Trendanalyse und proaktives Problem Management
- 4.5 Problem Management im Zusammenspiel mit Incident, Change und Knowledge Management
- Incident 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:
- RCA-Methoden,
- 5-Why-Beispiele,
- Ishikawa-Kategorien,
- Pareto-Beispiele,
- Checklisten,
- Ursachenarten,
- und Praxisbeispiele
sind herstellerneutrale Praxisempfehlungen.
ITIL schreibt keine universelle:
- RCA-Methode,
- Anzahl von Analysefragen,
- Diagrammform,
- Review-Struktur,
- Maßnahmenmatrix,
- oder konkrete Dokumentationsvorlage
für alle Organisationen vor.
Die konkrete Umsetzung muss an:
- Services,
- Risiken,
- technische Umgebung,
- Datenqualität,
- Organisation,
- Lieferanten,
- Service Levels,
- Sicherheitsanforderungen,
- 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
4.3 Workarounds und Known Errors
Kurz erklärt
Ein Workaround ist eine vorübergehende Möglichkeit, die Auswirkungen eines Incidents oder Problems zu umgehen oder zu reduzieren.
Ein Known Error ist ein bekanntes Problem oder ein bekannter Fehlerzustand, bei dem Ursache, Zusammenhang oder Fehlerbild ausreichend verstanden sind.
Workarounds und Known Errors helfen dabei, Incidents schneller zu bearbeiten, Benutzer arbeitsfähig zu halten und Wissen für den Service Desk nutzbar zu machen.
Warum Workarounds wichtig sind
Nicht jede Ursache kann sofort dauerhaft beseitigt werden.
Gründe können sein:
- dauerhafte Lösung benötigt einen Change,
- Hersteller muss Fehler beheben,
- Wartungsfenster ist erforderlich,
- Risiko einer Sofortänderung ist zu hoch,
- Ursache ist noch nicht vollständig verstanden,
- Ersatzhardware ist nicht sofort verfügbar,
- Freigaben fehlen,
- oder eine technische Abhängigkeit muss zuerst geklärt werden.
Ein Workaround kann in solchen Situationen helfen, die Auswirkungen zu begrenzen.
Beispiele:
- alternativer Drucker,
- Webversion statt Desktop-Anwendung,
- Neustart eines betroffenen Dienstes,
- anderer Netzwerkzugang,
- manuelle Ersatzbearbeitung,
- temporäre Umleitung,
- Nutzung eines Ersatzsystems.
Ein Workaround ist nicht automatisch schlecht.
Er wird problematisch, wenn er dauerhaft genutzt wird und die eigentliche Ursache nie bearbeitet wird.
Workaround und dauerhafte Lösung unterscheiden
| Workaround | Dauerhafte Lösung |
|---|---|
| reduziert oder umgeht Auswirkungen | beseitigt Ursache oder Risiko nachhaltig |
| oft kurzfristig verfügbar | benötigt häufig Analyse, Planung oder Change |
| kann Service schnell wieder nutzbar machen | verhindert Wiederholung besser |
| Ursache kann bestehen bleiben | Ursache wird behoben oder kontrolliert |
| muss dokumentiert und überwacht werden | muss getestet und dauerhaft übernommen werden |
Beispiel:
Ein VPN-Client verliert nach dem Ruhezustand die Verbindung.
Workaround
VPN-Client vollständig beenden und neu starten.
Dauerhafte Lösung
Fehlerhafte Client-Version aktualisieren oder Konfiguration korrigieren.
Was ist ein Known Error?
Ein Known Error ist ein Problem oder Fehlerzustand, der bekannt und ausreichend beschrieben ist.
Typische Merkmale:
- Fehlerbild ist bekannt,
- betroffene Services oder Komponenten sind bekannt,
- Ursache oder wahrscheinliche Ursache ist dokumentiert,
- Auswirkungen sind beschrieben,
- Workaround ist vorhanden oder geprüft,
- dauerhafte Lösung ist geplant, offen oder bewusst zurückgestellt.
Ein Known Error muss nicht bedeuten, dass bereits eine endgültige Lösung vorhanden ist.
Gerade deshalb ist die Dokumentation wichtig.
Problem, Known Error, Workaround und Lösung unterscheiden
| Begriff | Bedeutung |
|---|---|
| Problem | Ursache oder mögliche Ursache eines oder mehrerer Incidents |
| Known Error | bekanntes Problem oder bekannter Fehlerzustand mit dokumentiertem Wissen |
| Workaround | vorübergehende Maßnahme zur Umgehung oder Reduzierung der Auswirkungen |
| dauerhafte Lösung | Maßnahme zur Beseitigung der Ursache oder dauerhaften Risikoreduzierung |
Beispiel:
Problem
Mehrere Benutzer verlieren regelmäßig die VPN-Verbindung.
Known Error
VPN-Client-Version 5.8 verursacht nach dem Ruhezustand fehlerhafte Tunnelzustände.
Workaround
VPN-Client vollständig beenden und neu starten.
Dauerhafte Lösung
Getestete Client-Version 5.9 über Change Enablement ausrollen.
Ein Workaround ist keine endgültige Lösung
Ein häufiger Fehler besteht darin, einen erfolgreichen Workaround als vollständige Lösung zu behandeln.
Beispiel:
Ein Dienst stürzt regelmäßig ab.
Der Service Desk startet den Dienst jedes Mal neu.
Dadurch ist der Service kurzfristig wieder verfügbar.
Die Ursache bleibt jedoch bestehen.
Mögliche offene Fragen:
- Warum stürzt der Dienst ab?
- Warum erkennt Monitoring den Fehler nicht früher?
- Warum gibt es keinen automatischen Neustart?
- Warum wurde die Ursache nicht untersucht?
- Warum tritt der Fehler regelmäßig auf?
Merke
Ein Workaround kann einen Incident lösen.
Er löst aber nicht automatisch das zugrunde liegende Problem.
Anforderungen an einen guten Workaround
Ein guter Workaround sollte:
- wirksam sein,
- verständlich beschrieben sein,
- reproduzierbar funktionieren,
- sicher sein,
- zulässig sein,
- keine größeren Folgerisiken erzeugen,
- für die Zielgruppe geeignet sein,
- dokumentiert sein,
- und regelmäßig überprüft werden.
Zu prüfen ist außerdem:
- Für welche Versionen gilt der Workaround?
- Für welche Benutzer oder Services gilt er?
- Welche Voraussetzungen bestehen?
- Welche Einschränkungen bleiben?
- Wie lange darf er genutzt werden?
- Wann muss eskaliert werden?
- Muss später eine Rücknahme erfolgen?
Ungeeignete Workarounds
Ein Workaround ist ungeeignet, wenn er:
- Sicherheitsvorgaben umgeht,
- Datenschutz verletzt,
- Datenverlust riskieren kann,
- unkontrollierte Änderungen verursacht,
- nur zufällig funktioniert,
- nicht dokumentiert ist,
- Benutzer überfordert,
- oder die Ursache verschlimmern kann.
Beispiel:
Benutzer sollen vertrauliche Dokumente über private E-Mail-Konten austauschen, weil der Dateiserver nicht erreichbar ist.
Das wäre technisch vielleicht möglich, aber organisatorisch und sicherheitlich ungeeignet.
Workaround dokumentieren
Ein Workaround sollte so dokumentiert sein, dass er wiederverwendbar ist.
Typische Inhalte:
- Titel,
- betroffener Service,
- Fehlerbild,
- Voraussetzungen,
- betroffene Versionen oder Komponenten,
- genaue Arbeitsschritte,
- erwartetes Ergebnis,
- Einschränkungen,
- Risiken,
- Abbruchkriterien,
- Eskalationshinweise,
- Gültigkeitsdauer,
- Verantwortlicher,
- Bezug zu Problem Record oder Known Error.
Eine ungenaue Notiz reicht nicht aus.
Ungeeignet:
Client neu starten.
Besser:
VPN-Client vollständig beenden, prüfen ob der Prozess beendet ist, Client neu starten und erneut verbinden. Gilt nur für Windows-Notebooks mit Client-Version 5.8 nach Ruhezustand. Wenn Verbindung weiterhin fehlschlägt, an Netzwerkteam eskalieren.
Known Error dokumentieren
Ein Known Error sollte mindestens enthalten:
- bekannte Symptome,
- betroffener Service,
- betroffene Configuration Items,
- betroffene Versionen,
- Ursache oder wahrscheinliche Ursache,
- Auswirkungen,
- Workaround,
- bekannte Einschränkungen,
- dauerhafte Lösung oder geplanter Change,
- Status,
- Verantwortlicher,
- Verknüpfung zu Incidents und Problems,
- Datum der letzten Prüfung.
Ziel ist, dass Service Desk und Fachgruppen schneller erkennen:
- ob ein neuer Incident zu einem bekannten Fehler passt,
- welcher Workaround genutzt werden kann,
- wann eskaliert werden muss,
- und ob eine dauerhafte Lösung geplant ist.
Known Error Database
Organisationen können bekannte Fehler in einer Known Error Database oder in einem vergleichbaren Wissenssystem dokumentieren.
Das Werkzeug ist nicht entscheidend.
Möglich sind beispielsweise:
- ITSM-System,
- Knowledge Base,
- Wiki,
- CMDB-Verknüpfung,
- Problem-Management-Modul,
- Runbook-Sammlung.
Wichtig ist:
- Informationen sind auffindbar,
- Inhalte sind aktuell,
- Zielgruppen sind klar,
- Verknüpfungen zu Incidents und Problems sind vorhanden,
- und Workarounds sind verständlich beschrieben.
Lebenszyklus eines Known Errors
Ein möglicher Ablauf:
wiederkehrender Incident erkannt
↓
Problem Record erstellt
↓
Ursache oder Fehlerzustand analysiert
↓
Known Error dokumentiert
↓
Workaround bereitgestellt
↓
dauerhafte Lösung geplant
↓
Change umgesetzt
↓
Wirksamkeit geprüft
↓
Known Error aktualisiert oder geschlossen
Nicht jeder Known Error folgt exakt diesem Ablauf.
Entscheidend ist, dass der Status nachvollziehbar bleibt.
Known Error offen lassen oder schließen
Ein Known Error sollte nicht einfach vergessen werden.
Mögliche Status:
- neu,
- in Analyse,
- Workaround verfügbar,
- dauerhafte Lösung geplant,
- Change in Vorbereitung,
- Lösung umgesetzt,
- Wirksamkeit wird geprüft,
- geschlossen,
- Risiko akzeptiert.
Ein Known Error kann offen bleiben, wenn:
- dauerhafte Lösung noch nicht verfügbar ist,
- Herstellerkorrektur aussteht,
- Änderung zu riskant wäre,
- Kosten unverhältnismäßig wären,
- oder Risiko bewusst akzeptiert wurde.
Dann müssen Workaround und Risiko weiterhin bekannt bleiben.
Workaround im Incident Management
Incident Management nutzt Workarounds, um den Service schnell wiederherzustellen.
Beispiele:
- Service Desk nutzt Known Error und Workaround,
- Benutzer erhält eine sichere Zwischenlösung,
- Incident wird mit Bezug zum Known Error dokumentiert,
- Problem Management verfolgt die Ursache weiter.
Wichtig:
Der Incident kann abgeschlossen werden, wenn der Benutzer wieder arbeitsfähig ist und die Organisation dies so definiert.
Das Problem kann trotzdem offen bleiben.
Workaround im Problem Management
Problem Management verwendet Workarounds, um Auswirkungen zu reduzieren, während die Ursache weiter untersucht wird.
Aufgaben:
- Workaround prüfen,
- Risiken bewerten,
- Dokumentation erstellen,
- Service Desk informieren,
- Known Error anlegen,
- dauerhafte Lösung vorbereiten,
- Change-Bedarf klären,
- Wirksamkeit überwachen.
Ein Workaround ist oft ein wichtiger Zwischenschritt zwischen Analyse und dauerhafter Lösung.
Workaround und Change Enablement
Ein Workaround kann selbst eine Änderung enthalten.
Beispiele:
- DNS-Eintrag temporär ändern,
- Dienst auf Ersatzsystem umleiten,
- Firewall-Regel vorübergehend anpassen,
- Konfiguration zurücksetzen,
- Zertifikat austauschen,
- Softwareversion zurückrollen.
Solche Maßnahmen müssen nach Risiko bewertet werden.
Nicht jeder Workaround darf ohne Change-Steuerung durchgeführt werden.
Die Organisation muss festlegen, welche Workarounds:
- als Standardmaßnahme erlaubt sind,
- eine Genehmigung benötigen,
- nur im Notfall zulässig sind,
- oder über einen Emergency Change laufen müssen.
Workaround und Knowledge Management
Workarounds sind nur dann wertvoll, wenn sie gefunden und verstanden werden.
Deshalb sollten sie in Knowledge Management eingebunden werden.
Zu klären ist:
- Wer darf den Artikel sehen?
- Ist der Artikel für Benutzer oder nur für IT?
- Welche Begriffe nutzen Benutzer bei der Suche?
- Muss es eine Kurzversion für den Service Desk geben?
- Gibt es Sicherheits- oder Datenschutzhinweise?
- Wann wird der Artikel überprüft?
- Wer ist für Aktualisierung verantwortlich?
Ein Workaround, der nur in einem alten Ticket steht, hilft beim nächsten Incident kaum.
Workaround und Service Desk
Der Service Desk benötigt klare Informationen:
- Wann passt dieser Workaround?
- Wann passt er nicht?
- Welche Fragen müssen gestellt werden?
- Welche Schritte sind erlaubt?
- Welche Risiken bestehen?
- Wann muss eskaliert werden?
- Wie wird der Incident dokumentiert?
- Welche Benutzerinformation ist freigegeben?
Beispiel:
Wenn Benutzer nach Ruhezustand keine VPN-Verbindung herstellen können und Client-Version 5.8 verwendet wird, Workaround aus Artikel KB-023 anwenden. Bei anderer Version oder Fehlermeldung an Netzwerkteam eskalieren.
Workaround und Benutzerkommunikation
Benutzer sollten verständlich informiert werden.
Wichtig ist:
- klar sagen, dass es eine Zwischenlösung ist,
- keine unsicheren technischen Vermutungen als Ursache darstellen,
- Einschränkungen nennen,
- nächsten Schritt erklären,
- bei Bedarf Statusmeldung ankündigen.
Beispiel:
Für diesen Fehler gibt es aktuell eine sichere Zwischenlösung. Bitte starten Sie den VPN-Client vollständig neu und verbinden Sie sich anschließend erneut. Die Ursache wird weiter untersucht. Eine dauerhafte Korrektur ist in Vorbereitung.
Ungeeignet:
Das ist ein bekannter Bug, machen Sie einfach Neustart.
Risiken dauerhaft genutzter Workarounds
Wenn Workarounds dauerhaft genutzt werden, entstehen Risiken:
- Ursache bleibt bestehen,
- Benutzer gewöhnen sich an Umwege,
- manuelle Fehler nehmen zu,
- Supportaufwand bleibt hoch,
- Sicherheitsrisiken werden akzeptiert,
- technische Schulden wachsen,
- und echte Verbesserungen werden verschoben.
Ein Workaround sollte deshalb regelmäßig überprüft werden.
Fragen:
- Wird der Workaround noch gebraucht?
- Gibt es inzwischen eine dauerhafte Lösung?
- Wie oft wird er genutzt?
- Welche Risiken bestehen?
- Gibt es Beschwerden?
- Ist ein Change geplant?
- Wurde Risiko bewusst akzeptiert?
Known Error und Risikoakzeptanz
Nicht jeder Known Error wird sofort beseitigt.
Beispiel:
Ein selten auftretender Fehler betrifft eine alte Anwendung.
Der Workaround funktioniert zuverlässig.
Eine dauerhafte Lösung wäre sehr teuer und riskant.
Die Organisation kann entscheiden, das Risiko vorerst zu akzeptieren.
Dann sollte dokumentiert werden:
- wer das Risiko akzeptiert,
- warum es akzeptiert wird,
- welche Einschränkungen bestehen,
- wie lange die Akzeptanz gilt,
- wann neu bewertet wird,
- und welcher Workaround genutzt wird.
Known Error bei Lieferantenfehlern
Ein Known Error kann auch durch einen Hersteller oder Lieferanten bestätigt werden.
Beispiele:
- Software-Bug,
- Firmwarefehler,
- Cloud-Service-Problem,
- Treiberproblem,
- API-Verhalten,
- Inkompatibilität.
Zu dokumentieren ist:
- Herstellerreferenz,
- betroffene Version,
- bestätigte Symptome,
- empfohlener Workaround,
- erwartete Korrektur,
- Lieferantenticket,
- interne Auswirkungen,
- geplanter interner Umgang.
Auch wenn ein Lieferant verantwortlich ist, bleibt die interne Serviceverantwortung bestehen.
Known Error und Major Incident
Nach einem Major Incident kann ein Known Error entstehen.
Beispiel:
Ein zentraler Dienst fällt wegen einer bestimmten Datenbankversion aus.
Der Service wurde wiederhergestellt.
Die dauerhafte Korrektur benötigt aber ein geplantes Upgrade.
Bis dahin wird ein Known Error dokumentiert mit:
- Symptomen,
- betroffenen Services,
- Workaround,
- Monitoringhinweisen,
- Eskalationsregeln,
- geplanter dauerhafter Lösung.
Dadurch kann bei Wiederholung schneller reagiert werden.
Beispiel: VPN-Client
Symptom
Benutzer verlieren nach dem Ruhezustand die VPN-Verbindung.
Problem
Mehrere Incidents mit gleichem Muster.
Known Error
VPN-Client-Version 5.8 verursacht nach Ruhezustand fehlerhafte Tunnelzustände.
Workaround
Client vollständig beenden und neu starten.
Dauerhafte Lösung
Version 5.9 testen und ausrollen.
Knowledge
Service Desk erhält einen Artikel mit Prüfschritten, Workaround und Eskalationskriterien.
Beispiel: Druckerwarteschlange
Symptom
Etiketten werden nicht gedruckt.
Problem
Druckwarteschlange blockiert regelmäßig durch bestimmte PDF-Dateien.
Known Error
Der aktuell installierte Druckertreiber verarbeitet bestimmte PDF-Formate fehlerhaft.
Workaround
Fehlerhaften Auftrag entfernen und Datei über alternative Druckoption ausgeben.
Dauerhafte Lösung
Treiberupdate testen und über Change Enablement ausrollen.
Beispiel: Zertifikat
Symptom
Anmeldung an Fachanwendung schlägt fehl.
Problem
Zertifikat des Anmeldedienstes ist abgelaufen.
Known Error
Zertifikatsablauf wird nicht überwacht und kann zu Anmeldeausfällen führen.
Workaround
Kein vollwertiger Workaround verfügbar.
Dauerhafte Lösung
Zertifikat erneuern, Monitoring einführen, Owner festlegen und Runbook erstellen.
Merke
Nicht jeder Known Error besitzt einen geeigneten Workaround.
Beispiel: Speicher läuft voll
Symptom
Server kann keine neuen Daten schreiben.
Problem
Logdateien wachsen unkontrolliert.
Known Error
Logrotation ist fehlerhaft konfiguriert.
Workaround
Temporäre Bereinigung nach Runbook durchführen.
Dauerhafte Lösung
Logrotation korrigieren, Monitoring-Grenzen anpassen und Verantwortlichkeit festlegen.
Typische Fehler
Fehler 1
Workaround wird als dauerhafte Lösung behandelt.
Fehler 2
Known Error wird nicht dokumentiert.
Fehler 3
Workaround steht nur in einem einzelnen Ticket.
Fehler 4
Service Desk kennt den Workaround nicht.
Fehler 5
Benutzer erhalten unsichere oder unklare Anweisungen.
Fehler 6
Workaround umgeht Sicherheitsregeln.
Fehler 7
Risiken und Einschränkungen werden nicht genannt.
Fehler 8
Known Errors bleiben dauerhaft offen, ohne Neubewertung.
Fehler 9
Dauerhafte Lösung wird nicht geplant oder verfolgt.
Fehler 10
Lieferantenfehler werden nicht intern dokumentiert.
Fehler 11
Workaround wird nicht getestet.
Fehler 12
Nach Umsetzung der dauerhaften Lösung wird der Knowledge-Artikel nicht aktualisiert.
Checkliste Workaround erstellen
- Fehlerbild eindeutig beschrieben
- betroffener Service genannt
- Voraussetzungen dokumentiert
- genaue Schritte beschrieben
- erwartetes Ergebnis beschrieben
- Risiken bewertet
- Einschränkungen genannt
- Abbruchkriterien definiert
- Eskalationsweg beschrieben
- Zielgruppe festgelegt
- Verantwortlicher benannt
- regelmäßige Prüfung vorgesehen
Checkliste Known Error dokumentieren
- Problem oder Fehlerzustand beschrieben
- betroffene Services und Komponenten genannt
- bekannte Symptome dokumentiert
- Ursache oder wahrscheinliche Ursache beschrieben
- Auswirkungen bewertet
- zugehörige Incidents verknüpft
- Workaround vorhanden oder als nicht verfügbar gekennzeichnet
- dauerhafte Lösung oder nächster Schritt dokumentiert
- Status festgelegt
- Verantwortlicher benannt
- Knowledge-Artikel oder Runbook verknüpft
- Datum der nächsten Überprüfung festgelegt
Checkliste Workaround im Betrieb nutzen
- passt das aktuelle Symptom zum Known Error?
- sind Version, Service oder Komponente betroffen?
- ist der Workaround für diesen Fall zulässig?
- wurden Risiken geprüft?
- wurde der Benutzer verständlich informiert?
- wurde die Anwendung dokumentiert?
- muss funktional eskaliert werden?
- muss Problem Management informiert werden?
- ist eine dauerhafte Lösung geplant?
- wurde die Wirksamkeit bestätigt?
Checkliste Known Error schließen
- dauerhafte Lösung umgesetzt
- Wirksamkeit geprüft
- zugehörige Incidents berücksichtigt
- Knowledge-Artikel aktualisiert
- Workaround entfernt oder angepasst
- Monitoring oder Runbook aktualisiert
- Rest Risiko bewertet
- Stakeholder informiert
- Problem Record aktualisiert
- Lessons Learned dokumentiert
Bedeutung für Fachinformatiker für Systemintegration
Für Fachinformatiker ist der saubere Umgang mit Workarounds und Known Errors besonders wichtig.
Im Arbeitsalltag bedeutet das:
- wiederkehrende Fehler erkennen,
- wirksame Zwischenlösungen sauber dokumentieren,
- Risiken eines Workarounds bewerten,
- bekannte Fehler für den Service Desk nutzbar machen,
- dauerhafte Lösungen vorbereiten,
- Changes fachlich unterstützen,
- und Knowledge-Artikel aktuell halten.
Ein guter Workaround spart Zeit.
Ein gut dokumentierter Known Error verhindert doppelte Analyse.
Eine dauerhafte Lösung verbessert den Service nachhaltig.
Zusammenfassung
Incident oder wiederkehrendes Fehlerbild erkennen
↓
Problem oder mögliche Ursache untersuchen
↓
Known Error dokumentieren
↓
sicheren Workaround bereitstellen
↓
Service Desk und Benutzer angemessen informieren
↓
dauerhafte Lösung planen
↓
Change bei Bedarf durchführen
↓
Wirksamkeit prüfen
↓
Known Error und Knowledge aktualisieren oder schließen
Merksätze
Ein Workaround ist hilfreich, aber nicht automatisch eine Lösung.
Ein Known Error muss auffindbar und verständlich dokumentiert sein.
Nicht jeder Known Error besitzt einen sicheren Workaround.
Workarounds dürfen Sicherheitsregeln nicht aushebeln.
Dauerhaft genutzte Workarounds sind ein Hinweis auf ungelöste Probleme.
Gute Known-Error-Dokumentation macht zukünftige Incidents schneller lösbar.
Verwandte Seiten
- 4.1 Problem Management – Ziele, Begriffe und Abgrenzung
- 4.2 Ursachenanalyse
- 4.4 Trendanalyse und proaktives Problem Management
- 4.5 Problem Management im Zusammenspiel mit Incident, Change und Knowledge Management
- 3.6 Erstdiagnose, Lösung und funktionale Eskalation
- Knowledge Management
- Change Enablement
- 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
- ITIL Foundation – Version 5
Einordnung
Die dargestellten:
- Workaround-Beispiele,
- Known-Error-Strukturen,
- Checklisten,
- Statusmodelle,
- Dokumentationshinweise,
- und Praxisbeispiele
sind herstellerneutrale Praxisempfehlungen.
ITIL schreibt keine universelle:
- Known-Error-Datenbank-Struktur,
- Workaround-Vorlage,
- Statusliste,
- Dokumentationstiefe,
- Freigaberegel,
- oder Toolauswahl
für alle Organisationen vor.
Die konkrete Umsetzung muss an:
- Services,
- Risiken,
- Sicherheitsanforderungen,
- Supportmodell,
- Knowledge Management,
- Change Enablement,
- Lieferanten,
- und organisatorische Verantwortlichkeiten
angepasst werden.
Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance
Fachlicher Stand: August 2026
4.4 Trendanalyse und proaktives Problem Management
Kurz erklärt
Trendanalyse und proaktives Problem Management helfen dabei, wiederkehrende Muster frühzeitig zu erkennen.
Ziel ist es, Problems nicht erst nach großen Störungen zu bearbeiten, sondern mögliche Ursachen und Risiken bereits vorher sichtbar zu machen.
Dadurch können Incidents reduziert, Auswirkungen begrenzt und Services langfristig stabiler betrieben werden.
Warum Trendanalyse wichtig ist
Ein einzelner Incident wirkt oft wie ein isolierter Fehler.
Erst durch die Betrachtung vieler Vorgänge wird sichtbar, ob ein Muster besteht.
Beispiele:
- VPN-Störungen nehmen jede Woche zu.
- Druckerprobleme treten immer am gleichen Standort auf.
- Anmeldefehler häufen sich nach Passwortänderungen.
- Speicherwarnungen treten regelmäßig vor Monatsende auf.
- Eine Anwendung wird nach jedem Update instabil.
- Ein bestimmter Service erzeugt überdurchschnittlich viele Tickets.
Trendanalyse hilft dabei, solche Muster zu erkennen und daraus Verbesserungen abzuleiten.
Reaktives und proaktives Problem Management unterscheiden
| Reaktives Problem Management | Proaktives Problem Management |
|---|---|
| beginnt nach Incidents | sucht nach Risiken und Mustern vor größeren Incidents |
| reagiert auf Störungen | verhindert oder reduziert zukünftige Störungen |
| nutzt Incident-Daten nach einem Ereignis | nutzt Trends, Monitoring, Reviews und Erfahrungswerte |
| häufig nach Major Incidents | häufig durch regelmäßige Analyse |
| Ziel: Ursache verstehen | Ziel: Risiken frühzeitig erkennen |
Beide Formen sind wichtig.
Reaktives Problem Management lernt aus bereits eingetretenen Incidents.
Proaktives Problem Management versucht, zukünftige Incidents zu vermeiden.
Was ist eine Trendanalyse?
Trendanalyse bedeutet, Daten über einen Zeitraum zu betrachten und Muster zu erkennen.
Mögliche Fragen:
- Welche Incidents treten besonders häufig auf?
- Welche Services sind überdurchschnittlich betroffen?
- Welche Standorte melden ähnliche Probleme?
- Welche Zeiträume sind auffällig?
- Welche Changes stehen zeitlich mit Incidents in Verbindung?
- Welche Kategorien wachsen stark an?
- Welche Workarounds werden häufig genutzt?
- Welche Teams erhalten besonders viele Eskalationen?
- Welche Fehler kehren trotz Lösung wieder?
Eine Trendanalyse betrachtet nicht nur einzelne Tickets, sondern Zusammenhänge.
Mögliche Datenquellen
Geeignete Quellen für Trendanalysen:
- Incident Records,
- Problem Records,
- Known Errors,
- Change Records,
- Monitoringdaten,
- Logdaten,
- Service-Desk-Kontakte,
- Benutzerfeedback,
- SLA-Berichte,
- Major-Incident-Reviews,
- Service Reviews,
- Knowledge-Base-Nutzung,
- Self-Service-Daten,
- CMDB-Informationen,
- Lieferantenberichte,
- Sicherheitsmeldungen.
Je besser die Datenqualität, desto aussagekräftiger die Analyse.
Typische Muster
| Muster | Mögliche Bedeutung |
|---|---|
| viele gleiche Incidents | wiederkehrendes Problem |
| steigende Ticketzahlen | wachsendes Risiko oder schlechter Service |
| gleiche Symptome nach Changes | mögliche Change-Ursache |
| hohe Wiedereröffnungsquote | unvollständige Lösung |
| viele Eskalationen an ein Team | fehlendes Wissen im Service Desk |
| häufige Workarounds | dauerhafte Ursache nicht beseitigt |
| viele Suchanfragen ohne Treffer | fehlende Knowledge-Artikel |
| häufige Störung an einem Standort | lokales Infrastrukturproblem |
| wiederkehrende Speicherwarnungen | Kapazitäts- oder Monitoringproblem |
Trendanalyse im Service Desk
Der Service Desk ist eine besonders wichtige Quelle für Trends.
Dort entstehen täglich Informationen über:
- häufige Benutzerprobleme,
- unklare Services,
- wiederkehrende Fehler,
- schlechte Formulare,
- unverständliche Knowledge-Artikel,
- fehlende Standardlösungen,
- unklare Zuständigkeiten,
- und wiederholte Eskalationen.
Wenn diese Informationen nur in einzelnen Tickets bleiben, gehen wichtige Verbesserungsmöglichkeiten verloren.
Zeitliche Muster erkennen
Incidents können sich zeitlich häufen.
Beispiele:
- viele Anmeldeprobleme am Montagmorgen,
- Druckerprobleme zum Schichtbeginn,
- Performance-Probleme am Monatsende,
- Speicherwarnungen nach nächtlichen Jobs,
- Backupfehler nach Wartungsfenstern,
- erhöhte Ticketzahlen nach Updates.
Solche Muster helfen bei der Ursachenfindung.
Beispiel:
Wenn ein Speicherbereich jeden Montagmorgen voll ist, kann ein Wochenendjob oder eine fehlende Bereinigung beteiligt sein.
Servicebezogene Muster erkennen
Zu prüfen ist:
- Welche Services erzeugen die meisten Incidents?
- Welche Services verursachen die längsten Ausfälle?
- Welche Services haben die meisten Wiedereröffnungen?
- Welche Services benötigen häufig Eskalation?
- Welche Services haben viele Benutzerbeschwerden?
- Welche Services besitzen viele Known Errors?
Ein Service mit wenigen, aber sehr kritischen Incidents kann wichtiger sein als ein Service mit vielen kleinen Standardanfragen.
Standortbezogene Muster erkennen
Standortbezogene Trends können Hinweise liefern auf:
- Netzwerkprobleme,
- WLAN-Abdeckung,
- lokale Druckinfrastruktur,
- defekte Hardware,
- unzureichende Schulung,
- lokale Prozesse,
- Providerprobleme,
- oder Standortbesonderheiten.
Beispiel:
Wenn nur ein Standort häufig VPN-Abbrüche meldet, muss nicht der VPN-Service selbst die Hauptursache sein.
Möglicherweise liegt das Problem bei lokaler Internetanbindung, Firewall, WLAN oder Routing.
Benutzergruppen und Rollen betrachten
Manchmal treten Incidents vor allem bei bestimmten Benutzergruppen auf.
Beispiele:
- Außendienst meldet häufig VPN- und Mobilgeräteprobleme.
- Buchhaltung meldet wiederkehrende Druck- und Exportfehler.
- Lager meldet Probleme mit Scanner- oder Etikettendruck.
- neue Mitarbeiter melden viele Zugriffsprobleme.
- Führungskräfte melden häufig Kalender- und Freigabethemen.
Solche Muster können auf fehlende Schulung, unklare Prozesse oder technische Sonderanforderungen hinweisen.
Change-bezogene Muster erkennen
Viele Problems entstehen im Zusammenhang mit Änderungen.
Zu prüfen ist:
- Häufen sich Incidents nach bestimmten Changes?
- Sind bestimmte Change-Typen besonders fehleranfällig?
- Treten Fehler nach Softwareupdates auf?
- Sind Rollbacks häufig notwendig?
- Werden Standard-Changes falsch genutzt?
- Werden Tests vor Changes ausreichend durchgeführt?
- Sind betroffene Services nach Changes korrekt überwacht?
Trenddaten können zeigen, ob Change Enablement verbessert werden muss.
Monitoringdaten proaktiv nutzen
Monitoring zeigt nicht nur akute Störungen.
Es kann auch zukünftige Risiken sichtbar machen.
Beispiele:
- Speicher wächst kontinuierlich.
- Antwortzeiten steigen über Wochen.
- Fehlerquote nimmt langsam zu.
- CPU-Auslastung ist regelmäßig nahe am Limit.
- Zertifikate laufen bald ab.
- Backupdauer überschreitet zunehmend das Zeitfenster.
- Datenbankverbindungen nähern sich der Obergrenze.
- Warteschlangen werden länger.
Solche Signale können ein Problem anzeigen, bevor Benutzer betroffen sind.
Kapazitätstrends
Kapazitätstrends helfen zu erkennen, ob Ressourcen bald nicht mehr ausreichen.
Zu betrachten sind:
- Speicherplatz,
- CPU,
- Arbeitsspeicher,
- Netzwerkbandbreite,
- Datenbankgröße,
- Anzahl gleichzeitiger Sitzungen,
- Lizenzverbrauch,
- Backupfenster,
- Cloud-Kosten,
- API-Limits.
Beispiel:
Wenn ein Dateiserver jeden Monat um 12 Prozent wächst, kann bereits vor einem Ausfall geplant werden, wie Kapazität erweitert oder Daten bereinigt werden.
Known Errors auswerten
Known Errors sollten regelmäßig überprüft werden.
Fragen:
- Wie oft tritt der Known Error noch auf?
- Wie viele Incidents sind damit verbunden?
- Funktioniert der Workaround zuverlässig?
- Gibt es inzwischen eine dauerhafte Lösung?
- Ist das Risiko noch akzeptabel?
- Sind Knowledge-Artikel aktuell?
- Muss ein Change priorisiert werden?
- Gibt es neue betroffene Versionen oder Services?
Ein Known Error darf nicht dauerhaft unbeachtet bleiben.
Workaround-Nutzung als Warnsignal
Wenn ein Workaround sehr häufig genutzt wird, ist das ein Hinweis auf ein ungelöstes Problem.
Beispiel:
Der Service Desk startet jede Woche denselben Dienst neu.
Der Workaround funktioniert kurzfristig.
Trotzdem zeigt die Häufigkeit, dass eine dauerhafte Lösung notwendig ist.
Zu prüfen ist:
- Wie oft wird der Workaround genutzt?
- Welche Benutzer sind betroffen?
- Wie viel Arbeitszeit kostet er?
- Welche Risiken entstehen?
- Welche dauerhafte Lösung wäre möglich?
- Warum wurde sie bisher nicht umgesetzt?
Knowledge-Base-Daten nutzen
Die Knowledge Base liefert Hinweise auf wiederkehrende Themen.
Mögliche Signale:
- bestimmte Artikel werden sehr häufig aufgerufen,
- Benutzer bewerten Artikel als nicht hilfreich,
- viele Suchanfragen führen zu keinem Treffer,
- Service Desk nutzt immer denselben Artikel,
- Artikel werden nach Updates schnell veraltet,
- bestimmte Themen erzeugen trotz Artikel weiterhin viele Tickets.
Daraus können Verbesserungen entstehen:
- Artikel überarbeiten,
- neue Artikel erstellen,
- Self-Service verbessern,
- Formulare anpassen,
- oder technische Ursache untersuchen.
Benutzerfeedback auswerten
Benutzerfeedback kann Trends sichtbar machen, die in technischen Daten nicht sofort erkennbar sind.
Beispiele:
- Anwendung ist langsam, aber Monitoring zeigt keinen Ausfall.
- Portal ist unverständlich, obwohl Requests formal korrekt erstellt werden.
- Benutzer nutzen E-Mail statt Self-Service, weil sie den Service nicht finden.
- Workaround funktioniert technisch, ist aber im Alltag zu umständlich.
- Statusmeldungen kommen zu spät oder sind unverständlich.
Qualitative Rückmeldungen ergänzen Kennzahlen.
Lieferanteninformationen einbeziehen
Auch Lieferanten können wichtige Hinweise liefern.
Beispiele:
- bekannte Softwarefehler,
- Firmwareprobleme,
- Sicherheitswarnungen,
- Cloud-Service-Störungen,
- Versionshinweise,
- End-of-Life-Ankündigungen,
- Supportfälle anderer Kunden,
- Roadmap-Informationen.
Ein wiederkehrender interner Incident kann mit einem bekannten Herstellerfehler zusammenhängen.
Sicherheitsmeldungen als Problem-Auslöser
Nicht jede Sicherheitsmeldung ist ein Incident.
Manche Sicherheitsmeldungen weisen auf ein Problem oder Risiko hin.
Beispiele:
- wiederholte fehlgeschlagene Anmeldeversuche,
- veraltete Softwareversionen,
- unsichere Standardkonfiguration,
- fehlende Patches,
- schwache Berechtigungsprozesse,
- wiederkehrende Phishing-Erfolge,
- nicht inventarisierte Geräte.
Proaktives Problem Management kann helfen, solche Risiken strukturiert zu bearbeiten.
Trend, Problem und Verbesserung verbinden
Ein Trend allein ist noch keine Lösung.
Ein sinnvoller Ablauf:
Daten sammeln
↓
Muster erkennen
↓
Trend bewerten
↓
Problem Record erstellen
↓
Ursache oder Risiko untersuchen
↓
Workaround oder Schutzmaßnahme bereitstellen
↓
dauerhafte Verbesserung planen
↓
Wirkung messen
Dadurch wird aus Beobachtung eine steuerbare Verbesserung.
Wann aus einem Trend ein Problem Record entsteht
Ein Problem Record kann sinnvoll sein, wenn:
- ein Trend wiederholt auftritt,
- viele Benutzer betroffen sind,
- ein kritischer Service betroffen ist,
- die Ursache unbekannt ist,
- ein Workaround häufig verwendet wird,
- ein Risiko steigt,
- Kosten oder Aufwand deutlich zunehmen,
- Sicherheitsrelevanz besteht,
- oder eine dauerhafte Verbesserung notwendig erscheint.
Nicht jede Auffälligkeit benötigt sofort einen Problem Record.
Aber wichtige Trends sollten nicht verloren gehen.
Priorisierung proaktiver Problems
Proaktive Problems konkurrieren mit anderen Aufgaben.
Kriterien zur Priorisierung:
- geschäftliche Auswirkung,
- Anzahl betroffener Benutzer,
- Kritikalität des Service,
- Risiko eines zukünftigen Incidents,
- Sicherheitsrelevanz,
- Häufigkeit,
- Kosten,
- Aufwand,
- Verfügbarkeit eines Workarounds,
- erwarteter Nutzen,
- Abhängigkeit von Changes oder Lieferanten.
Ein Problem ohne aktuellen Ausfall kann trotzdem hohe Priorität besitzen, wenn ein schwerer Ausfall absehbar ist.
Beispiel: Speichertrend
Beobachtung
Monitoring zeigt, dass ein Dateiserver jeden Monat stark wächst.
Trend
Bei gleicher Entwicklung ist der Speicher in sechs Wochen voll.
Proaktives Problem Management
- Ursache des Wachstums prüfen,
- Datenarten analysieren,
- Verantwortliche identifizieren,
- Bereinigungsregeln bewerten,
- Kapazitätserweiterung prüfen,
- Monitoring-Grenzen anpassen,
- Runbook erstellen.
Nutzen
Ein zukünftiger Ausfall wird verhindert.
Beispiel: Häufige Passwort- und MFA-Tickets
Beobachtung
Ein großer Anteil der Service-Desk-Kontakte betrifft Passwort und MFA.
Analyse
Viele Benutzer kennen den Self-Service-Passwort-Reset nicht.
MFA-Anleitungen sind veraltet.
Verbesserung
- Knowledge-Artikel aktualisieren,
- Portalhinweise verbessern,
- Self-Service sichtbarer machen,
- Onboarding-Unterlagen ergänzen,
- häufige Fehler im Formular erklären.
Nutzen
Weniger Standardkontakte und schnellere Hilfe für Benutzer.
Beispiel: VPN-Incidents nach Clientupdate
Beobachtung
Nach einem Clientupdate steigen VPN-Incidents deutlich an.
Analyse
Betroffen sind nur Windows-Notebooks mit einer bestimmten Version.
Problem Record
Ein Problem wird eröffnet, um Ursache, Workaround und dauerhafte Lösung zu verfolgen.
Maßnahmen
- Known Error dokumentieren,
- Workaround bereitstellen,
- Herstellerhinweis prüfen,
- neue Version testen,
- Rollout über Change Enablement planen.
Beispiel: Eskalationen an Netzwerkteam steigen
Beobachtung
Immer mehr Tickets werden vom Service Desk an das Netzwerkteam eskaliert.
Analyse
Viele Eskalationen betreffen einfache DNS- und VPN-Prüfungen.
Verbesserung
- Runbook für Erstdiagnose erstellen,
- Service Desk schulen,
- Knowledge-Artikel ergänzen,
- Diagnosewerkzeug bereitstellen,
- Eskalationskriterien präzisieren.
Nutzen
Weniger unnötige Eskalationen und schnellere Bearbeitung.
Typische Fehler
Fehler 1
Trends werden nicht ausgewertet, obwohl Daten vorhanden sind.
Fehler 2
Einzelne Incidents werden gelöst, aber Muster bleiben unbeachtet.
Fehler 3
Nur technische Kennzahlen werden betrachtet.
Fehler 4
Benutzerfeedback wird ignoriert.
Fehler 5
Monitoring wird nur für Alarmierung genutzt, nicht für proaktive Analyse.
Fehler 6
Known Errors bleiben offen, ohne Häufigkeit und Risiko neu zu bewerten.
Fehler 7
Trends werden erkannt, aber keine Maßnahmen abgeleitet.
Fehler 8
Proaktive Problems werden immer niedriger priorisiert als akute Tickets.
Fehler 9
Datenqualität ist schlecht, wird aber nicht verbessert.
Fehler 10
Verbesserungsmaßnahmen werden nicht auf Wirksamkeit geprüft.
Fehler 11
Lieferantenhinweise und bekannte Herstellerfehler werden nicht berücksichtigt.
Fehler 12
Trendanalysen werden nur einmalig durchgeführt statt regelmäßig.
Checkliste Trendanalyse
- relevante Datenquellen festgelegt
- Zeitraum definiert
- Incidents nach Service ausgewertet
- Incidents nach Kategorie ausgewertet
- Standorte und Benutzergruppen betrachtet
- Wiederholungen erkannt
- Changes zeitlich verglichen
- Monitoringdaten berücksichtigt
- Known Errors ausgewertet
- Workaround-Nutzung geprüft
- Benutzerfeedback berücksichtigt
- auffällige Trends dokumentiert
Checkliste proaktives Problem Management
- Trend oder Risiko beschrieben
- betroffener Service bekannt
- mögliche Auswirkungen bewertet
- Priorität festgelegt
- Problem Record bei Bedarf erstellt
- Verantwortlicher benannt
- Daten und Fakten gesammelt
- Hypothesen formuliert
- Workaround oder Schutzmaßnahme geprüft
- dauerhafte Lösung bewertet
- Change-Bedarf geprüft
- Verbesserung verfolgt
- Wirksamkeit geprüft
Checkliste Datenqualität
- Tickets enthalten betroffenen Service
- Kategorien werden einheitlich verwendet
- Prioritäten sind begründet
- Workarounds sind dokumentiert
- Changes sind nachvollziehbar verknüpft
- Monitoringdaten sind verfügbar
- Zeitstempel sind korrekt
- CMDB-Informationen sind ausreichend aktuell
- Known Errors sind auffindbar
- Abschlussnotizen sind verständlich
Bedeutung für Fachinformatiker für Systemintegration
Fachinformatiker erkennen Trends häufig direkt im technischen Alltag.
Beispiele:
- gleiche Fehlermeldung taucht immer wieder auf,
- derselbe Server erzeugt regelmäßig Warnungen,
- bestimmte Geräteklasse verursacht viele Tickets,
- ein Workaround wird ständig wiederholt,
- ein Monitoringwert verschlechtert sich langsam,
- oder ein Standort meldet auffällig viele Netzwerkprobleme.
Wichtig ist, solche Beobachtungen nicht nur mündlich weiterzugeben, sondern nachvollziehbar zu dokumentieren.
So können daraus Problems, Known Errors, Changes oder Verbesserungen entstehen.
Zusammenfassung
Incidents, Monitoring und Feedback auswerten
↓
Muster und Trends erkennen
↓
Risiko und Auswirkung bewerten
↓
Problem Record bei Bedarf erstellen
↓
Ursache oder mögliche Ursache untersuchen
↓
Workaround oder Schutzmaßnahme bereitstellen
↓
dauerhafte Verbesserung planen
↓
Change, Knowledge oder Continual Improvement einbinden
↓
Wirkung messen und Datenqualität verbessern
Merksätze
Trends zeigen, wo wiederkehrende Ursachen verborgen sein können.
Proaktives Problem Management beginnt, bevor der große Ausfall eintritt.
Monitoring ist nicht nur Alarmierung, sondern auch Frühwarnsystem.
Häufig genutzte Workarounds sind ein Hinweis auf ungelöste Problems.
Gute Datenqualität ist die Grundlage guter Trendanalyse.
Ein erkannter Trend ist erst wertvoll, wenn daraus eine konkrete Verbesserung entsteht.
Verwandte Seiten
- 4.1 Problem Management – Ziele, Begriffe und Abgrenzung
- 4.2 Ursachenanalyse
- 4.3 Workarounds und Known Errors
- 4.5 Problem Management im Zusammenspiel mit Incident, Change und Knowledge Management
- 3.9 Kennzahlen, Qualität und Continual Improvement im Service Desk
- Service Level Management
- Knowledge Management
- Change Enablement
- Continual Improvement
- Measurement and Reporting
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: Measurement and Reporting
- PeopleCert – ITIL Practice Guide: Continual Improvement
- ITIL Foundation – Version 5
Einordnung
Die dargestellten:
- Trendanalyse-Beispiele,
- Datenquellen,
- Prüffragen,
- Checklisten,
- Priorisierungskriterien,
- und Praxisbeispiele
sind herstellerneutrale Praxisempfehlungen.
ITIL schreibt keine universelle:
- Trendanalyse-Methode,
- Datenquellenliste,
- KPI-Struktur,
- Problem-Eröffnungsschwelle,
- Analysefrequenz,
- oder Toolauswahl
für alle Organisationen vor.
Die konkrete Umsetzung muss an:
- Services,
- Risiken,
- Datenqualität,
- Monitoring,
- Supportmodell,
- Service Levels,
- Organisation,
- Lieferanten,
- 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
4.5 Problem Management im Zusammenspiel mit Incident, Change und Knowledge Management
Kurz erklärt
Problem Management arbeitet nicht isoliert.
Es ist eng verbunden mit Incident Management, Change Enablement, Knowledge Management, Service Configuration Management und Continual Improvement.
Nur wenn diese Practices zusammenarbeiten, können Incidents schnell bearbeitet, Ursachen verstanden, dauerhafte Lösungen umgesetzt und Wissen für zukünftige Fälle nutzbar gemacht werden.
Warum das Zusammenspiel wichtig ist
Ein Problem entsteht häufig aus wiederkehrenden oder schwerwiegenden Incidents.
Die dauerhafte Lösung benötigt oft einen Change.
Der Service Desk benötigt Workarounds und Known Errors aus dem Knowledge Management.
Service Configuration Management liefert Informationen über betroffene Systeme und Abhängigkeiten.
Continual Improvement sorgt dafür, dass Erkenntnisse nicht verloren gehen.
Ohne dieses Zusammenspiel entstehen typische Schwächen:
- Incidents werden einzeln gelöst, aber Ursachen bleiben bestehen.
- Workarounds sind bekannt, aber nicht dokumentiert.
- Changes werden durchgeführt, ohne das Problem vollständig zu verstehen.
- Knowledge-Artikel werden nicht aktualisiert.
- Serviceabhängigkeiten sind unbekannt.
- Lessons Learned werden nicht umgesetzt.
- dieselben Incidents treten immer wieder auf.
Überblick über das Zusammenspiel
Incident tritt auf
↓
Incident Management stellt Service wieder her
↓
wiederkehrendes Muster oder schwere Auswirkung wird erkannt
↓
Problem Management untersucht Ursache
↓
Workaround oder Known Error wird dokumentiert
↓
Knowledge Management stellt Wissen bereit
↓
dauerhafte Lösung wird vorbereitet
↓
Change Enablement steuert Umsetzung
↓
Service wird stabilisiert
↓
Continual Improvement übernimmt Erkenntnisse
Problem Management und Incident Management
Incident Management und Problem Management haben unterschiedliche Schwerpunkte.
| Incident Management | Problem Management |
|---|---|
| schnelle Wiederherstellung des Service | Ursache verstehen und Wiederholung vermeiden |
| kurzfristiger Fokus | nachhaltiger Fokus |
| einzelne Störung bearbeiten | Muster und Ursachen untersuchen |
| Workaround kann genügen | dauerhafte Lösung wird angestrebt |
| Benutzer schnell arbeitsfähig machen | Service langfristig stabiler machen |
Beide Practices ergänzen sich.
Incident Management liefert Daten und Erfahrungen.
Problem Management liefert Workarounds, Known Errors und dauerhafte Verbesserungen zurück.
Was Incident Management an Problem Management liefert
Wichtige Informationen aus Incidents:
- betroffener Service,
- Symptome,
- Fehlermeldungen,
- Zeitpunkt,
- betroffene Benutzer oder Standorte,
- Priorität,
- Auswirkungen,
- erste Diagnose,
- durchgeführte Maßnahmen,
- verwendete Workarounds,
- Eskalationen,
- Logs,
- Monitoringdaten,
- betroffene Configuration Items,
- Benutzerfeedback,
- Wiedereröffnungen.
Je besser Incidents dokumentiert sind, desto leichter kann Problem Management Muster erkennen.
Was Problem Management an Incident Management zurückliefert
Problem Management unterstützt Incident Management durch:
- Known Errors,
- Workarounds,
- Diagnosehinweise,
- Eskalationsregeln,
- Knowledge-Artikel,
- Runbooks,
- Hinweise auf betroffene Versionen,
- bekannte Symptome,
- bekannte Risiken,
- und geplante dauerhafte Lösungen.
Dadurch kann der Service Desk zukünftige Incidents schneller erkennen und bearbeiten.
Beispiel:
Wenn ein VPN-Fehler als Known Error dokumentiert ist, muss der Service Desk nicht bei jedem neuen Ticket von vorn analysieren.
Wann ein Incident zu einem Problem führen kann
Ein Problem Record kann sinnvoll sein, wenn:
- mehrere ähnliche Incidents auftreten,
- ein Major Incident stattgefunden hat,
- die Ursache unbekannt bleibt,
- ein Workaround häufig genutzt wird,
- ein Service wiederholt instabil ist,
- ein Sicherheitsrisiko vermutet wird,
- ein Trend erkennbar ist,
- oder ein einzelner Incident sehr hohe Auswirkungen hatte.
Nicht jeder Incident benötigt automatisch ein Problem.
Die Organisation sollte Kriterien festlegen.
Beispiel: Incident zu Problem
Incident
Mehrere Benutzer melden, dass VPN nach dem Ruhezustand nicht mehr funktioniert.
Incident Management
Der Service Desk stellt die Verbindung durch Neustart des VPN-Clients wieder her.
Problem Management
Mehrere gleichartige Incidents werden verglichen.
Es wird erkannt:
- gleiche Client-Version,
- gleiches Fehlerbild,
- gleicher Auslöser,
- gleicher Workaround.
Ergebnis
Ein Problem Record wird erstellt.
Ein Known Error und ein Workaround werden dokumentiert.
Ein Change für eine neue Client-Version wird vorbereitet.
Problem Management und Change Enablement
Dauerhafte Lösungen erfordern häufig Änderungen an produktiven Systemen.
Beispiele:
- Softwareupdate,
- Konfigurationsänderung,
- Austausch defekter Hardware,
- Anpassung einer Firewall-Regel,
- Änderung eines Deployments,
- Zertifikatserneuerung,
- Monitoring-Erweiterung,
- Automatisierung,
- Prozessänderung.
Solche Maßnahmen dürfen nicht unkontrolliert durchgeführt werden.
Change Enablement sorgt dafür, dass Änderungen bewertet, geplant, genehmigt, umgesetzt und überprüft werden.
Warum dauerhafte Lösungen oft Changes sind
Eine dauerhafte Lösung verändert häufig den Zustand einer Umgebung.
Beispiele:
| Problem | mögliche dauerhafte Lösung | Bezug zu Change Enablement |
|---|---|---|
| VPN-Client fehlerhaft | neue Version ausrollen | Software-Change |
| Zertifikat läuft ab | Zertifikat erneuern und Monitoring ergänzen | technischer Change |
| Speicher läuft voll | Logrotation ändern | Konfigurations-Change |
| Druckertreiber fehlerhaft | Treiber aktualisieren | Standard- oder Normal-Change |
| Dienst stürzt regelmäßig ab | Anwendungspatch einspielen | Release oder Change |
| Berechtigungen falsch modelliert | Rollenkonzept anpassen | organisatorischer und technischer Change |
Die Art des Changes hängt von Risiko, Auswirkung und Organisationsregeln ab.
Problem Management liefert Input für Changes
Ein guter Change zur Problemlösung sollte auf nachvollziehbaren Informationen beruhen.
Problem Management liefert dafür:
- Problembeschreibung,
- Ursache oder wahrscheinliche Ursache,
- Auswirkungen,
- betroffene Services,
- betroffene Configuration Items,
- Risiko bei Nicht-Handeln,
- Workaround,
- bekannte Einschränkungen,
- empfohlene Lösung,
- erwarteten Nutzen,
- mögliche Nebenwirkungen,
- Testhinweise,
- Rollback-Hinweise,
- Verknüpfung zu Incidents.
Dadurch kann Change Enablement besser bewerten, ob und wie die Änderung umgesetzt werden soll.
Change Enablement liefert Informationen zurück
Nach einem Change sollte geprüft werden:
- Wurde die dauerhafte Lösung erfolgreich umgesetzt?
- Sind die betroffenen Incidents zurückgegangen?
- Sind neue Fehler entstanden?
- Funktioniert der Service stabil?
- Muss der Workaround angepasst oder entfernt werden?
- Muss der Known Error geschlossen werden?
- Müssen Knowledge-Artikel aktualisiert werden?
- Muss Monitoring angepasst werden?
Ein Problem sollte nicht automatisch geschlossen werden, nur weil ein Change umgesetzt wurde.
Die Wirksamkeit muss überprüft werden.
Emergency Change und Problem Management
Bei sehr kritischen Situationen kann eine schnelle Änderung notwendig sein.
Beispiele:
- Sicherheitslücke wird aktiv ausgenutzt,
- zentraler Service ist ausgefallen,
- Datenverlust droht,
- ein Workaround ist nicht verfügbar,
- ein Major Incident erfordert sofortige technische Änderung.
Auch dann sollten Entscheidungen dokumentiert werden.
Nach der Wiederherstellung sollten Problem Management und Review klären:
- Warum war ein Emergency Change nötig?
- War die Änderung wirksam?
- Welche Risiken entstanden?
- Welche dauerhafte Lösung ist noch erforderlich?
- Wie kann eine ähnliche Situation künftig vermieden werden?
Problem Management und Knowledge Management
Problem Management erzeugt Wissen.
Dieses Wissen muss auffindbar, verständlich und aktuell sein.
Geeignete Inhalte für Knowledge Management:
- bekannte Symptome,
- Workarounds,
- Known Errors,
- Prüfschritte,
- Eskalationskriterien,
- betroffene Versionen,
- Abbruchkriterien,
- sichere Benutzeranleitungen,
- interne Runbooks,
- dauerhafte Lösungen,
- Lessons Learned.
Wenn Wissen nicht dokumentiert wird, müssen Teams dieselben Fälle immer wieder neu analysieren.
Unterschiedliche Zielgruppen für Wissen
Nicht jedes Wissen gehört in denselben Artikel.
| Zielgruppe | Inhalt |
|---|---|
| Benutzer | einfache Anleitung, Workaround, Statushinweise |
| Service Desk | Prüfschritte, bekannte Symptome, Eskalationsregeln |
| Fachteam | technische Details, Logs, Konfigurationen, Ursachen |
| Management | Risiko, Auswirkungen, Verbesserungsstatus |
| Lieferant | Produktversion, Fehlerbild, technische Nachweise |
Ein Benutzerartikel sollte keine internen Diagnoseschritte oder vertraulichen technischen Details enthalten.
Known Error als Wissensbaustein
Ein Known Error ist besonders wichtig für Knowledge Management.
Er beschreibt:
- welches Fehlerbild bekannt ist,
- welcher Service betroffen ist,
- welche Ursache oder wahrscheinliche Ursache vorliegt,
- welcher Workaround gilt,
- wann eskaliert werden muss,
- welche dauerhafte Lösung geplant ist,
- und ob ein Change offen ist.
Dadurch kann der Service Desk schneller entscheiden, ob ein neuer Incident zu einem bekannten Fehler passt.
Knowledge-Artikel aktuell halten
Nach Problem- und Change-Bearbeitung müssen Wissensartikel geprüft werden.
Zu aktualisieren sind möglicherweise:
- Workarounds,
- Known-Error-Status,
- Screenshots,
- Menüpfade,
- betroffene Versionen,
- Eskalationswege,
- Sicherheitswarnungen,
- Benutzerinformationen,
- Runbooks,
- Monitoringhinweise,
- Abschlusskriterien.
Ein gelöster Known Error mit veraltetem Workaround kann später neue Verwirrung erzeugen.
Problem Management und Service Configuration Management
Für Problem Management sind Informationen über Configuration Items und Serviceabhängigkeiten sehr wichtig.
Hilfreich sind:
- betroffene Server,
- Anwendungen,
- Datenbanken,
- Netzwerke,
- Zertifikate,
- Schnittstellen,
- Cloud-Dienste,
- Lieferantenservices,
- Versionen,
- Standorte,
- Verantwortliche,
- Abhängigkeiten.
Ohne diese Informationen ist schwer erkennbar, welche Komponenten gemeinsam betroffen sind.
Beispiel: Abhängigkeiten erkennen
Mehrere Anwendungen melden Verbindungsfehler.
Einzelne Teams prüfen zunächst ihre Anwendungen getrennt.
Durch Service- und CI-Beziehungen wird sichtbar:
- alle Anwendungen nutzen denselben Datenbankcluster,
- der Datenbankcluster nutzt denselben Storage,
- genau dieser Storage zeigt erhöhte Fehlerraten.
Problem Management kann dadurch gezielter analysieren.
Problem Management und Service Level Management
Service Level Management hilft zu bewerten, welche Problems besonders wichtig sind.
Zu berücksichtigen sind:
- vereinbarte Service Levels,
- betroffene Servicezeiten,
- geschäftskritische Services,
- wiederholte SLA-Gefährdung,
- Benutzer- oder Kundenimpact,
- Service Reviews,
- Beschwerden,
- vertragliche Verpflichtungen.
Ein Problem mit wenigen Incidents kann hohe Priorität besitzen, wenn ein kritischer Service oder ein wichtiges Service Level gefährdet ist.
Problem Management und Supplier Management
Viele Problems betreffen Lieferanten oder Hersteller.
Beispiele:
- Software-Bug,
- Cloud-Service-Störung,
- Firmwarefehler,
- Providerproblem,
- fehlerhafte Schnittstelle,
- Lizenzdienst nicht erreichbar,
- Hardwarefehler.
Problem Management sollte dokumentieren:
- Lieferantenticket,
- Herstellerreferenz,
- betroffene Version,
- empfohlener Workaround,
- geplante Korrektur,
- interne Auswirkungen,
- Eskalationsweg,
- offene Risiken.
Auch wenn ein Lieferant technisch verantwortlich ist, bleibt die interne Serviceverantwortung bestehen.
Problem Management und Continual Improvement
Problem Management liefert viele Verbesserungsideen.
Beispiele:
- Monitoring erweitern,
- Knowledge Base verbessern,
- Runbooks erstellen,
- Standard-Changes definieren,
- Schulungen durchführen,
- Automatisierung einführen,
- Serviceabhängigkeiten pflegen,
- Prozesse verbessern,
- Lieferantensteuerung anpassen.
Diese Verbesserungen sollten nicht nur mündlich besprochen werden.
Sie sollten in einem Improvement Register oder vergleichbaren System verfolgt werden.
Problem Management und Information Security Management
Manche Problems haben Sicherheitsbezug.
Beispiele:
- wiederkehrende kompromittierte Konten,
- unsichere Standardkonfiguration,
- veraltete Software,
- fehlende Patchprozesse,
- zu weitreichende Berechtigungen,
- unzureichende Protokollierung,
- wiederholte Phishing-Erfolge,
- fehlende MFA-Ausnahmenkontrolle.
Sicherheitsbezogene Problems benötigen möglicherweise:
- besondere Vertraulichkeit,
- andere Eskalationswege,
- Beweissicherung,
- Risikobewertung,
- Meldefristen,
- und Abstimmung mit Informationssicherheit.
Problem Management und Monitoring
Monitoring unterstützt Problem Management durch:
- Frühwarnungen,
- Trends,
- Fehlerraten,
- Kapazitätsdaten,
- Verfügbarkeitsdaten,
- Antwortzeiten,
- Logereignisse,
- Zertifikatsabläufe,
- Backupstatus,
- Hardwarezustände.
Problem Management kann umgekehrt Monitoring verbessern.
Beispiele:
- neuer Alarm für Zertifikatsablauf,
- zusätzliche Überwachung von Logwachstum,
- Dashboard für häufig betroffene Services,
- bessere Alarmgrenzen,
- Überwachung eines Workarounds,
- Prüfung nach Change.
Zusammenspiel als Kreislauf
Incident-Daten
↓
Problem-Analyse
↓
Known Error und Workaround
↓
Knowledge-Artikel
↓
dauerhafte Lösung
↓
Change
↓
Wirksamkeitsprüfung
↓
Verbesserung von Monitoring, Wissen und Prozessen
↓
weniger oder schneller lösbare Incidents
Typische Fehler im Zusammenspiel
Fehler 1
Incidents werden gelöst, aber nicht mit Problems verknüpft.
Fehler 2
Problem Management erhält zu wenig Informationen aus Tickets.
Fehler 3
Workarounds werden gefunden, aber nicht in Knowledge Management übernommen.
Fehler 4
Known Errors sind nur Spezialisten bekannt.
Fehler 5
Dauerhafte Lösungen werden ohne Change-Bewertung umgesetzt.
Fehler 6
Nach einem Change wird nicht geprüft, ob das Problem wirklich gelöst ist.
Fehler 7
Knowledge-Artikel bleiben nach einer dauerhaften Lösung unverändert.
Fehler 8
CMDB- und Serviceabhängigkeiten werden nicht genutzt.
Fehler 9
Lieferantenfehler werden intern nicht nachvollziehbar dokumentiert.
Fehler 10
Lessons Learned werden nicht in Continual Improvement übernommen.
Fehler 11
Sicherheitsbezug wird zu spät erkannt.
Fehler 12
Problem Records bleiben offen, ohne Verantwortlichen oder nächsten Schritt.
Praxisbeispiel: VPN-Problem
Incident Management
Mehrere Benutzer melden VPN-Abbrüche.
Der Service Desk stellt die Verbindung durch Neustart des Clients wieder her.
Problem Management
Incidents werden verglichen.
Die Analyse zeigt:
- gleiche Client-Version,
- gleiches Fehlerbild,
- Auftreten nach Ruhezustand,
- bekannter Herstellerfehler.
Knowledge Management
Ein Known Error und ein Workaround werden dokumentiert.
Der Service Desk erhält Prüfschritte.
Change Enablement
Eine neue Client-Version wird getestet und kontrolliert ausgerollt.
Continual Improvement
Der Updateprozess wird angepasst, damit Clientupdates künftig besser getestet werden.
Praxisbeispiel: Zertifikatsausfall
Incident Management
Benutzer können sich nicht an einer Anwendung anmelden.
Das abgelaufene Zertifikat wird erneuert.
Problem Management
Die Ursache wird untersucht.
Ergebnis:
- kein Monitoring für Zertifikatsablauf,
- kein Owner für Zertifikate,
- kein Runbook für Erneuerung.
Knowledge Management
Symptome und Prüfschritte werden dokumentiert.
Change Enablement
Monitoring und Erneuerungsprozess werden eingeführt.
Continual Improvement
Zertifikatsübersicht und Wartungskalender werden als Standard etabliert.
Praxisbeispiel: Druckerfehler
Incident Management
Etikettendrucker blockiert regelmäßig.
Der Service Desk leert die Warteschlange.
Problem Management
Bestimmte PDF-Dateien und ein alter Treiber werden als Ursache erkannt.
Knowledge Management
Workaround wird dokumentiert.
Change Enablement
Treiberupdate wird getestet und ausgerollt.
Service Desk
Künftige Incidents können schneller erkannt werden.
Continual Improvement
Druckertreiber werden in einen regelmäßigen Prüfprozess aufgenommen.
Checkliste Zusammenspiel mit Incident Management
- zugehörige Incidents verknüpft
- Symptome aus Incidents zusammengefasst
- Auswirkungen dokumentiert
- Workarounds aus Incidents geprüft
- Wiedereröffnungen berücksichtigt
- Eskalationen ausgewertet
- Service Desk über Known Error informiert
- Incident-Abschlusskriterien geprüft
- neue Incidents dem Problem zugeordnet
- Trenddaten berücksichtigt
Checkliste Zusammenspiel mit Change Enablement
- dauerhafte Lösung beschrieben
- Risiko bewertet
- betroffene Services und CIs bekannt
- Change-Typ geprüft
- Testbedarf beschrieben
- Rollback betrachtet
- Wartungsfenster geprüft
- Kommunikationsbedarf erkannt
- Change mit Problem Record verknüpft
- Wirksamkeit nach Change geprüft
Checkliste Zusammenspiel mit Knowledge Management
- Known Error dokumentiert
- Workaround beschrieben
- Zielgruppe des Artikels festgelegt
- Service Desk informiert
- Benutzerinformation bei Bedarf erstellt
- interne technische Hinweise ergänzt
- Eskalationskriterien beschrieben
- Artikel nach Change aktualisiert
- veraltete Inhalte entfernt
- Lessons Learned übernommen
Checkliste Zusammenspiel mit Configuration Management
- betroffene CIs erfasst
- Serviceabhängigkeiten geprüft
- Versionen dokumentiert
- Standorte berücksichtigt
- Lieferantenbezug geprüft
- letzte Changes berücksichtigt
- CMDB-Abweichungen erkannt
- notwendige Aktualisierungen veranlasst
Checkliste Abschluss eines Problems
- Ursache oder Risiko ausreichend verstanden
- Workaround dokumentiert oder als nicht verfügbar gekennzeichnet
- Known Error aktualisiert
- dauerhafte Lösung umgesetzt oder bewusst zurückgestellt
- Change-Ergebnis geprüft
- Knowledge Base aktualisiert
- zugehörige Incidents berücksichtigt
- Monitoring oder Runbooks angepasst
- Lessons Learned dokumentiert
- Rest Risiko bewertet
- Verantwortliche informiert
Bedeutung für Fachinformatiker für Systemintegration
Fachinformatiker für Systemintegration stehen oft genau an der Schnittstelle zwischen Incident, Problem, Change und Knowledge.
Im Arbeitsalltag bedeutet das:
- Incidents sauber dokumentieren,
- wiederkehrende Muster erkennen,
- technische Ursachen nachvollziehbar beschreiben,
- Workarounds sicher formulieren,
- Knowledge-Artikel und Runbooks unterstützen,
- Changes fachlich vorbereiten,
- CIs und Abhängigkeiten berücksichtigen,
- Monitoring verbessern,
- und Lessons Learned in dauerhafte Verbesserungen überführen.
Gute technische Arbeit endet nicht mit der Wiederherstellung eines Services.
Sie hilft auch, zukünftige Incidents zu vermeiden oder schneller zu lösen.
Zusammenfassung
Incident wird bearbeitet
↓
Muster oder Ursache wird erkannt
↓
Problem Record wird erstellt
↓
Ursache, Risiko und Workaround werden untersucht
↓
Known Error und Knowledge werden dokumentiert
↓
dauerhafte Lösung wird vorbereitet
↓
Change Enablement steuert Umsetzung
↓
Wirksamkeit wird geprüft
↓
Monitoring, Knowledge, Prozesse und Standards werden verbessert
↓
zukünftige Incidents werden reduziert oder schneller lösbar
Merksätze
Incident Management stellt den Service wieder her.
Problem Management versteht Ursachen und reduziert Wiederholungen.
Change Enablement sorgt für kontrollierte dauerhafte Lösungen.
Knowledge Management macht Workarounds und Known Errors nutzbar.
Configuration Management zeigt Abhängigkeiten und betroffene Komponenten.
Continual Improvement sorgt dafür, dass Erkenntnisse nicht verloren gehen.
Gute Zusammenarbeit verhindert, dass dieselben Fehler immer wieder neu analysiert werden.
Verwandte Seiten
- 4.1 Problem Management – Ziele, Begriffe und Abgrenzung
- 4.2 Ursachenanalyse
- 4.3 Workarounds und Known Errors
- 4.4 Trendanalyse und proaktives Problem Management
- 3.6 Erstdiagnose, Lösung und funktionale Eskalation
- 3.9 Kennzahlen, Qualität und Continual Improvement im Service Desk
- 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: Change Enablement
- PeopleCert – ITIL Practice Guide: Knowledge Management
- PeopleCert – ITIL Practice Guide: Service Configuration Management
- PeopleCert – ITIL Practice Guide: Continual Improvement
- ITIL Foundation – Version 5
Einordnung
Die dargestellten:
- Schnittstellen,
- Checklisten,
- Praxisbeispiele,
- Ablaufdarstellungen,
- Rollenhinweise,
- und Dokumentationshinweise
sind herstellerneutrale Praxisempfehlungen.
ITIL schreibt keine universelle:
- Schnittstellenmatrix,
- Übergabestruktur,
- Problem-Abschlussregel,
- Knowledge-Vorlage,
- Change-Verknüpfung,
- oder konkrete Toolintegration
für alle Organisationen vor.
Die konkrete Umsetzung muss an:
- Services,
- Risiken,
- Organisation,
- ITSM-Werkzeuge,
- Datenqualität,
- Supportmodell,
- Change-Modell,
- Knowledge-Struktur,
- Lieferanten,
- 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