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 eigenaar is van de intakestap, welk schema en welke validatieregels daar zitten, en of dat werk binnen de PIM gebeurt of in een product dat je vóór de PIM inkoopt. Met die beslissing begint deze serie.

Jarenlang betekende 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 chaos opvangen. In de praktijk ving hij vooral de opschoonkosten op. Het systeem voor het productrecord werd de plek waar slechte leveranciersdata keer op keer met de hand werd opgeschoond, terwijl verrijking en kanaalpublicatie bleven wachten.

Dat verandert, om een eenvoudige commerciële reden. Leveranciers verkopen intake inmiddels als een eigen stap, met een eigen prijskaartje, portaal en API. De PIM blijft het system of record. Data in een vorm krijgen die de PIM kan vertrouwen, wordt het product van iemand anders.

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, met onboarding geprijsd per leverancier. 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 neemt dezelfde positie in, in gewone taal: de onboardinglaag tussen leveranciersbestanden en je PIM. Het leest pdf's en spreadsheets, mapt waarden op je bestaande model en houdt onzekere velden vast voor een mens voordat er iets in de catalogus wordt geschreven. SDM Portal trekt dezelfde knip verder door in de operatie. Je mapt het bestand van een leverancier één keer naar Ergonode, Akeneo of Pimcore in een visuele editor, daarna wordt elk nieuw bestand van die leverancier op die mapping gepubliceerd zonder ontwikkelticket, met een proefrun voordat er iets in de PIM terechtkomt. Drie bedrijven, één grens. De PIM beheert producten zodra ze binnen zijn. Ze binnen krijgen is het trage deel, en dat deel heeft nu eigen leveranciers.

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 knip. Intake zit vóór de PIM.

Je ziet hetzelfde patroon in hoe open-core PIM-leveranciers de markt verpakken. Toen we schreven over Tenzing dat Pimcore koopt, was de due-diligencevraag wie eigenaar is van het platform en de roadmap. Het loskomen van onboarding voegt een tweede due-diligencevraag toe: wie is eigenaar van de route van leverancierschaos naar dat platform. Een sterke PIM met een zwak intakeverhaal laat je nog steeds achter met de spreadsheet.

PIM's antwoorden met intake-API's

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

De Spring 2026-release van Inriver voegt Content Onboarding API-connectiviteit 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 positioneerden die API al als manier om systemen stroomopwaarts 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. Als er stroomopwaarts een gespecialiseerde laag ontstaat, opent de PIM een beheerde toegangsdeur naar zichzelf, in plaats van te doen alsof elk leveranciersbestand in de verrijkingsinterface thuishoort.

Dat is de juiste concurrentiereactie, en het bewijst de stelling nog steeds. Als je PIM een speciale onboarding-API met mapping en validatie uitbrengt, geeft hij toe dat intake een productonderdeel is, geen bijeffect van het hebben van attributen.

Wat dit betekent als je koopt

Stel je in 2026 een shortlist voor een PIM op, behandel leveranciersonboarding dan als een regel in de architectuur, niet als een demoslide. Drie praktische checks:

1. Waar wordt slechte data geweigerd? Als de eerste harde validatie pas plaatsvindt wanneer het record al in de PIM staat, betaal je je verrijkingsteam nog steeds om intake te doen.
2. Wie is eigenaar van het kanaal richting leveranciers? Een retailerschema in Salsify of Stibo PDX, een specialist zoals Onedot, openProd of SDM Portal, of het eigen portaal van de PIM zijn verschillende eigenaarschapsmodellen. Kies er bewust één. Drie tegelijk draaien is hoe teams een vierde spreadsheet uitvinden.
3. Wat verwacht je PIM aan de deur? 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 op die deur mikken, niet op een eigen importscript dat de regels omzeilt.

De afweging is echt. Een gespecialiseerde onboardinglaag voegt een extra leverancier toe, een extra contract en een extra plek waar attribuutdefinities kunnen afwijken van het PIM-model. Een intakeroute in de PIM zelf houdt het eigenaarschap op één plek, maar loopt mogelijk achter op de specialisten bij rommelige pdf's en chaos met meerdere leveranciers. Geen van beide keuzes is gratis. De dure keuze is doen alsof deze verschuiving niet plaatsvindt, terwijl je team elke maandag dezelfde leveranciersworkbook opnieuw mapt.

Dit is het eerste van vier stukken over één verschuiving: de PIM verliest zijn claim om de hele productdatastack te zijn en vestigt zich in de rol waarin hij altijd het sterkst was, het beheerde record in het midden. Elk deel bekijkt een andere rand waar werk uit de PIM verdwijnt naar een laag eromheen. 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 aan de andere kant naar buiten, waar publicatie verschuift 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 auditors moeten kunnen vertrouwen, en 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. Gebruik die kaart om laag voor laag te bepalen wat je de PIM wilt laten bezitten en wat je liever koopt, bouwt of aansluit, voordat een leveranciersdemo het voor je beslist.