Agentinis DI ataskaitų automatizavimas: nuo ~10 iki ~90
Kaip agentinis DI pakėlė komandos našumą beveik devyngubai be naujų etatų.
Skaityti →Kodėl apskaita, sandėlio sistema ir fizinė inventorizacija beveik niekada nesutampa — ir kaip dirbtinis intelektas iškelia tikrąją priežastį į paviršių, o ne dar vieną spėjimą.

DI atsargų neatitikimų aptikimas pradedamas nuo nemalonios tiesos: apskaitos, sandėlio valdymo sistemos (WMS) ir fizinės inventorizacijos duomenys beveik niekada nesutampa. Mažmenoje tai įprasta — bet kai skirtumas auga, jis virsta tiesiogine finansine rizika ir nepasitikėjimu savo paties skaičiais.
Priežasčių daug, ir jos persidengia: priėmimo klaidos, neužregistruotos grąžos, nurašymai be dokumento, neteisingai priskirti SKU, vidiniai nuostoliai (shrinkage), vagystės, taip pat paprasti sisteminiai laiko poslinkiai tarp pardavimo ir nurašymo momentų. Eksportavus ataskaitą Excel'yje matomas tik galutinis skirtumas — bet ne tai, kuri operacija, sandėlis, pamaina ar asmuo jį sukūrė.
Būtent čia tradicinis būdas lūžta. Žmogus negali rankomis perskaityti šimtų tūkstančių judėjimo eilučių ir pamatyti, kas iš jų yra normalu, o kas — anomalija. Todėl sprendimai dažnai priimami iš nuojautos: „turbūt vagia sandėlyje“ arba „tai tik apskaitos klaida“. Prielaida be įrodymo brangiai kainuoja — ji nukreipia dėmesį ne ten.
Mašininis mokymasis čia veikia ne kaip „magija“, o kaip mastelio įrankis. Vienas mūsų realus mažmenos projektas tiksliai dėl to ir buvo paleistas: apskaitos, sandėlio sistemų ir fizinės inventorizacijos duomenys nuolat skyrėsi, kėlė finansinę riziką ir neaiškumą operacijose. ERP ir sandėlio duomenų analizė atskleidė neįprastus judėjimus, pasikartojančius šablonus ir su jais susijusį laiką bei asmenis.
Techniškai tai yra anomalijų aptikimas. Modelis išmoksta, kaip atrodo „normalus“ konkretaus SKU, kategorijos ar sandėlio elgesys — kokie kiekiai, kokiu dažnumu, kuriomis valandomis, kurių darbuotojų registruojami — ir tada žymi nukrypimus. Ne pavienę eilutę, o šabloną: nurašymai, kurie sistemingai vyksta tą pačią pamainą; grąžos be atitinkamo pardavimo; korekcijos, kurios kartojasi tik tam tikrame taške.
Svarbus skirtumas: taisyklėmis grįsta sistema („pažymėk, jei korekcija > 100 vnt“) gaudo tik tai, ką jau žinai. ML gaudo tai, ko nežinojai ieškoti — tylius, pasikartojančius, mažus nuokrypius, kurie po vieną atrodo nereikšmingi, bet kartu sudaro nuostolio modelį. Tai ir yra perėjimas nuo prielaidų prie įrodymais grįsto tyrimo.
Esminė vertė nėra balas „rizikinga / nerizikinga“. Esminė vertė — tai pėdsakas, kurį galima patikrinti. Kai modelis pažymi neįprastą judėjimą, jis kartu pateikia kontekstą: kuris SKU, kuriame sandėlyje, kuriuo metu, su kokia operacija ir kuris asmuo ją atliko. Tai paverčia abstrakčią „nuostolių problemą“ į konkrečią, peržiūrimą bylą.
Tai keičia ir pokalbį viduje. Užuot kaltinus visą sandėlio komandą, vadovas gali parodyti faktą: „šie penki korekcijos atvejai per tris savaites vyko tuo pačiu šablonu“. Toks įrodymas yra teisingesnis darbuotojams (jis apsaugo nekaltus) ir efektyvesnis verslui (jis nukreipia auditą ten, kur tikrai yra problema).
Ne kiekvienas pažymėtas atvejis yra sukčiavimas — ir tai gerai. Dažnai anomalija atskleidžia broką procese: blogai aprašytą priėmimo žingsnį, dvigubą nurašymą tarp sistemų, neteisingą SKU žemėlapį. Tokie radiniai sutaupo pinigų net jei nė vienos vagystės nebuvo. DI atsargų neatitikimų aptikimas tampa ne tik saugumo, bet ir procesų švaros įrankiu.
Pradėti nereikia naujos sistemos ar didelio biudžeto. Pakanka to, ką jau turite: ERP arba apskaitos eksporto, WMS judėjimų žurnalo ir paskutinės fizinės inventorizacijos rezultatų. Pirmas žingsnis — sujungti šiuos tris šaltinius į vieną įvykių laiko juostą, kad kiekvieną skirtumą būtų galima atsekti iki konkrečios operacijos.
Antras žingsnis — pradėti nuo siaurai apibrėžtos srities: vienos kategorijos, vieno sandėlio ar didžiausios rizikos SKU grupės. Tai leidžia greitai pamatyti rezultatą ir suderinti modelio jautrumą (per daug pažymėjimų vargina komandą; per mažai — praleidžia nuostolį) prieš plečiant visam asortimentui.
Trečias žingsnis — sukurti reagavimo kilpą: kas peržiūri pažymėtus atvejus, kaip patvirtinamas ar atmetamas radinys ir kaip šis sprendimas grįžta į modelį, kad jis taptų tikslesnis. Be šio žmogaus žingsnio bet koks DI lieka tik ataskaita. Jei norite pamatyti, kur jūsų duomenyse slypi didžiausia rizika, mūsų interaktyvus DI galimybių vertinimo įrankis duoda pirmą orientyrą per kelias minutes.
Galime per 30 minučių suprasti, ar ši kryptis tinka jūsų verslui.
Rezervuoti pokalbį