Trex Pi
Igal jaemüüjal, kellega me kohtume, on sama lugu: e-pood müüs kolm ühikut millestki, mida laos polnud üldse, järgnes vihane kliendikiri ja keegi kuulutas integratsiooni "katki olevaks". Tavaliselt see nii ei ole. See teeb täpselt seda, milleks see loodi - sünkroniseerib laoseisu iga 15 minuti tagant - ja probleem peitub disainis.
Üle müümine on järjepidevuse küsimus
Laoseisu sünkroonimine asetseb kahe kulu vahelisel spektril:
- Sünkroniseerite liiga harva ja müüte seda, mida teil pole.
- Broneerite reaalajas ja maksate selle eest - ERP API koormuses, ostukorvi viivituses ja tehnilises keerukuses.
Viga on valida üks punkt sellel spektril kogu kataloogi jaoks. Jaemüüjal, kellel on 40 000 SKU-d, võib olla 200, mis üldse üle müümise lähedale jõuavad - kiiresti liikuvad tooted, kampaaniatooted, viimaste ühikute väljamüük. Need väärivad reaalajas broneerimist ostu sooritamisel. Ülejäänud 39 800 saavad suurepäraselt hakkama 15-minutilise partiipõhise andmevooga.
Kolmetasandiline mudel, mida me pakume
- Partii tasand - vaikimisi. Laoseisud liiguvad ERP-ist e-poodi kindla ajakava alusel. Odav, töökindel, sobib kõigele, millel on tervislik laosügavus.
- Läviväärtuse tasand - kui saadaolev kogus langeb alla seadistatava piiri, tõstetakse SKU automaatselt sündmuspõhistele uuendustele.
- Broneerimise tasand - ostu sooritamine teeb ERP-is kindla broneeringu enne tellimuse kinnitamist. Mõeldud väikesele hulgale SKU-dele, kus üle müümine maksab rohkem kui API päringud.
Tasandite vaheline tõstmine on automaatne ja andmepõhine - integratsioon jälgib oma enda vea määra ja kohandub. Kuus kuud pärast selle juurutamist ühele Balti jaekaubandusgrupile langesid ülemüümised iganädalasest intsidendikanalist kahe juhtumini kvartalis, ning mõlemal korral selgus, et laos oli laoseisu käsitsi korrigeeritud - andmesisestusviga andmete allikas, mitte sünkroonimise viga.
Disainige integratsioon eksimise hinna ümber ja arhitektuur järgneb sellele.