Das Change-Management stellt sicher, dass sämtliche Änderungen an der IT-Infrastruktur und den auf ihr basierenden Applikationen auf eine gesteuerte und kontrollierte Weise aufgezeichnet, bewertet, priorisiert, geplant, getestet, implementiert und dokumentiert werden.

Einzelziele:

• Risiken von Changes minimieren
• Dauer der Durchführung von Changes reduzieren
• nur Changes durchführen, die mit den Betroffenen abgestimmt sind
• Durchgeführte Changes dokumentieren
• Angeforderte und anstehende (geplanten) Changes dokumentieren

Stabilität und Qualität der IT-Services zur Unterstützung wichtiger Geschäftsprozesse werden nicht durch unkoordinierte und undokumentierte Änderungen an der ihnen zu Grunde liegenden IT-Infrastruktur gefährdet.

Request-for-Change (RfC):

Ein Request-for-Change wird in der Regel durch den Service-Desk angelegt. Abhängig vom Quellprozess und kann er auch durch andere Rollen angelegt werden. Ein RfC ist eine formale Anforderung eines Changes und hat folgenden Inhalt:

• Referenznumme,
• Bezeichnung / Kurzbeschreibung,
• betroffener Service (ggf. zusätzlich der betroffene Geschäftsprozess, das Objekt, welches verändert werden soll oder die gewünschte Auswirkung des Changes),
• Auswirkung bei Nicht-Durchführung des Changes,
• der Antragsteller,
• ein Terminvorschlag.

Im Laufe des Change-Management-Prozesses werden diese Informationen ergänzt:

• Change-Manager,
• Mitglieder des (Emergency) Change-Advisory-Board,
• Klassifizierung (Standard- oder Nicht-Standard-Change),
• Bewertung (Notfall-Change oder Change im normalen Betriebsablauf),
• Kosten / Aufwand,
• Ablehnung oder Genehmigung des Changes mit Begründung der Entscheidung.

Rolle Change Manager:

• die Person, die den RfC annimmt (kann durch Service-Desk aufgenommen werden),
• muss die fachliche Kompetenz haben, den Change und seine Auswirkungen vorabbewerten zu können,
• ist für die Durchführung des Change-Management-Prozesses verantwortlich,
• ruft das (E)CAB ein und trägt vor,
• genehmigt die Durchführung des Changes oder lehnt ihn ab,
• erstellt den Change-Record und den Change-Schedule zusammen mit der Rolle Service-Operation.
• In der Regel übernimmt der für den betreffenden Service verantwortliche Service-Manager die Rolle Change-Managers.

Change Advisory Board (CAB):

Das Change-Advisory-Board ist ein beratendes Gremium, in dem alle Betroffenen eines Changes vertreten sind:

• Die Zusammensetzung des CABs ist abhängig vom betroffenen Service.
• Der Service-Manager stellt das CAB für den jeweiligen Service zusammen.
• Der Change-Manger ruft das CAB bei Bedarf ein.
• Das CAB bewertet und priorisiert den Change.
• Es unterstützt den Change-Manager.
• Es stellt sicher, dass für den Fall des Scheiterns eines Changes eine Rückfalllösung geplant wird.
• Es stimmt die für den Change notwendigen Ressourcen ab.
• Es führt eine Liste der gestellten RfCs in seiner Verantwortung.

Change Record:

Im Change Record sind Planung und Umsetzung eines Changes dokumentiert:

• Referenznummer,
• betroffener Service, betroffener Geschäftsprozess,
• Ziel des Changes (z. B. Korrektur von / Integration von),
• Ursachen für den RfC,
• vom Change betroffene Systeme und Komponenten,
• Strategie im Fehlerfal,
• Ablaufplan zur Umsetzung des Changes,
• Vorgehensweise zur Kontrolle der erfolgreichen Umsetzung des Changes,
• Ausfallzeit des betroffenen Services.

Change-Schedule:

Das Change-Schedule ist die Ablaufplanung zum Durchführen eines Changes; sie enthält:

• Zeitpunkt der Umsetzung des Changes,
• Teilaktivität(en),
• durchführende Personen,
• Dauer,

Standard-Change:

• Ein Standard-Change ist ein Change, der im bereits im Vorhinein genehmigt ist. Beim Standard-Change liegen Change-Record und gegebenenfalls Change-Schedule bereits fest. Die Rolle Service-Operation führt einen Standard-Change gegebenenfalls ohne weitere Abstimmung durch, bzw. stimmt nur noch den Change-Schedule mit den Service-Nutzern ab.
• Bevor ein Change zu einem Standard-Change wird, muss er vorab den Change-Management-Prozess mindestens einmal als Nicht-Standard-Change durchlaufen haben. Im Rahmen dieses Durchlaufs erfolgen die notwendigen Abstimmungen und werden die erforderlichen Dokumente erstellt. Kein Change, der zum ersten Mal durchgeführt wird, kann ein Standard-Change sein.
• Der Change-Manger evaluiert nach der Durchführung eines Nicht-Standard-Changes, ob dieser zukünftig als Standard-Change durchgeführt werden kann.

Nicht-Standard-Change:

• Change, der im Rahmen des Change-Management-Prozesses genehmigt oder abgelehnt wird,
• Change wird per Change-Record und Change-Schedule geplant,
• ein Nicht-Standard-Change kann nach erfolgreicher Durchführung und Dokumentation zu einem Standard-Change werden.

Notfall-Change (Emergency Change):

• Ziel: schnellstmögliche Behebung einer Störung, die große negative Auswirkungen auf viele oder alle Geschäftsprozesse hat.
• Auch ein Notfall-Change muss durch das CAB bewertet werden (evtl. Emergency CAB, ECAB).
• Der Notfall-Change wird ebenfalls per Change-Record und Change-Schedule geplant. Gegebenenfalls ist eine Nachdokumentation des Changes notwendig, falls vorher nicht ausreichend Zeit war, die Dokumente vor Durchführung des Changes zu erstellen.

Oberster Grundsatz:

• RfCs müssen vor ihrer Umsetzung genehmigt werden! Entweder durch das Change-Advisory-Board (CAB) oder durch das Emergency-Change-Advisory-Board (ECAB). Dieses Vorgehen verhindert die Durchführung von Changes, die weder dokumentiert noch bekannt sind und somit zu unnötigen Risiken für die Servicequalität und zu zusätzlichen Aufwänden im Service Desk führen.

Weitere Grundsätze aus ITIL:

• Schaffung einer Null-Toleranz-Kultur in Bezug auf unautorisierte Changes,
• Abstimmung des Change Management-Prozesses auf andere Change-Prozesse in der Organisation,
• erfolgreiche Priorisierung, beispielsweise innovative versus präventive oder erkennende versus korrigierende Changes,
• Einrichtung einer zentralen Unterstützungsstelle für Changes,
• Sicherstellung der Integration mit anderen Service-Management-Prozessen,
• Einrichtung von Change-Fenstern, Leistungs- und Risikobewertungen oder Messungen der Leistungsfähigkeit.

1. Änderungsanforderungen (Change-Antrag, RfC), die in anderen Prozessen entstehen, aufnehmen.
2. Festlegen, was tatsächlich geändert wird.
3. Festlegen, wann der Change tatsächlich durchgeführt wird.
4. Auswirkungen des Changes identifizieren.
5. Genehmigung oder Ablehnung des Changes durch die vom Change Betroffenen (bzw. durch Vertreter der Betroffenen) herbeiführen. Dies schließt die Kunden und Nutzer des vom Change betroffenen Services, den Service-Manager, die Service-Operation, ggf. externe Lieferanten sowie Service-Desk-Vertreter und weitere Experten ein.
6. Change planen.
7. Change dokumentieren.
8. Change nachhalten.

Wie jeder Prozess wird auch das Incident-Management laufend anhand seiner Prozesskennzahlen bewertet und verbessert. Aktuell orientieren sich die IT-Dienste an diesen Kennzahlen:

1. Anzahl wichtiger Nicht-Standard-Changes, die vom CAB (Change Advisory Board) freigegeben werden müssen,
2. Anzahl von CAB-Einberufungen,
3. Mittlere Zeitdauer von der Einreichung eines RfC bis zur Change-Freigabe,
4. Verhältnis akzeptierter zu zurückgewiesenen RfCs,
5. Anzahl von Notfall-Changes, die vom ECAB freigegeben werden müssen.