Master Data Management
Dezelfde klant staat in drie systemen, met drie verschillende adressen. Welke waarde geldt? Wie mag die wijzigen? En vanaf wanneer? Master Data Management begint bij het beantwoorden van zulke vragen.
1. Wat is MDM?
Master Data Management (MDM) is het organiseren van het beheer van gedeelde stamgegevens. Het omvat de afspraken, verantwoordelijkheden, processen en techniek waarmee een organisatie bepaalt welke gegevens zij als leidend gebruikt en hoe die gegevens worden onderhouden en verspreid.
Masterdata beschrijft herkenbare entiteiten die in bedrijfsprocessen terugkomen, zoals klanten, leveranciers, producten en locaties. Een klant kan in het verkoopsysteem een klantnummer hebben en in het financiële systeem een debiteurnummer. MDM helpt vast te stellen of beide records dezelfde klant beschrijven, welke gegevens gedeeld worden en welke bron voor welk gegeven bevoegd is.
Masterdata, referentiedata en transactiedata
Een klant is masterdata. Een bestelling van die klant is transactiedata. De landcode bij het klantadres komt uit referentiedata: een beheerde verzameling codes of waarden waarmee andere gegevens worden aangeduid of ingedeeld. Ook referentiedata heeft definities, eigenaarschap, versies en geldigheidsafspraken nodig.
MDM kan worden ondersteund door een gespecialiseerde toepassing, maar begint met inhoudelijke keuzes. Een centrale database maakt bijvoorbeeld nog niet duidelijk of met “klant” een persoon, een rechtspersoon, een huishouden of een vestiging wordt bedoeld.
2. Wanneer MDM?
De behoefte wordt zichtbaar wanneer dezelfde gegevens op verschillende plaatsen worden gebruikt en verschillen gevolgen krijgen. Een verhuizing wordt wel in het ene systeem verwerkt en niet in het andere. Twee afdelingen maken dezelfde leverancier aan. Een rapport telt vestigingen als afzonderlijke klanten, terwijl een ander rapport op rechtspersoon telt.
Vragen die helpen de behoefte vast te stellen:
- Welke stamgegevens worden door meerdere processen of systemen gebruikt?
- Welke fouten of verschillen ontstaan, en wat kosten die aan herstel, tijd of vertrouwen?
- Is duidelijk wie de betekenis en de inhoud van de gegevens mag bepalen?
- Kunnen afnemers zien welke waarde zij moeten gebruiken en hoe actueel die is?
- Hoe worden conflicten, dubbele records en correcties afgehandeld?
Niet ieder verschil is een fout. Een factuuradres en een afleveradres kunnen terecht afwijken. Eerst moet duidelijk zijn of twee waarden hetzelfde gegeven beschrijven. Anders kan een poging om gegevens gelijk te trekken juist betekenis verliezen.
De omvang van de inrichting moet passen bij het probleem. Eén toepassing met duidelijk eigenaarschap kan met beperkte beheerafspraken uitkomen. Een keten van organisaties met verschillende bevoegdheden vraagt doorgaans om meer afstemming. Begin met de gegevens en risico’s die ertoe doen.
3. Wat biedt MDM?
Een bruikbare MDM-inrichting maakt afspraken uitvoerbaar. Zij kan helpen bij het herkennen van dezelfde entiteit in verschillende bronnen, het behandelen van dubbele records en het beschikbaar stellen van gegevens die aan afgesproken voorwaarden voldoen.
- Gedeelde betekenis: definities en identificatieregels maken duidelijk waarover systemen gegevens uitwisselen.
- Beheerst onderhoud: vastligt wie een wijziging mag voorstellen, beoordelen en doorvoeren.
- Navolgbare keuzes: herkomst, selectieregels en besluiten verklaren hoe een waarde tot stand is gekomen.
- Betrouwbaarder hergebruik: afnemers weten welke gegevens zij mogen gebruiken en welke beperkingen gelden.
- Gericht herstel: fouten worden bij de bevoegde bron aangepakt en correcties bereiken de betrokken afnemers.
MDM neemt de inhoudelijke verantwoordelijkheid niet over. Een waarde kan aan alle vastgelegde controles voldoen en toch feitelijk onjuist zijn. Daarom horen ook meldingen van gebruikers, uitzonderingen en herstel bij het beheerproces.
Maak de opbrengst meetbaar. Denk aan de tijd die een correctie nodig heeft om afnemers te bereiken, het aantal onopgeloste conflicten of de hoeveelheid handmatig herstel. Kies metingen die bij het oorspronkelijke probleem passen.
4. Relatie tot andere DAMA-DMBOK kerndomeinen
Binnen DAMA-DMBOK vallen masterdata en referentiedata onder het kerndomein Reference & Master Data. De uitvoering raakt aan de andere kerndomeinen. Onderstaande voorbeelden laten zien hoe die samenwerking er praktisch uit kan zien.
| Kerndomein | Relatie met MDM |
|---|---|
| Data Governance | Belegt zeggenschap, besluitvorming en de afhandeling van conflicten. |
| Data Architecture | Bepaalt de plaats van bronnen, beheer en afnemers in de gegevensvoorziening. |
| Data Modeling & Design | Beschrijft entiteiten, identificaties, attributen, relaties en tijdsdimensies. |
| Data Storage & Operations | Ondersteunt beschikbaarheid, herstel, historie en consistente verwerking. |
| Data Security | Regelt wie welke gegevens mag lezen, wijzigen of verspreiden. |
| Data Integration & Interoperability | Verzorgt uitwisseling, omzetting van identificaties en verwerking van wijzigingen. |
| Document & Content Management | Beheert onderliggende stukken, zoals bewijs voor een naamswijziging, en hun relatie met de stamgegevens. |
| Data Warehousing & Business Intelligence | Gebruikt gedeelde identificaties, definities en historische waarden bij analyses. |
| Metadata Management | Legt betekenis, herkomst, bronbevoegdheid en bewerkingsregels vast. |
| Data Quality | Stelt eisen, controleert afwijkingen en ondersteunt structurele verbetering. |
Ook data classes, of semantische datatypen, kunnen hierbij helpen. Zij beschrijven bijvoorbeeld het canonieke formaat, de opslag en de weergave van een e-mailadres. Dat maakt waarden vergelijkbaar. Of het e-mailadres daadwerkelijk bij de betreffende klant hoort, vraagt om aanvullende afspraken en controles.
5. Golden record en datagranulariteit
Een golden record is de volgens afgesproken regels geaccepteerde representatie van een entiteit. Die kan fysiek worden opgeslagen of als samenhangend beeld uit meerdere bronnen worden samengesteld. De naam beschrijft de beoogde gezaghebbende rol; zij is geen bewijs dat ieder gegeven juist is.
Welke bron bepaalt welke waarde?
De ene bron kan bevoegd zijn voor de juridische naam en een andere voor een contactadres. Bij conflicten bepalen selectieregels, vaak survivorship rules genoemd, welke waarde wordt overgenomen. “De nieuwste waarde wint” werkt alleen als die keuze inhoudelijk gerechtvaardigd is. Een recente invoerfout wordt niet juist doordat zij recenter is.
Het herkennen van dezelfde entiteit heet matching. Vervolgens kunnen records worden gekoppeld of worden samengevoegd (merging). Dat samenvoegen hoeft niet te betekenen dat bronrecords worden verwijderd. Bewaar de herkomst en maak duidelijk hoe een foutieve samenvoeging kan worden hersteld.
Op welk niveau beheert u de gegevens?
Datagranulariteit is de mate van detail waarop u gegevens onderscheidt en beheert. Bij MDM gaat het onder meer om de keuze tussen een hele entiteit, een groep samenhangende attributen, een afzonderlijk attribuut of een relatie. Een rechtspersoon en haar vestigingen zijn bijvoorbeeld verschillende niveaus.
Een golden record kan waarden uit meerdere bronnen bevatten, maar ook samenhang moet worden bewaakt. Een postcode uit bron A en een huisnummer uit bron B vormen samen niet vanzelf een geldig adres. Soms moet een groep attributen als één geheel worden geselecteerd en gevalideerd.
Een system of record is de aangewezen registratie voor bepaalde gegevens. Een source of truth is de afgesproken gezaghebbende bron voor een bepaald gebruik. Een golden record is het geaccepteerde resultaat. Leg de reikwijdte van deze begrippen vast: bevoegdheid kan per gegeven verschillen.
6. Registratie, geldigheid en validatie
Een waarde zonder tijdscontext kan een verkeerd antwoord geven. Het huidige klantadres vertelt bijvoorbeeld niet welk adres op een eerdere datum gold, wat het systeem toen wist of welke versie toen al was goedgekeurd.
| Tijd | Betekenis in dit artikel |
|---|---|
| Registratietijd | Wanneer een versie in het betreffende systeem is vastgelegd en als geregistreerde versie aanwezig was. |
| Geldigheidstijd | De periode waarvoor een gegeven van toepassing is volgens de beschreven werkelijkheid of bedrijfsafspraak. |
| Validatietijd | Wanneer een bevoegde controle de betreffende versie heeft geaccepteerd, en zo nodig gedurende welke periode die acceptatie gold. |
Voorbeeld: registratie in A, validatie in B
Stel: systeem A en datahub B gebruiken dezelfde klantgegevens. B beheert de golden records. Op 1 maart om 10:00 legt een gebruiker in A een klant vast. Het record wordt vrijwel direct naar B gerepliceerd. B controleert of de klant al bestaat en of de gegevens aan de afgesproken voorwaarden voldoen.
In dit voorbeeld wordt het record om 10:00:02 in B geregistreerd en om 10:04 als nieuwe klant geaccepteerd. Volgens de onderliggende afspraak is de klantrelatie die dag om 09:00 ingegaan.
- Geldig vanaf: 1 maart, 09:00.
- Geregistreerd in A: 1 maart, 10:00.
- Geregistreerd in B: 1 maart, 10:00:02.
- Gevalideerd door B: 1 maart, 10:04.
Om 10:02 bevat B dus al een registratie, maar nog geen geaccepteerde nieuwe klant. Een proces dat uitsluitend gevalideerde klanten mag gebruiken, moet daarmee rekening houden. De latere validatie verandert de registratietijd niet. Of de geldigheid bij registratie, validatie of een ander moment begint, volgt uit de bedrijfsafspraak.
Bitemporeel en tritemporeel
De gebruikelijke bitemporele benadering onderscheidt geldigheidstijd (valid time) en registratietijd (transaction time of system time). Daarmee kunt u vragen: “Welk adres gold op 1 maart, volgens wat wij op 5 maart hadden geregistreerd?” Een later ontvangen correctie hoeft de eerdere kennisstand dan niet uit te wissen.
Validatie kan als een derde, onafhankelijke tijdsdimensie worden gemodelleerd. In dit artikel gebruiken we tritemporeel voor die uitbreiding met validatiehistorie. De betekenis van een derde tijdsdimensie is niet universeel: andere modellen kiezen bijvoorbeeld besluitvorming of beschikbaarstelling. Daarom moet de definitie altijd bij het model staan.
Drie losse datumvelden leveren nog geen volledige temporele historie op. Bewaar de relevante versies en perioden, koppel een validatie aan de gecontroleerde versie en leg vast wie of wat heeft gecontroleerd en volgens welke regels. Ook een afwijzing, correctie, herbeoordeling of ingetrokken acceptatie moet achteraf te reconstrueren zijn.
Bij een periode kan een begin- en eindtijd nodig zijn. Een duidelijke afspraak is bijvoorbeeld: het begin hoort bij de periode, het einde niet. Leg bovendien tijdzone en precisie vast. Registratietijd is systeemgebonden; de ontvangsttijd in B mag niet ongemerkt de oorspronkelijke registratietijd in A vervangen.
7. Vergelijking van MDM-architecturen
De architectuur bepaalt waar onderhoud plaatsvindt en hoe het geaccepteerde beeld beschikbaar komt. Hieronder staan vier veelgebruikte implementatiestijlen. Benamingen kunnen per leverancier verschillen.
| Architectuur | Onderhoud | Centrale voorziening | Aandachtspunt |
|---|---|---|---|
| Registry | In de bronnen. | Koppelt bronidentificaties; stelt een gedeeld beeld samen. | Raadpleging kan afhankelijk blijven van bronbeschikbaarheid en actualiteit. |
| Consolidation | In de bronnen. | Bewaart een samengevoegde kopie, vaak voor analyse en rapportage. | Bronfouten verdwijnen niet vanzelf; vertraging blijft relevant. |
| Coexistence | Verdeeld, met afgesproken bevoegdheden. | Beheert een golden copy en verspreidt die naar afnemers. | Conflicten, wijzigingsvolgorde en terugkoppeling vragen expliciete regels. |
| Centralized | Centraal voor de gekozen gegevens. | Is de aangewezen registratie; stelt gegevens beschikbaar aan afnemers. | Afhankelijkheid van de centrale voorziening vraagt om herstel- en beschikbaarheidsafspraken. |
Deze indeling beschrijft de plaats van beheer en het gedeelde beeld. Zij zegt niet dat iedere uitwisseling direct plaatsvindt of dat iedere organisatie één stijl voor al haar stamgegevens moet kiezen. Klantgegevens en productgegevens kunnen verschillende eisen stellen. Ook een combinatie binnen een domein is mogelijk.
Voor iedere variant moet vastliggen wat er gebeurt bij een onbereikbare bron, een vertraagde wijziging of twee strijdige updates. Een centrale voorziening voorkomt zulke situaties niet automatisch.
8. Beslisboom voor de architectuurkeuze
Gebruik deze vragen om een eerste richting te bepalen voor de gegevens die u wilt beheren. De uitkomst is een startpunt voor verdere afweging. Beoordeel ook wettelijke eisen, kosten, bestaande toepassingen, tijdseisen en de bevoegdheden van betrokken partijen.
Bekijk de volledige beslisboom
- Moet het onderhoud van de gedeelde masterdata volledig centraal plaatsvinden?
Ja: onderzoek centralized MDM. Nee: ga naar vraag 2. - Moet een centraal samengesteld record worden teruggeleverd aan operationele systemen, terwijl onderhoud verdeeld blijft?
Ja: onderzoek coexistence. Nee: ga naar vraag 3. - Is een centraal opgeslagen, samengevoegd beeld vooral nodig voor analyse of rapportage?
Ja: onderzoek consolidation. Nee: ga naar vraag 4. - Wilt u verspreide records koppelen en als samenhangend beeld raadplegen?
Ja: onderzoek registry. Nee: werk eerst de behoefte en de afbakening verder uit.
Toets de richting vervolgens met concrete wijzigingen: een nieuw record, een verhuizing, een dubbel record, een correctie met terugwerkende kracht en een ingetrokken validatie. Kunnen beheerder en afnemer in iedere situatie bepalen welke gegevens zij mogen gebruiken?
Begrippen bij dit artikel
Onder meer MDM, masterdata, referentiedata, golden record, datagranulariteit, matching, merging, survivorship, de vier architectuurstijlen en de drie tijdsdimensies worden toegelicht in de begrippenlijst datamanagement.
Bronnen en afbakening
De architectuurvergelijking sluit aan bij de onderstaande leveranciersdocumentatie. De relaties tussen kerndomeinen, de beslisboom en het klantvoorbeeld zijn een praktische uitwerking voor dit artikel. Validatietijd wordt hier expliciet als eigen modelleringskeuze gedefinieerd.