Wat is master data management?
Kort antwoord
Master data management (MDM) is de manier waarop je zorgt dat de vaste gegevens over je klanten, producten en leveranciers overal hetzelfde zijn. Je legt per gegeven vast welk systeem leidend is, geeft elk record een vaste sleutel en laat je koppelingen die afspraken uitvoeren. Voor de meeste MKB-bedrijven is daar geen apart MDM-pakket voor nodig.
Een klant belt dat zijn factuur naar het oude adres is gestuurd. Hij heeft de verhuizing drie maanden geleden doorgegeven, en in het CRM staat het nieuwe adres ook netjes. Alleen het boekhoudpakket wist het niet, en de webshop evenmin. Niemand heeft iets fout gedaan. Er staan gewoon drie versies van dezelfde klant in drie systemen, en ze zijn uit elkaar gegroeid.
Dat is in één zin het probleem dat master data management oplost. De term klinkt als iets voor multinationals met een datateam, en de pakketten die eronder verkocht worden zijn daar ook naar. Maar het onderliggende vraagstuk speelt bij elk bedrijf dat meer dan één systeem gebruikt. In dit artikel leg ik uit wat master data is, waar het misgaat en hoe je het zonder zwaar platform op orde krijgt.
Gartner omschrijft MDM als een discipline waarin business en IT samen verantwoordelijk zijn voor de eenduidigheid, juistheid en het beheer van de gedeelde stamgegevens van een organisatie. Let op het woord discipline: het is in de eerste plaats een set afspraken, en pas daarna software.
Master data, transactiedata en waarom het verschil ertoe doet
In elk bedrijfssysteem zitten twee soorten gegevens. Het helpt om ze uit elkaar te houden, omdat ze een heel ander soort zorg nodig hebben.
- Master data (stamdata): de vaste dingen waar je bedrijf mee werkt. Klanten, contactpersonen, producten, leveranciers, medewerkers, locaties, grootboekrekeningen. Ze bestaan lang en worden steeds bijgewerkt.
- Transactiedata: de gebeurtenissen die naar die vaste dingen verwijzen. Een order, een factuur, een levering, een geboekt uur. Is zo'n gebeurtenis afgerond, dan verandert hij niet meer.
- Referentiedata: de vaste lijsten waaruit je kiest, zoals landcodes, btw-tarieven, eenheden en statussen. Klein, maar overal gebruikt.
Het verschil doet ertoe omdat een fout in stamdata zich vermenigvuldigt. Een verkeerd adres bij één order is één verkeerde levering. Een verkeerd adres bij de klant is elke order, elke factuur en elke herinnering die daarna volgt. En omdat stamdata in meerdere systemen tegelijk leeft, wordt de fout ook nog eens in elk systeem anders.
Transacties vertellen wat er gebeurde. Stamdata vertelt over wie en wat het ging. Klopt dat laatste niet, dan klopt het eerste ook niet.
Waar het misgaat: vier herkenbare patronen
In bijna elk bedrijf dat ik van binnen zie, komen dezelfde patronen terug. Ze ontstaan niet door slordigheid, maar doordat systemen een voor een zijn aangeschaft, elk met een eigen klantenlijst.
Dezelfde klant op meerdere plekken aangemaakt
Sales maakt een prospect aan in het CRM. Na de eerste order maakt de administratie dezelfde klant aan in de boekhouding, met net een andere schrijfwijze: "Bakkerij De Vries B.V." tegenover "De Vries Bakkerij". De webshop maakt er bij de eerste online bestelling een derde van. Geen van de drie weet van de andere twee.
Wijzigingen die maar op één plek landen
Het adres, het e-mailadres voor facturen of de contactpersoon verandert. Wie de wijziging binnenkrijgt, past het aan in het systeem dat hij zelf gebruikt. De rest volgt nooit, of pas als er iets misgaat.
Productgegevens die per kanaal verschillen
De omschrijving in de webshop is herschreven, het gewicht in het voorraadsysteem is nooit bijgewerkt en de marktplaats toont een oude foto. Voor producten bestaat met de GTIN van GS1, in Nederland beter bekend als EAN-code, een wereldwijde sleutel. Maar die sleutel helpt alleen als je hem ook in elk systeem vastlegt en als koppelveld gebruikt.
Niemand die eigenaar is
Vraag in een overleg wie verantwoordelijk is voor de juistheid van de klantgegevens, en het blijft vaak stil. Sales vindt dat de administratie het bijhoudt, de administratie vindt dat sales de klant aanmaakt. Zonder eigenaar heeft niemand de opdracht om het verschil op te lossen.
De kern: per gegeven één leidend systeem
Het belangrijkste besluit in master data management is ook het minst technische: welk systeem is leidend voor welk gegeven? Leidend betekent dat het gegeven daar wordt aangemaakt en gewijzigd, en dat de andere systemen het van daaruit overnemen. Ze mogen het tonen en gebruiken, maar niet zelf aanpassen.
Dat hoeft niet per object hetzelfde systeem te zijn. Het kan per veld verschillen, zolang het per veld maar vastligt. Een veelvoorkomende verdeling bij een B2B-bedrijf ziet er zo uit.
| Gegeven | Leidend systeem | Waarom daar |
|---|---|---|
| Bedrijfsnaam, adres, contactpersonen | CRM | Sales maakt de relatie aan en spreekt de klant het vaakst |
| Btw-nummer, betaaltermijn, factuuradres | Boekhouding | De administratie is verantwoordelijk voor juiste facturen |
| Artikelnummer, EAN, gewicht, inkoopprijs | ERP of voorraadsysteem | Inkoop en logistiek werken ermee en controleren het fysiek |
| Productomschrijving, foto's, kenmerken voor de webshop | PIM of webshop | Marketing schrijft de teksten per kanaal |
| Medewerker, functie, afdeling | HR- of salarissysteem | Indiensttreding en vertrek worden daar als eerste vastgelegd |
Schrijf deze tabel uit voor je eigen bedrijf voordat je één koppeling bouwt of aanpast. Het is een middag werk met de mensen die de systemen dagelijks gebruiken, en het voorkomt maanden discussie achteraf. In mijn ervaring blijkt tijdens die middag vaak dat twee afdelingen hetzelfde veld als "van hen" beschouwen. Dat is precies het gesprek dat je wilt voeren.
Sleutels: hoe systemen weten dat het om dezelfde klant gaat
Een afspraak over het leidende systeem werkt alleen als de andere systemen een record ook kunnen terugvinden. Daar zijn sleutels voor: een kenmerk dat een klant of product uniek maakt en in elk systeem wordt bewaard.
- Een eigen centrale sleutel: een klantnummer dat het leidende systeem uitgeeft en dat elke koppeling meestuurt. Het andere systeem bewaart het in een apart veld, zodat een wijziging altijd bij het juiste record terechtkomt.
- Een externe sleutel: voor zakelijke klanten het KVK-nummer, voor producten de EAN-code. Handig om dubbelingen te herkennen, maar niet elk record heeft er een. Particulieren hebben geen KVK-nummer, en een KVK-nummer hoort bij een rechtspersoon, terwijl je soms met meerdere vestigingen werkt.
- Een koppeltabel: waar systemen geen extra veld toestaan, houdt de koppeling zelf bij dat klant 1042 in het CRM dezelfde is als debiteur 30517 in de boekhouding.
Het verleidelijke alternatief is matchen op naam of e-mailadres. Dat werkt tot een klant van naam verandert, een collega een ander e-mailadres gebruikt of iemand een spatie te veel typt. Een naam is een kenmerk, geen sleutel. Daarnaast moet een koppeling die wijzigingen doorzet bestand zijn tegen dubbele berichten. Hoe je dat aanpakt, beschrijf ik in het artikel over idempotency bij API-koppelingen.
De meeste dubbele klanten ontstaan niet bij het invoeren, maar bij een koppeling die niet wist dat de klant al bestond.
Drie manieren om het in te richten
Er bestaan drie gangbare opzetten. Ze lopen op in omvang, en je kiest de lichtste die je probleem oplost.
1. Afspraken plus koppelingen
Je legt het leidende systeem per gegeven vast, geeft elk record een sleutel en laat de koppelingen wijzigingen in één richting doorzetten: van leidend naar volgend. In de volgende systemen maak je de velden alleen-lezen, of je laat de koppeling een wijziging daar overschrijven. Voor de meeste bedrijven met een handvol systemen is dit genoeg, en het is ook de opzet die het makkelijkst uit te leggen is aan een nieuwe collega.
2. Een centrale stamdatabase
Heb je veel systemen, of is geen van je pakketten geschikt als leidend systeem, dan kun je een eigen centrale plek bouwen. Elk systeem levert daar zijn versie aan, de centrale database legt de records naast elkaar, kiest per veld de juiste waarde en stuurt het resultaat terug. In de vakliteratuur heet dat ene samengevoegde record het golden record. Dit vraagt meer bouwwerk, maar je krijgt ook een plek waar je kunt zien waar een klant overal staat.
3. Een MDM-platform
Gespecialiseerde MDM-software biedt dit allemaal kant-en-klaar, met matchregels, goedkeuringsstappen en beheerschermen. Dat loont bij grote organisaties met tientallen bronnen, meerdere landen of werkmaatschappijen, of een assortiment met tienduizenden producten en veel kenmerken per product. Voor een MKB-bedrijf is het meestal te veel: je betaalt voor een complexiteit die je niet hebt, en je hebt een extra systeem dat iemand moet beheren.
Voor productgegevens bestaat er nog een tussenvorm: een PIM-systeem (product information management). Dat is in feite een MDM-oplossing alleen voor producten, gericht op teksten, foto's en kenmerken per verkoopkanaal. Verkoop je via een eigen webshop en meerdere marktplaatsen, dan is dat vaak de eerste plek waar een apart systeem zijn waarde bewijst.
Bestaande vervuiling opruimen
De afspraken en sleutels voorkomen nieuwe problemen, maar de bestaande dubbelingen en verschillen moet je één keer opruimen. Dat gaat in vaste stappen.
- Exporteren: haal de klant- of productlijsten uit alle systemen naast elkaar, met de sleutels die er al zijn.
- Normaliseren: maak namen, adressen en telefoonnummers vergelijkbaar. Hoofdletters, rechtsvormen als "B.V.", spaties in postcodes en landcodes zorgen anders voor gemiste matches.
- Matchen: zoek eerst op harde sleutels zoals KVK-nummer, btw-nummer of EAN. Daarna op een combinatie van genormaliseerde naam en postcode.
- Laten beoordelen: zekere matches voeg je automatisch samen. Twijfelgevallen gaan naar een mens die de klant kent. Dit is de stap die je niet moet willen automatiseren.
- Vastleggen: schrijf de gevonden koppelingen terug als sleutel in elk systeem, zodat de koppelingen vanaf nu het juiste record vinden.
Let bij het samenvoegen op de transacties die aan een record hangen. Twee debiteuren samenvoegen in een boekhoudpakket heeft gevolgen voor openstaande posten en historie. Doe dat in overleg met de administratie, en bij voorkeur niet midden in een afsluitperiode.
Master data en de AVG
Klantgegevens zijn vaak persoonsgegevens, zeker bij particulieren en bij contactpersonen van zakelijke klanten. Dan gelden de beginselen uit artikel 5 van de AVG, en een daarvan is juistheid: persoonsgegevens moeten juist zijn en zo nodig worden bijgewerkt. Staat een klant in vier systemen en wijzig je zijn adres in één, dan verwerk je in de andere drie gegevens waarvan je weet dat ze niet meer kloppen.
Het speelt nog sterker bij de rechten van betrokkenen. Vraagt iemand om inzage of om zijn gegevens te wissen, dan moet je weten in welke systemen hij staat. Met een centrale sleutel en een overzicht van waar welke gegevens leven, is dat een lijstje afwerken. Zonder is het zoeken in elk pakket afzonderlijk, met de kans dat je er een vergeet. Meer over de bredere eisen lees je in het artikel over AVG in webapplicaties.
Dat geeft master data management een tweede reden van bestaan naast efficiëntie: het maakt de verantwoordingsplicht uitvoerbaar. Je kunt laten zien waar gegevens vandaan komen en hoe ze actueel blijven.
Mijn kijk op master data management
Ik word regelmatig gevraagd om een koppeling te bouwen die "alles in sync houdt". Twee kanten op, elk systeem mag alles wijzigen, en de koppeling zorgt dat het overal hetzelfde wordt. Dat klinkt redelijk, maar het verschuift de vraag alleen. Wijzigt iemand het adres in het CRM en iemand anders tegelijk in de boekhouding, welke wint dan? Die keuze moet ergens gemaakt worden, en als je hem niet vooraf maakt, maakt de code hem voor je, op een manier die niemand heeft bedacht.
Daarom begin ik bij elk koppelingstraject met de tabel uit dit artikel: per gegeven één leidend systeem. Het is het minst spannende onderdeel van het project en het onderdeel dat later de meeste problemen voorkomt. De techniek daarna is overzichtelijk. Een koppeling die in één richting werkt met een vaste sleutel, is makkelijker te bouwen, te testen en uit te leggen dan een tweezijdige synchronisatie die alles probeert te verzoenen.
En ik zie dat goede stamdata de basis is voor alles wat erna komt. Een rapportagedatabase die klanten uit drie systemen moet combineren, of een AI-assistent die vragen over je klanten beantwoordt, is zo betrouwbaar als de klantenlijst eronder. Wie daar eerst orde schept, hoeft later minder te repareren.
— Jasper
Zo helpt Coding Agency hierbij
Wij bouwen koppelingen tussen CRM, boekhouding, webshop en eigen software, en beginnen daarbij altijd met de vraag welk systeem waarvoor leidend is. Bestaande dubbelingen ruimen we op met een vergelijking die de zekere gevallen samenvoegt en de twijfelgevallen aan je team voorlegt. Wil je eerst weten wat koppelen je kan opleveren, lees dan waarom systemen koppelen, of hoe je met een semantische laag ook je cijfers eenduidig maakt.
Herken je de klant die drie keer in je systemen staat? Neem contact op voor een vrijblijvend gesprek.
