Incident Record - Checkliste

 

Abb. 1: Incident Record
(YaSM-Checkliste / Dokument-Vorlage)

Definition: Ein Incident Record ist ein Datensatz mit allen Angaben zu einem Service Incident, in dem der Verlauf des Incidents von der Ersterfassung bis zur Schließung dokumentiert ist. Ein Service Incident ist definiert als ungeplante Unterbrechung oder Qualitätsminderung eines Service. Auch ein Ereignis, das in der Zukunft einen Service beeinträchtigen könnte, wird als Incident behandelt (z.B. der Ausfall einer Festplatte in einem Satz gespiegelter Festplatten).

Verbundener YaSM Service-Management-Prozess: Lösen von Incidents und Service Requests

Weitere Checklisten und Dokument-Vorlagen: Service-Management-Checklisten

 

Ein Incident Record enthält üblicherweise die folgenden Informationen:

 

Incident Record - Inhalte

Inhalt	Beschreibung
Eindeutige Incident-ID	In der Regel wird die ID automatisch von der Anwendung vergeben, die zum Managen der Incidents verwendet wird.
Status des Incidents	Statuswerte können beispielsweise sein: "Gemeldet", "Offen", "Behoben", "Abgeschlossen" usw.
Erfassung des Incidents	Datum und Zeitpunkt der Erfassung des Incidents.
Auftreten des Incidents	Datum und Zeitpunkt, wann der Incident aufgetreten ist.
Art der Benachrichtigung	Z.B. per Telefon, E-Mail, Intranet-Portal, Event-Überwachungs-System.
Kontaktdaten	Kontaktdaten des Melders / Anwenders und Kommunikationsweg für Rückmeldungen.
Angaben zur Berechtigung	Gegebenenfalls Angaben darüber, wie festgestellt wurde, dass der Anfordernde die Berechtigung hat, den Incident zu melden.
Verantwortlich (Incident-Owner)	Der / die Incident-Verantwortliche trägt die Gesamtverantwortung für die Behebung des Incidents, selbst wenn dieser im Verlauf seines Lebenszyklus anderen Support-Mitarbeitern oder -Teams zur Durchführung bestimmter Aufgaben übertragen wird.
Zuordnung	Mitarbeiter(in) oder Support-Team, dem der Incident zugeordnet ist. Der Incident kann im Verlauf seines Lebenszyklus unterschiedlichen Personen oder Teams zugewiesen werden.
Klassen bzw. Kategorien	Die Klassifizierung von Incidents ist eine Möglichkeit, Incidents in Kategorien einzuteilen. Dies erleichtert zum einen ihre Zuordnung zu den richtigen Support-Mitarbeitern bzw. -Teams und zum anderen die Erstellung von Statistiken sowie die Analyse aufgetretener Incidents. Das verwendete Klassifikationsschema kann je nach Organisation unterschiedlich sein, aber oft werden Incidents z.B. nach folgenden Kriterien klassifiziert: betroffene(r) Service(s) betroffene(r) Kunde(n) betroffene(r) Standort(e) betroffene Infrastruktur-Komponente(n) und Sub-Komponente(n) (d.h. Konfigurationselemente) Art von Symptom (z.B. "Hardware-Fehler", "Software-Fehler", "verminderte Leistung", "Sicherheitsproblem" usw.).
Symptome	Symptom-Beschreibung.
Priorisierung	Die Incident-Priorität wird häufig durch Prioritäts-Codes ausgedrückt, wie z.B. "Kritisch", "Hoch", "Mittel", "Niedrig", "Sehr niedrig"). Die Priorität ergibt sich aus der Kombination von Dringlichkeit und Auswirkung, wobei Dringlichkeit die verfügbare Zeit bis zur Lösung des Problems und Auswirkung den (potentiellen) Schaden für das Unternehmen ausdrückt. Ein Beispiel für ein Priorisierungsschema finden Sie in der Checkliste "Incident und Service-Request-Richtlinie". Für wiederholt auftretende Incidents sind die Priorisierungsregeln üblicherweise in den entsprechenden Incident-Modellen beschrieben bzw. konfiguriert.
Kennzeichnung als Major Incident	Diese Kennzeichnung gibt an, dass ein Incident als Major Incident (d.h. schwerwiegender) behandelt wird.
Zeitvorgabe für die Behebung des Incidents	Dies ist die vorgegebene Zeitspanne, die zur Lösung des Incidents gemäß Zusagen in den entsprechenden Service-Definitionen und ‑Vereinbarungen zur Verfügung steht. Soll-Lösungszeiten werden in der Regel anhand der Priorität des Incidents festgelegt.
Incident-Modell(e)	Anwendbare(s) Incident-Modell(e).
Links zu anderen Records	Links zu anderen relevanten Incident Records: Falls es ähnliche noch nicht behobene Incidents gibt, auf die der neue Incident zurückgeführt werden kann; in diesem Fall wird einer der Incidents üblicherweise als "Master-Incident" deklariert. Links zu relevanten Event Records: Falls der Incident auf einem Event beruht, der von einem Monitoring-System gemeldet worden ist. Links zu relevanten Problem Records: Falls es Problems gibt, die mit dem vorliegenden Incident zusammenhängen; insbesondere kann ein Problem Record einen geeigneten Workaround enthalten. Links zu relevanten Change Records: Falls während der Lösung des Incidents Requests for Change eingereicht wurden. Falls der Incident mit einem (kürzlich implementierten) Change in Zusammenhang steht.
Eskalation	Funktionale Eskalationen: Funktionale Eskalationen (Weiterleitungen des Incidents an bestimmte Support-Mitarbeiter oder Teams von Spezialisten) müssen aufgezeichnet werden. Hierarchische Eskalationen: Incidents mit hoher Priorität oder solche, die innerhalb der vereinbarten Zeit nicht behoben werden konnten, lösen in der Regel hierarchische Eskalationen aus, zum Beispiel an das oberste Management. Solche Eskalationen müssen aufgezeichnet werden.
Status-Änderungen	In diesem Abschnitt sind Statusänderungen bei den Incidents zu vermerken (zum Beispiel von "Offen" auf "Gelöst").
Aktivitäts-Protokoll/ Aufgabenliste	In den meisten Systemen zum Managen von Incidents ist es möglich, die zur Behebung des Incidents unternommenen Schritte in einem einfachen Protokoll aufzuzeichnen. Manche Systeme bieten auch die Möglichkeit, den Incidents "Aufgaben" zuzuweisen. Ähnlich den Incidents, denen sie zugeordnet sind, werden die Aufgaben in der Regel über Attribute beschrieben, wie beispielsweise Bezeichnung, Beschreibung, verantwortlicher Mitarbeiter, Priorität usw. und enthalten eine eigene Statushistorie und ein eigenes Aktivitätsprotokoll.
Abschluss des Incidents	Angaben zum Abschluss des Incidents.
Art der Lösung	Beseitigung der zugrundeliegenden Ursache oder Anwendung eines Workarounds. Falls der Incident mittels eines Workarounds behoben wurde, Angabe des verwendeten Workarounds.
Erstellte Problems	Ein Problem Record ist beispielsweise zu erstellen, falls zu erwarten ist, dass der Incident erneut auftritt, so dass vorbeugende Maßnahmen notwendig sind falls der Incident nicht vollständig verstanden wurde falls ein neuer Workaround während der Incident-Behebung entwickelt wurde.
Kunden-Feedback	Bestätigung seitens des Kunden oder Nutzers, dass der Incident behoben wurde; gegebenenfalls Ergebnisse einer Zufriedenheitsumfrage.
Zusatz-Informationen	Anmerkungen und Zusatz-Informationen.

 

Status-Werte und Lifecycle

(Diese Informationen beinhaltet das Lifecycle-Diagramm zum Incident Record, das in der YaSM®-Prozesslandkarte enthalten ist.)

Zu beachten

• Für bestimmte Typen von wiederholt auftretenden Incidents beschreiben Incident-Modelle, wie diese Incidents zu beheben sind. In vielen Fällen wird die Handhabung solcher Incidents von entsprechend konfigurierten Tools unterstützt (zum Beispiel kann es Schnellverfahren zur leichten Erstellung bestimmter Typen von Incident Records geben).
• Die Klassifizierung von Problems und Incidents sollte nach den gleichen Regeln erfolgen, damit Problems und Incidents einander leichter zugeordnet werden können. Dies ist beispielsweise im Rahmen der Incident-Behebung zur Identifizierung von bekannten Fehlern und verfügbaren Workarounds wichtig.

 

Anmerkungen

Basiert auf: Checkliste Incident Record zur YaSM-Prozesslandkarte.

Von:  Stefan Kempter   und  Andrea Kempter , IT Process Maps.

 

Definition  › Inhalte  › Klassen bzw. Kategorien  › Priorisierung  › Eskalation  › Zu beachten