Produktens vikt finns i materialhanteringssystemet. Andelen återvunnet material finns i receptsystemet. Leverantörens certifikat finns som PDF-fil på en nätverksenhet. Produktpasset behöver alla tre uppgifterna i en enda datapost, och det är just detta som integrationsprojektet handlar om - inte om att koppla samman två system.
”Sömlös ERP-integration” är ett standardlöfte som i praktiken följs av ett tre månader långt projekt. Vi publicerar vår guide så att er IT-avdelning kan kontrollera vad som faktiskt efterfrågas innan avtalet undertecknas. Den här artikeln visar vilka data produktpasset behöver från era system, på vilka tre sätt de skickas till oss och varför det går att genomföra på två veckor.
Vad ert ERP-system faktiskt måste leverera
För att ett produktpass ska kunna skapas behöver vi per produkt:
- Stamdata - artikelnummer, benämning, varianter, vikter, mått, bilder
- Stycklistdata - 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-kraven)
Teoretiskt sett finns alla dessa uppgifter i ert ERP-system. I praktiken är de fördelade på 4 till 7 moduler: materialhantering, produktion, kvalitet, leverantörsregister, ibland en separat modul för miljöuppgifter, ibland ett eget system för recept och stycklistor.
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 metoder
Metod 1: Hämta data från ERP-systemet
Fungerar bra med moderna ERP-system (SAP S/4HANA Cloud, Dynamics 365, Odoo). DPP-leverantören hämtar data via ERP-systemets gränssnitt (tekniskt sett OData eller REST). Endast ändringarna, enligt tidsplan eller utlöst av en händelse.
Fördelar: liten utvecklingsinsats från er sida, ni tillhandahåller läsbehörighet och leverantören bygger konverteringen.
Nackdelar: fungerar inte med äldre SAP ECC-installationer utan ett extra gränssnittslager. Ni behöver tydliga regler för vem som får läsa vilka data.
Metod 2: Vidarebefordra ändringar
Ert ERP-system rapporterar varje ändring som en händelse (via SAP Event Mesh, Apache Kafka eller RabbitMQ), och DPP-leverantören tar emot den.
Fördelar: nästan i realtid, skalar med behovet, systemen är inte beroende av varandra.
Nackdelar: Konfigurationen är krävande och kräver infrastruktur som inte alla IT-avdelningar har. Oftast överdrivet för mindre företag.
Metod 3: Använda det befintliga integrationslagret
Ni har redan ett integrationslager (Mulesoft, Boomi, Informatica, Azure Data Factory) mellan ERP-systemet och externa system. Detta lager fungerar som en mellanhand: DPP-leverantören kommunicerar med det, aldrig direkt med ERP-systemet.
Fördelar: Befintliga investeringar kan utnyttjas, reglerna förblir stabila, ingen direkt åtkomst till ERP-systemet för tredje part.
Nackdelar: Era kostnader för integrationslagret ökar i takt med detta.
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år gränssnitt tar emot ett neutralt dataformat (ett JSON-schema) som ni fyller med hjälp av ett verktyg efter eget val. Det innebär:
- Ni kan själva utföra databehandlingen med de verktyg som ert team är vana vid
- Ni kan byta ut oss - 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
- Vi tillhandahåller en importvaliderare som kontrollerar era data före uppladdningen
Det fullständiga formatet och alla förfrågningar är offentligt dokumenterade på /apidocs, som en gränssnittsbeskrivning enligt OpenAPI. Er IT-avdelning kan granska 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 det ledande för vilket fält.
Certifikat som PDF: Leverantörer levererar GOTS-, OEKO-TEX- eller REACH-certifikat som PDF-skanningar. Det är ingen strukturerad datakälla. Lösning: Certifieringsorgan erbjuder i allt högre grad möjligheten att hämta information via ett gränssnitt (OEKO-TEX ligger i framkant, GOTS halkar efter). Alternativt: registrera manuellt, men ange giltighetsdatum så att inga utgångna certifikat dyker upp i DPP.
Hemlighet kring recept: särskilt inom kosmetika, livsmedel och läkemedel: den fullständiga recepturen ä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 mer. Lösning: Maskinöversättning med terminologidatabas - vi har en separat artikel om detta.
Frågorna ni bör ställa er innan projektet inleds
Innan du skickar en 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 ett integrationslager som bör användas?
- Finns det redan ett fungerande gränssnitt via ert ERP-system?
Svaren avgör vilken av de tre vägarna som passar er bäst. Och de avgör om ett projekt tar två veckor eller sex månader.
Frågor om detta inlägg
Räcker det med REST-gränssnittet, eller behöver vi en mellanprogramvara?
Gränssnittet räcker. De tre modellerna skiljer sig åt i fråga om var omvandlingen sker, inte i fråga om vad vi tar emot - vårt gränssnitt accepterar ett neutralt JSON-schema, oavsett hur du har skapat det. En hämtning från ett modernt ERP-system, en händelseström och ett befintligt integrationslager hamnar alla vid samma slutpunkt. Middleware är värt att använda om du ändå har en sådan i drift och den ska fungera som avtal gentemot tredje part. Om det inte finns någon idag, skaffa inte någon för produktpasset.
Vad beslutas under kartläggningsworkshopen?
Vilket ERP-fält som motsvarar vilket passfält - och vilket system som är den ledande källan när flera system har samma värde. Workshopen äger rum under dag 1 och 2 och är hela projektets avgörande punkt, eftersom beslut om datakvalitet fattas där och inte senare i koden. Ta med de personer som sköter systemen, inte bara de som ansvarar för projektet - stamdata, produktion, kvalitet och inköp finns sällan inom en och samma avdelning. Allt därefter, det vill säga export, validering och felsökning, är hantverk.
Våra certifikat finns endast i form av inskannade PDF-filer. Vad ska vi göra med dem?
En skanning är ingen strukturerad datakälla och är därför oanvändbar för passet. Det finns två sätt att gå tillväga - certifikatutfärdare erbjuder i allt högre grad API-förfrågningar, och där sådana saknas matar ni in värdena manuellt, men alltid med giltighetsdatum, så att inget utgånget certifikat kvarstår i ett publicerat pass. Planera in den manuella metoden som en återkommande uppgift, inte som en engångsuppgift.
Kan vår IT-avdelning granska gränssnittet innan vi undertecknar något?
Ja. Det fullständiga schemat och alla slutpunkter finns som OpenAPI-specifikation under /apidocs, tillsammans med exempelförfrågningar, felmeddelanden och autentiseringsuppgifter. Inget av detta kräver något säljsamtal, så ert integrationsteam kan uppskatta arbetsinsatsen redan innan ett avtal har ingåtts. Om en leverantör inte visar sitt gränssnitt i detta skede är även det ett svar.
Vad händer med våra uppgifter när vi byter leverantör?
De följer med. Gränssnittet tar emot ett neutralt JSON-schema istället för ett proprietärt format, och hela ert datautbud exporteras som CSV, XLSX, JSON-LD och SQL eller via REST-API:et. Det är avsiktligt - det format du matar in är portabelt, så ett byte kräver bara en export och inte något helt nytt uppbyggande. Ställ samma fråga till varje leverantör före mappningsworkshopen, för efteråt kommer dina fältnamn att finnas i deras modell.
Hur lång tid tar en anslutning egentligen?
I de projekt vi arbetar med tar det två veckor - två dagar för kartläggning, tre dagar fram till de första exporterna via vår validerare, tre dagar för felsökning och två dagar fram till de första publicerade passerna. Den långa vägen handlar aldrig om koden, utan om vad valideraren upptäcker - saknade fält, inkonsekvent kodning, värden som ingen tar ansvar för. Planera in dessa dagar istället för att korta ner dem. Ett projekt som hoppar över dem publicerar luckorna tillsammans med resultatet.
Måste vi ansluta alla produkter på en gång?
Nej. Börja med de produkter som först och främst behöver ett pass och med ett källsystem - det neutrala schemat hanterar både en delkatalog och en fullständig katalog på samma sätt, och importen går att upprepa, vilket innebär att senare körningar uppdaterar beståndet. Detta gör också att mappningsworkshopen blir tillräckligt kort för att kunna genomföras på två dagar. Den efterföljande utvidgningen är en mappningsuppgift, inte ett nytt projekt.
