Verknüpfen ist kein Stammdatenmanagement
Auch in 28 Sprachen
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada)
Kapitel 6 von Data Architect, Teil 1: Datenarchitekt:in werden. Zurück: Datenqualität und Governance.
«Wir brauchen eine einzige Quelle der Wahrheit.» Das ist einer der meistwiederholten Sätze in der Architektur, und einer der am wenigsten hinterfragten. Wofür? Nehmen Sie einen Account. Dem ERP gehören vielleicht sein rechtlicher Name, seine Rechnungsadresse und sein Kreditlimit; Salesforce sein Account Executive und seine Supportstufe; einer Einwilligungsplattform seine Marketingpräferenzen. Drei Autoritäten auf einem Datensatz, und das ist normal. Wenn also jemand sagt «Salesforce ist unsere einzige Quelle der Wahrheit für den Kunden», lautet meine nächste Frage immer: Welche Wahrheit?
In diesem Kapitel geht es darum, diese Frage bewusst zu beantworten. Autorität wird Attribut für Attribut vergeben. Datensätze zu verknüpfen heisst nicht, sie als Stammdaten zu führen. Und Salesforce gibt Ihnen verschiedene Werkzeuge für verschiedene Aufgaben: Duplikatverwaltung und Zusammenführen innerhalb einer Org; Identitätsauflösung in Data 360 für eine Sicht über Quellen hinweg; eine eigene MDM-Plattform, wenn Werte einmal entschieden und überallhin zurückgeschrieben werden müssen. Es endet mit Checkpoint 1, wo Teil 1 bei Steve Trucking zusammenkommt.
Mit KI erstelltes Bild.
Die Positionen in diesem Kapitel
Abschnitt betitelt „Die Positionen in diesem Kapitel “- Wahrheit pro Attribut. Fragen Sie, wo jedes Datum angelegt, bearbeitet und referenziert wird, und wie schnell es sich ändert. Zeigen Sie externe Autorität im Schema mit einem Systempräfix, etwa
sap_odererp_. - Interessenten sind anders. Sie leben in Salesforce, bevor das ERP sie kennt; die Autorität des ERP gilt nach der Umwandlung.
- Registry ist die Norm in Salesforce-Projekten, dann Konsolidierung und Koexistenz; reines zentralisiertes MDM ist selten.
- Führen Sie nur mit einem klaren Gewinner zusammen. Behalten Sie Duplikate aus externen Ladevorgängen, wenn Sie vielleicht zurückverfolgen müssen; das Zusammenführen zerstört diese Historie. Und entscheiden Sie, was mit den untergeordneten Datensätzen passiert: verschieben, nicht laden oder an einem inaktiven Datensatz belassen.
- Ein einheitliches Profil ist eine Karte; ein Golden Record ist eine Entscheidung. Das kann verwirrend sein: Die Identitätsauflösung erzeugt eine einheitliche Einzelperson, aber keinen Golden Record.
- Die Strenge des Abgleichs ist eine Risikoentscheidung. Wo Vermischung teuer ist, gleichen Sie absichtlich zu wenig ab.
- Drei Werkzeuge für drei Aufgaben: Zusammenführen, Identitätsauflösung, MDM.
- Hierarchien haben geteilte Stammdatenhoheit. Entscheiden Sie die Autorität Zweig für Zweig.
- «Das Schwierigste sind die bidirektionalen.» Eine Integration in beide Richtungen macht nicht zwei Master. Entscheiden Sie vor der ersten Kollision, welche Felder als eine Transaktion gemeinsam reisen.
- Machen Sie Stammdaten sichtbar. Ein Feld, das sagt «Das sind Stammdaten» (der Schlüssel des ERP oder ein Kennzeichen), steuert die Bearbeitbarkeit, nicht ein Datensatztyp.
- Die ERPs kontrollieren wir nicht. Wir kontrollieren, wie wir sie in Salesforce darstellen: Ein Kunde in zwei ERPs wird zu einer Hierarchie, zu gleichrangigen Accounts oder zu einem Account mit einem untergeordneten Datensatz pro ERP, entschieden danach, wie gut der Kunde seine ERPs synchron hält.
Drei Werkzeuge für drei Aufgaben
Abschnitt betitelt „Drei Werkzeuge für drei Aufgaben “| Die Aufgabe | Das Werkzeug | Was es mit den Quellen tut |
|---|---|---|
| Duplikate innerhalb einer Org, mit klarem Gewinner | Duplikatverwaltung und Zusammenführen | Führt bis zu drei Datensätze zusammen; die anderen landen im Papierkorb |
| Eine Identität und eine einheitliche Sicht über Quellen hinweg | Identitätsauflösung in Data 360 | Verknüpft sie; ändert keine davon (eine Registry) |
| Ein gesteuerter Wert, zurückgeschrieben in jedes System | Eine eigene MDM-Plattform | Entscheidet den Wert und verteilt ihn (Koexistenz oder zentralisiert) |
Der Weg durch dieses Kapitel
Abschnitt betitelt „Der Weg durch dieses Kapitel “Sechs Module und eine Herausforderung, jedes steht für sich.
- Eine Quelle der Wahrheit pro Attribut. Die Autoritätskarte, der hybride Golden Record und Vertrauenssignale.
- Die vier Wege des Stammdatenmanagements. Registry, Konsolidierung, Koexistenz und zentralisiert, und warum ein gemeinsames Modell keine gemeinsame Wahrheit ist.
- Abgleichen, Zusammenführen und Survivorship. Der Preis eines falschen Treffers, was ein Zusammenführen in Salesforce wirklich tut (und was mit den untergeordneten Datensätzen passiert), und Survivorship als Aussage über Vertrauen.
- Eine Karte ist keine Entscheidung. Abgleichsregeln und Abgleichsmethoden, Abstimmungsregeln und warum ein einheitliches Profil kein Golden Record ist.
- Wenn die Autorität geteilt ist. Anfragen gegenüber Aktualisierungen, Schleifen und Kollisionen, Hierarchien mit geteilter Stammdatenhoheit und ein Kunde in zwei ERPs.
- Die Herausforderung zu Checkpoint 1, dann Checkpoint 1: Steve Trucking, was ich entwerfen würde. Versuchen Sie zuerst die Herausforderung: Zeichnen und verteidigen Sie den Entwurf von Teil 1, vergleichen Sie ihn dann mit meinem und sehen Sie, was sich gegenüber der Landschaft aus Kapitel 4 ändert.
Wenn Sie fertig sind, prüfen Sie sich mit dem Lernleitfaden zum Kapitel: eine Checkliste für die Prüfung, die Gewohnheiten darüber hinaus, die wichtigsten Begriffe und ein paar Fragen. Er schliesst Teil 1 ab; der Lernleitfaden zu Teil 1 führt alle sechs Kapitel zusammen.
Was Architekt:innen hier entscheiden
Abschnitt betitelt „Was Architekt:innen hier entscheiden “- Welches System für jedes wichtige Attribut massgeblich ist und wie das im Modell sichtbar wird.
- Welcher Stil des Stammdatenmanagements zu jedem Datenbereich passt und wie viel Autorität die Stammdatenschicht bekommt.
- Wann zusammenführen, wann verknüpfen, und wem jede Survivorship-Regel gehört.
- Wie streng der Abgleich sein sollte, je nachdem, was ein falscher Treffer kostet.
- Wo Daten in beide Richtungen und geteilte Hierarchien ausdrückliche Grenzen brauchen.
Über die Prüfung hinaus: Agenten brauchen eine Identität, auf die sie handeln, und das erhöht den Einsatz in beide Richtungen. Zu grosszügiges Abgleichen wird zum Datenschutzvorfall, und ein Agent, der «den Kunden aktualisiert», muss in das führende System jedes Attributs schreiben, nicht in das einheitliche Profil. Jedes Modul endet mit dem, was KI ändert.
Weiterlesen
Abschnitt betitelt „Weiterlesen “- Salesforce Architects, Data 360 Architecture (opens in a new tab) (auf Englisch), geprüft am 2026-10-14.
- Salesforce-Hilfe, Considerations for Merging Duplicate Accounts (opens in a new tab), Identity Resolution Match Methods (opens in a new tab) und Identity Resolution Reconciliation Rules (opens in a new tab) (auf Englisch), geprüft am 2026-10-14.
Weiter: Teil 2 beginnt mit Designing for Scale (coming soon).