Kodėl jūsų internetinė parduotuvė parduoda daugiau, nei turi: teisingai atlikta ERP atsargų sinchronizacija

Kiekvienas mažmenininkas, su kuriuo susiduriame, pasakoja tą pačią istoriją: internetinė parduotuvė pardavė tris vienetus prekės, kurios sandėlyje nebuvo likę nė vieno, sekė piktas kliento laiškas, ir kažkas paskelbė, kad integracija „sugedusi". Paprastai taip nėra. Ji daro būtent tai, kam buvo sukurta - sinchronizuoja atsargas kas 15 minučių - ir problema yra pati sistemos projektavimo idėja.

Pardavimas viršijant atsargas yra nuoseklumo klausimas

Atsargų sinchronizacija yra tarp dviejų kraštutinumų sąnaudų prasme:

• Sinchronizuojate per retai - ir parduodate tai, ko neturite.
• Rezervuojate realiuoju laiku - ir už tai mokate: ERP API apkrova, užsakymo apdorojimo delsa ir sudėtingesnė inžinerija.

Klaida - visam katalogui pasirinkti vieną tašką šiame spektre. Mažmenininkas, turintis 40 000 SKU, gali turėti tik apie 200, kurie kada nors artėja prie pardavimo viršijant atsargas - greitai parduodamos prekės, akcijų prekės, paskutinių vienetų išpardavimas. Jiems verta taikyti realaus laiko rezervaciją apmokėjimo metu. Likusiems 39 800 puikiai pakanka 15 minučių paketinio atnaujinimo.

Trijų lygių modelis, kurį diegiame

1. Paketinis lygis - numatytasis. Atsargų lygiai keliauja ERP → internetinę parduotuvę pagal grafiką. Pigus, patikimas, tinkamas viskam, kur atsargų yra pakankamai.
2. Ribos lygis - kai turimas kiekis nukrenta žemiau nustatytos ribos, SKU automatiškai perkeliamas į įvykiais grįstus atnaujinimus.
3. Rezervacijos lygis - apmokėjimo metu ERP sistemoje sukuriama tvirta rezervacija dar prieš patvirtinant užsakymą. Skirta nedideliam skaičiui SKU, kurių pardavimas viršijant atsargas kainuoja brangiau nei papildomi API kvietimai.

Perkėlimas tarp lygių vyksta automatiškai ir remiantis duomenimis - integracija stebi savo pačios klaidų dažnį ir prisitaiko. Praėjus šešiems mėnesiams po šio sprendimo diegimo Baltijos šalių mažmeninės prekybos grupei, pardavimas viršijant atsargas iš savaitinio incidentų kanalo virto dviem atvejais per ketvirtį, ir abiem atvejais paaiškėjo, kad atsargų likučiai sandėlyje buvo pakoreguoti ranka - duomenų įvedimo klaida pačiame šaltinyje, o ne sinchronizacijos triktis.

Suprojektuokite integraciją atsižvelgdami į klaidos kainą, ir architektūra susiformuos pati.