Teprve po několika letech vývoje jsme umožnili uživatelům naší e-commerce platformy Edee.one editovat objednávky v administraci jejich e-shopu. Řekli byste si, že je to s podivem, že taková, na první pohled samozřejmá věc, není v systému dostupná od začátku. Stejný pocit měla i řada našich klientů, než jsme měli příležitost jim vysvětlit, jaké dopady taková funkce na systém i je osobně vlastně má. Tento článek je součástí naší snahy rozkrýt souvislosti v této oblasti.
Většinu našich e-shopů stavíme na kvalitně implementované integraci se zákazníkovým ERP. Stav (nejen) českých ERP je v oblasti API velmi tristní a možnost editovat objednávku na straně e-shopu často ztroskotá již tady. Aby bylo možné přenést změny objednávky, která byla do ERP exportována, je nutné aby:
Krom toho musí ERP poskytovat nějaký způsob, jak aktualizovanou objednávku do systému podruhé zapsat. Netriviální může být někdy i rozpoznání změn na jednotlivých řádcích objednávky.
Už tyto základní požadavky vyřadí možnost editace objednávky u celé řady ERP systémů ze hry.
Objednávka má své stanovené workflow, které často upravujeme podle požadavků zákazníka. V určité chvíli již není možné ovlivnit obsah objednávky, protože není prakticky možné změny do logistiky výdejního a rezervačního procesu zanést. Například v momentě, kdy je zboží zabaleno a expedováno, nesmí být možné objednávku upravit. U některých firem do procesu promlouvá i systém rezervací zboží na skladě nebo objednávání zboží od externích dodavatelů - určitě nikdo nemá zájem na sebe přebírat riziko objednání maloobrátkového zboží, které si zákazník nakonec neodebere.
Cenotvorba na e-shopech je často velmi složitá a na základě obsahu košíku a zvolené platby či dopravy jsou v průběhu výpočtu brány v potaz různé slevy či přirážky, platné ve chvíli, kdy je objednávka vystavena. Když po vystavení objednávky upravíme její obsah, jak se vlastně postavíme k těmto slevám? Zákazník dostal při objednávce nad 1 000 Kč dopravu zdarma, ale pak třetinu objednávky zrušil - ponecháme mu dopravu zdarma nebo ji budeme vyžadovat k doplacení? Podobná komplikace nastává u množstevních slev nebo produktových balíčků, kdy k jednomu zboží dostává zákazník jiné zboží zdarma nebo se slevou. Musíme si říct, jak se budeme stavět k časově omezeným cenám - pokud již akční cena na produkt není platná, umožníme zákazníkovi zvýšit množství zboží v objednávce za původní cenu nebo si bude kupovat zboží za cenu aktuální? Na toto rozhodnutí bude zcela jistě mít vliv třeba to, jestli jsme na dané zboží i my jako prodejci nedostali nějakou slevu, kterou v současné době už uplatnit nemůžeme. Ponechme stranou, že koncový zákazník může mít v různých chvílích přístup k různým ceníkům zboží.
Pokud koncový zákazník využije některou z online plateb, je velmi komplikované obsah objednávky měnit, protože se musí řešit způsob, jakým bude inkasován doplatek či kam se vrátí přeplatek. To klade zvýšené požadavky nejen na systém e-shopu, ale i operativní náklady na čas zaměstnanců, kteří budou změny v objednávce řešit - ne každá firma je na toto připravena. Vše jen komplikuje fakt, že obliba on-line plateb rok od roku stoupá (případně zde, nebo zde). Ve chvíli, kdy e-shop nabízí celou řadu platebních možností včetně kombinace s předplacenými kredity či vouchery, je domyšlení všech možností skvělou zábavou na dlouhé zimní večery. Navíc o peníze jde všem až v první řadě, takže každé zakodrcání v této oblasti koncoví zákazníci jistě rádi peprně okomentují na sociálních sítích nebo v hodnocení e-shopu na Heurece.
Jasně že ano, pokud si tedy zákazník do objednávky nepřihodí paletu dlaždic. Záměrně uvádíme extrémní příklad, ale pravidel, za jakých může být pro danou objednávku využita ta či ona doprava, je celá řada a naši klienti jsou v tomto ohledu velmi kreativní. Pokud se stane, že pro objednávku už nebude možné využít doručení na pobočku Zásilkovny či pošty a bude nutné ji doručit přímo na adresu zákazníka, je nutné tuto adresu v době změny objednávky znát. Problém nastává, když nám tuto adresu zákazník v procesu vystavení objednávky nesdělil, protože jsme ji ještě v tu chvíli nepotřebovali a nevyžadovali. Pak je potřeba od zákazníka zjistit řadu dalších údajů a komunikovat s ním v souvislosti se změnou / výběrem nové dopravy.
A to je ta klíčová otázka. Zkuste si udělat vlastní analýzu, kolik procent vašich koncových zákazníků potřebuje provádět změny v objednávkách a jaké změny nejčastěji potřebují? Jedná se o výjimečné případy? Pak zcela určitě doporučujeme jít cestou stornování původní objednávky a vystavení objednávky nové - ušetříte si řadu starostí a nákladů. Teprve pokud představují změny v objednávkách běžnou záležitost, vyplatí se investovat do lepší aplikační podpory a souvisejícího servisu.
Potřeba aktualizovat objednávku po jejím vystavení je u některých našich zákazníků příliš velká na to, abychom si mohli dovolit ji úplně ignorovat. V nové verzi Edee.one 8.3 jsme tedy přidali omezené možnosti editace objednávky v administračním rozhraní, které považujeme z našeho pohledu za bezpečné, pokud je bude provádět člověk se znalostí celé problematiky. Koncový zákazník e-shopu objednávku nemůže měnit přímo - předpokládá se kontakt s podporou na straně prodejce, která v administraci potřebné změny provede.
V administraci je možné až do zvoleného stavu workflow objednávky provést:
a do budoucna ještě plánujeme:
Systém se v této chvíli nesnaží být nikterak inteligentní - plná odpovědnost za domyšlení dopadů je na straně administrátora. Při vkládání nového zboží dopočítáme správně cenu s nebo bez DPH, nabídneme aktuální cenu u nově přidaného produktu, ale na související dopady aktuálně rezignujeme. Zajistíme však změny v rezervacích na skladech a export změn do ERP.
Co a kdy je na konkrétní implementaci u zákazníka editovatelné, nakonec nastavíme až po zjištění jeho možností a diskusí s ním a vše podřídíme tomu, abychom byli schopni domyslet dopady těchto otevřených možností. Často skončíme u původní možnosti, že editovat objednávku z objektivních důvodů prostě nelze. Někde umožníme upravit pouze adresy, ale už nikoliv obsah objednávky.
Na změnu v objednávce by měl být uživatel nějakou formou upozorněn. Ideální se pro tento účel zdá být e-mail s rekapitulací nového stavu objednávky včetně aktuální ceny s případnou poznámkou od prodejce, ve které by byla shrnuta komunikace ohledně změn objednávky mezi prodejcem a koncovým zákazníkem.
Ještě hezčí by bylo v notifikaci zvýraznit, jaké změny se v objednávce udály - tedy co, kde a jak se oproti původní objednávce změnilo. To si ale necháme až do některých příštích verzí naší platformy.
Při integraci Edee.one s ERP zákazníka se snažíme implementovat i reverzní proces aktualizace objednávky tak, aby všechny změny, které provede obsluha ERP, byly v krátké době viditelné na straně e-shopu a koncový zákazník si mohl ve svém účtu zpětně dohledat reálné stavy toho, co se v dané objednávce skutečně odehrálo.
Pokud tedy ERP zákazníka neposkytuje API pro aktualizaci objednávky, je toto často jediná možnost, jak změny v objednávkách provádět - tedy přímým zápisem do ERP, odkud si je e-shop nakonec převezme.
I tak se ale najdou ERP systémy, se kterými nelze naimplementovat ani tento reverzní proces synchronizace. Těm v naší hantýrce říkáme “černá díra”. Jen tak pro zajímavost - víte, že se integrujeme s jedním ERP systémem, který dosud běží pouze pod MS DOS?
Jan Novotný, Senior Application Developer
