Håll dåliga data ute

🌐 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 2 av 6 i kapitlet Datakvalitet och styrning, kapitel 5 i kursen Data Architect. Varje modul står på egna ben. Föregående: Styrning designas in i orgen · Nästa: Känn dina data

Frågan den här modulen besvarar: Hur får du data att bli bra, och förbli bra?

Det finns två sätt att hantera dåliga data: stoppa dem innan de kommer in, eller städa upp efteråt. Du kommer att göra lite av båda. Men om jag får välja förebygger jag hellre problemet än bygger en organisation runt att städa upp för all framtid. Dubbletter, dåliga identifierare, information som saknas, värden som inte följer standard, användare som ändrar fält som ett annat system äger, integrationer som skriver över bra data med dåliga: allt blir någons städprojekt. Så designfrågan är vilka dåliga data kan jag rimligen hålla ute från början? Och ”rimligen” spelar roll, för svaret är inte att låsa varje fält tills systemet inte går att använda.

Tillräckligt bra är en affärsdefinition

Innan du förebygger dåliga data, definiera bra. Det finns ingen enda definition. Bra kan betyda tillräckligt fullständiga för att driva processen, tillräckligt korrekta för att fatta beslut på, tillräckligt aktuella för arbetslasten, tillräckligt konsekventa för att kombineras med andra system, tillräckligt unika för att veta vilken kund vi menar, tillräckligt standardiserade för automatisering, tillräckligt spårbara för att veta var de kom ifrån. Det beror på data. Om Steve Trucking fakturerar en detaljhandelspartner (Retail Partner) måste partnerns juridiska identitet vara rätt. Om en säljare antecknar efter ett möte behöver ingen en kommitté som godkänner varje mening. Tillräckligt bra är en affärsdefinition; arkitekten gör den mätbar och möjlig att genomdriva.

Förebygg de dyra felen

Alla dåliga fält förtjänar inte samma uppmärksamhet. Jag bryr mig mest om fel som får följder längre ned i kedjan. En dubblett av en kund betyder två säljhistoriker, två servicehistoriker, två uppsättningar kontakter, två externa ID:n, två integrationer som synkar samma företag, två versioner i datalagret och i Data 360, och till slut en agent som avgör vilken kund som är den riktiga. Det är mycket dyrare än ett stavfel i en beskrivning. Så börja inte med ”hur validerar vi varje fält?”. Börja med vilka dåliga data skapar det största problemet för verksamheten eller arkitekturen? och lägg de starkaste kontrollerna där.

Öppet eller låst?

Att skapa konton är det klassiska exemplet. Ska varje säljare kunna skapa ett konto? Mitt svar: det beror på styrningen runt data. För de flesta små och medelstora orgar fungerar öppet skapande bra. En säljare träffar ett prospekt, skapar kontot och sätter igång; det är det CRM är till för. Dubblettregler, obligatorisk information och förvaltning tar hand om kvaliteten. Jag lägger inte till en tung godkännandeprocess bara för att styrning låter ansvarsfullt.

Ändra nu landskapet. Den juridiska kunden hanteras som masterdata i ERP:t, flödar in i Salesforce med en ERP-identifierare, och ERP:t är auktoritativt. Nu betyder öppet skapande två sätt att skapa samma styrda enhet. När ERP:t och en säljare båda skapar samma företag, vem vinner, vilken identifierare använder integrationerna, vilken post bär historiken? Öppet skapande slutar vara en fråga om användbarhet och blir en masterdatafråga. När konton hanteras som masterdata i eller synkas med ett ERP: lås skapandet.

Men att låsa det helt misslyckas också. Säljaren har träffat ett prospekt som inte finns i ERP:t och vill öppna en affärsmöjlighet, och styrningsmodellen säger ”inget konto åt dig”. Så säljaren väntar tre dagar på Ekonomi, eller kopplar affärsmöjligheten till fel konto, eller håller prospektet i ett anteckningsfält eller ett kalkylark. Vi skyddade datamodellen och skadade verksamheten.

Mellanvägen: en provisorisk posttyp

Här är mellanvägen jag gillar. Låt försäljningen skapa kontot under en särskild posttyp, en prospekt- eller provisorisk typ, och kontrollera konverteringen till den styrda typen. Försäljningen fångar företaget och börjar sälja. Posten säger rakt ut: ännu inte etablerad i det auktoritativa systemet. Sedan konverterar en kontrollerad process den: Ekonomi godkänner den, eller en integration skickar den till ERP:t, som antingen matchar den mot en befintlig kund eller skapar en ny och skickar tillbaka den auktoritativa identifieraren. Nu korsar posten en gräns, provisorisk → styrd, vilket är något helt annat än att två system var för sig skapar det de tror är masterposten.

Posttypen är mekanismen jag lär ut. Vad du än använder, gör tillståndet synligt i data: var posten kom ifrån, om den har korsat gränsen, vem som får ändra den nu, och identifieraren som knyter den till det auktoritativa systemet. Kund-ID:t från ERP:t som bara finns efter konverteringen är den tydligaste signalen av alla.

En posttyp för varje flöde

Lägg hela flödet på en bild så ser du varför det här fungerar. Kunder och produkter kommer in från ERP:t. Affärsmöjligheter och deras rader går ut och blir ERP:ts ordrar. Och konton? Vissa kommer in, vissa går ut. Så ett vanligt mönster jag har sett i många implementeringar är två posttyper på konto (Account), en för varje riktning. Ett Sales-konto föds i Salesforce: säljarna skapar det, redigerar det, säljer till det, och när det blir en kund skickas det ut till ERP:t. Ett ERP-konto (jag har kallat det Customer, eller bara SAP) föds i ERP:t och kommer in via integrationen. Ingen skapar den posttypen utom integrationen, och dess masterdatafält (juridiskt namn, adresser, betalningsvillkor) är skrivskyddade för användarna. Posttypen säger dig åt vilket håll posten flödar, så riktningen för masterdatan står direkt på posten.

Click to enlarge

En posttyp för varje flöde: Sales-konton går ut, ERP-konton kommer in.

Det tar inte bort det svåra fallet. En säljare konverterar en lead för Steve’s Plumbing, men Steve’s Plumbing finns redan som ERP-konto, och på något sätt fångade dubblettkontrollen det inte. Nu slår du ihop poster, byter förälder för barnposterna och avgör vilken post som överlever (kapitel 6, modul 3).

Och fastna inte i själva posttypen. Normalt undviker jag posttyper om det inte finns starka skäl för dem. Jag använde dem här för att posttypen, före Dynamic Forms, valde sidlayouten, och en layout visade ERP-fälten skrivskyddade. Med Dynamic Forms kan synlighetsregler visa och dölja fält utifrån ett fälts värde, ett fält kan vara skrivskyddat på en viss sida, och Salesforce säger själva att Dynamic Forms minskar antalet sidlayouter och posttyper du behöver (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 skrivskyddat på en sida är skrivskyddat på just den sidan: API:et, en dataladdning eller en integration kan fortfarande skriva fältet. Det verkliga genomdrivandet är säkerhet på fältnivå eller en valideringsregel; validering i gränssnittet är inte datavalidering (kapitel 3, modul 9). Posttyper förtjänar fortfarande sin plats när de två typerna av konto behöver olika plocklistevärden eller affärsprocesser. Det som spelar roll är att något fält tydligt säger var posten kom ifrån: själva ERP-nyckeln, en masterdataflagga eller en plocklista för källa. Styr sedan redigerbarheten utifrån det fältet.

Click to enlarge

Från provisorisk till styrd: försäljningen börjar sälja direkt; bara den auktoritativa processen gör posten styrd.

Skydda den styrda posten

När kunden väl kommer tillbaka från ERP:t är dess ERP-ID, juridiska namn, skatteidentifierare och faktureringsuppgifter styrda attribut. Ska säljaren ändra dem? Inte om ERP:t äger dem. Det är policyn från modul 1 som behöver sin punkt där den genomdrivs: ERP-ID:t skrivskyddat, den juridiska identiteten kontrollerad, medan säljaren fortfarande redigerar distrikt, relationsanteckningar och Salesforce egna klassificeringar. Målet är inte ett konto som ingen får röra. Det är en tydlig linje mellan data som Salesforce äger och data som Salesforce refererar. (Prefixet erp_ från kapitel 4 gör den linjen synlig i schemat.)

Det du får till slut är en golden record som egentligen är en hybrid. ERP:ts masterdatafält kommer in: juridiskt namn, faktura- och leveransadresser, betalningsvillkor. Sedan lägger Salesforce till sina egna fält som aldrig går tillbaka: ett säljbetyg, senaste orderdatum, i stort sett allt som marknadsföringen använder. Samma konto, två typer av fält, och varje typ har en källa.

Det svåraste är de dubbelriktade flödena. Säg att en säljare behöver få ERP:ts juridiska namn ändrat från Steve’s Plumbing till Steve’s Plumbing LLC. Under samma fem minuter ändrar någon i ERP:t det till Steve’s Plumbing L.L.C. Vems ändring vinner? Här är tankesättet: om ett fält hanteras som masterdata i ERP:t ändrar du inte fältet, du ber om att få ändra det. Bestäm vad som händer när begäran krockar: ERP:t vinner, begäran avvisas om värdet har ändrats under tiden, eller den väntar på att en människa löser det. Och bestäm om relaterade fält följer med tillsammans som en ändring eller ett i taget. Kapitel 6 går vidare med kollisioner (Loopar och kollisioner).

Stoppa dubbletter vid dörren

Dubbletter växer. Fånga en innan den skapas så är det ett litet problem. Hitta den två år senare, med affärsmöjligheter, ärenden, kontakter, fakturor, integrationer och analyser som hänger på båda, så är det ett stort. Modul 7 i kapitel 3 gick igenom mekanismerna (matchningsregler, dubblettregler, unika External IDs), så jag lär inte ut dem igen. Styrningsfrågan är var måste vi förhindra dubbletter, och var tolererar vi dem och löser dem senare? En lös marknadsföringslead kan leva med otydlighet. En kund som styrs av ERP:t och har finansiella transaktioner kan inte det.

Standardisera det som maskiner läser

Fritext är underbart för människor och hemskt när ett system måste tolka den. Lägg Arizona, AZ, Ariz., Phoenix area och Southwest i ett fält som styr ruttplaneringen, så har du ett kvalitetsproblem. Om ett värde styr automatisering, integration, rapportering, säkerhet, tilldelning eller en agents handling, tänk noga på hur standardiserat det måste vara. Inte varje textfält blir en plocklista, men skilj på information som människor läser och information som maskiner fattar beslut utifrån. Den andra förtjänar starkare kontroll.

Låt inte obligatoriska fält skapa falska data

Vi bestämmer att ett fält är viktigt och gör det obligatoriskt. Användaren vet inte svaret, systemet låter inte användaren gå vidare, så användaren skriver N/A, Unknown, 999999 eller test@test.com. Fältet är ifyllt; data är skräp. Innan du gör något obligatoriskt, fråga om användaren faktiskt vet det vid den tidpunkten. Om inte, gör det obligatoriskt senare i processen, låt ett annat system leverera det, använd det provisoriska tillståndet, eller erbjud ett uttryckligt Okänt när okänt är ett legitimt svar. En valideringsregel kan genomdriva en policy. Den kan inte få någon att veta det de inte vet.

Varje datagräns behöver ett kvalitetsbeslut

Människor är inte den enda källan till dåliga data; integrationer producerar dem snabbare. Ett manifest från en detaljhandelspartner kommer in med några hundra rader. En handfull har ogiltiga postnummer, ett par anger en okänd distributionscentral, två upprepar samma orderreferens. Vad händer? Avvisa hela filen? Acceptera de bra raderna och skicka tillbaka de dåliga? Ladda allt och städa senare? Sätta undantagen i karantän? Vem får veta, och hur får partnern veta vad som misslyckades? Det finns inget universellt svar, men det måste finnas ett. Kapitel 4 sa att varje pil behöver en mekanism. Lägg till: varje datagräns behöver ett kvalitetsbeslut: vad vi accepterar, avvisar eller sätter i karantän, och vem som äger undantaget.

Click to enlarge

Varje datagräns behöver ett kvalitetsbeslut.

Historiska data är annorlunda

RouteDesk har åtta års historik för Steve Trucking, och kvaliteten varierar mellan distributionscentralerna. Ska vi städa alla åtta åren till dagens standard innan vi flyttar dem? Förmodligen inte automatiskt. Vad ska de användas till: daglig drift, referens, reklamationer, rapportering, trendanalys? Behöver allt finnas i Salesforce, eller kan en del stanna någon annanstans? Migreringskapitlet går på djupet. Poängen för styrningen: historik behöver inte automatiskt samma standard som aktiva data. Om du ska fatta beslut utifrån den spelar kvaliteten roll. Om du sparar den som referens kan en annan standard räcka. Känn till syftet innan du lägger en förmögenhet på att städa det förflutna.

Mät det som någon kommer att agera på

Styrningen blir aldrig klar, så du behöver se när kvaliteten sjunker: andelen dubbletter som ökar, fler poster i karantän, fler avvisningar i integrationer, platshållarvärden som sprider sig, fler förfrågningar om att kringgå reglerna, rapporter som inte längre stämmer överens. Men bygg inte 150 mått och ignorera 143 av dem. För Steve Trucking kanske det är leveranser utan giltig partnerreferens, leveranser utan användbar adress, upprepade orderreferenser, avvisade partnermeddelanden, konton som har fastnat i det provisoriska tillståndet. En instrumentpanel full av gröna cirklar betyder inte att data är bra. Mät det som någon är beredd att agera på.

Bortom provet: vad AI ändrar. Dåliga data blir allt oftare dåliga handlingar. En människa kanske märker att ett telefonnummer ser fel ut innan numret rings upp; en agent använder helt enkelt värdet den får. Dubbletter av kunder, inaktuella statusar, falska obligatoriska värden och fel identifierare blir direkt fel meddelande eller fel uppdatering. Det höjer värdet av att förebygga. Det tar inte bort behovet av förvaltning.

Vad en arkitekt bestämmer här

• Vilka kvalitetsfel som gör tillräckligt stor skada för att motivera förebyggande kontroller.
• Om styrda poster skapas fritt, bara av det auktoritativa systemet, eller via en väg från provisorisk till styrd.
• Vilka attribut Salesforce äger och vilka det bara refererar.
• Vad som händer med inkommande data som inte klarar kontrollerna (acceptera, avvisa eller karantän) och vem som äger undantaget.
• Vilka kvalitetssignaler som mäts, så att förvaltarna ser när det glider.

Du kommer aldrig att förhindra varje dålig post. Jobbet är inte perfekta data; det är att hindra dåliga data som går att undvika från att bli dyra data. Stoppa dubbletten innan den har två års historik. Skydda identifieraren innan tio integrationer är beroende av fel identifierare. Låt försäljningen skapa prospektet, men låtsas inte att det är den styrda kunden förrän det är det. Och när något dåligt slinker igenom, se till att någon kan se det, äga det och rätta det.

Utforska vidare

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