Az evi nagy leltarat a logisztikaban hivatalosan halottnak nyilvanitottuk. Egy 18.000 SKU-s raktarban a december 28-i 'osszes polc, egesz hetvegen, 14 ember' tipusu leltar 91.4% pontossagot adott. Cycle countingra valtas utan 9 hettel a pilot tenantunknal 98.7%-on alltunk. Itt van, hogyan tortent.
Miert nem mukodik az evi leltar
Ket ok. Az elso: egy 18.000 SKU-s raktarban a 14 fos team 2 napon at szamlal, es a fenntartott figyelmuk a 4. ora utan elveszik. A hibak halmozodnak. A masodik: az evi leltar zaras alatt allitja le a raktart 48 oranyira, ami a B2B partnerunknel rendelesi kapacitas-vesztesegben atlagosan 2-3 napos kuldemenyi csuszast okoz a december 28-30 hetvegen. A vasarloi tapasztalat is gyenge.
A cycle counting az ellenkezo iranyban dolgozik: napi 5-15 percnyi szamlalas, a raktar tovabbra mukodik, es a hibak azonnal latszanak.
ABC kategorizalas
Minden SKU egy A, B vagy C kategoriaba esik az elozo 90 nap forgalmaalapjan (revenue, nem darabszam).
- A: a forgalom 80%-at adjuk, a SKU-k ~20%-a. Hetente szamoljuk.
- B: a forgalom 15%-at adjuk, a SKU-k ~30%-a. Havonta szamoljuk.
- C: a forgalom 5%-at adjuk, a SKU-k ~50%-a. Negyedevente szamoljuk.
Az allocator algoritmusa minden este lefut, es masnapra letrehozza a cycle_count_assignments rekordokat a polcoknak. Egy pickere reggel a PWA-jaba bejelentkezve egy 'cycle count today' wave-t lat, ami 15-25 SKU-t tartalmazhat. A polchoz megy, scan-eli, beirja a megszamolt darabszamot.
Variancia kuszob
Ha a megszamolt darabszam ±2%-os tartomanyon belul van a rendszer szerinti keszlethez kepest, automatikusan elfogadjuk, a stock_movement rekord landol egy adjustment muveletkent. Ha a variancia 2-10% kozott van, a sor a supervisor wave-be esik, ahol a supervisorja ujraszamolja. Ha a variancia >10% (vagy egy A-kategoriaju SKU-nal egyaltalan), automatikus 'investigate' jelolest kap, es a vezeto operativ szemely manualisan vizsgalja: rossz polc-cimre lett pakolva? Lopas? Adatbeviteli hiba egy korabbi mozgasnal?
A change-management tanulsag
A pilot tenant raktari csapatatat harom hetig HALAM ellenezte. 'Eddig csak egyszer evente szamoltunk, most minden nap?' A perceptualis problem nem a munka volument volt, hanem hogy egy uj feladatot adunk hozzajuk a meglevo pick/pack mellé. A megoldas: a cycle count wave-t a muszak elejen futtatjuk (08:00-08:15), amikor a pickelési hullam meg nem indult, igy nem zavarja a fo munkat. A masodik megoldas: a supervisor a 9 hetes ramp-up alatt minden hetente atadja a stock-pontossagi metrikat a csapatnak, mint board metrika. A 91.4% -> 98.7% folyamat a csapat sajat ujsageszteseve valt.
A harom het utan a tonus megvaltozott. A pickerek elkezdtek maguktol elkulonbozteteni: 'ezt a polcot ma reggel mar szamoltam, de a tegnapi rendelesen ket darab hianyzott, csekkolnunk kell'. A folyamat sajatja lett.
Mobil-drivenen
A cycle count tisztan a PWA-n at megy. Nincs papir, nincs Excel. A scan-eles polc, scan-eles SKU, a darabszam beirasa, a 'submit' gomb. Egy SKU pillanatnyi szamla atlagosan 22 masodperc. Egy heti A-wave 60-80 SKU-t tartalmaz, ami 22-30 perc pickerenkent. Ez nem mukodne papirral.
A 9 hetes ramp-up gorbe
-
- het: 91.4% (baseline).
-
- het: 94.1% (a legtobb A-SKU vegre stabil).
-
- het: 96.8% (a B-kategoriak elkezdenek beigazodni).
-
- het: 98.0% (a C-kategoriak elso ciklusa is megvan).
-
- het: 98.7% (steady state).
Utana stabilis 98-99% kozott, kis ingadozasokkal. A maradek 1-2% varianciat foleg uj termekek bevitelekor latjuk (a SKU master adatban hiba), nem a pickere-fronton.