VERSION 1.2: OHNE HWZ-INTERNALS, OHNE INTERVIEWS. INHALTLICH UNVERÄNDERT. Voraussetzungen für die Audit-Fähigkeit bei HERMES 5-Projekten (Basierend auf COBIT) Masterarbeit Zürcher Fachhochschule HWZ Hochschule für Wirtschaft Zürich eingereicht bei: Prof. Dr. Walter Kuhn Dozent HWZ vorgelegt von: Jürg Briner MAS-Studiengang: Master of Advanced Studies in Project Management Adresse: Sunnehofweg 5 8605 Gutenswil .................................................................................................... Gutenswil, 26. Februar 2012
110
Embed
Voraussetzungen für die Audit-Fähigkeit bei HERMES 5 ... · MEA Monitor, Evaluate, Assess (COBIT 5) MEI Monitor, Evaluate, Inform (COBIT 5) ML Maturity Level NASDAQ National Association
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
VERSION 1.2: OHNE HWZ-INTERNALS, OHNE INTERVIEWS.
INHALTLICH UNVERÄNDERT.
Voraussetzungen für die Audit-Fähigkeit bei HERMES 5-Projekten (Basierend auf COBIT)
Masterarbeit
Zürcher Fachhochschule
HWZ Hochschule für Wirtschaft Zürich
eingereicht bei:
Prof. Dr. Walter Kuhn Dozent HWZ
vorgelegt von: Jürg Briner MAS-Studiengang: Master of Advanced Studies in Project Management Adresse: Sunnehofweg 5
Risk IT Framework for Management of IT Related Business Risks
RLCG Richtlinie betreffend Informationen zur Corporate Governance
RSKM Risiko Management
SA System Adaption
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
10 / 110
SAP Systeme Anwendungen Produkte
SAQ Verein Swiss Association for Quality
SE System Entwicklung
SEC Securities and Exchange Commission
SEI Software Engineering Institute
Six Sigma Standardabweichung, Methode im Qualitätsmanagment
SOX Sarbanes-Oxley Act
SPC Statistical Process Control
SPICE Software Process Improvement and Capability Determination
UN United Nations
VAL IT Framework for Business Technology Management
VDMA Verband Deutscher Maschinen- und Anlagebau e.V
VZPM Verein zur Zertifizierung von Personen im Management
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
11 / 110
1 EINFÜHRUNG IN DAS GEBIET
1.1 Ausgangslage
HERMES ist eine Projektführungsmethode, die vom Bund für sich selbst entwickelt wurde.
Informatikprojekte in der Bundesverwaltung müssen mit dieser Methodik abgewickelt
werden1. HERMES ist ein offener Standard und darf frei benutzt werden.
Die aktuelle Version 2003/2005 von HERMES wurde vor acht respektive fünf Jahren
herausgegeben. Bis heute wurden noch einige Erweiterungen hinzugefügt, es wurde aber
keine grundsätzlich neue Version erstellt.
Der Bund ist an der Weiterentwicklung der beiden Versionen und zugehörigen
Erweiterungen zur neuen Version HERMES 5. Die Leitung hat das
Informatiksteuerungsorgan des Bundes ISB2.
HERMES 5 soll u.a. zu COBIT konform sein. Das heisst, man will, dass die Projekte auch
nach den Grundsätzen der IT-Governance abgewickelt werden und hat als Referenz dafür
COBIT gewählt.
1.2 Problemanalyse
Projekte sind von Natur aus „im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer
Gesamtheit gekennzeichnet“3 und weisen nicht immer alle Elemente einer IT-Organisation
aus. COBIT wendet sich an die IT und deren Prozesse von Unternehmungen. Projekte sind
nur ein Teil einer Unternehmung und umfassen nicht immer die Gesamtheit aller Prozesse.
Wie soll man ein auf IT-Prozesse geschneidertes Framework auf Projekte abbilden? Genügt
es, die in den Projekten berücksichtigten Prozesse und Kontrollziele anzuschauen? Muss
man für ein Projektaudit nach COBIT das Audit der Unternehmung respektive des IT-
Bereiches voraussetzen?
Es stellt sich auch die Frage, was man in einem „einzigartigen“ Projekt auditieren kann, um
der Governance Genüge zu tun. Kann man überhaupt für Vorhaben, die immer wieder
andersartig sind, festlegen, ob der IT-Governance Genüge getan wurde? Etwa im Sinne
einer Checkliste? Oder muss man sich mit generellen Ansätzen zufrieden geben, nach
denen man die Projekte speziell untersuchen muss, um zu einem Ergebnis zu kommen?
1 P007 – Richtlinien für Projektführung in Informatikprojekten, Version 2.03 vom 26.08.2011, Informatikrat Bund
(IRB), vertreten durch das ISB, genehmigt am 14.09.2004, Seite 5 2 http://www.isb.admin.ch/themen/methoden/00793/index.html?lang=de, letzter Zugriff: 28.Januar 2012 3 DIN 69901-5:2009-01, Projektmanagement - Projektmanagementsysteme - Teil 5: Begriffe, Seite 11
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
12 / 110
2 ZIELSETZUNG
Das Ziel dieser Arbeit ist
für HERMES 5 die Frage der Auditierbarkeit nach dem Standard COBIT zu
beantworten.
Lösungsansätze aufzuzeigen, wie die minimalen Ergebnisse, Rollen und
Vorgehen aussehen müssen, um ein Audit über die Governance nach COBIT
erfolgreich zu erfüllen.
als Grundlage für ein Whitepaper „COBIT vs HERMES“ bei der ISACA zu
dienen.
mitzuhelfen, dass in Projekten die Grundlagen für ein erfolgreiches Bestehen
eines Audit während dem Projekt erarbeitet werden.
durch Erarbeiten der für ein Audit geforderten Ergebnisse, die (IT-)
Governance in einem Projekt auch ohne Audit zu verbessern.
2.1 Inhaltliche Abgrenzung
Es ist nicht der Sinn dieser Arbeit
festzulegen, ob COBIT der richtige Massstab ist, um die IT-Governance für
Projekte zu erfüllen. COBIT gilt als gesetzt.
das Wann, Wie und Wo eines Audit zu definieren4. Es ist Aufgabe des
Managements dies festzulegen.
zu verhindern, dass Projekte scheitern oder abgebrochen werden, indem
bestimmte Ergebnisse festgelegt sind.
Abgrenzungen:
Diese Arbeit wird für HERMES 5 erstellt und als Vergleich wird COBIT 5
verwendet. Sowohl HERMES als auch COBIT sind noch in Entwicklung. Für
HERMES 5 ist die Einführung auf 2Q 2013 geplant5. Die Freigabe von COBIT
5 soll 2012 erfolgen6.
4 vgl. Andreas Kühn, Konrad Walser, Reinhard Riedl (2008), Auditing Projects in e-Goverment based on IT
Governance Methods, Competence Centre Public Management and E-Government Berne University of Applied Sciences, Seite 3
5 vgl. http://www.ehermes.ch/ueber-hermes/projekt-hermes-weiterentwicklung/vorgehen, letzter Zugriff: 06. Januar 2012
6 vgl. http://www.isaca.org/Knowledge-Center/cobit/Pages/COBIT-5-Initiative-Status-Update.aspx, letzter Zugriff: 22. Februar 2012
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
13 / 110
Werden für diese Arbeit weitere Beispiele benötigt, werden diese, wenn nicht
in den Entwürfen vorhanden, aus den jeweils älteren, d.h. den gültigen und
publizierten Versionen von HERMES und COBIT verwendet.
Andere Themen werden nicht behandelt, obwohl man diese auch als Teil der
Governance betrachten könnte, so wie z.B. Risk Management.
2.2 Machbarkeit
Es wird gerade durch diese Arbeit geprüft, ob und wie man Projekte einem Standard-
Framework zur Auditierung unterwerfen kann.
Als Hypothese gilt:
Aufgrund von definierten Inhalten und Ergebnissen bei Projekten kann man die IT-
Governance erfüllen und somit, weil HERMES bei Verwaltungen angewendet wird, dem
Auftraggeber und schlussendlich dem Steuerzahler Rechenschaft ablegen, dass man
gewissenhaft und verantwortungsvoll gearbeitet hat.
Publizierte Mappings
Grundsätzlich sollte das Mapping „COBIT zu HERMES“ möglich sein, gibt es doch bereits
einige Hinweise und Arbeiten, die darauf hinzielen7. Diese Empfehlungen der
Schweizerischen Finanzkontrollen beziehen sich jedoch auf die ausgewählten
Schlüsseldokumente und sind somit nicht vollständig. Ebenfalls kann daraus nicht abgelesen
werden, welche konkreten Ergebnisse von HERMES gemeint sind. Das IT Governance
Institut ITGI hat bereits verschiedene Mappings8 mit Projekt-Managementmethoden oder
ähnlichen Praktiken publiziert:
Mapping of PMBOK® with Cobit® 4.0,
IT Governance Institute ITGI, ISBN: 1-933284-48-X
Mapping of PRINCE2™ with Cobit® 4.0,
IT Governance Institute ITGI, ISBN: 1-933284-48-X
Mapping of CMMI® for Development V1.2 with COBIT 4.0,
IT Governance Institute ITGI, ISBN: 1-933284-80-3
Das lässt darauf schliessen, dass auch HERMES mit COBIT gemapped werden kann.
7 vgl. Arbeitsgruppe IT Government Audit, Empfehlungen der Schweizerischen Finanzkontrollen für
Informatikprojekte, V.2.0, http://www.efk.admin.ch/images/stories/efk_dokumente/publikationen/fachtexte/NOVENA_V.2.0_d.pdf, letzter Zugriff: 17. Februar 2012
8 http://www.isaca.org/Knowledge-Center/Research/Pages/All-Deliverables.aspx, letzter Zugriff: 17. Februar 2012
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
14 / 110
3 METHODISCHE VORGEHENSWEISE
Grundlagen schaffen (Kapitel 4)
Zuerst müssen Begrifflichkeiten u.a. wie „Audit“, „Governance“, „Controlling“ und weitere
verwandte oder betroffene Themen geklärt werden. Ebenso müssen die Grundlagen für die
HERMES-Projektführungsmethodik und das COBIT Governance-Framework geschaffen
werden.
Marschrichtung ermitteln (Kapitel 5)
Die Marschrichtung festlegen bedeutet, die Anforderungen der Stakeholder (HERMES, EFK,
Bund, COBIT) herauszufiltern. Weiter muss untersucht werden, ob COBIT weitere
Anforderungen an die Governance oder an ein Audit stellt.
Überprüfung der Aufgabe (Kapitel 6)
Kann das funktionieren? Wird die Marschrichtung auf Basis der Grundlagen ins Ziel führen?
Eine kritische Auseinandersetzung der Grundlagen mit der Zielsetzung.
Kernaussagen erarbeiten (Kapitel 7)
Definierung der Voraussetzungen für die Audit-Fähigkeit von HERMES 5. Die in COBIT
definierten Vorgaben müssen erfüllt sein. Das bedeutet nichts anderes, als dass
Anforderungen an HERMES 5 aufgezeigt werden: Was muss HERMES 5 erfüllen, damit ein
Audit nach COBIT erfolgreich ist.
Fazit (Kapitel 8)
Das Fazit der Aufgabenstellung und Empfehlungen für die Umsetzung bilden den Abschluss
dieser Arbeit.
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
15 / 110
4 GRUNDLAGEN
4.1 Governance
Was ist Governance? Der Begriff „Governance“ wird vielseitig definiert und umschrieben.
Nach dem Brockhaus9 wird Governance als „Herrschaft“ oder „Regierungsgewalt“ in die
deutsche Sprache übersetzt. Als Erklärung wird weiter ausgeführt „Vieldeutiger
sozialwissenschaftlicher Begriff, der dem Gebiet der Wirtschaft entstammt (Corporate
Governance), wo er die Rahmenbedingungen und Grundsätze der
Unternehmensorganisation als Voraussetzungen effizienten Handelns von Unternehmen
umschreibt“.
Nach Wikipedia10 stammt Governance vom französischen „gouverner“ ab und bedeutet
„verwalten, leiten, erziehen“. Weiter wird es als „Regierungs-, Amts- bzw.
Unternehmensführung“ bezeichnet.
Nach Gabler11 wird Governance als „Regierungshandeln im weitesten Sinn“ erklärt und es
wird auf die Ausdrücke „Good Governance“ und „Global Governance“ verwiesen.
In den HERMES 5 Anforderungen12 wird Governance als „verantwortungsvolle Führung und
Kontrolle“ definiert.
Nach Willi13 ist Governance vom lat. „gubernator“ abgeleitet welches wiederum auf das
griechische „kybernetes“ zurückgeht und mit „Steuermann“ übersetzbar ist.
Benz14 hat den Begriff in englischen Wörterbüchern mit der Bedeutung „the act or manner of
governing“ und „the office function of governing“ nachgeschlagen und führt dann weiter aus:
„Diese Erläuterungen helfen uns zunächst insofern weiter, als sie erkennen lassen, dass
Governance nicht bloss die Tätigkeit des Regierens, Lenkes bzw. Steuerns und
Koordinierens meint, sondern auf die Art und Weise dieser Tätigkeit verweist, die
Wissenmedia, https://10920.lip.e-content.duden-business.com/lip-suche/-/lip_article/B15/600087071, letzter Zugriff: 13. Januar 2012
10 http://de.wikipedia.org/wiki/Governance, letzter Zugriff 22. Februar 2012 11 Gabler Verlag (Herausgeber), Gabler Wirtschaftslexikon, Stichwort: Governance, online im Internet:
http://wirtschaftslexikon.gabler.de/Archiv/131618/governance-v3.html, letzter Zugriff: 22. Februar 2012 12 Bernhard Kruschitz (2011), Governance mit HERMES 5, Version 0.7 vom 09.12.2011,
Informatikstrategieorgan Bund ISB, Seite 7 13 vgl. Böckli Peter, Schweizer Aktienrecht, 3. Auflage, zitiert nach: Annette Willi (2008), IT-Governance als
Aufgabe des Verwaltungsungsrates, Schulthess Juristische Medien AG, Zürich, Basel, Genf, Seiten 10-11 14 Arthur Benz, Nicolai Dose (2010) in Governance – Regieren in komplexen Regelsystemen, 2. aktualisierte und
überarbeitete Auflage 2010, Herausgeber: Arthur Benz, Susanne Lütz, Uwe Schimak, Georg Simonis, VS Verlag für Sozialwissenschaften, Springer Fachmedien Wiesbaden GmbH 2010, Kapitel 1: Governance – Modebegriff oder nützliches sozialwissenschaftliches Konzept, Seite 17
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
16 / 110
verschieden ausfallen kann“. Weiter ist Benz nicht erstaunt, „dass der Begriff Governance je
nach Erkenntnisinteresse verschiedene Bedeutungen erhält“.
Es scheint, dass der Begriff „Governance“ nicht eindeutig definiert ist respektive nicht
eindeutig interpretiert wird. Einheitlich ist in der Literatur aber festzustellen, dass es um die
Führung, Steuerung und Kontrolle von Unternehmen oder Staaten geht und weiter auch wie
diese Tätigkeiten („verantwortungsvoll“) auszuüben sind.
Weiter wird der Begriff Governance spezifisch verwendet in „Good Governance“, „Corporate
Governance“, „IT-Governance“ oder „Project Governance“. Diese weiteren Begriffe werden
im Folgenden erklärt.
4.1.1 Good Governance
Auch der Begriff „Good Governance“ wird vielseitig verwendet und umschrieben. Nach
Gabler15 wird „Good Governance“ als „die effiziente Gestaltung der öffentlichen Verwaltung
und die Einbeziehung wichtiger gesellschaftlicher Gruppen und Minderheiten in die
demokratische Entscheidungsfindung“ verstanden. Mit Effizient ist da wirksam oder
wirtschaftlich gemeint.
Gemäss dem Brockhaus16 wurde dieser Begriff von der Weltbank erfunden und meint:
„Kriterien einer effizienten und rechtsstaatlichen Verwaltungspraxis für die Vergabe von
Krediten an Entwicklungs- und Transformationsländern“.
Wie bei Brockhaus ist der Begriff „Good Governance“ auch nach Theobald17 durch die
Weltbank kreiert worden. Allerdings ging es zuerst um „Bad“ Governance im Zusammenhang
mit Entwicklungsprojekten in Drittwelt-Staaten. Erst danach wurde der Begriff „Good
Governance“ geschaffen.
Auch nach Czada18 geht der Begriff „Good-Governance“ auf die Weltbank zurück, „gilt die
1989 veröffentlichte Afrikastudie der Weltbank als Ausgangspunkt einer
15 vgl. Gabler Verlag (Herausgeber), Gabler Wirtschaftslexikon, Stichwort: Good Governance, online im Internet:
http://wirtschaftslexikon.gabler.de/Archiv/127685/good-governance-v3.html; letzter Zugriff: 22. Februar 2012 16 vgl. Brockhaus - Die Enzyklopädie in 30 Bänden. 21., neu bearbeitete Auflage. Leipzig, Mannheim: F. A.
17 vgl. Christian Theobald (2000), Zur Ökonomik des Staates, Good Governance und die Perzeption der Weltbank, Nomos Verlagsgesellschaft Baden-Baden 2000, Seiten 83-84
18 Roland Czada (2010) in Governance – Regieren in komplexen Regelsystemen, 2. aktualisierte und überarbeitete Auflage 2010, Herausgeber: Arthur Benz, Susanne Lütz, Uwe Schimak, Georg Simonis, VS Verlag für Sozialwissenschaften, Springer Fachmedien Wiesbaden GmbH 2010, Kapitel 10: Good Governance als Leitkonzept für Regierungshandeln: Grundlagen, Anwendungen, Kritik, Seite 201
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
17 / 110
entwicklungspolitischen Good Governance-Debatte“. Die Afrikastudie19 kommt zur
Erkenntnis, „dass Wirtschaftshilfen ihren Zweck verfehlen, wenn sie nicht im Rahmen gut
funktionierender öffentlicher Institutionen administriert und kontrolliert werden“. Czada führt
weiter aus, dass dies zur Entwicklung des „Guten Regierens“ geführt hat.
Nach Wikipedia20 ist die „Good Governance“ ein „gutes Steuerungs- und Regelungssystem
einer politisch-gesellschaftlichen Einheit“ und bringt den Begriff auch mit der Vergabe von
Geldern in Zusammenhang, wie „mit der guten Haushalts- bzw. Budget-Mittel-
Bewirtschaftung“.
In Willi21 wird mit „Good Governance“ die „verantwortungsbewusste Regierungsführung“
umschrieben.
Weil mehrere Quellen die Begrifflichkeit auf die Weltbank zurückführen, lässt sich die
Tendenz feststellen, dass „Good Governance“ im Sinne von „gutem“ Regieren verstanden
werden kann. Gut im Sinne von „rechtmässig“ und „unabhängig“. Und es muss nicht
zwangsläufig in einem Entwicklungsland angewendet werden.
4.1.2 Global Governance
Die „Global Governance“ ist nach Gabler22 „das gesamte System aller internationalen
Institutionen sowie die Regeln, nach denen sie arbeiten und wie sie mit nationalen
Institutionen interagieren“. Für Brand23 ist erstens der Begriff allmählich nur noch ein
Schlagwort und wird zweitens auch mit „Weltordnungspolitik“ oder „Globale Ordnungspolitik“
bezeichnet respektive gar nicht übersetzt.
Für Beisheim24 wird der Begriff mit „globalem Regieren“ („ohne Weltregierung“) oder auch als
„globale Steuerung“ behandelt.
Mit dem Buch25 „Wer regiert die Welt und mit welchem Recht? Beiträge zur Global
Governance-Forschung““ untersuchen verschiedene Autoren die „Global Governance“. Allein
dieser Ansatz zeigt, dass der Begriff noch keine allgemeinverbindliche Bedeutung hat. 19 World Bank, 1989, Sub-Sahara Africa, From Crisis to sustainable Growth, Washington (DC), zitiert nach:
Roland Czada (2010) in Governance – Regieren in komplexen Regelsystemen, 2. aktualisierte und überarbeitete Auflage 2010, Herausgeber: Arthur Benz, Susanne Lütz, Uwe Schimak, Georg Simonis, VS Verlag für Sozialwissenschaften, Springer Fachmedien Wiesbaden GmbH 2010, Kapitel 10: Good Governance als Leitkonzept für Regierungshandeln: Grundlagen, Anwendungen, Kritik, Seite 201
20 http://de.wikipedia.org/wiki/Good_Governance, letzter Zugriff: 22. Februar 2012 21 Annette Willi (2008), IT-Governance als Aufgabe des Verwaltungsrates, Schulthess Juristische Medien AG,
Zürich, Basel, Genf, Seite 11 22 Gabler Verlag (Herausgeber), Gabler Wirtschaftslexikon, Stichwort: Global Governance, online im Internet:
http://wirtschaftslexikon.gabler.de/Archiv/55791/global-governance-v3.html, letzter Zugriff: 22. Februar 2012 23 vgl. Ulrich Brand et al. Global Governance, Alternative zur neoliberalen Globalisierung, 1. Auflage Münster
2000, Verlag Westfälisches Dampfboot, Münster, Seiten 13-21 24 vgl. Marianne Beisheim (2004), Fit für Global Governance, Leske + Budrich, Opladen 2004, Seiten 25, 42
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
18 / 110
Auch Behrens26 (2007) hat den Begriff untersucht: „Global Governance ist ein komplexes,
wenig spezifiziertes Konzept, das (…) seit Mitte der 1990er Jahre geradezu inflationär
verwendet wird“ und erläutert, dass Global Governance als Konzept in die Internationale
Politik fällt. 201027 zitiert Behrens die UN-Kommission „Commission on Global Governance
CGG“ die den Begriff Global Governance als „Gesamtheit der zahlreichen Wege, auf denen
Individuen sowie öffentliche und private Institutionen ihre gemeinsamen Angelegenheiten
regeln“.
Aus diesen Nachforschungen lässt sich der Zusammenhang mit dem globalen Denken und
Lenken innerhalb der internationalen Politik nachvollziehen, auch wenn schlussendlich
Global Governance nicht in einem Satz erklärt werden kann.
4.1.3 Corporate Governance
Bei „Corporate Governance“ handelt es sich gemäss Gabler28 um „den rechtlichen und
faktischen Ordnungsrahmen für die Leitung und Überwachung eines Unternehmens“. Aber
auch diese kann natürlich noch besser oder schlechter umgesetzt werden. In Willi38 wird
„Corporate Governance“ mit „angemessene Unternehmensführung“ umschrieben.
Im Swiss Code29, den Empfehlungen von Economiesuisse, wird Corporate Governance als
„die Gesamtheit, der auf das Aktionärsinteresse ausgerichteten Grundsätze, die unter
Wahrung von Entscheidungsfähigkeit und Effizienz auf der obersten Unternehmensebene
Transparenz und ein ausgewogenes Verhältnis von Führung und Kontrolle anstreben“
definiert.
Corporate Governance ist in der Schweiz mit Bezug auf börsenkotierte Unternehmen klar
definiert. Die „Corporate Governance Richtlinie“ RLCG30 ist gültig für alle an der Schweizer
25 vgl. Wer regiert die Welt und mit welchem Recht? (2009), Beiträge zur Global Goverance-Forschung,
Herausgeber Volker Rittberger, Theodor Eschenburg Vorlesungen, Band 4, Nomos Verlagsgesellschaft, Baden-Baden
26 vgl. Maria Behrens, Alexander Reichlin (2007) in Handbuch Governance, Herausgeber: Arthur Benz, Susanne Lütz, Uew Schimanek, Georg Simonis, 1. Auflage Juni 2007, VS Verlag für Sozialwissenschaften, Springer Fachmedien Wiesbaden GmbH 2007, Kapite 3.4. Global Governance, Seite 311
27 CGG, 1995, Our global Neighbourhood, zitiert nach: Maria Behrens (2010), Governance – Regieren in komplexen Regelsystemen, 2. aktualisierte und überarbeitete Auflage 2010, Herausgeber: Arthur Benz, Susanne Lütz, Uwe Schimak, Georg Simonis, VS Verlag für Sozialwissenschaften, Springer Fachmedien Wiesbaden GmbH 2010, Kapitel 5, Global Governance, Seite 93
29 Economiesuisse (2007), swiss code of best practice for corporate governance, economiesuisse, Verband der Schweizer Unternehmen, Spitalgasse 4, Postfach, CH-3001 Bern, http://www.economiesuisse.ch/de/PDF%20Download%20Files/pospap_swiss-code_corp-govern_20080221_de.pdf, letzter Zugriff, 15. Januar 2012
30 http://www.six-exchange-regulation.com/admission_manual/06_15-DCG/de/index.html, letzter Zugriff: 22. Februar 2012
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
19 / 110
Börse kotierten Unternehmen mit Sitz in der Schweiz. Diese Richtlinien wurden erstellt, um
dem Gesetzesgeber31 Genüge zu tun. Sie beinhaltet klare Anweisungen bezüglich
Besitztum, Führungs- und Kontrollorganen und vieles mehr.
Gemäss dem Betreiber der Börse, der SIX Group AG32, bedeutet Corporate Governance „die
Gesamtheit der auf das Aktionärsinteresse ausgerichteten Grundsätze, die unter Wahrung
von Entscheidungsfähigkeit und Effizienz auf der obersten Unternehmensebene
Transparenz und ein ausgewogenes Verhältnis von Führung und Kontrolle anstreben“.
Daraus folgt, dass in einem Geschäftsbericht wie z.B. bei Tamedia33 die Besitzverhältnisse
im Detail aufgeführt sind wie auch Ihre gesamten Führungs- und Kontroll-Instanzen. Gemäss
der Basler Kantonalbank34 bedeutet „Corporate Governance“ „die Regeln und Grundsätze
von Organisation, Verhalten und Transparenz, durch die ein Unternehmen geleitet und
kontrolliert wird“.
Mit Blick auf die Corporate Governance wurde 2002 in den Vereinigten Staaten von Amerika
der Sarbanes-Oxley Act SOX35 ratifiziert. Dieser soll die Verpflichtungen der
Unternehmensführung und ihrer Überwachungsinstitutionen konkretisieren und die Haftung
ausweiten36. Gleichzeitig erliessen die Börsen NYSE und NASDAQ die „Corporate
Governance Proposal“ für die gelisteten Unternehmen. Damit wurde auf die „Non-
Governance“ der Unternehmungen rund um die dot-com-Blase reagiert.
Die Bedeutung des Begriffs „Corporate Governance“ wird also in der Wirtschaft einerseits
frei definiert, andererseits aber im Zusammenhang mit der Schweizerbörse und anderen
Börsen durch Vorschriften exakt vorgeben.
Corporate Governance kann zusammenfassend als Führungs- und Kontrollvorgabe
betrachtet werden, die durch das Management angewendet werden muss.
31 vgl. Bundesgesetz über die Börsen und den Effektenhandel (Börsengesetz, BEHG), SR 954.1 vom 24. März
1995 (Stand am 1. September 2011), http://www.admin.ch/ch/d/sr/9/954.1.de.pdf, letzter Zugriff: 22. Februar 2012
32 http://www.six-exchange-regulation.com/obligations/governance_de.html, letzter Zugriff: 22. Februar 2012 33 vgl. http://www.tamedia.ch/de/investorRelations/Documents/Corporate%20Governance%20GB%202010.pdf,
letzter Zugriff: 22. Februar 2012 34 http://www.bkb.ch/index/ihrebkb/corporate-governance-neu.htm, letzter Zugriff: 22. Februar 2012 35 http://thomas.loc.gov/cgi-bin/bdquery/z?d107:H.R.3763:, letzter Zugriff: 10. Februar 2012 36 vgl. Karsten Paetzman (2008), Corporate Governance, Springer Verlag Berlin Heiderlberg, 2008, Seite 31
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
20 / 110
4.1.4 IT-Governance
Dass für die IT Governance speziell betrachtet werden muss, stellt Johannsen37 fest, weil die
IT-Governance sowohl durch die IT-Strategie bestimmt ist, als auch von der Corporate
Governance respektive von der Unternehmensstrategie abhängt. Ebenso leiten sich die IT-
Prozesse aus den Geschäftsprozesse ab.
Nach Willi38 kann die IT-Governance wie folgt charakterisiert werden „IT-Governance
umfasst die Festlegung der Entscheidungsbefugnisse und Verantwortlichkeiten der
Leitungsorgane mit Bezug auf das Vorgehen zur Erreichung einer an die Anforderungen des
Unternehmens angepassten Ausgestaltung der IT“.
Das IT-Governance Institut ITGI39 wiederum definiert IT-Governance so:
IT Governance besteht aus Führung, Organisationsstrukturen und Prozessen, die
sicherstellen, dass die IT die Unternehmensstrategie und die Unternehmensziele unterstützt.
Nach Gaulke40 ist die Zielsetzung der IT-Governance einerseits einen „Wertbeitrag“ für das
Unternehmen zu liefern und andererseits die Risiken auf ein vertretbares Niveau zu
reduzieren.
Im HMD-Glossar41 versteht man unter IT-Governance „Grundsätze, Verfahren,
Massnahmen, welche möglichst effizient zur Unterstützung und Durchsetzung der
Unternehmensstrategien und -ziele beitragen sollen.“
Nach Kamleiter42 stellt die IT-Governance ein integraler Bestandteil der Corporate
Governance dar, da diese Richtlinien und Ziele definiert, welche an den IT-Bedürfnissen des
Unternehmens ausgerichtet sind.
Goltsche43 definiert wie folgt: „IT-Governance ist eine Struktur von Beziehungen und
Prozessen zur Steuerung und Führung eines IT-Unternehmens oder IT Bereiches, um die
37 vgl. Wolfgang Johannsen, Matthias Goeken (2007), Referenzmodell für IT-Governance, 1. Auflage,
dpunkt.verlag GmbH, Seite 20-21 38 Annette Willi (2008), IT-Governance als Aufgabe des Verwaltungsungsrates, Schulthess Juristische Medien
AG, Zürich, Basel, Genf, Seite 15 39 IT-Governance für Geschäftsführer und Vorstände, Zweite Ausgabe (Deutsch),
http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/Board-Briefing-on-IT-Governance-2nd-Edition.aspx, letzter Zugriff: 7. Februar 2012
40 vlg. Markus Gaulke (2006), COBIT als IT-Governance-Leitfaden in Praxis der Wirtschaftsinformatik, Herausgeber: Hans-Peter Fröschle, Susanne Strahringer, HMD Heft 250, August 2006, dpunkt.verlag, Seite 22
41 IT-Governance in Praxis der Wirtschaftsinformatik, Herausgeber: Hans-Peter Fröschle, Susanne Strahringer, HMD Heft 250, August 2006, dpunkt.verlag, HMD-Glossar, Seite 144
42 vgl. Jürgen Kamleiter und Michael Langer (2006), Business IT-Alignment mit ITIL, COBIT, RUP, 1. Auflage 2006, Herausgeber: Michael Kresse, Serview GmbH, Bad Homburg, Seite 42
43 Wolfgang Goltsche (2006), COBIT kompakt und verständlich, 1. Auflage September 2006, Friedr. Vieweg & Sohn Verlag | GWV Fachverlage GmbH, Wiesbaden 2006, Seite 6
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
21 / 110
Geschäftsziele zu erreichen. Der Wertzuwachs wird dabei durch das Ausbalancieren von
Risiko und Ertrag der IT und ihrer Prozesse erreicht.“
Nach Weill und Ross44 bedeutet IT-Governance „the decisions rights and accountability
framework for encouraging desirable behaviors in the use oif IT“.
Rüter45 kommt zu ähnlichen Folgerungen: „(…) deckt die IT-Governance im Wesentlichen die
Prinzipien und Anliegen der Corporate Governance, auf den IT-Bereich angewendet“.
Für Müller46 definiert sich die IT-Governance als „an der Geschäftstätigkeit. der
Unternehmensstrategie und den Unternehmenszielen ausgerichtete, gute und
verantwortliche Leitung der IT“, die sich u.a. an den relevanten gesetzlichen,
aufsichtsbehördlichen und vergleichbaren Vorgaben orientieren soll sowie international und
national anerkannten Normen und Standards zur Leitung, Steuerung und Überwachung der
IT.
Die IT-Governance kann somit als Beschreibung der IT betreffenden Teile eines
Unternehmens angeschaut werden, und diese unterliegen wie das gesamte Unternehmen
dem gleichen verantwortungsvollen Führungs- und Kontrolldenken. Die Literaturhinweise
zusammengefasst geht es darum, dass die IT Governance die Unternehmensziele und -
strategien unterstützt, indem die Prozesse und Aufgaben unter Berücksichtigung von
Effizienz und Risiken entsprechend gut und verantwortungsvoll ausgeführt werden.
Die Wahrung der IT-Governance kann mit verschiedenen Modellen erreicht werden. COBIT,
ITIL oder ISO 2700147 sind nur einige davon. Aufgrund der Vorgaben zu dieser Arbeit
untersuchen wir nur COBIT und verweisen für die anderen Modelle auf die Literatur. COBIT
ist später erklärt.
4.1.5 Project Governance
In Linguee48 wird „Project Governance“ mit „Projektmanagement-Rahmensystem“ übersetzt.
Heisst das, dass auch für Projekte eine eigene Governance zum Zuge kommt? Auch die
44 Peter Weill, Jeanne W. Ross (2004), IT Governance on one Page, MIT Sloan working Paper No 4517-04, CIS
Research Working Paper No: 349, November 2004. http://ssrn.com/abstract=664612, Seite 4; letzter Zugriff: 7. Februar 2012
45 Andreas Rüter (2010) et al., IT-Governance in der Praxis, 2. Auflage, Springer Verlag, Seite 20 46 vgl. Klaus-Rainer Müller (2011), IT-Sicherheit mit System, 4. neu bearbeitete und erweiterte Auflage 2011,
Vieweg + Teubner Verlag, Springer Fachmedien Wiesbaden GmbH 2011, Seite 524 47 ISO/IEC 27001 specifies the requirements for establishing, implementing, operating, monitoring, reviewing,
maintaining and improving a documented Information Security Management System within the context of the organization's overall business risks. http://www.iso.org.
48 http://www.linguee.de/englisch-deutsch/uebersetzung/project+governance.html, letzter Zugriff 22. Februar 2012
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
22 / 110
Firma SPOL49 findet: „Projekte wollen Recht und Ordnung“ und führt weiter aus, dass man
für eine erfolgreiche Investition von Mitteln auch ein „strategieorientiertes Projekt-
Governance-Modell“ benötigt.
Nach der Internationalen Norm ISO 2150050 „Guidance on Projekt Management“ hat auch
die Governance eine Bedeutung, wird aber abgeleitet aus der Corporate Governance:
„Project Governance is concerned with those areas of organizational governance that are
specifically related to project activities“.
Die Project Governance scheint sich also vom Unternehmen über die IT auf die einzelnen
Projekte niederzuschlagen. Nach Renz51 wird auch die firmenweite Governance mit dem
Projekt Management verbunden: „Project Governance represents a meaningful, value-
adding link between project management and (corporate) Governance“.
Weill52 ergänzt hierzu: “A critical Step in implementing IT Governance is to develop the
discipline to track the progress of individual IT Projects”. Aber nicht nur das Tracking nach
einer Standard-Projektmethodik ist wichtig, eine für das eigene Unternehmen entwickelte
Projektmethodik oder Einsetzung eines Capability Maturity Model hilft ebenfalls.
Zusammenfassend kann man unter Project Governance die jeweils für das einzelne Projekt
relevanten Teile der Governance-Aspekte einer Unternehmung respektive Organisation
verstehen. Sind es wie bei Renz51 Grossprojekte von NGOs, gelten die „Global Governance“
Grundsätze, bei IT-Projekten müssen die IT-Governance-Grundsätze angewendet werden.
4.2 Audit / Review / Prüfung
Im Rahmen dieser Arbeit wird unterschieden zwischen den Ausdrücken Audit, Review und
Prüfung. In der Literatur werden diese Ausdrücke teilweise synonym oder ungenau
verwendet. In Projekten allerdings, wie auch im Qualitätsmanagement ist ein Unterschied
festzustellen zwischen einer Review, einem Audit und einer Prüfung. Es wird weiter auch
unterschieden zwischen Projektaudit und Projektmanagement-Audit. Das Projektaudit nimmt
Bezug auf den Projektinhalt während sich das Projektmanagement-Audit auf die
Untersuchung und Überprüfung der Projektmanagement-Methode bezieht.
49 vgl. http://www.spol.ch/web/projektmanagement_governance.html, letzter Zugriff: 22. Februar 2012 50 vgl. ISO/DIS 21500, Draft International Standard, Guidance on project management, http://www.iso.org,
Seite 11 51 Patrick S. Renz (2007), Project Governance : Implementing Corporate Governance and Business Ethics in
Nonprofit Organizations, Physica Verlag Heidelberg New York, Seite 32 52 vgl. Peter Weill, Jeanne W. Ross (2000), IT Governance: how top performers manage IT decision rights for
superior results, Harvard Business School Press, Boston, Massachusetts, Seite 103
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
23 / 110
4.2.1 Prüfung
Mit einer Prüfung, sei es mündlich oder schriftlich, wird im Bildungswesen das Wissen oder
Erlernte abgefragt und mit der richtigen Lösung verglichen. Nach dem Brockhaus53 bedeutet
eine Prüfung die „Feststellung der Leistungen und Fähigkeiten…nach einer schulischen und
beruflichen Ausbildung oder Ausbildungsphase“. Das Bestehen einer Prüfung ist somit eine
Qualifizierung. Als Resultat werden Benotungen erstellt, Zertifikate ausgegeben oder andere
Arten der Qualifizierung durchgeführt. In der Betriebswirtschaftslehre wird die (Über-)-
Prüfung der Buchhaltung meistens als Revision53 bezeichnet. Der Ausdruck „Prüfung“ wird
auch in vielen weiteren Arten verwendet, z.B. Materialprüfung im Maschinenbau oder
Haltbarkeitsprüfung in der Lebensmittelbranche.
Eine Prüfung ist in dem Sinne der einmalige Vergleich eines Ist-Wertes (Prüfling) mit einem
Soll-Werte (was wird erwartet, was ist richtig).
4.2.2 Review
Je nach Herkunft wird eine „Review“ anders verstanden. Nach dem Brockhaus54 wird das
Wort mit „Rundschau“ und „Überblick“ übersetzt und hat verschiedene Bedeutungen: In der
Audiotechnik meint man das Mithören bei schnellem Bandlauf, in der Publizistik eine
Besprechung oder Rezension. Nach dem Duden55 ist die Review eine „kritische
Besprechung eines [künstlerischen] Produkts“. Nach Gabler56 ist eine Review die
„Vorgehensweise zum Testen und zur Prüfung von Systementwicklungen“. In Linguee57
wiederum wird für Review eine ganze Serie von Bedeutungen aufgelistet: „Überprüfung,
Rezension, Prüfung, Rückblick, Bewertung, Revision und weitere“.
In dieser Arbeit geht es um den Ausdruck im Sinne des Qualitätsmanagements in (IT)-
Projekten. Nach Pfetzing und Rhode58 wird mit Reviews „die bisher erzielte Qualität der
53 vgl. Quelle: Brockhaus - Die Enzyklopädie in 30 Bänden. 21., neu bearbeitete Auflage. Leipzig, Mannheim: F.
58 vgl. Karl Pfetzing, Adolf Rhode (2009), Ganzheitliches Projektmanagement, ibo Schriftenreihe Band 2, 3. Auflage, Verlag Dr. Götz Schmidt, Seiten 299-300
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
24 / 110
Ergebnisse gemessen“. Für Jenny59 ist eine Review eine Standortbestimmung aus einem
ganz bestimmten Blickwinkel. Für Projekte im Software-Entwicklungs-Umfeld wird nach
Frühauf/Ludewig/Sandmayr60 ein Arbeitsergebnis mit den Vorgaben respektive Richtlinien
verglichen. Die Swiss National Competence Baseline NCB61 ordnet eine „Project Review“
wiederum dem Berichtswesen in Form eines Qualitätsaudits zu.
Zusammenfassend gilt die Review als Teil des Qualitätsmanagements und wird in Projekten
zur Überprüfung von erwarteten Ergebnissen für einen ganz bestimmten und definierten
Gegenstand durchgeführt. Nach Pfetzing/Rhode62 gibt es verschiedene Levels, die von
„Schau mal drüber!“ bis zu einem formalisierten und strukturierten Bericht gehen. Eine
Review kann oder soll, je nachdem wer dies anordnet, durch Dritte durchgeführt werden. Für
die Qualitätssicherung innerhalb eines Projektes, z.B. für Dokumente beim Phasenende,
können auch Projektteam-Mitglieder die Review durchführen, sofern sie bei der Erstellung
des Review-Gegenstandes als Dritte nicht direkt daran beteiligt waren.
Nach Jenny63 ist der Ablauf einer Review wie folgt:
1. Planung Mit den Beteiligten wird der Review-Gegenstand und das Vorgehen
abgestimmt.
2. Vorbereitung Die Vorbereitung dient dem Gutachter zur Formulierung der Fragen und
Checklisten, das Projekt-Team kann den Review-Gegenstand
finalisieren und der Moderator plant das Review im Detail.
3. Durchführung Nach der Präsentation werden durch den Gutachter ev. noch Fragen
gestellt und die Checklisten abgearbeitet.
4. Analyse Nach der Durchführung erfolgt die Analyse und ein allfälliger Aktionsplan
wird durch den Gutachter erstellt.
5. Umsetzung: Die Ergebnisse werden umgesetzt.
Dieses Vorgehen wird in ähnlicher Weise auch von den Software Quality Labs64
vorgeschlagen.
59 vgl. Bruno Jenny (2001), Projektmanagement in der Wirtschaftsinformatik, 5. Auflage, vdf Hochschulverlag AG
an der ETH Zürich, Seiten 384-391 60 vgl. Karol Frühauf, Jochen Ludewig, Helmut Sandmayr ((2002), Software-Projektmanagement und –
Qualitätssicherung, vdf Hochschulverlag AG an der ETH Zürich, Seite 88 61 VZPM Beurteilungsstruktur, Swiss National Competence Baseline NCB, Version 4.1, Verlag: Verein zur
Zertifizierung im Projektmanagement (VZPM), Glattbrugg, Seite 74 62 vgl. Karl Pfetzing, Adolf Rhode (2009), Ganzheitliches Projektmanagement, ibo Schriftenreihe Band 2, 3.
Auflage, Verlag Dr. Götz Schmidt, Seiten 299-300 63 vgl. Bruno Jenny (2001), Projektmanagement in der Wirtschaftsinformatik, 5. Auflage, vdf Hochschulverlag AG
an der ETH Zürich, Seiten 384-391
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
25 / 110
4.2.3 Audit
Das Wort Audit stammt nach Duden65 aus dem lat. auditus = das (An)hören und bedeutet
eine (unverhofft durchgeführte) Überprüfung oder Revision. Der Brockhaus66 definiert Audit
mit „meist ohne Ankündigung durchgeführte Überprüfung oder Untersuchung“. Nach DIN EN
ISO 840267 ist ein Audit „eine systematische, unabhängige Untersuchung, um festzustellen,
ob die qualitätsbezogenen Tätigkeiten und damit zusammenhängenden Ergebnisse den
geplanten Anforderungen entsprechen, und ob diese Anforderungen tatsächlich verwirklicht
und geeignet sind, die Ziele zu erreichen“. Im Draft der ISO 2150068 wird unter
Qualitätsmanagement das Audit wie folgt beschrieben: „Quality audits determine the
performance of the quality process and quality control“. Die neuste Norm DIN 69901-569
erwähnt das Projektaudit unter Projektbewertung/Project Assessment „Beurteilung eines
Projektes zu verschiedenen Zwecken“. Die IPMA61 ordnet die Qualitätsaudits unter dem
Berichtswesen ein, analog den Reviews.
Sowohl Brockhaus, die DIN-Norm, als auch Wallmüller70 unterscheiden nach Produkt-,
Prozess- und Systemaudit. Ein Produktaudit ist nach Binner71 die Prüfung eines
fertiggestellten und geprüften Produktes. Es werden die in Zeichnungen, Normen oder
anderen Spezifikationen dokumentierten Qualitätsmerkmale überprüft. Bei einem
Prozessaudit wird die Arbeitsfolge auf mögliche Schwachstellen untersucht. Ein Systemaudit
wiederum dient zur Überwachung des Qualitätsmanagement-Systems. Für Wienhold72 ist ein
Audit „der Vergleich der tatsächlichen Vorgehensweise mit den geplanten Abläufen und die
lab.at/swql/uploads/media/Spezifikations-Reviews-20030920.pdf, letzter Zugriff: 22. Februar 2012 65 Duden – Deutsches Universalwörterbuch. Das umfassende Bedeutungswörterbuch der deutschen
66 Brockhaus - Die Enzyklopädie in 30 Bänden. 21., neu bearbeitete Auflage. Leipzig, Mannheim: F. A. Brockhaus 2005-06. https://10920.lip.e-content.duden-business.com/lip-suche/-/lip_article/B24/600109642, letzter zugriff: 10. Dezember 2011
67 DIN EN ISO 8402:1995-08, zitiert nach: http://www.quality.de/lexikon/qualitaetsaudit.htm, letzter Zugriff: 13. Januar 2012
68 ISO/DIS 21500, Draft International Standard, Guidance on project management, http://www.iso.org, letzter Zugriff: 22. Februar 2012
69 DIN 69901-5, Ausgabe 2009-01, Projektmanagement - Projektmanagementsysteme - Teil 5: Begriffe, Seite 12 70 vgl. Ernest Wallmüller (2001), Software-Qualitätsmanagement in der Praxis, 2. völlig überarbeitete Auflage,
Carl Hanser Verlag, München, Seiten 198-199 71 vgl. Hartmut F. Binner (2002). Prozessorientierte TQM-Umsetzung (Bd. 2. Auflage). München: Carl Hanser
Verlag, Seite 276 72 Klaus Wienhold (2003), Prozess- und Controllingorientiertes Projektmanagement für komplexe Projekte, Band
27 von „Controlling und Management“, Herausgegeben von Prof. Dr. Thomas Reichmann und Prof. Dr. Martin K. Welge, Peter Lang GmbH, Europäischer Verlag der Wissenschaften, Frankfurt am Main, 2004, Seite 96
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
26 / 110
Überprüfung der geplanten Abläufe hinsichtlich der Zielerreichung“, also eine Überprüfung
des Prozesses.
Zusammenfassend dient ein Audit der Überprüfung eines Produktes, Prozesses oder
Management-Systems. Als Vergleichswert werden Normen, Best Practices, Standards oder
interne Vorgaben verwendet. Diese Überprüfung wird durch eine unabhängige Person, den
Auditor, durchgeführt.
4.2.4 Projektaudit
Ein Projektaudit ist nach Ortner73 eine unabhängige objektive Wertung eines Projektes um
den wirklichen Status festzustellen. Dabei ist wie bei Jenny74 ein Produkt-Audit gemeint, d.h.
der Zustand des Projektes ist Ziel des Audit.
Für Kühn75 ist ein Audit „to gather relevant management information by implementing a
critical outside perspective (…) to allow for corrective actions“ und legt damit ein
Schwerpunkt auf die Massnahmen, die bei einem Audit folgen sollten.
Bei IT-Projekten kann zusätzlich zwischen einer Prüfung nach finanziellen Aspekten oder
einer reinen IT Prüfung unterschieden werden76.
Ein Projektaudit wird vom Projektausschuss, der Geschäftsleitung oder anderen
Stakeholdern gefordert und angeordnet. Als Grund werden oft vermutete, vorhersehbare
oder bereits eingetretene Kosten- oder Terminüberschreitungen angegeben. Es können aber
auch Audits als rein qualitätssichernde Massnahmen durchgeführt werden, entweder direkt
ausgewählt und geplant, oder zufällig ausgewählt oder statistisch ermittelt.
Ein Projektaudit wird meistens auch das weitere Vorgehen im Projekt beeinflussen. Je nach
den Befunden gibt es Optimierungen oder eine Neuplanung, es kann aber auch zu einem
Projektabbruch führen. Deshalb sollte ein Audit immer durch einen unabhängigen Auditor
geleitet werden.
Mit Bezug auf diese Arbeit könnte man ein Projektaudit mit der Frage „Wird das Projekt nach
COBIT-Grundsätzen geführt?“ anordnen.
73 vgl. Gerhard Ortner, Betina Stur (2011), Das Projektmanagment-Office, Springer-Verlag Berlin Heidelberg,
Seite 59 74 vgl. Bruno Jenny (2001), Projektmanagement in der Wirtschaftsinformatik, 5. Auflage, vdf Hochschulverlag AG
an der ETH Zürich, Seite 138 75 Andreas Kühn, Konrad Walser, Reinhard Riedl (2008), Auditing Projects in e-Goverment based on IT
Governance Methods, Competence Centre Public Management and E-Government Berne University of Applied Sciences, Seite 2
76 vgl. Manuel Juen (2005), IT Auditing im E-Government, Diplomarbeit im Fach Informatik, Institut für Informatik der Universität Zürich, Seiten 7-9
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
27 / 110
4.2.5 Projektmanagement-Audit
Das Projektmanagement-Audit ist nach Jenny77 die Prüfung der „Konformität bezüglich
Projektorganisation, Projektführungsprozess und Standards“. Nach Gabler78 steht ebenfalls
das „Projektmanagement im Fokus der Kritik“. Lent79 führt detailliert aus: „In einem
Projektmanagementaudit wird von unabhängigen Personen (…) systematisch untersucht, ob
die Verfahrensweisen und Ergebnisse den geplanten Prozessabläufen und Vorgaben
entsprechen“.
Es wird also die Führung und die Methodik des Projektes auditiert.
Mit Bezug auf diese Arbeit könnte man ein Projektmanagement-Audit mit der Frage „Ist
HERMES 5 nach COBIT-Grundsätzen aufgebaut?“ anordnen.
4.3 Controlling
Controlling stammt vom englischen und heisst übersetzt „das Steuern“. Es bedeutet nach
dem Brockhaus80 „Teilfunktion der Unternehmensführung, die die zielorientierte Steuerung
und Überwachung des Unternehmens zum Gegenstand hat“. Das Gabler
Wirtschaftslexikon81 hat eine ähnliche Definition, „Controlling ist ein Teilbereich des
unternehmerischen Führungssystems, dessen Hauptaufgabe die Planung, Steuerung und
Kontrolle aller Unternehmensbereiche ist. Im Controlling laufen die Daten des
Rechnungswesen und anderer Quellen zusammen“.
1986 definiert Horváth82 das Controlling als „ein Subsystem der Führung, Planung und
Kontrolle sowie Informationsversorgung systembildend und systemkoppelnd koordiniert“.
2002 wird durch den gleichen Autor83 das Controlling wie folgt definiert: „Controlling im Sinne
von Controllership wird als Teil der Führungsfunktion gesehen“ und auch „Inhaltlich ist die
Fokussierung auf das Planungs- und Kontrollsystem (…) mit der Ergebnisorientierung
77 vgl. Bruno Jenny (2001), Projektmanagement in der Wirtschaftsinformatik, 5. Auflage, vdf Hochschulverlag AG
an der ETH Zürich, Seite 138 78 vgl. Bernhard Hobel, Silke Schütte (2006), Projektmanagement A-Z, Gabler Business-Wissen,
Betriebswirtschaftlicher Verlag Dr. Th. Gabler | GWV Fachverlage GmbH, Wiesbaden 2006, Seite 260 79 vgl. Bogdan Lent (2003), IT-Projekte lenken – mit System, 1. Auflage Dezember 2003, Friedr. Vieweg & Sohn
Verlag | GWV Fachverlage GmbH, Wiesbaden, Seite QM-9 80 Brockhaus - Die Enzyklopädie in 30 Bänden. 21., neu bearbeitete Auflage. Leipzig, Mannheim: F. A.
Brockhaus 2005-06. https://10920.lip.e-content.duden-business.com/lip-suche/-/lip_article/B24/4067124, letzter zugriff: 14. Januar 2012
81 Gabler Verlag (Herausgeber), Gabler Wirtschaftslexikon, Stichwort: Controlling, online im Internet: http://wirtschaftslexikon.gabler.de/Archiv/399/controlling-v6.html, letzter Zugriff: 14. Januar 2012
82 Péter Horvát (1986), Controlling, 2. Auflage, Vahlens Handbücher der Wirtschaft- und Sozialwissenschaften, München 1986, Seite 154
83 Péter Horvát (2002), Der koordinationsorientierte Ansatz in Controlling als akademische Disziplin, Herausgeber: Jürgen Weber, Bernhard Hirsch, Schriften des Center for Controlling & Management (CCM), Band 7, Deutscher Universitätsverlag GmbH, Wiesbaden 2002, Seite 54
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
28 / 110
wesentlich“. Damit geht er auf die von ihm bereits 1978 erarbeiteten Vorschläge eines
koordinationsorientierten Ansatzes ein. Es ist kein wesentlicher Unterscheid festzustellen.
Controlling darf nicht mit Kontrolle übersetzt werden. Controlling bedeutet dem Sinne nach
Unternehmenssteuerung, während Kontrolle mehr der Soll-Ist-Vergleich ist84.
Internal Control85
Die COSO definiert „internal control“ als „Internal control is broadley defined as process (...)
designed to provide reasonable assurance regarding the achievement of objectives in the
following categories“86:
„Effectiveness and efficiency of operations“
„Reliabilitiy of financial reporting“
„Compliance with applicable laws and regulations“
Es werden als drei Hauptpunkte in das Zentrum der Kontrolle gestellt: Betrieb (Prozesse),
Finanzen und Compliance.
Die Operation (Betrieb, Prozesse) beinhaltet auch „performance and profitability goals“ sowie
„safeguard resources against loss“. Die Betriebsziele sollen helfen die Unternehmensziele zu
erreichen: „Moving the enterprise toward ist ultimate goal“86. Dazu gehören klare
Betriebsziele und eine Strategie „operation objektives and strategies“ und das führt zu einer
Zuordnung der Ressourcen. Sind die Zielsetzungen nicht klar, so kann es sein, dass die
Ressourcen nicht optimal eingesetzt werden. Der Ausdruck „Governance“ wird nicht benutzt.
Die Kontrolle der Finanzen ist nicht Kernpunkt dieser Arbeit und kann in der Literatur
nachgeschlagen werden. Der dritte Punkt der Internal Control, die Compliance, muss
sicherstellen, dass alle Gesetze und Policies eingehalten werden und ist, soweit notwendig,
als Bestandteil der Governance erfasst.
Der Zusammenhang zwischen Internal Control und Governance wird durch Kozer87 detailliert
ausgeführt. Die Unternehmensüberwachung wird durch unternehmensinterne oder
unternehmensexterne Überwachungsträger vorgenommen und ist als „Internal Control“ zu
verstehen. Wobei Gegenstand eben dieser Überwachung bei Kapitalgesellschaften die
84 vgl. Péter Horvát (1986), Controlling, 2. Auflage, Vahlens Handbücher der Wirtschaft- und
Sozialwissenschaften, München 1986, Seite 30 85 Die Ausdrücke Kontrolle, Controlling, internal Control etc. werden aufgrund der zweisprachigen Literatur-
Recherche (deutsch/englisch) synonym verwendet, auch wenn es fachlich nicht ganz korrekt ist. 86 vgl. Internal Control – Integrated Framework, Committee of Sponsoring Organizations of the Treadway
Commission COSO (1994), July 1994 Edition, Seiten 3, 34, 35 87 vgl. Melanie Kozer (2002), Corporate Governance: Das Zusammenspiel von Internal Control und External
Control, Inaugural-Dissertation zur Erlangung des grades Doktor oeconomia publica (Dr. oec. publ.) an der Ludwig-Maximilians-Universität München, Shaker verlag Achen 2002, Seiten 1-5, 31-34
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
29 / 110
Unternehmensführung ist. Die Mechanismen der Internal Control können als Bestandteil der
Corporate Governance im Sinne von Organen mit entsprechenden Zuständigkeiten
aufgefasst werden.
In der Literatur ist interessanterweise festzustellen, dass sich für die Begriffe Controlling und
Governance respektive deren Zusammenhang, kein einheitliche Betrachtungsweise etabliert
hat. Nicht einmal der Begriff „Controlling“ wird einheitlich aufgefasst und wird das Controlling
im Sinne des Rechnungswesen betrachtet, taucht der Begriff „Governance“ oft nicht einmal
auf.
Weber88 meinte dazu 2002 im Vorwort zu einer Tagung der Controlling-Lehrstühle in
Deutschland: „Anlass und Ziele der Tagung sind aus mehreren Merkmalen des aktuellen
Kontextes der akademischen Auseinandersetzung mit dem Controlling heraus erklärbar.
Nach eher schwierigem Beginn (..:) ist das Controlling an den Hochschulen zwar fest
etabliert. Trotz der Vielzahl von Lehrstühlen scheint das Fach allerdings noch nicht über eine
vorwissenschaftliche Phase hinausgekommen zu sein“! Bemerkenswert, weil 2010 gemäss
Aussage von Weber89 „Bis heute herrscht noch immer ein uneinheitliches Verständnis, was
unter Controlling zu verstehen ist und welche Entwicklungen vorstellbar sind“ immer noch
keine Verbesserung festgestellt werden konnte.
In COBIT90 gibt es den Prozess MEA02 „Monitor System of Internal Control“ mit der Aufgabe
„Continuously monitor and evaluate the control environment, including self--�assessments
and independent assurance reviews. Enable management to identify management
deficiencies and inefficiencies and to initiate improvement actions. Plan, organise and
maintain standards for internal control assessment and assurance activities“.
External Control
Nach dem Business Dictionary91 bedeutet External Control: „Various measures that affect a
company's operations, which are not enacted by the company but rather by the government
or other organizations“.
Diese Begrifflichkeit ist der vollständigkeitshalber aufgeführt, ist aber nicht Kernpunkt dieser
Arbeit und kann in der Literatur nachgeschlagen werden.
88 Jürgen Weber, im Vorwort zu Controlling als akademische Disziplin, Herausgeber: Jürgen Weber, Bernhard
Hirsch, Schriften des Center for Controlling & Management (CCM), Band 7, Deutscher Universitätsverlag GmbH, Wiesbaden 2002, Seite V
89 Daniel Schreiber (2010), Management von Controllingwissen, 1. Auflage 2010, Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2010, Seite 28
90 COBIT 5: Process Reference Guide, Exposure Draft, ISACA, Seite 196 91 http://www.businessdictionary.com/definition/external-control.html, letzter Zugriff: 21. Januar 2012
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
30 / 110
Von der Unternehmung zum Projekt
Auf der Unternehmens-Ebene ist das Controlling ein wichtiges Hilfsmittel des Managements
für die Führung und Kontrolle. In einzelnen Unternehmungen kann ohne das Controlling
nichts umgesetzt werden: „Alles was kein Prüfsiegel des Controllings besitzt, zählt nicht“ so
Ralf Stemmer, Personalvorstand der Postbank AG in Bonn, in einem Interview in Controlling
& Management92.
Aber auch auf Stufe Projekt braucht es ein Controlling. Ein Projekt ist nichts anderes als ein
„Unternehmen in der Unternehmung“ wie Blazek93 bereits auf dem Buchdeckel als Untertitel
aufführt. Weiter meint er, „Projekte müssen gemanaged und controlled werden“. Das führt
dann zum Projektcontrolling94.
Bereits 1981 definierte der VDMA95, „Eines der wichtigsten Instrumente ist das Projekt-
Controlling, mit dessen Hilfe Kosten, Termine und Teilergebnisse eines Projektes geplant,
überwacht und gesteuert werden“.
Für DIN 69901-396 ist denn auch das Projektcontrolling „integraler Bestandteil des
Projektmanagements“. Das bedeutet nichts anders, als dass ein Controlling als Norm für
Projekte vorgesehen ist, nämlich Projektcontrolling. DIN 69901-597 aus der gleichen
Normenreihe sieht dann die Aufgabe des Projektcontrollings als „Sicherstellung des
Erreichens aller Projektziele durch Ist-Datenerfassung, Soll-Ist-Vergleich, Analyse der
Abweichungen, Bewertung der Abweichungen gegebenenfalls mit Korrekturvorschlägen,
Massnahmenplanung, Steuerung der Durchführung von Massnahmen“ an.
Die DIN 2150098 führt ebenfalls die gleichen Aufgaben auf „The controlling processes are
employed to monitor, measure, and control the project’s performance against the project plan
so that preventive and corrective actions may be taken and change requests made when
they are necessary to ensure the project objectives are achieved“.
Fachmedien Wiesbaden GmbH, Seite 28 93 Alfred Blazek, Detelv R. Zillmer, (2001), Projekt-Controlling, VCW Verlag für Controllingwissen AG, Offenburg,
Wörthsee-Etterschlag, Seite 18 94 Es gibt zwei verbreitete Schreibweisen: Projektcontrolling und Projekt-Controlling. Im deutschen
Sprachgebrauch ist in der Literatur auch Projektkontrolle zu finden. In dieser Arbeit werden alle Schreibweisen synonym benutzt.
95 Verband Deutscher Maschinen- und Anlagebau e.V. VDMA, Projekt-Controlling im Anlagengeschäft, BmV 187, 2. Auflage August 1982, Maschinenbau-Verlag gmbH, Frankfurt/Main, Seite 11
96 DIN 69901-3, Ausgabe 2009-01, Projektmanagement - Projektmanagementsysteme - Teil 3: Methoden, Seite 6
97 DIN 69901-5, Ausgabe 2009-01, Projektmanagement - Projektmanagementsysteme - Teil 5: Begriffe, Seite 12 98 vgl. ISO/DIS 21500, Draft International Standard, Guidance on project management, http://www.iso.org,
Seite 16
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
31 / 110
Für Jenny99 bedeutet die Projektkontrolle „alle Aktivitäten um projektbezogene
Abweichungen zwischen SOLL- und dem IST-Zustand aufzudecken, um darauf gezielt
reagieren zu können“.
Kuster100 definiert das Projektcontrolling bereits als eigenständigen Begriff, der „Prozesse
und Regeln beschreibt, die innerhalb des Projektmanagements zur Sicherstellung des
Erreichens der Projektziele beiträgt“ und auch Qualitätsmanagement und Risikomanagement
beinhalten kann. Projektkontrolle und Projektsteuerung wird als ein Art Unterdisziplin des
Projektcontrollings verstanden.
In Wienhold101 bedeutet das Controlling u.a. „Unterstützung der Planung, Steuerung und
Kontrolle der Einzelprojekte“ und führt weiter aus: „Umfasst demnach alle Aktivitäten und
Massnahmen (…) zur Unterstützung der Planung, Steuerung und Kontrolle der
Einzelprojekte“.
Controlling soll durch „Beobachten des Verhaltens (Monitoring) von allen für das Projekt
wichtigen Parametern“ bewirken, dass die Projektziele erreicht werden, denn ohne
Monitoring „können Projekte leicht in eine Krise geraten“102.
Das Projektcontrolling befasst sich, zusammenfassend gesehen, mit der Führung, der
Steuerung, der Kontrolle und den Korrekturmassnahmen bei Projekten betreffend Termine,
Kosten und Qualität.
Zusammenhang mit Governance?
In der Fachliteratur wird auch, wie oben gezeigt, für jedes Projekt Kontrollen oder Controlling
als Bestandteil des Projektmanagements ausgewiesen. Werden nun die Anforderungen der
Governance auch vom Controlling gesteuert und überwacht?
Laut dem MAS-Studiengang der HWZ103 ist Controlling, „zu hinterfragen, inwiefern Prozesse,
Methoden und Instrumente den aktuellen und zukünftigen Anforderungen einer nachhaltigen
und wertorientierten Unternehmensführung gerecht werden“. Es soll: „Zusammenhänge
schaffen zwischen Unternehmenszweck, Geschäftsmodell, Wachstums- und
99 Bruno Jenny (2005), Projektmanagement, 2. Auflage 2005, vdf Hochschulverlag AG an der ETH Zürich,
Seite 129 100 Jürg Kuster et al.(2008), Handbuch Projektmanagement, 2. Auflage, Springer Verlag, Berlin, Heidelberg,
Seiten 154-158 101 Klaus Wienhold (2003), Prozess- und Controllingorientiertes Projektmanagement für komplexe Projekte, Band
27 von „Controlling und Management“, Herausgegeben von Prof. Dr. Thomas Reichmann und Prof. Dr. Martin K. Welge, Peter Lang GmbH, Europäischer Verlag der Wissenschaften, Frankfurt am Main, 2004, Seite 14-15
102 Rationalisierungs-Kuratorium der Deutschen Wirtschaft, Projektmanagement Fachmann (2001), 6. Auflage, Band 1, RKW-Verlag, Seite 204
103 Kursausschreibung CONTROLLING, MASTER of Advanced Studies (MAS), HWZ, Hochschule für Wirtschaft Zürich, Seite 6
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
32 / 110
Wirtschaftlichkeitszielen“. Das kann auch im Zusammenhang mit der (IT-)-Governance
gesehen werden, müssen doch in Bezug auf diese Frage die aktuellen und zukünftigen
Prozesse hinterfragt werden.
Krcmar104 sieht einen noch direkteren Zusammenhang der Governance mit dem Controlling:
„Eng verbunden mit der IT-Governance ist das IT-Controlling, das die Effizienz und
Effektivität bei der Erreichung der Unternehmensziele sicherstellen soll, sowie Sachziele
Qualität, Funktionalität und Termineinhaltung der Informationsverarbeitung fördert“. Weiter
folgert Krcmar, dass das IT-Controlling auch einen Teil zur Gestaltung und Abstimmung von
Geschäftsprozessen beiträgt, was auch Teil der Governance ist.
Und für Wagenhofer ist der Fall klar: „In seiner Service Funktion hilft das Controlling dem
Management, seine Aufgaben im Zusammenhang mit der Corporate Governance zu
erfüllen“. Weiter wirft er einen Blick auf die Zukunft: „Die ständige Weiterentwicklung der
Corporate Governance stellt erhebliche Anforderungen an die Unternehmensführung und hat
damit auch starke Auswirkungen auf das Controlling“. 105
Ein Zusammenhang kann auch über die Vorgaben106 der COSO „Control activities must be
evaluated in the context of management directives to address risks associated with
established objectives for each significant activity“ gesehen werden. Voigt107 folgert daraus,
„Um dies sicherzustellen müssen Kontrollaktivitäten definiert und im Unternehmen eingeführt
werden. Beispielsweise beziehen sich diese Kontrollaktivitäten auf die Überprüfung von
Konten hinsichtlich der Ordnungsmässigkeit der Rechnungslegung“. Und als
Schlussfolgerung dieser beiden Quellen darf interpretiert werden, dass mit „significant
activities“ auch die Rechnungslegung gemeint sein kann und damit wäre der
Zusammenhang mit dem Controlling gegeben.
In der Stadt Zürich definiert man zwei Arten Controlling. Einerseits das strategische
Controlling, mit dem die Dimension der IT-Governance abgedeckt wird und andererseits das
operative Controlling, das sich auf die korrekte Projektführung bezieht und auch auditiert
werden kann.
Zusammenfassung
104 vgl. Krcmar (2010), Einführung in das Informationsmanagement, Springer-Verlag, Berlin Heidelberg 2011,
Seite 159 105 Alfred Wagenhofer (2009), Corporate Governance und Controlling in Controlling und Corporate Governance-
106 vgl. Internal Control – Integrated Framework, Committee of Sponsoring Organizations of the Treadway Commission COSO (1994), July 1994 Edition, Seite 56
107 Johannes Voigt (2006), COSO & COBIT zur Unterstützung der Corporate Governance, 1. Auflage 2006, Seminararbeit an der Fachhochschule Koblenz, GRIN Verlag, Seite 13
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
33 / 110
Ob jetzt das Controlling, auf Stufe Unternehmung oder Projekt, als Unterdisziplin der
Corporate Governance anzuschauen ist, oder ob es lediglich ein Baustein für das
Management ist, um die Governance sicherzustellen, lassen wir in dieser Arbeit offen.
Man darf aber festhalten, dass Controlling mit der Governance in Verbindung gebracht
werden kann. Weiter ist festzuhalten, dass Resultate aus dem Controlling zur Umsetzung
respektive Einhaltung der Governance benötigt werden.
4.4 Organisationen
In der Erklärung und der weitergehenden Benutzung der Begriffe Governance und
Controlling werden Quellen der Organisationen COSO, ISACA, ITGI benutzt. Da diese
Organisationen den Kern dieser Arbeit bilden, sind sie hier kurz vorgestellt.
4.4.1 COSO
Das Committee of Sponsoring Organizations of the Treadeway Commission COSO wurde
1985 als Initiative von privaten amerikanischen Wirtschaftsinstituten108 gegründet. Ursache
war eine Studie bezüglich betrügerischer Finanzberichterstattung in den USA, in der
festgestellt wurde, dass das IKS109 in vielen Fällen entweder leicht umgangen werden konnte
oder nicht umfassend genug war. Es entwickelte Empfehlungen bezüglich IKS für öffentliche
Unternehmen, Wirtschaftsprüfer, für die SEC und andere Aufsichtsbehörden sowie für
Hochschulen. Die Kommission hat unabhängige Vertreter von Trägerorganisationen aus
Industrie, öffentlichen Rechnungswesens, Investment-Firmen und der New York Stock
Exchange.
Der erste Vorsitzende der Nationalen Kommission war James C. Treadway, Jr. Executive
Vice President und General Counsel, Paine Webber Incorporated und ein ehemaliger
Kommissar der US Securities and Exchange Commission. Daher die damals populäre
Bezeichnung "Treadway Commission". Derzeit ist der COSO Chairman David Landsittel.
Das Ziel der COSO ist, für die drei Themen Enterprise Risk Management (ERM), interne
Kontrolle und Betrugsprävention Support für das Management anzubieten, wobei hier nur die
interne Kontrolle von Interesse ist.
Im Bereich der internen Kontrolle hat die COSO 1992 das Rahmenwerk „Internal Control -
Integrated Framework“ publiziert und es 1994 überarbeitet. Ende 2010 gab COSO bekannt,
108 The American Accounting Association (AAA), the American Institute of Certified Public Accountants (AICPA),
Financial Executives International (FEI), The Institute of Internal Auditors (IIA), and the National Association of Accountants (now the Institute of Management Accountants [IMA]).
109 Internes Kontroll-System IKS
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
34 / 110
dieses Werk zu überarbeiten110, 111. Dieses Werk bezieht sich auf die interne Kontrolle, und
wenn die Kontrollen IT-lating wurden, verwenden viele Revisoren COBIT als Ergänzung.112
4.4.2 ISACA
ISACA hat seinen Ursprung im Jahr 1967, als eine kleine Gruppe von Individuen mit
ähnlichen Jobs wie Auditing und Kontrollen in EDV-Systemen, die zunehmend kritisch für
den Betrieb ihrer Organisationen wurden, die Notwendigkeit für einen zentrale Austausch
von Informationen sah. Im Jahre 1969 gründete die Gruppe die EDP Auditors Association.
1976 gründete dieser Verband eine Stiftung zur Forschung in der IT-Governance und
internen Kontrolle. Früher war die Vereinigung als Information Systems Audit and Control
Association bekannt, heute wird nur noch ISACA benutzt.113.
Heute ist die ISACA ein Zertifizierer (CISA, CISM, CGEIT, CRISC114), Sponsor für technische
und Management-Konferenzen und Herausgeber von Frameworks wie COBIT, Val IT115,
RISK IT116, ITAF117 und BMIS118.
Die ISACA publizierte 1994 die erste Version von COBIT (Control Objectives for Information
and related Technology).
4.4.3 ITGI
Das IT Governance Institute (ITGI) wurde durch die ISACA im Jahre 1998 gegründet
aufgrund der zunehmenden Wichtigkeit der Informationstechnologie am
Unternehmenserfolg. In vielen Unternehmen hängt der Erfolg zur Erreichung der
Unternehmensziele von der Fähigkeit der IT ab. In einem solchen Umfeld ist die IT-
110 vgl. http://www.coso.org/aboutus.htm, letzter Zugriff, 22. Januar 2012 111 vgl. Johannes Voigt (2006), COSO & COBIT zur Unterstützung der Corporate Governance, 1. Auflage 2006,
Seminararbeit an der Fachhochschule Koblenz, GRIN Verlag, Seite 9 112 vgl. Harry Cendrowski, William C. Mair (2009), Enterprise Risk Managmeent and COSO, Verlag John Wiley &
Sons, Inc., Hoboken, New Jersey, Seiten 77, 103 113 vgl. http://www.isaca.org/About-ISACA/Press-room/Pages/ISACA-Fact-Sheet.aspx, letzter Zugriff: 22. Januar
2012 114 CISA: Certified Information Systems Auditor, CISM Certified Information Security Manager, CGEIT Certified in
the Governance of Enterprise IT, CRISC Certified in Risk and Information Systems Control, http://www.isaca.org/CERTIFICATION/Pages/default.aspx. letzter Zugriff: 22. Januar 2012
115 VAL IT ist das Governance Framework von ISACA zur Steuerung und Messung des Wertebetrags der IT an das Business (Value Delivery). http://www.isaca.org/Knowledge-Center/Val-IT-IT-Value-Delivery-/Pages/Val-IT1.aspx, letzter Zugriff: 22. Februar 2012
116 RISK IT ist das Governance Framework von ISACA zur Identifizierung, Messung und Steuerung der IT bezogenen Risiken (Risk Management). http://www.isaca.org/Knowledge-Center/Risk-IT-IT-Risk-Management/Pages/Risk-IT1.aspx, letzter Zugriff: 22. Februar 2012
117 ITAF ist das Framework für IT-Audit und IT-Assurance, http://www.isaca.org/Knowledge-Center/ITAF-IT-Assurance-Audit-/Pages/default.aspx, letzter Zugriff: 22. Februar 2012
118 BMIS ist das Business Model for Information Security von der ISACA. http://www.isaca.org/Knowledge-Center/BMIS/Pages/Business-Model-for-Information-Security.aspx, letzter Zugriff: 22. Februar 2012
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
35 / 110
Governance genauso kritische Management-Disziplin wie die Corporate Governance oder
Enterprise Governance. Effektive IT-Governance hilft sicherzustellen, dass IT die
Unternehmensziele unterstützt und verwaltet IT-bezogenen Risiken und Chancen.119
Das ITGI ist eine Art Think Thank für die Manager bezüglich IT-Governance: „The IT
Governance Institute (ITGI) exists to help enterprise leaders understand why IT goals must
align with those of the business, how IT delivers value, and how its performance is
measured, its resources properly allocated and its risks mitigated.“120
4.5 Maturity Modell
4.5.1 CMMI
„CMMI (Capability Maturity Model Integration) is a process improvement approach that
provides organizations with the essential elements of effective processes, which will improve
their performance“, so lautet die erste Erklärung auf der Homepage121 des Software
Engineering Institute (SEI) an der Carnegie Mellon University122. Bereits 1986 begann das
SEI mit der Entwicklung eines Systems zur Bewertung der Reife von Softwareprozessen“123.
Dies führte 1991 zur erste publizierten Version des Capability Maturity Model CMM 1.0. Dies
wurde kontinuierlich weiterentwickelt und seit 2010 gibt es drei Versionen:
CMMI-ACQ CMMI for Acquisition
CMMI-DEV CMMI for Development
CMMI-SVC CMMI for Services
Dieses Framework definiert und misst die Qualität von Prozessen (Ursprünglich in der
Software Entwicklung) und legt dabei den Reifegrad (Maturity Level) fest mit dem Ziel einer
kontinuierlichen Prozessverbesserung. Die Reifegrade bedeuten dabei „how advanced an
organization’s processes are as a whole and how well the organization has achieved
capability levels“124. Jeder Prozess ist mit einem Reifegrad bewertet, d.h. die Zielsetzungen
HTMLDisplay.cfm&ContentID=57434, letzter Zugriff: 22. Januar 2012 120 http://www.isaca.org/About-ISACA/IT-Governance-Institute/Pages/default.aspx, letzter Zugriff: 22. Januar 2012 121 http://www.sei.cmu.edu/cmmi/, letzter Zugriff: 28. Januar 2012 122 The Carnegie Mellon Software Engineering Institute (SEI) works closely with defense and government
organizations, industry, and academia to continually improve software-intensive systems. Our core purpose is to help organizations such as yours to improve their software engineering capabilities and to develop or acquire the right software, defect free, within budget and on time, every time. http://www.sei.cmu.edu/about/, letzter Zugriff: 28. Januar 2012
123 http://de.wikipedia.org/wiki/Capability_Maturity_Model_Integration, letzter Zugriff: 28. Januar 2012 124 Eileen C. Forrester, Brandon L. Buteau, Sandy Shrum (2011), CMMI for Services, Second Edition, Addison-
Wesley, Copyright 2011 Pearson Education Inc., Seite 55
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
36 / 110
der Prozess-Bereiche für diesen Level müssen erfüllt sein. Es sind fünf Reifegrade definiert,
von 1 bis 5. Der erste Level „Initial“ hat keine Anforderungen, jeder Prozess ist mindestens
auf Level 1.
ML 1: Initial
Keine Anforderungen. Diesen Reifegrad hat jede Organisation automatisch. die
Prozess Implementierung ist nicht organisiert und chaotisch. Die Organisation ist
abhängig von den wenigen Personen die den Prozess beherrschen.
ML 2: Managed (Wiederholbar)
Eine Projektmanagement Methodik ist eingeführt und es existiert eine Infrastruktur
um Projekte erfolgreich durchzuführen. Ein ähnliches Projekt kann erfolgreich
wiederholt werden.
ML 3: Defined (Definiert)
Die Projekte und Prozesse werden nach einem angepassten Standard durchgeführt
und es gibt eine organisationsweite kontinuierliche Prozessverbesserung.
ML 4: Quantitatively Managed (Geleitet)
Quantitatives Management der Projekte und Prozesse ist eingeführt. Die Qualität und
die Prozess-Performance wird durch eine statistische Prozesskontrolle gemessen.
ML 5: Optimized (Optimierend)
Die Organisation verbessert kontinuierlich die Arbeitsweise mit Hilfe einer
statistischen Prozesskontrolle (siehe auch Techniken aus Six Sigma125 und SPC126).
Prozesse und Verbesserungen werden in der Organisation: „in a planned and
managed fashion“ eingeführt.
Quellen: Wikipedia127, Kennett128.
Für jeden Prozess und Reifegrad gibt es Prozessgebiete und Praktiken. Die Prozessgebiete
sind Teile des Prozesse die auf den Levels anzutreffen sind (Analog den Modulen in
HERMES 5 welche in jeder Phase anzutreffen sind). Die Prozessgebiete „gruppieren eine
Menge von zusammengehörenden Praktiken, die, wenn sie alle umgesetzt sind, wiederum
125 Six Sigma, Methode im Qualitätsmanagement 126 SPC, Statistical Process Control, siehe Six Sigma 127 vgl. http://de.wikipedia.org/wiki/Capability_Maturity_Model_Integration, letzter Zugriff: 28. Januar 2012 128 vgl. Ron S. Kenett, Emanuel R. Baker (2010), Process Improvement and CMMI for Systems and Software,
CRC Press, Taylor & Francis Group, Boca Raton, London, New York, Seiten 71-76
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
37 / 110
eine Menge von Zielen eines bestimmten Gebietes erfüllen“129. Diese Zielerreichung ist
wichtig um eine Verbesserung zu erreichen. Sind für einen bestimmten Reifegrad die
Praktiken durchgeführt und die Zielsetzungen erreicht so hat man für diesen Prozess den
Reifegrad erreicht.
Bezogen auf das Projekt Management gibt es das Prozessgebiet ICM Integrated Project
Management. Für jeden Level sind dafür gewisse Praktiken zu erfüllen. Das Risk
Management (RSKM) z.B. muss zuerst für den Level 3 erfüllt werden während auf dem Level
2 das Prozessgebiet Project Planning (PP) angesiedelt ist130.
Interessant wäre jetzt die Frage, ab welchem Level die Governance nach COBIT erfüllt
wird?131
4.5.2 ISO/IEC 15504, SPICE
Die Norm 15504132 der ISO ist ein Framework für Beurteilung von Prozessen analog dem
CMMI-Reifegrad-Modell. Das Model ist auch unter dem namen SPICE „Software Process
Improvement and Capability Determination“ bekannt.
CMMI und ISO 15504/SPICE sind inhaltlich vergleichbar. Beide Modelle wollen dasselbe und
sind in ihren Anforderungen fast identisch. Der Unterschied liegt in den Details133.
Auch Rout134 stellt fest, dass mit der Version CMMI V1.3 eine Annäherung stattgefunden hat:
„It offers a significant opportunity for greater interaction between CMMI and ISO/IEC 15504“.
Auch wenn beide Modell ihre Berechtigung haben und ähnlich sind, so würde Van Loon135
die gleiche Linie, die COBIT eingeschlagen hat wählen: „For organizations looking for a
general process assessment and improvement approach, either model is acceptable, but my
preference would be to use ISO/IEC 15504 because of the flexibility and the power of having
various process reference models“.
129 vgl. Jürgen Schmied et.al. (2008), Mit CMMI Prozesse verbessern, 1. Auflage 2008, dpunkt.verlag gmbH,
Heidelberg, Seiten 13, 14 130 vgl. Jürgen Schmied et.al. (2008), Mit CMMI Prozesse verbessern, 1. Auflage 2008, dpunkt.verlag gmbH,
Heidelberg, Seite 53 131 vgl. Anhang „Themen für Master-Arbeiten“ 132 ISO/IEC 15504-5:2006, An exemplar Process Assessment Model, www.iso.org 133 vgl. http://www.wibas.de/publikationen/cmmi/vergleich_cmmi_und_spice/index_de.html, letzter Zugriff:
29.Januar 2012 134 Terry Rout (2011), High Levels of Process Capability in CMMI and ISO/IEC 15504 in Software Process
Improvement and Capability Determination, Herausgeber Rory V. O’Connor, Terry Rout, Feragl McCaffery, Alec Dorling, 11th International Conference SPICE 2011, Dublin, Springer Verlag Berlin Heidelberg 2011, Seite 197
135 Han van Loon (2004), Process Assessment and ISO/IEC 15504, The Kluwer International Series in Engineering and Computer Science, Volume 775, Springer Science+Business Media, New York, Seite 252
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
38 / 110
4.6 HERMES
Das „Handbuch der Elektronischen Rechenzentren des Bundes, Methode für die
Entwicklung von Systemen“, kurz HERMES genannt, wurde als eigene Management-
Methodik für Informatikprojekte des Bundes136 entwickelt. HERMES ist gemäss Weisung137
des Bundes Standard bei der Bundesverwaltung und muss zwingend für Informatikprojekte
angewendet werden. Seit 2003 gilt HERMES als offener Standard des Bundes und am
22.06.2006 wurde HERMES vom Verein eCH138 (eGovernment-Standards) anerkannt und
publiziert.
4.6.1 Die Entstehungsgeschichte von HERMES
HERMES wurde ab ca. 1970 beim Bund entwickelt und 1975 erschien die erste offizielle
Version. Die Methodik wird infolge der freien und kostenlosen Verfügbarkeit auch ausserhalb
der Bundesverwaltung angewendet. Hauptsächlich jedoch durch staatliche Organisationen
wie Gemeinde- und Kantonsverwaltungen, Verwaltungen grösserer Städte sowie von
Lieferanten für Öffentliche Verwaltungen. 1986 und 1995 wird HERMES jeweils überarbeitet
und als neue Version publiziert139.
Im Jahre 2003 wird die Methode revidiert, so dass sie flexibel angepasst werden kann. Es
erscheint HERMES Systementwicklung SE140 und als Pendant dazu im Jahre 2005
HERMES-Systemadaption SA141. SE wird für Software-Entwicklung eingesetzt während SA
hauptsächlich für Evaluationsprojekte Verwendung findet. Die Versionen 2003/2005 sind
immer noch die aktuellen Versionen, zur Zeit wird die HERMES Version 5 vorbereitet,
welche bis 2013 eingeführt werden soll142.
Es wurden noch einige Ergänzungen publiziert, so steht seit 2009 mit HERMES OM auch
eine Methode für die Abwicklung von Organisationsprojekten zur Verfügung. 2010 wird
aufgezeigt, wie HERMES mit agilen Projektmethoden zurechtkommt.
136 vgl. http://www.ehermes.ch, letzter Zugriff: 22. Februar 2012 137 vgl. P007 – Richtlinien für Projektführung in Informatikprojekten, Version 2.03 vom 26.08.2011, Informatikrat
Bund (IRB), vertreten durch das ISB, genehmigt am 14.09.2004, http://www.isb.admin.ch/themen/standards/alle/03155/index.html, letzter Zugriff: 22. Februar 2012
138 vgl. http://www.ech.ch, letzter Zugriff: 22. Februar 2012 139 vgl. http://www.ehermes.ch/ueber-hermes/projekte, letzter Zugriff: 22. Februar 2012 140 HERMES, Führen und Abwickeln von Projekten der Informatik- und Kommunkationstechnik (IKT),
Systementwicklung, Ausgabe Februar 2004, Art.-Nr. 609.201 d Informatikstrategieorgan Bund ISB, CH-3003 Bern
141 HERMES, Führen und Abwickeln von Projekten der Informatik- und Kommunkationstechnik (IKT), Systemadaption, Ausgabe April 2005 (2. Auflage, überarbeitet August 2009), Art.-Nr. 609.202 d Informatikstrategieorgan Bund ISB, CH-3003 Bern
142 vgl. http://www.ehermes.ch/ueber-hermes/projekt-hermes-weiterentwicklung/vorgehen, letzter Zugriff: 22. Februar 2012
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
39 / 110
Abbildung 1: Die drei Pfeiler von HERMES [Seite 46]
4.6.2 Fachgruppe eCH und SAQ-Zertifikate
Neben der Methodik an und für sich gibt es weitere Unterstützungen für HERMES. Es wurde
vom Verein eCH als Standard143 anerkannt und erhält eine eigene Fachgruppe144.
Die Firma SAQ bietet eine zweistufige Zertifizierung an, den „HERMES Swiss Project Team
Professional HSPTP“ und den „HERMES Swiss Project Manager HSPM“145.
4.6.3 Die Grundzüge der Projektführungsmethode HERMES
Referenzen
Die folgenden Kapitel 4.6.3 bis 4.6.8 benutzen als Quelle, wenn nichts anderes bezeichnet
ist, das HERMES-Handbuch „Systemadaption Ausgabe 2005“146. Der einfachheithalber sind
die Fussnoten und Verweise hier einmal aufgeführt. Es wird nur noch auf die entsprechende
Seitenzahl verwiesen, [Seite xy] wenn referenziert wird. Für den Rest gilt „vgl.“. Referenzen
auf andere Literatur sind komplett referenziert.
HERMES Grundlagen
HERMES baut auf den drei Pfeilern Ergebnisse, Rollen
und Vorgehen auf.
Ergebnis: Was wird erarbeitet?
Rolle: Wer macht was?
Vorgehen: Wie wird gearbeitet?
Vom Vorgehen her entspricht HERMES einem Wasserfall-
orientierten Phasenmodell147. Nach jeder Phase sind
Ergebnisse vorgeschrieben, während den Phasen können
Zwischenergebnisse gefordert sein. Erarbeitet werden diese Ergebnisse durch Mitarbeiter
mit definierten Rollen, welche exakt zugeordnet werden. Somit sind die Verantwortlichkeiten
weitgehend festgelegt. In Submodellen werden die phasenübergreifenden Tätigkeiten
letzter Zugriff: 22. Februar 2012 144 vgl. http://www.ech.ch/vechweb/page?p=page&site=/Gremien/Fachgruppen/HERMES,
letzter Zugriff: 22. Februar 2012 145 vgl. http://www.saq.ch/de/zertifikate/hermes, letzter Zugriff: 22. Februar 2012 146 vgl. HERMES, Führen und Abwickeln von Projekten der Informatik- und Kommunikationstechnik (IKT),
Systemadaption, Ausgabe April 2005 (2. Auflage, überarbeitet August 2009), Art.-Nr. 609.202 d Informatikstrategieorgan Bund ISB, CH-3003 Bern
147 vgl. Bruno Jenny (2001), Projektmanagement in der Wirtschaftsinformatik, 5. Auflage, vdf Hochschulverlag AG an der ETH Zürich, Seite 220
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
40 / 110
Für die Reduktion der Ergebnisse auf die tatsächlich benötigten Elemente kann das Modell
angepasst werden, HERMES nennt das „Tailoring“148. Mit dem Tailoring können die jeweils
für das entsprechende Projekt geforderten minimale Ergebnisse definiert werden, und man
arbeitet dabei immer noch nach dem Standard.
4.6.4 Projektkategorien
HERMES ordnet die Projekte jeweils den Projektkategorien A, B, oder C zu:
Die Projektkategorien werden zur Einstufung des Projektes und auch für das Tailoring (siehe
Kapitel 4.6.8, Tailoring, Seite 44) benötigt.
4.6.5 HERMES - Vorgehen
HERMES baut auf einem Phasenmodell mit sechs Phasen auf. Nach jeder Phase gibt es
Entscheidungspunkte (Meilensteine) mit Ergebnissen, während den Phasen können
Zwischenergebnisse definiert werden. So ist z.B. während der Voranalyse das
Zwischenergebnis „Zielvereinbarung“ zu erarbeiten .
148 Aus dem englischen für „konfektionieren“, „zurechtschneidern“.
Abbildung 3: Phasenmodell HERMES [Seite 8]
Abbildung 2: Beurteilung der Projektkategorie [Seite 32]
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
41 / 110
HERMES unterscheidet zwischen den Projekttypen Entwicklung und Systemkauf. Es gibt
zwei unterschiedliche Vorgehen, welche mit SA (Systemadaption = Kauf/Evaluation) und SE
(Systementwicklung = Entwicklung) bezeichnet werden. Der Hauptunterschied liegt in den
Phasen der Evaluation/Konzeption und Implementierung/Realisierung
Submodelle
Alle Tätigkeiten oder Themen, die in jeder Phase des Projektes bearbeitet werden sind als
„Submodelle“ bezeichnet. Das sind auch die typischen Projektmanagement-Tätigkeiten,
womit ein Projektleiter permanent beschäftigt ist:
Projektmanagement
Risikomanagement
Qualitätssicherung
Konfigurationsmanagement
Projektmarketing
Für jedes der Submodelle werden an jedem Phasenende auch Ergebnisse verlangt. Die
zugehörigen Tätigkeiten und Verantwortlichkeiten respektive Rollen werden durch HERMES
definiert.
Abbildung 4: HERMES Phasenmodell SA und SE [Seite 49]
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
42 / 110
4.6.6 HERMES - Ergebnisse
Ein wesentliches Merkmal von HERMES ist die Ergebnisorientierung. Die Ergebnisse
werden durch Aktivitäten in den Arbeitsschritten erzeugt. Für jede Phase gibt es definierte
Ergebnisse. Diese Ergebnisse werden in Form von Dokumenten erstellt. Es gibt auch
Ergebnisse, die während dem gesamten Projekt erstellt und laufend erweitert werden, wie
z.B. das Projekthandbuch.
In Abbildung 5: Ausschnitt Ergebnisse Voranalyse [Seite 62] sind alle Ergebnisse aufgeführt.
Durch das Tailoring werden jeweils nur diejenigen Ergebnisse definiert, die im Projekt
notwendig sind und auch erstellt werden können. Die Ergebnisse werden in jeder Phase
durch eine Aktivität ausgelöst und durch die definierten und zugeordneten Rollen erarbeitet.
weiterentwicklung/stand-des-projektes, Folie 28, letzter Zugriff: 10. Februar 2012 152 vgl. Karl Pfetzing, Adolf Rhode (2009), Ganzheitliches Projektmanagement, ibo Schriftenreihe Band 2, 3.
Auflage, Verlag Dr. Götz Schmidt, Seite 220 153 vgl. Bruno Jenny (2001), Projektmanagement in der Wirtschaftsinformatik, 5. Auflage, vdf Hochschulverlag AG
an der ETH Zürich, Seite 236
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
49 / 110
4.9 COBIT 5
In diesem Kapitel wird auf folgende Dokumente verwiesen:
COBIT 5: The Framework, Exposure Draft154 [COBIT 5: Framework Seite xy]
COBIT 5: Process Reference Guide, Exposure Draft155 [COBIT 5: Process Seite xy]
Der einfachheithalber seien die entsprechenden Fussnoten und Verweise hier einmal
aufgeführt. Im Kapitel wird nur noch auf die entsprechende Seitenzahl verwiesen wenn
referenziert wird. Für den Rest des Kapitels gilt „vgl.“. Alle anderen Referenzen werden mit
Fussnoten aufgeführt.
4.9.1 COBIT - Übersicht
COBIT hat sich als Standard-Framework für die IT-Governance etabliert und steht für
„Control Objektives for Information and related Technologies“.
ISACA/COBIT definieren Governance wie folgt:
„IT-Governance ist die Verantwortung von Führungskräften und Aufsichtsräten und
besteht aus Führung, Organisationsstrukturen und Prozessen, die sicherstellen, dass
die Unternehmens-IT dazu beiträgt, die Organisationsstrategie und -ziele zu erreichen
und zu erweitern“156.
Um den Unternehmungen die Möglichkeit zu geben, ihre Governance und Management-
Ziele zu erreichen wurde das Standard-Framework COBIT durch die ISACA157 und das IT
Governance Institute®158 entwickelt. Das Standard-Framework COBIT 5 wird die Version
COBIT 4.1 in Kürze ablösen, bereits ist der Exposure Draft publiziert. Nachfolgendes bezieht
sich, wenn nichts anderes vermerkt ist, auf die neue Version COBIT 5.
Das COBIT 5 -Framework möchte folgendes erreichen [COBIT 5: Framework Seite 9]:
„Wertschöpfung durch unternehmensbezogene IT“
„Befriedigung der Geschäftseinheiten durch Engagement und Services der IT“
„Arbeiten nach den gültigen Gesetzen, Vorschriften und Policies“
154 COBIT 5: The Framework, Exposure Draft, ISACA 155 COBIT 5: Process Reference Guide, Exposure Draft, ISACA 156 COBIT 4.0, Control Objectives, Management Guidelines, Maturity Models, Deutsche Ausgabe, Organisation:
ITGI, Übersetzung KPMG Österreich (Wien) 157 ISACA Information Systems Audit and Control Association ist eine non-profit-Organisation (Berufsvereinigung
Informatik-Revision, Kontrolle, und Sicherheit) und tritt als Knowledge-Provider für IT Governance, IT Risk Management, IT Assurance und IT Security auf. www.isaca.org, www.isaca.ch.
158 Das IT Governance Institute (Institut für IT-Governance) (ITGI® www.itgi.org ) ist eine nichtkommerzielle unabhängige Forschungseinrichtung, die der Entwicklung von Leitlinien und Modellen zur Unternehmens-Steuerung von komplexen IT-Landschaften gewidmet ist.
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
50 / 110
COBIT ist als allgemeines Framework für alle Arten von Unternehmungen gedacht, inklusive
Non-Profit-Organisationen und dem öffentlichen Sektor. Es erlaubt durch optimales
Ausbalancieren von Gewinn/Wertschöpfung, Risikomanagement und Ressourceneinsatz die
Governance und Management-Ziele der IT zu erreichen.
4.9.2 COBIT 5 - Prinzipien
COBIT 5 basiert auf den folgenden 5 Prinzipien [COBIT 5: Framework Seiten 10-15]:
1. Prinzip: Integrator Framework
COBIT 5 deckt den gesamten Unternehmensbereich ab und positioniert sich als Framework
mit der Möglichkeit, andere Frameworks, Standards oder „Best Practices“ zu integrieren.
COBIT 5 will das übergreifende Regelwerk sein, mit Guidelines in einer allgemein
verständlichen Sprachregelung.
Es beinhaltet bereits die von der ISACA publizierten Standards wie COBIT 4.1, Val IT159,
Risk IT160, BMIS161, ITAF162.
COBIT 5 soll die konsistente Knowledge-Basis sein, dies auch für zukünftige Entwicklungen.
Aus dieser Knowledge-Basis sollen auch Auszüge für spezielle Themen gemacht werden
können.
2. Prinzip: Stakeholder-Value
Jedes Unternehmen muss Gewinne machen und eine Wertschöpfung aufweisen um zu
überleben und damit ihren Stakeholdern zu dienen. Gewinne oder auch Werte müssen
mittels optimierter Ressourcen und kalkulierbarem Risiko erzielt werden. Governance
bedeutet auch, Vereinbarungen und Entscheidungen zwischen verschiedenen Stakeholdern
herbeizuführen, welche nicht immer die gleichen Interessen haben. Es muss darum die
folgende Frage gestellt werden: Für wen ist der Gewinn und das Risiko und welche
Ressourcen sind dazu erforderlich?
159 VAL IT ist das Governance Framework von ISACA zur Steuerung und Messung des Wertebetrags der IT an
das Business (Value Delivery). http://www.isaca.org/Knowledge-Center/Val-IT-IT-Value-Delivery-/Pages/Val-IT1.aspx, letzter Zugriff: 22. Februar 2012
160 RISK IT ist das Governance Framework von ISACA zur Identifizierung, Messung und Steuerung der IT bezogenen Risiken (Risk Management). http://www.isaca.org/Knowledge-Center/Risk-IT-IT-Risk-Management/Pages/Risk-IT1.aspx, letzter Zugriff: 22. Februar 2012
161 BMIS ist das Business Model for Information Security von der ISACA. http://www.isaca.org/Knowledge-Center/BMIS/Pages/Business-Model-for-Information-Security.aspx, letzter Zugriff: 22. Februar 2012
162 ITAF ist das Framework für IT-Audit und IT-Assurance, http://www.isaca.org/Knowledge-Center/ITAF-IT-Assurance-Audit-/Pages/default.aspx, letzter Zugriff: 22. Februar 2012
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
51 / 110
3. Prinzip: Fokus auf das Geschäft
Der Fokus liegt auf den Unternehmenszielen und den zugehörigen Gewinnen, Risiko- und
Ressourcen-Optimierungen. COBIT 5 bezieht die Governance und das Management der IT
auf eine unternehmensweite, „end-to-end“-bezogene Perspektive. Die „end-to-end“-
Perspektive wird unterstützt durch den Einbezug von allen kritischen Geschäftselementen
wie z.B. Prozesse, Organisationsstrukturen, Policies, Kultur etc.
Weil jede Organisation unterschiedlich funktioniert und organisiert ist und auch andere
Zielsetzungen und Strategien hat, wurde COBIT wie folgt aufgebaut:
Kaskadierung der Ziele. Dies erlaubt jeder Unternehmung, ihre spezifische Situation, von
den generellen Zielsetzungen und Strategien bis hin zu den spezifischen IT-Zielen zu
definieren.
Die Qualitätsziele bezogen auf die Enabler sind in einem grossen Ausmass
kontextabhängig
4. Prinzip: Enabler Based
Neben den Governance-Zielen basiert COBIT auf „Governance Enabler“ und „Governance
Scope“.
Unter „Governance Enabler“ versteht man diejenigen Ressourcen, Services, IT Infrastruktur,
Vorgaben, Prinzipien, Prozesse, Standards etc., welche das Unternehmen befähigen,
verantwortungsvoll zu führen und die Unternehmensziele zu erreichen.
Unter „Governance Scope“ ist der Umfang zu verstehen, für den Governance gültig sein soll.
Für COBIT 5 ist das die IT. Daraus ist aber ebenfalls ersichtlich, dass man mit COBIT auch
andere Unternehmens-Bereiche abdecken könnte.
Die Rollen, Aktivitäten und Abhängigkeiten definieren desweiteren, „wer“ in die Governance
involviert ist, „wie“ man involviert ist, „was“ man genau machen muss und „wie“ die
Interaktionen innerhalb des Governance-Systems sind.
5. Prinzip: Governance und Management -Struktur
In jeder Unternehmung haben die verschiedenen Stakeholder andere oder teilweise
widersprüchliche Anforderungen an Gewinn, Risiko und Ressourcen. Deshalb trennt COBIT
5 als Schlüsselelement strikte zwischen „Governance“ und Management“. Diese beiden
„Disziplinen“ haben verschiedene Aktivitäten, denn sie benutzen unterschiedliche
Organisationsstrukturen und dienen unterschiedlichen Zwecken.
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
52 / 110
Governance-Struktur
Für die unterschiedlichen Stakeholder bedeutet Governance eine Organisation zu haben, die
alle Tätigkeiten eine Unternehmung zu führen, strukturiert. Zu diesen Tätigkeiten gehören:
Definieren der Richtung, Überwachung der Compliance und Fortschritte beim Erreichen der
spezifischen Unternehmensziele. Dazu werden Frameworks, Prinzipien, Policies,
Sponsorships, Strukturen und Entscheidungsmechanismen sowie Prozesse und Practices
eingesetzt.
In den meisten Unternehmungen nimmt diese Stellung die Geschäftsleitung unter der
Leitung des Geschäftsführers (CEO, Chief Executiv Officer) ein.
Management-Struktur
Management ist die ausführende Stelle (Executive) welche durch eine übergeordnete
Instanz geführt wird. Management beinhaltet Planung, Durchführung, Organisation und
Überwachung von operationellen Aktivitäten zur Erreichung der Ziele der übergeordneten
Governance.
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
53 / 110
4.9.3 COBIT 5 - Ziel-Kaskade
Abbildung 9: Ziel-Kaskade (Eigene Darstellung nach [COBIT 5: Framework Seite 24])
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
54 / 110
Die Prinzipien von COBIT 5 werden hierarchisch in einer „Ziel-Kaskade“ dargestellt,
eigentlich ein Top-Down-Approach. Mit diesem werden die Anforderungen der Stakeholder in
Prozesse und schlussendlich in Kontrollziele hinuntergebrochen.
Die Reihenfolge lautet:
1. Stakeholder-Bedürfnisse
2. Governance-Anforderungen
3. Unternehmens-Ziele
4. IT-Ziele
5. Prozesse und Prozess-Ziele
Stakeholder Bedürfnisse Governance Anforderungen
Die Stakeholder-Bedürfnisse werden den drei Governance-Anforderungen
Gewinn/Wertschöpfung, Risiko-Management und Ressourcen-Optimierung zugeordnet.
Governance-Anforderungen Unternehmens-Ziele
COBIT hat 17 generische Unternehmensziele definiert und den BSC (Balanced Score Card)
Dimensionen163 Finanz-, Kunden-, Prozess- und Potential-Perspektive zugeordnet. Diese 17
Ziele werden als Matrix zu den Governance-Anforderungen dargestellt und gewichtet. Die
meisten Unternehmensziele können diesen generell gefassten Zielsetzungen zugeordnet
werden.
Bei der Zuordnung steht ein „P“ für eine starke Beziehung und ein „S“ für eine zweitrangige
Beziehung.
D.h. dass alle Unternehmensziele, die bei den definierten Governance-Anforderungen mit P
bewertet sind auch priorisiert werden sollten.
163 Robert S. Kaplan, David P. Norton; The Balanced Scorecard: Translating Strategy into Action; Harvard
University Press, zitiert in: COBIT 5, Process Reference Guide, ISACA, Seite 20
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
55 / 110
Enterprise Goals Mapped to Governance Objectives
Unternehmen mit der Governance-Priorität auf „Ressourcenoptimierung“ müssten die Ziele
9., 11, 12, 14 und 16 priorisieren (Markiert in der Spalte „Resource Optimisation“ mit „*“).
BSC Dimensions
Enterprise Goals Governance objectives
Benefits Realisation
Risk Optimisation
Resource Optimisation
Financial 1. Stakeholder value of business investments
P
2. Portfolio of competitive products and services
P S
3. Managed business risks (Safeguarding of assets)
P S
4. Compliance with external laws and regulations
P
5. Financial transparency P S
Customer 6. Customer orientied service culture P S
7. Business service continiuit and availability
P
8. Agile response to a change in business environment
P S
9. Information-based strategic decision making
P P P*
10. Optimisation of service delivery cost
P S
Internal 11. Optimisation of business processs funcionality
P P*
12. Optimisation of business process cost
P P*
13. Managed busines change programme
P P S
14. Operational and staff productivity P P*
15. Complinace with internal policies P
Learning and growth
16. Skilled and motivated people S S P*
17. Product and business innovation culture P
Tabelle 1: Anforderungen und Ziele
(eigene Darstellung nach [COBIT 5: Process Seite 4])
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
56 / 110
Unternehmens-Ziele IT-bezogene Ziele
COBIT hat von jedem Unternehmensziel ein entsprechendes IT-bezogenes Ziel abgeleitet
und definiert, siehe Abbildung 10. Anzumerken ist, dass ein Unternehmensziel nicht nur
mittels IT-Zielen erreicht werden kann, denn COBIT bezieht sich ausschliesslich und nur auf
die IT-bezogenen Aspekte.
IT-Bezogene Ziele
Financial 1. Alignment of IT and business strategie
2. IT Compliance and support for business compliance with external laws and regulations
3. Commitment of executive management for making IT related decisions
4. Managed IT-related business risks
5. Realised benefits from IT enabled investments and services portfolio
6. Transparency of it costs, benefits and risk
Customer 7. Delivery of it services in line with business requirements
8. Adequate use of applications, information and technology solutions
Internal 9. IT Agility
10. Security of information and processing infrastructure and applications
11. Optimisation of it assets, resources and capabilities
12. Enablement and support of business process by integrating appications and technology intobusiness processes
13. Delivery of prorammes on time, on budget and meeting requirementes and quality standards
14. Availability of reliable and useful information
16. Competent and motivated IT personnel
Learning and growth 17. Knowledge, expertise and initiatives for non business innovation
Tabelle 2: IT-bezogene Ziele
(eigene Darstellung nach [COBIT 5: Process Seite 5])
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
57 / 110
In Tabelle 3 erfolgt nun das Mapping der IT-Ziele zu den Unternehmenszielen als kleiner
Ausschnitt. Die komplette Mapping-Tabelle ist hier [COBIT 5: Process Seite 215] zu finden.
Die Zuordnung jedes dieser Ziele wird in Relation zu den Unternehmenszielen wiederum in
einer Matrix dargestellt und mit „P“ (starke Beziehung) oder mit „S“ (schwache Beziehung)
gewichtet.
Betreffend Priorität der Ressourcen, müssen die gleichen Unternehmensziele wie beim
Mapping von Governance-Anforderungen zu Unternehmenszielen priorisiert werden. Die IT-
bezogenen Ziele erhalten danach auch eine entsprechende Priorität.
IT related goals Enterprise goals
Compliance with
external laws and regulation
Managed business
risks
Portfolio of competitive
products and
services
Corporate 1. Alignment of IT and business strategie
S S
2. IT Compliance with external laws and regulations
P S
3. Commitment of executive management for making IT related decisions
S S
4. Managed IT-related business risks
S P
5. Realised benefits from IT enabled investments and services portfolio
P
Tabelle 3: Ausschnitt IT- vs Unternehmensziele
(eigene Darstellung nach [COBIT 5: Process Seite 215])
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
58 / 110
IT-bezogene Ziele IT-Prozesse
In der Matrix zwischen IT-Zielen und COBIT 5-Prozessen werden die Relationen wiederum
mit P und S gewichtet. Somit sind für alle IT-bezogenen Ziele die Prozesse nach deren
Wichtigkeit geordnet. Die komplette Mapping-Tabelle ist hier [COBIT 5: Process Seite 217]
zu finden.
4.9.4 COBIT 5 - Disclaimer
Im COBIT-Standard wird darauf verwiesen, dass die Zuordnungen innerhalb der Ziel-
Kaskade nicht eins-zu-eins übernommen werden sollten. Jedes Unternehmen hat
verschiedene Prioritäten und Ziele, beides kann ändern im Laufe der Zeit. Das Mapping
widerspiegelt auch nicht die Branche oder Grösse einer Unternehmung. Darauf verweist das
Framework ziemlich klar mit „does not contain the ultimate and most complete answer“ und
auch „users should not attempt to use it in a purely mechanistic way“ [COBIT 5: Framework
Seite 6].
Das Framework ist demzufolge als Anweisung mit „klugen“ Beispielen zu verstehen um IT-
Governance in der eigenen Unternehmung/IT/Projekten umzusetzen. Es ist somit eine
Guideline.
IT related goals
Alig
nmen
t of
IT a
nd
busi
ness
st
rate
gie
IT c
ompl
ianc
e w
ith e
xter
nal
law
s an
d re
gula
tions
Com
mitm
ent
of e
xecu
tive
man
agem
ent
for
mak
ing
IT
rela
ted
Eva
luat
e, D
irect
and
M
onito
r
EDM1 Set and Maintain the Governance Framework
P S P
EDM2 Ensure value optimisation P S
EDM3 Ensure risk optimisation S S S
EDM4 Ensure esource optimisation S S
EDM5 Ensure Stakeholder transparency
S S P
Tabelle 4: Auszug IT-Ziele vs Prozesse
(eigene Darstellung nach [COBIT 5: Process Seite 217])
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
59 / 110
4.9.5 COBIT 5 - Enabler-Modell
Unter „Enabler“ versteht COBIT „anything that can help to achieve the governance objectives
of the enterprises“ [COBIT 5: Framework Seite 28]. Das können Ressourcen, Informationen,
aber auch Menschen sein. COBIT 5 hat sieben Kategorien von Enablern definiert:
Prozesse Beschreibung von Practices164 und Aktivitäten um ein
Ergebnis zu erreichen, dass die IT-Ziele unterstützt.
Prinzipien und Policies Werden benötigt, um die gewünschten
Handlungsweisen in das tägliche Management
umzusetzen.
Organisationsstrukturen Sind die Entscheidungseinheiten einer Organisation
Fähigkeiten und Kompetenzen Sind verbunden mit Menschen und sind erforderlich für
das Fällen von Entscheiden und Durchführen von
Aktivitäten.
Kultur und Handlungsweisen Werden oft unterschätzt als Erfolgsfaktor für
Governance und Management.
Informationen Ist erforderlich, um die Organisation am Laufen zu
halten. Auf operativer Ebene ist die Information oft das
Wichtigste in einer Unternehmung.
Service Fähigkeiten Beinhaltet Infrastruktur, Technologie, Applikationen die
der Unternehmung Informationen und deren
Verarbeitung sicherstellen.
Das COBIT Framework hat ein generisches Modell für alle Kategorien von Enablers, so dass
alle miteinander kommunizieren können.
Systemic Governance
In einer Unternehmung können korrekte Entscheidungen nur getroffen werden, wenn die
„systemic nature“, also „natürliche Systematik“, der Governance vorhanden ist. Das
bedeutet, dass man die Stakeholder-Anforderungen nur dann erfüllen kann, wenn alle
Enabler berücksichtigt werden. Dafür muss die Unterstützung des Top-Managements
vorhanden sein.
164 Practices wird mit Praktiken übersetzt und synonym verwendet. Es wird auch als Erfolgsmethode bezeichnet,
http://de.wikipedia.org/wiki/Best_Practice, letzter Zugriff: 27. Januar 2012 vgl. auch Online-Verwaltungslexikon olev.de: „Best Practice“ bedeutet: „hervorragende Praxis“ und „Lösungen oder Verfahrensweisen, die zu Spitzenleistungen führen und als Modell für eine Übernahme in Betracht kommen“ http://www.olev.de/b/best-practice.htm, letzter Zugriff: 27. Januar 2012 Nach Duden heisst es „bestmögliche Methode, höchster Standard“, https://10920.lip.e-content.duden-business.com/lip-suche/-/lip_article/D1/2021303, letzter Zugriff: 27. Januar 2012
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
60 / 110
Das Enabler-Modell
Jeder Enabler weist die fünf gleichen Elemente auf [COBIT 5: Framework Seiten 30-32]:
Stakeholders Jeder Enabler hat seine Stakeholder. Diese können sowohl
intern als auch extern sein.
Goals & Metrics Jeder Enabler hat eigene Ziele, die zu erreichen sind. Bei
Prozessen sind dies die Prozess-Ziele, für Information gibt es
verschiedene Qualitäts-Kriterien. Ziele können qualitäts- oder
effizienz-basierend sein. Ziele sollten die Governance
Anforderungen bezüglich Gewinn, Risiko und Ressourcen „im
Auge“ haben. Messwerte werden den Ziele zugeordnet. Sie
messen die Zielerreichung der Enabler.
Life Cycle Jeder Enabler hat einen Lifecycle mit Beginn, Betrieb und
Ende.
Good Practices Für jeden Enabler gibt es „good practices“, d.h. Beispiele oder
Vorschläge wie man Enabler am besten implementieren kann.
Attributes Ausser dem Capability-Attribute hat jeder Enabler seine eigene
Attribute. Das Capability-Attribute basiert auf der Norm ISO/IEC
15504 und erlaubt, die Enabler in einem Reifegradmodell zu
beschreiben. Für das Erreichen der Governance nach COBIT
muss der Level 1 „Performed“ erfüllt sein [COBIT 5: Framework
Seite 49]. Damit haben die Enabler ihre Ziele erreicht und die
„good practices“ angewendet. In der Draft Version existiert das
Reifegrad-Modell nur für den Enabler „Prozess“.
Abbildung 10: Enablermodell, (Eigene Darstellung nach [COBIT 5: Framework Seite 30])
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
61 / 110
Das COBIT Reifegrad Modell
COBIT 5 lehnt sich in dieser Beziehung neu an die ISO/IEC 15504 Norm an, auch als SPICE
bezeichnet (Software Process Improvement and Capability Determination). In den
Grundzügen bewirkt die ISO-Norm das gleiche wie CMMI, es ist allerdings in dem neusten
Release auf Prozesse allgemeiner Natur zugeschnitten165. In COBIT sind die Capability
Levels wie folgt definiert [COBIT 5: Framework Seite 46]:
0. Incomplete process
The process is not implemented or fails to achieve its process purpose. At this level,
there is little or no evidence of any systematic achievement of the process purpose.
1. Performed process (one attribute)
The implemented process achieves its process purpose.
2. Managed process (two attributes)
The previously described performed process is now implemented in a managed
fashion (planned, monitored and adjusted) and its work products are appropriately
established, controlled and maintained.
3. Established process (two attributes)
The previously described managed process is now implemented using a defined
process that is capable of achieving its process outcomes.
4. Predictable process (two attributes)
The previously described established process now operates within defined limits to
achieve its process outcomes.
5. Optimising process (two attributes)
The previously described predictable process is continuously improved to meet
relevant current and projected business goals.
Höhere Level können nur erreicht werden, wenn der vorhergehende Level zu 100% erreicht
wurde.
165 vgl. Ron S. Kenett, Emanuel R. Baker (2010), Process Improvement and CMMI for Systems and Software,
CRC Press, Taylor & Francis Group, Boca Raton, London, New York, Seiten 100-109
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
62 / 110
4.9.6 COBIT 5 - Prozesse
Jede Unternehmung besitzt eine unterschiedliche Anzahl und Art von Prozessen. COBIT
schlägt hierzu eine Aufteilung in Governance und Management-Prozesse vor und
berücksichtigt alle, normalerweise in der IT gefundenen, Prozesse. Trotzdem sollte jede
Unternehmung die eigenen Prozesse mit der eigenen Situation berücksichtigen.
COBIT teilt die Prozesse in die beiden Domains Government und Management ein nach
dem 5. Prinzip gemäss Kapitel „COBIT 5 - Prinzipien", Seite 50.
In COBIT bilden die Prozesse den gesamten Scope der Business und IT-Aktivitäten bezogen
auf die Governance und das Management ab. Das COBIT 5 Prozess Referenz Modell ist der
Nachfolger von COBIT 4.1 mit der Integration aller Risk IT- und Val IT- Prozessmodelle.
Es sind 36 Prozesse definiert und die Aufteilung in die beiden Domains sind:
Governance of Enterprise IT Evaluate, Direct and Monitor (EDM) 5 Prozesse
Management of Enterprise IT Align, Plan and Organise (APO) 12 Prozesse
Build, Acquire and Implement (BAI) 8 Prozesse
Deliver, Service and Support (DSS) 8 Prozesse
Monitor, Evaluate and Inform (MEI) 3 Prozesse
Abbildung 11: Prozess-Modell (Eigene Darstellung nach [COBIT 5: Framework Seite 35])
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
63 / 110
Abbildung 12: Prozess-Übersicht (Screenshot aus [COBIT 5: Process Seite 15])
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
64 / 110
4.9.7 Aufbau COBIT-Dokumentation
Das Framework weist 3 Kern-Bände166 auf:
Volume 1: The Framework:
Der erste Band hat als Zielpublikum die Stakeholders. Es deckt die Bedürfnisse der
Governance und des IT-Managements ab und soll die Übersicht über die Grundprinzipien
von COBIT 5 geben sowie die Implantation und Migration beschreiben.
Volume 2: Process Reference Guide:
Der zweite Band beinhaltet die Grundprinzipien von COBIT 5, das Prozess Referenz Modell
und die Beschreibung der Prozesse.
Volume 3: Implementing & Continually Improving Enterprise Governance of IT:
Der dritte Band ist eine Weiterentwicklung von COBIT 4.1 Lifecycle Approach (Implementing
and Continually Improving IT Governance) und beinhaltet die Implementierung und die
Migration von der COBIT-Version 4.1 auf 5.
Weitere Volumes
Es ist geplant, für jedes Sachgebiet eine eigenes Volume herauszugeben.
COBIT for Security
COBIT for Risk
COBIT for Value
COBIT for Assurance
COBIT for Privacy
COBIT for Small to Medium Enterprises
COBIT 5 Capability Assessment Guide
166 Das „Volume“ im englischen wird teilweise als „Bände“ ins Deutsche übersetzt. Der Begiff Volume wird
aufgrund der englischen Original-Quellen trotzdem benutzt.
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
65 / 110
5 ANFORDERUNGEN
In diesem Kapitel werden die Anforderungen genauer untersucht. Insbesondere müssen die
Ziele bezüglich Auditierung des HERMES 5-Projektes mit den Kontroll-Aufgaben der EFK
untersucht werden. Im Mittelpunkt steht grundsätzlich die Auditierung nach COBIT. Auf
Bundesebene wird diese durch die EFK vorgenommen.
5.1 Anforderung gemäss Detailstudie HERMES 5
Die Detailstudie ist das Ergebnis der Konzeptphase. Am 1. September 2011 wurde durch
den Projektausschuss die Phase Realisierung freigegeben 167.
In der Detailstudie168 vom Projekt HERMES 5 wird unter „Audits und Bezug zu COBIT“ die
folgende Anforderung gestellt: „Beschreibung der Minimalanforderungen, die ein Projekt
erfüllen muss, um einen Audit basierend auf COBIT erfolgreich bestehen zu können.
Identifikation der für ein Audit benötigten HERMES-Minimal-Ergebnisse“. Unter
„Audittauglichkeit“ wird folgendes verlangt: „Mit HERMES abgewickelte Projekte müssen
audittauglich sein“. Die Minimalanforderungen aus Sicht Auditing der EFK basierend auf
COBIT müssen klar dokumentiert sein. Es soll nicht unterstützt werden, dass in den
Projekten unnötiger Aufwand für die Projektarchäologie geleistet wird (Karl Gasser)“.
Daraus ist ersichtlich, dass die notwendigen Unterlagen um ein Audit zu bestehen, durch die
bestehende Projekt-Abwicklung automatisch erstellt werden müssen. Der Aufwand für die
Projektleitung für die Vorbereitung auf das Audit soll klein gehalten werden. Anders gesagt,
diese Anforderung bedeutet, dass ein Audit jederzeit stattfinden kann, weil alle Dokumente
bereits bestehen und das Projekt permanent nach den Governance-Anforderungen geführt
wird.
HERMES 5 muss demzufolge so gestaltet sein, dass die Vorgaben von COBIT als Teil
Ob COBIT das offizielle Referenzwerk für IT-Governance bei der EFK darstellt, kann nicht
gesagt werden.
Der Fachbereich 4 erfüllt u.a. seine Aufgaben unter Anwendung von Standards und
Methoden wie z.B. COBIT und die Revisoren sind CISA-Zertifiziert174. Auch die gemäss
Kapitel 5.2.3 erstellten Empfehlungen verweisen auf COBIT.
Weiter wird im Bericht „Business Continuity Management“175 COBIT als ein Framework
positioniert, dass sich an „professionelle IT-Prüfer“ wendet. Und bereits 2004 schreibt die
EFK in ihrem Audit-Newsletter176: „COBIT gilt heute unbestrittenermassen als weltweit
führendes Instrument auf dem Gebiet der IT-Governance“.
174 CISA: Certified Information Systems Auditor, http://www.isaca.org/Certification/CISA-Certified-Information-
Systems-Auditor/Pages/default.aspx, letzter Zugriff: 22. Februar 2012 175 http://www.efk.admin.ch//images/stories/efk_dokumente/publikationen/querschnittspruefungen/
QP%20%2810%29/9217BE_Gesamtbericht_QP_BCM_publ.pdf, Seite 4, letzter Zugriff: 22. Februar 2012 176 vgl. http://www.efk.admin.ch/index.php?option=com_content&view=article&id=188%3Aaudit-
letters&catid=120%3Ajahresberichte&Itemid=189&lang=de, letzter Zugriff: 22. Februar 2012
Abbildung 13: Schlüsseldokumente EFK pro Phase [Quelle: EFK]
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
69 / 110
Im Interview mit einem Mitarbeiter der EFK, Revisor im Fachbereich 4, wird angegeben, dass
für Audits eigene Checklisten entwickelt wurden, die u.a. auf COBIT basieren. Es werden,
unter Berücksichtigung von Anforderungen aus CobiT, jedoch auch andere Quellen
verwendet, insbesondere aufgrund von Risikoüberlegungen. Die EFK führt auch
Projektprüfungen durch um festzustellen, ob HERMES eingehalten wird.
Daraus darf jedoch lediglich gefolgert werden, dass COBIT bei der EFK einen starken
Stellenwert hat und als Referenz gelten KANN. Es wird aber sicher erforderlich sein, dass
eine Kompatibilität von HERMES zu COBIT und nur zu COBIT bei der EFK abzusichern ist.
5.3 Anforderungen aus COBIT
COBIT selbst stellt keine Anforderungen. Hier geht es um Anforderungen, welche sich
daraus ergeben, weil man COBIT als Referenz benutzt. Man kann das auch als
Vorbedingungen oder Rahmenbedingungen für HERMES auffassen.
COBIT selbst schlägt vor, dass man die Ziel-Kaskade für das eigene Unternehmen erstellt.
Das Framework [COBIT 5: Framework Seite 6] verweist ziemlich klar mit „does not contain
the ultimate and most complete answer“ und auch „users should not attempt to use it in a
purely mechanistic way but rather as a guideline“ darauf hin. Dies soll als Aufforderung
betrachtet werden, um mit dem Framework die Unternehmens-Ziele, IT-Ziele, Prozesse und
Enabler selbst zu definieren. Damit kann die Governance unternehmensspezifisch
angewendet werden.
Die Anforderung wäre demnach, COBIT auf das Unternehmen, in diesem Fall die
Verwaltung der Schweizerischen Eidgenossenschaft, anzupassen und erst diese Version als
Vergleich mit HERMES zu benutzen.
Wie bereits für COBIT 4.0 hat sich die ISACA auf Research-Arbeit177 der Antwerp
Management School178 bezogen um die Ziel-Kaskade, Unternehmens- und IT-Ziele, sowie
Prozesse zu definieren [COBIT 5: Process Seiten 6, 214, 216] respektive weiterzu-
entwickeln. Die Prozesse und Zielsetzungen unterliegen einem generischen Ansatz.
Demzufolge müsste es auch zulässig sein, die Voraussetzungen innerhalb HERMES auf
diesem generischen Ansatz aufzubauen. HERMES gilt auch als Standard mit einem
generischen Ansatz und kann mit den gleichen Vorbehalten wie COBIT publiziert werden.
Diese Annahme müsste noch weiter untersucht werden, in dieser Arbeit wird darauf
177 vgl. Win Van Grembergen, Steven De Haes, Hilde van Brempt (2008), Understanding How Business Goals
Drive IT Goals, University of Antwerp Management School im Auftrag vom IT Governance Institute ITGI™ 178 Antwerp Management School, http://www.antwerpmanagementschool.be/EN/search.aspx?q=cobit, letzter
Zugriff: 10. Januar 2012
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
70 / 110
verzichtet. In den geführten Recherchen/Interviews war man sich nicht ganz einig: „My
advice always is that organizations have to define their own business goals and IT goals” vs
“Aus dieser Sicht sind die Ziele und Prozesse sicher repräsentativ, jedoch noch nicht
operationalisiert“. Wobei „My advice“ eine eher schwächere Form ist und das Übernehmen
der Ziele nicht als Fehler ausschliesst.
Es wird daher angenommen, dass der generische Ansatz gültig ist und die in COBIT 5
verwendete Ziel-Kaskade verwendet werden kann. Die Auditierbarkeit von HERMES wird
aufgrund des aktuellen „Exposure Draft“ untersucht. Änderungen zum publizierten Standard
COBIT 5 müssen angepasst werden.
COBIT impliziert ausserdem, dass für die Prozesse der Reifegrad 1 erreicht sein muss: „If a
required process outcome is not consistently achieved, the process does not meet its
objective and needs to be improved“ [COBIT 5: Framework Seite 50].
5.4 Zusammenfassung der Anforderungen
Aufgrund den Zielen und der Informationen der EFK kann gefolgert werden, falls HERMES 5
die Kompatibilität zu COBIT herstellt respektive ein Projekt-Audit der EFK auf COBIT basiert,
dass mit der Erfüllung der Anforderungen an HERMES 5 ein entsprechendes Audit
bestanden werden kann.
Es gibt natürlich weitere Voraussetzungen. Insbesondere müssen die Ergebnisse und die
Projektarbeit in qualitativer Hinsicht ebenfalls genügend sein. Auch muss das Audit-Objekt in
einem Zustand sein, mit dem das Audit bestanden werden kann.
Es gilt aber im Verlaufe der Entwicklung von HERMES 5 zu klären, dass die EFK mit COBIT-
kompatiblen Ergebnissen ein Audit durchführen kann respektive dies so bestanden werden
kann. Es dürfen für das Audit keine weiteren Methoden oder Standards angewendet werden,
deren Inhalte nicht durch COBIT abgedeckt sind.
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
71 / 110
6 DER MASSSTAB: COBIT
6.1 COBIT als Referenz für ein Audit
Wie kann COBIT als Referenz gelten?
Unter Berücksichtigung von Kapitel 4.9.4 (Ziel-Kaskade-Disclaimer) und verschiedenen
Stellungnahmen kann man davon ausgehen, dass die Beschreibungen der IT-Ziele und die
Auswahl der Haupt-Prozesse [COBIT 5: Process Seiten 105 - 114] für Programme und
Projekte mit Activities, Input und Output als generischer Ansatz für eine Definierung der
Ergebnisse von HERMES ausreichen, um ein Audit nach den Grundsätzen der IT-
Governance nach dem Framework COBIT zu bestehen. Vorbehalten bleibt immer, dass die
bessere Lösung darin besteht, die Ziel-Kaskade organisations-spezifisch zu erarbeiten und
danach die HERMES-Ergebnisse auf diese Ziele und Prozesse auszurichten.
Bestandteile des Programmes vs Projekt
Bei einem Audit mit COBIT als Referenz wird ein Auditor in der Planung vorsehen, eine
Checkliste abzuarbeiten, auf der ein Prüfungsteil als obligatorische Kontrolle erfolgen wird.
Dabei wird es noch zufällige Prüfaspekte geben (Stichproben), die im Auditplan ersichtlich
sein werden.
Die obligatorischen Prüfpunkte werden einzelne oder alle Praktiken aus dem Prozess
“Manage Programmes and Projects” sein. Da COBIT nicht explizit nach Projekt und
Programm trennt, müssen die Prüfpunkte betreffend Programme auch dann erfüllt werden,
wenn es nur ein einzelnes Projekt ist. Ausnahme ist, wenn es nur die Organisation des
Programmes selbst betrifft.
Beispiel:
In Practice BAI01.02 “Initiate a programme” ist “Develop a detailed business case for a
programme” Bestandteil der Aktivität 3 [COBIT 5: Process, Seite 108].
Diese Aktivität fehlt bei einem reinen Projekt ohne Programme und muss deshalb auch für
ein Projekt aufgenommen werden.
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
72 / 110
Input und Output
Der Prozess “Manage Programmes and Projects” beinhaltet auch Inputs aus anderen
Prozessen. Ein Auditor wird vermutlich diese Prozesse zufällig auswählen und überprüfen.
Es kann aber auch sein, dass gewisse dieser “Input”-Prozesse in die Liste der
obligatorischen Prüfpunkte aufgenommen werden. Somit wird eine sorgfältige Analyse der
“Input-Prozesse” notwendig sein, um zu erkennen, welche Aspekte in HERMES als Ergebnis
aufgeführt werden müssten. Wenn das Unternehmen COBIT als Ganzes eingeführt hat,
sollte dies kein Problem darstellen. Ansonsten muss das Projekt sicherstellen, dass diese
Input-Prozesse respektive dessen Resultate korrekt ausgeführt sind.
Beispiel:
In Practice BAI01.01 “Maintain a standard approach for programme and project
management” besteht der Input von APO10.04 “Identified supplier delivery risks” [COBIT 5:
Process, Seite 108]. APO10 ist der Prozess “Manage suppliers” und Practice APO10.04 ist
“Manage supplier risk.“
Wird dieser Prozess nicht nach COBIT ausgeführt muss das Projekt sicherstellen, dass der
Output „Identified supplier delivery risks“ und „Identified contract requirements to minimise
risk“ korrekt erfolgt ist. Dies aber natürlich nur für Lieferanten des Projektes und nicht für alle
Lieferanten des Unternehmens.
Referenz
Was gilt nun als Referenz?
Als Referenz bei COBIT gelten die Praktiken der Prozesse. Jede Praktik hat Aktivitäten,
Input und Output. Ein Auditor wird aber nicht nur die Outputs prüfen, sondern auch ob die
Aktivitäten korrekt durchgeführt wurden. D.h. nicht nur das Ziel, sondern auch „der Weg zum
Ziel“ wird geprüft.
Da sich die Prozesse und Aktivitäten aus der Ziel-Kaskade herleiten, sind alle Anforderungen
und Zielsetzungen entsprechend erfüllt.
6.2 Governance-Aspekte
Was ist Governance für COBIT? Nach [COBIT 5: Framework, Seite 9] bedeutet Governance
für COBIT: Einen optimalen Wert von Information und Technologie zu erhalten durch ein
Ausbalancieren von Nutzen, Risiko- und Ressourcen-Management.
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
73 / 110
Der Originaltext lautet: “COBIT 5 allows enterprises to achieve their governance and
management objectives, i.e., to create optimal value from information and technology by
maintaining a balance amongst realising benefits, managing risk and balancing resources.”
Das beginnt bei den Stakeholder-Bedürfnissen, geht über Governance-Anforderungen zu
den Unternehmenszielen, IT-Zielen und zu den Prozessen und Aktivitäten.
Governance bedeut, wie in Kapitel 4.1, Governance, ausgeführt: “Verantwortungsvolle
Führung, Steuerung und Kontrolle“. Und genau diese Punkte werden durch das Einhalten
der Prozesse, dem Durchführen der Aktivitäten und dem Erstellen des „Output“ erfüllt.
6.3 Controlling
Wie im Kapitel 4.3 ausgeführt, sollte jedes Projekt ein Controlling besitzen. Wenn „Führung
und Kontrolle“ als Aufgabe des Controllings definiert sind, so können neben den klassischen
Werten wie Kosten und Termine auch die Teile der Governance dazu gehören.
Wenn die Annahme weiterhin gilt, dass ein Audit auf Basis COBIT bestanden werden muss,
so ist es unabdingbar, dass sich das Controlling damit befasst und sicherstellt, dass alle
geforderten Ergebnisse in der benötigten Qualität erstellt werden.
COBIT selbst führt aus [COBIT 5: Framework Seiten 14, 34]: „Management is responsible for
execution within the direction set by the guiding body or unit. Management is about planning,
building, organising and controlling operational activities to align with the direction set by the
governance body”. Das deutet auf ein Controlling hin. Wie in Kapitel 4.9.2, “5. Prinzip”,
dargelegt, unterscheidet COBIT zwischen der Governance- und Management-Struktur.
Aufgrund der Erklärungen muss man feststellen, dass der Ausdruck “Management” benutzt
wurde, aber es war nicht die Management-Struktur alleine gemeint. Auf Seite 34 wird erklärt:
“Given the role of governance - to evaluate, direct and monitor“. Dadurch wird klar, dass mit
Monitor das Controlling seitens der Governance-Struktur gemeint sein muss. Und da auch
die Management-Struktur eine Controlling-Instanz besitzt (“Plan - Build - Run - Monitor”
[COBIT 5 The Framework Seite 35]) muss es ein Controlling für die Governance geben. Der
Prozess MEA02 “Monitor System of internal control” ist u.a. dafür zuständig.
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
74 / 110
6.4 Ergebnisse, Vorgehen, Rollen
Zielsetzung aus HERMES:
Lösungsansätze aufzuzeigen, wie die minimalen Ergebnisse, Rollen und
Vorgehen aussehen müssen, um ein Audit über die Governance nach COBIT
erfolgreich zu erfüllen.
Gemäss diesen muss untersucht werden, ob zu den Ergebnissen auch die Rollen und das
Vorgehen speziell vorgesehen werden muss, entweder als zusätzliche Ergebnisse oder als
Spezifizierung der Ergebnisse.
Kann COBIT damit umgehen respektive was verlangt hier COBIT?
Rollen
Die Definition der Rollen werden in COBIT behandelt. Sowohl in APO01 „Define the
Management Framework for IT“ mit „Define the focus, roles and responsibilities of each
function within the IT“, als auch speziell in APO07 „Manage Human Ressources“ in
APO07.03 „Maintain the skills and competencies of personnel“ werden Anforderungen an
das Management bezüglich des Einsatzes und die Ausbildung der Mitarbeiter gestellt.
Für die spezielle Betrachtung des BAI01-Prozesses im Bereich des Projekt-Managements
werden ebenfalls Anforderungen an die „Human Resources“ gestellt.
In BAI01.04 „Develop and maintain the programme plan“ wird ein Input von BAI05.02 “Form
an effective implementation team” vorgegeben. In der Aktivität 2 müssen die Rollen und
Verantwortlichkeiten definiert werden: “Define the roles and responsibilities for all team
members and other interested parties.”
Für die Projektausführung BAI01.12 „Execute a project“ sind die erforderlichen Fähigkeiten
bezogen auf den Einsatzzeitpunkt zu identifizieren “Identify required skills and time
requirements for all individuals involved in the project phases in relation to defined roles”.
Ebenso sind sie zuzuweisen: „Staff the roles based on available skills information (e.g., IT
skills matrix).
Es sind demzufolge keine speziellen Ergebnisse bezüglich der Rollen gefordert. BAI01
einhalten genügt.
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
75 / 110
Vorgehen
In BAI01.01 „Maintain a standard approach for programme and project management“ wird
ein standardisiertes Vorgehen für die Abwicklung von Programmen und Projekten verlangt.
Das Vorgehen soll ein definierter Prozesse sein auf Basis von “Good Practice”. „Maintain
and enforce a standard approach aligned with good practice based on defined process and
use of appropriate technology.” Das Vorgehen soll den gesamten Projektablauf abdecken:
“Cover the full life cycle and disciplines to be followed including the management of scope,
resources, risk, cost, quality, time, communication, stakeholder involvement, procurement,
change control, integration and benefit realisation”.
Im Sinne des KVP muss das Vorgehen nach den Erfahrungen ergänzt oder korrigiert
werden: „Update the programme and project management approach based on lessons
learned from its use.“
Es sind demzufolge keine speziellen Ergebnisse bezüglich des Vorgehens gefordert. BAI01
einhalten genügt.
Zusammenfassung
COBIT beinhaltet in den geforderten Ergebnissen die Themen bezüglich Rollen,
Verantwortlichkeiten und Vorgehen.
Diese Punkte müssen nicht speziell untersucht werden, sie sind in den Ergebnissen
enthalten.
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
76 / 110
7 ANFORDERUNGEN AN HERMES-ERGEBNISSE
In diesem Kapitel werden die in HERMES zu erstellenden Ergebnisse, in COBIT als Output
bezeichnet, aufgeführt. Es werden Praktiken aus dem Prozess „Manage Programmes and
Projects“ kommentiert und die zugehörigen Ergebnisse für HERMES aufgeführt.
Davon ausgehend, dass für ein Audit alle Ergebnisse massgebend sind, sind diese auch als
Minimal-Ergebnisse zu verstehen. Ein Auditor wird immer den gesamten Standard als Prüf-
norm verwenden.
Out-of-Scope
Auf die Inputs und Outputs zu anderen Prozessen wird innerhalb dieser Arbeit, mit
Ausnahme des Vergleiches der EFK-Empfehlungen, nicht eingegangen.
7.1 Matching-Tabellen
Der Prozess BAI01 “Manage Programmes and Projects” [COBIT 5: Process Seite 105-114]
wird im Framework aufgeteilt in 14 “Process Practices”. Dieser Ausdruck “Process Practices”
sei im Folgenden im Original oder als „Praktiken“ verwendet.
Alle Praktiken, die mit Programmen in Verbindung stehen, werden nur soweit berücksichtigt
als ein Projekt, das nicht Bestandteil eines Programmes ist, diese auch benötigt. Der
vollständigkeithalber werden in der Haupt-Tabelle alle Praktiken aufgeführt.
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
77 / 110
7.1.1 Haupt-Tabelle Prozess BAI01 „Manage Programmes and Projects“
Die folgende Tabelle enthält die Übersicht aller im BAI01 erwähnten Process Practices und
zeigt auf, welche Ergebnisse nach COBIT resultieren.
Die Spalte „Praktik N°“ führt alle Nummern der Praktiken des Prozesses „Manage
Programme and Projects“ auf.
Die Spalte “Beschreibung” benennt die Praktiken, die durchzuführen sind.
Die Spalte “Ergebnisse nach COBIT” enthält den von COBIT verlangten Output. Ab Kapitel
7.1.2 wird dieser beschrieben und auch definiert, was als HERMES 5 „Minimalergebnisse“
angeschaut werden kann.
Praktik N° Beschreibung Ergebnisse nach COBIT
01 Maintain a standard approach for
programme and project management
Updated programme and project
management approaches
02 Initate a programme Programme concept business case,
Programme mandant and brief
Programme benefit realisation plan
03 Manage stakeholder engagements Stakeholder engagement plan
Results of stakeholder engagement
effectiveness assessements
04 Develop and maintain the programme
plan
Programme Plan
Programme budget and benefits
register
Resource requirements and roles
05 Launch and execute the programme Result of benefit realisation monitoring
Result of Programme goal
achievement monitoring
06 Monitor, control and report on the
programme outcomes
Results of programme performance
reviews
Stage-gate179 review results
179 Stage-Gate ist ein geschützter Begriff und wurde von Robert G. Cooper entwickelt. Der Stage-Gate-Prozess
unterteilt die Produkte-Einführung in verschiedene Abschnitte, die jeweils mit einem Tor (Gate) abgeschlossen sind. Dieses Tor kann nur passiert werden, wenn gewisse Bedingungen erfüllt sind. Es hat grosse Ähnlichkeiten zu Phasen im Projektmanagement, ist aber konzipiert für Produkte-Einführung. vgl. Robert G. Cooper (2010), Top oder Flop in der Produkt-Entwicklung, 2. Auflage 2010, WILEY-VCH Verlag GmbH & Co. KGaA, Seiten 145-148
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
78 / 110
Praktik N° Beschreibung Ergebnisse nach COBIT
07 Start up and initiate projects within a
programme
Project scope statements
Project definitions
08 Plan projects Project plans
Project baseline
Project reports and communications
09 Manage programme and project
quality
Quality management plan
Requirements for independent
verification of deliverables
10 Manage programme and project risk Project risk management plan
Project risk assessement results
Project risk register
11 Monitor and control a project Project performance criteria
Project progress reports
Agreed on hanges to project plan
12 Execute a project Project resource requirement
Project roles and responsibilites
Gaps in project planning
13 Close a project Post-implementation review results
Project lessons learned
Stakeholder project acceptance
confirmations
14 Close a programme Communication of programme
retirement an ongoing accountabilities
Tabelle 5: Prozess-Matching BAI01
(eigene Darstellung nach [COBIT 5: Process Seiten 105-114])
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
79 / 110
7.1.2 BAI01.01: Maintain a standard approach for programme and project
management
Aufgrund der geforderten Aktivitäten in COBIT wird ein umfangreicher Katalog von Themen
aufgeführt, die im “Standard approach” berücksichtigt werden müssen. Diese sind
management of scope, resources, risk, cost, quality, time, communication, stakeholder
involvement, procurement, change control, integration and benefit realisation [COBIT 5:
Process Seite 140].
Dies bedeutet, dass HERMES 5 alle diese Themen in der Methodik abdecken muss.
Weitergehend verlangt COBIT, dass diese Themen jeweils durch die “Lessons learned”,
Process Practice 13, angepasst werden sollten. HERMES 5 kann also keine statische
Methode mehr sein, sondern muss im Sinne von KVP180 permanent und aufgrund der
Erfahrungen „Lessons Learned“ angepasst werden. Damit könnte sich die Methode zu einer
Art „Best Practice in Project Management“ entwickeln181.
Im Sinne der Zielsetzungen von HERMES 5 mit Starter Kit und Minimal-Anforderungen ist es
sinnvoll, dass für alle diese Themen minimale Standard-Vorgaben entwickelt werden. Es
könnte z.B. ein Projekthandbuch entwickelt werden, das bereits die Abwicklung dieser
Themen beschreibt. Z.B. kann der Risiko-Management-Prozess beschrieben werden und
durch Beigabe von Templates können die entsprechenden Ergebnisse mit minimalem
Aufwand HERMES- und COBIT-gerecht erstellt werden.
Minimales Ergebnis HERMES 5
HERMES Methodik & Projekthandbuch:
Projektmethodik mit Beschreibung des ganzen Life-Cycles mit den Themen:
181 Eine näher zu untersuchende Hypothese des Autors.
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
80 / 110
7.1.3 BAI01.02: Initate a programme
In diesem Practice sind für die Initialisierung eines Programmes der Business Case
(Wirtschaftlichkeits-Berechnung) und die Planung des Nutzens182 (Benefit realisation plan)
erforderlich. COBIT äussert sich auf Stufe Projekt nicht mehr spezifisch über die
Wirtschaftlichkeit183. Deshalb wird dieser Punkt aus den Anforderungen für das Programme-
Management übernommen.
Für das Programm muss in dieser Phase der Auftraggeber und der Steuerungsausschuss
besetzt werden.
Minimales Ergebnis HERMES 5
Projektauftrag und Projektbeschreibung
Bestimmung Auftraggeber, Steuerungsausschuss und Projektleiter
Initial Business Case / Business Case (Wirtschaftlichkeits-Berechnung)
Benefit Realisation Plan (Nutzen Realisierungs Plan)
7.1.4 BAI01.03: Manage stakeholder engagements
COBIT verlangt hier nicht nur eine Stakeholder-Analyse, es muss auch eine
Kommunikationsplanung gemacht werden, um die Stakeholder entsprechend in das Projekt
einbinden zu können. Stakeholder müssen identifiziert, analysiert184 (Interessen,
Erwartungen), aktiviert185 und während dem ganzen Projekt betreut werden.
Die Anforderung lautet, dass der Einsatz der Stakeholder gemessen werden soll um
festzustellen, wenn das Engagement ungenügend ist. Es sind Massnahmen zu definieren, im
Falle das Engagement ungenügend wäre.
Minimales Ergebnis HERMES 5
Stakeholder Engagement-Plan, Stakeholder-Analyse
Auswertung des Stakeholder-Engagementes 182 vgl. Pascal Bänninger, Benefits Management – Behandlung des Nutzens aus IT-Projekten, Diplomarbeit im
Fach Informatik, Angefertigt am Institut für Informatik der Universität Zürich Prof. Dr. G. Schwabe, 15.10.2004, http://www.ifi.uzh.ch/archive/mastertheses/DA_Arbeiten_2004/Baenninger_Pascal.pdf, letzter Zugriff: 12. Januar 2012, [Beilage 12]
183 In der Detailstudie wird bereits gefordert: „Die Überprüfung der Wirtschaftlichkeit wird durch das ganze Projekt durchgezogen. vgl. Guido Eicher et al. Detailstudie zur Methode HERMES 5, Version 1.1. vom 16.9.2011, Informatikstrategieorgan des Bundes ISB, Seite 12
184 vgl. Karl Pfetzing, Adolf Rhode (2009), Ganzheitliches Projektmanagement, ibo Schriftenreihe Band 2, 3. Auflage, Verlag Dr. Götz Schmidt, Seiten 207-211
185 Aktivieren (engange) bedeutet die Stakeholder für das Projekt zu gewinnen, in Umgangssprache „ins Boot holen“
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
81 / 110
7.1.5 BAI01.04: Develop and maintain the programme plan
In dieser Praktik sind die Grundlagen für das Programm zu legen. Nicht alle Praktiken
müssen für ein Projekt ausgeführt werden. Der Projektplan, hier Programm-Plan, wird in
BAI01.08 gefordert.
Die Projektorganisation und das Projekt-Team muss definiert werden. Rollen,
Verantwortlichkeiten und Fähigkeiten (AKV186), die benötigt werden, müssen definiert sein.
Alle weiteren Ressourcen (betriebliche) müssen ebenso bestimmt sein. Allfällige „externe
Mitarbeiter“ sollten bereits berücksichtigt sein.
Die Verantwortungen müssen klar zugewiesen sein, insbesondere für das Erreichen des
Projektnutzens, Kostenkontrolle, Riskmanagement und Koordinationsaufgaben.
Es ist der Kommunikationsplan und das Reporting zu definieren.
Der Projekt Plan muss laufen aktualisiert und angepasst werden, damit man die Meilensteine
erreicht.
Der Business Case und der Nutzen Management Plan müssen laufend aktualisiert werden.
Ebenso das Projekt-Budget muss hier definiert werden. Die Aufstellung des Projektnutzens
soll unter BAI01.02 so gemacht werden, dass sie für das ganze Projekt benutzt werden
kann. Das Budget soll den ganzen Life-Cycle umfassen und auch den nicht-monetären
Nutzen berücksichtigen.
Minimales Ergebnis HERMES 5
Projektbudget
Ressource-Requirements und Rollen
Aufstellung des Projektnutzens (Quercheck mit BAI01.02 erforderlich)
7.1.6 BAI01.05: Launch and execute the programme
Betrifft nur Programme.
Minimales Ergebnis HERMES 5
Betrifft nur Programme.
186 Aufgaben, Kompetenzen, Verantwortung, z.B. nach Bruno Jenny (2001), Projektmanagement in der
Wirtschaftsinformatik, 5. Auflage, vdf Hochschulverlag AG an der ETH Zürich, Seite 104
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
82 / 110
7.1.7 BAI01.06: Monitor, control and report on the programme outcomes
Betrifft nur Programme.
Minimales Ergebnis HERMES 5
Betrifft nur Programme.
7.1.8 BAI01.07: Start up and initiate projects within a programme
Der Start eines Projektes beginnt, ob innerhalb eines Programmes oder als einzelnes
Projekt, mit der Definition der Ziele des Projektes und des Scopes.
Die Stakeholder sollten einverstanden sein mit Projektinhalt, Zielen, Scope, Nutzen und KPI
(Key Performance Indicators).
Es muss sichergestellt werden, dass die Projektanforderungen im Kommunikationsplan
enthalten sind.
Für die Durchführung muss das Change Management u.a. für die Projektanforderungen
implementiert sein.
Minimales Ergebnis HERMES 5
Aus diesem Practice sind die aufgeführten Angaben zu erstellen, erfahrungsgemäss wird
das im Projekthandbuch festgehalten.
Das Projekthandbuch mit “Project scope statements” und “Project definitions” ergänzen.
7.1.9 BAI01.08: Plan projects
Das Projekt muss detailliert geplant werden. Dazu muss der Projektplan erarbeitet und
abgenommen werden. Diese Planung soll den ganzen Life-Cycle des Projekts unterstützen.
Der Projektplan beinhaltet:
Projekt Ergebnisse, erforderliche interne und externe Ressourcen, Work Breakdown
Structure, Arbeitspakete, Meilensteine, Abhängigkeiten und die Identifizierung des kritischen
Pfades.
Während der Projektdurchführung müssen sowohl der Projektplan als auch alle anderen
abhängigen Planungen, wie z.B. das Risikomanagement oder das Qualitätsmanagement,
nachgeführt werden. Durch die Kommunikation muss sichergestellt sein, dass andere
abhängige Projekte und Programme über allfällige Änderungen informiert sind. Meilensteine
müssen dokumentiert und jeweils abgenommen sein.
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
83 / 110
Für den Soll-Ist-Vergleich ist eine Baseline festzuhalten bezüglich alle im QS erfassten
Elemente (Kosten, Termine, Scope, Qualität etc.).
Minimales Ergebnis HERMES 5
Projektplan
Projekt Baseline
Projekt Reporting and Kommunikationsplanung
7.1.10 BAI01.09: Manage programme and project quality
Die Qualitätssicherung muss nach dem Qualitätsmanagement Plan und dem QMS der
Unternehmung erfolgen. Dazu gehört das Change Management sowie das Sicherstellen der
Anforderungen betreffend interner Kontrolle und Security-Lösungen.
Die interne Kontrolle muss hier sicherstellen, dass das Projekt nach COBIT auditiert werden
kann.
Für das Sicherstellen der Qualität der Projektergebnisse müssen die Verantwortungen,
Ownership, Reviews, Erfolgskriterien und Messkriterien festgehalten sein.
Minimales Ergebnis HERMES 5
Qualitäts Management Plan
Voraussetzungen definieren für die unabhängige Überprüfung der Ergebnisse. Das bedeutet
dass allfällige Reviews und Audits für die Qualitätssicherung festgelegt werden.
7.1.11 BAI01.10: Manage programme and project risk
Das Risikomanagement muss die Identifikation, Analyse, Überwachung und Kontrolle über
alle Bereiche sicherstellen, die Auswirkungen (Risiko) auf das Projekt haben. Erfasste
Risiken müssen analysiert werden und es müssen Massnahmen zur Reduzierung der
Risiken definiert und durchgeführt werden (Mitigation). Dazu müssen alle Risiken und
Massnahmen permanent überwacht und dokumentiert werden.
Es ist abzuwägen, ob man das Risikomanagement einer unabhängigen Stelle übertragen will
oder ob man dieses innerhalb des Projekt-Teams durchführt.
In jeder neuen Phase des Projektes (Meilensteine) müssen die Risiken neu beurteilt werden.
Das Management der Risiken und die Kommunikation soll mit der Governance im Einklang
stehen.
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
84 / 110
Prozesse in COBIT
COBIT stellt zwei Unternehmens-Prozesse für das Risikomanagement zur Verfügung. In
APO12 “Manage risk” werden die Risiken für das Unternehmen kontinuierlich identifiziert und
nach Möglichkeit reduziert.
EDM3 “Ensure Risk Optimisation” stellt sicher, dass die Risiken der IT auf die aktuelle und
zukünftige Nutzung geprüft und beurteilt werden. Ebenso muss die Risikobereitschaft der
Unternehmung bezüglich dem Nutzen der IT beurteilt und angepasst werden.
Es muss in den Projekten jeweils geprüft werden, ob diese Risiken auch auf das Projekt
zutreffen.
Minimales Ergebnis HERMES 5
Projekt Risiko Management Plan
Projekt Risiko Beurteilungsprozess
Projekt Risiko Liste
7.1.12 BAI01.11: Monitor and control a project
Diese Praktik dient zur umfassenden Überwachung und Kontrolle des Projektes. Wichtigste
Kriterien für die Überwachung sind Scope, Kosten, Termine, Risiken und Qualität. Weitere
Kriterien können nach Bedarf hinzugefügt werden.
Die Projektperformance muss mit den KPI aus BAI01.07 verglichen werden. Abweichungen
müssen zu den Key Stakeholdern kommuniziert werden. Eventuelle Änderungen im Plan
müssen dokumentiert, von den Stakeholdern abgenommen und danach kommuniziert
werden. Für jede Phase (Meilenstein) sollen die KPI abgenommen werden.
Im Grundsatz geht es darum, dass Abweichungen prozessual korrekt implementiert, alle
betroffenen informiert und alle notwendigen Entscheidungen durch die Stakeholder
respektive gemäss durch die Verantwortlichen geprüft und akzeptiert werden.
Minimales Ergebnis HERMES 5
Projekt KPI
Projekt Fortschritt Report
Change Management Plan
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
85 / 110
7.1.13 BAI01.12: Execute a project
Die Durchführung des Projektes gemäss Projektplan aus BAI01.08 muss sichergestellt
werden, Entscheidungen getroffen und Arbeitspakete in Auftrag gegeben, geprüft und
abgenommen werden.
Minimales Ergebnis HERMES 5
Projekt Ressourcenplanung
Projekt Organigramm, Rollen und Verantwortungen (Koordinieren mit BAI01.04)
Projekt Kontrolle (Gaps in project planning)
7.1.14 BAI01.13: Close a project
Bei Projektende müssen die Stakeholder die erreichten Ziele und den erbrachten Nutzen des
Projektes abnehmen. Allfällige Projekt-Restanzen sind zu identifizieren und der Post-
Implementation zuzuführen.
Für die Lessons Learned ist das Projekt-Team zu involvieren. Die Lessons Learned
bezüglich der Projektmethodik sind in den KVP zu überführen.
Minimales Ergebnis HERMES 5
Reviews für die Kontrolle der erzielten Resultate
Projekt Lessons Learned
Genehmigung der Stakeholder des Projektes
7.1.15 BAI01.14: Close a programme
Betrifft nur Programme.
Minimales Ergebnis HERMES 5
Betrifft nur Programme.
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
86 / 110
7.2 Quercheck COBIT und EFK-Empfehlungen
Die Empfehlungen der EFK respektive der Schweizerischen Finanzkontrollen basieren auf
ihren Erfahrungen und nehmen Bezug auf COBIT 4.0 (Deutsch), Prince2, den
Prüfungsstandards der Schweizer Handbuch der Treuhandkammer187 und der Verordnung
über die Führung und Aufbewahrung der Geschäftsbücher188 sowie HERMES 2003/2005.
In zwei Schritten wird im Folgenden untersucht, welche Ergebnisse erforderlich sind, wenn
alle vorgegebenen Dokumente und alle in den Hinweisen erwähnten Prozesse und Praktiken
berücksichtigt werden.
7.2.1 EFK-Empfehlung: Mapping COBIT 4.1 – COBIT 5
Im ersten Schritt werden alle Hinweise in den Empfehlungen auf den Standard COBIT 4.0
herausgesucht und den neuen Praktiken in COBIT 5 gegenübergestellt. Diese Hinweise in
den Empfehlungen sind nicht als obligatorische Ergebnisse zu verstehen. Sie dienen dazu,
die in den Empfehlungen gesetzten Zielsetzungen zu erreichen.
In der Aufstellung gemäss Anhang Kapitel 9.1.1 werden die empfohlenen „Control
Objectives“ von COBIT 4.1 mit den Praktiken in COBIT 5 verglichen. Mit einem * markiert
sind alle Praktiken die in BAI01 enthalten und in Kapitel 7.1 bereits aufgeführt sind. Die
Mapping-Tabelle ist hier [COBIT 5: Process Seiten 205-210] zu finden.
Ergebnis: Von 72 aufgeführten Praktiken sind fünf (!) aus der Domäne Projektmanagement
BAI01. Das bedeutet, dass auf ganz allgemeine Prozesse zurückgegriffen wird oder auf
Prozesse, die ein Input-Prozess zu BAI01 darstellen. Es ist auch zu prüfen, ob es
Veränderungen in dieser Beziehung zwischen COBIT 4.1 und COBIT 5 gegeben hat.
7.2.2 EFK-Empfehlung: Ergebnisse nach COBIT 5
Im zweiten Schritt werden alle Ergebnisse aus Schritt 1, also die „gemappten“ COBIT 5
Praktiken, aufgeführt. Die Auflistung dieser Ergebnisse sind im Anhang unter Kapitel 9.1.2
aufgeführt.
Bei der Analyse stellt man fest, dass viele Ergebnisse keinen Teil des Projektmanagements
darstellen. Sie können in folgende Gruppen eingeteilt werden:
187 TREUHAND-KAMMER, Schweizer Prüfungsstandards (PS), Ausgabe 2010, http://www.treuhand-
kammer.ch/dynasite.cfm?dsmid=85591, letzter Zugriff 29. Januar 2012 188 Verordnung vom 24. April 2002 über die Führung und Aufbewahrung der Geschäftsbücher
(Geschäftsbücherverordnung; GeBüV), SR 221.431, http://www.admin.ch/ch/d/sr/c221_431.html, letzter Zugriff: 28. Januar 2012
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
87 / 110
Das Ergebnis könnte neu mit Ergebnissen in BAI01 definiert werden.
Z.B. in APO11.1 sind Ergebnisse des Qualitätsmanagements erforderlich. Diese
sind in BAI01.09 enthalten und könnten so referenziert werden.
Ergebnis ist als Input-Praktik zu BAI01 definiert.
Z.B. BAI02.03 ist als Input für BAI01.10 definiert.
Ergebnis ist das Resultat aus Prozessen der Unternehmung.
Z.B. muss DSS07.1 „Malicious software prevention policy“ durch die
Unternehmung definiert werden.
Ergebnisse sind in BAI01 enthalten = Projektmanagement
Zusammenfassung
Die Empfehlungen sollten neu überarbeitet und die Hinweise an COBIT 5 anpasst werden.
Es ist zu überprüfen, ob das Mapping nach COBIT 5 noch korrekt ist.
Die Anforderung der Minimal-Ergebnisse kann hier so verstanden werden, dass diese als
Hinweise abgegrenzten Prozesse und Praktiken nicht berücksichtigt werden müssen.
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
88 / 110
8 SCHLUSSFOLGERUNGEN UND EMPFEHLUNGEN
8.1 Disclaimer: Exposure Draft
Alle Ausführungen bezüglich COBIT beziehen sich auf den Exposure Draft. Auch wenn man
nicht davon ausgehen muss, dass sich das Framework grundsätzlich ändert, so muss man
doch den ersten Release COBIT 5 überprüfen, ob vielleicht die Rahmenbedingungen und
Restriktionen, aber auch die verwendeten Inhalte, Vorgaben, Ziele, Prinzipien, Prozesse und
Praktiken für diese Arbeit geändert haben. Dementsprechend müssen die Ergebnisse,
Folgerungen und Empfehlungen angepasst werden.
8.2 Schlussfolgerungen
Die Schlussfolgerungen werden auf die Zielsetzungen bezogen.
8.2.1 Auditierbarkeit
Zielsetzung:
Das Ziel dieser Arbeit ist es, für HERMES 5 die Frage der Auditierbarkeit nach dem Standard COBIT zu beantworten.
Schlussfolgerung:
Im Prinzip entsteht ein Widerspruch zwischen den Anforderungen des Bundes an die
Weiterentwicklung an HERMES, der Detailkonzeption des HERMES 5 Projektes, den
Empfehlungen der EFK und dem Anspruch von COBIT, das Dach aller Frameworks zu sein.
Der Bund fordert u.a.:
Einsatzfähige Minimallösung: eine einsatzfähige Einstiegslösung der Methode, welche
eine minimale Menge der zu erstellenden Ergebnisse beinhaltet.
Das HERMES 5 Projekt fordert:
Mit HERMES abgewickelte Projekte müssen „audittauglich“ nach COBIT sein.
Die EFK empfiehlt:
In den Empfehlungen der EFK werden 10 Dokumente empfohlen, die zwingend als
Ergebnisse vorzulegen sind. In den zugehörigen Hinweisen allein zu COBIT sind
Referenzen zu über rund 90 Ergebnissen enthalten.
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
89 / 110
COBIT wiederum
hat den Anspruch an sich, dass es alle Frameworks integriert „A single overarching
framework serves as a consistent and integrated source of guidance“.
ist keine direkte Anwendung, es ist ein Framework189.
verlangt gemäss der Definition der Reifegrade, dass ein Prozess jeweils Level 1 erreicht
hat, da er sonst die Ziele nicht erreicht haben kann190.
Widerspruch warum?
Ein Audit, das sich am “single overarching” Standard ausrichtet, muss zwangsläufig
umfangreich und aufwendig sein. Die vom Bund geforderte Minimal-Lösung zielt aber auf
eine schlanke und einfach zu handhabende Methodik hin.
Wie kann das gelöst werden? Folgende Statements müssen beachtet werden:
Der Bund verlangt nicht “per se” die Audit-Fähigkeit nach COBIT, diese
Anforderungen wurden im Detailkonzept gestellt.
Der gesetzte Auditor, d.h. die EFK respektive die Schweizerischen
Finanzkontrollen haben sich bis jetzt nicht dahingehend geäussert, dass COBIT
der Massstab sein wird. Welche Prozesse und Praktiken berücksichtigt werden
sollen, können frühestens nach dem Release von COBIT 5 definiert werden. Der
Umfang für ein Audit ist demzufolge (noch) nicht definiert.
COBIT beinhaltet als Framework nur “Beispiele” von Zielen, Prozessen und
Praktiken. Auch wenn diese Ziele und Prozesse in professionelle Art und
aufwändiger Forschung erarbeitet wurden, so sind es „generische“ Resultate.
Dahingehend müsste man, wollte man es perfekt realisieren, Ziele, Prozesse und
Praktiken nach dem Unternehmen Bund, oder eventuell auch generalisiert als
“Unternehmung in der öffentlichen Verwaltung”, spezifizieren.
Man kann unter gewissen Vorbehalten die im COBIT Release benutzten Ziele,
Prozess und Praktiken verwenden, aber “man muss wissen, was man macht”.
Das Prüfen der Prozesse auf einen bestimmten Reifegrad ist aufwendig und kann
nicht Aufgabe eines Projektes sein. Insbesondere muss sich ein Projekt auf
Prozesse innerhalb der Unternehmung abstützen können. Reifegrad 1 der
involvierten Prozesse muss demzufolge als Voraussetzung betrachtet werden. 189 Ein Framework ist ein Gerüst, nach dessen Anweisung man etwas realisieren kann. Es ist nicht das Ergebnis
direkt. Der Ausdruck Framework ist in der Software-Programmierung sehr populär. Ein Framework wird benutzt um Software-Programme zu erstellen.
190 COBIT 5: The Framework, Exposure Draft, ISACA, Seite 49: „If a required process outcome is not consistently achieved, the process does not meet its objective and needs to be improved.“
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
90 / 110
Es gibt demzufolge folgende Lösungsvarianten:
1. Die EFK spezifiziert aus dem ersten Release von COBIT 5 was benötigt wird, um ein
Audit zu bestehen. Es braucht nicht zwangsläufig den vollen Umfang von COBIT oder
nicht diese Ausführlichkeit, wie sie COBIT definiert. D.h. es müssten die Praktiken
und die “Tiefe” der Ausführung definiert werden, die für ein Audit gelten sollen. Dies
ergibt dann die Minimal-Anforderungen. Es wäre auch möglich, dies in die Szenarien
von HERMES zu integrieren oder von der Projektgrösse abhängig zu machen (siehe
auch Empfehlung „Projektgrösse“).
2. Man verwendet COBIT als Framework und erstellt für den Bund oder für eine
“allgemeine öffentliche Verwaltung” eine entsprechende Anwendung und daraus
kann die Minimal-Lösung entwickelt werden.
3. Man verwendet den ersten Release von COBIT 5 und führt Audits durch, entweder
echt oder als Testcase. Mittels KVP korrigiert man an der Methodik bis die
Anforderungen der EFK erfüllt sind. Das wäre dann die Minimal-Lösung. Eventuell
müsste man dies parametrisieren, also für verschiedene Projekte, Szenarien oder
Projektgrössen verschiedene Anforderungen stellen.
4. Die Anforderungen, dass HERMES 5 Projekte immer und automatisch ein Audit nach
COBIT bestehen müssen, wird angepasst (siehe auch Empfehlung „Projektgrösse“).
Mit der Formulierung „HERMES 5 erfüllt die Anforderungen an die IT-Governance“
oder „HERMES 5 ist für grosse Projekte COBIT Compliant“ könnte man für kleinere
Vorhaben den Aufwand der COBIT-Compliance umgehen. Für kleine Projekte
können trotzdem Governance-Grundsätze erfüllt werden, z.B. durch die
Ausgestaltung der Ergebnisse, durch Vorgaben im Projekthandbuch oder
Anforderungen an den Projektleiter (Skills, Zertifizierungen).
Folgerung: Die Auditierbarkeit ist prinzipiell gegeben.
Die Auditierbarkeit von HERMES 5 ist unter der Berücksichtigung der aufgezeigten
Rahmenbedingungen und Einschränkungen gegeben. Es ist eine Frage der Erfüllung der
Anforderungen, des Aufwandes und der Ausgestaltung der Realisierung von HERMES 5, um
ein Audit zu bestehen.
Ob es Sinn macht die Auditierbarkeit von HERMES 5 nur auf der Basis von COBIT zu
prüfen, war nicht Ziel dieser Arbeit. Aufgrund der Aufgaben der EFK, dargelegt in Kapitel 5.2,
sowie den Empfehlungen der Schweizerischen Finanzkontrollen, die als Basis weitere
Quellen benutzen, scheint das fraglich. Zu prüfen wäre, ob COBIT implizit auch andere
Anforderungen oder Standards abdeckt und somit als alleiniger Standard gelten kann.
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
91 / 110
8.2.2 Lösungsansätze
Zielsetzung:
Das Ziel dieser Arbeit ist Lösungsansätze aufzuzeigen, wie die minimalen
Ergebnisse, Rollen und Vorgehen aussehen müssen, um ein Audit über die
Governance nach COBIT erfolgreich zu erfüllen.
Es wurde in Kapitel 6.4 hergeleitet, dass man sich auf die Ergebnisse beschränken kann,
weil Rollen und Vorgehen darin enthalten sind.
Die in HERMES 5 zu erstellenden Ergebnisse gemäss Prozess BAI01 sind aufgeführt. Mit
dem gleichen Lösungsansatz müssen auch die anderen Prozesse, insbesondere die Input-
Prozesse für BAI01 analysiert und dessen Resultate dementsprechend hinzugefügt werden.
Folgerung: Der Lösungsansatz ist aufgezeigt
Mit der gleichen Systematik können alle Prozesse analysiert und die notwendigen
Ergebnisse, Rollen und Vorgehen definiert werden.
8.2.3 Grundlage White Paper
Zielsetzung:
Das Ziel dieser Arbeit ist als Grundlage für ein Whitepaper „COBIT vs HERMES“
bei der ISACA zu dienen.
Diese Arbeit kann als Grundlage zu einem Whitepaper dienen. Insbesondere ist geklärt,
dass man Prozesse und Praktiken von COBIT zu Ergebnissen von HERMES 5 referenzieren
kann.
Folgerung: Die Grundlagen sind gelegt.
Da weder COBIT 5 noch HERMES 5 realisiert sind, kann darüber noch nichts Definitives
gesagt werden.
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
92 / 110
8.2.4 Audit bestehen
Zielsetzung:
Das Ziel dieser Arbeit ist mitzuhelfen, dass in Projekten die Grundlagen für ein
erfolgreiches Bestehen eines Audit während dem Projekt erarbeitet werden.
Folgerung: Ein Audit kann bestanden werden.
Bei der Realisierung von HERMES 5 werden die Ergebnisse so definiert, dass damit die
Anforderungen an ein Audit erfüllt werden können.
Es sind aber die Rahmenbedingungen, Voraussetzungen, Schlussfolgerungen und
Empfehlungen dieser Arbeit zu berücksichtigen.
8.2.5 Verbesserung Governance
Zielsetzung:
Das Ziel dieser Arbeit ist durch Erarbeiten der für ein Audit geforderten
Ergebnisse, die (IT-) Governance in einem Projekt auch ohne Audit zu
verbessern.
Folgerung: Die Governance kann verbessert werden.
Wenn man COBIT berücksichtigt, wird implizit die Governance verbessert, vorausgesetzt,
das Management des Projektes hält sich an die Vorgaben (z.B. HERMES als obligatorisch
erklären und durchsetzen). Diese Vorgaben sind auch eine Governance-Aufgabe und
müssen von der übergeordneten Stelle festgelegt werden.
Wenn also vom Top-Management die Einhaltung der Vorgaben verlangt und durchgesetzt
wird, so ist dieses Ziel erfüllt.
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
93 / 110
8.3 Empfehlungen
Die Empfehlungen sind weder alphabetisch, thematisch, noch nach Prioritäten geordnet.
Abwägen des Vorgehens
Aufgrund dieser Arbeit sollte zuerst die Situation geklärt werden. Eine Analyse der folgenden
Punkte sollte folgen und darf auch zu einer Anpassung der Anforderungen an HERMES 5
führen:
Anforderungen der EFK / Schweizerische Finanzkontrollen
COBIT als einziger Standard für Auditierung
Reifegrad der Prozesse
COBIT als generische Framework vs COBIT für den Bund respektive für die
öffentliche Verwaltungen zu definieren
HERMES-Zertifizierungen
Die HERMES-Zertifizierungen sollen das Thema Governance explizit beinhalten oder aber,
man könnte alternativ eine „Governance für Projekte“-Zertifizierung machen.
Man kann sich auch vorstellen, dass grundlegendes Wissen über COBIT Inhalt einer
Zertifizierung sein könnte.
Wenn das Thema Governance Inhalt ist, so soll es nicht nur auf Ergebnisse von HERMES
reduziert werden. Es muss das grundsätzliche Verständnis geschult und geprüft werden.
Auditierbarkeit
Das Audit von Projekten kann und soll nicht nur nach einem Standard erfolgen. Weitere
Vorgaben sind ebenfalls zu berücksichtigen. Die Anforderung an HERMES sollte deshalb
lauten: HERMES 5 erfüllt die Governance-Aspekte von COBIT. Die Auditierbarkeit soll mit
dem Auditor vereinbart werden.
Modulbeschreibungen HERMES 5
Beim Erstellen der Modulbeschreibung191 sind die Aufgaben aufgeführt. Hier wäre es
nützlich, man würde die Aktivitäten in COBIT prüfen und entsprechende Tätigkeiten
übernehmen respektive abgleichen.
191 Bernhard Kruschitz (2012), HERMES 5: Methodenbeschreibung: Modul Projektmanagement, Version 0.1 vom
24.1.2012, Informatikstrategieorgan Bund ISB
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
94 / 110
Projektgrössen
Im Prinzip macht es keinen Sinn, alle Projekte nach COBIT zu erstellen, um für ein allfälliges
Audit gewappnet zu sein. Damit ist nicht gesagt, dass es keinen Sinn macht, Projekte nach
den Prinzipien der Governance zu führen.
Der Aufwand für das „administrative“ Führen von kleinen und mittleren Projekten soll gering
gehalten werden. Somit sollte eine Kategorisierung nach Projektgrösse darüber entscheiden,
ob die Projekt-Abwicklung voll COBIT-Compliant sein muss oder ob die Einhaltung gewisser
Grundsätze der Governance genügen. Unter COBIT-Compliance versteht man die exakte
Prüfung des Projektes gegenüber dem Standard (analog ISO-9001-Zertifizierungen).
Empfehlung der Abstufung:
Kategorie C klein < 230 kCHF192 (Vorschlag: die Ausschreibungsgrenze)
Andreas Kühn, Konrad Walser, Reinhard Riedl (2008), Auditing Projects in e-Government based on IT Governance Methods, Competence Centre Public Management and E-Government Berne University of Applied Sciences, Morgartenstrasse 2a, Postfach 305, 3000 Bern 22
Andreas Rüter, Jürgen Schröder, Axel Göldner, Jens Niebuhr (2010) , IT-Governance in der Praxis, 2. Auflage, Springer Verlag, Berlin Heidelberg 2010, ISBN: 978-3-642-03504-3
Annette Willi (2008), IT-Governance als Aufgabe des Verwaltungsrates, Schulthess Juristische Medien AG, Zürich, Basel, Genf 2008. ISBN: 978-3-7255-5713-4
Arthur Benz, Nicolai Dose (2010) in Governance – Regieren in komplexen Regelsystemen, 2. aktualisierte und überarbeitete Auflage 2010, Herausgeber: Arthur Benz, Susanne Lütz, Uwe Schimak, Georg Simonis, VS Verlag für Sozialwissenschaften, Springer Fachmedien Wiesbaden GmbH 2010, ISBN: 978-3-531-17332-0
Böckli Peter, Schweizer Aktienrecht, 3. Aufl. zitiert nach: Annette Willi (2008), IT-Governance als Aufgabe des Verwaltungsungsrates, Schulthess Juristische Medien AG, Zürich, Basel, Genf, ISBN: 978-3-7255-5713-4
Bogdan Lent (2003), IT-Projekte lenken – mit System, 1. Auflage Dezember 2003, Friedr. Vieweg & Sohn Verlag | GWV Fachverlage GmbH, Wiesbaden, ISBN: 3-528-05883--8
Bruno Jenny (2001), Projektmanagement in der Wirtschaftsinformatik, 5. Auflage, vdf Hochschulverlag AG an der ETH Zürich; ISBN: 3-7281-2791-4
Bruno Jenny (2005), Projektmanagement, 2. Auflage 2005, vdf Hochschulverlag AG an der ETH Zürich, ISBN: 3-7281-3004-4
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
105 / 110
CGG, 1995, Our global Neighbourhood, zitiert nach: Maria Behrens (2010) in Governance – Regieren in komplexen Regelsystemen, 2. aktualisierte und überarbeitete Auflage 2010, Herausgeber: Arthur Benz, Susanne Lütz, Uwe Schimak, Georg Simonis, VS Verlag für Sozialwissenschaften, Springer Fachmedien Wiesbaden GmbH 2010, ISBN: 978-3-531-17332-0
Christian Theobald (2000), Zur Öekonomik des Staates, Good Governance und die Perzeption der Weltbank, Nomos Verlagsgesellschaft Baden-Baden 2000. ISBN: 3-7890-6613-3
Daniel Schreiber (2010), Management von Controllingwissen, 1. Auflage 2010, Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2010, ISBN: 978-3-8349-2205-2
Economiesuisse (2007), swiss code of best practice for corporate governance, economiesuisse, Verband der Schweizer Unternehmen, Spitalgasse 4, Postfach, CH-3001 Bern
Eileen C. Forrester, Brandon L. Buteau, Sandy Shrum (2011), CMMI for Services, Second Edition, Addison-Wesley, Copyright 2011 Pearson Education Inc., ISBN: 978-0-321-71152-6
Ernest Wallmüller (2001), Software-Qualitätsmanagement in der Praxis, 2. völlig überarbeitete Auflage, Carl Hanser Verlag, München, ISBN: 3-446-21367-8
Gerhard Ortner, Betina Stur (2011), Das Projektmanagement-Office, Springer-Verlag Berlin Heidelberg, ISBN: 978-3-642-20785-3
Han van Loon (2004), Process Assessment and ISO/IEC 15504, The Kluwer International Series in Engineering and Computer Science, Volume 775, Springer Science+Business Media, New York, ISBN: 0-387-23172-2
Harry Cendrowski, William C. Mair (2009), Enterprise Risk Management and COSO, Verlag John Wiley & Sons, Inc., Hoboken, New Jersey, ISBN: 978-0-470-46065--8
Hartmut F. Binner (2002), Prozessorientierte TQM-Umsetzung (Bd. 2. Auflage). München: Carl Hanser Verlag, ISBN: 3-446-21852-1
IT-Governance für Geschäftsführer und Vorstände, Zweite Ausgabe (Deutsch), IT Governance Institut, Übersetzung durch KPMG Österreich, 2003
Johannes Voigt (2006), COSO & COBIT zur Unterstützung der Corporate Governance, 1. Auflage 2006, Seminararbeit an der Fachhochschule Koblenz, GRIN Verlag, ISBN: 978-3-638-71432-7
Jürg Kuster, Eugen Huber, Robert Lippmann, Alphons Schneider, Emil Schneider, Urs Witschi, Roger Wüst (2008), Handbuch Projektmanagement, 2. Auflage, Springer Verlag, Berlin, Heidelberg, ISBN: 978-3-540-76431-1
Jürgen Kamleiter und Michael Langer (2006), Business IT-Alignment mit ITIL, COBIT, RUP, 1. Auflage 2006, Herausgeber: Michael Kresse, Serview GmbH, Gartenstr. 23, 61352 Bad Homburg, ISBN: 978-3-9810977-1-9
Jürgen Schmied, Paul-Roux Wentzel, Michael Gerdom, Uwe Hehn (2008), Mit CMMI Prozesse verbessern, 1. Auflage 2008, dpunkt.verlag gmbH, Heidelberg, ISBN: 978-3-89864-538-6
Jürgen Weber (2002), Vorwort in Controlling als akademische Disziplin, Herausgeber: Jürgen Weber, Bernhard Hirsch, Schriften des Center for Controlling & Management (CCM), 1. Auflage November 2002, Band 7, Deutscher Universitätsverlag GmbH, Wiesbaden 2002, ISBN: 3-8244-7693-2
Karl Pfetzing, Adolf Rhode (2009), Ganzheitliches Projektmanagement, ibo Schriftenreihe Band 2, 3. bearbeitete Auflage, Verlag Dr. Götz Schmidt; ISBN: 978-3-921313-76-3
Karol Frühauf, Jochen Ludewig, Helmut Sandmayr (2002), Software-Projektmanagement und - Qualitätssicherung, vdf Hochschulverlag AG an der ETH Zürich, ISBN: 3-7281-2822-8
Klaus Wienhold (2003), Prozess- und Controllingorientiertes Projektmanagement für komplexe Projekte, Band 27 von „Controlling und Management“, Herausgegeben von Prof. Dr. Thomas Reichmann und Prof. Dr. Martin K. Welge, Peter Lang GmbH, Europäischer Verlag der Wissenschaften, Frankfurt am Main, 2004, ISBN: 3-631-52230-4
Klaus-Rainer Müller (2011), IT-Sicherheit mit System, 4. neu bearbeitete und erweiterte Auflage 2011, Vieweg + Teubner Verlag, Springer Fachmedien Wiesbaden GmbH 2011, ISBN: 978-3-8348-1536-1
Krcmar (2010), Einführung in das Informationsmanagement, Springer-Verlag, Berlin Heidelberg 2011, ISBN: 978-3-642-15830-8
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
106 / 110
Kursausschreibung CONTROLLING, MASTER of Advanced Studies (MAS), HWZ, Hochschule für Wirtschaft Zürich, HWZ / 11 000 / 04.09 / KL
Manuel Juen (2005), IT Auditing im E-Government, Diplomarbeit im Fach Informatik, Institut für Informatik der Universität Zürich
Maria Behrens, Alexander Reichlin (2007) in Handbuch Governance, 1. Auflage Juni 2007, Herausgeber: Arthur Benz, Susanne Lütz, Uew Schimanek, Georg Simonis, VS Verlag für Sozialwissenschaften, Springer Fachmedien Wiesbaden GmbH 2007, ISBN: 978-3-531-14748-2
Marianne Beisheim (2004), Fit für Global Governance, Leske + Budrich, Opladen 2004. ISBN: 3-8100-4031-2
Markus Gaulke (2006), COBIT als IT-Governance-Leitfaden in Praxis der Wirtschaftsinformatik, Herausgeber: Hans-Peter Fröschle, Susanne Strahringer, HMD Heft 250, August 2006, dpunkt.verlag, ISBN: 3-89864-382-4
Melanie Kozer (2002), Corporate Governance: Das Zusammenspiel von Internal Control und External Control, Inaugural-Dissertation zur Erlangung des grades Doktor oeconomia publica (Dr. oec. publ.) an der Ludwig-Maximilians-Universität München, Shaker verlag Achen 2002, ISBN: 3-8322-0609-4
Pascal Bänninger (2004), Benefits Management – Behandlung des Nutzens aus IT-Projekten, Diplomarbeit im Fach Informatik, Angefertigt am Institut für Informatik der Universität Zürich bei Prof. Dr. G. Schwabe, 15.10.2004
Patrick S. Renz (2007), Project Governance : Implementing Corporate Governance and Business Ethics in Nonprofit Organizations, Physica Verlag Heidelberg New York, ISBN: 978-3-7908-1926-7
Péter Horvát (1986), Controlling, 2. Auflage, Vahlens Handbücher der Wirtschaft- und Sozialwissenschaften, München, 1986, ISBN: 3-8006-1090-6
Péter Horvát (2002), Der koordinationsorientierte Ansatz in Controlling als akademische Disziplin, Herausgeber: Jürgen Weber, Bernhard Hirsch, Schriften des Center for Controlling & Management (CCM), 1. Auflage November 2002, Band 7, Deutscher Universitätsverlag GmbH, Wiesbaden 2002, ISBN:3-8244-7693-2
Peter Weill, Jeanne W. Ross (2000), IT Governance: how top performers manage IT decision rights for superior results, Harvard Business School Press, Boston, Massachusetts, ISBN: 978-1-59139-253-8
Peter Weill, Jeanne W. Ross (2004), IT Governance on one Page, MIT Sloan working Paper No 4517-04, CIS Research Working Paper No: 349, November 2004. http://ssrn.com/abstract=664612
Rationalisierungs-Kuratorium der Deutschen Wirtschaft, Projektmanagement Fachmann (2001), 6. Auflage, Band 1, RKW-Verlag, ISBN: 3-926984-57-0
Robert G. Cooper (2010), Top oder Flop in der Produkt-Entwicklung, 2. Auflage 2010, WILEY-VCH Verlag GmbH & Co. KGaA, ISBN: 978-3-527-50512-8
Robert S. Kaplan, David P. Norton; The Balanced Scorecard: Translating Strategy into Action; Harvard University Press, zitiert in: COBIT 5, Process Reference Guide
Roland Czada (2010) in Governance – Regieren in komplexen Regelsystemen, 2. aktualisierte und überarbeitete Auflage 2010, Herausgeber: Arthur Benz, Susanne Lütz, Uwe Schimak, Georg Simonis, VS Verlag für Sozialwissenschaften, Springer Fachmedien Wiesbaden GmbH 2010, ISBN: 978-3-531-17332-0
Ron S. Kenett, Emanuel R. Baker (2010), Process Improvement and CMMI for Systems and Software, CRC Press, Taylor & Francis Group, Boca Raton, London, New York, ISBN: 978-1-4200-6050-8
Terry Rout (2011), High Levels of Process Capability in CMMI and ISO/IEC 15504 in Software Process Improvement and Capability Determination, Herausgeber Rory V. O’Connor, Terry Rout, Feragl McCaffery, Alec Dorling, 11th International Conference SPICE 2011, Dublin, Springer Verlag Berlin Heidelberg 2011, ISBN: 978-3-642-21232-1
Ulrich Brand, Achim Brunnengräber, Lutz Schrader, Christian Stock, Peter Wahl, Global Governance, Alternative zur neoliberalen Globalisierung, 1. Auflage Münster 2000, Verlag Westfälisches Dampfboot, Münster, ISBN: 3-89691-471-5
Verband Deutscher Maschinen- und Anlagebau e.V. VDMA, Projekt-Controlling im Anlagengeschäft, BmV 187, 2. Auflage August 1982, Maschinenbau-Verlag GmbH, Frankfurt/Main, Bestellnummer: 047000
Wer regiert die Welt und mit welchem Recht? (2009), Beiträge zur Global Governance-Forschung, Herausgeber Volker Rittberger, Theodor Eschenburg Vorlesungen, Band 4, Nomos Verlagsgesellschaft, Baden-Baden, ISBN: 978-3-8329-4179-6
Win Van Grembergen, Steven De Haes, Hilde van Brempt (2008), Understanding How Business Goals Drive IT Goals, University of Antwerp Management School im Auftrag vom IT Governance Institute ITGI™
Wolfgang Goltsche, COBIT kompakt und verständlich, 1. Auflage September 2006, Friedr. Vieweg & Sohn Verlag | GWV Fachverlage GmbH, Wiesbaden 2006, ISBN-10: 3-8348-0141-0
Wolfgang Johannsen, Matthias Goeken (2007), Referenzmodelle für IT-Governance, 1. Auflage, dpunkt.verlag GmbH, ISBN: 978-3-89864-397-9
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
107 / 110
World Bank, 1989, Sub-Sahara Africa, From Crisis to sustainable Growth, Washington (DC), zitiert nach: Roland Czada (2010), Arthur Benz & Nicolai Dose (Herausgeber), Governance – Regieren in komplexen Systemen, 2. Auflage, VS Verlag für Sozialwissenschaften, Springer Fachmedien Wiesbaden GmbH 2010, ISBN: 978-3-531-17332-0
9.3.2 Sammelwerke
Controlling als akademische Disziplin, Herausgeber: Jürgen Weber, Bernhard Hirsch, Schriften des Center for Controlling & Management (CCM), 1. Auflage November 2002, Band 7, Deutscher Universitätsverlag GmbH, Wiesbaden 2002, ISBN: 3-8244-7693-2
Governance – Regieren in komplexen Regelsystemen, 2. aktualisierte und überarbeitete Auflage 2010, Herausgeber: Arthur Benz, Susanne Lütz, Uwe Schimak, Georg Simonis, VS Verlag für Sozialwissenschaften, Springer Fachmedien Wiesbaden GmbH 2010, ISBN: 978-3-531-17332-0
Handbuch Governance, Herausgeber: Arthur Benz, Susanne Lütz, Uew Schimanek, Georg Simonis (Herausgeber, 2007), 1. Auflage Juni 2007, VS Verlag für Sozialwissenschaften, Springer Fachmedien Wiesbaden GmbH 2007, ISBN: 978-3-531-14748-2
Software Process Improvement and Capability Determination, Herausgeber: Rory V. O’Connor, Terry Rout, Feragl McCaffery, Alec Dorling, 11th International Conference SPICE 2011, Dublin, Springer Verlag Berlin Heidelberg 2011, ISBN: 978-3-642-21232-1
IT-Governance in Praxis der Wirtschaftsinformatik, Herausgeber: Hans-Peter Fröschle, Susanne Strahringer, HMD Heft 250, August 2006, dpunkt.verlag, ISBN: 3-89864-382-4
Wer regiert die Welt und mit welchem Recht? (2009), Beiträge zur Global Goverance-Forschung, Herausgeber Volker Rittberger, Theodor Eschenburg Vorlesungen, Band 4, Nomos Verlagsgesellschaft, Baden-Baden, ISBN: 978-3-8329-4179-6
9.3.4 Dokumente aus dem HERMES-Projekt und des Bundes
Arbeitsgruppe IT Government Audit, Empfehlungen der Schweizerischen Finanzkontrollen für Informatikprojekte, V.2.0
Bernhard Kruschitz (2011), Governance mit HERMES 5, Version 0.7 vom 09.12.2011, Informatikstrategieorgan Bund ISB
Bernhard Kruschitz (2012), HERMES 5: Methodenbeschreibung: Modul Projektmanagement, Version 0.1 vom 24.1.2012, Informatikstrategieorgan Bund ISB
Guido Eicher, Roger Griessen, Hélène Mourgue d'Algue, Sven Guyet, Bernhard Kruschitz, Detailstudie zur Methode HERMES 5, Version 1.1. vom 16.9.2011, Informatikstrategieorgan des Bundes ISB
HERMES, Führen und Abwickeln von Projekten der Informatik- und Kommunikationstechnik (IKT), Systemadaption, Ausgabe April 2005 (2. Auflage, überarbeitet August 2009), Art.-Nr. 609.202 d Informatikstrategieorgan Bund ISB, CH-3003 Bern
HERMES, Führen und Abwickeln von Projekten der Informatik- und Kommunikationstechnik (IKT), Systementwicklung, Ausgabe Februar 2004, Art.-Nr. 609.201 d Informatikstrategieorgan Bund ISB, CH-3003 Bern
P007 – Richtlinien für Projektführung in Informatikprojekten, Version 2.03 vom 26.08.2011, Informatikrat Bund (IRB), vertreten durch das ISB, genehmigt am 14.09.2004
Bundesgesetz über die Börsen und den Effektenhandel (Börsengesetz, BEHG), SR 954.1 vom 24. März 1995 (Stand am 1. September 2011)
JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012
108 / 110
Bundesgesetz über die Eidgenössische Finanzkontrolle (Finanzkontrollgesetz), SR 614.0 vom 28. Juni 1967 (Stand am 1. Januar 2012)
Verordnung vom 24. April 2002 über die Führung und Aufbewahrung der Geschäftsbücher (Geschäftsbücherverordnung; GeBüV), SR 221.431 vom 24. April 2002 (Stand am 18. Juni 2002)
Verordnung des EVD über die Anpassung der Schwellenwerte im öffentlichen Beschaffungswesen für die Jahre 2012 und 2013 vom 23. November 2011, SR 172.056.1
9.3.6 Organisationen
COSO, Committee of Sponsoring Organizations of the Treadeway Commission. http://www.coso.org
DIN, Deutsches Institut für Normung e. V., Am DIN-Platz, Burggrafenstrasse 6, 10787 Berlin, http://www.din.de