20 5 Mythen über COBIT 5

IT-Governance 24 | September 2016

Zum Thema5 Mythen über COBIT 5Martin Ehrlich

COBIT 5 ist ein Rahmenwerk für Governance und Management der Unternehmens-IT. Seit seiner Veröffentlichung durch die ISACA im Jahr 2012 erfährt es aufseiten der IT-Revisoren und Prüfer eine große Popularität, während es in den IT-Abteilun-gen oft auf Unverständnis, Irritation und Ablehnung stößt. Vie-le IT-Abteilungen sehen sich mittlerweile durch ihre Prüfer dem Druck ausgesetzt, sich mit COBIT 5 auseinandersetzen zu müs-sen, ohne dass sie für sich einen direkten Mehrwert erkennen. Dieser Artikel möchte ein paar der Vorurteile über COBIT 5, die im Laufe der Zeit in den IT-Abteilungen entstanden sind, ausräumen bzw. entkräften. Es wird gezeigt werden, welchen Nutzen COBIT 5 auch für die IT-Abteilungen hat und wie es eingesetzt werden kann.

Seit COBIT 5 im April 2012 veröffentlicht wurde, verursacht es Wellen. In Prüferkreisen kam es schnell zu großer, teilweise begeisterter Akzeptanz, schien es doch in vielerlei Hinsicht praxisnäher und vollständiger als seine Vorgänger zu sein. Aufseiten der IT-Abteilungen gab es eher eine Welle der Ir-ritierung, bahnte sich doch da ein weiteres Rahmenwerk seinen Weg, dessen Nutzen man nicht erkennen konnte und man die Einführungen anderer Rahmenwerke wie ITIL oder ISO 2700x gerade hinter sich gebracht hatte. COBIT 5 hätte man gerne ignoriert, würden die Prüfer dies zulassen. Doch immer mehr unternehmensinterne Prüfer orientieren sich an COBIT 5 – teilweise ohne ihre IT-Abteilungen vorher darü-ber zu informieren.

Es entstanden Vorurteile über COBIT 5, die zu einer Reihe von gerne wiederholten Mythen über COBIT 5 mutierten, die in vielen IT-Abteilungen liebevoll gepflegt werden und die wir in diesem Artikel ein wenig entkräften wollen.

COBIT 5 ist ein Rahmenwerk für die Governance und das Management von IT in Unternehmen. Seine prominentesten (nicht wichtigsten oder größten) Aspekte sind das Enabler-Modell (vgl. [ISACA 2012a]) und das Prozessmodell (vgl. [ISACA 2012b]). COBIT enthält viele weitere Bestandtei-le, doch gerade das Prozessmodell wird oft als Synonym zu COBIT 5 wahrgenommen und am meisten diskutiert.

Das Enabler-Modell beschreibt alle Aspekte (= Enabler), die bei der Einführung und dem Betrieb einer Unternehmensfunk-tion (wie z.B. der IT) betrachtet werden müssen. Das Modell arbeitet mit den in Abbildung 1 angegebenen Enablern, weist ihnen Attribute zu und verlangt, dass sie einem verwalteten Lebenszyklus unterliegen. Damit ist das Enabler-Modell das

Mittel, das zur Gestaltung von Unternehmensfunktionen ver-wendet wird: Welche Prozesse werden gebraucht? Welche Fähigkeiten werden benötigt? Mit welchen Informationen wird gearbeitet? Wie ist die Kultur des Unternehmens aus-gerichtet?

Abb. 1: COBIT 5 – Enabler-Modell [ISACA 2012a, S. 27]

»Prozesse« sind nur einer der sieben Enabler und das Pro-zessmodell ist das Modell der Prozesse, die eine IT-Funktion im Unternehmen braucht, um ihre Aufgabe zu erfüllen. Das Prozessmodell ist das, was oft als Kern von COBIT 5 verstan-den wird. Aber das ist irreführend. In COBIT finden sich zu allen sieben Enablern Modelle in Form von Beispielen und Templates, wie sie im Unternehmen ausgeprägt sein könnten oder sollten. Das Prozessmodell ist nur eines von ihnen. Was wir im Folgenden über das Prozessmodell sagen, kann prinzi-piell auch auf alle anderen Enabler übertragen werden.

Mythos 1: COBIT 5 ist ein operationalisierbares Rahmenwerk. Es einzuführen bedeutet, das COBIT-5-Prozessmodell einzuführen.

Man könnte diesen Mythos auch so formulieren: Man macht nur entweder ITIL (bzw. ein anderes IT-Rahmenwerk) oder COBIT 5. Beides zugleich ist sinnlos.

Die Idee dieses Mythos ist, dass COBIT 5 detaillierte In-formationen enthält, wie IT-Prozesse effektiv und effizient durchgeführt werden sollen. COBIT 5 einzuführen würde bedeuten, die COBIT-5-Prozesse als konkrete Vorlagen für

5 Mythen über COBIT 5 21

IT-Governance 24 | September 2016

cess set, taking into account the specific situation« [ISACA 2012b, S. 24].

In den Prozessbeschreibungen in COBIT 5 sind viele Details enthalten. Aufgrund der Kompaktheit der Beschreibungen (4 Seiten pro Prozess) sind diese Details oft jedoch weder klar definiert oder erläutert noch in einen Kontext gesetzt. Viele der beschriebenen Anforderungen an die Prozesse beinhal-ten für das kundige Auge in zwei Zeilen ganze eigenständige Prozesswelten. Dies soll am Beispiel »Enterprise Architec-ture Management« (EAM) verdeutlicht werden: Der Prozess APO03 »Manage Enterprise Architecture« wird – wie alle Prozesse in COBIT 5 – auf vier Seiten beschrieben. Dem steht das EAM-Rahmenwerk TOGAF 9.1 gegenüber, in dem auf vielen Hundert Seiten beschrieben wird, wie eine EAM-Funk-tion effektiv und effizient aufgebaut und betrieben werden kann.

Aber: Kennt man TOGAF 9.1, so erkennt man, dass die Au-toren des APO03-Prozesses ebenfalls TOGAF 9.1 kannten. Die Prozessbeschreibung in COBIT 5 ist nichts anderes als eine Kurzfassung etlicher TOGAF-Elemente, eingebettet in das COBIT-Rahmenwerk und versehen mit den notwendigen

die eigenen Prozesse zu verwenden – so, wie man es z.B. von ITIL kennt (ja, wir wissen es, auch bei ITIL muss viel ange-passt werden).

COBIT 5 kennt 37 IT-Prozesse in seinem Prozessmodell. Es wird wohl kaum ein Unternehmen geben, das genau diese 37 Prozesse in genau diesem Zuschnitt etabliert hat. Der Zu-schnitt der definierten Prozesse wirft operative Fragen auf: Brauche ich wirklich eigenständige Governance-Prozesse? Das Verwalten von Beziehungen zu Stakeholdern (APO08) mache ich doch durch meine Supply- oder Key-Account-Ma-nager. Wozu dann noch einen Prozess? Wo wird eigentlich eine übergreifende RUN/CHANGE-Sicht hergestellt? Die Steuerung von Change (APO05) und Run (APO06) sind in COBIT 5 getrennt.

Diese Einwände sind prinzipiell richtig, gehen jedoch am Ziel von COBIT 5 vorbei. Es wird nicht verlangt, diese Pro-zesse so in dieser Strukturierung einzuführen. Im Gegenteil: COBIT fordert explizit dazu auf, ein eigenes Prozessmodell zu nutzen: »The proposed [COBIT 5] process model is a complete, comprehensive model, but it is not the only possi-ble process model. Each enterprise must define its own pro-

Abb. 2: COBIT 5 – Prozessmodell [ISACA 2012b, S. 26]

22 5 Mythen über COBIT 5

IT-Governance 24 | September 2016

ser ist in COBIT 5 jedoch der Prozess APO02. Deswegen kann und muss COBIT 5 nicht direkt operationalisiert wer-den und die eigenen Prozesse müssen nicht nach COBIT 5 zugeschnitten werden. Das ist weder Ziel des Prozessmodells noch Anspruch von COBIT 5. Auch kann und will COBIT die anderen Rahmenwerke nicht ersetzen.

Mythos 2: Wenn man COBIT 5 einführt, dann muss man (wieder) viele Leute schulen.

Viele Unternehmen haben in letzter Zeit ITIL, TOGAF, CMMI oder andere IT-relevante Rahmenwerke eingeführt oder haben sich ISO-xyz-zertifizieren lassen und aus die-sem Anlass viele ihrer Mitarbeiter mit einigem Aufwand geschult. Viele dieser Rahmenwerke enthalten im Vergleich zu COBIT 5 detailliertere Informationen zu einzelnen Pro-zessaktivitäten und haben so einen direkteren Einfluss auf die tägliche Arbeit der Mitarbeiter. Wie wir bereits dargelegt haben, ist das nicht der Anspruch von COBIT 5, das nicht direkt operationalisierbar ist. Deshalb ist es auch nicht sinn-voll, alle operativen Mitarbeiter von Anfang an in COBIT 5 zu schulen.

Doch wer muss oder sollte geschult werden? Und warum in welchem Umfang?

Halten wir uns vor Augen, dass COBIT 5 über seine sieben Enabler Hinweise und Anforderungen an alle Aspekte der IT bereithält, deshalb sollte breites und detailliertes Wissen über COBIT 5 auf jeden Fall bei den Personen vorhanden sein, die die IT in Ablauf- und Aufbauorganisation gestalten. Dies ist

Querverweisen in das TOGAF-Rahmenwerk. Ähnlich wird mit anderen Rahmenwerken wie ITIL V3 2011, ISO 38500, COSO, ISO 20000 oder PRINCE2 verfahren. Und diese Rahmenwerke sind nur ein Auszug von denjenigen, auf die in COBIT 5 verwiesen wird. Diese Verweise können auch in umgekehrter Lesart verwendet werden. Hat man bereits ITIL, COSO oder andere etabliert, so helfen einem diese An-gaben, sich in COBIT zurechtzufinden.

Was ist also der Sinn des COBIT-5-Prozessmodells? COBIT 5 stellt mit seinem Prozessmodell die Anforderungen an alle IT-Prozesse übergreifend zusammen. Als Quellen dienten dabei oft andere, spezialisiertere Standards und die Erfahrungen, die die ISACA in vielen Jahren Arbeit in IT-Abteilungen zu-sammengetragen hat. Insgesamt ergibt sich so ein sehr voll-ständiges Bild davon, was eine IT-Abteilung leisten können muss. Es geht um Effektivität, nicht um Effizienz, also um die Frage, WAS zu tun ist, nicht das WIE. Zu vielen der einzel-nen Prozesse gibt es ganze Rahmenwerke, die dann auch auf Effizienz eingehen (sollten).

Die COBIT-5-Prozesse sind per definitionem eine thema-tische Gliederung von Anforderungen an IT-Prozesse. So braucht ein Unternehmen tatsächlich nicht notwendigerwei-se eigenständige Governance-Prozesse. Es braucht aber einen oder mehrere Prozesse, die die Anforderungen aus COBIT 5 an die Governance-Prozesse erfüllen. So wird zum Beispiel die Aktivität »Ermitteln Sie, was im Unternehmen als Wert gilt«, die in COBIT 5 zum Governance-Prozess »EDM02 – Sicherstellung der Lieferung von Wertbeiträgen« gehört, in der Praxis eventuell dem Strategieprozess zugeschlagen. Die-

Rolle

Schulungsaufwand

Minimal Mittel Maximal

»IT-Gestalter« COBIT 5 Foundation COBIT 5 Foundation (COBIT 5 Implementation)

COBIT 5 Foundation COBIT 5 Implementation

Prüfungsbegleiter COBIT 5 Foundation COBIT 5 Foundation COBIT 5 Foundation

Prozessowner Keine Schulung

Prozessowner werden von den »IT-Gestaltern« über den Einfluss, den COBIT auf sie hat, informiert.

COBIT 5 Foundation

Die Verantwortung für die COBIT-Umsetzung liegt weiterhin bei den »IT-Gestaltern«, die die Prozessowner unterstützen.

COBIT 5 Foundation (COBIT 5 Implementation)

Prozessowner können bilateral mit anderen Prozessownern ihre Prozesse an COBIT 5 ausrichten, ohne von zentraler Unterstützung abhängig zu sein.

Alle anderen Keine Schulung COBIT 5 Foundation (Key User)

COBIT 5 Foundation

Zur Erleichterung der Zusammenarbeit mit den »IT-Gestaltern« und zur Verbesserung des Verbesserungsprozesses.

»COBIT 5 Foundation« und »COBIT 5 Implementation« sind Zertifizierungen der ISACA, USA

Unterstützung für Reifegrad der COBIT-5-Umsetzung

Abb. 3: Schulungsaufwand bei Einführung von COBIT 5

5 Mythen über COBIT 5 23

IT-Governance 24 | September 2016

oft Kernaufgabe von Personen im CIO-Stab, kann aber auch in Prozessmanagementteams oder Betriebsorganisationsab-teilungen angesiedelt sein. Auch Personen, die regelmäßig mit (nach COBIT 5 arbeitenden) Prüfern Kontakt haben, sollten sich intensiv mit COBIT 5 auseinandergesetzt haben.

Eine Gruppe von Personen, die zumindest detailliertes Wis-sen über das COBIT-5-Prozessmodell haben sollte, sind die Prozessowner, die die Aufgabe haben, »ihre« Prozesse zu ge-stalten. Sie sollten nicht nur die Anforderungen an »ihren« Prozess kennen, sondern auch die sie betreffenden Aspekte aus anderen Prozessen und allen Enablern, nicht nur dem Prozess-Enabler.

Der Umfang der Schulungen für alle anderen Mitarbeiter hängt davon ab, wie weit man das Enabler-Modell und sein Potenzial für eine bessere Strukturierung des organisatori-schen Verbesserungsprozesses nutzen möchte. Soll das Ena-bler-Modell in einer Vielzahl von Köpfen verankert werden, um die Mitarbeiter anzuregen, nicht nur über Prozessverbes-serungen, sondern auch über Verbesserungen in den anderen Enablern nachzudenken, so müssen sie natürlich geschult werden. Für eine erste COBIT-5-Einführung reicht oft das in der Tabelle dargestellte minimale Schulungsmodell, in dem sehr wenige Personen geschult werden. Bei Erfolg können die Schulungen auf weitere Personenkreise ausgeweitet werden.

Natürlich sollte COBIT 5 nicht als Herrschaftswissen be-trachtet werden. Dass man nach COBIT 5 arbeitet, sollte be-kannt gemacht und zumindest freiwillige Schulungen für alle Mitarbeiter angeboten werden.

Mythos 3: COBIT 5 ist ein Rahmenwerk von und für Prüfer.

Wer glaubt, dass die COBIT-5-Prozesse weltfremd sind und gleichzeitig vermutet, dass diese Prozesse direkt operationa-lisiert werden sollen, kommt schnell zu dem Schluss, dass COBIT 5 ein Rahmenwerk von und für Prüfer ist und nicht für operative IT-Abteilungen geeignet sein kann.

Auch wenn Operationalisierbarkeit direkt nicht dazu gehört, so hat der Einsatz von COBIT 5 auch für die IT-Abteilungen einen deutlichen Nutzen. In seiner Kompaktheit und Voll-ständigkeit adressiert COBIT 5 alle Themen der Ausgestal-tung einer modernen IT-Organisation. COBIT 5 ist damit eine gute Basis für Capability-Assessments der IT-Funktion. Diese können entweder intern durch die IT selbst initiiert und durchgeführt werden oder auch extern durch das Unterneh-men veranlasst werden. Dank COBIT 5 können IT-interne Assessments proaktiv und in Struktur und Sprache der Prüfer geschehen, bevor die entsprechenden Anmerkungen in den Prüfberichten erscheinen.

Man wird so in die Lage versetzt, anzugeben, wie und mit welchem Reifegrad die Anforderungen an die IT umgesetzt sind. Wenn festgestellt wird, dass bestimmte Anforderungen in der eigenen IT nicht umgesetzt werden, dann muss natür-

lich entschieden werden, wie mit diesen Lücken umgegangen wird. Aber die IT-Abteilung erhält diese Information direkt und selbst und nicht erst aus dem Prüfbericht und kann so frühzeitig reagieren. Übrigens ist auch die Entscheidung, be-stimmte Anforderungen nicht oder noch nicht umzusetzen, legitim, solange sie bewusst, fundiert, risikobewusst und do-kumentiert erfolgt.

Mythos 4: COBIT 5 einzuführen ist nur etwas für große Unternehmen.

Warum sollte das so sein? Die Anforderungen an die IT-Pro-zesse sind bei einem kleinen Unternehmen nicht prinzipiell anders als bei einem großen. In kleineren Unternehmen wer-den zwar unter Umständen nicht alle Prozesse ausgestaltet oder sie werden in Personalunion von wenigen Personen aus-geführt, aber prinzipiell machen die IT-Abteilungen kleiner Unternehmen nichts anderes als die großer Unternehmen. Es kann sich deshalb auch für diese Unternehmen lohnen, die COBIT-5-Anforderungen an die Prozesse zu kennen – und sei es nur, um bewusst zu entscheiden, was man alles nicht oder nur eingeschränkt macht. Gerade in kleineren Unternehmen sind oft nicht die Spezialisten in allen IT-Disziplinen vorhan-den, sodass COBIT 5 auch gute Hinweise geben kann, wo Prozesse verbessert oder Know-how aufgebaut werden sollte.

Mythos 5: Wer COBIT 5 in der IT eingeführt hat, hat auch eine effektive IT-Governance.

Dies sollte eigentlich kein Mythos sein. Ist es aber, leider, denn diesen Automatismus gibt es nicht. Um dies zu erläutern, müssen wir über das Prozessmodell von COBIT 5 hinaus-schauen. COBIT 5 betrachtet mit seinem Enabler-Modell die Governance (und auch das Management) aus allen Perspek-tiven, die nötig sind, sie effektiv zu gestalten. Vollumfänglich eingesetzt, kann das wirklich zu einer etablierten und funk-tionsfähigen Governance führen. Leider gibt es ein nicht un-beträchtliches »Aber«: COBIT 5 legt sehr deutlich dar, dass zu einer funktionsfähigen Governance nicht nur Prozesse ge-hören, sondern beispielsweise auch kulturelle und ethische Aspekte, Mitarbeiterfähigkeiten und Kompetenzen, Prinzipi-en und Richtlinien. Zudem existiert die IT im Unternehmen nicht alleine, sondern ist abhängig von der Geschäftsseite. COBIT 5 adressiert dies mit seinem Prinzip »Abdeckung des gesamten Unternehmens«. Die IT kann zwar hervorragende auf COBIT 5 basierende Prozesse, Mitarbeiter und Gremien etablieren, wenn das Unternehmen jedoch nicht entsprechend organisiert ist, wird hier keine Qualität erreicht. Prozesse ar-beiten nach dem GIGO-Prinzip: »Garbage In, Garbage Out«. Wird beispielsweise keine Unternehmensstrategie formuliert, so kann auch eine IT-Strategie nicht strukturiert abgeleitet, sondern in vielen Teilen – zwar in einem perfekt organisierten Prozess, aber dennoch – nur geraten werden.

24 5 Mythen über COBIT 5

IT-Governance 24 | September 2016

detailliert und mit eigenen Mitteln und im Vorfeld auf Prü-fungen vorbereiten zu können – und das in der Sprache, die auch von den Prüfern gesprochen wird. Anmerkungen kön-nen so bereits im Voraus verhindert werden, sofern der Wille da ist, die identifizierten Lücken zu schließen (oder man sich bewusst dazu entscheidet, sie offen zu lassen). Übrigens: Im Rahmen ihrer rechtlichen Einschränkungen können, dürfen und soll(t)en Revisionsabteilungen auch im Vorfeld bereits wertvolle Hilfestellung geben (»Wenn ich das jetzt prüfen würde, würde ich folgende Anmerkungen haben«).

1 Literatur

[ISACA 2012a] ISACA: COBIT 5: A Business Framework for the Governance and Management of Enterprise IT. ISACA, 2012.

[ISACA 2012b] ISACA: COBIT 5: Enabling Processes. ISACA, 2012, deutsche Übersetzung.

Dipl.-Math. Martin Ehrlichcobit@syracom.de

Um eine effektive Governance der IT zu etablieren, muss da-her außerhalb der IT angefangen werden. Es müssen ZZ eine entsprechende Kultur im Unternehmen etabliert, ZZ die Stakeholder außerhalb der IT identifiziert und mit

einbezogen, ZZ das klare Bekenntnis des Topmanagements eingeholt, ZZ die benötigten Mitarbeiter und Fähigkeiten aufgebaut,ZZ Entscheidungsmodelle etabliert und ZZ noch viele weitere Dinge adressiert werden,

bevor die Governance effektiv ist. COBIT 5 gibt über sein Enabler-Modell viele Hinweise und kann so eine große Un-terstützung dabei bieten, ändert aber nichts an der Tatsache, dass lebende Strukturen auch von lebenden Menschen mit lebenden Inhalten erfüllt werden müssen.

Was bleibt nach der Betrachtung dieser 5 Mythen? Ist der Einsatz von COBIT 5 anzuraten? Sehen wir uns zunächst die Haben-Seite an:

ZZ Anforderungskatalog für die gesamte IT ZZ Beschriebene Best Practices, helfen die eigenen Prozesse

zu verbessernZZ Vergleichsweise niedriger SchulungsaufwandZZ Proaktives Auffinden von Prozesslücken wird ermöglichtZZ Keine Anpassung bereits etablierter Strukturen, nur um

dem Rahmenwerk zu genügenZZ Einfachere Kommunikation mit PrüfernZZ Nutzbar in allen UnternehmensgrößenZZ Das Enabler-Modell hilft, Verbesserungspotenzial auch

weit außerhalb des Prozessmodells zu identifizieren

Dagegen können nur wenige Aspekte auf die Soll-Seite ge-stellt werden:

ZZ Wenige detaillierte Hinweise zur effizienten Umsetzung. Dazu gibt es aber die spezialisierten Rahmenwerke wie ITIL, PRINCE2 oder TOGAF.

ZZ Ein weiteres Rahmenwerk im Unternehmen

Zusammenfassend können wir sagen, dass der Einsatz von COBIT 5 für alle Unternehmen bzw. deren IT prinzipiell an-zuraten ist. Ausnahmen sind allenfalls Organisationen, die bereits nachgewiesenermaßen einen hohen Reifegrad haben. Aber auch diesen kann ein gelegentlicher Blick in COBIT 5 nicht schaden. IT-Abteilungen, die ihren eigenen Reifegrad erhöhen wollen oder müssen, können aus COBIT 5 erhebli-che Hilfestellungen erhalten, dürfen aber natürlich die spezi-alisierten Rahmenwerke wie ITIL oder TOGAF nicht außer Acht lassen.

In Unternehmen, in denen interne Revision oder Wirtschafts-prüfer nach COBIT 5 arbeiten, sollte sich die IT intensiv mit COBIT 5 auseinandersetzen. Die IT-Abteilungen haben es selbst in der Hand, ob sie sich von Prüfungsanmerkungen wie »Ihr habt BAI06 nicht vollständig umgesetzt« überraschen lassen. Mit COBIT 5 haben sie die einmalige Chance, sich