Én sannhetskilde per attributt
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 1 av 6 i kapitlet Masterdata og identitet, kapittel 6 i kurset Data Architect. Hver modul står på egne ben. Neste: De fire måtene å håndtere masterdata på
Spørsmålet denne modulen besvarer: Hva betyr egentlig «én sannhetskilde»?
Det er en frase jeg hører hele tiden: «Vi trenger én sannhetskilde.» Ok. For hva da? Kunden? Det er ikke spesifikt nok. Ta en konto. Hvem eier kundens navn, fakturaadresse, kredittgrense, kundeansvarlig, supportnivå, markedsføringspreferanser? De svarene peker ikke til det samme systemet. ERP-systemet kan kontrollere det juridiske navnet, fakturaadressen og kredittstatusen; Salesforce relasjonseieren og salgsattributtene; en annen plattform samtykket. Så når noen sier til meg «Salesforce er vår eneste sannhetskilde for kunden», er mitt neste spørsmål: hvilken sannhet?
Sannheten hører til et attributt
Section titled “Sannheten hører til et attributt ”Det første prinsippet for masterdata er dette: autoritet tildeles per attributt, ikke per post. En konto kan bo i Salesforce uten at Salesforce er autoritativt for hvert felt på den. Sju felt på én post, to autoriteter:
| Attributt | Autoritativt system |
|---|---|
| Juridisk navn, fakturaadresse, kunde-ID i ERP, kredittgrense | ERP |
| Kundeansvarlig, flagg for strategisk konto, kundesuksessnivå | Salesforce |
Én post; sannheten er fordelt. Det er normalt. «System of record = Salesforce» beskriver det ikke. En autoritetsmodell gjør det.
Opprettet, redigert, referert, og hvor raskt?
Section titled “Opprettet, redigert, referert, og hvor raskt? ”Når jeg underviser i masterdata, kommer jeg stadig tilbake til de samme spørsmålene for hver viktig bit data: hvor opprettes den, hvor redigeres den, hvor refereres den, og hvor raskt endres den? De avslører arkitekturen fort. (Du møtte de tre første i kapittel 4, da vi sorterte typene data; her gjør de den virkelige jobben.)
Ta et aktivum. En kunde bestiller tre sykler. Salesforce har salgsmuligheten og produktlinjene, og ordren går til ERP-systemet. ERP-systemet leverer den, og det er der aktivaene opprettes: tre sykler, tre serienumre, sendt tilbake til Salesforce. Måneder senere ringer kunden om en av dem, og support refererer aktivumet i en sak. Nå må noen rette et attributt. Hvilke kan Salesforce redigere, og hvilke tilhører ERP-systemet som opprettet dem? Og når ERP-systemet endrer ett, hvor raskt må Salesforce få vite det? Ett aktivum, fire spørsmål, og svarene er ikke de samme for hvert felt.
Si at det juridiske navnet opprettes i ERP-systemet og refereres i Salesforce, og en selger ser at det er feil. Skal selgeren rette det i Salesforce? Hvis ERP-systemet eier feltet, retter det ingenting å endre kopien. I beste fall overskriver neste synkronisering det; i verste fall er de to systemene nå uenige, og ingen vet hvilket de skal stole på. Hvis virksomheten vil at selgeren skal starte rettingen, er det noe annet: Salesforce gir brukeropplevelsen, sender en forespørsel til ERP-systemet, ERP-systemet gjør eller godkjenner endringen, og den autoritative verdien kommer tilbake. Det er en helt annen arkitektur enn å la Salesforce redigere feltet på egen hånd.
Forsinkelse er også en del av sannheten. ERP-systemet endrer en kundes kredittstatus kl. 10.00; Salesforce synkroniserer om natten; kl. 15.00 ser en selger i Salesforce. Er verdien feil? Den er utdatert. Hvis verdien endres én gang i året og en dags forsinkelse ikke koster noe, holder det med nattlig synkronisering. Hvis den avgjør om du tar imot en ordre på en million dollar i dag, holder det ikke. Autoritet sier hvor sannheten kommer fra; forsinkelse sier hvor raskt andre må få vite at den endret seg. To separate beslutninger.
System of record, engasjement, referanse
Section titled “System of record, engasjement, referanse ”Ordforrådet fra kapittel 4 hjelper her. Et system of record (kildesystem) vedlikeholder den autoritative versjonen. Et engasjementssystem er der folk jobber med den. Et referansesystem leverer data som et annet system bruker, men ikke eier. Salesforce kan være engasjementssystemet for kunderelasjonen mens ERP-systemet forblir system of record for de juridiske og finansielle attributtene. Det er ikke en svakhet i arkitekturen; det er arkitekturen. Feilen er å late som om ett system må eie alt, så diagrammet ser enklere ut.
Den hybride golden record
Section titled “Den hybride golden record ”Det endrer hva «golden record» betyr. Kapittel 5 introduserte idéen mens vi holdt dårlige data ute; her er den hjertet i designet. Folk ser for seg én magisk post der hvert felt mastres på ett sted. Noen ganger er det designet. På Salesforce ser jeg oftere en hybrid: en del av kontoen mastres et annet sted og kopieres inn (juridisk navn, kundenummer i ERP, fakturaadresse, kredittstatus), og en del finnes bare fordi Salesforce trenger den (kundeansvarlig, salgsstrategi, kundesuksessnivå, relasjonsnotater). ERP-feltene kommer inn så folk kan bruke dem. Salesforce-feltene går aldri tilbake, fordi ERP-systemet ikke bryr seg om dem. Helt fornuftig, så lenge alle vet hva som er hva.
Gjør autoriteten synlig
Section titled “Gjør autoriteten synlig ”Så jeg gjør ekstern autoritet tydelig i skjemaet. Hvis SAP kontrollerer et felt, får det et prefiks: sap_Customer_Number, sap_Credit_Status, sap_Legal_Name. Det er samme idé som erp_-prefikset i kapittel 4. Bruk systemets navn når autoriteten er spesifikk og stabil, og et generisk prefiks når betydningen er viktigere enn dagens leverandør. Poenget er at seks måneder senere skal den som leser modellen, kunne se: dette er ikke bare enda et Salesforce-felt; et annet system eier denne verdien. Ikke la folk gjenoppdage autoriteten ved å reversere integrasjonene.
Bygg et autoritetskart
Section titled “Bygg et autoritetskart ”For viktige masterdata vil jeg ha et autoritetskart: for hvert nøkkelattributt, hvem oppretter det, hvem eier forretningsbeslutningen, hvilket system er autoritativt, og hvem eller hva kan endre det. Fire forskjellige spørsmål:
| Attributt | Opprettes av | Forretningseier | Autoritativt system | Kan endre det |
|---|---|---|---|---|
| Juridisk navn | Økonomi | Økonomi | ERP | Økonomiprosessen |
| Kredittgrense | Økonomi | Økonomi | ERP | Kredittavdelingen |
| Kundeansvarlig | Salgsdrift | Salg | Salesforce | Salgsledelsen |
| Supportnivå | Servicedrift | Service | Salesforce | Serviceledelsen |
| Samtykke | Kunden | Personvern | Samtykkeplattform | Kunden, en godkjent prosess |
Legg merke til at forretningseier og autoritativt system ikke er det samme. Et system eier ikke policy; det gjør mennesker. Systemet lagrer og håndhever resultatet. Det er kapittel 5 igjen: eierne setter policyen; arkitektene håndhever den.
Én kunde. Mange attributter. Én autoritet for hvert.
Autoriteten endres gjennom livssyklusen
Section titled “Autoriteten endres gjennom livssyklusen ”En selger møter et prospekt som ERP-systemet aldri har hørt om, og oppretter kontoen i Salesforce. Da er Salesforce autoritativt for navn, adresse, kontakter og kvalifisering. Prospektet blir kunde; ERP-systemet oppretter den offisielle kunden og tildeler kundenummer, juridisk navn, fakturaadresse og kreditt. Autoriteten flyttet seg. Salesforce tok ikke feil før; livssyklusen endret seg. Det er mønsteret fra kapittel 5, fra foreløpig til styrt: før konverteringen eier Salesforce prospektet; etterpå eier ERP-systemet de styrte attributtene, og Salesforce fortsetter å eie sine egne. Så «hvilket system eier kontoen?» er et svakt spørsmål. Spør: hvilket system eier dette attributtet, på dette punktet i livssyklusen?
En kopi er ikke autoritet
Section titled “En kopi er ikke autoritet ”Vi kopierer ERP-data inn i Salesforce fordi folk trenger dem hele tiden. Det gjør Salesforce til en praktisk lokal kopi, ikke masteren, og arkitekturen bør oppføre seg deretter: skrivebeskyttet for brukerne, oppdatert av integrasjonen, merket med kilden, endret bare gjennom en forespørsel, kontrollert med avstemming når kopien glir fra. Kopien er nyttig. Autoriteten har ikke flyttet seg.
Tillit krever mer enn en verdi
Section titled “Tillit krever mer enn en verdi ”«Fakturaadresse: 123 Main Street.» Skal du stole på den? Jeg vil ha tillitssignaler: hvor den kom fra, når den sist ble bekreftet, hvilket system som leverte den, og hvem eller hva som sist endret den: en person, en integrasjon, en agent? Nå sier ERP-systemet 123 Main Street, Salesforce sier 125, og en partnerfil sier «123 Main St., Suite 200». Hvilken er riktig? Ikke svar «bruk den nyeste». Kanskje. Men «nyeste» er i seg selv en regel som antar at den som endret sist, fortjener å vinne. Det kan være sant, eller forferdelig. Modul 3 tar fatt i dette. Tillit kommer fra autoritet og opphav, ikke fra å finne et felt som er fylt ut.
Steve Trucking: hvem sin sannhet er det?
Section titled “Steve Trucking: hvem sin sannhet er det? ”En detaljhandelspartner (Retail Partner) sender en levering, og flere sannheter skjuler seg i den ene transaksjonen. Partnerens ordrereferanse er partnerens; Steve Trucking beholder den for å matche oppdateringer, men blir ikke masteren for den. Leveringsstatusen (ankommet, levert, montert, et avvik) er Steve Truckings; partneren mottar den, men å motta en status gjør ikke partneren autoritativ for det som skjedde på lastebilen. Og mottakeren (Recipient) er partnerens kunde. Partneren leverer navn, adresse, telefon og leveringsnotater fordi Steve Trucking trenger dem for å levere. Det gjør ikke Steve Trucking til master for den personens identitet, og det skillet avgjør designet av mottakeren ved kontrollpunktet.
Én levering, to autoriteter.
Hvor data bor, og hvem som eier sannheten om dem, er forskjellige spørsmål. Salesforce kan holde kundenummeret fra ERP-systemet uten å eie det; Snowflake kan holde leveringsstatus uten å være den operative masteren for den; en kundedataplattform kan samle identiteter uten å eie hvert attributt. En agent kan lese alle tre, og det gir absolutt ikke agenten rett til å avgjøre hva som er sant.
Utover eksamen: hva KI endrer. Agenter gjør attributtautoritet om til en kjøreregel. En person ser en feil fakturaadresse og vet: «den kommer fra SAP; den skal jeg ikke endre her.» En agent som får beskjed om å «oppdatere kundens fakturaadresse», vet ikke det med mindre vi designer for det. Den trenger det samme autoritetskartet som arkitekten har: tilgang til et felt gjør ikke det feltet til riktig sted å skrive.
Hva en arkitekt bestemmer her
Section titled “Hva en arkitekt bestemmer her ”- Hvilket system som er autoritativt for hvert viktig attributt, i stedet for ett system for en hel post.
- Hvor hvert attributt opprettes, redigeres og refereres, og hvor raskt endringene må komme fram.
- Hvem som setter policyen for hvert attributt, og hvilke personer, integrasjoner eller agenter som kan endre det.
- Hvordan ekstern autoritet synes i modellen: navneprefikser, tillatelser, integrasjonsatferd.
- Hvordan autoriteten flytter seg gjennom livssyklusen, som når et prospekt blir en kunde styrt av ERP-systemet.
Én sannhetskilde betyr ikke én org, ett ERP-system, én MDM-plattform eller én gigantisk post. Det betyr at arkitekturen for hver bit styrt informasjon kan si hvor den autoritative verdien er, og at alle andre systemer vet hvordan de skal oppføre seg på grunn av det. Det er ikke én sannhetskilde. Det er en arkitektur for sannhet.
Les mer
Section titled “Les mer ”- Salesforce Architects, Data 360 Architecture (opens in a new tab), på engelsk, kontrollert 2026-10-14.