Proč váš e-shop prodává přes stav skladu: synchronizace skladu s ERP, jak má být

Každý maloobchodník, se kterým se setkáme, má stejný příběh: e-shop prodal tři kusy něčeho, čeho měl sklad nula, následoval naštvaný e-mail od zákazníka a někdo prohlásil integraci za „rozbitou". Většinou není. Dělá přesně to, k čemu byla navržena - synchronizuje sklad každých 15 minut - a problémem je právě ten návrh.

Prodej přes stav skladu je otázkou konzistence

Synchronizace skladu se pohybuje na škále mezi dvěma náklady:

• Synchronizujete příliš zřídka a prodáváte to, co nemáte.
• Rezervujete v reálném čase a platíte za to - v zátěži API ERP, v latenci pokladny a ve složitosti řešení.

Chybou je vybrat jeden bod na této škále pro celý katalog. Maloobchodník se 40 000 SKU může mít 200, které se vůbec někdy přiblíží prodeji přes stav skladu - rychloobrátkové položky, propagační zboží, výprodej posledních kusů. Ty si zaslouží rezervaci v reálném čase při pokladně. Zbylých 39 800 je dokonale obslouženo dávkovým feedem každých 15 minut.

Třívrstvý model, který dodáváme

1. Dávková vrstva - výchozí stav. Úrovně skladu proudí z ERP → do e-shopu podle harmonogramu. Levné, robustní, vyhovuje všemu se zdravou hloubkou skladu.
2. Prahová vrstva - když množství na skladě klesne pod nastavitelnou hranici, SKU je automaticky povýšeno na aktualizace řízené událostmi.
3. Rezervační vrstva - pokladna vytvoří pevnou rezervaci v ERP ještě před potvrzením objednávky. Vyhrazeno pro malý počet SKU, kde prodej přes stav skladu stojí víc než volání API.

Přechod mezi vrstvami je automatický a řízený daty - integrace sleduje vlastní míru chybovosti a přizpůsobuje se. Šest měsíců po nasazení pro pobaltskou maloobchodní skupinu klesl prodej přes stav skladu z týdenního incidentního kanálu na dva případy za čtvrtletí - a v obou se ukázalo, že skladové zůstatky byly ve skladu ručně opraveny: chyba při zadávání dat u zdroje, ne závada synchronizace.

Navrhněte integraci kolem nákladů na to, být v neprávu, a architektura bude následovat.