Izbor između real-time i batch sinhronizacije zaliha zavisi od brzine prodaje, broja prodajnih kanala, pouzdanosti izvornog sistema i posledica pogrešnog podatka. Real-time pristup prenosi promenu čim se dogodi ili u veoma kratkom intervalu, dok batch pristup preuzima i obrađuje podatke periodično — na primer na svakih nekoliko minuta, jednom na sat ili jednom dnevno.
Ni jedan model nije automatski bolji. Za web shop sa ograničenim brojem porudžbina i dovoljno stabilnim stanjem magacina, dobro projektovan batch može biti jednostavniji i sasvim dovoljan. Kada se ista zaliha prodaje kroz više kanala, kada je proizvod često pri kraju ili kada kašnjenje može da dovede do preprodaje, real-time ili hibridni model ima više smisla. U praksi je najvažnije prvo definisati koji sistem je izvor istine, šta se sinhronizuje i koliko kašnjenje poslovanje može da podnese.
Šta zapravo znači sinhronizacija zaliha
Sinhronizacija zaliha nije samo prikaz broja komada na stranici proizvoda. To je tok podataka između web shopa i jednog ili više sistema, kao što su ERP, magacin, računovodstveni program, marketplace ili fizička prodavnica. U tom toku treba jasno razdvojiti:
- raspoloživu zalihu — količinu koju kupac može da naruči;
- rezervisanu zalihu — robu vezanu za porudžbine koje još nisu završene;
- fizičko stanje — količinu evidentiranu u magacinu;
- stanje po lokacijama — robu u centralnom, maloprodajnom ili eksternom skladištu;
- stanje u tranzitu — robu koja je poslata, ali još nije primljena ili razdužena.
Ako web shop prikazuje samo jednu vrednost, a ERP raspolaže sa više tipova stanja, integracija mora da sadrži pravilo za izračunavanje prodajne količine. Na primer, dostupna količina može biti fizičko stanje umanjeno za rezervacije i sigurnosnu zalihu. To pravilo je poslovna odluka, a ne samo tehnički detalj.
Real-time sinhronizacija: kada je opravdana
Real-time model reaguje na događaj ili proverava izvorni sistem dovoljno često da promena bude dostupna gotovo odmah. Događaj može biti nova porudžbina, otkazivanje, povraćaj, prijem robe ili ručna korekcija. U zavisnosti od sistema, komunikacija se može zasnivati na API pozivu, webhook događaju ili kombinaciji događaja i naknadne provere.
Ovaj pristup je opravdan kada mala razlika u vremenu može da napravi operativni ili finansijski problem. Tipični primeri su:
- proizvodi sa malom zalihom i brzom prodajom;
- prodaja istog artikla kroz web shop, fizičku prodavnicu i marketplace;
- ograničene serije, sezonska roba ili proizvodi sa čestim rasprodajama;
- artikli kod kojih je otkazivanje zbog nedostupnosti posebno skupo za korisničko iskustvo;
- više magacina iz kojih se automatski bira lokacija za isporuku.
Prednost nije samo u brzini prikaza. Pravovremena promena može sprečiti da dva kanala istovremeno prihvate poslednji komad. Ipak, real-time ne znači da je sistem apsolutno bez kašnjenja. Mreža, API ograničenja, redovi za obradu i privremeni prekidi mogu da odlože poruku. Zato se uz real-time tok planiraju ponovni pokušaji, evidencija grešaka i periodična kontrolna sinhronizacija.
Rizici real-time modela
Najčešća greška je pretpostavka da je dovoljno povezati dva API-ja. Pouzdana integracija mora da zna šta se dešava kada poruka stigne dva puta, kada stigne van redosleda ili kada ciljni sistem privremeno nije dostupan.
- Duplirana poruka: ista promena ne sme dvaput da umanji zalihu.
- Promašen događaj: sistem mora da omogući proveru i naknadno usklađivanje.
- Konflikt izvora: ručna izmena u web shopu ne sme nepredvidivo da pregazi stanje iz ERP-a.
- Prevelik broj poziva: učestalo čitanje podataka može naići na ograničenja platforme ili opteretiti integraciju.
- Nejasna rezervacija: treba definisati da li se zaliha rezerviše pri kreiranju porudžbine, uplati ili drugom događaju.
Batch sinhronizacija: kada je dovoljno dobra
Batch pristup prikuplja promene u intervalima. Umesto da se svaka promena šalje odmah, sistem u određenom trenutku preuzima ili šalje skup podataka. Batch može biti jednostavan dnevni uvoz, ali i češće ažuriranje na svakih nekoliko minuta. Zato nije korisno posmatrati ga samo kao „sporu“ varijantu — presudan je interval, obim podataka i način rešavanja grešaka.
Ovaj model često odgovara kada:
- asortiman nije podložan brzoj rasprodaji;
- web shop koristi jedan glavni kanal prodaje;
- stanje se menja sporije nego što traje interval sinhronizacije;
- izvorni sistem nema pouzdane webhook događaje;
- potrebno je periodično osvežavanje kataloga, cena i zaliha u većim paketima.
Prednost batch pristupa je kontrolisaniji tok i često jednostavnija dijagnostika. Moguće je obraditi paket, sačuvati izveštaj i ponoviti samo neuspele stavke. Mana je prozor u kome podatak nije ažuran. Ako je interval 30 minuta, porudžbina nastala neposredno posle poslednjeg uvoza može neko vreme ostati neusklađena sa stvarnim stanjem.
Real-time ili batch: kriterijumi za odluku
Pre izbora tehnologije treba odrediti maksimalno prihvatljivo kašnjenje. To je poslovni zahtev, ne broj koji se bira samo prema mogućnostima platforme.
| Kriterijum | Real-time ili češći događajni tok | Batch pristup |
|---|---|---|
| Brzina promene zalihe | Visoka, sa čestim porudžbinama | Niska ili umerena |
| Broj prodajnih kanala | Više kanala sa zajedničkom zalihom | Jedan kanal ili slaba međuzavisnost |
| Rizik od preprodaje | Visok | Prihvatljiv uz definisan interval |
| Izvorni sistem | Podržava pouzdane događaje ili API provere | Bolje radi sa periodičnim izvozom |
| Održavanje | Zahteva monitoring, retry i idempotentnost | Jednostavniji tok, ali zahteva kontrolu paketa |
| Tipična primena | Omnichannel prodaja i kritična dostupnost | Manji katalog i sporije promene |
Praktično pravilo je da se ne optimizuje ono što nije poslovno kritično. Ako kupci uglavnom naručuju proizvode koji su stalno dostupni, batch može smanjiti složenost bez vidljive štete. Ako se prodaje poslednjih nekoliko komada kroz više kanala, kašnjenje postaje direktan rizik za obradu porudžbine.
Hibridni model često daje najbolji rezultat
U hibridnom modelu kritične promene idu odmah, a ostali podaci se osvežavaju periodično. Na primer, nova porudžbina, otkazivanje i povraćaj mogu pokrenuti događajnu izmenu, dok se kompletno usklađivanje kataloga obavlja jednom dnevno ili na svakih nekoliko sati.
Druga mogućnost je da se za artikle sa visokom prodajom koristi kraći interval, a za sporije proizvode duži. Slično tome, dostupnost po glavnom magacinu može se prenositi često, dok se manje važni atributi osvežavaju u batch paketu. Ovakva podela treba da bude dokumentovana po tipu podatka i događaju, a ne da zavisi od neformalnog dogovora između timova.
Ukoliko je integracija sa ERP-om centralna za porudžbine, cene i zalihe, korisno je prvo definisati tokove podataka i odgovornosti po sistemima. Za detaljniji kontekst pogledajte vodič ERP integracija za web shop: porudžbine, zalihe i cene.
Kako projektovati pouzdanu integraciju zaliha
1. Odredite izvor istine
Za svaki podatak mora biti poznato gde se konačna odluka donosi. ERP može biti izvor fizičkog stanja, web shop može upravljati prikazom dostupnosti, a marketplace može slati potvrdu porudžbine. Ako dva sistema mogu nezavisno da menjaju istu vrednost bez prioriteta, konflikt je očekivan.
2. Napišite mapu događaja
Popišite šta se dešava nakon kreiranja porudžbine, neuspele naplate, otkazivanja, povraćaja, ručne korekcije, prijema robe i promene statusa isporuke. Za svaki događaj zabeležite koji sistem šalje podatak, koji ga prima i da li se zaliha rezerviše, umanjuje ili vraća.
3. Uvedite zaštitu od ponavljanja
Integracija treba da može da obradi isti događaj više puta bez pogrešnog umanjenja zalihe. To se obično rešava jedinstvenim identifikatorom događaja, evidencijom obrađenih poruka i jasnim pravilima za ponovni pokušaj. Tehnički naziv za ovakvo ponašanje je idempotentnost, ali važniji je rezultat: ponovljena poruka ne proizvodi ponovljenu poslovnu radnju.
4. Planirajte neuspeh, ne samo uspešan tok
Potrebni su zapis greške, status obrade, vreme poslednje uspešne sinhronizacije i mogućnost ponavljanja. Administrator treba da vidi da li je problem u nepoznatom SKU-u, nedostupnom API-ju, pogrešnoj količini ili konfliktu statusa. Bez ove evidencije integracija može delovati ispravno dok se razlika ne primeti tek tokom obrade porudžbine.
5. Uvedite kontrolno usklađivanje
Čak i uz real-time događaje korisno je periodično poređenje ukupnog stanja. Kontrolni proces može pronaći artikle koji nisu dobili događaj, razlike nastale ručnom izmenom i probleme sa mapiranjem varijanti. Važno je unapred definisati da li se razlika automatski ispravlja ili prvo ide na proveru.
Posebna pažnja: SKU, varijante i više magacina
Najviše problema nastaje kada identifikatori nisu dosledni. SKU u ERP-u, šifra varijante u web shopu i oznaka na marketplace-u moraju imati pouzdanu vezu. Ne treba se oslanjati samo na naziv proizvoda, jer isti naziv može postojati za više veličina, boja ili pakovanja.
Kod proizvoda sa varijantama zaliha se najčešće vodi na nivou konkretne varijante, a ne samo roditeljskog proizvoda. Kod više magacina treba definisati da li se kupcu prikazuje zbirna količina, samo određena lokacija ili dostupnost prema pravilima isporuke. Ako se stanje sabira iz više lokacija, integracija mora uzeti u obzir rezervacije i robu koja nije raspoloživa za svaki kanal.
Ove odluke utiču i na izbor platforme. Ako tek birate rešenje, poređenje opcija kroz custom web shop ili Shopify/WooCommerce treba da obuhvati API mogućnosti, upravljanje varijantama, webhooks, ograničenja i način rada sa više skladišta — ne samo izgled prodavnice.
Kako izgleda dobar proces pre izrade
- Popis sistema i kanala: evidentirati ERP, web shop, marketplace, POS i logistiku.
- Definisanje podataka: navesti koje stanje, cenu i status svaki sistem šalje ili prima.
- Procena tolerancije: odrediti koliko dugo podatak može biti zastareo za svaku grupu proizvoda.
- Izbor modela: odabrati real-time, batch ili hibrid po toku, a ne nužno za celu integraciju.
- Testiranje scenarija: proveriti rasprodaju, paralelnu kupovinu, otkazivanje, povraćaj, prekid veze i ponovljenu poruku.
- Monitoring i održavanje: definisati ko prati greške i kako se radi periodično usklađivanje.
Ovaj nivo analize je deo tehničkog obima, arhitekture i implementacije web shopa. Ako planirate projekat, pogledajte izradu web shopa kao glavnu stranicu za širi pregled procesa i mogućih funkcionalnih celina. Za projekte u kojima je potrebno povezati više sistema, relevantan je i kontekst izrade sajta, posebno kada web shop predstavlja samo jedan deo većeg digitalnog ekosistema.
Zaključak: brzina treba da prati rizik
Real-time sinhronizacija zaliha ima smisla kada postoji visoka frekvencija promena, više prodajnih kanala ili mala tolerancija na preprodaju. Batch pristup je racionalan kada su promene sporije, kanal jednostavniji i interval kašnjenja prihvatljiv. Hibridni model povezuje prednosti oba pristupa: kritične događaje obrađuje odmah, a kompletno usklađivanje koristi kao kontrolu.
Najbolja odluka ne počinje pitanjem „koja tehnologija je modernija“, već pitanjima: koji sistem je izvor istine, šta se dešava pri neuspehu i koliko zastareo podatak poslovanje može da podnese. Kada se odgovori dokumentuju pre razvoja, integracija zaliha postaje proverljiv deo arhitekture, a ne naknadna zakrpa.
