Ganzheitliches Integrationsmanagement in der Unternehmens-IT

Gernot Dern Integrationsmanagement in der Unternehmens-IT

VIEWEG+TEUBNER RESEARCH

Gernot Dern

Integrationsmanagement in der Unternehmens-IT Systemtheoretisch fundierte Empfehlungen zur Gestaltung von IT-Landschaft und IT-Organisation Mit einem Geleitwort von Prof. Dr. Reinhard Jung

VIEWEG+TEUBNER RESEARCH

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

Dissertation Universität Duisburg-Essen, 2010

1. Auflage 2011 Alle Rechte vorbehalten © Vieweg +Teubner Verlag | Springer Fachmedien Wiesbaden GmbH 2011 Lektorat: Ute Wrasmann | Britta Göhrisch-Radmacher Vieweg+Teubner Verlag ist eine Marke von Springer Fachmedien. Springer Fachmedien ist Teil der Fachverlagsgruppe Springer Science+Business Media. www.viewegteubner.de Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Umschlaggestaltung: KünkelLopka Medienentwicklung, Heidelberg Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier Printed in Germany ISBN 978-3-8348-1528-6

Geleitwort Veränderungen der Strategie, des Geschäftsmodells oder der Prozesse ziehen in der Regel Änderungsbedarf im Bereich der Informationstechnologie (IT) nach sich. Die IT-Landschaft größerer Unternehmen ist daher einem hohen Veränderungsdruck ausgesetzt, dem die IT-Verantwortlichen gegenwärtig bei sinkenden oder bestenfalls konstanten IT-Budgets gerecht werden müssen. Änderungen im IT-Bereich betreffen nicht einzelne, sondern in aller Regel mehrere IT-Systeme innerhalb von IT-Landschaften, die aus mehreren Hundert und mehr IT-Systemen bestehen. Derart große und komplexe IT-Landschaften sind das Ergebnis sich wandelnder Anforderungen über einen längeren Zeitraum, seien sie regulatorischer, wettbewerblicher oder technologischer Art. Eine IT-Landschaft der beschriebenen Größe lässt sich nur effektiv, d.h. im Sinne marktfähiger Wertschöpfungsprozesse, betreiben, wenn die IT-Systeme bedarfsgerecht miteinander verbunden (integriert) sind. Mit steigender Anzahl der IT-Systeme steigt die Komplexität der IT-Architektur, der damit verbundene Aufwand möglicherweise sogar überproportional. Die Konsequenz ist, dass immer größere Teile des IT-Budgets aufgezehrt werden und damit immer weniger Spielraum für die Umsetzung neuer Anforderungen aus den Fachbereichen bleibt. Letztlich können neue oder veränderte Wertschöpfungsprozesse dann nicht mehr effektiv unterstützt werden. Gernot Dern entwickelt in der vorliegenden Arbeit ein Konzept zum ganzheitlichen Integrationsmanagement. Das Konzept liefert umfassende Gestaltungsempfehlungen, ist in die Prozesslandschaft der Unternehmens-IT eingebettet und adressiert die zielgerichtete Steuerung der Komplexität der Unternehmensarchitektur. Das Konzept fußt dabei auf der gut begründeten Annahme, dass sich die Komplexität der IT-Landschaft nur bei gleichzeitiger Betrachtung der geschäftlichen Komplexität bewerten und adäquat verändern lässt. Die Ergebnisse der Dissertationsschrift von Gernot Dern bilden eine ausgezeichnete Basis, um durch komplexitätsbasiertes Integrationsmanagement die Handlungsfähigkeit der IT und damit der Unternehmen in einem von Wandel geprägten Umfeld zu gewährleisten. Ich wünsche der vorliegenden Arbeit eine große Verbreitung in Wissenschaft und Praxis. St. Gallen, im Februar 2011

Prof. Dr. Reinhard Jung

Vorwort Im Jahr 2002 führte Prof. Marty eine Studie zum IT-Kostenmanagement bei Banken durch. Marty kann zu dem Schluss, dass es in der IT zu einer Verschiebung der Leistungserbringung zuungunsten der Umsetzung fachlicher Anforderungen und zugunsten von solchen Leistungen kommt, die im Folgenden unter dem Begriff der Integrationsleistung subsumiert werden. Durch die Untersuchung von Marty sensibilisiert, betrachtete ich in der Folge das Management der Unternehmens-IT größerer Unternehmen zunehmend aus der Perspektive der von Marty aufgezeigten Problematik. So gewann ich die Überzeugung, dass die von Marty beschriebene Veränderung kennzeichnend für die Situation der Unternehmens-IT in vielen größeren Unternehmen ist. Infolgedessen schärfte sich mein Blick für die Thematik Integrationsmanagement. Dabei wurde mir bewusst, dass dem beschriebenen Trend nicht primär durch „bessere“ Integrationstechnologien zu begegnen ist, sondern durch die Gestaltung der UnternehmensIT im Sinne einer ganzheitlichen Managementaufgabe – wie auch Schelp und Winter im Vorwort des Bandes Integrationsmanagement1 hervorheben. In einer Untersuchung aus dem Jahr 2010 analysiert die GARTNER GROUP die zehn wichtigsten Problemfelder der IT aus Sicht der CEOs und Business Manager größerer Unternehmen.2 An erster Stelle steht Kompatibilität & Integration. GARTNER betont, dass Integration als Problemfeld gesehen wird, das nahezu alle Bereiche der IT durchdringt. An dritter Stelle findet sich IT-Komplexität. Das Problemfeld IT-Komplexität durchzieht aus Sicht von CEOs und Business Managern die gesamte IT und wird als Haupttreiber steigender IT-Kosten wahrgenommen. Dies ist der Hintergrund, vor dem die Idee eines Forschungsvorhabens zu sehen ist, die im Diskurs mit meinen Doktorvater Prof. Dr. Jung entstand und Integration im Sinne einer ganzheitlichen Perspektive in den Mittelpunkt stellt. Wie Jung im Vorwort seiner Habilitationsschrift bemerkt, ist Integration ein zentrales Forschungsgebiet der Wirtschaftsinformatik, sicherlich jedoch kein neues. Häufig werden bestimmte Probleme der Integration von IT-Systemen oder ganzer IT-Landschaften behandelt – zum Beispiel die Frage, wie Integrationsarchitekturen gestaltet werden können, um eine „bessere“ Integration zu ermöglichen. Die vorliegende Arbeit geht über diese Sicht auf Integration hinaus und stellt die Frage nach einem Konzept zum Integrationsmanagement in der Unternehmens-IT größerer Unternehmen, das Integration als ganzheitliche Ma1 2

Vgl. [ScheWin06]. Vgl. [Harris10].

VIII

Vorwort

nagementaufgabe versteht und dabei das Management der Komplexität der Unternehmens-IT einbezieht. Die in dem vorliegenden Band enthaltenen Modelle, Methoden und Gestaltungsempfehlungen stellen hierfür ein Instrumentarium zur Verfügung. Eine Forschungsarbeit wie die vorliegende ist immer das Ergebnis der Diskussion und des Meinungsaustauschs des Autors mit Wissenschaftlern und Praktikern. Von diesen bin ich einigen zu besonderem Dank verpflichtet. An erster Stelle steht mein Doktorvater Herr Prof. Jung, der stets für Rückfragen zur Verfügung stand und der durch seine Anregungen und Hinweise das Gelingen des Forschungsvorhabens ermöglicht hat. Durch den Austausch mit ihm war es mir möglich, innerhalb kurzer Zeit die Perspektive des Praktikers gegen die des Forschenden einzutauschen. Herzlicher Dank gebührt auch Prof. Dr. Eicker für das Korreferat und die Unterstützung beim Feinschliff der Arbeit. Hervorheben möchte ich Herrn Prof. Gadatsch. Der Austausch mit ihm war wesentlich für die Entscheidung, nach mehr als zwanzig Jahren IT-Praxis ein Forschungsvorhaben zur Unternehmens-IT größerer Unternehmen anzugehen. Großen Einfluss auf die vorliegende Arbeit hatten unzählige, fruchtbare Diskussionen mit meinen Kollegen Pär Öman und Ingemar Rask von der SEB AB, Stockholm. Sie haben in den Jahren unserer Zusammenarbeit mit ihrer Kompetenz und ihrem Urteilsvermögen wesentlich zur Weiterentwicklung meiner Vorstellungen zum Management der IT größerer Unternehmen beigetragen. Besonderer Dank gilt der SYRACOM AG. Diskussionen und Workshops mit den Mitarbeitern des Unternehmens und die dadurch mögliche Einbeziehung der Erfahrungen zahlreicher größerer Unternehmen lieferten Denkanstöße, die für die Entwicklung des vorliegenden Konzeptes essenziell waren. SYRACOM ist Mitbegründer des EAM Think Tank, in dem ich seit 2008 die Möglichkeit zum intensiven Austausch mit zahlreichen Vertretern aus Praxis und Forschung hatte. Wesentlich für die Entwicklung und die Verbesserung des Konzeptes waren die Diskussionen mit Klaus Grieger von der CIMT AG. Auf ihn geht das Modell des komplexitätsorientierten Lebenszyklus von IT-Systemen zurück. Hervorheben möchte ich die Unterstützung durch meine Kollegen Dr. Miriam Lux und Jörg Sadlowski von der SEB AG. Sie haben durch ihr fundiertes Feedback dazu beigetragen, die im Forschungsprozess erzielten Erkenntnisse und Ergebnisse zu präzisieren. Eine breit angelegte, umfassende und gleichzeitig detaillierte Fallstudie ist nur möglich, wenn ein Unternehmen bereit ist, umfangreiche Informationen über Strategien und Projekte in den Forschungsprozess einzubringen. Hier bin ich der SEB GRUPPE zu besonderem Dank verpflichtet. Idstein, im Januar 2011

Gernot Dern

Inhaltsübersicht 1

Einleitung ................................................................................................... 1 1.1 1.2 1.3 1.4 1.5

2

Motivation ........................................................................................... 1 Problembeschreibung und Handlungsbedarf ...................................... 4 Forschungsdesign in der Wirtschaftsinformatik ................................. 8 Forschungsdesign der Arbeit ............................................................ 12 Gang der Untersuchung .................................................................... 16 Bezugsrahmen und Grundlagen ............................................................. 21

2.1 2.2 2.3 2.4

3

Die Unternehmens-IT als komplexes Teilsystem des Unternehmens ................................................................................... 22 Begriffsbestimmung Integrationsmanagement ................................. 40 Unternehmensarchitektur und Integrationsmanagement ................... 59 Zusammenfassung - Gestaltungsprinzipien des Integrationsmanagements ................................................................. 73 Entwicklung übergeordneter Gestaltungsempfehlungen ..................... 75

3.1 3.2 3.3 4

Klassifikation verwandter Arbeiten .................................................. 76 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten ............................................................................................ 79 Zusammenfassung........................................................................... 144 Verfeinerung der übergeordneten Gestaltungsempfehlungen ........... 147

4.1 4.2 4.3 4.4 4.5 4.6 4.7

Festlegung des Verfeinerungsbedarfs ............................................. 148 Definition eines Referenzmodells zur IT-Prozesslandschaft .......... 154 Integrationsmanagement in der strategischen Konzeption der Unternehmens-IT ............................................................................ 169 Entwurf eines Kennzahlensystems zum Integrationsmanagement.. 180 Integrationsmanagement in Managementprozessen und operativen IT-Prozessen.................................................................. 197 Ergänzende Leitlinien zur Organisation der IT-Landschaft ............ 209 Management ganzheitlicher Integrationslösungen in der IT-Prozesslandschaft ....................................................................... 243

X

Inhaltsübersicht

4.8 4.9 5

Leitlinien zur Steigerung der Integrationseffizienz der Unternehmens-IT ............................................................................ 247 Zusammenfassung........................................................................... 249 Evaluierung des Konzeptes zum Integrationsmanagement ............... 251

5.1 5.2 5.3 5.4 6

Festlegung des Evaluierungsansatzes ............................................. 251 Evaluierungsmethode ...................................................................... 252 Fallstudie SEB GRUPPE ................................................................ 254 Zusammenfassung der Evaluierung ................................................ 320 Schlussbetrachtung und Ausblick ........................................................ 323

6.1 6.2 6.3 6.4

Ergebniszusammenfassung ............................................................. 323 Kritische Würdigung ....................................................................... 325 Ansatzpunkte für weitere Forschungsaktivitäten ............................ 328 Ausblick .......................................................................................... 330

Literaturverzeichnis………………………………………………………… 331

Inhaltsverzeichnis 1

Einleitung ................................................................................................... 1 1.1 Motivation ........................................................................................... 1 1.2 Problembeschreibung und Handlungsbedarf ...................................... 4 1.2.1 Problembeschreibung .................................................................... 4 1.2.2 Handlungsbedarf ........................................................................... 7 1.3 Forschungsdesign in der Wirtschaftsinformatik ................................. 8 1.4 Forschungsdesign der Arbeit ............................................................ 12 1.5 Gang der Untersuchung .................................................................... 16 1.5.1 Vorgehensmodell ......................................................................... 16 1.5.2 Kapitelübersicht .......................................................................... 17

2

Bezugsrahmen und Grundlagen ............................................................. 21 2.1

Die Unternehmens-IT als komplexes Teilsystem des Unternehmens ................................................................................... 22 2.1.1 Systemtheoretische Begriffsdefinition der IT-Landschaft ........... 22 2.1.2 Vervollständigung der Begriffswelt zur Unternehmens-IT ......... 33 2.1.3 Reflexion der Begriffswelt zur Unternehmens-IT ....................... 39 2.2 Begriffsbestimmung Integrationsmanagement ................................. 40 2.2.1 Zum Spektrum des ganzheitlichen Integrationsmanagements .... 41 2.2.2 Integrationsmanagement als Teildisziplin des IT-Managements . 44 2.2.3 Aufstellung eines Grundmodells zum Integrationsmanagement . 51 2.2.3.1 Änderung von Informationsbedarfen .................................... 52 2.2.3.2 Effizienzanforderungen ......................................................... 54 2.2.3.3 Ableitung des Grundmodells zum Integrationsmanagement 56 2.2.3.4 Informationsbeziehungen und Integrationsleistungen in der IT-Landschaft........................................................................ 57 2.3 Unternehmensarchitektur und Integrationsmanagement ................... 59 2.3.1 Unternehmensarchitektur und strategische Konzeption .............. 59 2.3.2 Begriffsklärung Unternehmensarchitektur .................................. 64 2.3.3 Integrationsmanagement und Unternehmensarchitektur ............. 70 2.3.4 Erweiterung des Grundmodells zum Integrationsmanagement ... 72 2.4 Zusammenfassung - Gestaltungsprinzipien des Integrationsmanagements ................................................................. 73

XII 3

Inhaltsverzeichnis

Entwicklung übergeordneter Gestaltungsempfehlungen ..................... 75 3.1 Klassifikation verwandter Arbeiten .................................................. 76 3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten 79 3.2.1 Integrationsmanagement und Komplexitätsmanagement in der Unternehmens-IT ........................................................................ 79 3.2.1.1 Analyse und Abbildung auf das Modell zum Integrationsmanagement ....................................................... 80 3.2.1.2 Komplexität und Integrationsmanagement ........................... 85 3.2.1.3 Komplexitätsfalle – statisches und dynamisches Potenzial... 86 3.2.1.4 Ansätze zur Komplexitätsreduktion bzw. zur Begrenzung der Komplexitätssteigerung .................................................. 89 3.2.1.5 Zusammenfassung und Gestaltungsempfehlungen ............... 96 3.2.2 Ganzheitliche Lösungen zur Anwendungsintegration in der IT-Landschaft ............................................................................ 100 3.2.2.1 Integrationslösungen in der IT-Landschaft und das Business Engineering Framework....................................... 100 3.2.2.2 Abbildung auf das Modell zum Integrationsmanagement der Arbeit ............................................................................ 105 3.2.2.3 Ganzheitliche Integrationslösungen .................................... 106 3.2.2.4 Zur Gestaltung eines Portfolios von Integrationslösungen . 108 3.2.2.5 Leistungsfähigkeit der Unternehmens-IT bei der Erbringung von Integrationsleistungen ............................... 110 3.2.2.6 Zusammenfassung und Gestaltungsempfehlungen ............. 111 3.2.3 Integration der Unternehmens-IT in adaptive Unternehmensarchitekturen ...................................................... 113 3.2.3.1 Das adaptive Sense-Response-Unternehmen ...................... 114 3.2.3.2 Das S-R-Unternehmen und Integrationslösungen ............... 117 3.2.3.3 Fraktale Strukturen und die ACE-Architektur .................... 119 3.2.3.4 Integration der Unternehmens-IT in den adaptiven Reaktionsprozess................................................................. 122 3.2.3.5 Abbildung auf das Grundmodell zum Integrationsmanagement ..................................................... 123 3.2.3.6 Das RED-Transaktionsportal .............................................. 124 3.2.3.6.1 Charakterisierung des RED-Transaktionsportals....... 124 3.2.3.6.2 Architekturentwurf für ein RED-Transaktionsportal . 125 3.2.3.7 Zur Transformation der Unternehmens-IT auf Basis der ACE-Architektur ................................................................. 126 3.2.3.8 Zusammenfassung und Gestaltungsempfehlungen ............. 127 3.2.4 Unternehmensintegration in verteilten Organisationen ............. 128

Inhaltsverzeichnis

XIII

3.2.4.1 Abbildung auf das Grundmodell zum Integrationsmanagement ..................................................... 129 3.2.4.2 IGF und die Zielsetzung einer global integrierten ITLandschaft ........................................................................... 130 3.2.4.3 Projektvorgehen .................................................................. 132 3.2.4.4 Ableitung von Erfolgsfaktoren............................................ 134 3.2.4.5 Zusammenfassung und Gestaltungsempfehlungen ............. 134 3.2.5 Muster für die IT-Konsolidierung bei Fusionen und Übernahmen .............................................................................. 137 3.2.5.1 Abbildung auf das Grundmodell zum Integrationsmanagement ..................................................... 138 3.2.5.2 Handlungsmuster erfolgreicher Geschäftsintegration ......... 139 3.2.5.3 Handlungsmuster für die IT-Konsolidierung ...................... 140 3.2.5.3.1 Nutzenbetrachtung der IT-Konsolidierung umfasst Wertzuwachs auf Geschäftsebene ............................. 140 3.2.5.3.2 Schnelle Konsolidierung der IT-Landschaften vor Perfektion .................................................................. 141 3.2.5.3.3 Sicherstellung der IT-Unterstützung des laufende Geschäftes ................................................................. 143 3.2.5.4 Zusammenfassung und Gestaltungsempfehlungen ............. 143 3.2.5.5 IT-Konsolidierung und Aufbau einer integrierten Informationswirtschaft ........................................................ 144 3.3 Zusammenfassung........................................................................... 144 4

Verfeinerung der übergeordneten Gestaltungsempfehlungen ........... 147 4.1 Festlegung des Verfeinerungsbedarfs ............................................. 148 4.1.1 Integrationsmanagement in der strategischen Konzeption der Unternehmens-IT ...................................................................... 149 4.1.2 Komplexitätsmanagement der Unternehmens-IT...................... 149 4.1.3 Ganzheitliche Integrationslösungen .......................................... 151 4.1.4 Leistungsfähigkeit der Unternehmens-IT in Bezug auf Integrationsleistungen ............................................................... 151 4.1.5 Zusammenfassung – Aufgabenstellung der weiteren Ausarbeitung ............................................................................. 152 4.2 Definition eines Referenzmodells zur IT-Prozesslandschaft .......... 154 4.2.1 Definition IT-Prozesslandschaft ................................................ 154 4.2.2 Abgrenzung zu COBIT, ITIL und ASL ..................................... 155 4.2.2.1 COBIT – Control Objectives for Information and related Technology ......................................................................... 156

XIV

Inhaltsverzeichnis

4.2.2.2 ITIL - IT Infrastructure Library .......................................... 157 4.2.2.3 ASL - Application Services Library ................................... 158 4.2.2.3.1 Analyse des ASL-Referenzmodells ........................... 158 4.2.2.3.2 Bewertung des ASL-Referenzmodells....................... 162 4.2.3 IT-Unternehmensarchitektur und IT-Prozesslandschaft ............ 163 4.2.4 Synthese des Referenzmodells zur IT-Prozesslandschaft .......... 168 4.3 Integrationsmanagement in der strategischen Konzeption der Unternehmens-IT ............................................................................ 169 4.3.1 Definition eines Modells zur strategischen IT-Planung............. 170 4.3.2 Aufstellung eines Modells zur IT-Strategiedefinition ............... 171 4.3.3 IT-Strategiedefinition und IT-Integrationsstrategie ................... 173 4.3.4 Integrationsmanagement in der strategischen IT-Planung ......... 175 4.3.5 Zusammenfassung ..................................................................... 179 4.4 Entwurf eines Kennzahlensystems zum Integrationsmanagement.. 180 4.4.1 Komplexität der IT-Landschaft ................................................. 180 4.4.1.1 Perspektiven der Komplexitätsbetrachtung ......................... 181 4.4.1.2 Autonome Komplexität der IT-Landschaft ......................... 185 4.4.1.2.1 Komplexität der Gesamtheit der IT-Systeme............. 185 4.4.1.2.2 Komplexität der IT-Systeme ...................................... 187 4.4.1.2.3 Komplexität der IT-Basisinfrastruktur ....................... 191 4.4.1.3 Wahrgenommene geschäftliche Komplexität ..................... 192 4.4.1.4 Zusammenfassung............................................................... 193 4.4.2 Integrationseffizienz der IT-Organisation.................................. 195 4.4.3 Aufwandsverteilung – der Aufwandsquotient zu Integrationsleistungen ............................................................... 196 4.5 Integrationsmanagement in Managementprozessen und operativen IT-Prozessen.................................................................. 197 4.5.1 IT-Portfoliomanagement und Integrationsmanagement ............ 198 4.5.2 IT-Projektdurchführung und Integrationsmanagement.............. 202 4.5.3 Zusammenfassung ..................................................................... 207 4.6 Ergänzende Leitlinien zur Organisation der IT-Landschaft ............ 209 4.6.1 Reflexion des Kennzahlensystems zur Komplexität der IT-Landschaft ............................................................................ 210 4.6.1.1 Betrachtungen zu adaptiven Geschäftsarchitekturen .......... 210 4.6.1.2 Subjektivität von Komplexität und Möglichkeiten der Komplexitätsreduktion ........................................................ 212 4.6.1.3 Unternehmensübergreifender Vergleich von Komplexität . 216 4.6.1.4 Grenzen des vorliegenden Komplexitätsmodells ................ 216 4.6.2 Lebenszyklusmanagement in der IT-Landschaft ....................... 220 4.6.2.1 Lebenszyklus und Komplexität von IT-Systemen .............. 220

Inhaltsverzeichnis

XV

4.6.2.2 Entwicklung von IT-Systemen als Theoriebildung ............. 223 Adaptierbarkeit, Flexibilität, Agilität und proaktive Gestaltung von IT-Landschaften ................................................................. 227 4.6.3.1 Begriffliche Abgrenzung..................................................... 229 4.6.3.2 Klassifikation von IT-Systemen nach Adaptierbarkeit, Flexibilität und Agilität ....................................................... 231 4.6.3.3 Angemessenheit von Adaptierbarkeit, Flexibilität und Agilität ................................................................................ 234 4.6.3.4 Proaktive Gestaltung der IT-Landschaft bezüglich zukünftiger M&A-Situationen ............................................ 235 4.7 Management ganzheitlicher Integrationslösungen in der IT-Prozesslandschaft ....................................................................... 243 4.7.1 Abbildung auf das Referenzmodell ........................................... 243 4.7.2 Reflexion der Gestaltungsempfehlung 2.3 ................................ 245 4.8 Leitlinien zur Steigerung der Integrationseffizienz der Unternehmens-IT ............................................................................ 247 4.9 Zusammenfassung........................................................................... 249 4.6.3

5

Evaluierung des Konzeptes zum Integrationsmanagement ............... 251 5.1 Festlegung des Evaluierungsansatzes ............................................. 251 5.2 Evaluierungsmethode ...................................................................... 252 5.3 Fallstudie SEB GRUPPE ................................................................ 254 5.3.1 Unternehmensprofil................................................................... 254 5.3.2 Problemstellung Unternehmens-IT der SEB GRUPPE ............. 256 5.3.2.1 Ausgangssituation und Herausforderungen ........................ 256 5.3.2.2 Ausgewählte IT-Projekte .................................................... 259 5.3.2.2.1 Das IT-Projekt Risk Information Management ......... 260 5.3.2.2.2 IT-Programm PROG_GF der SEB GRUPPE ............ 263 5.3.2.2.3 IT-Programm zur DWH-Konsolidierung der SEB AG..................................................................... 264 5.3.3 Analyse und Bewertung ............................................................ 266 5.3.3.1 Analyse der Vorgehensweisen und Ergebnisse ................... 266 5.3.3.1.1 Komplexitätsmanagement bei der SEB AG .............. 266 5.3.3.1.2 IS-Portfoliomanagement bei der SEB AG ................. 268 5.3.3.1.3 Das IT-Programm zur DWH-Konsolidierung............ 270 5.3.3.1.4 Das IT-Projekt Risk Information Management (RIM) ........................................................................ 277 5.3.3.2 Bewertung der Vorgehensweisen und Ergebnisse .............. 282 5.3.3.2.1 Die SEB GRUPPE als komplexes System ................ 283

XVI

Inhaltsverzeichnis

5.3.3.2.2 Bewertung Komplexitätsmanagement in der SEB GRUPPE ........................................................... 284 5.3.3.2.3 Bewertung des Programms PROG_GF und des Konzern-BIW der SEB GRUPPE ............................. 289 5.3.3.2.4 Bewertung des IT-Programms DWH-Konsolidierung ............................................... 299 5.3.3.2.5 Bewertung des IT-Projektes RIM .............................. 303 5.3.3.3 Zusammenfassung in Bezug auf die Evaluierung ............... 304 5.3.4 Kennzahlengetriebene Optimierung in der Unternehmens-IT der SEB AG ............................................................................... 304 5.3.4.1 Anpassung der strategischen Konzeption der Unternehmens-IT ................................................................ 305 5.3.4.1.1 Anpassung der IT-Strategie der SEB GRUPPE ......... 306 5.3.4.1.2 Anpassung der strategischen IT-Planung der SEB AG..................................................................... 307 5.3.4.2 Anpassung des IT-Portfoliomanagements .......................... 313 5.3.4.2.1 Verankerung des Kennzahlensystems in der Prozesslandschaft ...................................................... 313 5.3.4.2.2 Erweiterung des Modells zum Lebenszyklus von IT-Systemen .............................................................. 314 5.3.4.3 IT-Portfoliomanagement und Optimierung der IT-Projektdurchführung ...................................................... 320 5.3.4.4 Zusammenfassung............................................................... 320 5.4 Zusammenfassung der Evaluierung ................................................ 320 6

Schlussbetrachtung und Ausblick ........................................................ 323 6.1 6.2 6.3 6.4

Ergebniszusammenfassung ............................................................. 323 Kritische Würdigung ....................................................................... 325 Ansatzpunkte für weitere Forschungsaktivitäten ............................ 328 Ausblick .......................................................................................... 330

Literaturverzeichnis………………………………………………………… 331

Abbildungsverzeichnis Abbildung 1: Abbildung 2: Abbildung 3: Abbildung 4: Abbildung 5: Abbildung 6: Abbildung 7: Abbildung 8: Abbildung 9: Abbildung 10: Abbildung 11: Abbildung 12: Abbildung 13: Abbildung 14: Abbildung 15: Abbildung 16: Abbildung 17: Abbildung 18: Abbildung 19: Abbildung 20: Abbildung 21: Abbildung 22: Abbildung 23: Abbildung 24: Abbildung 25: Abbildung 26: Abbildung 27: Abbildung 28: Abbildung 29:

Trend in der Verteilung von IT-Aufwänden und Zielsetzung eines Integrationsmanagements ................................................ 4 Wirtschaftsinformatik und Positionierung der Arbeit............... 9 Dimensionen des Forschungsdesigns in der Wirtschaftsinformatik ............................................................... 9 Grundpositionen des nach Erkenntnis strebenden Individuums ............................................................................ 10 Klassifizierung von Forschungszielen .................................... 11 Grundlegende Forschungsposition der Arbeit ........................ 12 Forschungsdesign der Arbeit .................................................. 15 Vorgehensmodell des Forschungsvorhabens .......................... 16 Kapitel 1 und Vorgehensmodell der Arbeit ............................ 17 Kapitel 2 und Vorgehensmodell der Arbeit ............................ 18 Kapitel 3/4 und Vorgehensmodell der Arbeit ......................... 19 Zusammenhang Kapitel 5 und Gesamtmethodik der Arbeit ... 19 Kapitel 6 und Vorgehensmodell der Arbeit ............................ 20 Entwicklung von Gestaltungsempfehlungen .......................... 22 System in der Systemtheorie .................................................. 24 Interaktion mit der Unternehmensumwelt und Transformation – das Unternehmen als System ..................... 25 Das Unternehmen als offenes, komplexes System ................. 25 Kommunikationssystem als Aufgabenträger .......................... 26 Anwendung als Aufgabenträger ............................................. 26 Begriffsabgrenzung IT-System und Fokussierung der Arbeit 28 IT-Systeme als Aufgabenträger im Unternehmen .................. 29 Die IT-Landschaft als komplexes Teilsystem im Unternehmen .......................................................................... 31 Elemente des komplexen Systems IT-Landschaft .................. 32 IT-Landschaft und IT-Organisation als Teilsysteme der Unternehmens-IT .................................................................... 36 Informationsflüsse im Rollennetzwerk bei Anlageprozessen . 38 Integrationsreichweite aus Sicht eines Unternehmens U1 ...... 43 Balancedreieck zum informationswirtschaftlichen Gleichgewicht ......................................................................... 48 IT-Management im Gesamtunternehmen ............................... 49 Integrationsmanagement als Teildisziplin des IT-Managements..................................................................... 50

XVIII Abbildung 30: Abbildung 31: Abbildung 32: Abbildung 33: Abbildung 34 Abbildung 35: Abbildung 36: Abbildung 37: Abbildung 38: Abbildung 39: Abbildung 40: Abbildung 41: Abbildung 42:

Abbildung 43: Abbildung 44: Abbildung 45: Abbildung 46: Abbildung 47: Abbildung 48:

Abbildung 49:

Abbildungsverzeichnis

Extern und intern initiierte Informationsbedarfe und Bearbeitung durch die Unternehmens-IT ............................... 51 Integrationsanforderungen und -leistungen als Folge intern oder extern initiierter Informationsbedarfe ............................. 54 Integrationsanforderungen und -leistungen als Folge von Effizienzzielen ........................................................................ 55 Grundmodell zum Integrationsmanagement ........................... 57 Interaktionsbeziehungen in der IT-Landschaft Informationsbeziehung ........................................................... 58 Implementierung eines Informationsflusses – Integrationsleistungen in der IT-Landschaft ........................... 59 Der EWIM-Ansatz zum IT-Management i. S. eines unternehmensweiten Informationsmanagements .................... 61 IT-Management und IT-Unternehmensarchitektur im transformierten EWIM-Ansatz ............................................... 62 Unternehmensarchitektur im Zyklus der strategischen Konzeption ............................................................................. 64 Leitplankenfunktion der Unternehmensarchitektur bei der Weiterentwicklung des Unternehmens ................................... 68 Leitplankenfunktion der Geschäftsarchitektur bei der Weiterentwicklung der Anwenderorganisation ...................... 69 Leitplankenfunktion der IT-Unternehmensarchitektur beim Transformationsprozess der Unternehmens-IT....................... 69 Integrationsleistungen als Teil der Anpassungsleistung der Unternehmens-IT innerhalb der Leitplanken der ITUnternehmensarchitektur........................................................ 71 Erweitertes Grundmodell zum Integrationsmanagement ........ 73 Kapitel 3 und die Entwicklung des Systems von Gestaltungsempfehlungen ...................................................... 75 Arbeiten aus Gruppe 1 - Projektion auf das Grundmodell zum ganzheitlichen Integrationsmanagement ......................... 78 Interaktion von IT-Dienstleister und Nachfrager i. S. v. BÖHMANN UND KRCMAR ........................................................ 81 Abgrenzung der Begriffswelt von BÖHMANN UND KRCMAR .. 83 Projektion der Arbeit von BÖHMANN UND KRCMAR auf das Modell zum Integrationsmanagement der vorliegenden Arbeit ...................................................................................... 84 Komplexitätsbezogene Korrelationen im Kontext von IT-Organisation und IT-Landschaft in Anlehnung an BLISS .. 91

Abbildungsverzeichnis

Abbildung 50: Abbildung 51: Abbildung 52: Abbildung 53: Abbildung 54: Abbildung 55: Abbildung 56: Abbildung 57: Abbildung 58: Abbildung 59: Abbildung 60: Abbildung 61: Abbildung 62: Abbildung 63: Abbildung 64: Abbildung 65: Abbildung 66: Abbildung 67: Abbildung 68: Abbildung 69: Abbildung 70:

XIX

Verschiebung des integrationsbezogenen Entkopplungspunktes.............................................................. 93 Grundkonzeption des Business Engineering Framework ..... 102 Kritik der Technologiefokussierung von Lösungen zur Anwendungsintegration nach SCHELP UND SCHWINN .......... 103 Integrationsbeziehungen zwischen IT-Systemen nach SCHELP UND SCHWINN .......................................................... 104 Erweiterung des Business Engineering Framework zur Verzahnung von Prozessebene und IS-Ebene....................... 105 Projektion des Aufsatzes von SCHELP UND SCHWINN auf das Modell zum Integrationsmanagement ............................ 106 Modell zur Entwicklung ganzheitlicher Integrationslösungen ............................................................. 107 Eine Methode zum Management eines Portfolios ganzheitlicher Integrationslösungen ..................................... 109 Entwicklung von Integrationslösungen als eigenständige Disziplin der Weiterentwicklung der Unternehmens-IT ....... 112 Struktur eindimensionaler Prozessmodellierung .................. 114 Adaptiver Reaktionsprozess des S-R-Unternehmens in seinem Ökosystem in Anlehnung an RAMANATHAN ............ 117 Die ACE-Architektur - fraktale Organisation des S-RUnternehmens ....................................................................... 120 Bearbeitung eines Request-Objektes im Rahmen des adaptiven Reaktionsprozesses .............................................. 121 Bearbeitung einer Variation im adaptiven Reaktionsprozess .................................................................. 122 Projektion der Arbeit von RAMANATHAN auf das erweiterte Grundmodell zum Integrationsmanagement ......................... 124 Architektur des RED-Transaktionsportals ............................ 126 Projektion von SHORE auf das Grundmodell zum Integrationsmanagement ....................................................... 130 Gefährdung der Lebensfähigkeit von IGF durch Autonomie der Teilsysteme .................................................. 132 Ansatz zum Aufbau einer integrierten IT-Landschaft in global verteilten Unternehmen ............................................. 136 Projektion der Arbeit von HEAP, ISRAELIT UND SHPILBERG auf das Grundmodell zum Integrationsmanagement ............ 139 Portfoliomodell zur Auswahl von IT-Projekten während der IT-Konsolidierung .......................................................... 142

XX Abbildung 71: Abbildung 72: Abbildung 73: Abbildung 74: Abbildung 75: Abbildung 76: Abbildung 77: Abbildung 78: Abbildung 79:

Abbildung 80: Abbildung 81: Abbildung 82: Abbildung 83: Abbildung 84: Abbildung 85: Abbildung 86: Abbildung 87: Abbildung 88: Abbildung 89: Abbildung 90: Abbildung 91: Abbildung 92: Abbildung 93:

Abbildungsverzeichnis

Gestaltungsempfehlungen zum Integrationsmanagement nach Abschluss der Analyse verwandter Arbeiten ............... 145 Kapitel 4 und die Entwicklung des Systems von Gestaltungsempfehlungen .................................................... 147 Konzept zum Integrationsmanagement – übergeordnete Gestaltungsempfehlungen .................................................... 148 Vorgehen bei der Entwicklung weiterführender Gestaltungsempfehlungen .................................................... 153 Die IT-Prozessarchitektur im erweiterten Grundmodell zum Integrationsmanagement ............................................... 155 Grundstruktur der IT-Prozesslandschaft nach ASL .............. 159 Prozessgruppen in der IT-Prozesslandschaft nach ASL ...... 160 Positionierung von ACM und OCM im systemtheoretischen Modell der Unternehmens-IT ......................... 161 Architekturpyramide – Grundmodell zur Unternehmensarchitektur - in Anlehnung an DERN UND KELLER ................................................................................. 164 Das IT-Portfolio in Anlehnung an DERN UND KELLER ......... 166 Erweiterte Architekturpyramide in Anlehnung an DERN UND KELLER ............................................................... 167 Erweiterte Architekturpyramide einschließlich Prozesszuordnung ................................................................. 167 Referenzmodell zur IT-Prozesslandschaft ............................ 169 Modell zur strategischen Konzeption der Unternehmens-IT 173 IT-Integrationsstrategie als Teil der IT-Strategie ................. 175 Integrationsmanagement und Herleitung von Handlungsfeldern der Unternehmens-IT .............................. 177 Kennzahlen zum Integrationsmanagement im strategischen IT-Plan .................................................................................. 178 Modell der Einbettung des Integrationsmanagements in die strategische Konzeption der Unternehmens-IT............... 179 Faktoren der Komplexität der IT-Landschaft ....................... 182 Gesamtkomplexität der IT-Landschaft und berücksichtigte Systemelemente .................................................................... 184 Komplexitätsdiagramm zweier IT-Systeme der COMMERZBANK zur Partnerdatenverwaltung .................. 188 Kompliziertheit in der IT-Landschaft und Komplexität der Unternehmens-IT .................................................................. 190 Stand der Entwicklung weiterführender Gestaltungsempfehlungen .................................................... 198

Abbildungsverzeichnis

Abbildung 94: Abbildung 95: Abbildung 96: Abbildung 97: Abbildung 98: Abbildung 99:

Abbildung 100: Abbildung 101:

Abbildung 102: Abbildung 103: Abbildung 104: Abbildung 105: Abbildung 106: Abbildung 107: Abbildung 108: Abbildung 109: Abbildung 110:

Abbildung 111: Abbildung 112: Abbildung 113: Abbildung 114: Abbildung 115: Abbildung 116: Abbildung 117:

XXI

IT-Portfoliomanagement und Integrationsmanagement in der IT-Prozesslandschaft .................................................. 200 Erweitertes Modell zum IT-Portfoliomanagement ............... 202 Allgemeines Modell zur IT-Projektdurchführung ................ 203 Erweitertes Modell der IT-Projektdurchführung .................. 205 Vorlage zur erweiterten Business-Case-Analyse .................. 207 Gesamtmodell zur Erweiterung der Prozesse der operativen Ebene zur Bestimmung der Integrationseffizienz im IT-Portfoliomanagement ................................. 208 Ergänzende Leitlinien zur Organisation der IT-Landschaft.. 209 Wahrgenommene Komplexität zwischen Geschäftsarchitekturansatz und Fertigkeiten der IT-Organisation .................................................................... 212 Schwerpunkte des Komplexitätsmanagements ..................... 215 Balancedreieck zur Komplexität der Unternehmens-IT ....... 216 Angemessene Komplexität der IT-Landschaft vs. Extrempositionen .................................................................. 220 Komplexität und Systemlebenszyklus .................................. 222 Modell zur Klassifizierung von IT-Systemen nach Flexibilität, Adaptierbarkeit und Agilität.............................. 232 Leitlinien zum Management der IT-Landschaft nach Adaptierbarkeit, Flexibilität und Agilität.............................. 233 Architekturmuster zur Unterstützung der Expansion bestehender Geschäftsfelder in neue Märkte ........................ 239 Zielpositionierung von Plattformen zur Unterstützung der Integration übernommener Unternehmen ............................. 240 Mögliche Positionierung von Plattformen zur Unterstützung der Integration von Unternehmensübernahmen ................................................... 241 Abbildung des Modells zum Management von Integrationslösungen auf die IT-Prozesslandschaft .............. 244 Zielpositionierung einer ganzheitlichen Integrationslösung . 246 Konzept zum Integrationsmanagement als System von Gestaltungsempfehlungen .................................................... 250 Methode zur Durchführung der Fallstudie............................ 253 Strategische Wettbewerbspositionierung der SEB GRUPPE 255 Divisionale Struktur SEB GRUPPE ..................................... 255 IT-Unternehmensarchitektur der SEB GRUPPE Zielsituation zur IT-Landschaft ............................................ 259

XXII

Abbildungsverzeichnis

Abbildung 118: Risikomanagement-Plattform der SEB GRUPPE und Positionierung des Projektes RIM ........................................ 261 Abbildung 119: Positionierung des Konzern-BIW der SEB GRUPPE .......... 262 Abbildung 120: Treiber des Projektes RIM .................................................... 263 Abbildung 121: Referenzmodell zur Geschäftsprozesslandschaft der SEB AG ................................................................................ 264 Abbildung 122: Übersicht zur Data-Warehouse-Landschaft der SEB AG ..... 265 Abbildung 123: Zielarchitektur DWH-Landschaft – mittel- bis langfristig angestrebte Informationsarchitektur ..................................... 271 Abbildung 124: Ist-Architektur DWH-Landschaft - Informationsarchitektur 273 Abbildung 125: Zielarchitektur DWH-Landschaft – angepasste ZielInformationsarchitektur ........................................................ 274 Abbildung 126: Zielarchitektur DWH-Landschaft - langfristige angestrebte Zielsituation .......................................................................... 274 Abbildung 127: Ist-Architektur DWH-Landschaft SEB AG – übergreifendes Kontextdiagramm......................................... 275 Abbildung 128: Ziel-Architektur DWH-Landschaft SEB AG – übergreifendes Soll-Kontextdiagramm ................................. 277 Abbildung 129: Zielarchitektur DWH-Landschaft – durch RIM angepasste Zielinformationsarchitektur .................................................. 280 Abbildung 130: Zielarchitektur DWH-Landschaft – verfeinertes Kontextdiagramm unter Berücksichtigung von RIMS ......... 281 Abbildung 131: Lösungsarchitektur für das Projekt RIM – Kontextdiagramm ................................................................. 282 Abbildung 132: Teilsystem Unternehmens-IT im komplexen System SEB... 283 Abbildung 133: Ist- vs. Ziel-IT-Landschaft für das Financial Reporting & Accounting der SEB GRUPPE ............................................. 290 Abbildung 134: Architektur der Basisversion der Gruppenplattform PLAT_GrF............................................................................ 292 Abbildung 135: Konzern-BIW als ganzheitliche Integrationslösung ............. 294 Abbildung 136: Angestrebte Positionierung von PLAT_GrF nach Adaptierbarkeit, Flexibilität und Agilität.............................. 296 Abbildung 137: Erwartete Positionierung von PLAT_GrF nach Adaptierbarkeit, Flexibilität und Agilität.............................. 297 Abbildung 138: Phasen im Komplexitätslebenszyklus von IT-Systemen ...... 297 Abbildung 139: Schwerpunkte der Verankerung des Integrationsmanagements in der Unternehmens-IT der SEB AG ................................................................................ 305 Abbildung 140: Modell zur Komplexität der Unternehmens-IT der SEB AG .......................................................................... 307

Abbildungsverzeichnis

XXIII

Abbildung 141: Reihenfolge der Einführung von Kennzahlen zur Komplexität der Unternehmens-IT bei der SEB AG ............ 308 Abbildung 142: Scorecard zum Kennzahlensystem Integrationsmanagement SEB AG – Stufe 1 ........................................... 310 Abbildung 143: Bestimmung der wahrgenommenen Komplexität auf Basis einer Divisions-Produkt-Matrix ............................................ 311 Abbildung 144: Gesamt-Scorecard zum Kennzahlensystem eines Integrationsmanagement bei der SEB AG ............................ 312 Abbildung 145: Einbettung Integrationsmanagement in die ITProzesslandschaft der SEB AG ............................................ 314 Abbildung 146: IT-Portfoliomanagement bei der SEB AG - erweiterte Scorecard zum Lebenszyklus von IT-Systemen ................... 316 Abbildung 147: Erweiterte Scorecard zu Data1 ............................................. 317 Abbildung 148: Erweiterte Scorecard zum BIW der SEB AG ....................... 318 Abbildung 149: Abdeckung des entwickelten Konzeptes zum Integrationsmanagement im Rahmen der vorgenommenen Evaluierung........................................................................... 321

Tabellenverzeichnis Tabelle 1: Tabelle 2: Tabelle 3:

Tabelle 4: Tabelle 5: Tabelle 6: Tabelle 7: Tabelle 8: Tabelle 9: Tabelle 10:

Klassifizierung von Forschungsmethoden der Wirtschaftsinformatik ............................................................. 11 Schema zur Komplexitätsreduktion in der Unternehmens-IT .................................................................... 92 Maßnahmenkatalog zur Komplexitätsreduktion der Unternehmens-IT unter Berücksichtigung der Potentialwirkung..................................................................... 96 Klassifikation der Prozessebenen von ASL .......................... 158 Status von IT-Systemen bei der SEB AG ............................. 269 Business Value von IT-Systemen bei der SEB AG .............. 269 Change Policy von IT-Systemen bei der SEB AG ............... 270 Klassifikation der Data-Warehouse-Systeme im IS-Portfoliomanagement der SEB AG .................................. 272 Scorecard des Systems Data1 ............................................... 317 Scorecard des BIW der SEB AG .......................................... 318

Formelverzeichnis Formel 1: Formel 2: Formel 3: Formel 4: Formel 5: Formel 6: Formel 7: Formel 8: Formel 9: Formel 10: Formel 11: Formel 12: Formel 13: Formel 14: Formel 15: Formel 16: Formel 17: Formel 18: Formel 19: Formel 20:

Allgemeine Formel zur Komplexität eines Systems angelehnt an SESSIONS ............................................................ 85 Integrationseffizienz der IT-Organisation basierend auf SCHWINN ............................................................................... 111 KUIT – Gesamtkomplexität der Unternehmens-IT ................. 181 Komplexität der Gesamtheit der IT-Systeme ........................ 186 Maximale Komplexität der Informationsbeziehungen nach DERN UND JUNG .................. 187 Vereinfachte Erfassung der Komplexität der Gesamtheit der IT-Systeme ...................................................................... 187 Mittlere Komplexität der IT-Systeme in der IT-Landschaft . 187 Mittlere Kompliziertheit der IT-Systeme in der IT-Landschaft........................................................................ 190 Komplexität der IT-Basisinfrastruktur .................................. 191 Kennzahlen zur wahrgenommenen geschäftlichen Komplexität .......................................................................... 192 Mehrdimensionale Kennzahl KITL zur Gesamtkomplexität der IT-Landschaft.................................................................. 193 KAITL - Absolute Komplexität der IT-Landschaft ................. 194 KAEITL - Absolute Komplexität der IT-Landschaft - vereinfacht .................................................. 194 KRITL – Relative Komplexität der IT-Landschaft .................. 195 Integrationseffizienz der IT-Organisation auf Basis der Komplexität von Integrationsanforderungen ........................ 196 Alternative Kennzahl zur Leistungsfähigkeit der IT-Organisation bzgl. Integrationsleistungen ........................ 196 Aufwandsquotient zu Integrationsleistungen der IT-Organisation ..................................................................... 197 Integrationseffizienz auf Basis der Bewertung von Informationsflüssen............................................................... 248 Kennzahl zur Gesamtkomplexität der IT-Landschaft der SEB AG ................................................................................ 310 Kennzahl geschäftlichen Komplexität der SEB AG ............. 312

Abkürzungsverzeichnis ACE ACM ACM AIR AKAEM ASL BIM BIR BPO CEO CF CIO COBIT CRM DBMS DE DF DO DV DWH EA EAI EAM EDA EFFZ EIS ERP ESB EVA EWIM FANF FORWIN GE GP

Adaptive Complex Architecture Application Cycle Management Association for Computing Machinery Application Integration Requirement Arbeitskreis Architektur- und Entwurfsmuster Application Services Library Business Information Management Business Integration Requirement Business Process Outsourcing Chief Executing Officer Cashflow Chief Information Offices Control Objectives for Information and related Technology Customer Relationship Management Database Management Systeme Datenelement Datenfluss Deliverable-Objekt Datenverarbeitung Data Warehouse Enterprise Architecture Enterprise Application Integration Enterprise Architecture Management Event-Driven Architecture Effizienzziel Enterprise Information System Enterprise Ressource Planning Enterprise Service Bus Economic Value Added Enterprise wide Information Management Fachliche Anforderung Bayerischer Forschungsverbund Wirtschaftinformatik Gestaltungsempfehlung Gestaltungsprinzip

XXX IANF IASB M&B IB IEEE IFRS IKT INTL IO IS ISACF IT ITIL IuKLANF M&A MaRisk MQ OCM Prince Promet BECS RIM RDE RO S&O SBP SOA SOX S-R STP TIR US-GAAP UK-GAAP WFM

Abkürzungsverzeichnis

Integrationsanforderung International Accounting Standards Board Inventur, Monitoring & Bewertung Informationsbedarf Institute of Electrical and Electronics Engineers International Financial Reporting Standards Informations- und Kommunikationstechnologie Integrationsleistung Informationselement IT-System Information Systems Audit and Control Foundation Informationstechnologie IT Infrastructure Library Informations- und KommunikationsLeistungsanforderung Merger and Acquistion Mindestanforderungen an ein Risikomanagement bei Banken Message Queueing Organization Cycle Management Projects in Controlled Environments Prozess Methode Business Engineering Case Studies Risk Information Management Requirement & Planning, Execution, Delivery Request-Objekt Steuerung & Optimierung Strategische Business Planung Service-Oriented Architecture Sarbanes-Oxley Act Sense and Response Straight-Through Processing Technical Integration Requirement United States Generally Accepted Accounting Principles United Kingdom Accepted Accounting Principles Workflow Management

1 Einleitung 1.1 Motivation Die Unternehmens-IT größerer Unternehmen ist in den letzten Jahren hohem Veränderungsdruck ausgesetzt, dem die Verantwortlichen in der Informationstechnologie (IT3) mit bestenfalls gleich bleibenden IT-Budgets gerecht werden müssen4. Dieser Veränderungsdruck ist im Wesentlichen auf drei treibende Kräfte zurückzuführen. Die erste besteht in der Zunahme regulatorischer Anforderungen und ist die Folge von Trends wie der Globalisierung. Dies bedeutet u. a.: ƒ

ƒ

Internationale Gesetzgebungsinitiativen ziehen nationale Implementierungen nach sich, die von international agierenden Unternehmen gleichzeitig bedient werden müssen (e. g. Standards und Prinzipien zur Rechnungslegung wie IFRS und Umsetzung in nationale Standards wie US-GAAP5). International agierende und hier im Besonderen öffentlich gelistete Unternehmen müssen ein umfangreiches, sich ständig weiterentwickelndes Spektrum von Melde- und Offenlegungspflichten durch die Lieferung von Berichten und Kennzahlen erfüllen. Zu nennen sind hier exemplarisch Vorschriften wie SOX6 zur Regelung des Unternehmens-Reportings; Basel II zu Eigenkapitalvorschriften für Banken und deren Umsetzung in nationales Recht, wie etwa in Gestalt der Solvabilitätsverordnung in Deutschland; MaRisk, die Mindestanforderungen an das Risikomanagement bei Banken in Deutschland; Solvency II zur Eigenmittelausstattung von Versicherungsunternehmen.

Die genannten regulatorischen Anforderungen verlangen die Zusammenführung, die Verdichtung und den Abgleich sehr großer Datenmengen aus allen 3

Im Folgenden wird für die IT größerer Unternehmen der Begriff Unternehmens-IT verwendet. In Kapitel 2 wird die genaue Definition vorgenommen. Nach einer Analyse der Gartner Group werden die IT-Budgets von Unternehmen von 2010 bis 2012 im Durchschnitt um 0 % wachsen, nachdem für 2009 eine Reduktion von 4,7 % erwartet wurde. Vgl. [McGee09]. 5 Die International Financial Reporting Standards (IFRS) sind internationale Rechnungslegungsvorschriften für Unternehmen und werden vom International Accounting Standards Board (IASB) herausgegeben. US-GAAP - United States Generally Accepted Accounting Principles - sind allgemein anerkannte Rechnungslegungsgrundsätze der Vereinigten Staaten, die die Buchführung sowie den Jahresabschluss der Unternehmen regeln. Analoge Regelungen gibt es für andere Staaten, etwa UK-GAAP. 6 Sarbanes-Oxley Act of 2002 (SOX). US-Bundesgesetz, das als Reaktion auf Bilanzskandale von Unternehmen wie Enron oder Worldcom die Verlässlichkeit der Berichterstattung von Unternehmen verbessern soll, die den öffentlichen Kapitalmarkt der USA in Anspruch nehmen. 4

G. Dern, Integrationsmanagement in der Unternehmens-IT, DOI 10.1007/978-3-8348-8154-0_1, © Vieweg+Teubner Verlag | Springer Fachmedien Wiesbaden GmbH 2011

2

1 Einleitung

Unternehmensteilen. Dies erzeugt den permanenten Druck, die IT-Landschaft so anzupassen, dass der geforderte Informationsbedarf befriedigt werden kann. Die zweite treibende Kraft der Veränderung der Unternehmens-IT ergibt sich aus der Wettbewerbssituation der Unternehmen. Die Deregulierung und die Globalisierung von Märkten führen zu steigender Wettbewerbsintensität7, die sich im Effizienzsteigerungsdruck, im Zwang zur Anpassung der Geschäftsarchitektur und in der Veränderung von Unternehmensstrukturen - z. B. als Folge von Übernahmen und Fusionen - manifestiert. So ergibt sich die Forderung an die Unternehmens-IT, Anpassungen der Geschäftsarchitektur und Effizienzsteigerungen mithilfe der Automatisierung von Prozessen, einer verbesserten Informationslogistik usw. zu ermöglichen. Die Wirkung dieses Veränderungsdrucks geht bis zur Restrukturierung, Integration oder Desintegration ganzer ITLandschaften. Zwei Szenarien verdeutlichen dies exemplarisch: ƒ

ƒ

Ein Versicherungskonzern betreibt die Abtrennung und den Verkauf der Industriehaftpflichtsparte. Deckt der übernehmende Konzern diese Sparte bisher nicht ab, so zieht die Übernahme das Herauslösen, d. h. die Desintegration, des industriehaftpflichtspezifischen Teils der IT-Landschaft aus dem Mutterkonzern und die Integration von Daten und IT-Systemen in die ITLandschaft des übernehmenden Unternehmens nach sich. Eine international aufgestellte Finanzdienstleistungsgruppe startet zur Steigerung der Effizienz der IT ein Programm zur Konsolidierung der ITLandschaften über alle Divisionen und Länder hinweg. Dies zieht die Konsolidierung einer großen Zahl von IT-Systemen nach sich. So sollen z. B. in der Domäne des operativen Customer Relationship Management (Operational CRM) die bestehenden CRM-Systeme auf einen Gruppenstandard umgestellt werden – mit der Folge, dass im jeweiligen Systemkontext alle bestehenden Informationsbeziehungen zu anderen Systemen analysiert und umgestellt und die Auswirkungen auf die operativen Geschäftsprozesse der betroffenen Geschäftseinheiten bewältigt werden müssen. Darüber hinaus muss die Betreuungsorganisation für diese Systeme neu aufgestellt werden. Außerdem sind die entsprechenden IT-Prozesse anzupassen. Diese Integrationsprobleme müssen vor dem Hintergrund sowohl vertikal als auch horizontal organisierter und verzahnter Einheiten der globalen IT-Organisation und der lokalen Anwenderorganisationen gelöst werden.

Der Wandel der Informations- und Kommunikationstechnologien bildet die dritte treibende Kraft der Veränderung der Unternehmens-IT8. Dieser Wandel 7 8

Vgl. [MaRo04]. Vgl. [KaÖst07].

1.1 Motivation

ƒ

ƒ

3

schafft neue Potenziale, insbesondere auf Produkt- und Prozessebene – e. g. Straight-Through Processing (STP) für Außendienstmitarbeiter von Versicherungsunternehmen durch Wireless-Breitband9. Diesem Potenzial muss in der Unternehmens-IT durch die Erweiterung des Technologieportfolios und durch Integration von IT-Systemen entsprochen werden. erzeugt Technologierisiken, denen z. B. durch die Erneuerung von Systemen und Infrastrukturen aufgrund der veränderten Technologielebenszyklen begegnet werden muss.

Die durch die genannten treibenden Kräfte bedingte Anpassungsleistung der Unternehmens-IT vollzieht sich nicht im Kontext einzelner, monolithischer ITSysteme, sondern vor dem Hintergrund von IT-Landschaften, die aus einer vierstelligen Zahl von IT-Systemen und vielen Tausend Informationsflüssen bestehen können und die von IT-Organisationen mit bis zu mehreren Tausend Mitarbeitern betrieben und weiterentwickelt werden. Beispielsweise verfügte die SEB GRUPPE als international agierende Finanzgruppe mittlerer Größe Ende 2007 über ein IT-Systemportfolio (IS-Portfolio) von rund 1500 IT-Systemen, wobei z. B. kleinere, MS-Access- oder MS-Excel-basierte Systeme der Fachbereiche zur individuellen Informationsaufbereitung nicht berücksichtigt sind. Eine ähnliche Größenordnung weist die IT-Landschaft der COMMERZBANK, als auf den deutschen Markt ausgerichtetes Institut, auf. Solch komplexe IT-Landschaften sind das Ergebnis sich ständig wandelnder Anforderungen, seien sie regulatorisch, durch den Wettbewerb oder technologisch bedingt. Die Befriedigung jeder einzelnen Leistungsanforderung innerhalb dieser hochkomplexen IT-Landschaften erfordert die Bearbeitung und Lösung einer sehr großen Zahl von Integrationsproblemen zwischen einzelnen ITSystemen oder ganzen Teil-IT-Landschaften und führt so zu weiter steigender Komplexität von IT-Landschaften10, die wieder neue Integrationsprobleme kreiert. Integrationsprobleme auf der einen und Komplexität der Unternehmens-IT auf der anderen Seite sind daher untrennbar miteinander verbunden, bedingen sie sich doch gegenseitig. Mit weiter steigender Komplexität in der UnternehmensIT kommt es zwangsläufig zur Verschiebung von IT-Aufwänden. Aufwände in Bezug auf die Umsetzung konkreter fachlicher Anforderungen gehen zugunsten von Aufwänden für Integrationsleistungen zurück. In diesen steigenden Integrationsleistungen manifestiert sich die Komplexität der Unternehmens-IT. Abbildung 1 verdeutlicht diese Situation. Da Integration für sich genommen keinen Nutzen erzeugt, sondern erst durch darauf aufbauende Geschäftsprozesse und sie unterstützende fachliche 9

Vgl. [Simpson07]. Vgl. [CoBa09].

10

4

1 Einleitung

Funktionalität Wertschöpfung für das Unternehmen generiert, muss die Zielsetzung darin bestehen, dem Anstieg der Integrationsleistungen und der damit verbundenen Komplexitätsproblematik durch die Weiterentwicklung der Unternehmens-IT, insbesondere der IT-Prozesse, im Rahmen eines unternehmensübergreifend aufgestellten Integrationsmanagements zu begegnen. Verteilung von IT-Aufwänden 100%

Aufwand für Erfüllung von Integrationsanforderungen

Zielsetzung Integrationsmanagement: Beeinflussung der Aufwandsverteilung

Aufwand für Erfüllung von fachlichen Anforderungen

t

Abbildung 1:

Trend in der Verteilung von IT-Aufwänden und Zielsetzung eines Integrationsmanagements11

Vor dem Hintergrund dieser Problematik verändert sich die Rolle der ITOrganisation innerhalb des Unternehmens. In immer größerem Maß stehen die Erbringung von Integrationsleistungen und die Beherrschung von Komplexität im Vordergrund12 und dies auf der Grundlage eines profunden Verständnisses der Geschäftsprozesse und der einzusetzenden Technologien. Die ITOrganisation verändert sich von der Entwicklungs- und Betriebsorganisation hin zur Integrationsorganisation – einschließlich der damit verbundenen Konsequenzen für die strategische Konzeption der Unternehmens-IT. 1.2 Problembeschreibung und Handlungsbedarf 1.2.1 Problembeschreibung Der beschriebene Veränderungsdruck, der auf die Unternehmens-IT wirkt, zeigt sich nicht nur in konkreten Integrationsproblemen, die innerhalb der ITLandschaft zu lösen sind. Vielmehr ergeben sich Fragestellungen jenseits der Integration einzelner IT-Systeme. Diese Fragestellungen betreffen zum Beispiel: 11 12

In Anlehnung an [Marty02]. Vgl. [Durst07], S. 9 ff.

1.2 Problembeschreibung und Handlungsbedarf

ƒ ƒ ƒ ƒ

5

die Zusammenführung oder Desintegration von (Teil-) IT-Landschaften aufgrund von Fusionen, Übernahmen und Aufspaltungen von Unternehmen oder Unternehmensteilen die Erneuerung von (Teil-) IT-Landschaften die Zusammenführung oder Desintegration von IT-Organisationen die unternehmensübergreifende Integration von IT-Systemen

So sind etwa im Falle der Ausgliederung von Prozessen aus der Wertschöpfungskette eines Unternehmens unternehmensübergreifende Integrationsprobleme zu bewältigten. Ein Beispiel hierfür ist die Integration der Abrechnungssysteme einer Bank mit der Abwicklungsplattform eines Outsourcing-Partners aufgrund der Ausgliederung der Handelsabwicklung aus der Wertschöpfungskette der Bank. Zur Verdeutlichung der Problematik ist die Einführung der Abgeltungssteuer in die deutsche Steuergesetzgebung zum 1. Januar 2009 zu betrachten. Diese Neuregelung verlangt von Banken z. B. den Aufbau hoch integrierter Steuerverrechnungssysteme. Die Erfüllung der mit der Abgeltungssteuer verbundenen fachlichen Anforderungen stellt Banken dabei für sich genommen bereits vor große Herausforderungen, müssen doch neue IT-Systeme in sehr kurzer Zeit entworfen, realisiert, getestet und in Produktion genommen werden. Allein der Aufwand für den Test der neuen fachlichen Logik umfasst mehrere Tausend Testfälle. Die Problematik ist verbunden mit der Notwendigkeit, bestehende Informationsbeziehungen zu Dutzenden Beratungs-, Abwicklungs- und Bestandsführungssystemen umzugestalten. All diese veränderten oder neu gestalteten Informationsbeziehungen müssen so implementiert werden, dass sichergestellt ist, dass das Kreditinstitut die Abgeltungssteuer für den Kunden korrekt abführt. Andernfalls steht die Bank gegenüber den Finanzbehörden im Obligo. Auf diese Weise ergibt sich eine insbesondere durch Integrationsprobleme generierte Ressourcenproblematik, die dazu führt, dass andere Projekte nicht umgesetzt werden können. Dies betrifft dann insbesondere auch solche Projekte, die die Wettbewerbsposition des jeweiligen Instituts verbessern sollen. Dieses Beispiel zeigt, dass diejenigen Institute im Vorteil sind, die einerseits ihre Unternehmens-IT so organisieren, dass die Auswirkungen neuer Integrationsprobleme auf die IT-Landschaft möglichst gering sind, und deren IT-Organisation andererseits über große Kompetenz bei der Lösung dieser Probleme verfügt, da eine geringere Zahl von Projekten, die die Wettbewerbsposition verbessern, Anforderungen wie der Abgeltungssteuer zum Opfer fallen. Während ein Institut also Projekte zur Verbesserung der Wettbewerbsposition trotzt Abgeltungssteuer

6

1 Einleitung

durchführen kann, muss ein anderes Institut aufgrund ausufernder Integrationsprobleme solche Projekte verschieben. Die beschriebene Problematik wird dadurch verstärkt, dass bei der Durchführung der meisten Projekte Termin- und Kostendruck dominieren; ein Umstand, der den o. a. treibenden Kräften geschuldet ist und der die Sensibilität dafür reduziert, dass in Projekten immer wieder dieselben Arten von Integrationsleistungen erbracht werden, ohne dass auf standardisierte, systematisierte Lösungsmuster zurückgegriffen wird. Das bedeutet Folgendes: Mit einem immer größeren Teil der Ressourcen werden Integrationsleistungen für wiederkehrende Arten von Integrationsproblemen erbracht und dabei die Integrationsprobleme der Zukunft durch den ungesteuerten Anstieg der Komplexität der Unternehmens-IT geschaffen. So besteht für Unternehmen das Dilemma, immer mehr Ressourcen für Integrationsleistungen einsetzen zu müssen. Damit stehen weniger Ressourcen für die Umsetzung der dem Wettbewerb geschuldeten fachlichen Anforderungen zur Verfügung, deren Zahl aufgrund zunehmender Wettbewerbsintensität steigt. Insgesamt stellt sich die Situation in der IT größerer Unternehmen so dar, dass die Lösung von Integrationsproblemen ein allgegenwärtiges Thema ist. Der Kern der Problematik besteht dabei jedoch nicht darin, mithilfe bestimmter Technologien bestimmte Integrationsprobleme zu lösen, sondern die Unternehmens-IT durchgängig, das heißt ganzheitlich im Hinblick auf die beschriebene Problematik zu organisieren. SCHELP UND WINTER weisen in Integrationsmanagement13 darauf hin, dass es weniger um die Integrationsaufgabe aus technologischer Sicht geht, sondern vielmehr um die Perspektive des Managements auf Integration. Dies bedeutet für die Autoren die Planung, Steuerung, Führung, Wirtschaftlichkeitsanalyse und -kontrolle von Integrationsprojekten und Integrationsinfrastrukturen und schließt die Definition entsprechender Architekturen in der Unternehmens-IT ein. SCHELP UND WINTER weisen zudem darauf hin, dass das Themenfeld des Integrationsmanagements im Sinne einer übergreifenden Managementaufgabe erst am Anfang steht. Dies zeigt sich nach Erfahrung des Autors der vorliegenden Arbeit auch darin, dass bisher nur wenige Unternehmen Integrationsmanagement i.S. dieser ganzheitlichen Sicht in der strategischen Konzeption der Unternehmens-IT berücksichtigen14. Zusammenfassend kann also festgehalten werden, dass Integrationsmanagement auf Basis einer weiterentwickelten strategischen Konzeption Eingang in die Management-Prozesse und die operativen Prozesse der Unternehmens-IT 13

Vgl. [ScheWin06]. Die SEB GRUPPE ist ein Beispiel für ein Unternehmen, das Aspekte des Integrationsmanagements explizit in der strategischen Konzeption berücksichtigt. Komplexität der IT-Landschaft wird bei der SEB explizit als strategisches Handlungsfeld ausgewiesen. Siehe dazu auch Kapitel 5. 14

1.2 Problembeschreibung und Handlungsbedarf

7

finden muss, um der beschriebenen Situation aktiv zu begegnen. Dies muss einhergehen mit der gezielten Weiterentwicklung der IT-Organisation und ihrer Mitarbeiter. Mithilfe eines solchen ganzheitlichen, systematischen Integrationsmanagements kann die Unternehmens-IT dazu beitragen, den beschriebenen Veränderungsdruck zu bewältigen und so die Lebensfähigkeit des Unternehmens in seiner Umwelt zu sichern. 1.2.2 Handlungsbedarf Für die in den vorangehenden Abschnitten aufgeführten Integrationsprobleme existieren teilweise Lösungsangebote aus Forschung und Praxis – in einigen Bereichen haben sich Best Practices etabliert. Hierzu einige Beispiele: ƒ ƒ ƒ ƒ

ƒ ƒ

ƒ

15

Integration von Anwenderorganisation und Unternehmens-IT Es existieren erprobte Vorgehensweisen (Best Practices) zur Gestaltung der Integration der Anwenderorganisation und der IT-Organisation auf Basis von Referenzmodellen zur IT-Prozesslandschaft15. Systemintegration zur Befriedigung analytischer Fragestellungen Auf der Ebene der Systemintegration haben sich Methoden und Technologien des Data Warehousing etabliert, die das Problem schlecht integrierter operativer Systeme durch die Schaffung eines zentralen Information Hub für analytisch/dispositive Fragestellungen der Geschäftseinheiten adressieren. Systemintegration und Straight-Through Processing (STP) Paradigmen wie Event-Driven Architecture (EDA)16 oder Service-Oriented Architecture (SOA)17 werden in der IT umgesetzt, um Geschäftsprozesse im Sinne eines Straight-Through Processing durchgängig unter Integration von IT-Systemen entlang der Prozesskette zu implementieren. Dabei bedeutet STP die vollautomatische Abarbeitung von standardisierten Geschäftsereignissen bei gleichzeitiger Reduktion manueller Aktivitäten bei der Bearbeitung von Business Exceptions, also von geschäftlichen Ereignissen jenseits der definierten Standardfälle (z. B. STP von Baufinanzierungen ab Antragsstellungen bis zum Versand des Vertrages an den Kunden). Vorgehensmodell zur Entwicklung von Integrationsarchitekturen

Siehe dazu Abschnitt 4.2. Zum Paradigma der Event-Driven Architecture und deren Abgrenzung zum Paradigma der Service-Oriented Architecture vgl. [SchuRoy05]. 17 Vgl. [Quasar08]. 16

8

1 Einleitung

ƒ

Die OASYS-Gruppe18 definiert ein sechsstufiges Vorgehensmodell zur systematischen Entwicklung von Integrationsarchitekturen zur Lösung von Integrationsproblemen zwischen IT-Systemen.

Für bestimmte Integrationsprobleme existieren also erprobte Architekturmuster und Best Practices. Ein ganzheitlicher Ansatz, der Integrationsmanagement in der strategischen Konzeption der Unternehmens-IT verankert und die ITProzesse systematisch entlang eines übergreifenden Ansatzes aufstellt, steht bisher nicht zur Verfügung. Hier ergibt sich die Forderung nach einem Gesamtkonzept für das ganzheitliche Integrationsmanagement in der Unternehmens-IT größerer Unternehmen. Ein solches Konzept kann als System aufeinander abgestimmter Gestaltungsempfehlungen für die Unternehmens-IT verstanden werden, die darauf ausgerichtet sind, Integrationsmanagement und, damit verbunden, Komplexitätsmanagement in den Prozessen der Unternehmens-IT zu verankern. Die Zielsetzung dieser Verankerung besteht darin, die IT-Unternehmensarchitektur und die IT-Prozesslandschaft so aufzustellen, dass die Reaktionsfähigkeit und Leistungsqualität der Unternehmens-IT verbessert werden und dem in Abbildung 1 dargestellten Trend entgegengewirkt wird. Dieses Konzept zum Integrationsmanagement muss auf wohldefinierten Modellen und Vorgehensweisen beruhen und im Sinne eines unternehmensübergreifenden Ansatzes aufgestellt sein. Hier wird im Folgenden kurz vom ganzheitlichen Integrationsmanagement gesprochen. Die Aufgabe des Managements ist die Einführung eines solchen Integrationsmanagements: ƒ ƒ ƒ

Es betrifft alle Bereiche der Unternehmens-IT einschließlich der Verzahnung mit der Geschäftsseite. Es betrifft die strategische Konzeption der Unternehmens-IT. Es schafft Potenziale im Wettbewerb.

1.3 Forschungsdesign in der Wirtschaftsinformatik Die primären Untersuchungsgegenstände der Wirtschaftsinformatik sind betriebliche Informationssysteme19 und der Kontext, in dem sich deren Planung, Management, Realisierung, Nutzung und Weiterentwicklung vollziehen. Nach BE20 CKER ergibt sich aus der Positionierung der Wirtschaftsinformatik zwischen 18

OASYS, Forschungsprojekt Offene Anwendungssystem-Architekturen in betrieblichen Wertschöpfungsketten. Ein Forschungsprojekt, das von einer Bamberger Arbeitsgruppe im Rahmen des bayerischen Forschungsverbundes Wirtschaftsinformatik (FORWIN) durchgeführt wurde. 19 Zur Abgrenzung des Begriffes Informationssystem siehe Abschnitt 2.1.3. 20 Vgl. [Becker03].

9

1.3 Forschungsdesign in der Wirtschaftsinformatik

den beiden Mutterdisziplinen, den Wirtschaftswissenschaften auf der einen und der Informatik auf der anderen Seite, die Notwendigkeit eines festgelegten Forschungsdesigns für Forschungsvorhaben innerhalb der Wirtschaftsinformatik.

Wirtschaftsinformatik

Informatik

Betriebswirtschaftslehre

Integrationsmanagement

Aspekte der Informations- und Kommunikationstechnologie

Abbildung 2:

Aspekte des Managements von Unternehmen

Perspektive

Wirtschaftsinformatik und Positionierung der Arbeit21

BECKER schlägt gemäß nachstehender Abbildung vor, das Forschungsdesign in der Wirtschaftsinformatik auf die Grundposition des Forschenden, das Forschungsziel und die eingesetzte Forschungsmethode zu stützen. Forschungsdesign (e.g. Forschung zum Integrationsmanagement)

Grundposition

Forschungsziel

Forschungsmethode

Abbildung 3:

Dimensionen des Forschungsdesigns in der Wirtschaftsinformatik22

Grundposition Die Grundposition des nach Erkenntnis strebenden Individuums (Subjekt) und seines Verhältnisses zum Betrachtungsgegenstand (Objekt) prägen maßgeblich 21 22

Entnommen und angepasst aus [Jung06], S. 8. Vgl. [Becker03], S. 7.

10

1 Einleitung

den Gültigkeitsanspruch der betriebenen Forschung. Die möglichen Grundpositionen ergeben sich nach BECKER aus der ontologischen Position23 und der epistemologischen Position24. Insgesamt ergeben sich drei mögliche Grundpositionen für das nach Erkenntnis strebende Individuum. Epistemologische Position objektives Erkennen ist unmöglich

Ontologische Position

Abbildung 4:

es gibt eine objektive Welt

mögliche Position des Forschenden

es gibt keine objektive Welt

mögliche Position des Forschenden

objektives Erkennen ist möglich mögliche Position des Forschenden

entfällt

Grundpositionen des nach Erkenntnis strebenden Individuums25

Forschungsziel Erkenntnisziele konzentrieren sich auf das Verstehen der realen Welt und der hier auftretenden Sachverhalte. Dies kann mit dem Ziel verbunden sein, Prognosen über die Veränderung der beobachteten Sachverhalte zu erstellen. Gestaltungsziele betreffen die Veränderung der Realität, wobei auf die Ergebnisse der Forschung entlang von Erkenntniszielen zurückgegriffen wird. Nach BECKER26 lassen sich Forschungsziele in der Wirtschaftsinformatik gemäß Abbildung 5 klassifizieren. Forschungsmethode Die durch den Forschenden gewählte Methode muss auf die eingenommene Grundposition und das definierte Forschungsziel abgestimmt sein27. Die Festle-

23

Nach [Becker03] die Frage, ob eine Realwelt existiert, die unabhängig von der Erkenntnis existiert. Nach [Becker03] die Frage, ob subjektunabhängige Erkenntnis möglich ist. 25 Entnommen und adaptiert aus [Becker03], S. 8. 26 Vgl. [Becker03], S. 13. 27 „Darüber hinaus werden insbesondere diejenigen Positionen, die die Subjektivität von Erkenntnis und Kommunikation betonen, Maßnahmen als Bestandteil der Methoden vorsehen, die versuchen, Friktionen von Wahrnehmung und Erkenntnis aktiv zu begegnen. Neben der grundsätzlichen inhaltlichen Eignung der Forschungsmethode zur Erreichung des Sachzieles der Forschung wird die Auswahlentscheidung insbesondere durch die Anforderungen der Methoden an zur Verfügung stehende Ressourcen geprägt. Insbesondere die Verfügbarkeit von Interviewpartnern oder vergleichbarer Untersuchungsfelder schränkt die freie Auswahl der Forschungsmethoden häufig in bedeutendem Umfang ein.“ [Becker03], S.15. 24

11

1.3 Forschungsdesign in der Wirtschaftsinformatik

gung der Forschungsmethode der vorliegenden Arbeit erfolgt auf Basis der in Tabelle 1 gelisteten Methoden der Wirtschaftsinformatik.28 Perspektive IuK-Technologie

Erkenntnisziel

Gestaltungsziel

Verständnis von Methoden und Entwicklung von Methoden und Techniken der Gestaltung von Informationssystemen Informationssystemen

Methodischer Techniken der Gestaltung von Auftrag Inhaltlicher Auftrag

Verständnis des Anwendungsspektrums von Informationssystemen

Entwicklung weiterer Anwendungsbereiche von Informationssystemen

Perspektive Management von Unternehmen

Abbildung 5:

Klassifizierung von Forschungszielen

Konstruktionsorientiert ƒ Prototyping

Verhaltensorientiert ƒ Gounded Theory

ƒ

Simulation

ƒ

ƒ

Modellierung und Referenzmodellierung Formal-deduktive, konzeptionell-deduktive und argumentativ-deduktive Analyse Aktionsforschung

ƒ

ƒ ƒ

Tabelle 1:

ƒ

Quantitativ-empirische Querschnittsanalyse Qualitativ-empirische Querschnittsanalyse Fallstudien

ƒ ƒ

Labor- und Feldexperimente Ethnografie

Klassifizierung von Forschungsmethoden der Wirtschaftsinformatik

Das einem Forschungsvorhaben zugrunde liegende Design kann darüber hinaus durch das angewandte Forschungsparadigma charakterisiert werden. Nach FISCHER29 können bei der Durchführung von Forschungsvorhaben im Bereich der Wirtschaftsinformatik zwei komplementäre Paradigmen unterschieden werden: 28 29

Vgl. [WiHe06], S. 6 ff. Vgl. [Fischer08], S. 6 ff.

12 ƒ ƒ

1 Einleitung

der Behavioral-Science-Ansatz und der Design-Science-Ansatz.

Der Behavioral-Science-Ansatz verfolgt das Ziel, die Entwicklung und Validierung von Theorien durchzuführen, die das Verhalten von Organisationen und der Menschen innerhalb dieser Organisationen unter dem Blickwinkel der Entwicklung und des Betriebs von Informationssystemen30 erklären bzw. prognostizieren. Der Design-Science-Ansatz hingegen verfolgt das Ziel der Konstruktion und Evaluierung neuer, innovativer Artefakte, die dabei helfen sollen, zuvor identifizierte Problemstellungen zu lösen – stellt also einen konstruktionsorientierten Ansatz dar. Vier Arten von Artefakten können nach Fischer unterschieden werden: ƒ ƒ ƒ ƒ

Konstrukte (Begriffe oder Symbole), Modelle (Abstraktionen oder Abbildungen), Methoden (Vorgehensweisen oder Prozeduren), Instanzen (Systeme).

1.4 Forschungsdesign der Arbeit Das Design des durchgeführten Forschungsvorhabens wird durch die Definition der Forschungsposition, des Forschungszieles, des Forschungsparadigmas und der Forschungsmethode festgelegt. Forschungsposition Die Forschungsposition der Arbeit ergibt sich aus der in Abbildung 6 getroffenen Festlegung, geht somit von der Subjektivität zu gewinnender Erkenntnisse in einer nicht objektivierbaren Welt aus. Epistemologische Position objektives Erkennen ist unmöglich

Ontologische Position

Abbildung 6: 30

es gibt eine objektive Welt

mögliche Position des Forschenden

es gibt keine objektive Welt

mögliche Position des Forschenden

objektives Erkennen ist möglich mögliche Position des Forschenden

entfällt

Grundlegende Forschungsposition der Arbeit

Zur Abgrenzung des Begriffes Informationssystem siehe Abschnitt 2.1.3.

1.4 Forschungsdesign der Arbeit

13

Forschungsziel Auf Basis der in Abschnitt 1.2 beschriebenen Problemstellung, des dort definierten Handlungsbedarfes sowie der definierten Forschungsposition wird als Forschungsziel die Beantwortung der zentralen Forschungsfrage der Arbeit definiert. Zentrale Forschungsfrage Wie kann ein Gesamtkonzept zum ganzheitlichen Integrationsmanagement in der Unternehmens-IT größerer Unternehmen gestaltet werden, welche Bedeutung besitzt dabei das Komplexitätsmanagement, welcher Bezug besteht zur ITUnternehmensarchitektur, und wie kann Integrationsmanagement in die Prozesslandschaft der Unternehmens-IT eingebettet werden? Das Forschungsziel wird durch ein primäres Erkenntnisziel und ein primäres Gestaltungsziel operationalisiert. Primäres Erkenntnisziel Das primäre Erkenntnisziel besteht in der Beurteilung der Möglichkeiten, die Stärke des in Abbildung 1 dargestellten Trends zur Aufwandsverschiebung in der Unternehmens-IT hin zu Integrationsleistungen zu beeinflussen. Primäres Gestaltungsziel Das primäre Gestaltungsziel besteht in der Aufstellung eines Systems von Empfehlungen zur Gestaltung der Unternehmens-IT größerer Unternehmen, um auf diese Weise die zentrale Forschungsfrage zu beantworten. Auf Basis der Forschungsfrage sowie der definierten Forschungsziele wird das primäre Betrachtungsobjekt der Arbeit festgelegt. Primäres Betrachtungsobjekt Primäres Betrachtungsobjekt ist die Unternehmens-IT, bestehend aus ITLandschaft und IT-Organisation. Im Vorgriff auf die genaue begriffliche Abgrenzung in Kapitel 2 werden IT-Landschaft und IT-Organisation folgendermaßen verstanden: Die IT-Landschaft ist die Gesamtheit aller IT-Systeme eines Unternehmens einschließlich der zugrunde liegenden IT-Basisinfrastruktur, welche die Durchführung von Geschäftsprozessen unterstützen.31 Die IT-Organisation besteht aus allen Personen, deren Aufgabenportfolio 31

Angelehnt an die Definition des Begriffes Anwendungslandschaft durch DERN; vgl. [Dern09], S. 17.

14

1 Einleitung

auf die Planung, Steuerung, Weiterentwicklung oder den Betrieb von Elementen der IT-Landschaft ausgerichtet ist. Forschungsmethode Bei der Bearbeitung der Ziele der vorliegenden Arbeit kommen die konstruktionsorientierten Methoden der deduktiven Analyse sowie der induktiven (auf Basis von Beobachtungen) und der deduktiven Modellierung zur Anwendung. Die Evaluierung erfolgt mithilfe der verhaltensorientierten Methode der Fallstudie. Forschungsparadigma Die für die vorliegende Arbeit formulierten Ziele werden nach dem Forschungsparadigma des Design-Science-Ansatzes, d. h. konstruktionsorientiert bearbeitet. Konstruiert werden Definitionen, Modelle und Methoden, die in ein System aufeinander abgestimmter Gestaltungsempfehlungen münden, welches das Gesamtkonzept zum ganzheitlichen Integrationsmanagement repräsentiert. Die folgende Abbildung fasst das Design des Forschungsvorhabens zum Integrationsmanagement in der Unternehmens-IT zusammen.

15

1.4 Forschungsdesign der Arbeit

Forschungsdesign Integrationsmanagement Grundposition • Es gibt keine objektive Welt • Objektives Erkennen ist unmöglich

Zentrale Forschungsfrage Wie kann ein Gesamtkonzept zum Integrationsmanagement in der Unternehmens-IT incl. Berücksichtigung Komplexitätsmanagement, IT-Prozesslandschaft und IT-Unternehmensarchitektur gestaltet werden? Forschungsziele • Erkenntnisziel: Bewertung von Möglichkeiten, den Trend zur Aufwandsverschiebung hin zu Integrationsleistungen zu beeinflussen. • Gestaltungsziel: Entwicklung Gesamtkonzept zum Integrationsmanagement in Form eines Systems von Gestaltungsempfehlungen

Forschungsparadigma • Design-Science-Ansatz Forschungsmethode Konstruktionsorientiert • Deduktive Analyse • Modellierung Evaluation

Verhaltensorientiert • Fallstudien

Betrachtungsobjekt Unternehmens-IT = IT-Landschaft + IT-Organisation

Abbildung 7:

Forschungsdesign der Arbeit

Nach JUNG32 ist die Beantwortung der Forschungsfrage aus wissenschaftlicher Sicht als Formulierung von Hypothesen im Sinne möglicher Antworten und deren Überprüfung zu verstehen. Für die Forschungsfrage der Arbeit existiert keine anerkannte Theorie, die zur vollständigen Erklärung der zugrunde liegenden Zusammenhänge geeignet wäre. Daraus ergibt sich im Rahmen des konstruktionsorientierten Forschungsdesigns und der gewählten Methoden der Ansatz, aus Beobachtungen Hypothesen herzuleiten und darauf ausgerichtete Artefakte, d. h. Definitionen, Modelle und Methoden, induktiv und deduktiv zu

32

Vgl. [Jung06], S. 6 f.

16

1 Einleitung

erarbeiten, die dann zu evaluieren sind. Grundlage der für die vorliegende Arbeit genutzten Beobachtungen waren die folgenden Quellen: ƒ ƒ

ƒ ƒ

Literatur aus Forschung und Praxis; der durch die Beratungshäuser Syracom AG und Ardour Consulting Group gegründete EAM Think Tank, in dem unter Beteiligung zahlreicher größerer Unternehmen und des Lehrstuhls für betriebliche Informationssysteme (SEBIS) der TU München Fragestellungen des Architekturmanagements größerer Unternehmen bearbeitet werden; Beobachtungen durch Mitarbeiter mehrerer Beratungshäuser in den von diesen Mitarbeitern beratenen Unternehmen; diese Beobachtungen wurden in Workshops im Hinblick auf die Hypothesen analysiert; Beobachtungen des Autors im Rahmen seiner Tätigkeit für verschiedene Finanzdienstleister und Beratungsunternehmen.

1.5 Gang der Untersuchung 1.5.1 Vorgehensmodell

A

Definition Problemstellung und Handlungsbedarf

B

Festlegung Forschungsdesign

C

Analyse – Aufstellung Gestaltungsempfehlungen

D

Evaluierung

F

G

Abbildung 8:

Definitions-, Modell- und Methodenkonstruktion

Aus den bisherigen Ausführungen ergibt sich das in Abbildung 8 dargestellte Vorgehensmodell für die Durchführung des Forschungsvorhabens.

E

Ergebniszusammenfassung und kritische Würdigung Forschungsprozess

Ausblick

Vorgehensmodell des Forschungsvorhabens

17

1.5 Gang der Untersuchung

Das Vorgehensmodell der Arbeit kann folgendermaßen beschrieben werden: ƒ ƒ

ƒ ƒ

Ausgehend von der definierten Problemstellung und dem beschriebenen Handlungsbedarf (A) wird das Forschungsdesign (B) festgelegt. Im Rahmen des festgelegten Forschungsdesigns wird in der Analyse (C) das Gesamtkonzept in Form eines Systems von Gestaltungsemfehlungen zur Unternehmens-IT auf Basis der konstruierten Definitionen, Modelle und Methoden (E) entwickelt. Das entwickelte Gesamtkonzept wird im Rahmen der verhaltensorientierten Methode der Fallstudie (D) evaluiert. Die in (A) – (E) entwickelten Ergebnisse werden zusammengefasst. Der Forschungsprozess wird einer kritischen Würdigung unterzogen (F). Abschließend werden offen gebliebene Punkte benannt. Der identifizierte weiterführende Forschungsbedarf wird zusammengefasst (G).

1.5.2

Kapitelübersicht

Kapitel 1 - Einleitung • Motivation • Problemstellung und Handlungsbedarf • Forschungsdesign • Aufbau der Arbeit

Definition Problemstellung und Handlungsbedarf

Festlegung Forschungsdesign

Analyse – Aufstellung Gestaltungsempfehlungen

Definitions-, Modell- und Methodenkonstruktion

Die Struktur der vorliegenden Arbeit beruht auf dem definierten Vorgehensmodell. Kapitel 1 (Einleitung) skizziert die Problemstellung und leitet den Handlungsbedarf ab. Davon ausgehend werden Forschungsdesign, Methodik und Struktur der Arbeit festgelegt. Abbildung 9 zeigt den Zusammenhang zwischen Kapitel 1 und der Gesamtmethodik der Arbeit.

Evaluierung

Ergebniszusammenfassung und kritische Würdigung Forschungsprozess

Ausblick

Abbildung 9:

Kapitel 1 und Vorgehensmodell der Arbeit

Kapitel 2 schafft den Bezugsrahmen sowie die begriffliche Basis der Arbeit und liefert die Grundlegung für die Gesamtkonzeption. Dazu wird zunächst die

18

1 Einleitung

Kapitel 2 – Bezugsrahmen und Grundlegung • Die Unternehmens-IT als komplexes Teilsystem des Unternehmens • Definition und Abgrenzung Integrationsmanagement • Definition und Abgrenzung Unternehmensarchitektur • Grundprinzipien des Integrationsmanagements

Definition Problemstellung und Handlungsbedarf

Festlegung Forschungsdesign

Analyse - Aufstellung Gestaltungsempfehlungen

Definitions-, Modell- und Methodenkonstruktion

Unternehmens-IT als komplexes Teilsystem des Unternehmens definiert und modelliert. Anschließend wird das Verständnis des Begriffes Integrationsmanagement geschärft, indem Integration und IT-Management aus systemischer Sicht analysiert werden und eine beide Teile vereinende Definition erarbeitet wird. Zusammenfassend werden Grundprinzipien des Integrationsmanagements aufgestellt.

Evaluierung

Ergebniszusammenfassung und kritische Würdigung Forschungsprozess

Ausblick

Abbildung 10: Kapitel 2 und Vorgehensmodell der Arbeit Im dritten Kapitel werden verwandte Arbeiten identifiziert und im Kontext des in Kapitel 2 geschaffenen Fundamentes analysiert. Dabei werden Artefakte, das heißt Modelle und Methoden, konstruiert und in übergeordnete Gestaltungsempfehlungen überführt. Daraus werden die Ziele für die weitere Ausarbeitung abgeleitet. Im Folgeabschnitt werden existierende Ansätze zum ganzheitlichen Integrationsmanagement analysiert und - soweit möglich – für die weitere Ausarbeitung der Arbeit erschlossen. Zusammenfassend wird anschließend die Aufgabenstellung der weiteren Ausarbeitung in den Kapiteln 3-5 festgelegt. Im vierten Kapitel wird auf Basis der Ergebnisse des 3. Kapitels der Verfeinerungsbedarf festgelegt, der dann entlang der definierten Schwerpunkte bearbeitet wird. Bei der Bearbeitung werden die vorliegenden übergeordneten Gestaltungsempfehlung reflektiert und weitere Artefakte, das heißt Definitionen, Modelle und Methoden, werden unter Einbeziehung weiterer Arbeiten aus Forschung und Praxis konstruiert. Das Ergebnis der Bearbeitung sind weiterführende Gestaltungsempfehlungen und Leitlinien für das Integrationsmanagement.

19

Kapitel 3 – Übergeordnete Gestaltungsempfehlungen • Analyse verwandter Arbeiten • Entwicklung übergeordneter Gestaltungsempfehlungen

Kapitel 4 – Weiterentwicklung der Gestaltungsempfehlungen • Festlegung des weiteren Verfeinerungsbedarfes • Bearbeitung der definierten Verfeinerungsschwerpunkte • Entwicklung weiterführender Gestaltungsempfehlungen

Definition Problemstellung und Handlungsbedarf

Festlegung Forschungsdesign

Analyse - Aufstellung Gestaltungsempfehlungen

Definitions-, Modell- und Methodenkonstruktion

1.5 Gang der Untersuchung

Evaluierung

Ergebniszusammenfassung und kritische Würdigung Forschungsprozess

Ausblick

Abbildung 11: Kapitel 3/4 und Vorgehensmodell der Arbeit

Definition Problemstellung und Handlungsbedarf

Festlegung Forschungsdesign Kapitel 5 – Evaluierung • Definition Evaluierungsansatz und Evaluierungsmethode • Durchführung der Evaluierung

Analyse - Aufstellung Gestaltungsempfehlungen

Definitions-, Modell- und Methodenkonstruktion

In Kapitel 5 werden auf Basis des gewählten Forschungsdesigns der Evaluierungsansatz und die Evaluierungsmethode definiert. Die im Forschungsdesign ausgewählte verhaltensorientierte Methode der Fallstudie wird angewandt, um die aufgestellten Gestaltungsempfehlungen zu verifizieren. Auf diese Weise wird das Gesamtkonzept auf eine mögliche Falsifizierung überprüft.

Evaluierung

Ergebniszusammenfassung und kritische Würdigung Forschungsprozess

Ausblick

Abbildung 12: Zusammenhang Kapitel 5 und Gesamtmethodik der Arbeit Im sechsten Kapitel werden zunächst die Ergebnisse zusammengefasst. Dann wird das Forschungsdesign der Arbeit aufgegriffen und es wird analysiert, inwieweit die Forschungsfrage beantwortet und die definierten Gestaltungs- und Erkenntnisziele erreicht wurden. Dabei wird der Forschungsprozess kritisch

20

1 Einleitung

Kapitel 6 – Zusammenfassung und Ausblick • Ergebniszusammenfassung • Abgleich Forschungsdesign und durchgeführte Untersuchung • Offene Punkte • Identifizierter weiterführender Forschungsbedarf

Definition Problemstellung und Handlungsbedarf

Festlegung Forschungsdesign

Analyse - Aufstellung Gestaltungsempfehlungen

Modell- und Methodenkonstruktion

reflektiert. Abschließend wird ein Ausblick vorgenommen, indem offene Punkte benannt und Ansatzpunkte für ergänzende Forschungsaktivitäten aufgezeigt werden.

Evaluierung

Ergebniszusammenfassung und kritische Würdigung Forschungsprozess

Ausblick

Abbildung 13: Kapitel 6 und Vorgehensmodell der Arbeit

2 Bezugsrahmen und Grundlagen Das Ziel des zweiten Kapitels besteht darin, das begrifflich-definitorische Fundament der Arbeit zu legen und darauf aufbauende Gestaltungsprinzipien für das Integrationsmanagement in der Unternehmens-IT aufzustellen. Ausgehend vom Forschungsdesign der Arbeit wird im ersten Abschnitt des Kapitels die Unternehmens-IT aus systemtheoretischer Sicht beleuchtet. Daran schließt sich die systemtheoretische Abgrenzung des ganzheitlichen Integrationsmanagements an. Dies erlaubt die Abgrenzung des Integrationsmanagements als Teildisziplin des Managements der Unternehmens-IT. Anschließend wird das für die Arbeit geltende Grundmodell zum Integrationsmanagement definiert. Dieses Modell fasst die der vorliegenden Arbeit zugrunde liegende Sicht zusammen. In Abschnitt 2.2.3 wird das für die vorliegende Arbeit wesentliche Verständnis der Begriffe Unternehmensarchitektur und IT-Unternehmensarchitektur geklärt. Ebenso wird die Bedeutung eines transformationsorientierten Ansatzes zur Unternehmensarchitektur für das Konzept eines ganzheitlichen Integrationsmanagements erläutert. Auf Basis des so erweiterten begrifflichen Fundaments wird das Grundmodell zum Integrationsmanagement ergänzt. Abschließend wird das entwickelte Fundament in Form grundlegender Gestaltungsprinzipien zusammengefasst. Sie bilden den Rahmen der weiteren Ausarbeitung des Konzeptes zum ganzheitlichen Integrationsmanagement in den Kapiteln 3 und 4. Abbildung 14 fasst das Vorgehen bei der Entwicklung des Gesamtkonzeptes in Form eines Systems von Gestaltungsempfehlungen zusammen.

G. Dern, Integrationsmanagement in der Unternehmens-IT, DOI 10.1007/978-3-8348-8154-0_2, © Vieweg+Teubner Verlag | Springer Fachmedien Wiesbaden GmbH 2011

22

Was ist UnternehmensIT?

Das Unternehmen als komplexes, dynamisches, offenes System

Was ist ganzheitliches Integrationsmanagement?

Spektrum Integrationsmanagement

Einbettung Integrationsmanagement in das ITManagement

Grundmodell zum Integrationsmanagement

Systemtheoretisches Fundament

Integrationsmanagement und Unternehmensarchitektur

Forschungsdesign

Kapitel 2

Kapitel 1

2 Bezugsrahmen und Grundlagen

Gestaltungsprinzipien zum Integrationsmanagement der Unternehmens-IT

Kapitel 4

Übergeordnete Gestaltungsemfehlungen zum Integrationsmanagement der Unternehmens-IT

Kapitel 3

Analyse von Arbeiten aus Forschung und Praxis

Weiterführende Gestaltungsempfehlungen der Unternehmens-IT

Abbildung 14:

Entwicklung von Gestaltungsempfehlungen

2.1 Die Unternehmens-IT als komplexes Teilsystem des Unternehmens 2.1.1 Systemtheoretische Begriffsdefinition der IT-Landschaft Die Systemtheorie ist ein interdisziplinäres Erkenntnismodell, in dem Systeme zur Beschreibung und Erklärung unterschiedlich komplexer Phänomene herangezogen werden. Die Analyse von Strukturen und Funktionen von Systemen soll Vorhersagen über das Systemverhalten erlauben. Die Systemtheorie wurde von dem österreichischen Biologen VON BERTALANFFY begründet, der 1951 seine Theorie der offenen Systeme33 veröffentlichte, die der Erklärung von Prozessen des Wachstums, der Anpassung und 33

Vgl. [Bertal76].

2.1 Die Unternehmens-IT als komplexes Teilsystem des Unternehmens

23

Selbstregulation dient. VON BERTALANFFY geht davon aus, dass das SystemUmwelt-Verhältnis interaktiv ist, d. h., dass das System unter Umwelteinflüssen steht, aber auch selbst gestaltend auf die Umwelt einwirken kann. Solche Systeme, die unter Umwelteinflüssen stehen, gleichzeitig aber auch auf die Systemumwelt einwirken, versteht VON BERTALANFFY als offene Systeme. Nach seinem Verständnis können sie sich nur im Austausch mit der Umwelt erhalten und entwickeln34. Für den Begriff System gibt es keine für alle durch die Systemtheorie betroffenen Wissenschaftsdisziplinen allgemeingültige Definition. Die begriffliche Abgrenzung der vorliegenden Arbeit basiert auf dem Systemverständnis von SCHULTE-ZURHAUSEN35. Es ergibt sich die folgende Definition: Definition - System Unter einem System wird eine von der Umwelt abgrenzbare Gesamtheit von Elementen verstanden, die miteinander in Beziehung stehen. Dabei sind die Elemente des Systems materielle und immaterielle Komponenten, die durch ihre Interaktion das System erzeugen und bei ihrer Interaktion einen gemeinsamen Zweck verfolgen. Die im Zeitablauf relativ konstanten Beziehungsmuster zwischen den Elementen bilden die Struktur des Systems. Das Kriterium der Abgegrenztheit ergibt sich insbesondere aus dem gemeinsamen Zweck und der dem System zugrunde liegenden Struktur, die auf den Interaktionsmustern der beteiligten Elemente basiert. Offen ist ein System dann, wenn es sich im Austausch mit der Umwelt erhält und weiterentwickelt. Die Dynamik offener Systeme äußert sich in den vielfältigen Interaktionen des jeweiligen Systems mit seiner Umwelt. Die Komplexität der offenen Systeme lässt sich zurückführen auf die Zahl und die Vielfalt der Interaktionsbeziehungen, die einerseits zwischen den Systemelementen untereinander und andererseits zwischen ihnen und der Systemumwelt besteht.

34

In den Sozialwissenschaften werden soziale Systeme, die nach diesem Verständnis als offen zu klassifizieren sind, teilweise als geschlossen verstanden. Strömungen, die diese Sicht vertreten, gehen davon aus, dass die Wahrnehmung und Interpretation der Systemumwelt durch die das soziale System konstituierenden Individuen konstruiert werden, also keine wirkliche Interaktion mit der Systemumwelt stattfindet. Als Vertreter dieser Sicht ist NIKLAS LUHMANN hervorzuheben. Die Luhmann’sche Systemtheorie - in Abgrenzung zur allgemeinen Systemtheorie VON BERTALANFFYs – kann als eine der populärsten im deutschen Sprachraum, nicht nur in der Soziologie, sondern u. a. auch in der Theorie des Managements betrachtet werden. 35 Vgl. [Schulte05].

24

2 Bezugsrahmen und Grundlagen

Systemumwelt

Umweltelement

Umweltelement

System Umweltelement

Systemelement

Zweck Interaktionsbeziehung

Systemelement

Systemelement … …

Umweltelement

Abbildung 15: System in der Systemtheorie Ein Grundgedanke der von Systemtheorie und Kybernetik36 ausgehenden Managementansätze besteht darin, das Systemdenken auf das Verständnis eines Unternehmens zu übertragen, das Gesamtsystem in Teilsysteme zu strukturieren und auf diese Weise die Lenkung und Steuerung des komplexen Systems Unternehmen zu ermöglichen.37 In diesen Managementansätzen werden Organisationen als offene, dynamische und komplexe Systeme verstanden, die einem permanenten Wandel und einer Eigendynamik unterliegen und zweckorientiert sind.38 Auf der Grundlage dieser Ausführungen sowie der auf SCHULTEZURHAUSEN39 basierenden Überlegungen von FISCHER40 wird in der vorliegenden Arbeit der Begriff des Unternehmens folgendermaßen definiert: Definition – Unternehmen Ein Unternehmen ist ein offenes, dynamisches und komplexes soziotechnisches System, das darauf zielt, die Transformation von Input (Rohstoffe, Information, …) aus seiner Umwelt in Output an seine Umwelt (Produkte, Dienstleistungen, Information, …) durchzuführen. 36 Kybernetik wird als die Wissenschaft von der Steuerung und Regelung von Systemen bezeichnet, die das Systemverhalten und die Systemstrukturen auf grundlegende Steuerungs- und Regelungsmechanismen zurückführt; vgl. [Schulte05]. MALIK versteht Kybernetik allgemeiner als die Wissenschaft vom Funktionieren von Systemen; vgl. [Malik08]. 37 HANS ULRICH gilt im deutschen Sprachbereich als Begründer der systemorientierten Managementlehre. Mit seinem 1968 erschienenen Hauptwerk Die Unternehmung als produktives soziales System ([Ulrich70]) begründete er eine neue Richtung in der betriebswirtschaftlichen Forschung und Lehre, die sich in mehrfacher Beziehung von der klassischen Betriebswirtschaftslehre unterscheidet. Grundlegend ist die Abstützung auf Erkenntnisse von Systemtheorie und Kybernetik. Auf dieser Basis entwickelte ULRICH mehrdimensionale Modelle der Unternehmung und der Unternehmungsführung. Die Grundzüge dieses Begriffsgerüstes wurden 1972 als St. Galler Management-Modell publiziert. 38 Vgl. [Malik04]. 39 Vgl. [Schulte05]. 40 Vgl. [Fischer08].

25

2.1 Die Unternehmens-IT als komplexes Teilsystem des Unternehmens

Unternehmensumwelt

Unternehmen Geschäftszweck Input

Transformation

Output

Abbildung 16: Interaktion mit der Unternehmensumwelt und Transformation – das Unternehmen als System Die Dynamik von offenen Systemen äußert sich wie o. a. in der Vielfalt der Interaktionsbeziehungen des Systems mit seiner Umwelt. Kennzeichnend für die Interaktion mit der Umwelt ist die Transformation von Input aus der Umwelt in Output an die Umwelt, wobei sich die Komplexität des Systems aus den Wechselwirkungen zwischen den Elementen des Systems und der Systemumwelt ergibt. Dies ist ausgehend von Abbildung 16 in Abbildung 17 dargestellt. Unternehmensumwelt

Unternehmen als System Geschäftszweck Umweltelement

Umweltelement

…

Input

Input Input

Systemelement Schnittstelle

Output Schnittstelle

Output

Umweltelement

Output

Umweltelement

Teilsystem Systemelement

Schnittstelle

Systemelement Systemelement

…

Umweltelement

Systemelement

Schnittstelle

Schnittstelle …

Systemelement

… Transformation

Abbildung 17: Das Unternehmen als offenes, komplexes System Auf der Grundlage dieses Verständnisses des Unternehmens wird die Abgrenzung des Begriffes der Unternehmens-IT vorgenommen. Dazu wird zunächst auf die Bedeutung von Aufgaben, Aufgabenträgern und Automatisierung eingegangen. Davon ausgehend können einerseits die Teilsysteme und die Elemente identifiziert werden, die das komplexe Teilsystem Unternehmens-IT ausmachen, andererseits lässt sich die Definition der Unternehmens-IT aufstellen. Die Erbringung der Transformationsleistung des komplexen Systems Unternehmen wird durch die Durchführung von Aufgaben durch interagierende

26

2 Bezugsrahmen und Grundlagen

Elemente des Systems gewährleistet. Systemelemente, die Aufgaben erbringen, werden im Sinne von FERSTL UND SINZ41 als Aufgabenträger bezeichnet. Aufgaben können manuell, teilautomatisiert oder vollautomatisiert durchgeführt werden. Dabei interagieren personelle und maschinelle Aufgabenträger. Im Falle manuell durchgeführter Aufgaben interagieren ausschließlich personelle Aufgabenträger. JUNG42 unterscheidet ausgehend von FERSTL UND SINZ zwischen Anwendungen und Kommunikationssystemen als maschinelle Aufgabenträger. Aufgabenträger kommunizieren bei der Aufgabendurchführung über Kommunikationskanäle, die von Kommunikationssystemen bereitgestellt werden. Dabei wird Information unter Nutzung des Kommunikationskanals über das Kommunikationssystem ausgetauscht. Dieser Zusammenhang wird in der folgenden Abbildung zusammengefasst.

Aufgabenträger

Info

KommunikationsSystem

Info

Aufgabenträger

Kommunikationskanal

Abbildung 18: Kommunikationssystem als Aufgabenträger Demgegenüber versteht man unter Anwendungen43 maschinelle Aufgabenträger, die Anwendungssoftware zur Durchführung fachlicher Aufgaben bereitstellen. Anwendung Info

Anwendungssoftware

Info

Laufzeitumgebung HardwareSystem

HardwareSystem

…

Abbildung 19: Anwendung als Aufgabenträger

41

Vgl. [FerSin01]. Vgl. [Jung06]. FERSTL und SINZ sprechen von Anwendungssystemen, JUNG kurz von Anwendungen, andere Autoren von IT-Systemen.

42 43

2.1 Die Unternehmens-IT als komplexes Teilsystem des Unternehmens

27

Die Anwendungssoftware nutzt eine Laufzeitumgebung, die durch Systemsoftware bereitgestellt wird, die ihrerseits auf Hardwaresystemen ausgeführt wird. Die Aufgabe von Anwendungen besteht in der Transformation von InputInformation in Output-Information. Darüber hinaus betrachten FERSTL UND SINZ einen weiteren Typ des maschinellen Aufgabenträgers - maschinelle Aufgabenträger, die „Nicht-Information“ verarbeiten; hierunter fallen zum Beispiel Transportsysteme. Dieser Aufgabenträgertyp wird in der vorliegenden Arbeit nicht betrachtet. Bedingt durch die technische Entwicklung ist die Grenze zwischen Kommunikationssystemen und Anwendungen in zunehmendem Maße fließend: Beide zeichnen sich als maschinelle Aufgabenträger aus, deren Aufgabe darin besteht, Information zu verarbeiten; Erstere zum Zwecke der Kommunikation, Letztere zum Zwecke der Bereitstellung einer fachlichen Funktionalität. Da diese Zweckdefinitionen nach Erfahrung des Autors der vorliegenden Arbeit zunehmend verschwimmen44, wird in der weiteren Ausarbeitung auf die Unterscheidung verzichtet und von einem IT-System gesprochen. Ausgehend von diesen Überlegungen wird folgende grundlegende Definition vorgenommen: Definition – IT-System Ein IT-System ist ein maschineller Aufgabenträger, der sich aus einer Menge von Softwarebausteinen konstituiert. Die Softwarebausteine verarbeiten Information zum Zwecke der Kommunikation oder zur Bereitstellung fachlicher Funktionalität, um auf diese Weise die durch das Unternehmen erbrachte Transformationsleistung zu unterstützen. Die Softwarebausteine operieren innerhalb einer Laufzeitumgebung, die durch Hardwaresysteme unter Nutzung von Systemsoftware bereitgestellt wird. Von außen betrachtet, handelt es sich bei einem IT-System um eine abgegrenzte, wohldefinierte Menge von Bausteinen, die über Schnittstellen mit der Außenwelt kommunizieren und deren Abgrenzung von der Umwelt sich aus dem immanenten Zweck und den Interaktionsmustern der Bausteine untereinander und mit der Laufzeitumgebung ergibt. Im Sinne der Systemtheorie liegt ein offe44 Als Beispiel sei hier ein Dialer als Teil eines operativen CRM-Systems aufgeführt. Ein Dialer wird auf der Basis definierter Kampagnen mit Kundendaten gefüttert, die er dann automatisiert verarbeitet. Dabei baut dieses System auf Basis der eingespeisten Kommunikationsinformationen automatisch Telefonverbindungen zu potenziellen Kunden auf – nutzt also den Kommunikationskanal Telefon. Hebt der automatisch angewählte Kunde ab, wird durch den Dialer die Kommunikation mit einem Call Center Agent initiiert. Der Agent erhält die Basiskundendaten vom Dialer zur Anzeige auf den Bildschirm. Der Dialer fungiert als maschineller Aufgabenträger - als Kommunikationssystem und als Anwendung.

28

2 Bezugsrahmen und Grundlagen

nes Teilsystem im Unternehmen vor. Im Falle des bereits im ersten Kapitel zitierten Beispiels der SEB GRUPPE umfasst das System IT-Landschaft rund 1500 Teilsysteme, die als maschineller Aufgabenträger vom Typ IT-System agieren, um die Transformationsleistung dieses Finanzdienstleisters zu unterstützen. In der folgenden Abbildung wird das der vorliegenden Arbeit zugrunde liegende Verständnis von IT-Systemen zusammengefasst und der Fokus der Arbeit abgegrenzt. Unternehmen Transformation

Input

Output

Fokus

unterstützt durch

Aufgabe ist

teilautomatisiert vollautomatisiert

wird durchgeführt

Aufgabenträger ist

Person maschinell ist

IT-System ist

KommunikationsSystem Anwendung

nicht automatisiert

„Nicht-Info“verarbeitend

Abbildung 20: Begriffsabgrenzung IT-System und Fokussierung der Arbeit Auf der Grundlage dieser systemtheoretischen geprägten Definition von ITSystemen, die dem Zweck der Unterstützung der Transformationsleistung des Unternehmens dienen, ergibt sich ein vervollständigtes Bild zur Abgrenzung von IT-Systemen und der zugrunde liegenden IT-Basisinfrastruktur45. Dies ist in Abbildung 21 zusammengefasst.46

45 Alle Hardwaresysteme einschließlich Netze, Router etc. sowie Systemsoftware, die das infrastrukturelle Fundament der IT-Systeme bilden. 46 Zur Abgrenzung dieses Verständnisses zu dem von FERSTL UND SINZ siehe Abschnitt 2.1.2.

29

2.1 Die Unternehmens-IT als komplexes Teilsystem des Unternehmens

ƒ ƒ ƒ ƒ ƒ

Aufgabenträger unterstützen die für die Transformationsleistung des Unternehmens notwendigen Aufgaben47. IT-Systeme übernehmen die Rolle eines Aufgabenträgers im Rahmen von teil- und vollautomatisierten Aufgaben. Im Falle teilautomatisierter Aufgaben interagieren IT-Systeme mit Personen und anderen IT-Systemen. Im Rahmen der Interaktionen wird Information als Input bzw. Output ausgetauscht. Hardwaresysteme und Systemsoftware übernehmen gegenüber IT-Systemen die Rolle eines Aufgabenträgers, der die Laufzeitumgebung bereitstellt. Hardwaresysteme und Systemsoftware werden im Sinne dieses Rollenverständnisses als Basissysteme bezeichnet.

Aufgaben

Unternehmensumwelt Aufgabe (voll automatisiert)

…

Aufgabe

Aufgabe

(teilautomatisiert)

(nicht automatisiert)

Aufgabenträger

Aufgabe

IS

…

IS

IT-Basisinfrastruktur

Aufgabe

(voll automatisiert)

(nicht automatisiert)

Info

Person 2

BS

Person 3

IS

IS

IS

IS 2

BS

Laufzeitumgebung IS 1 und IS 2

BS

Aufgabe

…

Person 1

IS 1

(teilautomatisiert)

…

IS

Person 4

BS

BS

BS

BS

BS

BS IS = IT-System BS = Basissystem

Abbildung 21: IT-Systeme als Aufgabenträger im Unternehmen48 47 Dem liegt für die vorliegende Arbeit das Verständnis zugrunden, dass diese Aufgaben im Rahmen der Durchführung von Geschäftsprozessen bearbeitet werden und IT-Systeme diese Bearbeitung unterstützen. Häufig wird in Arbeiten aus Forschung und Praxis in diesem Zusammenhang von Aktivitäten gesprochen, die innerhalb von Geschäftsprozessen durchgeführt werden.

30

2 Bezugsrahmen und Grundlagen

Auf Basis der systemtheoretischen Positionierung von IT-Systemen folgt das für diese Arbeit fundamentale Verständnis der IT-Landschaft im Sinne eines komplexen Teilsystems des Unternehmens. Die Systemelemente der IT-Landschaft sind IT-Systeme und das sich aus Basissystemen konstituierende Teilsystem der IT-Basisinfrastruktur. Die immanente Struktur der IT-Landschaft ergibt sich aus den Interaktionen der IT-Systeme bei der Informationsverarbeitung. Wesentlich für die Definition des Begriffes der IT-Landschaft ist die Festlegung des Verständnisses des Begriffes Informationsbedarf. Für die vorliegende Arbeit wird die Definition von JUNG49 übernommen: Definition – Informationsbedarf Der Informationsbedarf bezeichnet die für die Aufgabenausführung eines menschlichen Aufgabenträgers erforderliche Menge von Informationsobjekten und deren Qualität. Dabei kann die Spezifizierung der Informationsobjekte auf Typ- oder Instanzebene durchgeführt werden. Damit kann der Begriff der IT-Landschaft definiert werden. Abbildung 22 fasst die Definition zusammen. Definition - IT-Landschaft Die IT-Landschaft eines Unternehmens ist die Gesamtheit aller ITSysteme, die als maschinelle Aufgabenträger die Transformationsleistung des Unternehmens durch die Verarbeitung50 von Information übernehmen, um den Informationsbedarf der menschlichen Aufgabenträger des Unternehmens zu befriedigen. Die IT-Landschaft umfasst ƒ die durch die enthaltenen Systeme durchgeführten Informationstransformationsaufgaben, ƒ Informationsflüsse zwischen den Elementen der IT-Landschaft, ƒ Informationsflüsse zu/von außerhalb der IT-Landschaft angesiedelter IT-Systeme, ƒ die zugrunde liegende IT-Basisinfrastruktur und die sie konstituierenden Basissysteme.

48

in Anlehnung an [FerSin01], S. 2. Vgl. [Jung06], S. 51. JUNG analysiert auf der Grundlage dieser Definition umfassend die Dimensionen, die bei der Analyse von Informationsbedarfen zu berücksichtigen sind (S. 101 ff.). 50 Hierbei handelt es sich im Sinne des systemtheoretischen Ansatzes von FERSTL UND SINZ um die der IT-Landschaft zugeordneten Aufgaben. 49

31

2.1 Die Unternehmens-IT als komplexes Teilsystem des Unternehmens

Unternehmen als komplexes System Geschäftszweck des Unternehmens IT-Landschaft als komplexes Teilsystem IS

Schnittstelle

…

IS

IS

BS

Information

Schnittstelle

Information

Schnittstelle

IS

Schnittstelle Schnittstelle …

BS

Transformation

Abbildung 22: Die IT-Landschaft als komplexes Teilsystem im Unternehmen Extern betriebene IT-Systeme sind nach dieser Definition Teil der ITLandschaft des Unternehmens. Gleiches gilt etwa für externe Marktplätze, die Mitarbeiter des Unternehmens bei der Aufgabendurchführung nutzen. Ein Beispiel hierfür sind externe Baufinanzierungsplattformen, die von Bankmitarbeitern genutzt werden, um den bankspezifischen Baufinanzierungsangebots/Antragsprozess durchzuführen. Wird hingegen im Rahmen eines SourcingProjektes ein vollständiger Geschäftsprozess ausgelagert und auf die IT-Systeme des Sourcing-Partners transferiert, so sind diese Systeme nach diesem Verständnis nicht Bestandteil der IT-Landschaft des Unternehmens. Die Informationsflüsse zu/von diesen Systemen sind hingegen Teil der IT-Landschaft. Als Beispiel kann hier die Verlagerung des Wertpapierabwicklungsprozesses einer RetailBank zu einer Wertpapierabwicklungsbank genannt werden. Das Depotführungssystem der Wertpapierabwicklungsbank ist nicht Bestandteil der IT-Landschaft des auslagernden Instituts, Informationsflüsse zwischen der E-Banking-Plattform der Retail-Bank und dem Depotführungssystem sind hingegen Bestandteil der IT-Landschaft. Zusammenfassend kann festgehalten werden, dass extern betriebene Systeme als Teil der IT-Landschaft verstanden werden, wenn sie unternehmensinterne Prozesse unterstützen. Systeme, die einen ausgelagerten Geschäftsprozess unterstützen, sind nicht Bestandteil der IT-Landschaft, Informationsflüsse zu bzw. von diesem System hingegen sehr wohl.

32

2 Bezugsrahmen und Grundlagen

Der Zweck der IT-Landschaft besteht in der Befriedigung des Informationsbedarfs von menschlichen Aufgabenträgern des Unternehmens. Informationsbedarfe von Umweltelementen des Unternehmens – zum Beispiel Aufsichtsbehörden – sind nach diesem Verständnis nicht unmittelbar zweckbestimmend für die IT-Landschaft. Solche unternehmensextern verursachten Informationsbedarfe werden von unternehmensinternen Aufgabenträgern in Informationsbedarfe überführt, die von der IT-Landschaft zu befriedigen sind. Ein Beispiel verdeutlicht dieses Verständnis: In einem Kreditinstitut übersetzen Organisationseinheiten des Meldewesens den Informationsbedarf von Umweltelementen, hier z. B. der Bundesbank, in Informationsbedarfe, die durch dafür vorgesehene ITSysteme zu befriedigen sind. Ausgehend von Abbildung 21 visualisiert die folgende Abbildung die Definition des Begriffes IT-Landschaft im Rahmen der Festlegung des begrifflichen Fundamentes der vorliegenden Arbeit. Aufgaben

Unternehmensumwelt Aufgabe

…

Aufgabe

…

(voll automatisiert)

(teilautomatisiert)

…

Aufgabe

Aufgabe

Aufgabe

Aufgabe

(teilautomatisiert)

(nicht automatisiert)

(voll automatisiert)

(nicht automatisiert)

Aufgabenträger

IS

IS

…

Person 1

IS 1

IT-Basisinfrastruktur

Person 2

Laufzeitumgebung IS 1 und IS 2 BS

IS

IS

IS

IS 2

BS

BS

BS

Person 3

Info

IS

Person

BS

BS

BS

BS

BS IS = IT-System BS= Basissystem

Abbildung 23: Elemente des komplexen Systems IT-Landschaft

2.1 Die Unternehmens-IT als komplexes Teilsystem des Unternehmens

33

2.1.2 Vervollständigung der Begriffswelt zur Unternehmens-IT Im Rahmen der Definition der Begriffswelt der vorliegenden Arbeit wird auch der Bereich der technischen Infrastruktur adressiert. In der Begriffswelt, wie sie von FERSTL UND SINZ verwendet wird, bleibt unscharf, wie die den Anwendungs- und Kommunikationssystemen zugrunde liegende technische Infrastruktur aus systemtheoretischer Sicht zu sehen ist. Hardwaresysteme und Systemsoftware werden bei FERSTL UND SINZ als Teil der Anwendungs- bzw. Kommunikationssysteme betrachtet51. Damit ist noch nicht definiert, wie die Gesamtheit aller Hardwaresysteme und der Systemsoftware begrifflich gefasst wird, die das infrastrukturelle Fundament der Anwendungs- und Kommunikationssysteme bilden. In dieser Arbeit wird diese Gesamtheit als Teilsystem der IT-Landschaft verstanden und mit dem Begriff IT-Basisinfrastruktur erfasst. Definition - IT-Basisinfrastruktur Die IT-Basisinfrastruktur bildet das infrastrukturelle Fundament der IT-Landschaft eines Unternehmens. Die IT-Basisinfrastruktur ist die Menge aller Basissysteme, das sind Hardwaresysteme (einschließlich Rechner, Netze, Router etc.) und Systemsoftwaresysteme (Betriebssysteme, Datenbankmanagementsysteme, Middleware, Firewall-Systeme, …), sowie aller für die Entwicklung und den Betrieb von IT-Systemen notwendigen Werkzeuge (Entwicklungswerkzeuge, Überwachungswerkzeuge, …). Die IT-Basisinfrastruktur bildet ein Teilsystem der ITLandschaft. In der Unternehmenspraxis werden heute allgemein Begriffe wie die IT oder die Unternehmens-IT verwendet, wenn eine umfassende, über das Verständnis des Begriffes der IT-Landschaft hinausgehende Sicht gemeint ist. Dieses Verständnis umfasst zum einen die IT-Landschaft des Unternehmens, wie für die vorliegende Arbeit definiert wird, und zum anderen die Personen und Prozesse, die die Planung, die Steuerung, die Weiterentwicklung oder den Betrieb der Elemente der IT-Landschaft in den Mittelpunkt stellen. Hierfür wird in der Regel der Begriff IT-Organisation verwendet, wobei im Einzelfall die funktionale oder die hierarchisch-aufbauorganisatorische Sicht gemeint sein kann und unklar ist, ob Personen, die aufbauorganisatorisch auf Geschäftsseite angesiedelt sind und Aufgaben im Bereich der Planung und Steuerung der IT-Landschaft übernehmen, als Teil der IT-Organisation anzusehen sind.

51

Vgl. [FerSin01], S. 3.

34

2 Bezugsrahmen und Grundlagen

Dem steht die Anwenderorganisation52 gegenüber, deren Mitglieder ITSysteme bei der Durchführung fachlicher Aufgaben nutzen. Als Teil des Bezugsrahmens dieser Arbeit wird hier die Begrifflichkeit geschärft. Nach dem Verständnis der vorliegenden Arbeit sind die funktionale und die hierarchischaufbauorganisatorische Sicht im Begriff der IT-Organisation eingeschlossen. Es ergibt sich die folgende Definition. Definition - IT-Organisation und Anwenderorganisation Die IT-Organisation ist das komplexe, offene Teilsystem des Unternehmens, welches die Gesamtheit aller nicht-maschinellen Aufgabenträger umfasst, die die Planung, die Steuerung, die Entwicklung oder den Betrieb der Elemente der IT-Landschaft durchführen.53 Die im Zeitablauf relativ konstanten hierarchisch-aufbauorganisatorischen Beziehungsmuster sind Bestandteil der IT-Organisation. Komplementär zur IT-Organisation ist das komplexe, offene Teilsystem der Anwenderorganisation. Es handelt sich hier um die Gesamtheit der Aufgaben (Prozesse) und menschlichen Aufgabenträger, die IT-Systeme zur Durchführung auf den Geschäftszweck ausgerichteter Aufgaben nutzen. Nach diesem Verständnis sind Personen54, die Aufgaben der Bedarfserhebung, der Planung oder der Steuerung von Elementen der IT-Landschaft übernehmen, aufbauorganisatorisch jedoch auf Geschäftsseite angesiedelt sind, auch Bestandteil des Teilsystems der IT-Organisation. Ist beispielsweise eine Organisationseinheit Business Information Management55 im aufbauorganisatorischen Sinne auf Geschäftsseite angesiedelt, so ist diese Einheit nach dem Verständnis der vorliegenden Arbeit ebenfalls Bestandteil der IT-Organisation. Somit bilden in der Begriffswelt der vorliegenden Arbeit die IT-Landschaft und die ITOrganisation Teilsysteme der Unternehmens-IT. Zwischen den Teilsystemen ITLandschaft bzw. IT-Organisation und der Anwenderorganisation bestehen Interaktionsbeziehungen, z. B.:

52

In der Praxis werden hierfür häufig unscharfe Begriffe wie das Business oder der Fachbereich verwendet. 53 Im Sinne des Verständnisses von FERSTL UND SINZ entsprechen Planung, Steuerung, Entwicklung und Betrieb den Aufgaben, welche durch die personellen Aufgabenträger durchgeführt werden. 54 Fachseite im Sinne einer aufbauorganisatorischen Sicht. 55 Das Business Information Management ist verantwortlich für die Sicherstellung der Fähigkeit der IT-Landschaft zur Befriedigung des Informationsbedarfs ihrer Nutzer und übernimmt dabei die Rolle des Systeminhabers, der die IT-Landschaft hinsichtlich fachlicher und finanzieller Rahmensetzung verantwortet; in Anlehnung an [vdPols07].

2.1 Die Unternehmens-IT als komplexes Teilsystem des Unternehmens

ƒ

ƒ

35

Das zum Teilsystem IT-Organisation eines Versicherungsunternehmen gehörende Systemelement BIM (Business Information Management) interagiert im Rahmen der strategischen Informationsbedarfserhebung mit dem Element SBP (Strategische Business-Planung) des Teilsystems Anwenderorganisation der Versicherung. Die Systemelemente (e. g. Versicherungsagenturen) des Teilsystems Anwenderorganisation interagieren im Rahmen einer Nutzungsbeziehung mit den Systemelementen der IT-Landschaft der Versicherung (e. g. dem Agentursystem der Versicherung).

Auf der Grundlage der diskutierten Begriffswelt ergibt sich folgende Definition: Definition - Unternehmens-IT Die Unternehmens-IT ist das komplexe, offene Teilsystem des Unternehmens, welches sich aus den komplexen, offenen Teilsystemen ITLandschaft und IT-Organisation konstituiert und der effizienten Befriedigung des Informationsbedarfs der außerhalb der Unternehmens-IT angesiedelten menschlichen Aufgabenträger des Unternehmens dient. Abbildung 24 fasst dieses Verständnis des Systems Unternehmens-IT zusammen und greift zur Verdeutlichung das o. a. Beispiel aus der Versicherungswirtschaft – hervorgehoben sind die Systemelemente Agenturen, Business Information Management (BIM) und Strategische Business-Planung (SBP) – auf.

36

2 Bezugsrahmen und Grundlagen

Unternehmen als komplexes System Geschäftszweck

Teilsystem Anwenderorganisation

Agentur Agentur

Schnittstelle

SBP

Agentur

Schnittstelle Schnittstelle

Teilsystem IT-Landschaft

Teilsystem IT-Organisation

Schnittstelle

BIM

Schnittstelle

…

…

Zweck: Informationstransformation

Zweck: Planung/Steuerung/ Weiterentwicklung/Betrieb

Zweck: Effiziente Befriedigung Informationsbedarf

Teilsystem Unternehmens-IT Transformation

Abbildung 24: IT-Landschaft und IT-Organisation als Teilsysteme der Unternehmens-IT Diese Zweckdefinition der Teilsysteme IT-Landschaft und IT-Organisation wird am Beispiel der Informationstransformationsaufgaben im Umfeld der Anlageprozesse in der Finanzindustrie verdeutlicht werden. Abbildung 25 zeigt dazu das Rollennetzwerk, das bei der Durchführung von Anlageprozessen für Bankkunden – z. B. bei Erteilung und Durchführung einer Wertpapierorder – beteiligt ist, und die dabei auftretenden Informationsflüsse.56 Der Begriff Rollennetzwerk ist hier so zu verstehen, dass bei der Prozessdurchführung ein Netzwerk aus verschiedenen Rollen interagiert, um den Anlageauftrag des Kunden durchzuführen. Die Rollen werden von verschiedenen Unternehmen und Institutionen wahrgenommen. Für die mit dem Kunden interagierende Bank stellt sich die Frage, welche Rollen die Bank selbst und welche Partner der Bank wahrnehmen sollten, um die Wettbewerbsposition und die Ziele der Bank bestmöglich zu unterstützen. Die Interaktionen dieser Rollen zur Ausführung des Kundenauftrages bedingen Geldflüsse und Titelflüsse sowie Informationsflüsse. Der Zweck der IT56

Entnommen und angepasst aus [AlBeZe09].

2.1 Die Unternehmens-IT als komplexes Teilsystem des Unternehmens

37

Landschaft der Bank des Kunden besteht in der maschinellen Unterstützung der Informationstransformation entlang der dargestellten Informationsflüsse. Wie weit diese Zweckbestimmung einer IT-Landschaft innerhalb des hier dargestellten Netzwerkes geht, hängt davon ab, welche Rollen das jeweils im Fokus stehende Unternehmen innerhalb dieses Netzwerkes einnimmt. Konzentriert sich der Finanzdienstleister beispielsweise auf die Rolle der Vertriebsbank, so ergibt sich daraus die Zweckbestimmung der IT-Landschaft dieser Vertriebsbank.

Geld-/Titelfluss

Marktdaten

Depotstellenabgleich

Marktdaten

Abwickler

Broker Broker

Depotstellenabgleich

Geldfluss

ZentralValorendaten verwahrer Provider (CSD)

ZentralZentralverwahrer verwahrer (CSD)

Zentralbank

(Geldseite)

Clearing

Broker Börsenplatz

Bestätigung / Status Auftrag

Bestätigung / Status

Titelfluss

DepotBroker führende Stelle

Settlement-Instruktion

Abbildung 25: Informationsflüsse im Rollennetzwerk bei Anlageprozessen

Legende

Informationsfluss

Auftrag Ausführungsbestätigung

Auftrag

Bestätigung/ Status

Vertriebsbank

Händler / Execution Desk Bestätigung

Bankkunde

Auftrag

Geldfluss

Geldfluss

Auftrag

Marktdaten

Bestätigung / Status

38 2 Bezugsrahmen und Grundlagen

Geldfluss

2.1 Die Unternehmens-IT als komplexes Teilsystem des Unternehmens

39

2.1.3 Reflexion der Begriffswelt zur Unternehmens-IT Nach dem Verständnis der wissenschaftlichen Kommission der Wirtschaftsinformation57 sind Informationssysteme soziotechnische („Mensch-Maschinen-“) Systeme, die menschliche und maschinelle Komponenten (Teilsysteme) umfassen und mit dem Ziel der optimalen Bereitstellung von Informationen und Kommunikation nach wirtschaftlichen Kriterien eingesetzt werden. Mit der Definition der wissenschaftlichen Kommission ist noch nicht die Frage beantwortet, ob der Begriff Informationssystem im Sinne des „einen“ Informationssystems des Unternehmens zu verstehen ist - wie es FERSTL UND SINZ vorschlagen - oder ob damit einzelne Anwendungen bzw. ein einzelnes Kommunikationssysteme gemeint sind. KRCMAR58 führt aus, dass in der Organisationstheorie üblicherweise von dem einen Informationssystem des Unternehmens gesprochen werde – auf dieser Linie liegen zum Beispiel FERSTL UND SINZ sowie JUNG -, während in der Wirtschaftsinformatik im Plural von den Informationssystemen gesprochen werde, also mit Informationssystem das einzelne Anwendungs- oder Kommunikationssystem gemeint sei. KRCMAR folgt dem letztgenannten Verständnis. Insgesamt zeigt sich in der dargelegten homonymen Verwendung des Begriffes Informationssystem durch führende Vertreter aus Forschung und Lehre in der Wirtschaftsinformatik eine begriffliche Unschärfe, die in der in Abschnitt 2.1.1 entwickelten Begriffswelt beseitigt ist: ƒ ƒ

ƒ

57 58

In der vorliegenden Arbeit wird IT-System anstelle des Begriffes Informationssystem im Sinne des Verständnisses von KRCMAR, also als Oberbegriff für Anwendung bzw. Kommunikationssystem verwendet. Die umfassende Sicht wird durch den Begriff der Unternehmens-IT zum Ausdruck gebracht und entspricht der Verwendung des Begriffes Informationssystem durch FERSTL UND SINZ. Die IT-Landschaft als Subsystem der Unternehmens-IT konstituiert sich dabei aus maschinellen Aufgabenträgern. Informationsflüsse zu/von anderen IT-Systemen werden als Teil des Subsystems verstanden. Die IT-Organisation als Subsystem der UnternehmensIT konstituiert sich aus menschlichen Aufgabenträgern und deren Interaktionsbeziehungen. Die Verwendung des Begriffes IT-Landschaft erscheint aus Sicht des Autors der vorliegenden Arbeit für heutige große Unternehmen, die regelmäßig über eine vierstellige Zahl miteinander vernetzter Anwendungen und Kommunikationssysteme verfügen, treffender. Dies steht zudem nach Erfahrung Vgl. [WKWI94]. Vgl. [Krcmar05], S. 24 f.

40

ƒ

2 Bezugsrahmen und Grundlagen

des Autors der vorliegenden Arbeit im Einklang mit der in größeren Unternehmen üblichen Begriffswelt, die durch Begriffe wie IT-Landschaft, Anwendungslandschaft oder Systemlandschaft geprägt ist und in der Begriffe wie Informationssystem, IT-System, Anwendungssystem oder Anwendung auf die Einzelsicht bezogen sind. Die Verwendung des Begriffes Informationssystem im umfassenden Sinn ist nach den Erfahrungen des Autors in der Praxis zunehmend weniger verbreitet und wird daher durch den Begriff der Unternehmens-IT zum Ausdruck gebracht. Auf die Verwendung des Begriffes Informationssystem wird zur Vermeidung von Homonymen wie ausgeführt zugunsten der Begriffes IT-System verzichtet In Arbeiten aus Forschung und Praxis, die im Rahmen der vorliegenden Arbeit analysiert wurden, werden teilweise folgende Begriffe synonym zum Begriff der Unternehmens-IT verwendet: Enterprise Information System, Enterprise System, Unternehmensinformationssystem, Informationslogistik.

2.2 Begriffsbestimmung Integrationsmanagement Für das in der vorliegenden Arbeit im Mittelpunkt stehende Konzept zum ganzheitlichen Integrationsmanagement stellen sich aus begrifflich-definitorischer Sicht folgende Fragen: ƒ ƒ ƒ

Frage 1: Was sind die Objekte, die einem ganzheitlichen Integrationsmanagement unterliegen? Frage 2: Was bedeutet in diesem Kontext ganzheitlich? Frage 3: In welchem Verhältnis stehen Integrationsmanagement und ITManagement?

Im folgenden Abschnitt werden zunächst die ersten beiden Fragen beantwortet. Dazu wird auf die von MERTENS59 vorgeschlagene Systematik zur Einordnung von Integrationsfragestellungen und deren Interpretation durch JUNG60 zurückgegriffen. Im darauf folgenden Abschnitt wird dann das systemtheoretisch geprägte Verständnis des Begriffes IT-Management der vorliegenden Arbeit herausgearbeitet, um dann Frage 3 beantworten zu können.

59 60

Vgl. [Mertens05]. Vgl. [Jung06], S.45 ff.

2.2 Begriffsbestimmung Integrationsmanagement

41

2.2.1 Zum Spektrum des ganzheitlichen Integrationsmanagements Nach JUNGS Interpretation lassen sich die folgenden Dimensionen heranziehen, um Fragestellungen zur Integration im Umfeld der betrieblichen Informationsverarbeitung zu positionieren: ƒ ƒ ƒ ƒ

Integrationsperspektive Integrationsreichweite Integrationsgegenstand Automationsgrad

Diese Dimensionen werden im Folgenden verwendet, um den Bezugsrahmen der vorliegenden Arbeit weiter zu präzisieren. In Anlehnung an JUNG werden diese Dimensionen in der vorliegenden Arbeit folgendermaßen verstanden: ƒ ƒ

ƒ ƒ

Integrationsperspektive: Welche grundsätzliche Sichtweise wird bei der Integrationsfragestellung eingenommen (e. g. betriebswirtschaftlich, organisatorisch, technisch)? Integrationsreichweite: Welche „organisatorische Entfernung“ wird bei der Integration überwunden? Beziehen sich die betrachteten Integrationsprobleme auf die Sicht einer einzelnen Organisationseinheit im Unternehmen, auf die Sicht mehrerer Organisationseinheiten im Unternehmen oder auf die Sicht mehrerer Unternehmen? Integrationsgegenstand: Welche Elemente der zu integrierenden Systeme stehen innerhalb der angenommenen Integrationsreichweite im Mittelpunkt? Automationsgrad: In welchem Maß sind bei der Integration der betrachteten Systemelemente menschliche Aufgabenträger zu involvieren?

Mithilfe dieser begrifflichen Abgrenzung wird das Verständnis des ganzheitlichen Integrationsmanagements definiert; die vier Dimensionen des Integrationsspektrums werden für die vorliegende Arbeit wie folgt festgelegt: Integrationsperspektive Hier stellt sich zunächst die Frage, welche Klasse von Unternehmen betrachtet wird. Um diese Frage zu beantworten, wird das Konstrukt der Komplexitätsbarriere zurückgegriffen. Diese kann in Anlehnung an MALIK61 so verstanden werden, dass bei ihrem Überschreiten das betreffende System nicht mehr durch Einwirken auf die Detailebene, sondern nur durch Einwirken auf die Metaebene 61

Vgl. [Malik08], S. 75.

42

2 Bezugsrahmen und Grundlagen

gemanagt werden kann. Innerhalb der Integrationsperspektive der vorliegenden Arbeit liegen diejenigen Unternehmen, für die die Unternehmens-IT strategische Bedeutung besitzt und deren Unternehmens-IT oberhalb der Komplexitätsbarriere positioniert ist, das heißt, deren Unternehmens-IT so komplex ist, dass sie durch Einwirken auf die Metaebene gemanagt werden muss. Die Integrationsperspektive umfasst die Managementsicht, die operative Sicht, die organisatorische Sicht sowie die informationswirtschaftliche Sicht. Die operative Sicht findet Berücksichtigung, da geschäftliche Anforderungen im Teilsystem Anwenderorganisation entstehen und Integrationsanforderungen erzeugen, die durch die Unternehmens-IT erfüllt werden müssen. So folgt beispielsweise die Integration zuvor nicht integrierter IT-Landschaften der unternehmensübergreifenden Integration von Geschäftsprozessen im Rahmen von BPO-Initiativen (Business Process Outsourcing).62 Darüber hinaus umfasst die Integrationsperspektive die Desintegration, also die bewusste Entflechtung zuvor integrierter Systeme, wie z. B. die Desintegration von Teil-IT-Landschaften63. Bestandteil der Integrationsperspektive ist die Komplexität der betrachteten Unternehmens-IT und ihrer Teilsysteme IT-Landschaft und IT-Organisation (s. Integrationsgegenstand), da Komplexität ein wesentlicher Aspekt der in Abbildung 1 darstellten Problematik der Verschiebung von Aufwänden hin zu Integrationsaufwänden darstellt. Die technische Sicht – im Sinne des Einsatzes bestimmter IuK-Technologie – wird in der durch vorliegende Arbeit eingenommenen Integrationsperspektive nicht berücksichtigt. Zu einzelnen Informations- und Kommunikationstechnologien (IuK-Technologien), wie z. B. Web-Services und ihren Einsatzmöglichkeiten bei der Bearbeitung von Integrationsproblemen, existieren zahlreiche Arbeiten aus Forschung und Praxis. Integrationsreichweite Nach dem Verständnis der vorliegenden Arbeit umfasst Integrationsmanagement das System Unternehmens-IT als Teilsystem des Unternehmens einschließlich der Interaktionsbeziehungen zur Anwenderorganisation. Die Integrationsreichweite geht über die Unternehmens-IT eines einzelnen Unternehmens hinaus. Sie umfasst die Interaktionsbeziehungen zu den IT-Landschaften von Lieferanten, 62

Ein Beispiel ist das Outsourcing von Handelsabwicklungsprozessen in der Finanzindustrie zu Spezialinstituten wie der DWP Bank oder der Xchanging Transaction Bank. 63 Beispielsweise, wenn Teile eines Unternehmens verkauft werden. Auf der Seite des kaufenden Unternehmens erzeugt dies vielfältige Integrationsaktivitäten in der Unternehmens-IT. Dem stehen auf Seiten des verkaufenden Unternehmens Desintegrationsaktivitäten in der Unternehmens-IT gegenüber. Ein weiterer Fall der Desintegration ergibt sich aus der Verlagerung ganzer Geschäftsprozesse auf einen Sourcing-Partner mit einer eigenen, auf diese Prozesse spezialisierten IT-Landschaft.

43

2.2 Begriffsbestimmung Integrationsmanagement

Kunden sowie Behörden und öffentlichen Institutionen, mit denen das Unternehmen Interaktionsbeziehungen unterhält. Dies ergibt sich aus der für die vorliegende Arbeit vorgenommenen Definition des Begriffes Unternehmens-IT und aus der definierten Integrationsperspektive. Die folgende Abbildung veranschaulicht diese Festlegung der Integrationsreichweite. Steht Unternehmen U1 im Mittelpunkt der Betrachtung, so liegt der Fokus auf dem Teilsystem Unternehmens-IT von U1 einschließlich dessen Interaktionsbeziehungen zur Anwenderorganisation von U1. Die Interaktionsbeziehungen zur Unternehmens-IT U2 und U3 liegen innerhalb der Integrationsreichweite, wenn IT-Systeme dieser Unternehmen Informationstransformationsleistungen für U1 erbringen. Nach der für die vorliegenden Arbeit getroffenen Definition des Begriffes IT-Landschaft sind Informationsflüsse zu diesen ITSystemen von U2 und U3 und - je nach Art der Leistungserbringung - die betroffenen Systeme von U2 und U3 selbst Bestandteil der Unternehmens-IT. Interaktionsbeziehungen zwischen U2 und U3 liegen hingegen nicht in der Integrationsreichweite. Unternehmen U2 Teilsystem Anwenderorganisation

Unternehmen U1 Teilsystem Anwenderorganisation

Teilsystem IT-Landschaft

Teilsystem ITOrganisation

Teilsystem IT-Landschaft

Teilsystem ITOrganisation

Teilsystem Unternehmens-IT

Teilsystem Unternehmens-IT

Unternehmen U3 Teilsystem Anwenderorganisation

Teilsystem IT-Landschaft

Integrationsreichweite

Teilsystem ITOrganisation

Teilsystem Unternehmens-IT

Abbildung 26: Integrationsreichweite aus Sicht eines Unternehmens U1 Integrationsgegenstand Aus der festgelegten Integrationsreichweite ergeben sich folgende Systemelemente als Integrationsgegenstand des ganzheitlichen Integrationsmanagements jeweils aus Intra- und Interunternehmensperspektive:

44 ƒ

ƒ

ƒ

2 Bezugsrahmen und Grundlagen

Systemelemente der IT-Organisation, das sind: o Personelle Aufgabenträger, welche die Planung, die Steuerung, die Weiterentwicklung oder den Betrieb von IT-Systemen sowie der zugrunde liegenden IT-Basisinfrastruktur durchführen o Interaktionsbeziehungen zur Anwenderorganisation im Rahmen der Planung, der Steuerung, der Weiterentwicklung und des Betriebs der IT-Landschaft o Interaktionsbeziehungen zur Unternehmens-IT in der Unternehmenswelt Systemelemente der IT-Landschaft, d. h.: o Informationstransformationsaufgaben, die sie durchführenden ITSysteme, Bausteine der IT-Basisinfrastruktur und deren Interaktionsbeziehungen untereinander o Nutzungsbeziehungen zur Anwenderorganisation o Interaktionsbeziehungen zur Unternehmens-IT in der Unternehmenswelt Interaktionsbeziehungen zwischen der IT-Organisation und der IT-Landschaft bei der Planung, Steuerung, Weiterentwicklung und des Betriebs der IT-Landschaft

Automationsgrad Aus der Festlegung des Integrationsgegenstandes ergibt sich die Festlegung des Automationsgrades im Integrationsspektrum. Die Berücksichtigung nicht automatisierter Integration im Integrationsspektrum folgt aus den Interaktionsbeziehungen der Systemelemente der IT-Organisation. Die teil- sowie vollautomatisierte Integration hingegen folgt aus den Interaktionsbeziehungen der Elemente der IT-Landschaft zur Anwenderorganisation sowie untereinander. Zusammenfassend wird für das begriffliche Fundament dieser Arbeit festgehalten, dass ganzheitlich im Sinne der oben definierten Integrationsperspektive, der definierten Integrationsreichweite, des definierten Integrationsgegenstandes und des definierten Automationsgrades verstanden wird.64 2.2.2 Integrationsmanagement als Teildisziplin des IT-Managements Nach den Überlegungen zu Beginn von Kapitel 2 besteht ein Grundgedanke der von Systemtheorie und Kybernetik ausgehenden Managementansätze darin, das 64

In der weiteren Ausarbeitung wird das Adjektiv „ganzheitlich“ zur Vereinfachung weggelassen. Wenn von Integrationsmanagement gesprochen wird, ist ganzheitliches Integrationsmanagement im Sinne der hier vorgenommenen begrifflichen Abgrenzung gemeint.

2.2 Begriffsbestimmung Integrationsmanagement

45

Systemdenken auf das Verständnis von Unternehmen zu übertragen. Dies geschieht, indem das Unternehmen als System interagierender Teilsysteme verstanden wird und systemtheoretisch geprägte Managementprinzipien auf die Teilsysteme, deren Elemente und deren Zusammenspiel angewandt werden. Die Steuerung des komplexen Systems Unternehmen erfolgt entlang dieser Systemstruktur, die sich aus den Interaktionsmustern der beteiligten Systemelemente ergibt. Nach diesem Verständnis ist das Management des Teilsystems Unternehmens-IT - welches das Management der Teilsysteme IT-Organisation und ITLandschaft umfasst - Teil des Managements des Gesamtsystems Unternehmen. Im Mittelpunkt des Systemansatzes von MALIK65 steht die Fähigkeit von Systemen zur Selbstorganisation. Als Selbstorganisation wird die Fähigkeit eines Systems verstanden, durch selbstständige strukturelle Evolution und Differenzierung das Komplexitäts- und Organisationsniveau in Bezug auf die Veränderungen der Systemumwelt zu optimieren. Die Fähigkeit zur Selbstorganisation stellt aus Maliks Sicht für komplexe Systeme - wie größere Unternehmen - die einzige Möglichkeit dar, die Komplexität und Dynamik sowohl der internen Strukturen als auch der Einflüsse der Systemumwelt zu bewältigen. Dies ist deshalb der Fall, weil Selbstorganisation eine erheblich höhere Reaktionsfähigkeit erzeugt, als dies in einer Befehlshierarchie der Fall sein kann. Durch die in selbstorganisierenden Systemen ablaufenden Prozesse entsteht nach PROBST66 eine Eigendynamik, die die Lebensfähigkeit des Systems Unternehmen garantiert. Das Verständnis des Begriffes Lebensfähigkeit größerer Unternehmen folgt in der vorliegenden Arbeit der Definition von MALIK. Ein komplexes System ist dann lebensfähig, wenn die spezifische Zustandskonfiguration, in der sich ein System bei einer gegebenen Umweltsituation befindet, auf unbestimmte Zeit aufrechterhalten werden kann. Die Lebensfähigkeit von Unternehmen beruht dabei nach MALIK auf zwei Grundlagen: einer flexiblen und anpassungsfähigen Struktur67 sowie einer intelligenten und immer wieder neu zu adaptierenden strategischen Konzeption. Daraus ergeben sich für MALIK zentrale Aspekte für das Management und die strategische Konzeption von Unternehmen. Wesentlich ist hier die Erkenntnis, dass die Fähigkeit des Unternehmens zur Selbstorganisation nicht so weit entwickelt werden kann, dass ein größeres Unternehmen ohne ein gewisses Maß an Planung und Steuerung und damit verbundenen korrigierenden Eingriffen auskäme. Diese Eingriffe finden jedoch nicht auf der Objektebene, sondern auf der Metasystemebene statt. Die Eingriffe mani65

Vgl. [Malik08]. Vgl. [Probst87], S. 69. 67 MALIKs auf BEERs (vgl. [Beer95]) Modell des lebensfähigen Systems aufbauende ManagementKybernetik zeigt auf, dass jedes System, dass sich als lebensfähig erwiesen hat, eine immanente, invariante Grundstruktur besitzt. Sie wird als Struktur lebensfähiger Systeme bezeichnet. 66

46

2 Bezugsrahmen und Grundlagen

festieren sich erstens in Leitlinien und Verhaltensvorgaben - die darauf zielen, die mit der Selbstorganisation verbundene, notwendige Autonomie von Teilsystemen, z. B. Geschäftsdivisionen, zur Gewährleistung der Lebensfähigkeit des Gesamtunternehmens einzuschränken, diese Einschränkung jedoch möglichst gering zu halten - und zweitens in der übergreifend gesteuerten Zuteilung von Ressourcen an Teilsysteme. MALIK überführt die Kenntnis der wesentlichen Systemeigenschaften Komplexität und Dynamik sowie die Unmöglichkeit, Systeme vollständig erfassen und zentral regulieren zu können - in übergeordnete Leitlinien für das Unternehmensmanagement. Im Kontext der vorliegenden Arbeit werden diese Leitlinien folgendermaßen interpretiert: ƒ

ƒ ƒ

ƒ

ƒ

ƒ ƒ

Aufgrund der Dynamik komplexer Systeme ist die kontextabhängige Gestaltung und Lenkung größerer Unternehmen in ihrer Umwelt nötig. Dies geht über die bloße Führung der personellen Aufgabenträger im Unternehmen hinaus. Beim Management des Unternehmens steht das Gesamtsystem im Vordergrund. Daher muss das Verhalten der Systemelemente durch das Einwirken auf die Interaktionsmuster dieser Elemente koordiniert werden. Führung ist Aufgabe vieler. Jeder, der es Anderen ermöglicht, Beiträge zum Unternehmenszweck zu leisten, sollte als Manager im Unternehmensnetzwerk betrachtet werden. Dies dient der Erhaltung der Flexibilität des Systems. Da der Output eines Unternehmens von den Interaktionsbeziehungen der Systemelemente und dem Verhalten der Elemente abhängt, sind bei inakzeptablem Output Änderungen der Systemstruktur notwendig. Organisation findet hier im Sinne der Lenkung der eigendynamischen Prozesse statt. Da das System über eigene Gestaltungskräfte verfügt, ist das Management auf die Optimierung der Reaktionsfähigkeit, Lernfähigkeit, Organisierbarkeit und letztlich auf die Steuerungsfähigkeit des Unternehmens auszurichten. Die unvollkommene Wissenslage des Managements soll zu Entscheidungen führen, die bei Veränderungen im Umfeld bzw. der Sachlage revidierbar sind. Systeme generieren Änderungen von selbst. Daher soll das Management auf die Maximierung der Lebensfähigkeit ausgerichtet sein, was insbesondere bedeutet, die für das System relevante Komplexität unter Kontrolle zu bringen.

2.2 Begriffsbestimmung Integrationsmanagement

47

KRCMAR68 fasst Management ausgehend von MALIK zusammen als: ƒ ƒ ƒ ƒ ƒ

Setzen von Vision und Zielen69, Organisieren, Entscheiden, Kontrollieren (Steuern)70, Menschen entwickeln und fördern.

Gemeinsam mit vorherigen Ausführungen ergibt sich das Verständnis des Begriffes IT-Management für die vorliegende Arbeit folgendermaßen: Definition - IT-Management71 IT-Management ist die Funktion des Managements des komplexen Teilsystems Unternehmens-IT. Diese Funktion wird innerhalb der Rahmenbedingungen ausgeübt, die durch das Unternehmen als Gesamtsystem gesetzt sind. IT-Management ist am Zweck des Teilsystems IT-Landschaft ausgerichtet, der in der auf den Unternehmenszweck ausgerichteten Informationstransformation besteht. Das Ziel der Funktion des IT-Managements ist die Sicherstellung des informationswirtschaftlichen Gleichgewichtes.72 Für die weitere Ausarbeitung wird der Begriff des informationswirtschaftlichen Gleichgewichts definiert. Definition - Informationswirtschaftliches Gleichgewicht Unter dem informationswirtschaftlichen Gleichgewicht wird der Zustand verstanden, der vorliegt,

68

Vgl. [Krcmar05], S. 24. Entsprechend der von MALIK geforderten adaptierbaren strategischen Konzeption. In der vorliegenden Arbeit wird im Folgenden der Begriff steuern anstelle von kontrollieren verwendet, da er aus Sicht des Autors besser das systemtheoretische Managementverständnis reflektiert, wie es z. B. bei MALIK zum Ausdruck kommt. 71 Hier handelt es sich um die funktionale Sicht. Analog wird unter der Funktion des Unternehmensmanagements das Management des Gesamtsystems im Sinne des von KRCMAR formulierten Verständnisses begriffen. Wird der Begriff des Managements i. S. einer aufbauorganisatorischen Sicht verwendet, so sind darunter die menschlichen Aufgabenträger zu verstehen, die die oberste Lenkungsebene des jeweiligen Systems bilden. 72 Dies entspricht der Sicht von KRCMAR und der von LINK. Vgl. dazu [Krcmar05] sowie [Link82]. 69 70

48

2 Bezugsrahmen und Grundlagen

ƒ ƒ ƒ

wenn der Informationsbedarf73, der sich aus den zur Erfüllung des Geschäftszweckes erforderlichen Transformationsaufgaben ergibt, durch das durch die IT-Landschaft bereitgestellte Informationsangebot innerhalb der für die Unternehmens-IT definierten Effizienzziele befriedigt wird.

Der Informationsbedarf ist nach AUGUSTIN74 dann befriedigt, wenn die erforderliche Information am richtigen Ort, zum richtigen Zeitpunkt, in der richtigen Menge sowie in der erforderlichen Qualität zur Verfügung steht. Die Funktion des IT-Managements erreicht das Ziel der Sicherstellung des informationswirtschafltlichen Gleichgewichtes mittels folgender Aktivitäten – sie werden auf der Grundlage übergreifender Leitlinien zum Unternehmensmanagement durchgeführt: ƒ ƒ

Formulierung einer adaptierbaren strategischen Konzeption für die Unternehmens-IT Organisierung, Entscheidung und Steuerung von IT-Landschaft und ITOrganisation; dies umfasst die Gestaltung der Interaktionsbeziehungen der Systemelemente der Unternehmens-IT untereinander und zur Systemumwelt, insbesondere durch das Entwickeln und das Fördern der personellen Aufgabenträger der IT-Organisation.

Aus den Überlegungen zum informationswirtschaftlichen Gleichgewicht ergibt sich das in der folgenden Abbildung 27 dargestellte Balancedreieck. Informationsbedarf – dem Geschäftszweck des Unternehmens geschuldet

Informationswirtschaftliches Gleichgewicht

Informationsangebot der IT-Landschaft

Effizienzziele der ITOrganisation

Abbildung 27: Balancedreieck zum informationswirtschaftlichen Gleichgewicht 73

Eine umfassende Analyse der Merkmale von Informationsbedarfen und der Möglichkeiten zu deren Erhebung findet sich in [Jung06]. 74 Vgl. [Augustin90].

49

2.2 Begriffsbestimmung Integrationsmanagement

Eine Kernfunktion des IT-Managements – als Management der Unternehmens-IT - besteht demnach darin, auf der Grundlage des abgestimmten Informationsbedarfs die richtigen Informationsquellen auszuwählen und die Informationsflüsse so zu organisieren, dass der Informationsbedarf innerhalb der definierten Effizienzziele befriedigt wird. KRCMAR75 verwendet hierfür den Begriff Management der Informationslogistik. Die Analyse der Unternehmens-IT aus systemtheoretischer Sicht und die dabei getroffenen definitorischen Festlegungen werden in ein Modell zur Funktion des IT-Managements überführt, das in der folgenden Abbildung dargestellt ist. In diesem Modell wird die rekursive Grundstruktur komplexer, lebensfähiger System deutlich, wie sie als notwendige Eigenschaft lebensfähiger, komplexer Systeme von BEER76 postuliert wird. Das Unternehmen als komplexes, dynamisches System Unternehmenszweck Management des Gesamtunternehmens Strategische Konzeption

Management der Teilsysteme IT-Management = Management der Unternehmens-IT

organisieren

Strategische Konzeption organisieren

entscheiden

entscheiden

Teilsystem IT-Landschaft

Teilsystem IT-Organisation

steuern

steuern entwickeln und fördern

entwickeln und fördern

Unternehmens-IT

Zielsetzung: Sicherstellung des informationswirtschaftlichen Gleichgewichtes

Anwenderorganisation Management Teilsystem B

Management Teilsystem C

Strategische Konzeption

Strategische Konzeption

organisieren

organisieren

entscheiden

entscheiden

steuern

steuern

entwickeln und fördern

entwickeln und fördern

Leitlinien des Unternehmensmanagement

Abbildung 28: IT-Management im Gesamtunternehmen Mit dem nun vorliegenden begrifflichen Fundament liefert die folgende Definition die Antwort auf die zu Beginn von Abschnitt 2.2 formulierte Frage 3 nach der Definition des Begriffes des - ganzheitlichen – Integrationsmanagement.

75 76

Vgl. [Krcmar05]. Vgl. [Beer95].

50

2 Bezugsrahmen und Grundlagen

Definition - Integrationsmanagement Integrationsmanagement ist eine Teildisziplin des IT-Managements. Der Fokus dieser Teildisziplin liegt auf der systematischen Bewältigung von Integrationsanforderungen an die Unternehmens-IT. Integrationsmanagement unterliegt als Teildisziplin des IT-Managements der Zielsetzung der Sicherstellung des informationswirtschaftlichen Gleichgewichtes. Das Spektrum des Integrationsmanagements ergibt sich aus der definierten Integrationsperspektive, der definierten Integrationsreichweite, dem definierten Integrationsgegenstand sowie dem definierten Automatisierungsgrad. Innerhalb dieses Spektrums bedeutet Integrationsmanagement: ƒ die Formulierung einer adaptierbaren strategischen Integrationskonzeption, das heißt Verankerung in der strategischen Konzeption der Unternehmens-IT ƒ das Organisieren, Entscheiden und Steuern der Realisierung von Integrationsanforderungen. Dies umfasst die Gestaltung von Interaktionsbeziehungen von Systemelementen innerhalb der Unternehmens-IT und außerhalb der Unternehmens-IT mit Blick auf die effektive und effiziente Bewältigung von Integrationsanforderungen. Das gezielte Entwickeln und Fördern personeller Aufgabenträger der IT-Organisation bildet hierfür die Grundlage. Die nachstehende Abbildung zeigt die Einbettung der Teildisziplin Integrationsmanagement in das Management der Unternehmens-IT, wie sie sich aus dem begrifflichen Fundament der vorliegenden Arbeit ergibt. IT-Management = Management der Unternehmens-IT Teildisziplin A

Teildisziplin Integrationsmanagement

Teildisziplin C

Teildisziplin ..

Strategische Konzeption organisieren entscheiden

Teilsystem IT-Landschaft

Teilsystem IT-Organisation

steuern entwickeln und fördern

Unternehmens-IT

Zielsetzung: Sicherstellung des informationswirtschaftlichen Gleichgewichtes

Abbildung 29: Integrationsmanagement als Teildisziplin des IT-Managements

51

2.2 Begriffsbestimmung Integrationsmanagement

2.2.3 Aufstellung eines Grundmodells zum Integrationsmanagement Gegenüber der Unternehmens-IT erhobene Informationsbedarfe beruhen auf Anforderungen unternehmensinterner oder unternehmensexterner Systemelemente. Extern (z. B. durch Kunden oder Aufsichtsbehörden) verursachter Informationsbedarf77 (Informationsbedarf A) repräsentiert eine Umweltänderung und wirkt nicht unmittelbar auf die Unternehmens-IT. Er wird vielmehr durch Systemelemente der Anwenderorganisation aufgenommen und als Leistungsanforderung gegenüber der IT-Organisation erhoben (Informationsbedarf A’). Dem steht intern verursachter Informationsbedarf (Informationsbedarf B) gegenüber, der nicht unmittelbar auf den Informationsbedarf von externen Systemelementen zurückzuführen ist. Hierzu zählt zum Beispiel Informationsbedarf, der sich aus der Art und Weise der Marktbearbeitung durch das Unternehmen ergibt.78 Unternehmen als komplexes System Geschäftszweck

Teilsystem Anwenderorganisation Schnittstelle Infobedarf A

Schnittstelle

Infobedarf A

internes Systemelement

weitere Elemente

(z.B. Meldewesen)

(z.B. Vertrieb) Infobedarf B

Umweltelement (z.B. Aufsichtsbehörde)

Info IB

Infobedarf A‘

Umweltelement Info IA

Teilsystem IT-Landschaft

Zweck Info-Transformation zur Befriedigung des Informationsbedarfs

Teilsystem IT-Organisation Infobedarf C

(z.B. Aufsichtsbehörde)

Zweck Planung/Steuerung/ Weiterentwicklung/ Betrieb der ITLandschaft

Zweck: Effiziente Befriedigung Informationsbedarf

Teilsystem Unternehmens-IT Transformationsleistung des Unternehmens Informationsbedarf als Anforderung

Informationsfluss zur Befriedigung des Informationsbedarfes

Abbildung 30: Extern und intern initiierte Informationsbedarfe und Bearbeitung durch die Unternehmens-IT

77

Zu Verfahren zur Erhebung und Beschreibung von Informationsbedarfen vgl. [Jung06], S. 120 ff. Ein Beispiel hierfür ist Steuerungsinformation, die benötigt wird, um die Leistung von Vertriebseinheiten zu messen und zu bewerten.

78

52

2 Bezugsrahmen und Grundlagen

In beiden Fällen übernimmt die IT-Organisation gemäß ihrem Zweck der Planung, Steuerung, Weiterentwicklung und des Betriebs der IT-Landschaft die Aufgabe, den Informationsbedarf zu erfassen, zu interpretieren und zu konsolidieren. Es ergibt sich der aus Sicht der IT-Organisation konsolidierte Informationsbedarf C, der im Teilsystem IT-Landschaft abgebildet und implementiert wird. Aufgrund dieser Implementierung erzeugen die IT-Systeme in der ITLandschaft die Information IA und IB zur Befriedigung der ursprünglichen Informationsbedarfe A und B. Die Wirkung von Informationsbedarfen auf die Unternehmens-IT ist in Abbildung 30 dargestellt. Im ersten Kapitel wurden Treiber des Anforderungsdrucks auf die Unternehmens-IT identifiziert: ƒ ƒ ƒ

Zunahme regulatorischer Anforderungen Zunahme der Wettbewerbsintensität Technologischer Wandel

Neben der beschriebenen Forderung nach Befriedigung neuer bzw. veränderter Informationsbedarfe ergeben sich aus diesen Treibern Effizienzanforderungen an die Unternehmens-IT. Die Notwendigkeit der Weiterentwicklung der Unternehmens-IT basiert demnach erstens auf Veränderungen der Informationsbedarfe der Anwenderorganisation und zweitens auf Effizienzzielen. Beide Fälle werden nun analysiert und, ausgehend von Abbildung 30, in ein Grundmodell zum Integrationsmanagement überführt. 2.2.3.1 Änderung von Informationsbedarfen Veränderungen des Informationsbedarfs basieren auf Veränderungen der Geschäftsprozesse (Beispiele: Veränderung der Kreditkartenabwicklungsprozesse eines Finanzinstitutes; Veränderung der Vertriebssteuerungsprozesse eines Energieversorgers), die zur Erbringung der Transformationsleistung des Unternehmens und zur Sicherstellung der Lebensfähigkeit des Unternehmens durchgeführt werden. Geänderter Informationsbedarf bedingt Leistungsanforderungen gegenüber der IT-Organisation (Beispiele: Bereitstellung einer Real-timeKreditkartenkonten-Übersicht für den Kanal Internet eines Finanzinstitutes; Änderung des Bereitstellungszeitpunktes von Vertriebssteuerungsinformationen eines Energieversorgers). Die durch Veränderungen von Informationsbedarfen verursachten Leistungsanforderungen an die Unternehmens-IT werden im Rahmen der vorliegenden Arbeit in zwei Klassen unterteilt:

2.2 Begriffsbestimmung Integrationsmanagement

1.

2.

53

Fachliche Leistungsanforderung im engeren Sinn Veränderter Informationsbedarf bedingt zusätzliche bzw. neue fachliche Leistungsmerkmale in bestehenden bzw. neuen IT-Systemen. Diese Anforderungen werden in der vorliegenden Arbeit als fachliche Anforderungen im engeren Sinne79 bezeichnet. Solche fachlichen Leistungsmerkmale können funktionaler Art sein (Beispiel: Erweiterung des Internet-Banking-Systems um die Kreditkartenkontoübersicht). In diesem Fall handelt es sich um eine funktionale Anforderung. Oder sie können nicht-funktionaler Art sein (Beispiel: maximale Antwortzeit bei der Abfrage der Kreditkartenkontenübersicht durch Bankkunden). In diesem Fall handelt es sich um eine nichtfunktionale Anforderung. Integrationsanforderung Veränderter Informationsbedarf führt zu Anforderungen in Bezug auf die Integration von IT-Systemen. Solche Integrationsanforderungen entstehen, da aufgrund des geänderten Informationsbedarfes neue bzw. veränderte Informationsflüsse in der IT-Landschaft realisiert werden müssen (Beispiel: Integration des Internet-Banking-Systems mit dem Kreditkartensystem des Kreditkarten-Providers und dem Kreditkartenschattenkonten-System des Kreditinstituts).

Legt man dieses Verständnis zugrunde, so kann die in Abbildung 1 dargestellte Problematik so interpretiert werden, dass sich die Leistungserbringung der Unternehmens-IT zugunsten von Integrationsanforderungen und zuungunsten von fachlichen Anforderungen im engeren Sinne verschiebt. Die Zielsetzung des Integrationsmanagements in der Unternehmens-IT besteht daher in der Beeinflussung dieses Trends zugunsten der fachlichen Anforderungen. Der Fokus der vorliegenden Arbeit liegt hier gemäß dem definierten Forschungsdesign auf Integrationsanforderungen. Integrationsanforderungen werden durch die IT-Organisation aus Leistungsanforderungen abgeleitet und durch die Erbringung von Integrationsleistungen erfüllt. Diese Leistungserbringung erfolgt ƒ

79

in der IT-Landschaft (Beispiel: Verknüpfung der neu zu erstellenden Komponente „Kreditkartenkontenübersicht“ des Internet-Banking-Systems mit dem Kreditkartenschattenkontensystem auf Basis der gültigen Standards),

Im Folgenden wird vereinfachend nur noch von fachlichen Anforderungen gesprochen.

54 ƒ

2 Bezugsrahmen und Grundlagen

innerhalb der IT-Prozesse der Unternehmens-IT (Beispiel: durch die Organisationseinheit, die die Weiterentwicklung des Internet-Banking-Systems verantwortet).

Die Befriedigung aus dem Informationsbedarf abgeleiteter Leistungsanforderungen – dies sind Integrationsanforderungen oder fachliche Anforderungen führt zur Bereitstellung von Informationselementen80 durch IT-Systeme zur Unterstützung der Geschäftsprozessdurchführung. Abbildung 31 fasst dies als Modell zusammen. Unternehmen als komplexes System Unternehmensumwelt

Geschäftsprozesse IB

IE

Schnittstelle

Schnittstelle IE

Unternehmensumwelt

Informationsfluss Anforderungsfluss IB Informationsbedarf

Anwenderorganisation IE

IB

LANF Leistungsanforderung an U-IT

extern initiiert

IANF Integrationsanforderung an U-IT INTL Integrationsleistung der U-IT

LANF

INTL IS

FANF Fachliche Anforderung i.e.S. IE Informationselement IS = IT-System Legende

intern initiiert

IANF

FANF INTL

IT-Prozesse

IT-Landschaft

IT-Organisation Unternehmens-IT

Abbildung 31: Integrationsanforderungen und -leistungen als Folge intern oder extern initiierter Informationsbedarfe 2.2.3.2 Effizienzanforderungen Effizienzziele für die Unternehmens-IT basieren entweder auf Vorgaben des Managements für die IT-Organisation (z. B. Senkung der Kosten des Anwendungsmanagements und des Betriebs bestimmter IT-Systeme) oder auf Effizienzzielen der Anwenderorganisation (z. B. Stückkostensenkung im Bereich der Leistungsprozesse einer Versicherung) – wobei Erstere letztlich ebenfalls auf 80

Nach JUNG sind Informationselemente Ausprägungen von Informationselementtypen. Ein Informationselementtyp ist ein mit einem Namen versehenes Merkmal einer Menge von Realweltobjekten. Unter einem Informationsobjekttyp ist eine zweckbezogene Zusammenfassung von miteinander in Beziehung stehenden Informationselementtypen zu verstehen. Ausprägungen von Informationsobjekttypen sind Informationsobjekte. Vgl. [Jung06], S.63, 64.

55

2.2 Begriffsbestimmung Integrationsmanagement

Effizienzziele der Anwenderorganisation zurückzuführen sind. Effizienzziele führen zu Leistungsanforderungen an 1.

2.

die IT-Prozesse (z. B. leistungsfähigeres Anwendungsmanagement) - daraus ergeben sich Anforderungen, die durch Veränderung der IT-Organisation einschließlich ihrer Interaktionsbeziehungen zur IT-Landschaft umgesetzt werden (z. B. Re-Integration des Anwendungsmanagements eines unternehmensextern betreuten Provisionierungssystems in die IT-Organisation), die IT-Landschaft (z. B. Prozessautomatisierung im Bereich der Leistungsprozesse eines Versicherungsunternehmens), die in Integrationsanforderungen münden (z. B. Austausch manueller Prozessschnittstellen durch automatisierte Systemschnittstellen).81

In beiden Fällen sind durch die IT-Organisation Integrationsleistungen zu erbringen, um die Erreichung der Effizienzziele zu ermöglichen. Abbildung 32 fasst diesen Zusammenhang zusammen. Unternehmen als komplexes System Geschäftsprozesse

Management des Gesamtunternehmens EFFZ

Anwenderorganisation EFFZ

LANF Anforderungsfluss EFFZ Effizienzziel LANF Leistungsanforderung an U-IT

INTL

INTL IS

IANF Integrationsanforderung an U-IT INTL Integrationsleistung der U-IT IS = IT-System

IANF

IT-Prozesse

IT-Landschaft

IT-Organisation

Unternehmens-IT

Legende

Abbildung 32: Integrationsanforderungen und -leistungen als Folge von Effizienzzielen 81

Ergeben sich dabei auch neue Informationsbedarfe, so sind diese bereits durch Fall 1 abgedeckt und können daher hier vernachlässigt werden.

56

2 Bezugsrahmen und Grundlagen

2.2.3.3 Ableitung des Grundmodells zum Integrationsmanagement Aus der in den vorherigen Abschnitten durchgeführten Fallanalyse folgt als Definition: Definition - Integrationsanforderung und Integrationsleistung Eine Integrationsleistung ist eine durch die IT-Organisation erbrachte Leistung, um aus Leistungsanforderungen an die Unternehmens-IT abgeleitete Integrationsanforderungen zu erfüllen. Eine Leistungsanforderung ist auf veränderten Informationsbedarf von Systemelementen innerhalb oder außerhalb der Unternehmens-IT oder eine Effizienzanforderung der Anwenderorganisation bzw. des Unternehmensmanagements zurückzuführen. Eine Integrationsanforderung ist eine Anforderung, die darauf zielt, die Interaktion von Systemelementen der Unternehmens-IT82 zu verändern. Auf der Grundlage dieser Definition ergibt sich aus der Analyse der beiden Fälle - Änderung des Informationsbedarfs sowie Effizienzanforderung - das in der folgenden Abbildung dargestellte Grundmodell zum Integrationsmanagement. Es fungiert in der weiteren Ausarbeitung als Ordnungsrahmen, z. B. zur Einordnung wissenschaftlicher Arbeiten in den Kontext der vorliegenden Arbeit.

82

Die relevanten Systemelemente ergeben sich aus der Definition des Begriffes „Unternehmens-IT“ in Abschnitt 2.1.

57

2.2 Begriffsbestimmung Integrationsmanagement

Unternehmen als komplexes System Unternehmensumwelt

Geschäftsprozesse

IB

Unternehmensumwelt

IE

Schnittstelle

Schnittstelle

Management des Gesamtunternehmens

IE

EFFZ

Anwenderorganisation Informationsfluss

IE

IB

EFFZ

Anforderungsfluss intern/extern initiiert

EFFZ Effizienzziel

LANF

IB Informationsbedarf LANF Leistungsanforderung an U-IT IANF Integrationsanforderung an U-IT

INTL

IE Informationselement IS = IT-System Legende

FANF INTL

IT-Prozesse

INTL Integrationsleistung der U-IT FANF Fachliche Anforderung i.e.S.

IANF

IS

Zweck: InfoTransformation zur Befriedigung Info-Bedarf

Zweck: Planung/Steuerung/ Weiterentwicklung/Betrieb IT-Landschaft

IT-Landschaft

IT-Organisation

Zweck: Effiziente Befriedigung Informationsbedarf

Unternehmens-IT

Abbildung 33: Grundmodell zum Integrationsmanagement 2.2.3.4 Informationsbeziehungen und Integrationsleistungen in der IT-Landschaft Das Grundmodell zum Integrationsmanagement lässt offen, wie genau Integrationsleistungen und Leistungen zur Implementierung fachlicher Anforderungen abzugrenzen sind. Um diese Abgrenzung sicherzustellen, wird die Bedeutung von Interaktionsbeziehungen zwischen Systemen geklärt und, davon ausgehend, die Implementierungsebene betrachtet. Unter Integrationsanforderungen sind Anforderungen zu verstehen, die die Interaktionsbeziehungen von Systemelementen der Unternehmens-IT betreffen. Interaktionsbeziehungen zwischen IT-Systemen manifestieren sich in Informationsflüssen zwischen den an der Interaktion beteiligten Systemen. Daher kann hier von Informationsbeziehungen gesprochen werden. Die folgende Abbildung fasst dieses Verständnis zusammen.

58

2 Bezugsrahmen und Grundlagen

Informationsbeziehung IO IO

IT-System 1

Informationsfluss A IO IO

Informationsfluss C

Abbildung 34

IT-System 2

Informationsfluss B IO IO

Interaktionsbeziehungen in der IT-Landschaft - Informationsbeziehung

Zwischen System 1 und System 2 bestehen drei Informationsflüsse, entlang derer Informationsobjekte fließen: Zwischen System 1 und System besteht somit eine Informationsbeziehung. Handelt es sich bei System 1 um ein System zur Verwaltung von Darlehen für Privatpersonen, etwa Konsumentenkredite oder Baufinanzierungen und bei System 2 um eine Cashflow-Engine zur Berechnung unterschiedlicher Arten von Cashflows für die Risikokontrolle und das Treasury des Kreditinstitutes, so manifestiert sich die Informationsbeziehung z.B. in einem Informationsfluss A. Dieser Fluss besteht aus Privatdarlehenspositionen von System 1 nach System 2. Auf der Implementierungsebene manifestieren sich Informationsflüsse im Fluss von Datenelementen (DE) zwischen Systemen. Diese Datenflüsse (DF) werden mithilfe von Ausgangsschnittstellen, Eingangsschnittstellen und den zugehörigen Programmmodulen implementiert. Die folgende Abbildung verdeutlicht dies. Ein Kreditinstitut implementiert eine Cashflow-Engine zur Berechnung verschiedener Arten von Cashflows, z. B. Liquiditäts-Cashflows. Diese Cashflows werden im Treasury der Bank zum operativen Liquiditätsmanagement und im Risikomanagement zur Überwachung des Liquiditätsrisikos benötigt. Cashflows sind für alle liquiditätswirksamen Positionen der Bank zu ermitteln. Deshalb besteht zwischen dem Darlehenssystem für Privatkunden und der Cashflow-Engine eine Informationsbeziehung, die sich in einem Informationsfluss Darlehen Privatkunden manifestiert. Dieser Informationsfluss wird in Form zweier Datenflüsse implementiert: Der erste Datenfluss liefert die Daten zu Konsumentenkrediten, der zweite diejenigen für Baufinanzierungen. Dazu werden im Darlehenssystem zwei Ausgangsschnittstellen (AS1, AS2) implementiert und mit den entsprechenden Eingangsschnittstellen (ES1, ES2) in der Cashflow-Engine verbunden. Die Implementierung des Informationsflusses Darlehen Privatkunden mithilfe dieser Schnittstellen stellt eine Integrationsleistung der Unternehmens-IT auf Basis einer aus den Leistungsanforderungen des Treasury und des Risiko-

59

2.3 Unternehmensarchitektur und Integrationsmanagement

AS1

IO IO DE

AS2

IO IO DE

DF Positionen Konsumentenkredit

DF Positionen private Baufi

ES1 ES2

Cashflow-Engine

Vertragsmanagement & Positionierungsführung

Informationsfluss Darlehen Privatkunden

Liquiditäts-CF-Berechnung

Darlehenssystem Privat

managements abgeleiteten Integrationsanforderung dar. Demgegenüber stellt die Implementierung der Funktionalität zur Liquiditäts-Cashflow-Berechnung eine Leistung in Bezug auf eine fachliche Anforderung (im engeren Sinn) dar.

..

…

weitere positionsführende Systeme

Abbildung 35: Implementierung eines Informationsflusses – Integrationsleistungen in der IT-Landschaft 2.3 Unternehmensarchitektur und Integrationsmanagement 2.3.1 Unternehmensarchitektur und strategische Konzeption KRCMAR stelle in seinem Werk Informationsmanagement83 den auf SZYPERSKI 84 UND ESCHENRÖDER zurückgehenden Begriff des Informationsmanagements in den Mittelpunkt. KRCMAR weist darauf hin, dass ÖSTERLE85 hierfür den Begriff Informatikmanagement geprägt hat, während HORVATH86 vom Management der Informationsversorgung spricht. Nach Erfahrung des Autors der vorliegenden Arbeit wird heute in der Praxis und der praxisnahen Literatur mehrheitlich der 83

Vgl. [Krcmar05]. Vgl. [SzyEsch83]. Vgl. [Öster87]. 86 Vgl. [Horv94]. 84 85

60

2 Bezugsrahmen und Grundlagen

Begriff IT-Management verwendet. Die in der vorliegenden Arbeit vorgenommene systemtheoretisch begründete Definition des Begriffes IT-Management spannt den Bogen von der in der Praxis verwendeten Begrifflichkeit hin zum Verständnis der Wirtschaftsinformatik, wie es z. B. bei KRCMAR oder ÖSTERLE zum Ausdruck kommt. Eine dem amerikanischen Raum entstammende Terminologie liefert der EWIM-Ansatz. EWIM steht für Enterprise-wide Information Management und geht auf BENSON UND PARKEr87 zurück. Klassiker wie das Werk Strategic Planning for Information Systems von WARD UND PEPPARD88 basieren auf dem EWIM-Ansatz und auch Krcmar bezieht sich in seinem Konzept des Informationsmanagements auf EWIM. Der EWIM-Ansatz wird nun aufgegriffen, um das definitorische Fundament der vorliegenden Arbeit mit Blick auf den Begriff Unternehmensarchitektur festzulegen. Wesentlich für den EWIM-Ansatz ist die Differenzierung zwischen Nutzer und DV-Organisation. Innerhalb des begrifflichen Rahmens der vorliegenden Arbeit entspricht dies den Teilsystemen Anwenderorganisation und ITOrganisation. Nutzer bzw. die DV-Organisation zeichnen sich durch unterschiedliche Planungsanforderungen aus, die durch einen integrierten Planungsprozess zu verbinden sind. Dabei definiert die Nutzerseite aus der Geschäftsplanung abgeleitete Anforderungen an die DV-Seite, während die DV-Seite unter Berücksichtigung verfügbarer und zukünftiger IuK-Technologien89 Potenziale, aber auch Restriktionen für die Nutzerseite erzeugt. Der EWIM-Ansatz stellt fünf Aktivitäten in den Mittelpunkt des unternehmensweiten Informationsmanagements und konzentriert sich dabei auf die strategische Perspektive des IT-Managements. Wesentlich für den EWIM-Ansatz ist die Notwendigkeit der Gestaltung der Informationssystemarchitektur (ISArchitektur). Der Begriff der IS-Architektur wird im EWIM-Ansatz nicht genau abgrenzt, kann nach Einschätzung des Autors der vorliegenden Arbeit jedoch als Architektur des Informationssystems verstanden werden – Informationssystem im Sinne des umfassenden Verständnisses von FERSTL UND SINZ. Die folgende Abbildung fasst den EWIM-Ansatz zusammen. Die im EWIM-Ansatz beschriebenen fünf zentralen Aktivitäten des Informationsmanagements sind:

87

Vgl. [BenPar85]. Vgl. [WaPe02]. 89 EWIM verwendet hier den Begriff Informationstechnologie. Da diese Verwendung homonym zur Verwendung innerhalb der vorliegenden Arbeit ist, wird zugunsten der sprachlichen Eindeutigkeit von Informations- und Kommunikationstechnologie (IuK-Technologie) gesprochen. 88

61

2.3 Unternehmensarchitektur und Integrationsmanagement

1.

2. 3. 4. 5.

Ableitung der Geschäftsplanung aus der strategischen Planung des Unternehmens - das Informationsmanagement (i. S. des IT-Managements) ist hiervon nicht unmittelbar betroffen Anpassung der IS-Architektur an die in der Geschäftsplanung definierten Ziele Beeinflussung der strategischen Planung des Unternehmens durch die Potenziale und die Restriktionen der IuK-Technologie Begrenzung der IuK-Technologie-Optionen durch die auf die Geschäftsziele ausgerichtete IS-Architektur Ableitung und Verzahnung der IS-Architektur mit der strategischen Planung des Gesamtunternehmens

Strategische Planung des Unternehmens

3

IuKTechnologie

1

5

4

Planung der strategischen Geschäftseinheiten

Nutzer

2

Informationssystemarchitektur

DV-Bereich Enterprise-wide Information Management

Abbildung 36: Der EWIM-Ansatz zum IT-Management i. S. eines unternehmensweiten Informationsmanagements Der EWIM-Ansatz wird nun transformiert und so in den begrifflichen Rahmen der vorliegenden Arbeit überführt. Folgende Transformationen werden vorgenommen: ƒ ƒ

Anstelle des Begriffes Informationssystemarchitektur findet der Begriff Architektur der Unternehmens-IT bzw. IT-Unternehmensarchitektur Verwendung. Der Begriff strategische Planung wird durch den auf MALIK zurückgehenden Begriff strategische Konzeption ersetzt. Die IT-Unternehmensarchitektur wird als Artefakt verstanden, das in die strategische Konzeption der Unternehmens-IT eingebettet ist und diese prägt.

62 ƒ

2 Bezugsrahmen und Grundlagen

Der Begriff DV-Nutzer wird durch Anwenderorganisation ersetzt. Die Geschäftsarchitektur wird als Artefakt verstanden, das in die strategische Konzeption der Geschäftseinheiten bzw. des Gesamtunternehmens eingebettet ist und diese(s) prägt.

Diese Transformation führt unter Berücksichtigung des in Abbildung 28 dargestellten Modells des IT-Managements zu dem in der folgenden Abbildung dargestellten Modell des transformierten EWIM-Ansatzes90. Unternehmensumwelt

Strategische Gesamtkonzeption des Unternehmens Gesamt-Geschäftsarchitektur

IT-Landschaft 3

4

IuK-Technologie

IT-Organisation

5

1 4

Strategische Konzeption der Geschäftseinheiten Geschäftsarchitektur

2

Strategische Konzeption IT-Unternehmensarchitektur

Anwenderorganisation

Unternehmens-IT

Mgmnt der Geschäftseinheiten

IT-Management

Management des Gesamtunternehmens

Abbildung 37: IT-Management und IT-Unternehmensarchitektur im transformierten EWIM-Ansatz Analog zum EWIM-Ansatz ergeben sich für den transformierten Ansatz fünf zentrale Aktivitäten. Diese bestimmen die strategische Konzeption der Unternehmens-IT: 1.

90

Die Aufstellung der strategischen Konzeption der Geschäftseinheiten auf Basis der strategischen Gesamtkonzeption des Unternehmens Die strategische Gesamtkonzeption umfasst die Geschäftsarchitektur des Unternehmens. Wesentlich ist das von Malik ausgehende Verständnis der

In Abschnitt 4.3 wird auf der Grundlage des EWIM-Ansatzes eines Vorgehensmodell zur Durchführung der strategischen Konzeption entwickelt.

2.3 Unternehmensarchitektur und Integrationsmanagement

2.

3.

4.

5.

63

strategischen Konzeption im Sinne einer immer wieder zu adaptierenden Ausrichtung und Leitplankensetzung. Nach Erfahrung des Autors der vorliegenden Arbeit erfolgt diese Aktivität - als Erweiterung des EWIMAnsatzes – bidirektional; das heißt, die strategische Konzeption der Geschäftseinheiten und die des Gesamtunternehmens werden parallel, topdown und bottom-up erarbeitet. Definition der strategischen Konzeption der Unternehmens-IT Die strategische Konzeption der Unternehmens-IT wird parallel und in laufender Abstimmung zur strategischen Konzeption der Geschäftseinheiten festgelegt. Auch hier ist der prozessorientierte Ansatz zu betonen; das heißt, das Verständnis der strategischen Konzeption der Unternehmens-IT im Sinne einer immer wieder zu adaptierenden Ausrichtung und Leitplankensetzung für die IT-Landschaft und die IT-Organisation und der in diesen Systemen enthalten personellen und automatisierten Aufgabenträger. Die ITUnternehmensarchitektur ist Gegenstand der strategischen Konzeption der Unternehmens-IT, fungiert im Sinne von Leitplanken für die Entwicklung der IT-Landschaft und folgt - im Vorgriff auf die nachfolgende genauere begriffliche Fassung - dem prozessorientierten Charakter der strategischen Konzeption. Die Beeinflussung der strategischen Planung des Unternehmens und seiner Geschäftseinheiten durch die Potentiale und die Restriktionen der ITLandschaft und der IT-Organisation Die Begrenzung der Möglichkeiten der IT-Landschaft und der ITOrganisation durch die Leitplankensetzung der IT-Unternehmensarchitektur auf der einen und die Potentiale und Restriktionen der IuK-Technologie auf der anderen Seite Die Verzahnung der strategischen Konzeption der Unternehmens-IT mit der strategischen Planung des Gesamtunternehmens als Ergänzung zu 2.

Der EWIM-Ansatz vermittelt das Bild eines aus fünf Aktivitäten bestehenden, sequenziellen Prozesses. Nach Erfahrung des Autors der vorliegenden Arbeit stellt sich die strategische Konzeption der Unternehmens-IT in der Unternehmenspraxis als zyklischer, iterativer Ansatz dar, der verschiedene Perspektiven im Sinne eines gesamtheitlichen Vorgehens verzahnt. Die fünf Aktivitäten des EWIM-Ansatzes sollten also als Zyklus verstanden werden, bei dem aus Sicht des systemtheoretischen Konzeptes der vorliegenden Arbeit folgende Perspektiven aufeinander abzustimmen sind:

64 ƒ ƒ ƒ

2 Bezugsrahmen und Grundlagen

Perspektive 1: Betrachtung des Gesamtsystems Unternehmen in seiner Umwelt Perspektive 2: Betrachtung strategischer Teilsysteme auf Seiten der Anwenderorganisation - wie zum Beispiel strategische Geschäftseinheiten und wichtige Steuerungseinheiten91 Perspektive 3: Betrachtung des Teilsystems Unternehmens-IT

Innerhalb dieser Perspektiven finden die jeweiligen Bausteine der Unternehmensarchitektur - als Vereinigung der Gesamtgeschäftsarchitektur, der Geschäftsarchitekturen der Geschäftseinheiten und der IT-Unternehmensarchitektur – Eingang. Es ergibt sich das folgende Bild zur Positionierung der Unternehmensarchitektur in der strategischen Konzeption. Strategische Gesamtkonzeption des Unternehmens GesamtGeschäftsarchitektur

Strategische Konzeption der Teilsysteme der Anwenderorg.

Strategische Konzeption

Geschäftsarchitektur

Strategische Konzeption der Unternehmens-IT IT-Unternehmensarchitektur

Abbildung 38: Unternehmensarchitektur im Zyklus der strategischen Konzeption 2.3.2 Begriffsklärung Unternehmensarchitektur FISCHER zitiert in seiner Dissertationsarbeit zur Organisation der Unternehmensarchitektur92 Arbeiten von LANGENBERG UND WEGMANN93, wonach die Unternehmensarchitektur noch nicht den Status einer ausgereiften Wissenschaftsdisziplin erreicht habe, was sich insbesondere darin manifestiere, dass es bisher noch keine allgemein anerkannte Begriffsdefinition gebe. Wie die Ausführungen zur Abgrenzung des Begriffes Informationssystem zu Beginn des Kapitels zeigen, wäre diese Kritik – würde man LANGENBERG UND WEGMANN folgen selbst bei diesem seit Langem gebräuchlichen Begriff angezeigt. Aus Sicht des

91

Z. B. die Risikokontrolle bei einem Finanzdienstleister. Vgl. [Fischer08]. 93 Vgl. [LanWeg04]. 92

2.3 Unternehmensarchitektur und Integrationsmanagement

65

Autors der vorliegenden Arbeit ist eine solche Kritik dann angemessen, wenn die Forderung der definitorischen Fassung eines Begriffes wie z. B. Unternehmensarchitektur innerhalb eines gegebenen Untersuchungskontextes unterbleibt. In Forschung und Praxis kommt eine Reihe von Definitionen des Begriffes Unternehmensarchitektur zur Anwendung, die durch FISCHER systematisch erhoben und eingeordnet werden. Alle Definitionen treffen Aussagen, die sich zu den folgenden gemeinsamen Kernaussagen verdichten lassen: ƒ

ƒ

ƒ

ƒ ƒ

Unternehmensarchitektur umfasst die abstrahierende Beschreibung der Struktur eines Unternehmens und seiner Teilbereiche. Die Abstraktion dient der Komplexitätsreduktion, um die zielgerichtete Kommunikation in Bezug auf die Weiterentwicklung des Unternehmens zu unterstützen.94 Die strukturelle Beschreibung des Ist- und des angestrebten Zielzustandes für das Unternehmen erfolgt mithilfe abstrahierender Modelle, die sowohl die Gesamtsicht als auch bestimmte Schwerpunkte, wie zum Beispiel die Architektur der IT-Basisinfrastruktur, adressieren. Unternehmensarchitektur vereint zwei Perspektiven: die geschäftliche Sicht und die IT-Sicht. Die geschäftliche Sicht wird in der Rolle des Anforderers gesehen, die IT-Sicht in der Rolle des Erfüllers, der zudem neue Möglichkeiten für den Anforderer schafft.95 Unternehmensarchitektur adressiert sowohl den Ist-Zustand als auch den im Hinblick auf eine bestimmte zeitliche Perspektive gewünschten Zielzustand für das Unternehmen. Unternehmensarchitektur ist verzahnt mit der strategischen Konzeption des Unternehmens und dient deren Umsetzung.

Neben diesen Gemeinsamkeiten in den verschiedenen Begriffsdefinitionen lässt sich ein wesentlicher Unterschied erkennen. Ein Teil der Autoren betont den strukturbeschreibenden Charakter einer Unternehmensarchitektur, sieht mithin zuerst die Funktion eines Bauplanes für das Unternehmen, der sich in modellhaften Beschreibungen manifestiert. Der andere Teil der Autoren stellt den Transformationsprozess in den Vordergrund, betont also den prozessorientierten Charakter der Unternehmensarchitektur, der durch strukturdefinierende Beschreibungen – wie zum Beispiel Modelle – unterstützt wird. Zusammenfassend kann gesagt werden: Die erste Autorengruppe stellt die statische, strukturelle Sicht in den Vordergrund, die zweite die dynamische, transformationsorientierte Sicht. 94 95

Vgl. auch [Dern09], S.3. Dies ist auch die Perspektive des im vorherigen Abschnitt beschriebenen EWIM-Ansatzes.

66

2 Bezugsrahmen und Grundlagen

Nach Erfahrung des Autors besteht der Vorteil der Betrachtungsweise der zweiten Autorengruppe in der Betonung des Mittels Unternehmensarchitektur, das dem Zweck der Weiterentwicklung des Unternehmens innerhalb der Unternehmensumwelt zur Sicherstellung der Lebensfähigkeit dient. Diese Betrachtungsweise gewährleistet, dass die Aufstellung von Modellen, Prinzipien und Leitlinien nicht Zweck, sondern Mittel zur Unterstützung der Transformation des Unternehmens ist. Hier steht die Kommunikation und Abstimmung von Modellen zur Beschreibung angestrebter Zielzustände und von Leitlinien und Prinzipien der Transformation im Vordergrund. Dieses Verständnis liegt auf einer Linie mit dem in Abschnitt 2.1 entwickelten Grundverständnis der Unternehmens-IT als eines komplexen Teilsystems des Unternehmens. Nach diesem Verständnis adressiert Management nicht die Objektebene des Unternehmens, vielmehr wird mithilfe von Leitlinien, Verhaltensvorschriften etc. die Metasystemebene adressiert. Die Artefakte der Unternehmensarchitektur adressieren genau diese Metasystemebene und bewirken bestimmte Autonomieeinschränkungen der Teilsysteme, die für die Gewährleistung der Lebensfähigkeit des Gesamtunternehmens auf Seiten der Anwenderorganisation oder der Unternehmens-IT notwendig sind. Im Folgenden wird auf Basis dieser Überlegungen und der begrifflichen Festlegungen des vorherigen Abschnittes eine Begriffsdefinition vorgenommen, die den dynamischen, transformationsorientierten Charakter einer Unternehmensarchitektur in den Mittelpunkt stellt. Den Ausgangspunkt bildet LAPKINS Definition:96 “Enterprise architecture is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key principles and models that describe the enterprise's future state and enable its evolution. The scope of the enterprise architecture includes the people, processes, information and technology of the enterprise, and their relationships to one another and to the external environment. Enterprise architects compose holistic solutions that address the business challenges of the enterprise and support the governance needed to implement them.” Die folgende begriffliche Festlegung greift LAPKINS Definition auf und entwickelt sie auf der Grundlage des im vorherigen Abschnitt erarbeiteten Verständnisses der strategischen Konzeption des Unternehmens und seiner Teilsys96 Vgl. [Lapkin06]. Die Definition von LAPKIN beruht auf der Analyse verschiedener von Standardisierungsgremien vorgeschlagenen Definitionen und auf der Erhebung von Definitionen, wie sie in der Unternehmenspraxis zur Anwendung kommen.

2.3 Unternehmensarchitektur und Integrationsmanagement

67

teme weiter. Dabei wird zur Gewährleistung der begrifflichen Klarheit der Begriff des Unternehmensarchitektur-Management als Ausgangspunkt genommen. Definition - Unternehmensarchitektur-Management Unternehmensarchitektur-Management ist ein von der strategischen Konzeption des Unternehmens ausgehender Prozess, der darauf zielt, die Weiterentwicklung des Systems Unternehmen zu unterstützen. Dies geschieht durch die fortlaufende Definition und Kommunikation wichtiger Prinzipien, Standards, Modelle und Muster97, welche - ausgehend vom aktuellen Zustand - den zukünftigen Zustand und die Transformation des Unternehmens, seiner Teilsysteme, seiner Systemelemente sowie deren Interaktionsbeziehungen untereinander und zur Systemumwelt beschreiben. Prinzipien, Standards, Modelle und Muster, welche abstrahierend die bestehende bzw. die angestrebte Struktur des Unternehmens beschreiben, bilden die Unternehmensarchitektur. Der Prozess des Unternehmensarchitektur-Managements umfasst Teilprozesse, die auf die Transformation der Geschäftsseite (Geschäftsarchitektur-Management) bzw. die Transformation der Unternehmens-IT (IT-Unternehmensarchitektur-Management) ausgerichtet sind. ƒ Der Teil der Unternehmensarchitektur, der das Teilsystem der Unternehmens-IT in den Mittelpunkt stellt, bildet die IT-Unternehmensarchitektur. ƒ Der Teil der Unternehmensarchitektur, der das Teilsystem der Anwenderorganisation in den Mittelpunkt stellt, bildet die Unternehmensgeschäftsarchitektur. Liegt der Fokus auf einem Teilsystem der Anwenderorganisation, handelt es sich um die Geschäftsarchitektur dieser Einheit. ƒ Unter einem Ansatz zur Unternehmensarchitektur wird ein Referenzmodell98 verstanden, welches die zur Beschreibung der Unternehmensarchitektur verwendeten Artefakte und deren Beziehung untereinander festlegt. 97

Prinzipien werden hier im Sinne von Leitlinien und Grundsätzen, d. h. als generelle Organisationsschemata für Teilsysteme des Unternehmens, verstanden. Standards werden im Sinne von Vorgaben und Mustern im Sinne erprobter Vorgehensweisen und Ansätze für bestimmte wiederkehrende Probleme verstanden. 98 Ein Referenzmodell ist verallgemeinerndes Modell für eine Klasse von Sachverhalten, das als Blaupause für die Entwicklung spezieller Modelle dient. Das Referenzmodell stellt somit ein Entwurfsmuster dar, das als idealtypisches Modell für die Klasse der zu modellierenden Sachverhalte verwendet werden kann.

68

2 Bezugsrahmen und Grundlagen

Das der vorliegenden Arbeit zugrunde liegende Verständnis des Managements der Unternehmensarchitektur ist somit das eines die Weiterentwicklung des Unternehmens begleitenden Setzens von Leitplanken. Dieses Setzen von Leitplanken ist, wie in dem oben beschriebenen, transformierten EWIM-Ansatz dargestellt, Teil der strategischen Konzeption des Unternehmens. Die folgende Abbildung fasst dieses Verständnis zusammen. Unternehmen (Ziel-Situation) Einheiten der Anwenderorganisation r ktu hite arc s n e ehm ern Unt

Unternehmen

n= nke pla Leit Weiterentwicklung des Unternehmens zur Sicherstellung seiner Lebensfähigkeit

(Ist-Situation) Einheiten der Anwenderorganisation

it Le

= en nk pla

te Un

h rne

Unternehmens-IT

r ktu ite rch sa n me

Unternehmens-IT

Abbildung 39: Leitplankenfunktion der Unternehmensarchitektur bei der Weiterentwicklung des Unternehmens Das Grundverständnis des Managements der Unternehmensgeschäftsarchitektur ist das eines die Weiterentwicklung der wesentlichen Teilsysteme der Anwenderorganisation begleitenden Setzens und Anwendens von Leitplanken, welches sich der strategischen Konzeption99 des jeweiligen Teilsystems unterordnet. Die folgende Abbildung fasst dieses Verständnis zusammen.

99

Strategische Konzeption verstanden als Strategiedefinition plus strategische Planung.

69

2.3 Unternehmensarchitektur und Integrationsmanagement

Unternehmen Weiterentwicklung der Anwenderorganisation als Beitrag zur Sicherstellung der Lebensfähigkeit des Unternehmens

Lei

n tpla

ken

itpl Le

Unternehmen

ftsa hä esc =G

en ank

itek rch

ftsa hä esc =G

tur

(Ziel-Situation) Einheiten der Anwenderorganisation Unternehmens-IT

tur i te k rch

(Ist-Situation) Einheiten der Anwenderorganisation Unternehmens-IT

Abbildung 40: Leitplankenfunktion der Geschäftsarchitektur bei der Weiterentwicklung der Anwenderorganisation Das Grundverständnis der IT-Unternehmensarchitektur ist das eines die Weiterentwicklung der Unternehmens-IT begleitenden Setzens und Anwendens von Leitplanken, welches sich der strategischen Konzeption der UnternehmensIT unterordnet. Die folgende Abbildung fasst dieses Verständnis zusammen. Unternehmen (Ziel-Situation)

Weiterentwicklung der Unternehmens-IT als Beitrag zur Sicherstellung der Lebensfähigkeit des Unternehmens

Unternehmen

n nke tpla Lei

(Ist-Situation) Einheiten der Anwenderorganisation

L

nte T-U =I

= ken lan ei tp

e hm rne

IT-

Einheiten der Anwenderorganisation Unternehmens-IT

tur itek rch nsa

n ter Un

en ehm

tur te k chi sar

Unternehmens-IT

Abbildung 41: Leitplankenfunktion der IT-Unternehmensarchitektur beim Transformationsprozess der Unternehmens-IT

70

2 Bezugsrahmen und Grundlagen

2.3.3 Integrationsmanagement und Unternehmensarchitektur Die zentrale Forschungsfrage der vorliegenden Arbeit zielt auf die Entwicklung eines Konzeptes zum ganzheitlichen Integrationsmanagement in der Unternehmens-IT und umfasst den Bezug zur Unternehmensarchitektur. Aufbauend auf dem nun definierten Verständnis des Begriffes Unternehmensarchitektur wird in diesem Abschnitt die Rolle der Unternehmensarchitektur bei der Entwicklung des Konzeptes zum Integrationsmanagement geklärt. Wie bereits in Abschnitt 2.2.2 ausgeführt, zeichnet das Unternehmen als sich selbst organisierendes System die Fähigkeit aus, durch selbstständige strukturelle Evolution und Differenzierung das Komplexitäts- und Organisationsniveau in Bezug auf die Anforderungen der Systemumwelt zu optimieren. Dieser fortlaufende Weiterentwicklungsprozess des Unternehmens bedingt, ausgehend von den Anforderungen der Systemumwelt, eine permanente Anpassungsleistung der Unternehmens-IT. Nach dem in Abschnitt 2.2.3 entwickelten Modell zum Integrationsmanagement führt die Forderung nach der Befriedigung unternehmensintern bzw. -extern initiierter Informationsbedarfe sowie nach der Erfüllung von Effizienzzielen auch zu Integrationsanforderungen. Die Erfüllung von Integrationsanforderungen durch die Erbringung von Integrationsleistungen ist Teil der Leistungsprozesse der Unternehmens-IT und damit Bestandteil des Beitrages der Unternehmens-IT zur Weiterentwicklung des Unternehmens. Daraus ergibt sich nach dem für die vorliegende Arbeit definierten Verständnis des Begriffes IT-Unternehmensarchitektur, dass die oben beschriebene Leitplankenfunktion der IT-Unternehmensarchitektur auch für die Erfüllung von Integrationsanforderungen durch die Erbringung von Integrationsleistungen gilt. Dies manifestiert sich in Prinzipien, Standards, Modellen und Mustern zur Integration der Systemelemente von IT-Landschaft und IT-Organisation. Zwei Beispiele verdeutlichen diese Leitplankenfunktion der IT-Unternehmensarchitektur in Bezug auf die Erbringung von Integrationsleistungen: ƒ

100

DERN beschreibt in Management von IT-Architekturen100 die Definition eines Integrationsstandards bei einem Versicherungsunternehmen, der das zu verwendende Architekturmuster101 für die Integration von operativen mit

Vgl. [Dern09], S. 42. Zum Konzept der Referenzarchitekturen vgl. auch [Quasar08]. Der Arbeitskreis Architektur- und Entwurfs-Muster (AKAEM) der Fachgruppe Software Architektur der Gesellschaft für Informatik stellt auf der Web-Seite www.architekturmuster.de eine Liste von Definitionen des Begriffes Architekturmuster zur Verfügung. Die Liste verdeutlicht, dass es keine allgemeingültige Begriffsdefinition gibt. Für die vorliegende Arbeit werden Architekturmuster als grundlegende Strukturen zur Organisation von IT-Landschaften, Teilsystemen von IT-Landschaften oder einzelnen IT-Systemen im Hinblick auf bestimmte Problemstellungen verstanden. 101

71

2.3 Unternehmensarchitektur und Integrationsmanagement

ƒ

analytischen Systemen in Form einer Referenzintegrationsarchitektur festlegt. Dieses Muster ist Teil der IT-Unternehmensarchitektur. Prinzipien, die darauf hinwirken, die IT-Landschaft eines Unternehmens so zu organisieren, dass Teil-IT-Landschaften bestimmter strategischer Geschäftseinheiten möglichst stark von den übrigen entkoppelt sind, um auf diese Weise strategische Optionen in Bezug auf die Fusionierung dieser Geschäftseinheiten mit anderen Unternehmen zu schaffen102, sind Teil der ITUnternehmensarchitektur.

Die Leitplankenfunktion der IT-Unternehmensarchitektur in Bezug auf die Erbringung von Integrationsleistungen wird mithilfe des folgenden Modells ausgehend von Abbildung 41 zusammengefasst. Es ergibt sich die Bedeutung der IT-Integrationsarchitektur innerhalb der IT-Unternehmensarchitektur des Unternehmens für das Integrationsmanagement. Unternehmen (Ziel-Situation) Einheiten der Anwenderorganisation

Weiterentwicklung der Unternehmens-IT als Beitrag zur Sicherstellung der Lebensfähigkeit des Unternehmens

Unternehmen (Ist-Situation) Lei

n nke tpla

tur itek rch nsa e ehm tern Integrations-Un leistung = IT

Integrationsleistung

Einheiten der Anwenderorganisation Integrationsleistung

IT n= nke tpla i e L

Unternehmens-IT

Integrationsanforderung

Integrationsanforderung

Integrationsanforderung

ar ens ehm n r e t -Un

Integrationsanforderung

tek chi

Unternehmens-IT

Integrationsleistung

tur

Leitplanken umfassen Prinzipien, Standards, Modelle und Muster zur Erbringung von Integrationsleistungen

Integrationsanforderung

Integrationsanforderung

Integrationsanforderung

Abbildung 42: Integrationsleistungen als Teil der Anpassungsleistung der Unternehmens-IT innerhalb der Leitplanken der ITUnternehmensarchitektur

102

Siehe dazu auch Abschnitt 4.6.3.4.

72

2 Bezugsrahmen und Grundlagen

Ein Ansatz zur Unternehmensarchitektur wurde als Referenzmodell definiert, das die zur Beschreibung der Unternehmensarchitektur verwendeten Artefakte festlegt. Aus der voranstehenden Abbildung ergibt sich damit Folgendes als Zusammenhang zwischen einem Ansatz zur Unternehmensarchitektur und einem Konzept zum Integrationsmanagement: Die IT-Unternehmensarchitektur als Teil der Unternehmensarchitektur umfasst Prinzipien, Standards, Modelle und Muster, die als Leitplanken bei der Erbringung von Integrationsleistungen fungieren. Definiert man diesen Teil der IT-Unternehmensarchitektur als IT-Integrationsarchitektur des Unternehmens, so folgt, dass ein Ansatz zur Unternehmensarchitektur das Referenzmodell zur Beschreibung der IT-Integrationsarchitektur umfasst. Im oben angeführten Beispiel des Versicherungsunternehmens kommt ein Ansatz zur Unternehmensarchitektur zur Anwendung, der Referenzintegrationsarchitekturen zur Standardisierung der Integration von IT-Systemen103 umfasst. 2.3.4 Erweiterung des Grundmodells zum Integrationsmanagement Auf der Grundlage des erarbeiteten Verständnisses der Unternehmensarchitektur im Sinne von Leitplanken für die Weiterentwicklung des Unternehmens wird das in Abbildung 33 beschriebene Grundmodell zum Integrationsmanagement erweitert. Dazu wird die Unternehmensarchitektur als weitere Dimension in das Grundmodell aufgenommen, da die definierten Modelle, Prinzipien, Standards und Muster auch Leitplanken für das Integrationsmanagement und damit für die systematische Bearbeitung von Integrationsanforderungen setzen. Die folgende Abbildung zeigt das erweiterte Grundmodell zum Integrationsmanagement.

103

DERN (vgl. [Dern09], S. 53) führt in diesem Zusammenhang den Begriff des Anwendungstypen ein. Zum Konstrukt des Anwendungstypen siehe Abschnitt 4.4.1.3.

73

IB

Informationsfluss Anforderungsfluss EFFZ Effizienzziel IB Informationsbedarf LANF Leistungsanforderung an U-IT IANF Integrationsanforderung an U-IT INTL Integrationsleistung der U-IT FANF Fachliche Anforderung i.e.S. IE Informationselement IS = IT-System Legende

Unternehmensgeschäftsarchitekturr

Schnittstelle

Unternehmen als System Geschäftsprozesse

Unternehmensumwelt

IE Schnittstelle

Management des Gesamtunternehmens

IE

EFFZ

Anwenderorganisation IE

IB

EFFZ intern/extern initiiert

IT-Unternehmensarchitektur

Unternehmensumwelt

U n t e r n e h m e n s a r c h i t e k t u r

2.4 Zusammenfassung - Gestaltungsprinzipien des Integrationsmanagements

LANF

INTL

IS

IANF

FANF INTL

IT-Prozesse Zweck: InfoTransformation zur Befriedigung Info-Bedarf

Zweck: Planung/Steuerung/ Weiterentwicklung/Betrieb IT-Landschaft

IT-Landschaft

IT-Organisation

Zweck: Effiziente Befriedigung Informationsbedarf

Unternehmens-IT

Abbildung 43: Erweitertes Grundmodell zum Integrationsmanagement 2.4 Zusammenfassung - Gestaltungsprinzipien des Integrationsmanagements Im ersten Kapitel wurde der Handlungsbedarf in Bezug auf ein Integrationsmanagement in der Unternehmens-IT beleuchtet und das Forschungsdesign der Arbeit festgelegt. Das Problem der Aufwandsverschiebung wurde adressiert. Die Notwendigkeit der Berücksichtigung der Komplexität der Unternehmens-IT bei der Entwicklung von Gestaltungsempfehlungen zum Integrationsmanagement wurde aufgezeigt. Das zweite Kapitel legte das begriffliche Fundament für die Entwicklung des im Forschungsdesign der Arbeit geforderten Konzeptes zum Integrationsmanagement. Dies umfasste die Festlegung des Integrationsspektrums, die Betrachtung des Unternehmens aus Sicht der Systemtheorie, die Analyse der Bedeutung eines Ansatzes zur Unternehmensarchitektur und führte zur Entwicklung eines Grundmodells zum Integrationsmanagement. Das so entwickelte Fundament wird in Form von Gestaltungsprinzipien zum Integrationsmanagement in der Unternehmens-IT zusammengefasst.

74

2 Bezugsrahmen und Grundlagen

Gestaltungsprinzip GP1 – Unternehmens-IT als komplexes Teilsystem des Unternehmens Die Unternehmens-IT wird als komplexes, offenes, dynamisches Teilsystem des Unternehmens verstanden, das dem Zweck der effizienten Befriedigung der Informationsbedarfe der Anwenderorganisation dient und so einen essenziellen Beitrag zur Sicherstellung des Lebensfähigkeit des Unternehmens leistet. Gestaltungsprinzip GP2 – Integrationsmanagement innerhalb eines breiten Spektrums von Integrationsanforderungen Ganzheitliches Integrationsmanagement adressiert ein breites Spektrum von Integrationsanforderungen an die Unternehmens-IT, welches sich aus Veränderungen des Informationsbedarfs und aus Effizienzzielen von Systemelementen außerhalb der Unternehmens-IT ergibt. Die Unternehmens-IT wird umfassend verstanden, d. h. als System, das die Teilsysteme IT-Landschaft und ITOrganisation beinhaltet. Integrationsmanagement bezieht sich auf die Elemente dieser Teilsysteme und umfasst das Management der Komplexität des Gesamtsystems Unternehmens-IT. Gestaltungsprinzip GP3 – Integrationsmanagement als Teildisziplin des ITManagements Ganzheitliches Integrationsmanagement ist als Teildisziplin im Management der Unternehmens-IT verankert. Dies bedeutet die Organisation, die Entwicklung und die Steuerung personeller Aufgabenträger der Unternehmens-IT einschließlich deren Interaktionsmuster, sodass die von der IT-Organisation geforderte permanente Weiterentwicklung der IT-Landschaft insbesondere durch die effektive und effiziente Erbringung von Integrationsleistungen unterstützt wird. Gestaltungsprinzip GP4 – Integrationsmanagement innerhalb der Leitplanken der IT-Unternehmensarchitektur Integrationsleistungen sind Bestandteil der Leistungsprozesse der Unternehmens-IT, die der Sicherung der Lebensfähigkeit des Unternehmens dienen. Die IT-Unternehmensarchitektur setzt Leitplanken für die effektive und effiziente Weiterentwicklung der Unternehmens-IT im Rahmen der Leistungsprozesse. Die Leitplankenfunktion der IT-Unternehmensarchitektur erstreckt sich auch auf die Erbringung von Integrationsleistungen und manifestiert sich in der IT-Integrationsarchitektur, d. h. Modellen, Standards, Prinzipien und Mustern, die bei der Erbringung von Integrationsleistungen wirken – z. B. Referenzintegrationsarchitekturen.

3 Entwicklung übergeordneter Gestaltungsempfehlungen

Was ist UnternehmensIT?

Das Unternehmen als komplexes, dynamisches, offenes System

Was ist ganzheitliches Integrationsmanagement?

Spektrum Integrationsmanagement

Einbettung Integrationsmanagement in das ITManagement

Integrationsmanagement und Unternehmensarchitektur

Systemtheoretisches Fundament

Grundmodell zum Integrationsmanagement

Forschungsdesign

Kapitel 2

Kapitel 1

Das Gestaltungsziel der Arbeit ist die Entwicklung eines Systems aufeinander abgestimmter Empfehlungen zur Gestaltung der Unternehmens-IT. Die Entwicklung der Gestaltungsempfehlungen vollzieht sich in zwei Schritten. Der erste Schritt betrifft übergeordnete, der zweite Schritte weiterführende Gestaltungsempfehlungen. Kapitel 3 dient der Aufstellung übergeordneter Gestaltungsempfehlungen auf Basis der Analyse verwandter Arbeiten aus Forschung und Praxis. Die folgende Abbildung zeigt die Einordnung des 3. Kapitels in den Prozess der Entwicklung der geforderten Gestaltungsempfehlungen.

Übergeordnete Gestaltungsemfehlungen zum Integrationsmanagement der Unternehmens-IT

Weiterführende Gestaltungsempfehlungen zum Integrationsmanagement der Unternehmens-IT

Kapitel 4

Analyse von Arbeiten aus Forschung und Praxis

Kapitel 3

Gestaltungsprinzipien zum Integrationsmanagement der Unternehmens-IT

Abbildung 44: Kapitel 3 und die Entwicklung des Systems von Gestaltungsempfehlungen

G. Dern, Integrationsmanagement in der Unternehmens-IT, DOI 10.1007/978-3-8348-8154-0_3, © Vieweg+Teubner Verlag | Springer Fachmedien Wiesbaden GmbH 2011

76

3 Entwicklung übergeordneter Gestaltungsempfehlungen

Zunächst wird ein Klassifikationsschema für Arbeiten aus Forschung und Praxis im Hinblick auf das Forschungsdesign der vorliegenden Arbeit festgelegt. Anschließend werden gemäß dieser Klassifikation als verwandt identifizierte Arbeiten analysiert und dabei werden übergeordnete Gestaltungsempfehlungen entwickelt. Diese übergeordneten Empfehlungen bilden den Ausgangspunkt der Verfeinerung im 4. Kapitel unter Einbeziehung weiterer Arbeiten aus Forschung und Praxis. 3.1 Klassifikation verwandter Arbeiten Gegenstand dieses Abschnittes ist die Klassifikation von Arbeiten, die einen Beitrag zur Beantwortung der Forschungsfrage, des Erkenntnisziels oder des Gestaltungsziels der vorliegenden Arbeit leisten können. Arbeiten werden dann als relevant für diese Arbeit betrachtet, wenn sie mindestens einem der folgenden Kriterien genügen: ƒ

ƒ ƒ

Kriterium 1: Die Zielsetzung der Arbeit weist große Ähnlichkeit zur zentralen Forschungsfrage der vorliegenden Arbeit auf. Dies erfordert, dass die betrachtete Arbeit Integrationsmanagement als Teildisziplin der gesamtheitlichen Gestaltung der Unternehmens-IT versteht. Kriterium 2: Das in der Arbeit betrachtete Integrationsspektrum weist große Ähnlichkeit zu dem für die vorliegende Arbeit in 2.2.1 definierten Integrationsspektrum auf. Kriterium 3: Die Arbeit liefert einen Beitrag bei der Aufstellung einzelner Gestaltungsempfehlungen zum ganzheitlichen Integrationsmanagement.

Die durchgeführte Literaturrecherche wurde unter Einbeziehung der Portale von ACM, IEEE104 und Springer durchgeführt. Bei der Suche nach verwandten Arbeiten wurde keine Arbeit identifiziert, die Kriterium 1 erfüllt. Dies bedeutet, dass keine der analysierten Arbeiten die Fragestellung behandelt, wie die Unternehmens-IT zu gestalten ist, um dem Problem der beschriebenen Aufwandsverschiebung zugunsten der Erbringung von Integrationsleistungen und zuungunsten der Bearbeitung fachlicher Anforderungen zu begegnen (s. Abbildung 1). Bei der Suche nach verwandten Arbeiten wurde ebenfalls keine Arbeit identifiziert, die Kriterium 2 erfüllt. Dies ist darauf zurückzuführen, dass keine der analysierten Arbeiten eine Integrationsperspektive einnimmt, die derjenigen der vorliegenden Arbeit nahe kommt. 104

ACM, Association for Computing Machinery; www.acm.org; IEEE, Institute of Electrical and Electronics Engineers, www.ieee.org.

3.1 Klassifikation verwandter Arbeiten

77

Identifizierte Arbeiten, die das dritte Kriterium erfüllen, wurden in drei Gruppen eingeteilt. Gruppe 1 – Arbeiten mit enger Fokussierung auf spezielle Integrationsaspekte Die erste Gruppe umfasst den größten Teil der Arbeiten, die im Rahmen der Recherche analysiert wurden. Hier wird Integration als Problem der Integration von IT-Systemen unter Nutzung spezieller Integrationsparadigmen, Integrationsmuster, Integrationstechnologien und Integrationsarchitekturen aufgefasst. Diese Arbeiten betrachten Integration nicht aus dem Blickwinkel des Managements der Unternehmens-IT, sondern aus Sicht der Lösung bestimmter Integrationsprobleme. Sie können gemäß ihrer Zielsetzung folgendermaßen klassifiziert werden: ƒ ƒ ƒ ƒ ƒ ƒ

Arbeiten zu speziellen Problemen der Integration von IT-Systemen105 Solche Arbeiten behandeln die Frage nach Integrationsmustern oder Integrationsmechanismen zur Lösung bestimmter Probleme der Integration von IT-Systemen. Arbeiten mit Fokussierung auf bestimmte Integrationsparadigmen106 Solche Arbeiten behandeln die Frage, wie ein bestimmtes Paradigma – z. B. SOA oder Data Warehousing – optimal umgesetzt werden kann. Arbeiten107 zu Einsatzmöglichkeiten ausgewählter Technologien in Bezug auf Integrationsprobleme in der IT-Landschaft Diese Arbeiten stellen ganz bestimmte Technologien in Bezug auf die Nutzung bei der Integration von IT-Systemen in den Mittelpunkt.

Charakteristisch für Arbeiten, die in Gruppe 1 fallen, ist das Fehlen des Bezuges zur gesamtheitlichen Gestaltung bzw. zum Management der Unternehmens-IT. Diese Positionierung wird in Abbildung 45 innerhalb des Grundmodells zum Integrationsmanagement verdeutlicht. Für das Gestaltungsziel der vorliegenden Arbeit, d. h. für die Entwicklung eines Systems von Gestaltungsempfehlungen für das ganzheitliche Integrationsmanagement in der Unternehmens-IT, leisten Arbeiten der ersten Gruppe nur einen geringen Beitrag. Aus ihnen können keine übergreifenden Gestaltungsempfehlungen abgeleitet werden. Gruppe 1 erfüllt also keines der drei definierten Kriterien und wird nicht in die weiteren Betrachtungen der vorliegenden Arbeit einbezogen. Dies bedeutet nicht, dass Arbeiten aus dieser Gruppe keinen wertvollen Beitrag für die Implementie105

Vgl. [HoWo03], [Linth03], [Bauer04], [Bauer05]. Vgl. [Kimb08], [KleKo09], [Quasar08]. Hierunter fallen z. B. Arbeiten zum Einsatz von Message-Queueing-Technologien bei der Integration von IT-Systemen. 106 107

78

3 Entwicklung übergeordneter Gestaltungsempfehlungen

rung bestimmter Integrationsanforderungen durch die Unternehmens-IT leisten. So besitzen Paradigmen wie SOA oder Data Warehousing heute große Bedeutung im Unternehmensalltag.108 Das Gestaltungsziel der vorliegenden Arbeit besteht jedoch nicht darin, bestimmte Paradigmen umzusetzen, sondern in der Entwicklung eines Systems von Gestaltungsempfehlungen für das Integrationsmanagement in der Unternehmens-IT. Unternehmen als komplexes System Unternehmensumwelt

Geschäftsprozesse

IB

Unternehmensumwelt

IE

Schnittstelle

Schnittstelle

Management des Gesamtunternehmens

IE

EFFZ

Anwenderorganisation Informationsfluss

IE

IB

EFFZ

Anforderungsfluss intern/extern initiiert

EFFZ Effizienzziel

LANF

IB Informationsbedarf LANF Leistungsanforderung an U-IT IANF Integrationsanforderung an U-IT

INTL

IE Informationselement IS = IT-System Legende

FANF INTL

IT-Prozesse

INTL Integrationsleistung der U-IT FANF Fachliche Anforderung i.e.S.

IANF

IS

Zweck: InfoTransformation zur Befriedigung Info-Bedarf

Zweck: Planung/Steuerung/ Weiterentwicklung/Betrieb IT-Landschaft

IT-Landschaft

IT-Organisation

Zweck: Effiziente Befriedigung Informationsbedarf

Unternehmens-IT

Abbildung 45: Arbeiten aus Gruppe 1 - Projektion auf das Grundmodell zum ganzheitlichen Integrationsmanagement Gruppe 2 – Arbeiten zur Gestaltung der Unternehmens-IT ohne Fokus auf ganzheitliches Integrationsmanagement Die zweite Gruppe von Arbeiten besteht aus Ausarbeitungen, die die übergreifende Gestaltung der Unternehmens-IT oder eines der beiden Teilsysteme ITLandschaft und IT-Organisation in den Mittelpunkt stellen. Es handelt sich um Arbeiten, die dies nicht mit dem Fokus eines ganzheitlichen Integrationsmanagements tun, die jedoch Aspekte einbeziehen, aus denen Gestaltungsempfehlungen für die vorliegende Arbeit abgeleitet werden können. In diese Gruppe von 108

Dies wird im fünften Kapitel bei der Evaluierung des Gesamtkonzeptes mithilfe einer umfassenden Fallstudie deutlich.

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

79

Arbeiten fallen z. B. Beiträge zur Integration bzw. Desintegration von (Teil-) ITLandschaften im Rahmen von Fusionen, Übernahmen oder Abspaltungen von Unternehmensteilen.109 Arbeiten dieser Gruppe werden in die Überlegungen vorliegender Arbeit einbezogen. Gruppe 3 – Arbeiten, aus denen einzelne Gestaltungsempfehlungen abgeleitet werden können Die dritte Gruppe besteht aus Arbeiten, die die übergreifende Gestaltung der Unternehmens-IT nicht in den Mittelpunkt stellen, nicht zur ersten Gruppe gehören, aus denen dennoch einzelne Gestaltungsemfehlungen für das Integrationsmanagement abgeleitet werden können. Solche Arbeiten werden ebenfalls in die Gedankenführung vorliegender Arbeit einbezogen. 3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten Im Folgenden werden fünf im Rahmen der Literaturrecherche als verwandt identifizierte Arbeiten diskutiert. Dabei werden übergreifende Gestaltungsempfehlungen abgeleitet. Die analysierten Arbeiten betreffen die folgenden Themengebiete: ƒ ƒ ƒ ƒ ƒ

Komplexitätsmanagement in der Unternehmens-IT Ganzheitliche Lösungen zur Integration von IT-Systemen in ITLandschaften Integration und adaptive Unternehmensarchitekturen Unternehmensintegration in verteilten Organisationen IT-Konsolidierung bei Übernahmen und Fusionen

3.2.1 Integrationsmanagement und Komplexitätsmanagement in der Unternehmens-IT In der Arbeit Zur Anwendbarkeit des industriellen Komplexitätsmanagements auf variantenreichen IT-Dienstleistungen zum Komplexitätsmanagement bei ITDienstleistern untersuchen BÖHMANN UND KRCMAR110 die Möglichkeiten, aus den Erfahrungen eines industriellen Komplexitätsmanagements Gestaltungsempfehlungen für die Beherrschung und Reduktion von Komplexität der IT abzuleiten. Die Autoren betrachten u. a. Aspekte wie die Wirkung der Integration von 109 Die vorliegende Arbeit spricht hier von IT-Konsolidierung in der Folge einer M&A-Situation. Verschiedene Autoren verwenden den Begriff der Post-Merger-Integration ([Alaranta05], [MiBu07]); andere Autoren sprechen von IT-Integration ([Glöckle07]). 110 Vgl. [BöhKrc05].

80

3 Entwicklung übergeordneter Gestaltungsempfehlungen

IT-Dienstleister und Leistungsnachfrager auf die Komplexität der IT-Landschaft. Die Arbeit von BÖHMANN UND KRCMAR fällt in die oben definierte Gruppe 2. Es handelt sich um eine Arbeit, die Aspekte der übergreifenden Gestaltung der Unternehmens-IT analysiert, ohne den Fokus auf ganzheitliches Integrationsmanagement zu legen. Im Folgenden wird zunächst untersucht, wie die Arbeit von BÖHMANN UND KRCMAR innerhalb des systemtheoretischen Rahmens der vorliegenden Arbeit zu positionieren ist. Anschließend werden auf der Grundlage der Überlegungen von BÖHMANN UND KRCMAR übergreifende Gestaltungsempfehlungen abgeleitet. Ausführungen der Autoren zu Aspekten des industriellen Komplexitätsmanagement werden im Folgenden nicht einbezogen, da der Schwerpunkt der Analyse auf der Interpretation und Anwendung der Ergebnisse der Autoren auf die Problemstellung der vorliegenden Arbeit liegt. 3.2.1.1 Analyse und Abbildung auf das Modell zum Integrationsmanagement In den Mittelpunkt der Betrachtung stellen BÖHMANN UND KRCMAR den ITDienstleister, der Leistungen zur Informationsverarbeitung für seine Leistungsnachfrager flexibel und gleichzeitig kostengünstig erbringt bzw. erbringen soll. Schlagwort ist hier On-Demand-Leistungserbringung, das heißt die Bereitstellung der von Leistungsnachfragern zur Befriedigung ihres Informationsbedarfs genau geforderten Menge an IT-Leistungen. Ein Beispiel hierfür ist die Bereitstellung einer IT-Basisinfrastruktur, die möglichst genau der vom Nachfrager geforderter Informationsverarbeitungskapazität entspricht. Dabei stellt sich für die Autoren die Frage, wie es gelingt, die Komplexität und die Anforderungsvielfalt der Nachfrager von der Komplexität und der Vielfalt auf Seiten des ITDienstleisters und der durch den Dienstleister bewirtschafteten IT-Landschaft zu entkoppeln. Damit verbunden ist für die Autoren die Fragestellung, wie die Komplexität der IT-Systeme und der IT-Basisinfrastruktur (Informations- und Kommunikations- (IKT) Infrastrukturen) 111 reduziert oder begrenzt werden kann. Aus Sicht von BÖHMANN UND KRCMAR setzt der IT-Dienstleister bei der Leistungserbringung für seine Nachfrager auf folgende Kernkompetenzen: ƒ

111

Einführung, Betrieb, Wartung und Weiterentwicklung der IT-Systeme und der IKT-Infrastrukturen

Zuordnung der von BÖHMANN UND KRCMAR verwendeten Begriffe in Klammern.

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

ƒ

81

Dies umfasst zum Beispiel die Transformation von IT-Systemen im Rahmen der Prozesse des IT-Dienstleisters. Im Sinne der vorliegenden Arbeit entspricht dies der Zweckdefinition des Teilsystems IT-Organisation. Nachfragerintegration durch effektive und effiziente Integration von maschinellen und nicht-maschinellen Aufgabenträgern auf Seiten des Nachfragers in die IT-Prozesse des IT-Dienstleisters Als Beispiel ist die Durchführung von IT-Projekten112 zur Weiterentwicklung oder Erneuerung von IT-Systemen zu nennen.

Die Autoren betonen die Bedeutung ihrer Analyse für das Outsourcing von IT-Leistungen und unterscheiden dabei nicht zwischen der Leistungserbringung durch einen unternehmensinternen oder unternehmensexternen IT-Dienstleister. Daher kann die Gültigkeit ihrer Analyse auch für die in der vorliegenden Arbeit im Mittelpunkt stehende Unternehmens-IT angenommen werden. Die folgende Abbildung fasst das der Analyse des Komplexitätsmanagements durch BÖHMANN UND KRCMAR zugrunde liegende Verständnis als Modell zusammen. IT-Dienstleister Nachfrager Nutzer

Anforderer

Leistungsanforderung

Anbieter von Leistungen, die Nachfrager zur Befriedigung ihres Informationsbedarfs benötigen Leistungserbringung

IT-Systeme IKT-Infrastrukturen

Abbildung 46: Interaktion von IT-Dienstleister und Nachfrager i. S. v. BÖHMANN UND KRCMAR Wesentlich an diesem Modell – wie die weiteren Ausführungen zum Komplexitätsmanagement zeigen werden - ist die Unterscheidung zwischen 112 Im Rahmen der vorliegenden Arbeit wird ein Projekt als Folge systematisch gesteuerter Aktivitäten mit definierten Anfangs- und Endterminen verstanden, das durchgeführt wird, um mit einem Auftraggeber abgestimmte Ziele zu erreichen und das abgestimmten Beschränkungen hinsichtlich Zeit, Kosten und Ressourcen unterliegt. Wird von einem IT-Projekt gesprochen, so ist darunter ein Projekt zu verstehen, welches zum Erreichen der abgestimmten Ziele Aktivitäten einschließt, die eine Veränderung von Systemelementen der Unternehmens-IT und deren Interaktionen bewirken. Dies sind insbesondere Projekte, die die Entwicklung oder Anpassung von IT-Systemen umfassen.

82 ƒ ƒ

3 Entwicklung übergeordneter Gestaltungsempfehlungen

der Rolle des Nutzers und der des Anforderers auf Seiten des Nachfragers.

Interpretiert man dieses Grundmodell im Sinne der vorliegenden Arbeit, ergibt sich folgende Transformation: ƒ ƒ

Die Vielfalt der verschiedenen Nachfrager ergibt sich aus der Vielfalt der Nutzer. Nutzer sind Systemelemente der Anwenderorganisation – zum Beispiel Fachbereiche eines Energieversorgers. Anforderer übersetzen den Informationsbedarf von Nutzern in Anforderungen an die IT-Landschaft (IT-Systeme und IKT-Infrastrukturen). Gemäß der in Abschnitt 2.1.2 vorgenommenen Abgrenzung bilden sie Elemente des Teilsystems IT-Organisation in der Unternehmens-IT. Die Elemente auf Nachfragerseite verteilen sich somit im Modell der vorliegenden Arbeit auf Anwender- und IT-Organisation.

Das Modell zur Arbeit von BÖHMANN UND KRCMAR in Abbildung 46 kann daher gemäß Abbildung 46 auf das systemtheoretische Fundament der vorliegenden Arbeit abgebildet werden. Dazu wird innerhalb der IT-Organisation zwischen ƒ ƒ

den Systemelementen unterschieden, die die Informationsbedürfnisse der IT-Nutzer in Leistungsanforderungen an die IT-Landschaft überführen und denjenigen Systemelementen, die auf der Grundlage abgestimmter Anforderungen Leistungen erbringen.

Die letztgenannten Systemelemente werden zur Abbildung des bei BÖHKRCMAR anzutreffenden Verständnisses auf die vorliegende Arbeit unter den Begriff IT-Dienstleister subsumiert. Dementsprechend werden die ITProzesse in Prozesse der Leistungsanforderungsabstimmung und der Leistungserbringung aufgeteilt.

MANN UND

83

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

Anwenderorganisation

Unternehmens-IT IT-Organisation Prozesse der Anforderungsabstimmung

Nachfrager Nutzer

InfoBedarf

Anforderer

InfoBedarf

Anforderer

Nachfrager Nutzer

InfoBedarf

Leistungsanforderung

IT-Dienstleister

Nachfrager Nutzer

Prozesse der Leistungserbringung

Anforderer

Leistungsanforderung

Anbieter von Leistungen, die Nachfrager zur Befriedigung ihres Informationsbedarfs benötigen

Leistungsanforderung

IT-Systeme IKT-Infrastrukturen

IT-Landschaft

Abbildung 47: Abgrenzung der Begriffswelt von BÖHMANN UND KRCMAR Mit dieser Zuordnung kann das Verständnis, das BÖHMANN UND KRCMAR ihrer Analyse zugrunde legen, gemäß Abbildung 48 auf das Modell zum Integrationsmanagement der vorliegenden Arbeit projiziert werden. Anforderer und ITDienstleister gehören zur Unternehmens-IT und IT-Nutzer zur Anwenderorganisation. Die durch den IT-Dienstleister zu bewältigende Anforderungsvielfalt und Komplexität basieren auf den durch Anforderer aus den Anforderungen der Nutzer abgeleiteten Leistungsanforderungen.

84

3 Entwicklung übergeordneter Gestaltungsempfehlungen

Unternehmen als komplexes System Unternehmensumwelt

Geschäftsprozesse

IB

Unternehmensumwelt

IE

Schnittstelle

Schnittstelle

Management des Gesamtunternehmens

IE

EFFZ

Anwenderorganisation Informationsfluss

IE

IB

Nutzer

EFFZ

Anforderungsfluss intern/extern initiiert

EFFZ Effizienzziel

LANF Leistungsanforderung an U-IT IANF Integrationsanforderung an U-IT

INTL

IE Informationselement IS = IT-System Legende

IANF

FANF IT-Dienstleister

IS INTL

IT-Prozesse

INTL Integrationsleistung der U-IT FANF Fachliche Anforderung i.e.S.

Anforderer

LANF

IB Informationsbedarf

Zweck: InfoTransformation zur Befriedigung Info-Bedarf

Zweck: Planung/Steuerung/ Weiterentwicklung/Betrieb IT-Landschaft

IT-Landschaft

IT-Organisation

Zweck: Effiziente Befriedigung Informationsbedarf

Unternehmens-IT

IT-Systeme & IKTInfrastrukturen – durch den IT-Dienstleister gemanagt

Abbildung 48: Projektion der Arbeit von BÖHMANN UND KRCMAR auf das Modell zum Integrationsmanagement der vorliegenden Arbeit Auf der Grundlage dieser Projektion kann die von BÖHMANN UND KRCMAR adressierte Fragestellung folgendermaßen formuliert werden: ƒ ƒ

Wie können Leistungsanforderungen der Anwenderorganisation on demand und flexibel erfüllt werden? Die Autoren sprechen hier von der Anpassbarkeit an die Bedarfsverlaufe der Nachfrager. Wie können auf Basis der Erfahrungen des industriellen Komplexitätsmanagements die Komplexität und die Anforderungsvielfalt auf Seiten der Anwenderorganisation von der Komplexität und Vielfalt auf Seiten der ITOrganisation und in der IT-Landschaft entkoppelt werden, o um auf diese Weise die Komplexität der IT-Organisation und der ITLandschaft zu reduzieren bzw. zu begrenzen und o die Vielfalt der Leistungsanforderungen ohne einen proportionalen Anstieg der Produktionskosten zu erfüllen?

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

85

3.2.1.2 Komplexität und Integrationsmanagement Nach SESSIONS113 ist die Komplexität eines Systems eine Funktion F der Zustände, in denen sich das System befinden kann, d. h.: Komplexität des Systems S = F (Zi), Zi = Zustand i des Systems S Formel 1:

Allgemeine Formel zur Komplexität eines Systems angelehnt an SESSIONS

Komplexität bezeichnet nach MALIK114 als empirisches Merkmal soziotechnischer Systeme die Mannigfaltigkeit von Zuständen und Zustandskonfigurationen solcher Systeme. Die Mannigfaltigkeit resultiert für Malik aus der Interaktion von Systemen und Systemelementen. Es stellt sich die Frage nach der Konkretisierung dieser abstrakten Definitionen im Kontext der vorliegenden Arbeit. Verschiedene Autoren verfolgen unterschiedliche Ansätze zur Erfassung des Begriffes der Komplexität.115 PILLER betrachtet Komplexität116 aus dem Blickwinkel der Systemtheorie. PILLER definiert Komplexität als „das Zusammentreffen einer strukturellen Vielschichtigkeit, resultierend aus der Anzahl und Diversität der Elemente eines Systems sowie deren gegenseitige Verknüpfung und der dynamischen Veränderlichkeit der gegenseitigen Beziehungen der Systemelemente“117 und liefert damit die Basis für die Definition von Komplexität im Kontext der vorliegenden Arbeit. Definition - Komplexität eines Systems Unter der Komplexität eines Systems wird die strukturelle Vielschichtigkeit verstanden, die zum einen aus der Anzahl und der Vielfalt seiner Systemelemente sowie deren Interaktionsbeziehungen untereinander und zur Systemumwelt und zum anderen aus der Dynamik der Veränderungen der Systemelemente und ihrer Interaktionsbeziehungen resultiert. Interaktionsbeziehungen zwischen IT-Systemen sind gemäß Abschnitt 2.2.3.4 Informationsbeziehungen, manifestieren sich als Informationsflüsse und stehen im Mittelpunkt der von der IT-Organisation erbrachten Integrationsleis113

Vgl. [Sessions08]. Vgl. [Malik08], S. 33. 115 Einen Überblick über verschiedene Ansätze zur Definition von Komplexität gibt LANGNER in [Langn07]. 116 Vgl. [Piller00]. 117 Vgl. [Piller00], S.179. 114

86

3 Entwicklung übergeordneter Gestaltungsempfehlungen

tungen. Veränderungen der Komplexität der Unternehmens-IT in Folge der Veränderungen der Informationsbeziehungen haben daher unmittelbaren Einfluss auf die für Integrationsleistungen erbrachten Aufwände. Das Gestaltungsziel der vorliegenden Arbeit besteht in der Entwicklung eines Konzeptes zum Integrationsmanagement in der Unternehmens-IT, um das in Abbildung 1dargestellte Verhältnis zwischen der Verteilung der Aufwände in der IT-Organisation für Integrationsleistungen und den Leistungen für die Erfüllung fachlicher Anforderungen zu beeinflussen. Aufgrund dieses Gestaltungsziels ist die Komplexität der Unternehmens-IT zwingend einzubeziehen, was das Gestaltungsprinzip GP1 aus Abschnitt 2.4 bestätigt.118 Im Folgenden wird die Arbeit von BÖHMANN UND KRCMAR analysiert. Dabei wird gezeigt, dass die Komplexität durch die Art und Weise bestimmt wird, wie Anwenderorganisation und Unternehmens-IT integriert und wie IT-Prozesse und die Architekturen der IT-Systeme gestaltet werden. Zunächst wird in Anlehnung an DERN119 dazu der Begriff der IT-Architektur definiert: Definition – IT-Architektur Eine IT-Architektur ist die strukturierende Abstraktion der Systemelemente und der Interaktionbeziehungen eines existierenden oder eines geplanten IT-Systems. Diese Abstraktion schafft die gemeinsame Kommunikationsplattform aller an der Gestaltung oder dem Management des IT-Systems Beteiligten, um so die Planbarkeit und die Steuerbarkeit der Gestaltung realer, miteinander in Wechselwirkung stehender Elemente der Unternehmens-IT zu erhöhen. 3.2.1.3 Komplexitätsfalle – statisches und dynamisches Potenzial Auf Basis des oben beschriebenen systemtheoretischen Verständnisses von Komplexität untersuchen BÖHMANN UND KRCMAR unter Berücksichtigung der Arbeiten von MEFFERT sowie von ADAM UND JOHANNVILLE120 eine von ihnen als Komplexitätsfalle bezeichnete Problematik. Diese Komplexitätsproblematik wird hier genauer beleuchtet und - der Projektion aus Abbildung 48 folgend - in den begrifflichen Kontext der vorliegenden Arbeit gestellt. 118 Dies bestätigt MALIKs Maxime - mit Blick auf die Unternehmens-IT -, nach der unter grundsätzlich vergleichbaren Unternehmen dasjenige besonders leistungsfähig ist, dem es am besten gelingt, Einfachheit zu verwirklichen, also die Komplexität im Unternehmenskontext möglichst gering zu halten. Für MALIK ist Komplexitätsmanagement daher zentrale Aufgabe des Managements; vgl. [Malik08], S. 159. 119 Vgl. [Dern09]. 120 Vgl. [Meff00] bzw. [AdJo98].

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

87

BÖHMANN und KRCMAR gehen davon aus, dass von Unternehmen zunehmend individualisierte und immer stärker ausdifferenzierte Leistungen gefordert werden, um im Wettbewerb bestehen zu können. Die Unternehmens-IT muss hierfür entsprechende, vielfältige Lösungen bereitstellen. Dies wird im Hinblick auf die Komplexität aus Sicht der Autoren umso problematischer, je größer die Vielfalt der Anforderungen auf Seiten der Nachfrager ist. Beispielsweise muss die Unternehmens-IT einer Universalbank IT-Systeme für alle Arten von Finanzierungsprodukten zur Verfügung stellen. Dies geht vom Konsumentenkredit, über den Sofortkredit, über Baufinanzierungslösungen, über Handelsfinanzierungslösungen und große Projektfinanzierungen bis hin zu Leasing- und Factoring-Lösungen. Werden für alle Produkte und Varianten Leistungen durch die IT-Organisation erbracht, sinkt die Kosteneffizienz der IT-Lösungen und damit der Finanzierungslösungen. Dies ist nach BÖHMANN und KRCMAR der Fall, weil: ƒ ƒ ƒ

die IT-Organisation für den Vertrieb der IT-Leistungen mehr Ressourcen – z. B. für die Angebotserstellung für die Anwenderorganisation – benötigt, mehr Varianten der IT-Prozesse auf Seiten der IT-Organisation notwendig werden, die Zahl der IT-Systeme, Subsysteme und Systemkomponenten, die Vielfalt der Vorgehensweisen bei Entwicklung und Produktion sowie die Vielfalt in der IT-Basisinfrastruktur steigen.

Folglich steigen die Komplexität der Unternehmens-IT und die damit verbundenen Kosten, insbesondere aufgrund steigender Integrationsleistungen, die durch die IT-Organisation erbracht werden müssen. So müssen etwa bei der o. a. Universalbank alle Finanzierungssysteme mit den Systemen für Meldewesen, Rating, Stammdatenmanagement, Treasury, Risikokontrolle usw. integriert werden. Werden diese komplexitätsbedingten Integrationskosten nicht verursachergerecht verrechnet, besteht die Gefahr der Quersubventionierung zwischen verschiedenen IT-Leistungen und in der Folge zwischen den Finanzierungsprodukten. Hochvolumige Standard-IT-Lösungen werden zu teuer, spezialisierte ITLeistungen mit geringer Stückzahl werden zu günstig angeboten. Hier stellt sich die Frage, welches Maß an Komplexität für ein Unternehmen angemessen ist. BÖHMANN UND KRCMAR folgend sollte dazu das Ziel der Sicherung der Lebensfähigkeit des Unternehmens in seiner Systemumwelt in den Mittelpunkt der Abwägung gestellt werden. Auf der einen Seite steht das statische Potenzial, mit dem ein Unternehmen auf Veränderungen der Umwelt reagieren kann. Hierunter ist laut BÖHMANN und KRCMAR die Anzahl der Alternativen zu verstehen, mit denen Veränderungen in der Unternehmensumwelt kompensiert werden können. Je größer diese Zahl - z. B. auf Seiten der Unterneh-

88

3 Entwicklung übergeordneter Gestaltungsempfehlungen

mens-IT -, umso größer ist die Fähigkeit des Unternehmens, auf zukünftige Veränderungen der Systemumwelt adäquat reagieren zu können und nicht in der Lebensfähigkeit bedroht zu werden. Die Fähigkeit des Unternehmens, Marktveränderungen in den verschiedenen Finanzierungsproduktsegmenten abzubilden, ist umso besser, je alternativenreicher und damit umfassender der Bestand an spezialisierten IT-Systemen innerhalb der Unternehmens-IT ist, die Finanzierungsprodukte und zugehörige Geschäftsprozesse abbilden können. Aus dieser Perspektive ist eine möglichst große Komplexität der Unternehmens-IT wünschenswert. Diesem positiven Effekt steht ein negativer Effekt gegenüber. Das Mehr an Alternativen in der Unternehmens-IT bewirkt eine Einschränkung des dynamischen Potenzials des Unternehmens. Hierunter wird die Fähigkeit verstanden, Umweltänderungen zeitgerecht zu kompensieren. Eine große Zahl von Systemelementen in der Unternehmens-IT führt zu einer erhöhten Selektionslast, da zu jeder neuen Leistungsanforderung an die Unternehmens-IT die passenden Systemelemente in IT-Organisation und IT-Landschaft gewählt und im Rahmen bestehender oder neu zu schaffender Interaktionsbeziehungen miteinander integriert werden. Bei einer großen Zahl möglicher Kombinationen muss der größte Teil der Möglichkeiten aussortiert werden. Reicht die Zeittoleranz für eine Reaktion auf die Umweltänderung nicht aus, um diesen Selektionsprozess durchzuführen, so ist die Lebensfähigkeit des Unternehmens gefährdet. Dies ist dann der Fall, wenn wegen der großen Vielfalt in Unternehmens-IT und Anwenderorganisation langwierige Prozesse der Auswahl und Integration passender Elemente der IT-Landschaft und der zugehörigen, für die Erfüllung der Leistungsanforderung notwendigen menschlichen Aufgabenträger in IT- und Anwenderorganisation notwendig werden. Daraus folgt, dass aufgrund eines großen statischen Potenzials große Integrationsleistungen durch die Unternehmens-IT erbracht werden müssen. Aus dieser Perspektive ist eine möglichst geringe Komplexität der Unternehmens-IT wünschenswert, damit das Unternehmen nicht nur das Potenzial zur Abbildung von Umweltänderungen innerhalb des Gesamtsystems hat, sondern diese Reaktion auf Umweltänderungen auch im Rahmen der verfügbaren Zeit geleistet werden kann. Um dieser Komplexitätsfalle zu entkommen, analysieren BÖHMANN UND KRCMAR Möglichkeiten der Komplexitätsreduktion bzw. der Begrenzung der Komplexitätssteigerung aufgrund zunehmender Ausdifferenzierung des Systems in Folge von Umweltänderungen.

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

89

3.2.1.4 Ansätze zur Komplexitätsreduktion bzw. zur Begrenzung der Komplexitätssteigerung Der erste von BÖHMANN UND KRCMAR analysierte Ansatz zur Komplexitätsreduktion besteht im Einsatz neuer Informations- und Kommunikationstechnologien. Dabei liegt die Zielsetzung darin, die Vielfalt der Leistungsanforderungen ohne Gefährdung des Gleichgewichts aus dynamischem und statischem Potenzial zu bewältigen und zudem einen unterproportionalen Anstieg der IT-Kosten zu erreichen. Kurz gesagt: Die der Anforderungsvielfalt folgende Komplexität der Unternehmens-IT soll durch Verbesserung der Technik beherrscht werden. Neue Standards, Architekturen und Werkzeuge sollen demnach Potenziale für die flexible, schnellere Gestaltung und Bereitstellung von IT-Leistungen eröffnen. Nach dem Modell zum Integrationsmanagement der vorliegenden Arbeit ist dies so zu interpretieren, dass neue Technologien dazu beitragen sollen, vielfältige Integrations- und fachliche Anforderungen durch effizientere Leistungserbringung zu befriedigen. Hier ist zu bedenken, dass neue Technologien a priori zunächst komplexitätssteigernd wirken, da neue Systemelemente und Interaktionsbeziehungen zur IT-Organisation und zur IT-Landschaft hinzugefügt werden, was die Gefahr der Reduktion des dynamischen Potenzials birgt. Neue Technologien können die beschriebene Wirkung nur dann entfalten, wenn sie ƒ ƒ

das statische Potenzial der Unternehmens-IT erhöhen, ohne dadurch das für die Lebensfähigkeit notwendige dynamische Potenzial einzuschränken oder das dynamische Potenzial erhöhen, ohne das mindestnotwendige statische Potenzial zu unterschreiten.

Darüber hinaus ist zu bedenken, dass die mit neuen Technologien verbundenen Risiken für die Unternehmens-IT beherrschbar bleiben müssen. Hierzu zählen z. B. der Reifegrad der Technologien oder die mit neuen Technologien verbundenen Know-how-Anforderungen. Zudem ist in der Regel davon auszugehen, dass der erfolgreiche Einsatz der Technologien durch ein Unternehmen dessen dynamisches Potenzial zwar erhöhen kann, die Nachahmung im Wettbewerb aber letztlich dazu führt, dass das für die Lebensfähigkeit im Markt des Unternehmens notwendige dynamische Potenzial insgesamt erhöht wird. Insgesamt ist die Wirkung des Einsatzes neuer Technologien zur Beherrschung der Anforderungsvielfalt an die Unternehmens-IT unter dem Blickwinkel des Komplexitätsdilemmas aus Sicht des Autors der vorliegenden Arbeit daher kritisch zu beurteilen. Dies gilt insbesondere auch in Bezug auf die Einführung neuer Integrationstechnologien. So hat nach den Erfahrungen des Autors der vorliegenden Arbeit die Einführung von Lösungen zur Enterprise Application

90

3 Entwicklung übergeordneter Gestaltungsempfehlungen

Integration (EAI)121 dazu beigetragen, das statische Potenzial von Unternehmen zu erhöhen, gleichzeitig aber das dynamische Potenzial - entgegen den Versprechungen der Hersteller von EAI-Lösungen - durch die Erhöhung der Komplexität gefährdet. Dies liegt insbesondere daran, dass die Wirkung von EAI häufig unter technologischer Perspektive mit Blick auf die Integration von IT-Systemen gesehen wird. Die Betrachtung der Wirkung auf die Gesamtkomplexität des Systems Unternehmens-IT mit ihren Teilsystemen IT-Organisation und ITLandschaft wird vernachlässigt.122 Der zweite von BÖHMANN UND KRCMAR diskutierte Ansatz zur Komplexitätsreduktion geht auf die o. a. Arbeit von BLISS123 zurück, der das Unternehmen als System in seiner Umwelt, der damit verbunden Kundenstruktur, des Leistungskatalogs usw. betrachtet. Nach BLISS steht die Komplexität eines Unternehmens nur in Bezug auf die Komplexität seines Leistungskatalogs mit der Komplexität seines Marktes in Beziehung. Dabei ist die Komplexität des Marktes bzw. der Systemumwelt keine objektive Größe, sondern manifestiert sich als durch das Unternehmen wahrgenommene Marktkomplexität. Der Begriff der korrelierten Komplexität des Unternehmens wird hier von Bliss verwendet, weil sich die Komplexität des Leistungskatalogs aus der durch das Unternehmen wahrgenommen Komplexität ableitet. Nach BÖHMANN UND KRCMAR besteht hier immer ein positiver Zusammenhang. Das heißt: Eine Steigerung der wahrgenommen Marktkomplexität führt zur Steigerung der Komplexität des Leistungskatalogs. Angewandt auf die Situation der Unternehmens-IT bedeutet dies, dass die Steigerung der Komplexität des Marktes der Unternehmens-IT – also die wahrgenommenen Komplexität der Anwenderorganisation - und der daraus hervorgehenden Vielfalt der Leistungsanforderungen gesteigerte Komplexität des durch die Unternehmens-IT angebotenen Leistungskataloges nach sich zieht. Komplexitätsmanagement der Unternehmens-IT muss sich an dieser Stelle daher ƒ ƒ

121

erstens auf die Reduktion der durch die Unternehmens-IT wahrgenommenen Marktkomplexität und zweites auf die Reduktion der Wirkung der Marktkomplexität124 auf den Leistungskatalog der Unternehmens-IT konzentrieren.

JUNG zeigt in [Jung06], dass die Begriffsbildung zu EAI diffus ist und den Charakter eines Schlagwortes ohne genaue Definition besitzt. Einige englischsprachige Autoren verwenden die Terminologie Integration of Enterprise Information Systems (EIS), die schon auf Begriffsebene betont, dass Integrationsaspekte der IT-Landschaft (i. S. der Begrifflichkeit der vorliegenden Arbeit) aus übergreifender Sicht im Vordergrund stehen. 122 Siehe dazu auch Abschnitt 4.4. 123 Vgl. [Bliss00]. 124 Im Rahmen eines Komplexitätsmanagements der Unternehmens-IT kann darüber hinaus über Möglichkeiten nachgedacht werden, die Komplexität auf Seiten der Anwenderorganisation zu redu-

91

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

Demgegenüber steht nach BLISS die Komplexität des Produktionsprogramms und Fertigungssystems sowie der dazu notwendigen Organisation in keinem direkten Bezug zur wahrgenommenen Marktkomplexität. Für die Unternehmens-IT bedeutet dies, dass die Komplexität von IT-Landschaft und ITOrganisation nicht unmittelbar von der wahrgenommenen geschäftlichen Komplexität, d. h. insbesondere der Anforderungsvielfalt, abhängen, sondern nur von der – veränderbaren – Komplexität des durch die Unternehmens-IT angebotenen Leistungskataloges. BLISS bezeichnet dies als autonome Komplexität. Die Übertragung der Überlegungen von BLISS in den Kontext der Unternehmens-IT ist in der folgenden Abbildung zusammengefasst.

Leistungsanforderung

positive Korrelation

positive Korrelation

IT-Landschaft

Leistungsanforderung

IT-Organisation

Informationsbedarf

Unternehmens-IT

Komplexität Leistungskatalog

Leistungsanforderung

Wahrgenommene Marktkomplexität

Anwenderorganisation

Nachfrager Nutzer

Anforderer

Komplexität Produktionsprogramm

Abbildung 49: Komplexitätsbezogene Korrelationen im Kontext von ITOrganisation und IT-Landschaft in Anlehnung an BLISS Auf der Basis der Komplexitätskorrelationen im Kontext der Unternehmens-IT können nach BLISS Maßnahmen des Komplexitätsmanagements ergriffen werden. Diese Maßnahmen sind in der folgenden Tabelle aufgeführt und in ihrer Wirktendenz auf die Reaktionsfähigkeit des Unternehmens dargestellt.

zieren. Dies bedeutet im Sinne der o.a. Maxime von MALIK - dass das einfachere unter grundsätzlich vergleichbaren Unternehmen das leistungsfähigere ist - das Überprüfen der Positionierung, des Geschäftsmodells und des Leistungsangebotes des Unternehmens und die kritische Reflexion jeder einzelnen Leistungsanforderung an die Unternehmens-IT.

92

3 Entwicklung übergeordneter Gestaltungsempfehlungen

Maßnahme

1. Autonome Komplexität U-IT 2. Korrelierte Komplexität U-IT 3. Wahrgenommene Komplexität Anwenderorganisation

Tabelle 2:

Reduktion

Wirktendenz statisches Potenzial neutral

Wirktendenz dynamisches Potenzial positiv

Reduktion

negativ

positiv

Reduktion

negativ

positiv

Schema zur Komplexitätsreduktion in der Unternehmens-IT

Schritt 1: Reduktion der autonomen Komplexität der Unternehmens-IT Für die Unternehmens-IT bedeutet dies die Durchführung von Maßnahmen zur Komplexitätsreduktion von IT-Organisation und IT-Landschaft. Dies geschieht durch die Reduktion der Zahl und der Vielfalt der Systemelemente, deren Interaktionsbeziehungen sowie der Dynamik der Veränderung und bewirkt die Steigerung des dynamischen Potenzials der Unternehmens-IT. Wegen der Korrelation mit dem Leistungskatalog der Unternehmens-IT ergibt sich für diese Reduktion die Notwendigkeit, mögliche Einschränkungen des Leistungskataloges zulasten des statischen Potenzials mit der Anwenderorganisation abzustimmen. Eine von BÖHMANN UND KRCMAR vorgeschlagene Maßnahme besteht hier in der Standardisierung der Elemente der IT-Landschaft sowie der IT-Prozesse. Hinsichtlich der Elemente der IT-Basisinfrastruktur und der IT-Prozesse ist dies heute gängige, erfolgreiche Praxis in der Unternehmens-IT. Komplexer stellt sich die Situation bzgl. der Standardisierung der IT-Systeme dar. Standardisierung von IT-Systemen kann nach BLISS als verstärkter Einsatz von normierten Softwarebausteinen für funktional identische Komponenten in verschiedenen ITSystemen verstanden werden. Dieses Ziel der Standardisierung wird z. B. durch das Paradigma der Service-orientierten Architekturen (SOA) adressiert. Dieses Paradigma besteht darin, normierte Funktionsbausteine zu schaffen und durch Standardisierung der Vorgehensweisen bei deren Design und Entwicklung sowie ihrer Integration mit den Elementen der IT-Landschaft die Komplexität zu reduzieren. Wie oben ausgeführt, ist dieses Komplexitätsreduktionsversprechen insofern kritisch zu hinterfragen, als dem unsicheren Versprechen längerfristig verbesserten statischen und dynamischen Potenzials ein kurz- bis mittelfristig reduziertes dynamisches Potenzial aufgrund zunächst gesteigerter Komplexität gegenübersteht. Als weiteren von BLISS identifizierten Treiber der autonomen Komplexität analysieren BÖHMANN UND KRCMAR die Vielfalt der Interaktionsbeziehungen

93

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

zwischen Nachfrager und IT-Dienstleister – also die Art der Integration dieser Systemelemente des Unternehmens. Eine starke, variantenreiche Integration der Nachfrager in die Prozesse der Leistungserbringung (s. Abbildung 47) zieht größere Komplexität auf Seiten der IT-Landschaft nach sich. Dies ist Folge der unkontrollierten Durchführung von Anpassungsleistungen an der IT-Landschaft durch die Mitglieder der IT-Organisation. Das heißt: Wenn Mitglieder der Anwenderorganisation unkontrolliert Interaktionsbeziehungen zu Mitgliedern der IT-Organisation aufbauen, besteht die Gefahr, dass die Komplexität der ITLandschaft ungesteuert wächst, weil zum Beispiel Standards zur Integration von IT-Systemen nicht zur Anwendung kommen. Die empfohlene Maßnahme zur Komplexitätsreduktion besteht daher in der Standardisierung der Nachfragerintegration. Nachfrager sollen möglichst wenig in die Prozesse der Leistungserbringung der Unternehmens-IT eingebunden sein. Dort, wo dies zwingend ist, soll die Einbindung standardisiert und kontrolliert erfolgen. Schritt 2: Reduktion der Stärke der korrelierten Komplexität Dies bedeutet die Durchführung von Maßnahmen, die die Stärke des Zusammenhangs von wahrgenommener Marktkomplexität und Leistungskatalog reduzieren und die somit darauf zielen, die Abhängigkeit des mindestnotwendigen statischen Potenzials der Unternehmens-IT von der Vielfalt der Leistungsanforderungen der Anwenderorganisation zu reduzieren. Als Maßnahmen extrahieren BÖHMANN UND KRCMAR aus der Arbeit von BLISS zum einen die Verschiebung des integrationsbezogenen Entkopplungspunktes zwischen Nachfrager und ITDienstleister und zum anderen die Bündelung und die Modularisierung. IT-Wertschöpfungskette

Nachfrager

IT-Dienstleister Verschiebung

Entkopplungspunkt

Abbildung 50: Verschiebung des integrationsbezogenen Entkopplungspunktes Bei der Erbringung von IT-Leistungen wird der integrationsbezogene Entkopplungspunkt nach BÖHMANN UND KRCMAR als die Stelle in der ITWertschöpfungskette verstanden, ab der die Leistungserbringung ohne Beteiligung des Nachfragers vollzogen werden kann. Die Zielsetzung der Maßnahme besteht darin, den Entkopplungspunkt möglichst früh in der Wertschöpfungskette zu platzieren. Dieses Ziel wird zum einen durch die Veränderung der Ausgestal-

94

3 Entwicklung übergeordneter Gestaltungsempfehlungen

tung der IT-Prozesse und zum anderen durch die Optimierung von ITArchitekturen innerhalb der IT-Landschaft erreicht. Eine von BÖHMANN UND KRCMAR vorgeschlagene Maßnahme zur Veränderung der IT-Prozesse besteht darin, Informationsbedarfe von Nutzern durch darauf spezialisierte Einheiten zu erheben, abzustimmen und in Leistungsanforderungen zu überführen. Ein solches Systemelement ist zum Beispiel eine Einheit zum Business Information Management (s. Abbildung 24). Dies bedeutet, dass in Abbildung 47 die Rolle des Anforderers durch eine Organisationseinheit zum Business Information Management übernommen wird und auf diese Weise die Integration zwischen Nutzer und IT-Dienstleister im Sinne der angestrebten Komplexitätsreduktion optimiert wird. Eine weitere Maßnahme zielt darauf, die Interaktion zwischen Nutzern und IT-Dienstleister nach der Produktivnahme von IT-Systemen auf wenige, standardisierte Integrationspunkte zu reduzieren. In Bezug auf die Veränderung der IT-Architekturen mit dem Ziel der Verschiebung des Entkopplungspunktes sehen BÖHMANN UND KRCMAR primär die Berücksichtigung nichtfunktionaler Leistungsmerkmale wie Mandantenfähigkeit und Parametrisierbarkeit. Auf diese Weise können spezifische Anforderungen der verschiedenen Nachfrager – zum Beispiel der verschiedenen BusinessDivisionen eines Finanzdienstleisters – durch Customizing anstelle von Programmierung erfüllt werden, sodass die Einbindung des Nachfragers frühzeitiger beendet werden kann und gleichzeitig keine weiteren Systemelemente und Interaktionsbeziehungen in der IT-Landschaft hinzugefügt werden müssen, um die Anforderungen der Nachfrager zu erfüllen. Während diese Maßnahme für einen IT-Dienstleister, der sich z. B. auf das Application-Hosting von ERP-Systemen (Enterprise Ressource Planning) spezialisiert hat, sinnvoll erscheint, ist die Umsetzung der Maßnahme innerhalb der über Jahrzehnte gewachsenen ITLandschaft größerer Unternehmen mit erheblichen Risiken behaftet: ƒ

ƒ

Handelt es sich um ein System zur Stammdatenverwaltung – etwa das Partnersystem eines Versicherungsunternehmens –, so hat die Veränderung des Systems hin zu einer flexibleren IT-Architektur aufgrund der zahlreichen, häufig unkontrolliert gewachsenen Implementierung von Informationsflüssen unmittelbare Auswirkungen auf die entlang dieser Flüsse integrierten Systeme und kann eine Komplexitätssteigerung bewirken. Handelt es sich um produktspezifische Systeme – beispielsweise verschiedene Systeme zur Unterstützung verschiedener Finanzierungsprodukte einer Universalbank –, so zieht die Veränderung hin zu einer flexibleren ITArchitektur eine komplette Restrukturierung aller betroffenen Produktsysteme nach sich und kann bis zum Austausch der betroffenen Systeme durch ein flexibleres Neusystem reichen.

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

95

Der Chance sinkender Komplexität steht in beiden Fällen das Risiko der Einschränkung des dynamischen Potenzials des Unternehmens während der Übergangsphase vom Alt- zum Neusystem gegenüber. Schritt 3: Reduktion der wahrgenommenen geschäftlichen Komplexität Als zentrale Maßnahmen sehen BÖHMANN UND KRCMAR die Bereinigung des Leistungskatalogs und der Kundenstruktur. Erstere ist im Kontext der Unternehmens-IT durch die bewusste Selektion von Leistungsanforderungen aus der Anwenderorganisation bedingt umsetzbar und führt zur Anpassung des ITLeistungskataloges. Die zweite Maßnahme ist gemäß des definierten Verständnisses der Unternehmens-IT nicht anwendbar. Die Reduktion des Leistungskataloges führt zu folgenden Effekten: ƒ ƒ ƒ

Das statische Potenzial wird reduziert. Das dynamische Potenzial wird gesteigert. Der Anstieg der Vielfalt der Leistungsanforderungen und damit der Integrationsanforderungen an die IT-Landschaft werden gebremst.

Die folgende Tabelle fasst die Detaillierung und Analyse des in Tabelle 2 entworfenen Schemas zum Komplexitätsmanagement zusammen. Daraus ergibt sich die Bewertung der aus der Arbeit von BÖHMANN UND KRCMAR abgeleiteten Maßnahmen. Deutlich wird, dass Maßnahmen sich vor allem auf die Verbesserung des dynamischen Potenzials konzentrieren und dass bei der Durchführung von Maßnahmen zwischen der längerfristig positiven Wirkung und der kurzfristigen Gefährdung des dynamischen Potenzials sowie einer möglichen Reduktion des statischen Potenzials der Unternehmens-IT abgewogen werden muss. Da sich das statische und das dynamische Potenzial der Unternehmens-IT unmittelbar auf die entsprechenden Potenziale des Gesamtunternehmens auswirken, muss der entsprechenden Abwägungsprozess zwingend unter der Beteiligung der Anwenderorganisation durchgeführt werden – idealerweise liegt hier auch das Entscheidungsmandat.

96

3 Entwicklung übergeordneter Gestaltungsempfehlungen

Maßnahmen zur Komplexitätsreduktion Ansatz I

Anwendbarkeit auf Unternehmens-IT ja

Wirktendenz auf statisches Potenzial

Standardisierung der Systemelemente

ja

Risiko

Standardisierung der Nachfragerintegration Verschiebung des integrationsbezogenen Entkopplungspunktes Optimierung der IT-Architekturen

ja

neutral

langfristig positiv kurz/mittelfristig Risiko positiv

ja

neutral

positiv

ja

Reduktion des Leistungskataloges Bereinigung der Kundenstruktur

bedingt

langfristig positiv kurz/mittelfristig Risiko Reduktion

langfristig positiv kurz/mittelfristig Risiko positiv

Einsatz neuer IuKTechnologien

positiv

Wirktendenz auf dynamisches Potenzial langfristig positiv kurz/mittelfristig Risiko

Ansatz II 1. Autonome Komplexität der U-IT

2. Korrelierte Komplexität der U-IT

3. Wahrgenommene Komplexität

Tabelle 3:

nein

Maßnahmenkatalog zur Komplexitätsreduktion der Unternehmens-IT unter Berücksichtigung der Potentialwirkung

3.2.1.5 Zusammenfassung und Gestaltungsempfehlungen In Abschnitt 3.2.1.4 wurden auf der Grundlage der systemtheoretischen Definition des Begriffes Komplexität Möglichkeiten zur Reduktion der Komplexität der Unternehmens-IT analysiert. Demzufolge muss aktives Komplexitätsmanagement Bestandteil eines ganzheitlichen Integrationsmanagements sein, da Ersteres unmittelbar auf die Verteilung der durch die Unternehmens-IT erbrachten Integrationsleistungen und Leistungen zur Erfüllung fachlicher Anforderungen wirkt. Aus Sicht eines ganzheitlichen Integrationsmanagements ergibt sich daraus die Forderung, bei der Weiterentwicklung der Unternehmens-IT Veränderungen der

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

97

Komplexität so zu begrenzen, dass das statische und das dynamische Potenzial die für die Lebensfähigkeit notwendigen Mindestniveaus nicht unterschreiten. Dabei muss insbesondere die Fähigkeit des Unternehmens erhalten bleiben, notwendige Integrationsleistungen nicht nur durchzuführen zu können, sondern auch termingerecht abzuschließen. Hier lautet die grundsätzliche Empfehlung, Variantenvielfalt zu reduzieren, da diese maßgeblich das dynamische Potenzial der Unternehmens-IT bestimmt. Aus der Analyse der Arbeit von BÖHMANN UND KRCMAR werden abgeleitet. Dazu wird zunächst folgende Definition vorgenommen: Definition – Reaktionsfähigkeit Die Reaktionsfähigkeit eines Systems ist der Grad, mit dem das System Umweltänderungen kompensieren kann. Die Reaktionsfähigkeit ergibt sich aus dem statischen und dem dynamischen Potenzial des Systems. Die für die Lebensfähigkeit des Systems erforderliche Reaktionsfähigkeit ist dann gegeben, wenn innerhalb einer gegeben Zustandskonfiguration des Systems das statische Potenzial und das dynamische Potenzial so verteilt sind, dass Umweltänderungen kompensiert werden können und diese Kompensation auch zeitgerecht geleistet werden kann. Gestaltungsempfehlung 1.1 – Erweiterung der IT-Prozesse um Bausteine zur Steuerung der Komplexitätswirkung, insbesondere in Bezug auf die Durchführung von IT-Projekten Da von IT-Projekten nach Erfahrung des Autors der vorliegenden Arbeit die größte Änderungswirkung auf die Komplexität der Unternehmens-IT ausgeht, sollte dies bei der Planung und Steuerung von IT-Projekten berücksichtigt werden. Auf der Grundlage der Analyse der Arbeit von Böhmann und Krcmar wird vorgeschlagen, zwei Dimensionen zu berücksichtigen und in die entsprechenden IT-Prozesse – z. B. den Prozess der IT-Projektdurchführung – zu integrieren.125 Dimension Reaktionsfähigkeit Darunter wird die Wirkung auf das dynamische und das statische Potenzial der Unternehmens-IT und damit des Unternehmens subsumiert. Die Bewertung der Wirkung auf die Reaktionsfähigkeit kann beispielsweise mithilfe einer qualitativen Bewertung im Rahmen einer Expertenschätzung126 vorgenommen werden. 125

Siehe dazu auch Abschnitt 4.5. Die konkrete Entwicklung von Quantifizierungsmethoden zum dynamischen und statischen Potenzial bietet Ansatzpunkte für weiterführende Forschungsaktivitäten. 126

98

3 Entwicklung übergeordneter Gestaltungsempfehlungen

Dabei sollte die Anwenderorganisation eingebunden werden. Die Analyse sollte die zeitliche Veränderung beinhalten – z. B. durch Vergleich der kurzfristigen Wirkung mit der längerfristigen. Dimension Komplexität Darunter wird die Wirkung auf die Zahl der Systemelemente in der Unternehmens-IT, die Zahl der Interaktionsbeziehungen und die Dynamik der Veränderung subsumiert. Die Analyse sollte ebenfalls die zeitliche Veränderung berücksichtigen. Die Komplexitätswirkung kann ebenfalls im Rahmen einer Expertenschätzung erfolgen qualitativ bewertet werden. Die Bewertung der erwarteten zeitlichen Veränderung dieser beiden Dimensionen ist insbesondere für Aktivitäten erforderlich, die explizit das Ziel der Komplexitätsreduktion der Unternehmens-IT verfolgen, da hier das Risiko im Zeitverlauf gegensätzlicher Wirkungen besteht. Positioniert sich beispielsweise eine Universalbank als Produktführer für alle Arten von Finanzierungsprodukten im Wettbewerb, so kann eine IT-Landschaft mit mehreren, hoch spezialisierten Finanzierungssystemen sinnvoll sein, da damit das für die einzelnen Produktlinien geforderte statische und dynamische Potenzial am besten gewährleistet werden kann. Umgekehrt kann ein standardisiertes Finanzierungssystem, das viele Produktlinien abdeckt, für einen Finanzdienstleister sinnvoll sein, der Preisführerschaft anstrebt. Initiativen zur Komplexitätsreduktion in der Unternehmens-IT sollten also vor dem Hintergrund der strategischen Positionierung127 des Unternehmens analysiert werden, da diese wesentlich die notwendigen Potenziale bestimmt. Die Berücksichtigung der Potenzial- und der Komplexitätswirkung einschließlich der zeitlichen Veränderung schafft darüber hinaus die Möglichkeit, die in Unternehmen häufig anzutreffende technologiezentrierte Sicht auf die Nutzung neuer Technologien zu überwinden, indem die Wirkung auf die Situation des Unternehmens in seiner Systemumwelt berücksichtigt wird. Gestaltungsempfehlung 1.2 – Aktive Gestaltung der Nachfragerintegration mit der IT-Organisation Dies bedeutet die gezielte Gestaltung der Integration der Anwenderorganisation und IT-Organisation entlang der IT-Wertschöpfungskette. Im Einzelnen beinhaltet dies folgende Maßnahmen:

127

Zu Modellen zur Beschreibung der strategischen Positionierung von Unternehmen vgl. [WaPe02]. Siehe dazu auch Abschnitt 5.3.2.1.

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

ƒ ƒ ƒ ƒ

99

Minimierung der Interaktionsbeziehungen zwischen IT-Nutzer und ITDienstleister Standardisierung der Prozesse der Anforderungsabstimmung zwischen Anwenderorganisation und IT-Organisation Einführung von Systemelementen auf Seiten der Anwenderorganisation, die auf die Anforderungserhebung und Abstimmung spezialisiert sind – wie zum Beispiel Einheiten zum Business Information Management Positionierung des integrationsbezogenen Entkopplungspunktes zu Beginn der IT-Wertschöpfungskette

Gestaltungsempfehlung 1.3 – Selektion von Leistungsanforderungen der Anwenderorganisation aufgrund systematischer Bewertung der Komplexitätswirkung Hierunter wird die bewusste Selektion von Leistungsanforderungen der Anwenderorganisation durch die Unternehmens-IT verstanden. Damit verbunden ist ein entsprechendes Rollenverständnis der Unternehmens-IT und das Bewusstsein, dass Einfachheit unter grundsätzlich vergleichbaren Unternehmen ein Wettbewerbsvorteil ist. Dies ist mit dem Anspruch verbunden, in der Anwenderorganisation Transparenz in Bezug auf die Wirkung der Umsetzung von Leistungsanforderungen auf die Komplexität zu schaffen und diejenigen Anforderungen zu erfüllen, die in ihrer Wirkung auf die Reaktionsfähigkeit und die Komplexität angemessen sind (siehe Gestaltungsempfehlung 1.1). Gestaltungsempfehlung 1.4 – Durchführung von Maßnahmen zur Standardisierung der Elemente der IT-Landschaft Solche Maßnahmen beziehen sich - wie Abschnitt 3.1.4.1.4 dargelegt hat – auf die IT-Basisinfrastruktur, IT-Systeme und IT-Prozesse. Dabei ist das Potenzial hinsichtlich der IT-Basisinfrastruktur und der IT-Prozesse optimistischer und das Potenzial hinsichtlich der IT-Systeme pessimistischer zu beurteilen.

100

3 Entwicklung übergeordneter Gestaltungsempfehlungen

Gestaltungsempfehlung 1.5 – Durchführung von Optimierungsmaßnahmen von IT-Architekturen zur Komplexitätsreduktion Dies sind Maßnahmen zur Restrukturierung oder zum Austausch von ITSystemen auf der Grundlage von IT-Architekturen, die nicht-funktionale Eigenschaften wie Parametrisierbarkeit und Mandantenfähigkeit vorsehen. Maßnahmen dieser Kategorie sind hinsichtlich ihrer Wirkung auf die Reaktionsfähigkeit und die Komplexität der Unternehmens-IT zu prüfen. 3.2.2 Ganzheitliche Lösungen zur Anwendungsintegration in der ITLandschaft 3.2.2.1 Integrationslösungen in der IT-Landschaft und das Business Engineering Framework Im Aufsatz Extending the Business Engineering Framework for Application Integration Purposes128 untersuchen SCHELP UND SCHWINN die Fragestellung, wie das Business Engineering Framework erweitert werden kann, sodass Integrationsanforderungen und Fragen der Integration von IT-Systemen systematisch aus Geschäftsanforderungen abgeleitet werden und die unternehmensübergreifende Sicht stärkere Berücksichtigung bei der häufig technologiefokussierten Einführung von EAI-Lösungen (Enterprise Application Integration) findet. Im Rahmen der Analyse der Arbeit von SCHELP UND SCHWINN wird zur begrifflichen Schärfung von Lösungen zur Anwendungsintegration in der ITLandschaft gesprochen, wobei Anwendung als Synonym zu IT-System zu verstehen ist. Im Mittelpunkt der Analyse der Autoren steht die Verzahnung der Entwicklung von Lösungen zur Anwendungsintegration in der IT-Landschaft mit einem Framework zur systematischen Gestaltung der Unternehmenstransformation. Die Arbeit fällt somit in die in Abschnitt 3.1 definierte zweite Gruppe von Arbeiten; es handelt sich um eine Arbeit, die Aspekte der übergreifenden Gestaltung der Unternehmens-IT adressiert, ohne den Fokus auf ganzheitliches Integrationsmanagement im Sinne des in Abschnitt 2.2.1 definierten Integrationsspektrums zu legen. Ausgangspunkt bildet für die Autoren die Kritik, dass Lösung zur Anwendungsintegration in der Regel einem technologiezentrierten Ansatz folgten und unzureichend mit den Anforderungen der Geschäftsebene verzahnt seien. Gleichzeitig steht nach SCHELP UND SCHWINN mit dem Business Engineering Framework129 ein ganzheitliches Vorgehen zur Verfügung, das die geschäftlich 128 129

Vgl. [ScheSchw05]. Zum Business Engineering vgl. [ÖstWiBa03].

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

101

getriebene Gestaltung der IT-Landschaft umfasst. Aus Sicht von SCHELP UND SCHWINN werden in der durch das Business Engineering angebotenen Methodik jedoch Aspekte der Anwendungsintegration in der IT-Landschaft nicht ausreichend berücksichtigt. Die Problematik besteht aus Sicht der Autoren also darin, dass auf der einen Seite Lösungen zur Anwendungsintegration in der ITLandschaft technologiefokussiert eingeführt werden und auf der anderen Seite Vorgehensweisen wie das Business Engineering Framework Anwendung finden, die die Geschäftsebene systematisch einbeziehen, Aspekte der Anwendungsintegration in der IT-Landschaft dabei jedoch vernachlässigen. Business Engineering bezeichnet die methodenorientierte und modellbasierte Konstruktionslehre für Unternehmen des Informationszeitalters. Business Engineering beschäftigt sich mit Problemstellungen, die aus der Transformation der Industrie- in die Informationsgesellschaft entstehen. Das Business Engineering Framework beruht auf einer systemtheoretischen Grundkonzeption und folgt einem holistischen Ansatz, der die für die Lebensfähigkeit des Unternehmens in seiner Umwelt notwendigen Veränderungen in den Mittelpunkt stellt. Die Bestimmung der lebensnotwendigen Veränderungen des Unternehmens umfasst die Veränderungen der IT-Landschaft, die für diese Transformation des Unternehmens erforderlich sind. Dazu werden auf der Grundlage einer systematischen, geschäftlich orientierten Strategie- und Anforderungserhebung die Leistungsmerkmale und die Struktur der IT-Landschaft entworfen. Dabei gilt es Potenziale neuer IuK-Technologien im Hinblick auf neue Geschäftsmodelle zu analysieren.130 Die folgende Abbildung gibt einen Überblick über die Grundstruktur des Business Engineering Framework einschließlich ausgewählter Artefakte und Fragestellungen. Die verwendete Terminologie wurde dabei auf die vorliegende Arbeit angepasst.

130

Hier zeigen sich Analogien des Business Engineering Framework zum EWIM-Ansatz von BEN-

SON UND PARKER.

102

3 Entwicklung übergeordneter Gestaltungsempfehlungen

Business Engineering Framework 1. Strategieebene – Was ist das Geschäftsmodell des Unternehmens? Wettbewerbsposition

Kernkompetenze n des Unternehmens

Kundensegemente

…

2. Prozessebene – Wie soll das Geschäftsmodell betrieben werden? Prozessarchitektur

Funktionen innerhalb der Prozesse?

Rollen

Geschäftsanforderungen (Informationsbedarfe)

…

3. Ebene – Womit wird die Automation der Geschäftsprozesse implementiert? Logische Ebene (Applikationsebene)

Anwendungsfunktionen

Clustern der Anw.-Funktionen zu Anwendungen

Informationsobjekte

Informationsflüsse

…

Physische Ebene (Softwarekomponenten und Datenstrukturen)

SoftwareBausteine

Datenstrukturen

Softwarearchitektur

Datenelemente

…

IT-Landschaft

Ebene der IT-Systeme

Analyse- und Ableitungsprozess

Rolle in der Wertschöpfungskette

4. Infrastrukturebene – Womit werden IT-Systeme implementiert und betrieben?

Hardware

Welche Netzwerktopologien

Systemsoftware

…

…

Abbildung 51: Grundkonzeption des Business Engineering Framework Ausgangspunkt der Konstruktion des Unternehmens des Informationszeitalters mithilfe des Business Engineering Framework bildet die Analyse der Strategieebene, der die Analyse auf Geschäftsprozessebene folgt. Auf der Ebene der IT-Systeme besteht ein wesentlicher Analyse- und Design-Schritt darin, zu entscheiden, welche aus Geschäftsprozessen genutzten geschäftlichen Funktionen durch welche IT-Systeme unterstützt werden sollen. Dazu definiert das Business Engineering Framework auf der dritten Ebene die Artefakte Anwendung und Anwendungsfunktion. Anwendungsfunktionen sind logische Repräsentationen der geschäftlichen Funktionen der Prozessebene auf der Ebene der IT-Systeme. Anwendungen entstehen durch die Gruppierung von Anwendungsfunktionen. Die physische Ebene der IT-Systeme umfasst Softwarebausteine, Datenbanken und Datenelemente, d. h. die Bausteine, die Anwendungsfunktionen unter Nutzung der Elemente der Infrastrukturebene implementieren. Die Kritik von SCHELP UND SCHWINN kann so interpretiert werden, dass Lösungen zur Anwendungsintegration i. d. R. lediglich die unteren Ebenen des Business Engineering Framework adressieren und nicht aus einem ganzheitlichen Ableitungsprozess hervorgehen, der seinen Ausgangspunkt auf der Strate-

103

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

gieebene hat. Dies ist in Abbildung 52 dargestellt. Für die Autoren stellt sich die Frage, wie das Business Engineering Framework erweitert werden kann, um Lösungen zur Anwendungsintegration in der IT-Landschaft abzuleiten, die dem Anspruch einer unternehmensweiten, auf der Geschäftsebene verankerten Integration von IT-Systemen gerecht werden. Business Engineering Framework 1. Strategieebene

2. Prozessebene

IT-Landschaft

3. Ebene der IT-Systeme Logische Ebene Physische Ebene

4. Infrastrukturebene

herkömmliche Lösungen zur Anwendungsintegration in der ITLandschaft

Abbildung 52: Kritik der Technologiefokussierung von Lösungen zur Anwendungsintegration nach SCHELP UND SCHWINN Im Mittelpunkt der Erweiterung des Business Engineering Framework durch SCHELP UND SCHWINN steht die Überlegung, dass angesichts umfassender IT-Landschaften bei der Analyse und Spezifikation der dritten Ebene nicht nur die Frage beantwortet werden muss, welche IT-Systeme benötigt werden, um die Automation der Prozessebene zu unterstützen. Vielmehr ist auch die Frage zu beantworten, aufgrund welcher geschäftlich getriebenen Integrationsanforderungen, welche IT-Systeme wie zu integrieren sind. Auf diese Weise adressieren die Autoren beide o. a. Kritikpunkte. Zum einen definieren sie einen Weg zur ganzheitlichen Erweiterung von Integrationslösungen, die die zu starke technologische Fokussierung bestehender Ansätze aufhebt. Zum anderen führen sie die Gestaltung von Integrationslösungen als eigene Teildisziplin in das Business Engineering Framework ein, sodass die geschäftlich getriebene Integration von IT-Systemen stärkere Berücksichtigung findet. Zu diesem Zweck schlagen die Autoren drei zusätzliche Artefakte für das Business Engineering Framework vor: ƒ

Geschäftsintegrationsanforderung (Business Integration Requirement, BIR) Dies sind aus Geschäftsanforderungen abgeleitete Integrationsanforderungen, die durch die Integration von IT-Systemen erfüllt werden sollen.

104

ƒ

ƒ

3 Entwicklung übergeordneter Gestaltungsempfehlungen

Beispiel: Forderung nach der Integration von IT-Systemen eines Kreditinstituts mit dem Ziel, Liquiditäts-Cashflows aus dem Bankbuch für die Liquiditätssteuerung im Treasury des Instituts bereitzustellen Anwendungsintegrationsbeziehung (Application Integration Relationship, AIR) Dies sind logische Beziehungen zwischen IT-Systemen, entlang derer Informationsobjekte aufgrund von definierten Geschäftsintegrationsanforderungen ausgetauscht werden. Nach dem Verständnis der vorliegenden Arbeit sind dies Informationsbeziehungen. Eine Anwendungsintegrationsbeziehung manifestiert sich in Informationsflüssen zwischen den an der Beziehung beteiligten IT-Systemen und ist auf der Ebene der Anwendungsfunktionen angesiedelt. Entlang des Informationsflusses werden Informationsobjekte ausgetauscht. Beispiel: Informationsflüsse zwischen positionsführenden Systemen und dem Data Warehouse des Kreditinstituts sowie zwischen dem Data Warehouse und dem Cashflow-Generator für Liquiditäts-Cashflows. Technische Integrationsbeziehung (Technical Integration Relationship, TIR) Technische Integrationsbeziehungen implementieren Anwendungsintegrationsbeziehungen und manifestieren sich im Austausch von Datenelementen zwischen den beteiligten Softwarebausteinen, d. h. in Datenflüssen. Der Datenaustausch wird mithilfe von Bausteinen der IT-Basisinfrastruktur (Middleware-Komponenten) realisiert. Beispiel: mittels MQ (Message Queueing) realisierte Einlagendatenlieferung aus dem Distributionsbereich eines Data Warehouse an einen Cashflow-Generator

Abbildung 53 veranschaulicht das Konzept der Integrationsbeziehung. Logische Ebene AnwendungsFunktionen

InformatinsObjekte

InformationsElemente

Logische Ebene

AIR

AnwendungsFunktionen

Anwendung

Datenbanken

IT-System

InformationsElemente

Anwendung

Physische Ebene Softwaremodule

InformationsObjekte

Datenelemente

TIR

Physische Ebene Softwaremodule

Datenbanken

Datenelemente

IT-System

Abbildung 53: Integrationsbeziehungen zwischen IT-Systemen nach SCHELP UND SCHWINN

105

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

Die Erweiterung des Business Engineering Framework nach SCHELP UND SCHWINN wird in der folgenden Abbildung zusammengefasst.131 Business Engineering Framework

Erweiterung

Strategieebene

IS-Ebene

logisch

Prozess

Funktion

Geschäftsanforderung

IT-System

Anwendungsfunktion

Informationsobjekt

Informationsfluss

AIR

SoftwareBaustein

Datenelement

Datenfluss

TIR

physisch

BIR

Infrastrukturebene MiddlewareKomponenten

IT-Landschaft

Prozessebene

Abbildung 54: Erweiterung des Business Engineering Framework zur Verzahnung von Prozessebene und IS-Ebene 3.2.2.2 Abbildung auf das Modell zum Integrationsmanagement der Arbeit Auf Basis dieser Analyse kann die Projektion der Arbeit von SCHELP UND SCHWINN auf das Grundmodell zum Integrationsmanagement der vorliegenden Arbeit aus Abbildung 33 folgendermaßen charakterisiert werden; die Projektion ist in der nachfolgenden Abbildung dargestellt: ƒ ƒ ƒ

131

Geschäftsanforderungen entsprechen erhobenen Informationsbedarfen und definierten Effizienzzielen. Geschäftsintegrationsanforderungen (BIR) entsprechen Leistungsanforderungen an die Unternehmens-IT, hier den Integrationsanforderungen (IANF) auf Basis zu befriedigender Informationsbedarfe oder Effizienzziele. Bei der Erbringung von Integrationsleistungen werden Geschäftsintegrationsanforderungen analysiert, Anwendungsintegrationsbeziehungen (AIR)

SCHELP UND SCHWINN entwerfen ein Metamodell, das in Form eines Entity-RelationshipDiagramms die Erweiterung detailliert beschreibt. Ausgehend vom begrifflichen Fundament der vorliegenden Arbeit werden in Abweichung zu diesem Modell Middleware-Komponenten nicht auf der physischen Ebene der dritten Ebene, sondern auf der vierten Ebene des Business Engineering Frameworks platziert.

106

3 Entwicklung übergeordneter Gestaltungsempfehlungen

identifiziert, auf technische Integrationsbeziehungen (TIR) abgebildet und implementiert. Unternehmen als komplexes System Unternehmensumwelt

Geschäftsprozesse

IB

Unternehmensumwelt

IE

Schnittstelle

Schnittstelle

Management des Gesamtunternehmens

IE

EFFZ

Geschäftsanforderungen

Anwenderorganisation Informationsfluss

IE

IB

EFFZ

Anforderungsfluss intern/extern initiiert

EFFZ Effizienzziel

LANF

IB Informationsbedarf LANF Leistungsanforderung an U-IT IANF Integrationsanforderung an U-IT

INTL

IE Informationselement IS = IT-System Legende

FANF

IS INTL

IT-Prozesse

INTL Integrationsleistung der U-IT FANF Fachliche Anforderung i.e.S.

IANF

BIR, aus geschäftlichen Anforderungen abgeleitet

Zweck: InfoTransformation zur Befriedigung Info-Bedarf

Zweck: Planung/Steuerung/ Weiterentwicklung/Betrieb IT-Landschaft

IT-Landschaft

IT-Organisation

AIR wird im Rahmen der Erbringung der INTL analysiert, in eine TIR überführt und umgesetzt

Zweck: Effiziente Befriedigung Informationsbedarf

Unternehmens-IT

Abbildung 55: Projektion des Aufsatzes von SCHELP UND SCHWINN auf das Modell zum Integrationsmanagement 3.2.2.3 Ganzheitliche Integrationslösungen Die Ergebnisse der Arbeit von SCHELP UND SCHWINN werden so interpretiert, dass Lösungen zur Anwendungsintegration in der IT-Landschaft nicht auf die Betrachtung von Software- und Infrastrukturkomponenten reduziert werden dürfen, die der Realisierung von Datenflüssen zwischen IT-Systemen dienen. Nach dem Verständnis von SCHELP UND SCHWINN entsteht eine über die technologische Sicht hinausgehende Integrationslösung durch die Berücksichtigung aller Ebenen des erweiterten Business Engineering Framework. Eine solche Lösung entsteht nach SCHELP UND SCHWINN in folgenden Schritten: 1.

Ableitung von Geschäftsintegrationsanforderungen aus Geschäftsanforderungen, die in der Strategieebene begründet sind

107

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

2. 3. 4.

Überführung der Geschäftsintegrationsanforderungen in Anwendungsintegrationsbeziehungen Ableitung technischer Integrationsbeziehungen Implementierung der technischen Integrationsbeziehungen auf der Grundlage von IT-Prinzipien und -Standards132 zur Integration von IT-Systemen mithilfe von Middleware-Komponenten

Das Artefakt der ganzheitlichen Integrationslösungen wird mithilfe eines Modells zusammengefasst, das in der folgenden Abbildung dargestellt ist. Integrationslösungen, die auf diesem Modell basieren, werden in der vorliegenden Arbeit als ganzheitliche Integrationslösung bezeichnet. Ein Beispiel einer ganzheitlichen Integrationslösung ist ein unternehmensweites Data-WarehouseSystem, das systematisch entlang dieses Modells aufgebaut wird.133 Ganzheitliche Integrationslösung

umfasst

IT-Unternehmensarchitektur

1..1

0..n

Geschäftsanforderung

0..n

0..n

IT-Leitlinie, -Prinzip, -Standard

0..n 0..n

adressiert

0..n

folgt

führt zu 1..n

0..n

Integrationstechnologie

folgt 1..n

folgt

BIR

MiddlewareKomponente

1..n

1..n umgesetzt mit

überführt in 1..n

AIR

1..n

1..n 1..n überführt in

1..n

TIR

1..n

Abbildung 56: Modell zur Entwicklung ganzheitlicher Integrationslösungen Abschließend kommen SCHELP UND SCHWINN zur folgenden Bewertung der vorgeschlagenen Erweiterung des Business Engineering Framework:

132 Nach dem Verständnis der vorliegenden Arbeit sind solche die Integration von Systemen in der IT-Landschaft betreffenden Prinzipien und Standards Teil der IT-Integrationsarchitektur des Unternehmens und damit Bestandteil der IT-Unternehmensarchitektur. Siehe dazu Abschnitt 2.3.3. 133 In der in Abschnitt 5.3 beschriebenen Fallstudie eines international agierenden Finanzdienstleisters werden Data-Warehouse-Systeme beschrieben, die als ganzheitliche Integrationslösung zu verstehen sind.

108 ƒ ƒ ƒ ƒ

3 Entwicklung übergeordneter Gestaltungsempfehlungen

Die Erweiterung erlaubt die rollenspezifische Gestaltung ganzheitlicher Integrationslösungen durch die Verankerung auf der Geschäftsprozess- und der IS-Ebene. Integrationsspezifische Anforderungen (BIR) werden systematisch aus Geschäftsanforderungen abgeleitet. Die nachvollziehbare, mit der Geschäftsprozessebene verzahnte Entwicklung wiederverwendbarer Integrationslösungen wird unterstützt. Die systematische Entwicklung von Integrationslösungen ermöglicht Standardisierung. Dies schafft die Voraussetzung, um unkontrolliertes Wachstum von Software-Bausteinen und Middleware-Komponenten zu vermeiden.

3.2.2.4 Zur Gestaltung eines Portfolios von Integrationslösungen SCHELP UND SCHWINN zeigen in ihrem Aufsatz die Defizite herkömmlicher Ansätze zur Enterprise Application Integration auf. Sie bestehen darin, dass unternehmensweit aufgestellte EAI-Lösungen nicht systematisch in der Geschäftsebene begründet sind. Wird darauf verzichtet, besteht das Risiko der Komplexitätssteigerung der IT-Landschaft, ohne dass die zusätzliche Komplexität sich wertsteigernd für das Unternehmen auswirkt. Zielsetzung sollte daher sein, für ein Unternehmen ein angemessenes Portfolio von Integrationslösungen aufzustellen, zu managen und mit der Geschäftsebene zu verzahnen. Dieser Aspekt wird in der Arbeit von SCHELP UND SCHWINN nicht betrachtet. Diese Lücke wird durch den Entwurf einer Methode zum Management eines Portfolios von Integrationslösungen geschlossen. Dabei sind sowohl bestehende als auch geplante Integrationslösungen zu berücksichtigen, zu bewerten und die Lebenszyklusplanung ist vorzunehmen. Hier können die Wirkung sowohl auf die Reaktionsfähigkeit als auch auf die Komplexität, wie in Abschnitt 3.2.1 beschrieben, berücksichtigt werden.134 Die Methode135 wird in Abbildung 57 zusammengefasst. Sie umfasst folgende Aktivitäten: 1.

2.

134

Ganzheitliche Anforderungsanalyse – übergreifende Ableitung der Geschäftsintegrationsanforderungen aus den Geschäftsanforderungen des Unternehmens Ist-Analyse – Analyse bestehender Integrationslösungen in Bezug auf funktionale (z. B. Unterstützung von Geschäftsintegrationsanforderungen) und

Ein auf der Komplexitätsbetrachtung basierendes Lebenszyklusmodell wird in Abschnitt 4.6.2 entwickelt. 135 In Abschnitt 4.7 wird beschrieben, wie dieses Modell in die IT-Prozesse eingebettet werden kann.

109

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

3.

4.

5.

6.

nicht-funktionale (z. B. Einhaltung von Prinzipien und Standards der ITUnternehmensarchitektur) Anforderungen Portfolioentwurf – Definition eines Portfolios von Integrationslösungen, insbesondere ganzheitlicher Integrationslösungen, unter Berücksichtigung der Ergebnisse der Ist-Analyse und im Abgleich mit den Prinzipien und Standards der IT-Unternehmensarchitektur Bewertung der Portfolioobjekte – begleitende Bewertung von Integrationslösungen unter Einbeziehung der Wirkung auf die Reaktionsfähigkeit und die Komplexität der Unternehmens-IT Laufendes Lebenszyklusmanagement – systematisches Management der Integrationslösungen auf Basis der für jede Lösung vorgenommenen Lebenszyklusplanung Implementierung von Integrationslösungen – Umsetzung der geplanten Lebenszyklusverläufe, z. B. durch den Aufbau neuer Integrationslösungen oder durch die Restrukturierung oder Stilllegung bestehender Lösungen unter Abgleich mit den Prinzipien und Standards der IT-Unternehmensarchitektur Bewertung und Optimierung des Portfolios unter Einbeziehung der Wirkung auf Komplexität und Reaktionsfähigkeit 4

Portfolio-Bewertung 1

Ganzheitliche Anforderungsanalyse

Bestimmung Geschäftsintegrationsanforderungen

2

3

5

Ist-Analyse

PortfolioEntwurf

Laufendes LebenszyklusManagement

Aufnahme und Bewertung existierender Integrationslösungen

Abgrenzung des notwendigen Portfolios von Integrationslösungen

Systematisches Management der Integrationslösungen

6

Implementierung geplanter Integrationslösungen

IT-Prinzipien & IT-Standards

IT-Integrationsarchitektur IT-Unternehmensarchitektur

Abbildung 57: Eine Methode zum Management eines Portfolios ganzheitlicher Integrationslösungen

110

3 Entwicklung übergeordneter Gestaltungsempfehlungen

3.2.2.5 Leistungsfähigkeit der Unternehmens-IT bei der Erbringung von Integrationsleistungen SCHWINN entwickelt in seiner Dissertationsarbeit Entwicklung einer Methode zur Gestaltung von Integrationsarchitekturen für Informationssysteme136 ausgehend von der beschriebenen Erweiterung des Business Engineering Framework eine Methode zur Gestaltung von Integrationsarchitekturen von IT-Systemen. Die Dissertationsarbeit stellt – basierend auf dem Begriffsverständnis des Business Engineering Framework – die Forschungsfrage in den Mittelpunkt, wie die Anwendungsintegration in heterogenen IT-Landschaften auf der Applikationsebene und auf der physischen Ebene möglichst effektiv und effizient gestaltet und methodisch unterstützt werden kann. Effektivität bemisst sich für SCHWINN nach dem Grad der Erfüllung der die Integration treibenden Geschäftsanforderungen, Effizienz nach den durch die Integration von IT-Systemen verursachten Kosten. Die Effizienz bezieht sich dabei nicht auf einzelne Anforderungen, sondern auf die insgesamt durch die ITOrganisation in der IT-Landschaft erbrachten Integrationsleistungen. SCHWINN schlägt vor, die von der IT-Organisation erbrachten Aufwände für die Integration von IT-Systemen in jedem IT-Projekt zu erheben. Nach dem begrifflichen Fundament der vorliegenden Arbeit werden Integrationsanforderungen als Anforderungen verstanden, die darauf zielen, Interaktionsbeziehungen von Systemelementen der Unternehmens-IT zu verändern. Die Betrachtung der Integrationseffizienz durch SCHWINN bezieht sich auf die Veränderung der Interaktion der Systemelemente der IT-Landschaft, d. h. auf die Integration von IT-Systemen entlang von Informationsbeziehungen. Da die Komplexität der in IT-Projekten relevanten Integrationsanforderungen unterschiedlich sein kann, empfiehlt SCHWINN, die Aufwände je Projekt mit der Bewertung der Komplexität der Anforderungen zu gewichten. In der vorliegenden Arbeit wird vorgeschlagen, diese Bewertung aus Sicht der IT-Organisation vorzunehmen. Die gewichteten Aufwände werden über alle IT-Projekte für eine definierte Periode summiert und gemittelt. Die so definierte Größe wird in der vorliegenden Arbeit als Integrationseffizienz der IT-Organisation bezeichnet. Es ergibt sich die folgende Kennzahl – kleinere Werte bedeuten dabei höhere Effizienz:

136

Vgl. [Schwinn06].

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

IE =

111

Integrationseffizienz der Unternehmens-IT = N

䌥 i=1

[IAi × IKi ] , N

mit

Formel 2:

N

= Anzahl IT-Projekte im Betrachtungszeitraum

IAi

= Aufwand für Integrationsleistungen der IT-Organisation im IT-Projekt i, i=1,…,N

IKi

= Komplexitätsbewertung der Integrationsanforderungen im IT-Projekt i, 0 ˺IKi ˺1

Integrationseffizienz der IT-Organisation basierend auf SCHWINN

Integrationsmanagement zielt darauf, Integrationsaufwände zugunsten fachlicher Anforderungen zu reduzieren. Die Kennzahl der Integrationseffizienz schafft die Möglichkeit, die Leistungsfähigkeit der Unternehmens-IT in Bezug auf Integrationsleistungen zu bewerten und u. a. die Wirkung des oben beschriebenen Portfolios von Integrationslösungen zu steuern. Voraussetzung für die Einführung der Kennzahl ist die Modifikation des in IT-Projekten eingesetzten Verfahrens zur Aufwandsverfolgung.137 Diese Modifikation muss sicherstellen, dass in allen Projekten, die durch die Erbringung von Integrationsleistungen verursachten Aufwände einheitlich erhoben werden. 3.2.2.6 Zusammenfassung und Gestaltungsempfehlungen Auf der Grundlage der Erweiterung des Business Engineering Framework durch SCHELP UND SCHWINN wurde das Modell der ganzheitlichen Integrationslösung in der IT-Landschaft entwickelt. Ausgehend von SCHWINNS Dissertationsarbeit wurde eine Kennzahl zur Leistungsfähigkeit der IT-Organisation bei der Erbringung von Integrationsleistungen definiert. Zusammenfassend ergeben sich die folgenden Gestaltungsempfehlungen: Gestaltungsempfehlung 2.1 – Verankerung ganzheitlicher Integrationslösungen auf Geschäftsebene Lösungen zur Anwendungsintegration in der IT-Landschaft sollten auf der Strategie- und Geschäftsebene verankert werden.

137

Siehe dazu Abschnitt 4.5.

112

3 Entwicklung übergeordneter Gestaltungsempfehlungen

Gestaltungsempfehlung 2.2 – Entwicklung ganzheitlicher Integrationslösungen als eigenständige Disziplin der Gestaltung der IT-Landschaft innerhalb der Leitplanken der IT-Unternehmensarchitektur Durch die Einführung des Konzeptes der ganzheitlichen Integrationslösung wird der Tatsache Rechnung getragen, dass ƒ ƒ ƒ

angesichts umfangreicher bestehender IT-Landschaften die systematische Gestaltung von aus Geschäftsanforderungen abgeleiteten Integrationslösungen als eigenständige Disziplin der Weiterentwicklung der Unternehmens-IT betrachtet werden sollte.

Die Entwicklung von Integrationslösungen erfolgt innerhalb der durch die IT-Unternehmensarchitektur definierten Prinzipien, Standards, Modelle und Muster zur Integration von IT-Systemen, welche die IT-Integrationsarchitektur konstituieren. Dies ist in der nachfolgenden Abbildung zusammengefasst Unternehmen (Ziel-Situation) Entwicklung ganzheitlicher Integrationslösungen – Bestandteil der Weiterentwicklung der Unternehmens-IT zur Sicherstellung der Lebensfähigkeit des Unternehmens

Unternehmen

L

= ken lan ei tp

(Ist-Situation) Einheiten der Anwenderorganisation

L

IT-

sar tion gra Inte

ke lan eitp

n=

I IT-

nte

Einheiten der Anwenderorganisation Unternehmens-IT

tur tek chi

s ar tion gra

te chi

r ktu

Unternehmens-IT

Abbildung 58: Entwicklung von Integrationslösungen als eigenständige Disziplin der Weiterentwicklung der Unternehmens-IT Gestaltungsempfehlung 2.3 – Management eines Portfolios von Integrationslösungen Lösungen zur Anwendungsintegration in der IT-Landschaft sollten im Rahmen einer definierten Portfoliomethode mithilfe dedizierter Artefakte der Geschäfts-, der Anwendungs- und der Infrastrukturebene abgrenzt und bewertet werden. Die Bewertung von Integrationslösungen berücksichtigt die Wirkung auf das stati-

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

113

sche und das dynamische Potenzial des Unternehmens (Reaktionsfähigkeit) und auf die Komplexität der Unternehmens-IT. Auf diese Weise kann ein in der Geschäftsebene verankertes Portfolio von Integrationslösungen definiert und gemanagt werden. Aus der Analyse der Dissertationsarbeit von SCHWINN in Abschnitt 3.2.2.5 folgt als weitere Gestaltungsempfehlung: Gestaltungsempfehlung 2.4 – Einführung einer Kennzahl zur Bewertung und Steuerung der Leistungsfähigkeit der IT-Organisation in Bezug auf Integrationsleistungen 3.2.3 Integration der Unternehmens-IT in adaptive Unternehmensarchitekturen Im Aufsatz Fractal architecture for the adaptive complex enterprise138 weist RAMANATHAN darauf hin, dass Unternehmen in immer größerem Maße auf sich verändernde Bedingungen der Unternehmensumwelt reagieren müssen. Eine Möglichkeit, diesen Veränderungen zu begegnen, besteht für RAMANATHAN darin, Unternehmen hin zum so genannten Sense-and-Response-Unternehmen (S-R-Unternehmen) zu entwickeln. Die Unternehmens-IT ist aus Sicht der Autorin gefordert, diesen Wandel zu ermöglichen. Die Arbeit von RAMANATHAN fällt in die in Abschnitt 3.1 definierte zweite Gruppe von Arbeiten. Es handelt sich um eine Arbeit, die Aspekte der übergreifenden Gestaltung der Unternehmens-IT adressiert, ohne den Schwerpunkt auf das ganzheitliche Integrationsmanagement im Sinne des in Abschnitt 2.2.1 definierten Integrationsspektrums zu setzen. Im Folgenden wird zunächst der Sense-and-Response-Ansatz (S-R-Ansatz) beschrieben. Dann wird die Problematik eindimensionaler Integrationslösungen in Bezug auf den S-R-Ansatz diskutiert. Anschließend werden die Merkmale der von der Autorin entworfenen adaptiven, fraktalen Architektur komplexer Unternehmen (ACE-Architecture) analysiert. Dann wird eine ganzheitliche Integrationslösung entworfen, die den Ansprüchen einer ACE-Architektur genügt. Die Analyse wird in Form von Gestaltungsempfehlungen zusammengefasst.

138 Vgl. [Raman05]. RAMANATHAN ist Director of Research at the Centre for Enterprise Transformation and Innovation within the Computer Science and Engineering Department an der Ohio State University.

114

3 Entwicklung übergeordneter Gestaltungsempfehlungen

3.2.3.1 Das adaptive Sense-Response-Unternehmen Nach RAMANATHAN beruhen Geschäftsstrategien und Modelle zur Beschreibung des Geschäftes heute in der Regel auf Ansätzen, die Variation nicht als Prinzip beinhalten, sondern die im Gegenteil versuchen, Variation zu eliminieren. Diese Beseitigung von Variation manifestiert sich nach RAMANATHAN vor allem in den verwendeten Methoden und Modellen beim Business Re-Engineering139 und hier vor allem bei der Modellierung der Geschäftsprozesse. Die Autorin kritisiert, dass die Modellierung des Geschäftes eindimensional erfolgt. Prozessschritt

Prozessschritt

Prozessschritt

Prozessschritt

unterstützt

Z1 Zielzustand

Prozessschritt

tzt stü

IS1

IS2

unterstützt

ter un

unterstützt

Prozessschritt unterstützt

A1 Auslöser

IS1 Informationssystem

Prozess 2 A2

Prozessschritt

……

Prozessschritt

Z2 Zielzustand

Auslöser

. . .

. . .

Prozess N AN

Prozessschritt

……

Prozessschritt

Auslöser

ZN Zielzustand

Abbildung 59: Struktur eindimensionaler Prozessmodellierung So werden Variationen, die sich aus den permanenten Veränderungen der Unternehmensumwelt ergeben, systematisch ausgeschlossen. Geschäftsprozesse werden nicht derart modelliert, dass Variation als Grundprinzip in der Art der Modellierung Berücksichtigung findet, sondern es werden für bestimmte Produkte und Dienstleistungen Abläufe beschrieben, indem

139 Unter Business Re-Engineering wird die Optimierung der Geschäftsprozess eines Unternehmens verstanden. Die Zielsetzung besteht darin, die Effizienz und die Effektivität der Prozesse zu verbessern. Das Business Re-Engineering führt zur Neuordnung der Aufbau- und Ablauforganisation und der sie unterstützenden IT-Landschaft.

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

ƒ ƒ ƒ

115

die den Ablauf auslösenden Ereignisse und der zu erreichende Endzustand festgelegt werden, die durchzuführenden Aktivitäten und deren Reihenfolge definiert werden, diesen Aktivitäten menschliche oder automatisierte Aufgabenträger zugeordnet werden.

Auf diese Weise werden je nach Unternehmen Hunderte von Geschäftsprozessen modelliert. Als Beispiel kann nach der Erfahrung des Autors der vorliegenden Arbeit die Geschäftsprozessmodellierung dienen, wie sie bei Finanzdienstleistern häufig anzutreffen ist. Hier werden Prozesse wie Baufinanzierungsberatung, die Beratung bei der Konsumentenkreditvergabe, die Abwicklung einer Überweisung, die Abwicklung einer Kontoeröffnung oder die Abwicklung einer Wertpapierorder jeweils einzeln im Sinne des von RAMANATHAN kritisierten eindimensionalen Ansatzes modelliert. Es stellt sich die Frage nach der Problematik eines solchen Ansatzes der Prozessmodellierung. Sie besteht nach RAMANATHAN darin, dass sich das gesamte Unternehmen entlang der eindimensionalen, statischen Prozessmodellierung ausrichtet, mit der Folge einer statischen Geschäftsarchitektur. Dies führt dazu, dass Unternehmen Umweltvariationen nur unzureichend kompensieren können. Als Alternative schlägt die Autorin das Sense-and-Response-Paradigma vor, das laut RAMANATHAN zu einer Geschäftsarchitektur führt, die eine schnellere Kompensation von Variationen der Unternehmensumwelt ermöglicht. RAMANATHAN bezieht sich auf eine systemtheoretisch ausgerichtete Arbeit von HAECKEL140, die den Paradigmenwechsel zum Sense-and-ResponseUnternehmen beschreibt. Der Kerngedanke besteht hier darin, die Reaktion auf Variationen der Unternehmensumwelt zum Grundprinzip der Struktur des Unternehmens zu machen. Zielsetzung ist es, das Unternehmen so zu organisieren, dass es in der Lage ist, auf Umweltvariationen effektiv und effizient zu reagieren. Effektiv bedeutet hier insbesondere rechtzeitig in Bezug auf die Anforderungen der Unternehmensumwelt. Im Sinne des in Abschnitt 3.2.1.3 beschriebenen Konzeptes der Reaktionsfähigkeit besteht das Ziel des Sense-and-ResponseAnsatzes darin, das dynamische Potenzial zu verbessern. Der von HAECKEL beschriebene Sense-and-Response-Ansatz beruht darauf, die Geschäftsarchitektur entlang eines adaptiven Interaktionsprozesses des Unternehmens mit seiner Umwelt zu gestalten.141 RAMANATHAN beschreibt diesen Prozess wie folgt:

140

Vgl. [Haeckel99]. HAECKEL und auch RAMANATHAN folgen einem Verständnis des Begriffes Unternehmens- bzw. Geschäftsarchitektur, das mit dem der vorliegenden Arbeit vergleichbar ist. Die Zielsetzung der 141

116 1.

2.

3 Entwicklung übergeordneter Gestaltungsempfehlungen

Wahrnehmung von Veränderungen der Systemumwelt o Ausgangspunkt ist die Wahrnehmung der Veränderungen der Systemumwelt durch das Unternehmen (sensing the ecosystem). RAMANATHAN verwendet für das Unternehmen in seiner Systemumwelt den Begriff Ökosystem (ecosystem). o Die Wahrnehmung manifestiert sich in einer Anfrage/Anforderung (request objekt); z. B. ein Kundenauftrag oder eine Kundenanfrage, die durch das Unternehmen aufgenommen werden. o Eine solche Anfrage/Anforderung liegt innerhalb des dem Unternehmen bekannten Spektrums oder sie ist das Ergebnis einer Umweltvariation. o Im zweiten Fall ist die Anfrage/Anforderung noch nicht durch das Unternehmen kompensiert. Nach RAMANATHAN ergibt sich für das Unternehmen hier die Chance, durch die wertschöpfende Transformation der Anforderung/Anfrage die Positionierung in der Unternehmensumwelt zu verbessern. Reaktionsprozess im Unternehmen o Die Anfrage/Anforderung löst den Reaktionsprozess im Unternehmen aus (response process). o Der Reaktionsprozess requiriert Ressourcen, d. h. menschliche und automatisierte Aufgabenträger (IT-Systeme). o Die Aufgabenträger übernehmen die ihnen innerhalb des adaptiven Reaktionsprozesses zugewiesenen Rollen und führen die damit verbundenen Aufgaben durch. o Die requirierten Ressourcen führen die wertschöpfende Transformation der Anfrage/Anforderung gemäß der von ihnen auszufüllenden Rollen und der damit verbundenen Interaktionen durch und erzeugen eine Lieferleistung (deliverable object) für den Kunden.

Der Kern des S-R-Paradigmas besteht in der Architektur des Reaktionsprozesses, der durch die Aufnahme weiterer Rollen und Ressourcen in die Prozessdurchführung auf veränderte Anfragen/Anforderungen reagieren kann. Durch diese Architektur schafft das Unternehmen die Fähigkeit, schneller auf Variationen der Unternehmensumwelt zu reagieren. RAMANATHAN spricht hier vom adaptiven Unternehmen. Abbildung 60 fasst die Struktur des adaptiven Reaktionsprozesses zusammen.

Definition dieser Architekturen ist die Unterstützung der fortlaufenden Weiterentwicklung des Unternehmens mithilfe der Definition und Umsetzung von Modellen, Standards und Prinzipien.

117

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

Ökosystem des Unternehmens Unternehmensumwelt

Unternehmen

RequestObjekt

DeliverableObjekt

Adaptiver Reaktionsprozess Transformation Request-Objekt in Deliverable-Objekt

Sense Änderung der ökonomischen oder technologischen Bedingungen

Response Rollenzuweisung Rolle

Rolle

Rolle

Rolle

Rolle

Kundenbefriedigung, Qualität, Durchlaufzeit, …

RessourcenRequirierung IS

IS

Abbildung 60: Adaptiver Reaktionsprozess des S-R-Unternehmens in seinem Ökosystem in Anlehnung an RAMANATHAN 3.2.3.2 Das S-R-Unternehmen und Integrationslösungen RAMANATHAN greift Aspekte der Anwendungsintegration in der IT-Landschaft auf. Die Autorin weist darauf hin, dass die für die Unternehmens-IT Verantwortlichen zwar häufig das Versprechen abgeben, die Transformation des Unternehmens zu ermöglichen, dieses Versprechen jedoch in der Folge nicht eingehalten wird. Dies liegt aus Sicht von RAMANATHAN daran, dass die zur Unterstützung der Transformation initiierten IT-Projekte zur unternehmensweiten Integration von IT-Systemen nicht den versprochenen Erfolg zeitigen, was laut der Autorin auf zwei Gründe zurückzuführen ist: 1. 2.

Die Projekte nehmen ihren Ausgangspunkt nicht in einem mit der Geschäftsebene verzahnten Modellierungsansatz. Der Modellierungsansatz sieht die Reaktion auf Variation nicht als immanenten Bestandteil vor.

Punkt 1 entspricht der von SCHELP UND SCHWINN formulierten Kritik aus Abschnitt 3.2.2, in der die Autoren die fehlende Verzahnung von Lösungen zur Anwendungsintegration in der IT-Landschaft mit der Geschäftsebene kritisieren, die sich in technologiefokussierten Integrationslösungen manifestiert. Sie schla-

118

3 Entwicklung übergeordneter Gestaltungsempfehlungen

gen deshalb eine Erweiterung des Business Engineering Framework vor. Daraus wurde in 3.2.2 das Modell der ganzheitlichen Integrationslösung hergeleitet. Der Unterschied zwischen SCHELP UND SCHWINN bzw. RAMANATHAN besteht im SR-Paradigma, das Variation zum integralen Bestandteil macht und das die eindimensionale Modellierung aufhebt, die auch bei der Anwendung des Business Engineering Framework, wie sie SCHELP UND SCHWINN vorschlagen, die Regel ist. Als Beispiel kann hier eine Workflow-Management-Lösung142 angeführt werden – wie sie beispielsweise bei einem Finanzdienstleister beim Aufbau einer Kreditfabrik143 für die Bearbeitung von Krediten eingesetzt wird. Ein solches ITSystem ist mit der Prozessebene verzahnt, indem festgelegt wird, welche Teile der einzelnen, eindimensional modellierten Geschäftsprozesse unter Nutzung eines Workflow-Management-Systems automatisiert werden sollen und welche IT-Systeme dazu wie zu integrieren sind. Das Resultat ist eine ganzheitliche Integrationslösung im Sinne der in Abbildung 56 definierten Struktur. Der erste von RAMANATHAN formulierte Kritikpunkt wird durch eine solche Lösung adressiert. Die Workflow-Management-Lösung erhöht den Automatisierungsgrad, indem zur Unterstützung von Prozessen bei Auftreten der auslösenden Ereignisse Teilabläufe der modellierten Prozesse instanziiert und durchgeführt werden. Bei Auftreten von Variationen in der Unternehmensumwelt, die für die Kreditabwicklung relevant sind, werden diese im Falle eindimensionaler Modellierung kompensiert. Dies geschieht durch die Anpassung der bestehenden bzw. durch die Modellierung neuer Prozesse und die daraus abgeleitete Anpassung der Aufbau- und Ablauforganisation, wobei die Möglichkeiten des eingesetzten Workflow-Management-Systems genutzt werden. Die so geschaffene Integrationslösung weist aufgrund der Möglichkeiten des zugrunde liegenden WorkflowManagement-Systems erhöhte Flexibilität auf. Die Beschränkungen einer eindimensionalen Modellierung kann sie nicht aufheben, da Variationen nur im Rah142

Als Workflow wird hier ein Teilablauf innerhalb eines Geschäftsprozesses verstanden, der mithilfe von Workflow-Management-Technologien automatisiert wird. Dabei beschreibt ein Workflow den entsprechenden Teil des Prozesses idealerweise so exakt, dass die folgende Aktivität durch den Ausgang der jeweils vorangehenden determiniert ist. Eine Workflow-Management-Lösung ist eine implementierte Lösung zur Steuerung von Workflows auf Basis ausgewählter WorkflowManagement-Technologien. Am Markt angebotene Softwarepakete im Bereich der WorkflowManagement-Technologien werden i. d. R. als Workflow-Management-System bezeichnet. 143 Unter Kreditfabrik wird ein Gesamtsystem aus automatisierten und menschlichen Aufgabenträgern und deren Interaktionen verstanden, dessen Zweck darin besteht, bestimmte Ausschnitte der Kreditprozesse im Auftrag von Kreditinstituten, Versicherungen oder Bausparkassen vollständig zu bearbeiten. Aus Sicht der Kreditfabrik sind die Auftraggeber Elemente der Systemumwelt. Die Interaktion zwischen Auftraggeber und Kreditfabrik erfolgt auf der Basis wohldefinierter Schnittstellen und Service-Level.

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

119

men des eindimensionalen Ansatzes abgebildet werden können. Der zweite Kritikpunkt RAMANATHANS trifft somit auf die beschriebene WorkflowManagement-Lösung zu.144 3.2.3.3 Fraktale Strukturen und die ACE-Architektur Die zentrale Fragestellung der Arbeit von RAMANATHAN besteht darin, wie Geschäftsseite und Unternehmens-IT integriert modelliert werden können, sodass die Unternehmens-IT den Wechsel zum Sense-and-Response-Unternehmen erfolgreich - unter Integration der IT-Systeme in den adaptiven Reaktionsprozess unterstützen kann. Dazu schlägt die Autorin vor, nicht lineare Repräsentationen der realen Welt zu verwenden, die die Fähigkeit besitzen, sich mit deren Variation zu verändern, und die elektronisch, das heißt durch die Unternehmens-IT, unterstützt werden können. RAMANATHAN entwirft hier den von ihr als fraktal bezeichneten Ansatz für das adaptive, komplexe S-R-Unternehmen, den sie als Adaptive Complex Architecture (ACE) bezeichnet. In der Komplexitätstheorie wird das Verhalten dynamischer, nicht linearer Systeme analysiert.145 Eine der Grundaussagen der Komplexitätstheorie besteht darin, dass komplexe, nicht lineare, dynamische Systeme nicht auf komplexen Grundstrukturen und -regeln beruhen müssen. Vielmehr können durch die rekursive Anwendung einfacher Rekursionsregeln auf einfache Grundstrukturen hochkomplexe, nicht lineare Systeme geschaffen werden. Eine rekursive Grundstruktur und die zugehörige Rekursionsregel werden in der Komplexitätstheorie als Fraktal bezeichnet.146 Die Grundhypothese des ACE-Ansatzes von RAMANATHAN besteht darin, dass komplexe Unternehmen durch relativ einfache fraktale Strukturen begründet werden können. RED-Transaktion als Fraktal Die von RAMANATHAN identifizierte fraktale Struktur besteht im oben beschriebenen adaptiven Reaktionsprozess, der ein Request-Objekt aus der Unternehmensumwelt unter Requirierung von Ressourcen zur Ausfüllung von Rollen in 144 Nach Erfahrung des Autors der vorliegenden Arbeit bewegen sich auch Integrationslösungen, die unter der Nutzung eines so genannten Enterprise Service Bus (ESB) im Rahmen des SOA-Ansatzes Flexibilität versprechen, in der Regel im Rahmen der beschriebenen eindimensionalen Modellierung. Sie unterliegen damit denselben Beschränkungen in Bezug auf ihre Adaptierbarkeit an Variationen wie die beschriebene Workflow-Lösung. 145 Zur Komplexitätstheorie vgl. [PeJüSa92]. 146 MALIK (vgl. [Malik08], S. 84 f.) definiert Eigenschaften lebensfähiger Systeme. Eine dieser Eigenschaften ist deren invariante Struktur, die darin besteht, dass die Teilsysteme auf allen Ebenen des Unternehmens derselben Grundstruktur folgen. Die von RAMANATHAN beschriebene fraktale Struktur kann im Sinne einer invarianten Grundstruktur interpretiert werden.

120

3 Entwicklung übergeordneter Gestaltungsempfehlungen

ein Deliverable-Objekt transformiert. Der Reaktionsprozess wird von der Autorin in den Schritten Requirement & Planning (R), Execution (E), Delivery (D) beschrieben, wobei jeder Schritt zur wertsteigernden Transformation des Request-Objektes in ein Deliverable-Objekt beiträgt. RAMANATHAN spricht an dieser Stelle von RED-Transaktionen. Dies sind konkrete Instanziierungen des adaptiven Reaktionsprozesses. RED-Transaktionen werden nach RED-Transaktionstypen klassifiziert. Die Rekursionsregel besteht darin, dass aus REDTransaktionen wiederum RED-Transaktionen initiiert werden können, um Teilaufgaben der Transformation des Request-Objektes zu übernehmen. Dieser fraktalen Struktur folgen auch die Teilsysteme des Unternehmens. So, wie das Unternehmen entlang des adaptiven Reaktionsprozesses aufgestellt ist, organisiert sich auch jedes Teilsystem des Unternehmens im Sinne dieses Prozesses, transformiert also Request-Objekte aus seiner spezifischen Systemumwelt innerhalb des Unternehmens in Deliverable-Objekte und requiriert dazu Ressourcen zur Ausfüllung von Rollen bei der Transformation. Zusammengefasst besteht die fraktale Struktur der adaptiven Unternehmensarchitektur (ACEArchitektur) darin, dass alle Teilsysteme des S-R-Unternehmens ebenfalls dem S-R-Ansatz folgen, die Teilsysteme der Teilsysteme wiederum dem S-R-Ansatz folgen usw. Dies beinhaltet auch die Organisation des Teilsystems Unternehmens-IT nach dem S-R-Ansatz. Die nachfolgende Abbildung zeigt die Struktur der ACE-Architektur. Unternehmen RequestObjekt (RO)

DeliverableObjekt (DO)

Adaptiver Reaktionsprozess Teilsystem Adaptiver Reaktionsprozess

RO RO

Unternehmens-IT Adaptiver Reaktionsprozess

DO

DO

Element RO

Element RO

Adapt. Reaktionsproz.

Adapt. Reaktionsproz.

DO

DO

Element RO

Adaptiver Reaktionsprozess

DO

Element RO

Adaptiver Reaktionsprozess

DO

Element RO

Adaptiver Reaktionsprozess

DO

Abbildung 61: Die ACE-Architektur - fraktale Organisation des S-RUnternehmens

121

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

Exemplarische Darstellung einer RDE-Transaktion Die folgende Abbildung zeigt die Umsetzung des adaptiven Reaktionsprozess durch eine RED-Transaktion. Hier wird ein dem Unternehmen bekanntes Request-Objekt RO (e. g. Angebotsanfrage an ein Versicherungsunternehmen zur Versicherung einer Produktionsanlage durch ein Produktionsunternehmen) in den RED-Schritten bearbeitet und in ein Deliverable-Objekt DO (Versicherungsangebot zum Request-Objekt RO) transformiert. RequestObjekt RO

DeliverableObjekt DO

Transformation des Request-Objektes Requirement & Planning

Execution

Delivery Rollenzuweisung

Rolle

Rolle

Rolle

Rolle

Rolle

RessourcenRequirierung IS

IS

Abbildung 62: Bearbeitung eines Request-Objektes im Rahmen des adaptiven Reaktionsprozesses Tritt eine Variation in der Systemumwelt auf (e. g. neuer, bisher nicht versicherbarer Produktionsanlagentyp), so führt dies beispielsweise dazu, dass zum Request-Objekt RO ein Delta besteht, welches in dieser Form bisher nicht durch das Unternehmen bearbeitet wurde. Diese Variation wird innerhalb des RSchrittes erkannt. Eine untergeordnete RED-Transaktion wird instanziiert, die in den Schritten R, E, D die Bearbeitung des Deltas übernimmt. So wird ein Deliverable-Objekt DO* erzeugt, welches in die Erstellung eines Deliverable-Objektes DO’ (Angebot zur Versicherung einer Produktionsanlage des neuen Typs) in der übergeordneten RED-Transaktion eingeht. Die folgende Abbildung fasst diese Verarbeitung der Umweltänderung auf Basis der ACE-Architektur zusammen.

122

3 Entwicklung übergeordneter Gestaltungsempfehlungen

RequestObjekt RO

Transformation Request-Objekt inklusive Variation

+

Requirement & Planning

Execution

DeliverableObjekt DO‘

Delivery

DeliverableObjekt DO*

Transformation Variation Requirement & Planning

Execution

Delivery Rollenzuweisung

Rolle

Rolle

Rolle

Rolle

Rolle RessourcenRequirierung

= Delta IS

IS

Abbildung 63: Bearbeitung einer Variation im adaptiven Reaktionsprozess Die Herausforderung besteht darin, das S-R-Unternehmen gemäß der ACEArchitektur so aufzustellen, dass die Reaktion auf nicht vorhersehbare Variationen durch die Instanziierung von untergeordneten RED-Transaktionen in entsprechenden Organisationseinheiten geleistet werden kann. RAMANATHAN beschreibt hierzu Muster, die im Rahmen des adaptiven Reaktionsprozesses Anwendung finden, um Variationen des Request-Objektes, Prozessvariationen oder Ressourcenvariationen und die damit verbundene Infrastrukturnutzung zu adressieren. 3.2.3.4 Integration der Unternehmens-IT in den adaptiven Reaktionsprozess Der Fokus wird nun auf die von RAMANATHAN als Infrastrukturnutzung bezeichnete Integration der Unternehmens-IT in die ACE-Architektur gelegt. Die Autorin formuliert Anforderungen an die Unternehmens-IT, die von den Systemen der IT-Landschaft und den Einheiten der IT-Organisation zu erfüllen sind, um die Integration der Unternehmens-IT in den adaptiven Reaktionsprozess zu ermöglichen und so den Wandel zum S-R-Unternehmen zu unterstützen: ƒ ƒ

Die Organisation der Einheiten der IT-Organisation folgt der ACEArchitektur. IT-Systeme und Organisationseinheiten147 sind so weiterzuentwickeln, dass sie Dienste zur Integration in RED-Transaktionen bereitstellen können.

147 Für die IT-Organisation sind dies beispielsweise Dienste, die ein User Help Desk für die Anwenderorganisation im Rahmen des implementierten Incident-Managements zur Verfügung stellt (siehe auch [vdPols07]).

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

ƒ

123

Elemente der Unternehmens-IT liefern wohldefinierte Dienste (well-defined shared services and protocols), die in möglichst vielen RED-Transaktionstypen Rollen übernehmen können. Für diese Dienste gilt: o Jeder Dienst unterstützt rollenbasierten Zugriff, das heißt, dass die angebotenen Dienste nur durch dafür autorisierte Rollen genutzt werden können. Der rollenbasierte Zugriff folgt einem definierten Standard. o Die Nutzung und die Zufriedenheit mit jedem durch die Unternehmens-IT bereitgestellten Dienst werden zum Zwecke der Optimierung gemessen. Die Messung erfolgt für alle Dienste nach einem definierten Standard. o Jeder durch die IT-Landschaft bereitgestellte Dienst besitzt eine Schnittstelle für die Administration, das Messen und die Überwachung. Diese Schnittstelle folgt einem definierten Standard. o Von der IT-Landschaft bereitgestellte Dienste ermöglichen spätes Binden (late binding), um die rollenbasierte Ressourcenrequirierung für neue RED-Transaktionen optimal zu unterstützen.

3.2.3.5 Abbildung auf das Grundmodell zum Integrationsmanagement Die beschriebene Standardisierung der durch die Unternehmens-IT bereitgestellten Dienste ist gemäß in der Abschnitt 2.3.2 getroffenen Definition Bestandteil der IT-Unternehmensarchitektur. Eine auf den von Ramanathan vorgeschlagenen Prinzipien und Standards beruhende Architektur der Unternehmens-IT kann als Service-orientierte Architektur verstanden werden, die darauf ausgerichtet ist, die Integration der Unternehmens-IT in eine adaptive, dem S-R-Ansatz folgende Geschäftsarchitektur zu ermöglichen. Auf Basis der vorgenommenen Analyse ergibt sich die Projektion der Arbeit von RAMANATHAN auf das erweiterte Grundmodell zum Integrationsmanagement gemäß Abbildung 43:

124

IB

Informationsfluss Anforderungsfluss EFFZ Effizienzziel IB Informationsbedarf LANF Leistungsanforderung an U-IT IANF Integrationsanforderung an U-IT INTL Integrationsleistung der U-IT FANF Fachliche Anforderung i.e.S. IE Informationselement IS = IT-System Legende

Unternehmensgeschäftsarchitekturr

Schnittstelle

Unternehmen als System Geschäftsprozesse

Unternehmensumwelt

IE Schnittstelle

Management des Gesamtunternehmens

IE

EFFZ Geschäftsprozesse – modelliert i.S. des adaptiven S-RUnternehmens

Anwenderorganisation IE

IB

EFFZ

Unternehmens-IT als Teil des S-RUnternehmens

intern/extern initiiert IT-Unternehmensarchitektur

Unternehmensumwelt

U n t e r n e h m e n s a r c h i t e k t u r

3 Entwicklung übergeordneter Gestaltungsempfehlungen

LANF

INTL

IANF

FANF

IS

INTL

Zweck: InfoTransformation zur Befriedigung Info-Bedarf

Zweck: Planung/Steuerung/ Weiterentwicklung/Betrieb IT-Landschaft

IT-Landschaft

IT-Organisation

IT-Prozesse

Anforderung: Integration von ITOrganisation + ITLandschaft in den adaptiven Reaktionsprozess Leistung: Weiterentwicklung der IT-Organisation gemäß ACEPrinzipien & Standards

Zweck: Effiziente Befriedigung Informationsbedarf

Unternehmens-IT Unternehmensarchitektur incl. IT-Unternehmensarchitektur folgt der ACE-Architektur

Leistung: Weiterentwicklung der IT-Landschaft gemäß ACEPrinzipien & Standards

Abbildung 64: Projektion der Arbeit von RAMANATHAN auf das erweiterte Grundmodell zum Integrationsmanagement 3.2.3.6 Das RED-Transaktionsportal 3.2.3.6.1

Charakterisierung des RED-Transaktionsportals

Zur Unterstützung des adaptiven Reaktionsprozesses schlägt RAMANATHAN den Aufbau eines Portals vor, das Funktionen bereitstellt, um RED-Transaktionen zu verwalten und auszuführen. Dieses IT-System wird hier als RED-Transaktionsportal bezeichnet. Wesentliches Merkmal ist die Fähigkeit, RED-Sub-Transaktionen zu starten und Ressourcen entlang vordefinierter Rollen zu requirieren. Auf diese Weise wird die rekursive Struktur des adaptiven Reaktionsprozesses abgebildet. Das Portal stellt folgende Funktionen zur Verfügung: ƒ ƒ

RED-Transaktionen definieren, verändern, starten, überwachen, auswerten in RED-Transaktionen zu bearbeitende Aufgabenlisten definieren und überwachen

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

ƒ ƒ ƒ ƒ ƒ

125

Rollendefinition Rollen-Ressourcen-Zuweisung Ressourcenzugriff, insbesondere auf durch IT-Systeme zur Verfügung gestellte Dienste Aufgabenlistenzuordnung zu Ressourcen, d. h. zu menschlichen Aufgabenträgern Zugriff auf zugeordnete Aufgabenlisten incl. Verwaltung des Bearbeitungsstatus und der Möglichkeit, RED-Sub-Transaktionen abhängig von der zugewiesenen Rolle zu definieren und starten

3.2.3.6.2

Architekturentwurf für ein RED-Transaktionsportal

Als technologische Basis der Implementierung des RED-Transaktionsportals schlägt RAMANATHAN die Nutzung von Workflow-Management-Technologien vor. Als Grundlage des RED-Transaktionsportals wird eine auf das S-RUnternehmen ausgerichtete Integrationslösung vorgeschlagen, die folgendermaßen in das Abbildung 56 beschriebene Modell der ganzheitlichen Integrationslösung eingeordnet werden kann: 1.

2.

3.

4.

Geschäftsanforderung Unterstützung der Transformation zum S-R-Unternehmen durch die Unternehmens-IT mittels Transformation der IT-Landschaft im Sinne der rollenbasierten Unterstützung des adaptiven Reaktionsprozesses und der im Rahmen dieses Prozesses durchgeführten RED-Transaktionen Î Aufbau eines RED-Transaktionsportals Geschäftsintegrationsanforderung (BIR) Integration der IT-Landschaft in das RED-Transaktionsportal und der im Portal verwalteten RED-Transaktionen Anwendungsintegrationsbeziehung (AIR) Bereitstellung von Diensten gemäß der ACE-IT-Prinzipien/-Standards durch die IT-Systeme, um den Informationsbedarf der Nutzer des REDTransaktionsportals zu befriedigen Technische Integrationsbeziehung (TIR) Technische Integration der die Dienste implementierenden Softwarebausteine unter Nutzung eines Enterprise Service Bus

Abbildung 65 zeigt den Architekturentwurf einer auf das RED-Transaktionsportal ausgerichteten ganzheitlichen Integrationslösung.

126 ACE-IT-Prinzipien/Standards

3 Entwicklung übergeordneter Gestaltungsempfehlungen

Execution

Delivery

RED-Transaktionportal RED-Transaktionen Ressourcen

Rollen

AufgabenListen

Rechte

Integrations-Middleware

manuelle Aufgabenträger

e.g. Enterprise Service Bus

Dienst

Dienst

IT-System

Dienst

Dienst

IT-System

Dienst

Dienst

IT-System

Workflow-ManagementSystem

RED-Transaktionsportal Requirement & Planning

Dienst

Dienst

IT-System

Abbildung 65: Architektur des RED-Transaktionsportals 3.2.3.7 Zur Transformation der Unternehmens-IT auf Basis der ACE-Architektur Die Arbeit von RAMANATHAN enthält keinen Vorschlag zur Frage, wie die Transformation der Unternehmens-IT im Sinne der durch die ACE-ITPrinzipien/-Standards definierten IT-Unternehmensarchitektur organisiert werden kann. Die durch die ACE-Architektur angestrebte Zielsetzung besteht, wie anfangs ausgeführt, darin, das dynamische Potenzial durch den Wandel zum SR-Unternehmen zu steigern. Wie in Abschnitt 3.2.1 gezeigt, besteht das Risiko, dass durch die umfangreiche Umgestaltung der Unternehmens-IT entlang der ACE-IT-Prinzipien/-Standards die Reaktionsfähigkeit des Unternehmens zumindest mittelfristig eingeschränkt wird. Die Herausforderung besteht also darin, das Unternehmen im Rahmen eines schrittweisen Vorgehens vom eindimensional modellierten, hin zu einem einer ACE-Architektur folgenden Unternehmen zu entwickeln und dabei die Unternehmens-IT entlang der ACE-IT-Prinzipien/Standards schrittweise zu verändern, ohne die Reaktionsfähigkeit bei dieser Transformation zu stark einzuschränken.

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

127

Zur Verdeutlichung wird das o. a. Beispiel der Kreditfabrik aufgegriffen. Die schrittweise Transformation zum S-R-Unternehmen könnte erfolgen, indem die Transformation hin zum S-R-Ansatz zunächst im Rahmen einer Pilotphase nur mit Blick auf die Kreditbearbeitung durch den Finanzdienstleister vorgenommen wird. Die Prozessarchitektur der Kreditfabrik wird dazu auf der Grundlage des adaptiven Reaktionsprozesses und der ACE-Architektur - ebenfalls in mehreren Schritten - angepasst und implementiert. Die schrittweise Implementierung der S-R-Kreditfabrik kann zum Beispiel mit Fokus auf die Anforderungen des Baufinanzierungsgeschäftes gestartet werden. Parallel zu diesem schrittweisen Vorgehen werden das RED-Transaktionsportal sukzessive aufgebaut, die o. a. ganzheitliche Integrationslösung realisiert sowie in der IT-Landschaft den ACE-IT-Prinzipien/-Standards folgende Kreditbearbeitungsdienste implementiert und mithilfe der Integrationslösung in das RED-Transaktionsportal integriert. 3.2.3.8 Zusammenfassung und Gestaltungsempfehlungen In Abschnitt 3.2.1.2 wurde gezeigt, dass Komplexitätsmanagement wesentlicher Bestandteil eines Integrationsmanagements sein muss, da es unmittelbar auf die Verteilung der durch die Unternehmens-IT erbrachten Integrationsleistungen und Leistungen zur Befriedigung fachlicher Anforderungen wirkt. Dabei wurde herausgearbeitet, dass die Komplexität auf Seiten der Anwenderorganisation - die sich als wahrgenommene Komplexität auf Seiten der Unternehmens-IT manifestiert - und die Komplexität der Unternehmens-IT positiv korreliert sind. Steigende Komplexität auf Seiten der Anwenderorganisation führt zu steigender Komplexität der Unternehmens-IT und verursacht eine Zunahme von Integrationsleistungen auf Seiten der IT-Organisation. Die Analyse der Arbeit von RAMANATHAN liefert einen Ansatz, um die wahrgenommenen Komplexität auf Seiten der Anwenderorganisation zu reduzieren. Herkömmliche Geschäftsarchitekturen basieren auf einer eindimensionalen, statischen Modellierung. Dies führt zu Geschäftsarchitekturen, die auf einer Vielzahl eindimensional modellierter Geschäftsprozesse beruhen und die Variationen der Systemumwelt durch Erweiterung der statischen abbilden. Eine solche Geschäftsarchitektur bildet sich in einer statischen Aufbau- und Ablauforganisation ab, die der eindimensionalen Prozessmodellierung folgt – mit der Konsequenz steigender Komplexität auf Seiten der Anwenderorganisation und damit wie in Abschnitt 3.2.1 erarbeitet - auf Seiten der Unternehmens-IT. Dies führt zu erhöhten Integrationsleistungen der IT-Organisation. Der als ACE-Architektur bezeichnete Ansatz zur Gestaltung einer Unternehmensarchitektur von RAMANATHAN sieht vor, solche statischen Geschäftsar-

128

3 Entwicklung übergeordneter Gestaltungsempfehlungen

chitekturen durch eine Geschäftsarchitektur zu ersetzen, die auf einem generischen, adaptiven Reaktionsprozess aufbaut. Auf diese Weise können das dynamische Potenzial des Unternehmens gesteigert, die Komplexität auf Seiten der Anwenderorganisation reduziert148 und so die Basis geschaffen werden, das Verhältnis von Integrationsleistung zu Leistungen zur Erfüllung fachlicher Anforderungen zu optimieren. Aus der Analyse der ACE-Architektur ergeben sich zusammenfassend die folgenden Gestaltungsempfehlungen. Gestaltungsempfehlung 3.1 – Aufwandsreduktion für Integrationsleistungen mithilfe adaptiver Geschäftsarchitekturen Die Transformation statischer, auf eindimensionaler Modellierung beruhender Geschäftsarchitekturen hin zu adaptiven Geschäftsarchitekturen schafft Möglichkeiten zur Veränderung der Aufwandsverteilung zwischen Integrationsleistungen und Leistungen für fachliche Anforderungen zugunsten fachlicher Anforderungen. Gestaltungsempfehlung 3.2 – Service-orientierte Integration der UnternehmensIT in adaptive Geschäftsarchitekturen mithilfe ganzheitlicher Integrationslösungen Durch die schrittweise Transformation der Unternehmens-IT auf der Grundlage einer auf den ACE-IT-Prinzipien/-Standards beruhenden IT-Unternehmensarchitektur unterstützt die Unternehmens-IT den Wandel des Unternehmens zum Sense-and-Response-Unternehmen. 3.2.4 Unternehmensintegration in verteilten Organisationen In seinem Aufsatz Enterprise Integration Across the Globally Disbursed Service Organisation149 analysiert SHORE Erfolgsfaktoren für die Unternehmensintegration in global aufgestellten Dienstleistungsorganisationen. Die Zielsetzung der Unternehmensintegration besteht aus Sicht des Autors in der Schaffung einer gemeinsamen, über die globale Organisation hinweg nutzbaren Informationswirtschaft (Shared Information Environment), die die Lieferung von Produkten und Dienstleistungen unterstützt. Der Begriff Informationswirtschaft kann mit der Verwendung des Begriffes IT-Landschaft in der vorliegenden Arbeit gleichgesetzt werden.

148 Dies wird in Abschnitt 4.6.1.1 aufgegriffen. Dabei werden die Grenzen der möglichen Reduktion diskutiert. 149 Vgl. [Shore06]. SHORE ist Professor für Management-Informationssysteme an der Whittemore School of Business and Economics der Universität von New Hampshire.

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

129

Ausgangspunkt der Analyse von SHORE ist die Feststellung, dass das Management einer globalen Dienstleistungsorganisation im Kontext eines Paradoxons agieren muss. Auf der einen Seite besteht der Druck, operative Geschäftseinheiten zu dezentralisieren und Geschäftsprozesse auszulagern. Auf der anderen Seite erfordert der globale Wettbewerb die Zentralisierung von Managementfunktionen und die Integration global verteilter Einheiten. In den meisten Unternehmen wird versucht, diese Situation zu entschärfen, indem organisationsübergreifend integrierte IT-Systeme geschaffen werden, die gemeinsam genutzte Informationen für das Unternehmen vom Lieferanten bis zum Kunden verfügbar machen. Der Autor verwendet hier den Begriff extended enterprise und spricht vom enterprise system. Diese Begriffsverwendung entspricht der Verwendung des Begriffes ecosystem durch RAMANATHAN. SHORE greift Arbeiten von SCOTT 150 sowie WORTHEN151 auf und zeigt, dass die Zielsetzung des ShaUND VESSEY red Information Environment häufig nicht erreicht wird. Dieser Einschätzung stellt SHORE in seinem Aufsatz die Fallstudie zur erfolgreichen Neuausrichtung der Informationswirtschaft152 bei IBM Global Financing (IGF) gegenüber. 3.2.4.1 Abbildung auf das Grundmodell zum Integrationsmanagement SHORES Aufsatz fällt in die zweite Gruppe der vorliegend betrachteten Arbeiten. Er untersucht die übergreifende Gestaltung der Unternehmens-IT, jedoch nicht hinsichtlich eines ganzheitlichen Integrationsmanagements. In den Mittelpunk seiner Ausarbeitung stellt SHORE die Fallstudie zum Unternehmen IBM Global Financing. Bei IGF wurde im Rahmen eines großen Transformationsprojektes eine gemeinsame, global nutzbare Informationswirtschaft geschaffen. Die Zielsetzung der Transformation bestand darin, die vom IGF-Management als old legacy systems designed for old business processes beschriebene IT-Landschaft durch state-of-the-art integrierte Systeme zu ersetzen, die sich an einer neuen, global aufgestellten, flexibleren Geschäftsprozessarchitektur ausrichten. Im Sinne des begrifflichen Fundamentes der vorliegenden Arbeit bestand die Zielsetzung also darin, eine IT-Landschaft zu schaffen, die den Informationsbedarf des Unternehmens einschließlich der mit dem Unternehmen verflochtenen Kunden und Lieferanten über die global verteilte Organisation befriedigt. Damit ergibt sich die Projektion auf das Grundmodell zum Integrationsmanagement gemäß nachstehender Abbildung.

150

Vgl. [ScoVes02]. Vgl. [Worthen02]. 152 SHORE verwendet den Begriff Informationswirtschaft synonym zum Begriff IT-Landschaft. 151

130

3 Entwicklung übergeordneter Gestaltungsempfehlungen

Unternehmen als komplexes System Unternehmensumwelt

Geschäftsprozesse

IB

Unternehmensumwelt

IE

Schnittstelle

Schnittstelle

Management des Gesamtunternehmens

IE

EFFZ Einführung einer neuen, flexiblen Prozessarchitektur

Anwenderorganisation Informationsfluss

IE

IB

EFFZ Befriedigung des Informationsbedarfs des Unternehmens, der Lieferanten & Kunden über die globale Organisation - extended enterprise

Anforderungsfluss intern/extern initiiert

EFFZ Effizienzziel

LANF

IB Informationsbedarf LANF Leistungsanforderung an U-IT IANF Integrationsanforderung an U-IT

INTL

IE Informationselement IS = IT-System Legende

FANF INTL

IT-Prozesse

INTL Integrationsleistung der U-IT FANF Fachliche Anforderung i.e.S.

IANF

IS

Zweck: InfoTransformation zur Befriedigung Info-Bedarf

Zweck: Planung/Steuerung/ Weiterentwicklung/Betrieb IT-Landschaft

IT-Landschaft

IT-Organisation

Zweck: Effiziente Befriedigung Informationsbedarf

Unternehmens-IT

Schaffung einer integrierten Informationswirtschaft zur Informationsbedarfs-befriedigung, des „Extended enterprise“

Globale Integration der Systeme der ITLandschaft, zur Schaffung des „Shared Information Environment“

Abbildung 66: Projektion von SHORE auf das Grundmodell zum Integrationsmanagement 3.2.4.2 IGF und die Zielsetzung einer global integrierten IT-Landschaft Zum Zeitpunkt des Transformationsprojektes konnte IBM Global Financing folgendermaßen charakterisiert werden: IBM Global Financing offeriert in 43 Ländern Finanzierungsprodukte und Dienstleistungen. Das Unternehmen umfasst zwei strategische Geschäftsbereiche: Asset Financing stellt alle Arten von Produkten- und Dienstleistungen für die Finanzierung von Hard- und Softwareprodukten von IBM und anderen Anbietern zur Verfügung. Asset Recovery bietet IGF-Kunden Dienstleistungen, um am Ende von Leasing-Perioden Folgeentscheidungen vorzubereiten, zu planen und umzusetzen. Hier verfolgt IGF das Ziel, gemeinsam mit dem Kunden sicherzustellen, dass sich Leasingentscheidungen nach Geschäftsanforderungen richten und nicht umgekehrt. Im Jahr 2002 verfügte IGF über Aktiva (assets under management) im Wert von 37 Milliarden Dollar, hatte zu diesem Zeitpunkt 3.200 Mitarbeiter und 125.000 Kunden. Die zu erneuernde IT-Landschaft von IGF stellte sich so dar, dass mehr als 800 Geschäftsprozesse mithilfe von ca. 300 IT-Systemen in 43 Ländern implementiert waren. Die Fähigkeit, auf Änderungen im Ökosystem des Unterneh-

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

131

mens zu reagieren, war aufgrund der statischen, eindimensionalen Prozessarchitektur und der statischen IT-Landschaft erheblich eingeschränkt. Im Sinne der Definitionen aus Abschnitt 3.2.1.3 ist dies so zu interpretieren, dass die Reaktionsfähigkeit des Unternehmens nicht mehr ausreichend war, um in seiner Umwelt, in seinem Ökosystem erfolgreich zu bestehen. Die vor Projektbeginn bestehende Architektur des Unternehmens kann folgendermaßen zusammengefasst werden: ƒ

ƒ

ƒ

Die Prozesslandschaft des Gesamtunternehmens beruhte nicht auf einer global abgestimmten Architektur, sondern auf der Vereinigung dezentraler Architekturen. Die aus Sicht des Gesamtunternehmens erforderliche Reaktionsfähigkeit war nicht mehr gewährleistet. Die dezentralen Geschäftseinheiten verfügten über dezentral optimierte Geschäftsarchitekturen, die die dezentral erforderliche Reaktionsfähigkeit garantierten. Die (Unternehmens-)-IT-Architekturen der dezentralen Einheiten folgten diesen dezentralen Geschäftsarchitekturen. Die IT-Landschaft des Gesamtunternehmens ergab sich als Vereinigung der dezentral optimierten IT-Landschaften der dezentralen Einheiten. Die daraus resultierende Reaktionsfähigkeit der Unternehmens-IT des Gesamtunternehmens war unzureichend und gefährdete die Lebensfähigkeit des Gesamtunternehmens.

In Abschnitt 2.2.2 wird das Konzept des lebensfähigen Systems beschrieben. Ein Merkmal ist die Maximierung der Autonomie seiner Teilsysteme, ohne die Lebensfähigkeit des Gesamtsystems zu gefährden. Im Fall von IGF war die Autonomie der Teilsysteme so groß, dass die Lebensfähigkeit des Gesamtsystems gefährdet war. Diese Situation bei IGF vor Durchführung des Transformationsprojektes ist in der folgenden Abbildung zusammengefasst.

132

3 Entwicklung übergeordneter Gestaltungsempfehlungen

RF (-)

IT-Landschaft des Gesamtunternehmens

Geschäftsprozesslandschaft des Gesamtunternehmes

beschränkt

beschränkt

beschränkt

Sicht der dezentralen Einheiten

Gesamtunternehmenssicht

RF (-)

RF (+) RF (+)

IT-Landschaft der dezentralen Unternehmenseinheit A IT-U.Architektur A

RF (+)

IT-Landschaft der dezentralen Unternehmenseinheit B

RF (+)

bestimmt

IT-U.Architektur B RF (+)

Geschäftsarchitektur A

IT-Landschaft der Holding (H) RF (+)

IT-Landschaft der dezentralen Unternehmenseinheit C

stellt sicher

IT-U.Architektur H

RF (-) = Reaktionsfähigkeit unzureichend

RF (+)

Geschäftsprozesse der dezentralen Unternehmenseinheit C

Geschäftsarchitektur B RF (+)

Geschäftsprozesse der Holding (H) Geschäftsarchitektur H

Geschäftsarchitektur C

IT-U.Architektur C

Legende

Geschäftsprozesse der dezentralen Unternehmenseinheit A

Geschäftsprozesse der dezentralen Unternehmenseinheit B

RF (+) = Reaktionsfähigkeit ausreichend

Abbildung 67: Gefährdung der Lebensfähigkeit von IGF durch Autonomie der Teilsysteme Die erneuerte IT-Landschaft des Gesamtunternehmens sollte IGF in seinem Ökosystem entlang der Wertschöpfungskette durch die Schaffung einer integrierten Informationswirtschaft optimieren - für alle Niederlassungen in allen 43 Ländern. Auf diese Weise sollte die verteilte Organisation mit unzureichend integrierten Systemen zu einem virtuellen, im E-Business wettbewerbsfähigen Unternehmen transformiert werden. 3.2.4.3 Projektvorgehen Das Projekt wurde auf Basis von vier definierten Schwerpunkten aufgestellt: ƒ ƒ ƒ ƒ

Transformation der Geschäftsprozesse Organisatorische Veränderungen Veränderungen im Management Transformation der IT-Landschaft

Das Projektvolumen belief sich auf ca. 60 Millionen Dollar. Das Projektvorgehen kombinierte Top-down-Führerschaft (leadership) mit Bottom-upZusammenarbeit (collaboration) und war darauf ausgerichtet, dezentralen Ge-

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

133

schäftseinheiten die Möglichkeit zur aktiven Mitgestaltung der Transformation zu geben. Ausgangspunkt des Projektes war die Analyse der bestehenden, mehr als 800 Prozesse umfassenden Geschäftsprozesslandschaft. Dabei wurde deutlich, dass eine der größten Schwächen darin bestand, gemeinsame Daten zu nutzen – die Wettbewerbsfähigkeit war deshalb in vielen Bereichen der Prozesslandschaft nicht mehr gegeben. Ausgehend von dieser Ist-Analyse wurde die neue Prozessarchitektur für IGF entworfen. Hier bestand das Ziel darin, die vorrangig aus dezentraler Sicht implementierten, keiner gemeinsamen Prozessarchitektur folgenden Prozesse durch eine flexiblere Prozessarchitektur zu ersetzen, die auf gemeinsame, globale Geschäftsprozesse setzt. Das Ziel der Flexibilität war so definiert, dass der Großteil der Anforderungen der 43 Länder innerhalb derselben Prozesse umgesetzt werden sollte und dezentrale Besonderheiten als Ergänzung global gültiger Prozesse umgesetzt werden sollten.153 Die neue Prozessarchitektur von IGF sollte auf 19 gemeinsamen, global ausgerichteten, flexiblen Prozessen basieren.154 Auf der Grundlage dieser Prozessarchitektur wurde die IT-Landschaft von 300 IT-Systemen auf 36 Systeme reduziert. Die neue IT-Landschaft von IGF beruht auf zwei Kernsystemen155: ƒ ƒ

dem globalen SAP-basierten Asset-Financing-System, das die Teilsysteme Finance/Controlling, Fixed Assets, Sales and Distribution, Accounts Receivable, Accounts Payable und Lease/Loan Accounting umfasst, dem globalen SAP-basierten Asset-Recovery-System, das Teilsysteme zum Inventory- und Lebenszyklusmanagement von gemieteten Gütern sowie zum Management der Weiterverwertung abgemieteter Güter umfasst.

Zur Befriedigung der Informationsbedarfe im Bereich der Planungs- und Steuerungsprozesse des Unternehmens und seiner Geschäftseinheiten wurden ITSysteme aufgebaut, die auf Architekturen, Methoden und Technologien des Data Warehousing beruhen. Aufgrund des beschriebenen Vorgehens können diese Systeme als ganzheitliche Integrationslösungen klassifiziert werden. Weitere Systeme dienen im Wesentlichen der Implementierung spezifischer Anforderun153 Diese Forderung geht in Richtung der in Abschnitt 3.2.3.1 beschriebenen adaptiven Prozessarchitektur. 154 Ob diese Prozesse im Sinne einer adaptiven Prozessarchitektur entworfen wurden, bleibt im Artikel von SHORE offen. 155 Kernsysteme werden hier im Sinne der von DERN in [Dern09] getroffenen Definition als ITSysteme verstanden, die die Anwenderorganisation bei der Durchführung von Kerngeschäftsprozessen unterstützen. Kerngeschäftsprozesse sind Aktivitätenfolgen im Unternehmen, die vom Kunden ausgelöst werden, beim Kunden enden und Nutzen für den Kunden erzeugen.

134

3 Entwicklung übergeordneter Gestaltungsempfehlungen

gen von Geschäftseinheiten. Sie sind mit den Kernsystemen bzw. dem Planungsund Steuerungssystem integriert und wurden einem Best-of-Breed-Ansatz folgend aufgebaut. 3.2.4.4 Ableitung von Erfolgsfaktoren Als wesentliche Erkenntnisse des beschriebenen Projektes zur Schaffung einer global integrierten Informationswirtschaft führt SHORE folgende Punkte auf: ƒ ƒ ƒ ƒ

ƒ ƒ ƒ ƒ

Einnahme einer holistischen Gesamtsicht Ausgangspunkt auf der Ebene der Geschäftsarchitektur Verzögern des Projektstarts, bis absolutes CEO-Commitment sichergestellt ist Aufgrund der großen Komplexität der Aufgabenstellung werden ProjektChampions benötigt, die die Fähigkeit besitzen, die Gestaltung der ITLandschaft und den Einsatz damit verbundener Technologien, die Gestaltung der Prozesslandschaft sowie Themen in den Bereichen Management und Organisation unter Berücksichtigung kultureller Unterschiede und Hürden auszubalancieren. Konzentration auf Kernaufgaben und Auslagerung möglichst vieler Projektaktivitäten. Hier führt SHORE die externe Durchführung der SoftwareEntwickung an. Sicherstellung der Einbindung stark zielorientiert agierender Geschäfts- und IT-Experten Sicherstellung enger Steuerung durch das Management Effektive Kommunikation unter Berücksichtigung kultureller Besonderheiten und Sicherstellung der Partizipation dezentraler Einheiten

3.2.4.5 Zusammenfassung und Gestaltungsempfehlungen SHORES Ausarbeitung bestätigt Ergebnisse der Analysen der Abschnitte 3.2.1 3.2.3. Die Studie zu IGF ƒ ƒ

belegt die beschriebenen Komplexitätsabhängigkeiten, insbesondere die Korrelation der wahrgenommenen Komplexität der Anwenderorganisation mit der Komplexität der Unternehmens-IT, liefert ein Beispiel für den Nutzen und die erfolgreiche Gestaltung ganzheitlicher Integrationslösungen,

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

ƒ

135

zeigt die Bedeutung flexibler Geschäftsarchitekturen und entsprechend aufgestellter IT-Unternehmensarchitekturen für die Reaktionsfähigkeit und damit die Lebensfähigkeit global agierender Unternehmen.

Aus der Studie werden die folgenden Gestaltungsempfehlungen abgeleitet: Gestaltungsempfehlung 4.1 – Der Aufbau einer organisationsübergreifend integrierten IT-Landschaft folgt der Erneuerung der Geschäftsprozesslandschaft Die Zielsetzung einer organisationsübergreifend integrierten Informationswirtschaft eines international agierenden Unternehmens muss ihren Ausgangspunkt auf der Geschäftsebene nehmen und aus Sicht des Gesamtunternehmens vorgenommen werden. Die umfassende Neuordnung der IT-Landschaft zur Schaffung einer global integrierten Informationswirtschaft wird getrieben durch die Neugestaltung der Geschäftsprozessarchitektur des Gesamtunternehmens. Im Einzelnen gilt: ƒ ƒ ƒ ƒ

Die Unternehmensgeschäftsarchitektur wird aus Sicht der für das Gesamtunternehmen erforderlichen Reaktionsfähigkeit und der Reaktionsfähigkeit der dezentralen Einheiten definiert. Die dezentralen Geschäftsarchitekturen definieren Verfeinerungen und Erweiterungen der Unternehmensgeschäftsarchitektur. Die Unternehmensgeschäftsarchitektur bestimmt die Leistungsanforderung an die IT-Landschaft des Gesamtunternehmens, insbesondere die angestrebte Reaktionsfähigkeit, d. h. das statische und das dynamische Potenzial. Die Transformation der IT-Landschaft vollzieht sich im Rahmen einer ITUnternehmensarchitektur, die auf die Reaktionsfähigkeit des Gesamtunternehmens ausgerichtet ist und die erforderlichen dynamischen und statischen Potenziale der dezentralen Einheiten als Randbedingung berücksichtigt. Die dezentralen IT-Unternehmensarchitekturen definieren Verfeinerungen und Erweiterungen im Rahmen der dezentralen Geschäftsarchitekturen.

Die folgende Abbildung fasst die Veränderungen der Unternehmensarchitektur von IGF, die die Lebensfähigkeit des Unternehmens wiederherstellen sollten, zusammen. Durch die mindestnotwendige Einschränkung der Autonomie der dezentralen Einheiten wurde die Reaktionsfähigkeit des Gesamtunternehmens wiederhergestellt.

136

3 Entwicklung übergeordneter Gestaltungsempfehlungen

Sicht der dezentralen Einheiten

Gesamtunternehmenssicht

RF (+)

RF (+)

bestimmt

IT-Landschaft des Gesamtunternehmens

Geschäftsprozesslandschaft des Gesamtunternehmes

gewährleistet

berücksichtigt

Geschäftsarchitektur

berücksichtigt

IT-U.Architektur A

RF (+)

IT-Landschaft der dezentralen Unternehmenseinheit A

RF (+)

bestimmt

IT-U.Architektur B RF (+)

IT-U.Architektur A

RF (+)

IT-Landschaft in der dezentralen Unternehmenseinheit B

IT-Landschaft der Holding (H) IT-U.Architektur H

IT-U.Architektur C

Legende

RF (+)

IT-Landschaft der dezentralen Unternehmenseinheit B

RF (+)

Geschäftsprozesse der dezentralen Unternehmenseinheit A Geschäftsarchitektur A

gewährleistet

RF (+)

Geschäftsprozesse der dezentralen Unternehmenseinheit C

Geschäftsprozesse der dezentralen Unternehmenseinheit B Geschäftsarchitektur B RF (+)

Geschäftsprozesse der Holding (H) Geschäftsarchitektur H

Geschäftsarchitektur C

RF (+) = geforderte Reaktionsfähigkeit ausreichend

Abbildung 68: Ansatz zum Aufbau einer integrierten IT-Landschaft in global verteilten Unternehmen Gestaltungsempfehlung 4.2 – Neugestaltung der IT-Landschaft im Rahmen einer adaptiven Prozessarchitektur Prozesslandschaften, die auf statischen, inflexiblen Architekturen beruhen, führen zu IT-Landschaften, die in Bezug auf das statische und das dynamische Potenzial einzelner Geschäftseinheiten ausreichend sein können, jedoch aufgrund zu großer Komplexität das mindestnotwendige dynamische Potenzial des Gesamtunternehmens gefährden. Die Verschlankung der Geschäftsarchitektur – zum Beispiel i. S. der in 3.2.3 beschriebenen ACE-Architektur – bildet die Voraussetzung für die Neuausrichtung der IT-Landschaft innerhalb einer international verteilt operierenden Organisation.

Gestaltungsempfehlung 4.3 - Erneuerung von Kernsystemen auf Basis von ITArchitekturen, die den Anforderungen der Geschäftsarchitektur bzgl. Adaptierbarkeit und Flexibilität folgen156 156 In Abschnitt 4.6.3 werden Fragen der Adaptierbarkeit, der Flexibilität und der Agilität aus Sicht der Komplexitätswirkung und der Beherrschbarkeit der IT-Landschaft diskutiert und weiterführende Gestaltungsempfehlungen abgeleitet.

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

137

Bei der Neugestaltung der Unternehmens-IT zur Schaffung einer übergreifend integrierten Informationswirtschaft steht die Erneuerung der Kernsysteme auf der Grundlage flexibler IT-Architekturen (e. g. durch Eigenschaften wie Parametrisierbarkeit und Mandantenfähigkeit) im Mittelpunkt. Die Leistungsmerkmale der Geschäftsarchitektur in Bezug auf Adaptierbarkeit und Flexibilität bestimmen die Leistungsanforderungen an die den Kernsystemen zugrunde liegenden ITArchitekturen. 3.2.5 Muster für die IT-Konsolidierung bei Fusionen und Übernahmen Im Aufsatz The hidden IT multipliers in mergers157 beschreiben HEAP, ISRAELIT 158 UND SHPILBERG Muster für die erfolgreiche Integration der Unternehmens-IT miteinander fusionierender Unternehmen (mergers & aquisitions). Der Erfolg der Integration bemisst sich aus Sicht der Autoren am Beitrag der neuen, integrierten Unternehmens-IT zur Erreichung der mit der Fusion oder Übernahme verbundenen Ziele. Ausgangspunkt der Ausarbeitung der Autoren sind die Ergebnisse unabhängiger Untersuchungen, die zeigen, dass mehr als die Hälfte aller Übernahmen und Fusionen Werte vernichten und die versprochenen Ziele nicht erreichen. Typische Merkmale solcher scheiternden Fusionen und Übernahmen sind die Abwanderung von Kunden und von wichtigen Mitarbeitern, Projekte, die sich aufgrund fehlender Ressourcen verzögern oder ganz scheitern, und IT-Landschaften, die den Anforderungen der vereinigten Geschäftsaktivitäten nicht gerecht werden. Der Aufsatz von HEAP, ISRAELIT UND SHPILBERG fällt in die dritte Gruppe der im Rahmen der vorliegenden Arbeit untersuchten Artikel und Arbeiten. Der Aufsatz stellt nicht die übergreifende Gestaltung der Unternehmens-IT in den Mittelpunkt, liefert jedoch Ansatzpunkte für die Ableitung von Gestaltungsempfehlungen für ein ganzheitliches Integrationsmanagement. Im Folgenden wird zur Vereinfachung von Fusionen von Unternehmen gesprochen. Übernahmen – auch von Unternehmensteilen - sind darin eingeschlossen. Der Fokus der Analyse der Arbeit von HEAP, ISRAELIT UND SHPILBERG liegt auf der Konsolidierung der Unternehmens-IT (IT-Konsolidierung) der beteiligten Unternehmen zu einer integrierten Unternehmens-IT. 157 Vgl. [HeIsSh03]. HEAP, ISRAELIT UND SHPILBERG waren zum Zeitpunkt der Veröffentlichung Mitarbeiter des Beratungsunternehmens Bain & Company. Das Unternehmen wurde 1973 gegründet, berät größere Unternehmen und unterhält Niederlassungen in 26 Ländern. Das Unternehmen hat 3.100 Mitarbeiter. Firmensitz ist Boston. Eines der Geschäftsfelder des Unternehmens ist die Unterstützung von Unternehmen bei der Entscheidung, Planung und Durchführung von Fusionen und Übernahmen. 158 Der von den Autoren verwendete Begriff Muster ist als Handlungsmuster, also im Sinne der vorliegenden Arbeit als Leitlinie und nicht als Architekturmuster zu verstehen.

138

3 Entwicklung übergeordneter Gestaltungsempfehlungen

Ausgangspunkt der Analyse der Autoren sind Muster, die sich bei der Integration der Geschäftsaktivitäten zu fusionierender Unternehmen auf Geschäftsseite als erfolgreich erwiesen haben. Diese Muster sind das Ergebnis der Analyse zahlreicher Fusionsprojekte durch die Autoren. Sie werden von HEAP, ISRAELIT UND SHPILBERG auf die Zusammenführung der Unternehmens-IT übertragen. 3.2.5.1 Abbildung auf das Grundmodell zum Integrationsmanagement Die Anforderungslage, die sich aus Sicht von HEAP, ISRAELIT UND SHPILBERG ergibt, kann folgendermaßen charakterisiert werden: ƒ ƒ ƒ

Es soll eine integrierte Unternehmens-IT geschaffen werden, die einen maximalen Beitrag zur Erreichung der Fusionsziele leistet. Die Geschäftsaktivitäten, d. h. insbesondere die Geschäftsprozesse, des neuen integrierten Unternehmens sollen durch die neue Gesamtunternehmens-IT effektiv und effizient unterstützt werden. Die IT-Landschaften und die IT-Organisationen sollen zur Unterstützung der definierten Fusionsziele konsolidiert und integriert werden.

Aus dieser Charakterisierung ergibt sich die Projektion der Arbeit von HEauf das Grundmodell zum Integrationsmanagement gemäß der folgenden Abbildung. AP, ISRAELIT UND SHPILBERG

139

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

Unternehmen als komplexes System Unternehmensumwelt

Unternehmensumwelt

IE Schnittstelle

IB

Schnittstelle

Management des Gesamtunternehmens

IE

EFFZ Schaffung einer integrierten Unternehmens-IT fusionierender Unternehmen, die maximalen Beitrag zu Fusionszielen leistet

Anwenderorganisation Informationsfluss

IE

IB

EFFZ

Anforderungsfluss intern/extern initiiert

EFFZ Effizienzziel

LANF

IB Informationsbedarf LANF Leistungsanforderung an U-IT IANF Integrationsanforderung an U-IT

INTL

IE Informationselement IS = IT-System Legende

FANF INTL

IT-Prozesse

INTL Integrationsleistung der U-IT FANF Fachliche Anforderung i.e.S.

IANF

IS

Zweck: InfoTransformation zur Befriedigung Info-Bedarf

Zweck: Planung/Steuerung/ Weiterentwicklung/Betrieb IT-Landschaft

IT-Landschaft

IT-Organisation

Unterstützung der Geschäftsaktivitäten der zusammen zu führenden Unternehmen Integration der ITLandschaften, der ITOrganisation im Sinne der definierten Fusionsziele Schaffung einer integrierten ITOrganisation

Zweck: Effiziente Befriedigung Informationsbedarf

Unternehmens-IT

Schaffung einer integrierten ITLandschaft

Abbildung 69: Projektion der Arbeit von HEAP, ISRAELIT UND SHPILBERG auf das Grundmodell zum Integrationsmanagement 3.2.5.2 Handlungsmuster erfolgreicher Geschäftsintegration Die Autoren identifizieren folgende Muster, die bei der Zusammenführung der Geschäftsaktivitäten fusionierender Unternehmen berücksichtigt werden sollen: ƒ

ƒ

ƒ

Höchste Priorität auf Wertzuwachs Höchste Priorität soll denjenigen Chancen der Geschäftsintegration eingeräumt werden, die den größten zusätzlichen Wert erzeugen. Schnelle Umsetzung vor Perfektion Die Geschwindigkeit der Umsetzung der wichtigsten Integrationsaktivitäten wird als entscheidendes Kriterium für den Erfolg angesehen. Sicherstellung der laufenden Geschäftsaktivitäten Der Fokus der Unternehmensressourcen soll in der Phase der Zusammenführung zweier zu einem integrierten Unternehmen auf der Sicherstellung der laufenden Geschäftsaktivitäten liegen und die Abwanderung von Kunden und Mitarbeitern zu verhindern.

140

3 Entwicklung übergeordneter Gestaltungsempfehlungen

Aus diesen Mustern werden von HEAP, ISRAELIT UND SHPILBERG Handlungsmuster für die Zusammenführung der Unternehmens-IT abgeleitet. Die Anwendung dieser Muster stellt sicher, dass die Zielsetzung der Zusammenführung der Unternehmens-IT von der Effizienzbetrachtung der IT-Konsolidierung hin zur Effektivitätsbetrachtung verändert wird. 3.2.5.3 Handlungsmuster für die IT-Konsolidierung Häufig stehen bei der Zusammenführung der IT-Landschaften und der ITOrganisationen Kostenvorteile, z. B. durch Stellenabbau und Einkaufsoptimierung, im Vordergrund. Durch diese Konzentration auf Kostenziele werden Chancen vergeben, die sich im Rahmen der Zusammenführung der Unternehmens-IT auf Geschäftsebene ergeben. Als Beispiel wird von den Autoren die Zusammenführung der Kundendaten genannt. Gelingt es, Kundendaten schnell zu vereinen, ergeben sich z. B. Potenziale für ein Cross Selling. Die Analyse von HEAP, ISRAELIT UND SHPILBERG zeigt, dass die Übertragung der Best-Practice-Muster der Geschäftsebene auf die Integration der Unternehmens-IT der beteiligten Unternehmen zu einer deutlichen Steigerung des Wertbeitrages der IT-Konsolidierung zur Fusion führen kann. Die Anwendung dieser Handlungsmuster unterbleibt nach Erfahrung der Autoren häufig, weil bei der Planung der IT-Konsolidierung Ziele unberücksichtigt bleiben, die nicht der IT-Organisation zuzuordnen sind. Aus der Arbeit von HEAP, ISRAELIT UND SHPILBERG ergeben sich die folgenden Muster für die IT-Konsolidierung. 3.2.5.3.1

Nutzenbetrachtung der IT-Konsolidierung umfasst Wertzuwachs auf Geschäftsebene

Dies bedeutet, dass das Nutzenpotenzial auf Geschäftsebene explizit als Erfolgskriterium der Zusammenführung der Unternehmens-IT definiert wird und diejenigen Optionen hoch priorisiert werden, die solche Nutzenpotential besitzen. Häufig unterliegt das IT-Management nach Erfahrung der Autoren dem Irrtum, dass die Zusammenführung der Unternehmens-IT nur geringen Wertzuwachs generiert, da das IT-Management den Fokus auf die Analyse von ITLandschaften im Sinne von „besseren IT-Architekturen, modernerer Technologien, usw.“ setzt. Wird die Nutzenbetrachtung der Integration von IT-Landschaften und IT-Organisationen auf wertsteigernde Effekte auf Geschäftsseite erweitert, ergeben sich häufig größere Potenziale. Als Beispiele werden von HEAP, ISRAELIT UND SHPILBERG die Fusion zweier Lebensmittelunternehmen und die Fusion zweier Hersteller von elektronischen Ausrüstungsgegenständen aufgeführt. Im ersten Fall führte die Erweite-

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

141

rung des Fokus zur Identifikation von Potenzialen, die die rein IT-bezogenen Synergien deutlich überstiegen. Im zweiten Fall wurde zunächst ermittelt, dass IT-Synergien mit 11 % zum Gesamtnutzen der Fusion beitragen würden. Als der Fokus für die Unternehmens-IT auf die Wertsteigerung auf Geschäftsseite erweitert wurde, konnte der Beitrag zum Gesamtnutzen auf 18 % erhöht werden. 3.2.5.3.2

Schnelle Konsolidierung der IT-Landschaften vor Perfektion

Die Zusammenführung größerer Unternehmen ist mit der schwierigen Entscheidung verbunden, welche IT-Systeme der beteiligten Unternehmen zukünftig genutzt werden sollen, um die Geschäftsprozesse zu unterstützen. So kann beispielsweise eines der beiden Unternehmen Mainframe-basierte Kernsysteme aufweisen, während das andere für die Kernprozesse auf dezentrale, Unixbasierte Systeme setzt. Der Versuch, die neue, integrierte IT-Landschaft nach dem Best-of-Breed-Ansatz aufzubauen, birgt zwei Risiken: ƒ

ƒ

159

Dieser Ansatz erhöht die Komplexität der Unternehmens-IT, da unabhängig voneinander entstandene IT-Systeme integriert werden müssen. Darüber hinaus muss die neue, zusammengeführte IT-Organisation das notwendige Wissen zur Wartung und Weiterentwicklung der Systeme beider IT-Landschaften vorhalten. Es besteht das Risiko, die Dauer der Zusammenführung von IT-Landschaften und IT-Organisationen signifikant zu erhöhen.159 Das bedeutet im Sinne des Konzeptes der Reaktionsfähigkeit der vorliegenden Arbeit, dass das Risiko besteht, die Dauer der durch die Fusion verursachten Einschränkung des dynamischen Potenzials zu erhöhen.

Folgendes Beispiel verdeutlicht nach Erfahrung des Autors der vorliegenden Arbeit diese Aussage: Bei Unternehmen sind bestandsführende Systeme stets mit dem Partner- bzw. Kundenstammdatensystem integriert. Geschieht dies entlang einer Fremdschlüsselbeziehung, bildet diese die Grundlage der Implementierung vielfältiger Geschäftsregeln. Diese Geschäftsregeln werden entlang der Informationsbeziehungen der Systeme implementiert. Die Informationsbeziehung manifestiert sich als Integration entlang der Fremdschlüsselbeziehung. Die Geschäftsregeln adressieren typischerweise Aspekte wie die Kundensystematik, die Vertriebsstruktursystematik etc. Werden nun für die angestrebte Ziel-IT-Landschaft die Bestandssysteme nach dem Best-of-Breed-Ansatz ausgewählt, so muss die Integration zwischen Bestandssystemen und Kundenstammdatensystem grundlegend verändert werden. Dies umfasst dann die Implementierung der o. a. Geschäftsregeln entlang einer neuen Fremdschlüsselbeziehung zwischen einem Teil der Bestandssysteme des einen mit dem Kundenstammdatensystem des jeweils anderen Unternehmens. Die Alternative besteht hier in der Datenmigration aus einer der beiden IT-Landschaften in die andere inklusive der damit verbundenen mindestnotwendigen Anpassungen der aufnehmenden Systeme.

142

3 Entwicklung übergeordneter Gestaltungsempfehlungen

Aufgrund dieser Risikobetrachtung empfehlen die Autoren, die Entscheidung für den Kern einer der beiden IT-Landschaften möglichst schnell herbeizuführen und umzusetzen, um dann den Fokus wieder auf den Nutzen für die Geschäftsseite zu legen. Als Fallbeispiel greifen HEAP, ISRAELIT und SHPILBERG die Fusion zweier produzierender Unternehmen auf. Hier überzeugte das IT-Management die Unternehmensführung, die Fusion mit der Migration beider Unternehmen auf moderne Produktions-, Auftrags-, Vertriebs- und Planungssystemen zu verbinden. Die mit der Einführung verbundenen Probleme führten zu erheblichen Qualitätsverlusten in den operativen Prozessen und Verlusten in Höhe zweistelliger $Millionenbeträge. Darüber hinaus führte die Verschlechterung der operativen Prozesse zu einem deutlichen Rückgang der Kundenzufriedenheit und damit zu einer längerfristigen Verschlechterung der Wettbewerbsposition des Unternehmens. Schnelle IT-Konsolidierung und IT-Projektportfolio160 Bestandteil der IT-Konsolidierung im Rahmen von Unternehmensfusionen ist die Zusammenführung der IT-Projektportfolien. Hier stellt sich die Frage, nach welchem Kriterium darüber entschieden werden sollte, welche dieser Projekte weiterverfolgt und welche aufgeben werden. HEAP, ISRAELIT UND SHPILBERG empfehlen, auf die Projekte zu setzen, die den meisten Wert innerhalb der geringsten Zeit erzeugen. Überführt man diese Empfehlung in dem in der folgenden Abbildung dargestellten Portfoliomodell, so fordern die Autoren die Konzentration auf den Quadranten 1. erwarteter Nutzen 3

Fo ku sq ua dr an t

1

hoch

2

4

niedrig

niedrig

hoch

erwartete Umsetzungsdauer

Abbildung 70: Portfoliomodell zur Auswahl von IT-Projekten während der ITKonsolidierung 160

Zum IT-Projektportfolio siehe Abschnitt 4.2.4.

3.2 Ableitung von Gestaltungsempfehlungen aus verwandten Arbeiten

3.2.5.3.3

143

Sicherstellung der IT-Unterstützung des laufende Geschäftes

Aus Sicht von HEAP, ISRAELIT UND SHPILBERG soll sich bei der Fusion von Unternehmen der Großteil der Unternehmensressourcen darauf konzentrieren, die störungsfreie Durchführung der Geschäftsprozesse zu gewährleisten. Dieses Handlungsmuster gilt entsprechend für die Unternehmens-IT. Die Aufgabe des IT-Managements besteht deshalb vorrangig darin, die störungsfreie Durchführung der bestehenden Geschäftsprozesse zu sichern, indem die IT-Systeme im Rahmen der definierten IT-Prozesse möglichst lange störungsfrei weiterbetrieben werden. Deshalb wird für die Zusammenführung des IT-Betriebs der beiden Unternehmen ein schrittweises, risikominimierendes Vorgehen empfohlen. Als Fallbeispiel wird die erfolgreiche Übernahme des Finanzdienstleisters NatWest durch die Royal Bank of Scotland (RBS) im Jahr 2000 aufgeführt. RBS räumte der möglichst störungsfreien Fortführung der Geschäftsprozesse während der Zusammenführung höchste Priorität ein. Aufgrund der geringeren Kosten und des einfacheren Betriebs wurde entschieden, die wesentlich kleinere, kostengünstigere, aber funktional weniger umfangreiche IT-Landschaft von RBS zur Grundlage der neuen Unternehmens-IT zu machen. 3.2.5.4 Zusammenfassung und Gestaltungsempfehlungen Ausgehend vom systemtheoretischen Fundament der vorliegenden Arbeit wurde im 2. Kapitel Integrationsmanagement als Teildisziplin des IT-Managements definiert. Integrationsmanagement unterliegt deshalb der übergeordneten Zielsetzung des IT-Managements: der Sicherstellung des informationswirtschaftlichen Gleichgewichtes. Dieses Ziel verlangt die effiziente Deckung der Informationsbedarfe der Anwenderorganisation und der Systemumwelt bei der Durchführung der Geschäftsprozesse des Unternehmens. Diese Zielsetzung bedeutet für ein ganzheitliches Integrationsmanagement, wie in 2.2.2 beschrieben: ƒ ƒ

die Formulierung einer adaptierbaren, strategischen Integrationskonzeption und das Organisieren, Entscheiden und Steuern der Realisierung von Integrationsanforderungen.

HEAP, ISRAELIT UND SHPILBERG liefern mit ihrem Aufsatz Leitlinien für das Organisieren, Entscheiden und Steuern der Realisierung der Integration von ITLandschaften und IT-Organisationen im Rahmen von Unternehmensfusionen. Diese werden zu folgenden Gestaltungsempfehlungen zusammengefasst:

144

3 Entwicklung übergeordneter Gestaltungsempfehlungen

Gestaltungsempfehlung 5.1 – Die Nutzenbetrachtung der IT-Konsolidierung im Rahmen von Fusionen muss die Generierung neuer Wertbeiträge auf Geschäftsebene umfassen. Gestaltungsempfehlung 5.2 - Schnelle IT-Konsolidierung vor Perfektion zur Sicherung des mindestnotwendigen dynamische Potenzials während der Transitionsphase Gestaltungsempfehlung 5.3 – Kritische Prüfung des Einsatzes eines Best-ofBreed-Ansatzes bei der Definition der Ziel-IT-Landschaft Gestaltungsempfehlung 5.4 – Aufrechterhaltung des informationswirtschaftlichen Gleichgewichtes durch Ressourcenkonzentration auf Sicherstellung des ordnungsgemäßen IT-Betriebs 3.2.5.5 IT-Konsolidierung und Aufbau einer integrierten Informationswirtschaft Im vorherigen Abschnitt wurden Gestaltungsempfehlungen zur Erneuerung der IT-Landschaft im Rahmen der Unternehmensintegration global verteilter Organisationen erarbeitet. Die Kernaussage besteht hier darin, dass diese Neugestaltung der IT-Landschaft der Erneuerung und Verschlankung der Geschäftsprozesse unterzuordnen ist. Wird diese Empfehlung auf die dargestellte Konstellation der Unternehmensfusion übertragen, so bedeutet dies, die Geschäftsprozessarchitektur grundlegend zu verändern und, davon ausgehend, eine erneuerte IT-Landschaft aufzubauen. Die aus dem Aufsatz von HEAP, ISRAELIT UND SHPILBERG abgeleiteten Gestaltungsempfehlungen zur IT-Konsolidierung bei Unternehmensfusionen weisen darauf hin, dass die beschriebene Übertragung der Gestaltungsempfehlungen des vorherigen Abschnittes auf die Konstellation der Unternehmensfusion problematisch sein kann. Diese Problematik ergibt sich aus der Empfehlung zur schnellen IT-Konsolidierung, der die Erneuerung der Geschäftsprozesslandschaft zuwiderläuft. Ein entsprechendes Projekt wäre in Abbildung 68 im Portfolioquadranten 3 einzuordnen, würde also nicht im Fokusquadranten der ITKonsolidierung liegen. 3.3 Zusammenfassung Im dritten Kapitel wurden übergeordnete Gestaltungsempfehlungen für das ganzheitliche Integrationsmanagement in der Unternehmens-IT aufgestellt. Dies erfolgte, indem verwandte Arbeiten identifiziert und diese auf der Grundlage des

145

3.3 Zusammenfassung

im 2. Kapitel geschaffenen begrifflichen Fundamentes analysiert wurden. Das Ergebnis dieser Analyse sind übergeordnete Gestaltungsempfehlungen mit folgenden Schwerpunkten: ƒ ƒ ƒ ƒ ƒ

Komplexitätsmanagement der Unternehmens-IT Ganzheitliche Integrationslösungen Integration der Unternehmens-IT und adaptive Unternehmensarchitekturen Gestaltung einer integrierten Informationswirtschaft Integration der Unternehmens-IT bei Fusionen und Übernahmen

Abbildung 71 fasst zeigt die nach Kapitel 3 vorliegenden Gestaltungsempfehlungen zum Integrationsmanagement zusammen. Gestaltungsprinzipien zum Integrationsmanagement der Unternehmens-IT GP1

Verständnis der Unternehmens-IT als komplexes Teilsystem des Unternehmens

GP2

Integrationsmanagement innerhalb eines breiten Spektrums von Integrationsanforderungen

GP3

Integrationsmanagement als Teildisziplin des IT-Managements

GP4

Integrationsmanagement innerhalb der Leitplanken einer ITUnternehmensarchitektur

Übergreifende Gestaltungsempfehlungen zum Integrationsmanagement der Unternehmens-IT Komplexitätsmanagement der Unternehmens-IT

Gestaltung von Integrationslösungen

GE 1.1- GE1.5

GE2.1 – GE2.4

Unternehmensintegration und Erneuerung der ITLandschaft in verteilten Organisationen

Handlungsmuster für die Integration der Unternehmens-IT bei Fusionen und Übernahmen

GE4.1 – GE4.3

GE5.1 – GE5.4

Unternehmens-IT und adaptive Unternehmensarchitekturen GE3.1 – GE3.2

Abbildung 71: Gestaltungsempfehlungen zum Integrationsmanagement nach Abschluss der Analyse verwandter Arbeiten

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

Was ist UnternehmensIT?

Das Unternehmen als komplexes, dynamisches, offenes System

Was ist ganzheitliches Integrationsmanagement?

Spektrum Integrationsmanagement

Einbettung Integrationsmanagement in das ITManagement

Grundmodell zum Integrationsmanagement

Systemtheoretisches Fundament

Integrationsmanagement und Unternehmensarchitektur

Forschungsdesign

Kapitel 2

Kapitel 1

Die Entwicklung des Gesamtkonzeptes zum Integrationsmanagement in Form eines Systems von Gestaltungsempfehlungen vollzieht sich in zwei Schritten. Im ersten Schritt (3. Kapitel) werden übergeordnete Gestaltungsempfehlungen auf Basis der Analyse verwandter Arbeiten entwickelt. Der hier erreichte Stand ist in Abbildung 73 dargestellt. Kapitel 4 deckt den zweiten Schritt ab, die Ergänzung und Verfeinerung dieses Standes durch die Entwicklung weiterführender Gestaltungsempfehlungen. Die folgende Abbildung zeigt die Einordnung des 4. Kapitels in das Vorgehen zur Entwicklung des Konzeptes zum Integrationsmanagement.

Gestaltungsprinzipien zum Integrationsmanagement der Unternehmens-IT

Weiterführende Gestaltungsempfehlungen zum Integrationsmanagement der Unternehmens-IT

Kapitel 4

Übergeordnete Gestaltungsemfehlungen zum Integrationsmanagement der Unternehmens-IT

Kapitel 3

Analyse von Arbeiten aus Forschung und Praxis

Abbildung 72: Kapitel 4 und die Entwicklung des Systems von Gestaltungsempfehlungen G. Dern, Integrationsmanagement in der Unternehmens-IT, DOI 10.1007/978-3-8348-8154-0_4, © Vieweg+Teubner Verlag | Springer Fachmedien Wiesbaden GmbH 2011

148

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

Im 4. Kapitel wird zunächst der bisher erreichte Stand reflektiert, um den Verfeinerungsbedarf der vorliegenden Gestaltungsempfehlungen zu bestimmen. Daraus wird die Aufgabenstellung der weiteren Ausarbeitung abgeleitet, die dann unter Einbeziehung ausgewählter Arbeiten aus Forschung und Praxis bearbeitet wird. Übergreifende Gestaltungsempfehlungen zum Integrationsmanagement Komplexitätsmanagement der Unternehmens-IT

Gestaltung von Integrationslösungen

GE1.1

GE2.1

GE1.2

GE2.2

GE1.3

GE2.3

GE1.4

GE2.4

Erweiterung der IT-Prozesse um Bausteine zur Steuerung der Komplexitätswirkung von IT-Projekten Durchführung von Maßnahmen zur Gestaltung der Nachfragerintegration mit der IT-Organisation Selektion von Leistungsanforderungen der Anwenderorganisation aufgrund einer systematischen Bewertung der Komplexitätswirkung Durchführung von Maßnahmen zur Standardisierung der Elemente der IT-Landschaft

Verankerung ganzheitlicher Integrationslösungen auf Geschäftsebene Entwicklung ganzheitlicher Integrationslösungen als eigenständige Disziplin der Gestaltung der IT-Landschaft auf Grundlage einer IT-Unternehmensarchitektur Aufstellung und Management eines Portfolios von Integrationslösungen mit Hilfe eines darauf ausgerichteten Vorgehensmodells Einführung einer Kennzahl zur Bewertung und Steuerung der Integrationseffizienz der IT-Organisation

GE1.5

Durchführung von Optimierungsmaßnahmen von ITArchitekturen zur Komplexitätsreduktion

Handlungsmuster für die Integration der Unternehmens-IT bei Fusionen und Übernahmen GE5.1

Unternehmensintegration und Erneuerung der ITLandschaft in verteilten Organisationen

Nutzenbetrachtung der IT-Konsolidierung im Rahmen von Fusionen muss die Generierung neuer Wertbeiträge auf Geschäftsebene umfassen

GE4.1

GE5.2

GE4.2

GE5.3

GE4.3

GE5.4

Der Aufbau einer organisationsübergreifend integrierten IT-Landschaft folgt der Erneuerung der Geschäftsprozesslandschaft Neugestaltung der IT-Landschaft im Rahmen einer adaptiven Prozessarchitektur Erneuerung von Kernsystemen auf Basis von ITArchitekturen, die den Anforderungen der Geschäftsarchitektur bzgl. Adaptierbarkeit & Flexibilität folgen

Schnelle IT-Konsolidierung vor Perfektion zur Sicherung des mindestnotwendigen dynamische Potentials während der Transitionsphase Kritische Prüfung des Einsatzes eines Best-of-BreedAnsatzes bei der Definition der Ziel-IT-Landschaft Aufrechterhaltung des informationswirtschaftlichen Gleichgewichtes durch Ressourcenkonzentration auf Sicherstellung des IT-Betriebes

Unternehmens-IT und adaptive Unternehmensarchitekturen GE3.1

Aufwandsreduktion für Integrationsleistungen durch Komplexitätsreduktion mit Hilfe adaptiver Geschäftsarchitekturen

GE3.2

Service-orientierte Integration in adaptive Geschäftsarchitekturen auf der Grundlage ganzheitlicher Integrationslösungen

Abbildung 73: Konzept zum Integrationsmanagement – übergeordnete Gestaltungsempfehlungen 4.1 Festlegung des Verfeinerungsbedarfs Integrationsmanagement wird in der vorliegenden Arbeit aus einer holistischen, die gesamte Unternehmens-IT abdeckenden Perspektive betrachtet und als Teildisziplin des Managements der Unternehmens-IT (IT-Management) verstanden. Um diesem Anspruch gerecht zu werden, besteht die Notwendigkeit, die Einbettung des Integrationsmanagements in die IT-Prozesslandschaft des Unternehmens festzulegen.

4.1 Festlegung des Verfeinerungsbedarfs

149

Zu diesem Zweck wird im 4. Kapitel zunächst ein auf die Problemstellung zugeschnittenes Referenzmodell161 zur IT-Prozesslandschaft erarbeitet, das bei der Entwicklung weiterführenden Gestaltungsempfehlungen verwendet wird, um die Abbildung auf die IT-Prozesslandschaft zu beschreiben. IT-Management unterliegt dem Ziel der Sicherstellung des informationswirtschaftlichen Gleichgewichtes. Dies erfordert die fortlaufende Weiterentwicklung der IT-Landschaft zur Adaption an die veränderten Informationsbedarfe der Anwenderorganisation. Diese Weiterentwicklung vollzieht sich innerhalb der ITProzesse des Unternehmens und innerhalb der Leitplanken der IT-Unternehmensarchitektur. Hieraus ergibt sich die Anforderung, die Entwicklung des Referenzmodells mit einem Ansatz zur IT-Unternehmensarchitektur zu verzahnen. Im Folgenden werden zunächst die Schwerpunkte der Detaillierung der bisher vorliegenden Gestaltungsempfehlungen definiert. Daraus wird dann die Gesamtaufgabenstellung der weiteren Ausarbeitung des 4. Kapitels abgeleitet. Die Ausarbeitung folgt dem für die vorliegende Arbeit im Forschungsdesign gewählten Design-Science-Ansatz, d. h. basiert auf der Aufstellung von Definitionen, Modellen, Methoden und Vorgehensweisen. 4.1.1 Integrationsmanagement in der strategischen Konzeption der Unternehmens-IT Als Teildisziplin des IT-Managements erfordert ganzheitliches Integrationsmanagement nach dem im 2. Kapitel festgelegten Verständnis die Berücksichtigung in der strategischen Konzeption der Unternehmens-IT. Hieraus ergibt sich die Forderung nach einem Modell zur Einbettung des Integrationsmanagements in die strategische Konzeption der Unternehmens-IT. Hierbei ist das Komplexitätsmanagement als zentraler Baustein des Integrationsmanagements zu berücksichtigen. 4.1.2 Komplexitätsmanagement der Unternehmens-IT In Abschnitt 3.2 wurde gezeigt, dass die Steuerung der Komplexität der Unternehmens-IT zentraler Bestandteil eines Integrationsmanagements darstellt. Hieraus ergibt sich die Forderung nach der Entwicklung eines Kennzahlensystems zur Messung der Komplexität der Unternehmens-IT. 161 Ein Referenzmodell ist ein verallgemeinerndes Modell für eine Klasse von Sachverhalten, das als Blaupause für die Entwicklung spezieller Modelle dient. Das Referenzmodell stellt somit ein Entwurfsmuster dar, das als idealtypisches Modell für die Klasse der zu modellierenden Sachverhalte verwendet werden kann.

150

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

Da - wie in Abschnitt 3.2 gezeigt wurde - die Komplexität der Unternehmens-IT wesentlichen Einfluss auf den Umfang zukünftiger Integrationsanforderungen sowie auf die Effizienz der IT-Organisation bei der Erbringung von Integrationsleistungen besitzt, wirkt die Komplexität der Unternehmens-IT direkt auf die in Abbildung 1 dargestellte Verteilung von Integrationsaufwänden im Vergleich zu Aufwänden zur Erfüllung fachlicher Anforderungen. Nach Erfahrung des Autors der vorliegenden Arbeit geht die größte Veränderungswirkung auf die Komplexität der Unternehmens-IT von IT-Projekten aus; IT-Projekte müssen daher im Fokus des Komplexitätsmanagements der Unternehmens-IT stehen. Hier setzen die Gestaltungsempfehlungen 1.1 und 1.3 an. 1.1 empfiehlt die Erweiterung der IT-Prozesse um Bausteine zur Steuerung der Komplexitätswirkung von IT-Projekten, 1.3 die Selektion von Leistungsanforderungen der Anwenderorganisation auf Basis einer systematischen Bewertung der Komplexitätswirkung einschließlich der Wirkung auf die Reaktionsfähigkeit, d. h. das dynamische und das statische Potenzial der Unternehmens-IT. Hieraus ergibt sich die Forderung nach der Verfeinerung der Gestaltungsempfehlungen 1.1 und 1.3. Um dem Anspruch der ganzheitlichen Sicht zu entsprechen, ist dazu unter Bezugnahme auf das Referenzmodell zur IT-Prozesslandschaft ein Ansatz zur Anforderungsselektion und zur Projektsteuerung unter Einbeziehung der Komplexitätswirkung und der Wirkung auf die Reaktionsfähigkeit zu entwickeln. Berücksichtigt man hier, dass die Zielsetzung des Integrationsmanagements wie beschrieben darin besteht, die Aufwandsverteilung so zu verändern, dass der auf Integrationsanforderungen zurückzuführende Aufwand möglichst gering gehalten wird, so folgt die Notwendigkeit, die Erhebung und Bewertung von Integrationsaufwänden zu berücksichtigen. Darüber hinaus ergibt sich die Frage, wie die auf einzelne Lösungen fokussierte IT-Projektsicht und die Gesamtsicht auf die IT-Landschaft miteinander verzahnt werden können. Wie in Abschnitt 3.2.1 dargestellt, besteht eine Möglichkeit der Komplexitätsbegrenzung darin, Architekturen von IT-Systemen im Hinblick auf die in der Unternehmens-IT durch die Umsetzung von Leistungsanforderungen verursachte Komplexitätswirkung zu optimieren. Die Gestaltungsempfehlung 1.5 empfiehlt daher die Durchführung von Maßnahmen zur Komplexitätsoptimierung von ITArchitekturen. Dies führt zu folgenden Fragen: 1.

Unterstellt man die oben geforderte Entwicklung eines Kennzahlensystems zur Komplexität der Unternehmens-IT, so ist die Frage, welche ergänzenden Leitlinien zur Organisation der IT-Landschaft aus diesem Kennzahlensystem hergeleitet werden können.

4.1 Festlegung des Verfeinerungsbedarfs

2.

3.

151

Es stellt sich die Frage nach der aktiven Gestaltung der Lebenszyklusverläufe von IT-Systemen aus der Perspektive der zukünftigen Komplexitätsentwicklung der IT-Landschaft einschließlich deren Beherrschbarkeit. Aus der Gestaltungsempfehlung 4.3 zur Erneuerung von Kernsystemen unter Berücksichtigung von IT-Architekturen, die auf Adaptierbarkeit und Flexibilität ausgerichtet sind, folgt die Frage nach Leitlinien zur Organisation von IT-Landschaften im Hinblick auf Adaptierbarkeit, Flexibilität und Agilität unter Berücksichtigung der Komplexitätswirkung einer solchen antizipierenden Organisation. Ein Spezialfall stellt in diesem Zusammenhang die proaktive Gestaltung von IT-Landschaften in Bezug auf Übernahmen, Fusionen oder Abspaltungen von Unternehmen bzw. von Unternehmensteilen dar. Dieser Spezialfall ist aus Sicht der entwickelten Gestaltungsempfehlungen zu analysieren.

4.1.3 Ganzheitliche Integrationslösungen In Abschnitt 3.2.2 wird das Konzept der ganzheitlichen Integrationslösung entwickelt, woraus Gestaltungsempfehlungen abgeleitet werden. Gestaltungsempfehlung 2.3 empfiehlt den Einsatz einer dedizierten Methode zum Management eines Portfolios ganzheitlicher Integrationslösungen, um auf diese Weise die Verankerung von Integrationslösungen auf Geschäftsebene sicherzustellen und die im Unternehmen eingesetzten Integrationslösungen im Hinblick auf die Gesamtanforderungen und die Effizienz übergreifend zu optimieren. Ein entsprechendes Vorgehensmodell wird entworfen. Aus der am Anfang von Abschnitt 4.1 aufgestellten Forderung nach der Einbettung des Integrationsmanagements in die IT-Prozesslandschaft ergibt sich die zusätzliche Forderung, das Vorgehensmodell in das Referenzmodell der IT-Prozesslandschaft zu integrieren. Dabei ist Empfehlung 2.3 zu reflektieren. 4.1.4 Leistungsfähigkeit der Unternehmens-IT in Bezug auf Integrationsleistungen Im Rahmen der Entwicklung des Konzeptes ganzheitlicher Integrationslösungen wurde die Kennzahl der Integrationseffizienz zur Leistungsfähigkeit der ITOrganisation bei der Erbringung von Integrationsleistungen entwickelt und deren Einführung empfohlen (Gestaltungsempfehlung 2.4). In die Kennzahl geht die Bewertung der Komplexität von Integrationsanforderungen ein. Hier ergibt sich erstens die Forderung nach der Definition eines Ansatzes zur Komplexitätsbewertung von Integrationsanforderungen und zweitens nach Leitlinien zur Verbesserung der Integrationseffizienz der Unternehmens-IT.

152

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

4.1.5 Zusammenfassung – Aufgabenstellung der weiteren Ausarbeitung Der identifizierte Verfeinerungsbedarf wird zur Gesamtaufgabenstellung der weiteren Ausarbeitung im 4. Kapitel zusammengefasst: ƒ ƒ

Es ist ein Referenzmodell der IT-Prozesslandschaft zu entwickeln. Ein Ansatz zur IT-Unternehmensarchitektur ist zu beschreiben und mit dem definierten Referenzmodell zu verzahnen. Die in Abbildung 73 zusammengefassten Gestaltungsempfehlungen sind zu vervollständigen, indem entlang der nachfolgenden Fragestellungen weiterführende Gestaltungsempfehlungen unter Bezugnahme auf das Referenzmodell zur IT-Prozesslandschaft erarbeitet werden: o Wie kann das Integrationsmanagement in die strategische Konzeption und in das Management der Unternehmens-IT eingebettet werden? Wie werden hier Aspekte des Komplexitätsmanagements und der Leistungsfähigkeit der Unternehmens-IT in Bezug auf die Erbringung von Integrationsleistungen berücksichtigt? o Wie kann ein Kennzahlensystem zum Integrationsmanagement aufgestellt werden? o Wie werden die strategische Gesamtsicht und die operative Weiterentwicklung der IT-Landschaft miteinander verzahnt? o Wie können Vorgehensweisen zur Selektion und Bewertung von Leistungsanforderungen an die Unternehmens-IT in der Steuerung von ITProjekten verankert werden, sodass Komplexitätswirkung und Integrationsaufwände systematisch Berücksichtigung finden? o Welche ergänzenden Leitlinien zum Management der IT-Landschaft können zu folgenden Punkten aufgestellt werden? • Gestaltung der IT-Landschaft entlang eines Kennzahlensystems zur Komplexitätsmessung • Lebenszyklusmanagement von IT-Systemen • Organisation der IT-Landschaft im Hinblick auf Adaptierbarkeit, Flexibilität und Agilität, insbesondere in Bezug auf die zukünftige Integration/Desintegration von (Teil-) IT-Landschaften im Rahmen von Übernahmen, Fusionen oder Abspaltungen o Wie kann das Vorgehensmodell zur Entwicklung eines Portfolios ganzheitlicher Integrationslösungen in die IT-Prozesslandschaft eingebettet werden? o Welche Gestaltungsempfehlungen lassen sich im Hinblick auf die Steigerung der Leistungsfähigkeit der Unternehmens-IT bei der Erbringungen von Integrationsleistungen entwickeln?

153

4.1 Festlegung des Verfeinerungsbedarfs

Die Gesamtaufgabenstellung der weiteren Ausarbeitung im 4. Kapitel ist in der folgenden Abbildung zusammengefasst. 1

Entwicklung Referenzmodell zur IT-Prozesslandschaft 2

Definition eines Ansatzes zur IT-Unternehmensarchitektur 3

Integrationsmanagement in der strategischen Konzeption Einbettung Integrationsmanagement in der strategischen Konzeption Leistungsfähigkeit der Unternehmens-IT im Hinblick auf Integrationsleistungen

Komplexitätsmanagement

4

Entwicklung eines Kennzahlensystems 5

Integrationsmanagement und Planung & Controlling von IT-Projekten Selektion von Anforderungen unter Berücksichtigung von Komplexitätswirkung + Integrationsaufwänden

Steuerung unter Berücksichtigung von Komplexitätswirkung und Integrationsaufwänden

6

Verzahnung Gesamtsicht und IT-Projektsicht 7

Ergänzende Leitlinien zur Organisation IT-Landschaft

Gestaltung der ITLandschaft mit Hilfe von Komplexitätskennzahlen

Lebenszyklusmanagement von ITSystemen

IT-Landschaft und Adaptierbarkeit, Flexibilität & Agilität

8

Ganzheitliche Integrationslösungen und IT-Portfoliomanagement 9

Empfehlungen zur Steigerung der Integrationseffizienz der Unternehmens-IT

Abbildung 74: Vorgehen bei der Entwicklung weiterführender Gestaltungsempfehlungen

154

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

4.2 Definition eines Referenzmodells zur IT-Prozesslandschaft 4.2.1 Definition IT-Prozesslandschaft Gemäß der definierten Aufgabenstellung ist zunächst ein Referenzmodell zur ITProzesslandschaft als Grundlage der Erweiterung der Gestaltungsempfehlungen zu erarbeiten. Ausgangspunkt ist die Erweiterung des begrifflichen Fundamentes der vorliegenden Arbeit durch folgende Definition: Definition - IT-Prozesslandschaft Die Gesamtheit aller IT-Prozesse in der Unternehmens-IT eines Unternehmens bildet die IT-Prozesslandschaft. Die fundamentale Grundstruktur der IT-Prozesslandschaft wird als IT-Prozessarchitektur bezeichnet. IT-Prozesse werden in ƒ Kern-IT-Prozesse und ƒ unterstützende IT-Prozesse unterschieden. Ein Kern-IT-Prozess wird als Folge von Aktivitäten in der Unternehmens-IT verstanden, der von einem Leistungsnachfrager der Unternehmens-IT ausgelöst wird, beim Leistungsfrager endet und für diesen Nutzen erzeugt. Unterstützende IT-Prozesse sind Aktivitätenfolgen, die Nutzen innerhalb der Unternehmens-IT erzeugen und die Durchführung von Kern-IT-Prozessen unterstützen. Ein Referenzmodell zur ITProzesslandschaft ist ein Modell, das als Blaupause zur Definition einer IT-Prozessarchitektur verwendet werden kann. Auf Basis dieser Definition wird die IT-Prozessarchitektur im erweiterten Grundmodell zum Integrationsmanagement der vorliegenden Arbeit positioniert. Sie ist gemäß der in Abschnitt 2.3.2 erarbeiteten Definition Bestandteil der ITUnternehmensarchitektur.

155

IB

Informationsfluss Anforderungsfluss EFFZ Effizienzziel IB Informationsbedarf LANF Leistungsanforderung an U-IT IANF Integrationsanforderung an U-IT INTL Integrationsleistung der U-IT FANF Fachliche Anforderung i.e.S. IE Informationselement IS = IT-System Legende

Unternehmensgeschäftsarchitekturr

Schnittstelle

Unternehmen als System Geschäftsprozesse

Unternehmensumwelt

IE Schnittstelle

Management des Gesamtunternehmens

IE

EFFZ

Anwenderorganisation IE

IB

EFFZ intern/extern initiiert

IT-Unternehmensarchitektur

Unternehmensumwelt

U n t e r n e h m e n s a r c h i t e k t u r

4.2 Definition eines Referenzmodells zur IT-Prozesslandschaft

LANF

INTL

IS

IANF

FANF INTL

IT-Prozesse Zweck: InfoTransformation zur Befriedigung Info-Bedarf

Zweck: Planung/Steuerung/ Weiterentwicklung/Betrieb IT-Landschaft

IT-Landschaft

IT-Organisation

Zweck: Effiziente Befriedigung Informationsbedarf

Die IT-Prozessarchitektur – strukturierende Abstraktion der IT-Prozesslandschaft der Unternehmens-IT als Teil der IT-Unternehmensarchitektur - Definition auf Basis eines Referenzmodells zur IT-Prozesslandschaft

Unternehmens-IT

Abbildung 75: Die IT-Prozessarchitektur im erweiterten Grundmodell zum Integrationsmanagement 4.2.2 Abgrenzung zu COBIT, ITIL und ASL Das Referenzmodell zur IT-Prozesslandschaft ist gemäß der oben definierten Aufgabenstellung unter Berücksichtigung der folgenden Aspekte zu entwickeln: ƒ ƒ ƒ ƒ ƒ ƒ

Verzahnung mit einem Ansatz zur IT-Unternehmensarchitektur Einbettung des Integrationsmanagements in die strategische Konzeption der Unternehmens-IT Komplexitätsmanagement der Unternehmens-IT Leistungsfähigkeit der Unternehmens-IT in Bezug auf die Erbringung von Integrationsleistungen Steuerung von IT-Projekten Management eines Portfolios ganzheitlicher Integrationslösungen

156

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

Ausgangspunkt der Entwicklung des Referenzmodells bildet die Analyse international anerkannter Rahmenkonzepte (Frameworks) zur Gestaltung der Unternehmens-IT. Solche Rahmenkonzepte liefern eine umfassende Sammlung erprobter Vorgehensweisen zur Gestaltung der Unternehmens-IT und stellen dabei eine bestimmte Perspektive in den Mittelpunkt, wie z. B. das Management der von der Unternehmens-IT bereitgestellten IT-Services. Die Rahmenkonzepte umfassen i. d. R. ein Referenzmodell zur IT-Prozesslandschaft, das als Ordnungsrahmen der angestrebten Standardisierung fungiert. Die Referenzmodelle ausgewählter Rahmenkonzepte werden hinsichtlich ihrer Eignung als Ausgangspunkt der Entwicklung des für die vorliegende Arbeit geforderten Referenzmodells analysiert. Betrachtet werden die Rahmenkonzepte COBIT, ITIL und ASL. 4.2.2.1 COBIT – Control Objectives for Information and related Technology COBIT ist ein international anerkanntes Rahmenkonzept zur IT-Governance und entstand mit dem Anspruch der Steuerung (Controlling) der gesamten Unternehmens-IT. COBIT wurde ursprünglich von der Information Systems Audit and Control Foundation (ISACF) entwickelt, dem Forschungsinstitut der Information Systems Audit and Control Association (ISACA), und war zunächst auf den Einsatz bei Wirtschaftsprüfern, Endanwendern (d. h. innerhalb der Anwenderorganisation) und im IT-Management ausgerichtet. COBIT positioniert sich als Bindeglied zwischen unternehmensweiten Steuerungs-Frameworks und ITspezifischen Frameworks wie ITIL (s. u.). Das COBIT-Rahmenkonzept besteht aus gängigen, generell akzeptierten Praktiken (best practices), die sicherstellen, dass IT-Prozesse die Geschäftsziele unterstützen, dass Ressourcen verantwortungsvoll eingesetzt und die Risiken angemessen überwacht werden. COBIT unterstützt dies in der hier berücksichtigten Version 4.1 durch die Bereitstellung einer umfassenden Sammlung von 318 Steuerungszielen und eines Prozessreferenzmodells, das entlang von vier ITProzessgruppen strukturiert ist. Die Prozessgruppen zerfallen in insgesamt 34 ITProzesse, die gemäß COBIT die Managementprozesse der IT darstellen. Folgende Prozessgruppen sind definiert: ƒ ƒ ƒ ƒ

Planning and Organization (PO) Acquisition and Implementation (AI) Delivery and Support (DS) Monitoring (M)

Aus der Beschreibung ergibt sich, dass COBIT den Schwerpunkt auf die übergreifende Steuerung der Unternehmens-IT setzt. Aufgrund dieser Ausrich-

4.2 Definition eines Referenzmodells zur IT-Prozesslandschaft

157

tung liegt der Großteil der oben aufgeführten, durch das zu entwickelnde Referenzmodell zu berücksichtigenden Aspekte nicht im Fokus von COBIT. Das Referenzmodell von COBIT wird daher als Ausgangspunkt des in der vorliegenden Arbeit aufzustellenden Referenzmodells verworfen. 4.2.2.2 ITIL - IT Infrastructure Library ITIL ist eine Sammlung generell akzeptierter Praktiken zur Implementierung eines so genannten IT-Service-Delivery-Modells. Ein IT-Service-DeliveryModell operationalisiert einen Ansatz zum IT-Service-Management. Hierbei handelt es sich um einen ganzheitlichen Ansatz, den ein IT-Dienstleister (ITService-Provider) – also z. B. die IT-Organisation in der Unternehmens-IT nutzt, um sicherzustellen, dass die richtigen Dienstleistungen (IT-Services) dem Leistungsnachfrager in der Anwenderorganisation zum angemessenen Preis, in der geforderten Qualität und zur rechten Zeit bereitgestellt werden und die bereitgestellten Leistungen sich mit der Leistungserwartung des Leistungsnachfragers decken. Der Fokus von ITIL liegt auf den für den Betrieb einer IT-Landschaft notwendigen Prozessen, der damit verbundenen Aufbauorganisation sowie auf unterstützenden Werkzeugen. Als Referenzmodell zur Gestaltung der ITProzesslandschaft aus Sicht des Managements von IT-Dienstleistungen ist ITIL mittlerweile quasi zum Standard geworden. ITIL setzt den Fokus auf die Organisation von IT-Prozessen eines IT-Dienstleisters in Bezug auf das ServiceManagement. Dementsprechend stellt ITIL den zuverlässigen Betrieb von ITSystemen (applications) und der zugrunde liegenden IT-Basisinfrastruktur in den Mittelpunkt. ITIL definiert in der hier berücksichtigten Version 3 fünf ServiceDisziplinen, d. h. IT-Prozessgruppen. Diese Disziplinen können der IT-Prozessgruppe Delivery and Support aus COBIT zugeordnet werden: ƒ ƒ ƒ ƒ ƒ

Service Strategy Service Design Service Transition Service Operation Kontinuierliche Service-Verbesserung

Die beschriebene Fokussierung von ITIL bedingt, dass ein großer Teil der bei der Entwicklung des Referenzmodells zu berücksichtigenden Aspekte nicht adressiert werden. Das Referenzmodell von ITIL wird daher nicht als Grundlage für das in der vorliegenden Arbeit zu entwickelnde Referenzmodell genutzt.

158

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

4.2.2.3 ASL - Application Services Library 4.2.2.3.1

Analyse des ASL-Referenzmodells

ASL162 ist ein holistisches, öffentlich verfügbares Rahmenkonzept zum Management der Gesamtheit der Anwendungen163 eines Unternehmens und beschreibt im Sinne der Begrifflichkeit der vorliegenden Arbeit ein Framework zum Management der IT-Landschaft. ASL basiert auf einem Referenzmodell zur IT-Prozesslandschaft und BestPractices, um hochwertige und umfassende Dienstleistungen im Bereich des Anwendungsmanagements zu erbringen. Der Anspruch eines holistischen Rahmenkonzeptes wird ASL gerecht, indem nicht nur operative Prozesse des Betriebs, der Wartung und der Weiterentwicklung von IT-Systemen betrachtet werden, sondern darüber hinaus Management- und Strategieprozesse. Ebene

Fokus

Umfang

Zeitbetrachtung

Perspektive

Operative Ebene

aktuell

groß

kontinuierlich

operativ

ManagementEbene

aktuell und das kommende Jahr

klein

kontinuierlich

taktisch

Strategische Ebene

kommende Jahre

klein

periodisch

strategisch

Tabelle 4:

Klassifikation der Prozessebenen von ASL

ASL trifft Grundannahmen in Bezug auf die Prozessebenen: ƒ ƒ

Die Unternehmens-IT muss strategische, Management- und operative Prozesse durchführen, um proaktiv und mit voller Ergebnisverantwortung für die Anwenderorganisation agieren zu können. Die operativen Prozesse und die Managementprozesse haben das Ziel, die Stabilität, die Kontinuität und Kompatibilität der IT-Landschaft mit den Geschäftsprozessen permanent zu überwachen und sicherzustellen – d. h. das informationswirtschaftliche Gleichgewicht zu gewährleisten. Die strategischen Prozesse legen die langfristige Ausrichtung der IT-Landschaft und

162 Die Analyse basiert auf der Beschreibung von ASL durch VAN DER POLS in [vdPols07] und erfolgt innerhalb des begrifflichen Fundamentes der vorliegenden Arbeit. 163 In ASL wird der Begriff der Anwendung (application) synonym zum Begriff des IT-Systems verwendet.

159

4.2 Definition eines Referenzmodells zur IT-Prozesslandschaft

ƒ

die Aufstellung der IT-Organisation im Hinblick auf die Anforderungen und die Zusammenarbeit mit der Anwenderorganisation fest. ASL definiert auf der Grundlage dieser Grundannahmen drei Prozessebenen, die nach folgender Tabelle klassifiziert werden können.

ASL stellt zwei Objekttypen in den Mittelpunkt der Betrachtung aller drei Ebenen. Es handelt sich erstens um IT-Services, also die durch die Unternehmens-IT für die Anwenderorganisation erbrachten Dienstleistungen, und zweitens um Anwendungen, d. h. IT-Systeme. Damit ergibt sich aus Sicht von ASL unter Projektion auf das begriffliche Fundament der vorliegenden Arbeit die folgende Grundstruktur der IT-Prozesslandschaft. Dienstleistungen für die Anwenderorganisation (IT-Services)

IT-Systeme (Applications)

Strategische Ebene

Strategische Konzeption der Unternehmens-IT

ManagementEbene

Management von IT-Organisation und IT-Landschaft

Operative Ebene

Betrieb und Weiterentwicklung der IT-Landschaft

Abbildung 76: Grundstruktur der IT-Prozesslandschaft nach ASL ASL definiert entlang dieser Struktur sechs IT-Prozessgruppen. Auf der Management-Ebene verzichtet ASL auf die Unterscheidung nach dem Objekttyp, sodass sich zunächst fünf Gruppen ergeben. Zusätzlich definiert ASL auf der operativen Ebene Koordinationsprozesse, die die sechste Gruppe bilden. Die folgende Abbildung zeigt die Verfeinerung der Grundstruktur mithilfe der ASLProzessgruppen.

160

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

Dienstleistungen für die Anwenderorganisation (IT-Services)

Strategische Ebene

ManagementEbene

Operative Ebene

IT-Systeme (Applications)

ASL-OrganisationCycle-Management

ASL-ApplicationsCycle-Management

(OCM)

(ACM)

ASL-Managementprozesse

ASL-Wartung

ASL-Erweiterung/ Erneuerung

Strategische Konzeption der Unternehmens-IT

Management von IT-Organisation und IT-Landschaft

Betrieb und Weiterentwicklung der IT-Landschaft

ASL-Koordinationsprozesse

Abbildung 77:

Prozessgruppen in der IT-Prozesslandschaft nach ASL

VAN DER POLS beschreibt die Zielsetzung für jede dieser Prozessgruppen. Sie wird folgendermaßen interpretiert:

ƒ

ƒ

ASL-Application-Cycle-Management (ACM) ACM zielt auf die Entwicklung einer von der Geschäftsstrategie ausgehenden Strategie der Informationsbereitstellung mithilfe von IT-Systemen zwecks Befriedigung des Informationsbedarfs der Anwenderorganisation. ASL-Organisation-Cylce-Management (OCM) OCM zielt auf die Entwicklung einer auf die Anwenderorganisation ausgerichteten Anwendungsmanagement-Strategie. Sie definiert die strategische Positionierung der IT-Organisation, um als Dienstleister das Management der IT-Landschaft im Auftrag der Anwenderorganisation erfolgreich durchzuführen.

Nach dem systemtheoretischen Modell der Unternehmens-IT der vorliegenden Arbeit liefert ƒ

die Prozessgruppe ACM die Strategie, wie der Zweck des Teilsystems ITLandschaft (Informationstransformation mithilfe von IT-Systemen zur Befriedigung des Informationsbedarfs der Anwenderorganisation) erfüllt wird

161

4.2 Definition eines Referenzmodells zur IT-Prozesslandschaft

ƒ

und die Prozessgruppe OCM die Strategie, wie der Zweck des Teilsystems IT-Organisation (Planung, Steuerung, Weiterentwicklung und Betrieb der IT-Landschaft) erfüllt wird.164 Unternehmen als komplexes System Geschäftszweck

Teilsystem Anwenderorganisation

Schnittstelle Schnittstelle Schnittstelle

Teilsystem IT-Landschaft

Teilsystem IT-Organisation

Schnittstelle

Schnittstelle … …

Zweck: Informationstransformation

Zweck: Planung/Steuerung/ Weiterentwicklung/Betrieb

Zweck: Effiziente Befriedigung Informationsbedarf Output der Prozessgruppe ACM: Strategie zur Erfüllung des Zwecks der ITLandschaft

Teilsystem Unternehmens-IT Transformation

Output der Prozessgruppe OCM: Strategie zur Erfüllung des Zwecks der ITOrganisation

Abbildung 78: Positionierung von ACM und OCM im systemtheoretischen Modell der Unternehmens-IT Die Zielsetzung der ASL-Prozessgruppen der operativen Ebene wird ausgehend von VAN DER POLS wie folgt zusammengefasst: ƒ

ASL-Wartung Die Zielsetzung der Wartungsprozesse besteht darin, existierende ITSysteme möglichst effektiv und mit möglichst geringem Ressourceneinsatz zur Befriedigung des Informationsbedarfes der Anwenderorganisation einzusetzen.

164 Die Entwicklung dieser Teilstrategien ist nach dem in Abschnitt 2.2 aus den Arbeiten von MALIK und von KRCMAR abgeleiteten Modell des IT-Managements Bestandteil der strategischen Konzeption der Unternehmens-IT. Ein Grundmodell zur strategischen Konzeption der Unternehmens-IT wird in Abschnitt 2.3 auf Basis des EWIM-Ansatzes beschrieben.

162 ƒ

ƒ

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

ASL-Erweiterung/Erneuerung Die Zielsetzung der Erweiterungs- und Erneuerungsprozesse besteht darin, die effiziente Weiterentwicklung der IT-Systeme entlang der Leistungsanforderungen an die Unternehmens-IT (aufgrund veränderter Informationsbedarfe der Anwenderorganisation) sicherzustellen. ASL-Koordination Die Prozesse der Erweiterung/Erneuerung und der Wartung sind eng miteinander verzahnt. Die Bausteine der IT-Systeme – wie Softwaremodule oder Datenelemente – werden im Rahmen der Erweiterung/Erneuerung erstellt bzw. weiterentwickelt und dann an die Prozesse der Wartung übergeben. Daraus ergibt sich aus Sicht von ASL die Notwendigkeit der Koordination. Die Zielsetzung der Prozessgruppe besteht daher darin, die Prozesse der Erweiterung/Erneuerung und der Wartung in Bezug auf das notwendige Change Management und auf Software Control & Distribution zu koordinieren.

Prozesse der Management-Ebene bilden nach ASL das Bindeglied zwischen der strategischen und der operativen Ebene. Die Zielsetzung der ManagementEbene besteht darin, die Prozesse der operativen Ebene aus einer Gesamtsicht heraus zu steuern und auf diese Weise sicherzustellen, dass diese in Übereinstimmung mit den auf der strategischen Ebene festgelegten Strategien durchgeführt werden. 4.2.2.3.2

Bewertung des ASL-Referenzmodells

Die Analyse des ASL-Rahmenkonzeptes zeigt die Nutzbarkeit als Basis eines Referenzmodells zur IT-Prozesslandschaft im Kontext der vorliegenden Arbeit. Da ASL auf das Anwendungsmanagement fokussiert ist, weist das Rahmenkonzept jedoch Lücken auf, die zu schließen sind, um dem Anspruch der vorliegenden Arbeit gerecht zu werden: ƒ ƒ

Die strategische Konzeption der Unternehmens-IT ist unterbelichtet. Ein dem erweiterten EWIM-Ansatz vergleichbarer Ansatz zur strategischen Konzeption ist nicht Bestandteil von ASL. Das IT-Portfoliomanagement als Kerndisziplin der Managementebene ist auf das IS-Portfoliomanagement beschränkt und auf der strategischen Ebene angesiedelt. Das IT-Portfoliomanagement sollte i. S. einer Gesamtsicht auf die Unternehmens-IT definiert und auf der Managementebene angesiedelt sein.

4.2 Definition eines Referenzmodells zur IT-Prozesslandschaft

ƒ ƒ

163

Aspekte der IT-Unternehmensarchitektur werden in ASL nicht explizit berücksichtigt. Die Durchführung von IT-Projekten als zentraler Prozess der Veränderung der IT-Landschaft ist nicht explizit im ASL-Referenzmodell ausgewiesen.

Im Folgenden wird ausgehend von der Grundstruktur von ASL ein Referenzmodell für die IT-Prozesslandschaft entworfen, welches auf dem begrifflichen Fundament der vorliegenden Arbeit beruht und die identifizierten Lücken schließt. Das Modell zeichnet sich durch folgende Merkmale aus: ƒ ƒ ƒ ƒ ƒ

Die strategische Ebene wird auf Basis des in Abschnitt 2.2.2 entwickelten Verständnisses der strategischen Konzeption der Unternehmens-IT gestaltet. Das IT-Portfoliomanagement bildet den Mittelpunkt der ManagementEbene. Das IT-Architekturmanagement, als Management der IT-Unternehmensarchitektur und sowie darein eingebetteter Teilarchitekturen, wird explizit berücksichtigt. Prozesse der IT-Projektdurchführung werden explizit berücksichtigt. Den Ausgangspunkt bildet die Verzahnung mit einem Ansatz zur Unternehmensarchitektur.

4.2.3 IT-Unternehmensarchitektur und IT-Prozesslandschaft Für das zu entwickelnde Referenzmodell wurde zu Beginn des vorangehenden Abschnittes die Forderung erhoben, die Verzahnung mit einem Ansatz zur ITUnternehmensarchitektur zu berücksichtigen. Dazu ist nach der in Abbildung 74 zusammengefassten Aufgabenstellung zunächst ein Ansatz zur IT-Unternehmensarchitektur zu definieren. Als Grundlage des Ansatzes zur Unternehmensarchitektur der vorliegenden Arbeit dient das Konzept der Vorlesung IT-Unternehmensarchitektur am HassoPlattner-Institut Potsdam von 2008165 von DERN UND KELLER. Das Konzept basiert auf der Zusammenführung der im deutschsprachigen Raum etablierten Werke zum Management von IT-Architekturen bzw. der IT-Unternehmensarchitektur von DERN166 bzw. von KELLER167. DERN UND KELLER entwickeln darauf aufbauend im Konzept der Vorlesung ein Referenzmodell zur IT-Unter165

Vgl. [DeKe08]. Vgl. [Dern09]. DERN spricht hier von IT-Architekturen. In der vorliegenden Arbeit wird der verallgemeinernde Begriff der Lösungsarchitektur verwendet. 167 Vgl. [Keller07]. 166

164

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

nehmensarchitektur. Dieses Modell wird im Folgenden aufgegriffen und auf die vorliegende Arbeit adaptiert. Grundlage des Konzeptes von DERN UND KELLER bildet die von DERN entwickelte und hier adaptierte Architekturpyramide zur Unternehmensarchitektur, die in der folgenden Abbildung dargestellt ist.

Strateg. Konzeption Geschäftsarchitektur

Informationsarchitektur

Lösungsarchitekturen

Infrastrukturarchitektur

Abbildung 79: Architekturpyramide – Grundmodell zur Unternehmensarchitektur - in Anlehnung an DERN UND KELLER Nach dem in Abschnitt 2.3 für die vorliegende Arbeit definierten Verständnis des Begriffes Unternehmensarchitektur bilden Prinzipien, Standards, Modelle und Muster, welche, ausgehend vom aktuellen Zustand, den zukünftigen Zustand und die Transformation des Unternehmens und seiner Teilsysteme beschreiben, die Artefakte einer Unternehmensarchitektur. Sie fungieren gemäß Abbildung 39 als Leitplanken der Weiterentwicklung des Unternehmens, die zur Kompensation der Veränderung der Unternehmensumwelt erforderlich ist. Dieses Verständnis liegt auf einer Linie mit dem von DERN UND KELLER beschriebenen. DERN UND KELLER nutzen die Ebenen der Architekturpyramide168 zur Klassifikation der für eine Unternehmensarchitektur relevanten Artefakte.169 Für die vorliegende Arbeit wird daraus die folgende Klassifikation abgeleitet: 168 Diese Ebenen beschreiben Sichten auf das Unternehmen. In anderen Arbeiten und Rahmenwerken zur Unternehmensarchitektur wird von Architektur-Viewpoints gesprochen. 169 Eine detaillierte Aufstellung von Modellen, die zur Beschreibung von Unternehmensarchitekturen eingesetzt werden können, findet sich in [Sebis08].

4.2 Definition eines Referenzmodells zur IT-Prozesslandschaft

ƒ

ƒ

ƒ

ƒ

ƒ

165

Ebene Strategie Artefakte zur Beschreibung der strategischen Konzeption des Unternehmens mit den Schwerpunkten Geschäftssicht und IT-Sicht (s. Abbildung 38). Ebene Geschäftsarchitektur Artefakte zur Beschreibung der Grundstruktur des Geschäftes des Unternehmens und seiner Geschäftseinheiten, z.B. in Bezug auf Markt- und Kundensegmente, Produkte, Geschäftsprozesse, Distributionskanäle und Organisationsstrukturen. Ebene Informationsarchitektur Artefakte zur Beschreibung der fundamentalen Struktur der Informationsbewirtschaftung des Unternehmens. Darunter fallen insbesondere übergreifende Modelle zur Beschreibung der Gesamtheit der IT-Systeme einschließlich einzusetzender Integrationslösungen. Ebene Lösungsarchitekturen Artefakte zur Beschreibung von IT-Lösungen, die zur Erfüllung von Leistungsanforderungen an die Unternehmens-IT entwickelt und eingeführt werden. Dies umfasst den Begriff der IT-Architektur, wie er in der vorliegenden Arbeit verwendet wird, und damit auch Architekturen von Integrationslösungen. Ebene Infrastrukturarchitektur Artefakte zur Beschreibung der IT-Basisinfrastruktur (Architektur der ITBasisinfrastruktur).

Gemäß Abbildung 39 fungieren die beschriebenen Artefakte als Leitplanken der Weiterentwicklung des Unternehmens und decken die Ist- und die Sollsicht ab. Artefakte, die die Weiterentwicklung der Unternehmens-IT in den Mittelpunkt stellen, definieren den Ansatz zur IT-Unternehmensarchitektur. Artefakte, die als Leitplanken für die Erbringung von Integrationsleistungen fungieren, bilden die IT-Integrationsarchitektur. DERN UND KELLER stellen der Architekturpyramide das IT-Portfolio gegenüber. Dieses umfasst aus Sicht der Autoren IT-Investitionen, IT-Risiken, ITAssets, insbesondere IT-Systeme170 und IT-Services. Die Autoren verwenden somit ein breites, umfassendes Verständnis des Begriffes IT-Portfolio.

170

Die Verwendung des Begriffs des Informationssystems durch DERN UND KELLER entspricht der Verwendung des Begriffes IT-System in der vorliegenden Arbeit.

166

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

Risiken in der IT

Informationssysteme

IT-Investitionen

InfrastrukturAssets

IT-Assets Ressourcen

IT-Portfolio IT-Services

Abbildung 80: Das IT-Portfolio in Anlehnung an DERN UND KELLER Nach Erfahrung des Autors der vorliegenden Arbeit wird in vielen Unternehmen die IT-Portfoliosteuerung auf IT-Investitionen sowie IT-Betriebs- bzw. IT-Wartungsaufwände fokussiert. Da Investitionen i. d. R. im Rahmen von ITProjekten erfolgen, wird vereinfachend vom IT-Projektportfolio gesprochen. Das IT-Portfoliomanagement umfasst dann typischerweise die Klassifikation von Projekten nach zuvor definierten Projektkategorien171 sowie das Monitoring, die Steuerung und Optimierung des Verhältnisses von IT-Investitionen zu ITBetriebs- und IT-Wartungskosten. Die Zielverteilung wird dabei im Rahmen der IT-Planung definiert. Im Folgenden wird diesem Verständnis gefolgt und von ITProjektportfolio gesprochen. DERN UND KELLER fassen die Architekturpyramide und das IT-Portfolio zur erweiterten Architekturpyramide zusammen. Hier ist anzumerken, dass die Autoren im Widerspruch zum beschriebenen Verständnis das IS- bzw. Anwendungsportfolio auf der Ebene der Informationsarchitektur ansiedeln. Dies ist in der Darstellung der erweiterten Architekturpyramide in Abbildung 81 korrigiert, in der das in Abbildung 80 dargestellte Portfoliomodell vereinfacht übernommen wurde. DERN UND KELLER ordnen den Bausteinen der erweiterten Architekturpyramide Prozesse zu. So gelingt es, die IT-Prozesslandschaft mit dem Ansatz zur Unternehmensarchitektur zu verzahnen. Abbildung 82 interpretiert den Vorschlag von DERN UND KELLER im Kontext der vorliegenden Arbeit; IT-Prozesse sind hervorgehoben.

171

Vgl. dazu [Dern09], S. 314 ff.

167

4.2 Definition eines Referenzmodells zur IT-Prozesslandschaft

Artefakte zur Strategie

Strateg. Konzeption IT–Portfolio

Informationssystem-Portfolio

IT-Projektportfolio

Risiken in der IT

IT-Service-Portfolio

IT-Ressourcen-Portfolio

Geschäftsarchitektur

Informationsarchitektur

Lösungsarchitekturen

Infrastrukturarchitektur

Artefakte zur Geschäftsarchitektur

Artefakte zur InformationsArchitektur

Artefakte zu LösungsArchitekturen

Artefakte zur InfrastrukturArchitektur

Abbildung 81: Erweiterte Architekturpyramide in Anlehnung an DERN UND KELLER GeschäftsstrategieEntwicklung Strategische Geschäftsplanung

IT-ProjektportfolioManagement Risikomanagement in der IT

IS-Portfolio-Management

IT-Strategiedefinition

Strateg. Konzeption

IT–Portfolio

Geschäftsarchitektur

Strategische IT-Planung GeschäftsprozessManagement ProduktManagement

Informationsarchitektur IS-Portfolio

IT-Projektportfolio

IT-Ressourcen-Portfolio

IT-Service-Portfolio

Risiken in der IT

…

IT-ArchitekturManagement

Lösungsarchitekturen

Infrastrukturarchitektur

IT-Service-Management

IT-Ressourcen-PortfolioManagement

Abbildung 82: Erweiterte Architekturpyramide einschließlich Prozesszuordnung

168

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

4.2.4 Synthese des Referenzmodells zur IT-Prozesslandschaft Die Ausführungen zu ASL und das in Abbildung 82 dargestellte Modell werden nun zusammengefasst und ergänzt, um so das geforderte Referenzmodell zur ITProzesslandschaft festzulegen. Abbildung 83 zeigt das Modell; es bildet die Grundlage der Entwicklung der weiterführenden Gestaltungsempfehlungen in den nachfolgenden Abschnitten und weist folgende Merkmale auf: ƒ

ƒ

ƒ

ƒ ƒ

172

Die strategische Ebene wird durch die Prozesse der IT-Strategiedefinition und der strategischen IT-Planung abgedeckt, die zusammen die strategische Konzeption der Unternehmens-IT i. S. des im 2. Kapitel formulierten Verständnisses liefern. Die Prozessgruppe IT-Portfoliomanagement umfasst vier Prozesse, für die jeweils die Teilprozesse Inventur, Monitoring & Bewertung (M & B) sowie Steuerung & Optimierung (S & O) durchgeführt werden. Diese Prozesse orientieren sich an den Management-Objekten des IT-Portfoliomanagements – hier IT-Systeme, Elemente der IT-Basisinfrastruktur172, ITProjekte und IT-Ressourcen. Das IT-Portfoliomanagement wird gegenüber der in Abbildung 80 vorgenommenen Abgrenzung enger gefasst, wodurch der Anwendung von COBIT und in der Praxis ITIL Rechnung getragen wird. Nach Erfahrung des Autors der vorliegenden Arbeit werden ITService-Management und IT-Risikomanagement im Rahmen von COBIT/ ITIL-Implementierungen in Unternehmen i. d. R. als eigenständige Prozesse außerhalb des IT-Portfoliomanagements gesehen. Entsprechend sind diese Prozesse im Referenzmodell positioniert. Auf diese Weise unterstützt das entwickelte Referenzmodell neben der Verzahnung mit ASL-basierten auch die Verzahnung mit ITIL- oder COBIT-basierten Prozessmodellen. Der Prozess des IT-Architekturmanagement, dient gemäß der in Abschnitt 2.3 getroffenen Definition der Abstimmung, der Kommunikation und der Weiterentwicklung der Artefakte der IT-Unternehmensarchitektur und darin eingebetteter Teilarchitekturen, wie z. B. Lösungsarchitekturen. Die Prozessgruppen Betrieb/Wartung, Change Management und Software Control & Distribution entsprechen den Prozessen aus ASL. ASL und ITIL sind in diesem Bereich weitgehend deckungsgleich. Die Prozessgruppe Erweiterung/Erneuerung beschreibt nach ASL Disziplinen der Systementwicklung, wie Anforderungsanalyse, Design, Realisierung, Test oder Produktionsvorbereitung. Nach Erfahrung des Autors der vorliegenden Arbeit ist hier die Zusammenfassung zum SystementwickFür den entsprechenden Prozess wird der Begriff Infrastruktur-Asset-Management verwendet.

169

4.3 Integrationsmanagement in der strategischen Konzeption

lungsprozess gängige Praxis in größeren Unternehmen. Der Systementwicklungsprozess wird bei der Durchführung von IT-Projekten und bei der Wartung/ Weiterentwicklung der IT-Landschaft außerhalb von IT-Projekten angewandt. Es ergeben sich in der Prozessgruppe Erweiterung/Erneuerung zwei weitere Prozesse: die IT-Projektdurchführung und die Wartung/Weiterentwicklung außerhalb von IT-Projekten.173 Die o. a. in ASL bestehende Lücke in Bezug auf die Durchführung von IT-Projekten wird auf diese Weise geschlossen. Darüber hinaus wird das Referenzmodell durch die Prozessgruppe der Wartung/Weiterentwicklung vervollständigt.

Strategische Ebene

IT-Strategiedefinition

Strategische Konzeption der Unternehmens-IT

Strategische IT-Planung

IT-Portfoliomanagement

ManagementEbene

IT-ProjektportfolioManagement

IT-RessourcenPortfolio-Mgmnt

IS-PortfolioManagement

Infrastruktur-AssetManagement

Inventur

Operative Ebene

M&B

Betrieb

IT-ServiceManagement

IT-ArchitekturManagement

IT-KostenManagement

IT-Risiko-Management

Management von IT-Org. & IT-Landschaft

S&O

ChangeManagement

Erweiterung/Erneuerung IT-ProjektDurchführung

IT-ProjektIncident-Management, Durchführung etc. Software Control & Distribution

Wartung / Weiterentwicklung

Systementwicklungsprozess

S & O = Steuerung & Optimierung

Betrieb & WeiterEntwicklung IT-Landschaft

M & B = Monitoring & Bewertung

Abbildung 83: Referenzmodell zur IT-Prozesslandschaft

4.3 Integrationsmanagement in der strategischen Konzeption der Unternehmens-IT Auf Basis des Referenzmodells zur IT-Prozesslandschaft wird in diesem Abschnitt zunächst ein Modell zur strategischen Konzeption der Unternehmens-IT erarbeitet. Davon ausgehend wird die Einbettung des Integrationsmanagements in die strategische Konzeption der Unternehmens-IT beschrieben.

173

Hier ist z. B. die Beseitigung von in der Produktion auftretenden Fehlern in IT-Systemen angesiedelt.

170

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

4.3.1 Definition eines Modells zur strategischen IT-Planung Ausgangspunkt der Modelldefinition bildet die Arbeit Architekturmanagement174 von DERN. Der Autor entwickelt unter Bezugnahme auf das Werk Strategic Planning for Information Systems175 von WARD UND PEPPARD ein Modell zur IT-Strategiedefinition und zur strategischen IT-Planung. DERN UND KELLER vervollständigen dieses Modell innerhalb des im vorangehenden Abschnitt aufgeführten Konzeptes. Wie in Abschnitt 2.3 ausgeführt, beruht der Ansatz von WARD UND PEPPARD auf dem EWIM-Ansatz. Das Modell von DERN UND KELLER wird nun aufgegriffen und im Rahmen des in 2.3 entwickelten transformierten EWIM-Ansatzes (s. Abbildung 37) verfeinert. Auf diese Weise ergibt sich ein konkretes Modell zur Ausgestaltung des transformierten EWIM-Ansatzes. Definition - Prozess der strategischen IT-Planung Der Prozess der strategischen IT-Planung ist die systematische Aufstellung eines IT-Plans zur Weiterentwicklung der Unternehmens-IT für einen definierten Planungshorizont auf der Grundlage einer aus den Geschäftszielen und den Geschäftsplänen des Unternehmens und seiner Geschäftseinheiten abgeleiteten Zielsituation für die IT-Landschaft. Dabei steht die Frage im Vordergrund, welche Leistungsmerkmale die IT-Landschaft bereitstellen muss, um die Lebensfähigkeit des Unternehmens in seiner Systemumwelt sicherzustellen, und welche unternehmensexternen Trends – sowohl auf Geschäfts- als auch auf IT-Seite – Berücksichtigung finden sollen. Der IT-Plan beantwortet als Output der strategischen IT-Planung für den definierten Planungszeitraum folgende Fragestellungen: ƒ ƒ

174

Welche strategischen Handlungsfelder der Unternehmens-IT werden aus der Geschäftsstrategie und der antizipierten Entwicklung der Systemumwelt abgeleitet? Welche Ziel-IT-Landschaft wird angestrebt?176 o Welches sind die für die Erhaltung und Weiterentwicklung der Leistungsfähigkeit (i. S. der definierten Handlungsfelder) des Unternehmens essenziellen IT-Systeme und IuK-Technologien?

Vgl. [Dern07]. Vgl. [WaPe02]. Die Ziel-IT-Landschaft ist Bestandteil der IT-Unternehmensarchitektur. Entsprechend besteht eine Schnittstelle zum Prozess IT-Architekturmanagement. 175 176

4.3 Integrationsmanagement in der strategischen Konzeption

171

Welche Systeme und Technologien werden eingesetzt, welche sollen auf- bzw. ausgebaut werden? o Wie soll die funktionale und strukturelle Qualität der IT-Assets im Rahmen der Weiterentwicklung der IT-Landschaft verändert werden? Wie werden im Rahmen der Weiterentwicklung der Unternehmens-IT auf Basis des definierten IT-Governance-Ansatzes Entscheidungen herbeigeführt? Welche übergeordneten Prinzipien, Standards, Modelle und Muster sollen bei der Weiterentwicklung der Unternehmens-IT gelten?177 Wie ist die IT-Organisation zu positionieren und weiterzuentwickeln, um als Dienstleister der Anwenderorganisation das Management der ITLandschaft zu übernehmen? 178 Was sind die strategischen Maßnahmen, die im Planungszeitraum zur Weiterentwicklung der Unternehmens-IT durchgeführt werden sollen?179 Welche Investitionsstrategie gilt, und welche Finanzplanung ergibt sich daraus für die Unternehmens-IT?180 Welche Ressourcen werden benötigt, und welche Struktur soll das Ressourcen-Portfolio aufweisen? Welche Leistungen sollen von innerhalb und von außerhalb des Unternehmens bezogen werden?181 Nach welchem Kennzahlensystem soll die Steuerung der Unternehmens-IT durchgeführt werden, und welche Werte werden für die Kennzahlen angestrebt? o

ƒ ƒ ƒ ƒ ƒ ƒ ƒ

4.3.2 Aufstellung eines Modells zur IT-Strategiedefinition Liefert die strategische IT-Planung den IT-Plan für einen definierten Planungshorizont, so liefert der Prozess der IT-Strategiedefinition nach DERN UND KELLER die IT-Strategie im Sinne von fundamentalen Aussagen zur Ausrichtung der Unternehmens-IT auf Basis der Geschäftsstrategie des Unternehmens und seiner Einheiten. Der Prozess der IT-Strategiedefinition definiert somit das allgemein verbindliche Fundament für die im IT-Plan angesprochenen Bereiche.

177 Bestandteil der IT-Unternehmensarchitektur; es besteht eine Schnittstelle zum Prozess ITArchitekturmanagement. 178 Schnittstelle zum Prozess IT-Service-Management. 179 Schnittstelle zum Prozess IT-Projektportfolio-Management. 180 Schnittstelle zum Prozess IT-Kosten-Management. 181 Schnittstelle zum Prozess Ressourcen-Portfoliomanagement.

172

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

Definition - Prozess der IT-Strategiedefinition Der Prozess der IT-Strategiedefinition ist die systematische Aufstellung von Kernaussagen zur Ausrichtung der Unternehmens-IT eines Unternehmens. Bestandteil der so erzeugten IT-Strategie sind Kernaussagen in folgenden Bereichen: ƒ Rolle der IT-Funktion und deren Ausübung durch die Unternehmens-IT inklusive ihrer Teilsysteme IT-Organisation und ITLandschaft. Daraus ergibt sich erstens der IT-Governance-Ansatz, d. h. die Art und Weise, wie die Unternehmens-IT gesteuert und organisiert wird, sodass sichergestellt ist, dass sie die Unternehmensstrategie und -ziele unterstützt182, und zweitens der Corporate-Funding-Ansatz, also die Art und Weise, wie die Unternehmens-IT finanziert wird und wie Ressourcen allokiert werden. ƒ IS-Strategie (IT-Systemstrategie), d. h. die Art und Weise, wie IT-Systeme zum Erhalt und zur Weiterentwicklung der Leistungsfähigkeit (Performance) des Unternehmens in seiner Systemumwelt beitragen. Ausgangspunkt ist die Rolle der ITFunktion. ƒ Technologie-Strategie, d. h. die Art und Weise, wie IuK-Technologien eingesetzt werden, um den Erhalt und die Weiterentwicklung der Leistungsfähigkeit des Unternehmens sicherzustellen und die IS-Strategie umzusetzen. ƒ Sourcing-Strategie, d. h. die Art und Weise, wie Leistungen im Rahmen der Leistungserbringung durch die Unternehmens-IT von innerhalb und außerhalb des Unternehmens bezogen und eingesetzt werden sollen. Die folgende Abbildung fasst das Modell zur IT-Strategiedefinition und zur strategischen IT-Planung zusammen. Nach diesem Modell formuliert die ITStrategie Grundaussagen zur Unternehmens-IT. Der IT-Plan beantwortet die Frage, wie die Vorgaben der IT-Strategie innerhalb des definierten Planungszeitraumes operationalisiert werden sollen.

182

Definition in Anlehnung an die Definition des IT Governance Institute (ITGI); www.itgi.org.

173

4.3 Integrationsmanagement in der strategischen Konzeption

IT-Strategiedefinition IT-Strategie – Fundamentale Ausrichtung der Unternehmens-IT

Strategische IT-Planung IT-Plan – Operationalisierung IT-Strategie

Rolle der IT-Funktion

IT-Unternehmensarchitektur Ziel-IT-Landschaft Umsetzung des IT-Governance-Ansatzes IT-Unternehmensarchitektur Prinzipien, Leitlinien, Standards Positionierung IT-Organisation als Dienstleister

IT-Governance-Ansatz IT-Funding-Ansatz Technologie-Strategie

Strategische Handlungsfelder

Strategische Konzeption der Unternehmens-IT

Strategische Maßnahmen IS-Strategie Sourcing-Strategie

Investitionsstrategie und Finanzplanung Ressourcen-Planung Kennzahlen zur Steuerung der Unternehmens-IT

Abbildung 84: Modell zur strategischen Konzeption der Unternehmens-IT Auf der Basis des in Abbildung 84 dargestellten Modells wird nun beschrieben, wie das Integrationsmanagement in der strategischen Konzeption der Unternehmens-IT verankert werden kann. Die in Abbildung 74 zusammengefasste Aufgabenstellung verlangt dabei die Berücksichtigung der Leistungsfähigkeit der IT-Organisation in Bezug auf die Erbringung von Integrationsleistungen und das Komplexitätsmanagement. 4.3.3 IT-Strategiedefinition und IT-Integrationsstrategie Zur Verankerung des Integrationsmanagements in der IT-Strategie wird vorgeschlagen, vier der im Modell zur IT-Strategiedefinition enthaltenen Kernaussagen zu ergänzen. Ergänzung der Kernaussage zur Rolle der IT-Funktion Die Beschreibung der Rolle der IT-Funktion definiert den Anspruch, mit dem das Unternehmen die IT-Funktion ausübt, und welchen Beitrag die Unternehmens-IT im Rahmen der Positionierung des Unternehmens leistet. Dieser Anspruch ist um Aspekte des Integrationsmanagements zu ergänzen, insbesondere im Hinblick auf die Leistungsfähigkeit der IT-Organisation bei der Erbringung von Integrationsleistungen.

174

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

Hier ist beispielsweise auch der Anspruch formuliert, mit dem die Unternehmens-IT eines Unternehmens zukünftige Unternehmensübernahmen antizipiert, sodass damit verbundene Integrationsaufwände verringert werden. Wie in Abschnitt 3.2.1.2 gezeigt, ist ganzheitliches Integrationsmanagement mit der Forderung verbunden, Veränderungen der Komplexität der Unternehmens-IT so zu steuern, dass das für die Lebensfähigkeit notwendige statische und dynamische Potenzial gewährleistet ist. Auch hier handelt es sich um eine fundamentale Aussage zur IT-Funktion des Unternehmens, die die Kernaussage zur Rolle der Unternehmens-IT in der IT-Strategie ergänzt. Ergänzung der Kernaussage zum IT-Governance-Ansatz Werden die Zielsetzung des Integrationsmanagements und die Bedeutung des Komplexitätsmanagements, wie beschrieben, in der Kernaussage zur Rolle der Unternehmens-IT ergänzt, so ergibt sich die Frage, ob und wie diese Aspekte bei der Steuerung der Unternehmens-IT Berücksichtigung finden sollen. Nach dem oben festgelegten Verständnis ist dies Teil der Kernaussage zum IT-GovernanceAnsatz, die innerhalb des jeweiligen Unternehmenskontextes entsprechend erweitert wird. Ergänzung der IS-Strategie Die IS-Strategie definiert innerhalb des für die IT-Funktion festgelegten Rollenverständnisses, wie IT-Systeme zum Erhalt und zur Weiterentwicklung der Leistungsfähigkeit (Performance) des Unternehmens in seiner Umwelt beitragen. Ganzheitliche Integrationslösungen sind nach dem Verständnis der vorliegenden Arbeit IT-Systeme. Die IS-Strategie ist hier um den Beitrag ganzheitlicher Integrationslösungen, wie etwa ein Data Warehouse zur Unternehmenssteuerung, zu ergänzen. Ergänzung der Technologiestrategie Die Technologie-Strategie definiert, wie IuK-Technologien zum Erhalt und zur Weiterentwicklung der Leistungsfähigkeit des Unternehmens und zur Umsetzung der IS-Strategie eingesetzt werden sollen. Die Technologiestrategie ist hier um den Beitrag von Integrationstechnologien, wie etwa ein Enterprise Service Bus (ESB), zu ergänzen. Aus diesen Überlegungen zur Ergänzung der IT-Strategie ergibt sich die folgende Definition:

175

4.3 Integrationsmanagement in der strategischen Konzeption

Definition - IT-Integrationsstrategie In der IT-Strategie enthaltene Kernaussagen zum Integrationsmanagement der Unternehmens-IT, die sich auf die Rolle der IT-Funktion und deren Detaillierung innerhalb der IS-Strategie, des IT-GovernanceAnsatzes sowie der Technologiestrategie beziehen, werden im Folgenden als IT-Integrationsstrategie des Unternehmens bezeichnet. Die folgende Abbildung fasst die vorgeschlagene Erweiterung des Modells zur IT-Strategie um die IT-Integrationsstrategie zusammen. IT-Strategie

IT-Plan IT-Integrationsstrategie

Rolle der IT-Funktion

=

Anspruch der Ausübung der ITFunktion durch die Unternehmens-IT?

Ergänzung um Aspekte des Integrationsmanagements

IT-Governance-Ansatz

=

Art und Weise der Steuerung & Organisation der Unternehmens-IT?

Ergänzung um Aspekte des Integrationsmanagements

IS-Strategie

=

Beitrag IT-Systeme zur Unternehmensperformance?

Ergänzung um Aspekte des Integrationsmanagements

Technologie-Strategie

=

Beitrag IuK-Technologien zur Unternehmensperformance ?

Ergänzung um Aspekte des Integrationsmanagements

Corporate-FundingAnsatz Sourcing-Strategie

Abbildung 85: IT-Integrationsstrategie als Teil der IT-Strategie 4.3.4 Integrationsmanagement in der strategischen IT-Planung Wird die IT-Strategie in der beschriebenen Weise um die IT-Integrationsstrategie ergänzt, so folgt daraus, dass der strategische IT-Plan ebenfalls entsprechend zu ergänzen ist, um die IT-Integrationsstrategie für den festgelegten Planungszeitraum zu operationalisieren. Dies bedeutet, dass in Abbildung 84 dargestellte Artefakte des IT-Plans im jeweiligen Unternehmenskontext zu ergänzen sind. Hervorzuheben sind hier strategische Handlungsfelder, die Positionierung der IT-Organisation als IT-Dienstleister, die damit verbundene Ressourcenplanung sowie Kennzahlen zur Steuerung der Unternehmens-IT.

176

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

Strategische Handlungsfelder DERN UND KELLER definieren strategische Handlungsfelder der UnternehmensIT als inhaltlich zusammengehörende Bündel strategischer Bedarfe der Geschäftseinheiten und der Steuerungseinheiten eines Unternehmens. Als Beispiel führen die Autoren Handlungsfelder wie Optimierung Kreditbearbeitungsprozesse oder Konsolidierung Banksteuerungsplattform eines Kreditinstituts an. Diesem Verständnis wird hier gefolgt. In Abschnitt 3.2.2 wurde das Konzept der ganzheitlichen Integrationslösung entwickelt. Als Ausgangspunkt der Definition ganzheitlicher Integrationslösungen wird das Artefakt der Geschäftsintegrationsanforderung (BIR) als aus Geschäftsanforderungen abgeleitete Integrationsanforderung definiert. Geschäftsintegrationsanforderungen sollen durch die Integration von IT-Systemen erfüllt werden. Eine ganzheitliche Integrationslösung ist auf die Erfüllung dieser auf der Geschäftsebene begründeten Integrationsbedarfe ausgerichtet und wird durch Artefakte der IT-Unternehmensarchitektur standardisiert. Wird dieses Verständnis auf die strategische Ebene transferiert, so sind strategische Geschäftsintegrationsanforderungen solche, die aus dem strategischen Bedarf der Geschäftseinheiten abgeleitet sind. Werden diese strategischen Geschäftsintegrationsanforderungen gebündelt, dann liegt im Sinne der getroffenen Definition ein strategisches Handlungsfeld vor, das die Entwicklung von Integrationslösungen im ITPlan verankert und so begründet. Neben solchen, auf die Entwicklung von Integrationslösungen ausgerichteten Handlungsfeldern können aus der IT-Integrationsstrategie weitere Handlungsfelder für den Planungszeitraum hergeleitet werden. Exemplarisch sind hier Handlungsfelder wie die Steigerung der Leistungsfähigkeit der IT-Organisation in Bezug auf die Erbringung von Integrationsleistungen, die Begrenzung der Komplexität der IT-Landschaft oder der Aufbau eines aktiven Komplexitätsmanagements zu nennen. Es ergeben sich zwei Wege zur Berücksichtigung des Integrationsmanagements bei der Definition der Handlungsfelder: ƒ ƒ

Bündelung von strategischen Geschäftsintegrationsanforderungen, die aus dem strategischen Bedarf hergeleitet sind Ableitung aus der IT-Integrationsstrategie

Die beschriebene Herleitung von Handlungsfeldern mit Bezug zum Integrationsmanagement ist im folgenden Modell zusammengefasst.

177

4.3 Integrationsmanagement in der strategischen Konzeption

Anforderungen und Trends der Unternehmensumwelt

Geschäftseinheiten

Trends der IuKTechnologien

strategische BIR strategischer Bedarf

Handlungsfeld 1

Handlungsfeld 2

Handlungsfeld 3

Handlungsfeld …

IT-Strategie IT-Integrationsstrategie

Strategische Handlungsfelder der Unternehmens-IT Trends der IuKTechnologien

Abbildung 86: Integrationsmanagement und Herleitung von Handlungsfeldern der Unternehmens-IT Positionierung der IT-Organisation und Ressourcenplanung Die Positionierung der IT-Organisation beschreibt auf Basis der definierten Handlungsfelder und der angestrebten Ziel-IT-Landschaft, wie sich die ITOrganisation für die Anwenderorganisation als Manager der IT-Landschaft im Planungszeitraum aufstellt, welchem Service-Management-Ansatz sie dabei folgt und welche Leistungen die IT-Organisation als ihre Kernkompetenz betrachtet. Hieraus wird die Ressourcenplanung der IT-Organisation abgeleitet. Diese Positionierung und die Ressourcenplanung sind auf Basis des oben beschriebenen Ableitungsprozesses von Handlungsfeldern zum Integrationsmanagement zu ergänzen. Dies bedeutet z. B., dass die Kernkompetenzen der IT-Organisation in Bezug auf die Erbringung von Integrationsleistungen definiert werden und, davon ausgehend, die Ressourcenplanung der IT-Organisation vervollständigt wird. Integrationsmanagement im Kennzahlensystem der Unternehmens-IT Nach dem Management-Grundsatz, dass effektive Steuerung entsprechende Kennzahlen zur Messung voraussetzt, sollte die strategische IT-Planung die Festlegung eines Systems von Kennzahlen umfassen – zum Beispiel in Form einer Balanced Scorecard –, mit dessen Hilfe der Zustand der Unternehmens-IT

178

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

gemessen, bewertet und die Weiterentwicklung der Unternehmens-IT gesteuert wird. Aus der IT-Integrationsstrategie und den Handlungsfeldern des jeweiligen Unternehmens ergibt sich, welche Kennzahlen zur Ergänzung der Steuerung der Unternehmens-IT aus Sicht eines zu verankernden Integrationsmanagements benötigt werden. Unabhängig vom jeweiligen Unternehmenskontext werden für folgende Aspekte gemäß des in Abschnitt 4.1 definierten Verfeinerungsbedarfs Kennzahlen benötigt: ƒ ƒ ƒ ƒ

Integrationsleistungen der IT-Organisation im Verhältnis zu Leistungen für die Umsetzung fachlicher Anforderungen (Aufwandsquotient) Komplexität der Unternehmens-IT Effizienz der IT-Organisation bei der Erbringung von Integrationsleistungen Reaktionsfähigkeit der Unternehmens-IT - statisches und dynamisches Potenzial

Die folgende Abbildung zeigt das Modell eines um Aspekte des Integrationsmanagements erweiterten Kennzahlensystems zur Steuerung der Unternehmens-IT. Es ist gemäß der im jeweiligen Unternehmenskontext gültigen IT-Integrationsstrategie zu adaptieren. Kennzahlensystem im strategischen IT-Plan Kennzahlen in anderen Bereichen

Erweiterung für Integrationsmanagement Integrationseffizienz der ITOrganisation

Komplexität der Unternehmens-IT

Aufwandsquotient der IT-Organisation

Reaktionsfähigkeit der Unternehmens-IT

Abbildung 87: Kennzahlen zum Integrationsmanagement im strategischen ITPlan Abgrenzung und Ansatzpunkte für ergänzende Forschungsaktivitäten – Messung der Reaktionsfähigkeit der Unternehmens-IT Überlegungen zu Kennzahlen zum dynamischen und statischen Potenzial der Unternehmens-IT werden im Rahmen der vorliegenden Arbeit auf deren Einbettung in die IT-Prozesslandschaft beschränkt. Die Aufstellung von Kennzahlen zur Reaktionsfähigkeit der Unternehmens-IT,

179

4.3 Integrationsmanagement in der strategischen Konzeption

d. h. zum dynamischen und zum statischen Potenzial der Unternehmens-IT, wird als weiterführender Forschungsbedarf eingeordnet. 4.3.5 Zusammenfassung Aus den vorgeschlagenen Erweiterungen der strategischen Konzeption der Unternehmens-IT ergibt sich das in Abbildung 88 dargestellte Modell. Es zeigt, welche Artefakte des der Arbeit zugrunde liegenden Modells zur ITStrategiedefinition bzw. zur strategischen IT-Planung zu ergänzen sind, um Integrationsmanagement in der strategischen Konzeption der Unternehmens-IT zu verankern. Vor dem Hintergrund dieses Modells wird im folgenden Abschnitt ein Kennzahlensystem zum Integrationsmanagement entworfen. Im darauf folgenden Abschnitt wird dann die Verankerung des Integrationsmanagements in der IT-Prozesslandschaft vervollständigt, indem die Managementebene und die operativen Ebene in den Mittelpunkt gestellt werden. Anforderungen & Trends der Umwelt

Geschäftseinheiten

Anforderungen & Trends der Umwelt

strategischer Bedarf

strategische BIR Strategische Handlungsfelder der Unternehmens-IT

IT-Strategie IT-IntegrationsStrategie

Trends der IuKTechnologien

Kennzahlensystem zur Steuerung der Unternehmens-IT

Positionierung IT-Organisation gegenüber Anwenderorganisation

Integrationseffizienz der ITOrganisation

Service-ManagementAnsatz?

Komplexität der U-IT Reaktionsfähigkeit der U-IT Aufwandsquotient der ITOrganisation

andere

Ziel-IT-Landschaft (Teil der IT-Unternehmensarchitektur)

Umsetzung des IT-Governance-Ansatzes

Kernkompetenzen?

Investitionsstrategie und Finanzplanung Kernkompetenzen bzgl. Integrationsleistungen?

Übergeordnete Prinzipien, Leitlinien, Standards Ressourcen-Planung

(Teil der IT-Unternehmensarchitektur)

Ressourcen für Integrationsleistungen?

Strategische Maßnahmen

Strategischer IT-Plan

Abbildung 88: Modell der Einbettung des Integrationsmanagements in die strategische Konzeption der Unternehmens-IT

180

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

4.4 Entwurf eines Kennzahlensystems zum Integrationsmanagement Nach DURST183 erfasst eine Kennzahl einen Sachverhalt in qualitativer, konzentrierter Form mit dem Ziel, den Zustand eines Systems zu beschreiben. Häufig genügt eine einzelne, eindimensionale Kennzahl nicht, um einen Sachverhalt ausreichend genau zu erfassen. Um dem zu begegnen, werden Kennzahlensysteme geschaffen, die sachlogisch miteinander im Zusammenhang stehen. Die Überlegungen des vorangehenden Abschnittes zur Erweiterung des Kennzahlensystems der Unternehmens-IT in Bezug auf ein Integrationsmanagement werden nun durch den Entwurf eines Kennzahlensystems untermauert. Der Schwerpunkt des Kennzahlensystems liegt auf der Komplexität der Unternehmens-IT. 4.4.1 Komplexität der IT-Landschaft In seinem Aufsatz Software Measurement: A Necessary Scientific Basis184 diskutiert FENTON Softwaremetriken aus Sicht der Messtheorie. Messtheorie definiert Messen als das Zuordnen von Symbolen oder Zahlen zu Attributen von Entitäten der realen Welt zum Zwecke der Beschreibung dieser Entitäten nach klar definierten Regeln. Ein wesentlicher Aspekt ist hier die Unterscheidung von direkter und indirekter Messung. Direkte Messung liegt vor, wenn die Messung eines Attributes unabhängig von der Messung andrer Attribute ist, andernfalls wird von indirekter Messung gesprochen. Ausgehend von den Anforderungen, denen Softwaremetriken nach den Regeln der Messtheorie genügen müssen, stellt FENTON die Komplexität von Software in den Mittelpunkt seiner Betrachtung. FENTON beweist, dass keine reelle, eindimensionale Messgröße existiert, mit der die Komplexität von Software direkt und vollständig erfasst werden kann, sondern dass es nur möglich ist, Softwarekomplexität indirekt zu messen, d. h. mit Hilfe der Messung mehrerer Attribute bestimmte Aspekte der Komplexität zu erfassen.185 Da die Komplexität von IT-Systemen in die Komplexität der IT-Landschaft eingeht, folgt, dass es keine eindimensionale, reelle Messgröße zur vollständigen Messung der Komplexität der IT-Landschaft und damit der Unternehmens-IT gibt, solche Messgrößen jeweils nur Teilaspekte der Komplexität erfassen können und die Messung der Komplexität der IT-Landschaft daher nur indirekt möglich ist. Die im Folgenden entwickelten Kennzahlen unterliegen folglich der Einschränkung, dass sie bestimmte Aspekte der Komplexität der 183

Vgl. [Durst07], S. 129. Vgl. [Fent94]. Der Beweis beruht darauf, zu zeigen, dass es nicht möglich ist, eine reelle Größe zu definieren, mit der die Komplexität des Kontrollflusses von Software vollständig gemessen werden kann. 184 185

4.4 Entwurf eines Kennzahlensystems zum Integrationsmanagement

181

Unternehmens-IT erfassen, ohne jedoch die Komplexität vollständig messen zu können. Auf Basis des Verständnisses der vorliegenden Arbeit besteht die Unternehmens-IT aus den Teilsystemen IT-Landschaft und IT-Organisation. Daraus ergibt sich der Ansatz, die Messung der Komplexität der Unternehmens-IT durch die Messung der Komplexität dieser Teilsysteme durchzuführen. Im Folgenden wird mit dem KITL die Gesamtkomplexität der IT-Landschaft bezeichnet, mit KITO die der IT-Organisation. Es folgt:186 KUIT (t) = Gesamtkomplexität der Unternehmens-IT zum Zeitpunkt t = ( KITL(t), KITO(t) ) Formel 3:

KUIT – Gesamtkomplexität der Unternehmens-IT

Abgrenzung und Ansatzpunkte für ergänzende Forschungsaktivitäten – Komplexität der IT-Organisation Die Komplexität der IT-Organisation steht nicht im Fokus der weiteren Ausarbeitung. Die Entwicklung von Kennzahlen zur Komplexität der IT-Organisation wird als weiterführender Forschungsbedarf eingeordnet. 4.4.1.1 Perspektiven der Komplexitätsbetrachtung Im Rahmen der zuvor beschriebenen, aus dem Aufsatz von FENTON abgeleiteten Einschränkungen werden nun wesentliche Merkmale der Komplexität der ITLandschaft beleuchtet und als Ausgangspunkt der Aufstellung des Kennzahlensystems festgelegt. In Abschnitt 3.2.1.2 wird Komplexität als strukturelle Vielschichtigkeit eines Systems definiert, die sich zum einen aus der Anzahl und der Vielfalt seiner Systemelemente sowie deren Interaktionsbeziehungen und zum anderen aus der Dynamik der Veränderungen der Systemelemente und ihrer Interaktionsbeziehungen ergibt. Wird diese Definition zugrunde gelegt, so manifestiert sich nach dem im 2. Kapitel definierten systemtheoretischen Verständnis der Unternehmens-IT und der in Abschnitt 3.2.1.2 getroffenen Definition die Komplexität der IT-Landschaft als Vielfalt, Anzahl und Veränderungsdynamik

186 In der weiteren Ausarbeitung wird auf die Darstellung der Variablen t verzichtet. Die Dynamik der Veränderung der IT-Landschaft kann mithilfe der im Folgenden beschriebenen Kennzahlen und deren Bestimmung am Ende bzw. am Anfang einer Periode erfasst werden. Dies wird im Folgenden nicht explizit ausgewiesen.

182 ƒ ƒ ƒ ƒ

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

der durch die IT-Landschaft unterstützen Informationstransformationsaufgaben, der diese Aufgaben durchführenden IT-Systeme, der Informationsbeziehungen dieser IT-Systeme, der die IT-Systeme tragenden Elemente der IT-Basisinfrastruktur.

In diesem Abschnitt aufgestellte Kennzahlen zur Messung der Komplexität der IT-Landschaft beruhen auf dieser Klassifikation. Für die vorliegende Arbeit ergibt sich daher das in der folgenden Abbildung dargestellte Modell.187 Komplexität der IT-Landschaft = Strukturelle Vielschichtigkeit

Anzahl BetrachtungszeitraumVielfalt

Quantifizierung

Dynamik der Veränderung

InformationsTransformationsaufgaben

IT-Basisinfrastruktur

IT-Systeme

Informationsbeziehungen

Klassifizierung der Systemelemente

Abbildung 89: Faktoren der Komplexität der IT-Landschaft Da die im Folgenden definierten Kennzahlen auf diesen Faktoren beruhen, stellt sich die Größe KITL zur Gesamtkomplexität der IT-Landschaft als mehrdimensionale Größe dar. Wesentlich für die Erfassung der Gesamtkomplexität KITL ist die Berücksichtigung der immanenten Komplexität der IT-Systeme, da diese aus Systemelementen wie z. B. Programmmodulen bestehen und daher zur Gesamtkomplexität beitragen. Vier Perspektiven werden, diesem Modell folgend, bei der Kennzahldefinition berücksichtigt: ƒ

ƒ 187

Perspektive 1 - Gesamtheit der IT-Systeme Diese Perspektive stellt die Betrachtung der IT-Landschaft im Sinne eines Netzes aus IT-Systemen und Informationsbeziehungen (Knoten und Kanten) in den Vordergrund – es gehen ein: o Anzahl, Vielfalt und Änderungsdynamik der IT-Systeme o Anzahl, Vielfalt und Änderungsdynamik der Informationsbeziehungen von IT-Systemen Perspektive 2 – IT-Basisinfrastruktur

Teil-IT-Landschaften sind Teilsysteme des Systeme IT-Landschaft. Deshalb können die im Folgenden entwickelten Kennzahlen grundsätzlich auch auf Teil-IT-Landschaften angewandt werden.

4.4 Entwurf eines Kennzahlensystems zum Integrationsmanagement

ƒ

ƒ

183

Diese Perspektive stellt das den IT-Systemen zugrunde liegende Teilsystem IT-Basisinfrastruktur in den Mittelpunkt. Es gehen ein: o Anzahl, Vielfalt und Änderungsdynamik der Elemente der IT-Basisinfrastruktur Perspektive 3 – Einzelsysteme188 Diese Perspektive stellt die den einzelnen IT-Systemen immanente Komplexität in den Mittelpunkt. HEINDL189 spricht hier von inhärenter Komplexität. In die Kennzahlendefinition gehen ein: o Komplexität je IT-System auf Basis der Bewertung der Anzahl, Vielfalt und Änderungsdynamik der enthaltenen Systemelemente wie Module, Datenbanken usw. Perspektive 4 – Informationstransformationsaufgaben und wahrgenommene geschäftliche Komplexität Nach dem systemtheoretischen Verständnis der vorliegenden Arbeit tragen die Anzahl, Vielfalt und Änderungsdynamik der durch die UnternehmensIT zu erbringenden Informationstransformationsaufgaben zur Komplexität der IT-Landschaft bei. Informationstransformationsaufgaben repräsentierten die durch die IT-Landschaft im Rahmen der Geschäftsprozessdurchführung zu erfüllenden Leistungsanforderungen. In den zu unterstützenden Transformationsaufgaben manifestiert sich aus Sicht der Unternehmens-IT die Komplexität der Leistungsanforderungen der Anwenderorganisation. Gemäß der in Abschnitt 3.2.1 analysierten und in Abbildung 49 zusammengefassten Korrelationen handelt es sich hier um die wahrgenommene Komplexität des Marktes der Unternehmens-IT, d. h. der Geschäftsseite. Die wahrgenommene Komplexität ist nach 3.2.1 positiv mit der Komplexität des Leistungskataloges der Unternehmens-IT korreliert, welche selbst positiv mit der autonomen Komplexität der IT-Landschaft korreliert. Diese autonome Komplexität wird durch die Perspektiven 1 - 3 adressiert.

Wird im Folgenden von der Komplexität der Geschäftsseite bzw. der geschäftlichen Komplexität gesprochen, bezieht sich dies auf die in Perspektive 4 adressierte, durch die IT-Organisation wahrgenommene Komplexität. 188 Die Erfassung der Komplexität einzelner IT-Systeme ist essenziell für die Bestimmung der Gesamtkomplexität der IT-Landschaft, da sich, wie in Abschnitt 3.2.1.2 diskutiert, die Komplexität eines Systems aus der Menge der Zustände ergibt, die es einnehmen kann. Die Menge der Zustände des Gesamtsystems IT-Landschaft wird wesentlich durch die Menge der Zustände der enthaltenen IT-Systeme und ihrer Kombination auf Grund der Interaktionsbeziehungen dieser Systeme untereinander bestimmt. 189 Vgl. [Heindl10].

184

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

Ein weiterer Aspekt der Komplexitätsbetrachtung der IT-Landschaft ergibt sich aus der Frage nach der Komplexität der bei Planung, Steuerung, Weiterentwicklung und Betrieb der IT-Landschaft durchgeführten Prozesse, angewandten Verfahren und Vorgehensweisen sowie der zugehörigen Aufbauorganisation. Diese Komplexität wird im Rahmen der vorliegenden Arbeit nur in Form des unten definierten Artefakts des Anwendungstypen berücksichtigt. Darüber hinausgehende Betrachtungen werden gemäß dem entwickelten Modell der Unternehmens-IT als Teil der Komplexität der IT-Organisation eingeordnet. Sie gehen daher nicht in die Komplexitätsbetrachtung der IT-Landschaft ein. Inhalt der weiteren Analyse dieses Abschnittes ist die Entwicklung eines Vorschlages zur Kennzahl KITL zur Komplexität der IT-Landschaft, der die o. a. Perspektiven einbezieht. Die folgende Abbildung hebt in der Darstellung der ITLandschaft aus Abbildung 90 diejenigen Elemente hervor, die gemäß den oben festgelegten Perspektiven 1-4 in die Größe KITL eingehen.

Aufgabe

…

Aufgabe

Aufgabe

(teilautomatisiert)

(nicht automatisiert)

IS Aufgabenträger

IS

…

…

Aufgabe (voll auto-

Info

…

Person

IT-Basisinfrastruktur

Aufgabe (nicht automatisiert)

Person

IS

IS

…

… IS

BS BS

BS

(teilautomatisiert)

matisiert)

IS

Person

Aufgabe

…

(voll automatisiert)

Aufgaben

Person

BS

BS

BS

BS

BS

BS

BS

Abbildung 90: Gesamtkomplexität der IT-Landschaft und berücksichtigte Systemelemente

4.4 Entwurf eines Kennzahlensystems zum Integrationsmanagement

185

Abgrenzung und Ansatzpunkte für ergänzende Forschungsaktivitäten – Wechselwirkungen zwischen KITL und KITO Betrachtet man die Komplexität einer IT-Landschaft zu einem bestimmten Zeitpunkt, so bedeutet eine Komplexitätssteigerung, dass entweder die geschäftliche Komplexität steigt und aufgrund der positiven Korrelation mit der Komplexität des Leistungsprogramms der Unternehmens-IT die autonome Komplexität der IT-Landschaft zunimmt oder dass die autonome Komplexität unabhängig von der geschäftlichen Komplexität steigt. In zweiten Fall ist die Komplexitätssteigerung nicht mit einer direkten Wertschöpfung für das Unternehmen verbunden, kann allerdings im Sinne des in 2.3 entwickelten EWIM-Ansatzes Wertschöpfungspotenziale schaffen. Diese nicht wertschöpfende Komplexität wird mit dem Begriff Kompliziertheit bezeichnet.190 In beiden Fällen beruht die Komplexitätssteigerung auf zusätzlichen Systemelementen der IT-Landschaft, die durch die IT-Organisation betrieben, betreut und weiterentwickelt werden müssen. Es ist also von einer positiven Korrelation der Komplexität der IT-Landschaft und derjenigen der IT-Organisation auszugehen. Fragen zur Wechselwirkung der Komplexität der Teilsysteme IT-Organisation und IT-Landschaft werden nicht in die weitere Ausarbeitung einbezogen. Sie liefern Ansatzpunkte für weiterführende Forschungsaktivitäten. 4.4.1.2 Autonome Komplexität der IT-Landschaft 4.4.1.2.1

Komplexität der Gesamtheit der IT-Systeme

Die Perspektive der Gesamtheit der IT-Systeme beruht auf der Zahl der ITSysteme, ihrer Vielfalt und der Abhängigkeiten untereinander. Dern beschreibt das Artefakt des Anwendungstypen.191 Anwendungstypen stellen eine Klassifikation von IT-Systemen nach dem Grad der Ähnlichkeit der zugrunde liegenden IT-Architekturen und der bei Wartung, Erweiterung und Erneuerung eingesetzten Vorgehensweisen dar. Das Artefakt des Anwendungstypen kann genutzt werden, um die Vielfalt der IT-Systeme zu erfassen. Unter Einbeziehung der Anwendungstypen wird die folgende Kennzahl definiert:

190 BECKER UND ROSEMANN assozieren im Gegensatz dazu den Begriff der Kompliziertheit mit der Vielfalt, d. h. Verschiedenheit der Elemente eines Systems; vgl. [BeRo98], S. 111 ff. 191 Vgl. [Dern09], S. 53.

186

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

KGI

= Komplexität der Gesamtheit der IT-Systeme = 1

$7 × ¦ 0L , L =

mit

Formel 4:

N

= Zahl der IT-Systeme

Mi

= Anzahl ein- und ausgehender Informationsflüsse des IT-Systems i

AT

= Anzahl Anwendungstypen

Komplexität der Gesamtheit der IT-Systeme

DURST entwickelt in Wertorientiertes Management von IT-Architekturen192 ein umfassendes Kennzahlensystem zur wertorientierten Steuerung der Unternehmens-IT. Nach dem begrifflichen Fundament der vorliegenden Arbeit stellt das von Durst entwickelte Kennzahlensystem die IT-Landschaft, deren Verzahnung mit der Geschäftssicht und das IT-Portfolio in den Mittelpunkt. DURST verwendet Modelle wie Geschäftsprozess-Produkt-System-Matrizen, um Größen wie die funktionale Vollständigkeit der IT-Landschaft zu messen. Er zeigt, wie mithilfe von Kennzahlen zur Strategiekonformität von IT-Projekten, der Konformität und der Zukunftsfähigkeit der IT-Landschaft der Wertbeitrag der Unternehmens-IT quantifiziert werden kann und sich daraus auf Basis von Bewertungen der Ist-IT-Landschaft und deren Abgleich mit quantitativen Solldefinitionen Optimierungsbereiche in der Unternehmens-IT ableiten lassen. DERN UND JUNG193 greifen DURST auf und beschreiben Möglichkeiten zur Steuerung der Unternehmens-IT mithilfe von Komplexitätskennzahlen. Die Autoren definieren eine Kennzahl, die die Zahl der IT-Systeme, die Informationsbeziehungen und die Homogenität, verstanden als Gleichartigkeit von Systemen, kombiniert. Im Sinne der o. a. Perspektiven der Komplexitätsbetrachtung adressieren die Autoren somit die Komplexität der Gesamtheit der IT-Systeme. Die Erfassung der Homogenität wird nicht genauer ausgeführt. Um diese Lücke zu schließen, kann auf die Anzahl der Anwendungstypen zurückgegriffen werden. Informationsbeziehungen werden im Vorschlag von DERN UND JUNG im Intervall [0,1] bewertet, wobei 0 bedeutet, dass keine Beziehung vorliegt, und 1 maximale Komplexität der Informationsbeziehungen zwischen zwei Systemen ausdrückt. Die maximale Komplexität der Informationsbeziehungen in einer ITLandschaft mit N Systemen liegt somit bei:

192 193

Vgl. [Durst07]. Vgl. [DeJu09].

4.4 Entwurf eines Kennzahlensystems zum Integrationsmanagement

IBmax =

Formel 5:

187

N × ( N - 1) 2

Maximale Komplexität der Informationsbeziehungen nach DERN UND JUNG

Dieser Ansatz kann vereinfacht werden, indem Informationsbeziehungen zwischen Systemen mit 1 oder 0 bewertet werden, je nachdem, ob Informationsflüsse vorliegen oder nicht. Aus den Überlegungen von DERN UND JUNG ergibt sich als vereinfachte, durch die maximale Komplexität der Informationsbeziehungen relativierte Kennzahl KGIE zur Komplexität der Gesamtheit der ITSysteme: KGIE

= Komplexität der Gesamtheit der IT-Systeme (vereinfacht) = N

䌥M

i

AT × N ×

i =1

IB max

,

mit

Formel 6:

4.4.1.2.2

N

= Zahl der IT-Systeme

Mi

= Indikator Informationsbeziehung für System i, Mi = 1 oder 0

AT

= Anzahl Anwendungstypen

Vereinfachte Erfassung der Komplexität der Gesamtheit der ITSysteme Komplexität der IT-Systeme

Um die Komplexität einzelner Systeme zu erfassen, wird auf die mittlere Komplexität zurückgegriffen. Diese kann wie folgt erfasst werden: MKX

= Mittlere Komplexität der IT-Systeme =

1 N × 䌥 K ( ISi ) , N i =1 mit N

= Anzahl IT-Systeme

K (ISi) = Komplexität des IT-Systems ISi,

0 ˺K(IS ) ˺1 i

Formel 7:

Mittlere Komplexität der IT-Systeme in der IT-Landschaft

188

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

Hier stellt sich die Frage nach der konkreten Bestimmung der Komplexität einzelner IT-Systeme. Ein möglicher Ansatz194 wurde von LEUKERT195 als Ergebnis eines Projektes der COMMERZBANK mit der Rotterdam Management School vorgestellt. Im Projekt der COMMERZBANK wurden neun Faktoren zur Komplexität von Applikationen (IT-Systemen) identifiziert, deren Ausprägung für Anwendungen mithilfe der EAM-Lösung196 der COMMERZBANK bestimmt wurden. Auf diese Weise wurden auf Basis der Komplexitätsfaktoren mehrdimensionale Bewertungsdiagramme der IT-Systeme erstellt. Mithilfe solcher Diagramme kann eine systematische, fundierte Expertenschätzung der Komplexität einzelner IT-Systeme vorgenommen werden. Die nachstehende Abbildung zeigt exemplarisch die Komplexitätsdiagramme zweier IT-Systeme der COMMERZBANK im Bereich der Partnersysteme.

Abbildung 91: Komplexitätsdiagramm zweier IT-Systeme der COMMERZBANK zur Partnerdatenverwaltung197 194 Ein alternativer Ansatz zur Messung der Komplexität von IT-Systemen ergibt sich aus der Softwaretechnik. Hier wurden schon in den 70er Jahren Modelle wie die zyklomatische Komplexität oder die Halstead-Metrik zur Messung der Komplexität von Softwaresystemen, d.h. IT-Systemen entwickelt. Vgl. dazu [Heindl10], S. 29 ff. 195 Vgl. [CoBa09]. 196 EAM-Lösungen (EAM = Enterprise Architecture Management) sind Werkzeuge, die das Management der Unternehmensarchitektur durch eine datenbankgestütztes Repository der UnternehmensIT unterstützen. Grundlage des Einsatzes solcher Werkzeuge beim Management der Unternehmensarchitektur ist ein Referenzmodell zur IT-Prozesslandschaft, das entweder „out of the box“ mitgeliefert wird oder vom anwendenden Unternehmen zu definieren ist. Je nach Werkzeug wird die ITProzesslandschaft mehr oder weniger umfassend abgedeckt. Eine umfassende Analyse von EAMLösungen findet sich in [Sebis08]. 197 Entnommen aus [CoBa09], S. 12.

4.4 Entwurf eines Kennzahlensystems zum Integrationsmanagement

189

Wird eine auf diese Weise qualitativ unterlegte Bewertung auf das Intervall [0,1] normiert, so entspricht der MKX-Wert 0 minimaler und 1 maximaler mittlerer Komplexität. Komplexität und Kompliziertheit Wie in der Analyse der Möglichkeiten zum Komplexitätsmanagement in Abschnitt 3.2.1 gezeigt, ist die für eine Unternehmens-IT anzustrebende Komplexität in Relation zum erforderlichen dynamischen und statischen Potenzial zu sehen und aufgrund bestehender Korrelationen abhängig von der geschäftlichen Komplexität, die sich in den Leistungsanforderungen an die Unternehmens-IT manifestiert. Daher muss, wie oben beschrieben, zwischen ƒ ƒ

der Komplexität unterschieden werden, die sich notwendigerweise – im Rahmen dieser Korrelation – aus der wahrgenommenen geschäftlichen Komplexität ergibt, und der Komplexität, die sich unabhängig davon in der autonomen Komplexität manifestiert. Hierunter fällt insbesondere nicht wertschöpfende Komplexität, die sich in unnötig redundanten Implementierungen, unnötig komplizierter Programmierung, unnötiger Technologievielfalt etc. manifestiert. Hierfür wurde der Begriff Kompliziertheit eingeführt.

Eine mögliche Zielsetzung für die Unternehmens-IT besteht offensichtlich darin, die Kompliziertheit in der IT-Landschaft zu minimieren, um auf diese Weise einen möglichst großen Teil der Komplexität der IT-Landschaft in der wahrgenommenen Komplexität der Geschäftsseite, d. h. im Sinne einer wertschöpfenden Wirkung, zu begründen. Dies bedeutet, dass ein IT-System hochkomplex sein kann, ohne kompliziert zu sein. Dies ist dann der Fall, wenn die Komplexität vollständig auf die geschäftlichen Anforderungen zurückzuführen ist. Da sich die Kompliziertheit der IT-Landschaft a posteriori vor allem in den IT-Systemen manifestiert und sich eine Reduktion nach Erfahrung des Autors der vorliegenden Arbeit – etwa im Vergleich zur IT-Basisinfrastruktur - hier am schwierigsten gestaltet, wird die Kompliziertheitsbetrachtung auf die der Einzelsysteme beschränkt. Die folgende Abbildung fasst diese Überlegungen zusammen.

190

Autonome Komplexität der Unternehmens-IT

Komplexität der Anwenderorganisation (Geschäftsprozesse mit enthaltene Aufgaben)

Leistungsanforderungen

Wahrgenommene Komplexität

Geschäftsseite

Kompliziertheit der IT-Systeme

Korrelierte Komplexität der Unternehmens-IT

Komplexität der Unternehmens-IT

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

begrenzt Dynamisches Potential Statisches Potential Reaktionsfähigkeit

Abbildung 92: Kompliziertheit in der IT-Landschaft und Komplexität der Unternehmens-IT Es ergibt sich die Kennzahl zur mittleren Kompliziertheit eines IT-Systems, die wie bereits für die die mittlere Komplexität gezeigt - durch eine qualitative Expertenschätzung bestimmt werden kann. MKZ

= Mittlere Kompliziertheit der IT-Systeme =

1 N × 䌥 K(ISi) , N i=1 mit N

= Anzahl IT-Systeme

K (ISi) = Kompliziertheit des IT-Systems ISi,

0 ˺K(IS ) ˺1 i

Formel 8:

Mittlere Kompliziertheit der IT-Systeme in der IT-Landschaft

4.4 Entwurf eines Kennzahlensystems zum Integrationsmanagement

4.4.1.2.3

191

Komplexität der IT-Basisinfrastruktur

Zur Erfassung der Komplexität der IT-Basisinfrastruktur wird die Zahl der in der IT-Landschaft eingesetzten Basissystemtypen - sowohl Hardware-Typen als auch Hardware-nahe Software-Typen – herangezogen. Beispiele für Basissystemtypen sind Server, Netzwerkkomponente, Datenbankmanagementsystem, Betriebssystem oder Middleware-Komponente.198 Für jeden auf diese Weise identifizierten Typ wird die Anzahl der Technologieausprägungen erhoben199. Für den Basissystemtyp „Datenbankmanagementsystem“ wären dies zum Beispiel Oracle 8i, Oracle 9i, IBM DB2 V9 usw. Beziehungen zwischen Basissystemen – wie z.B.: „DBMS (Database Management System) D1 läuft auf Server S1“ – werden vernachlässigt, da deren Bedeutung für die Komplexität der IT-Landschaft nach Erfahrung des Autors der vorliegenden Arbeit durch die Vielfalt der Systemelemente der IT-Basisinfrastruktur und die Vielfalt der Interaktionsbeziehungen zwischen IT-Systemen dominiert wird. Aus diesen Überlegungen ergibt sich die folgende Kennzahl: KB

= Komplexität der IT-Basisinfrastruktur =

෤

1 N × [Ti× Ii ], N 1 mit

Formel 9:

N

= Zahl der Basissystemtypen

Ti

= Zahl der Technologieausprägungen für Basissystemtyp i, i=1,..N

Ii

= Mittlere Zahl von Instanzen je Technologieausprägung des Basissystemtyps i

Komplexität der IT-Basisinfrastruktur

198 Die Festlegung der Basissystemtypen ist nach dem entwickelten Referenzmodell zur ITProzesslandschaft im Prozess Infrastruktur-Asset-Management anzusiedeln. 199 Für den Falle, dass virtualisierte Infrastruktur zum Einsatz kommt, ist im jeweiligen Unternehmenskontext und der Messziele festzulegen, wie virtuelle Instanzen im Vergleich zu physischen Instanzen bewertet werden.

192

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

4.4.1.3 Wahrgenommene geschäftliche Komplexität Aufgrund der Überlegungen zur Perspektive 4 wird vorgeschlagen, die wahrgenommene Komplexität der Geschäftsseite durch die Bewertung der Komplexität der Geschäftsprozesse aus Sicht der IT-Organisation zu erfassen. Zu diesem Zweck werden zwei Kennzahlen definiert - die summierte Komplexität der Prozesse sowie die mittlere Prozesskomplexität.200 In Abschnitt 4.6.3 werden diese Kennzahlen aufgegriffen und im Kontext adaptiver Geschäftsarchitekturen beleuchtet. WK

= Wahrgenommene geschäftliche Komplexität = N

䌥KU(G ) , i

i=1

mit N =

Gesamtzahl der Geschäftsprozesse

KU (Gi)=

Komplexitätsbewertung des Geschäftsprozesses i aus Sicht der IT-Organisation, 0 ˺ KU(G i) ˺1

sowie mWK

Formel 10:

=

Mittlere Prozesskomplexität =

WK N

Kennzahlen zur wahrgenommenen geschäftlichen Komplexität

200 Es wird davon ausgegangen, dass die Bewertung der Komplexität der Geschäftsprozesse auf das Intervall [0,1] normiert ist. In einem ersten Ansatz kann diese Normierung mithilfe der Expertenschätzung auf Basis einer Ordinalskala umgesetzt werden. In Abschnitt 5.3.4 wird gezeigt, wie diese Kennzahl auf Basis eines Referenzmodells zur Prozesslandschaft auf die Ebene der Geschäftsarchitektur gehoben werden kann. Auf diese Weise werden nicht einzelne Prozesse, sondern Prozessgruppen bewertet und die Komplexitätsbestimmung vereinfacht.

4.4 Entwurf eines Kennzahlensystems zum Integrationsmanagement

193

4.4.1.4 Zusammenfassung Die entwickelten Basiskennzahlen zur Komplexität der Geschäftsseite, der Gesamtheit der IT-Systeme, der Einzelsysteme und der IT-Basisinfrastruktur werden zur mehrdimensionalen Kennzahl KITL zur Gesamtkomplexität der ITLandschaft zusammengesetzt.201 KITL

= Gesamtkomplexität der IT-Landschaft = (WK, KGI, MKX, MKZ, KB),

mit WK

Formel 11:

= Wahrgenommene geschäftliche Komplexität

KGI

= Komplexität der Gesamtheit der IT-Systeme

MKX

= Mittlere Komplexität der IT-Systeme

MKZ

= Mittlere Kompliziertheit der IT-Systeme

KB

= Komplexität der IT-Basisinfrastruktur

Mehrdimensionale Kennzahl KITL zur Gesamtkomplexität der IT-Landschaft

Abgrenzung und Ansatzpunkte für ergänzende Forschungsaktivitäten – Korrelation der Einzelkennzahlen in KITL Zentraler Baustein des in Abschnitt 4.4 entwickelten Kennzahlensystems ist die mehrdimensionale Kennzahl KITL zur Komplexität der ITLandschaft. A priori bestehen zwischen den in KITL enthaltenen Einzelgrößen Korrelationen. Die Art und die Stärke dieser Zusammenhänge sollten im Rahmen empirischer Untersuchungen in der UnternehmensIT größerer Unternehmen überprüft werden, um auf diese Weise Hinweise für die Steuerung und Optimierung der Komplexität der Unternehmens-IT zu gewinnen. KITL kann durch Kombination der Einzelkennzahlen in eindimensionale Kennzahlen überführt werden202. Beispielsweise ergibt sich aus der Gewichtung der Komplexität der Gesamtheit der IT-Systeme mit deren mittlerer Komplexität

Eine vereinfachte Kennzahl KITLE erhält man durch das Ersetzen von KGI innerhalb von KITL durch KGIE. 202 Diese Kennzahlen können aufgrund der indirekten Messung, wie eingangs des Abschnittes beschrieben, nur bestimmte Aspekte der Komplexität der IT-Landschaft beschreiben, ohne diese vollständig erfassen zu können. 201

194

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

und der Addition der Komplexität der IT-Basisinfrastruktur eine eindimensionale Größe, die hier als absolute Komplexität203 der IT-Landschaft bezeichnet wird204. KAITL

= Absolute Komplexität der IT-Landschaft =

MKX × KGI + KB , mit

Formel 12:

A

K

ITL

MKX

= Mittlere Komplexität der IT-Systeme

KGI

= Komplexität der Gesamtheit der IT-Systeme

KB

= Komplexität der IT-Basisinfrastruktur

- Absolute Komplexität der IT-Landschaft

Ersetzt man KGI hier durch die beschriebene Vereinfachung KGIE und verzichtet auf die Berücksichtigung der IT-Basisinfrastruktur, so erhält man als Vereinfachung auf Basis der o. a. Arbeit von DERN UND JUNG: KAEITL

= Absolute Komplexität der IT-Landschaft – vereinfacht =

෤M ) N

( MKX × AT ×

i

i=1

,

N × (N 1) 2

mit

Formel 13:

AE

K

ITL

N

= Zahl der IT-Systeme

Mi

= Indikator Informationsbeziehung für System i; Mi = 1 oder 0

MKX

= Mittlere Komplexität der IT-Systeme

AT

= Zahl der Anwendungstypen

- Absolute Komplexität der IT-Landschaft - vereinfacht

Aufgrund der beschriebenen Korrelation sind wertschöpfende Veränderungen der Komplexität der IT-Landschaft im Verhältnis zu Veränderungen der Komplexität der Geschäftsseite zu sehen. Durch Gewichtung von KAITL mit der wahrgenommenen geschäftlichen Komplexität erhält man die Kennzahl KRITL, die die autonome Komplexität der IT-Landschaft ins Verhältnis zur Komplexität 203

Hier handelt es sich um eine eindimensionale Kennzahl zur autonomen Komplexität. Je nach der mit der Komplexitätsmessung verfolgten Zielsetzung kann zusätzlich ein Gewichtungsfaktor aufgenommen werden, der mit KB multipliziert wird, um auf diese Weise eine Gewichtung der IT-Basisinfrastruktur bei der Komplexitätsmessung einzuführen. 204

4.4 Entwurf eines Kennzahlensystems zum Integrationsmanagement

195

der Geschäftsseite setzt. Entsprechend ergäbe sich eine vereinfachte Variante KRITL durch Gewichtung von KAEITL mit WK. KRITL

= Relative Komplexität der IT-Landschaft = MKX × KGI + KB , WK

mit

Formel 14:

R

K

ITL

MKX

= Mittlere Komplexität Informationssysteme

KGI

= Komplexität der Gesamtheit der Informationssysteme

KB

= Komplexität der IT-Basisinfrastruktur

WK

= Wahrgenommene geschäftliche Komplexität

– Relative Komplexität der IT-Landschaft

4.4.2 Integrationseffizienz der IT-Organisation Zur Messung der Leistungsfähigkeit der IT-Organisation205 bei der Erbringung von Integrationsleistungen wurde in Abschnitt 3.2.2.5 auf Basis einer Arbeit von SCHWINN die Kennzahl IE der Integrationseffizienz entwickelt. Es handelt sich um eine Größe zur Erfassung der mit der Komplexität der Anforderungen gewichteten in IT-Projekten206 erbrachten Integrationsleistungen.

205 Nach der in Kapitel 2 getroffenen Definition umfasst die IT-Organisation alle nicht-maschinellen Aufgabenträger, die die Planung, die Steuerung, die Entwicklung oder den Betrieb der Elemente der IT-Landschaft durchführen. Externe Leistungserbringung ist daher bei der Bestimmung der Integrationseffizienz zu berücksichtigten. 206 Diese Kennzahl ist auf IT-Projekte ausgerichtet, da nach Erfahrung des Autors IT-Projekte die größte Veränderungswirkung auf die IT-Landschaft entfalten und die detaillierte Aufwandsermittlung und -verfolgung in Unternehmen in Projekten am weitesten fortgeschritten ist. Eine Ausweitung auf Wartungs- bzw. Weiterentwicklungsaktivitäten, die in der Linienorganisation durchgeführt werden, ist analog zum hier beschriebenen Ansatz möglich.

196

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

IE =

Integrationseffizienz der Unternehmens-IT = N

䌥 i=1

[IAi × IKi] , N

mit

Formel 15:

N

= Anzahl IT-Projekte im Betrachtungszeitraum

IAi

= Aufwand für Integrationsleistungen der IT-Organisation im IT-Projekt i, i=1,…,N

IKi

= Komplexitätsbewertung der Integrationsanforderungen im IT-Projekt i, 0 ˺IKi ˺1

Integrationseffizienz der IT-Organisation auf Basis der Komplexität von Integrationsanforderungen

Die Kennzahl WK zur wahrgenommenen Komplexität der Geschäftsseite basiert auf der Gesamtheit der Anforderungen der Anwenderorganisation. Diese Gesamtheit stellt eine Obermenge der Integrationsanforderungen dar. Mit Hilfe von WK, kann daher alternativ zum Vorschlag von SCHWINN eine Kennzahl IE’ definiert werden, die auf der Gewichtung erbrachter Integrationsleistungen mit WK basiert. IE’ beschreibt die Leistungsfähigkeit der IT-Organisation weniger präzise als IE. Dafür entfällt die Notwendigkeit, die Komplexität der Integrationsleistungen in jedem Projekt zu bestimmen. IE’ =

Integrationseffizienz der Unternehmens-IT = 1 N , 䌥IAi WK i=1

mit

Formel 16:

N

= Anzahl IT-Projekte im Betrachtungszeitraum

IAi

= Aufwand für Integrationsleistungen der IT-Organisation im Projekt i, i=1,…,N

WK

= Wahrgenommene Komplexität der Geschäftsseite zum Betrachtungszeitpunkt

Alternative Kennzahl zur Leistungsfähigkeit der IT-Organisation bzgl. Integrationsleistungen

4.4.3 Aufwandsverteilung – der Aufwandsquotient zu Integrationsleistungen Die Zielsetzung des Integrationsmanagements besteht in der Veränderung des Verhältnisses von Integrationsleistungen und Leistungen zur Implementierung

4.5 Integrationsmanagement in Managementprozessen und operativen IT-Prozessen

197

fachlicher Anforderungen i. e. S. Werden diese Leistungen je Projekt erfasst und ins Verhältnis gesetzt, so ergibt sich als Aufwandsquotient: Aufwandsquotient (t) = Aufwandsverteilung zum Zeitpunkt t =

෤ AI , ෤ AF N

i

1 N

i

1

mit

Formel 17:

N

= Anzahl IT-Projekte im Betrachtungszeitraum

AIi

= Aufwand für Integrationsleistungen der IT Organisation im IT-Projekt i

AFi

= Aufwand für Leistungen zur Implementierung fachlicher Anforderungen i.e.S. im IT-Projekt i

Aufwandsquotient zu Integrationsleistungen der IT-Organisation

4.5 Integrationsmanagement in Managementprozessen und operativen ITProzessen Auf der Grundlage der in Abschnitt 4.3.4 beschriebenen Verankerung des Integrationsmanagements in der strategischen Konzeption und der damit verbundenen Definition eines Kennzahlensystem zur Steuerung der Unternehmens-IT wird die Einbettung des Integrationsmanagements in die IT-Prozesslandschaft nun auf die Management-Ebene und die operative Ebene ausgedehnt. Das in 4.3.4 entwickelte Modell wird dazu in zwei Schritten erweitert: 1.

2.

Das Aufgabenspektrum der Prozesse des IT-Portfoliomanagements wird entlang des Kennzahlensystems erweitert. Dabei wird beschrieben, wie die Prozesse des IT-Portfoliomanagements zu ergänzen sind, um die operative und die Management-Ebene miteinander zu verzahnen. Es wird ein Modell zur Durchführung von IT-Projekten definiert, das Aspekte des Integrationsmanagements einbezieht und auf die zuvor beschriebene Erweiterung der Prozesse des IT-Portfoliomanagements zugeschnitten ist.

Nach der Durchführung dieser beiden Schritte ist das Modell zur Einbettung des Integrationsmanagements in die IT-Prozesslandschaft vollständig, und es liegen weiterführenden Gestaltungsempfehlungen zu den Punkten 1-5 des formu-

198

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

lierten Verfeinerungsbedarfs vor. Mit Abschluss des Abschnittes 4.5 ergibt der folgende Stand der Entwicklung weiterführender Gestaltungsempfehlungen. 1

Entwicklung Referenzmodell zur IT-Prozesslandschaft 2

Definition eines Ansatzes zur IT-Unternehmensarchitektur 3

Integrationsmanagement in der strategischen Konzeption Einbettung Integrationsmanagement in der strategischen Konzeption Leistungsfähigkeit der Unternehmens-IT im Hinblick auf Integrationsleistungen

Komplexitätsmanagement

4

Entwicklung eines Kennzahlensystems 5

Integrationsmanagement und Planung & Controlling von IT-Projekten Selektion von Anforderungen unter Berücksichtigung von Komplexitätswirkung + Integrationsaufwänden

Steuerung unter Berücksichtigung von Komplexitätswirkung und Integrationsaufwänden

6

Verzahnung Gesamtsicht und IT-Projektsicht 7

Ergänzende Leitlinien zur Organisation IT-Landschaft

Gestaltung der ITLandschaft mit Hilfe von Komplexitätskennzahlen

Lebenszyklusmanagement von ITSystemen

IT-Landschaft und Adaptierbarkeit, Flexibilität & Agilität

8

Ganzheitliche Integrationslösungen und IT-Portfoliomanagement 9

Empfehlungen zur Steigerung der Integrationseffizienz der Unternehmens-IT

Abbildung 93: Stand der Entwicklung weiterführender Gestaltungsempfehlungen 4.5.1 IT-Portfoliomanagement und Integrationsmanagement Die Prozesse der Management-Ebene bilden nach dem in Abschnitt 4.2 entwickelten Modell das Bindeglied der strategischen und der operativen Ebene der IT-Prozesslandschaft. Aufgabe der Management-Prozesse ist die Sicherstellung der Durchführung der Prozesse der operativen Ebene im Sinne der auf der strategischen Ebene festgelegten Ziele und des daraus abgeleiteten Kennzahlensystems zur Steuerung der Unternehmens-IT. Während die strategische Ebene das Kennzahlensystem vorgibt, wirken die Prozesse der operativen Ebene verändernd auf die Elemente der Unternehmens-IT. Diese Elemente werden als Port-

4.5 Integrationsmanagement in Managementprozessen und operativen IT-Prozessen

199

folioobjekte in den Prozessen des IT-Portfoliomanagements bewertet und gesteuert. In den Prozessen des IT-Portfoliomanagements - als Bindeglied der operativen und Management-Ebene - erfolgt daher Bestimmung der Kennzahlen. Dazu werden die Portfolioobjekte unter Einbeziehung der durch die operativen IT-Prozesse verursachten Veränderungen bewertet. Die Kennzahlenbestimmung erfordert die Aufstellung von Mess- bzw. Bewertungsmethoden innerhalb des jeweiligen Unternehmenskontextes. Dies bedeutet zum Beispiel, dass im IS-Portfoliomanagement definiert wird, welche Methode der Messung der Komplexität einzelner IT-Systeme zugrunde liegt. Die Definition umfasst z. B. die Festlegung der Typen von IT-Systemen, die in der Komplexitätsmessung berücksichtigt werden.207 Darüber hinaus ist sicherzustellen, dass die Veränderungen der Unternehmens-IT, die durch die Durchführung der Prozesse der operativen Ebene verursacht werden, z. B. aufgrund der Durchführung von IT-Projekten, systematisch erfasst und im IT-Portfoliomanagement berücksichtigt werden.208 Aus diesen Ausführungen ergibt sich ein auf das Integrationsmanagement zugeschnittenes Modell zum IT-Portfoliomanagement. Es weist die folgenden Merkmale auf und wird gemäß des definierten Verfeinerungsbedarfs (Punkt 5 in Abbildung 93) im nachfolgenden Abschnitt mit einem erweiterten Modell zur Planung und Steuerung von IT-Projekten verbunden: ƒ

ƒ ƒ ƒ ƒ

In den Prozessen des IT-Portfoliomanagements werden auf die Kennzahlen zugeschnittene Bewertungsmethoden definiert. Dazu wird die systematische Inventur der Portfolioobjekte - d. h. IT-Systeme, Infrastruktur-Assets, ITProjekte usw. - durchgeführt, um die gemäß den definierten Methoden erforderlichen Daten zu erheben. Die Daten werden auf der Basis definierter Bewertungsmethoden in die Bewertung der Portfolioobjekte - z. B. der Komplexität von IT-Systemen – überführt. Aus der Bewertung der Portfolioobjekte werden die Werte für die einzelnen Kennzahlen hergeleitet und z. B. in der Balanced Score Card verdichtet. Das laufende Monitoring der Kennzahlen wird durchgeführt. Aus der systematischen Bewertung, sowohl des Gesamtportfolios und als auch einzelner Portfolioobjekte, werden Maßnahmen zur Optimierung der Komplexität der IT-Landschaft und der Leistungsfähigkeit der IT-

207 So ist beispielsweise die Frage zu beantworten, ob Systeme zur individuellen Datenverarbeitung in der Komplexitätsmessung berücksichtigt werden. 208 Zum Beispiel die Einführung oder Abschaltung von IT-Systemen.

200

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

Organisation abgeleitet209. Auf dies Weise wird die Steuerung der Unternehmens-IT im Sinne eines Integrationsmanagements unterstützt. Die folgende Abbildung zeigt dieses entlang der Prozesse des ITPortfoliomanagements integrierte Modell zur kennzahlenbasierten Steuerung der Unternehmens-IT. insbesondere

Strategische IT-Planung Kennzahlen zum Integrationsmanagement

Strategische Ebene

Komplexität

Reaktionsfähigkeit

Aufwands- Integrationsquotient effizienz

Zielvorgaben

Reporting

IT-Portfoliomanagement

insbesondere

Monitoring/ Bewertung

ManagementEbene

Auswertung/ Verdichtung

Inventur

Steuerung / Optimierung

Management von IT-Organisation & IT-Landschaft

Optimierung

Ist-Werte

insbesondere

Operative Ebene

Strategische Konzeption der Unternehmens-IT

Erweiterung/Erneuerung im Rahmen von IT-Projekten

Betrieb & WeiterEntwicklung IT-Landschaft

Abbildung 94: IT-Portfoliomanagement und Integrationsmanagement in der ITProzesslandschaft Aus dem entwickelten Modell ergeben sich folgende Erweiterungen des Aufgabenspektrums der Prozesse des IT-Portfoliomanagements210: ƒ

IS-Portfoliomanagement o Festlegung von Bewertungsmethoden zur Komplexität und zur Kompliziertheit von IT-Systemen

209 Dies bedeutet z. B., dass nicht nur die mittlere Kompliziertheit der IT-Systeme bewertet wird, sondern aus der Bewertung der Komplexität einzelner Systeme Optimierungsmaßnahmen abgeleitet werden. 210 Die Komplexität der IT-Organisation und die Messung des statischen bzw. dynamischen Potenzials der Unternehmens-IT wurden als weiterführender Forschungsbedarf definiert und werden daher hier nicht berücksichtigt.

4.5 Integrationsmanagement in Managementprozessen und operativen IT-Prozessen

201

Definition von Anwendungstypen Inventur der IT-Systeme und ihrer Informationsbeziehungen bzw. flüsse o Klassifizierung der Systeme nach Anwendungstypen o Bestimmung der Komplexität und Kompliziertheit je IT-System Infrastruktur-Asset-Management o Definition von Basissystemtypen o Inventur der Basissysteme und Zuordnung zu Basissystemtypen und Technologieausprägungen IT-Projektportfoliomanagement o Festlegung von Bewertungsmethoden zur Anforderungskomplexität o Erweiterung der Projektleistungskategorien um Integrationsaufwände und Aufwände für fachliche Anforderungen o Inventur der IT-Projekte o Zusammenstellung der je IT-Projekt geleisteten Integrationsaufwände und Aufwände für fachliche Anforderungen o Bewertung der Anforderungskomplexität je IT-Projekt o o

ƒ

ƒ

Darüber hinaus erfordert die Bestimmung der wahrgenommenen Komplexität die Komplexitätsbewertung der Geschäftsprozesse. Die Inventur der Geschäftsprozesse wird hier nicht als Teil des IT-Portfoliomanagements verstanden, sondern als Input aus einem auf Geschäftsseite angesiedelten Prozess gesehen. Dieser Prozess wird als Geschäftsprozessmanagement verstanden und in Anlehnung an SCHMELZER UND SESSELMANN211 folgendermaßen definiert: Definition – Geschäftsprozessmanagement Unter Geschäftsprozessmanagement ist der Prozess der systematischen Steuerung der Geschäftsprozesse eines Unternehmens zu verstehen. Geschäftsprozessmanagement ist auf die Erfüllung der Bedürfnisse der Kunden und anderer Interessengruppen (Mitarbeiter, Kapitalgeber, Eigentümer, Lieferanten, Partner, Gesellschaft) ausgerichtet und dient der Erreichung der strategischen und operativen Ziele des Unternehmens, indem das Geschäftsprozessmanagement die Effektivität und Effizienz der Geschäftsprozesse erhöht. Die Eigentümerschaft des Prozesses des Geschäftsprozessmanagements liegt auf Seiten der Anwenderorganisation.

211

Vgl. [Schme06].

202

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

Mit dieser Definition wird das Gesamtmodell zur Prozessgruppe des ITPortfoliomanagements in ihrer Funktion als Integrator der operativen und der strategischen Ebene vervollständigt. Die folgende Abbildung zeigt das Modell. Geschäftsprozessmanagement Inventur

Integrationseffizienz und Aufwandsquotient Erfassung Integrationsaufwände Erfassung Anforderungskomplexität

Leistungskategorien Inventur Bewertungsmodelle

Bewertungsmodelle

Kennzahlenbestimmung

Komplexität je Prozess

Kennzahlenbestimmung

Wahrgenommene Komplexität

IT-Portfoliomanagement IT-Projektportfolio-Management

IT-Ressourcen-PortfolioManagement

IS-Portfolio-Management

Infrastruktur-Asset-Management

Inventur

Monitoring & Bewertung

Erfassung der geschäftlichen Komplexität

Steuerung & Optimierung

Inventur Inventur

Kompliziertheit je IS

Anwendungstypen definieren

Komplexität je IS

Bewertungsmodelle

Infoflüsse

Kennzahlenbestimmung Optimierungen

Komplexität der IT-Landschaft – Fokus Informationssysteme

Basissystemtypen definieren Ausprägungen bestimmen

Kennzahlenbestimmung Optimierungen

Komplexität der IT-Landschaft – Fokus IT-Basisinfrastruktur

Abbildung 95: Erweitertes Modell zum IT-Portfoliomanagement 4.5.2 IT-Projektdurchführung und Integrationsmanagement Gemäß dem definierten Verfeinerungsbedarf ist das Modell der Planung und des Controllings von IT-Projekten so zu erweitern, dass die Wirkung der Umsetzung von Leistungsanforderungen auf die Komplexität, die Reaktionsfähigkeit der Unternehmens-IT und die Leistungsfähigkeit der IT-Organisation berücksichtigt werden. Nach dem Referenzmodell zur IT-Prozesslandschaft werden Integrationsleistungen durch die IT-Organisation im Rahmen der Durchführung der Prozesse der Erweiterung/Erneuerung der IT-Landschaft erbracht. Die Erweiterung des Prozesses der IT-Projektdurchführung steht im Mittelpunkt dieses Abschnittes. Nach Erfahrung des Autors der vorliegenden Arbeit sieht das in größeren Unternehmen eingesetzte Prozessmodell zur IT-Projektdurchführung i. d. R. die

4.5 Integrationsmanagement in Managementprozessen und operativen IT-Prozessen

203

systematische Anforderungsanalyse und das gezielte Aufwands-Controlling im Projekt erbrachter Leistungen nach den für das jeweilige Unternehmen definierten Leistungskategorien212 vor. Ein solches Prozessmodell umfasst ein Entscheidungsmodell, das darauf beruht, an standardisierten Entscheidungspunkten den erreichten Projektstand zu überprüfen und die Durchführung von Folgeaktivitäten freizugeben.213 Für die vorliegende Arbeit wird das in der folgenden Abbildung dargestellte Modell angenommen. insbesondere

Erweiterung / Erneuerung im Rahmen von IT-Projekten

Analyse der Idee

E1

Machbarkeitsanalyse

E2

Realisierung

E3

Überführung in Produktion

Prozess der Projektdurchführung Abschätzung, Bewertung & Planung

Projekt-Controlling

(e.g. im Rahmen Business Case Analyse)

Entscheidungspunkte im Prozess der Projektdurchführung

E1

Entscheidung über Weiterverfolgung der Idee

E2

Entscheidung über Realisierung

E3

Entscheidung über Produktivnahme unter Einbeziehung einer Risikobewertung

Abbildung 96: Allgemeines Modell zur IT-Projektdurchführung Das Modell sieht drei Entscheidungspunkte vor. Bis zum Entscheidungspunkt E2 stehen die Zieldefinition, die Wirkungsanalyse und die Planung der zur Zielerreichung notwendigen Aktivitäten, Ressourcen, Budgets und Meilensteine im Vordergrund. Nach E2, der Entscheidung über die Realisierung, liegt der Fokus eines IT-Projektes auf der Durchführung der geplanten Implementierungsaktivitäten. Dies bedeutet die Entwicklung von IT-Lösungen auf Basis des definierten Systementwicklungsprozesses im Rahmen der Leistungserbringung der IT-Organisation.214 Die in frühen Projektphasen vorgenommene Nutzenanalyse wird häufig unter dem Begriff der Business-Case-Analyse zusammengefasst. In Literatur und 212 Nach dem entwickelten Modell zum IT-Portfoliomanagement erfolgt die Definition von Leistungskategorien im Prozess IT-Projektportfolio-Management. Siehe dazu Abbildung 95. 213 Dient das Projekt der Entwicklung von IT-Lösungen bzw. IT-Systemen, so legt der Systementwicklungsprozess die im jeweiligen Abschnitt der Projektdurchführung durchzuführenden Aktivitäten und die dabei zu erarbeitenden Artefakte fest. 214 Je nach Sourcing-Strategie der Unternehmens-IT schließt dies den Bezug von Leistungen von externen Dienstleistern ein.

204

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

Methodenpaketen zum Projektmanagement - z. B. Prince2215 - finden sich unterschiedliche Definitionen des Begriffs Business-Case-Analyse. Verallgemeinernd kann Business-Case-Analyse als die systematische, betriebswirtschaftlich orientierte Nutzenbetrachtung und Rechtfertigung einer Investition – insbesondere im Rahmen eines Projektes – verstanden werden. Für die vorliegende Arbeit wird folgende Festlegung getroffen: Definition - Business-Case-Analyse Als Business-Case-Analyse wird die systematische, betriebswirtschaftlich orientierte Analyse der Wirkungen eines Projektes und der damit verbundenen Investitionen verstanden. Dies umfasst insbesondere die Analyse der finanziellen, aber auch der nicht finanziellen Wirkung des Projektes. Zu diesem Zweck werden finanzielle Größen über die Projektlaufzeit und über den gesamten Lebenszyklus der durch das Projekt aufgebauten IT-Lösungen ermittelt und in Beziehung zueinander gesetzt. Auf diese Weise wird die Wirtschaftlichkeit des Projektes bewertet und die Investition gerechtfertigt. Bei der Analyse der finanziellen Wirkung kommen Instrumente wie die Kapitalwertbetrachtungen der prognostizierten Zahlungsströme oder das EVA-Verfahren (economic value added)216 zur Anwendung. Um den Prozess der IT-Projektdurchführung um die Anforderungen eines Integrationsmanagements zu erweitern, wird das hier beschriebene Prozessmodell in zwei Punkten ergänzt.217 1.

2.

Die Business-Case-Analyse wird um die Analyse der Wirkung der Umsetzung der Leistungsanforderungen auf die Komplexität und die Reaktionsfähigkeit der Unternehmens-IT erweitert. Dabei wird auch die Komplexität der Integrationsanforderungen bewertet. Projektplanung und -controlling werden durch die Planung und Erfassung von Integrationsleistungen sowie von Leistungen für fachliche Anforderungen ergänzt.

215 Prince2: Projects in Controlled Environments; eine Projektmanagement-Methode für Organisation, Management und die Steuerung von Projekten. 216 Abschätzung des Wertzuwachses, der im Unternehmen durch eine Investition entsteht. 217 Die durch diese Ergänzung erforderlichen zusätzlichen Mess- und Bewertungsmethoden und Leistungskategorien werden wie oben beschrieben in den Prozessen des IT-Portfoliomanagements definiert.

4.5 Integrationsmanagement in Managementprozessen und operativen IT-Prozessen

205

Die Analyse der Wirkung des Projektes auf die Komplexität und die Reaktionsfähigkeit der Unternehmens-IT wird auf diese Weise zusammen mit der Bewertung der Anforderungskomplexität zum festen Bestandteilen der BusinessCase-Analyse und der darauf beruhenden Entscheidungen, die an den Punkten E1 bzw. E2 getroffen werden. Komplexität und Reaktionsfähigkeit werden somit zum Selektionskriterium von Leistungsanforderungen an die Unternehmens-IT. Die an den Entscheidungspunkten E1 und E2 vorliegenden Daten können als Grundlage einer verfeinerten IT-Projektportfoliosteuerung im IT-Portfoliomanagement eingesetzt werden. Die folgende Abbildung fasst das erweiterte Prozessmodell zur IT-Projektdurchführung zusammen. Die Erweiterung beruht auf folgenden Ergänzungen: ƒ

ƒ

Ergänzungen im Bereich der Planung von IT-Projekten (bis Entscheidungspunkt E2) o Bewertung der Wirkung der Umsetzung der Leistungsanforderungen auf die Komplexität und die Reaktionsfähigkeit der Unternehmens-IT o Aufwandsschätzung unter Berücksichtigung der Leistungskategorien Integrationsleistung und Leistung zur Umsetzung fachlicher Anforderungen o Bewertung der Komplexität der Integrationsanforderungen Ergänzungen im Bereich des Controllings von IT-Projekten (nach E2) o Aufwandserfassung in den definierten Leistungskategorien o Abgleich mit der vorgenommenen Planung insbesondere

Erweiterung / Erneuerung im Rahmen von IT-Projekten

Analyse der Idee

E1

Machbarkeitsanalyse

E2

Realisierung

E3

Überführung in Produktion

Prozess der Projektdurchführung Bewertung bzgl. Reaktionsfähigkeit

Bewertungen bzgl. Komplexität

Aufwandsschätzung (Kategorien)

Tatsächliche Wirkung

Bewertung & Planung Projekt

Erweitertes Projekt-Controlling

- Erweiterte Business Case Analyse -

Entscheidungspunkte der Projektdurchführung

Geleistete Aufwände Kategorien)

E1

Entscheidung über Weiterverfolgung der Idee unter Berücksichtigung der erwarteten Wirkung auf Komplexität und Reaktionsfähigkeit

E2

Entscheidung über Realisierung unter Berücksichtigung der erwarteten Wirkung auf Komplexität und Reaktionsfähigkeit

E3

Entscheidung über Produktivnahme unter Einbeziehung einer Risikobewertung

Abbildung 97: Erweitertes Modell der IT-Projektdurchführung

206

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

Abschließend wird eine Vorlage (Template) einer um Aspekte des Integrationsmanagements erweiterten Methode zur Business-Case-Analyse entworfen. In Abschnitt 3.2.1.4 wurde gezeigt218, dass bei der Analyse der Wirkung auf die Reaktionsfähigkeit und die Komplexität der Unternehmens-IT zwischen der kurzfristigen und der langfristigen Wirkung unterschieden werden muss, da im Zeitverlauf gegenläufige Wirkungen entstehen können. Dies ist in den vorgeschlagenen Erweiterungen der Business-Case-Analyse berücksichtigt. Das Modell sieht folgende Erweiterungen vor:219 ƒ

ƒ

ƒ

Die Aufwandsschätzung der IT-Lösung erfolgt nach erweiterten Leistungskategorien. Sie unterstützen die Unterscheidung von o Integrationsleistungen und o Leistungen zur Erfüllung fachlicher Anforderungen. Die Bewertung der Wirkung auf die Reaktionsfähigkeit wird berücksichtigt. Neben der o verbalen Zusammenfassung wird o eine qualitative Bewertung mittels Expertenschätzung vorgenommen. Die Wirkung auf die Komplexität der IT-Landschaft wird berücksichtigt. Neben der o zusammenfassenden Beschreibung und der o qualitativen Bewertung der Wirkung ist die o quantitative Bewertung vorgesehen, die auf der Kennzahl KITL zur Komplexität der IT-Landschaft und den darin enthaltenen Einzelgrößen basiert. Eine weitere Möglichkeit zur quantitativen Bewertung besteht darin, die für den Rückbau der durch die neue IT-Lösung verursachten zusätzlichen Komplexität notwendigen Investitionen zu schätzen und in die Barwertberechnung aufzunehmen. Auf diese Weise wird sichergestellt, dass Komplexität in die monetäre Bewertung einfließt.

Die folgende Abbildung fasst die entwickelte, erweiterte Methode zur Business-Case-Analyse zusammen.

218

Siehe Tabelle 3. Die Bewertung der Komplexität der Integrationsanforderungen ist für die Messung der Integrationseffizienz notwendig. In das Template zur Zusammenfassung der Business-Case-Analyse wird sie nicht aufgenommen, da für die Projektentscheidung nicht wesentlich. 219

4.5 Integrationsmanagement in Managementprozessen und operativen IT-Prozessen

207

Business Case Analyse Projektzielsetzung

Nutzenzusammenfassung

Aufwandsschätzung nach Leistungskategorien Gesamtaufwandschätzung

IntegrationsFachliche leistungen Anforderungen

Weitere Kategorien

Wirkung auf Reaktionsfähigkeit Zusammenfassung

Weitere – z.B. Projektrisiken

Wirtschaftlichkeit der Investition

Barwert

EVA

Andere Größen

kurzfristig

langfristig

Statisches Potential

Statisches Potential

Dynamisches Potential

Dynamisches Potential

Qualitative Bewertung der Wirkung

Komplexitätswirkung Zusammenfassung

ohne Berücksichtigung Komplexitätskosten kurzfristig Barwert

EVA

Andere Größen

mit Berücksichtigung Komplexitätskosten

langfristig

Qualitative Bewertung Quantitative Bewertung (e.g. Kosten der Komplexitätsbeseitigung)

Wirkungsanalyse für IT-Lösungen

Abbildung 98: Vorlage zur erweiterten Business-Case-Analyse 4.5.3 Zusammenfassung Mithilfe des erweiterten Prozessmodells zur IT-Projektdurchführung wird Integrationsmanagement auf der Ebene der operativen IT-Prozesse verankert. Auf diese Weise ist sichergestellt, dass die für eine übergreifende, kennzahlenbasierte Steuerung der Unternehmens-IT notwendigen Daten bei der Projektdurchführung erhoben und Kennzahlen wie die Integrationseffizienz und der Aufwandsquotient bestimmt werden können. Die Erweiterung der IT-Projektportfoliosteuerung auf Basis der Wirkungsanalyse von Projekten bzw. Investitionen in Bezug auf die Komplexität und die Reaktionsfähigkeit der Unternehmens-IT wird unterstützt. Durch die Antizipation der Komplexitätswirkung von IT-Projekten im ITPortfoliomanagement können darüber hinaus frühzeitig Optimierungsmaßnahmen für die Unternehmens-IT abgeleitet werden.

208

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

Abschließend fasst die folgende Abbildung das entwickelte, integrierte Modell zur Verzahnung der Management-Ebene und der operativen Ebene der ITProzesslandschaft zusammen. IT-Portfoliomanagement IT-ProjektportfolioManagement

IT-RessourcenPortfolio-Management

IS-PortfolioManagement

Infrastruktur-AssetManagement

Inventur

Aufwände? Wirkung auf Reaktionsfähigkeit

Monitoring & Bewertung

Integrationseffizienz?

Projektsicht

erwartete KomplexitätsWirkung?

Management von IT-Org. & IT-Landschaft

Erfassung der geschäftlichen Komplexität

Steuerung & Optimierung

Aufwandsquotient?

erwartete KomplexitätsVeränderung?

Optimierungsmaßnahmen

Portfoliosicht

Erweiterung/Erneuerung IT-ProjektDurchführung

Betrieb & WeiterEntwicklung IT-Landschaft

Wartung / Weiterentwicklung

Systementwicklungsprozess

je IT-Projekt

Bewertung & Planung Projekt

Erweitertes Projekt-Controlling

- Erweiterte Business Case Analyse -

Analyse der Idee

E1

Machbarkeitsanalyse

E2

Realisierung

E3

Überführung in Produktion

Abbildung 99: Gesamtmodell zur Erweiterung der Prozesse der operativen Ebene zur Bestimmung der Integrationseffizienz im IT-Portfoliomanagement

209

4.6 Ergänzende Leitlinien zur Organisation der IT-Landschaft

4.6 Ergänzende Leitlinien zur Organisation der IT-Landschaft In diesem Abschnitt wird der in der folgenden Abbildung hervorgehobene Teil des in Abschnitt 4.1 festgelegten Verfeinerungsbedarfs bearbeitet. 1

Entwicklung Referenzmodell zur IT-Prozesslandschaft 2

Definition eines Ansatzes zur IT-Unternehmensarchitektur 3

Integrationsmanagement in der strategischen Konzeption Einbettung Integrationsmanagement in der strategischen Konzeption Leistungsfähigkeit der Unternehmens-IT im Hinblick auf Integrationsleistungen

Komplexitätsmanagement

4

Entwicklung eines Kennzahlensystems 5

Integrationsmanagement und Planung & Controlling von IT-Projekten Selektion von Anforderungen unter Berücksichtigung von Komplexitätswirkung + Integrationsaufwänden

Steuerung unter Berücksichtigung von Komplexitätswirkung und Integrationsaufwänden

6

Verzahnung Gesamtsicht und IT-Projektsicht 7

Ergänzende Leitlinien zur Organisation IT-Landschaft

Gestaltung der ITLandschaft mit Hilfe von Komplexitätskennzahlen

Lebenszyklusmanagement von ITSystemen

IT-Landschaft und Adaptierbarkeit, Flexibilität & Agilität

8

Ganzheitliche Integrationslösungen und IT-Portfoliomanagement 9

Empfehlungen zur Steigerung der Integrationseffizienz der Unternehmens-IT

Abbildung 100: Ergänzende Leitlinien zur Organisation der IT-Landschaft Zunächst wird das Kennzahlensystem zur Komplexität der IT-Landschaft reflektiert und so Ergänzungen der vorliegenden Gestaltungsempfehlungen zum Komplexitätsmanagement hergeleitet. Dann werden detaillierte Überlegungen zum Lebenszyklusmanagement in der IT-Landschaft angestellt. Anschließend wird die proaktive Gestaltung von IT-Landschaften unter Berücksichtigung der Eigenschaften Adaptierbarkeit, Flexibilität und Agilität diskutiert und danach in Bezug auf M&A-Situationen interpretiert. Begleitet zur Bearbeitung dieser Punkte werden die definitorischen Grundlagen der vorliegenden Arbeit vervollständigt und Konzepte anderer Autoren integriert.

210

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

4.6.1 Reflexion des Kennzahlensystems zur Komplexität der IT-Landschaft Das Konzept zur Komplexität der IT-Landschaft Unternehmens-IT basiert auf einem systemtheoretisch geprägten Verständnis, das verschiedene Perspektiven der Komplexität berücksichtigt und daraus ein Bündel von Kennzahlen zur Komplexitätserfassung ableitet. Dies führt zur mehrdimensionalen Kennzahl KITL zur Komplexität der IT-Landschaft. Die Bestimmung von KITL stellt ein Instrument der Objektivierung dar, das jedoch nicht ohne die Subjektivität bewertender Individuen auskommt. Ein Teil der Komplexitätsmessung basiert auf der Wahrnehmung der die Komplexität der IT-Systeme, Informationsbeziehungen und Geschäftsprozesse bewertenden Individuen220. Ansätze wie die in Abschnitt 4.4.1.2.2 vorgestellte Methode der COMMERZBANK zur Bestimmung der Komplexität einzelner IT-Systeme reduzieren diese Subjektivität, ohne sie jedoch gänzlich zu eliminieren. Dieser Aspekt ist beim Management der Komplexität des Unternehmens zu berücksichtigen. Dies verdeutlichen die folgenden Abschnitte. 4.6.1.1 Betrachtungen zu adaptiven Geschäftsarchitekturen Wird die geschäftliche Komplexität wie vorgeschlagen über die Bewertung der Komplexität der Geschäftsprozesse durch die IT-Organisation gemessen, so ergibt sich aus den Ausführungen in Abschnitt 3.2.3 die Fragestellung nach dem Zusammenhang dieser Komplexität und dem Ansatz zur Gestaltung der Geschäftsarchitektur. In 3.2.3 wurde, ausgehend von RAMANATHANS Arbeit zu adaptiven Architekturen, die Gestaltungsempfehlung 3.1 erarbeitet. Wesentliches Merkmal adaptiver Geschäftsarchitekturen sind so genannte S-R-Geschäftsprozesse. 3.1 empfiehlt die Reduktion von Aufwänden für die Erbringung von Integrationsleistungen durch Komplexitätsreduktion mittels adaptiver Geschäftsarchitekturen. Die Zielsetzung besteht darin, mithilfe der Transformation statischer, auf eindimensionaler Modellierung beruhender Geschäftsarchitekturen hin zu adaptiven Geschäftsarchitekturen die Komplexität auf Seiten der Anwenderorganisation zu reduzieren. Gemäß der in 3.2.1.4 analysierten Korrelation (s. Abbildung 49) führt dies zu einer Komplexitätsreduktion auf Seiten der Unternehmens-IT. Wird die geschäftliche Komplexität, wie in der vorliegenden Arbeit vorgeschlagen,

220

Dies steht im Einklang mit der Forschungsposition der vorliegenden Arbeit, die von der Unmöglichkeit objektiven Erkennens ausgeht.

4.6 Ergänzende Leitlinien zur Organisation der IT-Landschaft

211

mithilfe der Kennzahl WK221 erfasst, so ist Gestaltungsempfehlung 3.1 zu reflektieren. WK stellt die summierte Bewertung der Komplexität der im Rahmen des Geschäftsprozessmanagements erfassten Geschäftsprozesse durch die ITOrganisation dar. Beruht die Geschäftsarchitektur des Unternehmens auf dem Ansatz der eindimensionalen Geschäftsprozessmodellierung, so liegen viele einzelne, jeweils statisch modellierte Prozesse vor. In WK ergibt sich daraus ein größerer Faktor N. Dem steht eine Geschäftsarchitektur gegenüber, die auf dem adaptiven S-R-Prozess beruht. Hier liegt eine geringere Zahl von Prozessen vor, wobei nach Einschätzung des Autors der vorliegenden Arbeit davon auszugehen ist, dass nicht alle eindimensionalen Prozesse auf einen einzigen S-R-Prozess abgebildet werden können, sondern bestimmte Bereiche der geschäftlichen Interaktionen eines Unternehmens jeweils durch einen adaptiven S-R-Prozess abgedeckt werden. Eine solche Gruppierung kann zum Beispiel entlang fachlicher Domänen vorgenommen werden. Grundlage hierfür bildet ein Domänenkonzept, wie es z. B. von DERN222 vorgeschlagen wird. Das würde z. B. bedeuten, die Domäne der Kreditabwicklung im Privatkundengeschäft eines Finanzdienstleiters durch einen adaptiven S-R-Kreditprozess abzubilden. In WK ergibt sich so aufgrund der geringeren Zahl von Prozessen ein kleinerer Wert für N, also scheinbar geringere Komplexität. Welcher Ansatz hier aus Sicht der Unternehmens-IT tatsächlich zu einer geringeren geschäftlichen Komplexität führt, hängt davon ab, wie die Komplexität der einzelnen Prozesse durch die IT-Organisation bewertet wird. Wird die Komplexität eines adaptiven S-R-Kreditabwicklungsprozesses als deutlich höher eingeschätzt als die summierte Komplexität mehrerer eindimensionaler Kreditabwicklungsprozesse, so kann dies bedeuten, dass die wahrgenommene Komplexität einer adaptiver Geschäftsarchitektur höher ist als diejenige einer auf eindimensionaler Prozessmodellierung beruhenden Geschäftsarchitektur. An dieser Stelle ist zu vermuten, dass die Fertigkeiten der Mitarbeiter der IT-Organisation im Umgang mit Komplexität auf der einen und die Geschäftskenntnisse dieser Mitarbeiter auf der anderen Seite wesentlich die wahrgenommene Komplexität bestimmen und dementsprechend höher entwickelte Fertigkeiten zu einer anderen Komplexitätseinschätzung führen. Es ist also anzunehmen, dass die wahrgenommene Komplexität im Kontext einer adaptiven Geschäftsarchitektur niedriger ausfällt als im Kontext einer auf eindimensionaler Modellierung beruhenden Geschäftsarchitektur, wenn die Mitarbeiter im Um-

221

N

WK =

෤ KU(G ) . i

i=1

222

Vgl. in [Dern09].

212

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

gang mit Komplexität und in Bezug auf das Geschäftswissen ein höheres Kompetenzniveau besitzen. Die Gestaltungsempfehlung 3.1 ist daher vor dem Hintergrund des in der folgenden Abbildung dargestellten Spannungsfeldes von Geschäftsarchitekturansatz und Fertigkeiten der IT-Organisation zu sehen. Die beschriebene Abwägung ist in der folgenden Abbildung zusammengefasst. Geschäftsarchitekturansatz

Wirktendenz Komplexität

Adaptive Geschäftsarchitektur

niedriger

Generischer Prozess 1

. . . Generischer Prozess N1

Anzahl der Prozesse stärker ausgeprägt

Einzelprozesskomplexität KU höher

N1 < N2 !!

. . . Eindimensionaler Prozess N2

Wahrgenommene Komplexität N

größer

1-dim. Geschäftsarchitektur Eindimensionaler Prozess 1

Fertigkeiten der Mitarbeiter

¦

KU (Gi)

Fähigkeit zum Umgang mit komplexen Systemen

i =1

Anzahl Prozesse

geringer ausgeprägt

Einzelprozesskomplexität KU geringer

Anwenderorganisation

IT-Organisation

Abbildung 101: Wahrgenommene Komplexität zwischen Geschäftsarchitekturansatz und Fertigkeiten der IT-Organisation Abgrenzung und Ansatzpunkte für ergänzende Forschungsaktivitäten – Geschäftliche Komplexität und Ansatz zur Gestaltung der Geschäftsarchitektur Vor dem Hintergrund dieser Überlegungen zur Gestaltungsempfehlung 3.1 ergeben sich Ansatzpunkte für weiterführende Forschungsaktivitäten, die Fragestellungen zu den Zusammenhängen zwischen der Komplexität der Geschäftsseite sowie dem gewählten Ansatz zur Gestaltung der Geschäftsarchitektur auf der einen und den Fertigkeiten der Mitarbeiter der IT-Organisation sowie der Komplexität der IT-Landschaft auf der anderen Seite in den Mittelpunkt stellen. 4.6.1.2 Subjektivität von Komplexität und Möglichkeiten der Komplexitätsreduktion In Abschnitt 3.2.1.4 werden Gestaltungsempfehlungen zur Komplexitätsreduktion entwickelt und in Tabelle 3 zusammengefasst. Das in Abschnitt 4.4 entwickelte Kennzahlensystem verhält sich konsistent zu diesen Gestaltungsempfehlungen. So wird in Tabelle 3 die Standardisierung der Elemente der Un-

4.6 Ergänzende Leitlinien zur Organisation der IT-Landschaft

213

ternehmens-IT empfohlen. Diese Wirkung manifestiert sich z. B. in der Kennzahl KB223 zur Komplexität der IT-Basisinfrastruktur. Die Standardisierung der Elemente der IT-Basisinfrastruktur führt zur Komplexitätsreduktion, da die in KB eingehenden Größen verringert werden. Gleiches gilt beispielsweise für die Reduktion der Komplexität der Gesamtheit der IT-Systeme. Unter dem Blickwinkel der diskutierten Subjektivität von Komplexität und der Rolle der Fertigkeiten der Mitarbeiter der IT-Organisation stellt sich folgende Frage: Verdeckt die Konzentration auf die Reduktion bzw. die Wachstumsbeschränkung der Vielfalt, der Anzahl und der Änderungsdynamik der Systemelemente der Unternehmens-IT weitere Ansatzpunkte eines aktiven Komplexitätsmanagements? Diese Ansatzpunkte ergeben sich daraus, dass in die Bewertung der Komplexität, wie oben dargestellt, die subjektive Sicht der bewertenden Individuen einfließt. Deutlich wird dies durch die angesprochenen Überlegungen zur wahrgenommenen Komplexität. Komplexität ist kein absolutes Problem, sondern ein Problem, das im Kontext der Subjektivität der wertenden Individuen mehr oder weniger stark ausgeprägt ist. Darüber hinaus ist - wie in Abschnitt 3.2.1 gezeigt - zu beachten, dass Komplexitätsreduktion immer im Kontext der notwendigen Reaktionsfähigkeit, d. h. des statischen und dynamischen Potenzials der Unternehmens-IT zu sehen ist. Aus diesen Betrachtungen folgt, dass Komplexitätsmanagement die Beeinflussung der Wahrnehmung der wertenden Individuen einschließen muss. Wird die Komplexität als weniger ausgeprägt wahrgenommen, führt dies zu einer tatsächlichen Reduktion der Komplexität. Somit ist die Frage zu stellen, welche Möglichkeiten bestehen, die Komplexität durch Einflussnahme auf die Mitarbeiter der IT-Organisation zu reduzieren. Wie bereits ausgeführt, ist ein zentraler Ansatzpunkt offenbar die Fähigkeit der Mitarbeiter zum Umgang mit Komplexität. Je ausgeprägter diese Fähigkeit ist, desto eher ist es möglich, zum einen a priori die Komplexität zu reduzieren und zum anderen Möglichkeiten zu schaffen, alternative Architekturansätze – wie adaptive Geschäftsarchitekturen – einzuführen und auf diese Weise das durch immer neue regulatorische und wettbewerbsbedingte Anforderungen verursachte Wachstum der Gesamtkomplexität in seiner Stärke zu begrenzen. Weitere Ansatzpunkte bietet die Verbesserung des Geschäftswissens in der IT-Organisation, da die geschäftliche Komplexität dadurch als geringer wahrgenommen wird. Darüber hinaus zieht verbessertes Geschäftswissen die Fähigkeit nach sich, unnötig redundante Implementierungen zu 223

1 N × ¦ [Ti × Ii ] N 1

N = Zahl der Basissystemtypen; Ti = Zahl der Technologieausprägungen für Basissystemtyp i, i=1,..N; Ii = Mittlere Zahl von Instanzen je Technologieausprägung des Basissystemtyps i.

214

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

vermeiden. Nur in Bezug auf die jeweilige fachliche Anforderung adäquates Geschäftswissen erlaubt es der IT-Organisation zu unterscheiden, ob eine fachliche Anforderung bzw. eine Integrationsanforderung neu implementiert werden muss oder durch die Anpassung bestehender Systeme bzw. Informationsbeziehungen abgebildet werden kann. Geht man von der Hypothese aus, dass die Reduktion der Vielfalt und der Anzahl sowie der Änderungsdynamik der Systemelemente der Unternehmens-IT nicht in dem Maße möglich ist, dass die durch immer neue Anforderungen verursachten Komplexitätszuwächse kompensiert werden können, so stellt sich die Frage, wie das Komplexitätsmanagement - als Bestandteil des ganzheitlichen Integrationsmanagements - und die damit einhergehenden Investitionen gesteuert werden sollten. Als Investitionsschwerpunkte sind hier ƒ ƒ ƒ

die Reduktion bzw. Wachstumsbeschränkung der Anzahl, Vielfalt und Änderungsdynamik224 der Systemelemente, die Fertigkeiten der Mitarbeiter der IT-Organisation im Umgang mit Komplexität und der Ausbau des Geschäftswissens zu nennen.

Aus den in Abschnitt 3.2.1 entwickelten Gestaltungsempfehlungen zum Komplexitätsmanagement und deren Verfeinerung im Rahmen des 4. Kapitels ergeben sich vier Handlungsfeldern zur Reduktion bzw. zur Wachstumsbegrenzung der Komplexität der IT-Landschaft: ƒ ƒ ƒ ƒ ƒ

Gestaltung der Nachfragerintegration mit der IT-Organisation entlang der IT-Wertschöpfungskette Reduktion bzw. die Wachstumsbegrenzung der Komplexität der ITLandschaft auf der Ebene der Systemelemente Verbesserung der Fertigkeiten der Mitarbeiter der IT-Organisation im Umgang mit komplexen Systemen Ausbau des Geschäftswissens der Mitarbeiter der IT-Organisation

Da die Komplexität der IT-Organisation und die der IT-Landschaft gemäß Abschnitt 4.4.1.1 positiv korreliert sind, wirken die genannten Handlungsfelder auch auf die Komplexität der IT-Organisation. Die nachstehende Abbildung fasst diese Überlegungen zum Management der Komplexität der Unternehmens-IT zusammen.

224

Etwa durch neue Ansätze zu Architekturen von IT-Systemen. Siehe dazu Abschnitt 3.2.1.4.

215

4.6 Ergänzende Leitlinien zur Organisation der IT-Landschaft

Management der Unternehmens-IT Teildisziplin Integrationsmanagement

Teildisziplin Komplexitätsmanagement Handlungsfeld Nachfragerintegration in die IT-Wertschöpfungskette

Handlungsfeld Reduktion / Wachstumsbegrenzung Elemente der IT-Landschaft

IT-Landschaft

Handlungsfeld Verbesserung Fertigkeiten im Umgang mit Komplexität

Komplexitätskorrelation

IT-Organisation

Komplexitätskorrelation

Komplexitätskorrelation

Zielsetzung Sicherstellung des informations-wirtschaftlichen Gleichgewichtes

Handlungsfeld Ausbau Geschäftswissen

Anwenderorganisation

Abbildung 102: Schwerpunkte des Komplexitätsmanagements Geht man von den auf MALIK zurückgehenden, in Abschnitt 2.2.2 aufgeführten Leitlinien für das Unternehmensmanagement aus, welche u. a. besagen, dass das System Unternehmen über eigene Gestaltungskräfte verfügt und dass das Management deshalb auf die Optimierung der Reaktionsfähigkeit, Lernfähigkeit, Organisierbarkeit des Unternehmens auszurichten ist, so wird hier die Hypothese aufgestellt, dass Investitionen in die Fertigkeiten der Mitarbeiter der IT-Organisation im Rahmen der in der strategischen Konzeption225 der Unternehmens-IT definierten Ziele im Vordergrund stehen sollten. Hier sollte die Begrenzung des Komplexitätswachstums der IT-Landschaft - verursacht durch die zunehmende Ausdifferenzierung des Systems in der Folge neuer geschäftlicher Anforderungen - im Vordergrund stehen. Eine signifikante Reduktion der Komplexität setzt aktive, von außen initiierte Eingriffe in das System Unternehmens-IT voraus, da nach Erfahrung des Autors der vorliegenden Arbeit das Komplexitätswachstum im Rahmen dieser Ausdifferenzierung in kleineren Schritten, gewissermaßen unsichtbar erfolgt226, die in der Summe signifikante Komplexitätssteigerungen bewirken, die nach Erfahrung des Autors der vorlie225 226

Siehe dazu Abschnitt 4.3. Vgl. [CoBa09].

216

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

genden Arbeit das System Unternehmens-IT aus sich heraus häufig nicht mehr zurückführen kann. Beispiele, die diese Sicht belegen, sind das in Abschnitt 4.4.1.2 beschriebene Projekt der COMMERZBANK und das in 5.3.2.2 beschriebene Programm zur Data-Warehouse-Konsolidierung der SEB GRUPPE. Hier ergeben sich Ansatzpunkte für weitere Forschungsaktivitäten. 4.6.1.3 Unternehmensübergreifender Vergleich von Komplexität Nach Beobachtung des Autors der vorliegenden Arbeit gewinnt das Thema Komplexitätsmanagement z. Zt. in der Unternehmens-IT größerer Unternehmen an Bedeutung. Vor diesem Hintergrund ist zu erwarten, dass Versuche unternommen werden, die Komplexität der Unternehmens-IT verschiedener Unternehmen miteinander zu vergleichen. Da nach den o. a. Betrachtungen Komplexität wahrnehmungsabhängige und -unabhängige Elemente umfasst und da, wie in 3.2.1.3 gezeigt, Komplexität im Kontext des jeweils angestrebten dynamischen bzw. statischen Potenzials, also der Reaktionsfähigkeit, zu sehen ist, sind solche Versuche in ihrer Aussagefähigkeit zu prüfen. Die Einschätzung der Komplexität der Unternehmens-IT ist immer im Kontext des in der folgenden Abbildung dargestellten Spannungsfeldes zu sehen - im Mittelpunkt steht die für ein bestimmtes Unternehmen angemessene Komplexität seiner Unternehmens-IT. angestrebte Reaktionsfähigkeit

Komplexität der Unternehmens-IT wahrnehmungsabhängiger Teil der Komplexität

wahrnehmungsunabhängiger Teil der Komplexität

Abbildung 103: Balancedreieck zur Komplexität der Unternehmens-IT 4.6.1.4 Grenzen des vorliegenden Komplexitätsmodells Wie in Abschnitt 4.4.1 gezeigt wurde, kann die Komplexität der IT-Landschaft nur indirekt gemessen werden. Daher können Kennzahlen nur bestimmte Aspekte der Komplexität der IT-Landschaft erfassen, d.h. die Komplexität in ihrer Gesamtheit wird dabei nicht abgebildet. Diese Beschränkung gilt auch für die auf der Grundlage des Komplexitätsmodells der vorliegenden Arbeit entwickelte

4.6 Ergänzende Leitlinien zur Organisation der IT-Landschaft

217

mehrdimensionale Kennzahl KITL. Im Folgenden werden Grenzen des Komplexitätsmodells betrachtet, indem die in KITL enthaltenen Einzelgrößen diskutiert werden. Dazu wird für die Einzelgrößen jeweils eine Extremposition formuliert und interpretiert. Diese Interpretation zeigt die Beschränkungen des Kennzahlensystems bezüglich der Herleitung von Gestaltungsempfehlungen zur ITLandschaft auf. MKX – mittlere Komplexität der IT-Systeme Für die in KITL enthaltene Größe MKX zur mittleren Komplexität der IT-Systeme ergibt sich aus der o. a. Fragestellung die Leitlinie, die Informationsarchitektur und die IT-Architekturen der enthaltenen Systeme so zu gestalten, dass Leistungsanforderungen möglichst innerhalb bestehender IT-Systeme abgebildet werden können, und für den Fall, dass die dadurch hervorgerufene Komplexitätssteigerung signifikant ist, die Anforderung mithilfe eines neuen Systems zu erfüllen. Im Sinne einer Extremposition bedeutet diese Leitlinie die Empfehlung, Leistungsanforderungen immer dann, wenn deren Umsetzung in einem bestehenden IT-System zur Steigerung der Komplexität dieses Systems führt, durch neue IT-Systeme umzusetzen, deren mittlere Komplexität unterhalb der MKX liegt. Dies führt zur Forderung nach möglichst vielen einfachen Systemen, da die MKX so niedrig gehalten wird. Diese Extremposition führt jedoch zur Maximierung der Komplexität der Gesamtheit der IT-Systeme KGI. Die Analyse der Komplexitätsfalle in Abschnitt 3.2.1.3 zeigt darüber hinaus, dass ein solcher Ansatz in Bezug auf das dynamische Potenzial der IT-Landschaft problematisch ist. MKZ – mittlere Kompliziertheit der IT-Systeme In Bezug auf die in KITL enthaltene Größe MKZ zur mittleren Kompliziertheit der IT-Systeme ergibt sich aus der o. a. Fragestellung die Leitlinie, IT-Architekturen von Systemen so zu gestalten, dass die nicht auf Anforderungen der Anwenderorganisation zurückzuführende Komplexität für jedes System möglichst gering ist. Im Sinne einer Extremposition kann aus dieser Leitlinie die Empfehlung abgeleitet werden, die IT-Architektur – insbesondere die Softwarearchitektur227 sowie das Softwaredesign und die Programmierartefakte der IT-Systeme einer IT-Landschaft so stark zu standardisieren, dass Anforderungen der Anwenderor227

Nach DERN (vgl. [Dern09], S. 92 ff.) umfasst die IS-Architektur u. a. die Software-Architektur, das heißt die Grundstruktur der verwendeten bzw. geplanten Softwarebausteine des betrachteten Systems.

218

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

ganisation durch Generierung umgesetzt werden können. So besteht keine Möglichkeit, unerwünschte Kompliziertheit, die nicht auf die gewählte Standardisierung zurückzuführen ist, in Systemen zu implementieren. Ein solches, auf möglichst weitgehender Generierung beruhendes Systementwicklungsparadigma ist ebenfalls in Bezug auf die Reaktionsfähigkeit der IT-Landschaft zu diskutieren. Tendenziell wird sich das dynamische Potenzial, also die Fähigkeit, rechtzeitig auf Umweltänderungen zu reagieren, erhöhen und das statische Potenzial reduzieren, da nutzbare Technologien eingeschränkt werden.228 KGI – Komplexität der Gesamtheit der IT-Systeme Hinsichtlich der in KITL enthaltenen Größe KGI229 zur Komplexität der Gesamtheit der IT-Systeme ergibt sich aus der Analyse der obigen Fragestellung die Leitlinie, die Informationsarchitektur und die IT-Architekturen230 der Einzelsysteme so zu gestalten, dass ƒ ƒ

fachliche Anforderungen innerhalb bestehender IT-Systeme abgebildet werden können – dadurch wird die Zahl neuer IT-Systeme möglichst gering gehalten - und Integrationsanforderungen231 unter Vermeidung neuer Informationsflüsse abgedeckt werden können – dadurch wird die Zahl neuer Informationsflüsse je IT-System möglichst gering gehalten.

Diese Extremposition bedeutet, die IT-Landschaft so zu gestalten, dass genau ein IT-System alle Anforderungen abdeckt (N=1), somit genau ein Anwendungstyp vorliegt (AT=1) und die Zahl M1 eingehender bzw. ausgehender Informationsflüsse zur/von der Unternehmensumwelt mithilfe breiter generischer 228 Der Autor der vorliegenden Arbeit war 1994-95 als Mitarbeiter der R+V Versicherungsgruppe verantwortlich für die Einführung einer Softwareproduktionsumgebung, die ein solches Paradigma unterstützt. Die Erfahrungen bei dieser Einführung und der späteren Nutzung bestätigen diese Einschätzung. Das dynamische Potenzial wurde erheblich verbessert. Aufgrund der Einschränkungen des statischen Potenzials war das Einsatzspektrum beschränkt. 229

1

KGI = $7 × ¦ 0L , .d. h. mit der Zahl der Anwendungstypen gewichtete Summation der bewerL =

teten Informationsbeziehungen. 230 Zum Verständnis Informationsarchitektur und IS-Architekturen siehe Abschnitt 4.2.3. 231 Nach dem begrifflichen Fundament der vorliegenden Arbeit erzeugen Leistungsanforderungen, die auf Veränderungen des Informationsbedarfs der Anwenderorganisation zurückgehen, zum einen Integrationsanforderungen – z. B. Lieferung aller risikotragenden Positionen zu einem neuen Finanzinstrument an die Risikosysteme eines Kreditinstituts. Zum anderen erzeugen sie fachliche Anforderungen i. e. S, die durch die Bereitstellung neuer fachlicher Leistungsmerkmale erfüllt werden – z. B. Erweiterung der Cashflow-Berechnung in den Risikosystemen des Kreditinstituts auf Basis der zusätzlich gelieferten Risikopositionen.

4.6 Ergänzende Leitlinien zur Organisation der IT-Landschaft

219

Schnittstellen, die den gesamten jeweiligen Informationsbedarf abdecken, minimiert wird. Dies führt zur Extremforderung nach genau einem allumfassenden monolithischen IT-System. Diese Extremposition führt jedoch zur Maximierung der mittleren Komplexität MKX. Zudem ist ein solches allumfassendes System in Bezug auf die Beherrschbarkeit und die Reaktionsfähigkeit offensichtlich nicht erstrebenswert. KB – Komplexität der IT-Basisinfrastruktur In Bezug auf die in KITL enthaltene Komplexität der IT-Basisinfrastruktur ergibt sich aus der o. a. Fragestellung die Leitlinie, die Infrastrukturarchitektur so zu gestalten, dass die Gesamtheit der nicht-funktionalen Anforderungen durch eine möglichst niedrige Zahl von Basissystemtypen (e. g. DBMS) mit möglichst wenigen Technologieausprägungen (e. g. nur DB2V9) und möglichst wenigen Instanzen (e. g. maximal 1 Instanz je Teststufe) abgedeckt werden kann. Als Extremposition bedeutet diese Leitlinie die Empfehlung, je Basissystemtyp genau eine Technologieausprägung und genau eine Instanz zuzulassen. Dies führt zur Forderung nach einer allumfassenden Basisplattform, also nach einem Mainframe, der alle notwendigen Infrastrukturkomponenten in sich vereint. Auch hier ergibt sich die Problematik der Einschränkung der Reaktionsfähigkeit und der Beherrschbarkeit. Interpretation Die zu den in KITL enthaltenen Einzelgrößen diskutierten Leitlinien und die damit verbundenen Extrempositionen verdeutlichen die Grenzen des Komplexitätsmodells der vorliegenden Arbeit, da diese Leitlinien z. T. orthogonal zueinander stehen – die Anwendung einer Leitlinie führt zur Minimierung der zugehörigen Einzelgröße, erhöht jedoch den Wert einer anderen Größe. Bereits in Abschnitt 3.2.1 wurde gezeigt, dass die Komplexität der Unternehmens-IT immer unter Berücksichtigung des angestrebten statischen und dynamischen Potenzials zu beurteilen ist. Die beschriebenen Extrempositionen unterstreichen dies, da sie – wie im Falle des allumfassenden monolithischen ITSystems – u. a. den unerwünschten Nebeneffekt der übermäßigen Einschränkung des dynamische Potenzials nach sich ziehen können. Dies zeigt die Notwendigkeit, die Grenzen einer Komplexitätskennzahl wie KITL beim Komplexitätsmanagement im jeweiligen Unternehmenskontext zu erkennen und daran gebundene Entscheidungsprozesse entsprechend zu reflektieren. Die folgende Abbildung fasst das Spannungsfeld zur Angemessenheit der Komplexität der IT-Landschaft zusammen.

220

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

große Zahl an Einzelsystemen mit jeweils minimaler Komplexität

genau ein System – der Ultimative Monolith

angemessene Komplexität der ITLandschaft

die Ultimative Basisplattform mit genau einer Instanz, auf der alle IT-Lösungen betrieben werden

SoftwareGenerierung mit dem Ziel maximaler Standardisierung

Abbildung 104: Angemessene Komplexität der IT-Landschaft vs. Extrempositionen 4.6.2 Lebenszyklusmanagement in der IT-Landschaft 4.6.2.1 Lebenszyklus und Komplexität von IT-Systemen Betrachtet man die Komplexität der IT-Landschaft aus Sicht zukünftiger Leistungsanforderungen, so ergibt sich die Frage, in welcher Beziehung die Komplexität und die fortlaufende Weiterentwicklung eines IT-Systems zueinander stehen. Um diese Zusammenhang herauszuarbeiten, wird ein Lebenszyklusmodell entworfen. Die Komplexität einzelner IT-Systeme variiert zwischen der Produktivnahme und der Abschaltung bzw. dem Austausch des Systems, d. h. entlang des Systemlebenszyklus. Durch die Analyse von Lebenszyklusverläufen von ITSystemen können ein Lebenszyklusmodell zum Komplexitätsmanagement beschrieben und ergänzende Leitlinien232 für das Komplexitätsmanagement formuliert werden. Nach Erfahrung des Autors der vorliegenden Arbeit kann das zeitliche Muster der Veränderung der Komplexität eines IT-Systems mithilfe des Phasenkonzeptes charakterisiert werden, das in Abbildung 105 dargestellt ist:

232 Diese Leitlinien sind nach dem Verständnis der vorliegenden Arbeit und dem entwickelten Modell der IT-Prozesslandschaft innerhalb der Prozesse des IT-Portfoliomanagements und der Weiterentwicklung/Erneuerung von IT-Systemen zu berücksichtigen.

4.6 Ergänzende Leitlinien zur Organisation der IT-Landschaft

ƒ

ƒ

ƒ

ƒ

233

221

Phase 1 – Systemreifung nach Produktivnahme und Komplexitätsabnahme Zum Zeitpunkt t0 der Produktivnahme weist das System eine bestimmte Ausgangskomplexität K0 auf, die je nach implementierten Leistungsanforderungen und je nach Qualität der Implementierung (Kompliziertheit) höher oder niedriger ausfällt. Zunächst nimmt die Komplexität des Systems überproportional ab. Dies ist folgendermaßen zu begründen: Der wahrnehmungsabhängige Anteil der Komplexität wird reduziert durch zunehmende Erfahrung und Versiertheit der Mitarbeiter im Umgang mit diesem System. Diese Reduktion überkompensiert den durch neue Leistungsanforderungen verursachten Komplexitätsanstieg. Teilweise ist mit diesem Gewinn an Erfahrung und Fertigkeiten eine Reduktion der Komplexität des Systems verbunden, da zu Beginn des Lebenszyklus Qualitätsverbesserungen des Systems vorgenommen werden, die die zum Zeitpunkt der Produktivnahme vorliegende Kompliziertheit – die häufig dem Termindruck des Implementierungsprojektes geschuldet ist - zunächst verringert. Phase 2 – Komplexitätsstabilität Die Stärke der Komplexitätsreduktion geht gegen null. Das System erreicht ein lokales Komplexitätsminimum Kmin, welches zum Zeitpunkt tmin erreicht wird. Zusätzliche Leistungsanforderungen führen zu unterproportionalem Komplexitätsanstieg. Phase 3 – Überproportionale Komplexitätszunahme Durch die Implementierung zusätzlicher Leistungsanforderungen beschleunigt sich das Komplexitätswachstum des Systems. Dies ist darauf zurückzuführen, dass die wahrnehmungsunabhängige Komplexität des Systems aufgrund größeren Leistungsumfangs und aufgrund zunehmender Kompliziertheit steigt und gleichzeitig die wahrnehmungsabhängige Komplexität zunimmt, da sich die Einschätzung des Systems durch Mitarbeiter der Betreuungsorganisation verändert. Dies ist insbesondere dann der Fall, wenn Mitarbeiter, die die ursprüngliche Philosophie und Architektur des Systems geprägt haben, die Betreuungsorganisation verlassen bzw. dies in Kürze zu tun beabsichtigen233 - in diesem Fall kommt es z. B. zum Zeitpunkt t1 zu einem Komplexitätssprung. Phase 4 – Verlust der Beherrschbarkeit Das System wird aufgrund deutlich gestiegener Komplexität als Problemfall wahrgenommen. Der Austausch bzw. die Erneuerung des Systems werden erwogen, da es als nicht mehr beherrschbar und als Risiko für das Unter-

Was ohne Veränderung am System zu einem Komplexitätssprung führen kann.

222

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

nehmen eingeschätzt wird. Die Reaktionsfähigkeit des Unternehmens ist wegen des erreichten Komplexitätsniveaus gefährdet. Komplexität eines IT-Systems Phase 1

Phase 2

Phase 3

Phase 4

Komplexitätswachstum

Verlust der Beherrschbarkeit

K0 Komplexitätssprung

Kmin Komplexitätsreduktion

t0

Komplexitätsstabilität

tmin

t1

Zeit

Abbildung 105: Komplexität und Systemlebenszyklus Aus dem dargestellten Lebenszyklusverlauf ergeben sich folgende Überlegungen: ƒ

ƒ

Befindet sich das IT-System in Phase 4, ist die Wahrscheinlichkeit hoch, dass der Zeitpunkt überschritten ist, bis zu dem die Systemkomplexität durch Maßnahmen wie Codeoptimierungen signifikant reduziert werden kann. Für Systeme in Phase 4 besteht das Risiko von Fehlinvestitionen in Optimierungsmaßnahmen.

Da die Komplexität der IT-Landschaft wesentlich durch die Komplexität der sie konstituierenden IT-Systeme bestimmt wird, können aus dem dargestellten Lebenszyklusmodell in Bezug auf die eingangs formulierte Frage zur Begrenzung des Komplexitätswachstums aufgrund zukünftiger Leistungsanforderungen die folgenden ergänzenden Leitlinien hergeleitet werden: ƒ ƒ ƒ

Das IS-Portfoliomanagement sollte durch die Bewertung und Steuerung von IT-Systemen nach den vier Phasen des Komplexitätslebenszyklus ergänzt werden. Größere Restrukturierungsinvestitionen sollten für Systeme vermieden werden, die sich bereits in Phase 4 befinden. Investitionen in die Reduktion der Systemkomplexität sollten in Phase 2 und 3 so geplant werden, dass der Eintritt in die Phase 4 des überproportio-

4.6 Ergänzende Leitlinien zur Organisation der IT-Landschaft

223

nalen Komplexitätswachstums verhindert wird.234 Dies umfasst Investitionen zur Verbesserung der Fertigkeiten im Umgang mit der Komplexität des jeweiligen Systems und des Geschäftswissens über die fachlichen Domänen, die durch das System adressiert werden. 4.6.2.2 Entwicklung von IT-Systemen als Theoriebildung In diesem Abschnitt werden die im letzten Abschnitt entwickelten Leitlinien mit NAURS Konzept Programming as Theory Building verbunden. NAUR wurde bekannt als Autor der Backus-Naur-Form zur Syntaxnotation von Programmiersprachen. In seinem Werk Computing: A Human Activity235 stellt NAUR dem verbreiteten Verständnis, dass Systementwicklung gleichbedeutend mit der Produktion von Programmcodes sei, sein Konzept Programming as Theory Building gegenüber. Das Konzept basiert auf NAURS Beobachtung, dass fortlaufende Anpassungen und Ergänzungen von produktiven IT-Systemen zu unbeherrschbaren Systemen führen, wenn sie in einem Umfeld vorgenommen werden, in dem die kognitive Haltung dominiert, dass Systementwicklung gleichbedeutend mit der Produktion von Programmcode sei. In der NAURSCHEN Theorie wird Programmierung im Sinne des Entwurfs, des Designs und der Entwicklung einer Software-basierten Lösung verstanden, die einen Ausschnitt der realen Welt und dort stattfindende Interaktionen repräsentiert und unterstützt. Der Begriff des Programms wird von N AUR analog zum Verständnis des Begriffes IT-System in der vorliegenden Arbeit verwendet. NAURS Programming as Theory Building versteht Systementwicklung als die Entwicklung eine Theorie darüber, wie der relevante Ausschnitt der realen Welt auf die Softwarebausteine eines IT-Systems abgebildet wird, welche Philosophie dieser Abbildung zugrunde liegt und wie diese Philosophie in der Struktur des Systems zum Ausdruck kommt. Ein zentraler Aspekt der Systementwicklung besteht darin, dass die mit der Systementwicklung beauftragte Gruppe von Menschen diese Theorie entwickelt und umsetzt. NAURS Programming as Theory wird von COCKBURN in Agile Software Development236 aufgegriffen. Für COCKBURN bedeutet Programming as Theory die Interpretation und die Abbildung von Aspekten der realen Welt durch Analytiker, Designer und Entwickler auf die formale Sprache einer Software. Die (Weiter-) Entwicklung eines IT-Systems bedeutet demnach die fortlaufende Adaption der Software an Veränderungen des auf die Software abgebildeten 234 Eine solche Priorisierung muss darüber hinaus auf Faktoren wie der Bedeutung des Systems für das Unternehmen beruhen. 235 Vgl. [Naur91]. 236 Vgl. [Cock06].

224

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

Ausschnittes der realen Welt. COCKBURN schärft dieses Verständnis, indem er den Zustand beschreibt, wenn ein Team die Theorie des Systems beherrscht. Dies ist dann der Fall, wenn das Team ƒ ƒ

ƒ

erklären kann, in welcher Beziehung zur realen Welt das System steht und wie es hilft, Interaktionen der realen Welt durchzuführen, erklären kann, warum die Bausteine des Systems so sind, wie sie sind, also welche Philosophie, Architektur und Design-Regeln der Abbildung des relevanten Ausschnittes der realen Welt auf die Bausteine der Software zugrunde liegen, konstruktiv auf jede Art von Anpassungsanforderung antworten kann, was sich danach bemisst, inwieweit das Team in der Lage ist, Ähnlichkeiten zwischen neuen Anforderungen aus der realen Welt und den bereits im System implementierten Anforderungen zu erkennen und diese neuen Anforderungen im Kontext der Grundphilosophie, der Architektur und der DesignRegeln des Systems und unter Berücksichtigung der identifizierten Ähnlichkeiten zu implementieren.

Zusammengefasst bedeutet NAURS Programming as Theory Building, dass ein essenzieller Baustein von IT-Systemen – seine Theorie – untrennbar an die das System entwickelnden bzw. betreuenden Menschen gebunden ist und sich damit einer streng formalen Beschreibung entzieht. COCKBURN analysiert auf der Grundlage dieser Überlegungen Fragen des Zustandes von IT-Systemen mit Blick auf deren Erneuerung oder Sterben (death), diskutiert also Fragen zum Lebenszyklus von IT-Systemen. Folgende Kernaussagen können aus seinen Überlegungen extrahiert werden: ƒ ƒ ƒ

ƒ

Das primäre Ergebnis der Entwicklung eines IT-Systems ist seine Theorie. Systementwicklung bedeutet Theoriebildung durch Menschen. Der Zustand eines IT-Systems bemisst sich insbesondere danach, inwieweit das Team die Theorie des Systems beherrscht. Das IT-System ist beherrschbar, wenn ein Team existiert, das die Theorie beherrscht. Ein IT-System stirbt, wenn das Team sich so ändert, dass es die Theorie des Systems nicht mehr beherrscht. Ein totes IT-System kann sich dennoch im lauffähigen Zustand befinden und für die Anwenderorganisation sinnvolle Resultate produzieren. Der Zustand des toten IT-Systems wird sichtbar, wenn neue Leistungsanforderungen an das IT-System nicht mehr konstruktiv beantwortet werden können. Ein gerade eingeführtes IT-System kann ein totes System sein.

4.6 Ergänzende Leitlinien zur Organisation der IT-Landschaft

ƒ ƒ

ƒ ƒ

ƒ ƒ

ƒ

225

Die erfolgreiche Einführung eines Systems ist gegeben, wenn die Theorie durch die betreuende Organisation beherrscht wird. Um zu verhindern, dass ein System zum toten System mutiert, muss sichergestellt sein, dass bei Veränderungen des betreuenden Teams durch den unmittelbaren Austausch zwischen neuen Mitarbeitern und mit dem System vertrauten Mitarbeitern die Theorie des Systems weitergegeben wird. Systemerneuerung auf Basis von Dokumentation ist nicht möglich. Sind keine Mitarbeiter mehr verfügbar, die die Theorie des Systems beherrschen, so ist die Erneuerung des Systems schwieriger und kostenintensiver als eine Neuentwicklung. Die Neuentwicklung ist hier vor allem deshalb zu bevorzugen, weil ein System entsteht, dessen Theorie beherrscht wird. Systementwicklung ist Theoriebildung von Individuen. Die Forderung nach dem Einsatz vollständig standardisierter Methoden und Vorgehensweisen bei der Systementwicklung ist daher irreführend. Forderungen der industriellen Produktion von IT-Systemen basieren auf einem falschen Grundverständnis von Systementwicklung, da sie von der Vorstellung ausgehen, Systementwicklung sei gleichbedeutend mit der Produktion von Programmcodes. Auslagerung (Outsourcing) der Entwicklung eines IT-Systems kann nur erfolgreich sein, wenn sichergestellt ist, dass die Theorie des Systems nach Produktivnahme beherrscht wird.

Aus NAURS Arbeit folgt, dass sich wesentliche Bestandteile von ITSystemen einer formalen Beschreibung entziehen. Dies gilt ebenso für die ITLandschaft, da sie sich aus den IT-Systemen, den Informationsbeziehungen und der zugrunde liegende IT-Basisinfrastruktur konstituiert. Versuchen, die ITLandschaft durch eine umfassende Beschreibung der Systeme und ihrer Interaktionen mithilfe einer EAM-Lösung zu kontrollieren und zu steuern, sind daher Grenzen gesetzt. Dies wird durch das Varietätsgesetz von Ashby untermauert, das von MALIK so gedeutet wird, dass die vollständige Kontrolle eines komplexen Systems ein Kontrollsystem erfordert, das eine vergleichbare Komplexität aufweist.237

237 Vgl. dazu [Malik08], S. 92. Die Allgemeingültigkeit dieser Interpretation von MALIK ist insofern zu hinterfragen, als das Varietätsgesetz – genauer: das Gesetz von der erforderlichen Varietät – besagt, dass ein System, das ein anderes steuert, umso mehr Störungen in dem Steuerungsprozess ausgleichen kann, je größer seine Handlungsvarietät ist. Nach diesem, erstmals von ASHBY (vgl. [Ashby56]) beschriebenen zentralen Gesetz der Kybernetik handelt es sich um eine hinreichende, nicht jedoch notwendige Bedingung.

226

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

Zusammenfassung Im vorherigen Abschnitt wurde ein Modell zum Komplexitätslebenszyklus von IT-Systemen entwickelt. Aus der vorgenommenen Analyse der Theorie von NAUR können die folgenden ergänzenden Aussagen abgeleitet werden: ƒ ƒ

ƒ

Werden zusätzliche Leistungsanforderungen an ein produktives IT-Systems so durchgeführt, dass dessen Theorie verletzt wird, steigert dies die Komplexität, da die Kompliziertheit des IT-Systems erhöht wird. Der Komplexitätsanstieg eines IT-Systems nimmt zu, wenn die Theorie des IT-Systems verloren geht. Dies ist gleichbedeutend mit dem Verlust der Beherrschbarkeit und bedeutet den Eintritt in Phase 4 des beschriebenen Lebenszyklusmodells. Geht die Theorie eines IT-Systems verloren, so sind Codeoptimierungen u. ä. Maßnahmen zur Reduktion der Komplexität des Systems nicht zielführend, da nicht klar ist, wie die Grundphilosophie, die Architektur und die Design-Regeln des IT-Systems durch diese Optimierung verändert werden. Zur Reduktion der Komplexität des IT-Systems ist die Rückgewinnung der Theorie nötig. In der Regel ist eine Neuentwicklung bei Verlust der Theorie sinnvoller.

Die im vorherigen Abschnitt aufgestellten ergänzenden Leitlinien zur Begrenzung des Komplexitätswachstums aufgrund zukünftiger Leistungsanforderungen können somit folgendermaßen erweitert werden: ƒ

ƒ

Der Prozess IS-Portfoliomanagement sollte die systematische Einordnung von IT-Systemen in ihren Komplexitätslebenszyklus beinhalten. Daraus können IT-Projektkandidaten abgeleitet werden, um so dem Übergang in Phase 4 bzw. dem Verlust der Beherrschbarkeit von IT-Systemen rechtzeitig zu begegnen.238 Die Projektkandidaten werden im Prozess der ITProjektdurchführung bearbeitet. Im Rahmen der Prozesse der Erweiterung/Erneuerung sollte sichergestellt werden, dass Anforderungen nicht theorieverletzend umgesetzt werden. Das Lebenszyklusmanagement von IT-Systemen als Teil der Prozesse der Er-

238 Nach dem Referenzmodell zur IT-Prozesslandschaft umfasst der Prozess IT-Portfoliomanagement die Schritte Inventur, Monitoring & Bewertung, Steuerung & Optimierung jeweils für die enthaltenen Teilportfolien. Die empfohlene Erweiterung betrifft das IS-Portfolio und das IT-Projektportfolio; letzteres in Bezug auf die Aufstellung von IT-Projektkandidaten.

4.6 Ergänzende Leitlinien zur Organisation der IT-Landschaft

ƒ ƒ

227

weiterung/Erneuerung sollte sicherstellen, dass das betreuende Team die Theorie des IT-Systems beherrscht.239 Der Systementwicklungsprozess sollte so ausgestaltet werden, dass die Theoriebildung unterstützt wird.240 Die Weitergabe der Theorie eines Systems muss bei der Übergabe eines Systems in die Linienorganisation sichergestellt werden. Abgrenzung und Ansatzpunkte für ergänzende Forschungsaktivitäten – Erweitertes Verständnis von IT-Systemen Die Ausführungen zur Komplexität und hier insbesondere auch die Theorie der Systementwicklung als Theoriebildung von NAUR führen zu der Frage, ob die Definition des Begriffes IT-System, wie sie in der vorliegenden Arbeit getroffen wurde und wie sie auch in der Praxis verbreitet ist, zu eng gefasst ist. Denn diese Definition begreift ein ITSystem als die durch den gemeinsamen Zweck abgegrenzte Menge miteinander interagierender Softwarebausteine. Ein verändertes Verständnis von IT-Systemen würde die das IT-System entwickelnden und betreuenden Personen einbeziehen. Ein solches Verständnis würde Fragen der Integration, Fragen der Komplexität usw. stets aus dem Blickwinkel der Softwarebausteine und der sie betreuenden Gruppe behandeln.

4.6.3 Adaptierbarkeit, Flexibilität, Agilität und proaktive Gestaltung von ITLandschaften Die im Verfeinerungsbedarf formulierte Forderung nach ergänzenden Leitlinien zur Adaptierbarkeit, Flexibilität und Agilität von IT-Systemen im Kontext zukünftiger Leistungsanforderungen wird durch folgende Fragestellung geschärft:

239 In Abschnitt 4.5.2 wurde ein Modell zum Prozess der IT-Projektdurchführung entwickelt. Dieses Modell sieht einen Entscheidungspunkt D3 vor, an dem auf Basis einer Risikoanalyse über die Produktivnahme der im Projekt entwickelten IT-Lösung entschieden wird. Wird in die Risikoanalyse der Aspekt der Theoriebeherrschung einbezogen, kann sichergestellt werden, dass kein totes System in Produktion geht. 240 Dies wird insbesondere durch Modelle und Methoden der Agilen Softwareentwicklung adressiert. Die agile Softwareentwicklung stellt den Gedanken der Theoriebildung im Team in den Mittelpunkt. COCKBURN als Mitinitiator des so genannten Agilen Manifestes Mitbegründer der agilen Softwareentwicklung. Zu Konzepten, Modellen und Methoden der agilen Softwareentwicklung vgl. [BleWol08].

228

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

Wie ist die Komplexität der IT-Landschaft im Hinblick auf Adaptierbarkeit, Flexibilität, Agilität der enthaltenen IT-Systeme und die damit verbundene Antizipation zukünftiger Leistungsanforderungen zu managen? Hinter dieser Fragestellung steht eine Forderung, die nach Erfahrung des Autors der vorliegenden Arbeit in der Praxis der Unternehmens-IT größerer Unternehmen häufig diskutiert wird. Ausgangspunkt dieser Forderung ist die Vorstellung, Architekturen von IT-Systemen könnten auf eine Weise flexibel, adaptiert oder agil gestaltet werden, sodass zukünftige, zum Zeitpunkt der Entwicklung eines IT-Systems noch nicht berücksichtigte Leistungsanforderungen implementiert werden können, ohne die Komplexität der IT-Landschaft signifikant zu erhöhen. Verbunden damit ist die Vorstellung, die IT-Architektur des betreffenden Systems bzw. eines bestimmten Ausschnittes der IT-Landschaft könne in einer Art und Weise gestaltet werden, dass zukünftige Leistungsanforderungen – sowohl fachliche Anforderungen als auch Integrationsanforderungen - nicht nur antizipiert, sondern auch „schneller als sonst“ erfüllt werden können.241 Diese Vorstellungen müssen vor dem Hintergrund der bisher erarbeiteten Gestaltungsempfehlungen zum Integrationsmanagement und hier insbesondere in Bezug auf das Konzept der Reaktionsfähigkeit und die in Abschnitt 4.4 beschriebene Mehrdimensionalität von Komplexität differenziert betrachtet werden. Bevor die begriffliche Abgrenzung von Adaptierbarkeit, Flexibilität und Agilität vorgenommen wird, werden die beschriebenen Vorstellungen auf Basis der erarbeiteten Gestaltungsempfehlungen zur Reaktionsfähigkeit, zum Komplexitätsmanagement und zur Beherrschbarkeit von IT-Systemen diskutiert: ƒ

Der wahrnehmungsabhängige Teil der Komplexität einer IT-Landschaft mit IT-Systemen, deren IT-Architekturen schnellere Anpassung an fachliche Anforderungen und Integrationsanforderungen – z. B. durch Konfiguration und Parametrisierung – unterstützen, kann in Abhängigkeit von den Fertigkeiten der Mitarbeiter der IT-Organisation höher sein als die Komplexität

241 Ein Beispiel für den Versuch, solche IT-Systeme zu realisieren, sind die in der Versicherungswirtschaft insbesondere in den 90er Jahren diskutierten Produktsysteme. Solche IT-Systeme sollen die Möglichkeit schaffen, neue Versicherungsprodukte und damit verbundene Geschäftsprozesse spartenübergreifend durch die Abbildung und Implementierung auf Basis eines generischen Datenmodells zur Beschreibung des Informationsbedarfs dieser Prozesse und Produkte zu definieren und einzuführen. Dies war mit dem Anspruch verbunden, Geschäftsvorfälle zum Angebots-, Antrags-, Vertrags- und Leistungsmanagement deklarativ auf Basis des Modells zu implementieren. Entsprechende IT-Projekte scheiterten häufig, da sich die solchen Systemen immanente Komplexität als nicht beherrschbar erwies.

4.6 Ergänzende Leitlinien zur Organisation der IT-Landschaft

ƒ

ƒ

ƒ ƒ

229

einer IT-Landschaft, die auf solche Systeme verzichtet. Zudem kann unabhängig von der Wahrnehmung ein solches IT-System komplexer sein, da es mehr Zustände einnehmen kann als ein „herkömmliches“ System. Ob die IT-Landschaft höhere oder geringere Komplexität aufweist, hängt davon ab, ob die mögliche Reduktion der wahrnehmungsunabhängigen Komplexität die Steigerung der wahrnehmungsabhängigen über- oder unterkompensiert. Nach der beschriebenen Theorie von NAUR können flexiblere IT-Systeme und damit die IT-Landschaft schwerer zu beherrschen sein, da die Theorie dieser IT-Systeme schwerer zu beherrschen ist. Eine entsprechende Risikobetrachtung ist daher notwendig. Die Einführung neuer IT-Architekturen kann zunächst mit einer Reduktion des dynamischen Potenzials verbunden sein. Es stellt sich die Frage, inwieweit IT-Systeme eines bestimmten Unternehmens mit seiner spezifischen Einbettungen in die Systemumwelt ex ante nach IT-Architekturen gestaltet werden können, die bisher nicht berücksichtigte Leistungsanforderungen so antizipieren, dass diese mit geringerer Komplexitätswirkung als „herkömmlich“ realisiert werden können. Der Vergleichsmaßstab einer solchen Betrachtung ist unklar. Dem steht die Expost-Sicht gegenüber. Danach wären diejenigen IT-Systeme flexibel, agil bzw. adaptierbar, die sich für das jeweilige Unternehmen als solche erwiesen haben.

4.6.3.1 Begriffliche Abgrenzung Die Recherchen des Autors der vorliegenden Arbeit zur Definition der Begriffe Adaptierbarkeit, Flexibilität und Agilität von IT-Systemen erbrachten keine eindeutige, allgemein akzeptierte Definition. Die analysierten Definitionen weisen hinsichtlich des Begriffes der Adaptierbarkeit das gemeinsame Verständnis auf, dass ein IT-System im Rahmen seines ursprünglichen Zweckes den Veränderungen der Systemumwelt „leichter“ angepasst werden kann. Der Begriff der Adaptierbarkeit wird für die vorliegende Arbeit daher als Ausgangspunkt der durchzuführenden begrifflichen Abgrenzung genutzt. Adaptierbar wird mit Blick auf das ursprüngliche fachliche Einsatzspektrum und die zukünftigen Leistungsanforderungen definiert. Dieses fachliche Einsatzspektrum ergibt sich aus dem Ausschnitt der realen Welt und den dort stattfindenden Interaktionen, welche das System repräsentiert und unterstützt. Dieses Spektrum wird hier unter dem Begriff der fachlichen Domäne adressiert.

230

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

Definition - Adaptierbarkeit und Flexibilität von IT-Systemen Ein IT-System ist adaptierbar, wenn es auf zusätzliche Leistungsanforderungen aus den fachlichen Domänen angepasst werden kann, die bei der Entwicklung des Systems im Mittelpunkt standen, und wenn diese Anpassung ƒ theoriekonform, das heißt ohne Verletzung der Theorie des Systems, vorgenommen werden kann, ƒ komplexitätskonform vorgenommen werden kann, das heißt, ohne die Komplexität der IT-Landschaft242 signifikant zu erhöhen. Ein IT-System ist flexibel, wenn es darüber hinaus Leistungsanforderungen aus fachlichen Domänen angepasst werden kann, die bei der Entwicklung des Systems nicht im Fokus standen und die Anpassung theorie- und komplexitätskonform vorgenommen werden kann. Ein Beispiel verdeutlicht dieses Verständnis: Das Filial-IT-System eines Kreditinstituts für Konsumentenkredite für Privatkunden soll zusätzlich für die Kanäle Makler und Call Centre genutzt werden. Ein adaptierbares IT-System deckt diese Anforderung in derselben Domäne so ab, dass seine Theorie stabil bleibt und - bei Einschränkung der Betrachtung auf die Systemumwelt erster Ordnung – der betreffende Ausschnitt243 der IT-Landschaft nicht signifikant komplexer wird. Kann das Filial-IT-System zusätzlich für Baufinanzierungen eingesetzt werden, ohne die Theorie zu verletzen und ohne die Komplexität signifikant zu verändern, so ist das IT-System darüber hinaus als flexibel einzuordnen. Führt die Anpassung des IT-Systems an zusätzliche Kanäle bzw. an Baufinanzierungen dazu, dass seine Theorie verletzt oder die Komplexität seiner Sys242

Nach dem Komplexitätskonzept der vorliegenden Arbeit und dessen Umsetzung mithilfe von KITL sind hier die Komplexität des Systems, die Komplexität der Gesamtheit der IT-Systeme und die Komplexität der IT-Basisinfrastruktur einzubeziehen. Ein Ansatz zur Umsetzung in der Unternehmenspraxis besteht darin, die Komplexitätsbetrachtung auf die Systemumwelt des Systems zu fokussieren. Die Systemumwelt eines IT-Systems lässt sich anhand der Informationsbeziehungen zu anderen Systemen ermitteln. Hier ist zu unterscheiden, ob Informationsbeziehungen erster Ordnung oder auch solche höherer Ordnung einbezogen werden, um die Systemumwelt eines Systems zu ermitteln. Die Systemumwelt erster Ordnung eines Systems wird verstanden als die Menge aller IT-Systeme, die eine Informationsbeziehung mit dem betrachteten System aufweisen. Die Informationsflüsse, in denen sich die Informationsbeziehungen manifestieren, werden als Element der Systemumwelt erster Ordnung verstanden. Die Systemumwelt zweiter Ordnung ergibt sich durch Rekursion dieser Regel. EAM-Lösungen wie ARIS unterstützen die Abgrenzung von Systemumwelten. Wird ein solcher Ansatz gewählt, würde die Analyse der Komplexitätswirkung auf die Systemumwelt des im Fokus stehenden Systems konzentriert und die Frage beantwortet, ob zukünftige Anforderungen zur signifikanten Erhöhung der Komplexität der Systemumwelt führen. 243 Das wäre in diesem Fall das Filial-IT-System mit den IT-Systemen, zu denen es Informationsbeziehungen aufweist.

4.6 Ergänzende Leitlinien zur Organisation der IT-Landschaft

231

temumwelt signifikant gesteigert wird, so ist das IT-System nicht adaptierbar bzw. nicht flexibel. In der Definition von Adaptierbarkeit und Flexibilität wird die zeitliche Komponente der Anpassung nicht adressiert. Hier setzt die Definition des Begriffes Agilität an. Definition - Agilität von IT-Systemen244 Ein IT-System ist agil, wenn nachträgliche Leistungsanforderungen an das System zeitgerecht kompensiert werden können. Die Klassifizierung als zeitgerecht bemisst sich danach, ob die mit der Leistungsanforderung beabsichtigten bzw. vorgeschriebenen Veränderungen der Interaktionen des Unternehmens in der realen Welt rechtzeitig durch das System unterstützt werden können. Im Falle vorgeschriebener Veränderungen ergibt sich die Rechtzeitigkeit der Kompensation aus vom Gesetzgeber oder Aufsichtsbehörden festgelegten Terminen. Im Falle dem Wettbewerb geschuldeter Veränderungen ergibt sich die Rechtzeitigkeit der Kompensation aus der Business-Case-Analyse. 4.6.3.2 Klassifikation von IT-Systemen nach Adaptierbarkeit, Flexibilität und Agilität Auf Basis der vorgenommenen begrifflichen Abgrenzung kann die o. a. Vorstellung zur Adaptierbarkeit, Flexibilität bzw. Agilität von IT-Systemen präzisiert werden. Der Aspekt der Realisierung nachträglicher Anforderungen ohne signifikante Komplexitätssteigerung wird durch die Eigenschaften der Adaptierbarkeit und der Flexibilität adressiert. Die zeitliche Komponente ergibt sich aus der Eigenschaft der Agilität. IT-Systeme können auf diese Weise nach dem in Abbildung 106 dargestellten Modell klassifiziert werden. Nach Erfahrung des Autors der vorliegenden Arbeit bezieht sich die o. a. Vorstellung aus der Praxis größerer Unternehmen i. d. R. auf die Zielsetzung, die Architektur von ITSystemen so zu gestalten, dass sie in Segment 2 liegen.

244 Aus dieser Definition ergeben sich Ansatzpunkte für die Konkretisierung des dynamischen Potenzials der IT-Landschaft. Erweisen sich die in einer IT-Landschaft enthaltenen IT-Systeme in einer Ex-post-Betrachtung als agil, so kann dies so verstanden werden, dass das dynamische Potenzial der IT-Landschaft ex post ausreichend ist.

232

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

flexibel

4

1

adaptierbar

5

2

nicht adaptierbar

6

3

nicht agil

agil

Abbildung 106: Modell zur Klassifizierung von IT-Systemen nach Flexibilität, Adaptierbarkeit und Agilität Dieses Modell zur Klassifizierung von IT-Systemen stellt ein Werkzeug dar, das dem Prozess des IS-Portfoliomanagements zuzuordnen ist. Mithilfe des Modells und der in Abschnitt 4.6.1 entwickelten Leitlinien können folgende zusätzlichen Leitlinien zum IS-Portfoliomanagement aufgestellt werden: ƒ

ƒ

ƒ

Die IT-Landschaft ist optimal aufgestellt, wenn IT-Systeme mit großem Geschäftsnutzen in Segment 1 oder 2 liegen und die Erreichung der Effizienzziele der Unternehmens-IT sowie die Beherrschbarkeit der ITLandschaft gewährleistet ist. Systeme aus Segment 3 oder 6 können zusätzliche Leistungsanforderungen nur so implementieren, dass die Theorie des IT-Systems verletzt oder die Komplexität der IT-Landschaft signifikant gesteigert wird. Zudem ist für Segment 6 die zeitgerechte Implementierung gefährdet. Besitzen solche ITSysteme geringen Geschäftsnutzen, sollten sie stillgelegt, andernfalls ersetzt werden. IT-Systeme aus Segment 4 oder 5 können zusätzliche Leistungsanforderungen theoriekonform und ohne signifikante Steigerung der Komplexität der IT-Landschaft implementieren. Eine zeitgerechte Implementierung ist jedoch nicht sichergestellt. Der Nutzen der Adaptierbarkeit bzw. der Flexibilität dieser Systeme ist somit fraglich. Da IT-Architekturen von adaptierbaren bzw. flexiblen Systemen höhere Anforderungen an die Fertigkeiten der Mit-

233

4.6 Ergänzende Leitlinien zur Organisation der IT-Landschaft

ƒ

arbeiter der IT-Organisation im Umgang mit Komplexität stellen, ergeben sich zwei Möglichkeiten zur Repositionierung der betroffenen IT-Systeme: o Das IT-System wird theoriekonform weiterentwickelt - entweder durch Erhöhung der Agilität mittels Architekturoptimierung oder, falls nicht möglich, durch Vereinfachung und damit einher gehender Komplexitätsreduktion - falls notwendig unter Reduktion des Grades der Adaptierbarkeit/Flexibilität. o Ist dies nicht möglich, wird das IT-System bei geringem Geschäftsnutzen stillgelegt, andernfalls ersetzt. Das Management der IT-Systeme, die sich in Segment 1 oder 2 befinden, sollte auf die Sicherstellung der Beherrschbarkeit der Systeme im Sinne des Lebenszykluskonzeptes aus Abschnitt 4.6.2 ausgerichtet sein.

5

Beherrschbarkeit sicher stellen

adaptierbar

4

Falls nicht theoriekonform optimierbar • Stilllegen bei geringem Geschäftsnutzen • Ersetzen bei hohem Geschäftsnutzen

flexibel

Theoriekonforme Optimierung • Steigerung der Agilität oder • Vereinfachung – ggf. mit Reduktion von Adaptierbarkeit/ Flexibilität

Platziert man diese Leitlinien zum IS-Portfoliomanagement im entwickelten Klassifizierungsmodell, so ergibt sich die folgende Übersicht.

1

2

bei hohem Geschäftsnutzen ersetzen

nicht adaptierbar

6

3

bei geringem Geschäftsnutzen stilllegen

nicht agil

agil

Abbildung 107: Leitlinien zum Management der IT-Landschaft nach Adaptierbarkeit, Flexibilität und Agilität Die bis hierher vorliegenden Leitlinien zum Komplexitätsmanagement werden mit Blick auf die Adaptierbarkeit, Flexibilität und Agilität von IT-Systemen folgendermaßen zusammengefasst:

234 ƒ

ƒ

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

Das IS-Portfoliomanagement sollte die systematische Bewertung der Adaptierbarkeit, Flexibilität und Agilität sowie des Geschäftsnutzens von ITSystemen umfassen. Auf Basis der in Abbildung 107 darstellten Empfehlungen sollte der Weiterentwicklungspfad je System definiert werden. Je nach Einordnung ergeben sich daraus IT-Projektkandidaten. Innerhalb der Prozesse der Erweiterung/Erneuerung sollte sichergestellt werden, dass Systeme konform zu definierten Weiterentwicklungspfaden gemanagt werden.

4.6.3.3 Angemessenheit von Adaptierbarkeit, Flexibilität und Agilität Da ein IT-System tatsächlich erst dann adaptierbar, flexibel bzw. agil ist, wenn es diese Eigenschaften im Kontext der an das System sukzessive erhobenen Leistungsanforderungen auch gezeigt hat, werden Adaptierbarkeit, Flexibilität und Agilität im Sinne einer Ex-post-Betrachtung verstanden. Das heißt: ITSysteme sind adaptierbar, flexibel bzw. agil, wenn sie sich als solche erwiesen haben. Ausgangspunkt der weiteren Diskussion ist die Annahme, dass in größeren Unternehmen bei der Entwicklung von IT-Systemen IT-Architekturen zum Einsatz kommen, die auf praxiserprobten Konzepten der Software-Architektur und des Software-Designs beruhen, wie sie in zahlreichen Publikationen aus Forschung und Praxis245 beschrieben sind und die unabhängig vom speziellen Unternehmenskontext ein gewisses Maß an Adaptierbarkeit, Flexibilität und Agilität bewirken. Wird diese Annahme vorausgesetzt, so erhöht jede darüber hinausgehende, proaktive Gestaltung von IT-Architekturen zum Zeitpunkt t0 zwecks Antizipation zukünftiger Leistungsanforderungen das Risiko der Unbeherrschbarkeit des Systems, das Risiko der Komplexitätssteigerung oder das Risiko der Reduktion der Reaktionsfähigkeit. Die auf die Zukunft ausgerichtete Anpassung von ITArchitektur wird also mit erhöhten Risiken in t0 „erkauft“. Im Falle des o. a. Beispiels des Konsumentenkreditsystems würde dies bedeuten, Multikanalfähigkeit mithilfe entsprechender Best-Practice-Architekturen vorzusehen, wenn die Geschäftsarchitektur des Finanzdienstleisters eine solche Leistungsanforderung erwarten lässt. Gleichzeitig würde aufgrund des beschriebenen Risikos darauf verzichtet, das System so zu gestalten, dass zukünftig auch Baufinanzierungen abgedeckt werden könnten, wenn dies die Reaktionsfähigkeit gefährdet oder die heutige Erhöhung der Komplexität des Systems durch die zukünftig erwartete,

245

Vgl. dazu zum Beispiel [Fow03] oder [Starke05].

4.6 Ergänzende Leitlinien zur Organisation der IT-Landschaft

235

jedoch a priori unsichere Komplexitätsbegrenzung aufgrund zusätzlicher Leistungsanforderungen nicht kompensiert wird. Die Art und Weise, wie die Adaptierbarkeit, Flexibilität oder Agilität eines Systems erzeugt wird, ist Bestandteil der Theorie dieses Systems. Aus den angestellten Überlegungen wird folgende Definition abgeleitet: Definition - unangemessene Theorie von IT-Systemen Die Theorie eines IT-Systems ist unangemessen, wenn die Gestaltung seiner IT-Architektur zum Zeitpunkt t0 mit dem Ziel der Komplexitätsbegrenzung und Effizienzsteigerung mit Blick auf zukünftige Leistungsanforderungen mittels Adaptierbarkeit, Flexibilität und Agilität zur Unbeherrschbarkeit des IT-Systems, zur Gefährdung der Reaktionsfähigkeit oder zur signifikanten Komplexitätssteigerung zum Zeitpunkt t0 führt. Auf Basis dieser Definition ergeben sich folgende Leitlinien: ƒ ƒ

IT-Architekturen von IT-Systemen sollten nur insoweit in Bezug auf Adaptierbarkeit, Flexibilität und Agilität optimiert werden, wie dies nicht zur Unangemessenheit der Theorie des Systems führt. Ist diese Bedingung nicht erfüllt, dann ist das angestrebte Maß an Adaptierbarkeit, Flexibilität oder Agilität unangemessen und daher als Ziel einer proaktiven Gestaltung der IT-Landschaft zu verwerfen.

4.6.3.4 Proaktive Gestaltung der IT-Landschaft bezüglich zukünftiger M&ASituationen M&A-Situationen im Grundmodell zum Integrationsmanagement Betrachtet man M&A-Situationen246 aus der Perspektive des Grundmodells zum Integrationsmanagements aus Abschnitt 2.2.3, so besteht die Aufgabe der Konsolidierung der IT-Landschaft aus Sicht eines Unternehmens A darin, die aus der Fusion, Übernahme oder Abspaltung abgeleiteten Leistungsanforderungen durch Anpassung der IT-Landschaft zu befriedigen. Diese Leistungsanforderungen beruhen zum einen auf veränderten Informationsbedarfen in der Folge der Veränderungen in der Geschäftsprozesslandschaft von A und zum anderen auf den 246 In diesem Abschnitt werden Fusionen, Übernahmen oder Abspaltung von Unternehmen oder Unternehmensteilen unter dem Begriff der M&A-Situation (Merger & Acquisition) und die damit verbundene Integration oder Desintegration von (Teil-) IT-Landschaften unter dem Begriff der ITKonsolidierung zusammengefasst. Wie in Abschnitt 3.2 ausgeführt, sprechen verschiedene Autoren auch von Post-Merger-Integration.

236

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

mit der M&A-Situation verbundenen Effizienzzielen. Nach dem Grundmodell bestehen die Leistungsanforderungen in: 1.

2.

Integrationsanforderungen o Bestehende Informationsbeziehungen zwischen IT-Systemen werden aufgehoben – d. h. bestehende Implementierungen von Informationsflüssen sind zurückzubauen. Das bedeutet zum Beispiel, dass die Informationsflüsse aus den operativen IT-Systemen eines von A abzuspaltenden Geschäftsfeldes zu den IT-Systemen zur Unternehmenssteuerung von A aufgehoben werden. o Neue Informationsbeziehungen zwischen den IT-Systemen von A und den in die IT-Landschaft von A zu integrierenden Systemen sind aufzubauen – d. h. neue Informationsflüsse sind zu implementieren. Das bedeutet zum Beispiel, dass Informationsflüsse aus neuen operativen Systemen einer von A übernommenen Versicherungssparte zu den ITSystemen zur Unternehmenssteuerung von A implementiert werden. Fachlichen Anforderungen o Funktionale oder nicht-funktionale Leistungsmerkmale sind in der ITLandschaft von A zu ergänzen. Das bedeutet zum Beispiel, dass die IT-Systeme zur Unternehmenssteuerung von A um Funktionen zur Steuerung des zu integrierenden Geschäftsfeldes erweitert werden. o Funktionale oder nicht-funktionale Leistungsmerkmale sind aus der IT-Landschaft zu entfernen. Das bedeutet zum Beispiel, dass die Funktionen zur Steuerung des von A abzuspaltenden Geschäftsfeldes in den IT-Systemen zur Unternehmenssteuerung von A stillgelegt werden.

Die M&A-Situation kann aus Sicht der Unternehmens-IT so interpretiert werden, dass es sich um die Konstellation zusätzlicher, umfassender in der M&A-Situation begründeter Leistungsanforderungen an die Unternehmens-IT handelt. Dies ist mit der Notwendigkeit verbunden, parallel zur IT-Konsolidierung die bestehende Geschäftsprozessunterstützung möglichst störungsfrei sicherzustellen247. Die proaktive Gestaltung einer IT-Landschaft im Hinblick auf M&ASituationen ist daher gleichbedeutend damit, die für die erwartete IT-Konsolidierung essenziellen IT-Systeme darauf vorzubereiten, diese zukünftigen, zusätzlich auftretenden Anforderungen so zu antizipieren, dass sie möglichst effizient erfüllt werden können. Dies bedeutet die Definition und Umsetzung von IT-Architekturen, die die Adaptierbarkeit, Flexibilität bzw. Agilität248 der als 247 248

Siehe dazu die Gestaltungsempfehlung 5.4 aus Abschnitt 3.2.5.3.3. Siehe dazu Abschnitt 4.6.3.

4.6 Ergänzende Leitlinien zur Organisation der IT-Landschaft

237

essenziell identifizierten Systeme im Vergleich zur unveränderten IT-Landschaft erhöhen und auf diese Weise größere Effizienz zukünftiger IT-Konsolidierungen bewirken. Die konkret geforderte Verbesserung der Adaptierbarkeit, Flexibilität bzw. Agilität der essenziellen Systeme ergibt sich dabei aus der Geschäftsstrategie. Definiert diese Geschäftsstrategie beispielsweise die Expansion in neue Länder in bestehenden fachlichen Domänen, so müssen die IS-Architekturen die Adaptierbarkeit der essenziellen Systeme verbessern, da die zu antizipierenden Leistungsanforderungen bereits durch diese Systeme adressierte Domänen betreffen. Identifikation der essenziellen Systeme der IT-Konsolidierung Aus diesen Überlegungen ergibt sich als notwendige Bedingung der proaktiven Gestaltung von IT-Landschaften: ƒ ƒ

die Identifikation derjenigen Systeme, die für die durch eine zukünftige M&A-Situation ausgelöste IT-Konsolidierung essenziell sind, und damit verbunden die Festlegung der geforderten Verbesserung der Adaptierbarkeit, Flexibilität bzw. Agilität dieser Systeme.

Dies setzt eine Geschäftsstrategie voraus, die erstens M&A-Situationen erwarten lässt und zweitens so stringent formuliert ist, dass eine ITIntegrationsstrategie249 abgeleitet werden kann, in der die als essenziell identifizierten Systeme adressiert werden. Erfüllt die Geschäftsstrategie diese Anforderung nicht, so fehlt die Voraussetzung, um die Forderung nach einer proaktiven Gestaltung der IT-Landschaft so weit zu konkretisieren, dass daraus IT-Projekte abgeleitet werden können, die die zur Antizipation zukünftiger M&A-Situationen notwendigen IT-Architekturen implementieren. Architekturmuster als Grundlage der IT-Integrationsstrategie Nach dem Verständnis der vorliegenden Arbeit sind Architekturmuster grundlegende Organisationsstrukturen von IT-Landschaften, Teilsystemen von ITLandschaften oder einzelnen IT-Systemen in Bezug auf bestimmte Problemstellungen. Ein Architekturmuster zur proaktiven Gestaltung der IT-Landschaft legt demnach fest, wie die für die IT-Konsolidierung als essenziell identifizierten ITSysteme grundsätzlich zu organisieren sind, um erwartete Leistungsanforderungen, insbesondere Integrationsanforderungen, zu antizipieren. Ein solches Architekturmuster 249

Siehe dazu Abschnitt 4.3.

238 ƒ ƒ ƒ

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

ist nach dem in Abschnitt 2.3 entwickelten Modell Teil der IT-Integrationsarchitektur250 des Unternehmens, bestimmt als Teil der IT-Unternehmensarchitektur die IT-Integrationsstrategie und zielt auf die Verbesserung der Adaptierbarkeit, Flexibilität bzw. Agilität der identifizierten essenziellen IT-Systeme, indem es aus Sicht der IT-Konsolidierung Rahmenbedingungen für die übergreifende Organisation der ITArchitekturen dieser Systeme festlegt.

Analyse eines Architekturmusters Sieht die Geschäftsstrategie251 eines Unternehmens A Übernahmen zur Expansion und zur Ausdehnung bestehender Geschäftsfelder in neue Märkte vor, so besteht eine mögliche IT-Integrationsstrategie darin, IT-Landschaften zugekaufter Unternehmen in die Unternehmens-IT von A zu integrieren, indem die Daten in die IT-Landschaft von A migriert werden, die Geschäftsprozessunterstützung übernommener Unternehmen auf die IT-Landschaft von A umgestellt wird und hierfür notwendige Anpassungen in der IT-Landschaft durchgeführt werden. Unabhängig vom konkreten Einzelfall kann davon ausgegangen werden, dass IT-Systeme zur Unternehmenssteuerung und – falls vorhanden - zentrale Kundenstammdatensysteme essenziell für die Unterstützung dieser Expansionsstrategie sind, da diese Systeme unternehmensübergreifende Geschäftsprozesse unterstützen, mit den Kerngeschäftssystemen übernommener Unternehmen integriert werden müssen und daher Informationsbeziehungen zu zukünftig zu integrierenden Teil-IT-Landschaften erwarten lassen. Für das Unternehmen A ergibt sich die Frage, wie die IT-Landschaft proaktiv organisiert werden kann, um diese Situation zu antizipieren. Ein mögliches Architekturmuster stellt eine zentrale Geschäftsplattform252 zur Unternehmenssteuerung in den Mittelpunkt. Eine solche Plattform ist z. B. darauf ausgerichtet, Prozesse der Rechnungslegung, des ManagementReportings usw. über mehrere Märkte und Geschäftsfelder hinweg abzudecken. Wesentlicher Baustein des Aufbaus dieser Unternehmenssteuerungsplattform ist die Integration mit den IT-Systemen, die die Kernprozesse in den jeweiligen Märkten unterstützen, da diese Systeme die Master-Funktion der operativen Geschäftsdaten besitzen, die in die Unternehmenssteuerungsprozesse einfließen. 250

Siehe dazu Abschnitt 2.3. Ein Beispiel ist hier die Geschäftstrategie, die die SEB GRUPPE bis zum Jahr 2006 verfolgte; siehe dazu auch Kapitel 5. 252 Geschäftsplattformen sind als Teilsysteme der IT-Landschaft zu verstehen, die sich aus mehreren IT-Systemen konstituieren und die darauf ausgerichtet sind, bestimmte Geschäftsprozesse zu vereinheitlichen. 251

239

4.6 Ergänzende Leitlinien zur Organisation der IT-Landschaft

KerngeschäftsKerngeschäftsKerngeschäftssysteme systeme systeme H1

Heimatmarkt 2 (H2)

KerngeschäftsKerngeschäftsKerngeschäftssysteme systeme systeme H2

Neuer Markt 1 (N1)

Kerngeschäftsplattform Instanz N1

Neuer Markt 2 (N2)

Kerngeschäftsplattform Instanz N2

Neuer Markt …

Kerngeschäftsplattform Instanz …

Unterneh m enssteuerungspla ttform

Heimatmarkt 1 (H1)

DW H

Zwischen diesen Kernsystemen, der Unternehmenssteuerungsplattform und soweit vorhanden - dem zentralen Kundenstammdatensystem sind Informationsbeziehungen zu implementieren. Das Architekturmuster sieht den Aufbau einer Kerngeschäftsplattform zur Unterstützung der Kernprozesse in neuen Märkten vor. Nach diesem Architekturmuster ist die IT-Architektur der Plattform auf die Integration mit der Unternehmenssteuerungsplattform und dem zentralen Stammdatensystem unter Nutzung ganzheitlicher Integrationslösungen - einem Data Warehouse zur Unternehmenssteuerung - auszurichten. Während neue Märkte so auf einer standardisierten Kerngeschäftsplattform beruhen, verbleibt die Kerngeschäftsprozessunterstützung der Heimatmärkte auf den bestehenden Kernsystemen, die unter Nutzung der angesprochenen ganzheitlichen Integrationslösung ebenfalls mit der Unternehmenssteuerungsplattform integriert werden. Die folgende Abbildung fasst das Architekturmuster zusammen.

Abbildung 108: Architekturmuster zur Unterstützung der Expansion bestehender Geschäftsfelder in neue Märkte Auf Basis dieses in die IT-Integrationsstrategie eingehenden Architekturmusters sind die für die Expansion essenziellen IT-Systeme: ƒ ƒ

Geschäftsplattform zur Unternehmenssteuerung Data Warehouse zur Unternehmenssteuerung

240 ƒ ƒ

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

Kerngeschäftsplattform für neue Länder und Märkte Zentrales Kundenstammdatensystem (falls vorhanden)

Die Geschäftsplattformen und das Data Warehouse werden nun auf Basis der vorliegenden Gestaltungsempfehlungen analysiert. Ausgangspunkt bildet die Frage, wie diese IT-Systeme in Bezug auf Adaptierbarkeit, Flexibilität bzw. Agilität einzuordnen sind. Aus der beschriebenen Strategie der Expansion bestehender Geschäftsfelder folgt die Anforderung, die Plattformen und das Data Warehouse adaptierbar auszulegen. Das bedeutet, dass die IT-Architekturen so zu gestalten sind, dass ƒ Anforderungen zukünftiger Märkte ƒ im Bereich der bereits heute in den Heimatmärkten adressierten Domänen (Rechnungslegung Banking, Zahlungsverkehr, Projektfinanzierung, …) ƒ effizienter erfüllt werden können, als dies ohne den Aufbau der Plattformen möglich wäre, und ƒ die Integration zukünftig zugekaufter Unternehmen konform zur Theorie der Plattformen und ohne signifikante Komplexitätssteigerung der ITLandschaft vorgenommen werden kann. Im oben entwickelten Modell zur Klassifizierung von IT-Systemen bzgl. Adaptierbarkeit, Flexibilität und Agilität ergibt sich die folgende Einordnung. 4

1

flexibel

2 Plattform zur Unternehmenssteuerung

adaptierbar

DWH

5

Kerngeschäftsplattform für neue Märkte

nicht adaptierbar

6

nicht agil

3

agil

Abbildung 109: Zielpositionierung von Plattformen zur Unterstützung der Integration übernommener Unternehmen

241

4.6 Ergänzende Leitlinien zur Organisation der IT-Landschaft

Auf der Grundlage dieser Positionierung stellt sich die Frage nach der Gesamtkomplexität KITL einer IT-Landschaft, die dem beschriebenen Architekturmuster folgt. Wie in Abschnitt 4.6.1 gezeigt, kann die Komplexität einer solchen IT-Landschaft höher sein als die einer Landschaft, die auf derartige Plattformen verzichtet. Dies ist der Fall, wenn die mit der Einführung der Plattform verbundene Wirkung der Komplexitätsreduktion der Gesamtheit der IT-Systeme (Größe KGI in KITL sinkt) durch die erhöhte Komplexität dieser Plattform(en) (Größe MKX in KITL steigt) überkompensiert wird. Darüber hinaus ergibt sich die Frage der dauerhaften Beherrschbarkeit und der Reaktionsfähigkeit solcher Geschäftsplattformen. Beherrschbarkeit ist gegeben, wenn die Theorie der Plattform beherrscht wird. Offensichtlich ist die Beherrschbarkeit der Theorie einer solchen Plattform dauerhaft schwieriger zu gewährleisten, da sie eine größere Anforderungsvielfalt abbilden muss. Daher besteht ein höheres Risiko, dass die Plattform zu einem toten IT-System mutiert. Zusätzlich besteht das Risiko einer mittelfristigen Einschränkung der Reaktionsfähigkeit im Bereich der durch die Plattformen unterstützten Geschäftsprozesse, da die länder- und geschäftsfeldübergreifende Einführung nach Erfahrung des Autors der vorliegenden Arbeit mehrere Jahre dauern kann. Diese Analyse ist so zu interpretieren, dass das Risiko der Abweichung der tatsächlich eintretenden Positionierung der beschriebenen Geschäftsplattformen von der oben dargestellten Zielpositionierung besteht. Bei Eintreten dieses Risikos würde daher eine Positionierung eintreten, wie sie die folgende Abbildung zeigt. 4

1

5

2

6

3

flexibel

adaptierbar

nicht adaptierbar

nicht agil

agil

Abbildung 110: Mögliche Positionierung von Plattformen zur Unterstützung der Integration von Unternehmensübernahmen

242

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

Im Vergleich zu einer IT-Integrationsstrategie, die auf die proaktive Gestaltung der IT-Landschaft durch den Aufbau adaptierbarer Geschäftsplattformen verzichtet, ist die beschriebene Strategie in diesem Fall negativ zu beurteilen, da mit dem Aufbau der Plattformen zusätzliche Kosten und Einschränkungen der Reaktionsfähigkeit verbunden sind. Zusammenfassung In Abschnitt 4.6.3 wurde gezeigt, dass die Theorie eines IT-Systems unangemessen ist, wenn die Gestaltung seiner IT-Architektur zum Zeitpunkt t0 mit dem Ziel einer zukünftigen Komplexitätsbegrenzung oder der effizienteren Erfüllung von Leistungsanforderungen mittels Adaptierbarkeit, Flexibilität und Agilität zur Unbeherrschbarkeit, zur Reduktion des dynamischen Potenzials oder zur signifikanten Komplexitätssteigerung zum Zeitpunkt t0 führt. Daraus wurde die Leitlinie abgeleitet, IT-Architekturen von IT-Systemen nur insoweit in Bezug auf eine erwartete Adaptierbarkeit, Flexibilität und Agilität zu optimieren, wie dies nicht zu einer Unangemessenheit der Theorie des Systems führt. Die durchgeführte Analyse zeigt, dass die proaktive Gestaltung von ITLandschaften der Gestaltung von IT-Architekturen im Hinblick auf eine Steigerung der Adaptierbarkeit, Flexibilität bzw. Agilität wichtiger IT-Systeme zum Zeitpunkt t0 entspricht, um so eine effizientere Erfüllung der durch zukünftige IT-Konsolidierungen verursachten, antizipierten Leistungsanforderungen zu ermöglichen. Die Anwendung der aufgestellten Leitlinie zur Unangemessenheit der Theorie eines Systems mündet somit in folgende weitere Leitlinien: ƒ

ƒ ƒ

Die proaktive Gestaltung einer IT-Landschaft ist nur im Falle einer Geschäftsstrategie sinnvoll, die Übernahmen, Fusionen bzw. Abspaltungen erwarten lässt und die es erlaubt, eine auf zukünftige M&A-Situationen ausgerichtete IT-Integrationsstrategie festzulegen. Können die für die IT-Konsolidierung essenziellen IT-Systeme nicht ex ante auf Basis der Geschäftsstrategie identifiziert werden, so fehlt die Grundlage der proaktiven Gestaltung der IT-Landschaft. Voraussetzung der proaktiven Gestaltung der IT-Landschaft ist die Abschätzung der durch die IT-Konsolidierung verursachten Risiken o der Gefährdung des notwendigen dynamische Potenzials, o des Verlustes der Beherrschbarkeit der für die zukünftigen Übernahmen, Fusionen oder Abspaltungen essenziellen IT-Systeme.

4.7 Management ganzheitlicher Integrationslösungen in der IT-Prozesslandschaft

243

4.7 Management ganzheitlicher Integrationslösungen in der ITProzesslandschaft Der in Abschnitt 4.1 definierte Verfeinerungsbedarf verlangt die Abbildung des in Abschnitt 3.2.2.4 entwickelten Vorgehensmodells auf das Referenzmodell der IT-Prozesslandschaft. Zusätzlich ist die Gestaltungsempfehlung 2.3 auf Basis der ergänzenden Leitlinien zur Organisation der IT-Landschaft zu reflektieren. 4.7.1 Abbildung auf das Referenzmodell Die Gestaltungsempfehlung 2.3 empfiehlt das systematische Management eines Portfolios ganzheitlicher Integrationslösungen, um auf diese Weise bestehende und geplante Lösungen zur Anwendungsintegration in der IT-Landschaft bzgl. Effektivität und Effizienz zu optimieren. Beispiele für ganzheitliche Integrationslösungen sind unternehmensweit aufgestellte Data-Warehouse-Systeme oder das in Abschnitt 3.2.3.4 beschriebene RED-Transaktionsportal. Nach dem Verständnis der vorliegenden Arbeit sind solche Lösungen IT-Systeme, die systematisch unter Einbeziehung der Gesamtsicht auf das Unternehmen aus der Geschäftsstrategie- und der Geschäftsarchitektur hergeleitet werden. Als IT-Systeme unterliegen sie daher den Prozessen der strategischen Ebene, der Management-Ebene und der operativen Ebene, wie sie im IT-Prozessmodell der vorliegenden Arbeit beschrieben sind. Auf der Grundlage des entwickelten Referenzmodells zur ITProzesslandschaft und der in den Abschnitten 4.3 - 4.5 beschriebenen Verankerung des Integrationsmanagements können die sechs Aktivitäten des Modells den Bausteinen des Referenzmodells zugeordnet werden, wie in der folgenden Abbildung dargestellt.

244

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

Vorgehensmodell

4 Portfolio-Bewertung 1

2 Ganzheitliche Anforderungsanalyse

3

5 PortfolioEntwurf

Ist-Analyse

Laufendes Lebenszyklusmanagement

6 Implementierung geplanter Integrationslösungen

Referenzmodell

IT-Strategiedefinition

IT-Portfoliomanagement IT-Investitions- 5

IT-RessourcenPortfolio-Mgmnt

Portfolio-Management 2

3

5 IS-PortfolioManagement

Inventur

4

Infrastruktur-AssetManagement

M&B

Betrieb

1 3

Strategische Konzeption der Unternehmens-IT

Strategische IT-Planung

IT-ServiceManagement

IT-ArchitekturManagement

IT-KostenManagement

IT-Risiko-Management

Management von IT-Org. & IT-Landschaft

S&O

ChangeManagement

IT-ProjektDurchführung

IT-ProjektIncident-Management, Durchführung etc. Software Control & Distribution

5

Erweiterung/Erneuerung

Wartung / Weiterentwicklung

Systementwicklungsprozess

6

Betrieb & WeiterEntwicklung IT-Landschaft

Abbildung 111: Abbildung des Modells zum Management von Integrationslösungen auf die IT-Prozesslandschaft Dies bedeutet für die einzelnen Aktivitäten: ƒ Aktivität 1: ganzheitliche Anforderungsanalyse Die übergreifende Analyse von Geschäftsintegrationsanforderungen wird im Rahmen des Prozesses der strategischen Planung bei der Bestimmung strategischer Bedarfe der Geschäftsseite und der Aufstellung strategischer Handlungsfelder initiiert. ƒ

Aktivität 2: Ist-Analyse Initiiert durch den Prozess der strategischen Planung werden im Prozess ISPortfoliomanagement bestehende Integrationslösungen identifiziert und

4.7 Management ganzheitlicher Integrationslösungen in der IT-Prozesslandschaft

ƒ

ƒ

245

nach zuvor definierten Dimensionen253 bewertet. Die Bewertung bestehender Lösungen ist Bestandteil der Aktivität 4. Aktivität 3: Portfolioentwurf Der Entwurf eines Portfolios von Integrationslösungen schlägt sich auf der strategischen Ebene und der Managementebene der Prozesslandschaft nieder. Nach dem entwickelten Modell beantwortet die strategische Planung die Frage, was die zur Erhaltung der Leistungsfähigkeit des Unternehmens essenziellen IT-Systeme sind bzw. sein müssen. Details zur Beantwortung dieser Frage werden durch den Prozess des IS-Portfoliomanagements und die dort stattfindende Bewertung von IT-Systemen bereitgestellt. Dies schließt Integrationslösungen ein. Die Bewertung geplanter Integrationslösungen ist Bestandteil der Aktivität 4. Aktivität 5: Laufendes Lebenszyklusmanagement Die Planung des Lebenszyklus von IT-Systemen und damit auch von Integrationslösungen ist Aufgabe des Prozesses IS-Portfoliomanagement. Dies führt zur Planung entsprechender Investitionen – insbesondere in Form von IT-Projekten - im Rahmen des Projektportfolio-Managements. Die Umsetzung der vorgesehenen Lebenszyklusverläufe und der daraus abgeleiteten Projekte erfolgt auf operativer Ebene in den Prozessen der Erweiterung und Erneuerung und führt zum Aufbau neuer oder zur Restrukturierung bzw. Stilllegung bestehender Integrationslösungen (Aktivität 6). Die im Prozess IT-Architekturmanagement definierten IT-Prinzipien und IT-Standards definieren hierfür die Leitplanken.254

4.7.2 Reflexion der Gestaltungsempfehlung 2.3 Gestaltungsempfehlung 2.3 empfiehlt die Entwicklung und das Management eines Portfolios ganzheitlicher Integrationslösungen. Die Zielsetzung einer ganzheitlicher Integrationslösung kann so interpretiert werden, dass Leistungsanforderungen unterschiedlicher fachlicher Domänen an die Unternehmens-IT durch den Aufbau dieser Lösungen antizipiert werden sollen, um so die auf zukünftigen Integrationsanforderungen beruhende Komplexitätssteigerung der ITLandschaft zu begrenzen. Je nach Anspruch an die Integrationslösungen ist sie in dem in Abschnitt 4.6.3 entwickelten Modell in Segment 1 oder 2 zu positionie253 In Abschnitt 5.3.4.2.2 wird im Rahmen der Fallstudie zur SEB GRUPPE ein Modell zur Bewertung von Objekten des IS-Portfolios unter Einbeziehung des Integrationsmanagements entwickelt. Ein solches Modell bildet auch die Grundlage der Bewertung von Integrationslösungen. Im Rahmen der Fallstudie werden zwei Integrationslösungen exemplarisch bewertet. 254 IT-Integrationsarchitektur; siehe dazu Abschnitt 2.3.

246

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

ren: in Segment 1, wenn die Festlegung auf zu unterstützende fachliche Domänen unterbleibt, in Segment 2, wenn im Voraus eine Festlegung auf bestimmte Domänen erfolgt: 4

1

flexibel

Ganzheitliche Integrationslösung

adaptierbar

5 2

nicht adaptierbar

6

nicht agil

3

agil

Abbildung 112: Zielpositionierung einer ganzheitlichen Integrationslösung Wie im Falle der Analyse der Positionierung strategischer Geschäftsplattformen in Abschnitt 4.6.3.4 ergibt sich die Frage nach der Komplexität einer ITLandschaft, die auf ein Portfolio ganzheitlicher Integrationslösungen setzt. Wie in Abschnitt 4.6.1 gezeigt, kann die Komplexität einer solchen IT-Landschaft höher sein. Legt man zur Erfassung der Komplexität die entwickelte Kennzahl KITL zugrunde, so ist die Komplexität höher, wenn die mit der Einführung einer Integrationslösung verbundene Wirkung der Komplexitätsreduktion der Gesamtheit der IT-Systeme (KGI in KITL wird reduziert) durch die Wirkung der Komplexität dieser Integrationslösungen (MKX in KITL steigt) dominiert wird. Darüber hinaus stellt sich die Frage nach der Reaktionsfähigkeit und der Beherrschbarkeit ganzheitlicher Integrationslösungen. Besteht eine große Zahl von Informationsbeziehungen zwischen IT-Systemen und der Integrationslösung, so hängt die zeitgerechte Kompensation von Umweltänderungen, die auf diese Informationsbeziehungen wirken, davon ab, ob die Integrationslösung und ihre Betreuungsorganisation dazu auch in der Lage sind. Dies ist der Fall, wenn die erforderliche Ressourcenausstattung gewährleistet ist und die IS-Architektur der Integrationslösung keine grundsätzlichen Einschränkungen, etwa in Bezug auf die Rechtzeitigkeit von Datenlieferungen, verursacht. Außerdem muss gewähr-

4.8 Leitlinien zur Steigerung der Integrationseffizienz der Unternehmens-IT

247

leistet sein, dass die Theorie der Integrationslösung dauerhaft durch die Betreuungsorganisation beherrschbar bleibt und das System nicht in die Phase des Verlustes der Beherrschbarkeit255 eintritt. Diese Betrachtung unterstreicht, dass der Nutzen ganzheitlicher Integrationslösungen unter Berücksichtigung der Komplexität, der Reaktionsfähigkeit und des Komplexitätslebenszyklus systematisch gesteuert werden muss.256 Das beschriebene Vorgehensmodell zum Management eines Portfolios von Integrationslösungen schafft hierzu die Voraussetzungen. 4.8 Leitlinien zur Steigerung der Integrationseffizienz der Unternehmens-IT Die Integrationseffizienz IE257 wurde in Abschnitt 3.2.2, ausgehend von einer Arbeit von SCHWINN, als Größe zur Bestimmung der Leistungsfähigkeit der Unternehmens-IT bei der Erbringung von Integrationsleistungen eingeführt. Die IE zugrunde liegende Formel wurde unter der Annahme aufgestellt, dass die größte Veränderungswirkung auf die IT-Landschaft von IT-Projekten ausgeht. Da die Komplexität der in einem Projekt bearbeiteten Integrationsanforderungen variiert, werden die je IT-Projekt erbrachten Aufwände für Integrationsleistungen in der Kennzahl, wie von SCHWINN vorgeschlagen, mit der Bewertung der Anforderungskomplexität gewichtet. Die so gewichteten Aufwände werden in IE über alle Projekte für eine definierte Periode summiert und gemittelt. Hier ergibt sich die Problematik der Abschätzung der Anforderungskomplexität. Integrationsanforderungen in der IT-Landschaft beziehen sich auf die Anpassung bestehender oder den Aufbau neuer Informationsbeziehungen zwischen Systemen. Informationsbeziehungen manifestieren sich, wie in Abschnitt 2.2.3.4 beschrieben, auf logischer Ebene in Form von Informationsflüssen, die auf physischer Ebene als Datenflüsse mithilfe von Schnittstellen und den zugehörigen Programmmodulen, Übergabestrukturen, Lieferdateien etc. implementiert werden. Hier ergibt sich der Vorschlag, die Komplexität der Integrationsanforderungen in einem Projekt über die Komplexität der betroffenen Informationsflüsse zu erfassen. Somit kann die Kennzahl IE zur Kennzahl IE verfeinert werden: 255

Siehe Abbildung 105. Im Rahmen einer umfassenden Fallstudie werden im 5. Kapitel Integrationslösungen eines Großunternehmens analysiert. 256

෤ N

257

IE =

i=1

[ IAi × IKi] , N = Zahl der Projekte, im betrachteten Zeitraum, IAi = Aufwand für IntegN

rationsleistungen im Projekt i, IKi = Komplexitätsbewertung der Integrationsanforderungen im Projekt.

248

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

IE (t) = Integrationseffizienz im Zeitraum t-1 bis t = N

Ni

i=1

j=1

䌥(䌥IK × IA ) ij

,

ij

M×N

mit N =

Anzahl IT-Projekte im Betrachtungszeitraum t-1 bis t

IAij = Aufwand der IT-Organisation für die Anpassung des Informationsflusses ij im IT-Projekt, i, j = 1,…,Ni, Ni = Zahl der im IT-Projekt i betroffenen Informationsflüsse, i=1…N IKij = Bewertung der Komplexität des Informationsflusses ij, 0 ˺IKij ˺1 M = Anzahl der IT-Systeme in der IT-Landschaft zum Zeitpunkt t

Formel 18:

Integrationseffizienz auf Basis der Bewertung von Informationsflüssen

In der Formel werden die mit der Komplexität gewichteten Aufwände für die Anpassung bzw. die Realisierung der in IT-Projekten bearbeiteten Informationsflüsse summiert und mit der Zahl der IT-Systeme gemittelt. Diese Gewichtung ist notwendig, um die Schwankungen der Zahl der IT-Systeme im Zeitablauf auszugleichen. Entsprechend ergibt sich die Notwendigkeit zur Mittelung mit der Zahl der Projekte, um Schwankungen der Menge der Integrationsanforderungen im Beobachtungszeitraum auszugleichen, wobei hier die Annahme zugrunde liegt, dass sich diese Schwankungen in der Zahl der durchgeführten ITProjekte manifestieren. Zusammengefasst drückt die Kennzahl IE die mit der Komplexität der Informationsflüsse gewichteten durchschnittlichen Integrationsaufwände je ITProjekt im Beobachtungszeitraum aus. Aus der Weiterentwicklung von IE zu IE ergeben sich die folgenden, aufeinander aufbauenden Empfehlungen zur Durchführung von Maßnahmen zur Verbesserung der Integrationseffizienz der ITOrganisation: 1.

Standardisierung durch o Reduktion der Vielfalt der für die Implementierung von Informationsflüssen zulässigen Design-Varianten, Vorgehensweisen, Werkzeuge und Technologien mithilfe der Definition von Referenzintegrationsar-

4.9 Zusammenfassung

2.

249

chitekturen258 als Teil der IT-Integrationsarchitektur259 des Unternehmens o Aufbau und systematisches Management eines Portfolios von Integrationslösungen auf der Basis definierter Referenz-Integrationsarchitekturen260 Verbesserung des Analyse, Design- und Entwicklungs-Knowhows der Mitarbeiter in Bezug auf die Implementierung von Informationsflüssen im Rahmen der vorgenommenen Standardisierung

4.9 Zusammenfassung Zielsetzung des 4. Kapitels war die Verfeinerung der im dritten Kapitel entwickelten übergreifenden Gestaltungsempfehlungen. Zunächst wurde der Verfeinerungsbedarf festgelegt. Anschließend wurde - abgestimmt auf den für die vorliegende Arbeit gewählten Ansatz zur Unternehmensarchitektur - ein Referenzmodell zur IT-Prozesslandschaft entwickelt. Entlang dieses Referenzmodells wurden dann in mehreren Schritten Empfehlungen zur Verankerung des Integrationsmanagements in den IT-Prozessen erarbeitet. Das Ergebnis ist ein erweitertes Gesamtmodell zur Planung, zum Management sowie zum Betrieb und zur operativen Weiterentwicklung der IT-Landschaft. Die Prozesse der strategischen ITPlanung, des IT-Portfoliomanagements und der IT-Projektdurchführung stehen im Mittelpunkt dieses Modells, wobei die Prozesse des IT-Portfoliomanagements in ihrer Rolle des Integrators in der IT-Prozesslandschaft hervorzuheben sind. Zusammen mit der Entwicklung dieses Modells wurde ein Kennzahlensystem zur Steuerung der Unternehmens-IT im Sinne eines ganzheitlichen Integrationsmanagements entwickelt und in der IT-Prozesslandschaft verankert. Aufgrund der in den Kapiteln 2 und 3 beschriebenen fundamentalen Bedeutung des Komplexitätsmanagements für das Integrationsmanagement liegt der Schwerpunkt des Kennzahlensystems auf der Messung der Komplexität der Unternehmens-IT und hier auf der IT-Landschaft. Die mehrdimensionale Kennzahl KITL zur Komplexität der IT-Landschaft und deren Transformation in eindimensionale Größen sind hier hervorzuheben. Anschließend wurden ergänzende Leitlinien zur Organisation der IT-Landschaft erarbeitet. Zunächst wurden ergänzende Leitlinien zum Komplexitätsmanagement aufgestellt. Hier spielte die Abhängigkeit der Komplexität von der Wahrnehmung der die Komplexität bewertenden Individuen eine wesentliche Rolle. Ein an der Komplexität und der Beherrschbarkeit von IT-Systemen ausgerichte258

Zum Artefakt der Referenzarchitektur vgl. [Dern09], S. 50 ff. Zur IT-Integrationsarchitektur siehe Abschnitt 2.3. 260 Das entsprechende Modell ist in Abschnitt 3.2.2.4 beschrieben. 259

250

4 Verfeinerung der übergeordneten Gestaltungsempfehlungen

tes Lebenszyklusmodell wurde aufgestellt, in der IT-Prozesslandschaft positioniert und durch Überlegungen zur Adaptierbarkeit, Flexibilität, Agilität und Beherrschbarkeit von IT-Landschaft und IT-Systemen vervollständigt. Damit war es möglich, Empfehlungen zur proaktiven Gestaltung von IT-Landschaften in Bezug auf zukünftige Übernahmen, Fusionen bzw. Abspaltungen aufzustellen. Den Abschluss des vierten Kapitels bildeten die ergänzende Betrachtung ganzheitlicher Integrationslösungen und die Aufstellung von Empfehlungen zur Steigerung der Integrationseffizienz der Unternehmens-IT. Als Gesamtergebnis liegt nun das Gesamtkonzept zum Integrationsmanagement in der Unternehmens-IT in Form eines Systems von Gestaltungsprinzipien (Kapitel 2), übergeordneten Gestaltungsempfehlungen (Kapitel 3) und den im 4. Kapitel erarbeiteten verfeinernden Gestaltungsempfehlungen vor. Abbildung 113 fasst dieses Gesamtkonzept zusammen. Wie im Forschungsdesign der vorliegenden Arbeit festgelegt, wird im 5. Kapitel die Evaluierung vorgenommen. Gestaltungsprinzipien Verständnis der Unternehmens-IT als komplexes Teilsystem des Unternehmens

Integrationsmanagement folgt umfassendem Spektrum von Integrationsanforderungen

Integrationsmanagement als Teildisziplin des IT-Managements

Integrationsmanagement innerhalb der Leitplanken einer IT-Unternehmens-architektur

Übergreifende Gestaltungsempfehlungen Komplexitätsmanagement in der Unternehmens-IT

Gestaltung ganzheitlicher Integrationslösungen

Aufbau einer integrierten Informationswirtschaft in verteilt organisierten Unternehmen

Handlungsmuster für die Integration der Unternehmens-IT bei Fusionen und Übernahmen

Unternehmens-IT und adaptive Unternehmensarchitekturen

Verfeinerung der übergreifenden Gestaltungsempfehlungen Rahmen: Referenzmodell zur IT-Prozesslandschaft (IT-Prozessarchitektur) Kennzahlensystem zum Integrationsmanagement Komplexität der Unternehmens-IT

Integrationseffizienz

…

Ergänzende Leitlinien Reflexion Kennzahlensystem

Lebenszyklusmanagement

Ergänzende Betrachtungen zu Integrationslösungen

Adaptierbarkeit, Flexibilität, Agilität

Empfehlungen zur Steigerung der Integrationseffizienz

Abbildung 113: Konzept zum Integrationsmanagement als System von Gestaltungsempfehlungen

5 Evaluierung des Konzeptes zum Integrationsmanagement Das Ziel des fünften Kapitels besteht in der Evaluierung des entwickelten Konzeptes zum ganzheitlichen Integrationsmanagement. Im Forschungsdesign ist festgelegt, dass die Forschungsziele nach dem Forschungsparadigma des DesignScience-Ansatzes, d. h. konstruktionsorientiert bearbeitetet werden. Als Artefakte der Konstruktion wurden in den Kapiteln 3 und 4 Definitionen, Modelle und Methoden entwickelt und in das in Abbildung 113 zusammengefasste System von Gestaltungsempfehlungen überführt. Dieses System ist durch Überprüfung der Gestaltungsempfehlungen zu evaluieren. 5.1 Festlegung des Evaluierungsansatzes Im Prinzip können Artefakte, die in Bezug auf formulierte Problemstellungen einen Nutzen erzeugen sollen, nur durch Feldexperimente evaluiert werden. Dies würde im Falle des vorliegenden Konzeptes dessen Implementierung im betrieblichen Umfeld größerer Unternehmen bedeuten. Dies setzt voraus, dass sich Unternehmen finden, die sich für die Anwendung der Gestaltungsempfehlungen und der darin enthaltenen Modelle und Methoden während des gesamten Forschungsprozesses zur Verfügung stellen. Nach FRANK261 ist die vollständige Implementierung der Artefakte einer wissenschaftlichen Arbeit häufig nicht realisierbar. FRANK262 weist darüber hinaus darauf hin, dass die Implementierung in einem einzigen Fall zum Nachweis der Effektivität und der Effizienz der Artefakte nur dann ausreicht, wenn dieser eine Fall als repräsentativ für alle anderen Fälle angesehen werden kann. Für die Durchführung mehrerer Feldexperimente zur Überprüfung der vorliegenden Arbeit stehen dem Autor nicht mehrere Unternehmen zur Verfügung. Zudem ist der notwendige zeitliche Rahmen nicht gegeben, um Feldexperimente in mehreren Unternehmen durchzuführen. Aus diesem Grund kommt die Methode der Fallstudie zur Anwendung. Bei der Anwendung dieser Methode zur Evaluierung des vorliegenden umfassenden Konzeptes ist zu berücksichtigen, dass Fallstudien idealerweise ermöglichen sollten, möglichst umfassend die konstruierten Artefakte, also die aufgestellten Gestaltungsempfehlungen (Kapitel 3) und deren Verfeinerungen (Kapitel 4), anzuwenden und dabei zu überprüfen. Daraus ergibt sich die Forderung nach möglichst breit angelegten Fallstudien. Bei der Auswahl geeigneter Fallstudien ist ferner zu bedenken, dass das für die 261 262

Vgl. [Frank06], S. 11. Vgl. [Frank06], S. 54.

G. Dern, Integrationsmanagement in der Unternehmens-IT, DOI 10.1007/978-3-8348-8154-0_5, © Vieweg+Teubner Verlag | Springer Fachmedien Wiesbaden GmbH 2011

252

5 Evaluierung des Konzeptes zum Integrationsmanagement

Arbeit gewählte Paradigma des Design-Science-Ansatzes die Konstruktion neuer Artefakte für die definierte Problemstellung verlangt. Folglich hat bisher kein Unternehmen seine Unternehmens-IT im Sinne der in der vorliegenden Arbeit entwickelten Artefakte aufgestellt. Aufgrund dieser Rahmenbedingungen kommt ein pragmatischer Ansatz zur Anwendung. Innerhalb einer breit aufgestellten, umfassenden Fallstudie wird die Unternehmens-IT eines Unternehmens durch die Anwendung von Gestaltungsempfehlungen möglichst umfassend und unter Einbeziehung mehrerer ITProjekte analysiert und bewertet. Die Problemstellung des betrachteten Unternehmens muss innerhalb der als Ausgangspunkt des Forschungsdesigns der vorliegenden Arbeit im ersten Kapitel beschriebenen Problemstellung liegen. Für die Durchführung der Fallstudie wird daher ein Unternehmen benötigt, über das ein so breites und gleichzeitig detailliertes Wissen zu Unternehmensarchitektur, Unternehmens-IT, IT-Prozessen, IT-Portfolio und IT-Projekten vorliegt, dass ein möglichst großer Teil der entwickelten Gestaltungsempfehlungen angewendet und überprüft werden kann. Für dieses Unternehmen ist die Situation der Unternehmens-IT - möglichst unter Einbeziehung ausgewählter, zur Problemstellung passender IT-Projekte - zu analysieren. Ohne längere intensive Auseinandersetzung mit einem Unternehmen ist das für den beschriebenen Ansatz zur Evaluierung notwendige breite und detaillierte Wissen nicht verfügbar. Aus diesem Grund wird für die Fallstudie die SEB GRUPPE herangezogen. Der Autor der vorliegenden Arbeit ist seit mehreren Jahren als Chief IT Architect für das Unternehmen tätig und verfügt daher über die notwendigen umfassenden und detaillierten Kenntnisse, um die Fallstudie wie beschrieben durchzuführen. 5.2 Evaluierungsmethode SENGER UND ÖSTERLE entwickeln in [SenÖst04] unter der Bezeichnung Promet BECS eine Fallstudienmethodik (i. S. eines Vorgehensmodells) für die Erstellung von Forschungs- und Lehrfallstudien im Business Engineering und verwandten Themenstellungen. Diese Methode wird auf Basis der im vorangehenden Abschnitt angestellten Überlegungen auf die vorliegende Arbeit adaptiert. Die so aufgestellte Evaluierungsmethode besteht aus den folgenden Hauptschritten: ƒ

ƒ

Unternehmensprofil des Unternehmens o Beschreibung der Eckdaten zum Unternehmen, seiner Positionierung sowie der Herausforderungen, denen sich das Unternehmen gegenübersieht und die für die Fallstudie wesentlich sind Problemstellung der Unternehmens-IT

253

5.2 Evaluierungsmethode

Beschreibung der Ausgangssituation und der Herausforderungen, denen sich die Unternehmens-IT gegenübersieht und die für die Fallstudie wesentlich sind o Vorstellung ausgewählter IT-Projekte des Unternehmens Analyse o Beschreibung der in den ausgewählten Projekten angewandten Vorgehensweisen und der erzielten Ergebnisse o Anwendung der entwickelten Artefakte: Analyse und Bewertung der Situation der Unternehmens-IT und der vorgestellten IT-Projekte auf Basis der Gestaltungsempfehlungen Optimierung o Anwendung der entwickelten Artefakte: Aufstellung optimierter Vorgehensweisen für die Unternehmens-IT und die vorgestellten ITProjekte auf Basis der Gestaltungsempfehlungen Ergebnisbewertung o Bewertung der Ergebnisse der Fallstudie in Bezug auf die geforderte Evaluierung der Gestaltungsempfehlungen – wurden Gestaltungsempfehlungen bestätigt oder widerlegt? o Darstellung der durch die Evaluierung erreichten Abdeckung des Konzeptes o

ƒ

ƒ

ƒ

Die folgende Abbildung fasst die Evaluierungsmethode zusammen. Unternehmensprofil und Herausforderungen? Profil der Unternehmens-IT, Herausforderungen, IT-Projekte? Analyse & Bewertung Zur Zeit angewandte Vorgehensweisen und erzielte Ergebnisse?

Anwendung Artefakte: Bewertung Vorgehensweisen & Ergebnisse auf Basis der entwickelten Gestaltungsempfehlungen

Anwendung Artefakte: Optimierung auf Basis der entwickelten Gestaltungsempfehlungen

Bewertung Evaluierung

Abbildung 114: Methode zur Durchführung der Fallstudie

254

5 Evaluierung des Konzeptes zum Integrationsmanagement

5.3 Fallstudie SEB GRUPPE 5.3.1 Unternehmensprofil Die SEB GRUPPE263 mit Sitz in Stockholm ist eine der führenden Finanzgruppen in Nordeuropa. Die SEB GRUPPE besteht seit über 150 Jahren, betreut mehr als fünf Millionen Privatkunden, 400.000 kleine und mittlere Unternehmen (SME) sowie 1.500 Großunternehmen und Institutionen mit 600 Filialen und Standorten in 20 Ländern. Kernmärkte der Gruppe sind Nordeuropa (Skandinavien und Baltikum) und Deutschland. Die SEB GRUPPE definiert ihren Geschäftszweck in der Bereitstellung von Finanzdienstleistungen, dem Management finanzieller Risiken und der Durchführung von Transaktionen für Privatkunden, mittlere und kleinere Unternehmen sowie Großunternehmen und Institutionen. Im Rahmen dieses Zweckes wird die Zielsetzung verfolgt, in den bearbeiteten Märkten der Finanzdienstleister mit der höchsten Kundenzufriedenheit zu sein, nachhaltiges Wachstum zu kreieren und in der Öffentlichkeit als good corporate citizen wahrgenommen zu werden. Bis 2005 war die strategische Konzeption der SEB GRUPPE auf organisches Wachstum in den Kernmärkten, Akquisitionen in neuen Märkten und Schaffung einer OneSEB-Kultur im gesamten Konzern ausgerichtet. 2006 wurde die strategische Konzeption justiert und zielt seitdem auf Gewinnwachstum durch Fokussierung auf proaktiven Kunden-Service in bestehenden Märkten, auf Operational Excellence264 und auf beschleunigte Unternehmensintegration auf der Grundlage der weiterentwickelten OneSEB-Kultur. Innerhalb dieser strategischen Konzeption folgt die SEB GRUPPE einer Wettbewerbspositionierung, die in Anlehnung an WARD UND PEPPARD265 entlang der Dimensionen KundenService und Operational Excellence, Kostenführerschaft und Produktführerschaft folgendermaßen dargestellt werden kann.

263

Börsennotiert unter SEB AB. Operations Excellence ist als der Anspruch zu verstehen, die aus dem definierten Geschäftszweck hervorgehenden Geschäftsprozesse besonders gut, d. h. besser als vergleichbare Unternehmen durchzuführen. Im Falle der SEB sind dies die Prozesse der Bereiche Finanzierung, Risikomanagement und Transaktionsabwicklung. 265 Vgl. [WaPe02], S. 111 ff. 264

255

5.3 Fallstudie SEB GRUPPE

Kunden-Service & Operational Excellence

KostenFührerschaft

ProduktFührerschaft

Abbildung 115: Strategische Wettbewerbspositionierung der SEB GRUPPE266 Die SEB GRUPPE definiert fünf strategische Geschäftsfelder - Retail Banking (Privatkunden), Merchant Banking (Unternehmen, Institutionen und gewerbliche Immobilienkunden), Wealth Management (Vermögensverwaltung), Life (Personenversicherungen) und Baltikum - die innerhalb der divisionalen Struktur des Unternehmens als Divisionen abgebildet sind. Diese divisionale Struktur führt im Verbund mit divisionsübergreifend aufgestellten Einheiten der Gruppe - Group Operations (Abwicklung und Services), Group Staff (Finanzwesen, Treasury, Risiko Controlling, …), Group IT (Entwicklung und Betrieb der IT-Landschaft) - zu einer ausgeprägt matrixorientierten Organisationsstruktur.

Abbildung 116: Divisionale Struktur SEB GRUPPE267

266 267

Abbildung auf Basis [Dern09], S. 308. Quelle: SEB Gruppe.

256

5 Evaluierung des Konzeptes zum Integrationsmanagement

Eine der zentralen Herausforderungen der SEB GRUPPE besteht - nicht zuletzt aufgrund der Situation an den internationalen Finanzmärkten, aber auch wegen der speziellen Situation in den baltischen Märkten – in der Verbesserung des Risikomanagements auf allen Ebenen der Finanzgruppe. Die SEB AG ist 100%-ige Tochter der SEB AB und operiert als Universalbank in Deutschland. Die SEB AG betreute 2008 als Pfandbrief emittierende, deutsche Universalbank rund eine Million Kunden und ist in den Geschäftsfeldern Retail Banking, Merchant Banking und Wealth Management positioniert. Die Organisation der SEB AG folgt im Rahmen der Erfordernisse der lokalen Gesetzgebung der oben beschriebenen Struktur der Gruppe, d. h. Divisionen bearbeiten die genannten Geschäftsfelder und interagieren mit lokalen Ablegern der divisionsübergreifenden Einheiten Group Staff, Group IT und Group Operations. 5.3.2 Problemstellung Unternehmens-IT der SEB GRUPPE 5.3.2.1 Ausgangssituation und Herausforderungen Die Unternehmens-IT der SEB GRUPPE umfasst eine IT-Landschaft von ca. 1.500 IT-Systemen inklusive der zugrunde liegenden IT-Basisinfrastruktur. Die IT-Landschaft wird in Rechenzentren in Stockholm und Riga durch Group IT betrieben und weiterentwickelt. Die IT-Prozesslandschaft folgt dem divisionalen Ansatz der Gruppe. Während die IT-Prozesse der operativen Ebene im Wesentlichen durch Group IT abgedeckt werden, sind die IT-Prozesse der ManagementEbene sowie der strategischen Ebene verteilt über Group IT, die Divisionen, Group Operations und Group Staff organisiert. So werden beispielsweise die Prozesse zur strategischen Konzeption der Unternehmens-IT durch Organisationseinheiten aus den Divisionen, Group Staff, Group Operations und Group IT wahrgenommen und über entsprechende Gremien koordiniert. Der Prozess der IT-Strategiedefinition der Gruppe wird durch den CIO (Chief Information Officer) der Gruppe verantwortet. Die IT-Strategie wird im Rahmen der jährlich durchgeführten strategischen IT-Planung auf Ebene der Divisionen und auf Ebene des Konzerns in strategische Mehrjahres-IT-Pläne überführt bzw. aktualisiert. Grundlage der IT-Planung der Gruppe und ihrer Divisionen ist die aus der strategischen Konzeption des Unternehmens und seiner Divisionen abgeleitete Zielsituationen zur IT-Landschaft (SEB: IT-Target). Dies ist verbunden mit der Festlegung strategischer Geschäftsplattformen, ITSysteme sowie IT-Plattformen der IT-Basisinfrastruktur. Die IT-Strategie der

5.3 Fallstudie SEB GRUPPE

257

SEB GRUPPE adressiert folgende Aspekte zur Ausrichtung der UnternehmensIT:268 ƒ ƒ ƒ

ƒ ƒ

ƒ ƒ

Rolle und Beitrag der Unternehmens-IT bei der Umsetzung der strategischen Konzeption des Unternehmens (Rolle der Unternehmens-IT) Governance – Wie wird die Unternehmens-IT gesteuert, wie erfolgen Entscheidungen und wie wird die Unternehmens-IT finanziert (IT-GovernanceAnsatz und IT-Funding-Ansatz)? Applications (IS-Strategie) – Welchen Beitrag leisten IT-Systeme bei der Umsetzung der strategischen Konzeption, wie unterstützen sie Geschäftsprozesse, was sind strategische Geschäftsplattformen der Gruppe und wie ist das Lebenszyklusmanagement der IT-Systeme zu organisieren? Operations (IS-Strategie/Technologiestrategie) – Wie sollen der Betriebund die Weiterentwicklung der IT-Landschaft organisiert sein? Infrastructure (Technologiestrategie) – Welchen Beitrag leistet die ITBasisinfrastruktur bei der Umsetzung der strategischen Konzeption, welche IT-Plattformstrategie wird verfolgt und wie ist das Lebenszyklusmanagement der IT-Infrastruktur-Assets zu organisieren? IT-Architecture (im IT-Plan) – Welche Standards, Prinzipien und Leitlinien (SEB: IT-Architecture Framework) gelten? Sourcing-Strategie - Welche Kompetenzen, Leistungen und Lösungen sollen intern bereitgestellt und welche von extern bezogen werden?

Für die Fallstudie sind die folgenden Aspekte der strategischen Konzeption der Unternehmens-IT von besonderer Bedeutung: ƒ

Zur Befriedigung der Informationsbedarfe der Divisionen, von Group Operations und von Group Staff und zur Unterstützung der Effizienzziele des Unternehmens wird die Vereinheitlichungen der IT-Landschaft mithilfe des Aufbaus und der Integration von Gruppen-Geschäftsplattformen269, Gruppen-Geschäftsinfrastruktursystemen (SEB: Supporting Applications) und Gruppen-IT-Plattformen (SEB: Standard Platforms) angestrebt.270

268 Die Struktur der IT-Strategie bewegt sich somit innerhalb des in der vorliegenden Arbeit in Abschnitt 4.3 beschriebenen Modells zur strategischen Konzeption der Unternehmens-IT. Elemente dieses Modells sind jeweils in Klammern vermerkt. 269 Daraus erwächst zum Beispiel die Anwendungsintegrationsanforderung (siehe dazu Abschnitt 3.2.2), positionsführende Systeme aus allen Divisionen mit einer Standard-Geschäftsplattform zur Unternehmenssteuerung zu integrieren. 270 Gruppen-Geschäftsplattformen sind als Teilsysteme der IT-Landschaft zu verstehen, die sich aus mehreren IT-Systemen konstituieren und die darauf ausgerichtet sind, bestimmte Geschäftsprozesse gruppenweit einheitlich zu unterstützen. Gruppen-Geschäftsinfrastruktursysteme stellen zur Unter-

258 ƒ

ƒ

ƒ

5 Evaluierung des Konzeptes zum Integrationsmanagement

In der SEB GRUPPE wird wachsende Komplexität der IT-Landschaft als Hindernis der zeitgerechten Erfüllung von Leistungsanforderungen und als Treiber hoher IT-Kosten betrachtet271. Als Ursache wird die übermäßige Vielfalt in der IT-Landschaft und - verbunden damit - die unzureichende Beherrschbarkeit wichtiger IT-Systeme gesehen.272 Die Vielfalt führt aus Sicht der SEB dazu, dass Leistungsanforderungen nur mithilfe umfangreicher Integrationsleistungen erfüllt werden können. Komplexitätsreduktion und damit verbunden Effizienzsteigerungen sollen erreicht werden, indem o Gruppen-Plattformen ausgerollt und mit Teil-IT-Landschaften der verschiedenen Länder und Divisionen integriert werden, o in den verschiedenen Standorten der Divisionen zur Unterstützung ähnlicher Geschäftsfunktionen dieselben IT-Systeme (SEB: Common Applications) eingeführt und in die jeweiligen Teil-IT-Landschaften integriert werden, o aktiv bestehende Systeme bei geringem Geschäftsnutzen oder Redundanz zu anderen Systemen rückgebaut und abgeschaltet werden. Zur Unterstützung weiterer Akquisitionen wird der Aufbau einer Kerngeschäftsplattform für neue Märkte angestrebt, die eine zugekaufte, den Erfordernissen der SEB GRUPPE angepasste Kernbankenplattform in den Mittelpunkt stellt, die mit Geschäftsplattformen und Geschäftsinfrastruktursystemen der Gruppe integriert ist und auf Standard-IT-Plattformen der Gruppe betrieben wird. Für die IT-Prozesse der operativen Ebene wird die gruppenweite Vereinheitlichung angestrebt, um die Effektivität und Effizienz zu steigern. Hervorzuheben sind das so genannte SEB Business Oriented Maintenance Model zur Standardisierung der Prozesse der Wartung und der Weiterentwicklung, der Prozess zur standardisierten Projektdurchführung (SEB: Process for Ventures) und der Systementwicklungsprozess (SEB: Unified Process) zur einheitlichen Durchführung der Entwicklung von IT-Systemen in der gesamten Gruppe.

stützung der Durchführung von Geschäftsprozessen standardisierte Dienste bereit - wie zum Beispiel die Dokumenten-Archivierung. Ganzheitliche Integrationslösungen wie Data-Warehouse-Systeme fallen ebenfalls in diese Kategorie. Gruppen-IT-Plattformen sind als Teilsysteme der ITBasisinfrastruktur zu verstehen, die die Laufzeitumgebung für bestimmte Anwendungstypen standardisiert zu Verfügung stellen. 271 Komplexitätsmanagement ist als strategisches Handlungsfeld im strategischen IT-Plan der SEB GRUPPE und der SEB AG verankert. 272 Ein Beispiel hierfür ist das Depotsystem der SEB AG. Die Theorie des Systems wird unzureichend beherrscht. Dementsprechend führt die Implementierung von Leistungsanforderungen zu Komplexitätssteigerung, die nicht ausschließlich in den Anforderungen begründet ist.

259

5.3 Fallstudie SEB GRUPPE

In der strategischen Konzeption der Unternehmens-IT der SEB GRUPPE ergibt sich somit - als Teil der IT-Unternehmensarchitektur - das folgende konzeptionelle Zielbild der IT-Landschaft. Strategische Konzeption SEB Gruppe Effizienzziele

Effizienzziele InformationsEffizienzziele bedarfe

Effizienzziele Effizienzziele

IT-Landschaft SEB Gruppe Ebene der Informationssysteme

Standardisierte Informationssysteme

Informationssysteme für spezielle Geschäftsfunktionen

Systeme mit geringem Nutzen / redundante Systeme

Gruppen-Geschäftsplattformen

Gruppen-IT-Plattformen

GruppenGeschäftsinfrastruktursysteme

Geschäftsanwendungen der Divisionen, Group Operations & Group-Staff

Weitere Plattformen

Infrastrukturebene

BOMM

Unified Process

Process for Ventures

Standardisierte IT-Prozesse

Abbildung 117: IT-Unternehmensarchitektur der SEB GRUPPE - Zielsituation zur IT-Landschaft 5.3.2.2 Ausgewählte IT-Projekte Das IT-Portfolio der SEB GRUPPE umfasst verschiedene IT-Programme273 und IT-Projekte, die der Erreichung der oben beschriebenen Zielsituation dienen. Folgende Projekte aus dem IT-Projektportfolio werden im Rahmen der Fallstudie analysiert:274 273 Bei der SEB GRUPPE wird unter einem IT-Programm ein Bündel von IT-Projekten verstanden, das einer gemeinsamen Zielsetzung und Steuerung unterliegt. 274 Bezeichnungen der IT-Programme und –Projekte sowie der IT-Systeme der SEB im Rahmen der vorliegenden Arbeit verändert.

260 ƒ

ƒ

ƒ ƒ

5 Evaluierung des Konzeptes zum Integrationsmanagement

Risk Information Management (kurz RIM) - IT-Projekt zum Aufbau eines integrierten Risiko-Informationsmanagementsystems zur Verbesserung der Integration der SEB AG in die Risikomanagement-Prozesse der Gruppe und zur Erfüllung aufsichtrechtlicher Anforderungen PROG_GF (Programm Group Finance) - IT-Programm zum Aufbau der integrierten Gruppengeschäftsplattform PLAT_GrF (Group Finance Platform) für die Rechnungslegung, das Finanz Controlling und das Management Reporting sowohl auf Länder- als auch auf Gruppenebene Global Application Consolidation – IT-Programm zur Reduktion der Komplexität und zur Steigerung der Effizienz der IT-Landschaft der SEB GRUPPE DWH-Konsolidierung – IT-Programm zur Konsolidierung der DataWarehouse-Landschaft275 (kurz DWH-Landschaft) der SEB AG mit dem Ziel der Komplexitätsreduktion der IT-Landschaft

5.3.2.2.1

Das IT-Projekt Risk Information Management

Eine der Herausforderungen der SEB GRUPPE ist, wie oben ausgeführt, die Verbesserung des Risikomanagements der Gruppe. Deshalb strebt der verantwortliche Bereich Group Risk Control den Aufbau einer integrierten Risikomanagement-Plattform zur gruppenweit vereinheitlichten Steuerung der Markt-, der Liquiditäts- und der Ausfallrisiken an. Die Philosophie beim Aufbau dieser Geschäftsplattform besteht darin, Informationen aus allen Ländern und Divisionen entlang einer gemeinsamen Informationsarchitektur zu transformieren und in die Risikomanagement-Plattform zu integrieren. Treiber der Transformation sind die Informationsbedarfe von Group Risk Control und aufsichtsrechtliche Anforderungen. Dazu sind alle risikotragenden Positionen276 der in den verschiedenen Ländern der SEB GRUPPE vertretenen Divisionen und der Einheiten von Group Treasury277 gemäß der geforderten Datenqualität an die in der Plattform enthaltenen Systeme zur Risikomessung, Risikoanalyse, Risikobewertung und zum Risiko-Reporting zu liefern. Abbildung 118 fasst die Positionierung der Risikomanagement-Plattform 275 Das Teilsystem der IT-Landschaft, das sich aus den Data-Warehouse-Systemen konstituiert, wird als Data-Warehouse-Landschaft bezeichnet. 276 Risikotragende Positionen sind die Geschäfte einer Bank, die ein Risiko für die Liquidität oder das Ergebnis einer Bank beinhalten. Dies sind beispielsweise Wertpapiere im Eigenbestand oder Kredite an Kunden. Risiko ist dabei als negative Abweichung von definierten Zielgrößen zu verstehen – hier also in Bezug auf die Liquiditäts- bzw. Ertragsziele der Bank. 277 Die Einheiten von Treasury verantworten das Management des Bankportfolios. Teil dieser Funktion ist die Refinanzierung der Bank an den Geld- und Kapitalmärkten. Treasury hält daher selbst risikotragende Positionen, die durch Group Risk Control überwacht und gesteuert werden.

261

5.3 Fallstudie SEB GRUPPE

Informationstransformation

von Group Risk Control in der Unternehmensarchitektur der SEB GRUPPE zusammen. Der Fokus des Projektes Risk Information Management ist hervorgehoben.

PositionsStammdatenführende Systeme Systeme Quellsysteme D

Positionsführende Systeme

StammdatenSysteme

…

…

Quellsysteme SWE

…

Informations-bereitstellung

Informationsinfrastruktur D

Informationsinfrastruktur SWE

…

Integration und Informationsaufbereitung

Informationsbedarf

RisikoRisikoPositionen Positionen RETAIL Treasury

…

Marktrisiken

Liquiditätsrisiken

Ausfallrisiken

Risiko-Reporting

Risiko-Reporting

Risiko-Reporting

Risikomessung, -bewertung & -analyse

Risikomessung, -bewertung & -analyse

Risikomessung, -bewertung & -analyse

Informationsnutzung mittels Risikomanagement-Plattform Globale Steuerung Lokale Steuerung D

Lokale Steuerung SWE

…

Risikomanagement (Group Risk Control)

Abbildung 118: Risikomanagement-Plattform der SEB GRUPPE und Positionierung des Projektes RIM Die Zielsetzung des Projektes RIM besteht darin, die IT-Landschaft in Deutschland durch den Aufbau eines Risiko-Informationsmanagementsystems (kurz RIMS) zu optimieren, um so die von Group Risk Control geforderte Integration in die Gruppenplattform sicherzustellen und gleichzeitig aufsichtrechtliche Anforderungen zu erfüllen. Diese Zielsetzung zieht umfangreiche fachliche Anforderungen und Integrationsanforderungen nach sich. So besteht z. B. die Notwendigkeit der Realisierung eines IT-Systems zur Berechnung von Amortisations-Cashflows (kurz CF-Engine), welches mit allen positionsführenden Systemen integriert ist. Darüber hinaus ist die Einhaltung der Architekturstandards

262

5 Evaluierung des Konzeptes zum Integrationsmanagement

und -prinzipien der SEB GRUPPE eine der wesentlichen Rahmenbedingungen für das Projekt RIM. Architekturstandards und -prinzipien der SEB GRUPPE manifestieren sich im Projekt RIM insbesondere in der Forderung nach der Nutzung des globalen Business Information Warehouse (Konzern-BIW) zur Informationsaufbereitung und zur Integration. Das Konzern-BIW ist als gruppenweites Data Warehouse in der IT-Landschaft der Gruppe positioniert. Das Konzern-BIW hat die Aufgabe, Informationen aus den Systemen aller Divisionen und Länder so aufzubereiten, dass Funktionen der Unternehmenssteuerung – z. B. Risiko Controlling - sowie der Steuerungsfunktionen der Divisionen - z. B. der Vertriebssteuerung - lokal und global unterstützt werden. Es ergibt sich die folgende Positionierung des Konzern-BIW in der Unternehmensarchitektur der SEB.

Quellsysteme Deutschland

..

Life

Treasury

Life

Wealth

RETAIL

MB

…

Treasury

Wealth

RETAIL

MB

Informationsbereitstellung

…

Quellsysteme Schweden

Konzern-BIW Integration und Informationsaufbereitung

Lokale Steuerung D

Lokale Steuerung SWE

…

Globale Unternehmensteuerung

Lokale Steuerung D

Lokale Steuerung SWE

…

…

Globale Steuerung RETAIL

Informationsnutzung – integrierte Steuerung mit Hilfe von Informationssystemen

Abbildung 119: Positionierung des Konzern-BIW der SEB GRUPPE Komplexitätsreduktion der IT-Landschaft ist, wie o. a., eines der strategischen Handlungsfelder der Unternehmens-IT der SEB GRUPPE und findet daher auch in der strategischen Konzeption der SEB AG Berücksichtigung (s. u.). Für das Projekt RIM ergibt sich hier die Anforderung, IT-Lösungen aufzubauen, die

263

5.3 Fallstudie SEB GRUPPE

die Komplexität der IT-Landschaft nicht steigern, idealerweise senken. Für das Projekt RIM ergibt sich die folgende Gesamtsituation.

Projekt RIM IT-Projekt zum Aufbau eines integrierten Risiko-Management-Informations-Systems der SEB AG

Aufsichtsrechtliche Anforderungen

Komplexitätsreduktion SEB AG

Informationsbedarf Risikomanagement der SEB Gruppe

Architekturstandards und –prinzipien der SEB Gruppe

Abbildung 120: Treiber des Projektes RIM 5.3.2.2.2

IT-Programm PROG_GF der SEB GRUPPE

Haupttreiber im IT-Portfolio der SEB GRUPPE für das Konzern-BIW ist das ITProgramm zum Aufbau der integrierten Gruppengeschäftsplattform PLAT_GrF für die Rechnungslegung, das Finanz-Controlling und das Financial Management Reporting der SEB GRUPPE. Als Antwort auf den steigenden Informationsbedarf an konsolidierten, abgeglichenen Informationen aus allen Unternehmensteilen zur Unternehmenssteuerung in der Folge der Expansion und der Erweiterung des Produktangebotes der SEB GRUPPE wurde das Programm PROG_GF gestartet. Die SEB GRUPPE verfolgt mit dem Programm das Ziel, eine Financial Accounting- & ReportingPlattform (PLAT_GrF) zu schaffen, die es ermöglicht, innerhalb von fünf Banktagen die Bilanz sowie die Gewinn- und Verlustrechnung der Gruppe zu erstellen, langfristig die Kosten für Bilanzierung, Finanz-Controlling und Management-Reporting zu senken und für das Management des Konzerns und seiner Divisionen verlässliche Finanzinformationen (e. g. Profitabilitätskennzahlen für die Divisionen) zur Verfügung zu stellen. Für den Ausbau des Konzern-BIW bedingt dies die Fokussierung auf die Implementierung von Anforderungen der Bilanzierung, des Finanz-Controlling und des Financial Management Reporting.

264 5.3.2.2.3

5 Evaluierung des Konzeptes zum Integrationsmanagement

IT-Programm zur DWH-Konsolidierung der SEB AG

Zur Unterstützung des Handlungsfeldes Komplexitätsreduktion der ITLandschaft wurde das IT-Programm Data Warehouse Consolidation bei der SEB AG gestartet. Das Programm verfolgt die Zielsetzung, die Data-WarehouseLandschaft der SEB AG so zu konsolidieren, dass die Komplexität der ITLandschaft reduziert wird. Die IT-Landschaft der SEB AG umfasst mehrere Data-WarehouseSysteme278. Diese mehr oder weniger komplexen IT-Systeme sind in den vergangenen zwanzig Jahren unter Nutzung unterschiedlicher Technologien entstanden und decken Informationsbedarfe aus Prozessen der gesamten Geschäftsprozesslandschaft der SEB AG ab - dies jedoch weder überschneidungs- noch redundanzfrei. Die verschiedenen Data-Warehouse-Systeme werden von unterschiedlichen Einheiten der IT-Organisation gewartet, erneuert und weiterentwickelt. Abbildung 122 gibt einen Überblick über die Data-Warehouse-Systeme der SEB AG. Dazu wird auf das in der folgenden Abbildung dargestellte Referenzmodell zur Geschäftsprozesslandschaft der SEB AG zurückgegriffen, das in Form von Prozess-Clustern und Prozessgruppen die stark abstrahierte Grundstruktur der Geschäftsprozesslandschaft zeigt. Prozess-Cluster

Vertrieb & Kundenbetreuung

Beratung

Verkauf

Auskunft & Transaktionen

Verarbeitung & Abwicklung

Clearing

Settlement

KundenServices

Steuerung VertriebsFinancial PortfolioRisikosteuerung & Accounting, Management Reporting & Performance Management (Treasury) Management Planning

Compliance

Prozess-Gruppen innerhalb der Cluster

Abbildung 121: Referenzmodell zur Geschäftsprozesslandschaft der SEB AG279 Durch die Zuordnung von Data-Warehouse-Systemen zu Prozessgruppen entsteht folgende Bild zur Data-Warehouse-Landschaft der SEB AG.

278 Die Begriffe Anwendungssystem und Anwendung werden bei der SEB AG synonym zu IT-System verwendet. 279 Die Unternehmensarchitektur der SEB AG definiert im Cluster Vertrieb & Kundenbetreuung für jede Division eigenständige, voneinander unabhängige Geschäftsprozesse und darauf spezialisierte IT-Systeme. Gleiches gilt für die Prozessgruppe Vertriebssteuerung & Performance Management im Cluster Steuerung.

265

5.3 Fallstudie SEB GRUPPE

Informationsbereitstellung Quellsysteme Deutschland MB Positionen & Transaktionen

RETAIL Positionen & Transaktionen

Wealth Positionen & Transaktionen

Treasury Positionen & Transaktionen

Stammdaten

Integration und Informationsaufbereitung mittels DHW-Systemen STTS AG-BIW

DDB DWH-alt

Beratung

Verkauf

Auskunft & Transaktionen

Vertrieb & Kundenbetreuung

Clearing

Settlement

KundenServices

Verarbeitung & Abwicklung

Data1

Konzern-BIW

VertriebsFinancial Portfoliosteuerung & Accounting, RisikoPerformance Management Management Reporting & Management (Treasury) Planning

Compliance

Steuerung

Informationsnutzung mit Hilfe von Informationssystemen

Abbildung 122: Übersicht zur Data-Warehouse-Landschaft der SEB AG Deutlich wird, dass sechs Data-Warehouse-Systeme parallel mit Positionen, Transaktionen und Stammdaten aus Quellsystemen versorgt werden, um diese Informationen für die verschiedenen Prozess-Cluster und -Gruppen und die dort genutzten IT-Systeme aufzubereiten und bereitzustellen. Im Einzelnen sind folgende Punkte hervorzuheben: ƒ

ƒ ƒ ƒ

Das Konzern-BIW wird, der o. a. Strategie der Geschäftsplattform PLAT_GrF folgend, mit Informationen versorgt, um den Informationsbedarf der lokalen Rechnungslegung (Financial Accounting) als Teil der Finanzprozesse der SEB AG zu decken. Das Altsystem Data1 bildet die Basis der Informationsversorgung des Meldewesens (Financial Reporting), ebenfalls als Teil der Finanzprozesse. Data1 stellt darüber hinaus die Datenbasis für das operative Kreditrisikomanagement- und Limitsystem zur Verfügung. Das System wird zur Kundenengagement-Analyse bei der Kreditvergabe genutzt. Zur Informationsversorgung der Finanzprozesse wird außerdem das System STTS eingesetzt. Es unterstützt die Bestimmung von internen Transferpreisen für Kredite zwischen den Divisionen auf der einen und Treasury auf der andren Seite. STTS bildet zudem die Basis für die Erzeugung von IFRSBuchungen für die Rechnungslegung und stellt die Datenversorgung für das

266

ƒ

ƒ

ƒ

5 Evaluierung des Konzeptes zum Integrationsmanagement

operative Management von Zinsrisiken im Portfoliomanagement durch das Treasury der Bank sicher. Das Altsystem DDB stellt ebenfalls Daten für das Portfoliomanagement durch Treasury sowie für die Finanzplanung (Financial Planning) und zusätzlich für die Vertriebssteuerung bzw. das Performance-Management der Division Retail zur Verfügung. Das Business Information Warehouse der SEB AG (AG-BIW) folgt demselben logischen Modell wie das Konzern-BIW, wurde jedoch primär geschaffen, um Kundenbetreuungs- und Steuerungsprozesse der Division Retail mit Informationen zu versorgen. Das AG-BIW wird darüber hinaus zur Unterstützung von Compliance-Prozessen (z. B. Geldwäschevermeidung) genutzt. Daneben existiert das Altsystem DWH-alt zur Informationsversorgung des analytischen Kundenbeziehungsmanagements im Rahmen der Vertriebssteuerungsprozesse der Division Retail.

5.3.3 Analyse und Bewertung In diesem Abschnitt werden zunächst die im Rahmen der beschriebenen ITProgramme und IT-Projekte bei der SEB GRUPPE gewählten Vorgehensweisen und die erzielten Ergebnisse analysiert. Anschließend werden diese auf der Grundlage der in der vorliegenden Arbeit entwickelten Gestaltungsempfehlungen bewertet. 5.3.3.1 Analyse der Vorgehensweisen und Ergebnisse 5.3.3.1.1

Komplexitätsmanagement bei der SEB AG

Komplexitätsmanagement in der strategischen Konzeption Das Handlungsfeld Komplexitätsreduktion der IT-Landschaft ist in der strategischen Konzeption der Unternehmens-IT der SEB AG verankert. Obwohl in der strategischen Konzeption verankert, gibt es bei der SEB AG keine verbindliche und abgestimmte Definition von Komplexität der Unternehmens-IT. Insbesondere wird nicht zwischen Kompliziertheit und der Komplexität unterschieden, die sich zwingend aus der geschäftlichen Komplexität ergibt. Die strategische Konzeption der Unternehmens-IT der SEB AG beinhaltet keine Kennzahlen zur Messung und Steuerung der Komplexität der IT-Landschaft. Die Zielsetzung des Handlungsfeldes Komplexitätsreduktion der ITLandschaft besteht darin, die Komplexität der IT-Landschaft der SEB AG zu vermindern, indem die Vielfalt und die Anzahl von IT-Systemen und Informati-

5.3 Fallstudie SEB GRUPPE

267

onsflüssen verringert werden. Auf diese Weise sollen das übergeordnete Handlungsfeld der SEB GRUPPE zum Komplexitätsmanagement und das daraus hervorgegangene IT-Programm Gobal Application Consolidation unterstützt werden. Durch die Komplexitätsreduktion in der IT-Landschaft soll die Leistungsfähigkeit der Unternehmens-IT erhöht werden, sodass Anforderungen der Anwenderorganisation schneller und kostengünstiger umgesetzt werden können. Gleichzeitig soll durch Komplexitätsreduktion erreicht werden, dass Systeme mit unzureichender Beherrschbarkeit durch besser beherrschte Systeme ersetzt werden. Diese Zielsetzung der Komplexitätsreduktion basiert auf der Einschätzung der bestehenden Situation durch den CIO der SEB AG: Leistungen der Unternehmens-IT werden aufgrund der Vielfalt und der damit verbundenen Redundanz in Systemen und Informationsflüssen unnötigerweise mehrfach erbracht und bewirken unnötig zeitaufwendige und kostenintensive Projekte. Komplexitätsmanagement in den IT-Prozessen der Managementebene und der operativen Ebene Das Handlungsfeld zur Komplexitätsreduktion der IT-Landschaft der SEB AG findet sowohl in den IT-Prozessen der Management-Ebene als auch der operativen Ebene Berücksichtigung. Der Fokus liegt dabei auf der Bewertung der Komplexitätswirkung von IT-Projekten bzw. IT-Projektkandidaten im Rahmen des IT-Portfoliomanagements und im Rahmen der IT-Projektdurchführung. Komplexitätsanalysen zur IT-Landschaft erfolgen fallweise, projektzentriert, jedoch nicht durchgängig für alle Projekte. Sie werden durch die grobe Beurteilung der Komplexitätswirkung von IT-Projekten und IT-Projektkandidaten auf den jeweils relevanten Teil der IT-Landschaft durch beteiligte IT-Unternehmensarchitekten, IT-Portfoliomanager und Führungskräfte vorgenommen und führen im Kontext der jeweiligen Entscheidungssituation zur Priorisierung von Alternativen. Die Beurteilung beruht auf der erwarteten Veränderung der Zahl der ITSysteme und der Informationsflüsse mithilfe von Daten aus der EAM-Lösung der SEB AG. Die Komplexität der IT-Basisinfrastruktur, die Komplexität der einzelnen Systeme, die geschäftliche Komplexität sowie die Komplexität der ITOrganisation finden keine systematische Berücksichtigung. Zusammenfassend gilt für die IT-Prozesse der Management-Ebene und der operativen Ebene bei der SEB AG: ƒ

IT-Projekte und IT-Projektkandidaten werden im Rahmen des ITPortfoliomanagements regelmäßig durch IT-Unternehmensarchitekten und

268

ƒ

5 Evaluierung des Konzeptes zum Integrationsmanagement

IT-Portfoliomanager in Bezug auf ihre Komplexitätswirkung bewertet280. Diese Bewertung ist eines der Entscheidungskriterien, die bei der jährlichen der IT-Projektportfolioplanung angewandt werden. Lösungsalternativen, die bei der Durchführung von IT-Projekten aufgestellt werden, werden teilweise unter Berücksichtigung der Komplexitätswirkung priorisiert und entschieden.

Die IT-Projektdurchführung erfolgt bei der SEB AG entlang des oben beschriebenen IT-Prozesses der SEB GRUPPE, dem Process for Ventures. Im Prozess sind mehrere Entscheidungspunkte verankert, an denen ein Gremium aus Führungskräften aus der Anwender- und der IT-Organisation über die Durchführung des anstehenden Folgeschrittes (z. B. Start der Vorstudie) entscheidet. Grundlage hierfür bildet eine standardisierte Zusammenfassung der SEBspezifischen Business-Case-Analyse. Dieser Standard umfasst keine Aussage zur Komplexitätswirkung. Zusammenfassung Komplexitätsmanagement bei der SEB AG Die beschriebenen Vorgehensweisen der SEB AG zeigen, dass Komplexitätsmanagement aufgrund der Verankerung in der strategischen Konzeption in den Prozessen der Management-Ebene und der operativen Ebene Berücksichtigung findet, eine systematische, durchgängige und allgemein verbindliche Einbettung in die IT-Prozesslandschaft jedoch nicht gegeben ist. Über die Komplexitätswirkung hinausgehende Größen wie die Wirkung von IT-Projekten auf die Reaktionsfähigkeit der IT-Landschaft finden in Steuerungs- und Entscheidungsprozessen der SEB AG keine Berücksichtigung. Obwohl, wie oben angeführt, als Problem wahrgenommen, werden die in IT-Projekten erbrachten Integrationsleistungen nicht quantifiziert und erfasst, können daher nicht gezielt gesteuert werden. 5.3.3.1.2

IS-Portfoliomanagement bei der SEB AG

Im Prozess des IS-Portfoliomanagements der SEB AG findet die aktive Überwachung und Planung des Lebenszyklus von IT-Systemen statt. Verzahnt mit dem Prozess der strategischen IT-Planung, wird jedes IT-System jährlich in Bezug auf seine strukturelle und funktionale Qualität sowie auf die geschäftliche Bedeutung bewertet. Auf der Grundlage dieser Bewertung und der in der strategischen IT-Planung definierten Zielsituation zur IT-Landschaft wird für jedes System die grundsätzliche Richtung seiner Weiterentwicklung (SEB: Change Policy) für die nächsten drei Jahre definiert. Diese Bewertungen werden im Pro280

Von starke Erhöhung (--) bis starke Reduktion (++).

5.3 Fallstudie SEB GRUPPE

269

zess des IS-Portfoliomanagements definiert und im Rahmen des ITProjektportfolio-Managements genutzt. Ersteres berücksichtigt die Change Policy bei der Festlegung der Budgets für die Wartung und die Weiterentwicklung der Systeme, Letzteres leitet aus dem Systemstatus Optimierungsvorschläge in Form von IT-Projektkandidaten ab. Im Einzelnen sind die o. a. Größen folgendermaßen definiert: Der Systemstatus liefert einen Frühwarnindikator für den technischstrukturellen Zustand des Systems. Er basiert auf der Bewertung der technischstrukturellen und der funktionalen Qualität des Systems mithilfe der gleichen Ampelfunktion. Ausprägung

Bedeutung

rot

Mit 1-Jahres-Horizont sind massive technisch-strukturelle oder funktionale Defizite absehbar, die das Aufsetzen eines IT-Projektes erfordern, oder es sind Ressourcenengpässe zu erwarten, die eine dauerhafte Einschränkung des Service-Levels des Systems erwarten lassen. Mit 3-Jahres-Horizont besteht die Gefahr technisch-struktureller oder funktionaler Defizite, oder es sind Einschränken des ServiceLevels aufgrund von Ressourcenengpässen absehbar. Zurzeit sind keine technisch-strukturellen oder funktionalen Defizite erkennbar, die außergewöhnliche Maßnahmen erfordern.

gelb

grün

Tabelle 5:

Status von IT-Systemen bei der SEB AG

Der Business Value klassifiziert die Bedeutung eines IT-Systems für die Geschäftstätigkeit der Bank. Ausprägung

Bedeutung

hoch

Das System wird in Kerngeschäftsprozessen genutzt, ist essenziell für die Aufrechterhaltung des Geschäftsbetriebes oder für die Erreichung der Geschäftsziele einer Division. Das System wird in Kernprozessen genutzt oder ist essenziell für die Durchführung von Unterstützungsprozessen. Das System wird ausschließlich in Unterstützungsprozessen genutzt und nimmt hier keine zentrale Stellung ein.

mittel niedrig

Tabelle 6:

Business Value von IT-Systemen bei der SEB AG

270

5 Evaluierung des Konzeptes zum Integrationsmanagement

Die Change Policy legt für ein System fest, wie das weitere Wachstum seines funktionalen Umfangs geplant ist bzw. erwartet wird und welche Bedeutung die Sicherstellung der technisch-strukturellen Qualität besitzt. Ausprägung

Bedeutung

grow global

funktionaler Ausbau im Rahmen des Einsatzes als Gruppensystem Strukturell-technische Zukunftsfähigkeit sicherstellen

grow local

Funktionaler Ausbau im Rahmen des Einsatzes als lokales System Strukturell-technische Zukunftsfähigkeit sicherstellen Strukturell-technische Zukunftsfähigkeit sicherstellen Kein weiterer Ausbau Ersetzen der Funktionalität durch neues System oder Übernahme durch bestehende Systeme Reduktion der Wartungsaufwände Kein weiterer Ausbau Minimierung der Wartungsaufwände Einstellen der Wartung Vorbereitung für Abschaltung

rustproof replace

freeze sunset

Tabelle 7:

Change Policy von IT-Systemen bei der SEB AG

Das IS-Portfoliomanagement der SEB AG bewertet die strukturelle und funktionale Qualität von IT-Systemen und weist den Status von Systemen mithilfe einer Ampelfunktion aus. Aspekte der Beherrschbarkeit der Systeme im Sinne des in Abschnitt 4.6.2 entwickelten Modells finden keine Berücksichtigung. 5.3.3.1.3

Das IT-Programm zur DWH-Konsolidierung

Die Basis des IT-Programms wurde durch eine Studie zur Definition der mittelund langfristigen Zielarchitektur der DWH-Landschaft gelegt. Auf Basis der entwickelten Zielmodelle wurde eine Roadmap aufgestellt. In ihr sind die ITProjekte definiert, die zur Erreichung des mittelfristigen Zielbildes durchgeführt werden sollten. Für diese Roadmap wurde die Business-Case-Analyse durchgeführt. Diese Analyse führte zur Entscheidung für die Umsetzung der Roadmap. In der Folge unterliegt dann jedes einzelne der identifizierten IT-Projekte dem bei der SEB AG im Rahmen des Process for Ventures angewandten Entscheidungsverfahrens, das auf der Business-Case-Analyse des jeweiligen Projektes beruht.

271

5.3 Fallstudie SEB GRUPPE

Ausgangspunkt der Studie bildete die in der strategischen Konzeption der Unternehmens-IT der SEB AG definierte, mittel- bis langfristig281 angestrebte Zielsituation der IT-Landschaft. Sie wurde Ende 2008 im Rahmen des entsprechenden jährlichen Prozesses aktualisiert und umfasst die Zielsituation zur DataWarehouse-Landschaft. Die folgende Abbildung zeigt die für die DWHLandschaft mittel- bis langfristig angestrebte Zielsituation. In ihr ist ein Ausschnitt der Ziel-Informationsarchitektur als Teil der Unternehmensarchitektur der SEB AG dargestellt. Mithilfe des Referenzmodells zur Geschäftsprozesslandschaft der SEB AG282 ist in der Informationsarchitektur festgelegt, welche DataWarehouse-Systeme Daten zur Befriedigung des Informationsbedarfes283 bestimmter Prozessgruppen der Divisionen bzw. der Gesamtbank aufbereiten und bereitstellen. 9HUWULHE .XQGHQEHWUHXXQJ

%HUDWXQJ

9HUNDXI

$XVNXQIW  7UDQV DNWLRQHQ

9HUDUEHLWXQJ $EZLFNOXQJ

&OHDULQJ

6HWWOHPHQW

.XQGHQ 6HUYLFHV

6WHXHUXQJ 9HUWULHEV )LQDQFLDO 3RUWIROLR 5LVLNR VWHXHUXQJ  $FFRXQWLQJ 3HUIRUPDQFH 0DQDJHPHQW 0DQDJHPHQW 5HSRUWLQJ  &RPSOLDQFH 0DQDJHPHQW 7UHDVXU\ 3ODQQLQJ

AG-BIW

AG-BIW

MB

Diverse Lösungen

Diverse Lösungen

STTS

STTS

Gesamtbank

AG-BIW

RETAIL

Konzern-BIW

Abbildung 123: Zielarchitektur DWH-Landschaft – mittel- bis langfristig angestrebte Informationsarchitektur284 Für die angestrebte Informationsarchitektur im Bereich der DWHLandschaft gilt: ƒ

281

Das Konzern-BIW ist mittel- bis langfristig als zentraler Information Hub für alle Prozesse der Gesamtbanksteuerung (Portfoliomanagement; Risikomanagement; Financial Accounting; Reporting & Planning; Compliance) positioniert.

Das bedeutet bei der SEB AG einen 3-5 Jahre Horizont. Siehe Abbildung 121. 283 Informationsbedarfe, die mithilfe von Data-Warehouse-Systemen befriedigt werden sollen, beziehen sich hier auf operative, taktische und strategische Auswertungen innerhalb der jeweiligen Prozesse. 284 Die Geschäftsprozesse der Division Wealth werden im Wesentlichen durch eine extern betriebene Geschäftsplattform unterstützt und daher im Rahmen der Fallstudie vernachlässigt. 282

272 ƒ ƒ

ƒ

5 Evaluierung des Konzeptes zum Integrationsmanagement

Das BIW der SEB AG (AG-BIW) ist mittel- bis langfristig als zentraler Information Hub zur Unterstützung aller Retail-Prozesse und zusätzlich der Prozesse des Kreditrisikomanagement der Divisionen positioniert. STTS soll auf die bereits bestehende Prozessunterstützung beschränkt bleiben. Eine Ausweitung auf weitere Prozessgruppen ist nicht vorgesehen. Der Fokus des Managements von STTS soll auf der Sicherstellung technischstrukturellen Zukunftsfähigkeit liegen. Alle anderen bestehenden Data-Warehouse-Systeme sollen mittelfristig sukzessive ersetzt und abgeschaltet werden.

Aus der Zielarchitektur wurde für die Data-Warehouse-Systeme der SEB AG im Rahmen des beschriebenen Ansatzes zum IS-Portfoliomanagement die folgende Einordnung abgeleitet.

Tabelle 8:

grün

Business Value hoch

Change Policy grow global

grün gelb grün

hoch hoch hoch

grow local replace rustproof

rot rot

hoch mittel

sunset sunset

System

Status

KonzernBIW AG-BIW Data1 STTS DDB DWH-alt

Klassifikation der Data-Warehouse-Systeme im IS-Portfoliomanagement der SEB AG

Die zum Zeitpunkt der Studie bestehende Informationsarchitektur der DWH-Landschaft ist in Abbildung 124 zusammengefasst. Die Abbildung zeigt die Heterogenität der bestehenden Landschaft, wobei in der Abbildung die Heterogenität der zugrunde liegenden IT-Basisinfrastruktur nicht bezeigt wird.

273

5.3 Fallstudie SEB GRUPPE

9HUWULHE .XQGHQEHWUHXXQJ

%HUDWXQJ

9HUNDXI

$XVNXQIW  7UDQV DNWLRQHQ

Diverse Lösungen

Diverse Lösungen

DDB

Data1 Konz.BIW STTS

DDB AG-BIW

DDB

STTS

Gesamtbank

.XQGHQ 6HUYLFHV

Data1

MB

6HWWOHPHQW

DDB DWHalt

AG-BIW

&OHDULQJ

6WHXHUXQJ 9HUWULHEV )LQDQFLDO 3RUWIROLR 5LVLNR VWHXHUXQJ  $FFRXQWLQJ 3HUIRUPDQFH 0DQDJHPHQW 0DQDJHPHQW 5HSRUWLQJ  &RPSOLDQFH 0DQDJHPHQW 7UHDVXU\ 3ODQQLQJ

AG-BIW

RETAIL

9HUDUEHLWXQJ $EZLFNOXQJ

AGBIW

Abbildung 124: Ist-Architektur DWH-Landschaft - Informationsarchitektur Die Aufgabe der Studie zur DWH-Konsolidierung bestand darin, ausgehend von der aktuellen Informationsarchitektur einen Vorschlag zur Konsolidierung der DWH-Landschaft zum Zwecke der Komplexitätsreduktion auf der Grundlage der angestrebten Zielinformationsarchitektur, der Bewertung der DWH-Systeme im IS-Portfoliomanagement sowie den IT-Prinzipien und IT-Standards der SEB GRUPPE zu erarbeiten. Die bestehende Zielarchitektur und die Einordnung der DWH-Systeme sollten dabei ggf. korrigiert werden. Ergebnisse der Studie – Data Warehousing Ziellandschaft Die Studie ergab einen Vorschlag zur Anpassung der definierten Zielarchitektur zur DWH-Landschaft. Wesentliche treibende Kraft dieser Anpassung war die Erkenntnis, dass das Programm PROG_GF mit seiner Fokussierung auf den Aufbau der Accounting- und Reporting-Plattform PLAT_GrF dazu führt, dass das Konzern-BIW mittelfristig primär Anforderungen in Bezug auf die Integration weiterer Divisionen bzw. Länder in die Plattform PLAT_GrF erfüllen muss. Aus diesem Grunde wird einerseits die Positionierung des BIW der SEB AG als zentraler Information Hub aufgewertet und andererseits das Konzern-BIW auf den Fokus der Rechnungslegung beschränkt. Dies bedeutet, dass das AG-BIW mittelfristig vom Retail-orientierten Data Warehouse in Richtung Banksteuerung erweitert wird, da es zusätzlich Prozesse des Risikomanagements und des Meldewesens unterstützen soll. Aus der Studie ergab sich daher die folgende korrigierte mittel- bis langfristige Informationsarchitektur der DWH-Landschaft der SEB-AG, die sich vor allem in der Unterstützung der Prozesse des Risikomanagements zeigt.

274

5 Evaluierung des Konzeptes zum Integrationsmanagement

9HUWULHE .XQGHQEHWUHXXQJ

%HUDWXQJ

9HUNDXI

$XVNXQIW  7UDQV DNWLRQHQ

MB

Diverse Lösungen

6HWWOHPHQW

.XQGHQ 6HUYLFHV

AG-BIW

AG-BIW

AG-BIW

&OHDULQJ

6WHXHUXQJ 9HUWULHEV )LQDQFLDO 3RUWIROLR VWHXHUXQJ  $FFRXQWLQJ 5LVLNR 3HUIRUPDQFH 0DQDJHPHQW 0DQDJHPHQW 5HSRUWLQJ  &RPSOLDQFH 0DQDJHPHQW 7UHDVXU\ 3ODQQLQJ

DW Halt

RETAIL

9HUDUEHLWXQJ $EZLFNOXQJ

Diverse Lösungen

AG-BIW Konz.BIW STTS

STTS

AGBIW

Gesamtbank

AG-BIW

Abbildung 125: Zielarchitektur DWH-Landschaft – angepasste ZielInformationsarchitektur Die langfristige Zielsetzung, das Konzern-BIW zum einzigen Information Hub der Gesamtbanksteuerung der SEB AG zu machen, bleibt bestehen und ist in der nachstehenden Abbildung zusammengefasst. KonzernBIW

AG-BIW

Retail

Vertriebssteuerung & Performance Management

MB

PortfolioManagement (Treasury)

RisikoManagement

Financial Accounting, Reporting & Planning

Compliance

Abbildung 126: Zielarchitektur DWH-Landschaft - langfristige angestrebte Zielsituation DWH-Konsolidierung – Konsolidierung Data1, DDB, DWH-alt Einer der Hauptschritte auf dem Weg zur definierten Informationsarchitektur besteht im Austausch des Altsystems Data1 durch das BIW der SEB AG. Dies soll im Sinne des bei der SEB herrschenden Komplexitätsverständnisses einen wesentlichen Beitrag zur angestrebten Komplexitätsreduktion der IT-Landschaft leisten. Ausgangspunkt der Analyse ist der für die Data1-Ablösung relevante Ausschnitt der bestehenden DWH-Landschaft, wie er in Abbildung 127 in Form eines übergreifenden Kontextdiagramms dargestellt ist. Das Kontextdiagramm zeigt wesentliche Systeme und Informationsflüsse unter Hervorhebung von Da-

275

5.3 Fallstudie SEB GRUPPE

ta1. Diese Informationsflüsse285 dienen der Befriedigung der Informationsbedarfe der Prozesse des Meldewesens und des operativen Kreditrisikomanagements und der hier verwendeten Auswertungen, Berichte und Anwendungen. Rund dreißig Quellsysteme sind dazu mit Data1 integriert, teilweise über eigens geschaffene Zwischensysteme. Acht Systeme im Bereich des Meldewesens und des Kreditrisikomanagements basieren unmittelbar oder mittelbar auf den Daten von Data1. Informationsbereitstellung

Quellsysteme Positionen & Transaktionen

Sicherheiten

Stammdaten

Integration und Informationsaufbereitung

diverse Zwischensysteme

Konzern-BIW

Data1

STTS

CFEngine

Meldewesen Liefer-Engine

diverse Systeme

EKOT

Auswertungen & Berichte

DDB

MeldewesenSysteme

LieferEngine SEB Gruppe

Auswertungen & Berichte

Group Risk Control Integration

DWH-alt

AG-BIW

Operatives Kreditrisiko- & Limitsystem

Auswertungen & Berichte

Auswertungen & Berichte

Auswertungen & Berichte

Vertrieb & Kundenbetreuung

MarktRisikoSystem

Auswertungen & Berichte

Informationsnutzung

Abbildung 127: Ist-Architektur DWH-Landschaft SEB AG – übergreifendes Kontextdiagramm Für die Systeme DWH-alt und DDB ist die Verlagerung von Funktionalität auf das BIW der SEB AG und, soweit es die Unterstützung des Portfoliomanagement durch DDB betrifft, durch STTS geplant. Ein wesentlicher Unterschied zur Verlagerung von Data1 auf das BIW der SEB AG besteht darin, dass Data1 den Informationsbedarf von Prozessen des Meldewesens (innerhalb des ProzessClusters Financial Accounting, Reporting & Planning) und des Kreditrisikomanagements (innerhalb des Prozess-Clusters Risikomanagement) abdeckt, also 285 Auf physischer Ebene manifestieren sich die Informationsflüsse in Form mehrerer Dutzend Datenflüsse, die mithilfe von technischen Schnittstellen und zugehörigen Aufbereitungs- bzw. Verarbeitungsprogrammen realisiert sind.

276

5 Evaluierung des Konzeptes zum Integrationsmanagement

von Prozessen, die bisher nicht durch das BIW der SEB AG unterstützt wurden. Im Gegensatz dazu unterstützt das BIW (gleiches gilt für STTS) heute bereits Prozesse der Prozessgruppen, die auch von DDB und DWH-alt unterstützt werden. Das Ersetzen von Data1 durch das BIW der SEB AG erfordert also eine fundamentale funktionale Erweiterung, da fachlich komplexe und sehr änderungsanfällige Prozesse des Meldewesens und des Kreditrisikomanagements unterstützt werden müssen. Deshalb wird der Anforderungsdruck an die Betreuungsorganisation in Bezug auf die zu unterstützende Fachlichkeit, einzuhaltende Lieferzeiten und Änderungshäufigkeit der Informationsbedarfe signifikant erhöht – dies insbesondere wegen der nun zu erfüllenden gesetzlichen Anforderungen. Die Neuaufstellung und Ausweitung der Betreuungsorganisation des BIW der SEB AG ist daher zwingend, um Data1 ersetzen zu können. Komplexitätsreduktion durch Data1-Ablösung Die folgende Abbildung zeigt das - auf die oben beschriebene mittel- bis langfristige Informationsarchitektur abgestimmte übergreifende - Kontextdiagramm zur DWH-Landschaft der SEB AG. Nach dem Komplexitätsverständnis der SEB AG ergibt sich im Vergleich zur in Abbildung 127 dargestellten Ist-Situation eine deutliche Komplexitätsreduktion. Wesentliche Bausteine der Konsolidierung auf das BIW der SEB AG sind: ƒ

ƒ

Informationsflüsse zu und von Data1 sind auf das AG-BIW zu verlagern. Dies erfordert die Realisierung bzw. Anpassung entsprechender Datenflüsse von rund zwanzig Quellsystemen zum AG-BIW, verbunden mit der entsprechenden Erweiterung der Datentransformations- und Datenbereitstellungsprogramme des AG-BIW auf Basis des erweiterten Datenmodells. Darüber hinaus ist das AG-BIW mit der Meldewesen-Liefer-Engine und dem operativen Kreditrisiko- und Limitsystem zu integrieren, und die spezifischen Informationsbedarfe, insbesondere auch die Datenbereitstellungszeiten, sind sicherzustellen. Dies erfordert den Ausbau der entsprechenden Programme zur Datentransformation und -bereitstellung im AGBIW und die Reorganisation der bestehenden Datenlieferketten.

Darüber hinaus erfordern die Verlagerung von Data1 ins AG-BIW, das vollständige Ersetzen von DDB und das teilweise Ersetzen von DWH-ALT durch das AG-BIW einen weiteren Ausbau bereits im AG-BIW angesiedelter Transformations- und Bereitstellungsprogramme.

277

5.3 Fallstudie SEB GRUPPE

Informationsbereitstellung

Quellsysteme Positionen & Transaktionen

Sicherheiten

Stammdaten

Integration und Informationsaufbereitung

diverse Zwischensysteme

Konzern-BIW

AG-BIW

STTS

CFEngine

Auswertungen & Berichte

Operatives Kreditrisiko- & Limitsystem

Meldewesen LieferEngine

DiverseSysteme

EKOT

DWH-alt

MeldewesenSysteme

LieferEngine SEB Gruppe

Auswertungen & Berichte

Auswertungen & Berichte

MarktRisikoSystem

Auswertungen & Berichte

Vertrieb & Kundenbetreuung

Group Risk Control Integration

Auswertungen & Berichte

Informationsnutzung

Abbildung 128: Ziel-Architektur DWH-Landschaft SEB AG – übergreifendes Soll-Kontextdiagramm 5.3.3.1.4

Das IT-Projekt Risk Information Management (RIM)

Leistungsanforderungen im Projekt Die Zielsetzung des Projektes Risk Information Management bestand, wie oben beschrieben, darin, die IT-Landschaft zur Integration der SEB AG in die Risikomanagement-Plattform der Gruppe und zur Erfüllung gesetzlicher Auflagen weiterzuentwickeln. Daraus ergaben sich folgende Anforderungsschwerpunkte286 - die im Projekt entwickelte Lösungsarchitektur musste (u. a.) die Frage beantworten, wie die IT-Landschaft zu organisieren ist, um diesen Anforderungen gerecht zu werden: ƒ ƒ

Daten aus ca. 25 positions- und stammdatenführenden Systemen sind in die Risikomanagement-Plattform der Gruppe zu integrieren. Daten aus zwei Systemen zur Verwaltung von Kreditsicherheiten sind in die Risikomanagement-Plattform der Gruppe zu integrieren. Diese Integration

286 Hinter diesen Anforderungen verbergen sich nach dem Grundmodell zum Integrationsmanagement der vorliegenden Arbeit jeweils zahlreiche Integrationsanforderungen und fachliche Anforderungen.

278

ƒ

5 Evaluierung des Konzeptes zum Integrationsmanagement

bedeutet insbesondere, dass die Sicherheiten so vorverarbeitet werden müssen, dass auf die Anforderungen des Risikomanagements zugeschnittene und bewertete Daten zur Verfügung stehen. Die bisherige Interimslösung zur Verarbeitung meldewesenspezifischer Daten aus der MeldewesenLiefer-Engine kann dann entfallen. Ein System zur Generierung von Cashflows für die Bestimmung von Liquiditäts- und Marktpreisrisiken wird benötigt und ist in die IT-Landschaft zu integrieren.

Rahmenbedingungen des Projektes Wesentliche Rahmenbedingungen des Projektes waren die Ausrichtung auf das Konzern-BIW und die Forderung, die Komplexität der IT-Landschaft der SEB AG nicht zu erhöhen. Damit war die Forderung verbunden, für die Implementierung fachlicher Funktionen möglichst bestehende Systeme anzupassen, wenn die Fachlichkeit hier bereits in ähnlicher Form vorhanden war. Dies betraf insbesondere das System zur Cashflow-Generierung. Eine weitere Rahmenbedingung betraf die Forderung nach der Abstimmung auf das beschriebene Programm zur DWH-Konsolidierung; die durch das Projekt RIM definierte Lösungsarchitektur sollte konform zur mittel- bis langfristigen Zielarchitektur der DWH-Landschaft sein. Architekturentscheidungen Im Rahmen eines längeren Abwägungs- und Abstimmprozesses wurden folgende Entscheidungen zur Lösungsarchitektur des Projektes RIM getroffen. Diese liegt auf dem Weg zur mittelfristigen Zielarchitektur der DWH-Landschaft der SEB AG: ƒ ƒ ƒ

287

Als zentraler Punkt der Integration der SEB AG mit der RisikomanagementPlattform der Gruppe wird ein Risk-Information-Management-System (RIMS) aufgebaut. Alle für die Risikomanagement-Plattform relevanten Positionen, die bereits im Konzern-BIW verfügbar sind, sollen von dort in das RIMS geliefert werden. Wo notwendig, soll das BIW angepasst werden. Daten aus zehn positionsführenden Systemen von Merchant Banking sollen mithilfe einer bestehenden spezialisierten Integrationslösung integriert werden. Es handelt es sich um eine selbst entwickelte Integrations-Engine, die ursprünglich geschaffen wurde, um die SEB AG mit dem bestehenden Marktrisikomanagement-System287 (SEB: Market-Risk-Engine) der Gruppe Die Market-Risk-Engine ist als Teil der Risikomanagement-Plattform gesetzt.

5.3 Fallstudie SEB GRUPPE

ƒ

ƒ ƒ

288

279

zu integrieren. Diese Lösung widerspricht der Zielarchitektur, wurde dennoch ausgewählt, da weder die Betreuungsorganisation des BIW der SEB AG noch die Betreuungsorganisation des Konzern-BIW die Integration der zehn MB-Systeme innerhalb der Laufzeit des Projektes RIM sicherstellen konnten. Auf dem Weg zur definierten Zielarchitektur der DWH-Landschaft soll die Integration dieser zehn Systeme sukzessive über das BIW der SEB AG und das Konzern-BIW ersetzt werden. Eine wesentliche Architekturentscheidung ergab sich aus der geforderten Sicherheitenvorverarbeitung. Eine vergleichbare Vorverarbeitung ist bereits als Teil der Meldewesen-Liefer-Engine implementiert, welche auf Data1 aufsetzt. Die Implementierung ist zwar meldewesenspezifisch, kann jedoch mit vertretbarem Aufwand so angepasst werden, dass aufbereitete, konsolidierte Sicherheiten für alle nutzenden Prozesse, insbesondere das Risikomanagement, erzeugt werden. Daher wurde - abgestimmt auf die DWHKonsolidierung - entschieden, diese Anpassung durchzuführen und die aufbereiteten Sicherheiten in das BIW der SEB AG zu integrieren. Auf diese Weise müssen die Sicherheitensysteme nicht direkt an das AG-BIW angebunden werden; eine aufwendige Neuimplementierung der Sicherheitenvorverarbeitung im AG-BIW kann somit vermieden werden.288 Alle weiteren positionsführenden Systeme werden über das BIW der SEB AG integriert. Die Cashflow-Engine wird abhängig von der vorgenommenen Integration der positionsführenden Systeme über das BIW der SEB AG, das KonzernBIW und die o. a. Integrations-Engine mit Positionsdaten versorgt und liefert fertige Cashflows an RIMS. Es wurde entschieden, ein neues System aufzubauen. Der Ausbau einer bei der SEB AG bereits bestehenden Cashflow-Engine wurde verworfen. Die bestehende Engine erzeugt auf die Ermittlung von internen Transferpreisen und von auf IFRS-Buchungen zugeschnittenen Cashflows. Sie basiert auf dem System STTS und verfügt über eine flexible IS-Architektur, die die Implementierung zusätzlicher Modelle zur Cashflow-Generierung und damit verbundener erweiterter Informationsflüsse unterstützt. Die Weiterentwicklung dieses Systems nach den Anforderungen des Projektes RIM und im Einklang mit der definierten Zielarchitektur der DWH-Landschaft hätte die Laufzeit des Projektes RIM erheblich verlängert.

Der zukünftige Austausch von Data1 durch das BIW der SEB AG im Rahmen der DWHRoadmap wird auf diese Weise von der mit dem Projekt RDC geschaffenen Lösung entkoppelt.

280

5 Evaluierung des Konzeptes zum Integrationsmanagement

Ergänzungen in der Zielarchitektur der DWH-Landschaft durch das Projekt RIM Die Entscheidungen zur Lösungsarchitektur des Projektes RIM bewirken die folgenden Ergänzungen in der Informationsarchitektur der SEB AG: ƒ

Die Informationsversorgung der Prozessgruppe Risikomanagement beruht mittelfristig, wie in der folgenden Abbildung dargestellt, auf dem BIW der SEB AG und dem Konzern-BIW. 6WHXHUXQJ 9HUWULHEV )LQDQFLDO 3RUWIROLR VWHXHUXQJ  $FFRXQWLQJ &RPSOLDQFH 5LVLNR 3HUIRUPDQFH 0DQDJHPHQW 5HSRUWLQJ  0DQDJHPHQW 0DQDJHPHQW 7UHDVXU\ 3ODQQLQJ

Diverse Lösungen

AG-BIW

STTS

KonzernBIW

STTS

KonzernBIW

Gesamtbank

AG-BIW

MB

AG-BIW

DWH-alt

RETAIL

AG-BIW

Abbildung 129: Zielarchitektur DWH-Landschaft – durch RIM angepasste Zielinformationsarchitektur ƒ

Die Meldewesen-Liefer-Engine wird in zwei Sub-Systeme aufgeteilt: die Sicherheitenvorverarbeitung und die Meldewesenaufbereitung. Dazu wird die vorliegende, meldewesenspezifische Sicherheitenvorverarbeitung verallgemeinert, von der übrigen Funktionalität entkoppelt und stellt zukünftig aufbereitete, konsolidierte Sicherheiten für alle Abnehmer, insbesondere für Meldewesen und Risikomanagement, zur Verfügung. Auf diese Weise können die Anforderungen des Risikomanagements zeitgerecht erfüllt werden, und gleichzeitig wird die Ablösung von Data1 durch das BIW der SEB AG im Rahmen der DWH-Roadmap von den Abnehmern der Sicherheiten entkoppelt.

Die folgende Abbildung zeigt die Zielarchitektur der DWH-Landschaft der SEB AG, wie sie sich unter Berücksichtigung des neuen Systems RIMS darstellt. Informationsobjekte sind zur Klarheit in die Darstellung einbezogen. Die Informationsversorgung basiert mittelfristig ausschließlich auf dem BIW der SEB AG

281

5.3 Fallstudie SEB GRUPPE

und dem Konzern-BIW. Die Interimslösung zur Anbindung der MB-Systeme über die Integrations-Engine ist eliminiert.

Quellsysteme

Informationsbereitstellung Positionen & Transaktionen

Sicherheiten

Stammdaten

diverse Zwischensysteme

Integration und Informationsaufbereitung

SD

AG-BIW SD

AS

PS

Sicherh.-Vorverarbeitg. Meldewesenaufbereitg. Meldewes.-Liefer-Engine

AS

PS

KonzernBIW

AS

AS Operatives Kreditrisiko- & Limitsystem SD

Informationsnutzung

MeldewesenSysteme

PS

Auswertungen & Berichte

RIMS SD

LieferEngine SEB Gruppe AS

Group Risk Control Integration

= aufbereitete, konsolidierte Sicherheiten

PS

AS

RisikoMgmnt. Plattform PS = Positionen

SD = Stammdaten

Abbildung 130: Zielarchitektur DWH-Landschaft – verfeinertes Kontextdiagramm unter Berücksichtigung von RIMS Die Lösungsarchitektur des Projektes RIM Die vorangehende Abbildung zeigt die Ziel-DWH-Landschaft der SEB AG unter Einbeziehung des Systems RIMS. Die durch das Projekt RIM definierte ISArchitekur stellt einen Schritt auf dem Weg zu diesem Ziel dar, weicht jedoch aufgrund der Einschränkungen, die sich aus den Rahmenbedingungen des Projektes ergeben, davon ab. So wird zum Beispiel eine nicht architekturkonforme Interimslösung zur Integration der Systeme der Division MB genutzt. Abbildung 131 zeigt die Lösungsarchitektur des Projektes RIM in Form des Projektkontextdiagramms. Dargestellt sind Systeme, Informationsbeziehungen in Form von Informationsflüssen und Informationsobjekten. Das Projekt erweitert die ITLandschaft um die Systeme Cashflow-Engine und RIMS sowie um alle Schnitt-

282

5 Evaluierung des Konzeptes zum Integrationsmanagement

stellen und Programme, die zum Aufbau neuer oder Anpassung bestehender Informationsflüsse implementiert werden müssen. Der überwiegende Teil der durch das Projekt zu erbringenden Leistungen besteht in diesen Integrationsleistungen entlang der betroffenen Informationsflüsse. Informationsbereitstellung PS

SD

Quellsysteme S

PS

SD

CashflowEngine

PS

Positionsführende Systeme

PS

diverse Zwischensysteme

PS

IntegrationsEngine (Interimslösung)

Data1

Sicherheiten

Stammdaten

SD

Integration und Informationsaufbereitung KonzernBIW

AG-BIW

AS

SD

PS

PS PS SD PS S

SD

AS

PS SD

MeldewesenLiefer-Engine

PS

RIMS

CF SD MarktRisikoSystem

AS

PS

LiquiditätsRisikoSystem

CF AusfallRisikoSystem

Risikomanagement-Plattform SEB Gruppe

Informationsnutzung S

= Sicherheiten

AS = aufbereitete, konsolidierte Sicherheiten

PS = Positionen

SD = Stammdaten

CF = Cashflows

Abbildung 131: Lösungsarchitektur für das Projekt RIM – Kontextdiagramm 5.3.3.2 Bewertung der Vorgehensweisen und Ergebnisse Die Aufgabe dieses Abschnittes besteht darin, die im vorherigen Abschnitt analysierte Ansätze, Projekte und Programme der SEB GRUPPE auf Basis des in den Kapiteln 2-4 entwickelten Konzeptes zu bewerten. Dazu wird zunächst die SEB GRUPPE im systemtheoretischen Fundament der Arbeit positioniert. Anschließend wird das Komplexitätsmanagement der SEB GRUPPE bewertet. Davon ausgehend werden die betrachteten IT-Projekte, IT-Programme mit ihren Zielsetzungen, Rahmenbedingungen und ihrer Einordnung in der IT-Unternehmensarchitektur der SEB GRUPPE analysiert und vor dem Hintergrund der Gestaltungsempfehlungen bewertet.

283

5.3 Fallstudie SEB GRUPPE

5.3.3.2.1

Die SEB GRUPPE als komplexes System

Im Sinne des systemtheoretischen Fundamentes der vorliegenden Arbeit stellt die SEB GRUPPE ein komplexes System dar, das dem in Abschnitt 5.3.1 beschriebenen Geschäftszweck dient. Das Teilsystem der Anwenderorganisation der SEB GRUPPE besteht aus Teilsystemen wie der Anwenderorganisation in der Division Retail, der Division MB usw. Das Teilsystem der Unternehmens-IT der SEB GRUPPE umfasst die IT-Landschaft mit ihren ca. 1.500 IT-Systemen inklusive der zugrunde liegenden IT-Basisinfrastruktur und besteht wiederum aus Teilsystemen wie der IT-Landschaft Retail, der IT-Landschaft SEB AG, der DWH-Landschaft der SEB AG etc. Darüber hinaus umfasst die UnternehmensIT das Teilsystem IT-Organisation mit den verschiedenen Teilsystemen wie Group-IT Lettland oder dem Business Information Management der Division Retail in Deutschland. Nach dem Modell der vorliegenden Arbeit kann die SEB GRUPPE folgendermaßen dargestellt werden. SEB Gruppe als komplexes System Geschäftszweck Bereitstellung von Finanzdienstleistungen, Management finanzieller Risiken, Durchführung von Transaktionen für Privatkunden, mittlere & kleinere Unternehmen sowie Großunternehmen & Institutionen

Teilsystem Anwenderorganisation Schnittstelle

Teilsystem RETAIL IT-Anwender RETAIL

…

Teilsystem MB IT-Anwender MB

Schnittstelle

Teilsystem GRC IT-Anwender Group Risk Control

Schnittstelle Schnittstelle

Schnittstelle

Teilsystem IT-Organisation

Teilsystem IT-Landschaft

… 1500 Systeme + IT-Basisinfrastruktur

Zweck: Info-Transformation

Group-IT Lettland

…

Group-IT SWE

Business Info-Mgmnt RETAIL GER

…

Zweck: Planung/Steuerung/ Weiterentwicklung/Betrieb

Teilsystem Unternehmens-IT Transformation im Rahmen des Geschäftszweckes

Abbildung 132: Teilsystem Unternehmens-IT im komplexen System SEB

284

5 Evaluierung des Konzeptes zum Integrationsmanagement

5.3.3.2.2

Bewertung Komplexitätsmanagement in der SEB GRUPPE

Die beschriebenen Ziele und Ansätze der SEB GRUPPE zum Komplexitätsmanagement sind aus Sicht der erarbeiteten Gestaltungsempfehlungen zu bewerten. Die Bewertung erfolgt in folgenden Schritten: ƒ ƒ ƒ ƒ

Angemessenheit des Komplexitätsverständnisses Möglichkeiten und Maßnahmen der Komplexitätsreduktion Komplexität und Beherrschbarkeit wichtiger Systeme Zusammenfassung

Angemessenheit des Komplexitätsverständnisses in der SEB GRUPPE Komplexität der Unternehmens-IT ist in der SEB GRUPPE an die Vorstellung der Anzahl der IT-Systeme und ihrer Informationsflüsse gebunden.289 Die Komplexität einzelner IT-Systeme findet im Ansatz der SEB GRUPPE ebenso keine explizite Berücksichtigung, wie auch die Komplexität der IT-Organisation. Dieses eindimensionale Verständnis kann zu Fehlsteuerungen in der UnternehmensIT führen, insbesondere in Bezug auf die Reaktionsfähigkeit der IT-Landschaft. Wie in Abschnitt 4.6.1.4 gezeigt, wäre unter einem solchen Komplexitätsverständnis, das die Komplexität der einzelnen Systeme nicht berücksichtigt, das Szenario monolithischer, allumfassender IT-Systeme erstrebenswert. Diese Fehlsteuerung ist bei der SEB AG zu beobachten, wie in den folgenden Abschnitten gezeigt wird. Im Komplexitätsverständnis der SEB GRUPPE findet die geschäftliche Komplexität keine explizite Berücksichtigung. Daher erfolgt keine Unterscheidung zwischen der Komplexität, die durch die geschäftliche Komplexität bedingt ist, und derjenigen, die unnötiger Kompliziertheit der IT-Landschaft geschuldet ist. Daraus ergibt sich grundsätzlich die Problematik, dass Teile der Komplexität der Unternehmens-IT, die zur Ausdifferenzierung im Wettbewerb notwendig ist, als Problem verstanden und deshalb Maßnahmen abgeleitet werden, die im Sinne der Lebensfähigkeit in der Systemumwelt als fragwürdig einzuschätzen sind. Die Zielsetzung der SEB Gruppe hinter der konkret angestrebten Komplexitätsreduktion kann im Sinne der vorliegenden Arbeit so interpretiert werden, dass wertschöpfende Komplexität und unerwünschte Kompliziertheit in der ITLandschaft undifferenziert adressiert werden sollen, um so der unerwünschten Verschiebung der Leistungserbringung der IT-Organisation zuungunsten fachlicher Anforderungen zu begegnen. Die von der SEB aufgesetzten Programme zur 289 Im Komplexitätsmodell der vorliegenden Arbeit und der daraus abgeleiteten mehrdimensionalen Kennzahl KITL zur Komplexität der IT-Landschaft wird dies durch die Größe KGI innerhalb von KITL erfasst; siehe dazu Abschnitt 4.4.1.2.1.

5.3 Fallstudie SEB GRUPPE

285

Komplexitätsreduktion sind daher insofern problematisch, als sie nicht auf einem differenzierten Komplexitätsverständnis beruhen, das zwischen notwendiger und unerwünschter Komplexität unterscheidet. Zudem muss Komplexität, wie in Abschnitt 3.2.1 gezeigt, in Relation zur angestrebten Reaktionsfähigkeit des Unternehmens gesehen werden, was bei der SEB unterbleibt. Das Spektrum der Möglichkeiten und Maßnahmen zur Komplexitätsreduktion bei der SEB wird nun genauer beleuchtet. Möglichkeiten und Maßnahmen der Komplexitätsreduktion Nach den Gestaltungsempfehlungen der vorliegenden Arbeit bestehen grundsätzlich folgende Möglichkeiten zur Komplexitätsreduktion290 in der UnternehmensIT der SEB GRUPPE, d. h. in IT-Landschaft und IT-Organisation: 1.

2.

3.

4.

290

Reduktion der autonomen Komplexität der Unternehmens-IT Dies entspricht nach den Ausführungen aus Abschnitt 3.2.1.4 der Reduktion der Kompliziertheit der Unternehmens-IT. Reduktion der Stärke der korrelierten Komplexität der Unternehmens-IT Dies bedeutet neben der in Abschnitt 3.2.1 vorgeschlagenen Reorganisation von IT-Prozessen die Einführung von IS-Architekturen oder IuKTechnologien, die ein höheres Maß an Adaptierbarkeit bzw. Flexibilität und Agilität in der IT-Landschaft bewirken. Die primäre Wirkung besteht hier jedoch in der Verbesserung des dynamischen Potenzials der IT-Landschaft. Die Wirkung entsprechender Architekturen und Technologien auf die Komplexität der IT-Landschaft muss für jeden Einzelfall bewertet werden, da die Ausführungen in den Abschnitten 3.2.1 und 4.6.3 zeigen, dass die Komplexität der IT-Landschaft je nach Unternehmen zumindest kurz- bis mittelfristig zunehmen kann. Reduktion der geschäftlichen Komplexität Dies kann nach den vorliegenden Gestaltungsempfehlungen entweder durch die Veränderung der Geschäftsarchitektur der SEB GRUPPE oder durch die Verbesserung des Geschäftsverständnisses in der IT-Organisation der SEB GRUPPE erfolgen. Eine Möglichkeit besteht in der Einführung adaptierbarer Geschäftsarchitekturen. Wie in Abschnitt 4.6.1.1 gezeigt, ist die Komplexitätswirkung auch hier differenziert für das jeweils betrachtete Unternehmen zu bewerten, da sie sowohl positiv als auch negativ sein kann. Verbesserung der Fertigkeiten der Mitarbeiter der IT-Organisation der SEB GRUPPE im Umgang mit Komplexität Siehe Abschnitt 3.2.1, Tabelle 2 sowie Abschnitt 4.6.1.2.

286

5 Evaluierung des Konzeptes zum Integrationsmanagement

Im Rahmen des beschriebenen eingeschränkten Komplexitätsverständnisses der SEB GRUPPE werden diese vier Möglichkeiten nicht systematisch berücksichtigt. Der Fokus der Maßnahmen zur Komplexitätsreduktion liegt daher auf dem Ersetzen von Systemen durch vorhandene Systeme – z. B. durch die in der IT-Strategie der Gruppe vorgesehene Migration von Systemen auf Gruppensysteme. Solche Maßnahmen verringern nach dem Komplexitätsmodell der vorliegenden Arbeit und der daraus abgeleiteten mehrdimensionalen Kennzahl KITL nicht notwendigerweise die Komplexität der IT-Landschaft. Dies ist z. B. dann der Fall, wenn die Komplexitätsreduktion der Gesamtheit der IT-Systeme (abgebildet durch die Größe KGI innerhalb von KITL) sowie der IT-Organisation aufgrund des Wegfalls eines IT-Systems A, dessen Funktionalität und Daten auf ein System B migriert werden, durch die notwendige Erhöhung der Komplexität des Zielsystems B überkompensiert wird. Darüber hinaus besteht das Risiko, dass durch die Verlagerung von Funktionalität und Daten von A auf B keine vollständige Abdeckung der Leistungsanforderungen sichergestellt wird, die vor der Systemmigration auf B durch A abgedeckt wurden. Dies ist insbesondere dann der Fall, wenn die Theorie des Systems A unzureichend beherrscht wird.291 In diesem Fall ist das Wissen über die Abbildung des durch das System A adressierten Ausschnittes der Systemumwelt auf die IS-Architektur, das Design und die Programmstrukturen des Systems unzureichend. Die mögliche Folge sind Einschränkungen des Leistungskataloges der Unternehmens-IT für die Anwenderorganisation. Darüber hinaus bleibt unter der Zielsetzung der Reduktion der Zahl der ITSysteme unklar, ob Systemkonsolidierungsmaßnahmen primär unnötige Kompliziertheit aufgrund funktionaler Redundanz und komplizierten Software-Designs beseitigen sollen oder ob Einschränkungen des Leistungskataloges der Unternehmens-IT in Kauf genommen werden sollen, um Komplexität zu reduzieren.292 Zusammenfassend kann gesagt werden, dass unter dem Komplexitätsverständnis der SEB GRUPPE das Risiko von Fehlinvestitionen in Systemkonsolidierungsmaßnahmen besteht, da diese vor dem Hintergrund eines mehrdimensionalen Komplexitätsverständnisses keine tatsächliche Komplexitätsreduktion bewirken, diese im Einzelfall sogar steigern und zu einer Einschränkung der Geschäftsunterstützung durch die Unternehmens-IT führen können.

291

Siehe dazu Abschnitt 4.6.2. Die Systemkonsolidierungsstrategie der SEB beschränkt sich hier auf den unscharf formulierten Anspruch, für das Geschäft unwichtige Systeme abzuschalten. 292

5.3 Fallstudie SEB GRUPPE

287

Komplexität und Beherrschbarkeit wichtiger Systeme Komplexität der IT-Landschaft wird in der SEB AG, wie beschrieben, als Hindernis der zeitgerechten und effizienten Erfüllung von Leistungsanforderungen durch die Unternehmens-IT angesehen. Dies wird neben der Redundanz von Systemen und Informationsflüssen mit der unzureichenden Beherrschbarkeit wichtiger Systeme begründet. Im Sinne der vorliegenden Arbeit ist dies so zu interpretieren, dass die Kompliziertheit der IT-Landschaft und die unzureichende Beherrschung von Teilen der IT-Landschaft die Reaktionsfähigkeit beeinträchtigten. Das heißt: Die Fähigkeit, die IT-Landschaft Umweltänderungen anzupassen, ist eingeschränkt. Wie in Abschnitt 4.6.2 gezeigt, bewirken unzureichend beherrschte Systeme tendenziell Komplexitätssteigerung, da dies dazu führen kann, dass Leistungsanforderungen theorieverletzend implementiert werden, was die Kompliziertheit der IT-Systeme und damit die Komplexität der IT-Landschaft steigert und darüber hinaus die Reaktionsfähigkeit beeinträchtigen kann. Die von der SEB AG angenommene Ursache-Wirkungs-Beziehung in dem Sinne, dass Komplexität Unbeherrschbarkeit verursache, ist somit nicht korrekt. Es ist vielmehr davon auszugehen, dass schlecht beherrschte Systeme unnötige Komplexitätssteigerungen bewirken. Das Problem der Beherrschbarkeit wichtiger Systeme bei der SEB AG ist also nicht mit der Komplexität der IT-Landschaft zu begründen, sondern mit einem ineffektiven Lebenszyklus-Management dieser IT-Systeme, d. h. die betreffenden IT-Prozesse der Management- und der operativen Ebene, z. B. das ISPortfoliomanagement, sind zu optimieren. Mithilfe dieser Optimierung können die Voraussetzungen dafür geschaffen werden, die weitere Komplexitätssteigerung der IT-Landschaft zu verringern und die Reaktionsfähigkeit zu verbessern. Zusammenfassung Unter der Annahme, dass die Reaktionsfähigkeit der IT-Landschaft nicht reduziert werden kann, da dies in der wettbewerbsintensiven Finanzdienstleistungsindustrie die Lebensfähigkeit der SEB GRUPPE gefährden könnte, beschränken sich die Möglichkeiten der Komplexitätsreduktion der IT-Landschaft auf die Beseitigung von Kompliziertheit. Darüber hinausgehende Möglichkeiten der Reduktion der Komplexität setzen die Veränderung der geschäftlichen Komplexität, z. B. durch die Veränderung der Geschäftsarchitektur über die Bereinigung des Produkt- und Prozessportfolios293, voraus.

293

Die Bereinigung des Prozessportfolios bedeutet z. B. die Auslagerung von Geschäftsprozessen und der sie unterstützenden Systeme.

288

5 Evaluierung des Konzeptes zum Integrationsmanagement

Die Flut regulatorischer Anforderungen in der Finanzwirtschaft wirkt a posteriori komplexitätssteigernd auf die Steuerungsprozesse von Banken. Zudem bedingt die Wettbewerbsposition der SEB GRUPPE294 tendenziell eine Zunahme der Vielfalt von Produkten und Prozessen. Vor diesem Hintergrund erscheint das Ziel der Komplexitätsreduktion der IT-Landschaft der SEB GRUPPE unrealistisch, da die Komplexität der Geschäftsseite und damit verbunden die der zu erfüllenden Leistungsanforderungen weiter steigen dürften. Die positive Korrelation dieser Komplexität mit derjenigen der Unternehmens-IT lässt weitere Komplexitätssteigerung der Unternehmens-IT der SEB GRUPPE erwarten, die, wie in Abschnitt 3.2.1 gezeigt, durch die Einführung von IS-Architekturen, die größere Adaptierbarkeit, Flexibilität bzw. Agilität bewirken, nicht grundsätzlich kompensiert werden kann ggf. sogar konterkariert wird. Ausgehend von dieser Analyse besteht aus Sicht des Autors der vorliegenden Arbeit eine angemessene Zielvorstellung bei gegebener Wettbewerbsposition und Geschäftsarchitektur der SEB GRUPPE in der Verbesserung der Reaktionsfähigkeit der Unternehmens-IT auf Basis einer gezielten Steuerung der Komplexität. Die Zielsetzung der Komplexitätssteuerung ist auf die Minimierung der Komplexitätssteigerung der IT-Landschaft durch die Vermeidung von Kompliziertheit und durch die Verbesserung der Fertigkeiten der IT-Organisation im Umgang mit Komplexität auszurichten. Die Sicherstellung der notwendigen Reaktionsfähigkeit ist hierfür als zentrale Randbedingung zu positionieren. Über die Definition eines Kennzahlensystems, wie es in Abschnitt 4.4 entwickelt wurde, sind diese Ansätze zu operationalisieren und entlang der Empfehlungen aus Abschnitt 4.5 in den IT-Prozessen der SEB GRUPPE zu verankern. Eine wesentliche Maßnahme zur Vermeidung von Kompliziertheit in der IT-Landschaft der SEB AG besteht in der Verbesserung des Lebenszyklusmodells auf Basis des Komplexitätslebenszyklusmodells aus Abschnitt 4.6.2 und der darauf ausgerichteten Optimierung der Prozesse des IT-Portfoliomanagements und der Erweiterung/Erneuerung. Obwohl bei der SEB AG die Einschätzung besteht, dass als Folge unnötiger Komplexität der IT-Landschaft überhöhte Aufwände in Integrationsleistungen fließen, werden diese weder bei der Projektplanung noch bei der Projektdurchführung ausgewiesen, was die Bewertung und Steuerung von Aufwandsverteilung und Integrationseffizienz nicht zulässt. Hier besteht die Notwendigkeit der Optimierung des Prozesses der IT-Projektdurchführung einschließlich seiner Verzahnung mit den Prozessen des IT-Portfoliomanagements.

294

Unter der gegebenen Wettbewerbsposition der SEB GRUPPE ist mit einer Zunahme der Komplexität der Produkte und Prozesse – insbesondere im Geschäftsfeld Merchant Banking – zu rechnen.

5.3 Fallstudie SEB GRUPPE

5.3.3.2.3

289

Bewertung des Programms PROG_GF und des Konzern-BIW der SEB GRUPPE

Neben der Verbesserung der Prozesse des Financial Accounting & Reporting auf globaler Ebene verfolgt die SEB GRUPPE mit dem Programm PROG_GF die Zielsetzung der Komplexitätsreduktion der IT-Landschaft. Die Grundphilosophie von PLAT_GrF besteht darin, alle für die betroffenen lokalen und globalen Steuerungsprozesse relevanten Informationsbedarfe durch die Integration der entsprechenden positionsführenden sowie transaktionsführenden Systeme und Stammdatensysteme der verschiedenen Länder und Divisionen der SEB GRUPPE auf der Grundlage gemeinsamer Integrationsarchitekturen und Standardschnittstellen mit dem Konzern-BIW zu integrieren und die Datenversorgung der in PLAT_GrF enthaltenen IT-Systeme auf diese Weise vollständig auf den zentralen Information Hub der Gruppe abzustellen. Die Plattform PLAT_GrF und das Konzern-BIW müssen dazu die fachlichen Anforderungen und die Integrationsanforderungen aller in PLAT_GrF zu integrierenden Länder und Divisionen abbilden. Die fachliche Funktionalität der Plattform PLAT_GrF wird großenteils durch den Kern der Plattform, eine Standard-Software für das Financial Accounting, abgedeckt. Der überwiegende Teil der von der IT-Organisation im Rahmen des IT-Programms PROG_GF zu erbringenden Leistungen besteht daher aus Integrationsleistungen zur Implementierung von Informationsflüssen zum Konzern-BIW und zur Standard-Software, welche die Basis von PLAT_GrF bildet. PLAT_GrF - Komplexitätsreduktion und Integrationsleistungen Mit dem Aufbau und dem Ausrollen der Plattform PLAT_GrF sollen auf diese Weise sukzessive länderspezifische Lösungen abgebaut295 werden, was, ausgehend vom beschriebenen Komplexitätsverständnis der SEB GRUPPE, zur Komplexitätsreduktion der IT-Landschaft führen soll. Die folgende Abbildung für Prozessgruppe des Financial Accounting & Reporting der Ist-IT-Landschaft die mittel- bis langfristige IT-Landschaft gegenüber.

295

Für Deutschland bedeutet dies z. B. die Ablösung der bestehenden Lösung zur HGB-Bilanzierung.

StammdatenSysteme

Lokales Financial Accounting & Reporting in SWE

Lokales Financial Accounting & Reporting in D

Legende

…

…

…

…

StammdatenSysteme

StammdatenSysteme

= Prozessgruppe

…

…

Plattform PLAT_GrF

Globales Financial Accounting & Reporting SEB Gruppe

Lokales Financial Accounting & Reporting SWE

Financial Accounting & Reporting SEB

InformationsSystem …

Konzern-BIW

Quellsysteme SWE

Positions-und transaktionsführende Systeme

InformationsSystem 2

Lokales Financial Accounting & Reporting D

InformationsSystem 1

Informationsnutzung

Integration und Informationsaufbereitung

Quellsysteme D

Positions-und transaktionsführende Systeme

Informationsbereitstellung

Ziel-Situation – durch PROG_GF-Programm

Abbildung 133: Ist- vs. Ziel-IT-Landschaft für das Financial Reporting & Accounting der SEB GRUPPE

Globales Financial Accounting & Reporting SEB Gruppe

Systeme für globales Financial Accounting & Reporting SEB Gruppe

Systeme für Financial Accounting & Reporting in SWE

Lokale Integrationslösungen SWE

Systeme für Financial Accounting & Reporting in D

Informationsnutzung

Lokale Integrationslösungen D

StammdatenSysteme

Quellsysteme SWE

Positions-und transaktionsführende Systeme

Integration und Informationsaufbereitung

Quellsysteme D

Positions-und transaktionsführende Systeme

Informationsbereitstellung

Ist-Situation – vor PROG_GF-Programm

290 5 Evaluierung des Konzeptes zum Integrationsmanagement

5.3 Fallstudie SEB GRUPPE

291

Auf Basis des hohen Abstraktionsniveaus der voranstehenden Abbildung und des Komplexitätsverständnisses der SEB GRUPPE ist mit dem langfristig angelegten Programm PROG_GF anscheinend eine deutliche Komplexitätsreduktion verbunden, da die Zahl der Informationsflüsse und der Systeme abnimmt.296 Wie im vorangehenden Abschnitt ausgeführt, ist diese Sicht nach den Gestaltungsempfehlungen der vorliegenden Arbeit eindimensional, da sie die tatsächliche Komplexität unzureichend erfasst. So weist die angestrebte Gruppenplattform PLAT_GrF offensichtlich eine wesentlich höhere Komplexität auf als einzelne lokale Lösungen. Eine Komplexitätsanalyse nach den Gestaltungsempfehlungen der vorliegenden Arbeit käme daher ggf. zum Ergebnis, dass der betroffene Ausschnitt der Ziellandschaft höhere Komplexität aufweist. Das tatsächliche Ergebnis einer solchen Analyse kann dabei nicht vollständig antizipiert werden, da nach den Empfehlungen aus Abschnitt 4.6.1.2 die Komplexitätsbewertung vom jeweiligen Unternehmenskontext und den Fertigkeiten der die Bewertung durchführenden Individuen abhängt. Ein weiterer Ansatzpunkt der Komplexitätsbetrachtung von PLAT_GrF ergibt sich aus der in Abschnitt 3.2.1 analysierten zeitlichen Perspektive. Die Einführung neuer Technologien und IS-Architekturen mit dem Ziel einer längerfristigen Komplexitätsreduktion kann demnach mit einer kurz- bis mittelfristigen Komplexitätszunahme verbunden sein. Dies wird deutlich, wenn man die zeitliche Planung des Programms PROG_GF betrachtet, das länderweise organisiert ist. Die Grundlegung der Gruppen-Plattform PLAT_GrF erfolgte durch den Aufbau der Basisversion, verbunden mit der Umstellung des Financial Accounting & Reporting in der SEB AG auf PLAT_GrF. Das entsprechende Projekt ist auf mehrere Jahre angelegt. Aufgrund der gegebenen Komplexität der ITLandschaft der SEB AG, der Komplexität der lokalen Gesetzgebung und damit verbunden der betroffenen Geschäftsprozesse der SEB AG erwies es sich als nicht möglich, im ersten Schritt die angestrebte Zielarchitektur für Deutschland vollständig zu implementieren. Dies bedeutete insbesondere, dass die Implementierung der Anbindung der Quellsysteme an das Konzern-BIW nicht so organisiert werden konnte, dass das Erreichen des angestrebten Meilensteins zur Umstellung des Financial Accounting & Reporting der SEB AG auf die Plattform PLAT_GrF sichergestellt werden konnte. Aus diesem Grund wurde entschieden, das bestehende lokale System zur lokalen Bilanzierung als Integrationslösung zu verwenden, indem von dort aggregierte Positionen an PLAT_GrF geliefert wer296 Gerichtete Kanten in der Abbildung repräsentieren gebündelte Informationsflüsse. So verbirgt sich hinter den drei dargestellten Kanten von Quellsystemen zum globalen BIW tatsächlich eine dreistellige Zahl von Informationsflüssen und eine noch größere Zahl von Datenflüssen und damit einhergehenden Schnittstellen und Programmen.

292

5 Evaluierung des Konzeptes zum Integrationsmanagement

den. Die Basisversion von PLAT_GrF wurde daher nur für ausgewählte positionsführende Systeme der SEB AG über das Konzern-BIW beliefert. Parallel dazu wurde PLAT_GrF wie beschrieben mit dem zur Integrationslösung umgewidmeten bestehenden Bilanzierungssystem integriert. Die so an PLAT_GrF gelieferten aggregrierten Positionen werden in das Bilanzierungsschema von PLAT_GrF integriert. Auf diese Weise konnte die aufwendige Integration aller relevanten Quellsysteme der SEB AG in das Konzern-BIW vermieden werden und die Bilanzierung der SEB AG erfolgreich auf die Gruppenplattform PLAT_GrF umgestellt werden. Somit beruhen heute die HGB- und die IFRSBilanz der SEB AG auf PLAT_GrF. Die folgende Abbildung fasst die Architektur der Basisversion von PLAT_GrF zusammen. Informationsbereitstellung Positions-und transaktionsführende Systeme

StammdatenSysteme

Quellsysteme D

…

….

Quellsysteme SWE

…

Integration und Informationsaufbereitung Lokale Bilanzierungsplattform D

KonzernBIW

Lokale Integrationslösungen SWE

…

Informationsnutzung Implementierung PLAT_GrF für D

Systeme für Financial Accounting & Reporting SWE

…

Lokales Financial Accounting & Reporting D

Lokales Financial Accounting & Reporting SWE

…

Systeme für globales Financial Accounting & Reporting SEB Gruppe Globales Financial Accounting & Reporting SEB Gruppe

= Prozessgruppe Legende

Abbildung 134: Architektur der Basisversion der Gruppenplattform PLAT_GrF In Bezug auf die Komplexität der Unternehmens-IT bedeutet dies, dass das alte, lokale Bilanzierungssystem mittelfristig als Integrationslösung bestehen bleibt und die Komplexität der Gesamtheit der IT-Systeme (operationalisiert durch die Kennzahl KGI in KITL) durch PLAT_GrF zunächst erhöht wird. Das

5.3 Fallstudie SEB GRUPPE

293

heißt, dass die Ausführung aus Abschnitt 3.2.1 bestätigt werden: Im Falle von PLAT_GrF führt die neue Architektur mittelfristig zur Komplexitätssteigerung. Ihr steht eine langfristige Reduktion gegenüber, die weitere Investitionen297 erfordert und daher a priori unsicher ist. Da zudem die Betreuung des alten Systems weiter sichergestellt werden muss, lässt die Komplexität der ITOrganisation mittelfristig ebenfalls eine Komplexitätszunahme erwarten. Die durch PLAT_GrF verursachte mittelfristige Komplexitätssteigerung beruht, wie beschrieben, auch auf der mittelfristigen Zu- statt Abnahme der Zahl der Informationsflüsse. Dies bedeutet, dass durch das IT-Programm PROG_GF die durch die IT-Organisation der SEB GRUPPE zu erbringenden Integrationsleistungen zumindest mittelfristig steigen. PLAT_GrF und Reaktionsfähigkeit Betrachtet man die Situation der IT-Landschaft zum Zeitpunkt des Aufsetzens des Programms PROG_GF, zum Zeitpunkt der Produktivnahme der Basisversion und die angestrebte Zielsituation, so steht zu allen drei Zeitpunkten genau ein System zur Verfügung, mit dem Veränderungen der Umwelt im Bereich des Financial Accounting & Reporting auf Länderebene oder auf Gruppenebene kompensiert werden können. Das statische Potenzial der IT-Landschaft der SEB GRUPPE wird somit durch das Programm PROG_GF nicht signifikant verändert. Vor Einführung der Basisversion von PLAT_GrF in Deutschland wurden Änderungen im Bereich des Financial Accounting & Reporting implementiert, indem Leistungsanforderungen lokal analysiert wurden, die Integration betroffener Quellsysteme in die lokale Bilanzierungsplattform entlang der definierten Leistungsanforderungen lokal weiter entwickelt wurde und die lokale Plattform auf die neuen Regeln von der lokalen IT-Organisation angepasst bzw. erweitert wurde. Nach Einführung der Basisversion von PLAT_GrF werden Leistungsanforderungen lokal analysiert, die Systemintegration lokaler Quellsysteme in die lokale Altplattform weiterhin von der lokalen IT-Organisation angepasst bzw. erweitert. Darüber hinaus gehende Leistungen werden durch die globale ITOrganisation, d. h. zu großen Teilen außerhalb Deutschland angesiedelter Einheiten der IT-Organisation durchgeführt. Die Fähigkeit der SEB AG Veränderungen des Financial Accounting & Reporting zeitgerecht zu kompensieren, wird tendenziell verschlechtert, da die zeitgerechte Implementierung davon abhängig ist, dass außerhalb Deutschlands angesiedelte Einheiten lokale Leistungsanforderungen korrekt interpretieren und zeitgerecht umsetzen. Nach Erreichen der ange297

So muss das alte Bilanzierungssystem der SEB AG mithilfe der Integration aller entsprechenden Quellsysteme in das Konzern-BIW abgelöst werden.

294

5 Evaluierung des Konzeptes zum Integrationsmanagement

strebten Zielsituation beschränkt sich die Leistung der lokalen IT-Organisation auf die Anpassung der Quellsystemschnittstellen zum Konzern-BIW. Diese Analyse zeigt, dass durch die Einführung von PLAT_GrF zumindest auf Länderebene mit einer Einschränkung des dynamischen Potenzials zu rechnen ist. Die ganzheitliche Integrationslösung Konzern-BIW Im Sinne des in Abschnitt 3.2.2 Modells handelt es sich beim Konzern-BIW der SEB GRUPPE um eine ganzheitliche Integrationslösung. Diese wird vorrangig durch das Programm PROG_GF getrieben. Die damit verbundene Integration der Prozesse des Financial Accounting & Reporting auf Gruppen- und Länder/Divisionsebene manifestiert sich nach dem Modell der ganzheitlichen Integrationslösung aus Abschnitt 3.2.2 in Geschäftsintegrationsanforderungen (BIR) und Anwendungsintegrationsbeziehungen (AIR), die mithilfe technischer Integrationsbeziehungen (TIR) auf Basis des Konzern-BIW implementiert werden. Dies ist in der folgenden Abbildung dargestellt.

..

Life

Life

Treasury

Wealth

MB

Quellsysteme Deutschland

RETAIL

…

Treasury

Wealth

MB

RETAIL

Informationsbereitstellung

…

Quellsysteme Schweden BIR BIR AIRÎ TIR

Konzern-BIW BIR BIR AIRÎ TIR

Integration und Informationsaufbereitung

BIR BIR BIR

Globale Unternehmensteuerung Lokale Steuerung D

Lokale Steuerung SWE

…

Globale Steuerung RETAIL Lokale Steuerung D

Lokale Steuerung SWE

……

…

Informationsnutzung – Integrierte Steuerung mit Hilfe Informationssystemen

Abbildung 135: Konzern-BIW als ganzheitliche Integrationslösung Das Architekturmuster eines umfassenden Data Warehouse wie das Konzern-BIW besteht darin, auf der Grundlage eines umfassenden, einheitlichen

5.3 Fallstudie SEB GRUPPE

295

logischen Datenmodells sukzessive Daten aus allen angebundenen Ländern und Divisionen in das einheitliche Modell zu transformieren, zu speichern und aus diesem konsolidierten Datenbestand unterschiedliche Geschäftssichten durch die Bereitstellung veredelter Daten zeitgerecht zu befriedigen. Da aus der Zielpositionierung des Konzern-BIW folgt, dass insbesondere gesetzliche Anforderungen abzudecken sind, ergibt sich ein sehr breites Spektrum von fachlichen Anforderungen und Integrationsanforderungen, das die Betreuungsorganisation des BIW zeitgerecht erfüllen können muss. Die Architektur des Konzern-BIW - einschließlich der zugrunde liegenden IT-Basisinfrastruktur – muss deshalb z. B. der großen Änderungshäufigkeit der Anforderungen des Meldewesens in Deutschland gewachsen sein. Aus den oben angestellten Überlegungen zum dynamischen Potenzial folgt, dass mit einer Einschränkung des dynamischen Potenzials der SEB AG zu rechnen ist. Darüber hinaus ist zu bedenken, dass gesetzliche Anforderungen in Banken grundsätzlich höchste Priorität besitzen. Daraus ergibt sich die zu erwartende Einschränkung des dynamischen Potenzials der Divisionen, wenn Integrationsanforderungen der Prozessgruppe Vertriebssteuerung & Performance Management mithilfe der ganzheitlichen Integrationslösung des Konzern-BIW implementiert werden müssen - wie dies in der strategischen Konzeption der SEB GRUPPE vorgesehen ist. Die vorgenommene Analyse zeigt, dass die Positionierung des KonzernBIW Einschränkungen des dynamischen Potenzials lokaler Einheiten der SEB GRUPPE, wie dem Meldewesen in Deutschland und darüber im Bereich Vertriebssteuerung & Performance Management der Divisionen erwarten lässt. Flexibilität, Adaptierbarkeit und Agilität der Plattform PLAT_GrF In Abschnitt 4.6.3.2 wurde ein Modell zur Positionierung von IT-Systemen in Bezug auf Adaptierbarkeit, Flexibilität und Agilität entwickelt. Für die PLAT_GrF ergibt sich die Positionierung gemäß Abbildung 136. Diese Positionierung bedeutet, dass PLAT_GrF gewährleisten muss, dass zum Zeitpunkt des Aufbaus der Plattform noch nicht berücksichtigte Anforderungen im Bereich Financial Accounting & Reporting konform zur Theorie der Plattform und ohne signifikante Steigerung der Komplexität der IT-Landschaft implementiert werden können. Die Theoriekonformität verlangt, dass die Integration von Unternehmensakquisitionen in das Financial Accounting & Reporting der Gruppe gemäß der in Abbildung 133 dargestellten Sollarchitektur vorgenommen werden kann. Dies wird durch die beschriebene Architektur der Plattform offensichtlich sichergestellt.

296

5 Evaluierung des Konzeptes zum Integrationsmanagement

flexibel

4

adaptierbar

5

nicht adaptierbar

6

nicht agil

1

2 PLAT_GrF

3

agil

Abbildung 136: Angestrebte Positionierung von PLAT_GrF nach Adaptierbarkeit, Flexibilität und Agilität Die Komplexitätswirkung der zukünftigen Integration eines akquirierten Finanzdienstleisters ist demgegenüber kritisch zu beurteilen. Eine solche Integration wirkt komplexitätssteigernd, da neue Informationsflüsse von den Quellsystemen298 des zu integrierenden Unternehmens zum Konzern-BIW realisiert werden müssen und die Komplexität des Konzern-BIW und der Plattform PLAT_GrF aufgrund zusätzlich zu befriedigender Informationsbedarfe zunimmt. Das Ergebnis dieser Analyse folgt der positiven Korrelation geschäftlicher Komplexität mit der Komplexität der Unternehmens-IT. IS-Architekturen, wie die der Plattform PLAT_GrF, können die Stärke der Korrelation reduzieren. Komplexitätssteigerungen der Unternehmens-IT sind bei Zunahme der geschäftlichen Komplexität nicht zu vermeiden, wie dies etwa bei einer Unternehmensübernahme der Fall ist. Die Zielsetzung einer Komplexitätsreduktion der IT-Landschaft der SEB GRUPPE mithilfe der Plattform PLAT_GrF ist daher als unrealistisch einzuschätzen. Aus der Analyse von PLAT_GrF ergibt sich zusammenfassend die in der folgenden Abbildung dargestellte differenzierte Sicht auf die tatsächliche Positionierung von PLAT_GrF. Der Grad der Adaptierbarkeit ist insgesamt als geringer einzuschätzen. Der Grad der Agilität ist aus Sicht der globalen Prozesse positiver als aus Sicht lokaler Prozesse zu beurteilen.

298 Die IT-Strategie der SEB GRUPPE sieht vor, die Kernsysteme im Rahmen einer solchen Übernahme durch die Kerngeschäftsplattform für Akquisitionen zu ersetzen. Auch in diesem Fall sind neue Informationsflüsse zum Konzern-BIW zu implementieren.

297

5.3 Fallstudie SEB GRUPPE

flexibel

adaptierbar

4

1

4

1

5

2

5

2

PLAT_GrF

6

nicht adaptierbar

nicht agil

PLAT_GrF

3

6

3

nicht agil

agil

Positionierung aus globaler Sicht

agil

Positionierung aus lokaler Sicht

Abbildung 137: Erwartete Positionierung von PLAT_GrF nach Adaptierbarkeit, Flexibilität und Agilität Die Geschäftsplattform PLAT_GrF im Lebenszyklusmodell Die folgende Abbildung zeigt die Phasen des in 4.6.2 entwickelten Lebenszyklusmodells zur Komplexität von IT-Systemen. Komplexität Phase 1

Phase 2

Phase 3

Phase 4

Komplexitätsstabilität

Komplexitätswachstum

Verlust der Beherrschbarkeit

K0

Kmin Komplexitätsreduktion

t0

tmin

t1

Abbildung 138: Phasen im Komplexitätslebenszyklus von IT-Systemen Die Zielsetzung für PLAT_GrF besteht u. a. darin,

Zeit

298 ƒ ƒ

5 Evaluierung des Konzeptes zum Integrationsmanagement

die Bilanz der Gruppe innerhalb von fünf Banktagen zu erstellen und die Geschäftsplattform für die Integration der Länder und Divisionen der SEB GRUPPE und zusätzlich für Akquisitionen in das Financial Accounting & Reporting der Gruppe bereitzustellen.

Die vorangehenden Analysen zeigen, dass a priori eine Komplexitätssteigerung durch PLAT_GrF zu erwarten ist. Die mit der SEB AG implementierte Basisversion von PLAT_GrF wird hier als Ausgangspunkt der Lebenszyklusbetrachtung genommen. Die Komplexitätsbetrachtung wird auf PLAT_GrF, die relevanten Integrationslösungen sowie die Integration der Quellsysteme der verschiedenen Länder und Divisionen mit diesen Integrationslösungen bezogen, also die Systemumwelt von PLAT_GrF auf Basis von Informationsflüssen erster und zweiter Ordnung. Aufgrund des mit dem Programm PROG_GF einhergehenden Ausbaus der Plattform ist zu erwarten, dass die Plattform und das Konzern-BIW die Phasen der Komplexitätsreduktion und der Komplexitätsstabilität nicht durchlaufen, sondern von Beginn an und für mehrere Jahre in der Phase des Komplexitätswachstums bleiben. Aus Sicht des Autors der vorliegenden Arbeit besteht für PLAT_GrF und das Konzern-BIW das Risiko des vorzeitigen Übergangs in Phase 4, d. h. des Verlustes der Beherrschbarkeit. Dies ist darin begründet, dass die Beherrschung von PLAT_GrF durch die erwartete Komplexitätssteigerung gefährdet ist. Gemäß Abschnitt 4.6.2.2 beschreibt die Theorie der Plattform PLAT_GrF, wie der das Financial Accounting & Reporting betreffende Ausschnitt der Systemumwelt der SEB GRUPPE auf die Softwarebausteine von PLAT_GrF abgebildet wird und welche Philosophie, Architektur und Design dieser Abbildung zugrunde liegen. Aufgrund der zu erwartenden Veränderungen im Bereich des Financial Accounting & Reporting ist diese Abbildung laufenden Anpassungen ausgesetzt. Ohne Maßnahmen, die die Beherrschung der Theorie durch das PLAT_GrF betreuende Team sicherstellen, besteht das Risiko, dass Anpassungen nicht theoriekonform vorgenommen werden und damit die Theorie des Systems verloren geht. Dies ist nach den Gestaltungsempfehlungen aus 4.6.2.2 gleichbedeutend mit dem Verlust der Beherrschbarkeit. Zusammenfassung Die Plattform PLAT_GrF dient der strategischen Zielsetzung, die Prozesse des Financial Accounting & Reporting der SEB GRUPPE einschließlich länderspezifischer Ausprägungen zu vereinheitlichen und durch eine gemeinsame Geschäftsplattform zu unterstützen. Auf diese Weise soll u. a. die Bilanz der SEB GRUPPE in fünf Banktagen erstellt und die Integration zukünftiger Akquisitionen erleichtert werden. Darüber hinaus soll die Plattform gemäß der strategi-

5.3 Fallstudie SEB GRUPPE

299

schen Konzeption der Unternehmens-IT der SEB GRUPPE dazu beitragen, die Komplexität der IT-Landschaft zu reduzieren. Die vorangehende Analyse zeigt, dass die strategische Zielsetzung mithilfe des längerfristig angelegten IT-Programms PROG_GF erreicht werden kann. Die Zielsetzung einer Komplexitätsreduktion - und damit verbunden die Reduktion von Integrationsleistungen - erscheint jedoch unrealistisch. Problematisch erscheint PLAT_GrF hinsichtlich der Reaktionsfähigkeit, da das dynamische Potenzial im Bereich des Financial Accounting & Reporting zumindest auf Länderebene Einschränkungen erwarten lässt. Darüber hinaus gefährdet die PLAT_GrF-Architektur in Verbindung mit der Zielarchitektur der IT-Landschaft der SEB GRUPPE das dynamische und das statische Potenzial im Bereich der Vertriebssteuerung und des Performance Managements der Divisionen. Die Analyse der Integration der in der SEB AG aufgebauten PLAT_GrFBasisversion zeigt die Problematik des Architekturkonzeptes von PLAT_GrF in Bezug auf das dynamische Potenzial. Wie beschrieben, musste das Architekturkonzept teilweise verworfen werden, um die zeitgerechte Umstellung der Bilanzierung der SEB AG auf die neue Plattform sicherzustellen. Dies ist vor allem in der Positionierung des Konzern-BIW als ganzheitliche, allumfassende Integrationslösung begründet. Dies zeigt Grenzen des Konzeptes der ganzheitlichen Integrationslösung auf. Hinsichtlich des Lebenszyklusmanagements der Plattform PLAT_GrF und des Konzern-BIW wurde gezeigt, dass das Risiko eines verfrühten Eintritts in die Phase des Verlustes der Beherrschbarkeit besteht. Aufgrund der strategischen Bedeutung von PLAT_GrF und des Konzern-BIW kommt dem Lebenszyklusmanagement dieser Lösungen besondere Bedeutung zu. Hier muss der Fokus darauf liegen, die Beherrschung der Theorie von PLAT_GrF und des KonzernBIW permanent sicherzustellen. Dazu ist es unumgänglich, die Ressourcenausstattung der entsprechenden Einheiten der IT-Organisation der SEB GRUPPE priorisiert zu behandeln. 5.3.3.2.4

Bewertung des IT-Programms DWH-Konsolidierung

Wie in Abschnitt 5.3.3.1.3 dargestellt, wurde das Programm der SEB AG mit einer Studie zur Zielarchitektur initialisiert, aus der die Anpassung der mittelfristigen Strategie zur DWH-Landschaft der SEB AG hervorging. Diese Anpassung besteht in der Positionierung des lokalen BIW als primärem Information Hub und der Beschränkung des Konzern-BIW auf die Funktion des Information Hub für die Rechnungslegung. In dieser Strategieanpassung manifestieren sich die im vorherigen Abschnitt analysierten Einschränkungen des Programms PROG_GF und des Konzern-BIW in Bezug auf die Reaktionsfähigkeit lokaler Einheiten wie

300

5 Evaluierung des Konzeptes zum Integrationsmanagement

der SEB AG. Die Anpassung der DWH-Strategie bedeutet die Aufwertung einer lokalen Lösung - des AG-BIW - in der Strategie, um auf diese Weise den Einschränkungen der Reaktionsfähigkeit durch globale Lösungen zu begegnen. DWH-Konsolidierung, Komplexitätsreduktion und Integrationsleistungen Der Hauptschritt der DWH-Konsolidierung besteht in Bezug auf die angestrebte Komplexitätsreduktion im Ersetzen der Alt-Lösung Data1 durch das lokale BIW. Nach dem Komplexitätsverständnis der SEB GRUPPE wird durch diesen Austausch die Komplexität der IT-Landschaft reduziert, da die Zahl der Systeme und Informationsflüsse299 im Vergleich zur Ziel-Architektur300 abnimmt. Wie im Falle von PLAT_GrF ist diese Sicht nach den Gestaltungsempfehlungen der vorliegenden Arbeit eindimensional, da sie die tatsächliche Komplexität unzureichend erfasst. Die Komplexität des BIW der SEB AG wird durch die Verlagerungen der Funktionalität von Data1 erhöht. Gleichzeitig bewirkt die Abschaltung von Data1 eine Komplexitätsreduktion. Das Risiko der Überkompensation dieser Reduktion durch das Komplexitätswachstum des BIW der SEB AG - aufgrund der notwendigen funktionalen Erweiterungen einschließlich der Anbindung zusätzlicher Quellsysteme - wird jedoch als gering beurteilt. Dies liegt in der Architektur des AG-BIW begründet. Sie folgt einer Best-Practice-DWH-Architektur, die auf effiziente und effektive Informationsaufbereitung und -integration ausgerichtet ist. So ist beispielsweise Funktionalität zur Kontrolle der Qualität der Datenlieferungen in der Architektur des lokalen BIW grundsätzlich vorgesehen, während sie in Data1 nur rudimentär vorhanden ist, sodass eine entsprechende Funktionalität in der Meldewesen-Liefer-Engine sicherzustellen ist. Diese Funktionalität der Meldewesen-Liefer-Engine kann mit der Konsolidierung auf das BIW der SEB AG beseitigt werden. Informationsflüsse von Quellsystemen zu Data1 müssen zudem nicht vollständig reimplementiert werden, da ein großer Teil der relevanten Quellsysteme bereits an das AG-BIW angebunden ist und daher höchstens vervollständigt werden muss. Es ist daher insgesamt davon auszugehen, dass das notwendige Komplexitätswachstum des AG-BIW die Reduktion durch die Abschaltung von Data1 nicht überkompensiert, die Komplexität der IT-Landschaft also tatsächlich abnimmt. Darüber hinaus ist zu berücksichtigen, dass die das System Data1 betreuende Einheit der IT-Organisation und die IT-Prozesse der operativen Ebene rund um Data1 entfallen. Ob die Komplexität der IT-Organisation hier tatsächlich nachhaltig reduziert wird, hängt davon ab, wie stark die IT-Betreuungs299 300

Siehe Abbildung 127. Siehe Abbildung 128.

5.3 Fallstudie SEB GRUPPE

301

organisation des BIW AG ausgebaut werden muss, um den Leistungsanforderungen des Meldewesens zu entsprechen. DWH-Konsolidierung und Reaktionsfähigkeit Der Austausch von Data1 durch das AG-BIW bedeutet keine Änderung des statischen Potenzials, da vorher und nachher genau ein System zur Verfügung steht, um Veränderungen im Bereich des Meldewesens zu kompensieren. Der mit der DWH-Roadmap einhergehende Austausch der Altlösungen DDB und DWH-ALT führt zur Reduktion der Zahl der Alternativen, mit denen Umweltänderungen kompensiert werden können. Beispielsweise stehen zur Reaktion auf Anforderungen der Prozessgruppe Vertriebssteuerung & Performance Management vor der Konsolidierung der Alt-Lösung DWH-ALT auf das AG-BIW zwei Alternativen zur Verfügung, nach der Konsolidierung genau eine. Dies bedeutet die Reduktion des statischen Potenzials im Bereich der genannten Prozessgruppe. Diese Reduktion ist aus Sicht der SEB AG als unproblematisch zu bewerten, da die grundsätzliche Kompensation nicht beeinträchtigt ist. Bis zum Austausch von Data1 werden Leistungsanforderungen im Bereich des Meldewesens durch eine darauf spezialisierte Betreuungsorganisation mithilfe einer auf diese Anforderungen ausgerichteten IS-Architektur implementiert. Diese Architektur stellt sicher, dass die Lieferzeiten der benötigten Daten den strengen Anforderungen des Meldewesens entsprechen. Um eine Reduktion des dynamischen Potenzials im Bereich des Meldewesens zu vermeiden, ist daher die angemessene Verfügbarkeit von Geschäftswissen rund um das Meldewesen in der Betreuungsorganisation des BIW der SEB AG unbedingt notwendig. Dies erfordert den Ausbau entsprechender Analysekapazitäten und darüber hinaus den Ausbau der Kapazitäten im Bereich des BIW-Designs und der BIW-Implementierung. Dieser Ausbau reduziert jedoch die im Business Case der DWH-Roadmap angenommenen finanziellen Effekte. Bei unverändertem Business Case muss daher mit einer Einschränkung des dynamischen Potenzials gerechnet werden. Diese Wirkung wird durch die Architektur des AG-BIW verstärkt. Während die Architektur von Data1 auf die Lieferzeitenanforderungen des Meldewesens optimiert ist, handelt es sich bei einer DWH-Architektur, wie sie dem BIW zugrunde liegt, um eine generalisierte Architektur, die auf ein wesentlich breiteres Spektrum von Anforderungen ausgerichtet sein muss. Hier besteht das Risiko der Einschränkung der Reaktionsfähigkeit des Meldewesens, dem ggf. durch die Schaffung komplexitätssteigernder Zusatzkomponenten im Umfeld des AG-BIW begegnet werden muss. Dieser zu erwartenden Einschränkung des dynamischen Potenzials des Meldewesens durch die DWH-Konsolidierung steht jedoch eine allgemeine Ver-

302

5 Evaluierung des Konzeptes zum Integrationsmanagement

besserung gegenüber. Vor der Data1-Ablösung müssen Veränderungen, die sich auf Informationsflüsse von Quellsystemen zum Data1 und zum BIW auswirken301, jeweils parallel für Data1 und AG-BIW implementiert werden. Nach der Konsolidierung entfällt die Notwendigkeit zur Data1-Anpassung. Dies bewirkt die Reduktion der Aufwände für Integrationsleistungen. Gleichzeitig wird die Reaktionsfähigkeit verbessert, da Veränderungen der Unternehmensumwelt, die sich auf die Quellsysteme auswirken, schneller kompensiert werden können. Da es sich bei den Quellsystemen zum großen Teil um Kernsysteme der Bank handelt, ist daher davon auszugehen, dass die Reaktionsfähigkeit im Bereich der Kerngeschäftsprozesse der SEB AG verbessert wird. Die ganzheitliche Integrationslösung AG-BIW Im Sinne der Definition aus Abschnitt 3.2.2 handelt es sich beim BIW der SEB AG um eine ganzheitliche Integrationslösung. Diese wird vor der DWHKonsolidierung primär durch Anforderungen der Prozessgruppe Vertriebssteuerung & Performance Management getrieben; aufgrund der in Abbildung 125 dargestellten Zielarchitektur zusätzlich durch die Prozessgruppen Financial Accounting, Reporting & Planning (Meldewesen) und Risikomanagement. In Bezug auf die Wirkung auf die Reaktionsfähigkeit ergibt sich eine Bewertung, die vergleichbar mit der für das Konzern-BIW vorgenommenen ist: Aus der Positionierung des BIW der SEB AG folgt, dass in zunehmendem Maße gesetzliche Anforderungen abzudecken sind. Diese sind bei der SEB AG gegenüber der Prozessgruppe Vertriebssteuerung & Performance Management grundsätzlich höher priorisiert. Somit bewirkt die Positionierung des BIW der SEB AG das Risiko, dass die Reaktionsfähigkeit der Division Retail der SEB AG eingeschränkt wird. Zusammenfassung Das Programm zur DWH-Konsolidierung der SEB AG unterstützt die in der strategischen Konzeption der Unternehmens-IT der SEB AG festgelegte Zielsetzung der Komplexitätsreduktion. Problematisch erscheint das Programm hinsichtlich der Reaktionsfähigkeit, da hier im Vergleich zum bestehenden Zustand Einschränkungen für das Meldewesen und die Division Retail zu erwarten sind. Dieser Einschränkung stehen zu erwartende Verbesserungen gegenüber: ƒ

301

die Verbesserung des dynamisches Potenzials der IT-Landschaft im Bereich der Unterstützung der Kerngeschäftsprozesse

Zum Beispiel im Bereich der Stammdatensysteme.

5.3 Fallstudie SEB GRUPPE

ƒ

303

die Komplexitätsreduktion im betroffenen Teil der IT-Landschaft - hier insbesondere der Zahl der Informationsflüsse – und damit verbunden die Reduktion von Integrationsleistungen

Wie bereits bei der Bewertung des Konzern-BIW zeigt sich auch für das BIW der SEB AG die Problematik der Verschlechterung der IT-Unterstützung für Divisionen, da diese IT-Unterstützung auf einer ganzheitlichen Integrationslösung beruht, die gleichzeitig die Basis der Informationsaufbereitung für durch gesetzliche Anforderungen getriebene Banksteuerungsprozesse bildet. Daraus ergeben sich Ansatzpunkte für ergänzende Forschungsaktivitäten. Abgrenzung und Ansatzpunkte für ergänzende Forschungsaktivitäten – Reichweite ganzheitlicher Integrationslösungen Aus der Analyse ergibt sich die Frage nach Gestaltungsempfehlungen zur Festlegung der Reichweite ganzheitlicher Integrationslösungen, insbesondere von DWH-Systemen. Diese Festlegung muss die Abschätzung der Wirkung auf die Reaktionsfähigkeit berücksichtigen. Die Reichweite bezieht sich dabei auf die Abgrenzung der funktionalen Abdeckung der Prozess-Gruppen in der Prozessarchitektur eines Unternehmens. 5.3.3.2.5

Bewertung des IT-Projektes RIM

Das Projekt wurde aufgesetzt, um den Informationsbedarf eines verbesserten Risikomanagements der SEB GRUPPE zu befriedigen und gesetzliche Auflagen für die SEB AG zu erfüllen. Die damit verbundenen Leistungsanforderungen manifestieren sich in der Entwicklung und der Integration eines neuen Systems zur Ermittlung von Amortisations-Cashflows und des neuen RisikoInformationsmanagement-Systems RIMS. Die Veränderung der Geschäftssicht, z. B. in Form weiterentwickelter Modelle zur Zins- und Liquiditätsrisikosteuerung, treiben die Forderung nach dem System für Amortisations-Cashflows und dessen Integration in die IT-Landschaft. Dies führt im Sinne der grundsätzlich positiven Korrelation zum Anstieg der Komplexität der IT-Landschaft und damit verbunden der IT-Organisation. Eine realistische Zielsetzung des Projektes RIM kann daher nur in der Begrenzung des Komplexitätswachstums bestehen. Aus Sicht der Komplexitätsbegrenzung ist die im Projekt getroffene Entscheidung zur Neuentwicklung der Engine als kontraproduktiv zu bewerten. Dies gilt insbesondere, weil die im Unternehmen bereits eingesetzte CashflowEngine, wie beschrieben, eine flexible Architektur aufweist, die die Ausweitung der Cashflow-Generierung für weitere Modelle mittels Parametrisierung unter-

304

5 Evaluierung des Konzeptes zum Integrationsmanagement

stützt. Dies bedeutet, dass die Generierung von Amortisations-Cashflows mithilfe der bestehenden Engine a priori nicht zur erheblichen Komplexitätssteigerung führen würde. Im Falle der Verwendung der bestehenden Engine wäre die komplexitätssteigernde Wirkung im Wesentlichen in der Erweiterung bestehender und die Implementierung weniger neuer Informationsflüsse zu sehen. Diese Komplexitätswirkung auf IT-Landschaft und IT-Organisation ist offensichtlich geringer als die mit der geplanten Neuentwicklung einer CF-Engine und deren Integration in die IT-Landschaft verbundene. Hinsichtlich der Komplexität und der durch die IT-Organisation im Umfeld des Risikomanagements zu erbringenden Integrationsleistungen stellt die im Projekt definierte Architektur daher keine optimale Lösung dar. 5.3.3.3 Zusammenfassung in Bezug auf die Evaluierung Die Analyse und Bewertung im Rahmen der Fallstudie zeigt die SEB GRUPPE als ein Großunternehmen, das sich einer Problemstellung gegenübersieht, die im Sinne der für die vorliegende Arbeit im ersten Kapitel beschriebenen interpretiert werden kann: Integrationsleistungen der IT-Organisation dominieren in der SEB GRUPPE zunehmend Leistungen für die Erfüllung fachliche Anforderungen. Dieser Trend soll bei der SEB durch Maßnahmen zur Komplexitätsreduktion gebremst werden, die sich insbesondere auf neue IS-Architekturen stützen. Die vorgenommene Analyse und Bewertung zeigt die Relevanz der für die vorliegende Arbeit formulierten Problemstellung in der Praxis größerer Unternehmen. Mithilfe des entwickelten Konzeptes zum Integrationsmanagement wurden die in einem Großunternehmen zur Problemlösung eingesetzten Modelle, Methoden, Architektur und Vorgehensweisen umfassend analysiert, bewertet und deren Schwachstellen und Risiken aufgezeigt. Dabei zeigten sich keine Widersprüche innerhalb des entwickelten Systems von Gestaltungsempfehlungen, d. h. die Analyse und Bewertung führten nicht zur Falsifizierung des entwickelten Gesamtkonzeptes. Im nächsten Abschnitt wird, wie in der Evaluierungsmethode festgelegt, die Überprüfung des entwickelten Konzeptes fortgeführt, indem auf der Grundlage der Gestaltungsempfehlungen ein Optimierungsvorschlag für die SEB AG als Teil der SEB GRUPPE erarbeitet wird. 5.3.4 Kennzahlengetriebene Optimierung in der Unternehmens-IT der SEB AG Der Optimierungsvorschlag beantwortet die Frage, wie die der Unternehmens-IT der SEB AG auf Basis der Gestaltungsempfehlungen der vorliegenden Arbeit weiterentwickelt werden kann, um im Rahmen der definierten Ziele der SEB AG ein Integrationsmanagement in der Unternehmens-IT zu etablieren.

305

5.3 Fallstudie SEB GRUPPE

Das in Abschnitt 4.2 aufgestellte Referenzmodell zur IT-Prozesslandschaft liefert die Struktur für die Entwicklung des Optimierungsvorschlages. Die folgende Abbildung zeigt den Fokus des im Folgenden entwickelten Vorschlages zur Verankerung eines Integrationsmanagements in den IT-Prozessen der SEB AG.

IT-Strategiedefinition

Strategische Ebene

ManagementEbene

Operative Ebene

Strategische Konzeption der Unternehmens-IT

Strategische IT-Planung

IT-ServiceManagement

IT-ArchitekturManagement

IT-KostenManagement

IT-Risiko-Management

IT-Portfoliomanagement

Wartung IT-ProjektIncident-Management, Durchführung etc.

ChangeManagement

Erweiterung/Erneuerung

IT-ProjektDurchführung Software Control & Distribution

Wartung / Weiterentwicklung

Systementwicklungsprozess

Management von IT-Org. & IT-Landschaft

Betrieb & WeiterEntwicklung IT-Landschaft

Abbildung 139: Schwerpunkte der Verankerung des Integrationsmanagements in der Unternehmens-IT der SEB AG Zunächst wird die strategische Konzeption der Unternehmens-IT adressiert. Dazu wird ein Vorschlag zur Anpassung der IT-Strategie der SEB GRUPPE unterbreitet. Davon ausgehend wird die strategische IT-Planung der SEB AG ergänzt und eine Erweiterung des Kennzahlensystems zur Steuerung der Unternehmens-IT wird entworfen. Daraus wird ein Stufenplan zur Umsetzung bei der SEB AG abgeleitet. Anschließend wird aufgezeigt, wie bestehende IT-Prozesse der Management- und der operativen Ebene weiterzuentwickeln sind. 5.3.4.1 Anpassung der strategischen Konzeption der Unternehmens-IT In Abschnitt 4.3.3 wird auf Basis des entwickelten Modells zur strategischen Konzeption beschrieben, wie eine IT-Strategie und die daraus abgeleitete strategische IT-Planung zu ergänzen sind, um Integrationsmanagement in der strategischen Konzeption der Unternehmens-IT eines Unternehmens zu verankern. Für die strategische Konzeption der Unternehmens-IT der SEB GRUPPE werden hier folgende Ergänzungen vorgeschlagen:

306 ƒ ƒ

5 Evaluierung des Konzeptes zum Integrationsmanagement

IT-Strategiedefinition der SEB GRUPPE: Rolle der Unternehmens-IT, ITGovernance-Ansatz, Technologiestrategie Strategische IT-Planung der SEB AG: Konkretisierung des Handlungsfeldes Komplexitätsmanagement mithilfe eines Komplexitätsmodells, Erweiterung des Kennzahlensystems zur Steuerung der Unternehmens-IT

5.3.4.1.1

Anpassung der IT-Strategie der SEB GRUPPE

Rolle der Unternehmens-IT Die Erweiterung der Aussage zur Rolle der Unternehmens-IT beschreibt, welchen Beitrag das Integrationsmanagement in der Unternehmens-IT zur Positionierung der SEB GRUPPE im Wettbewerb leistet und welche Bedeutung dem Komplexitätsmanagement hier zukommt. Aus der in Abbildung 115 dargestellten Positionierung der SEB GRUPPE ergibt sich der folgende Vorschlag zur Ergänzung der Rollendefinition der Unternehmens-IT: „Die Unternehmens-IT der SEB GRUPPE betreibt aktives Komplexitätsmanagement. So wird sichergestellt, dass von der Anwenderorganisation erhobene fachliche Anforderungen, die dem Ziel hoher Servicequalität und operativer Exzellenz dienen, zeitgereicht in der ITLandschaft umgesetzt werden können.“ IT-Governance-Ansatz Die Erweiterung der Aussage zum IT-Governance-Ansatz definiert, wie Integrations- und damit Komplexitätsmanagement bei der Steuerung der UnternehmensIT berücksichtigt werden. Folgende Ergänzung des IT-Governance-Ansatzes wird vorgeschlagen: „Zur Sicherstellung der Reaktionsfähigkeit der SEB GRUPPE, wird die Komplexität der Unternehmens-IT aktiv gesteuert. Nicht der Geschäftsseite geschuldete Komplexität der Unternehmens-IT wird systematisch reduziert. Komplexität, Integrationsaufwände und die Leistungsfähigkeit der IT-Organisation bei der Erbringung von Integrationsleistungen werden systematisch gemessen und gesteuert. Komplexität und Reaktionsfähigkeit sind wesentliche Dimensionen der Entscheidungsprozesse in der Unternehmens-IT.“ Technologiestrategie Die Erweiterung der Aussage zur Technologiestrategie legt fest, wie Integrationstechnologien genutzt werden und wie sie zur Aufrechterhaltung und Steige-

307

5.3 Fallstudie SEB GRUPPE

rung der Leistungsfähigkeit des Unternehmens beitragen sollen. Die folgende Aussage legt den Fokus des Einsatzes von Integrationstechnologien fest: „Der Fokus des Einsatzes von Integrationstechnologien liegt auf der Verbesserung der Reaktionsfähigkeit und der Integrationseffizienz der Unternehmens-IT.“ 5.3.4.1.2

Anpassung der strategischen IT-Planung der SEB AG

Konkretisierung des Handlungsfeldes Komplexitätsmanagement Wie in Abschnitt 5.3.3.1.1 beschrieben, ist Komplexitätsmanagement als Handlungsfeld in der strategischen IT-Planung der SEB AG verankert. Der Begriff der Komplexität ist nicht verbindlich definiert und wird im IT-Management mit der Anzahl der Systeme und Informationsflüsse assoziiert. Grenzen und Schwächen dieses eindimensionalen Verständnisses wurden in Abschnitt 5.3.3.2.2 aufgezeigt. Zur Optimierung des Handlungsfeldes wird deshalb vorgeschlagen, ein mehrdimensionales Modell zur Komplexität der Unternehmens-IT bei der SEB AG einzuführen. Die folgende Abbildung zeigt das für die SEB AG vorgeschlagene Modell. Es unterstützt die bei der SEB AG definierten Ziele. Der mehrdimensionale Ansatz stellt sicher, dass den in Abschnitt 5.3.3.2.2 identifizierten Schwächen begegnet werden kann. Komplexität Unternehmens-IT SEB AG

Anzahl Anwendungstypen

Geschäftliche Komplexität

Anzahl IT-Systeme & Infoflüsse

Komplexität einzelner IT-Systeme

Komplexität der IT-Basisinfrastruktur

Komplexität der Gesamtlandschaft

Komplexität der IT-Organisation

Abbildung 140: Modell zur Komplexität der Unternehmens-IT der SEB AG

308

5 Evaluierung des Konzeptes zum Integrationsmanagement

Erweiterung des Kennzahlensystems der Unternehmens-IT Das dargestellte Komplexitätsmodell bildet die Grundlage der Erweiterung des bestehenden Kennzahlensystems302 zur Steuerung der Unternehmens-IT. Kennzahlen zur Steuerung der Komplexität der Unternehmens-IT sollten in mehreren Schritten bei der SEB AG eingeführt werden, um den Ergebnissen der Bewertung aus Abschnitt 5.3.3.2.2 zu entsprechen und um die mit den Veränderungen in der Unternehmens-IT verbundenen Risiken zu reduzieren. Im ersten Schritt kann die Erfassung der Komplexität der IT-Landschaft mithilfe eines Basiskennzahlensystems eingeführt werden, um das bestehende, auf die Zahl von Systemen und Informationsflüssen reduzierte Komplexitätsverständnis auf die Komplexität der einzelnen Systeme und auf die Vielfalt in der IT-Landschaft auszudehnen. Im nächsten Schritt sollte die Komplexität der Geschäftsseite Berücksichtigung finden, um so die Abhängigkeit der Komplexität der IT-Landschaft von der Geschäftsseite zu adressieren. Parallel kann im zweiten Schritt die Komplexität der IT-Basisinfrastruktur erfasst werden. Im abschließenden Schritt wäre dann die Komplexität der IT-Organisation im Kennzahlensystem zu verankern. Die folgende Abbildung zeigt die für die SEB AG empfohlene Reihenfolge zur Einführung von Kennzahlen zur Komplexität der Unternehmens-IT der SEB AG. Die Schritte 1 und 2 werden im Folgenden genauer betrachtet. Komplexität Unternehmens-IT SEB AG

2

Anzahl Anwendungstypen

Geschäftliche Komplexität

Komplexität der IT-Basisinfrastruktur

1 Komplexität der Gesamtlandschaft Anzahl IT-Systeme & Infoflüsse

Komplexität einzelner IT-Systeme

1

2

Komplexität der IT-Organisation

3

Abbildung 141: Reihenfolge der Einführung von Kennzahlen zur Komplexität der Unternehmens-IT bei der SEB AG 302

In diesem Kennzahlensystem sind beispielsweise Performance-Indikatoren zur Verfügbarkeit der IT-Landschaft oder zur Erfolgsquote von IT-Projekten enthalten.

5.3 Fallstudie SEB GRUPPE

309

Die Operationalisierung der vorgeschlagenen Ergänzungen in der ITStrategie erfordert über die Komplexitätskennzahlen hinaus Kennzahlen zur Leistungsfähigkeit der IT-Organisation in Bezug auf Integrationsleistungen sowie zur Aufwandsverteilung. Diesen Kennzahlen sollten daher zusätzlich zu den Komplexitätskennzahlen im Stufenplan berücksichtigt werden, der sich folgendermaßen darstellt: ƒ ƒ ƒ

Stufe 1: Einführung der Basiskennzahlen zur Steuerung der Komplexität der IT-Landschaft Stufe 2: Erweiterung der Komplexitätskennzahlen durch Berücksichtigung der Geschäftsseite und der IT-Basisinfrastruktur sowie zusätzlich Einführung einer Kennzahl zur Aufwandsverteilung Stufe 3: Einführung einer Kennzahl zur Leistungsfähigkeit der ITOrganisation bei der Erbringung von Integrationsleistungen sowie von Kennzahlen zur Komplexität der IT-Organisation

Die Stufen 1 und 2 werden nun genauer beleuchtet. In Bezug auf die dritte Stufe wird darauf verwiesen, dass zur Bestimmung der Komplexität der ITOrganisation, wie in Abschnitt 4.4.1 ausgeführt, zusätzlicher Forschungsbedarf besteht. Die Leistungsfähigkeit der IT-Organisation kann durch die Einführung der Kennzahl IE der Integrationseffizienz303 abgebildet werden. Stufe 1 In dieser Stufe werden die in Abschnitt 4.4.1 definierten Kennzahlen zur Komplexität der IT-Landschaft aufgegriffen und eine auf die SEB AG zugeschnittene Kennzahl zur Komplexität der IT-Landschaft aufgestellt. Grundlage der Kennzahl für die SEB AG sind die Größen zur mittleren Komplexität und Kompliziert der IT-Systeme sowie zur Komplexität der Gesamtheit der IT-Systeme. Um diese Basiskennzahlen zu bestimmen, ist im IS-Portfoliomanagement der SEB AG die Bestimmung der Kompliziertheit und der Komplexität jedes ITSystems mithilfe von Expertenschätzungen vorzunehmen. Die bei der SEB AG eingesetzte EAM-Lösung erlaubt in der derzeitigen Konfiguration die Bestimmung der in Abschnitt 4.4.1.2 beschriebenen Kennzahl304 KGIE zur Komplexität der Gesamtheit der IT-Systeme. In diese Größe geht zur Bestimmung der Vielfalt der IT-Landschaft die Zahl der Anwendungstypen ein, die dazu bei der SEB AG definiert und quantifiziert werden müssen. Erste Ansätze dazu existieren im 303

Siehe dazu Abschnitt 4.4.2. Die EAM-Lösung liefert die Information, ob Informationsbeziehungen zwischen Systemen bestehen; die Unterscheidung in mehrere Informationsflüsse ist nicht mit ausreichender Zuverlässigkeit möglich. 304

310

5 Evaluierung des Konzeptes zum Integrationsmanagement

IS-Portfoliomanagement und dem angewandten Lebenszyklusmodell, das entsprechend zu ergänzen ist. Die Komplexität der IT-Basisinfrastruktur wird in der ersten Stufe nicht berücksichtigt, da sie nicht im Vordergrund der von der SEB AG adressierten Problemstellung steht. Zur Messung der Gesamtkomplexität der IT-Landschaft der SEB AG ergibt sich somit gemäß der in Abschnitt 4.4.1.4 definierten Kennzahl KAEITL für die SEB AG: KAEITL (SEB AG) = Absolute Komplexität der IT-Landschaft der SEB AG =

෤M ) N

( MKX × AT ×

i

,

i=1

N × (N - 1) 2

mit

Formel 19:

N

= Anzahl IT-Systeme

Mi

= Indikator Informationsbeziehung für IT-System i, Mi = 1 oder 0

MKX

= Mittlere Komplexität der IT-Systeme

AT

= Anzahl Anwendungstypen

Kennzahl zur Gesamtkomplexität der IT-Landschaft der SEB AG

Die in der ersten Stufe entwickelten Kennzahlen können in eine Scorecard zur Komplexität der IT-Landschaft der SEB AG überführt werden, die in folgender Abbildung dargestellt ist. Komplexität der IT-Landschaft der SEB AG Mittlere Komplexität der IT-Systeme (MKX)

Mittlere Kompliziertheit der IT-Systeme (MKZ)

Vielfalt – Anzahl Anwendungstypen

Anzahl IT-Systeme

Absolute Komplexität der IT-Landschaft - KAEITIL

Anzahl Informationsflüsse

Abbildung 142: Scorecard zum Kennzahlensystem Integrationsmanagement SEB AG – Stufe 1

311

5.3 Fallstudie SEB GRUPPE

Stufe 2 Nach der erfolgreichen Umsetzung der ersten Stufe werden zusätzlich die Komplexität der IT-Basisinfrastruktur und die geschäftliche Komplexität berücksichtigt. So können ergänzend zur absoluten Komplexität der IT-Landschaft die Komplexität der IT-Basisinfrastruktur sowie die Komplexität der IT-Landschaft im Verhältnis zur geschäftlichen Komplexität ausgewiesen werden. Zur Messung der Komplexität der IT-Basisinfrastruktur müssen gemäß Abschnitt 4.4.1.2.2 die Basissystemtypen, deren Technologieausprägungen und die existierenden Instanzen erfasst und zur Kennzahl KB zusammengefügt werden. In Abschnitt 4.4.1.3 wird vorgeschlagen, die geschäftliche Komplexität zu messen - indem Experten die Komplexität der Geschäftsprozesse hinsichtlich der Unternehmens-IT einschätzen - und in die Kennzahl WK zu überführen. Dieser Ansatz kann vereinfacht werden, indem von der Ebene der einzelnen Geschäftsprozesse auf die Ebene der Geschäftsarchitektur gewechselt wird und statt Prozessen Prozessgruppen bewertet werden. Dazu kann auf die in Abbildung 123 verwendete Divisions-Prozess-Matrix zurückgegriffen werden.305 In der Matrix werden Prozessgruppen und Divisionen der Bank gegenübergestellt. Anstelle der Komplexitätsschätzung einzelner Prozesse kann die Schätzung der Komplexität der Matrixsegmente durchgeführt werden, um die wahrgenommene Komplexität der Prozesslandschaft der SEB AG zu bestimmen. In der folgenden Abbildung wird dieser Ansatz verdeutlicht. Mithilfe der Expertenschätzung durch Mitarbeiter der IT-Organisation wird die Komplexität des Prozesssegmentes der Abwicklungsprozesse MB, des Segmentes der Verkaufsprozesse Retail usw. bestimmt.306 9HUWULHE .XQGHQEHWUHXXQJ

%HUDWXQJ

9HUNDXI

$XVNXQIW  7UDQV DNWLRQHQ

9HUDUEHLWXQJ $EZLFNOXQJ

&OHDULQJ

6HWWOHPHQW

.XQGHQ 6HUYLFHV

6WHXHUXQJ 9HUWULHEV )LQDQFLDO VWHXHUXQJ  3RUWIROLR $FFRXQWLQJ 5LVLNR 3HUIRUPDQFH 0DQDJHPHQW 0DQDJHPHQW 5HSRUWLQJ  &RPSOLDQFH 0DQDJHPHQW 7UHDVXU\ 3ODQQLQJ

RETAIL

MB Gesamtbank

Komplexität Segment Abwicklungsprozesse MB

Komplexität Segment Verkaufsprozesse RETAIL

Abbildung 143: Bestimmung der wahrgenommenen Komplexität auf Basis einer Divisions-Produkt-Matrix 305

Vgl. dazu auch [Dern09], S. 71 ff. Die Verfeinerung dieses Schätzansatzes kann vorgenommen werden, indem die Divisionen in Produktgruppen verfeinert werden. Das heißt z. B., dass Retail in die Produktgruppen Konten & Einlagen, Zahlungsverkehr, Kredite, … aufgeteilt wird. 306

312

5 Evaluierung des Konzeptes zum Integrationsmanagement

Zur Messung der geschäftlichen Komplexität ergibt so als Kennzahl: WKSEB AG = Wahrgenommene geschäftliche Komplexität der SEB AG = N

䌥KU(G ) i

i=1

N

,

mit N

= Anzahl Geschäftsprozesssegmente

Gi

= Geschäftsprozesssegment i

KU (Gi ) = Komplexitätsbewertung des Segmentes i aus Sicht der IT-Organisation, 0 ˺KU ( Gi ) ˺1

Formel 20:

Kennzahl geschäftlichen Komplexität der SEB AG

Neben der beschriebenen Verfeinerung der Komplexitätssteuerung umfasst Stufe 2 die Erweiterung des Kennzahlensystems um die Messung der Aufwandsverteilung, mithilfe des in Abschnitt 4.4.2 definierten Aufwandsquotienten. Für den Stufenplan zur Einführung eines Integrationsmanagements bei der SEB AG ergibt sich so die in Abbildung 140 vorgeschlagene Gesamt-Scorecard. Komplexität der Unternehmens-IT der SEB AG IT-Landschaft

IT-Organisation

Mittlere Komplexität der IT-Systeme (MKX)

Mittlere Kompliziertheit der IT-Systeme (MKZ)

Aufwandsquotient Integrationsleistungen

Vielfalt – Anzahl Anwendungstypen

Anzahl IT-Systeme

Integrationseffizienz

Komplexität der IT-Basisinfrastruktur

Anzahl Informationsflüsse

Komplexität der IT-Organisation

Gesamtkomplexität der IT-Landschaft

Stufe 1 Relative Komplexität der IT-Landschaft

Komplexität der Geschäftsprozesse

Stufe 2 Stufe 3

Abbildung 144: Gesamt-Scorecard zum Kennzahlensystem eines Integrationsmanagement bei der SEB AG

5.3 Fallstudie SEB GRUPPE

313

Zur Einführung dieser Scorecard sind Veränderungen in der UnternehmensIT der SEB AG notwendig. Dies betrifft insbesondere die Management- und die operative Ebene der IT-Prozesslandschaft. Nach den Gestaltungsempfehlungen der Abschnitte 4.5.1 - 4.5.3 stehen hier die Prozesse des IT-Portfoliomanagements in ihrer Rolle als Integrator der IT-Prozesslandschaft im Mittelpunkt. Die Anpassung des IT-Portfoliomanagements steht daher im Fokus des folgenden Abschnittes. Die vorgeschlagene Anpassung bezieht sich auf die erste Stufe der Erweiterung des Kennzahlensystems der Unternehmens-IT der SEB AG. Bei der Anpassung werden Bewertungen der Vorgehensweisen, IT-Projekte und ITProgramme der SEB AG aus Abschnitt 5.3.3.2 berücksichtigt. 5.3.4.2 Anpassung des IT-Portfoliomanagements 5.3.4.2.1

Verankerung des Kennzahlensystems in der Prozesslandschaft

Nach dem in Abschnitt 4.5.1 entwickelten Modell werden Basiswerte zur Kennzahlenbestimmung in den IT-Prozessen der operative Ebene erhoben, im ITPortfoliomanagement zusammengeführt und daraus nach den zuvor im ITPortfoliomanagement definierten Mess- und Bewertungsmethoden in Kennzahlen überführt. Dies bedeutet zum Beispiel, dass Integrationsaufwände im Rahmen der IT-Projektdurchführung erhoben werden und im Prozess des ITPortfoliomanagements daraus die Kennzahl der Integrationseffizienz bestimmt wird. Das Kennzahlensystem selbst ist aus der in der strategischen Konzeption definierten Ausrichtung der Unternehmens-IT hergeleitet. Bei der Steuerung und Planung des IT-Portfolios werden die ermittelten Kennzahlen daher genutzt, indem sie mit den Vorgaben der strategischen Planung abgeglichen und Vorschläge zur Optimierung des IT-Portfolios abgeleitet werden – z. B. in Form von IT-Projektkandidaten. Dieses Modell zur IT-Prozessintegration ist in Abbildung 94 dargestellt. Auf Basis dieses Modells sind in Abschnitt 4.5.1 Aktivitäten beschrieben, die in den Teilprozessen des IT-Portfoliomanagements durchzuführen sind, um ein auf das Integrationsmanagement ausgerichtetes Kennzahlensystem zu implementieren. Aus diesem Modell ergibt sich das in der folgenden Abbildung dargestellte, spezifische Modell zur Verankerung der Scorecard in der ITProzesslandschaft der Unternehmens-IT der SEB AG.

314

5 Evaluierung des Konzeptes zum Integrationsmanagement

Strategische IT-Planung AG

Strategische Ebene

IT-StrategieDefinition

Kennzahlensystem zur Steuerung der Unternehmens-IT

Ableitung

Komplexitätskennzahlen

Aufwandsquotient

Integrationseffizienz

vorhandene weitere weitere Kennzahlen

Strategische Konzeption Unternehmens-IT SEB AG

Zielvorgaben

Scorecard

IT-Portfoliomanagement

ManagementEbene

Monitoring/ Bewertung

Auswertung / Verdichtung

Inventariat

Inventariat

Ist-Werte

Operative Ebene

Steuerung / Optimierung

Management von IT-Org. & IT-Landschaft SEB AG

Optimierung

Betrieb & Weiterentwicklung der IT-Landschaft SEB AG

Abbildung 145: Einbettung Integrationsmanagement in die IT-Prozesslandschaft der SEB AG 5.3.4.2.2

Erweiterung des Modells zum Lebenszyklus von IT-Systemen

Im Folgenden wird dargestellt, wie das in Abschnitt 5.3.3.1.2 beschriebene Modell der SEB AG zum Systemlebenszyklusmanagement auf das vorgeschlagene Kennzahlensystem abgestimmt werden kann. Bei dieser Erweiterung werden Bewertungen aus Abschnitt 5.3.3.2 aufgegriffen. Im Rahmen der Lebenszyklusanalyse von IT-Systemen der SEB AG werden die geschäftliche Bedeutung, die strukturell-technische und die funktionale Qualität der Systeme bewertet. Daraus werden die Change-Policy sowie der im Sinne einer Frühwarnfunktion auszuweisende Systemstatus abgeleitet. Zur Unterstützung der ersten Stufe der Umsetzung des Kennzahlensystems muss das Lebenszyklusmodell um die Bewertung der Komplexität und der Kompliziertheit der IT-Systeme ergänzt werden. Bei der Bewertung des Komplexitätsmanagementansatzes der SEB AG in Abschnitt 5.3.3.2.2 wurde dargelegt, dass unnötige Kompliziertheit in der ITLandschaft der SEB AG insbesondere auf unzureichende Lebenszyklussteuerung in Bezug auf die Beherrschbarkeit der Systeme zurückzuführen ist. Dieser Bewertung wird Rechnung getragen, indem das Lebenszyklusmodell der SEB AG um die Phasenzuordnung für IT-Systeme nach dem in Abschnitt 4.6.2 entwickelten Modell erweitert wird und darüber hinaus bewertet wird, ob die Theorie eines

5.3 Fallstudie SEB GRUPPE

315

Systems durch die Betreuungsorganisation beherrscht wird. Die Erweiterung des Lebenszyklusmodells der SEB AG kann in eine erweiterte Scorecard für ITSysteme überführt werden. Sie ist in Abbildung 142 dargestellt und weist die Komplexität, die Kompliziertheit, die Beherrschbarkeit sowie die Zahl ein- und ausgehender Informationsflüssen für ein IT-System aus. Die Bewertung des Komplexitätsmanagements bei der SEB AG in Abschnitt 5.3.3.2.2 mündet in der Empfehlung, die Sicherstellung der Reaktionsfähigkeit der Unternehmens-IT als wesentliche Randbedingung bei der Steuerung der Komplexität der Unternehmens-IT der SEB AG zu berücksichtigen. Dieser Empfehlung wird im Lebenszyklusmodell entsprochen, indem die Reaktionsfähigkeit von IT-Systemen bewertet und der angestrebten gegenübergestellt wird. Mithilfe eines für die SEB AG zu definierenden Bewertungsansatzes kann so ausgewiesen werden, ob die Reaktionsfähigkeit eines Systems den Anforderungen der unterstützten Geschäftsprozesse genügt. Zusätzlich ermöglicht dies die Steuerung von Konsolidierungsvorhaben in der IT-Landschaft, wie das in Abschnitt 5.3.2.2.3 beschriebene Programm zur DWH-Konsolidierung, unter Einbeziehung der Wirkung auf die Reaktionsfähigkeit. Die Erweiterung des bestehenden Lebenszyklusmodells bewirkt, dass der Systemstatus und die Change-Policy eines IT-Systems nicht nur von der geschäftlichen Bedeutung, der technisch-strukturellen und funktionalen Qualität abhängen, sondern zusätzlich auf der Einschätzung der Reaktionsfähigkeit, der Systembeherrschung und der Systemkomplexität beruhen. Die folgende Abbildung zeigt das erweiterte Modell zum Lebenszyklusmanagement der ITSystemen der SEB AG.

316

5 Evaluierung des Konzeptes zum Integrationsmanagement

Scorecard für IT-Systeme geschäftliche Bedeutung

Systemqualität

Systemkomplexität

strukturell-technisch

Komplexität

funktional

Kompliziertheit

Reaktionsfähigkeit

Anzahl Infoflüsse

Systembeherrschung Theorie des Systems

Phase

Ist

Soll

Zusammenfassung Systemstatus

Change-Policy

Abbildung 146: IT-Portfoliomanagement bei der SEB AG - erweiterte Scorecard307 zum Lebenszyklus von IT-Systemen DWH–Konsolidierung und Scorecard der Systeme Data1 und AG-BIW Im Programm zur DWH-Konsolidierung soll die DWH-Landschaft der SEB AG auf weniger DWH-Systeme konsolidiert und so die Komplexität der ITLandschaft reduziert werden. Ein Kernelement dieser Konsolidierung besteht in der Verlagerung des Systems Data1 auf das BIW der SEB AG. Für beide Systeme wird nun die Scorecard aufgestellt und zur Bewertung der geplanten Konsolidierung genutzt. Das IT-Programm zur DWH-Konsolidierung sieht vor, die Funktionalität und die Informationsflüsse des Systems Data1 auf das BIW der SEB AG zu übertragen und dann Data1 abzuschalten. Data1 befriedigt heute Informationsbedarfe des Meldewesens und des operativen Kreditrisikomanagements. Die aktuelle Bewertung von Data1 ist in der nachstehenden Tabelle dargestellt. Der Systemstatus ist „gelb“, da die IT-Infrastruktur nicht auf einer Standardplattform der SEB GRUPPE beruht und zudem Lücken in der Informationsversorgung des Meldewesens bestehen. In Bezug auf die Wartung und die Weiterentwicklung von Data1 besteht eine erhebliche Abhängigkeit von externen Mitarbeitern.

307

In der Scorecard wird die Reaktionsfähigkeit als Zusammenfassung von dynamischem und statischem Potenzial ausgewiesen.

317

5.3 Fallstudie SEB GRUPPE

System

Status

Data 1

gelb

Tabelle 9:

strukturelltechnische Qualität rot

funktionale Qualität gelb

Business Value hoch

Change Policy replace

Scorecard des Systems Data1

Die folgende Abbildung zeigt die durch den Autor der vorliegenden Arbeit auf Basis des erweiterten Lebenszyklusmodells vorgenommene Bewertung308 des Systems Data1 (bestehende Bewertung hervorgehoben). geschäftliche Bedeutung

Systemqualität

Systemkomplexität

hoch

strukturell-technisch

Komplexität

rot

gering

funktional

Kompliziertheit

gelb

gering

Systembeherrschung Theorie des Systems beherrscht

Komplexitätsphase Stabilität

Reaktionsfähigkeit

Anzahl Infoflüsse

hoch

hoch

30

2

Ist

Soll

eingehend

ausgehend

Zusammenfassung Systemstatus gelb Change-Policy replace

Abbildung 147: Erweiterte Scorecard zu Data1 Im Einzelnen gilt für Data1: ƒ

ƒ

Die Reaktionsfähigkeit von Data1 wird als hoch bewertet, da die Architektur des Systems und die Betreuungsorganisation so aufgestellt sind, dass dem steten Wandel der Auflagen des deutschen Meldewesens für Banken entsprochen werden kann. Komplexe Verarbeitungslogik ist nicht in Data1, sondern in den angeschlossenen Systemen (Meldewesen-Liefer-Engine sowie operatives Kredit-

308 Hier wird davon ausgegangen, dass die zusätzlich ausgewiesenen Größen wie im bestehenden Ansatz der SEB AG mittels Expertenschätzung auf Basis von Nominal- bzw. Ordinalskalen quantifiziert werden. Folgende Ausprägungen werden vorgeschlagen: Theorie des Systems: beherrscht, gefährdet, verloren; Reaktionsfähigkeit: gering, mittel, hoch; Komplexität: gering, mittel, hoch, sehr hoch; Kompliziertheit: gering, mittel, hoch, sehr hoch.

318

ƒ

5 Evaluierung des Konzeptes zum Integrationsmanagement

risiko- und Limitsystem) realisiert. Systemkomplexität und -kompliziertheit von Data1 werden als gering bewertet. Die Theorie des Systems wird als beherrscht bewertet. Das System wird zwar weitgehend durch externe Mitarbeiter betreut. Da sich die Systemkomplexität jedoch als gering darstellt, wird dies in Bezug auf die Beherrschbarkeit als unproblematisch eingestuft.

Tabelle 10 zeigt die Scorecard für das Zielsystem der Konsolidierung von Data1, dem BIW der SEB AG. Die funktionale Qualität des lokalen BIW ist „gelb“, da die Anforderungen der Prozesse der Retail-Vertriebssteuerung und des Retail-Performance-Managements nicht vollständig abgedeckt werden. System

Status

AG-BIW

grün

Tabelle 10:

strukturelltechnische Qualität gelb

funktionale Qualität grün

Business Value hoch

Change Policy grow local

Scorecard des BIW der SEB AG

Abbildung 148 zeigt die Bewertung des AG-BIW innerhalb des erweiterten Lebenszyklusmodells (bestehende Bewertung hervorgehoben) durch den Autor der vorliegenden Arbeit. geschäftliche Bedeutung

Systemqualität

Systemkomplexität

hoch

strukturell-technisch

Komplexität

grün

mittel

funktional

Kompliziertheit

gelb

niedrig

Systembeherrschung Theorie des Systems gefährdet

Komplexitätsphase Wachstum

Reaktionsfähigkeit

Anzahl Infoflüsse

gering

hoch

35

10

Ist

Soll

eingehend

ausgehend

Zusammenfassung Systemstatus gelb Change-Policy grow local

Abbildung 148: Erweiterte Scorecard zum BIW der SEB AG

5.3 Fallstudie SEB GRUPPE

319

Im Einzelnen gilt für das BIW der SEB AG: ƒ

ƒ

ƒ

Komplexe Verarbeitungslogik ist im Bereich der Distribution-Area des AGBIW realisiert. Hier werden die zuvor in der Staging Area aufbereiteten und in der BIW-Datenbank gespeicherten Daten auf den Informationsbedarf der Abnehmer transformiert und in Form geschäftsspezifischer Sichten, z. B. als Data Mart, bereitgestellt. Die Systemkomplexität wird daher insgesamt als mittel bewertet. Die Kompliziertheit wird als gering eingeordnet, da die gesamte im AG-BIW implementierte Funktionalität die definierten DesignStandards einhält. Die Reaktionsfähigkeit wird als gering bewertet, da die Betreuungsorganisation derzeit einen „Flaschenhals“ repräsentiert. So werden z. B. die im Hinblick auf die Umsetzungsdauer geringeren Anforderungen der Prozesse der Vertriebssteuerung und des Performance-Managements von Retail nur teilweise erfüllt. Die Theorie des Systems wird als gefährdet bewertet, da sie nur von einer Mitarbeiterin beherrscht wird, die das Unternehmen aus Altersgründen in absehbarer Zeit verlassen wird.

Durch den Vergleich der beiden Scorecards wird die in Abschnitt 5.3.3.2.4 erstellte Bewertung der DWH-Konsolidierung untermauert. Die vorgesehene Verlagerung des Systems Data1 bedeutet das Ersetzen eines Systems mit hoher durch ein System mit geringerer Reaktionsfähigkeit. Die Betreuungsorganisation des Zielsystems ist bisher nicht auf die geforderte Reaktionsfähigkeit der zusätzlich zu unterstützenden Prozessgruppen ausgerichtet. Zudem ist die Theorie des Zielsystems gefährdet, was das Risiko einer Zunahme der Systemkompliziertheit und des Übergangs in die Phase des Verlustes der Beherrschbarkeit bedingt. Aus Sicht der Steuerungsfunktion des IT-Portfoliomanagements wären daher Maßnahmen durchzuführen, um die Reaktionsfähigkeit des BIW der SEB AG durch die Weiterentwicklung der Betreuungsorganisation so zu verbessern, dass der definierten Change-Policy (grow local) auch tatsächlich entsprochen werden kann und so die Risiken der Verlagerung des Systems Data1 verringert werden. Für das Programm der DWH-Konsolidierung bedeutet dies die Empfehlung, zusätzlich ein Projekt vorzusehen, das Maßnahmen zur Verbesserung der Reaktionsfähigkeit und der Beherrschung des BIW durchführt. Erst dann sollten Konsolidierungsschritte wie die Verlagerung von Data1 auf das AG-BIW unternommen werden.

320

5 Evaluierung des Konzeptes zum Integrationsmanagement

5.3.4.3 IT-Portfoliomanagement und Optimierung der IT-Projektdurchführung Aus der Optimierung des IT-Portfoliomanagements ergeben sich Optimierungsansätze für den IT-Prozess der Projektdurchführung. Im entsprechenden Prozess der SEB AG, dem „Process for Ventures“, sind Entscheidungspunkte vorgesehen, an denen Projektkandidaten und Projekte beurteilt werden. Fließt hier zusätzlich die Wirkung von Projekten auf die IT-Landschaft unter Nutzung der Scorecards der relevanten Systeme in die Business-Case-Analyse ein, können Risiken genauer abgeschätzt und die Zielsetzung und der Zuschnitt von ITProjekten optimiert werden. Ein entsprechend erweitertes Modell zur Projekt Business-Case-Analyse ist in Abschnitt 4.5.2 beschrieben. 5.3.4.4 Zusammenfassung In Abschnitt 5.3.4 wurde auf Basis der zuvor vorgenommenen Analyse und Bewertung von Vorgehensweisen, Projekten und Programmen der SEB GRUPPE ein Vorschlag zur Optimierung der Unternehmens-IT SEB AG entwickelt. Die Optimierung beruhte auf der Anwendung des Konzeptes zum Integrationsmanagement, wie es in der vorliegenden Arbeit entwickelt wurde. Die Anwendung zeigte keine Widersprüche in den Gestaltungsempfehlungen, d. h. die vorgenommene Optimierung führte nicht zur Falsifizierung der Gestaltungsempfehlungen und der enthaltenen Artefakte. 5.4 Zusammenfassung der Evaluierung Der für die vorliegende Arbeit definierte Evaluierungsansatz beruhte darauf, einen möglichste großen Teil des entwickelten Konzeptes durch die Anwendung der Gestaltungsempfehlungen und der enthaltenen Artefakte entlang einer umfassenden Fallstudie zu überprüfen. Hier wurde die SEB GRUPPE ausgewählt, da die im Unternehmen adressierten Problemstellungen in den Kontext der vorliegenden Arbeit fallen und für dieses Unternehmen breit angelegte und zugleich detaillierte Informationen über Problemstellungen, Lösungsansätze, Vorgehensweisen und IT-Projekte vorlagen. Die Anwendung der Gestaltungsempfehlungen erfolgte in zwei Schritten – der Bewertung und der Optimierung. In beiden Schritten erwiesen sich die in den entsprechenden Gestaltungsempfehlungen enthalten Artefakte als widerspruchsfrei anwendbar. Aus Sicht des Autors der vorliegenden Arbeit erwiesen sich die aufgestellten Empfehlungen als für die Optimierung der IT-Prozesslandschaft von Unternehmen geeignet, die sich vergleichbaren Problemstellungen gegenübersehen. Besonders hervorzuheben sind hier die Möglichkeiten der Optimierung bzw. Erweiterung des Kennzahlensys-

321

5.4 Zusammenfassung der Evaluierung

tems zur Steuerung der Unternehmens-IT und dessen Verankerung auf allen Ebenen der IT-Prozesslandschaft. Gemäß dem definierten Ansatz bestand die Zielsetzung der Evaluierung im Versuch der Falsifizierung des Konzeptes unter möglichst weitgehender Anwendung der Gestaltungsempfehlungen. Aufgrund der in Abschnitt 5.1 beschriebenen Restriktionen können die aufgestellten Gestaltungsempfehlungen und die enthaltenen Artefakte im Rahmen der vorliegenden Arbeit jedoch nicht vollständig überprüft werden. Die folgende Abbildung hebt die durch die Evaluierung abgedeckten Bereiche des entwickelten Konzeptes hervor. Innerhalb dieser Grenzen ist die Evaluierung erfolgreich abgeschlossen. Gestaltungsprinzipien Verständnis der Unternehmens-IT als komplexes Teilsystem des Unternehmens

Integrationsmanagement folgt umfassendem Spektrum von Integrationsanforderungen

Integrationsmanagement als Teildisziplin des IT-Managements

Integrationsmanagement innerhalb der Leitplanken einer IT-Unternehmensarchitektur

Übergreifende Gestaltungsempfehlungen Komplexitätsmanagement in der Unternehmens-IT

Gestaltung ganzheitlicher Integrationslösungen

Aufbau einer integrierten Informationswirtschaft in verteilt organisierten Unternehmen

Handlungsmuster für die Integration der Unternehmens-IT bei Fusionen und Übernahmen

Unternehmens-IT und adaptive Unternehmensarchitekturen

Verfeinerung der übergreifenden Gestaltungsempfehlungen Rahmen: Referenzmodell zur IT-Prozesslandschaft (IT-Prozessarchitektur) Kennzahlensystem zum Integrationsmanagement Komplexität der Unternehmens-IT

Integrationseffizienz

…

Ergänzende Leitlinien Reflexion Kennzahlensystem

Lebenszyklusmanagement

Ergänzende Betrachtungen zu Integrationslösungen

Adaptierbarkeit, Flexibilität, Agilität

Empfehlungen zur Steigerung der Integrationseffizienz

Abbildung 149: Abdeckung des entwickelten Konzeptes zum Integrationsmanagement im Rahmen der vorgenommenen Evaluierung

6 Schlussbetrachtung und Ausblick Im Schlusskapitel der Arbeit werden die wesentlichen Ergebnisse zusammengefasst. Dann wird das durchgeführte Forschungsvorhaben einer kritischen Würdigung unterzogen. Abschließend werden Ansatzpunkte für weitere Forschungsaktivitäten aufgezeigt und ein Ausblick vorgenommen. 6.1 Ergebniszusammenfassung Das Ziel der vorliegenden Arbeit besteht in der Beantwortung der zentralen Forschungsfrage nach der Gestaltung eines Gesamtkonzeptes zum ganzheitlichen Integrationsmanagement in der Unternehmens-IT. Diese Zielsetzung beruht auf der Beobachtung, dass Integrationsleistungen aufgrund wachsender regulatorischer Anforderungen, erhöhter Wettbewerbsintensität und technologischen Wandels in zunehmendem Maße die durch die Unternehmens-IT erbrachten Leistungen für die Umsetzung fachlicher Anforderungen im engeren Sinne dominieren. Daraus ergibt sich das primäre Gestaltungsziel der Arbeit, ein System von Empfehlungen zur Gestaltung der Unternehmens-IT größerer Unternehmen im Hinblick auf diese Problematik zu entwickeln, und das primäre Erkenntnisziel, Möglichkeiten zu beurteilen, die Stärke des beschriebenen Trends zu beeinflussen. Die Grundlagen der Arbeit wurden im zweiten Kapitel gelegt. Zunächst wurde die Unternehmens-IT größerer Unternehmen ausgehend von der Systemtheorie als komplexes, offenes, dynamisches System definiert. Anschließend wurde das für die Arbeit gültige Verständnis von Integrationsmanagement definiert. Integrationsmanagement wurde als Teildisziplin des Managements der Unternehmens-IT positioniert, und es wurde ein Grundmodell zum Integrationsmanagement entwickelt. Anschließend wurde das Verständnis von Unternehmensarchitektur für die vorliegende Arbeit geklärt und der Bezug zum Integrationsmanagement beleuchtet, indem die IT-Integrationsarchitektur als Teil der ITUnternehmensarchitektur positioniert wurde. Das Kapitel wurde mit der Aufstellung von vier Prinzipien des Integrationsmanagements zusammengefasst. In Kapitel 3 wurden übergreifende Gestaltungsempfehlungen zum Integrationsmanagement ausgehend von der Analyse verwandter Arbeiten aus Forschung und Praxis entwickelt. Dabei wurden die definitorischen Grundlagen der Arbeit erweitert und im Rahmen des gewählten Design-Science-Ansatzes weitere Artefakte entwickelt. Ergebnis des Kapitels ist die erste Stufe des geforderten Gesamtkonzeptes zum Integrationsmanagement, bestehend aus Gestaltungsprinzipien, übergreifenden Empfehlungen und den darin eingebetteten Artefakten, d. h. Definitionen, Modellen und Methoden. Aus Sicht des damit verbundenen G. Dern, Integrationsmanagement in der Unternehmens-IT, DOI 10.1007/978-3-8348-8154-0_6, © Vieweg+Teubner Verlag | Springer Fachmedien Wiesbaden GmbH 2011

324

6 Schlussbetrachtung und Ausblick

Erkenntnisprozesses ist der herausragende Einfluss der Komplexität der Unternehmens-IT auf die von der IT-Organisation erbrachten Integrationsleistungen hervorzuheben. Komplexitätsmanagement muss daher als Kerndisziplin eines Integrationsmanagements eingeordnet werden. Es wurde gezeigt, dass die Komplexität der Unternehmens-IT positiv mit der Komplexität der Geschäftsseite korreliert ist und daher zwingend im Integrationsmanagement berücksichtigt werden muss. Des Weiteren wurde gezeigt, dass ein Komplexitätsmanagement in der Unternehmens-IT immer unter Einbeziehung der für die Lebensfähigkeit des Unternehmens notwendigen Reaktionsfähigkeit der Unternehmens-IT organisiert werden muss. Aus den aufgezeigten Zusammenhängen konnte abgeleitet werden, dass unter der Annahme weiter steigender geschäftlicher Komplexität mit weiter steigenden Integrationsleistungen zu rechnen ist. In diesem Zusammenhang wurde gezeigt, dass der Zunahme von Integrationsaufwänden nur bedingt durch ISArchitekturen und neue Technologien begegnet werden kann. Im Hinblick auf das Erkenntnisziel der Arbeit - die Beurteilung der Möglichkeiten, die Stärke des Trends zur Zunahme von Integrationsleistungen zuungunsten von Leistungen für fachliche Anforderungen i. e. S. zu beeinflussen – ist daraus zu schließen, dass der Trend bei steigender geschäftlicher Komplexität nicht umgekehrt werden kann. Eine realistische Zielsetzung für ein Integrationsmanagement in der Unternehmens-IT besteht daher darin, die Komplexität der Unternehmens-IT unter der Nebenbedingung der Sicherstellung der mindestnotwendigen Reaktionsfähigkeit zu minimieren und so die Zunahme von Integrationsleistungen innerhalb des bestehenden Trends so gering wie möglich zu halten. Im 4. Kapitel wurde zunächst der Verfeinerungsbedarf analysiert, wie er sich aus den Ergebnissen des 3. Kapitels ergibt, und daraus die Aufgabenstellung der weiteren Ausarbeitung abgeleitet. Deren Bearbeitung mündet unter Konstruktion weiterer Artefakte in weiterführenden Gestaltungsempfehlungen und Leitlinien zur Organisation der IT-Landschaft. Diese Ergebnisse können genutzt werden, um die oben vorgeschlagene Zielsetzung - die Zunahme von Integrationsleistungen so gering wie möglich zu halten - zu erreichen. Zentrales Artefakt des Kapitels ist ein Gesamtmodell zur kennzahlenbasierten Verankerung des Integrationsmanagements auf allen Ebenen der IT-Prozesslandschaft dar. Das entwickelte Kennzahlensystem ist als Erweiterung vorhandener Kennzahlensysteme zur Steuerung der Unternehmens-IT positioniert. Der Schwerpunkt des Kennzahlensystems liegt auf der Komplexität der IT-Landschaft. Auf der Grundlage dieses Artefaktes wurden ƒ

erweiterte Modelle zum IT-Portfoliomanagement und zur IT-Projektdurchführung entwickelt,

6.2 Kritische Würdigung

ƒ ƒ ƒ

325

Empfehlungen zur proaktiven Gestaltung von IT-Systemen und IT-Landschaften zur Antizipation zukünftiger Anforderungen, insbesondere Integrationsanforderungen, erarbeitet, ganzheitliche Integrationslösungen reflektiert und Möglichkeiten der Steigerung der Leistungsfähigkeit der IT-Organisation in Bezug auf die Erbringung von Integrationsleistungen analysiert.

Mit Abschluss des 4. Kapitels liegt das geforderte Gesamtkonzept zum Integrationsmanagement, bestehend aus Gestaltungsprinzipien, Empfehlungen und den darin eingebetteten Artefakten, d. h. Definitionen, Modellen und Methoden, vor. Das Gesamtkonzept wurde im 5. Kapitel evaluiert, indem auf Basis des definierten Forschungsdesigns und der daraus abgeleiteten Evaluierungsmethode eine umfassende, detailliert und breit angelegte Fallstudie analysiert wurde. Dabei wurde ein großer Teil der entwickelten Artefakte einbezogen. Im Rahmen dieser Fallstudie gelingt keine Falsifizierung, sodass bis auf weiteres von der Gültigkeit des entwickelten Konzeptes und den enthaltenen Gestaltungsempfehlungen ausgegangen werden kann. 6.2 Kritische Würdigung Ziel des Abschnittes ist die kritische Diskussion des durchgeführten Forschungsvorhabens. Das Vorhaben wurde auf Basis des Forschungsparadigmas des Design-Science-Ansatzes durchgeführt. Im Rahmen dieses Ansatzes wurde die zentrale Forschungsfrage durch die Aufstellung eines Gesamtkonzeptes zum ganzheitlichen Integrationsmanagement beantwortet. Das primäre Gestaltungsziel wurde durch die Entwicklung eines Systems von Gestaltungsempfehlungen erreicht. Wie in Abschnitt 6.1 beschrieben, besteht die zentrale Erkenntnis des durchgeführten Forschungsvorhabens darin, dass Integrationsmanagement die Zielsetzung verfolgen muss, die Komplexität der Unternehmens-IT unter der Nebenbedingung der Aufrechterhaltung der mindestnotwendigen Reaktionsfähigkeit zu minimieren und so die Zunahme von Integrationsleistungen innerhalb des bestehenden Trends so gering wie möglich zu halten. Aus dem entwickelten System von Gestaltungsempfehlungen folgt die Erkenntnis, dass unter der Randbedingung dieser Zielsetzung ein Instrumentarium von Modellen und Methoden zur Verfügung steht, um den beschriebenen Trend innerhalb der Leitplanken der jeweiligen Unternehmensarchitektur aktiv zu beeinflussen. Die Weiterentwicklung der IT-Prozesslandschaft entlang dieser Modelle und Methoden bildet hierfür die Grundlage. Das Erkenntnisziel des Forschungsvorhabens wurde somit erreicht.

326

6 Schlussbetrachtung und Ausblick

Die im Folgenden durchgeführte kritische Würdigung des Forschungsvorhabens orientiert sich an dem von FISCHER309 gewählten Vorgehen, das auf der Arbeit Design Science in Information Systems Research von HEVNER, MARCH, PARK UND RAM310 beruht. Demnach muss der im Rahmen eines Design-ScienceForschungsvorhabens durchgeführte Forschungsprozess folgenden Kriterien genügen: ƒ ƒ ƒ ƒ ƒ ƒ

Der Prozess liefert ein innovatives, zweckgerichtetes und anwendbares Artefakt. Der Prozess sucht Lösungen für wichtige, real existierende Probleme und liefert so ein relevantes Artefakt (Relevanz). Der Nutzen und die Qualität des Artefaktes müssen durch Evaluierung nachgewiesen werden. Der Prozess liefert einen nachvollziehbaren und nachprüfbaren Forschungsbeitrag. Der Prozess genügt den forschungsmethodischen Grundsätzen der Stringenz und der iterativen Suche nach einer anspruchserfüllenden Problemlösung. Die erzielten Ergebnisse sind in geeigneter Form zu kommunizieren.

Das Ergebnis der vorliegenden Arbeit ist das Gesamtkonzept zum Integrationsmanagement. Es ist als Artefakt zu verstehen, welches sich aus den enthaltenen Definitionen, Modellen und Methoden und deren Einbettung in Gestaltungsempfehlungen konstituiert. Das Gesamtkonzept wurde erarbeitet, indem aus Beobachtungen Hypothesen hergeleitet und darauf aufbauend Definitionen, Modelle und Methoden konstruiert wurden, die über die Aufstellung von Gestaltungsempfehlungen zum Gesamtartefakt zusammengeführt wurden. Dabei wurden verschiedene Arbeiten aus Forschung und Praxis einbezogen. Das Konzept liefert auf diese Weise ein Gesamtsystem aufeinander abgestimmter Gestaltungsempfehlungen, das Arbeiten aus Forschung und Praxis in einem Gesamtmodell einbindet und zahlreiche, neu entwickelte Detailmodelle und -methoden umfasst. Das entwickelte Artefakt weist daher innovativen Charakter auf. Die umfassende Fallstudie zur SEB zeigt die Anwendbarkeit und die Zweckmäßigkeit des entwickelten Gesamtkonzeptes. Die Relevanz der vorliegenden Arbeit ergibt sich aus der im 1. Kapitel beschriebenen Problemstellung und dem aufzeigten Handlungsbedarf. Fallbeispiele von Großunternehmen wie der SEB GRUPPE und der COMMERZBANK belegen den Handlungsbedarf ebenso wie die im Rahmen des Forschungsprozesses berücksichtigten Beobachtungen aus den in Abschnitt 1.5 aufgeführten Quellen. 309 310

Vgl. [Fischer08], S. 246 ff. Vgl. [HMPR04].

6.2 Kritische Würdigung

327

Die Analyse verwandter Arbeiten aus Forschung und Praxis zeigt die bestehende Forschungslücke in Bezug auf ein Integrationsmanagement, wie es sich aus dem in der Arbeit definierten Integrationsspektrum ergibt. Diese Forschungslücke wird durch das konstruierte Artefakt geschlossen. Der Nutzen und die Qualität des entwickelten Artefaktes werden durch die Evaluierung im 5. Kapitel der Arbeit nachgewiesen, indem im Rahmen der umfassenden Fallstudie zur SEB GRUPPE gezeigt wird, dass das Gesamtkonzept geeignet ist, Problemstellungen und Lösungsansätze in einem größeren Unternehmen aufzugreifen, zu bewerten und Optimierungen durchzuführen. Wie bereits in Abschnitt 5.1 ausgeführt, weist FRANK darauf hin, dass die Implementierung in einem einzigen Fall zum Nachweis der Effektivität und der Effizienz der Artefakte nur dann ausreicht, wenn dieser eine Fall als repräsentativ für alle anderen Fälle angesehen werden kann. Da die SEB GRUPPE nicht als repräsentativ für alle anderen größeren Unternehmen angesehen werden kann, müsste die Überprüfung des Nutzens und der Qualität der Gestaltungsempfehlungen in ihrer Gesamtheit durch die Anwendung in einer als repräsentativ anzusehenden Auswahl größerer Unternehmen erfolgen, um die Validität des Artefaktes zu erhöhen. FRANK stell fest, dass dies für wissenschaftliche Arbeiten häufig nicht realisierbar ist. Dies trifft auch auf die vorliegende Arbeit zu und zeigt sich auch darin, dass keine vollständige Abdeckung des Gesamtkonzeptes im Rahmen der Evaluierung erreicht werden konnte (s. Abbildung 149). Das im Rahmen der Arbeit entwickelte Gesamtkonzept stellt einen Forschungsbeitrag dar, da es, wie o. a., eine bestehende Forschungslücke schließt. Im 1. Kapitel wurde das Forschungsdesign der Arbeit definiert und daraus ein Vorgehensmodell (s. Abbildung 8) für den Gang der Untersuchung abgeleitet. Das Vorgehensmodell mit den darin definierten Schritten wurde nachvollziehbar und nachprüfbar umgesetzt. Der Forschungsbeitrag der Arbeit erfüllt somit das Kriterium der Nachvollziehbarkeit und der Nachprüfbarkeit. Aus der systematischen Festlegung des Forschungsdesigns im 1. Kapitel und der Anwendung der in der Wirtschaftsinformatik allgemein akzeptierten Forschungsmethoden der deduktiven Analyse, der induktiven und deduktiven Modellierung sowie der Fallstudie (s. Abbildung 7) ergibt sich die Stringenz des durchgeführten Forschungsprozesses. Das heißt, dass der im Forschungsdesign festgelegte Problemlösungsanspruch erfüllt wird. Kritisch ist anzumerken, dass die im Rahmen des Forschungsprozesses entwickelte Lösung keine optimale Lösung darstellt. Fischer führt aus, dass Forschungsvorhaben, die dem Design-Science-Ansatz folgen, in der Regel keine optimale Lösung bestimmen. Das Vorgehensmodell der Arbeit generiert ein iteratives Vorgehen, das unter Einbeziehung verwandter Arbeiten zur Beantwortung der aufgestellten Forschungsfrage und zur Erreichung des primäre Erkenntnis- sowie des primären Gestaltungsziels führt. Zu-

328

6 Schlussbetrachtung und Ausblick

sammenfassend kann daher gesagt werden, dass das Forschungsvorhaben iterativ eine der möglichen Lösungen für die im Forschungsdesign festgelegte Problemstellung erzeugt, die dem definierten Problemlösungsanspruch gerecht wird. Neben diesen auf den gestaltungsorientierten Design-Science-Ansatz ausgerichteten Kriterien sind nach FISCHER der Referenzcharakter, d. h. die Allgemeingültigkeit innerhalb des beanspruchten Gültigkeitsbereiches, der Empfehlungscharakter und der Abstraktionsgrad des entwickelten Gesamtkonzeptes zu hinterfragen. Das in der Arbeit entwickelte Artefakt – d. h. das Gesamtkonzept zum Integrationsmanagement – ist auf die Unternehmens-IT größerer Unternehmen ausgerichtet. Wie in der Integrationsperspektive definiert, handelt es sich um die Klasse von Unternehmen, für die die Unternehmens-IT strategische Bedeutung besitzt und deren Unternehmens-IT oberhalb der Komplexitätsbarriere liegt. Das Artefakt wurde für diese Klasse von Unternehmen mit dem Anspruch von Allgemeingültigkeit konstruiert und wird als Grundlage einer entsprechenden Gestaltung der Unternehmens-IT empfohlen. Der Nachweis der Allgemeingültigkeit kann, wie oben beschrieben, nicht vollständig durch die Evaluierung mittels Fallstudie erbracht werden. Das Gesamtkonzept bezieht sich nicht auf ein einzelnes Unternehmen, sondern basiert auf dem systemtheoretischen Modell des Unternehmens und seiner Unternehmens-IT, wie es in Abschnitt 2.1 konstruiert wurde. Dieses Modell bestimmt den Abstraktionsgrades des Artefaktes. 6.3 Ansatzpunkte für weitere Forschungsaktivitäten Bei der Abgrenzung der vorliegenden Arbeit im Laufe der durchgeführten Untersuchung wurden in mehreren Bereichen Ansatzpunkte für weiterführende Forschungsaktivitäten identifiziert. Daraus können Schwerpunkte zukünftiger Forschungsarbeiten abgeleitet werden. In den nachfolgend hervorgehobenen Schwerpunkten manifestiert sich insbesondere die in der Arbeit gewonnene Erkenntnis, dass die von der Unternehmens-IT erbrachten Aufwände entscheidend von der Komplexität der Unternehmens-IT bestimmt werden, vorhandene oder zusätzliche Komplexität und damit die durch sie getriebene Höhe der Aufwände jedoch nur in Relation zu der angestrebten Reaktionsfähigkeit des Unternehmens beurteilt werden können. Integrationsaufwände, die durch wertschöpfende Komplexität verursacht werden, sind vor diesem Hintergrund als notwendige Folge der Ausdifferenzierung des Unternehmens zur Sicherstellung seiner Lebensfähigkeit einzuordnen. ƒ

Messung der Reaktionsfähigkeit der Unternehmens-IT Das Konstrukt der Reaktionsfähigkeit stellt einen essenziellen Baustein des entwickelten Systems von Gestaltungsempfehlungen dar. Es wird zusam-

6.3 Ansatzpunkte für weitere Forschungsaktivitäten

ƒ

ƒ

ƒ 311

329

men mit Größen wie der Komplexität der Unternehmens-IT als Größe zur Steuerung der Unternehmens-IT vorgeschlagen. Im Zuge der Abgrenzung der vorliegenden Arbeit wird die Reaktionsfähigkeit bei der Entwicklung des konkreten Kennzahlensystems zugunsten der Entwicklung von Detailgrößen zur Messung der Komplexität ausgeklammert. Dies führt z. B. dazu, dass im entwickelten, erweiterten Modell zur IT-Projektdurchführung Reaktionsfähigkeit mithilfe einer qualitativen Expertenschätzung einbezogen wird. Da die Komplexität der Unternehmens-IT immer relativ zur notwendigen Reaktionsfähigkeit zu sehen ist, würde die Entwicklung konkreter Kennzahlen zur Messung der Reaktionsfähigkeit der Unternehmens-IT die Möglichkeiten verbessern, die Qualität der Unternehmens-IT im Hinblick auf die Dynamik der Unternehmensumwelt zu bewerten und explizit ins Verhältnis zur Komplexität der Unternehmens-IT zu setzen. Messung der Komplexität der IT-Organisation und Korrelationen Detailbetrachtungen zur Komplexität der Unternehmens-IT werden auf das Teilsystem der IT-Landschaft beschränkt. Die Ausdehnung des vorliegenden Kennzahlensystems auf die IT-Organisation würde die Komplexitätsmessung der gesamten Unternehmens-IT ermöglichen. Hieran könnte sich, ausgehend von der beschriebenen positiven Korrelation der Komplexität der Teilsysteme IT-Landschaft und IT-Organisation, eine weitergehende Analyse der Wechselwirkungen zwischen diesen Teilsystemen der Unternehmens-IT anschließen. Erweitertes Verständnis von IT-Systemen Die Ausführungen zur Komplexität auf Basis der Theorie der Systementwicklung als Theoriebildung von Naur zeigen, dass die Definition des Begriffes IT-Systems311, wie sie in der vorliegenden Arbeit getroffen wurde und wie sie auch in der Praxis verbreitet ist, möglicherweise zu eng gefasst ist. Dieses Verständnis begreift IT-Systeme als eine durch den gemeinsamen Zweck abgegrenzte Menge miteinander interagierender Softwarebausteine. Ein verändertes Verständnis des Begriffes IT-System würde die das System entwickelnden und betreuenden Personen und damit explizit die Systemelemente der IT-Organisation einbeziehen. Ein solches Verständnis würde Fragen des Anwendungsmanagements, der Integration, Fragen der Komplexität usw. stets aus Sicht der Softwarebausteine, der Infrastrukturkomponenten etc. und aus Sicht der sie betreuenden Personen behandeln. Reichweite von Integrationslösungen

Im Sinne des in der Arbeit verwendeten Verständnisses als Anwendung bzw. als Kommunikationssystem.

330

6 Schlussbetrachtung und Ausblick

Bei der Analyse ganzheitlicher Integrationslösungen zeigt sich, dass der in Praxis und Forschung häufig postulierte Anspruch der unternehmensweiten Verwendung zu hinterfragen ist. Insbesondere in Bezug auf DataWarehouse-Systeme stellt sich die Frage nach der Festlegung einer angemessenen Reichweite unter Berücksichtigung der angestrebten Reaktionsfähigkeit der Unternehmens-IT. Die Reichweite bezieht sich dabei auf die funktionale Abdeckung in Bezug auf Prozess-Cluster und -Gruppen der Geschäftsprozesslandschaft eines Unternehmens. Auf diese Weise wäre es möglich, Data-Warehouse-Systeme unter Berücksichtigung der angestrebten Reaktionsfähigkeit zu planen und zu steuern. Die in der Praxis zu beobachtende Diskrepanz zwischen ursprünglich geplanter und tatsächlich eintretender Reichweite könnte reduziert werden. 6.4 Ausblick Nach MALIK ist unter zwei grundsätzlich vergleichbaren Unternehmen dasjenige das erfolgreichere, das die geringere Komplexität aufweist. Da sich die Komplexität der Unternehmens-IT u.a. in den durch sie erbrachten Integrationsleistungen manifestiert, kann die vorliegende Arbeit als Beitrag verstanden werden, das Verständnis dieses Zusammenhangs aus Sicht der Unternehmens-IT zu verbessern. Nach Erfahrung des Autors der vorliegenden Arbeit ist derzeit zu beobachten, dass sich die für die Unternehmens-IT größerer Unternehmen verantwortlichen Manager dieser Problemstellung in zunehmendem Maße bewusst werden. In verschiedenen Gesprächen des Autors trat dabei die Ratlosigkeit zutage, die Manager in der Unternehmens-IT größerer Unternehmen häufig angesichts der beschriebenen Problematik empfinden. Entsprechend ist zu beobachten, dass Integrationsmanagement und hier insbesondere Komplexitätsmanagement zunehmend an Gewicht gewinnt und die Forderung nach entsprechenden Modellen und Methoden lauter wird. Die vorliegende Arbeit mit dem entwickelten Gesamtsystem von Gestaltungsempfehlungen liefert keine Lösung des Problems. Sie liefert jedoch – wie im Forschungsdesign gefordert – ein Konzept, um die Ziele, Grenzen und Rahmenbedingungen zukünftig vermehrt zu erwartender Initiativen zum Integrations- und Komplexitätsmanagement so zu formulieren, dass die effiziente Erreichung einer aus Sicht des Gesamtunternehmens sinnvollen Zielsetzung unterstützt wird.

Literaturverzeichnis [AdJo98]:

Adam, D.; Johannville, U.: Die Komplexitätsfalle. In: Adam, D. (Hrsg.): Komplexitätsmanagement. Wiesbaden: Gabler, 1998. [AlBeZe09]: Alt, F., Bernet, B.; Zerndt, T.: Transformation von Banken: Praxis des In- und Outsourcings auf dem Weg zur Bank 2015. Berlin: Springer, 2009. [Alaranta05]: Alaranta, M.: Evaluating Success in Post-Merger IS Integration: A Case Study. In: Proceedings of the 12th European Conference on IT Evaluation, 2005. S. 11-20. [Ashby56]: Ashby, W. R.: An Introduction to Cybernetics. New York: Wiley, 1956. [Augustin90]: Augustin, S.: Information als Wettbewerbsfaktor: Informationslogistik – Herausforderungen an das Management. Köln: TÜV Media GmbH, 1990. [Bass98]: Bass, L.; Clements, P.; Kazman, R.: Software Architecture in Practice. Boston: Addison-Wesley, 1998. [Bauer04]: Bauer, T.: Integration heterogener Applikationstypen durch Workflow-Management-Technologie. In: Proc. Workshop on Enterprise Application Integration. S. 39-47. Oldenburg, 2004. [Bauer05]: Bauer, T.: Integration von prozessorientierten Anwendungen. In: Proc. of the 2n GI-Workshop on Enterprise Application Integration. Philipps-Universität Marburg, 2005. S. 66-47. [Becker03]: Becker, J; Holten, R.; Knackstedt, R; Niehaves, B.: Forschungsmethodische Positionierung in der Wirtschaftsinformatik – epistemologische, ontologische und linguistische Leitfragen. Arbeitsberichte des Instituts für Wirtschaftsinformatik. Arbeitsbericht Nr. 93. Westfälische Wilhelms-Universität Münster: Institut für Wirtschaftinformatik, 2003. [Beck05]: Becker, J.; Kugeler, M.; Rosemann, M.: Prozessmanagement. Ein Leitfaden zur prozessorientierten Organisationsgestaltung. 5. Auflage. Berlin Heidelberg: Springer, 2005. [Beer94]: Beer, S.: The Heart of the Enterprise (Managerial Cybernetics of Organization). Neuauflage. Chichester: Whiley and Sons, 1994. [BenPar85]: Benson, J.; Parker; M.: Enterprise-Wide Information Management - An Introduction of the concepts. IBM Los Angeles Scientific Center Reports G320-2768, 1985. G. Dern, Integrationsmanagement in der Unternehmens-IT, DOI 10.1007/978-3-8348-8154-0, © Vieweg+Teubner Verlag | Springer Fachmedien Wiesbaden GmbH 2011

332 [BeRo98]:

[Bertal76]:

[BleWol08] [Bliss00]:

[BöKrc05]:

[Bresch77] [Cassidy98]:

[CoBa09]: [Cock06]:

[DeJu09]:

[DeKe08]:

[Dern07]:

[Dern09]:

Literaturverzeichnis

Becker, J; Rosemann, M.: Informationsmanagement – ein Beitrag zur Beherrschung von Komplexität; in: Adam, D. (Hrsg.): Komplexitätsmanagement. Wiesbaden: Gabler, 1998. Von Bertalanffy, L.: General System Theory: Foundations, Development, Applications. Auflage: REV. New York: George Braziller Inc., 1976. Bleek, W.-G.; Wolf, H.: Agile Softwareentwicklung. Werte, Konzepte und Methoden. Heidelberg: dpunkt.verlag, 2008. Bliss, C.: Management von Komplexität. Ein integrierter systemtheoretischer Ansatz zur Komplexitätsreduktion. Wiesbaden: Gabler, 2000. Böhmann, T.; Krcmar, H.: Zur Anwendbarkeit des industriellen Komplexitätsmanagements auf variantenreiche IT-Dienstleistungen. Proceedings der 7. internationalen Tagung Wirtschaftinformatik. Bamberg 2005. Bresch, C.: Zwischenstufe Leben. Evolution ohne Ziel?. München: Piper, 1977. Cassidy, A.; Guggenberger, K.: A Practical Guide to Information Systems Strategic Planning. Boca Raton: CRC Press - St. Lucie Press, 1998. Leukert, P.: Die Hydra besiegen - Architekturkomplexität erfolgreich managen. Vortrag auf den SOA Days. Bonn 2009. Cockburn, A.: Agile Software Development: The Cooperative Game. 2. Auflage. Amsterdam: Addison-Wesley Longman, 2006. Dern, G; Jung, R.: IT-Architektur-Governance auf Basis von Kennzahlen zur Komplexitätsmessung. In: Zeitschrift Controlling. Ausgabe 12/2009. Dern, G.; Keller, W.: Vorlesung IT Enterprise Architecture vom 24.04.2008. Hasso Plattner Institut Potsdam. Vorlesungsskript unter http://www.hpi.uni-potsdam.de/hirschfeld/teaching/past/ itua08/index.html (Stand: 2009-08-17). Dern, G.: Der IT-Manager. Schriftlicher Lehrgang in 12 Lektionen. Lektion 3. Architekturmanagement. Eschborn: Management Cirle Edition, 2007. Dern, G.: Management von IT-Architekturen. 3., durchgesehene Auflage. Wiesbaden: Vieweg+Teubner, 2009.

Literaturverzeichnis

[Durst07]: [Fent94]

[FerSin01]: [Fischer08]: [Frank06]:

[Forr72]: [Fow03]: [Glöckle07]

[Haeckel99]:

[Harris10]

[Hars02]:

[Hayek67]: [HeIsSh03]: [Heindl10]:

333 Durst, M.: Wertorientiertes Management von IT-Architekturen. Wiesbaden: Deutscher Universitäts-Verlag, 2007. Fenton, N.: Software Measurement: A Necessary Scientific Basis. In: IEEE Transactions on Software Engineering. 20(3). March 1994. S. 199–206. Ferstl, O. K.; Sinz, E. J.: Grundlagen der Wirtschaftsinformatik. Band 1. 4. Auflage. München Wien: Oldenbourg, 2001. Fischer, R.: Organisation der Unternehmensarchitektur. Hamburg: Dr. Kovac, 2008. Frank, U.: Towards a Pluralistic Conception of Research Methods in Information Systems Research. ICB-Research Report No. 7. Institut für Informatik und Wirtschaftinformatik (ICB). Universität Duisburg-Essen 2006. Forrester, J. W.: Grundzüge der Systemtheorie. Wiesbaden: Gabler,1972. Fowler, M.: Patterns of Enterprise Application Architecture. Boston: Addison-Wesley Longman, 2002. Glöckle, H. H. R.: IT-Integration und Migration - Konzepte und Vorgehensweisen. In: HMD Praxis der Wirtschaftsinformatik. Heft 257. 2007. S. 7-19. Haeckel, S. H.: Adaptive Enterprise. Creating and Leading Sense-And-Response Organizations. Boston: Harvard Business School Press, 1999. Harris, K.: Gartner CEO and Senior Business Executive Survey, 2010: Perceptions of IT and Tactical Fixes. ID Number: G00174491. Gartner, Inc. 2010. Hars, A.: Wissenschaftstheorie für Wirtschaftsinformatiker. Tutorial im Rahmen der Multikonferenz Wirtschaftsinformatik 2002. 9.-11. September 2002. Hayek, F. von: Studies in Philosophy, Politics and Economics. Chicago: 1967. Heap, S.; Israelit, S.; Shpilberg, D.: The hidden IT multiplier in mergers. Financial Times 14.02.2003. Heindl, C.: Identifikation, Quantifizierung und Visualisierung von Komplexitätsmerkmalen einer Unternehmensarchitektur. Diplomarbeit der Fakultät für Informatik der technischen Universität München. 2010.

334 [HMPR04]:

Literaturverzeichnis

Hevner, A. R.; March, S. T.; Park, J., Ram, S.: Design Science in Information Systems research. In: MIS Quarterly 28. 2004. S.76105. [Horv94]: Horváth, P.: Controlling. 5. Auflage. München: Vahlen,1994. [HoWo03]: Hohpe, G; Woolf, B.: Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Boston et al.. Addison-Wesley, 2003. [Inmon05]: Inmon, W.H.; Imhoff, C.; Battas, G.: Building the Data Warehouse. 4. Auflage. New York: John Wiley & Sons, 2005. [Jung00]: Jung, R.; Winter, R. (Hrsg.): Data Warehousing Strategie - Erfahrungen, Methoden, Visionen. Berlin et al.: Springer 2000. [Jung06]: Jung, R.: Architekturen zur Datenintegration: Gestaltungsempfehlungen auf der Basis fachkonzeptueller Anforderungen (Habilitation). Wiesbaden: Deutscher Universitätsverlag, 2006. [KaÖst07]: Kagermann, H.; Österle, H.: Geschäftsmodelle 2010: Wie CEOs Unternehmen transformieren. 2., aktualisierte Auflage. Frankfurt: Frankfurter Allgemeine Buch, 2007. [Keller02]: Keller, W.: Enterprise Application Integration. Heidelberg: dpunkt.verlag, 2002. [Keller07]: Keller, W.: IT-Unternehmensarchitektur: Von der Geschäftsstrategie zur optimalen IT-Unterstützung. Heidelberg: dpunkt.verlag, 2007. [Kimb08]: Ralph, R.; Ross, M.; Thornthwaite, W.; Mundy, J.; Becker, B.: The Data Warehouse Lifecycle Toolkit. 2. Auflage. New York et al.: John Wiley & Sons, 2008. [KleKo09] Kleiner, C.; Koschel, A.: Praxisfallbeispiel: Modernisierung einer Mainframe-Anwendung durch eine verteilte SOA. Electronic Communications of the EASST. Volume 17: Kommunikation in Verteilten Systemen, 2009. Volltext unter http://journal.ub.tu-berlin.de/index.php/eceasst/article/view/203 (Stand: 2009-07-06). [Krcmar05]: Krcmar, H.: Informationsmanagement. 4. Auflage. Berlin et al.: Springer, 2005. [Krupinski05]: Krupinski, A.: Unternehmens-IT für Banken. Wiesbaden: Vieweg, 2005.

Literaturverzeichnis

[Langn07]:

335

Langner, T.: IT-Infrastrukturmanagement bei Banken und Versicherungen: Ein modellbasierter Ansatz zur Lösung komplexitätsbedingter Entscheidungsprobleme des Architekturmanagements im Bereich der IT-Infrastruktur. Saarbrücken: Vdm Verlag Dr. Müller, 2008. [LanWeg04]: Langenberg, K.; Wegmann, A.: Enterprise Architecture: What Aspects is Current Research Targeting. EPFL Technical Report IC/2004/77. Ecole Polytechnique Fédérale de Lausanne. 2004 [Lapkin06]: Lapkin, A.: Gartner Defines the Term Enterprise Architecture. Gartner Group Research. 2006. [Leist02]: Leist, S.; Winter, R. (Hrsg.): Retail Banking im Informationszeitalter. Berlin et al.: Springer, 2002. [Linth03]: Linthicum, D. S.: Next Generation Application Integration: From Simple Information to Web Services. Amsterdam. Addison-Wesley, 2003. [Malik04]: Malik, F.: Systemisches Management, Evolution, Selbstorganisation: Grundprobleme, Funktionsmechanismen und Lösungsansätze für komplexe Systeme. 4. Auflage. Bern et al.: Paul Haupt, 2004. [Malik08]: Malik, F.: Strategie des Managements komplexer Systeme: Ein Beitrag zur Management-Kybernetik evolutionärer Systeme. 10. Auflage. Bern et al.: Paul Haupt, 2008. [MaRo04]: Iansiti, M.; Levien, R.: The Keystone Advantage: What the New Dynamics of Business Ecosystems Mean for Strategy, Innovation and Sustainabity. Boston: Havard Business School Press, 2004. [Marty02]: Marty, R.: IT Kostenmanagement in Banken. Euroforum Konferenz. 9./10. April 2002. [Meff00]: Meffert, H.: Marketing: Grundlagen markorientierter Unternehmensführung. 9. Auflage. Wiesbaden: Gabler, 2000. [Mertens05]: Mertens, P.: Integrierte Informationsverarbeitung 15., über. Auflage. Wiesbaden: Gabler, 2005. [Mor99]: Morabito, J.: Organization Modeling. Upper Saddle River: Prentice Hall, 1999. [META02-1]: META Group Best-Practice Konferenz, Optimierung der Zukunft – das Projekt-Portfolio. Meta Group. 2002.

336

Literaturverzeichnis

[META02-2]: The Business of IT Portfolio Management: Balancing Risk, Innovation and ROI, A Meta Group White Paper. META Group 2002. [MiBu07]: Miklitz, T; Buxmann, P.: IT standardization and integration in mergers and acquisitions: a decision model for the selection of application systems. In Hubert Österle, Joachim Schelp und Robert Winter, (Hrsg.). Proceedings of the 15th European Conference on Information Systems (ECIS 2007) St.Gallen, 2007. S. 1041–1051. [Naur91]: Naur, P.: Computing: A Human Activity. New York: AddisonWesley, 1991. [Niemann05]: Niemann, K.: Von der Unternehmensarchitektur zur ITGovernance. Bausteine für ein wirksames IT-Management. Wiesbaden: Vieweg, 2005. [Öster87] : Österle, H.: Erfolgsfaktor Informatik: Umsetzung der Informationstechnik in der Unternehmensführung. In: Information Management, Vol. 2, Nr. 3, S. 24-31, 1987. [ÖstWiBa03]: Österle, H; Winter, R.; Baumöl, U.: Business Engineering: Auf dem Weg zum Unternehmen des Informationszeitalters. 2. Auflage. Berlin: Springer, 2003. [PeJüSa92]: Peitgen, H.-O.; Jürgens, H.; Saupe, D.: Fractals for the Class Room: Part One, Introduction to Fractals and Chaos. New York: Springer, 1992. [Piller00]: Piller, F.T.: Mass Customization. Ein wettbewerbsstrategisches Konzept im Informationszeitalter. Wiesbaden: Gabler, 2000. [Probst87]: Probst, G.: Selbstorganisation - Ordnungsprozesse in sozialen Systemen aus ganzheitlicher Sicht. Berlin Hamburg: Paul Parey, 1987. [Qusar08]: Engels, G.; Hess, A.; Humm, B.; Juwig, O.; Lohmann, M; Richter, J.; Voß, M; Willkomm; J.: Quasar Enterprise: Anwendungslandschaften. Heidelberg: dpunkt.verlag, 2008. [Raman05]: Ramanathan, J.: Fractal architecture for the adaptive complex enterprise. Communication of the ACM. Vol. 48, No. 5. May 2005. [Scheer1999]: Scheer, A.-W.: ARIS. Vom Geschäftsprozeß zum Anwendungssystem. Berlin et al.: Springer, 1999.

Literaturverzeichnis

337

[ScheSchw05]: Schelp, J.; Schwinn, A.: Extending the Business Engineering Framework for Application Integration Purposes. ACM Symposium om Applied Computing. 2005. [ScheWin06]: Schelp, J.; Winter, R. (Herausgeber): Integrationsmanagement: Planung, Bewertung und Steuerung von Applikationslandschaften. Berlin et al.: Springer, 2006. [Schme06]: Schmelzer, H.J.; Sesselmann, W.: Geschäftsprozessmanagement in der Praxis. 5. Auflage. München: Hanser, 2006. [Schulte05]: Schulte-Zurhausen, M.: Organisation. 4. Auflage. München: Vahlen, 2005. [SchuRoy05]: Schulte, R. W.: Clarifying the Terms 'Event-Driven' and 'Service-Oriented Architecture'. Gartner Group Research. 2005. [Schwinn06]: Schwinn, A.: Entwicklung einer Methode zur Gestaltung von Integrationsarchitekturen für Informationssysteme. Bamberg: Difo-Druck, 2006. [ScoVes02]: Scott, J.E.; Vessey, I.: Managing Risks in Enterprise Systems Integration. Commun. ACM 45, 4 (April 2002), 74-81. [Sebis08]: Matthes, F.; Buckl, S.; Leitel, J.; Schweda, C. M.: Enterprise Architecture Management Tool Survey 2008. Technische Universität München. 2008. [SenÖst04]: Senger, Enrico ; Österle, Hubert: PROMET Business Engineering Case Studies (BECS) Version 2.0. St. Gallen: Institut für Wirtschaftsinformatik, Universität St. Gallen, 2004 – Volltext unter http://www.alexandria.unisg.ch/Publikationen/23020 (Stand: 2009-12-12). [Sessions08]: Sessions, R.: Simple Architectures for Complex Enterprises. Washington: Microsoft Press, 2008. [Simpson07]: Simpson, R.: Case Study: Wireless Broadband Enables StraightProcessing for Mobile Insurance Agents. Gartner Group Research. 2007. [Shore06]: Shore, B.: Enterprise Integration Across the Globally Disbursed Service Organization. Communications for the ACM. June 2006/Vol 49. No. 6. [Starke05]: Starke, G.: Effektive Softwarearchitekturen. Ein praktischer Leitfaden. München et al.: Hanser, 2005. [SteiSchre00]: Steinmann, H.; Schreyögg, G.: Management. Grundlagen der Unternehmensführung. Wiesbaden: Gabler, 2000.

338 [SzyEsch83]:

[Ulrich70]: [vdPols07]: [WaPe02]: [Wiecz04]: [WiHe06]:

[WKWI94]:

[Worthen02]:

Literaturverzeichnis

Szyperski, N., Eschenröder, G.: Information-RessourceManagement. in: Kay, R.: Management betrieblicher Informationsverarbeitung. München: Oldenbourg, 1983. Ulrich, H.: Die Unternehmung als produktives soziales System. 2. Auflage. Bern et al.: Haupt, 1970. van der Pols, R.: ASL – Ein Framework für das Application Management. Zaltbommel: Van Haren Publishing, 2007. Ward, J.; Peppard, J.: Strategic Planning for Information Systems. Third Edition. Chichester: Whiley and Suns, 2002. Wieczorrek, H. W.: Management von IT-Projekten. Von der Planung zur Realisierung. Berlin: Springer, 2004. Wilde, T; Hess, T.: Methodenspektrum der Wirtschaftsinformatik. Überblick und Portfoliobildung. Arbeitsbericht Nr. 02/2006. Institut für Wirtschaftsinformatik und Neue Medien. LudwigMaximilians-Universität München. 2006. Wissenschaftliche Kommission Wirtschaftsinformatik (WKWI): Profil der Wirtschaftinformatik. In: Wirtschaftsinformatik 34 (1994). S. 80f. Worthen, B.: Nestle’s ERP odyssey. CIO (May 15, 2002). www.cio.com/archive/051502/nestle.html.