# 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