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.
• Als das Projekt in Angriff genommen wurde, war die gesamte IT-Mannschaft schon "verplant", das Auftragsbuch für 2004 prall gefüllt. Deshalb mussten alle Vorhaben neu priorisiert und teilweise verschoben werden. • Es handelte sich um ein Projekt ohne Vorbild. Vorgehensweisen und Projektpläne mussten völlig neu entwickelt werden. • Eine Eins-zu-eins-Übernahme der Daten war unmöglich: Während die Commerzbank ihren Datenbestand personenbezogen aufgebaut hatte, war die Führungsgröße der Schmidtbank-Daten die Kontonummer. Der gesamte Bestand war also erst einmal nach Namen zu sortieren. • Die Testumgebung hatte die gesamte Commerzbank-Welt abzubilden, weil alle Teile des Instituts betroffen waren. • Die Datenqualität des abgebenden Systems war "subomptimal". Die Kordoba-Software entsprach nicht mehr dem Standard, und die Dokumentation ließ zu wünschen übrig. Folglich konnte das Daten-Mapping nicht automatisiert werden. |
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.