Čím se liší napojení na sklad a dopravu od napojení na ERP

Technicky jde o stejnou úlohu jako u ERP — dokumentované rozhraní, dohodnutá pole, dohodnutá frekvence. Prakticky je jinak dvojí. Zaprvé počet stran: u ERP jedná IT obvykle s jedním správcem, u WMS (Warehouse Management System, skladový systém) a TMS (Transport Management System, systém plánování dopravy) přibývají další dva dodavatelé, každý s vlastním kalendářem nasazení změn. Zadruhé kolize horizontů: ERP pracuje s doklady a dny, WMS se skladem a rampou v rámci směny, TMS s plánem přeprav na dny dopředu — a ve chvíli, kdy si tři systémy o témže vozidle řeknou tři různé věci, musí být předem jasné, který záznam u brány vyhrává. Integrace se pak neláme na protokolu, ale na tom, že za funkci celku neručí nikdo.

Že frekvence výměny plyne z povahy dat, a ne z projektu — avízo na příští den snese dávku, ověření oprávnění u brány potřebuje aktuální stav — je základ popsaný v checklistu pro propojení vrátnice s ERP. Tenhle text ho předpokládá jako hotový a ptá se na to, co u jednoho ERP neexistuje: co dělat, když jsou systémy tři, patří třem různým vlastníkům a jejich horizonty si nad jedním vozidlem odporují. Kam všude se technologie na bráně napojuje a za jakých podmínek, shrnuje stránka integrace na podnikové systémy.

Tři horizonty, které se potkají nad jedním vozidlem

Rozdíl mezi tím, co jednotlivé vrstvy řídí — sklad, doprava a dvůr mezi bránou a rampou (Yard Management, YMS) — popisuje článek YMS vs. WMS vs. TMS. Pro návrh integrace je ale důležitější jiná osa než ta funkční: čas, se kterým každý systém počítá.

Samotný rozdíl horizontů se dá pokrýt různou frekvencí u každého toku. Zajímavé je až to, co se stane, když se horizonty potkají nad jedním vozidlem. Plánování dopravy změní ráno dopravce u odpolední přepravy, sklad má ale závoz z noční dávky už uzavřený a ERP drží u téhož dokladu původního partnera. K bráně pak dojede vozidlo, které odpovídá jednomu ze tří záznamů. Který z nich je platný, není technická otázka — je to rozhodnutí, které patří do zadání, a musí být udělané pro každé pole zvlášť, ne paušálně za systém.

Přitom platí, že o průjezdu nerozhoduje žádný z těch tří systémů. Rozhodnutí u závory padá lokálně z evidence, kterou má platforma u sebe — proto nejde o frekvenci dotazu, ale o to, jak stará smí ta evidence být. Změna dopravce nebo registrační značky (dále SPZ) provedená ráno musí být v evidenci, ze které elektronická vrátnice rozhoduje, dřív než k bráně dojede vozidlo. Interval se tedy neodvozuje od toho, jak často se dá ptát, ale od toho, jak rychle se změna v provozu skutečně děje.

A druhá věc, která u jednoho ERP nevzniká: dohodnutý interval je jen tak spolehlivý, jak spolehlivé je ohlašování změn na všech třech stranách. Upgrade skladového systému nasazený o víkendu umí změnit strukturu exportu a v pondělí ráno rozhraní mlčí, aniž by kdokoli něco porušil — dodavatel nasazoval podle svého kalendáře. Ohlašování změn proto patří do smlouvy s každým ze tří dodavatelů, ne do dobré vůle.

Tři rozhodnutí o datech, která u jednoho ERP nikdo dělat nemusí

Výčet polí, která z plánování dopravy a ze skladu tečou na bránu, i mechaniku párování závozu s časovým oknem a SPZ rozebírá článek jak propojit Yard Management s ERP a WMS — tady je neopakujeme. Se třemi systémy se ale k témuž výčtu přidávají tři rozhodnutí navíc:

• Granularita. WMS obvykle pracuje s řádky, paletami a skladovými jednotkami, TMS s přepravou mezi lokalitami. Brána potřebuje jeden záznam na vozidlo. Někdo tedy musí řádky agregovat do závozu — a je to rozhodnutí, které patří do zadání, ne na testování.
• Slovník polí. Totéž se v každém systému jmenuje jinak: v dopravě přeprava, ve skladu příjemka, na bráně vozidlo se značkou. Dokud si tři strany neodsouhlasí, které pole je v kterém systému nositelem téhož významu, mluví o integraci každý o něčem jiném a spor se pozná až u prvního testu.
• Dvojí evidence dopravce. Dopravce bývá založený v TMS i v ERP. Když se předává obojí, dostane areál dva různé záznamy o téže firmě a odbavení se rozpadne na ruční dohledávání. Jeden zdroj, jeden formát identifikace, ostatní jen čtou.

Za funkci celku neručí nikdo

Nejčastější příčina zpoždění není chybějící API, ale prázdné místo v odpovědnosti. Typický obrázek: ERP spravuje interní IT, WMS externí dodavatel, plánování dopravy má na starosti logistika s vlastním nástrojem — a technologie na bráně je čtvrtá strana. Každý ručí za svůj kus, za spojení neručí nikdo, a když se dodavatelé neshodnou, které pole nese referenční číslo, nemá kdo spor rozseknout. Že chybějící vlastník procesu je samostatná příčina neúspěchu, a ne organizační detail, rozebírají články IT/OT integrace areálu a kdy digitalizace nedává smysl.

Metodiku „nejdřív ověřit, potom slíbit" používá SECAPRO u každého napojení; podmínky shrnuje stránka napojení na podnikové systémy. U tří systémů k ní patří jedna role navíc, a to na straně zákazníka: člověk, který drží celek. Ne projektový manažer dodavatele, ale někdo, kdo má pravomoc rozhodnout, čí pole vyhraje, a svolat tři dodavatele k jednomu testu. Bez něj se dá integrace naprogramovat, ale ne dokončit.

Šest kroků projektu se třemi rozhraními

1. Inventura systémů a vlastníků. Ke každému systému jméno, verze a člověk, který za rozhraní odpovídá — u externího dodavatele i to, jak se jeho součinnost objednává. Dokud je některé políčko prázdné, není co termínovat.
2. Matice datových toků. Jeden řádek na každý tok: zdroj, cíl, konkrétní pole, směr, frekvence. Jak taková tabulka vypadá a proč patří i do zadávací dokumentace, rozebírá článek co má obsahovat zadání integrace v tendru. U tří systémů k ní přibývají dva sloupce, které u jednoho ERP nikomu nechybí: odpovědná osoba na obou stranách toku, aby při sporu o pole bylo koho svolat, a chování při výpadku, tedy co se stane u brány, když zrovna tenhle tok mlčí. Bez druhého sloupce se rozhoduje až na místě, kde stojí řidič.
3. Objednání součinnosti externích dodavatelů. Testovací prostředí, dokumentace a čas jejich lidí jsou samostatná objednávka s vlastní cenou a lhůtou. Bývá to nejdelší položka harmonogramu — a začít se s ní má dřív než s vývojem.
4. Záložní cesta ke každému toku. Neregistrovaný dopravce se odbaví na kiosku, závoz bez avíza vznikne z žádosti dopravce podané přes veřejnou předregistraci bez přihlášení, kterou logistik schválí přetažením na rampu, a chybějící rozhraní zastoupí pravidelný import souboru v dohodnutém formátu. Vrátnice i plánování ramp a časových oken fungují i bez integrace — integrace zkracuje cestu, není podmínkou provozu.
5. Testovací okno se všemi stranami najednou. Tři systémy znamenají tři testovací prostředí a tři vytížené kalendáře. Když se společný termín neplánuje jako samostatná položka harmonogramu, čeká se na součinnost a etapa se posune.
6. Akceptace na provozním scénáři. Ne přejímka po jednotlivých rozhraních, ale jeden souvislý průchod: závoz vznikne ve skladu, dopravce se předá do časových oken, vozidlo přijede, systém ho spáruje podle SPZ, projede a zapíše se historie. Každý dodavatel umí předvést, že jeho rozhraní odpovídá — a řidič u brány přesto stojí, protože se nikdo nedíval na celý řetěz.

Pořadí platí i pro etapy: první je ten tok, který odstraní nejvíc ručního přepisování. Vývoj každého rozhraní vede SECAPRO jako samostatnou položku rozpočtu, takže se zbytek dá odložit do druhé etapy, aniž se projekt zastaví.

Kdy to nedává smysl

• Není nikdo, kdo drží celek. Bez rozhodovací pravomoci nad datovým modelem se tři dodavatelé nedohodnou. Dokud tuhle roli zákazník neobsadí, je poctivější integraci odložit než ji termínovat.
• Plánování dopravy provozuje dopravce, ne vy. Rozhraní cizí firmy si nemáte jak objednat. Řešením je veřejná předregistrace dopravců, ne rozhraní, které nemá kdo na druhé straně držet.
• Součinnost dodavatele WMS není objednaná. Skladový systém provozuje externí firma a její čas ani testovací prostředí zatím nikdo neobjednal. Rozhraní se pak nedá otestovat ani termínovat, i kdyby dokumentace existovala.

Obecná omezení napojení na ERP a WMS — malý objem, systém před výměnou, očekávání živého obrazu dvora v podnikovém systému — rozebírá článek jak propojit Yard Management s ERP a WMS.

Časté dotazy

Máme ERP i WMS. Na který systém se napojit?

Podle toho, kde závozy skutečně vznikají a kdo je edituje během dne. Když se plán mění ve skladu, je zdrojem WMS a napojení na ERP nic nepřidá. Rozhoduje se to na začátku projektu podle jednoho datového toku, ne paušálně za celý podnik.

Náš systém plánování dopravy provozuje dopravce. Jde to napojit?

Jen tehdy, když se dá objednat součinnost jeho provozovatele — rozhraní cizí firmy si nemáte jak vynutit ani otestovat. Pokud to nejde, navrhneme místo integrace veřejnou předregistraci dopravců.

Kdo platí součinnost dodavatele WMS?

Ve smluvním vztahu je dodavatel skladového systému se zákazníkem, ne s dodavatelem technologie na bráně — jeho čas a testovací prostředí si tedy objednává a hradí zákazník. Do zadání proto patří nejen to, že rozhraní má existovat, ale i kdo u koho objedná součinnost a v jaké lhůtě. Když se tohle řeší až při realizaci, čeká celý projekt na jednu objednávku.

Kdo má být na naší straně odpovědný, když jsou systémy tři?

Za každé rozhraní jeho správce, a nad tím jeden člověk s pravomocí rozhodnout o datovém modelu a svolat všechny strany k testu. Tuhle roli dodavatel technologie nemůže převzít — nemá pravomoc uvnitř vašeho IT ani u vašich dodavatelů.

Co se stane, když avízo nedorazí nebo dorazí pozdě?

Vozidlo se odbaví jako neohlášené: na kiosku, kde projde registrací a seznámením. Chování při chybějícím avízu patří do návrhu procesů předem — u skladu a dopravy se to totiž netýká dokladu, ale řidiče, který právě stojí u brány.

---

Pokud napojení na sklad nebo plánování dopravy zvažujete, napište nám, jaké systémy a v jakých verzích provozujete a kdo za ně u vás odpovídá — vrátíme se s návrhem rozsahu a s tím, co k němu budeme potřebovat od vaší strany.

Související články

• Jak propojit přístupový systém s návštěvním systémem
• API elektronické vrátnice: co má umět a na co se ptát
• Integrace mostové váhy s evidencí průjezdů: vážní lístek bez přepisování
• Jak propojit docházku, přístupový systém, návštěvy a vjezd