Basisprincipes van Master Data Management

MDM wordt taai als de systemen in een bedrijf zijn uitgegroeid tot een kluwen zonder logische structuur. Dezelfde klant of hetzelfde artikel staat op meerdere plekken, de ene afdeling houdt haar kopie bij en de andere niet, en na een tijdje weet niemand meer welke versie klopt. Op informatie die je niet vertrouwt, kun je geen inkoop, verkoop of rapportage draaien, dus het probleem duikt overal tegelijk op: een factuur gaat naar een oud adres, de voorraad klopt niet met de artikelkaart en twee afdelingen rekenen dezelfde KPI anders uit. Deze gids legt uit wat MDM is, zet vier principes op een rij die het dagelijkse werk weer te overzien maken, beschrijft de vier pijlers van een MDM-programma en laat zien hoe MDM verschilt van PIM. Alleen de afkorting nodig? Zie waar MDM voor staat.

Wat is master data management (MDM)?

Master data management (MDM) is de afspraak, en de tooling, om de kritieke records van een organisatie één keer vast te leggen en zo te houden. Mensen, proces en technologie maken en houden samen één gezaghebbende bron bij, vaak het gouden record genoemd, voor data zoals klanten, producten, leveranciers en locaties. In de praktijk betekent dat één afgesproken versie van elke klant, elk product en elke leverancier, waar elk ander systeem naar verwijst. Elk systeem houdt dus niet langer een eigen versie bij die het zelf verbetert. Het doel is consistentie, nauwkeurigheid en toegang over de systemen heen.

Formeler gezegd is master data management de reeks processen om die data te verzamelen, te aggregeren, te matchen, te consolideren, op kwaliteit te borgen, te bewaren en te verspreiden, zodat de organisatie één begrip van het record deelt en integratie elk systeem naar één referentie kan wijzen. Elk van die stappen lost iets anders op: matchen vindt de records die hetzelfde beschrijven, consolideren bepaalt welke waarden blijven staan, en verspreiden zorgt dat het resultaat ook aankomt in de systemen die het nodig hebben. In de gemasterde set kunnen de toegestane waarden zitten (referentiedata, zoals landcodes of maateenheden) en de analytische data waarmee je beslist.

Een MDM-tool ondersteunt dat werk. Hij haalt duplicaten weg, standaardiseert waarden in massaal onderhoud en blokkeert foute invoer met regels, zodat het resultaat als gezaghebbende bron kan dienen. De tool zit meestal als middleware tussen de systemen die data maken en de systemen die data gebruiken. Wat juist is, bepaalt de tool overigens niet zelf. Mensen spreken de regels en de matchcriteria af, en de tool past ze consequent toe op elk record dat erdoorheen gaat.

ERP

Naam

Zinkschroeven 20 * 30

Gewicht

0,012 kg

Leverancier

SUP-1047

Spreadsheet

Naam

zinkschroef 20x30

Gewicht

12 g

Leverancier

Leverancier 1047

Leveranciersportaal

Naam

Schroef, zink, 20*30

Gewicht

12 gr

Leverancier

1047

Matchen en samenvoegen

★Gouden record Voorbeeld

Naam

Zinkschroeven 20 * 30Eén plek van invoer

Gewicht

12 gEén afgesproken eenheid

Leverancier

Leverancier 1047Gekoppeld record

Elk systeem leest daaruit

• ERP & finance
• CRM & sales
• PIM & webshop
• WMS & logistiek
• BI & rapportage

Waarom records uit elkaar lopen

MDM bestaat omdat kritieke records na verloop van tijd uit elkaar lopen. Product-, asset-, klant- en locatiedata die op de dag van een migratie nog klopten, kloppen een jaar later niet meer, omdat elk systeem door andere mensen voor een ander doel wordt bijgehouden. Een bedrijf dat over grenzen werkt, draait veel applicaties, onder meer ERP, CRM en PDM, en na een paar overnames vaak van elk meerdere. Data die een afdelingsgrens oversteekt, wordt in het volgende systeem gekopieerd en daarna niet meer bijgewerkt. Een simpele KPI zoals omzet per klant wordt dan een discussie over welk extract klopt.

De oorzaak zit meestal in segmentatie. Dezelfde klant wordt bediend door verschillende business units en productlijnen, en elke lijn typt de klant (de partij in de klantrol) en de rekening opnieuw in. Een groothandel die dezelfde installateur bedient via de webshop, de balie in de vestiging en een key-accountteam, heeft zo al snel drie klantrecords, elk met een net andere naam, een eigen adres en eigen betalingsvoorwaarden. Van front office naar back office vermenigvuldigt die kopie zich, juist waar één bron nodig was.

Consistente stamdata levert iets op in je beslissingen, in de operatie en bij compliance. Rapportage en analyse worden beter, omdat ze één betrouwbare bron lezen in plaats van een samengevoegde export die iemand met de hand heeft verbeterd. Processen worden eenvoudiger, omdat ze geen kopieën meer hoeven te vergelijken, bijvoorbeeld wanneer een order blijft hangen omdat het btw-nummer van de klant in het CRM anders is dan in het ERP. En naleving van regels leunt op data die nauwkeurig is en bestuurd wordt: een auditor accepteert die data pas als je kunt laten zien waar elke waarde vandaan kwam en wie haar heeft gewijzigd.

Wat zijn stamgegevens? (en wat niet?)

Stamgegevens zijn de bedrijfsobjecten met de informatie die de organisatie heeft afgesproken en deelt. Ze zetten transacties in context: wie, wat, wanneer en hoe, plus de categorieën, groepen en hiërarchieën waarmee je die transacties leest. Klanten, producten, medewerkers, materialen en leveranciers horen er standaard in, en er kan relatief statische referentiedata in zitten. Een orderregel op zich zegt weinig. Hij krijgt pas betekenis als hij verwijst naar een klant met een segment, een product met een categorie en een locatie met een regio.

Meestal gelden stamgegevens als niet-transactioneel, maar de grens is niet scherp. Soms bestaat die informatie alleen in orders en ontvangsten, zonder aparte opslag, en dan behandelt de organisatie die transactionele kopie als stamdata. Als noodoplossing kan dat. Het betekent wel dat je elke correctie in oude documenten moet doorvoeren en dat elk rapport de waarde uit transacties moet opdiepen, en daarom hoort het een uitzondering te blijven.

In dezelfde gesprekken kom je vier andere termen tegen. Haal je die door elkaar, dan wordt onduidelijk wat een MDM-programma moet dekken. Elk beschrijft een andere soort data, met eigen eigenaren en een eigen volume:

• Transactiedata beschrijft gebeurtenissen in het bedrijf, zoals orders, facturen en zendingen. Het is het grootste volume, en het staat in CRM, ERP, SCM en vergelijkbare systemen.
• Logdata legt gebeurtenissen vast of maakt een momentopname van een processtatus: sensor-, machine- en change-in-state data. Operatie en preventief onderhoud leunen erop.
• Metadata beschrijft andere data, bijvoorbeeld wie een record heeft aangemaakt en wanneer. Stamdata, referentiedata en logdata hebben elk hun eigen metadata.
• Big data mengt, in de definitie van Doug Laney bij Gartner (volume, variëteit en snelheid), logdata, transactiedata, referentiedata en stamdata. Het is geen aparte soort bedrijfsobject.

Dat onderscheid telt zodra je de reikwijdte van het werk bepaalt. Stamdata bestuur je record voor record, want één fout bankrekeningnummer van een leverancier of één fout artikelgewicht doet schade in elk proces dat die waarde gebruikt. Transactie- en logdata bestuur je vooral via de processen die ze aanmaken, en metadata maakt alles samen herleidbaar.

Productstamgegevens

Productstamgegevens, ook wel artikelstam of in een ERP de materiaalstam genoemd, zijn het productdomein van MDM. Ze bevatten wat elk systeem nodig heeft om een artikel in te kopen, op te slaan, te verkopen en te verzenden: codes, omschrijvingen, eenheden, afmetingen, gewichten, classificaties en leverancierskoppelingen.

Welke velden "master" zijn, volgt uit het proces. Een logistiek proces draait op volume, afmetingen en gewicht: de afmetingen bepalen hoeveel opslagruimte een artikel inneemt, en het gewicht bepaalt hoe het wordt verpakt en behandeld. Die eigenschappen leg je per artikel één keer vast, vaak aangevuld met kleur, barcode en verpakking, en je stelt ze beschikbaar in het WMS of ERP. Dan hoeft niemand dezelfde doos opnieuw te meten bij ontvangst, in het magazijn en bij verzending. De boekhouding heeft andere objecten nodig, zoals kostprijzen en grootboekrekeningen, en een medisch proces weer andere. Benoem eerst de kritieke velden van het proces dat je draait, voordat je een record "master" noemt.

De verkoopbare versie van het product is iets anders. Marketingteksten, kanaalattributen, vertalingen en beeld horen in een PIM, die het masterrecord leest en verrijkt. Een gebruikelijke verdeling: het ERP bevat het artikelnummer, het gewicht en de inkoopeenheid, de PIM de productnaam voor de webshop, de verkoopargumenten, de vertalingen en de link naar de hoofdfoto. Een ERP-migratie is vaak het moment waarop productstamdata wordt opgeschoond; dit stuk over S/4HANA-programma's legt uit waarom dat werk niet bij het ERP moet stoppen.

De vier principes van master data management

De pijlers verderop in deze gids beschrijven een volledig programma. De vier principes hieronder zijn kleiner en praktischer: dit is wat een datamanager of key user elke week controleert. Ze gelden in welk systeem het masterrecord ook staat, of dat nu een ERP is, een aparte MDM-hub of, voor het productdomein, een PIM.

Principe 1: een duidelijke herkomst

Een dataveld moet vaak op meerdere plekken in het netwerk tegelijk bestaan. Het gewicht van een artikel staat bijvoorbeeld in het ERP, het WMS, de webshop en het verzendsysteem van de vervoerder. Wijzig je het op één plek, dan moeten de andere mee, anders lopen ze uit elkaar en geeft elk systeem een ander antwoord.

Houd het aantal kopieën zo klein als het kan. Schrappen lukt niet altijd, want een applicatie leest de waarde van een vaste locatie en de meeste velden bestaan maar voor één applicatie. Een kopie is soms dus de prijs die je betaalt om die applicatie te laten draaien. Wat je wel kunt doen, is elke kopie zichtbaar maken en haar een bekende bron geven.

Goed MDM begint met het tekenen van die kaart: welke systemen en bestanden welke velden bevatten. Daarna leg je de routing vast, dus welk veld in welk systeem of bestand als eerste gevuld wordt en welke velden daaruit volgen. Laat die routing bij voorkeur vanzelf lopen via een koppeling, zodat niemand waarden met de hand overneemt. Kijk of het centrale systeem de data kan bevatten die de andere applicaties gebruiken, zodat je maar op één plek onderhoudt. Lukt dat niet, markeer dan in de volgende applicatie welke velden uit het eerste bestand kwamen, zodat gebruikers weten dat ze die daar niet moeten aanpassen. Grijze vlakken op de kaart betekenen meestal dat de data ergens anders vandaan kwam, en daar kijk je als eerste. Dit is het architectuurprincipe achter MDM: één plek van invoer per veld, en elk ander systeem leest daaruit of is duidelijk gemarkeerd als kopie.

Als de route vaststaat, benoem je wie de velden vult. Dat is meestal een key user die weet hoe de velden in het eigen domein zich gedragen: een key user bij inkoop weet welke leveranciersvelden gevuld moeten zijn voordat een order de deur uit kan, en een key user bij logistiek weet wat er misgaat als een pallethoogte ontbreekt. Excel is voor die controle een praktisch hulpmiddel. Een export van de sleutelvelden en de velden die ervan afhangen, laat snel zien welke records onvolledig zijn en welke waarden niet kloppen.

Principe 2: schrijf het altijd hetzelfde

Omschrijving en codering moeten consistent zijn. Zoeken werkt alleen als het woord steeds gelijk gespeld wordt: "Zinkschroeven 20 * 30", en niet ook "ijzeren schroef 40". Voor codes en eenheden geldt hetzelfde. Voert de ene inkoper een lengte in millimeters in en de andere in centimeters, of schrijft de een "verz." en de ander "verzinkt", dan splitsen filters en rapporten één productgroep op in meerdere. Een klant die in de webshop zoekt, vindt dan maar een deel van het assortiment.

Integraties en migraties zijn waar dit stukloopt, omdat twee manieren van benoemen elkaar tegenkomen en niemand de taak heeft ze samen te voegen. Zet het meteen terug op orde, zolang de mensen die beide manieren kennen er nog bij betrokken zijn. Elke maand dat de mix blijft staan, komen er records in beide stijlen bij, en de opschoning groeit mee. Een korte naamgevingsgids per productgroep, met de afgesproken afkortingen en eenheden, voorkomt het grootste deel van het probleem.

Principe 3: vul in wat gevuld hoort te zijn

Een veld dat gevuld moet zijn, is gevuld. Dat klinkt vanzelfsprekend, maar in de meeste artikelbestanden blijven de gaten onzichtbaar tot er iets misgaat: een order kan niet weg omdat het gewicht leeg is, of een product ontbreekt in een webshopfilter omdat één attribuut nooit is ingevuld. Welke velden verplicht zijn, hangt af van het soort record en het proces, dus leg volledigheid vast per productgroep of klanttype. Eén lijst met verplichte velden voor het hele bestand is te streng voor eenvoudige artikelen of te ruim voor complexe. Maak daarna in één oogopslag zichtbaar waar nog aangevuld of gecorrigeerd moet worden, bijvoorbeeld met een volledigheidsscore per record of een wekelijkse uitzonderingslijst voor de verantwoordelijke key user.

Principe 4: onderhoud elke week

Stamdata veroudert. Leveranciers veranderen hun verpakking, klanten verhuizen, artikelen krijgen een opvolger, en een record dat vorig jaar klopte, is ongemerkt fout geworden. Onderhoud heeft daarom een vast ritme nodig, geen grote opschoonactie om de paar jaar. Richt een werkgroep in die wekelijks onderhoud doet, onder leiding van een logistiek manager of een financieel manager, want zij merken de gevolgen van slechte data als eersten. De datamanager krijgt of geeft het werk via die groep. Zo blijven de prioriteiten helder en repareert het datateam geen records waar niemand om vroeg.

De vier pijlers van een MDM-strategie

De principes beschrijven het dagelijkse werk. Een MDM-strategie, het programma dat ze overeind houdt, rust op vier pijlers: data governance, datakwaliteitsbeheer, data-integratie en beheer van de masterdata-levenscyclus. Elke pijler kost meer tijd en mensen dan teams verwachten, dus breng eerst je huidige systemen en data in kaart voordat je eraan begint. Die inventarisatie laat ook zien waar je moet beginnen, want de meeste organisaties zijn op de ene pijler veel verder dan op de andere.

Pijler 1: data governance

Governance is de structuur om databeheer te overzien: wie welke data bezit, welke regels gelden en hoe je compliant blijft. Het telt het zwaarst bij meerdere datadomeinen en complexe regelgeving, en organisaties overschatten vaak hoe klaar ze ervoor zijn.

Governance begint bij eigenaarschap. Wijs datastewards aan uit de bedrijfsonderdelen en niet alleen uit IT, want zij kennen de nuances van hun eigen domein: marketing kan eigenaar zijn van de nauwkeurigheid van klantdata, finance van de integriteit van transactiedata en inkoop van de leveranciersrecords. Stewards die regelmatig bespreken wat audits hebben gevonden, zetten bevindingen om in correcties. Een steward die wel benoemd is maar nooit meedoet, maakt weinig verschil.

Eigenaarschap heeft beleid en standaarden nodig om tegen te toetsen. Leg vast hoe data wordt verzameld, opgeslagen, benaderd en gedeeld, stel datakwaliteitsmetrieken vast zodat je kunt nagaan of het beleid wordt gevolgd, en laat toegangscontroles aansluiten op je beveiligingsprotocollen. De mensen die het bankrekeningnummer van een leverancier mogen wijzigen, zijn bijvoorbeeld een kleine, bekende groep.

Compliance is het derde deel. Weet hoe regels zoals de AVG of de CCPA je omgang met stamdata raken, bijvoorbeeld hoe lang je het record van een vertrokken klant mag bewaren, en audit regelmatig tegen checklists voor je sector. Bouw compliance vanaf dag één in het raamwerk in, want later toevoegen betekent dat je elk proces dat al loopt opnieuw moet bekijken.

Meer over het waarom in vijf redenen voor data governance.

Pijler 2: datakwaliteitsbeheer

Datakwaliteitsbeheer houdt stamdata accuraat, consistent en betrouwbaar over domeinen heen. Organisaties onderschatten vaak de tijd en expertise die validatie en opschoning vragen.

Het dagelijkse werk is valideren en opschonen: geautomatiseerde profilering om patronen en uitschieters te vinden, deduplicatie en het aanvullen van onvolledige records. Een e-commercebedrijf kan binnenkomende klantdata controleren tegen bestaande records, zodat duplicaten en onvolledige invoer worden gevangen voordat er een tweede account ontstaat. Ingebouwde validatie houdt foute invoer tegen voordat die de database bereikt, en dat is veel goedkoper dan de fout maanden later in een rapport vinden. AI wordt steeds vaker ingezet voor patroonherkenning en het opsporen van afwijkingen, bijvoorbeeld om een artikelgewicht te signaleren dat ver afwijkt van vergelijkbare artikelen.

Om te weten of de kwaliteit vooruitgaat, heb je metrieken nodig. Nauwkeurigheid is het aandeel juiste records vergeleken met een betrouwbare bron. Volledigheid is het aandeel van de verplichte velden dat is ingevuld. Consistentie is de mate waarin data tussen systemen overeenkomt. Evalueer de metrieken volgens een vast ritme, want het bedrijf verandert: een veld dat vorig jaar optioneel was, kan dit jaar verplicht zijn voor een nieuwe marktplaats of door nieuwe regelgeving.

Kwaliteit heeft ook een weg terug nodig. Met feedbackloops melden eindgebruikers afwijkingen in het systeem, zodat een verkoper die een fout adres ziet of een magazijnmedewerker die een andere doosmaat meet, dat kan aangeven op een plek waar de steward het ziet. Nieuwe tools alleen lossen onduidelijke processen of gebrek aan training niet op, dus plan voor allebei tijd in.

Zie ook wat datakwaliteit is.

Pijler 3: data-integratie

Integratie geeft één beeld van de data over systemen heen. Het wordt complex zodra legacyplatforms meedoen, en wie dat onderschat, krijgt langere doorlooptijden en budgetoverschrijdingen.

De meeste programma's beginnen met samenvoegen. ETL-processen (extract, transform, load) brengen losse bronnen samen, bijvoorbeeld verkoopdata uit verschillende kassasystemen in één centrale database, en meestal worden de duplicaten en tegenstrijdige waarden dan voor het eerst zichtbaar. Samenvoegen in batches is niet genoeg als processen op actuele data draaien. Tools zoals Apache Kafka of MuleSoft houden platforms realtime gelijk, zodat een transactie direct in het CRM zichtbaar is en een gewijzigd klantadres het ERP bereikt voordat de volgende factuur de deur uitgaat.

Legacysystemen zijn het lastigste deel. Verouderde technologie en verschillende dataformaten vragen om passende middleware en een plan voor datamapping, waarin staat welk veld in het oude systeem bij welk veld in het nieuwe hoort en hoe waarden onderweg worden omgezet. Zonder die twee blijven integraties onvolledig en verliest de stamdata haar integriteit, omdat sommige systemen oude of halve waarden blijven ontvangen.

Geautomatiseerde tools hebben nog steeds menselijke controle nodig, en integratie vraagt om duidelijke communicatie tussen IT en de business. IT kan de koppeling bouwen, maar alleen de business kan zeggen welke van twee tegenstrijdige waarden de juiste is.

Pijler 4: beheer van de masterdata-levenscyclus

Stamdata doorloopt de fasen aanmaken, onderhouden en uitfaseren. Een financiële instelling maakt een klantprofiel aan bij het openen van een rekening, werkt het bij met transactiehistorie en archiveert of verwijdert de profielen van inactieve klanten. Sla je een fase over, dan loopt de dataset vol met records die verouderd of fout zijn: profielen van klanten die al lang weg zijn, of artikelen die niet meer verkocht worden maar nog wel in zoekresultaten en rapporten opduiken.

Metadata legt de herkomst, structuur en het gebruik van elk record vast, zodat je wijzigingen kunt volgen; teams die metadata buiten hun MDM-architectuur laten, verliezen dat zicht. Valideer in elke fase, niet alleen bij het aanmaken. Een retailer kan elk kwartaal de productinformatie nalopen op verouderde details, zoals een verwijzing naar een opvolger die zelf al uit het assortiment is, of een verpakkingswijziging die de leverancier nooit heeft doorgegeven.

Zo start je een MDM-programma

Een eenmalige opschoning laat de data een paar maanden goed ogen, en daarna brengen de oude gewoonten de problemen terug. MDM werkt als doorlopende afspraak, met een sponsor in het topmanagement die geschillen tussen afdelingen kan beslechten, information stewards in IT of bij de CDO die de systemen en regels bewaken, en data stewards in de business die eigenaar zijn van de inhoud. De stappen hieronder geven een praktische volgorde om te beginnen.

1. Breng in kaart waar elk veld ontstaat

   Teken de systemen en bestanden met je kritieke records, en markeer welk systeem elk veld als eerste vult. Neem ook de spreadsheets en lokale databases mee, want daar staan vaak de velden die verder niemand bijhoudt.

2. Benoem eigenaren en stewards

   Wijs de sponsor en de stewards aan, en benoem de key user die elk veld vult. Zorg dat ieder van hen ook echt tijd voor die rol krijgt.

3. Leg standaarden en kwaliteitsmetrieken vast

   Spreek omschrijvingen, codes en verplichte velden af, en meet daarna nauwkeurigheid, volledigheid en consistentie, zodat je een nulmeting hebt om vooruitgang aan af te lezen.

4. Begin bij nieuwe bronnen en applicaties

   Je hoeft niet eerst elk oud systeem te repareren. Pas MDM toe op nieuwe bronnen en applicaties, en trek het later door naar de records die je al hebt.

5. Onderhoud en audit

   Doe elke week onderhoud, en audit regelmatig op volledigheid, nauwkeurigheid, relevantie en tijdigheid.

De tool komt na dit voorwerk. Hoe je de juiste MDM-oplossing kiest behandelt de selectie vanuit bedrijfseisen.

PIM versus MDM

Veel mensen gebruiken PIM en MDM als namen voor hetzelfde systeem, deels omdat leveranciers in beide categorieën met productdata werken. Ze raken elkaar op het product, maar ze doen ander werk. MDM houdt de kritieke records binnen de organisatie gelijk, over domeinen zoals klant, leverancier en product heen. PIM brengt productinformatie naar buiten, naar de klant, in dezelfde vorm op elk kanaal.

MDM, PIM, ERP en DAM: wat elk systeem beheert

Systeem	Wat het beheert	Wie erin werkt	De vraag die het beantwoordt
MDMMaster data managementHier ben je	Gouden records over domeinen heen: klanten, leveranciers, locaties en producten, gematcht en beheerd.	Data governance, data stewards en IT.	Welke versie van dit record is de juiste, in elk systeem?
PIMProduct information managementGids over PIM	Verkoopbare productcontent: attributen, beschrijvingen, links naar assets, vertalingen en kanaalversies.	E-commerce, marketing, category management en productcontentteams.	Is dit product compleet en klaar om op dit kanaal te verkopen?
ERPEnterprise resource planningGids over ERP	Transacties en operatie: orders, voorraad, inkoop, prijzen en financiën.	Finance, supply chain, inkoop en sales operations.	Wat hebben we ingekocht, gemaakt, verkocht, verzonden en gefactureerd?
DAMDigital asset managementGids over DAM	Bestanden en media: beelden, video, documenten, varianten en gebruiksrechten.	Merk-, creatieve en marketingteams.	Waar staat het goedgekeurde bestand, en waar mogen we het gebruiken?

Wat MDM doet

MDM dekt de kritieke records van een organisatie over meerdere domeinen: klant, product, leverancier, medewerker, locatie en financiën. De gebruikers zitten intern: IT, data-governance-teams en business units die één operationeel beeld nodig hebben. Veel van het nut zit in de koppeling tussen soorten data. Leg klant en product op elkaar en je ziet gedrag, voorkeuren en kooppatronen, in plaats van twee lijsten die elkaar tegenspreken. Bij MDM gaat de inspanning naar die koppelingen en naar hiërarchieën, zoals welke dochterbedrijven bij welk moederbedrijf horen.

Wat PIM doet

Product information management blijft bij het productdomein en kijkt naar buiten. De taak is productinformatie op elk kanaal hetzelfde naar de klant te brengen: de webshop, marktplaatsen zoals Amazon of eBay, en print. De gebruikers zijn marketing, sales en commerce.

Voor marketing hoort daar beeld bij, foto en video, vaak uit een DAM (digital asset management) naast de PIM. Varianten zijn een kerngeval: in mode is één product (één tekst, één prijs) te koop in meerdere kleuren en maten. Relaties zijn het andere: alternatieven, accessoires en vervangende delen. Een PIM kan ook categorietemplates genereren die de brancheclassificaties van een centrale partij zoals GS1 volgen, zodat een product aankomt in de structuur die een retailer of datapool verwacht.

De verschillen die ertoe doen

De twee systemen verschillen op meer punten dan alleen de kant waar ze naar kijken. De lijst hieronder werkt als checklist als een leverancier of een collega ze als hetzelfde behandelt:

• Bereik. MDM dekt stamdata over domeinen: klant, leverancier, product, medewerker, locatie, financiën. PIM dekt productinformatie: attributen, beschrijvingen, specificaties, afbeeldingen, prijzen.
• Richting. MDM kijkt naar interne bronnen en de relaties daartussen. PIM kijkt naar externe kanalen en catalogi.
• Doel. MDM houdt één bron van waarheid voor de kritieke records van de organisatie. PIM houdt één betrouwbare versie van het product voor de klant.
• Datamodel. MDM heeft meestal een strakker model, gebouwd voor consistentie tussen entiteiten. PIM heeft meestal een flexibel entity-attribute-value-model (EAV), gebouwd voor veel producttypen en wisselende attributen.
• Governance. MDM brengt kwaliteitsbeheer, standaarden, stewardship en beleid in de hele organisatie. PIM brengt governancefuncties die de productattributen en de distributie dienen.
• Gebruikers. MDM: IT, data-governance-teams, business units. PIM: marketing, sales, e-commerce.
• Tijd tot livegang. MDM duurt vaak langer, door opschoning en governancewerk. PIM gaat meestal sneller, afhankelijk van het aantal producten en de integraties.

Het datamodel is een echte afweging. Met EAV kan een PIM een breed scala aan producttypen aan, met attributen die vaak veranderen, en dat past bij e-commerce met diverse catalogi: een retailer die een productcategorie met eigen attributen toevoegt, doet dat meestal met configuratie. Het strakkere model van MDM beperkt die flexibiliteit, en dezelfde wijziging kan daar een aanpassing van het datamodel en een testronde vragen. Daar staat tegenover dat het de data-integriteit tussen entiteiten beschermt.

Welke je nodig hebt

De eenvoudigste toets is kijken welk probleem je wilt oplossen. Kloppen de interne records niet, zodat finance, inkoop en verkoop elk met een andere versie van de klant of de leverancier werken, dan heb je een MDM-probleem. Is het productverhaal op de kanalen onvolledig, inconsistent of traag bij te werken, dan heb je een PIM-probleem. Veel bedrijven hebben allebei en hebben dus ook beide systemen nodig. Ze raken elkaar op het productdomein, waar MDM of het ERP het operationele productrecord bijhoudt en de PIM daarop de verkoopbare versie bouwt. Dat gedeelde domein maakt het ene systeem nog geen vervanging voor het andere.

Een veelvoorkomende misvatting is dat een PIM alleen alle databehoeften dekt. Een PIM dekt productcontent goed, maar vervangt MDM niet voor klant-, leveranciers- of regelgevende stamdata, en wie dat gat open laat, krijgt gefragmenteerde data tussen afdelingen. Het omgekeerde komt ook voor: MDM alleen lost niet alle dataproblemen op, en de integratie met bestaande systemen is complexer dan teams verwachten.

Bedrijfsgrootte en sector verschuiven het antwoord. Kleine bedrijven beginnen meestal met PIM, omdat dat snel live staat en flexibel met productdata omgaat: een kleine online retailer kan een seizoenscollectie in korte tijd invoeren en naar de webshop en marktplaatsen sturen. Dat dekt de directe behoefte, maar governance op lange termijn voor klant- en leveranciersdata dekt PIM niet, en dat gaat knellen als het bedrijf groeit.

Middelgrote ondernemingen onder regeldruk hebben vaak MDM nodig, bijvoorbeeld een productiebedrijf dat productspecificaties gelijk moet houden met leveranciersgegevens en tegelijk aan brancheregels moet voldoen. Grote ondernemingen met diverse productlijnen hebben meestal allebei nodig. Een wereldwijde elektronicaproducent die een smartphone lanceert, houdt de specificaties, het marketingmateriaal en de prijzen per markt bij in de PIM, en de klantprofielen en leverancierscontracten in MDM. Gereguleerde sectoren zoals farma en finance zetten MDM meestal voorop, terwijl retail en e-commerce vaker met PIM beginnen, omdat de eerste druk bij hen van de verkoopkanalen komt.

Beide systemen draaien vraagt planning. Datasynchronisatie, governancebeleid en gebruikerstraining zijn waar projecten vastlopen, en zonder plan maak je nieuwe silo's tussen de twee systemen. PIM heeft doorgaans lagere aanvangskosten en gaat sneller live. MDM brengt kosten voor licenties, integratie en onderhoud mee die teams vaak buiten de totale eigendomskosten laten, dus zet beide in hetzelfde meerjarenoverzicht voordat je ze vergelijkt.

Voor de grens met het ERP, zie waar ERP stopt en PIM begint.

Houd het eenvoudig

Maak master data management niet ingewikkelder dan het bestand vraagt. R.A. Jonker, F.T. Kooistra, D. Cepariu, J. van Etten en S. Swartjes zetten de belangrijkste do's en don'ts op een rij in Compact.

De meeste problemen met stamdata hebben geen groot programma nodig om beter te worden. Ze hebben iemand nodig die eigenaar is van het bestand en een vast moment per week om eraan te werken. De vier principes zijn de werkset: een overzichtelijk bestand waarin van elk veld de herkomst bekend is, eenduidige tekst en codes waarin je kunt zoeken, geen lege velden die blijven liggen, en wekelijks onderhoud met de functionele specialisten die de velden kennen. Voeg tooling en een formeel programma toe als de omvang van de data erom vraagt, en houd allebei zo eenvoudig als de data toelaat.

Hoe je verder gaat

Beide tools zijn gratis en onafhankelijk van welke vendor dan ook.

Twijfel je of je een PIM nodig hebt?

Een korte check die laat zien of een dedicated PIM je catalogus helpt, of dat spreadsheets en ERP het nog prima doen.

Check of een PIM past

Klaar om vendors te vergelijken?

Beantwoord vragen over je schaal, sector en harde eisen en krijg een gerangschikte shortlist.

Stel mijn vendor-shortlist samen