Kuinka nopeutimme tavaroiden purkamisaikaa varastossa

Kuinka nopeutimme tavaroiden purkamisaikaa varastossa
Tiedonkeruupääte Zebra WT-40 rengasskannerilla. Sitä tarvitaan, jotta tavarat voidaan skannata nopeasti samalla kun laatikot pinotaan fyysisesti lavalla (hands free).

Useiden vuosien aikana avasimme myymälöitä erittäin nopeasti ja kasvoimme. Se päättyi siihen, että nyt varastomme vastaanottavat ja lähettävät noin 20 tuhatta lavaa päivässä. Luonnollisesti meillä on nykyään jo enemmän varastoja: kaksi suurta Moskovassa - 100 ja 140 tuhatta neliömetriä, mutta pieniä on myös muissa kaupungeissa.

Joka sekunti, joka säästyy tavaroiden vastaanottamisessa, kokoamisessa tai lähettämisessä tällaisessa mittakaavassa, on mahdollisuus säästää aikaa toiminnassa. Ja se on myös valtava säästö.

Siksi kaksi tärkeintä tehokkuustekijää ovat hyvin harkittu toimintojen (prosessin) algoritmi ja räätälöidyt IT-järjestelmät. Mieluiten "kuin kello", mutta "toimii vähän vähemmän kuin täydellisesti" on myös varsin sopiva. Silti olemme todellisessa maailmassa.

Tarina alkoi kuusi vuotta sitten, kun tarkastelimme tarkemmin, kuinka tavarantoimittajat purkavat kuorma-autoja varastossamme. Se oli niin epäloogista, mutta tuttua, että työntekijät eivät edes huomanneet epäoptimaalista prosessia. Lisäksi meillä ei tuolloin ollut teollista varastonhallintajärjestelmää, ja periaatteessa luotimme 3PL-operaattoreihin, jotka käyttivät ohjelmistoaan ja kokemustaan ​​logistiikkatoimintojen prosessien rakentamisessa.

Kuinka nopeutimme tavaroiden purkamisaikaa varastossa

Tavaroiden vastaanotto

Kuten sanoimme, yrityksemme pyrki tuolloin (kuten periaatteessa nytkin) avaamaan monia myymälöitä, joten jouduimme optimoimaan varastoprosesseja lisätäksemme läpimenoa (enemmän tavaroita lyhyemmässä ajassa). Tämä ei ole helppo tehtävä, ja sitä oli mahdotonta ratkaista yksinkertaisesti lisäämällä henkilöstöä, vaikka vain siksi, että kaikki nämä ihmiset häiritsevät toisiaan. Niinpä aloimme miettiä WMS-tietojärjestelmän (varastonhallintajärjestelmä) käyttöönottoa. Aloitimme odotetusti kohdevarastoprosessien kuvauksella ja jo heti alussa löysimme viljelemättömän pellon parannuksille tavaroiden vastaanottoprosessissa. Prosessit piti selvittää yhdessä varastosta, jotta ne voidaan sitten siirtää muihin varastoihin.

Vastaanotto on yksi ensimmäisistä suurista toiminnoista varastossa. Sitä voi olla useita tyyppejä: kun laskemme yksinkertaisesti pakettien määrän uudelleen ja milloin meidän on lisäksi laskettava kuinka monta ja mitä tuotteita kullakin lavalla on. Suurin osa tuotteistamme kulkee telakkavirran läpi. Tällöin tavarat saapuvat varastoon toimittajalta, ja varasto toimii reitittimenä ja yrittää lähettää ne välittömästi uudelleen lopulliselle vastaanottajalle (myymälälle). Muitakin virtoja on esimerkiksi silloin, kun varasto toimii kätkönä tai myymälänä (tarvike täytyy laittaa varastoon, jakaa osiin ja viedä vähitellen kauppoihin). Luultavasti kollegani, jotka harjoittavat jäännösten optimoinnin matemaattisia malleja, kertovat paremmin varaston kanssa työskentelystä. Mutta tässä on yllätys! Ongelmat alkoivat ilmaantua puhtaasti manuaalisista toiminnoista.

Prosessi näytti tältä: kuorma-auto saapui, kuljettaja vaihtoi asiakirjoja varastonhoitajan kanssa, ylläpitäjä ymmärsi mitä sinne oli saapunut ja minne se lähetetään, sitten hän lähetti kuormaajan noutamaan tavarat. Kaikki tämä kesti noin kolme tuntia (hyväksymisaika tietysti riippuu pitkälti siitä, millaisen logistiikkavirran hyväksymme: jossain on pakko tehdä paketin sisäinen uudelleenlaskenta, mutta jossain ei). Yhdelle kuorma-autolle ei voida lähettää enempää ihmisiä: he häiritsevät toisiaan.

Mitkä olivat tappiot? Ne olivat meri. Ensin varastotyöntekijät saivat paperiasiakirjat. Heitä ohjattiin ja tehtiin päätöksiä siitä, mitä heidän mukaansa toimitukselle tehdään. Toiseksi he laskivat lavat käsin ja merkitsivät määrät samoihin rahtikirjoihin. Sitten täytetyt hyväksymislomakkeet vietiin tietokoneelle, jossa tiedot syötettiin XLS-tiedostoon. Tämän tiedoston tiedot tuotiin sitten ERP:hen, ja vasta sitten IT-ydin näki tuotteen. Meillä oli hyvin vähän metatietoja tilauksesta, kuten kuljetuksen saapumisaika, tai nämä tiedot olivat epätarkkoja.

Ensimmäinen asia, jonka teimme, oli itse varastojen automatisointi, jotta niillä olisi prosessituki (vaati joukon ohjelmistoja, laitteistoja, kuten mobiili viivakoodilukijat, infrastruktuurin käyttöönotto kaikkeen tähän). Sitten he liittivät nämä järjestelmät ERP:hen väylän kautta. Loppujen lopuksi saatavuustiedot päivittyvät järjestelmään, kun kuormaaja ajaa viivakoodilukijaa saapuvan kuorma-auton lavan yli.

Siitä tuli tällainen:

  1. Toimittaja täyttää itse tiedot siitä, mitä hän lähettää meille ja milloin. Tätä varten on joukko SWP- ja EDI-portaaleja. Toisin sanoen kauppa julkaisee tilauksen ja toimittajat sitoutuvat täyttämään hakemuksen ja toimittamaan tavaraa tarvittavan määrän. Tavaraa lähetettäessä ne ilmoittavat myös kuorma-autossa olevien kuormalavojen koostumuksen ja kaikki tarvittavat logistiset tiedot.
  2. Kun auto lähti toimittajalta meille, tiedämme jo, mitä tavaraa meille on tulossa; Lisäksi sähköinen dokumenttien hallinta on perustettu toimittajien kanssa, joten tiedämme, että UPD on jo allekirjoitettu. Tämän tuotteen optimaalista siirtoa varten valmistellaan suunnitelmaa: jos tämä on ristikkäistelakka, olemme jo tilaaneet kuljetuksen varastosta tavarat huomioon ottaen ja olemme jo määrittäneet kaikille logistiikkavirroille, kuinka paljon varastoresursseja aiomme käyttää. tarve käsitellä toimituksia. Ristitelakointiyksityiskohdassa alustava suunnitelma varastosta tapahtuvaan kuljetukseen tehdään aikaisemmassa vaiheessa, kun toimittaja on juuri varannut toimituspaikan toimittajaan integroidussa varastoovien hallintajärjestelmässä (YMS - yard management system) portaali. Tiedot tulevat YMS:lle välittömästi.
  3. YMS vastaanottaa kuorma-auton numeron (tarkemmin sanottuna lähetysnumeron SWP:ltä) ja kirjaa kuljettajan hyväksyntää varten, eli varaa hänelle tarvittavan aikavälin. Eli nyt ajoissa saapuneen kuljettajan ei tarvitse odottaa elävää jonoa, ja hänen laillinen aikansa ja purkulaituri on varattu hänelle. Tämän ansiosta pystyimme muun muassa jakamaan kuorma-autot optimaalisesti eri puolille aluetta ja käyttämään purkupaikkoja tehokkaammin. Ja myös, koska teemme aikataulun etukäteen, kuka, minne ja milloin saapuu, tiedämme kuinka monta henkilöä ja minne tarvitsemme. Eli se liittyy myös varastotyöntekijöiden työaikatauluihin.
  4. Tämän taian seurauksena kuormaajat eivät enää tarvitse lisäreititystä, vaan vain odottavat autojen purkamista. Itse asiassa heidän työkalunsa - pääte - kertoo heille, mitä tehdä ja milloin. Abstraktiotasolla se on kuin lataussovellusliittymä, mutta ihmisen ja tietokoneen vuorovaikutusmallissa. Ensimmäisen kuormalavan skannaushetki kuorma-autosta on myös tallenteena toimituksen metadatasta.
  5. Purkaminen tapahtuu edelleen käsin, mutta jokaiselle kuormalavalle lastaaja käyttää viivakoodilukijaa ja varmistaa, että tarratiedot ovat kunnossa. Järjestelmä valvoo, että se on oikea lava, jota odotamme. Purkamisen loppuun mennessä järjestelmällä on tarkka uudelleenlaskenta kaikista paketeista. Tässä vaiheessa avioliitto on edelleen eliminoitu: jos kuljetuskontissa on ilmeisiä vaurioita, riittää, että huomaat tämän purkuprosessin aikana tai ei hyväksy tätä tuotetta ollenkaan, jos se on täysin käyttökelvoton.
  6. Aiemmin lavat laskettiin purkualueella sen jälkeen, kun kaikki oli purettu kuorma-autosta. Nyt fyysisen purkamisen prosessi on uudelleenlaskenta. Palautamme avioliiton välittömästi, jos se on ilmeistä. Jos se ei ole ilmeinen ja löydetään myöhemmin, keräämme sen varaston erityiseen puskuriin. On paljon nopeampaa heittää lava syvemmälle prosessiin, kerätä niitä kymmenkunta ja antaa toimittajan noutaa kaikki kerralla yhdellä erillisellä käynnillä. Tietyt viat siirretään kierrätysvyöhykkeelle (tämä koskee usein ulkomaisia ​​toimittajia, joiden mielestä on helpompi saada kuvia ja lähettää uusi tuote kuin viedä se takaisin rajan yli).
  7. Purkamisen lopussa asiakirjat allekirjoitetaan ja kuljettaja lähtee omiin asioihinsa.

Vanhassa prosessissa kuormalavat siirrettiin usein erityiselle puskurivyöhykkeelle, jossa niitä jo työstettiin: ne laskettiin, avioliitto rekisteröitiin ja niin edelleen. Tämä oli tarpeen telakan vapauttamiseksi seuraavaa konetta varten. Nyt kaikki prosessit on konfiguroitu niin, että tätä puskurivyöhykettä ei yksinkertaisesti tarvita. On olemassa valikoivaa uudelleenlaskentaa (yksi esimerkeistä on Svetofor-projektissa toteutettu valikoiva kontinsisäinen uudelleenlaskenta prosessissa ristiintelakointia varten varastossa), mutta suurin osa tavaroista käsitellään heti vastaanottamisen jälkeen ja se on peräisin telakasta. se menee optimaaliseen paikkaan varastossa tai välittömästi toiselle laiturille lastausta varten, jos kuljetus varastosta on jo saapunut. Tiedän, että tämä kuulostaa sinusta hieman arkipäiväiseltä, mutta viisi vuotta sitten se, että pystyimme käsittelemään lähetyksen suoraan päätepisteisiin, kuten toisen kuorma-auton lastauslaituriin, tuntui meille eräänlaiselta avaruusohjelmalta.

Kuinka nopeutimme tavaroiden purkamisaikaa varastossa

Mitä tuotteelle tapahtuu seuraavaksi?

Lisäksi, jos tämä ei ole ristiintelakointi (ja tavarat eivät ole jo lähteneet puskuriin ennen toimitusta tai suoraan telakalle), se on laitettava varastoon varastointia varten.

On tarpeen määrittää, minne tämä tuote menee, mihin varastokennoon. Vanhassa prosessissa oli tarpeen määrittää visuaalisesti, mihin vyöhykkeeseen varastoimme tietyn tyyppisiä tavaroita, ja sitten valita paikka siellä ja ottaa, laittaa, kirjoittaa ylös, mitä laitettiin. Nyt olemme määrittäneet jokaiselle tuotteelle sijoitusreitit topologian mukaan. Tiedämme, minkä tuotteen pitäisi mennä mille vyöhykkeelle ja mihin soluun, tiedämme kuinka monta kennoa vierekkäin tulee ottaa lisäksi, jos se on ylimitoitettu. Henkilö lähestyy lavaa ja skannaa sen SSCC:llä TSD:n avulla. Skanneri näyttää: "Vie se numeroon A101-0001-002." Sitten hän ajaa sinne ja panee merkille, mitä hän laittoi, ja tönäisi skannerin paikalleen koodiin. Järjestelmä tarkistaa, että kaikki on oikein, ja huomauttaa. Sinun ei tarvitse kirjoittaa mitään.

Tämä päättää tuotteen kanssa tehdyn työn ensimmäisen osan. Sitten kauppa on valmis noutamaan sen varastosta. Ja tästä syntyy seuraava prosessi, josta toimitusosaston kollegat kertovat paremmin.

Joten järjestelmässä varasto päivitetään tilauksen hyväksymisen yhteydessä. Ja kennon tarjonta on sillä hetkellä, kun lava asetetaan siihen. Eli tiedämme aina, kuinka monta tavaraa on varastossa yhteensä ja missä mikä niistä sijaitsee.

Monet virrat toimivat suoraan solmukohtiin (alueellisiin jälleenlaivausvarastoihin), koska meillä on monia paikallisia toimittajia jokaisella alueella. Samat Voronežin ilmastointilaitteet on helpompi asentaa ei liittovaltion varastoon, vaan välittömästi paikallisiin solmukohtiin, jos se on nopeampaa.

Myös hylkyjen käänteiset virrat ovat hieman optimoituja: jos tavarat telakoidaan ristiin, toimittaja voi noutaa ne Moskovan varastosta. Jos avioliitto avattiin kuljetuspaketin avaamisen jälkeen (ja se ei ollut selvää ulkopuolelta, eli se ei ilmennyt kuljetustyöntekijöiden syytä), niin jokaisessa kaupassa on palautusalueet. Avioliitto voidaan heittää liittovaltion varastoon, tai voit antaa sen toimittajalle suoraan myymälästä. Toinen tapahtuu useammin.

Toinen prosessi, jota on tehostettava juuri nyt, on myymättömien kausituotteiden käsittely. Tosiasia on, että meillä on kaksi tärkeää vuodenaikaa: uusi vuosi ja puutarhan aika. Eli tammikuussa saamme DC:hen myymättömiä keinotekoisia joulukuusia ja seppeleitä ja talvella ruohonleikkurit ja muut sesonkitavarat, jotka on säilytettävä, jos ne kestävät vielä vuoden. Teoriassa ne pitää myydä kokonaan kauden lopussa tai antaa jollekin toiselle, eikä vetää takaisin varastoon - tämä on se osa, johon emme ole vielä päässeet käsiimme.

Viiden vuoden aikana olemme neljä kertaa lyhentäneet tavaroiden vastaanottoaikaa (koneen purkaminen) ja nopeuttaneet useita muita prosesseja, mikä yhteensä paransi ristiintelakan liikevaihtoa hieman yli kaksinkertaiseksi. Tehtävämme on optimoida varaston pienentämiseksi eikä "jäädyttää" rahaa varastossa. Ja ne mahdollistivat sen, että kaupat saivat oikean tuotteen hieman ajoissa.

Varastoprosesseissa suuria parannuksia olivat entisen paperin automatisointi, prosessin tarpeettomista vaiheista eroon laitteista ja oikein konfiguroiduista prosesseista johtuen sekä yrityksen kaikkien IT-järjestelmien yhdistäminen yhdeksi kokonaisuudeksi niin, että tilaus alkaen ERP (esimerkiksi kaupasta puuttuu jotain kolmannelta hyllyltä vasemmalta) muuttui lopulta konkreettisiksi toimiksi varastojärjestelmässä, kuljetusten tilaamiseen ja niin edelleen. Nyt optimoinnissa on kyse enemmän niistä prosesseista, joihin emme ole vielä päässeet, ja ennustamisen matematiikkaa. Eli nopean toteutuksen aikakausi on ohi, olemme tehneet ne 30 % työstä, joka antoi 60 % tuloksesta, ja sitten meidän on vähitellen katettava kaikki muu. Tai siirry muille alueille, jos siellä voidaan tehdä enemmän.

No, jos lasketaan säästetyt puut, niin myös toimittajien siirtyminen EDI-portaaleihin antoi paljon. Nyt melkein kaikki toimittajat eivät soita tai kommunikoi johtajan kanssa, vaan he itse tarkastelevat tilauksia henkilökohtaisella tilillään, vahvistavat ne ja toimittavat tavarat. Jos mahdollista, kieltäydymme paperista, vuodesta 2014 lähtien 98 % tavarantoimittajista on käyttänyt sähköistä dokumentinhallintaa. Kaikkiaan nämä ovat 3 000 puuta, jotka säästetään vuodessa vain kieltäytymällä painamasta kaikkia tarvittavia papereita. Mutta tämä on ottamatta huomioon prosessorien lämpöä, mutta myös samojen puhelimessa olevien johtajien kaltaisten ihmisten säästettyä työaikaa.

Viiden vuoden aikana olemme nelinkertaistaneet myymälöiden määrän, kolminkertaistaneet eri asiakirjojen määrän, ja jos EDI:tä ei olisi ollut, olisimme kolminkertaistaneet kirjanpitäjien määrän.

Emme lepää laakereillaan ja jatkamme uusien viestien yhdistämistä EDI:hen ja uusien toimittajien sähköiseen dokumenttien hallintaan.

Viime vuonna avasimme Euroopan suurimman jakelukeskuksen - 140 XNUMX neliömetriä. m - ja ryhtyi koneellistamiseen. Puhun tästä toisessa artikkelissa.

Lähde: will.com

Lisää kommentti