Mehrere Quellsysteme, ein Zielsystem: Multi-Source-Migration ohne Datenbrei

Kaum ein Versorger hat seine Daten in einem System: Abrechnung, Messwesen, Kundenkontakte und Energiehandel leben in getrennten Welten verschiedener Hersteller. Dieser Beitrag zeigt die fünf typischen Bruchstellen einer Multi-Source-Migration und das Architekturprinzip, das sie beherrschbar macht.

Die Realität: eine gewachsene Systemlandschaft

Das Zielbild ist klar: ein integriertes SAP S/4HANA Utilities. Die Ausgangslage ist es nicht. Typischerweise liegt die Abrechnung in einem Branchensystem, die Messdaten in einem separaten EDM (Energiedatenmanagement, die Welt der Lastgänge und Zählerstände), die Kundenhistorie in einem CRM und die Beschaffung in einem Handelssystem. Jedes System hat einen anderen Hersteller, ein anderes Datenmodell, einen anderen Exportweg. In einem Mandat waren es vier Quellsysteme, die in ein Zielsystem zusammenlaufen mussten.

Wer diese Landschaft wie eine Ein-System-Migration behandelt (Extrakt ziehen, mappen, laden), produziert das, was Projektteams treffend „Datenbrei" nennen: technisch geladene, fachlich widersprüchliche Bestände. Die Bruchstellen sind vorhersehbar.

Bruchstelle 1: Ein Kunde, vier Wahrheiten

Derselbe Kunde existiert in jedem Quellsystem, jeweils mit eigener Nummer, eigener Adressschreibweise und eigenem Pflegestand. „Müller GmbH & Co. KG", „Mueller GmbH" und „Müller GmbH i. G." sind im Zweifel dieselbe Firma. SAP verlangt das Gegenteil: einen Geschäftspartner (PARTNER), der alle Rollen bündelt: Vertragspartner, Zahler, Anschlussnehmer.

Ohne bewusste Dublettenstrategie entsteht pro Quellsystem ein eigener Geschäftspartner, und damit getrennte Konten, Mahnläufe und Korrespondenz für denselben Menschen. Die Gegenmaßnahme hat zwei Teile: eine Dublettenerkennung mit definierten Matching-Regeln (Name, Adresse, Bankverbindung, Geburtsdatum) und, wichtiger noch, ein führendes System je Attribut. Die Adresse gewinnt vielleicht das CRM, die Bankverbindung die Abrechnung, die Marktpartnerdaten das EDM. Diese Entscheidung ist fachlich, nicht technisch, und sie muss vor dem ersten Mapping fallen.

Bruchstelle 2: Encoding- und Formatchaos

Vier Hersteller heißt vier Exportkonventionen. Das eine System liefert UTF-8, das andere CP1252, und aus „Müller" wird beim falschen Einlesen „Müller". Das eine trennt Spalten per Pipe, das andere per Tabulator oder Semikolon. Das eine schreibt Datumswerte als TT.MM.JJJJ, das andere als JJJJMMTT, das dritte liefert leere Endedaten mal als Nullen, mal als leeres Feld.

Einzeln ist jedes dieser Probleme trivial. Gefährlich werden sie, weil sie still scheitern: Eine mit falschem Encoding gelesene Datei lädt fehlerfrei, nur eben mit zerstörten Umlauten in zehntausenden Namensfeldern. Deshalb gehört an den Anfang jeder Quellsystem-Anbindung eine technische Eingangsprüfung: Encoding, Trennzeichen, Spaltenzahl, führende Nullen in Schlüsselfeldern. Wie man solche stillen Fehler systematisch findet, beschreibt Stille Fehler in der Datenmigration.

Bruchstelle 3: Hersteller-Extrakte als Engpass

Die unangenehmste Abhängigkeit steht in keinem Projektplan: Extrakte aus Fremdsystemen liefert oft nur der Hersteller: gegen Beauftragung, mit Vorlauf, in seinem Format und seinem Rhythmus. Wer den Extrakt erst bestellt, wenn das Mapping ihn braucht, verliert Wochen; wer Änderungswünsche am Extraktformat hat, verliert Monate.

Die Konsequenz ist banal und wird trotzdem regelmäßig versäumt: Extrakte früh bestellen, als eine der ersten Projekthandlungen und nicht als Folgeaktivität des Mappings. Und zwar inklusive Testlieferung, damit Format und Vollständigkeit geprüft sind, bevor der Extrakt auf dem kritischen Pfad liegt.

Bruchstelle 4: Mandantentrennung und Unbundling

Versorger unterliegen der Entflechtung: Vertrieb, Netzbetrieb und Messstellenbetrieb müssen informatorisch getrennt arbeiten. Im Zielsystem heißt das meist: getrennte Mandanten oder strikt getrennte Organisationsstrukturen. Die Quellsysteme kennen diese Trennung aber oft nur teilweise: Ein Kundendatensatz trägt Vertriebs- und Netzinformationen gemischt.

Die Migration muss jede Zeile eindeutig einer Rolle zuordnen: Gehört dieser Vertrag dem Vertrieb, diese Lokation dem Netz, dieses Gerät dem Messstellenbetreiber? Ein typischer Fehler dabei ist so simpel wie folgenreich: Mappings werden vom einen Mandanten als Vorlage in den anderen kopiert, und ein vergessener Festwert schreibt Vertriebsdaten in den Netzmandanten. Solche Fehler sind später kaum rückholbar, weil sie die Entflechtungslogik selbst verletzen.

Das Prinzip dagegen: ein gemeinsames Zwischenmodell

Der strukturelle Fehler vieler Multi-Source-Projekte ist die Punkt-zu-Punkt-Architektur: jedes Quellsystem direkt aufs Ziel gemappt. Bei mehreren Quellen und dutzenden Migrationsobjekten explodiert die Zahl der Mappings, und jede Zielsystem-Änderung schlägt auf alle Quellstränge durch.

Die tragfähige Alternative ist ein gemeinsames Zwischenmodell: eine kanonische Datenschicht, die sich an den Zielobjekten orientiert: Geschäftspartner, Vertragskonto, Anlage, Gerät, Lokation. Jedes Quellsystem wird einmal in dieses Modell übersetzt; von dort führt genau ein qualitätsgesicherter Weg ins Ziel. Hier findet auch die Schlüsselharmonisierung statt: Jede Quellnummer wird auf einen eindeutigen, kollisionsfreien Altschlüssel abgebildet, sodass sich jeder Zieldatensatz bis in sein Quellsystem zurückverfolgen lässt. Es ist dieselbe Rückverfolgbarkeit, die auch der Wirtschaftsprüfer sehen will.

Nicht die Zahl der Quellsysteme entscheidet über den Datenbrei – sondern ob sie sich in einem gemeinsamen Modell treffen oder erst im Zielsystem.

Der Nebeneffekt: Dublettenentscheidung, Formatbereinigung und Mandantenzuordnung passieren einmal, zentral und prüfbar im Zwischenmodell statt verstreut in jedem einzelnen Mapping. Welche fachlichen Fallen dann noch bleiben, zeigt Datenmigration bei S/4HANA: typische Stolperfallen; das technische Laden übernimmt die Migration Workbench, erklärt in EMIGALL erklärt.