Fachbeitrag
– Ausgabe 21/2004

Erfahrungsbericht: Dezentralisierung der IT-Anwendungsarchitektur bei einer internationalen Bank

Nicht immer ist die Zentralisierung der Informationstechnologie ein Allheilmittel, mit dem Unternehmen Synergieeffekte erreichen und ihre Kosten senken können. Vor allem wenn über Landesgrenzen hinweg Datenverarbeitung und Prozesse zusammengelegt werden, birgt dies Risiken, die den langfristigen operativen Nutzen dieser Strategie in Frage stellen. Diese Erfahrung machte auch eine international tätige Bank, deren zentralisierte Anwendungs- und Datenarchitektur zur Kosten- und Qualitätsfalle zu werden drohte. Aus strategischen Gründen entschied sich die Bank für ein Dezentralisierungsprojekt, um lokale Anwendungen von konzernweit verwendeten zu trennen. Peter Esposito schildert das Projekt aus Sicht der deutschen Niederlassung.

Nicht immer ist die Zentralisierung der Informationstechnologie ein Allheilmittel, mit dem Unternehmen Synergieeffekte erreichen und ihre Kosten senken können. Vor allem wenn über Landesgrenzen hinweg Datenverarbeitung und Prozesse zusammengelegt werden, birgt dies Risiken, die den langfristigen operativen Nutzen dieser Strategie trotz einer detaillierten Analyse im Vorfeld in Frage stellen. Diese Erfahrung machte auch eine international tätige Bank. Wesentliche Bereiche der Anwendungsinfrastruktur und Datenverarbeitung waren im Laufe der europaweiten Expansion zentral gewachsen und weitgehend vereinheitlicht.

Um länderspezifische gesetzliche und regulatorische Anforderungen sowie Markterfordernisse in allen angeschlossenen Ländern einhalten zu können, musste die Bank einen gemeinsamen Nenner bei Anwendungen und Daten finden. Für die Unternehmenszentrale hatte dies zur Folge, dass die Anforderungen an Ressourcen, Datenhaltung und Anwendungsschnittstellen im Laufe der Zeit stark stiegen und demzufolge qualitative Mängel im operativen Betrieb auftraten. Die eingeschlagene Strategie einer zentralen Anwendungs- und Datenarchitektur, die ursprünglich dazu gedacht war, Synergien zu nutzen, drohte zur Kosten- und Qualitätsfalle zu werden.

Somit wurde die strategische Entscheidung zur Dezentralisierung getroffen, bei der lokal sensible und konzernweit verwendete Anwendungen voneinander getrennt werden sollten. Dabei galt es, nicht nur die technische Dezentralisierung von Anwendungen und Daten zu meistern, sondern auch die schwierige personelle Situation, die damit einherging. Das in der Zentrale aufgebaute Know-how musste innerhalb der geplanten Projektlaufzeit auf die lokalen Einheiten übergehen, um die Aufnahme des operativen Betriebs im jeweiligen Land sicherzustellen. Zudem musste ein Teil der bisher in der Zentrale tätigen Mitarbeiter in andere Bereiche des Konzerns ausgegliedert oder ggf. ganz "freigesetzt" werden. Der Grad zwischen Kostensenkung auf der einen und Aufbau des Know-hows auf der anderen Seite war dabei sehr schmal.

Die zentrale IT-Architektur und viele zentrale Prozesse machten es im Rahmen der international ausgerichteten, dezentralen Neustrukturierung notwendig, das Vorhaben in ein zentrales Projekt und in lokale Projekte je Land aufzuteilen. Dieser Beitrag beschreibt das Dezentralisierungsprojekt aus Sicht der deutschen Niederlassung.

Projektorganisation und -planung

Die Projektleitung setzte die Gesamtlaufzeit des Projekts zu Beginn auf zwölf Monate fest. Wegen der großen Zahl und der Komplexität der Anwendungen und Prozesse, die lokalisiert werden mussten, unterteilte die Projektleitung das lokale Projekt von Anfang an in mehrere Teilprojekte - unter anderem für die Bereiche Informationstechnologie und Operations, Kernbanksystem sowie die Bereiche Schnittstellen/Drittsysteme und Wertpapierdaten. Im Projektverlauf kamen weitere separat geführte Teilprojekte für das Testumfeld, Finance sowie Drittsysteme dazu. Im Rahmen einer beratenden Funktion wurden zusätzlich marktorientierte Abteilungen eingebunden. So stellte die Projektleitung sicher, dass auch Stakeholder, die nicht direkt am Projekt beteiligt waren, regelmäßig die aus ihrer Sicht bestehenden Risiken und Aufgaben dem Projektteam im Rahmen der wöchentlichen Statusmeetings mitteilen konnten. Außerdem wurde ein Projektbüro eingesetzt. Es sollte als Informations- und Kommunikationsdrehscheibe innerhalb der Projektorganisation dienen und gewährleisten, dass die Projektteams bei der Durchführung des Projekts die vereinbarten Mindeststandards einhielten. Ein Projekt-Lenkungsausschuss steuerte das Gesamtprojekt.

Ende der Artikelvorschau. Der vollständige Artikel ist für Abonnenten frei zugänglich.
Anzeige
Artikel (7 Seiten) |
0
Leserbewertungen
Kostenlos weiterlesen!
  • Diesen Beitrag kostenlos lesen
  • 4 Wochen voller Zugriff auf alle Artikel, Vorlagen und das Glossar
Artikel kaufen (2,50 €)
  • 7 Seiten Praxiswissen
  • Download als PDF möglich
  • Unbegrenzter Zugriff
Tech Link