De fire måder at håndtere masterdata på

🌐 Findes også på 28 sprog

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 · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Billedet er lavet med AI

Oversat med AI. Fællesskabet har endnu ikke gennemgået oversættelsen. Læs på engelsk

Modul 2 af 6 i kapitlet Masterdata og identitet, kapitel 6 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Én sandhedskilde pr. attribut · Næste: Matchning, sammenfletning og overlevelsesregler

Spørgsmålet, dette modul besvarer: Hvordan håndterer organisationer masterdata, og hvilken stil passer?

Modul 1 sagde, at autoritet tildeles attribut for attribut. Nu: Hvad gør vi, når de attributter lever i flere systemer på én gang? Kundeoplysninger i Salesforce, ERP’et, fakturering, support, måske Data 360, måske et datavarehus, hver med sin egen version. Det er det problem, master data management (MDM) forsøger at løse, og MDM er ikke én arkitektur. Du kommer til at høre om fire mønstre: register (registry), konsolidering, sameksistens (coexistence) og centraliseret. De er ikke produktindstillinger. De er fire svar på ét spørgsmål: Hvor meget autoritet har masterlaget?

Start med problemet, ikke produktet

Folk hører MDM og begynder at shoppe efter et MDM-produkt. Jeg ville starte med problemet. Skal vi bare vide, at flere poster er den samme kunde? Har vi brug for ét samlet billede til analyse? Skal vi beslutte, hvilke værdier der er autoritative, og sende dem tilbage til andre systemer? Eller vil vi have ét centralt system, der opretter masterdata for alle? Meget forskellige krav, meget forskellige arkitekturer.

Register: fortæl mig, hvem der er hvem

Det letteste mønster. Et register erstatter ikke kilderne. ERP’et beholder sin kunde, Salesforce sin konto, faktureringen sin kunde, og registeret finder ud af, at disse poster repræsenterer den samme enhed: Salesforce-kontoen 001…, ERP-kunden SAP-43821 og faktureringskunden BILL-9127 hører til én kunde. Kilderne bliver, hvor de er, og bliver ikke overskrevet. Nu har »vis mig alt, hvad vi ved om denne kunde« et svar.

Men læg mærke til, hvad et register ikke svarer på. Salesforce siger 123 Main Street, ERP’et 125, faktureringen »123 Main St., Suite 200«. Registeret ved, at de hører sammen. Det beslutter ikke, hvilken der skal ændres. At linke er ikke at mastere.

Min erfaring er, at register er normen på Salesforce-projekter, derefter konsolidering og sameksistens; ren centraliseret MDM er sjælden. Register er almindeligt, fordi det ikke griber ind i noget. Du redesigner ikke hvert operationelt system, før du får værdi. Salesforce bliver ved med at gøre det, den gør, ERP’et bliver ved med at gøre det, det gør, og du tilføjer et identitetslag. Det er en langt mindre ændring end at sige til hvert system: »Du styrer ikke længere kundedata; det gør dette nye centrale system.«

Click to enlarge

Registeret svarer på: Hvilke poster hører til den samme enhed?

Konsolidering: saml dataene

Konsolidering tager data fra flere kilder og kombinerer dem i en central repræsentation til rapportering, analyse, segmentering og kundeindsigt. Et datavarehus er det velkendte eksempel: Salesforce sender kunden, ERP’et økonomien, faktureringen betalingerne, og forretningen kan endelig analysere kunden på tværs af systemer. Kilderne findes stadig og kan stadig være autoritative. Retningen er vigtig: Data flyder ind i det konsoliderede system, som normalt ikke sender masterændringer tilbage. Et bedre billede af kunden, uden at blive dens operationelle autoritet.

Register og konsolidering er lette at forveksle. Forskellen er, hvad der centraliseres: Et register centraliserer identitet (»disse hører sammen«); konsolidering centraliserer mere af dataene (»saml attributterne, så vi kan bruge dem«). Ingen af dem siger: »Dette centrale system er nu masteren, og hver applikation skal acceptere dets værdier.«

Click to enlarge

Konsolidering samler dataene uden at tage ejerskabet fra kilderne.

Sameksistens: beslut, og send det tilbage

Ved sameksistens får masterlaget reel autoritet. Dataene lever stadig i flere operationelle systemer, men MDM-processen beslutter masterværdien og publicerer den tilbage. Salesforce, ERP’et og faktureringen har hver et forskelligt juridisk navn; MDM-processen fastlægger det styrede og distribuerer det til alle tre. Systemerne eksisterer side om side, men de konvergerer mod masterværdien.

Det er en meget stærkere form for MDM. Den siger ikke »disse hører sammen«; den siger »for denne attribut er dette den værdi, virksomheden bruger«. Det kræver mere end matchning: forretningsregler, ejerskab, overlevelsesregler, tovejsintegration, fejlhåndtering og styring, for nogen skal beslutte, hvorfor én værdi vinder.

Click to enlarge

Sameksistens linker ikke bare posterne. Den beslutter masterværdier og sender dem tilbage.

Centraliseret: masteren skaber sandheden

Det stærkeste mønster. Ved centraliseret MDM bliver de styrede masterdata oprettet og vedligeholdt i den centrale master og distribueret til alle andre. I stedet for at hvert system opretter sin egen kunde, og MDM afstemmer dem bagefter, opretter du den styrede kunde i masteren og sender den derefter til Salesforce, ERP’et og faktureringen. Meget stærk styring og en meget betydelig forandring: Eksisterende processer opretter deres egne kunder, brugerne har deres arbejdsgange, integrationerne forudsætter lokal oprettelse, og forretningsenhederne er måske ikke engang enige om, hvad en kunde er. Derfor er det sjældent i de Salesforce-landskaber, jeg ser. Det kan være det rigtige. Det er en langt større beslutning end at installere et værktøj.

Click to enlarge

Centraliseret MDM flytter oprettelse og autoritet ind i masteren.

De fire side om side

Stil	Hvad der centraliseres	Bliver kilderne?	Sender styrede værdier tilbage?
Register	Identitet og links	Ja	Normalt ikke
Konsolidering	Identitet plus samlede data	Ja	Normalt ikke
Sameksistens	Identitet, data og masterbeslutninger	Ja	Ja
Centraliseret	Oprettelse og autoritet	Ja, som forbrugere	Ja

Jo længere ned i tabellen, jo mere autoritet får masterlaget, og jo mere skal organisationen som regel ændre sig.

Eksamensviden. Kend de fire implementeringsstile for MDM: register (linker identiteter; kilderne beholder deres data), konsolidering (samler dataene, som regel til analyse), sameksistens (beslutter masterværdier og publicerer dem tilbage til kilderne) og centraliseret (masteren opretter dataene; kilderne forbruger dem).

Så der findes ikke noget med »centraliseret er mest modent, så alle bør nå dertil«. Vælg det letteste mønster, der løser problemet. Skal du vide, at poster hører sammen? Tænk register. Et samlet billede til analyse? Konsolidering. Styrede værdier synkroniseret tilbage til flere operationelle systemer? Sameksistens. Én proces, der opretter og styrer masterdata for alle? Centraliseret.

Hvor passer Data 360 ind?

Data 360 bygger samlede profiler på tværs af mange kilder, hvilket lyder meget som MDM, og den løser også en del af problemet. Dens identitetsopløsning matcher kildeprofiler til en samlet identitet og beholder linkene tilbage til kildeposterne (Data 360 Architecture (opens in a new tab), på engelsk). Det placerer den tættest på et register. Den kan også vise afstemte værdier på den samlede profil. Men det gør den ikke til et centraliseret golden record-system, der omskriver kilderne. Et samlet billede er ikke automatisk en mastered virksomhedspost. Modul 4 handler om netop den forskel.

En fælles model er ikke en fælles sandhed

Du vil også høre om en kanonisk datamodel. Salesforces konto (Account), ERP’ets forretningspartner og faktureringens kunde mappes alle til ét aftalt virksomhedsbegreb, Customer, med aftalte identifikatorer og attributter, så hver integration ikke behøver at forstå alle andre systemers form. Datamodellen i Data 360 er et eksempel på at harmonisere kilder til fælles begreber. Men en kanonisk model svarer på, hvordan vi repræsenterer det konsistent. MDM svarer på, hvordan vi identificerer, styrer og masterer det på tværs af systemer. Map alle tre systemer perfekt ind i én Customer-form, og Salesforce siger stadig 123 Main Street, mens ERP’et siger 125. Du har løst strukturen, ikke autoriteten. At harmonisere og at mastere er ikke det samme.

Én virksomhed, flere mønstre

Så »Steve Trucking har brug for MDM« er ikke et krav. Til hvad? Detailpartnere, distributionscentre, teams, lastbiler og modtagere er forskellige domæner med forskellige autoriteter: detailpartnere styret i Salesforce og økonomiafdelingens ERP, lastbilernes identitet fra FleetLink, hver modtager leveret af en partner for hver levering. Forskellige domæner kan få forskellige mønstre, og inden for et domæne kan attributter have forskellige autoriteter. Så tegn ikke en boks med teksten MDM midt i diagrammet og kald det løst. Spørg, hvad boksen gør.

Stilen ændrer også integrationen. Et register har brug for identitetslinks; konsolidering for pålidelige indgående flows; sameksistens for data i begge retninger; centraliseret for distribution fra masteren plus kontroller, der forhindrer andre systemer i at skabe en konkurrerende sandhed. Når autoriteten vokser, vokser koordineringen også, og det samme gør fejlhåndteringen: Hvad hvis MDM ændrer det juridiske navn, og ERP’et afviser det? Derfor er sameksistens og centraliseret ikke »register med flere funktioner«. De bærer et andet driftsansvar.

MDM er en forretningsbeslutning

Den vigtigste pointe: MDM er ikke grundlæggende en teknologibeslutning. Det er en beslutning om autoritet. Hvem opretter kunden, hvem må ændre den, hvem beslutter, hvilken værdi der vinder, hvilke systemer skal acceptere den, hvad sker der, når de er uenige? Et værktøj kan implementere de beslutninger; det kan ikke få organisationen til at blive enig om dem. Derfor kan et MDM-projekt have fremragende teknologi og alligevel fejle: Det tekniske team løste matchningen, og forretningen løste aldrig ejerskabet.

Den generelle lektie, jeg har lært på den hårde måde: Når flere systemer er master for de samme data, kan Salesforce ikke afstemme det, de ikke er enige om. Når en virksomhed kører to ERP’er, spørger jeg, hvordan de holder dem synkroniseret. Hvis de ikke kan, kan Salesforce heller ikke. Modul 5 fortæller den historie (Én kunde, to ERP’er).

Hvad en arkitekt beslutter her

• Om problemet kræver identitetslinks, samlede data, masterværdier sendt tilbage eller central oprettelse.
• Hvilket mønster der passer til hvert datadomæne, i stedet for ét mønster for hele virksomheden.
• Hvor meget autoritet masterlaget får, og hvilke systemer der skal acceptere dets beslutninger.
• Om der er brug for en kanonisk model, uden at forveksle harmonisering med autoritet.
• Hvordan det valgte mønster ændrer integrationens retning, ejerskabet og fejlhåndteringen.

Når nogen sætter en MDM-boks på et diagram, så spørg, hvad den gør. Ved den, hvilke poster der hører sammen? Kombinerer den deres data? Beslutter den, hvilke værdier der vinder? Sender den de beslutninger tilbage? Opretter den dataene i første omgang? Svarene fortæller dig, hvilken arkitektur du reelt har, og hvor autoriteten bor.

Læs mere

• Salesforce Architects, Data 360 Architecture (opens in a new tab) (på engelsk, kontrolleret 2026-10-14).