«Naadloze ERP-integratie» is een standaardbelofte, die in de praktijk wordt gevolgd door een project van drie maanden. We publiceren ons API-playbook, zodat uw IT-afdeling vóór het ondertekenen van het contract kan controleren wat er daadwerkelijk wordt opgevraagd. Dit is wat u moet weten voordat u aan een integratieproject begint.
Wat uw ERP-systeem eigenlijk moet leveren
Om een DPP te kunnen opstellen, hebben we 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₂-equivalent per eenheid, waterverbruik, energieverbruik
- Leveranciersgegevens - wie levert welke component (voor due diligence)
In uw ERP zijn deze gegevens in theorie allemaal aanwezig. In de praktijk zijn ze verspreid over 4 tot 7 modules: materiaalbeheer (MM), productie (PP), kwaliteit (QM), leveranciers (LFA1), soms een aparte EHS-module voor milieugegevens, soms een PLM-systeem voor recepturen.
De integratievraag is niet: „Levert uw ERP-systeem gegevens aan een DPP?“ De vraag is: „Hoe brengt u de gegevens uit 5 subsystemen samen tot één samenhangende dataset?“
Drie beproefde integratiemodellen
Model 1: OData / REST-pull
Werkt goed met moderne ERP-systemen (SAP S/4HANA Cloud, Dynamics 365, Odoo). De DPP-aanbieder haalt gegevens op via OData of REST. Incrementeel, gepland of gebeurtenisgestuurd.
Voordelen: weinig ontwikkelingswerk van uw kant; u verstrekt leesrechten, de aanbieder bouwt de transformatie.
Nadelen: werkt niet met oudere SAP ECC-installaties zonder extra API-laag. U hebt governance nodig over verzoeken om gegevenstoegang.
Patroon 2: Gebeurtenisgestuurde integratie
SAP Event Mesh, Apache Kafka, RabbitMQ. Uw ERP publiceert wijzigingsgebeurtenissen, de DPP-aanbieder verwerkt deze.
Voordelen: vrijwel in realtime, elegant schaalbaar, ontkoppeld.
Nadelen: de implementatie is veeleisend en vereist infrastructuur waar niet elke IT-afdeling over beschikt. Voor kleinere bedrijven meestal overdreven.
Patroon 3: Middleware / ETL
U beschikt over een integratielaag (Mulesoft, Boomi, Informatica, Azure Data Factory) tussen het ERP-systeem en externe systemen. De middleware fungeert als tussenpersoon - de DPP-aanbieder communiceert met de middleware, nooit rechtstreeks met het ERP-systeem.
Voordelen: bestaande investeringen kunnen worden benut, stabiel beheer, geen directe toegang tot het ERP-systeem voor derden.
Nadelen: uw middleware-kosten stijgen mee.
Wat wij in concrete projecten anders aanpakken
Veel aanbieders willen rechtstreeks verbinding maken met uw ERP. Wij bouwen in principe een tussenstap in: onze API accepteert een neutraal JSON-schema, dat u met een tool naar keuze kunt vullen. Dat betekent:
- U kunt de gegevens zelf voorbereiden, met de tools die uw team kent
- U kunt van leverancier wisselen - 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 schema en alle eindpunten zijn openbaar gedocumenteerd als OpenAPI-specificatie op /apidocs. Uw IT-afdeling kan de interface controleren voordat er een contract wordt ondertekend - inclusief voorbeeldverzoeken, foutmeldingen en authenticatiegegevens.
Tijdschema voor deze aanpak in de praktijk:
- Dag 1 tot en met 2: mapping-workshop. Welk ERP-veld wordt welk DPP-veld?
- Dag 3 tot en met 5: eerste JSON-exports vanuit het ERP, via 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 beeld. Oplossing: bepaal vóór het project welk systeem de ‘Source of Truth’ is voor welk veld.
Certificaten als PDF: leveranciers leveren GOTS-, OEKO-TEX- of REACH-certificaten aan als PDF-scan. Dat is geen gestructureerde gegevensbron. Oplossing: certificeringsinstanties bieden steeds vaker API-query’s aan (OEKO-TEX loopt voorop, GOTS blijft achter). Of: handmatig invoeren, maar met een geldigheidsdatum, zodat er geen verlopen certificaten in het DPP terechtkomen.
Geheimhouding van de samenstelling: met name in cosmetica, levensmiddelen en de farmaceutische sector: de volledige samenstelling is een bedrijfsgeheim. Moet het DPP deze openbaar maken? Oplossing: het drielagenmodel van de ESPR. De productcategorie is openbaar, autoriteiten zien de volledige receptuur. Dit vormt bijna nooit een belemmering, maar moet wel in een vroeg stadium worden opgehelderd.
CO₂-gegevens op leveranciersbasis: uw leverancier geeft een gemiddelde waarde voor zijn gehele portfolio, niet per batch. Oplossing: tijdelijk accepteren, op lange termijn leverancierscontracten aanpassen. De ESPR eist 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 Engels. Voor 27 EU-landen heeft u meer nodig. Oplossing: machinevertaling met een terminologiedatabase; hierover hebben we een apart artikel.
De vragen die u vóór het project moet stellen
Voordat u een offerteaanvraag naar drie aanbieders stuurt, beantwoordt u intern:
- Hoeveel producten/artikelnummers moeten DPP’s hebben? (10, 10.000, 1 miljoen?)
- Welke systemen bevatten momenteel DPP-relevante gegevens?
- Welke afdeling beheert elk van de systemen?
- Heeft u een investering in middleware die benut moet worden?
- Is er al een werkende API-laag bovenop uw ERP?
De antwoorden bepalen welk van de drie modellen voor u geschikt is. En ze bepalen of een project twee weken of zes maanden duurt.