SP5: Bewerten und Koordinieren von Changes
Prozessname: Bewerten und Koordinieren von Changes - Teil von: Unterstützende Service-Management-Prozesse
Vorhergehender Prozess: Verwalten von Konfigurations-Informationen
Nächster Prozess: Managen von Projekten
Prozess-Beschreibung
Der YaSM-Prozess "SP5: Bewerten und Koordinieren von Changes" 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.
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
"Bewerten und Koordinieren von Changes " 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 "Bewerten und Koordinieren von Changes" 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.
Change-Richtlinie [*]
- Die Change-Richtlinie beschreibt und kommuniziert das in der Organisation angewandte Verfahren zum Umgang mit Änderungen an Konfigurations-Elementen (CIs). Um effektiv zu sein, muss die Richtlinie vom oberen Management unterstützt und allen Betroffenen bekannt gemacht werden.
Informationen zum Change-Status
- Aktuelle Status-Informationen zur Implementierung eines Changes. Diese Informationen werden dem Change-Manager von den verschiedenen Prozessen zur Verfügung gestellt, die freigegebene Changes implementieren. Der Change-Manager wird so in die Lage versetzt, die Change Records und die Change-Planung aktuell zu halten.
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.
| 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 | - | - |
[ Infobox ]
| Link zu dieser Seite: | https://yasm.com/wiki/de/index.php/SP5:_Bewerten_und_Koordinieren_von_Changes |
| Sprachversionen: | Deutsch | English |
| Image: | YaSM SP5: Bewerten und Koordinieren von Changes (.JPG) |
| Autoren: | Stefan Kempter  und
Andrea Kempter - IT Process Maps. |
Prozess-Beschreibung › Sub-Prozesse › Prozess-Outputs › Kennzahlen › Rollen
