Legen Sie für jedes Objekt die maßgebliche Datenquelle und eine stabile Identität fest und beschreiben Sie anschließend für jedes Feld Bedeutung, Format, Einheit, Pflichtstatus, Transformation und Fehlerzustand. Prüfen Sie das Mapping anhand realer Ausnahmen, versionieren Sie es und stimmen Sie jede Änderung mit den Verantwortlichen beider Systeme ab.
Das Mapping von Daten zwischen Systemen ist kein mechanisches Verbinden von Spalten mit ähnlichem Namen. Das Feld Kunde kann im CRM einen Geschäftskontakt bedeuten, im ERP einen Rechnungsempfänger und auf der Website ein Benutzerkonto. Unterscheidet die Integration die Bedeutung nicht, überträgt sie syntaktisch gültige Daten in den falschen Prozess, und der Fehler zeigt sich womöglich erst bei der Abrechnung oder im Support.
Ein gutes Mapping beschreibt Zuständigkeit, Identität, Pflichtangaben, Format, Transformation und das Verhalten bei unbekannten Werten. Das Dokument bleibt ein gemeinsamer Vertrag zwischen Fach- und Technikteam. Es muss testbar und versionierbar sein, da sich beide Systeme weiterentwickeln. Eine einmalige Tabelle ohne Verantwortlichen entspricht schnell nicht mehr der Realität.
Beginnen Sie mit Objekten, Ereignissen und Zuständigkeiten
Skizzieren Sie, welche Objekte bei welchem Ereignis übertragen werden. Bestellung, Kunde, Produkt und Zahlung haben unterschiedliche Lebenszyklen. Legen Sie fest, welches System einen bestimmten Wert ändern darf und welches nur eine Kopie empfängt. Eine bidirektionale Synchronisierung ohne Konfliktregeln kann einen neueren Wert durch einen älteren überschreiben.
Unterscheiden Sie zwischen Erstellen, Aktualisieren, Archivieren und Löschen. Nicht jeder Status sollte automatisch weitergegeben werden. Ein abgemeldeter Kontakt im Marketing bedeutet nicht zwangsläufig, dass ein Buchhaltungsdatensatz gelöscht wird. Der Prozessverantwortliche muss die Bedeutung des Ereignisses und die Aufbewahrungsregeln bestätigen; die technische Integration sollte sie nicht anhand der verfügbaren Endpoints erfinden.
Verwenden Sie stabile Identitäten und eine Zuordnungstabelle
Bewahren Sie interne und externe Kennungen nebeneinander auf. Name, E-Mail-Adresse oder Telefonnummer können sich ändern und müssen nicht eindeutig sein. Erstellen Sie bei der ersten Verknüpfung eine nachvollziehbare Zuordnung und legen Sie eine Regel für Duplikate fest. Eine manuelle Zusammenführung erfordert ein Audit, damit die nächste Synchronisierung den Datensatz nicht erneut aufteilt.
Unterscheiden Sie bei Produkten zwischen interner ID, SKU, EAN und der Identität der Variante. Bei einem Unternehmen kann es eine juristische Person, eine Betriebsstätte und eine Kontaktperson geben. Wählen Sie den Identifikator nach dem Objekt, nicht nach der Bequemlichkeit einer einzelnen Ansicht. Fehlt ein stabiler Schlüssel, entwerfen Sie einen kontrollierten Abgleichprozess, in dem unsichere Fälle sichtbar sind.
- stabile ID von Quelle und Ziel
- Regel für die Erstverknüpfung und Duplikate
- Audit der manuellen Zusammenführung
- Verhalten bei fehlender Identität
Beschreiben Sie Bedeutung, Format und Transformation des Feldes
Ein Mapping-Eintrag sollte die fachliche Definition, das Quell- und Zielfeld, den Datentyp, die Pflichtangabe und die Transformation enthalten. Geben Sie bei Beträgen die Währung und den Umgang mit Steuern an, bei Datumsangaben die Zeitzone, bei Adressen die Struktur und bei Listen die zulässigen Werte. Ein gleicher Name ohne Einheit kann einen stillen Fehler verursachen.
Halten Sie Transformationen deterministisch und testbar. Die Normalisierung einer Telefonnummer, die Umwandlung eines Status oder das Zusammenführen eines Namens sollten sowohl beschriebene Eingaben als auch den Informationsverlust dokumentieren. Kann das Ziel ein Detail der Quelle nicht erhalten, entscheiden Sie, ob Sie es separat speichern oder die Übertragung ablehnen. Ordnen Sie einen unbekannten Wert nicht automatisch der nächstliegenden Option zu.
Unterscheiden Sie leere, fehlende und ungültige Werte
Ein fehlendes Feld kann „keine Änderung“ bedeuten, ein leerer Wert „Löschen“ und null „unbekannter Wert“. Diese Bedeutung muss Teil des Vertrags sein. Bei einer Teilaktualisierung besteht die Gefahr, dass nicht vorhandene Felder das Ziel mit einem leeren Wert überschreiben. Testen Sie jede Variante und verwenden Sie explizite Operationen, wenn die API die Unterscheidung der Absicht ermöglicht.
Die Validierung soll zwischen einem vorübergehend unvollständigen Datensatz und einer dauerhaft ungültigen Eingabe unterscheiden. Geben Sie Fehler mit dem Feldbezeichner und einem sicheren Grund zurück. Erlaubt der Prozess eine Quarantäne, legen Sie fehlerhafte Datensätze zur Korrektur beiseite, ohne den gesamten Batch anzuhalten. Verarbeiten Sie den korrigierten Wert erneut mit demselben kontrollierten Verfahren.
Versionieren Sie das Mapping und testen Sie mit repräsentativen Daten
Halten Sie zu jeder Änderung den Grund, den Verantwortlichen, das Datum und die Auswirkungen auf historische Datensätze fest. Die Einführung eines neuen Pflichtwerts kann eine nachträgliche Ergänzung oder eine Übergangsfrist erfordern. Speichern Sie das Mapping zusammen mit dem Code oder der Konfiguration, sodass es einem konkreten Deployment zugeordnet und sicher zurückgesetzt werden kann.
Die Testsuite umfasst gängige Fälle, diakritische Zeichen, lange Werte, unbekannte Enums, Identitätsänderungen, Zeitgrenzen und Duplikate. Vergleichen Sie das Ergebnis auf beiden Seiten sowie im Nutzerprozess. Eine technisch erfolgreiche Antwort reicht nicht aus, wenn ein Wert in der falschen Währung angezeigt oder einem anderen Kunden zugeordnet wird.
- Änderung der Bedeutung oder des Datentyps eines Feldes
- neuer Wert außerhalb der bekannten Liste
- Grenze von Zeitzone und Währung
- unvollständige historische Daten bei der Migration
- nachvollziehbares Ergebnis auf beiden Seiten
- Identitätsänderung oder Zusammenführung doppelter Objekte
- sicheres Verhalten bei fehlendem Pflichtwert
Häufige Fragen
Was ist die Single Source of Truth?
Es ist das System oder der Prozess, das bzw. der befugt ist, über eine bestimmte Angabe zu entscheiden. Es muss nicht für das gesamte Objekt dasselbe sein; beispielsweise kann das ERP den Lagerbestand und das CRM die Vertriebsnotiz verantworten.
Reicht eine Zuordnung in einer Tabelle?
Eine Tabelle ist ein gutes gemeinsames Dokument, die Implementierung braucht aber auch testbare Regeln, eine Version, einen Verantwortlichen und die Verknüpfung mit dem Code. Ohne Änderungsmanagement laufen Dokument und Betrieb schnell auseinander.
Wie geht man mit einem Wert um, den das Zielsystem nicht kennt?
Übersetzen Sie sie nicht stillschweigend. Führen Sie je nach geschäftlicher Bedeutung eine explizite Regel, eine Quarantäne oder eine Erweiterung des Ziels ein. Der Prozessverantwortliche muss entscheiden, welcher Informationsverlust akzeptabel ist.
Quellen und weiterführende Lektüre
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
