Hierarchien und Daten in beide Richtungen

🌐 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)

Mit KI erstelltes Bild

Von KI übersetzt. Noch nicht von der Community geprüft. Auf Englisch lesen

Modul 5 von 6 im Kapitel Stammdaten und Identität, Kapitel 6 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Eine Karte ist keine Entscheidung · Weiter: Checkpoint 1: Steve Trucking

Die Frage, die dieses Modul beantwortet: Wie verwalten Sie Daten, die mehr als ein System pflegt?

Die einfache Architektur: Dem ERP gehört der Kunde, Salesforce bekommt eine Kopie, fertig. Echte Unternehmen sind nicht so sauber. Dem ERP gehört der rechtliche Kunde und Salesforce die Vertriebsbeziehung; eine Sparte lebt in SAP, eine übernommene in einem anderen ERP; Interessenten existieren nur in Salesforce. Dann will jemand, dass Salesforce-Benutzer ein vom ERP kontrolliertes Feld aktualisieren, und die Pfeile beginnen in beide Richtungen zu zeigen. Wie ich es im Unterricht sage: „Das Schwierigste sind die bidirektionalen.“ Nicht weil es technisch schwer ist, Daten in beide Richtungen zu schicken, sondern weil Sie, sobald beide Systeme an Änderungen beteiligt sind, bei der Autorität extrem genau sein müssen.

Daten in beide Richtungen heißen nicht zwei Master

Dem ERP gehört die Rechnungsadresse, in Salesforce kopiert. Jemand aus dem Vertrieb erfährt vom Kunden, dass sie sich geändert hat, und das Geschäft will, dass sie ohne Verlassen von Salesforce aktualisiert wird. Vernünftig. Jetzt fließen Daten ERP → Salesforce und Salesforce → ERP. Gehört die Rechnungsadresse jetzt Salesforce mit? Nein. Die Richtung einer Integration entscheidet nicht über die Autorität. Der Vertrieb ändert nicht die Kopie von Salesforce. Architektonisch bittet er darum, den maßgeblichen Wert zu ändern. Sie ändern nicht das Feld des ERP; Sie bitten darum, es zu ändern. Salesforce ist die Oberfläche; das ERP bleibt der Master.

Das ändert den Entwurf. Gehörte das Feld Salesforce, speichern und fertig. Gehört es dem ERP, heißt „speichern“: Salesforce schickt die vorgeschlagene Adresse, das ERP prüft und nimmt sie an, aktualisiert seinen Master und schickt den maßgeblichen Wert zurück. Erst dann hat sich der gesteuerte Wert geändert: anfragen → prüfen → annehmen → veröffentlichen, nicht „beide Systeme aktualisieren und hoffen, dass sie synchron bleiben“.

Click to enlarge

Eine Integration in beide Richtungen schafft keine Autorität in beide Richtungen.

Wenn der Master Nein sagt

Das ERP lehnt die Änderung ab: Der Kunde ist inaktiv, die Adresse verletzt eine ERP-Regel, der Benutzer darf rechtliche Adressen nicht ändern, das ERP ist ausgefallen, oder jemand anderes hat den Kunden in der Zwischenzeit geändert. Wenn Salesforce die neue Adresse schon angezeigt hat, haben wir jetzt zwei Wahrheiten, und Modul 1 hat uns schon gesagt, welche gewinnt: die des ERP. Die Architektur braucht also einen Zustand für angefragt, noch nicht angenommen: einen getrennten vorgeschlagenen Wert, ein Kennzeichen „ausstehende Änderung“ oder das Warten auf Bestätigung, bevor er angezeigt wird. Der Mechanismus hängt vom Anwendungsfall ab. Die Regel nicht: Lassen Sie eine abgelehnte Anfrage nie zu konkurrierender Wahrheit werden.

Schleifen und Kollisionen

Hier ein Klassiker. Das ERP aktualisiert Salesforce; die Integration von Salesforce sieht eine Änderung und schickt sie ans ERP; das ERP sieht eine Aktualisierung und schickt sie zurück. Sie haben eine sehr teure Schleife gebaut. Ein guter Entwurf in beide Richtungen weiß, wo eine Änderung begonnen hat, ob der Master sie angenommen hat und ob es eine neue geschäftliche Änderung ist oder nur das Echo einer schon verarbeiteten: Quellkennungen, Zeitstempel, Integrationsmetadaten, idempotente Verarbeitung. Das Integrationskapitel geht in die Tiefe. Das Stammdatenprinzip ist einfach: Wissen Sie, ob Sie eine Änderung auslösen oder eine widerspiegeln.

Dann Kollisionen. Eine kennen Sie aus Kapitel 5: Jemand aus dem Vertrieb beantragt Steve’s Plumbing LLC, während jemand im ERP Steve’s Plumbing L.L.C. eintippt (Schützen Sie den gesteuerten Datensatz). Hier ist eine weitere. Salesforce schlägt 125 Main Street vor; fast im selben Moment ändert ein ERP-Benutzer sie auf 130. Welche gewinnt? Es gibt keine allgemeine technische Antwort. Vielleicht gewinnt immer das ERP, weil ihm das Feld gehört; vielleicht geht die Salesforce-Anfrage in eine Prüfwarteschlange; vielleicht gewinnt die später angenommene Änderung; vielleicht lehnt das ERP jede Aktualisierung ab, deren Ausgangswert sich geändert hat. Das ist Nebenläufigkeit, aber darunter liegt eine Autoritätsentscheidung, und kein Integrationsmuster kann Sie retten, wenn niemand entschieden hat, wer die maßgebliche Änderung vornehmen darf.

Und ein einzelnes Feld ist der einfache Fall. Eine Adresse besteht aus Straße, Ort und Postleitzahl. Salesforce schickt eine neue Straße, während das ERP gerade den Ort geändert hat. Lassen Sie die Straße allein durch? Oder behandeln Sie die Adresse als eine Transaktion, sodass alle Felder gemeinsam gehen oder keines, und lehnen die gesamte Änderung ab? Entscheiden Sie vor der ersten Kollision, welche Felder als Gruppe reisen, nicht danach.

Wann immer ich eine Integration in beide Richtungen sehe, frage ich: Was passiert, wenn beide Seiten dieselben Daten ändern? Wenn die Antwort lautet „Das wird wohl nicht passieren“, sind wir nicht fertig. Welche gewinnt, lehnen wir ab, stellen wir in eine Warteschlange, vergleichen wir Versionen, prüfen wir? Sollte das Feld überhaupt an beiden Orten bearbeitbar sein? Manchmal entfernt der beste Entwurf in beide Richtungen für ein bestimmtes Attribut eine Richtung: Salesforce darf anfragen; nur das ERP veröffentlicht den angenommenen Wert. Daten bewegen sich weiterhin in beide Richtungen, aber nur ein System führt das Feld als Stammdatum. Dieser Unterschied ist alles.

Auch Hierarchien sind Stammdaten

Auch Beziehungen können Stammdaten sein. Eine globale Muttergesellschaft mit Regionen Nordamerika und Europa, jede mit Landesgesellschaften: Die Hierarchie selbst trägt Bedeutung. Wer ist die Muttergesellschaft? Welche Tochter gehört zu welcher juristischen Person? Welche Accounts laufen beim globalen Kunden zusammen? Das steuert Berichte, Gebiete, Preise, Verträge, Kreditrisiko, Service, Datenzugriff und Analytik. Eine Hierarchie kann so wichtig sein wie die Datensätze darin, und sie braucht dieselbe Governance. (Die Prüfung nennt das Hierarchiemanagement; man vergisst es leicht.)

Auf Salesforce werden Account-Hierarchien mit dem Feld Übergeordneter Account gebaut. Die Lightning-Hierarchieansicht zeigt bis zu 2.000 Accounts, und nur die, die der Benutzer sehen darf; Personenaccounts werden in der Hierarchie nicht unterstützt; und Account-Standort unterscheidet die Standorte eines Unternehmens (Considerations for Using Account Hierarchy (opens in a new tab), auf Englisch). Aber das Feld Übergeordneter Account beantwortet nicht die Architekturfrage: Wem gehört die Hierarchie?

Prüfungswissen. Kennen Sie die Grundlagen der Account-Hierarchie: Sie wird mit Übergeordneter Account (Parent Account) gebaut; die Lightning-Ansicht zeigt bis zu 2.000 Accounts, nur diejenigen, die der Benutzer sehen kann; Personenaccounts werden nicht unterstützt; und Account-Standort (Account Site) unterscheidet die Standorte eines Unternehmens.

Eine Hierarchie, mehrere Master

Nach meiner Erfahrung haben Hierarchien geteilte Stammdatenhoheit. Die nordamerikanischen Gesellschaften kommen aus SAP, die europäischen aus einem anderen ERP, neue Interessenten werden in Salesforce aufgebaut, und eine übernommene Tochter ist noch nicht migriert. Wem gehört die Hierarchie? Es hängt vom Zweig ab. Jedes ERP kontrolliert seinen Zweig; Salesforce kontrolliert die Beziehungen der Interessenten, bis sie umgewandelt werden. Das ist eine legitime Architektur, solange alle wissen, wo die Grenzen sind. Entscheiden Sie pro Zweig.

Click to enlarge

Die Autorität über eine Hierarchie lässt sich Zweig für Zweig zuweisen.

Lassen Sie also nicht zu, dass das Feld Übergeordneter Account die Autorität verbirgt. Ein Benutzer hängt eine Tochter in Salesforce um. Technisch trivial. Architektonisch: Hat er gerade die rechtliche Struktur des Unternehmens geändert? Wenn das ERP diesen Zweig führt, wahrscheinlich nicht, also sollte Salesforce es blockieren oder in eine Änderungsanfrage verwandeln. Oder vielleicht hält Salesforce legitimerweise eine kommerzielle Hierarchie, während das ERP die rechtliche hält. Dann sollten sie vielleicht gar nicht dieselbe Beziehung sein.

Ein Unternehmen kann mehrere gültige Hierarchien haben: rechtlich, Abrechnung, Vertrieb, Service, geografisch. Die globale Muttergesellschaft unterschreibt den Vertrag, Regionen bekommen eigenen Service, die Abrechnung läuft über eine gemeinsame Finanzgesellschaft, der Vertrieb steuert nach Region. Welche ist die wahre Hierarchie? Alle; sie beantworten verschiedene Fragen. Der Fehler ist anzunehmen, es müsse eine geben. Es sollte für jede Art von Beziehung eine klare Autorität geben: das Attributprinzip aus Modul 1, angewandt auf Beziehungen.

Und nicht jede Eltern-Kind-Beziehung ist ein Stammdatum. Die heutigen Lieferungen auf einer Tour zu gruppieren ist eine Beziehung, aber eine Bewegung, ein operatives Ereignis. Eine Kundenhierarchie beschreibt eine dauerhafte Geschäftsbeziehung. Beide sehen im Modell aus wie Eltern-Kind; sie teilen keinen Lebenszyklus. Fragen Sie, was die Beziehung bedeutet und wie lange diese Bedeutung hält.

Ein Kunde, zwei ERPs

Wenn ich das unterrichte, frage ich in die Runde: Wer hat schon mit einem Kunden gearbeitet, der eine Salesforce-Org und mehr als ein ERP hat? Jedes Mal gehen Hände hoch. Fragen Sie nach dem Warum, und es zeigt sich, dass die ERPs regional aufgeteilt sind (eines für Nordamerika, eines für Europa), funktional (ein Sanitärunternehmen kauft ein Elektrounternehmen, und jedes behält sein eigenes ERP) oder einfach historisch: Das Geschäft wurde übernommen, und niemand hat es bisher migriert.

Nehmen Sie Steve’s Plumbing als Kunden. Das Unternehmen ist in Nordamerika tätig, also hat das nordamerikanische ERP einen Kundendatensatz dafür. Dann eröffnet es ein Büro in München, und das europäische ERP legt einen eigenen Kundendatensatz an, mit eigener Kundennummer. Dasselbe Unternehmen, zwei Datensätze, zwei IDs. Wie stelle ich das in einer Salesforce-Org dar? Ich habe drei Wege gesehen.

Eine Account-Hierarchie. Steve’s Plumbing ist der übergeordnete Account, mit Steve’s Plumbing North America und Steve’s Plumbing Europe als untergeordneten Accounts, von denen jeder für den Datensatz eines ERP steht. Der Haken: Die untergeordneten Accounts sind nicht mehr wirklich Steve’s Plumbing. Sie sind Steve’s Plumbing, tätig in einer Region, und wie wir gerade gesehen haben, trägt eine Hierarchie Bedeutung.

Gleichrangige Accounts. Zwei Accounts nebeneinander, jeder mit einem Feld, das sagt, zu welchem ERP er gehört: ein Buchungskreis, eine Region. Nichts ist versteckt. Die Kosten zeigen sich im Reporting: Um Steve’s Plumbing weltweit zu sehen, brauchen Sie etwas, das sagt, dass diese beiden Accounts dasselbe Unternehmen sind.

Ein Account, mit einem untergeordneten Datensatz pro ERP. Ein Steve’s Plumbing und ein untergeordnetes Objekt mit einem Datensatz pro ERP, der die Kunden-ID dieses ERP hält. Zwei ERPs oder zehn. Der Vertrieb sieht einen Kunden und erfasst einen Auftrag; im Hintergrund entscheiden Flows, an welches ERP jede Position geht: Elektroarbeiten an das Elektro-ERP, Sanitärarbeiten an das Sanitär-ERP. Aber jetzt müssen Sie entscheiden, welches ERP für die gemeinsamen Werte wie Name und Adresse primär ist, und was passiert, wenn der Kunde in einem ERP existiert und im anderen nicht.

Click to enlarge

Ein Kunde, zwei ERPs: drei Wege, ihn in Salesforce darzustellen.

Fragen Sie, wie die ERPs synchron gehalten werden

Also welcher? Zuerst: Wie viel von der ERP-Struktur soll der Vertrieb sehen? Wenn die Leute im Vertrieb immer gewusst haben, dass Nordamerika und Europa getrennte Geschäfte sind, weil sie sich am einen oder am anderen ERP anmelden, verstecken Sie es nicht vor ihnen. Übernehmen Sie diese Struktur als gleichrangige Accounts in Salesforce. Wenn das Geschäft dem Vertrieb ein einziges Steve’s Plumbing zeigen will, läuft es auf einen Account mit einem untergeordneten Datensatz pro ERP hinaus.

Dann die Frage, die es wirklich entscheidet, und sie wird nicht in Salesforce entschieden. Ich frage den Kunden: Wie halten Sie diese beiden Datensätze zwischen Ihren ERPs synchron? Nicht das, was in jedem ERP lokal ist, wie den Saldo; das sind Bewegungsdaten. Ich meine die Stammdaten: den rechtlichen Namen, die Adressen. Wenn er ein Team hat, das die beiden ERPs synchron hält, können wir sie zu einem Account zusammenführen. Wenn er sie nicht einmal in seinen eigenen ERPs synchron halten kann, wie kann er erwarten, dass wir sie in Salesforce synchron halten? Dann sind es gleichrangige Accounts oder eine Hierarchie.

Denken Sie daran, was ein ERP ist. Das sind riesige Systeme, deren Einführung Jahre dauert, und sie bringen ihre eigene Art mit, Stammdaten zu verwalten. Salesforce wird sie nicht steuern. Die ERPs kontrollieren wir nicht. Wir kontrollieren, wie wir sie in Salesforce darstellen.

MDM in der Mitte

Manche Kunden haben das schon gelöst, bevor wir kommen. Ein großes Unternehmen, viele Jahre im Geschäft, mehrere ERPs: Sie sind lange vor Salesforce auf dieses Problem gestoßen und haben ein eigenes MDM-Produkt in die Mitte gesetzt, das zwischen den ERPs vermittelt. Das ist das Koexistenz- oder zentralisierte MDM aus Modul 2. Jetzt verdrahtet sich Salesforce nicht mit jedem ERP. Es zeigt auf einen Ort, den MDM-Hub, und bekommt eine einzige Darstellung des Kunden. Rechnen Sie aber nicht damit, so etwas oft zu sehen. Das sind große Implementierungen für sich; in all meinen Jahren habe ich nur zwei- oder dreimal mit einem gearbeitet. Und selbst mit dem Hub brauchen Sie vielleicht noch das untergeordnete Objekt, damit jeder Auftrag weiß, an welches ERP er geht.

Click to enlarge

MDM in der Mitte: Salesforce zeigt auf einen Ort.

Steve Trucking: Wessen Hierarchie?

Ein Handelspartner hat seine eigene Struktur: Konzernmutter, regionale Sparten, Verteilzentren, Filialen. Gehört diese Hierarchie Steve Trucking? Nein; der Partner ist die Autorität für seine eigene Organisation. Aber Steve Trucking braucht vielleicht eine eigene kommerzielle Sicht auf dieselben Standorte, für Verträge, Account-Management, Service und Berichte, vielleicht einen untergeordneten Account für jedes Verteilzentrum unter dem Partner. Zwei legitime Hierarchien, zwei Autoritäten. Benennen Sie sie, und tun Sie nicht so, als stelle ein Baum jede Beziehung dar.

Machen Sie die Grenzen sichtbar

Wann immer die Autorität geteilt ist, will ich die Grenze sichtbar: Feldbenennung, Datensatzmetadaten, Kennungen des Quellsystems, Berechtigungen, Integrationsverhalten, Dokumentation. Was ich nicht will, ist, dass jemand im Entwicklungsteam fünf Integrationen liest, um zu entdecken: „Diese Werte von Übergeordneter Account kommen aus SAP, außer bei Interessenten, außer in Europa.“ Das ist kein wartbares Autoritätsmodell. Wenn die Hierarchie geteilte Stammdatenhoheit hat, dokumentieren Sie die Teilung. Wenn sich die Autorität bei der Umwandlung ändert, dokumentieren Sie die Änderung. Wenn Salesforce eine Änderung anfragen, aber nicht vornehmen darf, machen Sie das im Erlebnis offensichtlich.

In Salesforce beginnt das mit einem Feld. Es braucht ein Feld, das klar sagt: Das sind Stammdaten: den Schlüssel des ERP oder ein Kennzeichen „ist Stammdatum“. Steuern Sie die Bearbeitbarkeit der Felder über dieses Feld, nicht über einen Datensatztyp; mit Dynamic Forms brauchen Sie keinen Datensatztyp mehr, um die Felder des ERP schreibgeschützt anzuzeigen (Kapitel 5, Ein Datensatztyp pro Datenfluss). Sie können erlauben, dass Datensätze außerhalb des Masters angelegt werden, aber achten Sie auf die Bearbeitungen.

Über die Prüfung hinaus: Was KI ändert. Ein Kunde sagt einem Agenten: „Ändern Sie unsere Rechnungsadresse auf 125 Main Street.“ Das Feld ist direkt da in Salesforce. Sollte der Agent es aktualisieren? Nicht, wenn es dem ERP gehört. Ein Agent braucht Schreibautorität, nicht nur Feldzugriff: Seine Aktion sollte den genehmigten Weg abbilden, eine Änderungsanfrage einreichen und sagen „Ich habe die Änderung zur Bearbeitung eingereicht“, nicht fälschlich melden „Ich habe Ihre Rechnungsadresse aktualisiert.“

Was Architekt:innen hier entscheiden

• Ob eine Bearbeitung in Salesforce maßgebliche Daten ändert oder eine Änderung bei dem System anfragt, dem sie gehören.
• Wie Flüsse in beide Richtungen auslösende Änderungen von Echos unterscheiden und mit Ablehnung, Kollisionen, Latenz und Ausfall umgehen.
• Wem jede Hierarchie gehört, wenn nötig Zweig für Zweig.
• Für einen Kunden, der in mehreren ERPs geführt wird: eine Hierarchie, gleichrangige Accounts oder ein Account mit einem untergeordneten Datensatz pro ERP, entschieden danach, wie gut der Kunde seine ERPs synchron hält.
• Ob konkurrierende Hierarchien in Wahrheit verschiedene legitime Beziehungen sind: rechtlich, Abrechnung, Vertrieb, Service.
• Wie Autoritätsgrenzen und genehmigte Schreibwege für Benutzer, Integrationen, Entwicklungsteams und Agenten sichtbar gemacht werden.

Geteilte Autorität ist nicht das Problem. Unklare Autorität ist es. Mehrere ERPs können verschiedene Zweige führen, Salesforce kann manche Attribute führen und für andere Änderungen anfragen, und mehrere Hierarchien können ein Unternehmen beschreiben. Das alles funktioniert, solange Sie für jedes wichtige Attribut und jede wichtige Beziehung sagen können, wem es gehört, wer es ändern darf, wo die maßgebliche Änderung vorgenommen wird und was passiert, wenn Systeme sich widersprechen. Wenn Sie das nicht können, repariert es kein weiterer Pfeil in beide Richtungen im Diagramm.

Weiterlesen

• Salesforce-Hilfe, Considerations for Using Account Hierarchy (opens in a new tab) (auf Englisch), geprüft am 2026-10-14.