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.

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. (Computerwoche)