Prozessablauf des Problem Managements
Wie funktioniert Problem Management? ITIL Problem Management geht über die bloße Lösung von Incidents hinaus – es berücksichtigt den gesamten Lebenszyklus eines Problems. Der Prozessablauf des Problem-Management-Lebenszyklus kann so strukturiert werden, dass er Probleme verwaltet, die zunächst von Benutzern oder Service-Desk-Technikern als Incidents gemeldet werden – über ein Self-Service-Portal, telefonisch, per E-Mail oder persönlich – sowie potenzielle Probleme, die automatisch von ITSM-Mitarbeitern oder -Technologie erkannt werden, bevor ein Incident auftritt. Der Umfang des Problem-Management-Prozessablaufs umfasst:
1) Problemerkennung
Probleme können auf verschiedene Weise erkannt werden, unter anderem als Ergebnis eines Incident-Berichts, einer laufenden Incident-Analyse, einer automatischen Erkennung durch ein Event-Management-Tool oder einer Lieferantenbenachrichtigung. Ein Problem wird häufig erkannt, wenn die Ursache eines oder mehrerer beim Service-Desk gemeldeten Incidents unbekannt ist. Es ist möglich, dass der Service-Desk den Incident gelöst hat und er erneut auftreten kann, die zugrundeliegende Ursache jedoch unbekannt ist – in diesem Fall wird ein Problem-Datensatz erstellt. In anderen Fällen kann es für den Service-Desk offensichtlich sein, dass ein gemeldeter Incident mit einem Problem zusammenhängt. Dieses Problem wurde möglicherweise bereits erfasst – bekanntes Problem – und der Incident kann mit dem bestehenden Problem-Datensatz verknüpft werden. Wurde das Problem noch nicht erfasst, sollte unverzüglich ein Problem-Datensatz erstellt werden, um die Service-Performance sicherzustellen.
2) Problemprotokollierung
Um eine vollständige historische Aufzeichnung zu gewährleisten, müssen alle Probleme – unabhängig von der Methode ihrer Identifizierung und Meldung beim Service-Desk – mit allen relevanten Details protokolliert werden, einschließlich Datum/Uhrzeit, Benutzerinformationen, Beschreibung, zugehörigem Configuration Item aus der CMDB, verknüpften Incidents, Lösungsdetails und Abschlussinformationen.
- Kategorisierung – Nach der Protokollierung müssen alle geeigneten Kategorien ausgewählt werden, um Häufigkeiten und Problemtrends korrekt zuzuweisen, zu eskalieren und zu überwachen.
- Priorisierung – Die Zuweisung von Prioritäten ist entscheidend dafür, wie und wann das Problem vom Personal bearbeitet wird. Sie wird durch die Auswirkung bestimmt – die Anzahl der verknüpften Incidents, die Aufschluss über die Anzahl der betroffenen Benutzer oder die Auswirkungen auf das Unternehmen geben kann. Darüber hinaus wird die Dringlichkeit des Problems – wie schnell eine Lösung erforderlich ist – berücksichtigt, um die Priorität festzulegen.
3) Untersuchung und Diagnose
Eine Untersuchung der Grundursache des Problems wird auf der Grundlage der Auswirkung, des Schweregrads und der Dringlichkeit des betreffenden Problems durchgeführt. Gängige Untersuchungstechniken umfassen die Überprüfung der Known-Error-Datenbank (KEDB), um übereinstimmende Probleme und Lösungen zu finden, und/oder die Reproduktion des Fehlers zur Bestimmung der Ursache.
4) Workaround
In einigen Situationen ist es möglich, dem Benutzer, der den mit dem Problem zusammenhängenden Incident erlebt, eine vorübergehende Lösung oder einen Workaround bereitzustellen. Es ist jedoch wichtig, eine dauerhafte Änderungslösung für den vom Problem Management erkannten zugrundeliegenden Fehler anzustreben.
5) Bekannten-Fehler-Datensatz erstellen
Sobald die Untersuchung und Diagnose abgeschlossen ist, ist es wichtig, einen Known-Error-Datensatz zu erstellen. Sollten zukünftig Incidents oder Probleme auftreten, kann der untersuchende Service-Desk-Techniker mithilfe der Known-Error-Datenbank (KEDB) und der zugehörigen Workarounds schneller eine Lösung identifizieren und bereitstellen.
6) Lösung
Nach der Lösung kann die Fehlerbehebung über das standardmäßige Change-Verfahren implementiert und getestet werden, um die Service-Wiederherstellung zu bestätigen. Wenn jedoch eine normale Änderung erforderlich war, wird ein zugehöriger Request for Change (RFC) erstellt und genehmigt, bevor eine Lösung auf das Problem angewendet wird.
7) Abschluss
Nach der Bestätigung, dass der Fehler behoben wurde, können das Problem und alle zugehörigen Incidents geschlossen werden. Der Service-Desk-Techniker sollte sicherstellen, dass die ursprünglichen Klassifizierungsdetails für zukünftige Referenz und Berichterstattung korrekt sind.
- Major-Problem-Review – Major-Probleme werden durch die Business-Impact-Analyse (BIA) und Risikobewertung (RA) einer Organisation definiert, um Reaktion und Priorität (Auswirkung, Dringlichkeit und Schweregrad des Problems) zu bestimmen. Das Ziel eines Major-Problem-Reviews ist die kontinuierliche Verbesserung des Problem-Management-Prozesses bei der Reaktion auf schwerwiegende Geschäftsprobleme. Ein Überprüfungsprozess kann Dinge identifizieren, die korrekt durchgeführt wurden, Dinge, die fehlerhaft durchgeführt wurden, was verbessert werden kann, zusätzliche Risiken, wie ein erneutes Auftreten verhindert werden kann und die Art der Verantwortung etwaiger Dritter. Diese Überprüfung sollte nicht isoliert stattfinden, sondern im Rahmen von Schulungs- und Sensibilisierungssitzungen mit Teammitgliedern geteilt werden.
- Problem Control und Error Control – In einigen Situationen können die Begriffe Problem Control und Error Control während des Problem-Management-Lebenszyklus verwendet werden. Problem Control kann in die Untersuchungsphase einbezogen werden mit dem Ziel, die Grundursache des Problems zu finden und es in einen bekannten Fehler umzuwandeln. Dies hilft dem Service-Desk-Techniker, dem Benutzer vorübergehende Workarounds bereitzustellen. Error Control hingegen ist Teil der Lösungsphase mit dem Ziel, bekannte Fehler in Lösungen umzuwandeln und sie bei Bedarf aus der Known-Error-Datenbank (KEDB) zu entfernen.