Případová studie systémové integrace v e-shopu

Někdo každé ráno otevře administraci e-shopu, stáhne nové objednávky a poté je zkopíruje do podnikového systému. Poté zkontroluje sklad v samostatné tabulce, pošle seznam chybějících položek skladu a opraví řádky, kde se data liší. Než tento proces skončí, přijdou nové objednávky. Tento případ integrace systémů není příběhem špatně pracujícího týmu. Naopak: je to o zaměstnancích, kteří se snaží udržet stávající proces funkční, zatímco společnost z něj vyrůstá.

Následující příklad ukazuje typický, anonymizovaný rostoucí obchodní provoz. Poučení není, že na každý problém je odpovědí nový systém nebo kompletní výměna ERP. Podstatné je nejprve pochopit, kde se přerušuje tok informací a proč lidé nahrazují propojení mezi systémy.

Případová studie integrace systémů: když objednávky cestují ručně

Společnost prodávala tisíce produktů prostřednictvím vlastního e-shopu a několika partnerských kanálů. E-shop, fakturační program a skladová evidence fungovaly samostatně. Problém byl v tom, co se dělo mezi nimi.

Objednávková data byla do podnikového systému přenášena dvakrát denně. Informace o skladových zásobách se do e-shopu dostávaly se zpožděním, takže se stávalo, že bylo možné zakoupit produkt, který již byl vyprodán. Před fakturací kolegové ručně kontrolovali údaje o zákaznících, způsob dopravy a dobírkové objednávky. Pokud zákazník změnil adresu, změna se často projevila pouze v jednom systému.

První otázka vedení byla pochopitelně: máme automatizovat zpracování objednávek? Správná první otázka však byla jiná: proč je třeba stejnou objednávku kontrolovat třikrát a který systém je důvěryhodným zdrojem daných dat?

Tento rozdíl je zásadní. Pokud technicky propojíme neuspořádaný proces, integrace pouze rychleji přenáší chyby. Chybná logika skladových zásob, neúplná kmenová data nebo nejasné odpovědnosti se nevyřeší tím, že přenos dat bude automatický.

Šetření nezačalo u rozhraní

Při mapování procesu se nejprve nezjišťovalo, jaké API systémy mají. Sledovalo se, co se děje od přijetí objednávky po odeslání balíku, a poté až po dokončení faktury a reportu.

Ukázalo se, že značná část manuální práce nebyla skutečným zadáváním dat, ale řízením rizik. Zaměstnanci kontrolovali každou objednávku, protože nedůvěřovali údajům o skladových zásobách. Vedli samostatnou tabulku problémových položek, protože ve skladovém systému nebylo snadné filtrovat objednávky čekající na částečné dodání. Komunikovali e-mailem s finančním oddělením, protože stav refundací se nevracel jednotně do zákaznického systému.

Šetření objasnilo čtyři rozhodnutí. E-shop se stal zdrojem přijetí objednávek, podnikový systém zdrojem fakturačních a finančních stavů a skladový systém zdrojem skutečných zásob a plnění. Kromě toho bylo nutné stanovit, kdy je objednávka považována za zpracovatelnou, jak se řeší nedostatek zásob a kdo je oprávněn vytvářet výjimky.

Tato práce není tak viditelná jako spuštění nové integrace, ale zde se rozhoduje, kolik výjimek bude třeba později ručně opravovat. Dobré propojení systémů není dobré tím, že přenáší mnoho dat, ale tím, že všichni zúčastnění vidí stejný obchodní stav.

Kam patří která data?

Za většinou problémů s integrací stojí jednoduchá, ale nezodpovězená otázka: pokud se stejná data vyskytují ve více systémech, která jsou platná?

V tomto případě mohl název produktu a marketingový popis zůstat v e-shopu, ale zásoby, stav nákupu a možnost dodání byly spojeny se skladovým provozem. Fakturační údaje a stav plateb se vracely z podnikového systému. Ne všechna pole musela být zkopírována všude. Jen ta, která měla tam obchodní roli.

To snížilo počet datových konfliktů a také objasnilo řešení chyb. Pokud jsou zásoby chybné, nezačíná kolega z e-shopu pátrat ve třech systémech. Je vidět, kde vznikla odchylka a kdo je zodpovědný za opravu.

Řešení: cílené propojení, ne úplná výměna systému

Po průzkumu nebyl zaveden nový podnikový systém. Stávající systémy stále podporovaly základní obchodní potřeby a kompletní výměna by znamenala neodůvodněné riziko, náklady a provozní zátěž.

Místo toho mezivrstva integrace zajišťovala přenos objednávkových, skladových a stavových dat. Tato vrstva kontrolovala povinná pole, zaznamenávala pohyb dat a oddělovala případy, které vyžadovaly lidské rozhodnutí. Například neznámé číslo položky nebo nepochopitelný způsob dopravy se v procesu tiše neztratily. Systém vydal chybové hlášení a určený zaměstnanec viděl úkol na zvládnutelném seznamu výjimek.

Integrace nebyla spuštěna najednou. Nejprve byly na testovacích datech zkontrolovány stavy objednávek, sazby DPH, slevy, částečné dodávky a stornované doklady. Poté se provoz spustil s užším sortimentem a postupně s celým objemem.

Postupné zavádění nebylo zpomalením, ale ochranou obchodního provozu. V procesu objednávek přímo ovlivňuje zákazníka ztráta dat, dvojité fakturování položky nebo chybná indikace zásob. Proto k ostrému spuštění patřila možnost obnovení, zaznamenávání, systém oprávnění a jasný postup řešení chyb.

Co změnila integrace systémů v každodenní práci?

Nejviditelnějším výsledkem nebylo jen to, že bylo třeba ručně zadávat méně dat. Ranní kopírování objednávek skončilo, ale ještě důležitější bylo, že kolegové nezačínali den hledáním odchylek z předchozího večera.

Sklad rychleji získal seznam objednávek k zpracování. Zákaznický servis viděl stejný stav objednávek a plnění jako logistika. Finanční oddělení nemuselo žádat o samostatné seznamy refundací. Vedení dostalo report, který nebyl složen z několika souborů týdně.

Měřitelný dopad se liší podle společnosti, proto nemá smysl předem slibovat obecná procenta. V tomto typu situace však obvykle klesá čas věnovaný manuální kontrole, je méně oprav kvůli překlepům a zpracování objednávek se zrychluje. Méně kvantifikovatelný zisk je také významný: provoz není založen na paměti a každodenní pozornosti jednoho zkušeného člověka.

Co nestojí za automatizaci

Není třeba eliminovat všechny výjimky. Objednávka s vysokou hodnotou a specifickými podmínkami dopravy nebo podezřelá platební situace může vyžadovat lidské schválení. Cílem není, aby všechna rozhodnutí byla strojová, ale aby systém rozpoznal, co je normální obchodní proces a co skutečně vyžaduje pozornost.

Proto v integraci zůstaly vědomé kontrolní body. Objednávky přesahující limit dobírky, neúplné adresní údaje a určité případy nedostatku zásob byly přezkoumány. Rozdíl byl v tom, že zaměstnanci nekontrolovali každou objednávku, pouze ty, kde to mělo obchodní důvod.

Co je třeba rozpoznat ve vlastním provozu?

Projekt integrace systémů je oprávněný, pokud problém není chybou jednoho člověka nebo dočasným organizačním zmatkem, ale opakujícím se provozním vzorem. Takovým znakem je, když se stejná data vedou na více místech, když oddělení předávají e-mailem informace, které by měly být v systému, nebo když příprava týdenního reportu pro vedení trvá hodiny.

Hloubka řešení závisí na stabilitě stávajících systémů, kvalitě dat a počtu výjimek, které proces zpracovává. Někde stačí několik dobře definovaných datových propojení. Jinde je třeba nejprve dát do pořádku kmenová data, odpovědnosti nebo skladové procesy. Technologické rozhodnutí může být trvale dobré až poté.

Pokud ve rostoucí společnosti zaměstnanci pravidelně fungují jako spojovací článek mezi dvěma systémy, nemusí to nutně znamenat, že je potřeba více lidí. Často to naznačuje, že stojí za to prozkoumat samotnou cestu informací - než další růstový krok přidá do provozu ještě více ruční práce.