Produktets vægt findes i lagerstyringssystemet. Andelen af genbrugsmateriale findes i receptursystemet. Leverandørens certifikat ligger som PDF på et netværksdrev. Produktpasset har brug for alle tre oplysninger i én enkelt datapost, og det er netop dét, integrationsprojektet handler om - ikke om at forbinde to systemer.
»Problemfri ERP-integration« er et standardløfte, der i praksis efterfølges af et tre måneders projekt. Vi offentliggør vores vejledning, så jeres IT-afdeling kan tjekke, hvad der rent faktisk kræves, inden kontrakten underskrives. Denne artikel viser, hvilke data produktpasset har brug for fra jeres systemer, på hvilke tre måder de kommer til os, og hvorfor det kan klares på to uger.
Hvad jeres ERP-system faktisk skal levere
For at der kan oprettes et produktpas, har vi brug for følgende pr. produkt:
- Stammdata - varenummer, betegnelse, varianter, vægt, mål, billeder
- Stykelisteoplysninger - komponenter med mængder og andel af genanvendt materiale
- Oprindelsesoplysninger - produktionssted, batchnummer, produktionsdato
- Miljøoplysninger - CO2-ækvivalent pr. enhed, vandforbrug, energiforbrug
- Leverandøroplysninger - hvem leverer hvilke komponenter (til overholdelse af due diligence-kravene)
I jeres ERP-system findes disse data i teorien alle sammen. I praksis er de fordelt på 4 til 7 moduler: Materialestyring, Produktion, Kvalitet, Leverandørstam, undertiden et separat modul til miljødata, undertiden et eget system til recepturer og styklister.
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 metoder
Metode 1: Hente dataene fra ERP-systemet
Fungerer godt med moderne ERP-systemer (SAP S/4HANA Cloud, Dynamics 365, Odoo). DPP-udbyderen henter dataene via ERP-systemets grænseflade (teknisk set OData eller REST). Kun ændringerne, enten efter en tidsplan eller udløst af en begivenhed.
Fordele: minimalt udviklingsarbejde fra Deres side; De giver læseadgang, og udbyderen står for konverteringen.
Ulemper: fungerer ikke med ældre SAP ECC-installationer uden et ekstra grænsefladelag. Der skal være klare regler for, hvem der må læse hvilke data.
Metode 2: Videresend ændringer
Jeres ERP-system rapporterer hver ændring som en begivenhed (via SAP Event Mesh, Apache Kafka eller RabbitMQ), som DPP-udbyderen modtager.
Fordele: Næsten i realtid, skalerer med behovet, og systemerne er ikke afhængige af hinanden.
Ulemper: Konfigurationen er krævende og kræver en infrastruktur, som ikke alle IT-afdelinger har. For mindre virksomheder er det som regel overdrevet.
Metode 3: Brug det eksisterende integrationslag
De har allerede et integrationslag (Mulesoft, Boomi, Informatica, Azure Data Factory) mellem ERP og eksterne systemer. Dette lag udgør aftalen: DPP-udbyderen kommunikerer med det, aldrig direkte med ERP-systemet.
Fordele: Eksisterende investeringer kan udnyttes, reglerne forbliver stabile, ingen direkte ERP-adgang for tredjeparter.
Ulemper: Jeres omkostninger til integrationslaget stiger tilsvarende.
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 grænseflade modtager et neutralt dataformat (et JSON-skema), som De udfylder med et værktøj efter eget valg. Det betyder:
- De kan selv stå for databehandlingen med de værktøjer, som Deres team kender
- De kan skifte udbyder - det neutrale format er portabelt
- De kan til enhver tid hente hele Deres databeholdning ud igen - som CSV, XLSX, JSON-LD og SQL samt via REST-API’en
- Vi leverer en importvalidator, der kontrollerer Deres data inden upload
Det fulde format og alle forespørgsler er offentligt dokumenteret under /apidocs som en grænsefladebeskrivelse i henhold til OpenAPI. Jeres IT-afdeling kan gennemgå 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 bliver hvilket DPP-felt?
- Dag 3 til 5: Første JSON-eksport fra ERP-systemet gennem vores valideringsværktøj.
- 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 mapping-workshoppen - det er her, datakvaliteten afgøres.
Hvad der går 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 det primære for hvert 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 adgang via en grænseflade (OEKO-TEX er foran, GOTS halter bagefter). Eller: Indtast dem manuelt, men med gyldighedsdato, så der ikke dukker udløbne certifikater op i DPP.
Hemmeligholdelse af sammensætning: især inden for kosmetik, fødevarer og lægemidler: den fuldstændige sammensætning er en forretningshemmelighed. Skal DPP offentliggøre den? Løsning: ESPR’s tre-niveau-model. Produktkategorien er offentlig, mens myndighederne har adgang til den fulde opskrift. Dette udgør næsten aldrig en hindring, men skal afklares tidligt.
CO2-data på leverandørbasis: Jeres leverandør angiver en gennemsnitsværdi for hele sin portefølje, ikke pr. batch. Løsning: Accepter det midlertidigt, og tilpas leverandøraftalerne på lang sigt. ESPR kræver produktspecifikke værdier fra en bestemt dato, men den nuværende praksis er et kompromis.
Lokale sprogversioner: Deres ERP-system indeholder kun produktbetegnelsen på tysk og engelsk. Til 27 EU-lande har De brug for mere. Løsning: Maskinoversættelse med terminologidatabase - vi har en separat artikel om dette.
De spørgsmål, De bør stille 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 et integrationslag, der bør udnyttes?
- Findes der allerede en fungerende grænseflade via jeres ERP?
Svarene afgør, hvilken af de tre veje der passer bedst til jer. Og de bestemmer, om et projekt varer to uger eller seks måneder.
Spørgsmål til dette indlæg
Er REST-grænsefladen tilstrækkelig, eller har vi brug for middleware?
Grænsefladen er tilstrækkelig. De tre modeller adskiller sig i, hvor transformationen finder sted, ikke i, hvad vi modtager - vores grænseflade accepterer et neutralt JSON-skema, uanset hvad du har brugt til at generere det. Et pull fra et moderne ERP-system, en begivenhedsstrøm og et eksisterende integrationslag ender alle på det samme slutpunkt. Middleware er en god investering, hvis du alligevel allerede bruger det, og hvis det skal forblive en del af aftalen med tredjeparter. Hvis der ikke findes noget i dag, skal du ikke anskaffe noget til produktpasset.
Hvad bliver der besluttet på kortlægningsworkshoppen?
Hvilket ERP-felt der bliver hvilket passfelt - og hvilket system der er den primære kilde, hvis flere systemer indeholder den samme værdi. Workshoppen finder sted på dag 1 og 2 og er projektets afgørende punkt, fordi det er her, der træffes beslutninger om datakvalitet, og ikke senere i koden. Sørg for at medbringe de personer, der vedligeholder systemerne, ikke kun dem, der har ansvaret for projektet - stamdata, produktion, kvalitet og indkøb hører sjældent til samme afdeling. Alt det, der kommer bagefter, altså eksport, validering og fejlretning, er håndværk.
Vores certifikater findes kun som PDF-scanninger. Hvad skal vi gøre med dem?
En scanning er ikke en struktureret datakilde og kan derfor ikke bruges til passet. Der er to muligheder: Certifikatudbydere tilbyder i stigende grad API-forespørgsler, og hvor sådanne ikke findes, skal du indtaste værdierne manuelt, men altid med gyldighedsdato, så der ikke forbliver et udløbet certifikat i et offentliggjort pass. Planlæg den manuelle fremgangsmåde som en tilbagevendende opgave, ikke som en engangsopgave.
Kan vores IT-afdeling tjekke grænsefladen, før vi underskriver noget?
Ja. Det fulde skema og alle endepunkter findes som en OpenAPI-specifikation under /apidocs, sammen med eksempelforespørgsler, fejlmeddelelser og oplysninger om autentificering. Intet af dette er forbeholdt et salgsmøde, så dit integrationsteam kan vurdere omfanget af arbejdet, inden der er indgået en kontrakt. Hvis en udbyder ikke viser sin grænseflade i denne fase, er det også et svar i sig selv.
Hvad sker der med vores data, når vi skifter udbyder?
De følger med. Grænsefladen accepterer et neutralt JSON-skema i stedet for et proprietært format, og hele jeres database kommer ud som CSV, XLSX, JSON-LD og SQL eller via REST-API’en. Det er helt bevidst - det format, du indlæser data i, er portabelt, så et skift kræver blot en eksport og ikke en ny opbygning. Stil det samme spørgsmål til hver udbyder inden mapping-workshoppen, for bagefter vil dine feltnavne indgå i deres model.
Hvor lang tid tager en tilslutning egentlig?
I de projekter, vi følger, tager det to uger - to dage til kortlægning, tre dage indtil de første eksportfiler fra vores validator, tre dage til fejlretning og to dage indtil de første pas bliver offentliggjort. Den lange vej ligger aldrig i selve koden, men i det, som validatoren finder - manglende felter, inkonsekvent kodning, værdier, som ingen føler sig ansvarlig for. Sæt tid af til disse dage i stedet for at forkorte dem. Et projekt, der springer dem over, offentliggør også manglerne.
Skal vi tilknytte alle produkter på én gang?
Nej. Begynd med de produkter, der først skal have et pass, og med et kildesystem - det neutrale skema accepterer både et delkatalog og et komplet katalog, og importene kan gentages, så senere kørsler opdaterer lagerbeholdningen. Det holder også kortlægningsworkshoppen kort nok til, at den kan gennemføres på to dage. Den efterfølgende udvidelse er en kortlægningsopgave, ikke et nyt projekt.
