13.03.2009, 11:28 Uhr

Grenzerfahrungen mit einem Standard

Die IT Infrastructure Library hat sich zum De-facto-Standard für Aufbau und Betrieb von IT-Services entwickelt. Doch Standards haben erstens ihre Defizite und sind zweitens nicht immer sinnvoll. Wo fehlts?
Michael Oliver Maier ist Berater bei Maturity Consulting in München
Als Leitfaden für ein strukturiertes und systematisches IT-Service-Management (ITSM) stand ITIL in den vergangenen Jahren zu Recht bei vielen CIOs ganz oben auf der Tagesordnung. Das Rahmenwerk trug zweifellos dazu bei, dass sich die IT kontinuierlich professionalisieren konnte. Im Idealfall liefert eine als Serviceprovider definierte IT-Organisation gegen festgesetzte (Verrechnungs-)Preise ein Produkt oder einen Service an die Fachabteilungen. Davon profitieren beide Seiten: Die IT wird kalkulierbarer und kann ihr Potenzial leichter demonstrieren, weil ihr Wert bekannt ist. Das Top-Management profitiert, weil sich beispielsweise die Kosten einer Business-Applikation bis hinunter zum Plattenplatz verrechnen lassen. So kommt endlich Licht in die einst ominöse Black Box IT. Das wiederum erzeugt Marktdruck, weil jetzt die Möglichkeit besteht, einen Wettbewerb ins Leben zu rufen.
Doch nicht alle IT-Verantwortlichen sind mit dem Rahmen zufrieden, der ihnen durch das ITIL-Framework zur Verfügung gestellt wird. «Es fehlt durch die vorgegebenen Abgrenzungen an Differenzierung und an einer flexiblen Betrachtung der IT», stellt etwa Karl Hüttinger fest,
IT-Leiter des Salzburger Autohandelskonzerns Pappas. Seiner Einschätzung nach schreibt das Framework zu starre Kategorien vor, «die nicht wirklich so zuordenbar sind, wie dies für unsere IT der Fall sein müsste».
Die Pappas-Gruppe, einer der grössten Mercedes-Händler Mitteleuropas, verfügt über eine homogene und hoch integrierte IT. Diese für ITIL aufzubrechen und die Prozesse danach zu gliedern, wäre ineffizient, wenn man das Volumen der Aufgabe und die zur Verfügung stehenden Ressourcen der Pappas-IT gegenüberstellt. IT-Leiter Hüttinger bildet keine Ausnahme, denn für viele kleinere Unternehmen ist ITIL ein Aufwand, der sich kaum lohnt. Schon der administrative Overhead würde einfach zu viel Geld verschlingen. Gerade bei gewachsenen Strukturen kann man nicht einfach den Schalter auf ITIL umlegen. Prozesse, Mitarbeiter und Technologien müssen auf die neue Organisation vorbereitet werden, denn die Veränderung im Unternehmen ist gravierend. Wer ITIL noch nicht eingeführt hat, sollte sich ernsthaft die Frage stellen: Brauche ich das überhaupt nur, weil es ein Standard ist und viele Experten darüber reden? Zumal nicht garantiert ist, dass die IT nach der ITIL-Umstellung tatsächlich schneller oder effizienter läuft als mit den meist gewachsenen Prozessen der alten Organisation.
Hinzu kommen Defizite im Rahmenwerk, die gerade in grösseren Anwenderorganisationen schmerzlich vermisst werden. Zwar erhebt ITIL beileibe nicht den Anspruch, alle Bereiche des IT-Managements vollständig abzudecken. Angesichts des Hypes in den vergangenen Jahren dürfen IT-Verantwortliche indes nicht dem Glauben verfallen, allein die Orientierung am weit verbreiteten Standard verspreche ein umfassendes Prozessmanagement. Leider bedeutet die Standardisierung häufig auch «kleinster gemeinsamer Nenner», was automatisch Lücken reisst. Die wichtigsten werden im Folgenden kurz angerissen.
Lücke 1: Charging

Ungeachtet der Frage, ob ITIL genutzt wird oder nicht, müssen IT-Organisationen heute in der Lage sein, die Leistungsbestandteile ihrer Services den internen Kunden in Rechnung zu stellen. Zu diesem Kernbereich schweigt sich ITIL aber weitestgehend aus. Die Thematik wird
lediglich in einer groben Übersichtsstruktur angerissen: Definition des Verrechnungsmodells, Identifizierung der Leistungen, Preisermittlung, Arten der Leistungsverrechnung und Rechnungsstellung. Für ein echtes Charging müssen sich IT-Verantwortliche darauf einstellen, dass neben ITIL weitere Mechanismen umzusetzen beziehungsweise Beratungsleistungen einzukaufen sind.
Lücke 2: Government & Compliance

Ein wichtiger Teil der IT sind inzwischen die Governance sowie das Risk- und das interne beziehungsweise externe Compliance-Management (GRC). Gerade in diesen Themenfeldern steckt derzeit viel Potenzial, doch in ITIL werden sie nur am Rande, und zwar im Bereich Financial-Management, berücksichtigt. Für Compliance-Management beispielsweise gibt es keinen eigenen Prozess. Dies wiederum führt dazu, dass viele Unternehmen hierfür auf das Cobit-Framework zurückgreifen. Immerhin gibt es Verbesserungen von ITIL V2 auf V3, doch klare Handlungsanweisungen sucht man vergebens. Anwender werden stattdessen auf den ISO/IEC-Standard 27001 verwiesen.
Ohnehin ist es schwer, seine IT lediglich mit ITIL abzubilden. Aus Sicht der Prozesse ist das Framework gesetzt, das sich in V3 mehr an die geschäftliche Seite anzulehnen versucht. Nichtsdestotrotz ist ITIL relativ technisch-operativ orientiert. Auf der anderen Seite steht Cobit, das inzwischen versucht, den bislang schwach ausgeprägten technischen Teil stärker zu berücksichtigen. Cobit bietet indes den Vorteil, dass Managementprozesse umfassender abgebildet werden. Organisationen könnten beispielsweise den operativen Teil über ITIL abbilden und den Managementbereich über Cobit (Strategieentwicklung, GRC). Ideal, wenn auch sehr aufwendig, wäre eine Mischung aus ITIL, Cobit und einem individuell entworfenen Framework für die gewachsenen IT-Strukturen.

Lücke 3: Kennzahlen

Die grösste Lücke klafft aber im Bereich der Kennzahlen. Zwar finden sich auch bei ITIL klassische Prozesskennzahlen wie etwa Durchlaufzeiten oder Kosten sowie einige prozessspezifische Kennzahlen. Um ein vollständiges Bild der IT zu erhalten, müssen jedoch auch die operativen Kennzahlen Berücksichtigung finden. Während in ITIL die Applikation beziehungsweise der Service als Best Practice dargestellt wird, fällt die (Kennzahlen-)Ebene der Bereitstellung grösstenteils unter den Tisch. Der operative Unterbau (Drilldown) wie Server, Speicher, Projekte und Wartung taucht in diesem Framework nicht auf.
Naturgemäss spielen die operativen Kennzahlen für das oberste Management eine untergeordnete Rolle - die Verantwortlichen sollen im Überblick erkennen können, wie die IT läuft. Eine Kennzahl wie die Serververfügbarkeit sollte aber von unten nach oben durchaggregiert werden: Aus den operativen Kennzahlen A, B und C wird etwa die Top-Kennzahl A, diese wird zusammen mit B wiederum zu einer Managementkennzahl. Der Vorteil ist, dass oben nur wenige Werte aufschlagen, man aber unten
erkennen kann, wo ein Projekt oder die Produktivität der Mitarbeiter aus dem Ruder läuft.
Diese offensichtlichen Lücken in ITIL dürfen allerdings nicht als Argument dafür verstanden werden, das Framework guten Gewissens zu ignorieren. «Auch als kleines und mittleres Unternehmen sollte man sich damit beschäftigen», rät etwa Roland Ritsch, IT-Leiter der Raiffeisenbank Kleinwalsertal. Schliesslich helfe die Sammlung von Best Practices dabei, wichtige Punkte nicht zu vergessen - und das Rad muss so auch nicht jedes Mal neu erfunden werden. Für Unternehmen mit beschränkten Ressourcen gelte jedoch, sich die ITIL-Bereiche mit dem vermeintlich grössten Return on Investment herauszupicken, etwa das Incident- oder das Change-Management.

Der IT-Verantwortliche der Raiffeisenbank setzt jedenfalls stark auf Pragmatismus im Umgang mit ITIL: «Man muss bei der Anwendung solcher Standards stets auch die Verhältnismässigkeit im Bezug auf die Unternehmensgrösse berücksichtigen.»

ITIL: Unterschiede zwischen Version 2 und 3

Die ITIL-Versionen V2 (ab 1999) und V3 (ab 2007) unterscheiden sich in der Perspektive: Lag der Blickwinkel zuerst auf den Serviceprozessen, hat die aktuelle Version 3 den gesamten Lebenszyklus der Services im Blick. Die wichtigsten Neuerungen:
- ITIL V3 schlüsselt Prozesse, die bereits in der Version 2 kompliziert waren, weiter auf. So teilt sich das Incident-Management nun in drei Prozesse (Event-Management,
Request-Management, Incident-Management). In der Theorie sind die Abgrenzungen nachvollziehbar, jedoch ist es in der Praxis aufwendig, die vielen neuen Rollen einzuführen.
- ITIL V3 hat den Vorteil, dass es offener für andere Frameworks ist. Um eine IT ganzheitlich zu erfassen, wird aber eine Kombination aus mehreren Rahmenwerken (ITIL, Cobit, Prince2 etc.) sowie eigener Prozesse benötigt.
- ITIL V2 ist der De-facto-Standard. V3 ist weit umfangreicher und dadurch noch komplexer. Wenn ITIL neu eingeführt werden soll, empfiehlt es sich meistens, Prozesse aus V3 zu verwenden, weil sie die Services genauer erfassen.
- Für beide Versionen gilt: Nur weil die IT (theoretisch) zu 100 Prozent ITIL-konform ist, muss sie noch lange nicht gut sein.
Michael Oliver Maier



Das könnte Sie auch interessieren