Problem Identification

Aus Wiki Itil

Es gibt immer verschiedene Wege, Probleme zu identifizieren, aber die häufigsten Szenarien sind:

• Verdacht oder Feststellung einer unbekannten zugrunde liegenden Ursache eines oder mehrerer Incidents durch den Service Desk, resultierend in ein Problem-Ticket – der Service Desk mag zwar den Incident lösen, hat aber keine definitive Ursache festgestellt und vermutet, dass es wahrscheinlich ist, dass sich dieser wiederholt. Somit wird er ein Problem-Ticket öffnen (lassen), damit die zugrunde liegende Ursache erforscht wird. Alternativ können durch globale Probleme auch weitere Incidents entstehen – somit würde auch ein Problem-Ticket ohne jeglichen Zeitverzug eröffnet werden.
• Die Analyse eines oder mehrerer Incidents durch eine (technische) Support-Gruppe ergibt, dass hier ein Problem zugrunde liegt oder zugrunde liegen könnte.
• Automatisierte Entdeckung eines Infrastruktur- oder Applikationsfehlers durch entsprechende Event-/Alarm-Tools, die automatisch ein Incident- oder Problem-Ticket erstellen.
• Benachrichtigung eines externen Lieferanten oder Vertragspartners, dass ein Problem existiert, das gelöst werden sollte.
• Die Analyse von Incidents als Teil des proaktiven Problem Management – mit dem Ziel, Probleme im Voraus zu entdecken und die zugrunde liegende Ursache zu erforschen. Hierdurch werden weitere Incidents proaktiv verhindert. Häufige und regelmäßige Analysen von Incident- und Problem-Daten müssen vorgenommen werden, damit jegliche Form von Trends identifiziert wird, sobald sie wahrscheinlich wird. Dies erfordert aussagekräftige und detaillierte Kategorisierungen der Incidents / Probleme und regelmäßiges Reporting von Mustern und Zonen mit hohen Auftrittswahrscheinlichkeiten. „Top Ten“-Reportings mit der Möglichkeit, in niedrigeren Levels nachzuforschen, sind bei der Identifizierung von Trends sehr hilfreich. Weitere Details, wie mit entdeckten Trends umgegangen werden soll, sind im Continual Service Improvement enthalten.