Wie lassen sich Systeme unterschiedlicher Herkunft aneinander andocken? Wo liegen die Schwierigkeiten? Und wie lassen sie sich meistern? Mit diesen Fragen musste sich ein zu Spitzenzeiten 150-köpfiges Projektteam der Commerzbank beschäftigen. Die Antworten lassen sich anhand von zehn Erfolgsfaktoren zusammenfassen.
Klares Ziel von Anfang an
Essenziell war, im ersten Schritt die Zielprozesswelt und die fachliche Architektur klar zu definieren. Kein einfaches Unterfangen bei einer so komplexen Mischung aus "grünen" und "gelben" Elementen. Denn schließlich gab es niemanden, der sowohl die Dresdner- als auch die Commerzbank-Systemwelt beherrschte. Die Lösung bestand in "Kleeblattgesprächen": Fachliche und technische Experten sowohl der Dresdner Bank als auch der Commerzbank definierten und dokumentierten in gemeinsamen Workshops das Zielbild. Gerade an den Schnittstellen zwischen "grünen" und "gelben" Systemen gab es dabei Raum für Überraschungen.
Der Blick auf den Gesamtprozess
Wenn ein System unverändert aus der alten in die neue Welt übernommen wird, ist es verführerisch, es aus der Analyse auzuklammern. Schließlich erscheint es als "Black Box" mit wohldefinierten Schnittstellen und etablierten Prozessen. Doch der Schein trüg. Die Betrachtung der gesamten Prozesskette von der Geschäftserfassung im Front-Office über die Abwicklung im Back-Office bis zu den Finance- und Risk-Systemen ist unabdingbar. Trotz klar definierter Schnittstellen verhalten sich "gelbe" Systeme anders, wenn sie mit "grünen" Systemen zusammenspielen, als es zuvor mit dem "gelben" Pendant der Fall war.
Gebremster Mut zur Improvisation
Trotz aller Mühen, das Zielbild bei Betrachtung der gesamten Prozesskette zu definieren, gab es auch Überraschungen. In diesen Situationen war die Bereitschaft der Fachbereiche, tragfähige temporäre Lösungen zu erarbeiten und einzusetzen, essenziell. Doch musste hier auch ein gesunder Mittelweg gefunden werden. Temporäre Lösungen kamen nur dann zum Einsatz, wenn es keine Alternativen gab. Zudem galt es als ausgemacht, dass sie kurzfristig durch die korrekte Funktionalität ersetzt wurden. Umgekehrt war entscheidend, nur dann zu improvisieren, wenn es tatsächlich notwendig war. Mancher vermeintliche Quick Win wäre technisch aufwändig zu erreichen gewesen oder hätte gar vom Ziel weggeführt.
Sorgfältig geplante Etappen
Nach der Definition des Zielbilds hat das Team viel Energie darauf verwandt, gemeinsam mit den Fachbereichen die Etappen auf dem Weg zum Ziel festzulegen. Nach der Planung der einzelnen Migrationsschritte ging es an die Umsetzung. Zunächst wurden zwei kleinere Geschäftsfelder mit geringer Außenwirkung in die neue Prozess- und Systemwelt übernommen. Dank der dort gesammelten Erfahrungen ließen sich die Verfahren verbessern und die Werkzeuge schärfen.
Die Motivation und das Vertrauen des gesamten Teams in den Erfolg des Projekts wurden spürbar gestärkt und langfristig gefestigt. Nach dem geglückten "Warmlaufen" konnte schließlich die Migration der großen Geschäftsfelder beginnen - und zwar im Monatsrhythmus. Die letzten Migrationsschritte umfassten kleinere Bereiche, die spezifische Funktionen voraussetzten. Rückblickend waren, neben dem Ansatz in Etappen vorzugehen, zwei Entscheidungen bedeutend:
-
Zu jeder Etappe wurden die wesentlichen Planungsannahmen erarbeitet und dokumentiert.
-
Es war jederzeit ein stabiles und klar definiertes Bild vom jeweiligen Produktionsstand vorhanden.
IT-Plattform und Datenmigration entkoppeln
Die gedankliche und planerische Trennung half, die Komplexität des Projekts zu reduzieren. Jede einzelne Übernahme von Geschäftsfeldern in die Zielstruktur wurde in zwei Schritte untergliedert. Der erste Schritt bestand in der Umsetzung der jeweils notwendigen Änderungen an der IT, also der Funktionen und Schnittstellen. Der zweite Schritt folgte etwa zwei Wochen später; er bestand in der Migration der Stamm- und Transaktionsdaten aus der Quell- in die Zielwelt.
Selbstverständlich setzt der zweite Schritt den ersten voraus. Doch war er von diesem technisch und prozessual unabhängig. So konnten die Konzeption der Migration, die Entwicklung der Migrationsprogramme und deren Test von den Änderungen an der IT-Plattform entkoppelt werden.
Keine Premiere ohne Generalprobe
Trotz gründlicher Analysen ist man vor Überraschungen nie gefeit. Um damit nicht erst bei der produktiven Migration konfrontiert zu werden, wurde jede Migration dreimal geprobt. Und zwar so nah an der Realität wie möglich. Das heißt
-
auf einer Testumgebung, die dem produktiven Stand so gut wie technisch machbar entsprach,
-
unter Verwendung anonymisierter Daten aus der Produktion und
-
inklusive eines Tests der regulären Geschäftsprozesse nach Abschluss der Migration.
Jede Generalprobe begann mit einem neuen Datenabzug aus der Produktion. Dadurch umfassten die Läufe unterschiedliche Konstellationen, die auch zu unterschiedlichen Fehlerbildern führten. Durch diesen Ansatz ließen sich die Fehler vor der produktiven Migration beheben.
Neue Planung als neue Chance
War der Projektplan nicht mehr realistisch, beispielsweise weil es mehr Überraschungen gab als erwartet, so führte an einer Neuplanung kein Weg vorbei. In diesem Fall an einer alten Planung festzuhalten resultiert in einem Verlust an Motivation im Team. Das zeigt, wie wichtig Flexibilität in der Planung für den Erfolg des Projekts ist. Die Projektbeteiligten erkennen dadurch auch, dass es kontinuierlich weitergeht. Die Neuplanung muss aber unter den gleichen Rahmenbedingungen wie die initiale Etappenplanung stattfinden, also unter Einbindung der Fachbereiche und Berücksichtigung der Planungsannahmen.
Besser ins Ziel durch Teamarbeit
Die Senior Manager in der IT, die involvierten Fachbereiche und der externen Dienstleiter müssen alle das Projektziel, das Vorgehen sowie en Plan verstehen. Und sie müssen daran glauben. Unter diesen Voraussetzungen werden die richtigen Mitarbeiter für das Projekt abgestellt, die fokussiert auf das Ziel hinarbeiten.
Aber auch auf den Ebenen darunter ist der enge Schulterschluss aller Beteiligten unabdingbar. Bereichsübergreifende Meetings wurden deshalb um den regelmäßigen Austausch zu Fortschritt, Problemen und Risiken ergänzt. Das ermöglichte zu jeder Zeit ein gutes gegenseitiges Verständnis, was wiederum erheblich zur Effizienz und damit zum Projekterfolg beitrug. Bereichsspezifische Insellösungen waren von Beginn an ausgeschlossen.
Marathon mit Zwischenspurts
Einige kritische Situationen ließen sich während der n Laufzeit des Großprojekts nicht vermeiden, etwa das Auftreten größerer fachlicher Herausforderungen in den letzten Testphasen. Dann wurde sofort in den "Task-Force-Modus" umgeschaltet; der Fokus aller Teilprojekte war eine Zeitlang ausschließlich auf das Lösen dieser kritischen Situation gerichtet. Dies hieß konkret: kurze, tägliche Telefonkonferenzen aller Teilprojektleiter, in denen die Teilprobleme benannt sowie die nächsten Schritte und Verantwortlichkeiten zu deren Lösung definiert wurden. Tags darauf wurden die Fortschritte abgefragt und der weitere Weg vereinbart. Die Geschwindigkeit der Problemlösung ließ sich so enorm steigern.
Ein solches Vorgehen zehrt selbstverständlich an den Kräften des Teams. Es sollte deshalb wohldosiert eingesetzt werden. Viermal während der gesamten Projektdauer standen die Zeichen auf "Task Force", und nie überschritt die Dauer zwei Wochen.
Kraft tanken für die nächste Etappe
Nach jedem erfolgreichen Etappenziel wurden Ruhepausen eingelegt - aber nicht, ohne den Erfolg mit dem gesamten Team vorher gebührend zu feiern. Beides war wichtig, um frische Motivation zu gewinnen, das Erlebte zu verarbeiten und sich mental auf die nächste Etappe vorzubereiten. (qua)