„Plynulá integrácia ERP“ je štandardný sľub, po ktorom v praxi nasleduje trojmesačný projekt. Zverejňujeme našu príručku k API, aby vaše IT oddelenie mohlo ešte pred podpísaním zmluvy overiť, aké údaje sa skutočne vyžiadajú. Tu je to, čo by ste mali vedieť pred začatím integračného projektu.
Čo musí váš ERP systém skutočne poskytovať
Aby vznikol DPP, potrebujeme pre každý produkt:
- Základné údaje - číslo výrobku, názov, varianty, hmotnosť, rozmery, obrázky
- Údaje o zozname komponentov - komponenty s množstvami a podielmi recyklátov
- ú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 due diligence)
V vašom ERP systéme sú teoreticky všetky tieto údaje k dispozícii. V praxi sú však rozptýlené v 4 až 7 moduloch: Správa materiálov (MM), Výroba (PP), Kvalita (QM), Dodávatelia (LFA1), niekedy samostatný modul EHS pre environmentálne údaje, niekedy systém PLM pre receptúry.
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é integračné vzory
Vzor 1: OData / REST-Pull
Funguje dobre s modernými ERP systémami (SAP S/4HANA Cloud, Dynamics 365, Odoo). Poskytovateľ DPP načítava údaje cez OData alebo REST. Inkrementálne, plánované alebo riadené udalosťami.
Výhody: minimálny vývoj z vašej strany, vy poskytnete prihlasovacie údaje na čítanie, poskytovateľ zabezpečí transformáciu.
Nevýhody: nefunguje so staršími inštaláciami SAP ECC bez dodatočnej vrstvy API. Potrebujete riadenie žiadostí o prístup k dátam.
Vzor 2: Integrácia založená na udalostiach
SAP Event Mesh, Apache Kafka, RabbitMQ. Váš ERP systém publikuje udalosti zmien, poskytovateľ DPP ich spracováva.
Výhody: takmer v reálnom čase, elegantne škálovateľné, oddelené.
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é.
Model 3: Middleware / ETL
Máte integračnú vrstvu (Mulesoft, Boomi, Informatica, Azure Data Factory) medzi ERP a externými systémami. Middleware je akousi „zmluvou“ - poskytovateľ DPP komunikuje s middleware, nikdy priamo s ERP.
Výhody: je možné využiť existujúce investície, stabilná správa, žiadny priamy prístup tretích strán k ERP.
Nevýhody: Vaše náklady na middleware rastú úmerne s rozsahom projektu.
Č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 API akceptuje neutrálne schéma JSON, ktoré môžete naplniť pomocou nástroja podľa vlastného výberu. To znamená:
- Úprava údajov si môžete vykonať sami pomocou nástrojov, s ktorými je váš tím oboznámený
- Môžete nás kedykoľvek vymeniť - neutrálny formát je prenosný
- Celý svoj inventár si môžete kedykoľvek opäť stiahnuť - 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á schéma a všetky koncové body sú verejne zdokumentované na /apidocs ako špecifikácia 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ý harmonogram tohto prístupu v praxi:
- Deň 1 až 2: Workshop mapovania. Ktoré pole v ERP zodpovedá ktorému poľu v DPP?
- 3. až 5. deň: Prvé exporty JSON z ERP prostredníctvom nášho validátora.
- 6. až 8. deň: Odstraňovanie chýb (chýbajúce polia, nekonzistentné kódovanie).
- 9. až 10. deň: Prvé DPP sú v prevádzke.
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 vo viacerých systémoch: SAP má číslo artiklu, 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 „Source of Truth“ pre ktoré pole.
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ú dotazy cez API (OEKO-TEX je v čele, GOTS zaostáva). Alebo: ručné zadávanie, ale s dátumom platnosti, aby sa v DPP neobjavili 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 vyjasniť včas.
Údaje o CO₂ na základe informácií od 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é produkty 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 tomuto tématu máme samostatný článok.
Otázky, ktoré by ste si mali položiť pred začatím projektu
Než pošlete výzvu na predloženie ponúk (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 investíciu do middleware, ktorú by ste mali využiť?
- Existuje už fungujúca vrstva API nad vaším ERP?
Odpovede určujú, ktorý z troch modelov je pre vás vhodný. A určujú, či projekt potrvá dva týždne alebo šesť mesiacov.