In keinem anderen Service Management Prozess kommt die Kluft zwischen Entwicklung und Betrieb von IT Services stärker zum Tragen, als beim Change Management. Traditionell hat schon immer die IT Entwicklung gesagt, wo’s lang geht. In der Entwicklung entsteht der Fortschritt, wird an der Zukunft gearbeitet und entsteht Kreatives, während im Betrieb primär sichergestellt wird, dass die Systeme laufen, wie sie sollen.
Darin ist die ganze Schieflage des Berufshierarchie-Gefälles zwischen Entwicklung und Betrieb verankert. Noch ist die Meinung weit verbreitet, dass die Wertschöpfung in IT Organisationen primär in den Entwicklungsabteilungen entsteht, während das Operation für die niedrigen Arbeiten des täglichen Betriebs zuständig ist. Im Betrieb entsteht ja nicht wirklich Neues – es geht hier schliesslich nur darum, bereits Geschaffenes am Leben zu halten.
So werden auch die Budget-Hoheiten in den IT Organisationen verteilt. Die Entwicklungsbereiche haben auch heute noch in erster Linie das Sagen, was gemacht wird und was nicht. Die Entwickler denken dabei in aller Regel nur bis zur Projekteinführung und dann bereits an die nächste technische Herausforderung. Der Betrieb kann froh sein, wenn er etwas mehr als ein paar Tage auf das Knowhow der Entwickler zugreifen kann. Ich habe nicht selten erleben müssen, dass in der Sicht des Betriebes die Entwickler als Kunden der IT Services verstanden werden.
Mit dem Aufkommen von ITIL® und Service Management ist dieses Weltbild der Informatiker stark unter Druck geraten. IT Betriebe begehren auf und reklamieren ebenfalls Bedürfnisse an. Betreibbarkeit sei schliesslich nicht selbstverständlich. Und zudem hat der Anwender immer neue Vorstellungen, wie die Qualität des Services zu liefern sei. Services in Form von SLAs zu vereinbaren, um die grundlegende Erwartungshaltung zu dokumentieren wird dem Betrieb gerade noch zugestanden. Die Messbarkeit ist aber eh nicht gegeben – also kommt es auch nicht so ganz darauf an. Der Schreiber des Reports hat es in der Hand, wie gut die berichtete Qualität aussehen muss.
Die grössten Reibungsflächen gibt es an den Übergangspunkten zwischen Entwicklung und Betrieb. Immer dann, wenn die Entwicklung ihre bereits arg in Verzug geratenden Lieferobjekte in die Produktion übergeben möchten. Zeit zum Testen und Schulen war eh zu knapp. Aber das Business kann nicht mehr länger hingehalten und vertröstet werden. Der Betrieb andererseits ist sich schon einiges von den Entwicklern gewöhnt und stockt seine Abnahme-Kriterienliste noch etwas auf – „Never touch a running system“.
Ist es ein Projekt? Oder ist es ein Change?
Aus Sicht der Entwicklung ist die Antwort klar. Das Projekt hat den Auftrag, die Business Anforderungen in IT Systemlösungen umzuwandeln und wenn immer möglich rechtzeitig und im Rahmen des Budgets produktiv einzuführen. Solange das System nicht ausgeliefert ist, trägt das Projekt die Verantwortung. Welche Rolle spielt in den Augen den Entwickler das Change Management? Da gibt es zwei Ansichten: einerseits wird Change Management als Produktions-Einführungskoordination akzeptiert. Tonangebend bleibt jedoch immer das Projekt. Andere Organisationen sehen im Change Management primär die Verantwortung der Wartungs-Moderation – das heisst, Koordination von System-Anpassungen nach der erfolgreichen Einführung durch das Projekt.
Selbstbewusste Service Manager mit ITIL® Background tun sich mit dieser engen Sichtweise sehr, sehr schwer. Das Projekt muss doch unter Change Kontrolle gemangt werden! Oder wie war das schon wieder?
Nicht wenige Berater welche sich hier nicht gerne zwischen die Fronten werfen mögen, antworten dann auch etwas unschlüssig: „it depends…“.
Hier ist ein Paradigma-Wechsel unbedingt angesagt. Unternehmen leisten sich in aller Regel nicht eine IT Organisation, um Forschung und Entwicklung betreiben zu können. Nein, Unternehmen wollen doch in erster Linie tagtäglich mit den IT Services arbeiten, um das Business betreiben und aufrechterhalten zu können. Klar ist die Weiterentwicklung von Services absolut notwendig und auch wichtig – aber erst wenn im Alltag der Nutzen aus den Services gezogen werden kann, dann ist Mehrwert entstanden.
Die Nutzungsphase des Services ist aus Sicht des Business die absolut wichtigste Lebensphase des Services schlechthin. Die Qualität des Services hinsichtlich Funktionalität, Verfügbarkeit, Performance, Sicherheit und Kontinuität aber auch die Betreibbarkeit und Einhaltung der Sorgfaltspflichten ist in der Phase Service Operation, im Tagesgeschäft immer wieder unter Beweis zu stellen. Jeder Kunden- und Anwenderkontakt verlangt einen Balaceakt zwischen Flexibilität und Konformität. Die strategische, taktische und operative Abhängigkeit des Business von der Funktionsfähigkeit und der Verfügbarkeit der Services ist heute dermassen gross, sodass eine Einschränkung der Qualität nicht mehr hingenommen werden kann und will.
Qualität entsteht nicht erst im Betrieb
Damit die Erwartungshaltungen nicht nur bezüglich der Funktionalität sondern auch von der Qualität der Service Levels im Alltag erfüllt werden können, reicht es nicht, besonders freundliche Service Desk Mitarbeiter zu engagieren. Diese können im besten Fall unzufriedene Anwender beruhigen – aber nicht die verpasste Qualität einfach ungeschehen machen. Die Qualität muss bereits bei der Entwicklung eine nicht abdingbare Anforderung sein und in den Design der Lösung mit einfliessen. Der Transition Phase steht die wichtige Aufgabe zu, sicherzustellen, dass ein neuer Service oder eine Änderung an einem Service von der geschützten Werkstatt sicher und mit möglichst wenig Nebengeräuschen in die Produktion überführt wird. In dieser Phase werden die Nutzbarkeit, die Betreibbarkeit und die Supportfähigkeit des neuen oder geänderten Services geprüft und sichergestellt.
Jede Verbesserung ist eine Veränderung – aber nicht jede Veränderung ist eine Verbesserung!
Jede Veränderung ist ein Change und muss entsprechend gemanagt werden. Ist das nun die Aufgabe des Projekt Managements oder des Change Managements? Ein Change ist das Hinzufügen, Modifizieren oder Entfernen eines Elements, das Auswirkungen auf die IT Services haben könnte. Ein Projekt demgegenüber ist ein einmaliges, zeitlich befristetes Vorhaben mit einem spezifischen Ziel. Projekt Management ist die Methode, dieses Ziel in sachlicher, zeitlicher, finanzieller und personeller Begrenzungen umzusetzen.
Ein Projekt wird für komplexe Changes definiert, damit diese Veränderung besonders gut geführt und kontrolliert umgesetzt werden kann. Weniger komplexe Changes können als Tasks direkt den Spezialisten übertragen werden. Change Management gemäss ITIL® hat nun die Aufgabe, strategische, taktische und operative Changes ganzheitlich zu planen, zu autorisieren, zu koordinieren und ein friktionsfreies Einführen in die Produktion sicherzustellen.
Es braucht eine Gewaltentrennung zwischen dem Managen von Changes und der Umsetzung von Changes. Change Management ist der Prozess, welcher für das Managen, sprich: die Autorisierung und Steuerung des Lebenszyklus aller Changes zuständig ist. Demgegenüber ist Projekt Management eine Methode, um komplexe Changes strukturiert umzusetzen. Die Machbarkeit der Veränderung wird im Rahmen von Projekten vom Groben ins Detail analysiert und der Service über verschiedene Meilensteine steuerbar realisiert.
Es braucht eine unabhängige Instanz, welche alle Changes und Projekte gesamthaft steuert und überwacht. Dies ist eine der grössten Forderungen von gesetzlichen Regulatorien, um eine instanzierte Kontrolle, ein Vier-Augenprinzip für Änderungen an kritischen Assets zu überwachen.
Diese Instanz ist quasi der Treuhänder der Business- und IT Operations-Anliegen, welche Veränderungen ermöglichen aber ohne die Produktion zu gefährden. Als fürsorglicher Treuhänder hat diese Instanz die Verantwortung, dass neue oder geänderte Services den Businessanforderungen entsprechen und dass das Betriebspersonal in der Lage ist, den Betrieb und den Support zu gewährleisten. Verschiedene Changes oder Projekte müssen permanent mit den sich verändernden Business-Prioritäten und vorhandenen Betriebsressourcen abgestimmt werden.
Ohne übergreifendes Change Management fehlt diese Treuhänderfunktion und jedes Projekt versucht sich mit den Ressourcenanforderungen beim Betrieb durchzusetzen. Betreibbarkeit und Supportbarkeit bleiben in diesem Fall leider oft auf der Strecke – oder ist zumindest abhängig vom Willen und Können des jeweiligen Projektleiters.
Change Management ist Steuerung und Kontrolle
In vielen IT Organisationen, welche über kein übergreifendes Change Management im Sinne von ITIL® verfügen, tut man sich schwer mit der Akzeptanz einer übergeordneten Entscheidungsinstanz. Gerade IT Spezialisten fühlen sich nicht selten bevormundet, weil in ihren Augen diese Entscheidungsinstanz nicht über genügend fachliche Kompetenzen verfügen, die Änderungstätigkeiten inhaltlich zu beurteilen.
Dabei ist es nicht die Aufgabe des Change Managements die fachliche Kompetenz der Spezialisten zu hinterfragen. Es ist im Gegenteil zu hoffen, dass der Spezialist weiss was er tut und dass er sein Fach beherrscht. Change Management muss vielmehr abschätzen können, wie gross das Risiko bei einem jederzeit möglichen Scheitern des Changes für das Business und den Service Provider ist. Entsprechende Rahmenbedingungen sind einzurichten, damit die Änderung koordiniert und sicher realisiert werden kann. Change Management ist kein willkürlicher Akt, bei welchem nich nachvollziehbar über das Schicksal von Change-Anträgen entschieden wird.
Nein, Change Management will Changes ermöglichen – aber berieblich wirklich Notwendiges von allenfalls Wünschbaren abgrenzen können. Es gilt also Zeit, Kosten, Ressourcen und Businessprioritäten treuhänderisch abzuwägen. Mitunter kann daduch auch ein Release-Wechsel eines Betriebssystems abslut höchste Priorität erlangen, wenn damit der weitere künftige Support durch den Lieferanten gesichert werdenmuss.
Change Management ist also der Prozess, welcher die Aufrechterhaltung von Service-Versprechen gewährleistet und gleichzeitig die notwendigen Veränderungen des Business ermöglicht. Und zwar so ermöglicht, dass keine bösen Überraschungen im Tagesbetrieb entstehen. Change Management koordiniert demnach auch alle Projekte, welche strukturiert komplexe Veränderungen an Services oder neue Services umsetzen. Die IT Organisation braucht so eine zentrale und übergeordnete Instanz, welche über sämtliche Changes Bescheid weiss und die Kompetenz hat, Verschiebungen von Einführungen aufgrund von Business-Prioritäten durchzusetzen. Wie diese Instanz auch letztlich genannt wird, wichtig ist nur, dass diese unabhängig von der Umsetzung entscheiden kann (Gewaltentrennung, Segregation of Duty) und die sichere Überführung in die Produktion verantwortet.
Ein Projekt ist in dieser Hinsicht nicht unabhängig und kann nur jeweils für das eigene Projekt sprechen. Zudem hat das Projekt nach Einführung der IT Lösung seine Pflicht getan. Wer trägt die Verantwortung, dass die IT Lösung auch den erhofften Businessnutzen erbringt? Der Entwickler? Wohl kaum. Es ist eher der Service Owner, welcher letztendlich die Budgethoheit erhalten müsste. Und der Service Owner braucht eine treuhänderische Instanz, welcher die Veränderungen in der versprochenen Zeit, in der versprochenen Qualität und mit minimalsten Gefahren für den laufenden Betrieb sicherstellt.
In ITIL® heisst diese Instanz Change Management.