Service-Management-Checklisten

 

YaSM-Checklisten ('YaSM-Dokumentvorlagen') enthalten detaillierte Erläuterungen der verschiedenen Dokumente und Records ('Datenobjekte'), die in den YaSM-Prozessen erzeugt werden.

Auf dieser Seite: Beispiel - Checkliste Incident Record

 

YaSM-Dokument-Vorlagen

Jede Checkliste beschreibt die typischen Inhalte eines YaSM-Dokuments oder -Records, wie im folgenden Beispiel gezeigt. Da die Checklisten Microsoft-Word™-Dokumente sind, können sie in vielen Fällen als Vorlagen oder Templates genutzt werden, wenn bestimmte Service-Management-Dokumente erstellt werden müssen.

Die YaSM®-Prozesslandkarte enthält 75 Checklisten, eine für jedes YaSM-Datenobjekt. Zusätzlich gibt es 19 Checklisten für die Service-Management-Richtlinien.

 

Beispiel: YaSM-Checkliste "Incident Record"

Checkliste/ Dokument-Vorlage: Incident Record

Verbundener YaSM-Prozess: LP4.6: Lösen von Incidents und Service Requests

 

Incident Record: Definition

---

 

Abbildung 1: YaSM-Checkliste/ Dokument-Vorlage - Beispiel | "Incident Record".

Ein Incident Record ist ein Datensatz mit allen Angaben zu einem Incident, in dem der Lebenszyklus des Incidents von der Ersterfassung bis zur Lösung dokumentiert ist. Ein Incident ist definiert als ungeplante Unterbrechung oder Qualitätsminderung eines IT-Services. Auch ein Ereignis, das in der Zukunft einen IT-Service beeinträchtigen könnte, ist ein Incident (z.B. der Ausfall einer Festplatte in einem RAID-Verbund).

 

Typische Inhalte eines Incident Records

---

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

 

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 Incident.

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.

Incident-Verantwortlicher (Incident-Owner)

• Der 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 oder Support-Team, dem der Incident zugeordnet ist. Der Incident kann im Verlauf seines Lebenszyklus unterschiedlichen Personen oder Teams zugewiesen werden.

Incident-Klassifizierung

• 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.

Incident-Kategorisierung

• 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.

Priorität

• Die 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 (d.h. schwerwiegender) Incident

• Diese Kennzeichnung gibt an, dass ein Incident als Major Incident 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 to related incident records

• If similar outstanding incidents exist to which the new incident can be attributed in this case, one incident is usually declared the "master incident".

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.

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ätsprotokoll/ 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.

Zusatzinformationen

• Anmerkungen und Zusatzinformationen.

 

Anmerkungen

---

• 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.

 

[ Infobox ]

Link zu dieser Seite:	https://yasm.com/wiki/de/index.php/Service-Management-Checklisten
Sprachversionen:	Deutsch | English
Image:	Beispiel: YaSM-Checkliste 'Incident Record' (.JPG)
Basiert auf:	Checkliste "Incident Record" zur YaSM®-Prozesslandkarte
Autoren:	Stefan Kempter     und   Andrea Kempter     -   IT Process Maps.

YaSM-Checklisten › YaSM-Dokumentvorlagen › Beispiel: YaSM-Checkliste 'Incident Record'