Change Management

Beschreibung / Inhalt

Change Management behandelt jede Art einer Veränderung (Change) an einer IT Infrastruktur und seinen Servicen. Ein gut definierter, kontrollierter Prozess führt zum effektiven Ausführen von Veränderungen. Das Change Management wird immer dann ausgelöst, wenn eine Anfrage für einen Change (Request for Change) über eine der unterschiedlichen Wege, die einen solchen Request auslösen dürfen, eingegangen ist. Jeder angefragte Change wird klassifiziert, indem zumindest seine Priorität und seine Auswirkung ermittelt wird. Dann entscheidet die verantwortliche Change Autorität über die Annahme oder Ablehnung des Changes. Das Change Management koordiniert die Aktivitäten Annahme, Klassifizierung, Genehmigung, Autorisation, Planung, Testen, Freigabe und Ausführung sowie das erneute Testen und Freigeben in der produktiv Umgebung. Aufwendige Veränderungen werden dabei als Projekt realisiert. Aus diesem Grund und für den Erfolg des Change Managements ist es entscheidend, dass eine enge Zusammenarbeit zwischen dem Change Management, dem Projekt Management und dem Release Management besteht.

Ziele

Das Ziel des Change Management ist es, die Beeinträchtigungen von Veränderungen auf alle operativen Service so gering wie möglich zu halten. Es etabliert, koordiniert und kontrolliert die Aktivitäten zum Verwalten von Veränderungen. Der Bereich des Change Management ist der produktive Betrieb, der relevant für die Serviceerbringung ist und das dazugehörige administrative Umfeld.

Rollen & Funktionen

Spezifische Change Management Rollen

Statische Prozessrollen

Change Management Prozessverantwortlicher (Process Owner)
Der Prozessverantwortliche ist verantwortlich für das Definieren der prozessstrategischen Ziele und das Bereitstellen aller erforderlichen Ressourcen. Siehe auch Continual Process Improvement Management für eine detaillierte Beschreibung dieser Aktivitäten. Meist gibt es nur eine Prozessverantwortlicher (Process Owner) für alle Service Management Prozesse.

Change Management Prozess Manager (Change Manager)
Manager des gesamten Prozesses, verantwortliche für die Prozesseffektivität und -effizienz. Siehe auch Continual Process Improvement Management für eine detaillierte Beschreibung dieser Aktivitäten.

Change Management Team
Dies ist das Team, dass mit dem Change Management Prozess zugeordnet ist.

Emergency Change Advisory Board (ECAB)
Der Entscheidungsträger im Falle eines Notfall Changes. Er wird vom Senior Management bestimmt.

Senior Management
Leitung des IT Providers

Dynamische Prozessrollen

Diese Rollen werden während der Ausführung des Change Management Prozesses dynamisch belegt.

Change Verantwortlicher (Owner)
Das Attribut im Record (Ticket) beinhaltet den Namen der Person oder Gruppe die gegenwärtig für den Change (aber NICHT für den Change Management Prozess) rechenschaftspflichtig (accountable) ist. Der Change Verantwortliche kann durch eine Hierarchische Eskalation verändert werden.

Change Bearbeiter (Agent)
Das Attribut im Record (Ticket) beinhaltet den Namen der Person oder Gruppe die gegenwärtig für eine Aktivität oder einen Task innerhalb des Lebenszyklus eines Requests verantwortlich ist. Der Incident Bearbeiter kann durch eine Funktionale Eskalation verändert werden, wenn dies die Regeln erlauben.

Change Advisory Board (CAB)
Dies ist das zu konsultierende Gremium für Kategorie 2 und 3 Changes. Die Mitglieder des CAB werden in der Aktivität „Klassifikation“ definiert und eingestellt vom:

Serviceverantwortlichen
Change Prozess Manager
Service Expert oder Service Spezialist
Kunde oder Kundenvertreter
Anderen notwendigen Personen

Change Autorität (CA)
Dies ist die Person oder Gruppe die einen Change autorisiert; Change Autoritäten variieren abhängig von der Change Kategorie und der vom hange betroffenen Service. Die Gruppe kann ein oder mehrere Personen umfassen.

Change Antragsteller (Change Requester – CR)
Dies ist die Person, die einen Change über einen Request für einen Change auslöst (RFC). Dies Rolle kann von einer service- oder einer kundenspezifischen Rolle übernommen werden.

Change Tester
Dies ist die Person, die einen Change vor der Implementierung in der Testumgebung testet. Der Testumfang hängt von der Change-Kategorie ab. Diese Prüfung beinhaltet den Test

der Funktionen des zukünftigen Service
des Implementierungsplanes
des Fall-Back-Planes.

Diese Rolle ist auch verantwortlich für den Test nachdem der Change in die Liveumgebung implementiert wurde (Fallback-Tester). Es wird jedoch nur der Funktionstest durchgeführt. Der Change Tester muss bestätigen, dass die Tests durchgeführt wurden, indem dies im Change Record festhält. Falls der Change Tester die Bestätigung des Testes ablehnt, muss das Fall-Back-Szenario durchgeführt werden. Der Change Durchführender (Implementer) und der Change Tester dürfen nicht dieselbe Person sein.

Change Durchführender (Implementer)
Die ist die Person, die eine Change implementiert/durchführt welcher auf der RFC Form basiert. Dies kann identisch mit dem Change Builder (Entwickler) sein. Der Change Durchführende und der Change Tester dürfen nicht dieselbe Person sein.

Change Entwickler (Builder)
Die ist die Person, die die Klassifikation und eine detaillierte Planung der Aktivität „Entwerfen-Testen-Implementieren“ durchführt. Sie kann dieselbe Person wie der Change Durchführende sein, doch sollten Change Builder und Change Tester nicht die selbe Person sein.

Change Sponsor
Dies ist die Person, die für den Change bezahlt. Oftmals ist diese Person auch die Change Autorität.

Servicespezifische Rollen

Diese Rollen, abhängig vom betroffenen Service, findet man in der Service Beschreibung. Die Service Beschreibung, inklusive der servicespezifischen Rollen, wird vom Service Portfolio Management geliefert.

Service Experte/Service Spezialist
Übernehmen die dynamische Rolle des

Change Entwickler
Change & Fallback Tester
Change Durchführender

Service Verantwortlicher (Owner)
Er ist verantwortlich für den Service, wie es in der Service Beschreibung beschrieben steht. Kann als

Change Antragsteller
Change Autorität
Change Sponsor

eingesetzt werden.

Kundenspezifische Rollen

Rollen, die von den betroffenen Kunden abhängen findet man in den Service Level Agreements (SLA). Das Service Level Agreement für kundenspezifische Rollen wird durch das Service Agreement Management gepflegt.

Kunden (customer)
Kunden des betroffenen Service mit einem gültigen SLA

Informationsdokumente

Dieser Bereich beschreibt Dokument die während der Ausführung eines Change Managements Prozesses entstehen und Dokumente die zur Ausführung des Prozesses benötigt werden, sofern sie nicht von einem anderen Prozess bereitgestellt werden müssen und daher in der diesbezüglichen Prozessbeschreibung definiert werden

Zusätzliche Informationsdokumente, so wie der Request for Change (RFC) oder der Forwards Schedule of Change (FSC) im Kontext des Change Management, können normalerweise umgesetzt werden, indem die Informationen von einem oder mehreren Change Records (bis hin zu allen) berücksichtigt werden entweder durch filtern, verbinden, vergleichen oder interpretieren dieser Informationen (manchmal mit Referenzen zu anderen Daten und Informationsquellen).

Change Record

Der Change Record ist das Informationsdokument, das jegliche management-relevanten Informationen und die Historie eines bestimmten Changes beinhaltet. Beim durchlaufen des Prozesses wird er mit Informationen gefüllt, die vom Request for Change (RFC) zur Verfügung gestellt werden.

Change ID – Eindeutige Bezeichnung (Unique identifier)
Change Antragsteller (Requester) – Name der Person die den Change ausgelöst hat
Status – Status des Changes. Dieser wird gesetzt, wenn eine Kontrollaktivität passiert wird.
Change Bearbeiter (Agent)
Change Verantwortlicher (Owner)
Change Beschreibung – Die Beschreibung des Change
Prozessauslöser – Eindeutiger Bezeichner der Prozessinstanz, die den Change Management Prozess auslöst.
Change Kategorie
Change Priorität
Change Auswirkung – Geschäftsauswirkung des Changes
Services – Service die von diesem Change betroffen sind.
Kunde(n) – Kunden die von diesem Change betroffen sind
Change Sponsor – Name der Person die den Change bezahlt. Evtl. identisch mit Change Requester
Change Durchführender (Implementer) – Person, die die tatsächlich Veränderung durchführt. Wahrscheinlich aus der Gruppe der Service Experten bzw.Service Spezialisten
Change Entwickler (Builder) – Person die den Change plant und baut
Change Autorität – Person oder Gruppe, die je nach Kategorie den Change autorisiert
Change Tester – Person, die die den Test vor und nach der Implementierung durchführt.
Notfall Change (richtig/ falsch) – Wird auf “richtig” gesetzt wenn es sich um einen Notfall Change handelt
Risiko und Auswirkungsanalyse – Ergebnisse der Analyse
Kosten & Nutzen Analyse – Kosten, die für Entwerfen, Testen und Implementieren des Changes erwartet werden und Nutzen der Veränderung.
Implementierungsplan – Projektplan, der konkrete Arbeitsanweisungen und Zeitpläne beinhaltet
Implementierungsplan Testergebnisse -Text mit dem Ergebnissformular und Bemerkungen bzgl des Tests
Implementierungsstartdatum
Fallback-Plan – Fallback Plan beinhaltet genaue Arbeitsanweisungen und einen Auslöser für den Fallback
Fallback-Plan Testergebnisse – Text mit Ergebnissen und Anmerkungen bzgl. des Testes
Funktionstest-Plan – Funktioneller Testplan beinhaltet genaue Arbeitsanweisungen und erwartete Ergebnisse
Funktionstest-Plan Testergebnisse – Text mit den Ergebnissen und Bemerkungen bzgl. des Testes der Funktionen
Post Implementation Überprüfungsergebnisse – Text mit den Ergebnissen und Anmerkungen bzgl. des Testes
Dokumentationstest – Text mit dem Ergebnis des Dokumentationstest in der CMS/CMDB
Zusätzliche Bemerkungen – Text für zusätzliche Informationen, können Informationen über fehlgeschlagene Entwicklungen, Tests oder Implementierung eines Changes enthalten. Abschlussdatum – Datum für den *Abschluss des Changes

Forward Schedule of Changes (FSC)

Die FSC ist ein strukturierter Bericht, der sich auf alle offenen Changes bezieht. Er enthält service- und kundenrelevante Informationen aller geplanten Changes und bietet daher eine Zusammenfassung auf alle Change Records. Informationen die in den FSC einbezogen werden müssen:

Eindeutige Bezeichnung des Changes
Service
Kunde
Datum und Implementierungsstart des Changes
Beschreibung des Changes
Priorität
Kategorie

Report über abgeschlossen Veränderungen

Der Report bezieht sich auf alle geschlossenen oder abgebrochenen Veränderungen. Es ist eine wichtige Informationsquelle für den Incident Management Prozess und sollte folgendes beinhalten:

Eindeutige Bezeichnung des Changes
Service
Kunde
Beschreibung des Changes
Datum und Implementierungsstart des Changes
Post Implementation Überprüfungsergebnisse

Schlüsselkonzepte (Key Concepts)

Change Kategorie & Standard Change

Die folgende Tabelle zeigt unterschiedliche Change Kategorien von Veränderungen.

Kategorie	Vorgehensweise
0 – Standard/ vorautorisiert (preauthorized)	Changes in der Kategorie Standard werden von dem zuständigen Verantwortlichen (CA – Change Authority) vorautorisiert (preauthorized), da das Risiko niedrig ist und es sich um Changes handelt, die immer wieder erfolgen und einem Standardverfahren unterliegen. Eventuell ist der Zeitpunkt der Durchführung individuell zu planen. Veränderungen dieser Kategorie müssen auch dokumentiert werden.
1 – Geringfügig	Veränderungen, die als geringfügig eingestuft werden, werden vom Service Verantwortlichen autorisiert. Die Veränderung wird durch einen Change Verantwortlichen geplant. Changes der Kategorie ‚Geringfügig’ sind in der Umsetzung etwas aufwändiger und auch die Auswirkung im Problemfall im Vergleich zu der Kategorie ‚Mittel – 0’ höher als bei der Kategorie 0 – Geringfügig’, aber immer noch im Bezug auf das Risiko in einem gesunden Rahmen.
2 – erheblich	Diese Changes mit der Kategorie ‚erheblich’ werden vom Change Advisory Board (CAB) autorisiert (d.h. CAB ist gleichzeitig auch CA – Change Authority), da sie ein erhebliches Risiko in sich bergen. Vor der Genehmigung wird die Veränderung im Change Advisory Board (CAB) beraten. Changes der Kategorie erheblich können einen Projekt Charakter haben. D.h. der Change wir im Projekt vorbereitet und durch das Change Management autorisiert.
3 – weit reichend	Changes mit der Kategorie ‚weit reichend’ werden in der Geschäftsführung entschieden, dar das Risiko auf Geschäftsprozesse enorm ist. Das Change Advisory Board (CAB) hat hier einen beratenden Charakter Auch diese Veränderungen werden höchstwahrscheinlich in enger Zusammenarbeit mit Projekten durchgeführt.

Standard Changes tragen dazu bei, Prozessausführungen zu beschleunigen und dadurch die Effizienz des Change Management anzuheben. Wenn ein Change der oben genannten Kategorie angefragt wird, gibt es keine Verzögerung weil auf eine Change Autorisierung gewartet werden müsste (siehe unten). Dies ist so, da für jeden Standard Change eine erforderte Autorisierung vorab gegeben wurde, und dieser somit abrufbar für alle zukünftigen Veränderungen der selben Art ist. Es ist wesentlich, dass alle Prozeduren für die Definition und Administration eines Standard Changes etabliert sind. Dies wird erreicht durch den Sub-Prozess Standard Change Administration. Zusammenfassend sind Standard Changes folgendermaßen charakterisiert:

Geringes Risiko
Bekannte Kosten
Gut etablierte Prozedur (z.B. Arbeitsanweisungen) für die Change Implementierung
Gut etablierte Post Implementiere Testprozedur
Klar definierte Rollen:

o Wer ist Change Sponsor?
o Wer hat die Erlaubnis den Standardchange auszulösen? ( z.B. welcher User ist Change Requester)
o Wer ist verantwortlich dass der Change zur Ausführung durchgeführt wird? (z.B. das Service Desk)

Ein Test vor der Implementierung ist nicht erforderlich für Standard Changes (Kategorie 0). Dieser Test wurde während der Definition des Standard Changes durchgeführt. Per Definition, muss ein Standard Change ein geringes Risiko haben. Ein nachträgliche Post Implementation Review muss auch für Standard Changes durchgeführt werden. Das heißt, dass nachdem ein Change implementiert wurde, der definierte Test durchgeführt und dokumentiert werden muss, um zu ermitteln, ob der Change erfolgreich war. Für alle anderen Change Kategorien kann die Change Autorität entscheiden, ob ein Test in der Test-Umgebung notwendig ist. Falls entschieden wird, das kein Test notwendig ist, dann muss diese Entscheidung im Record dokumentiert werden. Dies ist notwendig um zu bestätigen, dass die Entscheidung keinen Test durchzuführen beabsichtigt war. Das selbe gilt für den Fallback-Plan. Manchmal ist ein Fallback-Plan nicht möglich bzw. sinnvoll z.B. aus finanziellen Gründen. Dies erhöht natürlich das Risiko einer Veränderung. Wenn es eine beabsichtigte Entscheidung ist, ohne Fallback-Plan zu arbeiten, dann muss das im Change Record festgehalten werden.

Change Priorität & Notfall Change

Die folgende Tabelle gibt einen Überblick für die Prioritätenund Ihre Relevanz für eine Veränderung.

Priorität	Beschreibung
„notfall“ (emergency)	Sollte eine Veränderung (Change) als „notfall“ (emergency) eingestuft werden, ist ein beschleunigtes Genehmigungs- und Implementierungsverfahren notwendig. Diese Priorität wird vergeben, wenn es bereits einen schweren Schadensfall (Major Incident) gibt. RFCs mit diesem Prioritätsvorschlag werden meist aus dem Incident und Problem Management gestellt und durch das Emergency Committee) (EC) bestätigt und somit genehmigt. „Notfall“ (emergency) bedeutet auch, dass Ressourcen von niedriger priorisierten Changes abgezogen werden können und andere Veränderungen verschoben werden müssen.
„hoch“ (high)	Eine Veränderung (Change) wird mit „hoch“ (high) priorisiert, wenn es einen potentiellen Schaden gibt. Er hat bei einer eventuell notwendigen CAB Sitzung (je nach Kategorie) eine hohe Priorität auf der Tagesordnung. „hoch“ (high) bedeutet auch, dass Ressourcen von niedriger priorisierten Veränderungen abgezogen werden können und es zu einer Neuplanung der Implementierungszeitpunkte aller Changes kommen kann.
„mittel“ (middle)	Eine Veränderung (Change), die als „mittel“ (middle) eingestuft wird, ist planbar und kommt meist aus dem Service Portfolio Managment. Gründe hierfür können sein: Neue bzw. Verbesserte Funktion an einem Service Korrekturen & Wartung
niedrig“ (low)	„ Eine Veränderung (Change) der Priorität „niedrig“ (low) ist wünschenswert aber nicht notwendig. Sie wird meist mit Veränderungen (Change) der Priorität „mittel“ (middle) umgesetzt.

Change Lebenszyklus

Status	Status	Beschreibung
new	new	der Change Management Prozess ist ausgelöst. Das Ticket ist entstanden und hat eine eindeutige Bezeichnung
aufgenommen-akzeptiert	recorded-accepted	Die Informationen des RFC werden in das Change-Record eingefügt. Jedes erforderliche Feld ist ausgefüllt. Ebenso darf der Antragsteller den Change auslösen
aufgenommen-abgelehnt	recorded-rejected	Der RfC wird abgelehnt. Der Grund wird auf dem Ticket dokumentiert und der Antragsteller informiert
aufgenommen-notfall	recorded-emergency	Der Antragsteller hat einen Notfall-Change geöffnet. Die Information im RFC war ausreichend um den Vorgang fortzuführen
klassifiziert	classified	Der Change wird klassifiziert. Jeder Kontrollfaktor ist definiert. Dies schließt Priorität und Kategorie mit ein.
autorisiert-abgelehnt	authorized-dismissed	Die Autorisierung für den Change wurde abgelehnt. Der Grund wird aufgenommen.
autorisiert-angenommen	authorized-approved	Der Change wird von der Change Autorität (CA) die für diesen Change relevant ist, autorisiert
implementiert	implemented	Der Change wurde geplant, getestet und implementiert. Die Aktivitäten wurden im Change Ticket aufgezeichnet.
dokumentiert	documented	Der Change wurde in der CMBD dokumentiert und die Dokumentation erfolgreich verifiziert.
abgeschlossen-fehlgeschlage	closed–failed	Der Change hat NICHT den Post implementation review (PIR) passiert.
fallback ausgeführt	fallback executed	Der Fallback wurde ausgeführt und wurde sowohl in der CMDB als auch im Change Record dokumentiert.
abgebrochen	cancelled	Der Change war NICHT erfolgreich und wurde abgebrochen
abgeschlossen-verifiziert	closed-verified	Der Change hat den Post Implementation Review erfolgreich passiert. Die Aktivität zum Abschluss wurde ausgeführt.

Change und Release Management

Es gibt zwei unterschiedliche Kategorieen von Changes:

Kategorie I: A -> A
Kategorie II: A -> B

Changes des ersten Kategories sind Kategorieischerweise durch das Incident Management beantragt. In diesem Fall ist z.B. ein Austausch Festplatte vom Kategorie Model A beantragt. Der Service und seine ihn definierenden Funktionen bleiben gleich. Das Auslösen des Release Management ist nicht notwendig. Model A wurde für den betroffenen Service bereits freigegeben. In diesem Fall existierte auch eine detaillierte Anweisung für die Installation und das Testen des Service. Keine neuen Tests von Servicefunktionen etc. müssen definiert und durchgeführt werden. In diesem Fall, kann das Change Management jederzeit den Change unter Berücksichtigung der Wartungsfenster planen. Im Falle eines Notfall Changes, ist der Service nicht oder eingeschränkt verfügbar daher muss der Change meist sofort also außerhalb des Wartungsfensters ausgeführt werden.

Im Fall eines Kategorie B Change muss das Release Management ausgelöst werden.

Das Release Management übernimmt die Planung und das Testen für das Change Management. Das Ergebnis des Release Management Prozesses muss an den Change Management Prozess zurückgegeben werden. Zwei Ergebnisse sind möglich.

Eine neue Version des Service ound/oder der daran beteiligten Komponenten wird freigegegebn
Die Freigabe wird mit einem dokumentierten Grund verweigert

Prozess

High Level Process Flow Chart

Die Grafik zeigt den Change Management Prozess und seine Aktivitäten, genau so wie die Lebenszyklen einer Changes.

Kritische Erfolgsfaktoren

Critical Success Factors (CSF):
Uneingeschränkte Einhaltung des Prozess
Enge Kooperation mit dem Configuration Management, Release und Service Portfolio Management
Keine Personalunion zwischen dem Change Manager und dem Configuration Manager
Hoher Anteil von Standard und geringfügigen Veränderungen
Hoher Anteil von Changes mit gering/mittel eingestufter Priorität

Key Performance Indicators (KPI)

Definition

Dauer jeder Aktivität (Zeitstempel beachten):

Change Aufnahmedauer =

ZS „Aufgenommen – zurückgewiesen“ – ZS „neu“ ODER
ZS „aufgenommen – akzeptiert“ – ZS „neu“ ODER
ZS “ aufgenommen – Notfall“ – ZS „neu“

Change Klassifikationsdauer=

ZS „klassifiziert“ – ZS „aufgenomen – akzeptiert “ ODER
ZS „autorisiert – bestätigt“ – ZS „aufgenommen – akzeptiert“

Change Notfallbehandlungsdauer =

ZS “ aufgenommen – akzeptiert “ – ZS „aufgenommen- Notfall“ ODER
ZS „implementiert“ – ZS “ aufgenommen- Notfall“

Change Autorisationsdauer =

ZS „authorisiert – abgelehnt“ – ZS „klassifiziert“ ODER
ZS „authorisiert – angenommen“ – ZS „klassifiziert“

Change Building, Test und Implementierungsdauer= ZS „implementiert“ – ZS “ authorisiert – angenommen “ *Change Dokumentationsdauer = ZS „dokumentiert“ – ZS „implementiert“
Change Evaluations und Abschlussdauer =

ZS „abgeschlossen – fehlgeschlagen“ – ZS „dokumentiert“ ODER
ZS „abgeschlossen – verifiziert“ – ZS „dokumentiert“

Change Fallback & Dokumentationsdauer = ZS „fallback ausgeführt“ – ZS “ abgeschlossen – fehlgeschlagen “
Change Umsetzungsdauer (ohne Emergency Umsetzungsdauer) = Change Annahme Dauer + Change Klassifikationsdauer + Change Autorisationsdauer + Change Building, Test und Implementierungsdauer + Change Dokumentationsdauer
Emergency Umsetzungsdauer = Change Recording Duration + Change Emergency Handling + Change Documentation Duration
Rekationsdauer = Change Recording Duration + Change Classification Duration + Change Authorization Duration Gemessen in Zeiteinheiten (z.B. Tag, Woche, Monat)
Offene Change Requests = alle Change Requests die NICHT im Status:

Abgeschlossen ODER
abgebrochen sind

Auswertung

Anzahl der aktuell offene Changes
Anzahl der durchschnittlichen offenen Changes pro Tag/pro Monat
Anzahl der geöffneten Changes pro Tag/pro Monat
Anzahl der gelösten Changes pro Tag/pro Monat
Anzahl der geschlossenen Changes pro Tag/pro Monat
Anzahl erfüllte Changes (Umsetzungsdauer der Veränderung <= vereinbarte Umsetzungsdauer für alle geschlossenen Veränderungen pro Tag/pro Monat)

ausgewertet wird die maximale, minimale und durchschnittliche Zeitdauer pro Kunde und/oder pro Service und/oder pro Priorität und/oder Kategorie

Prozessauslöser (Trigger)

Event Auslöser (Trigger)

Jeder Request for Change
Von einem Prozessbeteiligten in einem Supportprozess

Incident Management
Service Request Management
Event & Alert Management
Problem Management

Vom Kunden ausgelöst durch den Service Portfolio Management Prozess
Durch den Change Management Prozess selbst, wenn ein “Unter” Change benötigt wird.

Zeitliche Auslöser (Time Trigger)

Keine (Change Management ist normalerweise event-ausgelöst)

Prozessspezifische Regeln

jeder RFC löst die Entstehung eines neuen Change Record aus
der Change Bearbeiter ist verantwortlich für die Dokumentation jeder Aktivität im Change Record
der Change Verantwortliche muss den Change Agenten überprüfen
der Change Verantwortliche und Change Agent können ihre Pflichten/Verantwortungen nur übertragen, wenn sich die neue Gruppe / Person einverstanden erklärt
der darauffolgende Change Verantwortliche oder Change Agent müssen in den Change Record aufgenommen werden.
Der Change Verantwortliche und Change Agent sollten vorzugsweise eine Person anstatt einer Gruppe sein.
Jeder Change durchläuft eine Anzahl von standardisierten Aktivitäten und Prozeduren, um eine effektive und effiziente Abwicklung zu garantieren.
Jeder Change muss autorisiert werden.
Für jeden Change muss während der Change Klassifikationsaktivität eine Risiko- und Auswirkungsanalyse vorbereitet werden.
Jeder Change der riskiert den normalen Serviceablauf zu beeinträchtigen, muss vorsichtig abgeschätzt werden und ausreichend getestet werden, um eine Serviceunterbrechung oder eine Degradierung der Servicequalität zu vermeiden
Jeder Notfall Change ( emergency change) muss mit der Notfall Change Aktivität abgehandelt werden.
Jeder implementierte Change muss dokumentiert und nachgeprüft werden. (Post implementation Review).

Prozessaktivitäten

Change Recording

Der Request for Change (RFC) muss auf Vollständigkeit und formale Richtigkeit geprüft werden, z.B. es ist verifiziert, dass alle vorgeschriebenen Informationen vom Change Requester durch das RFC Formular bereitgestellt wurden. Sollte das nicht der Fall sein, oder sollte der Requester generell nicht autorisiert sein den RFC zu senden, kann das RFC abgelehnt werden. Der Change Record wird dann in den Status „aufgenommen-akzeptiert“, „aufgenommen-notfall“ oder „aufgenommen-abgelehnt“ gesetzt werden.

Aktivitätsspezifische Regeln

Change Requester wird auf die Person gesetzt, die den Change auslöst
Change Sponsor wird auf die Person gesetzt, die den Change ausgelöst hat, falls kein anderer Sponsor bekannt ist.
Change Agent wird auf “Change Management Team” gesetzt, falls es nicht einen verfügbaren Change Agenten gibt
Change Owner wird auch „Change Management Team“ gesetzt, falls keine andere Person als Change Verantwortlicher verfügbar ist.
Change Beschreibung Der RFC muss eine aussagekräftige Beschreibung des gewünschten Changes enthalten und ebenso eine verständliche rationale Angabe des Grundes für den Change.
Change Priority wird auf “3 (Middle)“ gesetzt, falls keine andere Priorität bekannt ist. Wenn ein Notfall Change erforderlich ist, muss die Priorität auf “1 (Notfall)” gesetzt werden.
Prozessauslöser wird gesetzt
Betroffene Service Mindestens ein Service muss definiert werden
Change Builder Mindestends eine Person der Serviceexperten oder Service Spezialisten Gruppe muss als Change Builder bestimmt werden. Dies kann auch eine ganze Gruppe sein, wenn mehrere Service betroffen sind.

Change Notfallbehandlung

Die Priorität “Notfall” muss vom Notfall Change Advisory Board (ECAB) bestätigt werden. Falls notwendig, kann das Testen vom ECAB ausgesetzt werden. Das ECAB muss alle Ressourcen bereitstellen und hat das Recht andere Changes zu verschieben.

Aktivitätsspezifische Regeln

Change Agent wird auf Emergency Change Advisory Board (ECAB) gesetzt
Change Owner wird auf ECAB gesetzt
Change Change Authorität wird auf ECAB gesetzt
Wenn die Priorität “Notfall” vom ECAB bestätigt ist, dann:
- Müssen der Antragsteller und Kunde informiert werden
- Werden der Change Builder, Change Tester und Change Durchführender vom ECAB bestimmt
- der Change Agent wird auf Change Builder gesetzt
- nach Planung des Changes muss der Change Agent auf Change Tester gesetzt werden
- nach einem erfolgreichen Testen, wird der Change Agent auf Change Durchführender gesetzt
Wenn ein Notfallchange vom ECAB bestätigt wurde, kann die Implementierung des Changes direkt in der Liveumgebung ausgeführt werden.
Notfallchanges müssen im Change Record oder der CMDB innerhalb von 5 Tagen dokumentiert werden.
Wenn die Priorität “Notfall” NICHT bestätigt ist, dann:
- Werden der Change Agent, Change Authority und Change Owner auf ihre vorherigen Werte gesetzt
- die Change Priorität wird auf einen anderen Wert als “Notfall” gesetzt

Change Klassifikation

Die Klassifikation des Changes ermittelt alle Steuergrößen für den, die für Entscheidungen hinsichtlich des Ablaufes wichtig sind. Um einen Change zu klassifizieren werden Priorität und Kategorie festgelegt. Die Priorität hängt oftmals von der Priorität der verwandten Störungen (Incident) bzw. Problemen ab , zusätzlich muss aber auch das Risiko des Changes hinsichtlich des Betriebes und damit potentiellen Unterbrechungen und/oder Degradierungen der Qualität berücksichtigt werden. Ein aufgenommener und akzeptierter Change muss kategorisiert werden und dann entsprechend seiner Kategorie weiterbearbeitet werden. Ein Standardchange (“Kategorie 0”) ist vorautorisiert. Der Record muss entsprechend der Standart Change Beschreibung vervollständigt werden Für kleine Changes (“Kategorie1”), ist die nächste Aktivität eine Risikoanalyse und ein Business Case. Falls Unterstützung benötigt ist, muss der entsprechende Delivery Prozess ausgelöst werden z.B. Security Implementation Assistance Bezogen auf das Ergebnis der Risikoanalyse kann eine Re-Klassifizierung notwendig sein. Für Major Changes (“Kategorie 2 oder 3”) muss geprüft werden, ob ein Service Design Package (SDP) existiert. Das Service Portfolio Management muss eventuelle als nächste Aktivität mit einbezogen werden, falls es keine existierende SDP gibt, die diesen Change abdeckt. Die Service Design Aktivität aktualisiert oder kreiert den SDP entsprechend um den Change abzudecken. Die nächste Aktivität hängt davon ab, ob der Kategorie bestätigt oder aktualisiert wird.

Activity Specific Rules

wenn der Kategorie „standard“ ist, wird der Change Verantwortliche und der Change Agent auf „Service Desk“ gesetzt
wenn der Kategorie NICHT „standard“ ist
o der Change Agent wird auf Change Builder gesetzt.
o Das Ergebnis der „Risk Analysis“ und es Business Case müssen im Change Record dokumentiert werden.
o die „Change Priorität“ ist dann entsprechend des Ergebnisses definiert. Die Priorität “Notfall” ist nicht länger möglich.
o Der „Change Kategorie“ wird unter Berücksichtigung des diagnostizierten Risikos aus der Risikoanalyse definiert
o Am Ende der Aktivität, wird der Change Agent auf den Change Owner gesetzt
Wenn der Kategorie „2 – Signifikant “ oder „3 – kritisch“ ist, müssen die Mitglieder des CAB definiert werden
Definiere die Change Autorität (CA)
o Für Kategorie 1 ist es der Service Verantwortliche (Owner)
o Für Kategorie 2 ist es das Change Advisory Board (CAB)
o Für Kategorie 3 ist es das Senior Management
Setzten weiter Steuergrößen soweit möglich
bestimme einen Wert für die Erwarteten Kosten. Dies basiert auf den Ergebnissen de Business Case

Change Autorisierung

In dieser Aktivität ist ein Change bestätigt, abgelehnt und abgebrochen. Change Autorisierung berücksichtigt die Priorität und den Kategorie des Changes, genauso wie die geplanten Kosten, Zeit und Ressourcengrenzen. Die Change Autorisierung muss im betreffenden Change Record dokumentiert sein. Die Besetzung der CA hängt vom Kategorie des Changes ab. Darum kann der CA auch der Service Verantwortliche des betroffenen Service sein, der das CAB oder nach einem beratenden Treffen des CAB auch die Geschäftsführung. Der Change Record wird dann auf den Status „autorisiert – bestätigt“ oder „ autorisiert – abgelehnt“ gesetzt, abhängig von den Stimmen des CS. Für eine Autorisierung müssen die folgenden Faktoren beachtet werden:

die Change Priorität und Kategorie (Risikoanalyse).
Projektkosten, Budget, Zeit und Ressourcengrenzen (Proof of Concept)

Aktivitätsspezifische Regeln

Bei Kategorie “1- geringfügig” wird die Change Autorität (CA) auf “Service Verantwortlicher” gesetzt
Bei Kategorie „2 – erheblich -„, die Change Autorität wird auf CAB gesetzt
Bei Kategorie „3 – weitreichend“, die Change Autorität wird auf Senior Management gesetzt ( nach Absprache mit dem CAB)
Nach der Auswahl der Change Autorität (CA) wird der Change Agent auf Change Autorität (CA) gesetzt
Die Bestätigung des Changes muss abgezeichnet, gescanned und an den Change Record angehängt werden.
Am Ende der Aktivität muss der Change Agent auf Change Verantwortlicher gesetzt werden.

Change Building, Testen und Implementierung

Bestätigte Changes sind während des Entstehens, dem Testen und der Implementierung koordiniert. Wenn die neue Hardwaremodelle oder Softwareprodukte erforderlich sind, die noch nicht released sind, muss der Release Management Prozess aktiviert werden. Release Management ist zuständig für die Zulassung der Konfiguratiuonsitems indem sie ihre Funktionalität und Genauigkeit, genauso wie ihre Austauschbarkeit oder Operationalität mit anderen Konfigurationsitems testet. Release Management sollte auch dem Change Management den Deployment Plan bereitstellen. Jeder Change muss mit einschlägiger und momentaner Dokumentation geliefert werden. Im Change Record wird festgelegt wann und wie die Dokumentation getestet werden muss.

Aktivitätsspezifische Rollen

ein Change Builder wird aus der Gruppe der Service Experten bzw. Service Spezialisten definiert
ein Change & Fallback Tester wird aus der Gruppe der Service Experten bzw. Service Spezialisten definiert
Der Implementierungsplan wird erstellt
Die Implementierung wird nach Plan getestet und die Testergebnisse werden im Change Record festgehalten.
Der Fallback Plan muss aufgezeichnet und verfügbar sein.
Der Fallbackplan muss getestet und seine Ergebnisse im Change Record festgehalten werden.
Der Funktionstest muss beschrieben werden
Der Funktionstest muss durchgeführt sein und seine Ergebnisse im Change Record festgehalten werden.

Change Dokumentation

In dieser Aktivität wird der Change in der CMDB dokumentiert und die Informationen benutzt, die vom Change Record zur Verfügung stehen. Die CMDB wird dann über den Configuration Management Prozess aktualisiert. Im Besonderen muss das Configuration Management folgendes aufnehmen:

jede Veränderung an Attributen von Configurations Items (CI)
jede Veränderung in Bezug Relationen
in manchen Fällen müssen Richtlinien und Vorgaben angepasst werden
Nach einer erfolgreichen Verifikation, wird der Change Record auf “dokumentiert” gesetzt.

Aktivitätsspezifische Regeln

Der Change Agent (momentan der Change Implementer ) löst den Configurations Management Prozess aus um die CI Attribute und /oder die Beziehungen in der CMDB zu aktualisieren.
Der Change Agent (momentan der Change Implementer ) veranlasst dass der Prozess Manager die Richtlinien und Vorgaben einer Prozedur aktualisiert, falls relevant.
Es ist nicht verboten dass der Change Implementer und der Configuration Librarian die selbe Peron sind.
Der Change Verantwortlicher muss die Dokumentation verifizieren, deshalb wird der Change Agent wird auf Change Verantwortlicher gesetzt
Wenn die Verifikation NICHT OK ist, wird der Change Agent auf Change Implementer gesetzt, um die Dokumentation zu überprüfen

Change Auswertung (Evaluation) und Abschluss (Closure) (PIR)

In dieser Aktivität, wird der Erfolg eines implementierten Changes ermittelt. Eine nachträgliche Implementierungsprüfung (Post Implementation Review (PIR)) wird durchgeführt, bezogen auf die Testverfahren, die während der Change Building Phase der Change Koordination definiert wurden. Nachdem eine PIR durchgeführt wurde, wird das Ergebnis dokumentiert. Wenn der PIR nicht erfolgreich ist, muss ein Fallback laut Plan ausgelöst werden. Der Change Record wird auf den Status “abgeschlossen-verifiziert” oder „abgeschlossen-fehlgeschlagen“ gesetzt, abhängig dem Ergebnis des Changes. Der Evaluationsbogen sollte für die PIR folgendes berücksichtigen:

Hat der Change die erwünschte Ziele erreicht?
Wurde der Change rechtzeitig implementiert?
Traten irgendwelche Störungen auf, während der Change den Prozess durchlaufen hat?
Wurde der Change ausgeführt und das bereitgestellte und zugesagte Budget zu überschritten?
Wurde der Change dokumentiert und die CMDB entsprechend aktualisiert?
Folgte jeder Beteiligte dem Ablauf des Prozesses?
Wurden Informationen zu irgendeinem Zeitpunkt des Prozesses vermisst die zu einer notwendigen Entscheidung gebraucht wurden?
Wurden die Interessengruppen über den Change Prozess informiert, in Übereinstimmung mit dem RASCI Chart ?
Falls anwendbar, wurden Changes and den Polices und Regeln in der Service Dokumentation überwacht (Test of documentation)?

Aktivitätsspezifische Regeln

Zu Beginn wird der Change Agent auf Change & Fallback Tester gesetzt
Das Ergebnis muss aufgezeichnet werden
Wenn der PIR erfolgreich ist, wird der Change Agent auf Change Verantwortlicher gesetzt
Alle notwendigen Abschlussarbeiten werden durchgeführt
Wenn der PIR NICHT erfolgreich war:

Der Change Agent wird auf Change Durchführender gesetzt
Dokumentation des Grundes im Change Record

Change Fallback and Dokumentation

Im Falle eines fehlgeschlagenen Changes, welcher durch eines negatives Ergebnis eines PIR erkannt wird, wird der Change zurückgebaut indem der Fallbackplan durchgeführt wird. Dieser Aktivität wird entsprechend dem Fallback Plan, der ein Teil des Change Record ist, abgearbeitet. Der Change Record wird dann auf den Status „Fallback ausgeführt“ gesetzt.

Aktivitätsspezifische Regeln

Zu Beginn wird der Change Agent auf Change Implementer gesetzt
Der Plan wird ausgeführt
Der Change Agent wird auf den Change & Fallback Tester gesetzt
Der Service wird getestet
Testergebnisse müssen dokumentiert werden
Wenn der Task Testen erfolgreich war:
- Wird der Change Agent auf den Change Verantwortlichen gesetzt
- der Configuration Management Prozess wird ausgelöst für die Dokumentation in der CMDB
- der Antragsteller des Changes wird über den Rollback informiert
wenn der Task Testen NICHT erfolgreich war:
- der Change Agent wird auf den Change Implementer gesetzt
- Gründe für die fehlgeschlagene Implementierung müssen im Change Record unter „zusätzliche Anmerkungen”
- Auslösen einer hierarchischen Eskalation und Planung weiterer Maßnahmen
- Eventuell Übergang in eine Emergency Change