PIM en ERP koppelen: datastromen en eigenaarschap

De PIM-ERP-koppeling is de belangrijkste integratie in uw productdataketen, en ze slaagt of faalt op eigenaarschap. Het ERP-systeem (Enterprise Resource Planning) is de bron voor operationele gegevens zoals artikelnummer, GTIN, prijs, voorraad en logistiek. Het PIM-systeem (Product Information Management) is de bron voor content: teksten, specificaties, classificaties, vertalingen en media. Ontwerp daarna per datatype de richting, het ritme en de uitzonderingsregels.

Welk systeem beheert welke productdata?

Leg per attribuut één eigenaar vast in een eigenaarschapsmatrix. Dat document voorkomt het meest voorkomende probleem: twee systemen die hetzelfde veld overschrijven.

Een uitgebreide uitleg van de rolverdeling vindt u in PIM vs ERP. Hoe u eigenaren en data stewards benoemt, staat in productdata-governance.

Hoe lopen de datastromen tussen PIM en ERP?

De basisstroom heeft twee stappen. Het ERP-systeem maakt een artikel aan en stuurt de operationele kern naar het PIM-systeem. Het PIM-systeem verrijkt het artikel en publiceert het naar webshop, marktplaatsen en print. Een terugstroom naar het ERP-systeem is soms nuttig, bijvoorbeeld voor een korte omschrijving op pakbon en factuur of een classificatie voor inkoopanalyses. Houd die terugstroom klein en expliciet.

Leg voor elke stroom vast:

1. Trigger. Event bij wijziging, geplande batch of handmatige vrijgave.
2. Sleutel. Meestal het ERP-artikelnummer, met GTIN als controleveld.
3. Mapping. Eenheden, keuzelijsten en hiërarchieën sluiten zelden één op één aan. Een ERP-productgroep is iets anders dan een PIM-familie of webshopcategorie.
4. Uitzonderingen. Wat gebeurt er als een artikel in het PIM-systeem al bestaat, een waarde niet in de keuzelijst past of het ERP-systeem tijdens de batch onbereikbaar is: overschrijven, negeren, in quarantaine zetten of escaleren naar een data steward.
5. Monitoring. Een dagelijks overzicht van mislukte berichten, met eigenaar en hersteltermijn.

Waar let u op bij Exact, AFAS, Business Central en SAP?

De Nederlandse markt kent een eigen mix van ERP-systemen. Elk heeft een API, maar de manier waarop artikeldata en wijzigingen beschikbaar komen, verschilt.

Microsoft Dynamics 365 Business Central. De API v2.0 bevat een item-resource met onder meer number, displayName, type, unitPrice en inventory, plus navigatie naar itemVariants en picture. Volgens Microsoft Learn kunt u de standaard-API's niet uitbreiden met extra velden; daarvoor kopieert u de AL-code naar een eigen API. Webhooks verlopen na drie dagen als u ze niet vernieuwt, en bij meer dan 1.000 wijzigingen binnen 30 seconden stuurt Business Central één collectiemelding in plaats van losse meldingen. Item attributes met overerving via artikelcategorieën zijn bruikbaar voor eenvoudige kenmerken, zonder verrijkingsworkflow. Voor Business Central bestaan ook PIM-oplossingen die in het ERP draaien, zoals Pimics. Zie PIM koppelen aan Microsoft Dynamics.

Exact Online en Exact Globe. Exact Online biedt een REST API voor koppelingen; in het mkb lopen implementaties vaak via een integratieplatform of een connector van de PIM-leverancier. Controleer vooraf de API-limieten in de actuele Exact-documentatie, omdat die het ritme van batches bepalen. De uitwerking staat in PIM koppelen aan Exact.

AFAS Profit. AFAS documenteert de REST API van Profit per endpoint op docs.afas.help, inclusief een testomgeving voor endpoints. Artikeldata in AFAS is sterk ingericht op order- en factuurprocessen, dus beperk de stroom naar het PIM-systeem tot de operationele kern. Zie PIM koppelen aan AFAS Profit.

SAP S/4HANA en SAP Business One. In grotere SAP-omgevingen beheert SAP Master Data Governance vaak de creatie en wijziging van het materiaalstam, met centrale workflows. Het PIM-systeem neemt dan de commerciële verrijking over. Perfion biedt volgens het leveranciersprofiel native connectoren voor SAP Business One en SAP S/4HANA, en Struct noemt SAP Business One.

Welk synchronisatiemechanisme kiest u?

Let ook op de limieten aan PIM-zijde. Akeneo staat volgens de API-documentatie maximaal vier gelijktijdige aanroepen per connectie toe en geeft HTTP 429 bij overschrijding. Een initiële laadactie van tienduizenden artikelen moet daarop zijn ingericht.

Rekenvoorbeeld (indicatief): stel dat u 40.000 artikelen laadt en elk artikel drie aanroepen vraagt (product, variantgegevens en een koppeling naar media). Dat zijn 120.000 aanroepen. Bij een gemiddelde van tien aanroepen per seconde duurt de eerste lading ruim drie uur, nog zonder herhaalpogingen na HTTP 429. Plan die lading daarom als aparte stap buiten kantoortijd, met batchgrootte en wachttijd als instelbare parameters, en houd de dagelijkse synchronisatie daarna beperkt tot gewijzigde artikelen. Bredere keuzes over middleware en architectuur staan in PIM-integraties.

Welke fouten komen het vaakst voor?

• Onduidelijk eigenaarschap. Teams bewerken omschrijvingen in beide systemen, waarna de koppeling elke nacht werk ongedaan maakt.
• Alles in twee richtingen synchroniseren. Dat veroorzaakt circulaire updates en een datastroom die niemand meer kan uitleggen.
• Mapping onderschatten. ERP-eenheden, kleurcodes en productgroepen passen zelden direct op PIM-attributen en keuzelijsten.
• Testen met tien artikelen. Time-outs, limieten en volgordeproblemen verschijnen pas bij productievolumes. Test met een volledige kopie en een realistische wijzigingsfrequentie.

Belangrijkste punten

• Leg per attribuut één eigenaar vast: ERP voor artikelnummer, GTIN, prijs, voorraad en logistiek; PIM voor content, specificaties, vertalingen en media.
• De basisstroom loopt van ERP naar PIM en van PIM naar kanalen; houd een terugstroom klein en expliciet.
• Business Central: standaard-API's zijn niet uit te breiden met velden, webhooks verlopen na drie dagen en bundelen meer dan 1.000 wijzigingen tot één melding.
• Kies het mechanisme per datatype en ontwerp de initiële laadactie rond de API-limieten van beide systemen.