Problem Management nach ITIL: Root-Cause-Analyse und Known Errors
Der Problem-Management-Prozess
Problem Management ist die ITIL-Practice, die verhindert, dass dieselbe Störung immer wieder neu bearbeitet wird. Statt jeden Vorfall isoliert zu lösen, sucht das Team nach der Ursache und beseitigt sie dauerhaft – oder dokumentiert zumindest einen zuverlässigen Workaround. Dieser Beitrag ist Teil des übergeordneten ITIL-Frameworks und erklärt Prozess, Methoden und Rollen anhand konkreter Beispiele aus der Praxis.
Weiterlesen: Problem Management nach ITIL einführen, Ursachen analysieren und wiederkehrende Incidents reduzieren
Problem Management nach ITIL systematisch einführen
Ein wirksames Problem Management beginnt nicht mit einem zusätzlichen Ticketstatus, sondern mit einer klaren Entscheidung: Wiederkehrende und besonders risikoreiche Störungen werden nicht nur erneut behoben, sondern als eigenes Problem analysiert, priorisiert und bis zu einer nachhaltigen Lösung verfolgt. Unternehmen können dafür zunächst eine Bestandsaufnahme beauftragen, einen Workshop anfragen und anschließend Rollen, Problem Records, Known Error Database und Schnittstellen zum Incident- und Change-Prozess schrittweise einführen.
Die Einführung lohnt sich insbesondere, wenn der Service Desk dieselben Workarounds wiederholt, technische Teams immer wieder ähnliche Ursachen vermuten oder wichtige Services trotz schneller Incident-Lösung regelmäßig ausfallen. Eine belastbare Problem-Management-Praxis schafft Transparenz darüber, welche Ursachen noch ungeklärt sind, welche Risiken akzeptiert werden und welche dauerhaften Maßnahmen bereits über einen Change umgesetzt werden. Sie verbindet operative Stabilität mit nachvollziehbaren Entscheidungen und verhindert, dass ungelöste Ursachen in verschiedenen Tickets verschwinden.
Scope und Auslöser für Problem Records definieren
Nicht jeder Incident muss automatisch ein Problem werden. Sinnvoll sind klare Triggerkriterien: wiederkehrende Incidents mit gleichem Symptom, Major Incidents, Sicherheits- oder Compliance-Risiken, auffällige Monitoring-Trends, bekannte Herstellerfehler oder Störungen mit hohem kumuliertem Aufwand. Der Problem Manager prüft diese Signale und entscheidet gemeinsam mit Service Ownern und Resolver-Teams, ob eine formale Ursachenanalyse notwendig ist.
- Häufigkeit: Dasselbe Symptom tritt innerhalb eines definierten Zeitraums mehrfach auf.
- Auswirkung: Ein einzelner Vorfall beeinträchtigt kritische Services, viele Nutzer oder wichtige Geschäftsprozesse.
- Risiko: Eine bekannte Schwachstelle oder technische Abhängigkeit kann künftig zu einem erheblichen Incident führen.
- Aufwand: Wiederholte Diagnose und manuelle Workarounds binden dauerhaft Service-Desk- und Resolver-Kapazitäten.
- Unklarheit: Ein Incident wurde wiederhergestellt, die technische oder organisatorische Ursache ist jedoch weiterhin unbekannt.
Diese Kriterien sollten nicht nur dokumentiert, sondern im Ticket-System technisch abbildbar sein. Ancud IT kann Trigger, Priorisierung und Eskalationen konzipieren, die Konfiguration entwickeln lassen oder gemeinsam mit dem internen Team umsetzen. Wer zunächst klein starten möchte, kann einen Pilot für einen kritischen Service bestellen und nach der Auswertung weitere Bereiche beauftragen.
Incident und Problem Management sauber verzahnen
Incident und Problem Management verfolgen unterschiedliche Zeithorizonte. Das Incident Management stellt einen Service so schnell wie möglich wieder her. Problem Management untersucht dagegen die Ursache, bewertet Risiken und entwickelt eine dauerhafte Lösung oder einen kontrollierten Workaround. Ein Incident kann geschlossen werden, obwohl das zugehörige Problem noch offen ist. Umgekehrt kann ein Problem bereits proaktiv angelegt werden, obwohl noch kein Nutzer einen Incident gemeldet hat.
Die technische Verknüpfung sollte eindeutig sein: Incidents referenzieren den Problem Record, Problem Records enthalten die betroffenen Services und Configuration Items, und Known Errors liefern dem Service Desk freigegebene Workarounds. So lässt sich später erkennen, wie viele Incidents durch eine Ursache entstanden sind, wie viel Bearbeitungszeit gebunden wurde und ob eine umgesetzte Maßnahme die Wiederholungsrate tatsächlich reduziert hat.
Bei der Einführung können Unternehmen die Prozessintegration beauftragen, Schnittstellen zur CMDB entwickeln lassen und automatische Verknüpfungen umsetzen lassen. Entscheidend ist, dass Mitarbeitende nicht zwischen mehreren unverbundenen Listen wechseln müssen. Ein Werkzeug soll die Zusammenarbeit unterstützen, nicht einen zusätzlichen Pflegeprozess erzeugen.
Reaktives und proaktives Problem Management kombinieren
Reaktives Problem Management beginnt nach einem oder mehreren Incidents. Proaktives Problem Management sucht dagegen nach Ursachen, bevor eine sichtbare Störung entsteht. Dazu werden Trenddaten, Kapazitätswerte, Event-Muster, Herstellerinformationen, Security Findings, abgebrochene Changes und wiederkehrende Warnungen ausgewertet. Beide Ansätze gehören in denselben Prozess, benötigen aber unterschiedliche Eingangskanäle und Priorisierungsregeln.
Ein realistischer Start besteht darin, monatlich die häufigsten Incident-Kategorien, die teuersten Wiederholfälle und offene Major-Incident-Maßnahmen zu prüfen. Zusätzlich können technische Teams pro Quartal Risiken aus Monitoring, Obsoleszenz und Herstellerhinweisen melden. Wer diese Auswertung nicht intern aufbauen möchte, kann das Reporting betreuen lassen, einen Analyse-Service anfragen oder die erforderlichen Dashboards entwickeln lassen.
Problem Manager, Service Owner und Resolver-Teams abgrenzen
Die Suchphrase Problem Manager ITIL bezeichnet keine rein administrative Ticketrolle. Der Problem Manager steuert den Prozess, moderiert Priorisierungen, fordert Ursachenanalysen ein, prüft die Qualität von Problem Records und berichtet über Risiken sowie Fortschritt. Die technische Analyse bleibt bei den zuständigen Resolver-Teams. Service Owner bewerten geschäftliche Auswirkungen, während Change-Verantwortliche die dauerhafte Behebung kontrolliert in die Produktion bringen.
Ein schlankes RACI-Modell verhindert, dass alle Beteiligten „irgendwie zuständig“ sind. Für Erfassung, Priorisierung, Root Cause Analysis, Workaround-Freigabe, KEDB-Pflege, Change-Anstoß, Wirksamkeitskontrolle und Abschluss sollte jeweils festgelegt werden, wer verantwortlich, ausführend, beratend und zu informieren ist. Ancud IT kann ein Rollenmodell erstellen lassen, Moderationsformate entwickeln lassen und die Einführung als zusammenhängendes Arbeitspaket beauftragen.
Problem Record und Known Error Database belastbar strukturieren
Ein Problem Record sollte mindestens Symptom, betroffene Services, verknüpfte Incidents, Priorität, Verantwortliche, Hypothesen, Analyseergebnisse, Ursache, Workaround, Risiken, geplante Changes und Prüftermine enthalten. Die Dokumentation muss verständlich bleiben: Ein Service-Desk-Mitarbeiter benötigt eine schnelle Handlungsanweisung, ein Resolver-Team technische Details und das Management eine nachvollziehbare Risikobewertung.
Ein Known Error entsteht, sobald Ursache und/oder ein verlässlicher Workaround ausreichend bekannt sind. Die Known Error Database ist deshalb eng mit dem Wissensmanagement verbunden. Freigegebene Einträge sollten suchbar, versioniert, mit Gültigkeit und Verantwortlichem versehen sowie regelmäßig überprüft werden. Veraltete Workarounds können neue Risiken erzeugen; deshalb müssen Review und Archivierung Teil des Prozesses sein.
Unternehmen können eine KEDB-Struktur bestellen, bestehende Wissensartikel prüfen lassen oder die Integration in das Service-Management-Tool entwickeln lassen. Für den laufenden Betrieb lässt sich die Datenqualität betreuen lassen und bei Bedarf Wartung buchen. Ein klarer Freigabeprozess verhindert, dass ungeprüfte technische Hinweise direkt als verbindliche Lösung veröffentlicht werden.
Root Cause Analysis passend zur Komplexität auswählen
Die Methode sollte zum Problem passen. 5 Whys eignet sich für überschaubare, lineare Ursachenketten. Das Ishikawa-Diagramm strukturiert mehrere Einflussfaktoren, während Fault Tree Analysis komplexe technische Abhängigkeiten und mögliche Fehlerpfade untersucht. Für organisatorische Probleme können Prozessmapping, Timeline-Analyse, Datenvergleich und moderierte Lessons-Learned-Workshops sinnvoller sein als eine rein technische Methode.
Eine gute Ursachenanalyse trennt Beobachtung, Hypothese, Nachweis und Entscheidung. „Server war überlastet“ ist zunächst nur eine Beobachtung. Erst Messdaten, Konfigurationsänderungen, reproduzierbare Tests und der Vergleich mit einem stabilen Zustand machen daraus eine belastbare Ursache. Der Abschluss sollte zudem prüfen, ob die Maßnahme tatsächlich wirksam war und keine neuen Nebenwirkungen erzeugt hat.
Ancud IT kann Root-Cause-Workshops moderieren, Vorlagen entwickeln lassen und ein standardisiertes Analyseverfahren einführen. Bei komplexen Fällen lässt sich die technische Analyse beauftragen; für wiederkehrende Themen kann ein Unternehmen einen Service anfragen, der Problem Reviews, Maßnahmenverfolgung und Management-Berichte kombiniert.
OTRS Problem Management, TOPdesk Problem Management und andere Tools
Suchanfragen wie OTRS Problem Management und TOPdesk Problem Management zeigen, dass viele Organisationen den Prozess ausgehend vom vorhandenen Tool betrachten. Entscheidend ist jedoch nicht allein, welche Maske verfügbar ist. Das Werkzeug muss Incident-Verknüpfungen, Problem Records, Known Errors, Workarounds, Prioritäten, Verantwortlichkeiten, Changes, Wissensartikel und Reporting in einem nachvollziehbaren Ablauf unterstützen.
Vor dem Kauf sollte geprüft werden, welche Funktionen bereits vorhanden sind, welche Konfiguration ausreicht und wo Integrationen nötig werden. Unternehmen können ein bestehendes Tool optimieren lassen, eine neue Lösung kaufen oder einen strukturierten Auswahlprozess beauftragen. Ein Toolvergleich sollte Lizenzmodell, Preise, Kosten für Implementierung, Datenmigration, Schnittstellen, Schulung, Support und Wartung berücksichtigen. Der niedrigste Preis führt nicht automatisch zu den niedrigsten Gesamtkosten.
Für OTRS, TOPdesk oder andere IT-Service-Management-Plattformen kann Ancud IT Workflows, Formulare, Rollen, Dashboards und KEDB-Verknüpfungen entwickeln lassen. Unternehmen können einen Konfigurationsworkshop anfragen, einen Pilot bestellen oder die vollständige Umsetzung beauftragen. Nach dem Go-live lassen sich Administration und Datenqualität betreuen lassen, ein Service anfragen und Wartung buchen.
ITIL Problem, Incident Problem und ITIL Bug fachlich einordnen
Die Suchbegriffe ITIL Problem, Incident Problem und ITIL Bug werden häufig synonym verwendet, bezeichnen fachlich aber unterschiedliche Dinge. Ein Problem ist die Ursache oder potenzielle Ursache eines oder mehrerer Incidents. Ein Incident ist eine ungeplante Unterbrechung oder Qualitätsminderung eines Services. Ein Bug ist ein Fehler in Software oder Konfiguration und kann eine Problemursache sein, muss aber nicht automatisch einen sichtbaren Incident erzeugen.
Für die Praxis ist die Abgrenzung wichtiger als die Bezeichnung. Ein Softwarefehler kann als Defect im Entwicklungssystem geführt, als Problem im IT-Service-Management bewertet und über einen Change produktiv behoben werden. Verknüpfte IDs und klare Statusübergänge verhindern doppelte Dokumentation. Wer diese Übergaben standardisieren möchte, kann Schnittstellen entwickeln lassen und den Workflow gemeinsam mit IT-Betrieb und Entwicklung umsetzen lassen.
Kennzahlen und Reporting für Problem Management
Ein reifer Prozess wird nicht an der Zahl geschlossener Problem Records gemessen. Wichtiger sind die Reduktion wiederkehrender Incidents, die Qualität von Workarounds, die Dauer bis zur bestätigten Ursache, der Anteil überfälliger Maßnahmen und die Wirksamkeit umgesetzter Changes. Auch offene Risiken ohne wirtschaftlich sinnvolle Dauerlösung müssen transparent berichtet werden.
- Anzahl neu erkannter Probleme nach Quelle und Priorität
- Anteil der Probleme mit bestätigter Ursache und freigegebenem Workaround
- Zahl verknüpfter Incidents und kumulierter Bearbeitungsaufwand je Problem
- Durchlaufzeit von Erfassung bis Ursache, Change und Wirksamkeitsprüfung
- Wiederholungsrate nach Umsetzung der dauerhaften Maßnahme
- Offene Risiken, akzeptierte Known Errors und überfällige Reviews
Dashboards sollten unterschiedliche Zielgruppen bedienen. Resolver-Teams benötigen technische Arbeitslisten, der Problem Manager Prioritäten und Fristen, Service Owner Auswirkungen auf Services und das Management Trends, Risiken und Nutzen. Reports können im vorhandenen Tool konfiguriert oder individuell entwickelt werden. Unternehmen können ein Reporting-Paket beauftragen und regelmäßige Reviews als laufenden Service betreuen lassen.
Preise und Kosten einer Problem-Management-Einführung
Die Kosten hängen von Prozessreife, Zahl der Services, Ticket-System, Datenqualität, Integrationen, Rollenmodell und gewünschtem Betriebsumfang ab. Ein kompakter Workshop hat einen anderen Preis als eine vollständige Einführung mit Toolkonfiguration, KEDB-Aufbau, Schulung, Dashboards und Betriebsbegleitung. Transparente Preise trennen deshalb Analyse, Konzeption, technische Umsetzung und laufende Leistungen.
Für eine erste Kostenschätzung reichen Angaben zu Incident-Volumen, wiederkehrenden Störungen, eingesetztem Tool, vorhandenen Problem Records, beteiligten Teams und gewünschten Zielen. Danach lassen sich einmalige Kosten und laufende Preise nachvollziehbar abgrenzen. Unternehmen können eine Analyse anfragen, die Einführung beauftragen oder zunächst einen Pilot bestellen. Über Problem-Management-Beratung anfragen erhalten Sie eine projektspezifische Einschätzung.
Rollout in sechs kontrollierten Schritten
- Bestandsaufnahme: Incident-Daten, Rollen, Tools, bekannte Ursachen, Workarounds und bestehende Reports bewerten.
- Zielbild: Scope, Trigger, Prioritäten, Statusmodell, Verantwortlichkeiten und Eskalationen definieren.
- Pilot: Einen kritischen Service oder eine wiederkehrende Störung vollständig durch den neuen Prozess führen.
- Tooling: Formulare, Verknüpfungen, KEDB, Dashboards und Change-Übergaben konfigurieren.
- Schulung: Service Desk, Resolver-Teams, Problem Manager und Service Owner anhand realer Fälle trainieren.
- Betrieb: Regelmäßige Reviews, Kennzahlen, Wirksamkeitsprüfungen und Continual Improvement etablieren.
Dieser Ablauf lässt sich vollständig beauftragen oder in klar abgegrenzte Arbeitspakete teilen. Unternehmen können das Zielbild anfragen, den Pilot umsetzen lassen, Tool-Anpassungen entwickeln lassen und den späteren Betrieb intern übernehmen. Alternativ kann Ancud IT den Prozess betreuen lassen, regelmäßige Problem Reviews durchführen und die Weiterentwicklung als Service übernehmen.
Welche Angaben für ein Angebot benötigt werden
Für ein belastbares Angebot sind Anzahl und Kritikalität der Services, monatliches Incident-Volumen, wichtigste Wiederholfälle, Ticket-System, vorhandene KEDB, Rollen, Reporting-Anforderungen und gewünschter Projektumfang relevant. Zusätzlich sollte geklärt werden, ob nur der Prozess konzipiert, das Tool angepasst oder auch der laufende Betrieb übernommen werden soll.
Auf dieser Basis können Sie eine Beratung anfragen, den Prozessaufbau beauftragen, einen Workshop bestellen, die Toolkonfiguration umsetzen lassen oder eine individuelle Integration entwickeln lassen. Für den Regelbetrieb können Unternehmen Support beauftragen, einen Service anfragen, die laufende Pflege betreuen lassen oder Wartung buchen. Die Antworten unter Häufige Fragen zu Problem Management fassen zusätzliche Entscheidungen kompakt zusammen.
Was ist Problem Management?
Ein Problem ist nach ITIL 4 die Ursache eines oder mehrerer Incidents – oder eines Incidents, der potenziell noch auftreten könnte. Problem Management analysiert diese Ursachen systematisch, statt Symptome immer wieder neu zu behandeln. Ziel ist es, die Anzahl und die Auswirkung künftiger Störungen spürbar zu senken. Die offizielle ITIL-4-Practice-Guide zu Problem Management beschreibt dazu Werteströme, Rollen und die Schnittstellen zu anderen Practices im Detail.
In der Praxis scheitert Problem Management selten an der Methodik, sondern an der Organisation: Ohne feste Verantwortlichkeit bleibt die Ursachenanalyse ein Nebenprojekt, das im Tagesgeschäft untergeht. Unternehmen, die den Prozess neu einführen, sollten deshalb zuerst klären, wer Probleme priorisiert und wer die Zeit für Root-Cause-Analysen tatsächlich bekommt – bevor Tools oder Vorlagen ausgewählt werden.
Incident vs. Problem
Ein Beispiel macht den Unterschied greifbar: „SAP-Login dauert 30 Sekunden“ ist ein Incident – eine konkrete, spürbare Störung, die der Service Desk sofort bearbeitet. Die Ursache dahinter, etwa überlastete Datenbank-Indizes, ist das Problem. Incidents werden schnell entschärft, Probleme dagegen gründlich analysiert – meist zeitversetzt und ohne den Druck einer laufenden Störung.
Reaktives vs. proaktives Problem Management
Reaktives Problem Management entsteht aus der Incident-Historie: Häufen sich Tickets zum gleichen Thema, wird daraus ein eigener Problem-Datensatz. Proaktives Problem Management dreht die Reihenfolge um – es wertet Monitoring-Trends, Herstellerwarnungen oder Lessons-Learned-Reviews aus, um Ursachen zu finden, bevor überhaupt ein Incident entsteht. In der Praxis funktioniert meist nur die Kombination aus beidem: reaktiv für akute Wiederholfälle, proaktiv für Themen, die sich langsam anbahnen, etwa wachsende Log-Dateien oder auslaufende Zertifikate.
Ein typisches Beispiel für proaktives Vorgehen: Ein Softwarehersteller meldet eine bekannte Schwachstelle in einer eingesetzten Komponente. Statt zu warten, bis daraus ein Incident wird, prüft das Problem-Management-Team, wo die Komponente im Einsatz ist, und plant die Behebung, bevor Nutzer überhaupt etwas bemerken. Reaktives Problem Management dagegen beginnt fast immer mit einer einfachen Beobachtung im Service Desk: Dieselbe Fehlermeldung taucht innerhalb weniger Wochen zum dritten Mal auf.
Der Problem-Management-Prozess
Der Prozess gliedert sich in fünf Schritte, die inhaltlich aufeinander aufbauen, auch wenn sie in der Praxis nicht immer streng nacheinander ablaufen.
Erkennung und Erfassung
Ein Problem entsteht aus wiederkehrenden Incidents, aus proaktiver Trendanalyse oder aus Hinweisen des Störungsmanagements. Der BSI-Baustein zur Behandlung von Sicherheitsvorfällen zeigt, dass sicherheitsrelevante Vorfälle hier eine eigene, strengere Betrachtung brauchen.
Kategorisierung und Priorisierung
Probleme werden nach Auswirkung und Häufigkeit priorisiert, nicht nach dem Datum ihrer Entdeckung. Ein Problem, das monatlich fünf Incidents auslöst, hat Vorrang vor einem seltenen Randfall – selbst wenn Letzterer optisch dringlicher wirkt.
Ursachenanalyse (Root Cause Analysis)
Hier kommen strukturierte Methoden wie 5 Whys, Ishikawa oder Fault Tree Analysis zum Einsatz – mehr dazu im nächsten Abschnitt. Ziel ist eine belastbare, dokumentierte Ursache statt einer Vermutung.
Behebung über den Change-Prozess
Ist die Ursache bekannt, aber noch nicht behoben, wird das Problem zum Known Error: Ursache, Workaround und Status werden in der Known Error Database festgehalten, damit der Service Desk sofort darauf zugreifen kann.
Behebung über den Change-Prozess
Die endgültige Beseitigung eines Problems erfordert fast immer einen Eingriff an Systemen oder Konfiguration – und läuft deshalb über den Change-Prozess. Problem Management liefert die fachliche Begründung, das Change-Team plant und autorisiert die Umsetzung.
Methoden der Ursachenanalyze
Welche Methode passt, hängt von der Komplexität des Problems ab. Für den Alltag reichen meist einfache, schnell anwendbare Ansätze.
5 Whys
Fünfmal „Warum?“ fragen, bis die eigentliche Ursache statt nur des Symptoms sichtbar wird. Beispiel: Warum schlägt der Batch-Job fehl? – Speicher voll. Warum? – Log-Rotation läuft nicht. Warum? – Cronjob wurde bei einem Systemupdate gelöscht. Für einfache, lineare Ursachenketten die schnellste Methode.
Ishikawa-Diagramm
Auch Fischgräten-Diagramm genannt: Ursachen werden nach den 6M-Kategorien sortiert – Mensch, Maschine, Methode, Material, Mitwelt, Messung. Geeignet, wenn mehrere Einflussfaktoren gleichzeitig infrage kommen und eine reine Warum-Kette zu kurz greift.
Fault Tree Analysis
Ein Fehlerbaum modelliert, welche Kombinationen von Teilausfällen zu einem Gesamtausfall führen können. Aufwendiger als 5 Whys, aber notwendig bei komplexen, sicherheitskritischen Systemen mit mehreren redundanten Komponenten.
Die Known Error Database (KEDB)
Die KEDB ist der zentrale Anwendungsfall von Wissensmanagement im Problem Management: Für jeden Known Error werden Symptom, Ursache, Workaround und aktueller Status dokumentiert. Gepflegt wird sie vom Problem Manager gemeinsam mit den Resolver-Teams, genutzt wird sie vom Service Desk – im Idealfall direkt bei der Erstannahme eines Incidents, bevor überhaupt eskaliert werden muss. Eine KEDB, die niemand pflegt, verliert innerhalb weniger Monate ihren Nutzen; deshalb sollte ein fester Review-Rhythmus Teil des Prozesses sein. In kleineren Teams reicht dafür oft eine einfache, gut strukturierte Tabelle in der bestehenden Wissensplattform – ein dediziertes Tool lohnt sich meist erst, wenn Verknüpfungen zu Configuration Items oder eine automatische Vorschlagsfunktion im Ticket dazukommen sollen.
Wer diese Rollen neu aufsetzt, bündelt das meist mit dem größeren Vorhaben, Service Desk und Incident-Prozess insgesamt zu strukturieren. Unsere ITSM-Beratung übernimmt dabei Rollenkonzept, KEDB-Aufbau und Schulung als ein zusammenhängendes Projekt statt vieler isolierter Einzelmaßnahmen.
Rollen im Problem Management
Problem Management braucht keine eigene Abteilung, aber klar zugeordnete Verantwortung. In den meisten mittelständischen Organisationen übernimmt eine Person die Rolle des Problem Managers zusätzlich zu anderen Aufgaben – wichtig ist, dass diese Zeit im Kalender auch tatsächlich eingeplant ist und nicht ständig hinter akuten Incidents zurücksteht.
Problem Manager
Koordiniert den gesamten Prozess, priorisiert offene Probleme, pflegt die KEDB und ist Schnittstelle zum Change Management.
Resolver-Teams
2nd- und 3rd-Level-Spezialisten oder Fachabteilungen, die die eigentliche Ursachenanalyse durchführen und Lösungsvorschläge liefern.
Service Desk
Erkennt Muster im Incident-Prozess nach ITIL zuerst, meldet Verdachtsfälle an Problem Management und nutzt später die KEDB im Tagesgeschäft.
Kennzahlen
- Anzahl identifizierter Probleme – zeigt, wie konsequent Ursachen überhaupt erfasst werden.
- Anzahl gelöster Probleme – Verhältnis zu neu erfassten Problemen zeigt, ob der Backlog wächst oder schrumpft.
- Durchschnittliche Time-to-Resolve – von Erfassung bis endgültiger Behebung über den Change.
- Reduktion wiederkehrender Incidents – die eigentliche Erfolgsmessung: weniger Tickets zum gleichen Thema im Zeitverlauf.
Diese letzte Kennzahl hängt direkt an der Umsetzungsgeschwindigkeit im Change Management: Eine sauber analysierte Ursache bringt wenig, wenn der zugehörige Change monatelang liegen bleibt. Deshalb lohnt es sich, Problem- und Change-Kennzahlen gemeinsam zu betrachten, statt beide Prozesse getrennt zu berichten. Ein realistischer Richtwert für eingeführte Teams: Zwischen Known-Error-Status und produktivem Fix vergehen selten weniger als zwei, oft mehrere Change-Zyklen – das ist normal und kein Zeichen für einen schlechten Prozess, solange die Priorisierung stimmt.
Wiederkehrende Störungen ohne erkennbare Ursache?
Wir helfen, Problem Management strukturiert einzuführen – von der Rollenverteilung über die KEDB bis zur Verzahnung mit Ihrem Change-Prozess. Für eine belastbare Einschätzung Ihrer aktuellen Prozessreife bieten wir eine unverbindliche Beratung zur ITIL-Einführung an.
Häufige Fragen zu Problem Management nach ITIL
Was ist der Unterschied zwischen Incident und Problem Management?
Incident Management stellt den betroffenen Service schnell wieder her. Problem Management untersucht die Ursache oder potenzielle Ursache wiederkehrender beziehungsweise bedeutender Incidents. Ein Incident kann geschlossen sein, während das zugehörige Problem weiter analysiert wird. Die Prozesse sollten über verknüpfte Tickets und freigegebene Workarounds miteinander verbunden sein; Details zeigt das Incident Management.
Was ist ein ITIL Problem?
Ein ITIL Problem ist die Ursache oder potenzielle Ursache eines oder mehrerer Incidents. Der Problem Record dokumentiert Auswirkungen, Hypothesen, Analyse, bekannte Ursache, Workaround, Risiken und geplante dauerhafte Maßnahmen. Das übergeordnete ITIL-Framework ordnet Problem Management in die übrigen Service-Management-Practices ein.
Was macht ein Problem Manager nach ITIL?
Die Suchphrase Problem Manager ITIL bezeichnet die Rolle, die Erfassung, Priorisierung, Ursachenanalyse, KEDB-Pflege, Maßnahmenverfolgung und Reporting koordiniert. Technische Ursachen werden gewöhnlich von Resolver-Teams untersucht. Ein klares Rollenmodell kann über eine ITSM-Beratung entwickelt und eingeführt werden.
Was ist proaktives Problem Management?
Proaktives Problem Management analysiert Trends, Events, Kapazitätsdaten, Security Findings und Herstellerinformationen, bevor ein sichtbarer Incident entsteht. Reaktives Problem Management startet dagegen nach bereits eingetretenen Störungen. Beide Varianten benötigen dieselbe Priorisierung, Dokumentation und Wirksamkeitskontrolle.
Was gehört in eine Known Error Database (KEDB)?
Eine KEDB enthält Symptom, betroffene Services, bekannte Ursache, freigegebenen Workaround, Risiken, Gültigkeit, Verantwortliche und Status der dauerhaften Behebung. Die Einträge sollten versioniert und regelmäßig überprüft werden. Die Verbindung zum Wissensmanagement macht Workarounds für den Service Desk schnell auffindbar.
Welche Methoden eignen sich für die Root Cause Analysis?
Für einfache Ursachenketten eignet sich 5 Whys. Ishikawa strukturiert mehrere Einflussfaktoren, während Fault Tree Analysis komplexe technische Fehlerpfade untersucht. Ergänzend können Timeline-Analyse, Datenvergleich, Prozessmapping und moderierte Lessons Learned eingesetzt werden. Entscheidend sind überprüfbare Nachweise statt bloßer Vermutungen.
Was bedeuten ITIL Bug und Incident Problem?
Die Begriffe ITIL Bug und Incident Problem sind verbreitete Suchkombinationen, aber keine identischen Objekte. Ein Bug ist ein Software- oder Konfigurationsfehler. Ein Incident ist die konkrete Servicebeeinträchtigung; ein Problem ist deren Ursache oder potenzielle Ursache. Die dauerhafte Behebung läuft häufig über den Change-Prozess.
Wie funktioniert OTRS Problem Management?
OTRS Problem Management sollte Incident-Verknüpfungen, Problem Records, Known Errors, Workarounds, Verantwortlichkeiten, Changes und Reporting unterstützen. Vor einer Konfiguration werden Prozess, Pflichtfelder, Status und Rollen festgelegt. Ancud IT kann einen OTRS-Workflow prüfen und die Umsetzung über eine ITSM-Beratung begleiten.
Wie unterstützt TOPdesk Problem Management?
TOPdesk Problem Management kann wiederkehrende Incidents bündeln, Ursachenanalysen dokumentieren und Known Errors sowie Changes verknüpfen. Der Nutzen hängt von sauberer Kategorisierung, klaren Triggern und regelmäßigen Reviews ab. Ein Tool allein ersetzt weder Problem Manager noch Resolver-Kapazität.
Was kostet die Einführung von Problem Management?
Preis und Kosten richten sich nach Incident-Volumen, Prozessreife, Tool, Zahl der Services, Integrationen, Schulungsbedarf und gewünschtem Betrieb. Nach einer Bestandsaufnahme lassen sich einmalige Projektkosten und laufende Preise trennen. Eine individuelle Kostenschätzung anfragen schafft eine belastbare Grundlage.
Wann lohnt sich ein eigener Problem-Management-Prozess?
Ein strukturierter Prozess lohnt sich, sobald dieselben Incidents und Workarounds wiederholt auftreten, Major Incidents ohne nachhaltige Ursachenbeseitigung geschlossen werden oder technische Risiken nicht systematisch verfolgt werden. Der Einstieg kann auf einen kritischen Service begrenzt und anschließend anhand messbarer Ergebnisse erweitert werden.
Kann Ancud IT Problem Management einführen und betreiben?
Ja. Ancud IT kann Bestandsaufnahme, Zielbild, Rollen, Problem Records, KEDB, Toolkonfiguration, Reporting, Schulung und Rollout im Auftrag übernehmen. Der Betrieb kann intern erfolgen oder als Service betreut werden. Über Problem Management anfragen lässt sich der gewünschte Leistungsumfang abgrenzen.