CIO: Schau aus dem Fenster! Es hat Kunden draussen!

Posted on 29. Oktober 2011 by Martin Andenmatten

Die IT als Black-Box ist sprichwörtlich – nicht so sehr, weil man von aussen nicht bereit wäre zu verstehen – sondern vielmehr, weil man sich im Innern der Box so geheimnisvoll verhält. Ich erlebe es gerade wieder in einem eigentlich sehr spannenden Service Management Projekt. Da sind Heerscharen von internen und externen Spezialisten daran, ein Architekturprozess-Modell zu entwickeln, das vermeintlich so genial wird, dass alle Eventualitäten des Business abgedeckt werden können. Nur – mit dem Business hat bis heute noch kein einziger gesprochen.

Kein Respekt vor dem Kunden

Gerade grosse IT Organisationen leiden unter diesem Phänomen: man beruft sich oft auf irgendetwas, was irgendjemand von ganz weit oben an einer Sitzung irgendwann mal gesagt hat. Und genau das gilt es nun unter allen Umständen umzusetzen – egal wie lange es dauert. Oder da gibt es auch die bewundernswerten Kollegen, welche einmal Kontakt mit einem echten Businessvertreter hatten und nun seit diesem Erlebnis ganz genau verstanden haben, was die Erwartungshaltung des Business ist. Kunden werden irgendwie als eine besondere Spezies betrachtet, welche schier Unmögliches verlangen und welches praktisch nicht befriedigt werden kann: how to please the unpleasable? In solchen Diskussionen gibt es oft nur eine Schwarz-Weiss Betrachtung: Es ist entweder kategorisch das einzig Richtige – oder dann ist es kategorisch falsch.

CIOs, lasst Euch sagen: Customers are people, too! Schaut aus Euren verdunkelten Fenstern raus. Viel besser noch: öffnet die Türen, lasst Licht in Euren Elfenbeinturm und tretet raus. Hört Euch rum und geht auf diese besonderen Menschen zu. Ich kann Euch versichern, dass deren Vorstellungen und Wünsche gar nicht mal so kompliziert sind. Mitunter sogar fast zurückhaltend einfach: man will bloss in Ruhe arbeiten können. Je einfacher und unbürokratischer, desto besser. Aber verlässlich – diesen Anspruch dürfen wir ihnen natürlich nicht verwehren.

Fehlendes Businessverständnis

Warum tun sich IT Organisationen mit der Öffnung eigentlich so schwer? Es fehlt ganz einfach oft am notwendigen Mut zu hinterfragen und zu wagen, Entscheide von früher oder von oben zu überdenken und umzustossen. Und es fehlt auch schlicht oft die Fähigkeit, zu zuhören und die Bereitschaft von anderen Erfahrungen zu lernen. Es herrscht oft die irrige Meinung vor, dass das was einfach klingt, nicht gut genug für unsere Kunden sein kann.

CIOs, hier fehlt es ganz eindeutig an Führung! Die Anforderungen an den IT Leiter reichen nicht mehr aus, als Dompteur einer schwer zufrieden zu stellenden, kreativ im unüberschaubaren Chaos aufblühenden, und vermeintlich unverzichtbaren Technologie-Junkies zu gelten. Die IT muss heute und morgen bereit und in der Lage sein, dem Business zu dienen und seine Mitarbeiter wo immer es geht zu unterstützen. Alles was nicht diesem Zwecke dient, muss als privates Hobby abgetan werden, wofür künftig kein Sponsor mehr bereit sein wird, zu zahlen. Forschung und Entwicklung ist nicht die Aufgabe von IT Organisationen in Unternehmen.

Die Anforderungen an einen CIO werden sich in Zukunft drastisch verändern. Es bleibt sicherlich der Anspruch, dass ein gewisses Technologieverständnis vorhanden sein muss. Künftige CIOs werden jedoch nicht zwingend ein IT Studium oder eine Laufbahn innerhalb der IT vorweisen müssen. Immer mehr werden CIOs gesucht, welche das Business-Verständnis einbringen und in der Lage sind, die Technologie im Unternehmen so einzusetzen, dass diese mit ihren Kunden vernetzt werden und damit das Umsatzwachstum steigern.

Künftige CIOs werden vermehrt direkt aus dem Business selbst kommen, welche dort eine hohe Affinität mit der Technologie und deren Nutzung aufgebaut haben. Mit der Durchdringung der IT in allen Lebenslagen wird künftig die Beurteilung der Nutzbarkeit von IT Technologie nicht mehr bloss den introvertierten Engineers überlassen werden. Nur was nützt macht auch Sinn und nur dafür wird man bereit sein, zu zahlen.

Darum CIOs: Macht die Not zur Tugend! Öffnet eure Fenster und Türen und besucht Eure Kunden. Ein jeder verantwortliche IT Manager sollte erst über Entscheidungskompetenz und Budget verfügen können, wenn er mindestens ein paar Monate direkt in den Fachabteilungen des Business gearbeitet hat. Ermöglicht für Eure besten Talente die Absolvierung von Praktika. Besser noch – besucht selber eines. Lasst die Business-Luft schnuppern und die wahren Bedürfnisse spüren. Diese Monate des Lernens sind Gold wert für das Aufbringen von Businessverständnis. Und Ihr werdet erstaunt sein: Euer Business empfängt Euch mit offenen Armen und wird es Euch später danken.

Service Portfolio – Navigationshilfe für IT Investitionen?

Posted on 22. Oktober 2011 by Martin Andenmatten

Mit Service Portfolio wurde uns durch ITIL® V3 ein wundersames Instrument in die Hände gelegt, welches dem CIO das Verständnis und damit die Hebelwirkung zwischen Business-Nutzen und IT Investitionen ermöglicht. Nur – es ist wie mit jedem neuen Tool: “A Fool with a tool is still a fool“.

Wie ein Service Katalog zu verstehen und einzusetzen ist, leuchtet bald einmal ein, wenn man einmal erkannt hat, wie einfach und direkt mit einem solchen Instrument mit dem Business über Leistungen der IT diskutiert werden kann. Aber ein Service Portfolio ist irgendwie zu abstrakt – irgendwie eine Kombination von Projektportfolio mit Service Katalog? Das will irgendwie nicht richtig zusammen passen. Das sind doch auch zwei verschiedene Welten?

Financial-Disaster

Wie werden heute IT Investitionen entschieden? Nun – da gibt es klassisch die heisse Phase der Budgetplanung. Jede Idee, welche diese Phase überlebt, wird in aller Regel auch umgesetzt. Gut – heute kann man auch da noch nicht sicher sein, weil es bereits üblich geworden ist, mindestens zweimal im Jahr die Budgets zu durchleuchten und alle noch offenen Posten zu hinterfragen.

Im Vorfeld wird schon auch mit dem Business diskutiert, was denn so anfällt. Und in der IT Infrastruktur werden Umfragen gemacht, welche Ausbauten anstehen. Ich nenne das die Zeit des Christbaum-Schmückens. Der Baum ist in aller Regel überhäuft und das verfügbare Budget reicht bei weitem nicht, alle Wünsche zu erfüllen. Es geht nun um den Kampf, was letzlich unter dem Baum zum Liegen kommt.

Relativ sicher fühlt sich der, welcher laufende Verträge zu erfüllen hat und daher das Geld bereits verpflichtet ist. Schlau ist der, welcher seine Budgetposten möglichst früh bereits verplichtet hat mit sogenannten “letters of intent”. Auf der Kippe stehen immer die neuen Projekte oder Anpassungen an bestehenden Systemen, welche möglicherweise einen effizientere und damit kostengünstigere Betrieb ermöglichen. IT Verantwortliche der Budget-Posten feilschen um diese Gelder, die es zu verteidigen gilt (als ob es ihre eigenen wäre). Wer sich damit durchsetzen kann gewinnt, wer seine Argumente nicht überzeugend darlegt, verliert.

Hand aufs Herz, das kann es ja nicht wirklich sein, oder? Wer würde schon sein eigenes Geld auf diese Weise einsetzen. So läuft es aber in vielen Organisationen ab, genauso.

Was läuft hier also falsch? Es ist ja keine böse Absicht im Spiel. Es zeigt einfach das Unvermögen der Organisationen, Investitionen im Lichte des Business Nutzens zu verstehen. Wenn ein Unternehmen in eine neue Verarbeitungsanlage investiert, so leuchtet jedem ein, dass die Investitionskosten mit den zu erwartenden Produktionenleistungen verglichen werden. Wenn es sich rechnet und wenn auch das Risiko einigermassen abschätzbar ist, wird man der Investition zustimmen. Die Anlage wird auch permanent im Auge behalten, inwieweit sie die Produktions-Anforderungen erfüllt. Die Investitionen werden über die Zeit abgeschrieben und Unterhaltsinvestitionen werden getätigt, wenn sich der Nutzen weiterhin aufrechterhalten kann und keine Ersatzlösung in Frage kommt.

Obwohl die meisten Unternehmen mehr und mehr in die IT Technologie investieren, hinterfragen die Businessverantwortlichen oft deren tatsächlichen Wert. Das führt dazu, dass der dominierende Fokus in der Steuerung der IT-Kosten mündet, anstelle zu verstehen, wie die Rolle der IT einen konkreten Nutzen für das Business generieren kann. Wen der Wert nicht erkannt wird, dann ist jeder Preis zu hoch. Was liegt also näher, als an der Kostenschraube zu drehen? Und wenn die IT es tatsächlich schafft, dass sie trotz weniger Budget die gleiche Leistung zu erbringen vermag, dann hat sie soeben den Tatbeweis erbracht, vorher nicht effizient genug gewesen zu sein. Da frag ich mich als Business-Verantwortlicher: liegt da nicht noch mehr Sparpotential in der IT?

Vermeiden von Überraschungen: IT matters

IT Organisationen müssen lernen, wie man den Spiess umdreht. Klar, kann und muss man immer auch intern optimieren. Man muss aber auch aufzeigen können, dass der Preis gerechtfertigt ist und dass sich die Investitionen rechnen. Was liegt also näher, diese Investitionen aus Sicht des der Produktivität – des wirklichen Nutzens für das Business zu managen?

Als CIO muss ich aber zunächst die Hausaufgaben machen. Ich muss die IT-Produktionsanlage aus Sicht des Businessprozesses sehen und verstehen können. Ich muss wissen, welche Leistungen nun genau in welche „Anlage“ einfliesst und damit für den jeweiligen Nutzen zugerechnet werden kann. Diese „Anlagen“ entsprechen den IT-Services, welche aus Anwendungen, Infrastrukturen, Operations- und Supportleistungen bestehen und deren Zusammensetzung ich verstehen muss, um die Kosten ableiten zu können.

Die Investition in IT Services ist aus dieser Sicht nichts anderes als eine Investition in eine Produktionsanlage. Es ist eine Infrastruktur mit Funktionalitäten, welche die Produktion der Businessprozesse unterstützen und automatisieren. Sie ist zwar nicht so stabil wie die Fabrikanlagen und braucht auch ständig Pflege und Support (das Business hat sich daran gewöhnt, dass die IT-Anlage ein wenig fragil ist und zwischendurch auch mal nicht funktioniert) – aber letztlich gehört die IT zur Infrastruktur-Ausstattung des Unternehmens.

Das Service Portfolio ist nun eine Art Inventarisierung sämtlicher IT-Investitionen respektive IT Services, welche einerseits einen erwarteten Nutzen oder Produktionsleistung aufweisen und andererseits Kosten verursachen. Nur Investitionen, welche sich aus Sicht des Business auch rechnen, sprich mehr Nutzen stiften als Kosten auslösen, haben eine Berechtigung, im Portfolio zu bleiben.

Aus dieser Betrachtung hat es drei wesentliche Kategorien von Investitionen, die unterschieden werden können:

IT Services, welche bereits im Betrieb sind und dem Business zur Verfügung stehen. Dies entspricht dem Service Katalog
IT Services, welche sich in der Entwicklung befinden. Die sogenannte Service Pipeline
IT Services, welche nicht mehr aufrechterhalten werden sollen, aber aus Support- oder sonst welchen Gründen weiterhin betrachtet werden müssen. Die zurückgezogenen Services

Mit unternehmerischem Gespür und in ständigem Kontakt mit dem Business muss der Business Case eines jeden Services – auch derer die sich erst in Entwicklung befinden – auf den Nutzen und die Geschäftsprozess-Unterstützung untersucht werden. Jede Investition muss sich rechnen. Die Nutzensicht verändert sich, genauso sich das Business verändert und entwickelt. Und daher ist gerade in der Budgetplanung wichtig, diese Kalkulation gemeinsam mit dem Business durchzuführen.

Die Argumentation für eine Investition respektive einen Budgetposten muss also ausschliesslich aus der Optik des Business-Nutzens erfolgen. Gerade auch Investitionen in Basis Infrastrukturen wie Netzwerke, Server, oder Datenbanken welche ja von allen Services irgendwie mit genutzt werden, müssen in ihrer Beanspruchung auf die Services kalkuliert werden. Keine Kosten sind aufgezwungen – jede Position kann und muss hinterfragt werden. Wenn es keine Alternativ-Lösungen gibt, so muss sich letztlich das Business fragen – und auch entscheiden, ob sich das Geschäft mit diesem IT Services überhaupt noch rechtfertigen lässt. Das kann nur das Business tun – niemals die IT aus eigenem Ermessen.

Und die Qualität des Services hinsichtlich Verfügbarkeit und Performance schlägt sich ebenfalls immer in Investitionen nieder. Auch das Vermeiden von Risiken oder Sicherstellen von Sicherheitsanforderungen durch Schutzmassnahmen ist hier als Nutzenstifter zu verstehen das auschliesslich dem Unternehmen zu gute kommt.

Es versteht sich daher auch von selbst, dass gerade bei Investitionen in neue IT Services die Total Cost of Ownership Betrachtung zwingend ist. Also nicht bloss die Beschaffungs- und Herstellungskosten sind zu berücksichtigen, sondern gerade auch die Betriebs-, Unterhalts- und Supportkosten. Dies sind die massgebliche Kostenfaktoren, um welche es dem erwarteten Nutzen gegenüberzustellen gilt.

Und wenn sich eine Investition für einen IT Service nicht mehr rechnet, dann muss diese abgebaut werden – das scheint dann auch logisch. Idealerweise zeichnet sich dies mit vorausschauender Investitionspolitik rechtzeig ab, damit kein abruptes Ende entschieden werden muss und Ressourcen ungenutzt verbleiben.

Ein Service Portfolio ist also aus Sicht des Business ein Portfolio sämtlicher IT Investitionen, welche sich das Unternehmen leistet, um seine Geschäftsprozesse optimieren zu können. Als zuständiger Service Portfolio Manager trägt man eine gewaltige Verantwortung – vor allem wenn das Business eine gewinnbringende Performance erwartet. Aus dieser Sicht muss der Budget-Prozess schon ziemlich von der Vorgehensweise wie eingangs beschrieben unterschieden werden. Und das Business muss selber Hand anlegen. Es gehört in die Anlagepolitik des Unternehmens, wo und wie investiert wird.

Das Service Portfolio muss also gemanagt werden. ITIL hat dazu den Service Portfolio Management bereits in der Phase Service Strategy positioniert. Folgende Fragestellungen sind in diesem Prozess zentral:

Warum sollte ein Kunde diesen Service kaufen?
Warum sollte ein Kunde diesen Service von uns kaufen?
Was ist das Preis- und Verrechnungsmodelle?
Was sind unsere Stärken und Schwächen, unsere Prioritäten und unsere Risiken?
Wie sollen unsere Ressourcen und Fähigkeiten zugewiesen werden

Sämtliche Änderungen am Portfolio werden durch Richtlinien und Verfahren gesteuert. Damit repräsentiert das Service Portfolio die Fähigkeit und Bereitschaft des Service Providers auf Anforderungen des Kunden reagieren zu können und Services zu liefern.

Service Asset & Configuration Management

Ach ja – da war noch das mit den Hausaufgaben. Die gilt es natürlich noch zu erledigen, bevor man überhaupt die Chance bekommt, die Kosten eines Services zu ermitteln. Ein Service Asset und Configuration Management mit einem Configuration Management System ist bereits ein guter Anfang. In einem meiner letzten Blogs bin ich bereits darauf eingegangen: “Configuration Management – die ungelöste Baustelle des CIOs“.

Lesen Sie dazu auch den Beitrag Val IT, das COBIT-Framework zu Mehrwert Generierung.

Change? oder Projekt? oder was?

Posted on 9. Oktober 2011 by Martin Andenmatten

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.

IT Berufshierarchie - Operation @ End of the chain

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.

Traditionelle IT - die Entwicklung hat das Sagen, der Betrieb das Nachsehen

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.

Change Mgmt - Im Zusammenspiel mit Projekt & Release Management

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.

Request for Change - Input für Change Beurteilung

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.

Service Management koordiniert Anforderungen und deren Umsetzung. Und steht dafür gerade.

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.

ITIL-Blog zu ITIL, ISO 20000 & COBIT

Vom Kennen. Zum Können. Zum Tun.

Monthly Archives: Oktober 2011

CIO: Schau aus dem Fenster! Es hat Kunden draussen!

Service Portfolio – Navigationshilfe für IT Investitionen?

Change? oder Projekt? oder was?