Středně velká logistická firma jela na pěti oddělených platformách (sklad, doprava, účetnictví, CRM a HR portál), které si mezi sebou nepředávaly žádná data. Místo riskantní kompletní výměny postavila Bitvea vlastní integrační vrstvu. Ta propojí každý systém přes jeho API, sjednotí data do jednoho společného modelu a pohání jednotný dashboard i automatizaci napříč systémy. Tady ukazujeme, jak taková architektura funguje a proč se agregační vrstva vyplatí víc než výměna nástrojů, na kterých firma stojí.
Logistika a dodavatelský řetězecKlientem je středně velká logistická firma, která provozuje sklady i centrální kancelář na pěti různých softwarových platformách: systém řízení skladu (WMS) pro zásoby a expedici, systém řízení dopravy (TMS) pro plánování tras a sledování zásilek, účetní software pro fakturaci a finance, CRM pro obchod a evidenci zákazníků a HR portál pro plánování směn a mzdy. Každý systém přišel v jiné fázi růstu firmy a vybralo si ho oddělení, které ho zrovna nejvíc potřebovalo. Žádný z nich přitom nesdílel data nativně. Firma zkoušela vestavěné integrace a Zapier, jenže ty pokrývaly jen zlomek datových toků a často se rozbíjely. Oddělení se navzájem informovala přes ruční exporty, e-maily a týdenní porady. Vedení chtělo jeden zdroj pravdy, ale výměna všech pěti platforem najednou byla moc drahá a moc rušivá, než aby dávala smysl.
Cena za odpojenost se projevovala všude. Sestavit report napříč systémy znamenalo, že provozní manažer ručně vytahoval čísla z každé platformy do jedné velké tabulky, a do půlky týdne už byla stejně neaktuální. Obchodníci v CRM neviděli živý stav zásob ve WMS, takže objednávali zboží, které nebylo skladem. Finance nedokázaly spárovat náklady na přepravu s fakturami, aniž by řádek po řádku porovnávaly TMS a účetnictví. Plánování směn v HR bylo odtržené od poptávky ve skladech, a tak se v klidných dnech přebíralo a ve špičkách chyběli lidé. Dřívější záplaty přes Zapier a CSV vyžadovaly neustálou údržbu a většinu důležitých datových toků stejně nepokryly. Firma rostla, ale její informační infrastruktura nestíhala.
Bitvea postavila vlastní integrační vrstvu, která stojí mezi pěti stávajícími systémy, aniž by kterýkoli z nich nahrazovala. Představte si ji jako překladač a rozbočovač v jednom. Každá platforma se připojí jednou: přes své API tam, kde existuje, a přímým čtením z databáze s detekcí změn tam, kde ne. Příchozí data se sjednotí do jednoho společného modelu, takže zákazník nebo objednávka znamenají totéž bez ohledu na to, ze kterého systému přišly. Tento společný model pak plní jednotný dashboard a pohání automatizaci napříč systémy řízenou událostmi. Protože se všemi platformami komunikuje jen tato vrstva, každý zdrojový systém běží dál sám o sobě. Když jeden vypadne, ostatních se to nedotkne. A klient vlastní vrstvu, datový model i dashboardy naplno.
Jedno rozhraní, které čte živá data ze všech pěti systémů: stav zásob, aktivní zásilky, otevřené faktury, hodnotu obchodního pipeline i obsazení směn, všechno na jednom místě. Manažer filtruje podle skladu, oddělení nebo období, místo aby čísla ručně skládal dohromady. Vše se čte ze společného modelu, takže všechny týmy konečně koukají na stejná čísla.
Každá platforma má vlastní konektor, který řeší autentizaci, stránkování, limity dotazů a převod do společného modelu. Tam, kde použitelné API chybělo (HR portál nabízel jen základní endpointy), čteme přímo z databáze s logikou detekce změn, takže zpracujeme jen záznamy, které se opravdu změnily. Konektory mají retry logiku a upozornění, takže výpadek zdroje se okamžitě zachytí a nahlásí, místo aby tiše kazil reporty.
Vrstva reaguje na události, místo aby se v pevných intervalech dotazovala systémů. Data tak zůstávají čerstvá a provoz je levný. Uzavřený obchod v CRM spustí kontrolu zásob ve WMS, koncept zásilky v TMS a přípravu faktury v účetnictví. Po dokončení přepravy se náklady spárují samy. Každá akce je idempotentní, takže opakovaně zpracovaná událost nikdy nevytvoří objednávku nebo fakturu dvakrát.
Vrstva spojí trendy objemu objednávek z CRM s harmonogramy zásilek z TMS, předpoví poptávku ve skladech a pak navrhne obsazení do HR portálu a označí dny, kdy hrozí přebytek nebo nedostatek lidí. Manažer schválí jedním kliknutím. Data, která už existovala, ale byla uvězněná v oddělených systémech, se tím mění v rozhodnutí, se kterým tým může něco udělat.
Projekty tohoto typu jdou vždycky stejnou cestou. Nejdřív discovery: zmapujeme všechny datové toky mezi odděleními, najdeme nejbolestivější místa a zdokumentujeme, co API každého systému umí a co ne. Vyzrálost API totiž určuje většinu harmonogramu. Pak navrhneme společný datový model a dashboard, které rovnou procházíme s lidmi, co je budou používat. Vývoj běží v krátkých sprintech a schválně začínáme dvěma nejvíc propojenými systémy, aby tým dostal něco užitečného brzy a ověřil si přístup ještě dřív, než přidáme zbytek. Nasazení jede jako paralelní provoz, starý postup vedle nového, a teprve pak přijde plný přechod s pohotovostní podporou. Protože se nic nevytrhává, nehrozí žádný velký třesk: každý systém běží po celou dobu dál.
Časový plán: Týdny na fázi, ne měsíce jako u kompletní výměny systémů
Abyste získali jednotný přehled, nemusíte měnit fungující systémy. Integrační vrstva, která propojí to, co už máte, je rychlejší, levnější a mnohem méně riziková než kompletní migrace platformy.
Skutečný zlom přináší společný datový model. Jakmile zákazník a objednávka znamenají všude totéž, dashboard i automatizace přestanou bojovat s pěti různými tvary dat.
Synchronizace řízená událostmi je lepší než plánované exporty. Data, která se aktualizují ve chvíli, kdy se něco děje, promění statický report v živý provozní systém, který tým opravdu používá.
Každou akci napříč systémy dělejte idempotentní. Sítě vypadávají a události se opakují. Bez idempotence dostanete místo čistých dat dvojité objednávky a faktury.
Systémy bez pořádného API nejsou překážka. Přímé čtení z databáze s detekcí změn mezery pokryje, pokud tento přístup schováte za stejné rozhraní konektoru.
Začněte dvěma nejvíc propojenými systémy. Brzká a viditelná hodnota vybuduje důvěru v přístup dřív, než se pustíte do zbytku.
Propojte stávající systémy, aniž byste je museli nahrazovat.
Zjistěte více