Het gewicht van een product staat in het materiaalbeheersysteem. Het aandeel gerecycled materiaal staat in het receptsysteem. Het certificaat van de leverancier staat als PDF op een netwerkschijf. Het productpaspoort heeft alle drie de gegevens in één enkel gegevensrecord nodig, en precies daarin schuilt de kern van het integratieproject, niet in de koppeling tussen twee systemen.
„Naadloze ERP-integratie“ is een standaardbelofte, die in de praktijk wordt gevolgd door een project van drie maanden. Wij publiceren onze handleiding zodat uw IT-afdeling vóór het ondertekenen van het contract kan controleren wat er daadwerkelijk wordt opgevraagd. Dit artikel laat zien welke gegevens het paspoort uit uw systemen nodig heeft, via welke drie wegen deze bij ons terechtkomen en waarom dit binnen twee weken kan worden gerealiseerd.
Wat uw ERP-systeem daadwerkelijk moet leveren
Om een DPP te kunnen opstellen, hebben wij per product het volgende nodig:
- Stamgegevens - artikelnummer, benaming, varianten, gewichten, afmetingen, afbeeldingen
- Stuklijstgegevens - componenten met hoeveelheden en het aandeel gerecycled materiaal
- Herkomstgegevens - productielocatie, batchnummer, productiedatum
- Milieugegevens - CO₂eq per eenheid, waterverbruik, energieverbruik
- Leveranciersgegevens - wie levert welke component (voor de zorgvuldigheidsverplichtingen)
In uw ERP zijn deze gegevens in theorie allemaal aanwezig. In de praktijk zijn ze verdeeld over 4 tot 7 modules: materiaalbeheer, productie, kwaliteit, leveranciersbestand, soms een aparte module voor milieugegevens, soms een apart systeem voor recepturen en stuklijsten.
De integratievraag luidt niet: „Levert uw ERP-systeem gegevens aan een DPP?” De vraag is: „Hoe brengt u de gegevens uit vijf subsystemen samen tot één samenhangend gegevensbestand?”
Drie beproefde methoden
Methode 1: De gegevens uit het ERP-systeem ophalen
Werkt goed met moderne ERP-systemen (SAP S/4HANA Cloud, Dynamics 365, Odoo). De DPP-aanbieder haalt de gegevens op via de interface van het ERP-systeem (technisch gezien OData of REST). Alleen de wijzigingen, volgens een tijdschema of getriggerd door een gebeurtenis.
Voordelen: weinig ontwikkelingswerk van uw kant; u verstrekt leestoegang, de aanbieder zorgt voor de conversie.
Nadelen: werkt niet met oudere SAP ECC-installaties zonder extra interface-laag. U hebt duidelijke regels nodig over wie welke gegevens mag inzien.
Methode 2: Wijzigingen doorsturen
Uw ERP meldt elke wijziging als een gebeurtenis (via SAP Event Mesh, Apache Kafka of RabbitMQ), waarna de DPP-aanbieder deze ontvangt.
Voordelen: vrijwel in realtime, schaalbaar, de systemen zijn niet van elkaar afhankelijk.
Nadelen: de implementatie is veeleisend en vereist infrastructuur waarover niet elke IT-afdeling beschikt. Voor kleinere bedrijven meestal overdreven.
Methode 3: Gebruikmaken van de bestaande integratielaag
U beschikt al over een integratielaag (Mulesoft, Boomi, Informatica, Azure Data Factory) tussen het ERP-systeem en externe systemen. Deze laag vormt de schakel: de DPP-aanbieder communiceert hiermee, nooit rechtstreeks met het ERP-systeem.
Voordelen: bestaande investeringen kunnen worden benut, de regels blijven stabiel, geen directe ERP-toegang voor derden.
Nadelen: uw kosten voor de integratielaag stijgen mee.
Wat wij in concrete projecten anders aanpakken
Veel aanbieders willen rechtstreeks verbinding maken met uw ERP-systeem. Wij bouwen in principe een tussenstap in: onze interface accepteert een neutraal gegevensformaat (een JSON-schema), dat u met een tool naar keuze kunt vullen. Dat betekent:
- U kunt de gegevensverwerking zelf uitvoeren, met de tools die uw team kent
- U kunt ons vervangen - het neutrale formaat is overdraagbaar
- U kunt uw volledige gegevensbestand op elk moment weer ophalen - als CSV, XLSX, JSON-LD en SQL, evenals via de REST-API
- Wij leveren een importvalidator die uw gegevens vóór het uploaden controleert
Het volledige formaat en alle query’s zijn openbaar gedocumenteerd op /apidocs, als interfacebeschrijving volgens OpenAPI. Uw IT-afdeling kan de interface controleren voordat een contract wordt ondertekend - inclusief voorbeeldverzoeken, foutmeldingen en authenticatiegegevens.
Tijdschema voor deze aanpak in de praktijk:
- Dag 1 tot en met 2: mappingworkshop. Welk ERP-veld wordt welk DPP-veld?
- Dag 3 tot en met 5: eerste JSON-exporten vanuit het ERP-systeem, gecontroleerd door onze validator.
- Dag 6 tot en met 8: Foutopsporing (ontbrekende velden, inconsistente coderingen).
- Dag 9 tot en met 10: De eerste DPP’s zijn live.
Twee weken, geen drie maanden. Het cruciale punt is de mapping-workshop - daar wordt beslist over de gegevenskwaliteit.
Wat er misgaat: de meest voorkomende valkuilen
Productstamgegevens in meerdere systemen: SAP heeft het artikelnummer, PIM heeft de afbeeldingen en marketingteksten, PLM heeft de stuklijst. Niemand heeft een consistent overzicht. Oplossing: bepaal voorafgaand aan het project welk systeem voor welk veld de leidende bron is.
Certificaten als PDF: leveranciers leveren GOTS-, OEKO-TEX- of REACH-certificaten aan als gescande PDF-bestanden. Dit is geen gestructureerde gegevensbron. Oplossing: certificeringsinstanties bieden in toenemende mate de mogelijkheid om gegevens via een interface op te vragen (OEKO-TEX loopt voorop, GOTS blijft achter). Of: voer de gegevens handmatig in, maar met een geldigheidsdatum, zodat er geen verlopen certificaten in het DPP verschijnen.
Geheimhouding van de samenstelling: met name in de cosmetica-, voedingsmiddelen- en farmaceutische sector is de volledige samenstelling een bedrijfsgeheim. Moet het DPP deze openbaar maken? Oplossing: het drielagenmodel van de ESPR. De productcategorie is openbaar, autoriteiten hebben inzage in de volledige samenstelling. Dit vormt vrijwel nooit een belemmering, maar moet in een vroeg stadium worden opgehelderd.
CO₂-gegevens op basis van toeleveranciers: uw toeleverancier geeft een gemiddelde waarde voor zijn gehele portfolio, niet per partij. Oplossing: dit tijdelijk accepteren en op lange termijn de leverancierscontracten aanpassen. De ESPR vereist productspecifieke waarden vanaf een bepaalde peildatum, maar de huidige praktijk is een compromis.
Lokale taalversies: Uw ERP-systeem bevat alleen de productnaam in het Duits en het Engels. Voor 27 EU-landen heeft u meer nodig. Oplossing: automatische vertaling met een terminologiedatabase; hierover hebben wij een apart artikel.
De vragen die u vóór het project moet stellen
Voordat u een offerteaanvraag naar drie aanbieders verstuurt, beantwoordt u intern de volgende vragen:
- Hoeveel producten/artikelnummers moeten DPP’s bevatten? (10, 10.000, 1 miljoen?)
- Welke systemen bevatten momenteel DPP-relevante gegevens?
- Welke afdeling beheert elk van de systemen?
- Beschikt u over een integratielaag die moet worden gebruikt?
- Bestaat er al een werkende koppeling via uw ERP-systeem?
De antwoorden bepalen welke van de drie benaderingen voor u geschikt is. En ze bepalen of een project twee weken of zes maanden duurt.
Vragen over dit artikel
Is de REST-interface voldoende, of hebben wij middleware nodig?
De interface volstaat. De drie voorbeelden verschillen in de plaats waar de transformatie plaatsvindt, niet in wat wij ontvangen - onze interface accepteert een neutraal JSON-schema, ongeacht waarmee u dit hebt gegenereerd. Een pull uit een modern ERP-systeem, een gebeurtenissenstroom en een bestaande integratielaag komen allemaal op hetzelfde eindpunt terecht. Middleware is de moeite waard als u er toch al een gebruikt en deze de contractuele verbinding met derden moet blijven vormen. Als er momenteel geen is, schaf er dan geen aan voor de productpas.
Wat wordt er tijdens de mapping-workshop beslist?
Welk ERP-veld wordt welk passveld - en welk systeem is de leidende bron wanneer meerdere systemen dezelfde waarde bevatten? De workshop vindt plaats op dag 1 en 2 en vormt het cruciale punt van het gehele project, omdat daar beslissingen over de gegevenskwaliteit worden genomen en niet pas later in de code. Neem de personen mee die de systemen onderhouden, niet alleen degenen die verantwoordelijk zijn voor het project - stamgegevens, productie, kwaliteit en inkoop bevinden zich zelden binnen één afdeling. Alles wat daarna volgt, dus exporten, validatie en foutopsporing, is vakwerk.
Onze certificaten zijn alleen beschikbaar als PDF-scan. Wat moeten wij hiermee doen?
Een scan is geen gestructureerde gegevensbron en daarom onbruikbaar voor het paspoort. Er zijn twee manieren waarop dit kan worden opgelost: certificeringsinstanties bieden steeds vaker API-query’s aan, en waar die niet beschikbaar zijn, voert u de waarden handmatig in, maar altijd met de geldigheidsdatum, zodat er geen verlopen certificaat in een gepubliceerd paspoort achterblijft. Plan de handmatige werkwijze in als een terugkerende taak, niet als een eenmalige taak.
Kan onze IT-afdeling de interface controleren voordat wij iets ondertekenen?
Ja. Het volledige schema en alle eindpunten zijn beschikbaar als OpenAPI-specificatie onder /apidocs, inclusief voorbeeldverzoeken, foutmeldingen en authenticatiegegevens. Dit alles is niet gebonden aan een verkoopgesprek, zodat uw integratieteam de benodigde inspanning kan inschatten nog voordat er een contract is gesloten. Indien een aanbieder zijn interface in deze fase niet openbaar maakt, is dat ook een antwoord op zich.
Wat gebeurt er met onze gegevens als wij van aanbieder veranderen?
Ze gaan mee. De interface accepteert een neutraal JSON-schema in plaats van een eigen formaat, en uw volledige inventaris wordt weer uitgevoerd als CSV, XLSX, JSON-LD en SQL of via de REST-API. Dat is de bedoeling - het formaat dat u invult, is draagbaar, dus een overstap kost slechts een export en geen nieuwe opbouw. Stel elke aanbieder dezelfde vraag vóór de mapping-workshop, want daarna staan uw veldnamen in diens model.
Hoe lang duurt een aansluiting werkelijk?
In de projecten die wij begeleiden: twee weken - twee dagen voor het in kaart brengen, drie dagen tot de eerste exporten via onze validator, drie dagen voor het verhelpen van fouten, twee dagen tot de eerste gepubliceerde paspoorten. Het meest tijdrovende onderdeel is nooit de code zelf, maar wat de validator aan het licht brengt: ontbrekende velden, inconsistente coderingen, waarden waarvoor niemand zich verantwoordelijk voelt. Houd rekening met deze dagen in uw planning, in plaats van ze in te korten. Een project dat deze stappen overslaat, publiceert de hiaten mee.
Moeten wij alle producten in één keer koppelen?
Nee. Begin met de producten waarvoor eerst een pas nodig is, en met een bronsysteem - het neutrale schema accepteert zowel een gedeeltelijke catalogus als een volledige, en importen zijn herhaalbaar; latere runs werken de voorraad dus bij. Hierdoor blijft de mapping-workshop ook klein genoeg om deze in twee dagen af te ronden. De uitbreiding daarna is een mappingtaak, geen nieuw project.
