Lionel Pilorget MIIP: Modell zur Implementierung der IT-Prozesse
Lionel Pilorget
MIIP: Modell zur Implementierung de...
294 downloads
1211 Views
3MB Size
Report
This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form
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ȱ<ȱ1ȱMonat)ȱ
Unterȱ derȱ operativenȱ Ebeneȱ verstehtȱ manȱ dieȱ Umsetzungȱ vonȱ Zielenȱ inȱ konkreteȱ Leistungen.ȱ
Bildȱ9:ȱMIIPȬProzessabhängigkeitenȱaufȱoperativerȱEbeneȱ
WieȱinȱdemȱBildȱ9ȱdargestellt,ȱwirdȱzwischenȱfünfȱverschiedenenȱHaupttätigkeitenȱ aufȱoperativerȱEbeneȱunterschieden:ȱ – betrieblicheȱTätigkeitenȱ(sieheȱPfadȱȱ11):ȱdiesȱumfasstȱalleȱTätigkeiten,ȱwieȱ zumȱ Beispielȱ dieȱ Durchführungȱ einesȱ Backups,ȱ welcheȱ regelmäßigȱ durchȱ denȱITȬBetriebȱdurchgeführtȱwerden.ȱ – Einrichtenȱ vonȱ neuenȱ ITȬGerätenȱ (sieheȱPfadȱ12):ȱNeueȱGeräteȱwerdenȱalsȱ rollenderȱErsatzȱinȱBetriebȱgenommen.ȱ – Incidentsȱ amȱ Helpdeskȱ entgegenȱ nehmenȱ (sieheȱ Pfadȱ 13)ȱ dasȱ Helpdeskȱ nimmtȱdieȱCallsȱderȱAnwenderȱentgegenȱundȱbearbeitetȱdieȱIncidentȱTicketsȱ gemäßȱIncidentȱManagementȬProzess.ȱ – Anforderungȱ entgegenȱ nehmenȱ undȱ analysierenȱ (sieheȱPfadȱ14):ȱdieȱKunȬ denȱ meldenȱ ihreȱ Anforderungenȱ beiȱ demȱ Accountȱ Managementȱ an.ȱ Diesesȱ analysiertȱdieȱBedarfsanmeldungenȱundȱleitetȱdieseȱanȱdieȱrichtigeȱStelleȱinȬ nerhalbȱderȱITȬOrganisationȱweiter.ȱ
ȱ
27
3ȱȱProzessabhängigkeitenȱ – Systemsänderungenȱproduktivȱsetzenȱ(sieheȱPfadȱ15):ȱimȱRahmenȱvonȱReȬ leasesȱ oderȱ Projektenȱ werdenȱ Systemänderungenȱ aufȱ dasȱ Produktivsystemȱ durchgeführt.ȱ
28 ȱ
ȱ
DieȱZusammenarbeitȱzwischenȱderȱITȬOrganisationȱundȱdenȱFachbereichenȱistȱeinȱ Schlüsselerfolgsfaktorȱ fürȱdasȱUnternehmen.ȱ Einerseitsȱ stelltȱ manȱdadurchȱ sicher,ȱ dassȱ dasȱ Unternehmenȱ keinȱ Risikoȱ eingehtȱ (Virenattacke,ȱ Wissensverluste,ȱ usw.)ȱ undȱandererseitsȱmüssenȱdieȱBedürfnisseȱdesȱGeschäftsȱrichtigȱadressiertȱwerden,ȱ umȱdieȱWettbewerbsfähigkeitȱderȱOrganisationȱgewährleistenȱzuȱkönnen.ȱ DiesesȱZusammenspielȱzwischenȱFachȱundȱITȱwirdȱalsȱ„ITȱGovernance“ȱbezeichnet.ȱ Daȱ proȱ Prozessȱ Rollenȱ definiertȱ werden,ȱ sowohlȱ imȱ Businessȱ alsȱ auchȱ inȱ derȱ IT,ȱ ermöglichtȱdieȱKenntnisȱderȱITȬProzesseȱeineȱModellierungȱderȱITȱGovernance.ȱ
Bildȱ10:ȱAllgemeinesȱOrganisationsmodellȱ
Umȱ diesȱ zuȱ erreichen,ȱ werdenȱ zwischenȱ dreiȱ „klassischen“ȱ Unternehmenslevelsȱ unterschiedenȱ(sieheȱzumȱBeispielȱdieȱOrganisationstheorieȱvonȱH.ȱMintzberg):ȱ – Oberstesȱ Managementȱ (Teilȱ A):ȱaufȱdiesemȱLevelȱwirdȱ dieȱUnternehmensȬ strategieȱdefiniertȱundȱumgesetzt.ȱ – Mittleresȱ Managementȱ (Teilȱ B):ȱ dasȱ Mittlereȱ Managementȱ stelltȱ dasȱ FühȬ rungsorganȱ desȱ Unternehmensȱ dar.ȱ Dieȱ taktischeȱ Ebeneȱ wirdȱ dadurchȱ adȬ ressiert.ȱ
ȱ
29
4ȱȱITȱGovernanceȱundȱProzessrollenȱ – Mitarbeiterȱ (Teilȱ C):ȱ dieȱ Mitarbeiterȱ stellenȱ dieȱ Arbeitskraftȱ desȱ UnternehȬ mensȱ dar.ȱ Wichtigeȱ Faktorenȱ wieȱ Motivation,ȱ Unternehmenskultur,ȱ ErfahȬ rung,ȱFachwissenȱbeeinflussenȱstarkȱdieȱLeistungȱderȱeinzelnenȱMitarbeiter.ȱ Wieȱ inȱ derȱ Abbildungȱ 10ȱ wirdȱ eineȱ vierteȱ Kategorieȱ eingefügtȱ (sieheȱ Teilȱ D).ȱ Esȱ handeltȱsichȱumȱdieȱ„Technostruktur“,ȱd.h.ȱübergeordneteȱLeistungenȱwieȱFinanzȱ oderȱPersonal.ȱ
Bildȱ11:ȱAllgemeinesȱITȬOrganisationsmodellȱ
Dieȱ ITȬOrganisationȱ hatȱ dieȱ Herausforderung,ȱ adäquateȱ Antwortenȱ denȱ entspreȬ chendenȱZielgruppenȱanbietenȱzuȱmüssen.ȱInteressenskonflikteȱsindȱdabeiȱoftȱvorȬ programmiert.ȱ Währendȱ dieȱ Geschäftsleitungȱ zumȱ Beispielȱ dieȱ Informatikkostenȱ niedrigȱ haltenȱ möchte,ȱ möchtenȱ dieȱ einzelnenȱ Bereicheȱ fürȱ sichȱ inȱ dedizierteȱ ITȬ Systemeȱinvestieren.ȱ Oderȱ dieȱEinhaltungȱ vonȱ ITȬStandardsȱ wirdȱ einfachȱunmögȬ lich,ȱwennȱkeineȱstrengeȱDisziplinȱvonȱdenȱeinzelnenȱBereichenȱbetriebenȱwird.ȱ ȱ AufȱjederȱEbeneȱistȱesȱmöglich,ȱ„Rollen“ȱzuȱdefinieren.ȱEineȱRolleȱwirdȱentwederȱ vonȱ einerȱ einzelnenȱ Personȱ oderȱ vonȱ einerȱ Gruppeȱ wahrgenommen.ȱ Einȱ gutesȱ Rollenverständnisȱistȱwichtig.ȱDamitȱkannȱsichergestelltȱwerden,ȱdassȱeineȱPersonȱ inȱderȱjeweiligenȱOrganisationȱweiß,ȱwasȱvonȱihrȱerwartetȱwird.ȱEsȱermöglichtȱauchȱ eineȱ strukturierteȱ Kommunikation,ȱ daȱ dieȱ unabwendbarenȱ Interessenskonflikteȱ zwischenȱ denȱ definiertenȱ Rollenȱ stattfindenȱ undȱ nichtȱ zwischenȱ denȱ Individuen.ȱ Letztendlichȱistȱesȱnotwendig,ȱverschiedeneȱRollenȱzuȱdefinieren,ȱumȱdieȱerforderȬ
30 ȱ
4ȱȱITȱGovernanceȱundȱProzessrollenȱ lichenȱFunktionentrennungenȱgewährleistenȱzuȱkönnenȱ(aufȱEnglischȱ„Segregationȱ ofȱDuties“).ȱ Umȱ eineȱ gutȱ operierendeȱ Informatikorganisationȱ zuȱ erreichen,ȱ müssenȱ entspreȬ chendeȱRollenȱvonȱdenȱFachbereichenȱwahrgenommenȱwerden.ȱ AufȱderȱoberstenȱManagementebeneȱwerdenȱdreiȱRollenȱdefiniert:ȱ – dieȱGeschäftsleitungȱ(alsȱGLȱbezeichnet),ȱ – derȱCEO,ȱ – derȱBereichsleiter.ȱ ȱ Dieȱ Geschäftsleitungȱ beinhaltetȱ denȱ CEOȱ undȱ alleȱ Bereichsleiter.ȱ Währendȱ derȱ Bereichsleiterȱ alleinȱ fürȱ seinenȱ Bereichȱ entscheidenȱ darf,ȱ werdenȱ alleȱ „GLȬ relevanten“ȱGelegenheitenȱvonȱderȱentsprechendenȱGruppeȱentschieden.ȱ ȱ ImȱBereichȱ„mittleresȱManagement“ȱwerdenȱsiebenȱRollenȱdefiniert:ȱ – – – – – – –
InformationȱManager,ȱ Auftraggeber,ȱ Auftragnehmer,ȱ STCȱMitglieder,ȱ ReleaseȱControlȱBoard,ȱ Projektleiterȱ(Fach)ȱ ApplicationȱOwner.ȱ
Dieseȱ Rollenȱ sindȱ wichtigȱ beiȱ derȱ Abnahmeȱ undȱ Überwachungȱ derȱ ITȬ DienstleistungenȱundȱvorȱallemȱbeiȱderȱDurchführungȱvonȱSystemänderungenȱimȱ Bereichȱ„Implementierung“.ȱ AlsȱITȬAnwenderȱwerdenȱzweiȱRollenȱdefiniert:ȱ – KeyȬUser,ȱ – ITȬAnwender.ȱ ȱ Zusätzlichȱ werdenȱ vierȱ Rollenȱ angefügt,ȱ dieȱ denȱ Querschnittsfunktionenȱ desȱ UnȬ ternehmensȱentsprechen:ȱ – – – –
CFOȱ(ChiefȱFinanceȱOfficer),ȱ Finanzȱ&ȱControlling,ȱ Personalabteilung,ȱ QȬPrüfer.ȱ
Imȱ Restȱ derȱ Präsentationȱ werdenȱ dieseȱ vierȱ Rollenȱ demȱ „Oberstenȱ ManageȬ ment“ȱzugeordnet.ȱ
ȱ
31
4ȱȱITȱGovernanceȱundȱProzessrollenȱ ȱ
Bildȱ12:ȱMIIPȬProzessrollenȱBusinessȱ
ImȱBereichȱITȱwerdenȱsechsȱRollenȱaufȱderȱEbeneȱ„OberstesȱManagement“ȱberückȬ sichtigt:ȱ – – – – – –
CIO,ȱ LeiterȱServiceȱManagement,ȱ LeiterȱProjektȱPortfolioȱManagement,ȱ ITȬArchitekt,ȱ LeiterȱApplikationsentwicklung,ȱ ITȬBetriebsleiter.ȱ
AufȱderȱEbeneȱ„mittleresȱManagement“ȱwerdenȱvierȱITȬRollenȱdefiniert:ȱ – AccountȱManager,ȱ – ServiceȱManager,ȱ – ITȬProjektleiter,ȱ – ReleaseȱManager.ȱ AufȱderȱEbeneȱ„Mitarbeiter“ȱwirdȱzwischenȱsiebenȱITȬRollenȱunterschieden:ȱ – ApplicationȱExpert,ȱ – SystemȱOwner,ȱ – KonfigurationȱManager,ȱ
32 ȱ
4ȱȱITȱGovernanceȱundȱProzessrollenȱ – – – –
HelpdeskȱAgent,ȱ 2ndȱLevelȱSupport,ȱ ProblemȱOwner,ȱ TaskȱForceȬMitglieder.ȱ
ZusätzlichȱwerdenȱdreiȱSupportfunktionenȱhinzugefügt:ȱ – ITȱControlling,ȱ – ITȬSicherheitsbeauftragter,ȱ – ITȬQualitätsbeauftragter.ȱ Dieseȱwerdenȱunterȱ„OberstesȱManagement“ȱeingestuft.ȱ
Bildȱ13:ȱMIIPȬProzessrollenȬITȱ
ȱ
33
4ȱȱITȱGovernanceȱundȱProzessrollenȱ
SiebenȱRollenȱwurdenȱimȱGeschäftȱaufȱdieserȱEbeneȱdefiniert.ȱ Geschäftsleitungȱ – definiertȱdieȱFirmenstrategie,ȱ – genehmigtȱdieȱITȬStrategie,ȱ – erteiltȱAufträgeȱzurȱBudgetierungȱmitȱFestlegungȱderȱfinanziellenȱVorgaben,ȱ – genehmigtȱdasȱITȬBudget,ȱ – definiertȱdasȱBudgetplafondȱfürȱITȬInvestitionen,ȱȱ – genehmigtȱdieȱeinzelnenȱITȬInvestitionen,ȱ – entscheidetȱüberȱdieȱnotwendigeȱBCMȬMaßnahmen,ȱ – bewilligtȱdieȱentsprechendeȱMittelȱfürȱdieȱBCMȬMaßnahmen.ȱ CEOȱ – gibtȱvor,ȱüberȱwieȱvieleȱMitarbeiterȱdieȱinterneȱInformatikȱverfügenȱsoll.ȱ Bereichsleiterȱ – definiertȱ dieȱ Kritikalitätȱ derȱ Geschäftsprozesseȱ undȱ derȱ entsprechendenȱ InȬ formationssysteme,ȱ – bewertetȱ inȱ Zusammenarbeitȱ mitȱ demȱ Sicherheitsbeauftragtenȱ dieȱ identifiȬ ziertenȱRisiken,ȱ – definiertȱ inȱ Zusammenarbeitȱ mitȱ demȱ Sicherheitsbeauftragtenȱ dieȱ notwenȬ digenȱMaßnahmen,ȱumȱdieȱRisikenȱzuȱmindernȱoderȱsogarȱganzȱzuȱvermeiȬ den,ȱ – unterstütztȱ dieȱ Durchführungȱ derȱ Aktivitätenȱ (Schulung,ȱ Übungen,...)ȱ zurȱ MinderungȱderȱGeschäftsrisiken.ȱ ȱ Zusätzlichȱwerdenȱdieȱvierȱ„Querschnittsrollen“ȱanȱdieserȱStelleȱberücksichtigt.ȱ CFOȱ – definiertȱdieȱfinanziellenȱRichtlinienȱzurȱBewertungȱderȱvorgesehenenȱInvesȬ titionen.ȱ Finanzȱ&ȱControllingȱ – setztȱdieȱTermineȱundȱAbläufeȱfürȱdieȱBudgetierungȱunternehmensweit,ȱ – ermitteltȱdenȱStundensatz,ȱ – veranlasstȱdieȱZahlungȱderȱerhaltenenȱundȱgeprüftenȱexternenȱRechnungen,ȱ – eröffnetȱundȱschließtȱInnenaufträgeȱab.ȱ
34 ȱ
4.1 MIIP-Rollenbeschreibung „Oberstes Management“ Personalabteilung – setzt Personalrichtlinien unternehmensweit auf, – betreut die IT-Organisation, – begleitet Coaching und Weiterbildungsmaßnahmen. Q-Prüfer – definiert die durchzuführenden Audits (Ziel, Umfang, Vorgehensweise, Zeitrahmen, usw.), – führt die Audits durch, – stellt dem CIO die Ergebnisse zur Verfügung. Dafür wurden insgesamt neun Rollen im IT-Bereich definiert: CIO – definiert die IT-Strategie, – trifft “make-or-buy”-Entscheide bezüglich dem Sourcing von ITDienstleistungen, – definiert die IT-Organisation, – ist für den Personalbestand der IT-Organisation zuständig, – stellt sicher, dass die Organisation bereits operativ steht und dass jeder über die IT-Strategie orientiert wird, – stellt sicher, dass die IT-Strategie aktuell ist, – ist für den Review der IT-Strategie zuständig, – nominiert die Abteilungsleiter, – stellt sicher, dass die IT-Standards definiert sind, – prüft die Einhaltung der IT-Standards, – stellt sicher, dass die Plan- IT-Architektur umgesetzt wird, – stellt sicher, dass das IT-Budget zeitgerecht geliefert wird, – ist zuständig für die Einhaltung des genehmigten IT-Budgets, – legt die Qualitätsmerkmale für die zu erbringenden IT-Dienstleistungen fest, – trifft die entsprechenden Maßnahmen bei der Feststellung von Qualitätsmängeln, – stellt sicher, dass die definierten Qualitätsstandards eingehalten werden, – genehmigt die einzelnen IT-Investitionen zusammen mit der Geschäftsleitung. Leiter Service Management – definiert die zu erbringenden Services und deren Qualitätsmerkmale, – liefert die Inputs für die Ermittlung des IT-Betriebsbudgets, – stellt sicher, dass das vorgeschlagene Betriebsbudget den angebotenen Services und den unterschriebenen SLAs entspricht, – ist verantwortlich für die Einhaltung des Betriebsbudgets, – vereinbart die Services mit den Fachbereichen, – veröffentlicht den Service-Katalog.
35
4ȱȱITȱGovernanceȱundȱProzessrollenȱ ȱ LeiterȱITȬProjektȱPortfolioȱManagementȱ – verwaltetȱdasȱProjektportfolio,ȱ – stelltȱsicher,ȱdassȱsichȱdasȱInvestitionsvolumenȱstrategiekonformȱentwickelt,ȱ – liefertȱdieȱInputsȱfürȱdieȱErmittlungȱdesȱITȬProjektportfoliotbudgets,ȱ – beauftragtȱdasȱControllingȱfürȱdieȱEröffnungȱeinesȱInnenauftrags,ȱsobaldȱeinȱ neuesȱProjektȱgenehmigtȱwird,ȱ – istȱ verantwortlichȱ fürȱ dasȱ Projektportfoliobudgetȱ undȱ behältȱ jederzeitȱ denȱ Überblick,ȱ – nimmtȱdieȱProjekteȱinȱdasȱPortfolioȱauf,ȱdamitȱsieȱaktiviertȱwerden,ȱ – definiertȱ inȱ Zusammenarbeitȱ mitȱ denȱ InformationȬManagernȱ dieȱ ProjektleiȬ tungȱundȱdieȱProjektȱKPIs,ȱ – pflegtȱdenȱITȬMasterplanȱ(rollendeȱPlanung),ȱ – pflegtȱdieȱListeȱderȱProjekte,ȱwelcheȱinȱdasȱPortfolioȱaufgenommenȱwurden,ȱ – machtȱeineȱSchätzungȱderȱnotwendigenȱRessourcen.ȱ ITȬArchitektȱ – definiertȱdieȱITȬStandards,ȱ – definiertȱ dieȱ notwendigeȱ ITȬArchitektur,ȱ sowohlȱ fürȱ dieȱ ITȬApplikationenȱ sowieȱfürȱdieȱITȬBasisinfrastrukturȱ(Netzwerk,ȱPCs,ȱServers,ȱusw.)ȱ – pflegtȱdieȱInfrastrukturȬRoadmap,ȱumȱdieȱLebensdauerȱderȱITȬSystemeȱmaȬ nagenȱzuȱkönnen,ȱ – definiertȱ dieȱ Applikationsroadmapȱ undȱ stelltȱ sicher,ȱ dassȱ dieseȱ mitȱ allenȱ Partnernȱabgesprochenȱist.ȱ LeiterȱApplikationsentwicklungȱ – prüftȱ dieȱ Machbarkeitȱ derȱ ITȬAnforderungenȱ (Ressourcenplanung,ȱ AufȬ wandsschätzung),ȱ – nimmtȱdieȱSpezifikationȱab,ȱ – prüftȱdieȱQualitätȱderȱEntwicklungȱgemäßȱProgrammierungsrichtlinien,ȱ – stelltȱsicher,ȱdassȱdieȱDokumentationȱzurȱVerfügungȱgestelltȱwird.ȱ ITȬBetriebsleiterȱ – definiertȱdieȱBedürfnisseȱimȱBereichȱITȬInfrastrukturȱimȱRahmenȱderȱMittel–ȱ undȱKurzfristigenȱPlanung,ȱ – erstelltȱundȱpflegtȱdieȱInfrastrukturroadmapȱundȱbereitetȱggf.ȱdieȱnotwendiȬ genȱITȬProjekteȱvor,ȱ – prüftȱdieȱSystemverfügbarkeit,ȱ – stelltȱmitȱdenȱSystemȱOwnersȱsicher,ȱdassȱdieȱnotwendigeȱLeistungsfähigkeitȱ derȱITȬSystemeȱgewährleistetȱist,ȱ – erstelltȱBerichteȱundȱStatistiken,ȱ – istȱfürȱdieȱMessungȱderȱQualitätsmerkmaleȱzuständigȱ – stelltȱdieȱAktualitätȱundȱQualitätȱdesȱITȬWiederanlaufplansȱsicherȱundȱistȱfürȱ dieȱDurchführungȱdesȱITȬWiederanlaufsȱverantwortlich,ȱ
36 ȱ
4.1ȱȱMIIPȬRollenbeschreibungȱ„OberstesȱManagement“ȱ – leitetȱ Anforderungsfragenȱ vomȱ Problemȱ Managementȱ anȱ dasȱ Accountȱ MaȬ nagementȱweiter,ȱ – stelltȱdieȱRessourcenplanungȱfürȱdenȱITȬBetriebȱ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,ȱwelcheȱfürȱdenȱBetriebȱnotȬ wendigȱsindȱ(solangeȱdieseȱalsȱsolcheȱbudgetiertȱsind),ȱ – erstelltȱBestellanforderungen,ȱ – bestelltȱsämtlicheȱfürȱdenȱBetriebȱnotwendigeȱHW,ȱSWȱundȱDienstleistungen,ȱ dieȱimȱRahmenȱdesȱbewilligtenȱBetriebsbudgetsȱliegen,ȱ – bestelltȱ sämtliche,ȱ inȱ Abspracheȱ mitȱ demȱ Projektleiter,ȱ fürȱ dasȱ Projektȱ notȬ wendigenȱHWȱundȱSW,ȱ – stelltȱsicher,ȱdassȱimȱRahmenȱvonȱBetriebsaktivitätenȱbestellteȱHW,ȱSWȱoderȱ DienstleistungenȱdieȱITȬStandardsȱentsprechenȱ(Ausnahmenȱwerdenȱanȱdenȱ CIOȱweitergeleitet),ȱ – bewertetȱdieȱLeistungsqualitätȱderȱZulieferer,ȱ – sammeltȱ Erfahrungȱ überȱ Zuliefererȱ undȱ pflegtȱ eineȱ Shortȱ Listȱ derȱ ITȬ Zulieferer,ȱ – istȱfürȱdenȱreibungslosenȱITȬBetriebȱverantwortlich,ȱ – imȱ Fallȱ vonȱ Problemenȱ bestimmtȱ derȱ ITȬBetriebsleiterȱ dieȱ Vorgehensweiseȱ zurȱLösungȱundȱdieȱentsprechendenȱVerantwortlichkeiten.ȱ ITȱControllingȱ – stelltȱdasȱITȬBudgetȱzusammen,ȱ – istȱfürȱdieȱkorrekteȱKontierungȱderȱexternenȱRechnungenȱzuständigȱundȱersȬ telltȱdieȱITȬeigenenȱRechnungen,ȱ – unterstütztȱdenȱCIOȱinȱderȱÜberwachungȱderȱBudgeteinhaltung,ȱrapportiertȱ sichȱ abzeichnendeȱ Abweichungenȱ rechtzeitigȱ undȱ stelltȱ einenȱ Forecastȱ zurȱ Verfügung,ȱ – konsolidiertȱdieȱbudgetiertenȱITȬRessourcenȱfürȱBetriebȱundȱProjekte,ȱumȱeiȬ nenȱRessourceȱCheckȱdurchführenȱzuȱkönnenȱ(Sachaufwandȱkontraȱinterneȱ Ressourcen),ȱ – erstelltȱ dieȱ konsolidierteȱ Kapazitätsplanungȱ proȱ ITȬAbteilungȱ bezüglichȱ Manpower,ȱ – istȱzuständigȱfürȱdieȱAufwandserfassungȱ(erfassteȱStundenȱfürȱdieȱerbrachȬ tenȱServicesȱundȱdieȱdurchgeführtenȱProjekte),ȱ – stelltȱsicher,ȱdassȱVerträgeȱvorhandenȱundȱunterschriebenȱsind,ȱbevorȱBestelȬ lungenȱinȱAnspruchȱgenommenȱwerden,ȱ – lässtȱdieȱRichtigkeitȱderȱRechnungȱprüfen,ȱ – schicktȱgeprüfteȱRechnungenȱanȱdasȱRechnungswesenȱzurȱBegleichung.ȱ ȱ ȱ ȱ
ȱ
37
4ȱȱITȱGovernanceȱundȱProzessrollenȱ ITȬSicherheitsbeauftragterȱ – setztȱdieȱITȱSecurityȬStandardsȱfest,ȱ – stelltȱsicher,ȱdassȱdieseȱeingehaltenȱwerden,ȱ – definiertȱdieȱSicherheitsroadmap,ȱanalogȱInfrastruktur.ȱ ITȬQualitätsbeauftragterȱ – unterstütztȱdenȱCIOȱbeiȱderȱFestlegungȱderȱQualitätsmerkmale,ȱ – istȱzuständigȱfürȱdieȱOrganisationȱundȱPlanungȱvonȱinternenȱAudits,ȱ – stelltȱsicher,ȱdassȱdieȱgetroffenenȱMaßnahmenȱverwirklichtȱwerdenȱundȱdassȱ dieȱfestgestelltenȱQualitätsmängelȱeffektivȱadressiertȱwerden,ȱ – kontrolliert,ȱ dassȱ dieȱ SLsȱ definiert,ȱ vereinbart,ȱ gemessenȱ undȱ rapportiertȱ werden,ȱ – stelltȱ beiȱ SLAȬVerletzungȱ sicher,ȱ dassȱ dieȱ entsprechendenȱ Maßnahmen,ȱ geȬ mäßȱQualitätsmanagementȬProzess,ȱinȱdieȱWegeȱgeleitenȱwerden.ȱ
38 ȱ
4.1ȱȱMIIPȬRollenbeschreibungȱ„OberstesȱManagement“ȱ InȱderȱfolgendenȱTabelleȱsindȱdieȱProzesseȱidentifiziert,ȱinȱdenenȱdieȱentsprechenȬ denȱRollenȱ„OberstesȱManagement“ȱwahrgenommenȱwerdenȱsollen.ȱ Tabelleȱ4:ȱMIIPȱProzessrollenȱ„OberstesȱManagement“ȱ
P01ȱȱ
P02ȱȱ
P03ȱȱ
P04ȱȱ
P05ȱ
P06ȱ
P07ȱ
P08ȱȱ
P09ȱȱ
P10ȱ
P11ȱ
P12ȱȱ
P13ȱȱ
P14ȱ
P15ȱȱ
P16ȱȱ
P17ȱȱ
Rollenȱ GLȱ
xȱ
ȱ
ȱ
xȱ
ȱ
xȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
CEOȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
BereichsȬ leiterȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
CFOȱ
xȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
Finanzȱ &ȱ Controllingȱ
ȱ
ȱ
ȱ
xȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
Personalȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
QȬPrüferȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
CIOȱ
xȱ
xȱ
xȱ
xȱ
xȱ
xȱ
xȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
Serviceȱ Managerȱ
xȱ
ȱ
ȱ
xȱ
xȱ
ȱ
xȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
Projektȱ Portfolioȱ
xȱ
ȱ
ȱ
xȱ
xȱ
xȱ
xȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ITȱȬ Architektȱ
xȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ApplikatiȬ onsentwickȬ lerȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
BetriebsȬ leiterȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
xȱ
xȱ
xȱ
xȱ
ȱ
ȱ
ȱ
xȱ
xȱ
ȱ
xȱ
ITȱ ControlȬ lingȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
SicherheitsȬ beauftragterȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
QualitätsȬ beauftragterȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
39
4ȱȱITȱGovernanceȱundȱProzessrollenȱ
SiebenȱRollenȱwurdenȱimȱBusinessȱaufȱdieseȱEbeneȱdefiniert:ȱ InformationȱManagerȱ – priorisiertȱdieȱProjektideenȱimȱRahmenȱderȱKurzfristplanung,ȱ – setztȱProjekteȱauf.ȱ Auftraggeberȱ – formuliertȱdieȱAnforderungenȱseitensȱFachbereich,ȱ – stelltȱdenȱBusinessȱCaseȱzusammen,ȱ – gibtȱdieȱAnforderungenȱinȱFormȱeinesȱAuftrags,ȱ – prüft,ȱobȱdieȱAnforderungenȱkorrektȱdurchgeführtȱwurden.ȱ Auftragnehmerȱ – bestelltȱdieȱITȬServicesȱundȱunterschreibtȱdieȱentsprechendenȱSLAs,ȱ – wirdȱüberȱdieȱEinhaltungȱdesȱServiceȱLevelsȱregelmäßigȱinformiert.ȱ 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ȱProȬ jektphasenȱverantwortlich,ȱ – sindȱdieȱEskalationsinstanzȱfürȱalleȱSituationen,ȱinȱdenenȱdieȱErreichungȱderȱ ProjektzieleȱdurchȱgeänderteȱRahmenbedingungenȱgefährdetȱist.ȱ ReleaseȱControlȱBoardȱ – hatȱeineȱzentraleȱFunktionȱwieȱeinȱSteeringȱCommitteeȱfürȱeinȱProjekt,ȱ – priorisiert,ȱbewilligtȱdenȱInhalteȱderȱReleasesȱundȱÄnderungen,ȱ – gibtȱdieȱReleaseȬEinführungȱfrei,ȱ – fürȱ einenȱ FixȬReleaseȱ kann/mussȱ derȱ Vorsitzendeȱ desȱ RCBȱ dieȱ Änderungȱ freigeben.ȱ Projektleiterȱ(Fach)ȱ – 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,ȱ – rapportiertȱ regelmäßigȱ ProjektȬStatusȱ undȱ Projektkostenȱ anȱ denȱ ITȬProjektȱ PortfolioȱManager.ȱ ApplicationȱOwnerȱ – nimmtȱdieȱAnforderungȱentgegenȱundȱanalysiertȱdiese,ȱ – stelltȱdieȱPriorisierungȱsicher,ȱ – stelltȱ sicher,ȱ dassȱ allfälligeȱ Dokumentationȱ (Handbücher,ȱ Weisungen,…),ȱ wennȱnotwendig,ȱangepasstȱwird,ȱ
40 ȱ
4.2ȱȱMIIPȬRollenbeschreibungȱ„ȱMittleresȱManagement“ȱ – gewährleistetȱeinenȱgutenȱAusbildungsstandȱbeiȱdenȱAnwendernȱundȱsorgtȱ fürȱdenȱnotwendigenȱKnowȬhowȬTransfer,ȱ – informiertȱdieȱUserȱüberȱvorgenommeneȱApplikationsänderungen.ȱ ȱ DafürȱwurdenȱaufȱdieserȱEbeneȱvierȱRollenȱimȱITȱBereichȱdefiniert:ȱ AccountȱManagerȱ – unterstütztȱdenȱAuftraggeberȱbeiȱderȱFormulierungȱderȱAnforderungenȱundȱ beimȱErrechnenȱdesȱBusinessȱCase,ȱ – identifiziertȱBedürfnisseȱfürȱneueȱServices,ȱ – informiertȱdieȱKundenȱüberȱdieȱQualitätȱderȱServices,ȱvorȱallenȱdieȱAuftragȬ nehmerȱüberȱmöglicheȱSLȬVerletzungen,ȱ – nimmtȱdieȱAnforderungenȱentgegenȱundȱerstelltȱeinenȱAuftrag,ȱ – analysiertȱ dieȱ Anforderungenȱ undȱ prüft,ȱ obȱ sieȱ imȱ Rahmenȱ derȱ ITȬ Servicepaletteȱabgedecktȱsind,ȱ – prüftȱdenȱAufwandȱdankȱeinerȱAufwandsschätzung,ȱ – wennȱ nötig,ȱ leitetȱ dieȱ Anforderungȱ weiter,ȱ entwederȱ zumȱ Portfolioȱ ManaȬ gementȱoderȱReleaseȱManagement.ȱ ServiceȱManagerȱ – istȱfürȱdieȱDefinition,ȱMessungȱundȱEinhaltungȱderȱServiceȱLevelsȱzuständig.ȱ ITȬProjektleiterȱ – istȱverantwortlichȱfürȱdieȱPlanungȱundȱLenkungȱderȱtechnischenȱProjektmiȬ tarbeiter,ȱeineȱsachgerechteȱUmsetzungȱderȱBenutzeranforderungenȱinȱtechȬ nischeȱ Lösungenȱ undȱderenȱ Überführungȱ inȱ dieȱ definitiveȱProduktionsumȬ gebung,ȱ – 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ȱDienstȬ leistungenȱ denȱ ITȬStandardsȱ entsprechen.ȱ (Ausnahmenȱ werdenȱ vonȱ demȱ CIOȱgenehmigt),ȱȱ – bewertetȱdieȱLeistungsqualitätȱderȱZulieferer,ȱ – sammeltȱ Erfahrungȱ überȱ Zuliefererȱ undȱ pflegtȱ eineȱ Shortȱ Listȱ derȱ ITȬ Zulieferer.ȱ
ȱ
41
4ȱȱITȱGovernanceȱundȱProzessrollenȱ 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ȱ notȬ wendigenȱSchritte,ȱ – vermitteltȱdieȱAufträge,ȱ – koordiniertȱdieȱReleaseȬPlanungȱmitȱderȱDetailplanungȱfürȱdieȱvorgeseheneȱ Entwicklungȱ(Aktivitätenȱ+ȱRessourcen),ȱ – beiȱeinemȱFixȬReleaseȱinformiertȱderȱReleaseȱManagerȱdenȱProblemȱOwner,ȱ umȱsicherzustellen,ȱdassȱdasȱProblemȱeffektivȱgelöstȱist.ȱ ȱ InȱderȱfolgendenȱTabelleȱsindȱdieȱProzesseȱidentifiziert,ȱinȱdenenȱdieȱentsprechenȬ denȱRollenȱ„MittleresȱManagement“ȱwahrgenommenȱwerdenȱsollen.ȱ Tabelleȱ5:ȱMIIPȬProzessrollenȱ„MittleresȱManagement“ȱ
P01ȱȱ
P02ȱȱ
P03ȱȱ
P04ȱȱ
P05ȱȱ
P06ȱȱ
P07ȱ
P08ȱȱ
P09ȱȱ
P10ȱȱ
P11ȱ
P12ȱȱ
P13ȱȱ
P14ȱȱ
P15ȱȱ
P16ȱȱ
P17ȱȱ
Rollenȱ Informationȱ Managerȱ
ȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
AuftragȬ geberȱ
ȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
AuftragȬ nehmerȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
STCȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
RCBȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
ȱ
Projektleiterȱȱ
ȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
Applicationȱ Ownerȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
Accountȱ Managerȱ
ȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
xȱ
xȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ServiceȱMgtȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ITȬ Projektleiterȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
xȱ
xȱ
xȱ
ȱ
ȱ
ReleaseȱMgtȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
xȱ
xȱ
xȱ
ȱ
ȱ
ȱ
ȱ
42 ȱ
4.3ȱȱMIIPȬRollenbeschreibungȱ„ȱMitarbeiter“ȱ
ZweiȱRollenȱwurdenȱimȱBusinessȱaufȱdieserȱEbeneȱdefiniert:ȱ KeyȬuserȱ – machtȱeinȱReviewȱderȱSpezifikation,ȱ – erstelltȱdieȱTestfälle,ȱ – stelltȱdieȱfachlicheȱAbnahmeȱdankȱderȱDurchführungȱderȱSystemtestsȱsicher,ȱ – führtȱdieȱIntegrationȱTestsȱdurch,ȱ – gibtȱdasȱOKȱfürȱdasȱEndeȱderȱEntwicklung.ȱ ITȬAnwenderȱ – stelltȱeineȱAnforderungȱzusammen,ȱumȱeinȱBusinessȬBedürfnisȱabzudecken,ȱ – prüft,ȱobȱdasȱBedürfnisȱkorrektȱadressiertȱwurde,ȱ – meldetȱStörungen,ȱ – nimmtȱdieȱLösungenȱab.ȱ ȱ DafürȱwurdenȱaufȱdieserȱEbeneȱsiebenȱRollenȱimȱITȱBereichȱdefiniert:ȱ ApplicationȱExpertȱ – prüftȱdenȱITȬAuftragȱaufȱVerständlichkeitȱundȱVollständigkeit,ȱ – berät,ȱ – erstelltȱ eineȱ Aufwandsschätzungȱ undȱ schlägtȱ eineȱ Detailplanungȱ (AktivitäȬ tenȱ+ȱRessourcenverfügbarkeit)ȱvor,ȱ – definiertȱdasȱlogischeȱDatenmodell,ȱ – erstelltȱdieȱSpezifikation,ȱ – programmiertȱoderȱparametrisiertȱundȱführtȱProdukttestsȱdurch,ȱ – unterstütztȱ beiȱ derȱ Durchführungȱ derȱ Integrationȱ Tests,ȱ derȱ Abnahmetestsȱ undȱderȱSchulungen,ȱ – dokumentiertȱdieȱProgrammeȱundȱdieȱKonfigurationselemente.ȱ SystemȱOwnerȱ – prüftȱdieȱSystemverfügbarkeit,ȱ – stelltȱ mitȱ demȱ Betriebsleiterȱ zusammenȱ sicher,ȱ dassȱ dieȱ notwendigeȱ LeisȬ tungsfähigkeitȱderȱITȬSystemeȱgewährleistetȱist,ȱ – prüftȱdieȱPlanungȱ(ProjekteȱundȱReleases)ȱbezüglichȱSystemȬPlanung,ȱ – stelltȱdieȱInfrastrukturȱzurȱVerfügung,ȱ – setztȱdieȱSystemänderungenȱproduktivȱum,ȱ – sorgtȱdafür,ȱdassȱdieȱnotwendigenȱSystemeȱ(z.B.ȱEntwicklungssystemeȱoderȱ Testsysteme)ȱdemȱProjektȱzurȱVerfügungȱgestelltȱwerden,ȱ – betreibtȱdasȱITȬSystemȱundȱüberwachtȱvorȱallemȱbeiȱkritischenȱSystemenȱdieȱ Systemstabilitätȱ (Anzahlȱ ungeplanterȱ Unterbrechungen)ȱ undȱ dasȱ SystemȬ verhaltenȱ(Antwortzeit,ȱSpeicherkapazität,ȱ...),ȱ – meldetȱEinkaufsbedarfȱbeimȱBetriebsleiter,ȱ
ȱ
43
4ȱȱITȱGovernanceȱundȱProzessrollenȱ – überwachtȱdieȱSystemstabilität,ȱ – liefertȱdieȱeffektivenȱWerteȱzuȱtechnischenȱMessgrößenȱderȱSLAs,ȱ – nimmtȱdieȱgeliefertenȱGeräteȱentgegen,ȱ – prüftȱdieȱVollständigkeitȱundȱdieȱQualitätȱderȱAnlage,ȱ – machtȱVorȬInstallationenȱundȱentsprechendeȱTestarbeiten,ȱ – installiertȱdieȱgelieferteȱAusrüstungȱundȱnimmtȱdieseȱinȱBetrieb.ȱ KonfigurationȱManagerȱ – nimmtȱdieȱAnforderungenȱfürȱSystemȬÄnderungȱentgegen,ȱ – plantȱdieȱSystemȬÄnderungenȱ(SystemȱPlan),ȱ – aktualisiertȱ dieȱ Konfigurationsdatenȱ nachȱ derȱ Durchführungȱ einerȱ ÄndeȬ rung.ȱ HelpdeskȱAgentȱ – nimmtȱdenȱCallȱentgegen,ȱ – erfasstȱdasȱCallȱTicket,ȱleistetȱersteȱHilfeȱundȱschließtȱTicket,ȱ – beiȱStörungenȱkreiertȱerȱeinȱIncidentȱTicketȱundȱleitetȱesȱweiter,ȱ – leitetȱ Anforderungsfragenȱ vomȱ Incidentȱ Managementȱ anȱ dasȱ Accountȱ MaȬ nagementȱweiter,ȱ – meldetȱdieȱAnforderungȱzuȱPaketierungȱvonȱClientȱSW.ȱDieȱschonȱpaketierteȱ SWȱwerdenȱautomatischȱzugeteilt.ȱ 2ndȱLevelȱSupportȱ – nimmtȱdenȱIncidentȱentgegenȱundȱlöstȱdieȱStörung,ȱgemäßȱTicketȬPriorität,ȱ – beiȱkomplexerȱStörungȱerstelltȱerȱeinȱProblemȬTicket,ȱ – informiertȱdenȱUserȱüberȱdenȱTicketstatus,ȱ – schließtȱdasȱIncidentȱTicket.ȱ ProblemȱOwnerȱ – analysiertȱeinenȱProblemfallȱundȱbietetȱeineȱLösungȱan,ȱ – hatȱ währendȱ desȱ ganzenȱ Problemlösungszyklusȱ dieȱ Führungȱ fürȱ dieȱ ProbȬ lemlösung,ȱ – stelltȱeineȱTaskforceȱzusammen,ȱkoordiniertȱdieȱTaskȬMitglieder,ȱinformiertȱ undȱeskaliert,ȱ – istȱ verantwortlich,ȱ dassȱ dasȱ Problemȱ innertȱ nützlicherȱ Fristȱ gelöstȱ undȱ imȬ plementiertȱ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.ȱ – fallsȱ einȱ FixȬReleaseȱ notwendigȱ ist,ȱ erstelltȱ erȱ eineȱ Anforderungȱ anȱ dasȱ ReȬ leaseȱManagement.ȱ TaskȱForceȬMitgliedȱ – stehtȱfürȱdieȱLösungȱeinesȱProblemsȱzurȱVerfügung,ȱdaȱoftȱinterdisziplinäreȱ Aktivitätenȱnotwendigȱsind.ȱ
44 ȱ
4.3ȱȱMIIPȬRollenbeschreibungȱ„ȱMitarbeiter“ȱ InȱderȱfolgendenȱTabelleȱsindȱdieȱProzesseȱidentifiziert,ȱinȱdenenȱdieȱentsprechenȬ denȱRollenȱ„Mitarbeiter“ȱwahrgenommenȱwerdenȱsollen.ȱ Tabelleȱ6:ȱMIIPȬProzessrollenȱ„Mitarbeiter“ȱ
P01ȱ
P02ȱȱ
P03ȱȱ
P04ȱȱ
P05ȱȱ
P06ȱȱ
P07ȱȱ
P08ȱȱ
P09ȱȱ
P10ȱȱ
P11ȱȱ
P12ȱ
P13ȱȱ
P14ȱ
P15ȱȱ
P16ȱȱ
P17ȱȱ
Rollenȱ KeyȬUserȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
xȱ
xȱ
ȱ
ȱ
ȱ
ȱ
ITȬ Anwenderȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ApplicaȬ tionȱExpertȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
xȱ
xȱ
ȱ
ȱ
ȱ
ȱ
Systemȱ Ownerȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
xȱ
xȱ
xȱ
xȱ
xȱ
xȱ
ȱ
xȱ
KonfiguȬ rationȱ MaȬ nagerȱȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
Helpdeskȱ Agentȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
xȱ
ȱ
xȱ
ȱ
2ndȱ Levelȱ Supportȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
Problemȱ Ownerȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
ȱ
ȱ
xȱ
TaskȱForceȬ Mitgliederȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
ȱ
xȱ
ȱ
ȱ
45
4ȱȱITȱGovernanceȱundȱProzessrollenȱ
InȱderȱfolgendenȱAbbildungȱsindȱdieȱBusinessȱundȱITȬRollenȱjeȱnachȱProzessȱdarȬ gestellt.ȱ
Bildȱ14:ȱBusinessȱ&ȱITȬProzessrollenȱ
Anȱ dieserȱ Stelleȱ wirdȱ deutlich,ȱ dassȱ fastȱ alleȱ Prozesseȱ sowohlȱ Rollenȱ imȱ FachbeȬ reichȱalsȱauchȱimȱITȱbrauchen,ȱumȱoptimalȱlaufenȱzuȱkönnen.ȱDieȱvierȱAusnahmenȱ sind:ȱ P03ȱȬȱITȱStandardsȱ&ȱArchitekturȱ DieȱITȱStandardsȱwerdenȱvonȱderȱInformatikȱvorgegeben.ȱDasȱtechnischeȱ WissenȱundȱdieȱBeurteilungȱderȱNutzungȱneuerȱInformationstechnologienȱ werdenȱimȱITȱangesiedelt.ȱ P07ȱȬȱCapacityȱ/ȱAvailabilityȱManagementȱ EsȱgehtȱinȱersterȱLinieȱdarum,ȱdieȱITȬRessourcenȱzuȱplanenȱundȱzurȱVerfügungȱ zuȱstellen.ȱDiesȱistȱwiederumȱAufgabeȱderȱInformatik.ȱ
46 ȱ
4.4ȱȱProzessrollenübersichtȱ P14ȱ–ȱITȬBetriebȱ&ȱKonfigurationȱManagementȱ Esȱmussȱgewährleistetȱwerden,ȱdassȱdieȱSystemeȱstabilȱlaufen.ȱDafürȱwerdenȱ unterschiedlicheȱÜberwachungstoolsȱaufgesetzt.ȱDieȱITȬOrganisationȱhatȱdieȱ HoheitȱüberȱdieseȱAktivitäten.ȱ P17ȱȬȱProblemȱManagementȱ BeimȱProblemȱManagementȱgehtȱesȱdarum,ȱtechnischeȱStörungenȱzuȱanalysieȬ renȱundȱLösungenȱzuȱimplementieren.ȱDiesȱwirdȱprimärȱvonȱderȱInformatikȱ gewährleistet.ȱ ȱ Dieȱ Gestaltungȱ derȱ Beziehungenȱ zwischenȱ denȱ Fachbereichenȱ undȱ derȱ ITȬ OrganisationȱistȱsicherȱvonȱderȱUnternehmenskulturȱabhängig.ȱUmȱdiesesȱplakativȱ darzustellen,ȱ kannȱ dieseȱ Beziehungȱ sehrȱ hierarchischȱ undȱ zentralistischȱ gestaltetȱ werdenȱ oderȱimȱ Gegenteilȱsehrȱ dezentralȱundȱ„demokratisch“.ȱ Esȱistȱ sicherȱ wünȬ schenswert,ȱeinȱMittelmaßȱzuȱfinden,ȱumȱeinerseitsȱdieȱgutenȱIdeenȱundȱErfahrunȬ genȱ derȱ Basisȱ aufzuwertenȱ undȱ anderseitsȱ dieȱ Initiativenȱ zuȱ fokussierenȱ undȱ dasȱ ZerstreuenȱderȱRessourcenȱzuȱvermeiden.ȱ ȱ Nebstȱ derȱ Frageȱ derȱ Rollenȱ fürȱ dieȱ ITȬProzesseȱ bleibtȱ nochȱ derȱ Punktȱ offen,ȱ wieȱ eineȱ ITȬOrganisationȱ zuȱ gestaltenȱ ist.ȱ Umȱ dieseȱ Frageȱ zuȱ beantworten,ȱ werdenȱ unterschiedlicheȱAspekteȱberücksichtigt:ȱ HauptrollenȱimȱVergleichȱzuȱZweitrollenȱundȱderenȱBindungȱ Beiȱ derȱ Beschreibungȱ derȱ Rollenȱ erscheinenȱ mancheȱ Aufgabenȱ alsȱ sehrȱ generischȱ undȱgewissermaßenȱuniversal,ȱwährendȱweitereȱFunktionenȱsichȱalsȱbedingtȱdurchȱ gewisseȱ Situationenȱ erwiesen.ȱȱ Esȱistȱ dannȱ möglichȱ dieȱWichtigkeitȱ derȱ Rollenȱzuȱ differenzierenȱundȱRollengruppenȱzuȱbilden.ȱEsȱistȱzumȱBeispielȱmöglich,ȱdieȱzweiȱ folgendenȱGruppenȱzuȱbilden:ȱ ȱ SystemȱOwner (Hauptrolle)ȱ – 2ndȱLevelȱSupportȱ(Nebenrolle)ȱ – ȱProblemȱOwnerȱ(Nebenrolle)ȱ – ȱTaskȱ ForceȬMitgliederȱ (NebenȬ rolle)ȱ
Applikationsexperteȱ(Hauptrolle)ȱ – 2ndȱLevelȱSupportȱ(Nebenrolle)ȱ – ȱProblemȱOwnerȱ(Nebenrolle)ȱ – ȱTaskȱ ForceȬMitgliederȱ (NebenȬ rolle)
ȱ
ȱ
47
4ȱȱITȱGovernanceȱundȱProzessrollenȱ Rollenkombinationȱ GewisseȱRollenȱkönnenȱkombiniertȱwerden.ȱZumȱBeispiel:ȱ – ServiceȱManagerȱundȱAccountȱManager,ȱ – ITȬProjektleiterȱundȱReleaseȱManager,ȱ – Imȱ Allgemeinenȱ dasȱ ITȱ Managementȱ (Leiterȱ Serviceȱ Management,ȱ Leiterȱ ProjektȱPortfolioȱManagement,ȱITȬArchitekt,ȱLeiterȱApplikationsentwicklung,ȱ ITȬBetriebsleiter,ȱ ITȱ Controlling,ȱ ITȬSicherheitsbeauftragter,ȱ ITȬ Qualitätsbeauftragter)ȱ ȱ Funktionstrennungȱ DieȱFunktionstrennungȱmussȱgewährleistetȱwerden.ȱDiesȱbedeutet,ȱdassȱnichtȱalleȱ Rollenȱkombiniertȱwerdenȱkönnen.ȱZumȱBeispielȱistȱesȱzuȱvermeiden,ȱdieȱRolleȱdesȱ SystemȱOwnersȱmitȱderȱRolleȱdesȱApplikationȱExpertȱzuȱkumulieren.ȱDiesȱkönnteȱ dazuȱ führen,ȱ dassȱ Systementwicklungenȱ direktȱ imȱ Produktivsystemȱ stattfindenȱ würden,ȱohneȱdassȱeinȱKontrollmechanismusȱinȱAnspruchȱgenommenȱwird.ȱ EsȱistȱsicherȱauchȱvonȱVorteil,ȱwennȱITȬSicherheitȱundȱITȬBetriebȱgetrennteȱAufgaȬ benȱ bekommen.ȱ Damitȱ wirdȱ auchȱ sichergestellt,ȱ dassȱ dieȱ konzeptuelleȱ Arbeitȱ inȬ klusivȱQualitätssicherungȱundȱdieȱoperativenȱVerantwortungenȱgetrenntȱsind.ȱ Weiterhinȱ sollȱ dieȱ Rolleȱ desȱ Portfolioȱ Managersȱ getrenntȱ vonȱ derȱ Rolleȱ desȱ ITȬ Projektleitersȱsein.ȱ ȱ KumulationȱderȱRollenȱ Esȱ istȱ empfehlenswert,ȱ dassȱ jedeȱ Personȱ inȱ derȱ ITȬOrganisationȱ nichtȱ mehrȱ alsȱ 3ȱ Hauptrollenȱwahrnimmt.ȱDiesȱlässtȱsichȱnichtȱüberallȱeinrichten.ȱFallsȱaberȱmehreȬ reȱPersonenȱzuȱvieleȱRollenȱerfüllenȱmüssen,ȱgehtȱdieȱITȬOrganisationȱgrößereȱRiȬ sikenȱein.ȱSpätestensȱbeiȱeinemȱAbgangȱoderȱeinerȱAbsenzȱderȱkritischenȱRessource.ȱ ȱ GestaltungȱdesȱManagementȱTeamsȱ Dasȱ Zielȱ ist,ȱ dieȱ Organisationȱ schlankȱ zuȱ halten.ȱ Diesȱ giltȱ insbesondereȱ fürȱ dasȱ Managementȱ Team.ȱ Dieȱ Schwierigkeitȱ dortȱ liegtȱ inȱ derȱ Mengeȱ undȱ Vielzahlȱ derȱ Rollen.ȱ Achtȱ Rollenȱ (ohneȱ CIO)ȱ müssenȱ wahrgenommenȱ werden.ȱ Jeȱ nachȱ Größeȱ derȱITȱOrganisationȱundȱjeȱnachdem,ȱwelcheȱITȬDienstleistungenȱerbrachtȱwerdenȱ müssen,ȱkannȱdasȱManagementȱTeamȱzwischenȱ4ȱundȱ8ȱPersonenȱvariieren.ȱAnbeiȱ einȱmöglicherȱVorschlagȱmitȱ6ȱPersonen:ȱ – – – – –
48 ȱ
LeiterȱServiceȱManagement,ȱ LeiterȱProjektȱPortfolioȱManagement,ȱ LeiterȱApplikationsentwicklung,ȱ ITȬArchitektȱ/ȱITȬSicherheitsbeauftragter,ȱ ITȬBetriebsleiter,ȱ
4.4ȱȱProzessrollenübersichtȱ – ITȱControllingȱ/ȱITȬQualitätsbeauftragter.ȱ ȱ DasȱManagementȱTeamȱmussȱgutȱfunktionieren.ȱEineȱSummeȱvonȱEinzelkämpfernȱ istȱnichtȱinȱderȱLage,ȱdieȱGesamtleistungȱaufgrundȱderȱgroßenȱIntegrationȱderȱProȬ zesseȱzuȱerbringen.ȱ ȱ AufgrundȱdieserȱverschiedenenȱBetrachtungen,ȱistȱesȱmöglich,ȱeinȱgenerischesȱBildȱ derȱHauptrollenȱinȱderȱITȱOrganisationȱzuȱskizzieren:ȱ
Bildȱ15:ȱMIIPȱITȬHauptrollenȱ
EineȱletzteȱFrageȱbleibtȱnochȱoffen:ȱAnȱwenȱrapportiertȱderȱCIO?ȱInȱmehrerenȱOrȬ ganisationenȱ rapportiertȱ derȱ CIOȱ entwederȱ anȱ demȱ CFOȱ (Chiefȱ Financeȱ Officer)ȱ oderȱanȱdemȱLeiterȱ„CorporateȱServices“.ȱJeȱnachȱBedeutungȱderȱInformatikȱfürȱdieȱ nachhaltigeȱ Entwicklungȱ desȱ Unternehmensȱ istȱ esȱ empfehlenswert,ȱ denȱ CIOȱ alsȱ MitgliedȱderȱGeschäftsleitungȱzuȱnominieren.ȱDadurchȱwirdȱsichergestellt,ȱdassȱdieȱ BelangeȱimȱBereichȱInformationȬManagementȱdieȱrichtigeȱGewichtungȱbekommen.ȱ
ȱ
49
5 Funktionsgruppe „strategische Entscheidungsprozesse“ Die Funktionsgruppe „strategische Entscheidungsprozesse“ beinhaltet fünf Prozesse, – P01 - IT-Strategie, – P02 - HR Management, – P03 - IT-Standards & Architektur, – P04 - Financial Management, – P05 - Qualitätsmanagement, welche in diesem Kapitel ausführlich beschrieben werden. Aufgrund der Prozessabhängigkeiten ist es notwendig, vier weitere Prozesse zu betrachten: – P06 - IT-Projekt Portfolio Management, – P07 - Capacity / Availability Management, – P09 - Service Management, – P15 - Supplier Management. Die Beziehungen zu diesen vier Prozessen werden am Ende des Kapitels erläutert.
5.1 P01 – IT-Strategie-Prozess Die IT-Strategie stellt ein wichtiges Element dar, um die Ziele der IT-Organisation und ihre Daseinsberechtigung zu definieren. Effizienz, Kosten, erforderliche Qualität sind Grundmerkmale, die für eine IT-Organisation von großer Bedeutung sind. Als Folge dessen bietet der beiliegende Prozess die Möglichkeit, eine IT-Strategie zu definieren, zu verbreiten und anhand Bedürfnisse des Unternehmens zu bewerten.
5.1.1
Hauptaktivitäten „P01 – IT-Strategie“
Um den Prozess „IT-Strategie“ abwickeln zu können, sind die folgenden Schritte vorgesehen.
51
5 Funktionsgruppe „strategische Entscheidungsprozesse“
Tabelle 7: Hauptaktivitäten „P01 - IT-Strategie“
Hauptschritte
Beschreibung
IT-Strategie definieren und genehmigen
Die notwendigen IT-Dienstleistungen werden identifiziert, vor allem in Bereichen, wo die Firma von der IT abhängig ist. Basierend auf der Unternehmensstrategie wird die ITStrategie abgeleitet. Diese soll den Mehrwert der Informatik sicherstellen und die IT-Kosten optimieren.
IT-Strategie entwickeln und umsetzen
Das Umsetzen der IT-Strategie stellt eine wichtige Tätigkeit dar und bietet die Möglichkeit, Rahmenbedingungen für – die IT-Architektur und Standards, – die IT-Infrastruktur & entsprechende IT-Investitionen, – die Definition der IT-Services, – die Sourcing-Politik, zu definieren und aufzusetzen.
IT-Strategie kommunizieren und verbreiten
Gewisse IT-Dienstleistungen werden intern erbracht. In dem Fall soll jeder Mitarbeiter der IT-Organisation über die ITStrategie orientiert werden. Anderseits werden die Dienstleistungen von externen Providern in Anspruch genommen. Diese sollen auch überwacht werden.
IT-Strategie prüfen und überwachen
Viele Änderungen können Auswirkungen auf die ITStrategie haben: Änderung der Unternehmensstrategie, Fusion, Verkauf einer Einheit, Änderung bei externen Zulieferern, usw. Aus diesem Grund soll die IT-Strategie jährlich überprüft und wenn nötig angepasst werden.
52
5.1 P01 – IT-Strategie-Prozess
5.1.2
Rollen „P01 – IT-Strategie“
Um den IT-Strategie-Prozess am Leben zu halten, müssen folgenden Rollen wahrgenommen werden.
Business
Tabelle 8: Prozessrollen „P01 – IT-Strategie“
Geschäftsleitung – definiert die Firmenstrategie, – genehmigt die IT-Strategie. CFO – definiert die finanziellen Richtlinien zur Bewertung der vorgesehenen Investitionen. CIO – definiert die IT-Strategie, – trifft “make-or-buy”-Entscheide bezüglich dem Sourcing von ITDienstleistungen, – definiert die IT-Organisation, – stellt sicher, dass die Organisation bereits operativ steht und dass jeder über die IT-Strategie orientiert wird, – stellt sicher, dass die IT-Strategie aktuell ist, – ist für die Prüfung der IT-Strategie zuständig.
IT
IT-Architekt – definiert die IT-Standards, – definiert die notwendige IT-Architektur, sowohl für die ITApplikationen als auch für die IT-Basisinfrastruktur (Netzwerk, PCs, Servers,…). Leiter Projekt Portfolio Management – verwaltet das Projektportfolio, – stellt sicher, dass sich das Investitionsvolumen strategiekonform entwickelt. Leiter Service Management –
definiert die zu erbringenden Services und deren Qualitätsmerkmale.
53
5 Funktionsgruppe „strategische Entscheidungsprozesse“
5.1.3
Prozessbeschreibung „P01 – IT-Strategie“
Die folgende Abbildung zeigt den Ablauf des Prozesses mit den entsprechenden Prozessabhängigkeiten. An der Stelle wird es klar, dass dieser Prozess eine zentrale Rolle für die gesamte IT-Organisation spielt. Unternehmensstrategie
Definition der IT-Bedürfnisse
IT-Standards & Architektur
Rahmenbedingungen für IT-Architektur & Standards
Projekt Portfolio Management
Rahmenbedingungen für IT-Infrastruktur & Investments
IT Service Management
Rahmenbedingungen der IT-Services
Sourcing Prinzipien
IT HR Management
IT-Organisation
IT-Strategie kommunizieren
IT-Qualitätsmanagement
IT-Strategie überwachen
Ende Bild 16: Prozessbeschreibung „P01 - IT-Strategie“
54
Input Output Firmen-Strategie
Geschäftsleitung
IT-Strategie
CIO, Geschäftsleitung
Rahmenbedingungen für IT-Infrastruktur & Standards
CIO, IT-Architekt
Kriterien für IT-Investitionen
CIO, CFO Leiter Portfolio Managementt
Definition der IT-Dienstleistungen
CIO, Leiter Service Management
Auswahl der IT strategische Partners + Verträge
CIO
IT-Organigramm
Kommunikation
IT-Strategie Review IT BSC
CIO
CIO
CIO
5.2 P02 - HR Management-Prozess
5.2 P02 - HR Management-Prozess Der HR Management-Prozess dient dazu, dass die internen IT-Ressourcen verwaltet werden. Da im Bereich IT eine sehr dynamische technologische Entwicklung stattfindet, ist es besonders wichtig, wertvolle Mitarbeiter zu behalten und zu fördern. Im letzen Teil vom Kapitel wird zwischen vier Managementlevels unterschieden: 1. 2. 3. 4.
CIO: das Oberstes Managementlevel der IT-Organisation. In vielen Unternehmen gehört der CIO zu der Geschäftsleitung, IT Management: ein Abteilungsleiter ist typischerweise für mehrere ITTeams zuständig, IT mittleres Management: dieser Kreis beinhaltet die Gruppenleiter und die Projektleiter, IT-Mitarbeiter: hiermit sind alle IT-Mitarbeiter gekennzeichnet, die Ihre Entlohnung von dem Unternehmen bekommen und keine ManagementVerantwortung tragen.
55
5 Funktionsgruppe „strategische Entscheidungsprozesse“
5.2.1
Hauptaktivitäten „P02 – HR Management“
Vier Hauptschritte sind im Prozess definiert. Tabelle 9: Hauptaktivitäten „P02 - HR Management“
Hauptschritte
Beschreibung
IT-Aufbauorganisation definieren
Basierend auf der IT-Strategie wird der Entscheid „make-orbuy“ getroffen. Als Folge dessen wird die IT-Organisation definiert. Die Vorgabe der Geschäftsleitung bezüglich maximaler Anzahl Stellen im Bereich Informatik wird an dieser Stelle berücksichtigt. Mit internen Ressourcen sollen zum Beispiel die Grundleistungen erbracht werden. Betriebs- und Projekt-bezogene Spitzen sollen in Zusammenarbeit mit Externen gebrochen werden. Gleiches gilt für Know-how, bei dem keine kritische Größe erreicht wird.
Interne Ressourcen planen und einsetzen
Um die IT-Leistungen erbringen zu können, werden die ITRessourcen geplant und eingesetzt. Für die Projektarbeiten werden Leistungen und Preise durch interne Offerten vereinbart.
Interne Ressourcen weiterentwickeln
Da die IT-Technologien sich schnell erneuern, ist es wichtig, IT-Ressourcen weiterzuentwickeln. Einen wichtigen Aspekt stellt auch die Kenntnis der Geschäftsprozesse dar.
Leistung bewerten Um eine positive Weiterentwicklungsspirale optimal und fair gestalten zu können, werden die Leistungen der ITMitarbeiter regelmäßig bewertet. Folgende Prinzipien der modernen Organisationstheorien werden für die Definition der IT-Organisation verwendet: – Gleichgewicht zwischen den Abteilungen, – Teams haben zwischen 4 und 10 Mitarbeitern, – minimale Schnittstellen zwischen den Prozessen.
56
5.2 P02 - HR Management-Prozess
5.2.2
Rollen „ P02– HR Management “
Dieser Prozess ist nicht IT-spezifisch und entspricht dem normalen Ablauf bei der Entwicklung von Dienstleistungsorganisationen. In erster Linie spielt die Personalabteilung eine wichtige Rolle bei der Verwaltung und Betreuung des Personals. Tabelle 10: Prozessrollen „P02 – HR Management“
Business
CEO – gibt vor, über wie viele Mitarbeiter die interne Informatik verfügen soll. Personalabteilung – setzt Personalrichtlinien unternehmensweit auf, – betreut die IT-Organisation, – begleitet Coaching und Weiterbildungsmaßnahmen. CIO – trifft „make-or-buy“-Entscheidungen über das Sourcing der ITDienstleistungen, – definiert die IT-Organisation, – nominiert die Abteilungsleiter.
IT
IT-Management – definiert die Struktur der Abteilung und nominiert die Gruppenleiter, – plant die Ressourcen der Abteilung, überwacht seine Kosten, – rekrutiert neue Ressourcen, wenn nötig, – trägt die Architekturverantwortung. IT mittleres Management – definiert Verantwortungen und verteilt Aufgaben an die ITMitarbeiter, – definiert die für die entsprechenden Mitarbeiter zu realisierenden Ziele, – ist zuständig für die Weiterentwicklung der Mitarbeiter, – bewertet die erbrachten Leistungen. IT-Mitarbeiter – erfüllt die vorgegebenen Aufgaben (Betrieb und Projekt), – sorgt für die eigene Weiterbildung (Holschuld), – entwickelt und setzt die IT Prozessvorgaben um.
57
5 Funktionsgruppe „strategische Entscheidungsprozesse“
5.2.3
Prozessbeschreibung „P02 – HR Management “
Die folgende Abbildung zeigt den Ablauf des Prozesses mit den entsprechenden Prozessabhängigkeiten.
Input Output
ITStrategie
Bedarf an IT-Arbeitskraft
Vorgabe & Stellen IT-Strategie Sourcing
CEO CIO CIO
internes Stellenplafond
Capacity – Availability Management
Analyse des Anforderungsprofils + Organigramm
Staffing
nein
Kompetent ?
Organigramm CIO, Kapazität pro Gruppe IT-Management Funktionsbeschreibung Ressourcen-Plan Aufgaben-Zuteilung
IT-Management
Prüfung der Kompetenz
IT mittleres Management
Personal Auswertung
IT mittleres Management, IT-Mitarbeiter
ja
Selbst-Analyse
Unterstützung
Leistungserbringung
Leistungsbewertung
Weiterbildung, Coaching
IT-Aufgaben und Aktivitäten
IT-Mitarbeiter
Leistungsbeurteilung
IT (mittleres) Management IT-Mitarbeiter
Jahresziele
Ende
Bild 17: Prozessbeschreibung „P02 - HR Management“
58
IT (mittleres) Management IT-Mitarbeiter Personalabteilung
5.3 P03 – IT-Standards & Architektur-Prozess
5.3 P03 – IT-Standards & Architektur-Prozess Die IT-Strategie bildet die Basis, um die Ziele der Informatik zu definieren. Die Definition von IT-Standards und Architektur spielt eine wichtige Rolle, um die Erreichung der strategischen Ziele ermöglichen zu können, wie zum Beispiel: – die IT-Stückkosten senken oder mindestens bleiben stabil, – einheitliche Lösungen werden eingesetzt, – die Stabilität und Vorhersehbarkeit der Betriebs- und Entwicklungskosten sind gewährleistet, – die Verfügbarkeit von Wartungs- und Betriebs-Know-how ist sichergestellt, – die Sicherheit gegenüber möglichen Schadensfällen/Katastrophen und Eingriffen von Dritten wird wahrgenommen, – die Sicherheit im Design von Applikationen und Projekten (Komplexität und Risiken reduzieren, Modularisierung, inkrementelle Strategien) ist berücksichtigt, – reife Lösungen mit breiter Benutzerbasis werden eingesetzt. Eine mögliche Darstellung der IT-Infrastruktur richtet sich nach „Ebenen“ der ITSysteme:
Fachbereich
IT-Anwender
Applikationen & Services
Middleware
RZ2
IT
RZ1 Ressourcen (Storage)
Netzwerk
Bild 18: IT-Architektur-Darstellung
59
5 Funktionsgruppe „strategische Entscheidungsprozesse“ – – – – –
5.3.1
Netzwerk (Switches, Routers...) Ressourcen für Speicherkapazitäten (Datenspeicherung, Servers,...) Middleware (Autorisierung, Authentifizierung,...) Applikationen & Services IT-Anwender
Hauptaktivitäten „P03 – IT-Standards & Architektur“
Die Hauptaktivitäten des Prozesses werden anhand der Definition und Umsetzung einer IT-Architektur festgelegt. Tabelle 11: Hauptaktivitäten „P03 – IT-Standards & Architektur“
Hauptschritte
Beschreibung
Definition der ITStandards
Die IT-Standards werden definiert. Dies bedeutet, dass Projektkonzepte konform mit diesen IT-Standards sind, bzw. dass alle „Reparaturaktivitäten“ im Betrieb auch konform mit den IT-Standards sind. Ausnahmen müssen an der Stelle vom CIO genehmigt werden.
Planung der ITArchitektur
Die IT-Architektur wird definiert mit dem Ziel, eine zukünftige IT-Plattform für das ganze Unternehmen mit dem Zeithorizont von fünf Jahren vorzubereiten und eine Roadmap zu definieren.
IT-Architektur weiterentwickeln und bewerten
Im Rahmen der Mittelfristplanung werden alle ITArchitektur-relevanten Investitionen berücksichtigt und nach den Prioritäten behandelt. Regelmäßig werden durch Audits und Konzeptprüfungen die Einhaltung und Umsetzung der IT-Architektur und Standards bewertet.
60
5.3 P03 – IT-Standards & Architektur-Prozess
5.3.2
Rollen „P03 – IT-Standards & Architektur“
Dieser Prozess ist IT-spezifisch. Als Folge dessen sind die entsprechenden Rollen nur IT-Rollen. Tabelle 12: Prozessrollen „P03 - IT-Standards & Architektur“
CIO – – – –
definiert die IT-Strategie, stellt sicher, dass die IT-Standards definiert sind, prüft die Einhaltung der IT-Standards, stellt sicher, dass die Soll- IT-Architektur umgesetzt wird.
IT
IT-Architekt – definiert die IT Standards für HW und SW-Komponenten, – pflegt die Infrastruktur-Roadmap, um die Lebensdauer der ITSysteme managen zu können, – definiert die Applikationsroadmap und stellt sicher, dass diese mit allen Partnern abgesprochen worden ist. Sicherheitsbeauftragter – setzt die IT Security-Standards fest, – stellt sicher, dass die IT-Sicherheit-Standards eingehalten werden, – definiert die Sicherheit-Roadmap, analog Infrastruktur.
61
5 Funktionsgruppe „strategische Entscheidungsprozesse“
5.3.3
Prozessbeschreibung „P03 – IT-Standards & Architektur“
Die folgende Abbildung zeigt die drei Hauptschritte des Prozesses mit der entsprechenden Prozessabhängigkeit zu „P07 – Capacity / Availability Management“.
IT-Strategie
Input Output CIO
Capacity – Availability Management
IT-Strategie
Definition der IT-Standards IT-Standards
Plan der Soll-Architektur Zeithorizont: 3-5 Jahre
InfrastrukturRoadmap
IT-Architekt, Sicherheitsbeauftragter
IT-Architekt
ApplikationRoadmap
Bewertung der Architektur
(Solll - Ist Architektur, Geschäftsprozesse, Synergien, Richtlinien,...)
Konzept-Audits CIO Mittelfristige Planung
Ende
Bild 19: Prozessbeschreibung „P03 - IT-Standards & Architektur“
62
5.4 P04 - IT Financial Management-Prozess
5.4 P04 - IT Financial Management-Prozess Ziel des Financial Management-Prozesses ist, Informationen zur betriebswirtschaftlichen Planung und Steuerung der IT-Organisation zur Verfügung zu stellen. Der Prozess umfasst unter anderem die Budgetierung, Nachkalkulation, Verbuchung, Buchführung, Budgetüberwachung und interne Leistungsverrechnung. IT Financial Management stellt eine wichtige Drehscheibe dar, und stellt sicher, dass die „Züge“ in der richtigen Richtung fahren!
Corporate Controlling IT Financial Management IT Portfolio Management
IT Service Management
Bild 20: IT Financial Management als „Drehscheibe“
5.4.1
Hauptaktivitäten „P04– IT Financial Management“
Die Hauptaktivitäten im Bereich Financial Management sind anhand der Budgetierungsabwicklung definiert. Tabelle 13: Hauptaktivitäten „P04 – IT Financial Management“
Hauptschritte
Beschreibung
Budgetierung
Mit der Budgetierung der IT-Kostenstellen nach Vorgaben von Finanz und Controlling werden die für die Zielerreichung bereitzustellenden finanziellen Mittel in der vorgegebenen Struktur festgelegt.
Nachkalkulation
Die Nachkalkulation dient zur Überprüfung und Festlegung des IT-Stundensatzes. Die Informationen aus der ITAufwandserfassung werden entsprechend aufbereitet und an das betriebliche Rechnungswesen weitergeleitet.
63
5 Funktionsgruppe „strategische Entscheidungsprozesse“ Hauptschritte
Beschreibung
Auftragsauslösung
Vor Auftragsauslösung muss jeweils geklärt werden, ob das Budget vorhanden ist oder nicht.
RechnungskontDie entstandenen Kosten werden erfasst, kontrolliert und rolle / Buchfüh- kontiert, d.h. den einzelnen Innenaufträgen für IT-Betrieb rung oder IT-Projekte zugeordnet. Diese Erfassung bildet die Basis für den Ist/Soll-Vergleich und ermöglicht das Festlegen von Korrekturmaßnahmen. Weiter ist es möglich, zuverlässig und jederzeit einen Forecast zu erstellen. Interne Leistungs- Zu den Aufgaben der internen Leistungsverrechnung gehöverrechnung (ILV) ren das Festlegen der Verrechnungsmodalitäten und das Erstellen der IT-internen Rechnungen gemäß Vereinbarungen. Auswertung / Reporting
5.4.2
Monatlich werden die verschiedenen Reports (Kostenstellenrechnung, Erfolgsrechnung, Budgetvergleich etc.) miteinander abgeglichen. Halbjährlich und jährlich werden Vorjahresvergleiche (mehrjährig) erstellt.
Rollen “P04 – IT Financial Management”
Die entsprechenden Rollen sind nicht IT-spezifisch, sondern gelten für alle dienstleistungsorientierte Organisationen, die als Produkt einerseits “Services” und anderseits “Projektarbeit” verkaufen. Tabelle 14: Prozessrollen „P04 – IT Financial Management“
Business
Geschäftsleitung
64
– erteilt Aufträge zur Budgetierung mit Festlegung der finanziellen Vorgaben, – genehmigt das IT-Budget Finanz & Controlling – setzt die Termine und Abläufe für die Budgetierung unternehmensweit, – ermittelt den Stundensatz, – veranlasst die Zahlung der erhaltenen und geprüften externen Rechnungen.
5.4 P04 - IT Financial Management-Prozess CIO – stellt sicher, dass das IT-Budget zeitgerecht geliefert wird, – ist zuständig für die Einhaltung des genehmigten IT-Budgets. Leiter Service Manager – liefert die Inputs für die Ermittlung des IT-Betriebsbudgets, – stellt sicher, dass das vorgeschlagene Betriebsbudget den angebotenen Services und den unterschriebenen SLAs entspricht – ist verantwortlich für die Einhaltung des Betriebsbudgets.
IT
Portfolio Manager – liefert die Inputs für die Ermittlung des IT-Projekt Portfoliobudgets, – beauftragt das Controlling für die Eröffnung eines Innenauftrags, sobald ein neues Projekt genehmigt wird, – ist verantwortlich für das Projektportfolio-Budget und behält jederzeit den Überblick. IT Controlling – stellt das IT-Budget zusammen, – ist für die korrekte Kontierung der externen Rechnungen zuständig und erstellt die IT-eigenen Rechnungen, – unterstützt den CIO in der Überwachung der Budgeteinhaltung, rapportiert abzeichnende Abweichungen rechtzeitig und stellt ein Forecast zur Verfügung.
5.4.3
Prozessbeschreibung „P04 – IT Financial Management“
Die folgende Abbildung zeigt den Ablauf des Prozesses mit den entsprechenden Prozessabhängigkeiten. Es wurde zwischen den jährlichen Aktivitäten (wie typischerweise die Erstellung des Budgets), den laufenden Aufgaben (wie etwa die Kontierung der Rechnungen) und den monatlichen Abläufen unterschieden.
65
5 Funktionsgruppe „strategische Entscheidungsprozesse“
Budget Prozess
Input Output Budget-Vorgabe
Service Management
IT-Betriebsbudget
IT-Services IT-Betriebsbudget
jährlich
IT-ProjektBudget
nein
laufend
Nachkalkulation
Auftrag kreieren
Portfolio Manager, IT Controlling
CIO
IT-genehmigtes Budget
Geschäftsleitung
IT-Aufwände
IT Controlling
Stundesatz
Finanz & Controlling
Innenauftrag gefragt
Portfolio Manager
Innenauftrag kreiert
Externe Rechnungen
LeistungsVerrechnung interne IT Rechnung
Budgetüberwachung Analysen
Bank Controlling
bezahlte Rechnungen
IT Controlling, Finanz & Controlling
Buchungen
Finanz & Controlling IT Controlling
IT-Rechnung Reporting
Finanz & Controlling, IT Controlling
Maßnahmen, wenn nötig
Leiter Service Manager, Portfolio Manager
Ende
Bild 21: Prozessbeschreibung „P04 - IT Financial Management“
66
IT Controlling
genehmigt ?
ja
monatlich
IT-Projektbudget
IT-Budgetvorschlag
ZuliefererManagement
Leiter Service Manager
IT-Projekt Portfolio
Projekt Portfolio Management
Projekt Portfolio Management
Geschäftsleitung, Finanz & Controlling
5.5 P05 – IT-Qualitätsmanagement-Prozess
5.5 P05 – IT-Qualitätsmanagement-Prozess Der Prozess IT-Qualitätsmanagement soll sicherstellen, dass die von einem Kunden erwartete Qualität in der Tat geliefert wird. Qualitätssicherungskriterien bei den gelieferten Produkten oder Dienstleistungen werden definiert und gemessen. Dafür gelten die SLAs (Service Level Agreements) für die betriebsorientierten Dienstleistungen, während Projektqualitätsmerkmale vor, während und nach dem Projekt mit KPIs überwacht werden. Eine zweite Vorgehensweise bietet die Durchführung von Qualitätsaudits an, die man als Qualitätsprüfung bezeichnen kann. Der Zweck ist, eine definierte Dienstleistung sowohl formell als auch inhaltlich durch eine neutrale Instanz prüfen zu lassen.
5.5.1
Hauptaktivitäten „P05 – IT Qualitätsmanagement“
Die Qualität bezieht sich auf die gelieferten IT-Produkte. Die entsprechenden Dienstleistungen werden zwischen IT-Services und IT-Projekten getrennt. Die Grundsätze des Qualitätsmanagement gelten für beide Arten von Leistungen. Tabelle 15: Hauptaktivitäten „P05 – IT-Qualitätsmanagement“
Hauptschritte
Beschreibung
Definition der Qualitätsmerkmale für die zu erbringenden IT Dienstleistungen
Die Qualitätsmerkmale der IT-Dienstleistungen werden definiert, und zwar:
Messung und Überwachung der Qualität Prüfung der Qualität
– für IT-Services: SLs müssen pro Service definiert werden, messbar sein und gemessen werden. – für IT-Projekte: Die Qualitätsmerkmale der IT-Projekte richten sich nach den üblichen Projektmanagement-Zielen: in Budget, in Time, mit der entsprechenden Qualität! Aufgrund der definierten Qualitätsmerkmale wird die Qualität der IT-Leistungen gemessen. Wenn ein Qualitätsproblem festgestellt wird, z.B. SL Verletzung über 3 Monate nacheinander oder gravierende Probleme bei der Durchführung eines Projektes, findet ein Qualitätsaudit statt.
67
5 Funktionsgruppe „strategische Entscheidungsprozesse“ Hauptschritte
Beschreibung
Audits durchführen und Ergebnisse präsentieren
Ein Qualitätsaudit wird definiert und geplant, um die Ursachen des Qualitätsmangels zu analysieren und die angemessenen Maßnahmen zu entwerfen. Die Ergebnisse werden dem Management vorgelegt.
Externe Prüfungen In vielen Branchen werden externe Audits durchgeführt, um begleiten sicherzustellen, dass die Industriestandards eingehalten werden. Q- Maßnahmen definieren, umsetzen und überwachen
Basierend auf den Ergebnissen der externen Prüfungen und der durchgeführten Audits definiert das IT-Management die notwendigen Maßnahmen und stellt sicher, dass die festgestellten Qualitätsmängel effektiv adressiert werden.
Die ISO-Zertifizierung für IT-Organisationen stellt eine gute Basis dar, um die Qualitätsanforderung vieler Industrien zu erfüllen. Dennoch ist die ISOZertifizierung keine Garantie für die Einhaltung der vorgeschriebenen Richtlinien.
68
5.5 P05 – IT-Qualitätsmanagement-Prozess
5.5.2
Rollen „P05 – IT-Qualitätsmanagement“
Es ist wichtig, dass eine neutrale Instanz die Prüfung der Leistungen durchführt. Aus diesem Grund werden die folgenden Rollen definiert.
Business
Tabelle 16: Prozessrollen „P05 – IT -Qualitätsmanagement“
Q-Prüfer – definiert den durchzuführenden Audit (Ziel, Umfang, Vorgehensweise, Zeitrahmen...), – führt den Audit durch, – stellt dem CIO die Ergebnisse zur Verfügung. CIO – legt die Qualitätsmerkmale für die zu erbringenden ITDienstleistungen fest, – trifft die entsprechenden Maßnahmen bei der Feststellung von Qualitätsmangel, – stellt sicher, dass die definierten Qualitätsstandards eingehalten werden.
IT
IT-Qualitätsbeauftragter – unterstützt den CIO bei der Festlegung der Qualitätsmerkmale, – ist zuständig für die Organisation und Planung von internen Audits, – stellt sicher, dass die getroffenen Maßnahmen in die Tat umgesetzt werden und dass die festgestellten Qualitätsmängel effektiv adressiert werden. Service Manager – ist für die Definition, Messung und Einhaltung der Service Levels zuständig. Leiter Projekt Portfolio Management – ist für die Definition und Messung der Projekt-KPIs zuständig.
69
5 Funktionsgruppe „strategische Entscheidungsprozesse“
5.5.3
Prozessbeschreibung „P05 – IT-Qualitätsmanagement“
Die folgende Abbildung zeigt den Ablauf des Prozesses mit den entsprechenden Prozessabhängigkeiten, vor allem was die Abwicklung der IT-Produkte (Services & Projekte) anbelangt. ITStrategie
Vorgabe der Qualitätsmerkmale festlegen
Service Management
Messung und Überwachung der Qualität
Projekt Portfolio Management
Input Output IT-Strategie
CIO
Qualitätsmerkmale (SLAs, Projekt KPIs)
CIO, IT-Qualitätsbeauftragter
SL-Definition
Service Manager Portfolio Manager
Projekt KPIs SL-Messungen Projektbewertung SL-Verletzung
ja
Qualität ausreichend ?
Projekt Eskalation Audit Plan
nein
Prüfung: internes Audit durchführen
Externe Prüfungen
Service Manager Portfolio Manager IT-Qualitätsbeauftragter
Audit Durchführung
Prüfer
Prüfungsbericht
Prüfer
Maßnahmen definieren
Qualitätsmaßnahmen
CIO
Nachprüfung sicherstellen
Prüfung der Umsetzung
IT-Qualitätsbeauftragter
Prüfungsergebnisse präsentieren
Ende
Bild 22: Prozessbeschreibung „P05 - IT-Qualitätsmanagement“
70
Service Manager Portfolio Manager
5.6 Prozessabhängigkeiten „Strategische Entscheidungsprozesse“
5.6 Prozessabhängigkeiten „Strategische Entscheidungsprozesse“ Das folgende Bild zeigt die Prozessabhängigkeiten von den fünf im „Strategische Entscheidungsprozesse“ definierten Prozessen mit vier zusätzlichen Prozessen (Service Management, Supplier Management, Portfolio Management & Capacity / Availability Management).
FirmenStrategie
ServiceDefinition
Personal Abteilung
IT-Organisation
Strategie Qualitätsanforderung
Qualitätsmerkmale
Ziel Architektur Roadmaps
IT-Standards & Prinzipien
Architektur
Umsetzung der Strategie
Finanz & Controlling
Budget Investition
strategische Projekte KPIs Definition
Verfügbarkeit SL Qualität
ServiceKatalog
Service
Projekt KPIs
Financial
Rechnung
ITStellenplafond
Innenauftrag Anfrage Innenauftrag
ProjektListe
gemessene Projekt KPIs Service Level Verletzung
HR
ITStandards
Qualität Standards
Qualität
Organigramm
Betriebsbudget
Projektantrag
Projekt Portfolio Messung
ProjektKosten
interne Ressourcen
Capacity ITAvailabilty Infrastruktur
BetriebKosten
Rechnungstellung
Supplier
Bild 23: MIIP-Prozessabhängigkeiten „Strategische Entscheidungsprozesse“
Die folgende Tabelle gibt den Überblick über die Interaktionen zwischen den Prozessen.
71
5 Funktionsgruppe „strategische Entscheidungsprozesse“
5.6.1
Prozessabhängigkeit „P01 – IT-Strategie“
P01 – IT-Strategie
IT-Organisation Organigramm
P01 – IT-Strategie
IT-Standards und Prinzipien Zielarchitektur, Roadmaps
P01 – IT-Strategie
Qualitätsanforderung Qualitätsstandards
P01 – IT-Strategie
Umsetzung Strategie Strategische Projekte
P01 – IT-Strategie
Service-Definition Service-Katalog
P02 – HR Management P03 – IT-Standards und Architektur P05 – ITQualitätsmanagement P06 – Portfolio Management P09 – Service Management
Die IT-Strategie gilt als Führungsinstrument zur Steuerung der IT-Organisation, um Geschäftsziele durch gezielte Nutzung der IT zu erreichen. Aus der Tabelle ist es deutlich ersichtlich, wie die IT-Strategie als Prozess aufgesetzt mitwirkt: – Definition der notwendigen Services und deren Kosten Kernanforderungen nach Geschäftsbereichen, Vertriebskanälen – Definition der Investitionsstrategie, Diese betrachtet die IT-Investitionsentscheidungen eines Unternehmens, um den effektiven und effizienten Einsatz der IT-Ressourcen sicherzustellen – Definition der Qualitätsstandards, – Definition der Standards & Architektur Diese befasst sich mit dem Einsatz von Software zur Unterstützung von Geschäftsprozessen, z.B. Lagerhaltungssoftware oder Bürosoftware. Einerseits der Einsatz von Software zur Ertragssteigerung, z.B. CRM Software zur Kundenbindung und Verkaufsförderung, andererseits Software zum effizienteren Geschäftsbetrieb, z.B. SAP-Software für die Buchhaltung und das Personalmanagement. Ziel der Infrastrukturstrategie ist es, mit möglichst geringen Kosten eine hohe Rechenleistung, Performance und Bandbreite in einem Unternehmen zur Verfügung zu stellen. – Definition der Sourcing-Politik. Diese setzt sich mit der IT-Wertschöpfungskette in einem Unternehmen auseinander. Ziel der Sourcing-Strategie ist es, festzulegen, welche IT-Leistungen durch das Unternehmen selbst erstellt und welche eingekauft werden.
72
5.6 Prozessabhängigkeiten „Strategische Entscheidungsprozesse“
5.6.2
Prozessabhängigkeit „P02 – HR Management“
P02 – HR Management
IT-Organisation
P02 – HR Management
IT-Stellenplafond
P01 – IT-Strategie
Organigramm Interne Ressourcen
P07 – Capacity / Availability
Die Unternehmensregelungen bezüglich Personals gelten auch für die ITOrganisation.
5.6.3
Prozessabhängigkeit „P03 – IT Standards & Architektur“
P03 – IT-Standards & Architektur
IT-Standards und Prinzipien
P01 – IT-Strategie
Zielarchitektur, Roadmaps P03 – IT-Standards & Architektur
IT-Standards IT-Infrastruktur
P07 – Capacity / Availability
Die IT-Standards und die IT-Architektur werden direkt von der IT-Strategie abgeleitet, während die vorgeschriebene Architektur direkte Wirkungen auf dem Capacity / Availability Plan hat.
5.6.4
Prozessabhängigkeit „P04 – IT Financial Management“
P04 – Financial Management
Projekt-Liste
P04 – Financial Management
Projektantrag
P04 – Financial Management P04 – Financial Management
Budget Investition Projektantrag Anfrage Betriebskosten Betriebsbudget Rechnungsstellung Rechnung
P06 – Portfolio Management P06 – Portfolio Management P09 – Service Management P15 – Supplier Management
Das „transparent machen“ der IT-Kosten und die verursachergerechte Verrechnung von IT-Leistungen gehören zu den Standardanforderungen an ITDienstleister. Dabei ist es gleichgültig, ob diese als externe Unternehmen oder als interne Dienstleister tätig sind. Voraussetzung hierfür ist, eine strukturierte IT Service-Definition auf der Basis von SLAs. Über ein Kostenkalkulationsmodell
73
5 Funktionsgruppe „strategische Entscheidungsprozesse“ wird die Verbindung zwischen den Serviceleistungen und den Servicekosten hergestellt. Eine transparente, verursachergerechte Leistungsverrechnung kann nur dann erfolgreich umgesetzt und gesteuert werden, wenn zwei Voraussetzungen erfüllt sind. Erstens müssen die Verfahren der Leistungsplanung, des LeistungsReportings und die Freiheitsgrade einer IT-Preisbildung von vornherein in die Betrachtung eingeschlossen werden. Zweitens muss hierfür ein ganzheitlicher Lösungsansatz gefunden werden. Dies gilt sowohl für die IT-Services als für die IT-Investitionen.
5.6.5
Prozessabhängigkeit „P05 – IT-Qualitätsmanagement“
P05 – Qualitätsmanagement
Qualitätsanforderung
P01 – IT-Strategie
Qualitätsstandards
P05 – Qualitätsmanagement
KPIs Definition
P05 – Qualitätsmanagement
Messung
P06 – Portfolio Management
Projekt-KPIs Gemeinsame KPIs
Projekt-
P05 – Qualitätsmanagement
Qualitätsmerkmale
P05 – Qualitätsmanagement
SL-Qualität
Verfügbarkeit SL-Verletzung
P06 – Portfolio Management P09 – Service Management P09 – Service Management
Qualitätsmanagement ist der Prozess zur Sicherstellung, dass die mit den Kunden vereinbarte und erwartete Qualität in die Tat geliefert wird. An der Stelle wird zwischen zwei „Haupt IT-Produkten“ unterschieden: einerseits IT-Services, die innerhalb des Services-Katalogs beschrieben werden und mittels SLAs mit den Kunden vereinbart werden, und anderseits IT-Projekte, die für verschiedene Auftraggeber abgewickelt werden. Um Abweichungen von den Qualitätszielen rechtzeitig zu erkennen, wird ein Qualitätsmanagementsplan eingerichtet, dessen Aufgabe es ist, die Maßnahmen zur Qualitätssicherung und Kontrolle zu organisieren und zu überwachen. Das Qualitätsmanagement ist also dafür verantwortlich, dass erkannte Abweichungen bekannt gemacht und die entsprechenden korrigierenden Maßnahmen eingeleitet werden.
74
5.6 Prozessabhängigkeiten „Strategische Entscheidungsprozesse“ Um dies zu ermöglichen, müssen drei Fragen beantwortet werden: 1) Wie wird das Produkt bewertet im Vergleich zu deren Qualitätsmerkmalen? 2) Wann wird diese Bewertung stattfinden? 3) Wer wird diese Prüfung durchführen? Im Fall von IT-Services werden die Qualitätsmerkmale im Rahmen der vereinbarten SLAs festgelegt. Die Messung der SLAs ist absolut notwendig, um die Qualitätssicherung gewährleisten zu können. Falls diese nicht machbar wäre, würde der SLA nichts bringen. Bei einer SLA-Verletzung soll eine Untersuchung durchgeführt werden, um den Fall zu analysieren. Damit soll vermieden werden, dass ein Fehler mehrmals passiert. Für IT-Projekte werden Projekt-KPIs am Anfang des Projektes definiert und am Ende des Projektes gemessen. Zum Beispiel können folgende KPIs benutzt werden: A) KPI „Termine“ Die Projektplanung wird eingehalten und die Meilensteine werden effektiv erreicht. B) KPI „Budget“ Das Projektbudget wird eingehalten. C) KPI „Liefergüter“ Die Projektliefergüter wurden geliefert. Zum Beispiel: Datenübernahme, Schulung, Aufsetzen eines neuen IT-Systems, Schnittstellen, usw. D) KPI „Standardisierung“ Die Abwicklung der IT-Lösung basiert auf standardisierten Lösungen. Z.B. gemäß Roll-out-Prinzip oder gemäß Entwicklung eines Kernels E) KPI „Kundenzufriedenheit“ Die Kundenzufriedenheit wird gemessen mit Hilfe einer Umfrage F) KPI „Personalentwicklung“ Projekte bieten eine gute Gelegenheit, viel Wissen zu sammeln. „Junioren“ sollen auch ihre Chance bekommen, und deswegen sollen auch Projekte besonders belohnt werden, die zum Beispiel Coaching-Maßnahmen für Anfänger integrieren. G) KPI „Wissenstransfer“ Dieser Punkt kann im Rahmen von Einträgen zu einer Wissensdatenbank abgedeckt werden. H) KPI „Dokumentation“ Ist die vereinbarte Dokumentation vollständig und in einer guten Qualität (formell und inhaltlich)?
75
5 Funktionsgruppe „strategische Entscheidungsprozesse“ I)
J)
KPI „Handover“ An der Stelle soll gewährleistet werden, dass alle offenen Punkte an die Support-Organisation überleitet werden. KPI „Compliance“ Bei dem neu aufgesetzten System oder bei der Systemerweiterung muss sichergestellt werden, dass die Compliance zu Gesetzen und internen Richtlinien gewährleistet wird.
Jeder Punkt wird gewichtet, und Notenkriterien werden am Anfang des Projektes festgelegt. Als Beispiel für das Projekt „Beispiel_KPIs“: der KPI „Termine“ wird mit 20 Punkten aus 100 gewichtet und wie folgt definiert: – Überschreitung von 20% der Gesamtdauer = 0 Punkte – Überschreitung von 10% der Gesamtdauer = 10 Punkte – Termingerecht = 20 Punkte
76
6 Funktionsgruppe „Planung & Controlling“ Drei Prozesse bilden die Funktionsgruppe „Planung & Controlling“: – P06 - Projekt Portfolio Management, – P07 - Capacity / Availability, – P08 - Continuity Management, die in diesem Kapitel detailliert beschrieben werden. Aufgrund der Prozessabhängigkeiten müssen neun zusätzliche Prozesse berücksichtigt werden: – P01 - IT-Strategie, – P02 - HR Management, – P03 - IT-Standards & Architektur – P04 - Financial Management, – P05 - Qualitätsmanagement, – P09 - Service Management, – P10 - Anforderungsmanagement, – P14 - IT-Betrieb & Konfiguration, – P15 - Supplier Management. Die Beziehungen zu diesen neun Prozessen werden am Ende des Kapitels erläutert, wobei die Prozessabhängigkeiten zu der Funktionsgruppe „Strategische Entscheidungsprozesse“ im vorherigen Kapitel beschrieben wurden.
6.1 P06 – IT-Projekt Portfolio Management-Prozess Der Portfoliomanagement-Prozess stellt sicher, dass die „richtigen“ IT-Projekte durchgeführt werden. Dies setzt voraus, dass mehr Wünsche als verfügbare Ressourcen vorhanden sind, sonst wird dieser Prozess nicht gebraucht. Das Portfoliomanagement ist verantwortlich für: – die Steuerung des Projektportfolios, – die Überwachung des Projektportfolios (Kosten, Termine, technische Lösung), und sorgt damit für die, im Sinne der Unternehmensstrategie, richtige Priorisierung der einzelnen Projekte. Zwei wichtige Instrumente werden an dieser Stelle benutzt: – der Business Case, – der Nutzen des Projektes (oder die strategische Bedeutung).
77
6 Funktionsgruppe „Planung & Controlling“
Soll der Portfolio-Prozess erfolgreich implementiert und abgewickelt werden, müssen Grundprinzipien in der Organisation verankert werden, wie zum Beispiel: 1) 2) 3) 4) 5) 6) 7) 8) 9) 10) 11)
Projekte werden nicht ohne Business Case gestartet. Die Verantwortungen und Projekt-Organisation sind bei jedem Projekt klar. Die finanziellen Ressourcen sind klar priorisiert. Die IT-Standards müssen bei der Konzipierung der Projekte eingehalten werden. Die Projektplanung wird auf Portfolio Ebene durchgeführt und nicht jedes Projekt für sich. Die Qualitätssicherungsaktivitäten und Prüfungsanforderungen werden berücksichtigt. Standard Software-Lösungen werden, wo möglich, eingesetzt. Die Projektüberwachung findet laufend bei der Projektdurchführung statt. Die Projektmitglieder werden belohnt für Ihre Leistung. Nach Projektabschluss wird der Business Case neu ermittelt. Die Nachprüfung der Wirtschaftlichkeit wird durchgeführt.
Analyse der Projektidee basiert auf ein Business Case und eine Bewertung der definierten Kritischen Erfolgsfaktoren
Projektideen sammeln Fachbereich Fachkonzept IT System/ Applikation
ProjektIdee
gemeinsame vorgeschlagene
Projekt Portfolio Management
IT Lösungen
IT Projekte können kategorisiert werden. Als Beispiele: I
Investitionsabhängig (neue Fabrik)
T
IT Infrastruktur
V
Vorstudien
P
Prozessverbesserungen
Management Genehmigung
Bewertung & Auswahl
Projekt-Durchführung ProjektÜberwachung
Nachprüfung der Wirtschaftlichkeit Mehrwert
Bild 24: MIIP-Portfolio-Prozess-Darstellung
Als Ergebnis verfügt das Unternehmen über eine IT-Projekt-Portfolio-Matrix, in der vier Kategorien von Projekten abgebildet sind:
78
6.1 P06 – IT-Projekt Portfolio Management-Prozess
B
A
D
C
?
bedeutend keine
Strategische Bedeutung
Generische Portfolio Clusters
.
hoch
gering
Wirtschaftlichkeit
Bild 25: IT-Projekt-Portfolio-Matrix
A) Stars sind Projekte, die für das Unternehmen ein großes Potential darstellen. B) Dilemmas (oder Fragezeichnen) sind Projekte, deren Potential noch geprüft werden soll. In so einen Fall ist es empfehlenswert, ein Pilotprojekt zu starten oder eine Vorstudie durchzuführen. C) „Cash-Cow“-Projekte ermöglichen große Ersparnisse, ohne eine wirkliche strategische Bedeutung zu haben. D) “Muss” Projekte sind weniger attraktiv, da sie „nur“ Kosten verursachen. Solche Projekte sind notwendig, um eine IT-Infrastruktur im Stand zu halten (System Upgrade zum Beispiel) oder wenn neue Anordnungen des Gesetzgebers ins Kraft treten. Es ist wichtig, dass das Projektportfolio ausgewogen bleibt. Zum Beispiel werden dank Dilemmas die STAR-Projekte entdeckt. Die Wirtschaftlichkeit wird anhand des Return on Investment (ROI) verrechnet. Unterschiedliche Modelle können an der Stelle verwendet werden. Eine einfache Formel ermöglicht den ROI zu schätzen: ROI = (erwartete Gewinne oder Ersparnisse) / (Investition + Betriebskosten für 3 Jahre) Projekte, die ein ROI ǃ 2 bis 3 Jahre werden als wenig attraktiv eingestuft.
79
6 Funktionsgruppe „Planung & Controlling“ Die strategische Bedeutung wird anhand kritischer Erfolgsfaktoren geschätzt. Es ist wichtig an der Stelle festzustellen, dass die Schätzung subjektiv bleibt. Dennoch zeigt die Erfahrung, dass über die Projektideen ein Konsens innerhalb der Firma schnell herrschen kann, was deren Attraktivität anbelangt. Die kritischen Erfolgsfaktoren können wie folgt definiert werden: Tabelle 17: MIIP-Beispiel kritischer Erfolgsfaktoren für IT-Projekte
Wachstum Neue Erträge Zusatzumsatz / Kunde erhöhte Kundentreue erhöhte Flexibilität Wettbewerbsvorteil Kosten Effektivitätssteigerung Kostenminderung Reduzierte Betriebskosten Erhöhtes Wissen
80
Hoch
Mittel
Gering
Null
(4 Punkte)
(2 Punkte)
(1 Punkt)
(0 Punkt)
6.1 P06 – IT-Projekt Portfolio Management-Prozess
6.1.1
Hauptaktivitäten „P06 – IT Projekt Portfolio Management“
In der folgenden Tabelle werden die Hauptaktivitäten des Portfolio-Prozesses beschrieben. Tabelle 18: Hauptaktivitäten „P06 – IT Projekt Portfolio Management“
Hauptschritte
Beschreibung
Projektideen oder Projektbedürfnisse sammeln
Gesteuert durch die IT-Strategie und durch das Anforderungsmanagement werden Projektideen und Bedürfnisse erst gesammelt und definiert.
Projektdefinition und Analyse
Eine Projektliste wird erstellt und geführt. Der Umfang der identifizierten Projekte wird festgelegt.
Projekte bewerten Identifizierte Projekte werden priorisiert anhand Business Case und strategischer Bedeutung. Projekt genehmigen
Projekte müssen von den zuständigen Instanzen genehmigt werden, bevor Ressourcen für die entsprechenden Projektaktivitäten freigestellt werden.
Projekt ins Leben rufen
Wenn das Projekt genehmigt ist, wird die Projektorganisation benannt und das Projekt ins Leben gerufen.
Projekt überwachen
Während der Abwicklung des Projektes finden regelmäßige Austausche zwischen Projekten und Portfolio statt.
Projektresultate bewerten
Beim Projektabschluss werden die definierten KPIs gemessen. Dadurch wird die Gesamtprojektperformanz gemessen.
Wirtschaftlichkeit nachprüfen
Hat das Projekt alle Leistungsberechtigungen erbracht, die man sich gewünscht hat? Um diese schwierige Frage beantworten zu können, findet die Nachprüfung des Business Case statt.
81
6 Funktionsgruppe „Planung & Controlling“
6.1.2
Rollen „P06 – IT-Projekt Portfolio Management“
Bei der Abwicklung des IT-Projekt Portfolio Management Prozesses spielt der Business-Teil eine überwiegende Rolle. Tabelle 19: Prozessrollen „P06 – IT-Projekt Portfolio Management“
Geschäftsleitung – definiert den Budgetplafond für IT-Investitionen, – genehmigt die einzelnen IT-Investitionen. Auftraggeber
Business
– formuliert die Anforderungen seitens Fachbereich, – stellt den Business Case zusammen. Information Manager – priorisiert die Projektideen im Rahmen der Kurzfristplanung, – setzt Projekte auf. Projektleiter (Fach) – rapportiert regelmäßig Projekt-Status und Projektkosten an den Portfolio Manager. Finanz & Controlling – stellt sicher, dass ein Business Case ausgearbeitet wurde, – stellt sicher, dass die eruierten Business Cases tatsächlich erreicht wurden. CIO – genehmigt die einzelnen IT-Investitionen.
IT
Portfolio Manager – nimmt die Projekte in das Portfolio auf, damit sie aktiviert werden, – definiert in Zusammenarbeit mit den Information Managers die Projektleitung und Projekt-KPIs, – pflegt den IT Master Plan (rollende Planung), – ist auch für die Einhaltung des Gesamt-Projektbudgets zuständig. Account Manager – unterstützt den Auftraggeber bei der Formulierung der Anforderungen und beim Errechnen des Business Case.
82
6.1 P06 – IT-Projekt Portfolio Management-Prozess
6.1.3
Prozessbeschreibung „P06 – IT Projekt Portfolio Management“
Anbei den Ablauf des Prozesses mit den entsprechenden Prozessabhängigkeiten. ITStrategie
Anforderungsmanagement
IT Projektdefinition
Capacity – Availability Mgt
Geschäftsleitung, CIO
Projektideen
Auftraggeber
Anforderungen
Auftraggeber
Fachkonzept
Auftraggeber Portfolio Manager Account Manager
Business Case
Projektantrag
nein
Projekt genehmigt ? ja
IT-Projektmanagement
IT-Mittelfristplanung
Projektideen
IT Financial Management IT-Qualitätsmanagement
Input Output
Projekt aufsetzen
ManagementEntscheidung Projektliste Projektleitung festlegen Projekt KPIs
Auftraggeber
Geschäftsleitung, CIO Information Manager Portfolio Manager, Projektleitung
Statusbericht Projekt-Kosten Controlling
Projektleitung
Projektabschluss: Bewertung
Projektbewertung
Portfolio Manager Projektleitung
Nachprüfung des Business Case
Erreichtes Business Case
Finanz & Controlling
Projekt Überwachung
Ende
Bild 26: Prozessbeschreibung „P06 – IT-Projekt Portfolio Management“
83
6 Funktionsgruppe „Planung & Controlling“
6.2 P07 - Capacity / Availability Management-Prozess Gemäß ITIL sind Availability und Capacity Management zwei getrennt definierte Prozesse unter der Kategorie „Service Delivery“. Bei MIIP wurde entschieden, die beiden Prozesse in einem zu gruppieren, da beide Prozesse im Grunde genommen eng miteinander verknüpft sind. Dieser Prozess wird benutzt, um die bestehenden Ressourcen optimal einzusetzen und die notwendigen Anpassungen terminund zeitgerecht planen und realisieren zu können. Bei Ressourcen unterscheidet man zwischen: – Arbeitskraft: Kann es sichergestellt werden, dass genügend IT-Ressourcen, intern oder extern, zur Verfügung stehen, um einerseits die betrieblichen als auch die projektbezogenen Aktivitäten in der geplanten Frist innerhalb des genehmigten Budgets durchführen zu können? – IT Infrastruktur (wie IT-Geräte, Diskspace, Bandbreite, ...): Kann es sichergestellt werden, dass die Applikationen aufgrund des Datenzuwachses reibungslos laufen? Genügend Lizenzen? Stabilität der IT-Systeme? Können die Antwortzeiten gewährleistet werden? Der Prozess „Capacity – Availability“ ist ein Schlüsselprozess für die Planung und die Überwachung der Belastung von IT-Ressourcen (Arbeitskraft und Infrastruktur).
6.2.1
Hauptaktivitäten „P07 – Capacity / Availability Management“
In der folgenden Tabelle werden die Hauptaktivitäten des Capacity / AvailabilityProzesses beschrieben, die sowohl für Arbeitskraft als Infrastruktur gelten. Tabelle 20: Hauptaktivitäten „P07 – Capacity / Availability Management“
Hauptschritte
Beschreibung
Schätzung der Bedürfnisse
Für die operative Abwicklung der Geschäftsabläufe und die Durchführung von IT-Projekten werden Ressourcen in Anspruch genommen. Durch den SL-Prozess und Portfolio Management-Prozess werden die Ressourcenbedürfnisse geschätzt.
Verfügbare Ressourcen
Die IT-Organisation verfügt über internes Personal und überwacht die IT-Infrastruktur. Diese Ressourcen müssen verwaltet und „inventarisiert“ werden.
84
6.2 P07 - Capacity / Availability Management-Prozess
Hauptschritte
Beschreibung
Capacity Plan erstellen
Aufgrund der Ressourcenbedürfnisse und der verfügbaren Ressourcen werden Capacity-Pläne erstellt. Diese sollen Engpässe identifizieren und früh genug ein Signal liefern, so dass die notwendigen Maßnahmen frühzeitig getroffen werden können.
Availability
Für kritische IT-Systeme soll diese Überwachung die Garantie liefern, dass das System verfügbar ist und reibungslos funktioniert.
überwachen
Die Arbeitsbelastung der einzelnen Mitarbeiter soll regelmäßig überprüft werden. Availability nachprüfen
Sollte die Verfügbarkeit nicht ausreichend sein, wird die erforderliche Kapazität geschätzt, organisiert und beschafft.
Rapportieren
Reports und Statistiken sollen ermöglichen, Erfahrungswerte zu bekommen, die für die Bedürfnisschätzung und die Gesamtplanung von großer Bedeutung sind.
Die Kapazität der Arbeitskraft wird in Stunden gemessen. Der Link zwischen Kapazität und Budget wird an der Stelle durch den internen Stundensatz erstellt.
6.2.2
Rollen “P07 – Capacity / Availability Management”
Die folgenden Rollen sind notwendig, um den Prozess abwickeln zu können, einerseits auf der Personal-Seite und anderseits auf der Infrastruktur-Seite. Tabelle 21: Prozessrollen „P07 – Capacity / Availability Management“
CIO – ist für den Personalbestand der IT-Organisation zuständig.
IT
Leiter Service Management – definiert in Zusammenarbeit mit dem Betriebsleiter die zu erbringenden Services, – vereinbart die Services mit den Fachbereichen. Leiter Projekt Portfolio Management – pflegt die Liste der Projekte, die in das Portfolio aufgenommen wurden, – macht eine Schätzung der notwendigen Arbeitskraft.
85
6 Funktionsgruppe „Planung & Controlling“ IT-Betriebsleiter – definiert die Bedürfnisse im Bereich IT-Infrastruktur im Rahmen der Mittel– und Kurzfristplanung, – erstellt und pflegt die Infrastruktur Roadmap und bereitet ggf. die notwendigen IT-Projekte vor, – prüft die Systemverfügbarkeit, – stellt mit den System Owners sicher, dass die notwendige Leistungsfähigkeit der IT-Systeme gewährleistet ist, – erstellt Berichte und Statistiken. IT Controlling – konsolidiert die budgetierten IT-Ressourcen für Betrieb und Projekte, um einen Ressource Check durchführen zu können (Sachaufwand kontra interne Ressourcen), – ist zuständig für die Aufwanderfassung (erfasste Stunden für die erbrachten Services und die durchgeführten Projekte), – erstellt die konsolidierte Kapazitätsplanung pro IT-Abteilung bezüglich Manpower. IT Management – ist zuständig für die IT-Ressourcen-Planung der Abteilung, – stellt die Erbringung der Liefergüter sicher. System Owner – prüft die Systemverfügbarkeit, – stellt mit dem Betriebsleiter zusammen sicher, dass die notwendige Leistungsfähigkeit der IT-Systeme gewährleistet ist.
86
6.2 P07 - Capacity / Availability Management-Prozess
6.2.3
Prozessbeschreibungen „P07 – Capacity / Availability“
Die folgende Abbildung zeigt den Ablauf des Prozesses mit den entsprechenden Prozessabhängigkeiten.
Projekt Portfolio
Input Output
IT Service Mgt kontraktierte Services
IT-Architektur Schätzung der Bedürfnisse
IT Continuity
HR Management
Projekt Portfolio
Leiter Service Mgt Portfolio Manager
Arbeitskraft / ITInfrastruktur Bedürfnisse
IT Controlling, IT-Betriebsleiter
IT-Stellenplafond
CIO
Capacity Check
IT Controlling
Infrastruktur Roadmap
IT-Betriebsleiter
Ressource Plan
IT Management
System Plan, Verfügbarkeit, Überwachung der IT-Systeme
IT-Betriebsleiter, System Owner
Arbeitsbelastung
IT Management
System-Kapazität
IT-Betriebsleiter, System Owner
Aufwanderfassung
IT Controlling
Statistiken, Berichte
IT-Betriebsleiter
interne Ressourcen
Infrastruktur Roadmap
Projekt Portfolio Management
Projekt Portfolio Management Verfügbarkeit überwachen
Betrieb Konfiguration
nein
Verfügbarkeit in Ordnung ?
Rapportieren
Ende
Bild 27: Prozessbeschreibung „P07 – Capacity / Availability Management“
87
6 Funktionsgruppe „Planung & Controlling“
6.3 P08 - Continuity Management-Prozess Hochwasser, drohende Seuchengefahren, Brandstiftung, terroristische Anschläge, Naturkatastrophen wie „Katrina“ oder ein einfacher Stromausfall – die Liste der Gefahren, welche die Kernprozesse eines Unternehmens bedrohen, ist ebenso lang wie vielfältig. Die Ereignisse der letzten Jahre haben die Anfälligkeit von Finanzmarktteilnehmern und -Systemen deutlich aufgezeigt. Die Sensibilisierung für derartige Ereignisse und ihre realen und potentiellen Auswirkungen sind merklich gestiegen. Mit der gestiegenen Sensibilisierung ist aber auch die Erwartungshaltung seitens Kunden, Aktionären und Regulatoren gestiegen, so dass sich die einzelnen Unternehmen erfolgreich vor diesen Szenarien schützen müssen. Ziel ist der Aufbau eines leistungsfähigen Business Continuity Managements (BCM) zwecks systematischer Vorbereitung auf die Bewältigung von Schadenereignissen, so dass wichtige Geschäftsprozesse selbst in kritischen Situationen und in Notfällen nicht oder nur temporär unterbrochen werden und die wirtschaftliche Existenz des Unternehmens trotz Schadenereignis gesichert bleibt. Das BCM ist grundsätzlich als integraler Ansatz zu betrachten, welche IT operationelle und sicherheitsrelevante Disziplinen umfassend abdecken soll. Sie wird mit den vorhandenen Prozessen so verknüpft und integriert, dass eine gute Effizienz erreicht werden kann. BCM-Maßnahmen sind nur dann erfolgreich, wenn sie auch im Regelbetrieb gelebt werden. Daher ist es unerlässlich, ein dauerhaftes Management zu etablieren, das z.B. für eine stete Anpassung an die veränderten Bedingungen sorgt und durch Übungen die Praxistauglichkeit und Akzeptanz der Notfallpläne prüft. Auch ökonomisch ist dies die sinnvollste Lösung: Nichts ist teurer als alle zwei Jahre von vorne zu beginnen oder in einer Krise falsch zu reagieren. Die Grundlage eines erfolgreichen BCM bildet die präventiv wirkende Risikobewirtschaftung. Die nachfolgende Grafik zeigt auf, wie Risiken in einem Prozess gezielt reduziert werden können. – Risiken kennen Nur wer seine Risiken wirklich kennt, kann diese beherrschen. Mittels einer so genannten „Business Impact Analysis“ (BIA) werden die Risiken von Organisationen und Prozessen identifiziert und quantifiziert. Danach wird die Eintrittswahrscheinlichkeit mit Hilfe einer Risiko Analysis (RA) ermittelt und darauf basierend adäquate Maßnahmen initialisiert. – Risiken reduzieren Sind die Risiken bekannt, können sie mittels verschiedener Maßnahmen reduziert werden. So kann z.B. durch das Zentralisieren eines Systems das Ausfallrisiko konzentriert und mittels redundanter Auslegung wirkungsvoll reduziert werden.
88
6.3 P08 - Continuity Management-Prozess – Schäden minimieren Für die verbleibenden Risiken gilt es nun, das Schadensausmaß sofern möglich zu senken. Zum Beispiel soll ein Unternehmen über mehrere Rechenzentren verfügen, welche Schäden durch den Ausfall eines RZ-Standortes verhindern sollen. – Risiken entschärfen Das nicht akzeptierbare Restrisiko ist nun, soweit möglich, mittels geeigneter Instrumente (zum Beispiel dank Versicherungen) zu entschärfen. – Akzeptierte und unbekannte Risiken Das verbleibende Risiko sowie die nicht erkannten Risiken sind nun durch das Unternehmen zu tragen und im Ereignisfall zu bewältigen.
Risiken reduzieren Erkanntes Risiko Schäden minimieren
Schadenspotential
Reduziertes Risiko
Risiken entschärfen
Minimiertes Risiko
Akzeptiertes Risiko
Unbekannte Risiken
„Continuity Management“ Prozess
Bild 28: Ziel des Continuity Management-Prozesses
89
6 Funktionsgruppe „Planung & Controlling“
6.3.1
Hauptaktivitäten P08 – Continuity Management
In der folgenden Tabelle sind die Hauptaktivitäten des Prozesses dargestellt, die in erster Linie auf der Risiko Analyse basieren. Tabelle 22: Hauptaktivitäten „P08 – Continuity Management“
Hauptschritte
Beschreibung
Business Impact Analysis
Im ersten Schritt erfolgt die BIA. Hier werden die kritischen Geschäftsprozesse identifiziert, ihre Toleranzgrenzen festge(BIA) durchführen legt und die möglichen Auswirkungen von Katastrophenszenarien untersucht. Folgende Fragen werden beleuchtet: – Wie ist der Prozess aufgebaut? Wer ist daran beteiligt? Wo wird er durchgeführt? Was wird mit diesem Prozess bezweckt? – Welche Ressourcen werden zur Durchführung des Prozesses benötigt? – Welche Unterstützungsleistungen sind durch Interne oder Externe zu erbringen? – Welche Parallel-Prozesse sind für die Durchführung zusätzlich bedeutend? – Wie hoch könnte bei Ausfall ein finanzieller Verlust bzw. ein Schaden für die Reputation sein? – Wie lange darf der Prozess ausfallen, ehe das Unternehmen in einen „kritischen“ Zustand verfällt? – Welche Risiken birgt der Prozess (Identifikation von Risiken)? – Welche kritischen Daten werden verarbeitet? Die daraus resultierenden Beschreibungen ermöglichen ein Ranking nach der maximal akzeptablen Dauer einer Unterbrechung des Kerngeschäftes. Bei der Identifikation gilt es aber auch zu berücksichtigen, dass Risiken durchaus vorhanden sein können, auch wenn sie in der Vergangenheit noch nicht aufgetreten sind. Transparenz, Kommunikation und Awareness-Programme sind hier oft zielgerichteter als reine Vermeidungsstrategien.
90
6.3 P08 - Continuity Management-Prozess Hauptschritte
Beschreibung
Risiko Analysis (RA) durchführen
Nach Abschluss der BIA wird versucht, die Eintrittswahrscheinlichkeit des Risikos zu ermitteln. Hierbei kommt man unweigerlich mit dem klassischen Risikobegriff in Berührung, der ein Risiko als Produkt von Schadenshöhe und Schadeneintrittswahrscheinlichkeit definiert. Aus der Kombination von qualitativen und quantitativen Daten wird ein Portfolio des Gesamtrisikos erstellt. Folgende Fragen gilt es dabei zu beantworten: – Welche Risiken haben in der Vergangenheit zu einem Prozessausfall geführt? – Welche neuen Risiken können auftreten? – Welches Szenario hält der Befragte für wahrscheinlich? – Welche risikominimierenden oder risikotransferierenden Maßnahmen wurden eingeleitet? Welche wären wünschenswert? – Welche Kosten könnten anfallen? Die Risiken werden dann bewertet als: – Tief, – Mittel, – Hoch. Das BCM konzentriert sich auf die Risiken welche als „Hoch“ eingestuft werden, da diese – Nachhaltige, negative Beeinflussung des Geschäftsergebnisses – Dauerhafter Verlust von Kunden und Marktanteilen zur Folge haben.
Risikomatrix tellen
ers- Das Ergebnis ist eine Risikomatrix inklusive Risikokategorisierung, Risikobeschreibung, Schadenshöhe, Eintrittswahrscheinlichkeit, Maßnahmen zur Risikominimierung für den Wiederanlauf sowie den Risikotransfer.
Maßnahmen defi- In dieser Phase stehen die Entwicklung eines Wiederanlaufnieren und umset- plans für Systeme, Alternativprozesse, sowie die Entscheizen dung über Umsetzungsmaßnahmen im Vordergrund. Dabei sind folgende Kernbestandteile zu beachten: – Konzentration auf das Wesentliche – Mut zur Lücke! – durchgängiges Ressourcenmanagement (IT, HR, Ge-
91
6 Funktionsgruppe „Planung & Controlling“ bäude, Telekommunikation usw.), – klare Vereinbarungen mit Partnern, – Bestimmung von System- und Prozess-Ownern, – Sicherstellung der internen und externen Kommunikationsfähigkeit, – Unterscheidung von risikominimierenden und Wiederanlaufmaßnahmen. Anschließend müssen die gefundenen Maßnahmen implementiert und dokumentiert werden. Training und Übungen planen
Letztendlich sind die Krisenstäbe zu trainieren und die Mitarbeiter über die Zielsetzung des BCM zu informieren. Der informierte, mündige Mitarbeiter ist für die Schaffung einer unternehmerischen Risikokultur unabdingbar und mindestens genau so wichtig wie eine verständliche und anwendbare Policy. Bei BCM handelt es sich nicht um eine lineare Prozesskette, sondern um einen Zyklus, da Prozessabläufe und deren Risiken sich ändern.
92
6.3 P08 - Continuity Management-Prozess
6.3.2
Rollen „P08 – Continuity Management“
Die folgenden Rollen sind notwendig, um den Prozess abwickeln zu können. Die Verantwortung liegt in diesem Modell bei dem obersten Management des Unternehmens. Tabelle 23: Prozessrollen „P08 – Continuity Management“
Geschäftsleitung
Business
– entscheidet über die notwendigen BCP-Maßnahmen, – bewilligt die entsprechenden Mittel für BCP-Maßnahmen. Bereichsleiter – definiert die Kritikalität der Geschäftprozesse und der entsprechenden Informationssystemen, – bewertet in Zusammenarbeit mit dem Sicherheitsbeauftragten die identifizierten Risiken, – definiert in Zusammenarbeit mit dem Sicherheitsbeauftragten die notwendigen Maßnahmen, um die Risiken zu mindern oder sogar ganz zu vermeiden – unterstützt die Durchführung der Aktivitäten (Schulung, Übungen,...) zur Minderung der Geschäftsrisiken.
IT
Sicherheitsbeauftragter – stellt sicher, dass jeder Bereich über Krisenmanagement verfügt, – informiert die Geschäftsleitung über potentielle Risiken, – bewertet in Zusammenarbeit mit dem Bereichsleiter die identifizierten Risiken, – definiert in Zusammenarbeit mit der Geschäftsleitung die notwendigen Maßnahmen, um die Risiken zu mindern oder sogar ganz zu vermeiden, – organisiert die entsprechenden Maßnahmen, sobald die von der GL bewilligt wurden, – organisiert Schulungen und Übungen, – stellt ein funktionierendes Krisenmanagement sicher. IT-Betriebsleiter – stellt die Aktualität und Qualität des IT-Wiederanlaufplans sicher, – ist für die Durchführung der Tests von IT-Anwendungen zuständig, – ist für die Durchführung des IT-Wiederanlaufs verantwortlich.
93
6 Funktionsgruppe „Planung & Controlling“
6.3.3
Prozessbeschreibung „P08 – Continuity Management“
Nachfolgend im A4 Format die Beschreibung des Prozesses. Unternehmenssicherheit Richtlinien
Business Impakt Analyse durchführen
Risiken identifizieren und bewerten
Capacity – Availability Mgt
Input Output
Bereichskrisenhandbuch
Risiko-Liste Geschäftsleitung, Risiko-Bewertung und Sicherheitsbeauftragter Analyse (z.B. Vogelgrippe)
Maßnahmen zur Krisenvermeidung/verminderung Maßnahmen zur Krisenbewältigung,
IT-Wiederanlaufplan Tests
und Umsetzung
Training Übungen
Weitere Maßnahmen, wie z.B. Versicherung abschließen
Schulungen Übungen (z.B. Evakuationsübung)
Ende
Bild 29: Prozessbeschreibung „P08 - Continuity Management“
94
Bereichsleiter Sicherheitsbeauftragter
IT-Betriebsleiter, Sicherheitsbeauftragter
Geschäftsleitung, Sicherheitsbeauftragter
6.4 Prozessabhängigkeiten „Planung & Controlling“
6.4 Prozessabhängigkeiten „Planung & Controlling“ Das folgende Bild zeigt die Prozessabhängigkeiten der drei in „Planung & Controlling“ definierten Prozessen mit neun zusätzlichen Prozessen (HR Management, Financial Management, Qualitätsmanagement, Service Management, Anforderungsmanagement, IT-Betrieb & Konfiguration, Supplier Management). Innenauftrag Anfrage
Financial Strategie
Innenauftrag
Budget Investition
Umsetzung Strategie
ProjektKPIs Messung
gemessene Projekt KPIs ServiceMengen
Service
ProjektNotwendige antrag Kapazität
KPIs Definition
ProjektListe
Projekt Portfolio
Projektantrag
ITAnforderung
Anforderung
ITStandards
HR Unternehmen Sicherheit
ITInfrastruktur
Projekt Kosten
strategische Projekte
Qualität
Architektur
ITStellenplafond
Bedarf Auslastung
Capacity Availabilty
Check
Plan
genehmigter Projektantrag
Überwachung, Bewertung
interne Ressourcen
Risiken Überwachung
System Kritikalität
Infrastruktur Roadmap
Projekt aufsetzen
Statusbericht
Continuity
SystemPlan
Betrieb Konfig.
Projekt
Bild 30: MIIP-Prozessabhängigkeiten „Planung & Controlling“
6.4.1
Prozessabhängigkeit „P06 – Portfolio Management“
P06 – Portfolio Management
Umsetzung Strategie
P06 – Portfolio Management
Projekt-Liste
P06 – Portfolio Management
P01 – IT-Strategie
Strategische Projekte Budget Investition Projektantrag Innenauftrag-Anfrage
P04 – IT Financial Management P04 – IT Financial Management
95
6 Funktionsgruppe „Planung & Controlling“
P06 – Portfolio Management
Innenauftrag
P06 – Portfolio Management
KPIs Definition
P06 – Portfolio Management
Messung
P06 – Portfolio Management
Bedarf
P06 – Portfolio Management
Check
P06 – Portfolio Management
IT Anforderung
P06 – Portfolio Management
Genehmigter Projektantrag
P04 – IT Financial Management
Projektkosten
P05 – IT Qualitätsmanagement
Projekt-KPIs Gemessene Projekt-KPIs
P07 – Availability / Capacity
Auslastung
P07 – Availability / Capacity
Plan
P10 – Anforderungsmanagement
Projektantrag
Projekt aufsetzen P06 – Portfolio Management
P05 – IT Qualitätsmanagement
P11 – ITProjektmanagement
Statusbericht Überwachung, tung
Bewer-
P11 – ITProjektmanagement
Im Sinne von Prozessabhängigkeit spielt der Projektportfolio-Prozess die Rolle des Einführungsorgans der Strategie, also „Top Down“. Im Rahmen des Anforderungsprozesses werden Projektideen „bottom-up“ berücksichtigt. Das Projektportfolio gilt als Dachfunktion für alle Projekte. Aus diesem Grund sind die Prozessabhängigkeiten zwischen Portfolio und ProjektmanagementProzessen absolut grundlegend. Vor allem, wenn mehrere Projekte wegen kritischen Ressourcen oder Systemintegration von einander abhängig sind. Beim Start eines neuen Projektes wird ein Innenauftrag kreiert. Basierend auf der Projektportfolio-Planung und der erfassten Projektkosten werden die jährlichen Investitionskosten geschätzt und mit dem vorgegebenen Budget verglichen.
96
6.4 Prozessabhängigkeiten „Planung & Controlling“
6.4.3
Prozessabhängigkeit „P07 – Availability / Capacity Management“
P07 – Availability / Capacity
IT-Stellenplafond
P07 – Availability / Capacity
IT-Standards
P07 – Availability / Capacity P07 – Availability / Capacity P07 – Availability / Capacity P07 – Availability / Capacity P07 – Availability / Capacity
P02 – HR Management
Interne Ressourcen IT-Infrastruktur
P03 – IT-Standards & Architektur
Bedarf Auslastung
P06 – Portfolio Management
Check Plan
P06 – Portfolio Management
System-Kritikalität Risiken Überwachen Service-Mengen
P08 – Continuity Management P09 – Service Management
Notwendige Kapazität Infrastruktur-Roadmap System-Plan
P14 – IT-Betrieb & Konfiguration Management
Der Prozess „Capacity / Availability Management“ bietet die Möglichkeit, die bestehenden und zusätzlichen Ressourcen zu planen. Wichtige Rahmenbedingungen werden durch – die definierten und zu erbringenden Services, – die geplanten Projekte im Rahmen des Projektportfolios, – die Architektur-Anforderungen, – die verfügbaren internen IT-Personal-Ressourcen, – die notwendigen Continuity-Maßnahmen festgelegt. Als wichtige Outputs werden in erster Linie: – Kapazitätspläne und Verfügbarkeitsmessungen, – Systempläne im Betrieb, – Ressource-Pläne für das Projektportfolio erstellt. Dieser Prozess gilt als zentrales Planungsinstrument, um die optimale Verwaltung der IT-Ressourcen (Personal und IT-Infrastruktur) gewährleisten zu können.
97
6 Funktionsgruppe „Planung & Controlling“
6.4.3
Prozessabhängigkeit „P08 – Continuity Management“
P08 – Continuity Management
System-Kritikalität Risiken Überwachen
P07 – Availability / Capacity
Die Anforderungen des Continuity Management haben direkte Auswirkungen auf den Capacity Plan. Je nach Kritikalität der Systeme sollen dedizierte Back-upLösungen zum Beispiel zur Verfügung gestellt werden.
98
7 Funktionsgruppe „Account Management“ Zwei Prozesse bilden die Funktionsgruppe „Planung & Controlling“: – P09 - Service Management, – P10 - Anforderungsmanagement, die in diesem Kapitel detailliert beschrieben werden. Aufgrund der Prozessabhängigkeiten müssen neue zusätzliche Prozesse berücksichtigt werden: – – – – – – – – –
P01 - IT-Strategie, P04 - Financial Management, P05 - Qualitätsmanagement, P06 - Portfolio Management, P07 - Capacity / Availability, P12 - Release Management, P14 - IT-Betrieb & Konfiguration, P16 - Incident Management, P17 - Problem Management.
Die Beziehungen zu diesen neuen Prozessen werden am Ende des Kapitels erläutert. Die Funktionsgruppe „Account Management“ gilt als Drehscheibe. Einerseits werden die IT-Dienstleistungen direkt von der IT-Strategie definiert („top-down“). Anderseits wird das Anforderungsmanagement als „bottom-up“-Ansatz berücksichtigt. Aus der Top-Down-Perspektive spielt die Definition der einzelnen IT-Services eine entscheidende Rolle. Einerseits sollen diese aus der IT-Strategie klar ersichtlich sein. Anderseits sollen bei der Definition von Service Level Agreements (SLAs) klare und messbare Qualitätsmerkmale, die für die Unternehmensbedürfnisse angemessen sind, definiert werden. In dem vorgeschlagenen Prozessmodell besteht die Möglichkeit, neue IT-Services als „bottom-up“-Anforderung zu definieren. Als Beispiel können Bereiche wie „Mobile Geräte“ (Black Berry, Palmtop, Mobiltelefon,...) erwähnt werden. Die rasante technologische Entwicklung, kombiniert mit einer weiten Verbreitung im Privathaushalt, prägt die Arbeitsgewohnheiten der Anwender, so dass die entsprechenden neuen IT-Dienstleistungen zwangsläufig eingeführt werden sollen.
99
7 Funktionsgruppe „Account Management“
7.1 P09 - Service Management-Prozess Unterschiedliche IT-Dienstleistungen werden als „Services“ definiert und als Produkt offeriert. Der Service Management-Prozess beinhaltet drei Hauptziele: – die Definition der IT Services und das Abschließen der Verträge mit den Fachbereichen, – die Erbringung der vereinbarten Dienstleistungen, – das Messen und Reporten der zur Verfügung gestellten Serviceleistungen. Die Definition und die Struktur der SLAs spielen eine entscheidende Rolle. Vor allem wird die ganze Kostenstruktur auf Service Level aufgebaut, da die Betriebsbudgets auf Service-Ebene gerechnet werden. Dieselbe Struktur wird auch für „Capacity / Availability“ im Rahmen der Planung und Nutzung der internen Personal-Ressourcen verwendet. Als allgemeiner Trend kann festgehalten werden, dass techniklastige SLAs eher auf dem Rückmarsch sind. Anwender vereinbaren zunehmend kunden- und systemorientierte Güteklassen mit ihrem Provider. Die SLAs werden sich tendenziell nach Geschäftsprozessen richten, wobei sich beide Seiten jedoch hier schwer tun. Folgende Elemente können sehr hilfreich benutzt werden, zum Prüfen, ob die eigene SLA Struktur adäquat ist: – die budgetierte Summe auf dem Service ist weder zu hoch noch zu niedrig, – die Anwender-Zielgruppe ist klar identifiziert, – die Service-Erbringer können ohne Schwierigkeiten ihre Zeit bei den verschiedenen Services erfassen, – die SLAs sind aktuell und unterschrieben, – die Messpunkte sind klar definiert und in der Tat regelmäßig gemessen. Die Formulierung der SLAs soll folgende Informationen beinhalten: – – – – –
100
welche Dienstleistung wird angeboten? wie wird die definierte Dienstleistung erbracht? wer prüft, ob die Dienstleistung erbracht worden ist, und wie? was passiert, falls eine SLA-Verletzung stattfindet? wie ist die Pflege des SLA geregelt?
7.1 P09 - Service Management-Prozess Folgende Parameter müssen dann in einem SLA definiert sein: Tabelle 24: Definition der Service-Zeiten
Betriebszeit
= die Zeit, in der ein Service für die Nutzung zur Verfügung steht zum Beispiel : 7 x 24 Stunden, abzüglich Wartungszeit
Servicezeit
= die Zeit, in der für die Erbringung eines Services ein Helpdesk zur Verfügung steht zum Beispiel: Montag - Freitag, 07:00 – 18:00
Bereitschaftszeit (Pikett)
= die Zeit, in der zur Erbringung des Services ein Pikettdienst zur Verfügung steht zum Beispiel: Montag - Freitag, 18:00 - 07:00, Samstag 07:00 - 16:00
Wartungszeit
= die Zeit, in der ein Service wegen einer geplanten Wartung nicht zur Verfügung steht
Ausfallzeit
= die Zeit, in der ein Service aus irgendwelchen Gründen unterbrochen ist
Reaktionszeit
= die Zeit zwischen der Meldung eines Ereignisses und dem Zeitpunkt, ab dem der Benutzer eine qualifizierte Rückmeldung erhält. Die Reaktionszeit ist nur innerhalb der Servicezeit maßgebend
Lösungszeit
= die Zeit zwischen der Meldung eines Ereignisses (Aufnahme des Problems im Incident Management System ) und dem Zeitpunkt, ab der der Service wieder für den Standardbetrieb zur Verfügung steht
Eskalationszeit
= die Zeit, nach der ein Problem eskaliert werden muss, falls keine Lösung oder Umgehung gefunden wird
101
7 Funktionsgruppe „Account Management“ Als Überblick: Tabelle 25: Reaktionszeiten
Anwendungskategorie
Erwarteter Service Level
Minimum ZeitRück- AusService fenster für ruf fallzeit Level Messung
Mission Critical Applikationen
Business Critical Applikationen Andere Applikationen
99.8%
99.7 %
Mo – Sa 07:00 – 18:00
99.5%
99.0%
Mo – Sa 60 07:00 – Min. 18:00
60 Std.
98.0%
Mo – Sa 07:00 – 2 Std. 18:00
2 Tage pro Applikation
99.0%
30 Min.
4 Std.
Eskalation Kunde / IT - 30 Min. => 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