Rollen und Verantwortlichkeiten im ITSM Change-Management-Prozess, Ziele, die 7 Rs sowie Unterschiede zwischen ITIL v3 und v4 – eine Geschichte für mehr Durchblick im ITSM.
Inhalt:
Änderungen in der IT können schnell zu Problemen führen: Sei es der simple Austausch eines Arbeitsplatzrechners, die Einführung einer neuen Software, der Wechsel in die Cloud oder gestiegene Sicherheitsanforderungen. Um solche Neuerungen im Unternehmen optimal umzusetzen, helfen fest definierte Prozesse. Mit dem Changemanagement lässt sich der gesamte Ablauf besser planen. Dies minimiert Risiken und vermeidet Unterbrechungen. Ziel ist es, die bestehende IT-Strategie immer weiterzuentwickeln.
Beim IT Change Management gibt es sieben relevante Aspekte die beim Erstellen und Bearbeiten eines Change Requests berücksichtigt werden sollten. Die sieben einfachen Fragen helfen dabei, Changes strukturiert auf den Weg zu bringen, die sonst wegen zu vieler Unklarheiten abgelehnt würden.
In der Fülle von Abteilungen, Ansprechpartnerinnen und Mitentscheidern sind Change Requests auf Zuruf ein Garant für Chaos. Zunächst muss geklärt werden, woher die Anforderung kommt. Für wen tun wir das? Wo bekomme ich Antworten auf Rückfragen her? Das systematisch zu dokumentieren ist der erste Schritt für strukturiertes IT Change Management.
Warum machen wir das? Aus welchem Grund wird der Change gebraucht? Eine gute Lösung ist nichts wert, wenn wir damit das falsche Problem lösen. Zum anderen werden mit einem Change häufig Lösungsansätze skizziert, die den Blick auf eine bessere Idee versperren. Wenn wir Klarheit über die Gründe für den Change bekommen, lassen sich Chancen und Risiken besser gegeneinander abwägen. Für wichtige Themen suchen wir dann nach der Lösung, die im Kontext am besten passt, während Änderungen mit hohem Risiko bei minimalem Geschäftsnutzen verhindert werden.
Bei der Klassifizierung hilft die Portfolio-Analyse entlang der Vierfeldermatrix, wobei sich die Changes ähnlich wie beim Incident Management entlang der zwei Achsen (1) Auswirkung (z. B. Anzahl der User und Devices) und (2) Dringlichkeit sortieren lassen.
Die Zukunft kennt niemand und dennoch ist es wichtig, verschiedene Szenarien durchzuspielen. Was soll die Änderung einbringen, damit wir anschließend sagen können: das hat sich gelohnt. Nicht jeder Change übersetzt sich direkt in Kundennutzen, der z. B. in Form eines Software-Features einen Aufpreis der Software rechtfertigt. Die Automatisierung von zeitaufwändigen händischen Tasks kann dagegen Kapazitäten im Development für Innovationen freilegen. Automatische Regressions- und Lasttests entlasten den technischen Support. Der Abbau von technischen Altlasten (Technical Debt) hält die Entwicklungsumgebung zukunftssicher, so dass auf Neuerungen am Markt schnell reagiert werden kann. Diese weichen Faktoren müssen, so gut es geht, in harte Kennzahlen mit Blick auf Kosten und Nutzen übersetzt werden, anhand derer sich priorisieren lässt.
Rückt bei den Returns v. a. die optimistische Seite samt Best Case Scenario am Ende der Skala in den Blick, nehmen wir bei den Risiken die pessimistische Perspektive hin zum Worst Case Scenario ein. Jede Änderung birgt Risiken. Manche lassen sich vermeiden, andere muss man gegebenenfalls in Kauf nehmen, wenn die Chancen einerseits oder die Nachteile, den Change nicht umzusetzen andererseits, schwerer wiegen. Doch dass sich Änderungen in einem Teil des Systems auf andere Bereiche auswirken, davon ist auszugehen. Die Konsequenzen sollte man daher vorab bestmöglich durchspielen.
Auf dem Makro-Level geht es hier immer um Zeit und Geld, auf der Mikro-Ebene des IT Change Managements um Mensch (Skills) und Maschine (Capabilities). Diese existieren – oder fehlen – nicht im Vakuum. Sind die Kräfte in einem Projekt gebunden, fehlen sie in einem anderen. Gehen wir trotzdem beide an? Gleichzeitig? Welche Verzögerungen treten an anderer Stelle auf, wenn wir einen Change umsetzen? Die Frage hört bei der internen IT-Organisation nicht auf, sondern umfasst die gesamte Wertschöpfungskette bis hin zum Kunden (Customer Value Chain). Auch Antworten auf diese Fragen müssen in die Priorisierung von IT-Projekten einfließen.
Wer soll's machen? Meist sind das für die einzelnen Teilschritte unterschiedliche Leute im Team oder sogar verschiedene Abteilungen. Umso wichtiger ist es, die Verantwortlichkeiten einerseits transparent und nachvollziehbar und somit um- und durchsetzbar zu machen. Dann ist unmissverständlich klar, wer für welche Aufgabe aktiv werden muss und im Falle eines Misserfolgs lassen sich unproduktive Schuldzuweisungen vermeiden. Über das gesamte Change und Release Management hinweg muss die Verantwortung klar verteilt und allen transparent sein.
IT-Umgebungen sind komplex und stehen in vielen Abhängigkeiten zu anderen Bereichen und Funktionen im System. Manchmal reicht es, auf Auswirkungen in anderen Bereichen hinzuweisen, in anderen Fällen ist man auf deren Vorarbeiten angewiesen. Eine integrierte Konfigurationsmanagement-Datenbank (Configuration Management Database, CMDB) macht gegenseitige Abhängigkeiten transparent und ermöglicht die gemeinsame Zeit- und Reihenfolgeplanung zur Umsetzung von Changes bei möglichst wenig Ausfallzeiten und Zeitverzögerungen.
Um das IT Change Management im Unternehmen optimal umzusetzen, müssen Veränderungen stets nach festgelegten Punkten erfolgen.
Zunächst müssen der Ist-Zustand analysiert und der Soll-Zustand definiert werden. Danach wird ein Zeitplan für den Change erstellt. Ein Testmodell hilft, Problemen – zum Beispiel bei der Servicequalität – vorzubeugen. Läuft das Testmodell, wird die Veränderung wie geplant umgesetzt.
Einfacher funktioniert dies, wenn die ITSM-Prozesse mit einer Service Management Software unterstützt und vereinheitlicht werden. Dieses sollte folgende Anforderungen erfüllen:
Eine IT Management Software, die diese Anforderungen bewältigt, trägt erheblich zur Verbesserung der Change-Management-Prozesse bei.
Abb.: Integration von Veränderungen im Unternehmen
Nach erfolgreicher Implementierung wird der gesamte Vorgang bewertet. Was sollte beim nächsten Mal optimiert werden? Wurden alle gesetzten Ziele erreicht? Wurde der Zeitplan eingehalten? Am besten wird für diese Überprüfung ein eigener Change-Manager eingesetzt, der das gesamte Projekt des IT Service Management überwacht und stetig optimiert.
Bei aller technischer Unterstützung darf aber auch der Mensch dahinter nicht vergessen werden. Bewährte, zum Teil geliebte Abläufe und Routinen sind seit Jahren etabliert. Veränderungen können daher schnell zu Unmut, Demotivation und politischen Interventionen auf Führungsebene führen.
Abhilfe schafft ITIL 4, das auf das Prinzip "einfach und praktikabel" setzt. Während die 26 Life Cycle Prozesse aus ITIL 3 relative starre, regelhafte Abläufe formulieren, gewähren die 34 Management Praktiken aus ITIL 4 Freiheiten für die Definition maßgeschneiderter Prozesse.
ITIL v3 |
ITIL v4 |
| Beschreibt Change Management als Prozess in der Service Transition. | Beschreibt das Change Management als Service-Management-Praktik und nennt es Change Enablement. ITIL v4 führt die grundlegenden Aktivitäten im Change Enablement auf sowie die wichtigsten Inputs, Outputs und Rollen. (IT-) Organisationen können auf Basis dieser Richtlinien einen angepassten Prozess für das Managen von Changes entwerfen, der die jeweiligen individuellen Anforderungen widerspiegelt. |
Prozessschritte:
|
Change-Enablement-Praktik: Der Change-Management-Prozess nach ITIL v3 wird nicht obsolet und kann als Vorlage für die individuelle Anpassung in der IT-Organisation verwendet werden.
|
| Fokus auf Service Transition und Deployment |
Fokus auf die Service-Wertschöpfungskette inklusive Konzeptions- und Entwicklungsphase Change Enablement soll so entworfen sein, dass es die Ende-zu-Ende-Wertschöpfungskette des Service Managements im Auge behält. Ein iterativer Ansatz soll die Balance halten zwischen einer schnellen Umsetzung eines RfCs einerseits und dem Management der einhergehenden Risiken für bestehende Services andererseits. |
An einem Anwendungsbeispiel möchten wir Ihnen den gesamten Prozess erläutern.
Dr. Christian Klaus hat ein Problem. Nach einem folgenschweren Ausfall im IT-System seiner Firma ist er aufgefordert, den Change-Management-Prozess zu überarbeiten. Den Fokus legt er dabei klar auf das Risikomanagement, eine der sieben Anforderungen im ITIL Change Management.
Auslöser für Dr. Klaus' Kopfschmerzen war eine kleine Änderung an der Hardware in einer regionalen Filiale. Die Störung hatte sich flächenartig ausgebreitet und am Ende die Kommunikations- und Videosysteme der gesamten Organisation stark beeinträchtigt. Mitarbeiterinnen und Mitarbeiter im Homeoffice waren abgeschnitten. Meetings zwischen der Geschäftsleitung und Kunden wie auch Lieferanten konnten nicht stattfinden. Drei Stunden ackerte die IT, bis wesentliche Geschäftsprozesse wieder anliefen.
Abb.: Bessere Zusammenarbeit beim Change Management
Als ITIL-Experte und Process Owner für das IT Change Management waren Dr. Klaus die Zusammenhänge, die zu dem Ausfall geführt hatten, in ihrer Gesamtheit mittlerweile transparent.
Die Root Cause Analysis war durchgeführt worden, eine Post Implementation Review gab es dagegen nicht. Die Änderung in der Außenstelle war weder durch den Change Prozess genehmigt, noch war sie durch eine qualifizierte und autorisierte Person vorgenommen worden.
Der Change-Management-Prozess sah konkrete Schritte für das Risiko Management vor, um genau solche Ausfälle zu verhindern. Zudem hatte Dr. Klaus schon vor zwei Jahren gemeinsam mit dem IT Change Manager eine Policy verfasst, die die Best Practices des Change Managements nach ITIL definiert und für die eigene IT-Organisation abbildet. Regelmäßig fanden Schulungen für die Teams statt, in denen die Inhalte wiederholt und diskutiert wurden. Alle Vorgaben aus dem Risiko Management der Change Management Policy waren schlicht ausgehebelt – sie waren einfach nicht beachtet worden.
Neue Technologien entscheiden immer mehr über den Erfolg von Unternehmen. Damit steigt die Bedeutung funktionierender Change Management Prozesse. Erfahren Sie im Webinar (45 Minuten), wie Sie das Change Management effizient und praxisorientiert aufstellen.
Veränderung kann nur gelingen, wenn klar ist, wofür man es tut und alle Beteiligten Vertrauen fassen, dass die Anstrengung auch gelingen kann. Diese Transparenz und Zuversicht herzustellen, war Dr. Klaus' größte Herausforderung.
Dass man künftig Ausfälle wie den jüngsten der Kommunikationssysteme verhindern wollte, dafür musste Dr. Klaus keine große Überzeugungsarbeit leisten. Niemand wünscht sich Fehler und Widersprüche im Prozess-Workflow, gestörte Abläufe, Ausfälle und Eskalationen. Auf einfach geregelte, nachvollziehbare und gut dokumentierte Abläufe mit klaren Verantwortlichkeiten sowie ein kontrolliertes Risikomanagement konnten sich alle einigen, denen eine sauber funktionierende, performante IT-Infrastruktur am Herzen lag.
Nur dann, so war er sich sicher, würden sich die Kollegen und Kolleginnen schnell mit den Veränderungen anfreunden. Nur dann könnten die Veränderungen im IT Change-Management-Prozess schnell aktiviert werden. Und nur unter dieser Voraussetzung lassen sich Systeme optimieren, Prozesse verbessern und Großausfälle künftig zuverlässig verhindern. Geschäftsziele werden so besser erreicht und die Digitalisierung im Unternehmen vorangetrieben.
Benötigen Sie professionelle Hilfe bei der Umsetzung des IT Change Managements in Ihrem Unternehmen? Unsere Experten von Serviceware unterstützen Sie gerne dabei, Ihre individuellen Anforderungen zu realisieren.