Voraussetzungen für die Audit-Fähigkeit bei HERMES 5 ... · MEA Monitor, Evaluate, Assess (COBIT...

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

JÜRG BRINER AUDITFÄHIGKEIT HERMES 5 26.02.2012

2 / 110

I MANAGEMENT SUMMARY

I.I AUSGANGSLAGE

Die Projektführungsmethodik HERMES des Bundes wird weiterentwickelt. Dabei will man die

Methode einfacher machen und besser strukturieren, sowie auch die IT-Governance stärker

berücksichtigen. Als Grundlagen für die IT-Governance soll das Framework COBIT der

ISACA verwendet werden.

Sowohl HERMES als auch COBIT sind noch in Entwicklung. Diese Arbeit basiert auf einer

Draft-Version von COBIT und auf der Detailstudie von HERMES 5.

I.II ZIEL

Das wichtigste Ziel dieser Arbeit ist die Prüfung der Auditierbarkeit der

Projektführungsmethode HERMES, bezogen auf den IT-Governance-Standard COBIT.

I.III ERGEBNISSE

Die Auditierbarkeit von Projekten auf der Basis von COBIT ist möglich. Es ist folgendes zu

beachten:

Eine Auditierung nur nach dem Standard COBIT sollte überprüft und auch mit der EFK,

allenfalls der Arbeitsgruppe der Schweizerischen Finanzkontrollen, abgestimmt werden. Bei

Audits werden oft auch andere Standards als Vorgabe benutzt.

Eine vollständige Implementation von COBIT in HERMES 5 ist aufwendig und es wird

empfohlen, dies auf die Projektgrösse abzustimmen. Ein abgestuftes Verfahren bezogen auf

die Projektgrösse erscheint sinnvoller. So kann in kleinen und mittleren Projekten der

Aufwand in vertretbarer Grösse gehalten werden. Grundsätze der Governance können

trotzdem verlangt werden.

COBIT ist ausserdem ein generisches Framework. Deshalb müsste man, um exakt zu sein,

zuerst COBIT der Verwaltung des Bundes respektive den Nutzern von HERMES anpassen

und dann auf diesen definierten Zielen und Prozessen die Governance in der Projektführung

festlegen. Alternativ könnte man prüfen, ob der generische Ansatz gültig ist.

Man kann im Grundsatz festhalten, dass der Einbezug vom COBIT 5 Framework für die

Gestaltung von HERMES 5 einen Fortschritt bezüglich der Governance bringen wird.


3 / 110

II INHALTSVERZEICHNIS

I Management Summary ................................................................................................... 2

I.I Ausgangslage .................................................................................................................. 2

I.II Ziel ................................................................................................................................ 2

I.III Ergebnisse ................................................................................................................... 2

II Inhaltsverzeichnis ........................................................................................................... 3

III Vorwort ............................................................................................................................. 6

IV Glossar ............................................................................................................................. 7

1 Einführung in das Gebiet ............................................................................................. 11

1.1 Ausgangslage .......................................................................................................... 11 1.2 Problemanalyse ....................................................................................................... 11

2 Zielsetzung .................................................................................................................... 12

2.1 Inhaltliche Abgrenzung ............................................................................................ 12 2.2 Machbarkeit ............................................................................................................. 13

3 Methodische Vorgehensweise ..................................................................................... 14

4 Grundlagen .................................................................................................................... 15

4.1 Governance ............................................................................................................. 15 4.1.1 Good Governance ......................................................................................................... 16

4.1.2 Global Governance ........................................................................................................ 17

4.1.3 Corporate Governance .................................................................................................. 18

4.1.4 IT-Governance ............................................................................................................... 20

4.1.5 Project Governance ....................................................................................................... 21

4.2 Audit / Review / Prüfung .......................................................................................... 22 4.2.1 Prüfung .......................................................................................................................... 23

4.2.2 Review ........................................................................................................................... 23

4.2.3 Audit ............................................................................................................................... 25

4.2.4 Projektaudit .................................................................................................................... 26

4.2.5 Projektmanagement-Audit ............................................................................................. 27

4.3 Controlling ................................................................................................................ 27 4.4 Organisationen ......................................................................................................... 33

4.4.1 COSO ............................................................................................................................ 33

4.4.2 ISACA ............................................................................................................................ 34

4.4.3 ITGI ................................................................................................................................ 34

4.5 Maturity Modell ......................................................................................................... 35 4.5.1 CMMI ............................................................................................................................. 35

4.5.2 ISO/IEC 15504, SPICE .................................................................................................. 37

4.6 HERMES .................................................................................................................. 38


4 / 110

4.6.1 Die Entstehungsgeschichte von HERMES .................................................................... 38

4.6.2 Fachgruppe eCH und SAQ-Zertifikate .......................................................................... 39

4.6.3 Die Grundzüge der Projektführungsmethode HERMES ............................................... 39

4.6.4 Projektkategorien ........................................................................................................... 40

4.6.5 HERMES - Vorgehen .................................................................................................... 40

4.6.6 HERMES - Ergebnisse .................................................................................................. 42

4.6.7 HERMES - Rollen .......................................................................................................... 43

4.6.8 Tailoring ......................................................................................................................... 44

4.7 HERMES 5 - Quo Vadis? ......................................................................................... 45 4.8 Wichtigste Änderungen in HERMES 5 ..................................................................... 46

4.8.1 Übersicht ........................................................................................................................ 46

4.8.2 Projektszenarien ............................................................................................................ 47

4.8.3 Arbeitspaket und Projektstrukturplan ............................................................................ 48

4.8.4 Starter-Kit ....................................................................................................................... 48

4.8.5 IT-Governance / Audit ................................................................................................... 48

4.9 COBIT 5 ................................................................................................................... 49 4.9.1 COBIT - Übersicht ......................................................................................................... 49

4.9.2 COBIT 5 - Prinzipien ...................................................................................................... 50

4.9.3 COBIT 5 - Ziel-Kaskade ................................................................................................ 53

4.9.4 COBIT 5 - Disclaimer ..................................................................................................... 58

4.9.5 COBIT 5 - Enabler-Modell ............................................................................................. 59

4.9.6 COBIT 5 - Prozesse ...................................................................................................... 62

4.9.7 Aufbau COBIT-Dokumentation ...................................................................................... 64

5 Anforderungen .............................................................................................................. 65

5.1 Anforderung gemäss Detailstudie HERMES 5 ........................................................ 65 5.2 Anforderungen der EFK ........................................................................................... 66

5.2.1 Die EFK ......................................................................................................................... 66

5.2.2 Fachbereich 4, Informatikprüfungen .............................................................................. 66

5.2.3 Regelwerke für die EFK ................................................................................................. 67

5.2.4 Empfehlungen der EFK für Informatikprojekte .............................................................. 67

5.2.5 EFK und COBIT ............................................................................................................. 68

5.3 Anforderungen aus COBIT ...................................................................................... 69 5.4 Zusammenfassung der Anforderungen ................................................................... 70

6 Der Massstab: COBIT ................................................................................................... 71

6.1 COBIT als Referenz für ein Audit ............................................................................. 71 6.2 Governance-Aspekte ............................................................................................... 72 6.3 Controlling ................................................................................................................ 73 6.4 Ergebnisse, Vorgehen, Rollen ................................................................................. 74

7 Anforderungen an HERMES-Ergebnisse .................................................................... 76

7.1 Matching-Tabellen ................................................................................................... 76 7.1.1 Haupt-Tabelle Prozess BAI01 „Manage Programmes and Projects“ ............................ 77

7.1.2 BAI01.01: Maintain a standard approach for programme and project management .... 79

7.1.3 BAI01.02: Initate a programme ...................................................................................... 80

7.1.4 BAI01.03: Manage stakeholder engagements .............................................................. 80

7.1.5 BAI01.04: Develop and maintain the programme plan ................................................. 81


5 / 110

7.1.6 BAI01.05: Launch and execute the programme ............................................................ 81

7.1.7 BAI01.06: Monitor, control and report on the programme outcomes ............................ 82

7.1.8 BAI01.07: Start up and initiate projects within a programme ........................................ 82

7.1.9 BAI01.08: Plan projects ................................................................................................. 82

7.1.10 BAI01.09: Manage programme and project quality ....................................................... 83

7.1.11 BAI01.10: Manage programme and project risk ............................................................ 83

7.1.12 BAI01.11: Monitor and control a project ........................................................................ 84

7.1.13 BAI01.12: Execute a project .......................................................................................... 85

7.1.14 BAI01.13: Close a project .............................................................................................. 85

7.1.15 BAI01.14: Close a programme ...................................................................................... 85

7.2 Quercheck COBIT und EFK-Empfehlungen ............................................................ 86 7.2.1 EFK-Empfehlung: Mapping COBIT 4.1 – COBIT 5 ....................................................... 86

7.2.2 EFK-Empfehlung: Ergebnisse nach COBIT 5 ............................................................... 86

8 Schlussfolgerungen und Empfehlungen .................................................................... 88

8.1 Disclaimer: Exposure Draft ...................................................................................... 88 8.2 Schlussfolgerungen ................................................................................................. 88

8.2.1 Auditierbarkeit ................................................................................................................ 88

8.2.2 Lösungsansätze ............................................................................................................. 91

8.2.3 Grundlage White Paper ................................................................................................. 91

8.2.4 Audit bestehen ............................................................................................................... 92

8.2.5 Verbesserung Governance ............................................................................................ 92

8.3 Empfehlungen .......................................................................................................... 93

9 Anhang ........................................................................................................................... 98

9.1 Dokumente & Tabellen ............................................................................................ 98 9.1.1 EFK-Empfehlung: Mapping COBIT 4.1 – COBIT 5 ....................................................... 98

9.1.2 EFK-Empfehlung: Ergebnisse nach COBIT 5 ............................................................. 100

9.2 Danksagungen ....................................................................................................... 104 9.3 Literaturverzeichnis ................................................................................................ 104

9.3.1 Literatur ........................................................................................................................ 104

9.3.2 Sammelwerke .............................................................................................................. 107

9.3.3 Fachzeitschriften, Journale, Zeitungen ....................................................................... 107

9.3.4 Dokumente aus dem HERMES-Projekt und des Bundes ........................................... 107

9.3.5 Botschaften, Gesetze, Verordnungen ......................................................................... 107

9.3.6 Organisationen ............................................................................................................ 108

9.3.7 Normen & Standards ................................................................................................... 108

9.3.8 Intranet ......................................................................................................................... 109

9.3.9 Internet ......................................................................................................................... 109

9.4 Tabellenverzeichnis ............................................................................................... 110 9.5 Abbildungsverzeichnis ........................................................................................... 110


6 / 110

III VORWORT

Governance ist seit einigen Jahren in aller Munde, auch wenn der Ausdruck es an und für

sich nicht ist. Dafür sind aber umso mehr Reizwörter wie Dot.com- und Immobilien-Blase,

Finanzkrise, Griechenland, Wulff, etc. bekannt. Diese stehen u.a. für Verhaltensweisen wie

unverantwortliche oder unvernünftige Führung, persönliche Machtansprüche oder finanzielle

Bevorteilung. Teilweise werden diese auch gefördert durch falsche Anreize oder es werden

einfach offensichtliche Risiken und Warnungen für fehlerhaftes Verhalten ignoriert.

Es ist deshalb sinnvoll, Mechanismen zu definieren, die die negativen Auswirkungen zu

verhindern suchen. Der Einbezug der Governance ist damit u.a. auch in der

Projektabwicklung sinnvoll und notwendig. Bei Bau- oder anderen grossen Projekten ist das

einleuchtend, doch auch IT-Projekte sollten nach den Grundprinzipien der Governance

durchgeführt werden. Und gerade in der öffentlichen Verwaltung, die mehr im

Scheinwerferlicht steht als privatrechtliche Unternehmungen, muss die Führungs-

verantwortung sehr ernst genommen werden.

In meiner täglichen Arbeit als Projektleiter in einer öffentlichen Verwaltung habe ich auch mit

HERMES zu tun. Da ich diese Methode erst seit einem Jahr „obligatorisch“ anwenden muss,

habe ich persönlich viel dazugelernt und davon profitiert, diese Zusammenhänge

untersuchen zu können.

Während des Schreibens der Arbeit kamen mir immer mehr Ideen, was man noch

aufnehmen sollte und über welche Themen man weiter nachforschen könnte. Wie hatte doch

einst Sokrates gesagt:„Ich weiss, dass ich nichts weiss“. So kam es mir tatsächlich auch vor,

denn je länger ich an der Arbeit schrieb und forschte, desto mehr wusste ich „was ich noch

nicht weiss“.

Das Projekt von HERMES 5 wird sehr systematisch weiterentwickelt. Durch meine Arbeit

habe ich Einblick in die Weiterentwicklung von HERMES erhalten, die mich sehr positiv

gestimmt haben. Es würde mich natürlich freuen, wenn ich etwas zum Projekt beitragen

könnte und das eine oder andere Resultat oder auch eine Empfehlung aus dieser Arbeit in

HERMES 5 wieder zu finden wären.

Jürg Briner


7 / 110

IV GLOSSAR

AAA American Accounting Association

AI Acquire and Implement (COBIT 4.1)

AICPA American Institute of Certified Public Accountants

AKV Aufgaben, Kompetenzen, Verantwortung

APO Align, Plan, Organize (COBIT 5)

BAI Build, Plan, Organize (COBIT 5)

BMIS Business Model for Information Security

BSC Balanced Score Card

CEO Chief Executive Officer

CGEIT Certified in the Governance of Enterprise IT

CGG Commission on Global Governance

CISA Certified Information Systems Auditor

CISM Certified Information Security Manager

CISR MIT Center for Information Systems Research

CMM Capability Maturity Model

CMMI Capability Maturity Model Integration

CMMI-ACQ CMMI for Acquisition

CMMI-DEV CMMI for Development

CMMI-SVC CMMI for Services

COBIT Control Objectives for Information and Related Technology

COSO Committee of Sponsoring Organizations of the Treadway Commission

CRISC Certified in Risk and Information Systems Control

DIN Deutsches Institut für Normung e.V.

DIS Draft International Standard (ISO)

DS Deliver and Support (COBIT 4.1)

DSS Deliver, Service, Support

eCH Verein eCH

EDM Evaluate, Direct, Monitor (COBIT 5)


8 / 110

EDP Electronic Data Processing

EDPAA Electronic Data Processing Auditors Association

EDV Elektronische Datenverarbeitung

EFK Eidgenössische Finanzkontrolle

EJPD Eidgenössisches Justiz- und Polizeidepartement

EN Europäische Norm

ERM Enterprise Risk Management

ERP Enterprise Resource Planning

FEI Financial Executives International

HERMES Handbuch der Elektronischen Rechenzentren des Bundes, Methode für die

Entwicklung von Systemen

HMD Handbuch der modernen Datenverarbeitung

HSPM HERMES Swiss Project Manager

HSPTP HERMES Swiss Project Team Professional

HWP Schweizer Handbuch der Wirtschaftsprüfung

HWZ Hochschule für Wirtschaft Zürich

ICM Integrated Project Management

ICT Information and Communication Technology

ICTL Informatik Controller

IEC International Electrotechnical Commission

IIA Institute of Internal Auditors

IKS Internes Kontrollsystem

IKT Informations- und Kommunikationstechnologie

IMA Institute of Management Accountants

IPMA International Project Management Association

ISACA Information Systems Audit and Control Association

ISB Informatiksteuerungsorgan des Bundes

ISBN International Standard Book Number

ISDS Informationssicherheits- und Datenschutzkonzept

ISO International Standard of Organization


9 / 110

IT Information Technology

ITAF Information Technology Assurance Framework

ITAG IT Alignment and Governance Research

ITGI Information Governance Institut

ITIL Information Technology Infrastructure Library

KK Koordinations- und Kontrollstellen

KPI Key Performance Indicator

KVP Kontinuierlicher Veränderungsprozess

MAS Master of Advanced Studies

ME Monitor and Evaluate (COBIT 4.1)

MEA Monitor, Evaluate, Assess (COBIT 5)

MEI Monitor, Evaluate, Inform (COBIT 5)

ML Maturity Level

NASDAQ National Association of Securities Dealers Automated Quotations

NCB National Competence Baseline

NGO Non Governmental Organisation

NYSE New York Stock Exchange

OM Organisations- bzw. Operationsmanagement

PMBOK Guide to the Project Management Body of Knowledge

PMI Project Management Institute

PMO Project Management Office

PMP Project Management Professional

PO Plan and Organise (COBIT 4.1)

POSAT ZH Projektmanagement Handbuch Kanton Zürich

PRINCE2 Projects in Controlled Environments

RACI Responsible, Accountable, Consulted, Informed (COBIT 5)

Risk IT Framework for Management of IT Related Business Risks

RLCG Richtlinie betreffend Informationen zur Corporate Governance

RSKM Risiko Management

SA System Adaption


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


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


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


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


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.


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

9 Brockhaus in 15 Bänden. Leipzig, Mannheim: F. A. Brockhaus 2002-2006. Verlag: © Brockhaus in der

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


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.

Brockhaus 2005-06. Verlag: © Brockhaus in der Wissenmedia, https://10920.lip.e-content.duden-business.com/lip-suche/-/lip_article/B24/600129263 , letzter Zugriff: 13. Januar 2012

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


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


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

28 Gabler Verlag (Herausgeber), Gabler Wirtschaftslexikon, Stichwort: Corporate Governance http://wirtschaftslexikon.gabler.de/Archiv/55268/corporate-governance-v5.html, letzter Zugriff: 22. Februar 2011

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


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


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


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


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


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.

A. Brockhaus 2005-06. Verlag: © Brockhaus in der Wissenmedia, https://10920.lip.e-content.duden-business.com/lip-suche/-/lip_article/B24/17057606, letzter Zugriff: 13. Januar 2012

54 vgl. Quelle: Brockhaus in 15 Bänden. Leipzig, Mannheim: F. A. Brockhaus 2002-2006. Permanent aktualisierte Online-Auflage.Verlag: © Brockhaus in der Wissenmedia. https://10920.lip.e-content.duden-business.com/lip-suche/-/lip_article/B15/41065300, letzter Zugriff: 30. Dezember 2011

55 Duden – Das Große Fremdwörterbuch. 4., aktualisierte Auflage. Mannheim, Leipzig, Wien, Zürich: Dudenverlag 2003. Verlag: © Dudenverlag, https://10920.lip.e-content.duden-business.com/lip-suche/-/lip_article/dgfw/56153, letzter Zugriff: 30. Dezember 2011

56 Gabler Verlag (Herausgeber), Gabler Wirtschaftslexikon, Stichwort: Review, online im Internet: http://wirtschaftslexikon.gabler.de/Archiv/77313/review-v5.html, letzter Zugriff: 22. Februar 2012

57 vgl. http://www.linguee.de/deutsch-englisch/search?source=auto&query=review, letzter Zugriff: 29. Dezeember 2011

58 vgl. Karl Pfetzing, Adolf Rhode (2009), Ganzheitliches Projektmanagement, ibo Schriftenreihe Band 2, 3. Auflage, Verlag Dr. Götz Schmidt, Seiten 299-300


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


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

64 vgl. Software Quality Labs, Spezifikations-Reviews, http://www.software-quality-

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

Gegenwartssprache. 6., überarbeitete Auflage. Mannheim, Leipzig, Wien, Zürich: Dudenverlag 2007, https://10920.lip.e-content.duden-business.com/lip-suche/-/lip_article/fx/10698, letzter Zugriff: 10. Dezember 2011

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


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


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


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


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


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“.

92 Zeitschrift für Controlling & Management, Sonderheft, Ausgabe 3/2011, 55. Jahrgang, Gabler Verlag / Springer

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


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


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-

Anforderungen, Herausgeber: Prof. Dr. Dr. h.c. Alfred Wagenhofer, © Erich Schmidt Verlag GmbH & Co., Berlin 2009, Seiten 16, 20

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


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


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


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

119 vgl. http://www.itgi.org/template_ITGI923a.html?Section=About_ITGI&Template=/ContentManagement/

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


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


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


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


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

definiert.

143 vgl. http://www.ech.ch/vechweb/page?p=dossier&documentNumber=eCH-0054&documentVersion=1.00,

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


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]


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]


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.

Abbildung 5: Ausschnitt Ergebnisse Voranalyse [Seite 62]


43 / 110

Abbildung 6 zeigt beispielhaft die tabellarische Auflistung der Ergebnisse.

Es werden folgende Spalten aufgeführt:

Aktivität Beschreibung der Aktivität

SM Definierung Submodell

Ergebnisse Das Ergebnis, das zu erarbeiten ist

A Die ausführende Rolle

mA Wer mitausführend ist

E Wer entscheidet

4.6.7 HERMES - Rollen

Die Rollen basieren auf der Projektorganisation mit klar definierten Aufgaben, Kompetenzen

und Verantwortung (AKV). Die zentrale Verantwortung des Projektes wird durch den

Projektausschuss, Projektauftraggeber und den Account Manager wahrgenommen.

Die im Projekt benötigten Rollen werden im Projekthandbuch beschrieben, die nächste

Abbildung zeigt die schematische Übersicht der Rollen.

HERMES kennt direkt involvierte Rollen, aber es gibt auch die Linienstellen, Stabstellen,

Gremien und Kommissionen welche übergreifend in verschiedenen Projekten einer

Organisation tätig sind. In der nächsten Abbildung sind diese ganz oben eingezeichnet.

Diese Personen/Funktionen bekleiden gleichzeitig innerhalb der Projektorganisation die

Koordinations- und Kontrollstellen (KK), welche sich bereichsübergreifend mit der

Koordination befassen oder Kontrollfunktionen ausüben.

Eine Wahrheit, die nicht nur bei HERMES gilt: „Die personelle Besetzung einer

Projektorganisation ist ein wesentlicher Erfolgsfaktor. Sie muss insbesondere sicherstellen,

dass die notwendigen Qualifikationen zur Verfügung stehen, und dass effektive Teamarbeit

geleistet wird“. So explizit [Seite 264] wird es aber selten definiert.

Abbildung 6: Tabelle Ergebnisse (Ausschnitt Voranalyse [Seite 62])


44 / 110

4.6.8 Tailoring

Unter „Tailoring“ versteht man das Anpassen der Ergebnisse, Rollen und Vorgehen auf die

für das Projekt notwendigen und erforderlichen Angaben. Damit verhindert man eine

Dokumentation, bei der der Aufwand für die Erstellung der Ergebnisse mit mehr Arbeit

verbunden ist, als für die Durchführung des Projektes selbst. HERMES soll nicht eine

Methode für den Selbstzweck sein, sondern zur Erhöhung der Qualität in der Projektarbeit,

dem Projektergebnis und dem Management von Projekten beitragen.

Tailoring ist eine ständige Aufgabe des Projekleiters und wird meist zu Beginn des Projektes

und jeweils zu Beginn jeder Phase intensiv durchgeführt.

Abbildung 7: Projektorganisation und Rollen in HERMES 2005 SA [Seite 53]


45 / 110

Im Prinzip gibt es nur zwei Ergebnisse, die zwingend vorhanden sein müssen: der

Projektantrag und das Projekthandbuch. Alle weiteren Ergebnisse können und sollen nach

den Bedürfnissen des Projektes angepasst werden. Es müssen alle Ergebnisse

berücksichtigt werden, welche für die Systemerstellung, die Entscheidungen und für die

Dokumentation notwendig sind. Dies betrifft das Ergebnis selbst, als auch der Inhalt des

Ergebnisses. Wichtig zu verstehen ist, dass mittels Tailoring der Umfang der Ergebnisse

selbst dokumentiert wird.

Bezüglich den Projektphasen dürfen „Voranalyse“ und „Konzept“ für Projekttyp SE oder

„Voranalyse“ und „Evaluation“ für Projektyp SA zusammengelegt werden. Alle anderen

Phasen müssen durchlaufen werden.

4.7 HERMES 5 - Quo Vadis?

HERMES 5.0 ist mitten in der Weiterentwicklung, man überarbeitet die aktuelle Version mit

folgenden Zielsetzungen:

Zielsetzungen des Bundes für die Weiterentwicklung von HERMES149

Positionierung: Die Position von HERMES gegenüber anderen Methoden ist überprüft

und nötige Anpassungen sind identifiziert.

Struktur: Der Aufbau der Methode mit Projekttypen, Submodellen, Rollen, Aktivitäten,

Ergebnissen und Arbeitstechniken ist überprüft und zweckmässige Optimierungen sind

umgesetzt.

Publikation: Die Methode wird auf anwenderfreundliche Weise und mit angemessenem

Aufwand publiziert

Pflege: Die Verwaltung der Methode erfolgt qualitätsorientiert und effizient.

Einsatzfähige Minimallösung: Eine einsatzfähige Einstiegslösung der Methode, welche

eine minimale Menge der zu erstellenden Ergebnisse beinhaltet.

Umfang der Methode: HERMES unterstützt einen professionalen Start eines Projektes.

Werteumgebung: Die grundsätzlichen Werte von HERMES, welche Vollständigkeit,

Verständlichkeit, Offenheit, Flexibilität und Standardisierung sind, werden in der

Weiterentwicklung der Methode berücksichtigt.

149 Informatikstrategieorgan Bund ISB, HERMES - Die schweizerische Projektführungsmethode,

http://www.hermes.admin.ch/ueber-hermes/projekt-hermes-weiterentwicklung/globale-und-hauptziele, letzter Zugriff: 22. Februar 2012


46 / 110

4.8 Wichtigste Änderungen in HERMES 5

4.8.1 Übersicht

Im Grundsatz soll HERMES 5 einfacher in der Handhabung sein, trotzdem soll es flexibler

eingesetzt werden können. In folgenden Punkten gibt es markante Abweichungen150:

Es gibt nur noch ein Phasenmodell für alle Projekttypen: Anstelle Projekttypen

und eigenes Phasenmodell werden Projektszenarien verwendet.

Einführung Arbeitspaket und Projektstrukturplan.

Submodelle werden durch Module ersetzt.

Reduktion und Zusammenfassung von Ergebnissen sollen die

“Überdokumentation” und den administrativen Aufwand reduzieren.

Starter-Kit mit minimal benötigten Dokument-Vorlagen. Das Tailoring wird als

Arbeitstechnik aufgeführt und kann auch “revers” angewendet werden: Man

beginnt mit dem Starter-Kit und fügt hinzu, anstatt dass man das Maximal-

Programm nimmt und alles Überflüssige wegschneidet.

Stärkere Betonung der Steuerungs-, Führungs- und Ausführungsebene.

Reduktion des Dokumentationsumfangs von HERMES und Einsatz von

moderneren Tools zur Unterstützung.

IT-Governance im Projekt soll durch Definition von Minimalergebnissen gemäss

COBIT unterstützt sein. Ein HERMES 5-Projekt soll audit-tauglich sein.

Die Überprüfung der Wirtschaftlichkeit wird durch das ganze Projekt

durchgezogen. Unter Wirtschaftlichkeit darf auch das wirtschaftliche oder

effiziente Abwickeln eines Projektes verstanden werden. Z.B. sind Projekte

aufgrund von Gesetzesvorgaben nicht immer „wirtschaftlich“ im engsten Sinne

des Wortes und haben direkte Erträge, sie müssen aber trotzdem realisiert

werden.

150 vgl. Guido Eicher et al. Detailstudie zur Methode HERMES 5, Version 1.1. vom 16.9.2011,

Informatikstrategieorgan des Bundes ISB, Seiten 7-13


47 / 110

4.8.2 Projektszenarien

Gemäss Detailkonzept HERMES 5 gibt es neu Projektszenarien. Mit einem Szenario werden

Projekte mit einem gleichen oder ähnlichen Charakter abgewickelt. Man kann sich das so

vorstellen: Ein Szenario stellt die Methodik dar, wie mit HERMES 2005 mittels Tailoring das

Vorgehen, die Ergebnisse und die Rollen für ein bestimmtes Vorhaben massgeschneidert

wurde.

Szenarium (z.B. Organisations-Projekt)

Initialisierung Voranalyse Konzept Realisierung Einführung Abschluss

Modul Projektmanagement

Modul Lösung

Modul Organisatorische Lösung

Szenarium SW-Individualentwicklung

………………………………………

Ergebnisse

Aufgaben

Aufgaben

Aufgaben

Modul Rechtliche Grundlagen

Modul ISDS

Aufgaben

Aufgaben

Szenarium IT-Infrastruktur-Ausbau

Projekt-Phasen

Mo

du

le

Ergebnisse Ergebnisse Ergebnisse Ergebnisse Ergebnisse

Abbildung 8: Projektszenarien (Eigene Darstellung)


48 / 110

Ein Szenario besteht aus der Zusammenfügen von Modulen. Die Module sind

themenspezifisch entwickelt. Ein Modul hat verschiedene Aufgaben. Diese Aufgaben können

einzeln oder in jeder Phase fällig sein und haben Ergebnisse. Gemäss dem Experten-

Workshop 5151 vom 24. Januar 2012 sind die Module wie folgt definiert:

Projektmanagement

Beschaffung

Lösungsentwicklung

IKT-Lösung

Organisatorische Lösung

IT-Migration

Testen

Rechtliche Grundlagen

ISDS

4.8.3 Arbeitspaket und Projektstrukturplan

In HERMES 2003/2005 enthält der Arbeitsauftrag alle relevanten Informationen zur

Erledigung einer gestellten Aufgabe. Nach Pfetzing/Rhode152 ist der Zweck von

Strukturplänen die grosse Projektaufgabe in kleinere, delegierbare Teile zu zerlegen. Nach

Jenny153 erhält der Projektleiter mit einem Strukturplan die notwendigen, planbaren und

kontrollierbaren modularen Teilaufgaben. In HERMES 5 werden Arbeitspakete und der

Projektstrukturplan neu eingeführt.

4.8.4 Starter-Kit

Ein Starter-Kit besteht aus den minimal notwendigen Unterlagen um HERMES einzusetzen.

4.8.5 IT-Governance / Audit

HERMES 5 will die Minimalanforderungen erfüllen, um ein Audit der EFK, basierend auf

COBIT, erfolgreich bestehen zu können.

Diese Anforderung in HERMES 5 ist der Auslöser dieser Master Thesis!

151 Präsentation Expertenworkshop, http://www.ehermes.ch/ueber-hermes/projekt-hermes-

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


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.


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


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.


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.


53 / 110

4.9.3 COBIT 5 - Ziel-Kaskade

Abbildung 9: Ziel-Kaskade (Eigene Darstellung nach [COBIT 5: Framework Seite 24])


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


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])


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



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



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



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


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])


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


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])


63 / 110

Abbildung 12: Prozess-Übersicht (Screenshot aus [COBIT 5: Process Seite 15])


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.


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

der HERMES-Ergebnisse erarbeitet werden.

167 vgl. http://www.hermes.admin.ch/ueber-hermes/projekt-hermes-weiterentwicklung/stand-des-projektes,

letzter Zugriff: 22. Februar 2012 168 Guido Eicher et al., Detailstudie zur Methode HERMES 5, Version 1.1. vom 16.9.2011,

Informatikstrategieorgan des Bundes ISB, Seiten 10-11


66 / 110

5.2 Anforderungen der EFK

5.2.1 Die EFK

Die Eidgenössische Finanzkontrolle169 (EFK) ist das oberste Finanzaufsichtsorgan des

Bundes. Sie unterstützt das Parlament und den Bundesrat, ist unabhängig und nur der

Verfassung und dem Gesetz verpflichtet. Der Aufgabenbereich ist im Bundesgesetz über die

Eidgenössische Finanzkontrolle (Finanzkontrollgesetz)170 geregelt.

Im Rahmen dieser Aufsicht prüft die EFK bei Dienststellen des Bundes, ob Ausgaben und

Einnahmen korrekt dokumentiert sind und ob sie den gesetzlichen Grundlagen entsprechen.

Weiter untersucht sie, ob das Ausgabegebaren wirtschaftlich ist, dass heisst, ob die Mittel

sparsam eingesetzt werden, ob Kosten und Nutzen in einem günstigen Verhältnis stehen

und ob die finanziellen Aufwendungen die erwartete Wirkung haben.

Die EFK führt auch Sonderprüfungen durch. Dazu zählen insbesondere Evaluationen und

Wirtschaftlichkeitsprüfungen, Informatikprüfungen und Bauprüfungen.

In der Matrix-Organisation der EFK gibt es sechs Prüfbereiche für die Departemente/Ämter

sowie sechs Fachbereiche (Matrix-Organisation). Die Fachbereiche nehmen in den

Prüfbereichen ihre Aufgaben themenbezogen wahr. Die Informatik ist im Fachbereich 4

angesiedelt.

5.2.2 Fachbereich 4, Informatikprüfungen

Ziel der Prüfhandlungen ist die Überprüfung des wirtschaftlichen Einsatzes von Finanzmitteln

bzw. des Finanzgebarens der Verwaltungseinheiten der zentralen und dezentralen

Bundesverwaltung. Im Vordergrund steht dabei die risiko-orientierte Beurteilung der

Informatikführung und der eingesetzten IKT-Mittel171.

Die Haupttätigkeiten sind:

Prüfungen durchführen, wenn Informatik-Anwendungen und -Systeme im

Einsatz sind oder in Entwicklung stehen

Finanzrevisoren unterstützen, um die mit elektronischen Mitteln verarbeiteten

Daten als ordnungsgemäss und nachvollziehbar zu bestätigen

169 http://www.efk.admin.ch, letzter Zugriff: 28. Januar 2012 170 http://www.admin.ch/ch/d/sr/614_0/index.html, letzter Zugriff: 28. Januar 2012 171 vgl. http://www.efk.admin.ch/index.php?option=com_content&view=article&id=219&Itemid=235&lang=de,

letzter Zugriff: 28. Januar 2012


67 / 110

Integrität, Vertraulichkeit und Verfügbarkeit von elektronisch gespeicherten

und verarbeiteten Daten hinterfragen und umgesetzte Massnahmen zur

Erfüllung der Anforderungen in diesen Bereichen auf Wirksamkeit prüfen

5.2.3 Regelwerke für die EFK

Die Audits der EFK basieren nicht nur auf COBIT. Gemäss Ihrem Auftrag werden weitere

gesetzliche Bestimmungen, Bundes-Interne Prozesse und Anforderungen sowie auch

Prüfungsstandards172 der Treuhand-Klammer und das Schweizer Handbuch der

Wirtschaftsprüfung (HWP) verwendet.

Für die Auditierung von Projekten benutzt die EFK u.a. die Empfehlungen173 der

„Schweizerischen Finanzkontrollen“ respektive der „Arbeitsgruppe IT Government Audit“.

Diese Arbeitsgruppe vereint die Informatik-Auditoren der öffentlichen Verwaltungen der

Schweiz. Die EFK ist Mitglied der Arbeitsgruppe und arbeitet demzufolge mit diesen

Empfehlungen.

Im Sinne einer Vereinfachung wird vorausgesetzt, dass diese Empfehlungen als

„Empfehlungen“ der EFK für das Auditieren von Projekten gelten und werden im folgenden

so bezeichnet.

5.2.4 Empfehlungen der EFK für Informatikprojekte

Mit diesen Empfehlungen will die EFK erreichen, dass die Ziele des sparsamen

Mitteleinsatzes, der Einhaltung der rechtlichen Erfordernisse und den Grundsätzen der

ordnungsgemässen Rechnungslegung erreicht werden. In diesen Empfehlungen wird

postuliert, dass 10 Dokumente für eine Revision unerlässlich sind, unabhängig von der

eingesetzten Projektmanagement-Methode.

In den Empfehlungen wird auch festgestellt, dass die Zielsetzungen mit den Zielen von

COBIT übereinstimmen und es wurden die 10 Dokumente auf die 7 Ziele gemapped Diese

sind: Effektivität, Effizienz, Einhaltung Gesetze, Integrität, Vertraulichkeit, Verfügbarkeit und

Zuverlässigkeit.

172 Schweizer Prüfungsstandards (PS), Ausgabe 2010, Treuhand-Kammer, Schweizerische Kammer der

Wirtschaftsprüfer und Steuerexperten 173 vgl. http://www.efk.admin.ch/images/stories/efk_dokumente/publikationen/fachtexte/NOVENA_V.2.0_d.pdf,

letzter Zugriff: 22. Februar 2012


68 / 110

Für jedes Schlüsseldokument wird kurz erklärt, was der Inhalt sein sollte. Zusätzlich erfolgt

ein (nicht abschliessender) Hinweis auf die Kapitel in einigen Standards, die für

Projektabwicklung genutzt werden: Hermes, POSAT ZH, COBIT, Prince2.

5.2.5 EFK und COBIT

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]


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


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.


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.


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.


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.


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.


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.


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.


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


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])


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:

Anforderungen/Scope, Ressourcen, Risiken, Kosten, Zeitplanung, Qualität, Kommunikation,

Stakeholder-Envolvement, Beschaffung, Change Management, Integration und

Wirtschaftlichkeits-Berechnung. Inklusive „Lessons learned“!

Die Methodik (mit Vorlagen) an und für sich ist hier das Ergebnis.

180 Kaizen, Begriff aus der japanischen Wirtschaft, der sich auf die permanente, schrittweise Verbesserung der

gesamten Arbeitsbereiche durch die Initiative der Mitarbeiterinnen und Mitarbeiter auf allen Unternehmensebenen bezieht. Voraussetzung eines solchen kontinuierlichen Verbesserungsprozesses (KVP) sind Teamgeist und Kommunikationsfähigkeit innerhalb der Belegschaft; alle sollen sich aufgefordert fühlen, zur Verbesserung ihres Arbeitsprozesses beizutragen. Quelle: Duden – Das Lexikon der Wirtschaft. Mannheim, Leipzig, Wien, Zürich; Dudenverlag 2001. Verlag: © Dudenverlag, https://10920.lip.e-content.duden-business.com/lip-suche/-/lip_article/duwilex/50000945, letzter Zugriff: 21. Januar 2012

181 Eine näher zu untersuchende Hypothese des Autors.


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.


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.


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“


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.


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.



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


82 / 110

7.1.7 BAI01.06: Monitor, control and report on the programme outcomes




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.


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.


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


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.


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.


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.


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.


Projekt KPI

Projekt Fortschritt Report

Change Management Plan


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.


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.


Reviews für die Kontrolle der erzielten Resultate

Projekt Lessons Learned

Genehmigung der Stakeholder des Projektes

7.1.15 BAI01.14: Close a programme





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


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.


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.


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.“


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.


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.


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.


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


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)

Starter-Kit generell

COBIT in den Vorlagen minimal integriert

Zuordnung Interner Controller

Kategorie B mittel > 250 kCHF bis < 1 Mio. CHF

Starter-Kit Szenario

COBIT in den Vorlagen teilweise integriert

Zuordnung Interner oder Externer Controller

HERMES-Zertifizierter PL notwendig

Kategorie A gross >= 1 Mio. CHF

Compliant mit COBIT und nach COBIT Auditierbar

Zuordnung Externer Controller

HERMES-Zertifizierter PL notwendig (ev. Governance-Zertifizierung)

Es kann auch geprüft werden, ob die COBIT-Compliance als Modul eingeführt werden kann.

Damit würde es dem Steuerungsausschuss und dem Auftraggeber zufallen, die Governance

COBIT-like einzuführen und zu bezahlen.

192 Verordnung des EVD über die Anpassung der Schwellenwerte im öffentlichen Beschaffungswesen für die

Jahre 2012 und 2013, http://www.admin.ch/ch/d/as/2011/5581.pdf, letzter Zugriff: 11. Februar 2012


95 / 110

Kosten

Die Kosten für die COBIT-Compliance sollten direkt dem Projekt belastet werden. D.h. die

Kosten für einen internen oder externen Controller und das Audit muss das Projekt selbst

tragen (Verursacher-Prinzip). Man könnte Vorgaben für die Budgetierung machen (Standard-

Beträge kalkulieren) oder sogar Standard-Aufträge in Form von Vorlagen für Controlling und

Auditierung erstellen.

Committment EFK / Schweizerische Finanzkontrollen für Informatikprojekte

Die EFK muss entweder festhalten, dass ein Projekt-Audit durch sie bestanden werden

kann, wenn das Projekt nach den Grundsätzen von COBIT durchgeführt wird, oder sie muss

HERMES 5 prüfen und das Committment für diese Version abgeben, damit es für ein Audit

genügt. In letzterem Falle wird HERMES 5 bestmöglichst nach COBIT implementiert, aber

nicht nur COBIT ist massgebend für die Ausgestaltung.

Ob die EFK diese Anforderungen definiert oder ob diese durch die „Schweizerischen

Finanzkontrollen für Informatikprojekte“ gestellt werden, ist zu prüfen. In dieser Arbeit hatte

man diese Empfehlungen der einfachheithalber der EFK zugeordnet. Hier muss man das

wieder trennen.

Controlling / Rollen

Wie in dieser Arbeit ausgeführt ist das Projekt-Controlling nicht nur Bestandteil der

Projektorganisation, sondern kann auch in Verbindung zur Governance gebracht werden. In

HERMES 2005 wird die Rolle des Controlling nach den in Kapitel 4.3 hergeleiteten Relevanz

des Controlling eher unterbewertet. In den Koordinations- und Kontrollstellen (KK) des

Rollenmodells von HERMES ist erwähnt, dass diese Funktionen „sich bereichsübergreifend

mit der Koordination befassen oder Kontrollfunktionen ausüben“.

Die Empfehlung sieht darum so aus: Gesamthaft und mit den erarbeiteten Grundlagen

müsste man die Controller zu mehr Verantwortung für die Überwachung und Steuerung des

Projektes verpflichten sowie ab einer bestimmten Projektgrösse als obligatorisch erklären. Es

ist auch zu prüfen, ob der Controller als „extern“ zu definieren ist. Mit „extern“ ist eine

unabhängige Stelle gemeint, die nicht direkt mit dem Vorhaben oder der Führung des Amtes

oder des Departementes in Verbindung steht.


96 / 110

Lessons Learned

COBIT verlangt nicht nur, dass am Ende von Projekten die „Lessons Learned“ erarbeitet

werden, sondern auch dass die Methodik jeweils angepasst wird „update the programme and

project management approach based on lessons learned from its use“.

Die Empfehlung lautet: Die Lessons Learned in den Update- und Weiterentwicklungsprozess

von HERMES integrieren.

Dazu wären alle auditierten Projekte des Bundes respektive alle nach HERMES 5 geführten

und auditierten Projekte einzuschliessen. Die Lessons learned gehören damit zu den

obligatorische Kontrollpunkten eines Audits. Da Audits aber üblicherweise vor dem Erstellen

der Lessons learned durchgeführt werden, können entweder aktuelle Lesson Learned zum

Zeitpunkt des Audits gefordert werden oder sie wären nachzuliefern.

Die Lessons Learned teilen sich auf in

Erfahrungen für das Projekt respektive Projekt-Team

Erfahrungen für die Unternehmung

Erfahrungen für die Methodik, Vorlagen oder Dokumentation von HERMES

Hier wird empfohlen, für alle drei Bereiche entsprechende Prozesse und Vorlagen

aufzusetzen.

Nach dem Model der Szenarien in HERMES 5 und der vorgesehenen Dokumentation mit

„Praxis“-Teil könnten die Lessons Learned jeweils direkt in den Szenarien im Praxis-Teil

einfliessen. Das könnte wiederum zu einer Art „Best Practice“ führen.

Vorbehalte generischer Ansatz (Disclaimer)

Um COBIT gerecht werden zu können, muss in HERMES, falls die in COBIT 5 verwendete

Ziel-Kaskade (Ziele, Prozesse, Enabler) als Referenz benutzt wird, ein Disclaimer analog

dem COBIT-Disclaimer angebracht werden193. Damit wird sichergestellt, dass sich die

Benutzer der HERMES-Methode bewusst sind, dass es sich um einen generischen Ansatz

handelt. Auch können Unternehmungen, die sich bereits an COBIT orientieren, die Methodik

respektive die Ergebnisse von HERMES dahingehend prüfen, ob es für sie immer noch

COBIT-konform ist.

193 COBIT 5, The Framework, Exposure Draft, ISACA, Seite 6


97 / 110

COBIT-Anforderungen markieren

Im Zusammenhang mit dem Controlling und einem Audit wäre es vorteilhaft für den

Projektleiter, man wüsste welches die (obligatorischen) Anforderungen sind. Deshalb wird

empfohlen, diese Ergebnisse entsprechend zu markieren. Ebenfalls vorteilhaft wäre es,

wenn auch die Vorlagen die entsprechende Information aufweisen würden.

Überprüfung Reifegrad der Prozesse

In den Schlussfolgerungen wurde bereits postuliert, dass man für alle durch das Projekt

verwendeten Prozesse den Reifegrad 1 voraussetzen muss. Was ist aber zu tun, wenn diese

Voraussetzung nicht erfüllt ist? Muss das Projekt hier nachbessern? Ab welchem Zeitpunkt

kann und muss man sicherstellen, dass das erfüllt ist?

Die Empfehlung lautet, dass man sich einerseits diesem Thema annehmen und weitere

Untersuchungen durchführen sollte. Andererseits ist diese Voraussetzung von perfekt

funktionierenden Prozessen erfahrungsgemäss problematisch. Dieses Thema ist deshalb als

Risiko in der Risikoliste eines Projektes aufzuführen. Es obliegt dann der Auftraggeberschaft

und der Projektleitung, sich diesem Risiko anzunehmen und es mittels qualitätssichernden

Massnahmen zu reduzieren.


98 / 110

9 ANHANG

9.1 Dokumente & Tabellen

9.1.1 EFK-Empfehlung: Mapping COBIT 4.1 – COBIT 5

Gegenüberstellung der Hinweise in den Empfehlungen der EFK, Basis COBIT 4.0, zu den

neuen Praktiken in COBIT 5. Mit * bezeichnete Praktiken gehören zu “Projekt-Management”.

Dokument EFK-Empfehlung Cobit 4.0/4.1 COBIT 5

Machbarkeitsstudie AI1.3 BAI02.2

Pflichtenheft PO10.5 BAI01.7*

AI1.1 BAI02.1

Wirschaftlichkeitsanalyse AI1.1 BAI02.1

AI1.2 BAI02.3

AI1.3 BAI02.2

Integration ins Informatikumfeld PO2 APO03.2, APO01.6

AI1.3 BAI02.2

Anforderungen PO2 APO03.2, APO01.6

ME 3 MEA03

Anforderungsbeispiele Keine direkten Referenzen

IKS PO8 APO011.1, .2, .3, .5, .6

AI1.1, AI1.2 BAI02.1, BAI02.3

AI2.2, AI2.3, BAI03.2, BAI03.5,

AI2.4 BAI03.1; BAI03.2; BAI03.3;

BAI03.5

DS4 DDS06

DS5 DSS07.1, .2, .4, .6, .7, .8,

APO01.6

DS11 DSS01.1, DSS06.8,


99 / 110

Dokument EFK-Empfehlung Cobit 4.0/4.1 COBIT 5

DSS7.8, DSS08.4, DSS08.5,

ME 2 MEA02.1, .2, .3, .4, .6, .7, .8

Systemarchitektur PO2, APO03.2, APO01.6

AI1.3 BAI02.2

AI2.1, AI2.2, BAI03.1, BAI03.2

AI2.5 BAI03.3; BAI03.5

AI2.6 BAI03.10

Tests PO8 APO011

AI2.8 BAI03.6

AI3.4 BAI03.7,BAI03.8

AI5.6 -

AI7.2 BAI07.1; BAI07.3

AI7.4, AI7.6, AI7.7 BAI07.4, BAI07.5, BAI07.5

Abnahme AI3.1, AI3.2, AI3.3 BAI03.4, BAI03.3, BAI03.10

AI7.6, AI7.7 BAI07.5, BAI07.5,

PO10.6 BAI01.7*

Schlussbilanz PO10.6 BAI01.7*

PO10.13 BAI01.6*; BAI01.11*

PO10.14 BAI01.13*

AI7.12 -

Tabelle 6: EFK-Empfehlung Mapping COBIT 4.1 - COBIT 5



100 / 110

9.1.2 EFK-Empfehlung: Ergebnisse nach COBIT 5

Ergebnisse die aus den COBIT 5 Praktiken, hergeleitet aus den Empfehlungen der EFK

resultieren. In dem Sinne sind das die transponierten Ergebnisse aller in den Empfehlungen

der EFK respektive der Schweizerischen Finanzkontrollen aufgeführten Hinweise.

Praktik COBIT 5 Ergebnis aus COBIT 5

APO01.6 Data classification guidelines

Data security and control

Data integrity procedures guidelines

APO03.2 Baseline domain descriptions and architecture definition

Process architecture model

Information architecture model

APO011.1 QMS roles, responsibilities and decision rights

Quality management plans

Results of QMS effectiveness reviews

APO011.2 Quality management standards

APO011.3 Customer requirements for quality management

Acceptance criteria

Review results of quality of service, including customer feedback

APO011.5 Results of solution and delivery quality service monitoring

Root causes of quality delivery failures

APO011.6 Communications on continual improvement and best practices

Examples of good practice to be shared

Quality review benchmark results

BAI01.6 Results of programme performance reviews

Stage-Gate review results

BAI01.7 Project scope statements

Project definitions


101 / 110


BAI01.11 Project performance criteria

Project progress reports

Agreed on hanges to project plan

BAI01.13 Post--implementation review results

Project lessons learned

Stakeholder project

Acceptance confirmations

BAI02.1 Requirements definition repository

Confirmed acceptance of requirements from stakeholders

Record of requirement change requests

BAI02.2 Feasibility study report

High--‐level acquisition/development plan

BAI02.3 Requirements risk register

Risk mitigation actions

BAI03.1 Approved high--‐level design specification

BAI03.2 Approved detailed design specification

BAI03.3 Documented solution components

BAI03.4 Approved acquisition plans

Updates to asset inventory

BAI03.5 Integrated and configured solution components

BAI03.6 Quality assurance plan

Quality review results, exceptions and corrections

BAI03.7 Test plan

Test procedures

BAI03.8 Test result logs and audit trails


102 / 110


Test result communications

BAI03.10 Maintenance plan

Updated solution components and related documentation

Periodic maintenance analyses

BAI07.1 Approved implementation plan

Implementation fallback and recovery process

BAI07.3 Approved acceptance test plan

BAI07.4 Test data

BAI07.5 Test results log

Evaluation of acceptance results

Approved acceptance and release for production

DSS01.1 Operational schedule

Backup log

DSS06 Alle Dokumente aus DSS06

DSS07.1 Malicious software prevention policy

Evaluations of potential threats

DSS07.2 Connectivity security policy

Results of penetration tests

DSS07.4 Approved user access rights

Results of reviews of users accounts and privileges

DSS07.6 Inventory of sensitive documents and devices access privileges

DSS07.7 Security incident characteristics

Security incident investigations and reviews

DSS07.8 Manage information handling

DSS08.4 Retention requirements


103 / 110


Record of transactions

DSS08.5 Reports of violations

MEA02.1 Results of internal control monitoring and reviews

Results of benchmarking and other evaluations

MEA02.2 Evidence of control effectiveness

MEA02.3 Self-Assessment plans and criteria

Results of self--assessments

Results of reviews of self--assessments

MEA02.4 Control deficiencies

Remedial actions

MEA02.6 High--‐level assessments

Assurance plans

Assessment criteria

MEA02.7 Assurance review scope

Engagement plan

Assurance review practices

MEA02.8 Refined scope

Assurance review results

Assurance review report

MEA03 Alle Dokumente aus MEA03

Tabelle 7: EFK-Empfehlung nach COBIT 5



104 / 110

9.2 Danksagungen

Mein Dank gilt allen, die mich in der Arbeit unterstützt haben, insbesondere:

der HERMES 5 Projektleiterin Frau Hélène Mourgue d’Algue für das Thema.

Herr Prof. Dr. Walter Kuhn für die Betreuung.

Herr Bernhard Kruschitz vom HERMES 5 Projekt-Team für die Beratung.

Frau Katharina Egli für das Lektorat.

den Interview-Partnern

der Stadt Zürich für die Teilfinanzierung der Master-Arbeit.

und nicht zuletzt auch meiner Frau Alice für ihre Geduld während ich am Schreiben und

Recherchieren war.

9.3 Literaturverzeichnis

Bei Sammelbänden sind die verwendeten Quellen sowohl für jeden zitierten Autor (im

Unterkapitel „Literatur“) als auch für das Sammelwerk (im Unterkapitel „Sammelwerke“)

aufgeführt.

9.3.1 Literatur

Alfred Blazek, Detlev R. Zillmer, (2001), Projekt-Controlling, VCW Verlag für Controllingwissen AG, Offenburg, Wörthsee-Etterschlag, ISBN: 3-7775-0256-1

Alfred Wagenhofer (2009), Corporate Governance und Controlling in Controlling und Corporate Governance-Anforderungen, Herausgeber: Prof. Dr. Dr. h.c. Alfred Wagenhofer, © Erich Schmidt Verlag GmbH & Co., Berlin 2009, ISBN: 978-3-503-11613-3

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

Bernhard Hobel, Silke Schütte (2006), Projektmanagement A-Z, Gabler Business-Wissen, Betriebswirtschaftlicher Verlag Dr. Th. Gabler | GWV Fachverlage GmbH, Wiesbaden 2006, ISBN-10: 3-409-12547-7

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


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

Internal Control – Integrated Framework, Committee of Sponsoring Organizations of the Treadway Commission COSO (1994), Two Volume Edition, July 1994 Edition, Copyright © 1992, 1994 by the Committee of Sponsoring Organizations of the Treadway Commission http://www.coso.org, Product Number: 990012

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

Hans-Peter Fröschle, Susanne Strahringer (2006), Praxis der Wirtschaftsinformatik, HMD, Herausgeber: Hans-Peter Fröschle, Susanne Strahringer, Heft 250, August 2006, dpunkt.verlag, ISBN: 3-89864-382-4

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

Karsten Paetzman (2008), Corporate Governance, Springer Verlag Berlin Heiderlberg, 2008, ISBN: 978-3-540-78410-1

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


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


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

Controlling und Corporate Governance-Anforderungen, Herausgeber: Prof. Dr. Dr. h.c. Alfred Wagenhofer, © Erich Schmidt Verlag GmbH & Co., Berlin 2009, ISBN: 978-3-503-11613-3

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.3 Fachzeitschriften, Journale, Zeitungen

Zeitschrift für Controlling & Management, Sonderheft, Ausgabe 3/2011, 55. Jahrgang, Gabler Verlag / Springer Fachmedien Wiesbaden GmbH

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

Präsentation Expertenworkshop, http://www.ehermes.ch/ueber-hermes/projekt-hermes-weiterentwicklung/stand-des-projektes

9.3.5 Botschaften, Gesetze, Verordnungen

Bundesgesetz über die Börsen und den Effektenhandel (Börsengesetz, BEHG), SR 954.1 vom 24. März 1995 (Stand am 1. September 2011)


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

eCH, Verein eCH - E-Government-Standards, Mainaustrasse 30, Postfach, 8034 Zürich, http://www.ech.ch

Economiesuisse, Verband der Schweizer Unternehmen, Spitalgasse 4, Postfach, CH-3001 Bern, http://www.economiesuisse.ch

ISACA, Information Systems Audit and Control Association, 3701 Algonquin Road, Suite 1010 | Rolling Meadows, IL 60008 USA, http://www.isaca.org

ISACA, Switzerland Chapter, c/o ITACS Training AG, Stampfenbachstrasse 40, 8006 Zürich, http://www.isaca.ch

ITGI, IT Governance Institute, 3701 Algonquin Road, Suite 1010, Rolling Meadows, IL, 60008 USA, http://www.itgi.org

ISO International Organization for Standardization, ISO Central Secretariat, 1, Ch. de la Voie-Creuse, 1211 Geneva 20, Switzerland, http://www.iso.org

SEI, Software Engineering Institute, 4500 Fifth Avenue, Pittsburgh, PA 15213-2612, USA, http://www.sei.cmu.edu

TREUHAND-KAMMER, Schweizerische Kammer der Wirtschaftsprüfer und Steuerexperten, Limmatquai 120, CH-8021 Zürich, http://www.treuhand-kammer.ch

VZPM, Verein zur Zertifizierung von Personen im Management, Flughofstrasse 50, CH-8152 Glattbrugg, http://www.vzpm.ch

9.3.7 Normen & Standards

BMIS, Business Model for Information Security, Organisation: ISACA

COBIT 4.0 (2005), Control Objectives, Management Guidelines, Maturity Models. Deutsche Ausgabe, Organisation: ITGI, Übersetzung KPMG Österreich (Wien). ISBN: 1-933284-37-4

COBIT 4.1, Framework, Control Objectives, Management Guidelines, Maturity Models, Organisation: ITGI, ISBN 1-933284-72-2

COBIT 5: The Framework, Exposure Draft, Organisation: ISACA

COBIT 5: Process Reference Guide, Exposure Draft, Organisation: ISACA

DIN 69901-1, Ausgabe 2009-01, Projektmanagement - Projektmanagementsysteme - Teil 1: Grundlagen, Organisation: DIN

DIN 69901-2, Ausgabe 2009-01, Projektmanagement - Projektmanagementsysteme - Teil 2: Prozesse, Prozessmodell Organisation: DIN

DIN 69901-3, Ausgabe 2009-01, Projektmanagement - Projektmanagementsysteme - Teil 3: Methoden, Organisation: DIN

DIN 69901-4, Ausgabe 2009-01, Projektmanagement - Projektmanagementsysteme - Teil 4: Daten, Datenmodell Organisation: DIN

DIN 69901-5, Ausgabe 2009-01, Projektmanagement - Projektmanagementsysteme - Teil 5: Begriffe, Organisation: DIN

DIN EN ISO 8402 (1986), Vorgänger von ISO 9001, Organisation: ISO

ISO 9001:2008, Ausgabe: 2008, Anforderungen an ein Qualitätsmanagement-System, Organisation: ISO

ISO/IEC 15504-5, Ausgabe 2006, An exemplar Process Assessment Model, Organisation: ISO

ISO/DIS 21500, Draft International Standard, Guidance on project management, Organisation: ISO

ISO/IEC 27001, Information Security Management System, Organisation: ISO


109 / 110

ITAF, Framework for IT-Audit und IT-Assurance, Organisation: ISACA

Risk IT, Framework for Management of IT Related Business Risks, Organisation: ISACA

Schweizer Prüfungsstandards (PS), Ausgabe 2010, Organisation: Treuhand-Kammer

Val IT, Framework for Business Technology Management, Organisation: ISACA

VZPM Beurteilungsstruktur, Swiss National Competence Baseline NCB, Version 4.0, Organisation: VZPM

9.3.8 Intranet

Firmeninterne Online-Ausgabe von: Brockhaus in 15 Bänden. Leipzig, Mannheim: F. A. Brockhaus 2002-2006. Verlag: © Brockhaus in der Wissenmedia

Firmeninterne Online-Ausgabe von: Brockhaus - Die Enzyklopädie in 30 Bänden. 21., neu bearbeitete Auflage. Leipzig, Mannheim: F. A. Brockhaus 2005-06. Verlag: © Brockhaus in der Wissenmedia

Firmeninterne Online-Ausgabe von: Duden – Das Lexikon der Wirtschaft. Mannheim, Leipzig, Wien, Zürich; Dudenverlag 2001. Verlag: © Dudenverlag

Firmeninterne Online-Ausgabe von: Duden – Das Grosse Fremdwörterbuch. 4., aktualisierte Auflage. Mannheim, Leipzig, Wien, Zürich: Dudenverlag 2003. Verlag: © Dudenverlag

Firmeninterne Online-Ausgabe von: Duden – Richtiges und gutes Deutsch. Wörterbuch der sprachlichen Zweifelsfälle - 6. Auflage. Bibliographisches Institut & F. A. Brockhaus AG, Mannheim, 2007, Verlag: © Dudenverlag

Firmeninterne Online-Ausgabe von: Duden – Deutsches Universalwörterbuch. Das umfassende Bedeutungswörterbuch der deutschen Gegenwartssprache. 6., überarbeitete Auflage. Mannheim, Leipzig, Wien, Zürich: Dudenverlag 2007. Verlag: © Dudenverlag

9.3.9 Internet

(Sortierung: Second-Level-domain; Alphabetisch)

http://www.admin.ch, Bundesbehörden der Schweizerischen Eidgenossenschaft

http://www.antwerpmanagementschool.be, Antwerp Management School, Sint-Jacobsmarkt 9-13, 2000 Antwerpen, Belgien

http://www.bkb.ch, Basler Kantonalbank, Postfach, 4002 Basel

http://www.businessdictionary.com, Webfinance Inc, 10201 Fairfax Boulevard, Suite 570 Fairfax, VA 22030, USA

http://www.efk.admin.ch, Eidgenössische Finanzkontrolle, Monbijoustrasse 45, CH-3003 Bern

http://www.ehermes.ch, Informatikstrategieorgan Bund ISB, Friedheimweg 14, 3003 Bern

http://wirtschaftslexikon.gabler.de, Gabler Wirtschaftslexikon, Gabler Verlag (Herausgeber), Abraham-Lincoln-Str. 46, 65189 Wiesbaden, Deutschland

http://www.hermes.admin.ch, Informatikstrategieorgan Bund ISB, Friedheimweg 14, 3003 Bern

http://www.isb.admin.ch, Informatikstrategieorgan Bund ISB, Friedheimweg 14, 3003 Bern

http://www.linguee.de, Linguee GmbH, Hohenzollernring 1, 50672 Köln, Deutschland

http://thomas.loc.gov, The Library of Congress, 101 Independence Ave, SE, Washington, DC 20540, USA

http://www.olev.de, Online-Verwaltungslexikon, Dr. Burkhardt Krems, Alteburgerstrasse 298, 50968 Köln, Deutschland

http://www.six-exchange-regulation.com, SIX Swiss Exchange AG, SIX Exchange Regulation, Selnaustrasse 30, Postfach 1758, CH-8021 Zürich

http://www.saq.ch, SAQ, Swiss Association for Quality, Stauffacherstrasse 65/42, CH-3014 Bern

http://www.snv.ch, SNV Schweizerische Normen-Vereinigung, Bürglistrasse 29, 8400 Winterthur

http://www.software-quality-lab.at, Software Quality Lab GmbH, Gewerbepark Urfahr 30, BG 4, 4041 Linz, Austria

http://www.spol.ch, SPOL AG, Höfenstrasse 33, CH-6312 Steinhausen

http://www.tamedia.ch, Tamedia AG, Werdstrasse 21, 8021 Zürich

http://www.wibas.de, wibas GmbH, Management Consultants, Otto-Hesse-Strasse 19 B, 64293 Darmstadt

http://de.wikipedia.org, Wikimedia Foundation Inc., 149 New Montgomery Street, 3rd Floor, San Francisco, CA 94105, USA


110 / 110

9.4 Tabellenverzeichnis

Tabelle 1: Anforderungen und Ziele 55

Tabelle 2: IT-bezogene Ziele 56

Tabelle 3: Ausschnitt IT- vs Unternehmensziele 57

Tabelle 4: Auszug IT-Ziele vs Prozesse 58

Tabelle 5: Prozess-Matching BAI01 78

Tabelle 6: EFK-Empfehlung Mapping COBIT 4.1 - COBIT 5 99

Tabelle 7: EFK-Empfehlung nach COBIT 5 103

9.5 Abbildungsverzeichnis

Abbildung 1: Die drei Pfeiler von HERMES [Seite 46] 39

Abbildung 2: Beurteilung der Projektkategorie [Seite 32] 40

Abbildung 3: Phasenmodell HERMES [Seite 8] 40

Abbildung 4: HERMES Phasenmodell SA und SE [Seite 49] 41

Abbildung 5: Ausschnitt Ergebnisse Voranalyse [Seite 62] 42

Abbildung 6: Tabelle Ergebnisse (Ausschnitt Voranalyse [Seite 62]) 43

Abbildung 7: Projektorganisation und Rollen in HERMES 2005 SA [Seite 53] 44

Abbildung 8: Projektszenarien (Eigene Darstellung) 47

Abbildung 9: Ziel-Kaskade (Eigene Darstellung nach [COBIT 5: Framework Seite 24]) 53

Abbildung 10: Enablermodell, (Eigene Darstellung nach [COBIT 5: Framework Seite 30]) 60

Abbildung 11: Prozess-Modell (Eigene Darstellung nach [COBIT 5: Framework Seite 35]) 62

Abbildung 12: Prozess-Übersicht (Screenshot aus [COBIT 5: Process Seite 15]) 63

Abbildung 13: Schlüsseldokumente EFK pro Phase [Quelle: EFK] 68

Voraussetzungen für die Audit-Fähigkeit bei HERMES 5 ... · MEA Monitor, Evaluate, Assess (COBIT...

Documents

Transcript of Voraussetzungen für die Audit-Fähigkeit bei HERMES 5 ... · MEA Monitor, Evaluate, Assess (COBIT...