Prípadová štúdia systémovej integrácie v e-shope

Každé ráno niekto otvorí administratívne rozhranie e-shopu, stiahne nové objednávky a potom ich skopíruje do podnikateľského systému. Následne skontroluje zásoby v samostatnej tabuľke, pošle zoznam chýbajúcich položiek do skladu a opraví riadky, kde sa údaje líšia. Kým sa proces skončí, prídu nové objednávky. Tento prípadový štúdia systémovej integrácie nie je príbehom zle pracujúceho tímu. Naopak, je to príbeh zamestnancov, ktorí sa snažia udržať existujúci proces funkčný, zatiaľ čo spoločnosť z neho vyrastá.

Nasledujúci príklad ukazuje typickú, anonymizovanú rastúcu obchodnú prevádzku. Poučenie nie je, že na každý problém je odpoveďou nový systém alebo úplná výmena ERP. Podstatné je najprv pochopiť, kde sa prerušuje cesta informácií a prečo ľudia nahrádzajú spojenie medzi systémami.

Prípadová štúdia systémovej integrácie: keď objednávky cestujú ručne

Spoločnosť predávala tisíce produktov cez vlastný e-shop a niekoľko partnerských kanálov. E-shop, fakturačný program a skladová evidencia fungovali samostatne. Problémom bolo to, čo sa dialo medzi nimi.

Údaje o objednávkach sa dvakrát denne prenášali do podnikateľského systému. Informácie o zásobách sa oneskorene vracali do e-shopu, preto sa stávalo, že sa dal kúpiť produkt, ktorý už bol vypredaný. Pred fakturáciou kolegovia ručne kontrolovali údaje o zákazníkoch, spôsob dopravy a objednávky na dobierku. Ak zákazník zmenil adresu, zmena sa často prejavila len v jednom systéme.

Prvá otázka vedenia bola pochopiteľne: máme automatizovať spracovanie objednávok? Správna prvá otázka však bola iná: prečo treba tú istú objednávku trikrát kontrolovať a ktorý systém je spoľahlivým zdrojom daných údajov?

Tento rozdiel je podstatný. Ak technicky prepojíme neusporiadaný proces, integrácia len rýchlejšie prenesie chyby. Chybná logika zásob, neúplný kmeňový súbor alebo nejasná zodpovednosť sa nevyriešia tým, že prenos údajov bude automatický.

Skúmanie nezačalo rozhraním

Pri mapovaní procesu sa najprv nepozerali na to, aké API majú systémy. Sledovali, čo sa deje od prijatia objednávky až po odoslanie balíka, a potom až po dokončenie faktúry a reportu.

Ukázalo sa, že významná časť manuálnej práce nebola skutočným zadávaním údajov, ale riadením rizík. Zamestnanci kontrolovali každú objednávku, pretože nedôverovali údajom o zásobách. Viedli samostatnú tabuľku o problematických položkách, pretože v skladovom systéme nebolo možné ľahko filtrovať objednávky čakajúce na čiastočné dodanie. Komunikovali e-mailom s financiami, pretože stav refundácií sa nevrátil jednotne do zákazníckeho systému.

Skúmanie objasnilo štyri rozhodnutia. E-shop sa stal zdrojom prijatia objednávky, podnikateľský systém zdrojom fakturačných a finančných stavov a skladový systém zdrojom skutočných zásob a plnenia. Okrem toho bolo potrebné určiť, kedy sa objednávka považuje za spracovateľnú, ako sa rieši nedostatok zásob a kto je oprávnený vytvoriť výnimku.

Toto je menej viditeľná práca ako spustenie novej integrácie, ale tu sa rozhoduje, koľko výnimiek bude neskôr potrebné ručne opraviť. Dobrý systémový vzťah nie je dobrý tým, že presúva veľa údajov, ale tým, že všetci zainteresovaní vidia rovnaký obchodný stav.

Kam patrí ktorý údaj?

Za väčšinou problémov s integráciou stojí jednoduchá, ale nezodpovedaná otázka: ak ten istý údaj figuruje vo viacerých systémoch, ktorý je platný?

V tomto prípade mohol názov produktu a marketingový popis zostať v e-shope, ale zásoby, stav obstarávania a možnosť dodania sa viazali na skladové operácie. Fakturačné údaje a stav platby sa vracali z podnikateľského systému. Nie každý údaj bolo potrebné kopírovať všade. Iba ten, ktorý mal tam obchodnú úlohu.

To znížilo počet kolízií údajov a ujasnilo riešenie chýb. Ak sú zásoby chybné, pracovník e-shopu nezačne pátrať v troch systémoch. Je viditeľné, kde vznikla odchýlka a kto je zodpovedný za opravu.

Riešenie: cielené prepojenie, nie úplná výmena systému

Po prieskume nebol zavedený nový podnikový systém. Existujúce systémy ešte podporovali základné obchodné potreby a úplná výmena by znamenala neopodstatnené riziko, náklady a prevádzkové zaťaženie.

Namiesto toho medzivrstvová integrácia spracovávala prenos objednávkových, skladových a stavových údajov. Táto vrstva kontrolovala povinné polia, zaznamenávala pohyb údajov a oddelila prípady, ktoré vyžadovali ľudské rozhodnutie. Napríklad neznáme číslo položky alebo neinterpretovateľný spôsob dopravy sa v procese ticho nestratili. Systém vydal chybové hlásenie a určený pracovník videl úlohu v zozname spravovateľných výnimiek.

Integrácia nebola spustená naraz. Najprv boli na testovacích údajoch overené stavy objednávok, sadzby DPH, zľavy, čiastočné dodávky a stornované doklady. Potom sa prevádzka začala s užším sortimentom produktov a postupne s celým objemom.

Postupné zavedenie nebolo spomalením, ale ochranou obchodnej činnosti. V procese objednávky strata údajov, dvojité fakturovanie položky alebo nesprávne zobrazenie zásob priamo ovplyvňuje zákazníka. Preto k spusteniu patrila možnosť obnovenia, zaznamenávanie, oprávnenia a jasný postup riešenia chýb.

Čo zmenila systémová integrácia v dennej práci?

Najviditeľnejším výsledkom nebolo len to, že bolo potrebné ručne zaznamenávať menej údajov. Ranné kopírovanie objednávok sa skončilo, ale ešte dôležitejšie bolo, že kolegovia nezačínali deň hľadaním odchýlok z predchádzajúceho večera.

Sklad rýchlejšie získal zoznam objednávok na spracovanie. Zákaznícky servis videl rovnaký stav objednávky a plnenia ako logistika. Financie nemuseli žiadať samostatné zoznamy o refundáciách. Vedenie dostalo report, ktorý nevznikol spojením viacerých súborov týždenne.

Merateľný efekt sa líši podľa podniku, preto sa neoplatí vopred sľubovať všeobecné percentá. V tomto type situácie však zvyčajne klesá čas venovaný manuálnej kontrole, menej je opráv z dôvodu preklepov a spracovanie objednávok sa zrýchľuje. Menej kvantifikovateľný zisk je tiež významný: prevádzka sa neopiera o pamäť a dennú pozornosť jediného skúseného človeka.

Čo sa neoplatí automatizovať

Nie každú výnimku treba odstrániť. Objednávka s vysokou hodnotou, s jedinečnými dodacími podmienkami alebo podozrivá platobná situácia môže vyžadovať ľudské schválenie. Cieľom nie je, aby všetky rozhodnutia boli strojové, ale aby systém rozpoznal, čo je normálny obchodný proces a čo si skutočne vyžaduje pozornosť.

Preto v integrácii zostali vedomé kontrolné body. Objednávky presahujúce limit dobierky, neúplné adresné údaje a určité prípady nedostatku zásob boli predmetom revízie. Rozdiel bol v tom, že zamestnanci nekontrolovali každú objednávku, iba tie, kde to malo obchodný dôvod.

Čo je dobré rozpoznať vo vlastnej prevádzke?

Projekt systémovej integrácie je oprávnený, ak problém nie je chybou jediného človeka alebo dočasným organizačným zmätkom, ale opakujúcim sa prevádzkovým vzorom. Takýmto znakom je, keď sa ten istý údaj vedie na viacerých miestach, keď oddelenia odovzdávajú e-mailom informácie, ktoré by mali byť v systéme, alebo keď príprava týždenného reportu pre vedenie trvá hodiny.

Hĺbka riešenia závisí od toho, nakoľko sú existujúce systémy stabilné, aká je kvalita údajov a koľko výnimiek proces spracováva. Niekde postačuje niekoľko dobre definovaných dátových spojení. Inde je potrebné najprv dať do poriadku kmeňový súbor, zodpovednosti alebo skladový proces. Až potom môže byť technologické rozhodnutie trvalo dobré.

Ak v rastúcej spoločnosti zamestnanci pravidelne fungujú ako spojka medzi dvoma systémami, neznamená to nutne, že je potrebné viac ľudí. Často to naznačuje, že stojí za to preskúmať samotnú cestu informácií - skôr než ďalší rastový krok pridá ešte viac manuálnej práce do prevádzky.