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.

Die wesentlichen Details der Planung des nationalen Gesamtprojekts und der Teilprojekte wurden im Rahmen von Kick Off-Workshops in den einzelnen Teilprojekten festgelegt und anhand von "Terms of Reference" schriftlich fixiert. Dazu gehörten neben der Definition des Projektumfangs auch die wichtigsten Aufgaben und Meilensteine, die grobe zeitliche Planung des Projekts bzw. Teilprojekts (über Microsoft Project), die Zuordnung der nötigen Ressourcen und die Identifikation von Risiken. Wegen der strategischen Bedeutung der Dezentralisierung verzichtete die Projektleitung bewusst auf ein detailliertes Kostenmanagement im Rahmen der Teilprojekte.

Zur Information des Projektfortschritts wurde ein wöchentlicher Statusbericht über die Teilprojekte sowie das Gesamtprojekt erstellt und ein wöchentliches Statusmeeting durchgeführt. An diesen Meetings nahmen alle Funktionsträger des Projekts (Projektsponsor, Projektleiter, Teilprojektleiter, Berater) teil. Zudem fanden in regelmäßigem Abstand Statusmeetings mit den in der Zentrale für das gesamteuropäische Projekt verantwortlichen Projekt- und Teilprojektleitern statt. Um den Aufwand für den wöchentlichen Statusbericht in vertretbaren Grenzen zu halten, wurden dessen Inhalte auf die Darstellung der wesentlichen Risiken und Probleme, die erreichten Ergebnisse, Meilensteine des Teilprojekts und die nächsten Schritte beschränkt. Das Projektbüro sammelte die jeweiligen Einzelberichte aus den Teilprojekten und präsentierte sie als Gesamtbericht bei den Statusmeetings. Wesentliche Informationen über das Projekt gab der Gesamtprojektleiter darüber hinaus im Lenkungsausschuss und zusätzlich über das unternehmensweite Intranet bekannt.

…