„Hladká integrace ERP“ je standardní slib, po kterém v praxi následuje tříměsíční projekt. Zveřejňujeme naši příručku k API, aby vaše IT oddělení mohlo ještě před podpisem smlouvy ověřit, jaké údaje budou skutečně vyžadovány. Zde je několik informací, které byste měli znát před zahájením integračního projektu.
Co musí váš ERP systém skutečně poskytovat
Aby vznikl DPP, potřebujeme pro každý produkt:
- Kmenová data - číslo položky, název, varianty, hmotnost, rozměry, obrázky
- Data kusovníku - komponenty s množstvím a podílem recyklátu
- údaje o původu - místo výroby, číslo šarže, datum výroby
- environmentální údaje - CO2eq na jednotku, spotřeba vody, spotřeba energie
- údaje o dodavatelích - kdo dodává kterou komponentu (pro účely due diligence)
Ve vašem ERP systému jsou teoreticky všechna tato data k dispozici. V praxi jsou však rozděleny do 4 až 7 modulů: řízení materiálů (MM), výroba (PP), kvalita (QM), dodavatelé (LFA1), někdy samostatný modul EHS pro environmentální údaje, někdy systém PLM pro receptury.
Otázka integrace nezní: „Poskytuje váš ERP systém data do DPP?“ Zní: „Jak spojíte data z 5 subsystémů do jednoho souvislého datového souboru?“
Tři osvědčené integrační vzory
Vzor 1: OData / REST-Pull
Funguje dobře s moderními ERP systémy (SAP S/4HANA Cloud, Dynamics 365, Odoo). Poskytovatel DPP stahuje data přes OData nebo REST. Inkrementálně, plánovaně nebo řízeno událostmi.
Výhody: minimální vývojová zátěž z vaší strany, poskytnete přihlašovací údaje pro čtení, poskytovatel zajistí transformaci.
Nevýhody: nefunguje se staršími instalacemi SAP ECC bez dodatečné vrstvy API. Potřebujete správu žádostí o přístup k datům.
Vzor 2: Integrace založená na událostech
SAP Event Mesh, Apache Kafka, RabbitMQ. Váš ERP systém publikuje události změn, poskytovatel DPP je spotřebovává.
Výhody: téměř v reálném čase, elegantně škálovatelné, oddělené.
Nevýhody: Nastavení je náročné a vyžaduje infrastrukturu, kterou nemá každé IT oddělení. Pro menší firmy je to většinou přehnané.
Model 3: Middleware / ETL
Mezi ERP a externími systémy máte integrační vrstvu (Mulesoft, Boomi, Informatica, Azure Data Factory). Middleware představuje rozhraní - poskytovatel DPP komunikuje s middlewarem, nikdy přímo s ERP.
Výhody: lze využít stávající investice, stabilní správa, žádný přímý přístup třetích stran k ERP.
Nevýhody: Vaše náklady na middleware rostou úměrně s rozsahem projektu.
Co děláme jinak v konkrétních projektech
Mnoho poskytovatelů se chce připojit přímo k vašemu ERP. My zásadně zavádíme mezikrok: naše API přijímá neutrální schéma JSON, které naplníte pomocí nástroje podle vlastního výběru. To znamená:
- Můžete si data připravit sami pomocí nástrojů, které váš tým zná
- Můžete nás vyměnit - neutrální formát je přenositelný
- Celý svůj datový fond si můžete kdykoli znovu stáhnout - ve formátech CSV, XLSX, JSON-LD a SQL, stejně jako přes REST-API
- Poskytujeme validátor importu, který vaše data před nahráním zkontroluje
Kompletní schéma a všechny koncové body jsou veřejně zdokumentovány na /apidocs jako specifikace OpenAPI. Vaše IT oddělení může rozhraní otestovat ještě před podpisem smlouvy - včetně ukázkových dotazů, chybových odpovědí a podrobností o autentizaci.
Časový rámec tohoto přístupu v praxi:
- 1. až 2. den: Workshop k mapování. Které pole ERP odpovídá kterému poli DPP?
- 3. až 5. den: První exporty ve formátu JSON z ERP systému, prověřené naším validátorem.
- 6. až 8. den: Oprava chyb (chybějící pole, nekonzistentní kódování).
- 9. až 10. den: První DPP jsou v provozu.
Dva týdny, ne tři měsíce. Klíčovým bodem je workshop mapování - tam se rozhoduje o kvalitě dat.
Co se může pokazit: nejčastější úskalí
Základní údaje o produktech v několika systémech: SAP má číslo artiklu, PIM má obrázky a marketingové texty, PLM má kusovník. Nikdo nemá ucelený přehled. Řešení: před zahájením projektu definujte, který systém je „Source of Truth“ pro které pole.
Certifikáty ve formátu PDF: dodavatelé dodávají certifikáty GOTS, OEKO-TEX nebo REACH jako naskenované soubory PDF. To není strukturovaný zdroj dat. Řešení: Certifikační orgány stále častěji nabízejí dotazy přes API (OEKO-TEX je v čele, GOTS zaostává). Nebo: ruční zadávání, ale s datem platnosti, aby se v DPP neobjevovaly certifikáty s prošlou platností.
Důvěrnost složení: zejména v kosmetice, potravinářství a farmacii: úplné složení je obchodním tajemstvím. Má je DPP zveřejnit? Řešení: Tříúrovňový model ESPR. Veřejně je dostupná kategorie produktu, úřady vidí kompletní složení. Téměř nikdy to není překážka, ale je třeba to vyjasnit včas.
Údaje o CO₂ na základě dodavatelů: Váš dodavatel uvádí průměrnou hodnotu pro celé své portfolio, nikoli pro jednotlivé šarže. Řešení: Dočasně to akceptovat, dlouhodobě upravit dodavatelské smlouvy. ESPR vyžaduje hodnoty specifické pro jednotlivé produkty od určitého data, ale současná praxe představuje kompromis.
Místní jazykové verze: Váš ERP systém obsahuje pouze názvy produktů v němčině a angličtině. Pro 27 zemí EU potřebujete více. Řešení: strojový překlad s terminologickou databází; k tomuto tématu máme samostatný článek.
Otázky, které byste si měli položit před zahájením projektu
Než zašlete výzvu k podání nabídky (RFP) třem dodavatelům, odpovězte si interně na následující otázky:
- Kolik produktů/čísel položek má mít DPP? (10, 10 000, 1 milion?)
- Které systémy dnes uchovávají data relevantní pro DPP?
- Které oddělení spravuje jednotlivé systémy?
- Máte investici do middlewaru, kterou byste měli využít?
- Existuje již funkční vrstva API nad vaším ERP systémem?
Odpovědi určí, který ze tří modelů je pro vás vhodný. A také určí, zda projekt potrvá dva týdny nebo šest měsíců.