Slechte data buiten de deur houden

🌐 Ook beschikbaar in 28 talen

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Afbeelding gegenereerd met AI

Vertaald door AI. Nog niet door de community nagekeken. Lees in het Engels

Module 2 van 6 in het hoofdstuk Datakwaliteit en governance, hoofdstuk 5 van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Governance wordt in de org ontworpen · Volgende: Ken je gegevens

De vraag die deze module beantwoordt: Hoe houd je data goed, en houd je het zo?

Er zijn twee manieren om met slechte data om te gaan: haar tegenhouden voordat ze binnenkomt, of haar achteraf opruimen. Je doet van allebei wat. Maar als ik mag kiezen, voorkom ik het probleem liever dan dat ik een organisatie bouw die het voor altijd opruimt. Duplicaten, foute identificatoren, ontbrekende informatie, niet-standaard waarden, gebruikers die velden wijzigen waarvan een ander systeem eigenaar is, integraties die goede data met slechte overschrijven: het wordt allemaal iemands opruimproject. Dus de ontwerpvraag is welke slechte data kan ik redelijkerwijs al bij de ingang tegenhouden? En “redelijkerwijs” doet ertoe, want het antwoord is niet elk veld afsluiten tot het systeem onbruikbaar is.

Goed genoeg is een bedrijfsdefinitie

Voordat je slechte data voorkomt, definieer je goed. Er is niet één definitie. Goed kan betekenen: volledig genoeg om het proces te draaien, nauwkeurig genoeg om op te beslissen, actueel genoeg voor de workload, consistent genoeg om te combineren met andere systemen, uniek genoeg om te weten welke klant we bedoelen, standaard genoeg voor automatisering, herleidbaar genoeg om te weten waar het vandaan kwam. Het hangt af van de data. Als Steve Trucking een retailpartner factureert, moet de juridische identiteit van de partner kloppen. Als een verkoper na een gesprek aantekeningen maakt, heeft niemand een commissie nodig die elke zin goedkeurt. Goed genoeg is een bedrijfsdefinitie; de architect maakt haar meetbaar en afdwingbaar.

Voorkom de dure fouten

Niet elk fout veld verdient dezelfde aandacht. Ik geef het meest om fouten met gevolgen verderop. Een dubbele klant betekent twee verkoophistories, twee servicehistories, twee sets contactpersonen, twee externe ID’s, twee integraties die hetzelfde bedrijf synchroniseren, twee versies in het datawarehouse en in Data 360, en uiteindelijk een agent die beslist welke klant de echte is. Dat is veel duurder dan een typefout in een omschrijving. Begin dus niet met “hoe valideren we elk veld?” Begin met welke slechte data veroorzaakt het grootste bedrijfs- of architectuurprobleem? en zet daar de sterkste controles.

Open of afgesloten?

Accounts aanmaken is het klassieke voorbeeld. Moet elke verkoper een account kunnen aanmaken? Mijn antwoord: het hangt af van de governance rond de data. Voor de meeste kleine en middelgrote orgs is open aanmaken prima. Een verkoper ontmoet een prospect, maakt het account aan, gaat aan de slag; daar is CRM voor. Duplicaatregels, verplichte informatie en stewardship bewaken de kwaliteit. Ik voeg geen zwaar goedkeuringsproces toe alleen omdat governance verantwoordelijk klinkt.

Verander nu het landschap. De juridische klant wordt beheerd in het ERP, stroomt Salesforce in met een ERP-identificator, en het ERP is gezaghebbend. Nu betekent open aanmaken twee manieren om dezelfde bestuurde entiteit aan te maken. Als het ERP en een verkoper allebei hetzelfde bedrijf aanmaken, welke wint, welke identificator gebruiken integraties, welk record bewaart de historie? Open aanmaken is dan geen kwestie van gebruiksgemak meer, maar een vraag over stamgegevens. Als accounts in een ERP beheerd of ermee gesynchroniseerd worden, sluit het aanmaken af.

Maar alles volledig afsluiten faalt ook. De verkoper heeft een prospect ontmoet die niet in het ERP staat en wil een verkoopkans openen, en het governancemodel zegt “geen account voor jou”. Dus wacht hij drie dagen op Finance, of hangt de verkoopkans aan het verkeerde account, of houdt de prospect bij in een notitieveld of een spreadsheet. We hebben het datamodel beschermd en het bedrijf beschadigd.

De middenweg: een voorlopig recordtype

Dit is de middenweg die ik graag gebruik. Laat sales het account aanmaken onder een specifiek recordtype, een prospect- of voorlopig type, en controleer de omzetting naar het bestuurde type. Sales legt het bedrijf vast en begint te verkopen. Het record zegt duidelijk: nog niet vastgesteld in het gezaghebbende systeem. Dan zet een gecontroleerd proces het om: Finance keurt het goed, of een integratie dient het in bij het ERP, dat het koppelt aan een bestaande klant of een nieuwe aanmaakt en de gezaghebbende identificator terugstuurt. Nu steekt het record een grens over, voorlopig → bestuurd, wat heel iets anders is dan twee systemen die elk aanmaken wat ze voor het masterrecord houden.

Het recordtype is het mechanisme dat ik leer. Wat je ook gebruikt, maak de toestand zichtbaar in de data: waar het record vandaan kwam, of het de grens overgestoken is, wie het nu mag wijzigen, en de identificator die het aan het gezaghebbende systeem verbindt. De klant-ID van het ERP, die pas na de omzetting bestaat, is het duidelijkste signaal van allemaal.

Een recordtype voor elke stroom

Zet de hele stroom op één tekening en je ziet waarom dit werkt. Klanten en producten komen binnen vanuit het ERP. Verkoopkansen en hun regels gaan naar buiten en worden de orders van het ERP. En accounts? Sommige komen binnen, sommige gaan naar buiten. Dus een veelvoorkomend patroon dat ik in implementaties gezien heb, is twee recordtypes op Account, één voor elke richting. Een Sales-account wordt in Salesforce geboren: verkopers maken het aan, bewerken het, verkopen eraan, en als het een klant wordt, gaat het naar het ERP. Een ERP-account (ik heb het Customer genoemd, of gewoon SAP) wordt in het ERP geboren en komt binnen via de integratie. Niemand maakt dat recordtype aan behalve de integratie, en de masterdatavelden ervan (juridische naam, adressen, betalingsvoorwaarden) zijn voor gebruikers alleen-lezen. Het recordtype vertelt je welke kant het record op stroomt, dus de richting van het beheer staat gewoon op het record.

Click to enlarge

Een recordtype voor elke stroom: Sales-accounts gaan naar buiten, ERP-accounts komen binnen.

Het haalt het moeilijke geval niet weg. Een verkoper converteert een lead voor Steve’s Plumbing, maar Steve’s Plumbing bestaat al als ERP-account, en op de een of andere manier heeft de duplicaatcontrole het niet opgemerkt. Nu ben je aan het samenvoegen, de onderliggende records aan een nieuwe ouder aan het hangen en aan het beslissen welk record overleeft (hoofdstuk 6, module 3).

En blijf niet hangen aan het recordtype zelf. Normaal vermijd ik recordtypes, tenzij er een sterke reden voor is. Ik gebruikte ze hier omdat vóór Dynamic Forms het recordtype de paginalay-out koos, en één lay-out de ERP-velden alleen-lezen toonde. Met Dynamic Forms kunnen zichtbaarheidsregels velden tonen en verbergen op basis van de waarde van een veld, kan een veld op een bepaalde pagina alleen-lezen zijn, en zegt Salesforce zelf dat Dynamic Forms het aantal paginalay-outs en recordtypes dat je nodig hebt verminderen (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)). Maar alleen-lezen op een pagina is alleen-lezen op die pagina: de API, een dataload of een integratie kan het veld nog steeds schrijven. De echte handhaving is beveiliging op veldniveau of een validatieregel; UI-validatie is geen datavalidatie (hoofdstuk 3, module 9). Recordtypes verdienen hun plek nog steeds als de twee soorten account verschillende keuzelijstwaarden of bedrijfsprocessen nodig hebben. Wat er wel toe doet, is dat een veld duidelijk zegt waar het record vandaan komt: de ERP-sleutel zelf, een masterdatavlag, of een keuzelijst voor de bron. Stuur de bewerkbaarheid dan vanuit dat veld.

Click to enlarge

Van voorlopig naar bestuurd: sales begint meteen met verkopen; alleen het gezaghebbende proces maakt het record bestuurd.

Bescherm het bestuurde record

Zodra de klant terugkomt uit het ERP, zijn de ERP-ID, juridische naam, het fiscale nummer en de factuurgegevens bestuurde attributen. Moet de verkoper ze wijzigen? Niet als het ERP er eigenaar van is. Dat is het beleid uit module 1 dat zijn handhavingspunt nodig heeft: de ERP-ID alleen-lezen, de juridische identiteit gecontroleerd, terwijl de verkoper nog steeds het verkoopgebied, relatienotities en de eigen indelingen van Salesforce bewerkt. Het doel is geen onaantastbaar account. Het is een duidelijke lijn tussen data waarvan Salesforce eigenaar is en data waarnaar Salesforce verwijst. (De prefix erp_ uit hoofdstuk 4 maakt die lijn zichtbaar in het schema.)

Waar je uitkomt is een golden record dat eigenlijk hybride is. De masterdatavelden van het ERP komen binnen: juridische naam, factuur- en verzendadres, betalingsvoorwaarden. Dan voegt Salesforce zijn eigen velden toe die nooit teruggaan: een salesrating, de laatste orderdatum, zo ongeveer alles wat marketing gebruikt. Hetzelfde account, twee soorten velden, en elke soort heeft één bron.

Het moeilijkste zijn de stromen in twee richtingen. Stel dat een verkoper de juridische naam in het ERP wil laten veranderen van Steve’s Plumbing in Steve’s Plumbing LLC. In diezelfde vijf minuten verandert iemand in het ERP haar in Steve’s Plumbing L.L.C. Wiens wijziging wint? Dit is de mindset: als een veld in het ERP beheerd wordt, verander je het veld niet, je vraagt om het te veranderen. Beslis wat er gebeurt als het verzoek botst: het ERP wint, het verzoek wordt geweigerd als de waarde intussen veranderd is, of het wacht tot een persoon het oplost. En beslis of samenhangende velden samen als één wijziging reizen of één voor één. Hoofdstuk 6 gaat verder in op botsingen (Lussen en botsingen).

Houd duplicaten tegen bij de deur

Duplicaten stapelen zich op. Vang er een voordat hij aangemaakt wordt en het is een klein probleem. Vind hem twee jaar later, met verkoopkansen, cases, contactpersonen, facturen, integraties en analytics aan allebei, en het is een groot probleem. Module 7 van hoofdstuk 3 behandelde de mechanismen (overeenkomstregels, duplicaatregels, unieke externe ID’s), dus die leg ik niet opnieuw uit. De governancevraag is waar moeten we duplicatie voorkomen, en waar tolereren we haar en lossen we haar later op? Een losse marketinglead kan met onduidelijkheid leven. Een klant die door het ERP bestuurd wordt en financiële transacties heeft, niet.

Standaardiseer wat machines lezen

Vrije tekst is geweldig voor mensen en vreselijk als een systeem haar moet interpreteren. Zet Arizona, AZ, Ariz., Phoenix area en Southwest in een veld dat de routering stuurt, en je hebt een kwaliteitsprobleem. Als een waarde automatisering, integratie, rapportage, beveiliging, toewijzing of de actie van een agent stuurt, denk dan goed na over hoe standaard ze moet zijn. Niet elk tekstveld wordt een keuzelijst, maar onderscheid informatie die mensen lezen van informatie waarop machines beslissen. Die tweede verdient strengere controle.

Laat verplichte velden geen nepdata maken

We besluiten dat een veld ertoe doet en maken het verplicht. De gebruiker weet het antwoord niet, het systeem laat hem niet verder, dus typt hij N/A, Unknown, 999999 of test@test.com. Het veld is ingevuld; de data is rommel. Voordat je iets verplicht maakt, vraag je of de gebruiker het op dat moment eigenlijk weet. Zo niet, maak het later in het proces verplicht, laat een ander systeem het aanleveren, gebruik de voorlopige toestand, of bied een expliciete waarde Onbekend aan als onbekend een legitiem antwoord is. Een validatieregel kan beleid afdwingen. Ze kan niet zorgen dat iemand weet wat hij niet weet.

Elke datagrens heeft een kwaliteitsbeslissing nodig

Mensen zijn niet de enige bron van slechte data; integraties maken haar sneller. De vrachtlijst van een retailpartner komt binnen met een paar honderd regels. Een handvol heeft ongeldige postcodes, een paar noemen een onbekend distributiecentrum, twee herhalen dezelfde orderreferentie. Wat gebeurt er? Het hele bestand weigeren? De goede regels accepteren en de foute terugsturen? Alles laden en later opschonen? De uitzonderingen in quarantaine zetten? Wie krijgt het te horen, en hoe hoort de partner wat er misging? Er is geen universeel antwoord, maar er moet er een zijn. Hoofdstuk 4 zei dat elke pijl een mechanisme nodig heeft. Voeg toe: elke datagrens heeft een kwaliteitsbeslissing nodig: wat we accepteren, weigeren of in quarantaine zetten, en wie eigenaar is van de uitzondering.

Click to enlarge

Elke datagrens heeft een kwaliteitsbeslissing nodig.

Historische data is anders

RouteDesk bevat acht jaar historie van Steve Trucking, en de kwaliteit verschilt per distributiecentrum. Moeten we alle acht jaar opschonen tot de standaard van vandaag voordat we ze verplaatsen? Waarschijnlijk niet automatisch. Waarvoor is het: dagelijkse operatie, naslag, claims, rapportage, trendanalyse? Moet alles in Salesforce staan, of kan een deel ergens anders blijven? Het hoofdstuk over migratie gaat er diep op in. Het governancepunt: historie heeft niet automatisch dezelfde standaard nodig als actieve data. Als je er beslissingen op neemt, doet kwaliteit ertoe. Als je haar bewaart als naslag, volstaat misschien een andere standaard. Ken het doel voordat je een fortuin uitgeeft aan het opschonen van het verleden.

Meet waar iemand iets mee doet

Governance is nooit af, dus je moet zien wanneer de kwaliteit wegzakt: stijgende percentages duplicaten, meer records in quarantaine, meer weigeringen bij integraties, opvulwaarden die zich verspreiden, meer verzoeken om omwegen, rapporten die niet meer aansluiten. Maar bouw geen 150 metingen om er 143 te negeren. Voor Steve Trucking zijn het misschien leveringen zonder geldige partnerreferentie, leveringen zonder bruikbaar adres, herhaalde orderreferenties, geweigerde partnerberichten, accounts die in de voorlopige toestand blijven hangen. Een dashboard vol groene rondjes betekent niet dat de data goed is. Meet waar iemand bereid is iets mee te doen.

Voorbij het examen: wat AI verandert. Slechte data wordt steeds vaker slechte actie. Een mens merkt misschien dat een telefoonnummer er fout uitziet voordat hij belt; een agent gebruikt gewoon de waarde die hij krijgt. Dubbele klanten, verouderde statussen, nepwaarden in verplichte velden en foute identificatoren worden meteen het verkeerde bericht of de verkeerde update. Dat verhoogt de waarde van voorkomen. Het haalt de noodzaak van stewardship niet weg.

Wat een architect hier beslist

• Welke kwaliteitsfouten genoeg schade doen om preventieve controles te rechtvaardigen.
• Of bestuurde records vrij aangemaakt worden, alleen door het gezaghebbende systeem, of via een pad van voorlopig naar bestuurd.
• Van welke attributen Salesforce eigenaar is en naar welke het alleen verwijst.
• Wat er gebeurt met binnenkomende data die de controles niet doorstaat (accepteren, weigeren of in quarantaine zetten) en wie eigenaar is van de uitzondering.
• Welke kwaliteitssignalen gemeten worden, zodat stewards het wegzakken zien.

Je zult nooit elk slecht record voorkomen. De taak is geen perfecte data; het is voorkomen dat vermijdbare slechte data dure data wordt. Houd het duplicaat tegen voordat het twee jaar historie heeft. Bescherm de identificator voordat tien integraties van de verkeerde afhangen. Laat sales de prospect aanmaken, maar doe niet alsof het de bestuurde klant is tot het dat is. En als er toch iets slechts doorheen komt, zorg dan dat iemand het kan zien, er eigenaar van kan zijn en het kan repareren.

Verder lezen

• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (Engels, gecontroleerd op 2026-10-14).
• Salesforce Help, Break Up Your Record Details with Dynamic Forms (opens in a new tab) en Required and Read-Only Fields in Dynamic Forms (opens in a new tab) (Engels, gecontroleerd op 2026-10-14).