Zebra WT-40 datainnsamlingsterminal med ringskanner. Det er nødvendig for raskt å kunne skanne produktet samtidig som boksene fysisk plasseres på en pall (håndfri).
I løpet av flere år åpnet vi butikker og vokste veldig raskt. Det endte med at lagrene våre nå mottar og sender rundt 20 tusen paller om dagen. Naturligvis har vi i dag allerede flere varehus: to store i Moskva - 100 og 140 tusen kvadratmeter, men det er også små i andre byer.
Hvert sekund som spares i prosessene med å motta, montere eller sende varer i en slik skala er en mulighet til å spare tid på driften. Og dette er også en stor besparelse.
Derfor er de to viktigste effektivitetsmultiplikatorene en gjennomtenkt handlingsalgoritme (prosess) og tilpassede IT-systemer. Helst "som en klokke", men "å fungere litt mindre enn perfekt" er også ganske passende. Tross alt er vi i den virkelige verden.
Historien begynte for seks år siden, da vi så nærmere på hvordan nøyaktig leverandørene laster av lastebiler på lageret vårt. Det var så ulogisk, men vanemessig, at ansatte ikke en gang merket at prosessen ikke var optimal. Dessuten hadde vi ikke på det tidspunktet et industrielt lagerstyringssystem, og vi stolte hovedsakelig på logistikkoperasjoner til 3PL-operatører som brukte deres programvare og erfaring i byggeprosesser.
Aksept av varer
Som vi allerede har sagt, forsøkte selskapet vårt på den tiden (som i prinsippet nå) å åpne mange butikker, så vi måtte optimalisere lagerprosessene for å øke gjennomstrømningen (flere varer på kortere tid). Dette er ikke en lett oppgave, og det var umulig å løse det ved å øke bemanningen, om ikke annet fordi alle disse menneskene ville forstyrre hverandre. Dermed begynte vi å tenke på å implementere et WMS (varehusstyringssystem) informasjonssystem. Som forventet startet vi med en beskrivelse av mållagerprosessene og allerede i starten oppdaget vi et upløyd felt for forbedringer i prosessen med å motta varer. Det var nødvendig å utarbeide prosessene i et av varehusene for så å rulle dem ut til resten.
Mottak er en av de første store operasjonene på et lager. Det kommer i flere typer: når vi rett og slett teller antall lastestykker og når vi i tillegg til dette skal telle hvor mange og hva slags artikler som er på hver pall. De fleste av varene våre passerer gjennom cross-docking-strømmen. Dette er når varer kommer til lageret fra leverandøren, og lageret fungerer som en ruter og prøver å umiddelbart sende dem på nytt til den endelige mottakeren (butikken). Det er andre strømmer, for eksempel når lageret fungerer som en cache eller som en lagringsenhet (du må legge forsyningen på lager, dele den i deler og gradvis transportere den til butikker). Sannsynligvis vil kollegene mine som jobber med matematiske modeller for å optimalisere rester fortelle deg bedre om arbeid med lager. Men her er en overraskelse! Problemer begynte å oppstå rent i manuelle operasjoner.
Prosessen så slik ut: lastebilen ankom, sjåføren utvekslet dokumenter med lageradministratoren, administratoren forsto hva som hadde kommet dit og hvor han skulle sende det, så ledet han lasteren til å hente varene. Alt dette tok omtrent tre timer (selvfølgelig avhenger aksepttiden i stor grad av hva slags logistikkflyt vi aksepterer: noen steder er det nødvendig å gjøre en intern omtelling, og andre ikke). Det er umulig å sende flere mennesker til en lastebil: de vil forstyrre hverandre.
Hva var tapene? Det var et hav av dem. Først mottok lagerarbeidere papirdokumenter. De navigerte og tok beslutninger om hva de skulle gjøre med tilbudet basert på dem. For det andre telte de pallene manuelt og noterte mengdene på de samme følgesedlene. Deretter ble de utfylte akseptskjemaene sendt til en datamaskin, hvor dataene ble lagt inn i en XLS-fil. Dataene fra denne filen ble deretter importert til ERP, og først da så vår IT-kjerne faktisk produktet. Vi hadde svært lite metadata om bestillingen, for eksempel transportankomsttid, eller disse dataene var unøyaktige.
Det første vi gjorde var å begynne å automatisere selve lagrene slik at de ville ha støtte for prosesser (vi trengte å installere en haug med programvare, maskinvare som mobile strekkodeskannere, og distribuere infrastrukturen for alt dette). Deretter koblet vi disse systemene med ERP via en buss. Til syvende og sist oppdateres informasjon om tilgjengeligheten av varer i systemet når lasteren kjører en strekkodeleser over pallen på den ankommende lastebilen.
Det ble slik:
- Leverandøren fyller selv inn data om hva han sender til oss og når. For dette er det en kombinasjon av SWP- og EDI-portaler. Det vil si at butikken publiserer en bestilling, og leverandørene forplikter seg til å oppfylle bestillingen og levere varene i nødvendig mengde. Når du sender varene, angir de sammensetningen av pallene i lastebilen og all nødvendig logistikkinformasjon.
- Når bilen forlater leverandøren for oss, vet vi allerede hvilket produkt som kommer til oss; I tillegg er det etablert elektronisk dokumenthåndtering med leverandører, så vi vet at UPD allerede er signert. En ordning for optimal bevegelse av dette produktet er under utarbeidelse: hvis dette er cross-docking, har vi allerede bestilt transport fra lageret, regnet med varene, og for alle logistikkstrømmer har vi allerede bestemt hvor mye lagerressurser vi vil behov for å behandle leveranser. I cross-docking detaljer gjøres foreløpig planlegging for transport fra lageret på et tidligere tidspunkt, når leverandøren nettopp har reservert en leveringsluke i lagerportstyringssystemet (YMS - yard management system), som er integrert med leverandørportalen . Informasjon kommer til YMS umiddelbart.
- YMS mottar lastebilnummeret (for å være mer presis, forsendelsesnummeret fra SWP) og registrerer sjåføren for aksept, det vil si tildeler den nødvendige tidsluken til ham. Det vil si at nå trenger ikke sjåføren som kom i tide å stå i kø, og hans lovlige tid og lossebrygge er tildelt ham. Dette tillot oss blant annet å fordele lastebiler optimalt over hele territoriet og bruke lossespalter mer effektivt. Og også, siden vi legger opp en tidsplan på forhånd om hvem som kommer hvor og når, vet vi hvor mange folk som trengs og hvor. Det vil si at dette også er relatert til arbeidsplanene til lageransatte.
- Som et resultat av denne magien trenger ikke lenger lastere ytterligere ruteføring, men venter bare på at bilene skal losse dem. Faktisk forteller verktøyet deres - terminalen - hva de skal gjøre og når. På abstraksjonsnivå er det som loader API, men i en interaksjonsmodell mellom mennesker og datamaskiner. Øyeblikket den første pallen skannes fra lastebilen er også en registrering av leveringsmetadata.
- Lossing skjer fortsatt for hånd, men lasteren kjører en strekkodeleser på hver pall og bekrefter at etikettdataene er i orden. Systemet sørger for at det er riktig pall som vi forventer. Ved slutten av lossingen vil systemet ha en nøyaktig telling av alle lastelementer. På dette stadiet elimineres fortsatt feil: hvis det er åpenbar skade på transportbeholderen, er det nok å bare merke seg dette under losseprosessen eller ikke akseptere dette produktet i det hele tatt hvis det er helt ubrukelig.
- Tidligere ble det talt paller i losseområdet etter at alle ble losset fra lastebilen. Nå er prosessen med fysisk lossing en omberegning. Vi returnerer feilen umiddelbart hvis den er åpenbar. Hvis det ikke er åpenbart og oppdages senere, samler vi det i en spesiell buffer på lageret. Det er mye raskere å kaste pallen lenger inn i prosessen, samle et dusin av dem og gi leverandøren muligheten til å hente alt på en gang i ett separat besøk. Noen typer mangler overføres til gjenvinningssonen (dette gjelder ofte utenlandske leverandører, som har lettere for å motta bilder og sende et nytt produkt enn å ta det tilbake over grensen).
- På slutten av lossingen blir dokumenter signert, og sjåføren drar for å fortsette sin virksomhet.
I den gamle prosessen ble paller ofte flyttet til en spesiell buffersone, hvor de allerede ble jobbet med: de ble talt, ekteskap ble registrert, og så videre. Dette var nødvendig for å frigjøre kaien til neste bil. Nå er alle prosesser konfigurert på en slik måte at denne buffersonen rett og slett ikke er nødvendig. Det er selektive gjentellinger (ett eksempel er prosessen med selektiv gjentelling innen pakke for kryssdokking i et lager, implementert i «Traffic Light»-prosjektet), men det meste av varene behandles umiddelbart ved mottak og det er fra kaien at de reiser til det optimale stedet på lageret eller umiddelbart til en annen brygge for lasting dersom transport for forsendelse fra lageret allerede er kommet. Jeg vet at dette høres litt hverdagslig ut for deg, men for fem år siden, i et enormt lager, virket det som noe ut av et romprogram for oss å kunne behandle en forsendelse direkte til endepunkter som en lastebrygge for en annen lastebil.
Hva skjer ved siden av produktet?
Deretter, hvis dette ikke er cross-docking (og varene ikke allerede har gått inn i bufferen før sending eller direkte til kaien), må den settes på lager for lagring.
Det er nødvendig å bestemme hvor dette produktet skal gå, i hvilken lagringscelle. I den gamle prosessen var det nødvendig å visuelt bestemme i hvilken sone vi lagrer varer av denne typen, og deretter velge et sted der og ta det, legg det, skriv ned hva vi legger det. Nå har vi satt opp plasseringsruter for hvert produkt i henhold til topologien. Vi vet hvilket produkt som skal gå inn i hvilken sone og inn i hvilken celle, vi vet hvor mange ekstra celler som skal oppta i nærheten hvis det er overdimensjonert. En person nærmer seg pallen og skanner den med SSCC ved hjelp av TSD. Skanneren viser: "Ta den til A101-0001-002." Så tar han den dit og noterer hva han la der, og stikker skanneren i koden på stedet. Systemet sjekker at alt er riktig og noterer det. Det er ikke nødvendig å skrive noe.
Dette avslutter første del av arbeidet med produktet. Da er butikken klar til å hente den fra lageret. Og dette gir opphav til neste prosess, som kolleger fra innkjøpsavdelingen bedre vil fortelle om.
Så i systemet oppdateres beholdningen i det øyeblikket bestillingen aksepteres. Og cellens lager er i det øyeblikket pallen er plassert i den. Det vil si at vi alltid vet hvor mange varer som er totalt på lageret og hvor nøyaktig hvert produkt befinner seg.
Mange flyter fungerer direkte til hubs (regionale omlastingslagre) fordi vi har mange lokale leverandører i hver region. Det er mer praktisk å installere de samme klimaanleggene fra Voronezh ikke på det føderale lageret, men direkte til lokale knutepunkter, hvis dette er raskere.
Omvendte avfallsstrømmer er også litt optimalisert: hvis varene er cross-docking, kan leverandøren hente den fra et lager i Moskva. Hvis feilen ble avslørt etter åpning av transportpakken (og det ikke var tydelig fra utsiden, det vil si at det ikke var transportarbeidernes feil), så er det retursoner i hver butikk. Defekten kan sendes til et føderalt lager, eller den kan gis til leverandøren direkte fra butikken. Det andre skjer oftere.
En annen prosess som nå trenger optimalisering er behandling av usolgte sesongvarer. Faktum er at vi har to viktige årstider: Nyttår og hagetid. Det vil si at vi i januar mottar usolgte kunstige trær og girlandere på distribusjonssentralen, og til vinteren mottar vi gressklippere og andre sesongvarer som må bevares om de overlever ett år til. I teorien må vi selge dem helt på slutten av sesongen eller gi dem til noen andre, og ikke dra dem tilbake til lageret - dette er den delen hvor vi ikke har fått det til ennå.
I løpet av fem år har vi redusert tiden for varemottak (lossing av maskinen) med fire ganger og fremskyndet en rekke andre prosesser, som til sammen har forbedret crossdocking-omsetningen med litt over halvparten. Vår oppgave er optimalisering for å redusere varelageret og ikke "fryse" penger på lageret. Og de gjorde det mulig for butikker å få varene de trengte litt mer i tide.
For lagerprosesser var de store forbedringene å automatisere det som pleide å være papir, kvitte seg med unødvendige trinn i prosessen gjennom utstyr og riktig konfigurerte prosesser, og koble alle selskapets IT-systemer til en helhet slik at en ordre fra ERP ( for eksempel at butikken mangler noe på tredje hylle til venstre) ble til slutt omgjort til spesifikke handlinger i lagersystemet, bestilling av transport, og så videre. Nå handler optimalisering mer om de prosessene vi ennå ikke har kommet til, og matematikken til prognoser. Det vil si at æraen med rask implementering er over, vi har gjort de 30 % av arbeidet som ga 60 % av resultatet, og så må vi gradvis dekke resten. Eller flytt til andre områder hvis mer kan gjøres der.
Vel, regner man med lagrede trær, så ga også overgangen av leverandører til EDI-portaler mye. Nå ringer eller kommuniserer ikke nesten alle leverandører med lederen, men ser på bestillinger på deres personlige konto, bekrefter dem og leverer varene. Når det er mulig, nekter vi papir; siden 2014 har 98 % av leverandørene allerede brukt elektronisk dokumenthåndtering. Totalt er dette 3 trær som er reddet i løpet av et år bare ved å slippe å skrive ut alle nødvendige papirer. Men dette tar ikke hensyn til varmen fra prosessorene, men også uten å ta hensyn til den sparte arbeidstiden til folk som de samme lederne på telefonen.
På fem år hadde vi fire ganger så mange butikker, tre ganger så mange ulike dokumenter, og hadde det ikke vært for EDI hadde vi hatt tre ganger så mange regnskapsførere.
Vi stopper ikke der og fortsetter å koble nye meldinger til EDI, nye leverandører til elektronisk dokumenthåndtering.
I fjor åpnet vi det største distribusjonssenteret i Europa - 140 tusen kvm. m - og satte i gang med å mekanisere den. Jeg vil snakke om dette i en annen artikkel.
Kilde: www.habr.com