Planung und Realisierung von IT-Infrastrukturen - ein prozessbasierter Ansatz 9783486716917, 9783486713411

Citation preview

Planung und Realisierung von IT-Infrastrukturen – ein prozessbasierter Ansatz von

Prof. Dr. Rainer Rumpel

Oldenbourg Verlag München

Dr. Rainer Rumpel ist Professor für Wirtschaftsinformatik an der Hochschule für Wirtschaft und Recht Berlin. Seine fachlichen Schwerpunkte sind IT-Infrastrukturen und Informationssicherheit.

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. © 2012 Oldenbourg Wissenschaftsverlag GmbH Rosenheimer Straße 145, D-81671 München Telefon: (089) 45051-0 www.oldenbourg-verlag.de Das Werk einschließlich aller Abbildungen ist urheberrechtlich geschützt. Jede Verwertung außerhalb der Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Bearbeitung in elektronischen Systemen. Lektorat: Kathrin Mönch, Dr. Gerhard Pappert Herstellung: Constanze Müller Titelbild: thinkstockphotos.de Einbandgestaltung: hauser lacour Gesamtherstellung: Grafik & Druck GmbH, München Dieses Papier ist alterungsbeständig nach DIN/ISO 9706. ISBN 978-3-486-71341-1 eISBN 978-3-486-71691-7

Widmung Dieses Buch ist den Studierenden der Wirtschaftsinformatik und den Anwendern in der IT-Branche gewidmet.

Danksagung Diese Arbeit wurde während eines Forschungssemesters im Sommer 2011 begonnen, das vom Fachbereich Duales Studium der Hochschule für Wirtschaft und Recht Berlin bewilligt wurde. Ich habe mich über die Unterstützung durch eine studentische Hilfskraft gefreut. Ich bin dankbar für alle, die mich dabei unterstützt haben, dieses Buch zu schreiben und zu veröffentlichen. Insbesondere gilt mein Dank meinem Vater, der Korrektur gelesen hat, der Lektorin des Oldenbourg-Verlags, die meine Fragen immer hilfreich beantwortet hat und den Unternehmen NextiraOne Deutschland GmbH sowie arxes Information Design Berlin GmbH, die meine Ideen aus unmittelbarer Praxiserfahrung gespiegelt haben. Weiterhin möchte ich mich bei Dr. Chris Weck herzlich bedanken, der ebenfalls mit Interesse den Manuskriptentwurf gelesen und kommentiert und das Vorwort verfasst hat. Ein besonderer Dank gilt meiner Frau, die die zurückliegende außergewöhnliche Zeit sehr geduldig mitgetragen hat. Schließlich bin ich auch dankbar für Leser, die Verbesserungsvorschläge zu meinen Ausführungen haben. Ich bin per E-Mail unter [email protected] erreichbar. Berlin, im Dezember 2011 Rainer Rumpel

Vorwort Die Informations- und Kommunikationstechnik bietet heute durch die andauernden, rasanten technischen Entwicklungen nahezu unbegrenzte Möglichkeiten zur Prozessautomatisierung und Prozessoptimierung. Dabei werden die informationstechnischen Infrastrukturen immer komplexer und die Anforderungen sowohl an den Funktions- und Leistungsumfang als auch an die Systemintegrität und Systemzuverlässigkeit steigen ständig. Auf der anderen Seite ist nicht alles finanzierbar, was technisch machbar ist. Geschäftsleitungen und Projektleiter können die Verknappung der Ressourcen, seien sie finanzieller oder personeller Art, seien es Energie- und Umweltressourcen oder nicht vermehrbare Ressourcen, wie beispielsweise Übertragungsfrequenzen, nicht mehr übergehen. Das Buch regt an, intensiv darüber nachzudenken, welchen Sinn und Zweck eine technische Infrastruktur im Zusammenhang mit der Geschäftsstrategie eines Unternehmens eigentlich hat. Dabei geht es nicht nur um eine Kosten/Nutzen-Abwägung im Vorfeld einer Projektierung, denn der Nutzen einer technischen Einrichtung wird von Managern, Technikern oder Nutzern häufig sehr unterschiedlich eingeschätzt und bewertet, sondern es geht um die ganzheitliche Betrachtung einer technischen Infrastruktur im Hinblick auf die Geschäftsstrategie, die Erwartungen der Kunden sowie die Optimierung von Prozessstrukturen und Verfahrensschritten für die Nutzer. Doch wie kann sichergestellt werden, dass sich technische Projekte und insbesondere ITProjekte in die Gesamtschau des Unternehmens, in seine Strategie und seine Geschäftsziele optimal einfügen? Nicht nur Führungskräfte, sondern auch Projektleiter und Techniker sind herausgefordert, diesen Prozess proaktiv zu unterstützen. Hier setzt das Buch an. Ausgehend von den grundlegenden Fragestellungen bei der Planung von IT-Projekten wird eine strukturierte Vorgehensweise für IT-Projektleiter entwickelt, die den Blick von der IT-Lösung auf Geschäftsprozesse bzw. -ziele und umgekehrt erzielt. Zunächst werden verschiedene Ansätze und grundsätzliche Vorgehensmodelle beim ITManagement vorgestellt. Diese Zusammenstellung schafft einen Überblick über geeignete Wege bei IT-Projekten. Beispiele von großen IT-Unternehmen wie Microsoft und Cisco runden den Überblick ab. Aus den verschiedenen Quellen wird zum einen deutlich, welche wesentlichen Elemente bei einer ganzheitlichen Einbindung von IT-Projekten in die Unternehmenszielsetzung nicht fehlen dürfen und zum anderen lässt sich davon ein Modell für ein systematisches IT-Projektmanagement ableiten, das erstmals mit diesem Buch strukturiert vorgestellt wird. Am Beispiel eines typischen IT-Infrastruktur-Projektes wird dann die komplette Vorbereitung, Planung, Umsetzung und Abnahme einschließlich der Verifikation der Anforderungen, Verfügbarkeit, Leistung und Sicherheit vorgestellt. Dabei wird auch der Blick für die Geschäftsstrategie und für die Erwartungen von Kunden und Nutzern geschärft. Aus der strategischen Zielsetzung wird eine Anforderungsanalyse für Prozesse und Strukturen abgeleitet, die mit einer Dokumentation der geschäftlichen und technischen Erwartungen für

X

Vorwort

die Umsetzungen einhergeht. Dazu gehören unter anderem Themen wie Risikoanalyse, Sicherheitskonzept, Notfallrichtlinie und Service-Level-Management, damit die umgesetzten IT-Lösungen die Geschäftsprozesse auch optimal und ganzheitlich unterstützen können. Ziel des vorliegenden Buchs ist es, den Ablauf und die Steuerung von IT-InfrastrukturProjekten zu professionalisieren. Daher wird eine strukturierte Vorgehensweise für das ITProjektmanagement entwickelt, die für Leiter von IT-Infrastrukturprojekten einen sehr hilfreichen Leitfaden bietet, um solche Projekte erfolgreich umzusetzen. Auch weniger routinierte Projektleiter werden mit dieser Handreichung, insbesondere den ausführlichen Checklisten sowie den Struktur- und Ablaufdiagrammen, die wichtigsten Fragestellungen für die erfolgreiche Einbindung dieser Projekte in die jeweilige Geschäftsstrategie und den Leitfaden zur Durchführung solcher Projekte erkennen. Dr. Chris Weck Hauptabteilungsleiter Rundfunk- und Informationstechnik Deutschlandradio

Inhaltsverzeichnis Widmung Danksagung Vorwort Abkürzungsverzeichnis

V VII IX XV

1

Einleitung

1

2

Begriffliche Grundlagen

5

2.1 2.1.1 2.1.2 2.1.3

Methodische und generische Begriffe........................................................................ 5 Prozess ....................................................................................................................... 5 System ....................................................................................................................... 8 Vorgehensmodell........................................................................................................ 9

2.2 2.2.1 2.2.2 2.2.3

Technische Begriffe ................................................................................................. 10 Informationssystem .................................................................................................. 10 IT-Infrastruktur ........................................................................................................ 11 Strukturierte Verkabelung ........................................................................................ 13

3

Vorgehensmodelle und Rahmenwerke

3.1 3.1.1 3.1.2 3.1.3

Verfahrensweisen beim Projektmanagement ........................................................... 15 IT-Projekte ............................................................................................................... 15 PRINCE2 ................................................................................................................. 17 Project Management Body of Knowledge (PMBoK) .............................................. 18

3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5

Modelle zur Softwareentwicklung ........................................................................... 19 Wasserfallmodell...................................................................................................... 20 Systems Development Lifecycle (SDLC) ................................................................ 21 Structured Systems Analysis and Design Methodology (SSADM) ......................... 22 V-Modell .................................................................................................................. 24 Spiralmodell ............................................................................................................. 25

3.3 3.3.1 3.3.2

Systemanalysemodell............................................................................................... 26 Die Ist-Analyse ........................................................................................................ 27 Das Soll-Konzept ..................................................................................................... 29

3.4

CObIT als IT-Governance-Rahmenwerk ................................................................. 29

15

XII

Inhaltsverzeichnis

3.5 3.5.1 3.5.2 3.5.3

Rahmenwerke zum Servicemanagement ..................................................................30 ICTIM und ITSM .....................................................................................................30 ITIL v2 Infrastrukturmanagement ............................................................................30 ITIL v3 Infrastrukturmanagement ............................................................................38

3.6 3.6.1 3.6.2

Herstellerspezifische Rahmenwerke .........................................................................40 Rahmenwerke von Microsoft ...................................................................................40 Der Cisco-Lebenszyklus für Netzwerke ...................................................................43

4

Prozessqualität

4.1

Qualitätsmanagement gemäß ISO 9000ff. ................................................................45

4.2 4.2.1 4.2.2

Reifegradmodelle......................................................................................................47 Capability Maturity Model (CMM) ..........................................................................47 Capability Maturity Model Integration (CMMI) ......................................................48

5

Organisation von Prozessen

5.1 5.1.1 5.1.2 5.1.3

Erfassung und Analyse von Prozessen......................................................................49 Kundenorientierung ..................................................................................................50 Die Ist-Aufnahme .....................................................................................................51 Die Analyse ..............................................................................................................53

5.2 5.2.1 5.2.2

Planung von Prozessen .............................................................................................55 Strategische Planung .................................................................................................55 Operative Planung ....................................................................................................58

5.3 5.3.1 5.3.2 5.3.3

Beschreibung von Prozessen ....................................................................................59 Prozesskonzept .........................................................................................................59 Prozessdokumentation ..............................................................................................63 Prozessmodellierung .................................................................................................63

5.4

Einführung von Prozessen ........................................................................................67

5.5

Steuerung von Prozessen ..........................................................................................68

6

Methodik zur Definition und Strukturierung des Infrastrukturerrichtungsprozesses

45

49

71

6.1

Projektvarianten ........................................................................................................71

6.2

Projektmanagement ..................................................................................................72

6.3

Pilotnutzer.................................................................................................................73

7

Infrastrukturerrichtungsprozess: Die Ist-Situation

7.1

Der Markt und die Kunden .......................................................................................75

7.2

Die Prozessreife ........................................................................................................80

75

Inhaltsverzeichnis

XIII

8

Infrastrukturerrichtungsprozess: Die Definition

83

8.1

Zweck eines ITI-Projekts ......................................................................................... 83

8.2 8.2.1

Die Ziele .................................................................................................................. 85 Strategische Ziele ..................................................................................................... 85

8.3

Operative Ziele ........................................................................................................ 87

8.4

Weitere wesentliche Prozessattribute ....................................................................... 89

9

PAPRO-Prozess: Die Struktur

9.1 9.1.1 9.1.2 9.1.3 9.1.4

Zusammenstellung der verschiedenen Modelle und Ansätze................................... 95 Zyklische Modelle ................................................................................................... 95 Sequentielle Modelle ............................................................................................... 96 Management-Rahmenwerke .................................................................................... 98 Weitere Ansätze ..................................................................................................... 100

9.2 9.2.1 9.2.2 9.2.3 9.2.4 9.2.5

Teilprozesse ........................................................................................................... 102 TP AN Analyse ...................................................................................................... 102 TP PL Planung ....................................................................................................... 115 TP RE Realisierung................................................................................................ 127 TP OP Betriebsaufnahme ....................................................................................... 135 TP PM Projektmanagement ................................................................................... 140

9.3

Die Gesamtstruktur ................................................................................................ 142

10

PAPRO-Prozess: Der Ablauf

10.1

Teilprozess PM Projektmanagement ...................................................................... 146

10.2 10.2.1 10.2.2 10.2.3

Teilprozess AN Analyse ......................................................................................... 146 Prozessschritt PS AN1 Ist-Analyse ........................................................................ 147 Prozessschritt PS AN2 Soll-Aufnahme .................................................................. 148 Prozessschritt PS AN3 Alternativenbewertung ...................................................... 148

10.3 10.3.1 10.3.2 10.3.3 10.3.4 10.3.5

Teilprozess PL Planung .......................................................................................... 148 Prozessschritt PL1 Logisches Design .................................................................... 150 Prozessschritt PL2 Physisches Design ................................................................... 151 Prozessschritt PL3 Sicherheit ................................................................................ 152 Prozessschritt PL4 Realisierungsvorbereitung ....................................................... 152 Prozessschritt PL5 Betriebsvorbereitung ............................................................... 153

10.4 10.4.1 10.4.2 10.4.3 10.4.4

Teilprozess RE Realisierung .................................................................................. 153 Prozessschritt RE1 Beschaffung ............................................................................ 154 Prozessschritt RE2 Umsetzung .............................................................................. 155 Prozessschritt RE3 Integrationstest ........................................................................ 155 Prozessschritt RE4 Rollout .................................................................................... 156

10.5 10.5.1 10.5.2 10.5.3

Teilprozess OP Betriebsaufnahme ......................................................................... 157 Prozessschritt OP1 Objektverwaltung ................................................................... 157 Prozessschritt OP2 Überwachung .......................................................................... 158 Prozessschritt OP3 Steuerung ................................................................................ 158

93

145

XIV

Inhaltsverzeichnis

11

PAPRO-Prozess: Die Realisierung

159

11.1

Typische Vorurteile .................................................................................................159

11.2

Typische Fehler.......................................................................................................160

11.3

Rollenbezogene Aspekte.........................................................................................161

11.4 11.4.1 11.4.2

Der Prozessanlauf ...................................................................................................162 Einfrieren des Prozesses .........................................................................................162 Prozessanalyse ........................................................................................................162

11.5

PAPRO-Spezifika ...................................................................................................164

12

Beispiel für die Planung einer IT-Infrastruktur

12.1

Auftraggeber und Auftragnehmer ...........................................................................167

12.2

Projektinitiierung ....................................................................................................168

12.3 12.3.1 12.3.2 12.3.3

Analyse ...................................................................................................................171 Prozessschritt AN1 Analyse ....................................................................................171 Prozessschritt AN2 Soll-Aufnahme ........................................................................177 Prozessschritt AN3 Alternativenbewertung ............................................................181

12.4 12.4.1 12.4.2

Planung ...................................................................................................................184 Sicherheitskonzept ..................................................................................................185 Betriebsvorbereitung ..............................................................................................186

167

Literatur

189

Index

193

Abkürzungsverzeichnis BPMN BSI CEO CFO CI CIO CMDB CMMI DIN DV EPK ICT IKT ISEP ITI ITIL ITIM ITSG ITSM ITT KPI MAN MOF MSF OGC OLA OSPF OSI PPDIOO RADIUS SAN

Business Process Modeling Notation Bundesamt für Sicherheit in der Informationstechnik Chief Executive Officer Chief Financial Officer Configuration Item Chief Information Officer Configuration Management Database Capability Maturity Model Integration Deutsches Institut für Normung Datenverarbeitung Ereignisgesteuerte Prozesskette Information and Communication Technology (siehe auch IKT) Informations- und Kommunikationstechnologie Infrastrukturerrichtungsprozess (Prozess zur Errichtung einer IT-Infrastruktur) IT-Infrastruktur IT Infrastructure Library IT Infrastructure Management IT Steering Group IT Service Management Invitation to Tender Key Performance Indicator Metropolitan Area Network Microsoft Operations Framework Microsoft Solutions Framework Office of Government Commerce Operational Level Agreement Open Shortest Path First Open Systems Interconnection Prepare, Plan, Design, Implement, Operate, Optimize Remote Authentication Dial-In User Service Storage Area Network

XVI SDSL SLA SLR SOR SPS SSH UML VoIP VPN WWW

Abkürzungsverzeichnis Symmetric Digital Subscriber Line Service Level Agreement Service Level Requirement Statement of Requirements Speicherprogrammierbare Steuerung Secure Shell Unified Modeling Language Voice over IP Virtual Private Network World Wide Web

1

Einleitung Wer nicht weiß, wo er hin will, darf sich nicht wundern, wenn er woanders ankommt. Mark Twain

Hey Joe! Nein, Hey-Joe ist kein neues japanisches System zur Qualitätsoptimierung. „Hey Joe!“ heißt einfach „Hallo Josef!“ und ist ein gängiger Begriff bei externen und internen ITDienstleistern, wenn es um die schnelle Hilfe von Kollege zu Kollegin geht. Gemeint ist: „Hallo Josef! Kannst Du mir hier schnell mal helfen? Ich komme gerade nicht weiter...“ Die Antwort lautet: „Klar. Muss doch gemacht werden...“ Oder die Mitarbeiterin aus der Buchhaltung trifft IT-Joe beim Mittagessen und sagt: „Hey, könntest du nicht mal schnell auf meinem Rechner die Synchronisationssoftware für mein Smartphone installieren?“ Die Antwort: „Ich denke, das kriegen wir heute noch hin ...“ Nun, wer sollte etwas gegen so ein kundenfreundliches und kollegiales Handeln von IT-Servicemitarbeitern einzuwenden haben? Was auf der kollegialen Ebene in der IT-Abteilung möglich ist, spielt sich auch in der Vertikale der Organisation des Öfteren ab. Welcher IT-Joe kennt nicht die Situation, dass der IT-Leiter auf ihn zukommt und sagt: „Hallo Herr Fleißig, wir müssen für unseren Kunden diese Woche unbedingt einen Server XY zur Verfügung stellen, auf dem er seine Datenbank YZ betreiben kann. Wie ich Sie kenne, können Sie das sicher bis morgen auf die Beine stellen!?“ Das Problem ist erst unter der Oberfläche erkennbar. Das Hey-Joe-Prinzip repräsentiert das Ad-hoc-Vorgehen in Ermangelung oder unter Umgehung etablierter Prozesse. Das Ziel der Einführung und Umsetzung von Prozessen ist nicht, die Zusammenarbeit umständlicher und komplizierter zu machen. Es geht vielmehr darum, sich wiederholende Abläufe effektiver und effizienter zu gestalten. Angemessene und klar definierte Prozesse erhöhen die Qualität von Dienstleistungen und Produkten. Insbesondere sinkt die Fehlerrate bei der Erstellung von Dienstleistungen und Produkten. Industrialisierung der IT Seit einigen Jahren wird das Schlagwort „Industrialisierung der IT“ wörtlich oder sinngemäß regelmäßig in Publikationen behandelt. Krcmar und Böhmann schreiben im Jahr 2004 in HMD – Praxis der Wirtschaftsinformatik (Heft 237): „IT-Verantwortliche in Unternehmen sehen sich wachsenden Ansprüchen gegenüber. Ihre Aufgabe wird immer weniger in der Entwicklung und dem Betrieb von Informationstechnik (IT) gesehen, sondern in der Erbringung von Dienstleistungen, durch die IT bedarfsgerecht, effizient und mit hoher Qualität bereitgestellt wird.“ Michael Shipton, damals CEO von Swisscom IT Services, konstatiert im Jahr 2006 in der Neue Zürcher Zeitung: „Ein einwandfreies Funktionieren der Infrastruktur ist eine kritische Größe für das Gelingen der Geschäftsprozesse und letztlich für den

2

1 Einleitung

Erfolg einer Unternehmung beziehungsweise ihres Geschäftsmodells … Ziel muss es … sein, Transparenz zu schaffen sowie Prozesse und IT zu standardisieren und zu automatisieren.“ Und Zarnekow nennt sein 2007 erschienenes Buch „Produktionsmanagement von ITDienstleistungen“. Ein wichtiger Aspekt der Industrialisierung ist die Prozessorientierung. Diese Orientierung ist in IT-Rahmenwerken wie CObIT und ITIL ohne Weiteres erkennbar. Kaum ein ITService-Provider kann es sich heutzutage leisten, die bewährten Rahmenwerke für ITServices zu ignorieren. Aber während im Bereich der Systemwartung die Industrialisierung schon relativ weit fortgeschritten ist, ist diese im Bereich der Planung und Realisierung von IT-Infrastrukturen noch wenig ausgeprägt. Was ist mit den Unternehmen oder Teams, deren Ziel oder Aufgabe es ist diese Infrastrukturen zu planen und bereitzustellen? Ist hier Industrialisierung und Prozessorientierung machbar und sinnvoll? Welche Ansätze gibt es? Der Zweck des Buchs Wasserfall, Spirale, V-Modell, das sind vertraute Begriffe für Systementwickler. Vorgehensmodelle sind in der Softwareentwicklung seit vielen Jahren etabliert. Beispielsweise wurde das Wasserfallmodell bereits 1970 von W.W. Royce als Weiterentwicklung eines einfachen Phasenmodells vorgestellt. Im Software-Engineering ist die Auffassung kaum bestritten, dass Vorgehensmodelle dabei helfen, die Softwareentwicklung übersichtlicher zu gestalten und in der Komplexität beherrschbar zu machen. Wie ist aber die Lage bei Projekten zur Errichtung von IT-Infrastrukturen? Als Infrastrukturberater hatte ich in den 90er Jahren hierfür ein Vorgehensmodell kennen gelernt. Es hieß „Plan – Build – Run“1 und war ein primitives Phasenmodell aus der Praxis. Ich hatte aber kaum Details dazu erfahren. In den letzten zehn Jahren habe ich meine Studierenden nicht selten mit der Forderung konfrontiert, ihre Abschlussarbeiten aus dem Themenbereich IT-Infrastrukturen methodisch angemessen zu planen. Die Ausbeute war mager. Die Methodik war überwiegend handgemacht oder aus Softwareentwicklungsmodellen adaptiert, und es gab nur wenig konkrete Literaturhinweise. Schuld war nicht zuerst die Bequemlichkeit der Studierenden, sondern die nach wie vor unbefriedigende Quellenlage. Meine Recherchen haben ergeben, dass die Literatur zum Thema relativ schnell erschöpft ist. Die meines Erachtens ergiebigsten Quellen sind englischsprachig ([OPP2010], [PIL2005]). Als deutschsprachige Quelle von Interesse lässt sich [LAR1997] nennen, hier fehlt aber eine solide theoretische Fundierung. Mit diesem Buch soll ein Vorgehensmodell für die Planung und Realisierung von ITInfrastrukturen vorgelegt werden. Ein wesentlicher Bestandteil des Vorgehensmodells ist die Definition eines zugehörigen Prozesses. Das prozessorientierte Modell soll einen Beitrag zur Erhöhung der Qualität und Effizienz von IT-Infrastrukturprojekten leisten. Die wichtigen Anforderungen des Autors an sein Werk sind eine klare Struktur, eine tragfähige, theoretische Basis, eine verständliche Darstellung und die Praxistauglichkeit der Ausführungen. Die Ausführungen sind nicht nur, aber in erster Linie für leitende und operative Mitarbeiter aus IT-Dienstleistungsorganisationen und -einheiten gedacht. Es liegt daher auf der Hand,

1

siehe auch [ZHB2005, S.4]

1 Einleitung

3

dass dieses Buch auch auf konkrete technische Fragestellungen und Fälle Bezug nimmt. Es steht aber nicht die Technik im Vordergrund des Buchs, sondern die Methoden zur Errichtung von IT-Infrastrukturen, insbesondere IT-Netzwerken. Die Methodik des Buchs Basis der Ergebniserzielung war eine intensive Literaturrecherche. Es wurden Bücher, Fachzeitzeitschriften und Internetquellen recherchiert, die für das Thema unmittelbar oder indirekt relevant waren. Die Herleitung des Vorgehensmodells geschah weitgehend deduktiv, also ausgehend vom Allgemeinen und gefolgt von schrittweiser Spezialisierung. Aus dieser Vorgehensweise resultiert auch der Aufbau des Buches. Zunächst werden die für das Buch besonders relevanten Begriffe definiert. Anschließend werden generische Vorgehensmodelle und solche aus Nachbardisziplinen vorgestellt. Dann werden Prinzipien der Prozessorganisation vermittelt. Und schließlich werden diese Grundlagen genutzt, um den Prozess der Planung und Implementierung von IT-Infrastrukturen schrittweise zu definieren und zu veranschaulichen. Getestet wurden die Ergebnisse mit Hilfe von Praxispartnern, die im Rahmen von Interviews zum Thema Stellung nahmen und Prozesselemente in ihrem Tätigkeitsumfeld testeten.

2

Begriffliche Grundlagen Der Beginn der Weisheit ist die Definition der Begriffe. Sokrates

Die Klarheit beim praktischen Handeln wird dadurch gefördert, dass die Theorie mit klar definierten Begriffen arbeitet. In der Wirtschaftsinformatik sind nicht alle Begriffe eindeutig und präzise definiert. Damit ist dieses Fachgebiet in guter Gesellschaft mit anderen Wissenschaftszweigen. In solchen Fällen ist es umso wichtiger Klarheit herbeizuführen, indem eine in sich schlüssige und zweckgerechte Definition herausgearbeitet und zugrundegelegt wird. Es ist vielleicht nicht immer die Beste aller Möglichen oder die Einzige unter den Angemessenen, aber es ist methodisch nicht zielführend, nur bei einer vergleichenden Betrachtung verschiedener Definitionsmöglichkeiten stehen zu bleiben, da der Leser dann nur eine unklare Basis für sein Denken und Anwenden hat.

2.1

Methodische und generische Begriffe

2.1.1

Prozess Input

Tätigkeit

Tätigkeit

Tätigkeit

Output

Abbildung 1: Prinzipieller Ablauf eines Prozesses

Gemäß DIN EN ISO 9000:2005 ist ein Prozess ein „Satz von in Wechselbeziehungen oder Wechselwirkung stehenden Tätigkeiten, der Eingaben in Ergebnisse umwandelt.“ Wesentlich für einen Prozess ist neben dem Tätigkeitsmuster also das Vorhandensein eines Inputs und eines Outputs. Definierende Eigenschaften des Prozesses 1. eine nichtleere Menge von Tätigkeiten 2. die Vorgänger- beziehungsweise Nachfolgerbeziehung in der Tätigkeitsstruktur 3. Start- und Endpunkt 4. Input und Output 5. die Wiederholbarkeit der Tätigkeiten

6

2 Begriffliche Grundlagen

Input

Informationen

Aufgaben

Menschen

Sachmittel

Ein Prozess2 hat eine Tätigkeitsstruktur, die von einem definierten Startpunkt zu einem definierten Endpunkt führt. Ein Prozessschritt in einem Prozess kann selbst wieder ein Prozess sein (Subprozess, Teilprozess). Das Ergebnis eines Prozessdurchlaufs ist ein materielles oder immaterielles Produkt. Von einem Projekt unterscheidet sich der Prozess vor allem darin, dass die Tätigkeitsstruktur wiederholt durchlaufen werden kann und die Wiederholung beabsichtigt und gewünscht ist. Ansonsten sind sowohl der Prozessdurchlauf als auch das Projekt zeitlich begrenzt. Für Projekte gibt es im Gegensatz zu Prozessen konkrete Anfangs- und Endtermine. Der Ort der Ausführung oder die ausführenden Personen müssen bei Prozessen nicht konstant sein. Wenn man also regelmäßig IT-Netzwerkprojekte durchführt, die dieselbe Tätigkeitsstruktur aufweisen, aber mit verschiedenen Kunden oder an unterschiedlichen Orten oder mit anderen Mitarbeitern durchgeführt werden, so hat man es mit jeweils einzigartigen Projekten zu tun, die sich aber einem Prozess zuordnen lassen. Jedes Projekt kann man als Prozessdurchlauf ansehen.

Output

Prozessschritte

Prozessziele

(Ergebnis)

Prozessindikatoren

Abbildung 2: Übliche Prozesselemente

In Abbildung 2 wird deutlich, dass Aufgaben, Menschen, Sachmittel und Informationen wichtige Hilfsmittel bei der Durchführung des Prozesses sind. Bezüglich des Begriffs „Prozessobjekt“ gibt es in der Literatur unterschiedliche Ansichten.3 Im Folgenden verstehen wir unter dem Prozessobjekt (das auch „Bearbeitungsobjekt“ genannt wird) den Gegenstand, der im Prozess bearbeitet wird. Der Output pro Prozessdurchlauf ist dann das Ergebnis der Bearbeitung des Objekts.

2

bei Behörden in der Regel unter dem Begriff „Verfahren“ geläufig

3

siehe zum Beispiel [SSE2008, S. 133], [GAD2009, S. 251]

2.1 Methodische und generische Begriffe

7

Tabelle 1: Beispiel: Motorenproduktion

Input Prozessobjekt Output

Konstruktionszeichnung, Stückliste, ggf. Bestellung Motorenteile Motor

Die Durchlaufzeit (DLZ) eines Prozesses gibt Auskunft über die Zeitdauer eines Prozessdurchlaufs, entspricht also der Durchlaufzeit der längsten Teilprozesskette. Die Zykluszeit (ZZ) errechnet sich durch Addition der Prozesszeiten DLZx aller Teilprozesse, gibt also Auskunft über den Zeitaufwand eines Prozessdurchlaufs. Beide Zeiten können sich im Laufe der Zeit ändern. In der Abbildung 3 ist DLZ gleich DLZ1.

Abbildung 3: Prozesszeiten

In einem Teilprozess sind üblicherweise Transport-/ oder Liegezeiten zu berücksichtigen. Die Durchlaufzeit ergibt sich als Summe von: Arbeitszeit, Transportzeit und Liegezeit. Arbeitsgangnummer Transport-/ 297

Liegezeiten

298 299 07:00

08:00

Abbildung 4: Prozessdurchlauf

09:00

10:00

11:00

Zeit /Uhr

8

2 Begriffliche Grundlagen

Geschäftsprozess und Unterstützungsprozess Ein Geschäftsprozess ist ein Prozess, der wertschöpfende Aktivitäten derart miteinander verknüpft, dass die von Kunden erwarteten Leistungen erbracht werden.4 Einen Prozess, der einen oder mehrere Geschäftsprozesse unterstützt, selbst aber keinen direkten Nutzen hat, nennt man „Unterstützungsprozess“ oder „Supportprozess“. IT-Prozesse sind in der Regel Unterstützungsprozesse. IT-Prozesse haben bei der Unterstützung von Geschäftsprozessen heutzutage jedoch solch eine grundlegende Bedeutung, dass deren Wert nicht unterschätzt werden sollte.

2.1.2

System

In vielen Bereichen der Wissenschaft und Gesellschaft wird der Systembegriff verwendet, um Gemeinsamkeiten bestimmter Objektansammlungen zu beschreiben. Ein System ist eine nichtleere Menge von Elementen, zwischen denen es Beziehungen gibt.5 Definierende Eigenschaften eines Systems 1. Es besteht aus einer Menge von Elementen. 2. Die Menge ist nicht leer. 3. Zwischen den Elementen gibt es Beziehungen. Üblicherweise sind die Grenzen eines Systems durchlässig (offenes System). Es gibt also Eingaben (Input) und Ausgaben (Output) und somit auch Schnittstellen an den Systemgrenzen, die die Ein- und Ausgaben ermöglichen. Der Input ist der Einfluss der Umwelt auf das System. Der Output ist der Einfluss des Systems auf die Umwelt.

Input Element 1 Element 2 Element 3

Element 4

Output

Abbildung 5: Abstraktes System

4 5

[SSE2008, S.64] [HEI2007, S.7]

2.1 Methodische und generische Begriffe

9

Der Spezialfall eines abgeschlossenen Systems ist denkbar. Dort existieren keine Inputs und Outputs. In der Thermodynamik wird als Beispiel gerne ein wärmeisolierter Behälter (Thermoskanne) genannt. Damit hier die Systemeigenschaften erfüllt sind, muss allerdings irgendwann einmal der Behälter der Außenwelt ausgesetzt worden sein. Sonst wäre der Behälter leer und somit Eigenschaft 2 nicht erfüllt. Es ist leicht zu erkennen, dass auch ein Prozess ein System ist. Es handelt sich um ein offenes System von Tätigkeiten, die von einem Startpunkt zu einem Endpunkt führen und bei dem viele in einer Vorgänger- beziehungsweise Nachfolgerbeziehung stehen. Wenn man es mit einem System zu tun, dann lassen sich auch die Methoden der Systemtheorie anwenden. Ein wichtiges Beispiel ist die sogenannte Systemanalyse, auf die in Kapitel 3 eingegangen wird.

2.1.3

Vorgehensmodell

Die Fachgruppe „Vorgehensmodelle für die betriebliche Anwendungsentwicklung“ der Gesellschaft für Informatik6 versteht unter einem Vorgehensmodell eine Beschreibung „der Aufbau- und Ablauforganisation von Projekten zur Entwicklung und Wartung von Anwendungssystemen“. Verallgemeinert kann man formulieren: Ein Vorgehensmodell ist eine Beschreibung der Aufbau- und Ablauforganisation von Projekten zur Entwicklung und Wartung von Systemen. Die Aufbau- und Ablauforganisation von Projekten kann man sinngemäß durch den Begriff „Prozess“ ersetzen. So lässt sich schließlich kürzer fassen: Ein Vorgehensmodell ist eine Beschreibung des Prozesses zur Entwicklung und Wartung von Systemen. Diese Definition lässt sich auch auf IT-Infrastrukturen anwenden. In den folgenden Kapiteln soll ein Vorgehensmodell für die Planung und Realisierung von IT-Infrastrukturen entworfen werden. Dazu muss ein entsprechender Prozess beschrieben werden. In der englischsprachigen Literatur wird die Differenzierung zwischen Prozess und Vorgehensmodell nicht immer vorgenommen. Es bietet sich dennoch an, hier zu unterscheiden. Denn die „Beschreibung eines Prozesses“ ist nicht identisch mit dem Prozess als solchem. Im Prozessmanagement ist der Aspekt Prozessmodellierung wesentlich. Der Begriff Vorgehensmodell lässt darauf schließen, dass der Schwerpunkt der Betätigung auf dem Ablauf des Prozesses liegt. Prozessabläufe werden üblicherweise durch Diagramme veranschaulicht. Die grafische Veranschaulichung des Prozessablaufs bei der Planung und Realisierung von ITInfrastrukturen ist ein wichtiger Teil des Buchs. Man kann festhalten, dass das Vorgehensmodell ein wesentlicher Bestandteil des Prozesses ist und mit der Darstellung beziehungsweise Veranschaulichung des Prozesses gleichgesetzt werden kann.

6

http://www.wi-vm.gi-ev.de/

10

2 Begriffliche Grundlagen

2.2

Technische Begriffe

2.2.1

Informationssystem

Ein Informationssystem ist ein System, bei dem  die Systemelemente Maschinen, Maschinenteile oder Menschen sind und  der Informationsaustausch die Beziehung zwischen den Elementen darstellt. Die Systemelemente sind imstande Informationen zu verarbeiten, zu speichern oder zu übertragen. Als Beispiel bietet sich das bekannte Computermodell von John von Neumann an:

Prozessor

Steuerbus Adressbus Datenbus Hauptspeicher (Arbeitsspeicher)

Ein-/Ausgabewerk

Abbildung 6: Zentraleinheit des Von-Neumann-Computers

Hier handelt es sich um eine Maschine, bei denen Maschinenelemente über den Systembus (Datenbus, Adressbus, Steuerbus) Daten austauschen. Man kann sich einen Von-NeumannComputer als geschlossenes System, also ohne angeschlossene Peripherie vorstellen. Allerdings ist es dann nicht möglich, dem System über die Tastatur oder andere Eingabegeräte Daten zuzuführen. Somit kann die Zentraleinheit dann auch keine Daten speichern oder verarbeiten oder ausgeben. Infolgedessen ist ein Von-Neumann-Computer nur dann eine sinnvolle Idee, wenn das System offen ist, also Inputs und Outputs möglich sind. Die Elemente des Computers, die Inputs und Outputs ermöglichen, heißen Peripheriekomponenten. Es sollte beachtet werden, dass der Begriff „Informationssystem“ nicht mit „Computersystem“ gleichzusetzen ist, auch wenn wir uns heutzutage daran gewöhnt haben, dass Computer häufig Bestandteil von Informationssystemen sind. Wenn sich zwei Schiffe auf dem Meer Morsesignale per Licht zusenden, dann handelt es sich gemäß Definition auch um ein Informationssystem. Wenn ein Wirt seine mit Preisen versehene Speisekarte draußen an der Gaststätte aushängt, ist auch das ein Informationssystem (Wirt, Karte, Betrachter der Karte).

2.2 Technische Begriffe

2.2.2

11

IT-Infrastruktur

Den Begriff Infrastruktur kann man auch als „Unterbau“ bezeichnen. Es kann der Unterbau der Volkswirtschaft eines Staates sein, sich aber genauso auch auf eine Region, ein Gelände oder Gebäude beziehen. Infrastruktur ist Voraussetzung für das Funktionieren der Wirtschaft. In Europa gibt es nicht zuletzt wegen der unterschiedlich gut ausgebauten Infrastrukturen deutliche wirtschaftliche Leistungsunterschiede. Häufig gehören zur Infrastruktur Netze (Energieversorgungsnetz, Straßennetz usw.). Unter IT-Infrastruktur (im Folgenden auch „ITI“ genannt) ist die informationstechnologische beziehungsweise informationstechnische Infrastruktur zu verstehen. Sie ist der Unterbau für die Anwendungssoftware. Eine IT-Infrastruktur ist eine Ansammlung von Computern, Peripheriegeräten und Netzwerkkomponenten in einem Gebäude oder auf einem Gelände inklusive der für den Betrieb dieser Geräte benötigten Systemsoftware. Die Geräte können, aber müssen nicht miteinander vernetzt sein. Die zugehörigen Personen, Prozesse und Dokumente werden nicht unter diesen Begriff subsummiert. In Unternehmen gibt es nicht zuletzt wegen der unterschiedlich leistungsfähigen IT-Infrastrukturen deutliche wirtschaftliche Leistungsunterschiede. Router

Internet

Server 1 Switch

Switch

Switch

Server 2

Host 1

Host 2

Server 3

Abbildung 7: Beispiel eines kleinen lokalen Netzwerks

In vielen Fällen besteht eine IT-Infrastruktur in erster Linie aus IT-Netzwerken. ITNetzwerke sind räumlich verteilte Systeme von Computern (Frontends, Server) und Peripheriegeräten, die durch Datenübertragungseinrichtungen und -wege miteinander verbunden sind7. Hauptsächlich unterscheidet man Weitverkehrsnetze (WAN) und lokale Netzwerke (LAN).

7

[BRE1994, S.33]

12

Abbildung 8: Wide Area Network (WAN)

2 Begriffliche Grundlagen

8

Um zu klären, ob es sich bei einer IT-Infrastruktur um ein System handelt, sind die oben dargestellten definierenden Eigenschaften zu prüfen. Es handelt sich offensichtlich um eine nichtleere Menge von Elementen. Stehen diese aber in einer Beziehung zueinander? Bei einem IT-Netzwerk ist die Frage leicht positiv zu beantworten: Die Elemente des Netzwerks sind miteinander verbunden, damit zwischen einzelnen Netzwerkelementen Daten übertragen werden können. Sie stehen also in einer Beziehung des Datenaustauschs. IT-Netze sind demnach Systeme. Gehen wir nun alternativ davon aus, dass die IT-Infrastruktur nur aus einer Ansammlung von 10 PCs für ein Ingenieurbüro handelt, die untereinander nicht vernetzt sind und von denen nur einer einen Internetanschluss besitzt. Somit fehlt den Computern die Beziehung des bei IT-Netzen vorhandenen Datenaustauschs. Auch andere Beziehungen sind zunächst nicht erkennbar. Eine Ansammlung von Computern ist also per se noch kein System. Es ist auch nicht ausreichend, dass die Computer für sich genommen selbst Systeme sind. Damit aus dieser Menge von Computern ein System wird, ist die Menge um die Computernutzer – also die Ingenieure und der Bürochef – zu erweitern. Bei diesem System stehen die Arbeitsziele und -beziehungen der Mitarbeiter untereinander im Vordergrund. Die Computer haben jetzt nur noch untergeordnete Funktion. Sie sind dem System „Ingenieurbüro“ unterstützend zugeordnet.

8

http://ictf.cs.ucsb.edu/archive/iCTF_2004/ctf-topology.png

2.2 Technische Begriffe

13

Diese Betrachtung ist insofern relevant, als es für die Anwendung von systemtheoretischen Methoden wie der Systemanalyse wichtig ist, sich zunächst zu vergewissern, ob es sich bei dem Betrachtungsgegenstand tatsächlich um ein System handelt und welchen Umfang das System hat.

2.2.3

Strukturierte Verkabelung

Bei der Installation der Netzwerkverkabelung ist es in Europa mittlerweile üblich, sich an die Norm EN 50173-1 für Anwendungsneutrale Verkabelungssysteme zu halten, welche auch als DIN-Norm veröffentlicht worden ist. Es wird unterschieden zwischen Primär-, Sekundärund Tertiärverkabelung:

Gebäudeverkabelung Etagenverkabelung

Etagenverkabelung EV

EV AD

AD

AD

AD

AD

AD

AD

AD

AD

AD

AD

AD

EV

GV

AD

AD

AD

AD

AD

AD

AD

AD

AD

AD

AD

EV

EV LV

AD

EV LV

GV

Geländeverkabelung Legende LV Liegenschaftsverteiler EV Etagenverteiler GV Gebäudeverteiler AD Anschlussdose

Abbildung 9: Strukturierte Verkabelung



Primärverkabelung (auch Campus- oder Geländeverkabelung genannt) – Verbindungen zwischen Gebäuden eines Geländes (Campus) – meist LWL-Kabel9 , aber auch Funkverbindungen (zum Beispiel Richtfunk) Sekundärverkabelung (auch Gebäudeverkabelung genannt) – Verbindungen innerhalb eines Gebäudes vom Gebäudeverteiler zu den Etagenverteilern – sowohl Kupferkabel (Twisted Pair) als auch LWL-Kabel Tertiärverkabelung (auch Etagenverkabelung genannt) – meist Kupferkabel (Twisted Pair)10





9

LWL bedeutet „Lichtwellenleiter“; gleichbedeutend mit „Glasfaser“ Heutzutage wird im Tertiärbereich manchmal auf Verkabelung zugunsten drahtloser Technologien verzichtet.

10

14

2 Begriffliche Grundlagen –

Abschnitt vom Etagenverteiler bis zum Endgerät, bestehend aus • dem Patchkabel von der aktiven Komponente zum Patchfeld, • dem Patchfeld, • dem Verlegekabel zwischen Patchfeld und Anschlussdose, • der Anschlussdose und • dem Anschlusskabel zwischen Anschlussdose und Netzwerkadapter

3

Vorgehensmodelle und Rahmenwerke Wer hohe Türme bauen will, muss lange beim Fundament verweilen. Anton Bruckner

Ein Kernelement dieses Buchs ist die Präsentation eines Vorgehensmodells für die Planung und Einführung von IT-Infrastrukturen. Es ist deshalb wichtig zur Kenntnis zu nehmen, welche Vorgehensmodelle in der Informatik Verbreitung gefunden haben und ob beziehungsweise wie diese Modelle für die Einführung von IT-Infrastrukturen anwendbar sind. Da es sich um kein allgemeines Buch über Vorgehensmodelle handelt, sind die Modelle aus den Bereichen Projektmanagement, IT-Management und Softwareentwicklung nachfolgend jeweils nur knapp beschrieben. Bei vertieftem Interesse an einem Modell und an detaillierteren Informationen wird der Leser in der Literaturliste fündig. Es geht in unserem Zusammenhang nicht zuerst um die Darlegung der aktuellsten Modelle, sondern in erster Linie um bewährte, übersichtliche Modelle mit Transferpotenzial.

3.1

Verfahrensweisen beim Projektmanagement

Es ist wichtig Projekte zu planen, zu kontrollieren und zu steuern, denn die Projektziele Qualität und Wirtschaftlichkeit müssen erreicht werden. Die DIN 69901 definiert Projektmanagement als „Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Abwicklung eines Projekts“. Die Auswahl und der Einsatz von angemessenen Führungstechniken haben einen erheblichen Einfluss auf die Erreichung der genannten Projektziele. Verfahren zum allgemeinen Projektmanagements sollten nicht vernachlässigt werden, stehen aber nicht im Zentrum des Themas. Daher sind die folgenden bewährten Methoden und Ideen nur relativ kurz beschrieben. Mehr Details kann man in [OGC2009] und [PMI2008] finden.

3.1.1

IT-Projekte

Es gibt diverse Arten von IT-Projekten Die meisten fallen in eine der Kategorien 

Strategieprojekte,



Organisationsprojekte,



Softwareentwicklungsprojekte,



Infrastrukturprojekte.

16

3 Vorgehensmodelle und Rahmenwerke

Geschäftsstrategie Geschäftswachstum

Effizienter Geschäftsbetrieb

Infrastrukturstrategie

Sourcingstrategie Applikationsstrategie

Innovationsstrategie

Investmentstrategie

Abbildung 10: Bestandteile einer IT-Strategie11

Projekttypen Strategieprojekte beschäftigen sich mit der IT-Strategie. Diese besitzt die Komponenten 

Applikationsstrategie



Infrastrukturstrategie



Sourcingstrategie



Innovationsstrategie



Investmentstrategie

Organisationsprojekte haben üblicherweise den Aufbau oder die Änderung der Struktur der IT-Organisation zum Thema. In einem Softwareentwicklungsprojekt geht es meist darum, ein Anwendungssystem – maßgeschneidert oder als Standardprodukt – zu programmieren. Natürlich gibt es auch Projekte zur Entwicklung von Systemsoftware. Infrastrukturprojekte schließlich haben den Aufbau oder die Änderung der IT-Infrastruktur einer Organisation zum Ziel. Für unsere Zwecke stehen die Infrastrukturprojekte im Fokus. Zu den anderen Projekttypen gibt es allerdings mehr Material, und einiges davon besitzt Transferpotenzial für unser Thema. Brugger schlägt in seinem Buch IT-Projekte strukturiert analysieren [BRU2005, S.178] für die Phasen Analyse und Planung als Teil der Lösungsstrategie unabhängig vom Projekttyp folgende allgemeine Arbeitsschritte vor: 

Analyse – Situationsanalyse – Problemformulierung



Planung – Zielformulierung – Lösungsentwurf

11

in Anlehnung an: ILTIS GmbH, http://www.4managers.de

3.1 Verfahrensweisen beim Projektmanagement

17

– Bewertung der Lösungen – Entscheidung für eine Lösung Die Situationsanalyse kann man in sechs Schritten absolvieren: 1. Systemgrenzen definieren 1. Einflussgrößen ermitteln 2. Unter- und Teilsysteme abgrenzen 3. Schnittstellen bestimmen 4. Analysieren von Unter- und Teilsystemen 5. Gemeinsame Elemente ermitteln Brugger verweist auf die Unterschiede zwischen den Was- und den Wie-Fragen und betont, dass die Was-Fragen das Fachkonzept und die Wie-Fragen das DV-Konzept12 definieren. Das heißt, der Lösungsentwurf sollte hier konzeptionell differenzieren. Vor Beendigung des technologieunabhängigen Fachkonzepts muss sichergestellt sein, dass die Anforderungen an das System bekannt und berücksichtigt sind, da ansonsten die Effektivität der Lösung gefährdet ist. Anforderungsanalyse g g Ermittlung

Formulierung

Überprüfung

Verabschiedung

Abbildung 11: Vorgehen bei der Anforderungsanalyse, in Anlehnung an [BRU2005, S. 122]

Da die korrekte und umfassende Erfassung der Anforderungen ein wichtiger Erfolgsfaktor für IT-Projekte sind, hat sich hier ein Vorgehensmodell (Requirement Engineering) entwickelt, das im Wesentlichen aus den in Abbildung 11 dargestellten Elementen besteht. Wenn Anforderungen analysiert werden, kann es schon bei deren Formulierung zu Verständnisfragen kommen, die eine Nachermittlung erforderlich machen. Des Weiteren sind viele Anforderungen nicht von vornherein bekannt, sondern werden erst während der Gespräche in der Analysephase nach und nach offenbar. Auch nach der Abstimmung der Ergebnisse kann es dazu kommen, dass weitere, möglicherweise bislang unbewusste Anforderungen ersichtlich werden. Es handelt sich also um einen Vorgang, bei dem möglicherweise mehrfach Iterationsschleifen durchlaufen werden müssen.

3.1.2

PRINCE2

PRINCE2 (Projects in a Controlled Environment) ist eine Good-Practice-Methode des britischen Office of Government Commerce zum Management von Projekten, die weltweit

12

Datenverarbeitungskonzept, auch DV-Design oder IV-Konzept genannt

18

3 Vorgehensmodelle und Rahmenwerke

viel Akzeptanz erfahren hat. Die Methode hat einen generischen Charakter und ist deshalb weitgehend unabhängig von Größe und Typ des Projekts anwendbar. PRINCE2 sieht sechs Hauptaspekte von Projekten, die es zu steuern und zu überwachen gilt:  Kosten  Zeit  Qualität  Anwendungsbereich (Scope)  Risiken  Nutzen Es sind folgende Prozesse definiert:       

Vorbereiten eines Projekts Lenken eines Projekts Initiieren eines Projekts Steuern einer Phase Managen der Produktlieferung Managen eines Phasenübergangs Abschließen eines Projekts

3.1.3

Project Management Body of Knowledge (PMBoK)

Der Guide to the Project Management Body of Knowledge (PMBoK Guide) ist ein von dem renommierten Project Management Institute herausgegebenes Buch, das Leitfäden und begriffliche Standardisierung für das Projektmanagement bietet. Seit einigen Jahren wird dieser Ansatz vom US-amerikanischen Standardisierungsinstitut ANSI als Norm geführt [PMI2008]. PMBoK ist prozessorientiert, folglich wird Arbeit als im Rahmen von Prozessen durchgeführte Aktivitäten angesehen. Der Ansatz berücksichtigt die Normenfamilie ISO 9000ff. und besitzt Überschneidungen mit dem Reifegradmodell CMMI. Die Prozesse werden beschrieben mit den Elementen 

Input (Dokumente, Pläne, Konzepte usw.)



Output (Dokumente, Produkte, usw.) und



Werkzeuge und Techniken (Mechanismen, die auf den Input angewendet werden)

Die Anleitung behandelt 42 Prozesse, die in 5 Prozessgruppen aufgeteilt sind: 1. Initiating 2. Planning 3. Executing 4. Monitoring and Controlling 5. Closing

3.2 Modelle zur Softwareentwicklung

Initiating Processes

19

Planning Processes

Controlling Processes

Executing Processes

Closing Processes Abbildung 12: Verbindungen zwischen den Prozessgruppen, in Anlehnung an PMBoK

Die Pfeile repräsentieren Informationsflüsse. Während der Ablauf der Prozessgruppen 1,2,3 und 5 überwiegend seriell ist, begleiten die Prozesse der Prozessgruppe 4 die Prozessgruppen 2,3 und 5 parallel. Weiterhin gibt es neun Wissensbereiche, die für fast alle Projekte relevant sind: 1. Project Integration Management 2. Project Scope Management 3. Project Time Management 4. Project Cost Management 5. Project Quality Management 6. Project Human Resource Management 7. Project Communications Management 8. Project Risk Management 9. Project Procurement Management Da auch diese Anleitung nicht spezifisch auf IT-Projekte ausgerichtet ist, wird hier nicht weiter auf Details eingegangen.

3.2

Modelle zur Softwareentwicklung

Es wird schon seit Jahrzehnten Software entwickelt. H.D. Benington hat bereits 1956 ein Ablaufschema für die Entwicklung von großen Computerprogrammen vorgestellt („Stagewise Model“).13 Spätestens mit der Verbreitung prozeduraler Programmiersprachen wie zum Beispiel FORTRAN und ALGOL in der 60er-Jahren war es möglich, zunehmend komplexe

13

H.D. Benington “Production of Large Computer Programs”, Proceedings, ONR Symposium, June 1956

20

3 Vorgehensmodelle und Rahmenwerke

Programmieraufgaben zu lösen. Wachsende Komplexität führte zu steigendem Bedarf an einer strukturierten Vorgehensweise. Exemplarisch seien hier drei verbreitete beziehungsweise grundlegende Vorgehensmodelle für die Softwareentwicklung dargestellt, die von Relevanz für unser Thema sind.

3.2.1

Wasserfallmodell

In den 70er-Jahren hat sich das Wasserfallmodell als Vorgehensmodell für die Entwicklung von Software entwickelt. Es basiert auf dem Modell von Winston Royce, der 1970 ein Phasenmodell für die Softwareentwicklung vorstellte.

Anforderungen Analyse Entwurf Implementierung Test Betrieb Abbildung 13: Wasserfallmodell der Softwareentwicklung (in Anlehnung an [BAL1998, S. 99])

Das Wasserfallmodell ist ein Ablaufmodell, bei dem die Phasen sequentiell vonstattengehen. Keine der Phasen ist verzichtbar. Zum Output einer Phase gehören fast immer Dokumente. Dokumente der vorangegangen Phase sind Input für die nächste, darauffolgende Phase. Ein Rückschritt in die zurückliegende Phase ist bei festgestellten Problemen möglich. Falls sich beispielsweise ein Fehler, der sich beim Testen zeigt, nicht durch eine Korrektur bei der Implementierung beheben lässt, so kann und muss ein weiterer Rückschritt vollzogen werden. Das Wasserfallmodell gliedert sich häufig in die folgenden sechs Phasen: 1. Anforderungsermittlung – Funktionale Anforderungen: Es geht darum, die Funktionen, die das System (Beispiel: Kundenverwaltung) bieten soll, zu identifizieren. Die Probleme und Wünsche des Kunden beziehungsweise der Nutzer werden aufgenommen. – Technische Anforderungen: Es ist zu klären, wie die Datenhaltung vonstattengehen soll und welche Daten benötigt werden. Auch die Anforderungen an die Leistungsfähigkeit sind Teil der Betrachtung. 2. Analyse In dieser Phase werden die identifizierten Anforderungen analysiert. Die Anforderungen werden sortiert und detailliert spezifiziert. In dieser Phase wird üblicherweise auf Basis

3.2 Modelle zur Softwareentwicklung

3.

4. 5.

6.

21

eines Lastenhefts ein Pflichtenheft erstellt. Das Lastenheft wird vom Auftraggeber, das Pflichtenheft vom Auftragnehmer erstellt. Entwurf Es wird ein konkretes Konzept für die Software beziehungsweise die Softwarearchitektur ausgearbeitet. Die Schnittstellen werden definiert. Testpläne für die Softwarekomponenten werden erstellt. Implementierung Die Codierung in der gewählten Programmiersprache wird vorgenommen. Dabei wird das Konzept umgesetzt. Test Die Softwarekomponenten werden schrittweise getestet, um Fehler aufzudecken. Schließlich wird noch ein Gesamtsystemtest durchgeführt. Die Tests werden protokolliert. Aufnahme des Betriebs Das fertige Produkt wird übergeben und in die Kundenumgebung integriert. Häufig findet eine Schulung der Benutzer statt. Meistens durchläuft das System vor dem allgemeinen Produktivstart noch eine sogenannte "Beta-Testphase", in der das System an ausgewählte Benutzer zur Nutzung übergeben wird, um verbliebene Fehler zu finden.

3.2.2

Systems Development Lifecycle (SDLC)

Eine Variante des Wasserfallmodells ist das zyklische SDLC-Modell. Die erste Fassung wurde 1969 vom National Computing Centre in Großbritannien entwickelt und veröffentlicht. Es berücksichtigt den vollständigen Lebenszyklus eines spezifischen Informationssystems und hat ebenfalls einen Fokus auf die Softwareentwicklung. Unter Lebenszyklus wird in der Informatik – ähnlich wie in der Biologie - nicht die periodische Erneuerung, sondern der Lebenslauf eines Systems verstanden, der sich in ähnlichen Systemen ähnlich wiederholt. Der Zyklus besteht heutzutage meist aus den in Abbildung 14 dargestellten Phasen:        

Initiation: eine Startphase, die üblicherweise durch ein geschäftliches Problem oder eine geschäftliche Chance ausgelöst wird Feasibility Study: ein Versuch festzustellen, ob die geplante Systementwicklung realisierbar sein wird Requirement Analysis: Phase zur Feststellung der Anforderungen an das System Systems Design: Spezifikation, wie das System die festgestellten Anforderungen erfüllen kann Build: In dieser Phase wird das Design durch Programmierung, Tests und Implementierung von Datenbanken in ein physikalisches System überführt. Implement: Mittels Installation und Tests wird das Informationssystem in die geschäftliche Produktivumgebung überführt. Maintain: In dieser Phase wird das System gewartet. Das beinhaltet die Durchführung von Änderungen, Korrekturen, Ergänzungen und Upgrades um sicherzustellen, dass das System (weiterhin) die Geschäftsziele und Anforderungen unterstützt. Kill: In dieser Phase werden Aktivitäten durchgeführt, um das Ende des Systems herbeizuführen.

22

3 Vorgehensmodelle und Rahmenwerke

Initiation

Aussonderung

Machbarkeitsstudie

Projekt- und Changemanagement

Wartung

Anforderungsanalyse

Systemdesign

Deployment

Systementwicklung

Abbildung 14: SDLC-Modell, in Anlehnung an: [BGH2008, S. 277]

3.2.3

Structured Systems Analysis and Design Methodology (SSADM)

Ein weiterer Ansatz aus Großbritannien, der eine Weiterentwicklung der klassischen Softwareentwicklungsmodelle darstellt, ist die Structured Systems Analysis and Design Methodology (SSADM)14. Die Methodologie wird vom Office of Government Commerce (OGC) verantwortet und verwaltet. Wie der Name schon sagt, konzentriert sich die Methodik auf Analyse und Design und führt diese detailliert aus. Die Phasen Implementierung und Betrieb werden nicht berücksichtigt.

14

[BGH2008, S.293ff]

3.2 Modelle zur Softwareentwicklung

FEASIBILITY STUDY

REQUIREMENTS ANALYSIS

REQUIREMENTS SPECIFICATION

LOGICAL SYSTEMS SPECIFICATION

PHYSICAL DESIGN

23

STAGE 0 Feasibility Study

STAGE 1 Investigation of Current Environment STAGE 2 Business System Options STAGE 3 Definition of Requirements

STAGE 4 Technical System Options STAGE 5 Logical Design

STAGE 6 Physical Design

Abbildung 15: SSADM-Stufen, in Anlehnung an [WLW2002, S.8]

SSADM hat folgende Stufen: 

Stufe 0: Feasibility – Technik: Ist das Projekt technisch machbar? – Finanzen: Kann die Organisation es sich leisten das Projekt durchzuführen? – Organisation: Ist das neue System kompatibel mit den vorhandenen Regeln und Richtlinien? – Ethik: Sind die Auswirkungen des neuen Systems sozial akzeptabel?



Stufe 1: Investigation of current environment – Untersuchung und Definition der Anforderungen – Analyse der derzeitigen Prozesse – Analyse der derzeitigen Datenmodells



Stufe 2: Business systems options – Identifizierung der möglichen Systemoptionen aus fachlicher Sicht – Auswahl einer fachlichen Systemoption



Stufe 3: Definition of requirements – Identifizierung der angeforderten Prozesseigenschaften – Entwicklung des erforderlichen Datenmodells – Ableitung der Systemfunktionen – Entwicklung von Spezifikationsprototypen für Systemteile – Entwickeln der Prozessspezifikation – Review bezüglich der Systemanforderungen – Dokumentation der Anforderungsspezifikation



Stufe 4: Technical system options – Identifizierung der möglichen Systemoptionen aus technischer Sicht – Auswahl einer technischen Systemoption

24

3 Vorgehensmodelle und Rahmenwerke



Stufe 5: Logical design – Festlegung der Benutzerdialoge – Definition der Updateprozesse – Festlegung der Abfrageprozesse – Zusammenstellung des logischen Designs



Stufe 6: Physical design – Vorbereitung des physischen Designs – Erstellung eines Konzepts für die Datenhaltung – Erstellung einer Darstellung zur Abbildung der Funktionskomponenten auf die physischen Komponenten – Optimierung des physischen Datendesigns durch Testen – Konzept für das Komponentendesign – Erstellung einer Darstellung zur Abbildung zwischen der physischen Datenbank und dem Prozesskonzept – Zusammenstellung des physischen Designs

3.2.4

V-Modell

Das V-Modell, das in den 80er Jahren vom deutschen Verteidigungsministerium in Zusammenarbeit mit einem Beratungsunternehmen erstellt wurde, ist eine Weiterentwicklung des Wasserfallmodells. Betrieb

Anforderungsdefinition

Grobentwurf

Feinentwurf

Programmierung

Abnahmetest

Systemtest

Integrationstest

Modultest

Abbildung 16: Das V-Modell (Systemerstellung), in Anlehnung an [BAL1998, S. 101]

Aufgrund der Modellstruktur gestaltet sich der Ablauf V-förmig. Der Modultest prüft die Programmierung, der Integrationstest den Feinentwurf, der Systemtest den Grobentwurf und der Abnahmetest die Anforderungsdefinition. Diese aufgrund ihrer Einfachheit attraktive Zuordnung lässt sich in der Praxis allerdings nicht immer gewährleisten: Es können bei-

3.2 Modelle zur Softwareentwicklung

25

spielsweise beim Systemtest noch Fehler auftreten, die auf Programmierfehler zurückzuführen sind.

Test/Verification Systems Verification Test

Systems & Stakeholder Requirements Definition

Output: System Verification Test Procedures (SVTP) and Results (SVTR)

Output: System Requirements Doc. (SRD)

Systems Design & Analysis Software Requirements Def Safety Classification

H/W – S/W Integration Test Output: S/W Verification Cases and Procedures (SVCP) and Results (SVR)

Output: Software Requirements Spec. (SRS)

Software Design Definition Output: Software Design Description (SDD)

Coding Phase

Software Design Phase

Software Requirements Phase

System Requirements Phase

Definition/Development

Unit/Integration Testing Output: S/W Verification Cases and Procedures (SVCP) and Results (SVR)

Coding

Code Review

Output: Source and Object Code

Output: Source Code Review and Analysis Data

Abbildung 17: Vorgehensmodell gemäß IEC 62304 (Quelle: IBM)

Das Modell hat in ähnlicher Form Eingang gefunden in die internationale Norm IEC 62304 Medical device software - Software life cycle processes.

3.2.5

Spiralmodell

Das Spiralmodell ist 1986 von B. W. Boehm veröffentlicht worden. Es ist risikogetrieben und evolutionär und sollte insbesondere den typischen Softwareentwicklungsrisiken Anforderungsnonkonformität, Fehlerhaftigkeit und Budgetüberschreitung gerecht werden. Es reflektiert die Tatsache, dass Softwareentwicklung dazu tendiert, die Phasen Analyse, Design und Codierung mehrfach zu durchzulaufen.

26

3 Vorgehensmodelle und Rahmenwerke

Festlegung der Ziele, Randbedingungen und Alternativen

Bewertung der Alternativen

1

2

Risikoanalyse

Start

4

3

Planung des nächsten Zyklus

Fertigstellung und Abnahme Ende

Abbildung 18: Spiralmodell, in Anlehnung an [BPK2008, S. 31]

Das Spiralmodell versteht den Softwareentwicklungsprozess als iterativen Prozess mit vier folgenden wiederkehrenden Aktivitäten: 1. Festlegung der Ziele, Randbedingungen und Alternativen 2. Bewertung der Alternativen (Risikoanalyse) 3. Fertigstellung und Abnahme 4. Planung des nächsten Zyklus In Abbildung 18 sind diese Aktivitäten als Quadranten dargestellt. In jedem Entwicklungszyklus werden alle vier Quadranten durchlaufen. Mittels der Erstellung von Prototypen ab dem zweiten Zyklus verfolgt das Modell einen Ansatz zur Risikominimierung und ermöglicht eine frühe Erkennung von Fehlern.

3.3

Systemanalysemodell

Beim Prozess der System- beziehungsweise Softwareentwicklung ist die Systemanalyse der Systementwicklung vorgeschaltet.15. Sie besteht aus den hintereinandergeschalteten Teilprozessen  

15

Ist-Analyse und Soll-Konzept.

[HEI2007, S.3]

3.3 Systemanalysemodell

27

Erfassung des Istzustandes

Darstellung des Istzustandes

Analyse des Istzustandes Dokumentation des Istzustandes

Ist-Analyse

Entwickeln des Konzepts

Dokumentation des Konzepts

Soll-Konzept

Abbildung 19: Ablauf der Systemanalyse

3.3.1

Die Ist-Analyse

Bei der Ist-Analyse sind drei Prozessschritte zu absolvieren16: 1. Erfassung des Ist-Zustands 2. Darstellung des Ist-Zustands 3. Analyse des Ist-Zustands Der erste Schritt beginnt mit der Identifikation des Systems, insbesondere der Festlegung der Systemgrenze zur Unterscheidung von System und Umwelt. Dann kann sich die Informationsgewinnung anschließen. Heinrich [HEI2007] betont die Bedeutung der folgenden Informationsdimensionen:    

allgemeine Unternehmensdaten Mengengerüste Aufbauorganisation IT-Ablauforganisation

Die Anforderungen des Auftraggebers sind üblicherweise in einem Lastenheft zusammengestellt. Auch der Mensch (der Mitarbeiter) ist als wichtiger Bestandteil des Systems zu berücksichtigen. Klassische Darstellungsformen für den Ist-Zustand eines Systems sind:  

16

Datenflussdiagramme Prozessbeschreibungen

[HEI2007, S.26ff.]

28

3 Vorgehensmodelle und Rahmenwerke

Für die Analyse des Ist-Zustands stehen normalerweise Mitarbeiter und Dokumente als Informationsquiellen zur Verfügung. Als Techniken zur Informationsgewinnung sind besonders geeignet:  Fragebogenmethode  Interviewmethode  Inventurmethode Bei der Fragebogenmethode erstellt der Systemanalyst Formulare mit vorgegebenen Fragen. Die Übermittlung der Fragebögen sollte so durchgeführt werden, dass die betroffenen Personen die Bögen gleichzeitig erhalten. Bei der Interviewmethode stellt der Analyst seinem Interviewpartner in einem Gespräch Fragen. Standardisierte Interviews mit vorformulierten Fragen haben den Vorteil, dass sie gut vergleichbar und auswertbar sind. Die Inventurmethode ist keine personenbezogene, sondern eine dokumentenbezogene Technik. Es werden vorhandene Dokumente (zum Beispiel Richtlinien und Systemdokumentationen) ausgewertet. [KST2007] betonen bei der Analyse des Ist-Zustands neben der Aufgabe die Schwachstellen aufzudecken auch den Potenzialaspekt. Mit den vom System betroffenen Personen sollten Verbesserungsmöglichkeiten erwogen werden. In diesem Sinne sind Schwachstellen Optimierungsmöglichkeiten.

Erwünschter Zustand Optimierungspotenzial Istzustand mit Schwachstellen Abbildung 20: Schwachstellenanalyse

Schwachstellen kann man häufig wie folgt typisieren:  Organisatorische Schwachstellen  Informationelle Schwachstellen  Technische Schwachstellen  Sonstige Schwachstellen Es ist wichtig die Auswirkungen der Schwachstellen zu identifizieren und zu beschreiben. Dieser Vorgang wird erleichtert, wenn die Schwachstelle quantitativ beschrieben werden kann.17 Das ist zwar anzustreben, aber nicht immer möglich. Der Output des Teilprozesses Ist-Analyse ist hauptsächlich die Dokumentation des IstZustands. Das betrifft sowohl den Ist-Zustand des Systems als auch die vorhandenen Anforderungen.

17

Beispiel: Der Medienbruch bei der Auftragsbearbeitung führt zu einer Verlängerung der Prozessdurchlaufzeit in Höhe von 15 Minuten.

3.4 CObIT als IT-Governance-Rahmenwerk

3.3.2

29

Das Soll-Konzept

In diesem Fall ist der Name des Teilprozesses mit seinem Output identisch. Das fertig gestellte Soll-Konzept wird häufig auch Pflichtenheft oder Gesamtspezifikation oder Designspezifikation genannt. In dieser Phase wird beschrieben, wie ein externer oder interner Auftragnehmer die Anforderungen eines externen oder internen Auftraggebers zu erfüllen beabsichtigt. Der Input ist der Output der Ist-Analyse. Ausführliche Darstellungen zur Systemanalyse findet man unter anderem in [WAL2007].

3.4

CObIT als IT-Governance-Rahmenwerk

Die sogenannte IT-Governance hat in den letzten Jahren stark an Bedeutung zugenommen. Für die IT-Governance ist das Management der Organisation zuständig. Sie besteht aus geführten Organisationsstrukturen und Prozessen, die sicherstellen, dass die IT der Organisation die Strategien und Ziele der Organisation angemessen unterstützt. Das wohl bekannteste und international am meisten verbreitete Rahmenwerk für ITSteuerung ist CObIT. CObIT steht für „Control Objectives for Information and related Technology“. Im Jahr 2007 hat das IT Governance Institute (ITGI) CObIT Version 4.118 herausgegeben. ITGI ist ein Institut der ISACA, ein Berufsverband für IT-Revisoren und ITAuditoren. In CObIT 4.1 sind insgesamt 34 Prozesse zur Steuerung und Kontrolle der IT definiert, die jeweils einer der vier CObIT-Domänen zugeordnet sind. Es ist deutlich zu betonen, dass CObIT die IT-Steuerungsprozesse mit ihren Aktivitäten nicht im Detail festlegt, sondern in erster Linie die Ziele, die Inputs und Outputs, die Verantwortlichkeiten sowie die Kennzahlen des jeweiligen Prozesses kompakt darstellt. Von Interesse ist für uns beispielsweise der Prozess AI3 Acquire and Maintain Technology Infrastructure aus der Domäne Acquire and Implement. Dieser Prozess ist allerdings hauptsächlich auf die Beschaffung und Wartung der IT-Infrastruktur fokussiert und überschneidet sich mit unserem Thema nur partiell. Als relevante Aktivität ist AI3.1 Technological Infrastructure Acquisition Plan hervorzuheben, in der es vor allem um die Beschaffung und Implementierung der IT-Infrastruktur geht. Weitere Prozesse mit Bezug auf die Planung und Realisierung von IT-Infrastrukturen werden in Kapitel 9 behandelt. Die Hauptverantwortung für den Prozess AI3 hat der CIO. Der Prozess soll dazu beitragen, dass den Geschäftsanwendungen Plattformen zur Verfügung gestellt werden, die in Übereinstimmung mit der festgelegten IT-Architektur und den Technologiestandards sind. Die dabei erstellte IT-Infrastruktur soll sicher und zuverlässig sein. Um diese Ziele zu erreichen, soll unter anderem eine Umgebung zum Testen der Infrastruktur zur Verfügung gestellt werden. CObIT thematisiert zwar, welche Ziele für den jeweiligen Prozess zu erreichen sind und was die Outputs des Prozesses sind, stellt aber nicht im Detail dar, wie die Ziele zu erreichen und die Outputs zu liefern sind. Hinsichtlich der Planung und Realisierung von IT-Infrastrukturen liefert CObIT also einen groben Rahmen, den es zu füllen und zu vervollständigen gilt.

18

[ITGI2007]

30

3 Vorgehensmodelle und Rahmenwerke

Tabelle 2: Inputs und Outputs des CObIT-Prozesses AI3

19

Von Prozess PO3

Inputs Infrastrukturplan der Technologie; Standards und Möglichkeiten; Regelmäßige ‘state of technology’ Aktualisierungen

PO8 PO10

Beschaffungs- und Entwicklungsstandards Projektmanagementanleitungen; Detaillierte Projektpläne Machbarkeitsstudie bezüglich Unternehmenserfordernisse

AI1

Outputs Beschaffungsentscheidungen; Konfiguriertes System, fertig für Test / Installation; Anforderungen an die physische Infrastruktur; Überarbeitung technologischer Standards; Anforderungen an Systemmonitoring; Wissen über Infrastruktur; Vorabversionen von OLA

AI6 DS3

Beschreibung Change-Prozess Performance- und Kapazitätsplan (Anforderungen)

3.5

Rahmenwerke zum Servicemanagement

Serviceorientiertes Denken gewinnt auch bei Planung und Betrieb von Informationssystemen wachsende Bedeutung. Informationssysteme sind dazu da, IT-Services zu ermöglichen, die Geschäftsprozesse unterstützen. Auf die Qualität dieser Services wird mehr und mehr geachtet. Als diesbezügliches Good-Practice-Framework ist die IT Infrastructure Library (ITIL) der britischen Regierungsbehörde OGC besonders bekannt und verbreitet. Mit BS 15000 (internationalisiert als ISO/IEC 20000) existiert ein Standard, in dem vor allem die einzelnen ITSM-Prozesse (aus ITIL) aufgegriffen werden.

3.5.1

ICTIM und ITSM

Das IT-Management hat sich traditionell in erster Linie mit der Planung und Implementierung von Softwaresystemen und dem Betrieb von IT-Infrastrukturen befasst. Letzteres bekam allerdings nur mäßige Aufmerksamkeit. IT-Servicemanagement (ITSM) bezeichnet die Maßnahmen und Methoden, die für die bestmögliche Unterstützung von Geschäftsprozessen durch die IT-Organisation erforderlich sind. ITSM repräsentiert also den Wandel des IT-Managements von der Technikzur Kunden- und Serviceorientierung. Ein wichtiger Bereich des ITSM ist das ITInfrastrukturmanagement (ICTIM). Hier geht es sowohl um den Betrieb als auch um die Planung und Realisierung von IT-Infrastrukturen.

3.5.2

ITIL v2 Infrastrukturmanagement

ITIL v1 hatte einen Umfang von mehr als 30 Büchern. Um ITIL übersichtlicher und einfacher zugänglich zu machen, konsolidierte man in Version 2 die Publikation durch Gruppierung in 5 Hauptbüchern:

19

Quelle: [ITGI2007], S. 83

3.5 Rahmenwerke zum Servicemanagement 1. 2. 3. 4. 5.

31

The Business Perspective Service Delivery Application Management Service Support ICT Infrastructure Management

Die Bücher  Planning to Implement Service Management  Security Management  Software Asset Management sind als Ergänzungen anzusehen. Die Serviceausrichtung ist nicht so stark ausgeprägt wie bei den anderen Büchern. LEISTUNGSERBRINGER Strategisch Business Perspective

LEISTUNGSABNEHMER Markt

Taktisch Service Delivery

Kunden

Application Management Operativ Service Support

Nutzer

ICT Infrastructure Management Abbildung 21.: Die Kernelemente von ITIL v2

Die ITIL-Bücher sind jeweils der strategischen, der taktischen oder der operativen Handlungsebene zugeordnet. Die Unterscheidung in diese drei Kategorien hat sich in den letzten Jahrzehnten in der Betriebswirtschaft, speziell in der Managementlehre, durchgesetzt. Ursprünglich stammen diese Kategorien aus dem Militärwesen. Aufgaben und Aktionen werden strategisch genannt, wenn sie langfristig angelegt sind und grundsätzlichen Charakter haben. Sie betreffen meist die ganze Organisation. Taktische Aufgaben und Aktionen sind mittelfristig relevant. Die Detailtiefe ist größer. Sie betreffen üblicherweise einen größeren Teil der Organisation. Operative Aufgaben und Aktion sind kurzfristig angelegt und konkret formuliert. In der Regel ist nur eine Organisationseinheit davon betroffen. Die Zuordnung der ITIL-Prozesse zu den Handlungsebenen ist statisch und nicht durchgängig zutreffend. Beispielsweise enthält die Planungs- und Entwurfsphase des „ICT Infrastructure Management“ auch Elemente, die der taktischen Ebene zugeordnet werden können. Das uns hier interessierende Buch [OGC2002] ICT Infrastructure Management (ICTIM) ist der operativen Ebene zugeordnet. Im Rahmen von ICTIM werden Empfehlungen für die Anforderungsanalyse, die Planung, den Entwurf, die Auslieferung und den Betrieb einer ITInfrastruktur gegeben.

32

3 Vorgehensmodelle und Rahmenwerke

Beim ICT-Infrastrukturmanagement gemäß ITIL handelt es sich um einen Prozess, der aus folgenden Subprozessen besteht:    

EP: Design and Planning (Entwurf und Planung): Entwicklung und Wartung von Strategien, Prozessen und Richtlinien für die Implementierung und den Rollout einer adäquaten IT-Infrastruktur UA: Deployment (Umsetzung und Auslieferung): Implementierung und Rollout von Geschäfts- und ICT-Lösungen BE: Operations (Betrieb): Alle notwendigen Maßnahmen und Aktivitäten, um die geplante Benutzung der ICT-Infrastruktur beständig gewährleisten zu können, inklusive Überwachung, Kontrolle, Scheduling und Sicherheit TU: Technical Support (Technische Unterstützung): Technische Beurteilung und Unterstützung der ICTIM-Lösungen

Teilprozess EP (Entwurf und Planung) Dieser Prozess beschäftigt sich mit den Richtlinien für die Entwicklung und Installation von ICT-Infrastrukturen in einer Organisation, die den geschäftlichen Bedürfnissen gerecht wird. Business IS Strategy

Business requirement

Service Delivery

Business strategies and plans

CSIP Financial Plan IT Service Continuity Plan Capacity Plan Availability Plan

Design and Planning Service requirements, SLAs, SLRs and Infrastructure requirements

ICT Strategies, Architectures, plans, Processes and Policies

Security Management Security policy security plan

ITSG ICT programmes and plans

Business cases/ Feasibility studies Full SORs and ITTs

Service Support Service Support plans ans Policies

Deployment SWOT Reports

Revised site plans and designs

Application Management Application plans, Architectures and Strategies

ICT Management and Administration Contract; terms and conditions

Project plans deployment plans

Technical support Evaluation and test reports

Installation planning and control

Operations Evaluation and test reports

Site plans and Layouts

Abbildung 22: Inputs und Produkte des Prozesses Entwicklung und Planung (Design and Planning), Quelle: [OGC2002, S. 24]

3.5 Rahmenwerke zum Servicemanagement

33

Die Ziele des Prozesses sind:    

Koordination aller für Entwurf und Planung relevanten Aspekte Entwicklung und Aufrechterhaltung von Strategien für die Inbetriebnahme von ICTLösungen Erstellung einer ICT-Planungsschnittstelle für alle Planer in verbundenen Bereichen Unterstützung bei der Entwicklung von Richtlinien

Insbesondere geht es darum, Strategien und Pläne zu entwickeln, die 

Technologien,



Architekturen,



Prozeduren und

 Managementmethoden berücksichtigen. Der Prozess verläuft in der Regel in nacheinander ablaufenden Schritten. SWOT-Analyse Ein Review der derzeitigen IKT-Organisation ist ein wichtiges Instrument, um bei ITIProjekten zielgerichtet vorzugehen: Analysiert werden:    

die Stärken der Organisation (Strengths), z.B. Image, Partnerschaften, Qualität die Schwächen der Organisation (Weaknesses), z.B. Mangel an Know-How, mangelnde Prozessreife Chancen (Opportunities), z.B. neue Interessenten, neue Technologien externe Bedrohungen (Threats), z.B. neue Gesetzgebung, wirtschaftliche Veränderungen

Der Sinn der Analyse ist die Festlegung bzw. Revision von IT-bezogenen Zielen und Strategien samt Prioritäten. Die SWOT-Analyse wird üblicherweise nicht projektbezogen, sondern projektübergreifend durchgeführt. Weitere Ausführungen zur SWOT-Analyse findet man in Kapitel 5. Anforderungsprofil Das sogenannte Statement of Requirements enthält alle Anforderungen an einen neuen oder geänderten IT-Service. Machbarkeitsanalyse (Feasibility Study) Bei der Machbarkeitsanalyse geht es darum festzustellen, ob die geplante IT-Infrastruktur die Anforderungen erfüllen kann. Service Level Agreement Der Abschluss von Dienstgütevereinbarungen mit dem Kunden ist ein wesentliches Element der Durchführung eines IT-Projekts. Die Vereinbarung enthält zugesicherte Leistungseigenschaften wie etwa Leistungsumfang, Verfügbarkeit und Support. Der Servicelevel beschreibt die jeweilige Leistungsqualität.

34

3 Vorgehensmodelle und Rahmenwerke

Infrastrukturkonzept Das Infrastrukturkonzept enthält Architekturen, Pläne, Vorgaben und Richtlinien und orientiert sich an folgenden Eigenschaften:        

Brauchbarkeit, leichte Anwendbarkeit Skalierbarkeit Flexibilität Sicherheit Verfügbarkeit Unanfälligkeit für Störungen schnelle Wiederherstellbarkeit leichte Wartung und Fehlererkennung Business unit a Business Process

1

Business unit b

2

3

Business Process

4

Business unit c

5

6

Business Process

8

7

9

The Business SLAs Services

Service A

B

C

D

E

F

G

Components

Hardware

Software

Network

Environm.

Database

Contracts

OLAs

Suppliers

Teams Support team

(i)

(ii)

(iii) Supplier

(i)

(ii)

(iii)

Abbildung 23: ICT-Infrastrukturmodell; Quelle: [OGC2002, S.42]

Das Infrastrukturkonzept muss dafür sorgen, dass die ICT-Komponenten die Geschäftsziele des Unternehmens effektiv und effizient unterstützen. Das Konzept darf nicht im Widerspruch zu den Dienstgütevereinbarungen stehen. Hinsichtlich der Umsetzung des Konzepts ist darauf zu achten, dass mit Lieferanten angemessene Verträge geschlossen werden und auch mit den beteiligten, internen Organisationseinheiten Vereinbarungen (OLA) getroffen werden. Operational Level Agreements (OLAs) sind unternehmensinterne Vereinbarungen, die üblicherweise der Absicherung eines übergeordneten Service Level Agreements (SLA) des

3.5 Rahmenwerke zum Servicemanagement

35

Unternehmens gegenüber einem Endkunden dient. Sie definieren die Niveaus und Standards, an denen sich der die ICTIM-Prozesse auszurichten haben. Das ITIL Availability Management (Teilprozess von Service Delivery) stellt für EP einen Verfügbarkeitsplan zur Verfügung. Die Infrastruktur sollte so geplant werden, dass die mit dem Kunden im SLA vereinbarten Verfügbarkeitswerte eingehalten werden können.20 Teilprozess UA (Umsetzung und Auslieferung) Dieser Prozess befasst sich mit der Realisierung und Auslieferung von ICT-Infrastrukturen unter Verwendung des Outputs des EP-Prozesses als Input. Der Prozess liefert eine technische Lösung, die üblicherweise aus mehreren technischen Komponenten besteht Der UA-Prozess liefert Anleitungen und Strukturen, die einerseits die bestehende Infrastruktur und andererseits Normen und interne Standards berücksichtigen, so dass die Lösung investitionssicher ist. Die Lösung muss im Einklang mit den Ergebnissen der Entwicklungs- und Planungsaktivitäten sein. Im Rahmen des UA-Prozesses wird auch darauf geachtet, dass die mit neuen oder geänderten technischen Lösungen einhergehenden Änderungen in der Organisation von den betroffenen Mitarbeitern verstanden und akzeptiert werden können. Um den Betrieb in der Produktionsumgebung nicht unnötig zu beeinträchtigen, werden weitere, von der Produktionsumgebung separierte Umgebungen (Environments) eingerichtet, die nacheinander betreten werden. Verantwortlich: Projektteam Entwickeln

Testen

Deployment-Koordinator Freigeben

Ausliefern

Abbildung 24: Beziehungen zwischen den Arbeitsumgebungen. Quelle: [OGC2002, S.89]

Teilprozess BE (Betrieb) Der Prozess gewährleistet ein effektives operatives Management der ICT-Infrastruktur. Insbesondere die Wartung der Infrastruktur ist ein wichtiger Aspekt. Die Hauptziele beim Management des Betriebs von ICT sind:  

20

Betrieb, Verwaltung und Wartung einer ICT-Infrastruktur, die das Service Delivery unterstützt und alle vereinbarten Anforderungen und Ziele erfüllt Sicherstellung, dass die ICT-Infrastruktur zuverlässig, stabil, sicher und konsistent ist, um IT-Services mit angemessener Qualität anbieten zu können

[ZHB2005, S.92]

36

3 Vorgehensmodelle und Rahmenwerke

 Effektive und effiziente Unterstützung der Geschäftsprozesse des Unternehmens Der BE-Prozess ist in erster Linie technologieorientiert, enthält aber auch Managementelemente, bei denen es um die Überwachung und Steuerung der ICT-Infrastruktur geht. Die Serviceorientierung ist vorhanden. In Umgebungen mit Hochverfügbarkeitsanforderungen hat der Prozess ein besonderes Gewicht, da ein ordnungsgemäßer Betrieb der ICT-Infrastruktur unerlässlich für eine hohe Verfügbarkeit der betriebenen Services ist. Teilprozess TU (Technische Unterstützung) Die Ziele des Prozesses sind:    

Herausbildung eines Zentrums technischer Exzellenz in den Bereichen Auslieferung und Betrieb Unterstützung bei der Bereitstellung von Diensten Ressourcenkoordination kontinuierliche Berichterstattung zur Qualität der ICT-Dienste

Der Teilprozess TU besteht aus mehreren Subprozessen: 1. Forschung und Bewertung – Erforschung und Entwicklung neuer Technologien – Machbarkeitsprüfung von Infrastrukturkonzepten vor der Umsetzung – Überprüfung der von EP erwarteten Resultate – Erstellung von Berichten zur Infrastrukturperformance 2. Projekte – Zusammenarbeit mit EP bei der Erstellung von Statement Of Requirements (SOR) und Invitation To Tender (ITT)21 – Planung und Steuerung des Budgets – Beschaffung von Komponenten – Erstellung und Wartung von Testumgebungen – Zusammenarbeit mit UA hinsichtlich der Auslieferungsverfahren – Detaillierte technische Untersuchung zur Lauffähigkeit der in Arbeit befindlichen ICT-Lösung – Koordination der Lieferanten – Technische Unterstützung des Releasemanagements 3. Routinegeschäft – Erstellung und Wartung der technischen Wissensdatenbank – Einbeziehung technischer Spezialisten bei Untersuchungen von Störungen der vorhandenen ICT-Infrastruktur – Verifikation der Konfigurationselemente (CI) in der CMDB – Technische Planung und Verwaltung für die Bereiche Support, Administration und Betrieb – Verwaltung von Dokumentationen und Aufzeichnungen – Schulung der Mitarbeiter des Service Support

21

Ausschreibungsunterlage

3.5 Rahmenwerke zum Servicemanagement

37

Schnittstellen zu den anderen Bereichen des Managements gemäß ITIL22 The Business Kunden

Nutzer Dienste

Application Management

Service Management Service Delivery Service Support Service Level Management Capacity Management Financial Management Availability Management Service Continuity Management

Service Desk Incident Management Problem Management Configuration Management Change Management Release Management

ICT Infrastructure Management EP

UA

BE

TU

Partner

Technologie

Abbildung 25: Schnittstellen von ICTIM, in Anlehnung an [OGC2002, S.9]

ICTIM liefert dem Service Level Management das technische Know-How zur Festlegung und Überwachung der Service Level Agreements (SLA) mit dem Kunden. Die dort definierten Qualitätskriterien müssen vom ICTIM bei der Planung der ICT-Infrastruktur berücksichtigt werden. Für den EP-Teilprozess sind die vom Capacity Management gelieferten Informationen über IT-Komponenten ein relevanter Input. Das Financial Management liefert ICTIM Informationen über Kosten und Budgets. Diese beeinflussen die Gestaltung der ICT-Infrastruktur. Das Availability Management stellt dem EP-Teilprozess als Input verfügbarkeitsbezogene Informationen zur Verfügung. Die ICT-Infrastruktur ist so zu planen, dass die mit dem Kunden vereinbarten Verfügbarkeitswerte erreicht werden können. Während des Betriebs sollten diesbezügliche Berichte an das Availability Management geliefert werden. Das Service Continuity Management legt Maßnahmen und Prozesse für Katastrophenfälle fest. Die zugehörigen Pläne sind Input für ICTIM.

22

[ZHB2005, S.251ff.]

38

3 Vorgehensmodelle und Rahmenwerke

Die vom Incident Management gespeicherten Informationen zu Störungen der ICTInfrastruktur werden an ICTIM zur Bearbeitung weitergeleitet. Auch die Bedürfnisse und Anforderungen des Problem Management, insbesondere bezüglich der Analysen von Problemursachen, beeinflussen die Planung der ICT-Infrastruktur. Vom Teilprozess TU erhält das Change Management einen Änderungsantrag23. Das Change Management stellt Verfahren zur Planung und Durchführung von Änderungen zur Verfügung. ICTIM wird bei der Einführung einer neuen oder geänderten ICT-Infrastruktur vom Release Management unterstützt. Es sorgt dafür, dass mit der Einführung verbundenen Richtlinien und Verfahrensweisen eingehalten werden. Das Configuration Management verwaltet die IT-Komponenten in der CMDB. Die dort enthaltenen Informationen sind Input für den Teilprozess EP. Neue IT-Komponenten werden vom ICTIM dem Configuration Management gemeldet

3.5.3

ITIL v3 Infrastrukturmanagement

In der Version 3 wurde die IT Infrastructure Library deutlich umstrukturiert, um einen Lebenszyklus für Services abbilden zu können. Continual

Service Design

Service

Service Transition

ITILv3 Strategy

Service Operation Service Improvement Abbildung 26: Die Kernelemente von ITIL v3, Quelle: [OGC2007, S. 5]

Es gibt wiederum fünf Kernpublikationen:   

23

Service Strategy (Servicestrategie) Service Design (Serviceentwurf) Service Transition (Serviceüberführung)

Request for Change (RfC)

3.5 Rahmenwerke zum Servicemanagement  

39

Service Operation (Servicebetrieb) Continual Service Improvement (Kontinuierliche Serviceverbesserung)

Insgesamt gibt es jetzt deutlich mehr selbständige Prozesse als in Version 2. Im Buch „Service Transition“ sind beispielsweise folgende Prozesse dargestellt:       

Knowledge Management Change Management Service Asset and Configuration Management Transition Planning and Support Release and Deployment Management Service Validation and Testing Evaluation

Der Prozess „ICT Infrastructure Management“ wird nicht mehr wie in Version 2 behandelt. Er wurde hauptsächlich auf die Prozesse Service Transition / Release and Deployment Management, Service Operation / Technical Management, Service Operation / IT Operations Management und Service Operation / Event Management verteilt, ist also kein selbständiger Prozess mehr. Das ist insofern konsequent, als sich der bisherige Prozess über mehrere Phasen des Lebenszyklusses erstreckt hat und sich die neuen Bücher primär am Lebenszyklus eines IT-Service orientieren. Im Buch Service Design wird dem Thema ICTIM nur relativ wenig direkte Aufmerksamkeit gewidmet. Das Buch liefert aber wichtige Hinweise für die Planung von IT-Services und ermöglicht Rückschlüsse auf die Planung von ICTInfrastrukturen. Von den Designprinzipien24 sind insbesondere Folgende bemerkenswert:  Die IT-Services müssen die Geschäftsprozesse bestmöglich unterstützen.  Die Technnologiekomponenten müssen die IT-Services bestmöglich unterstützen. Dementsprechend ist es für die Planenden von ICT-Infrastrukturen wichtig, die Anforderungen, die an die IT-Services gestellt werden, gut zu kennen. Der weitsichtige Planer informiert sich auch über die dahinterliegenden Geschäftsanforderungen. Denn wenn er versteht, wozu die IT-Services eingeführt beziehungsweise geändert werden, ist es möglich, die Prioritäten bei der Infrastrukturplanung zu validieren oder zu korrigieren. Aus unserer Perspektive ist es mit ITIL Version 3 schwerer geworden, Hinweise für das Infrastrukturmanagement aus ITIL zu extrahieren, da der Schwerpunkt jetzt noch mehr auf den Services liegt. Der Ansatz des vorliegenden Buches ist es, den Infrastrukturprozess als selbständigen und wichtigen Prozess zu würdigen und zu strukturieren. Dabei wird auch in diesem Fall der Lebenszyklusansatz berücksichtigt. Es handelt sich um einen Prozess in Anlehnung an ITIL v2, der sich an den Grundideen Strategy – Design – Transition – Operation – Improvement von ITIL v3 orientiert.

24

[OGC2007a, Kapitel 3]

40

3 Vorgehensmodelle und Rahmenwerke

3.6

Herstellerspezifische Rahmenwerke

Nicht nur Institute und Behörden haben Rahmenwerke für das IT-Management entwickelt. Auch privatwirtschaftliche Organisationen haben sich engagiert. Insbesondere Microsoft und Cisco haben hier verfolgungswürdige Spuren hinterlassen, die sich für ITInfrastrukturprojekte nutzbar machen lassen.

3.6.1

Rahmenwerke von Microsoft

Microsoft Operations Framework (MOF) Ziel des Vorgehensmodells MOF ist, den erfolgreichen Betrieb einer IT-Infrastruktur (unter Verwendung von Microsoft-Produkten) sicherzustellen. MOF besteht aus drei grundlegenden Modellen für den IT-Betrieb:25 

Das Prozessmodell: Es stellt ein Modell der Prozesse dar, die von ServiceOrganisationen verwendet werden, um IT-Services zu erbringen, zu verwalten und zu warten.  Das Teammodell: Es handelt sich um eine Darstellung nötiger Rollen für den Betrieb, die das Management beim effektiven Organisieren des Personals unterstützen.  Das Risikomodell: Durch die Integration grundlegender Prinzipien, einer standardisierten Terminologie und eines strukturierten fünfstufigen Prozesses dient das Risikomodell dem alltäglichen Management bestehender Risiken. Der Fokus dieser Modelle ist auf den IT-Betrieb gerichtet. Da dieses Vorgehensmodell somit nur wenig relevant für unseren Betrachtungsgegenstand ist, werden keine weiteren Details dargestellt. Der interessierte Leser sei auf das Buch [PUQ2005] verwiesen. Microsoft Solutions Framework (MSF) Das Vorgehensmodell MSF zur Unterstützung der Planung, des Entwurfs, des Entwickelns und des Bereitstellens von IT-Lösungen ist ein Modell, das nicht nur Softwareentwicklungsprojekte, sondern auch Infrastrukturprojekte unterstützt. Allerdings werden diesbezügliche Aspekte nicht im Einzelnen dargestellt. Auch das MSF-Modell hat die Bestandteile Prozessmodell26, Teammodell und Risikomodell. Wenn man beide Rahmenwerke anwendet, sollten MSF und MOF nacheinander eingesetzt werden, da sich MSF vornehmlich mit der Projektphase und MOF hauptsächlich mit der Betriebsphase befasst.

Projekt

Betrieb

• MSF

• MOF

Abbildung 27: Anwendungsreihenfolge der Rahmenwerke

25 26

[PUQ2005, S. 13] seit MSF v4 auch Governancemodell genannt

3.6 Herstellerspezifische Rahmenwerke

41

Microsoft stellt angesichts der Vielartigkeit von IT-Projekten folgende Fragen zu den bekannten und teilweise oben dargestellten Vorgehensmodellen für Softwareentwicklung27:  

Passen die im Modell genannten Vorgehensweisen zur Unternehmenskultur? Kann ein Vorgehensmodell top-down und in Reinkultur eingeführt werden oder muss es aus dem Unternehmen heraus wachsen?  Induzieren diese Vorgehensmodelle mit und nach ihrer Einführung einen übermäßigen Verwaltungsaufwand? Ist dieser kalkulierbar? Sind Kunden bereit, dafür zu bezahlen? Microsoft hat insofern aus diesen Fragen Konsequenzen gezogen, dass MSF nicht im Detail das Vorgehen vorschreibt und somit relativ flexibel und sowohl für kleine als auch für große IT-Projekte einsetzbar ist. Es ist also im eigentlichen Sinne des Wortes ein Rahmenwerk für IT-Projekte. Auf MSF bzw. einzelne Phasen können spezialisierte Methoden aufgesetzt werden.

28

Abbildung 28: Überblick zum MSF v4 Governancemodell

Im abgebildeten Modell ist erkennbar, dass sich die fünf Phasen überlappen. Deshalb heißen die Phasen ab Version 4 Spuren. Der Name repräsentiert jeweils die zentrale Tätigkeit in dieser Phase (Spur). Um zu betonen, dass MSF schon immer einen Blickwinkel hatte, der über die Softwareentwicklung hinausgeht, wurde die Phase Development mit Version 4 in Build umbenannt.

27 28

Das Microsoft Solutions Framework (Teil 1), http://msdn.microsoft.com/de-de/library/bb979125.aspx Quelle: [TUR2006, S.150]

42

3 Vorgehensmodelle und Rahmenwerke

Tabelle 3: Die fünf Phasen (Spuren) des Prozessmodells; Quelle: [POM2006, S. 39] Phase (Spur) 1. Envision 2. Plan

Auftrag Projektziele und –erwartungen definieren Definition des Aufbauumfangs, des Zeitplans und der Vorgehensweise

3. Development (Build) 4. Stabilize 5. Deploy

Aufbau, Test und Verfeinerung aller Bestandteile der Lösung Test der Lösung und Vorbereitung des endgültigen Release für die Produktion Bereitstellung der Lösung im tatsächlichen Produktionsumfeld

Spur 1: Envision Das Projektteam wird zusammengestellt. Die Teammitglieder erhalten Rollen, Kompetenzen und Verantwortlichkeiten. Das Projektteam identifiziert und dokumentiert das Gesamtziel und den Umfang des Projekts sowie dessen Risiken. Dann wird das Ziel kommuniziert. Spur 2: Plan Die bestehende Umgebung wird analysiert, damit ein Lösungsentwurf erstellt werden kann. Ein Basisprojektplan wird erstellt, der alle Projektphasen umfasst. Der Plan berücksichtigt nicht nur zeitliche Abläufe, sondern auch eine Budget- und Qualitätskontrolle. An diesen Plan müssen sich die Teammitglieder halten. Spur 3: Develop (Build) Die Systemkomponenten - MSF spricht meist von Anwendungskomponenten - werden dem Lösungsentwurf entsprechend kreiert beziehungsweise transformiert. Output ist der vorläufig fertige Softwarecode oder die Datenbank. Spur 4: Stabilize Die entwickelten Komponenten werden getestet um sicherzustellen, dass die Lösung insgesamt erwartungsgemäß funktioniert. Es wird geprüft, ob die funktionalen Anforderungen sowie die Anforderungen an Performance und Sicherheit erfüllt sind. Sowohl das WhiteboxVerfahren, bei dem Wissen über den inneren Aufbau der zu testenden Komponente vorhanden ist, als auch das Blackbox-Verfahren, bei dem ohne Kenntnisse über den inneren Aufbau des Systems getestet wird, wird angewendet. Um das entwickelte System zu stabilisieren, ist auch ein Pilotbetrieb auf dieser Spur denkbar. Spur 5: Deploy Das entwickelte Produkt wird bereitgestellt, d.h. die getestete Lösung wird in den Produktivbetrieb übernommen. Die Stakeholder29 geben die Lösung frei, was damit gleichbedeutend sein sollte, dass die definierten Anforderungen erfüllt sind.

29

Als Stakeholder wird eine natürliche oder juristische Person bezeichnet, die ein berechtigtes Interesse an einem Wirtschaftsobjekt (Organisation, Projekt, Prozess) hat.

3.6 Herstellerspezifische Rahmenwerke

3.6.2

43

Der Cisco-Lebenszyklus für Netzwerke

Cisco Systems, Inc. ist ein bekanntes Unternehmen aus der Telekommunikationsbranche mit Sitz in den USA. Cisco hat sich unter anderem damit beschäftigt, welche Phasen ein ITNetzwerk während seines Lebenszyklus durchläuft und wie diese gestaltet werden sollten.

Plan

P

D

Design

Retirement

O

R

I

Optimize

Implement

O Operate Abbildung 29: PDIOO-Lebenzyklusmodell für IT-Netzwerke; Quelle: [TEP2005, S.7]

Das Lebenszyklusmodell von Cisco kennt folgende konsekutive Phasen30: Plan In dieser Phase werden die Anforderungen an das Netzwerk identifiziert. Es wird auch analysiert, an welchen Orten das Netzwerk installiert werden soll. Außerdem werden die Nutzer identifiziert, die Netzwerkdienste nutzen werden, und ihr Bandbreitenbedarf wird festgestellt. Diese Anforderungen und Rahmenbedingungen sollten dokumentiert werden, da sie für die nachfolgenden Phasen relevant sind. Design Diese Phase zerfällt in die Komponenten  logisches Design und  physisches Design. Die entsprechenden Konzepte berücksichtigen den Output der Plan-Phase als Input. Im Konzept für das logische Design spielt die Wahl der Netzwerktopologien eine zentrale Rolle. Im Konzept für das physische Design werden in Übereinstimmung mit dem logischen Design Technologien und Netzwerkkomponenten festgelegt.

30

[OPP2010, S. 7]

44

3 Vorgehensmodelle und Rahmenwerke

Implement Nach der Freigabe der Designkonzepte beginnt die Umsetzung der Konzepte. Das Netzwerk wird den Vorgaben entsprechend aufgebaut. Die Implementierungsschritte sind gleichzeitig Testfälle für die Konsistenz des Designs. Operate Die Inbetriebnahme ist der abschließende Test für die Effektivität des Netzwerkdesigns. In dieser Phase werden die Performance und andere Leistungsparameter des Netzwerks überwacht, um Fehler schnell zu erkennen. Die erkannten Fehler sind der Input für die nächste Phase. Optimize In dieser Phase wird angestrebt, aufgetretene Probleme so schnell zu lösen, dass die Netzwerkkonnektivität immer gewahrt bleibt. Es kann allerdings auch ein Redesign des Netzwerks erforderlich sein, wenn aufgrund von Designfehlern zu viele Probleme auftreten oder die Netzwerkperformance mit der Zeit abnimmt, weil der Netzwerkverkehr das Netzwerk an den Rand seiner Kapazität bringt. Ein Redesign kann auch notwendig sein, wenn sich die Anforderungen an das Netzwerk wesentlich ändern. Deshalb müssen die Anforderungen regelmäßig neu analysiert werden. Der Zyklus ist nun geschlossen, denn die Anforderungsanalyse ist eine Planungsaktivität. Die Retirement-Phase gehört zwar nicht direkt zum Zyklus hinzu, kann aber grundsätzlich jederzeit (meist in der Operate- oder Optimize-Phase) einsetzen. Auslöser für die Abschaffung der bisherigen IT-Infrastruktur sind meist:  Neuinstallation nach einem Redesign  Neuinstallation infolge von Anforderungsänderungen Bei der Abschaffung kann es sich auch um eine Teilabschaffung handeln, zum Beispiel:  Austausch der aktiven Netzwerkkomponenten mit Beibehaltung der Verkabelung  Austausch der aktiven Netzwerkkomponenten im Tertiärbereich eines LAN mit Beibehaltung der sekundären und primären Struktur  Austausch der IT-Infrastruktur in den Filialen eines Unternehmens bei Beibehaltung der IT-Infrastruktur in der Zentrale Cisco hat vor einiger Zeit seinen Netzwerk-Lebenszyklus um eine „Prepare-Phase“ ergänzt, so dass das Modell heutzutage meist PPDIOO abgekürzt wird. Hier geht es in erster Linie darum den Zweck des Projekts zu definieren und finanzielle und organisatorische Aspekte zu antizipieren.

4

Prozessqualität The quality of a system or product is highly influenced by the quality of the process used to develop and maintain it. The Carnegie Mellon Software Engineering Institute (SEI)

4.1

Qualitätsmanagement gemäß ISO 9000ff.

In der Norm DIN EN ISO 9000:2005 heißt es: Qualität ist der Grad, in dem eine Menge inhärenter Merkmale Anforderungen erfüllt. Inhärente Merkmale sind Eigenschaften, die ein zu beurteilendes Objekt dauerhaft besitzt. In diesem Sinne ist die Prozessqualität zu verstehen als der Grad, in dem die Merkmale eines Prozesses „die Anforderungen“ erfüllt. Prinzipien des Qualitätsmanagements Man irrt, wenn man erwartet, dass die bekannten Normen der ISO zum Thema Qualitätsmanagement die Anforderungen und Erwartungen im Detail benennen. Das wäre auch insofern unangemessen, als die Erwartungen an Qualität branchenspezifisch, objektspezifisch und kundenspezifisch sind. Es ist also erfolgversprechender, nach Prinzipien des Qualitätsmanagements zu suchen. Diese werden in Kapitel 0 der Norm ISO 9000:2005 präsentiert (siehe Kasten). Die acht Qualitätsmanagementprinzipien gemäß ISO 9000 1. Kundenorientierung Organisationen hängen von ihren Kunden ab und sollten daher gegenwärtige und künftige Kundenbedürfnisse verstehen, die Forderungen der Kunden erfüllen und danach streben, die Kundenerwartungen zu übertreffen. 2. Führung Führungskräfte sorgen für die einheitliche Zielsetzung und Ausrichtung der Organisation. Sie sollten das interne Umfeld schaffen und aufrechterhalten, in dem die Mitarbeiter sich voll und ganz für die Erreichung der Ziele der Organisation einsetzen können. 3. Einbeziehung der Mitarbeiter Die Mitarbeitenden sind auf allen Ebenen der prägende Faktor der Organisation. Ihre umfassende Einbeziehung ermöglicht es, ihre Fähigkeiten zum Vorteil der Organisation zu nutzen.

46

4 Prozessqualität

4. Prozessorientierung Ein gewünschtes Ergebnis lässt sich effizienter erreichen, wenn Tätigkeiten und dazugehörige Ressourcen als Prozess geleitet und gelenkt werden. 5. Systemorientiertes Management Prozesse, die miteinander in Wechselwirkung stehen, als System zu erkennen, zu verstehen und zu steuern trägt dazu bei, die Ziele der Organisation effektiv und effizient zu erreichen. 6. Ständige Verbesserung Die kontinuierliche Verbesserung aller Leistungen sollte eine ständige Aufgabe der Organisation sein. 7. Sachliche Entscheidungsfindung Wirksame Entscheidungen beruhen auf der Analyse von Daten und Informationen. 8. Lieferantenbeziehungen zum gegenseitigen Nutzen Eine Organisation und ihre Lieferanten sind voneinander abhängig. Beziehungen zum gegenseitigen Nutzen erhöhen die Wertschöpfung beider Seiten. Qualitätsmanagement von Prozessen Die genannten Prinzipien gelten auch für das Management der Qualität von Prozessen. Hier kann man folgende Zuspitzungen vornehmen:        

Prozesse sollten nicht nur betriebsintern geplant werden, sondern in enger Abstimmung mit den Empfängern des Outputs, also den Kunden. Die Prozessverantwortlichen sollten ihre Führungsaufgabe in Bezug auf den Prozess ernst nehmen und den Prozessausführenden ermöglichen, dass sie ungehindert die Prozessziele verfolgen können. Prozesse sollten kontrolliert und gesteuert werden. Die Prozessmitarbeiter sollten in die Prozessplanung und Prozessoptimierung einbezogen werden. Prozesse, die miteinander in Wechselwirkung stehen, sollten als System erkannt, verstanden und gesteuert werden. Die Verbesserung der Prozesse sollte eine ständige Aufgabe des Prozessverantwortlichen sein. Die Veränderung eines Prozesses sollte immer auf analysierten Informationen beruhen. Die Lieferanten sollten als wichtige Partner bei der Erreichung der Prozessziele gewürdigt werden. Deshalb sollte die Kommunikation mit ihnen nicht vernachlässigt werden.

4.2 Reifegradmodelle

47

Zusammenfassend gilt: Notwendig für einen Prozess hoher Qualität ist, dass - er in Abstimmung mit dem Kunden geplant wird, - der Prozessverantwortliche seine Führungsaufgabe ernst nimmt, - der Prozess kontrolliert und gesteuert wird, - die Prozessmitarbeiter in Planung und Optimierung einbezogen werden, - Wechselwirkungen mit anderen Prozessen erkannt werden, - der Prozess kontinuierlich verbessert wird, - der Prozess bei Bedarf auf der Basis von Fakten verändert wird - und die Lieferanten als wichtige Prozesspartner gewürdigt werden. All diese Eigenschaften sind aber noch nicht hinreichend für einen Prozess mit hoher Qualität, denn das Entscheidende ist, dass der geplante, kontrollierte und gesteuerte Prozess die Anforderungen erfüllt, die seitens der Kunden oder anderer Stakeholder bestehen. Wenn unter Prozessverbesserung hauptsächlich verstanden wird, dass die Anforderungen an den Prozess besser erfüllt werden (Effektivität), dann bestehen gute Chancen, dass der Prozess mit der Zeit das Kernmerkmal hoher Qualität, die Anforderungserfüllung, aufweist. Das Management der Organisation, die den Prozess betreibt, und die Shareholder zählen in der Regel auch die Effizienz, also den kostengünstige Betrieb des Prozesses, zu den Eigenschaften eines Prozesses hoher Qualität

4.2

Reifegradmodelle

Reifegradmodelle beschreiben die wesentlichen Elemente effektiver Prozesse. Sie sind keine Vorgehensmodelle. In den 80er Jahren begann man Prinzipien und Konzepte des Qualitätsmanagements auf die Softwareentwicklung anzuwenden. Diesbezüglich hat Watts Humphrey 1989 in seinem Buch Managing the Software Process wesentliche Arbeit geleistet. Reifegradmodelle basieren auf der Überzeugung, dass die Qualität eines Produkts erheblich von der Qualität des Prozesses abhängig ist, mit dem man das Produkt entwickelt und wartet. Deshalb sollen Reifegradmodelle dazu beitragen, die Prozessqualität in Organisationen schrittweise zu erhöhen. Sie weisen dem unreifen Prozess den Weg zur durch Qualität und Effektivität geprägten Reife.

4.2.1

Capability Maturity Model (CMM)

CMM für Software, der Vorgänger von CMMI, wurde 1993 vom Software Engineering Institute (SEI) der Carnegie Mellon University erstmals bekannt gemacht. CMM kennt folgende Reifegrade beziehungsweise Reifestufen: 1. Initial. Der Softwareprozess hat Ad-hoc-Charakter und verläuft gelegentlich chaotisch. Der Erfolg ist vom Talent und Einsatz einzelner Personen abhängig. 2. Repeatable. Grundlegende Projektmanagementverfahren sind eingeführt, um die Kosten, die Zeit und die Funktionalität zu überwachen. Bei ähnlichen Projekten früher erzielte Erfolge sind wiederholbar.

48

4 Prozessqualität

3.

Defined. Sowohl für das Management als auch für das Engineering des Softwareprozesses sind Aktivitäten definiert und standardisiert. In allen Projekten wird eine freigegebene und auf die Organisation zugeschnittene Version des Prozesses zur Entwicklung und Wartung von Software benutzt. 4. Managed. Kennzahlen zum Prozess sind definiert und zugehörige Werte werden gesammelt, um den Zustand zu überwachen. 5. Optimizing. Ein kontinuierlicher Verbesserungsprozess ist etabliert. Wesentliche Inputs sind hier quantitative Feedbacks vom Prozess und Ergebnisse von Pilotversuchen zur Umsetzung neuer Ideen und Technologien. Im Jahr 2000 wurde CMM von CMMI abgelöst

4.2.2

Capability Maturity Model Integration (CMMI)

CMMI ist noch stärker auf Softwareentwicklungsprozesse abgestimmt als CMM. CMMI31 ist mittlerweile eine Familie von Modellen: 

CMMI für Beschaffung



CMMI für Entwicklung



CMMI für Dienstleistungen

CMMI kennt sechs Fähigkeitsgrade. Ein Fähigkeitsgrad besteht aus einem Ziel und damit verbundenen Praktiken, die Prozesse verbessern können. Sie sind eine Ergänzung zu den Reifegraden.

31

[CKS2006]

5

Organisation von Prozessen Wenn die Sprache nicht stimmt, ist das, was gesagt wird, nicht das, was gemeint ist. So kommen keine guten Werke zustande. Also dulde man keine Willkür in den Worten. Konfuzius

Der Weg von der Planung bis zur Inbetriebnahme einer IT-Infrastruktur lässt sich als Prozess interpretieren. Deshalb soll in diesem Teil des Buchs insbesondere dargestellt werden, wie man Prozesse erfasst, analysiert, beschreibt und einführt. Wie wir in Kapitel 2 gesehen haben, besteht ein Prozess aus einer Menge von Tätigkeiten mit einem definierten Start- und Endpunkt, zu der es in der Regel einen Input und einen Output gibt. Soll nun ein Prozess sachgerecht organisiert werden, so sollten von der Planung bis zum Betrieb des Prozesses folgende Phasen durchlaufen werden32: Ablauf der Prozessorganisation 1. Analyse 2. Planung 3. Beschreibung 4. Einführung 5. Steuerung

5.1 Erfassung und Analyse von Prozessen Um einen Prozess angemessen analysieren zu können, ist es erforderlich, den Prozess zunächst hinreichend zu erfassen (Ist-Aufnahme). Bei der Ist-Aufnahme sind sowohl das Top-down- als auch das Bottom-up-Vorgehen möglich. Beim Bottom-Up-Ansatz geht man von der bestehenden Funktionsorganisation und den derzeitigen operativen Aktivitäten aus und bündelt Prozesse nach ablauf-, informations- und kostenrechnungstechnischen Aktivitäten. Der Bezug zur Strategie und zu den Kunden fehlt weitgehend. Der Top-Down-Ansatz geht dagegen von der Geschäftsstrategie (Geschäftsfelder, Kundengruppen,…) aus. Weitere Ausgangsdaten sind die Kundenanforderungen sowie das Leistungsangebot und die Kernkompetenzen der Organisation. Bei diesem Ansatz ist ein Verständnis der geschäftlichen Rahmenbedingungen vonnöten. Bei der Ist-Aufnahme von Prozessen, insbesondere Geschäftsprozessen, ist der Top-Down-Ansatz meist besser geeignet, da er die Verbindung mit der taktischen und strategischen Ebene garantiert. IT-Prozesse sind dazu da, die Geschäftsprozesse des Unternehmens zu unterstützen. Man spricht heutzutage von „Business Alignment“ und meint damit eine Ausrichtung der IT-Prozesse an den Geschäftszielen des

32

[OLF2009,S.180]

50

5 Organisation von Prozessen

Unternehmens. Würde man die Geschäftsprozesse hauptsächlich nach der Bottom-UpMethode erfassen, so bestünde die Gefahr, dass der Prozess die Erfüllung dieses Zwecks nicht gewährleisten kann. Wichtige Ausgangsdaten für die Erfassung und Gewichtung der Geschäftsprozesse sowie die Festlegung der Prozessziele sind33: 

Markt – Zielmärkte – Kundengruppen – Produkte



Kunden – Kundenanforderungen bzw. -erwartungen – Kundenbedürfnisse



Strategie – Wettbewerbsstrategie – Kernkompetenzen

5.1.1

Kundenorientierung

Es ist nicht mehr umstritten, dass die Kundenorientierung ein kritischer Erfolgsfaktor bei der Einführung von Geschäftsprozessen ist. Auch bei den IT-Prozessen hat sich diese Perspektive mehr und mehr durchgesetzt. Nun könnte der Planer eines IT-Prozesses bei der Ist-Aufnahme des Prozesses zu bedenken geben: „Aber ich habe gar keinen Kunden“. Hierzu ist zu sagen, dass ein Prozess immer einen externen oder internen Kunden hat, denn der Empfänger des Prozessoutputs ist der Prozesskunde. Auch für den Fall, dass ein Leiter einer IT-Abteilung einen Prozess zur Einführung von betriebsinternen IT-Infrastrukturen plant (Prozessverantwortlicher), ist es von Bedeutung, dass er sich des Kunden bewusst ist. Sein Auftraggeber ist sein Kunde. Es ist generell sehr wichtig, einen Auftraggeber zu haben, anderenfalls hätte man auch keinen Kunden. Der Nutzer bzw. Anwender eines Systems ist nicht im eigentlichen Sinne der Kunde. Im Servicemanagement ist der Kunde derjenige, mit dem eine Vereinbarung über die Güte einer Dienstleistung (Service Level Agreement) getroffen wird. Hat man keinen Auftraggeber, gibt es auch niemanden, mit dem man solche Vereinbarungen treffen könnte. Der IT-Leiter würde den Prozess in diesem Fall nach eigenem Gutdünken planen und einführen. Die Erwartungen an den Prozess wären ungeklärt. Die Kundenorientierung ist also nicht nur für typische IT-Dienstleister mit eindeutigen Kundenverhältnissen relevant, sondern auch für interne IT-Organisationen. In letzterem Fall sollte der IT-Leiter dafür sorgen, dass er den CIO, einen Bereichsleiter, ein Vorstandsmitglied oder den CEO als Kunden gewinnt. Es muss klar sein, dass die Zufriedenheit des Kunden hauptsächlich ein Ergebnis der Zufriedenheit der Nutzer ist. Es ist dementsprechend wichtig damit zu rechnen, dass viele Kundenerwartungen letzten Endes Erwartungen der Nutzer sind. Ein Prozessverantwortlicher sollte folgende Fragen beantworten können34:

33 34

[SSE2008, S. 123] [SSE2008, S. 124]

5.1 Erfassung und Analyse von Prozessen     

51

Womit verdient der Kunde sein Geld? Was sind die kritischen Erfolgsfaktoren des Kunden? Was sind die kritischen Prozesse des Kunden? Was sind die Hauptprobleme des Kunden? Wie kann der Prozess dem Kunden bei der Lösung eines Problems am besten helfen?

Die Antworten beeinflussen die Definition der eigenen Prozesse. Es wird nochmals deutlich, dass für einen Prozessverantwortlichen, der kaum Ahnung von seinem Kunden hat, ein erhebliches Risiko besteht, dass der Prozess seinen Zweck verfehlt. Aufgrund der erheblichen Bedeutung der Kundenorientierung hat sich das sogenannte Anforderungsmanagement (Requirements Engineering) professionalisiert. Eine der diesbezüglichen Grundfragen lautet: Wie muss der Prozess gestaltet sein, damit die Forderungen und Erwartungen der Kunden (Stakeholder) erfüllt werden? Man sollte nicht nur die Anforderungen der Kunden, sondern auch die der anderen Stakeholder kennen. Beispielsweise ist nicht sicher, dass die Erwartungen der Shareholder eines Unternehmens zufrieden sind, wenn die Kunden es sind. In Anlehnung an die Arbeit von N. Kano35 unterscheidet man folgende Typen von Anforderungen36: 

Leistungsanforderungen – von den Kunden ausdrücklich erwartet – führen je nach Erfüllungsgrad zu entsprechender Zufriedenheit oder Unzufriedenheit



Basisanforderungen – von den Kunden stillschweigend erwartet, ohne explizit genannt zu werden – erzielen keine volle Zufriedenheit, auch wenn sie erreicht werden – führen zu starker Unzufriedenheit, wenn sie nicht erreicht werden



Begeisterungsanforderungen37 – von den Kunden weder implizit noch explizit erwartet – erzielen Begeisterung bei Erfüllung – starker Einfluss auf Kundenzufriedenheit und Loyalität

5.1.2

Die Ist-Aufnahme

Um einen Prozess zielführend planen und beschreiben zu können, ist es bedeutsam, alle wichtigen Parameter sorgfältig zu erfassen. Olfert erfragt dazu folgende Parameter38:

35

Journal of the Japanese Society for Quality Control 14 (2): 39–48, 1984 [SSE2008, S. 126] 37 auch: Begeisterungsfaktoren 36

38

[OLF2009, S. 184]

52

5 Organisation von Prozessen

Tabelle 4: Aufnahmeinhalte für einen Prozess am Beispiel der Faktura Fragewort

Fragegegenstand

Beispiel: Rechnung

Was Wie Wer Womit Wo Wie viele Wann Wie lange Wie oft Wie teuer Warum Wozu

Objekt Verrichtung Subjekt Sachmittel Ort Menge Zeitpunkt Zeitdauer Häufigkeit Kosten Ursache Zweck

Rechnung Schreiben Fakturistin Computer Gebäude 3, Zimmer 22 30 Stück pro Tag Ab 13.00 Uhr 4 Stunden Täglich 2.000 EUR pro Monat Warenlieferung Zahlung

Aufnahmequellen39 Menschen Relevant sind vor allem Unternehmensleitung, Bereichsleitung, Abteilungsleitung und ausführende Mitarbeiter (Aufgabenträger). Dokumente Von Interesse sind hauptsächlich Aufbaudarstellungen (Organisationspläne, Stellenbeschreibungen etc.), Prozessdarstellungen (Datenflusspläne, Ablaufpläne etc.), Vorgaben (Richtlinien, Arbeitsanweisungen, Handbücher) und frühere Ist-Aufnahme-Daten. Arbeitsmittel des Organisators Beachtung sollten in erster Linie Formulare, Korrespondenz, Karteien (Datenbanken) und Anweisungen finden. Wichtige Erfassungstechniken    

Interview Fragebogen Beobachtung Selbstaufschreibung

Das Interview wird anhand eines Plans durchgeführt und ausgewertet. Der Fragebogen kann auch ohne Interview eingesetzt werden. Die Beobachtung eines Prozesses kann einmalig oder mehrmalig stattfinden. Der Beobachtungszeitraum sollte auf die Spezifika des Prozesses abgestimmt sein. Ein spezielles Beobachtungsverfahren ist die Multimomentaufnahme. Sie liefert auf Stichprobenbasis Aussagen zur Tätigkeitsverteilung von Mitarbeitern, die mit statistischen Methoden erzielt werden. Bei der Selbstaufschreibung beobachtet sich der Mitarbeiter einer Organisation selbst und dokumentiert seine Tätigkeiten in Erfassungsformularen.

39

[OLF2009, S. 183]

5.1 Erfassung und Analyse von Prozessen

5.1.3

53

Die Analyse

Die Aufgabe der Analyse eines Prozesses fällt in der Regel dem Prozesseigner (Process Owner) zu, wenn ein solcher schon benannt ist. Ansonsten kommen hierfür externe Berater oder interne Manager in Frage. Wichtig für den Analytiker ist ein grundsätzliches Vorverständnis des Prozesses. Für die Analyse gibt es verschiedene Organisationstechniken, unter anderem40:    

Benchmarking Schwachstellenanalyse per Checklistenverfahren SWOT-Analyse Wirtschaftlichkeitsanalyse

Mit Hilfe der Analyse (Ist-Kritik) soll die Abweichung des Ist-Zustands vom Soll-Zustand ermittelt werden. Es müssen also die Ergebnisse der Ist-Aufnahme vorliegen und der angestrebte Zustand bekannt sein. Das Soll sollte von den Zielen des Unternehmens abgeleitet sein. Ist der zu analysierende Prozess noch nicht klar definiert, so müssen vor der Ist-Kritik zunächst die Prozessziele (also der Soll-Zustand) fixiert werden, damit der Soll-Ist-Vergleich durchgeführt werden kann. Ist der Prozess bereits eingeführt, so beruht die Ist-Aufnahme auch auf Erfahrungen mit dem Prozessbetrieb. Benchmarking Benchmarking ist eine Methode, mit der sich durch zielgerichtete Vergleiche mehrerer Prozesse der beste als Leitobjekt zur Leistungsoptimierung ermitteln lässt (Best-PracticeBenchmarking). Notwendig ist das Vorhandensein bzw. die Festlegung von Kennzahlen. Danach werden die zugehörigen Daten erhoben und ausgewertet. Nach Ermittlung des Besten werden „Best Practices“ abgeleitet. Es ist nicht unbedingt erforderlich, ein eigenes Objekt in den Vergleich mit einzubringen. Es kann sich auch um ein rein externes Benchmarking handeln. Als Vorgehensphasen bekannt geworden sind die 10 Stufen von Xerox (R. C. Camp)41: 1. Auswählen des Betrachtungsgegenstands 2. Identifizieren der besten Praktiker 3. Daten erheben 4. Gap-Analyse durchführen 5. Performanceniveau projizieren 6. Analyseresultate kommunizieren 7. Funktionale Ziele aufstellen 8. Handlungsplan entwickeln 9. Plan umsetzen und Resultate überwachen 10. Benchmarking wiederholen

40 41

[OLF2009, S. 189} Sentinel events: evaluating cause and planning improvement von Joint Commission Resources, Joint Commission on Accreditation of Healthcare Organizations, S. 23

54

5 Organisation von Prozessen

Schwachstellenanalyse per Checklistenverfahren Eine Prüfliste ist ein bewährtes Hilfsmittel zum Auffinden von Schwachstellen. Es handelt sich um eine Zusammenstellung von logisch abgeleiteten oder aus der Erfahrung ermittelten Fragen. Die Liste soll gewährleisten, dass alle Schwachstellen des Ist-Zustandes erkannt werden. Die Qualität des Verfahrens hängt also hauptsächlich von der Qualität der Prüffragen ab. Normalerweise werden allgemeine und spezielle Fragen miteinander kombiniert. Für die Erstellung der Checkliste gibt es üblicherweise folgende Möglichkeiten:   

Eigenerstellung durch einen erfahrenen Prozessorganisator Erwerb von geeigneten Checklisten, zum Beispiel von Unternehmensberatungen Benutzung von in der Literatur vorhandenen Checklisten

SWOT-Analyse Die SWOT-Analyse ist ein Methode zur Bewertung der Stärken (Strengths), Schwächen (Weaknesses), Chancen (Opportunities) und Bedrohungen (Threats) eines Unternehmens oder eines Projekts. Bei der Analyse werden interne und externe Faktoren identifiziert, die förderlich für die Erreichung des definierten Ziels sind oder die Erreichung behindern.  

Interne Faktoren: Stärken und Schwächen der Organisation Externe Faktoren: Chancen und Bedrohungen, die von der Organisationsumgebung verursacht werden Die Identifikation dieser vier Faktoren ermöglicht die Ableitung von Handlungsempfehlungen, die die Erreichung des Ziels begünstigen. Die Anwendbarkeit der Methode ist nicht auf die Objekte Unternehmen oder Projekt beschränkt, sie lässt sich in vielen Entscheidungssituationen anwenden, für die ein Zielzustand definiert wurde. Definierte Prozesse besitzen definierte Ziele. Im Rahmen der Prozessoptimierung ist die SWOT-Analyse anwendbar. Die Analyse mündet üblicherweise in eine Matrix, in der interne und externe Faktoren gegenübergestellt werden, um jeweils die richtige Handlungsstrategie wählen zu können. Die in Tabelle 5 gezeigte Matrix ist auf das jeweilige Analyseobjekt hin abzustimmen. Tabelle 5: SWOT-Matrix42 SWOT Externe Sicht (Aufgabe, Wettbewerb, Markt)

Opportunities (Möglichkeiten) Threats (Bedrohungen)

42

Interne Sicht (Team, Unternehmen, Produkt) Strengths (Stärken) Weaknesses (Schwächen) Mit den eigenen Stärken Eigene Schwächen beseitigen, bestehende Chancen nutzen um bestehende Chancen zu nutzen Mit den eigenen Stärken Eigene Schwachstellen bestehenden Bedrohungen beseitigen, um Schaden zu entgegenwirken verhindern.

Quelle: http://www.projektmagazin.de/glossarterm/swot-analyse

5.2 Planung von Prozessen

55

Wirtschaftlichkeitsanalyse Die Wirtschaftlichkeitsanalyse besteht in der Regel darin, erhobene Istwerte mit den Werten möglicher anderer Lösungen zu vergleichen. Bei der Organisationsanalyse kommen insbesondere folgende Kennzahlen in Frage:    

Kosten Deckungsbeitrag Gewinn Rentabilität

Es ist auch möglich diese Kennzahlen im Hinblick auf eine einzelne Lösung zu erheben und zu bewerten. Für Prozesse sind diese Kennzahlen anzupassen. Typischerweise werden folgende Kennzahlen betrachtet:    

Prozesskosten Geschäftswertbeitrag Prozesserlöse Prozessrendite

5.2 Planung von Prozessen 5.2.1

Strategische Planung

Zu den wichtigsten Aufgaben der 23.03.2012 auf strategischer Ebene gehören:  

Planung der strategischen Prozessziele Planung langfristiger Maßnahmen für den Prozess, beispielsweise Aufbau und Ausbau von Kernkompetenzen  Strategische Gewichtung des Prozesses  Planung der Integration des Prozesses in den Organisationsaufbau des Unternehmens Denkbar ist die frühzeitige Festlegung des Prozessverantwortlichen. Wenn klar ist, wer für den in Planung befindlichen Prozess zuständig, also insbesondere für die Zielerreichung verantwortlich ist, dann kann man die betreffende Person bereits in der strategischen Phase am Planungsvorgang beteiligen. Andererseits geht es bei der strategischen Ausrichtung des Prozesses weniger um einzelne handelnde Personen, die ja jederzeit wechseln können, sondern um den Prozess an sich in der Langfristperspektive. Es ist also eine Frage der Abwägung, ob die in Frage kommende Person auch auf der strategischen Ebene einen nützlichen Beitrag leisten kann. Es kann auch sinnvoll sein, den Prozesseigner43 erst bei der operativen Planung festzulegen. Auf der operativen Ebene fehlen dem Berater beziehungsweise dem Manager oft die Detailkenntnisse, um hier hinreichend sachgerechte Festlegungen treffen zu können. Spätestens in der Phase der Prozessdokumentation muss der Prozessverantwortliche feststehen.

43

gleichbedeutend mit „Prozesseigentümer“ und „Prozessverantwortlicher“ bzw. englisch „Process Owner“

56

5 Organisation von Prozessen

Balanced Scorecard Die Balanced Scorecard ist ein mittlerweile bewährtes Instrument zur Definition von strategischen Zielen und den zugehörigen Aktivitäten. Der Ansatz verfolgt das Ziel, die klassischen, finanziellen Kennzahlensysteme um weitere wichtige Geschäftsperspektiven zu ergänzen. In der ursprünglichen Scorecard von Kaplan und Norton44 werden vier Perspektiven betrachtet:    

Finanzperspektive Kundenperspektive Prozessperspektive Lern- und Innovationsperspektive Financial

Ziele Messgröße Zielwert Maßnahmen

„To succeed financially, how should we appear to our shareholders?”

Customer

Ziele Messgröße Zielwert Maßnahmen

Vision and Strategy

„To achieve our vision, how should we appear to our customers?”

Learning and Growth

Internal Business Process

Ziele Messgröße Zielwert Maßnahmen

„To satisfy our customers, what business processes must we excel at?”

Ziele Messgröße Zielwert Maßnahmen

„To achieve our vision, how will we sustain our ability to change and improve?”

Abbildung 30: Balanced Scorecard gemäß R. S. Kaplan und D. P. Norton

Eine der großen Stärken der Balanced Scorecard ist die Forderung, Ziele konkret zu formulieren. Zu einem Ziel gehört nicht nur eine Aussage wie „Erhöhung der Kundenzufriedenheit“. Der Ersteller der Zielkarte muss auch angeben, womit er dieses Ziel messen möchte (Messgröße) und was der Zielwert ist. Scorecard für Prozesse Der Erfolg der Zielkarte hat dazu geführt, dass die Karte auch für einzelne Organisationseinheiten (zum Beispiel IT) oder Prozesse eingeführt wurde.

44

Kaplan, Robert S.; Norton, David P.: The balanced scorecard: Translating strategy into action. Harvard Business School Press, Boston, MA 1996.

5.2 Planung von Prozessen Prozessfinanzen

Prozesskunden

57 Ziele Messgröße Zielwert Maßnahmen

Ziele Messgröße Zielwert Maßnahmen

Vision und Strategie

Potenziale und Ressourcen

Prozessorganisation

Ziele Messgröße Zielwert Maßnahmen

Ziele Messgröße Zielwert Maßnahmen

Abbildung 31: Balanced Scorecard für Prozesse

45

Als Perspektiven für Prozesse sind geeignet: 

Prozessfinanzen – Leitfrage: Welche finanziellen Ziele muss der Prozess erreichen, um zur Wertsteigerung des Unternehmens beizutragen? – Zielobjekte: Geschäftswertbeitrag, Prozesskosten, Prozessumsatz, Prozesserlöse, Prozessproduktivität, Prozessrendite



Prozesskunden – Leitfrage: Welche strategischen Ziele sind hinsichtlich der Befriedigung der Wünsche des Prozesskunden zu setzen, um die finanziellen Ziele zu erreichen? – Zielobjekte: Kundenzufriedenheit, Kundenbindung, Reklamationen, Fehler, Liefertreue



Prozessorganisation – Leitfrage: Wie müssen die Prozesse und Strukturen gestaltet sein, um die Prozessziele zu erreichen und die Wandlungsfähigkeit der Organisation zu fördern? – Zielobjekte: Prozesszeiten (Durchlaufzeit), Prozessqualität, Prozesstermintreue, Prozesskostentreue



Prozesspotenziale – Leitfrage: Wie müssen die Potenziale und Ressourcen des Prozesses ausgerichtet sein, um die gesetzten Ziele zu erreichen?

45

in Anlehnung an: Fink, C.A., Prozessorientierte Unternehmensplanung, Gabler, 2003, S. 166

58

5 Organisation von Prozessen –

Zielobjekte: Mitarbeiterzufriedenheit, Personalqualifikation, Mitarbeitertraining, Job Rotation, IT-Struktur, Prozessorganisation, Prozessreifegrad

Tabelle 6: Beispiel: Prozessfinanzen Ziel Messgröße Zielwert Maßnahme

Senkung der Prozesskosten Leistungsmengeninduzierte Kosten (lmi) 20% Elektronische Unterstützung des Prozesses

Es sollte erwähnt werden, dass diese Scorecard speziell auf Geschäftsprozesse, also wertschöpfende Prozesse, ausgerichtet ist und für Unterstützungsprozesse nicht vollständig verwendbar ist. Das liegt daran, dass ein Unterstützungsprozess keine direkte Wertschöpfung aufzuweisen hat. Die Verwendung der Balanced Scorecard für Prozesse hat den Vorteil, dass die Prozessziele strategiekonform und systematisch abgeleitet werden. Außerdem werden bei der Zielfestlegung mehrere Prozessperspektiven berücksichtigt. Insbesondere wird dafür gesorgt, dass auch die Ressourcen und Potenziale Bestandteil des Zielsystems sind.

5.2.2

Operative Planung

Bei der Prozessplanung, die ins Detail geht, sind hauptsächlich folgende Aufgaben zu lösen:  

Auswahl der Leistungsparameter Festlegung des Messsystems und der mit den Leistungsparametern korrespondierenden Messgrößen (Metriken) Leistungsparameter geben Auskunft über den Leistungsstand (Effektivität und Effizienz) und die Leistungsentwicklung eines Prozesses. Die korrekte Auswahl und Anwendung beeinflusst den Erfolg der Prozesssteuerung. Sie setzen sich aus Ziel- und Messgrößen zusammen. Über die Prozessmessgrößen wird die Istleistung der Prozesse gemessen. Bei der Festlegung der operativen Prozessziele ist es wichtig zu beachten, dass die Ziele nicht nur klar zum Ausdruck bringen müssen, was erreicht werden soll, sondern auch wo, in welchem Ausmaß und bis zu welchem Termin. Nur so können Soll-Ist-Abweichungen festgestellt werden, die Korrekturmaßnahmen und Lerneffekte ermöglichen. Leistungsparameter Leistungsparameter nennt man auch „Performance Indicators“. Sie sollten folgende Eigenschaften haben:       

Strategiebezug Kundenbezug Bezug auf quantifizierbare Sachverhalte Akzeptanz durch Verständlichkeit und Klarheit Widerspruchsfreiheit (gegenüber anderen Leistungsparametern) Zugewiesene Verantwortung für Erfassung und Auswertung der Leistungsparameter Berücksichtigung der Wirtschaftlichkeit (günstiges Nutzen-Aufwands-Verhältnis)

5.3 Beschreibung von Prozessen

59

Bei der Beurteilung der Prozesseffektivität ist die Kundenzufriedenheit ein besonders wichtiger Parameter. Bei der Beurteilung der Prozesseffizienz sind insbesondere bedeutsam: Prozesszeit, Termintreue, Prozessqualität, Prozesskosten. Man nennt diese fünf Leistungsparameter auch „Key Performance Indicators“ (KPI) des Prozesses. Wichtig ist es, sowohl die Ergebnisse der strategischen als auch die der operativen Planung sorgfältig zu dokumentieren, denn diese Informationen werden für die Prozessbeschreibung und den Prozessbetrieb dringend gebraucht.

5.3 Beschreibung von Prozessen Nach Erfassung, Analyse und Planung ist es nun möglich, den Prozess zu beschreiben. Zu den wichtigsten Ergebnissen dieser Phase gehören:   

Diagramme zur Struktur der Prozesses Prozessdokument Diagramme zur Modellierung des Prozesses

5.3.1

Prozesskonzept

Um einen Prozess schriftlich fixieren zu können, sind noch etliche wichtige Eingabedaten zu erfassen bzw. festzulegen. Hierzu hat K. Olfert in [OLF2009] wichtige Hinweise gegeben. Die festzuzulegenden Aspekte sind hauptsächlich46:         

Prozesstyp Aufgliederung der Aufgaben Eingaben und Ausgaben Prozessverantwortliche Sachmitteleinsatz Arbeitsgangorganisation Arbeitsplatzorganisation Prozesszeiten Art der Datenorganisation

Das Ergebnis dieser Aktivitäten kann man als Prozesskonzept bezeichnen. Auf einige dieser Aspekte wird im Folgenden näher eingegangen. Die Prozesszeiten sind bereits in Kapitel 2 behandelt worden. Prozesstyp Zunächst gilt es sich Klarheit zu verschaffen, in welcher Form die Arbeit grundsätzlich erledigt werden soll. Als Varianten gibt es unter anderem:    

46

manuelle Arbeitsdurchführung arbeitsteilige Büroarbeit Dialogdatenverarbeitung automatische Aufgabenerledigung

[OLF2009, S. 201ff.]

60

5 Organisation von Prozessen

Prozessstruktur Eine bewährte Form der Ermittlung der Aufgabenstruktur ist die Aufgabenanalyse (Arbeitsanalyse). Die Aufgabenstruktur wird in hierarchischer Form dargestellt. Prozesse haben eine hierarchische Aufbaustruktur, die in der Regel aus mehreren Ebenen besteht. Aufgabe der Analyse ist es dementsprechend, den Prozess in Teile zu zerlegen. Der Arbeitsschritt ist das kleinste Strukturelement. Er wird auch Verrichtung genannt.

Teilprozess 1 Geschäftsprozess

Analyse

Prozessschritt 2.1 Teilprozess 2 Prozessschritt 2.2 Teilprozess 3

Arbeitsschritt 2.2.1

Logisches Design IT-Prozess

Arbeitsschritt 2.2.2

Planung

Verkabelung Physisches Design

Realisierung

Aktive Komponenten

Abbildung 32: Prozessaufbaustruktur (Ausschnitt) mit Beispiel

Die Prozessaufbaustruktur aus Abbildung 32 lässt sich auch über die Dezimalgliederung nachvollziehen: 1. IT-Prozess 1.1 Analyse 1.2 Planung 1.2.1 Logisches Design 1.2.2 Physisches Design 1.2.2.1 Verkabelung 1.3 Realisierung Wenn ein Prozess nur aus einem Teilprozess und der Teilprozess nur aus einem Prozessschritt besteht, ist das die kleinstmögliche Struktur: Prozess  Arbeitsschritt 1  Arbeitsschritt 2  …  Arbeitsschritt n In den meisten Fällen ist die Prozessstruktur komplexer. Eingaben und Ausgaben Der Output (Ergebnis) des Prozesses sollte bereits bei der Prozessanalyse bzw. Prozessplanung festgelegt werden. Denn eine Zielfixierung ohne Festlegung der Prozessergebnisse ist nicht vollständig durchführbar, weil in der Regel einige Zielobjekte ohne Kenntnis des Outputs nicht ableitbar sind. Jeder Prozess benötigt Inputs, um die Prozessobjekte bearbeiten zu können:   

Personal Material Informationen

5.3 Beschreibung von Prozessen

61

Tabelle 7: Beispiel: Verpackungsprozess (Prozessschritt Verpacken); Quelle: [OLF2009, S. 209] Eingaben

Verarbeitung

Sachmittel / Hilfsmittel Ausgaben

(1) Karton (2) Füllmaterial (3) Versandgüter (4) Klebeband (5) Versandliste (1) Güter in Karton ordnen (2) Abhaken der Versandliste (3) Mit Füllmaterial verfüllen (4) Mit Klebeband verschließen (1) Arbeitsraum (2) Arbeitstisch (1) Verschlossenes Paket (2) Abgehakte Versandliste

Die Ausgaben vorgelagerter Teilprozesse sind häufig Inputs für nachgelagerte Teilprozesse. Prozessverantwortliche Es ist eine wichtige Entscheidung im Prozessmanagement, wer die Verantwortung für einen Prozess übertragen bekommt. Der Prozesseigner ist der Gesamtprozessverantwortliche. Er wird gegebenenfalls von Teilprozessverantwortlichen unterstützt. Teilprozessverantwortliche sind dem Prozesseigner fachlich unterstellt. Der Prozessverantwortliche ist für die Erreichung der Prozessziele verantwortlich. Es handelt sich im Gegensatz zu einer Beauftragung als Projektleiter üblicherweise um eine unbefristete Rolle. Mit der Ernennung des Verantwortlichen ist die Festlegung von Aufgaben, Verantwortung und Befugnissen verbunden. Hier sind insbesondere folgende Aufgaben zu nennen:  Mitwirkung bei der Planung und Einführung des Prozesses  Schulung und Training der Prozessnutzer  effektive und effiziente Durchführung des Prozesses Die Zuweisung von Prozessrollen sollte dokumentiert werden. Dafür sind standardisierte Formblätter hilfreich. Tabelle 8: Formular zur Dokumentation von Prozessrollen Prozess Name Rolle Kurzbeschreibung Aufgaben Verantwortung Befugnisse

Personalnummer

62

5 Organisation von Prozessen

Sachmitteleinsatz Sachmittel sind Gegenstände, die den Prozessnutzer bei der Bearbeitung des Prozessobjekts unterstützen. Diese Hilfsmittel sind weder mit dem Bearbeitungsobjekt noch mit dem Prozessinput oder -output zu verwechseln (siehe Abbildung 2). Es gibt47: 

Klassische Sachmittel – Räume, zum Beispiel Werkstätten, Lagerräume, Arbeitsräume und Serverräume – Arbeitsmittel, zum Beispiel Arbeitstische, Schränke, Kopiergeräte, Maschinen und Roboter – Ordnungsmittel, zum Beispiel Ablaufdiagramme, Verfahrensanweisungen, Organisationshandbücher und Richtlinien



Datenverarbeitungsmittel – Hardware – Software

 Kommunikationsmittel, zum Beispiel WWW, Intranet, E-Mail und Telefon In Tabelle 7 findet man dem Prozessschritt Verpacken zugeordnete Sachmittel. Grundsätzlich ist die Sachmittelplanung davon geprägt, ob es sich um einen Prozess handelt, bei dem der Mensch den Prozess ohne Maschinenunterstützung durchläuft, ob Mensch und Maschine kombiniert zum Einsatz kommen oder ob der Prozessdurchlauf nur durch Maschinen bewerkstelligt wird. Es ist zu identifizieren, welche Anforderungen die einzusetzenden Sachmittel erbringen müssen und welchem Zweck die geplanten Sachmittel dienen. Es ist festzulegen, an welchem Ort in welchem Umfang Sachmittel zur Verfügung zu stellen und einzusetzen sind. Arbeitsgangorganisation Nach Kosiol ist ein Arbeitsgang ein Komplex aus mehreren Verrichtungen, der einem Arbeitssubjekt zur Durchführung übertragen wird.48 Verrichtungen sind konkrete Aktivitäten, die zu einem Arbeitsgang zusammengestellt werden, um einer Aufgabe gerecht zu werden.

Verpacken

Adressieren

Frankieren

Abbildung 33: Arbeitsgang Versand

Zu einer vollständigen Darstellung des Arbeitsgangs gemäß EVA-Prinzip Eingabe  Verarbeitung  Ausgabe gehört auch die Auflistung der Ein- und Ausgaben (siehe Tabelle 7). Aufgrund des hierarchischen Charakters von Prozessen kann ein Arbeitsgang eines Prozesses als Teilprozess eines Prozesses angesehen werden, wenn seine Verrichtungen eindeutig nur diesem Arbeitsgang zugeordnet sind.

47 48

[OLF2009, S. 63] Kosiol. E.: Organisation der Unternehmung. Wiesbaden: Gabler, 1962.

5.3 Beschreibung von Prozessen

63

Art der Datenorganisation Es geht um die Art der Speicherung beziehungsweise Archivierung der benötigten oder erarbeiteten Daten. Es bedarf der Klärung, in welcher Form die Speicherung durchgeführt werden soll (Dateien, Datenbanken, Listen, Karteien, Vorgangsakten).

5.3.2

Prozessdokumentation

Das dokumentierte Prozesskonzept kann als Dokumentation des Prozesses angesehen werden. In der Praxis hat es sich allerdings bewährt, das Konzept in einem Prozessbeschreibungsdokument zusammenzufassen und dabei auf das Vorhandensein aller relevanten Prozessattribute zu achten. Es ist möglich, dieses Dokument sowohl formfrei als auch formgebunden anzufertigen. Bei der formgebundenen Variante unterstützt ein Formblatt bei der Gewährleistung der Vollständigkeit aller relevanten Aspekte. Tabelle 9: Beispiel eines Prozessdokuments (Formblatt) Prozessname: Auftragsabwicklungsprozess für ITI-Komponenten Von: Auftragseingang Prozessverantwortliche(r): Bis: bezahlte Rechnung Maxi Musterfrau, Abteilung N Objekt: Kundenauftrag Typ des Prozesses: Geschäftsprozess Kunde: Muster AG Besondere Prozessanforderungen: Hohe Liefertermintreue Prozessdurchlaufzeit: 7 Tage Sachmittel: Lagerraum, Werkstatt, Fahrzeug, Arbeitstisch, Konfigurationsrichtlinie Prozessinputs: Prozessoutputs: Angebot, Auftrag Gelieferte und installierte Komponente, bezahlte Rechnung Durchführungsorte: Unternehmenszentrale, vom Kunden definierte(r) Installationsorte

Das Formblatt zur Prozessbeschreibung geht nicht ins Detail. Details finden sich hauptsächlich im Prozesskonzept. Wenn ein Prozess aus mehreren Teilprozessen besteht, dann sollten auch die Teilprozesse formal beschrieben werden. Die Prozessbeschreibung sagt meist nur wenig über den eigentlichen Prozessablauf aus. Daher bedarf die Prozessbeschreibung ergänzend der Prozessmodellierung.

5.3.3

Prozessmodellierung

Unter Prozessmodellierung versteht man die Darstellung von Prozessen. Man betrachtet die Reihenfolge der auszuführenden Prozessschritte, die Schnittstellen des Prozesses und seiner Teilprozesse sowie die Zuordnung zu den jeweiligen Organisationseinheiten. Es gibt zwei typische Darstellungsformen, die ihren Ursprung überwiegend in der Softwaretechnik haben:  

Skriptbasierte Modellierung Diagrammbasierte Modellierung

Skriptbasierte Modellierung In diesem Fall wird der Prozessablauf als Text dargestellt. Der Text basiert auf einer formalen Notation, die an eine Programmiersprache erinnert. Ein skriptbasiertes Modell besitzt eine hohe Präzision der Darstellung, andererseits allerdings eine geringe Anschaulichkeit.

64

5 Organisation von Prozessen

Skript für den Prozess Pizzaservice START INPUT Bestellung Bestellung_prüfen IF Bestellung korrekt THEN Pizza_belegen Pizza_backen Pizza_einpacken GOSUB Pizza_liefern ELSE Kundenrückruf GOTO START END In der Programmierung ist die textbasierte Codierung (in einer speziellen Programmiersprache) meist unerlässlich. Das allgemeine Prozessmanagement dagegen beschränkt sich aufgrund der höheren Anschaulichkeit meist auf die Darstellung des Prozessablaufs mit Hilfe von Diagrammen. Diagrammbasierte Modellierung Im Folgenden wird eine Auswahl von bewährten Darstellungsvarianten präsentiert. Es werden auch die Grundlagen von BPMN dargestellt, da sich BPMN wachsender Beliebtheit erfreut. Datenflussorientierte Diagramme

Kontrollflussorientierte Diagramme

Objektorientierte Diagramme

Flussplan gemäß DIN 66001

EPK

UML

IDEFDiagramme

BPMN

SOM

…

…

…

Abbildung 34: Darstellungsvarianten bei der Prozessmodellierung

Es werden nur flussorientierte Diagramme dargestellt, da sie leichte Vergleichbarkeit besitzen und für unseren Anwendungsfall geeignet sind. Die ausgewählten Diagramme finden bei der Darstellung von Prozessabläufen relativ viel Verwendung. Ein kontrollflussorientiertes Diagramm bietet im Gegensatz zum datenflussorientierten Diagramm die Möglichkeit des

5.3 Beschreibung von Prozessen

65

Abweichens von der Abarbeitungssequenz durch Kontrollstrukturen (Verzweigungen, Schleifen). Programmablaufplan gemäß DIN 66001 Der Programmablaufplan gemäß DIN 66001 sollte nicht mit dem Datenflussplan gemäß DIN 66001 verwechselt werden. Hauptsächlich werden die in Abbildung 35 dargestellten Elemente verwendet. Start/Stop Verzweigung

Nein

Ja Operation Ein-/Ausgabe Unterprogramm Abbildung 35: Datenflusssymbole

Abbildung 36: Programmablaufplan zum Pizzaservice

66

5 Organisation von Prozessen

EPK-Diagramme Die Methode zur Darstellung eines Prozessablaufs als ereignisgesteuerte Prozesskette wurde in den 1990er Jahren von Scheer, Keller und Nüttgens entwickelt. Die Methode ist relativ leicht erlernbar und hat in der Praxis weite Akzeptanz und Verbreitung sowohl bei Anwendern als auch bei IT-Spezialisten gefunden. Tabelle 10: Elemente der EPK-Basisnotation Element

Symbol

Beschreibung

Ereignis

beschreibt einen eingetretenen Zustand, von dem der weitere Verlauf des Prozesses abhängt

Funktion

beschreibt die Transformation einer Eingabeinformation in eine Ausgabeinformation. Sie beschreibt Aufgaben, die einem Ereignis folgen.

Informationsobjekt

repräsentiert ein Objekt der realen Welt (Material, Ressource, Information)

Datenfluss

stellt dar ob eine Funktion auf ein Informationsobjekt lesend, ändernd oder schreibend zugreift.

Kontrollfluss

stellt den zeitlich-logischen Zusammenhang von Ereignissen und Funktionen dar.

Prozesspfad

zeigt die Verbindung vom modellierten zu einem anderen Prozess.

Logische Verknüpfungen

Wenn zu einer Funktion oder einem Ereignis mehrere Kontrollflüsse führen, kann die Steuerungslogik durch einen Konnektor spezifiziert werden: AND, OR, XOR

Organisationseinheit

beschreibt eine Gliederungseinheit einer Organisation.

Zuordnung

zeigt an, welche Organisationseinheit für eine Funktion verantwortlich ist.

BPMN-Diagramme Die Modellierungsnotation für Geschäftsprozesse BPMN (Business Process Modeling Notation). Version 1 wurde im Jahr 2004 veröffentlicht. Ein Ziel war, eine für alle Prozessbeteiligte gut verständliche Modellierungssprache anzubieten. Mittels BPMN kann man Prozessdiagramme erstellen, die im Wesentlichen aus Aktivitäten, Ereignissen und Verzweigungen samt den zugehörigen Verbindungen bestehen. Tabelle 11: Elemente der BPMN-Notation Element

Symbol

Atomare Aktivität

Beschreibung beschreibt einen von der Organisation ausgeführten Vorgang

Task

Aktivität mit Subprozess

Subprocess

beschreibt einen von der Organisation ausgeführten Vorgang, der einen Teilprozess enthält

Startereignis

löst den Prozess aus

Zwischenereignis

beschreibt einen Zwischenzustand

Endereignis

signalisiert das Ende des Prozesses

Gateway (Verzweigung)

Entscheidet über den weiteren Verlauf des Prozesses. Als Varianten existieren: AND, OR, XOR und eventbasiert

Kontrollfluss

beschreibt den zeitlichen Ablauf im Prozess

Nachrichtenfluss

beschreibt den Austausch von Nachrichten zwischen zwei Objekten

5.4 Einführung von Prozessen

67

Planer Manager

Organisation

Die BPMN-Elemente lassen sich in verschiedenen „Schwimmbecken“ organisieren. Es gibt Pools and Lanes. Ein Pool repräsentiert einen Beteiligten an einem Arbeitsgang, das heißt einen Benutzer, eine Benutzerrolle, ein System oder eine Organisation. Ein Pool kann man in Lanes unterteilen. Lanes sind also Substrukturen von Pools. AN1 Ist-Analyse

AN2 Soll-Aufnahme

AN3 Alternativenbewertung

PM1 Initiierung

Abbildung 37: Teilprozess Analyse zum Infrastrukturerrichtungsprozess

5.4 Einführung von Prozessen Damit ein Prozess in einer Organisation erfolgreich eingeführt werden kann, bedarf es der Berücksichtigung von Erfolgs- und Misserfolgsfaktoren. Nicht zielführend ist die ungeplante, also unstrukturierte und unkoordinierte Einführung. Bei der Einführung eines neuen Prozesses handelt es sich um ein Projekt, das nach den Regeln des Projektmanagements durchgeführt werden sollte. In größeren Organisationen mit vielen Prozessen sollte man die Einführung eines Prozessmanagementsystems erwägen.49 Auf jeden Fall sollte es eine Richtlinie bzw. Verfahrensanweisung für die Einführung von Prozessen geben. Vor der Einführung eines Prozesses muss sichergestellt sein, dass alle Voraussetzungen für das erfolgreiche Durchlaufen gegeben sind. Die Checkliste sollte in der angegebenen Reihenfolge durchlaufen werden, damit der Gesamtaufwand für notwendige Iterationen so gering wie möglich bleibt. Checkliste 1 – Einführung eines Prozesses 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

49

Ist der Prozessverantwortliche festgelegt? Liegt eine Prozessbeschreibung vor? Ist ein Prozessablaufdiagramm erforderlich? An welchen Orten soll der Prozess durchlaufen werden? Ist der Prozess mit den Fachleuten abgestimmt worden? Ist der Prozess von den Fachleuten akzeptiert worden? Stehen die notwendigen Sachmittel in genügender Anzahl bereit? Stehen die notwendigen Sachmittel an den relevanten Orten bereit? Ist der Prozess in der Organisation (ggf. auch Betriebsrat) bekannt gemacht worden? Sind die Prozessbeteiligten geschult worden? Sind die Prozessbeteiligten motiviert worden?

siehe [SSE2008, S.405ff.]

68 12. 13. 14.

5 Organisation von Prozessen Sind Kunden und Lieferanten über den Prozess informiert worden? Sind die Prozessbeteiligten einsatzbereit? Gibt es einen Notfallplan bei Problemen mit der Einführung?

5.5 Steuerung von Prozessen Die Kontrolle und Verbesserung von Prozessen ist für qualitätsbewusste Unternehmen unerlässlich. Gemäß Kapitel 8 der Norm ISO 9001:2008 ist die Kundenzufriedenheit die zentrale Kenngröße für die Bewertung des Prozessoutputs. Weitere Kennzahlen (unter anderem Prozesskosten, Liefertreue, Durchlaufzeit, Mitarbeiterzufriedenheit, Prozessreifegrad) können wir der in Abschnitt 5.2 geschilderten Balanced Scorecard für Prozesse entnehmen. Auf Basis der Auswertungen sollten Korrekturmaßnahmen ergriffen werden, um die Prozessqualität zu verbessern. Für IT-Prozesse liefert das IT-Governance-Rahmenwerk CObIT spezielle Kennzahlen. Im Hinblick auf den Prozess zur Errichtung von IT-Infrastrukturen sind hauptsächlich die Prozessdomänen Acquire and Implement (AI) und Deliver and Support (DS) von Belang. In den Tabellen 12 und 13 sind Performance-Indikatoren aufgelistet, die für den Infrastrukturerrichtungsprozess relevant sind.

5.5 Steuerung von Prozessen

69

Tabelle 12: Perfomanceindikatoren für die Prozessdomäne AI Prozesskürzel

Name

Kennzahlen

AI1

Identify Automated Solutions



Anteil der zufriedenen Nutzer



Anteil der durchgeführten Machbarkeitsstudien

AI3

Acquire and Maintain Technology Infrastructure

Mittlere Zeit für die Konfiguration von ITI-Komponenten

AI4

Enable Operation and Use

Anzahl von Betriebsstörungen, die auf mangelnde Schulung von Nutzern oder unzureichende Dokumentation zurückzuführen sind

AI5

Procure IT Resources



Reduzierung der Einkaufskosten in Prozent



Anteil der wichtigen Stakeholder, die mit den Lieferanten zufrieden sind



Anteil der Anforderungen, die mit der erstellten Lösung erfüllt sind



Anteil der Beschaffungen, die pünktlich eingetroffen sind



Anteil der Änderungen, die Notfallbehebungen sind



Anteil der erfolglosen Änderungen



Anteil der Änderungen, die nicht ordnungsgemäß durchgeführt worden sind



Anzahl der Patches für Infrastrukturkomponenten



Anteil der Systeme, die die Nutzenerwartung erfüllt haben



Anzahl von Abweichungen von den Installationsrichtlinien, die im Rahmen eines Audits festgestellt worden sind



Arbeiten nach der Inbetriebnahme, die auf mangelnde Benutzerakzeptanz zurückzuführen sind



Anfragen durch Benutzer an den Support, die auf mangelndes Training zurückzuführen sind



Ausfallzeit, die auf unzureichende Tests zurückzuführen ist



Anteil von Projekten mit einem dokumentierten und freigegebenen Testplan



Anteil von Änderungen, die ohne Freigabe durchgeführt worden sind

AI6

AI7

Manage Changes

Install Solutions and Changes

70

5 Organisation von Prozessen

Tabelle 13: Perfomanceindikatoren für die Prozessdomäne DS Prozesskürzel DS1

DS5

Name

Kennzahlen

Define and Manage Service Levels



Anteil der Stakeholder, die bestätigen , dass der ausgelieferte Service dem vereinbarten Serviceniveau entspricht



Anteil der Benutzer, die bestätigen , dass der ausgelieferte Service dem vereinbarten Serviceniveau entspricht



Anzahl der SLA-Reviews pro Jahr

Ensure Systems Security



Anteil der Serviceniveaus, die gemessen wurden



Anteil der Serviceniveaus, die ausgewertet wurden



Anzahl der Personentage, die aufgewendet wurden, um in Abstimmung mit dem Kunden ein Serviceniveau anzupassen



Anzahl der Störungen mit Auswirkung auf das Geschäft



Anzahl der Systeme, die die Sicherheitsanforderungen nicht erfüllen



Zeitaufwand für das Verleihen von Zugriffsberechtigungen



Anzahl und Typ von abgewehrter Schadsoftware



Anzahl von festgestellten Sicherheitsereignissen



Anzahl und Typ überflüssiger Benutzerkonten



Anzahl von abgewehrten Angriffen mit nicht autorisierten IP-Adressen oder nicht zugelassenem Netzwerkverkehr

DS9

Manage the Configuration

Anzahl der Abweichungen zwischen der realisierten und der dokumentierten Konfiguration

DS10

Manage Problems



Anzahl der registrierten Probleme



Anteil der wiederkehrenden Probleme



Anteil der zufriedenen Benutzer bezüglich der Datenverfügbarkeit



Anzahl der Abweichungen von Complianceanforderungen infolge von Speichermanagementproblemen



Anteil der erfolgreichen Datenwiederherstellungen



Mittlere Zeit für Datenwiederherstellungen



Ausfallzeit infolge mangelnder Speicherkapazität



Häufigkeit des Backupmedientests



Anzahl von Störungen infolge von Sicherheitsmängeln bei der Infrastruktur



Anzahl unzulässiger Zutritte zu IT-Räumen



Häufigkeit von Trainings zur Infrastruktursicherheit



Anteil von Personal, das im Bereich der Infrastruktursicherheit geschult worden ist



Häufigkeit von Risikoassessments



Anzahl von Risikoreduzierungsprüfungen

DS11

DS12

Manage Data

Manage the Physical Environment

6

Methodik zur Definition und Strukturierung des Infrastrukturerrichtungsprozesses Nichts kann existieren ohne Ordnung. Nichts kann entstehen ohne Chaos. Albert Einstein

Die Erfassung, Analyse, Planung, Beschreibung, Einführung und Steuerung von Prozessen ist ein vielseitig durchdachtes Thema. In Kapitel 5 wurden wesentliche Eckpunkte hierzu vorgestellt. Diese Erkenntnisse werden auf den Prozess zur Errichtung von IT-Infrastrukturen (kurz: Infrastrukturerrichtungsprozess) angewendet werden. Es geht in erster Linie um die Planung und Beschreibung des Prozesses. Die gleichartigen Elemente der ITI-Projekte fließen in den Prozess ein. Die Ablaufstruktur muss unabhängig vom konkreten Projekt gleich sein, da es sonst kein Prozess ist. Der Prozess sollte die typischen Projektvarianten berücksichtigen. In Kapitel 3 wurden einige Modelle zum Vorgehen bei der Einführung von IT-Systemen vorgestellt. Bei Oppenheimer [OPP2010] und Teare/Paquet [TEP2005] findet sich ein Lebenszyklus speziell für IT-Netzwerke. Außerdem haben auch die ManagementFrameworks ITIL und CObIT Beiträge zum Thema geleistet. Etliche diese Erkenntnisse können in das Design des Infrastrukturerrichtungsprozesses einfließen beziehungsweise auf dieses adaptiert werden. Näheres hierzu wird in Kapitel 9 ausgeführt.

6.1 Projektvarianten IT-Infrastrukturprojekte können deutlich unterschiedliche Ausprägungen bezüglich Art und Volumen besitzen. An verschiedenen Stellen wird zwischen IT-Service-Providern (in unserem Zusammenhang auch „ITI-Provider“ genannt) und anderen Organisationen (im Folgenden auch „ITI-Nutzer“ genannt) an verschiedenen Stellen unterschieden werden, da die Erwartungen der jeweiligen Kunden unterschiedlich sind und bei internen Projekten in der Regel andere Zielgewichtungen bestehen als bei Projekten mit externem Auftraggeber. Grundsätzlich kann man die in Tabelle 14 aufgeführten Typen unterscheiden. Tabelle 14: Varianten von ITI-Projekten Beauftragtes Projekt Fokus auf das Netzwerk Fokus auf Frontends und Backends

PB1

Selbst realisiertes Projekt PS1

PB2

PS2

72

6 Methodik zur Definition und Strukturierung des Infrastrukturerrichtungsprozesses

Im Einzelnen werden derzeit meist folgende Projekte durchgeführt: 

PB1/PS1 – Neuinstallationen • Erstellung eines neuen IT-Netzwerks (passive und aktive Komponenten) • Installation eines SAN • Einführung eines Verzeichnisdienstes für das IT-Netzwerk • Einführung von VPN • Einführung von drahtlosen Netzen • Einführung eines Systems zur Unterstützung von Sprach- bzw. Videokommunikation • Einführung von Infrastrukturkomponenten zur Verbesserung der IT-Sicherheit – Veränderungen • Austausch der Verkabelung • Erweiterung eines IT-Netzwerks • Technologiewechsel in einem IT-Netzwerk • Protokollwechsel in einem IT-Netzwerk • Update / Upgrade / Austausch von Komponenten in drahtlosen Netzen • Aktualisierung von Infrastrukturkomponenten zur Verbesserung der ITSicherheit  PB2/PS2 – Neuinstallationen • Ausstattung der IT-Infrastruktur mit Frontends • Ausstattung der IT-Infrastruktur mit Servern • Installation von virtuellen Systemen • Rollout von Arbeitsplatzcomputern – Veränderungen • Verbesserung des Benutzer-/Identitätsmanagements • Update / Upgrade des Betriebssystems auf den Frontends Alle Projekte sollten grundsätzlich die gleiche Ablaufstruktur haben (Basisprozess). Im Folgenden werden sowohl der Basisprozess entwickelt als auch bei Bedarf unterschiedliche Prozessvarianten entsprechend den Projektvarianten vorgestellt.

6.2 Projektmanagement Da es sich beim Infrastrukturerrichtungsprozess um einen Prozess zur Professionalisierung von ITI-Projekten handelt, liegt es nahe, dass das Buch auch eine Handreichung zum Management von ITI-Projekten sein könnte. Wie wir aber in Kapitel 3 gesehen haben, ist diese Thematik auf allgemeiner Ebene schon intensiv bearbeitet und dokumentiert worden. Auch im IT-Bereich gibt es etliche Publikationen zu diesem Thema. Wir hatten uns unter anderem mit den „Microsoft Solution Framework Essentials“ [TUR2006] befasst, wo es insbesondere Hinweise zum Teammanagement bei Projekten gibt. Ertragreich bezüglich der Organisation von Projekten ist [BRU2005]. Es sind also hinreichend viele und gute Anregungen verfügbar, so dass eine vertiefte Behandlung dieser Aspekte hier nicht erforderlich ist. In den folgenden Kapiteln soll der Schwerpunkt auf ITI-spezifischen Aspekten der Prozessorganisation liegen. Es soll damit klargestellt sein, dass man durch das Studium dieses

6.3 Pilotnutzer

73

Buches noch kein guter ITI-Projektleiter im umfassenden Sinn wird, sondern in erster Linie den Ablauf und die Steuerung von ITI-Projekten professionalisieren kann.

6.3 Pilotnutzer Praxispartner aus der ITI-Branche wurden in die Entwicklung des Infrastrukturerrichtungsprozesses (im Folgenden auch kurz: ISEP oder ISE-Prozess) eingebunden. Diese Dienstleister wurden unter anderem zu ihrer bisherigen Vorgehensweise bei ITI-Projekten und dem diesbezüglichen Verbesserungsbedarf befragt. Weiterhin wurden deren Erwartungen hinsichtlich eines strukturierten Vorgehensmodells ermittelt. Außerdem wurden den Praxispartnern die geplanten Prozessabläufe zum Testen übermittelt. Die diesbezüglichen Ergebnisse hatten Einfluss auf die Inhalte des Buchs.

7

Infrastrukturerrichtungsprozess: Die Ist-Situation Wenn einer von euch einen Turm bauen will, setzt er sich dann nicht zuerst hin und rechnet, ob seine Mittel für das ganze Vorhaben ausreichen? Sonst könnte es geschehen, dass er das Fundament gelegt hat, dann aber den Bau nicht fertig stellen kann. Und alle, die es sehen, würden ihn verspotten und sagen: Der da hat einen Bau begonnen und konnte ihn nicht zu Ende führen. Jesus Christus

Zur Analyse eines Prozesses gehört die Erfassung von markt- bzw. kundenspezifischen Gegebenheiten. In einem konkreten Beratungsfall würde die Ist-Situation einer spezifischen Organisation erfasst werden. Um dem ISE-Prozess allgemein gerecht zu werden, sollte man   

7.1

wichtige Umgebungsfaktoren heutiger Organisationen beschreiben, wesentliche Parameter des Infrastrukturerrichtungsprozesses identifizieren und typische Ist-Zustände von Organisationen, die IT-Infrastrukturen nutzen oder errichten, darstellen.

Der Markt und die Kunden

Die Berücksichtigung des Marktes mit seinen Kunden und ihren Anforderungen an Produkte und Dienstleistungen ist vor allem für IT-Service-Provider ein wichtiger Prozess-Input. Es gibt folgende Aspekte zu beachten: 1. Der Markt für IT-Infrastrukturen liegt in erster Linie nicht im Bereich der Endverbraucher. Allerdings gibt es mittlerweile auch mehr und mehr Heimnetze. Diese werden jedoch meist in Eigenregie – mehr oder weniger erfolgreich – installiert und konfiguriert. Die Konzentration des Errichters von IT-Infrastrukturen ist deshalb auf den gewerblichen und behördlichen Bereich gerichtet. 2. Eine Branchenspezialisierung ist nicht unbedingt nötig, da die Infrastrukturservices grundsätzlich keinen direkten Branchenbezug haben. Es ist allerdings dennoch erwägenswert, sich auf Kunden aus bestimmten Branchen zu spezialisieren, da ein guter Provider bei der Planung einer IT-Infrastruktur eben auch die Geschäftsziele und -strategien des Kunden sowie seine spezifischen Bedürfnisse wahrnehmen sollte, um darauf die ITInfrastruktur optimal abstimmen zu können. Als Beispiel kann man die Installation von Komponenten in Fertigungsumgebungen nennen.

76

7 Infrastrukturerrichtungsprozess: Die Ist-Situation

Tabelle 15: Die sieben wichtigsten Erwartungen an IT-Infrastrukturen bei Benutzern und Experten Eigenschaft Verfügbarkeit51 Performance52 Zuverlässigkeit der Geräte Benutzerfreundlichkeit Sicherheit53 Testdurchführung Interoperabilität54 Skalierbarkeit55

3.

Priorität50 bei Benutzern 1 4 3 5 1 --5 5

Priorität51 bei Experten 1 7 5 --1 5 4 1

Heutige Kunden haben diverse Erwartungen, wenn sie an den Betrieb einer ITInfrastruktur denken. Im Rahmen einer Umfrage unter ITI-Benutzern und ITI-Experten wurde nach den wichtigsten Eigenschaften einer IT-Infrastruktur gefragt. Auch wenn die Grundgesamtheit der Befragten nicht ausreichend ist, um von einem statistisch stabilem Ergebnis sprechen zu können, so sind doch die Tendenzen so ausgeprägt, dass die Ergebnisse Beachtung finden sollten. Neben den in Tabelle 15 gelisteten Eigenschaften wurden auch Merkmale Bewährtheit, Modernität und Wirtschaftlichkeit abgefragt. Diese konnten aber bei beiden Gruppen nicht unter wichtigsten sieben ITI-Eigenschaften vordringen. Hinsichtlich der Wirtschaftlichkeit mag das überraschend anmuten, allerdings relativiert sich diese Tatsache angesichts dessen, dass die Befragten weder Manager noch Controller waren. Heutzutage erwarten Kunden nicht selten eine Verfügbarkeit ihrer Server und Netzwerkkomponenten von 99,9%. Die Performanceanforderungen werden häufig in Datentransferraten zum Ausdruck gebracht. Die Erwartungen steigen, zum Beispiel: 1 Gbit/s Datenübertragungsrate im Sekundärbereich des lokalen Netzes. Des Weiteren mögen Kunden keine IT-Infrastrukturen, die nur mit hohem Aufwand oder gar nicht erweiterbar sind. Das sollte der Auftragnehmer berücksichtigen. Außerdem gewinnen Sicherheitsaspekte zunehmend an Bedeutung. Kunden formulieren beispielsweise Erwartungen an die Transportsicherheit ihrer Daten und die Zugriffskontrolle ihrer Server oder die Zutrittskontrolle für Räume. Die genannten Erwartungen sind auch für Organisationen von Relevanz, die interne Auftraggeber für ihre ITI-Projekte haben.

Kundenorientierung Qualitätsorientierte Prozessverantwortliche und Projektleiter werden sich nicht mit sieben oder acht Standarderwartungen zufrieden geben, sondern genauer erforschen, wie die Situation des Kunden ist. In Kapitel 5 hatten wir folgende Fragen kennen gelernt: 

50

Womit verdient der Kunde sein Geld?

Die höchste Priorität ist 1. Eigenschaft eines IT-Systems, seine Funktionen innerhalb eines definierten Zeitraumes (Betriebszeit) zu erbringen. 52 Leistungsfähigkeit eines IT-Systems 53 Sicherung von Vertraulichkeit, Integrität und Authentizität (teilweise auch Verfügbarkeit) 54 Das funktionelle Zusammenwirken von Komponenten in einem System 55 Erweiterbarkeit der Struktur ohne großen Zeit- und Geldaufwand 51

7.1 Der Markt und die Kunden    

77

Was sind die kritischen Erfolgsfaktoren des Kunden? Was sind die kritischen Prozesse des Kunden? Was sind die Hauptprobleme des Kunden? Wie kann der Prozess den Kunden bei der Lösung ihrer Probleme am besten helfen?

Der ITI-Kunde kann aus jeder Branche stammen. Eine Bank verdient ihr Geld mit Finanzdienstleistungen, ein Automobilhersteller mit Automobilen, eine Spedition mit Transportdienstleistungen. Der ITI-Provider sollte sich genau bewusst machen, wo und wie beim Kunden die Wertschöpfung erzielt wird. Denn die IT-Infrastruktur darf die Wertschöpfung des Unternehmens keinesfalls behindern, sondern sollte zur Erhöhung der Wertschöpfung beitragen. Bei den kritischen Erfolgsfaktoren geht es um Faktoren, die für die Erreichung der Unternehmensziele von zentraler Bedeutung sind. Für eine Bank sind die Verfügbarkeit und Sicherheit der ITI sicher kritische Erfolgsfaktoren. Insofern sollte man diesbezüglich mit hohen expliziten und impliziten Erwartungen (Basis- oder Leistungsanforderungen) rechnen. Für ein Hotel mit 20 Zimmern ist das Funktionieren des Buchungs- und Belegungssystems sicherlich von Bedeutung, die manuelle Abwicklung von Buchungen, Belegungen und Zahlungen, unterstützt von Telefon und Telefax, ist aber sicher auch ersatzweise und zeitweise möglich. Die ITI ist ein Erfolgsfaktor, weil sie den Betrieb erleichtert und den Umsatz erhöht, aber er ist hier nicht kritisch. Es ist weiterhin zu beachten, dass das Augenmerk nicht nur auf den für den Unternehmenserfolg wichtigen IT-Faktoren liegen sollte, sondern die Geschäftsperspektive einzunehmen ist. Die meisten kritischen Erfolgsfaktoren (zum Beispiel die Wirtschaftlichkeit des Produktionsprozesses oder die Korrektheit des Buchhaltungsprozesses) sind zunächst einmal IT-unabhängige Faktoren. Aufgabe des ITI-Projektleiters ist es, aus diesen Faktoren die zugehörigen ITI-Erfolgsfaktoren abzuleiten und entsprechende Konsequenzen für das Design der IT-Infrastruktur zu ziehen. Kritische Prozesse haben einen engen Bezug zu den kritischen Erfolgsfaktoren und der Wertschöpfung. Beispielsweise ist für den Automobilhersteller der Produktionsprozess kritisch, weil dieser Prozess als Output das zu verkaufende bzw. bestellte Produkt hat. Es handelt sich also um einen zentralen Geschäftsprozess. Die ITI hat heutzutage einen wesentlichen Anteil an der Unterstützung von kritischen Prozessen. Die Steuerung des Produktionsablaufs geschieht mehr und mehr automatisch. Industrienetze ermöglichen die Produktionssteuerung. Hier ist eine besondere Sorgfalt hinsichtlich der Verfügbarkeit der Steuerungssysteme und der Datenübertragungseinrichtungen zu wahren. Spätestens seit dem Auftreten des komplexen Stuxnet-Computerwurms, der bewiesen hat, dass auch industrielle Steuerungssysteme von Schadsoftware geschädigt werden können, ist das Sicherheitsbewusstsein der Industriekunden in diesem Bereich deutlich angewachsen. Das sollte der ITI-Errichter in diesem Fall besonders beachten. Der erfahrene ITI-Dienstleister steht in der Gefahr, individuelle und spezielle Probleme des Kunden zu übersehen und somit nicht zu berücksichtigen, wenn er sich angesichts des Wissens um die kritischen Erfolgsfaktoren und Prozesse der Kundschaft zu sicher über sein Kundenwissen sein sollte. Möglicherweise hat der nächste Kunde eine ganze Reihe von Sicherheitsvorfällen mit erheblichem Schadensausmaß hinter sich, so dass die Sicherheit der Infrastruktur ein kritischer Erfolgsfaktor für das Unternehmen geworden ist. Oder der übernächste Kunde ist ein PC-Assemblierer. Dann spielen die IT-Schnittstellen mit den

78

7 Infrastrukturerrichtungsprozess: Die Ist-Situation

Lieferanten für das Lieferkettenmanagement eine sehr wichtige unterstützende Rolle, und die Funktionsfähigkeit der Schnittstellen ist hier wahrscheinlich ein kritischer Erfolgsfaktor. Checkliste 2A (ITI-Provider) Markt und Kunden O O O O O O O O O O O

Handelt es sich bei dem Interessenten um ein Wirtschaftsunternehmen, um eine Behörde oder um eine Privatperson? Mit welchen dieser drei Kundentypen möchten wir Geschäfte machen? Haben wir branchenspezifisches Wissen? Ist dieses nötig? Was ist das Kerngeschäft des Kunden? Was sind die kritischen Erfolgsfaktoren des Kunden? Was sind die kritischen Prozesse des Kunden? Was sind die Hauptprobleme des Kunden? Gibt es außergewöhnliche Anforderungen des Kunden bezüglich Verfügbarkeit, Performance, Zuverlässigkeit, Benutzerfreundlichkeit, Sicherheit, Interoperabilität, Testdurchführung oder Skalierbarkeit? Gibt es außergewöhnliche Anforderungen des Kunden bezüglich Compliance? Haben wir die wichtigsten Anforderungen, Erwartungen und Bedürfnisse unseres Kunden erfasst, verstanden und dokumentiert? Was für voraussichtliche Auswirkungen hat die vorläufige Ist-Aufnahme auf dieses spezielle ITI-Projekt? Wurden diese dokumentiert?

Es ist gut, einen Prozess für die Errichtung von IT-Infrastrukturen zu haben. Das allein reicht aber nicht aus, denn es ist die Frage nach dem Reifegrad und der Qualität des Prozesses zu stellen. Und da ist einer der wesentlichen Leistungsparameter die Kundenzufriedenheit.56 Berücksichtigt der eingeführte ITI-Prozess wirklich die Anforderungen und Bedürfnisse des Kunden? Ist diese Berücksichtigung in der Prozessbeschreibung verankert? Um diesen Aspekt abzudecken, werden Checklisten angeboten. Somit kann ein ITI-Projekt frühzeitig, also noch vor dem eigentlichen Projektbeginn eingeordnet und eingeschätzt werden. Checkliste 2B (ITI-Nutzer) Markt und Kunden O O O O O

56

Steht bei unserer Organisation das Gewinnstreben im Vordergrund oder die Qualität der Prozesse bzw. Verfahren? Haben wir unsere kritischen Erfolgsfaktoren identifiziert? Haben wir unsere kritischen Prozesse identifiziert? Kennen wir unsere Hauptprobleme? Gibt es außergewöhnliche Anforderungen bezüglich Verfügbarkeit, Performance, Zuverlässigkeit, Benutzerfreundlichkeit, Sicherheit, Testdurchführung; Interoperabilität oder Skalierbarkeit?

Gemäß ISO 9001:2008 ist die Kundenzufriedenheit ein obligatorischer Parameter bei der Messung der Güte eines Qualitätsmanagementsystems.

7.1 Der Markt und die Kunden O O O O O O

79

Gibt es außergewöhnliche Anforderungen bezüglich Compliance? Haben wir unsere Anforderungen, Erwartungen und Bedürfnisse erfasst, verstanden und dokumentiert? Was für voraussichtliche Auswirkungen hat diese vorläufige Ist-Aufnahme auf das Projekt? Wurden diese dokumentiert? Reicht unser Know-How, um das ITI-Projekt eigenständig durchzuführen? Wo benötigen wir Unterstützung? Option: Welcher der in Frage kommenden ITI-Provider hat eine angemessene IstAufnahme durchgeführt und besitzt Verständnis unserer Prozesse bzw. Verfahren? Option: Versteht der ITI-Provider unser Kerngeschäft?

Strategische Aspekte Es ist wichtig bei der Prozesserfassung auch die strategischen Einflussfaktoren aufzunehmen und im Prozessablauf zu berücksichtigen. Die hier aufgeführten strategischen Aspekte ergänzen die Markt- und Kundenperspektive und haben für den Infrastrukturerrichtungsprozess lenkende Funktion. Die Aspekte sind wiederum unterschiedlich für ITI-Provider und ITI-Nutzer, also Organisationen, die ihre IT-Infrastruktur nutzen, um ihre Geschäftsprozesse so gut wie möglich zu unterstützen. Einige Aspekte überlappen sich mit der Markt- und Kundenperspektive. Diese Redundanzen haben aber den Vorteil, dass das Risiko eines fehlgeleiteten Prozessdurchlaufs minimiert wird. Ein ITI-Provider sollte sich die Frage stellen, ob der Kunde in seine Unternehmensstrategie passt. Sollte der Provider auf Industriekunden und Industrienetze ausgerichtet sein, so ist in Frage zu stellen, ob beispielsweise ein ITI-Auftrag von einem Versicherungsunternehmen angenommen werden sollte. Wenn ein Kunde nicht in die Unternehmensstrategie passt, so sollte der Auftrag nur angenommen werden, wenn das Management diesbezüglich eine bewusste Entscheidung getroffen hat und einen Plan für die Zurverfügungstellung von Know-How verabschiedet. Hat ein ITI-Provider 20 Mitarbeiter, sollte er sich strategisch nicht auf Großkunden ausrichten, da die Personalkapazität dafür in der Regel nicht ausreichend ist. Es ist allerdings erfahrungsgemäß kein Problem, dass ein solcher Provider ein mittelständisches Unternehmen bedient. Vielmehr ist es für Kunden häufig von Vorteil, wenn der Dienstleister kleines als das Unternehmen selbst ist, da es dann üblicherweise mit mehr Aufmerksamkeit und Wertschätzung behandelt wird. Umgekehrt ist es für einen großen ITI-Provider meist nicht sinnvoll, in seine Kundengruppenstrategie auch Kleinunternehmen aufzunehmen, da der Provider in diesen Fällen wegen meist umfangreicher Projektverwaltung relativ viel Zeitaufwand haben wird und das Preisgefüge nicht passt. Schließlich sollte eine risikobasierte Vorentscheidung darüber getroffen werden, ob das Projekt angenommen und durchgeführt werden sollte. Nicht jedes Projekt ist für jeden ITIProvider geeignet und nützlich. Vielleicht sind mögliche Projektschäden so wahrscheinlich, dass ein Vertragsabschluss zu riskant wäre.

80

7 Infrastrukturerrichtungsprozess: Die Ist-Situation

Checkliste 3A (ITI-Provider) Strategische Aspekte O O O O

O

Passt der Kunde zur Unternehmensstrategie? Passt unsere Größe zur Größe des Kunden? Lässt sich die Branche des Kunden mit unserer Unternehmensstrategie vereinbaren? Liegt bei einem strategisch unpassenden Kunden eine ausdrückliche Aufforderung der Unternehmensleitung zur Durchführung des Projekts vor? Sorgt die Unternehmens-/Behördenleitung in diesem Fall für das notwendige Personal und Know-how? Sind die Projektrisiken (finanzieller Schaden, Verlust des Kunden, Imageschaden etc.) insgesamt so einzuschätzen, dass das Projekt durchgeführt werden sollte?

Der ITI-Nutzer hat ebenfalls strategische Randbedingungen zu beachten. Die Unternehmensführung mag festgelegt haben, dass die eigene IT-Abteilung möglichst schlank sein soll. Dementsprechend gibt es einen hohen Anteil an Outsourcing oder Outtasking. Eine solche IT-Abteilung ist nicht in der Lage, ein größeres IT-Infrastrukturprojekt in Eigenregie durchzuführen. Ein anderer ITI-Nutzer hat marktbedingt hohen Kostendruck und dementsprechend beschlossen, dass bei Auftragsvergaben grundsätzlich der preiswerteste Anbieter ausgewählt werden soll. Eine solche strategische Vorgabe kann Entscheidungen, die aus der Markt- und Kundenperspektive herrühren, relativieren bzw. verändern. Checkliste 3B (ITI-Nutzer) Strategische Aspekte O O O O O

7.2

Sollen wir das ITI-Projekt in Eigenregie durchführen? Können wir das ITI-Projekt in Eigenregie durchführen? Entspricht der ITI-Provider unseren Ansprüchen? Ist der ITI-Provider als Partner zu klein oder zu groß? Gibt es ausnahmsweise Abweichungsmöglichkeiten von der Unternehmensstrategie? Wie ist der Ausnahmefall geregelt?

Die Prozessreife

Es ist nicht möglich, die diversen individuellen Ausgangssituationen von Unternehmen, Behörden und anderen Organisationen zu verallgemeinern und gleichzeitig den Besonderheiten gerecht zu werden. Es sollen aber typische Situationen beziehungsweise Zustände in Bezug auf den Reifegrad von Infrastrukturerrichtungsprozessen beschrieben werden. Der Prozess ist nicht definiert Nicht nur bei ITI-Nutzern, auch bei ITI-Providern ist es häufig so, dass der ISE-Prozess nicht hinreichend definiert ist. Häufig trifft man nur den CMMI-Reifegrad 1(Initial) an, der Prozess ist also nicht oder kaum strukturiert und dokumentiert. Gespräche mit ITI-Providern haben gezeigt, dass ein wichtiger Grund dafür ist, dass ein auf ITI-Projekte zugeschnittenes,

7.2 Die Prozessreife

81

praxisnahes Rahmenwerk bislang fehlt. Insbesondere lassen sich folgende Mängel feststellen, die auf die unzureichende Definition und Detaillierung des Prozesses zurückgeführt werden können: 

mangelhafte Kundenperspektive



unzureichende Anforderungsanalyse



unvollständige Zielerfassung



mangelhaftes Servicelevel-Management



fehlendes Sicherheitskonzept



unsystematische Tests



unzureichende Steuerung und Kontrolle bei und nach Inbetriebnahme der ITI

ITI-Projekte werden nicht ausreichend gesteuert Insbesondere bei ITI-Nutzer-Organisationen ist das Controlling von Projekten zur Errichtung von IT-Infrastrukturen bezüglich Zeit und Budget oft zu wenig ausgeprägt. Die Projektmanagementkompetenz lässt insbesondere bei kleineren Organisationen oft zu wünschen übrig. Das gilt auch für einige ITI-Provider. Solange es sich um kleine, einfache Projekte handelt, ist dieser Umstand hinnehmbar, bei komplexen, größeren Projekten können aber erhebliche Schäden am Budget und am Image entstehen.

8

Infrastrukturerrichtungsprozess: Die Definition Nur wer das Ziel kennt, kann treffen. Griechisches Sprichwort

Um den ISE-Prozess festzulegen zu können, sollte zunächst klar werden, welche die Gründe für solche Projekte sind. Dementsprechend kann man auch einen Zweck definieren. Darüber hinaus ist es von großer Bedeutung, für das jeweilige Projekt nachprüfbare Ziele festzulegen. Für die Einhaltung ist der Prozesseigner verantwortlich. Tabelle 16: Eigner der IT-Infrastrukturprojekte 57

Projektvariante(n) Unternehmensgröße Klein

PS1/PS2

PB1/PB2

IT-Leiter

Geschäftsführer

Mittel

IT-Leiter

Projektmanager

Groß

Teamleiter Infrastrukturservices

Projektmanager Infrastrukturservices

8.1

Zweck eines ITI-Projekts

Der Zweck eines IT-Projekts ist es, die Unterstützung der Geschäftsprozesse durch IT zu verbessern. Bei ITI-Projekten gibt es in diesem Rahmen diverse Anlässe samt dem jeweils damit verbundenen Zweck (siehe Tabelle 17).

57

siehe Kapitel 6

84

8 Infrastrukturerrichtungsprozess: Die Definition

Tabelle 17: Veranlassungsmöglichkeiten für ein IT-Infrastrukturprojekt Begründungskategorie Erstellung einer neuen ITI

Grund / Anlass Neugründung

Umzug

Verbesserung der ITIArchitektur

Erweiterung

ITI-Anbindung weiterer Standorte der Organisation Ermöglichung von Datenaustausch und zentraler Datenablage für weitere Organisationseinheiten, Gebäude oder Räume Ermöglichung von Extranet-Funktionalitäten

Fusion Heterogenität einer bestehenden ITI (zum Beispiel auf OSISchicht 2)

Integration der IT-Infrastrukturen Erhöhung der Performance Erhöhung der Verfügbarkeit Reduzierung des administrativen Aufwands Reduzierung der Kosten Ermöglichung bzw. Vereinfachung von ITIErweiterungen Ermöglichung bzw. Vereinfachung von Funktionsergänzungen Erhöhung der Performance Erhöhung der Sicherheit Gewährleistung der zukünftigen Funktionsfähigkeit Sicherstellung des Supports Zuverlässige Speicherung großer Datenmengen Optimierung des Datenbackups Verbesserung der Datenspiegelungsmöglichkeiten

Protokollwechsel (zum Beispiel IPv6) oder Protokollergänzung (zum Beispiel SSH)

kein SAN

Verbesserung der Leistung einer existierenden ITI

Erhöhung des Funktionsumfangs für eine bestehende ITI

Zweck des Projekts Ermöglichung des Datenaustauschs in der Organisation Ermöglichung zentraler Datenspeicherung Kommunikation mit externen Informationssystemen Wiederherstellung der Datenaustausch-, Datenspeicherungs- und Kommunikationsmöglichkeiten

kein VPN

Sicherer Transport zwischen LAN über externe Netze Ermöglichung der ITI-Anbindung von Computern an organisationsexternen Standorten

Unzureichende Datentransferrate

Ermöglichung transferintensiver Dienste Skalierbarkeit der ITI Schnellere Zurverfügungstellung von Daten

Unzureichende Sicherheit beim Datentransport

Reduzierung von Vertraulichkeitsrisiken Reduzierung von Integritätsrisiken Reduzierung von Authentizitätsrisiken

Unzureichende Sicherheit bei der Datenspeicherung

Reduzierung des Datenverlustrisikos Reduzierung von Vertraulichkeitsrisiken Reduzierung von Integritätsrisiken

Unzureichende Verfügbarkeit der Systeme

Hohe Verfügbarkeit des IT-Netzwerks Hohe Verfügbarkeit der Server Verringerung der Energiekosten Zentrale Kontoverwaltung Zentrale Verwaltung der Zugriffsberechtigungen

Zu hohe Energiekosten Kein zentrales Benutzer-/ Identitätsmanagement

8.2 Die Ziele

85

Begründungskategorie

Grund / Anlass

Wenig Funktionen für das Benutzer-/ Identitätsmanagement Unzureichende Möglichkeiten der Computerverwaltung

Keine Sprach- und Videokommunikation per ITI

8.2

Zweck des Projekts Reduzierung des administrativen Aufwands Reduzierung von Authentizitätsrisiken Sicherstellung der Benutzertrennung Ermöglichung von benutzerübergreifenden Richtlinien Reduzierung von Authentizitätsrisiken

Ermöglichung von systemübergreifenden Richtlinien Bessere Übersicht über Ort und Zustand der Systeme Homogenisierung der Kommunikationsnetze /systeme Steigerung der Flexibilität Reduzierung der Kosten

Die Ziele

Ziele sind ein konstituierendes Merkmal von Prozessen. Sie lassen sich auf der strategischen und der operativen Ebene formulieren. Die operativen Ziele sollten zur Erreichung der strategischen Ziele beitragen.

8.2.1

Strategische Ziele

Die Balanced Scorecard ist ein bewährtes Mittel zur Zielfixierung. Auch auf Prozessebene lässt sich eine solche Scorecard entfalten (siehe Abschnitt 5.2) Als Perspektiven für Prozesse sind geeignet: 

Prozessfinanzen



Prozesskunden



Prozessorganisation



Prozesspotenziale

Nicht zu vergessen sind Prozessvision und –strategie, aus denen die strategischen Ziele ableitbar sein sollten. Dementsprechend sollen die strategischen Ziele zur Erreichung der Vision beitragen. Als Vision für den Infrastrukturerrichtungsprozess ist geeignet: Projekte zur Errichtung von IT-Infrastrukturen verlaufen strukturiert und koordiniert und sind effektiv, effizient und dokumentiert. Diese Vision ist natürlich nicht die einzig mögliche Variante. Es wäre auch möglich, die Vision mit Hilfe einer Reifegradterminologie (zum Beispiel CMMI) zu formulieren. Man könnte dann schreiben: „Die Reife des in der Organisation eingeführten Infrastrukturerrichtungsprozesses erreicht zumindest den Grad 3 (Defined).“ Für den CMMI-Kenner sind

86

8 Infrastrukturerrichtungsprozess: Die Definition

solche Visionen ohne Weiteres einschätzbar, für andere Leser aber zunächst wenig verständlich. Die Ziele eines internen ITI-Projekts unterscheiden sich von den Zielen eines Projekts, bei dem externe Leistungserbringer eingesetzt werden. Dementsprechend gibt es unterschiedliche Zielformulierungen. Die Ziele sind so formuliert, dass sie auch für Leser ohne beachtliche Kenntnisse der Betriebswirtschaft verständlich sind. Es handelt sich um Vorschläge, die von der anwendenden Organisation angepasst und ergänzt werden können und sollten. Auf die Spezifikation von Zielwerten wird auf dieser allgemeinen Ebene verzichtet, weil diese organisationsspezifisch festzulegen sind. Es fällt auf, dass IT-spezifische Prozessziele auf der strategischen Ebene kaum eine Rolle spielen. Prozessfinanzen 

Leitfrage: Welche finanziellen Ziele muss der Prozess erreichen, um zur Wertsteigerung des Unternehmens möglichst beizutragen?



Mögliche Zielobjekte: Geschäftswertbeitrag, Prozesskosten, Prozessumsatz, Prozesserlöse, Prozessproduktivität, Prozessrendite

Tabelle 18: Ziele zur Perspektive Prozessfinanzen (Beispiel) Projektvarianten PB1/PB2 Der Prozesskostensatz58 ist geringer als die Einnahmen aus dem Projekt.

Projektvarianten PS1/PS2 Der Prozesskostensatz ist geringer als die interne Verrechnungsgutschrift59.

Prozesskunden 

Leitfrage: Welche strategischen Ziele sind hinsichtlich der Befriedigung der Wünsche unserer Prozesskunden zu setzen, um die finanziellen Ziele zu erreichen?



Mögliche Zielobjekte: Kundenzufriedenheit, Kundenbindung, Reklamationen, Fehler, Liefertreue

Tabelle 19: Ziele zur Perspektive Prozesskunden (Beispiel) Projektvarianten PB1/PB2 Der Leistungsabnehmer ist mit dem Leistungserbringer so zufrieden, dass er beim nächsten ITIProjekt keine Absichten hegt, den Leistungserbinger zu wechseln.

Projektvarianten PS1/PS2 Der Leistungsabnehmer ist mit dem Leistungserbringer zufrieden.

Prozessorganisation 

58

Leitfrage: Wie müssen die Prozesse und Strukturen gestaltet sein, um die Prozessziele zu erreichen und die Wandlungsfähigkeit der Organisation zu fördern?

Der Prozesskostensatz gibt die Kosten pro Prozessdurchlauf an. Ein Vorgehen zur Ermittlung der Prozesskosten findet man zum Beispiel in Gadatsch, Masterkurs IT-Controlling, Vieweg 2005. 59 Hierfür ist Voraussetzung, dass die IT-Organisation als Profitcenter geführt wird.

8.3 Operative Ziele 

87

Mögliche Zielobjekte: Prozesszeiten (Durchlaufzeit), Prozessqualität, Prozesstermintreue, Prozesskostentreue

Tabelle 20: Ziele zur Perspektive Prozessorganisation (Beispiel) Projektvarianten PB1/PB2 Die Prozessdurchlaufzeit ermöglicht Termintreue gegenüber dem Kunden.

Projektvarianten PS1/PS2 Die Prozessdurchlaufzeit ermöglicht Termintreue gegenüber dem internen Kunden.

Prozesspotenziale 

Leitfrage: Wie müssen die Potenziale und Ressourcen des Prozesses ausgerichtet sein, um unsere Ziele zu erreichen?



Zielobjekte: Mitarbeiterzufriedenheit, Personalqualifikation, Mitarbeitertraining, Job Rotation, IT-Struktur, Prozessorganisation, Prozessreifegrad

Tabelle 21: Ziele zur Perspektive Prozesspotenziale (Beispiel) Projektvarianten PB1/PB2 Alle operativen Mitarbeiter sind für ITIStandardprojekte hinreichend qualifiziert; einige Mitarbeiter sind für komplexe Projekte speziell ausgebildet.

8.3

Projektvarianten PS1/PS2 Die operativen Mitarbeiter der IT-Organisation sind für ITI-Standardprojekte hinreichend qualifiziert.

Operative Ziele

Zur Festlegung der operativen Ziele ist es zunächst erforderlich, die Leistungsparameter des Infrastrukturerrichtungsprozesses festzulegen. Die Standard-Leistungsparameter sind: 

Kundenzufriedenheit



Prozesszeit



Termintreue



Prozessqualität



Prozesskosten.

Qualität ist gemäß der Norm DIN EN ISO 9000:2005 der Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt. Wie wir wissen, haben in erster Linie Kunden Anforderungen an den Prozess, darüber hinaus aber auch andere Stakeholder, insbesondere Shareholder, die Unternehmensleitung und der Staat. Beim ISE-Prozess mischt sich der Staat üblicherweise nicht mit Anforderungen ein. Es kann aber spezielle Projekte geben, wo Gesetzeskonformität doch eine Rolle spielt. Ein Beispiel ist die De-Mail-Infrastruktur, bei der die DeMail-Provider einem im Jahr 2011 verabschiedeten deutschen Gesetz unterliegen. Shareholder haben üblicherweise Anforderungen bezüglich der Prozesskosten, der Prozessrendite und der Prozesszeiten. Bei der Festlegung der operativen Ziele darf nicht aus dem Blickfeld geraten, dass auch diese Ziele letztlich zur Erreichung der Vision beitragen sollten.

88

8 Infrastrukturerrichtungsprozess: Die Definition

Was sind typische Anforderungen bezüglich der Prozessmerkmale? Zuerst können eine kurze Prozessdurchlaufzeit und geringe Prozesskosten genannt werden. Es sind Anforderungen, die üblicherweise vom Management und den Eigentümern der Organisation gestellt werden. Ein ISE-Prozessdurchlauf ist identisch mit der Durchführung eines ITI-Errichtungsprojekts. Die Projektdauer soll also so kurz wie möglich sein. Bei diesem Projekttyp ergeben sich hinsichtlich der Prozesszeit einige untergeordnete Ziele: 1. Die Soll-Aufnahme wird sorgfältig durchgeführt, so dass die Anzahl der notwendigen Nachbesserungen bis zur Abnahme gering ist. 2. Eine Machbarkeitsanalyse wird durchgeführt, so dass Projektrisiken frühzeitig erkannt und behandelt werden können. 3. Das logische und das physische Konzept sind ordentlich dokumentiert, so dass die Anzahl der Realisierungsfehler gering sind. 4. Die Service-Levels sind fixiert und an alle Beteiligten kommuniziert, so dass es bei der Abnahme diesbezüglich zu keinen Problemen kommt. 5. Der Beschaffungsprozess für die IT-Komponenten ist ausgereift, so dass es nicht aufgrund von unpünktlichen Lieferungen oder Beschaffungsversäumnissen zu Projektverzögerungen kommt. 6. Tests werden effektiv und effizient durchgeführt, so dass die Anzahl der Mängel bei der Abnahme gering ist und gleichzeitig nicht mehr Tests als nötig durchgeführt werden. 7. Das Rollout ist professionell strukturiert und die diesbezügliche Planung ist hinreichend dokumentiert, so dass es hier nicht zu Projektverzögerungen kommt. Weiterhin sollen die ITI-Errichtungsprojekte so kostengünstig wie möglich sein. Es besteht ein enger Zusammenhang zwischen Projektzeit und Projektkosten. Hier ist allerdings nicht nur auf die Durchlaufzeit, sondern auch auf die Zykluszeit zu achten, da sich der Personalzeitaufwand in erster Linie aus der Zykluszeit ergibt. Die Projektkosten sind in vielen Fällen hauptsächlich Personalkosten. Bezüglich der Prozesskosten lassen sich unter anderem folgende untergeordnete Ziele identifizieren: 8. Die einzelnen Teilprozesse werden regelmäßig einem Controlling unterzogen. 9. Geeignete Fachkräfte planen und realisieren die ITI. Sie sollten weder überqualifiziert noch unterqualifiziert sein. 10. Das Projektteam ist nicht von Quantität, sondern von Qualität geprägt. Die Personalausstattung ist aber ausreichend für die termintreue Abwicklung des Projekts. 11. Der Umfang des Projektmanagements ist auf den Umfang und die Komplexität des Projekts abgestimmt. 12. Fehlbestellungen werden vermieden. Die Qualität des Prozessoutputs Eine zentrale Anforderung, die der Kunde normalerweise hat, ist die Qualität des Prozessoutputs60, also des Produkts, in unserem Fall der fertiggestellten IT-Infrastruktur. Insofern

60

In der Norm ISO 9000:2005 ist „Produkt“ als „Ergebnis eines Prozesses“ definiert.

8.4 Weitere wesentliche Prozessattribute

89

lässt sich die Prozessqualität von der Produktqualität nicht trennen. Da das Produkt das Ergebnis des Prozesses ist, ist die Steigerung der Prozessqualität ein zentraler Aspekt bei der Steigerung der Produktqualität. Die Prinzipien des Qualitätsmanagements sind aber so allgemein gehalten, dass produktspezifische Zuspitzungen unerlässlich sind. Qualitätsmanagement alleine garantiert noch kein gutes Produkt. Produktbezogene Ziele sollten zusätzlich Berücksichtigung finden. Gemäß Abschnitt 7.1 sollte man für den Prozessoutput aus Anwendersicht vor allem folgende Ziele verfolgen: 1. Die ITI sollte eine hohe Verfügbarkeit aufweisen. 2. Die ITI sollte die aktuellen Sicherheitsanforderungen erfüllen. 3. Die ITI-Komponenten sollten zuverlässig funktionieren. 4. Die ITI sollte eine hohe Leistungsfähigkeit aufweisen. Ergänzend lassen sich aus den Erwartungen der ITI-Experten folgende Ziele ableiten: 5. Die ITI sollte leicht erweiterbar sein. 6. Die ITI sollte interoperabel sein. 7. Um die Qualität des Prozessoutputs zu erhöhen, sollten rechtzeitig und hinreichend oft Komponenten- und Integrationstests der ITI durchgeführt werden.

8.4

Weitere wesentliche Prozessattribute

Um einen Prozess angemessen zu beschreiben, müssen neben den Zielen diverse weitere Prozessattribute festgelegt werden. Sachmittel für ITI-Projekte Sachmittel sind Gegenstände, die den Prozessnutzer bei der Bearbeitung des Prozessobjekts unterstützen. In diesem Abschnitt werden ITI-spezifische Sachmittel vorgestellt. Klassische Sachmittel 

Räume – Wareneingang – Lagerraum – Technikraum – Testlabor – Installationsräume – Serverraum



Arbeitsmittel – Arbeitstische im Lagerraum – Arbeitstische im Testlabor – Schränke im Testlabor zur Verwahrung von DV-Mitteln – Bildschirme im Testlabor – Ethernet-Switch im Testlabor – diverse Schraubendreher – Kabelbinder – Datenkabel

90

8 Infrastrukturerrichtungsprozess: Die Definition – – – – –

Stecker für Datenkabel Werkzeug für Datenkabel Antistatische Matte mit Erdungskabel und -stecker Gerät zum Messen und Testen von IT-Netzwerken Beschriftungsgeräte



Ordnungsmittel – Prozesskonzept – Prozessbeschreibung – Prozessdiagramme – Anleitungen zur Systeminstallation und -konfiguration – Anleitungen zur Systemdokumentation Datenverarbeitungsmittel  Arbeitsplatzcomputer für Planer  Arbeitsplatzcomputer für Installateure  Kollaborationssoftware (zum Beispiel IBM Lotus Notes)  Bürosoftware (zum Beispiel Microsoft Office)  Netzwerkmanagementsoftware Kommunikationsmittel     

WWW Intranet E-Mail Telefon Faxgerät

Durchführungsorte für ITI-Projekte Um einen Prozess überwachen und steuern zu können, muss klar sein, an welchen Orten Prozessschritte durchgeführt werden. Diese Information muss Bestandteil der Prozessbeschreibung (siehe Abschnitt 5.3) sein. Bei internen Projekten werden die Durchführungsorte in der Regel je nach Bedarf an verschiedenen Standorten der Organisation gewählt. Es sollte eine Projektzentrale geben. Bei beauftragten Projekten wird das ITI-Projekt an den mit dem Kunden vereinbarten Standorten durchgeführt. Es sollte eine Projektzentrale und ein Testlabor geben Projekthäufigkeit Es sollte eingeschätzt werden, wie viele Projekte pro Jahr intern bzw. beim Kunden realisiert werden, da die Projektzahl Auswirkungen auf den Ressourcenbedarf und die Prozessrentabilität hat. Die Anzahl kann je nach Größe und Ausrichtung der Organisation ganz unterschiedlich sein.

8.4 Weitere wesentliche Prozessattribute

91

Tabelle 22: Anzahl der IT-Infrastrukturprojekte pro Jahr (Regelfall) Projekttyp Unternehmensgröße Klein Mittel Groß

ITI-Provider

ITI-Nutzer 1-10 1-20 1-50

1-5 1-10 1-20

Die Anzahl der jährlichen Installationen muss nicht proportional zur Größe des Unternehmens steigen. Häufig steigt mit der Unternehmensgröße nämlich auch die Größe der zu installierenden Infrastruktur.

Projektdauer

Projektdauer Die Projektdauer beschreibt den benötigten für das Projekt benötigten Zeitraum (z.B. vom 15.2. bis zum 18.6.). Es ist oft möglich die Projektdauer zu verkürzen, indem mehr Mitarbeiter im Projekt eingesetzt werden.

Anzahl der Projektmitarbeiter Abbildung 38: Zusammenhang zwischen Projektdauer und Mitarbeiterzahl

Diese Beziehung ist aber nicht proportional. Der Effekt der Erhöhung der Mitarbeiterzahl bezüglich der Projektdauer wird immer geringer, je mehr Mitarbeiter man in dem Projekt einsetzt. Andere Parameter, die die Projektdauer von ITI-Projekten beeinflussen, sind die Anzahl der angeschlossenen Frontends (Endgeräte) und die Zahl der zugehörigen Standorte. Die Dauer entwickelt sich mit zunehmender Anzahl von Endgeräten und Standorten jeweils logarithmisch.

92

8 Infrastrukturerrichtungsprozess: Die Definition

Tabelle 23: Maximale Zeitdauer von ITI-Projekten in Tagen (Regelfall) Anzahl Frontends Anzahl Standorte 1 2-10 11-40

1-100

101-1000 60 100 150

1001-10000 100 150 250

180 250 360

Projektaufwand Der Projektaufwand ergibt sich hauptsächlich aus dem Zeitaufwand der Projektteammitglieder, der für das Projekt erforderlich war. Drei Mitarbeiter, die jeweils 20 Tage lang mit einem Projekt beschäftigt waren, hatten den gleichen Aufwand wie sechs Mitarbeiter, die jeweils 10 Tage im Projekt tätig waren. Im zweiten Fall ist es allerdings möglich, dass der für das Projekt erforderliche Zeitraum (Projektdauer) kürzer war, da die Aufgaben eventuell parallelisiert werden können. Der Zeitaufwand dagegen ist relativ konstant, da sich weder die Anzahl noch der Umfang der Aufgaben nennenswert mit der Anzahl der Mitarbeiter ändern. Der Umfang der Projektleitungsaufgabe könnte steigen, dagegen wird in der Regel das verteilte Know-How der Beteiligten einen mindernden Effekt auf den Zeitaufwand haben. Auch der Projektaufwand entwickelt sich mit zunehmender Anzahl von Endgeräten und Standorten jeweils logarithmisch. Tabelle 24: Durchschnittlicher Zeitaufwand von ITI-Projekten in Personaltagen (Regelfall) Anzahl Frontends Anzahl LAN 1 2-10 11-40

1-100

101-1000 12 20 40

1001-10000 25 50 90

100 200 300

9

PAPRO-Prozess: Die Struktur Deckt sich das Interesse des Kapitals nicht mehr mit den Interessen der Nation, das heißt der Menschen, so möge es einer anderen Struktur Platz machen. Antoine de Saint-Exupéry

Jeder definierte Prozess hat eine Aufbaustruktur. Das Aufbauprinzip ist in Abbildung 32 (Prozessaufbaustruktur) beschrieben. Ihr kann man entnehmen, dass ein Prozesse in Teilprozesse, ein Teilprozess in Prozessschritte und ein Prozessschritt in Arbeitsschritte zerfallen. Die Arbeitsschritte zu den Prozessschritten werden aus fachlicher Sicht betrachtet, um eine zuverlässige Basis für die Entscheidungen über den Ablauf der Arbeitsschritte und deren Abhängigkeiten zu schaffen. Hierbei wurden insbesondere die Arbeiten von T.C. Piliouras [PIL2005] und P. Oppenheimer [OPP2010] verwendet. Die Struktur des Prozesses zur Errichtung von IT-Infrastrukturen basiert im Wesentlichen auf dem der Literatur entnehmbaren State of the Art. Weiterhin fließen Erkenntnisse aus Interviews mit Infrastrukturexperten aus der IT-Branche ein, die umfangreiche Erfahrung mit der Durchführung von ITI-Projekten besitzen. Die Prozessaufbaustruktur enthält noch keine Informationen über die zeitliche Reihenfolge von Tätigkeiten. Die Ablaufstruktur des zu entwickelnden Infrastrukturerrichtungsprozesses wird in Kapitel 10 behandelt. Ein wesentliches Element der Herleitung der ISEP-Struktur ist die Destillation von Strukturelementen aus den vorgestellten Vorgehensmodellen und Rahmenwerken nach den Kriterien der Bewährtheit, Verbreitung und Passgenauigkeit. Als Grundidee für den Phasenablauf eines IT-Infrastrukturprojekts ist „Plan – Build – Run“ (Planen – Realisieren – Betreiben) unstrittig. Es ist also möglich, eine phasenorientierte Grundstruktur für ITI-Projekte festzulegen. Die Phase Analyse sollte separat betrachtet werden, da sie immer eigenständig der Planung vorausgehen sollte, um das Projekt effektiver zu machen. Die Grundlage für die Strukturierung des ISE-Prozesses ist die in Abbildung 39 dargestellte Basisstruktur.

94

9 PAPRO-Prozess: Die Struktur

Für die Prozessstruktur wurde PAPRO als Name gewählt. Die Buchstaben repräsentieren die fünf Teilprozesse (PM, AN, PL, RE und OP) des Infrastrukturerrichtungsprozesses ISEP61. PAPRO steht also für die in diesem Werk gewählte Modellierung des Infrastrukturerrichtungsprozesses.

ISEP

TP PM Projektmanagement

TP OP

TP AN

TP PL

TP RE

Analyse

Planung

Realisierung

Betriebsaufnahme

Abbildung 39: PAPRO-Struktur des ISE-Prozesses

PL Planung

Errichter

AN Analyse

RE Realisierung

OP Betriebsaufnahme

Betreiber Manager

Organisation

Planer

In Abbildung 40 findet man vorgreifend den summarischen Ablauf des ISE-Prozesses als BPMN-Diagramm. Es handelt sich im Wesentlichen um eine sequentielle Struktur der Teilprojekte. Das Projektmanagement ist ein unverzichtbarer, unterstützender Teilprozess, der das ITI-Projekt bis zum Ende begleitet.

PM Projektmanagement

Abbildung 40: BPMN-Ablaufdiagramm zum ISE-Prozess (ohne Details)

61

Die Abkürzung ergibt sich aus den englischsprachigen Begriffen. OP steht für Operations.

9.1 Zusammenstellung der verschiedenen Modelle und Ansätze

95

Die Kombination und Bewertung der in den vorgegangenen Kapiteln bereits dargestellten Ansätze und Modelle ermöglicht es, eine sachgemäße Strukturierung der Teilprozesse vorzunehmen.

9.1

Zusammenstellung der verschiedenen Modelle und Ansätze

9.1.1

Zyklische Modelle

Im Gegensatz zu den Lebenszyklusmodellen sind die zyklischen Modelle in sich geschlossen. Im aktuellen Microsoft Solutions Framework (siehe Abbildung 28: Überblick zum MSF v4 Governancemodell) wird nicht von Phasen, sondern von Spuren gesprochen, da dort die Möglichkeit der Überlappung der Spuren berücksichtigt wird. Ansonsten handelt es sich ebenfalls um eine Darstellung, das sich auf IT-Systeme anwenden lässt, die folgende Reihenfolge beinhaltet: Envision  Plan  Build  Stabilize  Deploy. Für den Fall, dass es sich bei dem System um ein IT-Netzwerk handelt, liefert uns das PDIOO-Modell von Cisco (siehe Abbildung 29: Lebenzyklusmodell für IT-Netzwerke) einen weiteren Lebenszyklus mit folgender Phasensequenz: Plan  Design  Implement  Operate  Optimize. Die vom BSI „Aussonderung“ genannte Phase ist hier als Retirement berücksichtigt. Die Aussonderung (Retirement) steht nicht im Zentrum unserer Betrachtungen. Das Spiralmodell für Softwareentwicklungsprozesse (siehe Kapitel 3) liefert ebenfalls eine zyklische Darstellung. Die wiederkehrenden Aktivitäten heißen: 1. Festlegung der Ziele, Randbedingungen und Alternativen 2. Bewertung der Alternativen (Risikoanalyse) 3. Fertigstellung und Abnahme 4. Planung des nächsten Zyklus Der Schwerpunkt unserer Betrachtungen liegt nicht auf Betrieb, Optimierung oder Entsorgung, sondern auf Analyse, Planung und Realisierung. Die Realisierungsphase wird in der Regel mit der erstmaligen Inbetriebsetzung abgeschlossen. Eine erfolgreiche Inbetriebnahme ist für die Abnahme des ITI-Projekts in der Regel unabdingbar. Insofern ist der Betrieb der Infrastruktur auch für Errichtungsprojekte nicht ganz vernachlässigbar. Ein weiteres Argument für die – zumindest selektive – Einbeziehung der Betriebsphase ist, dass der Errichter die Infrastruktur geordnet an den Betrieb übergeben sollte. Eine Gegenüberstellung der verschiedenen Modelle kann behilflich sein, Unterschiede und Gemeinsamkeiten besser zu erkennen und Ideen für die Struktur der Teilprozesse zu erhalten. In den folgenden Tabellen wird dargestellt, welchen Beitrag die betrachteten Modelle bzw. Rahmenwerke für die PAPRO-Phasen liefern.

96

9 PAPRO-Prozess: Die Struktur

Tabelle 25: Relevante Beiträge der zyklischen Modelle zu den PAPRO-Phasen Cisco PDIOO

Analyse

Microsoft MSF Envision

Planung

Plan

Realisierung

Build Stabilize Deploy (Microsoft Operations Framework)

Plan Design Implement

Betrieb

9.1.2

Operate Optimize

Spiralmodell Festlegung der Ziele, Randbedingungen und Alternativen Bewertung der Alternativen (Risikoanalyse) Fertigstellung und Abnahme Fertigstellung und Abnahme

Planung des nächsten Zyklus

Sequentielle Modelle

Die in Kapitel 3 vorgestellten Lebenszyklusmodelle haben einen sequentiellen Charakter. Betrachtet man den gesamten Lebenszyklus einer IT-Infrastruktur, so sollte man auch die Außerbetriebnahme nicht außer Acht lassen. Für die Praxis zusätzlich relevant ist der Ansatz vom Bundesamt für Sicherheit in der Informationstechnik (BSI) in Zusammenhang mit der Gewährleistung der IT-Sicherheit.

Planung und Konzeption

Aussonderung

Beschaffung

Notfallvorsorge

Betrieb

Umsetzung

Abbildung 41: BSI-Lebenszyklus eines IT-Systems, Quelle: [BSI2008, S. 15]

Der Lebenslauf eines IT-Systems endet gemäß BSI also mit der Aussonderung. Der Lebenszyklus für Softwareentwicklung (SDLC) hat einen vergleichbaren Aufbau: Initation  Machbarkeitsstudie  Anforderungsanalyse  Systemdesign  Systementwicklung  Deployment  Wartung  Aussonderung Wie der Name schon sagt, beschränkt sich die Systemanalyse hauptsächlich auf die Analyse-Phase. Die sequentielle Struktur ist in Abbildung 19 (Ablauf der Systemanalyse) dokumentiert.

9.1 Zusammenstellung der verschiedenen Modelle und Ansätze

97

Das Wasserfallmodell für die Softwareentwicklung (siehe Abbildung 11: Wasserfallmodell der Softwareentwicklung) kennt sechs Phasen: Anforderungen Analyse  Entwurf  Implementierung  Test  Betrieb Im V-Modell für die Softwareentwicklung sind folgende Phasen festgelegt: Anforderungsdefinition  Grobentwurf  Feinentwurf  Programmierung  Modultest  Integrationstest  Systemtest  Abnahmetest  Betrieb Und bei der Methodik Structured Systems Analysis and Design (SSADM) spricht man von folgenden Stufen: Machbarkeitsprüfung  Analyse der derzeitigen Umgebung  Geschäftliche Optionen  Erfassung der Anforderungen  Technische Optionen  Logisches Design  Physisches Design In der Tabelle 26 sind die Phasen bzw. Stufen der erwähnten Modelle den PAPRO-Phasen zugeordnet. Tabelle 26: Relevante Beiträge der sequentiellen Modelle zu den PAPRO-Phasen BSI Lebenszyklus Analyse -

SDLC Lebenszyklus Initiation; Machbarkeitsstudie; Anforderungsanalyse

Systemanalyse

Wasserfallmodell

SSADM

V-Modell

Erfassung des Ist-Zustands; Darstellung des IstZustands; Analyse des Ist-Zustands; Dokumentation des IstZustands;

Anforderungen; Analyse

Machbarkeitsprüfung; Analyse der derzeitigen Umgebung; Geschäftliche Optionen; Erfassung der Anforderungen; Technische Optionen

Anforderungsdefinition

Entwickeln des Konzepts; Dokumentation des Konzepts

Entwurf

Logisches Design; Physisches Design

Grobentwurf; Feinentwurf

Planung

Planung und Konzeption

Systemdesign

Realisierung

Beschaffung Umsetzung

Systementwicklung; Deployment

Betrieb

Betrieb Aussonderung

Wartung; Aussonderung

-

Implementierung; Test

-

-

Betrieb

-

Programmierung; Modultest; Integrationstest; Systemtest; Abnahmetest Betrieb

98

9 PAPRO-Prozess: Die Struktur

9.1.3

Management-Rahmenwerke

ITIL v2 Das Infrastrukturmanagement (ICTIM) gemäß ITIL v2 hat die in Abbildung 42 dargestellte Grobstruktur. Diese vier Prozesse beinhalten etliche Aktivitäten, die bereits in Abschnitt 3.5 beschrieben wurden.

Design and Planning

Deployment

Operations

Technical Support Abbildung 42: Grobstruktur von ICTIM

Auch die Teilprozesse von ICTIM lassen sich den PAPRO-Phasen Analyse, Planung, Realisierung und Betrieb zuordnen. Zur Analysephase trägt ICTIM nichts bei. Tabelle 27: Relevante Beiträge von ITIL/ICTIM zu den PAPRO-Phasen Entwurf und Planung Analyse Planung

Koordination; Strategieentwicklung; ICTPlanungsschnittelle; Richtlinienentwicklung

Realisierung -

Umsetzung und Auslieferung

-

Implementierung; Rollout

Betrieb -

-

Betrieb

Technische Unterstützung Prüfung -

-

Überwachung; Kontrolle

-

Beschaffung; Testumgebungen; Budgetsteuerung; Dokumentation Dokumentation; Prüfung; Berichterstattung

CObIT 4.1 CObIT liefert etliche Ansatzpunkte für die Planung und Realisierung von IT-Infrastrukturen. Nachfolgend sind die passenden Prozessaktivitäten den Phasen Analyse, Planung, Realisierung und Betrieb zugeordnet. Im Bereich Betrieb sind die Prozessaktivitäten, die sich mit längerfristigen Betriebsaktivitäten befassen, nur teilweise berücksichtigt, da es nicht der Fokus unserer Betrachtung ist.

9.1 Zusammenstellung der verschiedenen Modelle und Ansätze Tabelle 28: Relevante Beiträge der CObIT-Prozesse zu den PAPRO-Phasen

PO8 Manage Quality

Analyse PO8.4 Customer Focus

PO9 Assess and Manage IT Risks

PO9.4 Risk Assessment

AI1 Identify Automated Solutions

AI1.1 Requirements AI1.2 Risk Report AI1.3 Feasibility Study AI1.4 Approval

AI3 Acquire and Maintain Technology Infrastructure

-

AI4 Enable Operation and Use

-

AI5 Procure IT Resources

-

AI6 Manage Changes

-

AI7 Install Solutions and Changes

-

DS1 Define and Manage Service Levels

-

DS5 Ensure Systems Security

62

-

Planung

99

62

Realisierung

Betrieb PO8.6 Quality Measurement

-

-

-

-

-

-

-

-

AI3.1 Infrastructure Acquisition Plan AI3.3 Infrastructure Maintenance

AI3.2 Infrastructure Resource Protection AI3.4 Feasibility Test Environment

AI5.1 Procurement Control AI5.2 Supplier Management

-

AI7.2 Test Plan AI7.3 Implementation Plan AI7.5 Conversion DS1.3 Service Level Agreements DS1.4 Operating Level Agreements DS5.7 Security Technology DS5.10 Network Security DS5.11 Exchange of Sensitive Data

Die Namen der Prozessaktivitäten sind teilweise gekürzt.

AI4.4 Knowledge Transfer to Staff AI5.1 Procurement Control AI5.3 Supplier Selection AI5.4 IT Resources -

AI7.4 Test Environment AI7.7 Final Test

-

DS5.5 Security Testing DS5.7 Security Technology DS5.10 Network Security

AI3.2 Infrastructure Resource Protection AI3.3 Infrastructure Maintenance -

-

AI6.1 Change Procedures AI6.2 Impact Assessment AI6.3 Emergency Changes AI6.4 Change Status Reporting AI6.5 Change Closure AI7.8 Promotion to Production AI7.9 Postimplementation Review DS1.5 Monitoring of Service Level Achievements DS5.5 Security Testing

100

9 PAPRO-Prozess: Die Struktur Analyse

Planung

DS9 Manage the Configuration

-

-

DS10 Manage Problems

-

-

DS11 Manage Data

-

DS12 Manage the Physical Environment

ME3 Compliance

-

ME3.1 Compliance Requirements

Realisierung DS5.11 Exchange of Sensitive Data DS9.1 Configuration Repository -

DS11.2 Storage Arrangements DS11.6 Security Requirements

DS11.1 Requirements Data Management DS11.2 Storage Arrangements DS11.3 Media Management System

DS12.1 Site Selection and Layout DS12.2 Physical Security Measures DS12.4 Protection Against Environmental Factors

DS12.1 Site Selection and Layout DS12.2 Physical Security Measures DS12.4 Protection Against Environmental Factors

ME3.1 Compliance Requirements

Betrieb

DS9.1 Configuration Repository DS10.1 Classification of Problems

-

-

-

-

Legende: PO = Plan/Organise; AI = Acquire/Implement; DS = Deliver/Support; ME = Monitor/Evaluate

9.1.4

Weitere Ansätze

Netzdesign nach Fischbach und Simon Bereits 1975 haben sich Fischbach und Simon in [FBS1975] mit dem Design von Kommunikationsleitungsnetzen befasst. Einige ihrer Ansätze und Ideen [FBS1975, S.171ff.] sind bis heute relevant.

9.1 Zusammenstellung der verschiedenen Modelle und Ansätze

101

Tabelle 29: Relevante Beiträge von Fischbach/Simon zu den PAPRO-Phasen Checkliste

Analyse

Problem analysieren; Anforderungen bewerten

Planung

Konzept entwerfen (SollZustand); Mengengerüst festlegen; Auslegung der EDV-Anlage festlegen; Leitungskosten ermitteln

Kriterien zur Leitungsauswahl

Eckpunkte der Planung

-

-

Übertragungssicherheit; Datenvolumen/Zeit; Antwortzeit; Übertragungskosten;

Projektorganisation mit Lenkungsausschuss gründen; Aufgabenstellungen eindeutig festlegen; Hardware einschließlich Speichermedien, Terminals, Leitungscontrollern und Konzentratoren planen; Räume planen

Realisierung

-

-

-

Betrieb

-

-

-

Eckpunkte der Realisierung

Vorsorgemaßnahmen

-

-

Analyse der Ausfallrisikos „Leitung“; Analyse des Ausfallrisikos „Datenübertragungseinrichtung“

Mit Lieferanten verhandeln; Hardware und Software auswählen und bestellen; Tests schrittweise durchführen; Räume bereitstellen; System dokumentieren; Beteiligte ausbilden; Installation: erst Hardware, dann Test und Abnahme, danach Software -

Planung von Informationssystemen nach Eberle Eberle bezeichnet seinen Ansatz als „integriertes, lebenszyklusorientiertes Denkkonzept“63. Vor dem Hintergrund des informationstechnologischen Strukturwandels war seine Vorgehensweise einer langfristigen Perspektive verpflichtet.

63

[EBE1984, S. 17]

102

9 PAPRO-Prozess: Die Struktur

Tabelle 30: Relevante Beiträge von Eberle zu den PAPRO-Phasen

Analyse Planung

Realisierung Betrieb

9.2

Planungs- und Entscheidungsprozess Kritische Situationsanalyse (Lückenbestimmung); Suche nach Gestaltungsalternativen (Konsequenzenanalyse); Auswahl von Gestaltungsalternativen (systemspezifische Nutzungskonzeption, Systemadäquate Nutzungskonzeption);

Planrealisierung und Kontrolle -

Lösungsspezifische Konsequenzenanalyse

Maßnahmen der Optimierung und Kontrolle

-

-

Teilprozesse

Es ist ein wichtiges Ziel zu klären, wie die Struktur der identifizierten Teilprozesse Analyse, Planung, Realisierung und Betrieb aussieht. Denn nur wenn diese Strukturen detaillierter aufgeschlüsselt werden, werden die Ausführungen für den Praktiker nützlich. Ein wesentliches Element zur Identifizierung der Teilstrukturen ist die Auswertung der vorgestellten Vorgehensmodelle zum PAPRO-Modell. Für die einzelnen Teilprozesse werden jeweils nach der Ermittlung der relevanten Elemente aus den Vorgehensmodellen die geeigneten Prozessschritte identifiziert und dargestellt Da die einzelnen Phasen des BSI-Lebenszyklus vom BSI nicht näher erläutert werden, wird dieser Ansatz für die Prozessstrukturierung abgesehen von den verwendeten Begrifflichkeiten (siehe Tabelle 26) mangels Details nicht weiter verwendet.

9.2.1

TP AN Analyse

Zusammenstellung der relevanten Bestandteile der bestehenden Vorgehensmodelle Der BSI-Lebenszyklus liefert keinen Beitrag. Microsoft MSF hat einen Envision Track definiert. Seine wesentlichen Bestandteile sind:  Definition der Projektziele  Definition des Projektumfangs  Definition der Projekterwartungen  Identifikation der Projektrisiken  Zusammenstellung des Projektteams  Zuweisung von Rollen und Verantwortlichkeiten Cisco PDIOO liefert keinen Beitrag. SDLC betont folgende Elemente:  Initiation: geordneter Startprozess  Feasibilty: Machbarkeitsanalyse  Requirement Analysis: Anforderungsanalyse Das Spiralmodell steuert folgende Elemente bei: 

Festlegung der Ziele

9.2 Teilprozesse

103

 Festlegung der Randbedingungen  Festlegung der Alternativen  Bewertung der Alternativen (Risikoanalyse) Die Systemanalyse kennt folgende Elemente:  Erfassung des Ist-Zustands  Darstellung des Ist-Zustands  Analyse des Ist-Zustands  Dokumentation des Ist-Zustands Die Phasen Anforderungen und Analyse des Wasserfallmodells haben folgende Elemente:   

Ermittlung der funktionalen Anforderungen Ermittlung der technischen Anforderungen Analyse der identifizierten Anforderungen

SSADM akzentuiert folgende Tätigkeiten 

Feasibility: – technische Realisierbarkeit – finanzielle Realisierbarkeit – organisatorische Realisierbarkeit – ethische Realisierbarkeit  Investigation of current environment: – Ist-Analyse – Anforderungsanalyse  Business systems options – Identifizierung der möglichen Systemoptionen aus geschäftlicher Sicht – Auswahl einer geschäftlichen Systemoption  Definition of requirements – Identifizierung der angeforderten Prozesseigenschaften – Ableitung der Systemfunktionen – Entwicklung von Spezifikationsprototypen für Systemteile – Dokumentation der Anforderungsspezifikation  Technical system options – Identifizierung der möglichen Systemoptionen aus technischer Sicht – Auswahl einer technischen Systemoption Beim V-Modell verbirgt sich hinter der Anforderungsdefinition vor allem Folgendes:  

Aufnehmen der Anforderungen und Wünsche des Leistungsnehmers Spezifizieren der Anforderungen und Wünsche des Leistungsnehmers

Der Teilprozess Technische Unterstützung von ITIL ICTIM liefert zur Analysephase: 

Machbarkeitsprüfung von Infrastrukturkonzepten

CObIT hat folgende relevante Prozessaktivitäten:      

PO8.4 Customer Focus PO9.4 Risk Assessment AI1.1 Definition and Maintenance of Business Functional and Technical Requirements AI1.2 Risk Analysis Report AI1.3 Feasibility Study and Formulation of Alternative Courses of Action AI1.4 Requirements and Feasibility Decision and Approval

104

9 PAPRO-Prozess: Die Struktur



ME3.1 Identification of External Legal, Regulatory and Contractual Compliance Requirements Eberle (Tabelle 30) weist auf die Bedeutung der kritischen Situationsanalyse (Lückenbestimmung) hin. Das Clustering der aufgeführten Aspekte führt zur Strukturierung des Teilprozesses Analyse (siehe Abbildung 43). TP AN Analyse

PS AN1

PS AN2

PS AN3

Ist-Analyse

Soll-Aufnahme

Alternativenbewertung

Abbildung 43: Grobstruktur zum ISE-Teilprozess Analyse

Prozessschritt AN1 Ist-Analyse Bei den Randbedingungen zu ITI-Projekten ist besonders auf die geschäftlichen und technologischen Vorgaben und Einschränkungen zu achten. Um den geschäftlichen Rahmenbedingungen auf die Spur zu kommen, ist in erster Linie aufmerksames Zuhören vonnöten. Oft sind die Vertreter der betroffenen Organisation nicht ohne Weiteres bereit diese Informationen zur Verfügung zu stellen. Die geschäftlichen Eckdaten haben meist sensibleren Charakter als die technischen. Das gilt auch für behördliche Rahmenbedingungen. In beiden Fällen ist der Vertraulichkeitsbedarf der Organisation entscheidend. Bei Bedarf sollte deshalb frühzeitig eine Vertraulichkeitszusicherung angeboten und unterzeichnet werden. Für eine passgerechte Lösung kann es sehr wichtig sein, die geschäftlichen Randbedingungen zu kennen, da es ansonsten dazu kommen könnte, dass das Design der Lösung nicht zur Akzeptanz beim Leistungsabnehmer führt. Auch bei organisationsinternen Projekten sollte es auf jeden Fall zu einem konstruktiven Dialog zwischen Fachebene und IT-Abteilung kommen. Zu den relevanten geschäftlichen Rahmenbedingungen gehören:            

Organisationsphilosophie / -kultur Branche / Kerngeschäft Organisationsstruktur Richtlinien IT-Strategie Projektbudget: Höhe und festlegende Person Gesetzliche oder vertragliche Vorgaben Strukturelle Änderungen Änderungsfreudigkeit Interesse am Projekterfolg bei den betroffenen Organisationseinheiten Berufe der Gesprächspartner Wissen und Erfahrung des technischen Personals

9.2 Teilprozesse

105

 Organisationsinterne oder organisationsübergreifend anerkannte Standards Weiterhin sind auch infrastrukturspezifische Informationen wichtige Inputs für den Prozessschritt Ist-Analyse. Zu folgenden Aspekten sollten Informationen beschafft werden, die sich sowohl auf den derzeitigen als auch auf den geplanten Zustand beziehen:        

Anzahl und Verteilung der beteiligten Gebäude und Standorte Anwendungen mit ITI-Nutzung Datenflusswege Datenverkehrsvolumen Datenverkehrstypen Anzahl und Typ der Netze Datentransportkosten Organisationsinterne oder organisationsübergreifend anerkannte Standards

Besondere Aufmerksamkeit sollte der Aufnahme der derzeitigen Netzwerkinfrastruktur gewidmet werden. Der Checkliste lassen sich die wesentlichen Fragen entnehmen, die beim Prozessschritt AN1 Ist-Analyse beantwortet werden sollten. Checkliste 4A – Ist-Analyse Geschäftliche Aspekte (Auftraggeber) O Zu welcher Branche gehört ihr Unternehmen? O Was ist das Kerngeschäft des Unternehmens? O Durch welche Adjektive lässt sich ihre Organisation treffend charakterisieren? O Wie ist die Organisation strukturiert? O Welche rechtlichen Vorgaben und Richtlinien prägen ihre Organisation? O Wie lässt sich die IT-Strategie beschreiben? O Wie hoch ist das Budget für das Projekt? Wer verwaltet es? O Welche gesetzlichen und vertraglichen Vorgaben sind projektrelevant? O Gibt es derzeit strukturelle Änderungen? Wie ist die Stimmung? O Sind die Interessen hinsichtlich des Projekterfolgs bei den betroffenen Organisationseinheiten unterschiedlich? Inwiefern? O Wie heterogen sind Wissen und Erfahrung des technischen Personals? O Welche geschäftlichen Standards bzw. Vorgaben sind zwingend zu beachten? O Welche Dienstgütevereinbarungen (SLA) bestehen derzeit für die ITI?

Checkliste 4B – Ist-Analyse Technische und organisatorische Aspekte (Auftraggeber) O Welche Standorte und Gebäude sind beteiligt/ betroffen? O Wie viele Nutzer benutzen die ITI? Wie sind sie auf die Standorte verteilt? O Welche Anwendungen nutzen die IT-Infrastruktur? O Was sind die zugehörigen Datenverkehrstypen? O Existieren Netzwerkstrukturdiagramme? Wie sehen die aus? O Was für Netzwerktypen gibt es (LAN, WLAN, VLAN, RAS, VPN, WAN etc.)?

106 O O O O O O O O O O O O O O O O O O O O O O O

9 PAPRO-Prozess: Die Struktur Was sind die hauptsächlichen Datenflusswege? Wo sind die wichtigsten Datenverkehrsquellen? Welche IT-Systeme haben viele Daten zu speichern? Wie hoch ist das Datenverkehrsvolumen in den Netzwerksegmenten im Durchschnitt? Welche Netzwerkprotokolle werden verwendet (CSMA/CD, IPv6, DNS etc.)? Welche Verfahren werden für die Benennung und Adressierung der Computer benutzt? Wie ist die IT-Infrastruktur logisch strukturiert bzw. separiert? Welche Netzwerkschnittstellen zu anderen Organisationen gibt es? Welche Sicherheitsmaßnahmen sind für das Netzwerk umgesetzt? Was sind die physischen und logischen Tolopogien? Was für Netzwerkkomponenten sind im Einsatz (Switches, Router etc.)? Wie/womit ist die Datenübertragung realisiert (Twisted-Pair, LWL, Laser etc.)? Wie viele Anschlussdosen gibt es? Wo befinden sich Patchfelder? Ist die Datenübertragungszuverlässigkeit durch externe Einflüsse (Störstrahlung, Hochwasser, Baustellen, unsachgemäße Verlegung etc.) gefährdet? Welche Dienste werden von den ITI-Komponenten realisiert? Welche Dienste sind voneinander abhängig? Wie viele Frontends sind an die IT-Infrastruktur angeschlossen? Gibt es Thinclients? Welches Betriebssystem ist auf den Frontends installiert? Werden virtuelle Desktops eingesetzt? Wie/womit wird die IT-Infrastruktur verwaltet? Toolunterstützung? Welche Probleme gibt es (Verfügbarkeit, Sicherheit, Performance etc.)? Wie hoch sind die Datentransportkosten? Welche technischen Standards sind von besonderer Bedeutung? Welche Schwachstellen hat die derzeitige IT-Infrastruktur?

Eine Unterscheidung zwischen PB- und PS-Projekten (siehe Tabelle 14) ist hier weder notwendig noch zweckmäßig. Der ITI-Provider hat diese Fragen zu stellen, also muss der ITI-Nutzer imstande sein diese Fragen zu beantworten. Alternativ kann ein ITI-Nutzer den ITI-Provider bitten bei der Ist-Aufnahme behilflich zu sein, falls er sich außer Stande sieht, alle Fragen sachgemäß zu beantworten. Man könnte bei den Checklisten 4A und 4B zwischen den Projekten differenzieren, die in erster Linie auf das Netzwerk bzw. auf die Frontends ausgerichtet sind. Allerdings sollte ein Leiter eines Projekts für Endgeräterollouts auch Wissen über die Netzwerkumgebung haben, in die die Geräte zu integrieren sind, und Leiter von Netzwerkprojekten müssen in der Regel auch Informationen über die anzuschließenden Endgeräte haben. Aus diesem Grund wurde die Checkliste nicht aufgeteilt. Insgesamt ergeben sich für den Prozessschritt Ist-Analyse folgende Arbeitsschritte:

9.2 Teilprozesse

107

Arbeitsschritte zum Prozessschritt AN1 Ist-Analyse AN1.1 Aufnahme der geschäftlichen und strategischen Rahmenbedingungen AN1.2 Aufnahme des infrastrukturspezifischen Ist-Zustands AN1.3 Identifizierung der angewendeten Standards und Vorgaben AN1.4 Identifizierung der Anforderungen an das Netzwerk (Ist) AN1.5 Situationsbewertung Bei der Situationsbewertung ist insbesondere darauf zu achten, dass die ermittelten Schwachstellen dokumentiert werden. Es sollte zum Ausdruck gebracht werden, an welchen Stellen die Anforderungen an die vorhandene IT-Infrastruktur nicht erfüllt werden, um daraus für die zukünftige ITI lernen zu können. Tabelle 31: Im Rahmen von AN1 zu erstellende Dokumente Arbeitsschritt AN1.1

Dokumentenkürzel DAN1

AN1.2

DAN2

Dokument Dokumentation der geschäftlichen und strategischen Rahmenbedingungen Dokumentation des infrastrukturspezifischen Ist-Zustands

AN1.3 AN1.4 AN1.5

DAN3 DAN4 DAN5

Dokumentation der angewendeten Standards und Vorgaben Dokumentation der Anforderungen an das Netzwerk (Ist) Situationsbewertung nach Ist-Analyse

Prozessschritt AN2 Soll-Aufnahme Bei der Soll-Aufnahme spielt das Identifizieren und Fixieren der geschäftlichen und technischen Erwartungen und Ziele eine wichtige Rolle. Bei Projekten mit externem Leistungserbringer gilt das für beide Projektparteien. Einige typische Möglichkeiten für geschäftliche Ziele im Zusammenhang mit ITI-Projekten, sind:        

Steigerung der Effizienz von Geschäftsprozessen Beschleunigung des Informationsflusses Schneller und einfacher Zugang zu Informationen Bessere externe Erreichbarkeit Optimierung der Business-to-Business-Kooperation Vereinfachung der Business-to-Customer-Beziehung Sicherung der Vertraulichkeit beim Informationstransport Übereinstimmung mit gesetzlichen oder anderweitigen Vorgaben (Compliance)

Tabelle 17 - Veranlassungsmöglichkeiten für ein IT-Infrastrukturprojekt mit dem jeweils aufgeführten Zweck hilft in erster Linie beim Finden technischer Ziele. Hieraus abgeleitet sollten Erwähnung finden:      

Vernetzung der Gebäude und Standorte Zentrale Datenspeicherung Hohe Verfügbarkeit der IT-Infrastruktur Beschleunigung der Datentransfers Sicherer Datentransfer Sichere Datenspeicherung

108    

9 PAPRO-Prozess: Die Struktur Authentische Transaktionen Zentrale Benutzerverwaltung Zentrales Systemmanagement Reduzierung der Technologieheterogenität

Eine Umfrage des Autors bei IT-Experten und IT-Anwendern zeigte deutliche Tendenzen hinsichtlich der Erwartungen an die Eigenschaften von ITI. Den Befragten wurde die Frage Was erwarten Sie von einer hochwertigen IT-Infrastruktur? vorgelegt. Es gab zwölf vordefinierte Antwortmöglichkeiten, von denen die sechs wichtigsten auszuwählen waren, und die Möglichkeit für eine Freitextantwort. Tabelle 32: Mögliche Erwartungen an eine IT-Infrastruktur Nr. 1

Erwartung ausfallfreier Betrieb

Dahinter stehende Eigenschaft Verfügbarkeit

2 3 4 5 6 7

zuverlässige Speichergeräte einfacher Zugang resistent gegen Sicherheitsbedrohungen preisgünstig schneller Datentransfer schnelle Internetanbindung

Zuverlässigkeit Usability Sicherheit Wirtschaftlichkeit Performance Performance

8 9

vor Einführung sorgfältig getestet Reibungslose Interoperabilität der Infrastrukturkomponenten untereinander Bewährte Hersteller mit bewährtem Support moderne Technologien Erweiterbarkeit der Struktur ohne großen Zeit- und Geldaufwand

Testdurchführung Interoperabilität

10 11 12

Bewährtheit Modernität Skalierbarkeit

Interessanterweise wurden sowohl bei den Anwendern als auch bei den Experten die Eigenschaften Verfügbarkeit und Sicherheit gleich stark und am meisten genannt. Bei den Experten rangiert gleichauf die Skalierbarkeit, während bei den Anwendern die Zuverlässigkeit die meisten Nennungen nach Verfügbarkeit und Sicherheit erhalten hat. Usability und Performance hatten bei den Anwendern eine mittlere Relevanz. Bei den Experten hat die Mehrheit der Befragten außerdem Zuverlässigkeit, Performance, Testdurchführung und Interoperabilität genannt. Bei beiden Gruppen spielten Wirtschaftlichkeit, Bewährtheit und Modernität nur eine geringe Rolle. Die Wirtschaftlichkeit darf dennoch nicht außer Acht gelassen werden, da Projekte immer wirtschaftlich angelegt sein müssen, um nicht zu einem finanziellen Risiko für das ausführende Unternehmen zu werden. Die Relevanz der Befragungsergebnisse sollte bei den beiden befragten Gruppen nicht unterschiedlich eingestuft werden. Sowohl Anwender als auch Experten müssen gehört werden, und jede der beiden Sichtweisen ist für die Planung einer IT-Infrastruktur wichtig. Dementsprechend lässt sich feststellen, dass insgesamt die in Tabelle 32 aufgelisteten Erwartungen an die ITI besonders ausgeprägt sind.

9.2 Teilprozesse

109

Tabelle 33: Die wichtigsten Erwartungen an IT-Infrastrukturen Priorität 1 (besonders wichtig) Verfügbarkeit Sicherheit

Priorität 2 (wichtig) Skalierbarkeit Zuverlässigkeit

Priorität 3 (ziemlich wichtig) Usability Performance Testdurchführung Interoperabilität

Da es sich bei der Umfrage nicht um eine umfangreiche Studie gehandelt hat und außerdem in einer spezifischen Projektsituation bestimmte Eigenschaften besonderes Gewicht erhalten, sollten die Erwartungsprioritäten im konkreten Einzelfall verifiziert bzw. angepasst werden. Dazu kann Tabelle 33 – Die wichtigsten Erwartungen an eine IT-Infrastruktur verwendet werden. Es empfiehlt sich die Befragung in Form eines Interviews durchzuführen, um Missverständnissen vorzubeugen. Im Bereich der Sicherheit sollten präzisierende Fragen gestellt werden. Welche der folgenden Eigenschaften sind besonders wichtig?      

vertraulicher Datentransfer integrer Datentransfer authentische Transaktionen nicht abstreitbare Transaktionen64 vertrauliche Datenspeicherung integere Datenspeicherung

Checkliste 5 – Soll-Aufnahme O O O O O O O O O O O O O O O

64

Welche rechtlichen Vorgaben und Richtlinien prägen ihre Organisation zukünftig? Sind Änderungen an der IT-Strategie geplant? Wie sollen sich die Dienstgütevereinbarungen (SLA) für die geplante ITI von den bisherigen unterscheiden? Was ist das Ziel der strukturellen Änderungen in ihrer Organisation? Welche Standorte und Gebäude sind zukünftig beteiligt/ betroffen? Existieren zur Planung Netzwerkstrukturdiagramme? Wie sehen die aus? Was für Netzwerktypen gibt es zukünftig (LAN, WLAN, VPN, WAN etc.)? Welche Anwendungen nutzen die künftige IT-Infrastruktur? Von welchem Typ sind die Architekturen der Anwendungen? Was sind die zugehörigen Datenverkehrstypen (Nachrichten,Voice,Video etc.)? Was für Änderungen an den IT-Systemen sind geplant? Wo sind die wichtigsten Datenverkehrsquellen? Welche Netzwerkprotokolle sollen verwendet werden (IPv6, DNS etc.)? Welche Verfahren sollen für die Benennung und Adressierung der Computer benutzt werden? Gibt es Vorgaben zur Strukturierung bzw. Separierung des IT-Netzes?

Gemeint ist die nachträgliche Nichtabstreitbarkeit der Herkunft einer Nachricht oder die nachträgliche Nichtabstreitbarkeit des Erhalts einer gesendeten Nachricht

110 O O O O O O O O O O O O O O O O

9 PAPRO-Prozess: Die Struktur Welche Netzwerkschnittstellen zu anderen Organisationen sind geplant? Welche Sicherheitseigenschaften sind besonders wichtig? Welche Sicherheitsmaßnahmen sind für das Netzwerk umzusetzen? Gibt es Vorgaben hinsichtlich der physischen und logischen Tolopogien? Was für Netzwerkkomponenten sind zukünftig im Einsatz (Switches, Router etc.)? Wie/womit soll die Datenübertragung realisiert werden (Twisted-Pair, LWL, etc.)? Wie viele Anschlussdosen gibt es zukünftig? Wo sind Patchfelder geplant? Welche Dienste werden gemäß der derzeitigen Planung von den ITI-Komponenten realisiert? Wie viele Frontends sind an die IT-Infrastruktur anzuschließen? Wie viele ITI-Benutzer wird es geben? Wie sind sie auf die Standorte verteilt? Wie/womit wird die IT-Infrastruktur verwaltet? Toolunterstützung? Sollen die Benutzer der ITI dezentral oder zentral verwaltet werden? Wie hoch dürfen die Datentransportkosten sein? Welche Technologien sind unerwünscht? Welche technischen Standards sind von besonderer Bedeutung? Welche Infrastruktureigenschaften haben besondere Priorität (Verfügbarkeit, Sicherheit, Skalierbarkeit, Zuverlässigkeit, Usability, Performance, Testdurchführung)?

Die Fragen helfen dabei, die Arbeitsschritte zur Soll-Aufnahme sachgemäß durchzuführen. Arbeitsschritte zum Prozessschritt AN2 Soll-Aufnahme AN2.1 Ermittlung der geschäftlichen Erwartungen und Anforderungen – Prozessaspekte – finanzielle Aspekte – funktionale Aspekte – Priorisierung AN2.2 Ermittlung der technischen Erwartungen und Anforderungen – Client/Server-Struktur – IT-Netzwerk – Priorisierung Tabelle 34: Im Rahmen von AN2 zu erstellende Dokumente Arbeitsschritt AN2.1 AN2.2

Dokumentenkürzel DAN6 DAN7

Dokument Dokumentation der geschäftlichen Erwartungen und Anforderungen Dokumentation der technischen Erwartungen und Anforderungen

Prozessschritt AN3 Alternativenbewertung Bei der Alternativenbewertung geht es darum, die beste Lösungsvariante für das ITI-Projekt zu identifizieren. Zu diesem Zweck wird eine Machbarkeitsanalyse durchgeführt. Zur verbliebenen Lösungsvariante wird anschließend ein Pflichtenheft erstellt.

9.2 Teilprozesse

111

Machbarkeitsanalyse Bocij et. al. betonen die Wichtigkeit einer Machbarkeitsanalyse.65 Es geht darum einzuschätzen, ob ein geplantes System realisierbar ist. Wichtige Aspekte sind 1. die organisatorische Realisierbarkeit, 2. die technische Realisierbarkeit, 3. die finanzielle Realisierbarkeit und 4. die ethische Realisierbarkeit. 1. Organisatorische Realisierbarkeit In diesem Zusammenhang spricht man auch von betrieblicher Realisierbarkeit. Es ist zu klären, ob die geplante IT-Infrastruktur die geschäftlichen Erwartungen und die Erwartungen an die Leistungsfähigkeit der Struktur weitgehend erfüllen kann. Darüber hinaus wird eingeschätzt, ob die IT-Infrastruktur die betrieblichen Prozesse angemessen unterstützt (Business Alignment). Hier sind auch die Anforderungen der Benutzer zu berücksichtigen. 2. Technische Realisierbarkeit Es wird geprüft, ob für die geplante IT-Infrastruktur die notwendigen Technologien zur Verfügung stehen, um diese realisieren zu können. 3. Finanzielle Realisierbarkeit In diesem Zusammenhang wird auch von ökonomischer Realisierbarkeit gesprochen. Es wird eingeschätzt, ob die Investitionskosten tragbar sind und wie hoch der Return on Invest (ROI) sein wird. 4. Ethische Realisierbarkeit Bei der Einführung eines neuen Systems sollte erwogen werden, ob die Realisierung ethisch vertretbar ist. Leicht zu erklären ist das am Beispiel des Kernkraftwerks. Rechtfertigt der Nutzen der Anlage die Inkaufnahme des Risikos der Umweltzerstörung und der Gefährdung der Gesundheit beziehungsweise des Lebens vieler Menschen? In den meisten Fällen sind die möglichen Auswirkungen der Einführung oder Erweiterung einer IT-Infrastruktur nicht so drastisch. Allerdings sollte beispielsweise die Frage der Notwendigkeit der ITIEinführung angesichts des dadurch wachsenden Energiebedarfs gestellt werden. Im Rahmen von Green IT66 gibt es mittlerweise etliche Möglichkeiten energieeffiziente ITInfrastrukturen zu betreiben. CObIT 4.1 stellt bei der Machbarkeitsstudie die Realisierbarkeit der geschäftlichen Anforderungen in den Vordergrund (AI1.3 Feasibility Study and Formulation of Alternative Courses of Action). Es geht also in erster Linie um die betriebliche und ökonomische Realisierbarkeit. Der Input der Machbarkeitsprüfung ist die Idee für die Einführung eines neuen Informationssystems. Der Output ist der Machbarkeitsbericht samt Empfehlung zum Voranschreiten. CObIT 4.1 empfiehlt, dass der Machbarkeitsbericht vom zuständigen Business-Manager in Abstimmung mit dem zuständigen IT-Manager verfasst wird. Der Bericht sollte vom Management der Organisation abgenommen werden. In Deutschland gibt es das Berufsbild des

65 66

[BGH2008, S.288] Bemühungen, die Nutzung von Informationssystemen vom Design der Systeme und der Produktion der Komponenten über deren Verwendung bis zur Entsorgung umweltschonend zu gestalten.

112

9 PAPRO-Prozess: Die Struktur

Wirtschaftsinformatikers. Dieser ist imstande, die Aktivitäten des Teilprozesses TP AN Analyse, also auch die Machbarkeitsanalyse, verantwortlich durchzuführen. Es muss klargestellt werden, dass die Machbarkeitsanalyse nicht mit einer endgültigen und unumstößlichen Feststellung endet, die davon ausgeht, alle Aspekte vollständig behandelt zu haben. Die Frage nach der Machbarkeit sollte auch die Beteiligten in der Planungsphase noch begleiten, denn bei der Ausarbeitung des Designs können sich – insbesondere in technischer Hinsicht – neue Anhaltspunkte ergeben, die die Realisierbarkeit in Frage stellen. Der Status Quo als Lösungsalternative spielt eine Sonderrolle. In den seltensten Fällen kann der Status Quo die Erwartungen des Auftraggebers erfüllen. Es kann aber sein, dass die Alternativen die Erwartungen in noch geringerem Maße erfüllen . Deshalb ist es zielführend, auch den Status Quo als Vergleichsalternative mitzuführen. Häufig wird bei der Machbarkeitsanalyse eine risikoorientiertes Vorgehensweise gewählt. Ein wesentliches Element ist die Analyse möglicher Gefährdungen. Gibt es Umstände, die sich aus der Ist-Analyse oder der Soll-Aufnahme ergeben haben, die die effektive und effiziente Projektdurchführung gefährden? In erster Linie ist der Projektleiter für die gefährdungsorientierte Projektüberwachung zuständig. Es kann aber Aspekte geben, die vom Verantwortlichen des Teilprozesses AN zu beurteilen sind. Beispiel einer Alternativenbewertung In der Mathematik und den Naturwissenschaften ist es meistens so, dass es zu einer Aufgabe nur eine richtige Lösung gibt. Aber selbst dort gibt es in vielen Fällen unterschiedliche Lösungswege, um die Aufgabe zu erfüllen. Wenn man eine IT-Infrastruktur systematisch plant, so sind Zweck und Ziel des Projekts frühzeitig klar und bekannt, die Aufgabe ist also definiert. Der Schluss, dass es nur eine passende Lösung zu dieser Aufgabenstellung gibt, ist aber meistens falsch. Wenn beispielsweise die Aufgabe lautet, den Frontends der Niederlassung Leipzig der Dienst+Leist GmbH eine performante und zuverlässige Verbindung mit der Kundendatenbank der Zentrale in Hannover zu ermöglichen, so gibt es unter anderem diese Lösungswege: 1. Kopplung mittels Webserver mit DSL-Anschluss an einen Internet-Service-Provider 2. Kopplung per VPN mit DSL-Anschluss an einen Internet-Service-Provider 3. Kopplung per MPLS-Netz mit DSL-Anschluss an einen WAN-Provider 4. Serielle Datenübertragung gemäß ITU-T-Standard V.11(Standleitung) Alle Varianten können hinreichende Performance (von bidirektional 2 Mbit/s) gewährleisten und gelten gemeinhin als zuverlässig. Um zu einer begründeten Entscheidung hinsichtlich einer Lösungsalternative kommen zu können, bedarf es genauerer Untersuchungen, inwieweit die geschäftlichen Erwartungen und technischen Anforderungen von der jeweiligen Lösungsoption erfüllt werden. Es ist also für jede Variante eine Machbarkeitsanalyse durchzuführen. Dafür ist es sehr wichtig, die Anforderungen so präzise wie möglich zu kennen.

9.2 Teilprozesse

113

In unserem Beispiel präzisiert der Kunde seine technischen Anforderungen:  

Datentransferrate bidirektional mindestens 4Mbit/s „Zuverlässig“ bedeutet: – Verfügbarkeit der Verbindung mindestens 99,9%, keine Einschränkung der Betriebszeiten – Sicherstellung der Vertraulichkeit Mit den heutigen Technologien ist es bei allen vier erwähnten Varianten möglich, Anforderungen an die Datenübertragungsrate zu erfüllen. Die hohen Anforderungen an die Verfügbarkeit lassen sich bei den ersten beiden Varianten nicht zuverlässig erfüllen, da der InternetService-Provider nicht die Verfügbarkeit der verbindenden Internetknoten garantieren kann. Die Vertraulichkeitsanforderung kann normalerweise von den verbleibenden Varianten 3 und 4 erfüllt werden, da die Daten in einem vom jeweiligen Provider kontrollierten Netz übertragen werden. Als weiteres Entscheidungskriterium sollte nun die Wirtschaftlichkeit der Lösungsvarianten betrachtet werden. In diesem Fall sind hauptsächlich die Betriebskosten relevant. Der Preisvergleich ergab, dass bei Variante 4 von ca. 800,-EUR/Monat auszugehen ist, wohingegen die monatlichen Kosten bei Variante 3 nur ca. 500,-EUR/Monat betragen. Somit bleibt als Realisierungskandidat die Variante „Kopplung per MPLS-Netz mit DSLAnschluss an einen WAN-Provider“ übrig. Da die vom Provider in der Leistungsbeschreibung zugesicherte Verfügbarkeit in beiden Fällen aber nur bei 99,2% liegt, ist mit dem Leistungsabnehmer abzustimmen, ob dieser Wert Akzeptanz findet oder nicht. Es geht umgerechnet immerhin um den Unterschied zwischen 10 und 80 Minuten Ausfallzeit pro Woche. Wird die Verfügbarkeit von 99,2% akzeptiert, so wird Variante 3 als Lösung ausgewählt. Pflichtenheft Bei der Erstellung von Individualsoftware ist es für professionelle Lösungsanbieter selbstverständlich ein Pflichtenheft zu erstellen. Dieses wird üblicherweise auf Basis eines Lastenhefts und in Abstimmung mit dem Kunden entwickelt. Im Pflichtenheft beschreibt der Auftragnehmer, wie er die Anforderungen des Auftraggebers zu erfüllen gedenkt. Für professionelle ITI-Provider sollte es ebenso selbstverständlich sein, ein solches Heft zu erstellen, denn auch hier können sonst im Verlauf des Projekts große Differenzen zwischen den ausgesprochenen und unausgesprochenen Erwartungen des Kunden und den Vorstellungen des Auftragnehmers entstehen, die zu Missstimmung beim Auftraggeber oder möglicherweise unbezahlten Zusatzaufwendungen beim Auftragnehmer führen können. Auch bei Pflichtenheften für ITI-Projekte sollten sowohl funktionale als auch technische Anforderungen behandelt werden. Auch Anforderungen an den Datenschutz und die Informationssicherheit sollten spezifiziert sein. Es sollte außerdem reflektiert werden, ob mit der Errichtung der IT-Infrastruktur spezielle Programmieraufgaben verbunden sind.

114

9 PAPRO-Prozess: Die Struktur

Arbeitsschritte zum Prozessschritt AN3 Alternativenbewertung AN3.1 Darstellung der Alternativen AN3.2 Machbarkeitsanalyse – organisatorische Realisierbarkeit – technische Realisierbarkeit – finanzielle Realisierbarkeit – ethische Realisierbarkeit – Machbarkeitsentscheidung/-bestätigung AN3.3 Auswahl einer Variante AN3.4 Erstellung des Pflichtenhefts Tabelle 35: Im Rahmen von AN3 zu erstellende Dokumente Arbeitsschritt AN3.1 AN3.2

Dokumentenkürzel DAN8 DAN9 DAN10

Dokument Dokumentation der Alternativen Machbarkeitsanalyse Machbarkeitsentscheidung

AN3.3 AN3.4

DAN11 DAN12

Dokumentation zur Auswahl der ITI-Variante Pflichtenheft

Inputs und Outputs In Tabelle 36 ist dargestellt, welche Objekte in den Teilprozess einzugeben sind und welche Objekte nach einem Prozessdurchlauf erzeugt worden sein sollten. Tabelle 36: Ein- und Ausgaben der Prozessschritte zum Teilprozess AN Analyse Prozessschritt AN1

AN2 AN3

Inputs Projektrisiken; Geschäftliche Rahmenbedingungen; Vorhandene Standards und Vorgaben; Zustand der ITI; Systemumgebung Situationsbewertung nach Ist-Analyse

Outputs Dokumente DAN1 – DAN5 (siehe Tabelle 31)

Geschäftliche Erwartungen und Anforderungen; Technische Erwartungen und Anforderungen

Dokumente DAN8 – DAN12 (siehe Tabelle 35)

Dokumente DAN6 – DAN7 (siehe Tabelle 34)

9.2 Teilprozesse

115

Tabelle 37: Ein- und Ausgaben zum Teilprozess AN Analyse Inputs Projektrisiken geschäftliche Rahmenbedingungen Vorhandene Standards und Vorgaben Zustand der ITI Systemumgebung

9.2.2

Outputs Im Rahmen von AN1 zu erstellende Dokumente (siehe Tabelle 31) Im Rahmen von AN2 zu erstellende Dokumente (siehe Tabelle 34) Im Rahmen von AN3 zu erstellende Dokumente (siehe Tabelle 35)

TP PL Planung

Zusammenstellung der relevanten Bestandteile der bestehenden Vorgehensmodelle Der BSI-Lebenszyklus liefert die Schlagworte Planung und Konzeption. Microsoft MSF hat einen Plan Track definiert. Seine wesentlichen Bestandteile sind:    

Dokumentierung der Anforderungen Entwicklung eines Lösungskonzepts – Logisches Design – Physisches Design Erstellung eines Projektplans Einrichtung der Implementierungsumgebung

Wesentliche Elemente der Plan-Phase von Cisco PDIOO sind:  Identifizierung der Anforderungen an das Netzwerk  Festlegung der Installationsorte  Identifizierung der Nutzerprofile (Netzwerkdienste, Bandbreite, …) Die Design-Phase von Cisco PDIOO ist durch nachfolgende Bestandteile gekennzeichnet: 



logisches Design – Netzwerktopologie – Adressierung und Nummerierung – Netzwerkprotokolle – Sicherheitsstrategie – Netzwerkmanagementstrategie physisches Design

– Technologieauswahl – Auswahl von Geräten und Übertragungsmedien SDLC trägt folgendes Element bei:  Systems Design: Erstellung einer Spezifikation zur Erfüllung der Systemanforderungen Das Spiralmodell liefert folgenden Beitrag.  Erstellung des Grobentwurfs (Produktdesign)  Validierung des Entwurfs  Erstellung des Feinentwurfs Bei der Systemanalyse besteht der Teilprozess Soll-Konzept aus den Prozessschritten  

Entwickeln des Konzepts und Dokumentation des Konzepts

116

9 PAPRO-Prozess: Die Struktur

Die Phase Entwurf des Wasserfallmodells ist durch folgende Bestandteile geprägt:  Schnittstellendesign  Softwaredesign  Testplan SSADM liefert folgende Schlagwörter:  

Logical Design Physical design

Das V-Modell kennt folgende Elemente: Grobentwurf (funktionaler Systementwurf)67: Abbildung der Anforderungen auf Funktionen des neuen Systems  Feinentwurf (technischer Systementwurf)68: Entwurf für die technische Realisierung des Systems Der Teilprozess Entwurf und Planung von ITIL ICTIM trägt zur Planung Folgendes bei: 



Entwicklung von Strategien, Prozessen und Richtlinien für die Implementierung der ITInfrastruktur  Entwicklung von Strategien, Prozessen und Richtlinien für den Rollout der ITInfrastruktur Der Teilprozess Technische Unterstützung von ITIL ICTIM trägt zur Planung Folgendes bei: 

Planung und Steuerung des Budgets

CObIT trägt zur Planung folgende Elemente bei:                  

67 68

PO8.4 Customer Focus AI3.1 Technological Infrastructure Acquisition Plan AI3.3 Infrastructure Maintenance AI5.1 Procurement Control AI5.2 Supplier Contract Management AI7.2 Test Plan AI7.3 Implementation Plan AI7.5 System and Data Conversion DS1.3 Service Level Agreements DS1.4 Operating Level Agreements DS5.7 Security Technology DS5.10 Network Security DS5.11 Exchange of Sensitive Data DS11.2 Storage and Retention Arrangements DS11.6 Security Requirements DS12.1 Site Selection and Layout DS12.2 Physical Security Measures DS12.4 Protection Against Environmental Factors

auch Fachkonzept genannt auch DV-Konzept genannt

9.2 Teilprozesse

117



ME3.1 Identification of External Legal, Regulatory and Contractual Compliance Requirements Fischbach/Simon (Tabelle 29) tragen folgende Aspekte bei:     

Konzept entwerfen (Soll-Zustand) Hardware (Speichermedien, Terminals, Konzentratoren etc.) planen Mengengerüst für die Hardware festlegen Auslegung der EDV-Systeme festlegen Einflussfaktoren für das physische Design – Datenvolumen/Zeit – Antwortzeit – Übertragungssicherheit – Leitungskosten / Übertragungskosten  Räume planen  Analyse der Ausfallrisiken Eberle (Tabelle 30) setzt folgende Akzente: 

Suche nach Gestaltungsalternativen



Auswahl von Gestaltungsalternativen

Das Clustering der aufgeführten Aspekte führt zur Strukturierung des Teilprozesses Planung (siehe Abbildung 44). TP PL Planung PS PL1 Logisches Design

PS PL2 Physisches Design

PS PL3 Sicherheit

PS PL4

PS PL5

Realisierungsvorbereitung

Betriebsvorbereitung

Abbildung 44: Grobstruktur zum ISE-Teilprozess Planung

Bei der logischen Konzeptionierung ist es unerlässlich sich bewusst zu machen, dass die zugehörigen Ideen nicht im leeren Raum entstehen, sondern dass dem Teilprozess Planung der Teilprozess Analyse zeitlich vorangeht. Einige Inputs und Outputs dieser Phase sind wichtige Inputs für das Design der Infrastruktur, insbesondere das Lastenheft und das Pflichtenheft (DAN12) sowie die Dokumentation der geschäftlichen und technischen Erwartungen und Anforderungen (DAN6, DAN7). Prozessschritt PL1 Logisches Design Das physische Konzept für eine IT-Infrastruktur ist unzweifelhaft notwendig und wichtig. Aber das logische Konzept folgt nicht aus dem physischen, sondern das physische Konzept aus dem logischen. Die Begründung ist recht einfach. Wenn die Ideen das Sein bestimmen, dann gibt es einen grundsätzlich unbeschränkten Freiraum für die Erzeugung von Lösungen für Aufgaben. Wenn das Sein die Ideen bestimmt, dann werden die daraus entstehenden

118

9 PAPRO-Prozess: Die Struktur

Lösungen den Aufgaben häufig nicht ausreichend gerecht werden. Das gilt nicht nur für die großen Zusammenhänge des Lebens, sondern auch für die konkrete Ebene der ITI-Planung. Bei der logischen Planung von IT-Infrastrukturen sollten folgende Planungskategorien Berücksichtigung finden: Datenübertragungsverfahren / logische Topologien, Netzwerkdienste /-protokolle, Betriebssystemdienste, Netzsegmentierung, Identifizierung von Computern (Adressen, Namen), Netzwerksicherheit, Netzwerkmanagement und die Physik der Datenübertragung (drahtgebunden, drahtlos). Beim letzten Punkt geht es nicht um die Auswahl eines materiellen Mediums, beispielsweise Twisted-Pair-Kupferkabel Cat. 6 (4paarig, geschirmt), sondern um grundsätzliche Entscheidungen, die sich aus den Anforderungen ergeben. Variante 1: Projekte vom Typ PB1/PS1 Gehen wir davon aus, dass der Projektschwerpunkt auf dem IT-Netzwerk liegt, korrespondieren mit den Planungskategorien die folgenden sechs Arbeitsschritte: Arbeitsschritte zum Prozessschritt PL1 Logisches Design – Variante Netzwerk PL1.1N Auswahl geeigneter Datenübertragungsverfahren (WAN,MAN,LAN,SAN,WLAN) – logische Topologien – Datenübertragungstechnologien (drahtgebunden, drahtlos) – Medienzugriffsverfahren PL1.2N Erarbeitung einer geeigneten Netzsegmentierung – Switching / Repeating – Subnetze – Routing PL1.3N Auswahl geeigneter Netzwerkdienste /-protokolle – Netzwerkschicht – Transportschicht – Anwendungsschicht(en) PL1.4N Erarbeitung eines Konzepts zur Benennung und Adressierung von Computern – Adressenauflösung zwischen OSI-Schicht 2 und OSI-Schicht 3 – Namensauflösung (DNS, NetBIOS, etc.) PL1.5N Ausarbeitung einer Netzwerkmanagementstrategie – Architektur – Protokolle – Überwachung PL1.6N Abnahme69 – intern – Kunde Die Ausarbeitung des Netzwerksicherheitskonzepts findet in einem separaten Prozessschritt (PL3) statt. Ergebnisse aus den Schritten PL1 und PL2 fließen dort ein.

69

Eine Differenzierung nach selbst realisierten und beauftragten ITI-Projekten ist nicht erforderlich, da es auch bei internen Projekten einen Projektleiter (interne Abnahme) und einen Abnehmer (Kunden) gibt.

9.2 Teilprozesse

119

Variante 2: Projekte vom Typ PB2/PS2 Gehen wir davon aus, dass der Projektschwerpunkt auf dem Client/Server-Computing liegt, korrespondieren mit den Planungskategorien die folgenden fünf Arbeitsschritte: Arbeitsschritte zum Prozessschritt PL1 Logisches Design – Variante Client/Server PL1.1S Auswahl geeigneter Systemdienste ( DHCP, LDAP, SMTP, HTTP,…) PL1.2S Auswahl geeigneter Netzwerkdienste /-protokolle – Netzwerkschicht – Transportschicht – Anwendungsschicht(en) PL1.3S Konzipierung von Zugangs- und Zugriffsberechtigungen PL1.4S Ausarbeitung einer Systemmanagementstrategie – Architektur – Protokolle – Überwachung PL1.5S Abnahme – intern – Kunde Tabelle 38: Im Rahmen von PL1 zu erstellende Dokumente Arbeitsschritt PL1.1N/S PL1.2N/S PL1.3N/S PL1.4N/S PL1.5N

Dokumentenkürzel DPL1

Dokument Konzept für das logische Design der ITI

PL1.6N/ PL1.5S

DPL2 DPL3

Mängelliste Abnahmebestätigung logisches Design

Prozessschritt PL2 Physisches Design Wenn geklärt ist, wie die logische Topologie aussehen und wie das Netzwerk segmentiert werden soll, welche Netzwerkdienste zum Einsatz kommen sollen bzw. müssen, wie die Computer adressiert und benannt werden sollen, welcher Namensauflösungsmechanismus verwendet werden, wie das Netzwerkmanagement realisiert werden sollte und wie viele Nutzer und Systeme die zukünftige ITI umfasst, kann man sich dem physischen Design des Netzwerks widmen. In diesem Zusammenhang sind etliche Fragen zu beantworten. Checkliste 6 – Physisches Design O Wie soll die Verkabelung strukturiert werden? O Welche Kabel sollen zum Einsatz kommen? O Wie soll das Datenübertragungsverfahren realisiert werden? O Welche Datenübertragungsgeschwindigkeit soll realisiert werden? O Welche Geräte sollen als WAN-Gateway zum Einsatz kommen? O Welche Geräte sollen im LAN zum Einsatz kommen? O Welche Geräte sollen im WLAN zum Einsatz kommen? O Wo /wie oft sind die Netzwerkanschlussdosen zu installieren?

120 O O O O O O

9 PAPRO-Prozess: Die Struktur Wo sollen die Patchfelder, Switches, Router und Server platziert werden? Werden Netzwerkverteilerräume /-schränke benötigt? Ist die Infrastruktur der Technikräume zum Betrieb der Technikräume geeignet (Energieversorgung, Klimatisierung, Einbruchsicherheit etc.)? Soll das Internet oder ein Provider-WAN genutzt werden? Welche Leitungen / Leitungstypen sind für den WAN-Anschluss zu realisieren? Sollen der Netzwerkverkehr und die Netzwerkkomponenten mittels eines ITSystems überwacht werden?

Aus den obigen Darstellungen und Fragen lassen sich Arbeitsschritte extrahieren: Arbeitsschritte zum Prozessschritt PL2 Physisches Design PL2.1 Vorschläge hinsichtlich der Frontendgerätetypen – Desktop-PC – Notebook – Thinclient – Smartphone / PDA PL2.2 Konzept für die Verkabelung – Struktur – Notwendige Bandbreiten – Kabeltypen – Patchfelder / Anschlussdosen / Steckverbindungen – Verteilerräume PL2.3 Vorschläge für den Anschluss an das Weitverkehrsnetz – Auswahl des WAN – Vorschläge für Leitungstypen und –bandbreiten PL2.4 Vorschläge für den Einsatz von aktiven Komponenten im LAN / SAN – Hubs / Switches – Router – Firewalls – Modems – WLAN Access Points – Überwachung – Redundanz PL2.5 Abnahme – intern – Kunde

9.2 Teilprozesse

121

Tabelle 39: Im Rahmen von PL2 zu erstellende Dokumente Arbeitsschritt PL2.1 PL2.2 PL2.3 PL2.4 PL2.5

Dokumentenkürzel DPL4

Dokument Konzept für das physische Design der ITI

DPL5 DPL6

Mängelliste Abnahmebestätigung physisches Design

Prozessschritt PL3 Sicherheit Sicherheitsanforderungen haben in den vergangenen Jahren stetig an Bedeutung gewonnen. Mit einer Firewall allein ist es längst nicht mehr getan. Es muss auch erwogen werden, welcher Datenverkehr zu verschlüsseln ist und wie die Netzwerkkomponenten vor Angriffen geschützt werden können. Grundwerte der IT-Sicherheit O Verfügbarkeit O Vertraulichkeit O Integrität. Für IT-Infrastrukturen ist weiterhin die Authentizität relevant. Diese Sicherheitseigenschaft wird allerdings häufig unter den Begriff der Integrität subsummiert. Zentraler Bestandteil des Sicherheitskonzepts ist die Risikoanalyse.70 Um diese durchführen zu können, muss Klarheit über die geplanten beziehungsweise im Einsatz befindlichen Infrastrukturelemente (Systeme, Räume, Gebäude) geschaffen werden. Man nennt diese Objekte auch Assets, weil sie für die Organisation von Wert sind. Das ganze Verfahren würde zu kurz greifen, wenn nicht auch die in der ITI zu verarbeitenden Informationen als Assets berücksichtigt werden würden. Im nächsten Schritt sind nun die möglichen Bedrohungen und die Schwachstellen der Assets zu ermitteln. Hier können die IT-Grundschutzkataloge des BSI und der Anhang der Norm ISO/IEC 27005 hilfreich sein. Anschließend sind die zugehörigen Risiken einzuschätzen, also die Eintrittswahrscheinlichkeit und Auswirkung eines Schadens bezüglich eines Assets. Diese Schätzungen sind die Grundlage für die Risikobehandlung. Die landläufigen Risikobehandlungsoptionen sind. Risikoreduzierung, Risikovermeidung, Risikotransfer und Risikoakzeptanz. In der Regel wird am häufigsten die Risikoreduzierung durch entsprechende Sicherheitsmaßnahmen gewählt. Es gibt technische und organisatorische Sicherheitsmaßnahmen. Eine wichtige Maßnahmenklasse ist die Sicherheitsrichtlinie. Es empfiehlt sich, für die IT-Infrastruktur eine oder mehrere zu entwerfen. Im Sicherheitskonzept ist auch festzuhalten, wie die Umsetzung der Sicherheitsmaßnahmen überwacht werden sollen. Wenn das Sicherheitskonzept keine konkreten technischen Sicherheitsmaßnahmen enthält, dann sind diese zusätzlich zu planen und zu dokumentieren. Es ist zu gewährleisten, dass folgende Aspekte bearbeitet werden:

70

Eine Alternative zur klassischen Risikoanalyse ist die Durchführung einer SWOT-Analyse.

122

9 PAPRO-Prozess: Die Struktur

Tabelle 40: Technische Sicherheitsaspekte und die zugehörigen hauptsächlichen Sicherheitsbedürfnisse Sicherheitsaspekt

Verfügbarkeit

Vertraulichkeit

Weitverkehrsverbindungen Remote Access

x x

x x

Integrität/ Authentizität x x

Router / Firewall Namensserver Verzeichnisdienst WLAN

x x x x

x

x x x x

In Tabelle 40 geht es darum, welche Schutzbedürfnisse bestimmte Netzwerkdienste und – funktionen (teilweise repräsentiert durch das IT-System) haben. Umgekehrt lässt sich auch betrachten, durch welche Dienste / Systeme die Schutzziele der IT-Sicherheit unterstützt werden. Systeme zur Gewährleistung der IT-Sicherheit sind in erster Linie Router und Firewall sowie Intrusion-Detection-Systeme. Auch ein RADIUS-Server gehört in diese Klasse, da er für Authentizität der Netzwerkbenutzer sorgt. Auch LAN-Switches besitzen häufig Sicherheitsfeatures (zum Beispiel VLAN, MAC Locking). Besonderes Augenmerk verdienen die ITI-Komponenten, die via Internet erreichbar sind. Insbesondere verdienen Router, Firewalls und VoIP-fähige Systeme eine sorgfältige Risikobehandlung, da ein Einbruch in diese Systeme erhebliche Auswirkungen auf die gesamte ITI haben können. Bei VoIP-Systemen kann der Missbrauch insbesondere zu erheblichen finanziellen Schäden führen. Nicht vergessen werden darf, dass Netzwerkkomponenten wie beispielsweise eine Firewall nicht nur durch technisches Hacking, sondern auch durch elementare Angriffstechniken durch physischen Zutritt gefährdet sind. Deshalb ist bei der Konzeptionierung der Sicherheit auch die Zutrittssicherheit von Gebäuden und Räumen mit zu berücksichtigen. Arbeitsschritte zum Prozessschritt PL3 Sicherheit PL3.1 Risikoanalyse – Assetidentifizierung (Informationen, Systeme, Gebäude, Räume) – Bedrohungsanalyse – Schwachstellenidentifizierung – Risikoeinschätzung / Schadensprognose PL3.2 Risikobehandlungsplanung PL3.3 Organisatorische Sicherheitsmaßnahmen – Richtlinien – Verfahrensanweisungen PL3.4 Technische Sicherheitsmaßnahmen – Berechtigungen für Zugang und Zugriff – Abwehr von Angriffen Die notwendige Planung der ITI-Überwachung ist durch die Prozessschritte PL1 und PL5 abgedeckt.

9.2 Teilprozesse

123

Tabelle 41: Im Rahmen von PL3 zu erstellende Dokumente Arbeitsschritt PL3.1 PL3.2 PL3.3 PL3.4

Dokumentenkürzel DPL7

Dokument Konzept für die Sicherheit der IT-Infrastruktur

Prozessschritt PL4 Realisierungsvorbereitung Dieser Schritt klingt nach Projektmanagement, ist aber nicht damit zu verwechseln. Da Projektmanagement verfasst Projektpläne und plant und überwacht Zeiten, Ressourcen und Budgets. Im Prozessschritt PL4 Realisierungsvorbereitung werden aber keine Projektpläne ausgearbeitet oder ergänzt. Viele „Hey-Joe“-Projekte leiden nicht nur an mangelhafter Projektführung, sondern auch an unzureichender inhaltlicher Vorbereitung auf die Projekttätigkeiten. Um die Realisierungsphase effektiv und effizient gestalten zu können, sind in angemessenem Umfang Richtlinien und Verfahrensanweisungen vonnöten. Es geht hier nicht um Steuerdokumente für den Betrieb der IT-Infrastruktur, sondern um solche, die die Projektrealisierung unterstützen und lenken. Als Beispiele kann man nennen:    

Richtlinie für die Implementierung von IT-Infrastrukturen71 Richtlinie für die Qualitätssicherung Verfahrensanweisung für die Durchführung von Tests Richtlinie für die Planung und Durchführung von Schulungen

Diese Dokumente sollten so gestaltet sein, dass ihre Abhängigkeit vom jeweiligen Projekt gering ist, sie also als Prozessdokumente wiederholt einsetzbar und projektspezifisch nur geringe Anpassungen erforderlich sind. Andererseits sind aber zusätzlich auch konkrete Pläne für das spezifische Projekt erforderlich (zum Beispiel Testplan). Außerdem muss die Beschaffung der benötigten ITI-Komponenten sachgerecht geplant werden, um Projektverzögerungen mangels Material zu vermeiden. Im Konzept zum physischen Design ist zwar bereits festgelegt worden, welche Kommunikationsmedien und Gerätetypen zu verwenden sind, eine Produktentscheidung ist aber genauso wenig getroffen worden wie eine Entscheidung über das Mengengerüst und die Leistungsdaten der Systeme. Die dafür notwendige Kapazitätsprognose basiert auf den im Teilprozess Analyse ermittelten Ist- und Sollinformationen. Für die Produkt- und Lieferantenauswahl ist es eine wichtige flankierende Maßnahme einen entsprechenden Standard festzulegen beziehungsweise anzuwenden. Hierbei sollte die in Aussicht gestellte Lieferzeit als Kriterium nicht fehlen. Insbesondere bei großen ITI-Projekten kann es vorkommen, dass die bislang zur Verfügung stehende Lagerfläche für den Flächenbedarf der anzuliefernden Systeme nicht ausreicht. Dieser logistischen Herausforderung muss rechtzeitig begegnet werden, indem alternative bzw. ergänzende Flächen samt Auslieferungslogistik organisiert werden. Weiterhin ist die Planung der Installationsorte nicht vergessen werden. Öffentliche Auftraggeber sind einer europäischen Richtlinie zur Auftragsvergabe unterworfen, die in Deutschland unter anderem als Vergabe- und Vertragsordnung für Leistungen (VOL Teil A) umgesetzt ist. Bei Erreichen

71

Eine solche ist vom Teilprozess RE Realisierung bereits abgedeckt.

124

9 PAPRO-Prozess: Die Struktur

bestimmter Schwellenwerte hinsichtlich des Auftragsvolumens ist eine öffentliche Ausschreibung erforderlich. Daraus kann eine Verlängerung der Beschaffungsphase resultieren. Nicht zu unterschätzen ist außerdem die Herausforderung, die mit der Migration von Daten in geänderte Infrastrukturen verbunden ist. Nicht immer handelt es sich nicht nur um Daten auf Fileservern. Häufig geht auch die Migration von Datenbanken mit einher. Oder es wird großer Wert darauf gelegt, dass die Profile von Netzwerkbenutzern ohne Funktionsbeeinträchtigung auf das Zielsystem übertragen werden. Um diesen Anforderungen gerecht zu werden, muss ein projektspezifischer Migrationsplan erstellt werden. Arbeitsschritte zum Prozessschritt PL4 Realisierungsvorbereitung PL4.1 Richtlinien / Pläne für die Realisierung entwerfen / überarbeiten / anpassen – Implementierung (siehe Teilprozess RE) – Qualität – Tests – Schulung – Migration PL4.2 Beschaffungsplanung – Kapazitätsbedarf (Mengengerüst, Auslegung der Systeme) – Beschaffungsverfahren – Logistik für Lagerung und Installation Tabelle 42: Im Rahmen von PL4 zu erstellende Dokumente Arbeitsschritt PL4.1

Dokumentenkürzel DPL8 DPL9 DPL10 DPL11

Dokument Qualitätsmanagementrichtlinie Verfahrensanweisung zum Testen Testplan Migrationsplan

PL4.2

DPL12 DPL13 DPL14

Kapazitätsprognose Anweisung zum Beschaffungsverfahren Logistikplan

Prozessschritt PL5 Betriebsvorbereitung Die Qualität des funktionalen Designs der IT-Infrastruktur ist essentiell für den Projekterfolg. Allerdings ist der erfolgreiche Abschluss des Projekts noch nicht garantiert. Es bedarf daneben auch präziser Klärungen mit dem Leistungsabnehmer und eigenen internen oder externen Dienstleistern bezüglich der Güte der zur Verfügung gestellten Dienste. Das Rahmenwerk ITIL (siehe Kapitel 3) hat hierzu klare Empfehlungen gegeben. Von besonderer Relevanz ist das Service Level Agreement (SLA). Ein SLA ist ein Vertrag zwischen dem Leistungserbringer und dem Kunden, der die vereinbarte und vom Leistungserbringer zugesicherte Dienstgüte dokumentiert. Es handelt sich also um eine Vorsorgemaßnahme, die unmissverständlich darstellen soll, welche Dienstgüte vom ITI-Errichter im Betrieb gewährleisten werden soll und dass der ITI-Errichter sich zur Erreichung dieses Serviceniveaus verpflichtet. Eine solche Vereinbarung ist nicht nur für den Kunden, sondern auch für den Dienstleister von Vorteil, da im SLA Kennzahlen und Zielwerte festgelegt werden, die eine Planungs- und Realisierungshilfe sind.

9.2 Teilprozesse

125

Zu einem professionellen Betrieb von IT-Infrastrukturen gehört das Konfigurationsmanagement, also die Dokumentation der im Einsatz befindlichen Infrastrukturelemente. ITIL hat dafür – wie oben beschrieben – bewährte Hinweise geliefert. Wichtige Anforderungen zum Konfigurationsmanagement finden sich in Kapitel 9 der Norm ISO/IEC 20000-1:2005 wieder. Für ein Servicemanagementsystem wird gefordert, dass das Konfigurationsmanagement Informationen zur Konfiguration der Services und Infrastrukturelemente liefert. Weiterhin sollen die Konfigurationselemente dokumentiert werden (Erstdokumentation siehe Dokument DRE22), bevor die ITI in der Produktivumgebung freigegeben wird. Außerdem ist sicherzustellen, dass alle Konfigurationselemente eindeutig identifizierbar und in einer Konfigurationsmanagementdatenbank (CMDB) gespeichert sind (siehe auch OP1 Objektverwaltung). Versionen, Standorte, Veränderungen, Probleme und zugehörige Dokumentationen der Elemente (CI) sind zu vermerken. Damit die Datenbank eine inhaltliche Aussagekraft erhält, sollten auch die verknüpften Anwendungen mit aufgenommen werden. Ein ähnlicher Ansatz findet sich im CObIT-Prozess DS9 Manage the Configuration wieder. Dort heißt die CMDB Configuration Repository. Es ist zu gewährleisten, dass alle Änderungen (nach der Betriebsaufnahme) in der CMDB dokumentiert werden. Sollte sich bei der Überwachung der ITI zu Betriebsbeginn herausstellen, dass die Qualität der ITI trotz Abnahme und Freigabe (siehe Prozessschritt RE4 Rollout) doch nicht ganz den mittels Pflichtenheft spezifizierten Erwartungen des Kunden entspricht oder Erwartungen doch vom vereinbarten Pflichtenheft abweichen, so sind Änderungen erforderlich. Für Änderungen an Software oder Hardware sollte es ein Verfahren geben, das sich an ITIL bzw. die Norm ISO/IEC 20000-1:2005 anlehnt. Beim Änderungsmanagement ist zu gewährleisten, dass  das Problem dokumentiert und klassifiziert wird,  die Änderung geplant wird (Zeit, Ressourcen),  die Auswirkungen der Änderung analysiert werden,  die Änderung nach Priorität klassifiziert wird,  die Änderung dokumentiert wird,  die Fallbackoption dokumentiert wird,  die Änderung freigegeben wird,  der Erfolg der Änderung überprüft wird,  ein verkürztes Verfahren für eilige Änderungen definiert wird,  es eine klare Zuordnung der Verantwortlichkeiten gibt und  der Vertrag mit dem Kunden gegebenenfalls angepasst wird. In der zugehörigen Richtlinie muss klar definiert sein, was eine eilige Änderung ist. Die Definition muss so gehalten sein, dass dieser Fall Ausnahmefall und nicht Regelfall ist.

126

9 PAPRO-Prozess: Die Struktur

Arbeitsschritte zum Prozessschritt PL5 Betriebsvorbereitung PL5.1 Servicelevel-Management – Service Level Agreements – Operational Level Agreements PL5.2 Richtlinien / Verfahrensanweisungen für den Betrieb entwerfen/überarbeiten – Rollout / Deployment – Konfigurationsmanagement – Fallback – Schulung (optional) – Notfall (optional) PL5.3 Vorbereitung von Instrumenten zur Überwachung der ITI PL5.4 Planung von Änderungsvorgängen Tabelle 43: Im Rahmen von PL5 zu erstellende Dokumente Arbeitsschritt PL5.1

Dokumentenkürzel DPL15 DPL16

Dokument Servicegütevereinbarung mit dem Kunden (SLA) Servicegütevereinbarung mit internen Einheiten des ITI-Providers (OLA)

PL5.2

DPL17 DPL18 DPL19 DPL20 DPL21

Verfahrensanweisung zum Rollout (Deployment) Konfigurationsmanagementrichtlinie Verfahrensanweisung zum Fallback Schulungsplan (optional) Notfallrichtlinie (optional)

PL5.3 PL5.4

DPL22 DPL23

Konzept zur Überwachung der ITI Richtlinie zum Änderungsmanagement

Die Planung der Schulungen wird üblicherweise vom Projektmanagement gesteuert. Der ITIPlaner trägt gegebenenfalls Schulungsinhalte bei. Der Aufwand für das Erstellen der Notfallrichtlinie kann erheblich sein. Wenn möglich, ist diese vor der Betriebsaufnahme fertigzustellen. Gegebenenfalls sollte man die Notfallrichtlinie bei entsprechendem Umfang an einen spezialisierten Dienstleister vergeben. Inputs und Outputs In Tabelle 44 ist dargestellt, welche Objekte in den Teilprozess einzugeben sind und welche Objekte nach einem Prozessdurchlauf erzeugt worden sein sollten.

9.2 Teilprozesse

127

Tabelle 44: Ein- und Ausgaben der Prozessschritte zum Teilprozess PL Planung Prozessschritt PL1

Inputs Geschäftliche und strategische Rahmenbedingungen; Infrastrukturspezifischer Ist-Zustand; Angewendete Standards und Vorgaben; Ergebnisse der Ist-Analyse; Geschäftliche Erwartungen und Anforderungen; Technische Erwartungen und Anforderungen; Ausgewählte ITI-Variante; Pflichtenheft Konzept für das logische Design des Netzwerks

Outputs Dokumente DPL1 – DPL3 (siehe Tabelle 38)

PL3

Konzept für das logische Design des Netzwerks; Konzept für das physische Design des Netzwerks

Dokument DPL7 (siehe Tabelle 41)

PL4

Konzept für das logische Design des Netzwerks; Konzept für das physische Design des Netzwerks; Sicherheitskonzept; Konzept zur Überwachung der ITI; Servicegütevereinbarung (SLA); Angewendete Standards und Vorgaben; Systemumgebung Geschäftliche und strategische Rahmenbedingungen; Angewendete Standards und Vorgaben; Geschäftliche Erwartungen und Anforderungen; Technische Erwartungen und Anforderungen; Ausgewählte ITI-Variante; Pflichtenheft

Dokumente DPL8 – DPL14 (siehe Tabelle 42)

PL2

PL5

9.2.3

Dokumente DPL4 – DPL6 (siehe Tabelle 39)

Dokumente DPL15 – DPL23 (siehe Tabelle 43)

TP RE Realisierung

Zusammenstellung der relevanten Bestandteile der bestehenden Vorgehensmodelle Der BSI-Lebenszyklus liefert die Schlagworte Beschaffung und Umsetzung. Microsoft MSF hat einen Build Track definiert. Die wesentlichen Bestandteile sind:  Erstellung des Softwarecodes  Erstellung der Datenbank Der Stabilize-Track von MSF steuert Folgendes bei:   

Prüfung der entwickelten Komponenten auf Erfüllung der funktionalen Anforderungen Prüfung der entwickelten Komponenten auf Erfüllung der Anforderungen an Performance und Sicherheit Initiierung eines Pilotbetriebs als Option

Der Deploy-Track von MSF hat die Bestandteile  Übernahme der Lösung in den Produktivbetrieb  Freigabe durch die Stakeholder Die Implement-Phase von Cisco PDIOO hat folgende Elemente:  

Freigabe der Designkonzepte Umsetzung der Konzepte

128

9 PAPRO-Prozess: Die Struktur

 Test der Designkonsistenz im Verlauf der Implementierungsschritte Beim SDLC können folgende Themen zugeordnet werden: 

Build

 Implement Das Spiralmodell liefert die Schlagworte Fertigstellung (Realisierung) und Abnahme (Überprüfung). Damit ist im Zusammenhang mit der Realisierung gemeint:    

Erstellung des Softwarecodes Komponententest Integrationstest Akzeptanztest

Die Systemanalyse liefert keinen Beitrag. Das Wasserfallmodell liefert folgende Elemente:  

Implementierung des Softwarecodes Test des Softwarecodes

SSADM liefert keinen Beitrag. Einige Elemente des V-Modells beziehen sich auf die Realisierung:     

Programmierung Modultest Integrationstest Systemtest Abnahmetest

Der Teilprozess Umsetzung und Auslieferung (Deployment) von ITIL ICTIM hat folgende Realisierungsaspekte: 

Anleitungen, die die bestehende Infrastruktur sowie Normen und interne Standards berücksichtigen  Erstellung der ICT-Lösung im Einklang mit den Ergebnissen der Entwicklungs- und Planungsaktivitäten Der Teilprozess Technische Unterstützung von ITIL ICTIM trägt die Elemente  Beschaffung von Komponenten  Koordination der Lieferanten  Erstellung und Wartung von Testumgebungen  Überprüfung der erwarteten Resultate  Technische Unterstützung des Releasemanagements und  Verwaltung der Dokumentationen und Aufzeichnungen bei. Folgende Prozessaktivitäten von CObIT kann man der Phase Realisierung zuordnen:      

AI3.2 Infrastructure Resource Protection AI3.4 Feasibility Test Environment AI4.4 Knowledge Transfer to Staff AI5.1 Procurement Control AI5.3 Supplier Selection AI5.4 IT Resources

9.2 Teilprozesse

129

 AI7.4 Test Environment  AI7.7 Final Test  DS5.5 Security Testing  DS5.7 Security Technology  DS5.10 Network Security  DS5.11 Exchange of Sensitive Data  DS9.1 Configuration Repository  DS11.1 Requirements Data Management  DS11.2 Storage Arrangements  DS11.3 Media Library Management System  DS12.1 Site Selection and Layout  DS12.2 Physical Security Measures  DS12.4 Protection Against Environmental Factors Fischbach/Simon (Tabelle 29) steuern folgende relevante Aspekte bei:  Hardware und Software auswählen und bestellen  Tests schrittweise durchführen  Räume bereitstellen  System dokumentieren  Beteiligte ausbilden  Installation: erst Hardware, dann Test und Abnahme, danach Software Das Clustering der aufgeführten Punkte führt zur Strukturierung des Teilprozesses Realisierung.

TP RE Realisierung

PS RE1

PS RE2

PS RE3

PS RE4

Beschaffung

Umsetzung

Integrationstest

Rollout

Abbildung 45: Grobstruktur zum ISE-Teilprozess Realisierung

Prozessschritt RE 1 Beschaffung Um zur rechten Zeit am rechten Ort zu einem günstigen Preis die richtigen Komponenten (sowohl Prozessmaterial als auch Hilfsmittel72) zur Verfügung zu haben, die zur Realisierung der ITI benötigt werden, sollte man ein Beschaffungsverfahren definieren. Es sollte die Aspekte Lieferantenauswahl, Vertragsmanagement und Beschaffungslogistik abdecken und auch den Funktionstest sowie die eventuelle Rückgabe von Geräten berücksichtigen. Der zugehörige Arbeitsschritt ist bereits im Prozessschritt PL4 Realisierungsvorbereitung vorgesehen.

72

siehe Abschnitt 5.3.1 Prozesskonzept

130

9 PAPRO-Prozess: Die Struktur

Arbeitsschritte zum Prozessschritt RE1 Beschaffung RE1.1 Beschaffung notwendiger Hilfsmittel RE1.2 Beschaffung notwendiger ITI-Komponenten RE1.3 Einrichten einer geeigneten Testumgebung Es ist weiterhin darauf zu achten, dass in vielen Fällen sowohl Hardware als auch Software zu beschaffen ist. Das gilt mitunter auch für Netzwerkkomponenten. Es ist auch an die rechtzeitige Beschaffung von geeigneten Projektmitarbeitern zu denken. Das ist aber in erster Linie Aufgabe des Teilprozesses Projektmanagement. Bei Beschaffungsproblemen muss der Projektleiter mit einer Änderung der Personalzuweisung reagieren. Die Durchführung der Beschaffung wird normalerweise vom Projektteam vorbereitet, aber von der Einkaufsabteilung der Organisation durchgeführt. Das Projektteam sollte sich die Beschaffungsaktivitäten bestätigen lassen. Tabelle 45: Im Rahmen von RE1 zu erstellende bzw. zu beschaffende Dokumente Arbeitsschritt RE1.1

RE1.2

RE1.3

Dokumentenkürzel DRE1 DRE2 DRE3 DRE4 DRE5 DRE6 DRE7

Dokument Bestellung (Kopie) Bestellbestätigung (Kopie) Lieferschein Bestellung (Kopie) Bestellbestätigung (Kopie) Lieferschein Bestätigung der ausgewählten Testumgebung durch den Projektleiter

Prozessschritt RE 2 Umsetzung Gemäß dem Teilprozesses Planung sind die Konzepte für das logische und physische Design sowohl intern als auch vom Kunden bereits abgenommen und damit zur Umsetzung freigegeben. Es geht bei diesen Prozessschritt darum, spezifische Arbeitsschritte für die Errichtung einer beauftragten IT-Infrastruktur zu definieren. Es bietet sich an, hierzu eine Implementierungsrichtlinie zu entwickeln, die sich grundsätzlich in jedem neuen ITI-Projekt anwenden lässt. Diese Richtlinie ergänzt die in Arbeitsschritt PL 4.1 entworfenen Richtlinien und sollte folgende Elemente enthalten:     

Verpflichtung auf die Einhaltung der erstellten Designkonzepte Verpflichtung auf die Erstellung von Installations- und Konfigurationsanweisungen Verpflichtung auf die Verwendung von Installations- und Konfigurationsanweisungen Sicherheitsanforderungen bei ITI-Implementierungen Dokumentationspflichten zu Installation und Konfiguration

Um die ITI-Komponenten testen zu können, muss sichergestellt sein, dass eine geeignete Testumgebung zur Verfügung steht. Dafür sind geeignete Arbeitsräume beim ITI-Errichter erforderlich. Bestandteil der Testauswertung sollte auf jeden Fall der Abgleich mit dem vereinbarten SLA sein.

9.2 Teilprozesse

131

Arbeitsschritte zum Prozessschritt RE2 Umsetzung RE2.1 Implementierungsrichtlinie entwerfen / überarbeiten RE2.2 ITI-Komponenten installieren / konfigurieren RE2.3 ITI-Komponenten testen RE2.4 Installationen und Konfigurationen dokumentieren RE2.5 Systemverwalter schulen (optional) Beim Arbeitsschritt RE2.3 ITI-Komponenten testen sollte darauf geachtet werden, dass – wenn möglich – zunächst ein Funktionstest der Hardware gemacht wird, bevor das Zusammenspiel von Hard- und Software getestet wird. So lassen sich Fehlerquellen besser identifizieren. Tabelle 46: Im Rahmen von RE2 zu erstellende Dokumente Arbeitsschritt RE2.1 RE2.2 RE2.3 RE2.4

Dokumentenkürzel DRE8 DRE9 DRE10 DRE11

Dokument Implementierungsrichtlinie Vorläufige Notizen Standardisierte Notizen zu den Ergebnissen des Komponententests Dokumentation zur Installation/Konfiguration

RE2.5

DRE12

Schulungsunterlagen

Prozessschritt RE3 Integrationstest Das Testen ist nicht nur bei Softwareentwicklungsprojekten, sondern auch bei ITI-Projekten von großer Wichtigkeit. Kein Auftragnehmer kann es sich ohne Imageverlust, Verlust der Kundentreue oder sogar Vertragsstrafen leisten, beim Kunden Systeme in den Produktivbetrieb einzubringen, bei denen die Hardware nicht voll funktionsfähig oder die Funktionsfähigkeit nicht gegeben ist, weil die Installation / Konfiguration nicht korrekt durchgeführt wurde. Wenn eine geeignete Testumgebung zur Verfügung steht (Arbeitsschritt RE 1.3), muss auch sichergestellt sein, dass die Testräume netzwerktechnisch so ausgestattet sind, dass die vom Kunden gewünschten Kommunikationsverbindungen (drahtgebunden, drahtlos) getestet werden können. Isolierte Tests einzelner Hardwarekomponenten sind sinnvoll, aber nicht ausreichend. Den Komponententests muss ein Integrationstest (Gesamttest) folgen, bei dem die miteinander verbundenen Komponenten so wie weit möglich die ITI repräsentieren. Handelt es sich um eine WAN/MAN-Lösung, so ist auch diese in geeigneten Räumen nachzustellen. Der Aufwand für einen 1/1-Test kann hier relativ hoch sein. Dennoch sollte ein WAN/MAN mit mehreren angeschlossenen LAN zumindest als WAN/MAN mit zwei angeschlossenen LAN getestet werden. Als Integrationstest (Gesamttest) ist ein Test zu verstehen, der dazu dient, die verschiedenen, voneinander abhängigen Komponenten der IT-Infrastruktur im Zusammenspiel miteinander zu testen. Dabei haben die beteiligten Komponenten vorher den Komponententest bezüglich ihrer Funktionsfähigkeit und Fehlerfreiheit erfolgreich bestanden. Mit dem Kunden sollten die Erwartungen frühzeitig besprochen worden sein (TP Analyse). Sie sind in der Regel im Lastenheft zu finden und im Pflichtenheft spezifiziert. Dennoch kommt es erfahrungsgemäß zu Situationen, dass der Kunde von der Realität überrascht ist und sich unter der Lösung doch teilweise etwas Anderes vorgestellt hat. Daher lohnt sich der

132

9 PAPRO-Prozess: Die Struktur

Aufwand dem Kunden bereits vor dem Rollout der Systeme die „kleine Lösung“ (Testumgebung) vorzustellen. Wenn die ITI erst mal in die Zielumgebung eingebaut ist, kann der Aufwand für nachträgliche Korrekturen deutlich höher ausfallen. Das gilt insbesondere für einfache ITI-Projekte wie Frontend-Rollouts. Man sollte sich den fertigen Mustercomputer auf jeden Fall vom Auftraggeber abnehmen lassen. Denn Konfigurationsprobleme oder – fehler lassen sich nach dem Rollout von n Computern an m Standorten nur mit großem Zeitund Kostenaufwand beheben, wenn nicht umfangreiche Remotesteuerungsmöglichkeiten mittels einer zentralen Managementsoftware realisiert worden sind. Arbeitsschritte zum Prozessschritt RE3 Integrationstest RE3.1 Repräsentativen Gesamttest durchführen RE3.2 Gesamttest vorstellen – intern – Kunde Tabelle 47: Im Rahmen von RE3 zu erstellende Dokumente Arbeitsschritt RE3.1 RE3.2 RE3.3

Dokumentenkürzel DRE13 DRE14 DRE15 DRE16

Dokument Standardisierte Testnotizen Dokumentation des Gesamttests Präsentation Mängelliste

Prozessschritt RE4 Rollout In vielen Fällen werden Projekte beauftragt, wo nur Teile einer IT-Infrastruktur erneuert oder ergänzt werden. Es sind mehrere Fälle zu unterscheiden. Typische Projektfälle Fall 1 nur passive Netzwerkkomponenten Fall 2 nur aktive Netzwerkkomponenten Fall 3 nur Frontends (Arbeitsplatz) Fall 4 nur Backends (Server, SAN-Komponenten) Fall 5 Kombination aus den Fällen 1 bis 4 Abhängig vom Projekttyp gibt es deutliche Unterschiede beim Rollout, insbesondere hinsichtlich des Ablaufs. Ein „Big Bang“, d.h. die Aktivierung der kompletten, neuen ITI mit einem Schlag, ist nicht immer angemessen und kann risikoreich sein. Pilotbetrieb und Parallelbetrieb bieten sich in bestimmten Fällen als Alternativen an. Beim Pilotbetrieb werden zunächst nur Teile der neuen ITI (Pilotfiliale, Pilotnutzer etc.) in Betrieb genommen. Beim Parallelbetrieb wird die neue ITI zusätzlich zu der alten in Betrieb genommen, aber auf die neue ITI umgeschwenkt. Bei erheblichen Problemen ist ein Zurückschwenken (Fallback) in die alte ITI mit geringem Aufwand möglich. Fall 1: Eine Verkabelung passiert nicht immer auf der grünen Wiese. In etlichen Fällen wird die bestehende Verkabelung modernisiert. Häufig müssen dann auch die Patchfelder ausgetauscht werden. Nach einem erfolgreichen Test steht der Verkabelung in der Produktivumgebung eigentlich nichts entgegen. Allerdings lässt sich die Testumgebung mit der Zielumge-

9.2 Teilprozesse

133

bung nur teilweise vergleichen. Insbesondere die zu überbrückenden Entfernungen haben meist eine größere Dimension. Das Rollout muss hier ebenfalls von Tests begleitet werden, da sicherzustellen ist, dass die Verkabelung die Datentransporte zuverlässig gewährleisten wird. Für diesen Zweck gibt es Kabeltestgeräte. Fall 2: Möchte der Kunde in seinem LAN die Datendurchsatzrate erhöhen, dann ist es meist ratsam, leistungsfähigere Netzwerkverteiler (meist Ethernet-Switche) im Sekundär- und Tertiärbereich zu installieren. Die diesbezüglichen, dem Rollout vorangehenden Tests haben meist gute Aussagekraft. Die Realität lässt sich hier gut nachstellen. Beim Rollout sind diesbezüglich keine speziellen Zusatzaspekte zu berücksichtigen. Fall 3: Sind beispielsweise 500 Frontends an 10 Standorten zu platzieren, damit diese die alten Geräte ersetzen, so sind diese in aller Regel vor dem Rollout vorinstalliert und die Konfiguration ist so weit wie möglich bereits geschehen. Das Rollout-Verfahren muss aber berücksichtigen, dass jeder Computer eine gewisse Menge an individuellen Einstellungen (zum Beispiel IP-Konfiguration, Name) zum ordnungsgemäßen Betrieb benötigt. Dabei kann ein DHCP-Server hilfreich sein. Allerdings ist zu beachten, dass DHCP eine Sicherheitslücke eröffnet, die geeignet zu behandeln oder zu vermeiden ist.73 Um das Risiko nachträglicher Korrekturen zu reduzieren, sollte mit dem Kunden ein Pilotbetrieb vereinbart werden. In diesem Fall sind die Korrekturen nur an einem Standort zu vollziehen. Fall 4: Gehen wir davon aus, dass fünf zentrale Server der Organisation (interner DNSServer, DHCP-Server, Intranet-Server, 2 Fileserver) ersetzt werden sollen, weil die Hardware schon mehr als vier Jahre alt ist und der Kunde einerseits den Ausfall der Hardware nicht riskieren will und andererseits mit der Performance der bisherigen Geräte nicht mehr zufrieden ist. In diesem Fall ist ein repräsentativer Gesamttest (siehe PS RE3) nicht immer hinreichend möglich, da die vollständig korrekte Funktion letztendlich nur in der Produktivumgebung getestet werden kann. Auch eine Pilotinstallation ist hier nicht angemessen bzw. möglich. Es empfiehlt sich, den Rollout mit einem Parallelbetrieb in der Produktivumgebung zu verbinden, so dass ein Fallback in die alte ITI ohne große Probleme möglich ist. In einem anderen Fall ist der Pilotbetrieb eventuell nicht realisierbar, weil es sich um eine zusammenhängende Serverlandschaft handelt, aber es besteht die Möglichkeit übergangsweise eine Parallelstruktur zu betreiben, indem ein zusätzlicher Serverschrank mit der neuen Serverfarm aufgebaut wird. Die Zusammenhänge entstehen meist durch voneinander abhängige Dienste. Der vorübergehende Parallelbetrieb ist auch bei SAN-Projekten möglich. So können mögliche Zugangs- und Zugriffsprobleme nach Betriebsaufnahme durch ersatzweisen Zugriff auf die alte SAN-Struktur kompensiert werden. Allerdings gibt es bei solchen Parallelstrukturen Schwierigkeiten einen konsistenten und aktuellen Datenbestand aufrechtzuerhalten. In der Regel sollte also ein gründlich geplanter Big Bang die geeignete Wahl sein. Auch die Unternehmensgröße und der Projektumfang können Parameter sein, die den Rollouttyp beeinflussen. Beispielsweise gibt es nicht selten kleinere ITI-Projekte, wo es verantwortbar ist, mit einem „Big Bang“ zügig in die neue IT-Infrastruktur zu migrieren, weil möglicherweise auftretende Probleme nicht so weit reichende Auswirkungen haben und

73

Hinweise gibt beispielsweise der IT-Grundschutzmaßmahmenkatalog des Bundesamtes für Sicherheit in der Informationstechnik.

134

9 PAPRO-Prozess: Die Struktur

Fehler meistens relativ schnell behebbar sind. Auf jeden Fall sollte die Entscheidung für eine bestimmte Rolloutvariante ein bewusster Vorgang sein. Wurde das Rollout durchgeführt, so ist darauf zu achten, dass das Rollout mit der Abnahme durch den Kunden beendet wird. Die Abnahme sollte sich am Pflichtenheft orientieren. Bestandteile der Abnahme sollten auf jeden Fall sein:    

Vollständigkeitsverifikation Verfügbarkeitsverifikation Performanceverifikation Sicherheitsverifikation

Die für das Rollout notwendigen Richtlinien sind bereits in Prozessschritt PL5 Betriebsvorbereitung entworfen und dokumentiert worden. Arbeitsschritte zum Prozessschritt RE4 Rollout RE4.1 Auswahl der Rolloutvariante RE4.2 Rollout der passiven Netzwerkkomponenten RE4.3 Rollout der aktiven Netzwerkkomponenten RE4.4 Rollout der Backendsysteme (Server) RE4.5 Rollout der Frontendsysteme (Arbeitsplatzcomputer) RE4.6 Dokumentation der IT-Infrastruktur RE4.7 Abnahme – intern – Kunde Es empfiehlt sich die Dokumentation der ITI in einem gängigen Dateiformat als Text vorzunehmen, damit diese problemlos an relevante Stakeholder des Projekts übergeben werden kann. Die ITI-Dokumentation ist Grundlage für die Erstellung der CMDB. Tabelle 48: Im Rahmen von RE4 zu erstellende Dokumente Arbeitsschritt RE4.1 RE4.2 RE4.3

Dokumentenkürzel DRE17 DRE18 DRE19

Dokument Begründete Entscheidung zur Rolloutvariante Meldung des Rolloutabschlusses Meldung des Rolloutabschlusses

RE4.4 RE4.5 RE4.6 RE4.7

DRE20 DRE21 DRE22 DRE23 DRE24 DRE25

Meldung des Rolloutabschlusses Meldung des Rolloutabschlusses Dokumentation der ITI Mängelliste Abnahmebestätigung zum Realisierungsergebnis gemäß Pflichtenheft Freigabe durch den Projektleiter (Auftragnehmer)

Inputs und Outputs In Tabelle 49 ist dargestellt, welche Objekte in den Teilprozess einzugeben sind und welche Objekte nach einem Prozessdurchlauf erzeugt worden sein sollten.

9.2 Teilprozesse

135

Tabelle 49: Ein- und Ausgaben der Prozessschritte zum Teilprozess RE Realisierung Prozessschritt RE1

RE2

RE3

RE4

9.2.4

Inputs Anweisung zum Beschaffungsverfahren; Logistikplan; Verfahrensanweisung zum Testen Konzept für das logische Design der ITI; Konzept für das physische Design des Netzwerks; Konzept für die Sicherheit der IT-Infrastruktur; Konzept zur Überwachung der ITI; Qualitätsmanagementrichtlinie; Konfigurationsmanagementrichtlinie; Verfahrensanweisung zum Testen Testplan; Migrationsplan; Schulungsplan (optional) Testplan; Qualitätsmanagementrichtlinie; Verfahrensanweisung zum Testen

Outputs Dokumente DRE1 – DRE7 (siehe Tabelle 45)

Logistikplan; Konzept für das physische Design des Netzwerks; Konfigurationsmanagementrichtlinie; Migrationsplan;

Dokumente DRE17 – DRE25 (siehe Tabelle 48); die installierte und konfigurierte IT-Infrastruktur

Dokumente DRE8 – DRE12 (siehe Tabelle 46)

Dokumente DRE13 – DRE16 (siehe Tabelle 47)

TP OP Betriebsaufnahme

Es ist nicht das Ziel einen umfassenden Betriebsprozess zu modellieren. Es geht in unserem Zusammenhang nur um die Betriebsaufnahme nach Abschluss der Planung und Realisierung der ITI. Der Betrieb von IT-Infrastrukturen stellt ein umfangreiches, eigenständiges Thema dar, das nicht Schwerpunkt unserer Betrachtungen ist. Dementsprechend ist die Auswahl der Betriebsaspekte in diesem Sinne selektiv. PRINCE2 beschäftigt sich unter anderem mit dem Managen von Phasenübergängen. Hier handelt es sich um den Übergang von der Projektphase in die Betriebsphase. Wichtig für einen gelungenen Phasenübergang ist der ordentliche Abschluss der vorangegangenen Phase. Dieser ist bei uns mittels der Arbeitsschritte RE4.6 Dokumentation der IT-Infrastruktur und RE4.7 Abnahme repräsentiert. Für die Betriebsaufnahme ist eine aktuelle und umfassende Dokumentation der Installationen samt Konfigurationen wichtig. Durch den Abnahmevorgang kann sichergestellt werden, dass keine offensichtlichen Mängel mehr verblieben sind. Nach dem Durchlaufen des Teilprozesses Realisierung sind also alle notwendigen Voraussetzungen für eine erfolgreiche Betriebsaufnahme geschaffen. Natürlich kann man als Auftragnehmer das Projekt mit der erfolgreichen Abnahme als abgeschlossen ansehen. Es soll ja schließlich auch eine Rechnung gestellt werden. Dennoch empfiehlt es sich, dem Auftragnehmer im Projektvertrag kulante Regelungen für die erste Zeit nach der Inbetriebnahme der ITI anzubieten, weil diese Maßnahme ein relevantes Qualitätsmerkmal eines ITI-Providers ist und die Kundenbindung erhöht. Und ob die errichtete ITI tatsächlich alle Erwartungen bzw. Anforderungen des Auftraggebers erfüllt, stellt sich häufig erst nach Aufnahme des Betriebs heraus.

136

9 PAPRO-Prozess: Die Struktur

Zusammenstellung der relevanten Bestandteile der bestehenden Vorgehensmodelle Der BSI-Lebenszyklus trägt die Schlagworte Betrieb und Aussonderung bei. Microsoft MSF trägt zum Betrieb nichts bei. Dieser ist im Rahmenwerk Microsoft MOF behandelt. Die dort geschilderten Serviceaktivitäten System Administration und Service Monitoring and Control sind relevant. Cisco PDIOO trägt die Lebenszyklusphasen Operate und Optimize bei. Es geht um die Überwachung der Leistungsfähigkeit des IT-Netzwerks. Die erkannten Fehler werden in der Optimize-Phase aufgegriffen. Das Ziel ist die schnellstmögliche Lösung von Problemen unter Beibehaltung der Netzwerkverfügbarkeit. Bei schwerwiegenden Fehlern kann ein Redesign des Netzwerks erforderlich sein. SDLC berücksichtigt, dass es notwendig sein kann, Korrekturen, Ergänzungen oder Upgrades durchzuführen, um zu gewährleisten, dass das System die Anforderungen erfüllt. Beim Spiralmodell beginnt mit der Abnahme schon die Planung des nächsten Zyklusses. Die Systemanalyse liefert keinen Beitrag. Das Wasserfallmodell trägt zur Betriebsaufnahme die Elemente  

Schulung der Benutzer und Beta-Testphase

bei. Die Beta-Testphase kann man allerdings auch noch der Rollout-Phase zurechnen. SSADM trägt hier nichts bei. Das V-Modell kennt die Phase Betrieb. Details werden hierzu nicht behandelt. Beim Teilprozess Betrieb von ITIL ICTIM ist insbesondere die Wartung der ITI von Bedeutung, damit die Infrastruktur stabil und zuverlässig ist beziehungsweise wird. Überwachung und Kontrolle sind hier wichtige Begleitaspekte. Der Teilprozess Technische Unterstützung von ITIL ICTIM liefert folgende Aspekte:  Berichterstattung zur Infrastrukturperformance  Verifikation der CMDB-Elemente  Verwaltung von Dokumenten und Aufzeichnungen  Schulung der Support-Mitarbeiter Folgende Prozessaktivitäten von CObIT kann man der Phase Betrieb zuordnen:  PO8.6 Quality Measurement, Monitoring and Review  AI3.2 Infrastructure Resource Protection  AI3.3 Infrastructure Maintenance  AI6.1 Change Standards and Procedures  AI6.2 Impact Assessment, Prioritisation and Authorisation  AI6.3 Emergency Changes  AI6.4 Change Status Tracking and Reporting  AI6.5 Change Closure and Documentation  DS1.5 Monitoring and Reporting of Service Level Achievements  DS5.5 Security Testing, Surveillance and Monitoring  DS9.1 Configuration Repository  DS10.1 Identification and Classification of Problems Eberle (Tabelle 30) betont die Bedeutung von Maßnahmen der Optimierung und Kontrolle.

9.2 Teilprozesse

137

Das Clustering der aufgeführten Punkte führt zur Strukturierung des Teilprozesses Betriebsaufnahme.

TP OP Betriebsaufnahme

PS OP1

PS OP2

PS OP3

Objektverwaltung

Überwachung

Steuerung

Abbildung 46: Grobstruktur zum ISE-Teilprozess Betriebsaufnahme

Ist nicht vorgesehen, dass die Organisation, die das ITI-Projekt durchgeführt hat, auch den Betrieb übernimmt, so ist es sinnvoller, die folgenden Prozessschritte dem Betreiber der ITI zu überlassen. Ein entsprechendes Übergabedokument ist vorhanden (DRE22). Die vom Betreiber abgedeckten Prozessschritte sollten in diesem Fall im Pflichtenheft des ITIErrichters ausdrücklich ausgeschlossen werden. Prozessschritt OP1 Objektverwaltung Das Konfigurationsmanagement der Infrastrukturelemente ist gemäß Richtlinie DPL18 Konfigurationsmanagementrichtlinie (siehe Prozessschritt PL5 Betriebsvorbereitung) umzusetzen. Arbeitsschritte zum Prozessschritt OP1 Objektverwaltung OP1.1 Erstellen einer CMDB für IT-Infrastrukturkomponenten und Anwendungen OP1.2 Füllen der CMDB auf Basis der ITI-Dokumentation DRE22 Der Wunsch des Auftraggebers die Verwaltung der ITI-Objekte selbst zu übernehmen, ist akzeptabel und kann zweckmäßig sein, weil der Kunde sich frühzeitig mit der neuen ITI vertraut machen kann. Tabelle 50: Im Rahmen von ÓP1 zu erstellende Dokumente bzw. Dateien Arbeitsschritt OP1.1 OP1.2

Dokumentenkürzel DOP1

Dokument Datenbank für Konfigurationsmanagement (CMDB)

Prozessschritt OP2 Überwachung In einigen Fällen wird der Auftraggeber einen Probebetrieb vertraglich vereinbaren, der zum Beispiel vorsieht, dass innerhalb der ersten zwei Monate alle durch Installations- oder Konfigurationsmängel verursachten Leistungsmängel kostenfrei vom ITI-Errichter behoben werden. Diese Forderung ist nachvollziehbar, sollte aber in der Kalkulation angemessen

138

9 PAPRO-Prozess: Die Struktur

berücksichtigt werden (siehe Teilprozess Projektmanagement). Alternativ kann im Vertrag für die Phase der Betriebsaufnahme eine Vereinbarung getroffen werden, bei der Korrekturen nach Aufwand abgerechnet werden. Allerdings ist eine kostenpflichtige Gewährleistung der Funktionsfähigkeit der ITI während der ersten Monate des Betriebs möglicherweise rechtlich problematisch. Auf jeden Fall hat gleich mit Beginn der Betriebsaufnahme auch die Überwachung der Leistungsfähigkeit der ITI zu beginnen. Dazu sollten regelmäßig oder quasipermanent Messungen durchgeführt werden. Von entscheidender Bedeutung ist die Einhaltung der im SLA vereinbarten Service Levels. Auch die Einhaltung der festgelegten Sicherheitsrichtlinien sollte geprüft werden. Die wichtigsten Aspekte der Überwachung sind:   

Performance Verfügbarkeit Sicherheit – Zugang – Zugriff Damit die Überwachung angemessen durchgeführt werden kann, müssen geeignete Werkzeuge (Methoden, Software) zur Verfügung stehen. Diese sind im Arbeitsschritt PL5.3 Vorbereitung von Instrumenten zur Überwachung der ITI festgelegt worden. Zu den Überwachungsaktivitäten sollte dem Kunden regelmäßig (wöchentlich oder monatlich) Bericht erstattet werden. Arbeitsschritte zum Prozessschritt OP2 Überwachung OP2.1 Überwachung der technischen Leistungsfähigkeit der ITI OP2.2 Überwachung der Sicherheitseigenschaften OP2.3 Berichterstattung Tabelle 51: Im Rahmen von OP2 zu erstellende Dokumente bzw. Dateien Arbeitsschritt OP2.1

Dokumentenkürzel DOP2

Dokument Logdatei(en) zur technischen Leistungsfähigkeit

OP2.2 OP2.3

DOP3 DOP4

Logdatei(en) zu Objektzugriffen / Zugriffsversuchen Bericht zur SLA-Konformität der ITI

Prozessschritt OP3 Steuerung Die Steuerung von IT-Infrastrukturen ist hauptsächlich Änderungsmanagement. Das Änderungsmanagement der Infrastrukturelemente ist gemäß Richtlinie DPL23 (siehe Prozessschritt PL5 Betriebsvorbereitung) umzusetzen.

9.2 Teilprozesse

139

Arbeitsschritte zum Prozessschritt OP3 Steuerung OP3.1 Identifizierung, Klassifizierung und Dokumentierung des Problems OP3.2 Auswirkungsanalyse durchführen OP3.3 Änderungsvorschlag erstellen OP3.4 Änderung freigeben OP3.5 Änderung durchführen Probleme lassen sich in der Regel am besten durch konsequente Überwachung74 der Systeme identifizieren (OP2 Überwachung). Die Auswirkungsanalyse untersucht, welche Auswirkungen das Problem auf die Funktionsfähigkeit der ITI hat. Es wird bewertet, inwiefern das Problem eine Veränderung des Ist-Zustands erforderlich macht, um das Problem zu lösen. Im Änderungsvorschlag sollten auf jeden Fall die Priorität der Änderung und die Fallbackoption ausgewiesen sein. Der Freigabe der Änderung durch den Changemanager oder eine äquivalente Person sollte gegebenenfalls eine Abstimmung mit dem Kunden vorausgehen. Eine weitgehende Änderung kann den Vertrag mit dem Kunden tangieren. Bei eiligen Änderungen sind die dementsprechenden Ausführungen in Richtlinie DPL23 zu beachten. Einzelheiten zur Professionalisierung des Änderungsmanagements findet man in [OGC2007]. Tabelle 52: Im Rahmen von OP3 zu erstellende Dokumente bzw. Dateien Arbeitsschritt OP3.1 OP3.2 OP3.3 OP3.4

Dokumentenkürzel DOP5 DOP6 DOP7 DOP8

Dokument Standardisierte Notiz zum Problem Standardisiertes Dokument zur Auswirkungsanalyse Änderungsvorschlag Bestätigung der Freigabe

OP3.5

DOP9

Standardisierte Notiz zur Erfolgsprüfung

Die Dokumente DOP5, DOP6 und DOP7 kann man bei Bedarf in einem Dokument zusammenfassen. Die Bestätigung der Freigabe (DOP8) kann man bei Bedarf als separaten Abschnitt in das Dokument DOP7 integrieren. Ansonsten ist DOP8 so zu gestalten, dass es einen eindeutigen Zusammenhang mit dem Änderungsvorschlag gibt. Entsprechendes gilt für das Dokument DOP9. Falls der Übergangsbetrieb als Parallelbetrieb oder Pilotbetrieb begonnen hat, so ist eine der notwendigen Änderungen der Übergang zur Ziel-ITI. Beim Parallelbetrieb bedeutet das den Wegfall der alten ITI-Komponenten, beim Pilotbetrieb die Erweiterung der neuen ITI auf alle Standorte und Benutzergruppen. Inputs und Outputs In Tabelle 53 ist dargestellt, welche Objekte in den Teilprozess einzugeben sind und welche Objekte nach einem Prozessdurchlauf erzeugt worden sein sollten.

74

Rechtliche Rahmenbedingungen (insbesondere Datenschutzgesetze) sind zu beachten.

140

9 PAPRO-Prozess: Die Struktur

Tabelle 53: Ein- und Ausgaben der Prozessschritte zum Teilprozess OP Betriebsaufnahme Prozessschritt OP1

OP2

OP3

9.2.5

Inputs Die installierte und konfigurierte IT-Infrastruktur; Dokumentation der ITI; Konfigurationsmanagementrichtlinie; Konzept zur Überwachung der ITI; Servicegütevereinbarung mit dem Kunden (SLA); Servicegütevereinbarung mit internen Einheiten des ITIProviders (OLA)

Outputs Dokumente DOP1 (siehe Tabelle 50)

Servicegütevereinbarung mit dem Kunden (SLA); Servicegütevereinbarung mit internen Einheiten des ITIProviders (OLA); Richtlinie zum Änderungsmanagement; Verfahrensanweisung zum Fallback; Notfallrichtlinie (optional)

Dokumente DOP5-DOP9 (siehe Tabelle 52)

Dokumente DOP2 – DOP4 (siehe Tabelle 51)

TP PM Projektmanagement

Der Teilprozess PM Projektmanagement hat eine besondere Rolle. Er ist ein Unterstützungsprozess für die anderen vier Teilprozesse (siehe Abbildung 47). Die Verantwortlichen für diesen Teilprozess haben dafür Sorge zu tragen, dass das Projekt geordnet abläuft, die Ressourcen geplant und verfügbar sind, ein Zeitplan vorhanden ist und möglichst eingehalten wird, die Arbeitsschritte ausreichend dokumentiert sind, die Kosten im Rahmen des Budgets bleiben und das Projekt ordnungsgemäß beendet wird. Weiterhin hat der Projektleiter dafür zu sorgen, dass die Projektbeteiligten rechtzeitig und regelmäßig über den Projektfortschritt Bericht erstatten, so dass seine Berichterstattung an das Management weder behindert noch eingeschränkt wird. Grobstruktur TP PM Projektmanagement

PS PM1

PS PM2

PS PM3

PS PM4

PS PM5

Initiierung

Planung

Durchführung

Controlling

Abschluss

Abbildung 47: Grobstruktur zum ISE-Teilprozess Projektmanagement

Zur Errichtung der Grobstruktur des Teilprozesses Projektmanagement ist das Handbuch PMBoK (siehe Abschnitt 3.1.3) sehr gut geeignet, da hier die 42 Prozessschritte in 5 Gruppen aufgeteilt sind, die sich gut als Prozessschritte eignen: 1. Initiierung 2. Planung 3. Durchführung

9.2 Teilprozesse

141

4. Controlling 5. Abschluss IT-Spezifika spielen bei diesem Granulationsgrad noch keine Rolle. Darüber hinaus sind die Prozessaktivitäten beim klassischen Projektmanagement relativ unabhängig vom Projektgegenstand. Eine Aufgliederung der Arbeitsschritte zu den Prozessschritten von TP PM Projektmanagement wird nicht vorgenommen. Es soll nicht der Eindruck erweckt werden, dass diese unwichtig sind. Aber es liegen viele ausgereifte Publikationen vor, auf die zurückgegriffen werden kann. Insbesondere sei auf [PMI2008] und [OGC2009] sowie den Prozess PO10 Manage Projects von CObIT 4.1 (siehe [ITGI2007]) verwiesen. Ich möchte aber zumindest auf die Bedeutung des Prozessschritts PM5 Abschluss hinweisen. Ein IT-Projekt sollte geordnet enden, also nicht einfach im Sande verlaufen. Folgende Elemente sollten beim Projektabschluss nicht vergessen werden:   

Bewertung der Projektergebnisse durch Projektleiter und Teammitglieder Einigung auf Verbesserungsmaßnahmen („Lessons learned“) Projektabschlussbericht zu den Ergebnissen, der Wirtschaftlichkeit und den Verbesserungsmaßnahmen

In einem abschließenden Teamgespräch haben auch Lob und Tadel ihren Platz. Beide Führungsinstrumente sollten gezielt und zutreffend eingesetzt werden. Im Anhang des Projektabschlussberichts sollten Kopien der Abnahmebestätigungen zum zurückliegenden Projekt abgelegt werden. Entscheidung über die Durchführung des Projekts Ein Projekt beginnt mit der Grundsatzentscheidung über die Durchführung des Projekts. Sie ist der Übergang zum Start der Planungs- und Realisierungstätigkeiten. Das Vorgehen zur Herbeiführung der Entscheidung ist im Projektschritt PM1 Initiierung mit aufgenommen, da ansonsten die Tätigkeiten vor Projektbeginn nicht näher behandelt werden. Streng genommen fällt dieser Arbeitsschritt in die Per-Sales-Phase. In Kapitel 7 wurde behandelt, ob Markt und Kunde so aufgestellt sind, dass das Projekt durchgeführt werden kann beziehungsweise sollte. Die dort hinterlegten Checklisten sollten verwendet werden. Im Falle eines externen Leistungserbringers sollte das Angebot erst nach einer positiven Entscheidung übergeben werden. Weiterhin sollten zwecks Entscheidungsfindung die im Prozessschritt AN2 SollAufnahme enthaltene Anforderungsdokumentation und die in AN3 Alternativenbewertung enthaltene Machbarkeitsanalyse berücksichtigt werden. Die Entscheidung über die Durchführung des Projekts sollte auf jeden Fall begründet und dokumentiert werden. Aus kaufmännischer Sicht empfiehlt es sich für ITI-Provider, bei größeren ITI-Projekten zunächst eine Vorstudie zu verkaufen, die als Hauptteil TP AN Analyse umfasst. Im anderen Fall besteht die Gefahr, dass erheblicher Aufwand für Analysetätigkeiten betrieben wurde, der im Falle einer Entscheidung gegen das Projekt zu finanziellen Verlusten führt. Der Auftraggeber hat häufig bei solchen qualifizierten Analysetätigkeiten Verständnis, dass diese Leistung nicht kostenfrei erbracht werden kann. Bei kleinen Projekten ist der mögliche

142

9 PAPRO-Prozess: Die Struktur

monetäre Schaden relativ gering, so dass die Aktivitäten in der Regel als kostenloser PerSales-Aufwand in Kauf genommen werden können.

9.3

Die Gesamtstruktur

Zusammenfassend kann nun die Gesamtstruktur des ISE-Prozesses präsentiert werden. Es handelt sich um die Aufbaustruktur. Die Struktur bietet alle Bausteine für die im Folgekapitel entwickelten Ablaufstruktur. In Abbildung 48 sind die Arbeitsschritte aus Übersichtlichkeitsgründen nicht mit dargestellt.

9.3 Die Gesamtstruktur

143 PS PM1 Initiierung PS PM2 Planung

TP PM Projektmanagement

PS PM3 Durchführung PS PM4 Controlling

PS PM5 Abschluss PS AN1 Ist-Analyse

TP AN Analyse

PS AN2 Soll-Aufnahme PS AN3 Alternativenbewertung PS PL1 Logisches Design PS PL2 Physisches Design

TP PL Planung

ISEP

PS PL3 Sicherheit PS PL4 Realisierungsvorbereitung PS PL5 Betriebsvorbereitung PS RE1 Beschaffung

PS RE2 Umsetzung

TP RE Realisierung

PS RE3 Integrationstest

PS RE4 Rollout PS OP1 Objektverwaltung

TP OP Betriebsaufnahme

PS OP2 Überwachung PS OP3 Steuerung

Abbildung 48: Aufbaustruktur des ISE-Prozesses

10

PAPRO-Prozess: Der Ablauf Gebraucht der Zeit, sie geht so schnell von hinnen, doch Ordnung lehrt euch Zeit gewinnen. Johann Wolfgang von Goethe

PL Planung

Errichter

AN Analyse

RE Realisierung

OP Betriebsaufnahme

Betreiber Manager

Organisation

Planer

Die Aufbaustruktur des Infrastrukturerrichtungsprozesses ist nun bekannt. Die Teilprozesse mit ihren Prozess- und Arbeitsschritten sind festgelegt. Zugehörige erforderliche Dokumente wurden ausgewiesen. Ziel dieses Kapitels ist es, die Abläufe zu den einzelnen Teilprozessen festzulegen und zu beschreiben. Wenn die Ablaufstruktur vorliegt, ist nicht nur klar, was zu tun ist, sondern auch, wann es zu tun ist. Die Grobstruktur des Ablaufs ist relativ einfach. Der serielle Charakter dominiert. Der Teilprozess PM Projektmanagement begleitet die Hauptprozesse AN Analyse, PL Planung, RE Realisierung und OP Betriebsaufnahme kontrollierend und steuernd.

PM Projektmanagement

Abbildung 49: Ablaufdiagramm zum ISE-Prozess

Normalerweise wird ein Prozess in Bezug auf eine konkrete Organisation beschrieben. In unserem Fall werden generische Abläufe dargestellt, die gegebenenfalls nach beauftragten und selbst realisierten Projekten (siehe Tabelle 14) zu differenzieren sind.

146

10 PAPRO-Prozess: Der Ablauf

Teilprozess PM Projektmanagement

PM2 Planung

Manager

Organisation

10.1

PM1 Initiierung

PM3 Durchführung

PM5 Abschluss

PM4 Controlling

Abbildung 50: Ablaufdiagramm zum Teilprozess PM Projektmanagement

In Abbildung 50 ist der prinzipielle Ablauf des Teilprozesses Projektmanagement dargestellt. Bei einem konkreten Prozessdurchlauf sollte man allerdings nicht ausschließen,. dass ein Planungsschritt (zum Beispiel Projektplan) bereits während der Initiierungsphase und ein Durchführungsschritt (zum Beispiel Teambildung) bereits während der Planungsphase gegangen wird, wenn es für das Projekt angemessen ist. Der Prozessschritt PM1 Initiierung ist eng mit dem Teilprozess AN Analyse verbunden. Es ist darauf zu achten, dass mit PM1 gleich zu Beginn des Prozessdurchlaufs begonnen wird. Weiterhin ist der Prozessschritt PM2 Planung eng mit dem Teilprozess PL Planung verknüpft. Schließlich gilt das auch für den Prozessschritt PM3 Durchführung und den Teilprozess RE Realisierung. Die Verzweigung (Gateway) ist gesetzt, da es möglich sein kann, dass im laufenden Projektmanagement Situationen auftreten, die eine Änderung der Planung erforderlich machen. Die Steuerung und Kontrolle des Projekts (PM4 Controlling) setzt erst nach Projektbeginn ein. Gemäß BPMN-Standard (siehe Tabelle yy) bezeichnet das Symbol O·······> einen Nachrichtenfluss. PM4 Controlling, die Überwachungs- und Steuerungsinstanz, sendet also Nachrichten an PM2 Planung, PM3 Durchführung und PM5 Abschluss. Hierbei handelt es sich meist um Statusmeldungen zu Pünktlichkeit, Aufwandsverbrauch und Budgetkonformität. Außerdem sendet PM3 Durchführung auch Nachrichten an PM4 Controlling. Ein Beispiel für eine Nachricht von PM3 an PM4 könnte die Mitteilung über eine Initiative zur Projektplanänderung sein.

10.2

Teilprozess AN Analyse

Der Ablauf dieses Teilprozesses ist relativ übersichtlich, da die drei Prozessschritte seriell hintereinander ablaufen können und sollten: AN1 Ist-Analyse  AN2 Soll-Aufnahme  AN3 Alternativenbewertung. Die jeweilige Ablaufstruktur des Prozessschrittes kann also separat dargestellt werden.

Planer

147

AN1 Ist-Analyse

Manager

Organisation

10.2 Teilprozess AN Analyse

AN2 Soll-Aufnahme

AN3 Alternativenbewertung

PM1 Initiierung

Abbildung 51: Ablaufdiagramm zum Teilprozess AN Analyse

Dass das möglich ist, liegt daran, dass die Outputs des Prozessschritts AN1 teilweise als Inputs für den Schritt AN2 benötigt werden und AN3 erst gestartet werden kann, wenn auch die Outputs von AN2 vorliegen. Die Inputs und Outputs basieren auf Tabelle 37 (Ein- und Ausgaben zum Teilprozess AN Analyse). Im Teilprozess AN Analyse erhält der Schritt PM1 Initiierung zum Teilprozess PM Projektmanagement Nachrichten von AN1, AN2 und AN3. Es werden die jeweiligen Outputs übermittelt. Damit ist sichergestellt, dass der Projektleiter weiß, welche Prozessschritte abgeschlossen sind. Außerdem kann der Projektleiter aus den erhaltenen Nachrichten (z.B. DAN5 Situationsbewertung nach Ist-Analyse) Schlüsse auf erforderliche Projektplanspezifika ziehen.

10.2.1

Prozessschritt PS AN1 Ist-Analyse

AN1.1 Geschäftliche Rahmenbedingungen

AN1.3 Standards und Vorgaben

Planer

Organisation

Wenn die Ist-Analyse zu einem ITI-Projekt durchgeführt wird, so ist es möglich, die geschäftlichen Rahmenbedingungen (AN1.1) und den Ist-Zustand der Infrastruktur (AN1.2) parallel zu ermitteln, da die hierfür erforderlichen Ansprechpartner in der Regel unterschiedlich sind. Um die in der Organisation angewendeten Standards und Vorgaben zu identifizieren (AN1.3), ist es sinnvoll, zunächst die geschäftlichen Rahmenbedingungen erfasst zu haben. Und wenn man herausfinden möchte, welche die Anforderungen an die derzeitige ITI (AN1.4) sind, so ist es wichtig, dass man den Ist-Zustand der ITI bereits kennt. Die Situationsbewertung (AN1.5) basiert auf den bereits erwähnten Arbeitsschritten.

AN1.5 Situationsbewertung AN1.2 Istzustand Infrastruktur

AN1.4 Identifizierung Anforderungen

Abbildung 52: Ablaufdiagramm zum Prozessschritt PS AN1 Ist-Analyse

148

10 PAPRO-Prozess: Der Ablauf

10.2.2

Prozessschritt PS AN2 Soll-Aufnahme

AN2.1 Geschäftliche Anforderungen

Planer

Organisation

Auch bei der Soll-Aufnahme kann man eine Parallelisierung anstreben, da zur Ermittlung der geschäftlichen Erwartungen und Anforderungen (Arbeitsschritte AN2.1 und AN2.2) meist unterschiedliche Ansprechpartner gehören. Die Situationsbewertung nach Ist-Analyse (DAN5) ist der Hintergrund, vor dem sich diese Tätigkeiten vollziehen.

AN2.2 Technische Anforderungen

Abbildung 53: Ablaufdiagramm zum Prozessschritt PS AN2 Soll-Aufnahme

10.2.3

Prozessschritt PS AN3 Alternativenbewertung

Planer

Organisation

Bei diesem Prozessschritt handelt es sich um einen klassisch seriellen Ablauf. Die Aktionskette beginnt mit der anspruchsvollen und kreativen Tätigkeit, Lösungsalternativen zu entwickeln (AN3.1). Wenn die Lösungsalternativen dokumentiert sind, kann man deren Realisierbarkeit überprüfen (AN3.2). Die danach verbleibenden Lösungsvarianten können dann einem Auswahlprozess (AN3.3) unterzogen werden, so dass eine beste Variante identifiziert wird. Nun ist es sinnvoll, dieser Lösung entsprechend ein Pflichtenheft zu erstellen (AN3.4).

AN3.1 Darstellung der Alternativen

AN3.2 Machbarkeitsanalyse

AN3.3 Auswahl Variante

AN3.4 Erstellung Pflichtenheft

Abbildung 54: Ablaufdiagramm zum Prozessschritt PS AN3 Alternativenbewertung

10.3

Teilprozess PL Planung

Die Ablaufstruktur des Planungsprozesses ist komplexer als die des Analyseprozesses. Von einem seriellen Charakter kann man nicht sprechen. Der klassische Pfad ist PL1 Logisches Design  PL2 Physisches Design  PL3 Sicherheit  PL5 Betriebsvorbereitung  PL4 Realisierungsvorbereitung. Die zunächst ungewöhnliche Reihenfolge PL5  PL4 rührt daher, dass ITI-Implementierung zwar natürlicherweise vor deren Inbetriebnahme liegt,

10.3 Teilprozess PL Planung

149

andererseits aber Output von PL5 (z.B. DPL14 Servicegütevereinbarung (SLA)) den Prozessschritt PL4 beeinflussen kann.

Planer

PL1 Logisches Design

PL5 Betriebsvorbereitung

PL2 Physisches Design

Manager

Organisation

PL3 Sicherheit

PL4 Realisierungsvorbereitung

PM2 Planung

PM4 Controlling

Abbildung 55: Ablaufdiagramm zum Teilprozess PL Planung

Dass das Ablaufdiagramm stark verzweigt ist, hat hauptsächlich folgende Ursachen: 

Die Analyse der Risiken samt deren Behandlung (PL3) kann dazu führen, dass eine Revision am logischen oder physischen Design erforderlich ist.  Die im Rahmen von PL5 Betriebsvorbereitung verabschiedete Dienstgütevereinbarung (SLA) kann dazu führen, dass das Portfolio der Sicherheitsmaßnahmen zu variieren ist oder sogar Änderungen am Design der IT-Infrastruktur erforderlich sind. Aufgrund der Gateways ergeben sich Schleifen, die bei Bedarf auch mehrmals durchlaufen werden können. Der Planungsprozess ist ein komplexer Vorgang, und die Möglichkeit der Iteration ist durchaus sachgerecht. Im Teilprozess PL Planung erhält der Schritt PM2 Planung zum Teilprozess PM Projektmanagement Nachrichten von PL1 bis PL5. Es werden die jeweiligen Outputs übermittelt. Damit ist sichergestellt, dass der Projektleiter weiß, welche Prozessschritte abgeschlossen sind. Außerdem kann der Projektleiter aus den erhaltenen Nachrichten (z.B. DPL13 Logistikplan) Schlüsse auf gegebenenfalls erforderliche Projektplananpassungen ziehen. Diese können Auswirkungen auf die Realisierungsvorbereitungen haben. Daher gibt es auch einen Nachrichtenfluss von PM2 an PL4. Nach dem Projektbeginn wird das Projektcontrolling aktiv. Im Rahmen von PM4 Controlling wird darauf geachtet, ob Zeiten und Budget eingehalten werden und ob die notwendigen Ressourcen zur Verfügung stehen. Diesbezügliche

150

10 PAPRO-Prozess: Der Ablauf

Warnungen werden an PM2 Planung übermittelt, damit Korrekturmaßnahmen ergriffen werden können.

10.3.1

Prozessschritt PL1 Logisches Design

Variante 1: Projekte vom Typ PB1/PS1

Planer

Organisation

PL1.1N Datenübertragungsverfahren

PL1.4N Namen und Adressen PL1.6N Abnahme

PL1.2N Netzsegmentierung PL1.5N Netzwerkmanagement PL1.3N Netzwerkdienste

Abbildung 56: Ablaufdiagramm zum Prozessschritt PS PL1 Logisches Design (Netzwerke)

Dieser Prozessschritt hat einen überwiegend seriellen Charakter. Bevor man sich mit den Netzsegmentierungsoptionen (PL1.2N) beschäftigt, sollte man sich für eine geeignete logische Topologie und passende Übertragungstechnologien/-verfahren (PL1.1N) entschieden haben. Mit diesen Arbeitsschritten sind die Voraussetzungen für die Auswahl geeigneter Netzwerkdienste und –protokolle (PL1.3N) geschaffen. Die konzeptionellen Arbeiten zu Namen und Adressen im Netzwerk (PL1.4N) und zur Ausarbeitung einer Netzwerkmanagementstrategie (PL1.5N) besitzen untereinander keine inhaltlichen Abhängigkeiten und können parallel ausgeführt werden. Konzepte sollen von den Beratern bzw. Systemplanern nicht im Alleingang verabschiedet werden. Deshalb schließt der Prozessschritt PL1N mit der Abnahme des Konzepts zum logischen Design (PL1.6N).

PL1.1S Systemdienste

PL1.3S Berechtigungen

Planer

Organisation

Variante 2: Projekte vom Typ PB2/PS2

PL1.5S Abnahme PL1.2S Netzwerkdienste

PL1.4S Systemmanagement

Abbildung 57: Ablaufdiagramm zum Prozessschritt PS PL1 Logisches Design (Client/Server)

10.3 Teilprozess PL Planung

151

Diese Variante hat ebenfalls einen hauptsächlich seriellen Charakter. Bevor man sich mit der Auswahl geeigneter Netzwerkprotokolle (PL1.2S) beschäftigt, sollte man die zu betreibenden Systemdienste (PL1.1S) festgelegt haben. Das Konzept für Zugangs- und Zugriffsberechtigungen (PL1.3S) kann hingegen unabhängig von der Systemmanagementstrategie (PL1.4S) ausgearbeitet werden. Auch hier schließt der Prozessschritt mit der Abnahme des Konzepts zum Design (PL1.5S).

Prozessschritt PL2 Physisches Design

PL2.3 Weitverkehrsnetz

Planer

Organisation

10.3.2

PL2.1 Frontendgeräte

PL2.2 Verkabelung

PL2.5 Abnahme

PL2.4 Aktive LANKomponenten

Abbildung 58: Ablaufdiagramm zum Prozessschritt PS PL2 Physisches Design

Die Verkabelung ist die Basis der IT-Infrastruktur. Sie muss kompatibel zum logischen Design (PL1) gestaltet werden und ist möglicherweise von der Wahl der Frontendgeräte (PL2.1) beeinflusst. Liegen Anforderungen zur weitgehenden Zentralisierung der Datenverarbeitung vor, so können in großem Umfang Thinclients als Frontends zum Einsatz kommen. Dieser Umstand wiederum beeinflusst den Bandbreitenbedarf im LAN. Weiterhin kann auch die Auswahl von Netzwerkkomponenten das Verkabelungskonzept (PL2.2) beeinflussen. Beispielsweise ist hier relevant, ob ein Gerät den Anschluss von Glasfaserkabeln ermöglicht oder nicht. Also sollte man im Ablauf die umfassenderen Aktivitäten (PL2.3 und PL2.4) vorziehen, damit die Ergebnisse als Input für PL2.2 dienen können. Von PL2.3 nach PL 2.4 ist ein Nachrichtenfluss vorgesehen, damit die LAN/WAN-Schnittstelle angemessen geplant werden kann. Die Abnahme sollte nicht vergessen werden und erfolgt logischerweise zum Schluss.

152

10 PAPRO-Prozess: Der Ablauf

Prozessschritt PL3 Sicherheit

PL3.3 Organisatorische Maßnahmen

Planer

Organisation

10.3.3

PL3.1 Risikoanalyse

PL3.2 Risikobehandlung PL3.4 Technische Maßnahmen

Abbildung 59: Ablaufdiagramm zum Prozessschritt PS PL3 Sicherheit

Es ist offensichtlich, dass die Risikobehandlungsplanung (PL3.2) erst nach der Risikoanalyse (PL3.1) erfolgen kann. Liegt der Risikobehandlungsplan vor, so kann mit dessen Umsetzung begonnen werden. Organisatorische und technische Sicherheitsmaßnahmen ergänzen sich zwar einerseits, sind aber vom Charakter her so unterschiedlich, dass sie parallel konzipiert werden können. Um sie aufeinander abstimmen zu können, ist ein beidseitiger Nachrichtenfluss vorgesehen. Beim Sicherheitskonzept sollte zumindest intern eine Abnahme erfolgen. Hat das Sicherheitskonzept Auswirkungen auf PL1 oder PL2, so erfährt der Abnehmer der diesbezüglichen Konzepte (also der Kunde) gemäß Abbildung 48 davon.

Prozessschritt PL4 Realisierungsvorbereitung

PL4.1 Realisierungsrichtlinien

Planer

Organisation

10.3.4

PL4.2 Beschaffungsplanung

Abbildung 60: Ablaufdiagramm zum Prozessschritt PS PL4 Realisierungsvorbereitung

Dieser Prozessschritt hat eine einfache und kurze Ablaufstruktur. Obendrein ist es möglich, die Beschaffungsplanung (PL4.2) in den Prozessschritt PM2 Planung zu integrieren. Da es bei Arbeitsschritt PL4.1 um die Erstellung von Richtlinien und Plänen für Qualität, Tests, Schulungen und das Kapazitätsmanagement geht, ist eine Parallelisierung mit PL4.2 realisierbar.

10.4 Teilprozess RE Realisierung

10.3.5

153

Prozessschritt PL5 Betriebsvorbereitung

Planer

Organisation

PL5.2 Betriebsrichtlinien

PL5.1 ServicelevelManagement

PL5.3 Überwachungsinstrumente

PL5.4 Änderungsplanung

Abbildung 61: Ablaufdiagramm zum Prozessschritt PS PL5 Betriebsvorbereitung

Da der Entwurf von Richtlinien für den Betrieb der ITI (PL5.2), die konzeptionellen Überlegungen zur Überwachung der ITI (PL5.3) und die Änderungsplanung (PL5.4) sich nicht gegenseitig beeinflussen, kann hier stark parallelisiert werden. Das Wissen um die Servicegütevereinbarung ist dagegen für diese Planungen relevant. Insofern geht PL5.1 den anderen Schritten voraus.

10.4

Teilprozess RE Realisierung

Organisation

Planer

RE1 Beschaffung

Manager

RE2 Umsetzung

RE3 Integrationstest

RE4 Rollout

PM3 Durchführung

Abbildung 62: Ablaufdiagramm zum Teilprozess RE Realisierung

Die Ablaufstruktur dieses Teilprozesses ist grundsätzlich seriell, ermöglicht aber Iterationen. Sind die Hilfsmittel und ITI-Komponenten beschafft und die Testumgebung eingerichtet (Prozessschritt RE1 Beschaffung), so kann mit der Realisierung der ITI begonnen werden (RE2 Umsetzung). Nachdem die ITI-Komponenten installiert, konfiguriert, getestet und dokumentiert worden sind, kann mit dem Gesamttest begonnen werden (RE3 Integrationstest), vorausgesetzt, dass der Komponententest erfolgreich verlaufen ist. Ansonsten muss die

154

10 PAPRO-Prozess: Der Ablauf

Installation oder Konfiguration erneut durchlaufen werden. Es kann auch sein, dass aufgrund von Produktfehlern die Beschaffung erneut durchlaufen werden muss. Sollte der Integrationstest erfolgreich verlaufen sein, kann das Rollout der ITI angeschlossen werden. Falls es beim Test zu Problemen gekommen ist (Funktionsfehler, Qualitätsschwächen), so muss die Umsetzung erneut durchlaufen werden. Sollte sich herausgestellt haben, dass die Testumgebung nicht alle Anforderungen erfüllt, um den Integrationstest in der gebotenen Gründlichkeit durchzuführen, so ist erneut bei der Beschaffung anzusetzen. Das ist auch der Fall, wenn deutlich wird, dass bestimmte Komponenten nicht geeignet sind, um die ITI insgesamt anforderungsgemäß betreiben zu können. Über die Ergebnisse der Prozessschritte RE1 bis RE4 wird PM3 Durchführung in Kenntnis gesetzt, damit die Projektleitung – wenn erforderlich - angemessen reagieren kann.

Prozessschritt RE1 Beschaffung

RE1.1 Beschaffung Hilfsmittel RE1.3 Einrichten Testumgebung

Planer

Organisation

10.4.1

RE1.2 Beschaffung Komponenten

Abbildung 63: Ablaufdiagramm zum Prozessschritt PS RE1 Beschaffung

Die Realisierungsvorbereitung ist im Teilprozess PL Planung verankert und somit vor Beginn des Prozessschritts RE1 abgeschlossen. Dementsprechend liegen eine Anweisung zum Beschaffungsverfahren (DPL13) und ein Logistikplan (DPL14) vor. Eckdaten für die Beschaffung der notwendigen Komponenten liefert das Planungsdokument DPL4 Konzept für das physische Design der ITI. Räume, Schränke, Regale, Tische einerseits und Ordnungsmittel (Richtlinien, Verfahrensanweisungen etc.) andererseits sind typische Hilfsmittel für die Durchführung von Prozessen. Zusätzlich können unterstützende Computersysteme mitsamt seinen Kommunikationsmöglichkeiten oder Messgeräte für das Netzwerk zum Einsatz kommen. Sowohl für den Arbeitsschritt RE 1.1 Beschaffung notwendiger Hilfsmittel als auch für den Arbeitsschritt RE1.2 Beschaffung notwendiger ITI-Komponenten liegen die notwendigen Informationen zur Durchführung mit Abschluss der Planungsphase vor. Eine Abhängigkeit der Arbeitsschritte untereinander ist nicht gegeben.

10.4 Teilprozess RE Realisierung

155

Das Einrichten der geeigneten Testumgebung kann erst stattfinden, wenn die notwendigen Hilfsmittel und ITI-Komponenten beschafft sind.

Prozessschritt RE2 Umsetzung

RE2.1 Implementierungsrichtlinie

RE2.5 Systemverwalter schulen

Planer

Organisation

10.4.2

RE2.2 Komponenten installieren

RE2.3 Komponenten testen

RE2.4 Komponenten dokumentieren

Abbildung 64: Ablaufdiagramm zum Prozessschritt PS RE2 Umsetzung

Eine aktuelle und passende Implementierungsrichtlinie ist Voraussetzung für RE2.2 ITIKomponenten installieren / konfigurieren. Nach der Installation können die Komponenten getestet werden (RE2.3). Der grundsätzlich serielle Ablauf kann durchbrochen werden, falls der Komponententest zu unbefriedigenden Ergebnissen führt. Meist geht es dann um eine Korrektur der Systemkonfiguration. Abbildung 62 macht allerdings deutlich, dass es sogar zu einem Rücksprung zu RE1 Beschaffung kommen kann, denn es kann sich auch um fehlerhafte Komponenten handeln. Ist der Komponententest erfolgreich abgeschlossen und sind die Informationen zur Installation und Konfiguration der Komponenten dokumentiert (RE2.4), so kann sich bei Bedarf die Schulung der Systemverwalter bezüglich der installierten Komponenten (RE2.5) anschließen.

Prozessschritt RE3 Integrationstest

Planer

Organisation

10.4.3

RE3.1 Gesamttest durchführen

RE3.2 Gesamttest vorstellen

Abbildung 65: Ablaufdiagramm zum Prozessschritt PS RE3 Integrationstest

156

10 PAPRO-Prozess: Der Ablauf

Der Integrationstest ist unabdingbar, um Probleme beim Rollout zu reduzieren. Es ist aber nicht ausreichend, wenn einige Mitglieder des Projektteams diesen Test nur miteinander durchführen. Der Test muss dann auch dem Projektleiter intern präsentiert werden, denn dieser hat möglicherweise andere Erwartungen an den Test und die ITI als die Experten. Entsprechendes gilt auch für den Auftraggeber. Es liegt auf der Hand, dass der Test erst im Expertenkreis durchgeführt wird, bevor er anderen vorgestellt wird.

10.4.4

Prozessschritt RE4 Rollout

Planer

Organisation

RE4.2 passive Netzkomponenten

RE4.1 Rolloutvariante

RE4.7 Abnahme

RE4.3 aktive Netzkomponenten

RE4.4 Backendsysteme

RE4.6 Dokumentation

RE4.5 Frontendsysteme

Abbildung 66: Ablaufdiagramm zum Prozessschritt PS RE4 Rollout

In Abschnitt 9.2.3 TP RE Realisierung wurden fünf verschiedene Projektfälle aufgezeigt. Diesem Fallspektrum muss das Ablaufdiagramm zum Rollout gerecht werden. Es ist dementsprechend so angelegt, dass die Arbeitsschritte RE4.2, RE4.3, RE4.4 und RE4.5 wahlweise durchlaufen oder umgangen werden können. Die Reihenfolge dieser Arbeitsschritte ist von Bedeutung, denn das Verkabelungsrollout ist die Grundlage für die Inbetriebnahme der aktiven Komponenten und die Inbetriebnahme der aktiven Komponenten Grundlage für die Erreichbarkeit der Server. Die Endgeräte sollten zuletzt angeschlossen werden, damit diese mit den Servern der ITI von Anfang an kommunizieren können. Zu Beginn wird die Rolloutvariante (Big Bang, Pilotbetrieb oder Parallelbetrieb) festgelegt. Denn diese Entscheidung prägt den Verlauf und Umfang der folgenden Arbeitsschritte. Nach Abschluss der Rolloutaktivitäten kann die errichtete ITI detailliert dokumentiert werden (RE4.6). Für die Abnahme (RE4.7) ist es zweckmäßig, dass nicht nur die ITI selbst, sondern auch deren Dokumentation präsentiert werden kann.

10.5 Teilprozess OP Betriebsaufnahme

Teilprozess OP Betriebsaufnahme OP1 Objektverwaltung

OP2 Überwachung

OP3 Steuerung

Planer

Organisation

10.5

157

Abbildung 67: Ablaufdiagramm zum Teilprozess OP Betriebsaufnahme

Im Prozessschritt RE4 Rollout wurde geklärt, welche Form des Übergangsbetriebs (vollständiger Betrieb der neuen ITI, Pilotbetrieb oder Parallelbetrieb) gewählt werden soll. Um die ITI angemessen überwachen zu können (OP2), werden detaillierte Systeminformationen benötigt. Diese werden in OP1 Objektverwaltung zusammengestellt. Die Informationen, die aus der Überwachung der technischen Leistungsfähigkeit und der Sicherheitseigenschaften resultieren, sind Grundlage für die Problemidentifikation und die daraus folgenden Änderungsaktivitäten (OP3). Die Durchführung einer Änderung kann eine Änderung der Konfiguration eines ITI-Objekts mit sich bringen. In diesem Fall ist OP1 erneut zu durchlaufen. Ansonsten kann gleich wieder zur Überwachung übergangen werden. Wenn es sich bei der Änderung um den Übergang vom Pilotbetrieb zum Vollbetrieb handelt, dann ist vor OP2 immer auch OP1 erneut zu durchlaufen, da etliche ITI-Objekte zur CMDB hinzugefügt werden müssen.

Prozessschritt OP1 Objektverwaltung

Planer

Organisation

10.5.1

OP1.1 Erstellen CMDB

OP1.2 Füllen CMDB

Abbildung 68: Ablaufdiagramm zum Prozessschritt OP1 Objektverwaltung

Beim Arbeitsschritt OP1 Erstellen einer CMDB für IT-Infrastrukturkomponenten und Anwendungen geht es darum eine Datenbank einzurichten. Informationen zur Datenbankstruktur sollte man in der Richtlinie DPL18 Konfigurationsmanagementrichtlinie finden. Nach Fertigstellung der Datenbankstruktur kann die CMDB auf Basis der ITIDokumentation DRE22 mit Inhalt gefüllt werden.

158

10 PAPRO-Prozess: Der Ablauf

Prozessschritt OP2 Überwachung

OP2.1 Überwachung Leistungsfähigkeit

Planer

Organisation

10.5.2

OP2.3 Berichterstattung OP2.2 Überwachung Sicherheit

Abbildung 69: Ablaufdiagramm zum Prozessschritt OP2 Überwachung

Ein entscheidender Schritt für die erste Zeit nach der Betriebsaufnahme ist die konsequente Überwachung der technischen Leistungsfähigkeit der ITI (OP2.1) und deren Sicherheitseigenschaften (OP2.2). Diese Überwachungsaktivitäten beeinflussen sich gegenseitig nicht, so dass sie ohne Einschränkungen parallel durchgeführt werden können. Die Resultate der Überwachung sollten anschließend in einem Bericht für den Kunden (und auch die eigene Organisation) zusammengefasst werden.

Prozessschritt OP3 Steuerung

Planer

Organisation

10.5.3

OP3.1 Problem identifizieren

OP3.2 Auswirkungsanalyse

OP3.3 Änderungsvorschlag

OP3.4 Änderung freigeben

OP3.5 Änderung durchführen

Abbildung 70: Ablaufdiagramm zum Prozessschritt OP3 Steuerung

Die Arbeitsschritte verlaufen konsequent seriell. Durch die dokumentierte Überwachung der ITI ist eine gute Grundlage geschaffen, um Probleme identifizieren zu können (OP3.1). Nun können die Auswirkungen dieses Problems analysiert werden (OP3.2). Sind die Auswirkungen erheblich, so ist ein Änderungsvorschlag zu machen (OP3.3). Dieser ist vom Änderungsmanager freizugeben (OP3.4). Nun kann die Änderung durchgeführt werden (OP3.5).

11

PAPRO-Prozess: Die Realisierung Falschmünzer und Heuchler sind solche, welche alles in der Theorie, aber in der Praxis nichts zustande bringen. Demokrit

Es ist gut einen definierten und strukturierten Prozess zur Errichtung von IT-Infrastrukturen zu kennen. Eine andere Sache ist es, diesen in der eigenen Organisation erfolgreich und nachhaltig zu verankern, damit er sein Potenzial voll entfalten kann. Viele Organisationen scheitern bei der Einführung neuer Prozesse nicht an mangelnder Prozessqualität, sondern an mangelhaftem Prozessmanagement. Zuerst sollte die Checkliste in Abschnitt 5.4 Beachtung finden.

11.1

Typische Vorurteile

Nr. 1 Jedes ITI-Projekt ist einzigartig. Es gibt kaum Gemeinsamkeiten. Man kann die verschiedenen Projekte nicht miteinander vergleichen. Natürlich ist jedes ITI-Projekt einzigartig. Kunden, Orte, Ressourcen und Anforderungen variieren von Fall zu Fall. Es ist aber hoffentlich deutlich geworden, dass ITI-Projekte ohne Weiteres viele Gemeinsamkeiten haben. Nicht nur die vom Projektmanagement begleiteten Phasen Analyse, Planung, Realisierung und Betriebsaufnahme lassen sich auf alle ITIProjekte anwenden, auch fast alle geschilderten Prozessschritte gelten grundsätzlich für alle ITI-Projekte. Der Prozessschritt zum logischen Design ist ein Beispiel für eine notwendige Differenzierung nach Projekttyp. Aber diese Differenzierungsnotwendigkeit ist nicht die Regel, sondern die Ausnahme. Viele ITI-Projekte sind sowohl bezüglich der Aufbaustruktur als auch bezüglich der Ablaufstruktur sehr gut miteinander vergleichbar. Nr. 2 ITI-Projekte sind überschaubar. Der Ablauf ist naheliegend. Ein Prozess zur Planung und Realisierung von ITI-Projekten ist unnötig. Diese Aussagen sind ein Plädoyer für das Prinzip: „Macht es nicht unnötig kompliziert, wenn es doch einfach ist“. Das in der Einleitung vorgestellte Hey-Joe-Prinzip lässt grüßen. Aber dieses Vorurteil ist meist nicht zutreffend. Die Mehrheit heutiger ITI-Projekte haben ein solches Ausmaß an Komplexität oder Größe, dass eine einigermaßen effektive und effiziente Projektbewältigung ohne definierte Rahmenstruktur nur möglich ist, wenn das Projektteam aus sehr erfahrenen ITI-Experten und Projektleitern besteht. Es kann aber nicht Ziel sein, den

160

11 PAPRO-Prozess: Die Realisierung

ISE-Prozess auf einem Reifegrad75 zu halten, wo das Wohl und Wehe der Projekte von einzelnen Personen abhängt, die möglicherweise bald in ein anderes Unternehmen wechseln. Professionelles Management von ITI-Projekten beinhaltet den Anspruch den Reifegrad des zugehörigen Prozesses so zu erhöhen, dass eine hohe Wahrscheinlichkeit besteht, die Projekte effektiv und effizient durchzuführen und zu beenden, ohne von bestimmten Personen abhängig zu sein. Nr. 3 Ein vorgegebener Infrastrukturerrichtungsprozess ist lästig und macht nur Arbeit. Man ist als Experte mehr mit dem Verfassen von Dokumenten als mit der Erreichung der Projektziele beschäftigt. Hinter diesen Aussagen steht oft die Angst, dass der Fachexperte in ein bürokratisches Korsett gezwängt werden soll. Es besteht der Eindruck, dass man nicht zügig auf das Ziel zusteuern kann, sondern durch diverse Dokumentations- und Kontrollpflichten bei der eigentlich wertschöpfenden Arbeit behindert wird. Das Ziel von Dokumentationen und Checklisten ist aber nicht die Bürokratisierung der Projekte, sondern die Qualitätssteigerung. Es soll nicht in Abrede gestellt werden, dass der erste Prozessdurchlauf durchaus mühevoll und relativ unwirtschaftlich sein kann. Die Schlagkraft bekommt ein solches Rahmenwerk für ITI-Projekte erst, wenn die Unternehmensleitung die Umsetzung konsequent unterstützt und von Projekt zu Projekt Effizienzsteigerung festzustellen ist. Die Effizienzsteigerung tritt unter anderem schon deshalb ein, weil etliche Dokumente (Richtlinien, Verfahrensweisungen) für den ISE-Prozess nur einmalig zu erstellen oder nur geringfügig anzupassen sind. Viele IT-Experten haben eine Abneigung gegen schriftliche Dokumentationen. Diese Abneigung ist oft schwer zu beseitigen. Die entsprechenden Mitarbeiter benötigen eine konstruktive, motivierende Teamatmosphäre, die in erster Linie vom Projektleiter geprägt wird. Es kann allerdings auch sein, dass der Projektleiter dennoch beständig auf die Einhaltung der Dokumentationspflichten der Teammitglieder achten muss.

11.2

Typische Fehler

Eine Prozesseinführung scheitert keinesfalls immer an den Schwächen des Prozesses. Häufig ist das Scheitern vielmehr auf vermeidbare Fehler während der Einführung zurückzuführen76: O O O O

75 76

Die Führungskräfte der Organisation unterstützen die Prozesseinführung nur halbherzig. Die Erwartungen an kurzfristige Effizienzsteigerungen durch Einführung des Prozesses sind hoch. Befürchtungen (Ängste, Bedenken) der Mitarbeiter werden nicht ernst genommen. Die Widerstände in der Organisation werden ignoriert. Stattdessen wird frühzeitig Zwang ausgeübt.

siehe Abschnitt 4.2 Einige der hier genannten Misserfolgsfaktoren sind [SSE2008, S.412] entnommen.

11.3 Rollenbezogene Aspekte O O O O O O O O

161

Die betroffenen Mitarbeiter werden nicht ausreichend und rechtzeitig mit dem Prozess vertraut gemacht. Die Einsatzbereitschaft der benötigten Mitarbeiter wird nicht geprüft. Die Stakeholder der Organisation werden nicht ausreichend und rechtzeitig über den Prozess informiert. Der Prozess wird gleich an einem bedeutsamen Kundenprojekt „geübt“. Die betroffenen Mitarbeiter sind nicht hinreichend qualifiziert, also mit der Prozessumsetzung überfordert. Die benötigten Sach- bzw. Hilfsmittel stehen nicht ausreichend zur Verfügung. Es liegt kein praxisorientiertes, kompaktes Prozesshandbuch als Unterstützung bei der Prozessabwicklung vor. Die Einführung des Prozesses verläuft unstrukturiert und unkoordiniert.

Wer die hier geschilderten Fehler, die den Misserfolg der Prozesseinführung wahrscheinlich machen, vermeidet, besitzt eine große Chance die Qualität und den Erfolg seiner ITIProjekte deutlich zu erhöhen. Insbesondere sollte darauf geachtet werden, dass die Mitarbeiter in mehreren Stufen und auf verschiedene Weisen informiert und unterrichtet werden und die Informationen und Materialien gut verständlich, motivierend und praxisnah sind. Geeignet sind Gesprächsrunden, Workshops, persönliche Gespräche, Rundschreiben per Email, Informationen im Intranet und für ITI-Provider gegebenenfalls auch eine Betriebsversammlung. Grundsätzliche Richtlinien und Verfahren können und sollten bereits im Vorfeld des ersten Projekts gemäß ISE-Prozesses erstellt und verfügbar gemacht werden.

11.3

Rollenbezogene Aspekte

Typische Rollen im PAPRO-Prozess sind:  Analytiker  Planer  Realisierer  Betreiber  Projektleiter Die Mitarbeiter, die in den Phasen Analyse und Planung aktiv werden, sind üblicherweise Berater (Consultants) und haben meistens einen Hochschulabschluss. Diese sind gewohnt, strukturiert zu denken und vorzugehen. Es bedarf normalerweise nicht großer Bemühungen, um sie von der Notwendigkeit des Dokumentierens zu überzeugen. Systemintegratoren77 und Systemtechniker werden schwerpunktmäßig in der Realisierungsphase und der Betriebsphase eingesetzt. Erstere unterstützen bei Bedarf auch in der Planungsphase. Letztere sind hauptsächlich bei Routinearbeiten oder Aufgaben mit überschaubarer Komplexität eingesetzt. Systemintegratoren unterscheiden sich von Systemtechnikern üblicherweise durch das Maß an Weiterbildung, Zertifizierung und Erfahrung, ansonsten haben beide Gruppen in der Regel

77

Systemintegratoren werden auch „Systemingenieur“ oder „Systems Engineer“ genannt. Es gibt überwiegend herstellerspezifische Zertifizierungen, zum Beispiel „Microsoft Certified Systems Engineer (MCSE)“.

162

11 PAPRO-Prozess: Die Realisierung

eine anerkannte Berufsausbildung, aber keinen Hochschulabschluss vorzuweisen. Beide Mitarbeitergruppen leisten für den Projekterfolg wichtige Beiträge, sind aber weniger schnell von der Notwendigkeit des Dokumentierens zu überzeugen. Den Systemintegratoren und Systemtechnikern ist dementsprechend bei der Einführung des PAPRO-Prozesses besondere Aufmerksamkeit zu widmen. Die Rolle des Projektleiters lässt sich bestimmten Berufsbildern kaum zuordnen. Je nach Unternehmensgröße und –typ können als Projektleiter Mitarbeiter mit Hochschulabschluss und/oder mit hinreichend Projekterfahrung und Leitungskompetenz eingesetzt sein. Es ist auch bei Projektleitern keine Selbstverständlichkeit, dass sie ordnungsgemäß dokumentieren.

11.4

Der Prozessanlauf

Der Prozesserfolg kann riskiert werden, indem die Verantwortlichen nach dem Prozessanlauf ungeeignete Maßnahmen ergreifen oder notwendige Maßnahmen unterlassen. Diesem Risiko kann zunächst durch ein Einfrieren des Prozesses und anschließend durch eine strukturierte Analyse des Prozesses begegnet werden.

11.4.1

Einfrieren des Prozesses

Ist der ISE-Prozess verabschiedet und bekannt gemacht, so sollte er möglichst schnell in einem ITI-Projekt durchlaufen werden. In dieser Anfangsphase besteht die Gefahr, dass Änderungen am Prozess übereilt und ungerechtfertigt in Gang gesetzt werden. Änderungsvorschläge oder Forderungen sollten natürlich gesammelt, aber zunächst zurückgestellt werden, damit die Prozesseinführung nicht durch Änderungen destabilisiert wird. Man spricht auch von „Frozen Zone“. Auch offensichtlich plausible Vorschläge sollten zurückgestellt werden, denn der ISE-Prozess ist in seiner Gesamtheit so komplex, dass jeder Vorschlag auf seine Angemessenheit umfassend und ohne Zeitdruck geprüft werden sollte. Eine Ausnahme sollte nur bei entdeckten Mängeln gemacht werden, die den Prozesserfolg insgesamt gefährden. Ansonsten hat sich herausgestellt, dass einige „Mängel“ nach einer Eingewöhnungszeit gar nicht mehr als Mangel angesehen werden, weil es sich nicht um objektive Fehler handelt, sondern um Änderungen, die gewohnte Verhaltensweisen ersetzen.

11.4.2

Prozessanalyse

Die Durchführung eines ersten ITI-Projekts als ISE-Prozessdurchlauf ist noch keine Garantie für die erfolgreiche Verankerung des Prozesses in der Organisation. Normalerweise werden gerade bei den ersten Projekte einige Schwachstellen bzw. Ist-Soll-Differenzen erkennbar. Schwachstellenanalyse Bei der Schwachstellenidentifizierung und –analyse sollte genau unterschieden werden, von welchem Typ die Schwachstellen sind. Wichtige Typen sind: 1. Schwachstellen, die mit einzelnen Mitarbeitern verknüpft sind 2. Schwachstellen, die auf inkorrekte oder unvollständige Anwendung des Prozesses zurückzuführen sind 3. Schwachstellen, die auf Schwächen des Prozesses zurückzuführen sind

11.4 Der Prozessanlauf

163

Im ersten Fall geht es darum, dem Mitarbeiter dabei zu helfen, seine persönlichen Schwachstellen (zum Beispiel mangelndes Wissen oder mangelndes Verständnis) zu beseitigen. Im zweiten Fall sollte das Augenmerk darauf gerichtet werden, den Prozess klarer zu vermitteln und/oder auf die vollständige Umsetzung des Prozesses bei Folgeprojekten zu achten. Im letzten Fall schließlich sollte man nicht davor zurückschrecken, den ISE-Prozess an die eigenen Bedürfnisse anzupassen. Hier kann insbesondere die Revision der Prozessziele hilfreich sein. Um sicherzustellen, dass der Prozess durch die Anpassungen tatsächlich effektiver oder effizienter wird, sollte der angepasste Prozess zunächst an einem unkritischen Projekt getestet werden. Außerdem sollte die Änderung von einem kompetenten Team in der Organisation gemeinsam entwickelt und vom Prozessverantwortlichen freigegeben werden. Gap-Analyse Um eine Gap-Analyse, also ein Analyse der Lücke zwischen Ist und Soll durchführen zu können, muss das Soll definiert sein. Als Überschrift über die Sollvorgaben kann auf die Vision aus Kapitel 8 zurückgegriffen werden: ITI-Projekte verlaufen strukturiert und koordiniert und sind effektiv und effizient. Für den ISE-Prozess gibt es insbesondere folgende Soll-Vorgaben: 1. Die Prozessziele müssen klar definiert sein78. 2. Es muss Kennzahlen für die Bewertung des Prozesses geben. 3. Der Prozess muss verständlich und verstanden sein. 4. Die Aufbaustruktur des Prozesses soll eingehalten werden. 5. Die Ablaufstruktur des Prozesses soll eingehalten werden. 6. Die Arbeitsschritte des Prozesses sollten vollständig durchlaufen werden79. 7. Die Zykluszeit des Prozesses sollte so bald wie möglich einen Wert haben, der für die Organisation profitabel ist. 8. Die tatsächliche Durchlaufzeit des Prozesses weicht gar nicht oder wenig von der Planung ab. 9. Die Ergebnisse zu den Prozessschritten sollen konsequent dokumentiert werden. 10. Die Prozessmitarbeiter sollen die Dokumentvorlagen verwenden. 11. Die Checklisten sollen eingesetzt werden. 12. Die Anforderungen der Kunden müssen erfüllt werden. 13. Die Servicegütevereinbarungen entsprechen ihrem Zweck. 14. Die Planungsdokumente werden konsequent umgesetzt. 15. Die zu realisierende ITI wird vor der Betriebsaufnahme systematisch getestet. 16. Die realisierte ITI wird nach der Betriebsaufnahme systematisch überwacht. 17. Die Prozessbeteiligten sollen mittelfristig zufrieden sein. 18. Die Projektleitung hat das Projekt beständig zu kontrollieren und zu lenken.  PM4 19. Die Analytiker, Planer und Realisierer haben die Projektleitung über die Zwischenergebnisse zu unterrichten.

78 79

zum Beispiel mittels einer Balanced Scorecard für Prozesse wie in Abschnitt 5.2 beschrieben Im Einvernehmen mit der Projektleitung und dem Prozessverantwortlichen ist es möglich, bestimmte Arbeitsschritte zusammenzufassen bzw. auszulassen. Diese Entscheidungen sollten aber begründet und dokumentiert sein. Mögliche Anlässe für solche Vereinfachungen sind kleine Projekte oder Projekte mit geringfügiger Komplexität.

164

11 PAPRO-Prozess: Die Realisierung

20. Das Projekt soll einen strukturierten Abschluss haben.  PM5 In die Gap-Analyse sollten viele Prozessbeteiligte mit einbezogen werden. Es bietet sich ein Auswertungsworkshop an, in dem die Lücken aufgrund der Sollvorgaben identifiziert und die Ursachen analysiert werden. Ergebnis des Workshops sollten Korrekturmaßnahmen sein, die geeignet sind, die Lücken zu schließen.

11.5

PAPRO-Spezifika

Zielorientierung Beim PAPRO-Prozess geht es nicht nur darum, die Strukturen für Aufbau und Ablauf einzuhalten. Genauso wichtig ist es, organisationsspezifische Prozessziele zu definieren. In der Medizin ist es nur möglich, einen Menschen als gesund oder krank zu erkennen, weil es spezifische Wertebereiche für Indikatoren gibt, die Gesundheit bzw. Krankheit signalisieren. Analog ist es auch für den PAPRO-Prozess bedeutsam, die Ziele so konkret zu formulieren, dass man anhand von Kennzahlen erkennen kann, wie „krank“ der Prozess ist. Die Ziele und Kennzahlen sollten vor Beginn des ersten im Rahmen des PAPRO-Prozesses verlaufenden ITI-Projekts verabschiedet sein. Eine Anpassung der Ziele und Kennzahlen zu einem späteren Zeitpunkt ist natürlich möglich. Projektinitiierung Es ist für Projektleiter zum Teil ungewohnt, einen Initiierungsvorgang, wie in PS PM1 Initiierung beschrieben, zu durchlaufen. Es ist auch nicht zwingend, dass dieser Prozessschritt vom Projektleiter absolviert wird. Möglicherweise ist es sinnvoller, dass dieser Prozessschritt vom Vertrieb in Zusammenarbeit mit einem Berater gegangen wird. Entscheidender als die Frage, wer diesen Schritt ausführt, ist die Frage, ob er wie geplant ausgeführt wird. Bei der Prozesseinführung sollte besonders auf PM1 Initiierung geachtet werden, weil damit finanzielle Projektrisiken reduziert und ungeeignete Projekte ausgefiltert werden können. Ein funktionierender Prozessschritt Initiierung wird die Prozessakzeptanz erhöhen. Checklisten Zum ISE-Prozess gehören etliche Checklisten. Diese Checklisten geben dem jeweiligen Projekt Orientierung und Richtung. Auch der Auftraggeber profitiert von durchdachten und zielführenden Fragestellungen und deren Einsatz fördert die Vertrauensbildung zwischen dem Anbieter und dem Interessenten bzw. Kunden. Außerdem kann der Anbieter auf diese Weise zügig wichtige Informationen sammeln. Daher sollte darauf geachtet werden, die Checklisten von Anfang an konsequent einzusetzen. Dokumente Der PAPRO-Prozess fordert ein konsequentes Dokumentieren der erzielten Ergebnisse. In diesem Zusammenhang sollten Widerstände nicht ignoriert, sondern ernst genommen werden. Andererseits sollten keine Kompromisse geschlossen werden, die die Qualität des Prozesses reduzieren. Der formale Aufwand sollte für die Prozessbeteiligten so gering wie möglich gehalten werden. Deshalb ist es insbesondere wichtig, vor Einführung des Prozesses

11.5 PAPRO-Spezifika

165

in der Organisation zweckdienliche Dokumentvorlagen zu erstellen, die den dokumentierenden Mitarbeitern die Erfüllung ihrer Pflicht erleichtern.

12

Beispiel für die Planung einer IT-Infrastruktur Es ist nicht genug zu wissen, man muß auch anwenden; es ist nicht genug zu wollen, man muß auch tun. Johann Wolfgang von Goethe

Dieses Kapitel dient dazu, einige Aspekte des PAPRO-Prozesses verständlicher und nachvollziehbarer zu machen. Eine vollständige beispielhafte Anwendung würde den Rahmen dieses Kapitels sprengen und auch einige unnötige Trivialitäten beinhalten. Stattdessen wird eine Auswahl prägnanter Prozesselemente im Rahmen eines fiktiven Anwendungsfalls präsentiert.

12.1

Auftraggeber und Auftragnehmer

Die Carovalio Production GmbH & Co. KG (im Folgenden auch kurz Carovalio genannt) ist ein Unternehmen, das sich vornehmlich mit der Produktion von Sicherheitsprodukten für die Industrie (Helme, Brillen, Gehörschutz, Schutzkleidung) befasst. Hauptsitz ist Berlin. Carovalio hat im Jahr 2009 die IT-Abteilung als Spin-Off 80 ausgelagert. Die daraus entstandene Tarovalio Services GmbH (im Folgenden auch kurz Tarovalio genannt) ist eine 80prozentige Tochter von Carovalio. Die restlichen 20 Prozent der Gesellschafteranteile befinden sich im Besitz von Mitarbeitern der Tarovalio. Carovalio konnte in den vergangenen Jahren ein stetiges Umsatzwachstum verzeichnen. Die Zentrale in Berlin-Schöneberg (Verwaltungs- und Produktionsstandort) ist mittlerweile zu klein geworden. Das bisherige Gebäude ist gemietet. Nun soll innerhalb der nächsten 6 Monate der Umzug in einen Neubau in Berlin-Treptow auf ein angekauftes Gelände stattfinden. Als Auftragnehmer für die Errichtung der IT-Infrastruktur ist die Tarovalio Services GmbH geplant. Taravalio ist so organisiert, dass ein Projektmanager (Maria Mustergültig) die Projekte steuert und überwacht. Sie ist gleichzeitig Eignerin des PAPRO-Prozesses.

80

Ein Spin-Off ist eine Abspaltung einer Geschäftseinheit aus einem Unternehmen und Firmenneugründung mit dieser Geschäftseinheit zu einer eigenständigen Firma.

168

12.2

12 Beispiel für die Planung einer IT-Infrastruktur

Projektinitiierung

Ein Projekt beginnt mit der Grundsatzentscheidung über die Durchführung des Projekts. Gemäß Prozessschritt PM1 Initiierung sollten die in Kapitel 7 hinterlegten Checklisten verwendet werden. Checkliste 2A (ITI-Provider) Markt und Kunden O O O O O O O O

O

O

O

Handelt es sich bei dem Interessenten um ein Wirtschaftsunternehmen, um eine Behörde oder um eine Privatperson? Wirtschaftsunternehmen Mit welchen dieser drei Kundentypen möchten wir Geschäfte machen? Wirtschaftsunternehmen Haben wir branchenspezifisches Wissen? Ist dieses nötig? Als ehemalige IT-Abteilung von Carovalio ist Tarovalio mit der Branche vertraut. Was ist das Kerngeschäft des Kunden? Produktion und Vertrieb von Sicherheitsprodukten für die Industrie Was sind die kritischen Erfolgsfaktoren des Kunden? Qualität, kurze Produktions- und Lieferzeiten Was sind die kritischen Prozesse des Kunden? Produktionsprozess, in Zukunft massiv automatisiert; Lieferkettenmanagement Was sind die Hauptprobleme des Kunden? Unzuverlässige und unsichere Automatisierungstechnologie Gibt es außergewöhnliche Anforderungen des Kunden bezüglich Verfügbarkeit, Performance, Zuverlässigkeit, Benutzerfreundlichkeit, Sicherheit, Interoperabilität, Testdurchführung oder Skalierbarkeit? Für die IT-Systeme, die die Produktion steuern, ist nur eine geringe Aus fallzeit (höchstens 12 Stunden pro Jahr) akzeptabel. Gibt es außergewöhnliche Anforderungen des Kunden bezüglich Compliance? Zur Aufrechterhaltung der Wettbewerbsfähigkeit bei gleichzeitig hohem Qualitätsanspruch sind die nationalen und internationalen Normen für Sicherheitsprodukte konsequent anzuwenden. Haben wir die wichtigsten Anforderungen, Erwartungen und Bedürfnisse unseres Kunden erfasst, verstanden und dokumentiert? Der Interessent bringt zum Ausdruck, dass ein sehr professioneller ITSupport Voraussetzung für die Zusammenarbeit ist. Was für voraussichtliche Auswirkungen hat die vorläufige Ist-Aufnahme auf dieses spezielle ITI-Projekt? Wurden diese dokumentiert? siehe Zwischenbericht 1 (siehe unten)

12.2 Projektinitiierung

169

Checkliste 3A (ITI-Provider) Strategische Aspekte O O O

O

O

Passt der Kunde zur Unternehmensstrategie? Zur Unternehmensstrategie gehört es, den Mehrheitseigner von Tarovalio bestmöglich zu bedienen. Er ist derzeit unser wichtigster Kunde. Passt unsere Größe zur Größe des Kunden? Carovalio hat derzeit 800 Mitarbeiter, Tarovalio hat 40 Mitarbeiter. Das Größenverhältnis passt Lässt sich die Branche des Kunden mit unserer Unternehmensstrategie vereinbaren? Die Branche ist geeignet, denn es gehört zur Unternehmensstrategie, hauptsächlich Projekte mit Industriekunden durchzuführen. Liegt bei einem strategisch unpassenden Kunden eine ausdrückliche Aufforderung der Unternehmensleitung zur Durchführung des Projekts vor? Sorgt die Unternehmens-/Behördenleitung in diesem Fall für das notwendige Personal und Know-how? trifft nicht zu Sind die Projektrisiken (finanzieller Schaden, Verlust des Kunden, Imageschaden etc.) insgesamt so einzuschätzen, dass das Projekt durchgeführt werden sollte? siehe Zwischenbericht 1 (siehe unten)

170

12 Beispiel für die Planung einer IT-Infrastruktur

Stellungnahme zur Projektannahme Projekt: ITI-Projekt Carovalio/Treptow Interessent: Carovalio Production GmbH & Co. KG Autor: Michael Wunderbar, Vertriebsbeauftragter Empfänger: Maria Mustergültig, Projektmanagerin Checkliste 2A „Markt und Kunden“: Caravalio gehört zum Kreis derjenigen Organisationen, mit denen wir Geschäfte machen wollen, denn es handelt es sich um ein Wirtschaftsunternehmen und sie ist sogar Mehrheitseigner der Tarovalio. Als ehemalige IT-Abteilung von Caravalio haben wir ein ausgeprägtes branchenspezifisches Wissen. ! Besonders zu beachten ist, dass hohe Anforderungen offensichtlich nicht im Bereich der Bürokommunikation, sondern bei der Produktions-IT bestehen. Hier sind insbesondere Verfügbarkeit und Sicherheit zu nennen. Es geht um eine Verfügbarkeit von 99,89%. Caravalio hat deutlich gemacht, dass vom Auftragnehmer erwartet wird, dass er nicht nur die ITI errichtet, sondern in der Betriebsphase auch einen professionellen Support anbietet. Da Tarovalio seit 2010 gemäß ISO/IEC 2000081 zertifiziert ist, ist diese Erwartung kein Hindernis für die Durchführung des Projekts. Außerdem betreibt Tarovalio auch bislang schon die IT der Caravalio. Checkliste 3A „Strategische Aspekte“ Der Interessent Caravalio passt in die Unternehmensstrategie, weil er Mehrheitseigner von Tarovalio ist und es sich um die passende Branche handelt. Die Unternehmensgröße des Interessenten passt zur Größe von Tarovalio. Einschätzung der Projektrisiken Es wurde keine Projektbedrohungen identifiziert, die ein erhebliches Projektrisiko bedeuten würden. Ein besonderes Augenmerk sollte auf die hohen Anforderungen bezüglich der Verfügbarkeit und Sicherheit der IT-Systeme zur Steuerung der Produktion gerichtet werden. In diesem Bereich ist mit besonderer Sorgfalt zu planen Votum des Autors Es sollte ein Angebot erstellt werden mit dem Ziel, Auftragnehmer des Projekts zu werden. Stellungnahme des Projektmanagers ____________________________

81

ISO/IEC 20000 ist eine international anerkannte Norm, in der die Anforderungen für ein professionelles ITService-Management spezifiziert sind.

12.3 Analyse

171

Im Folgenden wird davon ausgegangen, dass Frau Mustergültig das Votum bestätigt hat.

12.3

Analyse

12.3.1

Prozessschritt AN1 Analyse

Der Prozessschritt AN1 Ist-Analyse sieht vor, dass die in Abschnitt 9.2.1 hinterlegten Checklisten verwendet werden. Checkliste 4A - Ist-Analyse Geschäftliche Aspekte (Auftraggeber) O Zu welcher Branche gehört ihr Unternehmen? Industrie O Was ist das Kerngeschäft des Unternehmens? Produktion und Vertrieb von Sicherheitsprodukten für die Industrie O Durch welche Adjektive lässt sich ihre Organisation treffend charakterisieren? qualitätsorientiert, hochwertig, zuverlässig O Wie ist die Organisation strukturiert? Die Geschäftsführung besteht aus drei Personen. Die Organisation ist in Abteilungen gegliedert. Es gibt drei Stabsstellen (CIO, Datenschutzbeauftragter, Informationssicherheitsbeauftragter) O Welche rechtlichen Vorgaben und Richtlinien prägen ihre Organisation? nationale und internationale Normen für Sicherheitsprodukte; außerdem ISO 9001, ISO 1400182 (zertifiziert) O Wie lässt sich die IT-Strategie beschreiben? Outsourcing (Tarovalio) O Wie hoch ist das Budget für das Projekt? Wer verwaltet es? Für das Umzugsprojekt sind insgesamt 10 Mio. EUR vorgesehen. Ein spezielles IT-Budget ist bisher nicht abgegrenzt. Das Budget wird vom CFO festgelegt. O Welche gesetzlichen und vertraglichen Vorgaben sind projektrelevant? Caravalio legt großen Wert auf den Datenschutz. Der Auftragnehmer ist verantwortlich dafür, dass die neue IT-Infrastruktur geeignet ist, allen Datenschutzanforderungen gerecht zu werden. O Gibt es derzeit strukturelle Änderungen? Wie ist die Stimmung? Änderungen der Organisationsstruktur sind derzeit nicht geplant. Im Vordergrund steht die Änderung der physischen Struktur (Zentralstandort). O Sind die Interessen hinsichtlich des Projekterfolgs bei den betroffenen Organisationseinheiten unterschiedlich? Inwiefern? Der Leiter der Abteilung Fertigung interessiert sich fast nur für die optimale Kontrolle und Steuerung der Produktion. Bei der

82

Die internationale Norm ISO 14001 legt Anforderungen an ein Umweltmanagementsystem fest.

172

O

O O

12 Beispiel für die Planung einer IT-Infrastruktur Geschäftsführung steht der Gesamterfolg des ITI-Projekts im Vordergrund. Wie heterogen sind Wissen und Erfahrung des technischen Personals? Der Auftraggeber hat im Bereich der Produktionstechnik mehrere, erfahrene Mitarbeiter mit umfangreichen Kenntnissen und Fähigkeiten. Die klassische IT ist an Tarovalio ausgelagert. Carovalio hat einen CIO (Herr Dr. Hubert Hut), der für den Outsourcingnehmer als Ansprechpartner fungiert. Welche geschäftlichen Standards bzw. Vorgaben sind zwingend zu beachten? ISO 9001, ISO 14001 Welche Dienstgütevereinbarungen (SLA) bestehen derzeit für die ITI? Servicevertrag vom 28.09.2009 (siehe Kasten)

EDV-Servicevertrag Zwischen dem Serviceanbieter Tarovalio Services GmbH, Serviceweg 111, 12345 Berlin, nachfolgend 'Auftragnehmer' genannt, und der Carovalio Production GmbH & Co. KG, Produktallee 11, 13579 Berlin, nachfolgend 'Auftraggeber' genannt, werden mit Wirkung vom 28. September 2009 die folgenden Vereinbarungen getroffen. 1. Vertragsgegenstand Dieser Vertrag definiert die Dienstgütevereinbarung (DGV) für regelmäßig durchzuführende Support- und Wartungsaufgaben sowie für die Unterstützungsleistungen zur Sicherstellung bzw. Wiederherstellung der Betriebsbereitschaft für den im Anhang A beschriebenen IT-Verbund des Auftraggebers durch den Auftragnehmer. 2. Beschreibung der EDV-Dienstleistungen Folgende Dienstleistungen werden vom Auftragnehmer erbracht: 1. Anwendersupport 2. Systemwartung 3. Maßnahmen zur Sicherstellung der Betriebsbereitschaft 2.1 Anwendersupport Der Auftragnehmer unterstützt die Anwender des Auftraggebers bei Problemen mit Anwendungen und Hardware der Bürokommunikation. Umfasst sind: - Frontendsysteme - Drucker - Desktopbetriebssysteme - Microsoft Office (Word, Excel, Powerpoint, Outlook) - mySAP ERP Die Supportzeiten sind: …

12.3 Analyse

173

2.2 Systemwartung Der Auftragnehmer wartet die Frontend- und Backendsysteme und die Netzwerkkomponenten im IT-Verbund des Auftraggebers. Umfasst sind: - Frontendgeräte (inklusive Systemkonfiguration) - Backendgeräte (inklusive Systemkonfiguration und Datenbanken) - Aktive Netzwerkkomponenten (inklusive Systemkonfiguration) -… Der Auftraggeber verpflichtet sich, für den Zeitraum dieses Dienstvertrags einen für den Auftragnehmer kostenfreien Fernzugang zur Wartung der im IT-Verbund befindlichen IT-Systeme zur Verfügung zu stellen 2.3 Sicherstellung der Betriebsbereitschaft Der Auftragnehmer ist dafür verantwortlich, dass die in Anhang B beschriebenen Anwendungen benutzt werden können. 3. Dienstgüteniveaus Folgende Ziele gelten als vereinbart: Anwendersupport: Der Auftragnehmer hat innerhalb von 1 Stunde auf eine Anfrage des Auftraggebers zu reagieren. Das Problem ist zu 90% innerhalb von 6 Stunden zu lösen. Systemwartung: Der Auftragnehmer hat jedes Frontendgerät mindestens 1x monatlich, außerdem jedes Backendgerät und jede aktive Netzwerkkomponenten 1x wöchentlich zu warten. Einzelheiten zu den Wartungsleistungen sind im Anhang C beschrieben. Betriebsbereitschaft: Der Auftragnehmer muss im Laufe eines Geschäftsjahrs während der Betriebszeiten zwischen 6.00 und 21.00 Uhr folgende Verfügbarkeiten gewährleisten: Frontendsysteme: 99% Backendsysteme: 99, 5% Netzwerkkomponenten: 99,5% 4. Kommunikation und Berichtswesen … 5. Vergütung und Abrechnung … 6. Haftung, Gewährleistung und Gerichtsstand … Unterschriften … Anhänge …

174

12 Beispiel für die Planung einer IT-Infrastruktur

Checkliste 4B – Ist-Analyse Technische und organisatorische Aspekte (Auftraggeber) O

O O O O O O

O

O

O

Welche Standorte und Gebäude sind beteiligt/ betroffen? Bisherige Zentrale: (1) Produktallee 11, 13579 Berlin (1 Verwaltungsgebäude, 1 Produktionsgebäude) Niederlassungen: (2) Unterweg 22, 15555 Poselstein (3) Oberweg 33, 19999 Obermansendorf Vertriebsbüros: (4) Verkaufspfad 1, 69696 Wiesbaden (5) Kundengasse 2, 89898 München Das Rechenzentrum (RZ) befindet sich im Verwaltungsgebäude von Standort (1). Wie viele Nutzer benutzen die ITI? Wie sind sie auf die Standorte verteilt? (1) 560, (2) 35, (3) 30, (4) 5, (5) 5 Welche Anwendungen nutzen die IT-Infrastruktur? siehe Servicevertrag Anhang B Was sind die zugehörigen Datenverkehrstypen? Nachrichten Existieren Netzwerkstrukturdiagramme? Wie sehen die aus? ja, für die Zentrale; Diagramm liegt derzeit noch nicht vor Was für Netzwerktypen gibt es (LAN, WLAN, VLAN, RAS, VPN, WAN etc.)? LAN, WLAN, RAS, WAN Was sind die hauptsächlichen Datenflusswege? Wo sind die wichtigsten Datenverkehrsquellen? Welche IT-Systeme haben viele Daten zu speichern? 1. Datenfluss zwischen Verwaltung und Rechenzentrum, verursacht vor allem durch MS Office und mySAP ERP 2. Datenfluss zwischen Produktion und Rechenzentrum, verursacht vor allem durch mySAP ERP Wie hoch ist das Datenverkehrsvolumen in den Netzwerksegmenten im Durchschnitt? Über den Switch, der die Frontendsysteme mit den Servern im RZ verbindet, fließen während der Betriebszeiten durchschnittlich 120 Mb/s. Über den Switch, der die Frontendsysteme im Produktionsgebäude mit den Servern im RZ verbindet, fließen während der Betriebszeiten durchschnittlich 20 Mb/s. Über den Router, der die Niederlassungen und Vertriebsbüros mit der Zentrale verbindet, fließen während der Betriebszeiten durchschnittlich 2 Mb/s. Welche Netzwerkprotokolle werden verwendet (CSMA/CD, IPv6, DNS etc.)? OSI-Schicht 2: durchgängig Ethernet OSI-Schichten 3 und 4: IP, TCP, UDP, ARP OSI-Schichten 5 bis 7: DNS, DHCP, HTTP, SMTP, SNMP, RIP Welche Verfahren werden für die Benennung und Adressierung der Computer benutzt?

12.3 Analyse

O

O O

O

O

O O

O

O

175

ARP, DHCP, WINS, DNS Wie ist die IT-Infrastruktur logisch strukturiert bzw. separiert? Das Bürokommunikationsnetz der Zentrale ist nicht aufgeteilt. Zwischen Büronetz und Produktionsnetz befindet sich ein Router. Zur Anbindung der Niederlassungen und Vertriebsbüros dient ein weiterer Router. Zwecks Kommunikation mit dem Internet ist ein weiterer Router im Einsatz. Virtuelle LANs sind nicht eingerichtet. Welche Netzwerkschnittstellen zu anderen Organisationen gibt es? keine Welche Sicherheitsmaßnahmen sind für das Netzwerk umgesetzt? Der Internetrouter hat Firewallfunktionalitäten. Auf allen Frontendgeräten und Windows-Servern ist eine Anti-MalwareSoftware von Symantec installiert. Es existiert ein Active Directory mit etlichen zentral verwalteten Gruppenrichtlinien. Das RZ hat keine Fenster. Es ist gegen Zutritt durch eine einbruchsichere Tür gesichert. Schlüssel haben nur der CIO und der Servicebeauftragte von Tarovalio. Was sind die physischen und logischen Topologien? logisch: Bustopologie im LAN physisch: Baumtopologie in der Verwaltungszentrale, Sterntopologie im Produktionsbereich, in den Niederlassungen und den Vertriebsbüros Was für Netzwerkkomponenten sind im Einsatz (Switches, Router etc.)? 3 Router in der Zentrale (siehe oben); 1 Geländeswitch (Gigabit Ethernet), 2 Gebäudeswitche (Gigabit Ethernet), 7 Etagenswitche (Fast Ethernet) in der Zentrale; pro Niederlassung und Vertriebsbüro je ein ISDN-Router und ein FastEthernet-Switch Wie/womit ist die Datenübertragung realisiert (Twisted-Pair, LWL, Laser etc.)? LWL im Primärbereich, Twisted Pair (Cat. 5) im Sekundär- und Tertiärbereich Wie viele Anschlussdosen gibt es? Wo befinden sich Patchfelder? In den Büros befinden sich durchschnittlich zwei Doppeldosen. Das gilt auch für Konferenz- und Meetingräume. Im Produktionsbereich (2 Etagen) befinden sich pro Etage durchschnittlich 20 Doppeldosen. Im RZ befinden sich die Anschlüsse samt Patchfeldern in den EDVSchränken. Ist die Datenübertragungszuverlässigkeit durch externe Einflüsse (Störstrahlung, Hochwasser, Baustellen, unsachgemäße Verlegung etc.) gefährdet? Es gibt ab und zu Probleme mit der LWL-Verkabelung zwischen den Gebäuden der Zentrale. Diese ist mutmaßlich nicht sachgemäß verlegt worden. Welche Dienste werden von den ITI-Komponenten realisiert? Netzwerkkomponenten: RIPv2

176

O O O O

O O

O

O

O O

12 Beispiel für die Planung einer IT-Infrastruktur Server: DNS, DHCP, HTTP, SMTP, SNMP, MAPI, WINS, Verzeichnisdienst Frontends: DNS-Client, DHCP-Client, MAPI-Client Welche Dienste sind voneinander abhängig? Verzeichnisdienst und DNS; DNS, WINS und DHCP; SMTP und MAPI Wie viele Frontends sind an die IT-Infrastruktur angeschlossen? (1) 520, (2) 30, (3) 25, (4) 4, (5) 4 Gibt es Thinclients? Nein Welches Betriebssystem ist auf den Frontends installiert? Desktops (500 Stück): Windows 7 Service Pack 1 Notebooks (50 Stück): Windows XP Service Pack 2 PDAs (33 Stück): RIM BlackBerry OS 4.6 Werden virtuelle Desktops eingesetzt? Nein Wie/womit wird die IT-Infrastruktur verwaltet? Toolunterstützung? Als Systemmanagementsoftware ist Intel LANDesk Management Suite 6.3 im Einsatz. Die Installation der Frontendgeräte wird manuell durchgeführt. Welche Probleme gibt es (Verfügbarkeit, Sicherheit, Performance etc.)? Die Verfügbarkeit der Steuersysteme in der Produktion ist nicht immer ausreichend. Die Verfügbarkeit der Gebäudeverbindung in der Zentrale entspricht nicht immer den Erwartungen. Der Internetrouter wird häufig von außen angegriffen. Die Vergabe von Zugriffsberechtigungen erfolgt bislang ohne klares Konzept. Wie hoch sind die Datentransportkosten? Der WAN-Datenverkehr des Unternehmens wird über ISDN-Leitungen abgewickelt. Dafür fallen pro Monat Kommunikationskosten in Höhe von ca. 1.500 EUR an. Der Datenverkehr mit dem Internet wird über DSL abgewickelt. Dafür fallen pro Monat Kommunikationskosten in Höhe von ca. 150 EUR an. Welche technischen Standards sind von besonderer Bedeutung? Industrial Ethernet Welche Schwachstellen hat die derzeitige IT-Infrastruktur? Der Internetrouter hat nur einfache Firewallfunktionen (Portfilter). Die mögliche Datendurchsatzrate im WAN des Unternehmens ist unzureichend. Die Steuersysteme in der Produktion sind nicht hinreichend verfügbar.

Ausgehend davon, dass die Dokumentationen DAN1 bis DAN4 vorliegen, wird nachfolgend eine mögliche Situationsbewertung (DAN5) vorgestellt.

12.3 Analyse

177

Situationsbewertung nach Ist-Analyse Projekt: Kunde: Autor: Empfänger:

ITI-Projekt Carovalio/Treptow Carovalio Production GmbH & Co. KG Nina Schlau, Senior Consultant Guido Hurtig, Projektleiter

Zugrundeliegende Dokumente DAN1 Dokumentation der geschäftlichen und strategischen Rahmenbedingungen DAN2 Dokumentation des infrastrukturspezifischen Ist-Zustands DAN3 Dokumentation der angewendeten Standards und Vorgaben DAN4 Dokumentation der Anforderungen an das Netzwerk (Ist) Bewertung der Situation Der Auftraggeber nutzt eine bewährte IT-Infrastruktur. Allerdings entsprechen einige Technologien und Komponenten nicht mehr dem Stand der Technik. Dazu zählen: - WAN-Infrastruktur unter Nutzung von ISDN - Internetrouter - Routingprotokoll RIPv2 - Remote Access per RAS-Server Weiterhin wird die Möglichkeit der virtuellen Separation des LAN mittels VLAN nicht genutzt … Schlussfolgerungen Bei der Aufnahme der Anforderungen bezüglich der neuen ITI sollte dem Kunden vorgeschlagen werden, - die Router auszutauschen und sie mit VPN und OSPF auszustatten, - den WAN-Verkehr mittels VPN auf Basis von SDSL zu realisieren und - beim Internetrouter auf fortgeschrittene Firewallfunktionalitäten zu achten. … Berlin, den

________________

Unterschrift

________________

12.3.2

Prozessschritt AN2 Soll-Aufnahme

Der Prozessschritt AN2 Soll-Aufnahme sieht vor, dass die in Abschnitt 9.2.1 hinterlegte Checkliste verwendet wird.

178

12 Beispiel für die Planung einer IT-Infrastruktur

Checkliste 5 – Soll-Aufnahme O

O O

O O

O O O

O

O O

83

Welche rechtlichen Vorgaben und Richtlinien prägen ihre Organisation zukünftig? Bundesdatenschutzgesetz; nationale und internationale Normen für Sicherheitsprodukte; außerdem ISO 9001, ISO 14001 (zertifiziert) Sind Änderungen an der IT-Strategie geplant? Nein, der IT-Betrieb soll nach wie vor ausgelagert bleiben. Wie sollen sich die Dienstgütevereinbarungen (SLA) für die geplante ITI von den bisherigen unterscheiden? Die beauftragten Dienstleistungen sollen sich an sich nicht ändern. Die Verfügbarkeitsanforderungen sollen wie folgt angepasst werden: Frontendsysteme (Büro): 99% Frontendsysteme (Produktion): 99,5% Backendsysteme: 99, 9% Netzwerkkomponenten: 99,9% Was ist das Ziel der strukturellen Änderungen in ihrer Organisation? trifft nicht zu Welche Standorte und Gebäude sind zukünftig beteiligt/ betroffen? Bei den Niederlassungen und Vertriebsbüros ändert sich nichts. Neue Zentrale: (1) Pischkinstr. 99, 12222 Berlin (1 Verwaltungsgebäude, 1 Produktionsgebäude) Existieren zur Planung Netzwerkstrukturdiagramme? Wie sehen die aus? Es existieren noch keine Plandiagramme. Was für Netzwerktypen gibt es zukünftig (LAN, WLAN, VPN, WAN etc.)? LAN, WLAN, VLAN, VPN, WAN Welche Anwendungen nutzen die künftige IT-Infrastruktur? SAP ERP; SAP CRM; SAP PLM; SAP SCM; Textverarbeitung (Word); Tabellenkalkulation (Excel); Präsentationssoftware (Powerpoint); Mail (Outlook/Exchange); Projektverwaltung (Project); Webbrowser/Webserver; PDF-Reader (Acrobat); Telefonie; SPS-Software Von welchem Typ sind die Architekturen der Anwendungen? 1-Tier-Architektur83: Word, Excel, Powerpoint, Project, PDF-Reader, SPSSoftware 2-Tier-Architektur: Outlook/Exchange, Webbrowser/Webserver; Telefonie 3-Tier-Architektur: SAP ERP, SAP CRM, SAP PLM, SAP SCM Was sind die zugehörigen Datenverkehrstypen (Nachrichten, Voice, Video etc.)? Nachrichten, Voice Was für Änderungen an den IT-Systemen sind geplant? Erneuern Hardware: Notebooks, Server, Netzwerkkomponenten Erneuern Betriebssystem: Windows 7 auf den Notebooks, Windows Server 2008 auf den Backendsystemen

Tier (englisch): Stufe, Schicht

12.3 Analyse O

O

O O O O

O

O O

O

O

179

Wo sind die wichtigsten Datenverkehrsquellen? Auf den Frontendsystemen (Büro); hauptsächlich die Anwendungen SAP ERP; Outlook; Telefonieclient Der Bedarf an Datendurchsatz erhöht sich durch den Einsatz der VoIPLösung am Serverswitch um ca. 15 Mbit/s. Welche Netzwerkprotokolle sollen verwendet werden (IPv6, DNS etc.)? OSI-Schicht 2: durchgängig Ethernet OSI-Schichten 3 und 4: IPv4, IPv6, TCP, UDP, ARP OSI-Schichten 5 bis 7: DNS, DHCP, HTTP, SMTP, SNMP, OSPF Welche Verfahren sollen für die Benennung und Adressierung der Computer benutzt werden? ARP, DHCP, DNS Gibt es Vorgaben zur Strukturierung bzw. Separierung des IT-Netzes? Das LAN der Verwaltungszentrale soll separiert werden. Welche Netzwerkschnittstellen zu anderen Organisationen sind geplant? Es soll ein Extranet für Lieferanten aufgebaut werden. Welche Sicherheitseigenschaften sind besonders wichtig? Verfügbarkeit der SAP-Anwendungen und der SPS-Software; Integrität der ERP-Daten; Vertraulichkeit der Mitarbeiterdaten; Authentizität der Lieferanten Welche Sicherheitsmaßnahmen sind für das Netzwerk umzusetzen? Der Internetrouter bekommt eine Application-Level-Firewall. Es wird eine zentral verwaltete Anti-Malware-Software installiert. Es wird ein RADIUS-Server integriert. Die Mitarbeiter erhalten Benutzerausweise mit integriertem Chip. Diese dienen gleichzeitig als Zimmerschlüssel. Gibt es Vorgaben hinsichtlich der physischen und logischen Topologien? nein Was für Netzwerkkomponenten sind zukünftig im Einsatz (Switches, Router etc.)? Zentrale: 1 Internet/WAN-Router (DSL, VPN), redundant ausgelegt; 1 Geländeswitch (Gigabit Ethernet), redundant ausgelegt; 2 Gebäudeswitche (Gigabit Ethernet), redundant ausgelegt; 5 Etagenswitche (Fast Ethernet) im Verwaltungsgebäude; 2 Etagenswitche im Produktionsgebäude Niederlassungen und Vertriebsbüros: je ein DSL-Router und ein Fast-Ethernet-Switch; Wie/womit soll die Datenübertragung realisiert werden (Twisted-Pair, LWL, etc.)? LWL im Primärbereich, Twisted Pair (Cat. 7) im Sekundär- und Tertiärbereich Wie viele Anschlussdosen gibt es zukünftig? Wo sind Patchfelder geplant? In den Büros sollen jeweils zwei Doppeldosen (Bodentank) installiert werden. Das gilt auch für Konferenz- und Meetingräume.

180

12 Beispiel für die Planung einer IT-Infrastruktur Im Produktionsbereich (2 Etagen) sollen pro Etage durchschnittlich 20 LAN-Anschlüsse (Industrial Ethernet) zur Verfügung stehen. Zusätzlich sollen pro Etage vier WLAN-Access-Points installiert werden. Im RZ befinden sich die Anschlüsse samt Patchfeldern in den EDVSchränken. Zusätzlich gibt es in beiden Gebäuden pro Etage einen Raum mit einem Verteilerschrank, der Patchfelder und den Etagenverteiler aufnimmt. Welche Dienste werden gemäß der derzeitigen Planung von den ITIKomponenten realisiert? Netzwerkkomponenten: OSPF, VPN Server: DNS, DHCP, HTTP, SMTP, SNMP, MAPI, Verzeichnisdienst, VoIP Frontends: DNS-Client, DHCP-Client, MAPI-Client Wie viele Frontends sind an die IT-Infrastruktur anzuschließen? (1) 540, (2) 35, (3) 30, (4) 4, (5) 4 Wie viele ITI-Benutzer wird es geben? Wie sind sie auf die Standorte verteilt? (1) 600, (2) 40, (3) 35, (4) 5, (5) 5 Wie/womit wird die IT-Infrastruktur verwaltet? Toolunterstützung? IBM Tivoli Endpoint Manager für Softwareverteilung, Remote Support und Assetmanagement Sollen die Benutzer der ITI dezentral oder zentral verwaltet werden? zentral Wie hoch dürfen die Datentransportkosten sein? WAN/Internet-Datenverkehr: maximal 1.200 EUR pro Monat; Welche Technologien sind unerwünscht? Technologien, die aus heutiger Sicht nicht sicher sind Welche technischen Standards sind von besonderer Bedeutung? Industrial Ethernet, VoIP Welche Infrastruktureigenschaften haben besondere Priorität (Verfügbarkeit, Sicherheit, Skalierbarkeit, Zuverlässigkeit, Usability, Performance, Testdurchführung)? Verfügbarkeit, Sicherheit, Skalierbarkeit, Zuverlässigkeit, Usability, Umweltfreundlichkeit (Energieverbrauch)

O

O O O O O O O O

Da das Finanzbudget eine wichtige Steuergröße für das ITI-Projekt darstellt, wurde der Auftraggeber im Nachgang zum Interview über die Soll-Aufnahme gebeten, die bei der IstAnalyse gemachten Budgetangaben zu präzisieren. Der CFO teilte daraufhin mit, dass für das ITI-Projekt maximal 400.000 EUR zur Verfügung stehen. Wir gehen im Folgenden davon aus, dass die geschäftlichen und technischen Anforderungen (DAN6, DAN7) dokumentiert wurden. Zusammenfassung der hauptsächlichen Anforderungen 

geschäftlich o Datenschutzkonformität o Vertraulichkeit der Mitarbeiterdaten

12.3 Analyse

181 o o o o

hohe Usability Aufrechterhaltung der Zertifizierung gemäß ISO 9001 Aufrechterhaltung der Zertifizierung gemäß ISO 14001 IT-Outsourcing



technisch o Skalierbarkeit der IT-Systeme o Erhöhte Verfügbarkeitsanforderungen für IT-Systeme o Unterstützung von Sprachdatenverkehr per VoIP o Aktuelle Betriebssysteme o Erhöhte Datendurchsatzrate o IPv6-Fähigkeit der ITI-Komponenten o Separation des LANs in der Zentrale o Extranet im LAN der Zentrale o Authentizität der Extranetnutzer o Internetrouter mit Application-Level-Firewall o Router mit OSPF o Zentral verwaltete Anti-Malware-Software o RADIUS-Server o Benutzerausweise mit Schlüsselfunktion o Redundante Auslegung wichtiger Netzwerkkomponenten o DSL statt ISDN o VPN statt RAS o Systemmanagement mit Remoteinstallation o Aussondern unsicherer Technologien o Cat.7-Kabel im Sekundär- und Tertiärbereich o Anschlussdosen im Bodentank



finanziell o o



12.3.3

Projektkosten maximal 400.000 EUR WAN/Internet-Datenverkehr: maximal 1.200 EUR pro Monat

ethisch o Umweltfreundlichkeit (reduzierter Energieverbrauch)

Prozessschritt AN3 Alternativenbewertung

In diesem Prozessschritt sollen Lösungsalternativen bewertet werden. Der in diesem Projekt verantwortliche Berater auf Seiten von Tarovalio hat drei Alternativen zusammengestellt.

182

12 Beispiel für die Planung einer IT-Infrastruktur

Tabelle 54: Lösungsalternativen Bereich LAN/WLAN

Variante A Status Quo

Variante B Redundante Auslegung der Gebäudeswitche, des Geländeswitches und des Internet/WAN-Routers in der Zentrale; Patchfelder und Anschlussdosen gemäß dem derzeitigen Bedarf; LWL im Primärbereich, Twisted Pair (Cat. 6) im Sekundär- und Tertiärbereich; Separation per VLAN; Internetrouter mit Application-Level-Firewall; Neue Notebooks der Mittelklasse; Extranet in einer DMZ SDSL an allen Standorten; Verschlüsselter Datentransport im VPN IPv4 als Kommunikationsprotokoll; VoIP-Telefonie als Softwarelösung; RADIUS-Dienst; TLS/SSL für die Kommunikation mit dem Extranetserver

WAN

Status Quo

Dienste / Protokolle

Status Quo

Daten

Status Quo

Abspeicherung im LAN; Clusterservice für Fileserver; Zugriffsberechtigungskonzept für gespeicherte Daten

Software

Status Quo

Infrastruktur

Status Quo

IBM Tivoli Endpoint Manager als Systemmanagementlösung Benutzerausweise mit integriertem Chip als Zimmerschlüssel

Variante C Redundante Auslegung aller Switches und Router in der Zentrale; Patchfelder und Anschlussdosen großzügig ausgelegt; LWL im Primär- und Sekundärbereich, Twisted Pair (Cat. 7) im Sekundärund Tertiärbereich; Separation per VLAN; Internetrouter mit Application-Level-Firewall; Intrusion Detection System; Neue Notebooks der Oberklasse; Extranet in einer DMZ VDSL an allen Standorten; Verschlüsselter Datentransport im VPN IPv4 und IPv6 als Kommunikationsprotokolle; IPSec zur Kommunikation im LAN VoIP-Telefonie als Softwarelösung, zusätzlich ein VoIPTelefon pro Raum; RADIUS-Dienst; TLS/SSL für die Kommunikation mit dem Extranetserver Abspeicherung von Datenbanken im SAN, ansonsten Abspeicherung im LAN; Clusterservice für Fileserver; Rigides Zugriffsberechtigungskonzept für gespeicherte Daten IBM Tivoli Endpoint Manager als Systemmanagementlösung Benutzerausweise mit integriertem Chip als Zimmerschlüssel

Die drei Alternativen sind einer Machbarkeitsanalyse zu unterwerfen. Dabei ist deren Realisierbarkeit aus organisatorischer, technischer, finanzieller und ethischer Perspektive zu untersuchen. Es geht jeweils darum, ob bzw. in welchem Maße die Lösung die Erwartungen erfüllen kann.

12.3 Analyse

183

Tabelle 55: Machbarkeitsanalyse Realisierbarkeit Organisatorisch

Technisch

Variante A

Variante B

Variante C

Die Zutrittsbeschränkungen zu den Räumen sind bislang nicht ausreichend. (-) Die Vertraulichkeit der Mitarbeiterdaten ist mangels Zugriffsberechtigungskonzept bislang nicht ausreichend gesichert. (-) Die Usability ist befriedigend. (+) Die Zertifizierungen sind durch den Status Quo nicht gefährdet. (+) Die IT-Systeme sind nur teilweise skalierbar. (-) Variante A wird den Verfügbarkeitsanforderungen an die zukünftige ITI nicht gerecht. (-) VoIP wird nicht unterstützt. (-) Die Betriebssysteme sind nicht durchgängig aktuell. (-) Variante A kann die Anforderungen an den Datendurchsatz erfüllen. (+) Nicht alle Komponenten sind IPv6-fähig. (-) Das LAN ist nicht separiert. (-) Es gibt kein Extranet im LAN. (-) Es gibt keine authentischen Extranetnutzer. (-) Es gibt keinen InternetRouter mit ApplicationLayer-Firewall. (-) Die Router lassen sich auf OSPF umstellen. (+) Die derzeitige Anti-MalwareSoftware ist nicht zentralisierbar. (-) Es gibt keinen RADIUSServer. (-) Es gibt keine Benutzerausweise mit Schlüsselfunktion. (-) Die Netzwerkkomponenten sind nicht redundant ausgelegt. (-) DSL wird nicht unterstützt. (-) VPN wird nicht unterstützt. (-)

Die Zutrittsbeschränkungen zu den Räumen sind ausreichend. (+) Die Vertraulichkeit der Mitarbeiterdaten ist durch das Zugriffsberechtigungskonzept ausreichend gesichert. (+) Die Usability ist befriedigend. (+) Die Zertifizierungen sind durch Variante B nicht gefährdet. (+)

Die Zutrittsbeschränkungen zu den Räumen sind ausreichend. (+) Die Vertraulichkeit der Mitarbeiterdaten ist durch das Zugriffsberechtigungskonzept gut gesichert. (+) Die Usability ist befriedigend. (+) Die Zertifizierungen sind durch Variante C nicht gefährdet. (+)

Die ITI-Komponenten sind nur teilweise skalierbar. (-) Die Verfügbarkeitsanforderungen sind nur teilweise erfüllt. (-) Die Betriebssysteme sind durchgängig aktuell. (+) Variante B kann die Anforderungen an den Datendurchsatz erfüllen. (+) Alle Komponenten sind IPv6fähig. (+) Das LAN ist per VLAN separiert. (+) Es gibt ein Extranet im LAN. (+) Die Extranetnutzer werden authentisiert. (+) Es gibt einen Internet-Router mit Application-LayerFirewall. (+) Die Router unterstützen OSPF. (+) Die neue Anti-MalwareSoftware ist zentralisierbar. (+) Es gibt einen RADIUSServer. (+) Es gibt Benutzerausweise mit Schlüsselfunktion. (+) Die wichtigen Netzwerkkomponenten sind redundant ausgelegt. (+) DSL wird unterstützt. (+) VPN wird unterstützt.(+) Die neue Systemmanagementsoftware unterstützt Remoteinstallation. (+) Der neue Exchange-Server auf Basis von Windows 2008 unterstützt SMTP mit

Die ITI-Komponenten sind überwiegend skalierbar. (+) Die Verfügbarkeitsanforderungen sind nur teilweise erfüllt. (-) Die Betriebssysteme sind durchgängig aktuell. (+) Variante C kann die Anforderungen an den Datendurchsatz erfüllen. (+) Alle Komponenten sind IPv6fähig. (+) Das LAN ist per VLAN separiert. (+) Es gibt ein Extranet im LAN. (+) Die Extranetnutzer werden authentisiert. (+) Es gibt einen Internet-Router mit Application-LayerFirewall. (+) Die Router unterstützen OSPF. (+) Die neue Anti-MalwareSoftware ist zentralisierbar. (+) Es gibt einen RADIUSServer. (+) Es gibt Benutzerausweise mit Schlüsselfunktion. (+) Alle aktiven Netzwerkkomponenten sind redundant ausgelegt. (+) DSL wird unterstützt. (+) VPN wird unterstützt.(+) Die neue Systemmanagementsoftware unterstützt Remoteinstallation. (+) Der neue Exchange-Server auf Basis von Windows 2008 unterstützt SMTP mit

184

12 Beispiel für die Planung einer IT-Infrastruktur

Realisierbarkeit

Finanziell

Ethisch

SUMME

84

Variante A

Variante B

Variante C

Die Systemmanagementsoftware unterstützt keine Remoteinstallation. (-) Der derzeitige ExchangeServer unterstützt SMTP mit Authentisierung nicht. (-) Es werden Cat.5-Kabel verwendet. (-) Bodentanks können bei Umzug vorgesehen werden.(+)

Authentisierung. (+) Es werden Cat.7-Kabel verwendet. (+) Bodentanks sind vorgesehen.(+)

Authentisierung. (+) Es werden Cat.7-Kabel verwendet. (+) Bodentanks sind vorgesehen.(+)

Das Projektbudget wird nicht überschritten. (++) Die Kosten für den WAN/Internet-Datenverkehr überschreiten die Grenze. (-) Die derzeitigen Systeme erfüllen die Anforderungen an den Energieverbrauch nicht. (-) -15

Das Projektbudget wird nicht überschritten. (++) Die Kostengrenze für den WAN/Internet-Datenverkehr wird eingehalten.(+) Die neuen Systeme erfüllen die Anforderungen an den Energieverbrauch. (+)

Das Projektbudget ist gefährdet. (--) Die Kostengrenze für den WAN/Internet-Datenverkehr wird eingehalten.(+) Die neuen Systeme erfüllen die Anforderungen an den Energieverbrauch. (+)

24

22

Der Status Quo ist weit von den zukünftigen Anforderungen entfernt. Die Varianten B und C dagegen erfüllen die meisten Anforderungen, sind bezüglich der Punktsumme sehr ähnlich. Variante B hat rechnerisch den etwas besseren Wert. Besonders ausgezeichnet ist Variante B gegenüber Variante C hinsichtlich des Projektbudgets. Bei Variante C stellt die Option „Neue Notebooks der Oberklasse“ einen erheblichen Kostenblock dar. Variante C kann bei der Skalierbarkeit der Systeme punkten. Deshalb wird Variante B+ (d.h. Variante B, außerdem großzügige Auslegung der Patchfelder und Anschlussdosen) gewählt. Das Projektbudget ist dadurch nicht gefährdet. Nach Auswahl der Lösungsvariante kann nun ein Pflichtenheft (DAN12) erstellt werden. Wir gehen davon aus, dass das geschehen ist.

12.4

Planung

Wie bereits dargestellt, kann das Sicherheitskonzept (PL3) zu einer Revision der Konzepte für das logische (PL1) oder physische Design (PL2) führen.. Im Folgenden sollen wesentliche Eckpunkte der Erstellung des Sicherheitskonzepts bezogen auf den Anwendungsfall vorgestellt werden.

84

Die Summe ergibt sich aus der Summe der Plus- und Minussymbole.

12.4 Planung

12.4.1

185

Sicherheitskonzept

Es ist zunächst eine Risikoanalyse durchzuführen (PL3.1). Zuerst sind die Werte des Unternehmens zu identifizieren. Danach ist eine Analyse der Bedrohungen durchzuführen. Um die Risiken einschätzen zu können, muss Klarheit über die vorhandenen Schwachstellen herbeigeführt werden. Denn Anzahl und Umfang der Schwachstellen sind Parameter, die die Schadenseintrittswahrscheinlichkeit und das Schadensausmaß beeinflussen. Assetidentifizierung Carovalio pflegt mittels SAP ERP sorgfältig das Unternehmensinventar. Aus Sicht des ITIPlaners sind darüber hinaus aber auch Informationsassets von Bedeutung. Mit dem Auftraggeber wurde ein Workshop durchgeführt, um den Schutzbedarf der Assets festzustellen. In Tabelle 56 sind einige Assets mit erhöhtem Schutzbedarf aufgeführt. Tabelle 56: Assets mit erhöhtem Schutzbedarf Objekt Verwaltungszentrale Rechenzentrum SAP-Server Fileserver Domaincontroller Steuerungs-PCs SAP ERP SPS-Software

Vertraulichkeit X X X X

Integrität

X

X X X X X X X

Verfügbarkeit X X X X X X X X

Bedrohungsanalyse Die Norm ISO/IEC 27005 liefert in Anhang C typische Bedrohungen. Sie sind folgenden Klassen zuzuordnen:        

Physischer Schaden Naturereignisse Funktionsunfähigkeit von Infrastruktursystemen Störungen durch Strahlung Kompromittierung von Informationen Technische Fehler Unautorisierte Handlungen Kompromittierung von Funktionen

Ein Workshop mit dem Auftraggeber führte zu folgenden hauptsächlichen Bedrohungen: (B1) Verschmutzungsgefahr im Produktionsbereich (B2) Stromausfall (B3) Spionage via Internet (B4) Manipulation via Internet (B5) Unautorisierte Zugriffe Als erhebliche Schwachstellen (Ist-Zustand) wurden ausgemacht: (S1) Unzureichende Abschottung der Steuerungs-PCs gegenüber der Büro-LAN

186

12 Beispiel für die Planung einer IT-Infrastruktur

(S2) kein Schutz der Steuerungs-PCs gegenüber Umwelteinflüssen (S3) fehlendes Zugriffsberechtigungskonzept (S4) keine systematische Überwachung der IT-Systeme (S5) keine hinreichende Notstromversorgung (S6) veralteter Internetrouter Als inakzeptable Risiken wurden folgende Kombinationen aus Bedrohung und Schwachstelle erkannt: B1/S1; B2/S5; B3/S3; B3/S4; B3/S6; B4/S3; B5/S3 Risikobehandlung Da die gelisteten Risiken als inakzeptabel eingestuft wurden, müssen sie entweder reduziert, vermieden oder transferiert werden. Auftraggeber und Auftragnehmer haben sich darauf geeignet, dass geeignete Maßnahmen zur Reduzierung der Risiken zu finden sind. Zunächst ist zu identifizieren, welche Risiken bereits durch die ausgewählte Lösungsvariante B+ reduziert werden:       

B1/S1: bislang nicht berücksichtigt B2/S5: bislang nicht berücksichtigt B3/S3: hinreichend berücksichtigt B3/S4: bislang nicht berücksichtigt B3/S6: hinreichend berücksichtigt B4/S3: hinreichend berücksichtigt B5/S3: hinreichend berücksichtigt

Es stellt sich also im Rahmen der Risikoanalyse trotz Ist-Analyse und Soll-Aufnahme heraus, dass bestimmte Sicherheitsaspekte von der bisherigen Lösungsvariante nicht hinreichend abgedeckt sind. Die Ergebnisse führen zu einer Lösungsvariante B++, die sich von der Variante B+ wie folgt unterscheidet:   

Verwendung von speziell verkapselten Industrie-PCs im Produktionsbereich Konzept für die Notstromversorgung mittels USV und/oder Notstromaggregat Konzept für die Überwachung der aktiven Netzwerkkomponenten

Dementsprechend sind die Konzepte für das logische und physische Design der ITI anzupassen bzw. zu ergänzen.

12.4.2

Betriebsvorbereitung

Im Rahmen von Arbeitsschritt PL5.1 Servicelevel-Management ist dafür Sorge zu tragen, dass geeignete Dienstgütevereinbarungen mit dem Auftraggeber und internen Einheiten geschlossen werden. Aufgrund der Größe von Tarovalio wird der Abschluss von OLAs als nicht erforderlich angesehen. Grundlage für das neue SLA (DPL15) ist der Servicevertrag vom 28.9.2009. Hier ist insbesondere darauf zu achten, dass die erhöhten Verfügbarkeitsanforderungen dort verankert werden. Auch Anforderungen an die Vertraulichkeit und Integrität sollten redlicherweise thematisiert werden. Wenn DPL15 vorliegt, können Richtlinien und Verfahrensanweisungen (PL5.2) erstellt Überwachungsinstrumente (PL5.3) vorbereitet werden, die die Einhaltung der vereinbarten Service-Levels unterstützen. Zweckmä0ige Bestandteile des Überwachungskonzepts könnten sein:

12.4 Planung  

187

Dokumentationspflicht bei der Wartung der Systeme Einführung eines Syslog85-Servers

Nachdem die Änderungsvorgänge geplant (PL5.4) worden sind und die Realisierung vorbereitet worden ist (PL4), kann mit der Realisierung begonnen werden.

85

IETF-Standard, spezifiziert in RFC 3164

Literatur [BAL1998]

BALZERT, HELMUT

Lehrbuch der Software-Technik, SpektrumAkademischer Verlag, Heidelberg, 1998

[BGH2008]

BOCIJ, P., GREASLEY, A., HICKIE, S.

Business Information Systems, fourth edition, Essex, Pearson Education, Edinburgh, 2008

[BPK2008]

BRANDT-POOK, H., KOLLMEIER, R.

Softwareentwicklung kompakt und verständlich, Vieweg +Teubner, Wiesbaden, 2009

[BRE1994]

BRENNER, W.

Grundzüge des Informationsmanagements, Springer, Berlin/Heidelberg/New York, 1994

[BRU2005]

BRUGGER, R.

IT-Projekte strukturiert realisieren, weg+Teubner, Wiesbaden, 2005

[BSI2008]

BUNDESAMT FÜR SICHERHEIT IN DER INFORMATIONSTECHNIK (BSI)

BSI-Standard 100-1: Managementsysteme für Informationssicherheit (ISMS), Version 1.5, Bonn 2008

[CKS2006]

CHRISSIS, M.B., KONRAD, M., SHRUM S.,

CMMI - Richtlinien für Prozess-Integration und Produkt-Verbesserung, Pearson Education, München, 2006

[EBE1984]

EBERLE, M.

Planung und Realisierung technik-gestützter Informationssysteme, Vandenhoeck + Ruprecht, Göttingen, 1997

[FBS1975]

FISCHBACH, F.

Datenübertragungswege – Planung, Aufbau und Betrieb von Leitungsnetzen und Übertragungseinrichtungen in Datenverarbeitungssystemen, Köln, Rudolf Müller, Köln, 1975

SIMON, O.

Vie-

[GAD2009]

GADATSCH, A.

Grundkurs Geschäftsprozess-Management: Methoden und Werkzeuge für die IT-Praxis, Vieweg +Teubner, Wiesbaden, 2009

[HEI2007]

HEINRICH, G.

Allgemeine Systemanalyse, Oldenbourg, München, 2007

190

Literatur

[ITGI2007]

IT GOVERNANCE INSTITUTE

CobIT 4.1, Framework – Control Objectives Management Guidelines – Maturity Models, Rollling Meadows, 2007

[KST2007]

KRALLMANN, H. SCHÖNHERR, M., TRIER, M.

Systemanalyse im Unternehmen Prozessorientierte Methoden der Wirtschaftsinformatik, Oldenbourg, München, 2007

[OGC2002]

OFFICE OF GOVERNMENT COMMERCE

ITIL, ICT Infrastructure Management, TSO, Norwich, 2002

[OGC2007]

OFFICE OF GOVERNMENT COMMERCE

ITIL, Service Operation, Version 3, TSO, Norwich, 2007

[OGC2009]

OFFICE OF GOVERNMENT COMMERCE

Erfolgreiche Projekte managen mit PRINCE2, TSO, Norwich, 2009

[OLF2009]

OLFERT, K.

Organisation, 15. Auflage, Ludwigshafen, 2009

[OPP2010]

OPPENHEIMER, P.

Top-down network design, 3rd edition, 2010, Indianapolis, Cisco Press, Indianapolis, 2010

[PIL2005]

PILIOURAS, TERESA C.

Network Design - Management and Technical Perspectives, CRC Press, Boca Raton, 2005

[PMI2008]

PROJECT MANGEMENT INSTITUTE

ANSI/PMI 99/001/2008 - A Guide to the Project Management Body of Knowledge (PMBOK Guide), Fourth Edition, Project Management Institute, Newtown Square, 2008

[POM2006]

POWERS, M. K., MCMURRAY, A.

Das MSF-Taschenbuch: Erstellen von ITLösungen, Van Haren Publishing, Zaltbommel, 2006

[PUQ2005]

PULTORAK , D., QUAGLIARIELLO, P.

Das MOF-Taschenbuch. Microsoft Operations Framework: Effizientes Management von Dienstleistungen im IT Betrieb, Van Haren Publishing, Zaltbommel, 2005

[RUD2009]

RUDOLPH, S.

Servicebasierte Planung und Steuerung der ITInfrastruktur im Mittelstand: Ein Modellansatz zur Struktur der IT-Leistungserbringung, Gabler, Gabler, Wiesbaden, 2009

Literatur

191

[SSE2008]

SCHMELZER, H.J., SESSELMANN, W.

Geschäftsprozessmanagement in der Praxis, 6. Auflage, München, 2008

[TEP2005]

TEARE, D., PAQUET, C.

Campus Network Design Fundamentals, Indianapolis, Cisco Press, Indianapolis, 2005

[TUR2006]

TURNER, M.,

Microsoft Solutions Framework Essentials: Building Successful Technology Solutions, Microsoft Press, Redmond, 2006

[WAL2007]

WALTER, H.-C.

Systementwicklung - Planung und Realisierung von Anwendungssystemen, 5. Auflage, Technische Fachhochschule Berlin, 2007

[WLW2002]

WEAVER, P.L., LAMBROU, N., WALKLEY, M.

Practical business systems development using SSADM, Pearson Education, Edinburgh, 2002

[ZHB2005]

ZARNEKOW, R., HOCHSTEIN, A., BRENNER, W.

Serviceorientiertes IT-Management – ITILBest-Practices und -Fallstudien, Springer Verlag, Berlin u.a., 2005

Index Alternativenbewertung 110, 112, 148 Änderungsmanagement 139 Anforderungen 51 Anforderungsanalyse 17, 21, 23 Backend 132 Balanced Scorecard 56, 57, 58, 85 Benchmarking 53 Beschaffung 124, 129, 154 Betriebsaufnahme 135, 157 BPMN-Diagramm 66 Business Alignment 49 Capability Maturity CMM 47 CMMI 48 Checklisten 54, 67, 78, 80, 105, 106, 109, 119, 164 CMDB 137 CObIT 29, 98 Datenübertragungsverfahren 118 Dienstleister 50 Dokumentation 134 EPK-Diagramm 66 Frontend 132 Frozen Zone 162 Gap-Analyse 163 Geschäftsprozess 8 Geschäftsstrategie 49 ICT Infrastructure Management 31 ICTIM 37 Informationssystem 10 Infrastrukturerrichtungsprozess Betriebsvorbereitung 124 Gesamtstruktur 142 Planung 115 Realisierung 127 Realisierungsvorbereitung 123 Rollen 161 Infrastrukturkonzept 34 Integrationstest 131 ISO 9000 5, 18, 45, 87 ISO/IEC 20000 30 Ist-Analyse 27, 104, 147 IT Infrastructure Library 38 ITIL 30, 31, 39, 98 IT-Infrastruktur 9, 11, 12, 15, 40, 50, 190 IT-Netzwerk 11, 12 wIT-Servicemanagement 30

Konfigurationsmanagement 125 Kunde 50, 51, 76 Kundenorientierung 45, 50, 51, 76 Kundenzufriedenheit 87 LAN 120 Lastenheft 21 Logisches Design 117 lokales Netzwerk 11 Machbarkeitsanalyse 21, 33, 111 Microsoft Operations Framework 40 Microsoft Solutions Framework 40 Netzsegmentierung 118 Netzwerkdienste 118 Netzwerkmanagement 118 Netzwerkprotokolle 118 Objektverwaltung 137, 157 Operational Level Agreement 34 PDIOO 43 PDIOO-Zyklus 43, 95 Pflichtenheft 21, 113 Physisches Design 119 PMBoK 18 PRINCE2 17 Programmablaufplan 65 Projekt 41, 189 Sachmittel 89 Projektaufwand 92 Projektdauer 91 Projektmanagement 15, 140 Prozess 5, 9, 31, 40, 49, 50, 51, 55, 56, 57, 58, 77, 78, 86, 168 Analyse 53 Arbeitsschritt 60 Beschreibung 59 Dokumentation 63 Durchlaufzeit 7 Einführung 67 Fehler 160 Hilfsmittel 62 Modellierung 63 Output 88 Perspektiven 57 Planung 55, 58, 148 Prozessverantwortlicher 50, 53, 55 Reifegrad 80 Sachmittel 62 Steuerung 68

194 Struktur 60 Zykluszeit 7 Prozessanalyse 162 Prozessverantwortlicher 61 Qualität 45 Qualitätsmanagement 45 Reifegradmodell 47 Risikoanalyse 122 Risikobehandlung 122 Rollout 126, 132, 156 SAN 120 Schwachstellenanalyse 28, 54, 162 SDLC 96 Service Level Agreement 33 Servicelevel-Management 126 Sicherheit 121, 152 Sicherheitsmaßnahmen 122 Softwareentwicklung 22 Soll-Aufnahme 107, 148 Soll-Konzept 29 Spiralmodell 25, 26 Steuerung 138, 158 SWOT-Analyse 33, 54 System 8, 10, 12, 13

Index abgeschlossen 9 offenes 8 Systemanalyse 26, 96 Ist-Analyse 27 Systemmanagement 119 Systems Development Lifecycle 21 Test 132 Integrationstest 155 Testumgebung 130 Überwachung 137, 138, 158 Unterstützungsprozess 8 Verkabelung 13, 120 Primärverkabelung 13 Sekundärverkabelung 13 strukturierte 13 Tertiärverkabelung 13 V-Modell 24, 97 Vorgehensmodell 9, 15, 20, 40, 41, 115 Wasserfallmodell 20, 97 Weitverkehrsnetz 11, 120 Wirtschaftlichkeitsanalyse 55 Zugangsberechtigungen 119 Zugriffsberechtigungen 119