ERP en PIM beheren allebei productinformatie, maar zijn niet voor hetzelfde doel gebouwd. Lees waar gegevens zoals prijzen, technische kenmerken, productteksten en vertalingen thuishoren, en hoe je ze betrouwbaar naar webshops en andere verkoopkanalen stuurt.
PIM en ERP hebben ieder een andere rol in productbeheer
Een ERP-systeem ondersteunt de bedrijfsvoering. Het registreert bijvoorbeeld artikelen, inkoop, voorraad, kostprijzen, orders en facturen. Een PIM-systeem is gericht op het verzamelen, verrijken en verspreiden van productinformatie. Denk aan omschrijvingen, specificaties, afbeeldingen, vertalingen en informatie die nodig is om een product aantrekkelijk en begrijpelijk te presenteren. Beide systemen kunnen dus gegevens over hetzelfde artikel bevatten, maar gebruiken die gegevens voor verschillende processen.
Dat verschil is belangrijk bij de inrichting. Een artikelnummer dat in het ERP wordt aangemaakt, kan de vaste sleutel zijn waarmee het PIM het juiste product herkent. Het PIM vult vervolgens de verkoopinformatie aan en levert die bijvoorbeeld aan een webshop, marktplaats of catalogus. Het ERP blijft intussen leidend voor voorraad en orderverwerking. Zo voorkom je dat een redacteur per ongeluk een logistiek gegeven wijzigt op een plek waar dat gegeven alleen bedoeld is voor publicatie.
Een veelgemaakte fout is om één systeem verantwoordelijk te maken voor alles, zonder te kijken naar het werkproces. Een ERP kan wel tekstvelden hebben, maar is vaak niet ingericht voor vertaalstatussen, beeldselectie of kanaalspecifieke content. Andersom is een PIM meestal niet bedoeld om orders, boekingen of actuele voorraad te verwerken. Bepaal daarom per gegeven én per proces welk systeem de bron is. De beste verdeling is niet automatisch dezelfde voor iedere organisatie: die hangt af van de bestaande software, het assortiment en de manier waarop teams werken.
Deze productgegevens horen meestal thuis in het ERP
Gegevens die nodig zijn om producten in te kopen, te waarderen, op voorraad te houden en te verkopen, horen doorgaans in het ERP. Voorbeelden zijn het interne artikelnummer, de leverancier, de inkoopprijs, de kostprijs, de voorraadlocatie, de actuele voorraad en de status van een artikel. Ook verkoopprijzen of staffelprijzen kunnen daar thuishoren wanneer ze samenhangen met prijsafspraken, klantgroepen, marges of financiële processen. Het ERP is dan de plek waar medewerkers die informatie beheren binnen de bestaande bedrijfsregels.
Niet ieder gegeven dat technisch op een product lijkt, is daarom automatisch een ERP-veld. Een productspecificatie zoals materiaal, aansluiting of inhoud kan voor de winkelpresentatie nodig zijn, maar niet voor voorraadbeheer of boekhouding. Als zulke kenmerken in het ERP staan omdat daar toevallig ruimte voor is, wordt het systeem mogelijk lastig te beheren. Dat is vooral merkbaar wanneer het aantal kenmerken groeit of wanneer verschillende productgroepen ieder een eigen set eigenschappen hebben.
Let ook op gegevens die op meerdere plekken nodig zijn. Een artikelnummer kan vanuit het ERP naar het PIM gaan als vaste identificatie. Het PIM hoort dat nummer dan niet zelfstandig te veranderen. Hetzelfde geldt voor voorraad: de webshop kan voorraad tonen, maar de actuele stand moet uit het systeem komen dat de voorraadmutaties verwerkt. Spreek af hoe vaak die informatie wordt bijgewerkt en wat er gebeurt als de bron tijdelijk niet bereikbaar is. Zonder die afspraken kan een kanaal oude voorraad of prijzen tonen, terwijl medewerkers ervan uitgaan dat de koppeling actueel is.
Productteksten en verkoopkenmerken beheer je in het PIM
Een PIM is geschikt voor informatie die producten begrijpelijk en vergelijkbaar maakt voor klanten. Dat omvat meestal korte en lange productomschrijvingen, voordelen, gebruiksinstructies, specificaties, zoektermen en kenmerken die filters op een webshop aansturen. Ook beeldmateriaal, handleidingen en andere bestanden kunnen aan een product worden gekoppeld. Het voordeel is dat contentmedewerkers die informatie kunnen beheren zonder velden in het ERP te belasten met publicatiewerk.
Kenmerken vragen om een bewuste structuur. Een kledingwinkel kan bijvoorbeeld maat, kleur, pasvorm en materiaal gebruiken, terwijl een technisch assortiment aansluitingen, vermogen en compatibiliteit nodig heeft. Leg per productgroep vast welke velden verplicht zijn, welke keuzewaarden zijn toegestaan en hoe een kenmerk op de website wordt getoond. Een vrij tekstveld is flexibel, maar veroorzaakt al snel varianten als ‘zwart’, ‘Zwart’ en ‘antraciet’. Een gecontroleerde keuzelijst geeft meer consistentie, maar moet worden uitgebreid wanneer het assortiment daarom vraagt.
Niet alle content hoeft identiek te zijn voor ieder verkoopkanaal. Een marktplaats kan een korte titel en een vast aantal kenmerken eisen, terwijl de eigen webshop ruimte biedt voor advies en uitgebreide uitleg. Beheer daarom waar mogelijk één inhoudelijke basis in het PIM en maak aanvullende velden of regels voor kanalen. Dat betekent niet dat elk kanaal een volledig eigen productverhaal moet krijgen. Te veel uitzonderingen maken onderhoud duur en vergroten de kans op verouderde informatie. Bepaal welke verschillen echt nodig zijn en houd de kern van de productinformatie centraal beheerd.
Technische gegevens vragen om een duidelijke bronafspraak
Technische productgegevens vormen vaak het lastigste grensgebied tussen PIM en ERP. Gewicht, afmetingen, materiaal of een technische classificatie kunnen relevant zijn voor logistiek, inkoop én productpresentatie. De juiste plek hangt af van het gebruik en van de systemen waarin medewerkers de waarde nodig hebben. Een verzendgewicht dat vervoerskosten beïnvloedt, kan bijvoorbeeld in het ERP of een logistiek systeem leidend zijn. Een maatvoering die klanten helpt het juiste product te kiezen, kan beter als presentatiespecificatie in het PIM worden beheerd.
Maak onderscheid tussen één gegeven met meerdere toepassingen en twee gegevens die op elkaar lijken maar iets anders betekenen. ‘Gewicht’ kan het productgewicht zonder verpakking zijn, terwijl ‘verzendgewicht’ inclusief verpakking wordt berekend. Als beide velden dezelfde naam krijgen, kunnen medewerkers en koppelingen ze verwisselen. Leg daarom definities, eenheden en eventuele afrondingsregels vast. Noteer ook wie de waarde aanlevert en welk systeem bij een verschil de bron vormt.
Een praktische aanpak is een datadictionary met per veld de naam, betekenis, eenheid, toegestane waarden, eigenaar en bestemming. Controleer die afspraken met mensen uit productbeheer, logistiek en e-commerce; zij gebruiken dezelfde informatie vaak anders. Test vervolgens echte artikelen, inclusief uitzonderingen zoals sets, varianten en producten met afwijkende verpakking. Een veld kan in een eenvoudige demonstratie goed werken, maar in productie onduidelijk blijken zodra meerdere productgroepen het gebruiken. Door dit vóór de koppeling te ontdekken, voorkom je herstelwerk en misleidende productinformatie.
Een datamodel voorkomt verwarring tussen product en variant
Voordat productinformatie wordt verdeeld over systemen, moet duidelijk zijn wat de organisatie onder een product verstaat. Is een schoenmodel één product met maten en kleuren als varianten, of is iedere combinatie een apart artikel? Het ERP kan iedere verkoopbare variant een eigen artikelnummer geven, terwijl het PIM één bovenliggend product met gedeelde content beheert. Dat verschil is normaal, maar moet in het datamodel herkenbaar zijn. Anders kunnen beschrijvingen, afbeeldingen of voorraadgegevens aan het verkeerde niveau worden gekoppeld.
Leg vast welke velden gelden voor het hoofdproduct en welke per variant verschillen. Een algemene materiaalbeschrijving kan bijvoorbeeld voor alle maten gelijk zijn, terwijl kleur, EAN-code en beschikbare voorraad per variant verschillen. Bij andere assortimenten is juist de uitvoering bepalend: een technisch apparaat met verschillende voltages kan afzonderlijke specificaties en documentatie nodig hebben. Kopieer gedeelde gegevens niet zonder reden naar iedere variant. Dat levert dubbele invoer op en maakt wijzigingen arbeidsintensief. Maar erfelijkheid mag ook geen gegevens verbergen die voor een klant of verkoopkanaal expliciet nodig zijn.
Test het model met lastige productgroepen in plaats van alleen met een eenvoudig voorbeeld. Denk aan bundels, reserveonderdelen, samengestelde producten en artikelen die onder meerdere categorieën vallen. Controleer hoe een wijziging op het hoofdproduct doorwerkt naar varianten en kanalen. Kijk daarnaast of artikelidentificatie overal stabiel blijft wanneer een variant tijdelijk niet beschikbaar is of uit het assortiment verdwijnt. Een goed datamodel maakt zichtbaar welke relatie leidend is en voorkomt dat een koppeling producten samenvoegt op basis van een toevallige overeenkomst in naam of omschrijving.
Vertalingen vragen om meer dan extra taalvelden
Meertalige productinformatie beheren is meer dan een vertaalveld toevoegen aan een productrecord. Per taal kunnen andere titels, zoektermen, maateenheden, waarschuwingen en wettelijke teksten nodig zijn. Ook kan de inhoud per markt verschillen: een verpakking of uitvoering is niet in ieder land beschikbaar. Een PIM kan vertaalstatussen en taalvarianten overzichtelijk beheren, maar alleen als duidelijk is welke broninhoud wordt vertaald en wie de vertaling controleert.
Een bruikbare workflow onderscheidt bijvoorbeeld concept, klaar voor vertaling, in vertaling, gecontroleerd en gepubliceerd. Zo ziet het team of een vertaling ontbreekt of alleen nog op goedkeuring wacht. Spreek af wat er gebeurt wanneer de brontekst verandert. Kleine wijzigingen vragen niet altijd om een volledige nieuwe vertaalronde, maar wijzigingen in gebruiksadvies of veiligheidsinformatie kunnen wel direct gevolgen hebben. Zonder statusbeheer blijft een oude vertaling soms online naast een bijgewerkte brontekst.
Let op dat talen niet altijd één-op-één overeenkomen met verkoopmarkten. Nederlands voor België kan andere termen of afspraken vragen dan Nederlands voor Nederland. Een kanaal kan bovendien eigen titel- of lengte-eisen hanteren. Als iedere markt een compleet los productrecord krijgt, ontstaan al snel varianten die niet meer gelijklopen. Als alle markten dezelfde tekst delen, missen klanten juist relevante verschillen. Kies daarom welke informatie centraal wordt gedeeld, welke per taal wordt vertaald en welke per markt wordt aangepast. Maak die keuze zichtbaar in het datamodel en test ook hoe ontbrekende vertalingen worden afgehandeld: een lege pagina is niet altijd beter dan een zorgvuldig gekozen terugvaltekst.
Dubbele invoer verdwijnt pas met eigenaarschap en workflow
Een PIM naast een ERP voorkomt dubbele invoer niet vanzelf. Als medewerkers een omschrijving in beide systemen moeten aanpassen, blijven verschillen bestaan. Hetzelfde gebeurt wanneer een spreadsheet naast de systemen als informele bron wordt gebruikt. Wijs daarom per gegeven een eigenaarssysteem aan en spreek af wie de informatie invoert, controleert en vrijgeeft. Een gegeven kan op meerdere plekken zichtbaar zijn, maar hoort in principe maar op één plek gewijzigd te worden.
Breng eerst het werkelijke proces in kaart. Wie maakt een artikel aan? Wanneer zijn afbeeldingen beschikbaar? Wie controleert technische kenmerken en wie mag een product publiceren? In sommige organisaties maakt het ERP eerst een basisartikel aan en verrijkt het PIM dit later. In andere situaties begint productontwikkeling in een PIM, waarna gecontroleerde artikelgegevens naar het ERP gaan. Beide routes kunnen werken. Problemen ontstaan wanneer medewerkers niet weten welke stap eerst komt of wanneer een product al naar een webshop wordt gestuurd voordat verplichte informatie compleet is.
Maak de workflow passend bij de omvang en het risico van het assortiment. Een verplicht veld voor elk product kan de publicatie blokkeren, ook als dat veld voor een specifieke categorie niet relevant is. Werk liever met regels per productgroep en duidelijke uitzonderingsredenen. Gebruik daarnaast rollen en statussen om wijzigingen traceerbaar te maken. Een redacteur kan content aanvullen, terwijl een productspecialist technische gegevens goedkeurt. Houd de workflow niet ingewikkelder dan nodig: te veel goedkeuringsstappen leiden vaak tot omwegen via e-mail of spreadsheets, waardoor de officiële productdata alsnog achterloopt.
Datakwaliteit meet je met regels én productcontrole
Goede productdata is niet alleen compleet, maar ook juist, consistent en bruikbaar voor het doel. Een ingevuld materiaalveld kan bijvoorbeeld nog steeds onbruikbaar zijn als het een afwijkende schrijfwijze bevat. Een afbeelding kan technisch aanwezig zijn, maar de verkeerde uitvoering tonen. Datakwaliteit vraagt daarom om afspraken over waarden en betekenis, plus controles die fouten vroeg signaleren. Het PIM kan verplichte kenmerken, toegestane waarden en publicatieregels afdwingen, terwijl het ERP controles uitvoert op gegevens die nodig zijn voor transacties en logistiek.
Maak kwaliteitsregels concreet. Een product voor een bepaald verkoopkanaal kan pas worden gepubliceerd als er een titel, hoofdafbeelding en een afgesproken minimum aan relevante kenmerken is. Voor een productgroep kunnen afmetingen verplicht zijn, terwijl die voor een andere groep niet van toepassing zijn. Gebruik meldingen voor ontbrekende of verdachte waarden, maar voorkom dat medewerkers alleen waarschuwingen wegklikken. Een foutmelding moet uitleggen wat ontbreekt, waarom het nodig is en wie de informatie kan aanleveren.
Meet niet uitsluitend hoeveel velden gevuld zijn. Kijk ook naar fouten die in de praktijk gevolgen hebben: verkeerde filters, retouren door onjuiste maatvoering, afkeuringen door marktplaatsen of producten die niet vindbaar zijn. Analyseer terugkerende oorzaken en verbeter de invoerregels of brondata. Automatische controles zijn nuttig voor patronen, maar vervangen geen inhoudelijke beoordeling. Een systeem kan controleren of een tekst aanwezig is, niet of die tekst de klant echt helpt. Plan daarom steekproeven voor belangrijke productgroepen en leg vast hoe correcties worden teruggekoppeld naar de eigenaar van het gegeven.
Koppelingen naar webshop en marktplaats vragen om kanaalregels
Een PIM levert productinformatie niet zomaar op dezelfde manier aan ieder kanaal. Een webshop, marktplaats, printcatalogus en kassasysteem kunnen verschillende veldnamen, verplichte attributen, categorisaties en limieten gebruiken. De koppeling moet daarom gegevens vertalen naar het formaat van de bestemming. Een kenmerk als ‘materiaal’ kan op het ene kanaal een vaste keuzewaarde vereisen, terwijl een ander kanaal het als vrije tekst toont. Ook kunnen afbeeldingen in een bepaalde volgorde worden verwacht of moet een titel binnen een maximumaantal tekens blijven.
Beheer de inhoudelijke bron zo centraal mogelijk en voeg kanaalregels toe waar de bestemming dat echt vereist. Als ieder kanaal volledig aparte teksten krijgt, stijgt de beheerlast en kunnen wijzigingen achterblijven. Als alle kanalen dezelfde ruwe velden krijgen, ontstaan juist afkeuringen of een slechte presentatie. Leg daarom vast welke velden generiek zijn, welke kanaalspecifiek zijn en wie uitzonderingen beheert. Controleer ook of een kanaal gegevens terugstuurt, bijvoorbeeld afwijzingsmeldingen of statusinformatie. Zulke feedback kan productteams helpen fouten op te lossen.
Besteed aandacht aan synchronisatie en foutafhandeling. Een succesvolle technische verzending bewijst niet dat de informatie correct is weergegeven. Controleer na publicatie steekproefsgewijs de uiteindelijke productpagina en vergelijk kritieke gegevens zoals prijs, voorraad en variantrelaties met de bron. Spreek af hoe vaak wijzigingen worden verzonden en hoe een mislukte update opnieuw wordt aangeboden. Een wachtrij met zichtbare foutmeldingen is betrouwbaarder dan een koppeling die stilzwijgend stopt. Test bovendien wat er gebeurt bij verwijderde producten, tijdelijke voorraadtekorten en ontbrekende vertalingen, zodat kanalen geen verouderde of onvolledige artikelen blijven tonen.