Zaloge v realnem času pri B2B trgovini: kdaj nočna sinhronizacija ne zadošča

250 kosov v košarici, 47 v skladišču. Naročilo ni mogoče.

B2B kupec naroči 250 kosov izdelka. Spletna trgovina je prikazovala "na zalogi". Ko je naročilo prišlo v skladišče, so na polici našli 47 kosov. Razlika je nastala, ker je drug kupec dva dni prej kupil 200 kosov, sinhronizacija zaloge pa je tekla enkrat na dan, ponoči.

Pri B2C trgovini bi se to redko zgodilo, ker so naročila majhna. En kupec vzame 1 ali 2 kosa, razlika med dejansko zalogo in spletno je nekaj enot. Pri B2B je vsako naročilo lahko pet do dvajsetkrat večje od povprečnega B2C nakupa. Zamik 24 ur pomeni, da spletna trgovina ne ve, da je polovica zaloge že prodana.

Posledica ni samo en napačno sprejet nakup. Posledica je, da kupec, ki je računal na takojšnjo dobavo, dobi obvestilo: "Žal, dejansko stanje je drugačno." Naslednjič ne bo več naročil prek spleta. Pošlje povpraševanje komercialistu in vpraša, koliko je dejansko na zalogi. Trgovina je s tem izgubila uporabnika.

Zakaj B2C model sinhronizacije ne deluje za B2B

Standardni način sinhronizacije zaloge med spletno trgovino in skladiščnim sistemom je preprost. Vsako uro ali enkrat dnevno gre paket podatkov iz ERP v trgovino. Trgovina ima približno sliko zaloge in to zadošča, dokler so naročila majhna.

Pri B2B se to zalomi v treh točkah:

• Eno samo naročilo lahko zniža zalogo pod nič
• Več kupcev dela paralelno z istim artiklom
• Skladišče ima zalogo v več lokacijah in samo del je dostopen za določeno regijo strank

Ko spletna trgovina kaže stanje izpred 6 ali 24 ur, to za B2B kupca pomeni resne napake pri naročanju. Kupec naroči 300, sistem sprejme, čez dva dni se izkaže, da je dobava zamaknjena za 14 dni. To ni tehnična malenkost, je operativni problem.

Kaj pomeni "v realnem času"

Realni čas v praksi pomeni nekaj sekund do nekaj minut zamika, nikoli sekundne natančnosti. V rabi so trije pristopi.

Trgovina vpraša ERP ob vsakem prikazu

Najbolj točen, najbolj počasen. Ko kupec odpre stran izdelka, trgovina pošlje vprašanje ERP-ju in počaka odgovor. Pri katalogu z več tisoč artikli in 100 hkratnimi uporabniki to pomeni 100.000 vprašanj na uro. Večina ERP sistemov tega ne zdrži in postanejo počasni za interno rabo.

V praksi se ta pristop uporablja samo na strani izdelka in v košarici, ne pa pri seznamu kategorije. V kategoriji se prikaže "preverite zalogo" ali pa približna številka iz predpomnilnika.

Predpomnilnik s kratko življenjsko dobo

Trgovina hrani zalogo v lastni bazi in jo osveži vsakih 5, 10 ali 30 minut, odvisno od narave artiklov. Hitri artikli (potrošni material, akcije) se osvežujejo pogosteje, počasni (posebni izdelki, ki gredo enkrat mesečno) redkeje.

To je pristop, ki deluje za 90 odstotkov B2B trgovin. Zamik je dovolj kratek, da so napake zelo redke, in obremenitev ERP-ja je sprejemljiva. Pri napaki sistem zazna razliko ob potrditvi naročila in obvesti kupca pred plačilom.

ERP javlja spremembe ob vsakem dogodku

Ko se v ERP-ju zgodi sprememba zaloge (prodaja, vračilo, prevzem dobave), ERP javi trgovini novo stanje. Trgovina ne sprašuje, ampak posluša. Temu tehnično pravimo webhook ali objavljanje dogodkov.

Najbolj eleganten pristop, vendar ne deluje pri vseh ERP sistemih. Modernejši (Pantheon, Microsoft Business Central, Odoo) imajo to možnost. Starejši (RCL, nekateri Vasco moduli) tega ne podpirajo brez dodatnega vmesnika.

Rezervacija zaloge namesto klica v realnem času

Pri B2B je bolj kot prikaz zaloge pomembno, da kupec lahko zalogo rezervira. Ko kupec doda 200 kosov v košarico, se ti odštejejo iz razpoložljive zaloge za naslednjega kupca. Drugi kupec vidi zmanjšano zalogo, čeprav prvi še ni potrdil naročila.

Rezervacija velja določen čas, na primer 30 minut. Če prvi kupec ne potrdi nakupa, se zaloga vrne. Če potrdi, se rezervacija pretvori v dejansko prodajo in se posreduje v ERP.

To rešuje 80 odstotkov problema, ne da bi bilo treba postaviti komunikacijo v realnem času z ERP-jem. Trgovina vodi svoj števec rezervacij in se z ERP-jem usklajuje enkrat na uro ali pri spremembah. Kupci nikoli ne vidijo zaloge, ki jo je medtem nekdo drug vzel.

Pri tem pristopu mora ERP poznati koncept rezervacije. Če ne pozna, vmesni sistem prevzame to vlogo in z ERP komunicira v paketih.

Več skladišč, ena zaloga

Veleprodajno podjetje ima pogosto dve ali tri skladišča. Zagreb, Ljubljana, Velenje. Stranka iz Maribora dobi blago iz Ljubljane, stranka iz Hrvaške iz Zagreba. Spletna trgovina mora prikazati zalogo, ki je dejansko dostopna kupcu, ne skupne zaloge vseh skladišč.

Prikaz zaloge zato ne odgovarja na vprašanje "koliko je v sistemu", temveč "koliko je za to stranko v njeni regiji". Pri pogodbenih strankah, ki imajo dogovorjeno dostavo iz določenega skladišča, je ta logika fiksna. Pri drugih kupcih sistem izbere najbližje ali najugodnejše skladišče.

Brez tega prikaza kupec naroči, sistem rezervira, in šele pri pripravi se ugotovi, da v njegovem skladišču ni dovolj. Naročilo se razdeli, dobava zamakne, kupec ni zadovoljen.

Kdaj kateri model izbrati

Okvirno pravilo, ki velja v praksi:

• Manj kot 50 naročil dnevno, povprečno naročilo 1 do 5 kosov: zadošča sinhronizacija na 1 do 4 ure
• 50 do 200 naročil dnevno, povprečno 10 do 50 kosov: predpomnilnik s 5- do 15-minutnim ritmom in rezervacija v košarici
• Več kot 200 naročil dnevno ali povprečno naročilo nad 50 kosov: webhook iz ERP-ja ali aktivni predpomnilnik z 1-minutnim ritmom
• Več skladišč in regijska logika: ne glede na obseg, lokalna baza s sinhronizacijo na dogodek

Investicija raste s kompleksnostjo. Postavitev s 5-minutno sinhronizacijo in rezervacijo v košarici stane med 1.500 in 3.500 evrov dodatno. Webhook integracija z ERP, kjer ERP to podpira, je 2.500 do 5.000 evrov. Lastni vmesni sistem za starejše ERP, kjer je treba postaviti dnevnik dogodkov, je 4.000 do 8.000 evrov.