Trends in PIM, deel 1: de onboardinglaag maakt zich los van de PIM

Vraag je PIM-leverancier niet langer hoe ze "leveranciersonboarding afhandelen". Vraag wie verantwoordelijk is voor de intakestap, welk schema en welke validatieregels daar gelden, en of dat werk in de PIM gebeurt of in een product dat je ervoor inkoopt. Daar begint deze serie mee.

Jarenlang was onboarding een spreadsheet in iemands inbox, een mappingsessie tot laat in de avond en de hoop dat de volgende leverancier dezelfde kolomnamen gebruikte. De PIM moest die rommel opvangen. In de praktijk draaide hij vooral op voor het opschonen. Het systeem met het leidende productrecord werd de plek waar slechte leveranciersdata keer op keer met de hand werd opgeschoond, terwijl verrijking en publicatie naar kanalen bleven wachten.

Dat verandert, om een eenvoudige commerciële reden. Softwareaanbieders verkopen intake inmiddels als een eigen stap, met een eigen prijs, portaal en API. De PIM blijft het bronsysteem. Data in een vorm krijgen die de PIM kan vertrouwen, wordt een product van een andere partij.

Intake wordt een eigen categorie

Onedot verkoopt AI-gestuurde onboarding van productdata naar ERP-, PIM- of shopsystemen. De vermelding in de Pimcore Store begint bij € 4.950 per jaar voor classificatie, en onboarding wordt per leverancier afgerekend. Dat is geen extra PIM-functie. Het is een apart jaarabonnement voor het werk dat gebeurt voordat een record schoon genoeg is om te beheren. openProd zegt het zonder omwegen: de onboardinglaag tussen leveranciersbestanden en je PIM. Het leest pdf's en spreadsheets, mapt waarden op je bestaande model en legt twijfelgevallen eerst aan een medewerker voor, voordat er iets in de catalogus wordt geschreven. SDM Portal trekt diezelfde scheidslijn door tot in de dagelijkse operatie. Je mapt het bestand van een leverancier één keer op Ergonode, Akeneo of Pimcore in een visuele editor. Daarna publiceert elk nieuw bestand van die leverancier op die mapping, zonder ticket voor een ontwikkelaar, met een proefimport voordat er iets de PIM raakt. Drie bedrijven, één grens. De PIM beheert producten zodra ze binnen zijn. Ze binnenkrijgen is het trage deel, en voor dat deel bestaan nu eigen aanbieders.

De retail- en syndicatiekant van de markt trekt dezelfde lijn. Salsify laat leveranciersonboarding al lang toetsen aan het schema en de validatieregels van een retailer, in plaats van aan een vrij ingevulde spreadsheet. Syndigo documenteert een stagingstap tussen syndicatie en de PIM, zodat kanaalklare content niet rechtstreeks in de master belandt. PDX van Stibo Systems geeft leveranciers een kanaal om product- en assetmetadata aan te leveren, die te mappen op de attributen van de retailer en validatiefouten op te lossen voordat het record STEP bereikt. Andere logo's, dezelfde scheidslijn. Intake zit vóór de PIM.

Je ziet hetzelfde patroon in hoe open-core PIM-leveranciers de markt neerzetten. Toen we schreven over de overname van Pimcore door Tenzing, was de vraag bij de due diligence wie het platform en de roadmap beheert. Het loskomen van onboarding voegt een tweede vraag toe: wie de route beheert van leverancierschaos naar dat platform. Een sterke PIM met een zwak intakeverhaal laat je alsnog met de spreadsheet zitten.

PIM-leveranciers reageren met intake-API's

De PIM-leveranciers negeren dit niet. Ze maken een product van dezelfde grens, alleen vanaf de andere kant.

De Spring 2026-release van inriver voegt koppelingen via de Content Onboarding API toe voor geautomatiseerde imports uit ERP, PLM, leveranciersportalen en partnerfeeds, met mapping en validatie bij de intake. Ongestructureerde documenten (pdf, Excel, Word, PowerPoint) krijgen een extractieroute met een menselijke controlestap vóór het vastleggen. De release notes van november 2025 presenteerden die API al als manier om systemen vóór de PIM te koppelen zonder handmatige bestandsuploads. De PDX-route van Stibo doet vergelijkbaar werk voor syndicatie tussen retailer en leverancier. De boodschap van de PIM-kant is duidelijk. Ontstaat er vóór de PIM een gespecialiseerde laag, dan biedt de PIM zelf een gecontroleerde ingang, in plaats van te doen alsof elk leveranciersbestand in het verrijkingsscherm thuishoort.

Commercieel is dat de juiste reactie, en toch bevestigt het de stelling. Brengt je PIM een aparte onboarding-API uit, met mapping en validatie, dan geeft hij toe dat intake een productonderdeel is en geen bijproduct van het feit dat er attributen zijn.

Wat dit betekent als je koopt

Stel je in 2026 een PIM-shortlist op, behandel leveranciersonboarding dan als vast onderdeel van de architectuur, niet als een dia in de demo. Drie praktische controles:

1. Waar slechte data wordt geweigerd. Gebeurt de eerste harde validatie pas als het record al in de PIM staat, dan betaal je je verrijkingsteam nog steeds om intake te doen.
2. Wie het kanaal naar leveranciers beheert. Een retailerschema in Salsify of Stibo PDX, een specialist zoals Onedot, openProd of SDM Portal, of het eigen portaal van de PIM: dat zijn verschillende modellen voor wie verantwoordelijk is. Kies er bewust één. Wie er drie tegelijk laat draaien, eindigt met een vierde spreadsheet.
3. Wat je PIM bij de ingang verwacht. Een intake-API met mapping en validatie (de Content Onboarding-route van inriver is één voorbeeld) verandert het integratieontwerp. Je middleware of specialistische tool moet via die ingang aanleveren, niet via een los importscript dat de regels omzeilt.

Er is wel degelijk een afweging. Een gespecialiseerde onboardinglaag betekent een extra aanbieder, een extra contract en een extra plek waar attribuutdefinities kunnen afwijken van het PIM-model. Een intakeroute in de PIM zelf houdt de verantwoordelijkheid op één plek, en kan achterlopen op de specialisten bij rommelige pdf's en de chaos van tientallen leveranciers. Geen van beide is gratis. Duur wordt het als je doet alsof deze verschuiving niet plaatsvindt, terwijl je team elke maandag dezelfde leverancierswerkmap opnieuw mapt.

Dit is het eerste van vier stukken over één verschuiving: de PIM verliest de claim de hele productdatastack te zijn en komt terecht in de rol waarin hij altijd het sterkst was, het beheerde record in het midden. Elk deel bekijkt een andere grens, waar werk uit de PIM naar een laag eromheen schuift. Deel 2 gaat over MCP en AI-agents. Zodra verrijking, classificatie en vertaling via API's en agentprotocollen lopen, gebeurt veel werk buiten het PIM-scherm, en wordt de vraag welke regels agents moeten respecteren als ze terugschrijven. Deel 3 volgt de data op het punt waar ze de PIM aan de andere kant verlaat. Daar verschuift publicatie naar iPaaS, middleware en feedtools, zodat een wijziging in één kanaal geen PIM-project meer vraagt. Deel 4 gaat over regelgeving. Het Digitaal Productpaspoort en de bredere ESPR-regels voegen complianceattributen toe die leveranciers moeten aanleveren en die auditors moeten kunnen vertrouwen. Die druk komt als eerste terecht op de intakelaag uit dit artikel.

Samen geven de vier delen je een kaart voor je volgende selectie. Intake vooraan, agents ernaast, distributie erachter, en compliance die aan alle drie trekt. Hoe die intakelaag doorwerkt naar shoppingagents en antwoordmachines staat in AI-ready productdata en agentic commerce. Gebruik de kaart om laag voor laag te bepalen waar de PIM verantwoordelijk voor moet zijn en wat je liever koopt, bouwt of aansluit, voordat de demo van een PIM-leverancier dat voor je beslist.