4. Problem 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