Hmotnost produktu je uvedena v systému správy materiálu. Podíl recyklátu je uveden v systému receptur. Certifikát dodavatele je k dispozici ve formátu PDF na síťovém disku. Produktový pas potřebuje všechny tři údaje v jediném datovém záznamu, a právě v tom spočívá podstata integračního projektu, nikoli v propojení dvou systémů.
„Hladká integrace ERP“ je standardní slib, po kterém v praxi následuje tříměsíční projekt. Zveřejňujeme našeho průvodce, aby vaše IT oddělení mohlo před podpisem smlouvy ověřit, jaké údaje budou skutečně vyžadovány. Tento článek ukazuje, jaké údaje z vašich systémů produktový pas potřebuje, jakými třemi způsoby k nám přicházejí a proč je to možné zvládnout za dva týdny.
Co musí váš ERP systém vlastně poskytnout
Aby mohl vzniknout produktový pas, potřebujeme pro každý produkt:
- Kmenová data - číslo položky, označení, varianty, hmotnosti, rozměry, obrázky
- údaje o kusovníku - komponenty s množstvími a podíly 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 povinností náležité péče)
Ve vašem ERP systému jsou tato data teoreticky všechna k dispozici. V praxi jsou však rozložena do 4 až 7 modulů: správa materiálu, výroba, kvalita, databáze dodavatelů, někdy samostatný modul pro environmentální data, někdy samostatný systém pro receptury a kusovníky.
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é způsoby
Způsob 1: Načtení dat z ERP
Funguje dobře s moderními systémy ERP (SAP S/4HANA Cloud, Dynamics 365, Odoo). Poskytovatel DPP načítá data přes rozhraní ERP (technicky OData nebo REST). Pouze změny, podle časového plánu nebo vyvolané událostí.
Výhody: minimální vývojové náklady z vaší strany, vy poskytnete přístup pro čtení, poskytovatel zajistí konverzi.
Nevýhody: nefunguje se staršími instalacemi SAP ECC bez dodatečné vrstvy rozhraní. Potřebujete jasná pravidla, kdo smí číst která data.
Způsob 2: Předávání změn
Váš ERP systém hlásí každou změnu jako událost (prostřednictvím SAP Event Mesh, Apache Kafka nebo RabbitMQ) a poskytovatel DPP ji přijímá.
Výhody: téměř v reálném čase, systém roste s vámi, systémy nejsou na sobě závislé.
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 zbytečně nákladné.
Způsob 3: Využít stávající integrační vrstvu
Již máte k dispozici integrační vrstvu (Mulesoft, Boomi, Informatica, Azure Data Factory) mezi ERP a externími systémy. Tato vrstva představuje smlouvu: poskytovatel DPP komunikuje s ní, nikdy přímo s ERP.
Výhody: lze využít stávající investice, pravidla zůstávají stabilní, třetí strany nemají přímý přístup k ERP.
Nevýhody: Vaše náklady na integrační vrstvu rostou s ní.
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 rozhraní přijímá neutrální datový formát (schéma JSON), který naplníte pomocí nástroje podle svého výběru. To znamená:
- Úpravu dat můžete provádět 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í formát a všechny dotazy jsou veřejně zdokumentovány na /apidocs jako popis rozhraní podle 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 v ERP odpovídá kterému poli v DPP?
- 3. až 5. den: První exporty ve formátu JSON z ERP, 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 k mapování - tam se rozhoduje o kvalitě dat.
Co se může pokazit: nejčastější úskalí
Matriční data produktů v několika systémech: SAP má číslo položky, 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 pro které pole vedoucí.
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í dotazování prostřednictvím rozhraní (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: kompletní 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 za celé své portfolio, nikoli za 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 je kompromisem.
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 žádost o nabídku (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 integrační vrstvu, kterou by bylo vhodné využít?
- Existuje již funkční rozhraní přes váš ERP systém?
Odpovědi určí, která ze tří cest je pro vás vhodná. A také rozhodnou o tom, zda projekt potrvá dva týdny, nebo šest měsíců.
Dotazy k tomuto příspěvku
Stačí rozhraní REST, nebo potřebujeme middleware?
Rozhraní stačí. Tyto tři vzory se liší v tom, kde k transformaci dochází, nikoli v tom, co přijímáme - naše rozhraní přijímá neutrální schéma JSON, bez ohledu na to, čím jste jej vytvořili. Ať už jde o stahování dat z moderního ERP systému, proud událostí nebo stávající integrační vrstvu, vše končí na stejném koncovém bodě. Použití middlewaru se vyplatí, pokud jej již provozujete a má zůstat součástí smlouvy s třetími stranami. Pokud jej v současné době nemáte, nekupujte jej kvůli produktovému pasu.
O čem se rozhoduje v rámci workshopu o mapování?
Které pole v ERP se stane referenčním polem - a který systém je primárním zdrojem, pokud více systémů obsahuje stejnou hodnotu. Workshop se koná v 1. a 2. dni a je klíčovým bodem celého projektu, protože právě tam se rozhoduje o kvalitě dat, a ne až později v kódu. Přiveďte s sebou osoby, které systémy spravují, nejen ty, které za projekt odpovídají - kmenová data, výroba, kvalita a nákup zřídka spadají do jednoho oddělení. Vše, co následuje, tedy exporty, validace a odstraňování chyb, je již jen řemeslná práce.
Naše certifikáty máme k dispozici pouze jako naskenované soubory ve formátu PDF. Co s nimi máme dělat?
Sken není strukturovaným zdrojem dat, a proto je pro pas nepoužitelný. Existují dva způsoby - provozovatelé certifikací stále častěji nabízejí dotazy přes API a tam, kde to není možné, zadávejte hodnoty ručně, vždy však s datem platnosti, aby v publikovaném pasu nezůstalo žádné certifikát s prošlou platností. Plánujte ruční zadávání jako opakující se činnost, nikoli jako jednorázový úkol.
Může naše IT oddělení zkontrolovat rozhraní, než něco podepíšeme?
Ano. Kompletní schéma a všechny koncové body jsou k dispozici jako specifikace OpenAPI na adrese /apidocs, včetně ukázkových dotazů, chybových odpovědí a podrobností o autentizaci. Nic z toho není skryto za obchodními jednáními, takže váš integrační tým může odhadnout náročnost projektu ještě před uzavřením smlouvy. Pokud poskytovatel v této fázi své rozhraní nezveřejní, je to také určitá odpověď.
Co se stane s našimi údaji, když změníme poskytovatele?
Jdou s vámi. Rozhraní přijímá neutrální schéma JSON namísto proprietárního formátu a veškerá vaše data jsou výstupem ve formátech CSV, XLSX, JSON-LD a SQL nebo prostřednictvím REST API. To je záměr - formát, do kterého data vkládáte, je přenositelný, takže změna vyžaduje pouze export, nikoli vytvoření nového modelu. Před workshopem o mapování položte každému poskytovateli stejnou otázku, protože poté budou názvy vašich polí součástí jeho modelu.
Jak dlouho připojení ve skutečnosti trvá?
V projektech, na kterých spolupracujeme, to trvá dva týdny - dva dny mapování, tři dny do prvních exportů prostřednictvím našeho validátoru, tři dny odstraňování chyb, dva dny do zveřejnění prvních pasů. Dlouhá cesta nikdy nespočívá v kódu, ale v tom, co validátor najde - chybějící pole, nejednotné kódování, hodnoty, za které se nikdo necítí zodpovědný. Naplánujte si tyto dny, místo abyste je zkracovali. Projekt, který je přeskočí, zveřejní i tyto mezery.
Musíme propojit všechny produkty najednou?
Ne. Začněte s produkty, které potřebují průkaz jako první, a se zdrojovým systémem - neutrální schéma přijímá jak dílčí katalog, tak kompletní katalog, a importy jsou opakovatelné, takže pozdější běhy aktualizují stav zásob. Díky tomu zůstane workshop věnovaný mapování dostatečně krátký, aby se dal zvládnout za dva dny. Následné rozšíření je úkolem v rámci mapování, nikoli novým projektem.
