Kāpēc jūsu tiešsaistes veikals pārdod vairāk, nekā ir noliktavā: ERP krājumu sinhronizācija, kas darīta pareizi

Katram mazumtirgotājam, ar kuru tiekamies, ir viens un tas pats stāsts: tiešsaistes veikals pārdevis trīs vienības kaut kā, no kā noliktavā bijusi nulle, sekojis dusmīgs klienta e-pasts, un kāds pasludinājis integrāciju par "salauztu". Parasti tā nav. Tā dara tieši to, kam bija paredzēta - sinhronizē krājumus ik pēc 15 minūtēm -, un problēma ir pašā dizainā.

Pārdošana pāri krājumam ir konsekvences jautājums

Krājumu sinhronizācija atrodas spektrā starp divām izmaksām:

• Sinhronizējiet pārāk reti, un jūs pārdosiet to, kā jums nav.
• Rezervējiet reālajā laikā, un jūs par to maksāsiet - ERP API slodzē, pasūtīšanas aiztures laikā un inženiertehniskajā sarežģītībā.

Kļūda ir izvēlēties vienu punktu šajā spektrā visam katalogam. Mazumtirgotājam ar 40 000 SKU varētu būt 200, kas jebkad tuvojas pārdošanai pāri krājumam, - ātri ejošas preces, akcijas preces, pēdējo vienību izpārdošana. Tām pienākas reāllaika rezervācija pasūtīšanas brīdī. Pārējiem 39 800 lieliski der 15 minūšu pakešu plūsma.

Trīspakāpju modelis, ko mēs piegādājam

1. Pakešu pakāpe - noklusējums. Krājumu līmeņi plūst no ERP uz tiešsaistes veikalu pēc grafika. Lēts, uzticams, piemērots visam, kam ir pietiekams krājumu apjoms.
2. Sliekšņa pakāpe - kad pieejamais daudzums nokrītas zem konfigurējama sliekšņa, SKU automātiski tiek paaugstināts uz notikumu virzītiem atjauninājumiem.
3. Rezervācijas pakāpe - pasūtīšanas process ERP sistēmā izveido stingru rezervāciju pirms pasūtījuma apstiprināšanas. Paredzēta nelielam skaitam SKU, kurām pārdošana pāri krājumam maksā vairāk nekā API izsaukumi.

Pārvietošanās starp pakāpēm ir automātiska un balstīta uz datiem - integrācija seko līdzi savam kļūdu īpatsvaram un pielāgojas. Sešus mēnešus pēc šī risinājuma ieviešanas kādai Baltijas mazumtirdzniecības grupai pārdošana pāri krājumam no ik nedēļas incidentu kanāla samazinājās līdz diviem gadījumiem ceturksnī, un abos gadījumos izrādījās, ka noliktavā krājumu atlikumi bija laboti manuāli - datu ievades kļūda pašā avotā, nevis sinhronizācijas vaina.

Veidojiet integrāciju ap kļūdas cenu, un arhitektūra izveidosies pati no sevis.