Datenkolekta terminalo Zebra WT-40 kun ringa skanilo. Ĝi estas bezonata por povi rapide skani la varojn, dum fizike stakante la skatolojn sur paledo (senmane).
Dum pluraj jaroj, ni malfermis vendejojn tre rapide kaj kreskis. Ĝi finiĝis per tio, ke nun niaj magazenoj ricevas kaj sendas ĉirkaŭ 20 mil paledojn tage. Kompreneble, hodiaŭ ni jam havas pli da magazenoj: du grandaj en Moskvo - 100 kaj 140 mil kvadrataj metroj, sed ankaŭ estas malgrandaj en aliaj urboj.
Ĉiu sekundo ŝparita en la procezo de ricevado, kunigo aŭ sendo de varoj sur tia skalo estas ŝanco ŝpari tempon pri operacioj. Kaj ĝi ankaŭ estas grandega ŝparado.
Tial la du ĉefaj efikaj faktoroj estas bone pripensita algoritmo de agoj (procezo) kaj personecigitaj IT-sistemoj. Prefere "kiel horloĝo", sed ankaŭ "funkcii iom malpli ol perfekte" estas sufiĉe taŭga. Tamen ni estas en la reala mondo.
La rakonto komenciĝis antaŭ ses jaroj, kiam ni pli detale rigardis ĝuste kiel provizantoj malŝarĝas kamionojn en nia magazeno. Ĝi estis tiel mallogika, sed konata, ke la dungitoj eĉ ne rimarkis la suboptimuman procezon. Krome, en tiu momento ni ne havis industrian magazenan administradsistemon, kaj esence ni fidis 3PL-funkciigistojn, kiuj uzis sian programaron kaj sperton en konstruado de procezoj por loĝistikaj operacioj.
Akcepto de varoj
Kiel ni diris, nia firmao tiutempe (kiel, principe, nun) strebis malfermi multajn vendejojn, do ni devis optimumigi stokajn procezojn por pliigi trafluon (pli da varoj en malpli da tempo). Ĉi tio ne estas facila tasko, kaj estis neeble solvi ĝin simple pliigante la personaron, se nur ĉar ĉiuj ĉi tiuj homoj malhelpos unu la alian. Tiel, ni ekpensis pri efektivigo de informsistemo WMS (warehouse management system). Kiel atendite, ni komencis kun priskribo de la celaj stokprocezoj kaj jam komence trovis nekultivitan kampon por plibonigoj en la procezo de ricevado de varoj. Necesis ellabori la procezojn en unu el la magazenoj, por poste ruli ilin al la ceteraj.
Ricevado estas unu el la unuaj grandaj operacioj en magazeno. Ĝi povas esti de pluraj tipoj: kiam ni simple rekalkulas la nombron da pakaĵoj kaj kiam ni bezonas, krome, kalkuli kiom kaj kiaj artikoloj estas sur ĉiu paleto. La plej multaj el niaj varoj pasas tra la transdoka rivereto. Jen kiam varoj alvenas al la magazeno de la provizanto, kaj la magazeno funkcias kiel enkursigilo kaj provas tuj resendi ilin al la fina ricevanto (butiko). Estas aliaj fluoj, ekzemple, kiam la magazeno funkcias kiel kaŝmemoro aŭ kiel vendejo (vi devas meti la provizon en stoko, dividi ĝin en partojn kaj iom post iom elporti ĝin al vendejoj). Verŝajne, miaj kolegoj, kiuj okupiĝas pri matematikaj modeloj de optimumigo de restaĵoj, pli bone rakontos pri laboro kun stoko. Sed jen surprizo! Problemoj ekestis nur pri manaj operacioj.
La procezo aspektis jene: alvenis la kamiono, la ŝoforo interŝanĝis dokumentojn kun la magazena administranto, la administranto komprenis, kio alvenis tien kaj kien sendi ĝin, poste li sendis la ŝargilon preni la varojn. Ĉio ĉi daŭris ĉirkaŭ tri horojn (kompreneble, la akcepta tempo grandparte dependas de kia loĝistika fluo ni akceptas: ie necesas fari rekalkulon en la pakaĵo, sed ie ne). Pli da homoj ne povas esti senditaj al unu kamiono: ili malhelpos unu la alian.
Kio estis la perdoj? Ili estis la maro. Unue, magazenaj laboristoj ricevis paperajn dokumentojn. Ili estis gviditaj kaj faris decidojn pri tio, kion fari kun la provizo, laŭ ili. Due, ili kalkulis la paletojn mane kaj notis la kvantojn sur la samaj veturbiletoj. Tiam la kompletigitaj akceptoformularoj estis prenitaj al komputilo, kie la datumoj estis enigitaj en XLS-dosieron. La datumoj de ĉi tiu dosiero tiam estis importitaj en ERP, kaj nur tiam nia IT-kerno efektive vidis la produkton. Ni havis tre malmulte da metadatenoj pri la ordo, kiel la alventempo de la transporto, aŭ ĉi tiuj datumoj estis malprecizaj.
La unua afero, kiun ni faris, estis komenci aŭtomatigi la stokejojn mem por ke ili havu procezan subtenon (necesis amaso da programaro, aparataro kiel moveblaj strekkodaj skaniloj, deploji la infrastrukturon por ĉio ĉi). Tiam ili kunligis ĉi tiujn sistemojn kun ERP per buso. Finfine, haveblecaj informoj estas ĝisdatigitaj en la sistemo kiam ŝargilo prizorgas strekkodskanilon super paledo sur alvenanta kamiono.
Fariĝis jene:
- La provizanto mem plenigas la datumojn pri tio, kion li sendas al ni kaj kiam. Estas amaso da SWP kaj EDI-portaloj por ĉi tio. Tio estas, la vendejo publikigas la mendon, kaj la provizantoj entreprenas plenumi la peton kaj provizi la varojn en la bezonata kvanto. Sendante la varojn, ili ankaŭ indikas la konsiston de la paledoj en la kamiono kaj ĉiujn necesajn informojn de loĝistika naturo.
- Kiam la aŭto lasis la provizanton por ni, ni jam scias, kiaj varoj venas al ni; Krome, elektronika dokumenta administrado estis establita kun provizantoj, do ni scias, ke la UPD jam estis subskribita. Skemo estas preparita por la optimuma movado de ĉi tiu produkto: se ĉi tio estas transdokiĝo, tiam ni jam mendis transporton de la magazeno, kalkulante je la varoj, kaj por ĉiuj loĝistikaj fluoj ni jam determinis kiom da stokaj rimedoj ni faros. bezonas prilabori liveraĵojn. En transdokaj detaloj, antaŭplano por transportado el la magazeno estas farita en pli frua etapo, kiam la provizanto ĵus rezervis liveran fendon en la mastruma sistemo de pordo de la magazeno (YMS - korta administradsistemo), kiu estas integrita kun la provizanto. portalo. Informoj venas al YMS tuj.
- YMS ricevas la kamion-numeron (por esti pli preciza, la sendo-numeron de la SWP) kaj registras la ŝoforon por akcepto, tio estas, asignas al li la necesan tempon. Tio estas, nun la ŝoforo, kiu alvenis ĝustatempe, ne bezonas atendi vivan vicon, kaj lia laŭleĝa tempo kaj la malŝarĝa doko estas asignitaj por li. Ĉi tio permesis al ni, interalie, optimume distribui kamionojn tra la teritorio kaj uzi la malŝarĝajn fendojn pli efike. Kaj ankaŭ, ĉar ni faras horaron anticipe, kiu, kie kaj kiam alvenos, ni scias kiom da homoj kaj kie ni bezonas. Tio estas, ĝi ankaŭ estas ligita kun la laborhoraroj de magazenaj dungitoj.
- Sekve de ĉi tiu magio, ŝargiloj ne plu bezonas plian vojigon, sed nur atendas aŭtojn por malŝarĝi ilin. Fakte, ilia ilo - la terminalo - diras al ili kion fari kaj kiam. Je la abstrakta nivelo, ĝi estas kiel la ŝargilo API, sed en la homa-komputila interagado modelo. La momento de skanado de la unua paleto de la kamiono ankaŭ estas rekordo de la liveraj metadatenoj.
- Malŝarĝo ankoraŭ estas farita mane, sed por ĉiu paledo la ŝargilo funkciigas strekkodskanilon kaj konfirmas ke la etikeddatenoj estas en ordo. La sistemo kontrolas, ke ĝi estas la ĝusta paleto, kiun ni atendas. Antaŭ la fino de malŝarĝo, la sistemo havos precizan rekalkulon de ĉiuj pakaĵoj. En ĉi tiu etapo, geedziĝo ankoraŭ estas forigita: se estas evidenta damaĝo al la ekspedujo, tiam sufiĉas nur rimarki tion dum la malŝarĝa procezo aŭ tute ne akcepti ĉi tiun produkton, se ĝi estas tute neuzebla.
- Antaŭe, paledoj estis nombritaj en la malŝarĝa areo post kiam ĉiuj estis malŝarĝitaj de la kamiono. Nun la procezo de fizika malŝarĝo estas rekalkulo. Ni resendas la geedziĝon tuj se ĝi estas evidenta. Se ĝi ne estas evidenta kaj estas trovita poste, tiam ni amasigas ĝin en speciala bufro en la magazeno. Estas multe pli rapide ĵeti paleton plu en la procezon, kolekti dekduon da ĉi tiuj kaj lasi la provizanton preni ĉion samtempe en unu aparta vizito. Iuj specoj de difektoj estas transdonitaj al la reciklada zono (tio ofte validas por eksterlandaj provizantoj, kiuj trovas pli facile ricevi fotojn kaj sendi novan produkton ol repreni ĝin trans la landlimon).
- Ĉe la fino de malŝarĝo, dokumentoj estas subskribitaj, kaj la ŝoforo foriras por sia propra komerco.
En la malnova procezo, paletoj ofte estis movitaj al speciala bufrozono, kie ili jam estis prilaboritaj: ili estis kalkulitaj, geedziĝo estis registrita, ktp. Ĉi tio estis necesa por liberigi la dokon por la sekva maŝino. Nun ĉiuj procezoj estas agorditaj tiel ke ĉi tiu bufrozono simple ne estas bezonata. Estas selektemaj rekalkuloj (unu el la ekzemploj estas la procezo de selektema intra-ujo rekalkulado por transdokado en magazeno, efektivigita en la projekto Svetofor), sed la plej multaj el la varoj estas procesitaj tuj post akcepto kaj estas de la doko ke ĝi iras al la optimuma loko en la magazeno aŭ tuj al alia doko por ŝarĝo, se la transporto por sendo de la magazeno jam alvenis. Mi scias, ke tio sonas al vi iom sekulara, sed antaŭ kvin jaroj, en grandega magazeno, povi procesi sendon rekte al finpunktoj kiel ŝarĝodoko por alia kamiono ŝajnis al ni speco de spaca programo.
Kio okazas poste kun la produkto?
Plue, se ĉi tio ne estas transdokado (kaj la varoj ne jam foriris al la bufro antaŭ ekspedo aŭ rekte al la doko), tiam ĝi devas esti metita en stokon por stokado.
Estas necese determini kien ĉi tiu produkto iros, al kiu stoka ĉelo. En la malnova procezo, estis necese vide determini en kiu zono ni stokas varojn de difinita tipo, kaj poste elekti lokon tie kaj preni, meti, noti tion, kio estis metita. Nun ni agordis lokitinerojn por ĉiu produkto laŭ la topologio. Ni scias, kiu produkto devas iri al kiu zono kaj kiun ĉelon, ni scias kiom da ĉeloj preni aldone unu apud la alia, se ĝi estas trogranda. Persono alproksimiĝas al la paledo kaj skanas ĝin kun la SSCC uzante la TSD. La skanilo montras: "Portu ĝin al A101-0001-002." Poste li veturas tien kaj notas kion li metis, enŝovante la skanilon en la kodon en la loko. La sistemo kontrolas, ke ĉio estas ĝusta kaj notas. Vi ne bezonas skribi ion ajn.
Ĉi tio finas la unuan parton de la laboro kun la produkto. Tiam la vendejo pretas preni ĝin el la magazeno. Kaj ĉi tio estigas la sekvan procezon, pri kiu kolegoj de la provizora fako pli bone rakontos.
Do, en la sistemo, la stoko estas ĝisdatigita en la momento de akcepto de la mendo. Kaj la provizo de la ĉelo estas en la momento, kiam la paleto estas metita en ĝin. Tio estas, ni ĉiam scias kiom da varoj estas en stoko entute kaj kie kiu kuŝas specife.
Multaj fluoj funkcias rekte al naboj (regionaj transŝipaj stokejoj), ĉar ni havas multajn lokajn provizantojn en ĉiu regiono. La samaj klimatiziloj de Voronezh estas pli oportune instali ne ĉe la federacia magazeno, sed tuj ĉe lokaj naboj, se ĝi estas pli rapida.
La inversaj fluoj de forĵetoj ankaŭ estas iomete optimumigitaj: se la varoj estas transdokitaj, tiam la provizanto povas preni ilin el magazeno en Moskvo. Se la geedziĝo estis malfermita post la malfermo de la transportpakaĵo (kaj ĝi ne estis klara de ekstere, tio estas, ĝi ne aperis pro la kulpo de la transportistoj), tiam estas revenaj zonoj en ĉiu vendejo. Geedzeco povas esti ĵetita en la federacian magazenon, aŭ vi povas doni ĝin al la provizanto rekte de la vendejo. La dua okazas pli ofte.
Alia procezo, kiu devas esti simpligita nun, estas la uzado de nevenditaj laŭsezonaj aĵoj. La fakto estas, ke ni havas du gravajn sezonojn: la Nova Jaro kaj la tempo de la ĝardeno. Tio estas, en januaro ni ricevas nevenditajn artefaritajn kristnaskajn arbojn kaj girlandojn ĉe la DC, kaj vintre ni ricevas gazontondilojn kaj aliajn sezonajn varojn, kiuj devas esti konservitaj se ili daŭras alian jaron. En teorio, vi devas vendi ilin tute ĉe la fino de la sezono aŭ doni ilin al iu alia, kaj ne treni ilin reen al la magazeno - ĉi tiu estas la parto, kie ni ankoraŭ ne ekhavis niajn manojn.
En kvin jaroj, ni reduktis la tempon de akcepto de varoj (malŝarĝado de la maŝino) je kvar fojojn kaj akcelis kelkajn aliajn procezojn, kiuj entute plibonigis la spezon de transdokado de iom pli ol dufoje. Nia tasko estas optimumigi por redukti la stokon kaj ne "frosti" monon en la magazeno. Kaj ili ebligis al butikoj ricevi la ĝustan produkton iom pli ĝustatempe.
Por stokprocezoj, la grandaj plibonigoj estis aŭtomatigi tion, kio antaŭe estis papero, forigi nenecesajn paŝojn en la procezo pro ekipaĵo kaj konvene agorditaj procezoj, kaj konekti ĉiujn IT-sistemojn de la firmao en ununuran tuton por ke mendo de ERP (ekzemple, en la vendejo mankas io sur la tria breto de maldekstre) fine transformiĝis en konkretajn agojn en la stoksistemo, ordigi transporton, ktp. Nun optimumigo temas pli pri tiuj procezoj, kiujn ni ankoraŭ ne atingis, kaj pri la matematiko de prognozo. Tio estas, la epoko de rapida efektivigo finiĝis, ni faris tiujn 30% de la laboro, kiuj donis 60% de la rezulto, kaj tiam ni devas iom post iom kovri ĉion alian. Aŭ moviĝu al aliaj areoj, se oni povas fari pli tie.
Nu, se ni kalkulas en konservitaj arboj, tiam la transiro de provizantoj al EDI-portaloj ankaŭ donis multon. Nun preskaŭ ĉiuj provizantoj ne vokas aŭ komunikas kun la administranto, sed ili mem rigardas mendojn en sia persona konto, konfirmas ilin kaj liveras la varojn. Se eble, ni rifuzas paperon; ekde 2014, 98% de provizantoj uzas elektronikan dokumentan administradon. Entute temas pri 3 000 arboj ŝparitaj jare nur per rifuzo presi ĉiujn necesajn paperojn. Sed ĉi tio estas sen konsideri la varmegon de la procesoroj, sed ankaŭ sen konsideri la ŝparitan labortempon de homoj kiel la samaj administrantoj ĉe la telefono.
En kvin jaroj, ni kvarobligis la nombron da vendejoj, triobligis la nombron de malsamaj dokumentoj, kaj se ne ekzistus EDI, ni triobligis la nombron de kontistoj.
Ni ne ripozas sur niaj laŭroj kaj daŭre ligas novajn mesaĝojn al EDI, novajn provizantojn al elektronika dokumenta administrado.
Pasintjare ni malfermis la plej grandan distribucentron en Eŭropo - 140 XNUMX sq. m - kaj prenis ĝian mekanizadon. Mi parolos pri tio en alia artikolo.
fonto: www.habr.com