Zebra WT-40 dataopsamlingsterminal med ringscanner. Det er nødvendigt for hurtigt at kunne scanne produktet, mens kasserne fysisk placeres på en palle (håndfri).
I løbet af flere år åbnede vi butikker og voksede meget hurtigt. Det endte med, at vores lagre nu modtager og sender omkring 20 tusind paller om dagen. Naturligvis har vi allerede i dag flere lagre: to store i Moskva - 100 og 140 tusinde kvadratmeter, men der er også små i andre byer.
Hvert sekund, der spares i processerne med at modtage, samle eller sende varer i en sådan skala, er en mulighed for at spare tid på driften. Og det er også en kæmpe besparelse.
Derfor er de to vigtigste effektivitetsmultiplikatorer en gennemtænkt algoritme af handlinger (proces) og tilpassede it-systemer. Helst "som et ur", men "at arbejde lidt mindre end perfekt" er også ganske velegnet. Vi er trods alt i den virkelige verden.
Historien begyndte for seks år siden, da vi kiggede nærmere på, hvordan leverandører præcis læsser lastbiler af på vores lager. Det var så ulogisk, men vanemæssigt, at medarbejderne ikke engang bemærkede, at processen ikke var optimal. Desuden havde vi på det tidspunkt ikke et industrielt lagerstyringssystem, og vi stolede hovedsageligt på logistikdriften til 3PL-operatører, som brugte deres software og erfaring i byggeprocesser.
Modtagelse af varer
Som vi allerede har sagt, søgte vores virksomhed på det tidspunkt (som i princippet nu) at åbne mange butikker, så vi var nødt til at optimere lagerprocesserne for at øge gennemløbet (flere varer på kortere tid). Det er ikke en nem opgave, og det var umuligt at løse det ved blot at øge personalet, om ikke andet fordi alle disse mennesker ville blande sig i hinanden. Derfor begyndte vi at tænke på at implementere et WMS (warehouse management system) informationssystem. Som forventet startede vi med en beskrivelse af mållagerprocesserne, og allerede i begyndelsen opdagede vi en upløjet mark for forbedringer i processen med at modtage varer. Det var nødvendigt at udarbejde processerne i et af lagrene for derefter at rulle dem ud til resten.
Modtagelse er en af de første større operationer på et lager. Det findes i flere typer: når vi blot tæller antallet af laststykker, og når vi udover dette skal tælle hvor mange og hvilke slags artikler der er på hver palle. De fleste af vores varer passerer gennem cross-docking-strømmen. Det er, når varer ankommer til lageret fra leverandøren, og lageret fungerer som en router og forsøger straks at gensende dem til den endelige modtager (butik). Der er andre flows, for eksempel når lageret fungerer som en cache eller som en lagerenhed (du skal lægge forsyningen på lager, opdele den i dele og gradvist transportere den til butikker). Sandsynligvis vil mine kolleger, der arbejder på matematiske modeller til optimering af restprodukter, fortælle dig bedre om arbejdet med lager. Men her er en overraskelse! Problemer begyndte at opstå rent i manuelle operationer.
Processen så sådan ud: lastbilen ankom, chaufføren udvekslede dokumenter med lageradministratoren, administratoren forstod, hvad der var ankommet der, og hvor den skulle sendes, så bad han læsseren om at hente varerne. Alt dette tog omkring tre timer (naturligvis afhænger accepttiden i høj grad af, hvilken slags logistikflow vi accepterer: nogle steder er det nødvendigt at lave en intern gentælling, og andre ikke). Det er umuligt at sende flere mennesker til en lastbil: de vil forstyrre hinanden.
Hvad var tabene? Der var et hav af dem. Først modtog lagerarbejdere papirdokumenter. De navigerede og traf beslutninger om, hvad de skulle gøre med forsyningen baseret på dem. For det andet talte de pallerne manuelt og noterede mængderne på de samme følgesedler. Herefter blev de udfyldte acceptblanketter sendt til en computer, hvor data blev lagt ind i en XLS-fil. Dataene fra denne fil blev derefter importeret til ERP'en, og først derefter så vores it-kerne faktisk produktet. Vi havde meget få metadata om ordren, såsom transportankomsttid, eller disse data var unøjagtige.
Det første, vi gjorde, var at begynde at automatisere selve lagrene, så de ville have support til processer (vi skulle installere en masse software, hardware som mobile stregkodescannere og implementere infrastrukturen til alt dette). Så har vi forbundet disse systemer med ERP via en bus. I sidste ende opdateres information om tilgængeligheden af varer i systemet, når læsseren kører en stregkodescanner hen over pallen på den ankommende lastbil.
Det blev sådan her:
- Leverandøren udfylder selv data om, hvad han sender til os og hvornår. Til dette er der en kombination af SWP- og EDI-portaler. Det vil sige, at butikken offentliggør en ordre, og leverandører forpligter sig til at opfylde ordren og levere varerne i den nødvendige mængde. Ved afsendelse af varerne angiver de sammensætningen af pallerne i lastbilen og alle nødvendige logistikoplysninger.
- Når bilen forlader leverandøren for os, ved vi allerede, hvilket produkt der kommer til os; Desuden er der etableret elektronisk dokumenthåndtering med leverandører, så vi ved, at UPD'en allerede er underskrevet. En ordning for den optimale bevægelse af dette produkt er ved at blive udarbejdet: hvis dette er cross-docking, så har vi allerede bestilt transport fra lageret, regner med varerne, og for alle logistikstrømme har vi allerede bestemt, hvor mange lagerressourcer vi vil behov for at behandle leverancer. I cross-docking detaljer foretages den foreløbige planlægning af transport fra lageret på et tidligere tidspunkt, når leverandøren netop har reserveret en leveringsplads i lagerportstyringssystemet (YMS - yard management system), som er integreret med leverandørportalen . Information kommer til YMS med det samme.
- YMS modtager lastbilnummeret (for at være mere præcis, forsendelsesnummeret fra SWP) og registrerer chaufføren til accept, det vil sige, tildeler ham det nødvendige tidsrum. Det vil sige, at nu behøver chaufføren, der kom rettidigt, ikke stå i kø, og hans lovlige tid og losseplads er tildelt ham. Dette gjorde det blandt andet muligt for os at fordele lastbiler optimalt i hele territoriet og bruge lossepladser mere effektivt. Og da vi på forhånd laver en tidsplan om, hvem der kommer hvor og hvornår, ved vi, hvor mange mennesker der er brug for, og hvor. Det vil sige, at dette også er relateret til lagermedarbejdernes arbejdsplaner.
- Som et resultat af denne magi behøver læssere ikke længere yderligere ruteføring, men venter kun på, at biler læsser dem af. Faktisk fortæller deres værktøj - terminalen - dem, hvad de skal gøre og hvornår. På abstraktionsniveau er det ligesom loader API, men i en menneske-computer interaktionsmodel. Det øjeblik, den første palle scannes fra lastbilen, er også en registrering af leveringsmetadata.
- Aflæsning sker stadig i hånden, men læsseren kører en stregkodescanner på hver palle og bekræfter, at etiketdata er i orden. Systemet sørger for, at det er den rigtige palle, vi forventer. Ved afslutningen af losningen vil systemet have en nøjagtig optælling af alle lastemner. På dette stadium er defekter stadig elimineret: Hvis der er åbenlyse skader på transportbeholderen, er det nok blot at bemærke dette under aflæsningsprocessen eller slet ikke acceptere dette produkt, hvis det er helt ubrugeligt.
- Tidligere blev paller talt i aflæsningsområdet, efter at alle var blevet læsset af lastbilen. Nu er processen med fysisk aflæsning en genberegning. Vi returnerer fejlen med det samme, hvis den er åbenbar. Hvis det ikke er indlysende og opdages senere, så samler vi det i en særlig buffer på lageret. Det er meget hurtigere at smide pallen længere ind i processen, samle et dusin af dem og give leverandøren mulighed for at hente alt på én gang i et separat besøg. Nogle typer af mangler overføres til genbrugszonen (det gælder ofte udenlandske leverandører, som har nemmere ved at modtage fotografier og sende et nyt produkt end at tage imod det tilbage over grænsen).
- Ved afslutningen af aflæsningen underskrives dokumenter, og chaufføren tager af sted for at udføre sit arbejde.
I den gamle proces blev paller ofte flyttet til en særlig bufferzone, hvor der allerede blev arbejdet med dem: de blev talt, ægteskab blev registreret og så videre. Dette var nødvendigt for at frigøre kajen til den næste bil. Nu er alle processer konfigureret på en sådan måde, at denne bufferzone simpelthen ikke er nødvendig. Der er selektive gentællinger (et eksempel er processen med selektiv intra-pakke gentælling til crossdocking i et lager, implementeret i "Traffic Light"-projektet), men de fleste af varerne behandles umiddelbart efter modtagelsen, og det er fra kajen at de rejser til det optimale sted på lageret eller straks til en anden dok for lastning, hvis transport til forsendelse fra lageret allerede er ankommet. Jeg ved godt, at det lyder lidt hverdagsagtigt for dig, men for fem år siden, i et enormt lager, virkede det som noget ud af et rumprogram for os at kunne behandle en forsendelse direkte til endepunkter som en læsseplads for en anden lastbil.
Hvad sker der ved siden af produktet?
Dernæst, hvis dette ikke er cross-docking (og varerne ikke allerede er gået i bufferen før afsendelse eller direkte til kajen), så skal det lægges på lager til opbevaring.
Det er nødvendigt at bestemme, hvor dette produkt vil gå, i hvilken opbevaringscelle. I den gamle proces var det nødvendigt visuelt at bestemme, i hvilken zone vi opbevarer varer af denne type, og derefter vælge et sted der og tage det, sætte det, skrive ned, hvad vi lægger det. Nu har vi opsat placeringsruter for hvert produkt i henhold til topologien. Vi ved hvilket produkt der skal gå ind i hvilken zone og ind i hvilken celle, vi ved hvor mange ekstra celler der skal optages i nærheden, hvis det er overdimensioneret. En person nærmer sig pallen og scanner den med SSCC ved hjælp af TSD. Scanneren viser: "Tag den til A101-0001-002." Så tager han den derhen og noterer, hvad han har lagt der, og prikker scanneren i koden på stedet. Systemet tjekker at alt er korrekt og noterer det. Der er ingen grund til at skrive noget.
Dette afslutter den første del af arbejdet med produktet. Så er butikken klar til at hente den på lageret. Og det giver anledning til næste proces, som kollegaer fra indkøbsafdelingen bedre fortæller om.
Så i systemet opdateres lagerbeholdningen i det øjeblik, ordren accepteres. Og cellens lager er i det øjeblik, pallen er placeret i den. Det vil sige, at vi altid ved, hvor mange varer der i alt er på lageret, og hvor præcist hvert produkt befinder sig.
Mange flows arbejder direkte til hubs (regionale omladningslagre), fordi vi har mange lokale leverandører i hver region. Det er mere praktisk at installere de samme klimaanlæg fra Voronezh ikke på det føderale lager, men direkte til lokale hubs, hvis dette er hurtigere.
Omvendte affaldsstrømme er også en smule optimeret: Hvis varerne cross-docking, kan leverandøren hente det fra et lager i Moskva. Hvis manglen blev afsløret efter åbning af transportpakken (og det ikke var tydeligt udefra, dvs. det var ikke transportarbejdernes skyld), så er der returzoner i hver butik. Defekten kan sendes til et føderalt lager, eller den kan gives til leverandøren direkte fra butikken. Det andet sker oftere.
En anden proces, der nu trænger til optimering, er forarbejdning af usolgte sæsonvarer. Faktum er, at vi har to vigtige årstider: nytår og havearbejde. Det vil sige, at vi i januar modtager usolgte kunstige træer og guirlander på distributionscenteret, og til vinteren modtager vi plæneklippere og andet sæsongods, som skal bevares, hvis de overlever endnu et år. I teorien skal vi sælge dem fuldstændigt i slutningen af sæsonen eller give dem til en anden, og ikke trække dem tilbage til lageret - det er den del, hvor vi ikke er nået til det endnu.
I løbet af fem år har vi fire gange reduceret tiden til varemodtagelse (aflæsning af maskinen) og accelereret en række andre processer, hvilket samlet set har forbedret crossdocking-omsætningen med lidt mere end det halve. Vores opgave er optimering for at reducere lagerbeholdningen og ikke "fryse" penge på lageret. Og de gjorde det muligt for butikkerne at modtage de varer, de skulle bruge lidt mere til tiden.
For lagerprocesser var de store forbedringer at automatisere det, der plejede at være papir, slippe af med unødvendige trin i processen gennem udstyr og korrekt konfigurerede processer og koble alle virksomhedens it-systemer til en samlet helhed, så en ordre fra ERP'en ( fx mangler butikken noget på den tredje hylde til venstre) i sidste ende blev til specifikke handlinger i lagersystemet, bestilling af transport og så videre. Nu handler optimering mere om de processer, som vi endnu ikke er nået til, og matematikken i forecasting. Det vil sige, at æraen med hurtig implementering er forbi, vi har udført de 30 % af arbejdet, der gav 60 % af resultatet, og så skal vi gradvist dække resten. Eller flyt til andre områder, hvis der kan gøres mere der.
Tja, hvis man tæller i sparede træer, så gav overgangen af leverandører til EDI-portaler også meget. Nu ringer eller kommunikerer næsten alle leverandører ikke med lederen, men ser på ordrer på deres personlige konto, bekræfter dem og leverer varerne. Når det er muligt, afviser vi papir; siden 2014 har 98 % af leverandørerne allerede brugt elektronisk dokumenthåndtering. I alt er det 3 træer, der er reddet på et år, blot ved ikke at skulle printe alle de nødvendige papirer ud. Men dette tager ikke højde for varmen fra processorerne, men også uden at tage højde for den sparede arbejdstid for folk som de samme ledere på telefonen.
På fem år havde vi fire gange så mange butikker, tre gange så mange forskellige dokumenter, og hvis det ikke var for EDI, havde vi haft tre gange så mange revisorer.
Vi stopper ikke der og fortsætter med at koble nye beskeder til EDI, nye leverandører til elektronisk dokumenthåndtering.
Sidste år åbnede vi det største distributionscenter i Europa - 140 tusinde kvm. m - og gik i gang med at mekanisere det. Jeg vil tale om dette i en anden artikel.
Kilde: www.habr.com