Checkliste Request for Change RFC: Unterschied zwischen den Versionen

Aus IT Process Wiki
Keine Bearbeitungszusammenfassung
KKeine Bearbeitungszusammenfassung
Zeile 1: Zeile 1:
<seo metakeywords="request for change, itil rfc, rfc itil, itil change request" metadescription="Für jeden Nicht-Standard-Change muss der Request for Change (RFC) beim Change Management eingereicht werden (das Change Management definiert ..." />
<seo metakeywords="request for change, itil rfc, rfc itil, itil change request" metadescription="Nach ITIL ist der Request for Change (RFC) ist ein formeller Antrag zur Durchführung eines Changes. Für jeden Nicht-Standard-Change muss der Request for Change (RFC) beim Change Management eingereicht werden ..." />
<imagemap>
<imagemap>
Image:ITIL-Wiki-english-es.jpg|ES - EN - Checkliste Request for Change RFC - Vorlage Request for Change RFC|100px
Image:ITIL-Wiki-english-es.jpg|ES - EN - Checkliste Request for Change RFC - Vorlage Request for Change RFC|100px
Zeile 7: Zeile 7:
</imagemap>
</imagemap>
<br style="clear:both;"/>
<br style="clear:both;"/>
== <span id="RFC ITIL">Überblick</span> ==


'''ITIL-Prozess''': [[ITIL V3 Service Transition - Serviceüberführung|ITIL 2011 Service Transition]] - [[Change Management]]
'''ITIL-Prozess''': [[ITIL V3 Service Transition - Serviceüberführung|ITIL 2011 Service Transition]] - [[Change Management]]
Zeile 25: Zeile 27:


<p>&nbsp;</p>
<p>&nbsp;</p>
__TOC__
== Request for Change (RFC) - Inhalte ==


'''Ein Request for Change (RFC) umfasst in der Regel die folgenden Informationen:'''
''Ein Request for Change umfasst in der Regel die folgenden Informationen:''


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


# Eindeutige Kennung (ID)
===== Kennung =====
# Datum der Einreichung  
(Eindeutige Kennung - ID)
# Change-Owner
 
# Initiator des RFC (falls nicht mit dem Change Owner identisch)
===== Datum der Einreichung =====
# Vorgeschlagene Priorität des Changes (z.B. "Sehr hoch (Notfall-Change)", "Hoch", "Normal", "Gering" – die vorgeschlagene Priorität kann evt. während der Change-Bewertung vom Change Management neu eingestuft werden)
 
# Referenz auf einen Change-Vorschlag (falls der Change in Zusammenhang mit einem Change-Vorschlag steht, der im Vorfeld eingereicht wurde)
===== Change-Owner =====
# Beschreibung des beantragten Changes
 
## Zusammenfassende Beschreibung
===== Initiator des RFC =====
## Business Case
(falls nicht mit dem Change Owner identisch)
### Grund für die Durchführung des Changes
 
### Kosten
===== Change-Priorität =====
### Nutzen
(Vorgeschlagene Priorität des Changes, z.B. "Sehr hoch (Notfall-Change)", "Hoch", "Normal", "Gering". Die vorgeschlagene Priorität kann evt. während der Change-Bewertung vom Change Management neu eingestuft werden.)
### Folgen, falls der Change nicht implementiert wird   
 
### Verweise (z.B. auf einen [[Problem Management#Problem Record|Problem Record]], der diesen RFC erforderlich macht)  
===== Referenz auf einen Change-Vorschlag =====
## Kundenseitige Geschäftsbereiche und -prozesse, die von diesem Change betroffen sind
(falls der Change in Zusammenhang mit einem Change-Vorschlag steht, der im Vorfeld eingereicht wurde)
## Services, die von diesem Change betroffen sind  
 
## IT-Infrastrukturkomponenten ([[Checkliste CMS CMDB|CIs]]), die von diesem Change betroffen sind  
===== Beschreibung des beantragten Changes =====
## Technologische Aspekte (wird eine neue Technologie eingeführt?)
# Zusammenfassende Beschreibung
# Risiken während der Implementierung des Changes  
# Business Case
## Erkannte Risiken
## Grund für die Durchführung des Changes
## Zu treffende Gegenmaßnahmen (z.B. Rückfallverfahren)
## Kosten
## Back-Out-Strategie für den Fall einer fehlgeschlagenen Change-Implementierung
## Nutzen
# Vorgesehener Zeitplan für die Implementierung  
## Folgen, falls der Change nicht implementiert wird   
# Geschätzte Ressourcen für die Implementierung
## Verweise (z.B. auf einen [[Problem Management#Problem Record|Problem Record]], der diesen RFC erforderlich macht)  
## Benötigte Personalressourcen (aus welchen Bereichen?)
# Kundenseitige Geschäftsbereiche und -prozesse, die von diesem Change betroffen sind
## Geschätzter Umfang an benötigten Personalressourcen
# Services, die von diesem Change betroffen sind  
## Kostenkalkulation (bei größeren Changes detaillierte Aufstellung)  
# IT-Infrastrukturkomponenten ([[Checkliste CMS CMDB|CIs]]), die von diesem Change betroffen sind  
# Angabe, ob ein Budget für diesen Change beantragt und freigegeben wurde  
# Technologische Aspekte (wird eine neue Technologie eingeführt?)
# Ggf. Verzeichnis ergänzender Dokumente (z.B. das [[Service Level Management#SDP|Service Design Package]] für größere Erweiterungen oder Änderungen der Services)
 
# Genehmigung oder Ablehnung
===== Risiken während der Implementierung des Changes =====
## Datum
# Erkannte Risiken
## Für die Genehmigung des Changes zuständige(s) Person/ Gremium ([[Rollen in ITIL V3#Change Manager|Change Manager]]/ [[Rollen in ITIL V3#Change Advisory Board (CAB)|CAB]]/ [[Rollen in ITIL V3#Emergency Change Advisory Board (ECAB)|ECAB]])
# Zu treffende Gegenmaßnahmen (z.B. Rückfallverfahren)
## Am Review beteiligte Change Reviewer
# Back-Out-Strategie für den Fall einer fehlgeschlagenen Change-Implementierung
## Vom Change Management vergebene Priorität
 
## Ggf. Restriktionen
===== Vorgesehener Zeitplan für die Implementierung =====
## Ggf. Gründe für die Ablehnung des RFC
 
===== Geschätzte Ressourcen für die Implementierung =====
# Benötigte Personalressourcen (aus welchen Bereichen?)
# Geschätzter Umfang an benötigten Personalressourcen
# Kostenkalkulation (bei größeren Changes detaillierte Aufstellung)  
 
===== Budgetierung =====
(Angabe, ob ein Budget für diesen Change beantragt und freigegeben wurde)
 
===== Ggf. Verzeichnis ergänzender Dokumente =====
(z.B. das [[Service Level Management#SDP|Service Design Package]] für größere Erweiterungen oder Änderungen der Services)
 
===== Genehmigung oder Ablehnung =====
# Datum
# Für die Genehmigung des Changes zuständige(s) Person/ Gremium ([[Rollen in ITIL V3#Change Manager|Change Manager]]/ [[Rollen in ITIL V3#Change Advisory Board (CAB)|CAB]]/ [[Rollen in ITIL V3#Emergency Change Advisory Board (ECAB)|ECAB]])
# Am Review beteiligte Change Reviewer
# Vom Change Management vergebene Priorität
# Ggf. Restriktionen
# Ggf. Gründe für die Ablehnung des RFC


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

Version vom 22. April 2012, 16:02 Uhr

<seo metakeywords="request for change, itil rfc, rfc itil, itil change request" metadescription="Nach ITIL ist der Request for Change (RFC) ist ein formeller Antrag zur Durchführung eines Changes. Für jeden Nicht-Standard-Change muss der Request for Change (RFC) beim Change Management eingereicht werden ..." />

ES - EN - Checkliste Request for Change RFC - Vorlage Request for Change RFCesta página en españolthis Page in English
ES - EN - Checkliste Request for Change RFC - Vorlage Request for Change RFC


Überblick

ITIL-Prozess: ITIL 2011 Service Transition - Change Management

Checklisten-Kategorie: Checklisten ITIL Service Transition (Serviceüberführung)

Quelle: Checkliste "Request for Change - RFC" aus der ITIL-Prozesslandkarte

 

Der Request for Change (RFC) ist ein formeller Antrag zur Durchführung eines Changes. Für jeden Nicht-Standard-Change muss der Request for Change beim Change Management eingereicht werden (das Change Management definiert in der Regel eine Reihe von Standard- oder Routine-Changes; es handelt sich dabei um kleinere, häufig auftretende Changes, die nicht dem Change-Management-Prozess unterworfen werden müssen).

Einem Change ist ein Change Owner zugeordnet, der über ein Budget für die Implementierung verfügt. In vielen Fällen ist der Change Owner gleichzeitig auch der Initiator des RFC. Als Change Owner treten zumeist die Inhaber der Service-Management-Rollen auf (z.B. der Problem Manager), aber auch das IT-Management kommt hier infrage.

Der RFC ist ein Vorläuferdokument des Change Records und enthält alle Angaben, die zur Genehmigung eines Changes notwendig sind. Weitere Informationen werden im Verlauf des Change-Lebenszyklus ergänzt.

Der Detaillierungsgrad hängt von der Größe und der voraussichtlichen Auswirkung des Changes ab. Häufig beinhaltet der RFC Verweise auf andere Dokumente, die nähere Einzelheiten enthalten, z.B. einen ausführlichen Change Proposal.

 

Request for Change (RFC) - Inhalte

Ein Request for Change umfasst in der Regel die folgenden Informationen:

 

Kennung

(Eindeutige Kennung - ID)

Datum der Einreichung
Change-Owner
Initiator des RFC

(falls nicht mit dem Change Owner identisch)

Change-Priorität

(Vorgeschlagene Priorität des Changes, z.B. "Sehr hoch (Notfall-Change)", "Hoch", "Normal", "Gering". Die vorgeschlagene Priorität kann evt. während der Change-Bewertung vom Change Management neu eingestuft werden.)

Referenz auf einen Change-Vorschlag

(falls der Change in Zusammenhang mit einem Change-Vorschlag steht, der im Vorfeld eingereicht wurde)

Beschreibung des beantragten Changes
  1. Zusammenfassende Beschreibung
  2. Business Case
    1. Grund für die Durchführung des Changes
    2. Kosten
    3. Nutzen
    4. Folgen, falls der Change nicht implementiert wird
    5. Verweise (z.B. auf einen Problem Record, der diesen RFC erforderlich macht)
  3. Kundenseitige Geschäftsbereiche und -prozesse, die von diesem Change betroffen sind
  4. Services, die von diesem Change betroffen sind
  5. IT-Infrastrukturkomponenten (CIs), die von diesem Change betroffen sind
  6. Technologische Aspekte (wird eine neue Technologie eingeführt?)
Risiken während der Implementierung des Changes
  1. Erkannte Risiken
  2. Zu treffende Gegenmaßnahmen (z.B. Rückfallverfahren)
  3. Back-Out-Strategie für den Fall einer fehlgeschlagenen Change-Implementierung
Vorgesehener Zeitplan für die Implementierung
Geschätzte Ressourcen für die Implementierung
  1. Benötigte Personalressourcen (aus welchen Bereichen?)
  2. Geschätzter Umfang an benötigten Personalressourcen
  3. Kostenkalkulation (bei größeren Changes detaillierte Aufstellung)
Budgetierung

(Angabe, ob ein Budget für diesen Change beantragt und freigegeben wurde)

Ggf. Verzeichnis ergänzender Dokumente

(z.B. das Service Design Package für größere Erweiterungen oder Änderungen der Services)

Genehmigung oder Ablehnung
  1. Datum
  2. Für die Genehmigung des Changes zuständige(s) Person/ Gremium (Change Manager/ CAB/ ECAB)
  3. Am Review beteiligte Change Reviewer
  4. Vom Change Management vergebene Priorität
  5. Ggf. Restriktionen
  6. Ggf. Gründe für die Ablehnung des RFC

 

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