Die Fallstricke und Fehlerquellen der ITIL-Anwendung

Der Erfolg einer Servicemanagement-Initiative kann etwa nach 24 bis 30 Monaten gesichert nachgewiesen werden. Während dieser Zeit können verschiedene Umstände zu einem Abbruch der Übung oder zu schwerwiegenden Beeinträchtigungen des Fortschrittes führen.
Die Gründe für einen Misserfolg lassen sich meist auf eines von vier grundlegenden Missverständnissen zurückführen: die zu technische Ausrichtung der Initiative, der fehlende Blick auf die gesamte Wertschöpfungskette, die Ungeduld im Management, rasche Erfolge nachweisen zu können, und der laienhafte Umgang mit dem erforderlichen Wandel.

Die zu technische Ausrichtung

Nicht jeder Prozess ist ein Prozess (oder will so behandelt werden). So wie nicht jeder Hund ein Hund und nicht jedes Schwein auch eine Sau ist - Flughunde gehören zur Gattung der Flattertiere und ein Schwein ist auch ein Schimpfname für einen widerwärtigen Menschen - so ist auch ein Prozess nicht immer ein Prozess im herkömmlichen Verständnis.

Ausserhalb des juristischen Streites assoziiert in der Informatik mit dem Begriff Prozess eine überwältigende Mehrheit das E-V-A-Prinzip (Eingabe - Verarbeitung - Ausgabe) und verbindet dies mit einem definierten Ablauf - einem Workflow. Dieser Verlauf kann Verarbeitungen von einzelnen Ja/Nein-Signalen zur Steuerung von übergeordneten Prozessen bis hin zu umfangreichen Abläufen zur Herstellung von komplexen Produkten umfassen. Um diese Prozesse zu ordnen und in Softwaretools eindeutig zu identifizieren, werden verschiedene Begriffe verwendet wie Hauptprozess, Nebenprozess, Überprozess, Subprozess, Teilprozess.

Bis auf Incident und Change Management sind den anderen Servicemanagement-Funktionen aus ITIL diese ablaufbezogenen Eigenschaften nicht anzumerken. Vielmehr handelt es sich um eine Zuordnung von Aufgaben aus verschiedenen Phasen der Wertschöpfungskette, die dafür Sorge tragen sollen, dass eine bestimmte gewollte Qualität erzeugt wird. So ist es nicht verwunderlich, dass ITIL der wissenschaftlichen Beurteilung als Prozessmodell nicht standhalten kann - und auch nicht will.

Die Servicemanagement-Prozesse nach ITIL stellen Instanzen dar, die über die Einhaltung von definierten Regeln wachen, Messpunkte abgreifen und Berichte zuhanden des Managements erstellen. Das Abgreifen und Berichten dieser Metriken erfolgt in Zyklen, die ein rechtzeitiges Eingreifen durch das Management ermöglichen. Dadurch, dass die Messpunkte nach den aus dem Risikomanagement abgeleiteten Testprinzipien gesetzt werden - das heisst schwachstellen- und schadensausmassorientiert -, können gleichzeitig die Wirkung und die Wirtschaftlichkeit der Messung gewährleistet werden. Ein verfahrensmässiges Gestalten dieser Instanzen, im Extremfall mit einem Modellierungswerkzeug, erübrigt sich. Der schnellste und einfachste, aber unspektakuläre Weg, sich diesen Prozessen zu bemächtigen, ist, sich ein Buch zu kaufen, dessen Inhalt abzuschreiben und sich auf die wesentlicheren Dinge des Servicemanagements zu konzentrieren.

Der fehlende Blick auf die gesamte Wertschöpfungskette

Studien haben ergeben, dass die meisten Vorhaben im Bereich des Service Support, also des Incident, Problem, Change und Configuration Management sowie teilweise im Service Level Management, initialisiert und umgesetzt werden. Obwohl ITIL umfangreiche Empfehlungen für die Serviceplanung und -gestaltung enthält, sind die Erfolge in diesen Phasen der Wertschöpfung bisher sehr bescheiden ausgefallen. Auch die Unterstützung mit integrierten Funktionen ist in diesen Bereichen noch nicht sehr ausgeprägt.

Dies scheint aus den im vorherigen Beitrag dargestellten Sachverhalt naheliegend. Handelt es sich doch beim Service Support um Aufgaben, die in der Wertschöpfungsphase Operations & Optimize selber respektive an deren Grenze durchgeführt werden. Fatalerweise wird damit Servicemanagement auf die operative Phase beschränkt. Die Folge davon ist unter anderem, dass Änderungen nicht bereits bei deren Entstehung als solche wahrgenommen werden, sondern erst kurz vor deren Inbetriebnahme und somit viel zu spät.
ITIL ist die Grundlage für Servicemanagement, und als solche gehört ITIL nicht in die unbeaufsichtigten Hände von Systems Engineers. Das heisst nicht, dass die Engineers bei der Gestaltung von Verfahren und bei der Integration von Werkzeugen, wie im ersten Beitrag der Serie beschrieben, nicht äusserst wertvolle Beiträge leisten können. Doch die Kernelemente von ITIL zielen in erster Linie auf die Verbesserung der Führungsleistung und nicht auf die Standardisierung der Arbeitsinhalte der Mitarbeiter. Engineers glauben aber ausgeprägt an die Vereinfachung und die Standardisierung, und das setzen sie manchmal bis zur bitteren Neige um. Es ist nicht anders erklärbar, weshalb in einer IT-Abteilung alle Mitarbeiter die gleichen RfC (Request for Change) ausfüllen müssen, ob das Formular für ihren Aufgabenbereich passt oder nicht.

Es ist wie in folgender Geschichte aus dem Patentamt: Sitzt ein Mann im Wartezimmer des Patentamtes und hält ein sonderbares Gerät auf seinen Knien. Nach einer Weile kommt ein weiterer Mann hinzu. Nach Minuten des Schweigens fragt der neu hinzugekommene den anderen was denn dieses Gerät leisten kann. «Das ist ein Haarschneideautomat» erwidert dieser stolz, «die Maschine wird auf den Kopf gesetzt und schneidet vollautomatisch den gewünschten Haarschnitt.» Nach einigem Stirnrunzeln und Nachdenken bohrt der Frager nach: «Kann das überhaupt funktionieren? Die Köpfe der Menschen sind doch alle ganz verschieden.» «Ja, ja, da haben Sie schon recht, aber das ist nur beim ersten Mal so.»
Vor diesem Hintergrund kann auch der kürzlich in einer deutschen Computerzeitung erschienene Beitrag besser eingeordnet werden, in dem ein Berater (!) im Zusammenhang mit der «Einführung von ITIL» schreibt, dass «Arbeitsweisen gegen den Willen der Mitarbeiter aufgebrochen werden müssen». Welche Horrorvorstellung für einen Manager und erst noch für die betroffenen Mitarbeiter. Wer Servicemanagement richtig verstanden hat, der wird die Arbeitsweisen von Mitarbeitern in die Entwicklung einbeziehen und diese nicht aufbrechen.

Was Service Management verändert

Die Ungeduld des Managements

ITIL wird häufig als «Wundermittel» betrachtet, als Medizin, die innerhalb von kurzer Zeit Wirkung entfalten kann. Da die Skepsis verständlicherweise sehr gross ist, werden «Quick Wins» heraufbeschworen, mit denen die eigene Hoffnung auf den Erfolg gestärkt werden kann. Quick Wins sind durchaus nützlich, um die Mitarbeiter zu ermutigen, dran zu bleiben, dürfen aber keinen Ersatz für fehlenden Mut und Weitblick des Managements sein. Zudem erfordert die Umsetzung von Quick Wins sehr gute Kenntnisse der Wirkungszusammenhänge im damit beeinflussten Umfeld. Ich muss die Auswirkungen meiner Entscheidung verstehen. Damit verbunden ist auch die Ungeduld mit der Entwicklungsgeschwindigkeit der betroffenen Mitarbeiter. Das Management sollte dabei bedenken, dass die Entwicklung der erforderlichen Managementfähigkeiten mit der operationellen Optimierung in den seltensten Fällen Schritt halten kann.

Der laienhafte Umgang mit Veränderungen

Um die Nachhaltigkeit der erreichten Verbesserungen sicherzustellen, ist eine Verhaltensänderung erforderlich. Diese grundlegende Verhaltensänderung ist denn auch die weitaus grösste Herausforderung für technisch orientierte Serviceorganisationen. Es ist eine Veränderung, die ganz oben beginnt und auch da wieder endet.

Was verändert sich mit Servicemanagement?

Gründe für eine Veränderung innerhalb der eigenen Organisation gibt es in der sich schnell ändernden Welt der IT-Dienstleistungsunternehmen genug: die technische Entwicklung, der Kostendruck, die Ausgliederungen, um nur einige zu nennen. Da diese Veränderungen nach heutigem Ermessen in immer schnellerer Reihenfolge angegangen und umgesetzt werden müssen, besteht die Herausforderung heutiger IT-Manager darin, ihr Unternehmen für den künftigen Wandel entsprechend vorzubereiten. Sind früher Veränderungen im Rahmen von grossen Projekten und Organisationsentwicklungen abgelaufen, wird morgen die Veränderung «Tagesgeschäft» und eine Verbesserung von Arbeitsweise und Strukturen durch eine kontinuierliche Entwicklung (KVP) gesteuert. Leider fehlt den meisten Organisationen momentan die Fähigkeit, sich schnell zu verändern. Sie sind in der Regel schlichtweg nicht in der Lage, kurzfristig auf Veränderungen zu reagieren.

Die Wirkung der Service-Management-Instanzen

Wie aktivieren wir diese Veränderungen?

Strukturen und Prozesse leben nur, indem die Mitarbeiter sich diese zunutze machen und nicht, indem sie sich dahinter verstecken. Wenn also neue Strukturen geschaffen werden, verhalten sich die Mitarbeiter genau wie vorher auch, und so kann ich eine strukturelle Änderung nach der nächsten angehen. Damit dieser Prozess an Dynamik gewinnt, muss gleich zu Beginn deutlich werden, dass es sich auch um eine kulturelle Entwicklung oder besser um eine Entwicklung der Kommunikation und des Zusammenarbeitens handelt. Und hier müssen alle Mitarbeiter involviert werden. Die Entwicklung der Kultur muss sich auf die konkrete Arbeit beziehen und den Zielen (Strategie) des Unternehmens dienen. Nur so erkennen die Beteiligten den Sinn und die Zielrichtung und können nach einer gewissen Zeit sogar ihren eigenen Fortschritt erkennen.

Wie halten wir diese Veränderungen nach?

Eine Veränderung, wie oben beschrieben, kostet Zeit, Mühe und ständige Aufmerksamkeit des Managements. Sie lässt sich nicht wie ein klassisches Projekt organisieren und abschliessen, denn die Ergebnisse werden zu einem integralen Bestandteil der täglichen Arbeit. So sollten beobachtbare Verhaltensweisen die Ziele in Mitarbeiterentwicklungen sein und auch in die Zielvereinbarungen einbezogen werden. Als Führungsperson sollte ich die Richtung der Verhaltensentwicklung nicht aus der Hand geben (die Umsetzung natürlich schon), sondern die Ziele immer wieder in Erinnerung rufen und meinen Mitarbeiter helfen, sie in der Praxis zu erreichen.
Es gilt: Veränderungen finden immer ausserhalb der Komfortzone statt. Veränderung bedeutet: «Habe ich bisher nicht gekonnt oder bisher nicht gemacht, werde ich aber künftig tun.»

Dos and Don’ts einer ITIL-Einführung

Dos

• Änderung unbedingt
zur Chefsache machen

• Vorhaben projektmässig
und kontrolliert umsetzen

• Mitarbeiter/Teams einbeziehen

• Mitarbeitern den Blick auf die gesamte Leistung ermöglichen

• Strukturen der Leistungserstellung transparent machen

• Führungskompetenz
der Teamleiter stärken

• Performance aller Teams definieren und regelmässig nachweisen

• Wenige Regeln definieren,
diese aber konsequent einhalten

• Den Mut zu einfachen
Lösungen aufbringen

• Die Zusammenarbeit
zwischen den Teams fördern

• Freude am Erfolg zeigen und diesen kommunizieren

Don’ts

• Vorhaben an ein Projekt delegieren (und dabei aus den Augen verlieren)

• Die Mitarbeiter überladen,
zuviel auf einmal wollen

• Den Erfolg zu schnell erzwingen

• Geschäftsprozesse der IT durch
ITIL-Prozesse ersetzen

• Formelle Prozessorientierung
zu stark hervorheben

• Den Änderungsvorgang bei den Menschen unterschätzen

• Den Nutzen von Standardisierungen überschätzen

• Die vorhandene Komplexität durch «brillante» Lösungen verstärken

• Beim Werkzeug anfangen

Autor

Walter Vogt ist Gründer des Schweizer Ablegers der ITIL-Nutzervereinigung itSMF und Geschäftsführer von Perseo Consult, Basel.