Die vier Wege des Stammdatenmanagements
Auch in 28 Sprachen
English · Español · 日本語 · Português (Brasil) · Français · 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) · Deutsch (Schweiz)
Modul 2 von 6 im Kapitel Stammdaten und Identität, Kapitel 6 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Eine Quelle der Wahrheit pro Attribut · Weiter: Abgleichen, Zusammenführen und Survivorship
Die Frage, die dieses Modul beantwortet: Wie führen Organisationen Stammdaten, und welcher Stil passt?
Modul 1 hat gesagt, Autorität wird Attribut für Attribut vergeben. Jetzt: Was tun wir, wenn diese Attribute in mehreren Systemen zugleich leben? Kundeninformationen in Salesforce, im ERP, in der Abrechnung, im Support, vielleicht in Data 360, vielleicht in einem Data Warehouse, jedes mit seiner eigenen Version. Das ist das Problem, das Stammdatenmanagement (MDM) zu lösen versucht, und MDM ist nicht eine Architektur. Sie werden von vier Mustern hören: Registry, Konsolidierung, Koexistenz und zentralisiert. Das sind keine Produkteinstellungen. Es sind vier Antworten auf eine Frage: Wie viel Autorität hat die Stammdatenschicht?
Beginnen Sie mit dem Problem, nicht mit dem Produkt
Abschnitt betitelt „Beginnen Sie mit dem Problem, nicht mit dem Produkt “Die Leute hören MDM und beginnen, ein MDM-Produkt einzukaufen. Ich würde mit dem Problem beginnen. Müssen wir nur wissen, dass mehrere Datensätze derselbe Kunde sind? Brauchen wir eine kombinierte Sicht für die Analytik? Müssen wir entscheiden, welche Werte maßgeblich sind, und sie in andere Systeme zurückschreiben? Oder wollen wir ein zentrales System, das die Stammdaten für alle anlegt? Sehr verschiedene Anforderungen, sehr verschiedene Architekturen.
Registry: Sag mir, wer wer ist
Abschnitt betitelt „Registry: Sag mir, wer wer ist “Das leichteste Muster. Eine Registry ersetzt die Quellen nicht. Das ERP behält seinen Kunden, Salesforce seinen Account, die Abrechnung ihren Kunden, und die Registry stellt fest, dass diese Datensätze dieselbe Entität darstellen: Salesforce-Account 001…, ERP-Kunde SAP-43821 und Abrechnungskunde BILL-9127 gehören zu einem Kunden. Die Quellen bleiben, wo sie sind, und werden nicht überschrieben. Jetzt hat „Zeig mir alles, was wir über diesen Kunden wissen“ eine Antwort.
Aber beachten Sie, was eine Registry nicht beantwortet. Salesforce sagt 123 Main Street, das ERP 125, die Abrechnung „123 Main St., Suite 200“. Die Registry weiß, dass sie zusammengehören. Sie entscheidet nicht, welche sich ändern sollte. Verknüpfen ist kein Stammdatenmanagement.
Nach meiner Erfahrung ist Registry die Norm in Salesforce-Projekten, dann Konsolidierung und Koexistenz; reines zentralisiertes MDM ist selten. Registry ist verbreitet, weil sie nicht invasiv ist. Sie gestalten nicht jedes operative System neu, bevor Sie Nutzen haben. Salesforce macht weiter, was es tut, das ERP macht weiter, was es tut, und Sie fügen eine Identitätsschicht hinzu. Das ist eine weit kleinere Veränderung, als jedem System zu sagen: „Ihr kontrolliert die Kundendaten nicht mehr; dieses neue zentrale System tut es.“
Die Registry beantwortet: Welche Datensätze gehören zu derselben Entität?
Konsolidierung: Führen Sie die Daten zusammen
Abschnitt betitelt „Konsolidierung: Führen Sie die Daten zusammen “Konsolidierung nimmt Daten aus mehreren Quellen und kombiniert sie in einer zentralen Darstellung, für Berichte, Analytik, Segmentierung, Kundenwissen. Ein Data Warehouse ist das vertraute Beispiel: Salesforce schickt den Kunden, das ERP die Finanzdaten, die Abrechnung die Zahlungen, und das Geschäft kann den Kunden endlich systemübergreifend analysieren. Die Quellen existieren weiter und sind vielleicht weiterhin maßgeblich. Die Richtung zählt: Daten fließen in das konsolidierte System, das meist keine geführten Änderungen zurückschreibt. Ein besseres Bild des Kunden, ohne seine operative Autorität zu werden.
Registry und Konsolidierung werden leicht verwechselt. Der Unterschied ist, was zentralisiert wird: Die Registry zentralisiert die Identität („die gehören zusammen“); die Konsolidierung zentralisiert mehr von den Daten („bringen wir die Attribute zusammen, damit wir sie nutzen können“). Keine von beiden sagt „Dieses zentrale System ist jetzt der Master, und jede Anwendung muss seine Werte übernehmen.“
Die Konsolidierung führt die Daten zusammen, ohne den Quellen die Eigentümerschaft zu nehmen.
Koexistenz: Entscheiden und zurückschicken
Abschnitt betitelt „Koexistenz: Entscheiden und zurückschicken “Bei der Koexistenz bekommt die Stammdatenschicht echte Autorität. Die Daten leben weiterhin in mehreren operativen Systemen, aber der MDM-Prozess entscheidet den geführten Wert und veröffentlicht ihn zurück. Salesforce, das ERP und die Abrechnung haben je einen anderen rechtlichen Namen; der MDM-Prozess bestimmt den gesteuerten und verteilt ihn an alle drei. Die Systeme koexistieren, aber sie laufen auf den geführten Wert zu.
Das ist eine viel stärkere Form von MDM. Sie sagt nicht „die gehören zusammen“; sie sagt „Für dieses Attribut ist das der Wert, den das Unternehmen verwendet.“ Das braucht mehr als Abgleichen: Geschäftsregeln, Eigentümerschaft, Survivorship, Integration in beide Richtungen, Fehlerbehandlung und Governance, denn jemand muss entscheiden, warum ein Wert gewinnt.
Die Koexistenz verknüpft nicht nur die Datensätze. Sie entscheidet geführte Werte und schickt sie zurück.
Zentralisiert: Der Master schafft die Wahrheit
Abschnitt betitelt „Zentralisiert: Der Master schafft die Wahrheit “Das stärkste Muster. Beim zentralisierten MDM werden die gesteuerten Stammdaten im zentralen Master angelegt und gepflegt und an alle anderen verteilt. Statt dass jedes System seinen eigenen Kunden anlegt und MDM sie danach abstimmt, legen Sie den gesteuerten Kunden im Master an und schicken ihn dann an Salesforce, das ERP und die Abrechnung. Sehr starke Governance, und sehr große Veränderung: Bestehende Prozesse legen ihre eigenen Kunden an, Benutzer haben ihre Arbeitsabläufe, Integrationen setzen ein lokales Anlegen voraus, und Geschäftsbereiche sind sich vielleicht nicht einmal einig, was ein Kunde ist. Deshalb ist es in den Salesforce-Landschaften, die ich sehe, selten. Es kann richtig sein. Es ist eine viel größere Entscheidung, als ein Werkzeug zu installieren.
Zentralisiertes MDM verlagert Anlage und Autorität in den Master.
Die vier nebeneinander
Abschnitt betitelt „Die vier nebeneinander “| Stil | Was zentralisiert wird | Bleiben die Quellen? | Schreibt gesteuerte Werte zurück? |
|---|---|---|---|
| Registry | Identität und Verknüpfungen | Ja | Meist nicht |
| Konsolidierung | Identität plus kombinierte Daten | Ja | Meist nicht |
| Koexistenz | Identität, Daten und geführte Entscheidungen | Ja | Ja |
| Zentralisiert | Anlage und Autorität | Ja, als Abnehmende | Ja |
Je weiter unten in der Tabelle, desto mehr Autorität bekommt die Stammdatenschicht, und desto mehr muss sich die Organisation meist ändern.
Prüfungswissen. Kennen Sie die vier MDM-Implementierungsstile: Registry (verknüpft Identitäten; die Quellen behalten ihre Daten), Konsolidierung (führt die Daten zusammen, meist für die Analyse), Koexistenz (entscheidet geführte Werte und veröffentlicht sie zurück an die Quellen) und zentralisiert (der Master legt die Daten an; die Quellen nutzen sie).
Es gibt also kein „Zentralisiert ist am reifsten, also sollten alle dorthin“. Wählen Sie das leichteste Muster, das das Problem löst. Müssen Sie wissen, dass Datensätze zusammengehören? Denken Sie an Registry. Eine kombinierte Sicht für die Analytik? Konsolidierung. Gesteuerte Werte, die in mehrere operative Systeme zurück synchronisiert werden? Koexistenz. Ein Prozess, der Stammdaten für alle anlegt und kontrolliert? Zentralisiert.
Wo passt Data 360 hinein?
Abschnitt betitelt „Wo passt Data 360 hinein? “Data 360 baut einheitliche Profile über viele Quellen hinweg, was sehr nach MDM klingt, und es löst tatsächlich einen Teil des Problems. Seine Identitätsauflösung gleicht Quellprofile zu einer einheitlichen Identität ab und behält die Verknüpfungen zu den Quelldatensätzen (Data 360 Architecture (opens in a new tab), auf Englisch). Damit kommt es einer Registry am nächsten. Es kann auch abgestimmte Werte im einheitlichen Profil anzeigen. Aber das macht es nicht zu einem zentralisierten Golden-Record-System, das die Quellen umschreibt. Eine einheitliche Sicht ist nicht automatisch ein geführter Unternehmensdatensatz. Um genau diesen Unterschied geht es in Modul 4.
Ein gemeinsames Modell ist keine gemeinsame Wahrheit
Abschnitt betitelt „Ein gemeinsames Modell ist keine gemeinsame Wahrheit “Sie werden auch vom kanonischen Datenmodell hören. Der Account von Salesforce, der Geschäftspartner des ERP und der Kunde der Abrechnung werden alle einem vereinbarten Unternehmenskonzept Kunde zugeordnet, mit vereinbarten Kennungen und Attributen, sodass nicht jede Integration die Form jedes anderen Systems verstehen muss. Das Datenmodell von Data 360 ist ein Beispiel dafür, Quellen zu gemeinsamen Konzepten zu harmonisieren. Aber ein kanonisches Modell beantwortet Wie stellen wir das einheitlich dar? MDM beantwortet Wie identifizieren, steuern und führen wir es systemübergreifend? Ordnen Sie alle drei Systeme perfekt einer Kundenform zu, und Salesforce sagt trotzdem 123 Main Street, während das ERP 125 sagt. Sie haben die Struktur gelöst, nicht die Autorität. Harmonisieren und Stammdatenführung sind nicht austauschbar.
Ein Geschäft, mehrere Muster
Abschnitt betitelt „Ein Geschäft, mehrere Muster “„Steve Trucking braucht MDM“ ist also keine Anforderung. Wofür? Handelspartner, Verteilzentren, Crews, Lkw, Empfänger sind verschiedene Bereiche mit verschiedenen Autoritäten: Handelspartner gesteuert in Salesforce und im Finanz-ERP, die Identität der Lkw aus FleetLink, jeder Empfänger von einem Partner für jede Lieferung geliefert. Verschiedene Bereiche können verschiedene Muster nehmen, und innerhalb eines Bereichs können Attribute verschiedene Autoritäten haben. Zeichnen Sie also keinen Kasten mit MDM in die Mitte des Diagramms und betrachten es als gelöst. Fragen Sie, was der Kasten tut.
Der Stil ändert auch die Integration. Registry braucht Identitätsverknüpfungen; Konsolidierung verlässliche eingehende Flüsse; Koexistenz Daten in beide Richtungen; zentralisiert die Verteilung aus dem Master plus Kontrollen, die andere Systeme davon abhalten, konkurrierende Wahrheit zu schaffen. Mit wachsender Autorität wächst die Koordination, und auch die Fehlerbehandlung: Was, wenn MDM den rechtlichen Namen ändert und das ERP ihn ablehnt? Deshalb sind Koexistenz und zentralisiert nicht „Registry mit mehr Funktionen“. Sie tragen andere betriebliche Verantwortungen.
MDM ist eine geschäftliche Entscheidung
Abschnitt betitelt „MDM ist eine geschäftliche Entscheidung “Der wichtigste Punkt: MDM ist im Kern keine Technologieentscheidung. Es ist eine Entscheidung über Autorität. Wer legt den Kunden an, wer darf ihn ändern, wer entscheidet, welcher Wert gewinnt, welche Systeme müssen ihn übernehmen, was passiert, wenn sie sich widersprechen. Ein Werkzeug kann diese Entscheidungen umsetzen; es kann die Organisation nicht dazu bringen, sich darauf zu einigen. Deshalb kann ein MDM-Projekt hervorragende Technologie haben und trotzdem scheitern: Das technische Team hat das Abgleichen gelöst, und das Geschäft hat nie die Eigentümerschaft gelöst.
Die allgemeine Lektion, die ich auf die harte Tour gelernt habe: Wenn mehrere Systeme dieselben Daten als Stammdaten führen, kann Salesforce nicht abstimmen, worüber sie sich nicht einig sind. Wenn ein Unternehmen zwei ERPs betreibt, frage ich, wie es sie synchron hält. Wenn es das nicht kann, kann Salesforce es auch nicht. Modul 5 erzählt diese Geschichte (Ein Kunde, zwei ERPs).
Was Architekt:innen hier entscheiden
Abschnitt betitelt „Was Architekt:innen hier entscheiden “- Ob das Problem Identitätsverknüpfungen, kombinierte Daten, zurückgeschriebene geführte Werte oder zentrale Anlage braucht.
- Welches Muster zu jedem Datenbereich passt, statt eines Musters für das ganze Unternehmen.
- Wie viel Autorität die Stammdatenschicht bekommt und welche Systeme ihre Entscheidungen übernehmen müssen.
- Ob ein kanonisches Modell nötig ist, ohne Harmonisierung mit Autorität zu verwechseln.
- Wie das gewählte Muster Integrationsrichtung, Eigentümerschaft und Fehlerbehandlung ändert.
Wenn jemand einen MDM-Kasten in ein Diagramm setzt, fragen Sie, was er tut. Weiß er, welche Datensätze zusammengehören? Kombiniert er ihre Daten? Entscheidet er, welche Werte gewinnen? Schreibt er diese Entscheidungen zurück? Legt er die Daten überhaupt erst an? Die Antworten sagen Ihnen, welche Architektur Sie wirklich haben, und wo die Autorität lebt.
Weiterlesen
Abschnitt betitelt „Weiterlesen “- Salesforce Architects, Data 360 Architecture (opens in a new tab) (auf Englisch), geprüft am 2026-10-14.