Produktets vekt finnes i lagerstyringen. Andelen resirkulert materiale finnes i oppskriftssystemet. Leverandørens sertifikat ligger som PDF-fil på et nettverk. Produktpasset trenger alle tre opplysningene i én enkelt datasett, og det er nettopp dette som utgjør integrasjonsprosjektet - ikke sammenkoblingen av to systemer.
«Sømløs ERP-integrasjon» er et standardløfte som i praksis følges opp av et tre måneders prosjekt. Vi publiserer vår veiledning slik at IT-avdelingen din kan sjekke hva som faktisk blir etterspurt før kontrakten signeres. Denne artikkelen viser hvilke data produktpasset trenger fra systemene deres, på hvilke tre måter de kommer til oss, og hvorfor dette kan gjøres på to uker.
Hva ERP-systemet deres faktisk må levere
For å kunne opprette et produktpass trenger vi følgende per produkt:
- Stammeopplysninger - varenummer, betegnelse, varianter, vekt, dimensjoner, bilder
- Stykklisteopplysninger - komponenter med mengder og andel resirkulert materiale
- Opprinnelsesopplysninger - produksjonssted, batchnummer, produksjonsdato
- Miljøopplysninger - CO₂-ekvivalent per enhet, vannforbruk, energiforbruk
- Leverandørdata - hvem leverer hvilke komponenter (for aktsomhetspliktene)
I ERP-systemet ditt finnes alle disse dataene i teorien. I praksis er de fordelt på 4 til 7 moduler: materialforvaltning, produksjon, kvalitet, leverandørregister, noen ganger en egen modul for miljødata, noen ganger et eget system for oppskrifter og stykklister.
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 metoder
Metode 1: Hente dataene fra ERP-systemet
Fungerer godt med moderne ERP-systemer (SAP S/4HANA Cloud, Dynamics 365, Odoo). DPP-leverandøren henter dataene via ERP-systemets grensesnitt (teknisk sett OData eller REST). Kun endringene, enten etter tidsplan eller utløst av en hendelse.
Fordeler: lite utviklingsarbeid fra din side; du gir leseadgang, og leverandøren utvikler konverteringen.
Ulemper: fungerer ikke med eldre SAP ECC-installasjoner uten et ekstra grensesnittlag. Du trenger klare regler for hvem som har lov til å lese hvilke data.
Metode 2: Videresende endringer
Deres ERP-system melder fra om hver endring som en hendelse (via SAP Event Mesh, Apache Kafka eller RabbitMQ), og DPP-leverandøren mottar dem.
Fordeler: nesten i sanntid, skalerer med behovet, systemene er ikke avhengige av hverandre.
Ulemper: Konfigurasjonen er krevende og krever infrastruktur som ikke alle IT-avdelinger har. For mindre bedrifter er dette vanligvis overdrevet.
Metode 3: Bruke det eksisterende integrasjonslaget
Dere har allerede et integrasjonslag (Mulesoft, Boomi, Informatica, Azure Data Factory) mellom ERP-systemet og eksterne systemer. Dette laget fungerer som mellomleddet: DPP-leverandøren kommuniserer med dette laget, aldri direkte med ERP-systemet.
Fordeler: Eksisterende investeringer kan utnyttes, reglene forblir stabile, ingen direkte ERP-tilgang for tredjeparter.
Ulemper: Kostnadene for integrasjonslaget øker i takt med dette.
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: Vår grensesnitt aksepterer et nøytralt dataformat (et JSON-skjema) som du 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
- Dere kan bytte ut oss - det nøytrale formatet er portabelt
- Dere kan hente ut hele datamengden når som helst - som CSV, XLSX, JSON-LD og SQL, samt via REST-API
- Vi leverer en importvalidator som sjekker dataene deres før opplasting
Det fullstendige formatet og alle forespørsler er offentlig dokumentert under /apidocs, som en grensesnittbeskrivelse i henhold til OpenAPI. IT-avdelingen din kan sjekke grensesnittet før en kontrakt signeres - 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 styklisten. Ingen har et konsistent bilde. Løsning: Definer før prosjektstart hvilket system som er det ledende 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 henting via grensesnitt (OEKO-TEX ligger i forkant, 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, tilpasse leverandørkontraktene på lang sikt. 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 et integrasjonslag som bør benyttes?
- Finnes det allerede et fungerende grensesnitt via ERP-systemet deres?
Svarene avgjør hvilken av de tre løsningene som passer best for dere. Og de avgjør om et prosjekt vil ta to uker eller seks måneder.
Spørsmål om dette innlegget
Er REST-grensesnittet tilstrekkelig, eller trenger vi en mellomvare?
Grensesnittet er tilstrekkelig. De tre modellene skiller seg fra hverandre med hensyn til hvor transformasjonen finner sted, ikke med hensyn til hva vi mottar - grensesnittet vårt aksepterer et nøytralt JSON-skjema, uansett hva du har brukt til å generere det. En henting fra et moderne ERP-system, en hendelsesstrøm og et eksisterende integrasjonslag ender alle på samme endepunkt. Middleware er verdt å bruke hvis du uansett allerede har en i drift og den skal forbli kontrakten overfor tredjeparter. Hvis du ikke har noen i dag, trenger du ikke å kjøpe noen for produktpasset.
Hva blir det bestemt på kartleggingsverkstedet?
Hvilket ERP-felt som skal være referansefelt - og hvilket system som er den ledende kilden når flere systemer har samme verdi. Workshopen finner sted på dag 1 og 2 og er det avgjørende punktet i hele prosjektet, fordi det er der man tar beslutninger om datakvalitet, og ikke senere i koden. Ta med de som vedlikeholder systemene, ikke bare de som har ansvaret for prosjektet - stamdata, produksjon, kvalitet og innkjøp er sjelden samlet i én avdeling. Alt som kommer etterpå, altså eksport, validering og feilretting, er håndverk.
Sertifikatene våre finnes kun som PDF-skanninger. Hva skal vi gjøre med dem?
En skanning er ikke en strukturert datakilde og kan derfor ikke brukes til passet. Det finnes to måter å gjøre dette på: Sertifiseringsoperatører tilbyr i økende grad API-forespørsler, og der dette ikke er tilgjengelig, må du registrere verdiene manuelt, men alltid med gyldighetsdato, slik at det ikke forblir et utløpt sertifikat i et publisert pass. Planlegg den manuelle metoden som en gjentakende oppgave, ikke som en engangsoppgave.
Kan IT-avdelingen vår sjekke grensesnittet før vi signerer noe?
Ja. Det fullstendige skjemaet og alle endepunktene er tilgjengelige som en OpenAPI-spesifikasjon under /apidocs, med eksempler på forespørsler, feilmeldinger og autentiseringsdetaljer. Ingenting av dette er avhengig av en salgssamtale, så integrasjonsteamet ditt kan vurdere arbeidsomfanget før det foreligger en kontrakt. Hvis en leverandør ikke viser grensesnittet sitt i denne fasen, er også det et svar.
Hva skjer med opplysningene våre når vi bytter leverandør?
De følger med. Grensesnittet aksepterer et nøytralt JSON-skjema i stedet for et proprietært format, og hele datamengden din blir eksportert som CSV, XLSX, JSON-LD og SQL eller via REST-API-et. Dette er med vilje - formatet du fyller ut er portabelt, så et bytte krever bare en eksport og ikke en ny oppbygging. Still alle leverandører det samme spørsmålet før kartleggingsworkshopen, for etterpå vil feltnavnene dine være i deres modell.
Hvor lang tid tar en tilkobling egentlig?
I prosjektene vi følger opp, tar det to uker - to dager med kartlegging, tre dager frem til de første eksportene gjennom vår validator, tre dager med feilretting, to dager frem til de første passene blir publisert. Den lange veien ligger aldri i koden, men i det validatoren finner - manglende felt, inkonsekvent koding, verdier som ingen føler seg ansvarlig for. Sett av tid til disse dagene, i stedet for å kutte dem ned. Et prosjekt som hopper over dem, publiserer også manglene.
Må vi koble til alle produktene på en gang?
Nei. Begynn med produktene som trenger en pass først, og med et kildesystem - det nøytrale skjemaet aksepterer både delkataloger og fullstendige kataloger, og importene kan gjentas, slik at senere kjøringer oppdaterer beholdningen. Dette gjør også at kartleggingsworkshopen blir kort nok til å gjennomføres på to dager. Utvidelsen etterpå er en kartleggingsoppgave, ikke et nytt prosjekt.
