Prodaja na webshopu, u POS-u i kroz druge kanale ne mora stvarati različita stanja zaliha. Polazište je jedno centralno stanje, jasna pravila rezervacije i poznat tijek svake promjene. Sinkronizacija zaliha tada ne služi kao povremeno kopiranje brojeva, nego prenosi događaje uz kontrolu kašnjenja, grešaka i iznimki.
Trgovac često vidi isti artikl na više mjesta: u ERP-u, webshopu, POS-u, skladištu ili na kanalu partnera. Ako svaki kanal samostalno mijenja količinu, razlike nastaju brzo. Webshop može prihvatiti narudžbu za zadnji komad, dok prodavač istodobno izdaje račun u poslovnici. Ručno usklađivanje tada kasni za stvarnim prometom.
Najčešći uzroci različitih stanja nisu samo tehnički prekidi. Problem može nastati zbog nejasnih poslovnih pravila:
Zato pitanje nije samo "koliko komada imamo". Važnije je razlikovati fizičku količinu, rezerviranu količinu i količinu raspoloživu za novu prodaju.
Prvi procesni izbor glasi: koji sustav vodi službeno stanje zaliha? U uređenom modelu jedan sustav ima ulogu vlasnika centralnog stanja. To je često ERP, jer u njemu mogu biti objedinjeni nabava, skladište, izdavanje, povrati i računovodstveni zapisi. Ipak, ulogu nije dovoljno pretpostaviti - potrebno ju je izričito definirati za svaki tok.
Vlasnik centralnog stanja treba primiti ili potvrditi događaje koji mijenjaju zalihu, primjerice:
Webshop, POS i drugi prodajni kanali mogu prikazivati raspoloživost i slati prodajne događaje, ali ne bi trebali neovisno stvarati konkurentsku verziju istine. Takva podjela odgovornosti pojednostavljuje provjeru: kada se pojavi razlika, tim zna gdje se provjerava službeni zapis i kojim putem je promjena trebala proći.
Kod Povezanog poslovanja važno je promatrati prodaju, skladište i financijske posljedice kao povezane procese, a ne kao odvojene ekrane. Promjena zalihe bez jasnog poslovnog dokumenta teško je objašnjiva i još teže se naknadno ispravlja.
Izraz "stanje zalihe" često pokriva nekoliko različitih količina. Za višekanalnu prodaju korisno je voditi barem sljedeće pojmove:
Jednostavan model raspoloživosti može polaziti od fizičke količine umanjene za aktivne rezervacije i blokiranu robu. No stvarna formula ovisi o poslovnim pravilima. Neki trgovci žele uračunati potvrđeni dolazak robe, dok drugi žele ponuditi samo robu koja je fizički raspoloživa. Oba pristupa traže jasno označene statuse i dosljednu primjenu kroz ERP, webshop i POS.
Posebnu pozornost zaslužuje trenutak rezervacije. Rezervacija nakon slanja narudžbe smanjuje rizik preprodaje, ali otvara pitanje plaćanja, provjere podataka i roka čuvanja robe. Rezervacija tek nakon potvrde plaćanja smanjuje broj blokiranih artikala, ali povećava mogućnost da drugi kanal proda isti artikl prije potvrde. Nema univerzalnog pravila. Potrebno je odabrati pravilo prema vrsti robe, načinu naplate i prihvatljivom operativnom riziku.
Periodično slanje cijelog stanja može biti korisno kao dodatna provjera, ali samo po sebi nije dovoljno za prometne kanale. Između dva slanja mogu nastati prodaja, otkaz, povrat ili korekcija. Zato sinkronizacija zaliha treba imati jasan tok događaja i odgovora.
Za svaki događaj korisno je znati:
Redoslijed je važan. Ako kanal obradi prodaju prije starije promjene stanja, prikazana raspoloživost može biti pogrešna iako su obje poruke tehnički stigle. Sustav stoga treba prepoznati duplikate, sačuvati vezu s izvornim događajem i spriječiti višestruko knjiženje iste promjene pri ponovnom slanju.
Kašnjenje sinkronizacije nije uvijek moguće potpuno ukloniti. Cilj procesa nije obećanje trenutačnog prijenosa u svakoj okolnosti, nego vidljivost kašnjenja i postupak za rad tijekom prekida. Primjerice, kanal može privremeno prikazivati konzervativniju raspoloživost, a tim može dobiti popis narudžbi koje čekaju potvrdu centralnog stanja.
Pretpostavimo da centralno skladište ima pet komada artikla. Dva komada već su rezervirana za potvrđene narudžbe. Prema pravilima, webshop i POS smiju nuditi tri komada.
Ako webshop primi novu narudžbu za dva komada, potrebno je odmah poslati zahtjev za rezervaciju vlasniku centralnog stanja ili primijeniti unaprijed dogovoreni mehanizam dodjele. Nakon potvrde rezervacije raspoloživost pada na jedan komad. Ako u istom trenutku POS pokuša prodati dva komada, sustav treba prepoznati nedostatnu raspoloživost i pokrenuti unaprijed definiran postupak - primjerice djelomičnu isporuku, alternativni artikl, kasniju isporuku ili ručnu provjeru.
Loš model samo ažurira broj na kanalima u određenom intervalu. U tom slučaju oba kanala mogu nakratko ponuditi tri komada. Dobar model ne pretpostavlja da se sukob neće dogoditi, nego određuje tko potvrđuje rezervaciju, koji događaj ima prednost i kako se bilježi odluka.
Nijedna integracija ne uklanja iznimke. Razlika je u tome ostaju li skrivene u e-pošti i tablicama ili ulaze u vidljiv radni red. Za višekanalnu prodaju korisno je definirati kategorije iznimki i odgovorne osobe.
Tipične iznimke uključuju:
Za svaku kategoriju potrebno je odrediti vlasnika obrade, rok interne provjere i dopuštenu korekciju. Važno je zadržati trag: izvorni događaj, učinjenu promjenu, osobu ili sustav koji je izvršio obradu te razlog odluke. Takav zapis pomaže pri operativnom rješavanju, inventuri i analizi ponavljajućih problema.
ERP webshop POS povezivanje ne počinje od konektora. Počinje od podataka i odluka. Prije povezivanja kanala vrijedi provjeriti:
Kompromis je često između veće prodajne dostupnosti i manjeg rizika od preprodaje. Agresivnija raspoloživost može povećati ponudu, ali traži pouzdaniju kontrolu rezervacija i spreman tim za iznimke. Konzervativniji sigurnosni fond smanjuje sukobe, ali može sakriti robu koja je stvarno dostupna. Pravu razinu treba odrediti prema vrijednosti artikala, brzini prometa, mogućnosti zamjenske isporuke i trošku pogreške.
Praktičan sljedeći korak nije odmah nova integracija, nego prolazak kroz jedan artikl od zaprimanja do povrata. Zabilježite gdje nastaje fizička količina, kada se stvara rezervacija, koji sustav potvrđuje raspoloživost, što se šalje svakom kanalu i tko rješava neuspjelo ažuriranje.
Takva mapa brzo otkriva ručne prijenose, dvostruke upise i nejasne odgovornosti. Ako planirate urediti višekanalnu prodaju ili provjeriti postojeći tok između ERP-a, webshopa i POS-a, Razgovarajte s ORKA timom o procesnim pravilima i točkama koje vrijedi razjasniti prije promjene sustava.