Príklad automatizácie toku objednávok v e-shope

Keď príde objednávka z e-shopu, niekto pošle údaje e-mailom alebo v Exceli do skladu. Kolega skontroluje platbu, prepíše fakturačné údaje, vytvorí štítok, zmení stav a nakoniec sa pokúsi informovať zákazníka. Toto funguje, pokiaľ ide o niekoľko objednávok denne. príklad automatizácie toku objednávok v e-shope sa stáva skutočne užitočným, keď rast znamená viac manuálnych krokov, viac výnimiek a čoraz ťažšie sledovateľné zodpovednosti.

Problém zvyčajne nie je v tom, že by nebolo dosť aplikácií. Skôr v tom, že medzi e-shopom, ERP, skladovým systémom, fakturáciou a kuriérskou službou udržujú tok informácií ľudia. Ak sa objednávka zasekne, často sa to zistí až vtedy, keď zákaznícka služba dostane sťažnosť. V takom prípade sa oplatí začať nie automatizačným nástrojom, ale otázkou: čo presne sa deje s objednávkou od platby po odovzdanie?

Kde sa prerušuje cesta objednávky?

V stredne veľkom obchode je spracovanie objednávok zriedka jediným procesom. Inú cestu môže mať objednávka na sklade, predobjednávka, dobierka, firemná faktúra alebo osobný odber. Propagačné balíky, čiastkové dodávky, refundácie a chyby v adresách zvyšujú počet variantov.

Preto je prvou chybou často to, že spoločnosť sa snaží spracovať všetky objednávky rovnakým spôsobom. V skutočnosti cieľom nie je, aby systém slepo prenášal všetky údaje, ale aby časté, jednoznačné prípady postupovali automaticky a neisté alebo obchodne citlivé prípady sa dostali k správnej osobe.

Oplatí sa sledovať konkrétnu objednávku nielen na obrazovkách systémov, ale aj v skutočnej práci. Kto rozhoduje o platobnej odchýlke? Odkiaľ vie sklad, že položka je ešte rezervovateľná? Kedy sa vystavuje faktúra? Čo sa stane, ak kuriérska služba neprijme adresu? Ak sú odpovede na tieto otázky založené na ústnom podaní alebo na pamäti skúseného kolegu, proces ešte nie je dostatočne pod kontrolou.

Príklad automatizácie toku objednávok v e-shope

Predpokladajme, že objednávky z e-shopu sa momentálne manuálne zaznamenávajú do ERP. Sklad pracuje odtiaľ, faktúra sa vytvára v treťom systéme a prepravné štítky sa vytvárajú na samostatnom rozhraní. Stav objednávky sa v e-shope často aktualizuje oneskorene, preto sa zákaznícka služba pýta na sklad telefonicky.

V tejto situácii nie je nevyhnutne nový e-shop alebo úplná výmena ERP dobrým prvým krokom. Menšia, dobre definovaná zmena môže byť, že schválená objednávka automaticky vytvorí alebo aktualizuje príslušný záznam objednávky v ERP. ERP zostáva centrálnym záznamom obchodného plnenia: odtiaľ pochádzajú údaje potrebné na rozhodnutie o zásobách, fakturácii a doprave.

Keď je objednávka spracovateľná, skladový systém dostane úlohu na vychystávanie. Po zostavení balíka sa prepravné údaje dostanú do kuriérskeho spojenia, štítok sa vráti do skladu a identifikátor balíka a príslušný stav sa aktualizuje v e-shope. Zákazník je tak informovaný nie z ručne zostaveného e-mailu, ale na základe skutočných plniacich udalostí.

Logika procesu je stručne organizovaná okolo piatich stavov:

• objednávka prijatá a technicky platná;
• platba alebo obchodné schválenie overené;
• zásoby rezervované a vytvorená úloha plnenia;
• balík pripravený na odovzdanie alebo odovzdaný dopravcovi;
• plnenie uzavreté, zaznamenané potrebné finančné a zákaznícke komunikačné údaje.

Názvy stavov sa môžu líšiť podľa spoločnosti. Dôležité je, aby každý stav mal jasný obchodný význam, zodpovednosť a systémový zdroj. Napríklad „v spracovaní“ nie je dobrý stav, ak raz znamená, že čakajú na platbu, inokedy, že balík je už v sklade.

Automatizácia nie je odstránenie výnimiek

V toku objednávok vždy budú výnimky. Produkt môže byť vypredaný, bankové potvrdenie môže meškať, adresa môže byť neúplná alebo zákazník môže chcieť zlúčiť viac objednávok. Tieto nie je vhodné skrývať za automatický proces.

Dobrý riešenie rozpozná, že konkrétna objednávka nemôže bezpečne pokračovať, zastaví ju na správnom mieste a vytvorí úlohu. Úloha musí byť viditeľná: kto ju dostane, na základe akých informácií rozhoduje, ako dlho objednávka čaká a čo sa stane po rozhodnutí. Toto nie je administratívny detail. Ak sa spracovanie výnimiek stane e-mailovým hľadaním, automatizácia len rýchlejšie generuje neistotu.

Osobitnú pozornosť si zaslúžia čiastočné chyby. Môže sa stať, že objednávka bola vytvorená v ERP, ale skladová úloha nie. Alebo prepravný štítok bol vytvorený, ale e-shop nedostal sledovací identifikátor. V takom prípade by systém nemal opakovane generovať duplicitné objednávky, faktúry alebo štítky.

Preto je v technickom návrhu potrebné mať jedinečné identifikátory, opakovateľné spracovanie a logovanie. Jednoducho povedané: neskôr musí byť možné zistiť, ktorý systém kedy, aké údaje odovzdal a prečo sa proces zastavil. Toto je súčasťou prevádzkovej kontroly, nielen otázkou vývoja.

Ktorý systém hovorí pravdu?

Mnoho chýb v objednávkach vyplýva z toho, že rovnaké údaje sa upravujú na viacerých miestach. V e-shope sa zmení adresa, v ERP zostane stará. Sklad pracuje z tabuľky, zatiaľ čo zásoby sa už zmenili. Fakturačný systém používa iné údaje o zákazníkovi, ako vidí zákaznícka služba.

Pre všetky dôležité údaje sa oplatí určiť vedúci systém. Pre produktové dáta, cenu, údaje o zákazníkovi, zásoby, stav objednávky a fakturačné údaje nemusí byť zdroj vždy rovnaký. To je v poriadku, ak je pravidlo vyslovené a synchronizácia ho nasleduje.

Zásoby sú obzvlášť citlivou oblasťou. Pri predaji cez e-shop nie sú vždy fyzické skladové zásoby predajné zásoby. Treba brať do úvahy už rezervované množstvo, produkty pod kontrolou kvality, tovar v procese prechodu a prípadne aj zásoby očakávané z nákupu. Ak sa tento rozdiel nevyjasní, automatizovaný prenos objednávok môže spôsobiť nadmerný predaj alebo neopodstatnené zastavenie.

Meranie nie je neskoršie vytváranie správ

Automatizovaný tok objednávok prináša hodnotu pre vedenie, ak zviditeľňuje prevádzku. Nestačí vedieť, koľko objednávok prišlo. Oplatí sa sledovať, koľko času uplynie medzi objednávkou a skladovým vydaním, koľko objednávok čaká na spracovanie výnimiek, ktorá chyba sa opakuje a kde sa hromadí práca.

Tieto údaje často vyvolávajú nepríjemné otázky. Možno nie je pomalá integrácia, ale denné schvaľovanie faktúr zdržuje objednávky. Môže sa tiež stať, že sklad nedostáva včas informácie o kampaniach. Cieľom merania nie je kontrolovať kolegov, ale pochopiť, kde sa oplatí proces zmeniť.

Pri zavádzaní je vhodné začať s dobre definovaným typom objednávky. Napríklad s objednávkami na sklade, vopred zaplatenými, s doručením v rámci krajiny. Tieto sú zvyčajne dobre regulovateľné a na základe skúseností je možné spresniť stavy, dátové polia a pravidlá spracovania chýb. Potom je možné zapojiť zložitejšie prípady.

Postupný prístup neznamená nevyhnutne spomalenie vývoja. Skôr znižuje pravdepodobnosť, že sa do systémov trvalo zabuduje nesprávne pochopený proces. V prístupe CGAT je integrácia a automatizácia hodnotná, ak sa pracovný poriadok za ňou stáva jasnejším, merateľnejším a udržateľnejším.

Dobrá prvá otázka teda nie je, ktorý nástroj spája e-shop s ERP. Skôr je to, že ak by zajtra prišlo dvakrát toľko objednávok, presne pri ktorom kroku by spoločnosť stratila kontrolu. Tam sa oplatí najprv urobiť poriadok.