Information Technology Reference
In-Depth Information
'RNXPHQWDWLRQ
5HYLHZ
5HTXHVW
IRU&KDQJH
$XVZLUNXQJHQ
5LVLNHQEHZHUWHQ
$UEHLWV
$XIWULJH
3ULRULVLHUHQ
3ODQXQJGHU
'XUFKIKUXQJ
$UEHLWV
$XIWULJH
&KDQJH
6FKHGXOH
*HQHKPLJXQJ
,PSOHPHQWLHUXQJ
EHUZDFKHQ
5HYLHZ
$EVFKOXVV
ABBILDuNG 4.13
Change-Prozess
Abbildung 4.13 zeigt beispielhat den schematischen Ablauf bei der Bearbeitung eines
Changes. Je nach Art und Umfang des jeweiligen Changes ist es durchaus möglich, unter-
schiedliche Modelle für die Bearbeitung zu deinieren.
4.2.6.3.1■Change-Dokumentation (Record RfC)
Wenn Changes aus dem Business oder der IT beantragt werden, so wird zunächst ein Change
Record in einem deinierten Change-Management-Tool angelegt. Die Inhalte des Change
Records orientieren sich an denen des RFC, können aber um weitere Felder, wie z. B. Ver-
merke zur Bewertung oder Freigabe, ergänzt werden.
Der Change Record dient der Verfolgung des Fortschrittes bei der Change-Durchführung
durch alle Phasen des Change-Management-Prozesses. Er muss eindeutig identiizierbar
sein (RFC-ID). Anhand der Dokumentation sollen jederzeit der Status (z. B. eingegangen,
akzeptiert, genehmigt, …) und erfolgte Maßnahmen nachvollzogen werden können.
4.2.6.3.2■RFC prüfen (Review RFC)
Im zweiten Schritt werden die RFC einem Review unterzogen. Es wird geprüt, ob die Durch-
führung möglich ist, ob evtl. gleichartige Changes bereits durchgeführt werden oder schon
abgelehnt wurden oder ob die Angaben im RFC ausreichend sind. Wird ein RFC nach dieser
Prüfung abgelehnt, so wird der Antragsteller darüber informiert und ggf. Hinweise gegeben,
welche Änderungen notwendig sind. Die Literatur schlägt hier folgenden Bewertungen vor:
Nicht umsetzbar
Wurde bereits in früheren Changes abgelehnt oder ist bereits in Arbeit
Unvollständiger RFC (es fehlen wichtige Informationen oder zum Beispiel eine Budget-
freigabe)
