Integrace e-commerce a logistiky

Objednávka přijde do e-shopu, poté ji někdo e-mailem nebo v Excelu předá skladu. Kolega zkontroluje zásoby, ručně zaznamená údaje do kurýrního systému a později v jiném systému změní stav objednávky. Dokud se jedná o několik desítek balíků denně, může se to zdát zvládnutelné. Při růstu se však rychle ukáže, proč je klíčové, jak integrujeme systémy e-commerce a logistiky: přenos dat není skutečná práce, přesto na něj jde čas a zde vzniká nejvíce chyb.

Cílem integrace není jen to, aby si dva softwary vyměňovaly data. Cílem je vytvořit takový provoz, ve kterém všichni pracují ze stejného stavu, je jasné, kdo za co odpovídá, a systém provádí mechanickou administraci místo lidí. K tomu je nejprve třeba dát do pořádku obchodní proces. Špatně navržený proces rychle propojit znamená rychleji produkovat stejné chyby.

Proč se e-shop a logistika rozdělují?

Většinu problémů nezpůsobuje jediný chybný systém. E-shop, ERP, evidence zásob, WMS, fakturační systém, kurýrní rozhraní a nástroje zákaznického servisu mohou být jednotlivě vhodné. Problémy začínají, když není jasné, který systém říká pravdu o produktu, zásobě nebo stavu objednávky.

Typická situace je, že e-shop slibuje k prodeji zásoby, které sklad již rezervoval pro jiný kanál. Jindy sklad fyzicky připravil balík, ale v e-shopu je stále ve stavu „zpracovává se“. Zákaznický servis pak volá, sklad přerušuje práci kvůli odpovědím a vedoucí se později snaží pochopit, co se stalo, z několika protichůdných zpráv.

Nejde jen o IT nepříjemnosti. Přímo ovlivňují slib dodání, financování zásob, zpracování vratek a zatížení zaměstnanců. Pokud zkušený kolega ví, kterou tabulku je třeba aktualizovat, proces není kontrolovaný, jen obvyklý.

Jak integrovat systémy e-commerce a logistiky?

Správná první otázka není, zda existuje API mezi dvěma systémy. Otázka je, jak objednávka prochází firmou od platby po doručení a kde musí člověk skutečně rozhodnout.

Stojí za to sledovat konkrétní objednávku. Kdy vzniká? Kdy se kontroluje platba? Kdy se rezervuje zásoba? Kdo řeší nedostatek, částečnou dodávku nebo chybu adresy? Kdy se vystavuje faktura? Kdy a za jakých podmínek dostane zákazník oznámení? Při mapování procesu se často ukáže, že ruční krok již neposkytuje obchodní kontrolu, ale kompenzuje dřívější nedostatek systému.

Při plánování integrace poskytují čtyři základní principy stabilní výchozí bod:

• každý důležitý údaj by měl mít určený hlavní systém;
• předaná data by měla mít jasnou obchodní událost a stav;
• zpracování výjimek by nemělo být skryto v běžném procesu;
• chyby musí být viditelné, dohledatelné a opravitelné.

Určení hlavního systému je obzvláště důležité. Obchodní popis a cenu produktu obvykle spravuje e-shop nebo systém produktových informací. Fyzicky dostupné a rezervovatelné zásoby často eviduje skladový systém nebo ERP. Zdroj doručovací adresy a komunikace se zákazníkem může být e-shop, zatímco štítek pro přepravu a událost doručení pochází z přepravního spojení. Ne vždy je stejný rozdělení dobré, ale na stejná data nemůže být trvale více nezávislých „konečných“ zdrojů.

Nespojujte datová pole, ale obchodní události

Slabé řešení je, když časově řízený proces každou půlhodinu kopíruje údaje o objednávkách z jedné databáze do druhé. V určitých prostředích to může být přijatelný kompromis, například u starého systému nebo nízkého objemu objednávek. Ale i tehdy je třeba navrhnout zpracování zpoždění, opakovaných odeslání a přerušeného zpracování.

Lepší výchozí bod je definování obchodních událostí. Například: objednávka schválena, zásoba rezervována, vydáno ke komisionování, balík odeslán, doručení neúspěšné, vratka přijata. Každá událost má odpovědný systém, interpretovatelný stav a v případě potřeby lidský úkol.

To je důležité, protože objednávka není jediný záznam, ale série stavů. Pokud kurýr vygeneroval štítek, ale balík ve skladu ještě není na paletě, nemělo by se automaticky komunikovat se zákazníkem, jako by zásilka již byla na cestě. Takové drobné rozdíly rozhodují o tom, zda zůstanou zprávy a zákaznické informace důvěryhodné.

Výjimky rozhodují, zda je řešení použitelné

Normální cesta objednávky je obvykle rychle automatizovatelná. Těžší otázky se objevují u výjimek: nedostatečné zásoby, zákazník by chtěl změnit objednávku, je třeba plnit z více skladů, adresa je neplatná, poškozené zboží se vrací nebo přepravce hlásí neúspěšné doručení.

Na tyto situace se ne vždy vyplatí dávat zcela automatické odpovědi. U objednávky nad určitou hodnotu, jedinečné B2B dodávky nebo opakovaného problému s adresou může být obchodně odůvodněná lidská kontrola. Úkolem systému je v takovém případě ukázat problém správnému kolegovi se všemi potřebnými podkladovými údaji. Ne vytvářet e-mailové okruhy a samostatné seznamy.

Pro zpracování výjimek jsou potřeba i hranice odpovědnosti. Rozhoduje sklad o náhradním produktu? Může zákaznický servis změnit adresu po komisionování? Kdo řeší anomálii platby nebo rezervace zásob? Pokud tato rozhodnutí existují pouze ústně, integrace neodstraní nejistotu.

Technické provedení: jednoduché, ale kontrolovatelné

Ne každá společnost potřebuje samostatnou integrační platformu nebo velkou přeměnu. Může se stát, že standardní propojení e-shopu a ERP je vhodné, pokud model dat, logika zásob a zpracování výjimek odpovídají provozu. V jiném prostředí může být mezivrstva integrace odůvodněná, zejména pokud se spojují různé prodejní kanály, více skladů, vlastní vývojový systém nebo různé datové struktury.

Bez ohledu na technické řešení jsou potřeba identifikátory, logování a možnost opětovného zpracování. Objednávka, zásilka a produkt musí být konzistentně identifikovatelné ve všech dotčených systémech. Pokud je spojení dočasně nedostupné, systém by neměl tiše ztratit událost. Mělo by být vidět, které přenosy čekají, které jsou chybné a kdo je může bez obchodního rozhodnutí nebo s obchodním schválením znovu spustit.

Práva a ochrana dat jsou také součástí plánování. Ne každý systém a ne každý uživatel musí mít přístup ke kompletním údajům o zákaznících nebo objednávkách. V integraci by měly být přenášeny pouze ty osobní a obchodní údaje, které jsou potřebné k provedení úkolu. To snižuje riziko a činí provoz transparentnějším. Při zavádění neměňte celý provoz najednou

Velká, jednorázová změna se může na první pohled zdát efektivní, ale zpracování objednávek není oblast, kde je snadné přijmout delší období chyb. Je lepší vybrat fázi, kde je jasná bolest a měřitelná změna. Může to být automatizace předání objednávky, synchronizace zásob nebo nahrazení generování přepravních štítků.

Před spuštěním nového propojení je třeba testovat na reálných případech. Nejen na pravidelné, předem zaplacené objednávce, ale i na zrušení, částečné dodávce, nedostatku zásob, vratce, opravě adresy a opakovaném odeslání události. Přijímací podmínky musí být formulovány obchodním jazykem: co vidí sklad, co vidí zákaznický servis, jaký stav dostane zákazník a co se objeví ve zprávě pro vedení. I po zavedení je třeba sledovat proces. Nestačí kontrolovat, zda rozhraní běží. Je třeba vidět, kolik objednávek čeká bezdůvodně, kolik případů vyžaduje ruční zásah, kde se liší systémová zásoba od fyzické a kolik času uplyne mezi jednotlivými stavy. Tyto údaje ukazují nejen fungování IT, ale i kvalitu plnění procesu.V přístupu CGAT se integrace proto nezačíná jako samostatný vývojový úkol, ale společným zkoumáním provozu objednávek a skladu. Dobrý výsledek často nevzniká zavedením více technologií, ale tím, že se odstraní několik nejistých předání, paralelních zdrojů dat nebo zbytečných schválení.

Na příští schůzce vedení je vhodné se neptat, který systém by se měl ještě propojit. Místo toho si vyberte včerejší problematickou objednávku a sledujte ji systémem po systému. Kde se informace zastaví, opakuje nebo pokračuje jen v hlavě jednoho člověka, tam začíná práce, která může skutečně zlepšit spolupráci e-commerce a logistiky.

locale

cs

translation_notes