A termék súlya az anyaggazdálkodási rendszerben szerepel. Az újrahasznosított anyagok aránya az összetétel-nyilvántartási rendszerben található. A beszállító tanúsítványa PDF-formátumban egy hálózati meghajtón található. A terméknyilvántartáshoz mindhárom adatnak egyetlen adatrekordban kell szerepelnie, és pontosan ebben rejlik az integrációs projekt lényege, nem pedig a két rendszer összekapcsolásában.
A „zökkenőmentes ERP-integráció” egy szokásos ígéret, amelyet a gyakorlatban egy háromhónapos projekt követ. Útmutatónkat azért tesszük közzé, hogy az Ön IT-részlege a szerződés aláírása előtt ellenőrizhesse, hogy valójában milyen adatokra van szükség. Ez a cikk bemutatja, hogy a termékigazolványnak milyen adatokra van szüksége az Önök rendszereiből, milyen három módon jutnak el hozzánk ezek az adatok, és miért lehetséges mindez két hét alatt.
Mit kell valójában szolgáltatnia az Önök ERP-rendszerének
Ahhoz, hogy elkészülhessen a termékigazolvány, termékenként a következőkre van szükségünk:
- Alapadatok - cikkszám, megnevezés, változatok, súlyok, méretek, képek
- alkatrészlista-adatok - alkatrészek mennyiséggel és újrahasznosított anyagok arányával
- származási adatok - gyártási hely, tételszám, gyártási dátum
- környezeti adatok - CO2-egyenérték egységenként, vízfogyasztás, energiafogyasztás
- beszállítói adatok - ki szállítja melyik alkatrészt (a gondossági kötelezettségek teljesítése érdekében)
Elméletileg ezek az adatok mind megtalálhatók az Ön ERP-rendszerében. A gyakorlatban azonban 4-7 modul között vannak elosztva: anyaggazdálkodás, gyártás, minőségbiztosítás, beszállítói adatbázis, néha egy külön modul a környezeti adatokhoz, néha pedig egy saját rendszer a receptúrákhoz és az alkatrészlistákhoz.
Az integrációval kapcsolatos kérdés nem az, hogy „Az Ön ERP-rendszere szolgáltat-e adatokat egy DPP-nek?”, hanem az, hogy „Hogyan egyesíti az 5 alrendszerből származó adatokat egy összefüggő adatkészletbe?”
Három bevált módszer
1. módszer: Az adatok lekérése az ERP-ből
Ez jól működik a modern ERP-rendszerekkel (SAP S/4HANA Cloud, Dynamics 365, Odoo). A DPP-szolgáltató az ERP interfészén keresztül tölti le az adatokat (technikailag OData vagy REST). Csak a változásokat, ütemezés szerint vagy egy esemény által kiváltva.
Előnyök: kevés fejlesztési munkát igényel az Ön részéről; Ön biztosítja az olvasási hozzáférést, a szolgáltató pedig megvalósítja az átalakítást.
Hátrányok: nem működik régebbi SAP ECC-telepítésekkel további interfészréteg nélkül. Egyértelmű szabályokra van szükség arra vonatkozóan, hogy ki mely adatokat olvashatja.
2. módszer: A változások továbbítása
Az Ön ERP-je minden változást eseményként jelenti (SAP Event Mesh, Apache Kafka vagy RabbitMQ segítségével), a DPP-szolgáltató pedig fogadja azokat.
Előnyök: szinte valós időben történik, a rendszer a növekedéssel együtt bővül, a rendszerek nem függenek egymástól.
Hátrányok: A beállítás igényes, és olyan infrastruktúrát igényel, amellyel nem minden IT-részleg rendelkezik. Kisebb cégek számára általában túlzott.
3. módszer: A meglévő integrációs réteg használata
Már rendelkezik ### integrációsréteggel (Mulesoft, Boomi, Informatica, Azure Data Factory) az ERP és a külső rendszerek között. Ez a réteg jelenti a közvetítőt: a DPP-szolgáltató vele kommunikál, soha nem közvetlenül az ERP-vel.
Előnyök: a meglévő beruházások felhasználhatók, a szabályok stabilak maradnak, harmadik felek nem férhetnek hozzá közvetlenül az ERP-hez.
Hátrányok: az integrációs réteg költségei is növekednek.
Mit csinálunk másképp a konkrét projektekben
Sok szolgáltató közvetlenül szeretne csatlakozni az Ön ERP-jéhez. Mi alapvetően beépítünk egy köztes lépést: interfészünk egy semleges adatformátumot (egy JSON-sémát) fogad, amelyet Ön egy Ön által választott eszközzel tölthet meg. Ez azt jelenti, hogy:
- Az adatfeldolgozást saját maga végezheti el, a csapata által ismert eszközökkel
- Kicserélhet minket - a semleges formátum hordozható
- Bármikor visszaszerezheti teljes adatállományát - CSV, XLSX, JSON-LD és SQL formátumban, valamint a REST-API-n keresztül
- Biztosítunk egy import-érvényesítőt, amely feltöltés előtt ellenőrzi az adatait
A teljes formátum és az összes lekérdezés nyilvánosan elérhető a API-dokumentáció oldalon, OpenAPI szerinti interfészleírásként. Az Ön IT-részlege a szerződés aláírása előtt ellenőrizheti az interfészt - beleértve a példakérdéseket, a hibaüzeneteket és a hitelesítési részleteket is.
A gyakorlatban ez a megközelítés a következő időkeretet jelenti:
- 1-2. nap: Mapping-workshop. Melyik ERP-mező melyik DPP-mezőnek felel meg?
- 3-5. nap: Első JSON-exportok az ERP-ből, a validátorunkon keresztül.
- 6-8. nap: Hibaelhárítás (hiányzó mezők, inkonzisztens kódolások).
- 9-10. nap: Az első DPP-k élesben működnek.
Két hét, nem három hónap. A kulcs a leképezési workshop - ott dől el az adatminőség.
Mi sülhet el rosszul: a leggyakoribb buktatók
Termékalapadatok több rendszerben: az SAP-ban van a cikkszám, a PIM-ben a képek és a marketing szövegek, a PLM-ben pedig a darabjegyzék. Senkinek sincs egységes képe a dolgokról. Megoldás: a projekt megkezdése előtt határozzák meg, melyik rendszer melyik mező tekintetében a vezető.
Tanúsítványok PDF-formátumban: a beszállítók a GOTS-, OEKO-TEX- vagy REACH-tanúsítványokat PDF-beolvasásként szállítják. Ez nem strukturált adatforrás. Megoldás: A tanúsító szervezetek egyre gyakrabban kínálnak lekérdezést interfészen keresztül (az OEKO-TEX élen jár, a GOTS lemarad). Vagy: manuálisan rögzíteni, de érvényességi dátummal, hogy ne jelenjenek meg lejárt tanúsítványok a DPP-ben.
Összetétel titkossága: különösen a kozmetikai, élelmiszer- és gyógyszeriparban: a teljes összetétel üzleti titok. A DPP-nek nyilvánosságra kell hoznia azokat? Megoldás: az ESPR háromszintű modellje. A termékkategória nyilvános, a hatóságok láthatják a teljes összetételt. Szinte soha nem jelent akadályt, de ezt korán tisztázni kell.
CO2-adatok beszállítói alapon: a beszállítója átlagértéket ad meg teljes portfóliójára vonatkozóan, nem pedig tételenként. Megoldás: ideiglenesen elfogadni, hosszú távon pedig módosítani a beszállítói szerződéseket. Az ESPR egy meghatározott időponttól kezdve termékspecifikus értékeket követel, de a jelenlegi gyakorlat egy kompromisszum.
Helyi nyelvi változatok: Az Ön ERP-rendszere csak a terméknevet tartalmazza német és angol nyelven. 27 EU-ország esetében ennél többre van szükség. Megoldás: gépi fordítás terminológiai adatbázissal; erről külön cikkünk is van.
A kérdések, amelyeket a projekt megkezdése előtt fel kell tennie
Mielőtt ajánlatkérést küldene három szolgáltatónak, válaszoljon meg belsőleg a következő kérdéseket:
- Hány terméknek/cikkszámnak kell DPP-vel rendelkeznie? (10, 10 000, 1 millió?)
- Mely rendszerek tárolnak jelenleg DPP-re vonatkozó adatokat?
- Melyik osztály kezeli az egyes rendszereket?
- Van-e olyan integrációs réteg, amelyet érdemes lenne használni?
- Van-e már működő interfész az ERP-rendszerén keresztül?
A válaszok alapján dől el, hogy a három lehetőség közül melyik a legmegfelelőbb az Ön számára.
A válaszok határozzák meg, hogy a projekt két hétig vagy hat hónapig tart-e.
Kérdések ehhez a bejegyzéshez
Elég a REST-interfész, vagy szükségünk van egy köztes szoftverre?
Az interfész elegendő. A három minta abban különbözik egymástól, hogy hol történik az átalakítás, nem pedig abban, hogy mit fogadunk be - az interfészünk semleges JSON-sémát fogad el, függetlenül attól, hogy mivel hozták létre. Egy modern ERP-rendszerből származó pull-művelet, egy eseményáram és egy meglévő integrációs réteg mind ugyanazon a végponton végződik. A middleware akkor érdemes, ha amúgy is üzemeltet ilyet, és azt szeretné, hogy az maradjon a harmadik felekkel kötött szerződés tárgya. Ha jelenleg nincs ilyen, ne vásároljon egyet a termékútlevélhez.
Mit határoznak meg a térképészeti műhelymunkán?
Melyik ERP-mező melyik passzmezővé válik - és melyik rendszer a vezető forrás, ha több rendszer is ugyanazt az értéket tárolja. A workshop az 1. és 2. napon kerül megrendezésre, és ez az egész projekt kulcsfontosságú pontja, mert ott dől el az adatminőség kérdése, nem pedig később a kódban. Hozzák magukkal azokat is, akik a rendszereket karbantartják, ne csak azokat, akik a projektért felelősek - az alapadatok, a gyártás, a minőségbiztosítás és a beszerzés ritkán egy osztályon belül működnek. Minden, ami ezután következik, azaz az exportálás, az érvényesítés és a hibajavítás, már csak kivitelezés kérdése.
A tanúsítványaink csak PDF-formátumban, beolvasott változatban állnak rendelkezésre. Mit tegyünk velük?
A szkennelt dokumentum nem minősül strukturált adatforrásnak, ezért a Pass rendszerben használhatatlan. Két módszer működik: a tanúsítvány-kibocsátók egyre gyakrabban kínálnak API-lekérdezéseket, és ahol ezek nincsenek, ott az értékeket kézzel kell rögzíteni, de mindig az érvényességi dátummal együtt, hogy ne maradjon lejárt tanúsítvány a közzétett Pass-profilban. A kézi adatbevitelét ismétlődő feladatként tervezze be, ne egyszeri munkaként.
Megvizsgálhatja-e az informatikai részlegünk az interfészt, mielőtt aláírnánk valamit?
Igen. A teljes sémakép és az összes végpont OpenAPI-specifikációként elérhető a API-dokumentáció oldalon, példakérésekkel, hibaüzenetekkel és hitelesítési részletekkel együtt. Mindez nem titkosított, így integrációs csapatuk már a szerződés megkötése előtt fel tudja mérni a munkával járó ráfordítást. Ha egy szolgáltató ebben a fázisban nem teszi közzé az interfészét, az is egyfajta válasz.
Mi történik az adatainkkal, ha szolgáltatót váltunk?
Ezeket is átveszi. Az interfész egy semleges JSON-sémát fogad el a saját fejlesztésű formátum helyett, és az egész adatállomány CSV, XLSX, JSON-LD és SQL formátumban, illetve a REST-API-n keresztül kerül ki. Ez szándékos - a feltöltött formátum hordozható, így a váltáshoz csupán egy exportálásra van szükség, nem pedig új adatbázis létrehozására. Tegye fel ugyanazt a kérdést minden szolgáltatónak a leképezési workshop előtt, mert utána a mezőnevei megjelennek a szolgáltató modelljében.
Mennyi ideig tart valójában egy csatlakozás?
Az általunk kísért projektekben: két hét - két nap térképezés, három nap az első exportokig a validátorunk segítségével, három nap hibajavítás, két nap az első közzétett útlevelekig. A hosszú út soha nem a kódban rejlik, hanem abban, amit a validátor talál: hiányzó mezők, egységtelen kódolások, olyan értékek, amelyekért senki sem érzi magát felelősnek. Tervezze be ezeket a napokat, ahelyett, hogy lerövidítené őket. Egy projekt, amely kihagyja őket, a hiányosságokat is közzéteszi.
Minden terméket egyszerre kell hozzáadnunk?
Nem. Kezdje azokkal a termékekkel, amelyekhez először engedélyre van szükség, és egy forrásrendszerrel - a semleges sémája ugyanúgy fogadja a részkatalógust, mint a teljeset, és az importálások megismételhetők, így a későbbi futtatások frissítik a készletet. Így a leképezési workshop is elég rövid marad ahhoz, hogy két nap alatt el lehessen végezni. Az ezt követő kiterjesztés egy leképezési feladat, nem pedig új projekt.
