SP5: Bewerten und Koordinieren von Changes

 

Prozessname: Bewerten und Koordinieren von Changes - Teil von: Unterstützende Prozesse

Vorhergehender Prozess: Verwalten von Konfigurations-Informationen

Nächster Prozess: Managen von Projekten

 

Prozess-Beschreibung

Der Change-Management-Prozess in YaSM fungiert als 'Gatekeeper': Er gewährleistet, dass Änderungen bezüglich der Serviceangebote des Service-Providers sowie der zugrunde liegenden Komponenten erst nach sorgfältigem Abwägen der Risiken und möglichen Nebeneffekte erfolgen.

Abbildung 1: 'Bewerten und Koordinieren von Changes'. - YaSM unterstützender Service-Management-Prozess SP5.

Hierzu ergeht von anderen YaSM-Prozessen, bei denen eine Änderung erforderlich ist, ein Request for Change (RFC) an den Change-Manager. Je nachdem, welche Genehmigungsebene zuständig ist, wird der betreffende RFC dann entweder vom Change-Manager oder vom Change Advisory Board (CAB) bewertet.

Für die Bewertung von Notfall-Changes wird ein besonderes Verfahren angewandt, z.B. wenn die Lösung eines Major Incidents notfallbedingt die Implementierung eines nicht standardmäßig freigegebenen Changes erforderlich macht.

In diesem Zusammenhang sind Change-Modelle ein wichtiges Instrument zur Verringerung des Arbeitsaufwands für den Change-Manager und das CAB. Change-Modelle werden für die Definition von "Standard-Changes" verwendet, d.h. für bekannte Changes mit geringem Risiko, die ohne Einschalten des formalen Change-Bewertungs-Prozesses implementiert werden können.

 

Sub-Prozesse

YaSM Change-Management beinhaltet die folgenden Sub-Prozesse:

 

SP5.1: Unterstützen der Bewertung von Changes

Prozessziel: Bereitstellen und Pflegen der Werkzeuge für eine effektive und effiziente Verwaltung von Changes.

SP5.2: Erfassen und Prüfen von RFCs

Prozessziel: Herausfiltern von Requests for Change (RFCs), die nicht alle erforderlichen Informationen für eine Bewertung enthalten oder für nicht machbar erachtet werden.

SP5.3: Bewerten von Notfall-Changes

Prozessziel: Schnellstmögliches Bewerten und Freigeben von Notfall-bedingten Changes. Dieser Prozess wird aufgerufen, wenn normale Abläufe zum Bewerten von Changes nicht angewandt werden können, da z.B. ein Notfall unmittelbares Eingreifen erfordert.

SP5.4: Bewerten von Changes (Change-Manager)

Prozessziel: Bestimmen der zutreffenden Autorisierungs-Ebene für die Bewertung eines vorgeschlagenen Changes. Bedeutende Changes werden an das CAB weitergeleitet, während weniger bedeutende Changes unmittelbar vom Change-Manager bewertet und freigegeben werden.

SP5.5: Bewerten von Changes (CAB)

Prozessziel: Bewerten und Autorisieren eines vorgeschlagenen Changes durch das Change Advisory Board (CAB). Falls erforderlich, werden höhere Genehmigungs-Ebenen in den Freigabe-Prozess mit einbezogen (z.B. die Geschäftsleitung).

SP5.6: Überwachen von offenen Changes

Prozessziel: Fortwährend offene Changes in Hinsicht auf ihren Implementierungs-Status überwachen, und - falls erforderlich - korrigierende Maßnahmen einleiten.

SP5.7: Nachprüfen und Schließen von Changes

Prozessziel: Bewerten des Verlaufs der Change-Implementierung und der erreichten Ergebnisse, um sicherzustellen, dass eine komplette Historie aller Aktivitäten aufgezeichnet wurde; Vergewissern, ob alle Fehler analysiert und die für die Zukunft wichtigen Erfahrungen dokumentiert worden sind.

 

Prozess-Outputs

Die folgenden Dokumente und Records werden von 'Change-Management' erzeugt. YaSM-Datenobjekte [*] sind mit einem Sternsymbol markiert, und andere Objekte werden in grau dargestellt.

 

Bericht zur Change-Bewertung

Die Ergebnisse einer Change-Bewertung werden in einem Bericht zur Change-Bewertung dokumentiert. Jeder Nicht-Standard-Change erfordert vor dessen Autorisierung eine formale Bewertung. Bestimmte Changes erfordern eine ausführlichere Begutachtung als andere, somit hängt der Inhalt des Bewertungs-Berichts von Art und Umfang des vorgeschlagenen Changes ab. [*]

Bericht zur Change-Nachprüfung

Die Ergebnisse einer Change-Nachprüfung werden in einem entsprechenden Bericht festgehalten. Change-Nachprüfungen (Post-Implementation Reviews, PIR) werden durchgeführt, nachdem ein Change implementiert worden ist. Ziel ist, zu bestimmen, ob der Change erfolgreich war; weiterhin sollen Verbesserungs-Potentiale für künftige Changes ermittelt werden. [*]

CAB-Protokoll

Das CAB-Protokoll dokumentiert die Themen und Entscheidungen eines Change Advisory Board (CAB) Meetings. Ein Entwurf dieses Dokuments kann zur Vorbereitung des CAB Meetings verteilt werden, um die Mitglieder des CAB über die zu behandelnden Themen zu informieren. [*]

Change Record

In einem Change Record sind alle Einzelheiten eines Changes enthalten; er dokumentiert somit den Lebenszyklus eines einzelnen Changes. Zu Beginn beschreibt ein Change Record einen Change-Antrag (Request for Change, RFC), der vor der Implementierung des Changes zu bewerten und freizugeben ist. Weitere Informationen werden im Verlauf des Changes hinzugefügt. [*]

Change-Modell

Change-Modelle beschreiben Verfahren zum Umgang mit wiederkehrenden Changes. Change-Modelle können für Changes jeder Tragweite erstellt werden; oft werden Sie zur Definition von Standard-Changes eingesetzt (vorab freigegebene Changes mit geringem Risiko, wie z.B. die Aufrüstung eines Client-PCs). Change-Modelle sind ein wichtiges Hilfsmittel, um die Arbeitsbelastung des Change-Managers und des CABs zu reduzieren. [*]

Change-Planung

In der Change-Planung (Change Schedule) sind alle vorgeschlagenen und genehmigten Changes mit den geplanten bzw. tatsächlichen Implementierungsterminen aufgeführt. Die Change-Planung wird manchmal auch als Forward Schedule of Changes bezeichnet, obwohl sie auch Informationen zu Changes enthält, die bereits implementiert wurden. [*]

Nachricht über Change-Autorisierung

Eine Information bezüglich des Autorisierungs-Status eines Changes. Eine solche Information wird an den Initiator eines Changes gesendet, um diesem mitzuteilen, ob der Change autorisiert oder zurückgewiesen wurde. Im Falle einer Zurückweisung kann die Benachrichtigung Empfehlungen enthalten, wie der Change geändert werden muss, um eine Autorisierung zu erhalten.

Vorschlag zur Prozess-Änderung

Ein Vorschlag zur Änderung eines oder mehrerer Service-Management-Prozesse. Vorschläge für Prozess-Änderungen oder -Verbesserungen können an jeder Stelle innerhalb der Organisation entstehen.

 

---

Anmerkungen:

[*] "YaSM-Datenobjekte" sind Dokumente und Records, für die YaSM detaillierte Empfehlungen bereithält: Für jedes YaSM-Objekt gibt es eine Checkliste (siehe Beispiel), die die typischen Inhalte beschreibt, und ein Lifecycle-Diagramm, das darstellt, wie sich der Zustand des Objekts ändert, während es von verschiedenen YaSM-Prozessen erstellt, geändert, gelesen und archiviert wird (siehe Beispiel).

"Andere Objekte" sind eher informelle Daten oder Informationen. Es gibt aus diesem Grund keine zugehörigen Lifecycle-Diagramme oder Checklisten.

 

Prozess-Kennzahlen

Prozesskennzahlen werden benötigt, wenn gemessen werden soll, ob die Service-Management-Prozesse "zufriedenstellend" laufen.

Vorschläge zu geeigneten Prozess-Kennzahlen entnehmen Sie der Liste von Kennzahlen zum Prozess zur Change-Bewertung.

 

Rollen und Verantwortlichkeiten

Prozess-Owner: Change-Manager

• Der Change-Manager kontrolliert alle Changes über ihren gesamten Lebenszyklus hinweg. Sein wichtigstes Ziel ist, nützliche Änderungen zu ermöglichen und dabei störende Auswirkungen auf den laufenden Betrieb so gering wie möglich zu halten. Bei weitreichenden Veränderungen bindet er das Change Advisory Board (CAB) mit ein.

 

Verantwortlichkeits-Matrix: "SP5: Bewerten und Koordinieren von Changes"

YaSM-Rolle / Sub-Prozess		CAB	Change-Mgr.	Change-Owner	Config.-Mgr.	ECAB
SP5.1	Unterstützen der Bewertung von Changes	R	AR	-	-	-
SP5.2	Erfassen und Prüfen von RFCs	-	AR	R	-	-
SP5.3	Bewerten von Notfall-Changes	-	AR	-	-	R
SP5.4	Bewerten von Changes (Change-Manager)	-	AR	-	R	-
SP5.5	Bewerten von Changes (CAB)	R	AR	-	R	-
SP5.6	Überwachen von offenen Changes	-	AR	-	-	-
SP5.7	Nachprüfen und Schließen von Changes	R	AR	R	-	-

 

Anmerkungen

Basiert auf: Der Change-Bewertungs-Prozess aus der YaSM-Prozesslandkarte.

Von:  Stefan Kempter   und  Andrea Kempter , IT Process Maps.

 

Prozess-Beschreibung  › Sub-Prozesse  › Prozess-Outputs  › Kennzahlen  › Rollen