Zebra WT-40 adatgyűjtő terminál gyűrűszkennerrel. Erre azért van szükség, hogy gyorsan le tudjuk szkennelni a terméket, miközben a dobozokat fizikailag raklapra helyezzük (kihangosítva).
Több év alatt üzleteket nyitottunk, és nagyon gyorsan növekedtünk. Ennek az lett a vége, hogy jelenleg a raktáraink napi körülbelül 20 ezer raklapot fogadnak és szállítanak ki. Természetesen ma már több raktárunk van: két nagy Moszkvában - 100 és 140 ezer négyzetméter, de vannak kicsik más városokban is.
Az áruk ilyen léptékű átvétele, összeszerelése vagy küldése során megspórolt minden másodperc lehetőséget jelent a műveletek időmegtakarítására. És ez is hatalmas megtakarítás.
Éppen ezért a két fő hatékonysági szorzó a cselekvések (folyamatok) jól átgondolt algoritmusa és a testre szabott informatikai rendszerek. Lehetőleg „olyan, mint egy óra”, de a „kicsit kevésbé működik, mint tökéletesen” szintén megfelelő. Végül is a való világban vagyunk.
A történet hat évvel ezelőtt kezdődött, amikor közelebbről megvizsgáltuk, hogyan raktározzák ki a beszállítók a teherautókat a raktárunkban. Ez annyira logikátlan, de megszokott volt, hogy az alkalmazottak észre sem vették, hogy a folyamat nem optimális. Ráadásul abban a pillanatban még nem rendelkeztünk ipari raktárirányítási rendszerrel, a logisztikai műveleteket elsősorban a 3PL üzemeltetőkre bíztuk, akik szoftvereiket és tapasztalataikat az építési folyamatokban használták.
Áruk átvétele
Mint már elmondtuk, cégünk akkoriban (ahogy elvileg most is) sok üzlet nyitására törekedett, így a raktári folyamatokat optimalizálni kellett az áteresztőképesség növelése érdekében (több áru kevesebb idő alatt). Ez nem könnyű feladat, és egyszerűen létszámbővítéssel lehetetlen volt megoldani, már csak azért is, mert ezek az emberek zavarják egymást. Így elkezdtünk gondolkodni egy WMS (raktárkezelő rendszer) információs rendszer bevezetésén. Ahogy az várható volt, a célraktári folyamatok leírásával kezdtük, és már a kezdet kezdetén felfedeztünk egy feltáratlan terepet az áruátvételi folyamat fejlesztésére. Az egyik raktárban ki kellett dolgozni a folyamatokat, hogy aztán kiterjesszék a többibe.
Az átvétel az egyik első nagyobb művelet egy raktárban. Többféle is létezik: amikor egyszerűen megszámoljuk a rakománydarabok számát, és amikor ezen kívül még meg kell számolnunk, hogy egy raklapon hány és milyen cikk található. Áruink nagy része áthalad a keresztdokkolási áramláson. Ekkor érkezik meg az áru a beszállítótól a raktárba, a raktár pedig routerként működik, és igyekszik azonnal újra elküldeni a végső címzettnek (üzletnek). Vannak más folyamatok is, például amikor a raktár gyorsítótárként vagy tárolóegységként működik (a készletet raktárra kell helyezni, részekre kell osztani, és fokozatosan az üzletekbe kell szállítani). Valószínűleg a maradékanyagok optimalizálására szolgáló matematikai modelleken dolgozó kollégáim jobban megmondják a raktárral való munkavégzést. De itt egy meglepetés! A problémák pusztán a kézi műveleteknél kezdtek felmerülni.
A folyamat így nézett ki: megérkezett a kamion, a sofőr okmányokat cserélt a raktári adminisztrátorral, az ügyintéző megértette, hogy mi érkezett oda, és hova kell küldeni, majd utasította a rakodót, hogy vegye fel az árut. Mindez körülbelül három órát vett igénybe (persze az átvételi idő nagyban függ attól, hogy milyen logisztikai folyamatot fogadunk el: van, ahol belső újraszámlálást kell végezni, máshol nem). Lehetetlen több embert küldeni egy kamionra: zavarni fogják egymást.
Mik voltak a veszteségek? Tengernyi volt belőlük. Először a raktári dolgozók kaptak papíralapú dokumentumokat. Ezek alapján navigáltak és döntöttek arról, hogy mit kezdjenek a kínálattal. Másodszor, manuálisan megszámolták a raklapokat, és ugyanazokon a szállítóleveleken feljegyezték a mennyiségeket. Ezután a kitöltött elfogadólapokat számítógépre küldték, ahol az adatok XLS fájlba kerültek. Az ebből a fájlból származó adatokat ezután importálták az ERP-be, és csak ezután látta meg az IT-magunk a terméket. Nagyon kevés metaadatunk volt a rendelésről, például a szállítás érkezési ideje, vagy ezek az adatok pontatlanok voltak.
Az első dolgunk az volt, hogy elkezdtük automatizálni magukat a raktárakat, hogy támogatást kapjanak a folyamatokhoz (egy rakás szoftvert, hardvert, például mobil vonalkód-leolvasókat kellett telepítenünk, és mindehhez az infrastruktúrát telepíteni). Aztán ezeket a rendszereket egy buszon keresztül kapcsoltuk össze az ERP-vel. Végső soron az áruk elérhetőségére vonatkozó információk frissülnek a rendszerben, amikor a rakodó vonalkód-leolvasót futtat az érkező teherautó raklapján.
Ilyen lett:
- A szállító maga tölti ki az adatokat, hogy mit és mikor küld nekünk. Ehhez az SWP és az EDI portálok kombinációja létezik. Vagyis az üzlet megrendelést tesz közzé, a beszállítók pedig vállalják a rendelés teljesítését és az áruk szükséges mennyiségben történő szállítását. Az áru feladásánál feltüntetik a kamionban lévő raklapok összetételét és minden szükséges logisztikai információt.
- Amikor az autó elhagyja a beszállítót értünk, már tudjuk, milyen termék érkezik hozzánk; Sőt, a beszállítókkal kialakították az elektronikus dokumentumkezelést, így tudjuk, hogy az UPD-t már aláírták. Készül egy séma ennek a terméknek az optimális mozgatására: ha ez keresztdokkolás, akkor már megrendeltük a raktárból a szállítást, számolva az áruval, és minden logisztikai folyamatra már meghatároztuk, hogy mennyi raktári erőforrást fogunk igénybe venni. szállítmányok feldolgozására van szükség. A keresztdokkolási részleteknél a raktárból történő szállítás előzetes tervezése egy korábbi szakaszban történik, amikor a beszállító éppen lefoglalt egy szállítási helyet a beszállítói portállal integrált raktárkapu menedzsment rendszerben (YMS - yard management system). . Az információ azonnal érkezik az YMS-hez.
- Az YMS megkapja a kamionszámot (pontosabban a szállítmányszámot az SWP-től), és átvételre regisztrálja a sofőrt, vagyis kijelöli számára a szükséges időrést. Vagyis az időben érkező sofőrnek most már nem kell sorban állnia, a törvényes ideje és a kirakodó dokkja neki van kiosztva. Ez többek között lehetővé tette számunkra a teherautók optimális elosztását az egész területen, és a kirakodóhelyek hatékonyabb kihasználását. És mivel előre elkészítjük a menetrendet arról, hogy ki hova és mikor érkezik, tudjuk, hány emberre van szükség és hova. Vagyis ez összefügg a raktári alkalmazottak munkarendjével is.
- Ennek a varázslatnak köszönhetően a rakodóknak már nincs szükségük további útválasztásra, csak megvárják, amíg az autók kirakják őket. Valójában az eszközük - a terminál - megmondja nekik, hogy mit és mikor kell tenniük. Absztrakciós szinten olyan, mint a betöltő API, de egy ember-számítógép interakciós modellben. Az a pillanat, amikor az első raklapot letapogatják a teherautóról, a szállítási metaadatok is rögzítik.
- A kirakodás továbbra is kézzel történik, de a rakodó minden raklapon vonalkód-leolvasót futtat, és megerősíti, hogy a címkeadatok rendben vannak. A rendszer gondoskodik arról, hogy az általunk elvárt megfelelő raklap legyen. A kirakodás végére a rendszer pontosan megszámolja az összes rakományt. Ebben a szakaszban a hibákat még kijavítják: ha a szállítótartályon nyilvánvaló sérülések vannak, akkor elég ezt a kirakodás során egyszerűen megjegyezni, vagy egyáltalán nem fogadják el ezt a terméket, ha az teljesen használhatatlan.
- Korábban a raklapokat a kirakodási területen számolták, miután az összeset kipakolták a teherautóból. Most a fizikai kirakodás folyamata egy újraszámítás. A hibát azonnal visszaküldjük, ha az nyilvánvaló. Ha nem nyilvánvaló és később derül ki, akkor a raktárban egy speciális pufferben felhalmozzuk. Sokkal gyorsabb, ha a raklapot tovább dobja a folyamatba, összegyűjt belőlük egy tucatnyit, és lehetőséget ad a beszállítónak, hogy egy külön látogatás alkalmával mindent egyszerre vegyen át. Egyes hibák átkerülnek az újrahasznosítási zónába (ez gyakran vonatkozik a külföldi beszállítókra, akik könnyebben kapnak fényképeket és küldenek új terméket, mint a határon túlra visszafogadni).
- A kirakodás végén a dokumentumokat aláírják, a sofőr pedig elmegy, hogy intézze a dolgát.
A régi eljárás során a raklapokat gyakran speciális pufferzónába helyezték át, ahol már dolgoztak velük: megszámolták, házasságot jegyeztek stb. Erre azért volt szükség, hogy felszabadítsák a dokkolót a következő autó számára. Most minden folyamat úgy van beállítva, hogy erre a pufferzónára egyszerűen nincs szükség. Léteznek szelektív visszaszámlálás (egy példa erre a „Traffic Light” projektben megvalósított, raktári keresztdokkoláshoz szükséges csomagon belüli szelektív újraszámlálás), de az áruk nagy részét a beérkezés után azonnal feldolgozzák, és a dokkból származik. hogy a raktárban az optimális helyre utazzanak, vagy azonnal egy másik dokkba rakodásra, ha már megérkezett a raktárból történő kiszállításhoz szükséges szállítás. Tudom, hogy ez egy kicsit hétköznapinak hangzik számodra, de öt évvel ezelőtt egy hatalmas raktárban az, hogy egy szállítmányt közvetlenül a végpontokhoz, például egy másik teherautó rakodóállomásához tudtunk feldolgozni, úgy tűnt, mintha valami űrprogramból származna.
Mi történik a termék mellett?
Ezután, ha ez nem keresztdokkolás (és az áruk még nem kerültek a pufferbe a kiszállítás előtt vagy közvetlenül a dokkolóba), akkor raktárra kell helyezni tárolás céljából.
Meg kell határozni, hogy ez a termék hová kerüljön, melyik tároló cellába. A régi folyamatban vizuálisan meg kellett határozni, hogy melyik zónában tároljuk az ilyen típusú árukat, majd ott ki kell választani egy helyet, és elvinni, elhelyezni, felírni, hogy mit teszünk. Most minden termékhez a topológiának megfelelő elhelyezési útvonalakat állítottunk fel. Tudjuk, hogy melyik termék melyik zónába és melyik cellába kerüljön, tudjuk, hogy a közelben hány további cellát kell elfoglalni, ha túlméretezett. Egy személy megközelíti a raklapot, és SSCC-vel beszkenneli a TSD segítségével. A szkenner ezt mutatja: „Vigye az A101-0001-002 címre.” Aztán odaviszi, és megjegyzi, hogy mit rakott oda, és ott helyben megböki a szkennert a kóddal. A rendszer ellenőrzi, hogy minden rendben van-e, és megjegyzi. Nem kell semmit írni.
Ezzel befejeződik a termékkel való munka első része. Ezután az üzlet készen áll arra, hogy átvegye a raktárból. És ebből adódik a következő folyamat, amelyről a beszerzési osztály kollégái jobban fognak mesélni.
Tehát a rendszerben a készlet a megrendelés elfogadásának pillanatában frissül. A cella készlete pedig abban a pillanatban van, amikor a raklapot belehelyezik. Vagyis mindig tudjuk, hogy összesen hány áru van a raktárban, és az egyes termékek pontosan hol találhatók.
Sok áramlás közvetlenül a csomópontokba (regionális átrakodó raktárakba) érkezik, mivel minden régióban sok helyi beszállítónk van. Kényelmesebb ugyanazokat a Voronyezsből származó klímaberendezéseket nem a szövetségi raktárba telepíteni, hanem közvetlenül a helyi csomópontokra, ha ez gyorsabb.
A fordított hulladékáramlás is kismértékben optimalizált: ha az árut keresztben dokkolik, a szállító átveheti egy moszkvai raktárból. Ha a hiba a szállítócsomag felbontása után derült ki (és kívülről nem volt egyértelmű, vagyis nem a szállítómunkások hibája volt), akkor minden üzletben van visszaküldési zóna. A hiba elküldhető egy szövetségi raktárba, vagy közvetlenül az üzletből adható át a szállítónak. A második gyakrabban fordul elő.
Egy másik folyamat, amely most optimalizálásra szorul, az eladatlan szezonális áruk feldolgozása. Az a helyzet, hogy két fontos évszakunk van: az újév és a kertészkedés. Vagyis januárban az eladatlan műfákat és füzéreket kapjuk az elosztóközpontban, télre pedig fűnyírókat és egyéb szezonális árukat, amelyeket meg kell őrizni, ha még egy évet túlélnek. Elméletileg a szezon végén teljesen el kell adnunk, vagy másnak kell adnunk, nem pedig visszarángatni a raktárba – ez az a rész, ahol még nem értünk rá.
Öt év alatt négyszeresére csökkentettük az áruátvétel (a gép kirakodásának) idejét és számos egyéb folyamatot felgyorsítottunk, ami összességében valamivel több mint felére javította a keresztdokkolási forgalmat. Feladatunk az optimalizálás annak érdekében, hogy csökkentsük a készletet, és ne „befagyjunk” a pénz a raktárban. És lehetővé tették, hogy az üzletek időben megkapják a szükséges árukat.
A raktári folyamatok esetében a nagy fejlesztések a korábban papír automatizálása, a folyamat szükségtelen lépéseinek megszüntetése a berendezéseken és a megfelelően konfigurált folyamatokon keresztül, valamint a vállalat összes informatikai rendszerének egyetlen egésszé történő összekapcsolása volt, így az ERP-től érkező megrendelés ( pl. a boltból hiányzik valami a bal oldali harmadik polcról) végül konkrét műveletekké alakult a raktári rendszerben, szállítás megrendelése stb. Az optimalizálás most inkább azokról a folyamatokról szól, amelyekhez még nem jutottunk el, illetve az előrejelzés matematikájáról. Vagyis a gyors megvalósítás korszaka lejárt, a munka 30%-át elvégeztük, ami az eredmény 60%-át adta, majd fokozatosan le kell fedni a többit. Vagy költözz más területekre, ha ott többet lehet tenni.
Nos, ha mentett fákkal számolunk, akkor a beszállítók EDI-portálokra való átállása is sokat adott. Most szinte minden beszállító nem hívja és nem kommunikál a menedzserrel, hanem személyes fiókjában nézi meg a megrendeléseket, erősíti meg és szállítja ki az árut. Lehetőség szerint elutasítjuk a papírt, 2014 óta a beszállítók 98%-a használ már elektronikus dokumentumkezelést. Ez összesen 3 fát ment meg egy év alatt, csak azért, mert nem kell kinyomtatni az összes szükséges papírt. De ez nem veszi figyelembe a processzorok hőjét, de nem veszi figyelembe az olyan emberek megtakarított munkaidejét, mint ugyanazok a menedzserek a telefonban.
Öt év alatt négyszer annyi üzletünk, háromszor annyi különböző bizonylatunk volt, és ha nincs EDI, háromszor annyi könyvelőnk lett volna.
Nem állunk meg itt, és továbbra is új üzeneteket kapcsolunk az EDI-hez, új beszállítókat az elektronikus dokumentumkezeléshez.
Tavaly megnyitottuk Európa legnagyobb, 140 ezer négyzetméteres elosztó központját. m - és nekilátott a gépesítésnek. Erről egy másik cikkben fogok beszélni.
Forrás: will.com