En sanningskälla per attribut

🌐 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 1 av 6 i kapitlet Masterdata och identitet, kapitel 6 i kursen Data Architect. Varje modul står på egna ben. Nästa: De fyra sätten att hantera masterdata

Frågan den här modulen besvarar: Vad betyder ”en enda sanningskälla” egentligen?

Det finns en fras jag hör hela tiden: ”Vi behöver en enda sanningskälla.” Okej. För vad? Kunden? Det är inte tillräckligt specifikt. Ta ett konto. Vem äger kundens namn, faktureringsadress, kreditgräns, kundansvariga säljare, supportnivå, marknadsföringspreferenser? De svaren pekar inte på samma system. ERP:t kanske styr det juridiska namnet, faktureringsadressen och kreditstatusen; Salesforce relationsägaren och säljattributen; en annan plattform samtycket. Så när någon säger till mig ”Salesforce är vår enda sanningskälla för kunden” är min nästa fråga: vilken sanning?

Sanningen hör till ett attribut

Den första principen för masterdata är den här: auktoritet tilldelas per attribut, inte per post. Ett konto kan bo i Salesforce utan att Salesforce är auktoritativt för varje fält på det. Sju fält på en post, två auktoriteter:

Attribut	Auktoritativt system
Juridiskt namn, faktureringsadress, kund-ID i ERP:t, kreditgräns	ERP
Kundansvarig säljare, flagga för strategiskt konto, kundnivå	Salesforce

En post; sanningen är fördelad. Det är normalt. ”System of record = Salesforce” beskriver det inte. En auktoritetsmodell gör det.

Skapas, redigeras, refereras, och hur snabbt?

När jag undervisar om masterdata återkommer jag hela tiden till samma frågor för varje viktig del av data: var skapas den, var redigeras den, var refereras den, och hur snabbt ändras den? De blottlägger arkitekturen snabbt. (Du mötte de tre första i kapitel 4, när vi sorterade typerna av data; det är här de gör sitt verkliga jobb.)

Ta en tillgång. En kund beställer tre cyklar. Salesforce har affärsmöjligheten och dess rader, och ordern går till ERP:t. ERP:t levererar den, och det är där tillgångarna skapas: tre cyklar, tre serienummer, som skickas tillbaka till Salesforce. Månader senare ringer kunden om en av dem, och supporten refererar till tillgången i ett ärende. Nu behöver någon rätta ett attribut. Vilka får Salesforce redigera, och vilka hör till ERP:t som skapade dem? Och när ERP:t ändrar ett, hur snabbt behöver Salesforce få veta det? En tillgång, fyra frågor, och svaren är inte desamma för varje fält.

Säg att det juridiska namnet skapas i ERP:t och refereras i Salesforce, och en säljare märker att det är fel. Ska säljaren rätta det i Salesforce? Om ERP:t äger fältet rättar du ingenting genom att ändra kopian. I bästa fall skriver nästa synk över det; i värsta fall är de två systemen nu oense och ingen vet vilket man ska lita på. Om verksamheten vill att säljaren ska starta rättelsen är det något annat: Salesforce står för upplevelsen, skickar en förfrågan till ERP:t, ERP:t gör eller godkänner ändringen, och det auktoritativa värdet kommer tillbaka. Det är en helt annan arkitektur än att låta Salesforce redigera fältet på egen hand.

Latens är också en del av sanningen. ERP:t ändrar en kunds kreditstatus klockan 10.00; Salesforce synkar den varje natt; klockan 15.00 tittar en säljare i Salesforce. Är värdet fel? Det är inaktuellt. Om värdet ändras en gång om året och en dags fördröjning inte kostar något går det bra med en nattlig synk. Om det avgör om du ska acceptera en order på en miljon dollar i dag gör det inte det. Auktoritet säger var sanningen kommer ifrån; latens säger hur snabbt andra måste få veta att den ändrats. Två separata beslut.

System of record, engagemang, referens

Vokabulären från kapitel 4 hjälper här. Ett system of record (källsystem) förvaltar den auktoritativa versionen. Ett engagemangssystem är där människor arbetar med den. Ett referenssystem levererar data som ett annat system använder men inte äger. Salesforce kan vara engagemangssystemet för kundrelationen medan ERP:t förblir system of record för de juridiska och finansiella attributen. Det är ingen svaghet i arkitekturen; det är arkitekturen. Misstaget är att låtsas att ett system måste äga allt så att diagrammet ser enklare ut.

Den hybrida golden record

Det ändrar vad ”golden record” betyder. Kapitel 5 introducerade idén när vi höll dåliga data ute; här är den hjärtat i designen. Folk föreställer sig en magisk post där varje fält hanteras som masterdata på ett och samma ställe. Ibland är det designen. I Salesforce ser jag oftare en hybrid: en del av kontot hanteras som masterdata någon annanstans och kopieras in (juridiskt namn, kundnummer i ERP:t, faktureringsadress, kreditstatus), och en del finns bara för att Salesforce behöver den (kundansvarig säljare, affärsstrategi, kundnivå, relationsanteckningar). ERP-fälten kommer in så att folk kan använda dem. Salesforce-fälten går aldrig tillbaka, eftersom ERP:t inte bryr sig om dem. Helt rimligt, så länge alla vet vilket som är vilket.

Gör auktoriteten synlig

Så jag gör extern auktoritet tydlig i schemat. Om SAP styr ett fält får det ett prefix: sap_Customer_Number, sap_Credit_Status, sap_Legal_Name. Det är samma idé som prefixet erp_ i kapitel 4. Använd systemets namn när auktoriteten är specifik och stabil, och ett generiskt prefix när betydelsen väger tyngre än dagens leverantör. Poängen är att någon som läser modellen sex månader senare kan se: det här är inte bara ännu ett Salesforce-fält; ett annat system äger det här värdet. Låt inte folk upptäcka auktoriteten på nytt genom att baklängesanalysera integrationer.

Bygg en auktoritetskarta

För viktiga masterdata vill jag ha en auktoritetskarta: för varje nyckelattribut, vem som skapar det, vem som äger affärsbeslutet, vilket system som är auktoritativt, och vem eller vad som får ändra det. Fyra olika frågor:

Attribut	Skapas av	Affärsägare	Auktoritativt system	Får ändra det
Juridiskt namn	Ekonomi	Ekonomi	ERP	Ekonomiprocessen
Kreditgräns	Ekonomi	Ekonomi	ERP	Kreditteamet
Kundansvarig säljare	Säljoperationer	Försäljning	Salesforce	Försäljningsledningen
Supportnivå	Serviceoperationer	Service	Salesforce	Serviceledningen
Samtycke	Kunden	Integritet	Samtyckesplattform	Kunden, en godkänd process

Lägg märke till att affärsägare och auktoritativt system inte är samma sak. Ett system äger ingen policy; det gör människor. Systemet lagrar och genomdriver resultatet. Det är kapitel 5 igen: ägarna sätter policyn; arkitekterna genomdriver den.

Click to enlarge

En kund. Många attribut. En auktoritet för varje.

Auktoriteten ändras under livscykeln

En säljare träffar ett prospekt som ERP:t aldrig har hört talas om och skapar kontot i Salesforce. Då är Salesforce auktoritativt för namnet, adressen, kontakterna och kvalificeringen. Prospektet blir kund; ERP:t skapar den officiella kunden och tilldelar kundnummer, juridiskt namn, faktureringsadress och kredit. Auktoriteten flyttade. Salesforce hade inte fel tidigare; livscykeln ändrades. Det är mönstret från provisorisk till styrd i kapitel 5: före konverteringen äger Salesforce prospektet; efter den äger ERP:t de styrda attributen, och Salesforce fortsätter att äga sina egna. Så ”vilket system äger kontot?” är en svag fråga. Fråga: vilket system äger det här attributet, vid den här punkten i livscykeln?

En kopia är ingen auktoritet

Vi kopierar ERP-data till Salesforce eftersom folk behöver dem hela tiden. Det gör Salesforce till en bekväm lokal kopia, inte till master, och arkitekturen bör bete sig därefter: skrivskyddat för användarna, uppdaterat av integrationen, märkt med sin källa, ändrat bara genom en förfrågan, kontrollerat med avstämning när kopian glider isär. Kopian är användbar. Auktoriteten har inte flyttat.

Förtroende kräver mer än ett värde

”Faktureringsadress: 123 Main Street.” Ska du lita på den? Jag vill ha förtroendesignaler: var den kom ifrån, när den senast bekräftades, vilket system som levererade den, och vem eller vad som senast ändrade den: en person, en integration, en agent? Nu säger ERP:t 123 Main Street, Salesforce säger 125, och en partnerfil säger ”123 Main St., Suite 200”. Vilken är rätt? Svara inte ”använd den senaste”. Kanske. Men ”den senaste” är i sig en regel som förutsätter att den som ändrade sist förtjänar att vinna. Det kan stämma, eller vara förfärligt. Modul 3 tar sig an det här. Förtroende kommer från auktoritet och ursprung, inte från att hitta ett fält som är ifyllt.

Steve Trucking: vems sanning är det?

En detaljhandelspartner (Retail Partner) skickar en leverans, och flera sanningar gömmer sig i den enda transaktionen. Partnerns orderreferens är partnerns; Steve Trucking behåller den för att matcha uppdateringar, men blir inte dess master. Leveransstatusen (framme, levererad, installerad, ett undantag) är Steve Truckings; partnern tar emot den, men att ta emot en status gör inte partnern auktoritativ för vad som hände vid lastbilen. Och mottagaren (Recipient) är partnerns kund. Partnern levererar namn, adress, telefon och leveransanteckningar eftersom Steve Trucking behöver dem för att leverera. Det gör inte Steve Trucking till master för den personens identitet, och den skillnaden avgör designen av mottagaren vid kontrollpunkten.

Click to enlarge

En leverans, två auktoriteter.

Var data bor och vem som äger deras sanning är olika frågor. Salesforce kan hålla ERP:ts kundnummer utan att äga det; Snowflake kan hålla leveransstatus utan att vara dess operativa master; en kunddataplattform kan förena identiteter utan att äga varje attribut. En agent kan läsa alla tre, och det ger verkligen inte agenten rätt att avgöra vilket som är sant.

Bortom provet: vad AI ändrar. Agenter gör attributens auktoritet till en exekveringsregel. En person ser en felaktig faktureringsadress och vet ”den kommer från SAP; jag borde inte ändra den här”. En agent som får veta att den ska ”uppdatera kundens faktureringsadress” vet inte det om vi inte designar för det. Den behöver samma auktoritetskarta som arkitekten har: åtkomst till ett fält gör inte fältet till rätt ställe att skriva på.

Vad en arkitekt bestämmer här

• Vilket system som är auktoritativt för varje viktigt attribut, i stället för ett system för en hel post.
• Var varje attribut skapas, redigeras och refereras, och hur snabbt dess ändringar måste färdas.
• Vem som sätter policyn för varje attribut, och vilka personer, integrationer eller agenter som får ändra det.
• Hur extern auktoritet syns i modellen: namnprefix, behörigheter, integrationernas beteende.
• Hur auktoriteten skiftar under livscykeln, till exempel när ett prospekt blir en kund som styrs av ERP:t.

En enda sanningskälla betyder inte en org, ett ERP, en MDM-plattform eller en jättepost. Det betyder att arkitekturen för varje del av styrd information kan säga var det auktoritativa värdet finns, och att varje annat system vet hur det ska bete sig tack vare det. Det är inte en enda sanningskälla. Det är en sanningens arkitektur.

Utforska vidare

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