Foto: Raywoo - Fotolia.com
Regelwerke sind brauchbare Instrumente für die Strukturierung und Ausrichtung der IT-Organisation dar. Unter bestimmten Bedingungen und für gewisse Zwecke helfen sie den Unternehmen, ihre IT zu optimieren, indem sie Definitionen, Techniken, Prozesse und Vorgehensweisen als Orientierungsrahmen und Starthilfe anbieten. Die darin enthaltenen "Best Practices" oder "Common Practices" sind zudem eine Quelle guter Ideen.
Allerdings werden solche Regelwerke oder De-facto-Standards häufig als Rezeptbücher missverstanden, von denen nur "Unläubige" abweichen. IT-Verantwortliche machen sich selbst zur Geisel dieser Standards, wenn sie sich sklavisch an die Vorgaben halten, anstatt sie als Methodenvorschlag zu begreifen und intelligent auf die eigenen Unternehmenserfordernisse zuzuschneiden.
Nur das Was, nicht das Wie
Obwohl die Regelwerke sehr umfangreich sind, beschreiben sie eigentlich nur das Was. Damit eignen sie sich für die operativ Verantwortlichen allenfalls bedingt als Ideengeber. Denn die Praxis fragt weniger danach, was zu tun ist, sondern wie das unter Berücksichtigung der Ausgangslage im eigenen Unternehmen funktioniert.
Von daher ist Zweierlei sinnvoll: Zum einen sollten sich die Unternehmen auf die Kernideen der Frameworks konzentrieren. Zum anderen müssen sie deren Umsetzung konsequent an den eigenen Zielen und Handlungsbedürfnissen ausrichten.
Fehleinschätzungen und Missverständnisse
Als Beispiel für Fehleinschätzungen kann die Einführung "ITIL-konformer" Prozesse im IT-Service-Management gelten - vor allem in konzerngebundenen IT-Organisationen. Zunächst ist zu fragen, was eigentlich ITIL-konform bedeutet. In der Praxis sind ja teilweise erhebliche Anpassungen der ITIL-Vorgaben an das Unternehmen vorzufinden.
Sodann muss mit einem Irrglauben aufgeräumt werden. Die Orientierung an dem internationalen De-facto-Standard zieht nicht automatisch eine durchgreifende Verbesserung der Leistungsqualität oder gar eine Kostenreduktion nach sich. Letzteres ließ sich bislang noch durch keine unabhängige Studie belegen (siehe beispielsweise Rob England, Review of Recent ITIL Studies).
Inzwischen sind viele ITIL-engagierte Unternehmen tief enttäuscht darüber, dass entgegen ihrer Erwartung weder der Output an Leistung noch die Kosteneffizienz gestiegen sind. Ein Nutzen stellt sich in aller Regel erst dann ein, wenn die implementierten Prozesse auch in der Aufbauorganisation des Unternehmens verankert und bei den Mitarbeitern angekommen sind. Die empfohlenen Best-Practice-Kennzahlen ungefiltert den IT-Regelwerken zu entnehmen lässt sich oft nicht mit Geschäftsstrategie des Unternehmens vereinbaren.
Eines der größten Missverständnisse haben die ITIL-Protagonisten im OGC (nun Cabinet Office) selbst geschürt. Nämlich die These, dass ITIL keine Prozesse sondern Funktionen beschreibe. Tatsächlich definiert ITIL Funktionen innerhalb eines bipolaren Organisationsmodells zwischen Kunde (Business) und IT-Dienstleister. In der Unternehmenspraxis gilt es aber, über mehrere Organisationsbereiche hinweg IT-Prozesse und -Verfahren einzuführen und zu steuern.
Dabei spielen mit: der jeweilige Fachbereich (getrennt nach Kunde und User), der zentrale IT-Dienstleister, in großen Unternehmen auch eine IT-Governance-Einheit sowie dezentrale IT-Dienstleister, die unter Umständen tief in den Fachbereichen verankert sind. Hat das Unternehmen Teile seiner IT ausgelagert, kommen noch ein oder mehrere externe IT-Dienstleister hinzu. Dieses komplizierte und manchmal auch komplexe Gebilde gilt es, im Sinne der Unternehmensstrategie optimal auszurichten. Ein generisches Modell ist dafür ungeeignet; das kann nur mit unternehmensspezifisch zugeschnittenen Lösungen gelingen.
Zur Abbildung der Schnittstelle von Unternehmen zu (externen) IT-Dienstleistern hat sich ITIL zweifellos etabliert. Es ist inzwischen zur Selbstverständlichkeit bei Ausschreibungen und Angeboten beim IT-Infrastruktur-Outsourcing geworden. Allerdings gibt es auch hier Einschränkungen: Konzepte wie "Operational Integrator" beim Multi-Sourcing mit kaskadierenden Prozessen und Verantwortlichkeiten lassen sich damit allenfalls unzureichend abbilden.
Mangelndes Verständnis
Das Ziel, über Standards das gemeinsame Verständnis von Sachverhalten zu schaffen, ist de facto nur begrenzt erreichbar. Bereits in der Verständigung zwischen IT-Verantwortlichen untereinander ist trotz Einführung eines Standards ein Manko festzustellen. Noch weniger haben es Regelwerke bisher geschafft, das Zusammenspiel von IT-Abteilungen und Fachbereichen hinsichtlich der Kommunikation klarer zu gestalten. Das ist auch nicht verwunderlich, wenn man bedenkt, dass die fachlichen Schulungen für IT-nahe Frameworks fast ausschließlich auf die IT-Mitarbeiter fokussiert sind.
Aber ganz davon abgesehen dürfen Regelwerke inhaltlich nicht als Inbegriff der Wahrheit verstanden werden. Schließlich beruhen sie nicht unbedingt auf einer durchgängig präzisen oder allgemein anerkannten Terminologie. Deshalb war ja das im vergangenen Jahr veröffentlich Refresh von ITIL V3 mit einer deutlichen Schärfung von Begrifflichkeiten und Definitionen notwendig. An dem Regelwerk haben weltweit zahlreiche Autoren mitgewirkt. Solche Bedingungen bergen selbst bei großem Bemühen um fachliche Genauigkeit das Risiko inhaltlicher und terminologischer Widersprüchlichkeiten. Auch deshalb ist vor einem zu großen Vertrauen in die die IT-Regelwerke zu warnen.
It´s not a trick, it´s a service
Mit ITIL hielt der Begriff "Service" Einzug in die IT-Bereiche der Unternehmen. Doch ITIL hat es bislang nicht geschafft, diesen Begriff verständlich und praxistauglich zu definieren sowie von anderen Definitionen/Begriffen abzugrenzen. Dort lautet die Beschreibung: "a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks". Was aber ist ein solches Mittel ("means")? Was sind die spezifischen Kosten? Eine allgemeingültige Definition des Servicebegriffs lässt sich auf diese Weise nicht erreichen.
Ein unabweisbares Problem einer starken Regelwerksorientierung besteht zudem darin, dass die Frameworks ständig umfangreicher werden - sowohl hinsichtlich des Scope als auch der Detaillierung. ITIL, CoBIT und Togaf sind Paradebeispiele dafür. Dadurch geraten die Frameworks zu sehr in den Mittelpunkt und werden zum Selbstzweck. Zudem steigt durch die immer komplexeren Methoden auch der Bedarf an regelwerksspezifischer Fortbildung/Zertifizierung und an Projektressourcen, ohne dass diesem Mehraufwand ein nennenswerter Nutzengewinn gegenüberstünde. Außerdem verlängert sich die Projektdauer, was im Regelfall mit Kostensteigerungen einhergeht.
Standards reduzieren Kreativität
IT-Prozesse entstehen selten auf der grünen Wiese. Daher sind in der Unternehmenspraxis immer mehrere Einflussgrößen für die Organisationsgestaltung zu berücksichtigen - beispielsweise Größe, Kultur, Geografie, Produktspektrum, Mitarbeiterfähigkeiten, Wertschöpfungstiefe in der IT, vorhandene IT-Unterstützung etc. All diese Anforderungen kann ein generisches Referenzmodell nicht leisten.
Schneller und kostengünstiger umgesetzt sind unternehmensspezifische IT-Prozessdesigns, die durchaus an gängige Standards angelehnt sein können, aber die Prozessschritte aus der Praxis heraus begründen sollten. Hilfreich ist hierbei, die Anforderungen der ISO 20000 (aus ITIL abgeleitet) als Prozesscheckliste zu verwenden, also zu überprüfen, ob die dort festgeschriebenen Anforderungen/Merkmale von den eigenen und unternehmensspezifischen Prozessdesigns abgedeckt werden. Um jedem Missverständnis vorzubeugen: Ein Standard ist schon wichtig, es sollte aber ein Unternehmensstandard sein - so individuell wie der Betrieb selbst. (qua)