Checkliste Incident Record: Unterschied zwischen den Versionen

Aus IT Process Wiki
Keine Bearbeitungszusammenfassung
 
Keine Bearbeitungszusammenfassung
Zeile 1: Zeile 1:
'''ITIL-Prozess''': [[Service Support]] - [[Service Desk and Incident Management]]
<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." />
<imagemap>
Image:ITIL-Wiki-english-es.jpg|ES - EN - Checkliste Incident Record - Vorlage Incident Record|100px
rect 0 0 50 30 [https://wiki.es.it-processmaps.com/index.php/Lista_de_control_-_Registro_de_Incidente esta página en español]
rect 50 0 100 30 [https://wiki.en.it-processmaps.com/index.php/Checklist_Incident_Record this Page in English]
desc none
</imagemap>
<br style="clear:both;"/>


'''Checklisten-Kategorie''': [[ITIL-Checklisten#Checklisten für Service Desk and Incident Management|Checklisten für Service Desk and Incident Management]]
'''ITIL-Prozess''': [[ITIL V3 Service Operation - Servicebetrieb]] - [[Incident Management]]


'''Checklisten-Kategorie''': [[ITIL-Checklisten#Checklisten ITIL V3 Service Operation (Servicebetrieb)|Checklisten ITIL V3 Service Operation (Servicebetrieb)]]


Bei der Erfassung eines Incidents werden die folgenden Daten aufgenommen:
'''Quelle''': Checkliste "Incident Record" aus der [https://de.it-processmaps.com/produkte/itil-prozesslandkarte.html ITIL-Prozesslandkarte V3]


* eindeutige ID des Incidents (in der Regel durch das System automatisch vergeben)
 
* Datum und Uhrzeit der Aufnahme (in der Regel durch das System automatisch vergeben)
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.
* aufnehmender Service-Desk-Mitarbeiter
 
* Melder-/ Anwenderdaten
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-Typ (Störung, Serviceauftrag)
 
* Symptombeschreibung
 
* betroffener IT-Service
'''Ein Incident Record enthält üblicherweise die folgenden Informationen:'''
* relevante SLAs
 
* Bezug zu CIs
 
* Produkt-Kategorie, z.B. anhand eines Kategorien-Baums nach dem folgenden Muster:
# Eindeutige Kennung (ID) des Incidents (in der Regel automatisch vom System vergeben)  
** Client-PC
# Datum und Uhrzeit der Ersterfassung
*** Standardkonfiguration1
# Mitarbeiter des Service-Desks, der den Incident Record erfasst hat
*** ...
# Art der Benachrichtigung (z.B. Anwender per Telefon, Event Monitoring)
** Drucker
# Melder-/ Anwenderdaten
*** Hersteller 1
# Kommunikationsweg für Rückmeldungen
*** ...
# Symptombeschreibung
** Incident-Kategorie, z.B.
# Betroffene Anwender/ Geschäftsbereiche
*** Softwarefehler
# Betroffene(r) Service(s)
*** ...
# Priorisierung gemäß folgender Kategorien:
* Zuordnung zu einem anderen Incident (falls ein gleichartiger offener Incident besteht, dem der neue Incident zugeordnet werden kann)
## Dringlichkeit (verfügbare Zeit bis zur Lösung des Incidents), z.B.
### bis zu 0,5 Std.
### bis zu 2,0 Std.
### bis zu 6,0 Std.
## Auswirkung (Schaden bzw. potentieller Schaden für das Unternehmen), z.B.
### "Hoch" (weitreichende Unterbrechung unternehmenskritischer Prozesse)
### "Normal" (Unterbrechung der Arbeit einzelner Mitarbeiter)
### "Gering" (Behinderung der Arbeit einzelner Mitarbeiter, Weiterarbeiten mit einem Workaround jedoch möglich)
## Priorität (zum Beispiel in Stufen 1, 2 und 3): Ergibt sich aus der Kombination von Dringlichkeit und Auswirkung
# Bezug zu CIs
# Produktkategorie, anhand eines Kategorienbaums nach folgendem Muster:  
## Client-PC
### Standardkonfiguration 1
### ...
## Drucker
### Hersteller 1
### ...
# Incident-Kategorie, anhand eines Kategorienbaums nach folgendem Muster:
## Hardware-Fehler
### Server A
### Server B
### ...
## Software-Fehler
### System A
### System B
### ...
# Links zu anderen Incident Records (falls ein gleichartiger offener Incident existiert, dem der neue Incident zugeordnet werden kann)
# Links zu Problem Records (falls ein offenes Problem existiert, dem der neue Incident zugeordnet werden kann)  
# Protokoll der Aktivitäten/ Lösungshistorie
## Datum und Uhrzeit
## Ersteller des Protokolls
## Beschreibung der Aktivitäten
## Neuer Status (falls der Status sich ändert)
# 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 Workarounds; falls ein Workaround angewendet wurde: Angabe des angewendeten Workarounds
## Kunden-Feedback (ist der Incident aus Sicht vom Kunden gelöst?)
 
 
 
<!-- Diese Seite liegt in folgenden Kategorien: -->
[[Kategorie:ITIL V3|Incident Record]][[Kategorie:Checkliste (ITIL)|Incident Record]][[Kategorie:Service Operation|Incident Record]][[Kategorie:Incident Management|Incident Record]]
<!-- keine Inhalte nach diesem Kommentar! -->

Version vom 6. September 2011, 17:40 Uhr

<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." />

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


ITIL-Prozess: ITIL V3 Service Operation - Servicebetrieb - Incident Management

Checklisten-Kategorie: Checklisten ITIL V3 Service Operation (Servicebetrieb)

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


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


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


  1. Eindeutige Kennung (ID) des Incidents (in der Regel automatisch vom System vergeben)
  2. Datum und Uhrzeit der Ersterfassung
  3. Mitarbeiter des Service-Desks, der den Incident Record erfasst hat
  4. Art der Benachrichtigung (z.B. Anwender per Telefon, Event Monitoring)
  5. Melder-/ Anwenderdaten
  6. Kommunikationsweg für Rückmeldungen
  7. Symptombeschreibung
  8. Betroffene Anwender/ Geschäftsbereiche
  9. Betroffene(r) Service(s)
  10. Priorisierung gemäß folgender Kategorien:
    1. Dringlichkeit (verfügbare Zeit bis zur Lösung des Incidents), z.B.
      1. bis zu 0,5 Std.
      2. bis zu 2,0 Std.
      3. bis zu 6,0 Std.
    2. Auswirkung (Schaden bzw. potentieller Schaden für das Unternehmen), z.B.
      1. "Hoch" (weitreichende Unterbrechung unternehmenskritischer Prozesse)
      2. "Normal" (Unterbrechung der Arbeit einzelner Mitarbeiter)
      3. "Gering" (Behinderung der Arbeit einzelner Mitarbeiter, Weiterarbeiten mit einem Workaround jedoch möglich)
    3. Priorität (zum Beispiel in Stufen 1, 2 und 3): Ergibt sich aus der Kombination von Dringlichkeit und Auswirkung
  11. Bezug zu CIs
  12. Produktkategorie, anhand eines Kategorienbaums nach folgendem Muster:
    1. Client-PC
      1. Standardkonfiguration 1
      2. ...
    2. Drucker
      1. Hersteller 1
      2. ...
  13. Incident-Kategorie, anhand eines Kategorienbaums nach folgendem Muster:
    1. Hardware-Fehler
      1. Server A
      2. Server B
      3. ...
    2. Software-Fehler
      1. System A
      2. System B
      3. ...
  14. Links zu anderen Incident Records (falls ein gleichartiger offener Incident existiert, dem der neue Incident zugeordnet werden kann)
  15. Links zu Problem Records (falls ein offenes Problem existiert, dem der neue Incident zugeordnet werden kann)
  16. Protokoll der Aktivitäten/ Lösungshistorie
    1. Datum und Uhrzeit
    2. Ersteller des Protokolls
    3. Beschreibung der Aktivitäten
    4. Neuer Status (falls der Status sich ändert)
  17. 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?)