»Problemfri ERP-integration« er et standardløfte, der i praksis efterfølges af et tre måneders projekt. Vi offentliggør vores API-playbook, så jeres IT-afdeling kan tjekke, hvad der rent faktisk bliver forespurgt, inden kontrakten underskrives. Her er, hvad I bør vide, inden I går i gang med et integrationsprojekt.
Hvad dit ERP-system faktisk skal levere
For at der kan oprettes en DPP, har vi brug for følgende pr. produkt:
- Stammdata - varenummer, betegnelse, varianter, vægt, mål, billeder
- Styklisteoplysninger - komponenter med mængder og andel af genanvendt materiale
- Oprindelsesdata - produktionssted, batchnummer, produktionsdato
- Miljødata - CO2eq pr. enhed, vandforbrug, energiforbrug
- Leverandørdata - hvem leverer hvilke komponenter (til due diligence)
I jeres ERP-system findes disse data i teorien alle sammen. I praksis er de fordelt på 4 til 7 moduler: Materialestyring (MM), Produktion (PP), Kvalitet (QM), Leverandør (LFA1), undertiden et separat EHS-modul til miljødata, undertiden et PLM-system til formler.
Spørgsmålet om integration er ikke: »Leverer jeres ERP-system data til en DPP?« Det er: »Hvordan samler I dataene fra fem delsystemer til et sammenhængende datasæt?«
Tre gennemprøvede integrationsmønstre
Mønster 1: OData / REST-Pull
Fungerer godt med moderne ERP-systemer (SAP S/4HANA Cloud, Dynamics 365, Odoo). DPP-udbyderen henter data via OData eller REST. Inkrementelt, planlagt eller begivenhedsstyret.
Fordele: minimal udviklingsindsats fra jeres side; I stiller læseadgangskoder til rådighed, og udbyderen bygger transformationen.
Ulemper: fungerer ikke med ældre SAP ECC-installationer uden et ekstra API-lag. I har brug for governance over dataadgangsanmodninger.
Model 2: Begivenhedsbaseret integration
SAP Event Mesh, Apache Kafka, RabbitMQ. Jeres ERP offentliggør ændringsbegivenheder, og DPP-udbyderen forbruger dem.
Fordele: Næsten i realtid, elegant skalerbar, afkoblet.
Ulemper: Konfigurationen er krævende og kræver en infrastruktur, som ikke alle IT-afdelinger har. For mindre virksomheder er det som regel overdrevet.
Model 3: Middleware / ETL
De har et integrationslag (Mulesoft, Boomi, Informatica, Azure Data Factory) mellem ERP og eksterne systemer. Middlewaren fungerer som mellemled - DPP-udbyderen kommunikerer med middlewaren, aldrig direkte med ERP-systemet.
Fordele: Eksisterende investeringer kan udnyttes, stabil governance, ingen direkte ERP-adgang for tredjeparter.
Ulemper: Jeres middleware-omkostninger stiger i takt med væksten.
Hvad vi gør anderledes i konkrete projekter
Mange udbydere ønsker at oprette en direkte forbindelse til jeres ERP-system. Vi indbygger som udgangspunkt et mellemled: Vores API accepterer et neutralt JSON-skema, som I udfylder med et værktøj efter eget valg. Det betyder:
- De kan selv stå for databehandlingen med de værktøjer, som jeres team kender
- De kan skifte udbyder - det neutrale format er portabelt
- De kan til enhver tid hente hele jeres databeholdning ud igen - som CSV, XLSX, JSON-LD og SQL samt via REST-API’en
- Vi leverer en importvalidator, der kontrollerer dine data inden upload
Det fulde skema og alle endpoints er offentligt dokumenteret som en OpenAPI-specifikation under /apidocs. Jeres IT-afdeling kan teste grænsefladen, inden en kontrakt underskrives - inklusive eksempelforespørgsler, fejlmeddelelser og autentificeringsoplysninger.
Tidsramme for denne tilgang i praksis:
- Dag 1 til 2: Mapping-workshop. Hvilket ERP-felt svarer til hvilket DPP-felt?
- Dag 3 til 5: Første JSON-eksport fra ERP-systemet gennem vores validator.
- Dag 6 til 8: Fejlretning (manglende felter, inkonsekvent kodning).
- Dag 9 til 10: De første DPP’er er live.
To uger, ikke tre måneder. Det afgørende punkt er kortlægningsworkshoppen - det er her, datakvaliteten afgøres.
Hvad der kan gå galt: de hyppigste faldgruber
Produktstamdata i flere systemer: SAP har varenummeret, PIM har billederne og marketingteksterne, PLM har styklisten. Ingen har et sammenhængende overblik. Løsning: Definer inden projektet, hvilket system der er »Source of Truth« for hvilket felt.
Certifikater som PDF: Leverandører leverer GOTS-, OEKO-TEX- eller REACH-certifikater som PDF-scanninger. Det er ikke en struktureret datakilde. Løsning: Certificeringsudbydere tilbyder i stigende grad API-forespørgsler (OEKO-TEX er foran, GOTS halter bagefter). Eller: Indtast manuelt, men med gyldighedsdato, så der ikke dukker udløbne certifikater op i DPP.
Formelhemmeligholdelse: især inden for kosmetik, fødevarer og lægemidler: den fulde formel er en forretningshemmelighed. Skal DPP offentliggøre den? Løsning: ESPR’s tre-niveau-model. Produktkategorien er offentlig, mens myndighederne kan se den fulde opskrift. Dette udgør næsten aldrig en hindring, men skal afklares tidligt.
CO2-data baseret på leverandører: Jeres leverandør angiver en gennemsnitsværdi for hele sin portefølje, ikke pr. batch. Løsning: Accepter det midlertidigt, og tilpas leverandørkontrakterne på lang sigt. ESPR kræver produktspecifikke værdier fra en bestemt dato, men den nuværende praksis er et kompromis.
Lokale sprogversioner: Jeres ERP-system indeholder kun produktbetegnelsen på tysk og engelsk. Til 27 EU-lande har I brug for mere. Løsning: Maskinoversættelse med terminologidatabase - vi har en separat artikel om dette.
De spørgsmål, I bør stille jer selv inden projektet
Inden du sender en RFP til tre leverandører, skal du internt besvare følgende:
- Hvor mange produkter/varenumre skal have DPP’er? (10, 10.000, 1 million?)
- Hvilke systemer indeholder i dag DPP-relevante data?
- Hvilken afdeling administrerer de enkelte systemer?
- Har I en middleware-investering, der bør udnyttes?
- Findes der allerede et fungerende API-lag oven på jeres ERP-system?
Svarene afgør, hvilken af de tre modeller der passer til jer. Og de bestemmer, om et projekt varer to uger eller seks måneder.