PIM vs ERP: waarom het artikelbestand je kanalen niet alleen aankan

Wat is het verschil tussen een PIM en een ERP?

Het ERP regelt de transacties rond een product, het PIM regelt de content die het product verkoopt. Beide systemen bevatten productdata, en daarom denken kopers vaak dat het ene het werk van het andere kan doen. De pijler Wat is een PIM-systeem laat zien waar elk systeem in de productdatastack zit.

Een ERP is gebouwd voor order-to-cash. Het artikelbestand in het ERP bedient inkoop, productie, magazijn, facturatie en finance. Het slaat het artikelnummer op, de eenheden, kostprijs, prijs, voorraad, logistieke gewichten en de stuklijst. Het datamodel ligt per bedrijf vast en is geoptimaliseerd voor transactionele nauwkeurigheid.

Een PIM bedient productmanagers, marketeers, e-commerceteams en kanalen. Het bevat de technische en commerciële attributen per productfamilie en marketingteksten in elke taal. Ook classificaties zoals ETIM of ECLASS, relaties zoals accessoires en reserveonderdelen, en koppelingen naar afbeeldingen en documenten staan erin. Het datamodel verandert mee met het assortiment en de kanalen, en productdatamanagers passen het aan zonder ontwikkelproject.

Het verschil telt vooral op schaal. Een groothandel met 50.000 SKU's van 300 leveranciers, in vier talen en voor zes kanalen, heeft per productfamilie en per kanaal andere attributensets nodig. Artikelbestanden in een ERP ondersteunen dat zelden zonder zwaar maatwerk. Dit voorbeeld is illustratief, en het omslagpunt verschilt per bedrijf.

Hoe verhouden PIM en ERP zich op een rij?

PIM en ERP verschillen in doel, flexibiliteit van het datamodel, soorten content en de teams die ermee werken. De tabel vergelijkt beide systemen op tien dimensies die er in een selectie toe doen.

De schattingen voor productvelden komen uit selectiewerk van PIMvendors en verschillen per ERP en per assortiment. De structurele rijen wegen zwaarder. Het ERP houdt één artikelmodel aan voor het hele bedrijf, terwijl een PIM het model per productfamilie aanpast.

Waarom kan een ERP je kanalen niet alleen bedienen?

Het artikelbestand in een ERP schiet tekort als het bedrijf via meerdere kanalen, in meerdere talen en met complexe producten verkoopt. Vijf signalen tonen dat het ERP als contentsysteem zijn grens heeft bereikt:

1. Marketingteksten staan in Word-bestanden of in de webshop, omdat de ERP-velden te kort zijn.
2. Vertalingen staan buiten het ERP en worden door bureaus in spreadsheets bijgehouden.
3. Technische attributen staan in vrije tekstvelden in plaats van als getypeerde, gevalideerde waarden.
4. Elke kanaalexport vraagt maatwerkcode of handmatige bewerking.
5. Er bestaan maatwerkvelden voor e-commerce in het ERP die maar één of twee mensen begrijpen.

De kanalen leggen die gaten bloot. Google Merchant Center accepteert omschrijvingen tot 5.000 tekens en verwacht voor de meeste nieuwe producten een merk en een GTIN. Retailers en datapools voegen hun eigen attributenlijsten toe. Een ERP-veld dat is ontworpen voor een picklijst, kan daar onmogelijk allemaal aan voldoen.

Het ERP uitbreiden kan, en sommige bedrijven kiezen bewust die route. Voor één merk met een stabiel assortiment en één webshop werkt dat. De rekening komt later: in upgradeprojecten, in afhankelijkheid van een paar specialisten en in elk nieuw kanaal dat weer een maatwerkexport vraagt. De vergelijking tussen PIM en MDM beschrijft dezelfde afweging voor masterdataplatforms op enterpriseniveau.

Wanneer heb je zowel een PIM als een ERP nodig?

Vrijwel elk bedrijf dat een PIM koopt, houdt zijn ERP, dus de echte vraag is hoe je het werk verdeelt. Een heldere verdeling wijst elke attribuutgroep toe aan één systeem dat de data aanmaakt en aan één integratierichting.

Een gangbare verdeling ziet er zo uit:

• Het ERP maakt aan: artikelnummer, toekenning van GTIN's, eenheden, logistieke afmetingen, kostprijs, prijs, status.
• Het PIM maakt aan: marketingteksten, technische attributen, classificaties, relaties, assetkoppelingen, vertalingen.
• Het ERP stuurt naar het PIM: nieuwe artikelen, statuswijzigingen, logistieke data en prijslijsten voor catalogi.
• Het PIM stuurt naar het ERP: zelden iets, soms goedgekeurde omschrijvingen voor documenten en facturen.
• Het ERP stuurt rechtstreeks naar commerce: live voorraad en klantspecifieke prijzen.

Maak expliciete afspraken over GTIN's. GTIN's bestaan in formaten van 8, 12, 13 en 14 cijfers, en GTIN-14 identificeert dozen en verpakkingsniveaus. Meestal kent het ERP de GTIN per verpakkingsniveau toe, en het PIM moet ze per niveau opslaan en valideren.

De integratie-inspanning is aanzienlijk. Schatting van PIMvendors: integratie beslaat doorgaans 20 tot 40 procent van de implementatie-inspanning van een PIM. De gids over de integratie tussen PIM en ERP behandelt patronen, middleware en foutafhandeling.

Wat leg je vast voordat je een PIM selecteert?

Leg de verdeling van attribuuteigenaarschap en de integratierichting vast voordat je leveranciers uitnodigt. Die twee besluiten vormen de eisen sterker dan welke functielijst ook.

Bouw de verdeling op in vier stappen:

1. Zet elke attribuutgroep op een rij die in ERP, webshop, catalogus en kanaalbestanden voorkomt.
2. Wijs elke groep toe aan één systeem dat de data aanmaakt en één rol die eigenaar is.
3. Markeer de integratierichting en de trigger, zoals nieuw artikel, statuswijziging of nachtelijke synchronisatie.
4. Markeer de attributen die regelgeving nu vraagt, zoals fabrikantgegevens voor de GPSR of verpakkingsdata voor de PPWR.

Schatting van PIMvendors: de verdeling past in één spreadsheet van 20 tot 60 rijen, één per attribuutgroep. Houd het kort genoeg om in één vergadering met de stuurgroep door te nemen. Meningsverschillen over eigenaarschap komen in dit format snel boven, en nu oplossen is goedkoper dan tijdens de implementatie.

In PIMvendors-selecties vormt deze verdeling de basis voor integratiescenario's. De leverancier importeert je ERP-voorbeeld, verrijkt het, verwerkt een statuswijziging en toont de foutafhandeling als het ERP ongeldige data stuurt. De gids over productdata-governance legt uit hoe eigenaarsrollen aan elke attribuutgroep worden gekoppeld.