A „zökkenőmentes ERP-integráció” egy szokásos ígéret, amelyet a gyakorlatban egy három hónapos projekt követ. Közzétesszük az API-útmutatónkat, hogy az Ön IT-részlege a szerződés aláírása előtt ellenőrizhesse, hogy valójában milyen adatlekérdezésekre kerül sor. Íme, amit egy integrációs projekt előtt tudnia kell.
Mit kell valójában biztosítania az ERP-rendszerének
Ahhoz, hogy létrejöhessen egy DPP, termékenként a következőkre van szükségünk:
- Törzsadatok - cikkszám, megnevezés, változatok, súlyok, méretek, képek
- Alkatrészlista-adatok - alkatrészek mennyiségekkel é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 due diligence céljából)
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 (MM), gyártás (PP), minőségbiztosítás (QM), beszállítók (LFA1), néha egy külön EHS-modul a környezeti adatokhoz, néha egy PLM-rendszer a receptúrá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észletté?”
Három bevált integrációs### minta
- minta: OData / REST-Pull
Jól működik a modern ERP-rendszerekkel (SAP S/4HANA Cloud, Dynamics 365, Odoo). A DPP-szolgáltató OData vagy REST segítségével tölti le az adatokat. Inkrementálisan, tervezett módon vagy eseményvezérelt módon.
Előnyök: kevés fejlesztési munka az Ön részéről, Ön biztosítja az olvasási jogosultságokat, 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 API-réteg nélkül. Szükség van az adathozzáférési kérelmek feletti irányításra.
2. minta: Eseményalapú integráció
SAP Event Mesh, Apache Kafka, RabbitMQ. Az Ön ERP-rendszere közzéteszi a változási eseményeket, a DPP-szolgáltató pedig feldolgozza azokat.
Előnyök: szinte valós időben történik, elegánsan skálázható, szétválasztott.
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. modell: Middleware / ETL
Van egy integrációs rétegük (Mulesoft, Boomi, Informatica, Azure Data Factory) az ERP és a külső rendszerek között. A middleware jelenti a kapcsolódási pontot - a DPP-szolgáltató a middleware-rel kommunikál, soha nem közvetlenül az ERP-vel.
Előnyök: a meglévő beruházások kihasználhatók, a kormányzás stabil, harmadik felek számára nincs közvetlen hozzáférés az ERP-hez.
Hátrányok: a middleware-költségek a rendszer méretével arányosan nőnek.
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: API-nk elfogad egy semleges JSON-sémát, amelyet Ön egy ön által választott eszközzel tölthet meg. Ez azt jelenti, hogy:
- Önök maguk végezhetik el az adatok előkészítését, a csapatuk által jól ismert eszközökkel
- Lehetőségük van szolgáltatót váltani - a semleges formátum hordozható
- Bármikor visszaszerezhetik a teljes adatállományukat - CSV, XLSX, JSON-LD és SQL formátumban, valamint a REST-API-n keresztül
- Biztosítunk egy import-érvényesítőt, amely a feltöltés előtt ellenőrzi az adatait
A teljes sémát és az összes végpontot a /apidocs oldalon OpenAPI-specifikációként nyilvánosan dokumentáljuk. Az Ön IT-részlege a szerződés aláírása előtt ellenőrizheti az interfészt - beleértve a példakéré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 igényli:
- 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 már élnek.
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. Senki sem rendelkezik konzisztens képpel. Megoldás: a projekt megkezdése előtt határozzák meg, melyik rendszer melyik mező esetében a „Source of Truth” (megbízható forrás).
Tanúsítványok PDF-formátumban: a beszállítók a GOTS-, OEKO-TEX- vagy REACH-tanúsítványokat PDF-szkennelésként szállítják. Ez nem strukturált adatforrás. Megoldás: a tanúsító szervezetek egyre gyakrabban kínálnak API-lekérdezéseket (az OEKO-TEX élen jár, a GOTS lemarad). Vagy: manuálisan rögzítsük az adatokat, de érvényességi dátummal, hogy ne kerüljenek lejárt tanúsítványok a DPP-be.
Ö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 a teljes portfóliójára vonatkozóan, nem tételenként. Megoldás: ideiglenesen elfogadni, hosszú távon 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ül és angolul. 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 projekt megkezdése előtt felteendő kérdések
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 middleware-beruházásuk, amelyet érdemes lenne kihasználni?
- Van-e már működő API-réteg az ERP-jük felett?
A válaszok alapján dől el, hogy a három modell közül melyik felel meg Önöknek. És ezek határozzák meg, hogy a projekt két hétig vagy hat hónapig tart-e.