Wann immer das Thema Governance zur Sprache kommt, ist Cobit nicht weit. Die Control Objectives for Information and related Technology positionieren sich als der Quasi-Standard für IT-Governance.

IT-Governance hat sich aus der übergeordneten Corporate Governance entwickelt, die auf die 1987 ausgesprochenen Empfehlungen der "Treadway"-Kommission in den USA zurückgeht. Daraus entstand 1992 das Coso-Framework, 1996 abgelöst durch Cobit. Wie der Begriff "Control Objectives" bereits suggeriert, bestand das ursprüngliche Ziel in der Kontrolle der IT-Nutzung. Der IT-Governance-Aspekt entwickelte sich erst später daraus.

Ziele und Aufgaben der IT-Governance

Die Definitionen dafür sind sehr abstrakt:

"IT-Governance besteht aus Führung, Organisationsstrukturen und Prozessen, die sicherstellen, dass die IT die Unternehmensstrategie und -ziele unterstützt", so die Definition, die das IT Governance Institute (Itgi) 2006 für die Studie "IT Governance in Practice, Insight from leading CIOs" verwendet hat. Bei einem derartigen Abstraktionsgrad führte die Studie konsequenterweise zu dem Schluss, dass es kein gemeinsames Verständnis dessen gibt, was IT-Governance eigentlich ist.

Etwas klarer wird das Bild, wenn der Blick auf die Ziele der IT-Governance fällt. Hier werden am häufigsten genannt: Compliance(-Kontrolle)und Kostenüberwachung, Ausrichtung der IT an den Unternehmenszielen beziehungsweise -erfordernissen, Erzielen des versprochenen Nutzens sowie verantwortungsvoller Umgang mit IT-Ressourcen.

IT-Governance ist erklärtermaßen eine Aufgabe der Unternehmensführung, also des CEO. Sie soll helfen, die lange beklagte Kluft zwischen der Unternehmenssicht, also den Zielen der Fachabteilungen, und der IT als Service- und Infrastruktur zu überwinden.

Was Cobit zum Quasi-Standard macht

Cobit enthält eine systematische und stringente Darstellung der abstrakten Kernprozesse, die jedes Unternehmen benötigt, wenn es IT einsetzt. Diese 34 Prozesse sind in vier Domänen eingeteilt: Plan and Organise (PO), Acquire and Implement (AI), Deliver and Support (DS) sowie Monitor and Evaluate (ME).

Die Abbildung "Beziehungen zwischen den Cobit-Komponenten" verdeutlicht sowohl die Struktur als auch die Ziele von Cobit: Den Prozessen werden "Control Objectives" zugeordnet, mit deren Hilfe sie sich überwachen lassen. Ebenfalls hinterlegt sind Aktivitäten mit den zugehörigen Zielen. Sie sollen die Prozesse ausführbar machen. Dazu gehören wiederum Key-Performance-Indikatoren (KPIs) und Key-Goal-Indikatoren (KGIs) sowie Reifegradmodelle, mit denen sich die gesamte Systematik nachvollziehbar und messbar halten lässt.

Für den geplagten IT-Chef bedeutet Cobit eine einfache, strukturierte und messbare Vorgehensweise, mit der er seine IT unter Kontrolle bekommt – oder zumindest den Eindruck gewinnt, sie unter Kontrolle zu haben. Für die Auditoren stellt Cobit eine eindeutige Vorgehensweise und eine Checkliste bereit, mit deren Hilfe sie ein hochkomplexes Gebiet strukturiert prüfen können. Damit steigt aber auch der Druck auf den CIO: Die Wirtschaftsprüfer fordern Cobit mittlerweile ein. Und der CEO ist der Ansicht, dass sich das doch einfach mal so machen lassen sollte.

Anspruch auf übergeordnete Gültigkeit für alle IT-Aufgaben

Der Charme des strukturierten Vorgehens auf dieser Abstraktionsebene besteht auch darin, dass sich andere – konkretere – Standards und Methoden in die 34 Hauptprozesse unterbringen lassen. Als Beispiel mag der Hauptprozess "PO10 Mange Projects" dienen: Prinzipiell lässt sich jede konkrete Projekt-Management-Methode hier einordnen. Ähnliches gilt in vergleichbarer Form für alle anderen Hauptprozesse. Daraus leitet sich der Anspruch von Cobit ab, als übergeordnetes Rahmenwerk der Standard für die IT-Governance und sämtliche IT-Aufgaben eines Unternehmens zu sein.

Nun lässt sich trefflich darüber streiten, ob diese Methodik tatsächlich die ganze Komplexität des IT-Managements abbilden kann. Die Antwort hierauf ist ein klares "Nein", denn die Realität ist zu vielfältig. Andererseits gibt es keine wirklich akzeptierte Alternative im Bereich der IT-Governance. Aber die Standesorganisation der Wirtschaftsprüfungen die Vorgehensweise von Cobit. Folglich müssen sich die CIOs damit beschäftigen, wenn sie nachweisen wollen, dass Vorschriften, Nachweispflichten und Berichtspflichten eingehalten werden.

Cobit liefert dem cIO keine Handlungsanweisungen

Der CIO sollte Cobit nutzen, um Schwachstellen, Risiken und Verbesserungspotenziale in der eigenen Organisation sowie in ihren Prozessen zu identifizieren und systematisch darzustellen. Cobit bietet allerdings keine Handlungsanweisungen. Wie das, was gefordert ist, getan werden soll oder kann, wird nicht definiert.

Für die Untersuchung "IT-Governance Global Status Report – 2006" hat das Itgi im vergangenen Jahr knapp 700 Unternehmen weltweit befragt. Die Studie zeichnet ein Bild der Anwendungsrealität in Sachen IT-Governance:

21 Prozent der Organisationen nutzen ISO 9000.

13 Prozent verwenden die IT Infrastucture Library (Itil).

Neun Prozent setzten Cobit ein.

33 Prozent bevorzugen intern entwickelte Frameworks, wobei Cobit oft als "Referenzrahmen" dient.

Dieses Bild bestätigt die anschließende Itgi-Untersuchung "IT-Governance in Practice". Sie basiert auf Tiefeninterviews mit 50 CIOs, die bereits IT-Governance-Projekte begonnen haben:

63 Prozent nutzen Cobit als Framework.

60 Prozent verwenden Itil als Framework.

65 Prozent setzten Cobit und Itil gemeinsam ein.

Itil ist heute der allgemein anerkannte Standard für das IT-Service-Management. Häufig ist es schon im Einsatz, wenn die Unternehmen die Diskussion über IT-Governance erst beginnen. Das erklärt, warum in der Praxis häufig sowohl Cobit als auch Itil verwendet werden.

Die Best-Pactices-Sammlung füllt ziemlich genau die Lücke, die Cobit lässt. Sie gibt Antwort auf die Frage, wie "etwas" getan werden kann oder sollte. Dieses Etwas umfasst Service-Support, Service-Delivery, Security-Management, Application-Management, Financial Management, Infrastructure Management und die Business-Perspektive. Die neue Version 3 erweitert das Spektrum in Richtung Service-Lifecycle-Management.

Eine fast heile Management-Welt

Damit könnte man annehmen, dass die IT-Governance- und Service-Management-Welt fast heil wäre: Es gibt einen Quasistandard für Governance in der Form von Cobit, der unterfüttert ist durch einen Quasistandard für das Service-Management. Aber wie das so ist mit den großen Gedankengebäuden: Im Grundsatz sind sie richtig, in der Realisierung nicht ganz so einfach.

Seit 2006 existiert ein gemeinsamen Arbeitskreis der Information Systems Audit and Control Association (Isaca) und des IT System Management Forum (itSMF), der sich mit dem gemeinsamen Einsatz beider Referenzmodelle beschäftigt.

Folgende drei Themen erachtet der Arbeitskreis als besonders relevant:

Einsatz in der Organisation

Da die Beteiligten unterschiedliche Interessen vertreten, divergieren auch Ziele und Sichtweisen auf Fragen und Probleme teilweise stark. Itil repräsentiert traditionell die Perspektive des Serviceanbieters; Cobit vertritt eher die Sicht des Nutzers oder Käufers von Dienstleistungen. Folglich könnte man bei Cobit von einer Unterbewertung und vielleicht sogar Unterschätzung der Erbringungsleistung sprechen. Sie zeigt sich zum Beispiel beim Blick auf die Aktivitäten im Bereich "Manage Performance and Capacity" oder "Manage the Configuration": Jede Serviceorganisation wird sich hier – zu Recht – schlecht aufgehoben fühlen. Umgekehrt dürfte wohl jeder CFO den Itil-Bereich Financial Management als unzureichend betrachten. Es gilt also, die Balance zwischen den unterschiedlichen Gewichtungen und Sichtweisen herzustellen. Wie viel Sprengkraft darin liegt, wird klar, wenn man sich verdeutlicht, dass sowohl Cobit wie auch Itil einen "allgemeinen" Anspruch erheben.

Verantwortlichkeiten und Rollen

Beide Modelle enthalten grundsätzliche Vorstellungen zu Verantwortung und Rollen in einer Organisation. Diese Grundannahmen sind bei Cobit relativ deutlich erkennbar – in Form von RACI-Charts. Itil vertritt zwar die Prozessverantwortung und Rollenorientierung, hält dies aber nicht ganz durch: Aufbau- und ablauforganisatorische Aspekte treten gemischt auf und lassen sich nicht immer deutlich voneinander abgrenzen. Die Rollen und Verantwortungen der beiden Strukturen müssen aufeinander abgestimmt werden, damit sie kompatibel sind.

Key-Performance-Indikatoren

In beiden Strukturen werden KPIs gefordert und definiert. Allerdings ist – von einigen Ausnahmen abgesehen – nicht gewährleistet, dass es sich um kompatible oder gleiche Indikatoren handelt. Wenn KPIs aus der einen Struktur in die andere übernommen werden, ohne dass ein gemeinsames Verständnis sichergestellt ist, entsteht Verwirrung. In Cobit haben die KPIs einen investigativen Charakter; sie dienen der Aufdeckung von Schwächen. Hingegen haben sie bei Itil eher defensiven Charakter; sie sollen nachweisen, dass der Service in der vereinbarten Form erbracht wurde. Deshalb muss innerhalb der Organisation oder mit dem Dienstleister ein klares Verständnis über die Interpretation bestehen. Vor allem dort, wo es "harte" Überschneidungen gibt ist es erforderlich, die verwendeten Begriffe zu prüfen und abzustimmen. Es sollte auch gefragt werden, ob die Inhalte der Begriffe tatsächlich gleich sind. Wer sich für die Nutzung beider Referenzmodelle entscheidet, muss zudem darauf achten, dass die Übergänge und Schnittstellen zwischen den Modellen sauber abgestimmt sind.

Noch gar nicht angesprochen ist dabei die Frage, inwieweit die Modelle skalierbar sind. Eine große und moderne IT-Organisation wird von den vielfältigsten Lieferbeziehungen zwischen und mit internen sowie externen Dienstleistern geprägt. Sie alle nutzen vielleicht eines oder beide Modelle ganz oder teilweise. Die Probleme, die sich daraus ergeben können, wurden bislang höflich verschwiegen. Bislang müssen sie individuell gelöst werden. (qua)