Příklad automatizace toku objednávek v e-shopu

Objednávka z e-shopu dorazí a někdo e-mailem nebo v Excelu předá údaje do skladu. Kolega zkontroluje platbu, přepíše fakturační údaje, vytvoří štítek, změní status a nakonec se pokusí informovat zákazníka. To funguje, dokud jde o několik objednávek denně. příklad automatizace toku objednávek v e-shopu se stává opravdu užitečným, když růst znamená více manuálních kroků, více výjimek a stále obtížněji sledovatelné odpovědnosti.

Problém obvykle není v tom, že by nebylo dost aplikací. Spíše v tom, že mezi e-shopem, ERP, skladovým systémem, fakturací a kurýrní službou udržují tok informací lidé. Pokud se objednávka zasekne, často se to zjistí až ve chvíli, kdy zákaznický servis obdrží stížnost. V takovém případě není vhodné začít s automatizačním nástrojem, ale s otázkou: co přesně se děje s objednávkou od platby po předání?

Kde se přeruší cesta objednávky?

U středně velkého obchodníka je zpracování objednávek zřídka jedním procesem. Jinou cestu může mít objednávka na skladě, předobjednávka, dobírka, firemní faktura nebo osobní odběr. Propagační balíčky, částečné dodávky, vrácení peněz a chyby v adresách dále zvyšují počet variant.

Proto je první chybou často to, že se firma snaží zpracovat všechny objednávky stejným způsobem. Ve skutečnosti není cílem, aby systém slepě přenášel všechna data, ale aby časté, jednoznačné případy probíhaly automaticky a nejisté nebo obchodně citlivé případy se dostaly k příslušné osobě.

Je vhodné sledovat konkrétní objednávku, nejen na obrazovkách systémů, ale i v reálné práci. Kdo rozhoduje o platební odchylce? Jak sklad ví, že položka je stále dostupná? Kdy se vystaví faktura? Co se stane, pokud kurýrní služba nepřijme adresu? Pokud jsou odpovědi na tyto otázky založeny na ústním podání nebo paměti zkušeného kolegy, proces ještě není dostatečně pod kontrolou.

Příklad automatizace toku objednávek v e-shopu

Předpokládejme, že objednávky z e-shopu se aktuálně ručně zaznamenávají do ERP. Sklad s nimi pracuje, faktura se vytváří v jiném systému a přepravní štítky se vytvářejí na jiné platformě. Stav objednávky se v e-shopu často aktualizuje se zpožděním, takže zákaznický servis se na sklad dotazuje telefonicky.

V této situaci nemusí být nutně novým e-shopem nebo úplnou výměnou ERP dobrým prvním krokem. Menší, dobře definovanou změnou může být, že schválená objednávka automaticky vytvoří nebo aktualizuje odpovídající záznam objednávky v ERP. ERP zůstává centrálním záznamem pro obchodní plnění: odtud pocházejí údaje pro sklad, fakturaci a rozhodování o přepravě.

Když je objednávka zpracovatelná, skladový systém obdrží úkol pro komisionování. Po sestavení balíku se přepravní údaje dostanou do kurýrního spojení, štítek se vrátí do skladu a identifikátor balíku a odpovídající status se aktualizují v e-shopu. Zákazník tak není informován z ručně sestaveného e-mailu, ale na základě skutečných událostí plnění.

Logika procesu je stručně organizována kolem pěti stavů:

• objednávka přijata a technicky platná;
• platba nebo obchodní schválení ověřeno;
• sklad rezervován a úkol plnění vytvořen;
• balík připraven k předání nebo předán dopravci;
• plnění uzavřeno, potřebné finanční a zákaznické komunikační údaje zaznamenány.

Názvy statusů se mohou lišit podle společnosti. Důležité je, aby každý stav měl jasný obchodní význam, odpovědnost a systémový zdroj. Například „zpracování“ není dobrý stav, pokud jednou znamená čekání na platbu a jindy, že balík je již ve skladu.

Automatizace není odstranění výjimek

V toku objednávek budou vždy výjimky. Produkt může být vyprodán, bankovní potvrzení může být zpožděno, adresa může být neúplná nebo zákazník může chtít sloučit více objednávek. Tyto situace není vhodné skrývat za automatický proces.

Dobré řešení rozpozná, že konkrétní objednávka nemůže bezpečně pokračovat, zastaví ji na správném místě a vytvoří úkol. Úkol musí být viditelný: kdo jej obdrží, na základě jakých informací rozhoduje, jak dlouho objednávka čeká a co se stane po rozhodnutí. To není administrativní detail. Pokud se řešení výjimek stane hledáním v e-mailech, automatizace jen rychleji vytváří nejistotu.

Zvláštní pozornost si zaslouží částečné chyby. Může se stát, že objednávka byla vytvořena v ERP, ale skladový úkol ne. Nebo byl vytvořen přepravní štítek, ale e-shop neobdržel sledovací identifikátor. V takových případech by systém neměl znovu a znovu generovat duplicitní objednávky, faktury nebo štítky.

Proto je v technickém návrhu potřeba jedinečných identifikátorů, opakovatelného zpracování a logování. Jednoduše řečeno: později musí být možné říci, který systém kdy, jaká data předal a proč se proces zastavil. To je součástí provozní kontroly, nejen otázka pro vývojáře.

Který systém říká pravdu?

Mnoho chyb v objednávkách vyplývá z toho, že stejná data se upravují na více místech. V e-shopu se změní adresa, v ERP zůstane stará. Sklad pracuje s tabulkou, zatímco zásoby se již změnily. Fakturační systém používá jiné zákaznické údaje než ty, které vidí zákaznický servis.

U každého důležitého údaje je vhodné určit vedoucí systém. U produktového kmenového souboru, cen, zákaznických údajů, zásob, statusu objednávky a fakturačních údajů nemusí být vždy stejný zdroj. To je v pořádku, pokud je pravidlo vyslovené a synchronizace ho následuje.

Zásoby jsou obzvláště citlivou oblastí. U prodeje přes e-shop není vždy fyzická skladová zásoba tou prodejnou zásobou. Je třeba zohlednit již rezervované množství, produkty pod kontrolou kvality, zboží v procesu převodu a případně i zásoby očekávané z nákupu. Pokud tento rozdíl není vyjasněn, automatizovaný přenos objednávek může způsobit nadměrný prodej nebo neopodstatněné zastavení.

Měření není dodatečné vytváření zpráv

Automatizovaný tok objednávek poskytuje manažerskou hodnotu, pokud zviditelňuje provoz. Nestačí vědět, kolik objednávek dorazilo. Je vhodné sledovat, kolik času uplyne mezi objednávkou a vydáním ze skladu, kolik objednávek čeká na řešení výjimek, která chyba se opakuje a kde se hromadí práce.

Tyto údaje často přinášejí nepříjemné otázky. Možná není integrace pomalá, ale denní schválení faktur zdržuje objednávky. Může se také stát, že sklad nedostává včas informace o kampaních. Cílem měření není kontrola kolegů, ale pochopení, kde je vhodné proces změnit.

Při zavádění je vhodné začít s dobře vymezeným typem objednávky. Například s objednávkami na skladě, předem zaplacenými, s dodáním v tuzemsku. Tyto objednávky jsou obvykle dobře regulovatelné a na základě zkušeností lze upřesnit statusy, datová pole a pravidla pro řešení chyb. Poté lze zapojit složitější případy.

Postupný přístup nutně nezpomaluje vývoj. Spíše snižuje pravděpodobnost, že se špatně pochopený proces trvale integruje do systémů. V přístupu CGAT je integrace a automatizace cenná, pokud se pracovní postup za ní stává jasnějším, měřitelnějším a udržitelnějším.

Dobrá první otázka tedy není, který nástroj propojí e-shop s ERP. Spíše je to, pokud by zítra dorazilo dvakrát tolik objednávek, v jakém kroku by firma ztratila kontrolu. Tam je vhodné nejprve udělat pořádek.