MIIP: Modell zur Implementierung der IT-Prozesse: Konkrete Prozessbeschreibung und pragmatische Umsetzung IT-Prozessen

Lionel Pilorget MIIP: Modell zur Implementierung der IT-Prozesse

Lionel Pilorget

MIIP: Modell zur Implementierung der IT-Prozesse Mit 60 Abbildungen PRAXIS

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. 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 2010 Alle Rechte vorbehalten © Vieweg +Teubner Verlag | Springer Fachmedien Wiesbaden GmbH 2010 Lektorat: Christel Roß | Walburga Himmel Vieweg+Teubner Verlag ist eine Marke von Springer Fachmedien. Springer Fachmedien ist Teil der Fachverlagsgruppe Springer Science+Business Media. www.viewegteubner.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. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Umschlaggestaltung: KünkelLopka Medienentwicklung, Heidelberg Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier. Printed in Germany ISBN 978-3-8348-1308-4

Vorwort Es gibt schätzungsweise 6´500 verschiedene Sprachen in dieser Welt. Bekanntlich entstanden die Sprachen aus dem alten Testament, nachdem die Menschen beim Turmbau zu Babel probiert haben, Gott gleichzukommen. Ziel des Modells zur Implementierung der IT-Prozesse (als MIIP bezeichnet) ist sicher nicht zu erforschen, woher die verschiedenen Sprachen entstanden sind. Dennoch geht es darum, eine „gemeinsame Sprache“ zu sprechen. Entscheidend sind nicht die Wörter, sondern vielmehr der Sinn der Überlegungen dahinter. Damit werden Prinzipien konzipiert, die dazu beitragen, ein gemeinsames Verständnis zu schaffen. Dieser Punkt ist von besonderer Bedeutung für Organisationen, damit die verschiedenen Akteure in den wechselhaften Situationen kohärent und effizient agieren können. MIIP soll dazu beitragen, bei den IT-Organisationen ein konsistentes Verständnis über die IT-Prozesse zu erreichen. Nachdem gewisse Definitionen festgelegt sind, wird man schnell mit der Komplexität der IT-Prozesse konfrontiert. Woher kommt diese Komplexität und vor allem wie kann man diese unterbinden? Das Problem liegt sowohl in der Tatsache, dass ein Mensch in der Gegenwart nur ein Teil des Systems wahrnehmen kann, als auch in der notwendigen Zeit, um Begriffe und Theorien anhand praxisnaher Erfahrungen zu integrieren, oder besser gesagt zu „verdauen“. MIIP bietet an dieser Stelle einen Rahmen, der auf systematischen Analysen basiert. Eigentlich ist MIIP ursprünglich „bottom-up“ entstanden und wurde erst am Schluss „top-down“ formatiert. Damit wurde die Komplexität ersichtlich, vor allem aufgrund der zahlreichen Abhängigkeiten zwischen den Themengebieten. Die Komplexität wird dann durch Visualisierung und klare Informationsstrukturen eingeschränkt und quasi „systematisiert“. Es gibt sicher noch einen ganz komplexen Faktor in diesem Zusammenhang, und zwar der Faktor „Mensch“. Die besten Theorien helfen nicht, wenn der Mensch nicht mitmachen möchte. Die Motivation und das eigene Interesse bleiben die Schlüsselfaktoren für eine erfolgreiche Implementierung der IT-Prozesse. Und gerade wenn die Situation angespannt ist, gibt es meistens viel Potential. Ich hatte das Glück, diese Erfahrung innerhalb einer IT-Organisation sammeln zu dürfen. Durch zahlreiche Workshops und zum Teil mühselige Iterationen, nach dem Motto ein Schritt nach vorne und zwei Schritte zurück, ist es uns gelungen, die Prozesslandkarte aufzusetzen. Ich bin an dieser Stelle den Kollegen und unserem Chef

V

Vorwort sehr dankbar. Das Abenteuer war aber nicht zu Ende. Die Entstehung dieses Buches stellte noch eine weitere intellektuelle Herausforderung dar, um die Abstraktionsebene über die Definition der IT-Prozesse und deren Zusammenhänge zu realisieren. Beinahe hätte mir die Energie gefehlt. Zum Glück bekam ich Verstärkung von meiner Schwiegermutter und von Bekannten, so dass das Werk zu Ende geführt werden konnte. Ich wünsche allen, sei es bei der Entdeckungsreise oder bei dem Umsetzungsleidensweg, viel Spaß. Positive Energie aber auch Frustrationen gehören zur Übung und geben die Möglichkeit, viel über sich selbst zu lernen.

VI

Inhaltsverzeichnis 1 Einleitung ......................................................................................................................... 1 2 Präsentation der IT-Prozesslandkarte .......................................................................... 7 2.1 MIIP IT-Prozesslandkarte ....................................................................................... 8 2.2 Definition Prozessabhängigkeit ........................................................................... 12 2.3 IT Governance-Prinzipien ..................................................................................... 14 2.4 Roadmap für ein MIIP-Projekt ............................................................................. 16 3 Prozessabhängigkeiten ................................................................................................. 21 3.1 Gesamtüberblick..................................................................................................... 23 3.2 Auf die strategische Ebene (Zeithorizont > 1 Jahr) ............................................ 24 3.3 Auf die taktische Ebene (1 Jahr > Zeithorizont > 1 Monat) ............................... 25 3.4 Auf die operative Ebene (Zeithorizont < 1 Monat) ............................................ 27 4 IT Governance und Prozessrollen ............................................................................... 29 4.1 MIIP-Rollenbeschreibung „Oberstes Management“ ......................................... 34 4.2 MIIP-Rollenbeschreibung „ Mittleres Management“ ........................................ 40 4.3 MIIP-Rollenbeschreibung „ Mitarbeiter“ ............................................................ 43 4.4 Prozessrollenübersicht........................................................................................... 46 5 Funktionsgruppe „strategische Entscheidungsprozesse“ ....................................... 51 5.1 P01 – IT-Strategie-Prozess ..................................................................................... 51 5.1.1 Hauptaktivitäten „P01 – IT-Strategie“...................................................... 51 5.1.2

Rollen „P01 – IT-Strategie“ ........................................................................ 53

5.1.3

Prozessbeschreibung „P01 – IT-Strategie“ ............................................... 54

5.2 P02 - HR Management-Prozess ............................................................................ 55 5.2.1 Hauptaktivitäten „P02 – HR Management“ ............................................ 56 5.2.2

Rollen „ P02– HR Management “ .............................................................. 57

5.2.3

Prozessbeschreibung „P02 – HR Management “ .................................... 58

5.3 P03 – IT-Standards & Architektur-Prozess ......................................................... 59 5.3.1 Hauptaktivitäten „P03 – IT-Standards & Architektur“.......................... 60 5.3.2

Rollen „P03 – IT-Standards & Architektur“ ............................................ 61

5.3.3

Prozessbeschreibung „P03 – IT-Standards & Architektur“ ................... 62

VII

Inhaltsverzeichnis 5.4 P04 - IT Financial Management-Prozess ............................................................ 63 5.4.1 Hauptaktivitäten „P04– IT Financial Management“ ............................. 63 5.4.2

Rollen “P04 – IT Financial Management” ............................................... 64

5.4.3

Prozessbeschreibung „P04 – IT Financial Management“...................... 65

5.5 P05 – IT-Qualitätsmanagement-Prozess ............................................................. 67 5.5.1 Hauptaktivitäten „P05 – IT Qualitätsmanagement“.............................. 67 5.5.2

Rollen „P05 – IT-Qualitätsmanagement“ ................................................ 69

5.5.3

Prozessbeschreibung „P05 – IT-Qualitätsmanagement“ ...................... 70

5.6 Prozessabhängigkeiten „Strategische Entscheidungsprozesse“ ..................... 71 5.6.1 Prozessabhängigkeit „P01 – IT-Strategie“ ............................................... 72 5.6.2

Prozessabhängigkeit „P02 – HR Management“ ..................................... 73

5.6.3

Prozessabhängigkeit „P03 – IT Standards & Architektur“ ................... 73

5.6.4

Prozessabhängigkeit „P04 – IT Financial Management“ ...................... 73

5.6.5

Prozessabhängigkeit „P05 – IT-Qualitätsmanagement“ ....................... 74

6 Funktionsgruppe „Planung & Controlling“ ............................................................. 77 6.1 P06 – IT-Projekt Portfolio Management-Prozess ............................................... 77 6.1.1 Hauptaktivitäten „P06 – IT Projekt Portfolio Management“................ 81 6.1.2

Rollen „P06 – IT-Projekt Portfolio Management“ .................................. 82

6.1.3

Prozessbeschreibung „P06 – IT Projekt Portfolio Management“ ......... 83

6.2 P07 - Capacity / Availability Management-Prozess .......................................... 84 6.2.1 Hauptaktivitäten „P07 – Capacity / Availability Management“.......... 84 6.2.2

Rollen “P07 – Capacity / Availability Management” ............................ 85

6.2.3

Prozessbeschreibungen „P07 – Capacity / Availability“ ....................... 87

6.3 P08 - Continuity Management-Prozess .............................................................. 88 6.3.1 Hauptaktivitäten P08 – Continuity Management .................................. 90 6.3.2

Rollen „P08 – Continuity Management“ ................................................. 93

6.3.3

Prozessbeschreibung „P08 – Continuity Management“ ....................... 94

6.4 Prozessabhängigkeiten „Planung & Controlling“ ............................................ 95 6.4.1 Prozessabhängigkeit „P06 – Portfolio Management“ ............................ 95

VIII

6.4.3

Prozessabhängigkeit „P07 – Availability / Capacity Management“ ... 97

6.4.3

Prozessabhängigkeit „P08 – Continuity Management“ ........................ 98

Inhaltsverzeichnis 7 Funktionsgruppe „Account Management“ ............................................................... 99 7.1 P09 - Service Management-Prozess ................................................................... 100 7.1.1 Hauptaktivitäten „P09 – Service Management“ ................................... 105 7.1.2

Rollen „P09 – Service Management“ ...................................................... 106

7.1.3

Prozessbeschreibung „P09 – Service Management“............................. 107

7.2 P10 – Anforderungsmanagement-Prozess ........................................................ 108 7.2.1 Hauptaktivitäten „P10 – Anforderungsmanagement“ ........................ 108 7.2.2

Rollen „P10 – Anforderungsmanagement“ ........................................... 109

7.2.3

Prozessbeschreibung „P10 – Anforderungsmanagement“ ................. 111

7.3 Prozessabhängigkeiten „Account Management“ ............................................ 112 7.3.1 Prozessabhängigkeit „P09 – Service Management“ ............................. 113 7.3.2

Prozessabhängigkeit „P10 – Anforderungsmanagement“ .................. 114

8 Funktionsgruppe „Implementierung“ ..................................................................... 115 8.1 P11 - IT Projektmanagement-Prozess ................................................................ 115 8.1.1 Hauptaktivitäten „P11 – IT Projektmanagement“ ................................ 122 8.1.2

Rollen „ P11 – IT Projektmanagement “ ................................................. 123

8.1.3

Prozessbeschreibung „P11 – IT Projektmanagement“ ......................... 124

8.2 P12 - Release Management-Prozess ................................................................... 125 8.2.1 Hauptaktivitäten „P12 – Release Management“ ................................... 125 8.2.2

Rollen „ P12 – Release Management “.................................................... 128

8.2.3

Prozessbeschreibung „P12 – Release Management“ ............................ 129

8.3 P13 – Applikationsentwicklung-Prozess........................................................... 130 8.3.1 Hauptaktivitäten „P13 – Applikationsentwicklung“ ........................... 130 8.3.2

Rollen „P13 – Applikationsentwicklung“ .............................................. 131

8.3.3

Prozessbeschreibung „P13 – Applikationsentwicklung“ .................... 132

8.4 Prozessabhängigkeiten „Implementierung“ .................................................... 133 8.4.1 Prozessabhängigkeit „P11 – Projektmanagement“............................... 134 8.4.2

Prozessabhängigkeit „P12 – Release Management“ ............................. 136

8.4.3

Prozessabhängigkeit „P13 – Applikationsentwicklung“ ..................... 137

9 Funktionsgruppe „IT-Betrieb & Konfigurationsmanagement“ ............................. 139 9.1 P14 – IT-Betrieb & Konfigurationsmanagement-Prozess ............................... 139

IX

Inhaltsverzeichnis 9.1.1

Hauptaktivitäten „P14 – IT-Betrieb & Konfiguration“ ........................ 140

9.1.2

Rollen „ P14 – IT-Betrieb & Konfigurationsmanagement” ................. 141

9.1.3

Prozessbeschreibung „P14 – IT-Betrieb & Konfiguration“ ................. 144

9.2 Prozessabhängigkeiten „IT-Betrieb & Konfiguration“ ................................... 145 10 Funktionsgruppe „Supplier Management“ .......................................................... 151 10.1 P15 – IT-Supplier Management-Prozess ........................................................ 151 10.1.1 Hauptaktivitäten „P15 – IT-Supplier Management“ ....................... 151 10.1.2

Rollen „ P15 – IT Supplier Management “ ........................................ 152

10.1.3

Prozessbeschreibung „P15 – IT-Supplier Management“ ................ 154

10.2 Prozessabhängigkeiten „Supplier Management“ ......................................... 155 11 Funktionsgruppe „IT Support“ .............................................................................. 157 11.1 P16 - Incident Management-Prozess ............................................................... 157 11.1.2 Hauptaktivitäten „P16 – Incident Management“ ............................ 160 11.1.2

Rollen „P16 – Incident Management“ ............................................... 161

11.1.3

Prozessbeschreibung „P16 – Incident Management“...................... 163

11.2 P17 - Problem Management-Prozess .............................................................. 164 11.2.1 Hauptaktivitäten „P17 – Problem Management“ ............................ 164 11.2.2

Rollen „P17 – Problem Management“ ............................................... 167

11.2.3

Prozessbeschreibung „P17 – Problem Management“ ..................... 168

11.3 Prozessabhängigkeiten „IT Support“ ............................................................. 169 11.3.1 Prozessabhängigkeit „P16 – Incident Management“ ...................... 169 11.3.2

Prozessabhängigkeit „P17 – Problem Management“ ...................... 170

12 Einführung der IT-Prozesse .................................................................................... 173 12.1 Wie sieht eine Einführung aus? ....................................................................... 174 12.2 Entwicklung der IT-Organisation ................................................................... 177 12.3 Eine Frage des Tooleinsatzes ........................................................................... 179 12.4 Wie sieht es mit Outsourcing aus? .................................................................. 184 13 Prozess-Kennzahlen und Reporting ....................................................................... 187 13.1 Definition und Wahl der Prozess-Kennzahlen .............................................. 187 13.1.1 Mögliche Prozess-Kennzahlen ........................................................... 187

X

13.1.2

BSC-Modell (Balanced Score Card) für IT-Prozesse ........................ 196

13.1.3

IT-Performanz messen anhand IT und Business-Kennzahlen ....... 204

Inhaltsverzeichnis 13.2 Abläufe im Berichtswesen................................................................................. 205 13.2.1 Weitere Definitionen ............................................................................ 205 13.2.2

Ablauf im allgemeinen Berichtswesen ............................................... 207

13.3 Reporting für IT-Organisation.......................................................................... 209 13.3.1 IT-Jahresbericht ..................................................................................... 210 13.3.2

IT-Quartalsbericht ................................................................................. 211

13.3.3

IT-Monatsbericht ................................................................................... 213

13.3.4

IT-Eskalation / Information (täglich) .................................................. 214

14 Evaluation des Reifegrads (COBIT) ........................................................................ 215 14.1 COBIT Framework ............................................................................................. 215 14.1.1 PO: planen und organisieren............................................................... 216 14.1.2

AI: beschaffen und einführen .............................................................. 217

14.1.3

DS: ausliefern und unterstützen ......................................................... 217

14.1.4

M: überwachen ...................................................................................... 219

14.1.5

CobiT-Kernprüfpunkte ........................................................................ 219

14.2 Maturity Model .................................................................................................. 221 14.3 Bewertung des Reifegrades der IT Prozesse................................................... 223 15 Schlussfolgerung ....................................................................................................... 233 A Abkürzungen .............................................................................................................. 235 B Glossar .......................................................................................................................... 237 C Literatur ....................................................................................................................... 245 D IT-Management-Standards ....................................................................................... 249 E ITIL ............................................................................................................................... 253 F CobIT ............................................................................................................................ 257 G MIIP-Vorlagen ............................................................................................................ 269

XI

Abbildungsverzeichnis Bild 1: Bedeutung und Rolle der IT-Organisation .......................................................... 7 Bild 2: MIIP IT-Prozesslandkarte ...................................................................................... 9 Bild 3: Definition der Prozessabhängigkeit ................................................................... 12 Bild 4: Schnittstellen Fachbereiche – IT-Organisation in einem Unternehmen ........ 15 Bild 5: Erste Schritte zum MIIP-Projekt.......................................................................... 16 Bild 6: Überblick über die MIIP-Prozessabhängigkeiten ............................................. 23 Bild 7: MIIP-Prozessabhängigkeiten auf strategischer Ebene ..................................... 25 Bild 8: MIIP-Prozessabhängigkeiten auf taktischer Ebene .......................................... 26 Bild 9: MIIP-Prozessabhängigkeiten auf operativer Ebene ......................................... 27 Bild 10: Allgemeines Organisationsmodell ................................................................... 29 Bild 11: Allgemeines IT-Organisationsmodell .............................................................. 30 Bild 12: MIIP-Prozessrollen Business ............................................................................. 32 Bild 13: MIIP-Prozessrollen-IT ........................................................................................ 33 Bild 14: Business & IT-Prozessrollen .............................................................................. 46 Bild 15: MIIP IT-Hauptrollen ........................................................................................... 49 Bild 16: Prozessbeschreibung „P01 - IT-Strategie“ ....................................................... 54 Bild 17: Prozessbeschreibung „P02 - HR Management“.............................................. 58 Bild 18: IT-Architektur-Darstellung................................................................................ 59 Bild 19: Prozessbeschreibung „P03 - IT-Standards & Architektur“ ........................... 62 Bild 20: IT Financial Management als „Drehscheibe“ .................................................. 63 Bild 21: Prozessbeschreibung „P04 - IT Financial Management“ ............................... 66 Bild 22: Prozessbeschreibung „P05 - IT-Qualitätsmanagement“................................ 70 Bild 23: MIIP-Prozessabhängigkeiten „Strategische Entscheidungsprozesse“ ........ 71 Bild 24: MIIP-Portfolio-Prozess-Darstellung ................................................................. 78 Bild 25: IT-Projekt-Portfolio-Matrix ................................................................................ 79 Bild 26: Prozessbeschreibung „P06 – IT-Projekt Portfolio Management“ ................. 83 Bild 27: Prozessbeschreibung „P07 – Capacity / Availability Management“ ........... 87 Bild 28: Ziel des Continuity Management-Prozesses ................................................... 89 Bild 29: Prozessbeschreibung „P08 - Continuity Management“ ................................ 94

XIII

Abbildungsverzeichnis Bild 30: MIIP-Prozessabhängigkeiten „Planung & Controlling“ ............................... 95 Bild 31: Prozessbeschreibung „P09 - Service Management“ .................................... 107 Bild 32: Prozessbeschreibung „P10 - Anforderungsmanagement“ ......................... 111 Bild 33: MIIP-Prozessabhängigkeiten „Account Management“ .............................. 112 Bild 34: Projektablauf ..................................................................................................... 116 Bild 35: Generische Projektorganisation...................................................................... 117 Bild 36: Generische Projektphasen ............................................................................... 118 Bild 37: Prozessbeschreibung „P11 – IT Projektmanagement“ ................................ 124 Bild 38: Release-Ablauf .................................................................................................. 126 Bild 39: Testarten ............................................................................................................ 127 Bild 40: Prozessbeschreibung „P12 - Release Management“ .................................... 129 Bild 41: Prozessbeschreibung „P13 – Applikationsentwicklung“ ........................... 132 Bild 42: MIIP-Prozessabhängigkeiten „Implementierung“ ...................................... 133 Bild 43: Projektmanagement-Abhängigkeiten............................................................ 135 Bild 44: Prozessbeschreibung „P14 – IT-Betrieb & Konfigurationsmanagement“ 144 Bild 45: MIIP-Prozessabhängigkeiten „IT-Betrieb & Konfiguration“ ..................... 145 Bild 46: Prozessbeschreibung „P15 – IT-Supplier Management“ ............................ 154 Bild 47: MIIP-Prozessabhängigkeiten „Supplier Management“ .............................. 155 Bild 48: Prozessbeschreibung „P16 - Incident Management“ .................................. 163 Bild 49: Ablauf Problem Management (Quelle = ABB Industrie) ............................ 165 Bild 50: Prozessbeschreibung „P17 - Problem Management“ .................................. 168 Bild 51: MIIP-Prozessabhängigkeiten „IT Support“ .................................................. 169 Bild 52: Vorgehensweise bei der Einführung der IT-Prozesse ................................. 175 Bild 53: Möglicher Plan zur Einführung der IT-Prozesse ......................................... 176 Bild 54: Motivationsfaktoren......................................................................................... 177 Bild 55: Persönliche Fragen bei Veränderung ............................................................ 178 Bild 56: BSC-Modell für IT-Organisation .................................................................... 197 Bild 57: Berichtswesen Modellierung .......................................................................... 208 Bild 58: Beispiel Berichtswesen anhand Aufwanderfassung ................................... 209 Bild 59: Stufe des Prozessreifegrades........................................................................... 223 Bild 60: Bewertung des Prozessreifegrades ................................................................ 232

XIV

Tabellenverzeichnis Tabelle 1: Ausprägung der IT-Prozesse je nach Geschäft ............................................ 18 Tabelle 2: Nutzenpotential eines MIIP-Projektes .......................................................... 20 Tabelle 3: MIIP-Prozessabhängigkeiten ......................................................................... 22 Tabelle 4: MIIP Prozessrollen „Oberstes Management“ .............................................. 39 Tabelle 5: MIIP-Prozessrollen „Mittleres Management“ ............................................. 42 Tabelle 6: MIIP-Prozessrollen „Mitarbeiter“ ................................................................. 45 Tabelle 7: Hauptaktivitäten „P01 - IT-Strategie“ .......................................................... 52 Tabelle 8: Prozessrollen „P01 – IT-Strategie“ ................................................................ 53 Tabelle 9: Hauptaktivitäten „P02 - HR Management“ ................................................. 56 Tabelle 10: Prozessrollen „P02 – HR Management“ ..................................................... 57 Tabelle 11: Hauptaktivitäten „P03 – IT-Standards & Architektur“ ............................ 60 Tabelle 12: Prozessrollen „P03 - IT-Standards & Architektur“ ................................... 61 Tabelle 13: Hauptaktivitäten „P04 – IT Financial Management“ ............................... 63 Tabelle 14: Prozessrollen „P04 – IT Financial Management“ ...................................... 64 Tabelle 15: Hauptaktivitäten „P05 – IT-Qualitätsmanagement“ ................................ 67 Tabelle 16: Prozessrollen „P05 – IT -Qualitätsmanagement“ ...................................... 69 Tabelle 17: MIIP-Beispiel kritischer Erfolgsfaktoren für IT-Projekte ......................... 80 Tabelle 18: Hauptaktivitäten „P06 – IT Projekt Portfolio Management“ .................. 81 Tabelle 19: Prozessrollen „P06 – IT-Projekt Portfolio Management“ ......................... 82 Tabelle 20: Hauptaktivitäten „P07 – Capacity / Availability Management“ ............ 84 Tabelle 21: Prozessrollen „P07 – Capacity / Availability Management“ ................... 85 Tabelle 22: Hauptaktivitäten „P08 – Continuity Management“ ................................. 90 Tabelle 23: Prozessrollen „P08 – Continuity Management“........................................ 93 Tabelle 24: Definition der Service-Zeiten ..................................................................... 101 Tabelle 25: Reaktionszeiten ............................................................................................ 102 Tabelle 26: SLO-Definitionsmerkmale.......................................................................... 103 Tabelle 27: Beispiele SLOs .............................................................................................. 103 Tabelle 28: Hauptaktivitäten „P09 – Service Management“ ..................................... 105 Tabelle 29: Prozessrollen „P09 – Service Management“ ............................................ 106

XV

Tabellenverzeichnis Tabelle 30: Hauptaktivitäten „P10 – Anforderungsmanagement“.......................... 108 Tabelle 31: Prozessrollen „P10 – Anforderungsmanagement“ ................................ 109 Tabelle 32: Hauptaktivitäten „P11 – IT Projektmanagement“ ................................. 122 Tabelle 33: Prozessrollen „P11 – IT Projektmanagement“ ........................................ 123 Tabelle 34: Hauptaktivitäten „P12 – Release Management“ .................................... 125 Tabelle 35: Prozessrollen „P12 – Release Management“ ........................................... 128 Tabelle 36: Hauptaktivitäten „P13 – Applikationsentwicklung“............................. 130 Tabelle 37: Prozessrollen „P13 – Applikationsentwicklung“ ................................... 131 Tabelle 38: Vergleich Release Management-Prozess mit ProjektmanagementProzess ............................................................................................................................. 136 Tabelle 39: Hauptaktivitäten „P14 – IT-Betrieb & Konfigurationsmanagement“ . 140 Tabelle 40: Prozessrollen „P14 – IT-Betrieb & Konfigurationsmanagement“ ........ 141 Tabelle 41: Trennung Service Manager / System Owner .......................................... 142 Tabelle 42: Hauptaktivitäten „P15 – IT-Supplier Management“ ............................. 151 Tabelle 43: Prozessrollen „P15 – IT Supplier Management“ .................................... 152 Tabelle 44: Hauptaktivitäten „P16 – Incident Management“ ................................... 160 Tabelle 45: Prozessrollen „P16 - Incident Management“ .......................................... 161 Tabelle 46: Hauptaktivitäten „P17 – Problem Management“ .................................. 164 Tabelle 47: Prozessrollen „P17 – Problem Management“ ......................................... 167 Tabelle 48: Auswahlkriterien eines EDV-Tools für IT-Prozesse .............................. 180 Tabelle 49: Prozesskennzahlen im IT-Jahresbericht................................................... 210 Tabelle 50: Prozesskennzahlen im IT-Quartalsbericht .............................................. 212 Tabelle 51: Prozesskennzahlen im IT-Monatsbericht ................................................ 213 Tabelle 52: „PO“ CobiT und MIIP-Prozesse ............................................................... 216 Tabelle 53: „AI“ CobiT und MIIP-Prozesse ................................................................ 217 Tabelle 54: „DS“ CobiT und MIIP-Prozesse................................................................ 218 Tabelle 55: „M“ CobiT und MIIP-Prozesse ................................................................. 219 Tabelle 56: CobiT „light“ und MIIP-Prozesse............................................................. 219 Tabelle 57: MIIP-Prozessreife-Modell .......................................................................... 226 Tabelle 58: Ergebnisse eines Prozessaudits als Beispiel ............................................ 227 Tabelle 59: Kritikalitätskarte der IT-Prozesse ............................................................. 230

XVI

1 Einleitung Die Bedeutung der Informatik in unserem täglichen Leben ist unbestritten. Sowohl im Privatbereich (GPS im Auto, Cybershopping,…) als im Büro benutzen wir immer mehr die Computer mit immer mehr integrierten Programmen. Die technologische Entwicklung im Bereich Informationstechnik ist rasant: die Vernetzung wird immer dichter und die Leistungsfähigkeit der IT-Komponenten steigt ständig. Die IT-Industrie bleibt weiterhin eine „junge“ Industrie. Der erste Computer erschien erst im Jahr 1939, und die Mikroprozessoren wurden erst 1971 patentiert. Die Vaterschaft zwischen Gilbert Hyatt bei Micro Computer Co. und Gary Boone bei Texas Instruments wurde hart bestritten. Dennoch steigen im Laufe der Zeit die Anforderungen an die Informatik. Programme müssen zuverlässig laufen und die IT-Systeme müssen quasi „Tag und Nacht“ zur Verfügung stehen. Es ist auch notwendig, sich zu schützen. Viren oder Datenschutz sind hoch aktuelle Themen. Man muss auch für das „Schlimmste“ vorbereitet werden: der Katastrophenfall! Die Komplexität der Datenintegration muss beherrscht werden und die Kosten unter Kontrolle bleiben. In diesem Kontext ist es nicht erstaunlich, dass das Thema der Standardisierung und Industrialisierung der Informatik erscheint. Um die notwendige Reife zu erreichen, müssen Standards und Methoden entwickelt werden. Der Begriff „Prozess“ bietet an der Stelle eine hilfreiche Unterstützung. Damit können Abläufe definiert werden, die reproduzierbar sind. Diese können in kleinen Einheiten, die so genannten Arbeitsschritte, charakterisiert werden, so dass die Komplexität dadurch reduziert werden kann. Die Definition der IT-Prozesse ermöglicht ein gesamthaftes und systematisches Verständnis der IT-Aktivitäten, die für die Abwicklung der elektronischen Tätigkeiten einer Privatperson oder eines Unternehmens erforderlich sind. In diesem Buch wird ein Prozessmodell für IT-Prozesse dargestellt, um eine Gesamtsicht über die IT-Belange zu ermöglichen. Dadurch werden wichtige Zusammenhänge transparent, wie etwa die Qualität der Projektabwicklung entscheidend für die Einhaltung der Service Levels im Betrieb wirkt. Dieses Modell, als MIIP gekennzeichnet, ist kein „abstraktes Konstrukt“, sondern beruht auf der mehrjährigen Erfahrung zahlreicher IT-Manager und der systematischen Verwendung und Entwicklung von Prozessstandards in verschiedenen IT-Organisationen, sowohl im Industriesektor als auch im Dienstleistungsbereich. Alle Inhalte und Analysen richten sich nach dem entworfenen Modell. Es handelt sich in dem Buch nicht um eine systematische Auflistung der bestehenden Literatur und der veröffentlichten Beispiele. Dank erprobter Erfahrung werden konkrete

1

1 Einleitung und pragmatische Lösungen angeboten. Diese mögen nicht in allen Fällen angewendet werden, dennoch stellt die vorgestellte Methode einen Rahmen mit Lösungsansätzen, die sehr hilfreich sind. Nebst der Beschreibung des Prozessmodells sind 61 Abbildungen und 59 Tabellen in diesem Buch zu finden. Damit soll auf einen Blick eine didaktische Erklärung eines Konzepts oder einer Situation ermöglicht werden. Im OnlinePLUS-Service zum Buch sind 62 Vorlagen abrufbar, die man von der Homepage des Verlags (www.viewegteubner.de) downloaden kann. Durch die Verwendung der Vorlagen werden die dargelegten Begriffe praktisch anwendbar. Die Erfahrung zeigt auch, dass es viel einfacher ist, aus einem bestehenden Beispiel, die eigenen Vorlagen zu entwerfen, anstatt von Null anzufangen. Um die Lesbarkeit zu erleichtern, werden unterschiedliche Ebenen betrachtet. Klassischerweise werden drei verschiedene Schichten berücksichtigt: Die Strategische Ebene Die strategische Ebene bezieht sich auf die oberste Stufe des Unternehmensmanagements. Diese wird in diesem Buch als Managementetage oder Geschäftsleitung (GL als Abkürzung) gekennzeichnet. Auf dieser Ebene werden strategische Entscheidungen getroffen, die für die Weiterentwicklung des Unternehmens von großer Bedeutung sind. Die Taktische Ebene Auf dieser Ebene sind in erster Linie planerische Aktivitäten positioniert, die sowohl die Erbringung von Services als auch die Durchführung von Projekten umfassen. Die Verantwortung wird an der Stelle von dem so genannten „mittleren Management“ getragen. Dies wird unter dem Begriff „IT-Kunde“ definiert. Die Operative Ebene Diese Ebene umfasst alle Aktivitäten, die für die eigentliche Herstellung eines Produktes oder die Erbringung einer Dienstleitung notwendig sind. Alle IT-Anwender sind dieser Kategorie zugeordnet. In der Folge eine Übersicht zu den einzelnen Kapiteln und den Aufbau des Buches. Das Buch beinhaltet drei Hauptteile: Teil A: Einführung und Modellierung der IT-Prozesse (Kapitel 1 bis 4) In diesem einleitenden Teil wird die Gesamttheorie des Modells dargestellt. Basierend auf empirischen Beobachtungen der IT-Abläufe, aber auch der organisatorischen Probleme in einer IT-Organisation, werden die IT-Prozesse abstrahiert und in einem Modell zusammengefasst.

2

1 Einleitung Teil B: Detailbeschreibung der IT-Prozesse (Kapitel 5 bis 11) Im Teil B werden die IT-Prozesse definiert. Anhand von Ablaufbeschreibungen werden Prozessschritte definiert. Die Prozessbeschreibung beinhaltet auch die „Inputs“ und „Outputs“, sowie die an der Prozessabwicklung beteiligten Rollen. Teil C: Einführung und Überwachung der IT-Prozesse (Kapitel 12 bis 14) Die definierten IT-Prozesse sollen umgesetzt und überwacht werden. Teil C ist vollständig auf der operativen Ebene positioniert und behandelt die praktische Implementierung der Prozesse. Anbei die detaillierten Inhaltsbeschreibungen der einzelnen Kapitel. Teil A: Präsentation der Methode und Modellierung der IT-Prozesse Kapitel 2

Die MIIP-Prozesslandkarte wird definiert und als Basis für die Entwicklung des Prozessmodells festgelegt. Die 17 MIIP-Prozesse werden im Detail vorgestellt.

Kapitel 3

Eine konzeptuelle Schwierigkeit bei der Darstellung der Prozesse stellt die hohe Abhängigkeit zwischen den Prozessen dar. Um damit umgehen zu können, soll ein gewisses Gespür für die Prozesse entwickelt werden. Es wird an der Stelle zwischen drei Ebenen unterschieden: – – –

Kapitel 4

die strategische Ebene, die taktische Ebene, die operative Ebene.

Die Verankerung der Prozesse innerhalb der Organisation ist ein absoluter Schlüsselfaktor. Dies bedingt ein gutes Zusammenspiel zwischen dem Business und der IT-Organisation. Um dort ein klares Bild zu schaffen, wird zwischen drei Stufen unterschieden: – – –

Oberstes Management, Mittleres Management, Mitarbeiter.

Teil B: Beschreibung der einzelnen IT-Prozesse Kapitel 5

Dieses Kapitel umfasst die Funktionsgruppe „strategische Entscheidungsprozesse“, die fünf Prozesse beinhaltet: – –

„P01 - IT-Strategie“, „P02 - HR-Management“,

3

1 Einleitung – – –

„P03 - IT-Standards & Architektur“, „P04 - IT Financial Management“, „P05 - IT-Qualitätsmanagement“.

Die Hauptaktivitäten und Rollen werden beschrieben und als Zusammenfassung jeweils einer Prozessbeschreibung im A4-Format erstellt. Am Schluss werden die entsprechenden Prozessabhängigkeiten dargestellt. Kapitel 6

In diesem Kapitel wird die Funktionsgruppe „Planung & Controlling“ behandelt, welche die folgenden drei Prozesse beinhaltet: – „P06 - IT-Projekt Portfolio Management“, – „P07 - Capacity / Availability Management“, – „P08 - Continuity Management“. Ähnlich wie beim Kapitel 5 werden die Hauptaktivitäten, Rollen, sowie die Prozessbeschreibung im A4-Format und die entsprechenden Prozessabhängigkeiten vorgelegt.

Kapitel 7

Die Funktionsgruppe „Account Management“ wird im Kapitel 7 dargestellt, inklusiv der entsprechenden zwei IT-Prozesse: – „P09 - Service Management“, – „P10 - Anforderungsmanagement“. Hauptaktivitäten, Rollen, Prozessbeschreibung und entsprechende Prozessabhängigkeiten werden beschrieben.

Kapitel 8

Die Funktionsgruppe „Implementierung“ stellt ein wichtiges taktisches Element dar und wird im Kapitel 8 mit den entsprechenden drei IT-Prozessen präsentiert: – „P11 - Projektmanagement“, – „P12 - Release Management“, – „P13 - Applikationsentwicklung“. Um ein komplettes Bild zu gewinnen, werden Hauptaktivitäten, Rollen, Prozessbeschreibungen und entsprechende Prozessabhängigkeiten ausgewiesen.

Kapitel 9

Im operativen Bereich bietet die Funktionsgruppe „IT-Betrieb & Konfigurationsmanagement“ die Kernaktivitäten an. Der einzige Prozess lautet auch: –

4

„P14 - IT-Betrieb & Konfigurationsmanagement“.

1 Einleitung Dieser Prozess wird inklusive Hauptaktivitäten, Rollen und Prozessabhängigkeiten beschrieben. Kapitel 10

Die Aktivitäten der IT-Einkäufer werden innerhalb Funktionsgruppe „Supplier Management“ dargestellt:

der

– „P15 - IT Supplier Management“. Gemäss dem MIIP-Grundschema werden auch zu diesem ITProzess Hauptaktivitäten, Rollen und Prozessabhängigkeiten beschrieben. Kapitel 11

Um sicherzustellen, dass die IT-Anwender effektiv unterstützt werden, werden innerhalb der Funktionsgruppe „IT Support“ die zwei folgenden IT-Prozesse mit Hauptaktivitäten, Rollen und Prozessabhängigkeiten beschrieben: – „P16 - Incident Management“, – „P17 - Problem Management“. Der Vollständigkeit halber werden Hauptaktivitäten, Rollen und Prozessabhängigkeiten dieser zwei IT-Prozesse definiert.

Teil C: Umsetzung des Modells und Überwachung der IT-Prozesse Kapitel 12

Hier wird die Frage der Prozesseinführung thematisiert und eine Vorgehensweise vorgeschlagen. Ereignisse, wie die Einführung eines neuen IT Tools oder die Durchführung eines OutsourcingProgramms, bieten günstige Gelegenheiten, IT-Prozesse einzuführen. Wichtig ist dabei, die organisatorische Entwicklung zu berücksichtigen.

Kapitel 13

Um die IT-Prozesse effizient bewirtschaften zu können, werden Kennzahlen definiert, gemessen und überwacht. Die Vielzahl der möglichen Kennzahlen kennt gewissermaßen keine Grenze. In dem Kapitel werden Beispiele gegeben und eine mögliche Struktur des IT-Reportings skizziert.

Kapitel 14

Die Prozesse sind nicht für die Ewigkeit in Stein gemeißelt, sondern müssen ständig weiterentwickelt werden. CobIT bietet ein interessantes Modell an, um den Reifegrad der Prozesse zu messen. Damit wird die Basis geschaffen, um die Prozesse kontinuierlich zu verbessern.

5

WieȱinȱderȱfolgendenȱAbbildungȱdargestelltȱdientȱdieȱITȬOrganisationȱeinerseitsȱalsȱ EmpfängerȱderȱITȬBedürfnisseȱdesȱUnternehmensȱundȱanderseitsȱAuftraggeberȱfürȱ ITȬZulieferer.ȱȱ

Bildȱ1:ȱBedeutungȱundȱRolleȱderȱITȬOrganisationȱ

Esȱ istȱ wichtig,ȱ dieȱ Bedürfnisseȱ desȱ Unternehmensȱ richtigȱ zuȱ adressierenȱ undȱ siȬ cherzustellen,ȱ dassȱ dieȱ eingekauftenȱ ITȬDienstleistungenȱ dieȱ erwartetenȱ Vorteileȱ fürȱdieȱEntwicklungȱdesȱUnternehmensȱbringen.ȱ Umȱ diesȱ darzustellen,ȱ werdenȱ 3ȱ Ebenenȱ innerhalbȱ desȱ Unternehmensȱ unterschieȬ den:ȱ 1) OberstesȱManagement:ȱEsȱhandeltȱsichȱinȱderȱRegelȱumȱdieȱGeschäftsȬȱundȱ Bereichsleitung;ȱ 2) MittleresȱManagement:ȱDieseȱEbeneȱentsprichtȱderȱStufeȱ„Abteilungsleiter“;ȱ 3) Mitarbeiter:ȱEsȱhandeltȱsichȱumȱdieȱoperativeȱEbene,ȱohneȱManagementverȬ antwortung.ȱ

ȱ

7ȱ

2ȱȱPräsentationȱderȱITȬProzesslandkarteȱ Fürȱ dieȱ Definitionȱ derȱ Prozesslandkarteȱ werdenȱ dieseȱ 3ȱ Ebenenȱ alsȱ „Rollen“ȱ chaȬ rakterisiert.ȱInȱdemȱFallȱwirdȱdieȱobersteȱEbeneȱalsȱGeschäftsleitung,ȱinȱAbkürzungȱ GL,ȱgekennzeichnet,ȱdasȱMittlereȱManagementȱalsȱITȬKundeȱgenannt,ȱundȱdieȱMiȬ tarbeiterȱwerdenȱweiterhinȱalsȱAnwenderȱbezeichnet.ȱ

DerȱKompassȱistȱfürȱSeeleuteȱabsolutȱnotwendig,ȱumȱihrenȱWegȱzuȱfinden.ȱDasselȬ beȱgiltȱfürȱdieȱITȬProzesslandkarte.ȱDankȱdieserȱKarteȱistȱesȱmöglich,ȱdieȱProzesseȱ einzuordnenȱundȱdieȱeinzelnenȱAktivitätenȱderȱITȬOrganisationȱzuȱspezifizieren.ȱ UmȱdasȱBildȱübersichtlicherȱzuȱmachen,ȱwerdenȱdieȱITȬProzesseȱnichtȱeinfachȱaufȬ gelistet,ȱsondernȱinȱsoȱgenannteȱFunktionsgruppenȱgruppiert.ȱDiesȱermöglichtȱeineȱ PositionierungȱderȱThemenȱundȱeinȱbesseresȱVerständnisȱderȱAbhängigkeiten.ȱ ȱ DieȱFunktionsgruppeȱStrategischeȱ Entscheidungsprozesseȱ istȱfürȱdieȱstrategischeȱ Ebeneȱ relevant,ȱ daȱ esȱ sichȱ inȱ ersterȱ Linieȱ umȱ strategischeȱ Entscheidungenȱ imȱ BeȬ reichȱITȱhandelt.ȱ ȱ Wasȱ dieȱ taktischeȱ Ebeneȱ betrifft,ȱ sindȱ inȱ ersterȱ Linieȱ dieȱ Funktionsgruppenȱ PlaȬ nungȱ&ȱControlling,ȱAccountȱManagementȱundȱImplementierungȱrelevant.ȱ ȱ ImȱoperativenȱBereichȱbietetȱdieȱFunktionsgruppeȱITȱSupportȱeineȱadäquateȱAntȬ wort.ȱ ȱ ZweiȱFunktionsgruppenȱsindȱüberȱmindestensȱzweiȱEbenenȱverteilt:ȱ – ITȬBetriebȱ&ȱKonfigurationsmanagement:ȱdieseȱFunktionsgruppeȱbeinhaltetȱ sowohlȱtaktischeȱalsȱoperativeȱAspekte.ȱ – SupplyȱManagement:ȱDerȱEinkaufȱvonȱexternenȱDienstleistungenȱbetrifftȱalleȱ Ebenen.ȱDerȱCIOȱbrauchtȱeventuellȱUnterstützungȱvonȱStrategieberatern,ȱumȱ dieȱ ITȬOrganisationȱ neuȱ zuȱ organisieren.ȱ Einȱ Projektleiterȱ wirdȱ ITȬ Dienstleistungenȱ kaufen,ȱ umȱ einȱ neuesȱ ITȬSystemȱ zuȱ parametrisieren.ȱ Einȱ SystemȬOwnerȱwirdȱneueȱSpeicherkapazitätȱkaufen,ȱsoȱdassȱdasȱSystemȱweiȬ terhinȱstabilȱläuft.ȱ ȱ

8

ȱ

2.1ȱȱMIIPȱITȬProzesslandkarteȱ

Bildȱ2:ȱMIIPȱITȬProzesslandkarteȱ

ȱ Dieȱ Funktionsgruppeȱ Strategischeȱ Entscheidungsprozesseȱ enthältȱ dieȱ Definitionȱ derȱ ITȬDienstleistungenȱ undȱ derenȱ Erbringung,ȱ umȱ dieȱ Bedürfnisseȱ desȱ UnterȬ nehmensȱ optimalȱ zuȱ erfüllen.ȱ Dieseȱ stelltȱ auchȱ sicher,ȱ dassȱ dieȱ ITȬ Sicherheitsaspekteȱabgedecktȱsind.ȱ FolgendeȱProzesseȱwerdenȱinnerhalbȱdieserȱFunktionsgruppeȱdefiniert:ȱ – – – – –

ȱ

P01ȱȬȱITȬStrategieȱ P02ȱȬȱHRȬManagementȱ P03ȱȬȱITȬStandardsȱ&ȱArchitekturȱ P04ȱȬȱFinancialȱManagementȱ P05ȱȬȱQualitätsmanagementȱ

9ȱ

2ȱȱPräsentationȱderȱITȬProzesslandkarteȱ Dieȱ Funktionsgruppeȱ Planungȱ &ȱ Controllingȱ beinhaltetȱ dieȱ Planungȱ allerȱ notȬ wendigenȱ Aktivitätenȱ undȱ derenȱ Überwachung,ȱ umȱ dieȱ Qualitätȱ derȱ ITȬ Dienstleistungenȱzuȱgarantieren.ȱ FolgendeȱProzesseȱwerdenȱinnerhalbȱdieserȱFunktionsgruppeȱdefiniert:ȱ – P06ȱȬȱITȬProjektȱPortfolioȱManagementȱ – P07ȱȬȱCapacityȱ/ȱAvailabilityȱManagementȱ – P08ȱȬȱContinuityȱManagementȱ Imȱ Bereichȱ Accountȱ Managementȱ sollenȱ dieȱ Kundenbeziehungenȱ optimiertȱ werȬ den,ȱumȱdieȱBusinessȬAnforderungenȱgemäßȱITȬRichtlinienȱoptimalȱzuȱgestalten.ȱ FolgendeȱProzesseȱwerdenȱinnerhalbȱdieserȱFunktionsgruppeȱdefiniert:ȱ – P09ȱȬȱServiceȱManagementȱ – P10ȱȬȱAnforderungsmanagementȱ Dieȱ Funktionsgruppeȱ Implementierungȱ erzieltȱ dieȱ termingerechteȱ Durchführungȱ vonȱÄnderungen.ȱDieseȱmüssenȱgenehmigtȱwerdenȱundȱdieȱentsprechendenȱRisiȬ kenȱanalysiertȱwerden.ȱ FolgendeȱProzesseȱwerdenȱinnerhalbȱdieserȱFunktionsgruppeȱdefiniert:ȱ – P11ȱȬȱProjektmanagementȱ – P12ȱȬȱReleaseȱManagementȱ – P13ȱȬȱApplikationsentwicklungȱ ImȱBereichȱITȱBetriebȱ&ȱKonfigurationsmanagementȱwirdȱsichergestellt,ȱdassȱdieȱ bestehendenȱ ITȱ Servicesȱ stabilȱ laufen.ȱ Dieȱ Informationsbasisȱ überȱ dieȱ zurȱ LeisȬ tungserstellungȱverwendetenȱKonfigurationselementeȱwirdȱlaufendȱaktualisiert.ȱ FolgenderȱProzessȱwirdȱinnerhalbȱdieserȱFunktionsgruppeȱdefiniert:ȱ – P14ȱȬȱITȬBetriebȱ&ȱKonfigurationȱ DasȱSupplyȱManagementȱumfasstȱdieȱBewertungȱdesȱselektivenȱSourcingȱaufȱderȱ BasisȱderȱstrategischenȱBedeutungȱdesȱServices.ȱEsȱermöglichtȱdenȱEinkaufȱvonȱITȬ DienstleistungenȱundȱITȬProduktenȱbeiȱDrittfirmenȱundȱdecktȱweitereȱwichtigeȱITȬ Bereiche,ȱwieȱLizenzverwaltungȱoderȱVerträgeȱab.ȱ FolgenderȱProzessȱwirdȱinnerhalbȱdieserȱFunktionsgruppeȱdefiniert:ȱ – P15ȱȬȱSupplierȱManagementȱ Dieȱ Funktionsgruppeȱ ITȱ Supportȱ unterstütztȱ dieȱ Userȱ undȱ stelltȱ sicher,ȱ dassȱ dieȱ bestehendenȱ ITȱ Servicesȱ reibungslosȱ laufen.ȱ Dieseȱ giltȱ auchȱ alsȱ Frühwarnsignal,ȱ beugtȱvorȱundȱreduziertȱStörungenȱdurchȱKorrigierenȱoderȱVermeidenȱvonȱFehlern.ȱ FolgendeȱProzesseȱwerdenȱinnerhalbȱdieserȱFunktionsgruppeȱdefiniert:ȱ – P16ȱȬȱIncidentȱManagementȱ – P17ȱȬȱProblemȱManagementȱ ȱ

10 ȱ

2.1ȱȱMIIPȱITȬProzesslandkarteȱ Imȱ Vergleichȱ zuȱ denȱ zehnȱ definiertenȱ ITILȱ V2ȬProzessen,ȱ kannȱ manȱ feststellen,ȱ dass:ȱ VierȱITILȬProzesseȱinȱdemȱMIIPȬModellȱübernommenȱwurden:ȱ – FinancialȱManagement,ȱ – ContinuityȱManagement,ȱ – IncidentȱManagement,ȱ – ProblemȱManagement.ȱ VierȱITILȬProzesseȱwurdenȱteilweiseȱübernommen:ȱ – ServiceȱManagementȱ(anstattȱServiceȱLevelȱManagement)ȱ – CapacityȱundȱAvailabilityȱManagementȱ(inȱMIIPȱzusammengefasstȱanstattȱ2ȱ getrennteȱProzesseȱfürȱITIL)ȱ – ITȬBetriebȱ &ȱ Konfigurationsmanagementȱ (anstattȱ nurȱ Configurationȱ ManaȬ gement)ȱ EinȱITILȬProzessȱwirdȱzumȱTeilȱandersȱȱdefiniert:ȱ – ReleaseȱManagement:ȱinȱMIIPȱbeziehtȱsichȱderȱReleaseȱManagementȬProzessȱ inȱersterȱLinieȱaufȱdieȱWeiterentwicklungȱeinerȱSoftware.ȱDiesȱkannȱentweȬ derȱvonȱdemȱSWȱProviderȱoderȱinternȱdurchȱeigeneȱEntwicklungenȱgewährȬ leistetȱwerden.ȱAllerdingsȱerlaubtȱdieȱDefinitionȱdesȱMIIPȱReleaseȱManageȬ mentȬProzessesȱ auchȱ dieȱ Abwicklungȱ derȱ ReleaseȬAktivitäten,ȱ wieȱ inȱ ITILȱ vorgeschlagen,ȱzumȱBeispielȱwennȱesȱsichȱumȱdasȱRollȬoutȱvonȱSicherheitsȬ patchesȱoderȱeinȱDatenbankȬUpgradeȱhandelt.ȱ EinȱITILȬProzessȱwirdȱnichtȱverwendet:ȱ – ChangeȱManagement:ȱinȱMIIPȱistȱeigentlichȱChangeȱManagementȱeinȱbreiterȱ Begriff,ȱ derȱ sowohlȱ Organisationsentwicklungȱ alsȱ Systemeinführungȱ beinȬ haltet.ȱDasȱChangeȱManagementȱfängtȱmitȱdenȱAnforderungenȱanȱundȱendetȱ mitȱ derȱ produktivenȱ Umsetzungȱ vonȱ SystemȬȱ oderȱ OrganisationsänderunȬ gen.ȱ AchtȱProzesseȱsindȱneuȱdefiniert:ȱ – ITȬStrategie,ȱ – HumanȱResourcesȱManagement,ȱ – ITȬStandardsȱ&ȱArchitektur,ȱ – Qualitätsmanagement,ȱ – ITȬProjektȱPortfolioȱManagement,ȱ – Anforderungsmanagement,ȱ – Projektmanagement,ȱ – Applikationsentwicklung.ȱ ȱ

ȱ

11

2ȱȱPräsentationȱderȱITȬProzesslandkarteȱ

DieȱAnalyseȱundȱBeschreibungȱderȱ17ȱITȬProzesseȱbringenȱdieȱLösungȱzuȱderȱFrageȱ derȱKomplexitätȱderȱITȬOrganisation.ȱInȱderȱTatȱhängenȱalleȱProzesseȱzusammen.ȱ Dieȱ engenȱ Prozessabhängigkeitenȱ erschwerenȱ dasȱ Verständnisȱ derȱ einzelnenȱ AbȬ läufe.ȱ Esȱ istȱ anȱ derȱ Stelleȱ entscheidend,ȱ dieȱ Abgrenzungȱ zwischenȱ denȱ Prozessenȱ klarȱzuȱdefinieren.ȱDaȱesȱnichtȱmöglichȱist,ȱalleȱITȬVorgängeȱinȱeinemȱallgemeinenȱ Prozessȱzuȱintegrieren,ȱmüssenȱzwangsläufigȱdieȱProzessschnittstellenȱsauberȱundȱ sorgfältigȱ definiertȱ undȱ umgesetztȱ werden.ȱ Umȱ dieȱ Antwortȱ zuȱ derȱ Grundfrage,ȱ wieȱ eineȱ ITȬOrganisationȱ erfolgreichȱ funktioniert,ȱ istȱ eineȱ präziseȱ Definitionȱ derȱ AbläufeȱundȱvorȱallemȱeinȱgutesȱVerständnis,ȱwieȱdieȱITȬProzesseȱ„ticken“,ȱerforȬ derlich.ȱ Einȱ Prozessȱ beginnt,ȱ wennȱ einȱ bestimmterȱ Triggerȱ stattfindet.ȱ Dieserȱ wirktȱ dannȱ alsȱAuslöser,ȱundȱdieȱSequenzȱderȱverschiedenenȱimȱProzessȱgeplantenȱAktivitätenȱ läuftȱab.ȱDerȱentscheidendeȱAnstoßȱkannȱvonȱeinerȱeinzelnenȱPerson,ȱeinerȱGruppeȱ vonȱ Mitarbeiterȱ oderȱ vonȱ einemȱ anderenȱ Prozessȱ veranlasstȱ werden.ȱ ȱ Inȱ demȱ zuȬ letztȱ erwähntenȱ Fallȱ wirdȱ dieseȱ Beziehungȱ vonȱ einemȱ Prozessȱ zuȱ einemȱ anderenȱ alsȱProzessabhängigkeitȱdefiniert,ȱwieȱimȱfolgendenȱBildȱdargestelltȱwird.ȱ

Bildȱ3:ȱDefinitionȱderȱProzessabhängigkeitȱ

12 ȱ

2.2ȱȱDefinitionȱProzessabhängigkeitȱ Inȱ demȱ obigenȱ Beispielȱ beinhaltetȱ derȱ Prozessȱ P0Xȱ dreiȱ Hauptschritteȱ undȱ eineȱ Prüfung,ȱdieȱnachȱderȱAktivitätȱP0XȬBȱdurchgeführtȱwird.ȱJeȱnachȱErgebnisȱdiesesȱ Checksȱ wirdȱ entwederȱ derȱ Prozessȱ zuȱ Endeȱ geführt,ȱ oderȱ fallsȱ dieȱ Prüfungȱ nichtȱ erfolgreichȱ ist,ȱ wirdȱ derȱ Prozessȱ P0Yȱ inȱ Anspruchȱ genommen.ȱ ȱ Inȱ demȱ Fallȱ stehtȱ eineȱ Abhängigkeitȱ zwischenȱ denȱ Prozessenȱ P0Xȱ undȱ P0Y,ȱ undȱ zwarȱ inȱ demȱ Fallȱ einseitigȱvonȱP0XȱzuȱP0Y.ȱ ȱ FolgendeȱSchaltzeichenȱwerdenȱbenutzt:ȱ ȱ

ȱ

Diesesȱ Symbolȱ wirdȱ benutzt,ȱ umȱ dieȱ ProȬ zessabhängigkeitenȱ darzustellen.ȱ Damitȱ wirdȱ sofortȱ ersichtlich,ȱ wieȱ vieleȱ Prozesseȱ inȱ Abhängigkeitȱ zuȱ demȱ beschriebenenȱ Prozessȱstehen.ȱ

ȱ ȱ

Dieȱ Abbildungȱ zeigtȱ zweiȱ Möglichkeiten,ȱ

ȱ

wieȱderȱProzessȱP0Xȱaktiviertȱwird:ȱ – Fallȱ 1:ȱ derȱ Prozessȱ P0Xȱ wirdȱ vonȱ eiȬ nemȱexternenȱTriggerȱausgelöst.ȱ – Fallȱ 2:ȱ derȱ Prozessȱ P0Xȱ stehtȱ inȱ AbȬ hängigkeitȱzuȱdemȱProzessȱP0Zȱundȱ wirdȱvonȱihmȱausgelöst.ȱ

ȱ ȱ ȱ ȱ ȱ ȱ ȱ ȱ ȱ

ȱ

13

2ȱȱPräsentationȱderȱITȬProzesslandkarteȱ

Umȱ dieȱ verschiedenenȱ Geschäftsbereicheȱ optimalȱ zuȱ unterstützen,ȱ habenȱ ITȬ Organisationenȱ konsequentȱ ITȬServicesȱ aufgebaut.ȱ Damitȱ werdenȱ dieȱ KundenanȬ forderungenȱkonkretȱfestgelegt,ȱdieȱgeliefertenȱLeistungenȱgemessenȱundȱeinȱquanȬ tifizierterȱ Nutzenȱ imȱ Sinneȱ vonȱ verrechnetenȱ Dienstleitungenȱ ersichtlich.ȱ ZusätzȬ lichȱ werdenȱ ITȬProjekteȱ durchgeführt,ȱ dieȱ dieȱ Weiterentwicklungȱ desȱ UnternehȬ mensȱsicherstellenȱsollen.ȱ Wegenȱ derȱ zunehmendȱ komplexenȱ Systemabhängigkeitenȱ undȱ desȱ steigendenȱ KostendrucksȱwerdenȱServiceanforderungenȱdurchȱITȬProzesseȱabgewickelt.ȱNebstȱ Effizienzsteigerungȱ könnenȱ auchȱ dankȱ Standardisierungȱ dieserȱ Servicesȱ dieȱ NutȬ zenorientierungȱundȱdieȱSteuerungȱderȱITȬKostenȱerreichtȱwerden,ȱumȱdenȱWertȬ beitragȱ fürȱ dasȱ Unternehmenȱ zuȱ gewährleisten.ȱ Dieȱ Umsetzungȱ derȱ ServiceȬȱ undȱ KundenorientierungȱerfordertȱinȱdenȱUnternehmenȱneueȱProzesseȱundȱVerantworȬ tungenȱimȱITȬBereich,ȱderenȱAuswirkungenȱinȱBeschaffung,ȱEntwicklungȱundȱBeȬ triebȱderȱITȬSystemeȱsichtbarȱsind.ȱ Eineȱ großeȱ Erkenntnisȱ beziehtȱ sichȱ aufȱ dieȱ Zusammenarbeitȱ zwischenȱ derȱ ITȬ Organisationȱ undȱ denȱ internenȱ Kunden.ȱ Dieȱ ITȬProzesseȱ könnenȱ nurȱ erfolgreichȱ umgesetztȱ werden,ȱ wennȱ dasȱ Zusammenspielȱ zwischenȱ Fachȱ undȱ ITȱ gutȱ abgeȬ stimmtȱist.ȱDieȱGestaltungȱderȱBeziehungenȱzwischenȱdenȱFachbereichenȱundȱderȱ ITȬOrganisation,ȱ dieȱ soȱ genannteȱ „ITȱ Governance“ȱ stelltȱ einenȱ Schlüsselfaktorȱ beiȱ derȱerfolgreichenȱErbringungȱderȱITȬDienstleistungenȱdar.ȱNennenswertȱistȱsicherȱ dieȱ Rolleȱ derȱ Geschäftsleitungȱ (GL),ȱ alsȱ obersteȱ Führungsinstanzȱ desȱ UnternehȬ mens.ȱVieleȱEntscheideȱmitȱdirektenȱAuswirkungenȱaufȱdieȱITȬOrganisationȱmüsȬ senȱvonȱderȱGLȱgetroffenȱwerden.ȱDerȱCIOȱistȱsicherȱdoppeltȱgefordert:ȱeinerseitsȱ dieȱITȬOrganisationȱaufȱVordermannȱzuȱbringenȱundȱanderseits,ȱdieȱGLȱsteuernȱzuȱ können,ȱ soȱ dassȱ „vernünftige“ȱ Entscheidungenȱ getroffenȱ werden.ȱ Imȱ Bereichȱ „mittleresȱ Management“ȱ mussȱ dieȱ Kooperationȱ auchȱ gutȱ funktionieren.ȱ Projekteȱ zumȱBeispielȱkönnenȱnurȱdannȱerfolgreichȱsein,ȱwennȱbeideȱParteien,ȱFachȱundȱIT,ȱ gemeinsamȱanȱeinemȱStrangȱziehen.ȱ Wieȱ beiȱ derȱ ITȱ Governanceȱ festgestellt,ȱ mussȱ dasȱ Managementȱ derȱ Firmaȱ dieȱ ImȬ plementierungȱderȱITȬProzesseȱunterstützen,ȱsonstȱistȱsieȱzwecklos.ȱDasȱReportingȱ derȱ ITȱ Performanceȱ istȱ einȱ bedeutenderȱ Kommunikationsträger.ȱ Damitȱ wirdȱ siȬ chergestellt,ȱ dassȱ dieȱ strategischenȱ Entscheidungenȱ kohärentȱ mitȱ derȱ operativenȱ Führungȱbleiben.ȱ

14 ȱ

2.3ȱȱITȱGovernanceȬPrinzipienȱ JederȱAkteurȱaufȱjederȱEbeneȱhatȱspezielleȱBedürfnisseȱanȱdieȱITȬOrganisation,ȱwieȱ inȱderȱfolgendenȱAbbildungȱdargestelltȱwird.ȱ

ƒ ƒ ƒ

ƒ ƒ ƒ ƒ

ƒ ƒ ƒ

ƒ ƒ ƒ ƒ

ƒ ƒ ƒ

ƒ ƒ

Bildȱ4:ȱSchnittstellenȱFachbereicheȱ–ȱITȬOrganisationȱinȱeinemȱUnternehmenȱ

NichtȱnurȱdieȱBedürfnisseȱderȱ„internen“ȱKundenȱsollenȱabgedecktȱwerden.ȱDieȱITȬ Organisationȱ sollȱ auchȱ inȱ derȱ Lageȱ sein,ȱ dieȱ richtigenȱ Serviceanforderungenȱ anȱ externeȱ ITȬDienstleisterȱ zuȱ formulieren,ȱ bezogeneȱ Servicesȱ richtigȱ zuȱ vereinbarenȱ undȱ dieȱ Inanspruchnahmeȱ angemessenȱ zuȱ managen.ȱ Inȱ kritischenȱ Branchenȱ wieȱ Pharma,ȱMedizintechnikȱoderȱKreditwirtschaftȱreguliertȱhierfürȱsogarȱderȱGesetzȬ geberȱdieȱAnforderungen,ȱinsbesondereȱwennȱesȱsichȱumȱdasȱOutsourcingȱwesentȬ licherȱITȬLeistungenȱhandelt.ȱ ȱ ȱ ȱ

ȱ

15

2ȱȱPräsentationȱderȱITȬProzesslandkarteȱ

DieȱAbwicklungȱeinesȱProzessesȱistȱkeineȱeinmaligeȱAktion.ȱDieȱVerbreitungȱeinesȱ ProzessesȱnimmtȱsehrȱvielȱZeitȱinȱAnspruch,ȱundȱmehrereȱJahreȱsindȱoftȱnotwendig,ȱ bisȱeinȱAblaufȱinȱderȱOrganisationȱeingespieltȱist.ȱUmȱdieȱQualitätȱdesȱProzessesȱzuȱ sichern,ȱ istȱ esȱ anȱ derȱ Stelleȱ notwendig,ȱ dieȱ Reifeȱ derȱ Prozesseȱ zuȱ messen.ȱ Damitȱ wirdȱfestgelegt,ȱwoȱdieȱSchwerpunkteȱzurȱUnterstützungȱdesȱBusinessȱliegenȱundȱ woȱ dieȱ Organisationȱ bezüglichȱ derȱ Implementierungȱ derȱ ITȬProzesseȱ steht.ȱ Esȱ istȱ dannȱmöglich,ȱkontinuierlichȱSchrittȱfürȱSchrittȱdieȱProzessgedankenȱundȱEffizienzȱ imȱUnternehmenȱzuȱverbreiten.ȱ

Bildȱ5:ȱErsteȱSchritteȱzumȱMIIPȬProjektȱ

EineȱwichtigeȱInformationȱinȱdemȱZusammenhangȱstelltȱdieȱAusgangsituationȱdar.ȱ Undȱ zwarȱ liegtȱ dieȱ Motivationȱ fürȱ dieȱ Einführungȱ derȱ ITȬProzesseȱ oftȱ inȱ derȱ BeȬ handlungȱeinesȱKrisenzustandes.ȱFolgendeȱBeispieleȱkönnenȱalsȱ„Auslöser“ȱgelten:ȱ LaufendeȱITȬOrganisationȱ,ȱdieȱverbessertȱwerdenȱsollȱ Inȱ soȱ einemȱ Kontextȱ istȱ esȱ empfehlenswert,ȱ eineȱ inkrementelleȱ Einführungȱ zuȱ erȬ zielen.ȱInȱderȱobigenȱAbbildungȱwirdȱdargestellt,ȱwelcheȱAktivitätenȱgeplantȱwerȬ denȱkönnen,ȱumȱersteȱSchritteȱmachenȱzuȱkönnen.ȱ FusionȱzwischenȱzweiȱUnternehmenȱ InȱsoȱeinȱFallȱstelltȱsichȱdieȱFrage,ȱobȱdieȱzukünftigeȱITȬOrganisationȱaußerhalbȱdesȱ neuenȱUnternehmensȱabgewickeltȱwerdenȱsoll.ȱAnderseitsȱkannȱesȱkosteneffektiverȱ werden,ȱdieȱeineȱITȬOrganisationȱinȱderȱ“führenden”ȱOrganisationȱzuȱintegrieren.ȱ Inȱ beidenȱ Optionenȱ istȱ esȱ vonȱ Vorteil,ȱ wennȱ ITȬAbläufeȱ dokumentiertȱ undȱ klarȱ definiertȱ sind.ȱ Damitȱ könnenȱ Verhandlungenȱ professionellerȱ durchgeführtȱ undȱ eineȱklareȱAnalyseȱderȱOrganisationsentwicklungȱsichergestelltȱwerden.ȱ

16 ȱ

2.4ȱȱRoadmapȱfürȱeinȱMIIPȬProjektȱ OutsourcingȱderȱITȬDienstleistungenȱ Derȱ Entscheidȱ zumȱ Outsourcingȱ derȱ ITȬDienstleistungenȱ istȱ gefallen.ȱ Imȱ Rahmenȱ einesȱ Transitionsprojektesȱ werdenȱ juristische,ȱ finanzielle,ȱ organisatorischeȱ undȱ technologischeȱ Fragenȱ behandelt.ȱ Dieȱ Möglichkeitȱ derȱ Übernahmeȱ desȱ ITȬ PersonalsȱstelltȱfürȱdieȱITȬOrganisationȱeinenȱzentralenȱPunktȱdar.ȱEineȱgroßeȱGeȬ fahrȱ bildetȱ derȱ Wissensverlustȱ beiȱ Kündigungen,ȱ gewolltȱ oderȱ ungewollt,ȱ vonȱ Kernressourcen.ȱ Einȱ finanziellerȱ Planȱ zurȱ Aufrechthaltungȱ derȱ Schlüsselpersonenȱ sollȱaufgesetztȱwerden.ȱ Unternehmensgründungȱ DieȱGründungȱeinesȱUnternehmensȱbietetȱdieȱMöglichkeit,ȱdieȱITȬInfrastrukturȱaufȱ eineȱsolideȱBasisȱaufzubauen.ȱEsȱistȱwichtig,ȱdieȱSkalierbarkeitȱderȱOrganisationȱzuȱ gewährleisten.ȱ ȱ JeȱnachȱUnternehmensgrößeȱkannȱesȱsichȱlohnen,ȱdieȱnötigenȱITȬDienstleistungenȱ externȱ zuȱ kaufen.ȱ Dennochȱ istȱ esȱ vonȱ Vorteil,ȱ wennȱ dieȱ ITȬKompetenzenȱ internȱ vorhandenȱ sind.ȱ Inȱ derȱ Regelȱ wirdȱ einȱ Mitarbeiterȱ ausgesucht,ȱ derȱ eineȱ gewisseȱ AffinitätȱzuȱITȬTechnologienȱbesitzt.ȱAbȱmindestensȱ20ȱMitarbeiterȱistȱesȱzuȱempȬ fehlen,ȱeinȱprofessionellesȱITȬManagementȱaufzusetzen.ȱ ȱ DieȱAusprägungȱderȱITȬProzesseȱhängtȱvonȱeinigenȱMerkmalenȱundȱEckdatenȱdesȱ Unternehmensȱab,ȱunterȱanderen:ȱ – – – – –

ȱ

dieȱGröße,ȱ dieȱweltweiteȱVertretung,ȱ KundenȬPortfolio,ȱ dieȱProzesskomplexität,ȱ dieȱgesetzlichenȱRahmenbedingungen.ȱ

17

2ȱȱPräsentationȱderȱITȬProzesslandkarteȱ Tabelleȱ1:ȱAusprägungȱderȱITȬProzesseȱjeȱnachȱGeschäftȱ Kennzeichenȱ

Merkmalȱ

Größeȱ

Konglomeratȱ (versusȱkleinȱ undȱmittleresȱ Untenehmen)ȱ

BedeutungȱfürȱdieȱITȬOrganisationȱ

– Globaleȱ Verträgeȱ mitȱ ȱ führendenȱ ITȬ Herstellernȱ – KritischeȱMasseȱfürȱdieȱBereitstellungȱvonȱITȬ Dienstleistungenȱ24ȱStundenȱproȱTag,ȱ7ȱTageȱ dieȱWocheȱ – Möglichkeit,ȱ dasȱ Offshoringȱ derȱ ITȬ DienstleistungenȱinȱAnspruchȱzuȱnehmenȱ InternationaȬ WeltweiteȱVerȬ – Eineȱ gemeinsameȱ Spracheȱ innerhalbȱ desȱ leȱStandorteȱ tretungȱ(versusȱ Konzernsȱ (besondersȱ wichtigȱ fürȱ dieȱ ITȬ regionaleȱoderȱ Dienstleistungenȱ imȱ Bereichȱ KommunikatiȬ nationaleȱAbdeȬ onstechnologien)ȱ ckung)ȱ – Schwierigkeitenȱ beiȱ derȱ Sprachkompatibilitätȱ derȱSoftwaresȱ – “followȱ theȱ sun”ȱ SupportȬKonzeptȱ möglichȱ fürȱ dieȱ 24ȱ Stundenȱ amȱ Tagȱ verfügbareȱ ITȬ Dienstleistungenȱ – Bedeutungȱ derȱ landspezifischenȱ gesetzlichenȱ Vorgabenȱ – Sicherheitsaspekte GlobaleȱKundenȱ – ÜbergeordneteȱDatenȬStruktur KundenȬ Portfolioȱ – AbarbeitungȱderȱKundensonderkonditionenȱ – DediziertesȱReporting ProzessȬ Standardisierteȱ – Automatisierungȱ derȱ SystemüberwachungsȬ komplexitätȱ Prozesseȱ(gegeȬ aufgabenȱ nüberȱhochȱspeȬ – PerformanceȬMessungenȱ zialisiertenȱundȱ – regelmäßigeȱBackupsȱ volatilenȱAbläuȬ – SoftwareȬVerteilungȱundȱRemoteȱControlȱ fen)ȱ – GlobaleȱITȬInvestitionenȱ – GlobalesȱProjektmanagementȱ ȱ – IntegrationȱmitȱZulieferernȱdankȱdemȱEinsatzȱ einerȱ EȬBusinessȬPlattformȱ (BȬtoȬBȱ vertikaleȱ BusinessȱIntegration) Gesetzlicheȱ Hochȱreguliertȱ – Hoheȱ ITȬQualitätsstandardsȱ (zumȱ Beispielȱ Vorgabenȱ (verglichenȱmitȱ CSVȱ Anforderungenȱ /ȱ CSVȱ =ȱ Computerȱ SysȬ einemȱdereguȬ temȱValidation)ȱ ȱ liertenȱMarkt)ȱ – Bedeutungȱ desȱ Dokumentmanagementsȱ undȱ dessenȱIntegrationȱbeiȱderȱDurchführungȱderȱ Produktionsabläufeȱ – HochspezialisierteȱITȬAnbieter

18 ȱ

2.4ȱȱRoadmapȱfürȱeinȱMIIPȬProjektȱ EinȱweiteresȱwichtigesȱElementȱstelltȱdieȱAbstimmungȱderȱITȬSupportȬLandschaftȱ anȱdieȱBewirtschaftungȱderȱGeschäftsprozesseȱdar.ȱUmȱdenȱZusammenhangȱerstelȬ lenȱzuȱkönnen,ȱwerdenȱzweiȱDimensionenȱberücksichtigt:ȱ ArtȱderȱVerwaltungȱderȱITȬSysteme:ȱzentralȱversusȱdezentral,ȱ EigenschaftenȱderȱGeschäftsprozesse:ȱlokalȱversusȱglobal.ȱ AlsȱzentraleȱVerwaltungȱeinesȱITȬSystemsȱistȱdieȱInbetriebnahmeȱeinerȱApplikationȱ gemeint,ȱ dieȱ vonȱ mehrerenȱ Standortenȱ benutztȱ wird.ȱ Dieȱ Pflegeȱ undȱ WeiterentȬ wicklungȱ derȱ Applikationȱ wirdȱ aberȱ zentralȱ anȱ einemȱ Ortȱ geführt.ȱ Dadurchȱ könȬ nenȱ dankȱ Rahmenverträgenȱ undȱ Bündelungȱ vonȱ Auftragsvergabenȱ erheblicheȱ Einsparungenȱerzieltȱwerden.ȱAlsȱdezentralȱüberwachtȱgeltenȱITȬSysteme,ȱdieȱvonȱ einerȱ dediziertenȱ Organisationȱ anȱ einemȱ Standortȱ betreutȱ werden.ȱ Dieȱ Betreuungȱ erfolgtȱvorȱOrtȱundȱdieȱgemeldetenȱBedürfnisseȱkönnenȱraschȱundȱkompetentȱadȬ ressiertȱwerden,ȱ„àȱlaȱcarte“ȱsozusagen.ȱ ȱ Beiȱ denȱ Fachbereichenȱ werdenȱ zwischenȱ „lokalen“ȱ Abläufenȱ undȱ „globalen“ȱ GeȬ schäftsprozessenȱunterschieden.ȱAlsȱlokaleȱAbläufeȱgeltenȱProzesse,ȱdieȱlandespeȬ zifisch,ȱ zumȱ Beispielȱ wegenȱ desȱ Gesetzgebers,ȱ aufgesetztȱ sind.ȱ Durchȱ dieȱ BenutȬ zungȱvonȱspeziellerȱSoftwareȱoderȱeigenerȱEigenschaftenȱinȱderȱProduktionsȬȱoderȱ MarktstrukturȱdesȱLandesȱwerdenȱArbeitsverfahrenȱstandortspezifischȱentwickelt.ȱ BeiȱdenȱglobalenȱProzessenȱwirdȱeineȱHarmonisierungȱaufȱdieȱGesamtebeneȱerzielt,ȱ umȱ dieȱ Leistungsfähigkeitȱ desȱ Unternehmensȱ zuȱ steigern.ȱ Nebenȱ einerȱ höherenȱ Flexibilitätȱ wirdȱ auchȱ eineȱ Kostenreduzierungȱ beiȱ zentralenȱ Geschäftsprozessenȱ erwartet.ȱ ȱ InȱderȱfolgendenȱTabelleȱwerdenȱbeideȱDimensionenȱkombiniert.ȱDurchȱdieȱAnalyȬ seȱderȱEigenschaftenȱderȱGeschäftsprozesseȱundȱdieȱÜberlegungenȱzurȱOrganisatiȬ onȱdesȱITȬSupportsȱkannȱeineȱLandschaftȱderȱlaufendenȱITȬSystemenȱerstelltȱwerȬ den.ȱDieȱGlobalisierungȱderȱFirmaȱsollȱinȱdenȱmeistenȱFällenȱzuȱeinerȱZentralisieȬ rungȱderȱITȬServicesȱundȱderȱITȬOrganisationȱführen.ȱEsȱistȱinȱderȱTatȱkaumȱvorȬ stellbar,ȱ dassȱ einȱ globalerȱ Prozessȱ durchȱ eineȱ dezentraleȱ Supportorganisationȱ nachhaltigȱgepflegtȱwerdenȱkann.ȱDankȱRemoteȱTechnologienȱsindȱdieȱZentralisieȬ rungȱundȱdasȱOffshoringȱderȱITȬServicesȱimmerȱeinfacherȱgeworden.ȱEsȱistȱwichtig,ȱ dassȱ dieȱ Ausrichtungȱ derȱ ITȬOrganisationȱ mitȱ denȱ Eigenschaftenȱ undȱ WeiterentȬ wicklungȱderȱGeschäftsprozesseȱabgestimmtȱist.ȱ ȱ ȱ ȱ ȱ

ȱ

19

2ȱȱPräsentationȱderȱITȬProzesslandkarteȱ Tabelleȱ2:ȱNutzenpotentialȱeinesȱMIIPȬProjektesȱ GeschäftsȬ prozessȱ

lokalȱ

globalȱ

Moderat:ȱ Standardȱ ITȬProzesseȱ könnenȱ schwerȱ umgesetztȱ werȬ denȱ undȱ kritischeȱ Masseȱ fürȱ eineȱ ITȬSupportȬOrganisationȱ fehltȱ

Hoch:ȱ Standardȱ ITȬProzesseȱ könnenȱ weltweitȱ verwendetȱ werdenȱ

ITȬSystemȱ Managementȱ ȱ

dezentralȱ

Dieseȱ Konstellationȱ erscheintȱ seltenȱundȱistȱschwierigȱzuȱmaȬ Lokaleȱ ITȬSysteme,ȱ wieȱ zumȱ nagen,ȱ daȱ dieȱ Nachhaltigkeitȱ Beispiel:ȱ schwerȱ zuȱ leistenȱ ist.ȱ Möglicheȱ Fälleȱsind:ȱ LIMSȱ(LaboratoryȱInformatiȬ Telefonbücher,ȱ onȱManagementȱSystem),ȱ StandardisierterȱProduktiȬ PCSȱ(ProcessȱControlȱSystem)ȱ onsprozessȱkombiniertȱmitȱ HRȱSystemȱ(HumanȱResourȬ einerȱlokalenȱAnwendung.ȱ ces)ȱ LokalesȱReportingȱ MarketingȬKampagnenȱ NationalerȱEinkauf,ȱdasȱvorȱ Ortȱbetreutȱwird.ȱ Hoch:ȱ Standardȱ ITȬProzesseȱ Sehrȱ Hoch:ȱ Standardȱ ITȬ könnenȱ zentralȱ umgesetztȱ werȬ Prozesseȱ könnenȱ zentralȱ undȱ weltweitȱumgesetztȱwerden.ȱ den.ȱ Allgemeineȱ ITȬInfrastruktur,ȱ Übergreifendeȱ Systeme,ȱ dieȱ dieȱ inȱ allenȱ Standortenȱ benutztȱ eineȱ Datenkonsolidierungȱ aufȱ Konzernebeneȱermöglichen.ȱ wird,ȱwieȱzumȱBeispiel:ȱ Email,ȱ StandardȱClientȱApplikatioȬ nen,ȱ Intranetȱ/ȱInternet,ȱ WissensmanagementȱAppliȬ kation,ȱ KernelȱundȱRolloutȱfürȱKernȬ applikationenȱ

zentralȱ

ȱ

20 ȱ

Folgendeȱ Systemeȱ sindȱ guteȱ Kandidatenȱdafür:ȱ Finanzsysteme,ȱ DataȱWarehouse,ȱ ZentralesȱReporting,ȱ Logistikmanagementsysteme,ȱ zentralesȱHRȬSystem,ȱ DokumentmanagementȬ Systeme.ȱ

Umȱ dieȱ Beschreibungȱ vonȱ Prozessenȱ ermöglichenȱ zuȱ können,ȱ istȱ esȱ wichtig,ȱ fürȱ jedenȱ Prozessȱ einenȱ Anfangȱ undȱ einȱ Endeȱ zuȱ definieren.ȱ Dadurchȱ wirdȱ dieȱ WirȬ kungȱderȱeinzelnenȱProzesseȱersichtlich.ȱ WieȱschonȱangekündigtȱsiehtȱdasȱMIIPȬModellȱvor,ȱdassȱAbhängigkeitenȱzwischenȱ denȱProzessenȱsorgfältigȱdefiniertȱwerdenȱsollen,ȱdaȱalleȱrelevanteȱAbläufeȱderȱITȬ OrganisationȱinȱeinemȱProzessȱFlowȱnichtȱdarstellbarȱist.ȱ Anȱ derȱStelleȱ kannȱ derȱ Unterschiedȱzwischenȱ exogenenȱ undȱ endogenenȱ Faktorenȱ gemachtȱwerden.ȱ Dieȱ exogenenȱ Faktorenȱ umfassenȱ einerseitsȱ alleȱ Unternehmensaspekte,ȱ dieȱ nichtȱ fürȱ dieȱ ITȬOrganisationȱ spezifischȱ sindȱ (wieȱ etwaȱ dieȱ Budgetierung),ȱ undȱ anderȬ seitsȱ dieȱ Interaktionenȱ mitȱ Anwendernȱ oderȱ Kunden.ȱ Alsȱ exogeneȱ Faktorenȱ werȬ denȱfolgendeȱElementeȱfestgehalten:ȱ – – – – – –

dieȱUnternehmensstrategie,ȱ dieȱfinanziellenȱAbläufeȱ(BudgetierungȱwurdeȱschonȱalsȱBeispielȱerwähnt),ȱ dieȱPersonalbelange,ȱ dieȱSicherheitsrichtlinienȱderȱFirma,ȱ dieȱBedürfnisseȱderȱKunden,ȱ dieȱBedürfnisseȱderȱAnwender.ȱ

UnterȱendogenenȱEinflüssenȱwerdenȱalleȱProzessabhängigkeitenȱzwischenȱdenȱITȬ Prozessenȱverstanden.ȱEsȱistȱanȱderȱStelleȱwichtig,ȱdieȱKonsistenzȱderȱAbhängigkeiȬ tenȱzuȱgewährleisten.ȱD.h.ȱwennȱProzessȱP0XȱinȱAbhängigkeitȱzuȱP0Yȱsteht,ȱmussȱ sichergestelltȱwerden,ȱdassȱbeiȱderȱBeschreibungȱdesȱProzessesȱP0YȱdieseȱberückȬ sichtigtȱwirdȱundȱerscheint.ȱ Dieȱ Komplexitätȱ derȱ Einführungȱ derȱ ITȬProzesseȱ liegtȱ sicherȱ inȱ denȱ zahlreichenȱ Abhängigkeitenȱ zwischenȱ diesenȱ ITȬProzessen.ȱ Esȱ kannȱ anȱ derȱ Stelleȱ festgehaltenȱ werden,ȱ dassȱ eineȱ ITȬOrganisationȱ nurȱ eineȱ guteȱ Leistungȱ erbringenȱ kann,ȱ wennȱ alleȱProzesseȱgutȱmiteinanderȱfunktionierenȱundȱharmonieren.ȱUmȱdieseȱKompleȬ xitätȱbewältigenȱzuȱkönnen,ȱsollȱeinȱgewissesȱGespürȱfürȱjedenȱProzessȱentwickeltȱ werden.ȱ Damitȱ werdenȱ dieȱ Abgrenzungenȱ zwischenȱ denȱ Prozessenȱ klarȱ undȱ dieȱ Schnittstellenȱ sauberȱ definiert.ȱ Anderseitsȱ bestehtȱ dieȱ Gefahr,ȱ dassȱ amȱ Schlussȱ jeȬ derȱProzessȱmitȱallenȱProzessenȱinȱAbhängigkeitȱsteht,ȱsoȱdassȱdasȱganzeȱProzessȬ gebildeȱabsolutȱunübersichtlichȱundȱunbeherrschbarȱwirkt.ȱ Insgesamtȱwerdenȱ64ȱProzessabhängigkeitenȱidentifiziert.ȱ

ȱ

21

3ȱȱProzessabhängigkeitenȱ

P03ȱȱ

P04ȱȱ

P07ȱȱ

P08ȱȱ

P09ȱȱ

P10ȱȱ

P11ȱȱ

P12ȱȱ

P13ȱȱ

P14ȱȱ

P15ȱȱ

P16ȱȱ

P17ȱȱ

ȱ

xȱ

xȱ

ȱ

xȱ

xȱ

ȱ

ȱ

xȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

P02ȱ

xȱ

ȱ

ȱ

ȱ

ȱ

ȱ

xȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

P03ȱȱ

xȱ

ȱ

ȱ

ȱ

ȱ

ȱ

xȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

P04ȱȱ

ȱ

ȱ

ȱ

ȱ

ȱ

xȱ

ȱ

ȱ

xȱ

ȱ

ȱ

ȱ

ȱ

ȱ

xȱ

ȱ

ȱ

P05ȱȱ

xȱ

ȱ

ȱ

ȱ

ȱ

xȱ

ȱ

ȱ

xȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

P06ȱȱ

xȱ

ȱ

ȱ

xȱ

xȱ

ȱ

xȱ

ȱ

ȱ

xȱ

xȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

P07ȱȱ

ȱ

xȱ

xȱ

ȱ

ȱ

xȱ

ȱ

xȱ

xȱ

ȱ

ȱ

ȱ

ȱ

xȱ

ȱ

ȱ

ȱ

P08ȱȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

xȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

P09ȱ

xȱ

ȱ

ȱ

xȱ

xȱ

ȱ

xȱ

ȱ

ȱ

xȱ

ȱ

ȱ

ȱ

xȱ

ȱ

ȱ

ȱ

P10ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

xȱ

ȱ

ȱ

xȱ

ȱ

ȱ

xȱ

ȱ

ȱ

ȱ

xȱ

xȱ

P11ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

xȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

xȱ

xȱ

xȱ

ȱ

ȱ

P12ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

xȱ

ȱ

ȱ

xȱ

xȱ

ȱ

ȱ

xȱ

P13ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

xȱ

xȱ

ȱ

ȱ

ȱ

ȱ

ȱ

P14ȱȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

xȱ

ȱ

xȱ

ȱ

xȱ

xȱ

ȱ

ȱ

xȱ

xȱ

ȱ

P15ȱ

ȱ

ȱ

ȱ

xȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

xȱ

ȱ

ȱ

xȱ

ȱ

ȱ

ȱ

P16ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

xȱ

ȱ

ȱ

ȱ

xȱ

ȱ

ȱ

xȱ

P17ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

ȱ

xȱ

ȱ

xȱ

ȱ

ȱ

ȱ

xȱ

ȱ

̕ȱ

5ȱ

2ȱ

2ȱ

3ȱ

3ȱ

6ȱ

6ȱ

1ȱ

6ȱ

5ȱ

4ȱ

4ȱ

2ȱ

6ȱ

3ȱ

3ȱ

3ȱ

P06ȱȱ

P02ȱȱ

P01ȱ

P05ȱȱ

ȱ

P01ȱȱ

Tabelleȱ3:ȱMIIPȬProzessabhängigkeitenȱ

ȱ Mitȱ mehrȱ alsȱ 60ȱ Prozessabhängigkeitenȱ zeigtȱ dieȱ ITȬProzesslandkarteȱ eineȱ hoheȱ Prozessintegration,ȱdieȱschwerȱzuȱbewältigenȱist.ȱ InsbesondereȱkennzeichnenȱsichȱvierȱProzesseȱalsȱSchlüsselprozesseȱaufgrundȱdeȬ renȱhoherȱZahlȱanȱSchnittstellen:ȱ – – – – ȱ

22 ȱ

P06ȱȬȱITȬProjektȱPortfolioȱManagement,ȱ P07ȱȬȱCapacityȱ/ȱAvailabilityȱManagement,ȱ P09ȱȬȱServiceȱManagement,ȱ P14ȱȬȱITȬBetriebȱ&ȱKonfigurationsmanagement.ȱ

3.1ȱȱGesamtüberblickȱ

UmȱdieȱKomplexitätȱderȱProzessintegrationȱdarzustellen,ȱzeigtȱdieȱfolgendeȱAbbilȬ dungȱ eineȱ vereinfachteȱ Sichtȱ derȱ Prozessabhängigkeitenȱ zwischenȱ denȱ ITȬ Prozessen.ȱ

Bildȱ6:ȱÜberblickȱüberȱdieȱMIIPȬProzessabhängigkeitenȱ

InȱdemȱBildȱsindȱdieȱsechsȱdefiniertenȱexogenenȱFaktorenȱ(FirmenȬStrategie,ȱFinanzȱ &ȱ Controlling,ȱ Personalabteilung,ȱ Unternehmenssicherheit,ȱ Kundenȱ undȱ AnwenȬ der)ȱerkennbar.ȱ Umȱ dieȱ Abhängigkeitenȱ zwischenȱ denȱ ITȬProzessenȱ imȱ Einzelnenȱ zuȱ verstehen,ȱ werdenȱ dieseȱ erstmalsȱ aufȱ denȱ strategischen,ȱ taktischenȱ undȱ operativenȱ Ebenenȱ erläutert.ȱ Dieseȱ werdenȱ dannȱ genauerȱ proȱ Funktionsgruppeȱ beschrieben,ȱ umȱ dieȱ IntimitätȱderȱProzessinteraktionenȱzuȱverstehen.ȱ

ȱ

23

3ȱȱProzessabhängigkeitenȱ

Strategischȱ istȱ alsȱ „längerfristigȱ ausgerichtetesȱ planvollesȱ Anstrebenȱ einerȱ vorteilȬ haftenȱLageȱoderȱeinesȱZiels“ȱgemeint.ȱDerȱProzessȱP01ȱȬȱITȬStrategieȱstelltȱdeȱfactoȱ dasȱwichtigsteȱElementȱfürȱdieȱDefinitionȱderȱITȬStrategie.ȱ ȱ Dankȱ derȱ Prozesslandkarteȱ istȱ esȱ möglich,ȱ dieȱ wichtigenȱ strategischenȱ Elementeȱ ausȱdenȱProzessabhängigkeitenȱzuȱerkennenȱ(sieheȱBildȱ7):ȱ – DefinitionȱderȱnötigenȱITȬServicesȱ(sieheȱPfadȱ1):ȱimȱRahmenȱeinesȱServiceȬ Katalogsȱ werdenȱ dieȱ zuȱ erbringendenȱ ITȬServicesȱ definiertȱ undȱ dieȱ StückȬ kostenȱfestgelegt.ȱ – Definitionȱ derȱ strategischenȱ Projekteȱ (sieheȱ Pfadȱ 2):ȱ imȱ Rahmenȱ desȱ ProȬ jektportfoliosȱ werdenȱ dieȱ wertvollenȱ Projekteȱ identifiziert,ȱ soȱ dassȱ dieȱ UnȬ ternehmensstrategieȱdurchȱdieȱITȱunterstütztȱwerdenȱkann.ȱ – Definitionȱ derȱ ITȬArchitekturȱ undȱ Standardsȱ(sieheȱPfadȱ3):ȱDieȱArchitekȬ turȱbietetȱeinenȱwichtigenȱRahmenȱan,ȱsoȱdassȱkonzipierteȱITȬLösungenȱkonȬ zeptionellȱ richtigȱ aufgesetztȱ werden.ȱ Anȱ dieserȱ Stelleȱ werdenȱ zumȱ Beispielȱ ITȬSicherheitsrichtlinienȱausgearbeitet.ȱ – Definitionȱ derȱ ITȬOrganisationȱ (sieheȱ Pfadȱ 4):ȱ Derȱ Entscheidȱ „makeȬorȬ buy“ȱsollȱfürȱdieȱErbringungȱderȱITȬDienstleistungenȱgetroffenȱwerden.ȱFürȱ dieȱinternenȱzurȱVerfügungȱgestelltenȱRessourcenȱwirdȱeineȱITȬOrganisationȱ abgewickelt.ȱEinȱOrganigrammȱfürȱdieȱentsprechendeȱITȬOrganisationȱwirdȱ erstellt.ȱ – Sourcingȱ(sieheȱPfadȱ5):ȱimȱRahmenȱderȱSourcingȬStrategieȱwerdenȱdieȱentȬ sprechendenȱITȬPartnerȱidentifiziertȱundȱdefiniert.ȱEineȱlangfristigeȱZusamȬ menarbeitȱ istȱ oftȱ notwendig,ȱ umȱ dieȱ erwartetenȱ Leistungenȱ erntenȱ zuȱ könȬ nen.ȱ – Qualitätsmerkmaleȱ (sieheȱ Pfadȱ 6):ȱ dieȱ Qualitätsmerkmaleȱ fürȱ dieȱ ErbrinȬ gungȱ derȱ ITȬDienstleistungenȱ werdenȱ festgelegt,ȱ gemäßȱ denȱ Bedürfnissenȱ desȱUnternehmens.ȱ

24 ȱ

3.3ȱȱAufȱdieȱtaktischeȱEbeneȱ(1ȱJahrȱ>ȱZeithorizontȱ>ȱ1ȱMonat)ȱ

Bildȱ7:ȱMIIPȬProzessabhängigkeitenȱaufȱstrategischerȱEbeneȱ

Esȱmussȱauchȱfestgehaltenȱwerden,ȱdassȱFinanzȱundȱQualitätȱengȱmitȱServiceȱMaȬ nagementȱ undȱ Portofolioȱ Managementȱ zusammenhängen.ȱ Dafürȱ nehmenȱ dieȱ HRȱ undȱStandardsȬArchitekturȬProzesseȱbeideȱEinflussȱaufȱdenȱCapacityȱ/ȱAvailabilityȬ Prozess.ȱDiesȱwirdȱnochȱimȱnächstenȱAbsatzȱaufȱtaktischerȱEbeneȱkommentiert.ȱ

UnterȱTaktikȱwerdenȱderȱoptimaleȱEinsatzȱvonȱRessourcenȱ(PersonalȱundȱMaterial)ȱ undȱ dieȱ koordinierteȱ Anwendungȱ derȱ verfügbarenȱ Mittel,ȱ umȱ eineȱ ITȬ Dienstleistungȱzuȱerbringen,ȱverstanden.ȱ Einȱ ersterȱ Kreislaufȱ (sieheȱ Bildȱ 8,ȱ Pfadȱ 7)ȱ befasstȱ sichȱ mitȱ derȱ Qualitätȱ derȱ ITȬ Dienstleistungen.ȱDieȱQualitätȱderȱITȬProjekteȱwirdȱimȱRahmenȱdesȱPortfolioȱMaȬ nagementȬProzessesȱ festgehalten,ȱ währendȱ dieȱ Qualitätȱ derȱ geliefertenȱ Servicesȱ durchȱdieȱMessungȱderȱSLAsȱveröffentlichtȱwird.ȱ ȱ

ȱ

25

3ȱȱProzessabhängigkeitenȱ

Bildȱ8:ȱMIIPȬProzessabhängigkeitenȱaufȱtaktischerȱEbeneȱ

Dieȱ zweiȱ Qualitätsaspekteȱ sindȱ nichtȱ unabhängig,ȱ sondernȱ kombinierenȱ sich.ȱ Dieȱ Qualitätȱderȱabgeschlossenenȱ Projekteȱbeeinflusstȱ oftȱ dieȱ Qualitätȱ derȱ ITȬServices.ȱ Leidenȱ dieȱ ITȬServicesȱ unterȱ Qualitätsmangel,ȱ dannȱ sindȱ oftȱ dieȱ Ursachenȱ inȱ derȱ schlechtenȱQualitätȱderȱProjektlieferungȱzuȱfinden.ȱ Einȱ zweiterȱ Kreislaufȱ (sieheȱ Pfadȱ 8)ȱ stelltȱ denȱ finanziellenȱ Zyklusȱ dar.ȱ Durchȱ dieȱ BudgetierungȱwerdenȱsowohlȱInvestitionsbudgetsȱ(viaȱPortfolioȱundȱProjektmanaȬ gement)ȱ alsȱ auchȱ Betriebsbudgetsȱ (viaȱ Serviceȱ Management)ȱ definiertȱ undȱ überȬ wachtȱ(IstȬKosten,ȱForecast).ȱ EinȱdritterȱKreislaufȱ(sieheȱPfadȱ9)ȱbeziehtȱsichȱaufȱdieȱKapazitätsplanung.ȱAnȱdieȬ serȱ Stelleȱ werdenȱ unterschiedlicheȱ Parameterȱ berücksichtigt,ȱ umȱ einerseitsȱ dieȱ Bedürfnisseȱ derȱ Servicesȱ undȱ Projekteȱ undȱ ContinuityȬAnforderungenȱ inȱ AnsȬ pruchȱzuȱnehmenȱundȱanderseitsȱdieȱVerfügbarkeitȱderȱpassendenȱRessourcenȱzuȱ gewährleisten.ȱ Dieȱqualitativenȱ Kriterienȱ wieȱ Kompetenz,ȱ Wissenȱ oderȱ Erfahrungȱ spielenȱanȱderȱStelleȱeineȱwichtigeȱRolle.ȱ ZumȱSchlussȱwirdȱdasȱContinuityȱManagementȱ(sieheȱPfadȱ10)ȱalsȱeigenerȱwichtiȬ gerȱStreamȱdargestellt.ȱ ȱ

26 ȱ

3.4ȱȱAufȱdieȱoperativeȱEbeneȱ(Zeithorizontȱ Leiter Account Mgt - 4 Std. => CIO - 1 Tag => CEO - 2 Std. => Leiter Account Mgt - 2 Tage => CIO - 2 Tage => Leiter Account Mgt

Die formale Vereinbarung mit exakter Definition der technischen Parameter eines SLA wird mit Hilfe von Service Level-Spezifikation (SLS) oder Service Level Objective (SLO) durchgeführt. Kriterien für eine angemessene Anzahl von SLOs sind: – Alle SLOs zusammen decken mengenmäßig (Prozesse, Transaktionen, Geschäftsvorfälle) den Großteil des betrachteten Services und / oder die kritischsten Funktionalitäten ab – Die Anzahl der SLOs eines SLA bleibt überschaubar, d.h. im unteren zweistelligen Bereich

102

7.1 P09 - Service Management-Prozess Die wesentlichen Bestandteile eines SLO sind: Tabelle 26: SLO-Definitionsmerkmale

– was und / oder wie viel wird geliefert? – präzise Beschreibung mit Messstrecke und Messverfahren

Menge bzw. Leistung

– definiert, welche Eigenschaften ein Liefergut aufweisen muss, damit es anerkannt wird – anfallende Kosten und / oder Aufwände – Maximum oder Durchschnitt – Verweis auf Budget- oder Projektplanung

Qualität Kosten

– eine physisch existierende Person oder eine Rolle, die mit wechselnden Personen stets besetzt ist – keine Gruppen als Gesamtheit – keine Rollen, die nur sporadisch wahrgenommen werden

Verantwortlicher

In der folgenden Tabelle werden Beispiele in jeder Kategorie gezeigt: Tabelle 27: Beispiele SLOs

Menge bzw. Leistung

Verfügbarkeit – 98,5% (Grad der Verfügbarkeit) – Mo-Fr, 8:00 – 17:00 Uhr (Zeitraum) – für die Prozesskette „Auftrag eingeben -> speichern -> weiterleiten -> Antwort erhalten“ genaue Messpunkte definieren – pro Kalendermonat (Messperiode) – 3 Stunden maximale Ausfalldauer für ein einzelnes Ereignis (maximale Wiederanlaufzeit) – max. 3% der Clients simultan betroffen (für verteilte Anwendungen) Performance – max. 2 Sekunden von Drücken „Enter“ bis Bildschirmanzeige für Maske Auftragsanlage (Antwortzeit) – max. 4 Stunden Batchdauer und 2 Stunden CPU-Zeit von Start Batchnacht – mindestens 40.000 Transaktionen pro Stunde.

103

7 Funktionsgruppe „Account Management“ – bei täglicher Datenlieferung: maximal 1 Ausfall / Verspätung pro Jahr – bei technischen Komponenten: maximal 1 Ausfall von höchstens 2 Stunden pro Monat – beim Monatsabschluss: abgeschlossen bis um 6:00 Uhr des ersten Werktages des neuen Monats – Antworten des Helpdesk: 90% der Anrufer betrachten das Problem als gelöst

Qualität

Aufwand Kosten

oder

für eine Dienstleistung: – Gesamtaufwand maximal 1500 Stunden / Jahr – durchschnittlich 15 PT pro Antrag, maximal 60 PT für einen einzelnen Antrag für Kosten: – Kosten maximal 400.000 CHF für Betrieb (Personalund Sachaufwand) und laufende Investitionen (z.B. Hardwareerneuerung) – maximal 100 CHF / Monat und pro 100 GB Speicherplatz

104

7.1 P09 - Service Management-Prozess

7.1.1

Hauptaktivitäten „P09 – Service Management“

In der folgenden Tabelle sind die Hauptaktivitäten des Prozesses dargestellt. Tabelle 28: Hauptaktivitäten „P09 – Service Management“

Hauptschritte

Beschreibung

Definition der Services

Das Unternehmen braucht IT-Services, um seine Dienstleistungen erbringen zu können. Die IT-Organisation stellt sicher, dass die notwendigen IT-Services zur Verfügung gestellt werden. Dafür werden innerhalb eines Service Katalogs allgemeine Rahmenbedingungen (z.B. Betriebszeiten), aber auch die spezifischen Bedingungen eines Service definiert. Pro Service werden Qualitätsmerkmale definiert, die messbar sind.

Services vereinba- Der IT Provider und die Service-Abnehmer einigen sich über ren die Definition des Service, die Qualitätsmerkmale, deren Messung und die Mengen, die in Anspruch genommen werden. Erbringung der Services

Die vereinbarten Services, die für die Firma notwendig sind, werden von IT-Organisationseinheiten erbracht.

Messen der Qualitätsmerkmale der erbringenden Services

Jeder definierte Service beinhaltet Merkmale, die am Ende des Monats gemessen werden. Ein SL, der nicht gemessen werden kann, bringt nichts und soll als solcher nicht vereinbart werden.

Rapportieren der Ergebnisse

Die Ergebnisse der SL-Messungen werden veröffentlicht.

Bei SL Verletzung, Bei SL-Verletzung wird der Qualitätsmanagement-Prozess Maßnahmen defi- eingeschaltet. Eine Analyse wird durchgeführt, um die kornieren rektiven Maßnahmen, sowohl technisch als organisatorisch, einzuleiten. Prüfung der Servi- Die Service Levels werden regelmäßig überprüft und wenn ce Levels nötig angepasst. Die Struktur der IT-Services soll am einfachsten der Unternehmensorganisation entsprechen, und zwar mit der Trennung zwischen allgemeinen IT-Services (Desktop, Netzwerk,...) und bereichsspezifischen Services (Betreuung eines spezifischen IT-Systems).

105

7 Funktionsgruppe „Account Management“

7.1.2

Rollen „P09 – Service Management“

Die folgenden Rollen sind notwendig, um den Prozess abwickeln zu können.

Business

Tabelle 29: Prozessrollen „P09 – Service Management“

Auftragnehmer – bestellt die IT-Services und unterschreibt die entsprechenden SLAs, – wird über die Einhaltung der Service Levels regelmäßig informiert. CIO – definiert die IT-Strategie, insbesondere welche IT-Services für das Unternehmen angeboten werden oder nicht.

IT

Leiter Service Management / Service Manager – definiert, in Zusammenarbeit mit dem IT-Betriebsleiter, die unterschiedlichen Services (Bündelung von Dienstleistungen, wie z.B. 1 Arbeitsplatz = PC + LAN -Anschluss + Mailbox + PrinterAnschluss + Telefon + Helpdesk), – veröffentlicht den Service-Katalog, – stellt sicher, dass die IT-Services von den Auftragnehmern vereinbart werden. IT-Betriebsleiter – ist für die Messung der Qualitätsmerkmale zuständig. Account Manager – identifiziert Bedürfnisse für neue Services, – informiert die Kunden über die Qualität der Services, vor allen die Auftragnehmer über mögliche SL-Verletzungen. IT-Qualitätsbeauftragter –

kontrolliert, dass die SLs definiert, vereinbart, gemessen und rapportiert werden, – stellt bei SLA-Verletzung sicher, dass die entsprechenden Maßnahmen, gemäß Qualitätsmanagement-Prozess, in die Wege geleiten werden.

106

7.1 P09 - Service Management-Prozess

7.1.3

Prozessbeschreibung „P09 – Service Management“

Wie in der folgenden Abbildung dargestellt, ist der Prozess „P14 - IT-Betrieb und Konfigurationsmanagement“ eingebettet in dem Prozess „P09 - Service Management“. ITStrategie Anforderungsmanagement

Definition der IT-Services

IT-Qualitätsmanagement IT Financial Management

IT-Strategie Service Anforderung

CIO Account Manager

Service-Katalog

Leiter Service Mgt

SLAs

Auftragnehmer, Leiter Service Mgt

erbrachtete Dienstleistungen

IT-Betriebsleiter

Messung der Qualitätsmerkmale

IT-Betriebsleiter

Services kontraktieren

Capacity – Availability Mgt

Betrieb Konfiguration

Servicemerkmale messen

IT-Qualitätsmanagement

Input Output

nein

Qualität in Ordnung ?

Qualitätsprüfungen SL-Verletzungen

Anforderungsmanagement

nein

IT-Betriebsleiter, Leiter Service Mgt, IT-Qualitätsbeauftragter

Rapportieren (Berichte)

SL-Berichte Kundeninformation

IT-Betriebsleiter Account Manager

SL in Ordnung ?

Prüfung der Service Definition

Leiter Service Mgt

ja

Ende Bild 31: Prozessbeschreibung „P09 - Service Management“

107

7 Funktionsgruppe „Account Management“

7.2 P10 – Anforderungsmanagement-Prozess Der Anforderungsmanagement-Prozess gehört zu der Prozessgruppe „Account Management“. Das Ziel ist, Kundenanforderungen prompt und prozessgerecht durchführen zu können. Der Account Manager spielt eine entscheidende Rolle, um einerseits den Fachbereich zu beraten, zu unterstützen, und anderseits sicherzustellen, dass die Anforderungen von der IT-Organisation im Rahmen eines Releases oder eines Projektes richtig bearbeitet werden. Für alle wichtigen Applikationen des Unternehmens werden aus diesem Grunde ein Application Owner und sein Stellvertreter ernannt. Der Application Owner und sein Stellvertreter sollen in den Fachbereichen angesiegelt werden. Diese gelten als Bindeglied zwischen den Fachbereichen und der Informatik.

7.2.1

Hauptaktivitäten „P10 – Anforderungsmanagement“

In der folgenden Tabelle sind die Hauptaktivitäten des Prozesses dargestellt. Tabelle 30: Hauptaktivitäten „P10 – Anforderungsmanagement“

Hauptschritte

Beschreibung

Anforderung entgegennehmen

Fachbereiche stellen Anforderungen, um BusinessBedürfnisse abdecken zu können. Als Beispiel: ein Bereich braucht Datenauswertungen bezüglich einer bestimmten Kundengruppe. Dies wird als Kleinauftrag abwickelt. Anforderungen können auch aus den Prozessen „Incident Management“ und „Problem Management“ kommen.

Anforderung analysieren

108

Eine neue Anforderung wird zuerst analysiert. Handelt es sich um eine Anforderung, die durch einen angebotenen ITService abgedeckt werden kann, wird eine Aufwandschätzung stattfinden und die Anforderung im Rahmen des Service entgegengenommen. Falls kein Service zur Verfügung steht, wird die Anforderung an den Service ManagementProzess weitergeleitet.

7.2 P10 – Anforderungsmanagement-Prozess Hauptschritte

Beschreibung

Aufwände schätzen

Eine erste Aufwandschätzung findet statt. Wenn der Aufwand kleiner als 10 Tage ist, wird der Release Management-Prozess in Anspruch genommen: Planung => Genehmigung => Programmierung, wenn nötig => Test => Durchführung. Wenn der Aufwand größer als 10 Tage ist (projektrelevant), wird der Portfolio Management-Prozess in Anspruch genommen: Offerte Vorstudie => Antrag Vorstudie.

Anforderung entweder durch Portfolio Management oder Release Management abwickeln lassen

7.2.2

Die Durchführung der Anforderung erfolgt gemäß den definierten Prozessen (Release oder Portfolio). Es kann auch passieren, dass die Anforderung nicht durchgeführt wird, falls keine Genehmigung gegeben wird.

Rollen „P10 – Anforderungsmanagement“

Die folgenden Rollen sind notwendig, um den Prozess abwickeln zu können. Tabelle 31: Prozessrollen „P10 – Anforderungsmanagement“

Auftraggeber

Business

– gibt eine Anforderung in Form eines Auftrags, – prüft, dass die Anforderung korrekt durchgeführt wurde. Application Owner – nimmt die Anforderung entgegen, analysiert diese, – stellt die Priorisierung sicher, – stellt sicher, dass allfällige Dokumentation (Handbücher, Weisungen,…), wenn notwendig, angepasst wird, – gewährleistet einen guten Ausbildungsstand bei den Anwendern und sorgt für den notwendigen Wissenstransfer, – informiert die User über vorgenommene Änderungen der Anwendung.

109

7 Funktionsgruppe „Account Management“ IT-Anwender – stellt eine Anforderung zusammen, um ein Business-Bedürfnis abzudecken, – prüft, dass das Bedürfnis korrekt adressiert wurde. IT-Betriebsleiter – leitet Anforderungsfragen vom Problem Management an das Account Management weiter. Helpdesk Agent – leitet Anforderungsfragen vom Incident Management an das Account Management weiter.

IT

Account Manager – nimmt die Anforderung entgegen und erstellt einen Auftrag, – analysiert die Anforderung und prüft, ob sie im Rahmen der ITServicepalette abgedeckt ist, – prüft den Aufwand dank einer Aufwandschätzung, – leitet, wenn nötig, die Anforderung weiter, entweder im Bereich Portfolio Management oder Release Management. Application Expert – prüft den IT-Auftrag auf Verständlichkeit und Vollständigkeit, – erstellt eine Aufwandschätzung und schlägt eine Detailplanung (Aktivitäten + Ressourcenverfügbarkeit) vor. System Owner – –

110

prüft die Planung bezüglich System-Planung, stellt die Infrastruktur zur Verfügung.

7.2 P10 – Anforderungsmanagement-Prozess

7.2.3

Prozessbeschreibung „P10 – Anforderungsmanagement“

Der Prozess „Anforderungsmanagement“ ermöglicht einen „bottom-up“-Ansatz, wie in der folgenden Prozessbeschreibung dargestellt. Anforderung

Incident Management

Anforderung

Anforderung registrieren

Problem Management

Anforderung analysieren

Service Management

ja

Neuer Service ? nein

Projekt Portfolio Management

Input Output

ja

Aufwand > 10 Tage ?

Incident / Problem Ticket

Anwender, Auftraggeber Helpdesk Agent IT-Betriebsleiter

Auftrag

Account Manager

Erste Analyse

Account Manager Application Owner

Prüfung, ob der Service vorhanden ist

Account Manager

Offerteanfrage

Auftraggeber

Aufwandschätzung

Account Manager

Kleinauftrag

Account Manager

Priorisierung der Aufträge, Wunschtermine

Application Owner, Account Manager

IT-Auftrag

Application Expert

Auftrag Durchführung

System Owner

nein

Kleinauftrag erstellen

Priorität festlegen

Release Management

Ende

Umsetzung Bestätigung

Anwender, Auftraggeber

Bild 32: Prozessbeschreibung „P10 - Anforderungsmanagement“

111

7 Funktionsgruppe „Account Management“

7.3 Prozessabhängigkeiten „Account Management“ Das folgende Bild zeigt die Prozessabhängigkeiten der zwei im „Account Management„ definierten Prozesse mit neun zusätzlichen Prozessen (IT Strategie, Qualität Management, IT Financial Management, Portfolio Management, Capacity / Availability Management, Release Management, IT Betrieb & Konfiguration, Incident Management, Problem Management).

QualitätsMerkmale

Strategie Service Definition

Verfügbarkeit

Qualität

SL Verletzung

SL Qualität

Betriebsbudget

Financial Notwendige Kapazität

Betrieb Kosten

Service Bedürfnisse

Service Mengen Service Katalog

Service Check Neues Service

Anforderung

SL Bericht Fachkonzept

Prüfung Projektidee

Anforderung

Capacity Availabilty

SL Definitionen

Service

SLAs

Projekt Portfolio

Kleinauftrag Messung der Qualitätsmerkmale

Auftrag

Auftrag

Anforderung

Anforderung

Problem

Incident

Bild 33: MIIP-Prozessabhängigkeiten „Account Management“

112

SLA Ziele

Release Auftrag

Release

Betrieb Konfig.

7.3 Prozessabhängigkeiten „Account Management“

7.3.1

Prozessabhängigkeit „P09 – Service Management“

P09 – Service Management

Service-Definition

P09 – Service Management

Betriebkosten

P09 – Service Management

P01 – IT-Strategie

Service-Katalog Betriebsbudget Qualitätsmerkmale Verfügbarkeit

P04 – IT Financial Management P05 – Qualitätsmanagement

SL-Qualität SL-Verletzung P09 – Service Management P09 – Service Management

Service-Mengen Notwendige Kapazität Neuer Service Service-Katalog

P07 – Capacity / Availability Management P10 – Anforderungsmanagement

Service Check Prüfung P09 – Service Management

Service-Definitionen SLA-Ziele

P14 – IT-Betrieb & Konfiguration Management

Messung der Qualitätsmerkmale SL-Bericht Ein IT-Service ist innerhalb des Service-Katalogs mit den entsprechenden genehmigten SLAs definiert. Dieser wird aber im Rahmen des IT-Betriebs erbracht. Damit der Kreislauf zwischen Service Management und IT-Betrieb geschlossen wird, findet die Überwachung der SLA-Einhaltung beim Service Management statt. Weiterhin wird die Qualität, im Sinne von Einhaltung oder Verletzung der SLAs, gemessen und rapportiert. Falls ein SLA gravierend oder mehrmals verletzt wurde, sollte ein Qualitätsaudit durchgeführt werden. Die Ergebnisse der SLA-Messung sollen regelmäßig, zum Beispiel monatlich, an dem entsprechenden Service-Empfänger rapportiert werden. Die Kommunikation zu den Kunden ist sicher entscheidend, um Missverständnisse über die subjektive Qualitätswahrnehmung eines Service zu vermeiden. Oft befindet sich die interne Informatik in einem Spannungsfeld zwischen Kundenzufriedenheit (nach dem Motto „Der Kunde ist König“) und Ersparnisziele, welche nicht immer realistisch sind.

113

7 Funktionsgruppe „Account Management“

7.3.2

Prozessabhängigkeit „P10 – Anforderungsmanagement“

P10 – Anforderungsmanagement

Projektidee Fachkonzept

P10 – Anforderungsmanagement

Neuer Service Service-Katalog

P06 – IT Projekt Portfolio Management

P09 – Service Management

Service Check Prüfung P10 – Anforderungsmanagement

Kleinauftrag

P10 – Anforderungsmanagement

Anforderung

P10 – Anforderungsmanagement

Anforderung

Release Auftrag Auftrag Auftrag

P12– Release Management P16 – Incident Management P17 – Problem Management

Eine wichtige Funktion des Account Managements ist, die Anforderungen der Anwender entgegen zu nehmen. Die Anforderungen kommen aus verschiedenen Quellen: – direkt von den Anwendern, – aus dem Incident-Prozess (das Incident Ticket wird in diesem Fall abgeschlossen und ein Auftrag wird dafür eröffnet), – aus dem Problem-Prozess (das Problem Ticket wird in diesem Fall abgeschlossen und ein Auftrag wird dafür eröffnet). Die Anforderungen werden erst analysiert und gemäß Governance-Modell entweder als: – Neue Services an den Prozess „Service Management“ weitergeleitet, – Projektidee ins Projekt-Portfolio eingefügt, – Kleinauftrag für ein Applikationsrelease durchgearbeitet.

114

8 Funktionsgruppe „Implementierung“ Drei Prozesse bilden die Funktionsgruppe „Implementierung“: – P11 - Projektmanagement, – P12 - Release Management, – P13 - Applikationsentwicklung die in diesem Kapitel detailliert beschrieben werden. Aufgrund der Prozessabhängigkeiten müssen fünf zusätzliche Prozesse berücksichtigt werden: – P06 - Portfolio Management, – P10 - Anforderungsmanagement, – P14 - IT-Betrieb & Konfiguration, – P15 - Supplier Management – P17 - Problem Management. Die Beziehungen zu diesen fünf Prozessen werden am Ende des Kapitels erläutert.

8.1 P11 - IT Projektmanagement-Prozess Als Projekte werden Aufgaben bezeichnet, die einmalig, zeitlich begrenzt, komplex und darum risikobehaftet sind. Das Projektmanagement hat zum Ziel, das Risiko von Projekten einzugrenzen, deren Wirtschaftlichkeit sicherzustellen und eine Steuerung des geplanten Projektnutzens zu ermöglichen. Manche denken, dass Projektaufgaben genau so lästig wie Mücken sind. Diese heißen doch „Mosquito“ auf Englisch: MOney, Skills, QUality, Information, Time and Organisation! Jedes Projekt beginnt mit einer Idee, etwas zu verändern, zu optimieren, zu steuern, zu erneuern oder einer Anforderung von außen (Kunden, Gesetz, Anpassung von externen Gegebenheiten usw.). In der Regel ist diese Idee schon zuvor in die Mittel- und Kurzfristplanung eingeflossen und budgetiert. Erfolgreiche Projekte starten mit einer intensiven und gewissenhaften Vorbereitung, in der der Rahmen des Projektes (Ausgangslage, Ziele, Abgrenzungen, offene Punkte usw.) definiert wird. Die Vorbereitung (Projektinitiierung) endet mit dem Antrag zur Vorstudie. Wenn der Antrag bewilligt wird, ist das Gesamtprojekt ins Portfolio aufgenommen. Allerdings wird das Gesamtprojekt aus Portfoliosicht nach der Vorstudie neu beurteilt. Erst zu diesem Zeitpunkt ist eine zuverlässige Aussage zum Business Case vorhanden und damit eine vernünftige Entscheidungsgrundlage gegeben.

115

8 Funktionsgruppe „Implementierung“

Initiative der Geschäftsleitung

Langfristplanung der Informationssysteme Angebot einer externen Firma

Anforderungskatalog

Geschäftsideen

Informeller Projektstart

Projektinitiierung

Vorstudie

Bestimmung und Besetzung des Projektleiters und des Projektteams

Projektablage

Projektablage

Projektablage

Projekt Projektscope

Konzept

Realisierung / Test

Einführung Projektabschluss

Bild 34: Projektablauf

Für die Dauer eines Projektes bedarf es einer spezifischen temporären Projektorganisation, welche sich für das Projekt einsetzt, es steuert und kontrolliert. Diese sorgt für klare Zuständigkeiten und Verantwortlichkeiten. Eine durchdachte, strukturierte und klare Projektorganisation ist äußerst wichtig für das Gelingen

116

8.1 P11 - IT Projektmanagement-Prozess eines Projektes. Eine standardisierte, generische Projektorganisation für Projekte zeigt die folgende Abbildung.

Sponsor Steuerungsausschuss Fach-Projektleiter IT-Projektleiter

Projekt Office

Qualitätssicherung

Technisches Team IT-Projektleiter

IT-Experten

Application Team(s) Application Team(s) Applikation Team(s) Teamleader Teamleader Teamleiter

Information Management

Projekt- und Portfolio- Management Support

Geschäftsleitung und Projekt-Portfolio Management

Business Experts Business Experts Fachexperten Key Users Key Users Key Users Experts Application Application Experts Application Expert

Applikation und technischer Support

Bild 35: Generische Projektorganisation

Projektorganisationen können beim Start nicht immer über alle Phasen vollständig und bleibend definiert werden. Somit können sie für jede Phase anders aussehen. Eine Anpassung der Organisation eines Projektes für die nächste Phase ist möglich und wird durch das STC (Steering Committee = Steuerungsausschuss) für die nächste Phase abgenommen. In kritischen Fällen kann die Projektorganisation auch in einer laufenden Phase angepasst werden. Dies sollte jedoch nur mit Einverständnis durch das STC erfolgen. Projekte leben in einem Umfeld. Dieses Umfeld wird durch geschäftsgetriebene Themen wie Unternehmensstrategie und -steuerung (Portfoliomanagement) sowie technische Rahmenbedingungen (Betrieb) bestimmt. Es ist von Vorteil, sich nach dem Phasenmodell zu richten. Damit können pro Projektphase klare Lieferobjekte definiert und dank Erfahrungswerten eine realistische Planung gewährleistet werden.

117

8 Funktionsgruppe „Implementierung“ Folgende Phasen werden definiert: – – – –

Vorstudie, Konzept, Realisierung & Test, Einführung & Nutzung

und Projektabschluss. Phasen / Meilensteine Vorstudie Genehmigung

Konzept 0

Review

Realisierung & Test

Einführung 2

1

Nutzung 4

3 Abschluss

Haupt-Lieferobjekte • geschultes Team • Projekt aufsetzen

• Vereinbarte Geschäftprozesse • Sandpit System

• angenommenes System • Entwicklung & Test Systeme

• Geschulte Anwender • Erfahrene Anwender • Produktivsystem • Operatives System

Dokumentation • Kreditantrag • Project Charter • Project Plan • Dokumentation Plan

• Endgültiges Business Case • Konzeptpapier • Prozessbeschreibungen

• Datenmodell-Dokument

• Schulungsunterlagen

• Lessons learned

• Systemdokumentation

• Schulung Protokol

• Berechtigungen

• Einführungsplan

• Protokoll über die offenen Anforderungen

• Testkonzept

• SLA (Service Level Agreement)

• Datenmodell

• Integration Testfälle

• ProgrammSpezifikation

• Testprotokolle (Integration, Abnhame, Regression)

• Offerte

• SchnittstellenSpezifikation

• Stress Testfälle

• Incident und Problem Management Prozedere

• Qualitätsplan

• Testprotokoll Stresstests

• Datenübernahme

• Audit Bericht

• Schulungskonzept

• Ausschreibung • Infrastruktur Plan

• Dokumentation • BerechtigungsIndex konzept • Risiko Analyse • Sicherheitskonzept

Qualitätssicherung

• Betriebshandbuch

• Übergabeprotokoll • Projektbewertung

• Schulungsplan • Benutzerhandbuch

1.Prüfpunkt

2. Prüfpunkt

3. Prüfpunkt (Produktreife)

4. Prüfpunkt (Übergabe)

Bild 36: Generische Projektphasen

Um ein Projekt erfolgreich abwickeln zu können, müssen noch weitere Themen berücksichtigt werden. Eine umfangreiche Literatur in diesem Bereich steht zur Verfügung. Aus diesem Grund werden diese Themen hier kurz skizziert und nicht weiter vertieft.

118

8.1 P11 - IT Projektmanagement-Prozess Planung & Ressourcenmanagement Die Projektplanung stellt einen wichtigen Rahmen dar. Dadurch wird die Grundlage für das Projekt geschaffen, wonach sich alle für die Projektzielerfüllung ausgerichteten Aktivitäten richten. Die klar mess- und kontrollierbaren Zwischenschritte in der Planung werden Meilensteine genannt. Der Sinn der Projektplanung ist, einen realistischen und stabilen Etappenplan mit Meilensteinen, die durch das STC abgenommen werden sollen, zu erstellen. Phasenübergänge sind fixe Meilensteine. Die Projektplanung ist verbindlich bezüglich Ressourcen und Planungsinhalt. Team Management Im Rahmen eines Projektes wird ein Team zusammengestellt. Beteiligte kommen in der Regel zum ersten Mal zusammen und müssen dann oft unter Zeitdruck intensiv zusammen arbeiten. Es ist die Aufgabe des Projektleiters, sicherzustellen, dass das Projektteam richtig funktioniert. Um diese Aufgabe zu bewältigen, stellt das Kick-off eine besondere Gelegenheit dar, da zum ersten Mal das Team zusammen kommt. Es ist daher besonders wichtig, dies gut vorzubereiten. Der Projektleiter muss dafür sorgen, dass alle Projektmitglieder ihre Rolle(n) im Projekt verstehen. Diese müssten auch in der Lage sein, diese Rolle wahrzunehmen. D.h. Schulungsbedürfnisse sollen erkannt und im Rahmen des Projektes adressiert werden. Im Einzelnen kann auch ein Coaching aufgesetzt werden. In der Teamarbeit gibt es immer Konflikte. Es wurde zum Beispiel beobachtet, dass effiziente Teams durch unterschiedliche Bildungsphasen gehen müssen, um die optimale Leistung erbringen zu können: Forming -> Storming -> Norming -> Performing. Viele Konflikte können benutzt werden, um eine positive Projektentwicklung sicherzustellen. Dieser Prozess nimmt viel Kraft und Zeit in Anspruch und wird selten bei der Planung berücksichtigt, bzw. wahrgenommen. Eine offene und gesunde Konfliktkultur soll im Rahmen eines Projektes gepflegt werden. Die Projektleitung spielt eine entscheidende Vorbildrolle (durch „Vorleben“ des gewünschten Verhaltens). Kommunikation Braucht es im Projekt Kommunikation? Selbstverständlich, ein Projekt benötigt sowohl eine interne als auch eine externe Kommunikation. Emails: Emails sind mit Vorsicht zu genießen. Dieses mächtige Kommunikationstool wird oft missbraucht (typischerweise ein einziger Nachrichtempfänger mit 10 Namen „cc“). Dieses Medium soll dosiert eingesetzt werden, um eine Email-Flut vermeiden zu können. Oft bringt ein direkter Kontakt mehr als 10 Mails. Beschlüsse: relevante Beschlüsse müssen schriftlich festgehalten werden.

119

8 Funktionsgruppe „Implementierung“ Meetings: ein Meeting-Konzept soll am Anfang des Projekts definiert werden und spätestens beim Kick-off präsentiert werden. Für jedes Meeting sollen das Ziel, die Häufigkeit, die Teilnehmer, die Inputs und Outputs festgelegt werden. Projektname: es ist wichtig, einen Projektnamen (zum Beispiel NEWTON => NEW Telefon Over Network) zu wählen, der einerseits einen positiven Appell gibt und andererseits eine Verbindung zum Projektziel schafft. Die Wahl des Projektnamens ist eine gute Gelegenheit, die Stakeholders für das Projekt zu gewinnen: es kann auch ein kleiner Wettbewerb organisiert werden. Logo: wenn es das „Corporate Design“ zulässt, ist es empfehlenswert, ein Logo für das Projekt zu kreieren. Newsletter: dies ermöglicht eine breite Informationsverteilung auf eine persönlichere Weise als ein Email. Artikel: immer wieder daran denken, durch die etablierten Unternehmenskanäle Informationen über das Projekt zu vermitteln. Intranet: ist vor allem bei der Einführung ein mächtiges Informationsmittel, um viele Mitarbeiter erreichen zu können. Wirklich zu empfehlen zum Beispiel bei einer Systemumstellung, bei der viele Benutzer betroffen sind. Marketing: es gibt auf diesem Gebiet keine Grenzen der Vorstellung; ein Beispiel wäre ein Mouse Pad mit der Helpdesk-Telefonnummer bei einem PC Rollout. Projektaufwandssteuerung und Berichterstattung Im Rahmen eines Projektes sind ein Ressourcenüberblick und eine regelmäßige Berichterstattung notwendig, damit über den Verlauf eines Projektes das STC und die Entscheidungsträger informiert sind. Mit dem Start des Projektes, ab 1. Bewilligung durch das Portfoliomanagement, beginnt die monatliche Berichterstattung mit Hilfe des Projekt-Statusberichtes. Drittlieferanten Bei vielen Projekten werden externe Ressourcen eingeholt. Entweder fehlen interne Ressourcen für die Durchführung des Projektes oder das Wissen ist nicht vorhanden. Die Gewinnung von externen Ressourcen hat Auswirkungen auf Kosten, Zeitrahmen und Risiken. Dieser Prozess muss deshalb sorgfältig durchgeführt werden. Zwei Phasen sind besonders kritisch: – Auswertung und Selektion von IT-Anbieter und – Auswertung und Selektion von einzelnen Projektmitgliedern. Meistens spielt die Zeit eine kritische Rolle in dem Selektionsprozess, da auch eine eventuelle Fragerunde berücksichtig werden muss. Jedoch sollen die Anbieter eine angemessene Antwortzeit für die Angebotserstellung bekommen. Die Angebotsphase beträgt somit typischer Weise 4 bis 6 Wochen.

120

8.1 P11 - IT Projektmanagement-Prozess Wissenstransfer Die Projektarbeit bietet die Möglichkeit, für die einzelnen Projektmitglieder sehr viel neues Wissen zu sammeln. Es liegt in der Projektverantwortung sicherzustellen, dass dieses gesammelte Wissen nach dem Projektabschluss in der Organisation verbleibt und nicht verschwindet. Wenn dies nicht erfolgt, kann es passieren, dass die ganze Organisation von dem Wissen einzelner Mitarbeiter oder externer Berater abhängig ist oder dass Wissenslücken bei der Prozessdurchführung entstehen. Um diesen Transfer optimal gestalten zu können, müssen folgende Aktionen am Anfang des Projektes eingeleitet werden: – Identifikation von Schlüsselpersonen im Fachbereich, – Einbezug der IT-Betriebsorganisation. Die fachlichen Schlüsselpersonen spielen eine entscheidende Rolle, sowohl beim Aufbau des Systems, als auch später bei der Durchführung wichtiger Aufgaben wie Schulung, Autorisierung, Anforderungsdefinition und Prozessmitgestaltung. Diese sollen über ein gutes Verständnis der Geschäftsabläufe verfügen, gute Kommunikationsfähigkeiten besitzen und unbefangen gegenüber der Technik sein. Um einen reibungslosen Betrieb der implementierten Lösung sicherstellen zu können, muss die Betriebsorganisation, insbesondere innerhalb der IT Organisation, frühzeitig miteinbezogen werden. Dies soll durch den IT Projektleiter geschehen.

121

8 Funktionsgruppe „Implementierung“

8.1.1

Hauptaktivitäten „P11 – IT Projektmanagement“

In der folgenden Tabelle werden die Hauptaktivitäten des ProjektmanagementProzesses beschrieben. Tabelle 32: Hauptaktivitäten „P11 – IT Projektmanagement“

Hauptschritte

Beschreibung

Projektinitiierung und Erstellen des Projektantrags

Die finanziellen Mittel für die Durchführung des Projektes oder einer Vorstudie werden freigegeben. Damit kann die erste Projektphase beginnen. Nach Annahme eines Projektantrages hat das eingesetzte Steering Committee die volle Projektverantwortung bis zur Annahme des Abschlussberichtes. Im Falle einer Budgetüberschreitung ist das neue Gesamtbudget von der für einen solchen Betrag zuständigen Instanz zu genehmigen.

Phasenabschlüsse Durchführung und Protokollierung von STC.

Der Abschluss einer Phase wird von der Projektleitung dokumentiert und durch das Steering Committee abgenommen. Die STC-Sitzungen, mindest eine beim Phasenabschluss, werden protokolliert.

Projektabschluss

Beim Projektabschluss muss die Projektleitung eine Abschlusssitzung mit dem STC durchführen. In dieser Sitzung wird auch eine „Lessons Learned“-Übung durchgeführt. Dies wird im Abschlussprotokoll festgehalten.

Projektabbruch

Das STC oder das Projektportfoliomanagement kann jederzeit (z. B. Projekt läuft aus dem Rahmen bezüglich Business Case, Zeit, Qualität und/oder Kosten), einen Antrag für einen Projektabbruch bei der entsprechenden Instanz stellen, dabei sind die Abbruchkosten und Konsequenzen offen zu legen. Diesem ist eine entsprechende Begründung sowie ein allfälliger Projekt-Audit beizulegen. Ein Projektabschluss muss dabei durchgeführt werden.

122

8.1 P11 - IT Projektmanagement-Prozess

8.1.2

Rollen „ P11 – IT Projektmanagement “

Tabelle 33: Prozessrollen „P11 – IT Projektmanagement“

Business

STC Mitglieder – überwachen insbesondere das Erreichen der Projektziele, das Einhalten der Meilensteinplanung, das Einhalten des Projektbudgets, – sind für die Abnahme von Ergebnissen und die Freigabe der nächsten Projektphasen verantwortlich, – sind die Eskalationsinstanz für alle Situationen, in denen die Erreichung der Projektziele durch geänderte Rahmenbedingungen gefährdet ist. Fach-Projektleiter – ist verantwortlich für eine ordnungsgemäße Planung & Durchführung des Projektes, eine nachvollziehbare Dokumentation des Projektnutzens und der Lösungen, die diesen Projektnutzen erzielen oder unterstützen sollen, die Realisierung des Projektnutzens und eine zeitnahe und korrekte Information des STC. Finanz & Controlling – eröffnet und schließt Innenaufträge ab. Leiter Projekt Portfolio Management – verwaltet das Projektportfolio. IT-Projektleiter

IT

– ist verantwortlich für die Planung und Lenkung der technischen Projektmitarbeiter, eine sachgerechte Umsetzung der Benutzeranforderungen in technische Lösungen und deren Überführung in die definitive Produktionsumgebung. Projekt-Mitarbeiter – liefern die ihnen zugeteilten Aufträge fristgerecht und in der notwendigen Qualität, – informieren ihren Vorgesetzten über ihre Aufwände (Ressourcenplanung). System Owner – setzt die System-Änderungen produktiv um, – stellt dem Projekt die notwendigen Systeme (z.B. Entwicklungssysteme oder Testsysteme) zur Verfügung.

123

8 Funktionsgruppe „Implementierung“

8.1.3

Prozessbeschreibung „P11 – IT Projektmanagement“

Nachfolgend im A4 Format die Beschreibung des Prozesses. Projekt Portfolio Management

Projekt aufsetzen

Supplier Management

Ausführung Projektphase

nein

Input Output genehmigte Projekte Kick-off

Portfolio Manager Projektleitung

Phasen Lieferobjekte

Projektleitung Projekt-Mitarbeiter

STC-Protokoll

STC-Mitglieder

Projekt-Plan, Phasendokumente

Projektleitung

Produktionsfreigabe

Projektleitung

produktiv gestellt

System Owner

Abschlussbericht

Projektleitung

Projekt-Bewertung

Portfoliomanager

Schließung Innenauftrag

Finanz & Controlling

STC Abnahme ? ja

Applikationsentwicklung

Nächste Projektphase

nein

Produktionsfreigabe ? ja

Betrieb & Konfiguration

Lessons learned

Projektabschluss

Ende

Bild 37: Prozessbeschreibung „P11 – IT Projektmanagement“

124

8.2 P12 - Release Management-Prozess

8.2 P12 - Release Management-Prozess Das Release Management hat zum Ziel, Einführungen von Applikationsfunktionalitäten zeitlich, inhaltlich und technisch zu bündeln und aufeinander abzustimmen. Ein korrektes Release Management unterstützt die Planung des Projektportfolios und die Betriebssicherheit.

8.2.1

Hauptaktivitäten „P12 – Release Management“

In der folgenden Tabelle werden die Hauptaktivitäten des Release ManagementProzesses beschrieben. Tabelle 34: Hauptaktivitäten „P12 – Release Management“

Hauptschritte

Beschreibung

Anforderungen Anforderungen werden durch den Anforderungsprozess sammeln, klassifi- erstellt und gesammelt. zieren und prioriFalls eine dringende Änderung stattfinden muss, wird die sieren Anforderung im Rahmen des Problem ManagementProzesses adressiert und als „Fix-Release“ abgewickelt. Overall Release planen

Release Plan auf jährlicher Basis, der die geplanten Releases im Jahresverlauf darstellt. Der Plan wird gemäß SLAs entwickelt.

Release Detailplan Pro Release wird ein detaillierter Plan erstellt. Neue Funktionali- Im Rahmen des Applikationsentwicklung-Prozesses werden täten entwickeln neue angeforderte Funktionalitäten entwickelt und getestet (Produkte und Integration Tests). Tests durchführen Die entwickelten Änderungen müssen noch von den entund Release absprechenden Fachbereichen abgenommen werden. Die Abnehmen nahmetests beinhalten vor allem die User Acceptance Tests (UATs), die bestätigen, dass das System alle geforderten Business-Funktionalitäten abdeckt und korrekten Output produziert. Release durchfüh- Wenn die Tests erfolgreich durchgeführt wurden, werden ren die neuen Funktionalitäten auf alle Zielobjekte ausgebreitet und durch die Betriebsorganisation installiert. Die Dokumentation über die entsprechenden Konfigurationselemente wird aktualisiert.

125

8 Funktionsgruppe „Implementierung“ Für jedes Release sind Namenskonventionen definiert, die eingehalten werden sollen. Release-Nummerierung wie folgt: 2006.03.01: Jahr.Monat.Laufnummer (aufsteigend). Die Abwicklung eines Release ist ähnlich der Abwicklung eines Projektes. Drei Hauptphasen, anstatt fünf für ein Projekt, können definiert werden: I. Release Aufbau (äquivalent zu Konzeptphase): in dieser Phase wird der Inhalt des Release festgelegt und das Release als „Paket geschnürt“. II. Release Zustellung (äquivalent zu Realisierungsphase): die Entwicklung der Applikation wird realisiert und deren Qualität sichergestellt. III. Release Rollout (äquivalent zu Einführung vor dem Go-live): die entwickelten und abgenommenen Systemfunktionalitäten werden verteilt und auf Produktivsystem(e) migriert. I. Release-Aufbau Release-Aufbau ist der Prozess des “Zusammenbauens” jedes Releases abhängig von Kapazitäten, Terminplan, Kosten und Nutzen

Aufträge sammeln Analyse

II: Release-Zustellung Release-Zustellung umfasst die Entwicklungsphasen (Analyse, Design, Build, Test).

Zuweisung

III. Release Roll-Out Spezifikation, Konzept

Der Release Roll-Out umfasst alle Aktivitäten, um einen neuen Release dem „Zielpublikum“ zur Verfügung zu stellen (inklusiv Kommunikation und physische Ausbreitung der Release Packages).

Programmierung, Parametrisierung, Unit Test Integration Test Planung Roll-out

M0 M0 – Abnahme Release-Umfang

Information Benutzer, Schulung

M1 M1 – Abnahme Spezifikation

M2

Mn

M2– Abnahme Integration Test

Abnahmen durch RCB

Abnahme Tests, Regression M3 M3 – Abnahme Produktion M4 M4 – Produktion Roll-out Zeit (Wochen)

Bild 38: Release-Ablauf

126

8.2 P12 - Release Management-Prozess Die Test Aktivitäten spielen eine wichtige Rolle bei der Abwicklung der Releases. Es muss sichergestellt werden, dass die neuen Funktionalitäten korrekt funktionieren, ohne dass die übrigen Funktionalitäten tangiert sind. Folgende Tests sind im Rahmen des Release-Prozesses vorgesehen: Unit Test

Integration Test

Abnahme-Test

Verantwortung:

Verantwortung:

Verantwortung:

Application Expert

IT-Projektleiter

Fachprojektleiter

¾ Functional Unit Test:

¾ Integration Test: Dieser Test prüft, dass die definierten Funktionen und die Schnittstellen zusammen spielen – möglichst in allen „Benutzer-Szenarien“.

¾ User Acceptance Test: Dieser Test bestätigt, dass das System alle geforderten Business-Funktionalitäten abdeckt und korrekten Output produziert.

Arbeiten alle Schnittstellen zusammen?

¾ Regression Test: Sicherstellen, dass eine Systemänderung nicht einen zuvor funktionierenden Teil beeinflusst hat.

ƒ Jedes Element „funktioniert“ wie spezifiziert. ƒ Testdaten werden definiert. ƒTestprogramme/Skripts werden geschrieben. ƒ Einfache Testfälle werden benutzt.

bei Bedarf: Installation Test: Eine „Generalprobe“ für die Installation der Software mit den „live“ Tools & Prozessen! Performance Test: Aufgrund der vorhandenen Datenmenge müssen erste „Hochrechnungen“ auf das Produktions-Verhalten gemacht werden können.

Bild 39: Testarten

127

8 Funktionsgruppe „Implementierung“

8.2.2

Rollen „ P12 – Release Management “

Die folgenden Rollen sind notwendig, um den Prozess abwickeln zu können. Tabelle 35: Prozessrollen „P12 – Release Management“

Business

Release Control Board (RCB) – hat eine zentrale Funktion wie ein Steering Committee für ein Projekt, – priorisiert, bewilligt Releaseinhalte und Änderungen, – gibt die Release-Einführung frei, – für einen Fix-Release kann/muss der Vorsitzende des RCB die Änderung freigeben. Key-User – erstellt die Testfälle, – stellt die fachliche Abnahme durch die Durchführung der Systemtests sicher. Release Manager – ist für die jährliche Planung der Releases zuständig, – priorisiert und klassifiziert die eingetroffenen IT-Anforderungen, – ist für die Release-Durchführung zuständig, plant und überwacht die notwendigen Schritte, – bei Fix-Release informiert der Release Manager den Problem Owner, um sicherzustellen, dass das Problem effektiv gelöst ist.

IT

Application Expert – berät, – programmiert oder parametrisiert und führt Produkt-Tests durch, – unterstützt bei der Durchführung der Integration Tests, der Abnahmetests und der Schulung. Account Manager – sendet IT-Anforderung an dem Release Manager. Problem Owner – analysiert einen Problemfall und bietet eine Lösung an, – falls ein Fix-Release notwendig ist, erstellt eine Anforderung an das Release Management. System Owner – setzt die System-Änderungen produktiv um.

128

8.2 P12 - Release Management-Prozess

8.2.3

Prozessbeschreibung „P12 – Release Management“

Die Prozessbeschreibung „Release Management“ hat gewisse Ähnlichkeiten zu Projektmanagement. Dennoch ist die Ausganglage anders. Anforderungsmanagement

Problem Management

IT-Anforderung

Account Manager, Problem Owner

Release-Anforderung

Release Manager

Overall Release-Plan

Release Manager

Release-Umfang

Release Manager

Release-Plan

Release-Detailplan

Release Manager

RCB Bewilligung ?

RCB-Genehmigung Fix-Release

Release Control Board (RCB)

Analyse der IT-Anforderungen

Klassifikation der Anforderungen / Plan

nein

Input Output

geplante Release ? ja

nein

ja SW-Anforderung

Applikationsentwicklung Abnahme-Tests Release-Abnahme

Betrieb & Konfiguration Problem Management

Durchführung des Releases

Entwicklungen / Programmierung

Application Expert

Testfälle

Key-Users

Freigabe, Abnahmeprotokoll

Key-Users, RCB

Konfigurationsdokumente

System Owner

ReleaseAbschlussbericht

Release Manager

Ende

Bild 40: Prozessbeschreibung „P12 - Release Management“

129

8 Funktionsgruppe „Implementierung“

8.3 P13 – Applikationsentwicklung-Prozess Der Applikationsentwicklung-Prozess hat zum Ziel, Software mit hoher Qualität herzustellen. Der Prozess stellt sicher, dass von der Anforderungsdefinition bis zur Abnahme durch den Key-User klare Schritte und Verantwortungen definiert sind. Der Prozess wird einerseits im Rahmen der Applikation-Releases, andererseits im Rahmen der Projektabwicklung in Anspruch genommen.

8.3.1

Hauptaktivitäten „P13 – Applikationsentwicklung“

In der folgenden Tabelle werden die Hauptaktivitäten beschrieben. Tabelle 36: Hauptaktivitäten „P13 – Applikationsentwicklung“

Hauptschritte

Beschreibung

Anforderung analysieren

Die Anforderungen werden analysiert und eine Programmspezifikation wird erstellt.

Planen

Die Realisierung der Entwicklung wird geplant.

Planung prüfen

Um sicherzustellen, dass die Entwicklungsplanung realistisch ist, wird sie mit der Ressourcenplanung und der Systemplanung abgeglichen.

Entwickeln oder parametrisieren

Es wird programmiert oder parametrisiert, gemäß Spezifikation.

Test der Entwicklung

Folgende Tests sind im Prozess vorgesehen:

Abnahme der Entwicklung

Die Abnahme der Entwicklung wird einerseits aufgrund der Qualität der Programmierung und anderseits durch die Erfüllung der Anforderung entschieden.

130

Unit Tests Modultest als Funktional Unit Test: Dieser Test ist der erste Schritt im Test-Zyklus und stellt sicher, dass jedes einzelne Element „funktioniert“. Speziell werden alle Schnittstellen anhand der Spezifikation geprüft, bevor es in die nächste Testphase geht. Integration Tests Diese Tests prüfen, ob die definierten Funktionen und die Schnittstellen zusammen spielen – möglichst in allen „Benutzer-Szenarien“.

8.3 P13 – Applikationsentwicklung-Prozess

8.3.2

Rollen „P13 – Applikationsentwicklung“

Der Prozess findet hauptsächlich bei der IT-Organisation statt.

Business

Tabelle 37: Prozessrollen „P13 – Applikationsentwicklung“

Key-User – prüft die Spezifikation, – führt die Integrationstests durch, – gibt das OK für das Ende der Entwicklung. Release Manager oder Projekt-Manager – vermittelt die Aufträge, – koordiniert die Release-Planung mit der Detailplanung für die vorgesehenen Entwicklung (Aktivitäten + Ressourcen),

IT

Leiter Applikationsentwicklung – prüft die Machbarkeit (Ressourcenplanung, Aufwandschätzung), – nimmt die Spezifikation ab – prüft die Qualität der Entwicklung gemäß Programmierungsrichtlinien, – stellt sicher, dass die Dokumentation zur Verfügung gestellt wird. Application Expert – prüft die Anforderung auf Verständlichkeit und Vollständigkeit, – erstellt eine Aufwandschätzung und schlägt eine Detailplanung (Aktivitäten + Ressourcenverfügbarkeit) vor, – definiert das logische Datenmodel, – erstellt die Spezifikation, – programmiert oder parametrisiert, – führt die Funktional Unit Tests durch, – unterstützt den Key-User bei der Durchführung der Integration Tests, – dokumentiert die Programme und die Konfigurationselemente. System Owner – prüft die Release-Planung anhand Systemplanung, – stellt die IT-Infrastruktur zur Verfügung.

131

8 Funktionsgruppe „Implementierung“

8.3.3

Prozessbeschreibung „P13 – Applikationsentwicklung“

Der Applikationsentwicklung-Prozess ist innerhalb der Prozesse „Projekt Management“ und „Release Management“ eingebettet. Projektmanagement Release Management

Input Output Auftrag

Analyse und Design

nein

Planung in Ordnung ? ja

Programmieren, parametrisieren

Produkte Tests

Integration Tests

Detailplanung, Datenmodel, ProgrammSpezifikation

Tests erfolgreich ? ja

Release Management

System Owner

Ressource-Plan

Leiter Applikationsentwicklung

Spezifikation

Application Expert

Programme, Parametrisierung

Application Expert

Test Skripts

Application Expert

Programm-Check, Peer Review

Leiter Applikationsentwicklung

Testfälle

Key-User, Application Expert Key-User, Application Expert

Konfiguration / ProgrammDokumentation

Application Expert

abgeschlossener Auftrag

Application Expert

Projektmanagement

Bild 41: Prozessbeschreibung „P13 – Applikationsentwicklung“

132

Leiter Applikationsentwicklung, Application Expert

System-Plan

Test-Protokolle

nein

Release/ProjektLeiter

8.4 Prozessabhängigkeiten „Implementierung“

8.4 Prozessabhängigkeiten „Implementierung“ Das folgende Bild zeigt die Prozessabhängigkeiten von den drei in „Implementierung“ definierten Prozessen mit fünf zusätzlichen Prozessen (IT-Projekt Portfolio, Anforderungsmanagement, IT-Betrieb & Konfiguration, Supplier Management, Problem Management). genehmigter Projektantrag

Projekt Portfolio

Projekt aufsetzen Bestellung

Überwachung, Bewertung Statusbericht

Projekt

Abnahme

Anforderung

Auftrag

Kleinauftrag

Entwicklungsauftrag Spezifikation

ReleaseAuftrag ReleaseAnforderung

Problem

Spezifikation

Programm, Parametrisierung

Release FixRelease

Supplier

Beschaffungsantrag

Go-live

Warenausgang Lieferung Produktiv Freigabe

Applikation Entwicklung

Abnahme

Produktiv setzen Programm, Parametrisierung

ProduktivFreigabe Release

Problem Ticket abgeschlossen

Produktiv setzen

Betrieb Konfig. Installation, produktiv gesetzt

Bild 42: MIIP-Prozessabhängigkeiten „Implementierung“

133

8 Funktionsgruppe „Implementierung“

8.4.1

Prozessabhängigkeit „P11 – Projektmanagement“

P11 – Projektmanagement

Genehmigter Projektantrag Projekt aufsetzen

P06 – IT-Projekt Portfolio Management

Statusbericht Überwachung, tung P11 – Projektmanagement

Bewer-

Entwicklungsauftrag Spezifikation

P13 – Applikationsentwicklung

Programm, Parametrisierung Abnahme P11 – Projektmanagement

Produktiv-Freigabe Produktiv setzen Installation gesetzt

P14 – IT-Betrieb & Konfiguration

produktiv

Go-live P11 – Projektmanagement

Beschaffungsantrag Bestellung

P15 – Supplier Management

Warenausgang Lieferung Die folgende Abbildung zeigt die Positionierung des Projektes auf die taktische Ebene, zwischen dem strategischen Projekt Portfolio-Prozess und der operativen Ebene „IT-Betrieb“.

134

8.4ȱȱProzessabhängigkeitenȱ„Implementierung“ȱ

Bildȱ43:ȱProjektmanagementȬAbhängigkeitenȱ

ȱ

135

8 Funktionsgruppe „Implementierung“

8.4.2

Prozessabhängigkeit „P12 – Release Management“

P12 – Release Management

Kleinauftrag

P12 – Release Management

Entwicklungsauftrag

P10 – Anforderungsmanagement

Release-Auftrag

P13 – Applikationsentwicklung

Spezifikation Programm, Parametrisierung Abnahme

P12 – Release Management

Produktiv-Freigabe

P14 – IT-Betrieb & Konfiguration

Produktiv setzen Installation gesetzt

produktiv

Go-live P12 – Release Management

Release-Anforderung

P17 – Problem Management

Release-Auftrag Fix-Release Problem Ticket schlossen

abge-

Der Prozess Release Management besitzt gewisse Ähnlichkeiten mit dem Projektmanagement-Prozess. In der folgenden Tabelle werden dennoch die Hauptunterschiede festgehalten: Tabelle 38: Vergleich Release Management-Prozess mit Projektmanagement-Prozess

Ablaufschritte

Fix-Release (SW-Erweiterung)

Standard Release

Projekt

Abklärung der Anforderung(en)

Ja

Ja

Ja

Definition der ITSpezifikation

Ja

Ja

Ja

Nein

Ja

Ja (sehr wichtig)

Planung

136

8.4 Prozessabhängigkeiten „Implementierung“ Ablaufschritte

Fix-Release (SW-Erweiterung)

Standard Release

Projekt

Ja

Ja

Ja

Minimal

Nach bekanntem Plan,

"nach Maß", inklusiv Regression und IT-Betrieb Readiness Test

Entwicklung Test

inkl. Regression Tests Training Produktivsetzen

Überwachung nach dem Produktivsetzen

8.4.3

Nein

minimal

intensiv

Schnell, ohne Cutover Plan

Nach einem Standard Cutover Plan

Individuell Cutover Plan

1 Tag

1 Woche

1 Monat

Prozessabhängigkeit „P13 – Applikationsentwicklung“

P13Applikationsentwicklung

Entwicklungsauftrag Spezifikation Programm, sierung

P11 – Projektmanagement

Parametri-

Abnahme P13- Applikationsentwicklung

Entwicklungsauftrag Spezifikation Programm, sierung

P12 – Release Management

Parametri-

Abnahme Wie schon erwähnt ist der Prozess in den Projektmanagement und Release Management-Prozessen eingebettet.

137

9 Funktionsgruppe „IT-Betrieb & Konfigurationsmanagement“ Ein einziger Prozess bildet die Funktionsgruppe „IT-Betrieb & Konfigurationsmanagement“: – P14 - IT-Betrieb & Konfigurationsmanagement, der in diesem Kapitel detailliert beschrieben wird. Aufgrund der Prozessabhängigkeiten müssen sechs zusätzliche Prozesse berücksichtigt werden: – P07 - Capacity / Availability Management, – P09 - Service Management, – P11 - IT-Projektmanagement, – P12 - Release Management – P15 - Supplier Management – P16 - Incident Management. Die Beziehungen zu diesen sechs Prozessen werden am Ende des Kapitels erläutert.

9.1 P14 – IT-Betrieb & Konfigurationsmanagement-Prozess Die Verfügbarkeit der IT-Systeme stellt eine wichtige Aufgabe der ITOrganisation dar. Im Rahmen von SLAs werden die Rahmenbedingungen definiert, wie die Benutzung der Systeme gewährleistet werden soll. Dennoch werden immer System-Änderungen vorgenommen. Zum Beispiel im Rahmen von Releases werden neue Funktionalitäten eingebaut. Aus dem Grund ist es wichtig, den Prozess IT-Betrieb und Konfiguration am Leben zu halten. Die Vollständigkeit und Aktualisierung des Inventars spielen eine besondere Rolle. Der Teil „Konfiguration“ bezieht sich auf die Konfiguration der Server und Office-Geräte (PCs, Drucker, Mobil Geräte,…). Dies gilt auch für Firewall Servers oder Routers.

139

9 Funktionsgruppe „IT-Betrieb & Konfigurationsmanagement“

9.1.1

Hauptaktivitäten „P14 – IT-Betrieb & Konfiguration“

In der folgenden Tabelle werden die Hauptaktivitäten des IT-Betrieb & Konfigurationsmanagement-Prozesses beschrieben. Tabelle 39: Hauptaktivitäten „P14 – IT-Betrieb & Konfigurationsmanagement“

Hauptschritte

Beschreibung

Analyse der zu erbringenden Services

Jeder IT-Service wird analysiert, um den Systembetrieb, die Betriebskosten und die notwendigen Ressourcen zu definieren.

Planung der Ressourcen

Die notwendigen Ressourcen für die Erbringung der vereinbarten Services müssen geplant und budgetiert werden.

Systemüberwachung

Verschiedene IT-Systeme werden betrieben. Im Rahmen der SLAs werden die betrieblichen Rahmenbedingungen definiert und vom Fachbereich angenommen. Die Systeme werden ständig überwacht.

System-Änderung Anhand des Systemplans wird die Änderung definitiv geplanen und durch- plant. System Backups, Wartungsfenster oder System Freeze führen müssen berücksichtigt werden. Wenn eine System-Änderung soweit geplant ist, wird diese gemäß Plan durchgeführt. Systemteile einkaufen

Im Rahmen des Betriebsbudgets werden Ersatzteile beschafft und eingebaut.

Reports herstellen Reports werden hergestellt, um die Einhaltung der Service Levels zu prüfen. Analyse der zu erbringenden Services

Jeder IT-Service wird analysiert, um den Systembetrieb, die Betriebskosten und die notwendigen Ressourcen zu definieren.

Es ist wichtig, das Helpdesk über eine Systemänderung im Voraus zu informieren. Eine intensivere Systemüberwachung nach Produktionsbeginn soll gewährleistet werden, gemäß der Natur und dem Umfang der Änderung: – für kleinere Änderungen soll das System zum Beispiel 2 Tage intensiver überwacht werden, – im Rahmen eines „normalen“ Release ist es empfohlen, das System während einer Woche zu beobachten, – bei dem Produktiv-Setzen innerhalb eines Projektes sollte das System bis zu einem Monat überwacht werden.

140

9.1 P14 – IT-Betrieb & Konfigurationsmanagement-Prozess

9.1.2

Rollen „ P14 – IT-Betrieb & Konfigurationsmanagement”

Die folgenden Rollen sind notwendig, um den Prozess abwickeln zu können. Tabelle 40: Prozessrollen „P14 – IT-Betrieb & Konfigurationsmanagement“

Service-Manager – definiert, in Zusammenarbeit mit dem Betriebsleiter, die zu erbringenden Services

IT

IT-Betriebsleiter – definiert, in Zusammenarbeit mit dem Leiter Service Management, die zu erbringenden Services und deren Qualitätsmerkmale, – stellt die Ressourcen-Planung sicher, – stellt sicher, dass die im IT-Betrieb benutzen Geräte inventarisiert werden, – stellt sicher, dass die Inventardaten aktuell sind, – kauft alle notwendigen HW und SW-Elemente, die für den Betrieb notwendig sind (solange diese als solches budgetiert sind). Konfiguration Manager – nimmt die Anforderungen für System-Änderung entgegen, – plant die System-Änderungen (System-Plan), – aktualisiert die Konfigurationsdaten nach der Durchführung einer Änderung. System Owner – betreibt das IT-System und überwacht vor allem bei kritischen Systemen die Systemstabilität (Anzahl ungeplanter Unterbrechungen) und das Systemverhalten (Antwortzeit, Speicherkapazität, ...), – meldet Einkaufbedarf beim Betriebsleiter, – führt die System-Änderungen durch, – überwacht die Systemstabilität, – liefert die effektiven Werte zu technischen Messgrößen der SLAs. Release Manager / IT-Projektleiter – meldet dem System Owner die Termine für die Produktivsetzung im Rahmen eines Releases oder Projektes. Helpdesk Agent – Meldet die Anforderung zu Paketierung von Client SW. SW, die schon paketiert sind, werden automatisch zugeteilt.

141

9 Funktionsgruppe „IT-Betrieb & Konfigurationsmanagement“ Nachfolgend eine Darstellung der Aufgabenverteilung zwischen dem Service Manager und dem System Owner im Rahmen des „normalen“ IT-Betriebs (Implementierung nicht berücksichtigt): Tabelle 41: Trennung Service Manager / System Owner

Aufgabe

Service Manager

System Owner

Kurzbeschreibung

SLAReporting

X

Ausfälle werden sofort im Reporting nachgeführt. Dabei sind nur Ausfälle während der Betriebszeit zu rechnen

Einhaltung SLA

X

Alles daran setzen, dass das SLA erfüllt werden kann

Capacity Überwachung

X

Überwachen der Produktion und der gebrauchten System-Ressourcen (Speicherungskapazität, CPU-Leistung etc.)

Inventar

X

Nachführen der Konfiguration (Hardware, Software, Datenbanken etc.)

Autorisierungen

X

Sicherstellen, dass nur autorisierte Mitarbeiter mit den entsprechenden Rechten das System benützen können

Durchführung der Business Continuity Plan Tests

Periodisches Überprüfen des BCP (läuft der Failover etc.?). X

Datensicherung

X

Patch Management

X

Überwachung

X

142

Stellt sicher, dass die Daten in der geforderten Periodizität und Anzahl Generationen sichergestellt und auch wiederhergestellt werden können. Bedeutet tägliche Überwachung und Registrierung der Kontrolle Einspielen, Testen und Produktivsetzung von notwendigen Fixes oder Upgrades Überwachen der Funktionsfähigkeit des Systems

9.1 P14 – IT-Betrieb & Konfigurationsmanagement-Prozess

Aufgabe

Service Manager

System Owner

Performance

X

Life Cycle Management

X

Überwachen der Performance bzw. Erkennen von Veränderungen mit entsprechender Definition von Maßnahmen Nachführen der Infrastruktur-Roadmap

Systemdokumentation, Dokumentation der Schnittstellen (welche anderen Systeme sind angeschlossen), BCP Dokumentation

Kurzbeschreibung

Erstellen bzw. Nachführen der SystemDokumentation

X

143

9 Funktionsgruppe „IT-Betrieb & Konfigurationsmanagement“

9.1.3

Prozessbeschreibung „P14 – IT-Betrieb & Konfiguration“

Hier im A4 Format die Beschreibung des Prozesses. Service Management

Input Output SL-Agreements

Service Manager

Service-Konzept

Betriebsleiter

Betrieb-Roadmap

Betriebsleiter

System-Plan

Betriebsleiter

SystemÜberwachung

System Owner

Meldung einer Systemänderung

Release Manager, IT-Projektleiter, Helpdesk Agent

Analyse

Capacity Availability

Ressourcen planen

Betriebaktivitäten, SystemÜberwachung

Release Management Projektmanagement Incident Management

Änderung nötig ? nein ja

Planung der Systemänderung

Supplier Management

SW Request

Durchführung der Änderung

Aktualisierung der Konfigurationsdaten, Inventar

Reporting

angenommene Änderungen

KonfigurationManager

Wunschtermin

Release Manager, IT-Projektleiter

Änderungstermin, Plan

System Owner

Durchführung der Änderung

System Owner

Konfigurationsdaten aktualisieren

KonfigurationManager

System Reports SL Reports

System Owner

Ende

Bild 44: Prozessbeschreibung „P14 – IT-Betrieb & Konfigurationsmanagement“

144

9.2 Prozessabhängigkeiten „IT-Betrieb & Konfiguration“

9.2 Prozessabhängigkeiten „IT-Betrieb & Konfiguration“ Das folgende Bild zeigt die Prozessabhängigkeiten von dem im „IT-Betrieb & Konfigurationsmanagement“ definierten Prozess mit sechs zusätzlichen Prozessen (Capacity-Availability Management, Service Management, Projektmanagement, Release Management, Supplier Management, Incident Management). InfrastrukturRoadmap

Capacity

Bestellung

Service

ProduktivFreigabe

Projekt

SL-Definitionen SLBericht

Warenausgang

Go-live

Release

Rollout Release

Produktiv Freigabe

Incident

Supplier

Messung der Qualitätsmerkmale

Produktiv setzen System Plan Installation produktiv gesetzt

Produktiv setzen

Betrieb Konfig.

SLA-Ziele

Beschaffungsantrag

Lieferung

SW Client Zuordnung

Anfrage für SW Client

Bild 45: MIIP-Prozessabhängigkeiten „IT-Betrieb & Konfiguration“

145

9 Funktionsgruppe „IT-Betrieb & Konfigurationsmanagement“ P14 – IT-Betrieb & Konfigurationsmanagement

Infrastruktur map

Road-

System-Plan P14 – IT-Betrieb & Konfigurationsmanagement

SL-Definitionen SLA-Ziele

P07 – Capacity / Availability Managment

P09 – Service Management

Messung der Qualitätsmerkmale SL-Bericht P14 – IT-Betrieb & Konfigurationsmanagement

Produktiv-Freigabe Produktiv setzen

P11 – Projektmanagement

Installation produktiv gesetzt Go-live P14 – IT-Betrieb & Konfigurationsmanagement

Produktiv-Freigabe Produktiv setzen

P12 – Release Management

Installation produktiv gesetzt Release Rollout P14 – IT-Betrieb & Konfigurationsmanagement

Beschaffungsantrag Bestellung

P15 – Supplier Management

Warenausgang Lieferung P14 – IT-Betrieb & Konfigurationsmanagement

Anfrage SW Client SW Client-Zuordnung

P16 – Incident Management

Für die „normale“ Durchführung der betrieblichen Aktivitäten werden: – die Infrastruktur Roadmap und die entsprechende Systemverfügbarkeiten berücksichtigt, – die Service-Definition und deren SLA-Merkmale gemessen. Das Inventar dient als wichtige Informationsbasis und muss korrekt durch den System Owner gepflegt werden. Die Informationen werden benötigt für:

146

9.2 Prozessabhängigkeiten „IT-Betrieb & Konfiguration“ – Abschreibungsbeträge pro Jahr (Abschreibungsplan), – die Versicherungspolicen, – Projekte (sind Erweiterungen notwendig, genügen die vorhandenen Komponenten?), – die generelle Überwachung, – die Erstellung der Roadmap, – die Kapazitätsplanung im Allgemeinen, – Belegung der Rechenzentren (Æ Basis für Stromverbrauch, Kälte, USV, …). Der Datenqualität und der Nachvollziehbarkeit muss somit größte Beachtung geschenkt werden. Jedem Anwender ist eine Hardware-Box mit den entsprechenden Software-Paketen, Drucker-Queues und den entsprechenden Berechtigungen zugeordnet. Zusätzlich zu den betrieblichen Aktivitäten werden aber immer SystemÄnderungen vorgenommen, und zwar aus drei verschiedenen Gründen: 1) aus einem Incident, 2) durch das Produktivsetzen eines Release, 3) Projekt Go-lives. Diese System-Änderungen sind so zu planen, dass einerseits die SLAs nicht verletzt werden und grundsätzlich die Betriebssicherheit nicht gefährdet wird. Die Änderung ist durch den System Owner zu planen und zu registrieren. Vor der Durchführung müssen je nach Situation die betroffenen Fachbereiche und zusätzlich das Helpdesk orientiert werden. Bei größeren Umstellungen ist ein Pikett einzurichten und genügend Ressourcen für allfälligen Support bereit zu halten. Der Erfolg der Umstellung wird als „lessons learned“ festgehalten. Es ist sicher hilfreich an der Stelle, eine Check-Liste aufzusetzen, um alle kritischen Punkte abzudecken. Anbei ein Beispiel: Beschaffung Server-Infrastruktur

† Ja

Begründung/Konsequenzen

† Nein Entspricht Standard?

Hardware

dem

IT- † Ja † Nein

Ist ein Test resp. Failover-System † Ja geplant? † Nein

147

9 Funktionsgruppe „IT-Betrieb & Konfigurationsmanagement“ Beschaffung Server-Infrastruktur

† Ja

Begründung/Konsequenzen

† Nein † RZ x

Server-Standort

† RZ y † RZ z Sind Rack-Platz und schluss vorhanden?

Stroman- † Ja † Nein

Ist die bestehende Netzwerk- † Ja Infrastruktur ausreichend? † Nein Ist Hardware-Wartung hen?

vorgese- † Ja † Nein

Gib es Alternativen zur geplanten † Ja Anschaffung? † Nein Entsprechen die Leistungsmerkma- † Ja le des Servers den Anforderungen? † Nein † Ja

Installation Betriebsystem

Begründung/Konsequenzen

† Nein Welches Operating System eingesetzt werden?

soll

Entspricht das Operating System † Ja dem IT-Standard? † Nein Besteht ein Wartungsvertrag?

† Ja † Nein

Müssen zusätzliche Lizenzen be- † Ja schafft werden? † Nein Beschaffung Applikation

† Ja † Nein

Gibt es Alternativen?

† Ja † Nein

Software-Wartungsvertrag?

† Ja † Nein

148

Begründung/Konsequenzen

9.2 Prozessabhängigkeiten „IT-Betrieb & Konfiguration“ Begründung/Konsequenzen

Datenschutz, -sicherheit und Datenhaltung Wie hoch ist die zu erwartende Datenmenge? Wie und wo werden die Daten  gespeichert (lokal oder extern, Fehler-Toleranz)? Wird eine Datenbank benötigt und † Ja entspricht diese dem IT-Standard? † Nein Werden spezielle IT Security- † Ja Einrichtungen benötigt (Firewall)? † Nein Gibt es Failover-Möglichkeiten?

† Ja † Nein

Wird der Server zentral gesichert? Sind diesbezüglich nötig?

† Ja

Investitionen † Nein

Einführung/Realisierung

Begründung/Konsequenzen

Kann der Auftrag mit den beste- † Ja henden Ressourcen durchgeführt † Nein werden? Termin:



Betrieb

Begründung/Konsequenzen

Hat die Einführung Einfluss auf † Ja andere Systeme (z.B. Clients)? † Nein Wer betreibt das System und wel- † IT Einheit che Person wird Systemverantwort- † ............. licher? Kann das System mit den beste- † Ja henden Ressourcen betrieben wer- † Nein den? Ist das benötigte Wissen im Hause? † Ja † Nein

149

9 Funktionsgruppe „IT-Betrieb & Konfigurationsmanagement“ Wird Ausbildung benötig?

† Ja † Nein

Gibt es Aufgrund der Checkliste † Ja Betriebsrisiken? † Nein SLAs

Begründung/Konsequenzen

In welchem Ausmaß wird der Betriebsaufwand durch die gewählte Konfiguration gesenkt? Kommentar

Alle notwendigen Geräte oder Anlagen werden von externen Zulieferern eingekauft und in Betrieb genommen. Grundsätzlich muss die Inbetriebnahme neuer Komponenten (Hard- oder Software) frühzeitig geplant werden. Einerseits muss der System Owner bestimmt werden, andererseits muss geprüft werden, ob genügend Kapazitäten und Wissen vorhanden sind.

150

10 Funktionsgruppe „Supplier Management“ Ein einziger Prozess bildet die Funktionsgruppe „Supplier Management“: – P15 - Supplier Management, der in diesem Kapitel detailliert beschrieben wird. Aufgrund der Prozessabhängigkeiten müssen drei zusätzliche Prozesse berücksichtigt werden: – P04 - Financial Management, – P10 - Projektmanagement, – P14 - IT-Betrieb & Konfigurationsmanagement. Die Beziehungen zu diesen drei Prozessen werden am Ende des Kapitels erläutert.

10.1 P15 – IT-Supplier Management-Prozess Der Einkauf externer Geräte und Dienstleistungen stellt eine wichtige Funktion von der IT-Organisation dar. Es muss sichergestellt werden, dass der entsprechende Prozess formell korrekt abgewickelt wird, um gegebenenfalls juristische Schwierigkeiten zu vermeiden. Zum Beispiel ist es absolut notwendig, dass vor der Erbringung von Dienstleistungen ein unterschriebener Vertrag vorliegt. Es ist auch wichtig, bei der Bestellung sicherzustellen, dass definierte Standards eingehalten werden.

10.1.1 Hauptaktivitäten „P15 – IT-Supplier Management“ In der folgenden Tabelle werden die Hauptaktivitäten des Supplier ManagementProzesses beschrieben. Tabelle 42: Hauptaktivitäten „P15 – IT-Supplier Management“

Hauptschritte

Beschreibung

Bestellanforderungen werden erstellt und geprüft. Bestellanforderung erstellen und „Standard“-Bestellungen werden schnell bearbeitet und setprüfen zen voraus, dass der Zulieferer bekannt ist, die Waren verfügbar sind und einfach zur Verfügung gestellt werden können. Eine Standard-Bestellung ist z. B. eine SW-Installation, welche bereits paketiert ist. Die Nicht-Standard-Bestellungen müssen dementsprechend genehmigt werden. Es ist an der Stelle wichtig, sich an die definierten Standards zu halten und sicherzustellen, dass das entsprechende Budget genehmigt wurde.

151

10 Funktionsgruppe „Supplier Management“ Hauptschritte

Beschreibung

Zulieferer wählen

Der Zulieferer soll vertrauenswürdig sein, preislich vorteilhaft und seriös. Die Geschäftsbedingungen werden mit einem unterschriebenen Vertrag vereinbart.

Bestellen und die Waren oder

Nachdem die Bestellung gemacht wurde, werden die Waren geliefert oder die Dienstleistung erbracht.

Dienstleistungen im Empfang

Lieferungen werden auf Vollständigkeit und Qualität im Rahmen einer Abnahmebestätigung geprüft.

nehmen Nutzung / Installa- Betrieb: die bestellten Waren werden installiert und „in Betion trieb“ genommen. Projekt / Betrieb: die externen Mitarbeiter werden geschult und im Projektteam integriert. Rechnung prüfen und bezahlen

Der Kauf von Waren, bzw. die Erbringung der externen Dienstleistung wird in Rechnung gestellt. Die Rechnungen werden kontiert und vor der Auszahlung geprüft.

Zulieferer bewerten

Es ist wertvoll, Erfahrungen über die Qualität der Zuliefererleistungen zu sammeln. Nach der Erbringung einer Dienstleistung soll der Zulieferer systematisch bewertet werden. Eine „Short List“ der IT-Zulieferer soll immer wieder aktuell gehalten werden.

Bestellungen für IT-Geräte außerhalb der IT-Standards müssen vom CIO genehmigt werden.

10.1.2 Rollen „ P15 – IT Supplier Management “ Die folgenden Rollen sind notwendig, um den Prozess abwickeln zu können.

Supplier

Tabelle 43: Prozessrollen „P15 – IT Supplier Management“

152

Zulieferer – bei Anfragen liegt eine Offerte vor, – unterschreibt einen Vertrag, – liefert vereinbarte Dienstleistungen oder bestellte Waren, – stellt die erbrachten Dienstleistungen oder die bestellten Waren in Rechnung.

10.1 P15 – IT-Supplier Management-Prozess IT-Betriebsleiter – erstellt Bestellanforderungen, – bestellt alle für den Betrieb notwendige HW, SW und Dienstleistungen, die im Rahmen des bewilligten Betriebsbudgets genehmigt wurden, – bestellt alle – in Absprache mit dem Projektleiter - für das Projekt notwendigen HW und SW, – stellt sicher, dass im Rahmen von Betriebsaktivitäten bestellte HW, SW oder Dienstleistungen der IT-Standards entsprechen, – bewertet die Leistungsqualität der Zulieferer, – sammelt Erfahrung über Zulieferer und pflegt eine Short List der IT-Zulieferer.

IT

IT-Projektleiter – stellt Bestellanforderungen her, – bestellt alle für das Projekt notwendigen Dienstleistungen, die im Rahmen des bewilligten Projektbudgets genehmigt wurden. – stellt sicher, dass im Rahmen von Projekten bestellte HW, SW oder Dienstleistungen der IT-Standards entsprechen, – bewertet die Leistungsqualität der Zulieferer, – sammelt Erfahrung über Zulieferer und pflegt eine Short List der IT-Zulieferer. System Owner – – – –

nimmt die gelieferten Geräte entgegen, prüft die Vollständigkeit und die Qualität der Anlage, macht Vor-Installation und entsprechende Testarbeit, installiert die gelieferte Ausrüstung und nimmt diese in Betrieb.

IT Controlling – stellt sicher, dass Verträge vorhanden und unterschrieben sind, bevor Bestellungen in Anspruch genommen werden, – kontiert externe Rechnungen, – lässt die Richtigkeit der Rechnung prüfen, – schickt geprüfte Rechnungen an das Rechnungswesen zur Bezahlung.

153

10 Funktionsgruppe „Supplier Management“

10.1.3 Prozessbeschreibung „P15 – IT-Supplier Management“ Hier im A4 Format die Beschreibung des Prozesses. Betrieb & Konfiguration Projektmanagement

Bestellanforderung

Bestellanforderung

IT-Betriebsleiter, Projektleiter

Kostenanfrage

IT-Betriebsleiter

RfP für Projekte

Projektleiter

ManagementEntscheid

Betrieb: CIO Projekt: STC

Beschaffungsantrag

IT-Betriebsleiter Projektleiter

Bestellung

Bestellung

IT-Betriebsleiter, Projektleiter

Lieferung Abnahme

Lieferung (Lagerung, Qualitätskontrolle, Garantie) Abnahmebestätigung

Zulieferer, System Owner, Projektleiter

installierte Geräte

System Owner

Nutzung der Dienstleistung

Projektleiter

Rechnungen

Zulieferer

Offertenanfrage

nein

Input Output

genehmigt ? ja

Beschaffungsauftrag

Betrieb & Konfiguration Projektmanagement Financial Management

Installation / Nutzung

Rechnung

Bewertung Zulieferer

kontierte und bezahlte IT Controlling Rechnungen Bewertungsbericht, „Short List“ Zulieferer

Ende

Bild 46: Prozessbeschreibung „P15 – IT-Supplier Management“

154

IT-Betriebsleiter, Projektleiter

10.2 Prozessabhängigkeiten „Supplier Management“

10.2 Prozessabhängigkeiten „Supplier Management“ Das folgende Bild zeigt die Prozessabhängigkeiten von dem im „Supplier Management“ definierten Prozess mit drei zusätzlichen Prozessen (Financial Management, Projektmanagement, Betrieb & Konfiguration).

Rechnung

Financial

Rechnung Stellung Warenausgang

Supplier

Bestellung Warenausgang

Lieferung Bestellung

Projekt

Beschaffungsantrag

Beschaffungsantrag

Betrieb & Konfiguration

Lieferung

Bild 47: MIIP-Prozessabhängigkeiten „Supplier Management“

155

10 Funktionsgruppe „Supplier Management“

P15 – Supplier Management

Rechnungsstellung Rechnung

P15 – Supplier Management

P04 – Financial Management

Beschaffungsantrag Bestellung

P11 – ITProjektmanagement

Warenausgang Lieferung P15 – Supplier Management

Beschaffungsantrag Bestellung

P14 – IT-Betrieb & Konfigurationsmanagement

Warenausgang Lieferung In dem dargestellten Prozessmodell werden Einkäufe von IT-Geräten und ITAnlagen durch die Betriebsorganisation gewährleistet. Damit wird sichergestellt, dass Standards eingehalten werden. Im Rahmen von Projekten werden zusätzlich externe Dienstleistungen eingekauft. Die entsprechenden Aktivitäten (Wahl der Provider, Aufwanderfassung, Qualitätsprüfung,...) werden dann von dem Projektleiter durchgeführt, während alle notwendige Geräte oder Anlagen (neue Servers) auch durch die Betriebsorganisation abgewickelt sind. Die finanziellen Belange werden dann durch den „IT Financial Management“Prozess abgedeckt. Die Wahl eines Zulieferers bleibt ein entscheidender Punkt. Eine strukturierte Vorgehensweise und die Anwendung einer Check-Liste sind sehr wertvoll und empfehlenswert.

156

11 Funktionsgruppe „IT Support“ Zwei Prozesse bilden die Funktionsgruppe „IT Support“: – P16 - Incident Management, – P17 - Problem Management, die in diesem Kapitel detailliert beschrieben werden. Aufgrund der Prozessabhängigkeiten müssen drei zusätzliche Prozesse berücksichtigt werden: – P10 - Anforderungsmanagement, – P12 - Release Management, – P14 - IT-Betrieb & Konfiguration. Die Beziehungen zu diesen drei Prozessen werden am Ende des Kapitels erläutert.

11.1 P16 - Incident Management-Prozess Der Prozess “Incident Management” stellt sicher, dass Services bei Störungen so schnell wie möglich, maximal in der vereinbarten Zeit wiederhergestellt werden. Alle eingehenden Meldungen via Telefon, Mail oder Web-Meldungen werden systematisch als Ticket festgehalten. In den meisten Fällen erzielt der Prozess eine schnelle Lösung der gemeldeten Störungen. Die Lösung der Incidents erfolgt durch die IT-Organisation. Dort wird an der Stelle zwischen unterschiedlichen „Support Levels“ unterschieden: – der Helpdesk gilt als „Single Point of Contact” (SPOC) und wirkt als 1st Level Support, – 2nd Level Support: spezialisierte Teams, die für ein Arbeitsgebiet wie PCSupport zuständig sind, – 3rd Level Support: vertiefte spezialisierte Teams mit einem ganz speziellen Wissen.

157

11 Funktionsgruppe „IT Support“ Die Kommunikation spielt eine wichtige Rolle und folgende Punkte sollen an der Stelle berücksichtigt werden: Habe ich das Problem und die Kritikalität verstanden? Hat das Ticket die richtige Priorität erhalten?

Rückfragen und weitere Informationen anfordern

Wenn das Problem klar ist, ist es die Lösung vielleicht auch ….

Die Lösung entwickeln, testen, abnehmen lassen und einführen. Erkenntnisse / Rückfragen an den Fachbereich wenn immer möglich im Ticket dokumentieren!

Vielleicht braucht es aber auch weitere Abklärungen oder Unterstützung von Kollegen im Fachbereich!? Kann die Behebung des Problems nicht in der vorgesehenen oder mit dem Kunden vereinbarten Frist erledigt werden!

Kunden informieren und einen neuen Termin ausmachen

Es ist wichtig, die Kritikalität der Incidents zu klassifizieren und eine angemessene Eskalation zu definieren. Die folgenden Definitionen gelten als mögliche Beispiele: Priorität 1: Unternehmenskritische Anwendungen – Das System ist nicht operativ. Es gibt keinen annehmbaren Weg, das Problem zu umgehen. Der Ausfall bedeutet für das Unternehmen eine ernsthafte Bedrohung sowohl in finanzieller wie geschäftlicher Hinsicht. Der Systemausfall hat für die Firma, ihre Anwender und ihre Kunden ernsthafte geschäftliche, operative und finanzielle Auswirkungen. Eine bedeutende Anzahl von Anwendern ist davon betroffen. Der Ausfall der Anwendungen hat weiter zur Folge, dass die Benutzer ihre Arbeit entweder gar nicht oder in wichtigen Teilen nicht ausführen können – Ein Priorität-1-Fehler muss sofort und ohne Unterbrechung einer Lösung zugeführt werden. Die Problemlösung darf nicht länger als die hierfür festgelegte Zeitspanne betragen. Wenn nicht anders vereinbart, dann gilt als vorgegebene Zeitspanne für die Problemlösung der Zeitpunkt ab Aufnahme des Problems im Incident Management System bis zur Implementierung und Abnahme der Lösung durch den Anwender.

158

11.1 P16 - Incident Management-Prozess Priorität 2: Geschäftskritische Anwendungen – Wichtige Systemfunktionen sind nicht verfügbar, nicht verwendbar oder die gesamte Systemperformanz ist wesentlich (über 10%) unter der normalen Leistung. Es gibt eine akzeptable Möglichkeit, das Problem zu umgehen (zum Beispiel können die Abläufe auf eine andere Art ausgeführt werden). Ein manueller Eingriff ist erforderlich, um das System wieder korrekt laufen zu lassen. Performanz- und funktionale Probleme verhindern, dass Anwender, System-Administratoren oder Wartungspersonal ihre Arbeit ausführen können. – Ein Priorität-2-Fehler muss sofort angegangen werden und muss innerhalb der angegebenen Frist für Priorität-2 gelöst werden. Wenn nicht anders vereinbart, dann gilt als vorgegebene Zeitspanne für die Problemlösung der Zeitpunkt ab Aufnahme des Problems im Incident Management System bis zur Implementierung und Abnahme der Lösung durch den Anwender. Priorität 3: Andere Anwendungen – Nebensächliche Systemfunktionen sind nicht verfügbar, nicht verwendbar oder die gesamte Systemperformanz ist bis 10% unterhalb der maximalen Leistung. Funktionale Probleme oder Probleme mit der Performanz sind für eine kleine Anzahl von Anwendern, System-Administratoren oder Wartungspersonal Ursache für Unbequemlichkeit. Es sind für die Benutzer, welche das Problem entdeckt haben, akzeptable Möglichkeiten vorhanden, es zu umgehen. – Ein Priorität-3-Problem muss korrigiert werden. Damit kann jedoch bis zum nächsten größeren Release gewartet werden. – Ein Priorität-3-Fehler muss innerhalb der angegebenen Frist gelöst werden. Wenn nicht anders vereinbart, dann gilt als vorgegebene Zeitspanne für die Problemlösung der Zeitpunkt ab der Problemmeldung bis zur Implementierung und Abnahme der Lösung durch den Anwender.

159

11 Funktionsgruppe „IT Support“

11.1.2 Hauptaktivitäten „P16 – Incident Management“ In der folgenden Tabelle werden die Hauptaktivitäten des Incident ManagementProzesses beschrieben. Tabelle 44: Hauptaktivitäten „P16 – Incident Management“

Hauptschritte

Beschreibung

Störungen identifizieren, Call entgegen nehmen und registrieren

Störungen werden durch die Anwender und durch den ITBetrieb gemeldet. Störungen können durch Systemüberwachung festgestellt und automatisch registriert werden.

Erste Unterstützung leisten und TicketPriorität festlegen

Mit dem Anwender wird die Priorität der Störung festgelegt und dem betroffenen Service zugeordnet. Durch Abfrage der Wissensdatenbank ist es durchaus möglich, dem Anwender eine rasche Hilfestellung anzubieten. Sofern die Störung bereits gemeldet worden ist, wird diese der in Bearbeitung befindlichen Störung zugeordnet.

Incident lösen

Handelt es sich um eine komplexere Störung, wird ein Incident Ticket kreiert und der entsprechenden Betriebseinheit Support zugewiesen. Der Anwender wird kontinuierlich über die Schritte der Ticketbearbeitung via Mail informiert. Falls das Incident nicht einfach lösbar ist, wird das Ticket als Problem eingestuft.

Call oder Incident Die Qualitätssicherung der Dokumentation hat eine große Ticket abschließen Bedeutung. Vor dem Abschließen des Tickets werden die Informationen vollständig und verständlich eingetragen. Das Ticket wird abgeschlossen und ein Mail wird an den User zugeschickt. Anwender back

160

Feed- Der Anwender hat die Möglichkeit, ein Feedback über den Service zu geben.

11.1 P16 - Incident Management-Prozess

11.1.2 Rollen „P16 – Incident Management“ Die folgenden Rollen sind notwendig, um den Prozess abwickeln zu können.

Business

Tabelle 45: Prozessrollen „P16 - Incident Management“

Anwender – meldet Störungen, – nimmt die Lösung ab.

Helpdesk Agent

IT

– nimmt den Call entgegen, – erfasst das Call Ticket, leistet erste Hilfe und schließt Ticket, – bei Störung, kreiert ein Incident Ticket und leitet es weiter. 2nd Level Support – nimmt den Incident entgegen und löst die Störung, gemäß TicketPriorität, – bei komplexer Störung, erstellt ein Problem Ticket, – informiert den User über den Ticketstatus, – schließt das Incident Ticket. Eskalationswege müssen auch ganz klar definiert werden, wie zum Beispiel: Priorität 1: Missionskritische Anwendungen – nach 20 Minuten: Eskalation zu System Owner – nach 30 Minuten: Eskalation zu IT-Betriebsleiter, Account Management, Applikation Owner – nach 4 Stunden: Eskalation zu Leiter Account Management und Information Manager – nach 12 Stunden: Eskalation zu CIO und CEO Priorität 2: Businesskritische Anwendungen – nach 40 Minuten: Eskalation zu System Owner – nach 2 Stunden: Eskalation zu IT-Betriebsleiter, Account Management, – Application Owner – nach 12 Stunden: Eskalation zu Leiter Account Management und Information Manager – nach 24 Stunden: Eskalation zu CIO und CEO

161

11 Funktionsgruppe „IT Support“ Priorität 3: Andere Anwendungen – Nach 100 Minuten: keine Eskalation, nur die Priorität ändert sich – Nach 12 Stunden: Eskalation zu IT-Betriebsleiter, Account Management, Application Owner – Nach 24 Stunden: Eskalation zu Leiter Account Management und Information Manager

162

11.1 P16 - Incident Management-Prozess

11.1.3 Prozessbeschreibung „P16 – Incident Management“ Nachfolgend im A4 Format die Beschreibung des Prozesses Eingehende Mails oder Anrufe Call Ticket eröffnen und ergänzen

Call

Erste Analyse des Calls und Priorität definieren

Anforderungsmanagement

ja

Betrieb & Konfiguration

Änderung nötig ?

Anwender

Call Ticket

Helpdesk Agent

Ticket-Priorität

Anwender, Helpdesk Agent

Anforderung

Helpdesk Agent

Wissensdatenbank

Call gelöst ? nein

Incident Ticket kreieren

Incident

Kundenmeldung

nein ja

Incident bearbeiten

Problem Management

Input Output

nein

Incident gelöst ?

Lösungsvorschlag

Helpdesk Agent

Incident Ticket, Infomail zu System Owner

Helpdesk Agent

bearbeitetes Ticket

2nd Level Support

Problem Ticket

System Owner

Abschliessen

ja

Lösung dokumentieren

Kunden informieren Ticket schließen

Ende

dokumentiertes Ticket Helpdesk Agent 2nd Level Support

Info zu User Closed Ticket Infomail zu User Feedback

2nd Level Support, Anwender Helpdesk Agent, 2nd Level Support Anwender

Bild 48: Prozessbeschreibung „P16 - Incident Management“

163

11 Funktionsgruppe „IT Support“

11.2 P17 - Problem Management-Prozess Das Problem Management hat die Aufgabe, Störungen und deren Auswirkungen auf die IT-Infrastruktur zu minimieren und so die Betriebsstabilität zu gewährleisten. Vorhandene Fehler werden aufgrund von aufgetretenen Störungen oder sich abzeichnenden Problemen analysiert und behoben. Im Gegensatz zum Incident Management, welches eine rasche Lösung bzw. Wiederherstellung zum Ziel hat, liegt das Ziel des Problem Managements im Analysieren der Fehlerursache und in der Implementierung einer nachhaltigen Lösung. Aus Erfahrung entstehen typische Probleme: – Bei Auftreten von Performance-Engpässen. Diese müssen in der Regel über eine gewisse Zeitspanne verifiziert und messbar gemacht werden. – Nach Einführung von Projekten oder neuer Komponenten, – Bei Störungen, die unregelmäßig auftreten.

11.2.1 Hauptaktivitäten „P17 – Problem Management“ In der folgenden Tabelle werden die Hauptaktivitäten des Problem ManagementProzesses beschrieben. Tabelle 46: Hauptaktivitäten „P17 – Problem Management“

Hauptschritte

Beschreibung

Problem melden und erkennen

Der Input kommt von dem Incident-Prozess.

Problem lösen

Das Problem wird hinsichtlich seines Umfangs und seiner Auswirkungen bewertet. Die Problemlösung muss unter der Kontrolle der Implementierung durchgeführt werden. Der erfolgreiche Abschluss wird durch eine Nachkontrolle bestätigt (z.B. telefonische Anfrage beim Kunden).

Überwachen, steuern und informieren

– Fortschrittsüberwachung während der Beseitigung von Problemen – Aufzeichnen der Problembearbeitung für späteres Reporting – Wenn erforderlich, Eskalation gemäß Richtlinien auslösen Um Probleme effizient lösen zu können, sind folgende Schritte definiert.

164

11.2 P17 - Problem Management-Prozess

  (UJHEQLV EHZHUWHQ

 /¸VXQJ HLQI¾KUHQ

3UREOHP LGHQWLIL]LHUHQ XQG DXVZ¦KOHQ

3UREOHP O¸VXQJV DEODXI



 3UREOHP DQDO\VLHUHQ XQG8UVDFKHQ EHVWLPPHQ

0¸JOLFKH /¸VXQJHQ HUDUEHLWHQ



/¸VXQJHQ DXVZ¦KOHQ XQGSODQHQ

Bild 49: Ablauf Problem Management (Quelle = ABB Industrie)

Der Problemlösungszyklus kann für Probleme jeglicher Komplexitäts-Stufe angewendet werden. Folgende Schritte sind empfohlen: Schritt 1: Situationsanalyse Der Zweck der Situationsanalyse besteht darin, sich mit der Problemstellung und der Aufgabenstellung vertraut zu machen: – – – – –

Verständliche Beschreibung des Problems Beschaffung von Informationen Abgrenzung festlegen Strukturierung der Problemstellung Klassifizierung (Impakt, Dringlichkeit, Priorität)

165

11 Funktionsgruppe „IT Support“ Schritt 2: Zielformulierung Zweck der Zielformulierung ist die systematische Zusammenstellung der Absichten, die der Lösungssuche zugrunde gelegt werden sollen: – präzise und verständlich, – realistisch, – Priorität klar festlegen. Schritt 3: Mögliche Lösungen erarbeiten Zweck ist es auf den Ergebnissen der Situationsanalyse bzw. Zielformulierung aufbauend Lösungsvarianten zu erarbeiten (Synthese). Danach müssen die Lösungsvarianten geprüft werden, ob sie auch den Anforderungen genügen. Schritt 4: Lösung auswählen und planen Der Zweck besteht darin, taugliche Lösungen einander systematisch gegenüber zu stellen, um die am besten geeignete Lösung heraus zu finden. Schritt 5: Lösung einführen Die Lösung wird eingeführt. Schritt 6: Ergebnis bewerten Es wird überprüft, ob das Problem gelöst worden ist.

166

11.2 P17 - Problem Management-Prozess

11.2.2 Rollen „P17 – Problem Management“ Die folgenden Rollen sind notwendig, um den Prozess abwickeln zu können. Tabelle 47: Prozessrollen „P17 – Problem Management“

IT-Betriebsleiter – ist für den reibungslosen IT-Betrieb verantwortlich, – bestimmt die Vorgehensweise zur Lösung der Probleme und die entsprechenden Verantwortlichkeiten.

IT

Problem Owner – hat während des ganzen Problemlösungszyklus die Führung für die Problemlösung, – stellt eine Taskforce zusammen, koordiniert die Task-Mitglieder, informiert und eskaliert, – ist verantwortlich, dass das Problem innert nützlicher Frist gelöst und implementiert wird, – zeichnet sich für die Abwicklung der Problemlösung dem Kunden gegenüber bis zum Ende verantwortlich, – stellt sicher, dass für IT-Anforderungen ein Change Request erstellt wird und durch den Anforderungsmanagement-Prozess bearbeitet wird. Task Force-Mitglied – steht für die Lösung eines Problems zur Verfügung, da oft interdisziplinäre Aktivitäten notwendig sind. System Owner – ist für die betrieblichen Belange des entsprechenden Systems verantwortlich.

167

11 Funktionsgruppe „IT Support“

11.2.3 Prozessbeschreibung „P17 – Problem Management“ Hier im A4 Format die Beschreibung des Prozesses. Incident Management

Problem Owner bestimmen

Untersuchungen, Diagnose

Anforderungsmanagement

ja

Änderung nötig ?

Input Output Problem Ticket Problem Owner, Task Force

Betriebsleiter

Problem-Analyse

Problem Owner, Task Force

Request for Change

Problem Owner

Plan

Problem Owner, System Owner

nein

Änderung planen

Release Management

ja

Release Anforderung ?

Release-Anforderung, Problem Owner wenn nötig

nein

Änderung durchführen

nein

Lösung implementiert

Problem Ticket aktualisieren

Problem gelöst ?

Problem Owner, System Owner

Problem Owner

ja

Änderung dokumentieren

Ticket schließen

Lösungsbeschreibung, Problem Owner, Antrag in der System Owner Wissensdatenbank gelöstes Problem Info an Betriebsleiter

Ende Bild 50: Prozessbeschreibung „P17 - Problem Management“

168

Problem Owner

11.3 Prozessabhängigkeiten „IT Support“

11.3 Prozessabhängigkeiten „IT Support“ Das folgende Bild zeigt die Prozessabhängigkeiten von den zwei im „IT Support „ definierten Prozessen mit drei zusätzlichen Prozessen (Anforderungsmanagement, Release Management, Betrieb & Konfigurationmanagement).

Anforderung Auftrag

ReleaseAuftrag

Release

Auftrag

FixRelease

Email Telefon

Anforderung

Lösung

Anforderung ReleaseAnforderung

Problem Keine Lösung Ticket

Incident Anfrage für SW Client

Problem Wissensdatenbank

Problem Ticket abgeschlossen

Problem gelöst

Betrieb & Konfiguration SW ClientZuordnung

Konfiguration Datenbank

Bild 51: MIIP-Prozessabhängigkeiten „IT Support“

11.3.1 Prozessabhängigkeit „P16 – Incident Management“ P16 – Incident Management

Anforderung

P16 – Incident Management

Anfrage SW Client

P16 – Incident Management

Incident nicht gelöst

Auftrag SW Client-Zuordnung Problem Ticket

P10 – Anforderungsmanagement P14 – IT-Betrieb & Konfiguration P17 – Problem Management

Problem gelöst Wissensdatenbank

169

11 Funktionsgruppe „IT Support“ Falls der Incident nicht schnell gelöst werden kann, wird aus dem Incident Ticket ein Problem Ticket kreiert. Incidents werden zum Problem: – wenn Incidents nicht innerhalb des Ticket Lifecycle behoben werden können, – sofern Incidents nur mit Hilfe von externen Partnern behoben werden können, – wenn sporadisch Störungen innerhalb der Infrastruktur oder einer Applikation auftreten. Am Helpdesk können auch Anfragen oder Anforderungen deponiert werden. In solchem Fall werden die Anforderungen an das Account Management weitergeleitet. Dort werden die notwendigen Abklärungen durchgeführt, um die Anfrage genau zu analysieren. Als letzte Situation wird die direkte Abwicklung einer Anforderung definiert. Dieses wird in Anspruch genommen, um einfache und klar definierte Anforderungen sehr effizient abwickeln zu können. In dem Fall handelt es sich um Anfragen für Software-Client, die schon als Client „paketiert“ sind. Die Client-SoftwareVerteilung zu dem entsprechenden Anwender erfolgt in diesem Prozessmodell automatisch, ohne weitere Kontrolle.

11.3.2 Prozessabhängigkeit „P17 – Problem Management“ P17 – Problem Management P17 – Problem Management

Anforderung Auftrag Release-Anforderung Release-Auftrag

P10 – Anforderungsmanagement P12 – Release Management

Fix Release Problem Ticket abgeschlossen P17 – Problem Management

Incident nicht gelöst Problem Ticket

P16 – Incident Management

Problem gelöst Wissensdatenbank Probleme werden innerhalb der IT-Organisation täglich gelöst. Dennoch muss man feststellen, dass solche Übungen zum Teil komplexe Verfahren verlangen, die richtige Herausforderungen für die Organisation darstellen.

170

11.3 Prozessabhängigkeiten „IT Support“ Anbei einige Beispiele: – sich auf eine Schlussfolgerung stürzen, bevor man alle Aspekte des Problems analysiert hat, – die wichtigsten Daten über das Problem oder über die vorgeschlagenen Lösungen nicht sammeln, – Probleme behandeln, die außerhalb der Kontrolle oder des Einflussbereichs der Mitglieder der Gruppe liegen, – An Problemen arbeiten, die zu allgemein, zu groß oder schlecht definiert sind, – Wichtige Leute in die Lösungssuche nicht einbeziehen, – Implementierung nicht ausreichend planen. Aus einer Problemanalyse kann auch eine Anforderung formuliert werden, wenn z.B. ein Projekt notwendig wäre, um die geeignete Lösung des Problems umsetzen zu können. Um die Auswirkung des Problems zu begrenzen, können gegebenenfalls Umgehungslösungen (auf English „workarounds“) stattfinden. Damit wird sichergestellt, dass die operativen Tätigkeiten weiterhin abgewickelt werden. Eine Release-Anforderung bedingt die Problemlösung durch eine ProgrammÄnderung. Diese kann nicht ohne Berücksichtigung des Release ManagementProzesses durchgeführt werden. Für dringende Bug-Fixing wird ein so genanntes „Fix-Release“ in Anspruch genommen. Probleme, die keine sofortige Software-Anpassungen verlangen, können auch im Rahmen eines geplanten Release aufgehoben werden. In beiden Fällen wird eine Anforderung erstellt und deren Abwicklung gemäß Release Management-Prozess geplant.

171

12 Einführung der IT-Prozesse Entscheidend ist die Tatsache, dass die IT-Organisation „richtig“ funktioniert. Das MIIP-Modell soll dazu beitragen, die verschiedenen Abhängigkeiten und die notwendigen Rollen definieren und verstehen zu können. Dennoch bleibt die Frage offen: „was mache ich damit?“ Um diese Frage zu beantworten, werden vier unterschiedliche Aspekte berücksichtigt: – wie können die IT-Prozesse eingeführt werden? Bei der Fragestellung geht es darum, die folgende Situation zu lösen. Ein Reifen muss gewechselt werden, obwohl das Auto immer noch fährt. Mit anderen Worten, die IT-Organisation muss gleichzeitig den normalen Betrieb sicherstellen und die Einführung neuer Prozesse ermöglichen. – Wie soll die IT-Organisation sich entwickeln? Die Prozesseinführung hat Auswirkungen auf die gesamt IT-Organisation und auf die Mitarbeiter. Was bedeutet es eigentlich für meinen Job? Wie soll ich mich verhalten? Diese Fragen werden zwangsläufig gestellt, und eine adäquate Antwort ist ein Schlüsselerfolgsfaktor. – Wie werden die Prozesse durch EDV-Tools unterstützt? Man sagt, dass der Schuhmacher die schlechtesten Schuhe trägt. Das kann man auch oft von der Informatik behaupten. Es gibt sicher gute Gründe dazu. Dennoch ist es ein Versuch wert, die IT für die Informatik auch professionell zu betreiben. – Ist Outsourcing die Lösung aller Sorgen? Es ist mehr als ein Modephänomen: Outsourcing oder sogar Offshoring nahmen in den vergangenen Jahren große Bedeutung an.

173

12 Einführung der IT-Prozesse

12.1 Wie sieht eine Einführung aus? Um die MIIP-Prozesse optimal zu führen, ist es vorerst wichtig, die Ausgangslage zu kennen. Handelt es sich um eine Organisation, die über verschiedene Länder verbreitet ist? Gibt es etwa spezifische Industrierichtlinien, wie Computer System Validation in der Pharma-Industrie oder Basel II im Bankensektor? Entscheidend ist sicher, die Einführung so schnell wie möglich durchführen zu können. Dadurch werden mögliche Organisationsänderungen oder Managementwechsel vermieden. Die Unsicherheitsdauer wird auch begrenzt. Dennoch braucht es mehrere Monate, bis ein Prozess effektiv und reibungslos läuft. Die Benutzung des MIIP-Modells soll ermöglichen, dass die Einführung erfolgreich innerhalb eines verkürzten Zeitrahmens realisiert wird. Die Implementierung des MIIP-Modells für ein mittleres Unternehmen (z.B. 500 Mitarbeiter insgesamt) dauert ca. 1 Jahr. Die Realisierung teilt sich auf in vier Hauptphasen von jeweils einem Quartal: Analyse / Vorbereitung In dieser ersten Phase sollen alle Aktivitäten, die für die Implementierung der ITProzesse notwendig sind, definiert und geplant werden. Die Kommunikation und die Beteiligung des IT-Managements sind entscheidend. Als Ergebnis dieser Phase soll die Prozesslandkarte verabschiedet und die Prozess Owners nominiert, mindestens identifiziert werden. Es ist stark zu empfehlen, ein Projekt aufzusetzen. Damit werden wichtige Aspekte wie Planung oder Kommunikation automatisch abgedeckt. Ein Kick-off wird dann stattfinden, damit alle Stakeholders informiert werden. Einführung „Welle A“ Bei der „Welle A“ ist eine Gruppierung von IT-Prozessen gemeint. Es wird empfohlen, alle Prozesse, die zu derselben Funktionsgruppe gehören, gleichzeitig einzuführen. In der „Welle A“ sollen die Prozesse berücksichtigt werden, bei denen der Schuh am meisten drückt. Einführung „Welle B“ Die Welle B ist auch eine Gruppierung von Prozessen, die möglicherweise zu denselben Funktionsgruppen gehören. Idealerweise werden 5 bis 6 Prozesse in dieser Phase implementiert.

174

12.1 Wie sieht eine Einführung aus? Einführung „Welle C“ Die Welle C beinhaltet alle übrigen Prozesse. In dem nachfolgenden Bild ist die Abwicklung der Prozesseinführung erkennbar. Jahr n 1 Q.

2 Q.

Jahr n+1 3 Q.

4 Q.

1 Q.

2 Q.

3 Q.

4 Q.

Analyse Vorbereitung

Kick-off

Einführung Nachprüfung

Welle „A“ Einführung

Nachprüfung

Welle „B“

Einführung Welle „C“

Nachprüfung

Bild 52: Vorgehensweise bei der Einführung der IT-Prozesse

Ein weiteres Element erscheint auf dem Bild, und zwar die Nachprüfung. Während der Implementierung der Prozesse haben sich möglicherweise die ersten implementierten Prozesse geändert und hoffentlich weiterentwickelt. Die Definition der drei Wellen ist jeder Organisation überlassen. Es ist empfehlenswert, mit operativen IT-Prozessen wie zum Beispiel P16 - Incident Management anzufangen. Damit werden die zum Teil abstrakten Prozessbegriffe sofort begreifbar. In der folgenden Abbildung wird ein Plan zur Einführung der ITProzesse vorgeschlagen. Bei einer Welleneinführung sollen Workshops geplant werden. An dieser Stelle wird zuerst ein Brainstorming über den Prozess stattfinden. Es geht darum, alle Ideen und alle möglichen unterschiedlichen Auffassungen der Begriffe auszutauschen. In einem zweiten Schritt wird ein Prozess-Flow präsentiert und von dem (potentiellen) Prozess Owner kommentiert. Am Schluss findet eine „Fragen und Antworten“ Runde statt, in der die offenen Punkte festgehalten werden. Idealerweise wird 1 Prozess innerhalb eines ½ Tages behandelt. Dies bedeutet, dass das IT Management dafür 3 Tage im Quartal reservieren soll. Schätzungsweise braucht das Management 4 bis 5 Tage im Monat, quasi 1 Tag pro Woche, um diese Übung

175

12 Einführung der IT-Prozesse durchführen zu können. Die Schätzung umfasst die Vorbereitungs- und die Nacharbeitungszeit. Jahr n 1. Quartal Analyse Vorbereitung

Kick-off

2. Quartal

3. Quartal

4. Quartal

Welle „A“ Change Management P11 - Projektmanagement P12 - Release Management P13 - Applikationsentwicklung

Welle „B“

Planung & Controlling IT Support P16 - Incident Management P06 - IT Projekt Portfolio P17 - Problem Management P07 - Capacity / Availability P08 - Continuity Account Management Welle „C“ P09 - Service Management P10 - Anforderungsmanagement Strategische EntscheidungsBetrieb & Konfiguration P14 - IT-Betrieb & Konfiguration prozesse P01 - IT-Strategie P02 - HR-Management P03 - IT-Standards & Architektur P04 - Financial Management P05 - Qualitätsmanagement Supply Management P15 - Supplier Management

Bild 53: Möglicher Plan zur Einführung der IT-Prozesse

Im obigen Beispiel wurde die Implementierung nach einem „Bottom-up“-Ansatz konzipiert, von den operativen zu den strategischen Prozessen. Als Projektmotto kann das folgende Akronym benutzt werden: EASY! E Enlarge Wir behalten immer das Gesamtinteresse im Auge und verstehen uns als Team. A Analyse Unsere analytischen Kompetenzen ergänzen sich gegenseitig. S Solve Wir fokussieren uns rasch auf Lösungen. Y Yes Wir sind offen für das bessere Argument und unterstützen die Umsetzung der Lösung. Das Engagement der Mitarbeiter und vor allem des Management ist ein „Key Success Factor“. Die Einführung kann mit einer KVP (Kontinuierlicher VerbesserungsProzess) kombiniert werden.

176

12.2 Entwicklung der IT-Organisation

12.2 Entwicklung der IT-Organisation Die Einführung der IT-Prozesse verursacht in den meisten Fällen organisatorische Anpassungen. Dies kreiert Unsicherheiten und führt zu Widerständen. Viele Gründe können diese Reaktion erklären: – Angst vor der zunehmenden Transparenz, – Überforderung durch die Integrationsaspekte, – Produktivitätsdruck durch Effektivitätssteigerung, – Fehlende Kommunikation und mangelhafte Einbindung. Es ist dann wichtig, die Entwicklung der IT-Organisation und der IT-Mitarbeiter zu berücksichtigen. Das Veränderungsmanagement trägt dazu bei, diese komplexen Aspekte zu adressieren und gehört zu den „normalen“ Managementaufgaben. In der Literatur stehen verschiedene Modelle zur Verfügung. Verschiedene Schritte werden dann definiert und entscheidend ist vor allem, die klaren Gründe der Veränderung und deren positive Auswirkungen zu kommunizieren. Psychologie (Erwartungen, Motivation) und Führung sind zwei essentielle Elemente. Auf der individuellen Ebene wird sich eine Reihe von Fragen automatisch stellen. Diese können in vier Hauptkategorien klassifiziert werden: – – – –

Lohn und Bonifikation, Stellenbeschreibung, Karriere-Entwicklung, Soziales Umfeld. • Ist die Arbeit herausfordernd? • Kann ich meine Kenntnisse erweitern? • Kann ich selber Entscheide treffen? • Ist die Arbeit von den Kollegen und in meiner Privatsphäre anerkannt? • Macht die Arbeit Spaß? • Wird mein Wissen sich erweitern?

• Wie wird meine Leistung gemessen? • Ist mein Lohn marktkonform? • Welches Bonifikationssystem ist aufgesetzt? • Wie trägt meine Leistung zum Erfolg des Unternehmens bei?

Lohn und Bonifikation

KarriereEntwicklung • Entspricht dieser Arbeit eine Beförderung? • Habe ich genug Unterstützung? • Lerne ich was Neues? • Darf ich mehr Verantwortungen übernehmen? • Wie schnell entwickelt sich meine Karriere?

Stellenbeschreibung

Soziales Umfeld • Teile ich die Werte und Ziele? • Wie findet die Teamarbeit statt? • Wie ist die Unternehmenskultur? • Wie läuft die Kommunikation? • Sind Arbeitsbeziehungen offen und vertrauenswürdig? • Ist mein Beruf anerkannt?

Bild 54: Motivationsfaktoren

177

12 Einführung der IT-Prozesse Ein bekanntes Phänomen, als „Jammertal“ genannt, erscheint meistens, wenn Veränderungen stattfinden. Nach einer positiven oder neugierigen, manchmal sogar euphorischen Stimmung, folgt die Konfrontation zur Realität. Der Geist rebelliert und verweigert die notwendigen Konsequenzen der Veränderung. Wenn der Tiefpunkt erreicht ist, fängt die Akzeptanzkurve, wenn vorhanden, sich zu steigern. Wie sieht mein Lohn aus?

Wie sieht mein MBO aus? (MBO = Management by Objectives)

Behalte ich mein Büro? Welche Tätigkeiten habe ich?

Kann ich mein Dienstauto beibehalten?

Wie werde ich eingestuft? Was Was passiert passiert mit mit meiner meiner Stelle? Stelle?

Bin ich in der Lage, die neuen Aufgaben zu meistern?

Muss ich noch auf eine weitere Förderungsrunde warten?

Behalte Behalte ich ich meine meine Arbeit? Arbeit?

Wie ändern sich die Prozesse und die Organisation? Wie wird sich das Team ändern?

Bin ich weiterhin für das Budget und die Mitarbeitenden zuständig?

Werde ich Überstunden machen müssen?

Wer wird mein Chef sein?

Bild 55: Persönliche Fragen bei Veränderung

Die Gratwanderung zwischen Zustimmung (ich werde nach den neuen Vorgaben arbeiten) und Engagement (ich möchte mit neuen Vorgaben arbeiten) hängt von diesen Fragen ab. Schlüssel ist, die Mitarbeiter für die Änderung zu gewinnen. Damit sollte das Risiko der passiven Teilnahme, nach dem Motto „ich werde diese Veränderung ausprobieren und mich damit abfinden“ vermieden werden. Aktive Mitarbeitende dafür wünschen sich die Änderung und setzen sich ein, damit die Veränderung erfolgreich umgesetzt wird. Die Frage, die sich hier stellt, ist, welche Motivationsfaktoren im IT-Bereich eingesetzt werden können. Mehrere Möglichkeiten bieten sich an. Anbei eine nicht erschöpfende Liste: – Wechsel von IT zu Fachbereich ermöglichen: eine IT-Karriere kann zu einer Position in einem Fachbereich führen. Zum Beispiel als Information Manager.

178

12.3 Eine Frage des Tooleinsatzes – Breitere Verantwortung anbieten: eine Stelle mit operativen Tätigkeiten kann zu einer „Management“-Position führen, wo Planung und Überwachung entscheidend sind. – Neue Funktion wahrnehmen: bei der Einführung der IT-Prozesse können neue Rollen und Funktionen begründet werden. Die Stelle zum Beispiel „ITProjekt Portfolio“ kann kreiert und intern besetzt werden. Die Erfahrung zeigt, dass es besonders schwierig ist, Mitarbeiter in der IT zu entwickeln, wenn eigene selbst entwickelte Tools bei der Einführung der IT-Prozesse ersetzt werden. Die emotionale Bindung zu der eingespielten Arbeitsroutine ist meistens schwer zu überwinden. Auf Ebene der IT-Organisation kann das Modell „Plan-Do-Check-Act“ (Planen Entwickeln - Überprüfen - Verbessern) verwendet werden. Damit werden 4 Haupteinheiten definiert: – Planung & Account Management (Plan): diese Einheit verwaltet die Kundenanforderungen und plant die verschiedenen Aktivitäten der ITOrganisation – Projekte & Entwicklung (Do): diese Einheit stellt die Weiterentwicklung der IT-Systeme sicher. Dieses wird im Rahmen von Projekten oder Releases realisiert. – Betrieb & Support (Check): die Einheit stellt sicher, dass die IT-Systeme zur Verfügung stehen. Stabilität und Verfügbarkeit sind die zwei Ziele. – Strategie & Qualität (Act): in vielen IT-Organisationen werden die entsprechenden Rollen in einer kleineren Abteilung mit Stabsstellen aufgesetzt. Es ist auch wichtig, sicherzustellen, dass die IT Governance richtig adressiert wird. Die Definition der Zusammenarbeit und Verbindungen zwischen der IT Organisation und den Fachbereichen müssen sorgfältig analysiert und Schritt für Schritt entwickelt werden.

12.3 Eine Frage des Tooleinsatzes Aufgrund der hohen Frequenz der Prozessaktivitäten, wie zum Beispiel im Helpdesk, ist eine Automatisierung der IT-Prozesse notwendig. Die Frage stellt sich dann, welche Tools eingesetzt werden sollen. Die erste Feststellung ist, dass die Einführung eines „Universaltools“ nicht möglich ist. Die IT-Organisation wird immer mit den zahlreichen Management-EDV-Tools konfrontiert. Typischerweise wird das IT Controlling mit dem Unternehmens Controlling Tool (wie in etwa SAP Fi-Co) arbeiten. Die Verträge werden mit Excel oder mit einem dedizierten System verwaltet. Die Incident Tickets werden mit

179

12 Einführung der IT-Prozesse einem Helpdesk SW überwacht, während Projekte mit einer selbst entwickelten Applikation zum Beispiel verwaltet werden. Die Zeiterfassung wird noch separat abgewickelt. Am Schluss wird mit mindestens 10 verschiedenen Tools jongliert. Eine weitere Schwierigkeit liegt in der Vielfalt der existierenden Tools. Nur für ein Helpdesk Tool stehen mindestens 90 Produkte (nebst Remedy oder Peregrine) zur Verfügung. Bevor ein Tool zur Unterstützung der IT-Prozesse eingeführt wird, soll zuerst geklärt werden, was von diesem erwartet wird. Es ist empfehlenswert, einen Pilot basierend auf einer Testversion des Anbieters zu starten. Damit ergibt sich die Möglichkeit, festzustellen, ob die Software den Anforderungen entspricht und die IT-Prozesse unterstützt. Weiterhin soll die Betriebsinstandhaltung berücksichtigt werden. Die Fragen der notwendigen Schulung und der Verfügbarkeit des Supports seitens Zulieferer sind entscheidend. In der folgenden Tabelle sind Kriterien gelistet, die bei der Wahl einer Software geprüft werden sollen. Tabelle 48: Auswahlkriterien eines EDV-Tools für IT-Prozesse

Bewertungskriterien

Beschreibung

Maßstab

1) Funktiona- Beschreibung der notwen- - 5 Punkte: hervorragend digen Funktionalitäten (z.B. - 3 Punkte: normal litäten Incident Tickets können - 0 Punkt: nicht vorhanden erfasst werden)

Gewich wichten Muss

Kann das Tool Abläufe - 5 Punkte: hervorragend unterstützen (z.B. Geneh- - 3 Punkte: normal migungsverfahren)? - 0 Punkt: nicht vorhanden

20

3) Skalierbar- Kann das System für die - 5 Punkte: hervorragend eigene Bedürfnisse ange- - 3 Punkte: normal keit passt werden? - 0 Punkt: nicht vorhanden

30

4) Informati- Abfragemöglichkeit („onli- - 5 Punkte: hervorragend on & Reporting ne Status“) und verfügbare - 3 Punkte: normal Berichte - 0 Punkt: nicht vorhanden

20

Bietet das Tool Möglichkei- - 5 Punkte: hervorragend ten, eine Wissensdatenbank - 3 Punkte: normal zu pflegen oder Notizen zu - 0 Punkt: nicht vorhanden verwalten?

10

2)

Abläufe

5) Unterstützung und Wissensmanagement

180

12.3 Eine Frage des Tooleinsatzes 6) Zeitmanagement

Können Aktivitäten automatisch gesteuert werden? (z.B. Mail-Avisierung)

- 5 Punkte: hervorragend - 3 Punkte: normal - 0 Punkt: nicht vorhanden

10

7) Tool Integration

Wie einfach kann das Tool mit anderen SW integriert werden?

- 5 Punkte: hervorragend - 3 Punkte: normal - 0 Punkt: nicht vorhanden

30

- 5 Punkte: Standard (wie z.B. Unix) - 3 Punkte: dediziertes System 0 Punkt: kein bekanntes Standard

40

- 5 Punkte: alle Sprachen - 3 Punkte: English + 1 lokale Sprache - 0 Punkt: keine Multisprache Funktionalität - 5 Punkte: hervorragend - 3 Punkte: normal - 0 Punkt: nicht vorhanden

20

8) Systeman- Welche Systeme werden benötigt (Betriebsysforderungen tem,…)?

9)

Sprachen

Welche Sprachen werden unterstützt?

10) Sicherheit und User Management

Sind die Sicherheitsaspekte abgedeckt und das User Management einfach zu implementieren und verwalten?

11) Strategie des Anbieters

Wie sieht die Strategie des Anbieters bezüglich der Weiterentwicklung des Produktes aus?

- 5 Punkte:

40

30

Lange Tradition und klare Weiterentwicklung - 3 Punkte: kurze Vergangenheit und klare Strategie - 0 Punkt: keine überzeugende Verkaufargumente

12) Produktentwicklung

Welche Produktentwicklung ist vorgesehen?

- 5 Punkte:

20

Klares Release Management - 3 Punkte: erweiterte Funktionalitäten geplant - 0 Punkt: keine

181

12 Einführung der IT-Prozesse 13) Notwendi- Welche Kompetenzen sind ge Kompeten- erforderlich, um das Produkt instand zu halten? zen

30

- 5 Punkte: Keine spezifische - 3 Punkte: spezifische - 0 Punkt: sehr speziell

14) Verbreitung des Produktes

In welcher Industrie und bei welcher Unternehmensgröße ist die Lösung eingeführt worden?

40

- 5 Punkte: Ähnliche Größe, ähnliche Industrie - 3 Punkte: ähnliche Größe - 0 Punkt: noch nirgends eingeführt

15) Kundenservice

Wie sieht die Kundenbetreuung aus?

20

- 5 Punkte: Schnell ziert

und

unkompli-

- 3 Punkte: Standardangebot - 0 Punkt: nicht vorhanden

16) Geographische Flächendeckung

Wie flächendeckend wird der Service angeboten?

- 5 Punkte:

10

weltweit - 3 Punkte: landesweit - 0 Punkt: lokal

17) Kosten

Wie hoch sind die Kosten (Lizenzen, Einführung, Betrieb)?

- 5 Punkte:

30

Tief im Vergleich zu ähnlichen SW-Lösungen - 3 Punkte: marktgerecht - 0 Punkt: sehr teuer

18) Tragfähig- Wie solid (finanziell) ist der keit des Anbie- Anbieter? ters

- 5 Punkte: Hohe Betriebseinnahmen - 3 Punkte: marktgerecht - 0 Punkt: Verlustgeschäft

182

40

12.3 Eine Frage des Tooleinsatzes 19) Marktanteil

Wie weit ist die Lösung verbreitet?

30

- 5 Punkte: Industriestandard - 3 Punkte: signifikanter Markanteil - 0 Punkt: Marktanteil

20) Interne Über welche Ressourcen Ressourcen des verfügt der Anbieter? Anbieters

marginaler

- 5 Punkte:

30

Mehr als 1´000 MA - 3 Punkte: mehr als 100 MA - 0 Punkt: sehr begrenzt

In dieser Tabelle sind 20 Kriterien gelistet (Gesamtgewichtung = 500). Dieses zeigt schon, wie komplex und wie arbeitsintensiv die Wahl einer SW Lösung ist. Viele Informationen sind nötig, um den Entscheid optimal gestalten zu können: 1. Produktbeschreibung Aus Sicht des Anbieters ist sein Produkt das Beste auf dem Markt. Es ist oft üblich, dass das SW-Paket wie eine Zauberformel wirkt. Die Vorteile und Nachteile der SW-Lösung im Hinblick auf die formulierten Anforderungen müssen ganz klar offen gelegt werden. 2. Produkt-Pilotierung Das Produkt soll idealerweise getestet werden. Eine Probeinstallation bietet eine gute Möglichkeit an, den Service zu prüfen und die Komplexität der EDVLösung zu schätzen. 3. Preiskatalog Die Preisstruktur des Produkts und die angebotenen Zusatzdienstleistungen ermöglichen eine erste Bewertung, wie professionell der Anbieter ist. 4. Best Practices-Berichte Berichte oder Artikel über ähnliche Umsetzungen können als wertvolle Quelle benutzt werden, um die Einführungsaufwände und Dauer schätzen zu können. 5. Kundenreferenzen Zufriedene Kunden stellen immer ein gutes Verkaufsargument dar. Es lohnt sich oft, direkt bei den Unternehmen ein kurzes Interview durchzuführen. Damit werden wertvolle Informationen aus der Praxis gewonnen.

183

12 Einführung der IT-Prozesse 6. Informationen über den Hersteller Ein Blick auf die Internet-Seiten reicht meistens, um die Kennzahlen und die geographische Verteilung des Herstellers zu erfahren. Vision und strategische Entwicklung sind auch entscheidend. 7. Benchmark Produktvergleiche werden oft im Rahmen von Studien veröffentlicht. Spezialisierte Unternehmen bieten zahlreiche Dienstleitungen in diesem Gebiet. Die Einführung eines Tools bietet oft die Gelegenheit, neue IT-Prozesse umzusetzen. Bei der Übung spielen die Akzeptanz der Anwender und die kurze Dauer der Einführung eine entscheidende Rolle. Um dies realisieren zu können, soll eine Projektorganisation, wie bei einem „normalen“ IT-Projekt, definiert werden. Die Unterstützung des IT Managements stellt ein Muss dar, und die aktive Projektarbeit der IT-Mitarbeiter ist absolut erforderlich. Man wird oft mit den grundsätzlichen Problemen der Organisationsstrukturen konfrontiert. Diese Aspekte müssen berücksichtigt werden, damit die neue Lösung überhaupt akzeptiert und erfolgreich benutzt wird.

12.4 Wie sieht es mit Outsourcing aus? Das Wort „Outsourcing“ steht für die Zusammenfassung des englischen Begriffs „Outside resource using“. Viele Unternehmen haben sich für ein Outsourcing der IT Services entschieden, entweder komplett oder selektiv. Damit wird erwartet, dass professionelle, flexible und kostengünstige Dienstleistungen bezogen werden können. Die Überlegung ist an und für sich legitim. Wenn ein Service, zum Beispiel Server Management, in Anspruch genommen wird, kann man damit rechnen, dass kein Fachwissen intern aufgebaut werden muss, dass größere Kostenersparnisse ermöglicht werden und dass die durch andere Kunden gewonnenen Erfahrungen eine Zusatzgarantie bilden. Typischerweise wird ein Outsourcing bei der Einführung einer neuen IT-Kernapplikation in Anspruch genommen, um die speziellen Kompetenzen intern nicht aufbauen zu müssen. In der Tat zeigt aber die Realität, dass viele Versuche scheitern. Je flexibler die Beziehung gestaltet wird, umso höher die Ungenauigkeit und die Unsicherheit bezüglich zusätzlichem Aufwand. Es ist an der Stelle wichtig, transparente SLAs zu definieren, die Klarheit und Verständlichkeit bringen. Die Beschreibung der zu erbringenden Dienstleitungen und die verwendeten Begriffe müssen ganz klar festgelegt werden. Folgende Elemente müssen eindeutig formuliert werden: – – – –

184

Definition der benutzten Begriffe, Beschreibung der Services, Beschreibung der Service-Levels, Beschreibung der Messverfahren und Messgrößen.

12.4 Wie sieht es mit Outsourcing aus? In der Regel wird ein Outsourcing in Etappen entwickelt. Die Startphase Die Frage des Umfangs des Outsourcing muss erst geklärt werden. Handelt es sich um ein komplettes Outsourcing, übergibt zum Beispiel das Unternehmen seine Informatik an einen IT-Dienstleiter, meistens für einen längeren Zeitraum (zum Beispiel 10 Jahre). In diesem Fall wechseln meistens die ehemalige IT-Mitarbeiter in das Drittunternehmen. Die interne Kommunikation spielt an der Stelle eine wichtige Rolle, um die negativen Effekte der Gerüchteküche zu vermeiden. Die kurzfristigen Überlegungen zu den Kostenproblemen sind meistens schlechte Ratgeber. Qualitätsaspekte müssen unter die Lupe genommen werden. Durch die Abhängigkeit von Drittunternehmen müssen zusätzliche Risiken im Kauf genommen werden. Die strategischen und finanziellen Überlegungen müssen an der Stelle klar formuliert werden. Als Beispiel: Strategische Ziele: – optimale Skalierbarkeit, – höhere Konzentration auf die eigenen Kernkompetenzen, – Mangel an Know-how oder qualifizierten Mitarbeitern. Finanzielle Ziele: – Wegfall der externen Wartungs- und Unterhaltskosten der eigenen Infrastruktur, – klar limitierte Betriebs-Gesamtkosten budgetierbar pro User und Monat, – Vermeiden der lokal nötigen Investitionen in Sicherheit und Datenschutz. Es ist auch im Vorfeld wichtig, die geschäftlichen Anforderungen zu definieren. Die Wahl des Partners und die Verhandlung Ein Auswahlprozedere muss aufgesetzt werden. Am besten via Ausschreibung. Damit wird die erwartete Servicequalität festgelegt. Es ist notwendig, die technischen und geschäftlichen Bedürfnisse exakt zu beschreiben. Die kritischen Bereiche müssen identifiziert werden. Wenn ein Reporting System mehrere Tage nicht zur Verfügung steht, kann gegebenenfalls das Unternehmen weiter produzieren und verkaufen. Die in MIIP beschriebenen IT-Prozesse tragen dazu bei, die genauen Abläufe festzuhalten. Weiterhin werden die Messkriterien verhandelt. 99,9% Verfügbarkeit ist dann durchschnittlich pro Jahr oder pro Monat zu verstehen? Während des normalen Betriebs oder inklusiv Wartungszeit? Die Erwartungen des Unternehmens müssen auch mit den finanziellen Mitteln in Relation gebracht werden: ein Helpdesk mit 7 Tagen Verfügbarkeit und mit einer 99,9% Erreichbarkeit wird sehr teuer. In den meisten Fällen sind fünf Wochentage

185

12 Einführung der IT-Prozesse mit acht Stunden, einer Reaktionszeit von 30 Minuten und einer Lösungszeit von zwei Stunden ausreichend. Der Abschluss Verständliche Leistungsbeschreibungen sind wichtig. Zum Beispiel muss abgeklärt werden, ob der Server „nur“ in einem Rechnerzentrum überwacht wird, oder ob Instandhaltungsaufgaben (Upgrade Betriebssystem,…) mit beinhaltet sind. Besonders empfindlich ist die Diskussion bezüglich der Anzahl Software Updates und der Hardware Upgrades. Zusätzlich muss die ganze Entwicklungskette mit der Einspielung von Systemänderungen sorgfältig reglementiert werden. Zwischen 5 und 15 Seiten soll ein SLA beinhalten. SLAs mit 100 Seiten, die sämtliche Aspekte des erbrachten Service betreffen, werden von keiner Seite gelesen und bringen daher nicht viel. Die Verwaltung Es wäre utopisch zu denken, dass mit dem Outsourcing kein internes Fachwissen benötigt wird. Die Schnittstelle zwischen Unternehmen und Anbietern muss noch gepflegt werden. Kontrolle und Steuerung der Partnerschaft werden auf einer regelmäßigen (zum Beispiel wöchentlich) Basis stattfinden. Die in Rechnung gestellten Dienstleitungen müssen auch kontrolliert werden. Im schlimmsten Fall können Strafberechnungen verlangt werden. Die Verlängerung oder das Ende Am Ende der Vertragslaufzeit muss der Entscheid getroffen werden, wie es mit dem Outsourcing weiterlaufen soll. Ein Wechsel des Outsourcing-Partners ist meistens nicht geregelt. Es ist empfehlenswert, im Outsourcing-Vertrag eine Regelung zur Mitwirkungspflicht des Dienstleisters für den Fall der Vertragsauflösung zu treffen. Die aktive Unterstützung des Service-Providers beim Übergang muss geregelt und die Verantwortung für die dadurch anfallenden Kosten klar definiert werden. Meistens werden Benchmarks gezogen und neue Verhandlungen mit dem bestehenden Provider durchgeführt. Im Hinblick auf die MIIP-Prozesse können folgenden IT-Dienstleistungen outgesourced werden: – – – –

Betrieb von ICT-Applikationen (ERP, CRM, MS Office, E-Mail etc.), Betrieb von Servers, Betrieb von Desktop Services, Helpdesk Services.

Kritisch wird das Outsourcing von IT-Projekt Portfolio und IT-Projekte. Damit wäre die ganze Investitionspolitik tangiert. Die Prozesse der Funktionsgruppe „Strategische Entscheidungsprozesse“ sollen auch intern bleiben

186

13 Prozess-Kennzahlen und Reporting Um die Prozesse verwalten und optimieren zu können, werden Messungen vorgenommen. Die Ergebnisse werden in Berichten zeitgerecht veröffentlicht, die dem Management als Steuerungsinstrument dienen sollen. Im diesem Kapitel wird die Vielfalt dieser Messpunkte, oder anders genannt „Kennzahlen“ beleuchtet. Die Wahl brauchbarer und nützlicher Kennzahlen wird vor allem anhand der Beschreibung der im Berichtswesen notwendigen Abläufe deutlich erklärt. Die Erkenntnisse erlauben, ein Reporting für IT-Prozesse aufzusetzen, das aufwandgerecht und effektiv wirkt.

13.1 Definition und Wahl der Prozess-Kennzahlen In der Regel werden pro Prozess Kennzahlen definiert. Diese dienen dazu, den Prozess zu charakterisieren und messbar zu machen. In der Literatur wird oft der Begriff „KPI“ (KPI = Key Performance Indicator) verwendet. Die Bedeutung der Kennzahlen ist groß. Damit werden Zielvorgaben definiert. Es ermöglicht auch eine Vergleichsmöglichkeit, die zu Benchmark-Analyse führen kann. Vor allem kann damit ein besseres Verständnis über die operativen Abläufe gewonnen werden.

13.1.1 Mögliche Prozess-Kennzahlen Die Vielfalt der Kennzahlen, um die Prozesse zu messen, ist grenzenlos. Sobald ein Indikator definiert wird, lässt sich eine Messung davon abziehen. In der folgenden Tabellen sind Beispiele von Kennzahlen, die für die ITIL-Prozesse definiert worden sind: Für IT Security Management Kennzahl (KPI)

Definition

Anzahl implementierter PräventivMaßnahmen

Anzahl präventiver Sicherheitsmaßnahmen, die in Reaktion auf identifizierte Bedrohungen der IT-Sicherheit implementiert worden sind

Umsetzungsdauer Vorsorgemaßnahmen

Zeitspanne von der Identifikation einer Bedrohung der IT-Sicherheit bis zur Implementierung einer geeigneten Gegenmaßnahme

187

13 Prozess-Kennzahlen und Reporting Anzahl schwerwieAnzahl identifizierter, sicherheitsrelevanter Incidents, gender sicherheitsreleklassifiziert nach Schweregrad vanter Incidents Anzahl der Security Anzahl sicherheitsrelevanter Incidents, die zu einer Serbedingten Service- vice-Unterbrechung oder zu einer reduzierten VerfügAusfallzeiten barkeit führen Anzahl von heitstests

Sicher- Anzahl der durchgeführten Sicherheitstests und Trainings

Anzahl identifizierter Anzahl der identifizierten Defizite bezüglich der SicherDefizite im Rahmen heits-Mechanismen, die im Rahmen von Tests ermittelt von Sicherheitstests werden

Für Financial Management Kennzahl (KPI)

Definition

Einhaltung BudgetProzeduren

Anteil der Projekte, die nach dem Standardprozess zur Budgetbewilligung aufgesetzt werden

Kosten-/ NutzenBetrachtung

Anteil der Projekte, die im Projektantrag eine Kosten-/ Nutzen-Betrachtung enthalten

Auswertung nach Projektabschluss

Anteil der Projekte, bei denen Kosten und Nutzen nach Projektende begutachtet werden

Budget-Einhaltung

Anteil der IT-Kosten, der das geplante IT-Budget überschreitet

Einhaltung Projektressourcen

Anteil der Kosten, der die geplanten Projektkosten überschreitet

Anzahl Kostenoptimie- Anzahl der Vorschläge aus dem Financial Management rungen zur Optimierung der IT-Kosten

188

13.1 Definition und Wahl der Prozess-Kennzahlen Für Capacity Management Kennzahl (KPI)

Definition

Anzahl der aufgetretenen Incidents, die auf unzureiIncidents wegen Kapachende Service bzw. Component Capacity zurückzufühzitätsengpasses ren sind Genauigkeit der Kapa- Abweichung der vorhergesagten Kapazitätsentwicklung zitätsprognose vom tatsächlichen Verlauf Häufigkeit Kapazitäts- Anzahl der Anpassungen der Service bzw. Component anpassungen Capacity an sich ändernden Bedarf Anzahl der unvorhergesehenen Erweiterungen der SerUngeplante Kapazitätsvice bzw. Component Capacity als Folge von Kapazianpassungen tätsengpässen Dauer für Lösen von Lösungszeit bis zur Beseitigung eines erkannten KapaziKapazitätsmängeln tätsengpasses Kapazitätsreserven

Prozent der Kapazitätsreserven zu Zeiten von Normalund Spitzenlasten

Anteil Kapazitätsüber- Prozentsatz an Services und Infrastrukturkomponenten wachung unter Kapazitätsüberwachung

189

13 Prozess-Kennzahlen und Reporting Für Availability Management Kennzahl (KPI)

Definition

Service-Verfügbarkeit

Verfügbarkeiten der IT Services relativ zu den in den SLAs vereinbarten Verfügbarkeiten

Anzahl von ServiceUnterbrechungen

Anzahl von Unterbrechungen der IT Services pro Zeitintervall

Dauer von ServiceUnterbrechungen

Durchschnittliche Dauer von Unterbrechungen der IT Services

Anteil Verfügbarkeitsüberwachung

Prozentsatz von Services und Infrastrukturkomponenten unter Verfügbarkeitsüberwachung

Anzahl Verfügbarkeitsmaßnahmen

Anzahl der implementierten Maßnahmen mit dem Ziel der Verfügbarkeitserhöhung

Für IT Service Continuity Management Kennzahl (KPI)

Definition

Geschäftsprozesse mit Kontinuitätsvereinbarungen

Prozentsatz von Geschäftsprozessen auf Kundenseite, die durch explizite Service-Kontinuitäts-Ziele abgedeckt werden

Anzahl VorsorgeLücken

Anzahl identifizierter Lücken bei der Katastrophenvorsorge (schwerwiegende Bedrohungen ohne definierte Gegenmaßnahmen)

Umsetzungsdauer Vorsorgemaßnahmen

Dauer von der Identifizierung eines (mit einem möglichen Katastrophenfall verbundenen) Risikos bis zur Umsetzung einer entsprechenden Vorsorgemaßnahme

Anzahl KatastrophenÜbungen

Anzahl der durchgeführten Katastrophen-Übungen

Anzahl identifizierter Defizite während Katastrophen-Übungen

Anzahl identifizierter Defizite in Vorbereitung auf den Katastrophenfall, die im Rahmen praktischer Übungen identifiziert werden

190

13.1 Definition und Wahl der Prozess-Kennzahlen Für Service Portfolio Management Kennzahl (KPI)

Definition

Anzahl geplanter neuer Services

Prozentsatz neu entwickelter Services, die vom Service Portfolio Management initiiert worden sind

Anzahl ungeplanter neuer Services

Prozentsatz neu entwickelter Services, die nicht vom Service Portfolio Management initiiert worden sind

Anzahl der strategischen Initiativen

Anzahl strategischer Initiativen, die vom Service Portfolio Management angestoßen worden sind

Anzahl von Neukunden

Anzahl neu gewonnener Kunden

Anzahl (an Mitbewerber) verlorener Kunden

Anzahl von Kunden, die an konkurrierende ServiceProvider verloren wurden

Für Service Level Management Kennzahl (KPI)

Definition

Service-Abdeckung

Anzahl der Services, die durch SLAs abgedeckt werden

Service-Abdeckung durch OLAs/ UCs

Anzahl der durch SLAs abgedeckten Services, die durch OLAs bzw. UCs abgesichert sind

Überwachte SLAs

Anzahl überwachter Services/ SLAs, für die Schwachstellen und Gegenmaßnahmen berichtet werden

SLAs unter Review

Anzahl der Services/ SLAs, die regelmäßig einem Review unterzogen werden

Erreichung der SL

Anzahl der erreichten SLAs

Anzahl von Verbesserungspotentialen

Anzahl von Verbesserungspotentialen, die erkannt und in den Service-Verbesserungsplan aufgenommen wurden

191

13 Prozess-Kennzahlen und Reporting Für Change Management Kennzahl (KPI)

Definition

Anzahl wichtiger (Major) Changes

Anzahl wichtiger (Major) Changes, die vom CAB (Change Advisory Board) freigegeben werden müssen

Anzahl von CAB Sitzungen

Anzahl von Einberufungen des CAB (Change Advisory Board)

Zeitbedarf für ChangeFreigabe

Mittlere Zeitdauer von der Einreichung des RFC bis zur Change-Freigabe

Akzeptanzrate für Changes

Verhältnis akzeptierter zu zurückgewiesenen RFCs

Anzahl dringender Changes

Anzahl dringender Changes, die vom ECAB (Emergency Change Advisory Board) freigegeben werden müssen

Für Projektmanagement (Transition Planning und Support) Kennzahl (KPI)

Definition

Anzahl von Projekten

Anzahl wichtiger Release Rollouts unter der Leitung des Projektmanagements

Anzahl von Projekten mit Projektauftrag

Prozentsatz von Projekten, bei deren Start ein unterzeichneter Projektauftrag vorlag

Anzahl von Änderungen am Projektauftrag

Anzahl von Änderungen am Projektauftrag nach dem Beginn des Projektes

Einhaltung des Projekt- Soll-/ Ist-Vergleich (geplanter/ aktueller Stand) des VerBudgets brauchs finanzieller und personeller Ressourcen Projekt-Verzögerungen

192

Soll-/ Ist-Vergleich (geplanter/ aktueller Stand) der Projektabschluss-Termine

13.1 Definition und Wahl der Prozess-Kennzahlen Für Release und Deployment Management Kennzahl (KPI)

Definition

Anzahl von Releases

Anzahl von Releases, die in die produktive ITUmgebung ausgerollt wurden, gruppiert in Major (wichtige, risikobehaftete) und Minor (geringfügiger, risikoarmer) Releases

Dauer von Major Deployments

Durchschnittliche Zeitspanne von der Freigabe eines Major Deployments bis zu dessen Abschluss

Anzahl zurückgerollter Anzahl der Releases, die während oder nach dem Rollout zurückgerollt werden mussten Releases Anteil automatisch ausgerollter Releases

Anteil der automatisch ausgerollten Releases an der Gesamtzahl von Releases

Für Service-Validierung und Test Kennzahl (KPI) Prozentsatz nicht bestandener ReleaseKomponenten in Eingangstests

Definition

Prozentsatz der Fälle, in denen Release-Komponenten den Eingangstest nicht bestehen

Anzahl der identifizier- Anzahl identifizierter Fehler im Rahmen des Releaseten Fehler Tests, pro Release Dauer bis zur Fehlerbeseitigung

Zeitdauer für die Beseitigung von Fehlern, die im Rahmen der Release-Tests festgestellt worden sind

Anzahl der durch neue Releases verursachten Incidents

Anzahl von Incidents, die mit dem Ausrollen eines neuen Releases in Verbindung stehen

Prozentsatz nicht bestandener ServiceAbnahmetests

Prozentsatz von Service-Abnahmetests, die die Abnahme durch den Kunden nicht bestehen

193

13 Prozess-Kennzahlen und Reporting Für Service Asset und Konfiguration Management Kennzahl (KPI)

Definition

ÜberprüfungsHäufigkeit

Häufigkeit, mit der die Inhalte der CMS physikalisch überprüft werden

Dauer der CMSPrüfungen

Zeitdauer für eine physikalische Überprüfung der CMSInhalte

Aufwand für CMSPrüfungen

Aufwand für eine physikalische Überprüfung der CMSInhalte

CMS-Abdeckung

Anteil der Konfigurationskomponenten (CIs), die in der CMS verzeichnet werden

Automatische CMSAktualisierung

Anteil der Konfigurationskomponenten (CIs), für die die Daten in der CMS automatisch aktualisiert werden

Anzahl CMS-Fehler

Anzahl von Fällen, in denen sich Einträge in der CMS als falsch herausstellen

Für Supplier Management Kennzahl (KPI)

Definition

Anzahl vereinbarter UCs

Prozentsatz von Verträgen, die durch UCs abgesichert sind

Anzahl von Vertragsnachprüfungen

Anzahl unterzeichneter Supplier- und Vertragsnachprüfungen

Anzahl identifizierter Vertragsverstöße

Anzahl von vertraglichen Verpflichtungen, die nicht durch die Supplier erfüllt worden sind (identifiziert im Rahmen von Vertragsnachprüfungen)

194

13.1 Definition und Wahl der Prozess-Kennzahlen Für Incident Management Kennzahl (KPI)

Definition

Anzahl doppelter Incidents

Anzahl wiederholt auftretender Incidents (mit bereits bekannten Lösungswegen)

Incident-Lösung durch Fernzugriff

Anzahl der Incidents, die vom Service Desk aus gelöst wurden (d.h. ohne Durchführung von Arbeiten vor Ort beim Anwender)

Anzahl Eskalationen

Anzahl von Eskalationen durch Incidents, die nicht in der vereinbarten Zeit gelöst werden konnten

Anzahl der Incidents

Anzahl der vom Service Desk bearbeiteten Incidents (aufgeschlüsselt nach Kategorien)

Incident-Lösungszeit

Mittlere Lösungszeit eines Incidents (aufgeschlüsselt nach Kategorien)

Erstlösungsrate

Prozentualer Anteil der Incidents, die vom Service Desk unmittelbar beim ersten Anruf gelöst werden können (aufgeschlüsselt nach Kategorien)

Lösung innerhalb SLA

Rate von Incidents, die innerhalb der in den SLAs vereinbarten Lösungszeiten gelöst werden

Lösungsaufwand Incident

Mittlerer Arbeitsaufwand für die Lösung eines Incidents (aufgeschlüsselt nach Kategorien)

195

13 Prozess-Kennzahlen und Reporting Für Problem Management Kennzahl (KPI)

Definition

Anzahl der Probleme

Anzahl der vom Problem Management bearbeiteten Probleme (aufgeschlüsselt nach Kategorien)

Problem-Lösungszeit

Mittlere Lösungszeit eines Problems (aufgeschlüsselt nach Kategorien)

Anzahl Incidents pro Problem

Mittlere Anzahl gleichartiger Incidents aufgrund desselben Problems, bevor das zugrunde liegende Problem identifiziert wird

Anzahl Incidents pro bekanntem Problem

Mittlere Anzahl gleichartiger Incidents aufgrund desselben Problems, nachdem das zugrunde liegende Problem identifiziert wurde

Zeit bis zur ProblemIdentifizierung

Mittlere Zeitspanne zwischen dem ersten Auftreten eines Incidents und der Identifizierung des zugrunde liegenden Problems

Lösungsaufwand Prob- Mittlerer Arbeitsaufwand für die Lösung eines Problems lem (aufgeschlüsselt nach Kategorien)

(Quelle = Wikipedia, http://wiki.de.itprocessmaps.com/index.php/ITIL-Kennzahlen)

13.1.2 BSC-Modell (Balanced Score Card) für IT-Prozesse Eine weitere Möglichkeit für die Definition von Kennzahlen für IT-Prozesse besteht in der Anwendung der „Balanced Scorecard“ (BSC)-Methode. Aus der Vision und Strategie werden in vier Themenbereichen so genannte „Karten“ (in English „Scorecard“) aufgesetzt, um dem Management ein Cockpit zu Verfügung zu stellen. Die BSC fokussiert nicht nur auf den Finanzbereich, sondern integriert auch die Kundensicht, die Prozessverbesserung und die organisatorische Weiterentwicklung.

196

13.1 Definition und Wahl der Prozess-Kennzahlen

Wo liegt der Mehrwert der Informatik?

Finanz • Kostennutzen erhöhen • Business-Effizienz unterstützen

Wie ist die ITOrganisation von den Kunden wahrgenommen? Kundennutzen • Erforderliche Qualität der IT-Services erbringen • Kundenzufriedenheit sicherstellen • Neue Services anbieten

Wo und wie bringen wir Spitzenleistungen? Interne Prozesse

Vision und Strategie Was ist unsere Vision?

• Optimierungspotentiale durch Prozessverbesserung verwirklichen

Lernende Organisation • Wissensmanagement fördern • Mitarbeiter motivieren und entwickeln

Was lernen wir, um unser Potential auszuschöpfen?

Bild 56: BSC-Modell für IT-Organisation

Basierend auf dem Balanced Scorecard Model können folgende Kennzahlen pro ITProzess definiert werden. Die entsprechenden Prüfpunkte, wo die Messungen stattfinden, werden auch beschrieben. Für P01 – IT-Strategie Kennzahlen Kundennutzen

Finanz

Interne Prozesse / Qualität Lernende Organisation

Metriken

Strategische Ausrich- Unterstützung und Beitrag zur Ertung füllung der strategischen Unternehmensziele Benchmark der IT- Wirtschaftlichkeit, zum Beispiel Kosten mit ähnlichen Kosten pro Arbeitsplatz; Industrie- oder Servi- Entwicklung der Betriebs- und Inceunternehmen vestitionskosten Einhaltung der Ziele BSC Reports Wissensmanagement

Verfügbarkeit vom kritischen Wissen

197

13 Prozess-Kennzahlen und Reporting Für P02 – HR Management Kennzahlen

Metriken

Kundennutzen

Service Verfügbarkeit

Finanz

Personalkosten

Stellvertretungsregelung; Erfahrung der Mitarbeiter und Altersstruktur der IT-Organisation Interne Leistungsverrechnung

Interne Prozesse / Qualität

Jahresziele für Mitar- Einhaltung der Personalvorgaben beiter definieren und bewerten

Lernende Organisation

Business und IT Wis- Weiterbildung; sen Ausbildung (Uni, FH, Lehre)

Für P03 – IT-Standards & Architektur Kennzahlen Kundennutzen

Finanz

Interne Prozesse / Qualität Lernende Organisation

Metriken

Vollständigkeit und IT-Flexibilitätsgrad Relevanz der Systemarchitektur TechnologieAnzahl Applikationen und VerminLebenszyklus derung der Systemvielfalt; Reduktion der Betriebskosten Standardisierungsgrad Einhaltung der IT-Standards; Anzahl unterschiedlicher Geräte für ähnliche Funktionalitäten Nutzung der Architektur

IT- Wirkungsgrad der IT-Standards und Architektur

Für P04 – Financial Management Kennzahlen Kundennutzen

Finanz

198

Rechnungen verbucht

Metriken

richtig Keine Rechnungen verbucht ohne Unterschrift des Kostenstellenverantwortlichen und des CIO Aufwände minimieren Aufwand für Budgetierung reduzieren

13.1 Definition und Wahl der Prozess-Kennzahlen Interne Prozesse / Qualität

Budgeteinhaltung

keine Budgetüberschreitung

Lernende Organisation

Reports liegen vor

Reporting bis zum 3. Arbeitstag vorliegend

Für P05 – Qualitätsmanagement Kennzahlen

Metriken

Interne Prozesse / Qualität

Messung der SL-Verletzungen; Projekt-Performanz Finanzieller Schaden Schadenschätzungen verursacht durch ITFehler Audit Kultur Anzahl Audits im Jahr; Häufigkeit des Audits pro Bereich

Lernende Organisation

Qualitätsmaßnahmen umsetzen

Kundennutzen Finanz

Null Fehler

Anzahl erfolgreicher Qualitätsmaßnahmen

Für P06 – IT-Projekt Portfolio Management Kennzahlen

Metriken

Kundennutzen

Kundenzufriedenheit

Kundenumfrage

Finanz

Investitionsbudget

Interne Prozesse / Qualität Lernende Organisation

Überwachung des jährlichen Investitionsbudgets Einhaltung der Pla- Planungseinhaltung des Portfolios nung (via Projekt KPI) Verbesserung der Siehe „Projekt KPIs” Projektmethode und Projekt Best Practices

199

13 Prozess-Kennzahlen und Reporting Für P07 – Capacity / Availability Management

Kundennutzen Finanz

Interne Prozesse / Qualität

Lernende Organisation

Kennzahlen

Metriken

Wissensverfügbarkeit; Service-Verfügbarkeit Personalbestand / Sachaufwandkosten; Einhaltung des Betriebsbudgets Ressourcen-Plan aufsetzen; System-Performanz

Stellvertretung; SLA-Messung Kosten; Betriebskosten

Plan-Genauigkeit;

Häufigkeit der Ausfälle und deren Auswirkungen Keine Ressourceneng- Ausgeglichene Arbeitsbelastung; pässe; Technologische Erfah- Einhaltung der IT-Standards rung

Für P08 – Continuity Management Kundennutzen

Kennzahlen

Metriken

Risikobewertung

Anzahl identifizierten Risiken

Finanz

Häufigkeit der prä- Kosten / Nutzen Analyse ventiven Übungen; Kosten der Maßnahmen Anzahl „unerwartete“ Fehler Interne Prozesse / Übungen Qualität im Pro Krisenfall Lernende Organisa- Reaktionszeit tion Krisenfall; VerminderungsGemäß Risikominderung maßnahmen Für P09 – Service Management Kennzahlen Kundennutzen

200

Metriken

Messbare und ver- Graphisches Reporting; ständliche SLAs; Kundenzufriedenheit Priorisierung der Services

13.1 Definition und Wahl der Prozess-Kennzahlen

Interne Prozesse / Qualität

Preisreduktion der Preisentwicklung Services pro Einheit Einhaltung der SLAs SLA Reporting; Anzahl SL-Verletzungen

Lernende Organisation

Bündelung Services

Finanz

der

IT Kostentransparenz

Für P10 – Anforderungsmanagement

Kundennutzen

Finanz

Interne Prozesse / Qualität Lernende Organisation

Kennzahlen

Metriken

Antwortzeit für eine erste Aufwandschätzung innerhalb von 5 Tagen Verhältnis Aufwand Account Manager (PT) und Anzahl Anforderungen Durchlaufzeit der Anforderungsabwicklung Wissen über die Business-Bedürfnisse

Gemäß Anforderung Ticket

Stundenerfassung

Gemäß Anforderung Ticketing System Qualität der Aufwandschätzung

Für P11 – Projektmanagement Kennzahlen

Metriken

Kundennutzen

Lieferung der defi- Kundenumfrage mit Fragebogen nierten Liefergüter

Finanz

Budgeteinhaltung

Ist Kosten / Projektbudget

Interne Prozesse / Qualität

Planungseinhaltung

Liefertermin

Lernende Organisation

Qualität der Projekt- Leistungsbericht über abgeschlosabwicklung sene Projekte

201

13 Prozess-Kennzahlen und Reporting Für P12 – Release Management Kennzahlen Kundennutzen

Finanz Interne Prozesse / Qualität Lernende Organisation

Metriken

Kundenzufriedenheit Kundenumfrage und Lieferung der Lieferobjekte Budgeteinhaltung Kosten der Releases Stabilität der Applika- Anzahl Incidents vor und nach tion / keine Service- einem Release Unterbrechung Einhaltung der Ter- Terminüberwachung mine beim Overall Release Plan

Für P13 – Applikationsentwicklung Kennzahlen

Metriken

Finanz

Erfüllung der Funk- Anzahl Tests und Wiederholung der Testdurchführung tionalität Entwicklungskosten Aufwanderfassung

Interne Prozesse / Qualität

Ratio (Fehler/LOC) < Anzahl Incidents 2.5 pro mille

Lernende Organisation

Qualität der Entwicklung; Wiederverwendung der Programme

Kundennutzen

Anzahl Nacharbeit; Entwicklungszeit / Wiederverwendbarkeit der geschriebenen Programme

Für P14 – IT-Betrieb & Konfiguration Kennzahlen

Metriken

Kundennutzen

Systemverfügbarkeit

SLA-Messung

Finanz

Betriebsbudget pro Einhaltung des Betriebsbudgets SLA Einplanung der Ände- System-Plan rungen

Interne Prozesse / Qualität Lernende Organisation

202

Keine Störung nach Anzahl Incident Tickets pro System Einführung einer Systemänderung

13.1 Definition und Wahl der Prozess-Kennzahlen Für P15 – Supplier Management Kennzahlen

Metriken

Kundennutzen

Lieferzeit

Anzahl Reklamationen wegen mangelnder Geräte oder wegen nicht verfügbarer externer Dienstleistungen

Finanz

Markt-Preise; Weniger Lagerkosten Bestellungen, entsprechend der definierten Standards Bewertung der Zulieferer

Benchmark-Analyse; Lagerinventar und Lagerwert Anzahl „Nicht-Standard“Bestellungen

Interne Prozesse / Qualität Lernende Organisation

Short List der Zulieferer

Für P16 – Incident Management Kennzahlen Kundennutzen

Finanz Interne Prozesse / Qualität

Lernende Organisation

Metriken

Erreichbarkeit des Anzahl angenommene Anrufe; Helpdesk; Anzahl Call Tickets versus Incident Lösungsquote der Call Tickets; Tickets; Resolution Time Tickets Prio1; Kundenvertrauen und Resolution Time Tickets Prio2; Zufriedenheit Kundenzufriedenheit Ticketpreis Verrechnung der Incident Tickets Gelungene Eskalation Ticket Aging; und Ticket Tracking; Anzahl wiedereröffnete Anzahl der wieder eröffneten Tickets Tickets Wissensdatenbank Anzahl Einträge und Nutzbarkeit

Für P17 – Problem Management

Kundennutzen

Kennzahlen

Metriken

Verletzung der SLAs

Welche Art von Problemen sind aufgetreten (Kategorie aus Ticket) Æ Gewichtung / Auswirkung; Offene Problemfälle; Anzahl geschlossene Probleme

203

13 Prozess-Kennzahlen und Reporting Finanz Interne Prozesse / Qualität

Lernende Organisation

IT-Kosten verursacht Kosten pro Problem durch Probleme Problem-Häufigkeit; Anzahl Tickets, welche ins Problem Lösungseffektivität Management eingeflossen sind; Anzahl dem Release Management zugeführte Problemfälle Wissensdatenbank Anzahl Einträge und Nutzbarkeit

Falls diese Vorgehensweise verwendet wird, werden dafür mindestens 4*17= 68 Indikatoren definiert und verwaltet.

13.1.3 IT-Performanz messen anhand IT und Business-Kennzahlen Eine andere Betrachtungsweise bezieht sich auf generische Kennzahlen, die die übergeordneten Ziele der Informatikorganisation anzeigen. Als Beispiel können folgende drei übergeordnete Kennzahlen definiert werden: – die Gesamtkosten der Informatik, – der Standardisierungs- und Harmonisierungsgrad – der Beitrag zu der Optimierung der Unternehmensprozesse Was die Gesamtkosten der Informatik betrifft, werden sicher einerseits Budgets gemäß Mittelfrist- und Kurzfristplanung berücksichtigt, aber auch mögliche Benchmarks der Branche. In dem Fall werden Ziele bezüglich der Informatikkosten im Voraus festgelegt, übereinstimmend mit vergleichenden Unternehmen. Zum Beispiel sollen die Informatikkosten nicht mehr als 2,3% des jährlichen Umsatzes (1,8% für IT-Betrieb und 0,5% für IT-Investitionen) überschreiten. Diese Vorgehensweise bietet sicher einige Vorteile: – Die erstellten Anforderungen sind in dem Fall keine Wünsche, sondern werden direkt vom Business bewertet. Damit wird auch sichergestellt, dass die genehmigten Investitionen von großer Bedeutung für das Gesamtunternehmen sind. – Der Vergleich mit einem Industriestandard ermöglicht die Wahrnehmung der Kosten von IT-Systemen und der Effizienz der durchgeführten Investitionen. Es mag sicher an der Stelle noch schwierig sein, quer über alle Business-Bereiche ein gemeinsames Verständnis vom Wert einer IT-Investition zu entwickeln. Interessanterweise liegen die meisten Potentiale weniger in einer lokalen Optimierung innerhalb eines Fachbereiches, als bei den übergreifenden Themen, wie etwa in Planungsprozess und Lagerbestandoptimierung.

204

13.2 Abläufe im Berichtswesen Als Standardisierungskriterien kann der Anteil von den als „nicht standard“ bekannten Applikationen durch die Gesamtzahl der im IT-Betrieb überwachten Applikationen sein. Diese Kennzahl setzt voraus, dass Standards in dem Applikationsumfeld aufgesetzt und gepflegt werden. Im Fall eines weltweit tätigen Unternehmens ist es klar, dass sich aufgrund eines landspezifischen Gesetzes eine 100% Standardisierung nicht umsetzen lässt. Als Voraussetzung zu der Kennzahl „Beitrag zu der Optimierung der Unternehmensprozesse“ müssen zuerst die Unternehmensprozesse bekannt sein und beschrieben werden. Es ist dann möglich, anhand der Zahl von Prozessen die Anzahl Optimierungen zu messen. Es hilft, wenn das Unternehmen ISO-zertifiziert ist. Damit ist ein Rahmen zur Verwaltung der Prozesse vorhanden. Der oben kurz skizzierte Weg ermöglicht sicher am meisten Synergien zwischen der IT-Organisation und den Fachbereichen. Wichtige Vorbedingungen müssen dafür erfüllt werden. Ein gemeinsames Verständnis für die übergeordneten Unternehmensziele und ein fundiertes Wissen der Abläufe stellen das Fundament für die Errichtung gemeinsamer Kennzahlen dar. So eine Vorgehensweise ist nur in einem Unternehmen möglich, wo eine offene Kommunikationskultur und ein gegenseitiges Vertrauen vorhanden sind.

13.2 Abläufe im Berichtswesen Berichte unterstützen auf allen Ebenen die strategische und operative Unternehmensführung: Vom Top-Management über die Leitung der Unternehmensbereiche bis hin zu den einzelnen operativen Einheiten. Sie unterstützen die Zusammenarbeit mit Kunden und Geschäftspartnern, indem sie die wirtschaftlichen Grundlagen der Beziehung transparent machen. Die Berichte werden meistens unter der Verantwortung des Berichtswesens erstellt. Unter dem Begriff betriebliches Berichtswesen (auch Reporting) versteht man die Einrichtungen, Mittel und Maßnahmen eines Unternehmens zur Erarbeitung, Weiterleitung, Verarbeitung und Speicherung von Informationen über den Betrieb und seine Umwelt in Form von Berichten.

13.2.1 Weitere Definitionen Berichte stellen eine definierte Sammlung von formatierten Daten dar. Diese können auch als Tabelle verstanden werden. Im Bereich „Daten“ wird der Unterschied zwischen „Stammdaten“, „Bewegungsdaten“ und „Bestandsdaten“ gemacht. Stammdaten zeichnen sich durch eine gewisse Statik aus (zeitlich invariant) und haben meistens keinen Zeitbezug. Sie werden oft von mehreren Anwendungen bzw. Unternehmensbereichen verwendet, zum Beispiel Teilstammsätze (Einkauf, Konstruktion, Vertrieb, Arbeitsvorbereitung) und sind bei analytischen Auswer-

205

13 Prozess-Kennzahlen und Reporting tungen oft die Kriterien, nach denen ausgewertet wird (Produkt, Filiale, Kunde, usw.). Diese werden meistens langfristig gehalten. Bewegungsdaten zeichnen sich durch eine gewisse Dynamik aus (zeitlich abweichend) und haben meistens einen Zeitbezug (Gültigkeitsdatum). Sie werden oft von wenigen Anwendungen genutzt und liefern oft die Fakten bei analytischen Auswertungen. Diese Daten werden meistens nur zeitlich begrenzt benötigt und daher kurz oder mittelfristig gehalten. Bestandsdaten zeichnen sich durch eine gewisse Dynamik aus (zeitlich abweichend) und liefern oft die Fakten bei analytischen Auswertungen. Sie werden meistens langfristig gehalten. Beispiele für Stammdaten sind die verkauften Artikel im Bereich Materialwirtschaft. Lagerzugangs- und Abgangsdaten stellen dafür Teilestammdaten und Bewegungsdaten dar. Als weiteres Beispiel sind bei einem Bibliothekssystem die Katalog- und Benutzerdaten (z. B. Name und Adresse) Stammdaten, während die Daten zu den entliehenen Büchern eines Benutzers und zur Meldung einer Rückgabe Bewegungsdaten sind. Die Datenquelle ist der Ursprungsort der Datensendestelle. Die Datenquelle ist normalerweise mit einer standardisierten Übertragungsschnittstelle ausgestattet. Bei Berichten wird der Unterschied zwischen statistischen Berichten, in denen die Daten nicht veränderbar sind, und dynamischen Berichten, in denen „Queries“ erstellt werden können, gemacht. Die Informationsdichte (oder Aggregation, Konsolidierung oder Verdichtung) bezeichnet, im Zusammenhang der Verwaltung großer Datenmengen in einem Data Warehouse, das Zusammenfassen einer Reihe von Fakten zu einem einzelnen Fakt. Beispielsweise lassen sich aus einer Menge von Zahlen der Mittelwert, das Minimum bzw. Maximum oder die Summe bestimmen. Das Ergebnis wird dann stellvertretend für die Quelldaten verwendet. Der umgekehrte Weg wird als Verfeinerung bezeichnet. Sie bilden einen Cube auf einen kleineren (Aggregation) oder größeren (Verfeinerung) Cube ab. Die Operationen finden entlang von Klassifikationspfaden statt und verändern somit die Klassifikationsstufen (auch: Konsolidierungsebenen) der einzelnen Dimensionen. Unter Häufigkeit verstehen wir im Berichtswesen das regelmäßige Intervall, indem ein Bericht zur Verfügung gestellt wird. Diese Intervalle können wie folgt sein: – – – –

206

wöchentlich, monatlich, quartalsmäßig, jährlich.

13.2 Abläufe im Berichtswesen

13.2.2 Ablauf im allgemeinen Berichtswesen Es ist möglich, den Aufbau eines Berichtes in vier Schritten zu beschreiben: 1) Erfassung / Erstellung der Daten Daten werden erst erzeugt. Es handelt sich an der Stelle um die Bewegungsdaten, die dann systematisch gesammelt werden. 2) Lieferung der Daten Die Daten werden gesammelt. Meistens findet in diesem Schritt eine erste Aggregation der Daten statt. 3) Formatierung & Verteilung der Daten Die gesammelten Daten werden in einer zwei-dimensionalen Tabelle geordnet und veröffentlicht. 4) Nutzung der Daten Die im Bericht veröffentlichen Daten werden genutzt. Diese können zum Beispiel zur Abrechnung von Dienstleistungen gelten oder als Beweis für die Einhaltung der Qualitätskriterien. Es ist auch möglich, den Ablauf auf Systemebene zu charakterisieren, von den Menschen bis zu den automatisierten Datenverarbeitungssystemen. In diese Dimension können die Rollen, die Kommunikationskanäle, die Natur der Daten und die involvierten IT-Systeme aufgenommen werden. Die folgende Abbildung bietet einen Rahmen, um die Berichtswesensaktivitäten zu beschreiben.

207

13 Prozess-Kennzahlen und Reporting

1 Erfassung, Erstellung

A

Wer? ¾ Rolle

B

Wie? ¾ Kommunikation

C

Was? ¾ Daten

D

Wo? ¾ IT-System

2 Lieferung

3 Formatierung, Verteilung

4 Nutzung

Datenhersteller

Datenlieferer

Daten Formatierer

Daten Empfänger

Schnittstellen

Daten extrahieren

Datentransfer, Formatierung

Daten publizieren

Datenspeicher Transaktionen

Datenformat

Reporting Daten

Abgefragten Daten

Datenquellen

„Cube“

Abfragen („Queries“)

Berichte (statisch oder dynamisch)

Bild 57: Berichtswesen Modellierung

Nachfolgend ein einfaches Beispiel. Mit diesem Beispiel, anhand der Aufwanderfassung, soll die praktische Umsetzung des Reportingmodells aufgezeigt werden. Die Aufwände werden zuerst von den Mitarbeitern in einem EDV-Tool eingetragen (wöchentlich auf Tagesbasis). Die erfassten Aufwände werden dann gesammelt und monatlich konsolidiert (zum Beispiel pro IT-Service und pro IT-Projekt). Danach werden zum Beispiel die entsprechenden Aufwände nach Fachbereich verteilt und verrechnet. Die Empfänger der Berichte können dann feststellen, ob die damit erfassten Aufwände und die resultierenden Kosten passend zu den budgetierten Aufwänden sind.

208

13.3 Reporting für IT-Organisation

A

Wer? ¾ Rolle

B

Wie? ¾ Kommunikation

C

Was? ¾ Daten

D

Wo? ¾ IT-System

1

2

3

4

Erfassung, Erstellung

Lieferung

Formatierung, Verteilung

Nutzung

Mitarbeitenden

IT Controlling

IT Controlling

IT Management

Erfassungstool

Zentrale Datenabfrage

Bericht Erstellung

Reports abrufbar auf Intranet

Stundenerfassung

Aufwände pro Monat

Kostenreport pro IT Services und pro Projekt

Kostenverteilung pro Abteilung

Datenbank Erfassungstool

Daten Konsolidierung

Ablage auf Controlling Folder

PDF Files

Bild 58: Beispiel Berichtswesen anhand Aufwanderfassung

Dieses Beispiel zeigt die Kette der Aktivitäten zwischen den Mitarbeitern, die ihre Aufwände erfassen, und dem Management, das die entsprechenden Kosten nach Fachbereich und IT-Dienstleistungen erhält. Der Schwierigkeitsgrad und die nötige Energie werden oft an der Stelle unterschätzt. Bis ein Bericht erstellt wird und in der Tat von Empfängern effektiv benutzt wird, dauert es in der Regel Wochen. Ein aufwendiges Reporting kann auch oft nicht sehr aussagekräftig sein.

13.3 Reporting für IT-Organisation Das Reporting innerhalb einer IT-Organisation muss unterschiedliche, zum Teil widersprüchliche Anforderungen erfüllen: – fokussiert auf die Zielgruppe: die Empfänger sollen mit den Informationen etwas anfangen, bzw. Entscheidungen treffen können, – die Genauigkeit muss gewährleistet werden, – der Aufwand zur Bereitstellung der Berichte muss gering bleiben.

209

13 Prozess-Kennzahlen und Reporting Das Berichtswesen gilt als Steuerungsinstrument und seine Gestaltung muss sorgfältig überlegt werden. Die Aggregationsebenen der Informationen, die Häufigkeit und die Art und Weise der Berichtverteilung sind Parameter, die die Effizienz des Berichtswesens stark beeinflussen. In dem folgenden Absatz wird ein Vorschlag für ein mögliches Reporting innerhalb einer IT-Organisation skizziert. Dieser Vorschlag bezieht sich auf das BSCModell, das ermöglicht, Vision und Ziele auf die verschiedenen Organisationseinheiten herunterzubrechen. Andererseits wird angenommen, dass die Aggregationsstufe der Information mit der Häufigkeit und dem Managementlevel korreliert. D.h. mit anderen Worten es werden vier Arten von Berichten definiert: 1) 2) 3) 4)

IT-Jahresbericht IT-Quartalsbericht IT-Monatsbericht IT-Eskalation / Information auf Tagesbasis

13.3.1 IT-Jahresbericht Der Jahresbericht wird unter der Verantwortung des CIO erstellt. Zielgruppe ist die Geschäftsleitung. Solange keine vertraulichen Informationen behandelt werden, kann der Jahresbericht jedem im Unternehmen zugänglich gemacht, zum Beispiel auf Intranet veröffentlicht werden. Die treffenden Prozesse beziehen sich primär auf die fünf der Funktionsgruppe „strategische Entscheidungsprozesse“. Tabelle 49: Prozesskennzahlen im IT-Jahresbericht

-> pro Jahr

Kennzahlen

Metriken

MIIP-Prozesse

Kundennutzen

Vollständigkeit und Relevanz der Systemarchitektur

IT-Flexibilitätsgrad

P03 – IT-Standards & Architektur

Null Fehler

Messung der SLVerletzungen; Projekt-Performanz IT Kosten im Vergleich zu

P05 - Qualitätsmanagement

Finanz

Benchmark der IT Kosten TechnologieLebenszyklus

210

Anzahl Applikationen und Verminderung der Systemvielfalt; Reduktion der Betriebskosten

P01 – IT-Strategie P03 – IT-Standards & Architektur

13.3 Reporting für IT-Organisation Interne Prozesse / Qualität

Lernende Organisation

Budgeteinhaltung

keine Budgetüberschreitung

P04 – Financial Management

Audit-Kultur

Anzahl Audits im Jahr; Häufigkeit des Audits pro Bereich Verfügbarkeit des kritischen KnowHow

P05 - Qualitätsmanagement

Know-How und Wissensmanagement

P01 – IT-Strategie

Internes Wissen

Kennzahlen über die Personalmerkmale der ITOrganisation (Weiterbildung, Ausbildung,…)

P02 – HR Management

Qualitätsmaßnahmen umsetzen

Anzahl erfolgreicher Qualitätsmaßnahmen

P05 - Qualitätsmanagement

Neun Hauptthemen werden in dem Jahresbericht gemäß dem beiliegenden Vorschlag behandelt. Trends sollen identifiziert werden und Zukunftsperspektiven skizziert. Die vier BSC-Bereiche sind in dem Beispiel quasi identisch behandelt (2 Kennzahlen in der Regel und 3 für „lernende Organisation“).

13.3.2 IT-Quartalsbericht Der Quartalsbericht richtet sich an die Kunden, d.h. Auftraggeber, STC-Mitglieder, Information Manager, Release Control Board. Die betroffenen IT-Prozesse sind in erster Linie die drei Prozesse der Funktionsgruppe „Planung & Controlling“. Der Bericht wird unter der Verantwortung des Berichtswesens veröffentlicht. Der Quartalsbericht bietet eine konsolidierte Sicht über die IT-Aktivitäten an. Die Qualität ist als Schwerpunkt vorgesehen.

211

13 Prozess-Kennzahlen und Reporting Tabelle 50: Prozesskennzahlen im IT-Quartalsbericht

-> pro Quartal

Kennzahlen

Metriken

MIIP-Prozesse

Kundennutzen

Kundenzufriedenheit (Services)

Kundenumfrage pro IT-Services

P09 – Service Management

Kundenzufriedenheit (Projekt)

Zufriedenheit gemessen nach Projektabschluss

P06 – IT-Projekt Portfolio Management

Finanz

Kostenentwicklung (Investitionen & Betrieb)

Ist-Kosten, Forecast im Vergleich zum Budget

P04 – Financial Management

Interne Prozesse / Qualität

Einhaltung der Planung (via Projekt-KPI)

Planungseinhaltung des Portfolios

P06 – IT-Projekt Portfolio Management

Übungen

Anzahl „unerwartete“ Fehler

P08 - Continuity Management

Ressource-Plan aufsetzen; System-Performanz

Plan-Genauigkeit; Häufigkeit der Ausfälle und deren Auswirkungen gemäß Projekt KPI

P07 – Capacity / Availability Management

Pro Krisenfall; Gemäß Risikominderung

P08 - Continuity Management

Lernende Organisation

Verbesserung der Projektmethode und Projekt Best Practices Reaktionszeit im Krisenfall; Verminderungsmaßnahmen

P11 – Projektmanagement

Der Bericht kann gezielt pro Fachbereich erstellt werden. Dennoch ist hier die Empfehlung, einen einzigen Bericht zu veröffentlichen. Damit gewinnt der Leser den Überblick über alle IT-Aktivitäten.

212

13.3 Reporting für IT-Organisation

13.3.3 IT-Monatsbericht Der Monatsbericht ist ein Kommunikationsinstrument, in dem ein Status über die IT-Dienstleistungen abgegeben wird. Zielgruppen sind sicher die Kunden der ITOrganisation, aber auch Key-Users. Tabelle 51: Prozesskennzahlen im IT-Monatsbericht

-> pro Monat

Kennzahlen

Metriken

MIIP-Prozesse

Kundennutzen

Antwortzeit für eine erste Aufwandschätzung innerhalb von 5 Tagen

Gemäß Anforderung Ticket

P10 – Anforderungsmanagement

Lieferung definierten fergüter

Kunden-Umfrage mit Fragebogen / Statusbericht

P11 – Projektmanagement

Systemverfügbarkeit

SLA-Messung

P14 – IT-Betrieb & Konfiguration

Erreichbarkeit des Helpdesks; Lösungsquote der Call Tickets; Kundenvertrauen und Zufriedenheit

Anzahl angenommene Anrufe; Anzahl Call Tickets versus Incident Tickets; Resolution Time Tickets Prio1; Resolution Time Tickets Prio2; Kundenzufriedenheit -

P16 – Incident Management

SLA Reporting; Anzahl SLVerletzungen

P09 – Service Management

Anzahl Incidents vor und nach einem Release

P12 – Release Management

Finanz

-

Interne Prozesse / Qualität

Einhaltung SLAs

der Lie-

der

Stabilität der Applikation / keine ServiceUnterbrechung

-

213

13 Prozess-Kennzahlen und Reporting Gelungene Eskalation und Ticket Tracking;

Ticket Aging; Anzahl der wieder eröffneten Tickets

P16 – Incident Management

Anzahl Einträge und Nutzbarkeit

P16 – Incident Management

Anzahl wiedereröffnete Tickets Lernende Organisation

Wissensdatenbank

P17 – Problem Management Im Monatsbericht werden Themen, die für den Kundennutzen wichtig sind (Status eines Projekts, Verfügbarkeit eines IT-Service), rapportiert. Es ist empfehlenswert, eine Sicht pro Fachbereich als Strukturelement zu definieren.

13.3.4 IT-Eskalation / Information (täglich) Wie in der Prozessbeschreibung für P09 – Service Management festgehalten, sollen wichtige Systemfehler sofort korrigiert und gegebenenfalls bis zum CEO eskaliert werden. Es ist auch wichtig, die IT-Anwender über Systemunterbrechungen zu informieren. Email ist ein Medium, das besonders dafür geeignet ist. Ein Intranet Dashboard ist auch sehr effizient, um über Störungen Nachrichten zu verbreiten. Es ist dennoch notwendig, sich weitere Informationskanäle zu überlegen. Und zwar wenn gerade das Netzwerk nicht verfügbar ist, hilft eine Email-Nachricht oder eine Information auf Intranet nicht viel. Verschiedene Informationswege können dann in Anspruch genommen werden. Als Beispiel können Aussagen zum Beispiel via Alarmanlage in den verschiedenen Gebäuden durchgespielt werden. Oder SMS verteilen. Plakate können auch verwendet werden.

214

14 Evaluation des Reifegrads (COBIT) Um die Implementierung der Prozesse sicherzustellen, ist es empfehlenswert, eine Evaluation deren Umsetzung durchzuführen. Damit wird die Basis geschaffen, um diese kontinuierlich zu verbessern und die größten Lücken in der IT-Organisation zu adressieren. Es besteht auch die Möglichkeit einer Zertifizierung. Damit können die Qualität der organisatorischen Regelungen und deren Wirksamkeit gegenüber dem Management oder den Kunden nachgewiesen werden. Dies wirkt vertrauensbildend, reduziert aber auch den Aufwand für sonstige individuelle Überprüfungen.

14.1 COBIT Framework CobiT (Control Objectives for Information and Related Technology) ist ein Modell zur Überwachung und Steuerung der gesamten IT-Umgebung. Cobit stellt der IT Governance einen Rahmen mit gängigen, generell akzeptierten Prüfpunkten zur Verfügung. Damit soll sichergestellt werden, dass die eingesetzte Informationstechnologie die Geschäftsziele abdeckt, dass die Ressourcen verantwortungsvoll eingesetzt werden und, dass die Risiken angemessen überwacht werden. CobiT wurde ursprünglich von der Organisation ISACF (Information Systems Audit and Control Foundation) entwickelt, dem Forschungsinstitut der ISACA (Information Systems Audit and Control Association). 1999 wurden die Aufgaben von ISACF für CobiT auf das IT Governance Institut (ITGI) übertragen, welches ein unabhängiges Organ ist. Die Entwicklung von CobiT wurde 1994 begonnen und wird kontinuierlich weitergeführt. Mit insgesamt 34 IT-Prozessen legt CobiT ein Rahmenwerk für jeden der ITProzesse fest, welche Kernaufgaben definiert sein sollen. Die Prozessdomänen bilden einen Managementkreislauf. Die vier CobiT-Domänen sind: – – – –

“Plan and Organise” (PO): planen und organisieren „Acquire and Implement“ (AI): beschaffen und einführen „Deliver and Support“ (DS): bereitstellen und betreiben „Monitore and evaluate“ (ME): überwachen und bewerten

In den folgenden Tabellen werden die Hauptthemen des CobiT-Modells in Beziehung zu den MIIP-Prozessen aufgelistet.

215

14 Evaluation des Reifegrads (COBIT)

14.1.1 PO: planen und organisieren Die Rubrik PO „planen und organisieren“ beinhaltet 11 Punkte. Bei jedem Punkt wird die Beziehung zu den MIIP-Prozessen herstellt. Die Themen, die bei diesen Punkten geprüft werden, sind im Anhang F aufgelistet. Tabelle 52: „PO“ CobiT und MIIP-Prozesse

Punkt / Themen PO1: Definition eines strategischen Informationstechnologie-Plans PO2: Definition der Informationsarchitektur PO3: Bestimmung der technologischen Richtung PO4: Definition der IT-Organisation und ihrer Beziehungen PO5: Verwaltung der IT-Investitionen

PO6: Kommunikation von Führungszielen und -richtung PO7: Personalwesen PO8: Sicherstellung der Einhaltung von externen Anforderungen PO9: Risikobeurteilung

PO10: Projektmanagement

PO11: Qualitätsmanagement

216

MIIP-Prozess(e) – –

P01 - IT-Strategie P04 - Financial Management

–

P03 - IT-Standards & Architektur

–

P03 - IT-Standards & Architektur

–

P01 - IT-Strategie

– – – – –

P04 - Financial Management P06 - IT-Projekt Portfolio Management P09 - Service Management P01 - IT-Strategie P08 - Continuity Management

–

P02 - HR Management

–

P10 - Anforderungsmanagement

–

P06 - IT-Projekt Portfolio Management P08 - Continuity Management P06 - IT-Projekt Portfolio Management P11 - Projektmanagement P05 - Qualitätsmanagement P13 - Applikationsentwicklung

– – – – –

14.1 COBIT Framework

14.1.2 AI: beschaffen und einführen Der Teil AI „beschaffen und einführen“ beinhaltet 6 Punkte mit insgesamt 68 Prüfpunkten. In der folgenden Tabelle ist die Beziehung zu den MIIP-Prozessen ersichtlich. Tabelle 53: „AI“ CobiT und MIIP-Prozesse

Punkt / Themen

MIIP-Prozess(e)

AI1: Identifikation von automatisierten Lösungen

– – –

AI2: Beschaffung und Unterhalt von Software AI3: Beschaffung und Unterhalt der technischen Infrastruktur AI4: Entwicklung und Unterhalt von Verfahren AI5: Installation und Akkreditierung von Systemen

AI6: Änderungswesen

– – – – – – – – –

P01 - IT-Strategie P03 - IT-Standards & Architektur P06 - IT-Projekt Portfolio Management P15 - Supplier Management P10 - Anforderungsmanagement P11 - IT-Projektmanagement P12 - Release Management P11 - IT-Projektmanagement P14 - IT-Betrieb & Konfiguration P15 - Supplier Management P11 - IT-Projektmanagement P14 - IT-Betrieb & Konfiguration

– – – – – – – –

P08 - Continuity Management P11 - IT-Projektmanagement P12 - Release Management P14 - IT-Betrieb & Konfiguration P08 - Continuity Management P11 - IT Projektmanagement P12 - Release Management P14 - IT-Betrieb & Konfiguration

14.1.3 DS: ausliefern und unterstützen Bei dem Teil DS „Auslieferung und Unterstützung“ sind 13 Punkte berücksichtigt. In der Tabelle werden die entsprechenden MIIP-Prozesse erwähnt, die den CobiTPunkten entsprechen.

217

14 Evaluation des Reifegrads (COBIT)

Tabelle 54: „DS“ CobiT und MIIP-Prozesse

Punkt / Themen DS1: Definition und Management von Dienstleistungsgraden DS2: Handhabung der Dienste von Drittparteien

DS3: Leistungs- und Kapazitätsmanagement DS4: Sicherstellen der kontinuierlichen Dienstleistung DS5: Sicherstellen der Systemsicherheit

DS6: Identifizierung und Zuordnung von Kosten DS7: Aus- und Weiterbildung von Benutzern DS8: Unterstützung und Beratung von Kunden DS9: Konfigurationsmanagement DS10: Umgang mit Problemen und Zwischenfällen DS11: Verwaltung von Daten

DS12: Verwaltung von Einrichtungen DS13: Management der Produktion

218

MIIP-Prozess(e) – –

P04 - Financial Management P09 - Service Management

– – – – –

P01 - IT-Strategie P03 - IT-Standards & Architektur P08 - Continuity Management P15 - Supplier Management P07 - Capacity / Availability Management

–

P08 - Continuity Management

– – – –

P03 - IT-Standards & Architektur P08 - Continuity Management P14 - IT-Betrieb & Konfiguration P04 - Financial Management

–

P11 - IT-Projektmanagement

– –

P10 - Anforderungsmanagement P16 - Incident Management

–

P14 - IT-Betrieb & Konfiguration

–

P17 - Problem Management

– – – –

P09 - Service Management P10 - Anforderungsmanagement P14 - IT-Betrieb & Konfiguration Physische Sicherheit

–

P14 - IT-Betrieb & Konfiguration

14.1 COBIT Framework

14.1.4 M: überwachen Im Bereich M „Überwachung“ sind 4 Themen gelistet, mit insgesamt 24 Prüfpunkten (siehe Anhang F). Die Tabelle zeigt die Beziehung zwischen diesen Prüfpunkten und den MIIP-Prozessen. Tabelle 55: „M“ CobiT und MIIP-Prozesse

Punkt / Themen

MIIP-Prozess(e)

M1: Überwachung der Prozesse M2: Beurteilung der Angemessenheit der internen Kontrollen M3: Erlangen einer unabhängigen Bestätigung M4: Für eine unabhängige Revision sorgen

–

P05 - Qualitätsmanagement

–

P05 - Qualitätsmanagement

–

P05 - Qualitätsmanagement

–

P05 - Qualitätsmanagement

14.1.5 CobiT-Kernprüfpunkte Mit insgesamt 318 Prüfpunkten stellt CobiT eine sehr ausführliche Methode dar, um das Funktionieren einer IT-Organisation zu prüfen. Es ist auch möglich, nur ausgewählte Punkte zu prüfen. Damit kann eine effektive Prüfung stattfinden, ohne den Überblick durch viele Details zu verlieren. Tabelle 56: CobiT „light“ und MIIP-Prozesse

Nr.

Prüfgebiet

MIIP Prozesse

1. PLANUNG UND ORGANISATION (PO) PO 1

IT-Strategie und ITPlanung

– –

P01 - IT-Strategie P04 - Financial Management

P02

Informationsarchitektur

–

P03 - IT-Standards & Architektur

PO 4

IT-Organisation

–

P01 - IT-Strategie

PO 6

Weisungen, Konzepte

– –

P01 - IT-Strategie P08 - Continuity Management

PO7

Personalwesen

–

P02 - HR Management

PO 8

Externe Anforderungen

–

P10 - Anforderungsmanagement

PO 10

Projektmanagement

–

P06 - IT-Projekt Portfolio Manage-

Richtlinien,

219

14 Evaluation des Reifegrads (COBIT) ment – P11 - IT-Projektmanagement PO11 Qualitätsmanagement – P05 - Qualitätsmanagement – P13 - Applikationsentwicklung 2. BESCHAFFUNG UND EINFÜHRUNG (AI) AI 5

Installation neuer Systeme

DS 2

Drittparteien

DS3

Leistungs- und tätsmanagement

DS 4

– P08 - Continuity Management – P11 - IT-Projektmanagement – P12 - Release Management – P16 - IT-Betrieb & Konfiguration AI 6 Änderungswesen – P08 - Continuity Management – P11 - IT-Projektmanagement – P12 - Release Management – P16 - IT-Betrieb & Konfiguration 3. AUSLIEFERUNG UND UNTERSTÜTZUNG (DS) – – – – –

P01 - IT-Strategie P03 - IT-Standards & Architektur P08 - Continuity Management P15 - Supplier Management P07 - Capacity / Availability Management

Ununterbrochener Betrieb

–

P08 - Continuity Management

DS 5

IT-Sicherheit

DS 9

Konfigurationsmanagement

– – – –

P03 - IT-Standards & Architektur P08 - Continuity Management P14 - IT-Betrieb & Konfiguration P14 - IT-Betrieb & Konfiguration

DS 10

Problem Management

–

P17 - Problem Management

DS 11

Datenintegrität, Backup und Archivierung

DS 13

IT Operations

– – – –

P09 - Service Management P10 - Anforderungsmanagement P14 - IT-Betrieb & Konfiguration P14 - IT-Betrieb & Konfiguration

–

P05 - Qualitätsmanagement

Kapazi-

4. ÜBERWACHUNG (M) M2

Interne Kontrollen

Mit den 212 ausgewählten Prüfpunkten ist es möglich, innerhalb kürzsteter Zeit ein erstes Bild der IT-Organisation zu gewinnen.

220

14.2 Maturity Model

14.2 Maturity Model Mit dem Capability Maturity Model (CMM) wird auf ein Modell hingewiesen, das für die Bewertung der Prozessreife eingesetzt wird. Durch standardisierte Reifegrade, die auf alle Prozesse gleichermaßen angewendet werden können, wird der Fortschritt der Prozessentwicklung messbar. Dieses Instrument wird deshalb vom Qualitäts- und Prozessmanagement angewendet. 1986 begann das Software Engineering Institute (SEI) der Carnegie Mellon University mit der Entwicklung eines Bewertungsmodells für die Reife von Softwareentwicklungsprozessen. Initiator dieses Vorhabens war das US-Verteidigungsministerium. 1991 wurde das Capability Maturity Model in seiner ersten Version veröffentlicht. Kurz vor Veröffentlichung der Hauptversion 2.0 wurde diese abgebrochen und ein Folgeprojekt unter dem Titel CMMI gestartet, dessen Ergebnisse 2000 als Pilot veröffentlicht wurden. 2002 wurde CMMI unter dem Namen Capability Maturity Model Integration ® freigegeben. CMMI® definiert Anforderungen an integrierte Prozesse zur Produktentwicklung. Das SPICE-Projekt hat auf Basis CMMI® 1998 einen Technischen Report veröffentlicht, der ein Modell zur Ermittlung der Prozessreife empfiehlt und dafür die im ISO 12207 definierten Software-Lebenszyklusprozesse zugrunde legt. Dieser Technische Report wurde in den ISO-Standard 15504 überführt, der Anforderungen an die Konzeption und Durchführung von Prozess-Bewertungen regelt. Die Vorteile des Modells sind die Vergleichbarkeit der Prozesse, um die richtigen Prioritäten in der Prozessentwicklung setzen zu können. Mittelfristige Ziele für eine gezielte Prozessweiterentwicklung können dann identifiziert und priorisiert werden. Das Capability Maturity Model beinhaltet 6 Abstufungen der Prozessqualität: Nicht existent, Initiiert, Teilweise definiert, Definiert, Kontrolliert und Optimiert. Level 0: Nicht existent Erkennbare Prozesse fehlen vollständig. Die Organisation hat nicht einmal erkannt, dass Maßnahmen erforderlich sind. Level 1: Initiiert Die Organisation hat nachweislich erkannt, dass Maßnahmen getroffen werden müssen. Standardisierte Prozesse fehlen jedoch und an deren Stelle treten ad hoc-

221

14 Evaluation des Reifegrads (COBIT) Maßnahmen, welche vorwiegend von Fall zu Fall durchgeführt werden. Die damit verbundenen Managementprozesse erfolgen nicht organisiert. Level 2: Teilweise definiert Die Prozesse sind soweit entwickelt, dass sie von unterschiedlichen Personen für gleiche Aufgaben in ähnlicher Art und Weise angewendet werden. Es existiert keine formelle Schulung oder Kommunikation eines standardisierten Vorgehens. Die Verantwortung ist Einzelnen überlassen. Das Wissen ist auf einzelne Personen abgestützt, was auf die Eintretenswahrscheinlichkeit von Fehlern ungünstig wirkt. Level 3: Definiert Prozesse sind standardisiert und dokumentiert und mittels Schulung kommuniziert. Es ist jedoch den einzelnen Personen überlassen, diesen Vorgaben nachzukommen. Abweichungen werden nur mit kleiner Wahrscheinlichkeit entdeckt. Die Prozesse selber sind wenig entwickelt und formalisieren einfach die bestehende Praxis. Level 4: Kontrolliert Das Einhalten von Prozessvorgaben kann gemessen und gesteuert werden. Korrekturmaßnahmen werden durchgeführt, falls Prozesse nicht effizient funktionieren. Die Prozesse werden laufend verbessert und entsprechen guter Praxis. Automatisierung und Einsatz von Werkzeugen erfolgen nur begrenzt oder ansatzweise. Level 5: Optimiert Prozesse sind soweit verbessert, dass sie bester Praxis entsprechen, basierend auf ständiger Verbesserung und im Abgleich mit anderen Organisationen. IT wird in einer integrierten Art und Weise eingesetzt, mit dem Ziel, Arbeitsabläufe zu automatisieren (Workflow), Werkzeuge zur Verbesserung von Qualität und Effizienz einzusetzen und das schnelle Anpassen der Organisation an neue Anforderungen zu ermöglichen.

222

14.3 Bewertung des Reifegrades der IT Prozesse

Optimiert Kontrolliert

Initiert (Level 1) Der Prozess wurde identifiziert, ist aber nicht klar definiert. Ad hocMaßnahmen werden getroffen. Die Lage wirkt „chaotisch“.

Teilweise definiert (Level 2)

Der Prozess wurde identifiziert, ist aber teilweise definiert. Die prozessbezogenen Aktivitäten finden unkoordiniert statt. Keine Messung oder VerbesserungsMaßnahmen sind umgesetzt. Das Wissen ist auf einzelne Personen konzentriert.

Definiert (Level 3)

Der Prozess ist definiert und dokumentiert. Ein Prozessmanagement mittels statistischen Berichten wird durchgeführt. Das Prozesswissen ist auf mehrere Organisationseinheiten verteilt.

(Level 5)

(Level 4)

Der Prozess ist definiert und dokumentiert. Der Prozess ist in der Organisation verankert und wird professionell gemanaged. Prozessabhängigkeiten werden berücksichtigt. Automatisierung zum Teil vorhanden.

Der Prozess ist definiert und dokumentiert. Der Prozess ist „institutionalisiert“ und wird ständig verbessert. Proactive Maßnahmen werden ergriffen. Die Beziehung zu den strategischen Zielen ist klar vorhanden.

Bild 59: Stufe des Prozessreifegrades

14.3 Bewertung des Reifegrades der IT Prozesse Anhand des Maturity Models ist es möglich, die Prozesse nach definierten Stufen zu bewerten. Die Frage stellt sich, nach welchem Raster die Einstufung nach Level stattfinden kann. Um diese Frage beantworten zu können, werden Kriterien definiert, die es ermöglichen, eine Differenzierung in der Prozessreife zu erreichen. Das folgende Modell beinhaltet 35 Kriterien, die in 8 Themen gruppiert sind. Diese sind: – – – – – – – – –

Prozessdefinition, Verantwortlichkeit, Verbreitung, Methoden, Tooling, Q-Sicherung, Verfügbare Berichte, Wissensmanagement, Nutzen.

223

14 Evaluation des Reifegrads (COBIT) Folgenden Kriterien werden zu diesen Themen verwendet: Prozessdefinition

– – – –

Name vorhanden Prozessbeschreibung Prozessschnittstelle definiert Intranet veröffentlicht

Verantwortlichkeit

– – – –

Prozess-Owner definiert Aufgaben definiert Aufgaben wahrgenommen Die Prozessrollen wurden geschult

– – – –

Prozesswissen ist verteilt ein einziger Wissensträger mehrere Wissensträger abteilungsübergreifendes Wissen

Methoden

– – – –

Anweisungen verfügbar regelmäßige Schulungen werden durchgeführt Best Practices / Lernen aus Erfahrung Benchmark wird durchgeführt

Tooling

– – – –

Vorlagen verfügbar EDV-Unterstützung Handbücher verfügbar und gepflegt EDV-Integration (Schnittstellen zu anderen ITSystemen)

Q-Sicherung

– – – – –

Q-Standards definiert Prozessziele definiert KPI werden gemessen Verbesserungsmaßnahmen – reaktiv Verbesserungsmaßnahmen – proaktiv

Verfügbare Berichte

– – – – –

Kostenberichte (Ist Kosten) BSC durchgeführt SWOT jährlich Forecast verfügbar Nachweisbare Wirtschaftlichkeit

Wissensmanagement

– –

Wissensmanagement-Tool verfügbar Wissensmanagement-Tool effektiv benutzt

Nutzen

– – –

Akzeptanz im Fachbereich Unterstützung der Fachbereiche klare strategische Bedeutung

Verbreitung

224

14.3 Bewertung des Reifegrades der IT Prozesse Mit zunehmender Maturity-Stufe werden mehr Kriterien erfüllt werden müssen. Level 1: 1 Kriterium [Name vorhanden] Level 2: 6 Kriterien [Kriterium Level 1] + [Prozessbeschreibung, Prozess-Owner, Aufgaben definiert, 1 Wissensträger, Q-Standards definiert] Level 3: 15 Kriterien [Kriterien Level 2] + [Prozessschnittstelle definiert, Intranet veröffentlicht, Aufgaben wahrgenommen, Prozessrollen geschult, Anweisungen, Vorlagen, EDVUnterstützung, Prozessziele definiert, Kostenberichte] Level 4: 27 Kriterien [Kriterien Level 3] + [Wissen verteilt, mehrere Wissensträger, regelmäßige Schulungen, Best Practices / Lernen aus Erfahrung, Handbücher, KPI gemessen, Verbesserungsmaßnahmen -reaktiv, BSC durchgeführt, SWOT jährlich, Forecast verfügbar, Wissensmanagement-Tool verfügbar, Akzeptanz im Fachbereich] Level 5: 35 Kriterien [Kriterien Level 4] + [Abteilungsübergreifend, Benchmark, EDV-Integration, Verbesserungsmaßnahmen – proaktiv, Nachweisbare Wirtschaftlichkeit, Wissensmanagement-Tool effektiv benutzt, Unterstützung der Fachbereiche, klare strategische Bedeutung] Dank der Sortierung der Kriterien nach Reifestufe ist es möglich, eine ProzessreifeMatrix zu entwickeln, um die IT-Prozesse bewerten zu können:

225

14 Evaluation des Reifegrads (COBIT)

Tabelle 57: MIIP-Prozessreife-Modell

Themen

Kriterien

ProzessDefinition

Name schaft

auf

Prozessland-

Prozessbeschreibung Prozessschnittstelle niert

Level 1

Level 2

Level 3

Level 4

Level 5

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

defi-

Intranet veröffentlicht Verantwortung

Prozess-Owner

1

1

1

1

Aufgaben definiert

1

1

1

1

Aufgaben wahrgenommen

1

1

1

Prozessrollen wurden geschult

1

1

1

1

1

1

1

1

1

Prozesswissen verteilt Verbreitung

1 einziger Wissensträger

1

1

mehrere Wissensträger abteilungsübergreifendes Wissen

Methoden

1

Anweisungen verfügbar

1

1

1

Regelmäßige Schulungen

1

1

Best Practices / Lernen aus Erfahrung

1

1

Benchmark Tooling

1

Vorlagen verfügbar

1

1

1

EDV-Unterstützung

1

1

1

1

1

Handbücher verfügbar und gepflegt EDV-Integration QSicherung

Q-Standards definiert Prozessziele definiert KPI gemessen

226

1 1

1

1

1

1

1

1

1

1

14.3 Bewertung des Reifegrades der IT Prozesse Verbesserungsmaßnahmen reaktiv

1

Verbesserungsmaßnahmen proaktiv Reports verfügbar

1

Kostenberichte (Ist-Kosten)

1

1

BSC durchgeführt

1

1

SWOT jährlich

1

1

Forecast verfügbar

1

1

Nachweisbare lichkeit Wissen

1

Wirtschaft-

1

Wissensmanagement-Tool verfügbar

1

Wissensmanagement-Tool effektiv benutzt Nutzen

1

1 1

Akzeptanz im Fachbereich

1

1

Unterstützung der Fachbereiche

1

klare strategische Bedeutung

1

Total "Punkte"

1/1

6/6

15/15

27/27

35/35

Es ist an der Stelle wichtig, die SOLL-Reifestufe eines Prozesses zu definieren. Nicht alle Prozesse müssen bis zum Level 5 entwickelt werden. Anbei ein Beispiel, bei welchem für den Prozess A eine Reifestufe 4 erreicht werden soll. Ein Prozessaudit wurde anhand der definierten Kriterien durchgeführt. In der folgenden Tabelle sind die Ergebnisse aufgeführt: Tabelle 58: Ergebnisse eines Prozessaudits als Beispiel

Themen

Kriterien

ProzessDefinition

Name vorhanden Prozessbeschreibung Prozessschnittstelle niert Intranet veröffentlicht

defi-

Level 1

Level 2

Level 3

Level 4

Level 5

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

227

14 Evaluation des Reifegrads (COBIT) Verantwortung

Prozess-Owner

1

1

1

1

Aufgaben definiert

1

1

1

1

Aufgaben wahrgenommen

1

1

1

Prozessrollen wurden geschult

1

1

1

1

1

1

1

1

1

Prozesswissen verteilt Verbreitung

1 einziger Wissensträger

1

1

mehrere Wissensträger abteilungsübergreifendes Wissen

Methoden

1

Anweisungen verfügbar

1

1

1

Regelmäßige Schulungen

1

1

Best Practices / Lernen aus Erfahrung

1

1

Benchmark Tooling

X

Vorlagen verfügbar

1

1

1

EDV-Unterstützung

1

1

1

1

1

Handbücher verfügbar und gepflegt EDV-Integration QSicherung

X

Q-Standards definiert

1

1

1

1

1

1

KPI gemessen

1

1

Verbesserungsmaßnahmen reaktiv

1

1

Prozessziele definiert

1

Verbesserungsmaßnahmen proaktiv Reports verfügbar

Kostenberichte (Ist-Kosten)

1

1

BSC durchgeführt

1

1

SWOT jährlich

X

-

Forecast verfügbar

X

-

Nachweisbare lichkeit

228

X

Wirtschaft-

1

X

14.3 Bewertung des Reifegrades der IT Prozesse Wissen

Wissensmanagement-Tool verfügbar

X

Wissensmanagement-Tool effektiv benutzt Nutzen

X

Akzeptanz im Fachbereich

1

1

Unterstützung der Fachbereiche

1

klare strategische Bedeutung

1

Total "Punkte"

1/1

6/6

15/15

24/27

27/35

Aus den Ergebnissen ist ersichtlich, dass der Prozess etabliert ist. Der Level 4 ist „fast“ erreicht und bleibt sicher anstrebenswert. Dafür sollen folgende Punkte adressiert werden: – BSC Reporting wird veröffentlicht, – eine SWOT-Analyse auf Prozessebene findet einmal im Jahr statt, – ein Wissensmanagement-Tool soll abteilungsübergreifend benutzt werden, um das Prozesswissen innerhalb der Organisation zu verbreiten. Um die Soll-Reife der IT-Prozesse zu definieren, ist es hilfreich, die Kritikalität der Prozesse zu kennen. Es ist möglich, die Kritikalität eines IT-Prozesses anhand 7 Kriterien zu definieren: – – – – – – –

Integrität: ist die Datenintegrität gewährleistet? Vertraulichkeit: können Daten manipuliert werden? Einfluss von Dritten? Verfügbarkeit: zeitliche Risiken? Notfallplanung? Effektivität: Kosten / Nutzen? Effizienz: Ressourcen Verfügbarkeit? Compliance: Wichtigkeit und Einhaltung der Standards und Normen? Verlässlichkeit: wie groß ist das Ausfallrisiko? Wie komplex?

Hiermit lässt sich eine Kritikalitätskarte der IT-Prozesse skizzieren.

229

14 Evaluation des Reifegrads (COBIT)

Vertraulichkeit

Verfügbarkeit

Effektivität

Effizienz

Compliance

Verlässlichkeit

Summe

P01 - IT-Strategie

0

3

0

2

3

1

0

9

mittel

P02 - HR Mgt

0

0

1

2

1

1

1

6

tief

P03 - IT-Standards & Architektur

1

2

1

1

2

3

3

13

mittel

P04 - Financial Mgt

0

1

0

2

0

2

0

5

tief

P05 – Qualitätsmgt

2

1

0

1

1

2

0

7

tief

P06 - Portfolio Mgt

1

1

2

3

2

2

1

12

mittel

P07 - Availability Capacity Mgt

2

1

3

3

2

1

0

12

mittel

P08 - Continuity Mgt

3

2

3

2

1

2

2

15

hoch

P09 - Service Mgt

1

0

1

3

2

1

1

9

mittel

P10 - Anforderungsmgt

1

0

2

2

1

0

1

7

tief

P11 - Projektmgt

3

1

2

3

3

3

2

17

hoch

P12 - Release Mgt

3

1

2

3

3

2

1

15

hoch

P13 – Applikationsentwicklung

3

2

1

2

2

1

2

13

mittel

P14 - IT-Betrieb & Konfiguration

3

3

2

1

2

1

2

14

mittel

P15 - Supplier Mgt

2

3

2

2

2

1

1

13

mittel

P16 - Incident Mgt

1

1

2

2

2

1

1

10

mittel

P17 - Problem Mgt

1

0

2

2

3

2

2

12

mittel

Bewertung

Integrität

Tabelle 59: Kritikalitätskarte der IT-Prozesse

Pro Kriterium wird zwischen 0 Punkten (nicht relevant) und 3 Punkten (sehr relevant) gewertet. In der Summe werden die Prozesse mit Punkten zwischen 15 und 21 als „hoch-kritisch“ bewertet. Die Prozesse mit Punkten zwischen 8 und 14 werden als „mittel-kritisch“ beachtet. Die Prozesse mit weniger als 7 Punkten werden als „unkritisch“ eingestuft.

230

14.3 Bewertung des Reifegrades der IT Prozesse Anhand der definierten Kritikalität der Prozesse ist es möglich, eine minimale Anforderung bezüglich Prozessreife zu definieren. Es ist naheliegend zu denken, dass „hoch-kritische“ Prozesse eine Reifestufe von mindestens 4 erreichen müssen. Bei den „mittel-kritischen“ Prozessen ist eine Reife von mindestens 3 empfehlenswert. Anbei ein Beispiel über eine IT-Organisation, in der die Soll-Reifen definiert wurden und die Prozessaudits (Ist-Reife-Werte) durchgeführt worden sind. Soll-Reife

Ist-Reife

P01 – IT-Strategie

3

2

P02 – HR Management

4

2

P03 - IT-Standards & Architektur

4

1

P04 - Financial Management

4

2

P05 – Qualitätsmanagement

3

2

P06 – Portfolio Management

4

2

P07 - Availability / Capacity Management

4

1

P08 – Continuity Management

4

2

P09 – Service Management

4

2

P10 - Anforderungsmanagement

4

3

P11 – Projektmanagement

4

3

P12 – Release Management

4

2

P13 - Applikationsentwicklung

4

3

P14 – IT-Betrieb Konfiguration

4

2

P15 – Supplier Management

3

1

P16 – Incident Management

4

3

P17 – Problem Management

4

1

Die Ergebnisse sind in der folgenden Abbildung zusammengefasst. Die hellgrau markierten Zellen stellen die Diskrepanz zwischen „Soll“ und „Ist“ dar. Damit wird auf einem Blick ersichtlich, wo die Prozesslücken in der IT-Organisation sind.

231

14 Evaluation des Reifegrads (COBIT) Strategische Entscheidungsprozesse HR Management

IT-Strategie

/ -

Level 3 Level 2 Level 1

11/15 6/6 1/1

Level 4 Level 3 Level 2 Level 1

-

-

/

20/27 13/15 6/6 1/1

-

Level 4 Level 3 Level 2 Level 1

Level 4 Level 3 Level 2 Level 1

20/27 14/15 6/6 1/1

Projektmanagement

22/27 15/15 6/6 1/1

-

IT Support

-

Level 4 Level 3 Level 2 Level 1

Qualitätsmanagement

20/27 14/15 6/6 1/1

-

Level 3 Level 2 Level 1

11/15 6/6 1/1

Supply Management

Continuity Management

Capacity/ Availability

/

Level 4 Level 3 Level 2 Level 1

Level 4 Level 3 Level 2 Level 1

24/27 15/15 6/6 1/1

Applikationsentwicklung Level 4 Level 3 Level 2 Level 1

Incident Management

-

Level 4 Level 3 Level 2 Level 1

23/27 15/15 6/6 1/1

24/27 15/15 6/6 1/1

Problem Management

/

Level 4 Level 3 Level 2 Level 1

18/27 12/15 5/6 1/1

Bild 60: Bewertung des Prozessreifegrades

232

/

18/27 13/15 5/6 1/1

/ -

Implementierung

Anforderungsmanagement

-

8/27 7/15 4/6 1/1

IT-Projekt Portfolio Management

Service Management Level 4 Level 3 Level 2 Level 1

Level 4 Level 3 Level 2 Level 1

/

Financial Management

Planung & Controlling

Account Mgt

/

23/27 14/15 6/6 1/1

IT-Standards & Architektur

Release Management

/

Level 4 Level 3 Level 2 Level 1

Level 4 Level 3 Level 2 Level 1

13/27 9/15 6/6 1/1

Supplier Management

IT-Betrieb & Konfiguration Management

18/27 13/15 6/6 1/1

IT-Betrieb & Konfiguration

/ -

Level 4 Level 3 Level 2 Level 1

19/27 12/15 6/6 1/1

/

Level 3 Level 2 Level 1

12/15 5/6 1/1

15 Schlussfolgerung Dieser „Tour d´horizon“ hat die Vielfalt des Themas gezeigt. Aufgrund der Tatsache, dass alle IT-Prozesse eng vernetzt sind und dass alle Tätigkeiten Auswirkungen auf die alltäglichen Abläufe haben, muss das Bewusstsein herrschen, dass gut laufende Prozesse absolut notwendig sind. Die Schwierigkeit liegt in der Qualität der Interaktionen zwischen den verschiedenen Organisationseinheiten, so dass sich das Unternehmen mit den umgesetzten IT-Systemen optimal entwickeln kann. Die IT-Organisation kann ein Stück weit mit einem Restaurant verglichen werden. Die IT-Prozesse entsprechen den Rezepten, die Restaurantbesucher den Benutzern der Informatik, die Zutaten den IT-Systemen und das Kochpersonal dem IT-Staff. Entscheidend an der Stelle bleiben die Qualitäten und Fähigkeiten der Mitarbeiter. Das IT-Management spielt eine wichtige Rolle, so dass die Arbeitsbedingungen und das Arbeitsklima appellierend wirken. Anerkennung und Wertschätzung sind fantastische Hebel, die ermöglichen, viele Herausforderungen in Erfolge umzuwandeln. Es lohnt sich, die Prozesse kontinuierlich zu verbessern, um damit die Qualität des Service Management-Systems - schrittweise in der Anerkennung und Wertschätzung der Leistung der Mitarbeiter – zu erhöhen. Anders gesagt: „Wenn Sie denken, wie Sie immer gedacht haben und handeln, wie Sie immer gehandelt haben, werden Sie bekommen, was Sie immer bekommen haben und erleben, was Sie immer erlebt haben!“ Der gesunde „Menschenverstand“ ist ein nützliches und einfach einzusetzendes Werkzeug. Damit ist es möglich, vieles Schritt für Schritt zu optimieren. Folgende Situationen, die man sehr einfach reflektieren kann, kommen häufig vor, müssen aber sofort korrigiert werden. Strategie

HR Management

–

–

–

Stimmt es, was als strategisch „verkauft“ wird? Wird es in der Tat umgesetzt?

Inwieweit nimmt das Management die Vorbildfunktion wahr?

233

15 Schlussfolgerung IT-Standards & Architektur

Financial Management

–

–

Wir haben eigentlich ein sehr sicheres Sicherheitssystem. Nur jeder kann unbemerkt ins Rechnerzentrum reinkommen!

Wie viel ist wirklich nötig? Wie die Angelsachsen sagen: „what is the value for money? “.

Qualitätsmanagement

IT-Projekt Portfolio Management

–

–

Qualitätsmanagement ist eine geistige Verfassung: bin ich auch ein Botschafter?

Wissen wir, welche Projekte für das Unternehmen wirklich einen Mehrwert bringen?

Capacity / Availability Management

Continuity Management

–

–

Wie stelle ich sicher, dass die Kapazität der IT-Systeme reicht, ohne überdimensioniert zu sein?

Was mache ich im Katastrophenfall?

Service Management

Anforderungsmanagement

–

–

Wie kundenorientiert sind unsere ITDienstleistungen?

Wie kann ich den Wünschen meiner IT-Kunden entgegen kommen?

Projektmanagement

Release Management

–

–

Alle unsere Projekte sind erfolgreich. Nur sind wir sicher, dass wir die richtigen Lösungen bauen?

Ich kann einfach Änderungen im Produktivsystem einspielen. Es passiert sowieso nichts.

Applikationsentwicklung

IT-Betrieb & Konfiguration

–

–

Ist eine organisatorische Lösung effizienter als eine Programmierung, auch wenn mein Auftraggeber es nicht so sieht?

Wie stelle ich das Wissen und die Erfahrung im IT-Betrieb sicher?

Supplier Management

Incident Management

–

–

Der Zulieferer ist Schuld und ich kann nichts dafür!

Problem Management –

234

Inwieweit sind wir sicher, dass die Lösung des Problems richtig ist, bzw. keine weitere Probleme verursacht?

Störungen sind unangenehm und ich möchte solche Situationen vermeiden. Meine Kreativität dazu ist grenzenlos!

A Abkürzungen BCM

Business Continuity Management

BIA

Business Impact Analysis

BMC

Softwarehersteller

BSC

Balanced Scorecard

BSI

Bundesamtes für Sicherheit in der Informationstechnik

B-to-B

Business to Business

CAB

Change Advisory Board

CFO

Chief Finance Officer

CI

Configuration Item

CIO

Chief Information Officer

Co

Controlling

COBIT

Control Objectives for Information and related Technology

CMS

Configuration Management System

CSV

Computer System Validation

Dvt

Development

ECAB

Emergency Change Advisory Board

EDV

Elektronische Datenverarbeitung

ERP

Enterprise Resource Planning

Fi

Finanz

GL

Geschäftsleitung

GPS

globales Positionsbestimmungssystem

HP

HEWLETT-PACKARD

HR

Human Resources

IKS

Internes Kontrollsystem

ILV

Interne Leistungsverrechnung

ISO

International Standards Organisation

235

A Abkürzungen IT

Information Technology

ITGS

IT Grundschutz (Standard des Bundesamtes für Sicherheit in der Informationstechnik)

ITIL

Information Technology Infrastructure Library

ITSM

Information Technology Service Management

Konfig.

Konfiguration

LIMS

Laboratory Information Management System

LOC

Lines Of Code

MA

Mitarbeiter

MIIP

Modell zur Implementierung der IT-Prozesse

Mgt

Management

MS

Microsoft

OLA

Operational Level Agreement

PCS

Process Control System

PT

Personentag

RA

Risk Analysis

RfC

Request for Change

RfP

Request for Proposal

ROM

Rough Order of Magnitude

RZ

Rechnerzentrum

SAP

Systemanalyse und Programmentwicklung

SL

Service Level

SLA

Service Level Agreement

SPOC

Single Point Of Contact

STC

Steering Committee

SW

Software

SWOT

Strengths - Weaknesses - Opportunities - Threats

TOP

Technical Operation Procedure

UAT

User Acceptance Test

UC

Underpinning Contract

USV

unterbrechungsfreie Stromversorgung

236

B Glossar In der folgenden Tabelle werden alle wichtigen IT-Begriffe erklärt, die in diesem Buch verwendet werden. Diese Begriffe werden durch Stichwörter gekennzeichnet. Da viele Konzepte aus dem angelsächsischen Raum kommen, können diese Wörter sowohl in Deutsch als in Englisch sein. Wort Abnahme

Definition Definierter Vorgang, mit dem ein Auftraggeber erklärt, dass ein abgeliefertes Produkt die vertraglichen Vereinbarungen erfüllt

Abnahmetests

Diese Tests werden in der Endphase durchgeführt, bevor das System an die Produktion übergeben wird. Diese beinhalten: – User Acceptance Test: Dieser Test bestätigt, dass das System alle geforderten Business-Funktionalitäten abdeckt und korrekten Output produziert. – Regression Test: Sicherstellen, dass ein Change (Bug Fix) nicht einen zuvor funktionierenden Teil beeinflusst hat. – IT-Betrieb Readiness Test: Dieser Test bestätigt, dass das System mit minimalem (kalkulierbarem) Risiko in die Produktion eingeführt, und dort betrieben, überwacht und unterhalten werden kann, auch in Bezug auf Qualität und Sicherheit.

Anforderung

Beschreibung einer geforderten Systemeigenschaft

Anwender

Nutzer der IT Services. Dies sind in der Regel die Mitarbeiter des Kunden (siehe Kunde).

Anwendung / Applikation

Zusammenfassung von Programmen, die als Gesamtheit implementiert ist. Aus Sicht des Fachbereichs besteht eine Anwendung primär aus denjenigen Funktionen des Fachbereichs, die mit Hilfe der Informationstechnik automatisiert oder unterstützt werden.

Arbeitsanweisung

Anweisung, welche die einzelnen Schritte einer Aktivität beschreibt, die in der Regel aus Abgrenzung und Beschreibung besteht

237

B Glossar Backup-Fenster

Das Backup-Fenster beschreibt den Zeitraum, in welchem die Daten mittels Datensicherungstool gesichert werden. Je nach Funktionalität des verwendeten Tools und der zu sichernden Daten, kann während dieser Zeit nicht auf die Daten zugegriffen werden (geplante Nicht-Verfügbarkeit).

Balanced Scorecard

Die Balanced Scorecard (oder kurz BSC) ist ein ManagementHilfsmittel zur Steuerung einer Organisation. Es konzentriert sich nicht nur auf die finanziellen Kennzahlen, sondern auch auf die Effizienz der internen Prozesse. Die BSC berücksichtigt gleichermaßen die Kundensicht, Lernziele und Wachstumsziele der Organisation. Das Kennzahlensystem wird oft anhand eines so genannten Cockpit Charts präsentiert.

BusinessAuswirkungen

Die Business-Auswirkungen für den Kunden ermitteln sich aus mehreren Faktoren: – Wichtigkeit der betroffenen Geschäftsprozesse – Anzahl betroffene Anwender beim Kunden – Auswirkungen / Unterbrechungen auf die normale Arbeitstätigkeit der Mitarbeiter

Business Case

Szenario zur betriebswirtschaftlichen Beurteilung einer Investition. Ein Projekt stellt eine Investition dar und muss gegenüber der Geschäftsführung eines Unternehmens seine Aussichten auf Gewinn hinreichend überzeugend begründen, um genehmigt zu werden.

Call

Alle Meldungen und Anfragen, welche an den Service Desk (Single Point Of Contact = SPOC) gelangen, gleichgültig ob per Telefon, Email, Fax.

Change

Beschreibt das Hinzufügen, Modifizieren oder Entfernen von freigegebener oder unterstützter Hardware, Netzwerken, Software, Applikationen, Umgebungen, Systemen, PCArbeitsplätzen oder zugehöriger Dokumentation.

Cutover Plan

Die Planung aller nötigen Aktivitäten, um die Migration eines existierenden IT-Systems zu einen neuen zu realisieren

238

B Glossar Datensicherheit

Mit Datensicherheit wird der Schutz von Daten hinsichtlich gegebener Anforderungen an deren Vertraulichkeit, Verfügbarkeit und Integrität bezeichnet. Die Datensicherheit besteht aus vier Kategorien: – Vertraulichkeit: Die Vertraulichkeit von Informationen ist vorhanden, wenn die Informationen nur Befugten in der zulässigen Weise zugänglich sind (Klassifizierung von personen- und sachbezogenen Daten). – Verfügbarkeit: Die Verfügbarkeit der Daten muss jederzeit in der entsprechenden Form gewährleistet werden können. – Integrität: Bei der Integrität der Daten muss sichergestellt werden, dass diese vollständig, unverfälscht und korrekt vorhanden sind. – Verbindlichkeit: Bei der Verbindlichkeit von Informationen muss sichergestellt werden, dass die geforderte Aktualität (z. B. letzte gültige Version) oder die entsprechende Historisierung im Rahmen einer möglichen Revision gewährleistet werden kann.

Failover

Der Failover Mechanismus stellt eine von verschiedenen Möglichkeiten dar, die Verfügbarkeit von Services im Fehlerfall zu erhöhen. Dabei übernimmt eine redundante Komponente im Fehlerfall automatisch die Funktion der fehlerhaften Komponente. Hier stellt sich je nach technischer Implementierung die Frage nach dem Verlust von Daten in den jeweiligen Zwischenspeichern und der eigentlichen User-Session.

Helpdesk

Das Helpdesk stellt im Rahmen des SPOC-Konzeptes ein wichtiges Teilelement des Service Desk dar. Das Helpdesk umfasst die Mitarbeiter und deren Hilfsmittel für den Erstkontakt mit den anrufenden Benutzern.

Incident

Störung, deren Ursache bekannt ist und wo eine vorläufige Umgehung oder eine dauerhafte Lösung existiert. Beispiel: „Reset password“ Ein Incident ist ein Zwischenfall, welcher nicht zum normalen Betrieb eines Service gehört (Ausfall, Qualitätsbeeinträchtigung, Teilausfall, etc.). Der Incident wird durch ein spezifisches Ereignis (Event) ausgelöst und tritt im Helpdesk als Störungsmeldung ein.

239

B Glossar

Incident Ticket

Störungsmeldung, die im Helpdesk Tool festgehalten ist

Integration Tests

Diese Tests fokussieren auf die Integration der verschiedensten Software-Komponenten – über alle Plattformen hinweg. Die beinhalten: –

– –

End-to-End Test: prüft, ob die definierten Funktionen und die Schnittstellen zusammen spielen – möglichst in allen „Benutzer-Szenarien“ Installation Test: eine „Generalprobe“ für die Installation der Software mit den „live“ Tools & Prozessen! Performance Test: aufgrund der vorhandenen Datenmenge müssen erste „Hochrechnungen“ auf das ProduktionsVerhalten gemacht werden können.

IT-System

Gesamtheit der zur selbständigen Erfüllung eines Aufgabenkomplexes erforderlichen technischen und/oder organisatorischen Mittel bestehend unter anderem aus Hardware, Betriebssystemen, Middleware und Software.

Kleinauftrag

Anforderung mit einem Gesamtaufwand von max. 10'000 CHF. Kleinaufträge werden im Rahmen eines SLA abgewickelt.

Kleinprojekt

Ein Kleinprojekt ist ein Projekt, dessen Gesamtaufwand mehr als 10'000 CHF und maximal 50'000 CHF beträgt. Typischerweise werden für Kleinprojekte weniger als 4 Phasen eingeplant.

Known Error

Ein Incident oder Problem, für welche der tiefer liegende Grund bekannt ist und für welche eine temporäre Umgehungslösung oder eine Alternative existieren. Der Known Error bleibt so lange bestehen, bis er durch einen Change gelöst wird.

Konfiguration Item

Komponente der Infrastruktur aus dem Bereich Hardware , Software oder Kommunikation sowie deren Dokumentation. Die Komponenten werden vom Prozess „Konfigurationsmanagement“ kontrolliert.

Konzept

Ein Konzept stellt eine Bauanleitung (hier meist für Software) dar (wie wird etwas gemacht und womit).

Kunde

Auftraggeber für IT-Services. Dies kann die Leitung externer

240

B Glossar Organisationen oder interner wie z.B. der Fachabteilungen sein. ITIL grenzt den Kunden vom Anwender (User) ab. Problem

Störung mit unbekannter Ursache, die einem oder mehreren Incidents zugrunde liegt. Meist ergibt sich ein Problem aufgrund eines Incidents oder interner Analysen. Basierend auf dem so ermittelten Problem wird die Ursache ermittelt. Dabei wird grundlegend davon ausgegangen, dass die Ursache eines Problems behoben wird und somit auch das Problem beseitigt werden kann.

Problem Ticket

Problem Meldung, die in einem Problem Management Tool festgehalten wird

Produktetests

Tests, die durch den Entwickler durchgeführt werden: – Modul Test: dieser Test ist der erste Schritt im Testzyklen und stellt sicher, dass jedes einzelne Element (Executable) „funktioniert“. Speziell werden alle Schnittstellen anhand der Spezifikation geprüft, bevor es in die nächste Test-Phase geht. – Korrektur Test: nach Möglichkeit führt der Entwickler mit eigenen Daten und Scripts schon eine Art Regressions-Test durch, um sicherzustellen, dass alles, was vorher funktionierte, auch nach einer Änderung noch läuft

Projekt

zeitlich begrenztes, einmaliges Vorhaben, um Ziele in der vorgegebenen Zeit innerhalb des finanziellen Budgets, mit verfügbaren personellen Ressourcen und entsprechendem Realisierungsverlauf zu erreichen

Prozess

Vorgang oder Vorgänge, in einer Organisation oder Projekt des Planens, Verwaltens, Ausführens, Anzeigens, Steuerns und Verbessern von Geschäftstätigkeiten

Release

eine Sammlung neuer oder geänderter Konfigurationselemente, welche zusammen getestet, freigegeben und eingeführt werden

Release-

geforderte Systemeigenschaft, die im Rahmen eines Releases im

241

B Glossar Anforderung

Produktivsystem eingeführt wird.

Request for Change (RfC)

Zentrales Dokument, das über den gesamten Lebenszyklus einer Systemänderung nachgeführt wird. Es umfasst unter anderen die Anforderungen, die Ziele und die Verantwortlichkeiten für den Change.

Rolle

In Rollen werden Aufgaben, Zuständigkeiten und Kompetenzen zusammengefasst, um sie einer oder mehreren Personen zur Ausführung zu übertragen. Mitarbeitende werden in mehreren Prozessen und in verschiedenen Rollen tätig sein. Die Rollen bilden einen wichtigen Teil der Stellenbeschreibung.

Roll-out

Verteilung und Installation von Soft- oder Hardwarekomponenten

Routine Incident

Beim Routine-Incident handelt es sich um voraussehbare Störungen und Anfragen. Für die Behebung solcher Incidents existieren Prozeduren und Anleitungen. Diese können durch das Helpdesk abgerufen werden. Beispiele: – Passwort vergessen – Papierstau im Drucker – Zugriffsberechtigungen stimmen nicht mehr – Nochmaliges Installieren der Workstation/Laptop

Schulung

Vermitteln von Wissen

Service Desk

Support-Einheit im Rahmen des Incident Management-Prozesses und dedizierte Ansprechstelle für Anwender von IT-Services.

Übersicht aller erbrachten Services und Leistungen mit deren Service- und Leistungskatalog Eigenschaften Service Level

Qualitative oder quantitative Ausprägung eines definierten Services

Service Level

Formelle Vereinbarung oder Vertrag zwischen Kunden und IT-

242

B Glossar Agreement (SLA) SLA-Verletzung

Dienstleister über Umfang und Güte des zu erbringenden Service

Service Level Requirement (SLR) Single Point of Contact (SPOC)

Die mit dem Kunden auf seine Bedürfnisse ausgerichteten Anforderungen an den Service Level.

Steering Committee

Die Steuerungsgruppe (oder Steering Committee, STC) besteht aus den Führungsverantwortlichen der meistbetroffenen Organisationseinheiten und der Projektleitung (Mitsprache-, aber kein Entscheidungsrecht).

Eine SLA-Verletzung liegt vor, wenn ein vereinbarter Service Level nicht eingehalten werden kann (konnte). Wenn aufgrund der Aktivitäten festgestellt werden kann (vorsorglich) oder festgestellt wird (effektiv), dass eine SLAVerletzung vorliegt, wird diese anhand des Informations- und Eskalationskonzepts entsprechend kommuniziert. SLAVerletzungen müssen anhand ihrer Auswirkungen ( Business Auswirkungen ) für den Leistungsbezieher (Kunden) behandelt werden.

Definierter und einzig möglicher Kontaktpunkt zwischen ITAnwendern und dem IT-Leistungserbringer. Der SPOC ist meist eine zentrale Telefonnummer und eine zentrale, bediente Mailbox. Die Betriebszeiten des SPOC sind im SLA geregelt.

Das STC überwacht insbesondere das Erreichen der Projektziele, das Einhalten der Meilensteinplanung und das Einhalten des Projektbudgets. SW-Anforderung geforderte Systemeigenschaft an bestehenden Applikationen SW-Verteilung

Werkzeug, um die Benutzung einer Anwendung von mehreren PCs zu ermöglichen

Vorlage (oder Template)

Vorlagen und Formulare zur einheitlichen und geordneten Dokumentation von Sachverhalten, Resultaten und Geschäftsvorfällen

Test

Aktivität, um sicherzustellen, dass die Qualität der Anwendungen und der IT-Systeme gewährleistet ist, und damit nachzuwei-

243

B Glossar sen, dass die Anwendungen und Systeme den zuvor definierten Anforderungen genügen Testdrehbuch

Das Testdrehbuch listet alle Tests auf, die im Rahmen eines Projektes oder eines Release durchgeführt werden sollen.

Testfall

Ein Testfall beschreibt einen Test (einbezogene Daten, Transaktionen, Schnittstellen,...) und dokumentiert die Testdurchführung (Fehlermeldung, Re-testing).

Teststrategie

Die Teststrategie ist ein Dokument, das festlegt, welche Tests im Rahmen eines Projektes oder eines Release durchgeführt werden sollen, wer dafür zuständig ist, bzw. welche Testarten nicht durchgeführt werden.

User

Siehe Anwender

Version

Identifizierte und dokumentierte Fassung einer Konfiguration oder einer Konfigurationseinheit

Vertrag

Vereinbarungen über Leistungen externer Lieferanten

Wartungsfenster

Wartungsfenster sind geplante Betriebsunterbrechungen (NichtVerfügbarkeit) für die gesamte ICT-Infrastruktur oder Teile davon. Sie dienen der pro-aktiven oder geplanten Wartung der Komponenten.

Wissensdatenbank

systematisch strukturierte Sammlung von elektronischen Daten, um die Gesamtheit aller organisierten Informationen und ihrer wechselseitigen Zusammenhänge behandeln zu können

2nd & 3rd Level Support

Der 2nd Level Support unterstützt die Lösung komplexerer Anfragen, welche im 1st Level Support nicht gelöst werden konnten. In manchen Fällen ist es sogar nötig, Probleme an den Software Hersteller oder Spezialisten weiterzuleiten; dies entspricht einem 3rd Level Support.

Wichtige Quelle: Informatikstrategieorgan Bund (Siehe http://www.isb.admin.ch/)

244

C Literatur Behr K., Kim G., Spafford G. The visible Ops Handbook: implementing ITIL in 4 practical and auditable steps, IT Process Institute, 2007 Berger T. Service Level Agreements, VDM, 2007 Blanchard K., Lacinak T., Tompkins C., Ballard J. Whale Done!: The Power of Positive Relationships, Nicholas Brealey Publishing Ltd, Mai 2002 van Bon Jan IT Service Management Based on ITIL V3: A Pocket Guide (ITSM Library), Paperback - 30 Nov 2007 Buchta, D., Eul, M., Schulte-Croonenberg, H. Strategisches IT Management, Gabler Verlag, 2004 Carr N. Does IT Matter?, Information Technology and the Corrosion of Competitive Advantage, HBS Press Book, 2004 Central Computer and Telecommunications Agency (CCTA) Security Management (ITIL), Ausgabe 1999 Collins J. Good to Great: Why Some Companies Make the Leap... and Others Don't, Random House UK, Oktober 2001 Covey S. The 7 Habits of Highly Effective People, Fireside, 1990 Dumont C. ITIL: pour un service informatique optimal, Eyrolles, 2006 Ellis A., Kauferstein M. Dienstleistungsmanagement - Erfolgreicher Einsatz von prozessorientiertem Service Level Management. Springer, 2007

245

C Literatur Finkelstein S. Why Smart Executives Fail: And What You Can Learn from Their Mistakes, Portfolio, 2003 Goldratt E., Cox J., Whitford D. The Goal: A Process of Ongoing Improvement, North River Press, 2004 Hansen H. R., Neumann, G. Wirtschaftsinformatik 1, 9. Auflage, 2005 Helbig R. Prozessorientierte Unternehmensführung. Physica Verlag, Heidelberg 2003 Informatikstrategieorgan Bund ISB http://www.isb.admin.ch/imperia/md/content/methodenundterminologie/terminol ogie/gloss_isb_termdat_v2_040220.pdf Johnson S. Who Moved My Cheese?, Random House UK, 1999 Kaplan, R. S./Norton, D. P. Balanced Scorecard: Strategien erfolgreich umsetzen, 1997 Keller , W. IT-Unternehmensarchitektur: Von der Geschäftsstrategie zur optimalen ITUnterstützung, Dpunkt Verlag, 2006 Kotter J. A Sense of Urgency, HBS Press Book, 2008 Kotter J., Cohen D. Heart of Change: Real-Life Stories of How People Change Their Organizations, HBS Press Book, 2002 Kütz, M. Kennzahlen in der IT, Dpunkt.Verlag GmbH Liker, J. The Toyota Way: Fourteen Management Principles from the World's Greatest Manufacturer, McGraw-Hill, 2004 Lloyd V., Peters L., Rupchock K. Planning to Implement Service Management (IT Infrastructure Library), Juni 2002 Lundin S., Paul H., Christensen J., Schilasky S. FISH! for Life, Moderne Verlagsges. Mvg, 2004

246

C Literatur Mertens, P. Lexikon der Wirtschaftsinformatik, 4. Auflage, 2001 Mertens, P., Bodendorf F., König W., Picot A., Schumann M., Hess T. Grundzüge der Wirtschaftsinformatik, Auflage: 9., überarbeitet A. 2005 Mintzberg, H. Structure & Dynamique des Organisations, Les Editions d´Organisation, 4. Auflage, 1988 Niemann, K. D. Von der Unternehmensarchitektur zur IT Governance, 2005 Niessink F., van Vliet H. Software Process - Improvement and Practice, 1998 Office for Government Commerce (OGC) Best Practices for Service Support (ITIL), Ausgabe 2000 Office for Government Commerce (OGC) Best Practices for Service Delivery (ITIL), Ausgabe 2001 Olbrich, A. ITIL kompakt und verständlich, Vieweg Verlag, 2004 Paulk, M.C. An Empirical Study of Process Discipline and Software Quality, Dissertation, University of Pittsburgh, 2005 Project Management Institute (PMI) A Guide to the Project Management Body of Knowledge (PMBOK® Guide), PMI, 2004 The IT Infrastructure Management Forum IT Service Management, 1995 Roberts W. Leadership Secrets of Attila the Hun, Simon & Schuster Ltd, März 1989 Saleck T. Auftragsklärung in IT Projekten, Vieweg Verlag, 2003 Scheer A.-W. ARIS – Vom Geschäftsprozess zum Anwendungssystem, 4. Auflage, März 2002 Schwarze J. Einführung in die Wirtschaftsinformatik, Auflage 2000

247

C Literatur Serview GmbH ITSM Advanced Pocket Book, live ITIL, 2005 Sidi J., Otter M., Hanaud L. Guide des certifications SI, comparatif, analyse et tendances : Itil, CobiT, Iso 27001, eSCM..., Dunod, 2006 Victor F., Günther H. Optimiertes IT Management mit ITIL, Vieweg Verlag, 2005 Vogel O., Arnold I., Chughtai A., Ihler. E., Kehrer T., Mehlig U., Zdun U. Software-Architektur, Spektrum Verlag, 2. Auflage 2008 Waniczek M. Berichtswesen optimieren, Redline Wirtschaft, 2002 Wolf S. IT Governance mit ITIL, CObIT und der Balanced Scorecard, Diplomarbeit, Hochschule Niederrhein, Fachbereich Wirtschaftswissenschaften, 2006 Zarnekow R., Brenner W., Pilgram U. Integriertes Informationsmanagement, Springer Verlag, 2005 Zarnekow R., Hochstein A., Brenner W. Service-orientiertes IT Management, Springer Verlag, 2005 Zarnekow R. Produktionsmanagement von IT Dienstleistungen, Springer Verlag, 2007 Zarnekow R., Brenner W., Grohmann H. Informationsmanagement, Springer Verlag, 2005

248

D IT-Management-Standards ISO 20000: Service Management Part 1: Specification Part 2: Code of practice definiert eine integrierte und prozessorientierte Methodik für eine effektive Planung und Erstellung von IT Services http://www.iso.org ISO 19770: Software Asset Management konkretisiert die Anforderungen an das Asset Management für eingesetzte Softwareprodukte (SAM) und gilt im Zusammenhang mit ISO 12207 (Software Lifecycle Management) und ISO 20000 (IT Service Management). www.bsi-global.com ISO 17799: Security techniques Code of practice for information security management http://www.iso.org ISO 27001: Security techniques Information security management systems -- Requirements http://www.iso.org http://17799.standardsdirect.org/ ISO 27002: Security techniques Code of practice for information security management ersetzt den Standard ISO17799:2005 http://www.iso.org ISO 27005: Security techniques Information security risk management behandelt das Risikomanagement http://www.iso.org

249

D IT-Management-Standards ISO 27006: Security techniques Requirements for bodies providing audit and certification of information security management systems Regelt Fallback- und Wiederherstellungsmechanismen in der IT http://www.iso.org ISO 15408: Security techniques Evaluation criteria for IT security Gemeinsame Kriterien für die Prüfung und Bewertung der Sicherheit von Informationstechnik http://www.iso.org ISO 15504: Process assessment Norm für Prozessmodelle und Prüfungsverfahren http://www.iso.org SSE-CMM: IT-Sicherheitsmanagement http://www.sse-cmm.org/ British Standard BS 15000 (ersetzt durch ISO 2000) http://www.bs15000.org.uk ITIL http://www.itsmfi.org COBIT Framework http://www.isaca.org/cobit IT Service CMM: CMM für das IT Service Management http://www.itservicecmm.org/ CMMI (Capability Maturity Model Integration) Software Engineering Institute, Carnegie Mellon http://www.sei.cmu.edu/cmmi/

250

D IT-Management-Standards IT-Grundschutz-Standards des BSI http://www.bsi.de/gshb/index.htm KBSt (inklusiv V-Modell) Ausschreibung und Bewertung von IT-Leistungen (UfAB) http://www.kbst.bund.de PRINCE 2 Projekt Management Methode http://www.prince2.com Project Management Body of Knowledge (PMBOK) http://www.pmi.org Management of Risk (M_o_R) http://www.mor-officialsite.com/home/home.asp eSourcing Capability Model for Service Providers (eSCM-SP), Carnegie Mellon University http://itsqc.cmu.edu/

251

E ITIL Im Bereich IT Service Management bietet die IT Infrastructure Library (ITIL) einen anerkannten und weit verbreiteten Management Standard für die Gestaltung der IT Services. ITIL liefert vor allem einen integrierten Rahmen für die Planung und Steuerung von IT Services, für die Gestaltung von Kunden- und Lieferantenbeziehungen der IT-Organisation und für die Sicherstellung der Informationssicherheit. Damit sollen die IT-Organisationen im Bereich IT Service Management folgendes erreichen: – die IT-Systeme werden in Stand gehalten und weiterentwickelt, – neue IT-Systeme können aufgesetzt werden, – die erbrachten IT Services werden den wechselnden Business Bedürfnissen angepasst. Als Folge dessen, werden die folgenden Vorteile für das Unternehmen erwartet: – – – –

eine Steigerung der Produktivität, die Sicherstellung der Qualität, eine größere Leistungsfähigkeit der IT Services, eine Minderung der Risiken.

Das IT Service Management nach ITIL V2 lässt sich in zwei Prozessbereiche gliedern: 1) Service Support Management: dies umfasst fünf Prozesse, die zur Unterstützung der Qualität und Wirtschaftlichkeit der Services im täglichen Betrieb notwendig sind. Diese Prozesse beziehen sich in erster Linie auf die Betriebsfunktionen. 2) Service Delivery Management: die fünf entsprechenden Prozesse erzielen die Planung und Umsetzung der Serviceanforderungen. Diese umfassen in erster Linie Management-Funktionen, um die Kosten, Verfügbarkeit und Wirtschaftlichkeit, den optimalen Ressourceneinsatz sowie die Vorsorge und Behandlung von Notfällen der IT Services zu beherrschen.

253

E ITIL 1) Service Support-Prozesse

2) Service Delivery-Prozesse

Configuration Management

Service Level Management

Incident Management

Capacity Management

Problem Management

Availability Management

Change Management

Continuity Management

Release Management

Financial Management

Zusätzlich wurde Security Management berücksichtigt, um die Themen „Vertraulichkeit“ „Datenintegrität“ oder „Systemverfügbarkeit“ zu adressieren In der folgenden Tabelle werden die Ziele der 10 definierten ITIL-Prozesse beschrieben. Prozess

Beschreibung / Ziel

Configuration Management

Aktualisierte Informationen über die Konfigurationselemente der umgesetzten Systeme werden zur Verfügung gestellt.

Incident Management

Services werden so schnell wie möglich, in der vereinbarten Zeit, wiederhergestellt

Problem Management

Durch Korrigieren oder Vermeiden von Fehlern werden Störungen reduziert oder verhindert.

Change gement

Mana-

Änderungen werden termingerecht mit minimalen Risiken implementiert.

Release gement

Mana-

Rollouts von geprüften und freigegebenen Hardware- und Softwarekomponenten werden termingerecht und störungsfrei durchgeführt.

Service Level Management

Die Übereinstimmung zwischen der erbrachten und der vereinbarten Leistung wird sichergestellt.

Capacity Management

Es wird sichergestellt, dass die vereinbarten Leistungen zu wirtschaftlichen Bedingungen erbracht werden.

254

E ITIL Availability Management

Die vereinbarte Serviceverfügbarkeit wird gewährleistet

Continuity Management

In Ausnahmesituationen wird die Serviceleistung sichergestellt.

Financial Management

Finanzinformationen zur betriebswirtschaftlichen Steuerung der Organisation werden bereitgestellt.

Dank eines evolutionären Ansatzes wird ITIL als Methode ständig weiterentwickelt. Das kürzlich veröffentlichte ITIL V3 legt mehr Wert auf die Beziehung zwischen der IT und dem Business. Es beinhaltet einen Servicelebenszyklus von „Service Strategy“ bis zum „Service IT-Betrieb“, wo zwei weitere Zwischenschritte „Service Design“ und „Service Transition“ berücksichtigt werden. Nennenswert sind Verbesserungen in folgenden Bereichen: – die Verbindung der Geschäftsstrategie mit der IT Service-Strategie ist klarer definiert, – Servicegestaltung soll durch einen ROI-Plan ermöglicht werden, – die Überführung von Services in dem Betrieb wird beschrieben, – das Management von Serviceprovidern und Sourcing-Modellen wird klarer , – das Management von Services für dynamische, schwer berechenbare und sich rasch verändernde Geschäftsbedürfnisse mit hohem Risiko wurde verbessert, – die Messbarkeit des Nutzens wurde verbessert, – die Verbesserung und Veränderungen im gesamten Servicelebenszyklus sind aufzeigt. Es ist empfehlenswert, die ITIL-Prozesse zu kennen, um das Rad nicht neu zu erfinden. Dennoch, im Hinblick auf ein Gesamtprozessmodell für eine ITOrganisation muss Folgendes festgehalten werden: – ITIL ist keine fertige Gebrauchsanweisung, – ITIL sagt, was man tun soll, leider aber nicht konkret wie, – Alle für eine IT-Organisation notwendigen Prozesse werden im ITIL nicht abgebildet, – viele andere nützliche IT Standards zur Gestaltung und Management der ITProzesse (ISO, Cobit, CMM,…) stehen zur Verfügung,

255

E ITIL – die detaillierte Analyse und die operative Umsetzung der Prozesse zeigen möglicherweise eine Diskrepanz zwischen ITIL-Definitionen und den realen Bedürfnissen der IT-Organisation. Aus diesen Gründen erschien es notwendig, das ITIL-Modell zu ergänzen und in bestimmten Bereichen neu zu definieren.

256

F CobIT PO: planen und organisieren Die Rubrik PO „planen und organisieren“ beinhaltet 11 Punkte. Punkt / Themen PO1: Definition eines strategischen Informationstechnologie-Plans PO 1.1: IT als Teil der kurz- und langfristigen Planung des Unternehmens PO 1.2: Langfristiger IT-Plan PO 1.3: Langfristiger IT-Plan – Vorgehen und Struktur PO 1.4: Änderungen des langfristigen IT-Plans PO 1.5: Kurzfristige Planung der Informatikabteilung PO 1.6: Kommunikation der IT-Pläne PO 1.7: Überwachung und Beurteilung von IT-Plänen PO 1.8: Bewertung bestehender Systeme PO2: Definition der Informationsarchitektur PO 2.1: Informationsarchitektur-Modell PO 2.2: Unternehmensweites Datenverzeichnis und Datensyntaxregeln PO 2.3: Schema zur Datenklassifikation PO 2.4: Sicherheitsstufen PO3: Bestimmung der technologischen Richtung PO 3.1: Planung der technischen Infrastruktur PO 3.2: Überwachung zukünftiger Trends und Vorschriften PO 3.3: Notfallaspekte der technologischen Infrastruktur PO 3.4: Beschaffungspläne für Hard- und Software PO 3.5: Technologie-Standards PO4: Definition der IT-Organisation und ihrer Beziehungen PO 4.1: Der IT-Planungs- oder Lenkungsausschuss PO 4.2: Organisatorische Einordnung der Informatik PO 4.3: Prüfung der organisatorischen Ausgestaltung PO 4.4: Rollen und Verantwortlichkeiten PO 4.5: Verantwortung für Qualitätssicherung

257

F CobIT PO 4.6: Verantwortung für logische und physische Sicherheit PO 4.7: Eigentümerprinzip und treuhänderische Tätigkeit PO 4.8: Eigentümerprinzip für Daten und Systeme PO 4.9: Beaufsichtigung PO 4.10: Funktionstrennung PO 4.11: Personelle Besetzung der IT PO 4.12: Aufgaben- oder Stellenbeschreibungen für Informatikpersonal PO 4.13: IT-Schlüsselpersonen PO 4.14: Richtlinien und Verfahren für Leihpersonal PO 4.15: Beziehungen PO5: Verwaltung der IT-Investitionen PO 5.1: Jährliches Informatik-Betriebsbudget PO 5.2: Überwachung von Kosten und Nutzen PO 5.3: Kosten- und Nutzen-Rechtfertigung PO6: Kommunikation von Führungszielen und -richtung PO 6.1: Positive Informationskontrollumgebung PO 6.2: Verantwortung des Management für Richtlinien PO 6.3: Bekanntgabe der Unternehmensrichtlinien PO 6.4: Ressourcen zur Umsetzung der Richtlinien PO 6.5: Unterhalt der Richtlinien PO 6.6: Einhaltung von Richtlinien, Verfahren und Standards PO 6.7: Verpflichtung zur Qualität PO 6.8: Konzept für Sicherheit und internes Kontrollsystem PO 6.9: Urheberrechte PO 6.10: Themenspezifische Richtlinien PO 6.11: Kommunikation des IT-Sicherheitsbewusstseins PO7: Personalwesen PO 7.1: Rekrutierung und Beförderung des Personals PO 7.2: Personalqualifikationen PO 7.3: Rollen und Verantwortlichkeiten PO 7.4: Ausbildung des Personals PO 7.5: Quer-Training oder Stellvertretung

258

F CobIT PO 7.6: Sicherheitsabklärung für Personal PO 7.7: Leistungsbeurteilung für Angestellte PO 7.8: Stellenwechsel und Kündigung PO8: Sicherstellung der Einhaltung von externen Anforderungen PO 8.1: Überprüfung der externen Anforderungen PO 8.2: Praktiken und Verfahren zur Einhaltung von externen Anforderungen PO 8.3: Einhaltung von Arbeitssicherheit und Ergonomie PO 8.4: Datenschutz, Urheberrecht und Datenfluss PO 8.5: Elektronischer Handel PO 8.6: Einhaltung von Versicherungsverträgen PO9: Risikobeurteilung PO 9.1: Beurteilung der Geschäftsrisiken PO 9.2: Vorgehen zur Risikobeurteilung PO 9.3: Risikoidentifikation PO 9.4: Risikomessung PO 9.5: Risikoaktionsplan PO 9.6: Risikoakzeptanz PO 9.7: Auswahl der Sicherheitsvorkehrungen PO 9.8: Verpflichtung zur Risikobeurteilung PO10: Projektmanagement PO 10.1: Projektmanagement-Rahmen PO 10.2: Beteiligung der Fachbereiche bei der Projektinitiierung PO 10.3: Projektteam-Mitgliedschaft und Verantwortlichkeiten PO 10.4: Projektdefinition PO 10.5: Projektfreigabe PO 10.6: Freigabe der Projektphasen PO 10.7: Projektmasterplan PO 10.8: System-Qualitätssicherungsplan PO 10.9: Planung von Bestätigungsmethoden PO 10.10: Formelles Projektrisikomanagement PO 10.11: Testplan PO 10.12: Schulungsplan

259

F CobIT PO 10.13: Plan zur Prüfung nach der Einführung PO11: Qualitätsmanagement PO 11.1: Allgemeiner Qualitätsplan PO 11.2: Vorgehen bei der Qualitätssicherung PO 11.3: Planung der Qualitätssicherung PO 11.4: Prüfung der Qualitätssicherung auf Einhaltung von IT-Standards und Verfahren PO 11.5: Systementwicklungsmethode PO 11.6: Systementwicklungsmethode für größere Änderungen an der bestehenden Technologie PO 11.7: Aktualisierung der Systementwicklungsmethode PO 11.8: Koordination und Kommunikation PO 11.9: Handlungsrahmen für Beschaffung und Unterhalt der technischen Infrastruktur PO 11.10: Beziehungen zu Drittparteien-Entwicklern PO 11.11: Standards für Programmdokumentationen PO 11.12: Standards für Programmtests PO 11.13: Standards für Systemtests PO 11.14: Paralleltest, Pilotbetrieb PO 11.15: Dokumentation von Systemtests PO 11.16: Beurteilung der Einhaltung von Entwicklungsstandards durch die Qualitätssicherung PO 11.17: Qualitätssicherungsprüfung auf Erreichung der Informatikziele PO 11.18: Messgrößen der Qualität PO 11.19: Berichte über Qualitätssicherungsprüfungen AI: beschaffen und einführen Der Teil AI „beschaffen und einführen“ beinhaltet 6 Punkte mit insgesamt 68 Prüfpunkten. Punkt / Themen AI1: Identifikation von automatisierten Lösungen AI 1.1: Definition der Informationsbedürfnisse AI 1.2: Formulierung von Handlungsalternativen

260

F CobIT AI 1.3: Formulierung der Beschaffungsstrategie AI 1.4: Anforderungen an Drittparteien-Dienstleistungen AI 1.5: Technologische Machbarkeitsstudie AI 1.6: Wirtschaftliche Machbarkeitsstudie AI 1.7: Informationsarchitektur AI 1.8: Risikoanalyse-Bericht AI 1.9: Kostenwirksame Sicherheitsmassnahmen AI 1.10: Gestaltung von Prüfspuren AI 1.11: Ergonomie AI 1.12: Auswahl der Systemsoftware AI 1.13: Kontrolle der Beschaffung AI 1.14: Beschaffung von Software-Produkten AI 1.15: Software-Unterhalt durch Drittparteien AI 1.16: Anwendungsprogrammierung im Auftragsverhältnis AI 1.17: Abnahme von Anlagen AI 1.18: Abnahme der Technologie AI2: Beschaffung und Unterhalt von Software AI 2.1: Entwurfsmethoden AI 2.2: Grundlegende Änderungen an bestehenden Systemen AI 2.3: Genehmigung des Entwurfs AI 2.4: Definition und Dokumentation der Dateianforderungen AI 2.5: Programmspezifikationen AI 2.6: Entwurf der Erfassung von Quelldaten AI 2.7: Definition und Dokumentation von Eingabeanforderungen AI 2.8: Definition von Schnittstellen AI 2.9: Schnittstelle Mensch-Maschine AI 2.10: Definition und Dokumentation von Verarbeitungsanforderungen AI 2.11: Definition und Dokumentation von Ausgabeanforderungen AI 2.12: Kontrollierbarkeit AI 2.13: Verfügbarkeit als Schlüssel-Entwurfsfaktor AI 2.14: IT-Integritätsvorkehrungen in Software AI 2.15: Testen von Software

261

F CobIT AI 2.16: Benutzerhandbuch und andere Hilfen AI 2.17: Neubeurteilung des Systementwurfs AI3: Beschaffung und Unterhalt der technischen Infrastruktur AI 3.1: Beurteilung von neuer Hard- und Software AI 3.2: Präventive Hardware-Wartung AI 3.3: Sicherheit der Systemsoftware AI 3.4: Installation der Systemsoftware AI 3.5: Wartung der Systemsoftware AI 3.6: Änderungskontrollen für Systemsoftware AI 3.7: Verwendung und Überwachung von Dienstprogrammen AI4: Entwicklung und Unterhalt von Verfahren AI 4.1: Betriebliche Anforderungen und Dienstleistungsgrade AI 4.2: Handbücher der Benutzerverfahren AI 4.3: Betriebshandbuch AI 4.4: Schulungsunterlagen AI5: Installation und Akkreditierung von Systemen AI 5.1: Schulung AI 5.2: Leistungsanpassung für Software AI 5.3: Einführungsplan AI 5.4: Systemkonvertierung AI 5.5: Datenkonvertierung AI 5.6: Teststrategien und –Pläne AI 5.7: Testen von Änderungen AI 5.8: Kriterien für Paralleltest/Pilotbetrieb und dessen Durchführung AI 5.9: Abschließender Abnahmetest AI 5.10: Sicherheitstest und Akkreditierung AI 5.11: Betriebstest AI 5.12: Produktivsetzung (”Umzugs-/Zügelverfahren”) AI 5.13: Beurteilung der Erfüllung von Benutzeranforderungen AI 5.14: Überprüfung nach der Einführung durch das Management AI6: Änderungswesen AI 6.1: Anstoß und Kontrolle von Änderungsanträgen

262

F CobIT AI 6.2: Beurteilung der Auswirkungen AI 6.3: Kontrolle der Änderungen AI 6.4: Änderungen im Notfall AI 6.5: Dokumentation und Verfahren AI 6.6: Genehmigte Wartung AI 6.7: Software Versionskonzept AI 6.8: Software-Verteilung DS: ausliefern und unterstützen Bei dem Teil DS „Auslieferung und Unterstützung“ sind 13 Punkte berücksichtigt. Punkt / Themen DS1: Definition und Management von Dienstleistungsgraden DS 1.1: Rahmen der Dienstleistungsvereinbarung DS 1.2: Aspekte von Dienstleistungsvereinbarungen DS 1.3: Leistungsverfahren DS 1.4: Überwachung und Berichterstattung DS 1.5: Prüfung von Dienstleistungsvereinbarungen und Verträgen DS 1.6: Verrechenbare Einheiten DS 1.7: Programm zur Dienstleistungsverbesserung DS2: Handhabung der Dienste von Drittparteien DS 2.1: Schnittstellen zu Lieferanten DS 2.2: Beziehungen zu Eignern DS 2.3: Verträge mit Drittparteien DS 2.4: Qualifikationen von Drittparteien DS 2.5: Auslagerungsverträge DS 2.6: Kontinuität der Dienstleistungen DS 2.7: Sicherheit in Beziehungen DS 2.8: Überwachung DS3: Leistungs- und Kapazitätsmanagement DS 3.1: Verfügbarkeits- und Leistungsanforderungen DS 3.2: Verfügbarkeitsplan DS 3.3: Überwachung und Berichterstattung

263

F CobIT DS 3.4: Modellierungswerkzeuge DS 3.5: Proaktives Leistungsmanagement DS 3.6: Prognosen über die Auslastung DS 3.7: Kapazitätsmanagement der IT-Ressourcen DS 3.8: Verfügbarkeit der Ressourcen DS 3.9: Ressourcenplanung DS4: Sicherstellen der kontinuierlichen Dienstleistung DS 4.1: Rahmen der IT-Kontinuität DS 4.2: Strategie und Philosophie des IT-Kontinuitätsplans DS 4.3: Inhalte des IT-Kontinuitätsplan DS 4.4: Minimierung der IT-Kontinuitätsanforderungen DS 4.5: Unterhalt des IT-Kontinuitätsplans DS 4.6: Testen des IT-Kontinuitätsplans DS 4.7: Schulung des IT-Kontinuitätsplans DS 4.8: Verteilung des IT-Kontinuitätsplans DS 4.9: Ausweichverfahren der Fachabteilung DS 4.10: Kritische IT-Ressourcen DS 4.11: Ausweichstandort und Ersatz-Hardware DS 4.12: Auslagerung von Sicherungen DS 4.13: Aufbearbeitungsverfahren DS5: Sicherstellen der Systemsicherheit DS 5.1: Handhabung von Sicherheitsmaßnahmen DS 5.2: Identifikation, Authentisierung und Zugriff DS 5.3: Sicherheit des Direktzugriffs auf Daten DS 5.4 Verwaltung der Benutzerkonten DS 5.5: Überprüfung der Benutzerkonten durch das Management DS 5.6: Überprüfung der Benutzerkonten durch die Benutzer DS 5.7: Sicherheitsüberwachung DS 5.8: Datenklassifikation DS 5.9: Zentrale Verwaltung von Identifikation und Zugriffsrechten DS 5.10: Rapportierung von Verstößen und Sicherheitsaktivitäten DS 5.11: Umgang mit Zwischenfällen

264

F CobIT DS 5.12: Re-Akkreditierung DS 5.13: Vertrauenswürdigkeit der Gegenpartei DS 5.14: Genehmigung von Transaktionen DS 5.15: Nicht-Abstreitbarkeit DS 5.16: Vertrauenswürdiger Pfad DS 5.17: Schutz von Sicherheitsfunktionen DS 5.18: Verwaltung kryptographischer Schlüssel DS 5.19: Prävention, Aufdeckung und Korrektur bei bösartiger Software DS 5.20: Firewall Architekturen und Verbindungen mit öffentlichen Netzwerken DS 5.21: Schutz von elektronischen Werten DS6: Identifizierung und Zuordnung von Kosten DS 6.1: Verrechenbare Einheiten DS 6.2: Kostenabrechnungsverfahren DS 6.3: Verfahren für Rechnungsstellung und Weiterverrechnung DS7: Aus- und Weiterbildung von Benutzern DS 7.1: Identifikation von Schulungsbedürfnissen DS 7.2: Schulungsorganisation DS 7.3: Schulung von Sicherheitsprinzipien und Sicherheitsbewusstsein DS8: Unterstützung und Beratung von Kunden DS 8.1: Helpdesk DS 8.2: Registrierung von Kundenanfragen DS 8.3: Eskalation von Kundenanfragen DS 8.4: Überwachung der Erledigung DS 8.5: Trendanalyse und Berichterstattung DS9: Konfigurationsmanagement DS 9.1: Aufzeichnung der Konfiguration DS 9.2: Konfigurations-Referenzversion DS 9.3: Statusbericht DS 9.4: Konfigurationskontrolle DS 9.5: Unbewilligte Software DS 9.6: Aufbewahrung von Software DS 9.7: Verfahren für Konfigurationsmanagement

265

F CobIT DS 9.8: Nachvollziehbarkeit der Software DS10: Umgang mit Problemen und Zwischenfällen DS 10.1: Problemmeldewesen DS 10.2: Problemeskalation DS 10.3: Problemverfolgung und Prüfspur DS 10.4: Notfallmäßige und vorübergehende Zugriffsberechtigungen DS 10.5: Prioritäten für die Notfallbearbeitung DS11: Verwaltung von Daten DS 11.1: Verfahren zur Vorbereitung von Daten DS 11.2: Verfahren zur Genehmigung von Urbelegen DS 11.3: Erfassung von Urbelegen DS 11.4: Fehlerbehandlung von Urbelegen DS 11.5: Aufbewahrung von Urbelegen DS 11.6: Genehmigungsverfahren für Dateneingabe DS 11.7: Prüfung auf Genauigkeit, Vollständigkeit und Berechtigung DS 11.8: Fehlerbehandlung bei der Dateneingabe DS 11.9: Integrität bei der Datenverarbeitung DS 11.10: Validierung und Aufbereitung der Datenverarbeitung DS 11.11: Fehlerbehandlung bei der Datenverarbeitung DS 11.12: Handhabung und Aufbewahrung von Output DS 11.13: Verteilung von Output DS 11.14: Saldierung und Abstimmung von Output DS 11.15: Prüfung und Fehlerbehandlung von Output DS 11.16: Sicherheitsvorkehrungen für Output-Berichte DS 11.17: Schutz von sensitiven Informationen während Übermittlung und Transport DS 11.18: Schutz von entsorgten sensitiven Informationen DS 11.19: Speicherungsmanagement DS 11.20: Aufbewahrungsfristen und Speicherungsbedingungen DS 11.21: Datenträger-Bibliotheksverwaltung DS 11.22: Verantwortlichkeiten der Datenträger-Bibliotheksverwaltung DS 11.23: Sicherung und Wiederherstellung

266

F CobIT DS 11.24: Sicherstellungsarbeiten DS 11.25: Aufbewahrung der Sicherungen DS 11.26: Archivierung DS 11.27: Schutz von sensitiven Nachrichten DS 11.28: Authentisierung und Integrität DS 11.29: Integrität von elektronischen Transaktionen DS 11.30: Andauernde Integrität von gespeicherten Daten DS12: Verwaltung von Einrichtungen DS 12.1: Physische Sicherheit DS 12.2: Unauffälliges Profil des IT-Standortes DS 12.3: Begleitung von Besuchern DS 12.4: Gesundheit und Schutz des Personals DS 12.5: Schutz gegen Umweltfaktoren DS 12.6: Unterbrechungsfreie Stromversorgung DS13: Management der Produktion DS 13.1: Verarbeitungsbetriebsverfahren und Anweisungshandbücher DS 13.2: Startprozess- und andere Betriebsdokumentation DS 13.3: Job-Terminplanung DS 13.4: Abweichungen von Standard-Job-Plänen DS 13.5: Kontinuität der Verarbeitung DS 13.6: Betriebs-Protokolle DS 13.7: Sicherheitsvorkehrungen für Spezialformulare und Ausgabegeräte DS 13.8: Ferngesteuerter Betrieb M: überwachen Im Bereich M „Überwachung“ sind 4 Themen gelistet, mit insgesamt 24 Prüfpunkten. Punkt / Themen M1: Überwachung der Prozesse M 1.1: Sammeln von Überwachungsdaten M 1.2: Beurteilung der Leistung M 1.3: Beurteilung der Kundenzufriedenheit

267

F CobIT M 1.4: Berichterstattung an das Management M2: Beurteilung der Angemessenheit der internen Kontrollen M 2.1: Überwachung der internen Kontrollen M 2.2: Rechtzeitigkeit des Betriebs von internen Kontrollen M 2.3: Berichterstattung über den Wirkungsgrad der internen Kontrollen M 2.4: Betriebliche Sicherheit und Bestätigung der internen Kontrollen M3: Erlangen einer unabhängigen Bestätigung M 3.1: Unabhängige Zertifizierung/Akkreditierung von Sicherheit und internen Kontrollen der IT-Dienste M 3.2: Unabhängige Zertifizierung/Akkreditierung von Sicherheit und internen Kontrollen bei Dienstleistungen von Drittanbietern M 3.3: Unabhängige Beurteilung der Effektivität von IT-Diensten M 3.4: Unabhängige Dienstleistungen

Beurteilung

der

Effektivität

von

Drittanbieter-

M 3.5: Unabhängige Bestätigung der Einhaltung von Gesetzen, Vorschriften und vertraglichen Verpflichtungen M 3.6: Unabhängige Bestätigung der Einhaltung von Gesetzen, Vorschriften und vertraglichen Verpflichtungen durch die Drittanbieter M 3.7: Kompetenz der unabhängigen Bestätigungsfunktion M 3.8: Proaktiver Einbezug der Revision M4: Für eine unabhängige Revision sorgen M 4.1: Revisionsstatut M 4.2: Unabhängigkeit M 4.3: Berufsethik, Berufsstandards M 4.4: Kompetenz M 4.5: Planung M 4.6: Durchführung der Revisionstätigkeiten M 4.7: Berichterstattung M 4.8: Folgeaktivitäten (Nachrevision)

268

G MIIP-Vorlagen Im OnlinePLUS-Service zum Buch sind die Vorlagen abrufbar, die man von der Homepage des Verlags (www.viewegteubner.de) downloaden kann. Allgemeine Vorlagen (2 Vorlagen) Name Beschreibung

Format

Vorlage 1

Vorlage für Arbeitsdokumente

MS Word

Vorlage 2

Vorlage für formelle Freigabe

MS Word

P01 – IT-Strategie (4 Vorlagen) Name

Beschreibung

Format

P01-1_Vorlage_ITStrategie

Dokument mit den IT-Grundsätzen

MS Word

P01-2_Vorlage_ITIS

Beschreibung der IT-Architektur, der festgelegten Standards und der eingesetzten IT-Technologien

MS Word

P01-3_Vorlage_

Wirtschaftlichkeitsrechnung Investition

MS Excel

Business Case P01-4_Vorlage_ITOrganigramm

einer

IT-

Aufbauorganisation graphisch dargestellt

MS Powerpoint

P02 – HR-Management (6 Vorlagen) Name

Beschreibung

Format

P02-1_Vorlage_

Festlegung der Rekrutierungsvorgehensweise

MS Word MS Word

Checkliste neue MA

Planung der notwendigen Aktivitäten für eine erfolgreiche Einführung neuer Mitarbeiter

P02-3_Vorlage_

Definition einer IT-Stelle

MS Word

Definition der Jahresziele

MS Word

Evaluationsvorgehen P02-2_Vorlage_

Stellenbeschreibung P02-4_Vorlage_

269

G MIIP-Vorlagen Jahresziele P02-5_Vorlage_

eigene Kompetenzbewertung

MS Excel

Coaching aufsetzen

MS Word

Kompetenz Radar P02-6_Vorlage_ Coaching Vertrag P03 – IT- Standards & Architektur (2 Vorlagen) Name

Beschreibung

Format

P03-1_Vorlage_ITStandards

Dokument , um IT-Geräte und Komponente zu inventarisieren

MS Word

P03-2_Vorlage_

Dokument, um die Lebensdauer der ITSysteme zu planen

MS Excel

InfrastrukturRoadmap

P04 – IT-Financial Management (4 Vorlagen) Name

Beschreibung

Format

P04-1_Vorlage_

Vorbereitung der Budgetierung der IT Services

MS Excel

Vorbereitung der Budgetierung der ITProjekte

MS Excel

P043_Vorlage_Monatliches Reporting IT Services

Rapportierung der Kosten von IT Services

MS Excel

P044_Vorlage_Monatliches Reporting IT-Projekte

Rapportierung der IT-Projekte-Kosten

MS Excel

Budgetierung Services

der

IT

P04-2_Vorlage_ Budgetierung der ITProjekte

270

G MIIP-Vorlagen P05 – IT-Qualitätsmanagement (3 Vorlagen) Name

Beschreibung

P05-1_Vorlage_

Handbuch, um die Qualität Dienstleistungen zu erläutern

Format IT-

MS Word MS Word

Projekt-Audit

Dokument, um ein Projektaudit durchführen zu können.

P05-3_Vorlage_

Liste der Qualitätspendenzen

MS Word

Qualitätshandbuch P05-2_Vorlage_

der

Qualitätspendenzen P06 – IT-Projekt Portfolio Management (6 Vorlagen) Name

Beschreibung

Format

P06-1_Vorlage_ITProjekt Liste

Liste aller genehmigten Projekten und deren Stati, Kosten und Termine

MS Excel

P06-2_Vorlage_ITProjekt-Master Plan

Projekt, Ressourcen, Systemplanung

MS Excel

P06-3_Vorlage_

Dokument zur Festlegung der Projektmerkmale

MS Word

P06-4_Vorlage_ITProjektantrag

Erstellung des Projektantrags

MS Word

P06-5_Vorlage_

Dokument zur Festlegung der Projekt KPIs am Anfang eines Projektes

MS Word

Dokument zur Bewertung der ProjektPerformanz am Ende eines Projektes

MS Word

Fachkonzept

KPIs_Definition P06-6_Vorlage_ KPIs_Bewertung

P07 –Capacity / Availability Management(1 Vorlage) Name

Beschreibung

Format

P071_Vorlage_Capacity Interne MA.

File, in dem die IT interne Ressourcen nach IT Services und Projekten zusammengestellt werden

MS Excel

271

G MIIP-Vorlagen P08 – Continuity Management (3 Vorlagen) Name

Beschreibung

Format

P08-1_Vorlage_

Dokument zur Bewältigung von Krisen

MS Word

Dokument zur Bewältigung von Krisen für die IT-Organisation

MS Word

Plan der verschiedenen Test Aktivitäten im Rahmen des „Business Continuity Plan“

MS Excel

Bereichskrisenhandbuch P08-2_Vorlage_IT nhandbuch

Krise-

P08-3_BCP Testplan

P09 – Service-Management (3 Vorlagen) Name

Beschreibung

Format

P09-1_Vorlage_

Beschreibt die angebotenen ITDienstleistungen in Form von IT Services, inklusiv Preis pro Einheit

MS Word

P09-2_Vorlage_SLAsBereich-X

SLA zwischen IT und einem Fachbereich

MS Word

P09-3_Vorlage_ITMonatsbericht

Dieser Bericht beinhaltet das Reporting über die SLAs Messung.

MS Word

Service Katalog

P10 – Anforderungsmanagement (4 Vorlagen) Name

Beschreibung

Format

P10-1_Vorlage_ITAnforderung

Formular zur Abwicklung einer IT- Anforderung

MS Word

P10-2_Vorlage_

Formular zur Durchführung eines Kleinauftrags

MS Word MS Word

Aufwandschätzung

Aufwand- und Kostenschätzung einer ITAnforderung

P10-4_Vorlage_

Vorlage für die Erstellung von Offerten

MS Word

Kleinauftrag P10-3_Vorlage_

Offerteanfrage

272

G MIIP-Vorlagen P11 – Projektmanagement (7 Vorlagen) Name

Beschreibung

Format

P11-1_Vorlage_

Dokument, um ein Projekt zu initiieren

MS Word

Planungsunterlage

MS Excel

P11-3_Vorlage_Risiko Matrix

Matrix, um die Projektrisiken zu identifizieren und managen

MS Excel

P11-4_Vorlage_

Status eines IT-Projektes

MS PowerPoint MS Word

Schulungsstrategie

Definieren, wie Schulungen stattfinden werden

P11-6_Vorlage_

Vorlage, um Handbücher zu schreiben

MS Word

Dokument, wo die gesammelten Erfahrungen über das Projekt festgehalten werden

MS Word

Projekt Pflichtenheft P11-2_Vorlage_ Projektplan

Projekt Statusbericht P11-5_Vorlage_

Handbuch P11-7_ProjektAbschlussbericht

P12 – Release Management (5 Vorlagen) Name

Beschreibung

Format

P12-1_Vorlage_

Definierte Termine, wann geplante Releases jährlich stattfinden

MS Excel MS Excel

Release Detailplan

File, um ein Release in Detail planen zu können

P12-3_ReleaseTestplan

Testkonzept, um die Test Aktivitäten für ein Release zu definieren

MS Word

P12-4_ReleaseAbnahmeprotokoll

Protokoll zur Release Abnahme

MS Word

P12-5_ReleaseAbschlussbericht

Abschlussbericht eines Release

MS Word

Releaseplan P12-2_Vorlage_

273

G MIIP-Vorlagen P13 – Applikationsentwicklung (3 Vorlagen) Name

Beschreibung

Format

P13-1_Vorlage_

File, um die Anforderung eines ITProgramms festzuhalten

MS Word

File, um ein Programm zu dokumentieren

MS Word

File, um die Beschreibung und Durchführung eines Tests zu dokumentieren

MS Word

Programmspezifikation P13-2_Vorlage_ Programmbeschreibung P13-3_Vorlage_Testfall

P14 –IT-Betrieb & Konfiguration Management(3 Vorlagen) Name

Beschreibung

Format

P14-1_Vorlage_IT Application Liste

File, wo alle IT-Applikationen erscheinen

MS Excel

P14-2_Vorlage_

System Planung

MS Excel

Dokumentation zur Wartung und Überwachung eines IT-Systems

MS Word

System Plan P14-3_Vorlage_ITSystem Betriebshandbuch

P15 – IT Supplier Management (6 Vorlagen) Name

Beschreibung

Format

P15-1_Vorlage_

Dokument, um die Prinzipien zum Zulieferer Management festzuhalten

MS Word MS Word

Ausschreibung

Dokument, um Offerten bei Zulieferern zu holen

P15-3_Vorlage_

Wahl eines Zulieferers oder eines Produktes

MS Word

Beispiel eines Vertrages für den Kauf von SW Lizenzen

MS Word MS Word

Bewertung IT Berater

Dokument für die Selektion und Rekrutierung von IT-Beratern

P15-6_Vorlage_

Dokument für die Leistungsbewertung der

MS Word

Richtlinie-Zulieferer P15-2_Vorlage_

AusschreibungAuswertung P15-4_Vorlage_ Mustervertrag P15-6_Vorlage_

274

Be-

G MIIP-Vorlagen wertung IT Berater

selektierten IT-Berater

P16 – Incident Management (1 Vorlage) Name

Beschreibung

Format

P16-1_Vorlage_

Beschreibung der Incident-Bearbeitung via Ticket Handling

MS Word

Ticket-Bearbeitung

P17 – Problem Management (1 Vorlage) Name

Beschreibung

P17-1_Vorlage_

Methode zur Lösungsfindung

Problem-Lösung

Format Problemanalyse

und

MS Word

275