Fusionieren will geplant sein

04.05.2005
Die Datenmigration ist einer der kritischen Faktoren bei einer Firmenübernahme. Wie er zu meistern ist, demonstrierte kürzlich die Commerzbank AG, Frankfurt am Main.

Meist ist die IT das Letzte, woran das Topmanagement bei Akquisitionen und Fusionen denkt. Doch für die schnelle und reibungslose Integration zweier Unternehmen dient die Vereinheitlichung der IT-Systeme als unverzichtbarer Katalysator. Wie der Fusionsexperte Helmut Schulte-Croonenberg betont, zählt diese Erkenntnis aber vor allem im produzierenden Gewerbe noch nicht zum Allgemeinwissen. Anders bei den Banken: "Die Gefahr, dass die IT zu gering geschätzt wird, ist hier relativ gering", so der Vice President bei A.T. Kearney.

Die Commerzbank kann als positives Beispiel dienen. Nachdem sie im Juni vergangenen Jahres die Schmidtbank geschluckt hatte, waren unter anderem die Daten von 360000 Privatenkunden in die Zentralsysteme zu übertragen. Dank sorgfältiger Planung ließen sich viele Probleme im Vorfeld lösen, so dass die Migration Anfang März relativ reibungslos über die Bühne ging.

"Die Datenmigration ist immer heikel", weiß Schulte-Croonenberg, "insbesondere dann, wenn sie von einem Tag auf den anderen geschieht." Ein Parallelbetrieb auf unterschiedlichen Systemen lässt sich jedoch allenfalls auf Zeit bewerkstelligen, weil er die Konsistenz des Datenmaterials gefährdet.

Unter Zeitdruck

Die Maxime der Commerzbank war eindeutig; es sollten nur Daten, keine Systeme übernommen werden. Aus gutem Grund: Während die Commerzbank im kommerziellen Bereich - wie viele andere Banken - eine maßgeschneiderte, zu 95 Prozent selbst entwickelte Software betreibt, hatte die Schmidtbank große Teile ihrer IT vier Jahre zuvor ausgelagert - größtenteils an die Accenture-Tochter ASK. Sie betreibt ein Rechenzentrum für Finanzdienstleister.

Dort lief eine ältere Version der von Siemens stammenden Bankenapplikation "Kordoba", die bereits zur Ablösung anstand. Der Dienstleistungs- und Softwarenutzungsvertrag war eigentlich zum Ende 2004 gekündigt, dann aber noch einmal um drei Monate verlängert worden. Folglich stand das Projekt unter einem gewissen Zeitdruck.

Die 2000 Firmenkunden der mittelständisch orientierten Schmidtbank ließen sich gut von Hand erfassen. "Eine komplexe technische Migration lohnte sich nicht", erläutert Axel Wintermantel, Leiter Zentraler Servicebereich Information Technology Applications, Private Kunden/ Mittelstandsbank und Leiter des Migrationsprojekts bei der Commerzbank. Außerdem eröffnete dies dem neuen Schmidtbank-Eigner die Gelegenheit, die gesamte übernommene Geschäftsklientel erstmals telefonisch zu kontaktieren. Diese Entscheidung nötigt dem Berater Schulte-Croonenberg Respekt ab. Ist sie doch ein Beleg dafür, dass IT und Fachbereiche Hand in Hand gearbeitet haben.

Die Kooperation mit der Business-Seite sei vor allem in der Analysephase sehr eng gewesen, beteuert Wintermantel: "Wie ist zum Beispiel ein Wertpapier-Depot auf der Datenseite abgebildet? Diese Frage muss man sowohl fachlich als auch technisch beantworten." Aus diesem Grund seien die Teams "gemischt" besetzt worden. Beinahe schulbuchmäßig flossen denn auch die Kosten der Datenmigration schon in den Business-Case für die Firmenübernahme ein. "Wären sie zu hoch gewesen, hätten wir das sicher nicht gemacht", bestätigt Wintermantel. Wie hoch sie denn waren, verrät er nicht. Nur so viel: "Meine Schätzungen sind eingehalten worden." Insgesamt waren 200 IT-Spezialisten in das Projekt involviert, davon 120 eigene Leute und 80 "zeitweilige Verstärkungen", wie der IT-Manager sie nennt. Alle Schlüsselpositionen wurden intern besetzt.

Erste Trockenschwimmübungen

Im März 2004, also lange vor der eigentlichen Akquisition, gingen die Migrationsteams daran, die Datenübernahme vorzubereiten. Allerdings konnten sie damals nicht mehr als Trockenschwimmübungen leisten, weil die Kundendaten vor dem Closing nicht zur Verfügung standen. "Wir haben aber schnell gemerkt, dass man in die tatsächlichen Daten schauen muss, um zu sehen, welche Aufgaben man vor sich hat", berichtet Wintermantel.

Für die Übernahme der Daten entwickelten die IT-Experten eine zentrale "Migrationsmaschine". Auf Basis des Software-Tools "Data Integrator" von Business Objects entstand eine Drehscheibe für das Daten-Mapping. Die dort hinterlegten Regeln spiegelten die Ergebnisse aus der Analyse der eigenen und der fremden Systeme wider.

Genügend Spielraum

Der Datenumzug war für das Wochenende vom 5. bis zum 6. März vorgesehen. Das räumte der Commerzbank genügend Zeit ein, um Soll und Ist der Daten vor dem Stichtag 31. März zu vergleichen. Wäre etwas schief gegangen, hätte der Versuch zwei Wochen später wiederholt werden können.

Neben der Vollständigkeit der Daten war auch deren Revisionssicherheit - sowohl intern als auch gegenüber externen Stellen wie den Aufsichtsbehörden - eine notwendige Bedingung. Als absolut kritisch galt jedoch der Faktor Zeit. "In dem Dreieck aus Zeit, Geld und Qualität stellte die Zeit das wichtigste Kriterium dar", sagt Wintermantel. Solange es in den Business-Case passte, habe er einer schnellen Lösung den Vorzug gegenüber einer billigen gegeben.

So kam es, dass die Daten nicht über die Leitung, sondern auf insgesamt sieben Tapes im Hubschrauber von Hof nach Frankfurt transportiert wurden. Die ländlichen Regionen Deutschlands sind im Gegensatz zu den Ballungsräumen mit relativ schwachbrüstigen Leitungen an das Telekom-Netz angebunden. Deshalb hätte die elektronische Übertragung deutlich länger gedauert.

Ende April feierten die Beteiligten den Erfolg des Projekts mit einer großen Party. Bis dahin waren jedoch etliche Hindernisse zu überwinden - angefangen von der mangelhaften Qualität der Ursprungsdaten über unterschiedliche Zugriffsschlüssel bis zu divergierenden Produktangeboten (siehe Kasten "Die Herausforderungen").

Ein Erfolgsfaktor des Projekts war sicher die bankweite Testumgebung. Hier wurden nach dem Einspielen der Bänder unterschiedliche Geschäftsfälle von der Eingabe über den Abschluss bis zum Meldewesen simuliert - beispielsweise die Verlängerung ("Prolongation") einer Einlage, die Kündigung eines Kontos, der Kauf eines Depots und ein kompletter Tagesabschluss. Viele Stolpersteine ließen sich so schon im Vorfeld der Datenübernahme aus dem Weg räumen.

Im Nachhinein beglückwünscht sich Wintermantel auch dazu, mehr Zeit als geplant für die Analysephase aufgewendet zu haben - obwohl dies das Projekt zwischenzeitlich um etwa zwei Monate verzögert habe. Auf der anderen Seite warnt er davor, die Vorsorge zu übertreiben. "Wer in der Analyse perfekt werden will, braucht dafür zwei Jahre." Die Commerzbank habe 80 Prozent der Probleme in der Analyse und 20 Prozent während der Testphase gelöst. Statt der geplanten vier ließ Wintermantel sogar fünf Komplettläufe fahren: Die "Generalprobe" im Dezember 2004 wurde um die Weihnachtsfeiertage wiederholt, weil die Software "noch nicht so weit gewesen" sei.

Die Investitionen in Systemdesign und Know-how dürften sich bei eventuellen weiteren Zukäufen des Finanzdienstleisters doppelt auszahlen. Denn die für das Projekt aufgebauten Strukturen sind zumindest auf Commerzbank-Seite wiederverwendbar. Ändern müssen sich nur die Schnittstellen zu den Systemen der übernommenen Bank.

Beim nächsten Mal will Wintermantel noch mehr Wert auf die räumliche Nähe der Teams legen: "Ich würde am liebsten alle Teams in benachbarten Räumen zusammenziehen." Darüber hinaus hat der Projektleiter in der Praxis erfahren, wie wichtig die Kommunikation, insbesondere die schriftliche, ist: "Mit vier oder fünf Folien, die die Ergebnisse einer Besprechung zusammenfassen, lässt sich eine einheitliche Basis bis in die letzte Ecke des Projekts herstellen."