Checkliste Incident Record: Unterschied zwischen den Versionen

Aus IT Process Wiki
Keine Bearbeitungszusammenfassung
Zeile 1: Zeile 1:
<seo metakeywords="incident record, checkliste incident" metadescription="Ein Incident Record ist ein Datensatz mit allen Angaben zu einem Incident - einer ungeplanten Unterbrechung oder Qualitätsminderung eines IT-Services." />
<seo metakeywords="incident record, checkliste incident, incident record itil" metadescription="Ein Incident Record ist ein Datensatz mit allen Angaben zu einem Incident - einer ungeplanten Unterbrechung oder Qualitätsminderung eines IT-Services." />
<imagemap>
<imagemap>
Image:ITIL-Wiki-english-es.jpg|ES - EN - Checkliste Incident Record - Vorlage Incident Record|100px
Image:ITIL-Wiki-english-es.jpg|ES - EN - Checkliste Incident Record - Vorlage Incident Record|100px
Zeile 7: Zeile 7:
</imagemap>
</imagemap>
<br style="clear:both;"/>
<br style="clear:both;"/>
== <span id="Incident Record">Überblick</span> ==


'''ITIL-Prozess''': [[ITIL V3 Service Operation - Servicebetrieb|ITIL 2011 Service Operation]] - [[Incident Management]]
'''ITIL-Prozess''': [[ITIL V3 Service Operation - Servicebetrieb|ITIL 2011 Service Operation]] - [[Incident Management]]
Zeile 21: Zeile 23:


<p>&nbsp;</p>
<p>&nbsp;</p>
__TOC__
== Incident Record - Inhalte ==


'''Ein Incident Record enthält üblicherweise die folgenden Informationen:'''
'''Ein Incident Record enthält üblicherweise die folgenden Informationen:'''
Zeile 26: Zeile 31:
<p>&nbsp;</p>
<p>&nbsp;</p>


# Eindeutige Kennung (ID) des Incidents (in der Regel automatisch vom System vergeben)  
===== Kennung =====
# Datum und Uhrzeit der Ersterfassung
(Eindeutige Kennung ID des Incidents: In der Regel automatisch vom System vergeben)  
# Mitarbeiter des [[Rollen in ITIL V3#1st Level Support|Service-Desks]], der den Incident Record erfasst hat
 
# Art der Benachrichtigung (z.B. Anwender per Telefon, Event Monitoring)
===== Ersterfassung =====
# Melder-/ Anwenderdaten
(Datum und Uhrzeit der Ersterfassung)
# Kommunikationsweg für Rückmeldungen
 
# Symptombeschreibung
===== Art der Benachrichtigung =====
# Betroffene Anwender/ Geschäftsbereiche
(z.B. Anwender per Telefon, E-Mail, Intranet-Portal, Event-Monitoring-System)
# Betroffene(r) Service(s)
 
# Priorisierung gemäß folgender Kategorien (für weitere Informationen: siehe Checkliste [[Checkliste Incident-Priorität|Priorisierungs-Richtlinie für Incidents]]):   
===== Service-Desk-Agent =====
## Dringlichkeit (verfügbare Zeit bis zur Lösung des Incidents)
(Falls zutreffend, Service-Desk-Agent, der den Incident erfasst)
## Auswirkung (Schaden bzw. potentieller Schaden für das Unternehmen)
 
## Priorität (zum Beispiel in Stufen 1, 2 und 3): Ergibt sich aus der Kombination von Dringlichkeit und Auswirkung
===== Melder-/ Anwenderdaten =====
## Kennzeichnung als Major Incident (um anzuzeigen, dass der Incident als Major Incident behandelt wird)
(Falls zutreffend, Kontakt-Informationen des Melders bzw. Anwenders)
# Bezug zu CIs (wichtige CIs, die vom Incident betroffen sind)
 
# Incident-Kategorie, anhand eines Kategorienbaums nach folgendem Muster (die Kategorien für Incidents, Problems und CIs sollten harmonisiert sein, um die Abbildung von Beziehungen zwischen Incidents, Problems und CIs zu erleichtern):  
===== Kommunikationsweg =====
## Hardware-Fehler
(Kommunikationsweg für Rückmeldungen)
### Server A
 
#### Komponente x
===== Symptombeschreibung =====
##### Symptom a
 
##### Symptom b
===== Betroffene Anwender, Standorte und/ oder Geschäftsbereiche =====
#### Komponente y
 
##### ...
===== Betroffene(r) Service(s) =====
### Server B
 
### ...
===== Priorisierung =====
## Software-Fehler
Priorisierung gemäß folgender Kategorien (für weitere Informationen: siehe Checkliste [[Checkliste Incident-Priorität|Priorisierungs-Richtlinie für Incidents]]):   
### System A
# Dringlichkeit (verfügbare Zeit bis zur Lösung des Incidents)
### System B
# Auswirkung (Schaden bzw. potentieller Schaden für das Unternehmen oder die IT-Infrastuktur)
### ...
# Priorität
## Netzwerk-Fehler
## zum Beispiel ausgedrückt in Prioritäts-Codes wie "Kritisch", "Hoch", "Mittel", "Niedrig", "Sehr niedrig":  
## Ergibt sich aus der Kombination von Dringlichkeit und Auswirkung
# Kennzeichnung als Major Incident (um anzuzeigen, dass der Incident als Major Incident behandelt wird)
 
===== Bezug zu CIs =====
(wichtige [[Checkliste CMS CMDB#Configuration-Modell und CI-Typen|Configuration Items (CIs)]], die vom Incident betroffen sind)
 
===== Incident-Kategorie =====
Incident-Kategorie, anhand eines Kategorienbaums nach folgendem Muster (die Kategorien für Incidents und Problems sollten harmonisiert sein, um die Abbildung von Beziehungen zwischen Incidents und Problems zu erleichtern):  
# Hardware-Fehler
## Server A
### Komponente x
#### Symptom a
#### Symptom b
### Komponente y
#### ...
## Server B
## ...
## ...
# Links zu anderen Incident Records (falls ein gleichartiger offener Incident existiert, dem der neue Incident zugeordnet werden kann)
# Software-Fehler
# Links zu [[Checkliste Problem Record|Problem Records]] (falls ein offenes Problem existiert, dem der neue Incident zugeordnet werden kann)  
## System A
# Protokoll der Aktivitäten/ Lösungshistorie
## System B
## Datum und Uhrzeit
## ...
## Ersteller des Protokolls
# Netzwerk-Fehler
## Beschreibung durchgeführter Aktivitäten und erzielter Ergebnisse
# ...
## Neuer Status (falls der Status sich ändert)
 
# Lösungs- und Abschlussdaten
===== Links zu anderen Incident Records =====
## Abschlusskategorisierung (ggf. geänderte Produkt- und Incident-Kategorisierung)
(falls ein gleichartiger offener Incident existiert, dem der neue Incident zugeordnet werden kann)
## Identifizierte Problems (falls der Incident sich wiederholen könnte und vorbeugende Maßnahmen angezeigt sind)
 
## Lösungs-Typ (Beseitigung der dem Incident zugrundeliegenden Ursache vs. Anwendung eines [[Problem Management#Workaround|Workarounds]]; falls ein Workaround angewendet wurde: Angabe des angewendeten Workarounds
===== Links zu Problem Records =====
## Kunden-Feedback (ist der Incident aus Sicht vom Kunden gelöst?)
(Links zu [[Checkliste Problem Record|Problem Records]] - falls ein offenes Problem existiert, dem der neue Incident zugeordnet werden kann)  
 
===== Incident-Statushistorie =====
# Datum und Uhrzeit
# Verantwortlicher Mitarbeiter
# Grund für Status-Änderung
# Neuer Incident-Status
 
===== Aktivitäts-Historie/ Tasks =====
Aktivitäts-Historie bzw. Tasks, die dem Incident zugeordnet sind: Die meisten Service-Desk-Systeme erlauben, eine einfache Historie der Schritte zum Lösen eines Incidents aufzuzeichnen. Mit manchen Systemen lassen sich darüber hinaus "Tasks" zu Incidents erstellen. Ähnlich wie die Incidents, denen die Tasks zugeordnet sind, enthalten Tasks typischerweise Attribute wie Name, Beschreibung, Owner, Priorität etc. und verfügen über eine eigene Status- und Aktivitäts-Historie.
 
===== Lösungs- und Abschlussdaten =====
# Abschlusskategorisierung (ggf. geänderte Produkt- und Incident-Kategorisierung)
# Identifizierte Problems (falls der Incident sich wiederholen könnte und vorbeugende Maßnahmen angezeigt sind)
# Lösungs-Typ (Beseitigung der dem Incident zugrundeliegenden Ursache vs. Anwendung eines [[Problem Management#Workaround|Workarounds]]; falls ein Workaround angewendet wurde: Angabe des angewendeten Workarounds)
# Kunden-Feedback (ist der Incident aus Sicht vom Kunden gelöst?)


<p>&nbsp;</p>
<p>&nbsp;</p>

Version vom 10. Mai 2012, 14:15 Uhr

<seo metakeywords="incident record, checkliste incident, incident record itil" metadescription="Ein Incident Record ist ein Datensatz mit allen Angaben zu einem Incident - einer ungeplanten Unterbrechung oder Qualitätsminderung eines IT-Services." />

ES - EN - Checkliste Incident Record - Vorlage Incident Recordesta página en españolthis Page in English
ES - EN - Checkliste Incident Record - Vorlage Incident Record


Überblick

ITIL-Prozess: ITIL 2011 Service Operation - Incident Management

Checklisten-Kategorie: Checklisten ITIL Service Operation (Servicebetrieb)

Quelle: Checkliste "Incident Record" aus der ITIL-Prozesslandkarte

 

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

 

Incident Record - Inhalte

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

 

Kennung

(Eindeutige Kennung ID des Incidents: In der Regel automatisch vom System vergeben)

Ersterfassung

(Datum und Uhrzeit der Ersterfassung)

Art der Benachrichtigung

(z.B. Anwender per Telefon, E-Mail, Intranet-Portal, Event-Monitoring-System)

Service-Desk-Agent

(Falls zutreffend, Service-Desk-Agent, der den Incident erfasst)

Melder-/ Anwenderdaten

(Falls zutreffend, Kontakt-Informationen des Melders bzw. Anwenders)

Kommunikationsweg

(Kommunikationsweg für Rückmeldungen)

Symptombeschreibung
Betroffene Anwender, Standorte und/ oder Geschäftsbereiche
Betroffene(r) Service(s)
Priorisierung

Priorisierung gemäß folgender Kategorien (für weitere Informationen: siehe Checkliste Priorisierungs-Richtlinie für Incidents):

  1. Dringlichkeit (verfügbare Zeit bis zur Lösung des Incidents)
  2. Auswirkung (Schaden bzw. potentieller Schaden für das Unternehmen oder die IT-Infrastuktur)
  3. Priorität
    1. zum Beispiel ausgedrückt in Prioritäts-Codes wie "Kritisch", "Hoch", "Mittel", "Niedrig", "Sehr niedrig":
    2. Ergibt sich aus der Kombination von Dringlichkeit und Auswirkung
  4. Kennzeichnung als Major Incident (um anzuzeigen, dass der Incident als Major Incident behandelt wird)
Bezug zu CIs

(wichtige Configuration Items (CIs), die vom Incident betroffen sind)

Incident-Kategorie

Incident-Kategorie, anhand eines Kategorienbaums nach folgendem Muster (die Kategorien für Incidents und Problems sollten harmonisiert sein, um die Abbildung von Beziehungen zwischen Incidents und Problems zu erleichtern):

  1. Hardware-Fehler
    1. Server A
      1. Komponente x
        1. Symptom a
        2. Symptom b
      2. Komponente y
        1. ...
    2. Server B
    3. ...
  2. Software-Fehler
    1. System A
    2. System B
    3. ...
  3. Netzwerk-Fehler
  4. ...
Links zu anderen Incident Records

(falls ein gleichartiger offener Incident existiert, dem der neue Incident zugeordnet werden kann)

Links zu Problem Records

(Links zu Problem Records - falls ein offenes Problem existiert, dem der neue Incident zugeordnet werden kann)

Incident-Statushistorie
  1. Datum und Uhrzeit
  2. Verantwortlicher Mitarbeiter
  3. Grund für Status-Änderung
  4. Neuer Incident-Status
Aktivitäts-Historie/ Tasks

Aktivitäts-Historie bzw. Tasks, die dem Incident zugeordnet sind: Die meisten Service-Desk-Systeme erlauben, eine einfache Historie der Schritte zum Lösen eines Incidents aufzuzeichnen. Mit manchen Systemen lassen sich darüber hinaus "Tasks" zu Incidents erstellen. Ähnlich wie die Incidents, denen die Tasks zugeordnet sind, enthalten Tasks typischerweise Attribute wie Name, Beschreibung, Owner, Priorität etc. und verfügen über eine eigene Status- und Aktivitäts-Historie.

Lösungs- und Abschlussdaten
  1. Abschlusskategorisierung (ggf. geänderte Produkt- und Incident-Kategorisierung)
  2. Identifizierte Problems (falls der Incident sich wiederholen könnte und vorbeugende Maßnahmen angezeigt sind)
  3. Lösungs-Typ (Beseitigung der dem Incident zugrundeliegenden Ursache vs. Anwendung eines Workarounds; falls ein Workaround angewendet wurde: Angabe des angewendeten Workarounds)
  4. Kunden-Feedback (ist der Incident aus Sicht vom Kunden gelöst?)

 

Abgerufen von „https://wiki.de.it-processmaps.com/index.php?title=Checkliste_Incident_Record&oldid=6711“