Schelp / Winter Auf dem Weg zur Integration Factory

Proceedings der DW2004 - Data Warehousing und EAI
1. Auflage 2005
ISBN: 978-3-7908-1612-9
Verlag: Physica-Verlag HD
Format: PDF
Kopierschutz: 1 - PDF Watermark

E-Book, Deutsch, 508 Seiten

Das Buch Auf dem Weg zur Integration Factory fasst den State of the Art sowie die Zukunftsperspektiven im Bereich der integrierten Informationslogistik zusammen. Die Autoren untersuchen zum einen, inwieweit sich bisherige Ansätze zum Data Warehousing sowie zur Enterprise Application Integration mittelfristig technisch, organisatorisch und wirtschaftlich als geeignete Lösungen erwiesen haben. Die Kernthemen sind hierbei Architekturen, Vorgehensmodelle, Business Intelligence, Online-Analyse, Customer Relationship Management, Supply Chain Management und Anwendungsintegration. Zum anderen werden neuere Ansätze vorgestellt, welche die Integration des Data Warehouse in die Gesamt-Informationslogistik zum Ziel haben und so die Realisierung neuer Applikationstypen und Geschäftsmodelle ermöglichen. Darüber hinaus wird insbesondere auf eine Verbesserung der Prozessunterstützung durch einen höheren Integrationsgrad der Applikationen eingegangen. Das Buch wendet sich vorwiegend an Praktiker aus den Bereichen Betriebswirtschaft und Wirtschaftsinformatik.

Autoren/Hrsg.

Schelp, Joachim

Winter, Robert

Inhaltsverzeichnis

1;Vorwort und Einführung;6
2;Inhaltsverzeichnis;10
3;Modelle für Semantische Web-Anwendungen ;13
4;Strategische Fragen der integrierten Informationslogistik;33
4.1;Integration des Prozessmanagements in eine zukunftsorientierte CIO- Organisation am Beispiel von Siemens ICN;35
4.1.1;1 Einleitung;35
4.1.1.1;1.1 Motivation;36
4.1.1.2;1.2 Zielsetzung;37
4.1.1.3;1.3 Aufbau des Beitrags;37
4.1.2;2 Entwicklung des Prozessmanagements bei Siemens ICN;38
4.1.3;3 Methodenelemente des Prozessmanagements bei Siemens ICN;39
4.1.3.1;3.1 Zielsetzung des Prozessmanagements;39
4.1.3.2;3.2 Einheitliche Prozessdokumentation;40
4.1.3.3;3.3 Einheitliche Prozessoptimierung;42
4.1.3.4;3.4 Zentrales Prozesscontrolling;43
4.1.3.5;3.5 Organisation des Prozessmanagements;43
4.1.3.6;3.6 Koordination des Prozessmanagements;47
4.1.4;4 Lessons Learned;48
4.1.4.1;4.1 Nutzen der Integration von Prozess- und IT-Management;48
4.1.4.2;4.2 Erfolgsfaktoren eines integrierten, serviceorientierten Prozess- und IT- Managements;49
4.1.5;5 Zusammenfassung und Ausblick;49
4.1.6;6 Literatur;50
4.2;EAI und Nachhaltigkeit von Architekturen – Ergebnisse einer empirischen Studie;53
4.2.1;1 Ausgangssituation;53
4.2.2;2 Rolle von EAI in der Unternehmensarchitektur;54
4.2.3;3 Begriff der Nachhaltigkeit;56
4.2.3.1;3.1 Definitionen des Nachhaltigkeitsbegriffs;56
4.2.3.2;3.2 Nachhaltigkeitsbegriff der Wirtschaftsinformatik;57
4.2.3.3;3.3 Nachhaltigkeitsstrategien;58
4.2.4;4 EAI-Architekturen – Empirische Ergebnisse;62
4.2.4.1;4.1 Einschätzung der Dauerhaftigkeit der Architekturen;63
4.2.4.2;4.2 Einschätzung der Leistungsfähigkeit der Architekturen;63
4.2.4.3;4.3 Strategien der Architekturgestaltung;65
4.2.5;5 Bedrohungen der Nachhaltigkeit;66
4.2.6;6 Zusammenfassung;67
4.2.7;7 Literatur;68
4.3;Die Wertschöpfung des Metadatenmanagements für Unternehmen der Finanzindustrie;71
4.3.1;1 Einleitung;71
4.3.2;2 Strukturelle Eigenschaften des Metadatenmanagements;72
4.3.2.1;2.1 Handhabung von Anpassungsleistungen;73
4.3.2.2;2.2 Alternative Mechanismen und Zielkonflikte;73
4.3.3;3 Strukturelle Eigenschaften der Finanzindustrie;74
4.3.3.1;3.1 Kleinkundengeschäft bei Banken;75
4.3.3.2;3.2 Nichtlebengeschäft in der Rückversicherung;77
4.3.4;4 Wertschöpfungspotenziale;78
4.3.4.1;4.1 Auslagerung von IT-Dienstleistungen im Bankenumfeld;78
4.3.4.2;4.2 Produktkombination;79
4.3.4.3;4.3 Neue regulatorische Anforderungen (Sarbanes-Oxley-Act, Basel II);79
4.3.5;5 Erfahrungen;80
4.3.6;6 Zusammenfassung;81
4.3.6.1;6.1 Wann Metadatenmanagement (keinen) Sinn macht;81
4.3.6.2;6.2 Ausblick;82
4.3.7;7 Literatur;83
4.4;Outsourcing und Offshoring von Business Intelligence- Lösungen – Empirische Studien und Praxiserfahrung;85
4.4.1;1 Einleitung und Überblick;86
4.4.2;2 Business Intelligence als komplexes „Ökosystem“ aus Strategien, Rollen, Funktionen, Prozessen und Technik;88
4.4.2.1;2.1 Historie und aktuelle Entwicklung;88
4.4.2.2;2.2 Reifegradmodelle von IT-Lösungen und ITOrganisationen – insbes. BI- Lösungen;89
4.4.2.3;2.3 Das BI Maturity Model biMM;92
4.4.2.4;2.4 Das Business Intelligence Maturity Audit biMA®;95
4.4.3;3 Outsourcing: Onshore/Nearshore/Offshore;97
4.4.3.1;3.1 Geschäftsmodelle und Service Locations beim Outsourcing;97
4.4.3.2;3.2 Erwartungen an das Outsourcing und Erfahrungen aus durchgeführten Projekten;100
4.4.3.3;3.3 Funktionale Inhalte des Outsourcing/Application Management;102
4.4.3.4;3.4 Stand des BI-Outsourcing in Deutschland;104
4.4.3.5;3.5 Allgemeine Risiken im Outsourcing;104
4.4.3.6;3.6 Spezifische Risiken beim BI-Outsourcing;106
4.4.3.7;3.7 Abgrenzung von Outsourcing zu Application Service Providing ( ASP);108
4.4.4;4 Vorgehen beim BI-Outsourcing;109
4.4.4.1;4.1 Festlegen des Aufgabenbereichs für das BI-Outsourcing: „ Was soll das Outsourcing inhaltlich umfassen?“;109
4.4.4.2;4.2 Prüfung des Reifegrades der BI-Komponenten: „ Welche Anwendungen können im Outsourcing betreut werden?“;110
4.4.4.3;4.3 Vereinbarung eines Geschäfts- und Governance-Modells: „ Wie soll das Outsourcing durchgeführt werden?“;112
4.4.4.4;4.4 Durchführung eines BI-Outsourcing-Projekts;113
4.4.4.5;4.5 Chancen-/Risiken-Bewertung eines BI-Outsourcing;116
4.4.5;5 Literaturverzeichnis;117
4.4.6;6 Weiterführende Literatur;117
5;Ausgewählte Gestaltungsaspekte der integrierten Informationslogistik;119
5.1;Die Gestaltung einer unternehmensweiten, flexiblen Software- Architektur auf Basis eines selbst entwickelten Zonen- und Schichten- Modells;121
5.1.1;1 Einleitung;121
5.1.2;2 Das Vorgehensmodell;122
5.1.3;3 Die Daten-Architektur;124
5.1.4;4 Die Anwendungs-Architektur;127
5.1.4.1;4.1 Das „3-Dimensional Architectural Framework“;128
5.1.4.2;4.2 Das Zonen- und Schichten-Modell, der Bauplan zur Wiederverwendung;129
5.1.4.3;4.3 Die Schichten des ZSM;130
5.1.4.4;4.4 Die Zonen des ZSM;130
5.1.4.5;4.5 Die Umgebungen des ZSM;137
5.1.4.6;4.6 Ein Beispiel für die praktische Anwendung des ZSM;138
5.1.4.7;4.7 ZSM und Data Warehouse;139
5.1.5;5 Zusammenfassung und Ausblick;140
5.1.6;6 Literatur;141
5.2;Entwurfsmuster für die Applikationsintegration;143
5.2.1;1 Einleitung;143
5.2.2;2 Grundlagen;144
5.2.3;3 Vorhandene Entwurfsmusteransätze;146
5.2.3.1;3.1 Entwurfsmuster von Gamma et al.;146
5.2.3.2;3.2 Patterns for e-Business;149
5.2.3.3;3.3 EAI-Architekturmuster nach Lutz;155
5.2.4;4 Entwicklung von Integrationsarchitekturmustern;157
5.2.4.1;4.1 Muster vom Typ Informationsbedarf;158
5.2.4.2;4.2 Muster vom Typ Verarbeitungsauftrag;160
5.2.5;5 Zusammenfassung;163
5.2.6;6 Literatur;163
5.3;Twelve Mistakes to Avoid When Constructing a Real- Time Data Warehouse;165
5.3.1;1 Introduction;165
5.3.2;2 Mistake #1: Focusing on “Real” Time Rather than “ Right” Time;165
5.3.3;3 Mistake #2: Confusion between Bookkeeping, Decision Making, and Action Taking;166
5.3.4;4 Mistake #3: Using Legacy ETL Infrastructure;168
5.3.5;5 Mistake #4: Too Much Summary Data;169
5.3.6;6 Mistake #5: Lack of High Availability;170
5.3.7;7 Mistake #6: Failure to Initiate Business Process Changes;170
5.3.8;8 Mistake #7: Separate ODS Deployment per Channel;171
5.3.9;9 Mistake #8: Under Estimating the Importance of Historical Data;173
5.3.10;10 Mistake #9: Failure to Integrate the Data;174
5.3.11;11 Mistake #10: Assume that all Knowledge Workers want Real- time Data;175
5.3.12;12 Mistake #11: Big Bang Approach to Implementation;175
5.3.13;13 Mistake #12: Implementation of a Non-Scalable Solution;176
5.3.14;14 Conclusions;177
5.3.15;15 References;177
5.4;Anforderungsmanagement bei der Entwicklung von Data Warehouse- Systemen – Ein sichtenspezifischer Ansatz;179
5.4.1;1 Einleitung;179
5.4.2;2 Anforderungen an das Anforderungsmanagement;180
5.4.2.1;2.1 Erweiterter Anforderungsbegriff;180
5.4.2.2;2.2 Empfängerorientierung und Traceability;182
5.4.3;3 Anforderungsmanagement für Data-Warehouse- Systeme auf Grundlage der Viewpoint- Methode;183
5.4.3.1;3.1 Grundlagen und Vorgehen;183
5.4.3.2;3.2 Identifikation relevanter Viewpoints;184
5.4.3.3;3.3 Dokumentation der Viewpoint Requirements;185
5.4.3.4;3.4 Analyse und Spezifikation der Anforderungen;190
5.4.4;4 Implementierung;192
5.4.5;5 Fazit und Ausblick;194
5.4.6;6 Literatur;195
5.5;Lösungsansätze aus Data Warehouse-Projekten;199
5.5.1;1 Einleitung;199
5.5.2;2 Den ETL-Prozess gestalten;200
5.5.2.1;2.1 Dummy-Referenzen einfügen;201
5.5.2.2;2.2 Dublettenbehandlung;202
5.5.2.3;2.3 Historie aufbauen;204
5.5.3;3 Daten aufbereiten;206
5.5.3.1;3.1 Entdecken von schlechter Datenqualität;207
5.5.3.2;3.2 Auffüllen leerer Datenfelder;210
5.5.3.3;3.3 Data Marts für Data Mining und Kampagnen;211
5.5.3.4;3.4 Inkrementelle Aggregate;212
5.5.4;4 Daten nutzen;214
5.5.5;5 Literatur;216
5.6;XML-Einsatz in Business-Intelligence-Systemen – Eine systematische Übersicht;217
5.6.1;1 Nutzen des XML-Einsatzes in Business-Intelligence- Systemen;217
5.6.2;2 XML Standards;219
5.6.2.1;2.1 Core-Standards;220
5.6.2.2;2.2 Spezielle XML-Definitionen für Business-Intelligence- Systeme;222
5.6.3;3 Einsatzbereiche der XML-Standards in BISystemen;228
5.6.3.1;3.1 Datenintegration;229
5.6.3.2;3.2 Datenmodellierung;231
5.6.3.3;3.3 Nutzdaten-Speicherung;232
5.6.3.4;3.4 Metadatenverwaltung;233
5.6.3.5;3.5 Abfrage, Analyse und Präsentation;233
5.6.3.6;3.6 Anwendungskonfiguration;234
5.6.4;4 Fazit;234
5.6.5;5 Literatur;236
6;Neue Umsetzungsszenarien integrierter Informationslogistik;241
6.1;XML-Datenimport in das SAP Business Information Warehouse bei Bayer MaterialScience;243
6.1.1;1 Einleitung;243
6.1.2;2 XML-Datenimport im SAP Business Information Warehouse;245
6.1.2.1;2.1 Architektur des Business Information Warehouse;246
6.1.2.2;2.2 XML, SOAP und Webservices;248
6.1.2.3;2.3 Bedeutung des Einsatzes von XML in ETL-Prozessen mit dem Business Information Warehouse;250
6.1.3;3 Traditionelles Host basiertes Verfahren der Datenbereitstellung für SAP BW bei Bayer MaterialScience;252
6.1.4;4 Neues Datenimportverfahren auf Basis von XML und SOAP;254
6.1.4.1;4.1 Darstellung des Verfahrens in der Übersicht;255
6.1.4.2;4.2 Versand von XML-Datenpaketen;256
6.1.4.3;4.3 Verwaltung der per XML gelieferten Datenpakete in einer Web- Applikation;258
6.1.4.4;4.4 Implementierung des Datenflusses im BW;260
6.1.5;5 Ausblick;262
6.1.6;6 Literatur;262
6.2;OLAP-Techniken aus Sicht der industriellen Auftragsabwicklung;265
6.2.1;1 Einleitung;265
6.2.2;2 Verwandte Arbeiten;267
6.2.3;3 Domänenspezifische OLAP-Erweiterungen;269
6.2.3.1;3.1 Unvollständige Zuordnungen zu Dimensionsstufen;270
6.2.3.2;3.2 Nicht eindeutige Aggregationszuordnungen zwischen Bezugsobjekten;272
6.2.3.3;3.3 Rekursive Datenstrukturen der Anwendungssysteme;274
6.2.3.4;3.4 Typisierung von Dimensionsstrukturen;277
6.2.3.5;3.5 Integrierte Auswertung aktueller und historisierter Daten;279
6.2.4;4 Fazit;283
6.2.5;5 Literatur;284
6.3;Extending the Data Warehouse with Company External Data from Competitors' Websites – A Case Study in the Banking Sector;289
6.3.1;1 Motivation;289
6.3.2;2 Company External Data;291
6.3.3;3 LIXTO;292
6.3.4;4 Case Study: Extracting Competitors Web Data;293
6.3.4.1;4.1 The Organisation: An Online Bank;293
6.3.4.2;4.2 Architecture;294
6.3.4.3;4.3 Data Discovery;294
6.3.4.4;4.4 Data Acquisition;297
6.3.4.5;4.5 Data Structuring and Data Integration;298
6.3.5;5 Case Study: Data Analysis;299
6.3.5.1;5.1 Data Model;299
6.3.5.2;5.2 Business Questions;300
6.3.6;6 Related Work;303
6.3.7;7 Conclusion;304
6.3.8;8 Acknowledgement;304
6.3.9;9 References;305
6.4;Data Distribution with a Market Data Information System;307
6.4.1;1 Introduction;307
6.4.2;2 Conceptual framework;308
6.4.2.1;2.1 Data Warehouse concept;308
6.4.2.2;2.2 Modelling the Data-Warehouse-schema;309
6.4.2.3;2.3 Information retrieval process;310
6.4.3;3 Method;312
6.4.3.1;3.1 Descriptor definition;312
6.4.3.2;3.2 Filtering process;312
6.4.3.3;3.3 Visualization;313
6.4.4;4 Designing the data model for a distributed MAIS database;315
6.4.4.1;4.1 Distributed data sandbox model;315
6.4.4.2;4.2 Replication using streams;317
6.4.4.3;4.3 Replication using materialized views;318
6.4.4.4;4.4 Distributing the import procedure using synonyms;319
6.4.5;5 Conclusion;320
6.4.6;6 References;321
6.5;Einsatz von Peer-to-Peer-Technologie zur betriebswirtschaftlichen und informationstechnischen Unterstützung von EAI- Projekten;323
6.5.1;1 Einleitung;323
6.5.2;2 Unzulänglichkeiten klassischer EAI-Ansätze;325
6.5.2.1;2.1 Umsetzung betriebswirtschaftlicher Anforderungen;325
6.5.2.2;2.2 Technische Probleme;326
6.5.3;3 EAI mit Peer-to-Peer basierter Technologie;328
6.5.3.1;3.1 Bestehende Peer-to-Peer Anwendungen;328
6.5.3.2;3.2 Nutzenpotenziale von Peer-to-Peer zur Integration;329
6.5.3.3;3.3 Peer-to-Peer Integrationsansatz;331
6.5.4;4 Fazit;335
6.5.5;5 Literatur;336
7;Prozessintegration in der Praxis;339
7.1;Integrating Management Views in Supply Chain Environments – An arvato ( Bertelsmann) Business Case;341
7.1.1;1 Introduction;341
7.1.2;2 Advantage by Service;342
7.1.3;3 Order Fulfilment and Customer Service at arvato;344
7.1.3.1;3.1 Order Fulfilment Process;344
7.1.3.2;3.2 Customer Service Process;345
7.1.4;4 Technical Integration Architecture;346
7.1.4.1;4.1 Initial IT Infrastructure;346
7.1.5;5 Conceptual Supply Chain Integration;349
7.1.5.1;5.1 Value of Information;349
7.1.5.2;5.2 Management View Master Data;354
7.1.5.3;5.3 Sales Organization Key Accounting;358
7.1.5.4;5.4 Aggregated Key Accounting;360
7.1.6;6 Discussion and Outlook;361
7.1.7;7 References;362
7.2;Integrierte Prozesse mit Prozessportalen;365
7.2.1;1 Herausforderung der Netzwerkökonomie;365
7.2.2;2 Prozessportale als Basis für Integration;367
7.2.2.1;2.1 Management;368
7.2.2.2;2.2 Fachabteilung;368
7.2.2.3;2.3 IT-Spezialisten;368
7.2.3;3 Integrierte Geschäftsprozessarchitektur mit Prozessportalen und EAI Software;370
7.2.3.1;3.1 Process Design;371
7.2.3.2;3.2 Process Execution;371
7.2.3.3;3.3 Process Controlling;372
7.2.4;4 Das Beispiel DaimlerChrysler Bank;373
7.2.5;5 Nutzen des Prozessmanagements mit Prozessportalen;375
7.3;Planung und Einsatz von EAI am Beispiel eines Projekts in der Wertpapierabwicklung einer Geschäftsbank;377
7.3.1;1 Einleitung;377
7.3.2;2 Strategische Überlegungen;378
7.3.2.1;2.1 Geschäftspolitische Ziele;378
7.3.2.2;2.2 Vorgaben für die Lösung;379
7.3.3;3 Projekt;379
7.3.3.1;3.1 Einleitung;379
7.3.3.2;3.2 Prozess der Wertpapierabwicklung;380
7.3.3.3;3.3 Bestandsaufnahme;381
7.3.3.4;3.4 Zielarchitektur;383
7.3.4;4 Lessons Learned;385
7.3.4.1;4.1 Einbindung der Fachbereiche;385
7.3.4.2;4.2 Planung eines erhöhten Koordinationsaufwands;385
7.3.4.3;4.3 Einführung eines systemübergreifenden Entwicklungsprozesses;386
7.3.4.4;4.4 Einführung eines systemübergreifenden Betriebs;386
7.3.4.5;4.5 Festlegung einer anwendungsübergreifenden Fehlerbehandlung;386
7.3.4.6;4.6 Festlegung des Änderungsmanagements;387
7.3.4.7;4.7 Vorgabe: EAI-Komponenten ohne Anwendungslogik;387
7.3.5;5 Literatur;387
7.4;DWH und EAI im Integration Layer der Bank Julius Bär – Architektur, Anwendungen und Erfahrungen;389
7.4.1;1 Einleitung;389
7.4.2;2 Anforderungen;390
7.4.2.1;2.1 Die bankfachlichen Anforderungen;390
7.4.2.2;2.2 Spezifische DWH-Anforderungen;390
7.4.2.3;2.3 Spezifische EAI-Anforderungen;391
7.4.2.4;2.4 Wichtige IT-interne Motive;392
7.4.3;3 Architektur;392
7.4.3.1;3.1 Der funktionale Aspekt;393
7.4.3.2;3.2 Der technische Aspekt;396
7.4.3.3;3.3 Die Datawarehousing-Architektur;398
7.4.3.4;3.4 Die Architektur des operational Datastore;403
7.4.3.5;3.5 Das Zusammenspiel von DWH und EAI;404
7.4.3.6;3.6 Die eingesetzten Werkzeuge;404
7.4.4;4 Anwendungen;405
7.4.4.1;4.1 Data Integration and Warehousing;405
7.4.4.2;4.2 Applikations-Integration;406
7.4.4.3;4.3 Leistungsdaten;407
7.4.5;5 Erfahrungen;408
7.4.6;6 Ausblick;408
7.4.7;7 Literatur;409
8;Data Warehousing in der Praxis;411
8.1;Einsatz eines Data Warehouse im eGovernment- Bereich zur Asylsteuerung und Migrationsanalyse;413
8.1.1;1 Einleitung;413
8.1.2;2 Anforderungen an ein Data Warehouse aus Sicht des Geschäftsprozesses Asyl;414
8.1.3;3 Modellierungsebenen im Asylprozess;418
8.1.4;4 Vorgehensweise;422
8.1.5;5 Architektur und Werkzeugunterstützung;424
8.1.6;6 Weitere Schritte und Ausblick;427
8.1.7;7 Literatur;429
8.2;Analyse eines SAP BW-Einsatzes im Controlling am Beispiel der T- Com;431
8.2.1;1 Data Warehousing im Controlling der T-Com und Ansatz der Analyse;432
8.2.2;2 Vorgehensmodell zur Analyse bestehender Data Warehouse- Systeme;434
8.2.3;3 Analyse des CON BW;440
8.2.4;4 Entwicklung von Handlungsempfehlungen;442
8.2.5;5 Zusammenfassung und Ausblick;446
8.2.6;6 Literatur;447
8.3;Customer Investigation Process at Credit Suisse: Meeting the Rising Demand of Regulators;449
8.3.1;1 Introduction;449
8.3.2;2 Information Quality Framework;451
8.3.3;3 The Original Customer Investigation Process;453
8.3.3.1;3.1 Activities and Workflow;453
8.3.3.2;3.2 Analysis of Information Quality Issues;455
8.3.4;4 The Revised Process—Automated by an Information System;458
8.3.4.1;4.1 Workflow of the Revised Process;459
8.3.4.2;4.2 The Investigation Application—An Information System supporting the Investigation Process;460
8.3.4.3;4.3 Assessment of the Impact of the Revision on Information Quality;466
8.3.5;5 Conclusion and Experiences;468
8.3.6;6 References;469
8.4;Integrationsbedarf einer bankspezifischen Deckungsbeitragsrechnung;471
8.4.1;1 Einleitung;471
8.4.2;2 Grundlagen der Untersuchung;473
8.4.2.1;2.1 Die Bankkalkulation in der Literatur;473
8.4.2.2;2.2 Ist-Situation bei der HVB Luxembourg;475
8.4.2.3;2.3 Zielsetzung der HVB Luxembourg;476
8.4.3;3 Soll-Konzeption;478
8.4.3.1;3.1 Lösungsansatz Prozesskostenrechnung;478
8.4.3.2;3.2 Systemische Integration;482
8.4.3.3;3.3 Integration in den Controlling-Zyklus;485
8.4.4;4 Fazit;487
8.4.5;5 Literatur;488
8.5;Analytisches Investor Relationship Management – Ein innovatives Anwendungsfeld für Data Mining Technologien untersucht am Beispiel der AMP Ltd.;491
8.5.1;1 Einführung;491
8.5.1.1;1.1 Problemstellung – Vom Customer zum Investor Relationship Management;491
8.5.1.2;1.2 Stand der Forschung und Zielsetzung;492
8.5.1.3;1.3 Methodik und Aufbau des Beitrages;493
8.5.2;2 Grundlage der Analyse von Investorendaten;493
8.5.2.1;2.1 Aktienregister als Datenbasis;494
8.5.2.2;2.2 Datenaufbereitung und Investoren-Data-Warehouse;495
8.5.2.3;2.3 Data-Mining-Analysen von Aktienregisterdaten;497
8.5.3;3 Fallstudie: Analyse der Aktienregisterdaten bei der AMP Ltd.;501
8.5.3.1;3.1 Hintergrund der Fallstudie;501
8.5.3.2;3.2 Datenanalyse;502
8.5.3.3;3.3 Ergebnisse der Fallstudie;505
8.5.4;4 Zusammenfassung und Ausblick;506
8.5.5;5 Literatur;506
9;DW2004 – Data Warehousing und EAI;509
10;Veranstalter;509
11;Programmkomitee;509
12;Autorenverzeichnis;512

Leseproben

Planung und Einsatz von EAI am Beispiel eines Projekts in der Wertpapierabwicklung einer Geschäftsbank (S. 365-366)

Joachim Kreutzberg, Uwe Proft
sd&,m Schweiz AG

EAI ist ein viel diskutiertes Thema. Die Literatur vermittelt den Eindruck, dass bereits ausgiebige Erfahrungen mit der Einführung und dem Betrieb von EAISystemen bestehen. Die Praxis sieht jedoch oft ernüchternd aus: Nicht selten kommen erste Pilotinstallationen aus dem Experimentierstadium nicht heraus und EAI-Initiativen verlieren ihr Momentum, das zu Beginn ihrer Einführung existierte. Unser Beitrag will anhand der erfolgreichen Einführung von EAI bei einer Geschäftsbank in der Wertpapierabwicklung aufzeigen, welche Punkte beachtet werden müssen, um erfolgreich EAI einzuführen. Dabei zeigen wir auch auf, welche Voraussetzungen gegeben sein müssen, um den Erfolg sicherzustellen.

1 Einleitung

Praktische Erfahrungen mit der Einführung und dem Betrieb von grossen EAISystemen sind immer noch Mangelware (Connelly 1999). Oft erschöpfen sich erste Implementierungen in einzelnen Pilotprojekten und weitere Projekte folgen nicht. Dieser Beitrag will aufzeigen, dass auch in grossen Anwendungen mit hohen technischen Anforderungen und hoher Komplexität eine EAI-Lösung realisiert werden kann, die produktiv genutzt wird. Allerdings sind mehrere Voraussetzungen zu erfüllen, um den Erfolg sicherzustellen. Dieser Beitrag gliedert sich wie folgt: Zuerst werden in Abschnitt 2 grundlegende Überlegungen dargelegt und der Zusammenhang zwischen den geschäftspolitischen Vorgaben und den informationstechnischen Restriktionen aufgezeigt. Aus dieser Betrachtung folgen die konkreten Vorgaben für die Einführung von EAI in der Geschäftsbank. In Abschnitt 3 des Beitrags wird konkret am Beispiel der Wertpapierabwicklung aufgezeigt, wie im Projekt vorgegangen und dabei zuerst eine Bestandsaufnahme der Architektur gemacht und anschliessend eine Zielarchitektur definiert wurde. Abschliessend in Abschnitt 4 werden die Erfahrungen aus dem Projekt beschrieben und die wesentlichen Punkte dargestellt, die wichtig für den Erfolg waren.

2 Strategische Überlegungen

Finanzdienstleister sind wie viele andere Wirtschaftszweige von der Globalisierung betroffen. Banken und Versicherungen müssen auf neue Anforderungen und Veränderungen des Marktes reagieren und ihre Wirtschaftlichkeit erhöhen. Neben der Erhöhung der Wirtschaftlichkeit ist aber auch die Flexibilität ein wichtiger Erfolgsfaktor. Aufgrund der mageren Anlageergebnisse und dem harten Wettbewerb in den letzten Jahren hat jedoch die Kostenreduzierung die höchste Priorität.

2.1 Geschäftspolitische Ziele

Die wesentlichen geschäftspolitischen Vorgaben bestanden in der Erhöhung der Flexibilität und einer nachhaltigen Senkung der IT-Kosten. Aufgrund der strategischen Ausrichtung der Bank konnte mit der Ausweitung des Geschäfts, weiteren Unternehmenszukäufen und auch Abspaltungen gerechnet werden. Die Budgets mussten an die wirtschaftliche Lage und Aussichten nach unten angepasst werden. Die IT als ein wichtiger Faktor für viele Geschäftsprozesse musste sich diesen Herausforderungen stellen. Als wichtige Aufgabe erwies sich dabei die erforderliche Ablösung eines Altsystems für die Wertpapierabwicklung.

2.1.1 Erhöhung der Flexibilität

Die bisher eingesetzte Software für die Wertpapierabwicklung erreichte das Ende ihres Lebenszyklus. Der Lieferant dieser Software stellte die Produktlinie ein, weshalb die Bank gezwungen war, eine Alternativlösung zu planen und zu realisieren. Aufgrund von technischen Vorgaben war eine Fortführung des Altsystems nicht mehr möglich und die Ablösung des Altsystems für die Wertpapierabwicklung unbedingt erforderlich. Die Ablösung konnte bedingt durch die Verzahnung mit zahlreichen anderen Systemen nicht in einem Schritt bewältigt, sondern nur durch eine evolutionäre Strategie gelöst werden. Ziel der neuen Lösung war es, dass Geschäftsmodell der Bank optimal zu unterstützen. Neben der Flexibiltät gegenüber externen Ereignissen sollte auch die Flexibilität für interne Ereignisse wie Reorganisationen und damit das Ankoppeln von neuen Systemen gewährleistet sein