Hold dårlige data ude

🌐 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 2 af 6 i kapitlet Datakvalitet og styring, kapitel 5 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Styring designes ind i org’en · Næste: Kend dine data

Spørgsmålet, dette modul besvarer: Hvordan holder du data gode, og hvordan bliver de ved med at være det?

Der er to måder at håndtere dårlige data på: stop dem, før de kommer ind, eller ryd op bagefter. Du kommer til at gøre lidt af begge dele. Men hvis jeg kan vælge, vil jeg hellere forebygge problemet end bygge en organisation op omkring at rydde op i det for evigt. Dubletter, dårlige id’er, manglende oplysninger, ikke-standardiserede værdier, brugere, der ændrer felter, som et andet system ejer, integrationer, der overskriver gode data med dårlige: Alt det bliver til nogens oprydningsprojekt. Så designspørgsmålet er: Hvilke dårlige data kan jeg med rimelighed holde ude fra starten? Og »med rimelighed« betyder noget, for svaret er ikke at låse hvert felt, indtil systemet er ubrugeligt.

»Godt nok« er en forretningsdefinition

Før du forebygger dårlige data, så definér gode data. Der findes ikke én definition. Gode data kan betyde komplette nok til at køre processen, præcise nok til at træffe beslutninger på, aktuelle nok til arbejdsbelastningen, konsistente nok til at kombinere med andre systemer, unikke nok til at vide, hvilken kunde vi mener, standardiserede nok til automatisering, sporbare nok til at vide, hvor de kom fra. Det afhænger af dataene. Hvis Steve Trucking fakturerer en detailpartner, skal partnerens juridiske identitet være rigtig. Hvis en sælger noterer noget efter et møde, er der ingen, der har brug for et udvalg, der godkender hver sætning. »Godt nok« er en forretningsdefinition; arkitekten gør den målbar og håndhævelig.

Forebyg de dyre fejl

Ikke alle dårlige felter fortjener samme opmærksomhed. Jeg går mest op i fejl med konsekvenser længere nede i kæden. En dubletkunde betyder to salgshistorikker, to servicehistorikker, to sæt kontakter, to eksterne id’er, to integrationer, der synkroniserer den samme virksomhed, to versioner i datavarehuset og i Data 360, og til sidst en agent, der skal afgøre, hvilken kunde der er den rigtige. Det er langt dyrere end en tastefejl i en beskrivelse. Så start ikke med »hvordan validerer vi hvert felt?« Start med: Hvilke dårlige data skaber det største forretningsmæssige eller arkitektoniske problem? Og sæt de stærkeste kontroller dér.

Åben eller låst?

Oprettelse af konti er det klassiske eksempel. Skal alle sælgere kunne oprette en konto? Mit svar: Det afhænger af styringen omkring dataene. For de fleste små og mellemstore org’er er åben oprettelse fint. En sælger møder et emne, opretter kontoen og går i gang; det er det, CRM er til. Dubletregler, påkrævede oplysninger og forvaltning styrer kvaliteten. Jeg tilføjer ikke en tung godkendelsesproces, bare fordi styring lyder ansvarligt.

Lad os nu ændre landskabet. Den juridiske kunde er mastered i ERP’et, flyder ind i Salesforce med et ERP-id, og ERP’et er autoritativt. Nu betyder åben oprettelse to måder at oprette den samme styrede enhed på. Når ERP’et og en sælger begge opretter den samme virksomhed, hvem vinder så, hvilket id bruger integrationerne, og hvilken post rummer historikken? Åben oprettelse holder op med at være et spørgsmål om brugervenlighed og bliver et masterdataspørgsmål. Når konti er mastered i eller synkroniseret med et ERP, så lås oprettelsen.

Men at låse den helt fejler også. Sælgeren har mødt et emne, der ikke findes i ERP’et, og vil oprette en salgsmulighed, og styringsmodellen siger »ingen konto til dig«. Så venter sælgeren tre dage på økonomi, knytter salgsmuligheden til den forkerte konto eller gemmer emnet i et notefelt eller et regneark. Vi beskyttede datamodellen og skadede forretningen.

Mellemvejen: en foreløbig posttype

Her er den mellemvej, jeg godt kan lide. Lad salg oprette kontoen under en bestemt posttype, en emne- eller foreløbig type, og kontrollér konverteringen til den styrede type. Salg registrerer virksomheden og begynder at sælge. Posten siger klart: endnu ikke etableret i det autoritative system. Så konverterer en kontrolleret proces den: Økonomi godkender den, eller en integration sender den til ERP’et, som enten matcher den med en eksisterende kunde eller opretter en ny og sender det autoritative id tilbage. Nu krydser posten en grænse, foreløbig → styret, og det er noget helt andet end to systemer, der hver opretter det, de tror, er masterposten.

Posttypen er den mekanisme, jeg underviser i. Uanset hvad du bruger, så gør tilstanden synlig i dataene: hvor posten kom fra, om den har krydset grænsen, hvem der må ændre den nu, og det id, der binder den til det autoritative system. ERP’ets kunde-id, der først findes efter konverteringen, er det tydeligste signal af alle.

En posttype til hvert flow

Sæt hele flowet på ét billede, og du kan se, hvorfor det virker. Kunder og produkter kommer ind fra ERP’et. Salgsmuligheder og deres linjer går ud og bliver til ERP’ets ordrer. Og konti? Nogle kommer ind, nogle går ud. Så et almindeligt mønster, jeg har set på tværs af implementeringer, er to posttyper på konto (Account), én for hver retning. En Sales-konto fødes i Salesforce: Sælgerne opretter den, redigerer den, sælger til den, og når den bliver kunde, sendes den ud til ERP’et. En ERP-konto (jeg har kaldt den Customer eller bare SAP) fødes i ERP’et og kommer ind via integrationen. Ingen opretter den posttype undtagen integrationen, og dens masterdatafelter (juridisk navn, adresser, betalingsbetingelser) er skrivebeskyttede for brugerne. Posttypen fortæller dig, hvilken vej posten flyder, så retningen for mastering står lige dér på posten.

Click to enlarge

En posttype til hvert flow: Sales-konti går ud, ERP-konti kommer ind.

Det fjerner ikke det svære tilfælde. En sælger konverterer et kundeemne for Steve’s Plumbing, men Steve’s Plumbing findes allerede som ERP-konto, og på en eller anden måde fangede dubletkontrollen det ikke. Nu skal du sammenflette, flytte de underordnede poster til en ny forælder og afgøre, hvilken post der overlever (kapitel 6, modul 3).

Og lad være med at hænge dig i selve posttypen. Normalt undgår jeg posttyper, medmindre der er en stærk grund til dem. Jeg brugte dem her, fordi posttypen før Dynamic Forms valgte sidelayoutet, og ét layout viste ERP-felterne som skrivebeskyttede. Med Dynamic Forms kan synlighedsregler vise og skjule felter ud fra et felts værdi, et felt kan være skrivebeskyttet på en given side, og Salesforce siger selv, at Dynamic Forms reducerer antallet af sidelayouts og posttyper, du har brug for (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); på engelsk). Men skrivebeskyttet på en side er skrivebeskyttet på den side: API’et, en dataindlæsning eller en integration kan stadig skrive i feltet. Den rigtige håndhævelse er sikkerhed på feltniveau eller en valideringsregel; validering i brugerfladen er ikke datavalidering (kapitel 3, modul 9). Posttyper gør sig stadig fortjent til deres plads, når de to slags konti har brug for forskellige valglisteværdier eller forretningsprocesser. Det, der betyder noget, er, at et felt tydeligt siger, hvor posten kom fra: selve ERP-nøglen, et masterdataflag eller en valgliste for kilden. Styr så redigerbarheden ud fra det felt.

Click to enlarge

Fra foreløbig til styret: Salg begynder at sælge med det samme; kun den autoritative proces gør posten styret.

Beskyt den styrede post

Når kunden kommer tilbage fra ERP’et, er dens ERP-id, juridiske navn, skatte-id og faktureringsoplysninger styrede attributter. Skal sælgeren ændre dem? Ikke hvis ERP’et ejer dem. Det er politikken fra modul 1, der har brug for sit håndhævelsespunkt: ERP-id’et skrivebeskyttet, den juridiske identitet kontrolleret, mens sælgeren stadig redigerer salgsområde, relationsnoter og Salesforces egne klassifikationer. Målet er ikke en urørlig konto. Det er en klar linje mellem data, som Salesforce ejer, og data, som Salesforce refererer til. (Præfikset erp_ fra kapitel 4 gør den linje synlig i skemaet.)

Det, du ender med, er en golden record, der i virkeligheden er en hybrid. ERP’ets masterdatafelter kommer ind: juridisk navn, faktura- og leveringsadresser, betalingsbetingelser. Så tilføjer Salesforce sine egne felter, der aldrig går tilbage: en salgsvurdering, datoen for seneste ordre, stort set alt, hvad marketing bruger. Samme konto, to slags felter, og hver slags har én kilde.

Det sværeste er tovejsflowene. Lad os sige, at en sælger har brug for at få ERP’ets juridiske navn ændret fra Steve’s Plumbing til Steve’s Plumbing LLC. I de samme fem minutter ændrer nogen i ERP’et det til Steve’s Plumbing L.L.C. Hvis ændring vinder? Her er tankegangen: Hvis et felt er mastered i ERP’et, ændrer du ikke feltet, du beder om at ændre det. Beslut, hvad der sker, når anmodningen kolliderer: ERP’et vinder, anmodningen afvises, hvis værdien er ændret i mellemtiden, eller den venter på, at et menneske løser det. Og beslut, om relaterede felter følges ad som én ændring eller ét ad gangen. Kapitel 6 tager kollisioner videre (Løkker og kollisioner).

Stop dubletter ved døren

Dubletter vokser. Fang en, før den bliver oprettet, og det er et lille problem. Find den to år senere, med salgsmuligheder, sager, kontakter, fakturaer, integrationer og analyser hængende på begge, og det er et stort. Modul 7 i kapitel 3 dækkede mekanismerne (matchningsregler, dubletregler, unikke External ID’er), så dem underviser jeg ikke i igen. Styringsspørgsmålet er: Hvor skal vi forhindre dubletter, og hvor vil vi tolerere dem og løse dem senere? Et uforpligtende marketing-emne kan leve med tvetydighed. En ERP-styret kunde med finansielle transaktioner kan ikke.

Standardisér det, maskiner læser

Fritekst er vidunderlig for mennesker og forfærdelig, når et system skal fortolke den. Læg Arizona, AZ, Ariz., Phoenix area og Southwest i et felt, der styrer ruteføring, og du har et kvalitetsproblem. Hvis en værdi styrer automatisering, integration, rapportering, sikkerhed, tildeling eller en agents handling, så tænk grundigt over, hvor standardiseret den skal være. Ikke alle tekstfelter skal være valglister, men skeln mellem oplysninger, mennesker læser, og oplysninger, maskiner træffer beslutninger ud fra. De sidste fortjener stærkere kontrol.

Lad ikke påkrævede felter skabe falske data

Vi beslutter, at et felt er vigtigt, og gør det påkrævet. Brugeren kender ikke svaret, systemet lader dem ikke fortsætte, så de skriver N/A, Unknown, 999999 eller test@test.com. Feltet er udfyldt; dataene er skrald. Før du gør noget påkrævet, så spørg, om brugeren faktisk kender svaret på det tidspunkt. Hvis ikke, så kræv det senere i processen, lad et andet system levere det, brug den foreløbige tilstand, eller tilbyd et eksplicit Unknown (ukendt), når ukendt er et legitimt svar. En valideringsregel kan håndhæve en politik. Den kan ikke få nogen til at vide det, de ikke ved.

Hver datagrænse har brug for en kvalitetsbeslutning

Mennesker er ikke den eneste kilde til dårlige data; integrationer producerer dem hurtigere. Et manifest fra en detailpartner kommer med et par hundrede linjer. En håndfuld har ugyldige postnumre, et par nævner et ukendt distributionscenter, to gentager den samme ordrereference. Hvad sker der? Afviser vi hele filen? Accepterer vi de gode linjer og returnerer de dårlige? Indlæser vi det hele og rydder op senere? Sætter vi undtagelserne i karantæne? Hvem får besked, og hvordan finder partneren ud af, hvad der fejlede? Der er ikke noget universelt svar, men der skal være et. Kapitel 4 sagde, at hver pil skal have en mekanisme. Tilføj: Hver datagrænse har brug for en kvalitetsbeslutning: hvad vi accepterer, afviser eller sætter i karantæne, og hvem der ejer undtagelsen.

Click to enlarge

Hver datagrænse har brug for en kvalitetsbeslutning.

Historiske data er anderledes

RouteDesk rummer otte års historik for Steve Trucking, og kvaliteten varierer fra distributionscenter til distributionscenter. Skal vi rydde op i alle otte år til dagens standard, før vi flytter dem? Sandsynligvis ikke automatisk. Hvad skal de bruges til: daglig drift, opslag, reklamationer, rapportering, trendanalyse? Skal det hele ligge i Salesforce, eller kan noget blive et andet sted? Kapitlet om migrering går i dybden. Styringspointen: Historik har ikke automatisk brug for samme standard som aktive data. Hvis du skal træffe beslutninger ud fra den, betyder kvaliteten noget. Hvis du gemmer den til opslag, kan en anden standard være nok. Kend formålet, før du bruger en formue på at rydde op i fortiden.

Mål det, nogen vil handle på

Styring bliver aldrig færdig, så du skal kunne se, når kvaliteten glider: stigende dubletrater, flere poster i karantæne, flere afvisninger i integrationerne, pladsholderværdier, der breder sig, flere anmodninger om at omgå kontroller, rapporter, der ikke længere stemmer. Men byg ikke 150 målinger og ignorér de 143. For Steve Trucking er det måske leveringer uden en gyldig partnerreference, leveringer uden en brugbar adresse, gentagne ordrereferencer, afviste partnerbeskeder, konti, der sidder fast i den foreløbige tilstand. Et dashboard fuld af grønne cirkler betyder ikke, at dataene er gode. Mål det, nogen er parat til at handle på.

Ud over eksamen: hvad AI ændrer. Dårlige data bliver i stigende grad til dårlige handlinger. Et menneske lægger måske mærke til, at et telefonnummer ser forkert ud, før det ringer; en agent bruger bare den værdi, den får. Dubletkunder, forældede statusser, falske påkrævede værdier og forkerte id’er bliver direkte til den forkerte besked eller den forkerte opdatering. Det øger værdien af at forebygge. Det fjerner ikke behovet for forvaltning.

Hvad en arkitekt beslutter her

• Hvilke kvalitetsfejl der gør nok skade til at retfærdiggøre forebyggende kontroller.
• Om styrede poster oprettes frit, kun af det autoritative system eller via en vej fra foreløbig til styret.
• Hvilke attributter Salesforce ejer, og hvilke den kun refererer til.
• Hvad der sker med indgående data, der fejler tjek (acceptér, afvis eller sæt i karantæne), og hvem der ejer undtagelsen.
• Hvilke kvalitetssignaler der måles, så forvalterne kan se, når det glider.

Du kommer aldrig til at forhindre hver eneste dårlige post. Opgaven er ikke perfekte data; det er at forhindre, at dårlige data, der kunne være undgået, bliver til dyre data. Stop dubletten, før den har to års historik. Beskyt id’et, før ti integrationer afhænger af det forkerte. Lad salg oprette emnet, men lad ikke som om, det er den styrede kunde, før det er det. Og når noget dårligt slipper igennem, så sørg for, at nogen kan se det, eje det og rette det.

Læs mere

• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (på engelsk, kontrolleret 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, kontrolleret 2026-10-14).