Die Grenzen von Itil 3

16.08.2007 von Frank  Zielke, Jürgen Groß und Jürgen  Dierlamm
Unternehmen und Behörden reagieren zurückhaltend auf den allumfassenden Service-Lifecycle-Ansatz von Itil 3. Sie ahnen wohl, dass sich hinter den neuen fünf Kernbüchern viel Arbeit verbirgt.

Die neue Version der IT Infrastructure Library (Itil) liegt nun endlich vor. Besonders darauf gefreut haben sich Dienstleistungsunternehmen, die sich einen starken Schub an Nachfragen für (erweiterte) Itil-Implementierungsprojekte und Ausbildungen erhoffen. Das Wesentliche an der neuen Itil-Version ist der Wechsel von einer auf Prozesse ausgerichteten Sichtweise zu einem vollständigen Service-Lebenszyklus – angefangen von der Strategie über Design, Umsetzung und den Betrieb der IT-Services bis hin zu einem kontinuierlichen Verbesserungsprozess. Hinzu kommen sinnvolle Ergänzungen wie das Service-Portfolio-Management oder ein umfassendes Service-Wissens-Management-System, ohne das ein kontinuierlicher Service-Verbesserungsprozess nicht möglich wäre. Aber auch Redundanzen und nicht verständliche Prozess-Bestandteile aus der Version 2 des IT-Handbuches werden verbessert.

Hier lesen Sie ...

  • Welche Schwerpunkte die aktuelle Itil-Version hat;

  • welche Probleme die Rollenbeschreibungen in sich bergen;

  • warum Itil keine Organisationsmodelle empfiehlt;

  • welche Nachbesserungen beim Financial-Management erforderlich sind.

Ein steinerner Weg

Die Inhalte der fünf Bände von Itil 3: Die fett geschriebenen Prozesse sind neu.

Im Itil der Version 3 lässt sich absehen, dass zwei Themenbereiche auch weiterhin dynamischer Entwicklung unterliegen und sich weiter anpassen müssen. Zum einen geht es um organisatorische Fragen, zum anderen um die Rollen und Verantwortung in einer IT-Service-Organisation. Obwohl an vielen Stellen das Raci-Modell (Responsible, Accountable, Consulted und Informed) als relevant und hilfreich für Rollen und Prozessbeschreibungen erläutert wird, existiert noch eine deutliche Zurückhaltung, dies auch tatsächlich in den vorgeschlagenen Rollenbeschreibungen anzuwenden.

Tendenziell werden immer noch aus definierten oder zu definierenden Aufgaben sofort "Management-Rollen" gemacht. Bei der Beschreibung der Service-Design-Aufgaben findet sich beispielsweise als Rolle der Service-Design-Manager. Seine Gesamtbeschreibung ähnelt der Rolle eines CIO, doch wenn man dann die Rolle des IT-Planners betrachtet, hat man bereits den nächsten Inhaber eines Postens, der Anspruch auf den Titel CIO erheben könnte.

Itil hat traditionell – und mit gutem Grund – vermieden, Organisationsmodelle vorzuschlagen oder anzunehmen, und sich auf Rollendefinitionen konzentriert. Diese führen jedoch mittlerweile zu einer solchen Vielfalt, dass die Überlappung zwischen den Rollen sehr groß geworden ist. Selbst bei vorsichtiger Zählung sind in Itil 3 mehr als 50 Beschreibungen oder Definitionen von Rollen enthalten.

Einerseits sind solche Darstellungen sehr hilfreich: Immer dann – und das ist häufig der Fall –, wenn Itil nicht in seiner Gesamtheit angewendet werden kann oder soll, geben Rollenbeschreibungen sehr nützliche Hinweise darauf, welche Aspekte bei einer konkreten organisatorischen Aufgaben- oder Funktionsbeschreibung zu bedenken sind. Auf der anderen Seite wird es jedoch problematisch, wenn ein Unternehmen sich tatsächlich ganz auf Itil einstellt und alle Rollen abbilden will oder muss. Dies ist nahezu unmöglich, weil auch in der neuen Version die Schnittstellen zwischen Prozessen und Rollen zwar angesprochen, aber nicht erläutert sind. In der zukünftigen Weiterentwicklung von Itil wird deshalb den Rollen und Verantwortungen noch mehr Bedeutung zukommen.

Der zweite Problembereich ist eng verbunden mit der Frage der Rollen und Verantwortlichkeiten: Es geht um organisatorische Realisierung und Skalierbarkeit. Heute sind die vielfältigsten Mischformen der IT-Service-Erbringung an der Tagesordnung. Was in den Outsourcing-Strategien im Buch "Service Strategy" fein säuberlich getrennt dargestellt wird, findet in der Realität gleichzeitig statt. Internal Sourcing, Shared Services, Full-Service-Outsourcing, Consortium-, Prime- und Selective- Outsourcing sind in einem mittelgroßen bis großen Unternehmen zum Teil parallel betriebene Strategien. Sie werden auch kaskadierend eingesetzt, das heißt, während ein Unternehmen zum Beispiel ein Full-Service-Outsourcing betreibt, hat der Auftragnehmer seinerseits selektiv einige Funktionen ausgelagert. Die sich daraus ergebende Beziehungsvielfalt und deren Kosten bedürfen einer sorgfältigen Betrachtung und Bewertung, da die Schnittstellen und Kontrollfragen ausschlaggebend für die Leistungsqualität sind. Zumal davon auszugehen ist, dass Servicebeziehungen zukünftig noch stärker verflochten werden.

Erfreulicherweise beschäftigt sich insbesondere das Buch "Service Strategy" sehr intensiv mit unternehmensorientierten Fragen sowie Themen der Organisationsentwicklung. Allerdings findet sich wenig zu der Frage, wie und mit welchen Aufgaben IT-Service-Management in komplexen Organisationen abgebildet werden soll. Die angesprochenen Organisationsmodelle sind sehr abstrakt und geben keine Hinweise für die Praxis. Da auch hier weitere rasante Entwicklungen zu erwarten sind, ist zu hoffen, dass auch diese Themen in der nächsten Version intensiver und konsistenter behandelt werden.

Der Lifecycle hat noch Lücken

Nichts ist so perfekt, dass es nicht gleich wieder einer Verbesserung unterliegen könnte. So verhält es sich auch mit den "Financial Management for IT Services", einem wichtigen Prozess aus Itil 3. In der vorherigen Ausführung war dieser Bereich Teil der Service-Delivery-Gruppe und in den anderen vier Prozessen zur taktischen Planung und Steuerung von IT-Services entsprechend tief verankert. Ein Credo lautete zum Beispiel: kein SLA ohne entsprechende Passagen zur Preisgestaltung und Leistungsverrechnung. Leistung (IT-Service) und Gegenleistung (Preis) sollten sich gegenüberstehen und entsprechen. Juristen nennen das Synallagma. Bei vertraglichen SLAs ist diese Entsprechung ohnehin erforderlich. SLAs und deren Umsetzung in der Erbringung von IT-Services müssen kostendeckend sein, egal welches Geschäftsmodell und welche Art der Verrechnung der Service-Provider betreibt. Auch bei der Planung und Optimierung von Verfügbarkeit und Kapazität gab es dedizierte Nahtstellen zum Financial-Management. Selbst Service-Support-Prozesse haben vor allem über das Change-Management darauf Bezug genommen.

Itil 3 definiert das Financial-Management, richtet sich dabei aber vornehmlich an Service-Provider.

Inhaltlich blieb der Prozess in Version 2 zwar auf einer Ebene des betriebswirtschaftlichen Basiswissens stehen: Budgetplanung, Kostenrechnung (Kostenstellen, -arten, -träger), Preisgestaltung, Leistungsverrechnung auf Basis Kostenträger, ansatzweise auch Controlling sind Know-how auf Basis eines betriebswirtschaftlichen Grundstudiums ohne besonderen Bezug auf IT-Service-Management. Allerdings war dies auch schon mehr, als viele Firmen im Bereich IT-Controlling und vor allem in der Leistungsverrechnung (Pricing, Charging/Billing) bis vor wenigen Jahren zu leisten imstande waren.

Itil 3 definiert Financial-Management grundsätzlich gleich, und zwar folgendermaßen: "The Function and Processes responsible for managing an IT Service Provider's Budgeting, Accounting and Charging Requirements". Allerdings ist der Prozess nun noch konsequenter ausgerichtet an IT-Services aller Liefermodelle von Service-Providern, am Budget als strategischem Service-Asset und an Return-on-Investment-Analysen sowie Business-Cases für IT-Services. Financial-Management ist Teil der Service-Economics in der Service-Strategy – und das ist grundsätzlich auch gut so.

Wer die Aufteilung der bisherigen Itil-2-Prozesse in die fünf Core-Bücher von Itil 3 kennt, würde vermuten, dass in allen Bereichen Teile des Financial-Managements enthalten sind. Aber dem ist nicht so. Als Prozess oder Rolle findet es sich nur in der Kernpublikation "Service Strategy" wieder. Einzige Ausnahme sind RoI-Betrachtungen im Band "Continual Service Improvement".

Hier ist ein klares Manko auszumachen: Ein Service kann ohne Prüfung der finanziellen Machbarkeit der Service-Level-Requirements nicht gestaltet werden (Service-Design) und ohne Betrachtung der Kosteneinhaltung sowie -Vorgaben nicht in den Betrieb übernommen beziehungsweise dort nicht zielführend betrieben werden (Transition und Operation). Im Service-Lifecycle sind in verschiedenen Stadien Antworten auf Fragen rund um Servicekosten und Budgets erforderlich. Wenn man bedenkt, dass fast alle Itil-2-Prozesse in der neuen Version auf die fünf Bände aufgeteilt wurden, ist es schon verwunderlich, dass gerade das Financial-Management nur unter "Service Economics" im Strategy-Teil auftaucht.

Keine Frage: Geld ist immer noch der Motor des IT-Betriebs, und diese Ressource ist auch in Itil 3 als wichtiges Service-Asset hervorgehoben. Geld kommt immer noch vom Kunden und dessen Business, zumindest in der Refinanzierung der Service-Provider. Die strategische Bedeutung steht damit unumstritten fest. Im Band "Service Design" wäre deshalb ein Teil des Financial-Managements gut aufgehoben, am besten verankert mit dem Service-Level-Management-Prozess.

Was darf ein Service kosten?

Servicekosten waren schon immer ein heikler Punkt in jeder IT-Organisation. Wer kann Ist-Zahlen und Budget der einzelnen Service-Bestandteile liefern? Wo wird eine Grenze gezogen? Was dürfen Changes kosten, und wer bezahlt sie? Das sind alles sehr konkrete und berechtigte Fragen, die man erst nach Lektüre aller fünf Bücher der neuen Version beantworten kann. Und das, obwohl die Herausgeber vorgaben, dass je nach Stadium im Service-Lifecycle die Antworten im jeweiligen Buch direkt zu finden sind.

Die in den fünf Itil-Büchern beschriebenen Prozesse greifen ineinander und bilden einen kompletten Service-Lifecycle.

Sowohl im Band "Transition" als auch im "Operation" fehlt es an einer konsequenten Verantwortlichkeit für den Vergleich von Budget- und Servicekosten mit den Strategy- und Designvorgaben. Das gilt sowohl für die Kosten der Einführung von Services als auch für die des laufenden Betriebs. Hier wäre eine Aufteilung des Financial-Managements besser gewesen. Zu warten, bis der Service dem Zyklus der nächsten Continual-Service-Improvement-Maßnahme unterliegt (Band 5 - RoI-Betrachtung), greift zu kurz. Um den Gesamtwert der IT zu optimieren, empfiehlt sich der Band "Continual Service Improvement". Dort wird die Feedback-Schleife zurück von den Erfahrungen des Betriebs in die Strategie, aber auch in die anderen drei Itil-Bestandteile geliefert. Das ist im Prinzip auch gut und richtig.

Die Praxis der Itil-3-Implementierungen wird zeigen, dass es zu Beginn an Ressourcen mangelt, um alle Services immer schnell auf die Einhaltung und mögliche Verbesserung der Kostenvorgaben hin zu analysieren. Dies wird zyklisch in Audits erfolgen. Doch dann fehlen konkrete, rasche Antworten auf die zuvor gestellten Fragen. Nach Itil 3 müsste man dazu Rollen aus der Service-Strategy befragen, vor allem den Product-Manager. Besser wäre, die Rolle eines Financial-Managers in allen anderen Version-3-Prozessgruppen gleichermaßen zu verankern und die Aktivitäten des Prozesses so aufzuteilen, wie die zu messenden Anteile der anderen vier Service-Delivery-Prozesse aus dem Service-Design von Itil 2 auf die nachfolgenden drei Bände aufgeteilt worden sind. Das Motto aus dem Band 2 (Service-Design), "The best Service Strategy cannot be realized without well designed services", müsste ergänzt werden durch "And not without well delivered services". (jha)