Koristne informacije ...

Primer integracije spletne aplikacije z logistiko

Ko prodajna ekipa potrdi naročilo, skladišče pa zanj izve šele iz e-pošte ali preglednice, se napake ne pojavijo zaradi pomanjkanja truda. Nastanejo zato, ker sistemi ne govorijo med seboj. Dober primer integracije spletne aplikacije z logistiko pokaže, kako lahko naročilo iz spletne aplikacije samodejno sproži pripravo pošiljke, posodobi zalogo in kupcu vrne pravi status dostave.

To ni funkcija, ki bi bila zanimiva le velikim spletnim trgovinam. Za specializiranega trgovca, distributerja ali podjetje z lastnim prodajnim portalom je povezava z logistiko pogosto razlika med operativno preglednostjo in vsakodnevnim gašenjem požarov. Smisel integracije ni v tem, da je vse povezano za vsako ceno, ampak da se podatki premikajo takrat, ko to poslovni proces res potrebuje.

Kdaj logistična integracija postane nujna

Podjetje lahko v začetni fazi naročila še obvladuje ročno. Nekdo izvozi seznam naročil, ga pošlje v skladišče, preveri zalogo in kupcu naknadno sporoči številko za sledenje. Tak postopek pa hitro pokaže meje, ko se poveča število naročil, razširi ponudba ali ko prodajate prek več kanalov.

Največ težav se praviloma pojavi pri zalogi. Kupec v aplikaciji vidi izdelek kot dobavljiv, v skladišču pa ga ni več. Druga pogosta težava so napačni naslovi, podvojena naročila in ročno prepisovanje podatkov v sistem dostavne službe. Vsak dodaten ročni korak pomeni čas, strošek in možnost napake.

Integracija je smiselna tudi, kadar spletna aplikacija ni klasična trgovina. B2B portal lahko poslovnim kupcem omogoča naročanje po pogodbenih cenah, servisna aplikacija lahko naroča rezervne dele, interna aplikacija pa lahko usmerja material med lokacijami. Logistika je v vseh teh primerih del storitve, ne samo zaključni korak po prodaji.

Primer integracije spletne aplikacije z logistiko v praksi

Predstavljajmo si podjetje, ki prodaja tehnično opremo poslovnim kupcem. Kupec se prijavi v spletno aplikacijo, vidi njemu prilagojen cenik, odda naročilo in izbere dostavo na svojo poslovalnico. Podjetje ima zunanje skladišče, ki uporablja svoj skladiščno-logistični sistem, dostavo pa opravlja pogodbeni prevoznik.

Brez integracije bi administracija naročilo preverila, ročno prepisala podatke v logistični sistem in po odpremi še ročno posodobila status v aplikaciji. Pri nekaj naročilih na dan je postopek še izvedljiv. Pri več deset naročilih pa postane ozko grlo prav človek med sistemi.

S povezavo po meri se postopek spremeni. Ko kupec odda naročilo, spletna aplikacija preveri osnovne podatke: dostavni naslov, razpoložljivost artiklov, pogoje plačila in morebitne omejitve naročanja. Nato v logistični sistem pošlje naročilo s podatki, ki jih skladišče dejansko potrebuje - šiframi artiklov, količinami, prioritetami, načinom dostave in kontaktnimi podatki.

Logistični sistem naročilo sprejme, ga pripravi za komisioniranje in vrne potrditev. Ko skladišče pošiljko odpremi, se v spletno aplikacijo prenesejo številka pošiljke, povezava do sledenja in nov status. Kupec tako v svojem uporabniškem računu ne vidi splošnega zapisa »v obdelavi«, temveč realno stanje: naročilo je potrjeno, pripravljeno, odpremljeno ali dostavljeno.

Vzporedno se posodablja zaloga. Če je izdelek rezerviran za naročilo, aplikacija to upošteva takoj. Če skladišče zazna razliko med evidentirano in dejansko zalogo, mora sistem razliko zapisati, označiti za pregled ali omejiti nadaljnje naročanje. Pravilno zasnovana integracija ne skriva takšnih odstopanj. Pokaže jih pravočasno, da lahko podjetje ukrepa.

Podatki morajo imeti jasnega lastnika

Najpogostejša napaka ni tehnična, ampak organizacijska. Podjetje poveže dva sistema, ne določi pa, kateri je glavni vir posameznega podatka. Posledica so različni podatki o zalogi, kupcih ali statusih naročil, nato pa iskanje krivca med ponudniki.

Dobra zasnova že na začetku jasno določi pravila. Spletna aplikacija je lahko glavni vir za kupce, dostavne naslove in oddana naročila. Logistični sistem je običajno glavni vir za fizično zalogo, pakiranje, odpremo in dejansko dostavo. Računovodski ali ERP-sistem pa je lahko glavni vir za artikle, cene, račune in finančne statuse.

To ne pomeni, da se podatki ne smejo podvajati. Pomeni le, da je za vsak podatek določeno, kje nastane in kje se potrjuje njegova pravilnost. Integracija nato poskrbi za prenos tistih podatkov, ki jih drugi sistem potrebuje za svoje delo.

Statusi niso le tehnična oznaka

Status naročila je dober primer. Spletna aplikacija in logistični sistem lahko uporabljata različna poimenovanja. Logistika ima morda statuse »released«, »picked«, »packed« in »shipped«, kupec pa potrebuje razumljiva sporočila v slovenščini.

Zato je treba statuse preslikati. »Picked« lahko za kupca pomeni »v pripravi«, »packed« pa »pripravljeno za odpremo«. Pri tem ni treba prikazati vsakega notranjega koraka. Prikazati je treba tisto, kar kupcu pomaga razumeti, kaj se dogaja z njegovim naročilom, podporni ekipi pa olajša odgovor na vprašanja.

Integracija ni samo povezava API-jev

API je način, kako si sistema izmenjujeta podatke. Sam po sebi pa ne reši poslovnih pravil. Pred razvojem je treba popisati dejanski tok naročila: kaj se zgodi ob oddaji, kdo lahko naročilo spremeni, kako se obravnavajo delne dobave, kaj pomeni preklic in kaj se zgodi, ko prevoznik pošiljke ne more dostaviti.

Pri delnih dobavah se na primer hitro pokaže razlika med lepo predstavitvijo in uporabno rešitvijo. Če so trije artikli na zalogi, eden pa čaka na dobavo, mora podjetje odločiti, ali bo poslalo dve pošiljki, počakalo na celotno naročilo ali kupcu ponudilo izbiro. To ni odločitev programskega jezika. Je poslovna odločitev, ki jo mora aplikacija nato pravilno podpreti.

Enako velja za vračila. Če kupec vračilo prijavi v aplikaciji, se lahko samodejno ustvari zahtevek, skladišče prejme obvestilo, kupec pa navodila za pošiljanje. Kadar je proces vračil redek in preprost, je morda dovolj dobro zasnovan administrativni postopek. Kadar vračila pomenijo pomemben delež dela, je avtomatizacija upravičena.

Kaj mora rešitev predvideti že pred zagonom

Logistični sistemi niso vedno dosegljivi. Lahko je moten API prevoznika, skladišče lahko zamuja z odgovorom, povezava pa lahko pošlje isti zahtevek dvakrat. Kakovostna integracija zato potrebuje nadzor, ne le začetne povezave.

To v praksi pomeni zapisovanje pomembnih prenosov, prepoznavanje podvojenih naročil, varno ponovno pošiljanje neuspešnih zahtevkov in opozorilo ekipi, kadar nekaj zahteva ročni pregled. Namen ni ustvariti zapletenega nadzornega centra. Namen je, da napaka ne ostane nevidna, dokler je ne opazi nezadovoljen kupec.

Pomembna je tudi varnost. Izmenjujejo se osebni podatki kupcev, dostavni naslovi, včasih poslovne cene in podatki o zalogi. Dostopi morajo biti omejeni, komunikacija zaščitena, administrativne pravice pa prilagojene vlogam uporabnikov. Pri rešitvah po meri je to mogoče oblikovati glede na dejansko organizacijo podjetja, namesto da se proces prilagaja omejitvam generične platforme.

Začnite z najdražjo ročno nalogo

Ni nujno, da projekt takoj zajame vsak logistični scenarij. Pogosto je bolj pametno začeti tam, kjer ročno delo povzroča največ napak ali zamud: pri prenosu naročil v skladišče, usklajevanju zaloge ali vračanju številk za sledenje.

Prva faza mora biti dovolj uporabna, da razbremeni ekipo, hkrati pa dovolj pregledna, da lahko preverite podatke v realnem procesu. Nato se lahko rešitev razširi na vračila, več skladišč, prioritete dostave, posebne B2B pogoje ali napovedovanje dobavljivosti.

Pri Moxy Web takšne povezave obravnavamo kot del celotne spletne rešitve, ne kot dodatek, ki ga je treba na silo priključiti ob koncu projekta. Dizajn uporabniškega vmesnika, administracija, poslovna pravila in tehnična povezava morajo podpirati isti cilj: da naročilo od kupca do skladišča potuje jasno, sledljivo in brez nepotrebnega ročnega dela.

Najboljša integracija ni tista z največ funkcijami. Je tista, pri kateri ekipa neha prepisovati podatke, kupec pravočasno dobi zanesljivo informacijo, vodstvo pa končno vidi, kje se proces zares ustavlja. To je dober razlog, da logistiko načrtujete že ob zasnovi spletne aplikacije, ne šele takrat, ko ročni postopki postanejo predragi.