Product data management retail: gids voor ERP, PIM en GS1
Artikel samenvatting
Hoe organiseert u productdata in retail zodat elk kanaal dezelfde, juiste informatie toont?
Direct antwoord: Leg per productkenmerk één eigenaar, één bronsysteem en vaste kwaliteitsregels vast. Operationele stamgegevens zoals artikelnummer, GTIN, eenheden en prijzen horen doorgaans in uw ERP systeem, kanaalgerichte teksten in een PIM en beelden in een DAM. De koppelingen daartussen bepalen of webshop, kassa en marktplaats hetzelfde vertellen.
- Retailers die met Microsoft Dynamics 365 Business Central of LS Central werken, kunnen bij TCOG terecht om de ERP-kant van die productketen in te richten, te koppelen en te onderhouden.
- Begin bij datamodel en eigenaarschap. De softwarekeuze volgt daaruit.
- Leveranciersdata valideert u bij binnenkomst, want elke correctie na publicatie kost meer werk dan de vorige.
- GS1-standaarden zoals de GTIN geven u een gedeelde taal met leveranciers en marktplaatsen.
Het Excelbestand heette ooit ‘artikelen_webshop_tijdelijk’. Het werd aangemaakt omdat de webshop binnen enkele weken live moest en het ERP systeem geen plek had voor productteksten. Jaren later is het de belangrijkste productbron van de hele organisatie. Iedereen heeft er een eigen tabblad in.
Herkent u dat bestand, dan zit u midden in het vraagstuk van product data management retail: wie beheert welk productgegeven, in welk systeem, en via welke regels komt het bij kassa, webshop en marktplaats terecht. Het directe antwoord is nuchterder dan veel softwarepagina’s doen vermoeden. Laat operationele stamgegevens (artikelnummer, GTIN, eenheden, inkoop- en verkoopprijs) in uw ERP systeem wonen, beheer verkoopteksten en kanaalspecifieke kenmerken in een PIM, bewaar beelden en documenten in een DAM, en controleer alles wat binnenkomt voordat het ergens gepubliceerd wordt.
Software is daarbij het makkelijke deel.
Zoekt u eerder een brede vergelijking van pakketten, dan sluit onze pagina over retail ERP software beter aan. Hier gaat het om de inrichting van de productketen zelf.
Wat product data management in retail eigenlijk regelt
Product data management in retail is het geheel van afspraken, processen en systemen waarmee u alle informatie over een artikel beheert, van de eerste leveranciersfiche tot het moment dat het artikel uit het assortiment verdwijnt. Dat is veel meer dan een omschrijving en een prijs.
Neem een gewone winterjas. Die heeft een artikelnummer, een GTIN per maat en kleur, een inkoopprijs, een btw-tarief, afmetingen en gewicht voor verzending, een stofsamenstelling, wasvoorschriften, webteksten in meerdere talen (in België al snel twee of drie), een reeks foto’s en misschien een herkomstcertificaat voor het dons. Elk van die gegevens wordt door iemand anders aangeleverd en door een ander kanaal gebruikt.
Daar zit de kern.
Retail voegt er twee dingen aan toe die het lastiger maken dan in veel andere sectoren: volume en tempo. Per seizoen introduceert u mogelijk honderden of duizenden nieuwe artikelen, vaak met varianten, en elk kanaal stelt eigen eisen. Een marktplaats vraagt andere verplichte velden dan uw eigen webshop, terwijl uw kassa genoeg heeft aan een korte omschrijving en een prijs. Catalogusbeheer (welk artikel staat in welk assortiment, voor welk kanaal, in welke periode) hoort daarom net zo goed bij product data management als de gegevens zelf.
Aan de klantzijde duikt soms de term product experience management op. Daarmee bedoelt men dat productinformatie niet alleen juist is, maar ook overtuigt in de context waar uw klant ze leest. Een nuttige ambitie, die pas werkt wanneer de onderliggende stamgegevens al kloppen.
PDM, PIM, MDM en DAM: waar liggen de grenzen?
Deze vier afkortingen overlappen, en leveranciers gebruiken ze niet altijd op dezelfde manier. Voor u als retailer werkt de volgende indeling meestal goed.
PDM (product data management) komt oorspronkelijk uit de maakindustrie, waar het draait om technische specificaties, tekeningen en versies tijdens productontwikkeling. In retail gebruikt men de term vaak breder, als paraplu voor alles rond productgegevens. PIM (product information management) richt zich op het verrijken en publiceren van productinformatie voor verkoopkanalen. MDM (master data management) gaat over de stamgegevens van de hele organisatie, dus ook klanten, leveranciers en locaties, en over de spelregels die bepalen welke versie de juiste is. Product master data management is de toepassing daarvan op het productdomein. DAM (digital asset management) beheert beelden, video’s, handleidingen en certificaten.
In de tabel ziet u per begrip welke vraag het beantwoordt en waar het in de praktijk vaak terechtkomt.
| Begrip | Kernvraag | Typische gegevens in retail | Waar het vaak landt |
|---|---|---|---|
| PDM | Hoe ziet het product er technisch uit, en welke versie geldt? | Specificaties, samenstelling, maattabellen, versies | Bij private label of eigen productie, vaak naast het ERP |
| PIM | Hoe presenteren we dit artikel per kanaal? | Webteksten, kenmerken per categorie, vertalingen, kanaalvelden | Een apart PIM of uitgebreide artikelkenmerken in het ERP |
| MDM | Welke versie van een stamgegeven is de juiste, en wie beslist dat? | Artikel-, leveranciers- en locatiegegevens, beheerregels | Vaak een proces en een rolverdeling, niet per se een apart pakket |
| DAM | Waar staat het juiste beeld, en mag het gebruikt worden? | Foto’s, video’s, certificaten, gebruiksrechten | Een apart DAM, een PIM met beeldbeheer of een goed geordende opslag |
Kijk vooral naar de laatste kolom. Een middelgrote retailer heeft zelden vier afzonderlijke systemen nodig. Wij raden aan om eerst de vier kernvragen te beantwoorden en pas daarna te bepalen hoeveel systemen daar echt voor nodig zijn. Met een paar duizend artikelen en één webshop komt u vaak ver met goed ingerichte artikelkenmerken in het ERP systeem en een gestructureerde beeldbank, terwijl een apart PIM sneller te verdedigen valt zodra u via meerdere marktplaatsen in meerdere talen verkoopt.
Leveranciersdata controleren voordat ze uw systemen binnenkomen
Controleer leveranciersgegevens bij binnenkomst, niet achteraf. Een bakker test zijn bloem ook niet pas wanneer het brood al in de oven staat. Toch gaat het bij veel retailers precies zo: de inkoper maakt een artikel aan op basis van een leveranciersbestand, de webshop toont het, en pas wanneer een klant klaagt of de pakketdienst een toeslag aanrekent, ontdekt iemand dat de leverancier grammen en kilo’s door elkaar gebruikte.
Validatieregels hoeven niet ingewikkeld te zijn om effect te hebben. Een goede eerste set bestaat uit verplichte velden per productcategorie, vaste formaten voor eenheden en datums, gecontroleerde waardelijsten (zodat ‘marine’, ‘navy’ en ‘donkerblauw’ niet als drie kleuren eindigen) en een controle op het controlecijfer van elke GTIN. Wat de regels niet doorstaat, gaat terug naar de leverancier.
De vorm van de aanlevering bepaalt hoeveel van die controle u kunt automatiseren. Een vast importsjabloon is een begin. Een leveranciersportaal gaat verder, omdat de leverancier zijn gegevens zelf invult binnen uw regels en meteen ziet wat ontbreekt. Voor modemerken en groothandels beschreven we eerder hoe u een leveranciersportaal voor fashion aan Business Central koppelt, en die logica geldt ook buiten mode. Grotere leveranciers verkiezen soms een gestandaardiseerde datastroom boven een portaal.
Welke GS1-standaarden tellen voor retailproductdata?
De GTIN (Global Trade Item Number) is de basis: het nummer achter de streepjescode dat een handelseenheid wereldwijd uniek identificeert. Gebruikt u voor elke variant een eigen GTIN, dan spreken kassa, magazijn en marktplaats over hetzelfde artikel zonder vertaaltabellen. Voor het uitwisselen van volledige productgegevens tussen handelspartners bestaat het GDSN (Global Data Synchronisation Network), een netwerk van gecertificeerde datapools dat in sommige sectoren een vaste route is.
In België en Luxemburg is GS1 Belgium & Luxembourg het aanspreekpunt voor nummers en standaarden. Welke eisen voor uw assortiment gelden, hangt af van uw sector en uw afnemers. Check dat bij de bron.
Welke rol speelt uw ERP systeem in product data management?
In de meeste retailomgevingen is uw ERP systeem de bron voor alles wat met transacties te maken heeft: artikelnummers, varianten, eenheden, inkoop- en verkoopprijzen, leveranciers, voorraad en btw. Dat zijn de gegevens waar een fout meteen geld kost. Microsoft Dynamics 365 Business Central (de ERP software van Microsoft waarop TCOG veel van zijn oplossingen bouwt) kent daarvoor onder meer artikelvarianten, artikelkenmerken en artikelreferenties, waarmee u bijvoorbeeld een leveranciersnummer of streepjescode aan uw eigen artikelnummer koppelt.
Een werkbare verdeling ziet er vaak zo uit. Het artikel ontstaat in het ERP, omdat inkoop het daar nodig heeft om te bestellen. Een PIM, als u er een gebruikt, haalt dat basisartikel op en verrijkt het met teksten, kenmerken en beelden uit het DAM. Webshop en marktplaatsen krijgen de verrijkte inhoud uit het PIM, maar prijzen en voorraad komen rechtstreeks of via een integratielaag uit het ERP, omdat die gegevens te snel veranderen om via een tussenstation te reizen.
Werkt u met LS Central voor uw winkels, dan draait uw kassa (point of sale, POS) op dezelfde Business Central-basis. Artikel- en prijsgegevens hoeven dan niet eerst naar een apart kassasysteem vertaald te worden. Hoe winkel, webshop en magazijn op die manier samen één voorraadbeeld delen, werkten we uit in een artikel over omnichannel retail met ERP, POS, webshop en magazijn, inclusief de keuzes rond voorraadreservering.
Teken voor elk gegeven één pijl, nooit twee. Wordt een verkoopprijs zowel in het ERP als in de webshop aangepast, dan heeft u geen koppeling maar een wedstrijd.
Een productdatamodel dat ook volgend seizoen nog klopt
Veel teams zien het datamodel als iets voor IT. In werkelijkheid is het een commerciële beslissing in technische kleren: u bepaalt ermee welke informatie uw klanten kunnen filteren, vergelijken en vinden.
Een goed model werkt in lagen. Bovenaan staat het model of de stijl, daaronder de varianten en onderaan de SKU (stock keeping unit, de kleinste eenheid waarop u voorraad bijhoudt). Kenmerken leven op het niveau waar ze echt variëren. Materiaal hoort bij het model, kleur bij de variant, maat bij de SKU. Wie dat door elkaar haalt, typt hetzelfde gegeven twintig keer in en corrigeert het twintig keer wanneer het fout blijkt.
Een datamodel lijkt op de indeling van een keuken. Zolang er weinig in staat, maakt het niet uit waar de pannen liggen, maar bij elk nieuw toestel merkt u of er vooraf is nagedacht. Een nieuwe productcategorie of een extra marktplaats is zo’n toestel.
Werk daarom met kenmerkfamilies per categorie (schoenen hebben andere velden dan woontextiel) en leg per kanaal vast welke kenmerken verplicht zijn. Fashionbedrijven krijgen er een extra laag bij, met maat- en kleurmatrixen, seizoenscollecties en maatsystemen die per land verschillen. Voor die sector ontwikkelde TCOG itSuitsFashion 365, een fashionoplossing op basis van Business Central, zodat het datamodel aansluit bij hoe modebedrijven werken. Een pas ontdekte fout in de maattabel van een lopende collectie herstelt u liever één keer op modelniveau dan per variant.
Product data management invoeren in vier fasen
Een big bang werkt zelden bij productdata. Een gefaseerde aanpak geeft u sneller resultaat en minder verrassingen.
- Inventariseren. Breng in kaart welke systemen, bestanden en mensen vandaag productgegevens aanmaken of wijzigen, inclusief de schaduwbestanden.
- Spreek eigenaarschap af per gegevensgroep. Een data owner, meestal iemand uit de business, beslist over de regels, en een data steward bewaakt de dagelijkse kwaliteit en lost conflicten op. Zonder die rollen blijft elke kwaliteitsregel een suggestie. Reken op discussie: hier zitten inkoop, e-commerce, marketing en finance voor het eerst samen aan tafel en ontdekken ze dat ze onder ‘omschrijving’ vier verschillende dingen verstaan.
- Datamodel en validatieregels komen vóór de koppelingen tussen ERP, PIM, DAM en kanalen.
- Migreer per productgroep, te beginnen met een categorie die goed verkoopt en relatief eenvoudig is opgebouwd.
Voor de derde fase loont het om eerst een blauwdruk te maken van processen, scope en systemen, zoals in het blueprinttraject van TCOG, zodat de keuze voor een PIM of DAM uit het ontwerp volgt en niet omgekeerd. Meet daarna een paar eenvoudige zaken: het aandeel artikelen met volledige verplichte velden per kanaal, de doorlooptijd van leveranciersbestand tot live artikel, en het aantal retouren met als reden dat het artikel afwijkt van de beschrijving. Die drie cijfers vertellen u meer dan elk dashboard vol vinkjes.
Waar productdataprojecten meestal vastlopen
De zwaarste fout is beginnen met een softwaredemo. Een demo ziet er altijd overtuigend uit, omdat de demodata perfect zijn. Uw data zijn dat niet, en de vragen die er echt toe doen (wie mag een kenmerk wijzigen, welk systeem wint bij een conflict, wat gebeurt er met een artikel zonder beeld) komen in een demo zelden aan bod. Wie zo start, koopt een systeem en ontdekt achteraf dat het eigenaarschap nog geregeld moet worden. Dan wordt het nieuwe pakket gewoon een duurder Excelbestand.
Een tweede klassieker: vervuilde data migreren in de hoop ze later op te schonen. Later komt zelden.
Onderschat ook het onderhoud niet. Productdata zijn geen eenmalige klus, want elk seizoen brengt nieuwe leveranciers, nieuwe kanalen en soms nieuwe wettelijke vermeldingen. Reserveer daar structureel capaciteit voor, ook nadat het project officieel is afgesloten en het projectteam alweer aan iets anders werkt.
En laat geen enkel kanaal een eigen kopie van de productgegevens bijhouden die daarna handmatig wordt aangepast. Dat voelt bij de lancering van een nieuwe marktplaats als de snelste weg, en het is precies hoe het tijdelijke Excelbestand ooit begon.
Hoe TCOG retailers helpt met de ERP-kant van productdata
TCOG richt zich op het deel van de productketen waar operationele stamgegevens ontstaan en vanwaar ze naar winkels, webshops en magazijnen vertrekken. TCOG profileert zich als nummer 1 ERP-partner in de Benelux voor Fashion, Retail, Hospitality en Industry, werkt voor meer dan 225 klanten en is Microsoft Solutions Partner voor Business Applications en LS Retail Diamond Partner. Microsoft ontwikkelt Business Central en LS Retail ontwikkelt LS Central, terwijl TCOG die oplossingen implementeert, koppelt en optimaliseert.
Concreet betekent dat: een fit/gap-analyse van uw huidige productprocessen, een datamodel in Business Central dat past bij uw assortiment, datamigratie per productgroep en realtime integraties met webshop, kassa en andere applicaties. Goedkeuringsstappen voor nieuwe artikelen kunt u met Power Automate uit het Microsoft Power Platform laten verlopen, zodat een artikel pas naar de kanalen gaat wanneer de verantwoordelijke het heeft vrijgegeven. Na livegang blijft de omgeving niet stilstaan, met ondersteuning en een Continuous Improvement SLA (Service Level Agreement) voor doorlopende optimalisatie.
Een eerlijke grens hoort erbij. Zoekt u vooral een marketingplatform voor productcontent en speelt het ERP-vraagstuk nauwelijks, dan is een gespecialiseerde PIM-leverancier waarschijnlijk een logischer eerste gesprek. Wij zien de meeste winst juist waar ERP, kassa en webshop vandaag elk hun eigen versie van een artikel bijhouden.
Veelgestelde vragen over product data management in retail
Heeft een middelgrote retailer een apart PIM-systeem nodig?
Niet altijd. Met een overzichtelijk assortiment en één of twee verkoopkanalen volstaan goed ingerichte artikelkenmerken in het ERP systeem vaak. Een apart PIM wordt interessanter zodra u meerdere talen, marktplaatsen of complexe kenmerkfamilies moet beheren.
Wat is het verschil tussen PIM en MDM?
Een PIM verrijkt en publiceert productinformatie voor verkoopkanalen. MDM bepaalt over alle domeinen heen welke versie van een stamgegeven de juiste is en wie daarover beslist.
Hoe valideert u productdata van leveranciers?
U valideert leveranciersdata door bij binnenkomst vaste regels toe te passen. Denk aan verplichte velden per categorie, vaste eenheden, gecontroleerde waardelijsten en een controle op geldige GTIN’s. Een leveranciersportaal of vast importsjabloon maakt die controle grotendeels automatisch, zodat uw team alleen de uitzonderingen behandelt.
Moet elke maat- of kleurvariant een eigen GTIN hebben?
In de regel krijgt elke variant die als aparte handelseenheid wordt verkocht een eigen GTIN, zodat kassa, magazijn en marktplaats hem eenduidig herkennen. De exacte toewijzingsregels hangen af van uw sector, dus controleer ze bij GS1 Belgium & Luxembourg.
Kan Business Central dienen als centrale bron voor productdata?
Voor operationele stamgegevens wel. Microsoft Dynamics 365 Business Central beheert artikelen, varianten, kenmerken, referenties, prijzen en voorraad, en is daarmee de logische bron voor alles wat met inkoop, verkoop en logistiek te maken heeft. Uitgebreide marketingteksten en grote beeldbibliotheken beheert u vaak beter in een PIM of DAM dat met Business Central gekoppeld is. De vraag is dus niet of Business Central de bron is, maar voor welke gegevens.
Hoe lang duurt het om productdata op orde te krijgen?
Dat hangt sterk af van de omvang van uw assortiment, het aantal bronnen en de staat van uw huidige data. Een gefaseerde aanpak per productgroep levert meestal sneller zichtbaar resultaat op dan alles in één keer willen oplossen. Plan daarnaast structurele capaciteit voor onderhoud, want productdata blijven elk seizoen veranderen.
Wat betekent dit voor uw organisatie?
Goede productdata ontstaan niet in een nieuw pakket maar in duidelijke afspraken over wie welk gegeven bezit en welk systeem de bron is. Daarna bepalen validatie aan de poort en betrouwbare koppelingen met uw ERP of dezelfde jas op elk kanaal hetzelfde kost en hetzelfde weegt. Een goede eerste stap: zet de twintig productkenmerken die u het vaakst gebruikt op een rij en noteer bij elk kenmerk wie het vandaag aanpast, en in welk systeem.
