Information Technology Reference
In-Depth Information
Problem-Aufzeichnung (Problem logging)
Alle für die Bearbeitung des Problems relevanten Daten werden im Problem Record erfasst
und während der Bearbeitung regelmäßig aktualisiert. Im Ticketsystem wird ein Bezug zwi-
schen dem Problem-Record und den Incidents, dessen Ursache es ist, erstellt.
Kategorisierung (Problem categorization)
Um die Problems adäquat zu bearbeiten und Mitarbeiter mit dem entsprechenden Know-
how für die Bearbeitung auswählen zu können, müssen diese ähnlich wie die Incidents
kategorisiert werden.
Priorisierung (problem priorization)
Ähnlich dem Incident-Management-Prozess werden Problems priorisiert, um die Reihenfolge
und Geschwindigkeit der Bearbeitung entsprechend den erwarteten Auswirkungen und der
Dringlichkeit zu steuern. Insbesondere für die Bewertung der Auswirkungen von Problems
spielen die Häuigkeit und die Auswirkungen der betrofenen Incidents eine wichtige Rolle.
untersuchung und Diagnose (Investigation and diagnosis)
In diesem Prozessschritt werden die entsprechend der Kategorie und der Priorität benötigten
Fähigkeiten und Ressourcen zusammengestellt und die Ursache für das jeweilige Problem
(ot auch „root cause“ genannt) diagnostiziert. Diese Phase bringt je nach Anforderung die
in Abschnitt 4.3.8.2 vorgestellten Methoden zum Einsatz. Ein nützliches Hilfsmittel für die
Diagnose ist das CMS, aus dem sich die Zusammenhänge zwischen Services und Coniguration
Items sowie die Abhängigkeiten der Services untereinander ablesen lassen.
Ot inden sich während der Diagnose von Problems Hinweise auf Möglichkeiten zur Ver-
meidung von Auswirkungen der auf dem behandelten Problem basierenden Incidents. Diese
Workarounds werden erfasst, deiniert und im Problem Record sowie anschließend in der
Known Error Database dokumentiert.
Known Error dokumentieren (raising a known error)
Wird während der Diagnose ein Workaround identiiziert, so wird dieser in der Known Error
Database dokumentiert und steht anderen Prozessen wie dem Incident Management zur
Verfügung. Der Workaround kann als vorübergehende Lösung genutzt werden, solange noch
keine Lösung zur Behebung des Problems gefunden ist.
Praxistipp:
In vielen Fällen ist die Known Error Database keine eigenständige Datenbank,
sondern wird über das vorhandene Ticketsystem mit Hilfe eines Status „Known
Error“ für den jeweiligen Problem Record realisiert. Moderne Ticket-Tools arbeiten
wie Datenbanken und erlauben es, Known Errors über den Status der Problem
Records zu identiizieren und anderen Prozessen (insbesondere dem Incident
Management) zur Verfügung zu stellen.
 
Search WWH ::




Custom Search