Hold dårlige data ute

🌐 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)

Bildet er laget med KI

Oversatt med KI. Fellesskapet har ikke gjennomgått oversettelsen ennå. Les på engelsk

Modul 2 av 6 i kapitlet Datakvalitet og styring, kapittel 5 i kurset Data Architect. Hver modul står på egne ben. Forrige: Styring designes inn i orgen · Neste: Kjenn dataene dine

Spørsmålet denne modulen besvarer: Hvordan får du gode data, og hvordan holder du dem gode?

Det finnes to måter å håndtere dårlige data på: stopp dem før de kommer inn, eller rydd opp etterpå. Du kommer til å gjøre litt av begge. Men får jeg velge, vil jeg heller forebygge problemet enn å bygge en organisasjon rundt å rydde opp i det for alltid. Duplikater, dårlige identifikatorer, manglende informasjon, ikke-standardiserte verdier, brukere som endrer felt et annet system eier, integrasjoner som overskriver gode data med dårlige: alt blir noens opprydningsprosjekt. Så designspørsmålet er hvilke dårlige data kan jeg med rimelighet holde ute i utgangspunktet? Og «med rimelighet» betyr noe, for svaret er ikke å låse hvert felt til systemet blir ubrukelig.

Godt nok er en forretningsdefinisjon

Før du forebygger dårlige data, må du definere gode. Det finnes ingen enkelt definisjon. Gode kan bety komplette nok til å kjøre prosessen, nøyaktige nok til å ta beslutninger på, ferske nok for arbeidsbelastningen, konsistente nok til å kombineres med andre systemer, unike nok til at vi vet hvilken kunde vi mener, standardiserte nok for automatisering, sporbare nok til at vi vet hvor de kom fra. Det avhenger av dataene. Hvis Steve Trucking fakturerer en detaljhandelspartner, må partnerens juridiske identitet være riktig. Hvis en selger noterer etter et møte, trenger ingen en komité som godkjenner hver setning. Godt nok er en forretningsdefinisjon; arkitekten gjør den målbar og håndhevbar.

Forebygg de dyre feilene

Ikke hvert dårlige felt fortjener samme oppmerksomhet. Jeg bryr meg mest om feil med konsekvenser lenger ned i kjeden. En duplikatkunde betyr to salgshistorikker, to servicehistorikker, to sett med kontakter, to eksterne ID-er, to integrasjoner som synkroniserer samme selskap, to versjoner i datavarehuset og i Data 360, og til slutt en agent som bestemmer hvilken kunde som er den ekte. Det er langt dyrere enn en skrivefeil i en beskrivelse. Så ikke start med «hvordan validerer vi hvert felt?». Start med hvilke dårlige data skaper det største forretningsmessige eller arkitektoniske problemet?, og sett de sterkeste kontrollene der.

Åpent eller låst?

Oppretting av kontoer er det klassiske eksempelet. Skal hver selger kunne opprette en konto? Mitt svar: det avhenger av styringen rundt dataene. For de fleste små og mellomstore orger er åpen oppretting greit. En selger møter et prospekt, oppretter kontoen og setter i gang; det er det CRM er til for. Duplikatregler, obligatorisk informasjon og forvaltning tar seg av kvaliteten. Jeg legger ikke til en tung godkjenningsprosess bare fordi styring høres ansvarlig ut.

Endre nå landskapet. Den juridiske kunden forvaltes som masterdata i ERP-et, flyter inn i Salesforce med en ERP-identifikator, og ERP-et er autoritativt. Nå betyr åpen oppretting to måter å opprette den samme styrte enheten på. Når ERP-et og en selger begge oppretter samme selskap, hvilken vinner, hvilken identifikator bruker integrasjonene, hvilken post har historikken? Åpen oppretting slutter å være et brukervennlighetsspørsmål og blir et masterdataspørsmål. Når kontoer forvaltes i eller synkroniseres med et ERP, lås opprettingen.

Men å låse den helt feiler også. Selgeren har møtt et prospekt som ikke finnes i ERP-et og vil åpne en salgsmulighet, og styringsmodellen sier «ingen konto til deg». Så venter selgeren tre dager på økonomi, kobler salgsmuligheten til feil konto, eller holder prospektet i et notatfelt eller et regneark. Vi beskyttet datamodellen og skadet virksomheten.

Mellomveien: en foreløpig posttype

Her er mellomveien jeg liker. La salg opprette kontoen under en bestemt posttype, en prospekt- eller foreløpig type, og kontroller konverteringen til den styrte typen. Salg registrerer selskapet og begynner å selge. Posten sier rett ut: ennå ikke etablert i det autoritative systemet. Så konverterer en kontrollert prosess den: økonomi godkjenner den, eller en integrasjon sender den til ERP-et, som enten matcher den mot en eksisterende kunde eller oppretter en ny og sender tilbake den autoritative identifikatoren. Nå krysser posten en grense, foreløpig → styrt, og det er noe helt annet enn at to systemer hver for seg oppretter det de tror er masterposten.

Posttypen er mekanismen jeg lærer bort. Uansett hva du bruker, gjør tilstanden synlig i dataene: hvor posten kom fra, om den har krysset grensen, hvem som kan endre den nå, og identifikatoren som knytter den til det autoritative systemet. ERP-kunde-ID-en som bare finnes etter konverteringen, er det tydeligste signalet av alle.

En posttype for hver flyt

Sett hele flyten på ett bilde, så ser du hvorfor dette virker. Kunder og produkter kommer inn fra ERP-et. Salgsmuligheter og linjene deres går ut og blir ERP-ets ordrer. Og kontoer? Noen kommer inn, noen går ut. Så et vanlig mønster jeg har sett på tvers av implementeringer, er to posttyper på konto (Account), én for hver retning. En Sales-konto blir født i Salesforce: selgerne oppretter den, redigerer den, selger til den, og når den blir kunde, sendes den ut til ERP-et. En ERP-konto (jeg har kalt den Customer, eller bare SAP) blir født i ERP-et og kommer inn gjennom integrasjonen. Ingen oppretter den posttypen unntatt integrasjonen, og masterdatafeltene dens (juridisk navn, adresser, betalingsbetingelser) er skrivebeskyttet for brukerne. Posttypen forteller deg hvilken vei posten flyter, så retningen på masterdataforvaltningen står rett der på posten.

Click to enlarge

En posttype for hver flyt: Sales-kontoer går ut, ERP-kontoer kommer inn.

Det fjerner ikke det vanskelige tilfellet. En selger konverterer et kundeemne for Steve’s Plumbing, men Steve’s Plumbing finnes allerede som ERP-konto, og på et vis fanget ikke duplikatsjekken det opp. Nå holder du på med sammenslåing, flytter barnepostene til ny forelder og bestemmer hvilken post som overlever (kapittel 6, modul 3).

Og ikke heng deg opp i selve posttypen. Normalt unngår jeg posttyper med mindre det finnes sterke grunner for dem. Jeg brukte dem her fordi posttypen, før Dynamic Forms, valgte sideoppsettet, og ett oppsett viste ERP-feltene skrivebeskyttet. Med Dynamic Forms kan synlighetsregler vise og skjule felt basert på verdien i et felt, et felt kan være skrivebeskyttet på en gitt side, og Salesforce sier selv at Dynamic Forms reduserer antallet sideoppsett og posttyper du trenger (Break Up Your Record Details with Dynamic Forms (opens in a new tab); Required and Read-Only Fields in Dynamic Forms (opens in a new tab)). Men skrivebeskyttet på en side er skrivebeskyttet på den siden: API-et, en datainnlasting eller en integrasjon kan fortsatt skrive til feltet. Den egentlige håndhevingen er sikkerhet på feltnivå eller en valideringsregel; validering i brukergrensesnittet er ikke datavalidering (kapittel 3, modul 9). Posttyper gjør seg fortsatt fortjent til plassen når de to typene konto trenger forskjellige plukklisteverdier eller forretningsprosesser. Det som betyr noe, er at et felt tydelig sier hvor posten kom fra: selve ERP-nøkkelen, et masterdataflagg eller en kildeplukkliste. La så redigerbarheten styres av det feltet.

Click to enlarge

Fra foreløpig til styrt: salg begynner å selge med en gang; bare den autoritative prosessen gjør posten styrt.

Beskytt den styrte posten

Når kunden kommer tilbake fra ERP-et, er ERP-ID-en, det juridiske navnet, skatte-ID-en og faktureringsopplysningene styrte attributter. Skal selgeren endre dem? Ikke hvis ERP-et eier dem. Det er policyen fra modul 1 som trenger håndhevingspunktet sitt: ERP-ID-en skrivebeskyttet, den juridiske identiteten kontrollert, mens selgeren fortsatt redigerer salgsområde, relasjonsnotater og Salesforces egne klassifiseringer. Målet er ikke en urørlig konto. Det er en klar linje mellom data Salesforce eier og data Salesforce refererer til. (Prefikset erp_ fra kapittel 4 gjør den linjen synlig i skjemaet.)

Det du ender opp med, er en golden record som egentlig er en hybrid. ERP-ets masterdatafelt kommer inn: juridisk navn, faktura- og leveringsadresser, betalingsbetingelser. Så legger Salesforce til sine egne felt som aldri går tilbake: en salgsvurdering, siste ordredato, omtrent alt markedsføring bruker. Samme konto, to typer felt, og hver type har én kilde.

Det vanskeligste er toveisflytene. La oss si at en selger trenger å få ERP-ets juridiske navn endret fra Steve’s Plumbing til Steve’s Plumbing LLC. I de samme fem minuttene endrer noen i ERP-et det til Steve’s Plumbing L.L.C. Hvem sin endring vinner? Her er tankesettet: hvis et felt forvaltes som masterdata i ERP-et, endrer du ikke feltet, du ber om å få endre det. Bestem hva som skjer når forespørselen kolliderer: ERP-et vinner, forespørselen avvises hvis verdien er endret i mellomtiden, eller den venter på at et menneske løser det. Og bestem om relaterte felt følger med som én endring eller ett om gangen. Kapittel 6 tar kollisjoner videre (Løkker og kollisjoner).

Stopp duplikater i døra

Duplikater vokser seg større. Fang ett før det opprettes, og det er et lite problem. Finn det to år senere, med salgsmuligheter, saker, kontakter, fakturaer, integrasjoner og analyse hengende på begge, og det er et stort. Modul 7 i kapittel 3 dekket mekanismene (samsvarsregler, duplikatregler, unike External ID-er), så dem lærer jeg ikke bort på nytt. Styringsspørsmålet er hvor må vi hindre duplisering, og hvor tåler vi det og løser det senere? Et uforpliktende kundeemne fra markedsføring kan leve med uklarhet. En ERP-styrt kunde med økonomiske transaksjoner kan ikke det.

Standardiser det maskiner leser

Fritekst er fantastisk for mennesker og forferdelig når et system må tolke den. Putt Arizona, AZ, Ariz., Phoenix area og Southwest i et felt som styrer ruting, og du har et kvalitetsproblem. Hvis en verdi styrer automatisering, integrasjon, rapportering, sikkerhet, tildeling eller en agents handling, tenk nøye gjennom hvor standardisert den må være. Ikke hvert tekstfelt blir en plukkliste, men skill mellom informasjon mennesker leser og informasjon maskiner tar beslutninger på. Den andre fortjener sterkere kontroll.

Ikke la obligatoriske felt skape falske data

Vi bestemmer at et felt er viktig og gjør det obligatorisk. Brukeren vet ikke svaret, systemet lar dem ikke fortsette, så de skriver N/A, Unknown, 999999 eller test@test.com. Feltet er utfylt; dataene er søppel. Før du gjør noe obligatorisk, spør om brukeren faktisk vet det på det tidspunktet. Hvis ikke, gjør det obligatorisk senere i prosessen, la et annet system levere det, bruk den foreløpige tilstanden, eller tilby et eksplisitt Ukjent når ukjent er et legitimt svar. En valideringsregel kan håndheve en policy. Den kan ikke få noen til å vite det de ikke vet.

Hver datagrense trenger en kvalitetsbeslutning

Mennesker er ikke den eneste kilden til dårlige data; integrasjoner produserer dem raskere. Manifestet til en detaljhandelspartner kommer med noen hundre linjer. En håndfull har ugyldige postnumre, et par nevner et ukjent distribusjonssenter, to gjentar samme ordrereferanse. Hva skjer? Avvise hele filen? Godta de gode linjene og returnere de dårlige? Laste inn alt og rydde senere? Sette unntakene i karantene? Hvem får beskjed, og hvordan får partneren vite hva som feilet? Det finnes ikke noe universelt svar, men det må finnes et svar. Kapittel 4 sa at hver pil trenger en mekanisme. Legg til: hver datagrense trenger en kvalitetsbeslutning: hva vi godtar, avviser eller setter i karantene, og hvem som eier unntaket.

Click to enlarge

Hver datagrense trenger en kvalitetsbeslutning.

Historiske data er annerledes

RouteDesk inneholder åtte år av Steve Truckings historikk, og kvaliteten varierer fra distribusjonssenter til distribusjonssenter. Skal vi rydde alle åtte årene til dagens standard før vi flytter dem? Sannsynligvis ikke automatisk. Hva er de til: daglig drift, oppslag, reklamasjoner, rapportering, trendanalyse? Må alt ligge i Salesforce, eller kan noe bli et annet sted? Migreringskapitlet går i dybden. Styringspoenget: historikk trenger ikke automatisk samme standard som aktive data. Hvis du skal ta beslutninger ut fra den, betyr kvaliteten noe. Hvis du tar vare på den som oppslag, kan en annen standard holde. Kjenn formålet før du bruker en formue på å rydde fortiden.

Mål det noen vil handle på

Styring blir aldri ferdig, så du må se når kvaliteten glipper: økende duplikatandel, flere poster i karantene, flere avvisninger i integrasjonene, plassholderverdier som sprer seg, flere forespørsler om å slippe unna kontrollene, rapporter som ikke lenger stemmer overens. Men ikke bygg 150 målinger og overse 143 av dem. For Steve Trucking er det kanskje leveringer uten gyldig partnerreferanse, leveringer uten brukbar adresse, gjentatte ordrereferanser, avviste partnermeldinger, kontoer som står fast i den foreløpige tilstanden. Et dashbord fullt av grønne sirkler betyr ikke at dataene er gode. Mål det noen er villig til å handle på.

Utover eksamen: hva KI endrer. Dårlige data blir i økende grad dårlige handlinger. Et menneske legger kanskje merke til at et telefonnummer ser feil ut før det ringer; en agent bruker ganske enkelt verdien den får. Duplikatkunder, utdaterte statuser, falske verdier i obligatoriske felt og feil identifikatorer blir rett til feil melding eller feil oppdatering. Det øker verdien av å forebygge. Det fjerner ikke behovet for forvaltning.

Hva en arkitekt bestemmer her

• Hvilke kvalitetsfeil som gjør nok skade til å rettferdiggjøre forebyggende kontroller.
• Om styrte poster opprettes fritt, bare av det autoritative systemet, eller gjennom en vei fra foreløpig til styrt.
• Hvilke attributter Salesforce eier, og hvilke det bare refererer til.
• Hva som skjer med innkommende data som ikke består kontrollene (godta, avvis eller sett i karantene), og hvem som eier unntaket.
• Hvilke kvalitetssignaler som måles, slik at forvalterne ser når det glipper.

Du kommer aldri til å forebygge hver dårlige post. Jobben er ikke perfekte data; den er å hindre at unngåelige dårlige data blir dyre data. Stopp duplikatet før det har to års historikk. Beskytt identifikatoren før ti integrasjoner er avhengige av feil en. La salg opprette prospektet, men ikke lat som om det er den styrte kunden før det er det. Og når noe dårlig slipper gjennom, sørg for at noen kan se det, eie det og rette det.

Les mer

• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab), på engelsk, kontrollert 2026-10-14.
• Salesforce Help, Break Up Your Record Details with Dynamic Forms (opens in a new tab) og Required and Read-Only Fields in Dynamic Forms (opens in a new tab), på engelsk, kontrollert 2026-10-14.