”Sömlös ERP-integration” är ett standardlöfte som i praktiken följs av ett tre månaders projekt. Vi publicerar vårt API-handbok så att er IT-avdelning kan kontrollera vad som faktiskt begärs ut innan avtalet undertecknas. Här är vad ni bör veta inför ett integrationsprojekt.
Vad ditt ERP-system faktiskt måste leverera
För att ett DPP ska kunna skapas behöver vi följande per produkt:
- Stamdata - artikelnummer, benämning, varianter, vikter, mått, bilder
- Bomullslistdata - komponenter med mängder och andel återvunnet material
- Ursprungsdata - produktionsort, batchnummer, produktionsdatum
- Miljödata - CO2eq per enhet, vattenförbrukning, energiförbrukning
- Leverantörsdata - vem levererar vilken komponent (för due diligence)
Teoretiskt sett finns alla dessa data i ert ERP-system. I praktiken är de fördelade på 4 till 7 moduler: Materialhantering (MM), Produktion (PP), Kvalitet (QM), Leverantör (LFA1), ibland en separat EHS-modul för miljödata, ibland ett PLM-system för recept.
Integrationsfrågan är inte: ”Levererar ert ERP-system data till en DPP?” Den är: ”Hur sammanför ni data från fem delsystem till en sammanhängande datamängd?”
Tre beprövade integrationsmönster
Mönster 1: OData / REST-Pull
Fungerar bra med moderna ERP-system (SAP S/4HANA Cloud, Dynamics 365, Odoo). DPP-leverantören hämtar data via OData eller REST. Inkrementellt, planerat eller händelsestyrt.
Fördelar: liten utvecklingsinsats från er sida, ni tillhandahåller läsbehörigheter, leverantören bygger omvandlingen.
Nackdelar: fungerar inte med äldre SAP ECC-installationer utan ett extra API-lager. Ni behöver styrning av dataåtkomstförfrågningar.
Mönster 2: Händelsebaserad integration
SAP Event Mesh, Apache Kafka, RabbitMQ. Ert ERP-system publicerar ändringshändelser, DPP-leverantören konsumerar dem.
Fördelar: nästan i realtid, elegant skalbar, avkopplad.
Nackdelar: Konfigurationen är krävande och kräver infrastruktur som inte alla IT-avdelningar har. Oftast överdrivet för mindre företag.
Modell 3: Middleware / ETL
Ni har ett integrationslager (Mulesoft, Boomi, Informatica, Azure Data Factory) mellan ERP-systemet och externa system. Middleware fungerar som en mellanhand - DPP-leverantören kommunicerar med middleware, aldrig direkt med ERP-systemet.
Fördelar: befintliga investeringar kan utnyttjas, stabil styrning, ingen direkt åtkomst till ERP-systemet för tredje part.
Nackdelar: Era kostnader för mellanprogramvaran ökar i takt med verksamheten.
Vad vi gör annorlunda i konkreta projekt
Många leverantörer vill ansluta sig direkt till ert ERP-system. Vi bygger alltid in ett mellanled: vårt API accepterar ett neutralt JSON-schema som ni fyller i med ett verktyg efter eget val. Det innebär att:
- Ni kan själva utföra databehandlingen med de verktyg som ert team är vana vid
- Ni kan byta leverantör - det neutrala formatet är portabelt
- Ni kan när som helst hämta ut hela ert dataarkiv - som CSV, XLSX, JSON-LD och SQL samt via REST-API:et
- Vi tillhandahåller en importvaliderare som kontrollerar dina data innan de laddas upp
Det fullständiga schemat och alla slutpunkter är offentligt dokumenterade som en OpenAPI-specifikation under /apidocs. Er IT-avdelning kan testa gränssnittet innan ett avtal undertecknas - inklusive exempelförfrågningar, felmeddelanden och autentiseringsuppgifter.
Tidsram för denna metod i praktiken:
- Dag 1 till 2: Mappningsworkshop. Vilket ERP-fält motsvarar vilket DPP-fält?
- Dag 3 till 5: Första JSON-exporterna från ERP-systemet, genom vår validerare.
- Dag 6 till 8: Felsökning (saknade fält, inkonsekvent kodning).
- Dag 9 till 10: De första DPP:erna är live.
Två veckor, inte tre månader. Nyckeln är mappningsworkshopen - där avgörs datakvaliteten.
Vad som kan gå fel: de vanligaste fallgroparna
Produktstamdata i flera system: SAP har artikelnumret, PIM har bilderna och marknadsföringstexterna, PLM har stycklistan. Ingen har en enhetlig bild. Lösning: definiera före projektstart vilket system som är ”Source of Truth” för vilket fält.
Certifikat som PDF: Leverantörer levererar GOTS-, OEKO-TEX- eller REACH-certifikat som skannade PDF-filer. Det är ingen strukturerad datakälla. Lösning: Certifieringsorgan erbjuder i allt högre grad API-förfrågningar (OEKO-TEX ligger i framkant, GOTS släpar efter). Eller: registrera manuellt, men med giltighetsdatum, så att inga utgångna certifikat dyker upp i DPP.
Sekretess kring recept: särskilt inom kosmetika, livsmedel och läkemedel: det fullständiga receptet är en företagshemlighet. Ska DPP offentliggöra den? Lösning: ESPR:s tre-nivåmodell. Produktkategorin är offentlig, myndigheterna ser den fullständiga recepturen. Det är nästan aldrig ett hinder, men måste klargöras i ett tidigt skede.
CO2-data baserade på leverantörer: Er leverantör anger ett genomsnittsvärde för hela sitt sortiment, inte per sats. Lösning: Acceptera detta tillfälligt, men anpassa leverantörsavtalen på lång sikt. ESPR kräver produktspecifika värden från och med ett visst datum, men den nuvarande praxisen är en kompromiss.
Lokala språkversioner: Ert ERP-system innehåller endast produktbeteckningen på tyska och engelska. För 27 EU-länder behöver ni fler. Lösning: Maskinöversättning med terminologidatabas - vi har en separat artikel om detta.
Frågorna ni bör ställa er innan projektet
Innan du skickar en förfrågan (RFP) till tre leverantörer, besvara följande frågor internt:
- Hur många produkter/artikelnummer ska ha DPP:er? (10, 10 000, 1 miljon?)
- Vilka system innehåller idag DPP-relevanta data?
- Vilken avdelning förvaltar vart och ett av systemen?
- Har ni en middleware-investering som bör utnyttjas?
- Finns det redan ett fungerande API-lager ovanpå ert ERP-system?
Svaren avgör vilken av de tre modellerna som passar er. Och de avgör om ett projekt tar två veckor eller sex månader.