«Sømløs ERP-integrasjon» er et standardløfte som i praksis følges opp av et tre måneders prosjekt. Vi publiserer vårt API-håndbok slik at IT-avdelingen deres kan sjekke hva som faktisk blir hentet ut før kontrakten signeres. Her er det du bør vite før et integrasjonsprosjekt.
Hva ERP-systemet ditt faktisk må levere
For å kunne lage en DPP trenger vi følgende per produkt:
- Stamdata - varenummer, betegnelse, varianter, vekt, masse, bilder
- Stykklisteopplysninger - komponenter med mengder og andel resirkulert materiale
- Opprinnelsesdata - produksjonssted, batchnummer, produksjonsdato
- Miljødata - CO₂-ekvivalent per enhet, vannforbruk, energiforbruk
- Leverandørdata - hvem leverer hvilke komponenter (for due diligence)
Teoretisk sett finnes alle disse dataene i ERP-systemet deres. I praksis er de spredt over 4 til 7 moduler: Materialforvaltning (MM), Produksjon (PP), Kvalitet (QM), Leverandør (LFA1), noen ganger et eget EHS-modul for miljødata, noen ganger et PLM-system for formler.
Integrasjonsspørsmålet er ikke: «Leverer ERP-systemet ditt data til en DPP?» Det er: «Hvordan samler du dataene fra fem delsystemer til et sammenhengende datasett?»
Tre velprøvde integrasjonsmønstre
Mønster 1: OData / REST-Pull
Fungerer godt med moderne ERP-systemer (SAP S/4HANA Cloud, Dynamics 365, Odoo). DPP-leverandøren henter data via OData eller REST. Inkrementelt, planlagt eller hendelsesstyrt.
Fordeler: lite utviklingsarbeid fra deres side, dere stiller til rådighet lesetilgangsopplysninger, leverandøren bygger transformasjonen.
Ulemper: fungerer ikke med eldre SAP ECC-installasjoner uten et ekstra API-lag. Dere trenger styring av dataadgangsforespørsler.
Mønster 2: Hendelsesbasert integrasjon
SAP Event Mesh, Apache Kafka, RabbitMQ. ERP-systemet ditt publiserer endringshendelser, og DPP-leverandøren forbruker dem.
Fordeler: nesten i sanntid, elegant skalerbar, avkoblet.
Ulemper: Konfigurasjonen er krevende og krever infrastruktur som ikke alle IT-avdelinger har. For mindre bedrifter er dette som regel overdrevet.
Mønster 3: Middleware / ETL
Du har et integrasjonslag (Mulesoft, Boomi, Informatica, Azure Data Factory) mellom ERP-systemet og eksterne systemer. Middleware er bindeleddet - DPP-leverandøren kommuniserer med middleware, aldri direkte med ERP-systemet.
Fordeler: eksisterende investeringer kan utnyttes, stabil styring, ingen direkte ERP-tilgang for tredjeparter.
Ulemper: Kostnadene for mellomvaren øker i takt med skaleringen.
Hva vi gjør annerledes i konkrete prosjekter
Mange leverandører ønsker å koble seg direkte til ERP-systemet deres. Vi bygger som regel inn et mellomtrinn: API-et vårt aksepterer et nøytralt JSON-skjema som dere fyller ut med et verktøy etter eget valg. Det betyr:
- Du kan utføre databehandlingen selv, med verktøyene teamet ditt er kjent med
- Du kan bytte ut oss - det nøytrale formatet er portabelt
- Du kan hente ut hele datamengden din når som helst - som CSV, XLSX, JSON-LD og SQL, samt via REST-API-et
- Vi leverer en importvalidator som sjekker dataene dine før opplastingen
Det fullstendige skjemaet og alle endepunkter er offentlig dokumentert som en OpenAPI-spesifikasjon under /apidocs. IT-avdelingen din kan teste grensesnittet før en avtale inngås - inkludert eksempelforespørsler, feilmeldinger og autentiseringsdetaljer.
Tidsramme for denne tilnærmingen i praksis:
- Dag 1 til 2: Kartleggingsworkshop. Hvilket ERP-felt blir hvilket DPP-felt?
- Dag 3 til 5: Første JSON-eksport fra ERP-systemet, gjennom vår valideringsverktøy.
- Dag 6 til 8: Feilretting (manglende felt, inkonsekvent koding).
- Dag 9 til 10: De første DPP-ene er live.
To uker, ikke tre måneder. Det avgjørende er kartleggingsworkshopen - der avgjøres datakvaliteten.
Hva som kan gå galt: de vanligste fallgruvene
Produktstamdata i flere systemer: SAP har varenummeret, PIM har bildene og markedsføringstekstene, PLM har stykklisten. Ingen har et konsistent bilde. Løsning: Definer før prosjektstart hvilket system som er «Source of Truth» for hvert felt.
Sertifikater som PDF: Leverandører leverer GOTS-, OEKO-TEX- eller REACH-sertifikater som PDF-skanninger. Dette er ikke en strukturert datakilde. Løsning: Sertifiseringsorganer tilbyr i økende grad API-forespørsler (OEKO-TEX ligger i front, GOTS henger etter). Eller: registrer manuelt, men med gyldighetsdato, slik at ingen utløpte sertifikater dukker opp i DPP.
Hemmelighold av sammensetning: spesielt innen kosmetikk, matvarer og legemidler: den fullstendige sammensetningen er en bedriftshemmelighet. Skal DPP offentliggjøre den? Løsning: ESPRs tre-nivå-modell. Produktkategorien er offentlig, mens myndighetene ser den fullstendige sammensetningen. Dette er nesten aldri et hinder, men må avklares tidlig.
CO₂-data på leverandørbasis: Leverandøren oppgir en gjennomsnittsverdi for hele porteføljen, ikke per batch. Løsning: Akseptere dette midlertidig, og på lang sikt tilpasse leverandørkontraktene. ESPR krever produktspesifikke verdier fra en bestemt dato, men dagens praksis er et kompromiss.
Lokale språkversjoner: ERP-systemet ditt inneholder kun produktbetegnelsen på tysk og engelsk. For 27 EU-land trenger du mer. Løsning: Maskinoversettelse med terminologidatabase - vi har en egen artikkel om dette.
Spørsmålene du bør stille før prosjektet
Før du sender en anbudsforespørsel (RFP) til tre leverandører, bør du svare på følgende internt:
- Hvor mange produkter/varenumre skal ha DPP-er? (10, 10 000, 1 million?)
- Hvilke systemer inneholder i dag DPP-relevante data?
- Hvilken avdeling administrerer hvert av systemene?
- Har dere en middleware-investering som bør utnyttes?
- Finnes det allerede et fungerende API-lag over ERP-systemet deres?
Svarene avgjør hvilken av de tre modellene som passer for dere. Og de avgjør om et prosjekt vil ta to uker eller seks måneder.