IT Changemanagement – Ein erster Leitfaden

Die Notwendigkeit von regelmäßigen Änderungen an IT Infrastrukturen, Services oder Dokumentationen steht hinsichtlich der heutzutage hoch dynamischen Businesswelt außer Frage. Geht es jedoch um das kontrollierte Abhandeln dieser Änderungen und welche wie von wem dokumentiert werden müssen, scheiden sich schnell die Geister. Wer muss den Change Request (CR) stellen? Welche Objekte werden überhaupt im Rahmen des Change Management betrachtet? Welche CR’s sollten im CAB (Change Advisory Board) behandelt werden?

Diese und weitere Fragen sind nicht einfach zu beantworten. Vielleicht ist auch schon ein Change Management etabliert, doch Nutzen und bürokratischer Aufwand stehen immer wieder im Zwiespalt und werden regelmäßig hinterfragt und diskutiert. Wo und wie kann man ansetzen, um hier Abhilfe zu schaffen?

Wie fange ich an?

Bevor man sich als Change Manager oder anderweitig Beteiligter an eine punktuelle Verbesserung oder Einführung eines IT Change Management macht, steht Allem voran immer zunächst du Überlegung „Welches Ziel, bzw. welchen konkreten Zweck möchte ich mit dem Change Management erreichen?“ – in Neudeutsch auch die Critical Success Factors  kurz CSF genannt. Denn wie bei fast allen Prozessen, bzw. dem gesamten ITIL Framework ist es am wichtigsten, sich nicht auf das Ziel, möglichst „ITIL-konform“ zu sein, sondern den Zweck und den Mehrwert für das eigene Business zu konzentrieren und sich dahingehend dann mit den passenden Vorgehensweisen aus den ITIL Best Practices auszustatten.

Konkret könnten dies bspw. folgende CSF sein:

· Reduzierung des Geschäftsrisikos  durch ungeplante Ausfälle kritischer IT Systeme
· Sicherstellen, dass alle Änderungen an IT Komponenten kontrolliert und dokumentiert ablaufen

Praktisch orientierte Messwerte (KPI) zur Erreichung dieser Ziele könnten bspw. sein:

· Reduzierung der Anzahl von Incidents, die auf Changes zurückzuführen sind
· Reduzierung von nicht dokumentierten Abweichungen bei Audit der SOLL/IST Zustände der IT Umgebung

Weitere, allgemeine Prozessziele:

·  das Risiko von Störungen, verursacht durch Änderungen an der IT minimieren
·  Änderungen in einer vorhersehbaren, wiederholbaren, verbesserten, und nachvollziehbaren Weise einführen
·  Offene Kommunikationskanäle pflegen, um bei der Durchführung einer Veränderung einen reibungslosen Übergang zu erreichen
·  Die Sichtbarkeit und Mitteilung von Änderungen an Business und Support-Mitarbeiter erhöhen
·  Genaue Einschätzung der Kosten für die vorgeschlagenen Änderungen bieten, bevor sie entstehen
·  Eine verbesserte Fähigkeit bieten, eine große Anzahl von Änderungen zu managen.
·  Eine verbesserte Wahrnehmung der Qualität der IT bieten.

Erst wenn eine derartige Zielformulierung und die dafür zu überprüfenden Messwerte mit Themenvertretern (häufig Gruppen- oder Abteilungsleiter oder einzelne Themenverantwortliche) aller IT Abteilungen gefunden wurde, sollten die nächsten Schritte überdacht werden.

Rollen und Gremien

Zum besseren Verständnis dazu zunächst ein Vorschlag zur Definition einiger Begrifflichkeiten und Beteiligten Rollen und Gremien:

· Change Manager (CM) – Für gewöhnlich der Prozesszuständige (responsible) für den Change Management Prozess und Vorsitzender des Change Advisory Boards

·  Change Advisory Board (CAB) – Regelmäßig (wöchentlich/2-wöchig) stattfindendes Gremium zur Unterstützung des Change Managers zur Change Beurteilung. Das CAB setzt sich auch Themenverantwortlichen (DB, Netzwerk, Collaboration, usw.) und Stakeholdern des Business zusammen. Häufig wird das CAB aus einem Kernteam sowie dynamisch je nach anstehenden Changes benötigten Businessteilnehmern (also Kunden!) gebildet. Das CAB sollte keine Diskussionsforum der IT sein, da hier IT und Kunden eine direkte Schnittstelle haben und sich der Kunde an der Stelle überfordert fühlen könnte. Also Fokus auf Vorbringen von verständlichen Ergebnissen und Untersuchungen zur Beurteilungsgrundlage des vorgelegten Change.

·  Request for Change (RfC): der beantragte Change Record (CR). Aus meiner Sicht ist die begriffliche Unterscheidung von CR und RfC jedoch durchaus relevant, da ggfs. der Antragsteller (also Ersteller des RfC) ganz andere Informationen und Beweggründe für den RfC vorlegt, als vielleicht nachher die implementierende, also umsetztende Person an Einwände und mögliche Risiken bspw. von Systemseite her einzuwenden hat.

·  Change Record (CR): Der eigentliche, gesamte Vorgang im entsprechenden ITSM Tool (oder auch Excel Tabelle). Meist durch eine fortlaufende Nummer mit gleichem Prefix realisiert (bspw. CR001283).

·  Changetypen: Häufigste Einteilung unterschiedlicher Changevarianten in normal change, standard change und emergency change. Der normal change ist ein üblicher „non-standard change“. Der standard change bedient sich wiederholender Tätigkeit und ist in Auswirkung und Risiko überschaubar – er stellt somit ein wichtiges Werkzeug zur Verringerung des bürokratischen Aufwands im Change Management bereit. Zuguter Letzt bleibt dann noch der emergency change, dabei handelt es sich um eine Notfallsituation, die schnelles Handeln und zügige Reaktionsfähigkeit durch ein stark verkürztes Genehmigungsverfahren erfordert. Nicht selten wird ein EC aus durch ein sog. eCAB (Emergency Change Advisory Board) getragen, welches als „loses“ Gremium meist in Einzelgenehmigung des Change zur Durchführung genehmigt oder gar erst reaktiv meldet und genehmigt.

Prozessdefinition

Folglich steht anschließend die Überlegung, wie diese Rollen und Zuständigkeiten in der Praxis realisiert werden.

Das folgende Diagramm zeigt den High Level Prozess Change Management.

High Level Prozessmodell

Subprozesskurzbeschreibungen

Die Subprozesse des High Level Prozessmodell in Kurzbeschreibung

Nummer	Subprozess	Ziel
1.1	Change kategorisieren	Ziel des ersten Subprozesses ist die adäquate Einteilung eines RfC in die richtige Changekategorie. Aus der Wahl der Kategorie leiten sich unterschiedliche Prozesswege für den Change ab.
1.2	Change prüfen	Nachfolgend wird der kategorisierte RfC in detaillierterer Form geprüft. Kriterien wie Zeitraum, Risiko, Dringlichkeit, Konsequenzen und Ressourcen werden geprüft und festgelegt
1.3	Change implementieren	Der RfC ist an diesem Punkt kategorisiert, geprüft und geplant und somit als Change zur Änderung angenommen. Der Changemanager initiiert die Umsetzung des Changes zum genehmigten Zeitpunkt und kontrolliert dabei die benötigte Dokumentation der Umsetzung in Form des Feedbackformulars.
1.4	Change abschließen	Ist der Change umgesetzt, werden anhand der Rückmeldung die Punkte des Feedbackformular (Change erfolgreich ja/nein, Komplikationen?, Erkenntnisse aus dem Change, Aufwand Soll/Ist, etc.) durch den Changemanager und/oder des CAB´s überprüft. Die Änderungen müssen ggfs. zur CMDB übertragen werden sowie noch geprüft wird, ob der Change für die Zukunft als Standard Change Vorlage übernommen werden soll.

Subprozesseinzelbeschreibungen

Change kategorisieren (1.1)

Subprozess 1.1 Change kategorisieren

Der Lebenszyklus eines Change beginnt mit einem sog. Request for Change, kurz dem RfC. Als Eingangskanal kann der Antragsteller entweder seinen RfC direkt im Change Management Tool stellen oder aber per Mail an eine zentrale Mailadresse stellen. Der Changemanager prüft den eingegangenen Antrag auf Vollständigkeit und stellt ggfs. Rückfragen an den Antragsteller. Ist der Antrag komplett, kann er released werden. Nachdem folgend geprüft wurde, ob für den beantragten Change bereits eine passende Standard-Change Vorlage vorhanden ist, wird der Change durch den Change Manager kategorisiert. Dabei unterscheidet der Change Manager nach folgenden Einteilungen.

• Standard Change (ggfs. zusätzliche Templates für pre-approved Changes)
• Normal Change (ggfs. zusätzliche Aufteilung in minor, major und significant)
• Emergency Change

Außer dem direkt zu genehmigenden Standard Change werden die RfC´s mit den restlichen Kategorien auf den Change Status „prüfen“ gesetzt und die ausgewählte Kategorie wird vermerkt. Der RfC ist somit korrekt kategorisiert und kann zur Prüfung vorgelegt werden.

Change prüfen (1.2)

Subprozess 1.2 Change prüfen

Nachdem die Kategorisierung eines RfC erfolgt ist, haben Normal Changes sowie Emergency Changes eine genauere Prüfung (Risiken, Dringlichkeit, Konsequenzen und Ressourcen) zu durchlaufen. Fiel die Wahl der Kategorie eines RfC auf die Normal Change Kategorie 1, führt der Change Manager diese Prüfung sowie Planung des Zeitrahmens eigenständig durch und setzt nach erfolgreicher Prüfung den Status des RfC auf genehmigt. Ergibt eine Prüfung ein negatives Ergebnis, wird der RfC abgelehnt und eine nachvollziehbare (!) Begründung an den Antragsteller versendet.

Fällt die Wahl auf die Normal Change Kategorien 2 oder 3 (zusätzliche Zustimmung der IT-Steuerungsgruppe), wird der RfC gemeinsam im Change Advisory Board (CAB) auf dieselben Kriterien wie zuvor geprüft. Nachdem die Ergebnisse der Prüfung festgehalten wurden, wird auch hier der RfC auf Status „planen“ gesetzt oder im anderen Fall eine nachvollziehbare Begründung der Ablehnung an den Antragsteller versendet.

Im Sonderfall eines besonders dringenden Change, kann ein RfC mit der Kategorie Emergency Change versehen werden und durchläuft mit dem Emergency Change Advisory Board (ECAB) ein beschleunigtes Umsetzungsverfahren.

Change implementieren (1.3)

Subprozess 1.3 Change implementieren

Tritt einer der 3 möglichen Eingangswege „Emergency Change evaluiert“, „Change zur Implementierung genehmigt“ oder „Standard Change identifiziert“ ein, beginnt der Subprozess der Change Implementierung. Der Change Manager initiiert eingangs die Umsetzung des Change durch den Changeverantwortlichen. Nach der Umsetzung des Change wird beurteilt, ob die Umsetzung erfolgreich war. Ist dem nicht so, ist unverzüglich der zuvor im RfC aufzuführende Fallbackplan einzuleiten und umzusetzen sowie Feedback an den Change Manager zu leisten.

Ist die Umsetzung erfolgreich verlaufen, kann der Change im Falle eines Standard Changes nach ggfs. notwendiger Pflege der CMDB auf Status „abgeschlossen“ gesetzt werden. Bei Bedarf kann ein erstmaliger Standard Change als Vorlage hinterlegt werden, damit dieser künftig wiederverwendet werden kann.

Ist der umzusetzende Change kein Standard Change, wird vom Changeverantwortlichen Feedback an den Change Manager zugesandt. Der Change Manager entscheidet dann anhand des Feedbacks, ob der Change so umgesetzt wurde wie das Ziel des Change es deklariert hat. Um die genauere Betrachtung des Change im CAB zu initiieren sowie die weiteren Abschlusskriterien des Change zu durchlaufen, wird der Change dem Subprozess „Change schließen“ übergeben.

Change abschließen (1.4)

Abbildung 6: Subprozess 1.4 Change abschließen

Nachdem ein Normal- sowie Emergency Change durchlaufen ist, wird der Subprozess „Change abschließen“ durchlaufen. Der abschließende Subprozess gewährleistet das kontrollierte Abschließen des Change, sowie die korrekte Dokumentation und Information bzgl. der Änderungen, die durch den Change aufgetreten sind.

Zunächst ist zu prüfen, auf welchen Ursprung der gemeldete RfC ergründet. Ist der Change durch ein Problem, respektive dem Problem Manager beantragt worden, ist dieser noch einmal separat darüber zu informieren.

Bevor nun im CAB die Durchführung eines PIR (Post Implementation Review) auf Basis des Feedback und ggfs. weiteren Input der Beteiligten geschehen kann, wird durch den Changer Manager überprüft, ob das Feddback als Diskussionsbasis vorliegt. Ist dem nicht so, wird das Feedback erneut vom Changeverantwortlichen angefordert.

Mit vorliegendem Feedback, sowie den Anwesenden Inputgebern, kann der Verlauf, eventuelle Komplikationen, Stand von Soll/Ist, sowie der generelle Erfolg oder Misserfolg des durchlaufenden Change im Rahmen des Post Implementation Reviews (PIR) beurteilt werden. Die Ergebnisse werden dem Change vermerkt, ggfs. werden durch den Change Manager Änderungen an der CMDB eingetragen und ggfs. wird abschließend noch die Entscheidung getroffen, ob der Change künftig als Standard Change Vorlage zu deklarieren ist.

RACI Matrix und Rollenbeschreibungen

Aktivitäten			Rollen
			Antragsteller	Change Manager	CAB IT	CAB Kunde	Process Owner	Change- verantwort- licher
RfC erstellen			R	A, I, C
RfC prüfen			I	R
Change bewerten				R, A, I	I	I	I	C, R
Autorisieren des Changes			I	A, C, I	R	R	I	I
Planung des Changes			C, I	A, C, I	I	I	I	R
Koordinierung der Implementierung des Changes			I	A, I	I	I	I	R, A
Review und schließen des Change Records			C, I	R, A	I	I	I	C, I

Antragsteller (Falls abweichend von Changeverantwortlicher)

• Verantwortlich für die möglichst vollständige Weitergabe seines Informations- und Kenntnisstandes bei Einreichen eines RfC
• Ansprechpartner bei Rückfragen zur Beurteilung des RfC

Changemanager

• formale Prüfung eingereichter Changes (alle notwendigen Eingaben gemacht, Erklärungen verständlich, plausibel und nachvollziehbar, rechtzeitig eingereicht, …)
• Vorbereitung des CAB (Terminorganisation, Verteilung der Tagesordnung)
• Mailverteiler bei Genehmigung vervollständigen

Changeverantwortlicher (ggfs. auch Rollenpflichten des Antragstellers)

• inhaltlich Abstimmung des Changes inklusive Abstimmung von Downtimes und Einschränkungen mit den Betroffenen
• rechtzeitige Erstellung des Changes in officeAsset
• Vorstellung des Changes im CAB
• Zielgruppengerechte Information an Betroffene Anwendergruppen

CAB (IT/Kunde)

• Beurteilung der eingereichten Changes mit entsprechender Kategorie
• Einbeziehung einzeln relevanter Personen zum jeweils zu besprechenden Change
• Gemeinsamer PIR auf Basis der Rückmeldung aus dem Feedbackbogen und ggfs. Weiterem Input der Beteiligten

Prozessschnittstellen

Jeder Prozess wird durch ein Ereignis oder eine Aktivität ausgelöst und zugeordnete Artefakt(e), und erzeugt eien Output, der typischerweise in einen anderen Prozess mündet.

Interfaces

Dieser Prozess hat eine Schlüsselbeziehung oder Abhängigkeit mit den folgenden ITSM-Prozesse:

• Incident Management
• Problem Management
• Request Fulfillment
• Access Management
• Capacity Management
• Service Portfolio Management
• Service Asset and Configuration Management.

Inputs

Ggfs. vorhandener Input für den Prozess:

• Event Report
• Incident Report
• Problem Report
• Service Requests
• Security Report
• Problem Report
• Aktuelle Kosten
• Plan for change and release
• Grund für den Change
• Request for Change
• Forward Schedule of Changes (FSC)
• Service requirements
• Test Ergebnisse und Reports

Outputs

Ggfs. vorhandener Output für den Prozess:

• Aktualisierte Service Informationen
• Request for Change (RfC)
• Genehmigter RfC
• Abgelehnter RfC
• Änderungen an Services
• Neue , geänderte oder gelöschte Assets oder CIs
• Change Record und Reports
• Release Kalender und Benachrichtigungen
• Strategien zur Verbesserung
• Performanz von Service Requests
• Knowledge und Expertise

Fazit

Ich hoffe, dass mit diesen Rahmendaten ein erstes Change Management etabliert werden kann. Selbstverständlich ist auch das Change Management nach CSI kontinuierlich weiterzuentwickeln und besonders aus Kunden- sowie aus IT-interner Sicht immer wieder zu hinterfragen. Der Mehrwert sollte im Vordergrund stehen und jedem gut vermittelt werden können. Bürokratie und ‚Vorschriftenreiterei‘ wird dem Change Management Prozess Verwehrung und negative Vorbehalte einbringen und sind zu vermeiden. Änderungen gemeinsam zu planen, ggfs. betroffene Fraktionen durch die Auswirkungen zu identifizieren und anschließend die richtigen Personen informiert zu haben, wird in jedem Unternehmen bei engagierter Durchführung schnell als Mehrwert vermittelt werden können. Konstruktiver und offener Umgang innerhalb der Teams werden zu guter Letzt ein erfolgreiches IT Changemanagement auf den Weg bringen können.

Ich wünsche gutes Gelingen und freue mich über Feedback,

Jan