Hmotnosť produktu je uvedená v systéme správy materiálov. Podiel recyklovaného materiálu je uvedený v systéme receptúr. Certifikát dodávateľa je uložený vo formáte PDF na sieťovom disku. Produktový pas potrebuje všetky tri údaje v jednom jedinom zázname, a práve v tom spočíva projekt integrácie, nie v prepojení dvoch systémov.
„Plynulá integrácia ERP“ je štandardný sľub, po ktorom v praxi nasleduje trojmesačný projekt. Zverejňujeme náš návod, aby vaše IT oddelenie mohlo pred podpísaním zmluvy overiť, aké údaje sa skutočne vyžadujú. Tento článok ukazuje, aké údaje z vašich systémov pas potrebuje, akými tromi spôsobmi k nám prichádzajú a prečo to trvá len dva týždne.
Čo musí váš ERP systém skutočne poskytnúť
Aby mohol vzniknúť DPP, potrebujeme pre každý produkt:
- Základné údaje - číslo výrobku, označenie, varianty, hmotnosť, rozmery, obrázky
- údaje o zozname komponentov - komponenty s množstvami a podielmi recyklátu
- údaje o pôvode - miesto výroby, číslo šarže, dátum výroby
- environmentálne údaje - CO2eq na jednotku, spotreba vody, spotreba energie
- údaje o dodávateľoch - kto dodáva ktorú zložku (pre účely povinností náležitej starostlivosti)
V vašom ERP systéme sú tieto údaje teoreticky všetky k dispozícii. V praxi sú však rozložené v 4 až 7 moduloch: hospodárenie s materiálom, výroba, kvalita, databáza dodávateľov, niekedy samostatný modul pre environmentálne údaje, niekedy samostatný systém pre receptúry a kusovníky.
Otázka integrácie neznie: „Poskytuje váš ERP systém údaje do DPP?“ Znie: „Ako zjednotíte údaje z 5 subsystémov do jedného uceleného súboru údajov?“
Tri osvedčené spôsoby
Spôsob 1: Načítanie údajov z ERP
Funguje to dobre s modernými ERP systémami (SAP S/4HANA Cloud, Dynamics 365, Odoo). Poskytovateľ DPP získava údaje prostredníctvom rozhrania ERP (technicky OData alebo REST). Iba zmeny, podľa časového plánu alebo vyvolané udalosťou.
Výhody: minimálny vývoj z vašej strany, vy poskytnete prístup na čítanie, poskytovateľ zabezpečí konverziu.
Nevýhody: nefunguje so staršími inštaláciami SAP ECC bez dodatočnej vrstvy rozhrania. Potrebujete jasné pravidlá, kto smie čítať ktoré údaje.
Spôsob 2: Presmerovanie zmien
Váš ERP nahlási každú zmenu ako udalosť (prostredníctvom SAP Event Mesh, Apache Kafka alebo RabbitMQ), poskytovateľ DPP ju prijme.
Výhody: takmer v reálnom čase, systémy rastú spolu, nie sú na sebe závislé.
Nevýhody: Nastavenie je náročné a vyžaduje infraštruktúru, ktorú nemá každé IT oddelenie. Pre menšie firmy je to väčšinou neprimerané.
Spôsob 3: Využitie existujúcej integračnej vrstvy
Medzi ERP a externými systémami už máte integračnú vrstvu (Mulesoft, Boomi, Informatica, Azure Data Factory). Táto vrstva predstavuje zmluvu: poskytovateľ DPP komunikuje s ňou, nikdy priamo s ERP.
Výhody: existujúce investície sa dajú využiť, pravidlá zostávajú stabilné, tretie strany nemajú priamy prístup k ERP.
Nevýhody: Vaše náklady na integračnú vrstvu rastú spolu s ňou.
Čo robíme inak v konkrétnych projektoch
Mnohí poskytovatelia sa chcú pripojiť priamo k vášmu ERP. My zásadne zavádzame medzistupeň: Naše rozhranie prijíma neutrálny formát údajov (schéma JSON), ktorý naplníte pomocou nástroja podľa vlastného výberu. To znamená:
- Úpravu údajov môžete vykonať sami pomocou nástrojov, s ktorými je váš tím oboznámený
- Môžete nás nahradiť - neutrálny formát je prenosný
- Kedykoľvek si môžete stiahnuť celý svoj dátový fond - vo formátoch CSV, XLSX, JSON-LD a SQL, ako aj prostredníctvom REST-API
- Poskytujeme validátor importu, ktorý skontroluje vaše údaje pred nahratím
Kompletný formát a všetky dotazy sú verejne zdokumentované na /apidocs ako popis rozhrania podľa OpenAPI. Vaše IT oddelenie môže rozhranie otestovať ešte pred podpísaním zmluvy - vrátane ukážkových požiadaviek, odpovedí na chyby a podrobností o autentifikácii.
Časový rámec tohto prístupu v praxi:
- 1. až 2. deň: Workshop mapovania. Ktoré pole v ERP sa priradí ku ktorému poľu v DPP?
- 3. až 5. deň: Prvé exporty JSON z ERP, overené našim validátorom.
- 6. až 8. deň: Odstraňovanie chýb (chýbajúce polia, nekonzistentné kódovanie).
- 9. až 10. deň: Prvé DPP sú spustené.
Dva týždne, nie tri mesiace. Kľúčovým bodom je workshop mapovania - práve tam sa rozhoduje o kvalite údajov.
Čo sa môže pokaziť: najčastejšie úskalia
Základné údaje o produktoch v viacerých systémoch: SAP má číslo článku, PIM má obrázky a marketingové texty, PLM má zoznam komponentov. Nikto nemá ucelený prehľad. Riešenie: pred začatím projektu definujte, ktorý systém je pre ktoré pole hlavný.
Certifikáty vo formáte PDF: Dodávatelia dodávajú certifikáty GOTS, OEKO-TEX alebo REACH ako naskenované PDF súbory. To nie je štruktúrovaný zdroj údajov. Riešenie: Certifikačné organizácie čoraz častejšie ponúkajú vyhľadávanie prostredníctvom rozhrania (OEKO-TEX je v tom napred, GOTS zaostáva). Alebo: ručné zadávanie, avšak s dátumom platnosti, aby sa v DPP neobjavovali certifikáty s uplynutou platnosťou.
Dôvernosť zloženia: najmä v kozmetike, potravinárstve a farmaceutickom priemysle: kompletné zloženie je obchodným tajomstvom. Má ich DPP zverejniť? Riešenie: Trojúrovňový model ESPR. Verejne je dostupná kategória výrobku, orgány majú prístup k úplnému zloženiu. Takmer nikdy to nie je prekážka, ale je potrebné to včas vyjasniť.
Údaje o CO₂ na základe dodávateľov: Váš dodávateľ uvádza priemernú hodnotu za celé svoje portfólio, nie za jednotlivé šarže. Riešenie: Dočasne to akceptovať, z dlhodobého hľadiska prispôsobiť zmluvy s dodávateľmi. ESPR vyžaduje hodnoty špecifické pre jednotlivé výrobky od určitého dátumu, ale súčasná prax je kompromisom.
Miestne jazykové verzie: Váš ERP systém obsahuje len názvy produktov v nemčine a angličtine. Pre 27 krajín EÚ potrebujete viac. Riešenie: strojový preklad s terminologickou databázou; k tomu máme samostatný článok.
Otázky, ktoré by ste si mali položiť pred začatím projektu
Než pošlete žiadosť o ponuku (RFP) trom dodávateľom, odpovedzte si interne na nasledujúce otázky:
- Koľko produktov/čísiel položiek má mať DPP? (10, 10 000, 1 milión?)
- Ktoré systémy dnes uchovávajú údaje relevantné pre DPP?
- Ktoré oddelenie spravuje každý z týchto systémov?
- Máte integračnú vrstvu, ktorú by ste mali využiť?
- Existuje už fungujúce rozhranie cez váš ERP systém?
Odpovede určujú, ktorý z týchto troch spôsobov je pre vás vhodný. A určujú tiež, či projekt potrvá dva týždne alebo šesť mesiacov.
Otázky k tomuto príspevku
Stačí rozhranie REST, alebo potrebujeme middleware?
Rozhranie stačí. Tieto tri vzory sa líšia tým, kde prebieha transformácia, nie tým, čo prijímame - naše rozhranie prijíma neutrálne schéma JSON, bez ohľadu na to, čím ste ho vytvorili. Pull z moderného ERP systému, tok udalostí aj existujúca integračná vrstva končia všetky na tom istom koncovom bode. Použitie middleware sa oplatí, ak ho už aj tak prevádzkujete a má zostať súčasťou zmluvy voči tretím stranám. Ak ho dnes nemáte, nekupujte ho len kvôli produktovému pasu.
O čom sa rozhoduje v rámci workshopu o mapovaní?
Ktoré pole v ERP sa stane referenčným poľom - a ktorý systém je primárnym zdrojom, ak viacero systémov obsahuje tú istú hodnotu. Workshop sa koná v 1. a 2. deň a je kľúčovým bodom celého projektu, pretože práve tam sa rozhoduje o kvalite údajov, a nie neskôr v kóde. Priveďte so sebou ľudí, ktorí sa starajú o systémy, nielen tých, ktorí sú zodpovední za projekt - kmeňové údaje, výroba, kvalita a nákup sa málokedy nachádzajú v jednom oddelení. Všetko, čo nasleduje, teda exporty, validácia a odstraňovanie chýb, je už len remeselná práca.
Naše certifikáty máme k dispozícii iba ako naskenované súbory vo formáte PDF. Čo s nimi máme robiť?
Skenovaný dokument nie je štruktúrovaným zdrojom údajov, a preto je pre pas nepoužiteľný. Existujú dva spôsoby - prevádzkovatelia certifikácií čoraz častejšie ponúkajú dotazy cez API a tam, kde nie sú k dispozícii, zadávajte hodnoty ručne, avšak vždy s dátumom platnosti, aby sa v zverejnenom pase nezachoval žiadny certifikát s vypršanou platnosťou. Ručné zadávanie údajov si naplánujte ako opakujúcu sa činnosť, nie ako jednorazovú úlohu.
Môže naše IT oddelenie skontrolovať rozhranie, než niečo podpíšeme?
Áno. Kompletná schéma a všetky koncové body sú k dispozícii ako špecifikácia OpenAPI na adrese /apidocs, spolu s ukážkovými požiadavkami, chybovými odpoveďami a podrobnosťami o overovaní. Žiadna z týchto informácií nie je predmetom obchodných rokovaní, takže váš integračný tím môže odhadnúť náročnosť projektu ešte pred uzatvorením zmluvy. Ak poskytovateľ v tejto fáze nezverejní svoje rozhranie, je to tiež odpoveď.
Čo sa stane s našimi údajmi, ak zmeníme poskytovateľa?
Budú s vami. Rozhranie prijíma neutrálne schéma JSON namiesto proprietárneho formátu a všetky vaše dáta sa exportujú vo formátoch CSV, XLSX, JSON-LD a SQL alebo prostredníctvom REST API. Je to zámer - formát, do ktorého vkladáte údaje, je prenosný, takže zmena si vyžaduje iba export a nie je potrebné vytvárať nový formát. Pred workshopom o mapovaní položte každému poskytovateľovi tú istú otázku, pretože potom budú vaše názvy polí zahrnuté v jeho modeli.
Ako dlho skutočne trvá pripojenie?
V projektoch, ktoré sprevádzame, to trvá dva týždne - dva dni mapovania, tri dni do prvých exportov prostredníctvom nášho validátora, tri dni odstraňovania chýb, dva dni do zverejnenia prvých pasov. Najdlhšia cesta nikdy nespočíva v kóde, ale v tom, čo validátor odhalí - chýbajúce polia, nejednotné kódovanie, hodnoty, za ktoré sa nikto necíti zodpovedný. Naplánujte si tieto dni, namiesto toho, aby ste ich skracovali. Projekt, ktorý ich vynechá, zverejní aj tieto medzery.
Musíme pripojiť všetky produkty naraz?
Nie. Začnite s produktmi, ktoré potrebujú certifikát ako prvé, a so zdrojovým systémom - neutrálna schéma prijíma či už čiastkový katalóg, alebo kompletný, a importy sú opakovateľné, takže nasledujúce behy aktualizujú stav. Vďaka tomu zostane workshop mapovania dostatočne krátky na to, aby sa dal zvládnuť za dva dni. Následné rozšírenie je úlohou mapovania, nie novým projektom.
