Blog English Noda.li

Integrace ERP, WMS a TMS v logistice: jak sjednotit data bez výměny systémů


Integrace ERP, WMS a TMS do společné logistické datové vrstvy

Firma může mít moderní ERP, funkční WMS, samostatné TMS, telematiku, účetní systém a portály několika dopravců. Přesto může část každodenního řízení logistiky stále probíhat v Excelu, e-mailech a ručně sestavovaných reportech.

Neznamená to automaticky, že některý ze systémů nefunguje. Každý z nich obvykle popisuje jinou část provozu, používá jiné identifikátory a aktualizuje data v jiném okamžiku.

Problém se projeví ve chvíli, kdy má firma odpovědět na zdánlivě jednoduché otázky:


Odpověď často neleží v jednom systému. Musí se spojit data z ERP, WMS, TMS, dopravců, telematiky a účetnictví.

V tomto článku se podíváme na to, proč se data v jednotlivých systémech rozcházejí, jak určit správný zdroj pravdy a jak vytvořit společný logistický pohled bez okamžité výměny současné infrastruktury.

Právě nad tímto principem vzniká také Nodali – datová a řídicí vrstva pro moderní logistiku.


Jeden provoz, několik verzí reality

Představme si jednu běžnou objednávku.

Objednávka vznikne v e-shopu a následně se přenese do ERP. ERP ji eviduje jako obchodní doklad a může obsahovat informace o zákazníkovi, ceně, způsobu dopravy a fakturaci.

Ve WMS se stejná objednávka změní na úkoly pro sklad. WMS řeší dostupnost zboží, vychystání, balení, expedici a případné rozdělení objednávky do více balíků.

TMS pracuje s přepravou. Může seskupit více zásilek do jedné trasy, přiřadit vozidlo nebo dopravce a vytvořit plánované časy odjezdu a doručení.

Dopravce následně používá vlastní trackingové stavy. Telematika sleduje skutečný pohyb vozidla. Účetnictví nebo faktura dopravce až později ukáže konečné náklady.


Každý systém tedy odpovídá na jinou otázku:


Rozdílná čísla proto nemusí znamenat chybu. Mohou pouze popisovat jinou část procesu nebo jiný okamžik.

Chyba vzniká ve chvíli, kdy se tato data používají jako by znamenala totéž.


Proč se data v ERP, WMS a TMS nejčastěji neshodují

1. Každý systém pracuje s jinou entitou

Objednávka, zásilka, balík, přeprava, trasa a zastávka nejsou stejné objekty.

Jedna objednávka může obsahovat několik zásilek. Jedna zásilka může být rozdělena do více balíků. Několik zásilek může být spojeno do jedné přepravy a jedna trasa může obsahovat desítky zastávek.

Pokud se například počet objednávek z ERP porovná přímo s počtem přeprav v TMS, budou se výsledky přirozeně lišit.

2. Systémy používají rozdílné identifikátory

Jedna zásilka může mít současně:


Pokud mezi těmito identifikátory neexistuje spolehlivá vazba, musí se data spojovat pomocí kombinace adresy, času, zákazníka nebo jiných nepřesných údajů.

3. Stejné názvy stavů mohou znamenat něco jiného

Stav „expedováno“ může ve WMS znamenat, že zásilka opustila sklad. V ERP může znamenat pouze uzavření výdejového dokladu. U dopravce se podobný stav může objevit až po prvním fyzickém skenu.

Stejný název tedy nemusí představovat stejnou provozní událost.

Naopak různé názvy mohou znamenat totéž. Jeden dopravce používá „Delivered“, druhý „Completed“ a třetí vlastní číselný kód.

4. Jeden systém ukazuje plán, druhý skutečnost

TMS obvykle obsahuje plánované kilometry, časy a kapacitu. Telematika nebo mobilní aplikace řidiče ukazuje skutečný průběh.

Pokud report nesprávně kombinuje plánované a skutečné hodnoty, může vzniknout zavádějící výsledek. Trasa může být podle plánu včas, ale ve skutečnosti již nabírat zpoždění.

5. Události vznikají a přicházejí v rozdílný čas

Pro logistická data jsou důležité minimálně dva časy:


Řidič může potvrdit doručení v 10:15, ale data se kvůli nedostupnému připojení odešlou až v 11:02. Pokud systém pracuje pouze s časem přijetí, může nesprávně vyhodnotit SLA.

6. Aktualizace jsou asynchronní nebo selžou

Integrace mezi systémy obvykle neprobíhají ve stejném okamžiku. Jeden systém odesílá data okamžitě, jiný jednou za několik minut a další pouze dávkovým exportem jednou denně.

Navíc může dojít k dočasné nedostupnosti API, chybě importu nebo odmítnutí konkrétního záznamu. Bez monitoringu integračních toků pak jeden systém pracuje s novou hodnotou a druhý se starou.

7. Objednávka se během provozu změní

Zákazník může změnit adresu, zásilka může být rozdělena, položka může být stornována nebo může dojít k přesměrování na jiné výdejní místo.

Pokud se změna propíše pouze do části systémů, vznikne několik rozdílných verzí stejného případu.

8. Část procesu je stále ruční

Manuální úpravy nejsou automaticky špatně. V provozu jsou často nezbytné. Problém vzniká, pokud není dohledatelné:

9. Skutečné náklady přicházejí později

V době plánování může být k dispozici pouze tarifní nebo odhadovaná cena. Konečná faktura může později obsahovat palivový příplatek, mýtné, čekání, vratku, dobírku, nadrozměr nebo jinou doplňkovou službu.

Bez propojení provozních dat s fakturací firma porovnává plán s neúplnou skutečností.


Který systém má být zdrojem pravdy?

Častou chybou je snaha určit jeden systém jako univerzální zdroj pravdy pro celý logistický provoz.

Ve skutečnosti je praktičtější určit zdroj pravdy pro jednotlivé oblasti nebo atributy.


Příkladem může být:


Společná datová vrstva potom nevybírá jeden vítězný systém. Udržuje vazby mezi zdroji, zná původ jednotlivých údajů a vytváří sjednocený provozní pohled.

U každé důležité hodnoty by mělo být možné dohledat:


Proč samotný dashboard nebo Power BI problém nevyřeší

Business intelligence nástroje jsou velmi užitečné pro vizualizaci a analýzu dat. Samy o sobě ale automaticky neřeší význam, kvalitu a provozní návaznost vstupních informací.

Dashboard může zobrazit přesně to, co do něj bylo načteno. Pokud však nejsou správně vyřešené vazby mezi objednávkou, zásilkou, přepravou a náklady, pouze přehledně zobrazí nekonzistentní data.


Před vytvořením spolehlivého reportu je potřeba vyřešit například:


Dalším rozdílem je práce s provozní akcí.

Dashboard může ukázat, že je zásilka zpožděná. Řídicí vrstva může navíc vytvořit výjimku, přiřadit odpovědnost, zaznamenat způsob řešení a spustit navazující workflow.

Nejde tedy o volbu mezi datovou vrstvou a BI. Dobře připravená datová vrstva může naopak sloužit jako spolehlivý zdroj pro Power BI, vlastní dashboardy i další analytické nástroje.


Jak má vypadat společný logistický datový model

Společný model nemusí kopírovat strukturu jednoho konkrétního ERP, WMS nebo TMS. Měl by popisovat logistickou realitu napříč systémy.


Typicky může obsahovat například následující entity:


Každý záznam by měl vedle sjednoceného identifikátoru uchovávat také identifikátory ze zdrojových systémů.

U událostí je důležité rozlišit:


Takový model umožní porovnávat data, aniž by firma musela všechny systémy přinutit používat stejnou interní strukturu.


Jak propojit ERP, WMS a TMS bez jejich výměny

Integrace nemusí začínat rozsáhlým transformačním projektem.

V praxi lze využít různé způsoby napojení podle možností konkrétního systému:


Ne každý zdroj musí být od začátku připojen v reálném čase. Pro první pilot může být dostatečný pravidelný export, pokud umožní ověřit datový model a skutečnou hodnotu výsledku.

Důležité je navrhnout integraci tak, aby bylo možné později způsob přenosu změnit bez přestavby celého společného modelu.


Tři vrstvy spolehlivé integrace

1. Connect: bezpečně převzít data

První vrstva zajišťuje napojení zdrojů, pravidelné načítání, validaci formátu, evidenci chyb a opakování neúspěšných přenosů.

Jejím cílem není pouze data přijmout, ale také poznat, že očekávaná data nepřišla nebo přišla v neplatné podobě.

2. Understand: sjednotit význam

Druhá vrstva mapuje identifikátory, stavy, události a vztahy mezi jednotlivými entitami.

Zde se například určí, že tři rozdílné trackingové kódy různých dopravců představují jednotný stav „doručeno“ nebo že konkrétní fakturační položka patří k určité zásilce a trase.

3. Act: reagovat na provozní situaci

Třetí vrstva umožňuje nad sjednocenými daty vytvářet upozornění, výjimky a workflow.

Například:


Tím se integrace mění z pasivního přesouvání dat na praktický nástroj pro řízení provozu.


Jak začít malým pilotem

Nejbezpečnější cestou obvykle není propojit všechny systémy a celý provoz najednou.

Vhodnější je začít jednou otázkou, na kterou dnes firma nedokáže spolehlivě odpovědět.


Pilotní use-case může být například:


Typický postup může mít čtyři kroky:

1. Vybrat konkrétní problém

Problém by měl mít jasného vlastníka, dostupná data a prakticky měřitelný přínos.

2. Připojit pouze potřebné zdroje

Pro kontrolu výkonu dopravce může stačit ERP nebo e-shop, expediční data z WMS a tracking dopravce. Telematika ani kompletní účetnictví nemusí být v první fázi potřeba.

3. Ověřit data na reálném období

Výsledek je potřeba porovnat s reálným provozem, ručními kontrolami a znalostí lidí, kteří proces denně řídí.

4. Rozšířit pouze to, co přináší hodnotu

Další zdroje, dashboardy a automatizace se přidávají až podle výsledků pilotu.


Praktické příklady společného pohledu

Výkon externích dopravců

Objednávky z e-shopu nebo ERP se propojí s expedičními daty WMS a trackingovými událostmi dopravců.

Firma následně může porovnat rychlost doručení, první pokus o doručení, zpoždění, vratky a výkon podle regionu nebo služby.

Více informací o tomto typu využití najdete na stránce Nodali pro e-shopy.

Plán versus skutečný průběh trasy

Plán z TMS se spojí s pohybem vozidla z telematiky a se skutečnými časy na zastávkách.

Výsledkem může být přehled odchylek, čekání, zpožděných odjezdů, neplánovaných kilometrů nebo rozdílů v produktivitě jednotlivých tras.

Více informací je na stránce Nodali pro vlastní logistiku.

Kontrola nákladů a fakturace

Objednaná přepravní služba se porovná s plánovanou cenou, skutečným průběhem přepravy a fakturovanými položkami.

Firma může identifikovat nečekané příplatky, chybné sazby, duplicitní položky nebo náklady, které nelze přiřadit ke konkrétní zásilce.

Provozní výjimky

Nad sjednocenými daty lze rozpoznat zásilky bez očekávaného stavu, chybějící dokumenty, překročené SLA nebo neobvyklé odchylky.

Místo ručního procházení několika portálů vznikne seznam konkrétních případů, které vyžadují pozornost.


Jak poznat, že firma potřebuje společnou datovou vrstvu

Typickými signály jsou:


Samotná přítomnost Excelu není problém. Problémem je situace, kdy tabulka supluje chybějící vazby mezi klíčovými provozními systémy a její správnost závisí na ruční práci jednoho člověka.


Jak k integraci přistupuje Nodali

Nodali nevzniká jako náhrada ERP, WMS nebo TMS.

Vytváří nad dostupnými systémy společnou datovou a řídicí vrstvu. Ta sjednocuje logistické entity, uchovává vazby na zdrojová data a umožňuje nad nimi vytvářet provozní přehledy, metriky, výjimky a navazující automatizace.


Konkrétní pilot může začít pouze jedním zdrojem dat, jedním dopravcem nebo jednou částí provozu.

Není nutné mít připravená všechna API ani dokonale vyčištěná data. Dostupnost, kvalita a struktura dat jsou součástí úvodní analýzy.


Chcete sjednotit data z ERP, WMS a TMS?

Hledáme firmy, které řeší konkrétní problém s propojením logistických systémů, ručními reporty, výkonem dopravců nebo dohledatelností skutečných nákladů.

Pilotní spolupráce může začít jednou praktickou otázkou a omezeným rozsahem dat.



Často kladené otázky


Proč se data v ERP, WMS a TMS neshodují?

Každý systém obvykle pracuje s jinými entitami, identifikátory, stavy a časováním. ERP může evidovat objednávku, WMS expedici a TMS přepravu. Rozdílná čísla proto nemusí znamenat chybu, ale odlišný pohled na stejný provoz.


Musí mít firma jeden univerzální zdroj pravdy?

Nemusí. Praktické je určit zdroj pravdy pro jednotlivé oblasti. ERP může být zdrojem pro obchodní údaje, WMS pro expedici, TMS pro plán trasy, telematika pro skutečný pohyb a účetnictví pro konečné náklady.


Je nutné ERP, WMS nebo TMS vyměnit?

Ne. Společnou datovou vrstvu lze vytvořit nad existujícími systémy pomocí API, webhooků, databázového přístupu, SFTP, exportů nebo individuálních konektorů.


Stačí pro sjednocení dat Power BI?

Power BI a další BI nástroje jsou vhodné pro vizualizaci a analýzu. Předtím je však potřeba vyřešit identifikátory, význam stavů, kvalitu dat, konfliktní hodnoty a časování jednotlivých zdrojů.


Musí být všechny integrace v reálném čase?

Nemusí. Požadovaná rychlost závisí na konkrétním use-casu. Pro pravidelnou kontrolu nákladů může stačit denní import, zatímco řízení provozních výjimek může vyžadovat aktualizace v kratších intervalech.


Lze začít pouze s CSV nebo XLSX exporty?

Ano. Export může být vhodným začátkem pilotu, pokud obsahuje potřebná data a lze spolehlivě opakovat jeho zpracování. Později lze stejný datový model napojit na API nebo jiný automatizovaný zdroj.


Jaký use-case je vhodný pro první pilot?

Vhodný je konkrétní a měřitelný problém, například výkon jednoho dopravce, zpožděné zásilky, porovnání plánovaných a skutečných kilometrů, kontrola příplatků nebo nahrazení ručně sestavovaného reportu.


Jak Nodali pomáhá s integrací logistických dat?

Nodali propojuje dostupné zdroje, sjednocuje logistické entity a události a vytváří společný pohled na provoz, výkon, náklady a výjimky bez nutnosti okamžitě nahrazovat současné systémy.



Nodali | Nodali pro e-shopy | Nodali pro vlastní logistiku | Ceník | Pilotní program