Optimale Prozessorganisation im IT-Management : ein Prozessreferenzmodell für die Praxis 9783540715580, 3540715584 [PDF]

Zitiervorschau

Optimale Prozessorganisation im IT-Management

Albert Karer

Optimale Prozessorganisation im IT-Management Ein Prozessreferenzmodell für die Praxis

123

Albert Karer [email protected]

ISBN 978-3-540-71557-3 Springer Berlin Heidelberg New York

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. Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2007 Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Herstellung: LE-TEX Jelonek, Schmidt & Vöckler GbR, Leipzig Umschlaggestaltung: WMX Design GmbH, Heidelberg SPIN 12040308

88/3180YL - 5 4 3 2 1 0

Gedruckt auf säurefreiem Papier

Vorwort

Wir schreiben das Jahr 1997. Ort: das Sitzungszimmer eines großen, weltweit tätigen IT-Service-Providers. Anwesend: der Autor (als externer Berater) und ein Mitglied des Managements. Beide kennen sich und wissen, was sie voneinander zu halten haben. Das eigentliche Sitzungsthema ist bereits zur beidseitigen Zufriedenheit abgeschlossen, man befindet sich im Smalltalk und beim Fachsimpeln. Und dann die Frage, die rund 10 Jahre später zu diesem Buch führte: „Wir haben vor ein paar Wochen, wie du ja weißt, ein Business-ProcessRe-Engineering-Projekt gestartet. Wir sind meiner Meinung nach in einer Sackgasse gelandet. Wir kommen irgendwie nicht auf einen gemeinsamen Nenner. Wie würdest du an so eine Sache rangehen?“ Geprägt von den Ideen des Prof. August-Wilhelm Scheer (dem Leser wohl am besten im Zusammenhang mit dem Produkt ARIS bekannt), Unternehmensprozesse und gar ganze Unternehmen in Form von Referenzmodellen zu beschreiben, begann ich an der Wandtafel zu zeichnen. Das Gespräch ging wesentlich länger als geplant. Am Ende stand an der Wandtafel ein erstes rudimentäres Referenzmodell für eine Unternehmung, die Dienstleistungen im IT-Bereich anbietet. Damals gelang dem Projekt damit ein erster Durchbruch, da auf diese Weise die Grundlage für den gesuchten gemeinsamen Nenner geschaffen wurde. Belohnt wurde der Autor mit Umsetzungsprojekten, die er als Auftragnehmer mit seinen Mitarbeitern unterstützen durfte. Auch sprachen sich mit der Zeit unsere Erfolge herum, so dass immer mehr Menschen mit viel Know-how und Erfahrung immer mehr Prozesse zuerst in unternehmensspezifische Referenzmodelle gossen und anschließend ausgewählte Prozesse optimierten und erfolgreich umsetzten. Wichtig war und ist uns hierbei immer, dass es uns gelingt, die beteiligten Menschen zu begeistern und zwar nicht von uns oder der Methodik, sondern von dem Unternehmen, in dem sie arbeiten, denn die meisten lernen so zum ersten Mal ihr Unternehmen in seiner Gesamtheit kennen. Prozesse gestalten bedingt Prozesse zu verstehen. Insbesondere das Verständnis der Zusammenhänge der Prozesse untereinander, die Bedeutung ihrer

VI

Vorwort

Schnittstellen und das Finden einer gemeinsamen Sprache sind Erfolgsfaktoren, wenn es gilt, entsprechende Projekte umzusetzen. Aus dem ehemals rudimentären wurde mit der Zeit ein sehr umfassendes Referenzmodell. Die Herausforderung bei der Gestaltung des Buches lag darin, ausgehend von einem virtuellen Unternehmen ein dazu passendes Prozess-Referenzmodell zu beschreiben, das auf die meisten Unternehmen der IT- und Kommunikationsbranche übertragbar ist. Sicher hätte man an der einen oder anderen Stelle mehr schreiben, mehr Prozesse berücksichtigen können, aber der Überblick hatte immer Vorrang vor dem Detail, in dem man sich so gerne verlieren kann. Das beigelegte Poster ist eine Erfahrung aus der Praxis. Die Visualisierung des Prozess-Referenzmodells auf einer Seite, und wenn diese auch das Format A0 hat, ist für uns immer die Grundlage, die Kommunikation in den Arbeitsgruppen und zum Schluss im gesamten Unternehmen und darüber hinaus in Gang zu setzen, manchmal gar zu erzwingen. Viele von unseren Umsetzungserfahrungen sind in das Buch eingeflossen und ich wünsche mir, dass das eine oder andere auch Sie ein Stück weiterbringt. Wir haben in unseren Projekten gelernt: Projekte umsetzen, Prozesse gestalten, Menschen begeistern, eine Erfolgsformel, die zeitlos ist. Schweiz, Juli 2007

Albert Karer

Dank Korrekterweise müsste hier eine Liste all derjenigen stehen, die in diversen Projekten ihr Know-how und ihre Erfahrungen eingebracht haben. Das Risiko, jemanden zu vergessen, wäre viel zu groß, deswegen pauschal all denjenigen, die in irgendeiner Form an einem unserer Prozessprojekte mitgearbeitet haben: herzlichen Dank! Dank auch den Mitarbeitern der Karer-Gruppe, die nicht nur als Multiplikatoren, Projektleiter und Vorantreiber tätig waren, sondern selbst eine Quelle für die ständige Weiterentwicklung sind und waren, heute als Vorstände, Geschäftsführer, Berater und Projektleiter tagtäglich ihre Frau respektive Mann stehen und Projekte umsetzen, Prozesse gestalten sowie Menschen begeistern. Sodann den guten Geistern, die Texte redigierten, Grafiken zeichneten, meine Launen ertrugen, mich mit Kaffee und Kuchen versorgten und mir sonst irgendwie den Rücken freihielten. Euch allen einfach danke!

Geleitwort

Die IT wird auf der Vorstandsetage zunehmend als „Commodity“ und weniger als „strategische Kernfunktion“ des Unternehmens angesehen. Man hat die Probleme mit der IT, die Verzögerungen und Kostenüberschreitungen bei den Projekten, gründlich satt. Themen wie „Business Process Outsourcing“, „IT is a Commodity“, „Offshoring der Entwicklung“, „Konzentration auf Kernkompetenz“ beherrschen seit geraumer Zeit die Diskussion nicht nur in der Presse, sondern auch in den Geschäftsleitungen der Unternehmen. Worauf ist dieser dramatische Umschwung in den letzten 10 Jahren zurückzuführen? • Die Silostrukturen in den Unternehmen werden zu Gunsten einer Prozess- und Kundenorientierung aufgebrochen. • Die Kunden sind besser informiert, die Kundentreue hat abgenommen. • Die Globalisierung stellt neue Anforderungen an die Flexibilität und Produktivität – und erzeugt einen steigenden Kostendruck. • In der IT steht mit der Verfügbarkeit des Internets, mit dem Preisverfall bei Hardware, Kommunikation und Basissoftware die grundsätzliche Möglichkeit für substanzielle Verbesserungen offen. • „Unsere IT ist nicht in der Lage diese Möglichkeiten auszuschöpfen. Wir kleben an den Altlasten und alles ist so kompliziert.“ Die Zeiten, in denen selbstständige „Applikationen“ auf einem zentralen Host eingesetzt wurden und zwei Mal im Jahr ein Programm-Update gefahren wurde, sind endgültig vorbei. Die Komplexität im IT-Betrieb hat enorm zugenommen durch gemischte Hard- und Software-Plattformen, durch stetige kurzfristige Änderungen, einen Mix von Technologien, aber auch durch neue Bedrohungen und einen Wust von neuen Vorschriften. Auch die Zeiten, in denen einige wenige Mitarbeiter im „Rechenzentrum“ das Ganze im Kopf und im Griff hatten, sind vorbei. Eine Flucht aus dieser Situation zu einem „professionellen Serviceanbieter“ scheint sich geradezu aufzudrängen. Stellen wir uns jedoch zuerst die folgenden Fragen:

VIII

Geleitwort

• • •

Haben wir unser Verbesserungspotenzial ausgeschöpft? Wo stehen wir im Vergleich zum Rest der Welt? Sind wir reif dafür, Leistungen auszusourcen – und wenn ja, welche?

Von der Antwort auf diese Fragen hängt der Erfolg sowohl interner Verbesserungsprojekte als auch eines möglichen Outsourcings ab. Ein Outsourcing ausgehend von einem tiefen Reifegrad (Maturity Level) ist für beide Partner, den Auftraggeber und den Auftragnehmer, ein enormes Risiko und führt zwangsläufig zu Problemen. Als Einstieg in das Thema eignet sich das Process Maturity Framework von ITIL (PMF), das in Anlehnung an CMMI die bekannten fünf Reifegrad-Stufen definiert: Level

PMF

Focus

Comments

1

Initial

Technology

Technology excellence/experts

2

Repeatable

Product/Service

Operational processes (e.g., Service Support)

3

Defined

Customer Focus

Proper service level management

4

Managed

Business Focus

Business and IT aligned

5

Optimized

Value Chain

Seamless integration of IT into the business and strategy making

Als ersten Schritt gilt es, die allgemeine Akzeptanz für solches Assessment und damit die Basis für die weiteren Schritte zu schaffen. Ausgehend von der Kenntnis der Wichtigkeit und des Reifegrades jedes Bereichs können zielgerichtet Maßnahmen für das weitere Vorgehen geplant und durchgeführt werden. Für diese Arbeit benötigt man einen praktikablen Leitfaden. Das vorliegende Buch ist ein solcher Leitfaden, entstanden aus jahrelanger Praxis, in dem die Erfahrung vieler Projekte zu einem Modell eingedampft wurde, dem es gelungen ist, den Abstand sowohl zu einem theoretischen Kommitee-Produkt als auch einem „How-I-did-it“ zu wahren. Das Schwergewicht im Buch liegt auf der Erläuterung eines Referenzmodells für die Prozesse im IT-Betrieb und dessen Umsetzung. 1. Das Referenzmodell dient zunächst zur Beurteilung des Ist-Zustandes und als Grundlage für eine Sprach- und Konzeptbereinigung. Uneinheitlicher Sprachgebrauch ist bekanntlich ein Hauptgrund für Missverständnisse und Probleme, „etablierte Haussprachen“ mögen einen besonderen Reiz haben, erschweren jedoch die Einarbeitung neuer Mitarbeiter oder ein mögliches Outsourcing.

Geleitwort

IX

MetaModell

1

ReferenzModell

2

InstanzModell

Ist-Zustand

3 Instanz 2. Der Abgleich des Ist-Zustandes mit dem Referenzmodell erlaubt die Entwicklung einer Roadmap für die Überführung des Ist-Zustandes in ein dokumentiertes Rahmenwerk. Diese Roadmap definiert konkrete Modelle als Optimierungsziele und erläutert deren Wünschbarkeit (Nutzen, Kosten, Einsparungen, Verbesserungen) und Machbarkeit innerhalb sinnvoller Fristen. Damit werden die Voraussetzungen dafür geschaffen, von den unteren „Initial“-Regionen des Reifegrades zumindest auf die Ebene „Repeatable“ aufzusteigen. 3. Die konsequente Umsetzung des Modells in die tägliche Praxis kann dann anhand dieser Roadmap erfolgen. Damit wird der Reifegrad schrittweise auf einen angemessenen Level angehoben und nachhaltige Verbesserungen können erreicht werden. Der Umfang und Detaillierungsgrad des Buchs dürfen nicht darüber hinwegtäuschen, dass es sich um eine kondensierte Form eines Referenzmodells handelt. Dem kundigen Leser wird nicht entgehen, dass die Herausforderung für den Autor nicht darin bestand, den Stoff zusammenzutragen, sondern vielmehr darin, das nicht unbedingt Notwendige wegzulassen. Das Buch kann ein Wegbegleiter auf der Reise zu einem höheren Reifegrad sein. Allerdings ist es wohl sinnvoll, darüber hinaus den Rat und die professionelle Begleitung zu suchen, die einem so manchen unnötigen Umweg erspart. April 2007

Dr. Reinhold Thurner

Inhaltsverzeichnis

Motivation.............................................................................. 1 Und täglich grüßt das Murmeltier........................................................... 1 Übersicht................................................................................................. 3 Abgrenzung ............................................................................................ 4

Rahmenbedingungen ........................................................... 5 Der Fluch einer Basistechnologie........................................................... 5 Der Zwang zur Produktivitätssteigerung ................................................ 7 Die Stellschrauben .....................................................................................10 Der Lösungsansatz: Schwerpunkt Prozessoptimierung..............................14

ITIL ….................................................................................................. 16 … und andere........................................................................................ 18 BS 15000 / ISO 20000 ................................................................................18 CMMI – Capability Maturity Model Integration .......................................18 CobiT .........................................................................................................19 HP IT Service Management .......................................................................20 MOF Microsoft Operations Framework.....................................................20

Modellkonzept und Methodik............................................. 21 Was ist ein Modell? .............................................................................. 21 Vielfältige Modelle in der täglichen Praxis................................................22 Abgrenzung: Ist-, Soll- und Referenzmodell..............................................24 Anforderungen an ein Prozess-Referenzmodell .........................................29

Das Referenzmodell in der Praxis ........................................................ 31 Das eigene Prozess-Referenzmodell ..........................................................31 Was ein Referenzmodell ist........................................................................32 Was ein Referenzmodell nicht ist...............................................................33

Prozessverständnis................................................................................ 34 Prozessdefinition ........................................................................................34 Schachtelung von Prozessen ......................................................................38 Abgrenzung von Prozessen ........................................................................39

XII

Inhaltsverzeichnis

Ordnungs- und Klassifizierungssystem ................................................ 42 Gliederungsebenen..................................................................................... 42 Nummerierungssystem............................................................................... 45 Die wichtigsten Prozesselemente ............................................................... 46

Grundstrukturen.................................................................................... 48 Struktur des Top-Levels............................................................................. 49 Darstellung von Prozessketten ................................................................... 50 End-to-End-Betrachtung ............................................................................ 54 Leseübung Prozess-Referenzmodell .......................................................... 57 Anglizismen im Prozess-Referenzmodell .................................................. 57

ICT Company....................................................................... 59 Fiktives Unternehmen........................................................................... 59 Die Leistungen / Produkte der ICT Company....................................... 60 Struktur der ICT Company ........................................................................ 63 Kontext der ICT Company......................................................................... 65

Aufbauorganisation .............................................................................. 67 Ein schematisches Modell.......................................................................... 67 Die Aufbauorganisation der ICT Company ............................................... 69 Begriffswelt der ICT Company.................................................................. 71 Weitere Faktoren........................................................................................ 73

Ausgewählte Geschäftsvorfälle......................................... 75 End-to-End-Betrachtung....................................................................... 75 Geschäftsvorfall 1: Kunde kauft PC ..................................................... 76 Geschäftsvorfall 2: Betrieb einer ICT-Infrastruktur ............................. 81 Geschäftsvorfall 3: Individual-Software-Entwicklung......................... 87 Geschäftsvorfall 4: Kunde meldet Störung........................................... 93

Prozessbereiche und Prozesskategorien ......................... 99 Einführung ............................................................................................ 99 Prozessbereich Management .............................................................. 101 ICT Supplier Management....................................................................... 102 ICT Program Management....................................................................... 110 ICT Marketing ......................................................................................... 116 ICT Finance & Controlling ...................................................................... 123 ICT Human Resource Management......................................................... 126 ICT Quality & Risk Management ............................................................ 130

Prozessbereich Sales........................................................................... 139

Inhaltsverzeichnis

XIII

ICT Sales Planning & Execution Management........................................143 ICT Customer Contract Management ......................................................151

Prozessbereich Project & Development ............................................. 159 ICT Project Management .........................................................................164 ICT Consulting & System Development..................................................182 ICT Release Management ........................................................................186

Prozessbereich Support....................................................................... 198 ICT Change Management ........................................................................201 ICT Problem Management .......................................................................212 ICT Configuration Management ..............................................................216

Prozessbereich Operations.................................................................. 229 ICT Operations Planning..........................................................................233 ICT Operations Control Management......................................................241

Prozessbereich Customer Services ..................................................... 248 ICT Customer Services Planning and Monitoring ...................................251 ICT Customer Contact Management........................................................254 ICT On-Site Services ...............................................................................267 ICT Customer Education Management....................................................274

Prozessbereich Logistics & Infrastructure.......................................... 280 ICT Continuity Management ...................................................................281 ICT Methodic Development & Knowledge Management .......................287 ICT Security & Technology Management ...............................................292 ICT Logistics & Facility Management.....................................................298

Anhang .............................................................................. 305 Geschäftsvorfall 1: Kunde kauft PC ................................................... 305 Geschäftsvorfall 2: Betrieb einer ICT-Infrastruktur ........................... 307 Geschäftsvorfall 3: Individual-Software-Entwicklung....................... 310 Geschäftsvorfall 3: Kunde meldet Störung......................................... 313 Prozessliste des ICT-Prozess-Referenzmodells.................................. 315 Prozessbereich 1 Management .................................................................315 Prozessbereich 2 Sales .............................................................................315 Prozessbereich 3 Project & Development ................................................316 Prozessbereich 4 Support .........................................................................316 Prozessbereich 5 Operations ....................................................................317 Prozessbereich 6 Customer Services........................................................317 Prozessbereich 7 Logistics & Infrastructure.............................................318

Ereignisliste ........................................................................................ 319 Schnittstellen zum Kontext................................................................. 340

XIV

Inhaltsverzeichnis

ITIL-Disziplinen im ICT-Prozess-Referenzmodell ............................ 342 FAQs................................................................................................... 344 Literaturhinweise ................................................................................ 352 Glossar ................................................................................................ 358 Abkürzungen............................................................................................ 358 Begriffe .................................................................................................... 359

Abbildungsverzeichnis

Abb. 1. Abb. 2. Abb. 3. Abb. 4. Abb. 5. Abb. 6. Abb. 7. Abb. 8. Abb. 9. Abb. 10. Abb. 11. Abb. 12. Abb. 13. Abb. 14. Abb. 15. Abb. 16. Abb. 17. Abb. 18. Abb. 19. Abb. 20. Abb. 21. Abb. 22. Abb. 23. Abb. 24.

Typische Darstellung eines Ablaufes als Flussdiagramm ........23 Lebenszyklen von Modellen am Beispiel eines Organigramms ..........................................................................24 Position eines Referenzmodells im Lebenszyklus von Modellen...................................................................................27 PC-Bestellprozess, Aufgabenkette ...........................................35 PC-Bestellprozess, erweiterte Aufgabenkette ..........................36 PC-Bestellprozess, erweitert um Ereignisse.............................37 Prinzip der Schachtelung von Prozessen..................................39 Vernetzung des Bestellprozesses..............................................40 Prozessnetzwerk .......................................................................41 Gliederungsebenen ...................................................................42 Darstellung des Top- und des Makro-Levels ...........................43 Vergleich Darstellung Makro-, Mikro-Level ...........................44 Prozesselemente für die grafische Darstellung.........................46 Kontextdiagramm.....................................................................49 Prozessbereiche ICT-Unternehmen (Top-Level) .....................51 Prozessbereiche und ihre Prozesskategorien (Top-Level)........51 Darstellung der Prozess-Verknüpfungen..................................52 Darstellungsform Makro-Level................................................53 Ergänzung mit Leistungen, Rollen und Entscheidungen .........54 Position einer End-to-End-Betrachtung im Modell..................55 Leistungen / Produkte der ICT Company .................................60 Das M.I.S.S.O-Haus, Grundstruktur einer Unternehmung.......64 Erweiterte Grundstruktur der ICT Company............................65 Schnittstellen der ICT Company ..............................................66

XVI

Abb. 25. Abb. 26. Abb. 27. Abb. 28. Abb. 29. Abb. 30. Abb. 31. Abb. 32. Abb. 33. Abb. 34. Abb. 35. Abb. 36. Abb. 37. Abb. 38. Abb. 39. Abb. 40. Abb. 41. Abb. 42. Abb. 43. Abb. 44. Abb. 45. Abb. 46. Abb. 47. Abb. 48. Abb. 49. Abb. 50. Abb. 51. Abb. 52. Abb. 53. Abb. 54. Abb. 55.

Abbildungsverzeichnis

Der Kontext der ICT Company ................................................67 Basismodell der Aufbauorganisation der ICT Company .........69 Organigramm der ICT Company .............................................70 Detailorganigramm der ICT Company.....................................70 Fachbegriffsmodell 1 der ICT Company..................................71 Fachbegriffsmodell 2 der ICT Company..................................72 GV1: Relevanter Ausschnitt Order Management.....................77 GV1: Relevanter Ausschnitt Contract Administration.............78 GV1: Relevanter Ausschnitt Licence Management .................78 GV1: Relevanter Ausschnitt Service Charging........................79 GV1: Relevanter Ausschnitt Distribution Planning .................79 GV1: Relevanter Ausschnitt Material & Inventory Management .............................................................................80 GV1: Relevanter Ausschnitt HW / SW Distribution ................80 GV1: Relevanter Ausschnitt On-Site Dispatching ...................81 GV1: Relevanter Ausschnitt Installation & Relocation Management .............................................................................81 GV2: Relevanter Ausschnitt Sales Management .....................82 GV2: Relevanter Ausschnitt Bid Management ........................82 GV2: Relevanter Ausschnitt Production Planning ...................83 GV2: Relevanter Ausschnitt Contract Definition.....................83 GV2: Relevanter Ausschnitt Contract Administration.............84 GV2: Relevanter Ausschnitt Service Charging........................85 GV2: Relevanter Ausschnitt Production Planning ...................85 GV2: Relevanter Ausschnitt Production Control (1) ...............85 GV2: Relevanter Ausschnitt Output Management...................86 GV2: Relevanter Ausschnitt Production Control (2) ...............86 GV2: Relevanter Ausschnitt Service Charging........................86 GV2: Relevanter Ausschnitt Contingency Planning ................87 GV3: Relevanter Ausschnitt Sales Management .....................88 GV3: Relevanter Ausschnitt Bid Management ........................88 GV3: Relevanter Ausschnitt Project Planning .........................89 GV3: Relevanter Ausschnitt Program Planning.......................89

Abbildungsverzeichnis

Abb. 56. Abb. 57. Abb. 58. Abb. 59. Abb. 60. Abb. 61. Abb. 62. Abb. 63. Abb. 64. Abb. 65. Abb. 66. Abb. 67. Abb. 68. Abb. 69. Abb. 70. Abb. 71. Abb. 72. Abb. 73. Abb. 74. Abb. 75. Abb. 76. Abb. 77. Abb. 78. Abb. 79. Abb. 80. Abb. 81. Abb. 82. Abb. 83. Abb. 84. Abb. 85.

XVII

GV3: Relevanter Ausschnitt Bid Management ........................90 GV3: Relevanter Ausschnitt Contract Definition.....................90 GV3: Relevanter Ausschnitt Contract Administration.............90 GV2: Relevanter Ausschnitt Service Charging........................90 GV3: Relevanter Ausschnitt Approval Procedure ...................91 GV3: Relevanter Ausschnitt Project Planning .........................91 GV3: Relevanter Ausschnitt System Development .................92 GV3: Relevanter Ausschnitt Operations Acceptance Test.......92 GV3: Relevanter Ausschnitt Project Finalisation.....................93 GV4: Relevanter Ausschnitt Contact Management (1)............93 GV4: Relevanter Ausschnitt Incident Management.................94 GV4: Relevanter Ausschnitt Problem Handling ......................94 GV4: Relevanter Ausschnitt Error Control ..............................95 GV4: Relevanter Ausschnitt Change Handling........................95 GV4: Relevanter Ausschnitt Release Planning ........................96 GV4: Relevante Ausschnitte Entwicklung bis ReleasePackage Bildung.......................................................................96 GV4: Relevanter Ausschnitt Release Package Management .............................................................................97 GV4: Relevanter Ausschnitt Error Control ..............................97 GV4: Relevanter Ausschnitt Contact Management (2)............97 Die Prozessbereiche und ihre Prozesskategorien .....................99 Darstellung der Prozesskategorien und ihre Verknüpfungen.......................................................................100 Der Prozessbereich Management ...........................................102 ICT Supplier Management .....................................................104 ICT Program Management.....................................................111 ICT Marketing........................................................................117 ICT Finance & Controlling ....................................................124 ICT Human Resource Management .......................................127 ICT Quality & Risk Management ..........................................131 Prozessbereich Sales...............................................................142 ICT Sales Planning & Execution Management......................143

XVIII

Abbildungsverzeichnis

Abb. 86. ICT Customer Contract Management ....................................152 Abb. 87. Prozessbereich Project & Development .................................163 Abb. 88. ICT Project Management .......................................................165 Abb. 89. ICT Consulting & System Development Management..........183 Abb. 90. ICT Release Management ......................................................187 Abb. 91. Prozessbereich Support ..........................................................198 Abb. 92. ICT Change Management ......................................................202 Abb. 93. ICT Problem Management .....................................................212 Abb. 94. Konfiguration Erläuterung 1 ..................................................217 Abb. 95. Konfiguration Erläuterung 2 ..................................................218 Abb. 94. ICT Configuration Management ............................................223 Abb. 97. Prozessbereich Operations .....................................................231 Abb. 98. ICT Operations Planning........................................................234 Abb. 99. ICT Operations Control Management....................................242 Abb. 100. Prozessbereich Customer Services.........................................250 Abb. 101. ICT Customer Services Planning and Monitoring .................252 Abb. 102. ICT Customer Contact Management......................................255 Abb. 103. ICT On-Site Services .............................................................267 Abb. 104. ICT Customer Education Management ..................................274 Abb. 105. Prozessbereich Logistics & Infrastructure .............................280 Abb. 106. ICT Continuity Management .................................................282 Abb. 107. ICT Methodic Development & Knowledge Management .....288 Abb. 108. ICT Security & Technology Management .............................293 Abb. 109. ICT Logistics & Facility Management...................................299 Abb. 110. Geschäftsvorfall Kunde kauft PC, Teil 1 ...............................305 Abb. 111. Geschäftsvorfall Kunde kauft PC, Teil 2 ...............................306 Abb. 112. Geschäftsvorfall Betrieb einer ICT-Infrastruktur, Teil 1 .......307 Abb. 113. Geschäftsvorfall Betrieb einer ICT-Infrastruktur, Teil 2 .......308 Abb. 114. Geschäftsvorfall Betrieb einer ICT-Infrastruktur, Teil 3 .......309 Abb. 115. Geschäftsvorfall Individual-Software-Entwicklung, Teil 1 .....310 Abb. 116. Geschäftsvorfall Individual-Software-Entwicklung, Teil 2 .....311 Abb. 117. Geschäftsvorfall Individual-Software-Entwicklung, Teil 3 ......................................................................................312

Abbildungsverzeichnis

XIX

Abb. 118. Geschäftsvorfall Kunde meldet Störung, Teil 1 .....................313 Abb. 119. Geschäftsvorfall Kunde meldet Störung, Teil 2 .....................314 Abb. 120. Schnittstellen Kunde – ICT-Prozess-Referenzmodell (ICT Company) ......................................................................341 Abb. 121. Schnittstellen Lieferant – ICT-Prozess-Referenzmodell (ICT Company) ......................................................................341 Abb. 122. Ausgewählte ITIL-Disziplinen...............................................342 Abb. 123. Position ITIL-Disziplinen im ICT-ProzessReferenzmodell ......................................................................343

Motivation

Und täglich grüßt das Murmeltier In der Filmkomödie: Und täglich grüßt das Murmeltier sitzt Phil Connors in einer Zeitschleife. Er durchlebt albtraumhaft wieder und wieder denselben Tag. In dem Ort, in dem er sich aufhält, Punxsutawney / Pennsylvania, begeht man diesen Tag als den „Tag des Murmeltiers“. Diese moderne Fabel zu der Frage, welchen Nutzen das eigene Wissen und die eigenen Fähigkeiten für andere haben können, kam uns genau in dem Moment in den Sinn, als der Entschluss fiel, das vorliegende Buch zu schreiben. Seit den frühen 1990er Jahren setzen wir uns intensiv mit der Frage der optimalen Organisation von Unternehmungen bzw. Unternehmenseinheiten, die Leistungen im Bereich der Informationstechnologie und der Kommunikation erbringen, in der Folge kurz: ICT (Information Communication & Technology), auseinander. Die bis Anfang der 1980er Jahre dominierende zentral ausgerichtete IT-Infrastruktur sowie die damit verbundene Ablauforganisation waren überschaubar. Innerhalb kurzer Zeit hat sich dies für sämtliche Organisationen aber zu einem verteilten, komplexen, schwer überschaubaren und aus einer scheinbar unendlichen Vielzahl von Einzelkomponenten bestehenden elektronischen Nervensystem entwickelt. Neben einer wahren Explosion auf technologischer Basis musste eine Vielzahl neuer organisatorischer Abläufe erfunden, entwickelt und implementiert werden. Die Entwicklung war und ist hier nicht weniger dynamisch. Die organisatorischen Abläufe bzw. Prozesse wiederum unterliegen einem Lebenszyklus. Dieser gewährt eine ständige Anpassung an die sich ebenfalls ständig ändernden Anforderungen, die an die Unternehmen im Allgemeinen und an ICT-Organisationen im Speziellen gestellt werden. In der täglichen Praxis erleben wir, wenn es um das Thema Prozessorganisation1 / Prozessoptimierung in ICT-Unternehmungen bzw. ICT-Orga1

Hier wird zum ersten Mal der Begriff „Prozess“ verwendet. In diesem Kapitel reicht als Definition primär das Verständnis, einen Prozess als eine geregelte Abfolge von Aktivitäten aufzufassen.

2

Motivation

nisationen geht, immer wieder unseren eigenen „Tag des Murmeltiers“. Fast schon albtraumhaft erleben wir, dass wir mit einer Vielzahl von Ablauf- und Prozessbeschreibungen konfrontiert werden. Diese stammen aus den unterschiedlichsten Sichten, sind mit unterschiedlichstem Detaillierungsgrad beschrieben, in den unterschiedlichsten Systemen abgebildet und sie verfolgen eine Vielzahl von „Strategien“, wie etwa den Anforderungen eines Qualitäts-Management-Systems oder des Sarbanes-Oxley Acts2 zu genügen. Unser „Tag“ endet dann immer wieder mit der gleichen Erkenntnis: Niemand hat wirklich einen Überblick über die Zusammenhänge der Prozesse in seiner ICT-Unternehmung, in seiner ICT-Organisation. Der Überblick geht in der Detailbetrachtung und der Vielfalt verloren, die Konsequenzen sind tagtäglich spürbar: • Parallel laufende Aktivitäten, die sich mit den gleichen Aufgabenstellungen beschäftigen. • Gut gemeinte Änderungen bzw. Prozessoptimierungen verbessern zwar den „bearbeiteten Teil“, haben aber nicht die gewünschten Auswirkungen in anderen Bereichen. • Die handelnden Personen reden aneinander vorbei, da sie Problemstellungen nicht aus der Gesamtsicht, sondern immer nur aus Teilsichten heraus sehen. Nur drei Beispiele von vielen. Bedenklich wird es, wenn dann auch noch das Verständnis dafür fehlt, warum eigentlich die Zusammenhänge bekannt sein sollten. Im Rahmen eines Projektes bei einem der führenden Dienstleistungsunternehmen der Kommunikationsbranche haben wir verschiedene Organisationseinheiten, die im Rahmen einer „Prozesskette“ nacheinander tätig sind, über die Input- und Output-Qualität der jeweils mitgelieferten Daten 2

Der Sarbanes-Oxley Act of 2002 (SOX) ist ein US-Gesetz zur Verbesserung der Unternehmensberichterstattung in Folge der Bilanzskandale von Unternehmen wie Enron oder Worldcom. Benannt wurde es nach seinen Verfassern, dem Senator Paul S. Sarbanes und dem Abgeordneten Michael Oxley. Ziel des Gesetzes ist es, das Vertrauen der Anleger in die Richtigkeit der veröffentlichten Finanzdaten von Unternehmen wiederherzustellen. Das Gesetz gilt für inländische und ausländische Unternehmen, die an US-Börsen gelistet sind, sowie für ausländische Tochterunternehmen börsennotierter amerikanischer Gesellschaften. Im Rahmen der Section 404 des Sarbanes-Oxley Acts müssen Unternehmensprozesse beschrieben, definiert und Kontrollverfahren festgelegt werden, die das Risiko eines falschen Bilanzausweises minimieren sollen.

Übersicht

3

befragt. Das Ergebnis war unisono: Die Input-Daten wurden mit unzureichender und schlechter Qualität, die Output-Daten, also die Daten, die man selbst erzeugt und weitergibt, als optimal und mit guter bis sehr guter Qualität bewertet. Kein Einzelfall, tagtägliche Praxis! Gelebtes Unverständnis der Zusammenhänge. Mit den Jahren und den sich im Kern immer wiederholenden Problemstellungen der Prozessgestaltung für eine ICT-Unternehmung bzw. einer ICT-Organisation konnten wir für uns ein umfassendes Prozessmodell entwickeln. Dieses Modell setzen wir heute in der Praxis erfolgreich als Referenzmodell ein. Damit können wir einerseits die wesentlichsten Geschäftsvorfälle und die damit verbundenen Prozessketten identifizieren und andererseits die Zusammenhänge transparent darstellen. Dadurch gelingt es uns, in der täglichen Praxis die tatsächliche Situation gegen eine Referenz zu spiegeln und die oben beschriebene Endlosschleife zu unterbrechen. Die pragmatische und erfolgreiche Umsetzung in Form von klar abgegrenzten Projekten ist anschließend nur noch der nächste logische Schritt. Das Referenzmodell ist Mittelpunkt und Inhalt dieses Buches.

Übersicht Fachbücher lesen sich selten wie ein guter Roman: fesselnd von der ersten Seite bis zum Schluss. Blättern und einzelne Sachverhalte lesen, sich einen Überblick schaffen, dann das Buch weglegen und bei einem gegebenen Anlass wieder hervorholen entspricht wohl eher den Tatsachen. Wenn Sie nun also losblättern, dann werden Sie mit hoher Wahrscheinlichkeit schon das „Poster“ gefunden haben. Allein wegen der Größe fällt es aus dem Buch. Verlieren Sie es nicht, denn hierum geht es schlussendlich. Es handelt sich um die grafische Darstellung des Referenzmodells. Erschrecken Sie nicht, es ist einfacher zu lesen, als es auf den ersten Blick erscheint. In dem anschließenden Kapitel Rahmenbedingungen gehen wir kurz auf die Faktoren ein, die die permanente Optimierung von Prozessen bedingen und beeinflussen. Im Kapitel Modellkonzept & Methodik finden Sie die Beschreibung der Methoden und Techniken, die wir verwenden. Sicherlich nichts Unbekanntes, eher vielleicht ein wenig ungewohnt im Sinne der Kombination und des verwendeten Ansatzes. Das Referenzmodell bildet die Prozesse für ein fiktives Unternehmen der ICT-Branche ab. Dieses fiktive Unternehmen ist im Kapitel ICT Com-

4

Motivation

pany beschrieben. Es ist zwar nicht zwingend notwendig, diese Inhalte zu lesen, macht es Ihnen aber einfacher, das Referenzmodell in einem gewissen Kontext zu interpretieren. Vier ausgewählte Geschäftsvorfälle, die eine End-to-End-Betrachtung im Sinne von „Kunde erteilt einen Auftrag“ bis „Kunde erhält die damit verbundene Leistung“ beinhalten, sind im Kapitel Ausgewählte Geschäftsvorfälle beschrieben. Sie dienen als roter Faden, anhand dessen Sie den Verlauf der Aktivitäten der einzelnen Prozesse im Referenzmodell nachvollziehen können. Das Kapitel Prozessbereiche & Prozesskategorien ist der umfangreichste Teil des Buches. Es beschreibt in kurzer Form die Bereiche des Referenzmodells und unterlegt die grafischen Gesamtdarstellungen mit weiteren Informationen.

Abgrenzung Das Buch erhebt den Anspruch, die Gesamtzusammenhänge der wichtigsten Prozesse innerhalb einer ICT-Organisation aufzuzeigen. Dies hat zur Folge, dass eine Vielzahl komplexer Themengebiete berührt wird. Damit stellte sich für uns die Aufgabe, einerseits nicht zu oberflächlich zu bleiben, andererseits sich aber auch nicht im Detail zu verlieren. Das Referenzmodell ist in den letzten 10 Jahren im Rahmen einer Vielzahl von Projekten entstanden. Es war immer die Grundlage für anschließende und darauf basierende Umsetzungsprojekte, in denen Prozesse optimiert bzw. bestehende Lösungen, meist auch Applikationen, abgelöst wurden. Es ist ein Werk von Praktikern für Praktiker. Für jedes der angesprochenen Teilgebiete und Themenbereiche wie z.B. den Verkauf, das Projekt-Management, die Software-Entwicklung, das Supply-Chain-Management etc. gibt es eine umfassende Sammlung von Fachliteratur, die sich mit allen Facetten des jeweiligen Themas beschäftigt. Wir behandeln diese Themengebiete inhaltlich und fachlich jeweils nur oberflächlich, stellen aber dafür die wesentlichsten Prozessaktivitäten im Gesamtzusammenhang dar. Hier ist aus unserer Sicht weniger mehr und wir verweisen im Anhang auf eine Auswahl weiterführender bzw. ergänzender Fachliteratur. An den Leser stellt das Buch die Anforderung, gewisse Grundkenntnisse bezüglich der Aufgaben und Organisation von Unternehmen oder Organisationen zu haben, die ICT-Leistungen erbringen.

Rahmenbedingungen

Der Fluch einer Basistechnologie Es ist unbestritten, dass die ICT (Information & Communication Technology) schon seit Jahren, und in Zukunft noch wesentlich ausgeprägter, eine breit eingesetzte Basistechnologie für jede Unternehmung darstellt. Selbst Kleinstunternehmen nutzen heute Internet, E-Mail-Kommunikation, computerbasierte Verwaltungssysteme und programmierbare Produktionsmaschinen, um nur einige Beispiele zu nennen. Großunternehmen, ob Dienstleistungsunternehmen wie Banken und Versicherungen, Transportunternehmungen wie Bahn und Fluggesellschaften, Industrieunternehmen vom Serienfertiger bis zum Anlagenbauer oder staatliche Einrichtungen wie Steuerbehörden und Verwaltungen aller Art, können heute ohne den Einsatz von ICT-Lösungen ihre Aufgaben nicht mehr erfüllen. Für die Entwicklung, Produktion und den Betrieb von ICT-Lösungen entwickelte sich in den letzten Jahrzehnten weltweit eine riesige Branche von Hard- und Software-Herstellern, Telekommunikationsunternehmen, IT Service Providern und IT-Beratern. In den Unternehmen selbst entstanden, abhängig von der Firmengröße, mehr oder weniger große ICT-Abteilungen, die oftmals mehrere hundert Mitarbeiter umfassen. Je nach Organisationsform konzentrieren sich diese auf einige wenige Organisationseinheiten oder sind über das gesamte Unternehmen verteilt. In den letzten Jahren sind viele Unternehmen dazu übergegangen, Teile ihrer Informatik- und Kommunikationseinheiten auszugliedern, sei es in Form eines Outsourcings an eine Fremdfirma oder in Form einer Verselbstständigung, wobei die Verselbstständigung quasi der Ausgründung in ein dem Unternehmen zukünftig sehr nahe stehendes Softwarehaus oder einen IT Service Provider entspricht. Ob Klein- oder Großunternehmen, der Management-Aufwand und die Kosten für die Entwicklung und den Betrieb der ICT-Lösungen liegen in einer beachtenswerten Größenordnung. Die Planung, Steuerung und Kontrolle der ICT-Budgets ist heute zu einer nicht mehr wegzudenkenden Manage-

6

Rahmenbedingungen

mentaufgabe geworden. Weitreichende Unternehmensentscheidungen von der Produktentwicklung, der Anpassung der Organisation bis hin zu Fusionsvorhaben – alle haben einen ICT-Aspekt, den es zu berücksichtigen gilt. Selbst Aufsichtsräte müssen aufgrund der oftmals recht hohen Investitionskosten und der mit den Vorhaben verbundenen Risiken damit rechnen, dass sie für das Scheitern von ICT-Projekten zur Verantwortung gezogen werden, da sie evtl. ihre Aufsichtspflicht nicht ausreichend wahrgenommen haben. Das scheint der Fluch dieser Basistechnologie zu sein: Ohne sie geht es nicht, die Abhängigkeiten erscheinen unüberschaubar und die damit verbundenen Risiken – insbesondere in der Langzeitbetrachtung – sind oftmals nur schwer einschätz- und kontrollierbar. Nur eins scheint sicher: Die zu erbringenden Aufwände sind beträchtlich. Das Management von ICT-Organisationen, unabhängig davon, ob es sich hierbei um am freien Markt agierende ICT-Unternehmen oder um interne Organisationseinheiten handelt, ist schon lange keine Aufgabe mehr, die zwingend eine Ingenieur- oder eine Informatikausbildung voraussetzt. Die heutigen und zukünftigen ICT-Organisationen entsprechen organisatorisch einem komplexen und kostenintensiven Produktionsunternehmen mit zwei wesentlichen Wertschöpfungsketten. Die erste beinhaltet die Entwicklung und die Bereitstellung von ICTLösungen. Das umfasst so einfache Aufgaben wie die Beschaffung eines PCs und dessen Installation und so vielschichtige Vorhaben wie allgemeine Konzeptions- und Beratungsleistungen oder die spezifische Entwicklung einer individuellen Softwarelösung. Die zweite umfasst den Betrieb und den Unterhalt der eingesetzten ICTLösungen. Dies reicht von der Bereitstellung eines Kundenservices bis hin zum Betrieb komplexer Rechenzentrenstrukturen, Netzwerke und Kommunikationssysteme. Die Organisation von Informatik- und Kommunikationsbereichen bzw. Unternehmen unterliegt aufgrund der schnellen technologischen Entwicklung einem stetigen Wandel und im Vergleich zu anderen Bereichen einem höheren Veränderungsdruck. Während in der Vergangenheit die Technik im Vordergrund stand und zweifelsohne auch weiterhin der Treiber für die zukünftige Entwicklung ist, rücken immer mehr organisatorische Fragestellungen in den Vordergrund, denn losgelöst von der Technik treten immer wieder die gleichen von der Technologie unabhängigen Problemstellungen auf.

Der Zwang zur Produktivitätssteigerung

7

Hier liegen die entscheidenden Ansätze für Optimierung und Produktionssteigerung in den Bereichen Informatik und Kommunikation. Sie finden sich in der Gestaltung der Ablauforganisation. Den Gesetzmäßigkeiten, die sich durch die technische Weiterentwicklung ergeben, ist jede Unternehmung mehr oder weniger ausgeliefert. Die Gestaltung der Organisation hingegen liegt vollständig in der Hand des Unternehmers und seines Managements.

Der Zwang zur Produktivitätssteigerung Das primäre Ziel einer Unternehmung ist die Erwirtschaftung von Gewinn. Bei Non-Profit-Organisationen steht zwar nicht der monetäre Gewinn im Vordergrund, aber auch hier gilt, dass mit den eingesetzten Mitteln die höchstmögliche Leistung zu erbringen ist. Die Leistungsfähigkeit einer Unternehmung, einer Unternehmenseinheit, einer Maschine oder eines Mitarbeiters wird in Form der Produktivität gemessen. Die Produktivität beschreibt das Verhältnis zwischen dem geleisteten Aufwand und dem erzielten Erfolg. Eine Vielzahl von Gründen wie z.B. die Erwirtschaftung eines angemessenen Gewinns, eine angestrebte Gewinnsteigerung, Konkurrenz- und Margendruck, Bewahrung der Wettbewerbsfähigkeit oder auch Markteintritts- oder Erweiterungsstrategien zwingen Unternehmen und selbst ganze Volkswirtschaften dazu, ständig ihre Produktivität steigern zu müssen. Die Verantwortung des ICT-Managers bzw. des Unternehmers liegt darin, die richtige Balance zu finden zwischen der ständigen Optimierung der Leistung und des damit verbundenen Aufwandes und des realisierten Erfolges. Dieser muss sich nicht nur monetär ausdrücken, sondern kann z.B. auch in neuen Produkten, höheren Marktanteilen, neuen Märkten etc. seinen Ausdruck finden. Eine kurzfristige Schwerpunktbildung (Sparbremse, Investitionsschub) ist akzeptabel. Eine mittelfristige Strategie muss aber eine Balance beinhalten, ansonsten verliert das Unternehmen schnell an Wettbewerbsfähigkeit und Perspektive. Die Informations- und Kommunikationstechnologien haben in den letzten Jahren durch eine ständige Erweiterung der technischen Möglichkeiten und die Verbesserung der technischen Grundlagen viel dazu beigetragen. Die Unternehmen haben in diesen Bereichen hohe Investitionen getätigt.

8

Rahmenbedingungen

Die Organisationseinheiten, die sich mit der Entwicklung und der Einführung von Informatik- und Kommunikationslösungen sowie deren Unterhalt und Betrieb beschäftigen, sind bezüglich Personalbestand und Budgetbedarf stetig gewachsen. Spätestens seit der Bewältigung der Jahr-2000-Umstellung, dem Zusammenbruch des Dot-Com-Hypes und der sich anschließenden Flaute in der Weltwirtschaft sind die ICT-Bereiche der Unternehmen sowie die ganze Branche selbst in den Fokus der Optimierung geraten. Sie stehen unter einem starken Druck, grundsätzlich die Produktivität ihrer Organisationen und der von ihnen eingesetzten Mittel zu erhöhen. Die allgemeine Definition der Produktivität1 ist einfach: Produktivität bezeichnet das Verhältnis von Aufwand zu Erfolg. Hierbei bestimmt natürlich die erbrachte Leistung, das erstellte Produkt, welcher Art der geleistete Aufwand und wie der Erfolg definiert ist. Eine einfache Definition bzw. Erklärung des Aufwandes sind die Kosten, die für die Erbringung einer Leistung bzw. die Herstellung eines Produktes anfallen. Natürlich gibt es auch andere Kriterien, die einen Aufwand beschreiben können wie z.B. benötigte Arbeitsstunden, Produktionsdauer, Materialbedarf etc. Diese werden aber, bei einer rein finanziellen Betrachtung, eher als eine weitergehende Aufschlüsselung von Kostenfaktoren interpretiert. Der Erfolg wird am Ausstoß gemessen. Analog zu den Kosten steht hier bei einer rein monetären Betrachtung primär die Wertschöpfung2 im Vordergrund. Dies ist bei der End-to-End-Betrachtung eines Herstellungsprozesses noch relativ einfach nachvollziehbar, aber auf Teilbetrachtungen und damit auf Zwischenprodukte nicht immer einfach anwendbar. Hierzu ein einfaches (konstruiertes) Beispiel. Wir montieren und produzieren PCs. Auf der Aufwandsseite werden benötigt: diverse Hard- und Software sowie die Arbeitszeit für den Zusammenbau, die Installation der 1

In der Volkswirtschaftslehre wird unter Produktivität das (Mengen-)Verhältnis zwischen dem, was produziert wird (Output), und den dafür beim Produktionsprozess eingesetzten Mitteln verstanden. Diese einfache Definition ist für die folgenden Ausführungen ausreichend.

2

Differenz zwischen dem Marktwert der Komponenten (Rohstoffe), die für die Herstellung, Bearbeitung eines Produktes / Objektes verwendet werden, und dem des fertigen Produkts.

Der Zwang zur Produktivitätssteigerung

9

Software und ein Test des Systems. Außerdem haben wir eine Produktionsdauer, die mit der Auftragserteilung beginnt und mit der Verpackung des Produktes endet. Da die Produktionsdauer Warte- und Liegezeiten beinhaltet, kann sie größer sein als die effektiv geleistete Arbeitszeit. Mit fiktiven Zahlenwerten versehen könnte die Kalkulation wie folgt aussehen: Materialkosten Hardware Materialkosten Software Montageaufwand (in Stunden) Installationsaufwand Testaufwand Endabnahme Verpackungsmaterial Gesamtkosten Produktionsdauer Verkaufpreis (gemäß Preisliste)

1 000 € 500 € 3 Stunden à 40 € 120 € 2 Stunden à 40 € 80 € 2 Stunden à 40 € 80 € 50 € 1 830 € 76 Stunden 2 830 €

Eine ganz simple Betrachtung der Tabelle zeigt uns, dass die Wertschöpfung (Verkaufpreis – Gesamtkosten) 1 000 € beträgt. Es gibt zwei offensichtliche Ansatzpunkte für eine Produktivitätssteigerung: Preiserhöhung oder Kostenreduktion. Kostenreduktionen sind in zwei Bereichen möglich: zum einen auf der Ebene der Materialkosten, zum anderen beim Arbeitsaufwand. Ein bezüglich seiner Wirkung nicht so offensichtlicher Ansatzpunkt ist der Einfluss auf die Produktionsdauer. Hier stellt sich die Frage, welche Konsequenzen die Verkürzung bzw. Verlängerung der Produktionsdauer hat. Nimmt sie Einfluss auf die Qualität und damit direkt auf die Kundenzufriedenheit oder erhöht bzw. mindert sie den Aufwand für Garantieleistungen? Ist sie ein Wettbewerbsvor- oder Nachteil? Das sind Fragen, die sich aus dieser einfachen Betrachtung heraus nicht beantworten lassen. Nur ein fiktives Beispiel hierzu: Angenommen, der Abnehmer unseres oben kalkulierten PCs wäre bereit, z.B. 200 € dafür zu zahlen, dass er den bestellten PC bereits nach 24 Stunden erhält, würde sich rechnerisch gesehen eine entsprechende Steigerung der Wertschöpfung ergeben. Allerdings müssten die Kosten, die für einen entsprechenden „24-Stunden-Service“ anfallen, dagegengestellt werden. Die Leistungen und Produkte von ICT-Unternehmen sind, bis auf die Hardware-Herstellung und Montage sowie wenige Ausnahmen, komplexe Dienstleistungen, die z.T. durch einen hohen Personalaufwand charakterisiert sind. Typisch für sie ist, dass die zugrunde liegenden Prozesse viel-

10

Rahmenbedingungen

schichtig, verzweigt und dadurch oftmals für alle Beteiligten kompliziert und unübersichtlich sind. Somit ist das Risiko gegeben, dass sich eine partielle Produktivitätsverbesserung im Gesamtzusammenhang ins Gegenteil verkehrt. Die Kenntnis über die ICT-relevanten Prozesse einer Unternehmung, ihre internen und externen Schnittstellen, ihren Einfluss auf die objektiv erbrachte und vom Kunden subjektiv wahrgenommene Leistung bildet die Grundlage für ein systematisches Vorgehen zur Produktivitätssteigerung.

Die Stellschrauben Es gibt eine Reihe von Faktoren, die auf die Produktivität Einfluss nehmen. So kann allgemein gesagt werden, dass alle Maßnahmen, die den Aufwand reduzieren, gleichzeitig die Produktivität positiv beeinflussen. Dies gilt aber nur, und dieser Satz wird gerne überlesen, wenn das Endprodukt gleichwertig oder gar höherwertiger ist. Wenn Sie also als Produzent „billigeres Rohmaterial“ kaufen und dafür Ihre Garantieleistungen stärker in Anspruch genommen werden und / oder Ihre Ausschussrate steigt, glaubt bald nur noch die Einkaufsabteilung, dass sie einen guten Job gemacht hat. Neben diesen vielen kleinen Einflussfaktoren mit oftmals überraschend großen Wirkungen sehen wir eigentlich drei wesentliche Stellschrauben, mit denen sich die Produktivität maßgeblich beeinflussen lässt. Es sind diese: • der Mensch • die Technologie • die Prozessorganisation Alle drei Stellschrauben finden sich auf der sich ständig nach oben bewegenden Produktivitätsspirale und haben die Besonderheit, sich gegenseitig zu beeinflussen. Ein Seitenhieb sei noch erlaubt: Das Thema Aufbauorganisation an sich ist keine Stellschraube für die Produktivität und entspricht im Wesentlichen dem Faktor Mensch.

Der Zwang zur Produktivitätssteigerung

11

Der Mensch Wer kennt nicht die zahllosen Beispiele, in denen Einzelne oder eine Gruppe von Menschen trotz schlechter Ausgangslage Außergewöhnliches vollbracht haben. Oder im Gegensatz dazu, wo trotz hervorragender Rahmenbedingungen Menschen die in sie gesetzten Erwartungen nicht erfüllen konnten. Typische Beispiele finden sich im Sport: Fußballmannschaften mit besten Rahmenbedingungen und Topkader erzielen ein durchschnittliches Saisonergebnis. Die Meisterschaft gewinnt eine billige Provinzmannschaft, bestehend aus so genannten No-Names. Analysiert man den Erfolg bzw. Misserfolg, treten hauptsächlich so genannte Softfacts wie Motivation, die Devise „alle für einen“, eine positive Stimmung, der Glaube an den Erfolg und die eigenen Fähigkeiten etc. auf. Auf Unternehmen übertragen gilt das Gleiche: Je höher die Motivation der Mitarbeiter, je besser die Stimmung im Unternehmen, desto höher ist die Einflussnahme jedes einzelnen Mitarbeiters auf die Produktivität. Und was das Wichtigste ist: Die positive Stimmung spüren auch die Kunden! Motivation, positive Stimmung und optimale Softfacts sind zwar wichtig, aber nicht allein entscheidend. Zurück zu unserem Sportbeispiel: Die typischen Provinzmannschaften, die einmal eine Meisterschaft gewonnen haben, haben in der Regel nicht die Substanz regelmäßig Erfolge zu generieren. Die „großen“ Vereine haben vielleicht mal eine schlechte Saison – vielleicht gerade, weil die Softfacts nicht stimmten – über einen längeren Zeitraum betrachtet, erwirtschaften sie aufgrund ihrer besseren Rahmenbedingungen mehr Erfolge. Der Faktor Mensch in der Arbeitswelt ist ein weites Feld, so dass wir es hier an dieser Stelle auf seiner Erwähnung beruhen lassen und auf die umfassende Literatur, die es hierzu gibt, verweisen. Die Technologie Eine typische Rahmenbedingung, die die Produktivität beeinflusst, ist der Hardfact „Technologie“. Ihr Team kann noch so gut ausgebildet und noch so hoch motiviert sein, wenn die eingesetzte Maschinerie bzgl. ihrer Leistungsfähigkeit hinter der der Konkurrenz zurückbleibt, bleiben Sie über kurz oder lang auch zurück. Entsprechend schnell dreht sich die Technologieschraube in den Unternehmen. Insbesondere im IT- und Kommunikationsbereich haben wir heute extrem kurze Halbwertszeiten. Da in den letzten Jahren die Vernetzung

12

Rahmenbedingungen

dieser Basistechnologien mit Maschinen aller Art – von der Nähmaschine über das Auto bis zum Schweißroboter – weit fortgeschritten ist, sind die Konsequenzen des Technologiewandels in weiten Bereichen spürbar. Die „Alterung“ der eingesetzten Systeme erfolgt wesentlich schneller, die alten, langen Abschreibungszyklen werden aufgrund der Kurzlebigkeit der jeweils neuesten IT- und Kommunikationstechnologie indirekt wesentlich verkürzt, was die Aufwandsseite merklich erhöht. Die Beschaffung von Ersatzteilen – unabhängig ob Software (z.B. eine Betriebssystemversion) oder Hardware (z.B. Prozessor) – gestaltet sich als schwierig bis unmöglich. Wie weitreichend diese Abhängigkeit sein kann, zeigt folgende Pressenotiz aus dem Monat Mai 2002: NASA will i8086-CPUs bei eBay und Yahoo kaufen Die US-Raumfahrtbehörde NASA sucht in Online-Auktionen von eBay und Yahoo nach Intels i8086-Prozessoren. Wie die „New York Times“ berichtet, ist das Raumfahrt-Programm der USA abhängig von Ersatzteilen, die nicht mehr produziert werden. Deshalb kaufte die NASA zuletzt große Mengen an ausgedienten medizinischen Geräten, um an die gewünschten Chips zu kommen. Wie die Zeitung schreibt, spielt die i8086-CPU eine kritische Rolle im Diagnose-System für die Booster-Raketen, die dem Space Shuttle Starthilfe geben. Als Ersatz plant die NASA zurzeit ein neues automatisiertes System, das 20 Millionen Dollar kosten wird. Bis dieses einsatzbereit ist, muss sich United Space Alliance, Betreiber der ShuttleFlotte, mit alten Teilen behelfen. Aus Sicht der Produktivitätssteigerung gilt beim Faktor Technologie i.d.R., dass sowohl die Aufwandsseite wie die Erfolgsseite der Produktivität durch die jeweilige technische Nachfolgegeneration positiv beeinflusst wird. Meist reduziert eine weitergehende Automatisierung durch eine höhere Stabilität, Zuverlässigkeit und Qualität die Aufwandsseite. Die Erfolgs- bzw. Leistungsseite wird durch ein verbessertes Aufwand- / Ertragsverhältnis oder durch eine verbesserte Produktionsrate, die sich z.B. in der Steigerung von Mengen und / oder Produktionsgeschwindigkeit bemerkbar machen kann, positiv beeinflusst. Nicht verschwiegen werden darf, dass aufgrund von Fehleinschätzungen oder fehlenden Erfahrungen beim Einsatz neuer Technologien oftmals an

Der Zwang zur Produktivitätssteigerung

13

anderer Stelle die gewonnene Produktivitätssteigerung wieder zunichte gemacht wird. Die Prozessorganisation Die Prozessorganisation ist eine – im Gegensatz zu Mensch und Technologie – abstrakte Komponente, die ebenfalls einen wesentlichen Einfluss auf die Produktivität nimmt. Viele Beispiele von bahnbrechenden Entwicklungen basieren auf der Gestaltung der Prozessorganisation. Das wohl bekannteste ist die Einführung der Fließbandproduktion im Automobilbau durch Henry Ford. Die Gestaltung der Arbeitsabläufe ist aus Sicht der Organisationslehre eine schon lange bekannte Aufgabenstellung. Mit der zunehmenden informationstechnologischen Unterstützung erfolgt eine an sich paradoxe Entwicklung, die sich in drei Ausprägungen manifestiert. Know-how-Verlust: Es geht sehr viel Know-how bzgl. der Prozessabläufe, der Zusammenhänge und Abhängigkeiten und oft auch der Funktionen – was wie nach welchen Regeln verarbeitet wird – verloren. Es handelt sich hierbei um das bekannte Taschenrechnerproblem, bei dem Rechenfunktionen im Rechner fix programmiert sind, der Benutzer nur noch den Input liefern muss und anschließend den Output erhält, ohne dass er zwingend dazu in der Lage ist, die Rechenfunktionen zu verstehen und sie manuell nachvollziehen zu können. Dies vereinfacht zwar die Anwendung und reduziert die fachlichen und intellektuellen Anforderungen an das Personal, führt aber bei Veränderungen zu einem hohen Aufwand, da oftmals das „Wissen“ aus den Applikationen rekonstruiert werden oder quasi neu entwickelt werden muss. Änderungszwang: Erfolgen Änderungen in der Applikationslandschaft (z.B. durch Einführung einer Standard-Software), besteht das Risiko, dass informationstechnologisch unterstützte Prozesse zwangsläufig angepasst werden müssen, ohne dass dies einen Nutzen (aufwandsreduzierend bzw. leistungssteigernd) mit sich bringt. Die Anpassung der jeweiligen Prozesse erfolgt dann nicht zwingend im Sinne einer optimalen Organisation, sondern vielmehr als ein technologisches Diktat. Änderungsblockade: Dies ist in der Konsequenz das Gegenteil zum Änderungszwang. Eine organisatorisch logische und sinnvolle Anpassung der Prozesse wird durch die bestehende ICT-Infrastruktur verhindert. Dazu gehört – der wohl häufigste Fall –, dass die Anpassungsaufwände für den

14

Rahmenbedingungen

ausgewiesenen Nutzen zu hoch sind. Solange es sich dabei um einen Einzelfall handelt, ist diese Blockade nicht weiter störend. Wenn aber über die Zeit hinweg viele kleinere Anpassungen nicht möglich sind, ist das Risiko groß, dass eines Tages eine umfassende Neulösung, mit dem entsprechenden Aufwand und Risiko, angegangen werden muss. Der Lösungsansatz: Schwerpunkt Prozessoptimierung Im vorhergehenden Kapitel haben wir die für uns wesentlichen drei Faktoren, mit denen die Produktivität am stärksten beeinflusst werden kann – der Mensch, die Technologie und die Prozessorganisation –, beschrieben. Klammern wir für den Faktor Mensch den „Asieneffekt“3 einmal aus, stellt sich dieser Bereich eher als Konstante dar. Hier muss zwar Aufwand erbracht werden, um die Leistungsfähigkeit4 der Mitarbeiter zu steigern und auf einem hohen Niveau zu halten, aber hier sind gewisse Grenzen gesetzt. Die Technologie ist zumindest für die ICT-Branche im Prinzip auch eine Konstante, wenn man akzeptiert, dass eine vom Markt erzwungene regelmäßige Modernisierung oder der permanente Austausch veralteter Technologien bereits eine Konstante zur Optimierung der Produktivität darstellt. Die Einführung neuer Technologien zieht in einer ICT-Unternehmung bzw. ICT-Organisation in fast allen Fällen eine Anpassung der damit verbundenen Arbeitsabläufe nach sich. Dabei sind diese so zu gestalten bzw. zu optimieren, dass die neue Technologie optimal eingesetzt wird. Dies kann sich gegebenenfalls bis zu den Anwendern dieser Technik auswirken. Soll beim Anwender mit gleichem Personalaufwand mehr Leistung bei gleich bleibender oder gar höherer Qualität erbracht werden, kann dies ebenfalls oft nur durch die Neugestaltung der Arbeitsabläufe oder durch Einsatz neuer Technologien erfolgen – womit sich dann wieder der Kreis schließt. Das unbestreitbar größte Potenzial für eine Produktivitätssteigerung im ICT-Bereich bietet somit die Ablauforganisation, sprich die Prozesse. Grundsätzlich können hierfür zwei methodische Ansätze verwendet werden. Der eine ist die so genannte End-to-End-Betrachtung. Hier wird die Prozesskette ausgehend von dem den Prozess auslösenden Ereignis, z.B. Kun3

Senkung der Arbeitskosten.

4

Hier eher gleichzusetzen mit „Wissensstand“.

Der Zwang zur Produktivitätssteigerung

15

de bestellt PC, bis zum den Prozess abschließenden Ereignis, z.B. Kunde erhält bestellten PC, betrachtet. Dies hat den Vorteil, dass die Aufgabenstellung zumindest was Anfang und Ende betrifft, klar definiert ist. Es hat aber den Nachteil, dass nicht zwingend ersichtlich ist, wie dieser Prozess in die Vielfalt anderer bestehender Prozesse eingebettet ist. Es handelt sich immer um eine Einzelbetrachtung. Der zweite Ansatz basiert auf einem Prozessmodell, d.h. man betrachtet alle Prozesse und deren Abhängigkeiten untereinander. Der Vorteil liegt in der Gesamtbetrachtung und dem Überblick über die Zusammenhänge. Aufgrund der Masse der abzubildenden Information muss man sich aber zwangsläufig auf einer höheren Abstraktionsebene bewegen, was zum Nachteil hat, dass die Details Opfer der Abstraktion werden. Weiter sind End-to-End-Betrachtungen nicht ohne Sachkenntnis aus einem Prozessmodell herauszulesen. Ganz abgesehen davon, dass die Erstellung und der Unterhalt eines entsprechenden Prozessmodells ein gewisses Maß an Kompetenz und entsprechendem Aufwand benötigt. Die Praxiserfahrungen zeigen, dass die besten Ergebnisse erreicht werden, wenn beide Ansätze kombiniert werden. Für die Abgrenzung der Aufgabenstellung wird zwingend die Gesamtsicht benötigt. Für die Detailbetrachtung, die End-to-End-Sicht und die Verifikation von Veränderungen an den Prozessen erfordert es wiederum den Blick auf die Zusammenhänge. Entsprechend ist auch der Ansatz, der in diesem Buch verfolgt wird. So werden einzelne Problemstellungen jeweils aus der Sicht einer End-toEnd-Betrachtung diskutiert und die beteiligten Prozesse im Zusammenhang, auf der Basis eines umfassenden Referenzmodells für eine ICTUnternehmung, dargestellt. Trotz erheblicher Abstraktion und Konzentration auf das Wesentliche ist das Referenzmodell sehr umfangreich. Da es eine recht trockene Materie ist und es einiges an Aufwand kostet, sich in dieses Modell einzudenken, hat das Kapitel Prozessbereiche & Prozesskategorien mehr den Charakter eines Nachschlagewerkes. Für uns stellt ein Prozess-Referenzmodell die Grundlage für jede Art der Prozessoptimierung dar. Alle uns bekannten erfolgreichen Optimierungsprojekte haben schlussendlich im Rahmen der vorgängigen Analyse ein Ergebnis erarbeitet, welches als Modell bezeichnet werden kann. Wesentlich ist somit der Einsatz eines Modellkonzeptes.

16

Rahmenbedingungen

Der Lösungsansatz optimale Prozessorganisation im ICT-Management hat in den letzten Jahren zu einer Reihe von Konzepten geführt, die, mehr oder weniger standardisiert, ihren Niederschlag in Regelwerken, Konzepten oder gar Normen gefunden haben. Die bekanntesten sind derzeit sicherlich ITIL und CobiT, und an Bedeutung zunehmen wird die BS15000 / ISO 2000. Ein Überblick über diese drei und weitere befindet sich im nachfolgenden Kapitel.

ITIL … Eines der düsteren Kapitel der ICT-Branche ist die Entwicklung, Einführung und Durchsetzung von Standards aller Art. Bei echten Hardfacts, wie dies z.B. technische Standards darstellen, ist das noch relativ einfach. Denn erstens wird deren Durchsetzung vom Markt gesteuert und zweitens muss sich jeder Hersteller zwangsläufig, wenn er keine Inkompatibilitäten riskieren möchte, daran halten. Vorschläge zur Standardisierung von Themen, die den so genannten Softfacts zuzuordnen sind, haben es da wesentlich schwieriger. Hier fehlt der Marktdruck, und bei einer Abweichung von diesen Vorschlägen gibt es keine spürbaren Konsequenzen. Die Definition von Berufsbildern und Bezeichnungen sowie von Prozessen, Rollen und einer Vielzahl von ICT-spezifischen Fach- und Organisationsbegriffen gehören zu dieser Kategorie. Dies führte dazu, dass es heute eine unüberschaubare Anzahl und verschiedene Variationen von Prozess-, Aufgaben-, Rollen- und Begriffsdefinitionen innerhalb der ICT-Branche gibt. Bereits vor rund zwanzig Jahren wurden diese Defizite von der britischen Regierung erkannt, die daraufhin die CCTA (Central Computer and Telecommunications Agency) in Norwich, England, damit beauftragte, eine entsprechende Lösung zu erarbeiten. Das Ergebnis dieser Bemühungen ist die IT Infrastructure Library, besser bekannt unter dem Kürzel ITIL, deren Publikationen sich in den letzten 10 Jahren quasi zu einem De-factoStandard für IT-Service-Management-Organisationen entwickelt haben. Ähnliche, mehr oder weniger erfolgreiche Bestrebungen finden sich auch in anderen Themenbereichen, die direkt oder indirekt in Zusammenhang mit der ICT stehen, wie z.B. im Bereich der Systementwicklung, dem Projektmanagement und der Qualitätssicherung von ICT-Leistungen. ITIL gilt heute als die einzige Verfahrensbibliothek, die weite Bereiche des IT-Service-Managements im Sinne eines Rahmenwerkes abdeckt. Die

ITIL …

17

besondere Leistung besteht darin, dass das Know-how einer Vielzahl von Experten gebündelt und in einer einheitlichen Begriffs- und Verständniswelt zusammengetragen wurde. Die Konzentration erfolgte hierbei primär auf die Frage Was ist zu tun? und weniger auf das Wie ist es zu tun. ITIL bietet damit die Grundlagen für einen umfassenden Überblick über die Anforderungen und Funktionen im IT Service Management. Das vorliegende Buch sieht sich eher als ergänzendes und nicht etwa als konkurrierendes Werk. Es konzentriert sich auf die Frage Wie sind die Zusammenhänge? und setzt das ITIL-Verständnis voraus. Weiter sollen hier Ansätze für Produktivitätssteigerung aufgezeigt werden, womit sich der Schwerpunkt von der Theorie in die Praxis verschiebt. In den letzten Jahren hat sich unter dem „Label“ ITIL ein weites Feld von weiteren Dienstleistungen wie z.B. Ausbildung, Beratung und Software Tools etabliert. Auch die international organisierte Benutzervereinigung itSMF ist eine zwischenzeitlich in vielen Ländern etablierte Institution, welche die Weiterentwicklung und die Durchsetzung von ITIL unterstützt. ITIL ist im Web sehr gut vertreten. Der interessierte Leser kann sich auf den folgenden Webseiten ausführlich informieren und findet dort eine Reihe weiterer Links: www.iti.org.uk www.itil-itsm-world.com www.itil.co.uk www.itsmf.de Das vorliegende Buch berücksichtigt eine Vielzahl von Definitionen und Überlegungen, die in den ITIL-Schriften dokumentiert sind. Gleichwohl gibt es Unterschiede, die sich primär durch den gewählten methodischen Ansatz und durch die Integration weiterer Aspekte erklären. Der größte Unterschied ergibt sich vor allem durch den hier gewählten Ansatz, die organisatorischen Aspekte aus der Sicht eines umfassenden Prozessmodells zu diskutieren. Sicherlich gibt es auch punktuelle Abweichungen aufgrund einer unterschiedlichen Auffassung der Materie, die meist durch die eigenen praktischen Erfahrungen geprägt wurden. Dies ändert aber nichts daran, dass wir für eine vertiefte Auseinandersetzung mit dem Thema IT Service Management auf die ITIL-Literatur verweisen. Für April / Mai 2007 ist die seit einiger Zeit erwartete Version 3 von ITIL angekündigt. Nach dem letzten Update im Jahre 2000 wird das Fra-

18

Rahmenbedingungen

mework nun sicher auch eine Reihe von bestehenden Inkonsistenzen, insbesondere bei den Definitionen, beseitigen. Auch auf das angekündigte Lifecycle-Konzept darf man gespannt sein.

… und andere ITIL haben wir bewusst ein eigenes Kapitel gewidmet, um dessen Bedeutung zu unterstreichen. Unabhängig davon gibt es auf dem Markt aber weitere Konzepte bzw. Modelle, die aus den unterschiedlichsten Zielsetzungen entstanden sind bzw. für ganz bestimmte Aufgabenstellungen entwickelt wurden. Die folgende Auflistung soll dem interessierten Leser einen Hinweis auf mögliche weitere Informationsquellen geben. Die Ansätze und Elemente, die uns in unserer Zielsetzung der Darstellung Wie sind die Zusammenhänge? unterstützten, haben wir, soweit sinnvoll und notwendig, berücksichtigt. BS 15000 / ISO 20000 British Standard 15000 ist ein in Großbritannien von der British Standard Institution (BSI) entwickelter Standard für Qualität im IT Service Management (ITSM). Im BS 15000 werden die notwendigen generischen Prozesse spezifiziert („Objectives and Controls“) und dargestellt, die eine Organisation etablieren muss, um IT Services in definierter Qualität bereitstellen und managen zu können. BS15000 orientiert sich stark an ITIL Best Practices. Die Umsetzung der hier definierten Prozesse kann zertifiziert werden – damit ist BS 15000 die einzige Möglichkeit der Zertifizierung des IT Service Managements anhand eines internationalen Standards. Ende 2005 wurde die BS 15000 auch als internationaler Standard anerkannt und in die ISO 20000 überführt. Die ISO 20000 steht nicht in Konkurrenz zur ISO 9000 (Normenreihe für Qualitätsmanagementsysteme), sondern ist vielmehr eine Erweiterung und Konkretisierung für den IT-Bereich. CMMI – Capability Maturity Model Integration CMMI ist ein Prozessmodell zur Beurteilung und Verbesserung der Reife von Entwicklungsprozessen innerhalb eines Unternehmens. 1986 wurde es

… und andere

19

auf Initiative des US-Verteidigungsministeriums von Software Engineering Institute der Carnegie Mellon University entwickelt und 1991 erstmals herausgegeben. CMMI ist die neue Version von CMM (Capability Maturity Model) und integriert in seinem modularen Modell zusätzlich zu SoftwareEntwicklung auch weitere Entwicklungsdisziplinen wie die HardwareEntwicklung. CMMI beschreibt die Verbesserung eines Prozessgebiets durch Fähigkeitsgrade (0=Incomplete …, 5=Optimizing) und Reifegrade (1=Initial …, 5=Optimizing). Die Bewertung des Reife- und Fähigkeitsgrads geschieht durch ein SCAMPI-Appraisal5. SCAMPI („Standard CMMI Appraisal Method for Process Improvement“) wurde ursprünglich für die Evaluierung von Organisationen im Bezug auf CMMI entwickelt, kann heute allerdings auch zur Überprüfung anderer Prozessmodelle verwendet werden. Im August 2006 ist die neue Version 1.2 des CMMI veröffentlicht worden. Mit dem neuen Release sind einige grundlegende Veränderungen einhergegangen. So wurde u.a. die neue Version auf CMMI-DEV umbenannt. Das Konzept der Beurteilung von Reifegraden von Prozessen wird zwischenzeitlich von vielen Anbietern und Herstellern für spezifische Beurteilungen, z.B. für die Bewertung der Prozesse in einem Help Desk, verwendet. Alle uns bekannten Konzepte sind auf CMMI zurückzuführen. CobiT CobiT (Control Objectives for Information and Related Technology) ist ein Modell von generell anwendbaren und international akzeptierten ITprozessbezogenen Kontrollzielen (control objectives), die in einem Unternehmen beachtet und umgesetzt werden sollten, um eine verlässliche Anwendung der Informationstechnologie zu gewährleisten. Verantwortlich ist das „IT Governance Institute“ ITGI und die „Information Systems Audit and Control Association“ ISACA. 1993 begann die Entwicklung, 1995 wurde die erste Version veröffentlicht. Seit 2005 gibt es die vierte Version mit 34 IT-Prozessen, 300 Kontrollzielen und „Management Guidelines“. CobiT stellt eine Sammlung von Veröffentlichungen dar, die allgemein akzeptierter Standard für IT-Sicherheit und IT-Kontrolle sind und die von Mitgliedern des Managements sowie Anwendern und Auditoren ange-

5

Beurteilung.

20

Rahmenbedingungen

wandt werden können. CobiT ist die einzige alle Bereiche umfassende Methode zur Unterstützung von IT Governance auf allen Ebenen. HP IT Service Management IT Service Management von Hewlett Packard stellt einen Best-PracticeAnsatz für die Gestaltung der IT-Struktur dar. Das Modell beruht auf ITIL, es gibt allerdings auch Ansätze, das Modell auf die CobiT-Struktur anzuwenden. Das Modell wurde Mitte der 1990er Jahre von HP Consulting & Integration entwickelt. HP gehört zu den Gründungsmitgliedern des ITService-Management-Forums (ITSMF), dessen Aufgabe in der Etablierung von Best Practices im IT Management besteht. Im Vergleich zum (folgenden) Microsoft-Referenzmodell für IT Service Management (MOF) ist das HP-Referenzmodell weniger herstellerspezifisch und spricht damit eine größere Zielgruppe an. Unabhängig davon bietet HP auch Software-Produkte an, die speziell ihren Ansatz unterstützen. Das HP-Modell ist stark auf ITIL ausgerichtet und ist vor allem als zusätzliche Detaillierung zu dieser Sammlung von Best Practices zu sehen, mit dem Zweck, eine Implementierung bzw. Anpassung von IT Service Management im Unternehmen zu erleichtern. MOF Microsoft Operations Framework MOF stellt eine Komplettanleitung als Modell für die Planung und Realisierung von IT-Projekten dar. Es ist kein Referenzmodell, vergleichbar mit CobiT oder ITIL, vielmehr ist es ein anwendungsnahes Modell für IT Management in einer Microsoft-Umgebung. MOF ist speziell für die Anwender interessant, die eine reine Microsoft-Softwarelandschaft installiert haben und diese optimal managen wollen. Auch viele MOF-Inhalte orientieren sich an ITIL.

Modellkonzept und Methodik

Was ist ein Modell? Eine von breiten Kreisen der Forschung aufgenommene allgemeine Modelltheorie wurde 1973 von Herbert Stachowiak vorgeschlagen. Der in dieser Modelltheorie entwickelte Modellbegriff ist nicht auf eine Fachdisziplin festgelegt. Er will vielmehr disziplinübergreifend, also allgemein anwendbar sein. Nach Stachowiak ist der Begriff „Modell“ durch drei Merkmale gekennzeichnet: • Abbildung: Ein Modell ist immer ein Abbild von etwas, eine Repräsentation natürlicher oder künstlicher Originale, die selbst wieder Modelle sein können. • Verkürzung: Ein Modell erfasst nicht alle Attribute des Originals, sondern nur diejenigen, die dem Modellschaffer bzw. Modellnutzer relevant erscheinen. • Pragmatismus: Pragmatismus bedeutet soviel wie Orientierung am Nützlichen. Ein Modell ist einem Original nicht von sich aus zugeordnet. Die Zuordnung wird durch die Fragen: für wen?, warum? und wozu? relativiert. Ein Modell wird vom Modellschaffer bzw. Modellnutzer innerhalb einer bestimmten Zeitspanne und zu einem bestimmten Zweck stellvertretend für ein Original eingesetzt. Das Modell wird somit (vom Benutzer) interpretiert. Ein Modell zeichnet sich also durch Abstraktion aus, durch bewusste Vernachlässigung bestimmter Merkmale, um die für den Modellierer oder den Modellierungszweck wesentlichen Modelleigenschaften hervorzuheben. Dabei wird – im Gegensatz zu Modellbegriffen einzelner Wissenschaften – kein bestimmter Abstraktionsgrad vorausgesetzt, um ein Konstrukt als Modell zu bezeichnen. In der tagtäglichen Praxis arbeiten wir oft und z.T. auch unbewusst mit Modellen: einem Stadtplan, einer Landkarte, einem Bauplan, Schnittmus-

22

Modellkonzept und Methodik

tern, grafischen Darstellungen in Betriebsanleitungen, Spielzeugen (Auto-, Schiffsmodelle) usw. Grafisch aufbereite Prozessmodelle haben Ähnlichkeit mit einem Stadtplan oder einer Blaupause (Konstruktionsplan). Mit dem notwendigen Fachwissen kann jeder, der in die Symbolik eingeweiht ist, diese lesen, interpretieren und die für die Umsetzung notwendigen Informationen daraus ableiten. Vielfältige Modelle in der täglichen Praxis In der allgemeinen Organisationslehre wird eine Vielzahl von Techniken eingesetzt, die Modellcharakter haben. Konzentrieren wir uns in der Folge auf einige wenige ausgewählte grafische Darstellungstechniken. Die bekannteste ist wohl das Organigramm. Hier wird nach vorgegebenen Regeln die Organisationsstruktur einer Firma oder eines Teilbereiches mit wenigen grafischen Elementen dargestellt. Bereits die Bezeichnung der Organisationseinheiten und deren Zuordnung zu über- bzw. untergeordneten Organisationseinheiten liefern vielfältige Informationen. Wie das Unternehmen strukturiert ist, welche Tätigkeiten erbracht werden und, je nach Informationstiefe, wie viele Mitarbeiter oder wie viele Abteilungsleiter etc. beschäftigt werden, können dem Organigramm entnommen werden. Hierbei ist das Organigramm die Abbildung eines Teilaspektes der Unternehmung, es stellt verkürzt nur die relevanten Informationen dar und ist durch seine Einfachheit bewusst pragmatisch. Es erfüllt somit also die Kriterien für ein Modell. Eine weitere sehr bekannte Darstellungstechnik ist die Abbildung von Abläufen durch Flussdiagramme1. Hier werden in der Reihenfolge ihres Eintretens Tätigkeiten und Entscheidungen in ihrer logischen Abfolge anhand von Symbolen dargestellt. Dabei ergeben sich einfach zu lesende Diagramme, die z.B. einen Arbeitsablauf inkl. seiner diversen Ausprägungen beschreiben. Auch hier handelt es sich um eine typische abstrakte Abbildung, die in verkürzter Form und sehr pragmatisch nur die relevanten Informationen vermittelt. 1

Engl. Flowchart, wurde in den 1960er Jahren speziell für die grafische Darstellung von Programmablaufplänen entwickelt und in der DIN 66001 dokumentiert. Das Grundkonzept wurde anschließend in einer Vielzahl von Weiterentwicklungen verwendet (Datenflussdiagramme, strukturierte Analyse etc.). Auch alle bekannten Methoden zur Darstellung von Prozessabläufen lassen sich auf das Konzept des Flussdiagramms zurückführen.

Was ist ein Modell?

23

Abb. 1. Typische Darstellung eines Ablaufes als Flussdiagramm

Als drittes und letztes Beispiel soll das Datenmodell erwähnt werden. Hier ist bereits der Modellgedanke in den Namen integriert. Datenmodelle spielen insbesondere bei der Konzeption und Dokumentation von Datenbanklösungen eine wichtige Rolle. Mit nur wenigen grafischen Elementen werden Datenstrukturen definiert, gruppiert und in Beziehung zueinander gebracht. Das Datenmodell ist für die Datenbankentwickler quasi das Gleiche wie der Bauplan für den Architekten. Auch dieses Modell erfüllt die allgemeinen Modellansprüche: abstrakte Abbildung, verkürzte Darstellung durch eine reduzierte Symbolik und eine pragmatische Sicht auf das eigentliche Objekt. In der tagtäglichen unternehmerischen Praxis werden wir bewusst oder unbewusst mit einer Vielzahl von Modellen konfrontiert, mit deren Hilfe wir uns komplexe Zusammenhänge vereinfachen. Modelle erlauben uns, uns schnell und mit wenig Aufwand zu orientieren und darauf basierend Entscheidungen zu fällen. Methodisch gesehen ist unser Prozess-Referenzmodell eine Vernetzung und Kombination einer Vielzahl von grafischen Elementen, die bei einer

24

Modellkonzept und Methodik

Einzelbetrachtung eine große Ähnlichkeit mit Flussdiagrammen haben. Die verwendeten Gliederungs-, Strukturierungs- und Beziehungsüberlegungen haben Analogien zu denen im Organigramm oder im Datenmodell. Abgrenzung: Ist-, Soll- und Referenzmodell Ein Modell ist eine Abbildung. Organisationen haben die Eigenschaft, sich ständig zu verändern. Jedes Modell unserer Organisation, unseres Unternehmens, unterliegt somit, wie in der folgenden Abbildung dargestellt, einem Lebenszyklus. Je höher der Detaillierungsgrad, desto höher ist die Veränderungsdynamik, desto schneller altert das Modell. Sie kennen es aus der Praxis: „Das ist das Organigramm unserer Firma, es ist nicht mehr ganz (!) aktuell, das neue ist vorhanden, aber noch nicht verabschiedet.“ Die Frage nach der Aktualität eines Modells, also danach, inwieweit das Modell mit der tatsächlichen Situation übereinstimmt, ist omnipräsent.

Abb. 2. Lebenszyklen von Modellen am Beispiel eines Organigramms

Diese allgegenwärtige Frage versucht man allgemein mit den Zusätzen IST bzw. SOLL zu beantworten. IST beschreibt hier dann sinngemäß den derzeitig gültigen bzw. aktuellen Zustand und SOLL verweist auf die nicht weiter spezifizierte Zukunft: So soll (wird) es sein. Bei der Erstellung von umfassenden2 Prozessmodellen haben wir die gleichen Voraussetzungen. Sollen wir das IST oder das SOLL in unserem 2

Umfassend im Sinne von gesamthaft. Die Ausführungen gehen davon aus, dass viele verschiedene Prozesse einer Unternehmung parallel zu berücksichtigen sind und betrachtet werden müssen. Aufgrund der Vielzahl der zu berücksichtigenden Prozesse besteht in der Folge eine höhere Anpassungs- bzw. Änderungsdynamik. Werden nur einzelne Prozessketten betrachtet, können diese für sich durchaus auch über eine längere Zeit hinweg unverändert bleiben.

Was ist ein Modell?

25

Modell abbilden? Und wenn wir das SOLL abbilden, was sollen / können wir dann vom IST berücksichtigen? Die Prozessorganisation einer Unternehmung ist, wenn man Prozesse auf ihrer unteren Detaillierungsebene betrachtet, sehr dynamisch. Je höher der Detaillierungsgrad (z.B. bei konkret beschriebenen Arbeitsabläufen), desto häufiger müssen Anpassungen, Ergänzungen und Korrekturen vorgenommen werden. Hinzu kommt die direkt mit der Unternehmensgröße zusammenhängende zunehmende Komplexität von Abhängigkeiten jeglicher Art, insbesondere der Prozesse untereinander. D.h., selbst wenn der eigene Ablauf nicht direkt betroffen ist, muss er evtl. aufgrund von veränderten Rahmenbedingungen angepasst werden. Mit anderen Worten: Der Versuch, ein umfassendes IST-Prozessmodell zu erstellen, weicht sehr schnell der Erkenntnis, dass es schneller an Aktualität verliert, als man es nachdokumentieren kann. Typische Beispiele aus der Praxis für dieses Dilemma sind die Qualitäts-Management-Systeme, die theoretisch die IST-Abläufe dokumentieren sollten. Ein IST-Prozessmodell erhebt den Anspruch, die bestehende IST-Situation einer realen Unternehmung bzw. einer Organisationseinheit abzubilden. Typisch ist der in der Regel hohe Detaillierungsgrad. Die Erstellung eines umfassenden SOLL-Prozessmodells ist ein hoch interessanter und vielversprechender Ansatz, wenn ein Unternehmen neu, quasi auf der grünen Wiese entwickelt wird und das dafür notwendige Knowhow vorhanden ist. Es gibt keine Einschränkungen außer einigen („Natur-“) Gesetzen. Anpassungen und Korrekturen erfolgen im Rahmen der Umsetzung, die Dokumentation des Endergebnisses wird dann zum kurzzeitig aktuellen IST-Modell. Ein umfassendes Zukunfts- bzw. SOLL-Prozessmodell für eine über einen längeren Zeitraum gewachsene Unternehmung zu erstellen, ist schwierig, insbesondere dann, wenn das SOLL nicht in einer etwas ferneren Zukunft liegt, die es erlaubt, einengende Rahmenbedingungen zu vernachlässigen bzw. diese zumindest konzeptionell zu verändern. In der täglichen Praxis sind die Gestaltungszeiträume meist kürzer angesetzt. Somit scheitern SOLL-Vorstellungen oftmals an „derzeit nicht änderbaren“ Rahmenbedingungen. Typischerweise führen Schnittstellen von nicht veränderbaren Bereichen dazu, dass neue Ansätze schon auf Modellebene gekippt werden. Oder als stabil erachtete Bereiche ändern sich überraschend

26

Modellkonzept und Methodik

und die veränderten Rahmenbedingungen müssen erst einmal „aufgefangen“ werden. Man wird im wahrsten Sinne des Wortes von der aktuellen Wirklichkeit eingeholt, bevor man die zukünftige definiert hat. Die Gefahr, mit einen SOLL-Prozessmodell im Elfenbeinturm zu enden, ist groß. Unsere Konklusion: SOLL-Prozessmodelle machen nur dort Sinn, wo es sich um echte Neukonzeptionen3 handelt und es zwingend notwendig ist, eine erstmalige Detailvorgabe für die Prozessgestaltung im Einzelnen sowie im Zusammenhang zu machen. Ein SOLL-Prozessmodell erhebt den Anspruch, die zukünftige IST-Situation einer realen Unternehmung abzubilden. Es hat die Zielsetzung, die zukünftige Gestaltung der Prozesse aufzuzeigen. Ein weiterer vielversprechender und von uns in der Praxis erfolgreich umgesetzter Ansatz für die Entwicklung von Prozessmodellen ist der folgende: Unternehmen, ihre Organisationen und hier insbesondere ihre Prozesse unterliegen gewissen Gesetzmäßigkeiten. Betrachten wir hierzu zwei Standard-Funktionen eines Unternehmens: zum einen den Funktionsbereich Finanzen / Controlling, zum anderen das Personalwesen. Der Großteil der in diesen Bereichen zu erbringenden Funktionen, Tätigkeiten, Prozessen, benötigten Rollen etc. ist vollkommen von dem eigentlichen Geschäftszweck einer Unternehmung unabhängig. Die Erstellung eines Jahresabschlusses oder der Einstellungsprozess für einen neuen Mitarbeiter sind für alle Unternehmen auf einem gewissen Abstraktionslevel gleich. Diese Tatsache ist einer der wesentlichen Erfolgsfaktoren von StandardSoftware-Lösungen für diese Funktionsbereiche. Geht man nun davon aus, dass die für die Herstellung von bestimmten Produkten, für die Erbringung bestimmter Dienstleistungen benötigten Prozesse ebenso gewissen Gesetzmäßigkeiten unterliegen, kann dieser Ansatz auch auf die eigentlichen wertschöpfenden Bereiche übertragen werden. Dies erklärt auch den zunehmenden Erfolg so genannter Branchenlösungen, die, wie der Name sagt, branchenspezifische IT-unterstützte ProzessLösungen anbieten. Löst man sich von der eigentlichen IT-Lösung und begibt sich eine Ebene höher, auf die der Konzeption, ist es nicht von der Hand zu weisen, 3

Dazu gehört auch ein Business-e-Engineering.

Was ist ein Modell?

27

dass es möglich sein muss und ist, branchenspezifische Prozessmodelle zu definieren. Mit anderen Worten: Alle Autobauer bauen Autos, alle Kaufhäuser kaufen und verkaufen Waren und alle Banken machen Geldgeschäfte. Der Unterschied zwischen den einzelnen Unternehmen liegt im Wesentlichen nur auf der Produktebene. Die dafür notwendigen Herstellungs-, Zulieferer- und sonstigen Prozesse sind auf einer entsprechenden Abstraktionsebene identisch. Die Unternehmen unterscheiden sich in der Praxis in der Qualität ihrer Produkte, der Art und Weise der Umsetzung und der technologischen Unterstützung ihrer Prozesse und dem Grad der erzielten Wertschöpfung. Somit können Muster von Prozessen, die der gewünschten Branchenlösung in Teilen nahe kommen, entwickelt werden. Diese Muster dienen als Referenz und sind für die eigenen Bedürfnisse in der Folge zu konkretisieren. Werden nun für ein Unternehmen alle relevanten Prozesse in dieser Form – und vor allem die einzelnen Prozesse in ihrer Beziehung zueinander – dokumentiert, entsteht ein Prozess-Referenzmodell – also ein Modell, eine Vorlage, an der man sich orientieren und auf die man verweisen kann. Abbildung 3 stellt die Position des Referenzmodells innerhalb des Lifecycles eines Modells dar.

Abb. 3. Position eines Referenzmodells im Lebenszyklus von Modellen

28

Modellkonzept und Methodik

Die Kunst bei der Entwicklung eines Prozess-Referenzmodells liegt darin, eine Abstraktionsebene zu erreichen, die das Modell für einen Anwender wertvoll macht. Hierfür darf es auf der einen Seite nicht zu simpel, zu oberflächlich und zu allgemeingültig sein, da es sonst keinen erkennbaren Mehrwert liefert. Andererseits darf es aber auch nicht zu umfassend sein. Zu umfassend heißt in der Regel zu komplex und zu spezifisch. Ansonsten besteht die Gefahr, dass es selbst wieder der oben beschriebenen Veränderungsdynamik unterworfen wird. Weiter kommen ab einer gewissen Stufe Organisations- bzw. Unternehmensspezifika4 hinzu, die sich nicht ohne weiteres auf andere übertragen lassen. Mit dem in diesem Buch dargestellten Prozess-Referenzmodell setzen wir den beschriebenen Ansatz um. Wir wissen aus der Praxis, dass die Prozessorganisationen von ICT-Unternehmungen bzw. ICT-Abteilungen in ihren Grundstrukturen eine sehr hohe Ähnlichkeit aufweisen und sich oft nur in Details unterscheiden. Ein Prozess-Referenzmodell dient primär dem Aufzeigen der Zusammenhänge der Prozesse innerhalb der Unternehmung auf einem eher hohen Abstraktionslevel. Für das Unternehmen wichtige Vorgaben (wie z.B. Schnittstellen) werden hier definiert. Bei der Entwicklung bzw. Anpassung von operativen Prozessen wird das Referenzmodell als Vorlage (Referenz) verwendet. Die dort definierten Vorgaben wie z.B. Key Performance Indices, Regeln, zu verwendende Systeme, Dokumentvorlagen etc. müssen verwendet werden. Damit kann einerseits die Durch- und Umsetzung von Vorgaben erreicht, andererseits aber auch die Flexibilität in der Gestaltung auf der Detailebene sichergestellt werden. Das Prozess-Referenzmodell erhebt Anspruch auf Allgemeingültigkeit, auf Vollständigkeit, das Aufzeigen der Zusammenhänge und Abhängigkeiten sowie auf eine Konzentration auf das Wesentliche. Ziel ist es, als steuernde Vorlage im Sinne eines Musters, eben einer Referenz, zu dienen. Ein ProzessReferenzmodell ist im Gegensatz zu einem IST- oder SOLLModell zeitlos und unterliegt nur einer geringen Änderungsdynamik.

4

Dies fängt oftmals schon bei eingeführten und gelebten Begrifflichkeiten und Definitionen an, die oft sehr firmenspezifisch sind.

Was ist ein Modell?

29

Anforderungen an ein Prozess-Referenzmodell Auf welche Zusammenhänge kommt es an? Was sind die kritischen Punkte und wo befinden sich diese? Wie verschafft man sich einen Überblick? Was ist allgemeingültig, was ist firmenspezifisch? Es gibt zwei Möglichkeiten, diese Fragen zu beantworten: zum einen anhand von real existierenden Organisationen, zum andern auf der Grundlage eines allgemeingültigen Modells. Die Vorteile der ersten Variante sind beschränkt, da jede real existierende Organisation immer einen zu spezifischen, individuellen Hintergrund hat5. Dieser gibt dann eine Reihe von Rahmenbedingungen vor, die eine Verallgemeinerung und damit einen direkten Vergleich mit der eigenen Situation verhindert. Weiter sind solche Beispiele einem schnellen Alterungsprozess unterworfen, da sich Organisationen ständig ändern. Ein Modell, welches sich nur auf die wesentlichen Gesichtspunkte konzentriert, weist verschiedene Vorteile auf. So ist eine Verallgemeinerung und damit der Vergleich mit der eigenen Situation möglich. Es dient also zur Orientierung, zum Vergleich, kurzum als Referenz. Aus diesem Grund wird der Begriff Referenzmodell verwendet. Weiter hat ein Modell den Vorteil, dass es ohne großen Aufwand problemlos reduziert oder erweitert werden kann. Es wird somit ein Referenzmodell benötigt, welches erlaubt, aufgrund einer einfachen und nachvollziehbaren Systematik eine Struktur der Prozessorganisation, der wesentlichen funktionalen und prozessualen Elemente, darzustellen. Weiter muss es möglich sein, die Interaktion dieser Elemente untereinander und mit Objekten außerhalb des Modells abzubilden. Modelle sind abstrakte Gebilde. Die wesentlichen Nachteile liegen dementsprechend im Verständnis des Modells. Hierzu werden im Wesentlichen immer drei Fähigkeiten benötigt: 5

In unseren Projekten werden wir immer wieder gefragt: „Wie machen es denn andere?“. Nach der Präsentation der Konzepte, nach dem Besuch der Unternehmen hören wir dann oft: „Passt für uns nicht, wir sind keine Bank, kein Industrieunternehmen, wir sind größer, wir sind kleiner, wir sind komplexer, wir sind einfacher, bei uns nicht machbar, wir haben andere IT-Systeme, wir haben nicht soviel Geld …“

30

Modellkonzept und Methodik

• eine gewisse Kenntnis der Materie (in unserem Fall: wie ein ICTUnternehmen funktioniert) • eine gemeinsame Sprache (Begrifflichkeiten, Definitionen) • das Verständnis der eingesetzten Methodik und Darstellungsmittel Ein weiterer Nachteil eines Modells liegt in fehlenden Details, die für die Umsetzung wichtig sind. Ein Beispiel: In einer Bauzeichnung ist zwar der Ort und die Größe einer Tür ersichtlich, aus welchem Material sie besteht und welche Farbe sie hat, allerdings nicht. Dies bedeutet, dass nach dem Modell noch eine Detailkonzeption bzw. die Spezifikation der angestrebten Lösungen erfolgen muss. Auf der Basis dieses Anspruches und der Zielsetzung dieses Buches wurden folgende Anforderungen an ein ICT-Prozess-Referenzmodell abgeleitet: 1. Der gesamte ICT-Bereich soll wie ein selbstständiges Unternehmen betrachtet werden. Dies vor allem mit dem Hintergedanken, dass die Schnittstelle Kunde ein entsprechendes Gewicht erhält. 2. Wo immer möglich, sollen Prozesse im Vordergrund der Betrachtung stehen. Diese sollen auf einer höchstmöglichen Abstraktionsstufe behandelt werden, um eine Verallgemeinerung zu ermöglichen. 3. Es werden nur ICT-relevante Aspekte beachtet, d.h. allgemeine Unternehmensfunktionen oder Prozesse wie z.B. das Personalwesen oder die Finanzbuchhaltung werden nicht oder nur, wenn es ein spezifischer Bezug verlangt, berücksichtigt. 4. Das Modell soll den Anspruch an ein Referenzmodell erfüllen. D.h., es soll sinnvolle Elemente, deren Zusammenhänge und Abhängigkeiten logisch darstellen, unabhängig davon, wie diese in der Praxis tatsächlich realisiert sind oder realisiert werden. 5. Auf Perfektionismus wird verzichtet. Ziel ist es, im Sinne von Schwerpunkten die wichtigsten Zusammenhänge sowie kritische Aspekte aufzuzeigen. Dies hat die Konsequenz, dass evtl. bestimmte Betrachtungsweisen vernachlässigt werden und damit keine Vollständigkeit erreicht wird. 6. Die Detailtiefe muss in einem sinnvollen Maß gehalten werden. So werden Themen behandelt wie z.B. das Projektmanagement, zu denen es eine wahre Flut an Literatur gibt und deren Vertiefung hier nicht notwendig ist. Die inhaltliche Tiefe ist so zu wählen, dass einerseits die allgemeingültigen Prozessinhalte erkannt werden, andererseits aber eine themenspezifische Diskussion vermieden wird.

Das Referenzmodell in der Praxis

31

7. Die verwendete Methodik für die Darstellung von Prozessen und Prozessabläufen soll so einfach wie möglich sein. Es soll eine minimale Anzahl grafischer Objekte sowie grundlegender Definitionen zum Einsatz kommen. 8. Wo immer möglich, sollen sich die Begrifflichkeiten und Definitionen an allgemeingültigen Standards orientieren – wobei dies der schwierigste Punkt ist, da sich in vielen Bereichen Standards noch nicht durchgesetzt haben, viele Hersteller Definitionen dem Leistungsspektrum ihrer Produkte angepasst haben und sich in allen Unternehmen die Begrifflichkeiten historisch entwickelt und fest etabliert haben.

Das Referenzmodell in der Praxis Das eigene Prozess-Referenzmodell Jedes Unternehmen hat seine eigene Sprache, die sich in eigenen Definitionen, in der Verwendung bestimmter Begriffe und sogar in eigenen Wortkreationen oder Abkürzungen niederschlägt. Auch scheinbar klare, allgemeingültige Begriffe können nicht nur in unterschiedlichen Unternehmen, sondern bereits innerhalb einer Unternehmung unterschiedlich verstanden werden. Ein Beispiel: Eine Bestellung, ein Auftrag scheint auf den ersten Blick eindeutig. Aber was versteht die Verkaufsabteilung unter einer Bestellung, die bei ihr, ausgelöst durch einen Kunden, eingeht? Versteht sie das Gleiche wie die Einkaufsabteilung, die eine Bestellung bei einem Lieferanten auslöst? Selbst genormte oder standardisierte Begriffe werden oftmals durch Reduktionen oder Erweiterungen innerbetrieblich optimiert. Somit besteht bei jeder Vorgabe, an der man sich orientieren kann, die Gefahr, dass sie zumindest in Teilbereichen eine nicht unternehmenskonforme Begriffswelt abbildet. Das hier abgebildete und beschriebene Prozess-Referenzmodell kann aus diesem Grund nur eine Anregung bzw. eine Art Matrize sein, auf deren Basis ein eigenes, individuell angepasstes Referenzmodell entwickelt werden kann. Tatsächlich besteht eine Lücke zwischen allgemeinen, theoretischen Beschreibungen in der Literatur und der in den Unternehmen vorhandenen Dokumentation der bestehenden Ablauf- bzw. Prozessorganisation. Diese besteht pragmatischerweise i.d.R. aus detaillierten Einzelsichten, zeigt selten

32

Modellkonzept und Methodik

die Gesamtzusammenhänge der Unternehmungen auf und kämpft ständig mit dem Problem der Aktualität. Dieses Defizit lässt sich relativ einfach aufdecken: Sie fragen in Ihrem Unternehmen die unterschiedlichsten Personen, ob sie Ihnen nicht kurz einen Überblick über die wichtigsten Prozesse der Unternehmung geben können und an welchen Prozessen sie beteiligt sind. Gut, wenn jemand einen entsprechenden „Stadtplan“ hervorziehen kann, noch besser, wenn es alle können und paradiesisch, wenn Ihnen alle das Gleiche zeigen und auch mehr oder weniger das Gleiche erzählen. Wir können Sie nur dazu ermutigen, ein Prozess-Referenzmodell für Ihre Organisation zu erstellen. Der Nutzen ist wesentlich größer und anhaltender als der dafür notwendige Aufwand. Was ein Referenzmodell ist Natürlich beeinflussen die Autoren und ihre Auftraggeber, was alles in einem Referenzmodell abgebildet werden soll. Unabhängig davon können aber gewisse Leitsätze, die für ein Referenzmodell gelten sollen, definiert werden. Ein Referenzmodell ist: • eine gemeinsame Kommunikationsplattform • eine Zusammenfassung der wichtigsten Prozessketten der betrachteten Organisationseinheiten / Unternehmen • eine Übersicht über die Zusammenhänge / Verknüpfungen der wesentlichen Prozesse der Unternehmung • ein Instrument zur Harmonisierung von Begrifflichkeiten / Definitionen in der Unternehmung • ein Instrument, um maßgebliche Prozessvorgaben festzuhalten • eine Vorlage und Vorgabe für die Entwicklung von Detailprozessen • ein Instrument, um sich und anderen schnell einen Überblick über die wesentlichen Prozesse sowie deren Schnittstellen untereinander und zu den Kunden zu ermöglichen • ein Instrument, das sich hervorragend dazu eignet, neuen Mitarbeitern schnell, übersichtlich und vollständig einen Überblick über die wichtigsten Prozesse der Unternehmung zu vermitteln sowie ihr zukünftiges Tätigkeitsfeld im Gesamtkontext ein- und abzugrenzen • ein relativ statisches und stabiles Gebilde, da logische Abhängigkeiten und auch evtl. nicht realisierte bzw. implementierte Prozesse dargestellt werden

Das Referenzmodell in der Praxis

33

• ein Instrument, das aufgrund der Visualisierung gut kommuniziert, verteilt und eingesetzt werden kann • ein Instrument, das auch eine hohe Außenwirkung hat, wenn Kunden, Lieferanten etc. das „Funktionieren“ der Unternehmung erläutert werden soll Was ein Referenzmodell nicht ist Ein Referenzmodell ist: • kein Ist-Modell, also die Beschreibung der implementierten Ist-Situation • kein Soll-Modell, also die Beschreibung der zukünftig zu implementierenden Ist-Situation • keine Detailvorgabe für die Implementation von Workflows (Arbeitsabläufen) • kein Ersatz für ein Qualitäts-Management-System (es kann höchstens ein Bestandteil davon sein) • kein theoretisches Werk (soweit es bzgl. Begrifflichkeiten, Definitionen etc. auf das eigenen Unternehmen angepasst ist) • kein Instrument der Aufbauorganisation (es lässt sich daraus nicht direkt eine Aufbauorganisation ableiten) • kein Instrument, das nur von Spezialisten für Spezialisten erstellt werden kann • kein Garant für eine optimale Prozessorganisation Für die Entwicklung eines Referenzmodells muss in drei Bereichen ein gemeinsames Verständnis geschaffen werden: 1. Was ein Referenzmodell für das Unternehmen darstellt und was nicht 2. Eindeutige Definition und Verwendung der im Unternehmen verwendeten Begrifflichkeiten (gemeinsame Sprache) 3. Ein gemeinsames Prozessverständnis

34

Modellkonzept und Methodik

Prozessverständnis Prozessdefinition Da eine Vielzahl von Prozessen in einem Unternehmen existiert, stellt sich rasch die Frage: Wie sind Prozesse definiert und nach welcher Systematik lassen sie sich ordnen? Die Beantwortung dieser scheinbar einfachen, aber wichtigen Frage stellt sich in der Praxis als schwierig heraus. Diese Schwierigkeiten ergeben sich aus dem Verständnis heraus, was Prozesse eigentlich sind und wie sie im Unternehmen funktionieren. Bevor in der Folge der Begriff Prozess definiert wird, ist es wichtig, zu verstehen, wie in den meisten Fällen das Prozessverständnis erlebt und geprägt wird. Die ersten Erfahrungen damit entwickeln sich, wenn man eine Aufgabe, eine Arbeit, erstmals selbständig erledigen muss. Der erste Schritt ist die Planung des Vorgehens. Dies umfasst die Fragen: • Was benötige ich? • Wann beginne ich? • Was tue ich in welcher Reihenfolge? • Wann bin ich fertig? Damit wird das Grundgerüst eines Prozesses erfahren, nämlich dass Tätigkeiten in einer mehr oder weniger festgelegten Reihenfolge (Kette), in vielen Fällen sequenziell, manchmal auch parallel, durchgeführt werden. Weiter lernt man, • dass etwas diesen Ablauf auslöst, • dass bestimmte Voraussetzungen vorliegen müssen, • dass ein bestimmtes Ergebnis vorliegen muss, welches anzeigt, dass die Aufgabe abgeschlossen ist. Stellt man dies grafisch dar, zum Beispiel am Prozess der PC-Bestellung, erhält man folgendes typisches Bild6: 6

Die in der Folge dargestellten Abläufe, insbesondere die verwendeten Begrifflichkeiten und Bezeichnungen sind identisch mit denen, die im ProzessReferenzmodell verwendet werden. Dies hat den Vorteil, dass keine neuen bzw. zusätzlichen Elemente verwendet werden. Allerdings wirken die Beispiele, zumindest zu Beginn, ein wenig hölzern.

Prozessverständnis

Abb. 4. PC Bestellprozess, Aufgabenkette

35

36

Modellkonzept und Methodik

Eine weitere Erfahrung ist, dass bestimmte Voraussetzungen wie z.B. das Vorhandensein bestimmter Ausgangsmaterialien erfüllt sein müssen, damit eine Aufgabe ausgeführt werden kann und dass nach Abschluss der Aufgabe ein Ergebnis vorliegt. Dies gilt unabhängig davon, ob ein Servicebericht erstellt wird (Aufgabe), bei dem mit Papier und Stift ein geschriebenes Dokument entsteht oder ob es sich um die Aufgabe der Durchführung einer Installation handelt, bei der aus den Ausgangsmaterialien – Auslieferungspaket und Installationsanleitung – das Ergebnis eines betriebsbereiten PCs und einer leeren Kartonschachtel produziert wird.

Abb. 5. PC Bestellprozess, erweiterte Aufgabenkette

Prozessverständnis

37

Grafisch dargestellt führt dies zu einer Erweiterung der vorhergehenden Abbildung, wobei nur die Tätigkeit „Auslieferungspaket zusammenstellen“ ergänzt wurde, damit die Abbildung übersichtlich bleibt. Interessant sind jetzt noch die Fragen, was einen Prozess auslöst und was ihn abschließt. Im wirklichen Leben gibt es die in der Grafik dargestellten Elemente „Start“ und „Ende“ nämlich nicht. Viele Prozessdokumentationen beinhalten jedoch diese zwei Elemente und machen somit keine Aussage darüber, was den Prozess tatsächlich startet bzw. auslöst. Es gibt immer mindestens ein Ereignis, welches den Start eines Prozesses auslöst, und mindestens ein Ereignis, das einen Prozess abschließt. Der Begriff „Ergebnis“ wird in diesem Zusammenhang synonym für ein Ereignis verwendet, das aus einer Tätigkeit resultiert. Wie der folgenden

Abb. 6. PC Bestellprozess, erweitert um Ereignisse

38

Modellkonzept und Methodik

Abbildung zu entnehmen ist, hat ein Prozess mehrere Ergebnisse, die wiederum auslösende Ereignisse für Folgeaktivitäten sind. In unserem Beispiel „PC-Bestellung“ ist das Startereignis die Anfrage eines Kunden nach einer Leistung (hier die Bestellung eines PCs). Das Ende des Prozesses ist das Ereignis „Servicebericht erstellt“. Die vorhergehende Abbildung wurde dahingehend ergänzt, dass sowohl die Startund Endereignisse des Prozesses als auch wichtige Ereignisse, welche eine Änderung des Bearbeitungsstatus anzeigen, zugefügt wurden. Ein Prozess ist eine durch 1 bis n Ereignisse angestoßene Aufgabenkette, die 1 bis n Ereignisse und 1 bis n Leistungen hervorbringt. Bereits hier kann festgehalten werden, dass sich Prozessstrukturen in der Realität als komplexere Gebilde darstellen, als die meisten Menschen vermuten, die in der Regel einen Prozess auf eine Struktur analog der vorhergehenden Abbildungen reduzieren. Es wird an dieser Stelle nicht auf weitere innere Elemente einer Prozessbetrachtung wie z.B. Entscheidungen und Iterationen oder auf Messgrößen wie Bearbeitungs- und Liegezeiten etc. eingegangen, da diese für die weitere Diskussion nicht benötigt werden. In der Folge werden zwei Fragestellungen diskutiert, die in der Praxis immer wieder zur Verwirrung führen und insbesondere Einfluss auf die Fragestellung der systematischen Ordnung von Prozessen nehmen. Die eine ist das Prinzip der Schachtelung und die andere die Problematik der Abgrenzung. Schachtelung von Prozessen Das Prinzip der Schachtelung ist ein einfaches Verfahren, um Prozessdarstellungen, die eine große Anzahl einzelner Aufgaben enthalten, zu vereinfachen. Abbildung 7 stellt dieses Verfahren schematisch dar. Das Prinzip ist einfach: Es werden mehrere Aufgaben zusammengefasst und mit einer Bezeichnung versehen, die alle darin beschriebenen Aufgaben umfasst. In der Abbildung wurden die ersten vier Aufgaben unter dem Begriff „Sales“ und einem Prozesssymbol zusammengefasst. Damit reduziert sich die Darstellung dieser Tätigkeiten von vier auf ein Element. Es wurde eine zusätzliche Gliederungsstufe (Abstraktionslevel) eingeführt. Theoretisch können so unendliche viele Gliederungsstufen geschaffen

Prozessverständnis

39

Abb. 7. Prinzip der Schachtelung von Prozessen

werden. Für die Schachtelung gibt es keine festen Regeln, sie erfolgt immer willkürlich aufgrund von subjektiven Überlegungen. Die Vorteile liegen in der Möglichkeit, eine Vielzahl von Aufgaben zu einigen wenigen Elementen zusammenzufassen, d.h. man gewinnt einerseits an Überschaubarkeit, verliert aber an Detailtiefe. Je geringer die Schachtelungstiefe (Grad der Gliederung), desto mehr überwiegen die Vorteile. Eine optimale Gliederungstiefe liegt bei drei bis vier Ebenen und selbst da verliert man, wie die Praxis zeigt, schnell die Übersicht. Auf dem Prinzip der Schachtelung basieren auch so nichtssagende Prozessbezeichnungen wie Teil- und Unterprozesse, da diese oft nur Synonyme für Gliederungsstufen sind. Abgrenzung von Prozessen Eine der wohl spannendsten Fragestellungen ist die Frage der Prozessabgrenzung. Das heißt: • Wo beginnt ein Prozess? • Wo endet er? • Welche Aufgaben, Ereignisse und Ergebnisse gehören zu ihm? Um diese Fragen zu beantworten, müssen wir uns nochmals bewusst machen, dass ein Prozess aus einer Kette von Aufgaben besteht. Jede Aufgabe wird durch ein Ereignis angestoßen. Dieses Ereignis kann materieller oder immaterieller Natur sein. Mit dem Abschluss einer Aufgabe entstehen ein oder mehrere immaterielle und / oder materielle Ergebnisse, die wiederum selbst als Ereignisse wirken können. Diese stoßen dann wieder Aufgaben-

40

Modellkonzept und Methodik

Abb. 8. Vernetzung des Bestellprozesses

ketten, also Prozesse, an. Auf der Basis der Ereignisse kann die Abgrenzung eines Prozesses erfolgen. Somit kann man davon ausgehen, dass in der Realität viele Aufgaben in Form eines Netzwerks miteinander verknüpft sind. Für die Prozessabgrenzung gibt es keine festen Regeln. Der Beginn und der Abschluss eines Prozesses sind oftmals noch einfach bzw. nachvollziehbar festzulegen. Schwieriger gestaltet sich die Frage, was alles dazugehört und was nicht. Einen wesentlichen Einfluss auf die Prozessdefinition nimmt die jeweilige Sichtweise ein. Eine weit verbreitete Sichtweise ist z.B. die, dass ein Unternehmen oder eine organisatorische Einheit die Prozessgrenzen vorgibt. Hierzu ein Beispiel: Die Firma Auto AG produziert Autos. Die Motoren werden von einer Fremdfirma, der Motor AG, hergestellt. In der Auto AG wird z.B. der Bestellprozess durch eine Aufgabe abgeschlossen, deren Ergebnis eine Motorbestellung ist. Der Eingang der Motorbestellung bei der Motor AG ist das Ereignis, welches den entsprechenden Produktionsprozess anstößt. Das Ergebnis und der Abschluss dieses Prozesses ist ein Motor. Das Ereignis Motor produziert aktiviert bei der Motor AG den Lieferprozess, welcher durch die Lieferung des Motors abgeschlossen wird. Das Ereignis Motor geliefert startet dann den entsprechenden Einbauprozess bei der Auto AG.

Prozessverständnis

41

Abb. 9. Prozessnetzwerk

Werden hier die Prozesse aus der Sicht der einzelnen Unternehmen betrachtet, sind die Prozessgrenzen eindeutig. Die Auto AG bestellt und erhält Motoren. Die Motor AG erhält Bestellungen, produziert Motoren und liefert diese aus. Löst man sich von dieser Sichtweise und betrachtet z.B. den gesamten Autoproduktionsprozess, ergibt sich ein in sich geschlossener Produktionsprozess, der die Prozesse der Lieferanten mit einschließt. Ein beliebter Ansatz ist die so genannte End-to-End-Betrachtung. Hier geht man davon aus, dass ein Prozess von dem auslösenden Objekt im Sinne eines Ausgangspunktes, z.B. Kunde bestellt Produkt, bis zum Endpunkt, Kunde erhält Objekt, verfolgt wird. Bleiben wir bei dem Autobeispiel: Das auslösende Ereignis ist die Bestellung des Autos durch den Kunden. Mit der Übergabe des Fahrzeuges an den Kunden ist der Prozess abgeschlossen. Bei der End-to-End-Betrachtung werden die organisatorischen Abgrenzungen innerhalb von Unternehmen oder auch über Unternehmen hinweg aufgehoben.7 7

Dieser an sich logische Ansatz ist in der Praxis immer dann schwer umzusetzen, wenn mehrere Prozessteilnehmer, die nicht zwingend der gleichen Interessens-

42

Modellkonzept und Methodik

Eine Prozessdefinition ist ein mehr oder weniger willkürlich gewählter Ausschnitt von miteinander vernetzten Aufgaben bzw. Aufgabenketten. Sie stellt damit immer einen Ausschnitt aus einem größeren Netzwerk dar.

Ordnungs- und Klassifizierungssystem Gliederungsebenen Für die systematische Strukturierung verwenden wir ein Ordnungs- und Klassifizierungssystem, welches auf einer hierarchischen Gliederung und einer thematischen Klassifizierung basiert. Die Beschreibung von Prozessen erfolgt i.d.R. „top down“, vom Groben zum Feinen. Hierbei wird das Prinzip der vorher beschriebenen Schachtelung verwendet. Es entstehen verschiedene Betrachtungsebenen, deren

Abb. 10. Gliederungsebenen gruppe zugehören, involviert sind. So ist dies zwar auf der konzeptionellen Ebene machbar, eine Optimierung aus Gesamtprozesssicht scheitert dann aber oft aufgrund individueller Interessenlagen.

Ordnungs- und Klassifizierungssystem

43

unterste die Detailbeschreibung beinhaltet. Alle Prozessdarstellungen der oberen Ebenen sind im Prinzip Blackboxes, da sie keine Informationen über die jeweils betroffenen Ereignisse, Aufgaben und Leistungen der darunter liegenden Ebenen sichtbar machen. Wie bereits erwähnt, nehmen die Nachteile, und hier insbesondere die Unübersichtlichkeit, mit der Schachtelungstiefe zu. Aus diesem Grund konzentrieren wir uns auf drei Gliederungsebenen, die wir als Top-, Makro- und Mikro-Level bezeichnen. In diesem Buch beschreiben wir die Prozesse auf dem Top- und auf dem Makro-Level. Der Mikro-Level beinhaltet die meist sehr umfangreiche Detailbeschreibung. Während der Top- und Makro-Level eine hohe Abstraktion aufweisen, entspricht der Mikro-Level in seiner Detaillierung einer Arbeitsanweisung. Neben dem hierarchischen Ordnungssystem erfolgt parallel eine auf den Top-Level beschränkte, zweistufige thematische Kategorisierung der Prozesse. Die erste Ebene wird als Prozessbereich bezeichnet. Die zweite Ebene wird als Prozesskategorie, in der thematisch zusammengehörende Prozesse gruppiert werden, definiert. Die Prozesskategorien beinhalten 1 bis n Prozesse, die auf dem MakroLevel als Hauptprozesse bezeichnet werden. Das Präfix „Haupt-“ beschreibt somit lediglich die oberste Strukturierungsebene und sagt nichts über die Priorität oder Wertigkeit dieses Prozesses aus. Die folgende Abbildung zeigt das Ordnungs- und Klassifizierungssystem in der Übersicht:

Abb. 11. Darstellung des Top- und des Makro-Levels

44

Modellkonzept und Methodik

Lesebeispiel Top-Level: Der Prozessbereich Support beinhaltet die Prozesskategorien Configuration Management, Change Management und Problem Management. Lesebeispiel Makro-Level: Das Problem Handling ist ein Hauptprozess, der zu der Prozesskategorie Problem Management gehört, der dem Prozessbereich Support zugeordnet ist. Die Hauptprozesse werden in verdichteter Form (ein Prozesspfeil) oder in aufgelöster Form (mehrere Prozesspfeile) dargestellt. Eine Auflösung erfolgt, wenn die wichtigsten Aufgaben oder Aufgabenketten eines Hauptprozesses aufgezeigt werden sollen. Die Hauptprozesse des Makro-Levels umfassen nur die für das Verständnis notwendigen Prozesselemente wie auslösende und abschließende Ereignisse, die wichtigsten Aufgaben, Aufgabenketten und Leistungen (Input, Output). Eine detaillierte Auflösung der Hauptprozesse erfolgt auf dem Mikro-Level8. Die folgende Abbildung beinhaltet diese Detaillierung.

Abb. 12. Vergleich Darstellung Makro-, Mikro-Level

Die Darstellung der Prozesse auf dem Mikro-Level entspricht in der Praxis einer detaillierten Beschreibung des Arbeitsablaufes (Workflow), wie sie z.B. klassischerweise in QM-Handbüchern oder Arbeitsanweisungen erfolgt oder auch als Designvorlage für die Umsetzung in einer IT-unter8

Die Erklärung der einzelnen grafischen Elemente erfolgt in den folgenden Kapiteln.

Ordnungs- und Klassifizierungssystem

45

stützten Lösung Verwendung findet. Methodisch gesehen wird der MikroLevel noch um diverse grafische und / oder beschreibende Elemente wie z.B. Elemente für Entscheidungen oder Verzweigungen erweitert. Das Prozess-Referenzmodell beschreibt die Prozesse ausschließlich auf dem Topund Makro-Level. Nummerierungssystem Für die Identifikation der einzelnen Prozesse und die Herstellung von Verknüpfungen zwischen den einzelnen Prozessen verwenden wir ein einfaches Nummerierungssystem. So sind die einzelnen Prozessbereiche mit einer einstelligen Nummer, in unserem Fall von 1 für den Prozessbereich Management bis 7 für den Prozessbereich Logistics & Infrastructure, versehen. Die Prozesskategorien haben zweistellige Nummern, wobei die erste von dem jeweiligen Prozessbereich vorgegeben wird. Die zweite Stelle ist dann wieder fortlaufend. Also z.B. 11 für ICT Supplier Management, 12 für ICT Program Management und 71 für das ICT Continuity Management. Die Hauptprozesse wiederum werden über dreistellige Zahlen9 identifiziert, wobei die erste Zahl den Prozessbereich, die zweite die Prozesskategorie identifiziert und die dritte Zahl wieder fortlaufend ist. Beispiele: 111 Partner Management, 112 Supplier Contract Management und 113 Supply Chain Management. Der Einsatz dieses Systems ist am einfachsten anhand des Posters nachzuvollziehen. Bei der isolierten Betrachtung eines Prozesses sind so die vorangehenden und die folgenden Prozesse eindeutig identifizierbar. Weiter vereinfacht die grafische Darstellung des gesamten Prozess-Referenzmodells auf dem Makro-Level das System, da eine Vielzahl von Verbindungslinien, die in diesem Fall das Bild unleserlich gemacht hätten, eingespart werden konnten.10

9

Was tun, wenn die einstellige Zahl nicht ausreicht, da z.B. mehr als neun Prozessbereiche definiert werden? Grundsätzlich kann das gleiche System verwendet werden, allerdings empfiehlt es sich dann, die Schreibweise anzupassen, z.B. 11-12-15 (es handelt sich um den Hauptprozess Nr.15 in der Prozesskategorie Nr.12 im Prozessbereich Nr. 11).

10

Beim Einsatz einer entsprechenden IT-Lösung gibt das System i.d.R. die Identifikationsschlüssel für die einzelnen Elemente vor und es empfiehlt sich, diese Vorgabe zu übernehmen.

46

Modellkonzept und Methodik

Die wichtigsten Prozesselemente Die wichtigsten in diesem Buch für die Beschreibung und Darstellung von Prozessen verwendeten Symbole und Begriffe sind in der folgenden Abbildung zusammengefasst.

Abb. 13. Prozesselemente für die grafische Darstellung

Ein Ereignis beschreibt einen erreichten bzw. eingetroffenen Zustand. Es ist immer das Ergebnis einer vorangegangenen Aktivität. Die Besonderheit eines Ereignisses besteht darin, dass eine Vielzahl von Kriterien definiert werden kann, damit das Ereignis als eingetroffen gilt bzw. der entsprechende Zustand erreicht wurde. Ein Ereignis löst eine Aufgabe aus oder schließt eine Aufgabe als Ergebnis ab. Ohne Ereignis kann kein Prozess gestartet oder abgeschlossen werden. Auch die Zeit kann ein Ereignis sein. Es kann einmalig, z.B. am 26.02.2007 um 7:00 Uhr oder periodisch, z.B. jedes Monatsende, stattfinden.

Eine Aufgabe ist eine betriebliche Funktion / Tätigkeit. Die Aufgabe wird aufgrund eines auslösenden Ereignisses gestartet und verarbeitet und / oder erzeugt 1 bis n Leistungen und schließt mit einem Ereignis ab. Eine Aufgabe kann manuell oder automatisiert ausgeführt werden.

Ordnungs- und Klassifizierungssystem

Die logischen Operatoren beschreiben die Verknüpfung von Ereignissen. Dabei wird zwischen der Verknüpfung der Eingänge in einen Operator und der Verknüpfung der Ausgänge unterschieden. Beide können durch die logische „und / oder“bzw. nur „oder“-Beziehung verknüpft werden. In einer vereinfachten Form der EPK (Ereignisgesteuerte Prozesskette) entfallen die Eingangsoperatoren und die Ausgangsoperatoren werden durch eine Entscheidung ersetzt.

Ein Hauptprozess ist ein Prozess auf dem Makro-Level. Er wird entweder in verdichteter Form oder in aufgelöster Form (mehrere Prozesspfeile) dargestellt. Er besteht im Minimum aus dem prozessauslösenden Ereignis, einer Aufgabe oder einer Aufgabenkette sowie aus dem prozessabschließenden Ereignis. Eine Aufgabenkette besteht aus einer logischen Sequenz von Aufgaben. Aufgabenketten werden auf der Makro- und Mikro-Ebene dargestellt.

Eine Rolle wird neutral, ohne direkten Bezug zu einer Organisationseinheit oder einer Person, durch vorher ausgewählte Merkmale (z.B. Aufgaben, Kompetenzen und Verantwortung) definiert. Es wird zwischen externen Rollen (z.B. Lieferant) und internen Rollen (z.B. Management) unterschieden.

Eine Leistung ist der Output einer Aufgabe. Dieser Output kann immaterieller oder materieller Natur sein. Empfänger bzw. Erbringer einer Leistung können ein anderer Prozess oder eine Rolle innerhalb bzw. außerhalb des Unternehmens sein. Dort wird die Leistung zum Input für die nachfolgenden Aufgaben.

47

48

Modellkonzept und Methodik

Grundstrukturen Kontextdiagramm Die methodische Vorgehensweise für die Entwicklung des Modells entspricht einem Top-down-Vorgehen. Bildlich gesehen handelt es sich hierbei um eine • von oben nach unten, • von außen nach innen, • vom Groben zum Feinen, • vom Gesamten zum Detail verlaufende, ständige Verfeinerung, wobei die oberste Ebene jeweils das Gesamtsystem darstellt. Stellen Sie sich als Beispiel die Betrachtung des Planeten Erde aus dem Weltraum vor. Sie sehen zuerst das gesamte System Erde mit den Polen, Kontinenten und den Meeren. Im nächsten Schritt gehen Sie tiefer und sehen nun nur noch einen Kontinent. Sie sehen nun zwar das System Erde in seiner Gesamtheit nicht mehr, aber dafür mehr Details des Kontinents. Die nächste Betrachtungsebene liegt noch tiefer, so dass Sie nur noch eine Region und nicht mehr den gesamten Kontinent überblicken. D.h. mit jeder Stufe, die Sie tiefer gehen, erhalten Sie mehr Details, verlieren aber die Übersicht über das Ganze. Wenn Sie sich die Reihenfolge umgekehrt vorstellen, wenn Sie in der Zukunft vielleicht einmal die Erde in Richtung Mond verlassen, haben Sie den umgekehrten Ansatz: „bottom up“, vom Detail zur Übersicht. Für unser Referenzmodell definieren wir als oberste Ebene das System ICT-Unternehmen. Auf der Modellebene spielt es hierbei keine Rolle, ob unser Unternehmen in der Wirklichkeit aus einem oder mehreren Unternehmungen besteht, welche Rechtsform diese haben oder ob es sich um eine oder mehrere Organisationseinheiten innerhalb einer Firma handelt. Ein System erklärt sich durch die Elemente, die als zum System dazugehörend definiert werden, und durch die Elemente, die sich außerhalb des Systems befinden. Da uns natürlich nur die Elemente interessieren, mit denen unser System in Interaktion tritt, ist deren Anzahl reduziert und endlich. Elemente, die zu unserem System „Unternehmen“ gehören, sind z.B. die Prozesse der Unternehmung, die Mitarbeiter, die Maschinen etc. Elemente, die sich außerhalb des Systems Unternehmen befinden, sind z.B. Kunden, Lieferanten, Geschäftspartner aller Art, Prozesse anderer Unternehmen etc.

Grundstrukturen

49

Mit der Definition der externen Elemente, mit denen unser System in Interaktion tritt, beschreiben wir den Kontext und die Beziehungen unseres Unternehmens zur Umwelt, womit wir auch gleichzeitig die Möglichkeit haben, die wichtigsten Schnittstellen unseres Systems zu identifizieren. Grafisch dargestellt erhalten wir ein so genanntes Kontextdiagramm, welches den Kontext auf dem Top-Level unseres Prozess-Referenzmodells darstellt.

Abb. 14. Kontextdiagramm

Das Kontextdiagramm stellt die oberste Ebene des Referenzmodells, die Interaktion und damit die wichtigsten Schnittstellen des Unternehmens zu seiner Umwelt dar. Die externen Elemente werden als Rollen dargestellt. Wie diese Rollen intern organisiert sind, wie sie funktionieren, welche Personen dies sind etc., ist für die Betrachtung nicht relevant. Aus Sicht unseres Systems interessiert uns lediglich, welche Ereignisse und Leistungen im Sinne des Inputs wir von den externen Rollen erhalten und welche Ereignisse und Leistungen unser System für die externen Rollen produziert. Struktur des Top-Levels Ein Unternehmensmodell kann aus diversen Sichten betrachtet werden. Unser Referenzmodell konzentriert sich primär auf die Prozesssicht. In der

50

Modellkonzept und Methodik

Literatur und in verschiedenen Organisationslehren sind unterschiedliche Ansätze für die Kategorisierung von Prozessen zu finden. Beispiele hierfür sind Kategorien mit Bezeichnungen wie Kernprozess, Support- oder Unterstützungsprozess, Führungs- oder Steuerungsprozess, Haupt-, Neben- und Unterprozess und dergleichen. Allgemeingültige Merkmale für eine Ordnung sind schwer zu finden, die Definitionen sind in der Regel nicht ausreichend, um alle Varianten abzudecken, und bereits die Verwendung eines bestimmten Präfixes kann aufgrund unterschiedlicher Interpretation zu Irrtümern führen. Aus diesem Grunde wird auf diese Art der Kategorisierung und der Verwendung von Bezeichnungen, die eine bestimmte Wertigkeit oder Bedeutung implizieren, verzichtet. Das von uns verwendete Ordnungs- und Klassifizierungssystem ist im gleichnamigen Kapitel beschrieben. Der Top-Level wird in so genannte Prozessbereiche, die sich an typischen Unternehmensfunktionen orientieren, aufgeteilt. Unser Referenzmodell für ICT-Unternehmen unterscheidet sieben Bereiche: 1. 2. 3. 4. 5. 6. 7.

Management Sales Customer Services Project & Development Support Operations Logistics & Infrastructure

In den einzelnen Prozessbereichen werden in der Folge Prozesse in so genannten Prozesskategorien zusammengefasst. Die Darstellung des TopLevels besteht aus einer Kombination des Kontextdiagramms und der TopLevel-Struktur. Die folgende Abbildung 16 beinhaltet die Struktur des Top-Levels unseres Prozess-Referenzmodells. Es umfasst die bereits genannten 7 Prozessbereiche sowie 25 Prozesskategorien, die insgesamt 75 Hauptprozesse beinhalten. Darstellung von Prozessketten Wir verwenden zwei Varianten für die Darstellung von Prozessketten: • Verknüpfungsübersicht und • Makroprozess. Vor allem die letztgenannte bildet die Basis des Prozess-Referenzmodells.

Grundstrukturen

Abb. 15. Prozessbereiche ICT-Unternehmen (Top-Level)

Abb. 16. Prozessbereiche und ihre Prozesskategorien (Top-Level)

51

52

Modellkonzept und Methodik

Verknüpfungsübersicht Auf dem Top-Level werden Prozesse (Prozesskategorien) als Blackbox dargestellt. Hier liegt der Schwerpunkt auf der Darstellung der Verknüpfungen der Prozesse innerhalb des Systems. Für die Darstellung von Prozessketten, d.h. der Verknüpfung von Prozessen, verwenden wir lediglich die prozessauslösenden bzw. -abschließenden Ereignisse. Diese werden mit den vor- bzw. nachgelagerten Prozessen oder Rollen verknüpft. Diese Darstellungsform wird im Buch vor allem in den Kapiteln, in denen die Prozesskategorien und ihre Prozesse beschrieben werden, verwendet. Die Darstellungsform hat den Vorteil, dass sie die in der Mitte befindlichen Prozesse als Blackbox behandelt und somit die Konzentration auf die Schnittstellen (Verknüpfungen) ermöglicht.

Abb. 17. Darstellung der Prozess-Verknüpfungen

Makroprozess Auf dem Makro-Level werden wieder die prozessauslösenden bzw. -abschließenden Ereignisse sowie die wichtigsten Aufgaben bzw. Aufgabenketten in Prozesspfeilen dargestellt. Die Zahlen, die bei den Ereignissen stehen, stehen für die vor- bzw. nachgelagerten Prozesse. Ereignisse, welche mit gestrichelter Linie gezeichnet sind, sind Ereignisse, die aus der gleichen

Grundstrukturen

53

Prozesskategorie stammen. Ereignisse, die mit einem dicken Rand gekennzeichnet sind, sind Start- oder Endereignisse, die von außerhalb des Unternehmens kommen bzw. es verlassen. Diese Ereignisse sind also mit Rollen oder Prozessen des Kontextes verbunden. In der folgenden Abbildung ist neben den erwähnten Symbolen und Darstellungsarten auch auf das Symbol der Uhr zu achten. Diese symbolisiert ein Zeitereignis, welches einen fixen Zeitpunkt oder auch ein periodisches Vorkommen (z.B. täglich, wöchentlich etc.) beschreibt.

Abb. 18. Darstellungsform Makro-Level

Die Darstellungsform für den Makro-Level wird speziell für die Abbildung der Prozesse im Prozess-Referenzmodell (siehe Poster) verwendet. Die Zahlen vor dem Ereignis verweisen auf die vorhergehenden Prozesse, dort wird das Ereignis erzeugt. Die Zahlen hinter einem Ereignis verweisen auf die Prozesse, die von diesem Ereignis angestoßen werden. Auf dem Weg zur Detailbeschreibung wird die Prozessdarstellung Schritt für Schritt um weitere Informationseinheiten erweitert. In der folgenden Abbildung wurde die Prozessdarstellung um drei weitere Darstellungselemente, Rollen, Leistungen (In- / Output) und Entscheidungen, erweitert. Dies steigert einerseits die Aussagekraft, da wesentlich mehr Informationen abgebildet werden. Andererseits erhöht es die Komplexität und verhindert damit die Betrachtung größerer Zusammenhänge. Das beigelegte Poster des ProzessReferenzmodells umfasst 1030 grafische Elemente (Ereignisse und Aufgaben). Würde es analog der folgenden Abbildung erweitert, würde sich die Anzahl der Elemente auf rund 5000 erhöhen.

54

Modellkonzept und Methodik

Abb. 19. Ergänzung mit Leistungen, Rollen und Entscheidungen

End-to-End-Betrachtung Eine End-To-End-Betrachtung eines Prozesses geht von dem Anspruch aus, dass ein Prozess von dem auslösenden Ereignis, wie z.B. Kunde bestellt ein Produkt, bis zu dem abschließenden Ereignis Kunde erhält das bestellte Produkt betrachtet wird. Dabei erfolgt eine Konzentration auf die Aufgaben, die für diesen Prozess wesentlich sind. In der Praxis entzündet sich oft an dieser Forderung die Diskussion, was wesentliche Aufgaben sind und welche nicht. Die Abgrenzung des Prozesses ist nicht immer einfach, da dieser wie oben dargestellt in ein Prozess-Netzwerk eingebettet ist. Nach gängiger Meinung erfolgt eine End-to-End-Betrachtung auch über Unternehmensgrenzen hinweg. D.h., wenn ein Teil der Produktfertigung z.B. außerhalb des Unternehmens bei einem oder gar mehreren Lieferanten erfolgt, sind diese Prozessabschnitte ebenfalls zu berücksichtigen. Für unsere weitere Diskussion gehen wir davon aus, dass die Prozessgrenzen, wie wir sie definieren, von allen akzeptiert werden und dass wir uns bei der End-to-End-Betrachtung nur auf die Prozesse und Aktivitäten konzentrieren, die in unserem Unternehmen (Modell) stattfinden. Ein in der Praxis oft verwendeter Begriff, der eine ähnliche Zielsetzung ausdrückt, ist der Begriff des Geschäftsvorfalls – ein ehemals vorwiegend in der Buchhaltung verwendeter Begriff, der sich heute aber in der Welt

Grundstrukturen

55

der Ablauforganisation etabliert hat. Er beschreibt in der Regel einen spezifischen geschäftlichen Vorgang, der von einem Geschäftspartner ausgelöst wird und zu einer Reaktion innerhalb der Unternehmung führt. Er drückt eine ähnliche Zielsetzung wie die End-To-End-Betrachtung aus, bewegt sich aber ganz klar ausschließlich innerhalb der Unternehmung. Wir verwenden in der Folge Geschäftsvorfall und End-to-End-Betrachtung synonym. Unsere Erfahrungen zeigen, dass der Begriff des Geschäftsvorfalls in den meisten Unternehmen für „jemand will etwas – jemand kriegt etwas“11 bestens etabliert ist und sich damit gut arbeiten lässt. Die interessantesten Geschäftsvorfälle fallen, da meist wertschöpfend, naturgemäß in den Sales- und Service-Bereichen an:

Abb. 20. Position einer End-to-End-Betrachtung im Modell

Wie bereits geschildert sind einzelne Geschäftsvorfälle nicht auf den ersten Blick dem Prozess-Referenzmodell zu entnehmen. Tatsächlich ist aber eine Vielzahl davon im Modell abgebildet. Die folgende Auflistung beinhaltet einen Ausschnitt davon: • Kunde stellt eine (unspezifizierte) Leistungsanfrage • Kunde wünscht eine individuelle Software-Lösung • Kunde möchte Beratung 11

Eine authentische Definition im Rahmen eines Workshops.

56

Modellkonzept und Methodik

• Kunde bestellt ein Standardprodukt (z.B. einen PC) • Kunde bestellt eine Standardschulung • Kunde bestellt permanente Leistungen (z.B. Betrieb und Support einer ICT-Infrastruktur) • Kunde wünscht eine individuelle Schulung • Kunde meldet eine Störung • Kunde reklamiert • Kunde kündigt laufenden Vertrag • Kunde ändert Produktionsaufträge • Kunde will neuen Anwender einrichten • Kunde beauftragt den Umzug seiner ICT-Infrastruktur • Kunde will den Status einer Bestellung wissen • Kunde wünscht Erweiterung eines bestehenden SW-Systems • Kunde wünscht Änderung in laufendem Projekt • Lieferant liefert bestellte Ware • Lieferant kündigt neue Technologie an • Lieferant stellt Rechnung • Lieferant hat Vorschlag für Prozessoptimierung • Lieferant kündigt laufende Verträge • ICT-Unternehmung holt Angebote ein • ICT-Unternehmung bestellt Leistungen • ICT-Unternehmung sucht Kooperationspartner • ICT-Unternehmung will von einem Lieferanten den Bestellstatus wissen Im Kapitel Ausgewählte Geschäftsvorfälle werden die folgenden vier Geschäftsvorfälle im Sinne einer End-to-End-Betrachtung beschrieben: • Geschäftsvorfall 1: Kunde kauft PC • Geschäftsvorfall 2: Betrieb einer ICT-Infrastruktur • Geschäftsvorfall 3: Individuelle Softwareentwicklung • Geschäftsvorfall 4: Kunde meldet Störung

Grundstrukturen

57

Hierzu werden aus dem Prozess-Referenzmodell jeweils die Prozesse und deren Aufgaben isoliert, die im Fall des jeweiligen Geschäftsvorfalls benötigt werden. Leseübung Prozess-Referenzmodell Auf der Basis des in diesem Kapitel beschriebenen Methodenansatzes können Sie nun problemlos das Prozess-Referenzmodell lesen. Schlagen Sie nun zur Probe das Poster auf. Auf den ersten Blick sollten Sie sofort die sieben Prozessbereiche erkennen; achten Sie auf deren Nummerierung von 1 bis 7. In den einzelnen Prozessbereichen sehen Sie nun bereits die aufgelösten Hauptprozesse, die jeweils eine dreistellige Nummer tragen; jeder Hauptprozess ist dabei einer Prozesskategorie (zweistellige Nummer) zugeordnet. Suchen Sie nun den Hauptprozess 411 Change Handling. Aufgrund der ersten Zahl wissen Sie, dass Sie den Prozess im Prozessbereich Support finden, aufgrund der ersten zwei Zahlen gehört er zur Prozesskategorie 41 Change Management und hierunter befindet sich der Hauptprozess 411 Change Handling. Der Hauptprozess 411 wird von dem Ereignis RFC formuliert angestoßen. Anhand der Zahlen neben dem Ereignis sehen Sie die Vielzahl der Prozesse, in denen ein RFC formuliert wird. Wenn Sie nun noch den Prozess 211 Sales Management aufsuchen, finden Sie das auslösende Ereignis Leistungsanfrage formuliert. Da es fett umrandet ist, stellt dieses Ereignis einen Eingang von außerhalb, in diesem Fall von einem Kunden, dar. Das gleiche Ereignis kann aber auch im Prozess 621 Contact Management erzeugt werden. Wenn Sie nun zu dem Prozess „PC-Bestellung“ aus den ersten drei Abbildungen zurückblättern, sollten Sie in der Lage sein, die dort gezeigten Aufgaben und Ereignisse im Prozess-Referenzmodell zu verfolgen. Anglizismen im Prozess-Referenzmodell Der gesamte ICT-Bereich wird von der englischen Sprache dominiert. Viele Anglizismen sind in unseren Sprachgebrauch bereits fest integriert (wie Software) oder befinden sich in Konkurrenz mit den entsprechenden deutschen Übersetzungen (Software-Verteilung / Software Distribution). Den Sprachenmix konnten wir zwar nicht vermeiden, aber zumindest systematisieren. So haben wir uns zum Ziel gesetzt, alle Bezeichnungen

58

Modellkonzept und Methodik

bis auf die Makroebene inkl. der Hauptprozesse mit entsprechenden Anglizismen zu versehen. Bei allen methodischen Elementen, Ereignissen, Aufgaben, Leistungen etc. überwiegen die deutschen Formulierungen.

ICT Company

Fiktives Unternehmen Das Prozess-Referenzmodell orientiert sich an einem fiktiven MusterUnternehmen, das wir als ICT Company bezeichnen. Neben ihre Prozessen wird eine Unternehmung unter anderem auch durch die folgenden Aspekte repräsentiert: • Leistungen / Produkte • Struktur (Aufbauorganisation) • Begriffswelt Ziel des Kapitels ist es, für diese drei Themenbereiche die Inhalte soweit vorzugeben, dass das Prozess-Referenzmodell in einen Gesamtzusammenhang gebracht werden kann. Bei der Konstruktion dieser fiktiven Unternehmung haben wir vor allem darauf geachtet, dass die Inhalte quasi allgemeingültig sind und auf jedes ICT-Unternehmen übertragbar sind. Weiter gehen wir davon aus, dass die folgenden Inhalte unabhängig davon sind, ob die ICT Company als eigenständiges Unternehmen oder in Form einer firmeninternen Organisationseinheit organisiert ist. Die Unterschiede bzgl. der Einflussfaktoren, die sich aus dem jeweiligen Umfeld ergeben, sind, was die eigentlichen Leistungen der ICT Company betrifft, marginal. Sicherlich sind einzelne Bereiche wie z.B. der Sales-Bereich in einem am freien Markt agierenden Unternehmen stärker gefordert und entsprechend ausgebaut. Auch die Mitarbeiterstruktur wird sich gegenüber einer rein intern orientierten Organisation unterscheiden. Die grundsätzlich notwendigen Prozesse aber, die im Zusammenhang mit einer Kundenbeziehung bestehen, werden in jedem Fall benötigt. Die Schwierigkeit bei der Beschreibung einer Musterunternehmung liegt immer darin, möglichst allgemeingültig zu bleiben. Dies gelingt im Bereich der Leistungen / Produkte auf einem gewissen Abstraktionslevel erstaunlich gut. Schwierig wird es beim Thema der Aufbauorganisation,

60

ICT Company

aber auch hier gibt es verlässliche Anhaltspunkte und diskussionswürdige Grundüberlegungen. Aufs Glatteis begibt man sich im Bereich der Begriffswelt und dies gilt hier genauso wie in der realen Welt.

Die Leistungen / Produkte der ICT Company Die Leistungen / Produkte einer ICT-Unternehmung, so vielfältig sie im Detail auch sind, können in drei Gruppen unterteilt werden:

Abb. 21. Leistungen / Produkte der ICT Company

1. Hier geht es um Leistungen, deren Wertschöpfung primär auf der Erbringung von Arbeitszeit durch die eingesetzten Mitarbeiter basiert.1 Typische Leistungen, die in diese Kategorien fallen, sind: • Bereitstellung und Vermietung (Body Leasing) von Mitarbeitern mit spezifischem Know-how (z.B. Software-Entwickler) • Beratungsleistungen (z.B. Gutachten, Analysen, Konzeptarbeiten)

1

Diese und die unter Punkt 3. beschriebenen Leistungen werden klassischerweise mit einem „Dienstvertrag“ vereinbart.

Die Leistungen / Produkte der ICT Company

61

• Fachspezifische Aus- und Weiterbildung (z.B. Coaching, Referentenstellung) • Allgemeine Kundenserviceleistungen (z.B. Vorort-Support, Reparaturservice, Hotline) 2. Leistungen, deren Wertschöpfung primär auf der Herstellung bzw. dem (Wieder)-Verkauf von „Gewerken“ und direkt damit verbundenen Leistungen basiert.2 Beispiele: • Entwicklung und Implementierung von Individual-Software • Parametrisierung und Implementierung von Standard-Software • Implementierung eines EDV-Netzwerkes • Implementierung einer Telefonanlage • Verkauf von Hardware und Software aller Art inkl. Ersatzteile und Verbrauchsmaterial • Entwicklung von Schulungslösungen • Anbieten von Seminaren 3. Leistungen, deren Wertschöpfung auf der Bereitstellung und dem Betrieb einer ICT-Infrastruktur und der darauf installierten Software sowie den direkt damit verbundenen Leistungen basiert. Typische Beispiele: • Betrieb von Rechenzentren / Serverfarmen und den darauf implementierten Software-Anwendungen. • Betrieb eines Daten- bzw. Kommunikationsnetzwerkes • Betrieb von Kommunikationsanlagen aller Art 2

Der Begriff „Gewerk“ kommt historisch aus dem Handwerkswesen und bezeichnet im Allgemeinen das herzustellende und zu liefernde Werk und alle damit verbundenen Arbeiten. Der Begriff wird heute auch in vielen anderen Branchen verwendet, um die Herstellung eines Werkes, das heißt die Herbeiführung eines bestimmten Erfolges körperlicher oder nichtkörperlicher Art als Leistung zu definieren. Die Leistungen werden auf der Basis eines Werkvertrages vereinbart. Werden Gewerke nur weiterverkauft (Zwischenhandel), werden die Leistungen auf der Basis eines Kaufvertrages erbracht. Gerade in der ICT-Branche ist die Wahl der passenden Vertragsform für den Unternehmenserfolg entscheidend. Während der Besteller die meisten Vorteile aus einem allumfassenden Werkvertrag zieht, ist es für den Lieferanten von Vorteil, die Leistungen zu separieren und in entsprechenden Vertragsformen zu vereinbaren.

62

ICT Company

In der Praxis entsteht durch die Vielzahl der jeweiligen Produkte der Eindruck von hoher Komplexität. Auf die mit den einzelnen Produkten heruntergebrochenen Abläufe bezogen, reduziert sich dieser Eindruck aber schnell auf eine überschaubare Menge benötigter Prozesse. Eine weitere interessante Sicht auf die Leistungen und Produkte ist die folgende: Leistungen / Produkte der oben beschriebenen Gruppen 1 und 2 haben eine wesentliche gemeinsame Eigenschaft: Die Leistungserbringung ist mit der Übergabe des Ergebnisses bzw. des Produktes und dessen Abnahme durch den Kunden für das Unternehmen abgeschlossen bzw. wird in eine zeitlich befristete Garantiephase mit definiertem Ende überführt. Im Gegensatz hierzu steht die quasi permanente Leistungserbringung, die bei Leistungen / Produkten der Gruppe 3 anfällt. Ein Netzwerk, ein Server etc. muss auch dann betrieben werden, wenn gerade kein oder nur wenige User mit den Systemen arbeiten. Die Abnahme der Leistungserbringung ist komplexer und basiert i.d.R. auf einer periodischen Überprüfung vereinbarter Messwerte auf deren Einhaltung bzw. Erfüllung. Die Unterschiede sind für die Umsetzung in einer organisatorischen Struktur äußerst relevant. Leistungen der Gruppe 1 und 2 sind quasi projektorientiert3 zu erbringen. Das zukünftige Arbeitsvolumen und der damit verbundene Ressourcenbedarf sind bereits mittelfristig nur schwer zu kalkulieren. Nachfragespitzen und -täler bzgl. der Produktionsressourcen müssen von der Organisation aufgefangen werden können. Leistungen der Gruppe 3 sind permanent zu erbringen, die Leistungserbringung geschieht mehr unter funktionsorientierten Gesichtspunkten. Das zukünftige Arbeitsvolumen und der Ressourcenbedarf für die leistungserbringende Einheit sind auch langfristig gut kalkulierbar. Die Problematik der Nachfragespitzen und -täler existiert nicht oder weniger ausgeprägt. Die Leistungen / Produkte einer Unternehmung lassen sich in drei Gruppen gliedern: 1. Leistungen, die auf der Basis von Arbeitszeit erbracht und verrechnet werden 2. Leistungen / Produkte mit Gewerk-Charakter, die entweder selbst produziert oder wiederverkauft werden

3

Projektorientiert heißt in diesem Fall: festgelegter Starttermin (z.B. Auftragserteilung) und festgelegter Endtermin.

Die Leistungen / Produkte der ICT Company

63

3. Permanent zu erbringende Leistungen, die auf der Bereitstellung und dem Betrieb so genannter IT-Infrastruktur basieren

Struktur der ICT Company Grundsätzlich gehen wir bei der Prozessbetrachtung von einer End-to-EndBetrachtung aus. Hierbei wird der Prozess von dem Punkt an, der den Prozess im Unternehmen auslöst, bis zu dem Punkt, mit dem der Prozess aus Sicht der Unternehmung abgeschlossen wird, betrachtet. Im Allgemeinen wird hierfür auch der Begriff des Geschäftsvorfalls verwendet. Eine thematische Gliederung von Prozessen mithilfe von Bezeichnungen wie „Unterstützungsprozesse“, „Managementprozesse“, „Kernprozesse“ etc., wie man sie in manch anderen Ansätzen findet, verwenden wir nicht. Die Definition entsprechender Zuordnungskriterien orientiert sich i.d.R. an den Rahmenbedingungen der Unternehmung, ist meist subjektiv und oftmals auch nicht direkt auf vergleichbare Unternehmungen übertragbar. Wird eine Vielzahl von miteinander verknüpften Prozessen betrachtet, wird ab einer gewissen Detaillierungsebene die Anzahl der (grafisch) beschriebenen Elemente so umfangreich, dass schlicht durch ihre Menge die Komplexität derart zunimmt, dass zwecks besserer Lesbarkeit und Zuordnung eine Vereinfachung durch die Zusammenfassung von einzelnen Prozessen notwendig wird. Im Kapitel Modellkonzept und Methodik wird dies unter dem Stichwort Schachtelung von Prozessen beschrieben. Die konsequente Umsetzung der Schachtelung von Prozessen führt zu einer funktionalen Grundstruktur, die in der folgenden Abbildung dargestellt ist. So werden alle Prozesse, die primär funktionale Inhalte haben, die bspw. zum Sales gehören, unter diesem Bereich zusammengefasst. Alle Prozesse, die inhaltlich zur Thematik Services passen, sind in den gleichnamigen Bereich eingeschlossen. Diese einfache Grundstruktur bezeichnen wir als M.I.S.S.O®-Haus4 und diese ist auf jedes Unternehmen anwendbar. So einfach und simpel die Struktur ist, in der Praxis entzünden sich bereits hier leidenschaftliche Diskussionen – obwohl es sich nur um eine Hilfsstruktur handelt, um die Komplexität zu reduzieren.

4

M.I.S.S.O steht für Management, Infrastructure, Sales, Services & Operations.

64

ICT Company

Abb. 22. Das M.I.S.S.O-Haus, Grundstruktur einer Unternehmung

Der Bereich Infrastructure bildet quasi das Fundament der Unternehmung, das Management das Dach. Dazwischen liegen die drei Bereiche, in denen sich die eigentlich wertschöpfenden Prozesse befinden, nämlich die zwei tragenden Säulen Sales und Services sowie der zentrale Bereich Operations, in dem die Prozesse platziert sind, mit denen die Leistung der Unternehmung erbracht bzw. die Produkte hergestellt werden. Eine erweiterte Gliederung dieser Struktur ist, wo sinnvoll und notwendig, empfehlenswert. Unsere Erfahrungen zeigen, dass die äußeren Bereiche unverändert bleiben, dass aber der in der Mitte positionierte, eigentliche „Produktionsbereich“ oft weiter untergliedert wird. Dies ist insbesondere auch bei Unternehmungen der ICT-Branche sinnvoll. Unsere ICT Company hat die in Abbildung 23 dargestellte Grundstruktur, die sich auch im Prozess-Referenzmodell widerspiegelt. Besonders ist hierbei die weitere Gliederung in die Bereiche Project & Development, Production Support sowie Operations5.

5

Hierunter werden nun die typischen ICT Operations, also der Betrieb von Rechenzentren, Servern, Netzwerken, Telefonanlagen etc. verstanden.

Die Leistungen / Produkte der ICT Company

65

Abb. 23. Erweiterte Grundstruktur der ICT Company

Kontext der ICT Company Eine Unternehmung steht im stetigen Wechselspiel mit ihrer Umgebung (ihrem Kontext). Methodisch gesehen werden die Organisationen außerhalb der ICT-Unternehmung als Rollen dargestellt. Die Schnittstellen (siehe auch die folgende Abbildung 24) zwischen der ICT-Unternehmung und ihrem Kontext ergeben sich durch: • die Ereignisse, die außerhalb der ICT-Unternehmung erzeugt werden (z.B. ein Kunde bestellt eine Leistung) und auf die das ICT-Unternehmen reagiert (Entgegennahme der Bestellung, Produktion und Lieferung der Leistung), • die Ereignisse, die einen Prozess innerhalb der ICT-Unternehmung abschließen (z.B. Rechnung versendet) und auf die eine Organisation im Kontext reagiert (z.B. der Kunde, der die Rechnung erhält), • sämtliche Objektflüsse (Waren, Daten etc.), die die ICT-Unternehmung von außen erhält bzw. selbst produziert und nach außen liefert. (Die Objektflüsse werden im hier vorliegenden Prozess-Referenzmodell nicht dargestellt.) Die wesentlichste Rolle im Umfeld einer Unternehmung haben sicherlich die Kunden und Lieferanten inne. Sie haben den stärksten Einfluss auf das

66

ICT Company

Abb. 24. Schnittstellen der ICT Company

operative Geschäft. In unserem Beispiel wurden diese beiden Rollen bereits weiter qualifiziert. So werden die Lieferanten in die drei Gruppen potenzieller, aktiver und inaktiver Lieferant und in die anonyme Masse Anbietermarkt untergliedert. Die Kunden werden in Interessent, aktiver, inaktiver Kunde und in die anonyme Masse Kundenmarkt unterteilt. Bereits die Strukturierung des Kontextes lässt die Einstellung eines Unternehmens zu seinem Umfeld erkennen, d.h. wie es dieses wahrnimmt und bearbeitet. Auf der strategischen Seite nehmen außer den zuvor genannten Faktoren primär die Konkurrenz sowie die Forschungsinstitute und in einer eher untergeordneten, aber trotzdem zu berücksichtigenden Funktion der Gesetzgeber und die Verbände (Vereine, Gewerkschaften, Branchenverbände etc.) Einfluss auf das Unternehmen. Wird eine Unternehmung innerhalb einer Konzernstruktur betrachtet, sind auch die Schnittstellen zu den anderen Firmeneinheiten im Kontext zu berücksichtigen. In diesem Fall wird die Rollenliste entsprechend um Rollen wie z.B. zentrale IT, Produktionsfirma Nord etc. erweitert. Auch hier ist dann von Bedeutung, welche Ereignisse diese Rollen erzeugen und welche Ereignisse von der ICT-Unternehmung für diese Rollen erzeugt werden. Die folgende Abbildung stellt den Kontext unserer fiktiven Unternehmung, der ICT Company, dar:

Aufbauorganisation

67

Abb. 25. Der Kontext der ICT Company

Die Rollen im Kontext einer ICT-Unternehmung lassen sich in folgende Gruppen gliedern: 1. Kunden 2. Lieferanten / Hersteller 3. Konkurrenz 4. Öffentliche Insitutionen (wie Gesetzgeber, Verbände, Forschungsinstitute etc.) 5. Unternehmungen des Konzerns (soweit eine Konzernstruktur besteht)

Aufbauorganisation Ein schematisches Modell Die Gestaltung der Aufbauorganisation einer Unternehmung wird von einer Vielzahl von Faktoren wie z.B. verfügbarer Managementkapazität, verschiedenen Standorten, Führungs- und Managementkonzepten etc. beeinflusst. Diese Faktoren sind unabhängig von den Prozessen, beeinflussen aber die Effizienz und die Ablauforganisation einer Unternehmung z.T.

68

ICT Company

erheblich. Wir verweisen an dieser Stelle auf die dazu existierende umfangreiche Literatur. Allerdings kommen wir auch in unseren Projekten, trotz vehementen Gegensteuerns6, am Thema der Aufbauorganisation nicht vorbei, da die Prozesse selbst ja auch ein nicht unerheblicher Einflussfaktor für die Aufbauorganisation sind – aber eben nur einer von vielen! Ein modernes Bestreben ist es, die Organisation prozessorientiert aufzubauen. Typisch für eine Aufbauorganisation ist die Abgrenzung von Verantwortungsbereichen. Es erfolgt ein Auf- und Abteilen (Abteilung) von Tätigkeiten. Das Prozess-Referenzmodell visualisiert ein umfangreiches Prozess-Netzwerk. Abteilen (Abteilung) heißt also zu entscheiden, wenn an einer Stelle innerhalb des Prozesses dieser für die eine Abteilung abgeschlossen ist und gleichzeitig für die folgende Abteilung beginnt. Die Kunst liegt darin, an der für das Unternehmen, sprich: für die Organisation, passenden7 Stelle zu schneiden. Die weiter oben diskutierte Grundstruktur für die Clusterung von Prozessen kommt einem ersten Entwurf für eine Aufbauorganisation zumindest optisch sehr nahe; in der Praxis empfehlen wir einen anderen Ansatz. So erscheint es uns sinnvoller, sich an den zu erbringenden Leistungen und der damit verbundenen Auftragsabwicklung zu orientieren. Im vorhergehenden Kapitel Leistungen / Produkte der ICT Company, wurde darauf hingewiesen, dass die Leistungen einer ICT-Unternehmung sich auch in der Art der Leistungserbringung unterscheiden können. Während die einen quasi projektorientiert zu erbringen sind und die Ergebnisse unmittelbar durch den Kunden (bzw. dessen Vertreter) abgenommen werden, werden Leistungen wie insbesondere die der Bereitstellung und des Betriebs einer ICT-Infrastruktur quasi permanent erbracht. Aus Sicht der Aufbauorganisation macht es Sinn, den statischen Betriebsbereich von den mehr dynamisch geprägten Projekt- bzw. Auftragsabwicklungsbereichen zu trennen. Ein einfacher organisatorischer Gliederungsvorschlag orientiert sich an der im vorangegangenen Kapitel beschriebenen funktionalen Grundstruktur und führt zu folgendem schematischen Modell:

6

Mit der Thematik der Aufbauorganisation sind auch immer persönliche Zielsetzungen und Erwartungen von Mitarbeitern und Führungskräften verbunden. So genannte politische Interessen behindern in Projekten leider allzu oft die Entwicklung der optimalen Lösung.

7

Die Betonung liegt auf für das Unternehmen passend, und das ist dehnbar.

Aufbauorganisation

69

Abb. 26. Basismodell der Aufbauorganisation der ICT Company

Die Aufbauorganisation der ICT Company Für unser fiktives Unternehmen der ICT Company orientiert sich die Aufbauorganisation weiter an folgenden Überlegungen: Neben der allgemeinen Geschäftsführungsfunktion gibt es einen Verwaltungsbereich, in dem die allgemeinen Managementfunktionen angesiedelt sind, sowie einen Customer-Relationship-Management-Bereich, der sich in Sales und Customer Services unterteilt. Weiter werden zwei primäre Produktionsbereiche unterschieden: • Der Bereich Solutions Development produziert bzw. erbringt die im Kapitel über die Leistungen / Produkte der ICT-Unternehmung beschriebenen Leistungen der Leistungsgruppe 1 und 2. Dieser Bereich ist organisatorisch durch die typischen Eigenschaften des Projektgeschäftes geprägt. Oft ist er in mehrere themenspezifische Entwicklungsabteilungen unterteilt. • Der zweite ist der Operations-Bereich, der die Leistungen der Leistungsgruppe 3 erbringt, die sich durch eine permanente, statische Leistungserbringung auszeichnet. Auch dieser Bereich ist oft in mehrere plattformorientierte Abteilungen untergliedert. Eine besondere Struktur stellt der Bereich des Production Support dar. Dieser Bereich hat zwei primäre Aufgaben: Erstens stellt er alle übergrei-

70

ICT Company

fenden Instrumente (z.B. Configuration Management) und Verfahren (z.B. Security-Konzepte), die die Produktionsbereiche benötigen, zur Verfügung. Zweitens stellt er die Schnittstelle zwischen den Bereichen Solution und Operations dar. D.h. dieser Bereich übernimmt die Koordination der Abnahme von technischen Lösungen, die der Bereich Solution Development entwickelt hat und die die Operations zukünftig betreiben müssen. (Dies gilt natürlich auch für Lösungen, die extern entwickelt wurden). Daraus abgeleitet ergibt sich für unser Musterunternehmen folgendes vereinfachtes hierarchisches Organigramm:

Abb. 27. Organigramm der ICT Company

Abb. 28. Detailorganigramm der ICT Company

Aufbauorganisation

71

Mit der in Abbildung 28 dargestellten Variante einer möglichen Gliederung der Aufbauorganisation schließen wir das Thema Aufbauorganisation ab. Begriffswelt der ICT Company Jedes Unternehmen hat seine eigene Sprache. Tatsächlich liegt die Herausforderung oftmals darin, das gleiche Verständnis für die verwendeten Begriffe im Unternehmen zu finden. Das Prozess-Referenzmodell basiert auf zwei Begriffswelten: Zum einen orientieren wir uns an den fachspezifischen Begriffen und Definitionen von ITIL, was uns in diesem Umfeld sehr viel erleichtert. Zum andern verwenden wir einige wenige allgemeine Begriffe, die in der Praxis aber oft von Unternehmen zu Unternehmen sehr unterschiedlich und spezifisch belegt sind und von uns hier auch nur in ihrer oberflächlichen Definition verwendet werden. Klassischerweise werden Begriffsdefinitionen in einem Glossar dokumentiert, was in Sachen ITIL äußerst hilfreich ist, da hiermit quasi ein Standard-Glossar zur Verfügung steht. Für die allgemeinen Begriffe haben wir

Abb. 29. Fachbegriffsmodell 1 der ICT Company

72

ICT Company

Abb. 30. Fachbegriffsmodell 2 der ICT Company

so genannte Fachbegriffsmodelle definiert, die das Verständnis dieser Begriffe erleichtern. Diese Methodik hat es in der Praxis ermöglicht, unterschiedliche Interpretationen und Auslegungen zusammenzuführen. In den selbsterklärenden Abbildungen 29 und 30 haben wir eine Auswahl der wichtigsten in unserer ICT Company und damit auch im Modell verwendeten Begriffe in ihrem Zusammenhang dargestellt. Im ersten Fachbegriffsmodell werden vor allem die sensiblen Begriffe wie Angebot, Bestellung, Vertrag und Auftrag dargestellt. Das zweite Fachbegriffsmodell stellt die Begriffe Projekt und IT-System in den Mittelpunkt. An dieser Stelle scheint es uns nicht wichtig, den Begriff Projekt im Sinne einer zeitlich begrenzten Aufgabe mit einem definierten Start- und Endtermin und einem vorgegebenen Ergebnis zu definieren. Das Fachbegriffsmodell sagt hier aus, dass es zwei Arten von Projekten gibt: Beratungs- und Entwicklungsprojekte; außerdem liegt jedes IT-System als Release vor. Gerade das letztgenannte Beispiel zeigt die Wirkung von Fachbegriffsmodellen. Nach dem Studium des Prozess-Referenzmodells kommen Sie zu dem Schluss, dass auch noch andere Arten von Projekten realisiert werden. Entsprechend würde nun in der Praxis das Fachbegriffmodell erweitert, bis alle Projektarten eindeutig identifiziert und definiert sind.

Aufbauorganisation

73

Weitere Faktoren Natürlich gibt es noch eine Reihe von weiteren Faktoren, die eine Unternehmung ausmachen und über die es sich lohnen würde im Detail zu diskutieren. Unsere Zielsetzung konzentriert sich aber im Wesentlichen darauf, ein Umfeld zu skizzieren, in dem das hier vorgestellte Prozess-Referenzmodell anzusiedeln ist. Ein wesentlicher Aspekt der Organisation sind die Definitionen von Rollen sowie von Arbeits- und Entscheidungsgremien. Vor allem Rollendefinitionen sind eine Vorstufe zur organisatorischen Umsetzung in Stellen und Funktionen, dienen sie doch als Grundlage für Stellenbeschreibungen und Anforderungsprofile zwecks Auswahl des geeigneten Personals. Hierzu existieren diverse Beschreibungen. So finden sich z.B. in der ITILLiteratur Rollen- und Gremienbeschreibungen, die auch für unser Prozess-Referenzmodell verwendbar sind. Empfehlenswert sind in diesem Zusammenhang auch die in der Schweiz sehr bekannten Berufsbilder für die ICT-Branche. Themen wie z.B. Geschäftskonzepte (gewinnorientiert, kostendeckend), Marketingkonzepte, Technologie- und Sicherheitskonzepte haben durchaus auch wichtige Einflüsse auf die Organisation einer Unternehmung, sollen aber an dieser Stelle nicht weiter diskutiert werden.

Ausgewählte Geschäftsvorfälle

End-to-End-Betrachtung Das Prozess-Referenzmodell stellt die wesentlichsten Prozesse einer ICTUnternehmung auf einer hohen Abstraktionsebene im Zusammenhang dar. Alle Geschäftsvorfälle, die eine wertschöpfende Funktion haben, sind im Modell abgebildet. Durch Verknüpfung untereinander und mit weiteren relevanten Prozessen des ICT-Unternehmens entsteht ein komplexes Prozessnetzwerk. Ein einzelner spezifischer Geschäftsvorfall1 wie z.B. ein Kunde bestellt einen PC verliert sich in der Komplexität und ist nicht sofort auf den ersten Blick dem Modell zu entnehmen. Betrachten wir einen einzelnen Geschäftsvorfall, so konzentrieren wir uns auf die Voraussetzungen, die Aufgaben und die Schnittstellen, die für dessen Abwicklung notwendig sind. In der Praxis empfiehlt es sich in einem ersten Schritt, die wichtigsten Prozesse isoliert, d.h. für sich zu betrachten und zu einem späteren Zeitpunkt ins Modell zu integrieren und durch die Schnittstellen zu ergänzen. An dieser Stelle muss aber erwähnt werden, dass die Erfahrung auch zeigt, dass eine isolierte Betrachtung nicht zwingend der einfachere Weg ist. Oft stellt sich nämlich die Frage, welche Aufgaben zum Prozess gehören und welche nicht. Die Frage der Abgrenzung gewinnt vor allem immer dann an Einfluss, wenn zwar eine Schnittstelle definiert werden kann, aber die Qualität der dahinter liegenden Arbeitsabläufe fraglich oder nicht garantiert ist. In diesem Fall neigt man dann gerne dazu, sich über das eigentliche Thema hinweg zu engagieren und die ursprüngliche Aufgabenstellung aus dem Auge zu verlieren. Bei einer End-to-End-Betrachtung wird der Prozess von seinem Ausgangspunkt (dem auslösenden Ereignis) bis zu seinem Endpunkt (Empfänger des oder der Ergebnisse) betrachtet. Ein einfaches und einleuchtendes Beispiel ist das folgende: Der Kunde bestellt ein Produkt und erhält in der 1

Siehe hierzu auch die Ausführungen im Kapitel Modellkonzept und Methodik.

76

Ausgewählte Geschäftsvorfälle

Folge das bestellte Produkt. Alle Aktivitäten dazwischen, in unserem Beispiel also vom Bestellungseingang über die Herstellung des Produktes, die Warenendkontrolle und den Versand bis zur Übergabe des Produktes an den Kunden, werden in einer End-to-End-Betrachtung dargestellt. Auch hier ergeben sich dann Fragen zur Abgrenzung. Ist z.B. die Bereitstellung des Rohmaterials für die Herstellung des Produktes oder die Erstellung der Rechnung Bestandteil der Betrachtung? Keine einfache Fragen, deren Beantwortung durch die vorgegebene Aufgabenstellung beeinflusst wird. Besteht die Aufgabenstellung darin, einem Dritten – z.B. einem Kunden oder Lieferanten – einen Überblick zu verschaffen, so reicht die Darstellung der Zusammenhänge. Ist hingegen eine Realisierung in Form eines informationstechnologisch unterstützten Workflows gefordert, müssen bis zum letzten Datenattribut alle Informationen zur Verfügung gestellt werden. In der Praxis überwiegt auch hier das typische Top-down-Vorgehen, also vom Groben zum Detail. In einem ersten Schritt wird in einer Übersicht quasi der rote Faden vorgegeben, der dann in der Folge sukzessiv ergänzt und erweitert wird. In dem folgenden Kapitel haben wir für einzelne Geschäftsvorfälle die relevanten Ereignisse und Aufgaben aus dem Prozess-Referenzmodell isoliert und konzentrieren uns auf die Darstellung des „roten Fadens“. Wir haben dabei die für die im Anhang befindliche Gesamtübersicht verwendete Grunddarstellung der Prozesse beibehalten. Wenn Sie die Gesamtübersicht des Prozess-Referenzmodells parallel zu den folgenden Beschreibungen verfolgen, sehen Sie, welche Verknüpfungen berücksichtigt und welche übergangen wurden. Die folgenden Geschäftsvorfälle sind als Beispiele zu verstehen. Sie bilden jeweils eine von vielen möglichen Arten einer Geschäftsabwicklung ab und müssen in der jeweiligen Form nicht mit Ihren Vorstellungen und Erfahrungen übereinstimmen.

Geschäftsvorfall 1: Kunde kauft PC Beim ersten Geschäftsvorfall kauft der Kunde einen PC, bestehend aus der entsprechenden Hardware sowie ausgewählter Software. Weiter wünscht der Kunde, dass dieser bei ihm betriebsbereit installiert wird. Leistungsmerkmale der Hardware sowie die Art der gewählten Software spielen für unsere Betrachtung keine Rolle. Die End-to-End-Betrachtung beginnt mit der Bestellung der Leistung durch den Kunden und endet mit der Übergabe des betriebsbereiten Systems an den Kunden.

Geschäftsvorfall 1: Kunde kauft PC

77

Es handelt sich bei der Leistungserbringung um eine klassische Bestellabwicklung. Die zu erbringende Leistung umfasst die Annahme der Bestellung, die Herstellung des entsprechenden Produktes inkl. der Beschaffung der notwendigen Komponenten (wie z.B. der Software bzw. Lizenzen hierzu), die Auslieferung, die Installation des Systems sowie die betriebsbereite Übergabe an den Kunden. In der Folge wird der logische Ablauf2 beschrieben. Typische betriebsspezifische Rahmenbedingungen wie z.B. vorgegebene Bearbeitungs-, Liege- und Fertigungszeiten etc. spielen für unsere End-to-End-Betrachtung keine Rolle. Der Prozess beginnt mit dem Ereignis Produkt bestellt. Plakativ kann man sich vorstellen, dass dieses Ereignis z.B. im Rahmen einer Online-Bestellung durch das Drücken des Buttons: „Bestellung definitiv auslösen“3 eintritt.

Abb. 31. GV1: Relevanter Ausschnitt Order Management

Das Ereignis Produkt bestellt ist das Startereignis, welches in unserem Modell den Prozess 213 Order Management auslöst. Hier wird die Bestellung überprüft. Neben einer Plausibilitätsprüfung, die bei Online-Bestellungen i.d.R. bereits vor der definitiven Durchführung der Bestellung erfolgt, kann hier z.B. die Bonität bzw. Zahlungsmoral des Kunden geprüft werden. Der nächste Schritt ist die definitive Annahme der Bestellung durch deren Freigabe. Das Ereignis Bestellung bestätigt schließt diese erste Aufgabenkette ab. Dem Kunden wird die Annahme der Bestellung mitgeteilt. Weiter löst dieses Ereignis die nächsten Prozessschritte aus, die in den Prozessen 222 Contract Management und 334 Distribution Planning geregelt sind. 2

Die grafische Darstellung der Geschäftsvorfälle in Form einer Ablaufdarstellung befindet sich im Anhang. Damit der Ablauf lesbar verfolgt werden kann, haben wir uns entschlossen, in diesem Kapitel die jeweils aufeinander folgenden Sequenzen in Einzelbildern darzustellen.

3

Welches Medium der Kunde für die Aufgabe seiner Bestellung nutzt, ist auf der dargestellten logischen Ebene unerheblich. Er könnte das Produkt auch telefonisch oder per Fax bestellen. Welche Medien bzw. Kommunikationskanäle zugelassen bzw. unterstützt werden, werden in den Business Rules festgelegt.

78

Ausgewählte Geschäftsvorfälle

An dieser Stelle verzweigt sich unser Prozess zum ersten Mal. Bevor wir uns der eigentlichen Herstellung und Lieferung des Produktes widmen, verfolgen wir kurz den parallel verlaufenden Verwaltungszweig.

Abb. 32. GV1: Relevanter Ausschnitt Contract Administration

Im Prozess 222 Contract Administration werden alle Aktivitäten, die mit der Administration einer Bestellung verbunden sind, durchgeführt. Eine Bestellung hat grundsätzlich auch Vertragscharakter. In unserem Modell haben wir hier aufgrund des Vertragscharakters auch die Schnittstelle zum Lizenz-Management angesiedelt. Da unser Kunde den PC inkl. Software bestellt hat, für die eine entsprechende Lizenz benötigt wird, müssen die entsprechenden Aktivitäten im Prozess 115 Licence Management ausgelöst werden.

Abb. 33. GV1: Relevanter Ausschnitt Licence Management

Für unseren Geschäftsvorfall wird angenommen, dass der Lizenzstatus einer aktivierten Voll- und Einzelplatzversion der ausgewählten Software benötigt wird. Mit der Freischaltung der Lizenz könnte nun z.B. auch die Bereitstellung des Lizenzzertifikats oder die Freigabe der Installation dieser Software im Rahmen des Herstellungs- bzw. Installationsprozesses gesteuert werden. Wir begnügen uns an dieser Stelle damit, dass die Lizenz aktiviert wurde, d.h. die Nutzungsrechte der bestellten Software für den Kunden vorliegen. Ein weiterer Verwaltungsakt ist die Rechnungsstellung. Wir gehen davon aus, dass die Installation pauschal in Rechnung gestellt wird, die notwendigen Verrechnungsdaten im Prozess 222 Contract Management vor-

Geschäftsvorfall 1: Kunde kauft PC

79

liegen, dort die Rechnungsgrundlagen erstellt und damit der Prozess 141 Service Charging angestoßen wird.

Abb. 34. GV1: Relevanter Ausschnitt Service Charging

Hier werden nun die eigentlichen Verrechnungsinformationen zusammengestellt. Selbst in einem so eindeutigen Fall wie im vorliegenden Beispiel, bei dem die Preise der einzelnen Leistungen schon zum Zeitpunkt der Bestellung eindeutig klar waren, können die Verrechnungsdaten noch modifiziert werden. So können z.B. eine vom Kunden parallel eingereichte Gutschrift (z.B. Gutschein), eine gewünschte Rabattstufe (z.B. Studentenrabatt) oder auch variable Komponenten, die zu Bestellbeginn noch nicht eindeutig zu bestimmen waren (z.B. Versandkosten, Zollgebühren etc.), die Rechnungsstellung noch beeinflussen. Nach Abschluss des Prozesses kann die Debitorenrechnung gestellt werden. Diese kann nun nach der Systemübergabe versendet oder dem Versandpaket beigelegt werden, jeweils abhängig davon, nach welchen Rahmenbedingungen das Unternehmen die Rechnungsstellung geregelt hat. Nach diesem kurzen Ausflug in den parallel verlaufenden Prozesszweig setzen wir den Ablauf beim Prozess 334 Distribution Planning fort. Dieser wird ausgelöst durch das aus dem Prozess 213 Order Management resultierende Ereignis Bestellung bestätigt. Hier wird die Auslieferung des bestellten Produktes initialisiert und geplant. Für unser Fallbeispiel gehen wir davon aus, dass das Produkt eine regelmäßig nachgefragte, standardisierte Lösung ist, aus diesem Grunde eine Vorfabrikation erfolgt und das Produkt im Lager verfügbar ist.

Abb. 35. GV1: Relevanter Ausschnitt Distribution Planning

80

Ausgewählte Geschäftsvorfälle

In der Folge wird das Auslieferungspaket angefordert und die Auslieferung freigegeben. Da der Kunde das System inklusive Installation bestellt hat, ist zusätzlich ein On-Site-Einsatz notwendig, der geplant und koordiniert werden muss.

Abb. 36. GV1: Relevanter Ausschnitt Material & Inventory Management

Über den Prozess 742 Material & Inventory Management wird das Auslieferungspaket bereitgestellt und damit eine Voraussetzung für den folgenden Prozess 335 HW / SW Distribution geschaffen.

Abb. 37. GV1: Relevanter Ausschnitt HW / SW Distribution

Hier wird nun die Bestellung sowie das vorliegende Produkt abgeglichen, ergänzende Aktivitäten durchgeführt (z.B. Zollpapiere ausgefüllt) und gegebenenfalls korrigierend eingegriffen. Anschließend werden alle Maßnahmen ergriffen oder veranlasst, die für die Auslieferung der Hardund Software notwendig sind. Da die Installation durch einen Servicetechniker durchgeführt wird, erfolgt in solch einem Fall oftmals die Auslieferung an den Servicetechniker, der dann das Produkt zum Kunden transportiert. Mit der Auslieferung sind die Voraussetzungen für die Installation geschaffen. Bevor die Installation vor Ort durchgeführt werden kann, muss diese bzgl. Termin und Ressourcen geplant und koordiniert werden. Dies erfolgt aufgrund des Ereignisses On-Site-Einsatz notwendig (Ergebnis des Prozesses 334 Distribution Planning) in der Folge im Prozess 631 On-Site Dispatching. Hier finden die Terminabstimmung und die Zuweisung des benötigten Servicetechnikers statt.

Geschäftsvorfall 2: Betrieb einer ICT-Infrastruktur

81

Abb. 38. GV1: Relevanter Ausschnitt On-Site Dispatching

Die Installation und Übergabe des bestellten Systems an den Kunden ist im Prozess 633 Installation & Relocation Management abgebildet. Ausgehend davon, dass die HW / SW geliefert wurde, erfolgt die Installation und die Übergabe des Systems an den Kunden. Der Prozess wird mit den Ereignissen Servicebericht erstellt – hier bestätigt der Kunde die Übernahme des installierten und betriebsfähigen Systems – sowie System geliefert abgeschlossen.

Abb. 39. GV1: Relevanter Ausschnitt Installation & Relocation Management

Das zuletzt genannte Ereignis schließt gleichzeitig auch die End-to-EndBetrachtung des Geschäftsvorfalls Kunde bestellt einen PC – Kunde hat den PC erhalten ab.

Geschäftsvorfall 2: Betrieb einer ICT-Infrastruktur Für den Geschäftsvorfall 2 gehen wir von folgender Annahme aus. Ein Kunde vergibt einen Auftrag für den Betrieb einer ICT-Infrastruktur. Hierbei ist zu berücksichtigen, dass regelmäßig ein umfassender Druckoutput zu erzeugen ist sowie auch ein Notbetrieb sichergestellt ist. Der Geschäftsvorfall soll zum einen den Teil bis zur Auftragserteilung beschreiben, zum anderen den Teil ab Auftragserteilung. Dieses Beispiel umfasst somit zwei End-to-End-Betrachtungen:

82

Ausgewählte Geschäftsvorfälle

• von der Leistungsanfrage bis zum Vertrag • ab der Auftragserteilung bis zur Produktion

Abb. 40. GV2: Relevanter Ausschnitt Sales Management

Der Geschäftsvorfall beginnt damit, dass der Kunde eine Leistungsanfrage formuliert hat. Dies kann in Form einer Ausschreibung bis zur entsprechenden Notiz eines Vertriebsbeauftragten reichen. In einem ersten Schritt wird die Anfrage analysiert und zwar vor allem bezüglich der Frage, was angeboten werden muss und was angeboten werden kann. Hier erfolgt in der Praxis ein erster nicht zu unterschätzender Schritt. Oftmals bewegen sich Kunden und Lieferanten bzgl. der Verwendung von Begrifflichkeiten und Interpretation von Anforderungen auf unterschiedlichem Terrain. So können der Begriff „Notbetrieb“ und die in diesem Fall sicherzustellende Leistung ganz unterschiedlich ausgelegt werden. Damit also die angefragte Leistung auch von den nachfolgenden Stellen im Unternehmen richtig verstanden und damit auch passend angeboten werden können, wird im SalesBereich eine entsprechende Angebotsanfrage formuliert. Mit diesem Ereignis wird die Erstellung des Angebotes im Prozess 212 Bid Management initialisiert. Wir unterscheiden in unserem Modell für die Angebotserstellung zwei Bereiche: die Erstellung des fachlichen Inhaltes sowie die Ausarbeitung des Vertrages.

Abb. 41. GV2: Relevanter Ausschnitt Bid Management

Geschäftsvorfall 2: Betrieb einer ICT-Infrastruktur

83

Vor allem bei Grossaufträgen bzw. komplexen Aufträgen ist die Erstellung von Angeboten Teamarbeit. Die Erstellung eines Angebotes muss ab einer gewissen Größenordnung wie ein Projekt organisiert werden. Das Ergebnis muss von mehreren Menschen innerhalb eines meist kurzen Zeitraums zu einem bestimmten Termin erarbeitet werden. In unserem Beispiel wird z.B. das Fachwissen bezüglich des Betriebs benötigt. So muss unter anderem abgeschätzt werden, ob die geforderten Leistungen überhaupt erbracht werden können und welche Voraussetzungen dafür zu schaffen sind. Diese Tätigkeiten werden mit dem Ereignis ProduktionsPlanungsauftrag freigegeben initialisiert.

Abb. 42. GV2: Relevanter Ausschnitt Production Planning

In der Folge werden der Produktionsumfang (Volumina, Zeiten etc.), der Ressourcenbedarf sowie die voraussichtlichen Produktionskosten kalkuliert. Hierzu gehört auch die Definition von Rahmenbedingungen wie z.B. der Vorgaben, die ein Kunde erfüllen muss, damit die Erbringung der geforderten Leistung garantiert werden kann. Diese Tätigkeiten werden mit dem Ergebnis Produktionsofferte erstellt abgeschlossen. Auf dieser Basis kann nun im Prozess 212 Bid Management das Angebot vervollständigt werden. Dazu gehören z.B. eine Risikoanalyse inkl. Bewertung der Risiken, die Kalkulation der Aufwände und die Planung von Terminen. Mit Abschluss der fachlichen Arbeiten ist die Angebotsvorlage erstellt, und die Fertigstellung im Prozess 221 Contract Definition kann ausgelöst werden.

Abb. 43. GV2: Relevanter Ausschnitt Contract Definition

Die Fertigstellung des Angebotes wird von zwei Arbeiten geprägt: Die erste ist die juristische Ausgestaltung des Vertragsteiles, die zweite die Festlegung der definitiven Konditionen und Termine. Die juristische Ausarbei-

84

Ausgewählte Geschäftsvorfälle

tung und Prüfung ist nicht zu unterschätzen und kann das Unternehmen vor z.T. nicht unerheblichen Risiken schützen. Preise und Zahlungstermine sind Verhandlungsobjekte und werden von der Zielsetzung des Unternehmens und des Vertriebs beeinflusst. Nach der Freigabe des Vertragsteiles ist das Angebot erstellt und wird dem Kunden übergeben. Damit ist der erste Teil der End-to-End-Betrachtung unseres Geschäftsvorfalls abgeschlossen. Dem Kunden liegt das Angebot vor. Im einfachsten Fall zeichnet der Kunde nun die mit dem Angebot unterbreiteten Verträge gegen. Somit ist der Vertrag unterzeichnet, womit wir die Möglichkeit haben, unseren Geschäftsvorfall weiter zu verfolgen.

Abb. 44. GV2: Relevanter Ausschnitt Contract Administration

Mit Eingang des unterzeichneten Vertrages erfolgt die Einrichtung der Vertragsverwaltung. Hierzu gehört nicht nur die Ablage der entsprechenden Dokumentation, sondern vor allem auch die Einrichtung der Terminüberwachung. Aus Sicht der Wertschöpfung steht natürlich der Start der Leistungserbringung im Vordergrund. Das Ereignis Produktionsvertrag freigegeben löst die entsprechenden Aktivitäten in den Prozessen 711 Contingency Planning (wir haben vertraglich einen Notbetrieb garantiert) und 511 Production Planning aus. Weiter werden die Rechnungsgrundlagen erstellt, die im Prozess 141 Service Charging weiter bearbeitet werden. Unser Geschäftsvorfall teilt sich hier in drei Äste auf. Wir werden zuerst die Leistungsverrechnung, anschließend die Produktion, sprich den Betrieb der ICT-Infrastruktur, und zum Schluss die Notfallplanung verfolgen. Im Prozess 141 Service Charging werden auf der Basis der vertraglichen Vereinbarung die Vorbereitungen für die Verrechnung der Leistungen getroffen. In der Regel werden hierzu im jeweiligen Verrechnungssystem der Kundenstammsatz (Anschrift etc.), die Leistungsarten, die vereinbarten Preise, Zahlungstermine und -fristen etc. erfasst. Gehen wir in unserem Fall davon aus, dass bereits mit Auftragserteilung eine erste Akontozahlung vereinbart wurde, wird diese nun ausgelöst und der Prozess durch Debitorenrechnung gestellt abgeschlossen.

Geschäftsvorfall 2: Betrieb einer ICT-Infrastruktur

85

Abb. 45. GV2: Relevanter Ausschnitt Service Charging

Das Ereignis Produktionsvertrag freigegeben löst im Betrieb die Produktionsplanung aus. Es werden die Produktionsziele und -inhalte für die Planungsperiode festegelegt, der Ressourcen- und Materialbedarf ermittelt sowie die Produktionsvorgabe erstellt, welche im Prozess 521 Production Control die Produktion auslösen und die Grundlage für die Überwachung und Steuerung der Produktion sind. Die Arbeiten werden mit dem Ereignis Produktionsplanung erstellt zu Kenntnis des Kunden abgeschlossen.

Abb. 46. GV2: Relevanter Ausschnitt Production Planning

Ausgelöst durch das Ereignis Produktionsvorgabe erstellt wird im Prozess 521 Production Control der Produktionszyklus vorbereitet und die Produktion gestartet. Die Besonderheit beim Betrieb einer ICT-Infrastruktur ist, dass hier unter Produktion die Bereitstellung von verfügbaren Rechnerund Netzwerksystemen verstanden wird, unabhängig davon, ob und in welchem Umfang die Anwender die bereitgestellten Systeme nutzen. Das Ereignis Produktion gestartet bedeutet in diesem Fall, dass die entsprechenden Systeme hochgefahren sind und den Anwendern zwecks Nutzung zur Verfügung stehen.

Abb. 47. GV2: Relevanter Ausschnitt Production Control (1)

86

Ausgewählte Geschäftsvorfälle

Gemäß den Produktionsvorgaben stehen zu einem bestimmten Zeitpunkt die für die Erzeugung des Druck-Outputs notwendigen Daten zur Verfügung. Mit dem Ereignis Output produktionsbereit wird über den Prozess 523 Output Management die Erzeugung und Auslieferung des Outputs ausgelöst.

Abb. 48. GV2: Relevanter Ausschnitt Output Management

Die Produktionsleistung beim Betreiben einer ICT-Infrastruktur besteht nach dem Hochfahren der Systeme in deren ständiger Überwachung und in der Sicherstellung der Verfügbarkeit der Systeme gemäß den jeweiligen Produktionsvorgaben. Diese Aufgaben sind ebenfalls im Prozess 521 Production Control geregelt.

Abb. 49. GV2: Relevanter Ausschnitt Production Control (2)

Damit ist hier im Sinne der End-to-End-Betrachtung die Kette von Kunde beauftragt den Betrieb seiner ICT-Infrastruktur bis zu Anbieter betreibt diese abgeschlossen. Am Ende eines Produktionszyklus (z.B. Tagesende) werden die Verrechnungsdaten zusammengestellt und dem Prozess 141 Service Charging zwecks Faktura zur Verfügung gestellt.

Abb. 50. GV2: Relevanter Ausschnitt Service Charging

Geschäftsvorfall 3: Individual-Software-Entwicklung

87

In unserem Geschäftsvorfall wurde als weitere Leistung die Sicherstellung eines Notbetriebes vereinbart. Hierzu muss gemeinsam mit dem Kunden ein Notfallszenario, mit dem ein Notbetrieb sichergestellt wird, definiert werden. Ausgelöst durch das Ereignis Produktionsvertrag freigegeben erfolgen die dafür notwendigen Aktivitäten gemäß dem Prozess 711 Contingency Planning. Natürlich würde das Notfallszenario noch getestet werden, wir verzichten aber an dieser Stelle auf die entsprechenden Ausführungen.

Abb. 51. GV2: Relevanter Ausschnitt Contingency Planning

Damit sind alle mit dem Geschäftsvorfall verbundenen Ergebnisse im Sinne unserer angestrebten End-to-End-Betrachtung beschrieben worden. Der erste Teil des Geschäftsvorfalls startete mit der Anfrage des Kunden und endete mit der Unterbreitung des Angebotes. Der zweite Teil startete mit der Beauftragung durch den Kunden (Unterzeichnung des Vertrages) und endete mit den drei geforderten Ergebnissen Betrieb der ICT-Infrastruktur, Erzeugung von Druck-Ouput und Sicherstellung eines Notbetriebes.

Geschäftsvorfall 3: Individual-Software-Entwicklung In diesem Geschäftsvorfall wünscht unser Kunde eine klassische individuelle Software-Lösung. Auch hier teilt sich die Betrachtung in zwei Teile. Im ersten Teil geht es um die Angebotserstellung, der zweite Teil beinhaltet die Aktivitäten nach der Auftragsvergabe. Als Ergebnisse erhält der Kunde im Sinne der End-to-End-Betrachtung für seine Anfrage ein Angebot und für den erteilten Auftrag die Software-Lösung. Bevor wir uns nun dem Geschäftsvorfall zuwenden, noch zwei Bemerkungen: • Unser virtuelles Unternehmen, die ICT Company, steuert ihre Projekte auf der Basis eines Programm-Managements. Bevor ein Projekt realisiert werden kann, muss es vom Programm-Management genehmigt werden. Dies gilt auch und insbesondere für Entwicklungsprojekte im Kundenauftrag. Sinnvollerweise erfolgt die Prüfung und die Geneh-

88

Ausgewählte Geschäftsvorfälle

migung bzw. die Absage bereits vor dem Beginn der Angebotserstellung. Dieses Freigabeverfahren ist nicht zwingend überall üblich. • Im Rahmen eines Software-Entwicklungsprojektes wird üblicherweise auch das dazugehörige Release Management eingerichtet. Weiter erfolgt i.d.R. die Übergabe der Software an den Kunden, wenn das Rollout oder zumindest die Software-Verteilung Bestandteil des Projektes ist. Da dies die Geschäftsvorfallbeschreibung erheblich erweitern würde, haben wir an dieser Stelle darauf verzichtet, die Übergabe zu integrieren. Wir schließen den Geschäftsvorfall mit der Abnahme des Projektes, sprich der Software-Lösung, ab. Der Geschäftsvorfall wird durch eine Leistungsanfrage des Kunden ausgelöst. Die Anfrage wird analysiert und gemäß den Vorgaben der Unternehmung eine spezifische Angebotsanfrage formuliert. Insbesondere bei Software-Entwicklungen sind hier im Vorfeld oft umfangreiche Analysen der Anforderungen notwendig, in vielen Fällen liegt bereits ein Pflichtenheft vor. Ist dies nicht der Fall, empfiehlt es sich, dem Kunden zuerst die Aufnahme der Anforderungen und die Erstellung eines Pflichtenheftes zu verkaufen.

Abb. 52. GV3: Relevanter Ausschnitt Sales Management

Angebote für Individual-Software-Lösungen sind Teamarbeit. Für die Analyse sowie für die Erstellung des Angebotes werden verschiedene Fachexperten benötigt. Da eine Software-Entwicklung klassischerweise als Projekt realisiert wird, ist eine Projektofferte zu erstellen. Dies führt im BidManagement-Prozess zu dem Ergebnis, dass die Realisierung als Projekt vorgeschlagen wird, was in der Folge die entsprechenden Aktivitäten der Projektplanung auslöst.

Abb. 53. GV3: Relevanter Ausschnitt Bid Management

Geschäftsvorfall 3: Individual-Software-Entwicklung

89

Im Prozess 311 Project Planning werden in unserem Modell in der Angebotsphase primär zwei Aktivitäten durchgeführt. Zum einen wird das potenziell anstehende Projekt über das Ereignis Projekt beantragt dem Programm-Management der Unternehmung, welches alle Projekte koordiniert und überwacht, unterstellt. Im Prozess 121 Program Planning wird hierbei erstens geprüft, ob das Unternehmen in der Lage ist, das Projekt aus Sicht der verfügbaren Ressourcen zu realisieren und zweitens, ob es bereit ist, die evtl. mit dem Projekt verbundenen Risiken einzugehen. Wird das Projekt abgelehnt, endet hier der Prozess. Wir gehen davon aus, dass das Unternehmen das Projekt realisieren will, die Projektofferte erstellt und damit der Prozess 212 Bid Management fortgesetzt wird.

Abb. 54. GV3: Relevanter Ausschnitt Project Planning

Abb. 55. GV3: Relevanter Ausschnitt Program Planning

Liegt die interne Projektofferte vor, werden im Bid-Management-Prozess alle weiteren Inhalte für das Angebot an den Kunden zusammengetragen, die Risiken (bereits bekannte und evtl. vermutete) analysiert und bewertet sowie die abschließende Kalkulation erstellt. Liegen diese Inhalte vor, ist damit die interne Angebotsvorlage erstellt. Diese wird nun im Prozess 221 Contract Definition mit weiteren Vertragselementen und den definitiven Preisen versehen, womit dann das Angebot erstellt ist und dem Kunden übergeben werden kann. Damit ist dann der erste Teil der End-toEnd-Betrachtung Kunde stellt eine Anfrage und erhält ein Angebot abgeschlossen.

90

Ausgewählte Geschäftsvorfälle

Abb. 56. GV3: Relevanter Ausschnitt Bid Management

Abb. 57. GV3: Relevanter Ausschnitt Contract Definition

Mit dem Ereignis Vertrag unterzeichnet beginnt die Leistungserbringung, die intern mit dem Ereignis Entwicklungsauftrag freigegeben gestartet wird und bei Fertigstellung der Software mit dem Ereignis Projekt abgenommen enden wird. Mit dem Start der Auftragsabwicklung werden über das Ereignis Rechnungsgrundlagen erstellt auch alle Aktivitäten ausgelöst, die für eine erste und für die folgenden Fakturen notwendig sind.

Abb. 58. GV3: Relevanter Ausschnitt Contract Administration

Im Prozess 141 Service Charging wird neben der Einrichtung des Fakturasystems gegebenenfalls, wie bei einer individuellen Software-Entwicklung durchaus üblich, bereits mit der Vertragsunterzeichnung eine erste Meilensteinzahlung fällig.

Abb. 59. GV2: Relevanter Ausschnitt Service Charging

Geschäftsvorfall 3: Individual-Software-Entwicklung

91

In unserem Modell sind Software-Entwicklungsaufträge projektorientiert abzuwickeln und aus diesem Grunde einem zentralen Programm-Management zugeordnet. Dieses hat in dem Fall zwei primäre Aufgaben: erstens die Zuweisung der Ressourcen und zweitens die Formulierung des Projektauftrages inkl. Vorgabe der Projektorganisation (Lenkungsausschuss, Controlling etc.).

Abb. 60. GV3: Relevanter Ausschnitt Approval Procedure

Das Ereignis Projektauftrag freigegeben schließt das Freigabeverfahren des Programm-Managements ab und startet das Software-Entwicklungsprojekt, welches in der Folge im Prozess 311 Project Planning aufgesetzt wird. Es werden die organisatorischen Rahmenbedingungen für die Projektorganisation umgesetzt und der Realisierungsauftrag erteilt. In der Praxis erfolgt ein Projektstart selten so konsequent sequenziell, wie hier aus Prozesssicht dargestellt. Wesentlich ist, dass nach der Freigabe durch das Programm-Management die Ressourcenfragen gelöst sind, der Projektleiter benannt ist und die Projektorganisation steht. Nach den konstituierenden Aktivitäten erfolgt die Erteilung der diversen Projektaufträge, hier im Prozess mit dem Ereignis Realisierungsauftrag erteilt dargestellt.

Abb. 61. GV3: Relevanter Ausschnitt Project Planning

Der Software-Entwicklungs-Prozess wird durch den Prozess 322 System Development repräsentiert. Ein Entwicklungsprozess ist natürlich wesentlich umfangreicher und komplexer als hier dargestellt. Die beschriebenen Entwicklungsphasen Studie, Konzeption, Spezifikation, Realisierung und Test sind universelle Entwicklungsphasen. Die Inhalte dieser Phasen werden bestimmt durch die Art der zu entwickelnden Systeme und der verwendeten Entwicklungsverfahren. In unserer Betrachtung ist wesentlich, dass der

92

Ausgewählte Geschäftsvorfälle

Entwicklungsprozess definiert ist und mit einem Produkt, repräsentiert durch das Ereignis System abnahmebereit, abgeschlossen wird. In unserem Geschäftsvorfallbeispiel handelt es sich bei dem „System“ um eine individuelle Software-Lösung.

Abb. 62. GV3: Relevanter Ausschnitt System Development

In unserem Modell gehen wir davon aus, dass Systeme nach ihrer Entwicklung und den durchgeführten Funktionstests noch bzgl. ihrer Betriebstauglichkeit geprüft werden müssen. In dieser Phase geht es nicht mehr um die Frage, ob – wie in unserem Beispiel für die Software-Lösung – die funktionellen Anforderungen erfüllt werden, sondern ob sie in bestimmten Umgebungen installiert und betrieben werden kann. Neben den rein technischen Fragestellungen werden hier auch leistungsbezogene Fragen (z.B. Performance, erzeugtes Datenvolumen etc.) geprüft. Der Prozess schließt mit dem Ereignis Technische Abnahme erfolgt ab. Mit der technischen Abnahme wird auch festgelegt, welche technischen Voraussetzungen die Zielumgebung, in der die Software-Lösung installiert werden soll, erfüllen muss. Weiter leitet sie in unserem Geschäftsvorfall die Abnahme des Projektes durch den Auftraggeber ein.

Abb. 63. GV3: Relevanter Ausschnitt Operations Acceptance Test

Mit der technischen Abnahme ist der Entwicklungsprozess abgeschlossen. Damit kann die Endabnahme, mit der die Vertragserfüllung bestätigt wird, eingeleitet und durchgeführt werden. Hat der Kunde das Projekt abgenommen, in diesem Fall die entwickelte Software-Lösung, schließt hier die End-to-End-Betrachtung von Kunde beauftragt die Software-Entwicklung bis Kunde erhält die Software (nimmt das Projekt ab).

Geschäftsvorfall 4: Kunde meldet Störung

93

Abb. 64. GV3: Relevanter Ausschnitt Project Finalisation

Nach der Abnahme durch den Kunden wird das Projekt zeitlich verzögert auch intern abgeschlossen. Insbesondere die Garantiephase ist hierbei zu berücksichtigen.

Geschäftsvorfall 4: Kunde meldet Störung Dem folgenden Geschäftsvorfall liegen folgende Annahmen zu Grunde: Ein Anwender hat beim Drucken aus einer von unserem ICT-Unternehmen entwickelten Softwarelösung ein Problem. Immer wenn er die vorgeschlagenen Musterbriefe benutzt, werden, sobald die Seitenanzahl vier und mehr beträgt, grundsätzlich nur die ersten drei Seiten des Briefes ausgedruckt. Der Fehler ist jederzeit reproduzierbar. Der Geschäftsvorfall startet in dem Moment, in dem der Anwender mit dem ICT-Unternehmen Kontakt aufgenommen hat. Der Kommunikationskanal, z.B. Telefon oder E-Mail, ist für unseren Prozess zweitrangig. Wir gehen davon aus, dass der Anwender beim Service Desk unserer ICTUnternehmung angerufen hat. Dort wird der Kontakt entgegengenommen und einem Service-Desk-Mitarbeiter zur Bearbeitung zugewiesen. Nach der Beschreibung der Störung durch den Anwender wird der Vorfall vom Service-Desk-Mitarbeiter als Incident identifiziert.

Abb. 65. GV4: Relevanter Ausschnitt Contact Management (1)

94

Ausgewählte Geschäftsvorfälle

Der Incident wird mit der Fallbeschreibung erfasst. Der Service-DeskMitarbeiter sucht in der Knowledge Database nach einer zu dem beschriebenen Fall passenden Störungsbeschreibung und Lösung. In unserem Fall handelt es sich nicht um einen Known Error, also um einen bisher nicht bekannten Fehler. Der Service-Desk-Mitarbeiter vermutet als Ursache einen Software-Fehler und leitet mit Problem identifiziert die Problemanalyse im Prozess 421 Problem Handling ein. Als Umgehungslösung vereinbart er mit dem Anwender, dass dieser Briefe, die länger als drei Seiten sind, nicht mehr aus der Software-Lösung heraus druckt. Diese werden als Kopie ablegt und separat über das Textverarbeitungsprogramm des Anwenders ausgedruckt. Allerdings müssen in diesem Fall noch diverse manuelle Korrekturen bzw. Ergänzungen durchgeführt werden. Weiter wird vereinbart, dass der Anwender nach der Behebung des Fehlers informiert wird.

Abb. 66. GV4: Relevanter Ausschnitt Incident Management

In der Folge wird die gemeldete Störung analysiert. Hierbei wird festgestellt, dass es sich definitiv um einen Software-Fehler handelt. Der Fehler kann jederzeit reproduziert und beschrieben werden. Die vom ServiceDesk-Mitarbeiter vorgeschlagene Umgehungslösung wird als Standardlösung für diesen Fall übernommen. Der nun bekannte und beschriebene Fehler wird inklusive der vorgeschlagenen Umgehungslösung in der Knowledge Database dokumentiert. Mit dem Ereignis Known Error definiert wird dieser Teil abgeschlossen und die Fehlerbeseitigung angestoßen.

Abb. 67. GV4: Relevanter Ausschnitt Problem Handling

Ist ein Known Error definiert, sind in der Regel die Störungsauslöser bekannt. Weiter liegt eine mehr oder weniger abgesicherte Vermutung bzgl.

Geschäftsvorfall 4: Kunde meldet Störung

95

der Ursache vor. In unserem Fall gehen wir davon aus, dass es sich um einen Softwarefehler handelt. Der Prozess 422 Error Control koordiniert und überwacht die Problemlösung. Für die notwendige Korrektur der Software wird ein RFC formuliert. In der Folge wird die Problemlösung überwacht. Hierbei muss darauf hingewiesen werden, dass die eigentliche Überwachung durch eine Stelle erfolgt. Diese Stelle kann z.B. durch die Rolle Problem Manager beschrieben werden. Die Aufgabe des Problem Managers liegt nicht nur darin, die entsprechenden Prozesse um- und durchzusetzen, er entscheidet auch, wann ein Problem definitiv gelöst ist.

Abb. 68. GV4: Relevanter Ausschnitt Error Control

Im Change Management erfolgt die Analyse des RFCs und dessen Beurteilung. In unserem Fall kommt man zu dem Ergebnis, dass es sich um eine Fehlerbehebung handelt, die im Rahmen des Release Managements der betroffenen Software durchzuführen ist. Mit dem Ereignis R-Change identifiziert werden die entsprechenden Aktivitäten im Release Management angestoßen. Weiter wird festgestellt, dass es sich bei der Behebung um einen „Bugfix“ handelt, der die Auslieferung eines Patches4 zur Folge haben wird. In unserem Modell ist die Auslieferung eines Patches ein Standard Change, der nicht der Steuerung und Überwachung des Change-Management-Verfahrens unterstellt ist.

Abb. 69. GV4: Relevanter Ausschnitt Change Handling

4

Patch bezeichnet eine Korrekturlösung für eine Software. Aus Sicht des Release Managements handelt es sich hierbei i.d.R. um ein Mini-Release, das als Standard Change abgewickelt werden kann und nicht einem aufwändigen Change-Management-Verfahren unterstellt werden muss.

96

Ausgewählte Geschäftsvorfälle

Im 331 Release Planning wird nach der Analyse und der Festlegung der Dringlichkeit der Realisierungsauftrag erteilt.

Abb. 70. GV4: Relevanter Ausschnitt Release Planning

Mit der Erteilung des Realisierungsauftrages wird nun der gesamte Entwicklungsprozess, die Abnahme und die Konfiguration des ReleasePackages durchlaufen. In der Folge sind diese Prozesse verkürzt und ohne weiteren Kommentar dargestellt.

Abb. 71. GV4: Relevante Ausschnitte Entwicklung bis Release-Package Bildung

Ist das neue Release-Package konfiguriert, wird es in die Software Library überführt, die die produktiven Release-Packages verwaltet und für die Installation bereitstellt. Damit ist das neue Release produktiv. In unserem Beispiel handelt es sich um einen Patch (Mini-Release). Da durch diesen Patch ein vom Problem Management gemeldeter Fehler behoben wurde, wird über das Ereignis Release produktiv auch der Problem Manager über die Fertigstellung eines neuen Patches und somit über die Fehlerbeseitigung informiert.

Geschäftsvorfall 4: Kunde meldet Störung

97

Abb. 72. GV4: Relevanter Ausschnitt Release Package Management

Der Problem Manager prüft und entscheidet, ob mit der vorliegenden Lösung der Fehler beseitigt wurde. Kommt er zum Ergebnis, dass der Known error behoben ist, ist das Problem gelöst und alle damit verbundenen Überwachungsaktivitäten können eingestellt werden.

Abb. 73. GV4: Relevanter Ausschnitt Error Control

Abschließend wird mit dem Anwender, der die Störung meldete, Kontakt aufgenommen. Er wird über die Problemlösung und die Problembeseitigung durch die Installation des Patches informiert. Der Kontakt, der in der Praxis meist in Form eines so genannten Incident-Tickets dokumentiert ist, wird anschließend abgeschlossen.

Abb. 74. GV4: Relevanter Ausschnitt Contact Management (2)

Damit ist die End-to-End-Betrachtung des Geschäftsvorfalls Kunde meldet Störung, ausgelöst durch eine Störungsmeldung und beendet mit der Rückmeldung an den Kunden, abgeschlossen.

Prozessbereiche und Prozesskategorien

Einführung In diesem Kapitel werden die Prozessbereiche des Prozess-Referenzmodells und ihre Prozesskategorien beschrieben. Die folgende Abbildung stellt die Position der einzelnen Prozessbereiche und ihre Prozesskategorien im Modell dar:

Abb. 75. Die Prozessbereiche und ihre Prozesskategorien

100

Prozessbereiche und Prozesskategorien

Die Prozessbereiche sind von 1 bis 7 durchnumeriert. Ihre Titel verweisen auf die Art der Aufgaben, die die Prozesse, die diesem Bereich zugeordnet sind, erfüllen. 1. Prozessbereich Management 2. Prozessbereich Sales 3. Prozessbereich Customer Services 4. Prozessbereich Project & Development 5. Prozessbereich Support 6. Prozessbereich Operations 7. Prozessbereich Logistics & Infrastructure Auf dem beigelegten Poster sind die einzelnen Kategorien an der zweistelligen Nummer sowie der jeweiligen Bezeichnung zu erkennen. Dort sind die Hauptprozesse grafisch aufbereitet, wobei nur die wesentlichen Prozessschritte dargestellt sind. Die Hauptprozesse werden anhand einer dreistelligen Zahl plus einer entsprechenden Bezeichnung identifiziert. Sie werden jeweils mit ihren den Prozess auslösenden sowie den Prozess abschließenden Ereignissen dargestellt. Weiter sind zwecks besseren Verständnisses der Prozessinhalte beispielhafte Aufgabenketten beschrieben. In den folgenden Kapiteln wird eine weitere Darstellungsform eingesetzt:

Abb. 76. Darstellung der Prozesskategorien und ihre Verknüpfungen

Prozessbereich Management

101

Im Zentrum befinden sich die Prozesskategorie sowie die Hauptprozesse, die dieser Kategorie zugeordnet sind. Auf der linken Seite sind alle Ereignisse, die Aufgaben in den jeweiligen Hauptprozessen anstoßen, sowie die Prozesse bzw. die Rollen1, die diese Ereignisse erzeugen, dargestellt. Auf der rechten Seite befinden sich die Ereignisse, die von den Hauptprozessen erzeugt werden, sowie die Prozesse und Rollen, die auf diese Ereignisse reagieren müssen. Beim Lesen der folgenden Beschreibungen empfiehlt es sich, das Poster bereitzuhalten und parallel die einzelnen Prozesse darauf zu verfolgen. An dieser Stelle soll noch einmal erwähnt werden, dass das ReferenzProzessmodell ein Muster darstellt, welches individuell angepasst, erweitert bzw. reduziert werden muss. Einerseits ist davon auszugehen, dass für Sie bestimmte Themen zu gering, andere dafür zu stark und manche gar nicht behandelt werden. Andererseits besteht aufgrund der Komplexität der Materie – wir streifen ja quasi die gesamte Informatik – kaum die Möglichkeit zu einer umfassenden und detaillierten Erörterung aller Sachgebiete. Aus diesem Grunde verweisen wir im Anhang auf eine Auswahl einschlägiger Literatur. In den folgenden Kapiteln werden Bezeichnungen von Ereignissen, Prozessen und Prozesskategorien in den Texten kursiv dargestellt. Der Hauptprozess, der beschrieben wird, wird jeweils im ersten Absatz, in dem er genannt wird, fett gedruckt.

Prozessbereich Management Der Prozessbereich Management beinhaltet die in Abbildung 77 dargestellten Prozesskategorien. Eine Besonderheit des Prozess-Referenzmodells und damit dieses Kapitels liegt darin, dass einzelne Themenbereiche, die in sich abgeschlossene Funktionen der Betriebswirtschaftslehre darstellen, wie Finanzen, Controlling und Rechnungswesen, Einkauf, Marketing und Personalwesen, nur

1

Die verwendeten Rollen beschränken sich auf die im Kapitel ICT Company im Rahmen der Kontextdefinition aufgeführten Rollen (z.B. die Rolle Kunde). Zusätzlich wird noch die selbsterklärende Rolle ICT Management benutzt.

102

Prozessbereiche und Prozesskategorien

Abb. 77. Der Prozessbereich Management

aus einer ganz speziellen Sicht und dann auch nur punktuell (bedarfsorientiert) behandelt werden. Einzelne Themen wie z.B. die Organisation der Personalressourcen, der Produktentwicklung oder der Leistungsverrechnung stehen in unmittelbarem Zusammenhang mit den Prozessen der anderen Prozessbereiche, so dass diese gezielt integriert wurden. Alle anderen Aspekte des jeweiligen Themenbereiches wie z.B. Personalrekrutierung, Entwicklung von Vertriebskanälen oder das Mahnwesen werden als „gegeben“ angenommen. ICT Supplier Management Die Prozesskategorie 11 ICT Supplier Management umfasst die wichtigsten Aufgaben im Zusammenhang mit dem Management der Lieferanten. Zugeordnet sind die folgenden fünf Hauptprozesse: • 111 Partner Management • 112 Supplier Contract Management

Prozessbereich Management

103

• 113 Supply Chain Management • 114 Purchasing • 115 Licence Management Der Prozess 111 Partner Management beinhaltet die Aufgaben, die im Zusammenhang mit der Suche nach qualifizierten Partnern anfallen. Hierzu gehören die Evaluation, die Ausarbeitung möglicher Zusammenarbeitsverträge sowie in der Folge die regelmäßige Beurteilung der Partner aufgrund von Audits. Der Prozess kann von mehreren Ereignissen angestoßen werden: • Kooperationsanfrage gestellt; dieses Ereignis tritt ein, wenn ein potenzieller Partner von sich aus das ICT-Unternehmen zwecks Kooperation anspricht. • Partner-Suchauftrag erteilt; in diesem Fall sucht das ICT-Unternehmen selbst gezielt Kooperationen. Erzeugt wird dieses Ereignis im Prozess 134 Product & Service Management. • Vertragsänderung notwendig; bei einer bestehenden Kooperation müssen die Verträge geändert werden. Auslöser ist der Prozess 112 Supplier Contract Management. • Partner-Audit notwendig; ein Audit, das zum Beispiel die Lieferqualität oder die wirtschaftliche Stabilität des Kooperationspartners prüfen soll, kann von einer Reihe von Prozessen ausgelöst werden. In unserem Prozess-Referenzmodell sind dies die Prozesse: o 161 Audit & CIP o 162 QM-System o 163 Risk Management o 312 Project Control • Kreditorenbericht erstellt; löst im Partner Management eine Überprüfung des Forderungsverhaltens aus. Die Aufgaben des Prozesses 111 Partner Management erzeugen eine Reihe von Ergebnissen: • Kooperationsvertrag vorgeschlagen ist eine externe Schnittstelle2 zum Partner, dem eine entsprechende Vereinbarung vorgelegt wird. 2

Eine externe Schnittstelle ist im vorliegenden Zusammenhang eine Schnittstelle vom Unternehmen zum externen Partner. Das Ereignis sagt aus, dass der Prozess mit diesem Ergebnis abgeschlossen wurde. Würden nun noch die Leistungen (siehe Kapitel Modellkonzept & Methoden) aufgeführt, wären dies z.B. die Vertragsdokumente.

104

Prozessbereiche und Prozesskategorien

Abb. 78. ICT Supplier Management

Prozessbereich Management

105

• Kooperationsvertrag unterschrieben; in diesem Fall wurden alle Bedingungen für das Zustandekommen eines Vertrages erfüllt; die damit verbundenen und folgenden administrativen Tätigkeiten erfolgen im Prozess 112 Supplier Contract Management. • Partner beurteilt; eine Bewertung des Partners ist erfolgt, die Ergebnisse sind ihm mitgeteilt worden und gegebenenfalls löst das Ereignis den Prozess 113 Supply Chain Management oder den Prozess 162 QM-System aus. • Partner-Risiko erkannt; die vom ICT-Unternehmen definierten Bedingungen, dass ein Risiko in der Zusammenarbeit mit dem Partner vorliegt (z.B. drohendes Konkursrisiko), gelten als erfüllt. Der Prozess 122 Supplier Contract Management wird angestoßen. Insbesondere bei einer intensiveren Zusammenarbeit mit mehreren Zulieferern hat ein organisiertes Partner-Management die Aufgabe, die Produktion mit einer ausreichenden Anzahl an qualifizierten und geprüften Partnern zu versorgen. Standardisierte Rahmenverträge aller Art sichern hierbei die Interessen der Unternehmung ab. Durch regelmäßige Audits werden die Partner gezielt entwickelt und die Zulieferprozesse optimiert. Mit dem Prozess 112 Supplier Contract Management werden die Aufgaben definiert, die im Rahmen der Vertragsverwaltung und vor allem der Vertragsüberwachung anfallen. Neben der in bestimmten Zeitintervallen notwendigen regelmäßigen Aktualisierung der Verträge (z.B. Vertragsverlängerungen, Neuverhandlungen von Konditionen etc.) sind vor allem die Fälle, bei denen es zu Vertragsabweichungen kommt, zu bearbeiten. Auslösende Ereignisse sind hier: • Periodisch; z.B. halbjährliche Überprüfung der Vertragsvereinbarungen oder zu den in den Verträgen hierfür definierten Terminen • Partner-Risiko erkannt; die beim Partner identifizierten Risiken bedingen eine Überprüfung der Vertragssituation. Dieses Ereignis kann ein Resultat der folgenden Prozesse sein: o 111 Partner Management o 161 Audit & CIP

106

Prozessbereiche und Prozesskategorien

o 163 Risk Management o 313 Project Risk Management • S-Vertrag3 gekündigt bedeutet die Kündigung eines Lieferantenvertrages zwischen der ICT-Unternehmung und einem Supplier durch den Supplier. • Kooperationsvertrag unterschrieben, ausgelöst durch den Prozess 111 Partner Management und dem Kooperationspartner, leitet die damit verbundenen administrativen Tätigkeiten ein. • S-Vertrag unterzeichnet als Resultat des Prozesses 114 Purchasing leitet die mit dem Vertrag verbundenen administrativen Aufgaben ein. Ergebnisse des Prozesses 112 Supplier Contract Management können sein: • Nachbesserung gefordert, d.h. der Lieferant hat seine vertraglichen Verpflichtungen nicht erfüllt und muss nachbessern. • Entschädigung gefordert, d.h. hier erhebt das ICT-Unternehmen einen massiven finanziellen Anspruch an einen Supplier. Dieses Ereignis löst auch den Prozess 142 Invoicing aus, in dem dann evtl. noch offene Rechnungen zu Gunsten des betroffenen Lieferanten zurückgehalten werden. • S-Vertrag gekündigt; in diesem Fall wurde ein spezifischer Lieferbzw. ein allgemeiner Lieferantenvertrag gekündigt. • Vertragsänderung notwendig löst entsprechende Folgeaktivitäten in den Prozessen 111 Partner Management und 114 Purchasing aus. Die Verwaltung und das Controlling von Lieferantenverträgen als Disziplin sind in etwa so alt wie das Unternehmertum selbst. Unabhängig davon finden sich aber gerade in ICT-Unternehmungen hier z.T. erhebliche Defizite, vor allem dort, wo statische Vertragsstrukturen in Konflikt mit der Entwicklungsdynamik der eingesetzten Technologien / Produkte geraten.

3

Wir unterscheiden im Partner Management den Supplier-Vertrag und den Kooperationsvertrag. Der Supplier-Vertrag ist als Vereinbarung über die Lieferung von Leistungen auf der Basis eines Rahmen- oder Einzelvertrages zu verstehen. Ein Kooperationsvertrag regelt eine grundsätzliche Zusammenarbeit (zum Beispiel in der Produktentwicklung).

Prozessbereich Management

107

Der Überwachung der Lieferkette kommt immer dort, wo mit einem hohen Anteil an Fremdfertigung gearbeitet wird, eine hohe Bedeutung zu. Im Prozess 113 Supply Chain Management sind die entsprechenden Aufgaben angesiedelt. Die wichtigsten auslösenden Ereignisse kommen aus den Bereichen Operations, Project & Development und Customer Services: • Produktionsbericht erstellt; ein Resultat der Prozesse 512 Availability Management, 513 Capacity & Performance Management, 521 Production Control und 612 Customer Services Monitoring • Projektbericht erstellt; ein Ergebnis des Prozesses 312 Project Control • Servicebericht erstellt schließt die Prozesse 632 Repair Management und 633 Installation & Allocation Management ab. • Auditbericht erstellt resultiert aus dem Prozess 161 Audit & CIP. Die vorhergehenden Ereignisse führen zu einer Analyse der vom Lieferant erbrachten Leistungen und zu der anschließenden systematischen Suche nach Optimierungspotenzialen. Auch die folgenden Ereignisse können Auslöser für die Suche nach Möglichkeiten zur Optimierung auf Seiten des Lieferanten sein: • Prozessvorgabe erstellt, ein Ergebnis des Prozesses 164 Process Management; Veränderungen von Prozessen innerhalb der ICT-Unternehmung können auch Anpassungen seitens der Lieferanten bedingen. • Partner beurteilt; die Ergebnisse eines Partner-Audits (111 Partner Management) liegen vor und die gefundenen Verbesserungs- bzw. Optimierungspotenziale sind umzusetzen. • Nachbesserung gefordert als Resultat des Prozesses 112 Supplier Contract Management deutet auf eine Abweichung der erbrachten Leistung von der geforderten Leistung hin. Seitens der ICT-Unternehmung können gegebenenfalls Vorschläge zur zukünftigen Vermeidung entsprechender Abweichungen gemacht werden. Die Ergebnisse des Prozesses 113 Supply Change Management sind: • Verbesserungspotenzial identifiziert, beschrieben und dem Geschäftspartner mitgeteilt.

108

Prozessbereiche und Prozesskategorien

• Prozessänderung identifiziert, beschrieben, dem Geschäftspartner mitgeteilt und den Prozess 164 Process Management angestoßen. • Verbesserung vorgeschlagen; dieses Ereignis löst den kontinuierlichen Verbesserungsprozess (164 Audit & CIP) des ICT-Unternehmens aus. Unter dem Stichwort Supply Chain Management existiert heute ein eigenes Forschungs- und Entwicklungsgebiet, was auch die zahlreiche Literatur zu diesem Thema widerspiegelt. Fakt ist, dass nach der Optimierung der internen Prozesse die Optimierung der externen Zulieferprozesse für Unternehmen ein großes Optimierungspotenzial birgt. Der klassische Einkaufsprozess wird in 114 Purchasing abgebildet. Der Prozess kann in zwei Bereiche aufgegliedert werden. Der eine beinhaltet vor allem die Einholung und Bearbeitung von Offerten sowie die Vertrags- und Einkaufsverhandlungen. Er wird durch die folgenden Ereignisse ausgelöst: • Bedarf formuliert; in diesem Fall ist der Bedarf nach einer externen Leistung bzw. nach einem speziellen Produkt bezüglich der Art der Leistung, der Menge, des erwarteten Lieferdatums etc. spezifiziert. Das Ereignis ist ein Resultat der Prozesse o o o o o o

115 Licence Management 151 Professional Development 152 Human Resource Planning 311 Project Planning 641 Education & Training Planning 742 Material & Inventory Management

• Offerte eingereicht, durch den Lieferanten • Vertragsänderung notwendig, ein Ergebnis des Prozesses 112 Supplier Contract Management, kann ebenfalls zur Aufforderung der Abgabe einer Offerte führen. Die Ergebnisse, die mit der Einholung und den Verhandlungen verbunden sind, sind: Offerte angefordert und S-Vertrag unterzeichnet.

Prozessbereich Management

109

Der zweite Bereich des Prozesses 114 Purchasing beinhaltet vor allem die Auslösung der Bestellung4 durch das Ereignis Lieferauftrag freigegeben als Resultat des Prozesses 311 Project Planning. Ergebnisse sind: • HW bestellt • SW bestellt • Dienstleistung bestellt • CI geändert Während die externern Schnittstellen wie Software bestellt, Hardware bestellt und Dienstleistung bestellt an dieser Stelle mehr informativen Charakter haben, muss auf das Ereignis CI geändert gesondert hingewiesen werden. Dieses Ereignis stößt die Prozesse 432 CI Verification und 433 CI Document Management an. Mit der Bestellung von Objekten, die im Rahmen des Configuration Management verwaltet werden, beginnt deren Lifecycle. Mit anderen Worten, mit der Bestellung z.B. einer Hardware, wird das bestellte Objekt mit den Bestelldaten erstmals in der Configuration Database erfasst. Im Großen und Ganzen handelt es sich bei den hier beschriebenen Aktivitäten um klassische Einkaufsaufgaben. Wichtig ist zu beachten, dass, insofern Configuration Items (vorwiegend Hard- und Software) bestellt werden, diese erstmals in einer internen Datenbank erfasst werden und somit ein unbedingt zu beachtender Bezug zum Thema Configuration Management besteht. Die Zuordnung des Prozesses 115 Licence Management zu der Prozesskategorie 11 ICT Supplier Management mag den einen oder anderen überraschen. Aufgrund der Erfahrung, dass die Anzahl der benötigten Fremdlizenzen sowohl im Fall des Eigengebrauchs als auch des Weiterverkaufs primär ein Einkaufs- und ein Partner-Management-Thema ist, wurde dieser Prozess hier zugeordnet. 4

Wir haben uns im Modell bewusst dafür entschieden, die Auslösung von Bestellungen von externen Leistungen und Produkten auf den Prozess 311 Project Planning zu konzentrieren. Wir verzichten auf die Darstellung der Bestellauslösungen für die alltäglichen Bedarfs- und Verbrauchsgüter, die z.B. durch eine Lagerverwaltung oder eine Rolle ausgelöst werden.

110

Prozessbereiche und Prozesskategorien

Ausgelöst wird der Prozess durch das Ereignis Lizenz benötigt, welches ein Ergebnis des Prozesses 222 Contract Administration oder des Prozesses 431 System Configuration ist. Dass eine Lizenz abgelaufen ist, wird ebenfalls im Prozess 222 Contract Administration realisiert. Ergebnisse dieses Prozesses sind, dass eine Lizenz aktiviert bzw. eine Lizenz deaktiviert wird (Schnittstellen zum Kunden) oder, falls Lizenzen eingekauft werden müssen, wird der Bedarf formuliert und damit der Prozess 114 Purchasing angestoßen. Das Lizenz-Management ist ein in sich komplexes Thema, da insbesondere bei größeren Unternehmungen sehr schnell die Übersicht verloren gehen kann, welche Fremdsoftware gerade wo und in welcher Anzahl installiert und lizenziert ist.

ICT Program Management Jede ICT-Unternehmung steht täglich vor der Herausforderung, ihre finanziellen und personellen Ressourcen nicht nur ökonomisch sinnvoll einzusetzen, sondern auch insbesondere das dynamische, projektorientierte Geschäft planerisch zu beherrschen. Die Balance zu halten zwischen laufenden, anstehenden und sich in der Akquisition befindlichen Vorhaben ist nur dann möglich, wenn eine Übersicht über alle laufenden, geplanten und erwarteten Vorhaben möglich ist. Hinzu kommt in den meisten Fällen noch die Anforderung, zwischen den investiven internen und den bezahlten externen Vorhaben ausgewogen abzuwägen. Das 12 ICT Program Management umfasst die Aufgaben, die für die übergeordnete Steuerung projektorientierter Vorhaben notwendig sind. Der Einsatz der verfügbaren Mittel wird bestimmt durch: • Laufende Verträge / Aufträge, • Aktuellen Status der Projekte, • Evtl. anstehende größere Change-Anträge aus dem Projektumfeld, • In der Akquisition / in den Vertragsverhandlungen befindliche Aufträge, • Evtl. erkannte Risiken, die die Auftragsabwicklung gefährden. Die Aufgaben und die Aufträge des Betriebs werden aufgrund ihrer statischen Eigenschaften nicht in der Programm-Planung berücksichtigt. Je nach Organisation macht es aber Sinn, die Ressourcen des Betriebes in der

Prozessbereich Management

111

Abb. 79. ICT Program Management

Planung zu berücksichtigen, z.B. die Spezialisten, die in Projekten eingesetzt werden. Interne Vorhaben, die den Betrieb betreffen wie z.B. Ausbau der Infrastruktur etc. sind dem Programm-Management unterstellt. In diesem Themenbereich sind auch die Konzepte, Verfahren und Techniken des Multi-Projekt-Managements anzusiedeln. In der Praxis gibt es allerdings immer nur zwei Zustände. Sind genügend Aufträge vorhanden, fehlen die Ressourcen, hat man ausreichend Ressourcen, fehlen die Aufträge. Bei den wichtigsten Ressourcen (Spezialisten, Projektleiter, Geld etc.) gibt es in der Praxis sowieso immer Engpässe.

112

Prozessbereiche und Prozesskategorien

Im Prozess 121 Program Planning erfolgen die erste Prüfung des Projektantrages sowie die eigentliche Planung der Ressourcen unter Berücksichtigung der Termine und des Budgets. Die Gesamtheit aller laufenden, geplanten und erwarteten Vorhaben ergibt das Programm. Auslösende Ereignisse hierfür sind: • Eine periodische (z.B. monatliche) Überprüfung der Ressourcensituation unter spezieller Berücksichtigung der Fluktuation, der Neueinstellungen, des Krankenstandes, Urlaubs-, Ausbildungs- und sonstiger Abwesenheiten, • Eine periodische (z.B. jährliche) Planung interner Vorhaben, • Angebot erstellt als Ergebnis des Prozesses 221 Contract Management, • Projekt beantragt als Resultat des Prozesses 311 Project Planning, • Aktualisierung Projektplanung initialisiert als Folge einer Annahme von Changeanträgen im Prozess 123 Project Control, die sich auf das Projekt bzw. auf die Planung des Projektes auswirken. Aus dem Modell ist nicht direkt ersichtlich, woher die Initiativen für interne Vorhaben, die zur Weiterentwicklung der Unternehmung beitragen, kommen. Ein Strategieprozess5 in dem Sinne, dass dieses Vorhaben definiert und Projekte für die Weiterentwicklung der Unternehmung vorgeschlagen werden, ist im Modell nicht abgebildet. Stellvertretend hierfür ist die Aufgabe Vorhaben planen in den Planungsprozess integriert. Die Ergebnisse des Prozesses 121 Program Planning haben hauptsächlich drei Adressaten: • Den Prozess 311 Project Planning; dieser wird durch die Ereignisse Projekt vorgeschlagen und Planungsauftrag erteilt aktiviert, • Den Prozess 152 Human Resource Planning, der aufgrund des Ergebnisses Kapazitäts- und Skill-Bedarf erstellt angestoßen wird, • Den Prozess 143 Budgeting, wenn ein Budgetbedarf formuliert wurde. Mit dem Ergebnis Projekt / Entwicklungsprogramm aktualisiert werden Rollen / Prozesse angestoßen, die nicht im Modell abgebildet sind. In diesem

5

In der Einführung zum Prozess-Referenzmodell wurde erläutert, dass im Bereich der Management-Prozesse nur auf die Aspekte eingegangen wird, die unmittelbar mit der Leistungserbringung einer ICT-Unternehmung zu tun haben.

Prozessbereich Management

113

Fall könnten dies z.B. die Themenbereiche der Investitionsplanung und Kapitalbedarfsplanung sein. Wird ein Projekt abgelehnt, wird der Prozess und damit die weitere Bearbeitung abgeschlossen. Die Planung aller Vorhaben einer Unternehmung im Sinne eines Programms stellt hohe Anforderungen an die Organisation und das Management. Die Komplexität bzgl. Informations- und Entscheidungsbedarf nimmt mit der Größe der Unternehmung zu. Das Abwägen zwischen umsatzbringenden, ressourcenbindenden Aufträgen und Investitionen in eigene Entwicklungsvorhaben unterliegt der unternehmerischen Verantwortung. Mit der Vorlage der unterzeichneten Verträge durch den Kunden werden im Prozess 222 Contract Administration als Ergebnisse dieses Prozesses der Consulting-Auftrag freigegeben bzw. der Entwicklungsauftrag freigegeben. Die nun erforderliche definitive Freigabe des Projektes sowie die Zuordnung der Ressourcen erfolgt im Prozess 122 Approval Procedure. Dieser Prozess muss auch durchlaufen werden, wenn im Rahmen des 311 Project Planning der Projektplan aktualisiert wurde. Erfolgt keine Freigabe des Projektes, wird das Projekt abgelehnt. Erfolgt die Freigabe, werden die Ressourcen definitiv zugeteilt, anschließend wird der Projektauftrag freigegeben, die Steuerungsvorgaben definiert (für das Projekt Controlling) sowie die Ressourcen alloziiert. Während die Planung typischerweise Planungsszenarien beinhaltet, werden bei der definitiven Zuordnung der Ressourcen auch definitive Entscheidungen gefällt. Der Prozess an sich ist einfach, dies gilt aber nicht zwingend auch für die Entscheidungsfindung. Der dritte und letzte Prozess innerhalb des Programm-Managements ist der Prozess 123 Program Control. Mit diesem Prozess werden die dem Programm zugeordneten Projekte überwacht. Die Überwachung konzentriert sich auf die drei Schwerpunkte: Projektverlauf, Risiken und Projektänderungen.

114

Prozessbereiche und Prozesskategorien

Die eigentliche Entscheidungsfindung, was in welchem Fall zu tun ist, ist im Modell nicht abgebildet und muss im Rahmen der detaillierten Beschreibung des Prozesses geregelt werden. Vereinfacht können aber drei Situationen berücksichtigt werden: • Alles läuft im „grünen“ Bereich, dann sind keine weiteren Maßnahmen notwendig. • Es werden Risiken erkannt. Diese müssen abgeklärt werden und evtl. müssen die Kriterien der Steuerung und Überwachung angepasst werden. • Das Vorhaben läuft vollständig aus dem Ruder, dann kommen klassische Krisenszenarien zum Tragen, die entweder in speziellen Steuerungs- und Überwachungsvorgaben enden oder schließlich zum Projektabbruch führen. Ausgelöst wird der Prozess 123 Program Control bei Eintritt folgender Ereignisse: • Projektbericht erstellt; ein Resultat des Prozesses 312 Project Control. Auf der Basis des Projektberichtes kann der Projektverlauf überwacht werden. • Auditbericht erstellt; ein Ergebnis des Prozesses 161 Audit & CIP. Jeder Auditbericht beinhaltet potenzielle Hinweise auf Projektrisiken und auf den Projektverlauf allgemein. Hierbei muss es sich nicht nur um projektspezifische Audits handeln. Auch Audits, die aus anderen Gründen ausgelöst wurden, können Hinweise enthalten, die ein oder mehrere Projekte betreffen. • Risikoanalyse erstellt; Hauptergebnis des Prozesses 163 Risk Management. Auch hier kann es sich um ein Ergebnis handeln, das projektspezifisch oder projektunabhängig ist. Ein Beispiel: Ein Kunde, für den parallel fünf Projekte abgewickelt werden, hat wirtschaftliche Probleme. Er hat einen Stellenabbau von 25% seiner Belegschaft angekündigt. Diese Situation kann für die fünf Projekte ohne Belang sein, es könnten aber auch einzelne oder gar alle fünf Projekte davon betroffen sein. • Risikoanalyse aktualisiert; eine existierende Risikoanalyse wurde aufgrund neuer Erkenntnisse auf den neuesten Stand gebracht. Dies kann sowohl die zugrunde liegenden Informationen als auch deren Interpretation betreffen. Eine Aktualisierung einer Risikoanalyse kann das Ergebnis der folgenden Prozesse sein:

Prozessbereich Management

115

o 163 Risk Management o 311 Project Planning o 313 Project Risk Management • Projekt abgeschlossen ist ein Ergebnis des Prozesses 215 Project Finalisation und zeigt an, dass das Projekt nicht nur gegenüber dem Kunden, sondern auch gemäß den internen Richtlinien des Unternehmens abgeschlossen wurde und damit das Projekt aus der Überwachung durch das Programm-Management entlassen werden kann. • P-Change-Antrag gestellt; ein Resultat des Prozesses 314 Project Change Management. Ein Änderungsantrag, der über die Kompetenzen der Projektleitung hinausgeht und dem Programm-Management gemeldet wird. Dies können z.B. Änderungen sein, die die Projektrisiken erhöhen, die mehr oder länger Ressourcen binden, die andere Projekte beeinflussen etc. Der Prozess 123 Program Control weist in unserem Modell folgende Ergebnisse auf: • P-Risiko erkannt; es wurde ein spezifisches Projektrisiko erkannt (z.B. Absehbarer Ressourcenengpass im Projekt). Das Ereignis stößt den Prozess 314 Project Risk Management an. • Risiko erkannt; ein allgemeines Risiko (z.B. betreffend der Zusammenarbeit mit einem Partner) wird im Prozess 163 Risk Management genauer analysiert. • Steuerungsvorgaben definiert; damit sind die Vorgaben, nach denen das Projekt im Prozess 312 Project Control überwacht und gesteuert wird, festgelegt. • Aktualisierung Projektplanung initialisiert; ein Eingriff seitens des Programm-Managements nimmt voraussichtlich Einfluss auf die Projektplanung. Diese ist im Prozess 311 Project Planning zu aktualisieren. • P-Change-Antrag entschieden; ein vom Programm-Management zu beurteilender Projektänderungsantrag wurde entschieden und zur weiteren Bearbeitung an den Prozess 314 Project Change Management übergeben.

116

Prozessbereiche und Prozesskategorien

Das Horrorszenario des Abbruchs eines Kundenprojekts mit Rückabwicklung und allen weiteren möglichen Konsequenzen muss sicherlich nicht im Rahmen eines Prozessmodells oder der Planung einer Ablauforganisation berücksichtigt werden. Allerdings empfiehlt es sich durchaus, auf Managementebene ein entsprechendes Planspiel durchzuspielen und die Erfahrungen in Form einer Checkliste für den Notfall zu dokumentieren.

ICT Marketing ICT-Unternehmen treten heute meist als so genannte IT Service Provider am Markt auf. Dieser eher allgemeine Begriff umfasst sowohl die Herstellung, Lieferung und Installation von Hard- und Software als auch deren Betrieb. Die Leistungen / Produkte werden als Services bezeichnet und vermarktet. Das ITIL-Konzept basiert schlussendlich auf der Philosophie der Serviceerbringung und fokussiert sich auf die Themen des Service Managements und der Service Delivery. In der Prozesskategorie ICT Marketing streifen wir mit der Berücksichtigung einiger weniger Prozesse eine in sich sehr umfangreiche, komplexe und zentrale Funktion der Betriebswirtschaftslehre: das Marketing6. Die Berücksichtigung einiger weniger zentraler Prozesse ist vor allem in Zusammenhang mit dem Produktkatalog und dem Produktportfolio der ICTUnternehmung wichtig. Die Thematik der Produkt- / Leistungsdefinition (in ITIL die Definition der zu erbringenden Services) ist in der Praxis ein wichtiges und zentrales Thema. Die Definition und die Pflege eines Service- bzw. Leistungs- oder Produktkataloges ist ein zentrales Anliegen einer ICT-Unternehmung, da diese die Grundlagen für den Verkauf der eigenen Leistungen darstellt. Der Servi6

Eine allgemein akzeptierte Marketing-Definition hat die wissenschaftliche Literatur nicht hervorgebracht. Gängig ist jedoch der Begriff „Marketing Mix“, eine Aufstellung der einzelnen operativen Marketing-Maßnahmen in den Aufgabenbereichen Preis (Preisfindung), Produkt (Produktentwicklung), Distribution (Verkauf) und Kommunikation (Werbung). Im Jahr 1985 definiert die American Marketing Association (AMA) „Marketing” wie folgt: „Marketing is the process of planning and executing the conception, pricing, promotion and distribution of ideas, goods and services to create exchanges that satisfy individual and organisational objectives.“ (s. Marketing News, March 1, 1985, Vol. 19, No. 5, S. 1). Diese Definition ist bis heute allgemeine Lehrmeinung.

Prozessbereich Management

117

Abb. 80. ICT Marketing

ce- bzw. Leistungs- oder Produktkatalog eines ICT-Unternehmens kann schnell eine hohe Komplexität erreichen, da einerseits durch fast beliebige Kombinationen von Leistungen neue Services definiert und in der Regel diese Services dann auch noch in verschiedenen Kategorien (Service Levels7) angeboten werden können. 7

Erbringung einer Leistung in unterschiedlichem Umfang zu unterschiedlichen Preisen: Beispiel: Service Level „Gold“: Erreichbarkeit des Help Desks rund um die Uhr, „Silber“ von 6:00 bis 18:00 und „Bronze“ von 8:00 bis 17:00.

118

Prozessbereiche und Prozesskategorien

Service Levels spielen vor allem bei Dienstleistungen mit permanentem Charakter, wie sie der Betrieb erbringt oder wie sie im Rahmen von Kundenservices (wie z.B. Hotline- / Help-Desk-Leistungen) erbracht werden, eine Rolle. In der Praxis, insbesondere bei internen ICT-Organisationseinheiten, werden oftmals alle zu erbringenden Leistungen, z.B. auch Software-Entwicklung oder Hardware-Lieferungen, als „Services“ vermarktet. Die vertraglichen Vereinbarungen mit den Kunden werden in diesem Zusammenhang als Service Level Agreements, deren Überwachung als Service Level Management bezeichnet. Neutral betrachtet haben wir hier die Situation, dass Produkte definiert und angeboten werden. Der Vertrieb verkauft diese Produkte und vereinbart die Verträge. Die Produktion erfüllt die vereinbarten Leistungen, die Leistungserfüllung wird vom entsprechenden Vertrags-Management überwacht. Auch wenn es mancher ITler gar nicht gerne hört: Die Gesetze des Marketings gelten auch für die Leistungen von ICT-Unternehmungen und die erbrachten Leistungen sind zumindest aus Marketingsicht nicht so kompliziert, wie die dahinterliegende Technologie es manchmal vermuten lässt. Die Definition der Leistungen und Produkte, die ein ICTUnternehmen erbringt, ist von zentraler Bedeutung. Das ITILKonzept basiert darauf, dass eine ICT-Unternehmung Services erbringt, die im Rahmen eines Service Level Agreements vereinbart und deren Leistungserfüllung durch das Service Level Management überwacht werden. Unternehmen, die keine Services definiert haben bzw. kein Servicekonzept entwickelt haben, sind auch schwerlich in der Lage, das ITILKonzept einzuführen und umzusetzen. Im Prozess-Referenzmodell haben wir uns auf folgende Disziplinen konzentriert: 1. die Produktentwicklung, 2. die Erhebung und Sammlung von Informationen, die Hinweise / Ideen für die Entwicklung neuer Produkte geben, 3. die Erhebung und Sammlung von Informationen, die Auskunft über den Einsatz / Verkauf der Produkte / Leistungen (Produktportfolio) geben,

Prozessbereich Management

119

4. die Erhebung und Sammlung von Informationen, die Auskunft über den Einsatz / Verkauf der Produkte / Leistungen bei einzelnen Kunden (Kundenportfolio) geben, 5. die Kommunikation im Sinne der Werbung, da unser Musterunternehmen mit Schulungsangeboten und Hardware Leistungen / Produkte anbietet, deren Vermarktung durch klassische Werbemaßnahmen gefördert wird. Der Prozess 131 Marketing Management ist auf die Kommunikation mit dem Kunden fokussiert. D.h., hier erfolgen die allgemeine Ansprache des Kunden bzw. des Marktes sowie die Durchführung von Bedarfs- und Zufriedenheitsanalysen. Auslösende Ereignisse sind entweder zeitgesteuert (wie z.B. periodisch stattfindende Umfragen) oder Ereignisse, die eine werbende oder informierende Kommunikation mit dem Kunden auslösen. Diese sind: • Periodisch; Durchführung von Marketingaktionen, Umfragen, Zufriedenheitsanalyse etc., • Produkt freigegeben als Ergebnis der Produktentwicklung (134 Product & Service Management), • Produktportfolio aktualisiert; ein Resultat des Prozesses 133 Product Portfolio Management, • Seminarplanung aktualisiert als Ergebnis des Prozesses 641 ICT Customer Education Management, • Audit-Bericht erstellt als Resultat des Auditprozesses 161 Audit & CIP, wenn z.B. aufgrund der Ergebnisse des Audits eine gezielte Kommunikation (wie z.B. eine Rückrufaktion) mit den Kunden notwendig erscheint, • Umfrage beantwortet; von einer Umfrage liegen die Rückmeldungen in einer statistisch ausreichenden Stichprobe vor und können nun ausgewertet und analysiert werden. Die Ergebnisse des Prozesses 131 Marketing Management wirken einerseits nach außen, andererseits stoßen sie weitere Prozesse der Unternehmung an: • Kontaktaufnahme gestartet, Einladung zugestellt und Werbedokumente zugestellt symbolisieren Ergebnisse des Prozesses, die zum Ziel haben, Kunden über neue Produkte bzw. Produktentwicklung zu informieren und bei ihnen eine Reaktion zu provozieren.

120

Prozessbereiche und Prozesskategorien

• Sind Outbound-Aktivitäten definiert, erfolgt die telefonische Ansprache der Kunden wie im Prozess 621 Contact Management geregelt. • Erfolgt die Kommunikation über die firmeneigene Web Page, wird mit Content-Änderung definiert der Prozess 625 Content Management angestoßen. • Bedarfsanalyse aktualisiert; die Analysen regelmäßiger Umfragen führen dazu, dass die Bedürfnisse des Kunden ermittelt werden. Die Ergebnisse dienen als Input für die Produktentwicklung (134 Product & Service Management). • Methodenanpassung identifiziert; auch das Marketing setzt gewisse Methoden und Verfahren ein, die evtl. für das Unternehmen spezifisch sind. Aufgrund von Rückmeldungen kann es angezeigt sein, diese zu überarbeiten und anzupassen. Da es sich hier um wertvolles Know-how handeln kann, wird über Methodenanpassung identifiziert mit dem Prozess 721 Methodic Development eine Überarbeitung von Methoden und Verfahren ausgelöst. Unter einem Kundenportfolio verstehen wir sowohl eine Übersicht über die aktiven und ehemaligen Kunden als auch darüber, welche Umsätze mit diesen Kunden bei welchen Produkte in der Vergangenheit gemacht wurden. Außerdem gehören dazu der monatliche Umsatz pro Kunde für das aktuelle Geschäftsjahr und der Auftragsbestand inkl. einer Forecast auf das Jahresende. Der Prozess 132 Customer Portfolio Management erstellt das Ergebnis Kundenportfolio aktualisiert, dessen Empfänger das Management ist. Die auslösenden Ereignisse für diesen Prozess kommen vor allem aus dem Sales-Bereich: • Bestellinformationen erstellt und Abschlussinformationen erstellt sind Resultate des Prozesses 222 Contract Administration. • AE-Prognose erstellt resultiert aus dem Prozess 121 BID Management. • Die Umsatzzahlen, Umsatzmeldung erstellt, werden im Prozess 141 Service Charging ermittelt. Eine andere Sicht auf den Geschäftsverlauf ergibt das ProduktportfolioManagement. Hierbei handelt es sich um eine Übersicht aller vom ICTUnternehmen vertriebenen Services / Produkte / Leistungen, deren Preise sowie die damit erzielten Umsätze, die jeweils historisch, aktuell und als Forecast dokumentiert werden. Der Prozess 133 Product Portfolio Man-

Prozessbereich Management

121

agement erzeugt mit dem den Prozess abschließenden Ereignis Produktfolio aktualisiert diese Informationen für das Management. Der Prozess wird angestoßen durch die Ereignisse: • Bestellinformationen erstellt und Abschlussinformationen erstellt sind Resultate des Prozesses 222 Contract Administration. • Produkt eliminiert und Produkt freigegeben sind Ergebnisse des Prozesses 134 Product Service Management. • AE-Prognose erstellt resultiert aus dem 121 BID Management Prozess. • Umsatzmeldung erstellt aus dem Prozess 141 Service Charging erzeugt mit dem den Prozess abschließenden Produktfolio aktualisiert diese Informationen für das Management. Von zentraler Bedeutung ist die Thematik der Produktentwicklung, abgebildet im Prozess 134 Product & Service Management. Er behandelt drei Aspekte: Die Neu- und Weiterentwicklung von Produkten, die Anpassung des bestehenden Produktportfolios (z.B. Produkte eliminieren, Preise neu festlegen etc.) sowie die Überwachung der Produktentwicklung. Hierbei ist zu berücksichtigen, dass eine Produktentwicklung als internes Entwicklungsvorhaben abgewickelt wird, d.h. unter der Kontrolle des 12 ICT Program Management und in der Umsetzung gemäß den Prozessen des 31 ICT Project Managements. Die Produktentwicklung an sich wird angestoßen durch Ergebnisse folgender Prozesse: • 211 Sales Management: neue Leistung gefordert8, • 131 Marketing Management: Bedarfsanalyse aktualisiert, • 732 Technology Management: Trendanalyse aktualisiert, • 311 Project Planning: Realisierungsauftrag erteilt. Die Ergebnisse dieser Teilprozesse können einerseits dazu führen, dass für die Entwicklung eines Produktes ein Projekt vorgeschlagen wird, das dann via 311 Project Planning geplant und beim Programm-Management be8

Dies entspricht in ITIL einem Request for Service. In unserem Modell wird ein vom ICT-Unternehmen angebotener Service als Produkt des Unternehmens bezeichnet, welcher im Produkt bzw. Leistungskatalog der Unternehmung verwaltet wird.

122

Prozessbereiche und Prozesskategorien

antragt wird. Andererseits können externe Partner benötigt werden. Mit Partnersuchauftrag erteilt wird in diesem Fall der Prozess 111 Partner Management angestoßen. Handelt es sich bei dem neuen Produkt um ein Schulungsthema bzw. soll das neue Produkt mit einem entsprechenden Schulungsangebot begleitet werden, sind die entsprechenden Themenanforderungen definiert. Dies aktiviert den Prozess 641 Education & Training Planning. Bei der Neu- bzw. Weiterentwicklung von ICT-Produkten werden Sicherheitsanforderungen identifiziert, für die im Prozess 731 Security Management Lösungen gefunden werden. Die regelmäßige Analyse des Produktportfolios (Produktportfolio aktualisiert) führt zur Überarbeitung des Produkt- bzw. Leistungskataloges. Dies kann dazu führen, dass ein Produkt eliminiert wird und damit auch die Anforderungen an das interne Plattformangebot9 aktualisiert werden. In diesem Fall wird der Prozess 711 Contingency Planning angestoßen. Die Überwachung der Produktentwicklung wird einerseits angestoßen durch das periodisch auftretende Ereignis Projektbericht erstellt (aus 312 Project Control) oder abschließend, wenn das System freigegeben wurde (431 System Configuration). Mit der Freigabe des Produktes für den Vertrieb und für die Produktion wird die Produktion abgeschlossen. Produkt freigegeben aktiviert die Prozesse 131 Marketing Management und 133 Product Portfolio Management. Die Produktdefinition, die Produktentwicklung und die Überwachung des Produktlebenszyklus sind für ein Unternehmen lebenswichtige Funktionen. Die damit verbundenen Prozesse sind entsprechend hoch einschätzen. Besonders „interne“ Organisationen, die als IT Service Provider innerhalb einer Firma oder eines Firmenverbundes auftreten, haben hier oftmals erhebliche Defizite. Dies wirkt sich nicht nur schlecht auf das Image aus, sondern erschwert auch den Wettbewerb mit externen Anbietern.

9

Unter „Plattform“ ist hier die vom Unternehmen selbst betriebene Infrastruktur zu verstehen, die als Plattform für die angebotenen Services des Unternehmens dient. Wird nun eine bestimmte Leistung eliminiert, kann dies zur Folge haben, dass die dafür installierte ICT-Infrastruktur auch nicht mehr benötigt wird.

Prozessbereich Management

123

ICT Finance & Controlling Im Prozess-Referenzmodell für unsere ICT-Unternehmung konzentrieren wir uns auf zwei Schwerpunkte: zum einen auf die Verrechnung der vom ICT-Unternehmen erbrachten Leistungen, zum anderen auf die Prüfung und Bezahlung der von den Partnern bzw. Lieferanten gestellten Rechnungen. Mit Abschluss eines Vertrages resultiert aus dem Prozess 222 Contract Management das Ereignis Rechnungsgrundlagen erstellt. Auf dieser Grundlage werden die Vorgaben für die Rechnungsstellung im Prozess 141 Service Charging definiert. Je nach Art der erbrachten Leistung und der Zahlungsvereinbarungen (z.B. Vorauszahlung) kann so bereits die erste Rechnungsstellung ausgelöst werden. Das die Rechnungsstellung auslösende Ereignis Verrechnungsdaten zusammengestellt ist ein Ergebnis der Prozesse, die die leistungserbringenden Prozessketten abschließen bzw. begleiten: • 141 Invoicing (Verrechnung der Ansprüche an Lieferanten) • 222 Contract Management (Verrechnungen bei Vertragsbeginn, z.B. Anzahlung, bzw. bei Vertragsende, z.B. Bonus, Malus) • 223 Contract Monitoring (z.B. Verrechnung bzw. Gutschriften bei Vertragsverletzungen) • 312 Project Controlling10 (Verrechnung von Beratungs- , Entwicklungsleistungen) • 315 Project Finalisation (Verrechnung von Beratungs-, Entwicklungsleistungen) • 521 Production Control (Verrechnung von Betriebsleistungen, inkl. Produktionsmaterial wie z.B. Papier, Porto etc.) • 623 Complaint Management (Gutschriften im Fall von Beschwerden) • 632 Repair Management (Verrechnung von Ersatzteilen / Zeitaufwand im Fall von Reparatur & Service)

10

Korrekterweise werden hier alle Leistungsarten, die im Rahmen eines „Projektes“ erbracht werden wie z.B. Hard- und Software, Materialien aller Art, Spesen etc., verrechnet. Der Fokus liegt aber typischerweise auf der Verrechnung der geleisteten Arbeitszeit in Form von Zeiteinheiten oder pauschal im Rahmen von Meilensteinzahlungen.

124

Prozessbereiche und Prozesskategorien

Abb. 81. ICT Finance & Controlling

Prozessbereich Management

125

• 633 Installation & Relocation Management (Verrechnung von Hard- / Software, Zeitaufwand) • 642 Registration Handling (Verrechnung von Seminar- / Schulungsteilnahme) Früher war es noch üblich, dass der Fakturaprozess zeitgesteuert, z.B. jeweils bestimmt durch das Monatsende war. Heute ist es aus Liquiditätsüberlegungen heraus auch üblich, tatsächlich ereignisorientiert Rechnungen zu stellen. Die Fähigkeit, täglich Rechnungen stellen zu können, erscheint auf den ersten Blick simpel, aber gerade dort, wo nach Zeitaufwand verrechnet wird, kommen viele Organisationen bei dieser Anforderung an ihre Grenzen. Neben den üblichen Ergebnissen eines Verrechnungsprozesses wie Debitorenrechnungen und Mahnungen sind für unser ICT-Unternehmen die folgenden zwei Ereignisse von Bedeutung. So führt das Ergebnis Umsatzmeldung erstellt im Prozess 132 Customer Portfolio Management zum Kundenportfolio und im Prozess 133 Product Portfolio Management zum aktualisierten Produktportfolio. Wird die höchste Mahnstufe erreicht, löst dieses Ereignis den Prozess 223 Contract Monitoring aus, in dem Vertragsabweichungen bearbeitet werden. Wurde eine Kreditorenrechnung gestellt, wird der Prozess 142 Invoicing ausgelöst. Dort wird der Anspruch geprüft und im Normalfall wird die Kreditorenrechnung gezahlt. Wird als Resultat des Prozesses 112 Supplier Contract Management eine Entschädigung gefordert, z.B. in Form einer Gutschrift, führt dies im Rahmen der Prüfung des Anspruches zu der Zusammenstellung der Verrechnungsdaten (für die Gutschrift) und damit zur Auslösung der Rechnungsstellung. Für das 111 Partner Management ist das Ergebnis Kreditorenbericht erstellt ein auslösendes Ereignis. Wie bereits betont konzentrieren wir uns in der Betrachtung primär auf die Auslösung der Rechnungsstellung bzw. Zahlung. Wesentlich sind die Schnittstellen zu den Prozessen, die die Verrechnungsdaten liefern. In jedem Unternehmen nimmt die Finanzplanung eine Schlüsselstellung ein. Im Referenzmodell ist diese komplexe Thematik mit dem Prozess 143 Budgeting angedeutet. Budgetbedarf wird in den unterschiedlichsten Prozessen und Aufgaben formuliert: Das Ergebnis Budgetbedarf formuliert haben wir speziell in den Prozessen berücksichtigt, in denen die größten Volumina zu erwarten sind:

126

Prozessbereiche und Prozesskategorien

• 121 Program Planning • 151 Professional Development • 152 Human Resource Planning • 511 Production Planning • 741 Facility Management • 742 Material & Inventory Management Hierbei ist zu beachten, dass Projekt- und Entwicklungsbudgets über die Programmplanung berücksichtigt werden. Im Rahmen der periodischen Budgetüberwachung kann gegebenenfalls ein Risiko erkannt werden, welches dann in 163 Risk Management weiter verfolgt wird. Mit Abschluss des Prozesses ist die Budgetplanung aktualisiert; dieses Ergebnis richtet sich an das ICT Management. Die Erfassung, Bereitstellung und termingerechte Lieferung von Verrechnungsdaten bedingt über die gesamte ICT-Unternehmung pro Leistungsart ein einheitliches Konzept. Fallstricke in der Praxis sind vor allem dort zu finden, wo personenbezogene Leistungen, also z.B. geleistete Arbeitsstunden eines eindeutig zu identifizierenden Mitarbeiters, zu verrechnen sind. Dies ist darin begründet, dass es sich hierbei um personenbezogene Daten handelt, die auch zur Leistungsbeurteilung oder zum Leistungsvergleich verwendet werden können.

ICT Human Resource Management In dem weiten Feld des Personalwesens konzentrieren wir uns auf zwei Bereiche, die uns im Rahmen der Organisation einer ICT-Unternehmung spezifisch und damit besonders relevant erscheinen. Dies ist zum einen das ganze Thema der Aus- und Weiterbildung, da die hohe Dynamik der technologischen Entwicklung bei den Informations- und Kommunikationstechnologien eine ständige Aktualisierung des im Unternehmen vorhandenen Wissens bedingt. Zum andern ist insbesondere bei ICT-Unternehmungen, die regelmäßig und in einem großen Umfang Leistungen auf Projektbasis erbringen, die Ressourcenplanung von Bedeutung. Hier stehen vor allem die verfügbaren

Prozessbereich Management

127

Abb. 82. ICT Human Resource Management

„Skills“ (Qualifikationen) und Kapazitäten (Personentage) im Vordergrund. Der Prozess 151 Professional Development wird von dem Ereignis Ausbildungsbedarf ermittelt angestoßen. Dieses Ereignis kann ein Ergebnis der folgenden Prozesse sein: • 161 Audit & CIP; erkannte Defizite im Rahmen des Qualitäts- und Risiko Managements • 511 Production Planning; erkannter Bedarf bei der Planung zukünftiger Produktionsanforderungen, z.B. bei Einführung einer neuen Technologie • 611 Customer Services Planning; erkannter Bedarf bei der Planung zukünftiger Serviceanforderungen, z.B. bei Einführung neuer Produkte • 721 Methodic Development; erkannter Bedarf nach der Definition / Einführung neuer Methoden, Vorgehensmodelle etc. • 722 Knowledge Management; Bedarf, gezielt Wissen in der Unternehmung zu verbreiten

128

Prozessbereiche und Prozesskategorien

Die Ergebnisse des Prozesses sind vielfältig und stoßen folgende Prozesse im Unternehmen an: • Wird ein Bedarf ermittelt, der z.B. durch Zukauf externer Schulungsleistungen gedeckt werden kann, wird im Rahmen des Prozesses dieser Bedarf formuliert und damit der Prozess 114 Purchasing (Einkauf der Leistung) angestoßen. • Im Rahmen der Planung der Ausbildungsmaßnahmen wird auch der Budgetbedarf formuliert, der im Prozess 143 Budgeting behandelt wird. • Unser ICT-Unternehmen bietet selbst auch ICT-Seminare an und entwickelt diese gegebenenfalls selbst. Entsprechend werden im Prozess Themenanforderungen definiert, die im Prozess 641 Education & Training Planning zur Integration in die Seminarplanung (Thema, Ort, Termin) und gegebenenfalls auch zur Seminarentwicklung führen. • Im Rahmen der Bedarfsanalyse kann festgestellt werden, dass neue Methoden benötigt werden oder bestehende angepasst werden müssen. Sind notwendige Methodenanpassungen identifiziert, werden diese im Prozess 721 Methodic Development entwickelt. • Ebenso kann ein Ergebnis der Analyse sein, dass Wissensdefizite erkannt werden, welche in der Folge vom Prozess 722 Knowledge Management aufzubereiten sind. Ein typischer Ablauf könnte folgender sein: Im Rahmen eines Audits des Qualitäts-Managements werden Defizite in der Qualifikation der Projektleiter der Unternehmung festgestellt (Ausbildungsbedarf ermittelt). Die Analyse des erkannten Ausbildungsbedarfs und die daraus resultierenden Erkenntnisse führen zu folgenden Lösungen: 1. Jeder Projektleiter erhält ein spezifisches Fachbuch zum Thema „Projektleiter“; mit der Festlegung von Titel, Autor, Verlag, benötigter Menge, gewünschtem Zeitpunkt der Verfügbarkeit, Preisrahmen etc. ist der Bedarf formuliert, der dann im Rahmen des Einkaufsprozesses befriedigt wird. 2. Die vom Unternehmen angebotene Seminarreihe „Projektleitung“ wird für gut befunden, ist aber durch die Themen „Konflikt-Management“ und „Verhandlungstechniken“ zu ergänzen. Damit werden Themenanforderungen definiert, die im Education & Training Planning Prozess berücksichtigt werden.

Prozessbereich Management

129

3. Weiter wurde erkannt, dass bestimmte verwendete Methoden nicht mehr zeitgerecht sind. Durch Methodenanpassung identifiziert wird die Korrektur dieses Defizits veranlasst. Die Sicherstellung der Aus- und Weiterbildung von Mitarbeitern ist eine kostenintensive Aufgabe. Umso unverständlicher ist es, dass in der Praxis oftmals keine systematische Ausbildungs- und Entwicklungsplanung erfolgt. Die Fähigkeit des optimalen Managements der Personalressourcen hinsichtlich der verfügbaren Skills (Qualifikationen) und Kapazitäten ist bei einem ICT-Unternehmen von höchster betriebswirtschaftlicher Bedeutung. Die Personalkosten machen bei einer ICT-Unternehmung bis zu 80% der Gesamtkosten aus. Wie erfolgreich diese Produktionsressourcen eingesetzt und ausgelastet werden, ist entscheidend für den wirtschaftlichen Erfolg einer ICT-Unternehmung. Der Prozess 152 Human Resource Planning, der die Ressourcenzuordnung sowie die Auslastung plant, wird durch vier Ereignisse angestoßen: 1. Durch das Ereignis Kapazitäts- und Skillbedarf erstellt, resultierend aus den Prozessen • 121 Program Planning: Hier werden die für die projektorientierten Leistungsarten benötigten Personalressourcen ermittelt und geplant. • 511 Production Planning: Hier werden die für die Leistungsart „Betrieb“ benötigten Ressourcen geplant. • 631 On Site Dispatching: Das On Site Dispatching plant die Ressourcen für die Erbringung von Kundenservices vor Ort. • 722 Knowledge Management: Dieser Prozess meldet einen zu erwartenden zukünftigen Bedarf von bestimmten Qualifikationen bzw. Bedarf an spezifischem, externen Wissen. 2. Durch das Ereignis Trainerbedarf ermittelt als Resultat des Prozesses 641 Education & Training Planning; beim Trainer handelt es sich um einen spezifischen Skillbedarf. Aufgrund der Besonderheit der Leistungsart „Ausbildung- / Seminargeschäft“ und der Integration der damit verbundenen Prozesse haben wir diese im Modell mit einem eigenen Ereignis versehen.

130

Prozessbereiche und Prozesskategorien

3. Durch das Ereignis Ressourcen alloziiert, welches zum einen ein Ergebnis des Prozesses 122 Approval Procedure ist, zum anderen aus dem Prozess 641 Education & Training Planning resultiert; in diesen Prozessen werden primär die Ressourcen für die projektorientierten Leistungsarten geplant. 4. Durch das Ereignis Einsatzplan erstellt, resultierend aus den Prozessen 511 Production Planning und 631 On Site Dispatching, in denen primär die Einsatzplanung der Ressourcen für die betrieblichen Tätigkeiten erfolgt. Der Prozess 152 Human Resource Planning endet mit vier Ergebnissen: • Mit dem Prozessende ist die Auslastungsplanung aktualisiert. Dieses Ereignis aktiviert keinen weiteren Prozess. Das Ergebnis steht z.B. in Form einer entsprechenden Auswertung oder in einer Datenbank als möglicher Input für Aufgaben anderer Prozesse zur Verfügung. • Bei vorgesehenem Zukauf externer Ressourcen wird der Bedarf ermittelt und damit in der Folge der Einkaufsprozess (114 Purchasing) angestoßen. • Ebenso wird für die Personalressourcen der Budgetbedarf formuliert, der im Prozess 143 Budgeting behandelt wird. • Mit Abschluss des Prozesses ist weiter der zukünftige Personalbedarf definiert. Die optimale Auslastung der Personalressourcen ist vor allem bei Unternehmen, deren Umsätze von einem hohen Anteil projektorientierter Leistungsarten bestimmt werden, von höchster betriebswirtschaftlicher Bedeutung. Es handelt sich dabei um einen der kritischen Erfolgsfaktoren, betreffend der Wettbewerbsfähigkeit einer ICT-Unternehmung.

ICT Quality & Risk Management Die Prozesskategorie 16 ICT Quality & Risk Management umfasst die letzte größere Prozessgruppe des Bereiches Management. Sie unterteilt sich in die Hauptprozesse: • 161 Audit & CIP (Continuous Improvement Prozess) • 162 QM-System

Prozessbereich Management

Abb. 83. ICT Quality & Risk Management

131

132

Prozessbereiche und Prozesskategorien

• 163 Risk Management • 164 Process Management In der Praxis werden diese Prozesse, da nicht operativ und nicht wertschöpfend, gerne stiefmütterlich behandelt. Aber ein Blick auf die obige Abbildung zeigt, wie stark diese Prozesse in das gesamte Prozessnetzwerk einer ICT-Unternehmung eingebunden sind. Die Durchführung von regelmäßigen Audits11 ist ein klassisches Instrument, um Schwachstellen in der Organisation aufzudecken, diese in der Folge zu analysieren und Verbesserungsvorschläge daraus abzuleiten. Der Prozess 161 Audit & CIP deckt diese Aufgaben ab. Die Durchführung von Audits kann periodisch oder bedarfsorientiert angestoßen werden. Wir haben uns in unserem Modell auf zwei typische, bedarfsorientierte Auditauslöser beschränkt: • Als Resultat des Prozesses 731 Security Management stößt das Ereignis Security-Audit beantragt den Auditprozess an. • Das Gleiche gilt für den Fall, dass ein Q-Audit beantragt wird. Der Antrag auf einen Q-Audit kann aus den folgenden Prozessen gestellt werden: o 162 QM-System o 312 Project Control o 315 Project Finalisation o 412 Change Planning and Control o 432 CI Verification Wie unschwer festzustellen ist, haben wir, bezogen auf die Abläufe, drei Bereiche, die in jedem ICT-Unternehmen zu den dynamischsten und damit auch zu denen mit den größten Fehlerquellen und den häufigsten Qualitätsmängeln zählen. Es handelt sich dabei um das Projektgeschäft als solches und die komplexen Disziplinen des Change- und Configuration Managements. Nach dem Audit werden der Auditbericht erstellt und gegebenenfalls Verbesserungen vorgeschlagen. Verbesserungsvorschläge können weiter aus den folgenden Prozessen resultieren: 11

Als Audit (von lat. „Anhörung“) werden allgemein Untersuchungsverfahren bezeichnet, die dazu dienen, Prozessabläufe hinsichtlich der Erfüllung von Anforderungen und Richtlinien zu bewerten.

Prozessbereich Management

133

• 113 Supply Chain Management • 315 Project Finalisation • 432 CI Verification • 512 Availaibility Management • 513 Capacity & Performance Management • 623 Complaint Management Alle diese Prozesse beinhalten Analysetätigkeiten, deren Ergebnisse dazu führen können, dass Verbesserungsmaßnahmen benötigt und vorgeschlagen werden. Die Ergebnisse des Continuous Improvement Prozesses sind: • Verbesserungspotenzial identifiziert, welches außerhalb der ICTUnternehmung z.B. bei einem Lieferanten, Hersteller oder auch Kunden zu Veränderungen führen soll, die dem Unternehmen nützen. • Methodenanpassung identifiziert; in diesem Fall sind Methoden, Verfahren etc., die im ICT-Unternehmen verwendet werden, im Prozess 721 Methodic Development anzupassen. • Ausbildungsbedarf ermittelt; übrigens ein häufiger Verbesserungsvorschlag in ICT-Unternehmungen, in denen die Weiterbildung der Mitarbeiter zu dem Entwicklungstempo der eingesetzten Technologien einen zu großen Abstand hat. In diesem Fall wird der 151 Professional Development Prozess angestoßen. • RFC formuliert; eine Veränderung, die über das Change Management und hier konkret über den Prozess 411 Change Handling abzuwickeln ist. (Typisch z.B. wenn Veränderungen in der Infrastruktur oder auf Applikationsebene angestrebt werden). • Partner-Audit notwendig; manche Vorschläge führen indirekt dazu, dass Mängel bei Partnern vermutet werden, die gegebenenfalls über einen entsprechenden Audit, wie er im Prozess 111 Partner Management beschrieben ist, identifiziert werden können. • Partner Risiko erkannt; nimmt die Umsetzung eines Verbesserungsvorschlages Einfluss auf die Zusammenarbeit oder auf die Produkte eines Partners, können hier Risiken entstehen. Diese werden dann im Prozess 112 Supplier Contract Management, z.B. durch Nachbesserung der bestehenden Verträge, bearbeitet. • Wissensdefizite erkannt; in diesem Fall wird das fehlende Know-how über den Prozess 722 Knowledge Management aufbereitet.

134

Prozessbereiche und Prozesskategorien

Die Implementation eines kontinuierlichen Verbesserungsund auch Innovationsprozesses ist ein hohes Ziel, an welchem vor allem ICT-Unternehmen oft scheitern. Gerade die unendliche Zahl von Kombinationen von sich ständig wandelnden technischen Konzepten bietet eine genauso hohe Zahl von Innovationen und Verbesserungen. In der Praxis fehlt scheinbar oft die Zeit, in Tat und Wahrheit aber das System, die Disziplin und die Bereitschaft zur Vorinvestition. Das Qualitäts- und das Prozess-Management, obwohl klassische Dauerthemen, haben in den letzten zwei Jahren wieder an Bedeutung gewonnen. Ausschlaggebend sind hierfür drei Entwicklungen: • Mit dem British Standard 15000 / ISO 20000 existiert seit 2005 ein spezifischer Standard, um ICT-Organisationen bzgl. vorgegebener Qualitätsstandards zu zertifizieren. Da dieser Standard sich an den ITIL Best Practices orientiert, wird er der derzeitigen ITIL-Ausbreitungswelle folgen. • Der Sarbanes-Oxley Act of 2002 (SOX, auch SOA) ist ein US-Gesetz zur Verbesserung der Unternehmensberichterstattung in Folge der Bilanzskandale. Dies nimmt gerade bei größeren international ausgerichteten ICT-Unternehmungen Einfluss auf die in diesem Kapitel diskutierten Prozesse. • Ausbreitung des ITIL-Best-Practises-Konzeptes, welches sich zunehmend als De-facto-Standard für die Definition eines IT Service Managements durchsetzt. Neben den bereits beschriebenen Audit-Tätigkeiten sowie der Sicherstellung eines kontinuierlichen Verbesserungsprozesses gibt es im Umfeld eines Qualitäts-Managementsystems die Aufgabe, das Qualitäts-Managementsystem und die Qualitätsvorgaben ständig weiterzuentwickeln. Hierzu gehört auch die regelmäßige Überprüfung der Einhaltung dieser Vorgaben. Die Weiterentwicklung eines QM-Systems ist eine permanente Aufgabe. In der Praxis erfolgt eine periodische Überprüfung des QM-Systems. So wird der Prozess 162 QM-System zu regelmäßigen Zeiten angestoßen. Soweit es sich um die Weiterentwicklung des QM-Systems handelt, resultieren daraus zwei Ergebnisse:

Prozessbereich Management

135

• Wurde eine notwendige Prozessänderung identifiziert, wird der Prozess 164 Prozess Management angestoßen. • In etablierten QM-Systemen fällt der Großteil von Änderungen auf die einzelnen Abläufe. Die Anpassung der Qualitätsziele ist ein weiterer Schwerpunkt. Das Ergebnis Q-Ziele definiert nimmt Einfluss auf Tätigkeiten in den Prozessen 511 Production Planning und 611 Customer Services Planning, in denen vor allem betriebliche Aufgaben und Vorgaben geplant werden. An dieser Stelle muss die Frage nach den Qualitätsvorgaben für projektorientierte Leistungsarten diskutiert werden. Im Gegensatz zu den projektorientierten Leistungsarten sind betriebliche Aufgaben relativ statisch, d.h. es handelt sich in der Regel um mehr oder weniger gleiche, sich wiederholende Aufgaben mit den gleichen Ergebnissen. Sind die Qualitätsziele hierfür einmal definiert, unterliegen sie einem nur geringen Veränderungsdruck. Bei projektorientierten Leistungsarten gibt es zwei Gruppen von Qualitätszielen: • Die erste Gruppe beinhaltet die Qualitätsziele, die festlegen, wie ein Projekt, methodisch gesehen, abzuwickeln ist. Diese können, da auch eher statischer Natur, in einem Qualitäts-Managementsystem oder in den Methoden-, Verfahrensanweisungen der Unternehmungen festgelegt werden. • Die zweite Gruppe bezieht sich auf die Qualitätsziele, die die Qualität der Leistung bzw. des Produktes beschreiben, welche durch das Projekt zu erbringen sind. Die Planung der Qualitätsziele für projektorientierte Leistungsarten erfolgt entsprechend im Prozess 311 Project Planning. Die Überprüfung der Einhaltung der Qualitätsvorgaben wird ausgelöst durch die Ereignisse • Seminar beurteilt, aus 643 Education Processing • Projektbericht erstellt, aus 312 Project Control • Produktionsbericht erstellt, resultierend aus den Prozessen o 512 Availability Management o 513 Capacity & Performance Management o 521 Production Control o 612 Customer Services Monitoring

136

Prozessbereiche und Prozesskategorien

Wird im Rahmen des Prozesses 111 Partner Management ein Partner beurteilt, aktiviert dieses Ergebnis auch Aufgaben im Qualitäts-Management und kann zu dem Ergebnis führen, dass ein Partner-Audit notwendig wird. Qualitäts-Managementsysteme sind heute Standard. Bei ICTUnternehmen sind sie aber leider oftmals eher isoliert und nicht in den produktiven Betrieb integriert. Dies ist nur zu verhindern, indem die klassischen Tätigkeiten des QualitätsManagements wie das Prüfen, Messen und Kontrollieren sehr aktiv betrieben werden. Das Risk Management kann in ICT-Unternehmungen einen sehr hohen Stellenwert einnehmen. Dies gilt vor allem für ICT-Unternehmen, die • Komplette Systemlösungen auf Werkvertragsbasis liefern, • Einen hohen Anteil von Zulieferern haben, bzw. Garantien auch für outgesourcte Leistungen erbringen, • Für ihre Endkunden hochkritische Applikationen betreiben, deren Ausfall schnell zu Verlusten bzw. erheblichen Nachteilen auf der Kundenseite führen können. Hier sind vor allem die Haftungs- und Gewährleistungsrisiken von Bedeutung. Im Fall von projektorientierten Leistungsarten kommen oftmals auch Vertragsstrafen zum Einsatz. Beliebt sind besonders bei auf Termin zu liefernden Hard- und / oder Software-Systemen die so genannten Pönale.12 Der Prozess 163 Risk Management wird durch drei Ereignisse ausgelöst: • Periodisch sind die bekannten Risiken bzgl. ihres Status zu überwachen • Sicherheitsreport erstellt als Resultat des Prozesses 731 Security Management

12

Pönale (im Englischen penalty): pauschalierter Schadensersatz. Wird vor allem dann verwendet, wenn die genaue Einhaltung des Vertrages (z.B. Termine, Mengen etc.) für den Auftraggeber sehr wichtig ist. Bei einer Pönale muss der Auftraggeber keinen Schaden nachweisen, der Anspruch entsteht, wenn die vertragliche Vereinbarung nicht eingehalten wird.

Prozessbereich Management

137

• Risiko erkannt; generell sind dies alle Arten von Risiken, die in den unterschiedlichsten Prozessen, Aufgaben und Tätigkeiten innerhalb der ICT-Unternehmung erkannt werden. Innerhalb unseres Modells haben wir die folgenden Prozesse, die eine Prüfung auf Risiken beinhalten müssen, identifiziert: o 123 Program Control o 143 Budgeting o 223 Contract Monitoring o 313 Project Risk Management o 711 Contingency Planning o 713 Contingency Testing o 731 Security Management Im Referenzmodell ist nicht dargestellt, wie auf der Entscheidungsebene mit den erkannten Risiken verfahren wird. Organisatorisch gesehen ist es üblich, dass die Ereignisse einer Risikoanalyse inkl. Hintergrundmaterial, voraussichtlichen Konsequenzen bei Eintritt eines Risikos, Eintrittswahrscheinlichkeit etc. sowie Entscheidungsempfehlungen einem Entscheidungsgremium auf Managementebene, z.B. der Geschäftsleitung, vorgelegt werden, das dann das weitere Vorgehen beschließt. Wird ein Partnerrisiko erkannt, erfolgt dessen primäre Bearbeitung in der Folge im Prozess 112 Supplier Contract Management. Wird eine Risikoanalyse erstellt bzw. aktualisiert, werden die Prozesse, die unter anderem die Aufgabe haben, Maßnahmen zur Risikovermeidung bzw. -beseitigung zu treffen, angestoßen. In unserem Modell sind dies: • 123 Program Control; Einfluss auf Risiken über Veränderung der Steuerungsvorgaben • 313 Project Risk Management; konkrete Planung und Definition von Maßnahmen im Projektumfeld • 731 Security Management; konkrete Planung und Definition von Maßnahmen Ist ein Partner-Audit notwendig, wird in der Folge der Prozess 111 Partner Management aktiviert.

138

Prozessbereiche und Prozesskategorien

Beim Risiko-Management in ICT-Unternehmen steht immer ein Punkt im Vordergrund: finanzielle Risiken vermeiden. Vor allem die Risiken, die die produktiven Tätigkeiten begleiten, müssen im Auge behalten werden. Brennt einmal ein Rechenzentrum ab, ist zwar die Aufregung groß, i.d.R. funktioniert aber das Back-Up-Rechenzentrum und die Versicherung zahlt. Werden aber Produkte fehlerhaft oder nicht termingerecht ausgeliefert, kommt es zu Garantie- und Folgekosten sowie zu Imageschäden, die keine Versicherung abdeckt. Der letzte Hauptprozess des Kapitels ICT & Quality Management ist der Prozess 164 Process Management, der durch das Ereignis Prozessänderung identifiziert angestoßen wird. Dieses Ereignis ist jeweils ein Resultat von Aufgaben innerhalb der Prozesse: • 113 Supply Chain Management • 162 QM System • 411 Change Handling • 511 Production Planning • 611 Customer Services Planning Wir beschränken uns hierbei bewusst auf die Gestaltung der Prozesse. Sind diese zu implementieren, wird ein RFC formuliert, mit dem dann über das Change Management (411 Change Handling) das entsprechende Umsetzungsprojekt beantragt wird. Prozessvorgaben, die sich hauptsächlich auf Regeln, Zeiten, aktualisierte Arbeitsabläufe etc. für betriebliche Abläufe konzentrieren, müssen nicht zwingend in Form eines Projektes implementiert werden, sondern können als Standard Change behandelt werden. Sind die Prozessvorgaben erstellt, sind diese in den Prozessen 113 Supply Chain Management, 511 Production Planning und 611 Customer Services Planning zu berücksichtigen. Das Thema „Prozess-Management“ füllt einige Regale in der betriebswirtschaftlichen Bibliothek. Dies ist nicht nur ein Zeichen für dessen Bedeutung, sondern auch ein Hinweis auf die Komplexität, die damit verbunden ist. Wer Prozesse managen und gestalten will / darf / muss, tut gut daran, wenn er neben der Theorie vor allem die Zusammenhänge der gelebten Prozesse des eigenen Unternehmens kennt und diese als ein sich gegenseitig beeinflussendes Netzwerk begreift.

Prozessbereich Sales

139

Prozessbereich Sales Die Lebensader13 eines Unternehmens stellt die Verkaufsschnittstelle zum Kunden dar. Klassifiziert man die Kunden einer ICT-Unternehmung nach einem einfachen Schema, können folgende Kundenklassen unterschieden werden: 1. Der Markt mit den potenziellen Kunden, die für das Unternehmen weitestgehend anonym sind und die durch Werbe- bzw. PRMaßnahmen (ICT Marketing) angesprochen werden. 2. Kunden im Sinne von potenziellen bzw. aktiven oder ehemaligen Vertragspartnern; die Vertragspartner sind als Personen und / oder Organisationseinheiten bekannt. Hier erfolgt die Ansprache und Betreuung hauptsächlich durch den Vertrieb (Sales). 3. Kunden als Konsumenten oder Nutzer der Leistungen der ICTUnternehmung. Hierbei ist der Hinweis wichtig, dass Vertragspartner und Leistungsbezieher bzw. Nutzer nicht identisch sein müssen. Bei Privatpersonen als Kunden sind diese in der Regel auch gleichzeitig die Leistungsbezieher. Bei Firmenkunden sind die Mitarbeiter der Firma „Kunden im Sinne von Leistungsbeziehern“. Die Mitarbeiter14 haben wenig bis gar keinen Einfluss auf die Verträge. Im Rahmen des Leistungsbezugs, z.B. bei Supportbedarf, werden diese vom Customer Services betreut oder im Fall einer Projektabwicklung i.d.R. durch das Projektteam. Diese Unterscheidung ist auch in der Praxis relevant, da gerade im Firmenkundengeschäft auf den ersten Blick scheinbar kuriose Kombinationen in Sachen Kundenzufriedenheit auftreten können, die sich auch unmittelbar im ICT-Unternehmen auswirken: • Ziel jeder ICT-Unternehmung ist sicherlich folgende unbedenkliche Kombination: Die Kundenzufriedenheit ist sowohl beim Leistungsbezieher als auch beim Vertragspartner hoch. • Die Kombination eines zufriedenen Leistungsbeziehers und eines unzufriedenen Vertragspartners, ausgedrückt z.B. durch guten Service 13

Der Begriff „Lebensader“ wird hier verwendet, da hierüber die für das Betreiben der Unternehmen notwendige Ressource, nämlich Kapital, in das Unternehmen gebracht wird.

14

In diesem Fall sind End-User und End-Anwender häufig verwendete Synonyme.

140

Prozessbereiche und Prozesskategorien

einerseits, zu hohe Kosten andererseits, kann innerhalb der ICTUnternehmung durchaus zu Missverständnissen führen. Meldet z.B. der Sales-Bereich: „Kunde ist unzufrieden“ und der Bereich Customer Services: „unsere Kunden sind hochzufrieden“, kann dies intern zu Missverständnissen15 führen. Ein möglicher Versuch des SalesBereiches, aufgrund des hohen Zufriedenheitsgrades der Leistungsbezieher in der Folge bessere Vertragskonditionen zu erzielen, ist in diesem Fall dann eher schwierig. • Ein unzufriedener Leistungsbezieher und ein zufriedener Vertragspartner sind keine seltene Kombination. Ein Beispiel aus der täglichen Praxis: Die Leistungsbezieher melden: „Call Center in Asien verstehen unsere Arbeitsmentalität nicht, Support umständlich und unbrauchbar“, der Vertragspartner hält dagegen: „Unsere Kostenvorgaben werden voll eingehalten“. In diesem Fall fordert der CustomerServices-Bereich vielleicht mehr Ressourcen, um die unzufriedenen Leistungsbezieher zu besänftigen, mehr Ressourcen heißt aber im Endeffekt höhere Preise. Der Verkauf ist die letzte Funktion der betrieblichen Wertschöpfungskette und erfolgt klassisch nach der Produktion des Produktes. Dies trifft für ein ICT-Unternehmen nur bedingt zu. Vor allem, wenn Systementwicklungen oder zukünftig zu erbringende Dienstleitungen verkauft werden, beginnt die eigentliche Wertschöpfung mit dem Verkauf. Diese Verlagerung auf den Beginn der Wertschöpfungskette verändert natürlich auch die Anforderungen an die Vertriebsorganisation und die Mitarbeiter des Vertriebes. Gerade bei ICT-Unternehmungen erfolgt der Verkauf von Lösungen, die oftmals nicht vielmehr als eine Lösungsidee bzw. ein Lösungskonzept sind. Das Ziel des Verkaufes ist die Gewinnung von Neukunden, der Ausbau von aktiven (Stammkunden) und die Rückgewinnung von verlorenen Kunden. Dies jeweils unter den Prämissen, die eigenen Marktanteile, i.d.R. gemessen am Umsatz, auszubauen und die bestmögliche Gewinnspanne zu erzielen. Gerade bei ICT-Unternehmen, die oftmals zukünftig zu erbrin15

Anlässlich einer Betriebsversammlung des Help Desks wird die Kundenzufriedenheitsumfrage präsentiert. Der Servicebereich erhält Bestnoten. Anschließend präsentiert das Management die Kernaussage, dass ein Großteil der Kunden unzufrieden ist, da die Leistungen zu teuer sind. Nicht jeder Mitarbeiter versteht in diesem Fall die Zusammenhänge (Vertragspartner / Leistungsbezieher) auf der Kundenseite.

Prozessbereich Sales

141

gende Leistungen verkaufen, können hier ganz erhebliche Differenzen bzgl. Leistungsumfang, -inhalten, Kalkulation und Aufwand (Budget) zwischen Sales und der Produktion aufkommen. Dieses Spannungsfeld ist aus der Prozesssicht, die das Ineinandergreifen der Abläufe veranschaulicht, nicht zu erkennen. Aufgrund der Bedeutung16 soll dieses Thema hier aber nicht unerwähnt bleiben, auch wenn es in der Folge nicht weiter vertieft wird. Der Mitarbeiter einer ICT-Unternehmung sollte sich immer bewusst sein, dass er bei einer Firmenkundenbeziehung immer zwei Kundengruppen begegnet: dem Auftraggeber bzw. Vertragspartner (z.B. Management des Kunden) und dem Leistungsbezieher (z.B. Mitarbeiter des Kunden). Deren Zielsetzung und Zufriedenheitskriterien müssen dabei nicht immer deckungsgleich sein. Der Prozessbereich Sales beinhaltet die aus der Sicht der ICT-Unternehmung wichtigsten Schnittstellen zum Kunden. Wir konzentrieren uns im Modell auf folgende zwei Prozesskategorien: • Die Kundengewinnung (21 ICT Sales Planning & Execution Management), die die Prozesse von der Kundenansprache bzw. Kundenanfrage bis zum Vertragsabschluss umfasst, • Das Vertrags-Management (22 ICT Customer Contract Management), welches vor allem die Schnittstelle zu der Produktion (interne Auftragserteilung / Produktionsfreigabe) sowie die Überwachung der Vertragserfüllung beinhaltet. ITIL behandelt einen Teil dieser Thematik unter der Funktion Service Level Management. Das Konzept des Service Level Managements deckt die Prozesse zur Planung, zur Koordination, zum Entwurf, zum Abschluss der Vereinbarung, zur Vertrags-Überwachung und zum dazugehörigen Berichtswesen, den von der Organisation mit ihren Kunden abgeschlossenen Service Level Agreements (SLA), ab. Das SLA übernimmt hierbei die Funktion des Vertrags (Agreement). Hierzu gehören auch die aus einem 16

In der Tat finden sich in der Unternehmenspraxis hier eine Reihe von Fallstricken, die vorwiegend auf die Kommunikation und Zusammenarbeit von Menschen verschiedener Profession (Ingenieur vs. Verkäufer) zurückzuführen sind.

142

Prozessbereiche und Prozesskategorien

Abb. 84. Prozessbereich Sales

Service Level Agreement abzuleitenden Operational Level Agreements (OLA), die die Produktionsaufträge im eigentlichen Sinne darstellen. In unserem Modell decken die Prozesse im Sales die Anforderungen des Service Level Managements gemäß und analog ITIL ab. Wir fokussieren dabei bewusst auf die klassischen Aspekte einer Verkaufsorganisation, da es sich bei dem Aufbau eines Service Level Managements17 schlussendlich um nichts anderes handelt als darum, Dienstleistungen anzubieten, zu verkaufen, zu vereinbaren und die Vertragserfüllung zu überwachen. Insbesondere interne ITC-Organisationen sind bei Aufbau und Einführung eines Service Level Managements immer wieder überrascht, dass hier zwei klassische Funktionen des Marketings, nämlich der Verkauf einerseits sowie das Produkt-Management andererseits einen dominierenden Einfluss nehmen.

17

Die ITIL-Literatur liefert hierzu vertiefte Informationen wie z.B. die Struktur eines Muster-SLAs, Aufbau eines Service-Kataloges oder Aufgaben der Rollen eines Service Level Managers.

Prozessbereich Sales

143

ICT Sales Planning & Execution Management Die Prozesskategorie ICT Sales Planning & Execution Management umfasst die drei Hauptprozesse: • 211 Sales Management; hier wird die direkte Kundenansprache geplant, durchgeführt und in der Folge auf die Anfragen der Kunden reagiert.

Abb. 85. ICT Sales Planning & Execution Management

144

Prozessbereiche und Prozesskategorien

• 212 Bid Management umfasst die Angebotserstellung bis zur Vertragsvorlage für die Leistungen, die einen hohen Anteil an individuellen Anpassungen (spezifische Kundenlösung) haben. • 213 Order Management; über diesen Prozess werden alle Bestellungen von Leistungen abgewickelt, die ohne spezielle individuelle Anpassungen erbracht werden (z.B. Handelsware wie PC-Software, Hardware, Ersatzteile, Verbrauchsgüter etc. oder die Buchung von öffentlichen Seminaren, welche als Standardlösung verkauft werden). Die Auslöser des Prozesses 211 Sales Management bzw. einzelner Aufgaben davon können in vier Gruppen unterteilt werden: 1. Periodisch (z.B. monatlich) erfolgt die Planung des Vertriebsvorgehens mit der Zielsetzung, bestehende, ehemalige und potenzielle Kunden regelmäßig zu kontaktieren. Mit Abschluss des Prozesses wurde mit dem Kunden Kontakt aufgenommen oder für die geplante Kontaktaufnahme eine Pendenz18 erstellt. 2. Der Kunde hat eine Leistungsanfrage formuliert. Dieses kann das Ergebnis eines direkten Kontaktes zwischen der Verkaufsorganisation und dem Kunden sein oder es handelt sich um einen Kundenkontakt, der über den Prozess 621 Contact Management erfolgte. In diesem Fall wird die Anfrage in einem ersten Schritt analysiert und führt zu drei Ergebnissen: o Die Leistung kann durch das Unternehmen nicht erbracht werden. Handelt es sich um eine Leistung, die das Unternehmen erbringen sollte (z.B. auf der Basis einer neuen Technologie), wird von den Kunden eine Neue Leistung gefordert, die die Produktentwicklung (134 Product & Service Management) interessiert. (Eine potenzielle und denkbare Absage ist im Modell nicht dargestellt.) o Bei der Leistung handelt es sich um eine Standard-Leistung, die über den Prozess 213 Order Management abgewickelt werden kann. In der Folge wird für den Kunden die Bestellanfrage formuliert oder, wenn die gewünschte Leistung eindeutig ist, das Produkt bestellt. Hat der Kunde Kontakt auf der Basis einer bestehenden Bestellung aufgenommen, kann in der Folge die Bestellung geändert bzw. die Bestellung gekündigt werden. Die weitere Bearbeitung erfolgt dann gemäß dem Prozess 213 Order Management. 18

Pendenz ist ein im Schweizer Sprachgebrauch verwendeter Begriff für eine terminierte, noch zu erledigende Aufgabe.

Prozessbereich Sales

145

o Handelt es sich um eine Leistung, die eine individuelle Lösungskonzeption benötigt, wird eine entsprechende Angebotsanfrage formuliert. In der Praxis sind hierzu oftmals mehrere Gespräche mit dem Kunden notwendig, um alle benötigen Informationen zu erheben. Ist die Angebotsanfrage formuliert, löst dies das 212 Bid Management aus. 3. Rückmeldungen aus dem laufenden Geschäft können dazu führen, dass in der Folge Vertriebsaktivitäten notwendig sind. In unserem Referenzmodell haben wir drei Ereignisse berücksichtigt, die dazu führen, dass die daraus resultierenden Konsequenzen zu prüfen sind und das adäquate Vertriebsvorgehen zu planen ist: o Vertragsabweichung identifiziert als Ergebnis des 223 Contract Managements; erkannte Vertragsabweichungen, insbesondere wenn Leistungen nicht so erbracht werden wie vereinbart, sind vom Vertrieb aktiv im Rahmen der Kundenbetreuung zu bearbeiten. Dies kann je nach Situation auch zur Beendigung bestehender und zur Vereinbarung neuer Verträge führen. o Releaseplanung aktualisiert; ein Ergebnis des Prozesses 331 Release Planning löst im Vertriebsprozess, abhängig von der Art des neuen Release, die Aufgaben zur Vertriebsplanung aus. Zielsetzung könnte hier z.B. sein, Kunden, die bereits ein Release im Einsatz haben, das neue Release zu verkaufen. o Reklamation eskaliert; ein Ergebnis von 623 Complaint Management. Reklamationen sollten dem Vertrieb nicht nur bekannt sein, sondern dort auch entsprechende Vertriebsaktivitäten auslösen. Im Verkauf gilt, dass jede Reklamation auch eine Chance ist. So unangenehm eine Beschwerde auch sein mag, sie bietet dem Verkäufer immer eine Reihe vertrieblicher Möglichkeiten. 4. Primäres Werkzeug des Vertriebs ist die Kunden- bzw. Kontaktdatenbank. Neben der Dokumentation der eigenen Aktivitäten bei einem Kunden, der Überwachung und Planung der Kontaktarbeit und -frequenz sollte der Vertrieb auch über aktuelle Abschlüsse und Bestellungen, die ein Kunde getätigt hat, informiert sein. Hierzu gehört auch das jeweilige Produkt- und Kundenportfolio (132 Customer Portfolio Management und 133 Product Portfolio Management) Diese typischerweise in einem so genannten CRM-System19 verwalteten In-

19

Customer Relationship Management.

146

Prozessbereiche und Prozesskategorien

formationen müssen vom Vertrieb aktiv bearbeitet werden. In unserem Modell haben wir diese mit den folgenden Ereignissen abgebildet: o Wiedervorlage erstellt; ein Ergebnis des Prozesses 621 Contact Management, hiermit kann z.B. eine Kontaktaufnahme mit dem Kunden und / oder eine Überwachungsaufgabe (z.B. Verfolgung einer Bestellabwicklung) initialisiert werden. o Bestellinformationen erstellt und Abschlussinformationen erstellt sind mögliche Resultate des Prozesses 222 Contract Management und stoßen die Aufgabe Kundendaten aktualisieren an. Der Vertrieb ist hochgradig erfolgsorientiert ausgerichtet. Im Vordergrund steht der Abschluss. Die folgende Leistungserbringung wird vom Vertrieb nicht übermäßig beachtet. Hier liegt ein klassischer Konfliktherd zwischen Vertrieb und Produktion. Merkmale hierfür sind so geflügelte Worte wie: Wir könnten mehr verkaufen, wenn ihr das, was der Kunde wünscht, produzieren würdet – und auf der anderen Seite: Wir könnten die Kundenwünsche optimal erfüllen, wenn ihr das verkaufen würdet, was wir produzieren. Im 212 Bid Management wird die Entwicklung bzw. Erstellung von Angeboten20 behandelt, welche die Vereinbarungen von Leistungen betreffen, die in einem hohen Maße individuell an den jeweiligen Kunden angepasst werden müssen. Beispiele für solche spezifische Kundenlösungen sind die folgenden drei Fälle: • Individuelle Lösungen (z.B. Gutachten, Beratungs- und Entwicklungsvorhaben, Übernahme von betrieblichen Tätigkeiten etc.) • Anpassungen von Standardleistungen (z.B. spezielle Anpassungen für Großabnehmer bzgl. Preis, Ausstattung, Lieferfristen etc.) • Abschluss von Rahmenverträgen für den generellen Bezug von Leistungen 20

Unter einem Angebot versteht man gemäß § 145 BGB die Willenserklärung des Anbietenden, welche einem anderen den Abschluss eines Vertrages in der Weise anträgt, dass das Zustandekommen des Vertrages nur noch von dessen Annahme abhängig ist. Im einfachsten Fall wird das Angebot durch Gegenzeichnung durch den Käufer zum Vertrag.

Prozessbereich Sales

147

Die Besonderheit im Angebots-Management ist die Koordination der drei Funktionsbereiche Verkauf, Produktion und Vertrags-Management. Insbesondere die Erstellung von größeren Angeboten (z.B. Ablösung einer bestehenden Software-Lösung durch ein anderes Produkt, deren individuelle Anpassung inkl. der Bereitstellung der dafür notwendigen technischen Infrastruktur und der anschließende Betrieb der implementierten Lösung) kann schnell einen nicht zu unterschätzenden Zeit- und Ressourcenaufwand nach sich ziehen. Aus diesem Grunde werden bei professionellen Anbietern oftmals regelrechte Angebotsprojekte mit entsprechenden Projektteams definiert. Die Erstellung der Angebote erfolgt dann unter der Koordination einer Angebots-Projektleitung und nach den Regeln des Projekt-Managements. Die optimale Gestaltung des Angebotserstellungsprozesses kann sich zu einem eindeutigen Wettbewerbsvorteil entwickeln, insbesondere dann, wenn es gelingt, die drei Rahmenbedingungen • in der Regel knappe Zeitvorgaben, • hohe Qualität der fachlichen Inhalte des Angebotes und • umfangreiche Risikominimierung optimal in Einklang zueinander zu bringen. Insbesondere im Bereich der individuellen Software-Entwicklung gelingt es vielen ICT-Unternehmen nicht, die (eigenen) Risiken, die typisch für Entwicklungsvorhaben sind, umfassend abzuschätzen und ausreichend abzusichern. Der Angebotserstellungsprozess teilt sich vereinfacht in drei Abschnitte: • Vorneweg erfolgt die Analyse, aus der sich die Aufträge an die Produktions-(Spezialisten) ergeben, die die fachlichen Inhalte und Lösungen entwickeln müssen. • Liegen die fachlichen Inhalte vor, muss das Angebot vertrags-21 und verkaufstechnisch22 strukturiert werden und die Risiken ermittelt werden. 21

22

Vertragstechnisch strukturieren: Juristen mögen eine klare Sprache (Eindeutigkeit) und eine klare Struktur; besonders Redundanzen, die sich z.B. widersprechen könnten, sind zu vermeiden. Verkaufstechnisch strukturieren: An die Sprache und Formulierungen des Kunden anpassen, angebotene Leistungen in separat zu beziehende Module strukturieren etc. Ein einfaches Beispiel aus der Praxis: Der Kunde wünscht eine „Vorstudie“, im Sprachgebrauch des Anbieters wird hierfür der Begriff „Pre-DesignKonzept“ verwendet. Beide meinen das Gleiche, der Kunde versteht garantiert etwas anderes!

148

Prozessbereiche und Prozesskategorien

• Die vorgenannten Arbeitsschritte erfolgen dabei iterativ und natürlich auch unter ständiger Begleitung durch die Vertragsspezialisten. Liegen die fachlichen Inhalte, der Materialbedarf, die Termin- und Ressourcenplanungen vor und sind die Risiken identifiziert sowie bewertet, erfolgt abschließend die Kalkulation und Fertigstellung des Angebotes im Prozess 221 Contract Definition. Erhält der Kunde das Angebot, so erhält er nicht nur den fachlichen Teil (den Lösungsvorschlag), sondern i.d.R. ist auch bereits der von der Anbieterseite vorgeschlagene Vertragsentwurf integriert. Im weiteren Verlauf werden dann typischerweise erst die fachlichen Inhalte geklärt, bevor der eigentliche Vertrag ausgehandelt wird. Diesen Umstand haben wir im Prozessmodell berücksichtigt, indem wir Angebotserstellung und Vertragsgestaltung in zwei getrennten Prozessen (212 Bid Management und 221 Contract Definition) dargestellt haben. Das komplette Angebot für den Kunden liegt dann vor, wenn nach dem Ergebnis Angebots-Vorlage erstellt der Prozess 211 Contract Definition das Resultat Angebot erstellt erzeugt hat. Das primäre Ereignis, das den Prozess 212 Bid Management anstößt, ist das Ereignis Angebotsanfrage formuliert, welches ein Ergebnis aus 211 Sales Management ist. In der Folge wird die Anfrage analysiert. Stellt sich dabei heraus, dass lediglich eine Vertragsänderung notwendig ist (Vertragsänderung identifiziert), wird die Entwicklung eines entsprechenden Vertragsvorschlages im Prozess 221 Contract Definition initialisiert. Ansonsten muss die Angebotserstellung geplant werden, wobei der meist vorgegebene Abgabetermin die Planung dominiert. Die fachliche Leistung muss in Abstimmung mit den entsprechenden fachlichen Spezialisten formuliert werden. Entsprechend werden Aufträge erteilt, die in der Folge die fachlichen Inhalte liefern. Abhängig von den benötigten Angebotsinhalten kann dies mehrmals iterativ erfolgen. In unserem Modell werden durch folgende Ereignisse Prozesse aktiviert, die entsprechende Resultate liefern: • Projekt vorgeschlagen; für alle Leistungen, die projektorientiert23 erbracht werden, erfolgt die Definition der fachlichen Inhalte sowie die Projektplanung über den Prozess 311 Project Planning. 23

In diesem Fall: klarer Start- und Endtermin und erwartetes Endresultat. Das gilt ebenso für Beratungsleistungen, Gutachten und aufwändige Systementwicklungen. Sollten Sie reine Ressourcen im Sinne einer Arbeitnehmerüberlassung anbieten, so wird dies in unserem Modell auch über diesen Weg abgewickelt bzw. geregelt.

Prozessbereich Sales

149

• Produktions-Planungsauftrag freigegeben; hiermit wird die Produktion im Sinne des Betriebs von Applikationen und Infrastruktur beauftragt, die entsprechenden Leistungsinhalte gemäß Angebotsanforderung zu definieren und zu planen. Dies erfolgt im Prozess 511 Production Planning. • Kundenservice-Planungsauftrag freigegeben; der Prozess 611 Customer Services Planning definiert und plant die Inhalte für Kundenserviceleistungen wie z.B. Help Desk, Reparaturservices, Remote Support etc. • Schulungs-Planungsauftrag freigegeben; die hierfür notwendigen Informationen für die Beschreibung der Leistungsinhalte werden im Prozess 641 Education & Training Planning erarbeitet. Der Rücklauf der Ergebnisse in Form der folgenden Ereignisse: • Projektofferte erstellt, • Produktionsofferte erstellt, • Kundenserviceofferte erstellt und • Schulungskonzept entwickelt aktiviert im Bid-Management-Prozess die Integration der Leistungsinhalte in das Angebot. (Das Gleiche gilt auch, falls während der Angebotserstellung die Projektplanung aktualisiert wird, was gerade im Projektgeschäft typisch ist.) Sind die Leistungsinhalte ausreichend beschrieben, wird in der Folge das Angebot fertiggestellt. Der Prozess schließt mit den Ereignissen Angebots-Vorlage erstellt und AE-Prognose24 aktualisiert (initialisiert 132 Customer Portfolio Management und / oder 133 Product Portfolio Management) ab. Je umfangreicher und damit auch komplexer Angebote sind, desto größer ist die Herausforderung, die Anforderungen der drei Bereiche „Verkauf“, „fachliche Leistungsbeschreibungen“ und „rechtliche Absicherung“ ausgewogen zu berücksichtigen. Größere Angebote können oftmals nur unter Verwendung von Projektmanagement-Methoden in der vorgegebenen Zeit mit ausreichender Qualität erstellt werden. 24

AE: Auftragseingang.

150

Prozessbereiche und Prozesskategorien

Standardisierbare Leistungen (oder auch Katalogleistungen) sind bzgl. der Leistungsinhalte, der Preise und der Lieferbedingungen so gestaltet, dass diese nur noch vom Kunden bestellt werden müssen. Das Angebot liegt nicht personalisiert vor und wird durch eine Bestellung dieser Leistung personalisiert. Durch die Bestellung wird das Angebot, sowohl was die Leistung als auch die vertraglichen Rahmenbedingungen betrifft, akzeptiert und in einen Vertragszustand überführt. Aufgrund der Standardisierung können und werden solche Angebote dem Kunden heute meist in automatisierter Form (z.B. Internet Shop, webbasierende Bestellsysteme) oder halbautomatisiert (z.B. Telefonbestellung mit anschließender Erfassung im internen Bestellsystem) angeboten. Der Prozess 213 Order Management beschreibt die Abwicklung der Bestellungen von standardisierten Leistungen. Primärer Prozessauslöser ist das Ereignis Produkt bestellt, welches der Kunde direkt oder über die Prozesse 211 Sales Management und 632 Repair Management auslöst. Natürlich kann es auch bei einer Bestellung zu Abweichungen kommen, die einer Nachfrage bedürfen. Beispiele hierfür sind z.B. gewünschte Abweichungen von Liefermengen, Terminen oder besondere Zustellbedingungen. In diesem Fall wird eine Bestellanfrage formuliert und in der Folge geprüft, ob die vom Kunden gewünschten Leistungen verfügbar bzw. realisierbar sind. Wird eine Bestellung gekündigt oder erfolgt eine Änderung (Bestellung geändert), sind die jeweiligen damit verbundenen Aufgaben (z.B. Stornierung aller Folgeschritte wie z.B. Produktion, Auslieferung etc.) durchzuführen. Ergebnisse des Prozesses 213 Order Management: • Mit dem Ergebnis Standardangebot zugestellt erhält der Kunde ein standardisiertes Angebot. Im Gegensatz zu den Angeboten, die im 212 Bid Management erstellt werden, beziehen sich die Leistungsinhalte auf standardisierte Leistungen, und die Variabilität der Rahmenbedingungen (z.B. Preisgestaltung, Zahlungsmodalitäten, Lieferbedingungen etc.) ist stark eingeschränkt. • Bestellung bestätigt; hiermit wird dem Kunden das Zustandekommen des Vertrages bestätigt und die Prozesse 222 Contract Administration (z.B. Auslösung der Rechnungsstellung), 334 Distribution Planning (bei einer Hard- / Software-Bestellung) oder 642 Registration Handling (im Fall einer Seminarbuchung) angestoßen. • Ist eine Bestellung storniert, muss primär sichergestellt werden, dass die Produktion / Auslieferung der Leistung gestoppt wird. In unserem

Prozessbereich Sales

151

Modell erfolgt dies beispielhaft durch den Anstoß der Prozesse 334 Distribution Planning oder 642 Registration Handling. Eine Stornierung führt auch zu einer Auflösung des Vertrages (Vertrag gekündigt). • Das Ergebnis Vertrag gekündigt führt im Prozess 222 Contract Management dazu, dass die Konsequenzen der Vertragsauflösung geprüft und eventuell daraus resultierende Maßnahmen veranlasst werden. Die Abwicklung von Standard-Leistungen kann heute in einem hohen Maße standardisiert werden. Führende Hardware-Lieferanten haben die damit verbundenen Prozesse, begründet durch die sehr hohen Stückzahlen, wirtschaftlich günstig hochgradig automatisiert. Mittelständische Unternehmen mit eher geringeren Stückzahlen erreichen oft nur einen wesentlich geringeren Automatisierungsgrad.

ICT Customer Contract Management Das Vertrags-Management umfasst drei Basisfunktionen: • die Vertragsgestaltung, • die Vertragsverwaltung, • die Überwachung der Vertragseinhaltung. Die Vertragsgestaltung unterteilt sich pragmatisch gesehen in drei Bereiche: • die Leistungsbeschreibung, deren inhaltliche Erarbeitung im vorliegenden Modell im Prozess 212 Bid Management erfolgt, • die Formulierung der allgemeinen Vertragsbedingungen wie z.B. Laufzeit des Vertrages, Pflichten des Auftraggebers, Urheberrechte, Haftung, Garantien, Konditionen und Zahlungsmodalitäten, Kündigungsfristen und -bedingungen, Abnahmekriterien und Verfahren etc., • Die abschließende Festlegung von Preisen, Zahlungsmodalitäten und Terminen. Die formaljuristische Gestaltung von Verträgen, welche die Erbringung und Abnahme von ICT-Leistungen beinhaltet, benötigt spezialisierte Juristen. Insbesondere Verträge, die Festpreise, Pönalen, Sublieferanten oder

152

Prozessbereiche und Prozesskategorien

Abb. 86. ICT Customer Contract Management

Prozessbereich Sales

153

auch internationalen Charakter haben (z.B. Installation der Lösungen in verschiedenen Ländern), bedingen den Einsatz juristischer Profis. Die abschließende Festlegung von Preisen, Zahlungsmodalitäten und Terminen sind Funktionen, die grundsätzlich nicht allein dem Sales bzw. den Produktionsbereichen überlassen wird. Der Preis ist ein wesentlicher Entscheidungsfaktor beim Käufer. Das richtige „Pricing“ kann also wettbewerbsentscheidend sein. Allerdings bestimmt der Preis den Deckungsbeitrag, also die Marge, und deckt Risiken und Garantieleistungen ab. Die Zahlungsmodalitäten nehmen Einfluss auf die Liquidität und können bei größeren Projekten zu einer manchmal schwer verkraftbaren oder nur fremdfinanzierbaren Vorfinanzierung führen. Die Termine, die sich auf die Übergabe von Ergebnissen, Abnahmen von Leistungen etc. beziehen, sind grundsätzlich Risiken, da an diese Termine die Strafgebühren (Pönalen, Malusregelungen etc.) gekoppelt sind. Das richtige Pricing ist in vielen Fällen wettbewerbsentscheidend. Gerade bei Großaufträgen, wie sie im Projektgeschäft oder für das Outsourcing typisch sind, spielen eine Vielzahl von Kriterien eine Rolle, die die abschließenden Konditionen beeinflussen. In der Euphorie des bevorstehenden Auftrages wird dann schnell einmal auch das Risiko-Management vergessen. Der Prozess 221 Contract Definition, der primär die Aufgaben zur Vertragsgestaltung umfasst, wird von der Ereignissen Angebotsvorlage erstellt oder Vertragsänderung identifiziert, die jeweils Ergebnisse des 212 Bid Management-Prozesses sind, angestoßen. In der Praxis ist gerade bei größeren und / oder komplexeren Angeboten die fachliche Lösungsbeschreibung, die Termin- und Ressourcenplanung, die Kalkulation sowie die Definition der formellen Vertragsbestandteile ein iterativer Prozess, in welchen auch oftmals der Kunde eingebunden ist. Das Ereignis Vertragsänderungen identifiziert ergibt sich z.B. aus solch einem Überarbeitungszyklus. Ein anderer Fall, der diesem Ereignis zugrunde liegen kann, ist der, dass auf der Basis eines bestehenden Vertrages Leistungen angefragt werden, die einfach durch die Modifikation eines bestehenden Vertrages entsprechend geregelt bzw. abgesichert werden können. Das Ergebnis des Prozesses 221 Contract Definition ist das Ereignis Angebot erstellt. Folglich liegt zum Abschluss des Prozesses ein reales Dokument vor, welches durch Gegenzeichnung des Kunden zum Vertrag wird.

154

Prozessbereiche und Prozesskategorien

Die Erstellung von Rahmenverträgen, Vertragsbausteinen, Allgemeinen Geschäftsbedingungen etc. werden im Prozessmodell nicht eigens erwähnt, durchlaufen aber den gleichen Vorgang. Auslöser sind hier z.B. periodische Überprüfungen der bestehenden Vorlagen und deren evtl. Anpassung oder neue Leistungen / Produkte, für die neue vertragliche Regelungen benötigt werden. Ergebnisse sind i.d.R. standardisierte Vorlagen, die dem Vertrieb zur Verfügung gestellt werden. Die Vertragsverwaltung (222 Contract Administration) ist durch Aktivitäten geprägt, die nach dem Zustandekommen eines Vertrages beziehungsweise bei dessen Beendigung notwendig sind. Entsprechend sind die auslösenden Ereignisse: • Vertrag unterzeichnet, • Vertrag beendet; Beendigung nach Ablauf der vereinbarten Laufzeit oder durch Vertragserfüllung, • Vertrag gekündigt (Beendigung des Vertrages durch Kündigung), • Vertragsabweichung identifiziert. Mit der Unterzeichnung des Vertrages werden alle Aktivitäten gestartet, die zur Vertragserfüllung notwendig sind. Der Prozess bildet hierzu zwei Schwerpunkte ab: Einerseits werden alle Verrechnungsgrundlagen für die spätere Fakturierung der Leistungen erstellt: Rechnungsgrundlagen erstellt; die weitere Bearbeitung erfolgt dann im Prozess 141 Service Charging. Andererseits werden nun alle mit dem Vertrag verbundenen internen Aufträge zur Leistungserbringung freigegeben. Hierzu gehören die folgenden Ereignisse: • Lizenz benötigt aktiviert die Beschaffung / Sicherstellung entsprechender Software-(Fremd)-Lizenzen im Prozess 115 Licence Management. • Consulting-Auftrag freigegeben und Entwicklungsauftrag freigegeben; beides sind projektorientierte Auftragsformen, die personalintensiv in Form eines Projektes erbracht werden. Diese Aufträge werden aufgrund des sensiblen Themas „Ressourcenmanagement“ über das Programm-Management und dort über den Prozess 122 Approval procedure gesteuert. • Produktionsvertrag freigegeben; hiermit wird die Erbringung von Betriebsleistungen, die im Prozess 511 Production Planning geplant und initialisiert werden, angestoßen. Falls notwendig, wird auch der Pro-

Prozessbereich Sales

155

zess 711 Contingency Planning aktiviert, der Lösungen für die Sicherstellung und Fortsetzung des Betriebes bei Ausfall der ICTInfrastruktur plant und entwickelt. • Kundenserviceauftrag freigegeben; Beispiele hierfür sind Help-Deskoder auch Service-Leistungen vor Ort wie z.B. der Umzug von EDVSystemen oder Wartungsaufträge. Entsprechend werden die Prozesse 611 Customer Services Planning oder 633 Installation & Relocation Management angestoßen. • Schulungsauftrag freigegeben löst die definitive Seminarentwicklung und Ressourcenallokation (641 Education & Training Planning) sowie die Auftragsabwicklung über den Prozess 643 Education Processing aus. Mit der Freigabe der einzelnen Aufträge werden auch die definitiven Abschlussinformationen (Budgets, kalkulierter Umsatz, kalkulierter Deckungsbeitrag usw.) ermittelt und kommuniziert. Das Ergebnis Abschlussinformation erstellt ist ein auslösendes Ereignis für die Prozesse • 132 Customer Portfolio Management, • 133 Product Portfolio Management, • 211 Sales Management. Wird eine Vertragsabweichung identifiziert, sind die entsprechenden Konsequenzen zu prüfen und Maßnahmen einzuleiten. Erfolgt die Vertragsabweichung durch den Leistungserbringer, also die ICT-Unternehmung, kann dies z.B. Einfluss auf die Rechnungsstellung (Verrechnungsdaten zusammengestellt) nehmen oder, wenn der Kunden seine Pflichten nicht erfüllt, auch zur Kündigung des Vertrages führen (Vertrag gekündigt). Mit der Beendigung eines Vertrages, entweder nach Vertragserfüllung oder durch Kündigung, wird eine Vielzahl von Ereignissen ausgelöst. In unserem Modell haben wir die folgenden berücksichtigt: • Verrechnungsdaten zusammengestellt löst z.B. die Erstellung der Abschlussrechnung oder gegebenenfalls auch Gutschriften im Prozess 141 Service Charging aus. • Lizenz abgelaufen; wird z.B. ein Lizenzvertrag gekündigt, wird in der Folge im Prozess 115 Licence Management die Lizenz deaktiviert. • On-Site-Einsatz notwendig; muss z.B. eine im Rahmen des Vertrages installierte Hardware (z.B. Router) des ICT-Unternehmens beim

156

Prozessbereiche und Prozesskategorien

Kunden deinstalliert und zurückgenommen werden, wird dies über den Prozess 631 On-Site Dispatching abgewickelt. • Zugriffsberechtigung deaktiviert; haben Kunden Zugang zu passwortgesteuerten Systemen, wird ihr Zugang mit der Beendigung des Vertrages aufgehoben und die entsprechenden Aufgaben im Prozess 624 Authorization Management aktiviert. • Produktionsvertrag beendet; die Einstellung bzw. Beendigung von Betriebsaktivitäten kann je nach Art und Umfang vielfältige Aktivitäten zur Folge haben, diese werden über 511 Production Planning geplant und gesteuert. • Kundenserviceauftrag beendet; werden z.B. aufgrund des Vertragsendes Help-Desk-Leistungen nicht mehr erbracht, werden die Auswirkungen im Prozess 611 Customer Services Planning geplant und gesteuert. In unserem Modell sind die Standard-Leistungen / -Produkte der ICT-Unternehmung in Form von Bestellungen durch den Kunden beziehbar. Mit einer Bestellung, die i.d.R. auch eine Authentifizierung in Form einer Unterschrift oder einer Kundennummer benötigt, wird ebenfalls ein Vertrag eingegangen. Somit werden hier auch die Ereignisse Bestellung bestätigt und Bestellung storniert berücksichtigt, die das Zustandekommen bzw. den Abbruch der vertraglichen Beziehung bei einer Bestellung betreffen. Im Modell werden bewusst die Aufgaben des Verkaufes (in diesem Fall 213 Order Management) von denen der Vertragsverwaltung getrennt. Als Resultat des Prozesses 213 Order Management wird dem Kunden die Bestellung bestätigt oder aufgrund einer Änderung oder Kündigung die Bestellung storniert. Im Prozess 222 Contract Definition werden in der Folge die Bestellungen aus vertraglicher Sicht bearbeitet. Die Schwerpunkte liegen hierbei bei der Erzeugung folgender Ergebnisse: • Verrechnungsdaten erstellt; damit wird die Rechnungsstellung im Prozess 114 Service Charging angestoßen. • Bestellinformationen erstellt liefert die Informationen, die in den Prozessen 132 Customer Portfolio Management, 133 Product Portfolio Management und 211 Sales Management weiter bearbeitet werden. • Lizenz benötigt; soweit mit der Bestellung auch Lizenzen (insbesondere Fremdlizenzen) geliefert werden, wird der Prozess 115 Licence Management aktiviert.

Prozessbereich Sales

157

Sind Software-Fremd-Lizenzen integrierter Bestandteil der eigenen Leistung, sollten im Sinne eines Risiko-Managements zwingend alle damit verbundenen Konsequenzen, die sich durch die Verknüpfung mit der eigenen Leistung ergeben, von einem Spezialisten geprüft und gegebenenfalls vertraglich abgesichert werden. Während der Laufzeit der Verträge ist die Überwachung der Leistungserbringung, der Einhaltung der dazu gehörigen Vereinbarungen und gegebenenfalls der Reaktion bei Abweichungen das A und O. Dies gilt mehr oder weniger für alle Arten von Leistungen. Naturgemäß stehen Leistungen, die über einen längeren Zeitraum erbracht werden wie z.B. Großprojekte oder permanente Betriebsaufgaben, hierfür im Vordergrund. Besonders Verträge, auf deren Basis Applikationen und / oder Infrastrukturen betrieben oder auch regelmäßige Dienstleistungen (z.B. Help Desk) erbracht werden, beinhalten oftmals Rahmenwerte wie Verfügbarkeits-, Reaktionszeiten etc. Diese Leistungen werden dann meist in unterschiedlichen Service Levels, die auch unterschiedlich bepreist werden, angeboten. Vertraglich werden diese Leistungen z.B. in Form von Service Level Agreements (SLA) vereinbart. Der Prozess 223 Contract Monitoring beinhaltet die Aufgaben der Überwachung. Diese umfassen vereinfacht gesehen immer einen Soll- / IstAbgleich, im Fall von Abweichungen, die eine Nichteinhaltung des Vertrages bedeuten, die Überprüfung der vertraglichen Konsequenzen und die Einleitung entsprechender Maßnahmen. Der Schwerpunkt liegt in der Überwachung der Vertragserfüllung durch den Leistungserbringer, also die ICT-Unternehmung. Natürlich kann auch der Auftraggeber seine vertraglichen Pflichten vernachlässigen, was ebenso im Prozess 223 Contract Monitoring erkannt wird. Die Überwachung der Leistungserbringung im Sinne der Einhaltung der Verträge ist eine permanente Aufgabe. In unserem Modell haben wir als Resultat aus diversen Prozessen folgende Ereignisse, die einen entsprechenden Soll- / Ist-Abgleich anstoßen, berücksichtigt: • Vertragsverletzung identifiziert; besonders in den Prozessen 512 Availability Management und 513 Capacity & Performance Management werden produktionsnahe Kennzahlen erhoben, die insbesondere bei markanten Werten auf Vertragsverletzungen hinweisen.

158

Prozessbereiche und Prozesskategorien

• Höchste Mahnstufe erreicht, resultierend aus 141 Service Charging, verweist auf eine Nichterfüllung des Vertrages durch den Kunden. Dies kann aber auch ein Hinweis darauf sein, dass Leistungen nicht wie vereinbart erbracht wurden und aus diesem Grunde Rechnungen vom Kunden zurückgehalten werden. • Projektbericht erstellt und Projekt abgeschlossen; über projektorientierte Leistungen wird periodisch während der Projektlaufzeit im Prozess 312 Project Control berichtet, aus dem Prozess 315 Project Finalisation resultiert der Abschlussbericht. Sind diese Berichte strukturiert und werden Projektprobleme offen kommuniziert, sind sie eine wertvolle Quelle, um eventuelle Vertragsverletzungen im Vorfeld bzw. unmittelbar nach ihrem Eintritt zu erkennen. • Produktionsbericht erstellt; über Leistungen wie den Betrieb von Applikationen und einer ICT-Infrastruktur, die permanent erbracht werden, wird periodisch berichtet. I.d.R. sind diese Berichte auch kundenspezifisch strukturiert, d.h. die für die Überprüfung der Vertragserfüllung notwendigen Kriterien werden entsprechend ausgewiesen. In unserem Modell liefern die folgenden Prozesse Produktionsberichte: o 512 Availability Management o 513 Capacity & Performance Management o 521 Production Control o 612 Customer Services Monitoring • Servicebericht erstellt; werden Leistungen vor Ort erbracht, werden i.d.R. Serviceberichte erstellt. Auch wenn es sich dabei in den einfachsten Fällen um einen kurzen, vom Kunden gegenzuzeichnenden Arbeitsrapport handelt, kann auf dieser Basis die Vertragserfüllung überwacht werden. Serviceberichte sind Ergebnisse der Prozesse 632 Repair Management und 633 Installation & Relocation Management. • Schulungsbericht erstellt; insbesondere wenn umfassende Schulungsleistungen erbracht werden, können periodische oder abschließende Berichte erstellt werden, auf deren Basis die Vertragserfüllung überprüft werden kann. Als Resultate der Vertragsüberwachung haben wir folgende Ereignisse berücksichtigt:

Prozessbereich Project & Development

159

• Rechnungsgrundlagen erstellt kann z.B. die Folge einer Bonus / Malus-Vereinbarung sein und wird im Prozess 141 Service Charging weiterverarbeitet. • Risiko erkannt; z.B. ein erhöhter Bezug von Garantieleistungen durch den Kunden löst den Prozess 163 Risk Management aus. • Vertragsabweichung identifiziert; Art und Umfang können äußerst vielfältig sein, wobei hier vor allem die Abweichungen bei der Leistungserfüllung im Vordergrund stehen. Die weitere Bearbeitung erfolgt in den Prozessen o 211 Sales Management o 222 Contract Management o 312 Project Control o 511 Production Planning o 611 Customer Services Planning • Vertrag erfüllt; das optimale und erwünschte Ergebnis im Rahmen einer Vertragsüberwachung. Vertragsüberwachungen sind aufwändig und werden aus diesem Grunde in vielen ICT-Unternehmen vernachlässigt. Oft fehlt auch das Bewusstsein dafür, dass eine regelmäßige Kontrolle, ob die Leistungen wie vereinbart erbracht werden, eine Vorstufe des Risiko-Managements ist.

Prozessbereich Project & Development Im Kapitel ICT Company wird das Leistungsspektrum einer ICT-Unternehmung beschrieben. Grundsätzlich werden drei Leistungsgruppen unterschieden: 1. Leistungen die auf der Basis von Arbeitszeit erbracht und verrechnet werden, 2. Leistungen / Produkte mit Gewerk-Charakter, die entweder selbst produziert oder wiederverkauft werden, 3. permanent zu erbringende Leistungen, die auf der Bereitstellung und dem Betrieb einer IT-Infrastruktur basieren.

160

Prozessbereiche und Prozesskategorien

Die Leistungen der Gruppe 1 und 2 sind projektorientiert zu erbringen. Vorleistungen wie die Entwicklung neuer Produkte oder die Bereitstellung bzw. Weiterentwicklung einer IT-Infrastruktur sind Vorhaben, die ebenfalls in Form von Projekten realisiert werden. Gemäß der DIN 69901 ist ein Projekt ein Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in seiner Gesamtheit gekennzeichnet ist wie z.B.: • Zielvorgabe (Inhalt, Qualität, Kosten, Aufwand, Termin) • Zeitliche, finanzielle, personelle oder andere Begrenzungen • Abgrenzungen gegenüber anderen Vorhaben • Projektspezifische Organisation Auch der Definitionsansatz „Projekte sind Erst- und Einmalvorhaben“ verweist auf die Einmaligkeit der Bedingungen. Im Vergleich hierzu: Typischen Betriebsleistungen oder dem reinen Verkauf von Handelswaren wie Hard- oder Software, Seminaren, Verbrauchsgütern etc. fehlt die oben erwähnte Einmaligkeit der Bedingungen! Die Leistungserbringung erfolgt in einer speziell hierfür eingerichteten und darauf spezialisierten und permanent existenten Organisationsstruktur. Eingehende Aufträge sind entsprechend zu klassifizieren, ob sie in einer permanent bestehenden Organisationsstruktur abgewickelt werden können oder ob für die Abwicklung eine eigene, in diesem Fall dann projektspezifische Organisation benötigt wird. Ein typisches Merkmal hierfür ist, dass die Verantwortung für die Auftragserfüllung einer Person (Projektleiter!) und nicht einer Organisationseinheit (z.B. Rechenzentrumsbetrieb) zugeordnet wird. In vielen Unternehmen fehlt eine einheitliche Auffassung darüber, was ein Auftrag ist. Dies kommt daher, dass es eine Vielzahl von Ausprägungen geben kann, von denen dann aber immer nur ein Teil den Mitarbeitern (inkl. Management) bekannt ist. Die eindeutige Definition der Auftragstypen ist eine wesentliche Voraussetzung für die Definition der damit verbundenen und darauf ausgerichteten Geschäftsvorfälle. Projekte benötigen eine spezifische Führung, die die Aufgabe hat, die verschiedenen Einzelaktivitäten eines Projektes so zu steuern, dass die Projektziele und -vorgaben erreicht werden. Gemäß DIN 69901 versteht

Prozessbereich Project & Development

161

man unter Projektmanagement, „die Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mittel für die Abwicklung eines Projektes.“ Typische Vorhaben, die Projektcharakter haben – unabhängig davon, ob es sich hierbei um Kundenaufträge oder interne Vorhaben handelt –, sind z.B.: • Neuentwicklungsprojekte aller Art • Weiterentwicklungsprojekte aller Art • Infrastrukturprojekte • Konzeptionsarbeiten aller Art • Analysearbeiten • Erstellung von Gutachten • Installations-, Montageprojekte etc. Projekte werden i.d.R. in mehrere Phasen gegliedert. Diese können als Ganzes (Gesamtprojekt) oder in Teilen (Teilprojekt) beauftragt werden. Die Einrichtung eines Projektes zieht immer einen gewissen Aufwand nach sich, der sich in Anforderungen bzgl. des Projekt Controllings, des Qualitäts- und Risiko-Managements äußert. Weiter muss in vielen ICT-Unternehmen eine Freigabe durch ein übergeordnetes Programm-Management (Koordination, Überwachung aller im Unternehmen laufenden Projekte) erfolgen. Dies führt in der Praxis sehr schnell zu der Diskussion, ob wirklich jeder Auftrag, der per Definition ein Vorhaben mit Projektcharakter ist, tatsächlich auch als Projekt zu behandeln und der damit verbundene Aufwand zu erbringen ist. Dies gilt insbesondere für Klein- und Kleinstprojekte, bei denen der zu erbringenden Aufwand typischerweise zwischen 5 und 40 PT liegt und die innerhalb eines Monats abgeschlossen werden. Als Gegenargumentation wird oft der im Verhältnis zur tatsächlichen Leistungserbringung zu hohe Overhead-Aufwand für die Genehmigungs- und Freigabeaktivitäten ins Feld geführt. Dieser durchaus berechtigten Kritik muss und kann Rechnung getragen werden, indem Projekte nach verschiedenen Kriterien klassifiziert werden. Die Kriterien geben dann auch die entsprechenden Rahmenbedingungen für die jeweils notwendigen Tätigkeiten in den einzelnen Prozessen vor. So könnte z.B. für Kleinstprojekte25 auf reiner Aufwandsbasis auf das Risk Management vollständig verzichtet werden. 25

Aus der Praxis: Oftmals ist gerade bei Kleinaufträgen mit Festpreischarakter die Überschreitung des kalkulierten Aufwandes und der damit verbundene niedrigere

162

Prozessbereiche und Prozesskategorien

Andererseits ist es so, dass gerade für Kleinaufträge, in denen Knowhow für Konzeptions-, Analysearbeiten, Gutachten oder Planungen etc. erforderlich ist, Know-how-Träger der Unternehmung benötigt werden, die aufgrund ihrer Qualifikation auch in anderen Projekten und Tätigkeiten beschäftigt sind. In diesem Fall spielt dann das Ressourcen-Management eine entscheidende Rolle, da die i.d.R. begrenzte Verfügbarkeit von Knowhow-Trägern den tatsächlichen Engpass darstellt. Jeder Auftrag mit Projektcharakter ist als Projekt zu handhaben. Auf der Basis einer Typisierung (z.B. nach Größe, Komplexität) können die Anforderungen an das Projekt-Management gesteuert werden. Somit können kleinere bzw. einfachere Projekte von einem möglichen „Projekt-Overhead“ verschont und der Durchlauf durch die Freigabeprozesse beschleunigt werden. Unabhängig davon ist, dass die benötigten Ressourcen durch ein zentrales Ressourcen-Management bewirtschaftet werden. ICT-Unternehmen, die in einem hohen Maße Leistungen mit Projektcharakter erbringen, müssen über eine effiziente Organisation verfügen, die eine gewinnorientierte Auftragsabwicklung sicherstellt. Es werden Verfahren benötigt für • die Leistungserbringung an sich (Entwicklungsverfahren), • das Projektmanagement, • das Multi-Projekt-Management. Für alle drei Disziplinen gibt es umfangreiche Fachliteratur. Wir konzentrieren uns in unserem Referenz-Prozessmodell ausschließlich darauf, die in der Praxis z.T. sehr komplexen Zusammenhänge auf der Prozessebene für die genanten drei Disziplinen aufzuzeigen. Das Thema „MultiprojektManagement“ ist im Referenz-Prozessmodell in der Prozesskategorie ICT Program Management im Prozessbereich Management abgebildet. In diesem Kapitel wird der Prozessbereich Project & Development behandelt, die Prozesskategorie ICT Project Management beinhaltet wesentliche Prozesse Deckungsbeitrag erheblich. Prozentual gesehen ist diese Überschreitung oftmals sogar wesentlich höher als bei großen Festpreisprojekten, da hier gerne die Kontrollaktivitäten vernachlässigt werden bzw. zu schnell „nachgeliefert“ wird.

Prozessbereich Project & Development

163

Abb. 87. Prozessbereich Project & Development

des Projekt-Managements, die Prozesskategorien ICT Consulting & System Development sowie ICT Release Management vertreten die Prozesssicht auf Entwicklungsverfahren. ITIL selbst geht auf die Thematik des Projekt-Managements nicht ein und verweist auf PRINCE (Projects IN Controlled Environments), die Standardmethode der britischen Regierung für das Projekt-Management. Ebenso sind Entwicklungsverfahren für die Systementwicklung kein primärer Bestandteil von ITIL. ITILs Application Management behandelt den Lifecycle einer Applikation, die Anforderungen des Business, die Entwicklung, Ausbreitung, Betrieb und Optimierung, und stellt die Zusammenhänge zu den Service-Delivery- und Service-Support-Funktionen gemäß ITIL her. ITIL geht davon aus, dass die Soft- und Hardwaresysteme verfügbar sind, für die der Service26 Bereitstellen, Betrieb und Support der IT-Systeme, die die Geschäftsprozesse des Kunden unterstützen, erbracht wird. 26

Definition von „Service” nach ITIL: One or more IT systems which enable a business process.

164

Prozessbereiche und Prozesskategorien

ICT Project Management Ein Projekt-Management umfasst gemäß DIN 69901 „die Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mittel für die Abwicklung eines Projektes.“ Es beinhaltet dabei ein sehr weites Spektrum von Aufgaben und notwendigen Fähigkeiten. Trotz vielerlei Philosophien und Ansätzen zum Thema „Projekt-Management“ haben sich gewisse Grundsätze etabliert, die den Erfolg eines Projektes sicherstellen sollen. Diese sind: • Systematische Planung und Strukturierung von Projekten • Gezielte Freigabe eines Projektes, um Ziele und Vorgaben breit abzusichern • Systematisches Projekt-Controlling: Sicherstellen der Transparenz hinsichtlich Projektverlauf und Projektstand • Frühzeitiges Erkennen von Risiken • Systematischer Umgang mit Änderungen, Störungen und Anforderungen Diese Grundsätze werden in unserem Referenz-Prozessmodell in der Prozesskategorie 31 ICT Project Management auf Prozessebene abgebildet: • 311 Project Planning beinhaltet umfangreiche Planungs- und Vorbereitungsaktivitäten. • 312 Project Control umfasst die Aktivitäten zur Überwachung des Projektverlaufs und des Controllings. • 313 Project Risk Management enthält die Prüfung und Reaktion auf Risiken. • 314 Project Change Management regelt den Umgang mit ProjektChanges. • 315 Project Finalisation umfasst die Aktivitäten, die mit Abschluss eines Projektes notwendig sind. Die Genehmigung und Freigabe eines Projektes, die Zuweisung der benötigten Ressourcen und Mittel erfolgt in der Prozesskategorie 12 ICT Program Management. Ein Projekt kann vereinfacht in vier Phasen unterteilt werden: • Vorbereitungsphase: vor der Freigabe des Projektes; Konkretisierung des Projektvorhabens, Projektplanung, Formulierung des Projektauftrages.

Prozessbereich Project & Development

Abb. 88. ICT Project Management

165

166

Prozessbereiche und Prozesskategorien

• Initialphase: nach Auftragserteilung bzw. Freigabe des Projektes; Projektinitialisierung, Einrichtung der Projektorganisation, Verteilung der Aufträge, Start der Umsetzung. • Realisierungsphase: Erarbeitung der Projektergebnisse. • Abschlussphase: Übergeben der Projektergebnisse an den Kunden und evtl. an den Betrieb, Erfahrungen sichern, Abschlussrechnungen etc. Der folgende rote Faden veranschaulicht den Verlauf eines Projektes von der Projektidee bis zum Abschluss des Projektes. Hierzu nehmen Sie bitte das Referenz-Prozessmodell zur Hand. Wir starten beim Prozess 311 Project Planning. Vorbereitungsphase27: • Mit dem Ereignis Projekt vorgeschlagen liegt eine Projektidee vor. • Diese wird in der Folge soweit detailliert, dass ein Projekt beantragt werden kann. • Dieses Ereignis löst im Prozess 121 Program Planning, unter der Berücksichtigung aller im Unternehmen geplanten oder laufenden Vorhaben bzw. Projekte, die Antragsprüfung und bei vorläufiger Annahme des Projektes die Überprüfung der Planungsfreigabe aus. • Mit dem Ereignis Planungsauftrag erteilt werden die entsprechenden Ressourcen und Mittel für die Detailplanung freigegeben und im Prozess 311 Project Planning die entsprechenden Planungsaktivitäten ausgelöst. • Diese schließen mit dem Ergebnis Projektplanung aktualisiert ab. • Damit steht die vollständige Planung für den Genehmigungsprozess (122 Approval Process), der durch das genannte Ereignis aktiviert wird, zur Verfügung. • Im Erfolgsfall schließt dieser Prozess mit dem Ereignis Projektauftrag freigegeben ab und startet damit die Initialphase.

27

Die Dauer dieser Phase bzw. der beschriebenen Abläufe ist abhängig von der Projektgröße und der Komplexität des Vorhabens. Sie kann bei größeren Projekten mehrere Wochen bis Monate und bei Kleinprojekten wenige Stunden bis Tage, je nach Organisation der Entscheidungsprozesse, dauern.

Prozessbereich Project & Development

167

Initialphase: • Im Prozess 121 Project Planning wird aufgrund des Ereignisses Projektauftrag freigegeben das Projekt gestartet. • Hierzu gehört die Einrichtung des Projektes, gemäß den Projekt-Management-Vorgaben des Unternehmens. • Mit den Ereignissen Lieferauftrag freigegeben (soweit externe Lieferanten eingebunden sind) und Realisierungsauftrag freigegeben endet die Initialphase und beginnt die Realisierungsphase. Realisierungsphase: • In unserem Beispiel wird ein IT-System entwickelt. • Realisierungsauftrag freigegeben aktiviert in diesem Fall den Prozess 322 System Development. • Während der Projektlaufzeit wird periodisch (symbolisiert durch die Uhr) der Prozess 312 Project Control ausgelöst. • Primäres Ergebnis ist Projektbericht erstellt, welches die Transparenz über Projektverlauf und Projektstatus sicherstellt. • Unter anderem aktiviert dieses Ergebnis das Programm Controlling (Prozess 123 Program Controlling), welches alle laufenden Projekte des Unternehmens überwacht. • Werden während der Realisierungsphase Projektrisiken erkannt, werden diese über den Prozess 313 Project Risk Management abgewickelt, welcher bei Bedarf auch das Risiko-Management (162 Risk Management) auf Managementebene aktiviert. • Projekt Changes, die z.B. über das Change Management (411 Change Handling, P-Changes identifiziert) gesteuert werden, werden im Prozess 314 Project Change Management bearbeitet. Abschlussphase: • Der Prozess 322 System Development schließt mit dem Ereignis System abnahmebereit ab. • Dieses Ereignis aktiviert den Prozess 315 Project Finalisation. • Hier wird nun die Übergabe des Systems an den Kunden geregelt und bei erfolgreicher Abnahme und Übergabe (System abgenommen) das Projekt abgeschlossen.

168

Prozessbereiche und Prozesskategorien

Projekt-Management ist eine Führungsaufgabe. Die Person des Projektleiters nimmt wesentlichen Einfluss auf die Erfolgsaussichten eines Projektes. Wird ein Projekt nicht systematisch geleitet, dann leidet das Projektergebnis darunter! Diese Tatsache ist unabhängig von der Projektgröße. Die Planung eines Projektes ist keine einmalige Aufgabe. Die Planungsaktivitäten vor und bis zum Projektstart sind i.d.R. sehr aufwändig und zeitintensiv. Allerdings werden gerade bei größeren Projekten, ausgelöst durch die verschiedensten Ereignisse, die Planungsaktivitäten von ständigen Plananpassungen dominiert. Der Prozess 311 Project Planning wird entsprechend durch eine Reihe von Ereignissen angestoßen: 1. Projekt vorgeschlagen; mit diesem Ereignis liegt quasi eine mehr oder weniger konkrete Projektidee vor, die in der Folge zu detaillieren und in einem Projektantrag zu formulieren ist. Die Quellen für einen Projektvorschlag sind, je nach Art des Vorhabens, vielfältig: • Hervorzuheben als Auslöser ist der Prozess 212 Bid Management. In diesem Fall handelt es sich um eine Kundenanfrage, für die vorgängig eine Projektofferte erstellt wird. • Erfolgt der Anstoß aus einer zentralen Vorhabenplanung (z.B. strategische Vorhaben), erfolgt dieser periodisch durch den Prozess 121 Program Planning. • Sind neue Produkte zu entwickeln, handelt es sich um Entwicklungsvorhaben, die als Projekte durchzuführen sind. In diesem Fall ist das entsprechende Ereignis ein Ergebnis des Prozesses 134 Product & Service Management. • Steht die Entwicklung eines Software Release an, handelt es sich um ein Entwicklungsprojekt, das über den Prozess 331 Release Planning initialisiert wird. • Im Rahmen des Change Managements kann ein RFC zu einem Projektvorschlag führen. Ein Resultat des Prozesses 411 Change Handling kann das Ereignis Projekt vorgeschlagen sein. • Wird im Rahmen des Prozesses 711 Contingency Planning festgestellt, dass die Fortsetzung der Leistungserbringung bzw. die Sicherstellung des Geschäftsbetriebs von Kunden im Notfall nur

Prozessbereich Project & Development

169

durch Ausbau der Infrastruktur oder der Schaffung sonstiger Rahmenbedingungen gewährleistet werden kann, hat dies einen Projektvorschlag zur Folge. • Die Einführung neuer Technologien, initiiert über den Prozess 732 Technology Management, erfolgt ebenfalls projektorientiert. • Alle Vorhaben, die die Infrastruktur als solche betreffen und ebenfalls als Projekt zu realisieren sind, werden als Ergebnis des Prozesses 741 Facility Management vorgeschlagen. Der mit dem Ereignis Projekt vorgeschlagen ausgelöste Teilprozess endet mit drei Ergebnissen, die sowohl einzeln als auch in Kombination den Prozess abschließen können: • Primäres Ergebnis des Prozesses ist das Ereignis Projekt beantragt, welches die Freigabemechanismen des Projektes im Prozess 121 Program Planning anstößt. • Handelt es sich um ein komplexes Projekt, das, bevor der Projektantrag gestellt werden kann, weitere Abklärungen benötigt, wird ein Konzeptauftrag formuliert, welcher im Prozess 321 Conceptual Design die notwendigen Folgeaktivitäten auslöst. Der Prozess wird unterbrochen und erst dann wieder fortgesetzt, wenn das Ereignis Konzeptergebnis erarbeitet eintritt (Ergebnis des Prozesses 321 Conceptual Design). • Handelt es sich um eine Anfrage aus dem 212 Bid Management, wird eine Projektofferte erstellt, welche im Prozess 212 Bid Management in ein Angebot integriert wird. Projekte, die im Kundenauftrag realisiert werden sollen, erfordern im Vorfeld eine umfangreiche Analyse der Anforderungen (Requirements). Soll z.B. eine Software-Lösung zu einem Festpreis realisiert werden, muss die zu erbringende Leistung so detailliert beschrieben werden, dass darauf basierend die Abnahme der Software-Lösung erfolgen kann. Es empfiehlt sich, bereits diese Leistung (Formulierung des Abnahmekatalogs) als Projekt aufzusetzen und dem Kunden als eigenständige Leistung zu verkaufen.

170

Prozessbereiche und Prozesskategorien

2. Planungsauftrag erteilt hat alle Aktivitäten zur Folge, die einer detaillierten Planung zu Grunde liegen. Dies betrifft vor allem die Ressourcen und die Terminplanung, den Bedarf an finanziellen Mitteln, Material, Infrastruktur etc., die Kommunikation, die Qualitätsplanung sowie die Definition und Analyse von Projektrisiken etc. Eine detaillierte Planung ist nicht nur in der Vorbereitungsphase notwendig, sie kann auch in den folgenden Projektphasen ausgelöst werden bzw. erforderlich sein. Das Ereignis Planungsauftrag erteilt ist Resultat der folgenden Prozesse: • Handelt es sich um ein erstmaliges Vorhaben bzw. neues Projekt, ist das Ereignis ein Resultat des Prozesses 121 Program Planning, d.h. das Projekt wurde vom zentralen Programm-Management für eine detailliertere Planung, aber noch nicht zwingend für die Realisierung freigegeben. Insbesondere bei Großprojekten können hierfür schon erhebliche Ressourcen und Mittel notwendig sein. • In der Realisierungsphase können Änderungen auf das Projekt zukommen (im Referenz-Prozessmodell P-Change identifiziert). Die Quellen und Auswirkungen für Änderungen sind vielfältig und reichen von Kleinigkeiten bis zu umfangreichen Ergänzungen. Änderungen, die das Projekt betreffen, werden im Prozess 314 Project Change Management behandelt. Wird dort erkannt, dass die Änderung die Planung beeinflusst bzw. einen Planungsaufwand zur Folge hat, resultiert hieraus das Ereignis Planungsauftrag erteilt. • In der Abschlussphase des Projektes können Mängel erkannt werden, die zu Nachbesserungen führen, welche evtl. auch einen größeren Planungsaufwand nach sich ziehen können. Die Aktivitäten der Abschlussphase sind im Prozess 315 Project Finalisation geregelt. • Ein spezieller Fall ist die Weiterentwicklung eines Systems. Die Weiterentwicklung wird in unserem Referenz-Prozessmodell über das Release Management gesteuert. Einerseits wird ein neues Release genauso wie jedes andere Projekt über das Programm-Management genehmigt. Andererseits kann aber auch in der Vorbereitungsphase eines neuen Release ein entsprechender Planungsaufwand anfallen, der dann die entsprechenden Planungsaktivitäten im Prozess 311 Project Planning anstößt.

Prozessbereich Project & Development

171

Die Planungsaktivitäten enden mit den folgenden Ergebnissen, die sowohl einzeln wie auch in Kombination den Prozess abschließen können. • Im Rahmen der Ressourcenplanung wird auf dieser Ebene primär der Bedarf formuliert, welcher über Lieferanten abzudecken ist. Entsprechend wird der Prozess 114 Purchasing angestoßen mit der vorrangigen Aufgabe, entsprechende Offerten einzuholen. Die Planung der internen Ressourcen führt zu keinem eigenen Ergebnis und ist Bestandteil des im Planungsprozess entstehenden Projektplans. • Die Realisierung eines Projektes und die Einführung der Projektergebnisse führen i.d.R. zu zahlreichen Veränderungen im Unternehmen. Die Veränderungen können in allen Phasen des Projektes erkannt bzw. benötigt werden. Entsprechend werden im Rahmen der Planung oft mehrere RFC formuliert, welche im 411 Change Handling weiter bearbeitet werden. • Bewirkt das Projekt selbst Änderungen im Unternehmen, die über das Change Management gesteuert werden, wird der entsprechende Change geplant und dessen Genehmigung und Terminierung dann im Prozess 412 Change Planning & Control beurteilt und vorgenommen. • Im Planungsprozess wird auch eine Risikoanalyse durchgeführt. Da der Planungsprozess mehrmals durchlaufen wird, wird damit auch regelmäßig die Risikoanalyse aktualisiert, die im Prozess 123 Programm Control die entsprechenden Überwachungsaktivitäten initialisiert. • Projektplanung aktualisiert ist das Hauptergebnis der Planungsaktivitäten. Befindet sich das Projekt noch in der Vorbereitungsphase, löst dieses Ereignis den Prozess 122 Approval Procedure des zentralen Programm-Managements aus. Hier wird das Projekt definitiv zur Umsetzung freigegeben oder abgelehnt. Handelt es sich um ein „Auftragsprojekt“, also ein Projekt für einen Kunden, löst dieses Ereignis Aktivitäten (Angebotserstellung) im 212 Bid Management Prozess aus. Handelt es sich um ein Entwicklungsprojekt, das unter der Kontrolle des Release Managements steht, wird der Prozess 331 Release Planning aktiviert. 3. Change terminiert; ein Resultat des Prozesses 412 Change Planning & Control. Jeder Change, der direkten oder auch indirekten Einfluss

172

Prozessbereiche und Prozesskategorien

auf das Projekt hat, kann Einfluss auf die Projektplanung haben. Entsprechend kann dieses Ereignis die Planungsaktivitäten auslösen. Ein beliebtes Beispiel hierfür ist die Kollision von Einführungstermin und Wartungsfenster. Die Abhängigkeiten eines Projektes zu seinem Umfeld werden in der Planungsphase oftmals unterschätzt. Ein Projekt löst immer Veränderungen in seinem Umfeld aus! Diese sind frühzeitig zu kommunizieren, damit die entsprechenden Aktivitäten gestartet und die dafür notwendigen Mittel und Ressourcen zur Verfügung gestellt werden können. Auch sind die Veränderungen im Umfeld zu überwachen und bzgl. der Auswirkungen auf das eigene Projekt zu prüfen. 4. Projektauftrag freigegeben; dieses Ereignis löst die Initialphase und die damit verbundenen Aktivitäten aus. Die Projektorganisation wird aufgebaut und etabliert, die Terminplanung (mit allen oben beschrieben Konsequenzen) wird fortgeschrieben und aktualisiert und es werden die Realisierungsaufträge erteilt. Die wesentlichsten Ergebnisse dieser Aktivitäten sind: • Lieferauftrag freigegeben; hiermit wird der Einkauf von externen Leistungen oder Material über den Prozess 114 Purchasing ausgelöst. • Realisierungsauftrag erteilt – das entscheidende Ereignis! Es wird die inhaltliche Projektarbeit beauftragt und die Realisierungsphase des Projektes gestartet. Handelt es sich um ein rein konzeptionelles Projekt (typisch für Beratungsleistungen), sind die dafür notwendigen Aktivitäten im Prozess 321 Conceptual Design beschrieben. Ist es ein klassisches Realisierungsprojekt, wird der Prozess 322 System Development aktiviert. Jede Erteilung eines Realisierungsauftrages löst im Prozess 312 Project Controlling die damit verbundenen Aufgaben aus und dient dem Prozess 134 Product & Service Management als potenzielle Quelle für Produktideen. 5. Einführungsschulung beantragt ist bei einer ICT-Unternehmung eine Besonderheit im Rahmen der Entwicklung einer Software-Applikation, die von einer größeren Anzahl von Anwendern genutzt werden soll. Es ist ein typisches Ergebnis des Prozesses 322 System Development und bedarf i.d.R. einer umfangreichen Planung. Die Planungsaktivitäten schließen mit dem Ergebnis Schulung beauftragt ab.

Prozessbereich Project & Development

173

Die Detailplanung, inhaltliche Aufbereitung etc. wird im Prozess 641 Education & Training Planning geregelt. Eine Projektfreigabe ist grundsätzlich zentral in Form eines Multi-Projekts oder Programm-Managements zu organisieren. Es ist überraschend, in wie vielen ICT-Unternehmen bzw. -Organisationen dies nicht der Fall ist. Zentrales Entscheidungskriterium ist, ob die notwendigen Ressourcen in ausreichender Form bereitgestellt werden können. Hierzu bedarf es der zentralen Übersicht! Entscheidend ist auch die Besetzung der Projektleiterstelle, wobei der Mangel an geeigneten Projektleitern ein omnipräsentes Thema in der ICT-Branche ist. In der Praxis ist es aber so, dass viele Projekte trotz fehlender Voraussetzungen gestartet werden. Das Projekt-Management ist eine Führungs- und Steuerungstätigkeit. Hierzu gehören auch die Controllingaktivitäten wie sie im Prozess 312 Project Control beschrieben sind. Die Controlling-Aktivitäten können in der Grundausprägung wie folgt zusammengefasst werden: • Daten-, Informationserhebung und Verdichtung • Soll- und Ist-Abgleich der Planwerte (Budget, Termine, Meilensteine) • Erkennen von Planabweichungen, Risiken und sonstigen Besonderheiten • Führen des Controlling-Berichtswesens Der Prozess 312 Project Controlling kann von einer Vielzahl von Ereignissen angestoßen werden: 1. Steuerungsvorgaben definiert ist ein Ergebnis des Freigabeprozesses (122 Approval Procedure) und des übergeordneten ProgrammControllings (123 Program Control). Hiermit werden Vorgaben für das Berichtswesen und das Project Controlling gemacht. 2. Realisierungsauftrag erteilt; ein Resultat des Prozesses 311 Project Planning. Jeder Realisierungsauftrag führt dazu, dass das entsprechende Controlling für diesen Auftrag eingerichtet wird. 3. Periodisch (symbolisiert durch die Uhr); der gesamte Prozess muss z.B. monatlich durchlaufen werden und ein entsprechender Projektbericht vorgelegt werden.

174

Prozessbereiche und Prozesskategorien

4. Lieferstatus gemeldet; primär sind Lieferungen von externen Lieferanten zu überwachen, da die Zuverlässigkeit von externen Lieferungen zum einen oftmals einen Risikofaktor darstellt und zum anderen auch finanzielle Verpflichtungen damit verknüpft sind. Von den internen Prozessen melden die Prozesse 334 Distribution Planning, 335 HW / SW Distribution und 633 Installation & Relocation Management einen Lieferstatus, der z.B. auch für die Ergebniskontrolle von Bedeutung sein kann. 5. Leistungsdaten erfasst; hierbei handelt es sich um alle Leistungsdaten, die die ICT-Unternehmung in Zusammenhang mit dem Projekt erfasst. Im Vordergrund steht bei einem Dienstleistungsunternehmen primär die aufgewendete Arbeitszeit, die die Mitarbeiter melden und die oftmals eine wesentliche Grundlage für die Leistungsverrechnung darstellt. 6. Vertragsabweichungen identifiziert; ein Ergebnis des Prozesses 223 Contract Monitoring. Vertragsabweichungen sind immer heikel und haben immer entsprechende Controllingaktivitäten zur Folge. 7. Audit-Bericht erstellt; als Folge eines vom Prozess 161 Audit & CIP durchgeführten Audits können spezifische Controlling-Maßnahmen notwendig sein. Der Prozess 312 Project Control stellt die Transparenz und das Berichtswesen des Projektes bzgl. Projektverlauf und Projektstatus sicher und stößt auf der Basis der im Prozess gewonnen Erkenntnisse diverse weitere Aktivitäten an: 1. Lieferstatus angefordert richtet sich primär an Lieferanten mit dem wesentlichen Ziel, die Termineinhaltung zu kontrollieren bzw. sicherzustellen. 2. Change realisiert; im Rahmen der Terminüberwachung wird festgestellt, dass ein terminierter Change realisiert wurde, der die damit verbundenen Folgeaktivitäten im Prozess 412 Change Planning & Control auslöst. 3. P-Change identifiziert; Erkenntnisse im Controlling können dazu führen, dass Änderungen, die das Projekt28 betreffen, notwendig sind. Diese werden in der Folge im Prozess 314 Project Change Management bearbeitet. 28

P-Change = Projekt-Change, Änderung, die das Projekt betrifft.

Prozessbereich Project & Development

175

4. Q-Audit beantragt; im Controlling können Hinweise auf mangelnde Qualität bei der Leistungserbringung gefunden werden und bei Bedarf ein entsprechendes Qualitäts-Audit, das im Prozess 161 AuditCIP geregelt ist, initialisiert werden. 5. Partner-Audit notwendig; werden Defizite oder klare Mängel auf der Lieferantenseite erkannt, wird über dieses Ergebnis ein Audit im Rahmen des Prozesses 111 Partner Management veranlasst. 6. Lieferauftrag freigegeben; oftmals werden in Verbindung mit Meilensteinaktivitäten Aufträge bzw. Leistungen, die mit Dritten vereinbart wurden, freigegeben bzw. bestellt. Dies erfolgt aufgrund dieses Ereignisses im Prozess 114 Purchasing. 7. P-Risiko erkannt; wird im Rahmen der Controlling-Aktivitäten ein projektspezifisches Risiko29 erkannt, löst dies die notwendigen Aufgaben zur Risikenbehandlung im Prozess 313 Project Risk Management aus. 8. Verrechnungsdaten zusammengestellt aktiviert den Prozess 141 Service Charging und löst die Fakturierung gemäß Zahlungsvereinbarung aus. 9. Projektbericht erstellt; das selbsterklärende Hauptergebnis des Prozesses. Der Projektbericht löst in den folgenden Prozessen jeweils spezifische Aktivitäten aus: • 113 Supply Chain Management; dort erfolgt die Beurteilung der Leistungen, die durch die Partner erbracht werden. • 123 Program Control; übergeordnete Überwachung des Projektes im Rahmen des Programm-Managements. • 134 Product & Service Management; soweit es sich um eine Produktentwicklung handelt, wird dort der Entwicklungsstand verfolgt. • 162 QM-System überprüft periodisch auf Basis des Projektberichtes die Einhaltung der Qualitätsrichtlinien und -vorgaben. • 223 Contract Management überwacht unter anderem auf Basis des Projektberichtes die Vertragserfüllung.

29

P-Risiko = Projekt-Risiko, Risiko, das das Projekt gefährdet.

176

Prozessbereiche und Prozesskategorien

Die Erfahrung zeigt, dass die Bedeutung eines Projekt-Controllings jedem Manager und Projektleiter bewusst ist, dieses Thema in der Praxis aber oft vernachlässigt wird. Dabei zeigt sich auch, dass die Bereitstellung der Arbeitsgrundlage des Controllings, nämlich Informationen und Daten, meist äußerst stiefmütterlich gehandhabt werden. Professionelle ICT-Unternehmen, die mit der Realisierung von individuellen Kundenprojekten auch tatsächlich Geld verdienen wollen, kommen an einem intensiven Projekt-Controlling nicht vorbei. Jeder Umstand, der die Erreichung eines oder mehrerer Ziele oder gar des Gesamtzieles des Projektes gefährdet, stellt ein Projektrisiko30 dar. Diese Risiken müssen frühzeitig als solche identifiziert und kommuniziert werden. Weiter müssen entsprechende Maßnahmen, die den Eintritt der Risiken verhindern oder zumindest deren Auswirkungen mildern, definiert und ausgeführt werden. Projektrisiken gefährden primär die Zielerreichung des Projektes, müssen aber nicht zwingend ein Risiko für die Unternehmung darstellen. Beispiele für typische Risiken, die Projektziele gefährden, sind: • Ein Lieferant kann seine Termine nicht einhalten. • Ein Lieferant meldet Insolvenz an. • Eine vorgesehene Technologie steht nicht wie geplant zur Verfügung. • Eine vorgesehene Technologie beinhaltet Fehler, deren Behebung offen ist (typisch für Entwicklungsvorhaben). • Kunde fordert viele und z.T. massive Änderungen. • Zahlungsschwierigkeiten des Kunden etc. Der Prozess 313 Project Risk Management deckt das spezifische RisikoManagement auf Projektebene ab. Der Prozess ist bzgl. seiner Aufgaben einfach strukturiert. So ist ein erkanntes bzw. vermutetes Risiko bzgl. seiner Eintrittswahrscheinlichkeit und der möglichen Konsequenzen zu prüfen. Es sind entsprechende Maßnahmen zu definieren und gegebenenfalls einzuleiten. Es ist zu prüfen, ob evtl. weitere neue Risiken aufgrund der

30

Im Modell als P-Risiko dargestellt.

Prozessbereich Project & Development

177

geplanten oder eingeleiteten Maßnahmen31 entstehen. Die Risiken sowie die Maßnahmen sind zu kommunizieren. Der Prozess wird durch die folgenden zwei Ereignisse ausgelöst: 1. P-Risiko erkannt ist ein Ergebnis der zwei Controlling-Prozesse, einerseits auf Projektebene: 313 Project Risk Management, andererseits auf Programm-Ebene: 123 Program Control. 2. Risikoanalyse erstellt ist ein Resultat des übergeordneten RisikoManagements (163 Risk Management). Hier können z.B. Informationen über Lieferanten und Kunden gemeldet werden, die Risiken für das Projekt beinhalten. Der Prozess erzeugt folgende Ergebnisse: 1. Risikoanalyse aktualisiert; das Hauptergebnis des Prozesses dient primär dem Berichtswesen und aktiviert die entsprechenden Aufgaben im Prozess 123 Program Control. 2. RFC formuliert; Maßnahmen, deren Umsetzung über das Change Management gesteuert werden müssen, werden als RFC in den Prozess 411 Change Handling eingebracht. 3. P-Change identifiziert; Maßnahmen, die Änderungen im Projekt bewirken, werden über den Prozess 314 Project Change Management koordiniert. 4. Partner-Risiko erkannt führt zu entsprechenden Folgeaktivitäten im Prozess 112 Supplier Contract Management. 5. Risiko erkannt; in diesem Fall ist davon auszugehen, dass ein Risiko eintreten kann, welches nicht nur das Projekt, sondern auch die Unternehmung gefährden kann. Dabei handelt es sich primär um Risiken mit finanziellen und / oder vertraglichen Hintergründen. Diese Risiken werden im Prozess 163 Risk Management bearbeitet. Jeder Umstand, der die Erreichung eines oder mehrerer Ziele, oder gar des Gesamtzieles des Projektes gefährdet, stellt ein

31

Echte Projektrisiken sind selten durch einfache Maßnahmen zu verhindern bzw. deren Auswirkungen zu beseitigen. Oftmals ist es eher ein Abwägen vieler Möglichkeiten und Konsequenzen mit der Gefahr, dass eine vermeintliche Lösung neue Risiken birgt.

178

Prozessbereiche und Prozesskategorien

Projektrisiko dar. Die offene und transparente Darstellung der Projektrisiken bindet bei Eintritt eines Risikos den Auftraggeber sowie die Kontrollorgane des Projektes (z.B. Lenkungsausschuss) mit in die Verantwortung ein. „Nichts in der Geschichte ist beständiger als der Wandel32„ – dies gilt insbesondere auch für Projekte. Je größer ein Projekt und je länger seine Laufzeit, desto umfangreicher ist die Anzahl der Änderungswünsche, -forderungen und -anträge, die an ein Projekt gestellt werden. Allein die Tatsache, dass ein Projekt grundsätzlich Änderungen akzeptieren und integrieren muss, stellt für uns bereits ein Projektrisiko dar. Insbesondere die Änderungen, die die ursprünglichen Projektziele, seien sie nun inhaltlicher, finanzieller oder zeitlicher Natur beeinflussen, erfüllen dieses Kriterium. Aus diesem Grunde ist es zwingend notwendig, dass bereits sehr frühzeitig33 ein für alle am Projekt Beteiligten verbindliches Verfahren für den Umgang mit Änderungen aller Art etabliert wird. Die Rahmenbedingungen eines solchen Verfahrens sind: 1. Jede Änderung wird als Antrag formuliert. 2. Jede Änderung wird dokumentiert. 3. Jede Änderung wird bzgl. ihrer Auswirkungen und Konsequenzen beurteilt. 4. Jede Änderung durchläuft ein Genehmigungsverfahren. 5. Jeder Änderungsentscheid wird dokumentiert. Der Prozess 314 Project Change Management bildet in unserem Referenz-Prozessmodell dieses Verfahren für den Umgang mit Projekt-Changes ab und wird von zwei Ereignissen angestoßen: 1. P-Change identifiziert; ein Projekt-Change bzw. eine Änderungsanforderung kann einerseits vom Auftraggeber kommen oder Ergebnis der Aktivität eines anderen Prozesses sein. In unserem Modell haben wir drei Prozesse, die ein entsprechendes Ergebnis liefern: 32

Das Zitat wird Charles Darwin (1809 –1892), dem englischen Naturforscher, zugeschrieben; er begründete die als Darwinismus bekannte Abstammungslehre (Evolutionstheorie).

33

Bei sehr großen Projekten mit langen Angebotszyklen und Vertragsverhandlungen heißt „frühzeitig“: mit der Abgabe des ersten Angebotes.

Prozessbereich Project & Development

179

• 312 Project Control; so kann das Projekt-Controlling z.B. zu dem Ergebnis kommen, dass die Termine nicht wie geplant eingehalten werden können oder dass bestimmte Ergebnisse nicht wie vereinbart realisiert werden können. • 313 Project Risk Management; Maßnahmen, die getroffen werden, um den Eintritt eines erkannten Risikos zu verhindern oder bei dessen Eintritt die Konsequenzen aufzufangen, können zu einem Projekt-Change führen. (Beispiel: Ein Lieferant hat angekündigt, dass er eine von ihm entwickelte und im Projekt vorgesehene Software vom Markt nimmt, es muss nun auf eine andere Software gewechselt werden.) • 411 Change Handling; ein im Change Management vorliegender RFC hat bei seiner Umsetzung Auswirkungen auf das Projekt oder betrifft das Projekt direkt (Beispiel: Es erfolgt eine Veränderung der IT-Sicherheits-Standards, jedes laufende IT-Projekt muss diese zwingend implementieren). 2. P-Change Antrag entschieden; die Entscheidungskriterien und die -organisation für die Genehmigung einer beantragten Änderung ist im Verfahren zu regeln. Grundsätzlich gibt es Änderungen, die in der Entscheidungsbefugnis der Projektleitung liegen. Ebenso wird es aber auch Änderungsanträge geben, die außerhalb des Projektes entschieden werden müssen. Dies betrifft insbesondere Änderungen, die finanzielle Auswirkungen haben oder die vertraglichen Vereinbarungen betreffen. Diese übergeordnete Entscheidung haben wir in unserem Referenz-Prozessmodell in den Prozess 123 Programm Control gelegt. Der Prozess 314 Project Change Management gliedert sich in zwei Abschnitte. Im ersten werden der Projekt-Change konkretisiert, die Auswirkungen und Konsequenzen geprüft und die Entscheidung beantragt. Ist die Entscheidung gefallen, wird diese dokumentiert und im Fall der Umsetzung die entsprechenden Aktivitäten hierzu eingeleitet. Ergebnisse des Prozesses sind: 1. P-Change-Antrag gestellt; kann der Antrag auf Projektebene entschieden werden, wird kein weiterer Prozess angestoßen. Liegt die Entscheidung außerhalb der Kompetenz des Projektes, aktiviert das Ereignis den Prozess 123 Programm Control, der die Prüfung und Genehmigung des Antrages regelt.

180

Prozessbereiche und Prozesskategorien

2. RFC-formuliert; eine Änderung kann auch Einfluss auf das Umfeld nehmen – die damit verbundenen Aktivitäten sind im Prozess 411 Change Handling geregelt (Beispiel: Die Schnittstelle eines anderen Systems muss aufgrund der Änderung angepasst werden oder Installationstermine verschieben sich). 3. Planungsauftrag erteilt; handelt es sich um komplexere und aufwändigere Änderungen, müssen diese gemäß Prozess 311 Project Planning geplant und beauftragt werden. 4. P-Change Antrag abgelehnt; dieses Ergebnis ist selbsterklärend. In unserer Projektpraxis versuchen wir sehr restriktiv mit Änderungsanträgen umzugehen. Speziell in IT-Projekten setzen wir meist folgende Regelung durch: Das laufende Projekt realisiert das Release 1.0 auf der Basis des vereinbarten Leistungsumfangs. In der Planung wird bereits ein Korrektur / Ergänzungs-Release, welches x Monate nach Einführung des Release 1.0 implementiert wird, berücksichtigt. Weiter wird damit verbunden ein Release Management eingeführt, das die Weiterentwicklung der Lösung steuert und parallel die Planung für das Release 2.0 beginnt. Änderungsanträge, die angenommen werden (müssen), werden dem Release Management unterstellt. Es können dann drei Entscheidungen getroffen werden: Die Änderung muss im Release 1.0 (laufendes Projekt) berücksichtigt werden, sie wird im Release 1.1 oder im Release 2.0 berücksichtigt. Mit diesem Verfahren gelingt es i.d.R. sehr gut, die Auswirkungen von Änderungen im laufenden Projekt unter Kontrolle zu halten. Ein Projekt endet mit der Abnahme des Ergebnisses durch den Kunden. Im einfachsten Fall, wie ihn z.B. der Abschluss einer Konzeptionsarbeit darstellt, durch die protokollierte Übergabe der Ergebnis-Dokumentation. Werden Systeme entwickelt, werden diese i.d.R. durch mehrer Test- und Abnahmezyklen und schließlich durch eine so genannte Endabnahme abgenommen. Die Abschlussphase eines Projektes ist im Prozess 315 Project Finalisation geregelt, der durch die folgenden zwei Ereignisse angestoßen wird: 1. Technische Abnahme erfolgt; in diesem Fall wurde ein System entwickelt und die diversen Abnahmetests des Prozesses 333 Operations Acceptance Test wurden erfolgreich absolviert. Das System steht damit zur Endabnahme bereit.

Prozessbereich Project & Development

181

2. Konzeptergebnis erarbeitet schließt den Prozess 321 Conceptual Design ab und die Abschlussdokumentation (der Beratungsleistungen, der Konzeptarbeiten, der Studien oder eines Gutachtens) liegt vor und kann dem Kunden präsentiert und abgegeben werden. Die Abnahme der Leistungen ist abhängig von der Art des Ergebnisses und den vertraglich vereinbarten Abnahmekriterien. Werden bei der Abnahme Mängel festgestellt, führt dies zu Nacharbeiten. Diese können je nach Projektgröße selbst Größenordnungen erreichen, die ohne Projektorganisation nicht realisierbar wären: • Handelt es sich um kleinere und überschaubare Nacharbeiten, kann sofort der Realisierungsauftrag erteilt werden, womit die „Herstellungsprozesse“ 321 Conceptual Design oder 322 System Development angestoßen werden. • Sind die Nacharbeiten so umfangreich, dass ein Planungsauftrag erteilt werden muss, werden die dafür notwendigen Aktivitäten im Prozess 311 Project Planning angestoßen. Ist der Auftraggeber mit der Leistung zufrieden, wird das System bzw. die Abschlussdokumentation abgenommen. Das Projekt wird formell abgeschlossen, wobei evtl. vorgängig noch ein Qualitäts-Audit durchgeführt wird; das Know-how bzw. die Projekterkenntnisse werden gesichert und alle Dokumente und Ergebnisse des Projektes werden archiviert. Im Rahmen dieser Aktivitäten entstehen folgende Ergebnisse: 1. Projekt abgenommen; das angestrebte Schlussergebnis, das sowohl der Kunde als Auftraggeber als auch das Management der ICTUnternehmung als Auftragnehmer gerne entgegennimmt. 2. Q-Audit beantragt; oftmals wird gerade bei größeren Projekten nochmals ein abschließendes Qualitätsaudit (Prozess 161 Audit & CIP) durchgeführt. Ist der Audit-Bericht erstellt (Eingangsereignis), kann der formelle Abschluss des Projektes fortgesetzt werden. 3. Verbesserung vorgeschlagen; aus den Projekterfahrungen können Verbesserungsvorschläge abgeleitet werden, die im kontinuierlichen Verbesserungsprozess (161 Audit & CIP) weiterbearbeitet werden. 4. Verrechnungsdaten zusammengestellt; für die Endabrechnung im Prozess 141 Service Charging. 5. Projekt abgeschlossen; selbsterklärend.

182

Prozessbereiche und Prozesskategorien

In der Praxis werden die Projekte nicht immer vollständig abgeschlossen. Oft löst sich das Projektteam noch vor dem definitiven Ende des Projektes auf, da die Ressourcen an anderer Stelle benötigt werden. Mit der Projektübergabe an den Kunden oder an den Betrieb ist das Projektteam aber noch nicht aus der Verantwortung entlassen. Insbesondere die Archivierung von vertragsrelevanten Dokumenten und die Sicherstellung der Nachvollziehbarkeit bestimmter Beschlüsse, des Schriftverkehrs und insbesondere von E-Mails, kann für spätere Reklamationen, Garantiefälle und sonstige geltend gemachte Ansprüche entscheidend sein!

ICT Consulting & System Development Eine Vielzahl von Dienstleistungen, die eine ICT-Unternehmung erbringt, ist aufgrund ihrer Auftragsart in Form eines Projektes zu erbringen und abzuwickeln. Im Prozessbereich Project & Development werden die Prozesse behandelt, die für eine projektorientierte Auftragsabwicklung benötigt werden. Im Vordergrund steht die oben beschriebene Projektabwicklung an sich, wobei diese aber keinen Bezug zu den zu erbringenden Inhalten hat. In der Prozesskategorie ICT Consulting & System Development wird nun der Bezug zu den inhaltlichen Leistungen hergestellt. Es werden zwei Hauptgruppen unterschieden: • Leistungen ohne Gewerk-Charakter, deren Ergebnisse i.d.R. in Form von Dokumenten („Paperware“) erbracht werden. Hierzu gehören z.B. Beratungsleistungen, Konzepte, Studien, Gutachten etc. • Leistungen mit Gewerk-Charakter: das Ergebnis besteht aus einem oder mehreren Werken. Hierzu gehört z.B. die Entwicklung von Individual- und Standardsoftware, die Parametrisierung und Implementierung von Standard-Software-Lösungen, die Implementierung von Netzwerken, die Entwicklung von Hardware oder Gesamtsystemen (Soft- und Hardware) etc. Gerade für die System- bzw. Software-Entwicklung gibt es eine Vielzahl verschiedener Verfahren und eine umfangreiche Fachliteratur. Wir beschränken uns hier im Wesentlichen auf die Schnittstellen zu den jeweiligen Prozessen, die den logischen Zusammenhang zu den anderen Prozessen des ICT-Unternehmens sicherstellen.

Prozessbereich Project & Development

183

Abb. 89. ICT Consulting & System Development Management

Die konzeptionellen Leistungen ohne Gewerk-Charakter werden über den Prozess 321 Conceptual Design abgewickelt. Der Prozess wird von zwei Ereignissen angestoßen: 1. Realisierungsauftrag erteilt; in diesem Fall werden die zu erbringenden Leistungen in einem dafür beauftragten Projekt erbracht, das nur „konzeptionelle Lösungen“ beinhaltet. D.h., das Prozessergebnis Konzeptergebnisse erarbeitet ist das Endergebnis, das der Kunde beauftragt hat und erhält. Die Abnahme des Ergebnisses erfolgt im Prozess 315 Project Finalisation. Das Ereignis Realisierungsauftrag erteilt ist ein Ergebnis des Prozesses 331 Project Planning (ursprünglicher Auslöser Projektauftrag freigegeben) oder 315 Project Finalisation (wenn Nachbesserungen zu liefern sind). 2. Konzeptauftrag formuliert; dieses Ereignis tritt ein, wenn ein anderer Vorgang eine Konzeption z.B. im Sinne einer Vorstudie benötigt, um z.B. das weitere Vorgehen zu entscheiden. Dies ist der Fall, wenn das Ereignis ein Ergebnis der folgenden Prozesse ist:

184

Prozessbereiche und Prozesskategorien

• 411 Change Handling; liegt ein RFC vor, dessen Auswirkung und Umfang analysiert werden müssen, kommt es zu diesem Auftrag. Dies hat zur Folge, dass mit Eintritt des Ereignisses Konzeptergebnis erarbeitet die Aktivitäten im Prozess 411 Change Handling fortgesetzt werden. • 311 Project Planning; liegt ein Projektvorschlag vor, muss dieser evtl. durch eine vorgängige Analyse detailliert und konkretisiert werden. Das Ergebnis Konzeptergebnis erarbeitet dient in der Folge im Prozess 311 Project Planning dazu, den Inhalt und den Umfang des Projektes, das vorgeschlagen wurde, zu definieren. • 331 Release Planning; im Rahmen der Release-Plannung, z.B. zwecks Weiterentwicklung einer Software-Applikation, kann der Bedarf nach einem Lösungsvorschlag dazu führen, dass ein Konzeptauftrag formuliert wird. Das Ergebnis Konzeptergebnis erarbeitet aktiviert in der Folge im Prozess 331 Release Planning die Prozessaktivitäten, die über die Aufnahme des Lösungsvorschlages in eines der nächsten Releases entscheidet. Für viele ICT-Unternehmen sind Einstiegsaufträge bei Neukunden oft „konzeptionelle Leistungen ohne Gewerk-Charakter“. Viele Großaufträge mit Gewerk-Charakter wie z.B. Individual-Software-Entwicklungen sind nur zu akquirieren, wenn bereits im Vorfeld der Auftragsvergabe konzeptionelle Leistungen erbracht wurden. In vielen ICT-Unternehmen besteht für diese Arbeiten ein Ressourcenengpass. So werden neben einem speziellen Know-how auch konzeptionelle und kreative Fähigkeiten benötigt, die nicht selbstverständlich sind. Leistungen mit Gewerk-Charakter stellen für ICT-Unternehmen hinsichtlich Komplexität und Risiko die wohl anspruchvollsten Projekte bzw. Aufträge dar. Grundsätzlich sind mit jedem Gewerk Garantieleistungen verbunden, die bei der Lösungskonzeption und der Qualitätssicherung sowie vor allem auch bei der Kalkulation zu berücksichtigen sind. Das klassische Beispiel für solch einen Auftrag ist die Individual-Software-Entwicklung im Kundenauftrag. Der Prozess 322 System Development bildet auf der Ebene der Aktivitäten klassische Entwicklungsphasen für ein IT-System ab. Der Prozess wird ausschließlich von einem Ereignis ausgelöst: Realisierungsauftrag erteilt. Es

Prozessbereich Project & Development

185

resultiert einerseits aus dem Prozess 311 Project Planning und andererseits – in den Fällen, in denen Nacharbeiten notwendig sind – aus 315 Project Finalisation oder 333 Operations Acceptance Test. Es kann außerdem im Notfall eintreten, wenn über das Release Management (331 Release Planning) ein „Bugfix“, also eine dringende Fehlerkorrektur, angefordert wird. Typische Ergebnisse des Prozesses 322 System Development sind folgende: • Neuer CI-Basis-Type benötigt oder Neuer-CI-Struktur Typ aktivieren beide den Prozess 434 CI-Type-Engineering. Treten diese Ereignisse während der Entwicklung auf, fehlt in der Configuration Management Database (CMDB) eine Datenstruktur für ein neues Configuration Item, welches dann in diesem Prozess erzeugt wird. • CI geändert; während der Entwicklung werden neue Configuration Items angelegt oder bestehende verändert. Dieses Ergebnis löst die Prozesse 432 CI-Verification und 433 CI-Dokumentation aus. • Einführungsschulung beantragt; müssen Anwender geschult werden, wird über diesen Prozess das 311 Project Planning angestoßen, welches die Einführungsschulung plant und beauftragt. • Plattformangebot aktualisiert; mit der Neuentwicklung wird die bestehende IT-Plattform erweitert bzw. ergänzt. Im Prozess 711 Contingency Planning wird überprüft, welche Maßnahmen aufgrund der Ergänzung / Erweiterung notwendig sind, um die mit der Entwicklung verbundenen Geschäftsprozesse auch bei einem Notfall weiter betreiben zu können. • Systemabnahme bereit stellt das Ende des Entwicklungsprozesses dar und das System geht in die Abnahmeprozeduren 333 Operations Acceptance Test und, wenn dieser erfolgreich durchlaufen wurde, 315 Project Finalisation. In einer mittleren ICT-Unternehmung können schnell einmal mehrere „Projekte“ parallel laufen. Das Besondere hierbei ist, dass die direkt damit verbundenen „Realisierungsprozesse“, nämlich die des Prozessbereiches ICT Consulting & Development, quasi für jedes Projekt existieren und somit x-mal in der Organisation in mehreren Organisationseinheiten abgebildet sind. Im Gegensatz hierzu sind die Prozesse der anderen Prozessbereiche i.d.R. genau einer Organisationseinheit zugeordnet.

186

Prozessbereiche und Prozesskategorien

ICT Release Management Mit der erstmaligen Entwicklung und Einführung eines IT-Systems wird gleichzeitig auch das erste produktive Release (Quasi die Version 1.0) dieses Systems bereitgestellt. Grundsätzlich kann und wird das ReleaseVerfahren auf alle Configuration Items angewendet, welche nach ihrer Erstellung oder nach einer Änderung getestet und in die Betriebsumgebung eingeführt wurden. Ein Release-Verfahren entspricht einem spezialisierten Entwicklungsvorhaben, welches darauf spezialisiert ist, • Vorgängerversionen weiterzuentwickeln, • deren Austausch im laufenden Betrieb so zu gestalten, dass es für die unterstützten Geschäftsprozesse wie für die Nutzer möglichst unbemerkt geschieht, • je größer die Verbreitung (Anzahl der Installationen) ist, den parallelen Betrieb und Support mehrerer Versionen eines Releases zu gewährleisten. Bei der Weiterentwicklung eines Releases handelt es sich um ein Entwicklungsvorhaben. Entwicklungsvorhaben sind projektorientiert und unterliegen damit, zumindest in unserem Modell, der Kontrolle des Projekts und des übergeordneten Programm-Managements. Dadurch, dass ein Release in der Praxis immer eine Kombination vieler verschiedener Objekte (Configuration Items) ist, kommt der ReleaseBildung, also dem Zusammenführen der jeweiligen einzelnen Komponenten, die in ihrer Gesamtheit das Release ausmachen, besondere Bedeutung zu. Das Release Management umfasst für uns viele Entwicklungsfunktionen, die bis zum koordinierten Rollout eines Releases reichen. Die wichtigsten Funktionen eines Release Managements umfassen: • Weiterentwicklung und die dazu gehörige Planung der „Folge-Releases“, • Bildung von Release-Packages, • Test und Abnahme bzgl. der Betriebsfähigkeiten und technischen Freigabe unter der Berücksichtigung der Sicherheitsaspekte eines Release, • Verwaltung und Überwachung der verschiedenen Release-Versionen unter Verwendung entsprechender Datenbanken wie der Configuration Management Database und einer Definitive Software Library,

Prozessbereich Project & Development

Abb. 90. ICT Release Management

187

188

Prozessbereiche und Prozesskategorien

• Planung des Rollouts und Sicherstellung der Implementation ausschließlich getesteter und freigegebener Release-Versionen. Schnittstellen des Release-Management-Prozesses bestehen vor allem zu den Prozessen des Projekt-Managements sowie zu den Entwicklungsprozessen im Zusammenhang mit der Weiterentwicklung eines Releases. Im Rahmen der Release-Bildung und des folgenden Rollouts sind Schnittstellen zum Configuration- und zum Change Management vorhanden. Soweit im Rahmen des Rollouts ein Vor-Ort-Einsatz notwendig ist, bestehen Schnittstellen zum On-Site-Service. Die Prozesskategorie „ICT Release Management“ bildet die Prozesssicht auf diese Thematik ab. Insgesamt fünf Prozesse sind dem Release Management zugeordnet: • 331 Release Planning regelt und steuert die Weiterentwicklung. • 332 Release Package Management regelt und steuert den Rollout sowie die Verwaltung der Release-Packages. • 333 Operations Acceptance Test beinhaltet die technische Abnahme und Betriebsbereitschaft eines Systems / Releases. • 334 Distribution Planning regelt und steuert die Verteilung von Hardund Software. • 335 HW / SW Distribution beinhaltet die Auslieferung von Hard- und Software. Das Release Management ist ein spezialisiertes Entwicklungsvorhaben, das quasi den Lebenszyklus eines auf einer Vielzahl von Einzelkomponenten basierenden Systems nach dessen erstmaligen Inbetriebnahme regelt und steuert. Es umfasst alle Aktivitäten der Planung, der Entwicklung, der Tests und der Abnahme, des Rollouts und der Inbetriebnahme. Außerdem stellt es sicher, dass mehrere Release-Versionen parallel implementiert sein können und deren Betrieb und Support sichergestellt ist. Bei einer Weiterentwicklung eines sich bereits im Betrieb befindlichen oder am Markt platzierten Produktes sind die Voraussetzungen bzgl. Auftragserteilung, Budget, Terminen und Risiken etc. gegenüber einer Neu- bzw.

Prozessbereich Project & Development

189

Erstentwicklung eines Systems wesentlich einfacher. Dieses „vereinfachte“ Umfeld hat eine Vielzahl von Konsequenzen: • Manche Softwarehäuser, die für ihre Kunden Individual-Software entwickeln, berücksichtigen dies in ihrer Angebotskalkulation bzw. Risikoanalyse für eine Erst- bzw. Neuentwicklung. Sie können davon ausgehen, dass der Kunde mit der Erteilung eines Auftrages eine Bindung eingeht, die dem Softwarehaus Folgeaufträge für Weiterentwicklungen und Unterhalt beschert. Diese weisen minimale Vertriebskosten auf, die Risiken sind bekannt und die eigenen Preise lassen sich problemlos durchsetzen. Somit kann ein Erstauftrag durchaus nur kostendeckend oder sogar mit einem bewussten Verlust angeboten werden, da die Gewinne auf der Basis der Folgeprojekte kalkuliert werden. • Ist erst einmal ein Produkt, z.B. eine Standard-Software, am Markt platziert und werden damit Einnahmen generiert, ist die Budgetierung und Freigabe der Weiterentwicklungsaktivitäten, zumindest zu Beginn des Product Lifecycles, kein Problem mehr, da das Investitionsrisiko für das Management nun wesentlich einfacher abzuschätzen ist als in der Phase der Produktentwicklung. • Auch die Projektorganisation und der Ressourcenbedarf gestalten sich bei der Weiterentwicklung eines Releases im Vergleich zur Erstentwicklung einfacher. Oft sind ja nur Korrekturen, Ergänzungen und Erweiterungen des Systems zu realisieren. Die Basisarchitektur bleibt meist erhalten, sodass die Erweiterungen mit geringem Aufwand und hoher Fehlertoleranz entwickelt werden können. Natürlich weisen Weiterentwicklungen auch Risiken auf. Fast jeder hatte schon ein Hardware-Produkt, mit dem er eigentlich sehr zufrieden war und von dessen Weiterentwicklung er enttäuscht wurde. Ein schönes Beispiel ist der heikle Bereich der Stromversorgung auf der Basis eines Akkus. Jeder Hersteller versucht im Rahmen der Weiterentwicklung natürlich auch die Herstellungskosten zu minimieren. Oft werden hierzu bewährte Elemente wie z.B. Akkus durch eine kostengünstigere Lösung ausgetauscht. Können diese dann im Betrieb nicht die vom Markt geforderte Qualität bringen, kann das fatale Folgen haben. In der Praxis hat es sich bewährt, Release-Vorhaben nach ihrer Wichtigkeit, dem Umfang, den Inhalten und anderen Kriterien zu untergliedern. Mit der daraus resultierenden Gruppierung können für jede Gruppe die zu erfüllenden Rahmenbedingungen oder Steuerungsvorgaben definiert wer-

190

Prozessbereiche und Prozesskategorien

den, die sich auch direkt auf die Prozesse im Release Management auswirken (z.B. dass bestimmte Aufgaben übersprungen werden dürfen). Oft wird auch im Rahmen der Versionierung die Art des Releases zwecks eindeutiger Identifikation eines Releases in der Versionsnummer abgebildet. ITIL schlägt eine weit verbreitete Untergliederung in 3 Gruppen vor: • Major Releases (Hauptrelease) beinhalten typischerweise komplexe, funktionelle sowie technische Weiterentwicklungen. Es handelt sich quasi um die Maximalvariante, was auch die damit verbundenen Regelungen und Prozesse betrifft (Beispiel Versionsnummer: Buchungssystem Version 1.0, 2.0, 3.0 usw.). • Minor Releases (Zwischenrelease) weisen typischerweise einfache funktionelle Erweiterungen auf, oftmals aber auch Korrekturen von erkannten, aber nicht kritischen Fehlern. Bestimmte Anforderungen und Regeln, die für Major Releases gelten, sind hier aufgehoben. Minor Releases werden quasi in einem vereinfachten Verfahren realisiert (Beispiel Versionsnummer: Buchungssystem Version 1.1, 1.2, 1.3 …). • Emergency Fixes (Notfall- oder Korrektur-Release) beinhalten vor allem so genannte „Bugfixes“, also die Korrekturen erkannter und behobener Fehler. Notfälle haben, vor allem was die Zeitabläufe betrifft eigene, auf Geschwindigkeit ausgelegte Regeln (Beispiel Versionsnummer: Buchungssystem Version 1.1.1, 1.1.2, 1.1.3 …). Notfall-Lösungen sind darauf angelegt, eine schnelle Lösung zu ermöglichen. Aus diesem Grunde werden oft inhaltlich sinnvolle Tätigkeiten reduziert (z.B. Test und Abnahme) oder übersprungen (z.B. Dokumentation). Weiter werden die Entscheidungswege verkürzt oder ebenfalls übersprungen. Dies ist allerdings nur dann akzeptabel, wenn gleichzeitig sichergestellt ist, dass alle reduzierten oder übersprungenen Tätigkeiten nach der Implementierung der Notfall-Lösung nachgeholt werden. Die Weiterentwicklung eines Releases wird im Prozess 331 Release Planning koordiniert. Das Release Planning besteht aus einer Reihe von Teilprozessen, die durch die folgenden Ereignisse angestoßen werden:

Prozessbereich Project & Development

191

• Periodisch; Releasezyklen für funktionale Erweiterungen und technische Upgrades werden normalerweise durch den Kunden oder durch das Produkt-Management vorgegeben. Typisch hierfür ist ein halbjähriger oder jährlicher Turnus. Im Rahmen der periodischen Planung werden Inhalt und Umfang sowie die Rollout-Termine des nächsten Releases definiert und die Detailplanung beauftragt. Falls notwendig, werden Konzeptaufträge formuliert und beauftragt. • R-Change34 identifiziert; die Analyse eines RFC kann dazu führen, dass ein System, das dem Release Management untersteht, verändert werden muss. Die Änderungsanfrage muss analysiert und priorisiert werden, weiter muss auf der Basis eines Konzeptes ein Lösungsvorschlag erarbeitet werden. • Konzeptergebnis erarbeitet; im Rahmen der periodischen Planung oder ausgelöst durch das Change Management werden Erweiterungen, Ergänzungen, Korrekturen etc. definiert, für die vorgängig konzeptionelle Lösungsvorschläge erarbeitet wurden. Liegen diese vor, können sie beurteilt und in die Planung eines der nächsten Releases integriert werden. • Projektplan aktualisiert; hiermit liegt die Detailplanung der anstehenden Entwicklungsaufgaben, erstellt vom 311 Project Planning und überwacht vom ICT Program Management, vor. Das nächste Release kann nun definitiv bzgl. Inhalt und Umfang sowie Einführungstermin definiert werden, da entsprechende Entwicklungsprojekte vorgeschlagen bzw. beauftragt wurden. Die Ergebnisse des Projektes sind vor allem Planungsergebnisse, deren Ereignisse primär mit der Planung und der Beauftragung der notwendigen Entwicklungstätigkeiten in Verbindung stehen: • Konzeptauftrag erteilt; werden im Rahmen der Planung der nächsten Release-Inhalte konzeptionelle Lösungsvorschläge benötigt, löst dieses Ereignis die entsprechenden Aufgaben im Prozess 321 Conceptual Design aus. • Planungsauftrag erteilt; entspricht quasi dem ordentlichen Verfahren; die Inhalte sind provisorisch definiert und in der Folge wird im Prozess 311 Project Planning die Realisierung inkl. der notwendigen Ressourcen geplant und budgetiert. 34

R-Change: Release Change, eine Veränderung die ein Release betrifft.

192

Prozessbereiche und Prozesskategorien

• Releaseplanung aktualisiert; handelt es sich bei dem Release um ein Verkaufsprodukt, aktiviert dieses Ereignis im Prozess 211 Sales Management die Verkaufsaktivitäten. • Projekt vorgeschlagen; wurde der Realisierungsplan geprüft, wird die Realisierung in Form eines Projektes vorgeschlagen. Dies führt im Prozess 311 Project Planning zum Projektantrag und nach dessen Bewilligung durch das Programm-Management zum Realisierungsauftrag. • Realisierungsauftrag erteilt; hierbei handelt es sich um einen Ausnahmefall, der die Realisierung eines „Emergency Release“ im Prozess 322 System Development auslöst. (Der ursprüngliche Auslöser hierzu findet sich z.B. im Incident Management, das einen RFC auslöst. Dies wiederum wird im Change Management dahingehend interpretiert, dass evtl. ein „Bugfix“ (R-Change identifiziert) realisiert werden muss). Auf die funktionalen Inhalte der Release-Planung nehmen vor allem drei Gruppen Einfluss: Der Kunde (bei IndividualSoftware-Lösungen die treibende Kraft), der Vertrieb und das Produkt-Management. Bei den technischen Inhalten kommen zusätzlich noch der Betrieb und der Support hinzu. Zum Abschluss der Systementwicklung wird das System auf seine betriebliche Tauglichkeit hin getestet, abgenommen und für die Implementierung freigegeben. Nach der Abnahme wird im Prozess 431 System Configuration das Release-Package konfiguriert. Dieses Ereignis löst den Prozess 332 Release Package Management aus. Hier wird der Rollout geregelt und gesteuert sowie die verschiedenen Release-Versionen mit Hilfe einer Software Library35 verwaltet. Periodisch wird vor allem die Anzahl der Installationen der verschiedenen Release-Versionen überwacht. Da es durchaus möglich ist, dass mehrere Release-Versionen parallel produktiv sind, entscheidet unter anderem die Anzahl der Installationen, wann eine Release-Version definitiv archiviert und damit auch aus dem Betrieb und dem Verkauf genommen wird sowie der Support eingestellt wird. 35

ITIL verwendet hier die Bezeichnung Definitive Software Library (DSL). Die DSL beinhaltet die getesteten, abgenommenen und für den Betrieb freigegebenen Release-Versionen. Software-Installationen erfolgen nur mit Software, die in der DSL abgelegt ist bzw. von dieser bezogen wird.

Prozessbereich Project & Development

193

Die Ergebnisse der Rollout-Planung sind: • Change geplant; ein Rollout erfolgt unter der Kontrolle des Change Managements, das Ereignis löst den Prozess 412 Change Planning & Control aus. • Schulung beauftragt; sind Schulungen von Anwendern oder Service Mitarbeitern notwendig, wird dies im Prozess 641 Education Training Planning geplant und organisiert. • Distributionsauftrag erteilt; damit wird die eigentliche Ausbreitung, der Rollout des Releases im Prozess 334 Distribution Planning initialisiert. Die Release-Verwaltung führt zu folgenden Ergebnissen: • Release produktiv; bei einem Sofware-Release wurde eine ReleaseVersion in die Definitive Software Library eingestellt und steht für die Auslieferung, z.B. im Rahmen eines Rollouts oder – bei einer Standard-Software – im Rahmen einer Bestellung zur Verfügung. Handelt es sich um ein Gesamtsystem (Hard- & Software) oder ausschließlich um Hardware, stehen die technischen Spezifikationen36 für die Bestellung zur Verfügung. • Release archiviert; die archivierte Release-Version steht für die Installation bzw. für den Verkauf nicht mehr zur Verfügung. • CI geändert; Informationen zu einer Release-Version oder einer Komponente von ihr wurden geändert. Das Ereignis löst die Prozesse 432 CI-Verification und 433 CI-Documentation aus. Der hohe Grad der Automation, der heute im Bereich des Release Managements bereits erreicht wurde, ist sehr gut bei einer Vielzahl von PC-Software-Produkten zu erkennen. So prüft die Software auf Basis einer Internet-Verbindung die Aktualität der genutzten Software. Steht nun eine aktualisierte Version zur Verfügung, wird der Nutzer aufgefordert, ein automati-

36

Im Gegensatz zu einem reinen Software-Produkt, dessen Herstellung bereits abgeschlossen ist und für dessen Verkauf lediglich eine Kopie hergestellt werden muss, werden Systeme mit Hardware-Anteilen oft erstmals auf Basis einer Bestellung gefertigt.

194

Prozessbereiche und Prozesskategorien

siertes Update vorzunehmen. Nicht nur, dass der Hersteller hiermit einen recht guten Überblick über die Verteilung der diversen Release-Versionen erhält, er kann durch das automatische Update auch seine Service-Qualität verbessern und die Service-Kosten senken. Außerdem kann er bei einem kostenpflichtigen Update eine sehr kostengünstige und wirksame Verkaufsaktion durchführen. Jede Erst- bzw. Weiterentwicklung eines Systems muss, bevor sie für den Betrieb freigeben wird, ausführlich auf ihre betriebliche Tauglichkeit hin getestet werden. Diese Prüfung und Abnahme ist im Prozess 333 Operations Acceptance Test geregelt. Im Vordergrund steht die technische Abnahme hinsichtlich Stabilität, Performance, Sicherheit, Schnittstellen, Integration und Verhalten in verschiedenen Umgebungen. Die Prüfung der Funktionen, Anwenderfreundlichkeit etc. ist nicht Bestandteil und erfolgt im Fall einer Individual-Software-Entwicklung über den Prozess 315 Project Finalisation. Handelt es sich um ein für den Markt entwickeltes Produkt, ist das Produkt-Management für die Anwendungs- und Nutzungstests verantwortlich. Üblich ist hier, dass z.B. einer Auswahl von Anwendern so genannte Beta-Versionen zur Verfügung gestellt werden. Dieses Verfahren ist im Modell nicht abgebildet. Der Prozess 333 Operations Acceptance Test wird ausschließlich von dem Ereignis System abnahmebereit angestoßen, welches den Prozess 322 System Development abschließt. Die technische Abnahme besteht i.d.R. aus vielfältigen und umfassenden Tests, die längere Zeiträume benötigen können. Auch hier gilt: je größer, je komplexer das abzunehmende System, desto größer der Aufwand. In unserem Referenz-Prozessmodell haben wir folgende drei typische Ergebnisse berücksichtigt: • Technische Abnahme erfolgt; das gewünschte Endergebnis des Prozesses. Das abgenommene System kann gemäß der im Rahmen der Abnahme definierten und vorgegebenen technischen Spezifikation37 betrieben werden. Mit der Abnahme wird der Prozess 315 Project Finalisation angestoßen, mit dem das Entwicklungsprojekt als solches abgeschlossen wird. Weiter kann nun im Prozess 431 System Confi37

Hierbei handelt es sich z.B. um Mindestanforderungen, die an die Plattform, auf die ein System installiert werden soll, gestellt werden.

Prozessbereich Project & Development

195

guration ein so genanntes Release-Package konfiguriert oder ein Auslieferungspaket erstellt werden. • Realisierungsauftrag erteilt; in diesem Fall sind Nachbesserungen notwendig, deren Umfang abhängig von den erkannten Mängeln ist. Im äußersten Fall kann das ganze System zwecks Nachbesserung wieder in den Prozess 322 System Development zurückgeführt werden. • Technologie veraltet; dieses Ergebnis tritt dann auf, wenn das ICTUnternehmen das Produkt nicht nur entwickelt, sondern auch für seinen Auftraggeber den Betrieb in dessen oder auch in der eigenen ITInfrastruktur anbietet. Konkret bedeutet dies, dass bestimmte Komponenten der IT-Infrastruktur technologisch nachgerüstet oder ausgetauscht werden müssen, um den Betrieb oder die vollständige Nutzung des Systems sicherstellen zu können. Ein Beispiel: Das System nutzt als erstes die neueste Datenbankversion einer im Betrieb etablierten Datenbank-Software. Im Rahmen der technologischen Abnahme wird festgestellt, dass ein im Betrieb eingesetztes Monitoring System diese neue Version nicht unterstützt und entsprechend nachgerüstet werden muss. Dies wird dann im Prozess 431 Technology Management geregelt. Im vorhergehenden Kapitel wurden verschiedene mögliche Release-Arten beschrieben. Die mit diesen Release-Arten verbunden Rahmenbedingungen und Steuerungsvorgaben können auch direkt auf die Prozesse des Release Managements Einfluss haben. Ein Operations Acceptance Test ist von Natur aus umfangreich und oft langwierig. Im Fall eines Emergency Releases, welches Fehler im produktiven Betrieb beheben soll, wird ein schnelles und möglichst sicheres Freigabeverfahren benötigt. Emercency Releases müssen zwingend getestet und abgenommen werden, bevor sie in den produktiven Betrieb übernommen werden. So viel Zeit muss sein! Wenn es wirklich schnell und unkompliziert gehen soll, hat sich der „Expertentest“ bewährt. Hierzu beurteilt ein „Experte“, welche Risiken die vorgenommenen Änderungen oder Korrekturen haben könnten bzw. mit welchen Folgefehlern zu rechnen ist. Die Tests werden dann auf Basis dieser Annahmen gemacht. Nach der Einführung wird dann das übliche Test- und Abnahmeverfahren vollzogen.

196

Prozessbereiche und Prozesskategorien

Mit der Beauftragung des Rollouts im Prozess 332 Release Package Management wird der Distributionsauftrag erteilt. Dieser wird im Prozess 334 Distribution Planning umgesetzt. Hier wird die definitive Auslieferung geplant, vorbereitet und ausgelöst. Diese Aufgaben werden auch für Produkte, die Handelswarencharakter haben, benötigt. In diesem Fall ist das auslösende Ereignis Bestellung bestätigt, welches ein Ergebnis des Prozess 213 Order Management ist. Wird eine Bestellung storniert, muss der gesamte Auslieferungsprozess gestoppt werden. Da Rollouts der Kontrolle und Überwachung des Change Managements unterliegen, löst auch das Ereignis Change terminiert Aufgaben im Prozess 334 Distribution Planning aus. Ergebnisse des Distribution Planning sind: • Auslieferungspaket angefordert; wird für die Auslieferung ein physisches Auslieferungspaket38 benötigt, wird dies im Prozess 742 Material & Inventory Management bereitgestellt und in der Folge durch den Prozess 335 HW / SW Distribution ausgeliefert. • HW-System bestellt; existiert die bestellte bzw. zu liefernde Hardware noch nicht, sondern ist noch zu fertigen, dann wird hiermit die Fertigung gesteuert und über den Prozess 431 System Configuration ausgelöst. Nach der Fertigung wird dann das Auslieferungspaket bereitgestellt und in der Folge durch den Prozess 335 HW / SW Distribution ausgeliefert. • Change geplant; handelt es sich bei der vorgesehenen Auslieferung und der damit verbundenen Installation um ein Vorhaben, das vom Change Management überwacht werden muss, wird nach der Terminplanung mit diesem Ereignis der Change bzw. der damit verbundene Termin im Prozess 412 Change Planning & Control freigegeben oder neu terminiert. • On-Site-Einsatz notwendig; bedingt die Auslieferung eine Unterstützung vor Ort (z.B. Installation), wird diese in der Folge im Prozess 631 On-Site Dispatching organisiert. • Auslieferung freigegeben; mit diesem Ereignis wird die definitive Auslieferung im Prozess 335 HW / SW Distribution ausgelöst. 38

Hierunter sollte man sich ein reales Paket vorstellen. Dies könnte z.B. aus einer Kartonschachtel bestehen, die eine Hardware inkl. Styroporschutzelemente sowie Kabel, Dokumente etc. beinhaltet.

Prozessbereich Project & Development

197

• Lieferstatus gemeldet; im Fall eines Rollouts wird der Fortschritt des Rollouts im Prozess 312 Project Control überwacht. Wird reale Ware geliefert, erfolgt oftmals eine Abstimmung des Liefertermins mit dem Kunden oder zumindest eine Information bzgl. des vorgesehenen und tatsächlichen Versandes der Ware. Diese Tätigkeiten erfolgen im Prozess 621 Contact Management. Mit der definitiven Auslieferung der Ware im Prozess 335 HW / SWDistribution wird die Prozesskette von der Entwicklung eines Releases bis zu dessen Auslieferung und Verfügbarkeit beim Kunden abgeschlossen. Dieser Prozess wird von zwei Ereignissen beeinflusst: Zum einen ist das Auslieferungspaket bereitgestellt, die Auslieferung kann gemäß der für das jeweilige Paket geltenden Kriterien vorbereitet werden. Tritt zum anderen das Ereignis Auslieferung freigegeben ein, erfolgt die Auslieferung. Die Ergebnisse des Prozesses sind: • HW geliefert und SW geliefert; die Hardware bzw. Software wurde ausgeliefert. Handelt es sich um eine Lieferung, die direkt an den Kunden geht, hat er sie aus Sicht des Modells hiermit erhalten. Erfolgte die Bestellung im Rahmen einer Reparatur, lösen diese Ereignisse im Prozess 632 Repair Management die Reparatur aus. Wird die Ware vom ICT-Unternehmen vor Ort installiert, lösen die Ereignisse den Prozess 633 Installation & Relocation Management aus. • Lieferstatus gemeldet; im Fall eines Rollouts wird der Fortschritt des Rollouts im Prozess 312 Project Control überwacht. Wird Ware real geliefert, erfolgt hier die Meldung, dass die Ware ausgeliefert wurde. Diese Tätigkeiten erfolgen im Prozess 621 Contact Management. Speziell im Bereich der Software-Distribution sind die mit der Distribution verbundenen Prozesse zumindest ab dem Zeitpunkt der Bereitstellung der zu verteilenden Software und der Freigabe zur Verteilung hochgradig automatisiert. Der Kunde hat ein hohes Interesse daran, über den Stand seiner Bestellung bzw. den Verlauf der Lieferung informiert zu werden. Viele Unternehmen bieten heute ihren Kunden die Möglichkeit, den Status eines für sie bestimmten Objektes vom Auftrag über die Fertigung bis zur Auslieferung inkl. des Lieferweges zu verfolgen. Diese Transparenz schafft Vertrauen und reduziert nebenbei noch die Anfragen des Kunden, mit denen er sich über den aktuellen Stand informieren will.

198

Prozessbereiche und Prozesskategorien

Prozessbereich Support Im Referenz-Prozessmodell sind dem Prozessbereich Support drei Disziplinen zugeordnet, die auch heute noch in den meisten ICT-Unternehmungen bzw. ICT-Organisationen z.T. erhebliche Schwachstellen aufweisen. Es handelt sich hierbei um die Themen • Change Management, • Configuration Management und • Problem Management.

Abb. 91. Prozessbereich Support

Die hier behandelten Prozesse sind aus unserer Sicht Prozesse, die unabhängig von der Größe der ICT-Unternehmung zentral realisiert werden sollten. Einen Großteil der uns bekannten Praxisprobleme führen wir darauf

Prozessbereich Support

199

zurück, dass sich in diesen Themenbereichen – i.d.R. historisch bedingt – oft ein dezentralisierter Wildwuchs etabliert hat. Es empfiehlt sich, einmal einen Blick in andere Branchen zu werfen wie z.B. in den Anlagen-, Schiffs- oder Flugzeugbau. Hier unterscheiden sich die Anforderungen an die drei Prozesse Change-, Problem- und Configuration-Management nur unwesentlich von den Anforderungen an die gleichen Prozesse innerhalb des IT-Managements. Im Rahmen einer Maturity-Analyse39, die den organisatorischen Reifegrad der Prozesse nach gewissen Kriterien ermittelt, weist erfahrungsgemäß noch ein Großteil der ICT-Unternehmen in diesen Disziplinen vorwiegend niedrige Reifegrade aus. In den nächsten Jahren versprechen gerade die beiden erstgenannten Bereiche in vielen ICT-Unternehmen die größten Potenziale zur Optimierung und Produktivitätssteigerung. Vor allem die Funktionen und Abläufe des Change- und ConfigurationManagements sind selbst dann, wenn sie nicht systematisch organisiert sind, in irgendeiner Form in jeder ICT-Unternehmung per se vorhanden. Ihre konsequente, übergreifende Organisation gestaltet sich aufgrund vielfältiger Einflüsse als schwierig, aber nicht als unmöglich. Hierauf wird noch vertieft in den einzelnen Kapiteln eingegangen. Das systematische Problem Management hingegen muss gezielt aufgebaut und etabliert werden. Speziell in deutschsprachigen Unternehmen hat der Begriff „Problem Management“ eine andere Bedeutung als hier verwendet bzw. als in ITIL definiert. So wird der Begriff „Problem Management“ weit verbreitet mit der Bearbeitung von Störfällen gleichgesetzt. Die Trennung von „Incident Management“ (Störfallbearbeitung und -beseitigung) und „Problem Management“ (systematische Störfallanalysen und Behebung von Störungsursachen) setzt sich aber zunehmend, bedingt durch die Verbreitung von ITIL, durch. Was sind die Gründe dafür, dass ICT-Unternehmen vor allem in den Bereichen Change- und Configuration-Management Schwierigkeiten für eine optimale Lösungsfindung haben? 39

Basierend auf dem Ansatz des Capability Maturity Modells, welches speziell für die Beurteilung der Qualität bzw. „Reife“ von Software-Entwicklungsprozessen entwickelt wurde, wurde im Umfeld von ITIL ein entsprechendes Maturity Modell für die Bewertung von IT-Service-Management-Prozessen entwickelt.

200

Prozessbereiche und Prozesskategorien

Die Antwort ist so einfach wie banal. Das Change- und das Configuration-Management umfassen Funktionen, die mehr oder weniger von allen Funktionseinheiten einer ICT-Unternehmung benötigt werden und für eine ICT-Unternehmung quasi eine Basisfunktionalität darstellen. Partikularinteressen, fehlendes gemeinsames Verständnis, Vernachlässigung und Unterschätzung des Zusammenwirkens der Organisation in diesen Bereichen, unterschiedliche Begriffsdefinitionen und daraus resultierende Missinterpretationen sowie in der Folge verschiedenste Anforderungen an eine Lösung erschweren oder verhindern in der Praxis oft bereits die Entwicklung einer konzeptionell abgestimmten Lösungsstrategie. Fasst man die Ist-Situation in Stichworten zusammen, ergibt sich immer ein ähnliches Bild: • Einzelne Unternehmensbereiche haben in der Vergangenheit Lösungen entwickelt, die auf ihre eigenen Bedürfnisse ausgerichtet sind. Hier wurde z.T. erheblich investiert. • Es existieren mehrere Insellösungen, die in unterschiedlichen Reifegraden und auf unterschiedlichen technischen Plattformen realisiert sind. • Schnittstellen zu anderen Systemen oder auf organisatorischer Ebene erweisen sich i.d.R. als komplex und fehleranfällig. • Die Lösungen werden zwar für die Erfüllung der Aufgaben der eigenen Organisationseinheit benötigt, haben aber auf die eigentliche Wertschöpfung keinen oder nur sehr geringen Einfluss. • Die Lösungen laufen oft den technologischen Entwicklungen und Anforderungen hinterher. Die Zeit und das Geld reichen manchmal gerade dazu aus, einigermaßen Schritt zu halten. • Soweit Schnittstellen zu anderen Organisationseinheiten bestehen, sind die Datenempfänger unzufrieden mit den gelieferten Informationen (unpassende und fehlende Datenstrukturen), die dann – meist per Hand – im eigenen System ergänzt werden müssen. • Es gibt keine übergeordnete zentrale Verantwortlichkeit, die eine koordinierte Um- und Durchsetzung einer Gesamtlösung sicherstellt. • Investitionen in diese Art der Infrastrukturprojekte werden vom Management zwar als notwendig erkannt, haben aber oft letzte Priorität. • Typisch für größere und international tätige Unternehmen ist, dass regelmäßige Unternehmenszukäufe bzw. -verkäufe einer Harmonisierung entgegenwirken und die verfügbaren Ressourcen i.d.R. vollauf mit der Integration bzw. Desintegration beschäftigt sind.

Prozessbereich Support

201

Das Change- und das Configuration-Management sind die Bereiche, in denen in den nächsten Jahren viele ICT-Unternehmen langfristig ihre Produktivität optimieren und die Qualität ihrer Leistungen beeinflussen können. Während das Change Management primär eine organisatorische Herausforderung ist und vor allem durchgesetzt werden muss, kommt bei der Thematik des Configuration-Managements eine nicht zu unterschätzende konzeptionelle und technische Komplexität hinzu.

ICT Change Management Der Begriff „Change Management“ wird mit vielfältiger Bedeutung in der Unternehmenspraxis verwendet. Wir konzentrieren uns hier ausschließlich auf Veränderungen, die sich auf die IT-Infrastruktur und die damit verbundenen Dienstleistungen beziehen. Änderungen bzw. Änderungsanfragen (RFCs) der Systeme, die sich in der Neu- oder Weiterentwicklung befinden, werden in unserem Referenz-Prozessmodell zwar als solche identifiziert, aber den projektbezogenen Change-Verfahren zugewiesen und dort geregelt. Grundsätzlich ist davon auszugehen, dass in jeder Funktionseinheit einer ICT-Unternehmung RFCs generiert werden können und auch direkt Veränderungen durchgeführt werden. Bereits der Austausch einer defekten Hardwarekomponente wie z.B. einer Netzwerkkarte stellt im engeren Sinne einen Change dar, dessen Einfluss sich auf das betroffene System beschränkt. In diesem alltäglichen Beispiel zeigt sich auch der oft enge Bezug zum Configuration-Management. Bei dem genannten Beispiel werden Configuration Items verändert, die in der Configuration Database nachgeführt werden müssen. Der Rollout eines Major Releases ist hingegen ein Change, der einen vielfältigen Einfluss sowohl auf die Geschäftsprozesse des Unternehmens bzw. der betreuten Kunden an sich als auch speziell auf die Prozesse der ICT-Organisation haben kann und deshalb zwingend koordiniert und überwacht erfolgen muss. Weiter ist zu beachten, dass auch Changes außerhalb der ICT-Unternehmung geplant und realisiert werden, die Einfluss auf die Leistungserbringung der ICT-Unternehmung haben. Diese sind i.d.R. nicht vom ICTUnternehmen zu beeinflussen, können aber auf dessen Betrieb erheblichen Einfluss nehmen. Dies kann von einer geplanten temporären Stromunterbrechung über eine vorhergesehene Betriebsunterbrechung (z.B. Wartungs-

202

Prozessbereiche und Prozesskategorien

Abb. 92. ICT Change Management

Prozessbereich Support

203

fenster) bei Lieferanten bis zu Veränderungen von Produktions- oder Zulieferprozessen von verbundenen Unternehmen oder Lieferanten reichen, die direkt die Leistungserbringung des ICT-Unternehmens beeinflussen. Hiermit stellt sich dann auch schnell die Frage, welche Changes überwacht bzw. dokumentiert werden müssen und welche im Speziellen einem zentralen Change Management zu unterstellen sind. In der Praxis hat sich hierzu eine Kategorisierung von Changes etabliert. Hierbei wird ein Change bzgl. seines Einflusses, seiner Auswirkungen und Risiken hin bewertet. Je „kritischer“ ein Change, desto strenger auch die Vorgaben. Die Kriterien für die Zuordnung zu einer Kategorie sind unternehmensspezifisch und müssen innerhalb der ICT-Organisation abgestimmt werden. Die Spannbreite reicht von Standard-Changes bis zu MegaChanges. Standard-Changes sind so definiert, dass es sich dabei um klar umrissene, in ihren Auswirkungen und den damit verbundenen Tätigkeiten bekannte Veränderungen handelt. Diese müssen somit der Überwachung durch das Change Management im Sinne einer Freigabe (Genehmigung), einer Terminabstimmung und einer Abwicklungsverfolgung nicht unterstellt werden. Das oben beschriebene Beispiel eines Hardwareaustausches in einem Client-System oder ein einfaches Software-Upgrade ist z.B. ein typischer Standard-Change. Die Anzahl der Standard-Changes pro Monat gehen selbst bei mittleren Unternehmen schnell einmal in die Hunderte. Hier ist es wichtig, dass die Nachvollziehbarkeit der Veränderung gewährleistet ist und die Daten der veränderten Configuration Items aktualisiert werden. Mega-Changes, z.B. der Rollout eines Major Release, binden eine Vielzahl von Ressourcen, bedingen Abstimmungen mit anderen Einheiten, beeinflussen gegebenenfalls die Geschäftsprozesse der Anwender, wirken sich im Service Desk aus, beinhalten diverse Risiken etc. Sie müssen zwingend von einem zentralisierten Change Management koordiniert, terminiert, freigegeben und überwacht werden. In der Praxis ist hierfür eine entsprechende Management-Gruppe, die aus Vertretern verschiedener Bereiche (z.B. Betrieb, Entwicklung, Sicherheit, Service Desk etc.) zusammengesetzt ist, verantwortlich. ITIL bezeichnete dies Gruppe als Change Advisory Board (CAB). Zwischen diesen beiden Extremen können bedarfsorientiert weitere Kategorien gebildet werden. Es empfiehlt sich hier allerdings, eine überschaubare Anzahl anzustreben.

204

Prozessbereiche und Prozesskategorien

Der Wert eines Change Managements liegt darin, dass Veränderungen koordiniert, abgestimmt und nachvollziehbar durchgeführt werden und damit unnötige und teure Folgewirkungen vermieden werden. In unserem Referenz-Prozessmodell haben wir das Change Management in zwei Hauptprozesse untergliedert: • 411 Change Handling • 412 Change Planning & Control Diese beiden Hauptprozesse spiegeln auch die typische Trennung der im ICT-Unternehmen quasi überall möglichen „Change-Entstehung“ von der optimalerweise eher zentral organisierten Planung und Kontrolle der Changes wieder. Ausgangspunkt eines Changes ist das Bedürfnis, eine bestehende IstSituation zu ändern. Die Ursachen und Quellen hierfür sind vielfältig. Bereits bei mittleren ICT-Unternehmen geht alleine die Anzahl der RFCs pro Monat, von denen ein Großteil zu Standard-Changes führt, schnell in die Hunderte. Eine zentrale Stelle, die jeden RFC entgegennimmt und beurteilt, ist nicht praktikabel. Dies ist zum einen in der Masse begründet und zum anderen auch in der jeweils zur Beurteilung notwendigen Fachexpertise. Deshalb erfolgt eine erste Beurteilung eines RFC durch die jeweilige Fachorganisation. Wird der Change nicht abgelehnt, erfolgt dann dort auch meist die weitere Bearbeitung. Dies führt zu einem Lösungsvorschlag, der im Fall eines Standard-Changes direkt umgesetzt wird und ansonsten mit einem Lösungsvorschlag und einer Umsetzungsplanung abschließt. Damit ist dann ein Change geplant, der auf einer übergeordneten Ebene beurteilt und bzgl. seiner Realisierung terminiert und überwacht wird. Da an vielen Stellen einer ICT-Organisation RFCs auftreten und bearbeitet werden, ist es erstrebenswert, dass alle Aktivitäten des Change Managements über die gesamte Organisation hinweg einheitlich und abgestimmt erfolgen. Wird mit einzelnen Lieferanten, z.B. Outsourcing-Partnern, intensiver zusammengearbeitet, lohnt es sich, auch diese auf die eigenen Change-Management-Verfahren zu verpflichten. Der Prozess 411 Change Handling regelt die Bearbeitung eines RFC von dessen Entgegennahme bis – sofern er nicht abgelehnt wird – zur Vorlage eines Lösungsvorschlages, auf dessen Basis der Change geplant wird. Wird ein Standard Change festgestellt, der ohne weitere Kontrolle durch

Prozessbereich Support

205

das Change Management realisiert werden kann, wird dessen Umsetzung nicht weiter verfolgt. Ausgelöst wird der Prozess durch einen RFC. In unserem ReferenzProzessmodell ist ein RFC ein Ergebnis der folgenden Prozesse. Für jeden Prozess ist beispielhaft ein typischer RFC-Inhalt beschrieben: • 161 Audit & CIP; als Ergebnis eines Verbesserungsvorschlags sollen alle Server auf die gleiche Betriebssystemversion gebracht werden. • 164 Process Management; eine Prozessänderung führt zu einer Änderung eines in einer Software-Lösung implementierten Workflows. • 311 Project Planning; aufgrund einer Terminverschiebung eines Mega-Changes müssen alle in diesem Zeitraum geplanten Changes neu beurteilt und evtl. terminiert werden. • 313 Project Risk Management; im Rahmen eines Software-Entwicklungsprojektes wird erkannt, dass die vorgesehene Applikationsserver-Architektur die geforderte Performance nicht erbringen kann und hierfür eine neue Lösung benötigt wird. • 314 Project Change Management; der Kunde wünscht in einem Entwicklungsprojekt, dass die bereits installierten Server an einem anderen Ort installiert werden. • 412 Change Planning & Control; nach der Realisierung eines Changes wird festgestellt, dass der Aufwand unterschätzt wurde und dass anstehende, bereits terminierte Changes der gleichen Art aufgrund dieser Erfahrungen neu geplant und terminiert werden müssen. • 422 Error Control; ein regelmäßig auftretender Fehler kann beseitigt werden, indem die Server umkonfiguriert werden. • 432 CI Verification; es wird festgestellt, dass speziell nach Reparaturen die Konfigurationsdaten nicht oder nur unzureichend aktualisiert werden; es wird eine Prozessänderung vorgeschlagen. • 511 Production Planning; aufgrund einer Produktionsanforderung müssen die Verfügbarkeitszeiten des Mainframes für einen bestimmten Zeitraum partiell eingeschränkt werden. • 512 Availability Management; um die geforderte Verfügbarkeit der Systeme sicherstellen zu können, wird ein Ausbau der Infrastruktur beantragt. • 513 Capacity & Performance Management; um einen prognostizierten Speicherengpass eines Datenbanksystems zu vermeiden, muss der Storage ausgebaut werden.

206

Prozessbereiche und Prozesskategorien

• 622 Incident Management; aufgrund einer Störungsanalyse wird vorgeschlagen, dass die bei den Anwendern eingesetzte Netzwerkinfrastruktur optimiert wird. • 623 Proactive Problem Management; es wurde erkannt, dass eine bestimmte Hardware-Komponente eines bestimmten Notebooktyps besonders störungsanfällig ist und es wird der Austausch dieser Komponente beantragt. • 712 Emergency Process; in der Folge eines Notfalls wurde erkannt, dass weitere Systeme doppelt ausgelegt werden müssen. • 713 Contingency Testing; als Ergebnis eines Notfalltests wurde festgestellt, dass Prozesse geändert und das vorgesehene Notfallsystem ausgebaut werden muss. • 731 Security Management; aufgrund einer erkannten Lücke im Sicherheitssystem müssen diverse Systeme umkonfiguriert werden. • 741 Facility Management; aufgrund eines Platzengpasses in einer Serverfarm soll ein Teil der Server an einem anderen Ort installiert werden. Im Prozessverlauf wird der RFC analysiert und beurteilt, evtl. müssen noch weitergehende Abklärungen oder ein Lösungskonzept entwickelt werden. Die Ergebnisse des Prozesses sind: • Standard-Change festgestellt; diese Art von bekannten und grundsätzlich freigegebenen Changes werden aus Sicht des Change Managements nicht weiterverfolgt. (Die weitere Bearbeitung wird aufgrund der Vielzahl von Möglichkeiten nicht im Referenz-Prozessmodell abgebildet.) • Konzeptauftrag formuliert; es muss ein Lösungsvorschlag ausgearbeitet werden – dies erfolgt im Prozess 321 Conceptual Design. • Change abgelehnt; der Änderungsantrag wird nicht realisiert, der Antragssteller wird informiert. • P-Change identifiziert; beim RFC handelt sich um einen ProjektChange; dieser wird im Prozess 314 Project Change Management bearbeitet. • R-Change identifiziert; der RFC betrifft eine Lösung, die über das Release Management weiterentwickelt wird. Der RFC wird im Prozess 331 Release Planning weiter bearbeitet.

Prozessbereich Support

207

Kann direkt ein Changeauftrag formuliert werden bzw. wurde ein Konzeptergebnis erarbeitet, kann in der Folge der Changeauftrag erteilt werden. Ergebnisse dieses Prozesses sind: • Projekt vorgeschlagen; der Change ist so umfangreich oder komplex, dass die Lösung im Rahmen eines Projektes erarbeitet werden muss. In diesem Fall wird der Prozess 311 Project Planning angestoßen. • Materialbedarf ermittelt; für die Realisierung des Changes wird z.B. zusätzliche Hardware benötigt, welche dann über den Prozess 742 Material & Inventory Management bereitgestellt wird. • Infrastrukturbedarf ermittelt; für die Realisierung des Changes werden z.B. eigene Räumlichkeiten mit bestimmten Sicherheitsanforderungen (Klima, Brandschutz etc.) benötigt, die über den Prozess 741 Facility Management bereitgestellt werden. • Prozessänderung identifiziert; ein Prozess ist anzupassen bzw. zu definieren. Dies erfolgt im Prozess 164 Process Management. • Change geplant; der Change ist inhaltlich geplant, d.h. die angestrebte Lösung ist konzipiert und die Rahmenbedingungen für die Realisierung des Changes sind bekannt. Er kann bzw. muss nun, wenn es sich nicht um einen Standard-Change handelt, im Gesamtzusammenhang mit anderen Changes priorisiert und terminiert werden. Dies erfolgt im Prozess 412 Change Planning & Control. Es empfiehlt sich, das Handling von RFCs über die gesamte Organisation hinweg zu standardisieren. Hierzu gehört die Definition einheitlicher Change-Kategorien und der jeweiligen Zuordnungskriterien. Ziel muss es sein, dass die Analyse von RFCs und eine entsprechende Lösungsentwicklung kunden- und fachexpertennah erfolgt. Die Abschätzung der Konsequenzen eines Changes und ob dieser der Freigabe und Kontrolle eines zentralen Change Managements unterstellt werden muss, ist oftmals erst nach Vorlage des Lösungsvorschlages zu entscheiden. Ist ein Change geplant, liegt ein definiertes Vorhaben vor, welches auf die Geschäftsprozesse der Anwender, auf den Betrieb bzw. auf die Leistungserbringung des ICT-Unternehmens Einfluss nimmt oder zu konkreten Veränderungen der IT-Systeme und der damit verbundenen Prozesse führt.

208

Prozessbereiche und Prozesskategorien

Alle Changes, die nicht als Standard-Changes klassifiziert werden, müssen zentral geplant, koordiniert und überwacht werden. Diese Aktivitäten sind im Prozess 412 Change Planning & Control geregelt. Die Planung, Koordination und schließlich die Realisierung erfolgen unter der Berücksichtigung und dem Einfluss diverser Rahmenbedingungen wie z.B.: • anderer anstehender Changes, • der Verfügbarkeit der Systeme oder • Sondereinflüssen wie Betriebsferien, Verfügbarkeit von Spezialisten etc. Besonders zu beachten ist hierbei, dass einmal definierte und für die Umsetzung freigegebene Changes selbst ständigen Veränderungen unterworfen sind. Dies betrifft in erster Linie und vor allem anderen Terminänderungen. Eine Terminänderung bei einem Change mit vielen Abhängigkeiten kann unter Umständen zu einer Kettenreaktion führen, in welcher die Realisierungstermine anderer Changes ebenfalls neu geplant werden müssen. Das Ereignis Change geplant, – ein konkretes Änderungsvorhaben ist bereits geplant bzw. vorgesehen – kann ein Ergebnis von Aktivitäten außerhalb des ICT-Unternehmens40 oder von folgenden Prozessen (mit jeweils einem Beispiel) sein: • 311 Project Planning, z.B. Terminänderungen für bereits gemeldete Changes in Folge von Terminverschiebungen im Projekt, die eine Aktualisierung der Planung notwendig machen. • 332 Release Package Management, z.B. Meldung eines anstehenden Rollouts. • 334 Distribution Planning, z.B. Meldung einer Auslieferung eines Servers inkl. vorgesehenem Installations- und Inbetriebnahmetermin. • 411 Change Handling, z.B. Neukonfiguration mehrerer Firewalls als Ergebnis eines Sicherheitskonzepts. • 422 Error Control, z.B. Austausch von Netzwerkkarten eines bestimmten Typs bei diversen Applikationsservern. • 511 Production Planning, z.B. Einschränkung der Verfügbarkeit von Systemen in bestimmten Zeiträumen. 40

Z.B. angekündigte Stromunterbrechung, laufende Projektaktivitäten bei Kunden oder Lieferanten, die nicht dem eigenen Change-Management unterstehen.

Prozessbereich Support

209

• 631 On-Site Dispatching, z.B. Terminänderung eines bekannten, bereits gemeldeten und freigegebenen Changes aufgrund von Einflüssen vor Ort. • 713 Contingency Testing; z.B. die Planung einer Notfallübung, bei der gezielt Systeme abgeschaltet und Ersatzsysteme aktiviert werden, ist eine Aktivität, die dem Change Management und damit der restlichen Organisation bekannt sein muss. • 741 Facility Management; z.B. der Neueinbau einer Feuerlöschanlage in einem Rechenzentrum ist ein Change, der dem Change Management bekannt sein sollte. Im Prozess ist der Change hinsichtlich Termin und Rahmenbedingungen zu beurteilen, zur weiteren Bearbeitung freizugeben und mit einer Priorität zu versehen. Ein wichtiger Aspekt ist die Definition des Realisierungstermins. In der Praxis ist dies meist der schwierigste Teil, insbesondere wenn mehrere größere Changes um die verfügbaren Zeitfenster und Ressourcen konkurrieren. Ergebnisse dieser Aktivitäten können sein: • Change abgelehnt; dies ist meist dann der Fall, wenn die gewünschten Zeitfenster und / oder Ressourcen nicht wie gewünscht zur Verfügung gestellt werden können. • Outbound-Aktivität definiert; bei größeren Changes werden davon betroffene Kunden und Lieferanten über den Prozess 621 Contact Management informiert. • Change terminiert ist der Normalfall. Der festgelegte Termin beeinflusst unmittelbar alle davon abhängigen Planungsprozesse. Hiervon sind in unserem Modell betroffen: o 311 Project Planning o 334 Distribution Planning o 511 Production Planning o 631 On-Site Dispatching o 713 Contingency Testing o 741 Facility Management Das Ereignis Change realisiert ist das Resultat von Prozessen, in denen die Umsetzung eines Changes erfolgte. In unserem Modell haben wir dieses Ergebnis speziell bei den folgenden Prozessen berücksichtigt:

210

Prozessbereiche und Prozesskategorien

• 312 Project Control; aufgrund unseres Ansatzes werden alle größeren Vorhaben und damit auch die meisten Changes, die dem Change Management unterstellt sind, projektorientiert und somit in Form eines Projektes realisiert. Entsprechend überwacht der Prozess 312 Project Control den Projektfortschritt und kann damit die Realisierung eines Changes melden. • 633 Installation & Relocation Management; auch dieser Prozess beeinflusst bzw. beinhaltet direkt die Realisierung von Changes. Hier sehen wir speziell Installationsaktivitäten, die nicht zwingend in Form bzw. im Rahmen eines Projektes abgewickelt werden. • 713 Contingency Testing; in der Vorbereitung einer Notfallübung werden oft eine Reihe von Maßnahmen getroffen (z.B. im Bereich der Sicherheit), bei denen nach Beendigung der Übung sichergestellt werden muss, dass sie auch wieder zurückgesetzt werden. • 741 Facility Management; hier werden Veränderungen an der Grundversorgung und der Gebäudeinfrastruktur initialisiert und gesteuert. Soweit diese vom Change Management mit überwacht werden, kann auch hier eine entsprechende Rückmeldung bzgl. der Realisierung eines Changes erfolgen. Wir haben uns für die Rückmeldung Change realisiert auf die oben genannten vier Prozesse konzentriert. Eine entsprechende Schnittstelle kann selbstverständlich auch in andere Prozesse eingebaut werden. Dies ist abhängig davon, wie im Unternehmen grundsätzlich mit Änderungen verfahren wird. In unserem Ansatz gehen wir davon aus, dass die meisten Änderungen in Form von Projekten realisiert werden, und haben damit einen ausgeprägten Zusammenhang zwischen dem Change Management und dem Projekt-Management hergestellt. Besonders ist noch auf die folgenden zwei möglichen Quellen für das Ereignis Change realisiert hinzuweisen: 1. Auch Stellen außerhalb der Unternehmung, wie z.B. Lieferanten, können Aktivitäten durchführen, die sinnvollerweise dem Change Management der ICT-Unternehmung zumindest bekannt sind und von diesem verfolgt werden. Wenn z.B. ein Outsourcing-Partner an einem Wochenende ein Wartungsfenster plant, könnte das durchaus von Interesse für das ICT-Unternehmen sein. 2. Stellen oder Rollen können ebenfalls im Sinne eines Entscheidungsprozesses das Ereignis Change realisiert melden. Aus der Praxis kennt man das vor allem, wenn bestimmte Entscheidungskriterien von einer verantwortlichen Stelle übersteuert werden.

Prozessbereich Support

211

Ist ein Change realisiert, wird dieser – abhängig von der Art des Changes – direkt abgeschlossen, oder es erfolgt eine Erfolgskontrolle. Diese kann dazu führen, dass ein Q-Audit beantragt und / oder ein RFC formuliert wird, der entsprechende Korrekturen einleitet. Wurde mit dem Change eine bekannte Fehlerquelle beseitigt, stößt das Ereignis Known Error behoben die entsprechenden Aktivitäten im Prozess 422 Error Control an. Da im Rahmen der Realisierung eines Changes mit hoher Wahrscheinlichkeit CI geändert wurden, werden die Prozesse 432 CI-Verification und 433 CIDocumentation angestoßen. Einige allgemeine und einfache Regeln: Regel 1: Das RFC-Handling über die gesamte ICT Organisation hinweg standardisieren. Regel 2: Change-Kategorien inkl. der Zuordnungskriterien definieren. Regel 3: Die Kategorie „Standard-Change“ beinhaltet bekannte Veränderungen mit keinem oder geringem Einfluss auf seine Umwelt. Diese Changes müssen nicht speziell freigeben, koordiniert und überwacht werden. Evtl. stattfindende Veränderungen von Configuration Items sind über das Configuration Management nachvollziehbar. Regel 4: Alle Nicht-Standard-Changes werden ab dem Zeitpunkt, ab dem der Inhalt des Changes bekannt ist und dessen Umsetzung geplant werden kann, einem zentralen Change Management unterstellt. Regel 5: Alle Nicht-Standard-Changes, deren Inhalt und der vorgesehene Realisierungstermin müssen für die gesamte ICT-Organisation (evtl. auch für Kunden und Lieferanten) jederzeit einsehbar sein. Regel 6: Die Freigabe der Changes erfolgt über ein spezifisches Management- / Expertenteam (Change Advisory Board). Regel 7: Erfolgt eine Terminverschiebung, wird der gesamte Freigabeprozess wiederholt. Regel 8: Bei Changes aufgrund von Notfällen ist zwingend darauf zu achten, ob evtl. andere anstehende Changes davon betroffen sind. Nach Realisierung eines Notfall-Changes sind alle evtl. vorgesehenen Kontrollaktivitäten zwingend durchzuführen.

212

Prozessbereiche und Prozesskategorien

ICT Problem Management Besonders in deutschsprachigen Unternehmen hat der Begriff „Problem Management“ eine andere Bedeutung als hier verwendet bzw. in ITIL definiert. So wird der Begriff „Problem Management“ weit verbreitet mit der Bearbeitung von Störfällen gleichgesetzt. Die Trennung von Incident Management (Störfallbearbeitung und -behebung) und Problem Management (systematische Störfallanalysen und Behebung von Störungsursachen) setzt sich aber zunehmend, bedingt durch die Verbreitung von ITIL, durch. Das systematische Problem Management muss gezielt aufgebaut und etabliert werden. Hierzu dienen die in diesem Kapitel beschriebenen drei Prozesse: • 421 Problem Handling • 422 Error Control • 423 Proactive Problem Management Im 421 Problem Handling werden Störungen, deren Ursachen nicht eindeutig zu identifizieren sind oder die aufgrund von bestimmten Symptomen vermuten lassen, dass es sich um einen Fehler in einem System handelt, eingehend analysiert. Ziel ist es, den möglichen Fehler eindeutig, d.h. nachweisbar und wiederholbar zu definieren.

Abb. 93. ICT Problem Management

Prozessbereich Support

213

Der Prozess 422 Error Control regelt die Problemlösung. Er stellt sicher, dass für den bekannten Fehler eine Lösung gefunden wird. Die systematische Auswertung von Daten aus verschiedenen Bereichen wie System Monitoring, Incident Management, dem Betrieb etc. mit dem Ziel, Hinweise auf sich wiederholende Störungsursachen zu finden, die wiederum auf mögliche Systemfehler hinweisen, erfolgt im Prozess 423 Proactive Problem Management. Das Ereignis Problem identifiziert bedeutet, dass ein Defekt in einem System wie z.B. ein Programmierfehler oder ein Materialfehler vermutet wird. Das Ereignis löst den Prozess 421 Problem Handling aus. Dort wird das Problem im Detail (Auftreten, Häufigkeit, Symptome, mögliche Ursachen etc.) dokumentiert, analysiert und gegebenenfalls eine Umgehungslösung entwickelt. Daraus resultiert das Ergebnis Known Error definiert. Dies bedeutet, dass der Fehler erkannt, seine Beseitigung initialisiert wurde und evtl. eine Umgehungs- oder Zwischenlösung vorliegt. Das Ereignis Problem identifiziert ist ein Ergebnis der folgenden Prozesse: • 423 Proactive Problem Management; hier werden Statistiken z.B. aus dem Incident Management, dem Service Monitoring, Produktionsund Qualitätsberichte etc. systematisch ausgewertet und auf Auffälligkeiten hin analysiert. • 522 System Monitoring; die automatische bzw. halbautomatische Systemüberwachung erkennt i.d.R. sofort Funktionsstörungen, die aus vermuteten Systemfehlern resultieren. • 622 Incident Management; vor allem Software- und Materialfehler sind typische Defekte, die vom Anwender erkannt und gemeldet werden. Der Prozess 421 Problem Handling weist im Referenz-Prozessmodell vier Ergebnisse auf, die in der Folge mehrere Prozesse aktivieren: • Technologie veraltet; oftmals liegt eine Störung innerhalb eines Gesamtsystems einfach nur darin, dass Technologien verschiedener Generationen aufeinander treffen und keine hundertprozentige Kompatibilität gewährleistet ist. In diesem Fall wird der Prozess 732 Technology Management angestoßen, der die entsprechenden Konsequenzen einschätzt und Maßnahmen zur Beseitigung der Defizite einleitet.

214

Prozessbereiche und Prozesskategorien

• Wissensdefizit erkannt; gerade bei technologisch komplexen Lösungen stellen sich vermutete technische Fehler als Bedienfehler heraus. (hierzu gehören z.B. auch die relativ häufigen fehlerhaften Konfigurationen von Systemen aller Art). Eine mögliche Beseitigung kann über den Prozess 722 Knowledge Management erfolgen, der Maßnahmen für die Beseitigung der Wissensdefizite in die Wege leitet. • Sicherheitsproblem erkannt; im Rahmen von Problemanalysen können auch Sicherheitslücken erkannt werden, manchmal sind diese auch die Ursachen für Störungen (z.B. Hackerangriff). Die Beseitigung eines Sicherheitsproblems erfolgt über den Prozess 731 Security Management. • Outbound-Aktivität definiert; dies gilt vor allem für den Fall, dass vorerst eine Umgehungslösung für das erkannte Problem entwickelt wurde und die Betroffenen informiert werden müssen. Dies könnte im Extremfall aber auch eine Rückrufaktion sein. Die Kontaktaufnahme mit den Betroffenen erfolgt über den Prozess 621 Contact Management. • Known Error definiert; das primäre Ergebnis des Prozesses. Der Fehler bzw. das Problem ist mit allen seinen Symptomen, den vermuteten Ursachen sowie möglichen Umgehungslösungen beschrieben. Jede Support-Einheit sowie evtl. auch Lieferanten und Kunden haben Zugriff auf die Informationen. Darüber hinaus ist die Problembeseitigung, die im Prozess 422 Error Control geregelt ist, initiiert. Einer der größten Nutzen eines systematischen Problem Managements ist die Bereitstellung sämtlicher mit einem Known Error verbundenen Informationen. Dadurch wird sichergestellt, dass für bekannte Fehler keine unnötigen Aufwände wie Abklärungen etc. erfolgen oder schnell entsprechende Umgehungslösungen realisiert werden können. Für den Aufbau einer Knowledge-Datenbank eignen sich die Known Errors als erste Knowledge-Inhalte. Die eigentliche Problembehebung bzw. -beseitigung ist im Prozess 422 Error Control geregelt. Primärer Auslöser des Prozesses ist das Ereignis Known Error definiert, als Ergebnis des Prozesses 421 Problem Handling. Im Prozess erfolgen alle Aktivitäten, die für die Problembehebung bzw. -beseitigung notwendig sind. Ergebnisse dieser Aktivitäten können sein:

Prozessbereich Support

215

RFC formuliert, der im Prozess 411 Change Handling weiterbearbeitet wird oder Change geplant (aktiviert 412 Change Planning & Control), wenn die notwendigen Korrekturen und Änderungen direkt definiert und geplant werden können. Weiter erfolgt die Erfolgskontrolle, die durch das Ereignis Known Error behoben, ein mögliches Ergebnis des Prozesses 412 Change Planning & Control, angestoßen wird. Ist das Problem gelöst, werden, soweit notwendig, die betroffenen Kunden über den Prozess 621 Contact Management informiert. Eine wichtige Funktion ist die Überwachung des Fortschritts der Problemlösung von Known Errors. Es kommt relativ häufig vor, dass ein Known Error nach seiner Erstentdeckung relativ lange bestehen bleibt. Gründe hierfür gibt es viele. Insbesondere Fehler in der Konzeption oder Architektur einer Lösung halten sich oft sehr lange. Eine regelmäßige Überwachung soll sicherstellen, dass die Lösung bekannter Probleme bzw. Fehler nicht vergessen wird. Die Sicherstellung des laufenden Betriebes der IT-Infrastruktur und der daraus betriebenen Applikationen und Softwarelösungen erfolgt im Störungsfall typischerweise reaktiv. Es tritt eine Störung auf und diese wird schnellstmöglich beseitigt. Manchmal wird eine Umgehungslösung realisiert, die allzu oft dann auch als Dauerlösung bestehen bleibt. Die Vielfalt von Störungen, Reklamationen, Abweichungen von vorgegebenen Qualitäts- und Leistungsstandards, Produktions- und Monitoringberichten etc. beinhaltet die Möglichkeit, ein proaktives Problem Management zu betreiben. Bei einem proaktiven Problem Management wird versucht, aus einer Vielzahl von Informationen typische Störungsmuster zu erkennen, die auf versteckte Mängel hinweisen. Hierzu ein Beispiel: Ein Service Desk nahm in den letzen sieben Monaten im Durchschnitt monatlich rund 50 Incidents auf, die mit der Stromversorgung von Notebooks im Batteriebetrieb zu tun hatten. Eine Analyse der Notebooktypen hat zum Ergebnis, dass rund 60 % einem bestimmten Notebook Typ A und 30% einem anderen Notebook Typ B zugeordnet werden können. Die restlichen 10% verteilen sich fast gleichmäßig auf fünf andere Notebooktypen. Beide Hersteller, darauf angesprochen, kennen das Problem. Der Hersteller mit der 60%-Quote empfiehlt den Ersatz der Akkus, die Abwicklung des Austausches erfolgt auf Garantiebasis. Der

216

Prozessbereiche und Prozesskategorien

Hersteller mit den 30% bietet keine zufriedene Lösung, der Kauf von Notebooks des Typ B wird daraufhin eingestellt. Nach dieser Maßnahme sinkt die durchschnittlich Anzahl von Incidents im Zusammenhang mit dem Batteriebetrieb auf unter 10 pro Monat. Der Prozess 423 Proactive Problem Management wird periodisch (z.B. monatlich, viertel- oder halbjährlich) durchgeführt. Er beinhaltet die Analyse sämtlicher Informationen, die es ermöglichen, direkte Hinweise auf Fehler oder Störungsmuster zu erkennen. Ist dies möglich, ist das Ergebnis: Problem identifiziert. Die weitere Bearbeitung des erkannten oder vermuteten Problems erfolgt im Prozess 412 Problem Handling. Das Thema „Problem Management“ sollte nicht nur aus der Sicht der Fehlerbeseitigung gesehen werden. Es bietet vielmehr auch für die Entwicklungsingenieure eine Quelle von Hinweisen und Anregungen für die Weiterentwicklung und Verbesserung von Produkten!

ICT Configuration Management Das Configuration Management ist der Bereich, in dem in den meisten Unternehmen der größte Handlungsbedarf besteht. Neben unzureichenden Konzepten, Wildwuchs von Lösungen und fehlendem Verständnis für die Aufgabenstellung verhindern gerade die existierenden Lösungen mit z.T. riesigen und historisch gewachsenen Datenbeständen die Ablösung und Umstellung auf einheitliche und modernere Lösungen. Im Mittelpunkt des ICT Configuration Managements stehen die Verwaltung und das Management von Konfigurationen. Konfigurationen sind Kombinationen mehrerer Komponenten41 zu einer funktionalen Einheit und bestehen somit aus mehreren (Bau)-Teilen. Ein Teil kann hierbei selbst wiederum eine Konfiguration oder ein echtes Einzelelement darstellen, welches nicht mehr in einzelne Teile zerlegt werden kann bzw. per Definition42 nicht weiter zerlegt wird. Abbildung 94 veranschaulicht diese Zusammenhänge. 41

Hier primär Hard- und / oder Software.

42

Beispiel: Ein Monitor besteht aus einer Vielzahl von Bauteilen. Ein Unternehmen kann per Definition festlegen, dass für das Unternehmen ein Monitor als ein Teil zu betrachten ist, dessen innere Struktur aus Sicht der Unternehmung

Prozessbereich Support

217

Aus der Fertigungsindustrie kennt man hierfür den Begriff der Stückliste. Eine Stückliste ist eine hierarchisch strukturierte Anordnung von Objekten, die für die Herstellung der jeweils durch die Stückliste definierten Baugruppe benötigt werden. Grundsätzlich ist es empfehlenswert, sich bei der Auseinandersetzung mit dem Thema ICT Configuration Management an den Lösungen der Fertigungsindustrie und hier vor allem an denen der Einzel- (Anlagenbauer) oder Kleinserienfertiger zu orientieren. Diese Branche blickt auf eine über 100 Jahre alte Erfahrung zurück und hat schon viel komplexere Gesamtsysteme43 (Atomkraftwerke, Verkehrsflugzeuge, Kreuzfahrtschiffe etc.) realisiert und betrieben, als sie die im Vergleich hierzu doch relativ primitive IT-Infrastruktur einer Unternehmung darstellt. Ein sehr sinnvolles und zur Übernahme empfohlenes Konzept ist das in der Folge behandelte Lifecycle-Konzept.

Abb. 94. Konfiguration Erläuterung 1

keine Rolle spielt. Ein Hersteller von Monitoren hingegen benötigt die Übersicht über alle Bauteile, also die Konfiguration des Monitors. Wenn der Hersteller die Netzteile seiner Monitore einkauft, entscheidet er sich wahrscheinlich, das Netzteil per Definition als ein Teil zu behandeln, dessen innere Struktur ihn nicht weiter interessiert. 43

Die im Übrigen selbst eine z.T. sehr umfassende IT-Infrastruktur beinhalten.

218

Prozessbereiche und Prozesskategorien

Eine im Rahmen des ICT Configuration Managements verwaltete Einheit wird als Configuration Item bezeichnet. Die Verwaltung der Configuration Items erfolgt in Form von Daten in einer Configuration Database. Die Datenstruktur einer Configuration Database orientiert sich hierbei an einer klassischen Stücklistenstruktur. Die Aufgabe und die Herausforderung des ICT Configuration Managements liegen darin, den gesamten Lifecycle eines Objektes, welches als Einzelelement, als Bestandteil einer Konfiguration oder als Konfiguration vorliegen kann, abzubilden. Eine mögliche Ausprägung eines Lifecycles eines Configuration Items zeigt die folgende Abbildung:

Abb. 95. Konfiguration Erläuterung 2

Der Lifecycle eines Configuration Items wird durch den jeweiligen Zustand, in dem sich ein Configuration Item befindet, beschrieben. Jeder Zustand zeichnet sich durch bestimmte Kriterien zu einem bestimmten Zeitpunkt wie z.B. spezielle Dateninhalte, Anzahl und Umfang von Informationen, Ausprägungen, zugehörige Objekte etc. aus. Die folgende Zusammenstellung umfasst einige mögliche Zustände eines Configuration Items, die dieses im Laufe seines Lifecycles annehmen kann. Je nach Zustand kommen weitere Informationen hinzu bzw. werden Daten modifiziert. Configuration Management bedeutet primär Datenverwaltung, und die Menge der zu verwaltenden Daten eines Configuration Items wächst mit seiner Lebensdauer kontinuierlich an. In der Praxis ist somit auch die Sicherstellung einer akzeptablen Datenqualität und hier vor allem der Datenaktualität eine der größeren Herausforderungen. In der Klammer sind jeweils typische englische Fachtermini genannt, wie sie auch in der Fertigungsindustrie verwendet werden, weiter werden anhand des Beispiels „Monitor“ kurz mögliche Zustandsmerkmale beschrieben:

Prozessbereich Support

219

• Zustand: wie spezifiziert (as specified); Leistungsanforderungen, zu verwendende Basistechnologie; Größen des zukünftigen Monitors sind definiert, erste technische Zeichnungen liegen vor, erste Bauteile, die zu verwenden sind, sind benannt. • Zustand: wie konstruiert (as designed); Konstruktion ist vollständig abgeschlossen, Stücklisten liegen komplett vor, evtl. existieren erste Prototypen, diverse Modellvarianten des neuen Monitors sind definiert. • Zustand: wie freigegeben (as released); der neue Monitor wurde getestet und zum Verkauf / zur Produktion freigegeben. Die Modellvarianten wurden reduziert. In den Stücklisten wurden einzelne Bauteile (z.B. aus Kosten- oder Qualitätsgründen) ausgetauscht. • Zustand: wie gefertigt (as built); Monitor existiert nun physisch; für jeden produzierten Monitor liegt in der Configuration Database ein Datensatz vor (eindeutige Identifikation z.B. durch Seriennummer). Die Datenattribute der Bauteile gemäß Stückliste wurden mit realen Daten (z.B. Fertigungsnummern) ergänzt. • Zustand: wie bestellt (as ordered); der Kunde bestellt den Monitor, gemäß der veröffentlichten „Stückliste“ (Bestellformular) mit der Farbe weiß! Sämtliche Kundendaten, Bestelldatum etc. ergänzen den Informationssatz. • Zustand: wie versandt (as shipped); versandt wurde ein Monitor gemäß Bestellung, allerdings in der Farbe schwarz. Weiter sind die gesamten Versanddaten wie z.B. Auslieferung, Verpackungsart, Spediteur, Zollunterlagen etc. erfasst. • Zustand: wie verwendet, wie implementiert (as deployed, as implemented); der Monitor wurde in Betrieb genommen, weitere Daten wie z.B. Datum der Inbetriebnahme (z.B. für Garantiebeginn) oder der Standort etc. werden erfasst. • Zustand: wie gewartet (as maintained); nach einem Defekt wurde das Netzteil ausgetauscht. Die Daten des ausgetauschten Bauteils werden gelöscht bzw. durch die des neuen ersetzt. Weiter werden die Informationen zur Reparatur – wann, durch wen – Kosten etc. erfasst. Die meisten ICT-Unternehmen entwickeln nicht wirklich selbst Hardware. Vielmehr werden einzelne Bauteile zusammengekauft und zu Gesamtsystemen zusammengefügt, also konfiguriert. In diesem Fall werden dann die Informationen über das jeweilige Bauteil benötigt, so dass viele ICTUnternehmen in ihren Configuration-Management-Systemen für Hardware-

220

Prozessbereiche und Prozesskategorien

Objekte meist Daten ab dem Zustand „wie gefertigt“ verwalten. Wird Software entwickelt, erfolgt die Verwaltung von Software-Modulen optimalerweise bereits ab dem Zustand „wie konstruiert“. In unserem Referenz-Prozessmodell gehen wir davon aus, dass ein Configuration Management nach dem oben dargestellten Konzept, wie es für die Fertigungsindustrie typisch ist, organisiert wird. Tatsächlich handelt es sich hier um ein komplexes Thema, welches an dieser Stelle nur angedeutet werden kann. Es kann aber jedem, der sich mit diesem Thema auseinandersetzt, nur empfohlen werden, sich die Erfahrungen aus der Fertigungsindustrie zunutze zu machen. Das ICT Configuration Management umfasst die erstmalige Definition bzw. Erfassung der Datenstruktur eines Configuration Items in der Configuration Database, die erstmalige Erfassung einer real existierenden Ausprägung eines Configurations Items und in der Folge die Überwachung, die Kontrolle und die Verwaltung der Veränderungen. Hierbei wird der Zustand eines Configuration Items verändert. Die Veränderungen stellen einen Change dar, der durch einen Request for Change (RFC) ausgelöst wird. Configuration Items werden in einer Configuration Database verwaltet. Beim Design einer Datenbank werden die zukünftig zu verwaltenden Objekte in Form so genannter Entitätstypen (z.B. Entitätstyp PC-Arbeitsplatz, Applikations-Server etc.) definiert. Ein eindeutig identifizierbares Objekt eines Entitätstyps, z.B. der PC-Arbeitsplatz mit der Inventarnummer 4711, wird als Entität44 bezeichnet. Jedem Entitätstyp werden charakteristische Attribute zugeordnet. Diese können vereinfacht in drei Gruppen untergliedert werden: • Identifizierende (Schlüssel-)Attribute wie z.B. Seriennummer, Inventarnummer etc. • Objekttypische bzw. objektbeschreibende Informationen wie z.B. Modellbezeichnung, Bildschirmgröße in Zoll oder Speicherkapazität in Gigabyte etc. 44

Als Entität (synonym Informationsobjekt; englisch Entity) wird in der Informatik ein eindeutig zu bestimmendes Objekt bezeichnet, dem Informationen zugeordnet werden.

Prozessbereich Support

221

• Verwaltungs-, Verwendungstypische Attribute wie z.B. Kaufpreis, Standort, verantwortliche Kostenstelle, etc. Die folgende Liste gibt eine nicht abschließende Übersicht von verwaltungs- bzw. verwendungsorientierten Informationsinhalten: o o o o o o o o o o

Finanz- und Anlage-Informationen Organisatorische Informationen Fertigungs-Informationen Informationen der System-Konfiguration Informationen der Applikations-Konfiguration Betriebsinformationen Bestell-, Liefer- und Abwicklungsinformationen Wartungs- und Reparaturinformationen Lizenz-Informationen Produkt- & Verkaufsinformationen

In der Praxis findet sich innerhalb einer ICT-Unternehmung eine Vielzahl von unterschiedlichen verwaltungs- oder verwendungsorientierten Datenbanken, die Configuration Items meist redundant im Zusammenhang mit anderen Daten verwalten. So finden sich Lösungen, die sich auf die Thematik des Asset Managements (Verwaltung von Anlagegütern), also auf finanztechnische Aspekte, konzentrieren, die ihren Schwerpunkt in der Inventarverwaltung haben oder bestimmte Geschäftsprozesse unterstützen, die auf Informationen von Configuration Items zurückgreifen müssen. Weiter finden sich SoftwareProdukte im Bereich des System-Managements und des Monitorings, die in den meisten Fällen auf eine interne, produktspezifische Configuration Database zurückgreifen. Ergänzt wird dieses Bild durch Speziallösungen wie Kabel-Management-Systeme oder die Trennung45 von Datenbanken nach der Art der verwalteten Objekte (z.B. nur Mainframe-Objekte, nur Client-Systeme etc.). Zusammengefasst hat ein ICT Configuration Management die folgenden vier Basisfunktionen sicherzustellen:

45

Hier wird oft auch die ehemalige und bestehende organisatorische Trennung zwischen Abteilungen auf Datenbankebene sichtbar, So haben die „Mainframeler“, die „Netzwerkler“ und die „Peripherieler“ ihre eigenen Configuration Databases – meist dann auch noch auf verschiedenen Produktplattformen.

222

Prozessbereiche und Prozesskategorien

1. Eindeutige Identifikation eines Configuration Items; hierzu gehört neben der Definition des jeweiligen Entitätstyps vor allem die Entwicklung eindeutiger Identifikationsschlüssel (Nummernsystematik). 2. Überwachung der Veränderungen eines Configuration Items; hierzu gehören zum einen ein systematisches Änderungs- bzw. Change Management und – soweit es sich um Standard-Changes handelt, die nicht über das Change Management abgewickelt werden – die Sicherstellung der Datenverifikation und der Nachvollziehbarkeit der Änderungen. 3. Nachvollziehbarkeit der Änderungen; hier vor allem die Änderung bei Zustandswechseln. 4. Regelmäßige Überprüfung der Datenqualität in Bezug auf Richtigkeit, Vollständigkeit und vor allem Aktualität. Die Komplexität des ICT Configuration Managements liegt nicht in der Komplexität der dazugehörigen Prozesse. Die Komplexität ergibt sich durch die Vielzahl der zu verwendenden Daten, die selbst wiederum die Arbeitsgrundlage für eine Vielzahl von unterschiedlichsten Funktionen und Prozessen einer ICT-Unternehmung darstellen. Komplexitätstreiber sind in der Praxis oft eine unnötig hohe Anzahl von spezifischen Configuration Databases, die redundante Daten verwalten und oft als Insellösungen realisiert sind. In der Praxis liegt die Herausforderung nun nicht darin, eine einzige Configuration Database zu realisieren, sondern vielmehr darin, analog zum Change Management ein einheitliches Konzept über die gesamte Organisation hinweg durchzusetzen. Wie eingangs erwähnt stehen im Mittelpunkt des ICT Configuration Managements die Verwaltung und das Management von Konfigurationen. Dies beginnt bereits mit der Definition der jeweiligen Entitätstypen, die die Daten- und somit die Informationsstruktur eines zu verwaltenden Configuration Items vorgeben. Der zweite Schwerpunkt liegt in der Datenpflege von der Ersterfassung bis zur Löschung bzw. Historisierung. Hierbei ist der folgende Zusammenhang wesentlich und nicht zu unterschätzen: Änderungen eines

Prozessbereich Support

223

Configuration Items sind Bestandteil von Funktionen vielerlei Prozesse, die aus Sicht des Configuration Management nicht beeinflusst bzw. kontrolliert werden können. Die überwiegende Mehrheit dieser Änderungen betrifft ein oder wenige Datenattribute und wird nicht durch das Change Management kontrolliert. Aus diesem Grunde ist dem Aspekt der Datenqualität besonderes Augenmerk zu schenken, der tatsächlich in vielen ICT-Unternehmen ein Problem darstellt. Zu dieser Thematik gehört auch, quasi im Sinne eines spezialisierten Datentyps, die Dokumentation eines Configuration Items (soweit hierzu eine besteht). Diese kann von technischen Konstruktionszeichnungen bis zur Benutzeranleitung reichen.

Abb. 94. ICT Configuration Management

224

Prozessbereiche und Prozesskategorien

Weiter ist das eigentliche Konfigurieren, also das Zusammenfügen einer Konfiguration aus diversen Objekten bzw. Bauteilen, ein Prozess, der für die jeweiligen Produktgruppen im Detail zu regeln ist. Die oben genannten Aufgaben werden in der Prozesskategorie 43 ICT Configuration Management durch die folgenden vier Hauptprozesse abgebildet: • 431 System Konfiguration • 432 CI Verification • 433 CI-Documentation • 434 CI-Type-Engineering Unser hier beschriebenes ICT-Musterunternehmen bietet in seiner Produktpalette auch Hardware-Produkte (z.B. PCs, Notebooks etc.) an. Dies ist eine Produktgruppe, in der das auszuliefernde Gesamtsystem klassischerweise im Sinne des Zusammenstellens und Zusammenfügens von Bauteilen konfiguriert wird. Betrachtet man das Thema ganzheitlich, gehört selbst die Verpackung zur Auslieferungskonfiguration. Der Prozess 431 System Configuration regelt das Konfigurieren von Produkten. Der Prozess wird von zwei Ereignissen ausgelöst: • Technische Abnahme erfolgt; jedes Soft- bzw. Hardwareprodukt muss den Prozess 333 Operations Acceptance Test durchlaufen. Mit der Freigabe für den Betrieb kann auch das (später) auszuliefernde Produkt fertig konfiguriert werden. Dies reicht von der Erstellung spezifischer Dokumente bis zur Konfiguration des späteren „Auslieferungspaketes“. • HW-System bestellt; als Resultat des Prozesses 334 Distribution Prozesses wird hier im Sinne eines Konfigurators das bestellte System zusammengestellt und verpackt46. Abhängig von den einzelnen Funktionen des Prozesses 431 System Configuration liegen folgende Ergebnisse vor:

46

Wir haben in unserem Modell auf die Abbildung des Fertigungsprozesses von Hardware verzichtet und fassen diese Tätigkeiten unter der Funktion System montieren zusammen. Für ICT-Unternehmen, die wirklich Hardware produzieren, müsste das Modell mindestens um die Prozess-Kategorie „HardwareFertigung“ ergänzt werden.

Prozessbereich Support

225

• Materialbedarf ermittelt; soweit weiteres Material benötigt wird, wird dies über den Prozess 742 Material & Inventory Management bereitgestellt. Wir gehen davon aus, dass auch das reale Auslieferungspaket eine Konfiguration darstellt. Bei dem Materialbedarf kann es sich sowohl um Verpackungsmaterial handeln als auch um allgemeines Zubehör wie Adapter, länderspezifische Netzkabel etc. • System freigegeben; hiermit liegt die abschließende Gesamtkonfiguration – wie ein bestimmtes Produkt verkauft und ausgeliefert werden kann – vor. In der Praxis gibt es für ein Produkt i.d.R. natürlich eine Reihe von Varianten. Im Prozess 134 Product & Service Management wird hierauf basierend der Status der Produktentwicklung verfolgt. • Release Package konfiguriert; soweit das Produkt dem Release Management untersteht, wird mit diesem Ergebnis die Verwaltung des definierten Release im Prozess 332 Release Package Management angestoßen. • Auslieferungspaket bereitgestellt; in diesem Fall wird ein echtes physisches Auslieferungspaket (versandfertig) bereitgestellt. Dies löst dann entweder im Prozess 335 HW / SW Distribution die Auslieferung oder über den Prozess 742 Material & Inventory Management die Einlagerung im Warenlager aus • Lizenz benötigt; abhängig vom Produkt können evtl. eine oder mehrere Lizenzen benötigt werden, dies löst den Prozess 115 Licence Management aus, welcher die dafür notwendigen Aktivitäten regelt. • CI geändert; im Prozess 431 System Configuration wird eine Konfiguration physisch existent. Dabei werden z.B. Teile eingebaut sowie diverse Informationen wie Fertigungsdatum etc. erfasst. Jede Datenänderung bedeutet, dass ein Configuration Item geändert wurde. Nicht jede Änderung eines Attributes bzw. eines Configuration Items wird überwacht. Der Großteil der mit einem Configuration Item verbundenen Informationen ist für dessen Betrieb bzw. Nutzung nicht entscheidend. Kommt es zu Änderungen, die nicht oder falsch nachgeführt werden, nimmt dies keinen direkten Einfluss auf dessen Nutzung. Typisch hierfür sind organisatorische Informationen wie z.B. der physische Standort47 des 47

Hierbei muss noch nicht einmal ein Umzug des Systems erfolgen. Eine einfache Veränderung der Gebäudebezeichnung oder der Raumnummerierungen kann dafür verantwortlich sein, dass bei Hunderten von Configuration Items die entsprechenden Informationen nicht mehr aktuell sind.

226

Prozessbereiche und Prozesskategorien

Systems. Wird dann allerdings ein Support vor Ort benötigt, ist das System für den Servicetechniker plötzlich nicht auffindbar. Es gibt eine Vielzahl von Gründen dafür, dass Daten nicht wie notwendig aktualisiert werden. Aus diesem Grunde sind regelmäßige Audits, die die Datenqualität und hier insbesondere die Datenaktualität sicherstellen, notwendig. Dies regelt der Prozess 432 CI Verification. Dieser Prozess wird periodisch (z.B. monatlich) angestoßen oder dann, wenn im Rahmen eines Prozesses das Ergebnis CI geändert vorliegt und das Ergebnis dieser Änderung eine Überprüfung der Datenqualität empfiehlt. Der Prozess an sich gestaltet sich relativ einfach48; es werden jeweils der aktuelle Status (Lifecycle-Konzept!), der damit verbundene Informationsstand sowie die Datenqualität im Sinne von Vollständigkeit, Korrektheit und Aktualität geprüft. Im Fall von Abweichungen werden diese dokumentiert und korrigiert. Soweit notwendig werden Maßnahmen definiert und eingeleitet, die primär die zukünftige Datenqualität positiv beeinflussen sollen. Entsprechend weist der Prozess folgende Ergebnisse auf: • Verbesserung vorgeschlagen; dies können Verbesserungen aller Art sein, die dazu führen, dass die Datenqualität verbessert wird. Der Umgang mit Verbesserungsvorschlägen ist im Prozess 161 Audit & CIP geregelt. • Q-Audit beantragt kann abgeleitet werden, wenn bestimmte Defizite sich z.B. in Organisationen oder bestimmten Prozessbereichen häufen, die Ursache aber nicht eindeutig ermittelt werden kann – ein über den Prozess 161 Audit & CIP lancierter Qualitäts-Audit kann ein passendes Instrument sein. • RFC formuliert; bestimmte Korrekturmaßnahmen können direkt über klar formulierte Änderungen (z.B. an Prozessen, Systemen) realisiert werden. Diese werden als RFC über den Prozess 411 Change Handling abgewickelt. • Bestehender CI Type nicht mehr aktuell; in diesem Fall entspricht meist die Datenstruktur eines Entitätstyps nicht mehr den notwendigen 48

In der Praxis stößt man hier auf das Problem der i.d.R. hohen Datenvolumina. So ist die Überprüfung der korrekten Standortangaben (Gebäudebezeichnung und Büronummer) für z.B. 1.000, gar 20.000 oder mehr PC-Arbeitsplätze nicht vollautomatisch zu realisieren. Aus diesem Grunde empfiehlt es sich in diesem Fall z.B. durch zufallgesteuerte Stichproben die Datenqualität zu messen und abhängig von den Ergebnissen weitergehende Maßnahmen zu planen.

Prozessbereich Support

227

Anforderungen. Freie oder nicht benötigte, aber vorhandene Datenfelder werden zweckentfremdet mit Informationen belegt. Je höher das Datenvolumen, desto schneller geht i.d.R. die Übersicht verloren und die Datenqualität entwickelt sich negativ. Die eigentliche Datenpflege von der Ersterfassung bis zur Löschung bzw. Historisierung von Configuration Items erfolgt in Funktionen von Prozessen (z.B. Bestellabwicklung, Reparatur, Anlageverwaltung etc.), die selbst nicht dem Configuration Management zugeordnet sind! Die Verantwortung für die Datenpflege und deren Qualität liegt in der Praxis außerhalb des Configuration Managements. Die Definition einer Konfiguration, also aus welcher „Stückliste“ von Bauteilen ein Objekt besteht, und die Entscheidung, welche Bauteile zu verwenden sind, sind Aufgaben eines Entwicklungsingenieurs. Mit der Entwicklung wird gleichzeitig auch die Datenstruktur festgelegt, d.h. wie ein einzelnes Bauteil bzw. eine Konfiguration datenmäßig in einer Datenbank zu verwalten ist. Es handelt sich dabei um die Definition der Entitätstypen für die Configuration Database. Eine Konfiguration ist eine Kombination von mindestens zwei oder mehreren Teilen. Hierbei kann ein Teil selbst wieder eine Konfiguration sein oder ein Einzelteil darstellen (siehe hierzu die Ausführungen zu Beginn des Kapitels). Beide Ausprägungen sind aus Sicht der Configuration Database ein Configuration Item. Für die folgenden zwei Prozesse, bei denen es sich um dem Engineering nahe Prozesse handelt, muss vorgängig eine weitere Begriffsdefinition eingeführt werden. Diese Prozesse sind in dieser Form in den meisten ICTUnternehmen, die selbst keine Hardware entwickeln, nicht implementiert. Ein Einzelteil (z.B. ein Chip, ein Prozessor) bezeichnen wir als BasisType, wobei wir hier Type analog zum englischen Begriff als Bauart verstehen. Ein Einzelelement ist somit ein Basis-Type (gleich Bauteil). Eine Konfiguration bezeichnen wir als Structure-Type (gleich Baugruppe), also eine Bauart, die aus einer Struktur mehrerer Elemente besteht. In der Regel legt die Entwicklungsabteilung fest, welche Materialien (Bauteile, geführt in einer Materialliste) im Unternehmen zum Einsatz kommen und welche Baugruppen (Konfigurationen) gebaut werden. In ICT-Unternehmen bzw. ICT-Organisationen, die nicht über eine Entwicklungseinheit verfügen, sollte diese Funktion von einer zentralen Einheit

228

Prozessbereiche und Prozesskategorien

übernommen werden. In manchen Unternehmen finden sich hierfür dann Organisationseinheiten, die Bezeichnungen wie „Systemarchitektur“, „ITArchitektur“ oder ähnliches tragen. Leider gibt es in vielen Unternehmen diese Organisationseinheiten nicht bzw. sie haben oftmals nicht die notwendige Durchsetzungskraft. Für jeden Basis-Type gibt es (theoretisch) ein Auswahlverfahren, Anforderungen, die an das Produkt und den Lieferanten gestellt werden, Leistungskriterien, die erfüllt werden müssen, eine Lieferantenliste mit bevorzugten und abgelehnten Lieferanten und vieles mehr. Für einen StructureType gibt es eine Beschreibung der Konfiguration, oftmals in Form von Konstruktionszeichnungen, Bau- und / oder Schaltplänen, Stücklisten, diversen Vorgaben und vieles mehr. Die hiermit verbundene Dokumentation stellt ein umfassendes Know-how dar, welches im Entwicklungsprozess anfällt und in der Folge in den unterschiedlichsten Prozessen vom Einkauf über den Kundenservice (Reparaturen, Wartung) bis zum Problem Management Verwendung finden kann. Diese spezifischen Informationen, überwiegend in Form von Dokumentationen, müssen ebenso verwaltet werden wie die späteren Informationen über die jeweiligen physischen Configuration Items. Hier besteht eine entsprechende Analogie zur Fertigungsindustrie, wo das Dokumenten-Management eine sehr wichtige Rolle spielt. Diese Aufgaben sind in unserem Modell im Prozess 433 CI-Documentation geregelt. Der Prozess wird primär durch die zwei Ergebnisse Neuer CI-Type definiert und CI-Type geändert des Prozesses 434 CI-Type Engineering angestoßen. Dies geschieht, da mit der Einführung und Freigabe eines neuen Configuration Items zwingend und bei dessen Veränderung mit hoher Wahrscheinlichkeit eine entsprechende Dokumentation zu erstellen und zu verwalten ist. Ebenfalls kann die Änderung eines Configuration Items (CI geändert) dazu führen, dass dessen Basisdokumentation angepasst werden muss. Dieser eher seltene, aber doch vorkommende Fall betrifft vor allem komplexere Konfigurationen wie z.B. Serversysteme und klassische Mainframestrukturen. Die Definition von Configuration Items sind Ergebnisse eines Entwicklungsprozesses, der in unserem Modell vom Prozess 322 System Development repräsentiert wird. Bei Configuration Items, die nicht selbst entwickelt, sondern eingekauft werden, wird quasi auch die Definition des Configuration Items eingekauft. Wie detailliert hier dann die Datenstruktur in der eigenen Configuration Database sein muss, legt das Unternehmen nach seinen Bedürfnissen fest.

Prozessbereich Operations

229

Im Prozess 434 CI-Type-Engineering werden die Entitätstypen definiert und damit die Verwaltung entsprechender Configuration Items in der Configuration Database ermöglicht. Ausgelöst wird der Prozess primär durch die Ereignisse Neuer CI-Basis-Type benötigt und Neuer CI-StructureType benötigt. Weiter kann im Prozess 432 CI Verification festgestellt werden, dass ein Bestehender Basis-Type nicht mehr aktuell ist und die Configuration Database entsprechend angepasst werden muss. Neben der Weiterentwicklung oder Aktualisierung der Configuration Database durch Hinzufügen oder Entfernen von Entitätstypen stoßen die Prozessergebnisse Neuer CIType definiert und CI-Type geändert den vorher beschriebenen Prozess 433 CI-Documentation an. Die Entwicklung einer Configuration Database läuft in der Praxis oft nach einem Re-Engineering-Verfahren ab. So existiert i.d.R. bereits eine ICT-Infrastruktur. Meist existieren bereits auch eine oder mehrere Lösungen, die Konfigurationen verwalten und die zu berücksichtigen sind. In der Folge wird versucht, diese Strukturen zu analysieren (Re-Engineering), via Datenmodell einzufangen und daraus ein entsprechendes Datenbankdesign abzuleiten. Anschließend werden die bestehenden Daten migriert. Die Ablösung „alter“ Lösungen wird dann als Erfolg ausgewiesen, ein echter Fortschritt in Sachen Configuration Management wird meist aber nicht erreicht, da auch die alten Konzepte migriert wurden. Es ist nicht untypisch, dass ICT-Unternehmen bzw. ICT-Organisationen sich bzgl. des Themas Configuration Management in einem dauerhaften Re-Engineering-Prozess befinden.

Prozessbereich Operations In den letzten Jahren wurde verstärkt die so genannte Industrialisierung der Informationstechnologie thematisiert. Hintergrund ist die Überlegung, dass zwischen den Anforderungen und der Umsetzung von Prozessen, Methoden, Verfahren und Standards zwischen der Fertigungsindustrie und der ICT-Industrie eine große Übereinstimmung besteht. Somit liegt es nahe, die industriellen Erfahrungen und Erkenntnisse auf ICT-Unternehmen

230

Prozessbereiche und Prozesskategorien

bzw. ICT-Organisationen zu übertragen und damit deren Effizienz und Effektivität zu steigern. Vereinfacht können in einer ICT-Unternehmung vier Wertschöpfungsbereiche unterschieden werden, die in ähnlicher Art auch in der Fertigungsindustrie zu finden sind: • Der Entwicklungsbereich umfasst die Forschung, Konzeption und Konstruktion von Produkten. Innerhalb der ICT-Unternehmung beinhaltet er alle Arten von Konzeptionen für die Entwicklung von Hardund Software-Lösungen sowie von Dienstleistungen im ICT-Umfeld. • Der Fertigungsbereich umfasst die Herstellung von Software-, in diesem Fall durch Programmierung, und Hardware-Lösungen (klassische industrielle Fertigung) sowie alle notwendigen Maßnahmen – inkl. der Schaffung der organisatorischen Voraussetzungen – zu deren Einführung bzw. Installation (Montage) bis zu dem Punkt, an dem der Einsatz (Betrieb) des gefertigten Produktes gewährleistet ist. (In klassischen industriellen Unternehmen wird für die Fertigung synonym der Begriff „Produktion“ verwendet). • Der Betriebsbereich umfasst die Sicherstellung und Durchführung der Produktion von Leistungen49 auf der Basis einer ICT-Infrastruktur. Vergleichbar mit der Fertigungsindustrie stellt die ICT-Infrastruktur die Herstellungsinfrastruktur (Produktionsmaschinen) dar. Der Betrieb plant und steuert die Produktion; hierzu gehört sowohl die Sicherstellung der Verfügbarkeit als auch die Auslieferung50 der Produktionsergebnisse. In der Praxis werden für diesen Bereich in ICT-Unternehmen bzw. ICT Organisationen die folgenden Synonyme verwendet: Betrieb (früher auch RZ-Betrieb), Produktion oder Operations. • Der Servicebereich umfasst alle Dienstleistungen wie z.B. Reparaturund Wartungsleistungen, Schulungen, Helpline etc., die erbracht werden, damit der Kunde die Produkte des Unternehmens nutzen kann. 49

Die Art der Leistungen ist durch die Funktionen der jeweilige Hard- und Software definiert. (Ein Drucker druckt die ihm erteilten Druckaufträge, eine Steuerungssoftware steuert, eine Datenbankapplikation ermöglicht die Erfassung und Verwaltung von Daten usw.).

50

Der Charakter einer Auslieferung wird dann greifbarer, wenn man sich als Produktionsergebnisse z.B. die Herstellung der monatlichen Kontoauszüge in Papierform bei einer Großbank und der Organisation des damit verbundenen Massenversands vorstellt.

Prozessbereich Operations

231

In diesem Kapitel konzentrieren wir uns auf den Betriebsbereich bzw. in der Folge: den Betrieb oder die Operations.

Abb. 97. Prozessbereich Operations

Die Schwerpunkte des Betriebes liegen in der Sicherstellung der Verfügbarkeit der ICT-Infrastruktur sowie in der Planung und Steuerung der Produktion. Hierin liegt auch schon eine erste Besonderheit im Vergleich zu sonstigen Fertigungsunternehmen. Bereits die reine Zur-VerfügungStellung und das „Betreiben“ der ICT-Infrastruktur ist im Fall einer ICTOrganisation bereits eine Produktionsleistung. Es handelt sich hierbei um einen quasi permanent laufenden Produktionsprozess. Ein Beispiel: Der Betrieb stellt einen Applikationsserver sowie die Anbindung von Client-Systemen an diesen Server an sieben Tagen der Woche für 24 Stunden zur Verfügung. „Zur Verfügung“ heißt, der Server ist in Betrieb, die Applikationssoftware plus die benötigten Datenbanken sind ebenso funktionsfähig und der Server kann über das Netzwerk von den

232

Prozessbereiche und Prozesskategorien

Clients angesprochen werden. Dies ist die Produktionsleistung des Betriebes und zwar unabhängig davon, ob in diesem Zeitraum null oder tausend Anwender das System zur „Herstellung ihrer Leistungen“, wie z.B. das Bearbeiten von Schadensfällen, nutzen. Die Planungs- und Steuerungsaufgaben konzentrieren sich im obigen Beispiel auf die Bereitstellung und Sicherstellung von Ressourcen und Kapazitäten, es handelt sich also primär um ein Kapazitäts- und Verfügbarkeitsmanagement. Anders stellt sich die Situation dar, wenn der Betrieb tatsächlich physisch greifbare Produkte herstellt wie z.B. Druckerzeugnisse. Beliebte Beispiele hierfür sind die monatlichen Kontoauszüge51 oder periodische Rechnungserstellungen. Hier haben wir dann Aufgabenstellungen wie in einer Fertigung: Die Rohstoffe (in diesem Fall z.B. Papier, Druckertoner, Verpackungsmaterial etc.) müssen frühzeitig beschafft und angeliefert werden, die Logistik – bedarfsorientierte Bestückung der Drucker – muss organisiert sein. Die Tätigkeitsschwerpunkte des Betriebs liegen also in der Planung und Steuerung und damit verbunden in der Überwachung seiner Produktionstätigkeiten. Die Aufgaben lassen sich analog zu denen der Fertigungsindustrie beschreiben, in der die entsprechenden Verfahren unter dem Fachterminus PPS (Produktionsplanung und -steuerung) zusammengefasst werden. An dieser Stelle ist nur ein rudimentärer Überblick über dieses Themengebiete möglich, aus diesem Grunde verweisen wir auf die umfangreiche Fachliteratur. Die PPS teilt sich auf in die Produktionsplanung, die die mit der Produktion verbundenen Vorgänge lang-, mittel- bis kurzfristig52 vorplant und die Produktionssteuerung, die der Produktion Aufträge erteilt, freigibt, steuert, überwacht und kontrolliert. Beide Bereiche greifen im Tagesgeschäft i.d.R. fließend ineinander über. Wir haben diese in unserem Modell in den folgenden zwei Prozesskategorien: 51

Die deutsche Bank weist für das Jahr 2005 rund 16 Mio. Kunden aus. Angenommen jeder Kunde verfügt lediglich über ein Konto und erhält monatlich einen Papierkontoauszug à 10 Gramm Papier, so müssten pro Monat 16 Mio. Kontoauszüge, mit einem Gesamtverbrauch an Papier von rund 160 Tonnen, produziert werden. Wenn jeder Kontoauszug innerhalb einer viertel Sekunde gedruckt würde, würde ein sequenzieller Druck 46 Tage! dauern. (Hier wird durch e-banking eine Entlastung angestrebt).

52

Typisches Beispiel: Jahresendverarbeitung (langfristig), Monatsendverarbeitung (mittelfristig), Tagesendverarbeitung (kurzfristig).

Prozessbereich Operations

233

• 51 ICT Operations Planning und • 52 ICT Operations Control Management abgebildet. Für den Betrieb einer ITC Infrastruktur und Produktionstätigkeiten im Sinne der Herstellung eines Objektes (Beispiel: Druckoutput) können eine Vielzahl von Analogien zur Fertigungsindustrie gefunden werden. Allerdings besteht doch auch ein wesentlicher Unterschied. Im ICT Umfeld wird auch bereits das Betreiben eines Systems, auf dem der Kunde seine Leistungen fertigt, als Produktionsleistung verstanden.

ICT Operations Planning Die Produktionsplanung für den Betrieb einer ICT-Infrastruktur bzw. auch der spezifischen Fertigung von Output, im Sinne von Datenoutput in elektronischer oder gedruckter Form beinhaltet ähnliche Planungsinhalte wie sie aus der Fertigungsindustrie bekannt sind. Folgende Planungsinhalte sind zu berücksichtigen: • Planung des Produktionsprogramms im Sinne von „was“, „wann“, „auf welchem System“ und „unter welchen Voraussetzungen“; hierzu gehört primär die Abstimmung von regelmäßigen Produktionsprozessen (Monatsend-, Tagesendverarbeitungen) mit situativen Produktionsaufträgen (z.B. bedingt durch Marketingaktionen). Weiter sind mögliche Fremdeinflüsse (Change Management wie z.B. Einführung neuer Applikationen!) zu berücksichtigen. • Verfügbarkeitsplanung; hier geht es primär darum, die Verfügbarkeit der ICT-Infrastruktur in Abstimmung mit allen anderen Produktionsaufgaben zu planen. Typisch sind die Planung der Wartungsfenster oder anderer bekannter Einflussfaktoren (Betriebsferien, erhöhte Aktivitäten vor Weihnachten etc.). • Performance & Kapazitätsplanung, betrifft vor allem die Rechnerleistungen, die Datenbankkapazitäten, die Druckerkapazitäten und die Performance der Kommunikationskanäle bzw. der Netzwerke – auch hier gilt es vor allem, die Spitzenzeiten in Einklang mit dem normalen Produktionsbetrieb zu bringen.

234

Prozessbereiche und Prozesskategorien

Abb. 98. ICT Operations Planning

Prozessbereich Operations

235

• Ressourcen und Materialplanung, betrifft vor allem die Verfügbarkeit von Personal und Material wie z.B. Datenträger, Papier, Druckerfarbe etc. • Planung und Feinabstimmung der Produktionsprozesse und Termine, umfasst die Planung und Terminierung der sachlogischen Reihenfolge der Produktionsprozesse. Ein klassisches Beispiel ist hierfür z.B. die Jobablaufsteuerung für Batchverarbeitungen auf Mainframesystemen. Diese Planungsaufgaben sind in den Prozessen des ICT Operations Planning zusammengefasst und umfassen die folgenden drei Hauptprozesse: • 511 Production Planning • 512 Availability Management • 513 Capacity & Performance Management Der Prozess 511 Production Planning ist der zentrale Planungsprozess. Die Inhalte der Planung umfassen die Analyse zukünftiger Produktionsaufträge, die Definition des zu erwartenden bzw. möglichen Produktionsumfangs und -aufwandes, die Kalkulation der benötigen Ressourcen sowie die Ermittlung der Produktionskosten. Für bereits definierte Produktionsaufträge beinhaltet sie die Ziel- und Ergebnisplanung für die Planungsperiode, die Ermittlung der jeweils benötigten Ressourcen sowie die Definition der Vorgaben für die Produktion. Die Planung ist ein sich ständig wiederholender Prozess, der durch eine Vielzahl von Ereignissen angestoßen werden kann: • Produktions-Planungsauftrag freigegeben ist ein Ergebnis des Angebotsprozesses 212 Bid Management. Das Ereignis löst die Planung eines möglichen zukünftigen Produktionsauftrages aus. Hierbei geht es primär darum, die zukünftig zu erbringende Leistung detailliert zu definieren, die Konsequenzen der Auftragsannahme insbesondere bzgl. der benötigten Ressourcen und Auswirkungen auf den aktuellen Betrieb zu ermitteln und die Produktionskosten zu kalkulieren. Ergebnisse dieser Aufgabenkette sind: o Produktionsofferte erstellt, die im Angebotsprozess 212 Bid Management in das Angebot für den Kunden einfließt. Aus vertrieblicher Sicht beinhaltet die Produktionsofferte den von den Produktionsspezialisten definierten Leistungsumfang sowie die Produktionskosten, die eine Grundlage für die Preisfestlegung bilden.

236

Prozessbereiche und Prozesskategorien

o Budgetbedarf formuliert; neue bzw. zusätzliche Produktionsaufträge können eine Aufstockung des Personals oder den Ausbau der Infrastruktur zur Folge haben. Sind entsprechende Ausgaben bzw. Investitionen vorzunehmen, wird das dafür benötigte Budget kalkuliert und in das im Prozess 143 Budgeting geregelte Budgetverfahren eingebracht. • Periodisch; z.B. täglich, wöchentlich, monatlich werden für die anstehenden Produktionsaufträge die entsprechenden Planungsaktivitäten durchgeführt. Je kurzfristiger hierbei die Planungsperiode (z.B. aktueller Produktionstag), desto feiner und konkreter erfolgt auch die Planung. Wichtig ist hierbei vor allem, die Aktivitäten frühzeitig zu erkennen, die außerhalb der Betriebsorganisation stattfinden und die den Betrieb bzw. die Produktion beeinflussen können. Dies wird über ein für das gesamte Unternehmen geltende Change Management sichergestellt. • Produktionsvertrag freigegeben; wird vom Kunden ein Vertrag unterzeichnet, ist dieses Ereignis ein Resultat des Prozesses 222 Contract Administration. In die bestehende Planung muss nun der neue Produktionsauftrag integriert werden. Evtl. müssen auch zuerst die hierfür notwendigen Voraussetzungen wie z.B. Erweiterung der Infrastruktur, des Personalbestandes oder der Ausbildung von Mitarbeitern geschaffen werden. Dies kann unter Umständen dazu führen, dass die gesamten bisherigen Planungen überarbeitet werden müssen. • Change terminiert, ein Resultat des Prozesses 412 Change Planning & Control. Jeder geplante Change muss bzgl. seines Einflusses auf die Produktion beurteilt werden und gegebenenfalls in der Planung berücksichtigt werden. Dazu gehören vor allem Changes, die den Betrieb bzw. die Produktion stören oder behindern können. • Produktionsvertrag beendet; die vertraglichen Vereinbarungen wurden erfüllt oder die Vereinbarung, die dem Produktionsauftrag zugrunde liegt, wurde vom Kunden gekündigt. Das Ereignis ist ein Resultat des Prozesses 222 Contract Administration. Das Wegfallen einer Produktionsvereinbarung kann sowohl für die Planung wie für die gesamte Betriebsorganisation Konsequenzen haben, die in der Folge zu berücksichtigen sind. Im Extremfall kann dies bedeuten, dass Ressourcen reduziert oder zwecks weiterer Verwendung freizugeben sind. • Vertragsabweichung identifiziert; im Prozess 223 Contract Monitoring wurde im Fall dieses Ereignisses festgestellt, dass die in der Pro-

Prozessbereich Operations

237

duktion erbrachten Leistungen nicht den Leistungen entsprechen, die mit dem Kunden vereinbart wurden. Entsprechend sind Korrekturmaßnahmen in den Produktionsvorgaben notwendig. • Q-Ziele definiert; neben den Leistungsvorgaben auf der Basis von Kundenvereinbarungen werden über das interne Qualitäts-Management (162 QM-System) weitere Leistungsvorgaben vorgegeben, die direkt die Planung sowie die Produktionsvorgaben beeinflussen. • Prozessvorgaben erstellt; ein weiterer Einfluss sind Vorgaben, wie bestimmte Prozesse ablaufen müssen. Insbesondere Sicherheitsaspekte und Nachweispflichten können erhebliche Einflüsse auf die Produktionsprozesse nehmen. Meist werden durch diese Art der Vorgaben Produktionsprozesse komplexer und aufwändiger (d.h. teurer), ohne die erzeugte Leistung an sich (positiv) zu beeinflussen. Prozessvorgaben werden im Modell im Prozess 164 Process Management generiert. Die Ergebnisse des Planungsprozesses sind ebenso vielfältig und zeigen die Vernetzung der Produktionsplanung mit den anderen Prozessen der Unternehmung. • Change geplant; im Rahmen einer Betriebs- bzw. Produktionsplanung fallen ständig Änderungen an, die aufgrund ihrer Bedeutung einem zentralen Change Management (412 Change Planning & Control) unterstellt sein müssen. Damit wird sichergestellt, dass auch andere Organisationseinheiten und evtl. angebundene Kunden und Lieferanten über Changes, die sie betreffen können, rechtzeitig informiert werden. Typische Changes dieser Art sind z.B. geplante Wartungsfenster, kurzfristiges Abschalten von Systemen aufgrund von Reparaturen oder Maßnahmen, die zu Kapazitäts- und Performance-Engpässen führen können. • Produktionsvorgabe erstellt; ein Ergebnis der Produktionsplanung und Vorbereitung ist die Definition klarer Vorgaben, die einerseits die Produktionsprozesse steuern, andererseits Mengen, Qualität, Termine und Aufwand vorgeben. Durch dieses Ereignis wird im Prozess 521 Production Control der jeweilige Produktionszyklus vorbereitet, durchgeführt und überwacht. • Availability-Vorgaben erstellt; ein Resultat der Planung ist die Anforderung bzgl. der Verfügbarkeit der Ressourcen im Allgemeinen und der ICT-Infrastruktur im Besonderen. Mit diesem Ereignis wird

238

Prozessbereiche und Prozesskategorien

der Prozess 512 Availability Management ausgelöst, der einerseits die Machbarkeit prüft und andererseits die Verfügbarkeit aller Ressourcen sicherstellt. • Prozessänderung identifiziert; neue Produktionsaufträge, Veränderungen von Rahmenbedingungen (z.B. aufgrund von Changes) etc. können dazu führen, dass bestimmte Prozessänderungen, die nicht über einen RFC abgewickelt werden können, realisiert werden müssen. Dies erfolgt dann im Prozess 164 Process Management. • Produktionsplanung erstellt; abschließendes Ereignis der Produktionsplanung, aktiviert keinen weiteren Prozess. Der Produktionsplan steht dem Kunden, dem Management und den Mitarbeitern sowie evtl. weiteren Geschäftspartnern als Information zur Verfügung. • RFC formuliert; die Aufgabe der Planung umfasst neben der Sicherstellung der Leistungserfüllung auch die Optimierung der Produktion. Gerade im Planungsprozess und aufgrund der meist langjährigen Erfahrung erkennt die Planungseinheit Veränderungspotenziale außerhalb ihres Einflussbereiches. Diese werden in Form von RFCs formuliert und in den Prozess 411 Change Handling, zwecks weiterer Bearbeitung eingebracht. • Materialbedarf ermittelt; typisches Ergebnis des Planungsprozesses ist der Materialbedarf. Einfachstes Beispiel dafür sind Papier und Druckerfarbe. Die zum Teil gewaltigen Mengen an notwendigen „Rohstoffen“ werden über den Prozess 742 Material & Inventory Management beschafft bzw. bereitgestellt. • Infrastrukturbedarf ermittelt; ebenfalls ein typisches Ergebnis des Planungsprozesses, wenn z.B. weitere Rechner-, Drucker- oder Speicherkapazitäten benötigt werden. Oftmals werden auch zusätzliche Raumkapazitäten53 benötigt. Die Beschaffung und Bereitstellung erfolgt über den Prozess 741 Facility Management. • Ausbildungsbedarf ermittelt; abhängig vom jeweiligen Produktionsauftrag, von neu einzusetzenden Systemen aller Art kann im Rahmen der Planung ein entsprechender Ausbildungsbedarf festgestellt werden. 53

Praxisbeispiel: Ein neuer Produktionsauftrag hat einen sehr umfangreichen Druck-Output zum Ergebnis. Hierfür werden täglich mehrere Paletten Papier benötigt. Als echtes Problem stellt sich die Suche nach einem brauchbare Zwischenlager dar (Fläche, Anlieferung, kurze Wegstrecke und Transport zu den Druckern), da das verfügbare bereits seine Kapazitätsgrenzen überschritten hat.

Prozessbereich Operations

239

Das Ereignis löst die entsprechenden Maßnahmen im Prozess 151 Professional Development aus. • Einsatzplan erstellt; mit Abschluss der Produktionsplanung sind auch die entsprechenden Personalressourcen und Arbeitszeiten (Schichtplanung!) geplant und in den meisten Fällen ist auch das jeweilige Personal zugeordnet. Das Ereignis stellt über den Prozess 152 Human Resource Planning die definitive Zuordnung der Personalressourcen sicher. • Capacity- / Performance-Bedarf definiert; ein Resultat der Planung sind die Anforderungen bzgl. Kapazitäten und Performance insbesondere der ICT-Infrastruktur. Mit diesem Ereignis wird der Prozess 513 Capacity & Performance Management ausgelöst, der einerseits die Machbarkeit prüft und andererseits die entsprechenden Kapazitäten sowie die Performance sicherstellt. • Kapazitäts- und Skillbedarf erstellt; insbesondere ein Ergebnis bei längerfristig ausgelegten Planungshorizonten. Die Frage, wie viel Personal, mit welchem Ausbildungsstand wann benötigt wird, ist in diesem Fall beantwortet und aktiviert die entsprechenden Maßnahmen im Prozess 152 Human Resource Planning. Die Prozesse 512 Availability Management und 513 Capacity & Performance Management unterscheiden sich in ihren inhaltlichen Aufgaben, haben aber ansonsten identische Aufgabenstellungen, die zu den gleichen Prozessergebnissen54 führen. Die Prozesse unterscheiden zwei Aufgabenketten: Die erste Aufgabenkette wird durch das Ereignis Availability-Vorgaben erstellt (im Fall des Prozesses 512 Availability Management) bzw. durch das Ereignis Capacity- / Performancebedarf definiert (im Fall des Prozesses 513 Capacity & Performance Management) – jeweils als Resultat des Prozesses 511 Production Planning – ausgelöst. Im Prozess werden jeweils die gestellten Anforderungen auf ihre Machbarkeit geprüft und die Maßnahmen definiert, die die Erfüllung der Anforderungen sicherstellen sollen. Ergebnisse dieser Aktivitäten sind: 54

Das Ergebnis Produktionsbericht erstellt sagt lediglich aus, dass ein Bericht über einen Produktionsvorgang erstellt wurde. Es sagt nicht aus, welchen fachlichen Inhalt dieser Bericht hat. So können z.B. Produktionsberichte hinsichtlich der Qualität, der Verfügbarkeit der Ressourcen, der Kapazität, der Performance etc. erstellt werden.

240

Prozessbereiche und Prozesskategorien

• Infrastrukturbedarf ermittelt; in diesem Fall soll durch Ausbau bzw. Veränderung der Infrastruktur (z.B. zusätzliche Systeme, zusätzliche Speicherkapazitäten) sichergestellt werden, dass die gestellten Anforderungen erfüllt werden können. Veränderungen der Infrastruktur werden über den Prozess 741 Facility Management abgewickelt. • Produktionsvorgabe erstellt; über dieses Ereignis wird Einfluss auf den jeweils anstehenden Produktionszyklus (521 Production Control) genommen. So können z.B. durch die Vorgabe bestimmter Produktionsreihenfolgen oder auch Zeiten (z.B. Nachtstunden) Verfügbarkeits-, Kapazitäts- und Performance-Engpässe zu Spitzenzeiten vermieden werden. • Verbesserung vorgeschlagen; längerfristige Verbesserungen in der Organisation oder in der Technik werden über den kontinuierlichen Verbesserungsprozess (161 Audit & CIP) gesteuert. Im vorliegenden Themengebiet könnte z.B. ein Vorschlag sein, bestimmte Leistungen aus- oder einzulagern (Out- / In-Sourcing) oder einen Lieferanten zu wechseln. • RFC formuliert; oftmals können z.B. Veränderungen auf der Ebene der Applikationssoftware oder der Konfiguration der Datenbanken eine Optimierung in der Produktion bewirken. Diese Änderungsanforderungen werden in Form von RFCs formuliert und in den Prozess 411 Change Handling zwecks weiterer Bearbeitung eingebracht. Die zweite Aufgabenkette der Prozesse 512 Availability Management und 513 Capacity & Performance Management wird durch das Ereignis Monitoring-Bericht erstellt, ein Resultat des Prozesses 522 System Monitoring, ausgelöst. Es folgt ein Soll / Ist-Abgleich und – soweit notwendig – werden die Ursachen analysiert, vor allem wenn die Soll-Vorgaben nicht erfüllt wurden. Die Ergebnisse dieser Aufgabenkette sind: • Produktionsbericht erstellt; der jeweilige Bericht löst in den folgenden Prozessen die jeweils beschriebenen Aktivitäten aus: o 113 Supply Chain Management; wurde die Leistung oder Teile davon durch einen externen Lieferanten erbracht, wird dies analysiert und gegebenenfalls Maßnahmen zur Optimierung eingeleitet. o 162 QM-System; hier wird auf Basis des Produktionsberichts überprüft, ob die Qualitäts-Vorgaben erreicht bzw. eingehalten wurden. o 223 Contract Monitoring; hier dienen die Produktionsberichte dazu, die Vertragserfüllung zu prüfen und zu dokumentieren.

Prozessbereich Operations

241

• Vertragsverletzung identifiziert; dies ist meist bei besonders deutlichen Abweichungen der Soll- / Ist-Werte der Fall. Das Ereignis löst die entsprechenden Aktivitäten im Prozess 223 Contract Monitoring aus. Tritt dieses Ereignis ein, liegt es im Interesse des Unternehmens, dass es nicht im Produktionsbericht versteckt wird, sondern aktiv kommuniziert wird. Die Planung und Steuerung des „Betriebs“ und der auf der ICT-Infrastruktur stattfindenden Produktion ist mit anderen Organisationseinheiten einer ICT-Unternehmungen bzw. ICTOrganisation, Kunden und Lieferanten in vielfältiger Art und Weise vernetzt. Ein gut organisiertes Change Management ist aus diesem Grunde ein für alle Beteiligten zwingend notwendiges Kommunikationsinstrument.

ICT Operations Control Management Eine Produktionssteuerung umfasst die Vorbereitung der Produktion (Arbeitsvorbereitung (AVOR)), die Freigabe und die Beendigung der Produktionsaufträge. Die Steuerung und Überwachung erfolgt zeitnah durch so genannte Realtime-Systeme. Hierbei kann die Steuerung in einem gewissen Rahmen direkt in den Produktionsprozess eingreifen (z.B. Druckauftrag anhalten). Eine Voraussetzung für die Überwachung der Produktionsabläufe sind in Realtime verfügbare Rückmeldungen über den aktuellen Zustand. In der Fertigungsindustrie ist dies auch unter dem Stichwort Betriebsdatenerfassung (z.B. Anzahl gefertigter Teile oder im ICT-Bereich die Anzahl gedruckter Kontoauszüge) bekannt. Neben der Steuerung und Überwachung sind diese Betriebsdaten unter anderem auch für die Leistungsverrechnung relevant. Zwecks Veranschaulichung der typischen Produktionstätigkeiten auf der Basis einer ICT-Infrastruktur folgen nun zwei in Kurzform „idealisierte“ Produktionsbeispiele: Produktionsbeispiel 1: Monatlicher Ausdruck der Kontoauszüge; arbeitsvorbereitend müssen die (vereinfacht formuliert) entsprechenden Datenbank-Auswertungen vorliegen, die entsprechenden Druckfiles generiert und die Drucker mit dem richtigen Papier bestückt sein. Mit der Aktivierung des Druckjobs startet die Produktion, die einem Seriendruck entspricht.

242

Prozessbereiche und Prozesskategorien

Abb. 99. ICT Operations Control Management

Die Überwachung registriert die Anzahl der gedruckten Briefe, die Anzahl der noch zu druckenden Briefe, die Zustände der einzelnen Drucker etc. Muss ein Drucker neu mit Papier versorgt werden, wird der Druckprozess angehalten oder auf einen anderen Drucker umgeleitet. Parallel erfolgt stichprobenartig eine Qualitätskontrolle der Druckqualität. Abschließend werden für die spätere Leistungsverrechnung die Mengen des verbrauchten Materials, die Anzahl der gedruckten Einheiten, die benötigte Rechnerzeit, die Arbeitszeiten des Personals etc. festgehalten. Produktionsbeispiel 2: Betreiben eines Servers von 6:00 bis 22:00 Uhr; arbeitsvorbereitend muss vor 6:00 Uhr (vereinfacht formuliert) der Server betriebsbereit gemacht werden. Soweit das System nicht sowieso permanent läuft, heißt dies: Betriebssystem hochfahren, Netzwerkverbindungen herstellen, Datenbanksystem aktivieren, Applikations-Software starten, Funktionalität und Betriebsbereitschaft prüfen. Mit der Freischaltung der

Prozessbereich Operations

243

Nutzung durch die Anwender beginnt die „Produktion“. Die Überwachung registriert die Anzahl der aktiven Anwender, den Datenverkehr, die Datenbankzugriffe, die CPU-Auslastung etc. Bedingt eine Zustandsmeldung (z.B. begrenzte Datenbankkapazität) einen Eingriff in die „Produktion“, erfolgt diese durch den Systemoperator. Im laufenden Betrieb werden für die spätere Leistungsverrechnung die Anzahl der aktiven Anwender, die Anzahl der Datenbankzugriffe, Anzahl und Aufwand für Eingriffe des Systemoperators, die verbrauchte Rechnerzeit etc. festgehalten. Die Produktion wird um 22:05 durch eine Datensicherung und das anschließenden Herunterfahren des Systems beendet. In der Prozesskategorie ICT Operations Control Management sind die Produktionsprozesse und die Prozesse der Steuerung und Überwachung zusammengefasst. Wir unterscheiden drei Prozesse: • 521 Production Control beinhaltet die Aufgaben, die die Produktion regeln und steuern. • 522 System Monitoring regelt die Überwachung der für die Produktion eingesetzten Systeme. • 523 Output Management, ein einerseits typischer Produktionsprozess in einem ICT-Unternehmen, andererseits aufgrund des erzeugten Produktes und der dafür benötigten Logistik speziell erwähnenswert. Der Prozess 521 Production Control regelt die Vorbereitung, die Durchführung und die Überwachung und Steuerung des Produktionsverlaufs. Er beinhaltet zwei Aufgabenketten. Die erste regelt den Produktionszyklus55, die zweite die Überwachung und Steuerung der Produktion. Die erste Aufgabenkette wird durch folgende Ereignisse angestoßen: • Periodisch; die zeitliche Steuerung orientiert sich in diesem Fall an den vorgegebenen Produktionsterminen. Grundsätzlich können drei „Terminvarianten“, die vor allem auf die Vorbereitungsphase erheblichen Einfluss haben, unterschieden werden: o Einmaliger, sporadischer Produktionstermin, z.B. eine Serienbriefproduktion im Zusammenhang mit einer Vertriebsaktion. Typisch ist, dass der Auftrag „unerwartet“ kommt, er hat also eine gewisse Überraschungskomponente und muss in das laufende Geschäft in55

Unter einem Produktionszyklus verstehen wir die Vorbereitung, die Durchführung sowie die Nachbereitung der Produktion.

244

Prozessbereiche und Prozesskategorien

tegriert werden (Sonderfall). Es besteht wenig Spielraum beim Termin, eine Vorproduktion ist nicht möglich. o Mehrmaliger, regelmäßiger Produktionstermin, z.B. ein monatlicher Rechnungslauf. Typisch ist, dass der Auftrag gut planbar ist, da Art und Umfang bekannt sind. Es liegen Erfahrungswerte vor, der Auftrag ist nach einiger Zeit fest eingeplant und damit „fester“ Bestandteil des Geschäfts (Routinefall). Es besteht ein gewisser Spielraum bei den Terminen, eine Vorproduktion ist teilweise möglich. o Permanente Produktion – typisch, wenn ein System (z.B. Server) permanent betrieben wird, d.h. der Server wird zu einem bestimmten Termin hochgefahren (Produktionsbeginn) und ist dann dauernd und theoretisch unbeschränkt produktiv. Das geplante Herausnehmen (Produktionsabbruch) und das Wiedereinführen (Produktionsstart) des Systems in den Betrieb (z.B. aufgrund von Wartungsarbeiten) ist terminlich gesehen gut planbar und in der Ausführung Routine. • Produktionsvorgabe erstellt, ein Resultat der Prozesse des 51 ICT Operations Planning. Die Produktionsvorgaben erhalten neben Terminvorgaben auch eine Vielzahl von weiteren Vorgaben wie z.B. Mengen, Zeit-, Aufwands-, Material- und Qualitätsvorgaben sowie zur Verfügbarkeit, Kapazitätsbedarf und Performance. Insbesondere bei regelmäßigen oder permanent laufenden Produktionen, bei denen die Termine quasi bereits fest eingeplant sind und die Arbeitsvorbereitung Routinecharakter haben, löst dieses Ereignis alle notwendigen Arbeiten zur gegebenenfalls erneuten Vorbereitung eines Produktionszyklus aus. • Outputproduktion abgeschlossen ist das abschließende Ereignis des Prozesses 523 Output Management. Es aktiviert die Aufgaben, die mit dem Abschluss eines Produktionsvorgangs verbunden sind. Die Aufgabenkette, die die Produktionszyklen regelt, hat folgende Prozessergebnisse: • Materialbedarf ermittelt, typisches Ergebnis der Arbeitsvorbereitung; in der Regel handelt es sich hierbei um eine Überprüfung und Konkretisierung des Bedarfes. Das Material sollte zu diesem Zeitpunkt im Lager und damit direkt verfügbar sein, insbesondere bei kurzfristig laufenden Vorbereitungen. Die Bereitstellung und gegebenenfalls die Beschaffung sind im Prozess 742 Material & Inventory Management geregelt.

Prozessbereich Operations

245

• Verrechnungsdaten zusammengestellt; alle für die Verrechnung der Leistung notwendigen Daten wurden gemäß den Vorgaben zusammengestellt. Das Ereignis löst im Prozess 141 Service Charging die Rechnungsstellung aus. • Produktionsbericht erstellt; der jeweilige Bericht löst in den folgenden Prozessen die jeweils beschriebenen Aktivitäten aus: o 113 Supply Chain Management; wurde die Leistung oder Teile davon durch einen externen Lieferanten erbracht, wird dies analysiert und gegebenenfalls Maßnahmen zur Optimierung eingeleitet. o 162 QM-System; hier wird auf Basis des Produktionsberichts überprüft, ob die Qualitäts-Vorgaben erreicht bzw. eingehalten wurden. o 223 Contract Monitoring; hier dienen die Produktionsberichte dazu, die Vertragserfüllung zu prüfen und zu dokumentieren. • Produktion abgeschlossen; alle Aufgaben eines Produktionszyklus wurden durchgeführt. • Output produktionsbereit; im Produktionsprozess wurde ein Zustand erreicht, der die Produktion eines Outputs (Drucken, Bespielen von Datenträgern etc.) ermöglicht. Die Produktion des Outputs ist im Prozess 523 Output Management geregelt. • Produktion gestartet; der Produktionsprozess wurde gestartet. Das Ereignis löst die zweite Aufgabenkette des Prozesses 521 Production Control aus, der die Steuerung und Überwachung des Produktionsprozesses steuert. Die zweite Aufgabenkette des Prozesses 521 Production Control wird durch das vorhergehende Ereignis ausgelöst. Folgende Ereignisse nehmen Einfluss auf die Steuerung des Produktionsprozesses: • Monitoringbericht erstellt, ein Ergebnis des Prozesses 522 Systems Monitoring. Damit liegen Ist-Werte der „Produktionsumgebung“ vor, die mit den Soll-Werten der Produktionsvorgabe abgeglichen werden. Abweichungen können einen Eingriff in die Steuerung der Produktionsprozesse zur Folge haben • Produktionsauswirkung definiert ist ein Resultat der Störungsanalyse im Prozess 522 Systems Monitoring. Abhängig von der Art der Auswirkungen muss gegebenenfalls in die Steuerung des Produktionsprozesses eingegriffen und im Extremfall die Produktion gestoppt werden.

246

Prozessbereiche und Prozesskategorien

• Material bereitgestellt resultiert aus dem Prozess 742 Material & Inventory Management. Die Verfügbarkeit des Materials nimmt Einfluss auf die Produktion; insbesondere wenn es zu Engpässen kommt, muss in die Steuerung des Produktionsprozesses eingegriffen werden. Im Rahmen der Überwachungsaufgaben können Ereignisse auftreten die evtl. die Produktion stören. Wird solch ein Event identifiziert, stößt dieser die notwendige Ursachenanalyse im Prozess 522 System Monitoring an. Eine Produktionsüberwachung im ICT-Bereich umfasst einerseits die permanente Kontrolle der Bereitschaft und Verfügbarkeit der ICT-Infrastruktur (System Monitoring), andererseits die Aufsicht über die Durchführung und die Qualitätskontrolle der Produktionsaufträge, die auf der ICT-Infrastruktur abgewickelt werden. Die Überwachung und Steuerung der ICT-Infrastruktur, also der Systeme, auf denen die Produktion erfolgt, wird im Prozess 522 System Monitoring geregelt. Der Prozess wird durch das Ereignis Produktion gestartet (521 Production Control) ausgelöst. Er beinhaltet die Überwachung der Systeme, die Feststellung und Analyse von Abweichungen bei kritischen Messgrößen, im Störungsfall die Störungs- und Problemanalyse sowie die Feststellung bzw. Abschätzung der Auswirkungen der Störung auf die Produktion. Die Ereignisse Event identifiziert, ein Ergebnis der Produktionsüberwachung im Prozess 521 Production Control, das auf eine Störung im Produktionsprozess hinweist und Known Error definiert (421 Problem Handling), aktiviert die Störungs- und Problemanalyse des Prozesses. Dabei ist ein Known Error eher eine proaktive Überprüfung, die herausfinden soll, ob der Known Error evtl. eine System- und / oder Produktionsstörung zur Folge haben kann. Ergebnisse des Prozesses 522 System Monitoring sind: • Monitoring Bericht erstellt; periodisch werden die vorgegebenen Messkriterien und deren Messwerte in einem Monitoring-Bericht dokumentiert. Diese stoßen in den folgenden Prozessen jeweils entsprechende Analyseaktivitäten an: o 512 Availability Management o 513 Capacity & Performance Management o 521 Production Control

Prozessbereich Operations

247

• Produktionsauswirkungen definiert, Ergebnis der Störungs-, Problemanalyse, die von „unbedeutend“ bis „Notfall“ reichen kann und im Prozess 521 Production Control die Steuerung der Produktionsprozesse beeinflusst. • Notfall eingetreten; Ergebnis der Störungs-, Problemanalyse, die mit so gravierende Störungen konfrontiert ist wie z.B. einem Brand im Rechenzentrum, einem Totalausfall der Stromversorgung oder der Kommunikationsverbindungen; dann liegt ein Notfall vor, der eine Aktivierung des Prozesses 712 Emergency Process erfordert. • Problem identifiziert; eine erkannte Störung liegt dauerhaft vor und kann nicht beseitigt werden. Das Ereignis löst im Prozess 421 Problem Handling die Problemanalyse aus. Ein von der Regelung und der Gestaltung her einfacher, aber bei sehr großen Volumina aufgrund der damit zusammenhängenden Logistik durchaus komplexer Prozess ist das (523) Output Management. Unter „Output“ wird hier primär die (Massen)-Übertragung von Daten auf ein bestimmtes Medium verstanden. Dies kann eine Übertragung auf Papier, Mikrofilm, magnetische oder optische Datenträger sein oder auch ein elektronischer Versand via Mail oder Filetransfer. Im Fall eines Druckauftrages (z.B. Kontoauszüge) ist die Auslieferung der Druckerzeugnisse, zumindest bis zur Übergabe an die Post, eine Aufgabe des Prozesses. Abhängig von den verwendeten Medien und dem Volumen kommen für diese Aufgaben z.T. umfangreiche Systeme wie z.B. Großdrucker, Sortier- und Verpackungsmaschinen, robotergesteuerte Speichermedien etc. zum Einsatz. Der Prozess wird durch das Ereignis Output produktionsbereit, Resultat des Prozesses 521 Production Control, angestoßen. Gleichzeitig muss das Ereignis Material bereitgestellt eingetreten sein. Dies bezieht sich hier auf die Verfügbarkeit von ausreichenden Speichermedien bzw. Druckerpapier, welche zeitnah über den Prozess 742 Material & Inventory Management bereitgestellt werden. Den Abschluss des Prozesses bilden die zwei Ereignisse Output geliefert und Output-Produktion abgeschlossen. Das letztgenannte Ereignis schließt den damit verbundenen Produktionsauftrag im Prozess 521 Production Control ab.

248

Prozessbereiche und Prozesskategorien

Prozessbereich Customer Services Der Kundenservice ist der Bereich, der in der Summe die meisten und intensivsten Kontakte zu den Kunden der Unternehmung aufweist. Hier sei an die zwei an anderer Stelle bereits erwähnten Ausprägungen der Rolle „Kunde“ erinnert. Der Kunde ist erstens Auftraggeber und Vertragspartner und damit primärer Ansprechpartner des Sales-Bereiches. Zweitens ist er Leistungsempfänger bzw. Leistungsbezieher, der vor allem über den Kundenservice mit dem Unternehmen kommuniziert. Gerade bei Firmenkunden gehören dessen Mitarbeiter in diese Kategorie. Aus organisatorischer Sicht repräsentieren der Help- oder Servicedesk einer ICT-Unternehmung und die Servicetechniker, die vor Ort beim Kunden Installationen und Reparaturen durchführen, den Kundenservice. Der Kundenservice hat verschiedene Funktionen, die einerseits klar auf der Hand liegen, andererseits quasi im Verborgenen wirken. Die offensichtlichen Funktionen sind: • Beratung, evtl. auch Schulung und Unterstützung der Kunden bei der Nutzung der gelieferten bzw. bereitgestellten Leistungen • Reparaturleistungen, Lieferung von Ersatzteilen • allgemeine Anlauf- und Informationsstelle für Anfragen aller Art Die weniger offensichtlichen und oft auch unterschätzten Funktionen sind: • Sichern und Ausbau der Stammkunden • Imagesteuerung und -pflege • Aufnahme von Kundenrückmeldungen bzgl. der Zufriedenheit mit den gelieferten Produkten bzw. erbrachten Leistungen sowie deren Praxistauglichkeit Der Aspekt Sichern und Ausbauen von Stammkunden erscheint auf den ersten Blick als eine ausschließliche Tätigkeit des Vertriebsbereiches. Allerdings haben Dienstleistungen die Eigenheit, dass die Wahrnehmung der Dienste, die durch Menschen erbracht werden, maßgeblich durch die Persönlichkeit des Dienstleistungserbringers geprägt wird. Zusätzliche Hardware (wie z.B. Peripherie), individuelle Kundenkonzeptionen, Schulungsleistungen, Wartungsverträge etc. lassen sich oftmals durch den Service-

Prozessbereich Customer Services

249

techniker vor Ort wesentlich einfacher verkaufen56 als durch den zweimal im Jahr agierenden Verkaufsbeauftragten. Betrachtet man unter diesem Gesichtspunkt Outsourcing-Maßnahmen57, darf es so manchen internen wie externen IT Service Provider nicht wundern, dass er mittelfristig auch seine Kunden mit outsourct. Der Kundenservice nimmt einen nicht zu unterschätzenden Einfluss auf das Halten und Ausbauen von Stammkunden. Die Persönlichkeit der Dienstleistungserbringer mit direktem Kundenkontakt prägt das Verhältnis des ICT-Unternehmens zum Kunden. Der Prozessbereich Customer Services beinhaltet eine Vielzahl von Schnittstellen zum Kunden. Im Modell haben wir diesem Bereich die folgenden Prozesskategorien zugeordnet: • Planung und Überwachung des Kundenservices (61 ICT Customer Services Planning and Monitoring) • Das Contact Management (62 ICT Customer Contact Management), welches die Kommunikationsschnittstelle zum Kunden ist; hierüber werden alle in das ICT-Unternehmen eingehenden und die an die Leistungsbezieher gerichteten Kontakte gesteuert. Darüber hinaus finden sich hier das für ein ICT-Unternehmen typische Incident- und Autorisations-Management. Weiter werden hierüber auch eingehende Beschwerden abgewickelt. • Planung, Steuerung und Ausführung von Serviceleistungen vor Ort (63 ICT On-Site-Services) 56

Gründe dafür sind persönliche Nähe und ein damit verbundenes Vertrauensverhältnis. Der betreuende Mitarbeiter kennt seinen Kunden, er kann situationsbezogen „passende“ Lösungen verkaufen. Er gilt aus Sicht des Kunden als technischer Spezialist, dessen persönliche Empfehlung einen hohen Stellenwert hat.

57

Eine Geschichte aus der Praxis: Ein mittleres Systemhaus hatte den IT-ServiceSupport vor Ort beim Kunden an ein darauf spezialisiertes Unternehmen ausgelagert. Das Systemhaus und der Unterlieferant überwarfen sich. Aufgrund der starken Vor-Ort-Position des Unterlieferanten konnte er seine Position beim Kunden behaupten und in der Folge sogar bewirken, dass der Kunde sich einen neuen Hard- und Software-Lieferanten suchte.

250

Prozessbereiche und Prozesskategorien

Abb. 100. Prozessbereich Customer Services

• Planung und Erbringungen von Schulungsleistungen58 (64 ICT Customer Education Management) Teile der in diesem Kapitel behandelten Themen werden in ITIL unter den Titeln Customer Relationship Management, Service Desk und Incident Management behandelt. ITIL liefert hierzu weitergehende Informationen wie z.B. den organisatorischen Aufbau, benötigte Skill-Profile, Auswahl von Tools etc. ITIL verwendet den Begriff „Single point of Contact” um die Bedeutung und die Funktion des Service Desks zu betonen. Im idealisierten Fall laufen alle tagtäglichen Kontakte zwischen dem Serviceerbringer und dem Servicenutzer über den Service Desk. Während der klassische Help-DeskAnsatz darauf basiert, den Kunden primär bei der Nutzung der Services, 58

Wir haben diese Leistungen unter dem Aspekt, dass hauptsächlich Schulungsleistungen für eigene Produkte erbracht werden, im Kundeservice positioniert.

Prozessbereich Customer Services

251

z.B. im Störungsfall zu unterstützen (Incident Management), hat ein Service Desk umfassendere Aufgaben wie z.B.: • Bearbeitung von Service Requests (inkl. Bestellungen), • Bearbeitung von Änderungswünschen, • Unterstützung bei Fragen zu Rechnungen, aber auch • die Übernahme einer aktiven Rolle wie z.B. die Information der Servicenutzer über anstehende Changes etc. ICT Customer Services Planning and Monitoring Die Bereitstellung eines Kundenservices sowie die Erbringung dieser Leistung werden im Wesentlichen durch folgende Faktoren bestimmt: • Welche Standardleistungen werden angeboten? (inklusive Varianten in Form von Service Levels59) • Welche kundenspezifischen, individuellen Leistungen60 werden angeboten? Aufgrund der Erfahrungen und der oftmals bereits langfristig bestehenden Kundenbeziehungen sind bei Standardleistungen der Ressourcenbedarf und die Besonderheiten (z.B. typische Kommunikationsspitzen61) i.d.R. bekannt und damit einfacher zu planen und zu koordinieren. Insbesondere individuelle Serviceleistungen, die nur für einen bestimmten Zeitraum benötigt werden, sind bzgl. Planung und Koordination aufwändiger. So oder so, das Ressourcenmanagement ist hier die Herausforderung.

59

Beispiel einer allgemeinen Leistung: Bereitstellung eines Help Desks; Service Level A: Help Desk verfügbar Mo.- Fr. von 8:00 – 17:00; Service Level B: Help Desk verfügbar Mo.- Fr. von 7:00 – 19:00 und Sa. von 8:00 –12:00; Service Level C: Help Desk verfügbar 7 Tage, 24 Stunden.

60

Beispiel: Bereitstellung von zwei PC-Servicetechnikern vor Ort beim Kunden, von Mo. bis Fr. 8:00 bis 17:00.

61

In vielen Unternehmen liegen die Kommunikationsspitzen mit dem Service Desk am Vormittag zwischen 9:00 und 11:00 sowie am Nachmittag zwischen 13:00 und 15:00.

252

Prozessbereiche und Prozesskategorien

Abb. 101. ICT Customer Services Planning and Monitoring

Der Prozess 611 Customer Services Planning wird von drei Gruppen von Ereignissen angestoßen: •

Das Ereignis Kundenservice-Planungsauftrag freigegeben ist ein Resultat des Prozesses 212 Bid Management. In der Folge werden für den geforderten Leistungsumfang des gewünschten Kundenservices die Rahmenbedingungen, der Ressourcenbedarf und der Aufwand kalkuliert. Dieser Teilprozess endet mit dem Ergebnis Kundenservice-Offerte erstellt, welches dann wieder den Prozess 212 Bid Management aktiviert, in den die Resultate in das Gesamtangebot integriert werden.

•

Die definitive Planung inkl. Bedarf und Einsatzplanung der Ressourcen sowie die inhaltliche Vorgabe, welche Leistungen für welchen Kunden zu erbringen sind, erfolgt nach Eintritt der folgenden

Prozessbereich Customer Services

253

Ereignisse: Kundenserviceauftrag freigegeben und Kundenserviceauftrag beendet (beides mögliche Ergebnisse des Prozesses 222 Contract Administration) oder periodisch (z.B. wöchentlich). Ergebnisse dieser Planung können vor allem auch bei der Erweiterung des bestehenden Angebotes sein: o Infrastrukturbedarf ermittelt, z.B. wenn aufgrund zusätzlich verkaufter Leistungen im Contact Center mehr Arbeitsplätze benötigt werden. Diese Anforderung wird dann über den Prozess 741 Facility Management abgewickelt. o Ausbildungsbedarf ermittelt, z.B. wenn eine neue Applikation beim Kunden eingeführt wird, die durch den Help Desk unterstützt werden soll und die Help-Desk-Mitarbeiter das entsprechende Know-how benötigen. (Dieses Ereignis triggert den Prozess 151 Professional Development an). o Prozessänderung identifiziert, z.B. wenn eine kundenspezifische Anforderung62 eine Veränderung der Bearbeitungsprozesse und / oder der damit verknüpften Regelungen enthält, kann es notwendig sein, die entsprechenden Veränderungen über das 164 Process Management zu realisieren. o On-Site-Einsatz notwendig; typisch für kurzfristige, individuelle Serviceleistungen, die vor Ort beim Kunden zu erbringen sind (z.B. Help Desk vor Ort im Rahmen einer Neueinführung). Die weitere Bearbeitung erfolgt im Prozess 631 On Site Dispatching. o Content-Änderung definiert; die Entwicklung neuer oder die Modernisierung bestehender Kundendienstleistungen kann dazu führen, dass entsprechende Leistungen im Internet angeboten werden. Die entsprechende Erweiterung des Contents erfolgt im Prozess 625 Content Management. o Planung Kundenservice erstellt; das selbsterklärende Hauptergebnis des Planungsprozesses.

62

Anpassungen von Arbeitsschritten an kundenspezifische Sicherheitsanforderungen haben oftmals Anpassungen von Prozessen zur Folge. Dies kann auch Prozesse betreffen, die nichts mit der unmittelbaren Leistungserbringung zu tun haben. Beispiel: Aufgrund einer bestimmten Sicherheitsanforderung müssen zukünftig bereits im Einstellungsprozess bestimmte Voraussetzungen geprüft werden.

254

•

Prozessbereiche und Prozesskategorien

Während einer bestehenden Vertragsbeziehung kann es aufgrund bestimmter Ereignisse notwendig sein, die Planung insbesondere bzgl. des Ressourceneinsatzes zu überarbeiten. Stellvertretend haben wir die drei folgenden Ereignisse berücksichtigt: o Vertragsabweichungen identifiziert als Ergebnis des Prozesses 223 Contract Monitoring; typische Beispiele sind, wenn z.B. Reaktionszeiten bei Störungsmeldungen nicht eingehalten werden oder die Erreichbarkeit des Service Desks nicht sichergestellt ist. o Q-Ziele vorgegeben werden im Prozess 162 QM-System und nehmen unmittelbar Einfluss auf die Vorgaben des Kundenservices. o Prozessvorgabe erstellt resultiert aus dem Prozess 164 Process Management. Neue bzw. angepasste Prozesse oder damit verbundene Rollen, Mess- und Entscheidungskriterien und Ähnliches müssen in der Planung und in der Umsetzung der Kundenserviceleistungen entsprechend berücksichtigt werden.

Der Prozess 612 Customer Services Monitoring ist ein periodisch (z.B. täglich) aktivierter Prozess, der die Leistungserbringung im Kundenservice gemäß den Planungen und Vorgaben überwacht. Mit dem Ergebnis Produktionsbericht erstellt, welches die Prozesse 113 Supply Chain Management, 162 QM-System und 223 Contract Monitoring anstößt, wird der Prozess beendet. Die Ressourcen – und die daraus folgende Einsatzplanung – ist eine der Haupttätigkeiten bei der Organisation der Leistungserbringung durch den Kundenservice. Die Anforderung, Leistungen einerseits günstig – sprich mit wenig und „günstigem“ Personal –, andererseits mit optimaler Qualität zu erbringen, ist in der Praxis hier zu lösen.

ICT Customer Contact Management Das ICT Customer Contact Management beinhaltet eine Gruppe von Prozessen, die in ihrer Gesamtheit den „Single point of Contact“ der ICTUnternehmung aus Sicht der Prozesse repräsentieren: • 621 Contact Management ist der Prozess, über den eingehende sowie die systematisch geplanten und sich an eine größere Anzahl von

Prozessbereich Customer Services

Abb. 102. ICT Customer Contact Management

255

256

Prozessbereiche und Prozesskategorien

Kunden richtenden, ausgehenden Kontakte63 abgewickelt werden. Hierbei ist das Kommunikationsmedium (Telefon, Mail, Fax, Brief, Chat-Räume etc.) sekundär. Insbesondere die eingehenden Kontakte müssen nach ihrer Art identifiziert, an die richtige Stelle weitergeleitet und in den meisten Fällen auch dokumentiert werden. • 622 Incident Management, der bedeutsamste Kundenserviceprozess einer ICT-Unternehmung; immer dann, wenn der Kunde mit der Nutzung der betreuten IT-Infrastruktur bzw. den genutzten Softwaresystemen Schwierigkeiten hat und in der Nutzung bzw. seiner Arbeit beeinträchtigt wird, wird sein Fall als Incident behandelt und im Rahmen dieses Prozesses wenn möglich gelöst, oder es wird zumindest eine Umgehungslösung gefunden. • 623 Complaint Management behandelt die Beschwerden und stellt sicher, dass das ICT-Unternehmen eine wichtige Quelle für Verbesserungen aller Art nutzt. Weiter wird sichergestellt, dass keine Beschwerde verloren geht. • 624 Authorization Management; aus Sicht des Service Desks einer ICT-Unternehmung steht hier die Funktion, einem Kunden den Zugang zu den angebotenen Systemen zu ermöglichen, im Vordergrund. • 625 Content Management; die Homepages vieler ICT-Unternehmen haben heute schon eher den Status einer in Teilen für alle zugänglichen Web-Applikation. Seien es nun einfache Informationsseiten oder für Kunden reservierte Seiten mit speziellen Funktionen (z.B. automatische Passwortrücksetzung) oder ein Internetshop – das Content Management stellt die Aktualität der entsprechenden Internetseiten sicher. Im Mittelpunkt steht der Prozess 621 Contact Management. Dieser teilt sich in zwei Stränge auf, wobei der erste die Inbound64, also die eingehenden Kontakte behandelt und der zweite die Outbound-Aktivitäten steuert. 63

In der Praxis führt die Diskussion der Abgrenzung, welche Kommunikation mit dem Kunden unter dem Stichwort „Single point of contact“ zu verstehen ist und welche davon im Sinne eines zentralistischen Ansatzes zu organisieren ist, zu den unterschiedlichsten Lösungsansätzen. Entscheidend ist, dass für jede Art von Kommunikation und Kommunikationspartner eine adäquate Lösung definiert wird.

64

Inbound / Outbound sind typische Begriffe einer Call-Center-Organisation. Die Kontaktaufnahme zu dem Service Desk einer ICT-Unternehmung erfolgt zu über 90% telefonisch, gefolgt von E-Mail, so dass der Betrieb eines Call-Centers eine typische Umsetzung eines Service-Desks darstellt.

Prozessbereich Customer Services

257

Die den Prozess auslösenden Ereignisse lassen sich in drei Gruppen gliedern. • Kontaktaufnahme durch einen Kunden, Partner, Lieferanten etc., • Rückmeldungen aus einem anderen Prozess, die z.B. zu einer Kontaktaufnahme zum Kunden führen, • Auftrag zur systematischen Kontaktaufnahme mit mehreren, ausgewählten Kunden. Auf das vom externen Partner (Kunden, Lieferanten etc.) ausgelöste Ereignis Kontakt aufgenommen wird der Kontakt zwecks Bearbeitung angenommen. In der Praxis wird der Kunde heute, insbesondere bei engen und andauernden Kundenbeziehungen, bereits mit der telefonischen Kontaktaufnahme durch den Bearbeitungsprozess gesteuert. Dies erfolgt z.B. durch Einsatz von IVR65. (Beispiel: „…für Hardware-Probleme wählen Sie die 1, für Software-Probleme wählen Sie die 2 …) Kann der Kunde z.B. über seine Telefonnummer oder die Eingabe einer Kundennummer identifiziert werden, können unter Verwendung von CTI66 bereits weiterführende Kundeninformationen (z.B. aktuelles Service Level Agreement des anrufenden Kunden) dem Service-Desk-Mitarbeiter online zur Verfügung gestellt werden. Heute stehen vielfache informations- und kommunikationstechnologische Möglichkeiten zur Verfügung, die das Contact Management technisch unterstützen und optimieren (Stichwort „Customer Relationship Management“, CRM). Ohne auf diese Vielfalt im Speziellen einzugehen ist es heute quasi Standard, dass jeder Kontakt mit seinen Grunddaten in einer entsprechenden Datenbank erfasst wird und somit die Grundlage für eine evtl. Weiterbearbeitung und Überwachung des von ihm ausgelösten Geschäftsvorfalls bildet. In der Praxis hat sich hierbei der Begriff „Ticket“ als Überbegriff für den im Zusammenhang mit einem Kontakt angelegten und damit verknüpften Datensatz eingebürgert.

65

Interactive Voice Response, z.B. Sprachwahl oder Eingabe von Kunden- oder Identifikationsnummern etc. über die Telefontastatur.

66

Computer Telephony Integration, z.B. Verknüpfung von Datenbanksystemen mit der Telefonanlage zwecks Bereitstellung von anruferspezifischen Daten.

258

Prozessbereiche und Prozesskategorien

Nach der Kontaktannahme erfolgt typischerweise die Triage67 und somit die Festlegung der weiteren Bearbeitungsschritte. In unserem Modell haben wir folgende Triageergebnisse berücksichtigt: • Incident identifiziert, d.h. der Kunde kann die gewünschte Leistung (z.B. eine Applikation) nicht wie benötigt nutzen. Die weitere Bearbeitung erfolgt im Prozess 622 Incident Management. • Reklamation identifiziert; eine Kunde oder Lieferant beschwert sich, weitere Behandlung in 623 Complaint Management. • Autorisationsanfrage identifiziert; z.B. ein Kunde hat sein Passwort vergessen oder kann aufgrund eines verwehrten Zugriffs auf eine bestimmte Applikation nicht zugreifen. Dies aktiviert den Prozess 624 Authorization Management. • Content-Änderung definiert; z.B. aufgrund einer Nachfrage nach einem auf der Website beschriebenen, aber nicht mehr aktuellen Angebot. Dies führt zu den Aktivitäten des Prozesses 625 Content Management. • Leistungsanfrage formuliert; der Kontakt interessiert sich für ein Produkt, eine Leistung des ICT-Unternehmens. Dies aktiviert die entsprechenden Verkaufsprozesse (211 Sales Management), indem diese Anfragen zu einer Bestellung oder einem Angebot führen. • Lieferstatuts angefordert; in diesem Fall muss die benötigte Information z.B. vorgängig bei einem Unterlieferanten der ICT-Unternehmung eingeholt werden. Hierbei ist natürlich zu berücksichtigen, dass im Rahmen der Triage i.d.R. lediglich der weitere Bearbeitungsprozess ausgewählt wird. Damit ist nicht zwingend der Wechsel zu einem anderen Sachbearbeiter verbunden. Erfolgt aufgrund der Triage keine weitere Verzweigung in einen anderen Prozess, da der Kunde z.B. nur eine Information zu einem bestimmten Vorgang (z.B. zu einer Bestellung wünscht), wird der Bearbeitungsstatus des entsprechenden Vorgangs geprüft. Diese Aktivität wird auch durch die folgenden Ereignisse ausgelöst:

67

In der Betriebswirtschaftslehre, speziell in der Wirtschaftsinformatik, spricht man von Triage, wenn die Segmentierung von Kundenwünschen bzw. externen Anforderungen gemeint ist.

Prozessbereich Customer Services

259

• Pendenz erstellt, was einer terminierten Wiedervorlage innerhalb dieses Prozesses oder resultierend aus dem Prozess 211 Sales Management entspricht. • Lieferstatus gemeldet; dieses Ereignis kann von einem externen Partner gemeldet werden oder von einem der folgenden Prozesse, die eine Lieferung beeinflussen. Ob dieses Ereignis tatsächlich eine Aktivität wie z.B. eine Kontaktaufnahme mit den Kunden auslöst, ist natürlich abhängig davon, ob der Kunde bei Erreichung eines bestimmten Status kontaktiert werden muss68: o Prozess 334 Distribution Planning meldet z.B. die geplanten Liefertermine. o Prozess 335 HW / SW Distribution meldet z.B., ob die Ware zur Auslieferung bereitsteht und ob die Auslieferung bereits erfolgt ist. o Prozess 633 Installation & Relocation Management meldet wann und mit welchen Ergebnissen ein System installiert wurde. Ist es notwendig, dass aufgrund der Ergebnisse aus der Überprüfung des Bearbeitungsstatus der Vertrieb beim Kunden aktiv wird, wird eine Wiedervorlage erstellt. Dieses Ereignis aktiviert die entsprechenden Aktivitäten im Prozess 211 Sales Management. Kann die Anfrage eines Kunden direkt oder nach Abklärungen bzw. durch andere Prozesse beantwortet werden, werden die Ergebnisse dem Kunden mitgeteilt. In unserem Modell liefern folgende Prozesse Ergebnisse, die eine Kontaktaufnahme mit dem Kunden vorsehen können: • 422 Error Control, mit dem selbsterklärenden Ereignis Problem gelöst. • 622 Incident Management, • 623 Complaint Management, • 624 Authorization Management, • 625 Content Management. In den letztgenannten Prozessen werden fallspezifisch Kundeninformationen erstellt, die den Kunden mitzuteilen sind. Die abschließenden Ergebnisse des Contact Management Prozesses für den Kunden sind: 68

Dies ist der Fall, wenn der Kunde bestimmte Vorbereitungen (z.B. Zugang zu einem Gebäude zwecks Installation) zu treffen hat.

260

Prozessbereiche und Prozesskategorien

• Anfrage bearbeitet, wobei hier die abschließende Bearbeitung gemeint ist und davon ausgegangen wird, dass dies zur Zufriedenheit des Kunden erfolgte. • Bearbeitungsstatus aktualisiert, der Kunde kennt somit den aktuellen Bearbeitungsstatus einer offenen Anfrage bzw. einer Bestellung. Der Prozess und damit der Kontakt wird mit einem entsprechenden Eintrag in der Datenbank bzw. im „Ticket“ abgeschlossen. Der zweite Prozessstrang des Contact Managements umfasst die so genannten Outbound-Aktivitäten. Während beim Inbound die Organisation quasi passiv ist und auf die Kontaktaufnahme durch den Kunden wartet, wird sie beim Outbound selbst aktiv. Hierbei geht es weniger darum, einen einzelnen Kunden zu kontaktieren, sondern vielmehr um eine gezielte Kommunikationsstrategie, in der innerhalb eines bestimmten Zeitraums eine Vielzahl von Kunden mit einer bestimmten Zielsetzung kontaktiert wird. Typische Outbound-Aktivitäten einer ICT-Unternehmung können z.B. sein: • Kundenbefragung (Zufriedenheitsanalyse, Marktstudie etc.) • Telefonverkauf • Krisen- / Eskalationsintervention • gezielte Information ausgewählter Kundengruppen Das Ereignis Outbound-Aktivität definiert kann das Ergebnis einer Kundenrückmeldungsaktion innerhalb des Contact-Management-Prozesses oder ein Resultat der folgenden Prozesse sein: • 131 Marketing Management mit dem Ziel, eine Marketingaktion durchzuführen. • 412 Change Planning & Control mit dem Ziel, Kunden über einen bevorstehenden Change zu informieren. • 421 Problem Handling mit dem Ziel, Kunden über ein bestehendes Problem zu informieren und Lösungsvorschläge zu unterbreiten (z.B. auch Rückrufaktion). Mit dem Ergebnis Kunde kontaktiert wird der Prozess abgeschlossen.

Prozessbereich Customer Services

261

Die Organisation eines Service Desks erfolgt heute primär auf der Basis einer Call-Center-Organisation. Der Einsatz von informations- und kommunikationstechnologischen Hilfsmitteln hat in diesem Bereich einen hohe Automations- und Reifegrad erreicht. Unabhängig hiervon muss sichergestellt sein, dass jeder Kontakt dokumentiert, nachverfolgt und damit auch der damit verbundene Bearbeitungsprozess im Interesse des Kunden und der Unternehmung überwacht werden kann. Der in einem ICT-Unternehmen innerhalb des Service Desks am häufigsten zu bearbeitende Geschäftsvorfall ist die Bearbeitung von Störungsmeldungen. Unter einer Störung (Incident) ist hier die Behinderung eines Kunden aufgrund der Funktionseinschränkung eines informations- sowie kommunikationstechnologischen Arbeitsmittels zu verstehen. Dies umfasst Totalausfälle, eingeschränkte Nutzungen von Netzwerken, Datenbanken und Applikationen bis hin zu schlichten Unkenntnissen des Kunden, bestimmte Funktionen zu nutzen. Die Störungsbehebung bzw. die Sicherstellung, dass der Kunde gegebenenfalls auch auf Basis einer Umgehungslösung (Workaround) weiterarbeiten kann, ist die Zielsetzung des Prozesses 622 Incident Management. Wird ein Incident identifiziert, in unserem Modell ein Resultat des Prozesses 621 Contact Management, wird spätestens an dieser Stelle ein „Ticket“ eröffnet. Dieser fallspezifische Datenbankeintrag ist über den gesamten Bearbeitungsprozess hinweg für alle Bearbeitungsstellen die Grundlage für die Dokumentation und Kommunikation. Anschließend erfolgt die Analyse der Störung. Hierbei können aus Sicht des Incident Managements drei grundsätzliche Situationen ermittelt werden: 1. Es handelt sich um einen Notfall (Notfall eingetreten). Dieser in der Praxis eher seltene, aber nicht auszuschließende Fall aktiviert den Prozess 712 Emergency Prozess. An dieser Stelle sei der Hinweis erlaubt, dass die Definition eines Notfalls sehr kundenspezifisch sein kann. So ist der Ausfall eines PCs, eines Servers für den normalen IT-Fachmann ein gewöhnliches Tagesereignis und noch lange kein Grund, einen Notfall anzunehmen. Handelt es sich bei dem ausgefallenen oder gestörten System aber um das System, das eine Herz-Lungen-Maschine steuert, eine zentrale Funktion in der Flugsicherung innehat, Zahlungsflüsse oder einen Bankomaten steuert, kann dies durchaus für die direkt Betroffenen einen Notfall darstellen.

262

Prozessbereiche und Prozesskategorien

2. Die Behinderung des Kunden kann direkt oder unmittelbar z.B. durch erläuternde Hilfestellung (fehlendes Wissen seitens des Kunden), Remote Support69, Bereitstellung einer Umgehungslösung (z.B. im Fall eines bereits bekannten Fehlers – Known Error) oder eine sonstige Handlungsanweisung behoben werden. Ist die Störung definitiv behoben und ist keine weitere Bearbeitung notwendig, wird der Prozess abgeschlossen, der Vorgang dokumentiert (Kundeninformation erstellt) und der Kunde bei Bedarf über den Prozess 621 Contact Management informiert. 3. Die Störung kann nicht direkt behoben oder es kann nur eine Umgehungslösung angeboten werden. In diesem Fall wird der Incident (bzw. das „Ticket“) zur weiteren Bearbeitung weitergeleitet. In unserem Modell haben wir folgende Fälle berücksichtigt: o On-Site-Einsatz notwendig, in diesem Fall muss ein Techniker vor Ort sein, z.B. um eine Hardware-Komponente auszutauschen. (631 On-Site Dispatching). o RFC formuliert, wird ein Request for Change formuliert70, der im Prozess 411 Change Handling bearbeitet wird, kann davon ausgegangen werden, dass bestimmte Störungen bzw. daraus resultierende Störungsmeldungen / Anfragen durch gewisse Veränderungen z.B. in Bearbeitungsprozessen oder in Systemeinstellungen verhindert werden können. o Problem identifiziert; in diesem Fall kann davon ausgegangen werden, dass es sich um ein echtes, sich vermutlich wiederholendes Problem71 handelt, welches im Prozess 421 Problem Handling intensiver zu untersuchen ist. Wird das Problem dort eindeutig erkannt, wird es zu einem so genannten „Known Error“, also einem 69

70

71

Zugriff des Technikers via Netzwerk auf den PC / Server des Kunden und direkte Durchführung der notwendigen Maßnahmen auf dem Endgerät. Praxisbeispiel (Großunternehmung): Bei der Auslieferung von PCs wird oftmals eine Reihe von Kabeln mitgeliefert, die nicht benötigt werden. Typische Fragen an den Service Desk sind: „Was ist damit zu tun? Sind Sie für das Recycling verantwortlich?“ „Ich brauche das nicht und will den entsprechenden Gegenwert in Geld zurück“ usw., der RFC: dem Kunden nur das abgeben, was er wirklich braucht. Praxisbeispiel: Kunden einer bestimmten Notebookserie melden Schwierigkeiten mit dem Akku. Die Analyse im Rahmen des Problem Managements ergab, dass die Akkus einer bestimmten Produktionsserie nur 20% der definierten Kapazität erreichten.

Prozessbereich Customer Services

263

bekannten Fehler, für den dann auch entsprechende Handlungsanweisungen für den Customer Support definiert werden können. Ein effizientes Incident Management wird erheblich durch die Erfahrung und das Know-how der Service-Desk-Mitarbeiter beeinflusst. Trotz der vielfältig eingesetzten Technik muss oftmals auf der Basis weniger Informationen die richtige Diagnose getroffen werden. Auch wenn durch die Möglichkeiten des Remote Supports heute die Diagnosemöglichkeiten wesentlich erweitert werden, nimmt vor allem die Erfahrung und das Know-how Einfluss auf die Dauer und Qualität der Diagnose. Wird im Rahmen der Triage im Prozess 621 Contact Management eine Reklamation identifiziert, erfolgt deren weitere Bearbeitung im Prozess 623 Complaint Management. Die Bedeutung, der Umgang mit Beschwerden sowie Chancen und Risiken, die mit Beschwerden verbunden sind, werden ausführlich in umfangreicher Fachliteratur behandelt. In unserem Modell geht es vor allem um die Berücksichtigung der Beschwerde an sich und um deren möglichen Einfluss auf andere Prozesse. Die Grundfunktionen des Beschwerde-Managements liegen in der Aufund der Annahme derselben, der anschließenden Analyse (Ursache und Wirkung) sowie den daraus abzuleitenden Maßnahmen. Wir haben die folgenden Ergebnisse berücksichtigt: • Reklamation eskaliert; in diesem Fall wird z.B. das Management der Unternehmung eingeschaltet und informiert. Ebenso wird der Prozess 211 Sales Management angestoßen, in welchem mögliche Konsequenzen aus vertrieblicher Sicht geprüft werden und gegebenenfalls der Kontakt mit dem Kunden bzw. mit dem Auftraggeber gesucht wird. • Verbesserung vorgeschlagen; oft beinhalten Beschwerden auch mögliche Lösungsansätze. Werden diese im Rahmen des BeschwerdeManagements erkannt, können sie über den Prozess 161 Audit & CIP in den kontinuierlichen Verbesserungsprozess eingebracht werden oder gar einen Qualitäts-Audit auslösen. • RFC formuliert; ist direkt ersichtlich, dass Änderungen in den Prozessen der Unternehmung, der Produkte oder anderen Bereichen vorliegen, kann eine entsprechende Änderung beantragt werden, die dann im Prozess 411 Change Handling weiter bearbeitet wird.

264

Prozessbereiche und Prozesskategorien

• Verrechnungsdaten zusammengestellt, eine typische Wiedergutmachung; im Reklamationsfall ist das die Erstellung einer Gutschrift, die Gewährung eines Preisnachlasses oder ähnliches. In diesem Fall wird der Prozess 141 Service Charging angestoßen, indem z.B. eine neue Rechnung erstellt wird. Ist die Reklamation abschließend bearbeitet, wird der Prozess abgeschlossen, der Vorgang dokumentiert (Kundeninformation erstellt) und der Kunde bei Bedarf über den Prozess 621 Contact Management informiert. Als Kardinalfehler im Beschwerde-Management kann das Verlieren und Versickern von Reklamationen im Unternehmen bezeichnet werden. Jeder hat wohl schon Vergleichbares erlebt, wenn er zum x-ten Male reklamieren musste, jedes Mal einen neuen Ansprechpartner bekam und jedes Mal die Reklamation neu erfasst wurde. Der Gesichtspunkt „Sicherheit“ ist ein zunehmend dominierendes Thema beim Einsatz von kommunikations- und informationstechnologischen Lösungen. Ein kleiner Ausschnitt aus diesem weiten Feld ist der i.d.R. passwortgeschützte Zugang zu Systemen. Werden komplexe Applikationen und Plattformen eingesetzt, sind oftmals vielschichtige Zugangsregelungen im Einsatz, die auch oft eine zentrale Stelle zwecks Einrichtung entsprechender Zugangsberechtigungen benötigen. Im tagtäglichen Geschäft gliedert sich diese Autorisationsthematik, die mit dem Prozess 624 Authorization Management behandelt wird, in drei Hauptfunktionen: 1. Einrichten des Zugangs 2. Deaktivieren des Zugangs 3. Passwortrücksetzung Der Prozess wird durch zwei Ereignisse angestoßen: 1. Autorisationsanfrage identifiziert via 621 Contact Management; in diesem Fall benötigt der Kunde Zugang zu einem System. Hatte der Kunde bisher keinen Zugang, muss dessen Berechtigung überprüft werden; anschließend muss der Zugang eingerichtet und aktiviert werden. Die dafür notwendigen Prozeduren sind kundenspezifisch und können komplex sein.

Prozessbereich Customer Services

265

Bereits hier können aufgrund der Anfrage und der zur Verfügung gestellten Hintergrundinformationen Sicherheitsprobleme erkannt72 werden, die im Prozess 731 Security Management weiter bearbeitet werden. Handelt es sich um ein reines Passwortproblem, kann dieses zurückgesetzt werden. Manchmal sind Passwortprobleme auch Hinweise für einfache Hackerangriffe. 2. Zugriffsberechtigung deaktiviert, Resultat der Prozesse 222 Contract Management und 731 Security Management; einem Kunden oder einer Kundengruppe wird der Zugang zu den Systemen z.B. aufgrund einer Vertragsbeendigung oder aus sonstigen Sicherheitsgründen gesperrt. Sind die Autorisationstätigkeiten abgeschlossen, wird der Vorgang dokumentiert (Kundeninformation erstellt) und der Kunde bei Bedarf über den Prozess 621 Contact Management informiert. Die einfache Rücksetzung von Passwörtern online durch den Anwender selbst (self service) wird heute für nicht kritische Applikationen technologisch gut unterstützt. In sensiblen Bereichen, in denen heute mit einer Vielzahl von Kombinationen von Sicherheitssystemen gearbeitet wird, wird das klassische Passwort durch eine Kombination von verschiedenen Sicherheitselementen ersetzt. In unserem Modell haben wir die Pflege und den Unterhalt der Internetseiten einer ITC-Unternehmung mit dem Prozess 625 Content Management thematisch in den Bereich des Customer Services integriert. Hierfür sprechen mehrere Gründe: • Sucht der Kunde Zugang zum Unternehmen, ist die Internetseite eine der ersten Anlaufstellen. • Die Kontaktaufnahme via Internetseite, i.d.R. Generierung einer EMail, ist heute eine Standardfunktion.

72

Praxisbeispiel: Ein Firmenkunde möchte den Zugang über einen nicht freigegebenen, da nicht sicheren Kommunikationskanal und teilt gleichzeitig mit, dass er diesen schon für andere Zugänge problemlos nutzt.

266

Prozessbereiche und Prozesskategorien

• Viele Anbieter unterhalten heute Foren und Chat-Räume, in denen sich die Anwender untereinander bzgl. des Einsatzes der Produkte austauschen können. Auch Problemstellungen und Fragen werden dort durch die Entwickler und Techniker öffentlich diskutiert. • Die Bereitstellung eines Internet-Shops und die darüber gesteuerte Abwicklung von Bestellungen ist für ICT-Unternehmen, die entsprechende Produkte anbieten, ein Muss. • FAQ-Seiten sind ebenso Standard. • Die Auflistung bekannter Fehler und Lösungen sind gängige Inhalte von Web-Sites von ITC-Unternehmen. • Die Einrichtung von Download-Centern, in denen von Dokumenten über Patches bis zu Programm-Upgrades alles Notwendige für die Behebung von Problemen angeboten wird. Der Einsatz des Internets, gerade auch im Supportbereich, bietet eine Vielzahl von Möglichkeiten. Unser Prozess hierfür ist relativ einfach gehalten. Er wird durch das Ereignis Content-Änderung definiert angestoßen, welches ein Resultat folgender Prozesse sein kann: • 131 Marketing Management, z.B. Bereitstellung neuer Produkte • 611 Customer Services Planning, z.B. Einrichtung neuer Dienstleistungen • 621 Contact Management, z.B. Ergänzungen / Korrekturen aufgrund Kundenrückmeldungen Der Prozess beinhaltet die Aktivitäten, den Content gemäß den Vorgaben zu ändern; abgeschlossen wird er durch die entsprechenden Tätigkeiten und das Ergebnis Web-Content geändert. Bei Bedarf werden Kundeninformationen zusammengestellt und darauf basierend die Kunden über den Prozess 621 Contact Management informiert. Speziell für ICT-Unternehmen, die selbst Hard- / SoftwareSysteme entwickeln, hat das Internet als Kundenservice-Plattform eine hohe Bedeutung. Verfügbarkeit rund um die Uhr und weltweiter Zugriff, geschickt genutzt und optimal auf die eigenen Produkte abgestimmt, können erhebliche Wettbewerbsvorteile generieren.

Prozessbereich Customer Services

267

Abb. 103. ICT On-Site Services

ICT On-Site Services Der On-Site Service umfasst die Kundendienstleistungen, die das ICTUnternehmen am Sitz seiner Kunden, also vor Ort erbringt. Diese Leistungen können umfangreicher Natur sein und reichen von der Installation und Inbetriebnahme von Systemen über Reparatur- und Wartungsarbeiten bis zur Unterstützung der Anwender vor Ort. Im Vordergrund stehen hierbei

268

Prozessbereiche und Prozesskategorien

vor allem Dienstleistungen für lokale Netzwerke, lokale Server, Clientsysteme sowie die Peripheriegeräte wie Drucker, Scanner etc. Die folgenden drei Prozesse decken in unserem Modell diesen Bereich ab: • 631 On-Site Dispatching regelt im Wesentlichen die Einsätze des Servicepersonals vor Ort. • 632 Repair Management beinhaltet die Aktivitäten der Störungsbehebung und der Reparatur der Systeme vor Ort. • 633 Installation & Relocation Management umfasst die Installation von Systemen, deren Inbetriebnahme und Übergabe an den Kunden sowie als Sonderfall die Umzugsunterstützung. Abbau, Transport und erneute Installation sind gerade in Großunternehmen Standardleistungen des On-Site-Services. Mit der rasanten Entwicklung der dezentralen Systeme und der Vielzahl der Peripheriegeräte sind vor allem in den 90er Jahren des letzten Jahrhunderts die Kosten für Serviceleistungen vor Ort in die Höhe geschossen, denn Serviceleistungen vor Ort und die dazugehörigen Fahrtzeiten sind personalintensiv und damit teuer. Die technologische Entwicklung in der letzten Dekade, insbesondere die Möglichkeiten des Remote Supports, haben hier eine kostendämpfende Wirkung entfaltet. Vor allem Großunternehmen sind in den letzten Jahren dazu übergegangen, Vor-Ort-Services gezielt outzusourcen. Ein Kunde, der auf technische Hilfsmittel, wie sie die Informations- und Kommunikationstechnologie zur Verfügung stellt, angewiesen ist, erwartet im Störungsfall eine rasche und effektive Hilfe. Hierzu gehört bei Bedarf auch die Unterstützung vor Ort, die rein psychologisch für den Kunden die beste Form der Unterstützung ist, da: • der Ansprechpartner „greifbar“ und nicht anonym ist, • die Störungsanalyse aus Sicht des Kunden vor Ort durch einen Experten erfolgt, • die Tätigkeiten sichtbar vor Ort erfolgen und zumindest subjektiv der Eindruck da ist, dass am Problem gearbeitet wird und somit insgesamt ein Kontrollgefühl vorhanden ist. Kann eine Störung nicht über das Incident Management und via Remote Support gelöst werden und ist somit ein On-Site-Einsatz notwendig, löst

Prozessbereich Customer Services

269

dieses Ereignis den Prozess 631 On-Site Dispatching aus. Ein On-SiteEinsatz muss nicht zwingend vom Prozess 622 Incident Management ausgelöst werden, auch Aktivitäten in anderen Prozessen können zu diesem Ergebnis kommen: • 222 Contract Administration, vor allem im Zusammenhang mit der Freigabe eines Kundenserviceauftrages, für den die Ressourcen hier geplant werden, dessen Ausführung aber im Prozess 633 Installlation & Relocation Management geregelt ist, oder wenn z.B. mit Vertragsende Systeme abgebaut und abgeholt werden müssen. • 334 Distribution Planning, z.B. bei Systemlieferung mit Installationsauftrag • 611 Customer Services Planning, z.B. wenn dem Kunden eine spezielle Dienstleistung, die einen On-Site-Service beinhaltet, verkauft wurde. • 622 Incident Management (erwähnt) • 741 Facility Management, wenn z.B. bautechnische Maßnahmen einen entsprechenden Einsatz (z.B. Neuverkabelung) bedingen. Ein weiteres auslösendes Ereignis ist, wenn ein Change terminiert (aus 412 Change Planning & Control) wurde und für dessen Umsetzung vor Ort Leistungen zu erbringen sind. Im On-Site-Dispatching werden primär die verfügbaren Ressourcen auf die angewiesenen Aufträge verteilt und die Ausführungsaufträge erteilt. In der Praxis liegt die Herausforderung darin, ein ausgewogenes Gleichgewicht zwischen kurzfristig erfolgten und sofort durchzuführenden Einsätzen (z.B. Reparaturaufträge) und langfristig geplanten Einsätzen (z.B. Changes) zu finden. Die Ergebnisse dieses Prozesses können sein: • Ausführungstermin bestätigt, Terminbestätigung, die sich primär an den Kunden richtet. • On-Site-Einsatz beauftragt, Ergebnis der Einsatzplanung für die einzelnen Mitarbeiter, speziell auch für kurzfristig geplante Einsätze (typischerweise Support oder Reparatureinsatz), stößt den Prozess 632 Repair Management oder 633 Installlation & Relocation Management an. • Einsatzplan erstellt und Kapazitäts- u. Skillbedarf erstellt; beide aktivieren den Prozess 152 Human Resource Planning, in welchem die gesamten Personalkapazitäten der Unternehmung gesteuert werden. • Change geplant, Rückkopplung zum Prozess 412 Change Planning & Control, wenn z.B. ein von diesem Prozess vorgegebener Ausfüh-

270

Prozessbereiche und Prozesskategorien

rungstermin nicht realisiert werden kann und eine neue Terminfestlegung erfolgen muss. Vor-Ort-Einsätze sind zunehmend nur noch dann notwendig, wenn Hardware angefasst und bewegt werden muss. Dies gilt für Reparaturen, Wartungsarbeiten sowie Installationen und Deinstallationen. Spezialfälle sind Umzüge (Abbau, Transport, Installation) und Veränderungen an der Grundinfrastruktur (Renovationen, Umbauten), die gerade in Großunternehmen häufig sind. Der typisch kurzfristig durchzuführende Support-Einsatz wird über den Prozess 622 Incident Management ausgelöst. Durch den Prozess 631 OnSite-Dispatching wird dieser koordiniert und der On-Site-Einsatz beauftragt. Dieses Ereignis löst den Prozess 632 Repair Management aus, der die Aktivitäten der Störungsbehebung vor Ort regelt. Der Ablauf für eine Störungsbehebung vor Ort teilt sich in zwei mögliche Aufgabenketten: Zuerst erfolgt die Problemanalyse. Führt das Ergebnis dazu, dass mit den vorhandenen Mitteln das Problem gelöst werden kann, wird die Störung behoben. Wird zur Störungsbeseitigung zusätzliche Hard- oder Software oder anderes Material benötigt, muss dieses vorgängig bestellt werden. Meist handelt es sich dabei um Ersatzteile oder auch um einen Komplettaustausch. In diesem Fall wird der Prozess durch die folgenden Ereignisse angestoßen: • Materialbedarf ermittelt, welches den Prozess 741 Material & Inventory Management aktiviert, der das notwendige Material beschafft und bereitstellt. • Produkt bestellt, mit dem über Prozess 213 Order Management die benötigte Hard- und Software bestellt wird. Sind die bestellten Komponenten verfügbar, kann die Behebung der Störung fortgesetzt werden. Im Modell wird dies durch die folgenden Ereignisse ausgelöst: • HW geliefert oder SW geliefert; der Prozess 335 HW / SW Distribution hat die bestellte Hardware oder Software geliefert. • Material bereitgestellt; der Prozess 742 Material & Inventory Management hat das benötigte Material geliefert.

Prozessbereich Customer Services

271

Im Rahmen der Reparatur und der Störungsbehebung kann gegebenenfalls die Konfiguration des Systems so geändert werden, dass dies in der Konfigurations-Datenbank entsprechend nachgeführt werden muss. Dies ist vor allem der Fall, wenn wichtige Hardware-Komponenten wie z.B. eine Netzwerkkarte ausgetauscht werden. Wird dies in der Konfigurations-Datenbank nicht nachgeführt, verfügt der Service Desk beim nächsten Incident für die Störungsdiagnose über falsche Informationen. Der Prozess 632 Repair Management wird mit den folgenden Ergebnissen abgeschlossen: • Servicebericht erstellt, zu Händen des Kunden und zur weiteren Bearbeitung in den Prozessen 113 Supply Chain Management (wenn die Leistung z.B. durch einen externen Servicetechniker erbracht wurde) und 223 Contract Monitoring zwecks Überwachung der vereinbarten Leistungserbringung • Verrechnungsdaten zusammengestellt als Grundlage für die Verrechnung der erbrachten Leistung durch den Prozess 141 Service Charging • CI geändert; d.h. ein in der Konfigurations-Datenbank geführtes Objekt wurde durch die Prozessaktivitäten verändert, und im optimalen Fall wurde diese Veränderung auch gleichzeitig in der entsprechenden Konfigurations-Datenbank nachgeführt. Die Änderung eines Configuration Items (CI) aktiviert73 die Prozesse 432 CI-Verification und 433 Configuration Documentation. Reparaturen erfolgen i.d.R. unter einem hohen zeitlichen Druck und für den Servicetechniker in einer angespannten Atmosphäre (gestresster Anwender). Oft fehlt aufgrund des Zeitdrucks die Disziplin, die Änderungen an Configuration Items in der entsprechenden Konfigurationsdatenbank nachzuführen. In der Praxis ist es heute leider so, dass die meisten Konfigurationsdatenbanken eine unbefriedigende Datenqualität aufweisen, die sich unter anderem durch Veränderungen vor Ort begründen.

73

An dieser Stelle muss darauf hingewiesen werden, dass in der Praxis nicht jede Änderung eines Configuration Item unmittelbar die erwähnten Prozesse anstößt. Meist ist es so, dass die genannten Prozesse periodisch (z.B. monatlich) oder bei Erreichung einer bestimmten Menge (z.B. 1000 Änderungen) aktiviert werden. Das Modell bildet die logische Verknüpfung ab.

272

Prozessbereiche und Prozesskategorien

Für die Lieferung neuer Systeme gibt es grundsätzlich zwei Varianten: 1. Der Auftrag ist mit der vollständigen Lieferung „frei Rampe“ für das ICT-Unternehmen als Auftragnehmer abgeschlossen. (In diesem Fall wird die entsprechende Bestellung in unserem Modell im Prozess 335 HW / SW Distribution mit der Auslieferung der Hardware bzw. Software abgeschlossen). 2. Schlüsselfertige Lieferung; d.h. der Auftrag beinhaltet neben der Lieferung auch die Installation des gelieferten Systems inkl. der Inbetriebnahme. Während der erste Fall typisch für Privatanwender ist, ist der zweite Fall eher typisch für Firmenkunden. Eine besondere Aufgabenstellung der „schlüsselfertigen Bereitstellung“ von Arbeitsplätzen sind auch die speziell bei Großunternehmen regelmäßig stattfindenden Umzüge ganzer Organisationseinheiten. Die logistische Aufgabenstellung besteht darin, einerseits die Basisinfrastruktur (z.B. Verkabelung, Stromzuführung, etc.) bereitzustellen, andererseits die Client-Infrastruktur in den alten Räumlichkeiten abzubauen und an dem neuen Ort wieder neu zu installieren. Der Prozess 633 Installation & Relocation bildet diese beiden Aufgabenstellungen, die schlüsselfertige Installation von Systemen sowie die Realisierung von Umzügen, ab. Die schlüsselfertige Installation von vom Kunden bestellten Systemen bedingt neben dem eigentlichen Kundenauftrag, dass intern der On-SiteEinsatz beauftragt wird. Dies erfolgt im Prozess 631 On-Site Dispatching. Weiter müssen vom Prozess 335 HW / SW Distribution die HW geliefert und die SW geliefert sowie gegebenenfalls vom Prozess 742 Material & Inventory Management das benötigte sonstige74 Material bereitgestellt werden. Sind diese Ereignisse eingetroffen, kann die Installation, der Test des Systems sowie dessen Übergabe an den Kunden erfolgen. Der Prozess wird mit dem Ereignis System geliefert abgeschlossen. Weitere Ergebnisse dieses Prozesses sind: • Servicebericht erstellt, zu Händen des Kunden und zur weiteren Bearbeitung in den Prozessen 113 Supply Chain Management (wenn die Leistung z.B. durch einen externen Servicetechniker erbracht wurde) und 223 Contract Monitoring zwecks Überwachung der vereinbarten Leistungserbringung. 74

Z.B. Verlängerungskabel, Mehrfachsteckdosen etc.

Prozessbereich Customer Services

273

• Verrechnungsdaten zusammengestellt, als Grundlage für die Verrechnung der erbrachten Leistung durch den Prozess 141 Service Charging • CI geändert; d.h. ein in der Konfigurations-Datenbank geführtes Objekt wurde durch die Prozessaktivitäten verändert und im optimalen Fall wurde diese Veränderung auch gleichzeitig in der entsprechenden Konfigurations-Datenbank nachgeführt. Die Änderung eines Configuration Items (CI) aktiviert75 die Prozesse 432 CI-Verification und 433 Configuration Documentation. • Change realisiert; angenommen, es werden mehrere Systeme installiert und in unserer ICT-Unternehmung besteht die interne Vorgabe, dass Installationen von mehr als 10 Systemen unter der Kontrolle des Change Managements realisiert werden müssen, würde dieses Ergebnis im Prozess 412 Change Planning & Control die Aktivitäten anstoßen, die nach der Realisierung eines Changes erfolgen. Umzüge, die den Abbau und die erneute Installation von Systemen beinhalten sowie oftmals im Vorfeld entsprechende Vorarbeiten benötigen, werden immer unter der Kontrolle des Change Managements abgewickelt. Sie schließen damit den Prozess immer mit dem Ergebnis Change realisiert ab. Damit die für Umzüge typischen Projektaktivitäten durchgeführt werden können, muss zusätzlich zu dem primären, den Prozess auslösenden Ereignis On-Site Support beauftragt auch zusätzlich der Kundenauftrag freigegeben werden. Dies ist ein Ergebnis des Prozesses 222 Contract Management. Größere Umzüge im Umfeld der ICT-Infrastruktur (z.B. mehrere Dutzend PC-Arbeitsplätze) laufen immer unter der Kontrolle des Change Managements ab! Weiter wird in solch einem Fall eine Vielzahl von Dateninformationen der umgezogenen Objekte, die als Configuration Items in der Konfigurations-Datenbank abgelegt sind, verändert. Diese Änderungen müssen entsprechend nachgeführt werden!

75

An dieser Stelle muss darauf hingewiesen werden, dass in der Praxis nicht jede Änderung eines Configuration Items unmittelbar die erwähnten Prozesse anstößt. Meist ist es so, dass die genannten Prozesse periodisch (z.B. monatlich) oder bei Erreichung einer bestimmten Menge (z.B. 1000 Änderungen) aktiviert werden. Das Modell bildet die logische Verknüpfung ab.

274

Prozessbereiche und Prozesskategorien

Abb. 104. ICT Customer Education Management

ICT Customer Education Management Eine für sich separate Wertkette für ein ICT-Unternehmen76 stellt das Produkt „Schulung“ dar. Typische Schulungsthemen, die ein ICT-Unternehmen anbietet, sind z.B.: 76

Vor allem große ICT-Unternehmen, die parallel zu ihren Hard- und SoftwareProdukten ein ausgeprägtes Schulungsangebot haben, profitieren mehrfach. Neben dem Fakt, dass sie ihre Kunden an den eigenen Produkten schulen und damit deren Einsatz sicherstellen, sowie der separaten Wertschöpfung haben sie einen erheblichen Vorteil für die Ausbildung der eigenen Mitarbeiter. Sie können auf eine optimales und kostengünstiges Schulungsangebot zurückgreifen, das von ihren Kunden finanziert wird!

Prozessbereich Customer Services

275

• Technische Themen der Informatik und der Kommunikation wie Programmiersprachen, Datenbanken, technische Konzepte etc. • Entwicklungstechniken und Methoden • Anwenderschulungen für Applikationen inkl. Standard-SoftwareLösungen aller Art • Spezialistenschulungen für Standard-Software-Lösungen • Informatikneutrale Themen wie z.B. Projektleitung, Organisation, Arbeitstechniken Tritt das ICT-Unternehmen als Schulungsanbieter am Markt auf, bietet es in der Regel so genannte öffentliche Seminare an, die für jeden zugänglich sind und an vorgegebenen Orten stattfinden, wobei eine Durchführung i.d.R. eine Mindestteilnehmerzahl benötigt. Weiter werden firmenspezifische, so genannte Inhouse-Seminare angeboten. Typische Kunden sind Großunternehmen, die einerseits eine größere Anzahl von Mitarbeitern zum gleichen Thema schulen möchten und andererseits speziell auf die Bedürfnisse des Kunden zugeschnittene Inhalte wünschen. Termine und Ort werden hier vom Kunden vorgegeben. Eine Besonderheit sind so genannte Einführungsschulungen, die z.B. im Rahmen der Einführung einer neuen Software-Applikation oder eines neuen Releases durchgeführt werden. Hier müssen die Schulungsinhalte individuell und im Rahmen des Entwicklungsprojektes entwickelt werden. Aufgrund der Abhängigkeit zum verantwortlichen Entwicklungsprojekt wird von diesem meist auch die Einführungsschulung entwickelt und umgesetzt. Kann hierbei nicht auf eine professionelle Schulungsorganisation zurückgegriffen werden, ist das Ergebnis leider oftmals für die zukünftigen Anwender die erste Bestätigung, dass das neue System (wie erwartet) nichts taugt! Die Thematik „Schulung und Schulungsorganisation“ ist somit auch speziell für die ICT-Unternehmungen ein Thema, die Applikationen für ihre Kunden entwickeln und bereitstellen. Unser Modell ICT-Unternehmung bietet die Schulungsleistungen wie oben beschrieben in allen Ausprägungen an. Der Bereich ICT Customer Education Management bildet diese Aktivitäten in drei Prozessen ab: 1. 641 Education & Training Planning umfasst die Planung und Entwicklung des Schulungsangebots. 2. 642 Registration handling beinhaltet die Teilnehmerorganisation. 3. 643 Education processing konzentriert sich auf die Durchführung der Schulungsaktivitäten.

276

Prozessbereiche und Prozesskategorien

Wie für jede Leistung, die von der ICT-Unternehmung zu erbringen ist, steht die Planung der Leistungserbringung im Vordergrund. In unserem Modell sind hierbei zwei Angebotsarten zu planen: zum einen die öffentlichen Seminare, die i.d.R. bis zu einem Jahr im Voraus terminiert werden müssen, zum anderen individuelle Schulungsaufträge, die relativ kurzfristig beauftragt und terminiert werden. Beide Leistungen werden auch unterschiedlich verkauft. Das öffentliche Seminargeschäft wird typischerweise im Sinne eines Kataloges dem Markt präsentiert. Der Teilnehmer bestellt bzw. bucht seinen Platz, er erhält eine Teilnahmebestätigung und gleichzeitig die Rechnung, die spätestens bis zur Teilnahme zu bezahlen ist. Für individuelle Schulungen werden die Anforderungen in einem Vertriebsgespräch erhoben und die Gestaltung und Durchführung der Schulungsmaßnahme in Form eines Angebots dem Kunden vorgeschlagen. Typischerweise muss für eine individuelle Schulungsmaßnahme das jeweilige Seminar noch entwickelt oder ein Standard-Seminar entsprechend adaptiert werden. Die für die Erbringung der Schulungstätigkeiten notwendigen vorbereitenden Aktivitäten sind im Prozess 641 Education & Training Planning geregelt. Für die Planung des öffentlichen Seminarangebotes gibt es zwei wesentliche Auslöser: 1. Periodisch; bei vielen Seminaranbietern erfolgt im HalbjahresRhythmus die Planung des Angebotes für die folgenden 12 Monate. Die periodische Planung konzentriert sich hierbei vor allem auf die Auswahl der Seminarthemen, der Terminfestlegung und der benötigten Infrastruktur und Ressourcen. 2. Themenanforderungen definiert, als Ergebnisse der Prozesse 134 Product & Service Management und 151 Professional Development; dieses Ereignis löst primär die Entscheidungsprozesse aus, ob das angeforderte Thema öffentlich anzubieten ist, und bewirkt in der Folge die Seminarentwicklung. Das neu entwickelte Seminar wird dann im Rahmen der periodischen Planung berücksichtigt. Mit dem Abschluss der Planung, unabhängig davon, ob es sich um die gerade behandelten, öffentliche Seminare oder um die folgenden individuellen Schulungsangebote handelt, liegen folgende Prozessergebnisse vor: • Seminarplanung aktualisiert, was im Prozess 131 Marketing Management die entsprechenden Vermarktungs- und Werbemaßnahmen auslöst.

Prozessbereich Customer Services

277

• Infrastrukturbedarf ermittelt stellt z.B. die Bereitstellung entsprechender Räumlichkeiten mit der notwendigen technischen Ausstattung über den Prozess 741 Facility Management sicher. • Bedarf ermittelt aktiviert die Beschaffung der Verbrauchsmaterialien (Prozess 114 Purchaising), die für die Seminardurchführungen benötigt werden. • Trainerbedarf ermittelt löst im Prozess 152 Human Resource Planning die Ressourcenplanung und gegebenenfalls die Beschaffung externer Referenten aus. • Ressourcen alloziiert stellt über den Prozess 152 Human Resource Planning sicher, dass die bekannten und planbaren Ressourcen definitiv den geplanten Seminaren zugeordnet werden. Die Planung der individuellen Schulungen benötigen im Gegensatz zu den Standardseminaren einige vorhergehende Aktivitäten, die durch die folgenden Ereignisse angestoßen werden: • Schulungsplanungsauftrag freigegeben; handelt es sich um einen Schulungsauftrag, der einem Kunden angeboten wird, ist der Verkauf dieser Leistung über den Prozess 212 Bid Management geregelt. Grundlage hierfür ist ein entsprechendes Schulungs- bzw. Ausbildungskonzept, welches alle notwendigen Inhalte, Mengen und Aufwände beinhaltet. Das Ergebnis Schulungskonzept entwickelt bietet die Grundlage für die Angebotserstellung im Prozess 212 Bid Management. • Schulungsauftrag freigegeben entspricht der Auftragserteilung durch einen externen Kunden. Er löst die Seminarentwicklung gemäß den Vorgaben des Kunden aus. Die Leistungserbringung wird dann wie bei jedem Seminar bzgl. Termin, Ressourcen, Infrastruktur- und Materialbedarf geplant. • Schulung beauftragt resultiert aus den Prozessen 311 Project Planning, 332 Release Package Management und 731 Security Management. Sie betreffen die eingangs erwähnten Einführungsschulungen, die sich aufgrund von Veränderungen wie neuen Systemen, Ausrollen eines neuen Releases oder veränderten Sicherheitsregeln ergeben können. Diese Art der Schulung wird i.d.R. mit dem jeweiligen Entwicklungsauftrag durch den Kunden beauftragt.

278

Prozessbereiche und Prozesskategorien

Einführungsschulungen werden in vielen Unternehmen vernachlässigt. Wenn eine große Anzahl von Anwendern geschult werden muss, schrecken die damit verbundenen Aufwände die Verantwortlichen eher ab. In der Folge wird oft das entsprechende Budget reduziert, mit der Konsequenz, dass mit der Einführung die Produktivität stärker sinkt, als es eigentlich notwendig wäre. Das öffentliche Seminargeschäft wird im Sinne einer Katalogleistung verkauft. Auch wenn heute die Buchung eines Seminars meist über einen entsprechenden Internetauftritt erfolgt, versenden viele Anbieter immer noch klassische Kataloge, damit sie ihre potenziellen Kunden erreichen. Die Bestellung bzw. Buchung erfolgt über den Prozess 213 Order Management. Das Handling dieser Bestellung wird im Prozess 642 Registration Handling geregelt. Die den Prozess auslösenden Ereignisse sind Bestellung bestätigt bzw. Bestellung storniert, die beide Ergebnisse des Prozesses 213 Order Management sind. Die Besonderheiten bei der Verwaltung der Seminarbuchungen liegen vor allem in den durchaus sehr häufigen Ausnahmefällen. Aus Sicht der Abwicklung ist es für den Anbieter am einfachsten, wenn erstens für den Teilnehmer ein Platz verfügbar ist, zweitens das Seminar dann auch tatsächlich stattfindet und drittens der Teilnehmer nicht absagt bzw. nicht umbucht. Das Führen von Wartelisten bei überbuchten Seminaren, die Absage von Seminaren aufgrund geringer Teilnehmerzahlen und die kurzfristige Absage von Teilnehmern sind quasi Tagesgeschäft. Da es in der Branche üblich ist, dass die Rechnungsstellung mit der Buchung erfolgt und die Zahlung bis spätestens zu Seminarbeginn vorliegen muss, verursacht jede Stornierung oder Umbuchung gleichzeitig einen neuen Rechnungslauf. Die wesentlichen Ergebnisse des Prozesses sind: • Dem Kunden wird die Seminaranmeldung bestätigt. • Dem Kunden wird die Stornierung bestätigt. • Es werden die Verrechnungsdaten zusammengestellt, die den Prozess 141 Service Charging anstoßen. Die Durchführung des Seminars bzw. der vereinbarten Schulungsmaßnahme entspricht der Leistungserbringung. Die Besonderheit bei dieser

Prozessbereich Customer Services

279

Leistung ist, dass der Zeitraum der Leistungserbringung eindeutig durch Beginn und Ende sowie durch die Schulungsinhalte definiert ist. Ob die Leistung wie vereinbart erbracht wurde, kann (zumindest teilweise) durch Prüfung der Teilnehmer und / oder Beurteilung der Schulungsmaßnahme durch den Teilnehmer erfolgen. Der Prozess 643 Education Processing wird durch zwei Ereignisse angestoßen. Bei öffentlichen Seminaren geschieht dies durch die Zeit im Sinne des ausgeschriebenen Termins77. Individuelle, kundenspezifische Schulungsmaßnahmen werden gemäß der Vereinbarung mit dem Kunden gestartet. Das auslösende Ereignis Schulungsauftrag freigegeben ist ein Ergebnis des Prozesses 222 Contract Management. Die Ergebnisse des Prozesses sind: • Materialbedarf ermittelt, ein Ergebnis der abschließenden Vorbereitung; wenn noch Material benötigt wird, wird dies über den Prozess 742 Material & Inventory Management bereitgestellt. • Seminar beurteilt; die Beurteilung erfolgt durch den Teilnehmer meist auf der Basis eines standardisierten Beurteilungsbogens. Das Ereignis löst den Prozess 162 QM-System aus, in dem die Summe der Beurteilungen ausgewertet wird. • Schulungsbericht erstellt, vom Referenten bzw. Leiter der Schulungsmaßnahme; er umfasst vor allem die Zusammenfassung der Schulungsbeurteilung und im Fall einer kundenspezifischen Schulungsmaßnahme die dort vereinbarten Berichtsinhalte. Das Ereignis löst den Prozess 223 Contract Monitoring aus, in dem überprüft wird, ob zumindest gemäß Bericht die vertragliche Vereinbarung erbracht wurde. Die Organisation insbesondere von öffentlichen Seminarangeboten ist komplexer, als der erste Blick vermuten lässt. I.d.R. muss über das Gesamtangebot eine Mindestteilnehmerzahl von etwa sechs Teilnehmern erreicht werden, um kostendeckend zu arbeiten. Die Ausfallquote sollte möglichst null betragen, da ansonsten sehr schnell die Buchungszahlen zurückgehen.

77

Für den Seminaranbieter und den Referenten beginnt ein Seminar nicht mit dem im Katalog angegebenen Starttermin. Abhängig von der Art des Seminars gibt es eine Vorbereitungszeit, die insbesondere bei Seminaren mit technischer Infrastruktur mehrere Tage vor dem offiziellen Anfang beginnen kann.

280

Prozessbereiche und Prozesskategorien

Prozessbereich Logistics & Infrastructure Der Begriff „Infrastruktur“ wird heute allgemein als Überbegriff für Grundeinrichtungen verwendet, die als Basis für weitere darauf aufbauende Strukturen dienen. Aus Sicht einer Unternehmung gehören zur Infrastruktur: • Die Gebäude, deren Strom- und Wasserversorgung, Verkabelung, Klimatisierung etc. sowie deren Unterhalt und Pflege. Die Verwaltung dieser Teile der Infrastruktur wird heute organisatorisch unter dem Fachbegriff „Facility Management“ zusammengefasst. • Weiter werden auch Produktionsanlagen, Lager sowie die IT- und Kommunikationssysteme zur Infrastruktur gezählt, wobei es für deren Verwaltung und Unterhalt in den meisten größeren Unternehmen eigene darauf spezialisierte Organisationseinheiten gibt. Der Begriff „Logistik“ lässt sich im Zusammenhang mit den hier diskutierten Themen am einfachsten mit dessen militärischer Definition bzw. Aufgabe erläutern: Sicherstellen der Versorgung und des Nachschubs.

Abb. 105. Prozessbereich Logistics & Infrastructure

Prozessbereich Logistics & Infrastructure

281

Dem Prozessbereich Logistics & Infrastructure haben wir Prozesse zugeordnet, die einerseits für den Auf- und Ausbau sowie für den Unterhalt der Infrastruktur einer ICT-Unternehmung benötigt werden, andererseits für die Versorgung und den Nachschub der ICT-Unternehmung wesentlich78 sind. Wie in der vorhergehenden Abbildung dargestellt, sind diesem Bereich vier Prozesskategorien zugeordnet: 1. 71 ICT Continuity Management beinhaltet die Prozesse, die sicherstellen sollen, dass auch in einem Notfall ein Teil der IT-Infrastruktur dem ICT-Unternehmen und seinen Kunden zur Verfügung steht. 2. 72 ICT Methodic Development & Knowledge Management; die hier zugeordneten Prozesse verwalten das Know-how des Unternehmens und stellen dessen Weiterentwicklung sicher79. 3. 73 ICT Security & Technology Management beinhaltet Prozesse, die einerseits den Schutz der ICT-Infrastruktur und andererseits die technische Weiterentwicklung bzw. Modernisierung der eingesetzten Technologie sicherstellen. 4. 74 ICT Logistics & Facility Management umfasst die klassischen Prozesse für die Bereitstellung der Infrastruktur sowie der Materialund Inventarverwaltung. ICT Continuity Management Das ICT Continuity Management stellt sicher, dass die ICT-Infrastruktur oder zumindest Teile davon in einem Notfall für die Produktion, sprich die Erbringung der Leistungen gegenüber den Kunden, sichergestellt ist. Notfälle treten dann ein, wenn entscheidende Komponenten wie Server- und Kommunikationssysteme in einem Maße ausfallen, dass ein akzeptabler Betrieb bzw. die Produktion nicht mehr gewährleistet werden kann. Ursachen hierfür kann es viele geben, von der Naturkatastrophe bis zu einem Hackerangriff. Am gängigsten und gar nicht so selten wie vermutet sind 78

Im Gesamtzusammenhang des Buches haben wir Themen wie Gebäudereinigung, Betriebssicherheit und -schutz sowie Umgebungsunterhalt, Parkplatzbewirtschaftung etc. als unwesentlich eingestuft. Wir wollen deren Bedeutung für das Funktionieren einer Unternehmung damit aber nicht in Frage stellen.

79

Diese Prozesskategorie könnte auch mit der Argumentation, dass es sich hier um Themen handelt, die eher der Forschung und Entwicklung zuzuordnen sind, im Prozessbereich Management angesiedelt werden.

282

Prozessbereiche und Prozesskategorien

Abb. 106. ICT Continuity Management

schwerwiegende Störungen wie z.B. Stromausfälle und Zusammenbruch bzw. Beeinträchtigung der Kommunikation, die als Folge von anderen Ereignissen auftreten. Unternehmen wie Banken, Börsen oder solche der Telekommunikationsbranche, deren Wertschöpfung ausschließlich durch Informatik- und Kommunikationslösungen sichergestellt werden, haben selbst bei einem kurzfristigen Totalausfall z.T. erhebliche Verlustrisiken. Selbst Teilausfälle in heiklen Bereichen, z.B. in den Handelssystemen von Banken und Börsen, können in kürzester Zeit hohe Ausfallkosten generieren. Auch bei kleineren und mittleren Unternehmen ist heute ein Serverausfall meist nicht nur ärgerlich, sondern auch teuer. Da immer mehr Arbeitsplätze vernetzt sind und informationstechnologisch unterstützt werden, steigen auch die Folgekosten bei Ausfällen oder Störungen der ICTInfrastruktur. Betreibt ein ICT-Unternehmen im Kundenauftrag eine ICT-Infrastruktur, ist es heute üblich, dass Kunden sich vertraglich gegen einen Ausfall absichern. Sie fordern Lösungen, die eine Sicherstellung des Betriebes und

Prozessbereich Logistics & Infrastructure

283

damit ihrer Geschäftsprozesse auch in extremen Fällen gewährleisten. Dies reicht von der eigenen Stromversorgung über Notstromaggregate, der doppelten Auslegung von Systemen bis zum bewussten Aufbau und Unterhalt von Rechenzentren und Kommunikationszentralen an verschiedenen Orten der Welt, die einander gegenseitig als Backup-Lösung dienen. Der Branche und den Kunden sind die Risiken und die Konsequenzen, die mit Ausfällen der ICT-Infrastruktur zusammenhängen, bewusst. Allerdings werden Investitionen bzw. Budgets für entsprechende Absicherungsmaßnahmen, wenn sie nicht gerade Menschenleben gefährden, oft nur zögernd oder mit reduziertem Umfang und manchmal auch gar nicht bewilligt. Es ist wie bei einer Versicherung für den Schadensfall: So lange der Schadensfall nicht eintritt, „reut“ einen die Geldausgabe. Tritt der Schaden ein, hat man alles richtig oder falsch gemacht – abhängig davon, ob man eine Versicherung abgeschlossen hat oder nicht. Die Prozesse des ICT Continuity Management regeln die Planung und den Aufbau entsprechender Lösungen sowie die Steuerung des Notfalls. In unserem Modell sind diese Aufgaben in den folgenden drei Prozessen geregelt: • 711 Contingency Planning • 712 Emergency Process • 713 Contingency Testing Das Hauptziel aller Prozesse ist, sicherzustellen, dass die Geschäftsprozesse des Kunden auch bei einer schweren Störung, gar nicht oder nur geringfügig unterbrochen bzw. beeinträchtigt werden. Die Definition und Planung von Notfallszenarien, die Initialisierung und Umsetzung der jeweils notwendigen Maßnahmen sowie die Analyse der Risiken und Sicherheitsanforderungen werden im Prozess 711 Contingency Planning geregelt. Der Prozess wird von folgenden Ereignissen angestoßen: • Periodisch; z.B. halbjährlich werden die einzelnen Szenarien bzgl. ihrer Aktualität überprüft sowie die Planungen, die Risikoeinschätzungen, die Sicherheitsanforderungen etc. aktualisiert. • Produktionsvertrag freigegeben, ein Resultat des Prozesses 222 Contract Management. Ist mit dem Kunden eine hohe Verfügbarkeit bzw. eine Sicherstellung des Betriebes auch bei schwerwiegenden Störungen aller Art vereinbart worden, ist eine Planung und die Definition möglicher Notfallszenarien notwendig.

284

Prozessbereiche und Prozesskategorien

• Plattformangebot aktualisiert; dieses Ereignis zeigt an, dass die ICTInfrastruktur verändert wird. In diesem Fall ist zu prüfen, ob die Änderungen in irgendeiner Form die bestehenden Notfallszenarien beeinflussen oder evtl. ein neues Notfallszenario80 zu definieren ist. Die folgende Prozesse können eine Veränderung der ICT-Infrastruktur zum Ergebnis haben: o 134 Produkt & Service Management; werden neue Lösungen für Kunden entwickelt, werden hier die entsprechenden Produkte freigegeben. o 322 System Development; bereits in der Entwicklungsphase von Produkten bzw. neuen Services kann der Bedarf nach Konzepten für den Umgang mit Notfällen entstehen. o 741 Logistics & Facility Management; über diesen Prozess werden die Veränderungen der ICT-Infrastruktur gesteuert und initialisiert. • Notfallszenarien unvollständig, ein typisches Ergebnis, das im Laufe bzw. am Ende eines Testlaufes (713 Contingency Test) oder eines Ernstfalles (712 Emergency Process) eintritt; in diesem Fall müssen die entsprechenden Mängel beseitigt werden. Typische Ergebnisse des Prozesses 711 Contingency Planning sind: • Notfallszenario definiert; für einen bestimmten Fall, für einen bestimmten Kunden liegen entsprechende Notfallkonzepte vor. • Projekt vorgeschlagen; ein Notfallkonzept bedingt die Realisierung von Maßnahmen, die aufgrund ihres Umfanges oder ihrer Komplexität, z.B. Einrichtung eines Ausweichrechenzentrums, als Projekt abgewickelt werden müssen. Projekte werden über den Prozess 311 Project Planning gesteuert. • Infrastrukturbedarf ermittelt; in diesem Fall werden Anforderungen an die Infrastruktur gestellt. Typische Beispiele sind z.B. bauliche

80

Praxisbeispiel: In einem Unternehmen wurde die Betreuung von Servern durch die Schaffung einer so genannten Serverfarm optimiert. Die Server wurden hierzu räumlich zusammengelegt. In der Folge eines Wasserrohrbruchs mussten die Server aufgrund drohender Kurzschlussgefahr abgeschaltet werden. Ein Notfallkonzept war vorhanden, allerdings nicht aktualisiert. Das Konzept ging davon aus, dass die Server auf mehrere Standorte verteilt sind und deswegen a) ein Totalausfall nicht möglich ist und b) die Server sich gegenseitig als Backup dienen.

Prozessbereich Logistics & Infrastructure

285

Maßnahmen, Notstrom-Aggregate etc. Die Bereitstellung erfolgt über den Prozess 741 Facility Management. • Risiko erkannt ist ein Ergebnis der Analyse der möglichen Konsequenzen bei einem Ausfall, bei der erheblichen Beeinträchtigung einer bestimmten Leistung oder auch im Zusammenhang mit den vorgesehenen und evtl. nicht ausreichenden Maßnahmen. Dieses Ereignis nimmt Einfluss auf den Prozess 163 Risk Management. • Sicherheitsanforderungen definiert; auch bei einem Notbetrieb soll und muss die Sicherheit gewährleistet bleiben. Die entsprechenden Anforderungen unter anderen Rahmenbedingungen werden im Prozess 731 Security Management bearbeitet. Was oftmals bereits bei der Planung und Konzeption von Notfallszenarien vergessen wird: Auf die entsprechenden Notfallpläne und Konzepte muss im Notfall auch, oft an mehreren Standorten gleichzeitig, zugegriffen werden können. Eine elektronische Verfügbarkeit ist nicht immer gewährleistet. Weiter ist auch nicht immer sofort autorisiertes Personal da, welches den Zugang zu abgeschlossenen Büros, Schränken und Schreibtischen sicherstellt. Die Abwicklung eines Notfalls ablauftechnisch zu erfassen, ist – wie jeder, der schon einmal eine Krise zu managen hatte, bestätigen wird – ein theoretischer Ansatz, der im Fall einer Krise nicht wirklich hilft, in der Vorbereitung auf ein Krisenmanagement aber einen logischen Handlungsrahmen vorgibt. In unserem Modell sind die Aktivitäten, die im Notfall durchzuführen sind, im Prozess 712 Emergency Process geregelt. Prozessauslöser ist das Ereignis Notfall eingetreten als Resultat der Prozesse 622 Incident Management oder 522 System Monitoring. Im ersten Fall ist davon auszugehen, dass die Störung extern erkannt wird und über das Contact Management ins Unternehmen gelangt. Im zweiten Fall kommt die eigene Produktions- bzw. Systemüberwachung in ihrer Situations- bzw. Störungsanalyse zu diesem Ergebnis. Der erste, meist nicht sehr einfache Schritt, ist die Beurteilung der Situation und die Entscheidung, welcher oder welche Notfallpläne zu verwenden und zu aktivieren sind. Jeder Notfall, jede Krise hat ihren eigenen speziellen Verlauf. Notfallkonzepte können hier eine gewisse Sicherheit geben, indem sie z.B. sicherstellen, dass in der Hektik so wenig wie mög-

286

Prozessbereiche und Prozesskategorien

lich vergessen wird oder dass bestimmte notwendige Reihenfolgen eingehalten werden. Technische Vorschriften, Bedienungsanleitungen, Raumund Baupläne, Systemdokumentationen etc. für spezielle Verfahren sind in einer solchen Situation Gold wert! Mit Beendigung einer Krise sind alle Aktivitäten wieder auf den Normalbetrieb zurückzuführen. Oftmals werden in einer Krise bestimmte Security-Regeln und Systeme außer Kraft gesetzt, diese sind nun wieder zu aktivieren. Die notwendigen Schritte für die Wiederherstellung des Normalzustandes sind in einem Notfallplan relativ gut in Form einer Checkliste zu definieren. Hat man diese letzte Seite im Notfallplan abgearbeitet, weiß man auch, wie die ganze Abwicklung zu bewerten ist. Neben der Bewältigung der Notfallsituation zeigt der Prozess diese Ergebnisse: • Notfallstatus gemeldet; eines der ersten Ergebnisse des Prozesses ist die Information aller Betroffenen (Kunden, Lieferanten, Management, Mitarbeiter etc.). • RFC formuliert; nach jeder durchstandenen Krise gibt es eine Reihe von Änderungsvorschlägen. Meist sollen diese verhindern, dass sich ein ähnlicher Vorfall wiederholt. RFCs werden im Prozess 411 Change Handling beurteilt und weiter bearbeitet. • Notfallszenarien unvollständig, Grunderkenntnis nach der Bewältigung eines Notfalls: Irgendetwas wird immer vergessen. Dieses Ereignis bewirkt, dass erkannte Mängel und Defizite über den Prozess 711 Contingency Planning beseitigt werden. Jedes Szenario muss mindestens einmal, am besten mehrmals getestet werden. Solche Planspiele eignen sich auch immer hervorragend als Teambildungsmaßnahme. Der Prozess 713 Contingency Testing steht stellvertretend für diese Aufgabe. Er kann in drei Schritte unterteilt werden: die Planung der Übung, die selbst schon recht aufwändig sein kann, die Durchführung und die anschließende Manöverkritik. So trivial die Thematik erscheint, in Großunternehmungen können hier schnell einmal Dutzende von Mitarbeitern, Lieferanten und Kunden involviert sein. Ausgelöst wird der Prozess periodisch; d.h. je nach Vorgabe des Unternehmens oder auch der Kunden ist z.B. viertel- oder halbjährlich eine Notfallübung zu planen und durchzuführen. Auch ein Change (Change terminiert), der Risiken beinhalten kann, kann Auslöser für eine vorgängige Übung sein.

Prozessbereich Logistics & Infrastructure

287

Ganz allgemein ist das Change Management zu berücksichtigen. So sind sinnvollerweise alle größeren Übungen in Abstimmung mit dem Change Management zu planen und zu terminieren. Dadurch wird sichergestellt, dass alle potenziell betroffenen Stellen frühzeitig informiert sind und Überschneidungen mit anderen Aktivitäten vermieden werden. Ergebnisse des Prozesses sind: • Change geplant entspricht der Meldung einer geplanten Notfallübung, die in den Prozess 412 Change Planning & Control eingespeist wird. • Change realisiert löst im Prozess 412 Change Planning & Control, die Aktivitäten aus, die nach einem Change das Change-ManagementVerfahren abschließen. • RFC formuliert; ein Ergebnis eines Testlaufes kann sein, dass bestimmte Veränderungen wie z.B. Rollenverteilung, Prozessänderungen etc. notwendig sind. RFCs werden im Prozess 411 Change Handling beurteilt und weiter bearbeitet. • Risiko erkannt; eine weitere Erkenntnis eines Testlaufes können neue Risiken oder eine Neubeurteilung bekannter Risiken sein. Der Umgang mit Risiken ist im Prozess 163 Risk Management geregelt. • Notfallszenarien unvollständig; Ziel einer Übung bzw. eines Testlaufes ist es, festzustellen, ob die entwickelten Konzepte und Verfahren vollständig sind und funktionieren. Dieses Ereignis bewirkt, dass erkannte Mängel und Defizite über den Prozess 711 Contingency Planning beseitigt werden. Bei Planspielen und Notfallübungen dürfen Kunden nicht nur als Beobachter integriert werden. Kunden sollten damit konfrontiert werden, dass ihre Geschäftsprozesse unter Umständen massiv behindert werden. Denn oft können auch auf der Kundenseite Maßnahmen z.B. personeller oder organisatorischer Art getroffen werden, die zur Schadensbegrenzung beitragen.

ICT Methodic Development & Knowledge Management Die klassische Volkswirtschaftslehre bezeichnet die Faktoren „Arbeit“, „Kapital“ und „Boden“ als Produktionsfaktoren. In jüngster Vergangenheit hat sich der Faktor „Wissen“ als vierter Produktionsfaktor etabliert. Damit

288

Prozessbereiche und Prozesskategorien

Abb. 107. ICT Methodic Development & Knowledge Management

verbunden entstand mit dem Wissensmanagement eine neue Managementdisziplin. Wissensmanagement versucht, die Wissensbasis eines Unternehmens bewusst und gezielt zu verwalten, zu steuern und weiterzuentwickeln. Hierbei ist die Definition von Wissen sehr komplex. Umfasst sie doch sowohl dokumentiertes Wissen als auch die individuellen Fähigkeiten der Mitarbeiter (Kopfwissen) sowie weiter frei zugängliches (Allgemein)Wissen, erlerntes, spezialisiertes (Fach)-Wissen und geschütztes (patentiertes) Wissen. Ein Unternehmen, das forscht, entwickelt und produziert, entwickelt Spezialwissen und manchmal auch Wissen, dessen Wert für die Unternehmung gesichert und geschützt werden muss. ICT-Unternehmen, die Systeme entwickeln, haben in der Regel für ihre Entwicklungsprozesse spezifische Methoden entwickelt, die sich aufgrund der Erfahrungen ständig weiterentwickeln. Neben dem Wissensaufbau durch eigene Erfahrungen muss auch das gezielte Suchen und Integrieren von extern entwickeltem Wissen z.B. von Universitäten, Forschungsunternehmen, Herstellern, der Konkurrenz etc. für Unternehmen zum Standardrepertoire81 gehören. Diese Einstellung ist vor allem in Asien sehr weit verbreitet und schockiert uns in unserem Kulturkreis durch die Einstellung, dass fremdes 81

Hiermit ist nicht die gezielte Wirtschaftsspionage gemeint, wobei der Übergang in diesem Bereich wohl fließend ist.

Prozessbereich Logistics & Infrastructure

289

Know-how nicht (zwingend) schutzwürdig ist. Das folgende Zitat des chinesischen Philosophen Konfuzius (551 – 479 v. Chr.) liefert den kulturellen Hintergrund zu dieser Einstellung: Der Mensch hat dreierlei Wege klug zu handeln: erstens durch Nachdenken, das ist der edelste, zweitens durch Nachahmen, das ist der leichteste, und drittens durch Erfahrung, das ist der bitterste82. In der Kombination mit den in Asien derzeit bestehenden Vorteilen bei den drei klassischen Produktionsfaktoren „Arbeit“, „Boden“ und zunehmend „Kapital“ wird der vierte Produktionsfaktor „Wissen“ damit zum entscheidenden Wettbewerbsvorteil. Der Themenkreis Wissensmanagement wird im Modell mit zwei Prozessen berücksichtigt: • Der Prozess 721 Methodic Development regelt die Entwicklung und Weiterentwicklung von Methoden. Unter Methoden werden hier speziell alle Arbeitstechniken, Verfahren und Vorgehensweisen verstanden, die für die Entwicklung von ICT-Produkten bzw. -Services benötigt werden. • Der Prozess 722 Knowledge Management regelt die systematische Entwicklung der Wissensbasis im Unternehmen. Das in diesem Buch beschriebene Prozessmodell stellt ebenfalls ein erhebliches und in der geschriebenen Form theoretisches Wissen dar. In der Kombination mit dem Fach- und Erfahrungswissen von „Fachleuten“ kann es in adaptierter Form in ein gelebtes Unternehmenskonzept umgesetzt werden! Der Prozess 721 Methodic Development ist von der Gestaltung und dem Regelungsbedarf einfach. Ausgelöst wird er durch den Bedarf an einem methodischen Hilfs- bzw. Arbeitsmittel83. Wir haben hierfür in unserem Modell das Ereignis Methodenanpassung identifiziert formuliert, d.h. 82

Ersetzt man „der leichteste“ durch „der billigste“, und „der bitterste“ durch „der teuerste“, wird der Wert des Wissens deutlicher.

83

Wir verstehen hier „Methoden“ allumfassend im Sinne eines systematisch definierten Verfahrens für die Durchführung bestimmter Tätigkeiten wie z.B. Produktentwicklung, Softwareentwicklung, Angebotskalkulation, Mitarbeiterbeurteilung etc.

290

Prozessbereiche und Prozesskategorien

eine bestehende, vorhandene Methode ist zu überarbeiten bzw. an die bestehenden Anforderungen anzupassen und – wenn dies nicht möglich ist – neu zu entwickeln bzw. zu erstellen. Entsprechende Anforderungen resultieren aus den Prozessen: • 131 Marketing Management; aufgrund von Rückmeldungen und Erfahrungen bei der Entwicklung und Platzierung von Leistungen der Unternehmung wird erkannt, dass Arbeitstechniken oder Verfahren anzupassen, zu ändern oder evtl. auch neu zu entwickeln sind. • 151 Professional Development; gerade bei der Ausbildung von Mitarbeitern, die in den vom Unternehmen verwendeten Methoden und Verfahren geschult werden, werden einerseits bei der Planung, Vorbereitung und Durchführung Anpassungs- und Korrekturbedarf festgestellt, andererseits erfolgt auch im Rahmen der Ausbildung eine entsprechende Rückmeldungen der Mitarbeiter. • 161 Audit & CIP; in diesem Fall wird entweder auf der Basis eines eingereichten Verbesserungsvorschlages oder aufgrund von Erkenntnissen aus einem Qualitäts-Audit eine Anpassung einer Methodik angeregt. • 722 Knowledge Management; ausgelöst durch ermitteltes externes Wissen zu einer Methodik; zu einem Verfahren wird eine entsprechende Entwicklung bzw. Überarbeitung vorgeschlagen. Der Prozess endet mit den Ergebnissen: • Ausbildungsbedarf ermittelt, womit über den Prozess 151 Professional Development sichergestellt wird, dass die Methoden geschult werden. • Unternehmens-Methode definiert, womit die entwickelte Methodik den Mitarbeitern des Unternehmens zur Nutzung zur Verfügung gestellt wird. Die Weiterentwicklung der Wissensbasis des Unternehmens ist im Prozess 722 Knowledge Management geregelt. Periodisch, z.B. jährlich, sind die Wissensziele zu definieren, auf deren Basis einerseits der interne Wissenstand und -bedarf ermittelt wird, andererseits die Vorgaben für die externen Recherchen festgelegt werden. Das erworbene oder speziell entwickelte Wissen wird in der Folge aufbereitet, verbreitet bzw. allgemein zugänglich gemacht.

Prozessbereich Logistics & Infrastructure

291

Der Prozess kann auch ausgelöst werden, wenn an anderer Stelle Wissensdefizite erkannt werden. Dies kann in unserem Modell in folgenden Prozessen der Fall sein: • 151 Professional Development; speziell im Rahmen der Mitarbeiterentwicklung und Ausbildung ist dies ein typisches Ergebnis bei der Analyse und Beurteilung des vorhandenen Mitarbeiter-Know-hows. • 161 Audit & CIP, hier typischerweise als Resultat eines Verbesserungsvorschlages • 421 Problem Handling, eine Erkenntnis während der Problemanalyse; es fehlt an spezifischem Wissen, um ein Problem zu lösen. • 731 Security Management, in diesem Fall ein Ergebnis einer Situationsanalyse im Zusammenhang mit Sicherheitsproblemen; dies kann von fehlendem technischen Wissen bis hin zu fehlenden Rechtskenntnissen reichen. • 732 Technology Management, ausgelöst durch neue Technologien, die auf dem Markt erscheinen und für das Unternehmen wissensmäßig Neuland darstellen Die Ergebnisse des Prozesses 722 Knowledge Management sind: • Methodenanpassungen identifiziert, typisch, wenn bei einer externen Recherche neue Entwicklungsverfahren oder Varianten von im Haus bereits eingesetzten Methoden gefunden werden. • Ausbildungsbedarf ermittelt stellt die Verteilung des Wissens über den Prozess 151 Professional Development sicher. • Kapazitäts- und Skillbedarf erstellt; Wissen kann auch über die Einstellung von Personal gewonnen werden. In diesem Fall wird ein möglicher Bedarf über den Prozess 152 Human Resource Planning gesteuert. Das Thema Knowledge Management ist leider wie so viele andere Managementthemen schnell zum Marketing-Schlagwort verkommen. Nüchtern betrachtet hat jedes Unternehmen, das Forschung betreibt, schon immer ein ausgeprägtes Knowledge Management unterhalten. Unternehmen, die entwickeln, haben mit ihren Entwicklungsingenieuren und Entwicklungs-

292

Prozessbereiche und Prozesskategorien

verfahren auch viele Aspekte eines Knowledge Managements institutionalisiert. Schwer tun sich in diesem Bereich die Dienstleistungsunternehmen vor allem mit der Definition, was für sie relevantes Wissen ist.

ICT Security & Technology Management Das Faszinierende an der ICT-Branche ist, dass hier die rasante technologische Entwicklung quasi täglich in Form neuer Lösungen und Konzepte zu sehen und zu spüren ist. Dabei dreht sich das Rad zwischenzeitlich so schnell, dass auch finanzkräftige Großunternehmen nicht mehr nachkommen, jeden Entwicklungsschritt wirtschaftlich sinnvoll begründet, quasi zeitnah nachzuvollziehen. Ein Beispiel: Der flächendeckende Austausch des PC-Betriebssystems bei einer Großunternehmung, wie sie eine international tätige Großbank darstellt, die eine Vielzahl von eigenen Applikationen, Features und Sicherheitslösungen basierend auf dem eingesetzten Betriebssystem entwickelt hat, kann problemlos drei, vier und mehr Jahre dauern. In diesem Zeitraum wird heute jeweils eine neue Generation eines marktführenden PC-Betriebssystems entwickelt und auf den Markt gebracht. In vielen Unternehmen sind heute noch Systeme eingesetzt, die auf der Technologie von gestern (1990er Jahre) oder vorgestern (1980er Jahre) basieren. Die Unternehmen müssen also nicht nur den laufenden technologischen Wandel verfolgen und für ihr Unternehmen steuern. Sie müssen auch sicherstellen, dass die bestehenden Lösungen lange genug betriebsfähig bleiben, regelmäßig modernisiert, schließlich abgelöst und ersetzt werden. Wer die Integration neuer Technologien und die rechtzeitige Ablösung der eingesetzten Technologie in das richtige Gleichgewicht zwischen Kosten und Nutzen bringt, kann gegenüber seinem Wettbewerber Marktvorteile z.B. in Form neuer und oder günstigerer Produkte und Leistungen erzielen. Das Beherrschen des ICT-Technologie-Managements ist somit schleichend und noch nicht von jedem realisiert zu einem nicht zu unterschätzenden Wettbewerbsinstrument geworden. Dies spüren z.B. viele kleinere und mittlere Banken, die der Entwicklungspower der Grossbanken (Beispiel Online Banking) schon seit einiger Zeit nur mit Mühe oder gar nicht mehr begegnen können. Ein spezielles Technologiethema stellt das ICT Security Management dar. Die so genannte „Malware“, also Viren, Würmer, Trojaner, Spyware etc., beschäftigt und finanziert heute bereits eine eigene Branche mit Milliardenumsätzen. Die weltweite Internetkriminalität hat inzwischen ein

Prozessbereich Logistics & Infrastructure

293

Abb. 108. ICT Security & Technology Management

Schadensvolumen erreicht, das in die Milliarden84 geht. An einem normalen Arbeitstag sind alleine in den ICEs der deutschen Bundesbahn zigtausend Notebooks unterwegs, die alle mehr oder weniger vertrauliche oder gar geheime Firmeninformationen auf ihren Harddisks durch die Welt transportieren – Sicherheitsrisiken, wohin man auch blickt. Dem Technologie- und dem Security Management haben wir in unserem Modell die zwei Prozesse 731 Security Management und 732 Technology Management gewidmet. Ihre Aufgaben liegen primär darin, das ICTUnternehmen mit neuen Lösungen zu versorgen und damit den Anschluss an die technologische Entwicklung, und was noch viel wichtiger ist: an den Wettbewerb, sicherzustellen. 84

Meldung in Spiegel Online vom 8. Februar 2007: Chinesische Hacker spionieren den deutschen Mittelstand aus.

294

Prozessbereiche und Prozesskategorien

Im Prozess 731 Security Management werden die Entwicklung von Sicherheitsstandards, -vorgaben und -regeln sowie die Überwachung von deren Einhaltung geregelt. Der Prozess bzw. diverse Aufgaben des Prozesses werden von einer Reihe von Ereignissen angestoßen: • Periodisch, z.B. vierteljährlich, halbjährlich, werden die Sicherheitsanforderungen analysiert und die entsprechenden Sicherheitsstandards und -vorgaben aktualisiert sowie deren Umsetzung sichergestellt. • Periodisch, z.B. monatlich, sind Security-Audits zu planen und durchzuführen, um die Durchsetzung der Vorgaben zu prüfen und sicherzustellen. • Sicherheitsproblem erkannt; ein Resultat des Prozesses 421 Problem Handling oder 624 Authorization Management. In diesem Fall erfolgen die Analyse und anschließend die Einleitung der notwendigen Maßnahmen zur Beseitigung der Sicherheitslücke. • Risikoanalyse erstellt, Ergebnis des Prozesses 163 Risk Management; hier können z.B. Bedrohungsszenarien oder auch entsprechende Vorkommnisse gemeldet werden, für deren Abwehrung oder Verhinderung entsprechende Maßnahmen zu treffen sind. • Sicherheitsanforderungen definiert, hier im Sinne von vorgegeben. Entsprechende Anforderungen kommen oft von außen, z.B. durch den Gesetzgeber im Fall des Datenschutzgesetzes oder durch Kunden,85 die fordern, dass ihre eigenen Sicherheitsvorgaben umgesetzt und eingehalten werden. Weiter kann dies in unserem Modell ein Ergebnis des Prozesses 711 Contingeny Planning sein, wo spezielle Anforderungen im Fall eines Notfalls spezifiziert werden. Dies könnte z.B. auch die Aufhebung bestimmter Restriktionen betreffen. • Sicherheitsanforderungen identifiziert, hier im Sinne von vermutet. Typische Fälle hierfür sind, o wenn eine neue Technologie (über den Prozess 732 Technology Management) eingeführt wird und die Sicherheitsaspekte analysiert werden müssen oder o wenn ein neues Produkt entwickelt wird; hier erfolgt dann der Anstoß durch den Prozess 134 Product & Service Management, der in unserem Modell die Entwicklung neuer Services und Produkte steuert. 85

Typisches Beispiel: Outsourcing von ICT-Leistungen einer Bank an einen Lieferanten. Der Lieferant muss die strengeren Sicherheitsrichtlinien der Bank verwenden.

Prozessbereich Logistics & Infrastructure

295

Typische Ergebnisse des Prozesses 732 Security Management sind: • Sicherheitsstandards definiert und für alle verfügbar; dessen Bedeutung ist nicht zu unterschätzen, vor allem wenn man sich bewusst ist, dass eigentlich jeder Lieferant einer ICT-Unternehmung auf deren Einhaltung zu verpflichten ist. • Schulung beauftragt; Sicherheitsstandards müssen regelmäßig geschult werden bzw. gehören ins Schulungsprogramm für neue Mitarbeiter. Die entsprechenden Schulungsaktivitäten sind im Prozess 641 Education & Training Planning geregelt. • RFC formuliert; vielfältige Änderungen personeller, technischer und organisatorischer Art können ein Ergebnis des Prozesses sein. Diese werden über den Prozess 411 Change Handling dem Change Management zugewiesen. • Wissensdefizite erkannt; die Definition von Sicherheitsstandards setzt ein entsprechendes Wissen voraus; was ist z.B. gesetzlich vorgeschrieben oder erlaubt? Wissensdefizite werden durch den Prozess 722 Knowledge Management behoben. • Sicherheitsreport erstellt; dieser beinhaltet z.B. die vorgefallenen Sicherheitsverstöße, evtl. eine Abschätzung von Bedrohungsszenarien und eine Auflistung der bestehenden Sicherheitslücken; ein wichtiger Input für den Prozess 163 Risk Management. • Risiko erkannt; ein konkretes, erkanntes Risiko aktiviert den Prozess 163 Risk Management. Sicherheitsrisiken, die das eigene Unternehmen gefährden, können auch auf der Seite der Kunden oder der Lieferanten gefunden werden. • Security-Audit beantragt; die Audits werden in unserem Modell über den Prozess 161 Audit & CIP gesteuert. Es können zwei Audits unterschieden werden: zufallsgesteuerte Routine-Audits oder situationsbezogene Audits, die auf einem Verdacht basieren. • Zugriffsberechtigung deaktiviert, eine konkrete Handlungsmaßnahme bei einem Verstoß gegen die Sicherheitsrichtlinie (z.B. unerlaubte Weitergabe einer User-ID und des Passwortes); in diesem Fall erfolgt die entsprechende Ausführung im Prozess 624 Authorization Management.

296

Prozessbereiche und Prozesskategorien

Das Thema „Sicherheit“ rund um den Einsatz von Informatikund Kommunikationsmitteln beschert der Industrie auch in Zukunft weiter hohe Wachstumszahlen. Jede neue Entwicklung birgt neue Sicherheitsrisiken! Viele Unternehmen tun sich mit Ausgaben in diesem Bereich schwer, da sie keinen direkten wirtschaftlichen Nutzen sehen. Eine potenzielle Schadensverhinderung lässt sich eben schlecht bilanzieren! Die ICT-Infrastuktur einer Unternehmung unterliegt einem ständigen Lifecycle. Neue Hardware- und Software-Lösungen werden eingeführt, ältere werden aus dem Betrieb genommen, verschrottet bzw. gelöscht. Die Entsorgung der Hardware ist in größeren Organisationen schon ein eigener Zweig im Facility Management. Volkswirtschaftlich hat sich eine ganze, eigens auf das Recycling von Informatikschrott spezialisierte Branche etabliert. Die eigentliche Problematik und Herausforderung liegt darin, eine stabile System-Architektur zu gewährleisten. Es gibt wohl kaum eine Branche wie die ICT-Branche, wo so unbekümmert und manchmal quasi über Nacht eine neue Technologie in die laufende produktive Umgebung gebracht wird. Kein Autobauer käme auf die Idee, den neusten Schweißroboter mal eben schnell in eine bewährte Produktionsstraße einzubauen und gespannt zu verfolgen, wie er sich bewährt. In der ICT-Branche ist dies nicht unüblich! In unserem Modell-Unternehmen ist eine eigene Architektur-Einheit für die Integration neuer Technologien ins Unternehmen verantwortlich. Jede Technologie muss von dieser Einheit vor ihrer Beschaffung für den Betrieb freigegeben werden. Der Prozess 732 Technology Management regelt und steuert die Einführung neuer86 ICT-Produkte aller Art. Der Prozess wird primär durch das Ereignis Neue Technologie verfügbar ausgelöst. In den meisten Fällen ist dies ein Ergebnis von außen, z.B. durch eine Ankündigung eines Herstellers bzw. Lieferanten. Auch das Ereignis Technologie veraltet kann den Prozess anstoßen. Dieses Ereignis ist ein Ergebnis der Prozesse

86

Streng genommen ist jedes neues Release als ein neues technologisches Produkt zu behandeln, da nicht immer die Kompatibilität sichergestellt ist.

Prozessbereich Logistics & Infrastructure

297

• 421 Problem Handling, ein in der Praxis typisches Ergebnis einer Störungs- oder Problemanalyse; zunehmende Häufung von Störungen bei Systemen, die das Ende ihres technologischen Lifecycles erreicht haben – ein deutlicher Hinweis darauf, z.B. Geräte dieser Generation zu ersetzen. • 333 Operations Acceptance Test; neue Produkte müssen für den Betrieb freigegeben werden. Aus diesem Grunde werden sie in der zukünftigen Produktionsumgebung getestet. Vor allem bei SoftwareLösungen kann hier ein Ergebnis sein, dass die Technologie der Produktionsumgebung die volle Leistung der Software (z.B. Performance) aufgrund einer veralteten Technologie nicht garantieren kann. Der Prozess 732 Technologie Management analysiert die Möglichkeiten der neuen Technologien bzw. neuer Produkte. Es werden die Konsequenzen für die bestehende ICT-Infrastruktur und für die eigenen im Hause entwickelten Produkte abgeschätzt. Wird die Einführung entschieden, werden die neuen technologischen Standards und Vorgaben definiert sowie die Einführung in die Wege geleitet. Der Prozess kann folgende Ergebnisse haben: • Trendanalyse aktualisiert; insbesondere wenn die ICT-Unternehmung selbst Produkte entwickelt, muss sie die technologischen Trends und Entwicklungen verfolgen, um gegebenenfalls die eigenen Produkte darauf anzupassen bzw. neue zu entwickeln. Die Ergebnisse der Trendanalyse werden im Prozess 134 Product & Service Management verarbeitet. • Projekt vorgeschlagen; die Einführung neuer Technologien kann z.T. einen erheblichen Aufwand für das Unternehmen zur Folge haben. Eine projektorientierte Einführung wird über den Prozess 311 Project Planning sichergestellt. (Natürlich gibt es auch Einführungen bzw. Freigaben, die keinen großen Aufwand zur Folge haben. Hierzu gehört z.B. ein neues Monitormodell oder ein neuer Druckertyp. Für diesen Fall haben wir im Modell kein eigenes Ergebnis formuliert.) • Sicherheitsanforderungen identifiziert; jede neue Technologie birgt in sich neue Sicherheitsrisiken bzw. -lücken. Die entsprechenden Sicherheitsstandards werden im Prozess 731 Security Management definiert. • Wissensdefizite erkannt; die Beurteilung von technologischen Entwicklungen bedingt spezifisches Wissen. Notwendiges Wissen wird über den Prozess 722 Knowledge Management bereitgestellt.

298

Prozessbereiche und Prozesskategorien

Technologie-Management ist zentral zu organisieren. Ein bewusst geschaffener „bottle-neck“ stellt eine stetige und vor allem gesteuerte Einführung neuer Produkte sicher.

ICT Logistics & Facility Management In unserem Modell haben wir zwei Bereiche in Kurzform als Prozesse integriert, die von ihrer Bezeichnung her Themengebiete betreffen, von denen jedes einzelne selbst Bücherschränke füllt. Das Facility Management bezeichnet die Verwaltung und Bewirtschaftung von Gebäuden, Anlagen und Einrichtungen. Wir konzentrieren uns hier auf drei Leistungen: • Planung, Bereitstellung, Unterhalt der Verkabelung (als Grundlage der Netzwerke) • Planung, Bereitstellung, Unterhalt von Gebäuden / Räumen (z.B. für die Aufstellung der Serversysteme) • Planung, Bereitstellung, Unterhalt von Geräten (z.B. Notstromaggregate) • Planung, Bereitstellung, Unterhalt von Hardware (z.B. Server, Drucker etc.) Weiter haben wir eine rudimentäre Lager- und Inventarverwaltung abgebildet, die vor allem die Einlagerung und Auslieferung der von unserer ICT-Unternehmung entwickelten Hardwareprodukte abbildet. Die gewählte Darstellung reicht aus, die Schnittstellen der wertschöpfenden Prozesse eines ICT-Unternehmens zu diesen Bereichen aufzuzeigen. Abhängig vom jeweiligen Unternehmen können diese Bereiche vollständig vernachlässigt oder müssen umfangreicher berücksichtigt werden. Der Prozess 741 Facility Management stellt den grundsätzlichen Infrastrukturbedarf der ICT-Unternehmung sicher. Fokussiert auf den Einsatz der Informations- und Kommunikationstechnologie gehören hierzu vor allem: • die Verkabelung und die Stromversorgung, • spezielle Räumlichkeiten, die z.B. Anforderungen der Sicherheit (Zugang) und des Brandschutzes erfüllen (Serverräume, RZ-Betrieb)

Prozessbereich Logistics & Infrastructure

299

Abb. 109. ICT Logistics & Facility Management

• spezifische Hardware / Geräte wie z.B. Serversysteme, Speichersysteme, Notstromaggregate, Großdrucker, Verpackungsmaschinen und Ähnliches. Der Prozess wird durch zwei Ereignisse angestoßen: zum einen durch das Change Management (412 Change Planning & Control) mit dem Ereignis

300

Prozessbereiche und Prozesskategorien

Change terminiert – in diesem Fall ist zu prüfen, ob eine anstehende Aktion Auswirkungen auf die Tätigkeit des Facility Managements haben kann. Ein passendes Beispiel wäre eine geplante Notfallübung, bei der auch die Notstromaggregate zum Einsatz kommen sollen. Zum andern löst das Ereignis Infrastrukturbedarf ermittelt den Prozess aus. Abhängig von der Art des Bedarfs erfolgen die Planung, die Zuteilung, Bereitstellung und / oder die Beschaffung der benötigten Ressourcen. Das Ereignis Infrastrukturbedarf ermittelt kann das Ergebnis der folgenden Prozesse unseres Modells sein: • 411 Change Handling, z.B. ein geplanter Umzug erfordert eine neue Raumplanung und zusätzliche Räume. • 511 Production Planning, z.B. ein neuer Produktionsvertrag bedingt die Beschaffung einer spezifischen Verpackungsmaschine. • 512 Availability Management, es wird z.B. ein weiterer Applikationsserver benötigt. • 513 Capacity & Performance Management, z.B. aus Performancegründen soll in bestimmten Bereichen auf Glasfaser umgestellt werden. • 611 Customer Services Planning, z.B. ein neu gewonnener Kunde führt zur personellen Erweiterung des Service Desks, es werden weitere Räume inkl. Arbeitsplatzausstattung benötigt. • 641 Education & Training Planning, es werden z.B. Schulungsräumlichkeiten benötigt. • 711 Contingency Planning, es wird z.B. ein dieselbetriebenes Notstromaggregate benötigt. Typische Ergebnisse des Prozesses sind (jeweils mit Beispiel): • Materialbedarf ermittelt, z.B. Kabelrollen für Verkabelungsaufträge; die Bereitstellung erfolgt über den Prozess 742 Material & Inventory Management. • RFC formuliert, es wird z.B. die Einführung eines neuen Zutrittsystems (Sicherheit), basierend auf einer Chipkarte und direktem Zugriff, für das System der Personalverwaltung beantragt. Die Anfrage wird über den Prozess 411 Change Handling bearbeitet. • Change geplant, z.B. aufgrund einer baulichen Maßnahme muss in einem bestimmten Gebäude die Stromversorgung unterbrochen werden. Diese Aktivität untersteht dem Change Management und wird im Prozess 412 Change Handling & Control überwacht.

Prozessbereich Logistics & Infrastructure

301

• Change realisiert, z.B. die erfolgte Installation eines neuen Magnetband-Roboters löst im Prozess 412 Change Handling & Control die entsprechenden Abschlussaktivitäten für einen Change aus. • On-Site-Einsatz notwendig, z.B. für die Installation eines Servers werden Servicetechniker benötigt. Deren Verfügbarkeit und Einsatz werden über den Prozess 631 On-Site Dispatching sichergestellt. • Projekt vorgeschlagen, z.B. ein Gebäude soll vollständig neu verkabelt werden. Aufgrund der Abhängigkeiten, des Umfanges und der daraus resultierenden Komplexität soll das Vorhaben projektorientiert abgewickelt werden. Projekte werden über den Prozess 311 Project Planning gesteuert. • CI geändert, z.B. eine Serverfarm wurde von einem Raum in einen anderen verlagert, parallel wurde hierbei auch die Server-Architektur sowie die Server-Ausstattung verändert. Die Veränderungen sind wie in den Prozessen 432 CI Verification und 433 CI Documentation geregelt nachzuführen und zu dokumentieren. • Plattformangebot aktualisiert, das vorhergehende Beispiel führt z.B. zur Überarbeitung des mit der Serverfarm verbundenen Notfallkonzeptes wie im Prozess 711Contingency Planning realisiert. • Budgetbedarf formuliert, z.B. das Contingency Planning meldet einen Bedarf an Notstromaggregaten. Das Facility Management kalkuliert die notwendigen Investitionen und Kosten. Die Budgetierung erfolgt gemäß dem Prozess 143 Budgeting. Ein ICT-Unternehmen kann eine ICT-Infrastruktur sowohl im Auftrag eines Kunden konzipieren und implementieren als auch für sich selbst zwecks Eigennutzung oder Produktion von Leistungen für Kunden. Die Inhalte und Durchführung dieser Tätigkeiten sind die gleichen und werden meist auch von den gleichen Personen ausgeführt. Allerdings unterscheiden sich die Auftraggeber und damit auch die Rahmenbedingungen der Abwicklung. Im ersten Fall handelt es sich um einen Auftrag, der über die Prozesse des Sales gestartet und gesteuert wird. Im zweiten Fall ist das ICT-Unternehmen selbst der Auftraggeber und die Initialisierung und Steuerung erfolgt über das Facility Management.

302

Prozessbereiche und Prozesskategorien

In unserem Modell gehen wir davon aus, dass unser ICT-Unternehmen Hardware-Produkte bzw. auch Software-Produkte produziert, die dem Kunden als physisches Paket geliefert werden. Weiter existieren diverse Prozesse wie Output-Management, Facility Management, Systemmontage, Reparaturen etc., die einen gewissen Materialfluss87 wie Hardware, Ersatzteile, Druckerfarbe und Papier bedingen. Dieser Materialfluss wird im Modell in Form einer rudimentären Lagerverwaltung über den Prozess 742 Material & Inventory Management gesteuert. Der Prozess besteht aus drei Aufgabenketten. Die erste Aufgabenkette wird periodisch, z.B. viertel- oder halbjährlich angestoßen. Es handelt sich hierbei um einen Grundprozess der Lagerverwaltung, nämlich die Inventur, die Bestandsaufnahme der eingelagerten Objekte und damit eine regelmäßige Aktualisierung und Überprüfung des Lagerbestandes. Die zweite Aufgabenkette umfasst die Wareneingangskontrolle88 und die Einlagerung der gelieferten Ware. Ausgelöst wird diese Aufgabenkette durch zwei Ereignisse: • Ware eingegangen; in diesem Fall handelt es sich hauptsächlich um bestellte Güter, die von Lieferanten geliefert werden. Die Wareneingangskontrolle prüft hier vor allem, ob die Lieferung der Bestellung entspricht. • Auslieferungspaket bereitgestellt; die Produkte des Unternehmens, die als physisches Paket dem Kunden zugestellt werden, können entweder direkt an den Kunden gesendet oder im Lager zwischengelagert werden. Die dritte Aufgabenkette umfasst die Bereitstellung (Auslieferung) und gegebenenfalls die vorgängige Beschaffung des Materials. Die Aufgabenkette startet beim Eintritt eines der beiden folgenden Ereignisse: Auslieferungspaket angefordert, in Folge einer Bestellung ein Resultat des Prozesses 334 Distribution Planning. Das angeforderte Auslieferungspaket wird zwecks Auslieferung an den Besteller (geregelt im Prozess 335 HW / SW Distribution) dem Lager entnommen.

87

Wir definieren hier den Begriff „Material“ im Sinne von „jedes Objekt, das bei einem ICT-Unternehmen eingelagert wird“.

88

Ware verstehen wir hier als Material, das gehandelt, d.h. gekauft oder verkauft wird.

Prozessbereich Logistics & Infrastructure

303

Materialbedarf ermittelt; in diesem Fall liegt eine Anforderung an Material bzgl. Mengenbedarf und Termin (wann benötigt) vor. Die Materialbedarfsmeldung ist in unserem Modell ein Ergebnis der folgenden Prozesse (mit jeweils einem typischen Beispiel): • 411 Change Handling; z.B. eine Umstellung der Output-Lieferung von Papier auf elektronische Speichermedien bedingt mittelfristig eine Veränderung des Bedarfs an Papier (abnehmend) und elektronischen Speichermedien (zunehmend). • 431 System Configuration, z.B. Anforderung von Verpackungsmaterialien zwecks Verpackung der montierten Systeme • 511 Production Planning z.B. meldet den voraussichtlichen Bedarf an Papier für die Monatsendverarbeitung. • 521 Production Control z.B. fordert die konkreten Mengen an Papier für den anstehenden bzw. laufenden Produktions-(Druck)-prozess an. • 632 Repair Management; z.B. ein Servicetechniker fordert eine Netzwerkkarte zwecks Austauschs an. • 643 Education Processing z.B. fordert für den Kurs „Verpackungstechniken” Verpackungsmaterialien an, die vom Unternehmen für die Verpackung von Hardware-Produkten verwendet werden. • 741 Facility Management, z.B. das Facility Management plant eine Verkabelung und bestellt das hierfür notwendige Material (Kabel, Stecker, Wandbuchsen etc.). Die drei Aufgabenketten führen zu folgenden Prozessergebnissen: • CI geändert, z.B. bei der Wareneingangskontrolle wird festgestellt, dass die gelieferte Ware nicht konkret der Bestellung entspricht. Beispiel: Ein bestelltes Notebook wurde zum Zeitpunkt der Bestellung (as ordered89) in der Configuration Database mit der bestellten Konfiguration erfasst. Bestellt wurde ein System mit einem RAM-Speicher von 512 Megabyte, geliefert wurde das Notebook mit einem RAMSpeicher von 1024. Da die Lieferung zum gleichen Preis erfolgt, wird das Notebook angenommen. In der Configuration Database muss nun der Eintrag für den RAM-Speicher geändert werden. Die mit der Änderung eines Configuration Items verbundenen Aufgaben sind in den Prozessen 432 CI Verification und 433 CI-Documentation geregelt. 89

Siehe Life-Cycle-Konzept im Kapitel Support, ICT Configuration Management.

304

Prozessbereiche und Prozesskategorien

• Auslieferungspaket bereitgestellt; z.B. ein eingelagertes Produkt, verpackt als Auslieferungspaket, wird für die Auslieferung über den Prozess 335 HW / SW Distribution bereitgestellt. • Material bereitgestellt, Fortsetzung90 des Materialflusses zu den Prozessen o 521 Production Control, z.B. Lieferung der bestellten Datenträger bzw. Speichermedien (Magnetbänder, CDs etc.) o 523 Output-Management, z.B. Lieferung des angeforderten Druckerpapiers o 632 Repair Management, z.B. Auslieferung des Ersatzteils „Netzwerkkarte“ o 633 Installation & Relocation Management, z.B. Auslieferung von bestellten Client-Systemen zwecks Installation • Bedarf formuliert; im Sinne der Lagerbewirtschaftung wird auf der Basis des gemeldeten Materialsbedarfs der Einkaufsbedarf ermittelt. Die Beschaffung der Ware erfolgt über den Prozess 114 Purchasing. • Budgetbedarf formuliert; ebenfalls im Sinne der Lagerbewirtschaftung erfolgt eine Budgetplanung für das zu beschaffende Material. Die weitere Bearbeitung erfolgt wie im Prozess 143 Budgeting geregelt. „Wir brauchen kein Lager und wir haben kein Lager!“ Eine in ICT-Unternehmen bzw. ICT Organisation durchaus häufige Aussage, die nicht ganz korrekt ist. Korrekt ist in vielen Fällen diese Aussage: „Wir haben keine Lagerverwaltung und wir brauchen keine Lagerverwaltung!“ Ob die Bestände einer Unternehmung einer Lagerverwaltung zu unterstellen sind oder nicht, ist eine organisatorische und betriebswirtschaftliche Entscheidung. Diese Entscheidung kann aber nur dann bewusst getroffen werden, wenn die Bestände und die Materialflüsse bekannt sind.

90

Ein Lager hat die Funktion einer gewollten und bewussten Unterbrechung des Materialflusses. Es werden bewusst Bestände aufgebaut (aufgestaut), um anschließend einen optimierten Materialfluss zu gewährleisten.

Anhang

Geschäftsvorfall 1: Kunde kauft PC

Abb. 110. Geschäftsvorfall Kunde kauft PC, Teil 1

306

Anhang

Abb. 111. Geschäftsvorfall Kunde kauft PC, Teil 2

Geschäftsvorfall 2: Betrieb einer ICT-Infrastruktur

Geschäftsvorfall 2: Betrieb einer ICT-Infrastruktur

Abb. 112. Geschäftsvorfall Betrieb einer ICT-Infrastruktur, Teil 1

307

308

Anhang

Abb. 113. Geschäftsvorfall Betrieb einer ICT-Infrastruktur, Teil 2

Geschäftsvorfall 2: Betrieb einer ICT-Infrastruktur

Abb. 114. Geschäftsvorfall Betrieb einer ICT-Infrastruktur, Teil 3

309

310

Anhang

Geschäftsvorfall 3: Individual-Software-Entwicklung

Abb. 115. Geschäftsvorfall Individual-Software-Entwicklung, Teil 1

Geschäftsvorfall 3: Individual-Software-Entwicklung

Abb. 116. Geschäftsvorfall Individual-Software-Entwicklung, Teil 2

311

312

Anhang

Abb. 117. Geschäftsvorfall Individual-Software-Entwicklung, Teil 3

Geschäftsvorfall 3: Kunde meldet Störung

Geschäftsvorfall 3: Kunde meldet Störung

Abb. 118. Geschäftsvorfall Kunde meldet Störung, Teil 1

313

314

Anhang

Abb. 119. Geschäftsvorfall Kunde meldet Störung, Teil 2

Prozessliste des ICT-Prozess-Referenzmodells

Prozessliste des ICT-Prozess-Referenzmodells Prozessbereich 1 Management Prozesskategorie

Hauptprozess

11 ICT Supplier Management

111 Partner Management 112 Supplier Contract Management 113 Supply Chain Management 114 Purchasing 115 Licence Management

12 ICT Program Management

121 Program Planning 122 Approval Procedure 123 Program Control

13 ICT Marketing

131 Marketing Management 132 Customer Portfolio Management 133 Product Portfolio Management 134 Product & Service Management

14 ICT Finance & Controlling

141 Service Charging 142 Invoicing 143 Budgeting

15 ICT Human Resource Management 151 Professional Development 152 Human Resource Planning 16 ICT Quality & Risk Management

161 Audit & CIP 162 QM-System 163 Risk Management 164 Process Management

Prozessbereich 2 Sales Prozesskategorie

Hauptprozess

21 ICT Sales Planning & Execution Management

211 Sales Management

315

316

Anhang 212 Bid Management 213 Order Management

22 ICT Customer Contract Management

221 Contract Definition 222 Contract Administration 223 Contract Monitoring

Prozessbereich 3 Project & Development Prozesskategorie

Hauptprozess

31 ICT Project Management

311 Project Planning 312 Project Control 313 Project Risk Management 314 Project Change Management 315 Project Finalisation

32 ICT Consulting & System Development Management

321 Conceptual Design 322 System Development

33 ICT Release Management

331 Release Planning 332 Release Package Management 333 Operation Acceptance Test 334 Distribution Planning 335 HW / SW Distribution

Prozessbereich 4 Support Prozesskategorie

Hauptprozess

41 ICT Change Management

411 Change Handling 412 Change Planning & Control

42 ICT Problem Management

421 Problem Handling 422 Error Control 423 Proactive Problem Management

Prozessliste des ICT-Prozess-Referenzmodells 43 ICT Configuration Management

431 System Configuration 432 CI Verification 433 CI-Documentation 434 CI-Type-Engineering

Prozessbereich 5 Operations Prozesskategorie

Hauptprozess

51 ICT Operations Planning

511 Production Planning 512 Availability Management 513 Capacity & Performance Management

52 ICT Operations Control Management

521 Production Control 522 System Monitoring 523 Output Management

Prozessbereich 6 Customer Services Prozesskategorie

Hauptprozess

61 ICT Customer Services Planning and Monitoring

611 Customer Service Planning

612 Customer Service Monitoring 62 ICT Customer Contact Management

621 Contact Management 622 Incident Management 623 Complaint Management 624 Autorisation Management 625 Content Management

63 ICT On-Site-Services

631 On-Site Dispatching 632 Repair Management 633 Installation & Relocation Management

317

318

Anhang

64 ICT Customer Education Management

641 Education & Training Planning 642 Registration Handling 643 Education Processing

Prozessbereich 7 Logistics & Infrastructure Prozesskategorie

Hauptprozess

71 ICT Continuity Management

711 Contingency Planning 712 Emergency Process 713 Contingency Testing

72 ICT Methodic Development & Knowledge Management

721 Methodic Development 722 Knowledge Management

73 ICT Security & Technology Management

731 Security Management

732 Technology Management 74 ICT Logistics & Facility Management

741 Facility Management 742 Material & Inventory Management

Ereignisliste

319

Ereignisliste Ein Ereignis beschreibt einen erreichten bzw. eingetroffenen Zustand. Es ist immer ein Ergebnis einer vorangegangenen Aktivität. Die Besonderheit eines Ereignisses ist, dass eine Vielzahl von Kriterien definiert werden können, damit das Ereignis als eingetroffen gilt bzw. der entsprechende Zustand erreicht wurde. So kann z.B. für das Ereignis Vertrag unterzeichnet festgelegt werden, dass dieses Ereignis erst eingetreten ist, wenn folgende Bedingungen erfüllt sind: 1. Der Vertrag liegt in fünf Exemplaren vor. 2. Der Vertrag wurde von der Gegenpartei formgerecht unterschrieben. 3. Der Vertrag wurde von der eigenen Partei formgerecht, gemäß der im Hause geltenden Unterschriftenregelung, unterschrieben. 4. Der Vertrag wurde vom Notar beglaubigt. Somit geht die Formulierung eines Ereignisses im Bereich der Prozessmodellierung wesentlich weiter als nur die Beschreibung eines In- bzw. Outputs. In der folgenden Liste sind alle Ereignisse aufgelistet, die im ProzessReferenzmodell verwendet werden. In der Kommentarspalte sind beispielhaft zusätzliche Informationen wie z.B. mögliche Kriterien und Erläuterungen aufgeführt, die zum besseren Verständnis des Gesamtkonzeptes beitragen. Ausgehende Ereignisse sind Ereignisse, die innerhalb des Modells einen Prozess abschließen und dann außerhalb des Unternehmens (im Kontext) Aktivitäten auslösen. Zum Beispiel: Angebot erstellt schließt den BidManagement-Prozess ab und „löst“ beim Kunden die entsprechenden Folgeaktivitäten aus. Eingehende Ereignisse haben ihren Ursprung außerhalb des Unternehmens und lösen im Modell Folgeaktivitäten aus. Zum Beispiel: Vertrag unterzeichnet ist Ergebnis einer Aktivität auf der Kundenseite und löst im Modell den Prozess 222 Contract Administration aus.

320

Anhang

Ereignisse Ereignis

Kommentar

Periodisch

Symbol Uhr. Es handelt sich hier um ein Zeitereignis. Dabei kann es sich um ein fixes Datum handeln (z.B. Jahresabschluss immer am 31.12. eines Jahres) oder, was eher typisch ist, jeweils periodisch durchzuführende Aktivitäten wie z.B. monatlich, viertel-, halbjährlich etc.

Angebot erstellt

Es handelt sich hierbei um ein Dokument, das an einen potenziellen Kunden geliefert wird. Der Zustand Angebot erstellt gilt als erreicht, wenn es gemäß den Formvorgaben der Unternehmung (inkl. Unterschriften) erstellt wurde, der Kunde es durch Gegenzeichnen oder durch einen entsprechenden Zusatz in einen Vertrag umwandeln kann und das Dokument versandfertig vorliegt.

Abschlussinformationen erstellt

Sämtliche Daten und Informationen, die im Zusammenhang mit einem erfolgreichen Vertragsabschluss anfallen, sind in den entsprechenden Informationssystemen erfasst und den verantwortlichen Stellen zugänglich gemacht.

AE-Prognose aktualisiert

Die Auftragseingangsprognose ist dann aktualisiert, wenn von allen Vertriebseinheiten auf der Basis der aktuellen Angebote und der Vertriebseinschätzungen die entsprechenden Daten und Informationen in den hierfür vorgesehenen Systemen erfasst wurden.

Aktualisierung Projektplanung initialisiert

Dieses Ereignis tritt ein, wenn aufgrund von Veränderungen im Projekt eine Überarbeitung der Projektplanung auf Programmebene notwendig wird und davon auszugehen ist, dass andere Projekte der Unternehmung von den Änderungen betroffen sind.

Anfrage bearbeitet

Dieses Ereignis ist eingetreten, wenn eine vom Kunden ausgelöste Anfrage im Contact Managementsystem dokumentiert, deren Bearbeitung überwacht, die Bearbeitung abgeschlossen und der Kunde über das Ergebnis informiert wurde.

Angebotsanfrage formuliert

Bevor eine Kundenanfrage vom Vertrieb weiter bearbeitet und zu den internen Fachstellen weitergeleitet wird, muss diese auf der Basis einer internen Vorgabe konkretisiert werden. Es müssen z.B. gewisse Mussinformationen vorliegen wie z.B. Mengengerüste, geforderte Liefertermine etc.

Ereignisliste

321

Angebotsvorlage erstellt

Bevor ein Angebot fertig erstellt werden kann, müssen alle Leistungsinformationen in einer Angebotsvorlage zusammengetragen werden. Die juristische Prüfung, die abschließenden Preis- und Terminfestlegungen können erst dann erfolgen, wenn die vorgegebenen unternehmensspezifischen Kriterien für die Leistungsbeschreibung erfüllt sind.

Audit-Bericht erstellt

Die entsprechende Dokumentation liegt vor und ist zur Verwendung freigegeben.

Ausbildungsbedarf ermittelt

Der Ausbildungsbedarf ist gemäß den internen Richtlinien der Unternehmung inhaltlich und bzgl. des betroffenen Personals definiert.

Ausführungstermin bestätigt

Das Ereignis bedingt, dass die verantwortlichen Stellen formgerecht und gemäß den Richtlinien der Unternehmung eine Terminbestätigung formuliert haben und diese dem Empfänger zugestellt wurde.

Auslastungsplanung aktualisiert

Die Auslastungsplanung gilt als aktualisiert, wenn termingerecht (z.B. immer zum Zehnten des Monats) von allen verfüg- und einsetzbaren Ressourcen die Auslastung für die nächste Planungsperiode (z.B. 6 Monate) vorliegt, in den entsprechenden Systemen erfasst und somit den verantwortliche Stellen zugänglich ist.

Auslieferung freigegeben

Alle Bedingungen, die mit einer Auslieferung (z.B. einer Ware) erfüllt sein müssen, wie z.B. Lieferobjekt ist verpackt, Lieferschein liegt vor, Zollpapiere liegen vor, Spediteur ist beauftragt etc., sind erfüllt.

Auslieferungspaket angefordert

Eine Leistung, die in Form eines „Paketes“ – Achtung, hierunter kann auch ein elektronisch zu verteilendes Software-Paket verstanden werden – wurde gemäß den firmeninternen Richtlinien für die Bestellung des entsprechenden Objektes (z.B. via Bestellschein oder elektronischer Order) angefordert.

Auslieferungspaket bereitgestellt

Ein auszulieferndes Objekt wurde gemäß den Vorgaben und den objektspezifischen Kriterien bereitgestellt. (Kriterien könnten z.B. bestimmte Verpackungsregeln sein und die Verfügbarkeit des Objekts an einem bestimmten Ort.)

Autorisationsanfrage identifiziert

Dieses Ereignis tritt ein, wenn festgestellt wird, dass ein (Kunden)-Anwender Zugang zu einem System wünscht, für das er bisher keinen Zugang hatte oder ein (Kunden)-Anwender aufgrund vergessener UserID oder Passwortes keinen Zugang mehr hat.

322

Anhang

Availability-Vorgaben erstellt

Die Vorgaben für die Verfügbarkeit der ICT-Infrastruktur wurden gemäß den internen Richtlinien definiert, mit den Anforderungen und Vorgaben der Kunden abgeglichen und allen verantwortlichen Stellen zugänglich gemacht.

Bearbeitungsstatus aktualisiert

Der Bearbeitungsstatus eines Vorgangs (z.B. eines Incidents) unter der Überwachung des Contact Managements hat sich geändert und führt zu einer Information des Kunden.

Bedarf formuliert

Hier handelt es sich um einen allgemeinen Bedarf an Material, Ressourcen, Dienstleistungen etc., der via Einkauf zu beschaffen ist. Damit der Bedarf formuliert ist, muss dieser eindeutig spezifiziert, die entsprechende Menge sowie der benötigte Liefertermin definiert sein.

Bedarfsanalyse aktualisiert

Liegt vor, wenn die neuesten Analysedaten des Marktes und die daraus gezogenen Schlussfolgerungen für den aktuellen und zukünftigen Bedarf an Leistungen / Produkte erstellt und diese über die entsprechenden Systeme verfügbar gemacht wurden.

Bestehender CI-Type nicht mehr aktuell

Bei einer Überprüfung der in der Configuration Database verwalteten Configuration Items wurde festgestellt, dass ein CI-Type nicht mehr verwendet wird bzw. dessen Datenstruktur nicht mehr aktuell ist.

Bestellanfrage formuliert

Aus einer Leistungsanfrage wurde eine den Unternehmensanforderungen entsprechende Bestellung abgeleitet und alle Kriterien, Informationen für eine Bestellung liegen vollständig vor. (Im Modell gehen wir davon aus, dass ein Kunde eine Leistungsanfrage stellt, die dann gemäß den Anforderungen des Unternehmens konkretisiert wird.)

Bestellinformation erstellt

Sämtliche im Zusammenhang mit einer Bestellung zu erfassenden Informationen sind erhoben und in den entsprechenden Systemen erfasst und verfügbar.

Bestellung bestätigt

Eine Bestellung wurde dem Kunden gemäß Vorgaben des Unternehmens bestätigt, die Bestellung ist in den entsprechenden Systemen des Unternehmens erfasst und die damit verbundenen Daten stehen der Auftragsabwicklung zur Verfügung.

Bestellung geändert

Die Daten einer Bestellung wurden geändert, die Änderungen wurden in allen entsprechenden Systemen nachgeführt.

Ereignisliste

323

Bestellung gekündigt

Eine Bestellung wurde formgerecht gekündigt. Die Kündigung wurde in allen entsprechenden Systemen nachgeführt.

Bestellung storniert

Eine bereits für die Auftragsabwicklung bereitgestellte oder sich bereits in der Abwicklung befindliche Bestellung wird für die weitere Bearbeitung gesperrt und als solche in den entsprechenden Systemen dokumentiert.

Budgetbedarf formuliert

Der Budgetbedarf für ein Projekt, eine Tätigkeit, eine Beschaffung, eine Investition etc. ist dann formuliert, wenn die Budgetposition eindeutig spezifiziert wurde, das Mengengerüst definiert, das Budgetvolumen geschätzt sowie alle internen Vorgaben des Unternehmens zur Budgetierung eingehalten wurden.

Budgetplanung aktualisiert

Empfänger: Management, gegebenenfalls Inhaber, Aktionäre, Gesellschafter etc.; die Budgetplanung für eine Periode gilt als aktualisiert, wenn alle Veränderungen an der bestehenden Planung gemäß den Vorgaben der Unternehmung nachgeführt wurden, und die Ergebnisse in den dafür vorgesehenen Systemen zur Verfügung gestellt wurden.

Capacity- / Performance bedarf definiert

Die entsprechenden Planwerte und Bedarfswerte sind in den entsprechenden Systemen erfasst und stehen den betroffenen Stellen und Prozessen zur Verfügung.

Change abgelehnt

Ein Antrag bzw. eine geplante Veränderung wurde abgelehnt. Eine Begründung der Ablehnung und evtl. eine Alternative liegt vor und im Change Management System wurde der entsprechende Status erfasst.

Change geplant

Eine Veränderung ist inhaltlich beschrieben, die Abhängigkeiten und evtl. die damit verbundenen Risiken sind aufgezeigt und der Wunsch – sowie mindestens ein Alternativtermin für die Durchführung – ist festgelegt. Der Change wurde im Change Management System mit dem Status „geplant“ erfasst.

Change realisiert

Eine Veränderung wurde durchgeführt. Es liegt ein Abschlussbericht bzw. ein vergleichbares Ergebnis vor, welches auf besondere Geschehnisse wie z.B. eingetretene Risiken, Schnittstellenprobleme etc. hinweist. Der Status des Changes wurde im Change Management System auf „realisiert“ gesetzt.

Change terminiert

Der Termin für die Durchführung einer Veränderung wurde verbindlich festgelegt und im Change-Management-System der Status „terminiert“ erfasst. Damit gilt der Change gleichzeitig auch als genehmigt.

324

Anhang

CI geändert

Ein Configuration Item wurde hinsichtlich seiner verwalteten Datenattribute verändert.

CI-Dokumentation allgemein verfügbar

Eine zu einem Configuration Item (z.B. einem Notebook) gehörige Dokumentation (z.B. Benutzeranleitung) ist erstellt und so abgelegt oder verfügbar gemacht (z.B. in Form eines PDF-Files als Download), dass allgemeiner Zugriff (also durch alle Berechtigten) besteht.

CI-Type geändert

Die Datenstruktur (!) eines Configuration Items wurde verändert, die Configuration Database entsprechend angepasst, evtl. notwendige Schnittstellen zu anderen Systemen bereinigt, Datenmigrationen von der vorhergehenden Version zur neuen sind realisiert.

Consulting-Auftrag freigegeben

Ein entsprechender vom Kunden unterschriebener Vertrag liegt vor. Alle Vorgaben des Unternehmens zur Freigabe der Auftragsabwicklung für eine Beratungsleistung liegen vor.

Content-Änderung definiert

Eine strukturelle, inhaltliche Änderung des WebContents der Unternehmung oder einer von der Unternehmung betriebenen Lösung ist gemäß den entsprechenden Vorgaben spezifiziert.

Debitorenrechnung gestellt

Eine Verrechnung von Leistungen an einen Kunden wurde erstellt und an den Kunden versandt. Alle damit verbundenen allgemeinen und unternehmensspezifischen Tätigkeiten wurden durchgeführt.

Dienstleistung bestellt

Im Rahmen der Beschaffung wurde eine externe Dienstleistung gemäß den Vorgaben der Unternehmung und auf Basis eines Angebotes bestellt. Ein entsprechender Vertrag liegt vor.

Distributionsauftrag erteilt

Der Auftrag für die Verteilung eines oder mehrerer Objekte ist eindeutig spezifiziert (Art der Objekte, Anzahl, Liefertermin etc.) und der ausführenden Stelle zugewiesen.

Einführungsschulung beantragt

Ein Antrag für die Einführungsschulung eines entwickelten Systems ist gemäß den Vorgaben des Unternehmens spezifiziert (z.B. Art der Schulung, Anzahl der betroffenen Personen, benötigte Ressourcen, Terminplanung etc.) und an die verantwortliche Stelle weitergeleitet.

Einladung zugestellt

Eine Einladung zur Teilnahme an einer Marketingaktion wurde dem Kunden zugestellt (Ziel: Veranlassung einer Reaktion, Kontaktaufnahme durch den Kunden).

Ereignisliste

325

Einsatzplan erstellt

Der Einsatzplan (z.B. auch Schichtplan) für Mitarbeiter, evtl. auch Systeme für die nächste Planperiode, ist gemäß den Vorgaben des Unternehmens erstellt und den betroffenen Stellen, Mitarbeitern, Management, Personalabteilung etc. zugänglich gemacht.

Entschädigung gefordert

Vom Lieferant wird formgerecht eine Entschädigung gefordert. Der Vorgang ist in den entsprechenden Systemen dokumentiert. Die Forderung ist dem Lieferanten zugestellt.

Entwicklungsauftrag freigegeben

Ein entsprechender vom Kunden unterschriebener Vertrag liegt vor. Alle Vorgaben des Unternehmens zur Freigabe der Auftragsabwicklung für einen Entwicklungsauftrag liegen vor.

Event identifiziert

Ein Überwachungssystem (Produktionssteuerung, System Monitoring) meldet eine Warnung oder einen Alarm, der auf eine Störung oder ein Problem in der Produktion, bei einer Maschine oder in einem Programmablauf hinweist.

Höchste Mahnstufe erreicht

In unserem virtuellen Unternehmen wird maximal dreimal gemahnt. Wird das dritte Mal gemahnt, ist die höchste Mahnstufe erreicht.

HW bestellt

Eine Hardware wurde bestellt, eine entsprechende Vereinbarung inkl. Hardware-Spezifikation, Menge, Preis und Liefertermine liegt vor.

HW geliefert

Eine Hardware wurde vom Unternehmen gemäß Bestellung / Auftrag und den internen Vorgaben bereitgestellt und ausgeliefert

HW-System bestellt

Ein von unserem Unternehmen entwickeltes bzw. produziertes Hardware-System wurde im Rahmen eines Auftragsabwicklungsprozesses gemäß den damit verbundenen Richtlinien und Vorgaben bestellt. Die Bestellung ist mit allen notwendigen Angaben im entsprechenden, den Abwicklungsprozess unterstützenden System erfasst.

Incident identifiziert

Eine Störung in der Nutzung eines von unserem Unternehmen unterstützten Systems wurde erkannt. Es wurde ein Incident-Ticket eröffnet, alle Kontaktdaten erfasst und die Bearbeitung des Incidents z.B. durch Zuweisung an einen passenden Sachbearbeiter eingeleitet.

Infrastrukturbedarf ermittelt

Eine Anforderung bzgl. Ausbau, Ergänzung, Änderung der bestehenden Infrastruktur wurde erkannt und der Bedarf gemäß den Vorgaben spezifiziert und an die verantwortlichen Stellen weitergeleitet.

326

Anhang

Kapazitäts- und Skillbedarf erstellt

Der Bedarf an Personal in Form von Kapazität und Qualifikation ist gemäß den Vorgaben der Unternehmung und gemäß der Planungszyklen definiert und liegt vor.

Known Error behoben

Ein bekannter Fehler wurde definitiv behoben. Ein Nachweis der Fehlerbehebung bzw. -beseitigung liegt vor. Er ist in der Knowledge Database erfasst und entsprechend dokumentiert.

Known Error definiert

Ein Fehler wurde aufgrund der Kriterien jederzeit reproduzierbar oder regelmäßig feststellbar als solcher identifiziert und akzeptiert. Es liegt eine eindeutige Fehlerbeschreibung sowie, soweit möglich, eine Umgehungslösung vor. Er ist in der Knowledge Database erfasst.

Kontakt abgeschlossen

Ein im Rahmen des Contact Managements erfasster und bearbeiteter Kontakt gilt als abgeschlossen, wenn der entsprechende dafür im Contact Management angelegte und geführte Datensatz („Ticket“) gemäß den Vorgaben der Unternehmung gepflegt wurde und am Ende der Bearbeitung der Status auf abgeschlossen gesetzt wurde.

Kontakt aufgenommen

Ein Kontakt mit einem Kunden oder Geschäftspartner wurde aufgenommen. d.h. er ist erreicht worden und die vorgesehene Information konnte übermittelt werden. Im Fall einer Kontaktaufnahme von außen konnte der Kunde bzw. Geschäftspartner seine Anfrage ans Unternehmen platzieren. Der Kontakt wird im Contact Managementsystem als offener und zu überwachender, da noch in Bearbeitung befindlicher Kontakt verwaltet.

Kontaktaufnahme gestartet

Zieladressaten für eine Umfrageaktion sind gemäß statistischen Vorgaben definiert. Die zeitliche Reihenfolge für Ansprache der einzelnen Zielgruppen ist definiert. Erste Ansprachen sind erfolgt.

Konzeptauftrag formuliert

Für die Erarbeitung eines Konzeptes wurde ein entsprechender Auftrag gemäß den Vorgaben und Richtlinien des Unternehmens definiert und den verantwortlichen bzw. ausführenden Stellen zugestellt.

Konzeptergebnis erarbeitet

Das Konzeptergebnis (z.B. eine Studie) liegt gemäß erteiltem Auftrag und Vorgaben vor und wurde dem Empfänger zugestellt.

Kooperationsanfrage gestellt

Ein Geschäftspartner hat dem Unternehmen eine Anfrage, z.B. in Form eines Kooperationsvertrages, für eine weitergehende Zusammenarbeit (Kooperation) unterbreitet.

Ereignisliste

327

Kooperationsvertrag unterschrieben

Ein Kooperationsvertrag ist von allen Parteien unterschrieben und liegt dem Unternehmen vor.

Kooperationsvertrag vorgeschlagen

Ein Kooperationsvertrag wurde gemäß den Vorgaben und Richtlinien des Unternehmens erstellt, unterschrieben und dem potenziellen Kooperationspartner zugestellt.

Kreditorenbericht erstellt

Der Kreditorenbericht liegt gemäß den internen Vorgaben und Richtlinien vor.

Kreditorenrechnung erstellt

Eine Leistungsverrechnung eines Lieferanten liegt vor.

Kreditorenrechnung gezahlt

Eine Leistungsverrechnung eines Lieferanten wurde beglichen, die Zahlungsanweisung wurde ausgeführt, die entsprechenden Informationen liegen in den internen Systemen vor.

Kunde kontaktiert

Mit einem Kunden wurde Kontakt aufgenommen. Der Kontakt wurde im entsprechenden Customer Relationship Management System mit Datum und Kontaktgrund, Inhalt und Kundenreaktion dokumentiert.

Kundendaten aktualisiert

Bestehende Kundendaten wurden geändert oder aktualisiert. Die damit verbundene Datenpflege im CRM-System erfolgte.

Kundeninformation erstellt

Die im Rahmen einer vereinbarten Rückmeldung benötigten Kundeninformationen sind vorhanden.

Kundenportfolio aktualisiert

Für die jeweilige Berichtsperiode sind für jeden Kunden die Kennzahlen bzgl. Umsätzen und Auftragseingängen, jeweils verteilt auf die einzelnen Produkt- und Leistungsgruppen, erhoben und in den entsprechenden Systemen abgelegt und verfügbar.

Kundenserviceauftrag beendet

Alle Bedingungen, die mit der Erbringung eines Kundeserviceauftrages zusammenhängen, wurden erfüllt. Oder ein zeitlich befristeter Vertrag ist ausgelaufen. Alle mit der Einstellung verbundenen Aktivitäten wurden durchgeführt.

Kundenserviceauftrag freigegeben

Ein entsprechender vom Kunden unterschriebener Vertrag liegt vor. Alle Vorgaben des Unternehmens zur Freigabe der Auftragsabwicklung für einen Kundenserviceauftrag liegen vor.

Kundenservice-Offerte erstellt

Die Stelle, die für die Planung und Koordination der Customer Services verantwortlich ist, hat auf Anfrage des Verkaufes ein internes Angebot für die Erbringung von Kundendienstleistungen gemäß den Vorgaben und Richtlinien der Unternehmung erstellt und dem Verkauf übergeben.

328

Anhang

Kundenservice-Planungsauftrag freigegeben

Der Auftrag an den Bereich Customer Services, ein Angebot für die auf der Basis einer Kundenanfrage formulierte Leistungsanfrage zu erstellen, ist erteilt. Alle Anforderungen sind spezifiziert und der Termin für die interne Rückmeldung ist vorgegeben.

Leistungsanfrage formuliert

Ein Kunde hat (in seiner Sprache) eine Anfrage nach einer Dienstleistung oder einem Produkt gestellt – unabhängig davon, ob es sich um eine Leistung handelt, die das Unternehmen erbringt oder nicht. Dies kann von einer verbalen oberflächlichen Aussage („ich benötige Unterstützung …“) bis zum Ausfüllen eines Bestellformulars für eine konkrete Hardware reichen.

Leistungsdaten erfasst

Alle externen Leistungsdaten, die im Rahmen des Projekt Controllings benötigt werden, wurden gemäß den Vorgaben an die Lieferanten periodengerecht geliefert und in den entsprechenden Systemen erfasst.

Lieferauftrag freigegeben

Die Beschaffung einer Ware / Leistung wird im Rahmen eines Projektes freigegeben. Die für die Bestellung notwendigen Informationen (wie Art der Leistung, Mengen, Termine etc.) sind definiert.

Lieferstatus angefordert

Konkrete Anforderung nach der Statusmeldung eines sich in der „Lieferung“ befindlichen Objektes bzw. einer Leistung.

Lieferstatus gemeldet

Der aktuelle Lieferstatus für eine Ware / Leistung wurde gemeldet und in den entsprechenden Systemen erfasst und ist den Berechtigten zugänglich.

Lizenz abgelaufen

Eine Lizenzfrist ist abgelaufen. D.h. es wurde der Tag 1 nach dem Ablauf der vertraglich festgelegten Lizenzfrist erreicht.

Lizenz aktiviert

Eine mit einer Lizenz verbundene Leistung (z.B. Zugriff auf eine Software) kann ab sofort genutzt werden. Alle dafür notwendigen Aktivitäten wurden ausgeführt.

Lizenz benötigt

Für die Nutzung der mit einer Lizenz verbundenen Leistungen sind die Nutzungsvoraussetzungen noch nicht erreicht und müssen geschaffen werden.

Lizenz deaktiviert

Eine mit einer Lizenz verbundene Leistung (z.B. Zugriff auf eine Software) kann ab sofort nicht mehr genutzt werden. Alle dafür notwendigen Aktivitäten wurden ausgeführt.

Mahnung erstellt

Ein Mahnschreiben wurde erstellt und dem Empfänger zugestellt.

Ereignisliste

329

Material bereitgestellt

Bestelltes Material steht gemäß den Bestellungsvorgaben (Menge, Termin, Ort etc.) bereit.

Materialbedarf ermittelt

Der Materialbedarf ist hinsichtlich der Art des Materials, benötigter Menge, Liefertermin etc. definiert. Der Bedarf ist entsprechend den Vorgaben der Unternehmung an die verantwortlichen Stellen gemeldet.

Methodenanpassung identifiziert

Eine notwendige Anpassung einer angewandten Methode, eines eingesetzten Verfahrens ist erkannt, beschrieben und wurde an die Methoden -/ Verfahrenseinheit weitergeleitet.

Monitoring-Bericht erstellt

Die im Unternehmen definierten MonitoringBerichte liegen mit dem vorgegebenen Inhalt zu den vorgegebenen Terminen den verantwortlichen Stellen bzw. in den entsprechenden Systemen vor.

Nachbesserung gefordert

Von einem Lieferanten wird eine Nachbesserung der erbrachten Leistung bzw. des gelieferten Produktes schriftlich und formgerecht gefordert.

Neue Leistung gefordert

Ein Kunde wünscht eine Leistung, die das Unternehmen nicht bzw. noch nicht erbringt. Die Art der gewünschten Leistung ist beschrieben, klassifiziert und beurteilt. Sie ist dem Produkt-Management zugewiesen.

Neue Technologie verfügbar

Eine für das Unternehmen interessante und relevante neue Technologie ist soweit ausgereift, dass das Unternehmen darauf aufbauend die Weiter- oder Neuentwicklung von Produkten und Dienstleistungen planen kann. Dass eine neue Technologie als für das Unternehmen verfügbar gilt, wird aufgrund unternehmensspezifischer Kriterien festgelegt.

Neuer CI-Basic-Type benötigt

Für die Erfassung in der Configuration Database wird eine neue Datenstruktur für die Erfassung und Pflege eines CI-Basic-Types (echtes Einzelelement) benötigt. Der entsprechende CI-Basic-Type ist von der Stelle, die den Einsatz von Technologie im Unternehmung steuert, freigegeben worden. Alle notwendigen Attribute sind definiert.

Neuer CI-Structure-Type benötigt

Für die Erfassung in der Configuration Database wird eine neue Datenstruktur für die Erfassung und Pflege eines CI-Structure-Types (eine vorgegebene Konfiguration aus mehreren CIs) benötigt. Der entsprechende CI-Structure-Type ist von der Stelle, die den Einsatz von Technologie im Unternehmung steuert, freigegeben worden. Alle notwendigen Attribute sind definiert.

330

Anhang

Neuer CI-Type definiert

Eine Datenstruktur für einen CI-Basic-Type oder einen CI-Structure-Type wurde definiert, die KeyAttribute zugewiesen und in der Configuration Database integriert und zur Nutzung freigegeben.

Notfall eingetreten

Eine Notfallsituation ist für das Unternehmen gemäß der getroffenen bzw. mit den Kunden vereinbarten Definitionen eingetreten.

Notfallstatus gemeldet

Gemäß den jeweiligen Richtlinien sind alle betroffenen Stellen kontaktiert und informiert worden.

Notfallszenario definiert

Ein Notfallszenario bestehend aus der Definition eines Notfalls und einem Notfallplan (was ist in welcher Reihenfolge zu tun etc.) ist erstellt und von allen Beteiligten (Kunden, Lieferanten, ICT-Unternehmung) gemeinsam verabschiedet worden.

Notfallszenarien unvollständig

Ein Notfallszenario enthält nicht alle notwendigen Definitionen, Aktivitätenpläne etc. Defizite sind in einem Maßnahmenkatalog festgehalten.

Offerte angefordert

Ein oder mehrere Lieferanten wurden zur Angebotsabgabe gemäß abgegebener Leistungsbeschreibung / Anforderungskatalog aufgefordert.

Offerte eingereicht

Ein oder mehrere Lieferanten haben ein Angebot für die Erbringung / Lieferung von Leistungen eingereicht.

On-Site-Einsatz beauftragt

Ein Auftrag für einen Vorort-Einsatz (z.B. eines Servicetechnikers) wurde gemäß Richtlinien und Vorgaben des Unternehmens beauftragt. Hierzu gehören: Art der Leistung, Kundeninformationen, Aufwandsvorgaben etc.

On-Site-Einsatz notwendig

Für die Erbringung einer Leistung wird ein Einsatz vor Ort angekündigt. Die im Unternehmen definierten Kriterien, die einen Vor-Ort-Einsatz erlauben – wie z.B. Ist-Bestandteil des Supportvertrages, Kunde zahlt die Leistung, Kunde befindet sich im Einzugsgebiet etc. – sind erfüllt.

Outbound-Aktivität definiert

Eine gezielte Kontaktaufnahme mit Kunden / potenziellen Kunden (z.B. über das Service-Desk- / Call Center der Unternehmung) ist konzipiert (Inhalte beschrieben), vorbereitet (Adressstämme vorbereitet, Ressourcen und Termine geplant) und von den verantwortlichen Stellen freigegeben.

Output geliefert

Der Produktions-Output ist gemäß Produktionsvorgabe im Sinne von Umfang, Menge und Qualität produziert und an den Empfänger weitergeleitet worden (reicht von Bereitstellung zur Abholung bis zur Auslieferung).

Ereignisliste

331

Output produktionsbereit

Alle Aktivitäten, die vor der Produktion bzw. Erzeugung des Outputs durchgeführt werden müssen, sind erledigt, die Daten sind entsprechend aufbereitet und alle notwendigen Ressourcen sind verfügbar.

Output-Produktion abgeschlossen

Alle Kriterien, die für den ordnungs- und auftragsgemäßen Abschluss einer Output-Produktion definiert wurden, sind erfüllt.

Partner beurteilt

Eine Geschäftspartnerbeurteilung gemäß den Richtlinien der Unternehmung wurde durchgeführt. Der Geschäftspartner wurde über das Ergebnis informiert.

Partner-Audit notwendig

Ein oder mehrere Kriterien des ICT-Unternehmens wie z.B. wiederholte Terminverschiebungen, die einen Partner-Audit zur Folge haben, sind erfüllt. Ein entsprechender Antrag mit Begründung und Hinweisen, worauf beim Audit speziell zu achten ist, liegt vor.

Partner-Risiko erkannt

Ein oder mehrere Risiken, die sich in der Zusammenarbeit mit einem Partner ergeben bzw. die beim Partner bestehen, sind identifiziert und bzgl. ihrer möglichen Konsequenzen für das Unternehmen beschrieben und Möglichkeiten zur Risikominimierung oder -vermeidung wurden aufgezeigt.

Partnersuchauftrag erteilt

Ein Suchauftrag mit einem definierten Suchprofil für einen Geschäftspartner ist formuliert und den ausführenden Stellen zugewiesen.

P-Change identifiziert

Eine geforderte bzw. gewünschte Änderung betrifft ein laufendes Projekt (Projekt-Change), der damit verbundene Antrag ist dem entsprechenden Projekt zugewiesen.

P-Change-Antrag entschieden

Für einen Projektänderungsantrag liegt die Entscheidung vor.

P-Change-Antrag gestellt

Eine Projektänderung wurde gemäß den dafür gültigen Vorgaben dokumentiert und der Änderungsantrag an die verantwortlichen Stellen zur Entscheidung weitergeleitet.

P-Change-Antrag abgelehnt

Eine beantragte Projektänderung wurde begründet abgelehnt.

Pendenz erstellt

Eine Tätigkeit wurde als offene, zu erledigende Aktivität mit der Information, wer dafür verantwortlich ist und bis wann sie erledigt sein muss, definiert.

Personalbedarf definiert

Ein Bedarf an Personal ist gemäß den internen Vorgaben (z.B. Anzahl, angestrebtes Beschäftigungsverhältnis, benötigte Ausbildung, vorgesehene Funktion etc.) des Unternehmens definiert.

332

Anhang

Planung Kundenservice erstellt

Die Planung der Kundeserviceaktivitäten ist abgeschlossen, Einsatz-, Schicht- und Arbeitspläne liegen vor und sind in den entsprechenden Systemen erfasst. Kunden und die verantwortlichen sowie betroffenen Stellen sind informiert.

Planungsauftrag erteilt

Alle notwendigen Angaben für die Planung eines Projektes liegen vor, die für die Projektplanung notwendigen Mittel und Ressourcen sind freigegeben.

Plattformangebot aktualisiert

Die ICT-Infrastruktur wurde um weitere Systeme (Plattformen) erweitert, diese stehen für den produktiven Betrieb zur Verfügung.

P-Risiko erkannt

Ein oder mehrere Projektrisiken wurden identifiziert und bzgl. ihrer möglichen Konsequenzen für das Projekt, für den Kunden und für das Unternehmen beschrieben und Möglichkeiten zur Risikominimierung oder -vermeidung wurden aufgezeigt.

Problem gelöst

Ein bekannter Fehler wurde definitiv behoben. Ein Nachweis der Fehlerbehebung bzw. -beseitigung liegt vor.

Problem identifiziert

Eine Störung wird als schwerwiegend eingestuft. Es wird davon ausgegangen, dass die Ursache ein Problem (wie z.B. ein Software-Fehler oder ein Hardware-Defekt) darstellt, welches genauer analysiert werden muss. Alle bisherigen Informationen sind in einem Ticket zusammengestellt, das Problem wurde an die bearbeitende Stelle weitergeleitet.

Produkt bestellt

Eine Bestellung für ein Produkt liegt vollständig vor, die Bestelldaten sind im entsprechenden System erfasst und stehen für die weitere Bearbeitung zur Verfügung.

Produkt eliminiert

Ein Produkt ist aus dem Produktkatalog gestrichen, alle damit verbundene Aktivitäten (z.B. Anpassung der Systeme etc.) sind durchgeführt.

Produkt freigegeben

Ein Produkt ist für den Verkauf freigegeben. Alle mit dem Produkt verbundenen Informationen liegen vor.

Produktion gestartet

Alle Produktionsvorgaben und Kriterien wie z.B. Verfügbarkeit der Systeme, die für den Start der Produktion notwendig sind, sind erfüllt und die Produktion hat begonnen.

Produktionsauftrag aktualisiert

Ein bestehender Produktionsauftrag wurde geändert bzw. ergänzt. Alle Informationen liegen in den entsprechenden Systemen und den betroffenen Stellen vor.

Produktionsauftrag beendet

Alle Produktionsvorgaben und Kriterien, die für die Erfüllung eines Produktionsauftrages definiert wurden, sind erfüllt.

Ereignisliste

333

Produktionsvertrag freigegeben

Ein entsprechender vom Kunden unterschriebener Vertrag liegt vor. Alle Vorgaben des Unternehmens zur Freigabe der Auftragsabwicklung für einen Produktionsvertrag liegen vor.

Produktionsauswirkung definiert

Ergebnis der Analyse eines Events (Warnung, Alarmmeldung) – die möglichen Auswirkungen auf die Produktion sind identifiziert und beschrieben, die Ergebnisse sind der Produktionssteuerung mitgeteilt.

Produktionsbericht erstellt

Der Bericht über eine vorgegebene Produktionsperiode (z.B. Tages-, Wochenbericht etc.) wurde gemäß den Vorgaben und Richtlinien der Unternehmung oder der vereinbarten Verträge erstellt und den vorgegebenen Stellen zugestellt.

Produktionsofferte erstellt

Auf der Basis einer Leistungsanfrage für eine Produktionsleistung wurde für den Verkauf ein Angebot für die Produktionsleistungen inkl. genauer Beschreibung der Leistung, des Ressourcenbedarfs, den Pflichten des Kunden, der Aufwände und Termine etc. erstellt und zugestellt.

Produktionsplanung erstellt

Die Produktionsplanung ist gemäß den Vorgaben der Unternehmung hinsichtlich Produktionsinhalten, Terminen, Ressourcen- und Materialbedarf etc. für die vorgegebene Planungsperiode erstellt. Sie ist in den entsprechenden Systemen erfasst und den verantwortlichen und ausführenden Stellen zugänglich gemacht.

Produktionsplanungsauftrag freigegeben

Alle notwendigen Informationen für die Erstellung einer Produktions-Offerte liegen vor. Die dafür notwendigen Aufwände wurden vom Management genehmigt.

Produktionsvorgabe erstellt

Alle Vorgaben wie Produktionsinhalte, Start-, EndTermine, Verfügbarkeiten, Auslastungsraten etc. sind definiert und in den entsprechenden PlanungsSteuerungs- und Überwachungssystemen erfasst.

Produktportfolio aktualisiert

Das bestehende Produktportfolio wurde geändert bzw. ergänzt, die Informationen in den entsprechenden Systemen dokumentiert und zur Verfügung gestellt.

Projekt abgelehnt

Ein geplantes, beantragtes Projekt wurde begründet abgelehnt.

Projekt abgenommen

Ein Projekt wurde vom Auftraggeber abgenommen, d.h. alle Vereinbarungen und damit verbundene Kriterien wurden erfüllt bzw. evtl. Abweichungen wurden dokumentiert und akzeptiert. Das Projekt ist damit bzgl. der Leistungserbringung beendet.

334

Anhang

Projekt abgeschlossen

Alle internen Vorgaben und Richtlinien sowie alle mit dem Kunden getroffenen Vereinbarungen, die ein Projekt definitiv abschließen, sind erfüllt (z.B. alle Rechnungen sind bezahlt, alle Mängel sind beseitigt etc.)

Projekt beantragt

Ein Projektauftrag gemäß den Vorgaben der Unternehmung ist erstellt und liegt zur Entscheidung vor.

Projekt vorgeschlagen

Ein Vorhaben soll projektorientiert abgewickelt werden. Die Projektidee, das Vorhaben, ist soweit beschrieben, dass die Ausarbeitung eines Projektauftrages bzw. Projektantrages möglich ist.

Projekt- / Entwicklungsprogramm aktualisiert

Die Projekt- bzw. Entwicklungsvorhaben-Datenbank der Unternehmung wurde inhaltlich verändert bzw. ergänzt. Die Änderungen wurden dokumentiert und den verantwortlichen Stellen mitgeteilt.

Projektauftrag freigegeben

Ein Projektauftrag wurde gemäß den internen Vorgaben freigegeben. Die Ressourcen wurden zugeteilt, die Mittel bewilligt.

Projektbericht erstellt

Der Projektbericht wurde gemäß den internen Vorgaben oder gemäß den Vorgaben des Kunden erstellt und den Empfängern zugestellt.

Projektofferte erstellt

Im Rahmen des Angebotsprozesses wurde für den Verkauf auf der Basis einer Leistungsanfrage ein Angebot für die Realisierung eines Projektes inkl. aller notwendigen Informationen wie Aufwände, Termine, Ressourcenbedarf etc. erstellt.

Projektplan aktualisiert

Ein Projektplan wurde neu angelegt oder inhaltlich geändert. Er wurde in den entsprechenden Systemen abgebildet und den verantwortlichen und ausführenden Stellen verfügbar gemacht.

Prozessänderung identifiziert

Es wurde eine notwendige bzw. sinnvolle Veränderung eines Prozesses (auch z.B. beim Kunden oder bei einem Geschäftspartner) identifiziert, die zu treffenden Maßnahmen beschrieben und der Veränderungsvorschlag den betroffenen Stellen unterbreitet.

Prozesshandbuch aktualisiert

Das Prozesshandbuch wurde geändert, mit einer neuen Versionskennung versehen und die neue Version zur Verfügung gestellt.

Prozessvorgabe erstellt

Eine Vorgabe für einen Prozess wurde definiert und beschrieben, in den entsprechenden Systemen dokumentiert, die verantwortlichen Stellen informiert und an die ausführenden Stellen weitergeleitet.

Ereignisliste

335

Q-Audit beantragt

Ein Qualitäts-Audit wurde gemäß den Vorgaben der Unternehmung beantragt. Ziele und Umfang des QAudits sind definiert.

Q-Ziele definiert

Die Qualitätsziele sind definiert, vom Management freigegeben, in den entsprechenden Systemen dokumentiert und den betroffenen Stellen kommuniziert.

R-Change identifiziert

Ein Änderungsbegehren wurde als Änderung an einem bestehenden Release erkannt und zur weiteren Bearbeitung an das Release Management weitergeleitet.

Realisierungsauftrag erteilt

Der Auftrag für die Erbringung von Beratungs-, Konzeptions- oder Entwicklungstätigkeiten wurde gemäß den internen Vorgaben und Richtlinien formuliert und den entsprechenden Realisierungseinheiten zugewiesen.

Rechnungsgrundlagen erstellt

Alle Informationen aus einem neuen Vertrag liegen vor, damit das Abrechnungs- bzw. Fakturasystem für die zukünftige Leistungsverrechnung eingerichtet werden kann.

Reklamation eskaliert

Eine Reklamation wurde auf eine höhere Managementebene gemäß den Vorgaben der Unternehmung weitergeleitet, inkl. einer Dokumentation des Beschwerdegrundes, Hintergrund zum Beschwerdeführer, bereits durchgeführte Aktivitäten etc.

Reklamation identifiziert

Eine Kundenrückmeldung wird als Reklamation klassifiziert, im Beschwerde-Management-System erfasst und an die zu bearbeitende Stelle weitergeleitet.

Release archiviert

Ein Release-Stand wird archiviert. Der Status „Archiv“ ist vom Unternehmen definiert. Hier: Das Release ist zur Neu-Installationen / Verbreitung nicht mehr verfügbar. Alle Stellen sind informiert.

Release produktiv

Ein neues Release ist für die Produktion freigegeben und ab sofort verfügbar. Es ist in den entsprechenden Systemen dokumentiert bzw. verfügbar. Alle Stellen sind informiert.

Release-Package konfiguriert

Die Komponenten eines Releases sind gemäß den Vorgaben der Unternehmung zu einem voll funktionsfähigen Paket zusammengestellt worden. Das Package ist in den entsprechenden Systemen dokumentiert und verfügbar, die Anweisungen zur Installation des Release-Packages liegen vor.

Releaseplanung aktualisiert

Eine Releaseplanung wurde neu erstellt oder eine bestehende wurde geändert. Alle Änderungen sind in den entsprechenden Systemen nachgeführt bzw. dokumentiert. Die Planwerte sind vom Management freigegeben. Alle betroffenen Stellen sind informiert.

336

Anhang

Ressourcen alloziiert

Definierte Ressourcen wurden Vorhaben, Projekten, Aufgaben etc. verbindlich zugewiesen. Die Ressourcenzuteilung ist vom Management genehmigt und alle betroffenen Stellen sind informiert.

RFC formuliert

Ein Request for Change (Änderungsantrag) ist gemäß den Vorgaben und Richtlinien des Unternehmens dokumentiert und an das Change Management weitergeleitet worden.

Risiko erkannt

Ein Risiko ist als solches identifiziert, beschrieben und den verantwortlichen Stellen bekannt gemacht worden. Soweit möglich sind die Konsequenzen bei Risikoeintritt sowie Möglichkeiten zur Risikominimierung bzw. -vermeidung definiert.

Risikoanalyse aktualisiert

Eine Risikoanalyse wurde aktualisiert. Die Informationen sind in den entsprechenden Systemen abgelegt und verfügbar. Die verantwortlichen und betroffenen Stellen sind über die Aktualisierung informiert.

Risikoanalyse erstellt

Eine Risikoanalyse wurde neu erstellt. Die Informationen sind in den entsprechenden Systemen abgelegt und verfügbar. Die verantwortlichen und betroffenen Stellen haben die Analyse erhalten.

Schulung beauftragt

Ein Auftrag für die Durchführung einer Schulungsaktivität liegt inkl. Schulungsinhalten, Veranstaltungsort, Termin und Teilnehmern vor.

Schulungsauftrag freigegeben

Ein entsprechender vom Kunden unterschriebener Vertrag liegt vor. Alle Vorgaben des Unternehmens zur Freigabe der Auftragsabwicklung für einen Schulungsauftrag liegen vor.

Schulungsbericht erstellt

Der periodisch zu erstellende Schulungsbericht liegt gemäß den internen Vorgaben vor und wurde den verantwortlichen Stellen zugestellt.

Schulungskonzept entwickelt

Ein Schulungskonzept wurde gemäß den Vorgaben der Unternehmung erstellt, liegt als Dokument vor und wurde den Empfängern zugestellt.

Schulungsplanungsauftrag freigegeben

Alle notwendigen Informationen für die Erstellung eines Schulungskonzeptes (als Grundlage für ein Angebot) liegen vor. Die dafür notwendigen Aufwände wurden vom Management genehmigt.

Security-Audit beantragt

Ein Security-Audit wurde gemäß den Vorgaben der Unternehmung beantragt. Ziele und Umfang des Security-Audits sind definiert.

Seminar beurteilt

Eine Seminarbeurteilung durch die Teilnehmer liegt vor und ist von der bearbeiteten Stelle ausgewertet und analysiert sowie kommentiert worden.

Ereignisliste

337

Seminaranmeldung bestätigt

Der Kunde bzw. der Seminarteilnehmer hat eine Seminarbestätigung erhalten, die Seminarbestätigung ist in den entsprechenden Systemen eingetragen.

Seminarplanung aktualisiert

Die Inhalte der Seminarplanung (z.B. Inhalte, Termine, Veranstaltungsort) wurden geändert bzw. eine neue Seminarplanung (für die nächste Planungsperiode) erstellt. Die aktualisierte Seminarplanung ist freigegeben, in den entsprechenden Systemen erfasst und für alle Berechtigten zugänglich.

Servicebericht erstellt

Eine vor Ort erbrachte Leistung wurde gemäß den Richtlinien der Unternehmung in einem Servicebericht dokumentiert. Der Servicebericht wurde vom Kunden gegengezeichnet.

Sicherheitsanforderungen definiert

(Externe) Sicherheitsanforderungen, z.B. vom Kunden, vom Gesetzgeber etc., liegen in dokumentierter Form vor. Es ist festgelegt, welche der Anforderungen für das Unternehmen relevant sind und umgesetzt werden müssen.

Sicherheitsanforderungen identifiziert

Schutzwürdige Objekte bzw. Zustände oder Ähnliches sind identifiziert, mögliche Konsequenzen bei fehlenden Schutzmechanismen sind beschrieben.

Sicherheitsproblem erkannt

Ein Sicherheitsproblem wurde identifiziert, die Risiken und Konsequenzen, die mit dem Sicherheitsproblem zusammenhängen, sind beschrieben. Die verantwortlichen Stellen sind informiert.

Sicherheitsreport erstellt

Der Sicherheitsreport gemäß den Vorgaben der Unternehmung ist erstellt und liegt in schriftlicher Form dem definierten Empfängerkreis vor.

Sicherheitsstandards definiert

Die Sicherheitsstandards der Unternehmung sind definiert, dokumentiert und kommuniziert.

Standardangebot zugestellt

Ein Standardangebot ist gemäß Vorgaben und Richtlinien der Unternehmung erstellt und dem potenziellen Kunden zugestellt worden.

Standard Change festgestellt

Ein Change erfüllt die im Unternehmen festgelegten Kriterien für einen Standard Change.

Steuerungsvorgaben definiert

Die Vorgaben, nach denen ein Projekt gesteuert wird, wie z.B. Berichtsperioden, Berichtsinhalte, Controllingaktivitäten etc., sind definiert und dem Projektteam (Lenkungsausschuss, Projektleiter) bekannt.

Stornierung bestätigt

Die Stornierung eines Auftrages wurde gemäß den Vorgaben der Unternehmung dem Kunden bestätigt und in den entsprechenden Systemen dokumentiert.

S-Vertrag gekündigt

Die Kündigung eines Supplier-(Lieferanten-)Vertrages liegt form- und fristgerecht vor. Die entsprechenden Stellen sind informiert.

338

Anhang

S-Vertrag unterzeichnet

Ein Supplier-Vertrag wurde formgerecht unterzeichnet und der Vertrag liegt in schriftlicher Form vor. Die entsprechenden Informationen sind in der Supplier Database abgelegt. Die betroffenen Stellen sind informiert.

SW bestellt

Eine Software wurde bestellt, eine entsprechende Vereinbarung inkl. Software-Spezifikation, Anzahl der Lizenzen, Preis und Liefertermine liegt vor.

SW geliefert

Eine Software wurde vom Unternehmen gemäß Bestellung / Auftrag und den internen Vorgaben bereitgestellt und ausgeliefert.

System abnahmebereit

Ein entwickeltes System ist bereit zur Abnahme. Alle vertraglich vereinbarten Abnahmekriterien sind erfüllt. Alle vereinbarten Lieferobjekte sind fertiggestellt und übergabebereit. Der Termin für die Abnahme ist definiert.

System freigegeben

Das System erfüllt alle Kriterien, die für eine Produktionsfreigabe vom Unternehmen vorgegeben wurden.

System geliefert

Das System ist gemäß den Vereinbarungen geliefert und vom Abnehmer entgegengenommen worden. Eine vom Empfänger abgezeichnete Lieferbescheinigung liegt vor.

Technische Abnahme erfolgt

Ein System / Release wurde technisch abgenommen, wenn alle vom Unternehmen für dieses System / Release vorgegebenen technischen Abnahmekriterien erfüllt wurden. Weiter liegt ein technisches Abnahmeprotokoll inkl. Unterschriften der abnehmenden Experten vor.

Technologie veraltet

Die eingesetzte Technologie erfüllt die vom Unternehmen definierten Kriterien, ab wann eine Technologie veraltet ist und vom Unternehmen nicht mehr eingesetzt bzw. unterstützt wird (z.B. wird vom Hersteller nicht mehr unterstützt, Produkte sind im freien Handel nicht mehr erhältlich etc.). Die entsprechende Komponente ist identifiziert. Konsequenzen und Ersatzmöglichkeiten sind aufgezeigt.

Themenanforderung definiert

Themen für die Entwicklung von Schulungsleistungen sind identifiziert, beschrieben und so aufbereitet (z.B. Marktabschätzung, Bedarfsmeldungen), dass die Entscheidung, ob sie in die Seminarplanung integriert werden sollen, möglich ist.

Ereignisliste

339

Trainer-Bedarf ermittelt

Der Bedarf an Trainern hinsichtlich Wissensgebieten, Kapazitäten etc. ist definiert und in den entsprechenden Systemen erfasst und den verantwortlichen Stellen gemeldet.

Trendanalyse aktualisiert

Die Trendanalyse im Sinne von Markt-, Produktund Technologietrends wurde mit den neuen Daten und Informationen aktualisiert. Die Ergebnisse der Trendanalyse sind in den entsprechenden Systemen dokumentiert und allgemein verfügbar.

Unternehmens-Methode definiert

Ein Verfahren, eine Arbeitstechnik, eine Methode ist als Standard oder als zugelassenes Arbeitsmittel für das Unternehmen definiert, beschrieben, zur Verwendung freigegeben und allgemein zugänglich gemacht. Die betroffenen Stellen sind informiert.

Umfrage beantwortet

Die Ergebnisse einer Umfrage liegen ausgewertet vor und sind für den ausgewählten Empfängerkreis verfügbar.

Umsatzmeldung erstellt

Die periodisch zu erstellende Statistik der Umsätze ist gemäß den Vorgaben der Unternehmung erstellt und in den entsprechenden Systemen verfügbar.

Verrechnungsdaten zusammengestellt

Die für eine Verrechnung von Leistungen benötigten Daten sind gemäß den Vorgaben und Richtlinien der Unternehmung in den entsprechenden Betriebsdatenerfassungssystemen erfasst, den entsprechenden Verrechnungskonten zugewiesen, auf ihre Korrektheit geprüft und stehen dem Abrechnungssystem für die Faktura zur Verfügung.

Verbesserung vorgeschlagen

Ein Verbesserungsvorschlag gemäß den Vorgaben und Richtlinien der Unternehmung liegt in dokumentierter Form vor.

Verbesserungspotenzial identifiziert

Ein Verbesserungspotenzial wurde erkannt und formuliert.

Vertrag erfüllt

Alle im Vertrag vereinbarten Erfüllungskriterien sind erbracht. Die Vertragserfüllung ist von dem Vertragspartner bestätigt. Der entsprechende Status ist im Vertragsverwaltungssystem eingetragen.

Vertrag gekündigt

Der Vertrag ist formgerecht gekündigt. Alle mit der Kündigung verbundenen Dokumente liegen vor.

Vertrag unterzeichnet

Der Vertrag ist von allen Vertragspartnern formgerecht unterzeichnet. Alle mit dem Vertrag zusammenhängenden Dokumente liegen vor.

Vertragsabweichung identifiziert

Eine Vertragsabweichung wurde erkannt, beschrieben und den verantwortlichen Stellen mitgeteilt.

340

Anhang

Vertragsänderung identifiziert

Eine vom Kunden gewünschte Vertragsänderung liegt vor, wenn mit dem Kunden eine Vertragsbeziehung besteht und wenn der Kunde auf der Basis dieses Vertrages Leistungen beziehen möchte oder bereits bezieht, die dort nicht geregelt sind.

Vertragsänderung notwendig

Inhalte eines bestehenden Vertrages sollen geändert werden. Die Änderungen sind identifiziert, beschrieben und begründet.

Vertragsverletzung identifiziert

Eine Abweichung von den vereinbarten Kriterien zur Vertragserfüllung erfüllt gemäß den Vorgaben der Unternehmung die Bedingungen einer Vertragsverletzung. Sie ist identifiziert und dokumentiert.

Ware eingegangen

Eine von einem Lieferanten gelieferte Ware ist beim Empfänger eingegangen. Ein Lieferschein, abgezeichnet von Empfänger und Lieferant, liegt vor. Die Ware ist physisch vorhanden.

Web-Content geändert

Die Inhalte der betroffenen Web Pages sind geändert, freigeschaltet und im Internet bzw. Intranet aufrufbar.

Werbedokumente zugestellt

Die Werbedokumente sind bei den ausgewählten Empfängern eingetroffen.

Wiedervorlage erstellt

Eine Arbeitsaufgabe wurde unterbrochen und auf Wiedervorlage gelegt. Alle bisherigen Arbeiten sind dokumentiert, die Wiedervorlage ist terminiert.

Wissensdefizite erkannt

Ein Wissensdefizit wurde identifiziert und beschrieben.

Zahlung erfolgt

Eine Zahlung wurde ausgelöst und die entsprechende Buchung (Geldeingang bzw. -ausgang) im Buchhaltungssystem gebucht.

Zugriffsberechtigung deaktiviert

Eine Zugriffberechtigung auf ein System ist ausgeschaltet, eine Anmeldung mit der deaktivierten Benutzer-ID ist nicht mehr möglich.

Schnittstellen zum Kontext Die folgenden Abbildungen stellen die wichtigsten Schnittstellen zwischen dem Prozess-Referenzmodell (ICT Company) und den Kunden sowie den Lieferanten dar. Die Schnittstellen sind definiert durch die Ereignisse, die jeweils im Prozess-Referenzmodell einen Prozess auslösen oder Ergebnis eines Prozesses sind.

Schnittstellen zum Kontext

341

Abb. 120. Schnittstellen Kunde – ICT-Prozess-Referenzmodell (ICT Company)

Abb. 121. Schnittstellen Lieferant – ICT-Prozess-Referenzmodell (ICT Company)

342

Anhang

ITIL-Disziplinen im ICT-Prozess-Referenzmodell In der folgenden Tabelle sind die wichtigsten ITIL-Disziplinen aufgelistet und mit einem Positionssymbol versehen. Ein Kreissymbol bedeutet, dass sich Funktionen, Aufgaben etc. mit Prozessbezug, die unter der jeweiligen ITIL-Disziplin beschrieben sind, im ICT-Referenzmodell auf mehrere Prozesskategorien verteilen. Bei einem Dreieck konzentrieren sich die jeweiligen Aktivitäten auf eine Prozesskategorie des ICT-ProzessReferenzmodells.

Abb. 122. Ausgewählte ITIL-Disziplinen

Die folgende Übersicht zeigt die Position der einzelnen ITIL-Disziplinen im ICT-Prozess-Referenzmodell.

ITIL-Disziplinen im ICT-Prozess-Referenzmodell

Abb. 123. Position ITIL-Disziplinen im ICT-Prozess-Referenzmodell

343

344

Anhang

FAQs Im Prozess-Referenzmodell können wir auf Anhieb keinen Geschäftsvorfall erkennen. Wie können wir spezifische Geschäftsvorfälle in Form einer End-to-End-Betrachtung, wie z.B. Kunde bestellt eine Hardware, Kunde erhält diese Hardware geliefert, dem Modell entnehmen? Einzelne Geschäftsvorfälle sind nicht ohne weiteres in dem ProzessReferenzmodell ersichtlich. Wir empfehlen hierzu zwei Ansätze: 1) Ausgewählte Geschäftsvorfälle können mit einer farblich markierten Linie, die die End-to-End-Verbindung herstellt, im Prozess-Referenzmodell grafisch hervorgehoben werden. 2) Ausgewählte Geschäftsmodelle werden separat dargestellt und sinnvollerweise gleichzeitig um weitere Informationen ergänzt. Wird dabei die gleiche Darstellungsmethodik verwendet, können die Zusammenhänge mit anderen Prozessen auf der Ebene des ProzessReferenzmodells problemlos nachvollzogen werden. Welche Definitionen auf der Ebene des Prozess-Referenzmodells sind sinnvoll, welche nicht? Hier gilt der Grundsatz „weniger ist mehr“. Der Anspruch, die wichtigsten logischen Zusammenhänge so darzustellen, dass sie mit relativ wenig Know-how von jedem Mitarbeiter aus dem Prozess-Referenzmodell abgeleitet werden können, ist schon hoch genug. Sinnvoll ist es somit, die wichtigsten Ereignisse und Aufgaben darzustellen sowie eine sinnvolle Gruppierung von Prozessen zu entwickeln. Weiter sollten alle wichtigen Schlüsselbegriffe, die in der Unternehmung zum Einsatz kommen, verwendet und eindeutig definiert werden. Werden weitergehende Details benötigt, empfiehlt es sich, diese in separaten, abgegrenzten Prozessbeschreibungen zu dokumentieren. Können wir mit dem Prozess-Referenzmodell ITIL abbilden bzw. erreichen wir ITIL-Konformität? Ja, das ist nicht nur problemlos möglich, sondern auch durchaus eine unserer Zielsetzungen. So empfiehlt es sich schon alleine die im ITIL-Glossar verwendeten Begrifflichkeiten wo immer möglich zu übernehmen. Weiter bietet ITIL eine Vielzahl von Informationen über Ereignisse, Verknüpfungen und Prozessinhalte.

FAQs

345

Viele Prozesse beinhalten nur einige wenige Aufgaben. Manche Aufgaben sind in der Praxis wesentlich umfangreicher, als der erste Eindruck es vermuten lässt. Außerdem könnten die Prozesse noch durch viele Aufgaben ergänzt und damit konkretisiert werden. Die Aufgaben, die in den Prozessen beschrieben sind, dienen primär dazu, eine Vorstellung der Prozessinhalte zu erhalten. Rein methodisch und darstellungstechnisch gesehen ist es das Ziel, „so viel wie nötig und so wenig wie möglich“ Aufgaben darzustellen. Die Zielsetzung, einen Gesamtüberblick zu schaffen, führt zwangsläufig dazu, dass die Anzahl der Objekte reduziert wird. Es ist klar, dass es hierbei zu Unschärfen bzgl. des Umfangs einer Aufgabe kommt. Je detaillierter Aufgaben beschrieben werden, desto stärker kommen die Besonderheiten einer Unternehmung zum Tragen und umso weniger allgemeingültig wird das Modell. Wenn Sie Ihr eigenes Modell gestalten, können Sie die genannten Rahmenbedingungen eher vernachlässigen und mehr Aufgaben mit einem tieferen Detaillierungsgrad beschreiben. Müssen wir zu der Grafik zwecks Verständnis nicht ein umfangreiches Prosa-Dokument erstellen? Nein! Sie brauchen zusätzlich sicher ein Glossar, damit das gemeinsame Verständnis der verwendeten Begriffe sichergestellt ist. I.d.R. existiert dies ja in der einen oder anderen Form bereits im Unternehmen. Weiter ist es didaktisch hilfreich, dass parallel ein typischer Geschäftsprozess isoliert dargestellt und seine Einbettung im Modell gezeigt wird. Wo liegt der Nutzen eines Prozess-Referenzmodells, wie es hier dargestellt ist? Primär handelt es sich um ein Kommunikationsinstrument, auf dessen Basis eine Reihe von Vorgaben wie z.B. Prozessschnittstellen gemacht und kommuniziert wird. Aufgrund der grafischen Aufbereitung und der empfohlenen Verbreitung im A0-Format hat es im Gegensatz zu jeder Dokumentation den Vorteil, visuell verfügbar zu sein. Da die verwendeten Begriffe definiert sind, werden die Gesprächspartner bzgl. der Verwendung dieser Begriffe gesteuert und es setzt sich ein gemeinsames Verständnis hierfür und für die Zusammenhänge durch. In der Praxis stellen wir immer wieder fest, dass es in den Unternehmen zahlreiche Spezialisten gibt, die einzelne Arbeitsabläufe, ausgewählte Prozessbereiche bis ins letzte Detail kennen. Es gibt allerdings selten jemanden, der einen Gesamtüberblick über die Zusammenhänge und Abhängigkeiten darstellen kann. Diese Lücke füllt das Prozess-Referenzmodell.

346

Anhang

Können wir die Grundstruktur des Prozess-Referenzmodells als Vorgabe für eine Aufbauorganisation verwenden? Das Prozess-Referenzmodell kann sicherlich einen gewissen Input liefern, aber die Entwicklung einer Aufbauorganisation ist auch noch von vielen anderen Gesichtspunkten abhängig, die wesentlich mehr Einfluss auf die Gestaltung der Aufbauorganisation haben. Wie viel Aufwand wird für die Erstellung eines Prozess-Referenzmodells nach vorliegendem Muster für unser Unternehmen / unsere Abteilung benötigt? Grundsätzlich schaffen wir es heute, firmenspezifische Prozess-Referenzmodelle innerhalb von 2–3 Monaten auch für größere Organisationen zu entwickeln. Was sicherlich nicht überrascht, ist, dass der meiste Aufwand seitens der Unternehmung in der Klärung und Definition von Begriffen liegt, die tagtäglich mit unterschiedlichster Interpretation im Unternehmen angewendet werden. Ist das Prozess-Referenzmodell für eine Zertifizierung verwendbar? Ja, es kann durchaus als Bestandteil einer entsprechenden QM-Dokumentation mit dem Ziel verwendet werden, das Prozessumfeld zu definieren. Natürlich sind z.B. für ein QM-Zertifikat noch eine Vielzahl weiterer Informationen bereitzustellen. Wie reagieren Mitarbeiter auf solch ein Modell? Operative Mitarbeiter sind zu Beginn skeptisch und nach Vorlage des Modells meist begeistert. Wesentliche Gründe sind: • Viele sehen zum ersten Mal das Unternehmen in seiner Gesamtheit und können sich und ihre Tätigkeit zuordnen. • Sie profitieren von dem gemeinsamen Verständnis. • Die Schnittstellen werden transparent und damit auch das Verständnis, welche Qualität die Ergebnisse an den Schnittstellen haben müssen. Benötigt das Modell ein Handbuch, wie umfangreich wird es und besteht nicht die Gefahr, dass es zur typischen „Schrankware“ wird? In der Praxis verbreiten wir das Modell am liebsten als ansehnliche A0Grafik. Es wird dann eher zu einer immer verfügbaren „Wallware“. Das für die Begriffe notwendige Glossar sollte elektronisch zur Verfügung ste-

FAQs

347

hen. Neue Mitarbeiter bzw. Mitarbeiter, die die Methodik noch nicht kennen, werden von erfahrenen Mitarbeitern, die ihnen die Lesetechnik erläutern in sehr kurzer Zeit „geschult“. Betriebsorganisation – wie bleibt das Prozess-Referenzmodell am Leben? Grundsätzlich empfehlen wir, ein Prozess-Referenzmodell so zu gestalten, dass es aufgrund des gewählten Abstraktionsniveaus möglichst statisch bleibt und der Veränderungsdruck gering bleibt. Trotzdem gibt es auch hier regelmäßige Anpassungen, die am besten über eine entsprechende Fachstelle (z.B. Qualitäts- oder Prozess-Management) organisiert wird. Macht es Sinn, das hier vorgestellte Modell 1:1 zu übernehmen? Nein. Unsere Erfahrung zeigt, dass etwa 80% der definierten Prozessstruktur übernommen werden können sowie die Begriffe und Definitionen, die auf ITIL basieren (soweit diese von der Organisation so akzeptiert werden). In jedem Unternehmen gibt es Besonderheiten, die zu berücksichtigen sind. Außerdem sollte man nicht die Bedeutung einer eigenen „Entwicklung“ unterschätzen. Die Identifikation mit einem eigenen ProzessReferenzmodell ist ein wesentlicher Erfolgsfaktor bei der Umsetzung im Unternehmen. Können die Grafiken in elektronischer Form bezogen werden? Ja. Sprechen Sie uns an. Im Prozess-Referenzmodell kommen kaum Negativ-Ereignisse vor. Dabei kann ja fast jede Aufgabe sowohl ein Ergebnis haben, das den normalen Prozessverlauf fortsetzt, als auch ein Negativ-Ergebnis, das den Vorgang abbricht oder in eine ganz andere Richtung steuert. Grundsätzlich kann davon ausgegangen werden, dass nach jeder Aufgabe ein Ergebnis vorliegt, welches erlaubt, den normalen Prozess fortzusetzen, die Fortsetzung (temporär) zu unterbrechen oder den Prozess an dieser Stelle zu beenden. Ein Beispiel: Die Aufgabe Antrag prüfen hat folgende Ergebnisse: • Antrag bewilligt (da vollständig und Prüfkriterien erfüllt), • Antrag unvollständig (es fehlt also etwas, das nachgefordert werden muss) und • Antrag abgelehnt (aus welchen Gründen auch immer).

348

Anhang

Im Prozess-Referenzmodell bilden wir das erste Ereignis, das die Prozesskette fortsetzt, ab. Das zweite Ereignis ist auf unserer Betrachtungsebene irrelevant und wird nicht abgebildet. Bei dem dritten Ereignis gibt es zwei Alternativen: Entweder ist von diesem Ereignis ein anderer Prozess im Prozess-Referenzmodell betroffen, dann wird es aufgeführt. Oder das Ereignis betrifft keinen anderen Prozess auf dieser Betrachtungsebene, dann wird das Ereignis nicht dargestellt. Auch hier gibt es eine Ausnahme: Handelt es sich um ein Ereignis, das für das Verständnis der Zusammenhänge wichtig ist, wird es dargestellt. In unserem Modell ist dies z.B. bei den Ereignissen Projekt abgelehnt und Change abgelehnt der Fall. Deckt das Prozess-Referenzmodell alle Geschäftsvorfälle ab? Ist es vollständig? Das Prozess-Referenzmodell bildet die Prozesse ab, die den jeweiligen „Architekten“ wichtig sind. Naturgemäß sollten die wertschöpfenden Prozesse vollständig abgebildet sein. Grundsätzlich kann gesagt werden: Je wichtiger ein Geschäftsvorfall, desto wahrscheinlicher findet er sich im Prozess-Referenzmodell; je unwichtiger, desto wahrscheinlicher wird er nicht berücksichtigt. Alle Geschäftsvorfälle abzubilden ist aber auch nicht das zwingende Ziel des Prozess-Referenzmodells. Wir haben Hunderte von Arbeitsanweisungen und Arbeitsabläufen bis ins letzte Detail beschrieben, viele werden teilweise bzw. vollständig mit DV-Systemen unterstützt, was bringt da so ein ProzessReferenzmodell, ist das nicht ein unnötiger Overhead? Die Overhead-Kritik ist nicht von der Hand zu weisen und wird auch oft von Führungskräften, die das Vorgehen und das Konzept nicht tragen, gerne verwendet. Bisher war es so, dass sich diese Personen vor den Ergebnissen nicht schützen konnten, da sie automatisch in den Kommunikationsprozess gezwungen werden. Ein Prozess-Referenzmodell schafft Transparenz der Zusammenhänge. Transparenz ist nicht immer gewünscht und wird dann schnell einmal zum Overhead. In Ihrem Prozess-Referenzmodell fehlen für unser Unternehmen Prozesse, und mehrere Prozesse spielen für uns keine Rolle bzw. gibt es bei uns nicht! Das ist in Ordnung. Unser Prozess-Referenzmodell erhebt nicht den Anspruch, abschließend, vollständig und allwissend zu sein. Es ist eine Referenz, ein Muster, eine Vorlage. Nehmen Sie das, was sie brauchen können,

FAQs

349

primär einmal die Methodik und die Darstellungstechnik, dann ausgewählte Prozesse oder Teile davon. Werfen Sie raus, was für Sie bedeutungslos ist, und integrieren Sie die Dinge, die Ihrem Unternehmen wichtig sind. Verschiedene Ereignisse, die Sie im Modell aufführen, werden nicht ausschließlich von Prozessen generiert, sondern z.B. auch durch Mitarbeiter. Wie ist damit umzugehen? Methodisch gesehen stellen wir hier hauptsächlich Verknüpfungen von Prozessen dar. Eine Ausnahme bilden die fett umrandeten Ereignisse, die sich an Prozesse oder Rollen wie z.B. Kunden, Lieferanten außerhalb der ICT-Unternehmung oder Managementfunktionen innerhalb des ICT-Unternehmens richten. Wollen Sie nun im Modell sichtbar machen, dass bestimmte Ereignisse wie z.B. Risiko erkannt (siehe Prozess 163 Risk Management) auch von einem Mitarbeiter der Unternehmung kommen können, bietet es sich an, dies durch ein spezielles Symbol (z.B. eine Ellipse als Rollensymbol, verbunden mit dem Ereignis) zu kennzeichnen. Allerdings erhöhen Sie mit jedem Symbol die Komplexität der Grafik. (Im Buch haben wir diesen Fall auch speziell im Geschäftsvorfall 3 – Kunde meldet Störung – berücksichtigt). Wir sind ein Softwarehaus, für uns ist der Teil „Betrieb“ zu intensiv und der Bereich „Entwicklung“ nicht ausführlich genug abgebildet! Was schlagen Sie vor? Unser Bestreben ist es, Ihnen eine Vorlage zu liefern, die zum einen ein methodisches Muster ist und zum andern bekannte Prozesskonzepte abbildet. In Ihrem Fall spricht nichts dagegen, einerseits den Betriebsteil zu reduzieren und den Entwicklungsbereich gemäß Ihren Standardprozessen bzw. Verfahren auszubauen. Wo sehen Sie die meisten Probleme bei der Realisierung und Umsetzung eines Prozess-Referenzmodells bzw. dann auch später bei der Realisierung von Prozessen, und welche Lösungsvorschläge haben Sie? Am schwierigsten ist die Einigung auf gemeinsame Begriffsdefinitionen. Oft werden die gleichen Begriffe mehrfach mit unterschiedlicher Bedeutung verwendet. Dies geht soweit, dass diese im Unternehmen in allen möglichen wichtigen Dokumenten (z.B. Verträgen und Systemen) regelrecht zementiert sind. Am Anfang steht somit oft der Aufbau so genannter Fachbegriffsmodelle, die sicherstellen, dass die Definition der Fachbegriffe und ihrer Zusammenhänge systematisiert wird. Wo immer möglich werden

350

Anhang

standardisierte Fachbegriffe als neutrale Definitionsgrundlage verwendet. Das Glossar von ITIL ist hierbei z.B. eine sehr geeignete Grundlage. Ich vermisse in Ihrem Modell die Rollenbeschreibungen, sind diese nicht dringend notwendig? Richtig: Rollen, und hier vor allem die Rollen innerhalb einer ICT-Unternehmung bzw. ICT-Organisation, sind nur rudimentär erwähnt. Wir haben auf die Beschreibung von Rollen aus folgenden Gründen verzichtet: 1. ITIL beinhaltet ein Rollenmodell bzw. diverse Rollenbeschreibungen, die auch auf unser Modell übertragbar sind. Mit anderen Worten: Die Rollenbeschreibungen wären sehr ähnlich geworden. 2. Unser Modell basiert auf einem theoretischen Unternehmen, eine Rollenbeschreibung würde nur dann zusätzliche Informationen liefern, wenn wir in den Rollen auch das Unternehmenskonzept berücksichtigen würden. 3. Bei der Entwicklung eines unternehmensspezifischen Modells werden auch die Rollen beschrieben. In der Praxis empfehlen wir, sich hierbei an den Rollenbeschreibungen von ITIL zu orientieren. Wir hätten aus unserer Sicht andere Schwerpunkte gesetzt als Sie. Welche Kriterien empfehlen Sie, um eigene Schwerpunkte zu setzen? Unser Modell ist ja quasi eine Art Meta-Modell, also eine Vorlage, die versucht, aufgrund eines hypothetischen Unternehmensmodells und den von diesem Unternehmen zu erbringenden Leistungen die Zusammenhänge der wichtigsten Prozesse der Unternehmung aufzuzeigen. Bei der Erstellung eines unternehmensspezifischen Modells steht zuerst die Definition der Art der Leistungen, die das Unternehmen erbringt, im Vordergrund. Dann müssen die Terminologie und die verwendeten Begriffe vereinheitlicht werden. Weiter ist festzulegen, welche Ziele mit dem Modell erreicht werden sollen. Danach richten sich die Schwerpunkte, die Sie setzen wollen, aus. Unsere empfohlenen Ziele sind: 1. Eindeutige Charakterisierung der Leistungsarten der Unternehmung (mit was verdient das Unternehmen Geld?). 2. Durchsetzung einer standardisierten und eindeutig definierten Begriffwelt; dieses schließt auch die internen Fachbegriffe mit ein. Es sollte also z.B. für den Begriff „Vertrag“ nur eine eindeutige Definition in Ihrem Unternehmen existieren.

FAQs

351

3. Klare Definition der Prozesse und zwar vor allem hinsichtlich ihrer Abgrenzung; d.h. welche Voraussetzungen müssen erfüllt sein, damit ein Prozess ausgelöst wird und welche, damit ein Prozess als abgeschlossen gilt? 4. Das Modell dient als Referenz für die operativen Abläufe, d.h. es wird nur das geregelt, was zwingend in den operativen Prozessen zu berücksichtigen ist.

352

Anhang

Literaturhinweise Die folgenden Literaturhinweise verstehen sich als Anregungen und verweisen primär auf eine Auswahl von Fachbüchern, die die in diesem Buch nur angerissenen Fachthemen vertiefend behandeln. ARIS-Modellierungs-Methoden, Metamodelle, Anwendungen Scheer, August-Wilhelm Springer Verlag, Berlin 2001 ISBN: 9783540416012 Balanced Scorecard Kaplan, Robert; Norton, David Schäffer-Pöschel Verlag, Stuttgart 1997 ISBN3791012037 Berufe der ICT Herausgeber SwissICT, 2004, vdf Hochschulverlag AG an der ETH Zürich, ISBN 3728128856 Beschwerdemanagement Seidel, Wolfgang; Strauss, Bernd Carl Hanser Verlag, München, Wien 1998 ISBN3446193464 Business Reengineering Berndt, Ralph Springer Verlag, Berlin 1999 ISBN: 9783540625469 Cobit Audit Guidelines Information Systems Audit & Control, 1998 ISBN: 9780962944062 Cobit Framework Information Systems Audit & Control, 1998 ISBN: 9780962944048 Controlling und Finance Excellence. Herausforderungen und BestPractice-Lösungsansätze Horvath, Peter Schäffer-Poeschel Verlag, 2006 ISBN: 9783791025643

Literaturhinweise

353

Controlling von Projekten Fiedler, Rudolf Vieweg und Sohn, Wiesbaden 2001 ISBN 3528057408 Das große Handbuch der Strategieinstrumente Gathen, Andreas von der; Simon, Hermann Campus Verlag GmbH, Frankfurt / Main 2002 ISBN 3593369931 Das große Handbuch der Strategiekonzepte Simon, Hermann Campus Verlag GmbH, Frankfurt / Main 2000 ISBN 3593364107 Die Kunst der Projektsteuerung Kupper, Hubert Oldenbourg Verlag, München, Wien 2001 ISBN 3486254081 Die Praxis des Knowledge Managements Heck, Andreas Vieweg Verlag, 2002 ISBN13: 9783528057640 Distributionsmanagement Fritz, Wolfgang; Günter, Specht Kohlhammer-Verlag, 2005 ISBN: 9783170184107 Financial Supply Chain Management Pfaff, Donovan; Skiera, Bernd; Weiss, Jürgen Galileo Press, 2003 ISBN: 9783898422499 IT-Betriebsabrechnung. Der BAB des Rechenzentrums (Broschiert) Michels, Jochen Vdm Verlag Dr. Müller, 2004 ISBN: 9783936755541

354

Anhang

IT-Service-Level-Management. Konzepte und Implementierungsstrategien Seidel, Christoph Vdm Verlag Dr. Müller, 2006 ISBN: 9783865508287 IT-Servicemanagment mit ITIL und MOF Sommer, Jochen Mitp-Verlag, 2004 ISBN: 9783826613807 Integrated IT Project Management: A Model-Centric Approach: A Model-Centric Approach Bainey, Kenneth Artech House, 2004 ISBN: 9781580538282 ITIL Service Delivery Office of Government Commerce Stationery Office Books, 2001 ISBN: 9780113308934 ITIL Service Support Central Computer & Telecommunications Agency Stationery Office, 2000 ISBN: 9780113300150 ITIL Version 3 Vorankündigung Office of Government Commerce Verfügbar voraussichtlich ab Ende zweites Quartal 2007 Servicemanagement mit System Luczak, Holger Springer Verlag, Berlin, Heidelberg 1999 ISBN 3540652825 Managing the Change: Software Configuration and Change Management Cuevas, Gonzales, Haug, Michael, Olsen, Eric Springer Verlag, Berlin 2001 ISBN: 9783540417859

Literaturhinweise

Measuring Itil: Measuring, Reporting and Modelling Steinberg, Randy Trafford Publishing, 2006 ISBN: 9781412093927 Product Lifecycle Management Grieves, Michael McGraw-Hill Professional (November 2005) ISBN: 9780071452304 Programm-Management: Projekte Übergreifend Koordinieren und Einbinden Dobiey, Dirk; Köplin, Thomas; Mach, Wolfram Wiley-VCH, 2004 ISBN: 9783527501212 Projektmanagement Gartner, Peggy; Wuttke, Thomas Rhombos-Verlag, Berlin 2000 ISBN 3930894300 Projektmanagement mit dem Rational Unified Process Versteegen, Gerhard Springer Verlag, Berlin, Heidelberg 2000 ISBN 3540667555 Prozesse in Produktion und Supply Chain optimieren Becker, Torsten Verlag: Springer Verlag, Berlin 2005 ISBN: 9783540258414 Prozessmanagement Gaitanides, Michael; Scholz, Rainer; Vrohlings, Alwin; Raster, Max Carl Hanser Verlag, München, Wien 1994 ISBN 3446177159 Prozessmanagement leichtgemacht Franz, Stefan; Scholz, Rainer Carl Hanser Verlag, München, Wien 1996 ISBN 344618093

355

356

Anhang

Qualitätsmanagement für Dienstleistungen. Grundlagen, Konzepte, Methoden Bruhn, Manfred Springer Verlag, Berlin 2006 ISBN: 9783540277460 Qualitätsmanagement von A bis Z Brauer, Jörg-Peter; Kamiske, Gerd Hanser Verlag Wirtschaft, 2005 ISBN: 9783446402843 Risikomanagement in Projekten Harrant, Horst; Hemmrich, Angela Hanser Verlag Wirtschaft, 2004 ISBN: 9783446225923 Risikomanagement im Kontext der wertorientierten Unternehmensführung Wolf, Klaus Deutscher Universitätsverlag, 2003 ISBN: 9783824479252 Sales Excellence Homburg, Christian; Schneider, Janna; Schäfer, Heiko Gabler Verlag, Wiesbaden 2001 ISBN 3409116974 Sales-Promotion-Controlling Zahner, Wolfgang Hampp / Mering, 2005 ISBN: 9783879889532 Service Engineering. Entwicklung und Gestaltung innovativer Dienstleistungen Bullinger, Hans-Jörg; Scheer, August-Wilhelm Springer Verlag, Berlin 2005 ISBN: 9783540253242 Strategisches Management professioneller Dienstleistungen am Beispiel der Unternehmensberatung Binnewies, Stefan Duehrkohp & Radicke, Erlangen 2002 ISBN 3897442116

Literaturhinweise

357

Supply Chain Management. Prozessoptimierung in der logistischen Kette Thaler, Klaus Fortis Verlag, 2003 ISBN: 9783933430533 Total Customer Care Reinecke, Sven; Sipötz, Elisabeth; Wiemann, Eva-Maria Wirtschaftsverlag Carl Ueberreuter, Wien 1998 ISBN 370640477X Vertriebskonzeption und Vertriebssteuerung. Die Instrumente des integrierten Kundenmanagements Winkelmann, Peter Vahlen, 2005 ISBN: 9783800632343 Wirtschaftsinformatik. Referenzmodelle für industrielle Geschäftsprozesse Scheer, August-Wilhelm Springer Verlag, Berlin 1997 ISBN: 9783540629672

358

Anhang

Glossar Abkürzungen ACD AE-Prognose CAB CI CIP CMBD CRM CTI DSL HW ICT ISO IT ITIL IVR KSF LAN M.I.S.S.O OLA PC P-Change P-Risiko QM Q-Audit Q-Ziele RFC RZ S-Vertrag SW SSW SLA SLM i.d.R. CRM

Automatic Call Distribution Auftragseingangs-Prognose Change Advisory Board Configuration Item Continues Improvement Process Configuration Management Database Customer Relationship Management Computer Telephony Integration Definitive Software Library Hardware Information and Communications Technology International Standards Organisation Information Technology IT Infrastructure Library Interactive Voice Response Key Success Factors Local Area Network Management, Infrastructure, Sales, Services & Operations Operation Level Agreement Personal Computer Projektchange Projektrisiko Quality Management Qualitäts-Audit Qualitätsziele Request for Change Rechenzentrum Supplier-Vertrag Software Standardsoftware Service Level Agreement Service Level Management in der Regel Customer Relationship Management

Glossar

359

Begriffe1 Akontozahlung

Aufgabenkette AvailabilityITIL2

Best practice Blackbox

Business Rules

CategoryITIL

1

Synonym verwendet für Anzahlung. Im FIBU-Umfeld auch als Zahlung, die keinem Geschäftsvorfall zugeordnet ist, definiert. Mehrere aufeinander folgende Aufgaben innerhalb eines Prozesses. Fähigkeit einer Komponente oder eines Service, eine geforderte Leistung zu einem festgesetzten Termin oder in einer ausgewiesenen Zeitspanne zu erfüllen. Meist ist sie als Verfügbarkeitsgrad definiert, zum Beispiel das Verhältnis von Verfügbarkeit zu vereinbarten Servicestunden. (Ability of a component or service to perform its required function at a stated instant or over a stated period of time. It is usually expressed as the availability ratio, i.e. the proportion of time that the service is actually available for use by the Customers within the agreed service hours.) Bezeichnet die für eine Aufgabenstellung beste realisierte Lösung. Allgemein ein Objekt, dessen innerer Aufbau und innere Funktionsweise unbekannt ist oder als nicht von Bedeutung erachtet wird. Das Blackbox-Prinzip wird als Hilfsmittel verwendet, wenn der innere Aufbau für die Aufgabenstellung irrelevant ist und primär die Schnittstellen eine Rolle spielen. Sammelbegriff, der in der Wirtschaftsinformatik zur Anwendung kommt. Umfasst Geschäftsregeln, die die Steuerung von Anwendungssoftware beeinflussen (z.B. Bestellungen werden nur auf elektronischem Wege (Internet) angenommen und müssen dem definierten Standardformat entsprechen). Klassifizierung einer Gruppe von Konfigurationseinheiten, Veränderungselementen oder Problemen. (Classification of a group of Configuration Items, Change documents or Problems.)

Soweit Begriffe von ITIL übernommen wurden, wurden diese aus den folgenden Quellen zitiert: Service Delivery (ITIL Managing IT Services), Office of Government Commerce, London: The Stationery Office Service Support (ITIL Managing IT Services), Office of Government Commerce, London: The Stationery Office.

2

ChangeITIL hierbei handelt es sich um eine ITIL-Definition.

360

Anhang

Change Advisory BoardITIL

Change ControlITIL

ChangeManagementITIL

ChangeITIL

ChargingITIL

ClassificationITIL

Eine Gruppe von Personen, die Expertisen zum Change Management geben, um Änderungen durchzuführen. Normalerweise besteht diese Gruppe aus Verantwortlichen der IT und anderer Abteilungen. (A group of people who can give expert advice to Change Management on the implementation of Changes. This board is likely to be made up of representatives from all areas within IT and representatives from business units.) Der Vorgang zur Sicherstellung der Kontrolle von Veränderungen, inklusive Vorschlag, Analyse, Entscheidung, Bestätigung, Implementierung und Abschluss. (The procedure to ensure that all Changes are controlled, including the submission, analysis, decision making, approval, implementation and post implementation of the change.) Prozess zur Kontrolle von Änderungen in der Infrastruktur oder bzgl. jeglicher Bestandteile eines Services in einer kontrollierten Umgebung. (Process of controlling Changes to the infrastructure or any aspect of services, in a controlled manner, enabling approved Changes within minimum disruption.) Das Hinzufügen, Modifizieren oder Entfernen von genehmigten, unterstützten oder standardisierten IT-Komponenten wie Hardware, Netzwerke, Software, Anwendungen, Systeme etc. und deren „Umwelt“ sowie der zugehörigen Dokumentation. (The addition, modification or removal of approved, supported or baselined hardware, network, software, application, environment, system, desktop build or associated documentation.) Prozess zur Erstellung von Rechnungen pro Geschäftseinheit und Ausgabe von Kundenrechnungen. (The process of establishing charges in respect of business units, and raising the relevant invoices for recovery from customers.) Prozess zur formalen Gruppierung von Konfigurationselementen gemäß definierten Typen wie zum Beispiel Software, Hardware, Dokumentation, Umwelt oder Anwendung. Prozess zur formalen Identifikation von Änderungen nach Typen wie zum Beispiel eine Anfrage zur Änderung vom Projektzielen, Gültigkeit der Änderungsanfrage oder Infrastruktur. Prozess zur formalen Identifizierung von Störungen, Problemen und bekannten Fehlern nach Herkunft, Symptom oder Ursache. (Process of formally grouping Configuration Items by type, e.g. software, hardware, documentation, environment, application.

Glossar

Client

Configuration BaselineITIL

Configuration ControlITIL

Configuration DocumentationITIL

Configuration identificationITIL