De fire måtene å håndtere masterdata på
Finnes også på 28 språk
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 · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 2 av 6 i kapitlet Masterdata og identitet, kapittel 6 i kurset Data Architect. Hver modul står på egne ben. Forrige: Én sannhetskilde per attributt · Neste: Matching, sammenslåing og overlevelsesregler
Spørsmålet denne modulen besvarer: Hvordan håndterer organisasjoner masterdata, og hvilken stil passer?
Modul 1 sa at autoritet tildeles attributt for attributt. Nå: hva gjør vi når de attributtene bor i flere systemer samtidig? Kundeinformasjon i Salesforce, ERP-systemet, fakturering, support, kanskje Data 360, kanskje et datavarehus, hver med sin egen versjon. Det er problemet masterdatahåndtering (MDM) prøver å løse, og MDM er ikke én arkitektur. Du vil høre om fire mønstre: register (registry), konsolidering, sameksistens (coexistence) og sentralisert. De er ikke produktinnstillinger. De er fire svar på ett spørsmål: hvor mye autoritet har mastringslaget?
Start med problemet, ikke produktet
Section titled “Start med problemet, ikke produktet ”Folk hører MDM og begynner å handle inn et MDM-produkt. Jeg ville startet med problemet. Trenger vi bare å vite at flere poster er samme kunde? Trenger vi én samlet visning for analyse? Trenger vi å avgjøre hvilke verdier som er autoritative og sende dem tilbake til andre systemer? Eller vil vi ha ett sentralt system som oppretter masterdataene for alle? Svært forskjellige krav, svært forskjellige arkitekturer.
Register: fortell meg hvem som er hvem
Section titled “Register: fortell meg hvem som er hvem ”Det letteste mønsteret. Et register erstatter ikke kildene. ERP-systemet beholder kunden sin, Salesforce kontoen sin, fakturering kunden sin, og registeret finner ut at disse postene representerer samme enhet: Salesforce-konto 001…, ERP-kunde SAP-43821 og faktureringskunde BILL-9127 hører til én kunde. Kildene blir der de er, og blir ikke overskrevet. Nå har «vis meg alt vi vet om denne kunden» et svar.
Men legg merke til hva et register ikke svarer på. Salesforce sier 123 Main Street, ERP-systemet 125, fakturering «123 Main St., Suite 200». Registeret vet at de hører sammen. Det avgjør ikke hvilken som skal endres. Å koble er ikke å mastre.
Etter min erfaring er register normen på Salesforce-prosjekter, deretter konsolidering og sameksistens; ren sentralisert MDM er sjelden. Register er vanlig fordi det ikke griper inn. Du redesigner ikke hvert operative system før du får verdi. Salesforce fortsetter å gjøre det det gjør, ERP-systemet fortsetter å gjøre det det gjør, og du legger til et identitetslag. Det er en langt mindre endring enn å si til hvert system: «du kontrollerer ikke lenger kundedata; det gjør dette nye sentrale systemet.»
Registeret svarer på: hvilke poster hører til samme enhet?
Konsolidering: samle dataene
Section titled “Konsolidering: samle dataene ”Konsolidering tar data fra flere kilder og kombinerer dem til en sentral representasjon, for rapportering, analyse, segmentering, kundeinnsikt. Et datavarehus er det kjente eksempelet: Salesforce sender kunden, ERP-systemet økonomien, fakturering betalingene, og virksomheten kan endelig analysere kunden på tvers av systemene. Kildene finnes fortsatt og kan fortsatt være autoritative. Retningen betyr noe: data flyter inn i det konsoliderte systemet, som vanligvis ikke sender mastrede endringer tilbake. Et bedre bilde av kunden, uten å bli den operative autoriteten for den.
Register og konsolidering er lette å forveksle. Forskjellen er hva som sentraliseres: register sentraliserer identitet («disse hører sammen»); konsolidering sentraliserer mer av dataene («samle attributtene så vi kan bruke dem»). Ingen av dem sier «dette sentrale systemet er nå masteren, og hver applikasjon må godta verdiene det har».
Konsolidering samler dataene uten å ta eierskapet fra kildene.
Sameksistens: avgjør, og send det tilbake
Section titled “Sameksistens: avgjør, og send det tilbake ”I sameksistens får mastringslaget ekte autoritet. Dataene bor fortsatt i flere operative systemer, men MDM-prosessen avgjør den mastrede verdien og publiserer den tilbake. Salesforce, ERP-systemet og fakturering har hvert sitt juridiske navn; MDM-prosessen bestemmer det styrte navnet og distribuerer det til alle tre. Systemene sameksisterer, men de samles om den mastrede verdien.
Det er en mye sterkere form for MDM. Den sier ikke «disse hører sammen»; den sier «for dette attributtet er dette verdien virksomheten bruker.» Det krever mer enn matching: forretningsregler, eierskap, overlevelsesregler, toveisintegrasjon, feilhåndtering og styring, fordi noen må avgjøre hvorfor én verdi vinner.
Sameksistens kobler ikke bare postene. Den avgjør mastrede verdier og sender dem tilbake.
Sentralisert: masteren skaper sannheten
Section titled “Sentralisert: masteren skaper sannheten ”Det sterkeste mønsteret. I sentralisert MDM opprettes og vedlikeholdes de styrte masterdataene i den sentrale masteren og distribueres til alle andre. I stedet for at hvert system oppretter sin egen kunde og MDM avstemmer dem etterpå, oppretter du den styrte kunden i masteren, og sender den så til Salesforce, ERP-systemet og fakturering. Svært sterk styring, og svært stor endring: eksisterende prosesser oppretter sine egne kunder, brukerne har sine arbeidsflyter, integrasjoner forutsetter lokal opprettelse, og forretningsenhetene er kanskje ikke engang enige om hva en kunde er. Derfor er det sjelden i Salesforce-landskapene jeg ser. Det kan være riktig. Det er en mye større beslutning enn å installere et verktøy.
Sentralisert MDM flytter opprettelse og autoritet inn i masteren.
De fire side om side
Section titled “De fire side om side ”| Stil | Hva som sentraliseres | Blir kildene værende? | Sender styrte verdier tilbake? |
|---|---|---|---|
| Register | Identitet og koblinger | Ja | Vanligvis ikke |
| Konsolidering | Identitet pluss samlede data | Ja | Vanligvis ikke |
| Sameksistens | Identitet, data og mastrede beslutninger | Ja | Ja |
| Sentralisert | Opprettelse og autoritet | Ja, som konsumenter | Ja |
Nedover i tabellen får mastringslaget mer autoritet, og organisasjonen må vanligvis endre seg mer.
Eksamenskunnskap. Kjenn de fire implementeringsstilene for MDM: register (kobler identiteter; kildene beholder dataene sine), konsolidering (samler dataene, vanligvis for analyse), sameksistens (avgjør mastrede verdier og publiserer dem tilbake til kildene) og sentralisert (masteren oppretter dataene; kildene konsumerer dem).
Så det finnes ikke noe «sentralisert er mest modent, så alle bør komme dit». Velg det letteste mønsteret som løser problemet. Trenger du å vite at poster hører sammen? Tenk register. En samlet visning for analyse? Konsolidering. Styrte verdier synkronisert tilbake til flere operative systemer? Sameksistens. Én prosess som oppretter og kontrollerer masterdata for alle? Sentralisert.
Hvor passer Data 360 inn?
Section titled “Hvor passer Data 360 inn? ”Data 360 bygger samlede profiler på tvers av mange kilder, noe som høres mye ut som MDM, og det løser en del av problemet. Identitetsoppløsningen matcher kildeprofiler til en samlet identitet og beholder koblingene tilbake til kildepostene (Data 360 Architecture (opens in a new tab)). Det gjør den nærmest et register. Den kan også vise avstemte verdier på den samlede profilen. Men det gjør den ikke til et sentralisert golden record-system som skriver om kildene. En samlet visning er ikke automatisk en mastret post for virksomheten. Modul 4 handler helt og holdent om den forskjellen.
En felles modell er ikke en felles sannhet
Section titled “En felles modell er ikke en felles sannhet ”Du vil også høre om en kanonisk datamodell. Kontoen (Account) i Salesforce, forretningspartneren i ERP-systemet og kunden i fakturering mappes alle til ett avtalt virksomhetsbegrep, Kunde, med avtalte identifikatorer og attributter, så hver integrasjon slipper å forstå formen på hvert annet system. Datamodellen i Data 360 er et eksempel på å harmonisere kilder til felles begreper. Men en kanonisk modell svarer på hvordan representerer vi dette konsistent? MDM svarer på hvordan identifiserer, styrer og mastrer vi det på tvers av systemer? Map alle tre systemene perfekt til én Kunde-form, og Salesforce sier fortsatt 123 Main Street mens ERP-systemet sier 125. Du har løst strukturen, ikke autoriteten. Å harmonisere og å mastre kan ikke byttes om.
Én virksomhet, flere mønstre
Section titled “Én virksomhet, flere mønstre ”Så «Steve Trucking trenger MDM» er ikke et krav. For hva da? Detaljhandelspartnere, distribusjonssentre, team, lastebiler, mottakere er forskjellige domener med forskjellige autoriteter: detaljhandelspartnerne styres i Salesforce og i økonomisystemet (ERP), lastebilenes identitet kommer fra FleetLink, og hver mottaker leveres av en partner for hver levering. Forskjellige domener kan få forskjellige mønstre, og innenfor et domene kan attributtene ha forskjellige autoriteter. Så ikke tegn en boks merket MDM midt i diagrammet og kall det løst. Spør hva boksen gjør.
Stilen endrer også integrasjonen. Register trenger identitetskoblinger; konsolidering pålitelige innkommende flyter; sameksistens data i begge retninger; sentralisert distribusjon fra masteren pluss kontroller som hindrer andre systemer i å skape en konkurrerende sannhet. Når autoriteten vokser, vokser også koordineringen, og feilhåndteringen: hva om MDM endrer det juridiske navnet og ERP-systemet avviser det? Derfor er ikke sameksistens og sentralisert «register med flere funksjoner». De bærer et annet driftsansvar.
MDM er en forretningsbeslutning
Section titled “MDM er en forretningsbeslutning ”Det viktigste poenget: MDM er i bunn og grunn ikke en teknologibeslutning. Det er en beslutning om autoritet. Hvem oppretter kunden, hvem kan endre den, hvem avgjør hvilken verdi som vinner, hvilke systemer må godta den, hva skjer når de er uenige. Et verktøy kan implementere de beslutningene; det kan ikke få organisasjonen til å bli enig om dem. Derfor kan et MDM-prosjekt ha utmerket teknologi og likevel mislykkes: det tekniske teamet løste matchingen, og virksomheten løste aldri eierskapet.
Den generelle lærdommen jeg har lært på den harde måten: når flere systemer mastrer de samme dataene, kan ikke Salesforce avstemme det de ikke er enige om. Når et selskap kjører to ERP-systemer, spør jeg hvordan de holder dem synkronisert. Klarer de det ikke, klarer ikke Salesforce det heller. Modul 5 forteller den historien (Én kunde, to ERP-systemer).
Hva en arkitekt bestemmer her
Section titled “Hva en arkitekt bestemmer her ”- Om problemet trenger identitetskoblinger, samlede data, mastrede verdier sendt tilbake, eller sentral opprettelse.
- Hvilket mønster som passer hvert datadomene, i stedet for ett mønster for hele virksomheten.
- Hvor mye autoritet mastringslaget får, og hvilke systemer som må godta beslutningene det tar.
- Om det trengs en kanonisk modell, uten å forveksle harmonisering med autoritet.
- Hvordan det valgte mønsteret endrer integrasjonsretning, eierskap og feilhåndtering.
Når noen setter en MDM-boks på et diagram, spør hva den gjør. Vet den hvilke poster som hører sammen? Samler den dataene deres? Avgjør den hvilke verdier som vinner? Sender den de beslutningene tilbake? Oppretter den dataene i utgangspunktet? Svarene forteller deg hvilken arkitektur du egentlig har, og hvor autoriteten bor.
Les mer
Section titled “Les mer ”- Salesforce Architects, Data 360 Architecture (opens in a new tab), på engelsk, kontrollert 2026-10-14.