Zebra WT-40 datainsamlingsterminal med ringskanner. Det behövs för att snabbt kunna skanna produkten samtidigt som man fysiskt placerar lådorna på en pall (handsfree).
Under flera år öppnade vi butiker och växte väldigt snabbt. Det slutade med att våra lager nu tar emot och skickar cirka 20 tusen pallar per dag. Naturligtvis har vi redan idag fler lager: två stora i Moskva - 100 och 140 tusen kvadratmeter, men det finns också små i andra städer.
Varje sekund som sparas i processerna för att ta emot, montera eller skicka varor i en sådan skala är en möjlighet att spara tid på driften. Och detta är också en enorm besparing.
Det är därför de två huvudsakliga effektivitetsmultiplikatorerna är en genomtänkt algoritm av åtgärder (process) och skräddarsydda IT-system. Helst "som en klocka", men "att fungera lite mindre än perfekt" är också ganska lämpligt. Vi är trots allt i den verkliga världen.
Historien började för sex år sedan, när vi tittade närmare på exakt hur leverantörer lastar av lastbilar i vårt lager. Det var så ologiskt, men vanemässigt, att medarbetarna inte ens märkte att processen inte var optimal. Dessutom hade vi vid det tillfället inget industriellt lagerhanteringssystem, och vi litade huvudsakligen på logistikverksamheten till 3PL-operatörer som använde sin mjukvara och erfarenhet i byggprocesser.
Mottagande av varor
Som vi redan har sagt, försökte vårt företag vid den tiden (som i princip nu) öppna många butiker, så vi var tvungna att optimera lagerprocesser för att öka genomströmningen (mer varor på kortare tid). Det här är ingen lätt uppgift, och det var omöjligt att lösa det genom att bara utöka personalstyrkan, om så bara för att alla dessa människor skulle störa varandra. Därför började vi fundera på att implementera ett WMS (warehouse management system) informationssystem. Som väntat började vi med en beskrivning av mållagerprocesserna och redan i början upptäckte vi ett oplogat fält för förbättringar i processen för att ta emot varor. Det var nödvändigt att arbeta fram processerna i ett av lagren för att sedan rulla ut dem till resten.
Mottagning är en av de första större verksamheterna i ett lager. Det finns i flera typer: när vi helt enkelt räknar antalet laststycken och när vi utöver detta behöver räkna hur många och vilken typ av artiklar som finns på varje pall. De flesta av våra varor passerar genom crossdockningsflödet. Det är då varor anländer till lagret från leverantören, och lagret fungerar som en router och försöker omedelbart skicka om dem till den slutliga mottagaren (butiken). Det finns andra flöden, till exempel när lagret fungerar som en cache eller som en lagringsenhet (du måste lägga förråden i lager, dela upp den i delar och gradvis transportera den till butiker). Förmodligen kommer mina kollegor som arbetar med matematiska modeller för att optimera rester att berätta bättre om att arbeta med lager. Men här är en överraskning! Problem började uppstå enbart i manuella operationer.
Processen såg ut så här: lastbilen anlände, chauffören utbytte dokument med lageradministratören, administratören förstod vad som hade kommit dit och vart den skulle skickas, sedan uppmanade han lastaren att hämta varorna. Allt detta tog cirka tre timmar (naturligtvis beror acceptanstiden till stor del på vilken typ av logistikflöde vi accepterar: på vissa ställen är det nödvändigt att göra en intern omräkning, och på andra inte). Det är omöjligt att skicka fler människor till en lastbil: de kommer att störa varandra.
Vilka var förlusterna? Det fanns ett hav av dem. Först fick lagerarbetare pappersdokument. De navigerade och fattade beslut om vad de skulle göra med utbudet utifrån dem. För det andra räknade de pallarna manuellt och antecknade kvantiteterna på samma följesedel. Därefter skickades de ifyllda antagningsformulären till en dator, där uppgifterna matades in i en XLS-fil. Datan från den här filen importerades sedan till affärssystemet och först då såg vår IT-kärna verkligen produkten. Vi hade väldigt lite metadata om beställningen, som transportens ankomsttid, eller så var denna information felaktig.
Det första vi gjorde var att börja automatisera själva lagren så att de skulle ha stöd för processer (vi behövde installera en massa mjukvara, hårdvara som mobila streckkodsläsare och distribuera infrastrukturen för allt detta). Sedan kopplade vi ihop dessa system med ERP via en buss. I slutändan uppdateras information om tillgången på varor i systemet när lastaren kör en streckkodsläsare över pallen på den ankommande lastbilen.
Det blev så här:
- Leverantören fyller själv i uppgifterna om vad han skickar till oss och när. För detta finns en kombination av SWP- och EDI-portaler. Det vill säga att butiken publicerar en beställning, och leverantörer åtar sig att fullfölja beställningen och leverera varorna i erforderlig kvantitet. När de skickar varorna anger de sammansättningen av pallarna i lastbilen och all nödvändig logistikinformation.
- När bilen lämnar leverantören för oss vet vi redan vilken produkt som kommer till oss; Dessutom har elektronisk dokumenthantering etablerats med leverantörer, så vi vet att UPD redan har undertecknats. Ett schema för optimal förflyttning av denna produkt håller på att förberedas: om detta är cross-docking, har vi redan beställt transport från lagret, räknat med varorna, och för alla logistikflöden har vi redan bestämt hur mycket lagerresurser vi kommer att behöver behandla leveranser. I crossdockningsdetaljer görs preliminär planering för transport från lagret i ett tidigare skede, då leverantören precis har reserverat en leveransplats i lagerportens ledningssystem (YMS - yard management system), som är integrerat med leverantörsportalen . Information kommer till YMS omedelbart.
- YMS får lastbilsnumret (för att vara mer exakt, leveransnumret från SWP) och registrerar chauffören för acceptans, det vill säga tilldelar honom den nödvändiga tidsluckan. Det vill säga, nu behöver inte chauffören som kom i tid stå i kö, och hans lagliga tid och lossningsbrygga tilldelas honom. Detta gjorde att vi bland annat kunde fördela lastbilar över hela territoriet optimalt och använda lossningsplatser mer effektivt. Och eftersom vi gör upp ett schema i förväg om vem som kommer var och när vet vi hur många personer som behövs och var. Det vill säga, detta är också relaterat till arbetsscheman för lageranställda.
- Som ett resultat av denna magi behöver lastare inte längre ytterligare färdvägar, utan väntar bara på att bilarna ska lossa dem. Faktum är att deras verktyg - terminalen - talar om för dem vad de ska göra och när. På abstraktionsnivå är det som loader API, men i en interaktionsmodell mellan människa och dator. Det ögonblick som den första pallen skannas från lastbilen är också en registrering av leveransmetadata.
- Avlastning sker fortfarande för hand, men lastaren kör en streckkodsläsare på varje pall och bekräftar att etikettdata är i sin ordning. Systemet ser till att det är rätt pall som vi förväntar oss. I slutet av lossningen kommer systemet att ha en exakt räkning av alla lastartiklar. I detta skede elimineras fortfarande defekter: om det finns uppenbara skador på transportbehållaren räcker det att helt enkelt notera detta under lossningsprocessen eller inte acceptera den här produkten alls om den är helt oanvändbar.
- Tidigare räknades pallar i lossningsområdet efter att alla lossats från lastbilen. Nu är processen med fysisk lossning en omräkning. Vi returnerar felet omedelbart om det är uppenbart. Om det inte är uppenbart och upptäcks senare, så samlar vi det i en speciell buffert på lagret. Det går mycket snabbare att kasta pallen längre in i processen, samla ett dussin av dem och ge leverantören möjlighet att hämta allt på en gång i ett separat besök. Vissa typer av defekter förs över till återvinningszonen (det gäller ofta utländska leverantörer, som har lättare att ta emot fotografier och skicka en ny produkt än att ta emot den tillbaka över gränsen).
- I slutet av lossningen undertecknas dokument och chauffören går för att göra sitt jobb.
I den gamla processen flyttades pallar ofta till en speciell buffertzon, där man redan arbetade med dem: de räknades, äktenskap registrerades och så vidare. Detta var nödvändigt för att frigöra kajen för nästa bil. Nu är alla processer konfigurerade på ett sådant sätt att denna buffertzon helt enkelt inte behövs. Det finns selektiva omräkningar (ett exempel är processen med selektiv omräkning inom paket för crossdockning i ett lager, implementerad i "Traffic Light"-projektet), men de flesta av varorna behandlas direkt efter mottagandet och det är från kajen att de reser till den optimala platsen i lagret eller omedelbart till en annan brygga för lastning om transport för utsändning från lagret redan har kommit. Jag vet att det här låter lite vardagligt för dig, men för fem år sedan, i ett enormt lager, verkade det för oss att kunna behandla en försändelse direkt till slutpunkter som en lastkaj för en annan lastbil som något ur ett rymdprogram.
Vad händer bredvid produkten?
Därefter, om detta inte är cross-docking (och varorna inte redan har hamnat i bufferten innan frakten eller direkt till kajen), måste den läggas i lager för lagring.
Det är nödvändigt att bestämma var denna produkt kommer att gå, i vilken lagringscell. I den gamla processen var det nödvändigt att visuellt bestämma i vilken zon vi lagrar varor av denna typ och sedan välja en plats där och ta den, lägg den, skriv ner vad vi lägger den. Nu har vi satt upp placeringsvägar för varje produkt enligt topologin. Vi vet vilken produkt som ska gå in i vilken zon och i vilken cell, vi vet hur många ytterligare celler som ska uppta i närheten om den är överdimensionerad. En person närmar sig pallen och skannar den med SSCC med hjälp av TSD. Skannern visar: "Ta den till A101-0001-002." Sedan tar han det dit och noterar vad han lagt där, petar skannern i koden på plats. Systemet kontrollerar att allt stämmer och noterar det. Det finns inget behov av att skriva något.
Detta avslutar den första delen av arbetet med produkten. Då är butiken redo att hämta den från lagret. Och detta ger upphov till nästa process som kollegor från inköpsavdelningen bättre kommer att berätta om.
Så i systemet uppdateras lagret i det ögonblick då beställningen accepteras. Och cellens lager finns i det ögonblick som pallen placeras i den. Det vill säga att vi alltid vet hur många varor som totalt finns på lagret och var exakt varje produkt finns.
Många flöden går direkt till hubbar (regionala omlastningslager) eftersom vi har många lokala leverantörer i varje region. Det är bekvämare att installera samma luftkonditioneringsapparater från Voronezh inte på det federala lagret, utan direkt till lokala nav, om detta är snabbare.
Omvända avfallsflöden är också något optimerade: om varorna är crossdockning kan leverantören hämta det från ett lager i Moskva. Om defekten avslöjades efter att transportförpackningen öppnats (och det inte var tydligt från utsidan, det vill säga att det inte var transportarbetarnas fel), så finns det returzoner i varje butik. Defekten kan skickas till ett federalt lager, eller det kan lämnas till leverantören direkt från butiken. Det andra händer oftare.
En annan process som nu behöver optimeras är bearbetningen av osålda säsongsvaror. Faktum är att vi har två viktiga årstider: nyår och trädgårdstid. Det vill säga i januari tar vi emot osålda konstgjorda träd och girlanger på distributionscentralen och till vintern tar vi emot gräsklippare och andra säsongsvaror som behöver bevaras om de överlever ett år till. I teorin måste vi sälja dem helt i slutet av säsongen eller ge dem till någon annan, och inte dra tillbaka dem till lagret - det här är den delen där vi inte har kommit till det än.
Under loppet av fem år har vi minskat tiden för att ta emot gods (lossa av maskinen) med fyra gånger och accelererat ett antal andra processer, vilket totalt sett har förbättrat crossdockningens omsättning med drygt hälften. Vår uppgift är optimering för att minska lagret och inte ”frysa” pengar på lagret. Och de gjorde det möjligt för butiker att få de varor de behövde lite mer i tid.
För lagerprocesser var de stora förbättringarna att automatisera det som brukade vara papper, bli av med onödiga steg i processen genom utrustning och rätt konfigurerade processer, och koppla ihop alla företagets IT-system till en helhet så att en order från affärssystemet ( t.ex. saknar butiken något på den tredje hyllan till vänster) förvandlades till slut till specifika åtgärder i lagersystemet, beställning av transport, och så vidare. Nu handlar optimering mer om de processer som vi ännu inte har kommit till, och matematiken i prognoser. Det vill säga, eran av snabb implementering är över, vi har gjort de 30 % av arbetet som gav 60 % av resultatet, och sedan måste vi gradvis täcka resten. Eller flytta till andra områden om mer kan göras där.
Jo, om man räknar i sparade träd så gav också övergången av leverantörer till EDI-portaler mycket. Nu ringer nästan alla leverantörer inte eller kommunicerar med chefen, utan tittar på beställningar på sitt personliga konto, bekräftar dem och levererar varorna. När det är möjligt vägrar vi papper, sedan 2014 har 98 % av leverantörerna redan använt elektronisk dokumenthantering. Totalt handlar det om 3 000 träd som sparas på ett år bara genom att inte behöva skriva ut alla nödvändiga papper. Men detta tar inte hänsyn till värmen från processorerna, utan också utan att ta hänsyn till den sparade arbetstiden för personer som samma chefer på telefonen.
På fem år hade vi fyra gånger så många butiker, tre gånger så många olika dokument och om det inte vore för EDI hade vi haft tre gånger så många revisorer.
Vi stannar inte där och fortsätter att koppla nya meddelanden till EDI, nya leverantörer till elektronisk dokumenthantering.
Förra året öppnade vi det största distributionscentret i Europa - 140 tusen kvm. m - och satte igång att mekanisera den. Jag kommer att prata om detta i en annan artikel.
Källa: will.com