Én sandhedskilde pr. attribut

🌐 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 1 af 6 i kapitlet Masterdata og identitet, kapitel 6 i kurset Data Architect. Hvert modul står på egne ben. Næste: De fire måder at håndtere masterdata på

Spørgsmålet, dette modul besvarer: Hvad betyder »én sandhedskilde« egentlig?

Der er en sætning, jeg hører hele tiden: »Vi skal have én sandhedskilde.« Okay. For hvad? Kunden? Det er ikke præcist nok. Tag en konto. Hvem ejer kundens navn, fakturaadresse, kreditgrænse, account executive, supportniveau, markedsføringspræferencer? De svar peger ikke på det samme system. ERP’et styrer måske det juridiske navn, fakturaadressen og kreditstatus; Salesforce relationens ejer og salgsattributterne; en anden platform samtykket. Så når nogen siger til mig: »Salesforce er vores eneste sandhedskilde for kunden«, er mit næste spørgsmål: Hvilken sandhed?

Sandheden tilhører en attribut

Det første princip for masterdata er dette: Autoritet tildeles pr. attribut, ikke pr. post. En konto kan leve i Salesforce, uden at Salesforce er autoritativ for hvert felt på den. Syv felter på én post, to autoriteter:

Attribut	Autoritativt system
Juridisk navn, fakturaadresse, ERP’ets kunde-id, kreditgrænse	ERP
Account executive, flag for strategisk konto, successniveau	Salesforce

Én post; sandheden er fordelt. Det er normalt. »System of record = Salesforce« beskriver det ikke. Det gør en autoritetsmodel.

Oprettet, redigeret, refereret, og hvor hurtigt?

Når jeg underviser i masterdata, vender jeg hele tiden tilbage til de samme spørgsmål for hver vigtig bid data: Hvor oprettes den, hvor redigeres den, hvor refereres den, og hvor hurtigt ændrer den sig? De afslører arkitekturen hurtigt. (Du mødte de første tre i kapitel 4, da vi sorterede typerne af data; her gør de deres egentlige arbejde.)

Tag et aktiv. En kunde bestiller tre cykler. Salesforce har salgsmuligheden og dens linjer, og ordren går til ERP’et. ERP’et opfylder den, og det er dér, aktiverne bliver oprettet: tre cykler, tre serienumre, sendt tilbage til Salesforce. Måneder senere ringer kunden om en af dem, og support refererer til aktivet i en sag. Nu skal nogen rette en attribut. Hvilke må Salesforce redigere, og hvilke tilhører ERP’et, der oprettede dem? Og når ERP’et ændrer en, hvor hurtigt skal Salesforce så vide det? Ét aktiv, fire spørgsmål, og svarene er ikke de samme for alle felter.

Lad os sige, at det juridiske navn oprettes i ERP’et og refereres i Salesforce, og en sælger opdager, at det er forkert. Skal sælgeren rette det i Salesforce? Hvis ERP’et ejer feltet, retter det ingenting at ændre kopien. I bedste fald overskriver næste synkronisering det; i værste fald er de to systemer nu uenige, og ingen ved, hvilket man skal stole på. Hvis forretningen vil have, at sælgeren starter rettelsen, er det noget andet: Salesforce leverer oplevelsen, sender en anmodning til ERP’et, ERP’et foretager eller godkender ændringen, og den autoritative værdi kommer tilbage. Det er en helt anden arkitektur end at lade Salesforce redigere feltet på egen hånd.

Forsinkelse er også en del af sandheden. ERP’et ændrer en kundes kreditstatus kl. 10.00; Salesforce synkroniserer om natten; kl. 15.00 kigger en sælger i Salesforce. Er værdien forkert? Den er forældet. Hvis værdien ændrer sig én gang om året, og en dags forsinkelse ikke koster noget, er natlig synkronisering fint. Hvis den afgør, om du accepterer en ordre til en million dollars i dag, er den ikke. Autoritet siger, hvor sandheden kommer fra; forsinkelse siger, hvor hurtigt andre skal opdage, at den har ændret sig. To separate beslutninger.

Kildesystem, engagementssystem, referencesystem

Ordforrådet fra kapitel 4 hjælper her. Et system of record (kildesystem) vedligeholder den autoritative version. Et engagementssystem er dér, hvor folk arbejder med den. Et referencesystem leverer data, som et andet system bruger, men ikke ejer. Salesforce kan være engagementssystemet for kunderelationen, mens ERP’et forbliver system of record for de juridiske og økonomiske attributter. Det er ikke en svaghed i arkitekturen; det er arkitekturen. Fejlen er at lade, som om ét system skal eje alt, så diagrammet ser enklere ud.

Den hybride golden record

Det ændrer, hvad »golden record« betyder. Kapitel 5 introducerede idéen, mens vi holdt dårlige data ude; her er den hjertet i designet. Folk forestiller sig én magisk post, hvor hvert felt er mastered ét sted. Nogle gange er det designet. På Salesforce ser jeg oftere en hybrid: en del af kontoen er mastered et andet sted og kopieret ind (juridisk navn, ERP’ets kundenummer, fakturaadresse, kreditstatus), og en del findes kun, fordi Salesforce har brug for den (account executive, salgsstrategi, successniveau, noter om relationen). ERP-felterne kommer ind, så folk kan bruge dem. Salesforce-felterne går aldrig tilbage, for ERP’et er ligeglad med dem. Helt rimeligt, så længe alle ved, hvad der er hvad.

Gør autoriteten synlig

Så jeg gør ekstern autoritet tydelig i skemaet. Hvis SAP styrer et felt, får det et præfiks: sap_Customer_Number, sap_Credit_Status, sap_Legal_Name. Det er samme idé som præfikset erp_ i kapitel 4. Brug systemets navn, når autoriteten er specifik og stabil, og et generisk præfiks, når betydningen er vigtigere end dagens leverandør. Pointen er, at nogen, der læser modellen seks måneder senere, kan se: Det her er ikke bare endnu et Salesforce-felt; et andet system ejer denne værdi. Lad ikke folk genopdage autoriteten ved at reverse-engineere integrationer.

Byg et autoritetskort

For vigtige masterdata vil jeg have et autoritetskort: for hver nøgleattribut hvem der opretter den, hvem der ejer forretningsbeslutningen, hvilket system der er autoritativt, og hvem eller hvad der må ændre den. Fire forskellige spørgsmål:

Attribut	Oprettes af	Forretningsejer	Autoritativt system	Må ændre den
Juridisk navn	Økonomi	Økonomi	ERP	Økonomiprocessen
Kreditgrænse	Økonomi	Økonomi	ERP	Kreditteamet
Account executive	Salgsdrift	Salg	Salesforce	Salgsledelsen
Supportniveau	Servicedrift	Service	Salesforce	Serviceledelsen
Samtykke	Kunden	Databeskyttelse	Samtykkeplatform	Kunden, en godkendt proces

Læg mærke til, at forretningsejeren og det autoritative system ikke er det samme. Et system ejer ikke politik; det gør mennesker. Systemet gemmer og håndhæver resultatet. Det er kapitel 5 igen: Ejerne fastsætter politikken; arkitekterne håndhæver den.

Click to enlarge

Én kunde. Mange attributter. Én autoritet for hver.

Autoriteten skifter i løbet af livscyklussen

En sælger møder et emne, som ERP’et aldrig har hørt om, og opretter kontoen i Salesforce. På det tidspunkt er Salesforce autoritativ for navn, adresse, kontakter og kvalificering. Emnet bliver kunde; ERP’et opretter den officielle kunde og tildeler kundenummer, juridisk navn, fakturaadresse og kredit. Autoriteten flyttede sig. Salesforce tog ikke fejl før; livscyklussen ændrede sig. Det er mønsteret fra foreløbig til styret fra kapitel 5: Før konverteringen ejer Salesforce emnet; efter den ejer ERP’et de styrede attributter, og Salesforce bliver ved med at eje sine egne. Så »hvilket system ejer kontoen?« er et svagt spørgsmål. Spørg: Hvilket system ejer denne attribut på dette tidspunkt i livscyklussen?

En kopi er ikke autoritet

Vi kopierer ERP-data ind i Salesforce, fordi folk har brug for dem hele tiden. Det gør Salesforce til en praktisk lokal kopi, ikke til masteren, og arkitekturen skal opføre sig derefter: skrivebeskyttet for brugerne, opdateret af integrationen, mærket med sin kilde, ændret kun via en anmodning og tjekket med afstemning, når kopien glider. Kopien er nyttig. Autoriteten har ikke flyttet sig.

Tillid kræver mere end en værdi

»Fakturaadresse: 123 Main Street.« Skal du stole på den? Jeg vil have tillidssignaler: hvor den kom fra, hvornår den sidst blev bekræftet, hvilket system der leverede den, og hvem eller hvad der sidst ændrede den: en person, en integration, en agent? Nu siger ERP’et 123 Main Street, Salesforce siger 125, og en partnerfil siger »123 Main St., Suite 200«. Hvilken er rigtig? Svar ikke »brug den nyeste«. Måske. Men »den nyeste« er i sig selv en regel, der antager, at den, der ændrede den sidst, fortjener at vinde. Det kan være sandt, eller forfærdeligt. Modul 3 tager fat på det. Tillid kommer fra autoritet og oprindelse, ikke fra at finde et felt, der er udfyldt.

Steve Trucking: hvis sandhed er det?

En detailpartner sender en levering, og der gemmer sig flere sandheder i den ene transaktion. Partnerens ordrereference er partnerens; Steve Trucking gemmer den for at kunne matche opdateringer, men bliver ikke master for den. Leveringsstatus (ankommet, leveret, monteret, en undtagelse) er Steve Truckings; partneren modtager den, men det gør ikke partneren autoritativ for, hvad der skete på lastbilen, at den modtager en status. Og modtageren er partnerens kunde. Partneren leverer navn, adresse, telefon og leveringsnoter, fordi Steve Trucking har brug for dem for at levere. Det gør ikke Steve Trucking til master for den persons identitet, og den skelnen afgør designet af modtageren ved kontrolpunktet.

Click to enlarge

Én levering, to autoriteter.

Hvor data bor, og hvem der ejer deres sandhed, er to forskellige spørgsmål. Salesforce kan rumme ERP’ets kundenummer uden at eje det; Snowflake kan rumme leveringsstatus uden at være dens operationelle master; en kundedataplatform kan samle identiteter uden at eje hver attribut. En agent kan læse alle tre, og det giver bestemt ikke agenten lov til at afgøre, hvad der er sandt.

Ud over eksamen: hvad AI ændrer. Agenter gør autoritet pr. attribut til en regel for, hvad der må udføres. Et menneske ser en forkert fakturaadresse og ved: »Den kommer fra SAP; den skal jeg ikke ændre her.« En agent, der får besked på at »opdatere kundens fakturaadresse«, ved det ikke, medmindre vi designer til det. Den har brug for det samme autoritetskort, som arkitekten har: Adgang til et felt gør ikke feltet til det rigtige sted at skrive.

Hvad en arkitekt beslutter her

• Hvilket system der er autoritativt for hver vigtig attribut, i stedet for ét system for en hel post.
• Hvor hver attribut oprettes, redigeres og refereres, og hvor hurtigt dens ændringer skal nå frem.
• Hvem der fastsætter politikken for hver attribut, og hvilke personer, integrationer eller agenter der må ændre den.
• Hvordan ekstern autoritet ses i modellen: navnepræfikser, tilladelser, integrationernes opførsel.
• Hvordan autoriteten skifter i løbet af livscyklussen, for eksempel når et emne bliver en kunde, der styres af ERP’et.

Én sandhedskilde betyder ikke én org, ét ERP, én MDM-platform eller én kæmpe post. Det betyder, at arkitekturen for hver bid styret information kan sige, hvor den autoritative værdi er, og at hvert andet system ved, hvordan det skal opføre sig på grund af det. Det er ikke én sandhedskilde. Det er en arkitektur for sandhed.

Læs mere

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