Checkliste Problem Record: Unterschied zwischen den Versionen

Aus IT Process Wiki
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 1: Zeile 1:
<seo metakeywords="problem record, itil problem record" metadescription="Der Problem Record enthält alle Einzelheiten eines Problems und dokumentiert so den Lebenszyklus des Problems von der Erkennung bis zur Lösung." />
<seo metakeywords="problem record, itil problem record, problem record itil" metadescription="Der Problem Record enthält alle Einzelheiten eines Problems und dokumentiert so den Lebenszyklus des Problems von der Erkennung bis zur Schließung." />
<imagemap>
<imagemap>
Image:ITIL-Wiki-english-es.jpg|ES - EN - Checkliste Problem Record - Vorlage Problem Record|100px
Image:ITIL-Wiki-english-es.jpg|ES - EN - Checkliste Problem Record - Vorlage Problem Record|100px
Zeile 7: Zeile 7:
</imagemap>
</imagemap>
<br style="clear:both;"/>
<br style="clear:both;"/>
== <span id="Problem Record">Überblick</span> ==


'''ITIL-Prozess''': [[ITIL V3 Service Operation - Servicebetrieb|ITIL 2011 Service Operation]] - [[Problem Management]]
'''ITIL-Prozess''': [[ITIL V3 Service Operation - Servicebetrieb|ITIL 2011 Service Operation]] - [[Problem Management]]
Zeile 16: Zeile 18:
<p>&nbsp;</p>
<p>&nbsp;</p>


Der ''Problem Record'' enthält sämtliche Einzelheiten eines [[Problem Management#Problem|Problems]] und dokumentiert so den Lebenszyklus des Problems von der Erkennung bis zur Lösung.
Der ''Problem Record'' enthält sämtliche Einzelheiten eines [[Problem Management#Problem|Problems]] und dokumentiert so den Lebenszyklus des Problems von der Erkennung bis zur Schließung.


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


'''Ein Problem Record umfasst in der Regel die folgenden Informationen:'''
'''Ein Problem Record umfasst in der Regel die folgenden Informationen:'''
Zeile 24: Zeile 29:
<p>&nbsp;</p>
<p>&nbsp;</p>


# Eindeutige Kennung (ID) des [[Problem Management#Problem|Problems]] (in der Regel systemseitig vergeben)  
===== Kennung =====
# Datum und Uhrzeit der Erstellung
(Eindeutige Kennung (ID) des [[Problem Management#Problem|Problems]]: In der Regel systemseitig vergeben)  
# Problemverantwortlicher
 
# Symptombeschreibung
===== Erstellung =====
# Betroffene Anwender/Geschäftsbereiche
(Datum und Uhrzeit der Erstellung)
# Betroffene(r) Service(s)
 
# Priorisierung aufgrund folgender Kriterien:  
===== Problemverantwortlicher =====
## Dringlichkeit (zur Verfügung stehende Zeit bis zur Lösung des Problems), z.B.
 
### Bis zu 5 Arbeitstagen
===== Symptombeschreibung =====
### Bis zu 2 Wochen
 
### Bis zu 4 Wochen
===== Betroffene Anwender/ Geschäftsbereiche =====
## Schweregrad (Schaden für das Unternehmen), z.B.
 
### „Hoch“ (Unterbrechung kritischer Unternehmensprozesse)
===== Betroffene(r) Service(s) =====
### „Normal“ (Unterbrechung der Arbeit einzelner Mitarbeiter)
 
### „Gering“ (Behinderung der Arbeit einzelner Mitarbeiter, jedoch ist eine Fortsetzung der Arbeit mit Hilfe einer Umgehungslösung möglich)
===== Priorisierung =====
## Priorität (beispielsweise in Stufen 1, 2 und 3): Ergibt sich aus der Kombination von Dringlichkeit und Schweregrad
Priorisierung aufgrund folgender Kriterien:  
# Beziehung zu [[Service Asset and Configuration Management#CI|CIs]]
# Dringlichkeit (verfügbare Zeit bis zur Lösung des Problems)  
# Problemkategorie, in der Regel anhand eines Kategorienbaums nach folgendem Muster (die Kategorien für Problems, Incidents und CIs sollten harmonisiert sein, um die Abbildung von Beziehungen zwischen Incidents, Problems und CIs zu erleichtern):   
# Auswirkung (Schaden bzw. potentieller Schaden für das Unternehmen)
## Hardware-Fehler
# Priorität (zum Beispiel ausgedrückt in Prioritäts-Codes wie "Kritisch", "Hoch", "Mittel", "Niedrig", "Sehr niedrig"): Ergibt sich aus der Kombination von Dringlichkeit und Auswirkung.
### Server A
(Anmerkung: Die Priorisierung von Problems sollte denselben Regeln folgen wie die Priorisierung von Incidents; für weitere Informationen siehe Checkliste [[Checkliste Incident-Priorität|Priorisierungs-Richtlinie für Incidents]]).
#### Komponente x
 
##### Symptom a
===== Bezug zu CIs =====
##### Symptom b
(Beziehung zu [[Checkliste CMS CMDB#Configuration-Modell und CI-Typen|Configuration Items/ CIs]])
##### ...
 
#### Komponente y
===== Problem-Kategorie =====
##### ...
Problemkategorie, in der Regel anhand eines Kategorienbaums nach folgendem Muster:   
### Server B
# Hardware-Fehler
## Server A
### Komponente x
#### Symptom a
#### Symptom b
#### ...
### Komponente y
#### ...
#### ...
## Software-Fehler
## Server B
### System A
### System B
### ...
### ...
## Netzwerk-Fehler
# Software-Fehler
## System A
## System B
## ...
## ...
# Links zu anderen Problem Records (falls es andere offene, mit diesem Problem zusammenhängende Problems gibt)
# Netzwerk-Fehler
# Links zu anderen [[Checkliste Incident Record|Incident Records]] (falls es offene [[Incident Management#Incident|Incidents]] gibt, deren Lösung von der Lösung dieses Problems abhängt)
# ...
# Links zu [[Problem Management#Known Error|Known Errors]] und [[Problem Management#Workaround|Workarounds]] (falls Known Errors und Workarounds im Zusammenhang mit dem Problem identifiziert wurden)
(Anmerkung: Die Kategorien für Problems und Incidents sollten harmonisiert sein, um die Abbildung von Beziehungen zwischen Incidents und Problems zu erleichtern)
# Wiederherstellungs- (Recovery-) Prozeduren: Prozeduren, die erforderlich sind, um das Problem zu beseitigen. Solche Prozeduren sind u.U. erforderlich, um Workarounds zu beseitigen, die im Rahmen der Incident-Behebung angewendet wurden.
 
# Protokoll der Aktivitäten/ Lösungshistorie
===== Links zu anderen Problem Records =====
## Datum und Uhrzeit
(falls es andere offene, mit diesem Problem zusammenhängende Problems gibt)
## Ersteller des Protokolls
 
## Beschreibung der Aktivitäten
===== Links zu Incident Records =====
## Neuer Status (falls der Status sich ändert)
(Links zu [[Checkliste Incident Record|Incident Records]] - falls es offene [[Incident Management#Incident|Incidents]] gibt, deren Lösung von der Lösung dieses Problems abhängt)
 
===== Links zu Known Errors und Workarounds =====
(Links zu [[Problem Management#Known Error|Known Errors]] und [[Problem Management#Workaround|Workarounds]] - falls Known Errors und Workarounds im Zusammenhang mit dem Problem identifiziert wurden)
 
===== Links zu RFCs/ Change Records =====
(Links zu [[Change Management#RFC|RFCs]]/ [[Change Management#Change Record|Change Records]], die mit der Lösung des Problems verbunden sind)
 
===== Problem-Statushistorie =====
# Datum und Uhrzeit
# Verantwortlicher Mitarbeiter
# Grund für Status-Änderung
# Neuer Problem-Status
 
===== Aktivitäts-Historie =====
Aktivitäts-Historie bzw. Tasks, die dem Problem zugeordnet sind: Die meisten Service-Desk-Systeme erlauben, eine einfache Historie der Schritte zum Lösen eines Problems aufzuzeichnen. Mit manchen Systemen lassen sich darüber hinaus "Tasks" zu Problems erstellen. Ähnlich wie die Problems, 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.


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

Version vom 24. Juni 2012, 12:12 Uhr

<seo metakeywords="problem record, itil problem record, problem record itil" metadescription="Der Problem Record enthält alle Einzelheiten eines Problems und dokumentiert so den Lebenszyklus des Problems von der Erkennung bis zur Schließung." />

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


Überblick

ITIL-Prozess: ITIL 2011 Service Operation - Problem Management

Checklisten-Kategorie: Checklisten ITIL Service Operation (Servicebetrieb)

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

 

Der Problem Record enthält sämtliche Einzelheiten eines Problems und dokumentiert so den Lebenszyklus des Problems von der Erkennung bis zur Schließung.

 

Problem Record - Inhalte

Ein Problem Record umfasst in der Regel die folgenden Informationen:

 

Kennung

(Eindeutige Kennung (ID) des Problems: In der Regel systemseitig vergeben)

Erstellung

(Datum und Uhrzeit der Erstellung)

Problemverantwortlicher
Symptombeschreibung
Betroffene Anwender/ Geschäftsbereiche
Betroffene(r) Service(s)
Priorisierung

Priorisierung aufgrund folgender Kriterien:

  1. Dringlichkeit (verfügbare Zeit bis zur Lösung des Problems)
  2. Auswirkung (Schaden bzw. potentieller Schaden für das Unternehmen)
  3. Priorität (zum Beispiel ausgedrückt in Prioritäts-Codes wie "Kritisch", "Hoch", "Mittel", "Niedrig", "Sehr niedrig"): Ergibt sich aus der Kombination von Dringlichkeit und Auswirkung.

(Anmerkung: Die Priorisierung von Problems sollte denselben Regeln folgen wie die Priorisierung von Incidents; für weitere Informationen siehe Checkliste Priorisierungs-Richtlinie für Incidents).

Bezug zu CIs

(Beziehung zu Configuration Items/ CIs)

Problem-Kategorie

Problemkategorie, in der Regel anhand eines Kategorienbaums nach folgendem Muster:

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

(Anmerkung: Die Kategorien für Problems und Incidents sollten harmonisiert sein, um die Abbildung von Beziehungen zwischen Incidents und Problems zu erleichtern)

Links zu anderen Problem Records

(falls es andere offene, mit diesem Problem zusammenhängende Problems gibt)

Links zu Incident Records

(Links zu Incident Records - falls es offene Incidents gibt, deren Lösung von der Lösung dieses Problems abhängt)

Links zu Known Errors und Workarounds

(Links zu Known Errors und Workarounds - falls Known Errors und Workarounds im Zusammenhang mit dem Problem identifiziert wurden)

Links zu RFCs/ Change Records

(Links zu RFCs/ Change Records, die mit der Lösung des Problems verbunden sind)

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

Aktivitäts-Historie bzw. Tasks, die dem Problem zugeordnet sind: Die meisten Service-Desk-Systeme erlauben, eine einfache Historie der Schritte zum Lösen eines Problems aufzuzeichnen. Mit manchen Systemen lassen sich darüber hinaus "Tasks" zu Problems erstellen. Ähnlich wie die Problems, 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.

 

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