Migration ohne Gedächtnis

Eine Migration zentraler Systeme wird nicht durchgeführt, weil sie attraktiv wäre, sondern weil sie unvermeidlich geworden ist. Der Termin steht, der Zugriff auf die Altsysteme endet und das neue System braucht Daten, um überhaupt arbeiten zu können. Unter diesen Bedingungen fallen Entscheide, die im Moment vollkommen rational sind. Migriert wird, was der Betrieb am ersten Tag benötigt und was die Aufsicht verlangt. Alles andere hat keinen Fürsprecher.

Genau dort werden Weichen unbewusst gestellt, die Vertrieb, Operations, Finanzen und Risikomanagement noch Jahre später beeinträchtigen. Die Aufmerksamkeit des Projekts liegt beim Datenmapping, beim Testing, bei Schulung und Kundeninformation, bei der Archivierung und bei der Wiedereröffnung der Bank und ihrer Kanäle. Der Rest wandert auf die Zeit nach dem Cutover, wo er verstaubt. Sichtbar wird der Preis erst, wenn die Bank eine Frage stellt, die sie mit den vorhandenen Daten nicht mehr beantworten kann.

Dieser Beitrag ordnet das Thema aus Sicht der Geschäftsführung ein. Er beschreibt, welchen Zwecken Bankdaten dienen und zeigt, weshalb eine Migration systematisch zwei davon bevorzugt. Was eine Bank tun soll, sagt er nicht. Zwänge sind real und führen zu Recht oft zur schnelleren statt zur besseren Lösung. Er plädiert jedoch dafür, bewusst zu verzichten.

Termindruck und Abhängigkeiten

Kein Institut wechselt seine zentralen Systeme aus Freude an der Erneuerung. Der Anstoss kommt von aussen oder von weit oben. Ein Hersteller stellt eine Produktlinie ein oder hält mit den Anforderungen der Kunden nicht mehr Schritt, eine Architektur ist veraltet, eine Fusion verlangt eine gemeinsame Plattform oder eine Eigenentwicklung wird technisch und personell unhaltbar. Der Grundsatzentscheid ist meist gut abgestützt. Was danach folgt, steht unter einem Zeitregime, das mit der strategischen Bedeutung der Sache wenig zu tun hat.

Wir gehen von einer Cutover-Situation aus. Auf die Altsysteme lässt sich nicht dauerhaft zugreifen und das neue System benötigt Daten, um korrekt zu rechnen. Am ersten Arbeitstag danach müssen zum Beispiel der Zahlungsverkehr laufen, Börsenaufträge ausgeführt und abgerechnet werden, Bancomaten Bargeld ausgeben, Kartenzahlungen autorisiert und das E-Banking erreichbar sein. Auch der erste Abschluss muss durchlaufen. Jeder Fehler ist innerhalb von Stunden öffentlich. Diese Erwartung ist nicht verhandelbar und sie prägt jede Diskussion über den Datenumfang.

Hinzu kommt eine Konstellation, die oft verschwimmt. Eine Bank hat es mit zwei Partnern zu tun: mit dem Hersteller der Plattform und mit dem Betreiber, der sie im Auftrag der Bank parametriert, betreibt und wartet. Beides gleichzeitig zu wechseln, erhöht das Risiko erheblich, weil dann niemand mehr die Kombination aus alter und neuer Welt überblickt. In einer solchen Konstellation ist immer der andere schuld. Wer die Plattform wechselt, bleibt idealerweise beim Betreiber.

Lesen Sie auch unseren ausführlichen Beitrag Nähe hat ihren Preis.

Auf die abgelöste Seite können Sie nur begrenzt zählen, denn ein Anbieter, der einen Kunden verliert, hat kein Interesse an einer zügigen Übergabe. Bei alten Eigenentwicklungen steht gar kein Anbieter in der Pflicht und oft weiss auch im Haus niemand mehr, wie die Datenhaltung funktioniert. Was nicht dokumentiert ist, muss von Hand rekonstruiert werden, mitten auf dem kritischen Pfad.

Fachlicher Verwendungszweck

Wer über Datenmigration spricht, spricht in der Regel über Systeme. Das ist wichtig und wird meistens auch gut gelöst. Noch wichtiger ist die Frage, wozu die Daten fachlich gebraucht werden. Dieselbe Kontobewegung dient in einer Bank mindestens sechs Zwecken, jeder mit einem anderen Anspruch an dieselben Daten.

Der laufende Betrieb verlangt aktuelle und korrekte Daten. Ein Saldo muss stimmen, eine Versandadresse zustellbar und ein Produkt korrekt parametriert sein. Historie spielt dabei kaum eine Rolle. Dazu zählen auch Produktdefinitionen und Konditionslogik. Ihre Übersetzung in die Zielwelt ist der anspruchsvollste Teil der Übung und für die Führungsebene der unsichtbarste.

Die Nachweisführung verlangt das Gegenteil. Hier zählt nicht Aktualität, sondern Unveränderbarkeit. Belege, Geschäftsbücher und Beratungsdokumentationen müssen so vorliegen, dass sachkundige Dritte den Ablauf rekonstruieren können. Bei Grundpfändern reichen die Fristen deutlich über die üblichen zehn Jahre hinaus.

Im Risikomanagement zählen Vollständigkeit und Konsistenz über Kunden, deren Verbindungen und deren Transaktionen hinweg. Eine Risikosicht auf Portfolioebene ist nur so gut wie die Verknüpfungen, die tatsächlich abgebildet sind.

Das Kundenverständnis lebt von Breite und Verknüpfung. Beziehungen, Verhalten sowie Einkommens- und Vermögensverhältnisse ergeben zusammen ein Bild, das jederzeit auskunftsfähig ist. Im CRM läuft dieses Bild zusammen, gespeist wird es jedoch aus dem gesamten Datenbestand. Dazu zählen individuelle Vereinbarungen, die strukturiert vorliegen müssen, damit spätere Anpassungen automatisch erfolgen.

Für die Vertriebssteuerung zählt die Vergleichbarkeit über lange Zeiträume. Eine Aussage über die Wahrscheinlichkeit eines Wohneigentumserwerbs entsteht nicht aus dem heutigen Saldo, sondern aus dem Verhalten und Saldoverlauf der letzten Jahre.

Bei der Organisation geht es schliesslich um Eindeutigkeit. Stellen, Rollen, Kompetenzordnungen, Betreuerzuordnungen und Vertretungsregelungen bilden die Grundlage für Berechtigungen und Workflows. Auch diese Daten haben eine Zeitachse.

Sechs Zwecke, ein Datenbestand. Eine Migration presst diese Ansprüche in ein einziges Zielmodell. Was dort nicht abgebildet ist, existiert für die Bank fachlich nicht mehr, auch wenn es noch in einem Archiv liegt.

Der eingebaute Filter

Von diesen sechs Zwecken setzen sich zwei zuverlässig durch, einer teilweise und drei gehen oft leer aus. Das ist kein Versagen des Migrationsteams. Es folgt aus den Zielen und Rahmenbedingungen eines Projekts.

Der Betrieb setzt sich durch, weil ein zwingender Termin dahintersteht. Läuft der Zahlungsverkehr nicht, merken es die Kunden sofort und der Aufschrei ist gross. Die Nachweisführung setzt sich durch, weil Prüfer darauf achten und die Verantwortung bei fehlenden Belegen eindeutig zugeordnet ist. Daten für das Risikomanagement werden dagegen oft nur in dem Umfang migriert, wie sie für die Erfüllung regulatorischer Pflichten relevant sind.

Zu kurz kommen Themen rund um das Kundenverständnis, die Vertriebssteuerung und die Organisation. Nicht weil jemand sie geringschätzt, sondern weil ihr Nutzen zeitversetzt anfällt und ihr Verlust am Cutover niemandem auffällt. Eine fehlende Verhaltenshistorie löst keinen Alarm aus. Beschweren wird sich vorerst auch kein Kunde darüber, dass die Bank die Begründung seines Vorzugspreises verloren hat. Der Schmerz kommt später und er kommt ohne Absender.

Dazu kommt eine Asymmetrie der Kosten. Jede zusätzliche Datenkategorie verlängert Analyse, Mapping, Test und Durchlaufzeit. Die Ersparnis durch Weglassen ist sofort in Franken und Wochen ausweisbar, der Nutzen des Mitnehmens dagegen eine Option auf eine spätere Fähigkeit. Unter Termindruck gewinnt diese Rechnung immer dieselbe Seite.

Abschalten lässt sich dieser Filter nicht, sichtbar machen schon. Die eine Bank kann nach der Umstellung erklären, weshalb ihr etwas fehlt, die andere stellt es nur fest. Der Unterschied entsteht zu Beginn des Projekts und nicht in Sitzungen kurz vor dem Go-live.

Tiefe der Historie

Der wirkungsvollste Entscheid betrifft die Frage, wie weit zurück migriert wird. Gestellt wird sie als Aufwandsfrage. Tatsächlich legt sie die künftige Analysefähigkeit des Instituts fest. Mit der wachsenden Bedeutung von Analytics, Machine Learning und KI in Vertrieb und Risikomanagement wiegt ein Verzicht schwerer als noch vor einigen Jahren.

Für den Betrieb genügen Bestände und wenige Transaktionsdaten: Saldo, Restschuld mit Zinssatz, Depotpositionen sowie die Transaktionen der letzten zwölf bis achtzehn Monate. Ältere Bewegungen sind oft entbehrlich. Für die Nachweisführung genügt ein Archiv, sofern die Belege unveränderbar, jederzeit lesbar und systematisch abgelegt sind. Beide Anforderungen lassen sich mit vergleichsweise wenig Migrationsaufwand erfüllen. Genau das macht die Kombination so verführerisch.

Für das Kundenverständnis und die Vertriebssteuerung reicht ein reines Archiv nicht. Es ist eine rechtskonforme Konserve und enthält Dokumente, aber keine auswertbaren Strukturen. Auf Anfrage liefert es ein Beweisstück, nie eine strukturierte Zeitreihe. Wer die Verhaltenshistorie dorthin versorgt, hat sie formal aufbewahrt und fachlich verloren.

Die Konsequenz ist einfach zu beschreiben. Wer sich für ein Jahr Transaktionshistorie entscheidet, kann nach der Umstellung keinen Fünfjahresvergleich rechnen. Modelle, die Sparverhalten oder Zahlungsmuster auswerten, beginnen bei null. Auch die Mustererkennung in der Überwachung verliert ihre Referenzbasis und produziert mehr Fehlalarme. Auf eine Nachmigration zu hoffen, ist unrealistisch: Das Programm ist aufgelöst, die Fachleute sind zurück in der Linie und die Budgets verbraucht.

Daraus lässt sich eine Regel ableiten. Alles, was das Gesetz verlangt, gehört ins Archiv. Zusätzlich braucht es einen auswertbaren Ort für das, was der künftige Betrieb benötigt oder was dem Kundenverständnis, der Vertriebssteuerung und dem Risikomanagement dient. Das muss nicht das neue Kernsystem sein. Wer nur darüber diskutiert, wie viel Vergangenheit das Kernsystem verträgt, verwechselt den Ort der Verarbeitung mit dem Ort der Auswertung. Umgekehrt gilt: Ohne Löschkonzept wandern auch Bestände mit, deren Grundlage längst weggefallen ist.

Das Data Warehouse ist der Mittelweg zwischen beiden Extremen. Es nimmt Bewegungen und Zustände auf, die im Kernsystem weder gebraucht noch bezahlt werden müssen. Dort bleiben sie strukturiert und über Jahre vergleichbar. Der Aufwand fällt an einer Stelle an, die nicht auf dem kritischen Pfad des Cutovers liegt. Zwei Bedingungen sind allerdings zu erfüllen. Die Schlüssel zwischen alter und neuer Welt müssen die Umstellung überleben. Sonst zerfällt jede Zeitreihe am Stichtag in zwei unverbundene Hälften. Und die Vergangenheit muss geladen sein, bevor die Altsysteme abgeschaltet werden.

Gern übersehen wird dabei, dass das Data Warehouse selbst zu den betroffenen Systemen gehört. Seine Zulieferungen brechen am Cutover ab. Das Projekt baut sie neu, weil sonst die Auswertungen stillstehen. Umfassend nachgeladen wird die Vergangenheit dagegen selten. So entsteht der Bruch genau dort, wo die Bank ihre Mehrjahresvergleiche rechnet.

Kontext und Zuständigkeit

Der zweite Entscheid mit langer Nachwirkung betrifft nicht die Menge der Daten, sondern ihre Struktur. Es geht um alles, was einen einzelnen Datensatz mit seinem Umfeld verbindet.

Auf der Kundenseite sind das zum Beispiel Vollmachten, Verpfändungen, Sicherheiten, Beteiligungs- und Kontrollverhältnisse sowie Haushalts- und Firmenverbindungen. Oft sind sie unvollständig, nicht ausreichend qualifiziert oder über mehrere Applikationen verstreut. Die Versuchung ist gross, sie auf das zu reduzieren, was das Zielsystem in einem strukturierten Feld erwartet. Am Cutover fällt der Verlust nicht auf, weil der Betrieb oft nur den Kontoinhaber braucht. Er fällt auf, sobald eine Risikosicht über verbundene Gegenparteien verlangt wird. Was nie strukturiert erfasst war, lässt sich nur mit viel manuellem Aufwand rekonstruieren oder muss beim Kunden neu erhoben werden.

Auf der Bankseite geht es um die Organisation selbst. Betreuerzuordnungen, Kompetenzstufen, Unterschriftsregelungen und Vertretungen werden als Bild des Stichtags übernommen, weil der Betrieb nichts anderes braucht. Damit verschwindet die Zuordnungshistorie. Es ist aber nicht unerheblich, wer einen Kunden vor fünf Jahren betreut und wer in einem Workflow eine Ausnahme bewilligt hat. Das trifft die Nachweisführung ebenso wie jede Vergütungsmessung, die auf Zuordnung über Zeit beruht.

Qualität und Auslassung

Eine Migration ist der günstigste Moment, um Datenqualität herzustellen. Zugleich ist sie der schlechteste, weil die Bereinigung auf dem kritischen Pfad liegt. Deshalb fällt der Entscheid in vielen Projekten sinngemäss so aus: Wir bereinigen nach dem Go-live. In der Praxis heisst das, nicht zu bereinigen. Hinzu kommt ein subtiler Effekt. Was migriert wurde, gilt anschliessend als geprüft.

Wie stark das wirkt, zeigt ein unscheinbares Beispiel. Adressen sind in Altsystemen oft unvollständig, veraltet oder in Teilen als Freitext abgelegt. Solange an eine bestimmte Adresse keine Post geht, gibt es keine Retouren. Das neue System hingegen erwartet strukturierte, gültige Angaben. Aus einer stillen Altlast wird ein Arbeitspaket mit Mapping, Bereinigung und allenfalls Anreicherung aus externen Quellen. Wer es streicht, hat sauber terminiert und trägt die Unschärfe weiter.

Deutlich teurer wird es bei den Konditionen. Ein Kunde zahlt auf seiner Hypothek einen Abschlag von 30 Basispunkten. Zwei Fragen entscheiden über den Wert dieser Information. Unter welchen Umständen kam der Preis zustande? Stand die Begründung in einem Freitextfeld ohne Ziel, führt die Bank Jahre später ein Verlängerungsgespräch, ohne die eigene Zusage zu kennen. Und wurde ein absoluter Satz vereinbart oder ein Abschlag auf einen Referenzsatz? Das ist der Unterschied zwischen einer festen und einer mitlaufenden Verpflichtung, für den Vertrieb der Verhandlungsspielraum, für die Bilanzsteuerung das Verhalten bei einer Zinsbewegung. Landet beides im selben Zielfeld, verliert die Bank eine Unterscheidung, die sie nie wieder herstellen kann. Unangenehme Kundengespräche sind die Folge.

Auch der Übergang selbst hinterlässt Spuren. Fachlich ideal wäre ein Cutover auf den Jahresabschluss, weil jeder andere Zeitpunkt Abgrenzungen, Zinsperioden und Auswertungszeiträume mitten im Geschäftsjahr auftrennt. In der Praxis wird der Jahreswechsel gemieden, weil dann die Jahresendverarbeitung läuft, ein Codefreeze gilt und das Anrufvolumen im Kundendienst ohnehin am höchsten ist. Der Ausweichtermin ist vernünftig und erzeugt trotzdem Aufwand: Für Konten, die im Altsystem nicht monatlich abgeschlossen wurden, müssen die Zinsen von Hand ermittelt werden. In den Zeitreihen bleibt ein Bruch.

Entscheid und Verantwortung

Nichts davon führt zur Empfehlung, mehr zu migrieren. Die Zwänge sind real: Der parallele Betrieb zweier Welten kostet Geld und Nerven, der Aufwand für Analyse, Mapping und manuelle Aufbereitung ist schlecht schätzbar, das Zielsystem nimmt nicht jede historische Eigenheit auf und das Wissen über die alte Welt ist knapp. Jede Bank muss das für sich beurteilen. Wer sich gegen eine umfassende Migration ins Kernsystem entscheidet, hat damit allerdings noch nicht über die Historie entschieden. Sie kann strukturiert und auswertbar an einem zweiten Ort liegen, etwa im Data Warehouse.

Unterscheiden lässt sich hingegen, wie ein solcher Entscheid zustande kommt. Zwischen einem bewussten Verzicht und einem unbemerkten Verlust liegt ein grosser Unterschied. Ein bewusster Verzicht ist benannt, begründet, datiert und einer Person zugeordnet. Er hält fest, welche Fähigkeit das Institut aufgibt und unter welchen Bedingungen sie wiederhergestellt werden könnte. Im Projekt kostet er fast nichts, ausser der Disziplin, das Ergebnis aufzuschreiben.

Damit ist auch die Frage der Ebene beantwortet. Die Tiefe der Historie, die Abbildung von Beziehungen und Zuständigkeiten sowie der Umgang mit Konditionen sind keine Mapping-Fragen. Sie bestimmen, welche Geschäftsfragen das Institut in fünf oder zehn Jahren beantworten kann. Die Verantwortung für kritische Daten liegt aufsichtsrechtlich ohnehin bei Verwaltungsrat und Geschäftsleitung.

Bleibt der Blick über die eigene Umstellung hinaus. Die heutige Plattform wird nicht die letzte sein, weshalb die Herauslösbarkeit der Daten bereits heute zählt. Stabile Identifikatoren, dokumentierte Herkunft und eine Geschäftslogik, die nicht ausschliesslich in Systemparametern vergraben liegt, entscheiden darüber, ob die nächste Migration mit einem Startvorteil beginnt oder wieder mit Rekonstruktion.

Fazit

Eine Datenmigration ist kein technisches Vorhaben mit fachlichen Nebenwirkungen, sondern ein fachliches Vorhaben mit technischer Umsetzung.

Die Entscheidlogik im Projekt ist rational und einseitig zugleich. Der Betrieb und die Nachweisführung setzen sich durch, weil Termin und Aufsicht hinter ihnen stehen. Für das Kundenverständnis, die Vertriebssteuerung und die Organisation gilt das nicht. Ihr Nutzen fällt später an und ihr Verlust fällt im Moment der Umstellung niemandem auf.

Die Frage für die Geschäftsführung lautet deshalb nicht, ob am Cutover Kompromisse eingegangen werden. Das ist gesetzt. Sie lautet, ob das Institut hinterher weiss, welche Kompromisse es eingegangen ist. Ein dokumentierter Verzicht ist im Projekt beinahe gratis. Viele Jahre später ist er der Unterschied zwischen einer erklärbaren Lücke und einer unerklärlichen.

Zwischen vollständiger Migration und blossem Archiv liegt zudem ein Weg, der im Projekt oft gar nicht diskutiert wird. Die Historie muss nicht ins Kernsystem, sie muss auswertbar sein. Ein Data Warehouse leistet das, verlangt aber ein Konzept und Leute, welche die alte Datenwelt noch verstehen. Der Aufbau liegt nicht auf dem kritischen Pfad des Cutovers und lässt sich zeitlich entzerren. Abhängig davon bleibt er trotzdem, denn geladen werden kann nur, was vor dem Abschalten der Altsysteme noch verfügbar ist.

Und weil nach der Migration vor der Migration ist, lohnt sich am Tag der Einführung eine zweite Frage: Wie kommen diese Daten eines Tages wieder heraus?

---

Wir von Bricks & Brains verfügen über umfassende Projekterfahrung zu diesem Thema. Gerne unterstützen wir auch Ihr Institut.

Kontaktieren Sie uns »