COBIT kompakt und verständlich GERMAN

Wolfgang Goltsche

COBIT kompakt und verständlich

Aus dem Bereich IT erfolgreich gestalten

Visual Basic .NET mit Methode von Heinrich Rottmann Warum ausgerechnet .NET? von Heinrich Rottmann Requirements Analysis realisieren von Karl Scharbert Management der SoftwareEntwicklung von Carl Steinweg Das neue PL/I von Eberhard Sturm Projektmanagement der SW-Entwicklung von Werner Mellis Profikurs ABAP® von Patrick Theobald SAP R/3® Kommunikation mit RFC und Visual Basic von Patrick Theobald Six Sigma in der SW-Entwicklung von Thomas Michael Fehlmann Profikurs Eclipse 3 von Gottfried Wolmeringer und Thorsten Klein User Interface-orientierte Softwarearchitektur von Paul Chlebek Erfolgreiche Datenbankanwendung mit SQL3 von Jörg Fritze und Jürgen Marsch Web-basierte Systemintegration von Harry Marsh Sneed und Stephan Henry Sneed

www.vieweg.de

Terminalserver mit Citrix Metaframe XP von Thomas Joos Exchange Server 2000 von Thomas Joos Profikurs PHP-Nuke von Jens Ferner Unternehmensweites Datenmanagement von Rolf Dippold, Andreas Meier, Walter Schnider und Klaus Schwinn Netzarchitektur – Kompass für die Realisierung von Thomas Spitz, Markus Blümle und Holger Wiedel SIP – Die Technik von Andreas Kanbach IT-Sicherheit – Make or Buy von Marco Kleiner, Lucas Müller und Mario Köhler Mehr IT-Sicherheit durch Pen-Tests von Enno Rey, Michael Thumann und Dominick Baier IT-Risiko-Management mit System von Hans-Peter Königs IT-Sicherheit mit System von Klaus-Rainer Müller Der IT Security Manager von Heinrich Kersten und Gerhard Klett COBIT kompakt und verständlich von Wolfgang Goltsche

Wolfgang Goltsche

COBIT kompakt und verständlich Der Standard zur IT Governance – So gewinnen Sie Kontrolle über Ihre IT – So steuern Sie Ihre IT und erreichen Ihr Ziele Mit 92 Abbildungen

Bibliografische Information Der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar.

Das in diesem Werk enthaltene Programm-Material ist mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Der Autor übernimmt infolgedessen keine Verantwortung und wird keine daraus folgende oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieses Programm-Materials oder Teilen davon entsteht. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne von Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürfen. Höchste inhaltliche und technische Qualität unserer Produkte ist unser Ziel. Bei der Produktion und Auslieferung unserer Bücher wollen wir die Umwelt schonen: Dieses Buch ist auf säurefreiem und chlorfrei gebleichtem Papier gedruckt. Die Einschweißfolie besteht aus Polyäthylen und damit aus organischen Grundstoffen, die weder bei der Herstellung noch bei der Verbrennung Schadstoffe freisetzen.

1. Auflage September 2006 Alle Rechte vorbehalten © Friedr. Vieweg & Sohn Verlag | GWV Fachverlage GmbH, Wiesbaden 2006 Lektorat: Günter Schulz / Andrea Broßler Der Vieweg-Verlag ist ein Unternehmen von Springer Science+Business Media. www.vieweg.de

Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.

Konzeption und Layout des Umschlags: Ulrike Weigel, www.CorporateDesignGroup.de Umschlagbild: Nina Faber de.sign, Wiesbaden Druck- und buchbinderische Verarbeitung: MercedesDruck, Berlin Printed in Germany ISBN-10 3-8348-0141-0 ISBN-13 978-3-8348-0141-8

Vorwort Der Begriff der IT-Governance und der des IT Service Managements ist heute in aller Munde. Dies können Sie leicht feststellen, wenn Sie nur die einschlägigen Fachzeitschriften oder auch das Internet bemühen und nach diesen beiden Begriffen suchen. Dabei werden Sie höchstwahrscheinlich zwei Dinge feststellen: Erstens ist weder der Begriff der IT-Governance noch der Begriff des IT Service Managements einheitlich geklärt, und zweitens beziehen sich viele Autoren auf die beiden Begriffe COBIT und ITIL. COBIT steht für „Control Objectives for Information and related Technology“ ein vom IT-Governance Institute geprägter Ausdruck, und ITIL für „IT Infrastructure Library“, eine Abkürzung, die vom Office of Government Commerce geprägt wurde. Beide Begriffe werden in diesem Buch erläutert und in einen Kontext gestellt. Dieses Buch soll in COBIT einführen und verwendet daher auch die Definitionen von COBIT. Im ersten Schritt wird erläutert, was bei COBIT unter Governance und speziell unter IT-Governance zu verstehen ist und was ihre Funktion darstellt. Es folgt danach eine allgemeine Einführung in COBIT und in die Grundlagen oder Quellen von COBIT. Eine komplette Auflistung der Prozesse mit jeweils einer kurzen Beschreibung runden das Bild ab. In diesem Rahmen wird auch auf die Kontrollziele von COBIT eingegangen. Diese Einführung kann von allen IT-Interessierten, vom CIO bis zum Laien, genutzt werden, um sich ein Bild von COBIT zu machen und zu verstehen, worum es in diesem Modell geht. Da viele der Abkürzungen feststehende oder allgemeine gebräuchliche Begriffe innerhalb der IT sind, wurde auf eine Übersetzung dieser Begriffe ins Deutsche verzichtet und die englische Originalabkürzung beibehalten. Diese werden aber im Glossar übersetzt, und es sollte mithin keine Schwierigkeiten bei der Verwendung der Begriffe geben. Jeder einzelne Prozess wird im Überblick erläutert. Für eine Implementierung von COBIT sind weitergehende Informationen notwendig. Diese Ausarbeitung gibt Ihnen aber einen guten Überblick über die Gesamtheit von COBIT, und Sie haben dadurch die Möglichkeit, die Implementierungen zu bewerten, in

V

Vorwort dem diese den Prozessen und den angeführten Kontrollen gegenübergestellt werden. COBIT ist ein lebender Standard. Es ist daher möglich, dass sich bereits mehr Informationen finden lassen, als ich sie hier aufnehmen konnte. Bitte benutzen Sie für die Suche nach aktuellen Informationen die im Kapitel „COBIT Publikationen und Literaturverzeichnis“ aufgeführten Links und Literaturhinweise. Diese Ausarbeitung beruht auf der Version 4 von COBIT. Auch wenn es sich empfiehlt, die ersten Kapitel zunächst zu lesen, müssen Sie diese Ausarbeitung nicht Kapitel für Kapitel durcharbeiten. Nach dem Lesen der ersten Kapitel können Sie das Werk auch als Nachschlagewerk benutzen. Haben Sie Anregungen oder Fragen, Verbesserungen an dem Text? Bitte schreiben Sie mir. Jede Anregung ist willkommen. Ich wünsche Ihnen viel Spaß und Freude beim Lesen, denn Sie werden einen umfassenden Standard für die IT-Governance kennen lernen, der in den nächsten Jahren immer bedeutender werden wird. Ritterhude, im Juli 2006, Wolfgang Goltsche

VI

Inhaltsverzeichnis

1

Einführung ....................................................................................................1

1.1

IT-Governance – Eine Einführung...............................................................1

1.2

Modelle und Initiativen ................................................................................7

1.2.1

COSO .....................................................................................................8

1.2.2

ITIL.........................................................................................................9

1.2.3

COBIT .................................................................................................. 11

1.2.4

Sonstige Frameworks.......................................................................... 13

1.3

Qualität, Reifegradmodelle und Steuerungsinstrumente.......................... 13

1.3.1

Kontrollzyklus nach Deming.............................................................. 13

1.3.2

Normen................................................................................................ 14

1.3.3

EFQM-Modell ...................................................................................... 15

1.3.4

Modellvergleich................................................................................... 16

1.3.5

CMM / Spice (ISO/IEC 15504) ........................................................... 17

1.3.6

Steuerungsinstrumente BSC & Co...................................................... 21

2

Die Struktur von COBIT............................................................................. 25

2.1

Der Governance-Würfel ............................................................................. 25

2.2

Die Dimension der COBIT-Prozesse ......................................................... 27

2.2.1

Planung und Organisation (PO) ........................................................ 28

2.2.2

Akquisition & Implementierung......................................................... 30

2.2.3

Delivery & Support ............................................................................. 31

2.2.4

Monitoring und Evaluierung .............................................................. 33

2.3

Ressourcen .................................................................................................. 34

2.4

Geschäftsanforderungen ............................................................................ 35

2.5

Gesamtprozessübersicht............................................................................. 42

VII

Inhaltsverzeichnis

3

COBIT-Prozessbeschreibung ..................................................................... 45

3.1

Die verwendete Prozessdarstellung........................................................... 45

3.2

PO Planung und Organisation................................................................... 51

3.2.1

PO1 Definieren eines strategischen Plans......................................... 51

3.2.2

PO2 Definieren der Informationsarchitektur..................................... 54

3.2.3

PO3 Festlegen der technischen Ausrichtung .................................... 57

3.2.4

PO4 Definieren der IT-Organisation und ihrer Beziehungen.......... 60

3.2.5

PO5 IT-Investitionsmanagement........................................................ 64

3.2.6

PO6 Kommunizieren der Management-Ziele und Strategien .......... 67

3.2.7

PO7 Personalführungsmanagement................................................... 70

3.2.8

PO8 Qualitätsmanagement................................................................. 73

3.2.9

PO9 Risikomanagement ..................................................................... 76

3.2.10

PO10 Projektmanagement .................................................................. 79

3.3

3.3.1

AI1 Identifizierung automatisierter Lösungen ................................... 83

3.3.2

AI2 Erwerb und Pflege von Applikationssoftware ........................... 86

3.3.3

AI3 Erwerb und Pflege der technischen Infrastruktur...................... 89

3.3.4

AI4 Befähigen des Betriebes .............................................................. 92

3.3.5

AI5 Zur Verfügung stellen von IT-Ressourcen.................................. 95

3.3.6

AI6 Change Management ................................................................... 98

3.3.7

AI7 Installieren und Abnehmen von Systemen und Änderungen. 101

3.4

VIII

AI Akquisition und Implementierung........................................................ 83

DS Delivery und Support ......................................................................... 104

3.4.1

DS1 Service Level Management ....................................................... 104

3.4.2

DS2 Lieferanten-Management (Third Party Services) ..................... 108

3.4.3

DS3 Performance und Kapazitätsmanagement ............................... 111

3.4.4

DS4 Continuity Management............................................................ 114

3.4.5

DS5 Security Management................................................................ 117

3.4.6

DS6 Kostenmanagement................................................................... 120

3.4.7

DS7 Anwenderschulung und Training ............................................ 123

3.4.8

DS8 Anwenderunterstützung ........................................................... 126

Inhaltsverzeichnis 3.4.9

DS9 Konfigurationsmanagement...................................................... 129

3.4.10

DS10 Problem Management ............................................................. 132

3.4.11

DS11 Data Management ................................................................... 135

3.4.12

DS12 Facility Management ............................................................... 138

3.4.13

DS13 Operationsmanagement.......................................................... 141

3.5

ME Monitoring und Überwachung (Monitoring and Evaluation).......... 144

3.5.1

ME1 Überwachen und evaluieren der IT-Performance.................. 144

3.5.2

ME2 Überwachung und Begutachtung der internen Kontrollen ... 147

3.5.3

ME3 Sicherstellung der Einhaltung gesetzlicher Vorschriften........ 150

3.5.4

ME4 Sorgen für IT-Governance ....................................................... 153

4

IT-Governance-Implementierung ............................................................ 157

4.1

Einführung von COBIT ............................................................................ 157

4.2

Methodisches Vorgehen ........................................................................... 158

4.3

Verfügbare Tools ...................................................................................... 160

5 5.1

COBIT-Publikationen und Literaturverzeichnis ...................................... 163 Struktur der Publikationen ....................................................................... 163

5.1.1

Board Briefings ................................................................................. 164

5.1.2

Framework und Control Objectives................................................. 164

5.1.3

Management Guidelines................................................................... 164

5.1.4

IT Assurance Guide .......................................................................... 166

5.1.5

IT Control Objectives for SOA ......................................................... 167

5.1.6

Implementation Guide...................................................................... 167

5.2

Weitere Publikationen .............................................................................. 168

Glossar ...................................................................................................................... 169 Schlagwortverzeichnis.............................................................................................. 171

IX

1

Einführung In diesem Kapitel werden Sie die wesentlichen Strömungen im Rahmen von IT-Governance und IT Service Management kennen lernen. Nach der Vorstellung verschiedener Definition von ITGovernance und deren Zusammenhang mIT-Unternehmensgovernance und IT Service Management folgen die Erläuterungen zu COBIT, ITIL, EFQM, CMM und zum allgemeinen Verbesserungsmodell von Prozessen nach Deming.

1.1

IT-Governance – Eine Einführung Die Informationstechnologie (IT) dient zur Unterstützung fast aller Geschäftsprozesse in den Unternehmen, und ohne die Nutzung der IT ist die Durchführung vieler Prozesse nicht mehr möglich oder doch wesentlich erschwert. Gleichzeitig stellt die effiziente Nutzung vielfach einen Wettbewerbsvorteil dar, auf den nicht verzichtet werden kann. Die IT ist daher nicht nur Unterstützer der Geschäftsprozesse, sondern macht viele Abläufe erst möglich. Von besonderer Bedeutung ist es daher, dass die IT an der Gesamtstrategie und den Zielen des Unternehmens ausgerichtet wird. Genau dies ist, wie wir noch zeigen werden, eine der wesentlichen Aufgaben der IT-Governance. Governance und auch IT-Governance wird heute als Begriff in vielen Publikationen auch aus anderen Gründen verwendet und erlebt eine große Aufmerksamkeit. Zu einem großen Teil liegt das an den Skandalen, welche vor einigen Jahren die Aktienmärkte erschüttert haben. Durch fehlende Kontrolle und unzureichendes Risikomanagement der verantwortlichen Manager der Unternehmen wurden dabei erhebliche Werte vernichtet. Durch eine entsprechende Gesetzgebung in den Vereinigten Staaten und auch in Europa wurde auf diese Missstände reagiert. Stichworte in diesem Zusammenhang sind der Sarbanes Oxley Act (SOA) aus den USA und der Winter Report (Empfehlungen einer EU-Expertengruppe), die Regeln für die Governance der Unternehmen aufstellen. Da die Informationstechnik in den Unternehmen, als ein das Kerngeschäft unterstützender Bereich, seine Daseinberechtigung nur aus dieser Unterstützung gewinnt, ist es nur logisch, dass die 1

1

Einführung Regeln, die für das Kerngeschäft einer Unternehmung gelten, sinngemäß auch für die IT-Organisation anzuwenden sind. Neben der Auswirkung dieses geänderten Umfeldes kommen für die IT eine Reihe von Themen hinzu, die auch heute noch in vielen IT-Organisationen ungelöst sind. Zum einen ist das die immer noch fehlende Kundenorientierung vieler dezentraler oder auch zentraler IT-Organisationen, obwohl anerkannt werden muss, dass auch in diesem Bereich inzwischen Verbesserungen erkennbar sind. Die Herausforderungen im Projektmanagement und auch im Risikomanagement sind weiterhin groß. Nicht umsonst berichtet die Gartner Group, das weltweit führende Unternehmen für Analyse und Forschung im Bereich der IT, regelmäßig über die Schwierigkeiten mIT-Projekten in der IT. Bei einer Fehlerquote von 70% der IT-Projekte in Bezug auf entweder Kosten, Zeit oder Qualität kann von einem wirklichen Erfolg bei der Umsetzung dieser Projekte nicht gesprochen werden. Gleichzeitig nehmen die Risiken, die in der IT liegen, immer mehr zu. Dies liegt zum einen daran, dass die IT immer mehr als eigentlicher Motor der Kerngeschäftsprozesse eingesetzt wird, und zum anderen daran, dass die Technologie in Sprüngen vorwärts eilt und dadurch zersplitterte, kaum handhabbare IT HW / SW Landschaften entstehen. All diesen Herausforderungen muss mit einer geeigneten Strategie begegnet werden. Diese kann nur im Aufbau einer Governancestruktur für die IT liegen, denn nur dadurch werden die Leitlinien festgelegt, welche die IT am Kerngeschäft eines Unternehmens ausrichtet, die Risiken reduziert und die Chancen nützt. Standardisierung der Prozesse und der Aufbau einer Prozessorientierten Organisation, die in der Lage ist, diese Probleme zu lösen, müssen dem Modell zu Grunde liegen. Für diese Standardisierungsbemühungen taucht in letzter Zeit auch der Begriff Industrialisierung der IT auf, der allerdings ein wenig mehr aussagt, nämlich das Bemühen, die Prozesse auch so zu gestalten, dass sie industriellen Maßstäben genügt. In vielen ITOrganisationen ist es jedoch so, dass die Prozesse durch stark individuelle Züge der handelnden Personen geprägt sind, standardisiert zwar, aber keiner industriellen Güte genügend. Eine dieser Bemühungen, Ordnung in die Prozesse der IT Landschaft zu bringen und ein übergeordnetes Governancemodell zu etablieren, ist COBIT. COBIT als Begriff steht dabei für Control Objectives of Information and related Technology, es geht also um Kontrolle, genauer um Kontrollziele der Informationen und der

2

1.1

IT-Governance – Eine Einführung

damit verbundenen Technologie und dem Aufbau eines internen Kontrollsystems (IKS). COBIT als Standard für IT-Governance steht allerdings nicht alleine in der Welt und ist auch nicht einfach so entstanden, sondern hat seine Wurzeln in vielfältigen Vorläufern. Um einen Gesamtrahmen zu schaffen ist es daher wichtig die Beziehung zu den anderen Governance Frameworks darzustellen und zu erläutern. Dem umfangreichsten Framework, welchem man in der Literatur begegnet, ist ein Diskussionspapier von der CIMA (Chartered Institute of Management Accountants). In diesem Diskussionspapier werden die Begriffe „Enterprise Governance“, „Corporate Governance“ und „Business Governance“ benutzt. „Enterprise Governance“ ist dabei der Oberbegriff für das Framework, welches die beiden Aspekte der Corporate Governance und der Business Governance, zwischen denen in dem Framework unterschieden wird, abdeckt. Die Grafik zeigt den Zusammenhang zwischen den verschiedenen Begriffen.

Enterprise Governance

Corporate Governance Conformance

Business Governance Performance

Verantwortlichkeit Gewissheit

Erzeugung von Werten Ressourcen Nutzung

Abb. 1-1 CIMA Framework

CIMA benutzt die folgende Definitionen für Enterprise Governance: Definition Enterprise Governance Enterprise Governance ist die Summe der Verantwortlichkeiten und Praktiken, ausgeführt vom Oberen Management, sowie dem ausführenden Management mit dem Ziel, die strategische Richtung vorzugeben. Dabei muss sichergestellt werden, dass die gesetzten Ziele erreicht werden, indem Risiken behandelt werden und nachgeprüft wird, dass die Ressourcen des Unternehmens verantwortlich genutzt werden.

3

1

Einführung Gemäß CIMA gibt es zwei Dimensionen des Enterprise Governance: Anpassung (Conformance) und Durchführung (Performance). Die Anpassungsdimension beinhaltet die retrospektiven Sicht (rückwärts betrachtet), während die Leistungsdimension die prospektive Sicht (Zukunftsbetrachtung) repräsentiert. Die Verbindungen in Abb. 1-1 CIMA Framework zeigen, dass der Bereich Anpassung direkt mit Verantwortlichkeit und Gewissheit zu tun hat und die Performance direkt zur Werteschaffung und Ressourcennutzung führt. Es gilt andererseits auch, dass die beiden Dimensionen der Governance sich gegenseitig beeinflussen, so dass also zum Beispiel Corporate Governance die Werteschaffung und Ressourcennutzung beeinflusst. Wenn im täglichen Sprachgebrauch über Governance gesprochen wird, so ist meistens der Aspekt der Corporate Governance gemeint. Auf diesen Aspekt zielen die vor einiger Zeit in der Presse berichteten und bereits erwähnten Skandale. Unmittelbar nach diesen Skandalen, die auch das Ende eines der großen fünf Buchprüfungsunternehmens einleiteten, wurden in vielen Ländern, u.a. in den USA und in Europa, neue Regelungen entworfen und eingeführt, um die Unternehmensführung zu verstärken. In den USA, wurde aus diesem Grund der „Sarbanes-Oxley Act“ umgesetzt. In Europa gab der Winterreport Empfehlungen für einen modern geregelten Rahmen des Gesellschaftsrechts heraus, welcher der Europäischen Kommission zur Verfügung gestellt wurde. Als Beispiel mag eine der Empfehlungen dienen. Diese besagt, dass Firmen, deren Anteile auf dem freien Markt, also an den Börsen gehandelt werden, eine umfassende Beschreibung der Kernelemente ihrer Governance-Strukturen und Richtlinien auf ihren Internetseiten und in ihren jährlichen Berichten veröffentlichen sollen. Es gibt neben der Definition der Governance nach CIMA auch noch die Definition der Organisation der ökonomischen Zusammenarbeit und Entwicklung (OECD). Sie definiert Corporate Governance folgendermaßen: Definition Corporate Governance (OECD) Corporate Governance ist das System, durch das Kapitalgesellschaften geführt und gesteuert werden. Die Struktur der Corporate Governance spezifiziert die Verteilung von Rechten und von Verantwortlichkeiten unter unterschiedlichen Teilnehmern in dem Unternehmen, wie dem Direktorium, den Managern, den

4

1.1

IT-Governance – Eine Einführung

Aktieninhabern und anderen Beteiligten und diktiert die Richtlinien sowie die Verfahren für das Treffen von Entscheidungen in Firmenangelegenheiten. Indem es dies tut, liefert es auch die Struktur, durch die die Firmenziele festgelegt werden, die Mittel zur Erreichung jener Ziele sowie generell die Überwachung von Leistung. Inzwischen ist es weltweit anerkannt, dass Corporate Governance notwendig ist. Alle an einem Unternehmen interessierte Gruppen haben ein Anrecht auf verlässliche Informationen und auf eine gute Behandlung, respektive Abwehr, von Einflüssen, denen das Unternehmen ausgesetzt ist. Ein Großteil der Skandale war auf das Wirken von nicht ausreichend kontrollierten CEOs zurückzuführen, so dass es in diesem Zusammenhang auch darum geht, eine Balance zwischen dem Aufsichtsrat bzw Aufsichtsgremien und dem CEO herzustellen, so dass solche Auswüchse, wie sie vorgekommen sind, unwahrscheinlicher werden. Am Ende bedeutet es die Macht eines CEOs einzuschränken. Auf der anderen Seite haben wir die Business Governance, welche sich auf die realen Aufgaben der Rolle des Aufsichtsrates/Aufsichtsgremiums konzentriert. Diese bestehen auf der einen Seite im Treffen strategischer Entscheidungen, die konkrete Behandlung von Risiken und deren Beurteilung und Diskussion und auf der anderen Seite in den Erkenntnissen über die wesentlichen Treiber für das Geschäftsergebnis. Die Informationstechnologie ist in den meisten Firmen eine das Kerngeschäft des Unternehmens unterstützende Abteilung. In einigen Fällen bildet die IT selbst das Kerngeschäft. Dies trifft zum Beispiel für Outsourcer zu, die Anlagen für andere Firmen betreiben. Die internen IT-Abteilungen sollten keine wirkliche Sonderstellung genießen, sondern als eine, wenn auch wichtige Abteilung behandelt werden. Aus diesem Grund ist klar, dass auch die für die Unterstützung der Geschäftsprozesse eingesetzten Prozesse in geeigneter Weise gesteuert werden müssen. Wie sieht es damit aber in den IT-Abteilungen aus? Da diese Frage vielfach nicht hinreichend beantwortet werden kann wird IT-Governance als offene Frage immer drängender. Und da die IT einen wesentlichen Teil der Kerngeschäftsprozesse abbildet bzw. diese vielfach ohne die Unterstützung der IT nicht mehr durchgeführt werden können, gilt: Die IT-Governance ist wesentlicher Bestandteil der Corporate Governance.

5

1

Einführung Die Definition der IT-Governance orientiert sich daher an der Corporate Governance Definition. Im Rahmen von COBIT wird die IT-Governance folgendermaßen definiert. Definition IT-Governance IT-Governance ist eine Struktur von Beziehungen und Prozessen zur Steuerung und Führung eines IT-Unternehmens oder ITBereiches, um die Geschäftsziele zu erreichen. Der Wertzuwachs wird dabei durch das Ausbalancieren von Risiko und Ertrag der IT und ihrer Prozesse erreicht. Sie ist eine Aufgabe der Führungskräfte und der Aufsichtsgremien. Dies bedeutet in anderen Worten, IT-Governance legt die Verteilung von Rechten und Pflichten unter den unterschiedlichen Teilnehmern (Aufsichtsräten/Geschäfts- und IT-Managern, etc) fest und bestimmt, wie Entscheidungen getroffen werden, um eine möglichst hohe Transparenz zu schaffen. Damit stellt IT-Governance sicher, dass die IT in richtiger Art und Weise an den Geschäftsprozessen ausgerichtet und entsprechend organisiert ist sowie im Sinne des Geschäftes gesteuert wird. ITGovernance liefert die Struktur, IT-Prozesse, IT-Ressourcen und Informationen, die mit den Unternehmensstrategien und deren Zielsetzungen verknüpft sind. IT-Governance integriert und institutionalisiert Best Practice-Modelle. Sie organisiert, erwirbt, führt ein, liefert, stützt und überwacht IT-Leistungen, um sicherzugehen, dass die Informationen und die damit in Verbindung stehende Technologie des Unternehmens die Unternehmensziele unterstützt. IT-Governance ermöglicht es dem Unternehmen, den vollen Nutzen aus seinen Informationen zu ziehen. Dadurch maximiert es den Nutzen und kapitalisiert die Chancen, die dadurch zu einem Wettbewerbsvorteil führen. In der folgende Tabelle sind die drei vorgestellten Begriffe noch einmal zusammengefasst.

6

1.2

Modelle und Initiativen

Tabelle 1-1 Governancebereiche Corporate Governance

Business Governance

IT-Governance

Trennung von Eigentümerschaft und Kontrolle

Führung und Kontrolle des Geschäftes

Führung und Kontrolle der IT

Verantwortung der Leitung

Geschäftsziele

IT-Ziele

Gesetzliche und kaufmännische Compliance & Kontrolle

Geschäftsstrategie und Planung

Ausrichtung der IT an den Geschäftszielen

Shareholder Rechte

Geschäftsaktivitäten und Prozesse

IT-Ressourcen

Ethik & Integrität Geschäftsdurchführung, Risiken & Kontrolle Kostenrechnung und Berichterstattung Asset Management Risiko Management

Innovation und Forschungsfähigkeit Kapital an Wissen und Intellekt Information und ITS Management Personal Management Kundenservice und Beziehungsmanagement

Informations- und Wissensmanagement IT-Strategie und Planung IT-Einkauf und Einführung IT-Betrieb, Risiko und Kontrolle IT-Asset Management IT-Risiko Manage-ment IT-Projekte

Interne und externe Kommunikation Leistungskontrolle

1.2

Modelle und Initiativen Im Bereich der IT-Governance oder auch ergänzend für das IT Service Management gibt es eine ganze Reihe von bereits vorhandenen Modellen und Initiativen, von denen an dieser Stelle die wichtigsten vorgestellt werden sollen. Die in diesem Rahmen betrachteten Modelle sind in zwei Kategorien eingeteilt, in öffentliche und kommerzielle. COSO, ITIL und COBIT gehören zur Gruppe der auch Public Domain genannten frei zugänglichen Frameworks, und als kommerzielle Angebote stehen unter anderem MOF (Microsoft Operational Framework) und SOF (Siemens Operational Framework) zur Verfügung Auf jedes der öffentlichen Modelle werden wir kurz eingehen und die wichtigsten Elemente vorstellen.

7

1

1.2.1

Einführung

COSO Im Jahr 1992 gab das „Committee of Sponsoring Organizations of the Treadway Commission“ das „Internal Control – Integrated Framework“ heraus. In dieser Publikation wurde ein Rahmen zur internen Steuerung vorgestellt. Darüber hinaus enthielt es Auswertetools, die Firmen und andere Organisationen benutzen können, um ihre Steuerungssysteme zu analysieren. Das Framework benennt und beschreibt fünf zusammenhängende Bestandteile, die für eine wirkungsvolle interne Steuerung notwendig sind. In „Internal Control – Integrated Framework“, definierte COSO die interne Prozesssteuerung, die durch die Aufsichtsgremien einer Organisation, dem Management und anderem Personal ausgeführt wird. Diese Steuerung wurde entwickelt, um eine angemessene Sicherheit über die Erreichung von Zielsetzungen in Bezug auf die folgenden Kategorien zur Verfügung zu stellen: ¾

Wirksamkeit und Leistungsfähigkeit des Betriebes (Aktivitäten)

¾

Zuverlässigkeit des finanziellen Berichtes

¾

Befolgung der anwendbaren Gesetze und Regelungen

In 2004 ist das „Enterprise Risk Management“ (ERM) von COSO erschienen. In diesem Framework werden die hauptsächlichen ERM-Komponenten definiert, die Schlüsselprinzipien und Konzepte diskutiert, eine einheitliche Sprache vorgeschlagen und eine klare Richtung für das Enterprise Risk Management vorgegeben. ERM ist daher weiter gefasst als die interne Steuerung. Es erweitert und durchdringt die interne Steuerung, um eine stabilere Basis zu schaffen, die auf das Erkennen und Behandeln von Risiken ausgerichtet ist. Der „Enterprise Risk Management“-Rahmen erweitert den internen Steuerrahmen wie folgt: ¾

8

Vier Kategorien der Zielsetzungen werden spezifiziert: Operationen, Berichte, Einhaltung von Regeln und strategische Zielsetzungen. Die Berichte umfassen jene Reports, die innerhalb des Managements verwendet und solche, die zu externen Parteien herausgegeben werden.

1.2

Modelle und Initiativen

Strategische Zielsetzungen sind als neue Kategorie hinzugefügt worden.

1.2.2

¾

ERM betrachtet Risiken aus einer „Portfolio“-Perspektive.

¾

Der Rahmen bezieht die Menge der Risiken mit ein, die eine Firma bereit ist hinzunehmen, um ihre Ziele zu erreichen.

¾

Ereignisse, die die Firma beeinflussen können, werden identifiziert. Diejenigen mit potentiell negativer Auswirkung stellen Risiken dar.

¾

Die Risikobeurteilung wird erweitert.

¾

ERM benennt vier Reaktionsmöglichkeiten auf Gefahren - vermeiden, verringern, teilen und akzeptieren. Antworten werden für einzelne Risikoarten und für gesamte Risikogruppen betrachtet.

¾

ERM erweitert den Informations- und den Kommunikationsbestandteil und betrachtet Daten aus der Vergangenheit, der Gegenwart in Bezug auf die möglichen zukünftigen Ereignisse.

¾

ERM beschreibt die Rolle und die Verantwortlichkeiten der Risiko-Manager und erweitert dies auf die Rolle des Aufsichtsgremiums der Gesellschaft / Firma.

ITIL ITIL ist die Abkürzung für die „IT Infrastructure Library“. Es sind Richtlinien und Empfehlungen, die ursprünglich durch das CCTA (heute OGC) in Norwich, England, für die britische Regierung entwickelt wurden. ITIL ist ein praxisnaher Rahmen für IT Service Management und wird als der globale de facto-Standard in diesem Bereich angesehen. Zum Beispiel stellt ITIL die Grundlage für das „Microsoft Operations Framework“ und für das „HP IT Service Management Reference Model“ zur Verfügung. Das von Siemens Business Services erstellte Modell „Siemens Operational Framework“ beruht ebenfalls auf ITIL, integriert wesentliche Teile der Modelle und fügt neue Aspekte hinzu. ITIL besteht aus einer Reihe Büchern, die Best PracticeEmpfehlungen für IT Service-Management geben. ITIL erklärt dabei was, getan werden soll, aber niemals wie. Die Empfehlung, einen Servicedesk einzurichten, der die Schnittstelle zum Anwender abbilden soll, bildet in diesem Fall die einzige Aus9

1

Einführung nahme. Ausgehend von der Kundensicht auf die IT-Services wird eine auf das Kerngeschäft ausgerichtete Servicekultur propagiert. Ein wichtiges Element ist die Bestimmung der Qualität der ITDienstleistungen. ITIL versteht die IT ausschließlich als Unterstützer der Kerngeschäftsprozesse mit keinerlei Selbstzweck. Die Service Prozesse sind damit auf die Größe einer Unternehmung, der internen Kultur und den Geschäftsanforderungen auszurichten. Die bekanntesten ITIL Bücher sind „Service Support“, in dem der Service-Desk und die fünf Prozesse „Incident Management“, „Problem Management“, „Configuration Management“, „Change Management“ und „Release Management“ beschrieben sind. Ein weiteres ist das „Service Delivery“, in dem Prozesse für „Capacity Management“, „Financial Management“ für IT-Services, „Availability Management“, „Service-Level-Management“ und „IT-Service Continuity“ Management beschrieben werden. Die folgende Abbildung gibt einen Überblick über die Prozesse, die in den beiden Büchern behandelt werden.

Service Support ƒ ƒ ƒ ƒ ƒ ƒ

Service Desk (Funktion) Incident Management Problem Management Configuration Management Change Management Release Management

Service Delivery ƒ ƒ ƒ ƒ ƒ

Service Level Management Financial Management Capacity Management Continuity Management Availability Management Security Management

Abb. 1-2 Überblick über die ITIL-Prozesse

Obwohl Security als ein Element des Availability Management angesehen wird, ist auf Grund der aktuellen Situation und wegen der zunehmenden Bedeutung das Security Management als ein eigenständiges Thema weiterentwickelt worden. ITIL beschränkt sich allerdings nicht nur auf die beiden Themengebiete IT Support und IT Delivery, sondern umfasst noch andere Bereiche. Diese anderen wichtigen ITIL Bücher sind in der folgenden Abbildung dargestellt.

10

1.2

T h e

Planning to Implement Service Management

T h e B u s i n e s s

Modelle und Initiativen

Service Management

Service Support

The Business Perspective Service Delivery

Security Management Applications Management

Abb. 1-3

ICT Infrastructure Management

T e c h n o l o g y

Übersicht über die ITIL Bücher

Das Buch „Planning to Implement Service Management“ beschreibt die Schritte, die notwendig sind, damit eine Organisation erkennt, wie sie von ITIL profitieren kann und wie man diesen Nutzen erzielt. Es wird zur Einführung eine Projektmanagementmethodik (PRINCE2) empfohlen und gezeigt, wie ITIL in Firmen, unterschiedlichster Größe, implementiert werden kann. Das „ICT Infrastructure Management“-Buch betrifft die Prozesse, Organisationen und erforderlichen Werkzeuge, um eine beständige IT und Kommunikationsinfrastruktur zur Verfügung zu stellen. Das „Application Management“-Buch ist für Entwickler und Service Manager gedacht und beschreibt, wie Anwendungen von einer Service Managementperspektive aus gehandhabt werden können und sollen. „Security Management“ ist in einem separaten Buch beschrieben und hat Verbindungen mit mehreren der anderen Gebiete. Es beschreibt den Prozess Sicherheitsmanagement in Bezug auf die verschiedenen Aspekte der IT-Sicherheit.

1.2.3

COBIT COBIT ist das Akronym für Control Objectives for Information and related Technology, also für Kontrollziele für die Information und die damit verbundene Technologie. COBIT ist ein Model zur Kontrolle der gesamten IT. Der Name verrät bereits etwas 11

1

Einführung über den Hintergrund, denn es ist eine Methode zur Auditierung. So wurde es ursprünglich auch von der ISACF (Information Systems Audit and Control Foundation), dem Forschungsinstitut der ISACA (Information Systems Audit and Control Association) entwickelt. Die Aufgabe der Weiterentwicklung wurde 1999 an das IT-Governance Institut übertragen, eine von der ISACA unabhängige Einrichtung. Die Entwicklung von COBIT begann im Jahr 1994. Eine erste Version erschien 1996 und weitere Versionen 1998 und 2000. Die aktuellste Version ist derzeit V4.0 (Jan 06). Ursprünglich adressierte COBIT nur Auditoren, Endanwender und das Management. COBIT ist die Grundlage für das Berufsbild der CISA (Certified Information System Auditor), derzeit ca 14.000 weltweit. In COBIT sind eine Vielzahl von Standards aus unterschiedlichen Quellen eingeflossen, so dass die besten Teile aus allen Quellen zusammengefasst werden konnten und ein umfassendes Bild ergeben. COBIT unterstützt die IT-Governance indem eine umfassende Beschreibung der Kontrollziele für IT-Prozesse geliefert wird. Diese Kontrollziele, auf englisch Control Objectives genannt, sind Aussagen zum gewünschten Ergebnis/Zweck eines Prozesses, das mit der Implementierung von Kontrollverfahren in einer bestimmten Aktivität erreicht werden soll. Vom Prinzip her benutzt COBIT damit das Kontrollmodell von Deming (siehe 1.3.1 Kontrollzyklus nach Deming) setzt aber auf Normen, Standards und Zielen als Inputgeber für Verbesserungen.

Handeln

Normen Standards Ziele

Messen und Vergleichen

Prozess Kontroll Information

Abb. 1-4

12

COBIT Kontrollmodell

1.3

Qualität, Reifegradmodelle und Steuerungsinstrumente

Im Rahmen von COBIT ist es außerdem möglich, den Reifegrad der vorhandenen Prozesse zu ermitteln. COBIT liefert dazu für jeden Prozess eine Beschreibung von Kriterien, an Hand derer die Einstufung vorgenommen werden kann. Risiken und Chancen, die bei der Benutzung von Informationen und IT-Technologie auftreten, können bei der Anwendung von COBIT besser verstanden, eingeschätzt und behandelt werden. COBIT liefert den Managern ein Governance-Werkzeug, das ihnen hilft, die Lücke zwischen den Kontrollerfordernissen, den Informationssystemen (IS) und den Informationstechnologie (IT), Themen sowie den Geschäftsrisiken zu schließen. Damit ermöglicht es auch, klare Policies zu entwickeln sowie eine adäquate Kontrolle der gesamten IT in der Organisation einzurichten.

1.2.4

Sonstige Frameworks Viele Firmen haben auf der Basis der frei verfügbaren Frameworks, wie COBIT, ITIL, eigene Frameworks etabliert, welche die vorhandenen Modelle ergänzen. Diese Ergänzungen betreffen in der Mehrzahl die operative Ebene, da diese in den Public Domain Frameworks meist zu kurz kommt. Die Firmen setzen diese Frameworks für ihre eigene IT ein und als ein Mittel zur Beratung für ihre Kunden, um ein bereits mit detaillierteren Inhalten versehenes Referenzmodell zur Verfügung zu haben, an Hand dessen die Implementierung in eine Firma leichter gelingen kann. Die Frameworks können ja nicht ohne Anpassungen implementiert werden. Dazu sind die Firmen zu unterschiedlich.

1.3

Qualität, Reifegradmodelle und Steuerungsinstrumente

1.3.1

Kontrollzyklus nach Deming Qualität wird in einer Reihe von unterschiedlichen Modellen abgebildet. Alle diese Modelle zielen darauf ab, Produkte und Prozesse zu kontrollieren und zu verbessern. Ursprünglich wurden alle diese Modelle für die Kerngeschäftsbereiche der Unternehmen entwickelt. Zunehmend finden sie auch Anwendung im Rahmen der IT. Das Modell von Deming ist sehr weit verbreitet und gut bekannt. Es fokussiert auf die Prozessoptimierung im industriellen Fertigungsbereich, um dadurch die Qualität der erzeugten Produkte 13

1

Einführung zu steigern. Deming kreierte einen kontinuierlichen Verbesserungsprozess, den PDA-Zyklus (Plan, Do Check, Act). Dieser wird häufig als Kreislauf dargestellt, weil er zyklisch immer wieder durchlaufen wird, es gibt allerdings auch andere Darstellungen. Die englischen Begriffe wurden in diesem Kontext beibehalten, da sie Eingang in den allgemeinen Sprachgebrauch des Deutschen gefunden haben. Plan Ziele festlegen und Aktivitäten

Act

Steuerungsobjekt

Änderungen entscheiden

(z.B.: Organisation, Prozess, System, Projekt)

Do Aktivitäten umsetzen, Messen

Check Prüfung Ziele erreicht, Bericht

Abb. 1-5

Kontrollzyklus nach Deming

Die einzelnen Phasen können wie folgt charakterisiert werden: Plan:

Entwickeln oder ändern von Geschäftsprozessen oder Teilen davon, um die Ergebnisse zu verbessern, Aufstellen eines Plans

Do:

Durchführen des Plans und Messung der Wirksamkeit

Check:

Bewerten der Messergebnisse und Berichten der Bewertungen an die Entscheider

Act:

Entscheiden über Änderungen, die notwendig sind, um den Prozess zu verbessern

Deming hat in den 50er Jahren gearbeitet. Seitdem wurden die Qualitätsmodelle erheblich weiterentwickelt.

1.3.2

Normen Das Baldrigde National Quality Program (BNQP) wurde 1987, mit dem Ziel, Produkt- und Prozess-Qualität in amerikanischen Organisationen zu verbessern, gestartet. ISO (International Orga-

14

1.3

Qualität, Reifegradmodelle und Steuerungsinstrumente

nisation for Standardisation) veröffentlichte ebenfalls 1987 einen Qualitätsstandard (ISO 9000), der auf der Spezifikation BS 5750 aufsetzte. ISO 9000 wurde in der Folge zu einer ganzen Familie von ISO Standards für Qualität weiterentwickelt. ISO 17799 ist eine allgemeine Vorschrift für das InformationsManagement. Diese allgemeine Vorschrift nimmt Grundsätze der Informationssicherheit als Grundlage. Sie liefert 127 Informationssicherheitsrichtlinien, die unter 10 Hauptüberschriften strukturiert sind, um den Lesern zu ermöglichen, die Sicherheitskontrollen zu identifizieren, die zu ihrem bestimmten Geschäft oder spezifischem Verantwortlichkeitsbereich passen. Der Standard stellt eine Anleitung für die folgenden Themen zur Verfügung: ¾

Sicherheitspolitik

¾

Sicherheitsorganisation

¾

Wertklassifikation und Steuerung

¾

Personal-Sicherheit

¾

Körperliche und Umweltsicherheit

¾

Kommunikations- und Operationsmanagement

¾

Zugriffssteuerung

¾

Systementwicklung und Wartung

¾

Geschäftskontinuitätsmanagement

¾

Befolgung

BS7799-2 ist ein Begleitstandard zu ISO /IEC 17799. Dieser Managementstandard basiert auf der Risikobeurteilung und dem Plan-Do-Check-Act-Modell nach Deming, zwei wichtigen Bestandteilen der Unternehmensführung. Er stellt eine Grundlage dar, auf der die Managementkontrollen aufgebaut werden können. Diese Managementkontrollen sind notwendig, um den generellen Auftrag einer Organisation zu erfüllen, Risiken zu behandeln und um eine wirkungsvollere Steuerung zu sichern und Verbesserungen zu identifizieren.

1.3.3

EFQM-Modell Das EFQM Excellence Model wurde Anfang 1992 veröffentlicht. Es stellt das Framework für die Bewertung von Anwendungen für den European Quality Award dar. Es ist das am meisten benutzte und verbreitete Framework in Europa und wurde die Ba15

1

Einführung sis für eine Vielzahl von nationalen und regionalen Quality Awards. Das EFQM-Modell, als das bevorzugte Modell in Europa, soll ein praktisches Werkzeug sein. Es hilft beim Aufbau und der kontinuierlichen Weiterentwicklung eines umfassenden Managementsystems und zeigt auf, auf welcher Stufe der Excellence sich die Organisation befindet. Es hilft, eigene Stärken, Schwächen und Verbesserungspotenziale zu erkennen und die Unternehmensstrategie darauf auszurichten. Damit stellt es ein Total Quality Management-Modell dar, das alle Managementbereiche abdeckt und zum Ziel hat, den Anwender zu exzellentem Management und exzellenten Geschäftsergebnissen zu führen. Die Abbildung zeigt den Gesamtrahmen des Modells und die wesentlichen Einflussgrößen auf die Qualität. Treiber

Ergebnisse

Prozesse

Führung

Policies & Strategie

Kunden-bezogene Ergebnisse

Hauptergebnisse

Personen-bezogene Ergebnisse

Personen

Gesellschaftsbezogene Ergebnisse

Partner & Ressourcen

Innovation & Lernen

Abb. 1-6 EFQM-Modell Überblick

1.3.4

Modellvergleich Jedes Modell hat seine eigene Charakteristik. Die Modelle zeigen aber auch eine große Anzahl an Gemeinsamkeiten. Die folgende Tabelle zeigt diese Unterschiede und Gemeinsamkeiten in den Prinzipien und fundamentalen Konzepten auf.

16

1.3

Qualität, Reifegradmodelle und Steuerungsinstrumente

Tabelle 1-2 Modellvergleich Malcom BaldrigeModell

EFQM ExcellenzKonzept

ISO 9000 Prinzipien

Anwenderfokussiert

Kundenfokussiert

Kundenfokussiert

Ergebnisorientiert

Ergebnisorientiert

Managementverpflichtung

Führung und Konstanz des Zwecks

Führung wird eingefordert

Wertschätzung der Mitarbeiter

Mitarbeiterentwicklung und –einbindung

Einbindung der Mitarbeiter

Soziale Verantwortlichkeit

Organisationsimmanente soziale Verantwortlichkeit

Management beruhend auf Aktionen und Prozessen

Management durch Prozesse und Fakten

Nutzung eines Prozessansatzes

Kontinuierliches Lernen, Innovation und Verbesserung

Verstärkung der kontinuierlichen Verbesserung

Entwicklung einer Partnerschaft

Zusammenarbeit mit den Zulieferern

Langzeitvision der Zukunft

Proaktives Handeln und schnelle Reaktion Kontinuierliches Lernen

Benutze einen Systemansatz Besorge die Fakten, bevor entschieden wird

1.3.5

CMM / Spice (ISO/IEC 15504) Das erste „Capability Maturity Model“ wurde vom Softwareentwicklungsinstitut (SEI) der Carnegie Mellon University entwickelt und beschreibt Grundregeln und Praktiken für die SoftwareEntwicklung in Form eines Reifegradmodells. Es sollte Organisationen, die Software entwickeln, helfen, ihre SoftwareEntwicklungsprozesse zu verbessern. Das Modell sieht dabei Reifegradstufen vor, die von adhoc bis hin zu disziplinierten Softwareentwicklungsprozessen reichen. Solche Organisationen können damit einen quasi evolutionären Pfad beschreiten und ihre Prozesse stufenweise verbessern, anstatt den Versuch zu un17

1

Einführung ternehmen in einem revolutionären Ansatz die höchste Stufe der Prozessreife auf einmal zu erklimmen. Dieses CMM benennt fünf Reifegrade: 1. Initial – Die Software-Prozesse werden als ad hoc bezeichnet und gelegentlich sogar als chaotisch. Wenige Prozesse sind definiert, und der Erfolg hängt von den individuellen Bemühungen beziehungsweise von herausragenden Leistungen Einzelner ab. 2. Wiederholbar – Grundlegende Projektmanagementprozesse sind vorhanden, um Kosten, Zeitpläne, Funktionalität zu verfolgen. Die notwendige Prozessdisziplin ist vorhanden, um frühere Erfolge aus Projekten mit ähnlichen Anwendungen zu wiederholen. 3. Definiert – Der Software-Prozess für Management- und Entwicklungstätigkeiten wird in einem Standard-Software-Prozess für die Organisation dokumentiert, standardisiert und integriert. Alle Projekte verwenden eine anerkannte, angepasste Version des Standard-Software-Prozesses für das Entwickeln und das Warten von Software. 4. Managed – Detaillierte Kriterien des Software-Prozesses und der Produktqualität werden gemessen. Der Software-Prozess und die Softwareprodukte werden quantitativ verstanden und unter zu Hilfenahme der Messergebnisse gesteuert. 5. Optimierung – Der Prozess wird durch häufige Feedbacks im Rahmen des Prozesses und durch die Pilotierung innovativer Ideen und Technologien ständig verbessert. Folgt eine Organisation diesem evolutionären Pfad, so werden die Voraussagbarkeit, die Effektivität und die Steuerung der Software-Entwicklungsprozesse verbessert. Die Idee der Prozessreifegradbeschreibung hat sich enorm erweitert, seitdem das erste Reifegradmodell für die Softwareentwicklung vorgestellt wurde. Heutzutage werden Reifegradmodelle für eine Vielzahl von Bereichen verwendet, u.a für Software-Erwerb, Systemtechnik, integrierte Produkt-Entwicklung und in der IT. Inzwischen gibt es auch ein Reifegradmodell für ITIL, das in Zusammenarbeit des TÜV Süddeutschland mit der Siemens Business Services GmbH & Co OHG entwickelt wurde. Eine Reihe von Reifegradmodellen sind von SEI in das Reife® SEI gradmodell Integration (CMMI ) integriert worden. CMMI ist mit ISO/IEC 15504 konform und kompatibel. Dieser Standard resul-

18

1.3

Qualität, Reifegradmodelle und Steuerungsinstrumente

tiert aus der Arbeit der „Software Process Improvement and Capability Determination“-Initiative (SPICE), die einen ersten Entwurf 1995 lieferte. In COBIT wird das Reifegradmodell als Mittel zur Feststellung der Reife der Prozesse verwendet, die in den unterschiedlichen COBIT-Domänen beschrieben werden, Es dient darüber hinaus dazu Organisationen zu helfen ihre Reifegradziele für diese Prozesse festzulegen. Das COBIT-Reifegradmodell kennt auf der generischen Ebene die folgenden Niveaus: 0. Nicht Existent – Es gibt überhaupt keine erkennbaren Prozesse. Die Organisation hat nicht einmal erkannt, dass hier ein Thema oder offenes Problem existiert 1. Initial / adhoc – Offenbar hat die Organisation erkannt, dass das Thema existiert und angegangen werden muss. Es gibt aber auf dieser Stufe keinen standardisierten Prozess, statt dessen sind adhoc-Ansätze auf individueller Basis oder aber von Fall zu Fall unterschiedliche Abläufe die Regel. Das Management der IT und der zugehörigen Prozesse ist chaotisch. 2. Wiederholbar aber intuitiv – Prozesse wurden bis zu einem Stadium entwickelt, in dem unterschiedliche Personen, die die gleiche Aufgabe durchführen, auch nach diesen Prozessen arbeiten. Es gibt keine formalen Schulungsmaßnahmen, und die Kommunikation, das heißt die Verbreitung der Standardprozesse und Verantwortlichkeiten, wird den einzelnen Personen überlassen. Es gibt einen hohen Grad an Vertrauen in das Wissen der Einzelpersonen, und folglich sind Störungen wahrscheinlich, denn diese Personen haben ihr Wissen natürlich für sich erworben und nicht der Allgemeinheit zugänglich gemacht. 3. Definierte Prozesse – die Prozeduren wurden standardisiert, dokumentiert und im Rahmen eines formalen Trainings vermittelt. Auf dieser Stufe bleibt es trotzdem den einzelnen Personen überlassen, sich an die Regeln zu halten, und es ist nicht unwahrscheinlich, dass Abweichungen von den Prozeduren auftreten werden. Die Prozeduren selbst sind dabei keineswegs besonders ausgefeilt, stellen aber eine Dokumentation der gelebten Praxis dar. 4. Geführt und messbar – auf dieser Stufe wird die Einhaltung der Prozesse überwacht und gemessen. Es werden Aktionen angestoßen und durchgeführt, wenn erkannt wird, dass Pro19

1

Einführung zesse nicht effektiv und effizient arbeiten. Die Prozesse werden permanent verbessert, erzeugen dadurch gute interne Verfahren und liefern gute Ergebnisse. Automatisierung und Werkzeuge (Tools) werden in einer begrenzten und ungeordneten Art und Weise benutzt. 5. Optimiert – die Prozesse sind bis zu einem Niveau verbessert worden, das einer externen „best practice“ entspricht. Dies resultiert aus einem andauernden, permanenten Verbesserungsprozess und dem Vergleich der Reife der Organisation mit anderen Organisationen. IT wird als integraler Bestandteil benutzt, um Arbeitsabläufe zu automatisieren. Es werden Tools für die Qualitätsverbesserung und Effektivitätssteigerung eingesetzt, um die Organisation zu befähigen, sich auf die dauernden Änderungen der Umgebung, z.B. in Hinsicht auf Technologie, Wettbewerb etc, anzupassen. Common Criteria (ISO/IEC 15408) Es gab eine Reihe von Bemühungen, allgemeine Kriterien, sogenannte Common Criteria, für die Bewertung der IT-Sicherheit zu entwickeln. Die „Allgemeinen Kriterien“ stellen das Ergebnis dieser Bemühungen dar und werden von einer großen Zahl internationaler Firmen und Verbände genutzt. In den Jahren 1980 bis ca 2000 versuchten viele Länder ihre eigenen Sicherheitsstandards zu entwickeln. Im Juni 1993 wurde von sieben europäischen und nordamerikanischen Regierungsorganisationen das Common Criteria-Projekt gestartet. Das Ziel des Projektes war es, einen allgemeinen Standard für die IT-Sicherheit aus den verschiedenen Ansätzen zu kreieren, der von allen akzeptiert werden konnte. Das Ergebnis dieses Projektes sollte in die internationalen Bemühungen zur Standardisierung auf diesem Gebiet eingehen. 1999 wurde von der ISO das Dokument „Evaluation Criteria for Information Technologie / Security“ (ISO/IEC 15408) veröffentlicht. In diesem Dokument hat ISO den Begriff „Allgemeine Kriterien“ geprägt und seitdem weiter verwendet. Diese Allgemeinen Kriterien sind ein Mittel zur Definition, Bewertung und Messung aller Sicherheitsaspekte der IT. Sie unterstützt auf der einen Seite das Verständnis über die Sicherheitsfunktionalität, „Was macht das IT-Produkt?“, und auf der anderen Seite das Verständnis über die Sicherheitseinhaltung, „Wie sicher ist es, dass die Sicherheitsfunktionalitäten eingehalten werden?“.

20

1.3

Qualität, Reifegradmodelle und Steuerungsinstrumente

Diese Allgemeinen Kriterien sind sehr nützlich für Produktentwickler, weil es ihnen einen Rahmen gibt, in dem sie Produkte entwickeln können und dadurch die Sicherheit haben, dass diese Produkte auch den Sicherheitskriterien genügen und auch die entsprechende Prüfung bestehen können. Auf der anderen Seite können Kunden sicher sein, dass alle nach ISO/IEC 15408 zertifizierten Produkte entsprechend dieser allgemeinen Definition getestet wurden und auch welche dieser Aspekte bei den Tests Berücksichtigung fanden. Die Allgemeinen Kriterien werden zur Zertifizierung von Produkten in der Weise genutzt, dass eine Einstufung in die TOE (Targets of Evaluation) -Tabelle erfolgen kann. Die folgende Tabelle zeigt die Ebenen auf. Tabelle 1-3 TOE-Tabelle EAL1

Funktional getestet

EAL2

Strukturiert getestet

EAL3

Methodisch getestet und überprüft

EAL4

Methodisch entwickelt, getestet und überprüft

EAL5

Informell entwickelt und getestet

EAL6

Informell überprüftes Design und getestet

EAL7

Formell überprüftes Design und getestet

Es ist klar ersichtlich, dass auch diese Einteilung für die Bewertung einer Organisation hilfreich sein kann und nicht auf den Bereich der Produkte beschränkt bleiben muss.

1.3.6

Steuerungsinstrumente BSC & Co Die Balanced Score Card ist ein Management System, das es Organisationen erlaubt, ihre Vision und Strategie zu klären und in Aktionen zu überführen. Auf der einen Seite liefert sie Aussagen über die internen Geschäftsprozesse und auf der anderen Seite die externen Faktoren, die dazu dienen, die strategische Ausrichtung zu optimieren. Kaplan und Norton beschreiben die Bedeutung der Balanced Score Card sinngemäß wie folgt: Die Balanced Score Card enthält die traditionellen finanziellen Kennzahlen. Aber diese Kennzahlen zeigen nur die Vergangenheit, eine Methode, die für Firmen des Industriezeitalters gut war, denn für diese war die Investitionen in langfristige Güter und in Kundenbeziehungen nicht entscheidend für den Erfolg. Die fi21

1

Einführung nanziellen Größen sind aber inadäquat für Unternehmen des Informationszeitalters. Deren Erfolg hängt wesentlich davon ab, wie es ihnen gelingt, zukünftige Werte zu erzeugen, indem Investitionen in Kunden, Zulieferer, Mitarbeiter, Prozesse, Technologie und Innovationen getätigt werden. In ihrem Buch „The Balanced Score Card“ entwickeln Kaplan und Norton eine Hypothese über eine Kette von Ursachen und Wirkungen weiter, die zum strategischen Erfolg führt. Folgende vier Hypothesen dienen als Grundlage: 1. Die Grundlage für strategischen Erfolg sind Menschen 2. In lernenden und wachsenden Organisationen liefern die Mitarbeiter, die in den Kernprozessen des Unternehmens tätig sind, Ideen für die Verbesserung der Prozesse 3. Verbesserte Geschäftsprozesse führen zu verbesserten Produkten und Services. Die Balanced Score Card misst Kundenzufriedenheit, die durch die Verbesserung der Prozesse hervorgerufen wird. 4. Erhöhte Kundenzufriedenheit führt zu besserer Loyalität der Kunden und erhöhtem Marktanteil Finanzen Finanzieller Erfolg, Wie ist unser Erscheinungs-bild zu unseren Anteilseignern?

Kunden / Markt

Prozesse

Wie müssen wir gegenüber unseren Kunden auftreten um maximalen Erfolg zu haben und unsere Vision zu erreichen?

Welche Geschäftsprozesse müssen welchen Reifegrad haben um einen optimalen Erfolg zu erzielen (Shareholder / Kunden )?

Vision & Strategie

Mitarbeiter / Wachstum Wie entwickeln wir unsere Fähigkeiten zur Veränderung und Verbesserung in Hinsicht auf die Erreichung unserer Vision?

Abb. 1-7 Balanced Score Card-Modell

Die Balanced Score Card ist damit ein Instrument, um die Organisation aus vier Perspektiven zu betrachten. Für jede der Perspektiven müssen Messkriterien entwickelt werden, die zu der spezifischen Vision und Zielrichtung des Unternehmens passen. 22

1.3

Qualität, Reifegradmodelle und Steuerungsinstrumente

Obwohl dieses Instrument ursprünglich für die originären Geschäftsprozesse eines Unternehmens entwickelt wurde, wird es heute oft auch in IT-Bereichen eingesetzt. Seinen wahren Vorteil entwickelt es nämlich dann, wenn es im ganzen Unternehmen eingesetzt wird und dann eine Kette aufeinanderfolgender Scorecards bildet. Erst dann ist die gesamte Organisation auf die Unternehmensstrategie ausgerichtet.

Unternehmens Leitung

Balanced (Strategisch) Scorecard

Business Unit Management

Wertschöpfungsprozesse

Support Prozesse

Prozess (Operative) Scorecards oder individuelle Prozess Scorecards

Abb. 1-8 Scorecard Ebenen

Die Scorecard durchdringt hier das gesamte Unternehmen. ITProzesse werden als Support-Prozesse verstanden, die die primären Wertschöpfungsprozesse unterstützen. Unternehmensleitung und Business UnIT-Management entwickeln die Strategie und die dazu passende Scorecard, um das Unternehmen im Sinne der Vision und der Ziele zu steuern.

23

2

Die Struktur von COBIT In diesem Kapitel werden wir uns die Struktur des ITGovernance Modells von COBIT ansehen und die verschiedenen Dimensionen des Modells besprechen. Die Betrachtung schließt mit einer grafischen Übersicht des Gesamtprozessmodells.

2.1

Der Governance-Würfel Das COBIT Framework besteht aus den Kontrollzielen oder auch Objekten und aus der Struktur für ihre Klassifizierung. Die allgemeine Überlegung ist die, dass es drei Ebenen gibt, wenn es um das Management der IT-Ressourcen geht. Auf der untersten Ebene geht es um die Aktivitäten, die benötigt werden, um ein definiertes Resultat zu erzielen. Diese Aktivitäten werden zu natürlichen Gruppen zusammengefasst, die spezifische Kontrollen zulassen. Diese Aufgabengruppen werden Prozesse genannt. Auf der obersten Ebene werden diese Prozesse zu Domänen konsolidiert, die häufig auch den Organisationsanforderungen der ITBereiche entsprechen.

Domänen

Prozesse

Aktivitäten

Abb. 2-1 Hierarchie von COBIT

25

2

Die Struktur von COBIT Die COBIT Struktur wird um zwei weitere Dimensionen ergänzt. Diese Dimensionen sind: ¾

IT-Ressourcen

¾

Geschäftsanforderungen

Damit lässt sich das gesamte Modell in Form eines Würfels darstellen, wo die Kanten des Würfels die Dimensionen darstellen.

Ef fe kt Ef ivitä fiz t ie Ve nz rtr au li In chke te i Ve grit t rfü ät gb Co ark eit m p Zu lian Menschen ve c e rlä Anwendungssysteme ss IT ig -R ke Daten es it so Technische Infrastruktur ur ce Einrichtungen, Gebäude n

Geschäftsanforderungen

IT-Prozesse

Domänen

Prozesse

Aktivitäten

Abb. 2-2 Governance-Würfel

In der Version 4.0 werden die Themen Technische Infrastruktur und Einrichtungen, Gebäude zu Infrastruktur zusammengefasst. Um deutlich zu machen, dass hier sehr wohl ein Unterschied besteht, wurde auf die Einteilung der Version 3.0 zurückgegriffen. Diese Geschäftsanforderungen werden in COBIT auch Information Criteria genannt. In den Folgeabschnitten werden wir uns jetzt den einzelnen Dimensionen des Frameworks zuwenden und diese etwas genauer beleuchten.

26

2.2

2.2

Die Dimension der COBIT-Prozesse

Die Dimension der COBIT-Prozesse Die COBIT-Prozesse sind auf vier Domänen aufgeteilt. Diese sind: ¾

Planung & Organisation

¾

Akquisition & Implementierung

¾

Delivery & Support

¾

Monitoring und Evaluierung

Diese vier Domänen stellen einen Regelkreis dar. Planung und Organisation versorgt in erster Linie die Prozesse der Domäne Akquisition & Implementierung und in zweiter Linie das Monitoring und Evaluierung. Akquisition & Implementierung liefert den wesentlichen Input für Delivery & Support. Wir sehen an diesem Schaubild sehr deutlich, dass es eine Hierarchie in dem Ablauf gibt. Die Vorgaben kommen aus der Domäne Planung & Organisation, wohingegen die Domäne Monitoring und Evaluierung Beziehungen zu allen anderen Domänen unterhält. Dies liegt daran, dass das Monitoring Daten liefert, die in den Prozessen benötigt werden, um Verbesserungen zu erkennen und umzusetzen. COBIT setzt daher auf den Management-Zyklus nach Hopstraken & Kranendonk auf.

Strategie Modellierung, Planung

Monitoring & Korrektur

Realisierung

Delivery & Support

Abb. 2-3 Management-Zyklus nach Hopstraken & Kranendonk, 1988

27

2

Die Struktur von COBIT Im Managementzyklus entspricht „Strategie, Modellierung, Planung“ der Domäne „“Planung & Organisation“. Die anderen werden entsprechend zugeordnet. COBIT hält sich mit der Version 4.0 sehr eng an dieses Modell. Für jede dieser Domänen gibt es eine Reihe von definierten Prozessen, die als Überblick in der Tabelle aufgeführt sind. Tabelle 2-1 Prozessübersicht Planung & Organisation

Delivery & Support

PO1

Definieren eines strategischen IT-Plans

DS1

Service Level Management

PO2

Definieren der Informationsarchitektur

DS2

Lieferanten-Management

PO3

Definieren der technischen Ausrichtung

DS3

Performance und Kapazitätsmanagement

PO4

Definition der IT-Org. & ihrer Bezieh.

DS4

Continuity Management

PO5

IT-Investitionsmanagement

DS5

Sytem Security Management

PO6

Kommunizieren der Management Ziele und Strategien

DS6

Kostenmanagement

PO7

IT-Personalführungsmanagement

DS7

Anwenderschulung und Training

PO8

Managen der Qualität

DS8

Anwenderunterstützung

PO9

Risikomanagement

DS9

Konfigurationsmanagement

PO10

Projektmanagement

DS10

Problem Management

Akquisition & Implementierung

DS11

Data Management

AI1 Identifizierung automatisier Lösungen

DS12

Facility Management

AI2 Erwerb und Pflege von Applikations-SW

DS13

Operationsmanagement

AI3 Erwerb und Pflege der technischen IS

Monitoring und Evaluierung

AI4 Befähigen des Betriebes

ME1

Überwachen und evaluieren IT Performance

AI5 Zur Verfügungstellung von IT-Ressourcen

ME2

Überwachen und evaluieren interner Kon trollen

AI6 Change Management

ME3

Sicherstellung der Einhaltung gesetzlicher Vorschriften

AI7 Installieren und Abnehmen von Systemen und Änderungen

ME4

Sorgen für IT-Governance

2.2.1

Planung und Organisation (PO) Diese Domäne beschäftigt sich mit der Strategie und der Taktik der IT, um zu bestimmen, welches der beste Weg für die IT ist, die Erreichung der Geschäftsziele zu unterstützen. Die Umsetzung dieser Strategie muss geplant, kommuniziert und durchgeführt werden und das aus verschiedensten Blickwinkeln heraus. Damit sind im Wesentlichen die Themen Informationsarchitektur und Technologische Ausrichtung gemeint. Daneben ist sicher zu stellen, dass eine für die Umsetzung der Vision geeignete Organisation und technische Infrastruktur bereitgestellt wird. Die

28

2.2

Die Dimension der COBIT-Prozesse

Domäne Monitoring & Evaluierung liefert Input in Form der strategischen Aussagen des Geschäftes zur IT-Ausrichtung. Die Hauptprozesse dieser Domäne stellen die vier Prozesse PO1 (Definieren eines strategischen Plans), PO2 (Definieren der Informationsarchitektur), PO3 (Definieren der technischen Ausrichtung) und PO4 (Definition der IT Org. & ihrer Beziehungen) dar. Diese vier Prozesse müssen interaktiv und iterativ ausgeführt werden. Die Ergebnisse eines Prozesses beeinflussen direkt auch das Ergebnis der anderen Prozesse. Die größten Einflussfaktoren für diese Prozesse sind die Anforderungen des Geschäftes in Form von erneuerten Service- und Projektportfolios. Als wesentliche IT-externe Einflüsse sind an dieser Stelle die Geschäftsstrategie und deren Prioritäten zu nennen, die direkten Einfluss auf die strategische Ausrichtung der IT nehmen. Die Ergebnisse dieser strategischen Prozesse sind die Eingangsgrößen in die Prozesse PO5 (IT-Investitionsmanagement), PO6 (Kommunizieren der Management-Ziele und Strategien) und PO7 (Personalführungsmanagement). Die restlichen Prozesse, rechts außerhalb in einem separaten Kasten dargestellt, haben eine übergreifende Funktion und daher eine große Bedeutung nicht nur für die Prozesse dieser Domäne, sondern auch für die Prozesse in den anderen Domänen. Geschäftsanforderungen

Delivery & Support

Monitoring & Evaluierung

Definieren eines strategischen Plans

Definieren der Informationsarchitektur

Definieren der technischen Ausrichtung

Risikomanagement

Definition der IT Org. & ihrer Beziehungen

Projektmanage ment

Qualitätsmanagement

IT Investitionsmanagement

Kommunizieren der Mgmt Ziele und Strategien

Delivery & Support

Personalführungs -management

Monitoring & Evaluierung

Akqisition & Implementierung

Abb. 2-4 Planung & Organisation

29

2

2.2.2

Die Struktur von COBIT

Akquisition & Implementierung Um eine IT-Strategie umzusetzen, ist es notwendig, IT-Lösungen festzulegen, zu entwickeln oder zu erwerben. Ist dies erfolgt, so gilt es diese auch zu implementieren und in den Geschäftsprozess zu integrieren. Da die IT-Lösungen, Systeme oder Architekturen nie statisch sind, sondern Veränderungen unterliegen oder Störungen auftreten können, enthält diese Domäne auch das Change Management und die Wartung (maintenance). Geschäftsanforderungen werden in aller Regel über die Domäne PO transportiert. Allgemeine Anforderungen des Kerngeschäftes, beispielsweise Richtlinien und Regeln für den Einkauf, sind von dieser Domäne ebenfalls zu berücksichtigen. Die in der Domäne PO definierte Strategie und technologische Ausrichtung sowie die geschäftlichen und externen Anforderungen sind die Eingangsgrößen in den Prozess AI1 (Identifizierung automatisierter Lösungen). Dieser Prozess liefert als Ergebnis die Änderungen der IT-Infrastruktur, die notwendig sind, um die Strategie umzusetzen und die Anforderungen zu erfüllen. AI6 (Change Management) führt die Änderungen durch und zwar in der Weise, dass möglichst wenige oder keine Störungen am Betriebsablauf entstehen. Die drei dann folgenden Prozesse AI2 (Erwerb und Pflege von Applikationssoftware), AI3 (Erwerb und Pflege der technischen Infrastruktur), AI4 (Befähigen des Betriebs) und AI5 (Zur Verfügungstellung von IT-Ressourcen) bilden eine Einheit, die in ihrer Gesamtheit ein funktionierendes Informationssystem (IT-Lösung) liefern. Der Prozess AI6 (Changemanagement) liefert die Prozeduren, um im Prozess AI7 (Installieren und Abnehmen von Systemen und Änderungen) diese IT-Lösung in den operativen Betrieb überführen, indem die Lösung einem formalen Abnahmeprozess unterzogen und anschließend installiert und dem Betrieb übergeben wird. Wie auch in der Domäne Planung und Organisation werden die übergreifenden Prozesse, rechts außerhalb in einem separaten Kasten dargestellt. Sie wirken in ihrer Gesamtheit auf alle Prozesse der Domäne.

30

2.2 Geschäftsanforderungen

Die Dimension der COBIT-Prozesse

Planung & Organisation

Delivery & Support

Identifizierung automatisier Lösungen

Erwerb und Pflege von Applikationssoftware

Erwerb und Pflege der techn. Infrastruktur

Risikomanagement

Entwicklung und Pflege von Prozeduren

Projektmanagement

Qualitätsmanagement

Change Management

Installieren und Abnehmen von Systemen und Änderungen

Planung & Organisation

Monitoring & Evaluierung

Delivery & Support

Abb. 2-5 Akquisition & Implementierung

2.2.3

Delivery & Support In dieser Domäne werden die IT-Services geliefert. Der Umfang umfasst dabei nicht nur die traditionellen Themen wie das Operating, die Administration, sondern auch solche Themen wie Sicherheit und Schulungen. Um diese Services liefern zu können sind als erstes die Supportprozesse aufzusetzen. Damit die Ausrichtung der Services optimal erfolgt, nimmt der Prozess DS1 (Service Level Management) alle Anforderungen auf und überführt diese in die Betriebsorganisation. Damit ist dieser Prozess der Wichtigste in dieser Domäne. Da die Services meist nicht alleine, das heißt durch die interne IT-Organisation erbracht werden, sind immer auch Partner beteiligt. Dieser Prozess DS2 (Lieferanten-Management) wird immer wichtiger, da die Fertigungstiefe immer mehr abnimmt. Dies liegt daran, dass die Beherrschung der Komplexität heutiger Infrastrukturen immer mehr Organisationen überfordert. Diese Entwicklung hat aber auch mit den Kosten zu tun, denn Reduzierung von Kosten ist in der heutigen Zeit ein Muss. Es ist daher natürlich, dass diese beiden Prozesse direkt mit dem Prozess DS6 (Kostenmanagement) verknüpft sind. Das Service Level Management liefert den Input für die operationalen Prozesse DS11 (Data Management), DS12 (Facility Mana31

2

Die Struktur von COBIT gement) und DS13 (Operationsmanagement). Dieser Input besteht in den Performance-Kriterien (internen SLAs), gegen die die Leistung der gelieferten Services in Form von Quantität und Qualität gemessen wird. Service Level Management liefert auch wichtige Beiträge z.B. in Form von SLAs zu den Domänen PO und AI. Der Prozess DS8 (Anwenderunterstützung) stellt eine Kontaktstelle für Anwender zur Verfügung, die jedes Problem aus der IT, dem ein Anwender sich gegenübersieht, annimmt und weiterverarbeitet. Dieser Prozess betrachtet den Servicedesk und das Incident Management. Der darauf folgende Prozess DS10 (Problem Management) sorgt für eine professionelle und schnelle Behebung von Problemen. Alle diese Prozesse sind darauf angewiesen, dass im Rahmen des Prozesses DS9 (Konfigurationsmanagement) die Infrastruktur korrekt und angemessen dokumentiert wird. Die Prozesse DS3 (Performance und Kapazitätsmanagement), DS4 (Continuity Management), DS5 (Security Management) und DS7 (Anwenderschulung und Training) sind außerhalb des Kernbereichs dieser Domäne dargestellt, da sie die anderen Prozesse in dieser Domäne unterstützen. Die rechts außerhalb dargestellten Prozesse sind wie bei den vorhergegangen Domänen dargestellt um die Vollständigkeit sicher zu stellen. Geschäftsanforderungen

Performance und Kapazitätsmanagement

Continuity Management

Planung & Organisation

Akquisition & Implementierun g

Kostenmanagement

Service Level Management

Lieferantenmanagement

Data Management

Facility Management

Operationsmanagement

System Security Management

Anwenderschulung und Training

Projektmanagement

Qualitätsmanagement Anwenderunterunterstützung

Konfigurationsmanagement

Problem Management

Planung & Organisation

Abb. 2-6 Delivery & Support

32

Risikomanagement

Akquisition & Implementierung

Monitoring & Evaluierung

2.2

2.2.4

Die Dimension der COBIT-Prozesse

Monitoring und Evaluierung Alle IT-Prozesse müssen regelmäßig auf die Einhaltung der festgelegten Standards und der Qualitätskriterien überprüft werden. Diese Domäne berücksichtigt die Management-Sicht auf den Kontrollprozess der Organisation, die Erlangung von unabhängigen Audits, von internen und externen oder anderen Quellen. Daneben wird für die Einhaltung gesetzlicher Vorschriften gesorgt und die Durchdringung der Governancestrukturen in die gesamte Organisation sichergestellt. Der Prozess M4 (Sorgen für IT-Governance) bildet die Grundlage dieser Domäne, denn er liefert das Gerüst, an dem die anderen Prozesse sich orientieren. Er sorgt für den Überbau, wohingegen die anderen Prozesse die operative Durchführung im Fokus haben. Externe Anforderungen und sonstige Geschäftsanforderungen spielen hier eine wesentliche Rolle, da Diskussionen und Veränderungen im Gesellschaftsrecht von Unternehmen immer auch Auswirkungen haben können. Auch hier werden wieder die übergreifenden Themen rechts außen dargestellt.

Geschäftsanforderungen

Planung & Organisation

Akquisition & Implementierung

Delivery & Support

Risikomanagement

Überwachen und Evaluieren IT Performance Überwachen und Evaluieren interner Kontrollen

Projektmanagement

Sorgen für IT Governance

Qualitätsmanagement

Sicherstellung der Einhaltung gesetzlicher Vorschriften

Externe Berichterstattung

Planung & Organisation

Externe Anforderungen

Akquisition & Implementierung

Delivery & Support

Berichte für das Business

Abb. 2-7 Monitoring und Evaluierung

33

2

2.3

Die Struktur von COBIT

Ressourcen Im Allgemeinen unterscheidet man fünf Klassen von IT-Ressourcen, die in der folgenden Tabelle aufgezeigt werden. Tabelle 2-2 IT-Ressourcen Nr.

Qualitätskriterium

Erläuterung

A

Personal

Informationssysteme und Services benötigen Menschen, um durchgeführt zu werden, also um zu planen, zu organisieren, einzukaufen, zu unterstützen und zu überwachen

B

Applikationssysteme

manuell durchgeführte und programmierte Prozeduren, Anwendungssoftware

C

Technische Infrastruktur

enthält die HW, Betriebssysteme, Datenbanken, Netzwerke und Netzwerksoftware, etc

D

Facilities

das sind die Ressourcen, die benötigt werden um die technische Infrastruktur aufzustellen und sowohl das Geschäft als auch die Informationssysteme zu unterstützen (Räume, Strom, Klima)

E

Daten

zur Darstellung externer und interner Objekte, seien diese strukturiert oder unstrukturiert, Grafiken, Text, Audidateien, etc

Die Version 4.0 von COBIT fasst die Technische Infrastruktur und die Facilities in eine Einheit zusammen und nennt diese einfach Infrastruktur. Steuerung und Planung von IT-Ressourcen erfordern eine Abbildung in den technischen IT-Systemen, die zur Verwaltung der Ressourcen benutzt werden. Die Abbildung Abb. 2-8 zeigt, wie diese Informationssysteme in bedeutungsvolle Einheiten aufgeteilt werden können. Auf diese Einteilung ist besondere Sorgfalt zu verwenden, da diese zu einem wesentlichen Teil die spätere Qualität des Gesamtsystems und auch die Qualität des Supports für diese Informationssysteme bestimmt.

34

2.4

Geschäftsanforderungen

Informationssysteme

Applikationen

Information

Standardsoftware

Dokumentation

Individual Software

Datenbanken

Infrastruktur

Technische Infrastruktur Hardware

Personal

IT Mitarbeiter

IT Anwender

System SW Netzwerke

Facilities Gebäude Zugänge Strom, Klima

Abb. 2-8 Aufteilung der Informationssysteme

Jeder COBIT-Prozess hat mit der Kontrolle einer oder mehrer ITRessourcen zu tun. Die Intensität der Abhängigkeit der Ressourcen untereinander hängt dabei von den unterschiedlichsten Faktoren ab. Eine genaue Kenntnis dieser Abhängigkeiten ist aber unabdingbar um keine Fehlsteuerungen zu produzieren.

2.4

Geschäftsanforderungen Die im Governance-Würfel gezeigten sieben Kriterien zu Geschäftsanforderungen wurden aus den folgenden Überlegungen heraus abgeleitet. Das COBIT zu Grunde liegende Prinzip ist es, dass die Kontrolle der IT am besten funktioniert, wenn die für das Geschäft notwendige Information in Betracht gezogen wird. Das bedeutet nichts anders, als die Aufstellung von Kriterien für genau diese geschäftsrelevanten Informationen. Da es bereits umfangreiche Vorarbeiten aus anderen Standardisierungsbemühungen gibt, wurden bei der Erstellung von COBIT diese anderen Referenzmodelle herangezogen. ¾

¾

Qualitätsanforderungen o

Qualität

o

Kosten

o

Lieferung

Treuhänderische Anforderungen (COSO-Bericht) o

Effektivität und Effizienz des Betriebes 35

2

Die Struktur von COBIT

¾

o

Verlässlichkeit der Informationen

o

Verträglichkeit mit Gesetzen und Vorschriften

Sicherheitsanforderungen o

Vertraulichkeit

o

Integrität

o

Verfügbarkeit

Qualität wird oft in ihren negativen Aspekten betrachtet, keine Fehler, Zuverlässigkeit, etc. Dieses wird weitgehend abgedeckt durch das Informationskriterium. Die positiven, aber weniger greifbaren Aspekte der Qualität, wie Attraktivität, Aussehen, Übererfüllung, etc werden durch die anderen Aspekte abgedeckt. Der Verwendbarkeitsaspekt wird durch das Effektivitätskriterium berücksichtigt. Der Lieferaspekt überlappt stark mit dem Verfügbarkeitsaspekt der Sicherheitsanforderungen und auch bis zu einem gewissen Grade mit der Effektivität und der Effizienz. Schließlich sind es auch die Kosten, die durch das Kriterium der Effizienz bereits berücksichtigt sind. Für die treuhänderischen Anforderungen werden in COBIT die von ISACA und COSO benutzten Definitionen für Effektivität und Effizienz benutzt, anstatt neue zu entwickeln. Dies liegt einfach daran, dass diese Definitionen weitgehend akzeptiert sind. Dies trifft nicht auf die Zuverlässigkeit (reliability) zu. Diese wurde auf die gesamte zu betrachtende Information ausgedehnt und nicht begrenzt auf die finanziellen Informationen. Bei der Berücksichtigung der Sicherheitsanforderungen, hat COBIT die drei Schlüsselelemente Vertraulichkeit, Integrität, Verfügbarkeit übernommen, denn diese Begriffe werden weltweit einheitlich für diesen Sachverhalt benutzt. Aus den drei oben genannten Oberbegriffen wurden sieben Kriterien herausdestilliert, die für diese Abhandlung und für COBIT die Qualitätskriterien oder auch Geschäftsanforderungen sind, an denen gemessen wird.

36

2.4

Geschäftsanforderungen

Tabelle 2-3 Geschäftsanforderung / Qualitätskriterien Nr.

Geschäftsanforderung / Qualitätskriterium

Erläuterung

1

Effektivität

Das Ausmaß, in welchen die Information den definierten Zielen dient. Bewertet die Information, die für den Geschäftsprozess relevant und sachdienlich ist in Bezug auf die Lieferung in zeitlicher, korrekter und konsistenter und verwendbarer Art und Weise.

2

Effizienz

Das Ausmaß, in dem die Informationen im akzeptablen Kosten- und Aufwandrahmen zur Verfügung gestellt werden.

3

Vertraulichkeit

Der Schutz von sensiblen Daten vor nicht autorisiertem Zugriff. Im Englischen Confidentiality genannt.

4

Integrität

Die Genauigkeit und die Vollständigkeit von Informationen sowie deren Gültigkeit und Werthaltigkeit in Bezug auf die Geschäftsanforderungen

5

Verfügbarkeit

Bezieht sich auf die Verfügbarkeit von Informationen zum Zeitpunkt, zu dem die Geschäftsprozesse diese verwenden wollen. Es hat außerdem mit der Sicherheit der notwendigen Ressourcen. Im Englischen Sprachgebrauch wird von Availability gesprochen.

6

Übereinstimmung / Compliance

Vereinbarkeit der Prozesse im Geschäftsverkehr und in der IT mit den gesetzlichen Regeln und Vorschriften sowie mit den geschlossenen Verträgen.

7

Verlässlichkeit

Die Güte der Lieferung geeigneter Informationen für das Management zur Führung der Organisationseinheit und um die finanziellen und gesetzlichen Berichtsverantwortlichkeiten zu erfüllen.

/ Reliability

Der Geschäftsprozesseigner definiert, welche Informationen benötigt werden, um die Geschäftsziele zu unterstützen. COBIT, als ein Instrument zur Steuerung der IT, identifiziert die Prozesse innerhalb der vier Domänen und die IT-Ressourcen, die für die Erreichung der Qualitätskriterien notwendig sind. Die folgende Tabelle zeigt Ihnen überblickweise, welche Informationskriterien durch die Kontrollziele beeinflusst werden und welche Ressourcen dafür nötig sind und sie zeigt auch die Prozessabhängigkeiten. Dabei werden zwei Fälle unterschieden. Primäre Informationskriterien (P): das definierte Kontrollziel beeinflusst direkt das betroffene Informationskriterium.

37

2

Die Struktur von COBIT Sekundäres Informationskriterium (S): das definierte Kontrollziel beeinflusst indirekt oder nur wenig das betroffene Informationskriterium. Ist keine Markierung angegeben, bedeutet das nicht, dass keine Beziehung besteht. Diese ist nur nicht besonders ausgeprägt oder eben nur marginal. Wie ersichtlich ist, beeinflusst nicht jedes Informationskriterium die verschiedenen Geschäftsanforderungen oder auch Informationskriterien in gleicher Weise. Tabelle 2-4 Einflussfaktoren, Ressourcen

P

P

PO4 Definition der IT Org. & ihrer Beziehungen

P

P

PO5 IT Investitionsmanagement

P

P

PO6 Kommunizieren der Mgmt Ziele und Strateg.

P

PO7 Personalführungsmanagement

P

P

PO8 Managen der Qualität

P

P

PO9 Risikomanagement

S

S

PO10 Projektmanagement

P

P

AI1 Identifizierung automatisierter Lösungen

P

S

AI2 Erwerb und Pflege von Applikationssoftware

P

P

S

AI3 Erwerb und Pflege der technischen IS

S

P

S

Infrastruktur

PO3 Festlegen der technischen Ausrichtung

Appl.systeme

P

Information

S

Ressourcen Personal

PO2 Definieren der Informationsarchitektur

Reliability

S

Compliance

P

Verfügbarkeit

Effizienz

PO1 Definieren eines strategischen Plans

Integrität

Effektivität

Vertraulichkeit

Geschäftsanforderung/Informationskriterien

x

x

x

x

x

x

Planung und Organisation

S

P

x

x

x

x

x S S

x x

x

x S P

P

P

S

S

x

x

x

x

S

x

x

x

x

x

x

x

x

x

Akquisition & Implementierung

38

S S

x x

Geschäftsanforderungen

Reliability

Personal

S

x

P

P

AI5 Zur Verfügung stellen von IT-Ressourcen

S

P

AI6 Change Management

P

P

P

P

AI7 Installieren und Abnehmen von Systemen und Änderungen

P

S

S

S

DS1 Service Level Management

P

P

S

S

S

S

DS2 Lieferanten-Management

P

P

S

S

S

S

DS3 Performance und Kapazitätsmanagement

P

P

DS4 Continuity Management

P

S

Information

Compliance S

AI4 Befähigen des Betriebes

Infrastruktur

Verfügbarkeit S

Effizienz

Integrität

Ressourcen

S

Effektivität

Vertraulichkeit

Geschäftsanforderung/Informationskriterien

Appl.systeme

2.4

x

x

x

x

x

x

x

x

x

x

x

x

x

x

S

x

x

x

x

S

x

x

x

x

x

x

S S

Delivery & Support

DS5 System Security Management

P P

DS6 Kostenmanagement DS7 Anwenderschulung und Training

S

S

S

P P

S

DS8 Anwenderunterstützung

P

P

DS9 Konfigurationsmanagement

P

S

DS10 Problem Management

P

P

M1 Überwachen und evaluieren IT Performance

P

P

M2 Überwachen und evaluieren interner Kontrollen

P

P

x

x

x

x

x

P

x

x

x

x

x

x

x

x

x

x

S

S

DS12 Facility Management P

x

x

x S

x

P P

x S

x

DS11 Data Management DS13 Operations-management

P

P

P

P

S

S

S

S

S

S

S

S

S

x

x x x

x

x

x

S

x

x

x

x

S

S

x

x

x

x

P

S

x

x

x

x

S

S

x

x

x

x

Monitoring und Evaluierung

M3 Sicherstellung der Einhaltung gesetzlicher Vorschriften M4 Sorgen für IT-Governance

P

P

S

S

S

39

2

Die Struktur von COBIT

COBIT nennt fünf Hauptbereiche (Governance Fokus Areas) für die IT. Tabelle 2-5 Fokus-Bereiche der IT-Governance Nr.

Fokus-Bereich

Erläuterung

1

Strategische Ausrichtung der IT

Die IT ist an den Geschäftsbereichen auszurichten. Die Strategie der IT muss der Strategie der Kerngeschäftes folgen und an dieser sich messen lassen

2

Wertbeitrag

Welchen Wertbeitrag (Value Delivery) liefert die IT? Kann dieser quantifiziert und gemessen werden? Wie hoch ist dieser Wert?

3

Ressourcen Management

Die Ressourcen sind verantwortlich zu managen und auf die Anforderungen des Geschäftes auszurichten.

4

Risiko Management

Betrieb von IT birgt Risiken, aber auch Chancen. ITGovernance hat ein Risikomanagement System zu etablieren, das es erlaubt Risiken, aber auch Chancen zu erkennen und adäquat zu behandeln.

5

Performance Management

Die Leistungsfähigkeit des IT-Bereiches ist zu steigern und zu einem Optimum zu führen. Prozess sind zu implementieren, die das permanente Bemühen um Leistungssteigerung in der Organisation verankern.

Jeder Prozess trägt in unterschiedlichem Maße zu diesen Fokusbereichen bei. Die folgende Tabelle zeigt die Wichtigkeit der einzelnen Prozesse für die IT-Governance auf und wie diese auf die Fokus-Bereiche wirken. Für die Wichtigkeit wird dabei die Einteilung hoch, mittel und niedrig verwendet. Tabelle 2-6 Wichtigkeit und Wirkungsbereich der Prozesse

S

P

S

N

S

P

S

M

P

P

N

Wichtigkeit

Risiko Management S

Performance Management

Ressourcen Management S

Wertbeitrag

Strategische Ausrichtung

IT-Governance Fokusbereich

Planung und Organisation PO1

40

Definieren eines strategischen Plans

P

PO2

Definieren der Informationsarchitektur

P

PO3

Definieren der technischen Ausrichtung

S

PO4

Definition der IT Org. & ihrer Beziehungen

S

PO5

IT-Investitionsmanagement

S

P

S

H

S

M

2.4

Geschäftsanforderungen

P

Wichtigkeit

Performance Management

Risiko Management

Ressourcen Management

Wertbeitrag

Strategische Ausrichtung

IT-Governance Fokusbereich

PO6

Kommunizieren der Mgmt Ziele und Strateg.

P

PO7

Personalführungsmanagement

P

PO8

Managen der Qualität

P

PO9

Risikomanagement

P

PO10

Projektmanagement

P

S

S

S

AI1 Identifizierung automatisierter Lösungen

P

P

S

S

M

AI2 Erwerb und Pflege von Applikationssoftware

P

P

S

M

P S

S

M S

N

S

M

P

H S

H

Akquisition & Implementierung

AI3 Erwerb und Pflege der technischen IS AI4 Befähigen des Betriebes

P P

S

AI5 Zur Verfügung stellen von IT-Ressourcen

S

P

M

AI6 Change Management

P

S

H

S

P

S

P

P

P

AI7 Installieren und Abnehmen von Systemen und Änderungen

S

N S

S

N

S

M

P

M

Delivery & Support DS1 Service Level Management DS2 Lieferanten-Management

P

S

P

S

N

DS3 Performance und Kapazitätsmanagement

S

S

P

S

S

N

DS4 Continuity Management

S

P

S

P

S

M

DS5 System Security Management

P

DS6 Kostenmanagement

S

DS7 Anwenderschulung und Training

S

P

DS8 Anwenderunterstützung

S

P

P

H S

S

N N

S

N

DS9 Konfigurationsmanagement

P

S

M

DS10 Problem Management

P

S

M

DS11 Data Management

P

P

P

H

DS12 Facility Management

S

P

N

DS13 Operationsmanagement

P

N

Monitoring und Evaluierung

41

2

Die Struktur von COBIT

M1 Überwachen und evaluieren IT Performance

P

M2 Überwachen und evaluieren interner Kontrollen

P

M3 Sicherstellung der Einhaltung gesetzlicher Vorschriften

P

M4 Sorgen für IT-Governance

P

2.5

P

P

Wichtigkeit

Performance Management

Risiko Management

Ressourcen Management

Wertbeitrag

Strategische Ausrichtung

IT-Governance Fokusbereich

H

P

M

P

H

P

P

H

Gesamtprozessübersicht Die folgende Grafik Abb. 2-9 zeigt das gesamte Modell im Überblick. Ein Teil der englischen Begriffe wird häufig auch übersetzt. Überwachung steht dabei für Monitoring & Evaluierung Betrieb & Unterstützung steht für Delivery & Support Beschaffung & Implementation steht für Akquisition & Implementierung Die meisten anderen Begriffe sind selbsterklärend, und Sie sollten sich in der englischen Literatur gut zurecht finden können.

42

Themen • Effektive Ablieferung benötigter Dienstleistungen • Wirklich sicherer Betrieb inkl. Training • Aufstellung von Unterstützungsprozessen • Effektive Datenverarbeitung durch Anwendungen

Delivery & Support

Monitoring & Evaluierung

Themen • Regelmäßige Beurteilung aller ITProzesse • Einhaltung und Qualität der Kontrollen • IT Governance organisieren

• Daten • Anwendungen • Technologien • Anlagen • Personal

IT-Ressourcen

Information

Kriterien (Ziele) • Effizienz • Effektivität • Vertraulichkeit • Integrität • Verfügbarkeit • Compliance • Reliability.

Geschäftsziele Governance-Ziele

Themen • Realisierung der IT-Strategie • Lösungen identifiziert, entwickelt oder beschafft und implementiert • Lösungen in den Geschäftsprozess integriert • Änderung und Unterhalt von Systemen

Akquisition & Implementierung

Planung & Organisation

Themen • Strategie und Taktik für die ITUnterstützung • Erfüllung der Geschäftsanforderungen • Ausreichend geplant, kommuniziert und “gemanaged” • Korrekte organisatorische und technische Infrastruktur

2.5 Gesamtprozessübersicht

Abb. 2-9 Gesamtübersicht Framework

43

3

COBIT-Prozessbeschreibung Das zentrale Thema in COBIT ist die Kontrolle über die Prozesse, die in der IT aufzusetzen sind, um im Sinne einer guten ITGovernance die IT zu steuern. Dies bedeutet, es ist ein internes Kontrollsystem (IKS) aufzusetzen, das entsprechend begutachtet und bewertet werden kann. Dies entspricht auch den Anforderungen der entsprechenden Corporate Governance-Richtlinien, denen die Firma unterliegt. Dieses Kapitel erläutert daher die Prozesse so detailliert wie nötig, nennt die Kontrollmöglichkeiten, Ergebnisse, Aktivitäten und zeigt die Beziehungen zu den anderen Prozessen auf. Die Aufstellung von Kontrollzielen erfordert die Frage, wie die Kontrollziele überprüft werden. Auch auf dieses Thema wird bei den jeweiligen Prozessen eingegangen. Zum besseren Verständnis beginnt das Kapitel mit einer Einführung über die Darstellung von Prozessen, wie sie in diesem Buch verwendet wird. Die Darstellung der Prozesse soll einen ersten Überblick liefern und bildet keineswegs das vollständige Set von Kontrollzielen und Kontrollmöglichkeiten ab, die in COBIT genannt werden. Sie ergeben aber durch die Konzentration auf das Wesentliche einen guten Einstieg in die Problematik.

3.1

Die verwendete Prozessdarstellung Im Grundsatz besteht jeder Prozess aus einer Abfolge von Tätigkeiten, die aus gegebenen Eingangsgrößen (Input) ein Ergebnis (Output) produziert. Jeder Prozess enthält dabei eine Reihe von Charakteristiken. Diese bilden aber einen Prozess nur dann vollständig ab, wenn er durch eine Beschreibung des Sinns und Zwecks sowie des Ziels des jeweiligen Prozesses ergänzt wird. Die folgende Abbildung zeigt die verwendete Prozessdarstellung.

45

3

COBIT-Prozessbeschreibung Control Objectives KGI

Prozess Input

IC

Prozess Output

Prozess Aktivitäten CSF

KPI

IT-Ressourcen Abb. 3-1 Generische Prozessdarstellung

Diese Gesamtheit aller Prozesskennzeichen werden wir im Folgenden kurz erläutern.

46

1.

Prozessinhalt: Kurze Beschreibung des Prozesses in Form eines Diagramms und eines erläuternden Textes.

2.

Ziel: Was soll mit dem Prozess erreicht werden?

3.

KGI (Key Goal Indicators): Die wichtigsten Kennzeichen für die Bewertung, ob der Prozess sein Ziel erreicht, also effektiv arbeitet.

4.

Control Objectives: Das sind die Objekte oder auch Ziele, die bewertet werden, um zu beurteilen, ob der Prozess seine Ziele erreicht hat. Er liefert darüber hinaus eine Aussage zu dem gewünschten Ergebnis oder Zweck, der erreicht werden soll indem eine Kontrollprozedur in einer IT Aktivität eingeführt wird.

5.

Prozess Input: die wichtigsten Eingangsgrößen für den Prozess.

6.

Prozess Output: die wichtigsten Produkte des Prozesses.

7.

Informationskriterien: die Art und Weise in der Informationskriterien den Prozess beeinflussen

8.

IT-Ressourcen: Alle Ressourcen, die für die Ausführung des Prozesses wichtig sind.

9.

Aktivitäten: die Tätigkeiten, die im Rahmen des Prozesses durchgeführt werden (siehe auch das generische Aktivitätenmodell in Abb. 3-2).

3.1

Die verwendete Prozessdarstellung

10. Prozesskontrolle: Ein wesentlicher Teil eines jeden Prozesses ist die Überwachung der Prozessaktivitäten. Diese Überwachung ist standardisiert und für jeden Prozess gleich und ist daher nicht Bestandteil der Prozessbeschreibung. Die Themen für jeden Prozess sind: ¾

Funktionen und Verantwortlichkeiten: die Kontrollfunktionen und Verantwortlichkeiten, die für jeden Prozess definiert werden können

¾

KPI (Key Performance Indicators): die wichtigsten Performance Indikatoren für den Prozess

11. Berichterstattung: Angepasstes Berichtswesen für den Prozess 12. Beziehungen zu anderen Prozessen: Erklärung, wie der einzelne Prozess mit den anderen Prozessen des Frameworks verknüpft ist (siehe Abb. 3-4) 13. Kosten und Vorteile: ¾ Kosten: die wesentlichen Kostentreiber für den Prozess ¾ Vorteile: Die Vorteile, die durch eine Kontrolle des Prozesses gewonnen werden 14. Kritische Erfolgsfaktoren und Engpässe: ¾

Kritische Erfolgsfaktoren: die wesentlichen Erfolgsfaktoren für den Prozess

¾

Engpässe: die kritischsten Probleme für diesen Prozess

15. Reifegradmodell: die Kriterien für die verschiedenen Reifegrade im Rahmen des Reifegradmodells für diesen Prozess

47

3

COBIT-Prozessbeschreibung

Überwachung

Prozess Input

Aktivitäten 1

Aktivitäten 2...n

Überprüfung

Nein

Richtig Ja

Ende Abb. 3-2 Generisches Aktivitätenmodell

Dieses Buch stellt eine Einführung dar. Die Darstellung der Prozesse beschränkt sich daher auf einige wesentliche Themenbereiche. Im COBIT Framework selbst ist der folgende Aufbau eingehalten: Die Kontrolle von

IT Prozesse zur Erfüllung der

Business Anforderungen

wird ermöglicht durch

Kontrollaussagen

unter Nutzung von

Kontroll Methoden Abb. 3-3 Struktur des Frameworks

48

3.1

Die verwendete Prozessdarstellung

Diese Darstellung wird ergänzt durch ¾

detaillierte Aussagen zu Input und Output des Prozesses

¾

eine Aktivitätenliste mit Verantwortlichenzuordnung

¾

Zielwerten und Metriken

¾

Reifegradmodelleinstufungen

Für diese Einführung werden wir uns auf einige Themen beschränken. Diese sind: 1.

Kurzbeschreibung des Prozesses

2.

Ziele

3.

Ergebnisse

4.

Aktivitäten

5.

Kontrollen

6.

Beziehungen zu anderen Prozessen

Für jeden Prozess wird also neben der kurzen Einführung des Prozesses ein Flowchart gezeigt, das die bedeutendsten Aktivitäten darstellt. Diese Aktivitäten werden dann näher erläutert oder auch Hinweise gegeben, auf welche Themen bei dem Prozess besonders zu achten ist. COBIT legt den Schwerpunkt auf die Kontrolle. In der Literatur finden Sie daher keine wirklich ausgefeilte Darstellung der COBIT-Prozesse. Jeder der dargestellten COBIT-Prozesse enthält den Prozessschritt Überprüfung. Dieser ist obligatorisch, da immer geprüft werden muss, ob die vorhergehenden Prozessaktivitäten auch das gewünschte Resultat liefern. Außerdem dient dieser Schritt dazu, einen sich selbst verbessernden Prozess zu beschreiben. Der Part Kontrollen beschreibt nun, wie überprüft wird, ob der Prozess auch gelebt wird und welche Prüfpunkte hier angesetzt werden können. Im allgemeinen enthält dieses Unterkapitel eine Auflistung der Kontrollobjekte oder Ziele. Wie bereits ausgeführt ist diese Beschreibung nicht vollständig im COBIT-Sinne, sondern gibt einen ersten Anhaltspunkt und Überblick. Die genannten Kontrollobjekte sind immer vom Management auf Vorhandensein und auch auf Effektivität und Effizienz zu prüfen. Daneben gibt es immer eine Reihe weiterer Hinweise, auf welche Themen sich Kontrollen ebenfalls erstrecken können. Für die Kontrolle gilt außerdem, dass es natürlich schwer ist die Vollständigkeit z.B. einer Dokumentation nachzuweisen. Hier behilft man sich mit der Überprüfung einer Auswahl von Items. 49

3

COBIT-Prozessbeschreibung Soll beispielsweise die gesamte Dokumentation aller Applikationen vorliegen, so prüfe man für eine Auswahl von Applikationen, ob dafür die Dokumentation vorliegt. Benchmarking ist ebenfalls eine gute Möglichkeit der Kontrolle. Oft können hier Vergleiche und Bewertungen angestellt und die entsprechenden Schlussfolgerungen gezogen werden. Verbesserungsbedarf lässt sich so auf relativ einfache Weise erkennen. Diese muss dann von einer detaillierten Analyse unterfüttert werden. Prinzipiell sind Kontrollen im Rahmen der Prozesse als interne Kontrollen zu definieren und durch externe Audits zu unterfüttern. Prozessbeziehungen Für jeden Prozess werden in der dargestellten Form auch die Beziehungen zu den anderen Prozessen verdeutlicht.

Prozess Prozesseingang Ergebnis 1

Prozessbeziehung

Ergebnis n

Prozessbeziehung

Ergebnis 1

Prozessbeziehung

Ergebnis n

Prozessbeziehung

Abb. 3-4 Generisches Beziehungsdiagramm

Dieses Beziehungsdiagramm soll veranschaulichen, welche Eingangsgrößen in den Prozess einfließen. Es zeigt die Ergebnisse des Prozesses und liefert Informationen darüber, welche Prozesse diese Ergebnisse nutzen.

50

3.2

PO Planung und Organisation

3.2

PO Planung und Organisation

3.2.1

PO1 Definieren eines strategischen Plans Kurzbeschreibung Das Definieren einer Strategie ist für jeden Unternehmensbereich eine wichtige Aufgabe. Dies gilt für das Kerngeschäft eines Unternehmens, wie auch für die Unternehmensteile, die sich in ihrer Strategie an der des Kerngeschäftes ausrichten müssen. Für die IT, als einer der wesentlichen Stützprozesse, wenn nicht sogar Treiber des Kerngeschäftes, gilt dies in besonderem Maße. Es dient dazu die IT zukunftsfähig am Kerngeschäft auszurichten. Der Zyklus sollte für die langfristige Strategie nicht länger als ein Jahr betragen. Für die kurzfristige Strategie empfiehlt sich im schnelllebigen IT-Umfeld ein Dreimonatsrhythmus. COBIT selbst gibt hier keine Empfehlungen ab, sondern überprüft nur das Vorhandensein eines entsprechenden Prozesses und der dazu gehörenden Ergebnisse. Ziel Das Ziel des Prozesses ist die Herstellung einer optimalen Balance zwischen technischen Möglichkeiten und ITGeschäftsanforderungen, als auch die Sicherstellung der Zukunftsfähigkeit des IT-Bereiches und damit der gesamten Unternehmung. Aktivitäten Ausgehend von der Business-Strategie wird eine langfristige ITStrategie entwickelt, die ganz auf die Unterstützung der Geschäftsziele abgestimmt ist. Eine Strategie erfordert die Umsetzung in einen Plan, wobei hier zwischen einem kurzfristigen und einem mittelfristigen Plan zu unterscheiden ist. Diesen Plänen muss eine Betrachtung der auf dem Markt vorhandenen technischen Lösungen und der im Unternehmen vorhandenen Infrastruktur zu Grunde liegen, denn nur auf dieser Ausgangsbasis können die notwendigen Veränderungen geplant und umgesetzt werden. Die zu entwickelnden taktischen Pläne beschreiben die ITInitiativen, die Ressourcen und deren Beitrag zum Geschäftserfolg. Sie beantworten die Frage danach, wie dieser Nutzen gemessen und nachgewiesen wird. So gut wie alle anderen Prozesse werden von diesem Prozess direkt oder indirekt beeinflusst, 51

3

COBIT-Prozessbeschreibung da er die Eingangsgrößen für den gesamten IT-Bereich liefert. Die Geschäftsstrategie muss die gesamte IT-Organisation als Leitlinie durchziehen und spürbar bleiben. Business-Strategie

Verbinde Geschäftsziele mit IT-Zielen

Entwerfen taktischen Plan Analysiere Programm Portfolio und manage Projekt und Service Portfolio

Review alle drei Monate

Entwerfen strategischen Plan

Review einmal pro Jahr

AnalysiereAbhängigkeiten / jeztige Performance

Nein

Richtig Ja

Ende

Abb. 3-5 Flowchart - Definieren eines strategischen Plans

Die Einbindung aller Managementebenen zur Unterstützung und Mitarbeit bei der Umsetzung ist ein notwendiger Schritt. Dies schafft die Voraussetzungen für eine erfolgreiche Strategieumsetzung. Die Kommunikation der Strategie und der zugehörigen Pläne schafft ein Bewusstsein für die Ziele bei allen Mitarbeitern. Im Laufe des Prozesses wird der Erfolg der Strategie überprüft und Korrekturen an den Plänen vorgenommen, falls die erwarteten Ziele nicht erreicht werden. Kontrollen Als Kontrollobjekte dienen:

52

¾

Strategischer IT-Plan

¾

Tactical IT-Plan

¾

IT-Projekt Portfolio

¾

IT-Service Portfolio

¾

IT-Sourcing Strategie

3.2 ¾

PO Planung und Organisation

IT-Einkaufsstrategie

Um den Prozess zu überprüfen wird untersucht, ob die Policies und die Prozeduren einem strukturierten Planungsansatz folgen. Es muss eine Methode vorhanden sein, die es erlaubt Pläne zu formulieren und zu verändern. Diese Methoden bzw Pläne umfassen mindestens die folgenden Themen: ¾

Mission und Ziele der Organisation

¾

IT-Initiativen zur Unterstützung der Unternehmensziele

¾

Möglichkeiten und Machbarkeitsstudien für IT-Initiativen

¾

Risikountersuchungen von IT-Initiativen

¾

Investments für jetzige und zukünftige IT Investitionen

¾

Neuausrichtung der IT-Initiativen bei Änderung der Unternehmensziele

¾

Untersuchung alternativer Strategien für Data Applikation, Technologie und Organisation

Es muss daher überprüft werden, ob die mittel- und langfristigen Pläne existieren und ob überprüfbare Ziele in ihnen festgelegt wurden, an Hand derer nachgewiesen werden kann, dass die Pläne auch die Ziele der Organisation nachhaltig unterstützen. Das Überprüfen von Abläufen und Prozessen zur Anpassung kann zum Beispiel durch die Sichtung von Protokollen, geänderten Plänen und Dokumenten zu durchgeführten Prüfungen der Strategieumsetzung erfolgen. Beziehungen zu anderen Prozessen PO5, PO9, PO10 DS1, ME1, ME4, Geschäftsstrategie Programmportfolio

Definieren eines strategischen Plans Strategischer IT Plan Tactical IT-Plan

PO2..PO6, PO8, PO9, AI1, DS1 PO2..PO6, PO9, AI1, DS1

IT-Projekt Portfolio

PO5, PO6, PO10, AI6

IT-Service Portfolio

PO5, PO6, PO9, DS1

IT-Sourcing Strategie

DS2

IT-Einkaufsstrategie

AI5

Abb. 3-6 Beziehungsdiagramm - Definieren eines strategischen Plans

53

3

3.2.2

COBIT-Prozessbeschreibung

PO2 Definieren der Informationsarchitektur Kurzbeschreibung In dem Prozess werden das Datenmodell und die zugehörigen Informationssysteme, die zur Abbildung des Geschäftes notwendig sind, entwickelt. Ein weiterer wichtiger Faktor dieser Aktivitäten ist, dass die dahinter liegenden Prozesse zur Entwicklung und Wartung dieser Informationssysteme behandelt werden müssen. Ziel Optimierung des Zusammenspiels aller eingesetzten Informationssysteme und Daten, um die Geschäftsanforderungen optimal zu unterstützen. Aktivitäten IT Strategie Plan

Informations Architektur Modell Daten Modell

Review alle drei Monate

Sicherheitsstufen Zugriffsregeln, Klassifizierungen Kommuniziere Modelle an Datenverantwortliche Modelle anpassen zur Optimierung der Geschäftsanwendungen Überwachung / Evaluierung

Nein

Richtig Ja

Ende

Abb. 3-7 Flowchart - Definieren der Informationsarchitektur

54

3.2

PO Planung und Organisation

Der Prozess PO1 hat eine IT-Strategie und die taktischen Pläne geliefert, auf deren Grundlage ein Architekturmodell erstellt wird. Die Erstellung eines solchen Modells ist dabei keine einmalige Angelegenheit, sondern muss in regelmäßigen Abständen wiederholt werden, da sich Technologien und damit die Architekturen in einem fortwährenden Wandel begriffen sind. Der nächste Schritt besteht in der Datenmodellierung bzw in der Aufnahme der Daten, die in einer Organisation verwendet werden und auf deren Grundlage die Sicherheitspolicies zum Gebrauch und zur Verwendung dieser Daten aufgebaut wird. Diese Sicherheitspolicies enthalten Klassifizierungsschemata für die Informationsklassen und Eigentümerrechte, Festlegungen zu Zugriffsrechten und eine Anleitung zur Pflege dieser Sicherheitspolicies. Kontrollen Der Prozess selbst wird überprüft, indem nachgewiesen wird, ob die Erstellung der Ergebnisse im Rahmen eines festgelegten Ablaufs erfolgt. Es sollte sichergestellt sein, dass die Ergebnisse regelmäßig auf ihre Validität geprüft werden. Die Kontrollobjekte sind: ¾

Informationsarchitektur Modell

¾

Corporate Datenlexikon und Datensyntaxregeln

¾

Datenklassifizierungsschemata

¾

Integritätsmanagement

Änderungen in den Strategien müssen ihren Niederschlag in den Architekturmodellen finden. Ein möglicher Prüfpunkt für den Prozess stellt daher die Überprüfung des Einflusses von Strategieänderungen auf die Architektur sowie deren Geschwindigkeit dar. Folgende weitere wichtige Prüfpunkte können herangezogen werden: ¾

Kosten und Risiken, die mit Änderungen der ITArchitektur verbunden sind, sind eindeutig identifiziert und berücksichtigt

¾

Verwendete Datenmodelle und Sicherheitspolicies sind angemessen in Bezug auf die Organisation und deren Bedürfnisse, Änderungen werden rechtzeitig und in geeigneter Form kommuniziert

¾

Jede Beschreibung eines Datums enthält mindestens die Informationen:

55

3

COBIT-Prozessbeschreibung o

Zugriffsberechtigte

o

Verantwortlicher für die Zugriffserteilung

o

Spezifische Anforderungen für den Datenzugriff

¾

Architekturmodelle werden mit Modellen anderer Organisationen und/oder mit Best Practice-Modellen verglichen

¾

Die Vollständigkeit des Datenmodells wird überprüft, wie viel Prozent der Daten sind z. B. nicht Bestandteil des Geschäftsdatenmodells

¾

Die gewährten Zugriffe entsprechen den Zugriffsregeln und Sicherheitspolicies.

Vor allem die letzten Punkte können herangezogen werden, um die Risiken abzuschätzen, die in einer fehlenden Befolgung dieses Prozesses liegen. Beziehungen zu anderen Prozessen Strategische und taktische IT Pläne, AI1, AI7, DS3, ME1

Definieren der Informationsarchitektur Klassifikationsschemata

AI2, DS1, DS4, DS5, DS11, DS12

Plan zur Optimierung Geschäftssysteme

PO3, AI2

Daten Lexikon

AI2, DS11

Informationsarchitektur

PO3, DS5

Klassifikationsprozeduren und Tools

extern

Abb. 3-8 Beziehungsdiagramm - Definieren der Informationsarchitektur

Klassifikationsschemata und die Informationsarchitektur sind die wesentlichen Ergebnisse, die an die anderen Prozesse weitergegeben werden. Klassifikationsprozeduren und Tools werden im wesentlichen von den Geschäftsprozessen benutzt und sind damit Ergebnisse, die außerhalb von COBIT zu finden sind.

56

3.2

PO3 Festlegen der technischen Ausrichtung Kurzbeschreibung Ausgehend von der IT-Strategie werden vorhandene und potentielle Technologien im Hinblick auf ihre Verwendbarkeit und Einsatzfähigkeit untersucht und bewertet. Dabei ist das Hauptkriterium für die Bewertung die Einsatzmöglichkeit und der Nutzen für die Unterstützung der Geschäftsprozesse. Der Prozess ist in regelmäßigen Abständen durchzuführen, da die Technologien sich in oft unvorhergesehener Weise und in kürzester Zeit ändern können. Ziel Ausnutzen des Vorteils und der Verfügbarkeit von neuen Technologien zur Unterstützung und Fortentwicklung der Geschäftsstrategie Aktivitäten IT Strategie Plan

Techn. Infrastruktur Plan erstellen/pflegen Technolog. Standards erstellen und anpassen Kommunikation Technologische Ausrichtung/Standards Überwachung / Evaluierung techn. Entwicklungen

Review alle drei Monate

3.2.3

PO Planung und Organisation

Strategie zukünftiger Technologien festlegen Nein

Richtig Ja

Ende

Abb. 3-9 Flowchart - Festlegen der technischen Ausrichtung

57

3

COBIT-Prozessbeschreibung Im Rahmen dieser Aktivitäten werden die folgenden Themen bearbeitet und in Form von Dokumenten abgelegt: ¾

Planung der technologischen Infrastruktur

¾

Aufnahme zukünftiger Trends und Entwicklungen

¾

Abschätzungen der Fähigkeiten der technischen Infrastruktur

¾

Pläne für den Einkauf von Hard- und Software

¾

Technologische Standards

Ausgangspunkt auch dieses Prozesses sind vor allem die Ergebnisse des Prozesses PO1 Definieren eines strategischen Plans. Daneben ist allerdings auch das Datenmodell aus dem Prozess PO2 von großer Bedeutung. Kontrolle Die Kontrollobjekte sind ¾

Planung der technologischen Infrastruktur

¾

Beobachtung zukünftiger Trends und Regularien

¾

Zukunftssicherheit der technischen Infrastruktur

¾

Technologische Standards

¾

Architekturgremium

Zur Bewertung des Prozesses sollten neben den bereits genannten Themen folgende Dokumente und Unterlagen herangezogen werden. ¾

Policies und Prozesse für die Planung der Infrastruktur und deren Überwachung

¾

Die Rollenmodelle des Managements (Überwachungsaufgaben und Verantwortlichkeiten)

¾

Organisationsziele und alle Pläne

¾

Statusberichte der Management Meetings, die sich mITInfrastrukturt Planung beschäftigt haben

Es muss überprüft und sichergestellt werden, ob das ITManagement die Pläne für die technologische Infrastruktur versteht und auch verwendet. Die Änderungen an den Plänen müssen mit den Änderungen der IT-Strategie-Pläne konform gehen und diesen folgen. Die im Prozess enthaltene Überwachung der Einhaltung des Einkaufsplanes und der damit verbundenen Policies ist zwingend, da ansonsten die Einhaltung einer einheitlichen technologischen 58

3.2

PO Planung und Organisation

Ausrichtung nicht sicher gestellt werden kann. Hier kann geprüft werden, zu wie viel Prozent die technologischen Standards eingehalten werden, bzw wie oft davon abgewichen wird. Ein weiterer Aspekt ergibt sich aus der Sicherung der Zukunftsfähigkeit der Infrastruktur. Das Management muss über die Pläne die optimale Nutzung für die Gegenwart und die Zukunft abbilden bzw. dieses sicherstellen. Das dazu einzurichtende Architekturgremium muss regelmäßig tagen und seine Ergebnisse auch festhalten und veröffentlichen. Beziehungen zu anderen Prozessen PO1, PO2, AI3, DS3

Festlegen der technischen Ausrichtung Technologische Möglichkeiten

AI3

Technische Standards

AI1, AI3, AI7, DS5

Regelmäßige Updates

AI1, AI2, AI3

Technologie Infrastrukturplan Infrastruktur Anforderungen

AI3 PO5

Abb. 3-10 Beziehungsdiagramm - Festlegen der technischen Ausrichtung

59

3

3.2.4

COBIT-Prozessbeschreibung

PO4 Definieren der IT-Organisation und ihrer Beziehungen Kurzbeschreibung Der Aufbau einer Organisation ist wesentlich für die Erbringung qualitativ hochwertiger Services. In der Strategie wird die Fertigungstiefe bestimmt und damit auch implizit die Verteilung von Aufgaben an interne Leistungserbringer und an die notwendigen Zulieferer mitbestimmt, was den Aufbau einer Organisation und vor allem der Beziehungen daher wesentlich beeinflusst. Sind die Beziehungen nicht klar geregelt, so ist der Erfolg der ITOrganisation gefährdet. Ziel Die Herstellung einer, für die Lieferung der richtigen und angepassten Services, am besten geeignete IT-Organisation. Aktivitäten IT-Strategie-Plan Information Architektur Technologische Ausrichtung

Festlegen IT-Organisation & Strukturen

Festlegen Personalplan (Daten- / Systemverantwortliche) Implementierung Rollenmodell, Überwachung

Review jedes Jahr

Beschreibung Rollen, Aufgaben, etc

Überwachung / Evaluierung Nein

Richtig Ja

Ende

Abb. 3-11 Flowchart - Definieren der IT-Organisation und ihrer Beziehungen

60

3.2

PO Planung und Organisation

Die IT-Strategie adressiert die Themen Einkauf von Leistungen und damit wie bereits erwähnt die Fertigungstiefe einer Organisation. In der heutigen Zeit besteht der Trend diese zu verringern und Aufgaben an Fremdanbieter zu vergeben (Outsourcing). Für den tatsächlichen Organisationsaufbau ergeben sich daraus bestimmte Erfordernisse, vor allem was die Kenntnisse der beteiligten Mitarbeiter angeht. Diese müssen nun nicht mehr primär technologische Kenntnisse besitzen, sondern vor allem in der Lage sein, Geschäftsanforderungen mit technologischem Wissen und administrativem Fähigkeiten zu verknüpfen. Die Beschreibung einer IT-Organisation sollte die folgenden Elemente umfassen und berücksichtigen: ¾

Strukturierung der IT auf vier Ebenen: IT-Funktionen, ITAbteilungen, IT-Leitung, IT-Steuerungsgremien (ITOrganisationsstruktur)

¾

Beschreiben der Rollen, Aufgaben, Kompetenzen und Verantwortlichkeiten für alle vier Ebenen

¾

Festlegen der Verantwortlichkeiten für physikalische und logische Sicherheit

¾

Festlegen der Strukturen für Verantwortlichkeiten und Verwaltungsaufgaben

¾

Festlegung der Kommunikationsstrukturen

¾

Beschreibung der Aufgabentrennungen und Überwachung

¾

Aufbau der Policies für den Einkauf von Leistungen

Die Verantwortlichkeit für die IT insgesamt muss festgelegt werden, am besten in den Kreis der Unternehmensvorstände gelegt werden. Für diese ist festzulegen, wie sie die Überwachung und Steuerung der IT vornehmen und sicher stellen, dass die IT auf das eigentliche Kerngeschäft des Unternehmens optimal ausgerichtet ist. Bereits bei der Entwicklung der Organisation ist auf diese Ausrichtung auf das Kerngeschäft zu achten. Kontrolle Als Kontrollobjekte können gelten ¾

IT-Planungs- oder Steuerungsgremien o

Strategiegremium

o

Steering-Komitee

61

3

COBIT-Prozessbeschreibung ¾

Organisatorische Einordnung der IT-Funktionen (Organisationsstruktur)

¾

Review der Verbesserungen der Organisation

¾

Rollen und Verantwortlichkeiten

¾

Verantwortlichkeiten für die o

Qualitätsicherung

o

Logische und physikalische Sicherheit

o

Risikomanagement

¾

Überwachungsfunktionen

¾

Trennung der Verantwortungsbereiche und Aufgaben

¾

IT-Stellenbesetzungen

¾

Arbeits- oder Stellenbeschreibungen für das IT Personal

¾

Schlüsselpersonal

¾

Beziehungen

Um die Kontrolle durchzuführen, sind zunächst die Ergebnisse des Prozesses auf ihr Vorhandensein zu prüfen. Aus der Fülle der Kontrollmöglichkeiten seien hier die Wichtigsten genannt.

62

¾

Testen ob die Überwachung der IT wahrgenommen wird und ob abgeleitete Aktionen auch durchgeführt werden.

¾

Überprüfung ob Key Indicators verwendet werden, um die Performance der Organisation zu bewerten, und ob Abweichungen erkannt und Aktionen daraus abgeleitet werden.

¾

Ist das IT-Management sich seiner Rolle und Verantwortung bewusst?

¾

Inwieweit sind die Sicherheitsanforderungen und Sicherheitsbedürfnisse in der Organisation abgebildet und sind diese auch den Mitarbeitern der IT bewusst?

¾

Sind die Mitarbeiter Rekrutierungserfordernisse festgelegt?

¾

Haben alle Daten und Systeme einen Eigentümer oder einen zugeordneten Mitarbeiter, der für den Grad der Kontrolle dieser Daten und Systeme verantwortlich ist?

3.2

PO Planung und Organisation

¾

Die in der Organisation tatsächlich ausgeführten Kontrollaktivitäten müssen mit den Organisationsanforderungen übereinstimmen.

¾

Die Kompetenz des vorhandenen IT-Personals muss den Kriterien für die jeweiligen Positionen genügen.

¾

Die Zufriedenheit der Führungskräfte und der Mitarbeiter mit der Organisation und ihrer Arbeit kann gemessen werden. Die daraus zu ziehenden Schlussfolgerungen können die IT-Organisation nachhaltig verändern.

Beziehungen zu anderen Prozessen PO1, PO7, PO8, PO9, ME1..ME4

Definieren der ITOrganisation und ihrer Beziehungen Regelwerk IT-Prozesse Festgelegte Systemzuständige IT-Organisation und Beziehungen Rollenmodell und Verantwortlichkeiten

ME4 AI7, DS6 PO7 Alle

Abb. 3-12 Beziehungsdiagramm - Definieren der IT-Organisation und ihrer Beziehungen

63

3

3.2.5

COBIT-Prozessbeschreibung

PO5 IT-Investitionsmanagement Kurzbeschreibung IT-Organisationen wandeln sich immer stärker von reinen Costcentern hin zu Profitcentern. Außerdem haben Investments in Technologie oft eine hohe Wirkung, da die eingesetzten Mittel erheblich sind. Doch selbst für Costcenter ist die Planung und Aufstellung eines Budgets unerlässlich, um die Ausgaben detailliert planen zu können, im Griff zu haben und damit eine hohe finanzielle Verlässlichkeit in der Mittelverwendung sicher zu stellen. Dies hilft dem Kerngeschäft, die Kosten für ihre Prozesse mit hoher Genauigkeit zu berechnen und damit den Erfolg der Gesamtunternehmung zu gewährleisten. Ziel Sicherstellung der finanziellen Mittel über Investments in Technologie und der IT-Organisation, sowie allgemein Kontrolle der Ausgaben der IT Aktivitäten IT-Strategie-Plan Information Architektur Technologische Ausrichtung

Programmportfolio

Serviceportfolio

Bugetprozess erstellen und pflegen

Budget aufstellen

Überwachung Budget/ Evaluierung Prozesse Nein

Richtig Ja

Ende

Abb. 3-13 Flowchart - IT-Investitionsmanagement

64

Review alle drei Monate

Projektportfolio

3.2

PO Planung und Organisation

Im Prozess werden vier wesentliche Ergebnisse erarbeitet: ¾

Kosten/ Nutzen-Berichte

¾

Jährliches Budget für den IT-Betrieb

¾

Erneuertes Service Portfolio

¾

Erneuertes Projektportfolio

Budgets des IT-Bereiches werden vom Kerngeschäft erarbeitet und sind damit durch dieses zu genehmigen. Hierin manifestiert sich die einfache Erkenntnis, dass die IT nicht mehr Geld ausgeben kann, als das Business ihr zur Verfügung zu stellen bereit oder in der Lage ist. Es sind daher Alternativen zu betrachten, die einen kostengünstigeren Betrieb ermöglichen. Die Kontrolle der aktuellen Ausgabensituation, sowie die dauernde Bewertung von Kosten / Nutzen der Investitionen und des IT-Betriebes sind Kernelemente des Prozesses. Die mit dem Betrieb der IT-Anlagen einhergehende Total Cost of Ownership, die nicht nur die IT-Budgets enthält, sondern auch die Ausgabenelemente des Business mit betrachtet, ist ebenfalls ein Aspekt, den dieser Prozess zu berücksichtigen hat. Kontrolle Zur Beurteilung der Effektivität dieses Prozesses können die folgenden Kriterien herangezogen werden. ¾

Framework für das Finanzmanagement

¾

Priorisierungsmethoden innerhalb des Budgets

¾

Budgetprozesse

¾

Kostenmanagement

¾

Kosten/Nutzen Management

Eine Prüfung sollte daher neben der Überprüfung, ob die Kriterien überhaupt vorhanden sind, die folgenden Punkte umfassen. ¾

Jährliches IT-Betriebsbudget

¾

Kosten und Nutzen-Überwachung

¾

Kosten und Nutzen-Rechtfertigungen

Der IT-Budgetierungsprozess muss konsistent zum Budgetierungsprozess der Gesamtorganisation sein. Die für die Gesamtorganisation geltenden Policies sind auf die IT-Organisation übertragen und enthalten einen abgestimmten

65

3

COBIT-Prozessbeschreibung und angepassten Genehmigungsprozess für die Investitionsplanung. Die einmalige jährliche Aufstellung ist nicht ausreichend. Es sind Prozesse und Policies einzuführen, die eine Überwachung der aktuellen Kostensituation und -entwicklung erlauben. Trendanalysen sind durchzuführen und diese mit den prognostizierten Kosten in Beziehung zu setzen. Der Prozess muss eine Prüfung enthalten, ob die Kosten, die mit der Erbringung der Services verbunden sind, gerechtfertigt sind. In anderen Worten, ob Aufwand und Ertrag in einem vernünftigen Verhältnis zueinander stehen. Überbordende Kontrollen im Finanzbereich erzeugen selber unangemessen hohe Kosten. Zu geringe Kontrollen schaffen nicht die notwendige Transparenz. Ausgabenkategorien sind daher sorgfältigst an die Bedürfnisse der Organisation anzupassen und zu klassifizieren. Dies gilt in gleichem Maße für die Mittel / Tools (technische Hilfsmittel), die für das Monitoring eingesetzt werden. Die richtige Nutzung dieser Tools ist sicherzustellen, und im Rahmen von Kontrollen ist zu prüfen, ob das auch der Fall ist. Beziehungen zu anderen Prozessen PO1, PO3, PO10, AI1, AI7, DS3, DS6, ME4

IT-Investitionsmanagement Kosten / Nutzen Berichte IT-Budgets Erneuertes Service Portfolio Erneuertes Projekt Portfolio

PO1, AI2, DS6, ME1, ME4 DS6 DS1 PO10

Abb. 3-14 Beziehungsdiagramm - IT-Investitionsmanagement

66

3.2

PO6 Kommunizieren der Management-Ziele und Strategien Kurzbeschreibung Transparenz ist ein hohes Gut, das zu entwickeln und einzusetzen sich vielfach bezahlt macht. Transparenz bedeutet auch die vorhandenen Informationen und vor allem die Strategien und Ziele des Unternehmens, in diesem Fall des IT-Bereiches, in geeigneter Form zu kommunizieren. Auf diese Art wissen die Mitarbeiter woran sie sind und können sich entsprechend einstellen und auch dadurch Blindleistungen verhindern. Ziel Sicherstellung, dass den Mitarbeitern die Managementziele und Strategien bewusst sind und sie diese auch verstehen und umsetzen. Aktivitäten IT-Strategie-Plan Information Architektur Technologische Ausrichtung IT-Organisation

Entwickeln Kontroll Framework und Awareness-Programm Festlegen, Pflegen und Kommunizieren der Policies Planen der Ressourcen und Einführung der Polcies und Ziele

Review jährlich

3.2.6

PO Planung und Organisation

Überwachung / Evaluierung

Nein

Richtig Ja

Ende

Abb. 3-15 Flowchart - Kommunizieren der Management-Ziele und Strategien

67

3

COBIT-Prozessbeschreibung Wesentlicher Faktor ist die Übersetzung der Strategie in die Sprache der Mitarbeiter. Diese werden die Strategie nur dann verstehen und umsetzen, wenn diese in anwendbare, praktikable Anweisungen überführt ist. Vielfach bleiben Strategien auf einer zu abstrakten Ebene und sind dann nicht umsetzbar, werden also auch nicht beachtet und haben damit keinen Effekt. Eine gute Kommunikation ist wichtig und erfordert sorgfältige Arbeit. Die folgenden Themen sind zu beachten: ¾

Es ist ein Framework und ein Awareness-Programm zu erarbeiten, um eine positive Informationsumgebung zu schaffen

¾

Festlegen, Entwickeln, Dokumentieren und Kontrollieren der Policies, in Bezug auf generelle Ziele und Ausrichtung der Kommunikation

¾

Definieren und Auswählen geeigneter Kommunikationsmethoden

¾

Zur Verfügung stellen und Einführung einer Policy zur Wahrung der Rechte an geistigem Eigentum und anderen geschäftlichen Themen

¾

Kommunikation ist ein permanenter, ständig andauernder Prozess, der besonderer Aufmerksamkeit und Pflege bedarf

Von besonderer Bedeutung für die Kommunikation ist es, dass das Management die aufgestellten Regeln auch selber vorlebt. Es muss also eine Kongruenz zwischen erfahrener und kommunizierter Strategie vorhanden sein. Unterbleibt dies, so ist nicht zu erwarten, dass die Mitarbeiter sich an die Regeln und die Strategievorgaben halten. Dies ist unabhängig von jeder offiziellen Kommunikation, so ausgefeilt sie auch sein mag. Kontrolle Die Kontrollobjekte sind

68

¾

Positive Kontrollumgebung für die Informationen

¾

Unternehmens IT-Risiko Framework

¾

Framework zur internen Kontrolle

¾

Policy Management

¾

Policy Rollout

¾

Kommunikation von IT-Zielen und Ausrichtungen

3.2

PO Planung und Organisation

Verantwortlich für die Policies ist immer das Management selber. Es hat die Ressourcen zur Implementierung zur Verfügung zu stellen, die Einhaltung zu überwachen, die Schaffung eines Bewusstseins für Sicherheit und Qualität zu veranlassen und die Vereinbarkeit der entwickelten Policies, Prozeduren und Standards in der Organisation zu gewährleisten. Es ist also primär zu überprüfen, inwieweit das Management seine Aufgabe, ein positives Umfeld zu schaffen, wirklich wahrgenommen hat und ob sich dieses auf alle Schlüsselelemente erstreckt. Folgende Schlüsselelemente sind definiert: ¾

Ethische Werte

¾

Führungsgrundsätze

¾

Sicherheit und interne Kontrollen

¾

Kompetenzen des Personals

¾

Management Philosophie und Stil

¾

Integrität

¾

Verlässlichkeit

¾

Aufmerksamkeit und tatsächliche durch das Management

Richtungsvorgabe

Ebenso ist zu kontrollieren, ob die Wirksamkeit der Kommunikation überprüft wird? Findet also eine Kontrolle statt, ob die Kommunikation auch bei den Mitarbeitern ankommt und welche Wirkungen sie erzielt? Ein letztes wesentliches Merkmal ist der Test, ob die Policies, Standards, Arbeitsanweisungen etc aktuell sind. Ansonsten fehlt schon die Voraussetzung, eine effektive Kommunikation aufzusetzen, und die Ziele können nicht erreicht werden. Beziehungen zu anderen Prozessen PO1, PO9, ME2

Kommunizieren Management-Ziele und Ausrichtungen IT-Kontroll-Framework

Alle

IT-Policies

Alle

Abb. 3-16 Beziehungsdiagramm - Kommunizieren der Management Ziele und Strategien

69

3

3.2.7

COBIT-Prozessbeschreibung

PO7 Personalführungsmanagement Kurzbeschreibung Menschen prägen Organisationen. Die Auswahl und vor allem die Führung der Mitarbeiter ist aus diesem Grunde eine Kernaufgabe eines jeden Bereiches. Hier entscheidet sich oft Erfolg oder Misserfolg, Wachstum oder Stillstand. Effektivität und Effizienz einer Organisation sind die primär durch diesen Prozess beeinflussten Informationskriterien. Ziel Akquirierung und Halten einer kompetenten und motivierten Mitarbeitermannschaft und Maximierung des Beitrages dieser Mannschaft zu den IT-Prozessen. Aktivitäten IT-Strategie-Plan Information Architektur Technologische Ausrichtung IT-Organisation

Festlegen der Personalrichtlinien (HR-Policies)

Definieren, Pflegen und Kommunizieren der HR-Prozeduren

Review jährlich

Festlegen, Pflegen und Kommunizieren des Personalplans

Überwachung / Evaluierung

Nein

Richtig Ja

Ende

Abb. 3-17 Flowchart - Personalführungsmanagement

Voraussetzung für die Erreichung des Zieles ist ein Personalmanagement, das gut geführt, fair und transparent ist und keinen 70

3.2

PO Planung und Organisation

Bereich des Personalmanagements ausspart. Es muss daher die gesamte Kette von Einstellung über Beförderung oder Rückstufung bis zur Entlassung regeln. Die folgende Liste gibt einen Hinweis auf den Umfang der Aufgaben. ¾

Recruitment und Beförderungen

¾

Trainings und Qualifizierungsanforderungen

¾

Jobrotation und Cross-Trainings

¾

Einstellungs, Betreuungs- und Entlassungsprozese

¾

Leistungsmessungen (objektiv und messbar)

¾

Berücksichtigung von Marktänderungen

¾

Ausgleich von internen und externen Ressourcen

¾

Nachfolgepläne für Schlüsselpositionen

¾

Gehaltsgefüge

¾

Benchmarks für Personal Performance

Kontrolle Die Kontrolle erstreckt sich auf die oben genannten Elemente eines Personalmanagementsystems. Insbesondere wird überprüft, ob ¾

Auswahlkriterien objektiv und relevant für die Positionen sind

¾

Das Personal die entsprechenden Fähigkeiten und das notwendige Wissen für die jeweilige Position besitzt, ob es also Personal gibt, das die erforderlichen Fähigkeiten nicht aufweist

¾

Stellenbeschreibungen existieren und auf dem aktuellen Stand sind

¾

Andauerndes Training für die Personen mit kritischen Aufgaben durchgeführt wird

¾

Das IT-Personal in Sicherheitsfragen geschult wurde

¾

IT-Management und Personal die IT-Policies und Prozesse verstehen

¾

Sicherheitspolicies mit gesetzlichen Regelungen konform sind

¾

Das IT-Personal die Geschäftsziele kennt

71

3

COBIT-Prozessbeschreibung ¾

Die Abhängigkeiten der Aufgaben von bestimmten Personen minimiert ist

Die Überprüfung kann sich auch darauf erstrecken, ob die Stakeholder der IT mit den Kenntnissen und Fertigkeiten des ITPersonals zufrieden sind. Das Gleiche gilt für die Zufriedenheit des Personals selber. Hier ist die Fluktuationsrate ein geeigneter Anhaltspunkt. Beziehungen zu anderen Prozessen Personalmanagement PO4, AI1 IT-HR-Policy und Prozesse IT-Skill-Matrix Arbeitsplatzbeschreibungen Anwender Kenntnisse, Kompetenzen, Trainings Spezifische Schulungsanforderungen Rollen / Verantwortlichkeiten

PO4 PO4, PO10 PO4 DS7 DS7 Alle

Abb. 3-18 Beziehungsdiagramm – Personalführungsmanagement

72

3.2

3.2.8

PO Planung und Organisation

PO8 Qualitätsmanagement Kurzbeschreibung Kunden erwarten eine immer höhere Qualität bei gleichzeitiger Kostensenkung. Diesen Zwiespalt aufzulösen, bedarf es eines Qualitätsmanagements, das die gesamte Organisation durchdringt und das an jeder Stelle, von jedem Mitarbeiter in jedem System gespürt wird und auf der anderen Seite kostensensitiv reagiert und ausgerichtet ist. Ziel Managen der Qualität, um die Kundenanforderungen zu erfüllen und die Qualitätskosten zu senken sowie die Kundenzufriedenheit zu steigern. Aktivitäten IT-Strategie-Plan

Definieren Qualitätsmanagement System Implementieren / Pflegen Qualitätsmanagement-System Definieren, Pflegen und Kommunizieren der Qualitätsstandards Qualitätsplan für kontinuierliche Verbesserung erstellen und pflegen Überwachung / Evaluierung Compliance mit Qualitätszielen Nein

Richtig Ja

Ende

Abb. 3-19 Flowchart - Qualitätsmanagement

73

3

COBIT-Prozessbeschreibung Im Rahmen des Qualitätsmanagements sind vielfältige Aufgaben zu erledigen. Ausgehend von der Etablierung einer Qualitätskultur sind die Zielrichtungen und der Umfang des Qualitätsmanagements festzulegen. Qualitätspläne sind zu erstellen und zu kommunizieren, und es ist sicher zu stellen, dass diese auch von allen Mitarbeitern im Unternehmen verstanden und gelebt werden. Das bedeutet, dass das Qualitätsmangement Trainings aufbauen und durchführen muss. Das Qualitätsmanagement durchdringt alle Bereiche der ITOrganisation und hat daher Einfluss auf alle anderen Prozesse. Damit stellt es einen der Schlüsselprozesse dar. Kontrolle Die bei einer Überprüfung dieses Prozesses zu begutachtenden Zielgrößen sind: ¾

Allgemeiner Qualitätsplan

¾

Qualitätssicherungsanspruch

¾

Planung zur Wahrung des Qualitätsanspruchs

¾

Review der Qualitätssicherung in Bezug auf die Einhaltung von IT-Standards und Prozessen

¾

Lifecycle-Methode für die Systementwicklung auch im Rahmen von größeren Änderungen in der Technologie

¾

Fortentwicklungsverfahren für die Lifecycle-Methoden

¾

Koordination und Kommunikation

¾

Einkauf und Maintenance (Wartung) Framework (Richtlinien und Verfahren) für die Technische Infrastruktur

¾

Rahmenbedingungen zum Aufbau von Third Party Beziehungen

¾

Dokumentationsstandards

¾

Test-Standards für Systeme und Programme

¾

Reviews über die Erreichung der IT-Ziele

¾

Qualitätsmetriken

¾

Berichte über die Qualitätssicherungsreviews

Die erste Phase einer Prüfung umfasst zunächst die Kontrolle, ob die genannten Themen adressiert und behandelt werden. Daneben sind inhaltliche Aussagen zu prüfen. So ist bei der Durchsicht des Qualitätsplanes in Bezug auf die PerformanceKriterien zu testen, ob diese auch erreichbar, respektive messbar 74

3.2

PO Planung und Organisation

sind und ob diese auch die Anforderungen bzw die Erwartungen der Organisation und der Anwender widerspiegeln. Eine weitere Methode ist es, eine Auswahl an Projekten zu untersuchen und zu klären ob ¾

Die entwickelte Lifecycle-Methode verwendet wird

¾

Alle Meilensteine auch formal abgenommen wurden

¾

Eine enge Kommunikation zwischen allen Beteiligten gepflegt wird

¾

Die Einkaufs- und Wartungsrichtlinien befolgt werden

¾

Entwicklungen und Änderungen zur Zufriedenheit und in der erwarteten Zeit durchgeführt wurden

¾

Den Umständen angepasste -berichte erstellt wurden

Qualitätsreviews

und

Beziehungen zu anderen Prozessen Qualitätsmanagement PO1, PO10, ME1 Einkaufsstandards Entwicklungsstandards Qualitätsstandards / Messanforderungen Qualitätsverbesserungen

AI1, AI2, AI3, AI5, DS2 PO10, AI1, AI2, AI3, AI7 Alle PO4, AI6

Abb. 3-20 Beziehungsdiagramm - Qualitätsmanagement

75

3

3.2.9

COBIT-Prozessbeschreibung

PO9 Risikomanagement Kurzbeschreibung Risiken sind beim Einsatz von Technologie und Mensch immer vorhanden. Diese können extern sein, wie z.B. Erdbeben, Feuer, etc oder auch intern entstehen. Aus diesen Internen ergeben sich die eigentlichen Risiken, denen eine Unternehmung ausgesetzt ist, auch wenn die Bedrohung durch Terrorismus um vieles spektakulärer ist. Das Eintreten dieser internen Risiken kann dazu führen, dass ein Unternehmen gezwungen ist, seine Geschäftstätigkeiten einzustellen. Es ist daher von besonderem Interesse, diesen Risiken geeignet zu begegnen. Ziel Ermitteln von Risiken zur Management-Unterstützung mit der Absicht, auf Bedrohungen durch die Reduzierung der Komplexität, erhöhter Objektivität und Identifizieren der bedeutendsten Entscheidungsfaktoren zu reagieren. Aktivitäten Risikomanagement wirkt auf alle Informationskriterien und muss alle IT-Ressourcen in Betracht ziehen. Die Organisation ist nur dann in der Lage, die Ziele zu erreichen, wenn Risiko- und Auswirkungsanalysen mit einem interdisziplinären Ansatz bearbeitet werden und kosteneffektive Maßnahmen zur Vermeidung der identifizierten Risiken getroffen werden. Für das Risikomanagement sind dedizierte Verantwortlichkeiten zu schaffen. Diese haben die Aufgabe, für jeden der Bereiche mIT-Risikopotential (Technologie, Sicherheit, Notfall, Personal, etc) die Toleranz zu definieren, innerhalb deren Risiken akzeptiert werden. Diese so entwickelten Policies sind im gesamten Unternehmen zu kommunizieren. Diese Toleranzen dienen dazu, die Kosten in der Vermeidung von Risiken in akzeptablen Grenzen zu halten. Zur Bestimmung solcher Toleranzen ist neben einer Assessmentmethode zur Bestimmung der Risiken eine Bewertungsmethode für die Risiken zu entwickeln. Der dann zu entwickelnde Risikoplan enthält die geeigneten Maßnahmen, die, abhängig von der Bewertung, entweder zur Risikoreduzierung oder zur Vermeidung tauglich sind. In besonderem Maße sind Risiken einem regelmäßigen Review zu unterziehen. Auf Grund der rasanten technologischen Entwicklung und der permanenten Veränderung in den IT-

76

3.2

PO Planung und Organisation

Bereichen (Applikationen, Personal, etc) können sich die Risiken in unvorhersehbarer Weise ändern.

IT-Strategie-Plan Externe Anforderungen

Risiko-Management aufsetzen und Risiken ermitteln Relevante Geschäftsziele und Prozessziele verstehen Interne IT-Ziele und Risikozusammenhang identifizieren Risikoereignisse identifizieren, Geeignete Handlungen auf Risiken ermitteln Finanzielle Grundlagen der Risikopläne sicherstellen Risiko-Management-Plan pflegen Überwachung / Evaluierung

Nein

Richtig Ja

Ende

Abb. 3-21 Flowchart - Risikomanagement

Kontrolle Die Kontrollziele werden in Hinsicht auf die folgenden Bereiche definiert. ¾

Begutachtung der Geschäftsrisiken, Abgleich der IT Risiken mit den Geschäftsrisiken

¾

Risikomanagement-Framework, Zielsetzung der Risikobewertung 77

3

COBIT-Prozessbeschreibung ¾

Bedrohungs- und Schwachstellenanalyse

¾

Risikoidentifizierung

¾

Risikobewertung, Risikomaßnahmeplan, Risikoakzeptanz

¾

Pflege und Überwachung des Risikomanagementplans

¾

Vereinbarung zum Risikomanagement

Insgesamt ist zu testen, ob die erstellten Dokumente stets aktuell sind und der Prozess in regelmäßigen Abständen durchlaufen wird. Die Dokumentation des Risikoassessments muss mit dem im Risikoframework definierten Standard übereinstimmen. Dies dient dazu, eine verlässliche Grundlage zu schaffen, ein einheitliches Vorgehen, das eine hohe Qualität der Ergebnisse gewährleistet. Für jedes Risiko, sei es von hoher oder niedriger Priorität, muss eine Maßnahme definiert sein. Es ist zu prüfen, ob die akzeptierten Risiken durch Versicherungen abgedeckt sind. Die durch Versicherungen abzudeckenden Risiken stammen aus den folgenden Bereichen. ¾

Erdbeben, Feuer, Terrorismus u.ä.

¾

Geschäftsunterbrechungen

¾

Andere Risiken, die nicht durch das IT-Risikomanagement oder die Notfallplanung abgedeckt sind

Beziehungen zu anderen Prozessen PO1, PO10, DS2, DS4, DS5, ME1, ME4

Risikomanagement Risikoassessment

PO1, DS4, DS5, DS12, ME4

Risikobericht

ME4

IT-Risiko-Management

PO6

IT-Risiko-Vermeidung / Verhinderungsplan

PO4, AI6

Abb. 3-22 Beziehungsdiagramm - Risikomanagement

78

3.2

3.2.10

PO Planung und Organisation

PO10 Projektmanagement Kurzbeschreibung Zur Durchführung der IT-Aufgaben und zur Verbesserung der Leistungsfähigkeit der IT werden durch die IT-Organisationen Projekte unterschiedlichster Art und Größe durchgeführt. Nach aktuellen Untersuchungen erreicht die Mehrzahl der ITProjekte allerdings ihre gesteckten Ziele nicht. Entweder stimmt die Qualität, die Kosten oder der zeitliche Rahmen nicht oder die in die Projekte hineinprojizierten Erwartungen werden enttäuscht, indem sie zum Beispiel den erwarteten geschäftlichen Nutzen nicht liefern. Projekte in der IT sind aus diesem Grunde aus sich heraus risikobehaftet. Ein professionell durchgeführtes Projektmanagement kann hier Abhilfe schaffen und die Risiken, die mit der Durchführung von Projekten immer verbunden sind, erheblich senken. Das im PO9 erläuterte Risikomanagement muss sich daher auch auf die Risiken in Projekten erstrecken und prüfen, ob die definierten Standards des Projektmanagement eingehalten werden und ob ein Risikomanagement im Rahmen des Projektmanagements betrieben wird. Ziel Professionelles Managen von Projekten durch Priorisierung und Überwachung, um folgendes zu erreichen: ¾

Projekte werden innerhalb des Budgetrahmens und zeitgerecht geliefert

¾

Verbesserter Rückfluss (earned value) aus den Projekten

¾

Erreichen des ROI der Projekte

79

3

COBIT-Prozessbeschreibung Aktivitäten IT-StrategiePlan, Projekt-Portfolio

Programm / Portfolio-Mgmt Framework für IT-Investitionen IT-Projekt-Management Framework erstellen IT-Projekt-Monitoring, Messung, Mgmt System aufsetzen Projekt-Richtlinien, Pläne, QSMaßnahmen, Budgets, RisikoMgmt in Projekt integrieren Projekt-Stakeholder einbinden Änderungswesen im Projekt aufsetzen

Überwachung / Evaluierung

Nein

Richtig Ja

Ende

Abb. 3-23 Flowchart – Projektmanagement

Die IT-Organisation muss in der Lage sein, aufkommende Projekte als solche zu identifizieren und zu priorisieren. Dabei sind für alle durchzuführenden Projekte angemessene und erprobte Projektmanagementtechniken einzusetzen und auf die Projekte anzupassen. IT-Projekte sollten nur durchgeführt werden, wenn sie einen Business Bezug aufweisen. IT-Projekte um ihrer selbst willen sind zu vermeiden, wiewohl es technologisch begründete Ausnahmen geben kann. Das Business-Management sollte daher als Projektsponsor bei IT-Projekten auftreten. Bei großen IT-Organisationen kommt dem Programm-Management eine besondere Bedeutung zu. Projekte dürfen sich in ihren Abläufen erstens nicht behindern und zweitens sollen Doppelarbeiten vermieden werden. Des Weiteren sind finanzielle und personelle Ressourcen nicht 80

3.2

PO Planung und Organisation

beliebig verfügbar und müssen auf die Projekte entsprechend der Priorisierung verteilt werden. Ein dafür ausgelegtes Programmmanagement, das auch die Einhaltung der Projektmanagementstandards kontrolliert, ist unabdingbar. Kontrolle Die Kontrolle erstreckt sich auf folgende Bereiche ¾

Programm / Projekt-Management-Framework

¾

Stakeholder / Anwenderbeteiligung bei der Projektierung

¾

Projektteammitglieder und Verantwortlichkeiten

¾

Projektdefinitionen

¾

Projektinitialisierung

¾

Projekt-Masterplan

¾

Projekt-Ressourcen-Plan

¾

Projekt-Risiko-Management

¾

Qualitätspläne der Projekte

¾

Projekt-Änderung-Kontrolle

¾

Planung von Abnahmemethoden

¾

Projekt-Performance-Messungen, Berichterstattung, und Überwachung

¾

Projektende (Post Implementation Review Plan)

Die Einhaltung der definierten Standards ist zu kontrollieren und sicher zu stellen, dass diese auch kommuniziert und von allen Beteiligten in allen Projekten, verstanden und befolgt werden. Ohne eine schriftliche Darlegung des Ziels und Zwecks, sowie des Umfangs und des Wirkungsbereichs des angedachten Projekts darf es nicht gestartet werden. Diese Projektdefinition muss mit dem Standard Template konform sein und durch den oder die Projektsponsoren freigegeben werden. Die Zustimmung zur Durchführung eines Projektes erfordert eine Machbarkeitsstudie. Die Abnahmen von Teilergebnissen bedingt die Zustimmung zu bisher durchgeführten und erfolgreich abgeschlossenen Arbeiten. Wie bereits erwähnt, scheitern viele Projekte in der IT. Durch die Einbindung des Projektsponsors aus dem Business wird sicher gestellt, dass das Projekt den Geschäftserwartungen entspricht. Nicht erkannte Risiken bilden die nächstgrößere Quelle von Projektfehlleistungen. Ein professionelles Risikomanagement im 81

3

COBIT-Prozessbeschreibung Rahmen der Projekte kann diese reduzieren, im günstigsten Fall sogar verhindern. Ausreichende Tests, bevor ein Projektergebnis in die Produktion übergeben wird, sind ein Muss. Zu diesen Tests gehören schriftliche Testpläne, Test Reviews und Ergebnisse und die Testabnahmen. Die Einhaltung dieser Kriterien ist zu prüfen um eine hohe Qualität zu liefern, und die Prüfung sollte Teil des umfassenden Qualitätsplanes sein. Neue Funktionen erfordern die Einweisung oder Ausbildung der Mitarbeiter, die diese Funktionen später nutzen. Eine auf die Erfordernisse dieser Anwender angepasste Schulung oder Trainingsmaßnahme ist daher zu planen und durchzuführen. Zur Erzeugung einer selbstlernenden Organisation sind bei Abschluss von Projekten Post Implementation Reviews durchzuführen und zu gewährleisten, dass deren Ergebnisse in neue Projekte einfließen. Diese Post Implementation Reviews finden wir später bei dem Prozess Change Management wieder. Ein Projekt oder vielmehr die Teile davon, welche die Infrastruktur verändern, sind im Grunde nichts anderes als Änderungen und als solche auch zu behandeln. Beziehungen zu anderen Prozessen PO1, PO5, PO7, PO8, AI7

Projektmanagement Projekt Performance Bericht Projekt Risiko Management Plan Projekt Management Richtlinien Detaillierte Projektpläne Erneuertes Projektportfolio

ME1 PO9 AI1...AI7 PO8, AI1...AI7, DS6 PO1, AI5

Abb. 3-24 Beziehungsdiagramm - Projektmanagement

82

3.3

AI Akquisition und Implementierung

3.3

AI Akquisition und Implementierung

3.3.1

AI1 Identifizierung automatisierter Lösungen Kurzbeschreibung Für jeden Zweck gibt es heute eine Vielzahl von Lösungen auf dem Markt. Es gilt also die Bedürfnisse der Anwender, die Anforderungen durch die Informationsarchitektur und die Kosten zur Deckung zu bringen. Automatisierte und standardisierte Lösungen erfordern bei der Anwendung wenig Aufwand und sind somit zu bevorzugen. Ziel Identifizieren automatisierter Lösungen um einen effizienten und effektiven Gebrauch sicher zu stellen zur Zufriedenheit der Anwenderbedürfnisse Aktivitäten Am Anfang dieser Kette steht die Analyse der Anforderungen an eine Lösung, die den Geschäftsprozess unterstützen soll. Diese Anforderungen müssen sowohl in funktionaler Hinsicht als auch im Hinblick auf technische Erfordernisse erstellt werden. Die ITStrategie und die entworfene Informationsarchitektur ist bei der Definition der Anforderungen an diese Lösung zu berücksichtigen. Es sind alternative Handlungsmöglichkeiten aufzuzeigen, vor allem in Bezug auf die Geschäftsprozessrisiken. Dazu ist es notwendig, diese zunächst einmal zu ermitteln. All diese Angaben werden in einer Machbarkeitsstudie gebündelt und nach einer Entscheidung über die Umsetzung die tatsächlich zu realisierende automatisierte Lösung entworfen. Zu berücksichtigen sind hierbei neben der Funktionalität auch die Sicherheitsaspekte einer solchen Lösung. Damit das Management eine korrekte Bewertung durchführen kann und auch die Zustimmung zum geplanten Vorgehen erteilt, ist eine Nutzenbetrachtung erforderlich.

83

3

COBIT-Prozessbeschreibung Geschäfts- & IT Anforderungen, Strateg. und taktische Pläne

Funktionale und techn. Anforderungen des Geschäftes ermitteln Integrität und Gültigkeit der Anforderungen sicherstellen

Machbarkeitsstudie in Bezug auf die Anforderungen erstellen Nutzenanalyse (operational / Geschäft) der vorgeschlagenen Lösungen durchführen

Zyklisch und nach Bedarf

Geschäftsprozessrisiken ermitteln, dokumentieren, analysieren

Genehmigungsprozess entwickeln Genehmigungen für die Lösungen einholen Überwachung / Evaluierung

Nein

Richtig Ja

Ende

Abb. 3-25 Flowchart - Identifizierung automatisierter Lösungen

Kontrolle Die Ausübung der Kontrolle erfolgt durch die Überprüfung des Vorhandenseins folgender Kontrollobjekte und der verbundenen Ziele: ¾

Definition der Anforderungen an die Informationsverarbeitung (funktionale und technische Anforderungen)

¾

Bericht zur Risiko-Analyse

¾

Technische und wirtschaftliche Machbarkeitsstudie

¾

Entscheidung und Zustimmung zu Korrektheit der Anforderungen und zur Machbarkeitsstudie

Neben diesen Kontrollobjekten können weitere Teilaspekte herangezogen werden. Diese sind u.a.: 84

3.3

AI Akquisition und Implementierung

¾

Formulierung von Alternativen

¾

Service-Anforderungen

¾

Sicherheitskontrollen

¾

Einhaltung der definierten Standards

Bei der Durchführung der Kontrollen ist darauf zu achten, dass die Anforderungen der Anwender an das neue oder auch nur modifizierte System klar definiert und schriftlich niedergelegt wurden, bevor irgendeine Entwicklung des Systems begonnen oder ein Einkauf getätigt wurde. Dies sollte sich u.a. in einem Anwender-freundlichen Design der Applikation niederschlagen, die Ergonomie der Anwendungen ist ebenfalls in Betracht zu ziehen und zu prüfen, ob diese Aspekte berücksichtigt wurden. Die Einhaltung kann durch die Zufriedenheit der Anwender mit dem entwickelten System oder auch durch die Einhaltung der vorher definierten Kriterien überprüft werden. Auf der anderen Seite sind auch die funktionalen und operativen Anforderungen an die Lösung bezüglich Leistungsfähigkeit, Sicherheit, Zuverlässigkeit etc zu prüfen. Leistungsfähigkeit bedeutet dabei auch, dass die neue Lösung Schwächen der alten Lösung nicht mehr enthalten sollte. Dies impliziert eine genaue Identifizierung genau dieser Defizite der alten Lösung. Der gesamte Prozess und dessen Durchführung ist regelmäßig zu überprüfen, ob er für die Organisation auch angemessen ist. Vielfach gibt es in einer Organisation einfach nicht genügend Kapazitäten, um den Prozess in allen Facetten durchzuführen. Beziehungen zu anderen Prozessen PO1, PO3, PO8, PO10, AI6, DS1, DS3

Identifizierung automatisierter Lösungen Geschäftsanforderungsund Machbarkeitsstudie

PO2, PO5, PO7, AI2, AI3, AI4, AI5

Abb. 3-26 Beziehungsdiagramm - Identifizierung automatisierter Lösungen

85

3

3.3.2

COBIT-Prozessbeschreibung

AI2 Erwerb und Pflege von Applikationssoftware Kurzbeschreibung Anwenderwünsche können am besten mit selbstentwickelter SW befriedigt werden. Dieser über lange Jahre festgefügte Grundsatz wird langsam aufgeweicht. Es gibt einen Konflikt zwischen den Anforderungen der Anwender und denen an die IT-Leistungen möglichst kostengünstig zu erbringen. Letzteres kann meist nur durch Standardapplikationen erfüllt werden. Es wird also in der Realität Mischformen geben, also Anpassungen von auf dem Markt erhältlichen Applikationen. Ziel Erwerb und Pflege von Applikationssoftware, um automatisierte Funktionen zur Verfügung zustellen, welche die Geschäftsprozesse effektiv unterstützen. Aktivitäten Geschäfts- & IT Anforderungen

High Level Design der Anwendungssoftware Feinkonzeption und Designkontrollmethode Applikationsentwicklungsprozess aufbauen

Kaufen und Anpassen

Entwickeln

Test, Freigabe und Implementierung Überwachung / Evaluierung Nein

Richtig Ja

Ende

Abb. 3-27 Flowchart - Erwerb und Pflege von Applikationssoftware

86

3.3

AI Akquisition und Implementierung

Um automatisierte Funktionen zur Verfügung zu stellen, sind die funktionalen und operativen Anforderungen und eine Phasengetriebene Implementierung mit klaren Liefereinheiten zu definieren. Dazu ist es notwendig, für die Applikationssoftware Policies mindestens in Hinsicht auf die folgenden Aspekte aufzusetzen. ¾

Sicherheitsanforderungen

¾

Applikationskontrolle, zur Sicherstellung von Richtigkeit und Vollständigkeit von Inputs und Outputs

¾

Dokumentationsanforderungen

¾

Abnahmeerklärungen / Verantwortlichkeiten

¾

Testrichtlinien / -standards

Für die Applikationssoftware ist ein Lebenszyklus-Modell (Life Cycle Methodology) entsprechend des System LebenszyklusEntwicklungsmodells aufzusetzen. Dieses muss alle Phasen von der Definition der Applikation, über den Erwerb und die Pflege während des Betriebs bis hin zur Ausphasung des Produktes umfassen. Pläne sind aufzusetzen für die Definition und Pflege der Software und der verbundenen Dokumentation. Diese sind zusammen mit den Kriterien, welche für den Einkauf und die Entwicklung der Applikationen gelten, zu kommunizieren, um Transparenz für das Management und auch die Anwender zu schaffen. Diese Pläne müssen auch das Testen, die Einführung der Software, Anpassungsmaßnahmen sowie Maßnahmen für Verbesserungen enthalten. Kontrolle Für diesen Prozess gelten folgende Kontrollobjekte. ¾ Design-Methoden (High Level und Detailed Design) ¾

Kontrolle der Applikationen und Auditierfähigkeit

¾

Sicherheit und Verfügbarkeiten der Applikationen

¾

Konfiguration und Implementierung von erworbener Applikationssoftware

¾

Größere Änderungen bei existierenden Systemen

¾

Entwicklung von Applikationssoftware

¾

Einhaltung der Software-Qualität

¾

Applikationsanforderungsmanagement

¾

Softwarewartung der Applikationen 87

3

COBIT-Prozessbeschreibung Daneben gibt es viele Details, die bei der Entwicklung der Software und auch der Kontrolle / Einhaltung dieses Prozesses zu berücksichtigen ist. Dies reicht von der Erhebung von Speicheranforderungen und Definitionen, über Programmspezifikationen bis hin zu Anwenderunterlagen und Support-Material. Bei der Begutachtung der genannten Kontrollziele ist insbesondere darauf zu achten, dass die Einbindung der Anwender in den Lebenszyklus einer Applikation hoch ist. Dies kann der Fall sein, wenn Key User in den Prozess (Lebenszyklus und besonders System-Design) eingebunden sind. Ein Muss ist auch die Abnahme der Applikation durch den Anwender vor Übernahme in den operativen Betrieb. Ein mögliches Maß für die Güte der entwickelten Software ist die durchschnittliche Fehlerrate pro Monat. Beziehungen zu anderen Prozessen PO2, PO3, PO5, PO8, PO10, AI1, AI6

Erwerb und Pflege der Anwendungssoftware Spezifikation der Sicherheitskontrollen der Appl.

DS5

Applikations und Paketierungssoftware-Kenntnisse

AI4

Einkaufsentscheidungen

AI5

Geplante SLAs

DS1

Verfügbarkeit, Notfall und Wiederherstellungsszenarien

DS3, DS4

Abb. 3-28 Beziehungsdiagramm - Erwerb und Pflege von Applikationssoftware

88

3.3

3.3.3

AI Akquisition und Implementierung

AI3 Erwerb und Pflege der technischen Infrastruktur Kurzbeschreibung Die Basis für alle durch die IT geleistete Prozessunterstützung ist die technische Infrastruktur, auf der automatisierte Lösungen und Applikationen aufsetzen. Fehler in diesem Bereich haben sofort Auswirkungen auf die gesamte Leistungserbringung und können nur schwer wieder korrigiert werden. Ziel Erwerb und Pflege der technischen Infrastruktur, um eine optimierte Unterstützung für die Geschäftsapplikationen zur Verfügung zu stellen. Aktivitäten Geschäfts- & IT Anforderungen

Definieren der Einkaufsprozesse und Prozeduren Kauf und Test, Verhandeln mit zugelassenen Anbietern Strategie definieren und Wartung für IS festlegen Freigabe und Implementierung, Konfigurieren der IS Überwachung / Evaluierung Nein

Richtig Ja

Ende

Abb. 3-29 Flowchart - Erwerb und Pflege der technischen Infrastruktur

89

3

COBIT-Prozessbeschreibung Wohlüberlegter Einkauf standardisierter Hardware und Software, sowie eine klare Überprüfung der Leistungsfähigkeit dieser Hardware und Software tragen wesentlich zur Erreichung des Zieles einer Kontrolle der technischen Infrastruktur bei. Die Aktivitäten in diesem Prozess sind: ¾

Erstellen von Plänen und Anforderungen für die technische Infrastruktur

¾

Prüfen von neuer Hardware und System Software

¾

Erwerb von neuer Hardware und System Software

¾

Testen neuer Hardware und System Software

¾

Einführung von neuer Hardware und System Software

¾

Aufsetzen von vorbeugender Wartung für die Hardware

¾

Bewerten der technologische Infrastruktur

Dabei ist auf die Kompatibilität sowohl der ArchitekturRichtlinien und Standards als auch der IT-Strategien mit der Technischen Infrastruktur zu achten. Da die vorbeugende Wartung eine Rolle spielt, sind die Operational Level Agreements (das sind technische Vereinbarungen mit den Lieferanten über die Zulieferungen zu einem Service) initial festzulegen. Wegen der Risiken bei Änderungen von Infrastrukturen ist das Change Management ein wesentliches zu berücksichtendes Element. Kontrolle Die Kontrolle erstreckt sich auf folgende Objekte: ¾

Einkaufsplan für die technologische Infrastruktur

¾

Ressourcensicherung und Verfügbarkeit der Infrastruktur

¾

Wartung der Infrastruktur

¾

Geeignete Testumgebung

Der Einkaufsplan muss die Geschäftsanforderungen in funktionaler und technischer Hinsicht erfüllen und in Übereinstimmung mit der strategischen technologischen Ausrichtung sein. Bei der Überprüfung kann dann gemessen werden, wie hoch der Anteil der Infrastrukturkomponenten oder Plattformen ist, die nicht den vorher definierten Bedingungen entsprechen. Ein weiterer Punkt ist die Untersuchung, ob es kritische Geschäftsprozesse gibt, die durch nicht mehr verfügbare Infrastruktur (Main90

3.3

AI Akquisition und Implementierung

tenance nicht mehr möglich, Nachkauf schwierig oder unmöglich) unterstützt werden. Ganz allgemein gilt es sicher zu stellen, dass die eingesetzte Infrastruktur weiterhin gewartet und unterhalten werden kann. Weiterhin ist bei der Überprüfung des Prozesses zu ermitteln, ob detaillierte Pläne für die Begutachtung der IS vorliegen und ob diese Pläne auch die Auswirkungen auf die Leistungsfähigkeit der restlichen Infrastruktur ins Kalkül ziehen. Es ist ein formalisierter Sub-Prozess zur Überprüfung der Performance nötig. Die Wartungsaktivitäten dürfen die Geschäftsprozesse nicht mehr als nötig stören. Es ist daher zu prüfen, ob dieser Faktor bei der Aufstellung der Pläne für die Wartung berücksichtigt wurde. Sinngemäß gilt das auch für die Aktivitäten des IT-Betriebes. Änderungen an der technischen Infrastruktur unterliegen dem Change-Prozess. Es müssen daher alle Ergebnisse des ChangeProzesses bei Änderungen der technischen Infrastruktur vorliegen. Das Fehlen der Unterlagen deutet auf einen unzureichend und Risiko-behafteten Prozess hin. Beziehungen zu anderen Prozessen PO3, PO8, PO10, AI1, AI6, DS3

Erwerb und Pflege der technischen Infrastruktur Einkaufsentscheidungen

AI5

Systeme für das Testen und die Installation

AI7

Anforderungen an die physikalische Umgebung

DS12

Updates für technologische Standards

PO3

Anforderungen an das System Monitoring

DS3

Infratruktur-Kenntnisse

AI4

Initial geplante OLAs

DS1

Abb. 3-30 Beziehungsdiagramm - Erwerb und Pflege der technischen Infrastruktur

91

3

3.3.4

COBIT-Prozessbeschreibung

AI4 Befähigen des Betriebes Kurzbeschreibung Ohne die Fähigkeit des Betriebes, auf der einen Seite die eingesetzte Informationstechnologie in geeigneter Weise zu benutzen und auf der anderen Seite diese auch zu betreiben, ist die IT ohne echten Mehrwert. Der Gebrauch der IT scheitert nicht an den Möglichkeiten, welche die Software bietet, sondern oftmals an unzureichend zur Verfügung gestellten Manualen, Gebrauchsanweisungen, exakten Hinweisen zu Hintergründen (warum ist etwas so und nicht anders) und Tipps und Tricks in der Anwendung der Software. Ziel Entwicklung und Pflege von Anwender- und Betriebshandbüchern sowie Schulungen zum Wissenstransfer, um einen ordnungsgemäßen Gebrauch der Applikationen und der Technologie zu gewährleisten. Aktivitäten Geschäfts- & IT Anforderungen

Entwicklung der Betriebsstrategie Entwicklung, der Methoden zum Wissenstransfer Anwendermanuale (Prozeduren) erstellen Technische Support-Dokumentation für Betrieb erstellen Entwicklung der Schulungsmaterialien, Schulungen Überwachung / Evaluierung

Nein

Richtig Ja

Ende

Abb. 3-31 Flowchart – Befähigen des Betriebes

92

3.3

AI Akquisition und Implementierung

Um Anwendungen oder überhaupt die IT verwendungsfähig zu machen sind, Anwender-Manuale, Betriebshandbücher und Schulungsunterlagen in einem strukturierten Prozess zu entwickeln. Dieser muss die Geschäftsprozesse ausreichend berücksichtigen, und nach der Fertigstellung der Unterlagen sind diese einem definierten Änderungsprozess zu unterwerfen. Dieser Änderungsprozess muss von einer stetigen Qualitätsverbesserung der Unterlagen und Schulungen angestoßen werden. Kontrolle Zur Überprüfung des Prozesses werden die vier Themen ¾

Betriebsanforderungen und Servicelevel

¾

Wissenstransfer zum Business Management

¾

Wissenstransfer zu den Endanwendern

¾

Wissenstransfer in den Betrieb der IT

herangezogen. Auf der obersten Kontrollebene ist zu überprüfen, inwieweit die IT-Prozeduren sich in die Geschäftsprozesse nahtlos einfügen. Es gilt dabei zu überprüfen, ob die Erwartungen der Anwender und des Betriebes schriftlich fixiert sind und ob die Leistungsfähigkeit des Betriebes ausreichend gemessen wird. Messung ist nur der erste Schritt. Anwender und Betriebspersonal müssen die Leistungsanforderungen kennen, um sich darauf einstellen zu können. Diese Kenntnisse sind auch notwendig, um korrigierende Maßnahmen überhaupt definieren und umsetzen zu können. Trainings in welcher Form auch immer ermöglichen erst einen Wissenstransfer. Die Wirksamkeit der eingesetzten Schulungsmittel und Verfahren kann indirekt durch die Anzahl der Incidents mit Schulungshintergrund ermittelt werden, die am Servicedesk eingehen. Für alle eingesetzte Software und Hardware sind Betriebshandbücher und wo notwendig Anwendermanuale bereit zu halten und auch den Personen zugänglich zu machen, die diese benötigen. Ein Prüfpunkt stellt also die Verfügbarkeit der Benutzerhandbücher pro Applikation oder System dar. Anwenderhandbücher sollten dabei mindestens folgende Inhalte abdecken: ¾

Systemübersicht

¾

Darstellung der Programme mit Eingaben und Ausgaben, sowie die Zusammenhänge mit anderen Systemen 93

3

COBIT-Prozessbeschreibung ¾

Erläuterung des Anwenderinterfaces (Bildschirmmasken)

¾

Fehlerinformationen mit Erläuterungen

¾

Verhalten im Fehlerfalle

Die Betriebshandbücher auf der anderen Seite sollten mindestens folgende Themen abdecken: ¾

Systembeschreibungen, Namen, Abläufe, etc

¾

Auflistung aller Dateinamen, ihrer Verwendung und Formate

¾

Einsatzplanung, wann wird was verwendet

¾

Bedienungskommandos und Erläuterungen von Parameter für den Operator

¾

Fehlermeldungen und Erläuterungen

¾

Backup, Neustart, Wiederherstellungsabläufe bei verschiedensten Abbrüchen

¾

Spezielle Berichte zur Applikation

¾

Fehlerkorrigierende Maßnahmen

Als letztes kann geprüft werden, ob die Manuale auch aktuell sind. Beziehungen zu anderen Prozessen PO10, AI1, AI2, AI3, AI7, DS7

Befähigen des Betriebes Manuale für Anwender, Betrieb, Administration

AI7, DS4, DS8, S9, DS11, DS13

Anforderungen an den Wissenstransfer

DS7

Schulungsunterlagen

DS7

Abb. 3-32 Beziehungsdiagramm – Befähigen des Betriebes

94

3.3

3.3.5

AI Akquisition und Implementierung

AI5 Zur Verfügung stellen von IT-Ressourcen Kurzbeschreibung Mögliche IT-Ressourcen sind u.a. Mitarbeiter, Hardware, Software, Einrichtungen. Diese müssen kosteneffektiv und effizient unter Berücksichtigung der vertraglichen Bedingungen zur Verfügung gestellt werden. Dazu sind Einkaufsrichtlinien, Lieferantenauswahl und die Durchführung des Einkaufs selber notwendig. Ziel Diejenigen Ressourcen für den IT-Betrieb kosteneffektiv zur Verfügung zu stellen, die am besten die Profitabilität des Geschäftes unterstützen unter Reduzierung der Einkaufsrisiken. Aktivitäten Geschäfts- & IT Anforderungen

Entwicklung / Pflege Einkaufsrichtlinien und Prozeduren Erstellen / Pflegen einer Liste von zugelassenen Lieferanten Lieferantenauswahl durchführen Verträge schließen Einkaufen entsprechend der eingeführten Richtlinien Überwachung / Evaluierung

Nein

Richtig Ja

Ende

Abb. 3- 33 Flowchart – Zur Verfügung stellen von IT-Ressourcen

95

3

COBIT-Prozessbeschreibung Ausgangspunkt ist die Gesamtstrategie des IT-Bereiches in Bezug auf die Fertigungstiefe sowie die Einkaufsstandards und Richtlinien. Diese Einkaufsrichtlinien und Prozesse sind als erstes aufzusetzen und in Einklang mit den Einkaufsrichtlinien des Gesamtunternehmens zu bringen. Lieferanten sind mit Hilfe eines formalisierten RFP (Request for Proposal)-Prozesses zu akkreditieren, das heißt zuzulassen. Dies gilt für alle Arten des Einkaufs und von Lieferungen. Besonderes Augenmerk ist auf die Risikoverminderung zu legen. Die Anzahl der Dispute über Lieferungen von Leistungen der vertragliche Vereinbarungen gibt einen Hinweis auf die Effektivität des Prozesses, die Reduzierung von Kosten durch Fremdvergabe kann als Maß für die Effizienz dienen. Für alle Zulieferungen sind Verträge zu schließen, um die Interessen des Unternehmens zu wahren und die Qualität der Zulieferungen bewerten zu können. Kontrolle Aus dem Ablauf ergeben sich die Kontrollziele und Objekte: ¾

Kontrolle der Zulieferungen

¾

Lieferanten-Management

¾

Lieferantenauswahl

¾

Softwareeinkauf

¾

Einkauf von Entwicklungsressourcen

¾

Einkauf von Infrastruktur, Einrichtungen und damit verbundenen Services

Zulieferungen sind in Hinblick auf die Einhaltung der Richtlinien zu überprüfen. Dies bedeutet die Prüfung auf Vergabe von Aufträgen an nicht gelistete Lieferanten, Aktualität der Lieferantenliste, wie viele Zulieferungen wurden in der erforderlichen Zeit geleistet usw. Auch intern sind Verbesserungen anzustoßen. So kann überprüft werden, ob die RFPs den Anforderungen genügen oder ob diese nach Rückgabe durch die Lieferanten wieder angepasst und verändert werden müssen. Wesentliches Merkmal einer reduzierten Fertigungstiefe und damit eines vermehrten Einkaufs von IT-Leistungen ist der Wunsch Kosten zu reduzieren. Wie ausgeführt, ist also das Maß der Kostenreduzierung ein geeignetes Kriterium. Dies kann allerdings nicht alleine stehen, da Herausgabe von Leistungen immer mit Risiken verbunden ist. Wesentliches Ziel und damit auch der 96

3.3

AI Akquisition und Implementierung

Kontrolle zu unterlegen ist daher die Verminderung der Einkaufsrisiken. Diese bestehen in der Leistungsfähigkeit eines Lieferanten auf der einen Seite und auf der anderen in der Verfügbarkeit (Wie solvent ist der Lieferant?, Steht er für den Zeitraum der Leistung wirklich zur Verfügung?). Für alle Einkäufe und Verträge sind die Interessen der Organisation sicher zu stellen. Ein Kriterienkatalog ist zu entwickeln, der eine Bewertung dieser Einhaltung in objektiver Art und Weise gestattet. Die Interessen erstrecken sich auf den Schutz geistigen Eigentums ebenso wie auf Einhaltung gesetzlicher Regelungen oder auch der eingegangen vertraglichen Verpflichtungen mit anderen Partnern. Beziehungen zu anderen Prozessen PO10, AI1, AI2, AI3, AI7, DS7

Abb. 3-34

Zur Verfügung stellen von IT-Ressourcen Anforderungen an das Lieferanten-Management

DS2

Einkaufsliste

AI7

Vertragliche Vereinbarungen

DS2

Beziehungsdiagramm – Zur Verfügung stellen von ITRessourcen

97

3

3.3.6

COBIT-Prozessbeschreibung

AI6 Change Management Kurzbeschreibung In jeder IT-Organisation, in jedem Geschäftsbereich, treten Änderungen auf. Diese dürfen auf keinen Fall zu Störungen oder Beeinträchtigungen der Geschäftsabläufe führen. Die möglichst effektive und effiziente Behandlung und Durchführung solcher Änderungen muss geregelt werden. Ziel Managen von Änderungen, um die Wahrscheinlichkeit von Serviceunterbrechungen, unautorisierten Arbeiten und Störungen zu minimieren. Aktivitäten Änderungsprozess entwickeln und einführen Bewerten und Priorisieren der Änderungen

Änderungsanforderung

Dringende und kritische Änderungen Prozesskonform abwickeln Auswirkungsanalyse Abgelehnter oder neuer RFC

Nein

Akzeptieren / Freigabe? Ja

Changedurchführung • Planen, Ressourcen • Koordinieren • Freigeben • Überwachung, Bewertung

Nein

In Ordnung? Ja

Ende

Abb. 3-35 Flowchart - Change Management

98

3.3

AI Akquisition und Implementierung

Der Prozess bezieht sich auf alle relevanten IT-Assets. Diese sind in den Policies zum Change Management festgelegt und beschreiben dadurch den Umfang des Change Managements. Change Management hält die IT-Umgebung in einem kontrollierten Zustand. Es wird abgeprüft, ob die angeforderten Änderungen in die IT-Strategie passen und ob sie kompatibel mit der aufgesetzten Architektur sind. Dem Change Management allein obliegt die Planung, Koordinierung und Kontrolle der Änderungen und ihrer Dokumentation. Dazu setzt es Methoden ein, die eine Priorisierung der Anforderungen ermöglichen. In dringenden und eiligen Fällen stellt es Abläufe zur Verfügung, um, unter Wahrung größtmöglicher Sicherheit für den Betrieb, Änderungen schnell in die Umgebung einzubringen. Change Management ist nicht nur ein formalisierter Prozess für den IT-Betrieb, sondern erstreckt sich auch auf den Anwender und auf das Entwicklungspersonal. Es umfasst somit die ganze IT-Organisation und reflektiert damit die Unteilbarkeit des Prozesses. Kontrolle Kontrolle über diesen Prozess wird durch die Begutachtung der folgenden Themen ausgeübt: ¾

Änderungsstandards und Prozesse

¾

Auswirkungsanalyse, Priorisierung und Genehmigung

¾

Dringende Änderungen (Emergency Changes)

¾

Änderungsverfolgung und Berichterstattung

¾

Abschluss von Änderungen und Dokumentation

Um das Vorhandensein eines formalisierten Changeprozesses zu prüfen, sollten eine Auswahl von durchgeführten Änderungen begutachtet werden. Die formale Zustimmung des Managements zu einer Reihe von Punkten ist notwendig und kann geprüft werden. ¾

Änderungsverlangen liegt vor und ist genehmigt

¾

Änderung ist genau spezifiziert

¾

Programmierauftrag erteilt

¾

Anforderung die Tests zu starten liegt vor

¾

Abschluss der Akzeptanztests

¾

Anforderung auf Übergabe in die Produktion vorhanden 99

3

COBIT-Prozessbeschreibung ¾

Sicherheitsaspekte wurden berücksichtigt und akzeptiert

¾

Verteilungsprozess ist entwickelt und vorhanden

Zur Wahrung der Transparenz ist jeder Schritt des Prozesses zu dokumentieren. Das Änderungslogbuch enthält alle durchgeführten Änderungen. Ein Check auf Vollständigkeit ist ein Indikator auf die Ernsthaftigkeit, mit der der Prozess in der Organisation betrieben wird. Zusätzlich sollten aus diesen Untersuchungen mindestens die folgenden Parameter abgeleitet werden: ¾

Prozentsatz der tatsächlich aufgezeichneten / kontrollierten Änderungen zur Gesamtzahl

¾

Verhältnis von abgelehnten zu genehmigten Änderungen

¾

Prozentsatz der dringenden Änderungen

¾

Fehleraufkommen nach Änderungen

¾

Rückgang der Anzahl von Änderungen

¾

Rückgang der Kosten von Änderungen

Diese lassen Rückschlüsse auf die Güte des Prozesses selber zu und sind Eingangsgrößen in die permanente Verbesserung des Änderungsprozesses. Beziehungen zu anderen Prozessen PO1, PO8 PO9, PO10, DS3, DS5, DS8, DS9, DS10

Change Management Change Management Prozess-Beschreibung Änderungsberichte Änderungsgenehmigungen

AI1, AI2, AI3 ME1 AI7, DS8, DS10

Abb. 3-36 Beziehungsdiagramm - Change Management

100

3.3

3.3.7

AI Akquisition und Implementierung

AI7 Installieren und Abnehmen von Systemen und Änderungen Kurzbeschreibung Nachdem neue Systeme oder Änderungen entwickelt wurden, müssen diese in den Betrieb überführt werden. Dazu sind Tests, Releaseplanungen und Implementierungen notwendig, die von einem Post Implementation Review abgeschlossen werden. Dies soll sicher stellen, dass die neuen Systeme auch den Anforderungen und Erwartungen des Betriebes und der Anwender genügen. Ziel Neue oder geänderte Systeme arbeiten nach der Einführung einwandfrei und ohne Probleme. Aktivitäten Autorisierte Änderung

Aufsetzen und Review der Einführungspläne Entwickeln und Review der Teststrategie Testrepository und Testszenarienentwicklung Migrations- und Integrationstests Abnahmetests durchführen Empfehlung zur Einführung Überwachung / Evaluierung Nein

Richtig Ja

Ende

Abb. 3-37 Flowchart - Installieren und Abnehmen von Systemen und Änderungen

101

3

COBIT-Prozessbeschreibung Nach der Genehmigung einer Änderung wird diese eingekauft, entwickelt und in einer Laborumgebung getestet. Um den Einsatz der so erzeugten neuen oder geänderten Systeme in die Produktion ohne Fehler und größere Probleme zu gewährleisten, ist ein Test der Applikationen und Infrastrukturlösungen durchzuführen. Dies stellt sicher, dass diese Systeme frei von Fehlern und für die Produktion auch tatsächlich geeignet sind. Dieser Prozess bezieht sich allerdings nicht nur auf die Freigabe und Produktionsübernahme der so getesteten Systeme, sondern bezieht auch die Anwender ein, indem in seinem Rahmen auch die Schulungen der Anwender durchgeführt werden. Die Durchführung von Integrations- und Abnahmetests erfordert die Entwicklung einer Teststrategie oder auch Methode, welche die Belange der verschiedenen Interessengruppen berücksichtigt. Die auf dieser Grundlage aufzubauenden Testszenarien und vor allem ihrer Ergebnisse bedürfen der Abnahme durch das Management und unter Umständen auch der mit den Systemen später arbeitenden Mitarbeiter. Der Prozess wird formal beschlossen durch das PIR (Post Implementation Review). Bei der Durchführung dieses Reviews wird eine Empfehlung für den Einsatz der geänderten Systeme abgegeben. In dieses PIR sind alle Stakeholder (Interessengruppen) einzubeziehen, um das Risiko des Einsatzes eines nicht geeigneten Systems zu reduzieren. In diesem Review wird auch der Nutzen der eingesetzten Systeme begutachtet. Kontrolle Kontrolle über diesen Prozess wird durch die Begutachtung der folgenden Themen ausgeübt:

102

¾

Training

¾

Testpläne

¾

Einführungspläne

¾

Testumgebungen

¾

System und Datenkonvertierungen

¾

Änderungstests

¾

Abschlusstests

¾

Empfehlungen zum Produktionseinsatz

¾

Software Release

3.3

AI Akquisition und Implementierung

¾

Aufzeichnen und Überwachen von Änderungen

¾

Post Implementation Review (PIR)

Jegliche Einführung bedarf einer formalen Zustimmung des Managements. Diese wiederum muss auf einer abgegebenen Empfehlung des PIR beruhen. Für die Einhaltung des Prozess kann daher überprüft werden, in wie viel Fällen die formale Zustimmung nicht erteilt wurde, die Implementierung aber trotzdem stattfand. Weitere wichtige Prüfpunkte sind ¾

Incidents mit Trainingshintergrund

¾

Störungen an Systemen auf Grund unzureichender Tests

¾

Nacharbeiten nach der Implementierung

¾

Zufriedenheit der Interessengruppen mit der Implementierung

¾

Prozentsatz der Systeme, die den Erwartungen auch entsprechen

Beziehungen zu anderen Prozessen PO3, PO4, PO8, PO10, AI3, AI4, AI5,, AI6

Installieren und Abnehmen von Systemen und Änderungen Freigegebene Konfigurationen

DS8, DS9

Bekannte und akzeptierte Fehler

AI4

Freigabe zur Produktion

DS13

Software Release und Verteilungsplan

DS13

Post Implementation Review

PO2, PO5, PO10

Abb. 3-38 Beziehungsdiagramm – Installieren und Abnehmen von Systemen und Änderungen

103

3

COBIT-Prozessbeschreibung

3.4

DS Delivery und Support

3.4.1

DS1 Service Level Management Kurzbeschreibung Im komplexen Beziehungsgeflecht zwischen Kunden, ITOrganisation und Zulieferern sind Verträge zu schließen, ist zu moderieren und Vertrauen aufzubauen. Ohne das Management dieses Beziehungsgeflechtes gibt es für die IT-Organisation keine Möglichkeit, Einfluss auf die verschiedenen Interessenlagen zu nehmen oder sich entsprechend den Erwartungen der Kunden zu verhalten oder sich daran auszurichten. Ziel Erstellen und Managen von Service Levels, um ein gemeinsames Verständnis für den geforderten Service zwischen allen Beteiligten zu erlangen und die IT an der Geschäftsstrategie auszurichten. Aktivitäten Geschäftsanforderungen

Framework für die Definition von IT-Services entwerfen IT-Servicekatalog erstellen / erneuern SLAs entwerfen, verhandeln, abschließen OLAs entwerfen, verhandeln, abschließen End to End-Überwachung der Service Level Performance Review SLAs, OLAs, UCs

Review des Servicekatalogs Service Improvement Plan erzeugen und durchführen Nein

Prozess in Ordnung? Ja

Ende

Abb. 3-39 Flowchart - Service Level Management

104

3.4

DS Delivery und Support

Ausgangspunkt aller Aktivitäten im Service Level Management ist der Bedarf des Kunden, der ermittelt werden muss. Dieser Bedarf wird in formalisierte Service Level überführt. Diese Service Level stellen die Leistungskriterien dar, an Hand derer die Qualität und die Quantität der Services gemessen wird. An diesen hat sich die IT-Organisation auszurichten. Sind die Service Level definiert, so kann in die Verhandlungen eingetreten werden. Hierbei kann es aber vorkommen, dass sich neue Erkenntnisse zu Anforderungen ergeben, die dann wieder in neue Definitionen von Service Level münden. Die Kundenvereinbarungen müssen durch Verträge mit den Leistungserbringern (intern und extern) abgesichert werden. Bei Verträgen mit externen Anbietern spricht man hierbei von „underpinning contracts“. Diese werden durch den Prozess DS2 behandelt. Auf allen Ebenen sind diese Verträge zu kontrollieren. Dazu werden die vereinbarten Service Level regelmäßig berichtet, mit der Wirklichkeit verglichen und Maßnahmen getroffen, um eine Verbesserung der Einhaltung der Qualität zu erwirken. Diese Maßnahmen werden in die Service Improvement-Programme aufgenommen und mit allen Ebenen von Dienstleistern diskutiert. Alle diese Aktivitäten müssen im Rahmen eines definierten Service Level Management Frameworks ablaufen. Dieses Framework wird ebenfalls im Laufe dieses Prozesses erstellt und seine Einhaltung kontrolliert. Kontrolle Die für eine Kontrolle des Prozesses heranzuziehenden Themen sind: ¾

Rahmenwerk zu Service Level Management

¾

Servicedefinitionen

¾

Service Level Agreements

¾

Operating Level Agreements

¾

Überwachung und Berichterstattung zu Service Improvement-Programmen

¾

Review der Service Level Agreements und Verträge

Das Service Level Management Framework ist der Rahmen, in dem sich das Service Level Management bewegt, und stellt si105

3

COBIT-Prozessbeschreibung cher, dass durch einen formalisierten Prozess die IT auf die Geschäftsstrategie ausgerichtet ist und ein gutes Verständnis zwischen Kunden und IT hergestellt werden kann. Die in diesem Rahmenwerk definierten Prozesse sollen mindestens folgende Teilprozesse enthalten: ¾

Erzeugung Service Requirements

¾

Erzeugung Service Definitionen

¾

Service Level Agreements

¾

Operating Level Agreement und leistende Ressourcen

Der Servicekatalog ist die Zusammenstellung aller Elemente eines Services, d.h. Definition des Services, mögliche Servicelevel, Zulieferer zum Service und deren mögliche Leistungsindikatoren. Rollen, Aufgaben und Verantwortlichkeiten zwischen Kunde, ITOrganisation und Drittanbietern sind im Framework klar geregelt. Aus diesem Framework ergeben sich mögliche Kontrollpunkte, wie formalisierte Prüfungen auf das Vorhandensein der dem Framework zu Grunde liegenden Dokumente, also z.B. der Struktur des Servicekatalogs. Für alle Services sollen, für die kritischen Services müssen SLAs abgeschlossen werden. Diese enthalten die Zustimmung des Kunden, die Anforderungen and den Service, messbare Qualitätsmerkmale für den Service, kaufmännische Vereinbarungen sowie Rollen und Verantwortlichkeiten. Die Qualitätsmerkmale umfassen so unterschiedliche Punkte wie Verfügbarkeit, Leistungsfähigkeit, Kapazitäten bis hin zu Notfallplanungsmaßnahmen und Sicherheit. Es muss die Konformität der abgeschlossenen SLAs mit dem Framework geprüft werden. Um die Services abzusichern, sind OLAs abzuschließen. Diese sind vom Prinzip her SLAs, aber mit mehr technischem Hintergrund. Sie können zur Abdeckung nicht nur eines Services, sondern vieler Services genutzt werden. Es ist nachzuweisen, dass kein Service erbracht wird, der nicht durch entsprechende Vereinbarungen abgesichert ist. Zur Überprüfung der Einhaltung des Prozesses kann man eine Auswahl von Service Level Agreements heranziehen. Deren Inhalte sollten mindestens die folgenden Punkte abdecken:

106

¾

Definition des Service

¾

Kosten des Service

¾

Messbare Minimale Service Level

3.4

DS Delivery und Support

¾

Unterstützungsleistung durch die IT-Funktionen

¾

Verfügbarkeit, Zuverlässigkeit, Kapazität für Wachstum

¾

Notfallvorsorge

¾

Sicherheitsanforderungen

¾

Änderungsverfahren für den Vertrag

¾

Laufzeit, Laufzeitverlängerungen

¾

Inhalt und Häufigkeit der Berichterstattung und der Bezahlung

¾

Kalkulation nach Verrechnungsgrößen

¾

Service Improvement-Vereinbarung

¾

Formale Zustimmung zum Vertrag (Unterschriften)

Ein weiteres wichtiges Kennzeichen für die Wirksamkeit des Prozesses ist die Kundenzufriedenheit. Wird diese über die Zeit gemessen, so ergibt sich ein wichtiger Indikator. Die Überprüfung der Einhaltung der vereinbarten ServiceVerbesserungen und die dauernde Einhaltung der Überprüfung der Reviews der SLAs und OLAs ergeben ein umfassendes Bild. Beziehungen zu anderen Prozessen PO1, PO2, PO5, AI2, AI3, DS4, ME1

Service Level Management Bericht über das Vertragsreview

DS2

Prozess-PerformanceBericht

ME1

Neue/erneuerte ServiceAnforderungen

PO1

SLAs

AI1, DS2, DS3, DS4, DS6, DS8, DS13

OLAs

DS4..DS8, DS11, DS13

Erneuertes Service-Portfolio

PO1

Abb. 3-40 Beziehungsdiagramm - Service Level Management

107

3

3.4.2

COBIT-Prozessbeschreibung

DS2 Lieferanten-Management (Third Party Services) Kurzbeschreibung Dieser Prozess stellt eine wesentliche Zulieferung zum vorhergehenden Prozess Service Level Management. Lieferanten werden in der Serviceerbringung immer wichtiger und müssen daher auch entsprechend berücksichtigt werden. Qualität entscheidet sich über die gesamte Prozesskette hinweg, und die Lieferanten stellen einen wesentlichen Teil dieser Kette dar. Risiken, die mit einer Zulieferung immer verbunden sind, müssen reduziert werden. Ziel Managen von Lieferanten und deren Zulieferungen, um zu gewährleisten, dass Rollen und Verantwortlichkeiten klar festgelegt sind, eingehalten werden und die Anforderungen auch in Zukunft erfüllen. Aktivitäten

Bedarf identifizieren

Anbieterbezieungen identifizieren und kategorisieren

SLA definieren

Lieferanten-Mgmt-Prozess festlegen und dokumentieren Policies / Prozesse für Lieferantenauswahl aufstellen Risikomanagement in Bezug auf Lieferanten durchführen Verträge verhandeln, abschließen, überwachen Nein

In Ordnung? Ja

Ende

Abb. 3-41 Flowchart – Lieferanten-Management (Third Party Services)

Ähnlich wie im Service Level Management-Prozess geht es auch hier um das Management der Qualität, allerdings bezogen auf 108

3.4

DS Delivery und Support

die Zulieferungen von Dritten zu einem gegebenen Service. Die Anforderungen an den Lieferanten ergeben sich daher aus den definierten Services und den Service Level Agreements. Genau wie die Service Level Agreements müssen auch diese Verträge auf Einhaltung überwacht, regelmäßig berichtet und sofern nötig angepasst werden. Dazu finden entsprechende Meetings mit den Lieferanten statt. Um die Gesamtheit aller Verträge zu optimieren, müssen alle Verträge (Underpinning Contracts und Outsourcing-Verträge) in regelmäßigen Abständen bewertet werden. Dies dient zur Optimierung der zugelieferten Leistung in qualitativer und preislicher Hinsicht. Kontrolle Die Fertigungstiefe der IT-Organisationen nimmt immer mehr ab und so nimmt der Anteil der Lieferanten an der Lieferung der ITServices immer mehr zu und damit die Abhängigkeit der ITOrganisation von externen Lieferanten. Das bedeutet, dass der Kontrolle dieses Prozesses ebenfalls immer mehr Bedeutung zukommt. Im Wesentlichen erstreckt sich diese auf folgende Themen: ¾

Schnittstellen zu Lieferanten

¾

Beziehungsmanagement zu den Lieferanten

¾

Lieferantenrisikomanagement

¾

Überwachung Lieferanten in Bezug auf die gelieferten Leistungen

Mit allen Lieferanten müssen Verträge geschlossen sein, und diese müssen auch die tatsächlich zu liefernde Leistung beschreiben. Es kann also nicht sein, dass Lieferanten Leistungen erbringen, für die sie nicht ausgewählt wurden. Die Zulieferer sind sich über ihre Verantwortlichkeiten bewusst und kennen die Risiken für das Kerngeschäft, falls die Leistung nicht in der geforderten Qualität geliefert wird. Für Leistungen, außerhalb ihres Vertrages, können sie dieses Bewusstsein nicht haben. Die Inhalte der Verträge mit diesen Zulieferern sind ähnlich aufgebaut wie die Service Verträge mit den Kunden und haben ähnliche Inhalte. Diese Zuliefererverträge sind allerdings meist technischer als diese Kundenverträge. Auf jeden Fall sollten sie als zusätzliches Element das Recht des Einkäufers enthalten, die Leistungserbringung auditieren zu lassen. Überprüfungen, ob die 109

3

COBIT-Prozessbeschreibung Leistungserbringung auch kontrolliert wurde, kann durch Prüfung der Meetingprotokolle oder auch der Auditierungsergebnisse vorgenommen werden. Auswahl und Management der Zulieferer hat nach den Standards und Policies der Unternehmung statt zu finden. Die IT-Abteilung kann diese Standards lediglich verfeinern und detaillieren. Die Einhaltung dieser Vorschriften ist durch das Management sicher zu stellen. Als Maßstäbe zur Bewertung der Lieferanten können folgende Kriterien herangezogen werden: ¾

Zufriedenheit der Abnehmer (Geschäftseinheiten)

¾

Anzahl der Anwenderbeschwerden bezogen auf Periode

¾

Anzahl von Incidents des Lieferanten pro Periode, die auf Fehler des Lieferanten zurückzuführen sind

¾

Anzahl fehlerhafter Abrechnungen

Die Compliance mit dem Prozess selber kann auch durch Kontrolle der Einhaltung der Meetings mit den Lieferanten, der Lieferantenzufriedenheit oder auch durch Einhaltung der Anzahl vertraglicher Lieferanten überprüft werden. Beziehungen zu anderen Prozessen PO1, PO8,AI5, DS1, DS4

Lieferanten-Management

Lieferantenkatalog

AI5

Prozess Performance-Bericht

ME1

Lieferantenrisiken

PO9

Abb. 3-42 Beziehungsdiagramm – Lieferanten-Management (Third Party Services)

110

3.4

3.4.3

DS Delivery und Support

DS3 Performance und Kapazitätsmanagement Kurzbeschreibung Innerhalb der IT-Organisation müssen die Leistungsparameter und die internen Anforderungen an die Systeme überwacht und geregelt werden. Der Gebrauch der IT bedingt in sich eine immer höhere Auslastung der Ressourcen, da das, was gut nutzbar ist, auch immer mehr genutzt wird. Gleichzeitig ändern sich die Anforderungen der Geschäftseinheiten in immer kürzeren Abständen. Diesen Umständen muss Rechnung getragen werden. Ziel Managen der Performance (Leistung) und der Kapazität, um eine ausreichende Kapazität verfügbar zu haben und dadurch den besten und optimalsten Gebrauch davon zu machen, um die Performance-Anforderungen einzuhalten. Aktivitäten Verfügbarkeits- und Leistungsanforderungen

Verfügbarkeitsplan entwickeln und pflegen Kapazitätsplan entwickeln und pflegen Zukünftigen Bedarf an IT Ressourcen bestimmen Managen/ Review Leistung und Kapazität, Ressourcen Überwachung / Bewertung der Performance / Kapazitäten / Prozessqualität Nein

In Ordnung? Ja

Ende

Abb. 3-43 Flowchart - Performance und Kapazitätsmanagement

111

3

COBIT-Prozessbeschreibung Über die Leistungsfähigkeit der Ressourcen müssen Daten erhoben, Analysen durchgeführt und Berichte erstellt werden. Die Anpassung der Applikationen an den Bedarf und die Steuerung der Auslastung sind weitere Inhalte des Prozesses. Definieren der Performance und Verfügbarkeitsanforderungen muss entsprechend der Policies des Unternehmens und der originären Kundenanforderungen vorgenommen werden. So sind z.B. die Verfügbarkeitsanforderungen der Ressourcen über die Zeit zu ermitteln und dann bereit zu stellen, wenn sie wirklich benötigt werden. Dies dient dazu, Kosten und Ressourcenverbrauch in ein angemessenes Verhältnis zu bringen. Sinngemäß gilt dies auch für die Anpassung der Ressourcen an den Gebrauch. Die Hochrüstung von Systemen erfordert Kapitaleinsatz. Hier ist das Performance und Capacity Management gefordert, den Markt zu beobachten und kostenangepasste Alternativen aufzuzeigen und einzuführen. Trendanalysen und Analysen der Geschäftspläne sind für diesen Prozess unverzichtbare Bestandteile. Diese bieten die Möglichkeit, auf zukünftige Erfordernisse zu reagieren und kosteneffektiv zu reagieren. Allgemein gilt, dass die IT-Kapazität so anzupassen ist, dass sie den Erwartungen der Anwender und Kunden entspricht und in der Lage ist die abgesprochenen Servicelevel einzuhalten. Kontrolle Die durchzuführenden Kontrollen erstrecken sich auf die folgenden Themen: ¾

Verfügbarkeits- und Performance-Planung

¾

Derzeitige Performance und Kapazität

¾

Zukünftige Performance und Kapazität

¾

Verfügbarkeit der Ressourcen

¾

Überwachung und Berichterstattung

Für jeden angebotenen Service sind die zeitlichen Planungen durchzuführen, bzw es sind Aussagen dazu zu treffen. Diese müssen den Anforderungen der Anwender entsprechen und es muss nachvollziehbar sein, dass dieses auch stimmt. Die Planungen müssen den Anforderungen des Geschäftsbetriebes entsprechen und finanziell gerechtfertigt sein. Dieser Prozess erfordert den Einsatz von Modellierungstechniken. Das Vorhandensein entsprechender Skills und Voraussetzungen sind daher prüfbare Ergebnisse. 112

3.4

DS Delivery und Support

Statistiken zur Performance, Kapazität und Verfügbarkeit sind vorhanden und genau. Die erhaltenen Werte sollen den Anforderungen entsprechen. Prüfpunkte sind daher die Kontrolle der Exaktheit der Statistiken und ob der Abgleich mit den Anforderungen der Geschäftsbereiche auch stattfindet. Diese historischen Daten werden in die Zukunft extrapoliert. Alternativen sind aufzuzeigen. Kapazität bezieht sich dabei nicht nur auf die ITInfrastruktur, sondern umfasst alle Bereiche der IT, die zur Performance beitragen. Es ist daher zu untersuchen, ob der Focus auch eingehalten wird. Insbesondere kann in einer Überprüfung festgestellt werden ob ¾

SLA-Verletzungen wegen Kapazität und Performance auftreten und beseitigt werden

¾

Diese Berichte auch ganz offiziell an die Anwender und Kunden herausgegeben und gegebenenfalls an diese Zielgruppe angepasst werden.

¾

Änderungen an den Objekten des Prozesses über das Change Management vorgenommen werden sind Anwender-orientiert sind.

¾

Eskalationsprozeduren vorhanden sind und diese auch im Problemfalle befolgt werden.

¾

Für das Design notwendiger Anpassungen eine einheitliche standardisierte Methode eingesetzt wird.

Beziehungen zu anderen Prozessen AI2, AI3, DS1

Performance und Kapazitätsmanagement Performance und Kapazitätsinformationen Performance und Kapazitätsplan

PO2, PO3 PO5, AI1, AI3, ME1

Erforderliche Änderungen

AI6

Prozess Performance-Bericht

ME1

Abb. 3-44 Beziehungsdiagramm - Performance und Kapazitätsmanagement

113

3

3.4.4

COBIT-Prozessbeschreibung

DS4 Continuity Management Kurzbeschreibung Katastrophen kommen vor. Die Ursachen können dabei vielfältiger Natur sein, und es sind keineswegs die großen Katastrophen, welche die Mehrzahl der Konkurse verursachen, sondern die kleinen ganz alltäglichen Katastrophen, für die keine Vorsorge getroffen wurde. Continuity Management ist daher überlebenswichtig für die IT-Organisation. In vielen Fällen existieren auch gesetzliche Regelungen, die bestimmte Vorsorgemaßnahmen vorschreiben. Ziel Sicherstellen eines fortdauernden Betriebes auch im Falle einer größeren Störung (Notfall) um die Auswirkungen auf das Geschäft zu minimieren. Aktivitäten Notfallanforderungen

Impact Analyse und Risikobewertung

IT-Notfallstrategie entwickeln und pflegen

IT-Notfallplan entwickeln und pflegen Testen und Einführen, Schulen IT-Notfallplan Überwachung / Bewertung Nein

In Ordnung? Ja

Ende

Abb. 3-45 Flowchart - Continuity Management

114

3.4

DS Delivery und Support

Ausgangspunkt der IT Continuity-Aktivitäten ist der Business Continuity Plan und damit die Anforderungen des Geschäftes. Im Umkehrschluss bedeutet dies, dass das Management des Kerngeschäftes sich als erstes mit Notfällen auseinandersetzen muss, um die Rahmenbedingungen für die IT Continuity festzulegen. Die Business Continuity muss sich dabei auch mit den externen Anforderungen, unter anderem gesetzliche Regelungen, auseinandersetzen und diese in ihre Pläne einbauen. Auf dieser Basis sind dann die spezifischen auf die IT heruntergebrochenen Continuity-Anforderungen zu beschreiben und eine entsprechende Strategie zu entwickeln. Das Continuity Management erstreckt sich dabei auf alle Bereiche der IT und spart keinen aus. Der IT-Betrieb birgt spezielle Risiken, die Einfluss auf den Geschäftsablauf haben können. Im Rahmen des Risikomanagements sind diese aufzuzeigen und auf ihre Wirkung für die Continuity abzuschätzen. Ein besonderes Gefahrenpotential stellen die Single Points of Failure (SPF) dar. Das sind Ressourcen, deren Ausfall ganze Geschäftsprozesse gefährdet ohne dass sie redundant ausgelegt wären. Notfallpläne sind zu entwickeln, zu testen und zu pflegen. Permanente Anpassung an eine sich stetig wandelnde Umgebung ist dabei eine große Herausforderung. Kontrollen Für die Kontrolle des Prozesses sind die nachfolgenden Themen relevant. ¾

IT Continuity Framework

¾

IT Continuity Plan (Strategie und Philosophie)

¾

Kritische IT-Ressourcen

¾

Pflegen des IT-Continuity Plans

¾

Testen des IT-Continuity Plans

¾

Schulen / Trainieren der IT-Continuity-Prozeduren

¾

Kommunikation des IT-Continuity-Plans

¾

Wiederherstellungsprozeduren

¾

Notfallrechenzentren

¾

Review nach einem Notfall

115

3

COBIT-Prozessbeschreibung Ein durchgängiger Prozess für das Continuity Management ist zu beschreiben. Dies wird wie im SLM alle Bereiche umfassen und stellt dann eine Framework für diesen Bereich dar. Ein Notfallplan zur Reduzierung der Auswirkungen von ServiceNotfällen, basierend auf dem Framework, muss vorhanden und aktuell sein. Alle Bereiche der IT-Organisation müssen diesen Plan kennen, verstehen und danach handeln können. Der Plan enthält alternative Möglichkeiten für Rechner und Wiederherstellungsszenarien. Er sollte auch einen Anwenderleitfaden, Rollen und Verantwortlichkeiten, sowie die Prozeduren zur Wiederherstellung und der Kommunikation enthalten. Die Pläne müssen konsistent mit den Unternehmensplänen, Strategien und der Philosophie sein. Die Durchführung regelmäßiger Training, an denen die Mitarbeiter teilnehmen, ist zu prüfen. Die Teilnahme der Mitarbeiter ist explizit nachzuweisen. Der beste Plan taugt nichts, wenn er in der Praxis versagt. Nachvollziehbare, alle Bereiche umfassende Tests sind daher nachzuweisen. Die Tests müssen realistisch sein, um Erkenntnisse zu gewinnen, aus denen dann Verbesserungen abgeleitet werden. Sollte dennoch einmal ein Notfall eintreten, ist es um so wichtiger, dass aus diesen Vorfällen Lehren gezogen werden. Dieser Fall ist vorzusehen, und es ist nachzuweisen, dass dieser Prozess auch durchgeführt wird. Beziehungen zu anderen Prozessen PO2, PO9, AI2, AI4, DS1

Continity Management Test-Ergebnisse

PO9

Kritikalität der CIs

DS9

Plan zu Sicherung und Schutz der Systeme Schwellwerte für Katastrophen Service-Anforderungen für Katastrophen (Rollen) Prozess PerformanceBerichte

DS11, DS13 DS8 DS1, DS2 ME1

Abb. 3-46 Beziehungsdiagramm - Continuity Management

116

3.4

3.4.5

DS Delivery und Support

DS5 Security Management Kurzbeschreibung Sicherheit wird immer notwendiger, in Zeiten offener Netze und neu auftretender terroristischer Gefahren. Dabei ist absolute Sicherheit nicht herzustellen. Es gilt also, in einer Umwelt, in der die Sicherheitsprobleme, aber auch die Anforderungen an die Sicherheit, immer größer werden, einen Mittelweg zu finden, der für die Firma tragbar (effizient und effektiv) ist. Ziel Sicherstellen einer System Security, um Informationen gegen unautorisierten Gebrauch, widerrechtliche Veröffentlichung und Veränderung, Schaden oder Verlust zu schützen. Aktivitäten Sicherheitsanforderungen

Sicherheitspolicies entwickeln und pflegen Sicherheitsplan entwickeln und pflegen Testen und Einführen IT Sicherheitsplan Überwachen der Sicherheitslage Anwenderrechte regel-mäßig überprüfen / korrigieren Kontrollen für Kryptographie und Netzwerksicherheit entwickeln, implementieren Überwachung / Bewertung

Nein

In Ordnung? Ja

Ende

Abb. 3-47 Flowchart - Security Management

117

3

COBIT-Prozessbeschreibung Sicherheitspolicies setzen auf den Risiken auf, denen eine ITOrganisation natürlicherweise ausgesetzt ist, und auf den Anforderungen, die sich aus gesetzlichen und gesellschaftsrechtlichen Rahmenbedingungen ergeben. Schutz Firmen-vertraulicher Daten und privater Daten von Mitarbeitern oder Kunden ist ein absolutes Muss. Ein strategischer, zentral verfolgter Sicherheitsplan ist aufzusetzen. Dies bedeutet auch eine zentralisierte Sicherheitsorganisation, die alle Aspekte der Sicherheit verantwortet, also plant, kommuniziert, steuert und überwacht. Bezogen auf die Mitarbeiter ist ein Gleichgewicht zu finden zwischen dem, was getan werden darf, und dem, was getan werden muss und zwischen der Kontrolle dieser Tätigkeiten und dem Persönlichkeitsschutz. Es sind für jeden Anwender oder Gruppen von Anwendern Profile zu erstellen, die eine ausreichende Nachvollziehbarkeit der Handlungen (Identifikation) und eine Autorisierung für erlaubte Tätigkeiten umfasst. Bezogen auf die technischen Systeme ist der Einsatz von kryptographischen Methoden, Firewalls, Virenschutz und Erkennung Software, sowie der Einsatz von Monitoring-Tools für den Nachweis sicherer Netze und Systeme zu beplanen. Organisatorische Maßnahmen in dem Plan sind Fragen der zentralen Sicherheitsadministration, des Anwendertrainings und der Frage, wie mit Sicherheitsincidents umgegangen wird und wie diese berichtet werden. Kontrolle Die Objekte, auf die sich die Kontrolle bezieht sind, äußerst vielfältig.

118

¾

Management von Sicherheit

¾

Sicherheitsplanung

¾

Identifizierung, Authentifizierung und Zugriffsregeln

¾

Sicherheitsüberwachung und Test

¾

Sicherheitsincident, Definition und Bearbeitung

¾

Schutz der eingesetzten Sicherheitstechnologie

¾

Einsatz kryptographischer Methoden

¾

Vermeidung, Erkennung und Beseitigung von bösartiger Software

¾

Netzwerksicherheit

3.4

DS Delivery und Support

¾

Schutz sensitiver Daten

¾

Sicherheitsberichte (Sicherheitsverletzungen, eingeleitete Aktivitäten)

Im Rahmen des Managements der Sicherheit muss ein Verständnis für die Sicherheitsbedürfnisse, die Bedrohungen und der Schwachstellen aufgebaut werden. Regelmäßige Test der Sicherheitseinrichtungen sind vorzunehmen. Die Anwenderidentitäten sind zu begutachten. Es ergeben sich daher die Prüfpunkte: ¾

Anzahl unnötiger oder abgelaufener Accounts

¾

Anzahl unautorisierter IP-Adressen oder abgewiesener Zugriffe

¾

Anzahl der Änderungen an den Anwenderrechten

¾

Häufigkeit des Reviews der Sicherheitsbedürfnisse

Das Management muss das Vorhandensein der Mechanismen prüfen und Ziele für die einzelnen Themen setzen. Prozeduren für den externen Zugriff existieren (Passwörter, Logonmechanismen, Identifizierung, Rückrufe, etc) Die Sicherheitspolicies für die Systeme sind für die Beteiligten verfügbar, wurden verstanden und werden auch befolgt. Hier kann als Messwert die Anzahl der Anwender, die sich nicht an die Richtlinien halten (z.B. Speicherungsregeln, Aufgabenverteilung) herangezogen werden. Eine Berichterstattung existiert, die alle Aspekte der Sicherheit umfasst. Beziehungen zu anderen Prozessen PO2, PO3, PO9, AI2, DS1

Security Management

Definition Security Incident

DS8

Schulungsanforderungen zur Security

DS7

Erforderliche SecurityÄnderungen

AI6

Bedrohungen und Schwachstellen der Security

PO9

Prozess PerformanceBerichte

ME1

Abb. 3-48 Beziehungsdiagramm - Security Management

119

3

3.4.6

COBIT-Prozessbeschreibung

DS6 Kostenmanagement Kurzbeschreibung Das Aufstellen von IT-Budgets ist nicht genug, um die Kosten im Griff zu halten. Die andere Seite der Medaille ist es, genau die Kostentreiber zu identifizieren, die für die Kostenentwicklung verantwortlich sind, hierauf Einfluss zu nehmen oder das entsprechende Bewusstsein für die Kostentreiber zu vermitteln und dadurch die Kosten zu senken. Ziel Identifizieren und Zuweisen von Kosten, um ein Bewusstsein für die Kosten der IT zu schaffen und um eine verbesserte Entscheidungsfindung innerhalb der IT und des Business zu ermöglichen. Aktivitäten Anforderungen der Finanzberichterstattung

Kostenverteilstrukturen entwickeln und pflegen

Festlegen der Kostenberechnungsprozeduren Festlegen Verrechnung und Mittelrückfluss Abweichungsberichte erstellen und verteilen Überwachung / Bewertung Nein

In Ordnung? Ja

Ende

Abb. 3-49 Flowchart - Kostenmanagement

Zur Festlegung der Kostenstrukturen müssen die messbaren Ressourcen identifiziert werden. Diese Ressourcen sind den Services und den Service-Leveln zuzuordnen um, dadurch eine Struktur 120

3.4

DS Delivery und Support

zu schaffen, die es erlaubt, eine permanente Überwachung der Kosten und der Kostenentwicklung eines Services durchzuführen. Idealerweise wird diese Zuweisung und Überwachung automatisiert, so dass nicht unnötige Ressourcen in die Kostenüberwachung fließen und so den Vorteil wieder zunichte machen, der darin besteht, dass auf Grundlage der Kenntnisse, wo die Kosten tatsächlich entstehen, Maßnahmen getroffen werden können, die Service kostengünstiger zu erbringen. Exakte Zuweisung schafft auch erst die Voraussetzung, die Servicekosten mit externen Anbietern zu vergleichen. Ansonsten besteht eine nicht unerhebliche Gefahr, unzulässige Vergleiche anzustellen und dadurch eventuell Services zu teuer einzukaufen oder Kostenvorteile durch günstigeren Einkauf gar nicht heben zu können. Liefern Services die Ergebnisse nicht im erwarteten Kostenrahmen, so sind hierfür Berichte zu erstellen und durch die Organisation Maßnahmen einzuleiten, um diesen Missstand zu beseitigen. Die Verrechnung der Kosten liefert die Mittel zur Refinanzierung der IT-Mittel. Für diese IT-Mittel ist ein jährliches Budget zu erstellen. Dieses muss auf der einen Seite die organisatorischen Anforderungen der Firma und auf der anderen Seite die Verrechnungen an die Anwender enthalten. Zusätzlich muss die Investitionsplanung (PO5) berücksichtigt werden. Kontrolle Die Kontrollziele lassen sich auf drei Objekte reduzieren. ¾

Verrechenbare Einheiten (Services)

¾

IT Accounting

¾

Kostenzuweisung (Modellierung und Verrechnung)

¾

Kostenmodellanpassungen

Die Frage lautet also, sind verrechenbare Einheiten definiert und sind diese den Services zugeordnet. Ist also eine Kostenzuweisungsmethode etabliert und ist diese mit den Anwendern, respektive Kunden, abgestimmt. Die IT-Services sind mit den Geschäftsprozessen verbunden, und daher können nun die Kosten auch diesen Geschäftsprozessen zugeordnet werden. Ein Kostenmodell muss mit den aktuellen Werten gefüllt, also erhoben und entsprechend zugeordnet, werden. Abweichungen zwischen Plan und Realität sind vorzunehmen und in Übereinstimmung mit den kaufmännischen Prozessen der Geschäftsbe121

3

COBIT-Prozessbeschreibung reiche zu berichten und gegebenenfalls zu korrigieren. Die Anzahl der Überprüfungen der Abweidungen ist ein mögliches Messkriterium. Ein weiteres ist die Anzahl der Auseinandersetzungen mit den Kunden über die Verrechnung. Die Kostenzuweisung und die Berichterstattung über die Kosten und deren Entwicklung muss die effiziente und effektive Nutzung der ITRessourcen fördern. Die Verrechnung muss die Anwender fair behandeln und darf diese nur mit den Kosten belasten, die diese auch tatsächlich verursachen. Das Kostenmodell ist so zu modellieren, dass es der IT Refinanzierung der Aufwände erlaubt. Dies ist vernünftigerweise Servicebezogen vorzunehmen, da nur dann eine nachvollziehbare Relation zwischen Geschäftsprozess und Kosten erzeugt wird. Für den Abnehmer (Geschäftsberichte / Kunde) ist nicht nur die Nachvollziehbarkeit wichtig, sondern auch die Vorhersehbarkeit. Das dokumentierte Kostenmodell ist auf diese Kriterien zu untersuchen und die Compliance festzustellen. Geschäftsprozesse ändern sich und damit auch die Service. ITInfrastrukturen werden entwickelt und verändert. Dies muss in einer Veränderung der Kostenmodelle münden. Die permanente Anpassung der Modelle an diese sich ändernden Bedingungen ist daher zwingend geboten. IT-Finanzmanagement kann sich nicht nur auf rein rezeptive Aufgaben beschränken. Es ist daher zu prüfen, ob Verbesserungsprogramme existieren, um die Kosten zu reduzieren oder die Leistungsfähigkeit der IT-Ressourcen zu erhöhen. Diese Verbesserungen können allerdings nur in Verbindung mit anderen Prozessen eingeleitet und umgesetzt werden. Eine reine Betrachtung nach Kosteneffizienz ist nicht ausreichend. Beziehungen zu anderen Prozessen PO4, PO5, PO10, DS1

Kostenmanagement

IT-Finanzen

PO5

Prozess PerformanceBerichte

ME1

Abb. 3-50 Beziehungsdiagramm - Kostenmanagement

122

3.4

3.4.7

DS Delivery und Support

DS7 Anwenderschulung und Training Kurzbeschreibung IT-Systeme bilden aus sich heraus keinen Mehrwert für ein Unternehmen. Dies gewinnen sie erst aus der Nutzung der Systeme. Die Nutzung von IT erfordert dabei Kenntnisse und Fähigkeiten von den Mitarbeitern, die diese in der Regel erst erwerben müssen. Ein solches Training erhöht die Effektivität der IT-Systeme durch Reduzierung der Anwenderfehler und Steigerung der Mitarbeiterproduktivität. Ziel Schulen und Trainieren von Anwendern, um sicher zu stellen, dass diese die Technologie effektiv nutzen und sich über die Risiken und ihre Verantwortlichkeiten bei ihrem Einsatz bewusst sind. Aktivitäten Anforderungen an Schulung und Training

Schulungspläne, Traningsprogramm entwickeln und pflegen Schulungsorganisation aufsetzen Ermitteln Schulungsmethoden oder Einkauf von Schulungen Schulung durchführen Überwachung / Bewertung Nein

In Ordnung? Ja

Ende

Abb. 3-51 Flowchart - Anwenderschulung und Training

123

3

COBIT-Prozessbeschreibung Anforderungen an die Schulung und das Training ergeben sich aus der eingesetzten Technologie und der Software, sowie aus der Struktur und vor allem der Vorbildung der Mitarbeiter. Die Kenntnisse der Mitarbeiter sind daher zu erfassen und auf dieser Basis eine Analyse durchzuführen, die den benötigten Schulungsbedarf aufzeigt. Dieser Bedarf kann sich dabei auch aus anderen Prozessen ergeben, z.B. dem Security Management, welches periodische Schulungen für die Mitarbeiter vorsieht. Für alle neuen Mitarbeiter sind diese Sicherheitstrainings verpflichtend. Alle diese Anforderungen sind in einem Schulungsplan festzuhalten und in ein Curriculum zu überführen. Dieses enthält dann die Schulungsbausteine, aus denen sich die Gesamtheit aller Trainingsmaßnahmen ergibt. Für die Durchführung der Schulungen ist eine geeignete Organisation aufzubauen und auch zu entscheiden, ob die Schulungen fremd zu vergeben oder selber zu erbringen sind. Der Einkauf von Schulungen unterliegt dabei natürlich den Policies, welche für den Einkauf von externen Leistungen im Prozess PO4 entwickelt wurden. Schulungsmethoden sind zu evaluieren und geeignete Trainingsmethoden und Trainingssysteme auszuwählen. Kontrolle Im Prozess werden die folgenden Themen begutachtet: ¾

Trainingsanforderungen

¾

Trainingsdurchführung

¾

Evaluierung der durchgeführten Trainingsmaßnahmen

Es ist ein Curriculum zu erstellen, das auf die verschiedenen Anwendergruppen zugeschnitten ist. Unter Anwendergruppen wird hier jede zusammenfassbare Einheit verstanden, die Zielgruppe einer Schulungsmaßnahme sein kann. Diese sollte folgende Gebiete berücksichtigen:

124

¾

Heutige und zukünftige Geschäftsbedürfnisse und Strategien

¾

Firmenwerte (Ethik, Kontrollkultur, Sicherheitswerte, etc)

¾

Einführung neuer IT-Infrastrukturen und Software

¾

Vorhandene Fähigkeiten, Kompetenzprofile, Zertifizierungen

3.4 ¾

DS Delivery und Support

Trainingsmethoden (Frontalunterricht, Web-based Training, Größe der Schulungsgruppen, Zeitplanung, etc)

Es ist also zu prüfen, ob die Trainingsanforderungen tatsächlich erhoben wurden, wie oft das Curriculum angepasst bzw begutachtet wurde und inwieweit die besonderen Bedingungen der Organisation Berücksichtung fanden. Bei der tatsächlichen Trainingsdurchführung kommt es darauf an, diese so zeitnah zu Veränderungen durchzuführen, dass die Mitarbeiter nicht gezwungen sind, sich anderswo Hilfe zu holen. Der zeitliche Abstand zwischen Identifizierung von Trainingsnotwendigkeiten und der Durchführung ist daher ein geeignetes Maß für die Effektivität des Prozesses. Ein weiteres ist die Anzahl der Incidents mit Trainingshintergrund, welche am Service Desk beantwortet werden müssen. Da durch die Schulungsmaßnahmen die Produktivität gesteigert werden soll, ist auch dies ein zur Messung dieses Prozesses sinnvoller Prüfpunkt. In Bezug zum Prozess DS5 ist darüber hinaus sicher zu stellen, dass neuen Mitarbeiter die Sicherheitsrichtlinien und Erfordernisse bewusst sind und sie die Themen verstehen. Beziehungen zu anderen Prozessen PO4, PO5, PO10, DS1

Anwenderunterstützung Erforderliche Updates von Dokumentationen

AI4

Prozess PerformanceBerichte

ME1

Abb. 3-52 Beziehungsdiagramm - Anwenderschulung und Training

125

3

3.4.8

COBIT-Prozessbeschreibung

DS8 Anwenderunterstützung Kurzbeschreibung In der Originalunterlage heißt dieser Prozess „Servicedesk und Incident Management“. Trainings und Schulungen haben oft einen theoretischen Ansatz, und die Dinge stellen sich in der Praxis dann anders dar. Manchmal gibt es Änderungen, die eine Schulung nicht abdecken konnte, oder es treten Fehler auf. Die IT-Organisation muss sicherstellen, dass Unterstützung für den Gebrauch der von ihr zur Verfügung gestellten Systeme und Lösungen auch dann gewährleistet ist. Eine Anwenderunterstützung ist also zwingend notwendig. Ziel Unterstützung und Beratung der Anwender, um sicher zu stellen, dass jedes Problem, Anfrage oder Wunsch, mit dem ein Anwender konfrontiert wird, auch in geeigneter Weise gelöst wird. Aktivitäten Klasssifzierungs-/ Eskalationsprozeduren entwickeln

Kundenanfragen

Annahme & Registrierung

Klassifizierung

Analyse & Diagnose Lösung & Wiederherstellung Überwachung / Bewertung Nein

In Ordnung? Ja

Ende

Abb. 3-53 Flowchart - Anwenderunterstützung

126

3.4

DS Delivery und Support

Dieser Prozess ist wesentlich geprägt durch Servicedesk-Aktivitäten. Diese leisten den First Level Support und geben Hilfe bei der Unterstützung der Endanwender. Neben der Beantwortung von Kundenanfragen und Problemlösungen wird die Infrastruktur überwacht und Störungen proaktiv beseitigt. Um diese Aufgaben durchführen zu können, muss eine Wissensdatenbank und Unterstützungstools für das Management der Anfragen und Störungen aufgebaut werden. Erst das Vorhandensein einer solchen Tool-Unterstützung erlaubt es, die aufgetretenen Probleme mit einem vertretbaren Aufwand nachzuhalten und zu verfolgen, Trendanalysen zu erstellen und aussagekräftige Berichte zu erzeugen, die von anderen Prozessen benutzt werden, um unter anderem die Qualität des gelieferten Services nachzuweisen. Die Befüllung der Wissensdatenbank erfolgt dynamisch durch die Einträge während der Prozessschritte Analyse & Diagnose und Lösung & Wiederherstellung. In diesen Schritten müssen die den Problemen zu Grunde liegenden Ursachen gefunden werden. Ist dieses Wissen erst einmal für alle Agenten verfügbar, so wird sich die Qualität des Servicedesks verbessern, weil die Erstlösungsrate steigt. Die Agenten im Servicedesk benötigen für ihre Arbeit neben der reinen Toolunterstützung genaue Arbeitsanweisungen, Eskalationsregeln und die Vorgaben des Service Level Managements in Form von SLAs. Kontrolle Die Kontrollelemente sind: ¾

Servicedesk

¾

Registrierung von Kundenanfragen / -problemen

¾

Incident-Eskalationen

¾

Überwachung der Lösungen (Beendigung von Incidents)

¾

Trendanalysen und Berichterstattung

Zur Kontrolle prüfen, ob alle den Servicedesk betreffenden Policies und Aktivitäten schriftlich festgehalten, auf dem neuesten Stand sind und auch in der Praxis so durchgeführt werden wie beschrieben. Die Anwenderschnittstelle hat die Aufgabe, alle Anfragen zu registrieren, zu kommunizieren, zu analysieren und in die Fachgruppen zu verteilen, Incidents zu berichten und zu überwachen.

127

3

COBIT-Prozessbeschreibung Folgende weitere Prüfpunkte für den Prozess können genutzt werden: ¾

Die SLAs werden eingehalten, und Abweichungen werden in den Berichten erläutert.

¾

Die Lösung der Probleme und Anfragen erfolgt in einem zeitlich angemessenen Rahmen. Dies kann durch eine Überprüfung einzelner Anfragen und Probleme verifiziert werden.

¾

Mechanismen zur Abfrage der Benutzerzufriedenheit sind zu installieren, und es muss entsprechende Reaktionen geben, wenn diese Berichte Handlungsbedarf erkennen lassen. Die Umsetzung der Maßnahmen und der Erfolg lassen sich überprüfen.

¾

Trendanalysen und Berichte werden angefertigt. Es ist darauf zu achten, dass diese spezifische Probleme, Trendanalysen, Antwortzeiten etc enthalten und an eine verantwortliche Person adressiert sind, mit der Autorität Probleme zu lösen und Entscheidungen treffen zu können.

Beziehungen zu anderen Prozessen AI4, AI6, AI7, DS1, DS4, DS5, DS9, DS10, DS13

Anwenderunterstützung Service Requests / Änderungsanforderungen Incident-Berichte Berichte zur Anwenderzufriedenheit Prozess PerformanceBerichte

AI6 DS10 DS7, ME1 ME1

Abb. 3-54 Beziehungsdiagramm - Anwenderunterstützung

128

3.4

3.4.9

DS Delivery und Support

DS9 Konfigurationsmanagement Kurzbeschreibung Basis für die Arbeit der IT ist eine saubere und klare Informationsbasis. Auf dieser setzen alle Prozesse auf. Stimmt diese nicht, so haben alle anderen Prozesse Schwierigkeiten, ihre Aufgaben adäquat zu erbringen. Das Konfigurationsmanagement ist also keine Aufgabe, die nebenher mitlaufen kann, sondern ist eine der Kernaufgaben einer IT. Ziel Managen der Konfiguration, um für alle IT-Komponenten Rechenschaft ablegen zu können, unautorisierte Veränderungen zu verhindern, physische Existenz nachzuweisen und damit eine solide Basis für das Change Management zu schaffen. Aktivitäten Konfigurationsmanagement Strategie & Policies

Festlegen der Configuration Items (Cis) Verfizieren und autidieren Konfigurationselemente Konfigurationsrepository erneuern Überwachung / Bewertung Nein

In Ordnung? Ja

Ende

Abb. 3-55 Flowchart - Konfigurationsmanagement

Es müssen Kontrollen eingeführt werden, durch die alle IT-Assets identifiziert und aufgezeichnet werden. Die tatsächliche Aufstellort ist festzuhalten und ein Verfahren zu etablieren, das sicherstellt, dass die Assets auch tatsächlich überprüft werden und ihre Existenz nachgewiesen wird.

129

3

COBIT-Prozessbeschreibung Im Einzelnen wird also eine Nachverfolgung der Assets sowie der eingesetzten Software vorgenommen. In diesem Zusammenhang ist es ebenfalls wichtig die Beziehungen zwischen der Hardware und der Software eindeutig darzustellen und zu überprüfen, ob unautorisierte Software im Einsatz ist. Für die Durchführung des Konfigurationsmanagements empfiehlt es sich, automatisierte Tools einzusetzen. Manuelle Pflege von Daten ist im Allgemeinen fehlerbehaftet und führt dazu, dass auf der einen Seite der Aufwand sehr hoch ist und auf der anderen Seite, dass trotzdem die Korrektheit der Daten nicht in dem Maße gewährleistet werden kann, wie das notwendig ist, um einen effektiven Betrieb durchzuführen. Eine Kontrolle für die Speicherung der eingesetzten Software ist zu implementieren. Diese sollte folgende Themen einschließen: ¾

Definitionen von gesicherten Speicherumgebungen, die für alle Phasen des Lebenszyklus einer Software vorhanden sind.

¾

Diese Umgebungen sind getrennt für die Phasen Entwicklung, Test und Produktion, und es findet keine Durchmischung statt.

¾

Für den Zugriff auf diese Umgebungen sind logische und physikalische Zugriffsberechtigungen definiert und eingerichtet.

¾

Die Einhaltung dieser Richtlinien wird berichtet.

Damit eine Verfolgung und Kontrolle der eingesetzten Software erfolgen kann, ist diese eindeutig zu bezeichnen und in periodischen Abständen zu inventarisieren. Kontrolle Betrachten Sie bei der Einrichtung die Existenz folgenden Kontrollobjekte und prüfen ihr Vorhandensein und ihre Effektivität: ¾

Konfiguration Datenbank und Baseline

¾

Identifikation von Konfigurationselementen

¾

Begutachtung der Integrität der Konfigurationselemente

Die Konfigurationsdatenbank enthält alle relevanten Informationen zu den Konfigurationselementen. Sie beinhaltet Hardware, Software (Betriebssysteme und Applikationen), Parameter (soweit relevant), Dokumentationen usw. Eine Baseline sollte immer vorhanden sein, um einen Aufsetzpunkt zu haben, auf den wieder zurückgegriffen werden kann, wenn Änderungen fehl schla130

3.4

DS Delivery und Support

gen. Mögliche Prüfpunkte neben dem Compliancecheck zu den festgelegten Prozessen ist die Anzahl der Abweichungen in der Datenbank und der aktuellen Konfiguration. Ein Beispiel ist die Anzahl der Software-Lizenzen, welche tatsächlich genutzt werden in Bezug zu derjenigen Anzahl, die in der Datenbank hinterlegt sind. Folgende Subprozesse sind zu implementieren und deren Vorhandensein nachzuweisen: ¾

Identifizierung der Konfigurationselemente und ihrer Attribute

¾

Aufzeichnen neuer, geänderter und gelöschter Elemente

¾

Pflegen der Beziehungen zwischen den Elementen

¾

Verhindern der Einbeziehung unautorisierter Software

In regelmäßigen Abständen sind die Daten einem Integritätscheck zu unterziehen. Die Anzahl der Durchführung kann ein Maß für die Ernsthaftigkeit sein, mit welcher der Prozess betrieben wird. Der Integritätscheck bezieht sich auf die Bestätigung der Richtigkeit der aktuellen Konfiguration und der Einhaltung der Policies. Der Bericht sollte zur Prüfung des Prozesses herangezogen werden. Beziehungen zu anderen Prozessen Configuration Management AI4, AI7, DS4 IT Configruation, Asset-Details

DS8, DS10, DS13

RFC (Wo und wie zu ändern ist)

AI6

Prozess PerformanceBerichte

ME1

Abb. 3-56 Beziehungsdiagramm - Konfigurationsmanagement

131

3

3.4.10

COBIT-Prozessbeschreibung

DS10 Problem Management Kurzbeschreibung Störungen und Probleme treten immer auf. Dies ist Technologieimmanent. Es muss also darum gehen, neben der Vermeidungsstrategie die Auswirkungen von Störungen und Problemen zu minimieren und dadurch Kosten zu senken und ServiceVerbesserungen zu erzielen. Incidents, verstanden als jedes Ereignis, das potentiell einen Service stört, können zu Problemen führen. Probleme werden dabei verstanden als Störungen mit erheblichen Auswirkungen oder prinzipielle Fehler in der Technologie, deren Ursache noch nicht bekannt ist. Ziel Managen von Problemen und Incidents, um zu gewährleisten, dass Probleme und Incidents gelöst werden und die Ursache der Störung ermittelt wird, um zukünftige ähnliche Störungen auszuschließen. Aktivitäten Problem & Incident Mgmt Strategie & Policies

Problem-Identifizierung und Registrierung, Klassifizierung Ursachenuntersuchung

Problemlösung

Statusreview der Probleme Einzelfallbezogene Verbesserungsvorschläge und RFC Überwachung / Bewertung Nein

In Ordnung? Ja

Ende

Abb. 3-57 Flowchart - Problem Management

132

3.4

DS Delivery und Support

Grundsätzlich ist zunächst einmal eine Strategie notwendig, in der festgelegt wird, wie mit Incidents und Problemen umgegangen werden soll. Dies führt dann auf direktem Weg zu einer Definition eines Problem Management-Systems, in dem alle Ereignisse, die vom normalen Betriebsablauf abweichen, aufgezeichnet werden und das es erlaubt, eine Klassifizierung und Priorisierung von solchen Ereignissen vorzunehmen. Bei der Entwicklung der Abläufe des Problemmanagements ist zu berücksichtigen, dass der Geschäftsprozess möglichst wenig gestört wird. Die Wiederherstellung muss also in zeitlich angemessener Weise erfolgen. Es sind daneben Eskalationsprozeduren einzurichten, die immer dann aktiv werden, wenn die Vorgaben (SLAs) nicht eingehalten werden können. Hier sind vordefinierte Autorisierungen für das Ergreifen von Maßnahmen vorzusehen. Die Behebung von Störungen hat vielfach Änderungen an der Infrastruktur zur Folge. Änderungen werden immer über das Change Management gesteuert. Aus diesem Grund ist eine enge Verzahnung dieses Prozesses mit dem Change Management geboten. Es empfiehlt sich hier, Änderungen im Voraus zu definieren (Standardänderungen), die keine Genehmigung mehr benötigen, sondern nur noch gemeldet werden. Berichte über das Incident-Aufkommen, ihrer Art und Auswirkungen sind ein weiteres Element. Aus diesen lässt sich die Qualität der Infrastruktur ablesen und Verbesserungen ableiten. Kontrolle Kontrollelemente dieses Prozesses sind ¾

Problem Management System

¾

Identifikation und Klassifizierung von Problemen

¾

Problemverfolgung und Checklisten

¾

Beendigung von Problemen

¾

Integration von Änderungswesen, Konfigurationsmanagement und Problemmanagement

Es muss ein Problemmanagement-System installiert werden, das Probleme identifiziert und einer Lösung zuführt. Dies wird zweckmäßigerweise in ähnlicher Art und Weise wie im Incidentmanagement erfolgen. Das Management muss den Prozess regelmäßig einer Kontrolle unterziehen, um den Prozess stetig zu verbessern und effizienter zu gestalten.

133

3

COBIT-Prozessbeschreibung Die verwendeten Checklisten für die Prüfung, also der Einordnung, Priorisierung und Klassifizierung der Probleme und sogar der ersten Hilfe sollten in ausreichender Form vorhanden sein. Ein Prozess zur Verbesserung dieser Checklisten ist notwendig und auf Vorhandensein zu prüfen. Schwerwiegende Probleme müssen auch als solche erkannt werden können, Prioritäten sind entsprechend zu vergeben und zu definieren und Maßnahmen vorher zu autorisieren. Falls Fälle auftreten, in denen zwar gehandelt werden muss, aber keine vorher autorisierten Maßnahmen definiert wurden, ist ein Verfahren zu etablieren, das trotzdem Handlungen erlaubt. Hier kann geprüft werden, ob die Zustimmung des Managements auch in solchen Fällen geregelt ist und ob dieses auch die beschriebenen Sicherheitsaspekte berücksichtigt. Problemmanagement ist in der Verpflichtung, solche Fälle im Vorfeld zu bedenken. Weitere Prüfpunkte können sein: ¾

Anzahl der aufgezeichneten und verfolgten Probleme

¾

Anzahl der Probleme, die innerhalb der vereinbarten Zeit gelöst wurden

¾

Anzahl der wiederholt aufgetretenen Probleme

¾

Störungen des Geschäftsbetriebes auf Grund von Problemen

¾

Die Häufigkeit der Berichte oder der Updates zu Problemberichten

Beziehungen zu anderen Prozessen AI6, DS9, DS10, DS13

Problem Management Änderungsanforderungen

AI6

Aufgezeichnete Probleme

AI6

Bekannte Probleme und Fehler, Workarounds

DS8

Prozess PerformanceBerichte

ME1

Abb. 3-58 Beziehungsdiagramm - Problem Management

134

3.4

3.4.11

DS Delivery und Support

DS11 Data Management Kurzbeschreibung In der IT geht es grundsätzlich um die Verarbeitung von Daten. Diese Verarbeitung und die daraus abgeleiteten Ergebnisse (erneut Daten) werden immer wichtiger, denn sie bestimmen in zunehmendem Maße unsere Welt, indem darüber Einfluss auf unsere Wahrnehmung der Wirklichkeit genommen wird. Daten sind daher ein wertvolles Gut, das sorgfältigst zu behandeln und entsprechend zu schützen ist. Dieser Prozess kümmert sich daher um das Management der Speichersysteme, das Backup und die Wiederherstellung von Daten bis hin zur Vernichtung von Datenträgern. Ziel Managen von Daten, um deren Vollständigkeit, Integrität und Gültigkeit während der Eingabe, des Updates und der Speicherung sicher zu stellen. Aktivitäten Data Management Strategie & Policies

Data Management-Prozeduren Definieren, Pflegen, Implementieren der Prozeduren Backup & Recovery Data Storage Sichere Entsorgung von Daten implementieren, durchführen

Überwachung / Bewertung Nein

In Ordnung? Ja

Ende

Abb. 3-59 Flowchart - Data Management

Für diese Verarbeitung sind eine ganze Reihe von Faktoren zu berücksichtigen. Die Eingangsgrößen in den Prozess sind sorgfäl135

3

COBIT-Prozessbeschreibung tig auszuwählen und zu prüfen. Das Gleiche gilt für die Behandlung / Verarbeitung der Daten und der gelieferten Ergebnisse. Für das gesamte Datenmanagement ist eine Strategie zu entwickeln und dazu passende Policies zu definieren. Darüber hinaus sollte der Prozess ¾

Datenerhebungsprozeduren entwickeln und überwachen

¾

Datenintegrität sicherstellen

¾

Datenspeicherungsprozeduren entwickeln und überwachen

¾

Sicherungsmaßnahmen für Datastorage definieren und einführen

¾

Das Data Management bewerten

Kontrolle Wegen der Wichtigkeit der Daten sind die Kontrollen sehr ausgefeilt und detailliert vorzunehmen. Auf der obersten Ebene nennt COBIT die folgenden Elemente: ¾

Geschäftsanforderungen für das Datenmanagement

¾

Speicher- und Aufbewahrungsfestlegungen und Einrichtungen

¾

Speicherungsmanagement System

¾

Vernichtung von Datenträgern

¾

Backup und Restore

¾

Sicherheitsanforderungen für das Datenmanagement

Für die Phasen Datenvorbereitung, Dateneingabe, Datenbearbeitung und Datenausgabe werden beispielhaft einige detaillierte Prüfpunkte genannt, welche die IT sicher stellen muss: Datenvorbereitung:

136

¾

Die Abläufe stellen die Vollständigkeit, Genauigkeit und Gültigkeit der Quellen sicher

¾

Autorisierungsprozeduren für die Quelldaten sind vorhanden

¾

Geeignete Prozeduren für die Behandlung fehlerhafter Quellen ist vorhanden

¾

Der Schutz sensibler Quellen ist gewährleistet

¾

Quelldaten stehen ausreichend lange zur Verfügung, um eine Wiederherstellung bei fehlerhafter Weiterbearbeitung zu ermöglichen

3.4

DS Delivery und Support

Dateneingabe: ¾

Eindeutige Trennung der Aufgaben (Strukturieren, Genehmigen, Dateneingabe)

¾

Eindeutige Identifizierung des Eingebenden (Terminalcode / Benutzercode), Pflege der Codes ist gewährleistet

¾

Verifikation der eingegebenen Daten findet statt

¾

Geeignete Prozeduren für die Behandlung fehlerhafter Dateneingaben ist vorhanden

Datenbearbeitung: ¾

Eingesetzte Programme sollen Kontrollprozesse enthalten

¾

Die Programme müssen das Überschreiben falscher Daten erlauben, diese Korrekturen müssen genehmigt werden, Verantwortlicher für die Änderung muss identifiziert werden können.

¾

Datenfelder werden so benutzt, wie vorgesehen, dies wird auch überwacht

Datenausgabe: ¾

Die Ausgabedaten werden sowohl physikalisch als logisch nur den autorisierten Personen zur Verfügung gestellt

¾

Es wird ständig überprüft, ob die Ausgabedaten noch benötigt werden

¾

Es gibt eine klare Definition der Sicherheitsaspekte bei der Datenausgabe und Verteilung

¾

Die Vernichtung der Ausgabedaten ist von den Verantwortlichkeiten her klar geregelt

Beziehungen zu anderen Prozessen Data Management PO2, AI4, DS1, DS4 Betriebsanweisungen zum Daten-Management

DS13

Prozess PerformanceBerichte

ME1

Abb. 3-60 Beziehungsdiagramm - Data Management

137

3

3.4.12

COBIT-Prozessbeschreibung

DS12 Facility Management Kurzbeschreibung Ein weithin vergessenes Feld der IT sind die Einrichtungen, die von der IT benötigt werden, um ihre Leistungen auch erbringen zu können. Diese erschöpfen sich nicht nur in Form von Gebäuden, sondern auch den Inneneinrichtungen und Zuleitungen, wie z.B. Stromzuführungen, Trassen für das WAN u.a.m. Neben Sicherheitsproblemen, unter anderem unbefugte Zutritte in Gebäude, können diese Einrichtungen auch die mögliche Quelle einer Vielzahl anderer Arten von Störungen sein. Ziel Managen der Einrichtungen, um eine geeignete physikalische Umgebung herzustellen, welche die IT-Gerätschaften und das Personal gegen Menschen-verursachte oder natürliche Schadensereignisse schützt und dadurch verursachte Unterbrechungen des Geschäftsbetriebes minimiert. Aktivitäten Facility Management Strategie & Policies

Plan der physikalischen Sicherheit Facilities aufbauen, ändern entsprechend Anforderungen Standards und Abläufe implementieren Physikalische Sicherheitsmaßnahmen aufbauen Überwachung / Bewertung Nein

In Ordnung? Ja

Ende

Abb. 3-61 Flowchart - Facility Management

138

3.4

DS Delivery und Support

Eine Facility Management-Strategie und die damit zusammenhängenden Policies berücksichtigen Themen wie Gebäudeaufbau und -gestaltung, Sicherheitsaspekte, Zugangsmöglichkeiten und Zugangsschutz, Besucherregelungen, Arbeitsergonomie und Arbeitsschutz, Wartungsverträge und gesetzliche Regelungen. In Gebieten mit Umweltgefahren sind auch diese im Rahmen des Facility Managements in die Betachtung mit ein zu beziehen. Die aufzubauenden Prozesse müssen die Einhaltung der Policies überwachen und Eskalationsprozeduren bereitstellen. Facility Management hat immer auch mit dem Continuity Management zu tun, da ein Ausfall einer Einrichtung oft mit der Unterbrechung des Services einhergeht. Ein mögliches Bespiel ist hier Nichtbenutzbarkeit eines Raumes wegen Brand. Kontrolle Die Kontrollobjekte sind: ¾

Standortauswahl und Layout

¾

Physikalische Sicherheit

¾

Physischer Zutritt (Besucherregelungen)

¾

Vorkehrungen vor Umweltgefahren

¾

Management der Einrichtungen

Im Rahmen der Standortauswahl ist die Strategie der Geschäftsbereiche zu beachten. Die Sicherheitsüberlegungen in Bezug auf Naturgewalten und Menschen-verursachte Probleme sind zu berücksichtigen. Daneben gibt es unter Umständen gesetzliche Regelungen, die ins Kalkül einzubeziehen sind. Die Implementierung von Sicherheitsmaßnahmen bedingt, dass vorher eine Festlegung kritischer Bereiche stattfindet. Die Sicherheitseinrichtungen sind nach der Implementierung zu überwachen, um sicher zu stellen, dass diese nicht umgangen werden. Eine genaue Festlegung der Mitarbeiter und Personen, denen für die verschiedenen Sicherheitszonen Zutritte gewährt werden soll oder muss, ist zu designen. Ein formaler Autorisierungsprozess für die Zutritte ist zu entwickeln und zu implementieren. Naturgewalten machen nur einen kleinen Teil der Probleme aus, denen eine Unternehmung ausgesetzt ist. Trotzdem ist dies ein nicht unerhebliches Sicherheitsrisiko und bedarf deshalb einer genauen Betrachtung. Alle Bedrohungen und Schwachstellen sind zu erheben und mit geeigneten Maßnahmen unter Abwägung von Kosten und Nutzen zu reduzieren.

139

3

COBIT-Prozessbeschreibung Eine mögliche Policy zu den Einrichtungen kann folgende Elemente enthalten, die dann auf Einhaltung geprüft werden kann. ¾

Die Technikräume sind sicher zu gestalten, das heißt, es ist ein Zugangsschutz zu installieren und der Zugang darf nur autorisierten Personen gestattet sein.

¾

Die Besucher werden in geeigneter Weise kontrolliert, indem sie in eine Liste eingetragen werden, ein Besucherschild tragen müssen etc. Testen Sie dieses Verfahren in dem sie ohne eine Kennzeichnung durch die Einrichtung gehen. Wie ist die Reaktion?

¾

Die Rechnerräume sind separat von den Büroräumen zu halten, abzuschließen und Zutritt dürfen nur die berechtigten Personen haben.

¾

Gegenstände oder Waren, von denen eine Gefahr ausgehen kann, z.B. brandgefährliche Güter, dürfen nicht in den Einrichtungen gelagert werden. Denken Sie hier auch an Papierstapel.

¾

Zugangscodes sollen in regelmäßigen Abständen geändert werden. Hier ist ein Prozess einzurichten, der das sicher stellt.

Mögliche Prüfpunkte sind Compliance-Prüfungen mit den aufgestellten Policies. Weiterhin können folgende Themen geprüft werden. Sind Gebäudepläne und Notfalleinrichtungen und dazu passende Pläne aktuell und stimmen auch mit der Realität überein. Können die Notausgänge auch tatsächlich gefunden werden? Lassen sich deren Türen im Notfall auch wirklich öffnen? Wie viele Tests wurden durchgeführt, um die Compliance mit den Policies zu überprüfen? Wurden die Mitarbeiter in der Beachtung der Sicherheitseinrichtungen geschult und wie häufig geschah das? Beziehungen zu anderen Prozessen Facility Management PO2, PO9, AI3

Prozess PerformanceBerichte

ME1

Abb. 3-62 Beziehungsdiagramm - Facility Management

140

3.4

3.4.13

DS Delivery und Support

DS13 Operationsmanagement Kurzbeschreibung Die täglichen Aufgaben im Betrieb müssen organisiert und strukturiert werden. Die Mitarbeiter müssen klare Anweisungen erhalten, welche Aktivitäten zu welchen Zeiten durchgeführt werden sollen und müssen. Eine gute Planung ist dafür unerlässlich, um alle Bereiche und Aspekte abzudecken. Ziel Managen der Operations (des Betriebes) um zu gewährleisten, dass die wichtigen IT-Funktionen regelmäßig und korrekt ausgeführt werden. Aktivitäten Operationsmanagement Strategie & Policies

Betriebsplanung entwickeln und pflegen Operationale Abläufe entwickeln und pflegen Überwachen Infrastruktur / Prozesse, Probleme lösen Managen und sicherstellen physikalischer Output Änderungen an der IS durchführen Kontrolle der operationalen Prozeduren definieren und einführen Überwachung / Bewertung Nein

In Ordnung? Ja

Ende

Abb. 3-63 Flowchart - Operationsmanagement

141

3

COBIT-Prozessbeschreibung Operationale Abläufe sind in einem Plan festzuhalten, der die zeitliche Abfolge klärt und als Nachweis der Erledigung und der Vollständigkeit der Aufgaben dienen kann. Die physikalische und logische Trennung aller eingesetzten Bibliotheken und Umgebungen ist vorzusehen. Konkret heißt das, die Umgebungen von Test, Entwicklung und Produktion müssen getrennt voneinander existieren. Es ist ein geregeltes Verfahren im Rahmen des Änderungsverfahrens aufzusetzen, das ein geordnetes transparentes Verschieben der Programme zwischen den Bibliotheken und Umgebungen erlaubt. Die Aktivitäten im Bereich des Betriebes müssen den SLAs genügen. Eine Berichterstattung, die das nachweist, ist zu erstellen. Diese bezieht sich auf die Performancemessungen, beruhend auf den Betriebskennzahlen, abgeleitet aus den SLA-Anforderungen. Kontrolle Die Kontrollen des Betriebes sind wesentlich auf die Mitarbeiter gerichtet. Diese Mitarbeiter müssen den Betrieb sicherstellen und die aufgelisteten Ergebnisse erzeugen oder sich ihrer bedienen. ¾

Betriebsabläufe und Bedienungsanleitungen

¾

Job Scheduling

¾

IT-Infrastrukturüberwachung

¾

Sicherstellung spezieller Formulare und Output Devices

¾

Vorbeugende Wartung für Hardware

Das Personal des Betriebes muss die für sie relevanten Prozesse kennen und verstehen und natürlich nach diesen Prozessen handeln. Es ist also zu prüfen, inwieweit die Einhaltung dieser Prozesse gewährleistet ist und ob solche Ausnahmen als solche überhaupt erkannt und dokumentiert werden. Die Arbeiten sind in einem Arbeitsplan aufzuführen. Abweichungen von diesem Arbeitsplan sind ebenfalls zu dokumentieren, da sie auf die Qualität der Planung Hinweise geben, als auch Input für zukünftige Verbesserungen darstellen. Mögliche Verbesserungen sind systematisch zu erfassen und dem Management zur Verfügung zustellen, das daraus Aktionen ableitet. Eine Kontrolle bezieht sich auf beide Aspekte. Werden Performanceverbesserungen überhaupt systematisch erfasst und an das Management kommuniziert? Und führen diese Vorschläge auch zu messbaren Resultaten, setzt das Management diese Vorschläge überhaupt um oder berücksichtigt es diese?

142

3.4

DS Delivery und Support

Damit überhaupt konform gearbeitet werden kann, ist eine Betriebsdokumentation vollständig zur Verfügung zu stellen. Um operationale Betriebsabläufe zu bewerten, können die folgenden Messkriterien herangezogen werden: ¾

Prozentsatz der Hardwareassets, die in die vorbeugende Wartung eingeschlossen werden, um Störungen zu verhindern

¾

Prozentsatz der Arbeiten, die automatisiert wurden

¾

Häufigkeit der Überprüfung der operationalen Abläufe

¾

Anzahl der Incidents, die auf Grund von Abweichungen / Umgehungen von Arbeitsabläufen verursacht wurden

¾

Prozentsatz der Arbeiten, die nicht in der vereinbarten Zeit durchgeführt wurden

¾

Beeinflussung der Service Level-Einhaltung durch schlechte operationale Abläufe oder Incidents, die durch solche Abläufe verursacht wurden

Die Vielfalt operationaler Prozesse macht es schwierig an dieser Stelle detaillierte Kriterien zu nennen. Das gesamte Prozessmodell für die Betriebsführung, also operationalen Prozesse, ist mit KPIs (Key Performance-Indikatoren) zu hinterlegen und auf deren Grundlage eine Überwachung zu installieren. Beziehungen zu anderen Prozessen AI4, AI7 DS1, DS4, DS9, DS11

Operations Management Aufgezeichnete Incidents

AI6

Fehlerinformationen

AI6

Prozess PerformanceBerichte

ME1

Abb. 3-64 Beziehungsdiagramm - Operationsmanagement

143

3

COBIT-Prozessbeschreibung

3.5

ME Monitoring und Überwachung (Monitoring and Evaluation)

3.5.1

ME1 Überwachen und evaluieren der IT-Performance Kurzbeschreibung Zur Verbesserung und zur Prüfung der Einhaltung der Serviceziele (Performance) müssen verlässliche Prozesse eingerichtet sein, die sich immer weiter verbessern. Erst ein Monitoring, das sich auf die wirklichen wichtigen Testpunkte stützt, ist angemessen in Bezug auf den Aufwand und liefert die notwendigen Daten und erlaubt eine Anpassung der Prozesse an die Erfordernisse des Kunden unter Einhaltung der definierten Policies und Standards. Ziel Überwachen der IT-Performance um Transparenz und Verständnis über die IT-Kosten, Nutzen, Strategie in Übereinstimmung mit den Governance Anforderungen zu gewährleisten. Aktivitäten Anspruch an die Überwachung klären

Treiber in der IT für den Geschäftserfolges identifizieren Scorecards entwickeln Performance begutachten, berichten Verbesserungensmöglichkeiten entwicklen, anstoßen Überwachung / Bewertung Nein

In Ordnung? Ja

Ende

Abb. 3-65 Flowchart - Überwachen und evaluieren der IT-Performance

144

3.5

ME Monitoring und Überwachung (Monitoring and Evaluation) Für die gesamte IT sind zur Erreichung des Zieles Monitoringaktivitäten aufzusetzen. Im ersten Schritt bedeutet dies das Definieren, Pflegen und Kommunizieren von Überwachungspolicies (Monitoring Policies). Diese werden auf der Basis der definierten internen Kontrollpolicies entwickelt. Es sind relevante Performance-Indikatoren für die IT aufzusetzen und die Berichterstattung darüber zu implementieren. Die dazu notwendigen Hilfsmittel sind ¾

Scorecards über Leistungsindikatoren und Ergebniserreichung

¾

Kundenzufriedenheitsanalysen

¾

Management-Berichte

¾

Wissensdatenbank über historische Leistungsdaten

¾

Externes Benchmarking

Beim Ermitteln der Performanceindikatoren ist darauf zu achten, dass die Messungen auch adäquat für den jeweiligen Prozess sind. Es besteht sonst die Gefahr, den Prozess unter Umständen zu behindern oder Kosten ohne gegenstehenden Nutzen zu generieren. Die Daten aus der Prozessüberwachung müssen zeitlich so schnell zur Verfügung stehen, dass auch eine Reaktion erfolgen kann, die einen messbaren Effekt erzielt. Ist der Abstand zu groß, haben sich Bedingungen u.U. bereits so stark geändert, dass die eingeleiteten Maßnahmen kontraproduktiv wirken. Kontrolle Die definierten Kontrollobjekte sind ¾

Monitoring-Anspruch und Zielsetzung

¾

Definition und Sammlung von Monitoring-Daten

¾

Monitoring-Methoden

¾

Begutachtung der Performance

¾

Management-Berichterstattung

¾

Abhilfemaßnahmen

Es ist zu prüfen, ob für das Monitoring ein Framework aufgebaut wurde, das den Umfang, die Methode und die Prozesse festlegt, die für die Überwachung der IT-Performance gelten sollen. Das Framework muss sicherstellen, dass der Wertbeitrag der IT im Unternehmen gemessen und dargestellt wird, und es muss sich

145

3

COBIT-Prozessbeschreibung in das Performance-Management System des Gesamtunternehmens einbinden. Die definierten Monitoringdaten sollten u.a. die folgenden Punkte umfassen: ¾

Wertbeitrag der IT (aber nicht nur der finanzielle Beitrag)

¾

Leistungsaussagen in Bezug auf die Geschäftsstrategie und die IT-Planung

¾

Interne und externe Kundenzufriedenheit

¾

Zukunftsgerichtete Aktivitäten

Der Aufbau einer Balanced Scorecard ist in diesem Zusammenhang sinnvoll und sollte vorhanden sein. Dies kann als eine mögliche Methode verstanden werden. Die Leistungsfähigkeit des IT-Bereiches ist regelmäßig zu prüfen. Prüfprotokolle und deren Analyseergebnisse, sowie die dazu passenden Managementberichte müssen vorliegen. Diese Managementberichte sollten den Status der Aktivitäten enthalten, die angestoßen wurden, um Performanceprobleme zu beseitigen. Diese Aktivitäten sind in Form eines Programms zu führen, das alle Aktivitäten zusammenfasst und Doppelarbeiten vermeiden hilft. Ein konkretes Messergebnisse könnte hier in der Anzahl und dem Erfolg der Aktivitäten bestehen, die auf Grund der Monitoringanalysen gestartet wurden. Beziehungen zu anderen Prozessen PO5, PO10, AI6, DS1.. DS13, ME2, ME3, ME4

Überwachen und evaluieren IT-Performance Leistungsgrößen für die ITPlanung Wiederherstellungspläne

PO1,, PO2, DS1 APO4, PO8

Historische Risikoanalysen, Trendaussagen

PO9

Prozess PerformanceBerichte

ME2

Abb. 3-66 Beziehungsdiagramm – Überwachen und evaluieren der ITPerformance

146

3.5

3.5.2

ME Monitoring und Überwachung (Monitoring and Evaluation)

ME2 Überwachung und Begutachtung der internen Kontrollen Kurzbeschreibung Die im Prozess ME1 durchzuführenden Aktivitäten Überwachung und Evaluierung der IT-Performance erwartet korrekte Daten. Das interne Kontrollsystem muss eingerichtet werden. Es definiert die Ergebnisse der Eigenbeurteilung ebenso wie die der Fremdbeurteilungen. Die Erzielung von Verbesserungen darf dabei durch den Aufwand, der dadurch betrieben wird, nicht konterkariert werden. Zudem muss sichergestellt sein, dass die Prozesse auch wirklich die Kontrollpunkte gewählt haben, die fundierte Aussagen erlauben. Des weiteren stellt der Prozess die Einhaltung gesetzlicher und sonstiger Regelungen sicher. Ziel Begutachten der Angemessenheit der internen Kontrollmechanismen, um die internen Kontrollziele, die für die Prozesse aufgesetzt wurden, zu erreichen. Aktivitäten Überwachen und kontrollieren der Internen Kontrollaktivitäten

Selfassement überprüfen Unabhängige Audits, Reviews, Untersuchungen überwachen Überwachung der Prozesses der Kontrolle externer Dienstleister Überwachung des Prozesses zur Identifizierung und Beseitigung von Kontrollausnahmen Überwachung / Bewertung Nein

In Ordnung? Ja

Ende

Abb. 3-67 Flowchart - Überwachung und Begutachtung der internen Kontrollen

147

3

COBIT-Prozessbeschreibung Innerhalb des Prozesshauses der IT ist ein System von internen Kontrollen zu definieren. Die Effektivität dieser internen Kontrollen ist ebenfalls zu überprüfen, und entsprechende Berichte sind zu verfassen. Wie überall gibt es auch Ausnahmen, also Bereiche, auf die sich interne Kontrolle nicht erstreckt oder welche die interne Kontrolle entdeckt. Auch diese sind in den Berichten auszuführen. Die dauernde Überprüfung der internen Kontrollaktivitäten auf Effektivität und Effizienz kann dazu dienen, überbordende Kontrollaktivitäten zu vermeiden und ein Kontrollsystem zu etablieren, durch das die Prozesse sich selbst effektiv und effizient optimieren. Für diese internen Kontrollen sind Verantwortliche zu definieren, die Benchmarks durchführen und die Berichterstattung zur Effektivität und Effizienz der Kontrollmechanismen erstellen. Die Einhaltung von u.U. vorhandenen gesetzlichen Regeln zur Transparenz von Prozessen und der Unternehmens-internen Regelwerke ist eine weitere Aufgabe dieser Mitarbeiter. Kontrolle Die Kontrollen erstrecken sich auf: ¾

Monitoring interner Kontrollen

¾

Supervisor Review

¾

Ausnahmeberichte

¾

Kontrolle über die Eigenbegutachtung

¾

Begutachtung der internen Kontrolle durch Fremdbeurteilung

¾

Begutachtung der internen Kontrolle bei Lieferanten

¾

Abhilfemaßnahmen

Die Verfahren, Methoden und eingesetzten Hilfsmittel für die internen Kontrollen sind kontinuierlich zu überwachen und einem Benchmark zu unterziehen, um das Kontrollframework und die Kontrollumgebung zu optimieren. Treten Ausnahmen auf, so ist zu analysieren, woran das liegt, und es sind entsprechend Maßnahmen zu ergreifen. Es ist zu entscheiden, welche Ausnahmen zu tolerieren sind und welche nicht. Diese Entscheidungen sind in den Managementberichten zu dokumentieren. 148

3.5

ME Monitoring und Überwachung (Monitoring and Evaluation) Um Sicherheit bezüglich der erhobenen Daten zu erhalten sind die internen Kontrollmechanismen zu überprüfen. Dies kann auf zwei verschiedene Arten geschehen. Zum einen steht dafür die Eigenbewertung und zum anderen die Fremdbewertung zur Verfügung. In jedem Fall sind Eigenbewertungen regelmäßig durchzuführen, kontrolliert und nachgewiesen durch entsprechende Dokumentationen. Diese Eigenbewertung sollte sich auf das gesamte System der internen Kontrollen erstrecken. Sofern notwendig und gewünscht, kann diese Eigenbewertung durch die Fremdbewertung ergänzt werden. Fremdbewertung kann dabei sowohl durch eine interne Revisionsabteilung oder auch durch die Vergabe an ein Auditierungsunternehmen als sonstige geeignete Unternehmen durchgeführt werden. Zu achten ist in jedem Fall auf eine entsprechende Qualifikation der eingesetzten Mitarbeiter. Geeignet ist hier zum Beispiel ein Certified System Auditor (CISA). Da die Einhaltung gesetzlicher Auflagen sich nicht nur auf das eigene System erstreckt, ist die Begutachtung der internen Kontrollen auch auf die Zulieferer auszudehnen. Am besten geschieht dies durch den Nachweis externer Auditierungen bei dem Zulieferer. Beziehungen zu anderen Prozessen ME1

Überwachung und Begutachtung der internen Kontrollen Bericht über die Effektivität der internen Kontrollen

PO4, PO6, ME1, ME4

Abb. 3-68 Beziehungsdiagramm – Überwachung und Begutachtung der internen Kontrollen

149

3

3.5.3

COBIT-Prozessbeschreibung

ME3 Sicherstellung der Einhaltung gesetzlicher Vorschriften Kurzbeschreibung Ein Unternehmen muss sicherstellen, dass die gesetzlichen Regelungen und Auflagen eingehalten werden. Die Etablierung eines unabhängigen Reviewprozesses durch Überwachung dieser Einhaltung ist ein geeigneter Weg. Dieser muss die Themen, Unabhängigkeit der Auditoren, Auditplanung, Auditvorgehen, Ethiken und Standards, Berichtswesen und Folgeaktivitäten festlegen. Zu diesem Zweck sind alle anzuwendenden Regeln und Gesetze zu identifizieren und deren Einhaltung auf den verschiedenen Ebenen der IT-Organisation zu überprüfen. Ziel Sicherstellen der Einhaltung gesetzlicher Vorschriften, um die Risiken in diesem Bereich zu vermindern. Aktivitäten Definieren eines Prozesses zur Identifizierung gesetzlicher Anforderungen

Überprüfen der Einhaltung der IT-Aktivitäten mit Policies / Standards / Prozessen Liefern der Maßnahmen zur Ausrichtung der IT-Aktivitäten an den Policies / Standards Ausführung unabhängiger Bestätigung und Berichterstattung Berichterstattung der IT konform mit den Anforderungen der Geschäftsbereiche gestalten Überwachung / Bewertung Nein

In Ordnung? Ja

Ende

Abb. 3-69 Flowchart - Sicherstellung der Einhaltung gesetzlicher Vorschriften

150

3.5

ME Monitoring und Überwachung (Monitoring and Evaluation) Alle gesetzlichen Anforderungen müssen klar erfasst und dokumentiert sein, um Missverständnisse zu vermeiden. Die Auswirkungen dieser Regelungen auf die IT sind zu analysieren und deren Einhaltung auf allen Ebenen der IT zu prüfen. Im Kern geht es darum, die Risiken, die mit der fehlenden Einhaltung gesetzlicher Regeln verbunden sind, zu minimieren. Diese Risiken können von zusätzlichen Kosten in Form von Strafen, Auflagen bis hin zur Untersagung des Geschäftsbetriebes reichen. Es ist daher zwingen, den Prozess so aufzusetzen, dass sowohl eine schnelle Erkennung solcher Risiken oder Noncompliance, als auch deren Beseitigung möglich wird. Die Dauer zwischen den Prüfungen ist daher entsprechend kurz zu wählen. Kontrolle Es sind fünf detaillierte Kontrollziele definiert. ¾

Identifizierung gesetzlicher Auflagen mit einem Bezug zur IT

¾

Optimierung der Reaktion auf gesetzliche Anforderungen

¾

Überprüfung der Vereinbarkeit mit gesetzlichen Anforderungen

¾

Gewährleistung / Sicherheit der Einhaltung gesetzlicher Vorschriften

¾

Integrierte Berichterstattung

Es ist ein Prozess zur zeitnahen Erfassung der gesetzlichen Anforderungen in Bezug auf die verwendete Informationen, IT Delivery, inklusive Zulieferer, und der IT-Organisation festzulegen. Der Prozess hat zu prüfen, ob die zeitnahe Erfassung gewährleistet wird. Dazu kann die Zeit zwischen der Veröffentlichung eines neuen Gesetzes und der dokumentierten Überprüfung durch die IT-Organisation herangezogen werden. Die Anforderungen sollten folgende Themen berücksichtigen: elektronischer Handel, Privatsphäre, Interne Kontrollen, Finanzielle Berichte, Schutz geistigen Eigentums, Gesundheit und Sicherheit sowie Industriespezifische Regularien. Die Reaktion auf neue Anforderungen kann immer weiter verbessert werden. Diese Verbesserungen münden in Änderungen der Prozesse, Standards und Prozeduren und Policies.

151

3

COBIT-Prozessbeschreibung Die Vereinbarungen zur Erlangung einer unabhängigen Bestätigung sind auf Eignung und Umfang zu prüfen. Bei der Durchführung muss das Management die Leistungsfähigkeit, also die Ergebnisse des Lieferanten prüfen. Hier ist wichtig, ob er die vorher definierten Eckpunkte einhält und den erwarteten Umfang der Aktivitäten liefert. Dazu ist es notwendig, dass die den Prozess durchführenden Personen auch die notwendigen Fertigkeiten und Fähigkeiten mitbringen. Beziehungen zu anderen Prozessen Gesetzgebung des zuständigen Staates

Sicherstellung der Einhaltung gesetzlicher Vorschriften Gesetzliche Anforderungen für den IT-Betrieb

PO4, ME1

Bericht über die Einhaltung der gesetzl. Anforderungen

ME1

Abb. 3-70 Beziehungsdiagramm – Sicherstellung der Einhaltung gesetzlicher Vorschriften

152

3.5

3.5.4

ME Monitoring und Überwachung (Monitoring and Evaluation)

ME4 Sorgen für IT-Governance Kurzbeschreibung IT-Governance entsteht nicht von alleine. Es bedarf zunächst der Corporate Governance der Geschäftsbereiche, um eine wirkliche Ausrichtung an den Geschäftszielen zu ermöglichen. Dieser Prozess muss das IT-Governance Framework liefern, welches die Komponenten Organisationsstrukturen, Prozesse, Führungskultur und Gremien, Rollenmodelle und Verantwortlichkeiten definiert. Dies soll sicherstellen, dass die Investitionen in die IT die Geschäftsziele und Geschäftsstrategien unterstützt. Ziel Liefern von IT-Governance durch Verzahnung und Ausrichtung der IT an den Strategien des Geschäftes und Einhaltung der Gesetze und sonstiger vertraglichen Verpflichtungen. Aktivitäten Aufsichtsgremien und Strukturen für die ITAktivitäten etablieren

Definieren, Ausrichten, Pflegen und Kommunizieren der ITPerformance, Strategie, Risiken in Bezug zur Geschäftsstrategie Anfordern einer regelmäßigen unabhängigen Überprüfung der Einhaltung von Policies/Standards/ sonstigen Anforderungen Verbesesrungen durch die externen Audits anstoßen, überwachen

IT-Governance Bericht erstellen

Überwachung / Bewertung Nein

In Ordnung? Ja

Ende

Abb. 3-71 Flowchart - Sorgen für IT-Governance

153

3

COBIT-Prozessbeschreibung IT-Governance muss die Übersicht und die Führung der gesamten IT-Organisation regeln und durchführen. Über die Einhaltung der aufgestellten Regelungen ist ein Bericht für die Aufsichtsgremien anzufertigen. Die Aufsicht umfasst alle Prozesse inklusive der Überwachung des Prozesses Kontrollieren und Evaluieren der internen Kontrollen. Dieser Prozess stellt damit das letzte Glied in der Kette der Kontroll- und Führungsinstrumente dar. IT-Governance hat vor allem dafür zu sorgen, dass ¾

das Prozessframework, das wesentlich die Performance bestimmt, permanent verbessert wird

¾

die IT-Prozesse an dem Geschäftsanforderungen ausgerichtet sind

¾

die IT-Strategie tatsächlich der Geschäftsstrategie folgt

¾

der Nutzen von IT auch im Geschäft sichtbar wird, d.h. ein Wertbeitrag der IT erzeugt wird

IT-

Der Adressat für diesen Prozess liegt wesentlich außerhalb der IT, nämlich in den Aufsichtsgremien. Diese verarbeiten den Bericht zur IT-Governance und binden diesen in die Corporate Governance ein. Unabhängige Audits zur IT-Governance unterstützen und sichern die Glaubwürdigkeit der erreichten Ziele ab. Kontrolle Die Kontrollobjekte ergeben sich durch die Zielsetzungen des ITGovernance. ¾

Etablierung eines IT-Governance Frameworks

¾

Strategische Ausrichtung

¾

Wertbeitrag

¾

Ressourcen Management

¾

Risiko-Management

¾

Performance Management

¾

Unabhängige Versicherung

Ein IT-Governance Framework enthält die Elemente, Führung, Prozesse, Rollen und Verantwortlichkeiten, Anforderungen an die Informationen, organisatorische Strukturen. Es muss so aufgebaut sein, dass es einen klaren Bezug zwischen der Strategie des Gesamtunternehmens, seinen Investitionen und Projekten 154

3.5

ME Monitoring und Überwachung (Monitoring and Evaluation) zur IT herstellt. Die Verantwortlichkeiten sind so stringent festzulegen, dass keine Brüche in der internen Kontrolle auftreten. Das Framework selber hat sich an dem Corporate Governance Framework zu orientieren und darf diesem nicht entgegenstehen. Als Messkriterium kann die Durchgängigkeit der Prozesse untersucht werden. Die strategische Ausrichtung der IT ist ohne aktive Beteiligung durch das Business nicht möglich. Nur mit einem guten Verständnis des Geschäftes für die IT, also dem Verständnis ihrer Möglichkeiten, ihrer Leistungsfähigkeit und der eingesetzten Technologie, kann es gelingen maximalen Nutzen aus der IT zu ziehen. Umgekehrt muss auch die IT ein Verständnis für Aufgaben und Anforderungen der Geschäftsbereiche entwickeln. ITGovernance muss dieses Verständnis in die IT-Organisation hinein propagieren. Ein Strategiegremium ist zu entwickeln und zu implementieren, um diese Aufgabe zu leisten. Zur Kontrolle, ob die IT-Governance auch berücksichtigt wird, kann die Agenda dieses Meetings begutachtet werden. Hier sollte das Topic „ITGovernance“ auf jeden Fall auftauchen. Die Zufriedenheit der Stakeholder und die Häufigkeit der Berichte sind ebenfalls ein guter Indikator für die Durchführung des Prozesses. IT-Investitionen sind vom Geschäftswertbeitrag her zu entwickeln und zu betrachten. Die Fachbereiche müssen verstehen, was dieser Beitrag oder auch Nutzen ist und welche Anstrengungen und Aufwände die IT leisten muss, um diesen Nutzen zu erzeugen. Eine aktives Management für die Erzeugung dieses Mehrwertes ist unumgänglich und sollte von den Fachbereichen ausgehen. Diese sollten die Verantwortung für die geschäftsgetriebenen IT-Investitionen tragen. Die IT sorgt dann dafür, dass die IT-Services und Fähigkeiten optimal zugeliefert werden. Dabei ist es ebenso Aufgabe der IT die Standardisierung so weit zu treiben, dass die Kosten und die Komplexität weitgehend reduziert werden. Die IT muss ausreichende und geeignete Ressourcen an Maschinen und an Personal vorhalten, um ihre Aufgaben in der Gegenwart und in Zukunft erledigen zu können. Die Ressourcenplanung muss sich also an den gegenwärtigen und den zukünftigen Geschäftsanforderungen ausrichten. Das Management muss daher klare Richtlinien und Policies entwickeln für Material und Personal, um dieses zu erfüllen, und die Architektur geeignet zu unterstützen.

155

3

COBIT-Prozessbeschreibung Risikomanagement ist eine der vordringlichsten GovernanceAufgaben. Die Nutzung der IT ist, wie die jeder technischen Einrichtung, mit immanenten Risiken behaftet. Die Fachbereiche können mit bestimmten Risiken leben und mit anderen nicht. Es gilt also, sich diese Unterscheidung klar zu machen und auch zu kommunizieren. Mit den Fachbereichen ist ein Risikomanagementplan zu entwickeln. Die Risiken müssen regelmäßig geprüft, neue Risiken aufgenommen und Gegenmaßnahmen aufgesetzt werden. Das Management sollte besonderes Augenmerk auf die Risiken im Bereich Fehler in den internen Kontrollen und Einfluss solcher Fehler auf die geschäftliche Abwicklung legen. Die Leistungsfähigkeit des IT-Bereiches muss an die Aufsichtsgremien berichtet werden. Im Rahmen dieses Prozesses sind die Berichte zu konsolidieren und aufzubereiten. Ein Abgleich mit den Geschäftszielen wird vorgenommen, Abweichungen werden erläutert und geklärt. Um für alle Beteiligten Sicherheit zu gewinnen, dass das gesamte System performant und im Sinne des Unternehmens arbeitet, kann ein unabhängiges Audit herangezogen werden. Die Ergebnisse sind zu prüfen und Bericht zu erstatten. Beziehungen zu anderen Prozessen PO4, PO5, PO9, ME2, ME3

Sorgen für IT Governance Prozess Framework Verbesserungen Bericht zum IT Governance-Status

PO4 PO1, ME1

Erwarteter Geschäfsnutzen für IT-induzierte Investments

PO5

IT-Strategie des Kerngeschäftes

PO1

Anfälligkeit des Geschäftsbetriebes für IT-Risiken

PO9

Abb. 3-72 Beziehungsdiagramm - Sorgen für IT-Governance

156

4

IT-Governance-Implementierung In dem Kapitel wird zunächst erläutert, was es bedeutet, COBIT einzuführen und welche Implikationen damit verbunden sind. Danach wird die Methodik bei der Einführung erläutert und zum Schluss auf die verfügbaren Tools eingegangen.

4.1

Einführung von COBIT COBIT ist als ein Mittel zur Auditierung von Prozessen entworfen worden. Es legt daher besonderes Augenmerk auf die Kontrollmechanismen. Jede IT-Organisation hat Prozesse zur Abarbeitung der Aufgaben. Die Frage erhebt sich, in welchen Ausmaß diese Prozess schriftlich fixiert, wiederholbar oder auch selbstverbessernd sind. Mit anderen Worten, in welchem Reifegrad befinden sich die Prozesse. Nicht jede Organisation will sich bis zum höchsten Reifegrad steigern, denn dieses kann mit unvertretbar hohen Kosten verbunden oder für die Organisation ganz unangemessen sein. Die erste Frage, bei der Einführung lautet daher auch, welchen Reifegrad möchte ich überhaupt erreichen, welcher ist für mich angemessen? Kontrollstrukturen können ganz unabhängig von der gewählten Prozessstruktur aufgebaut werden. Diese Kontrollstrukturen zielen dann auf die einzelnen Prozessergebnisse und fragen in erster Linie nicht, ob ein Prozess im COBIT-Sinne etabliert ist. Die COBIT-Prozessstruktur dient in diesen Fällen dazu, die vorhandenen Prozesse zu strukturieren und deren Ergebnisse zu bewerten. Trotzdem bedeutet schon diese Einführung erhebliche Anpassungen und Änderungen. Das, was vorher so lief, wird jetzt transparent und kontrollierbar gemacht. Das schafft Ängste und schürt Misstrauen, dem begegnet werden muss, soll die Einführung nicht scheitern. COBIT als ein Mittel zum Aufbau einer Kontrollstruktur kann daher als ein Mittel zur Einführung von IT-Governance gesehen werden, denn es schafft Transparenz, liefert Handlungsfelder und führt zu einer insgesamt besseren Führung des IT-Betriebes. 157

4

4.2

IT-Governance-Implementierung

Methodisches Vorgehen Die Einführung von IT-Governance in eine Organisation bedeutet eine erhebliche Anstrengung, weil diese immer mit einer organisatorischen Veränderung verbunden ist. Die Mitarbeiter müssen neue ungewohnte Arbeitsweisen und Techniken lernen und sich mit ihnen vertraut machen. Zudem reicht es nicht aus, Governance auf einer oberen Ebene zu definieren und einzuführen, denn die Governance muss das ganze Unternehmen durchdringen. Einzuführende Gremien, Führungsstrukturen und Verantwortlichkeiten sind nicht dem oberen Management vorbehalten, sondern müssen bis auf die operative Mitarbeiterebene heruntergebrochen werden. Die gesamte Firma ist also betroffen. Die Durchführung solcher Änderungen kann nur im Rahmen eines korrekt geführten Change-Projektes erfolgen. Ein solches Projekt kann in den folgenden Phasen durchgeführt werden:

158

1.

Vorbereitung und Situationsanalyse Definieren der Stakeholder

2.

Ist-Zustandsanalyse Prozess-Analyse Risiko-Analyse Healthcheck

3.

Strategie und Sollzustand Reifegradmodellentwicklung GAP-Analyse (Was fehlt zum Soll?)

4.

Transition-Strategie und Plan Auswirkungsanalyse Geschäftliche Relevanz Projektplan für die Transition

5.

Durchführung des Plans der Transition Erstellen der Metriken, Arbeitsanweisungen, etc Verantwortliche benennen Bewusstsein für das Vorhaben aufbauen Personal schulen Prozesse implementieren Projektstatusberichte erstellen und verteilen

6.

Projektbegutachtung Erfolgsfaktoren des Projektes festlegen Berichten an Hand der Kriterien und des Statusses

4.2

Methodisches Vorgehen

Diese Auflistung ist für ein derart komplexes Changeprojekt natürlich nicht vollständig. Bitte ziehen Sie für eine vollständige Definition eines solchen Vorhabens professionelle Projektmanagementmethoden (z.B. Prince2) zu Rate und berücksichtigen Sie, dass es nicht nur darauf ankommt, die Arbeiten durchzuführen und die definierten Arbeitsergebnisse des Projektes zu erzeugen, sondern dass der Erfolg in hohem Maße von der Berücksichtung der Stakeholder, den kulturellen Aspekten, den unausgesprochenen Erwartungen der Beteiligten und den spezifischen Bedingungen in der Firma abhängt. Governance-Modelle werden oft in verschiedene Ebenen unterteilt. Die COBIT-Prozesse oder noch besser deren Kontrollstrukturen gelten für alle Ebenen und müssen auf allen Ebenen in entsprechender Form etabliert werden. Die oberste Ebene ist diejenige, die für die generellen Richtlinien und Ausrichtung der Organisation zuständig ist. Die darunter liegende Ebene, auch oft das Mittlere Management genannt, sorgt für die operative Ausführung der Richtlinien und Umsetzung der Ausrichtung in die betriebliche Praxis. Die Arbeitsebene schließlich führt die Tätigkeiten letztendlich aus. Ein gutes Governance-Modell, wie COBIT, berücksichtigt alle Ebenen. Auf der oberen Ebene ist das Governance-Modell häufig von Gremien gekennzeichnet und den dazu passenden Entscheidungsstrukturen. Die Gremien, die in den verschiedenen IT-Organisationen eingerichtet werden differieren sehr stark. Eine kleine Auswahl zeigt die Liste. COBIT selbst kennt diese Gremienstruktur nicht, macht also diesbezüglich keine Angaben. ¾

IT-Strategie & Ziele

¾

Informationsarchitektur & Technologie

¾

Portfolio-Management

¾

IT Investment-Planung

¾

IT-Controlling & Risiko-Management

¾

Prozess & Qualitätsmanagement

¾

Skill & Personal Management

¾

IT-Organisation & Beziehungen.

Alle Themen haben mit der Tatsache zu tun, dass das ITBusiness an dem Kerngeschäft ausgerichtet werden muss. Es gibt daneben Bedingungen, die spezifische Struktur der Gremien und Entscheidungen erfordern. Es sind dies z.B. Outsourcing159

4

IT-Governance-Implementierung Geschäfte. Betrachten wir die Outsourcer-Seite, dann ist darauf zu achten, in der Gremienstruktur die Kunden einzubinden und zwar der Gestalt, dass nicht immer alles geändert werden muss, wenn ein Kunde hinzukommt. Die andere Seite, also die Kundenseite muss ihren Dienstleister überwachen, und daher darauf achten, dass sie in die wesentlichen Gremien eingebunden ist. Nur dann hat der Kunde die vollständige Kontrolle über die Zulieferungen des IT Outsourcers. Es ist unmöglich, sich aus diesen Gremien herauszuhalten und trotzdem die Kontrolle zu behalten. Diese Aufgabe wird bei der Herauslösung der IT vielfach unterschätzt. Die Übertragung oder Perpetuierung der Führungsstrukturen in alle Ebenen der Organisation ist notwendig, um eine optimale Kontrolle der Ausrichtung der Gesamtorganisation zu gewährleisten. Hier ist der Aufbau einer prozessorientierten Organisation ein probates Mittel, Effizienz und Effektivität der Organisation zu steigern und damit maximalen Nutzen aus dem IT-Investment zu ziehen.

4.3

Verfügbare Tools COBIT hält eine Reihe von Tools bereit, die genutzt werden können. ¾

Das Implementation Tool Set enthält die Diagnostics und das Self Assessment

¾

Die Management Guidelines enthalten das Reifegradmodell basierend auf CMM

COBIT-Management Advisor, ein kommerzielles Produkt von Methodware, enthält eine Sammlung von kritischen Erfolgsfaktoren, Zielerreichungsfaktoren, Schlüsselerfolgsfaktoren und die Reifegrade für jeden der 34 COBIT IT-Prozesse. Das Produkt erlaubt es, einen IT-Prozess zu bewerten, und liefert eine bessere Unterstützung, um wesentliche IT-Risken zu erkennen und zu reduzieren. Royal Philips Electronics entwickelte das Process Service Tool weiter zu einem internen Benchmark zur Reifegradmessung seiner IT-Prozesse. Dieser Benchmark beruht auf mehr als 150 Organisationen (Unternehmensteile, die Serviceprozesse haben). Ein anderes verfügbares Produkt ist EZCOBIT. Dieses Produkt ist frei zugänglich und kann von der Website der ISACA (Südafrika Teil) heruntergeladen werden. Dieses Tool kann bei der Ein160

4.3

Verfügbare Tools

schätzung und Bewertung der IT-Prozesse in Bezug auf die COBIT-Prozesse unterstützen. Verschiedene Firmen arbeiten derzeit an Einführungstools für die Implementierung von COBIT-Prozessen. Andere Firmen arbeiten an der Toolunterstützung für Healthchecks und Awareness oder erweitern die Reifegradmethodik auf die originären Geschäftsprozesse als ersten Schritt hin zu einer Corporate Governance. ISACA selbst bietet eine einstündige Präsentation als Überblick über COBIT an. Diese Präsentation wird ohne Gebühren angeboten und ist als Einstieg in das PSS (Professional Seminar Series Program). ISACA bietet ebenfalls einen eintägigen Kurs an, in dem das COBIT allgemein, das Framework, die detaillierten Control Objectives, die Audit Guidelines und die Management Guidelines besprochen werden. Darauf aufbauend wird ein Kurs angeboten, der in die strukturierte Implementierung von COBIT einführt. Dieser Kurs stellt eine allgemeine Roadmap zur Einführung von COBIT in spezifischen Organisationen vor. Abgesehen von ISACA bieten Trainer überall in der Welt Kurse zu COBIT an, die auf der speziellen Erfahrung dieser Trainer beruhen. Es wird erwartet, dass auf dem Markt mehr und mehr Produkte rund um COBIT entstehen werden.

161

5

COBIT-Publikationen und Literaturverzeichnis An dieser Stelle möchten wir einen kurzen Überblick über die vorhandenen Publikationen zu COBIT geben. Dieser Überblick kann nicht vollständig sein, denn es gibt laufend Neuentwicklungen.

5.1

Struktur der Publikationen Derzeit besteht das COBIT (Version 4) aus den folgenden Büchern (alle in Englisch) 9

Board Briefings

9

Management Guidelines

9

COBIT Framework

9

Control Objectives

9

IT Assuance Guide

9

IT Control Objectives for SOA

9

IT Governacne Implementation Guide

9

COBIT Quickstart

9

COBIT Security Baseline

Board Briefings on IT Governance 2nd Edition Management Guidelines

CobiT Framework

IT Assurance Guide

IT Governance Implementation Guide

Control Obejctives

IT Control Objectives for SOA

CobiT Quickstart

Control Practices

CobiT Security Baseline

Abb. 5-1 Veröffentlichungen zu COBIT

163

5

COBIT-Publikationen und Literaturverzeichnis Da sich die Veröffentlichungen zu COBIT sehr schnell ändern und fortwährend neue hinzukommen, wurde hier auf eine umfassende Zusammenstellung verzichtet. Bitte schauen Sie für eine vollständige Auflistung auf die COBIT Homepage. Zum besseren Verständnis der einzelnen Veröffentlichungen sind im Folgenden die Inhalte der einzelnen Publikationen kurz dargestellt.

5.1.1

Board Briefings Diese Abhandlung liefert Basisinformationen zu COBIT. In einem kurzen Überblick wird das Framework vorgestellt und die Einbindung der IT-Governance in den Gesamtrahmen der Governance eines Unternehmens erläutert. Die Definitionen zu Kontrolle, Kontrollzielen und IT-Governance werden erläutert. Dies soll dem oberen Management helfen, seine Rolle im Gesamtzusammenhang zu verstehen und auszufüllen.

5.1.2

Framework und Control Objectives Die Publikationen sind eng miteinander verbunden. Das Buch COBIT Control Objectives liefert über das Framework hinaus einen detaillierteren Blick auf die Kontrollziele. Auf Grund der unterschiedlichen Tiefe sind auch die Adressaten der Bücher unterschiedlich. Das Framework ist eher für das Senior Management geschrieben, wohingegen die Control Objectives eher für das Mittlere Management gedacht sind.

5.1.3

Management Guidelines Die Management Guidelines geben Hinweise auf die Art und Weise, in der das Management die IT-Aktivitäten führen soll. Das Ziel ist es, eine Balance zwischen Risiko und Geschäftserfolg herzustellen. Um das durchzuführen, muss das Management die wichtigsten Aktivitäten identifizieren, Ziele dafür setzen, Fortschritte messen gegenüber den Zielen und einschätzen, wie gut die Prozesse arbeiten. Die Basis bilden die Ziele, die für die ITGovernance zunächst einmal generell gelten. Diese sind: Die IT ist am Geschäft ausgerichtet und unterstützt das Geschäft und maximiert den Profit IT-Ressourcen werden verantwortungsvoll genutzt Mit der IT-Nutzung verbundene Risiken werden angemessen behandelt

164

5.1

Struktur der Publikationen

In der Ausrichtung an diesen Zielen ist ein Kontrollzyklus einzurichten entsprechend dem PDCA-Zyklus, wie er in der folgenden Abbildung zu sehen ist. Die Geschäftsziele bilden den wesentlichen Input für den Verbesserungszyklus.

Geschäftsziele

Plan

Act

Do

Check Abb. 5-2 Abhängigkeit von Geschäftszielen

Für jeden der 34 COBIT-Prozesse wird eine Anzahl von Elementen beschrieben: ¾

Prozess-Identifizierung

¾

Zielaussage für den Prozess

¾

IT-Ressourcen, mit einer Angabe der Relevanz für den Prozess

¾

Informationskriterium, mit einer Angabe der relativen Wichtigkeit

¾

Kritischer Erfolgsfaktor (KEF), Faktoren, die die wichtigsten Management-orientierten Ergebnisse repräsentieren,

165

5

COBIT-Publikationen und Literaturverzeichnis die benötigt werden, um Kontrolle über den IT-Prozess zu haben

5.1.4

¾

Key Goal Indicators (KGI), Indikatoren, die Mittel definieren in Hinsicht auf die Informationsqualitätskriterien, die dem Management helfen (im Nachhinein) ob ein ITProzess die an ihn vom Business gesetzten Erwartungen erfüllt

¾

Key Performance Indicators, Hauptindikatoren, die anzeigen, ob ein Prozess die vorgegebenen Ziele erreicht

¾

Reifegradmodell, dies ist ein Instrument, um den aktuellen Zustand einer Organisation festzustellen. Das Modell kann genutzt werden, um Ziele für die Organisation festzulegen. Nicht immer ist es notwendig sich das Ziel Best in Class zu setzen.

IT Assurance Guide Die Audit Guidelines erlauben es, die IT-Prozesse gegen detaillierte Kontrollziele abzugleichen mit dem Ziel, dem Management Unterstützung für die Verbesserung der Prozesse zu geben. Die Erstellung der Audit Pläne, die sich an dem COBIT Framework und den Kontrollzielen orientieren, ist ein wesentliches Element. Dies erlaubt es dem Auditor, seine Schlussfolgerunge zu untermauern, denn COBIT ist eine auf den Best Practice Statements beruhender Ansatz zur Ableitung der Beurteilungskriterien. Zur weitergehenden Betrachtung sei an dieser Stelle auf die Literatur verwiesen, unbeschadet der folgenden Hinweise. ¾

Audit Guidelines sind nicht ausreichend, um einen vollständigen Plan für ein Audit zu erstellen, denn dieser hängt wesentlich von der Vorgeschichte ab

¾

Die Guidelines können auch nicht als Schulungsmaterial verwendet werden, auch wenn sie eine Grundlage für die Auditierung darstellen

¾

Die Automatisierung der Audits ist ebenfalls nicht Gegenstand der Guidelines. Hinweise dazu werden Sie vergebens suchen.

Es sind immer die gleichen Schritte, die bei einer Auditierung durchgeführt werden sollten:

166

5.1

5.1.5

Struktur der Publikationen

¾

Ein Verständnis für die Risiken, die mit den Geschäftsanforderungen und den relevanten Kontrollmitteln zu tun haben ist aufzubauen

¾

Die Angepasstheit der eingesetzten Kontrollen ist zu ermitteln

¾

Überprüfung der eingesetzten Kontrollen auf Konformität mit der Beschreibung der Kontrollen und ob diese kontinuierlich und abgestimmt durchgeführt werden.

¾

Erhärten die Risiken, die in der Nichterfüllung der Kontrollziele liegen. Es sind analytische Techniken anzuwenden oder andere Beratungsalternativen.

IT Control Objectives for SOA Die Forderung nach SOA-Konformität (Sarbanes Ochsley Act) von Organisation und damit auch der IT-Organisationen nimmt immer mehr zu. COBIT hat darauf reagiert, indem Kontrollziele aufgestellt wurden, die es erlauben eine IT-Organisation SOAkompatibel zu führen.

5.1.6

Implementation Guide Organisationen, die COBIT bereits schnell und erfolgreich eingeführt und verwendet haben, stellen ihre Erfahrungen zur Verfügung. Diese Schriften sind für IT-Direktoren (CIOs), Auditoren, mittleres IT-Management und sonstigen IT Managern gedacht. Das Toolset beschreibt einen Weg, um COBIT in Organisationen einzuführen, und berücksichtigt dabei: ¾

Stakeholder

¾

Gründe, warum ein Unternehmen COBIT einführen sollte

¾

Den Umfang und die Begrenzungen von COBIT

Es enthält des Weiteren Tools um die Analyse einer ITOrganisation in Hinblick auf die Kontrollen zu unterstützen. Die Tools sind: ¾

IT-Governance Self Asessment

¾

Management IT-IS concerned with diagnostic (betreffend Diagnostik)

¾

IT Control Diagnostic

¾

COBIT Quick Start 167

5

5.2

COBIT-Publikationen und Literaturverzeichnis

Weitere Publikationen Auf den Internetseiten des IT-Governance Instituts können Sie weitere Publikationen finden. Die folgende Liste gibt Ihnen einen Hinweis auf Seiten, die eventuell nützliche Informationen enthalten. Da das Internet einem schnellen Wandel unterliegt, kann für die Richtigkeit der Adressen nicht garantiert werden. COBIT Online

http://www.controlit.org/

ISCA

http://www.isaca.org

IT-Governance Portal

http://www.itgi.org

EZCOBIT

http://www.COBIT.co.za

Balanced Scorecard

http://www.balancedscorecard.org

CMM

http://www.sei.cmu.edu/cmm

CMMI

http://.sei.cmu.edu/cmmi

Auf den Internetseiten des Governance Institutes können Sie die folgenden Broschüren und Texte herunterladen:

168

¾

IT Control Practice Statements

¾

Board Briefings on IT-Governance

¾

IT-Governance Executive Summary

¾

IT Strategy Committee

¾

Information Security Governance

¾

Optimising Value Creation from IT Investments

¾

Information Risks - Whose Business Are They?

Glossar Abkürzung/Begriff

Erläuterung

BNQP

Baldrige National Quality Program

BS

British Standard

BSC

Balanced Score Card

CCTA

Central Computer and Telecommunication Agency

CEO

Chief Executive Officer

CI

Configuration Item

CIMA

Chartered Institute of Management Accountants

CIO

Chief Information Officer

CISA

Certified System Auditor

CMM

Capability Maturity Model

CMMI

Capability Maturity Model Initiative

COBIT

Control Objektives for IT and related Technology

COSO

Committee of Sponsoring Organizations of the Treadway Commission

EFQM

European Foundation for Quality Management

ERM

Enterprise Risk Management

HW

Hardware

ICT

Information & Communication Technology

IEC

International Electrontechnical Commission

IS

Informationssystem

ISACA

Information Systems Audit and Control Association

ISACF

Information Systems Audit and Control Foundation (heute ITGI)

ISO

International Standardisation Organisation

IT

Informationstechnologie

169

Glossar Abkürzung/Begriff

Erläuterung

ITGI

IT-Governance Institute

ITIL

IT Infrastructure Library

ITS

Information & Technology Service

KEF

Kritischer Erfolgsfaktor

KGI

Key Goal Indicator

KPI

Key Performance Indicator

OECD

Organisation for Economic Cooperation and Development

OGC

Office of Government Commerce

PDCA

Plan Do Check Act Zyklus

PIR

Project Implementation Review

Prince2

Projektmanagementmethodik, Voraussetzung für Projekte im öffentlichen Umfeld in UK

PSS

Professional Service Series

ROI

Return of Investment

SEI

Software Entwicklungsinstitut

SLA

Service Level Agreement

SOA

Sarbanes Oxley Act

SPF

Single Point of Failure

Spice

Software Process Improvement and Capability Determination

SW

Software

TOE

Targets of Evaluation

WAN

Wide Area Network

170

Schlagwortverzeichnis

A Abnahmemethoden 81 Anwenderbedürfnisse 83 Applikationssoftware 86 Arbeitsergonomie 139 Arbeitsplan 142 Arbeitsschutz 139 Architektur 90 Auditplanung 150 Autorisierungsprozess 139

B Backup 136 Balanced Score Card 21 Benchmark 148 Benchmarking 50 Benutzerzufriedenheit 128 Besucherregelungen 139 Betriebshandbücher 93 Betriebskennzahlen 142 BNQP 14 BS 5750 15 Business Continuity 115

C Capability Maturity Model 17 CCTA 9 Change Management 90 Change Projekt 158 CIMA 3, 12 CISA 149 CMMISEI 18 Cobit 2 Common Criteria 20

Compliance 140 Continuity 139 Continuity Management 114 COSO 7

D Datastorage 136 Datenausgabe 137 Datenbearbeitung 137 Dateneingabe 137 Datenmodell 54 Datenträger 135 Datenvorbereitung 136

E earned value 79 EFQM-Modell 16 Endanwender 127 Erdbeben 76 ERM 8 Eskalationsprozeduren 113 European Quality Award 15 EZCOBIT 160, 168

F Facility Management 139 Fertigungstiefe 31, 109 Firewalls 118 First Level Support 127 Führungsstrukturen 158

G Gebäudeaufbau 139 Gebrauchsanweisungen 92

171

Schlagwortverzeichnis Geschäftsrisiken 77 Gremien 158

H Healthceck 158 Healthcheck 161 Helpdesk 127

I IKS 3, 45 Incidents 132 Informationskriterium 165 Input 45 Integrität 36, 135 ISACA 12, 161 ISACF 12 ISO 15 ISO 17799 15 IT Budgets 120 IT Control Diagnostic 167 IT Delivery 10 IT Support 10 ITIL 1

J

Kostentreiber 120 Kostenzuweisungsmethode 121 KPI 143 Kritischer Erfolgsfaktor 165 kryptographischen Methoden 118 Kundenvereinbarung 105

L Lieferanten 108 Life Cycle Methodology 87 Lifecycle Methode 75

M Machbarkeitsstudie 81 maintenance 30 Manualen 92 Meilensteine 75 MOF 7 Monitoring 144

N Naturgewalten 139 Noncompliance 151 Notfalleinrichtungen 140 Notfallplan 116

Job Scheduling 142

K Kapazität 111 Katastrophen 114 Key Goal Indicators 46 Key Performance Indicators 47 KGI 166 Klassifizierung 134 Konfigurationsmanagement 129 Konkurse 114 Kontrollpunkte 147 Kontrollstrukturen 157

172

O OGC 9 Output 45 Outsourcing 109

P PDA Zyklus 14 PDCA 165 Performance 111 Performance Kriterien 32

Schlagwortverzeichnis physikalische Umgebung 138 PIR 103 Post Implementation Review 81 Primäre Informationskriterien 37 Prince2 159 Priorisierung 134 Probleme 132 Professional Seminar Series Program 161 Programmmanagemen 81 Projektdefinitionen 81 Projektmanagement 79 Projektmanagementmethoden 159 Projektsponsor 80 Projektzustimmung 81 Prozesskennzeichen 46

Service Level 104 Service Level Management 105 Servicekatalog 106 Sicherheitsplan 118 Sicherheitspolicies 55 Single Points of Failure 115 SOA 163 SOF 7 SPF 115 SPICE 19 Stakeholder 159 Standardapplikationen 86 Störungen 132 Stromzuführungen 138 System Security 117

Q

T

Qualität 13 Qualitätskosten 73 Qualitätskultur 74 Qualitätsmetriken 74 Qualitätsplan 81

Technikräume 140 Terrorismus 76 TOE 21 Transition 158 Trendanalysen 112

R

U

reliability 36 Restore 136 RFP 96 Risikoframework 78 Risikoplan 76 Risikopotential 76 ROI 79

Umweltgefahren 139 underpinning contract 105

S Sarbanes-Oxley Act 4 Schulungsbedarf 124 Schulungsmethoden 124 Security 10 Security Baseline 163 Sekundäres Informationskriterium 38 Service Improvement Programme 105

V Verfügbarkeit 36 Verfügbarkeitsanforderungen 112 Vermeidungsstrategie 132 Verrechnung 122 Vertraulichkeit 36 Virenschutz 118 Vollständigkeit 135

W WAN 138

173

Schlagwortverzeichnis Wartung 91 Wartungsverträge 139 Winterreport 4 Wissensdatenbank 127, 145

174

Z Zugangscodes 140 Zugangsmöglichkeiten 139 Zugangsschutz 139 Zuverlässigkei 36