De fyra sätten att hantera masterdata

🌐 Finns även 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 · العربية · עברית · Українська · हिन्दी · Русский · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Bilden är skapad med AI

Översatt med AI. Gemenskapen har inte granskat översättningen än. Läs på engelska

Modul 2 av 6 i kapitlet Masterdata och identitet, kapitel 6 i kursen Data Architect. Varje modul står på egna ben. Föregående: En sanningskälla per attribut · Nästa: Matchning, sammanslagning och överlevnadsregler

Frågan den här modulen besvarar: Hur hanterar organisationer masterdata, och vilken stil passar?

Modul 1 sa att auktoritet tilldelas attribut för attribut. Nu: vad gör vi när de attributen bor i flera system samtidigt? Kundinformation i Salesforce, ERP:t, fakturering, support, kanske Data 360, kanske ett datalager, var och en med sin egen version. Det är problemet som masterdatahantering (MDM) försöker lösa, och MDM är inte en enda arkitektur. Du kommer att höra fyra mönster: register (registry), konsolidering, samexistens (coexistence) och centraliserad. De är inga produktinställningar. De är fyra svar på en fråga: hur mycket auktoritet har masterdatalagret?

Börja med problemet, inte produkten

Folk hör MDM och börjar shoppa efter en MDM-produkt. Jag skulle börja med problemet. Behöver vi bara veta att flera poster är samma kund? Behöver vi en kombinerad bild för analys? Behöver vi bestämma vilka värden som är auktoritativa och skicka tillbaka dem till andra system? Eller vill vi att ett centralt system skapar masterdata åt alla? Väldigt olika krav, väldigt olika arkitekturer.

Register: säg vem som är vem

Det lättaste mönstret. Ett register ersätter inte källorna. ERP:t behåller sin kund, Salesforce sitt konto, faktureringen sin kund, och registret räknar ut att de här posterna representerar samma entitet: kontot 001… i Salesforce, kunden SAP-43821 i ERP:t och kunden BILL-9127 i faktureringen hör till en kund. Källorna stannar där de är och skrivs inte över. Nu har ”visa mig allt vi vet om den här kunden” ett svar.

Men lägg märke till vad ett register inte besvarar. Salesforce säger 123 Main Street, ERP:t 125, faktureringen ”123 Main St., Suite 200”. Registret vet att de hör ihop. Det avgör inte vilken som ska ändras. Att länka är inte att hantera masterdata.

Min erfarenhet är att register är normen i Salesforce-projekt, sedan konsolidering och samexistens; ren centraliserad MDM är ovanlig. Register är vanligt eftersom det inte är invasivt. Du behöver inte designa om varje operativt system innan du får värde. Salesforce fortsätter att göra det det gör, ERP:t fortsätter att göra det det gör, och du lägger till ett identitetslager. Det är en mycket mindre förändring än att säga till varje system ”du styr inte längre över kunddata; det gör det här nya centrala systemet”.

Click to enlarge

Registret besvarar: vilka poster hör till samma entitet?

Konsolidering: för samman data

Konsolidering tar data från flera källor och kombinerar dem till en central representation, för rapportering, analys, segmentering och kundinsikter. Ett datalager är det välbekanta exemplet: Salesforce skickar kunden, ERP:t det finansiella, faktureringen betalningarna, och verksamheten kan äntligen analysera kunden över systemen. Källorna finns kvar och kan fortfarande vara auktoritativa. Riktningen spelar roll: data flödar in i det konsoliderade systemet, som oftast inte skickar tillbaka masterhanterade ändringar. En bättre bild av kunden, utan att bli dess operativa auktoritet.

Register och konsolidering är lätta att blanda ihop. Skillnaden är vad som centraliseras: registret centraliserar identitet (”de här hör ihop”); konsolideringen centraliserar mer av data (”för samman attributen så att vi kan använda dem”). Inget av dem säger ”det här centrala systemet är nu master och varje applikation måste acceptera dess värden”.

Click to enlarge

Konsolidering för samman data utan att ta ägarskapet från källorna.

Samexistens: bestäm och skicka tillbaka

Vid samexistens får masterdatalagret verklig auktoritet. Data bor fortfarande i flera operativa system, men MDM-processen bestämmer det masterhanterade värdet och publicerar tillbaka det. Salesforce, ERP:t och faktureringen har var sitt juridiskt namn; MDM-processen avgör vilket som är det styrda och distribuerar det till alla tre. Systemen samexisterar, men de konvergerar mot det masterhanterade värdet.

Det är en mycket starkare form av MDM. Den säger inte ”de här hör ihop”; den säger ”för det här attributet är det här värdet som företaget använder”. Det kräver mer än matchning: affärsregler, ägarskap, överlevnadsregler, tvåvägsintegration, felhantering och styrning, eftersom någon måste bestämma varför ett värde vinner.

Click to enlarge

Samexistens länkar inte bara posterna. Den bestämmer masterhanterade värden och skickar tillbaka dem.

Centraliserad: master skapar sanningen

Det starkaste mönstret. Vid centraliserad MDM skapas och förvaltas styrda masterdata i den centrala mastern och distribueras till alla andra. I stället för att varje system skapar sin egen kund och MDM stämmer av dem i efterhand skapar du den styrda kunden i mastern, och skickar den sedan till Salesforce, ERP:t och faktureringen. Väldigt stark styrning, och väldigt stor förändring: befintliga processer skapar sina egna kunder, användarna har sina arbetsflöden, integrationerna förutsätter att posterna skapas lokalt, och affärsenheterna är kanske inte ens överens om vad en kund är. Därför är det ovanligt i de Salesforce-landskap jag ser. Det kan vara rätt. Det är ett mycket större beslut än att installera ett verktyg.

Click to enlarge

Centraliserad MDM flyttar skapandet och auktoriteten in i mastern.

De fyra sida vid sida

Stil	Vad som centraliseras	Finns källorna kvar?	Skickas styrda värden tillbaka?
Register	Identitet och länkar	Ja	Oftast inte
Konsolidering	Identitet plus kombinerade data	Ja	Oftast inte
Samexistens	Identitet, data och masterbeslut	Ja	Ja
Centraliserad	Skapande och auktoritet	Ja, som konsumenter	Ja

Ju längre ned i tabellen, desto mer auktoritet får masterdatalagret, och desto mer måste organisationen oftast förändras.

Provkunskap. Känn till de fyra implementeringsstilarna för MDM: register (länkar identiteter; källorna behåller sina data), konsolidering (för samman data, oftast för analys), samexistens (bestämmer masterhanterade värden och publicerar tillbaka dem till källorna) och centraliserad (mastern skapar data; källorna konsumerar dem).

Så det finns inget ”centraliserad är mest moget, så alla borde ta sig dit”. Välj det lättaste mönstret som löser problemet. Behöver du veta att poster hör ihop? Tänk register. En kombinerad bild för analys? Konsolidering. Styrda värden som synkas tillbaka till flera operativa system? Samexistens. En process som skapar och styr masterdata åt alla? Centraliserad.

Var passar Data 360 in?

Data 360 bygger enhetliga profiler över många källor, vilket låter väldigt likt MDM, och det löser verkligen en del av problemet. Identitetsupplösningen matchar källprofiler till en enhetlig identitet och behåller länkarna tillbaka till källposterna (Data 360 Architecture (opens in a new tab)). Det gör det närmast ett register. Det kan också visa avstämda värden på den enhetliga profilen. Men det gör det inte till ett centraliserat golden record-system som skriver om källorna. En enhetlig bild är inte automatiskt en masterhanterad post för företaget. Modul 4 handlar helt om den skillnaden.

En gemensam modell är inte en gemensam sanning

Du kommer också att höra kanonisk datamodell. Account i Salesforce, ERP:ts affärspartner och faktureringens kund mappas alla till ett överenskommet begrepp för hela företaget, Customer, med överenskomna identifierare och attribut, så att varje integration inte behöver förstå varje annat systems form. Datamodellen i Data 360 är ett exempel på att harmonisera källor till gemensamma begrepp. Men en kanonisk modell besvarar hur representerar vi det här konsekvent? MDM besvarar hur identifierar, styr och masterhanterar vi det över systemen? Mappa alla tre systemen perfekt till en enda Customer-form, och Salesforce säger ändå 123 Main Street medan ERP:t säger 125. Du har löst strukturen, inte auktoriteten. Harmonisering och masterdatahantering är inte utbytbara.

En verksamhet, flera mönster

Så ”Steve Trucking behöver MDM” är inget krav. För vad? Detaljhandelspartner (Retail Partners), distributionscentraler, team, lastbilar och mottagare (Recipients) är olika domäner med olika auktoriteter: detaljhandelspartnerna styrs i Salesforce och i ekonomins ERP, lastbilarnas identitet kommer från FleetLink, och varje mottagare levereras av en partner för varje leverans. Olika domäner kan ta olika mönster, och inom en domän kan attribut ha olika auktoriteter. Så rita inte en ruta märkt MDM mitt i diagrammet och kalla saken löst. Fråga vad rutan gör.

Stilen ändrar också integrationen. Ett register behöver identitetslänkar; konsolidering pålitliga inkommande flöden; samexistens data i båda riktningarna; centraliserad distribution från mastern plus kontroller som hindrar andra system från att skapa konkurrerande sanning. När auktoriteten växer gör samordningen det också, och felhanteringen: vad händer om MDM ändrar det juridiska namnet och ERP:t avvisar det? Därför är samexistens och centraliserad inte ”register med fler funktioner”. De bär olika operativa ansvar.

MDM är ett affärsbeslut

Den viktigaste poängen: MDM är i grunden inget teknikbeslut. Det är ett beslut om auktoritet. Vem skapar kunden, vem får ändra den, vem avgör vilket värde som vinner, vilka system måste acceptera det, vad händer när de är oense. Ett verktyg kan implementera de besluten; det kan inte få organisationen att enas om dem. Därför kan ett MDM-projekt ha utmärkt teknik och ändå misslyckas: det tekniska teamet löste matchningen, och verksamheten löste aldrig ägarskapet.

Den allmänna lärdom jag har fått den hårda vägen: när flera system är master för samma data kan Salesforce inte stämma av det som de inte är överens om. När ett företag kör två ERP:er frågar jag hur de håller dem synkade. Om de inte kan det kan inte Salesforce heller. Modul 5 berättar den historien (En kund, två ERP:er).

Vad en arkitekt bestämmer här

• Om problemet behöver identitetslänkar, kombinerade data, masterhanterade värden som skickas tillbaka, eller centralt skapande.
• Vilket mönster som passar varje datadomän, i stället för ett mönster för hela företaget.
• Hur mycket auktoritet masterdatalagret får, och vilka system som måste acceptera dess beslut.
• Om en kanonisk modell behövs, utan att blanda ihop harmonisering med auktoritet.
• Hur det valda mönstret ändrar integrationens riktning, ägarskapet och felhanteringen.

När någon sätter en MDM-ruta i ett diagram, fråga vad den gör. Vet den vilka poster som hör ihop? Kombinerar den deras data? Avgör den vilka värden som vinner? Skickar den tillbaka de besluten? Skapar den data från början? Svaren säger vilken arkitektur du verkligen har, och var auktoriteten bor.

Utforska vidare

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