Ar AI gali tiksliai prognozuoti, kiek prekės užsakyti?

AI gali labai gerai apskaičiuoti užsakymo tašką ir kiekį pagal istorinį pardavimą, jo svyravimą ir tiekimo laiką, bet „tiksliai“ nebūna niekada — prognozė visada turi paklaidą. Vertė ne ta, kad agentas atspės ateitį iki vieneto, o ta, kad jis nuolat perskaičiuoja skaičius, kurių žmogus rankomis nespėja sekti kiekvienam SKU, ir įspėja anksčiau, nei prekės pritrūksta. Netikėti dalykai — virusinis pikas, tiekėjo vėlavimas, sezono poslinkis — lieka žmogaus akiai. Todėl teisingas modelis: agentas skaičiuoja ir siūlo, žmogus tvirtina užsakymą.

Kokių duomenų reikia atsargų prognozei?

Minimaliai — pardavimų istorijos pagal SKU, esamo likučio (sandėlyje, kelyje ir rezervuoto), ir tiekimo laiko: kiek trunka tiekėjo gamyba, gabenimas ir prekės priėmimas Amazon sandėlyje. Naudinga pridėti sezoniškumą, planuojamas akcijas ir PPC intensyvumą, nes jie keičia pardavimo tempą. Amazon SP-API šiuos duomenis atiduoda automatiškai, todėl agentas gali juos traukti be rankinio darbo. Kuo tvarkingesni istoriniai duomenys, tuo geresnė prognozė — todėl praktikoje pirmas žingsnis dažnai yra ne modelis, o duomenų sutvarkymas.

Ar prognozavimo agentas pats užsako prekę iš tiekėjo?

Gali paruošti užsakymą, bet galutinį pirkimą praktiškai verta palikti žmogaus patvirtinimui. Agentas gerai tinka rutinai: perskaičiuoti užsakymo tašką, sudaryti užsakymo projektą su kiekiu ir data, priminti, kai likutis krenta žemiau ribos, net paruošti žinutę tiekėjui. Bet užsakymas iš tiekėjo yra pinigų ir įsipareigojimų sprendimas, priklausantis nuo derybų, kainos ir sezono — todėl jis natūraliai patenka į tą pačią žmogaus patvirtinimo liniją kaip ir kiti negrįžtami veiksmai.

Amazon atsargų prognozavimas su AI: kaip nelikti be prekės ir nemokėti už perteklių

Q: Kodėl per didelės atsargos Amazon irgi yra problema?

Nes už FBA sandėliavimą moki, o už seną ir perteklinį inventorių Amazon ima papildomus mokesčius. Ilgai gulinti prekė kaupia sandėliavimo sąnaudas, gali užsidirbti seno inventoriaus priemoką, o per mažas pardavimo tempas palyginti su likučiu blogina tavo atsargų rodiklius ir gali apriboti, kiek naujos prekės apskritai gali atsivežti. Prie to prisideda užšaldyti pinigai: kapitalas, gulintis prekėje, kurios niekas neperka šią savaitę, negali eiti į tai, kas parduodama. Todėl tikslas ne „kuo daugiau atsargų“, o tiek, kad užtektų iki kitos partijos su protinga saugos atsarga.

Amazon atsargų prognozavimas su AI — tai kai agentas per SP-API nuolat stebi tavo pardavimų tempą, likučius ir tiekimo terminus, apskaičiuoja, kiek dienų prekės dar užteks, ir laiku signalizuoja, kada užsakyti naują partiją. Tikslas dvipusis: nelikti be prekės ir nekaupti pertekliaus. Abu kraštutinumai kainuoja — tik skirtingai. Prekei pasibaigus, prarandi ne tik tos dienos pardavimus, bet ir Buy Box bei organinę poziciją, kurią atkurti užtrunka. Prekės prisivežus per daug, moki už sandėliavimą, rizikuoji seno inventoriaus mokesčiais ir užšaldai pinigus lentynoje.

Rankomis šitą pusiausvyrą išlaikyti sunku, kai turi daugiau nei kelis SKU. Kiekvienas produktas turi savo pardavimo tempą, savo tiekimo laiką ir savo sezoną. Žmogus fiziškai nespėja kasdien perskaičiuoti visų, todėl dažnai reaguoja pavėluotai — užsako tada, kai jau matosi tuščia lentyna. Prognozavimo agentas šitą darbą daro nuolat ir tyliai, o žmogui palieka sprendimą pirkti. Toliau — kaip tai realiai veikia ir nuo ko pradėti.

Kodėl atsargų prognozė yra pinigų klausimas, ne tik logistikos

Atsargos Amazon versle yra tavo pinigai, sustingę į prekę. Kiekvienas vienetas sandėlyje jau apmokėtas — už gamybą, gabenimą ir sandėliavimą — bet dar neuždirbo nieko, kol neparduotas. Todėl atsargų valdymas iš tikrųjų yra kapitalo valdymas: klausimas ne „kiek prekės turėti“, o „kiek pinigų verta laikyti sustingusių, kad neprarastum pardavimų“.

Iš čia du priešingi pavojai. Per mažai atsargų reiškia stockout: prekė baigiasi, listingas praranda Buy Box, krenta organinė pozicija, o su ja — ir matomumas, kurį atstatyti po grįžimo į sandėlį užtrunka. Per daug atsargų reiškia sustingusį kapitalą plius FBA sąnaudas: už ilgai gulinčią prekę kaupiasi sandėliavimo mokesčiai, ji gali užsidirbti seno inventoriaus priemoką, o prastas pardavimo tempas palyginti su likučiu blogina tavo atsargų rodiklius ir gali apriboti, kiek naujos prekės apskritai leidžiama atsivežti. Gera prognozė vaikšto tarp šių dviejų kraštų — laiko atsargas tokias, kad užtektų iki kitos partijos su protinga saugos marža, ir ne daugiau.

Trys skaičiai, iš kurių gimsta prognozė

Nepaisant sudėtingai skambančio žodžio „prognozavimas“, kasdienė logika remiasi trimis paprastais dydžiais. AI čia naudingas ne tuo, kad išgalvoja formulę, o tuo, kad perskaičiuoja ją nuolat ir kiekvienam SKU atskirai.

Pirmas — pardavimo tempas. Kiek vienetų per dieną vidutiniškai parduodi. Tai bazė, nuo kurios viskas skaičiuojama.

Antras — tempo svyravimas. Vieną dieną parduodi tris, kitą — dešimt. Kuo labiau svyruoja, tuo didesnės saugos atsargos reikia, kad piko diena neišvalytų lentynos anksčiau laiko.

Trečias — pilnas tiekimo laikas. Ne tik gabenimas. Tai visas kelias nuo užsakymo iki prekės, paruoštos pardavimui: tiekėjo gamyba, transportas ir Amazon sandėlio priėmimo (check-in) laikas, kuris irgi trunka. Būtent šitą dalį pardavėjai dažniausiai neįvertina.

Iš šių trijų dydžių gaunamas užsakymo taškas — likutis, ties kuriuo jau reikia užsakyti, kad spėtum sulaukti naujos partijos neišpardavęs esamos. Iliustracijai: jei per dieną parduodi vidutiniškai 10 vienetų, o pilnas tiekimas trunka 40 dienų, tik kelionei reikia apie 400 vienetų — plius saugos atsarga svyravimui ir vėlavimui. Tai ne matavimas iš tavo paskyros, o pavyzdys, rodantis logiką: užsakymo taškas beveik visada didesnis, nei intuicija sufleruoja, nes tiekimo laikas ilgesnis, nei atrodo.

Ką realiai daro AI agentas

Prognozavimo agentas nėra atskiras „protas“ — tai automatizacija, kuri per Amazon SP-API traukia duomenis, perskaičiuoja skaičius ir signalizuoja. Žemiau — kaip pasiskirsto darbas tarp agento ir žmogaus.

Užduotis	Ką daro agentas	Kas sprendžia
Duomenų rinkimas	Traukia pardavimus, likutį (sandėlyje, kelyje, rezervuotą) per SP-API	Automatika
Tempo skaičiavimas	Perskaičiuoja vidutinį pardavimą ir svyravimą kiekvienam SKU	Automatika
Dienų iki nulio	Rodo, kiek dienų prekės užteks esamu tempu	Automatika
Užsakymo taškas	Įspėja, kai likutis krenta žemiau ribos	Automatika (signalas)
Užsakymo projektas	Paruošia kiekį, datą, net žinutę tiekėjui	Žmogus tvirtina
Pirkimas iš tiekėjo	—	Žmogus
Sezono / akcijos korekcija	Pažymi, kad artėja pikas ar akcija	Žmogus sprendžia mastą

Esmė matoma iš stulpelio „kas sprendžia“: rutina — skaičiavimas, stebėjimas, įspėjimas — atitenka agentui, o pinigų ir įsipareigojimų sprendimai lieka žmogui. Tai ta pati žmogaus patvirtinimo linija, kurią taikome visur, kur agento veiksmas negrįžtamas. Užsakymas iš tiekėjo priklauso nuo derybų, kainos ir sezono, todėl jį tvirtina žmogus — bet jis tvirtina remdamasis paruoštu skaičiavimu, ne nuojauta.

Kur agentas klysta ir kaip tai valdyti

Prognozė turi paklaidą visada, ir sąžininga tai pasakyti. Modelis remiasi praeitimi, o rinka gyvena ateitimi: staigus pardavimo pikas, tiekėjo vėlavimas, sezono poslinkis ar konkurento akcija gali sujaukti skaičius. Todėl gera sistema ne apsimeta neklystanti, o palieka žmogui matomumą ir laiką reaguoti.

Praktiškai tai reiškia keletą dalykų. Agentas turi rodyti ne tik „užsakyk“, bet ir prielaidas — kokiu tempu skaičiuota ir koks tiekimo laikas įvestas, kad žmogus matytų, kada jos nebegalioja. Prieš sezoną prognozę verta koreguoti ranka, nes praeitų savaičių tempas nerodo artėjančio piko. Ir svarbiausia — saugos atsarga egzistuoja būtent tam, kad neišvengiama paklaida nevirstų stockout’u. Agentas sumažina spėliojimą, bet neatima atsakomybės; jis paverčia atsargų valdymą iš gaisrų gesinimo į ramų, laiku priimamą sprendimą.

Nuo ko pradėti

Prieš galvodamas apie modelius, sutvarkyk duomenis. Prognozė tokia gera, kokie tvarkingi tavo istoriniai pardavimai ir kiek realiai žinai savo tiekimo laiką. Pradėk nuo kelių SKU, kurie tau svarbiausi apyvarta, ir kiekvienam surašyk tris dydžius — tempą, svyravimą, pilną tiekimo laiką. Vien šis pratimas dažnai parodo, kad užsakymo taškas turėtų būti aukštesnis, nei buvai įpratęs.

Kai logika aiški, ją verta perkelti į agentą, kad skaičiavimas vyktų automatiškai ir kasdien, o ne tada, kai prisimeni. Kaip tokią sistemą jungiame prie Amazon per SP-API, gali pasižiūrėti Amazon automatizacijos paslaugoje arba plačiau apie visą operaciją — Amazon skiltyje. Jei nori suprasti, kaip toks agentas įsiterpia tarp kitų (kainodaros, klientų, ataskaitų), pravartu ir AI agentų ir chatbotų paslauga. O jei nori aptarti savo konkrečią situaciją — kiek SKU, kokie tiekimo laikai ir kur labiausiai skauda — susiskaičiuokim kartu per nemokamą konsultaciją.