Zebra WT-40 duomenų rinkimo terminalas su žiedo skaitytuvu. Jis reikalingas norint greitai nuskenuoti gaminį fiziškai dedant dėžutes ant padėklo (laisvų rankų įranga).
Per kelerius metus atidarėme parduotuves ir labai greitai išaugome. Tai baigėsi tuo, kad dabar mūsų sandėliai per dieną priima ir išsiunčia apie 20 tūkst. Natūralu, kad šiandien jau turime daugiau sandėlių: du didelius Maskvoje - 100 ir 140 tūkstančių kvadratinių metrų, bet yra ir mažų kituose miestuose.
Kiekviena sekundė, sutaupyta tokio masto prekių priėmimo, surinkimo ar siuntimo procesuose, yra galimybė sutaupyti laiko operacijoms. Ir tai taip pat yra didžiulis sutaupymas.
Būtent todėl du pagrindiniai efektyvumo daugikliai yra gerai apgalvotas veiksmų (proceso) algoritmas ir pritaikytos IT sistemos. Pageidautina "kaip laikrodis", bet "dirbti šiek tiek mažiau nei idealiai" taip pat tinka. Juk mes esame realiame pasaulyje.
Istorija prasidėjo prieš šešerius metus, kai atidžiau pažvelgėme į tai, kaip tiksliai tiekėjai iškrauna sunkvežimius mūsų sandėlyje. Tai buvo taip nelogiška, bet įprasta, kad darbuotojai net nepastebėjo, kad procesas nėra optimalus. Be to, tuo metu neturėjome pramoninio sandėlio valdymo sistemos, o logistikos operacijas daugiausia patikėjome 3PL operatoriams, kurie naudojo savo programinę įrangą ir patirtį statybos procesuose.
Prekių priėmimas
Kaip jau minėjome, mūsų įmonė tuo metu (kaip iš principo ir dabar) siekė atidaryti daug parduotuvių, todėl teko optimizuoti sandėlio procesus, kad padidėtų pralaidumas (daugiau prekių per trumpesnį laiką). Tai nelengva užduotis ir jos neįmanoma išspręsti tiesiog padidinus darbuotojų skaičių, jau vien todėl, kad visi šie žmonės trukdytų vieni kitiems. Taip pradėjome galvoti apie WMS (sandėlio valdymo sistemos) informacinės sistemos diegimą. Kaip ir tikėtasi, pradėjome nuo tikslinių sandėlio procesų aprašymo ir jau pačioje pradžioje aptikome neuždirbtą lauką prekių priėmimo proceso patobulinimams. Reikėjo apibūdinti procesus viename iš sandėlių, kad vėliau juos būtų galima perkelti į kitus.
Priėmimas yra viena iš pirmųjų pagrindinių operacijų sandėlyje. Jis būna kelių tipų: kai tiesiog suskaičiuojame krovinių skaičių ir kai, be to, reikia suskaičiuoti, kiek ir kokių gaminių yra ant kiekvieno padėklo. Dauguma mūsų prekių praeina per kryžminį dokų srautą. Tai yra tada, kai prekės iš tiekėjo atkeliauja į sandėlį, o sandėlis atlieka maršrutizatoriaus funkciją ir bando nedelsiant jas pakartotinai išsiųsti galutiniam gavėjui (parduotuvei). Yra ir kitų srautų, pavyzdžiui, kai sandėlis veikia kaip talpykla arba kaip saugykla (reikia sudėti atsargas sandėlyje, padalinti į dalis ir palaipsniui transportuoti į parduotuves). Tikriausiai mano kolegos, dirbantys su matematiniais likučių optimizavimo modeliais, geriau papasakos apie darbą su atsargomis. Bet čia staigmena! Problemos ėmė kilti vien atliekant rankines operacijas.
Procesas atrodė taip: atvažiavo sunkvežimis, vairuotojas apsikeitė dokumentais su sandėlio administratore, administratorė suprato kas ten atvažiavo ir kur siųsti, tada nukreipė krautuvę pasiimti prekes. Visa tai užtruko apie tris valandas (žinoma, priėmimo laikas labai priklauso nuo to, kokį logistikos srautą priimame: kai kur reikia atlikti vidinį perskaičiavimą, o kitur – ne). Į vieną sunkvežimį daugiau žmonių pasiųsti neįmanoma: jie trukdys vieni kitiems.
Kokie buvo nuostoliai? Jų buvo jūra. Pirmiausia sandėlio darbuotojai gavo popierinius dokumentus. Jie naršė ir pagal juos priėmė sprendimus, ką daryti su tiekimu. Antra, jie rankiniu būdu suskaičiavo padėklus ir užrašydavo kiekius tuose pačiuose važtaraščiuose. Tada užpildytos priėmimo formos buvo išsiųstos į kompiuterį, kuriame duomenys buvo suvedami į XLS failą. Duomenys iš šio failo buvo importuoti į ERP ir tik tada mūsų IT branduolys iš tikrųjų pamatė produktą. Turėjome labai mažai metaduomenų apie užsakymą, pvz., transporto atvykimo laiką, arba šie duomenys buvo netikslūs.
Pirmiausia pradėjome automatizuoti pačius sandėlius, kad jie turėtų procesų palaikymą (reikėjo įdiegti aibę programinės įrangos, aparatinės įrangos, pvz., mobiliųjų brūkšninių kodų skaitytuvų, ir visa tai diegti infrastruktūrą). Tada šias sistemas sujungėme su ERP per magistralę. Galiausiai informacija apie prekių prieinamumą sistemoje atnaujinama, kai krautuvas paleidžia brūkšninio kodo skaitytuvą ant atvažiuojančio sunkvežimio padėklo.
Tai tapo taip:
- Tiekėjas pats pildo duomenis, ką ir kada mums siunčia. Tam yra SWP ir EDI portalų derinys. Tai yra, parduotuvė paskelbia užsakymą, o tiekėjai įsipareigoja įvykdyti užsakymą ir tiekti prekes reikiamu kiekiu. Siunčiant prekes nurodoma sunkvežimyje esančių padėklų sudėtis ir visa reikalinga logistikos informacija.
- Kai automobilis išvažiuoja pas mus iš tiekėjo, mes jau žinome, kokia prekė atkeliauja pas mus; Negana to, su tiekėjais nustatytas elektroninis dokumentų valdymas, todėl žinome, kad UPD jau pasirašytas. Rengiama optimalaus šios prekės judėjimo schema: jei tai kryžminis dokas, tai mes jau užsisakėme transportą iš sandėlio, skaičiuodami prekes, o visiems logistikos srautams jau nustatėme, kiek sandėlio resursų turėsime. reikia apdoroti pristatymus. Kryžminio doko detalėse preliminarus transportavimo iš sandėlio planavimas atliekamas ankstesniame etape, kai tiekėjas ką tik rezervavo pristatymo vietą sandėlio vartų valdymo sistemoje (YMS – kiemo valdymo sistema), kuri yra integruota su tiekėjų portalu. . Informacija į YMS ateina nedelsiant.
- YMS gauna sunkvežimio numerį (tiksliau – siuntos numerį iš SWP) ir užregistruoja vairuotoją priimti, tai yra paskiria jam reikiamą laiko tarpą. Tai yra, dabar laiku atvykusiam vairuotojui nereikia laukti eilėje, o jam skirtas legalus laikas ir iškrovimo dokas. Tai, be kita ko, leido mums optimaliai paskirstyti sunkvežimius visoje teritorijoje ir efektyviau išnaudoti iškrovimo vietas. Be to, kadangi mes iš anksto sudarome grafiką, kas kur ir kada atvyks, žinome, kiek žmonių reikia ir kur. Tai yra, tai susiję ir su sandėlio darbuotojų darbo grafikais.
- Dėl šios magijos krautuvams nebereikia papildomo maršruto, o tik laukiama, kol automobiliai juos iškraus. Tiesą sakant, jų įrankis – terminalas – nurodo, ką ir kada daryti. Abstrakcijos lygiu tai panašu į įkroviklio API, bet žmogaus ir kompiuterio sąveikos modelyje. Pirmojo padėklo nuskaitymo iš sunkvežimio momentas taip pat yra pristatymo metaduomenų įrašas.
- Iškrovimas vis tiek atliekamas rankomis, tačiau krautuvas ant kiekvieno padėklo paleidžia brūkšninio kodo skaitytuvą ir patvirtina, kad etiketės duomenys yra tvarkingi. Sistema užtikrina, kad tai yra tinkamas padėklas, kurio tikimės. Iškrovimo pabaigoje sistema tiksliai suskaičiuos visus krovinius. Šiame etape defektai vis dar šalinami: jei yra akivaizdūs transportavimo konteinerio pažeidimai, užtenka tai tiesiog pastebėti iškrovimo metu arba visiškai nepriimti šio gaminio, jei jis visiškai netinkamas naudoti.
- Anksčiau padėklai buvo skaičiuojami iškrovimo zonoje, kai visi buvo iškraunami iš sunkvežimio. Dabar fizinio iškrovimo procesas yra perskaičiavimas. Jei defektas yra akivaizdus, nedelsiant grąžiname. Jei tai nėra akivaizdu ir atrandama vėliau, tai kaupiame specialiame sandėlyje esančiame buferyje. Daug greičiau paletę mesti toliau į procesą, surinkti jų keliolika ir suteikti tiekėjui galimybę viską pasiimti iš karto per vieną atskirą vizitą. Kai kurie defektų tipai perkeliami į perdirbimo zoną (tai dažnai taikoma užsienio tiekėjams, kuriems lengviau gauti nuotraukas ir išsiųsti naują prekę, nei priimti atgal per sieną).
- Pasibaigus iškrovimui, pasirašomi dokumentai, o vairuotojas išvažiuoja imtis savo reikalų.
Senajame procese padėklai dažnai būdavo perkeliami į specialią buferinę zoną, kur su jais jau buvo dirbama: skaičiuojama, registruojama santuoka ir pan. Tai buvo būtina norint atlaisvinti doką kitam automobiliui. Dabar visi procesai sukonfigūruoti taip, kad ši buferinė zona tiesiog nereikalinga. Yra selektyvinis perskaitymas (vienas pavyzdys – „Šviesoforo“ projekte įgyvendintas atrankinis vidinės pakuotės perskaičiavimas kryžminiam įkrovimui sandėlyje), tačiau didžioji dalis prekių apdorojama iškart gavus ir tai yra iš doko. kad jie keliautų į optimalią vietą sandėlyje arba iš karto į kitą doką pakrovimui, jei jau atvyko transportas siuntimui iš sandėlio. Žinau, kad jums tai skamba šiek tiek kasdieniškai, bet prieš penkerius metus didžiuliame sandėlyje galimybė apdoroti siuntą tiesiai į galinius taškus, pavyzdžiui, kito sunkvežimio pakrovimo doką, mums atrodė kaip kažkas iš kosminės programos.
Kas vyksta šalia produkto?
Be to, jei tai nėra kryžminis dokas (o prekės dar nepateko į buferį prieš išsiunčiant arba tiesiai į doką), tada jas reikia sudėti į sandėlį saugojimui.
Būtina nustatyti, kur šis produktas pateks, kurioje laikymo kameroje. Senajame procese reikėjo vizualiai nustatyti, kurioje zonoje laikome tokio tipo prekes, o tada pasirinkti vietą ten ir paimti, padėti, užsirašyti, ką dedame. Dabar mes nustatėme kiekvieno produkto išdėstymo maršrutus pagal topologiją. Mes žinome, kuris produktas turi patekti į kurią zoną ir į kurią ląstelę, žinome, kiek papildomų langelių turi užimti netoliese, jei jis yra per didelis. Asmuo prieina prie padėklo ir nuskaito jį SSCC naudodamas TSD. Skaitytuvas rodo: „Take it to A101-0001-002“. Tada nuneša jį ten ir pažymi, ką ten padėjo, vietoje spustelėdamas skaitytuvą į kodą. Sistema patikrina, ar viskas teisinga, ir tai pažymi. Nereikia nieko rašyti.
Taip baigiama pirmoji darbo su gaminiu dalis. Tada parduotuvė pasiruošusi pasiimti iš sandėlio. Ir tai lemia kitą procesą, apie kurį geriau papasakos kolegos iš pirkimų skyriaus.
Taigi sistemoje atsargos atnaujinamos užsakymo priėmimo momentu. O kameros atsargos yra tuo metu, kai į ją įdedamas padėklas. Tai yra, mes visada žinome, kiek iš viso prekių yra sandėlyje ir kur tiksliai yra kiekviena prekė.
Daugelis srautų nukreipiami tiesiai į centrus (regioninius perkrovimo sandėlius), nes kiekviename regione turime daug vietinių tiekėjų. Tuos pačius oro kondicionierius iš Voronežo patogiau montuoti ne federaliniame sandėlyje, o tiesiai į vietinius mazgus, jei taip greičiau.
Atvirkštiniai atliekų srautai taip pat šiek tiek optimizuoti: jei prekės yra kryžminės dokas, tiekėjas gali jas pasiimti iš sandėlio Maskvoje. Jei defektas paaiškėjo atidarius transportavimo pakuotę (o iš išorės tai nebuvo aišku, tai yra ne transporto darbuotojų kaltė), tai kiekvienoje parduotuvėje yra grąžinimo zonos. Defektas gali būti siunčiamas į federalinį sandėlį arba gali būti perduotas tiekėjui tiesiai iš parduotuvės. Antrasis pasitaiko dažniau.
Kitas procesas, kurį dabar reikia optimizuoti – neparduotų sezoninių prekių apdorojimas. Faktas yra tai, kad turime du svarbius sezonus: Naujuosius metus ir sodo darbų laiką. Tai yra, sausio mėnesį paskirstymo centre gauname neparduotų dirbtinių medžių ir girliandų, o iki žiemos – žoliapjoves ir kitas sezonines prekes, kurias reikia išsaugoti, jei išgyvens dar metus. Teoriškai turime juos visiškai parduoti pasibaigus sezonui arba atiduoti kam nors kitam, o ne tempti atgal į sandėlį – tai yra ta dalis, kurios dar nesusipratome.
Per penkerius metus keturis kartus sumažinome prekių priėmimo (staklių iškrovimo) laiką ir paspartinome daugybę kitų procesų, o tai iš viso kiek daugiau nei per pusę pagerino kryžminio doko apyvartą. Mūsų užduotis – optimizavimas, siekiant sumažinti atsargas ir „neužšaldyti“ pinigų sandėlyje. Ir jie leido parduotuvėse gauti reikiamas prekes šiek tiek daugiau laiku.
Didieji sandėlio procesų patobulinimai buvo automatizuoti tai, kas anksčiau buvo popierius, atsikratyti nereikalingų proceso žingsnių per įrangą ir tinkamai sukonfigūruotus procesus bei sujungti visas įmonės IT sistemas į vieną visumą, kad užsakymas iš ERP ( pvz., parduotuvėje kažko trūksta trečioje lentynoje kairėje) galiausiai virto konkrečiais veiksmais sandėliavimo sistemoje, transporto užsakymu ir pan. Dabar optimizavimas labiau susijęs su procesais, kurių dar nepriėjome, ir prognozavimo matematiką. Tai yra, greito įgyvendinimo era baigėsi, mes atlikome tuos 30% darbų, kurie davė 60% rezultato, o tada reikia palaipsniui padengti likusią dalį. Arba persikelkite į kitas sritis, jei ten galima padaryti daugiau.
Na, o jei skaičiuoti išsaugotuose medžiuose, tai tiekėjų perėjimas prie EDI portalų taip pat daug davė. Dabar beveik visi tiekėjai neskambina ir nebendrauja su vadovu, o pasižiūri užsakymus asmeninėje paskyroje, juos patvirtina ir pristato prekes. Esant galimybei atsisakome popierinio, nuo 2014 metų jau 98% tiekėjų naudojasi elektroniniu dokumentų valdymu. Iš viso tai yra 3 medžių, sutaupytų per metus vien dėl to, kad nereikia atsispausdinti visų reikalingų popierių. Bet čia neatsižvelgiama į procesorių skleidžiamą šilumą, bet ir į sutaupytą darbo laiką tokių žmonių, kaip tie patys vadovai telefone.
Per penkerius metus turėjome keturis kartus daugiau parduotuvių, tris kartus daugiau įvairių dokumentų, o jei ne EDI, buhalterių turėtume tris kartus daugiau.
Tuo nesustojame ir toliau jungiame naujas žinutes prie EDI, naujus tiekėjus prie elektroninių dokumentų valdymo.
Pernai atidarėme didžiausią platinimo centrą Europoje – 140 tūkst. kv. m – ir ėmėsi jį mechanizuoti. Apie tai pakalbėsiu kitame straipsnyje.
Šaltinis: www.habr.com