Тэрмінал збору дадзеных Zebra WT-40 са сканарам-кольцам. Патрэбен для таго, каб была магчымасць хутка сканаваць тавар, пры гэтым укладваць фізічна кораба на палету (вольныя рукі).
На працягу некалькіх гадоў мы вельмі хутка адчынялі крамы і раслі. Скончылася гэта тым, што зараз нашы склады прымаюць і адпраўляюць каля 20 тысяч палет у дзень. Натуральна, сёння ў нас ужо больш складоў: два вялікія ў Маскве — 100 і 140 тысяч квадратных метраў, але ёсць і невялікія ў іншых гарадах.
Кожная зэканомленая секунда ў працэсах прыёмкі, зборкі ці адпраўкі тавара ў такіх маштабах - гэта магчымасць зберагчы час на аперацыі. А яшчэ гэта вялізная эканомія.
Менавіта таму два галоўных множніка эфектыўнасці – гэта прадуманы алгарытм дзеянняў (працэс) і настроеныя ІТ-сістэмы. Пажадана «як гадзіннік», але «якія працуюць крыху менш, чым ідэальна» таксама цалкам падыдзе. Усё ж мы ў рэальным свеце.
Гісторыя пачалася шэсць гадоў таму, калі мы прыгледзеліся да таго, як менавіта пастаўшчыкі разгружаюць фуры ў нас на складзе. Гэта было настолькі нелагічна, але звыкла, што супрацоўнікі нават не заўважалі неаптымальнай працэсу. Больш таго, у той момант у нас не было прамысловай сістэмы кіравання складам, і ў асноўным лагістычныя аперацыі мы давяралі 3PL-аператарам, якія выкарыстоўвалі свой софт і досвед у пабудове працэсаў.
Прыёмка тавару
Як мы ўжо казалі, наша кампанія на той момант (як, у прынцыпе, і цяпер) імкнулася адкрыць шмат крам, таму прыйшлося аптымізаваць складскія працэсы для павелічэння прапускной здольнасці (больш тавараў за меншую колькасць часу). Гэта няпростая задача, і вырашыць яе, проста павялічыўшы персанал, было нельга хаця б таму, што ўсе гэтыя людзі будуць адзін аднаму замінаць. Такім чынам, мы пачалі думаць аб укараненні інфармацыйнай сістэмы WMS (warehouse management system). Як і належыць, мы пачалі з апісання мэтавых складскіх працэсаў і ўжо ў самым пачатку выявілі неаранае поле для паляпшэнняў падчас прыёмкі тавара. Трэба было адпрацаваць працэсы на адным са складоў, каб потым накаціць іх на астатнія.
Прыёмка - гэта адна з першых вялікіх аперацый на складзе. Яна бывае некалькіх тыпаў: калі мы проста пералічваем колькасць грузавых месцаў і калі нам неабходна, апроч гэтага, палічыць, колькі і якіх артыкулаў ляжыць на кожнай палет. Большая частка тавараў у нас праходзіць па плыні крос-докінг. Гэта калі тавары прыязджаюць на склад ад пастаўшчыка, а склад выступае ў ролі роўтара і імкнецца тут жа пераадправіць іх на канчатковага атрымальніка (крама). Ёсць і іншыя струмені, напрыклад, калі склад выступае ў ролі кэша ці ў ролі назапашвальніка (трэба пакласці пастаўку ў сцёк, падзяліць на часткі і паступова вывозіць у крамы). Напэўна, пра працу са сцёкам лепш раскажуць мае калегі, якія займаюцца матэматычнымі мадэлямі аптымізацыі рэшткаў. Але тут сюрпрыз! Праблемы сталі ўзнікаць чыста на ручных аперацыях.
Працэс выглядаў так: грузавік прыязджаў, кіроўца мяняўся дакументамі з адміністратарам склада, адміністратар разумеў, што там прыехала і куды яго адправіць, потым накіроўваў грузчыка забіраць тавар. Усё гэта займала каля трох гадзін (вядома, шмат у чым час прыёмкі залежыць ад таго, які лагістычны струмень мы прымаем: дзесьці неабходна рабіць унутрытарны пералік, а дзесьці - не). Большую колькасць людзей на адзін грузавік накіраваць нельга: будуць адзін аднаму перашкаджаць.
Якія былі страты? Іх было мора. Па-першае, работнікі склада атрымлівалі папяровыя дакументы. Яны арыентаваліся і прымалі рашэньні, што рабіць з пастаўкай, па іх. Па-другое, яны лічылі палеты ўручную і ў гэтых жа таварных накладных адзначалі колькасць. Затым запоўненыя бланкі прыёмкі ставіліся да кампутара, дзе дадзеныя забіваліся ў XLS-файл. Дадзеныя з гэтага файла затым імпартаваліся ў ERP, і толькі тады наша ІТ-ядро па факце бачыла тавар. Мы мелі вельмі мала метададзеных аб замове накшталт часу прыбыцця транспарта, альбо гэтыя дадзеныя былі недакладнымі.
Першае, што мы зрабілі, - гэта пачалі аўтаматызаваць самі склады так, каб у іх з'явілася падтрымка працэсаў (спатрэбілася паставіць кучу софту, жалеза накшталт мабільных сканараў штрыхкодаў, разгарнуць інфраструктуру для ўсяго гэтага). Затым звязалі гэтыя сістэмы з ERP праз шыну. У канчатковым выніку інфармацыя аб наяўнасці тавару абнаўляецца ў сістэме, калі грузчык праводзіць сканарам штрыхкода па палеце на які прыехаў грузавіку.
Стала так:
- Пастаўшчык сам запаўняе дадзеныя аб тым, што адпраўляе да нас і калі. Для гэтага ёсць звязак з SWP і EDI-парталаў. Гэта значыць крама публікуе замову, а пастаўшчыкі бяруцца выканаць заяўку і паставіць тавар у патрэбнай колькасці. Яны ж пры адпраўцы тавару паказваюць склад палет у фуры і ўсю неабходную інфармацыю лагістычнага характару.
- Калі машына з'ехала ад пастаўшчыка да нас, мы ўжо ведаем, які тавар да нас ідзе; больш за тое, з пастаўшчыкамі наладжаны электронны дакументазварот, таму мы ведаем, што УПД ужо падпісаны. Рыхтуецца схема аптымальнага перасоўвання гэтага тавара: калі гэта крос-докінг, то мы ўжо замовілі транспарт са склада, разлічваючы на тавар, а таксама для ўсіх лагістычных плыняў мы ўжо вызначылі, якая колькасць складскіх рэсурсаў нам спатрэбіцца для апрацоўкі паставак. У дэталях для крос-докінгу папярэдні план па транспарце са склада робіцца на больш раннім этапе, калі пастаўшчык толькі зарэзерваваў слот на пастаўку ў сістэме кіравання складскімі варотамі (YMS – yard management system), якая інтэграваная з парталам пастаўшчыка. Інфармацыя прыходзіць у YMS адразу.
- YMS атрымлівае нумар грузавіка (калі быць дакладней, то нумар адгрузкі з SWP) і запісвае кіроўцу на прыёмку, гэта значыць адводзіць яму неабходны слот часу. Гэта значыць зараз кіроўцу, які прыехаў своечасова, не трэба чакаць жывой чаргі, а пад яго адведзены яго законны час і док разгрузкі. Гэта дазволіла нам, акрамя ўсяго іншага, аптымальна размяркоўваць грузавікі па тэрыторыі і больш эфектыўна выкарыстоўваць разгрузачныя слоты. А яшчэ, паколькі мы загадзя складаем графік, хто, куды і калі прыедзе, то ведаем, колькі людзей і дзе патрэбна. То бок, гэта яшчэ звязана з працоўнымі графікамі супрацоўнікаў склада.
- У выніку гэтай магіі грузчыкі ўжо не маюць патрэбы ў дадатковай маршрутызацыі, а толькі чакаюць машыны для іх разгрузкі. Фактычна іх інструмент - тэрмінал - кажа ім, што рабіць і калі. На ўзроўні абстракцыі гэта як API грузчыка, але ў human-computer interaction-мадэлі. Момант сканавання першай палеты з грузавіка - гэта яшчэ запіс метададзеных па пастаўцы.
- Разгрузка пакуль робіцца ўсё гэтак жа рукамі, але па кожнай палеце грузчык праводзіць сканарам штрыхкодаў і пацвярджае, што дадзеныя этыкеткі ў парадку. Сістэма кантралюе, каб гэта была правільная паллета, якую мы чакаем. Да канца разгрузкі ў сістэме будзе дакладны пералік усіх грузавых месцаў. На гэтай стадыі яшчэ адсяецца шлюб: калі ёсць відавочныя пашкоджанні транспартнай тары, то дастаткова проста адзначыць гэта ў працэсе разгрузкі або зусім не прыняць гэты тавар, калі ён зусім непрыдатны.
- Раней палеты пералічваліся ў зоне разгрузкі пасля таго, як усе будуць выгружаны з машыны. Цяпер ужо працэс фізічнай выгрузкі з'яўляецца пералікам. Шлюб мы вяртаем адразу ж, калі ён відавочны. Калі ён невідавочны і выяўляецца потым, то мы назапашваем яго ў спецыяльны буфер на складзе. Значна хутчэй пракінуць палету далей у працэс, сабраць з дзясятак такіх і даць магчымасць пастаўшчыку забраць усё адразу за адзін асобны прыезд. Некаторыя віды шлюбу пераводзяцца ў зону ўтылізацыі (гэта часта тычыцца замежных пастаўшчыкоў, якім прасцей атрымаць фатаграфіі і даслаць новы тавар, чым прымаць яго назад праз мяжу).
- У канцы разгрузкі падпісваюцца дакументы, і кіроўца з'яжджае далей па сваіх справах.
У старым працэсе палеты перамяшчаліся часцяком у адмысловую буферную зону, дзе ўжо з імі працавалі: лічылі, рэгістравалі шлюб і гэтак далей. Трэба было гэта для таго, каб вызваліць док для наступнай машыны. Цяпер усе працэсы настроены так, што гэтая буферная зона проста не патрэбна. Ёсць выбарачныя пералікі (адзін з прыкладаў - працэс выбарачнага ўнутрытарнага пераліку для крос-докінгу на складзе, рэалізаваны ў праекце «Святлафор»), але большая частка тавару апрацоўваецца адразу па факце прыёмкі і менавіта з дока едзе на аптымальнае месца на складзе ці адразу ў іншы док для пагрузкі, калі транспарт на адгрузку са склада ўжо прыбыў. Ведаю, для вас гэта гучыць крыху звычайна, але пяць гадоў таму на велізарным складзе магчымасць апрацаваць пастаўку адразу на канчатковыя кропкі накшталт дока пагрузкі для іншага грузавіка - гэта нам здавалася чымсьці накшталт касмічнай праграмы.
Што далей адбываецца з таварам?
Далей, калі гэта не крос-докінг (і тавар ужо не з'ехаў у буфер перад адпраўкай ці проста ў док), тое яго трэба пакласці ў сцёк на захоўванне.
Трэба вызначыць, куды гэты тавар пойдзе, у якое вочка захоўвання. У старым працэсе трэба было глядзельна вызначыць, у якой зоне мы захоўваем тавары дадзенага тыпу, і потым абраць тамака месца і адвезці, пакласці, запісаць, што паклалі. Цяпер у нас настроены маршруты размяшчэння па кожным тавары па тапалогіі. Мы ведаем, які тавар у якую зону і ў якое вочка павінен патрапіць, ведаем, колькі вочак заняць дадаткова побач, калі гэта негабарыт. Чалавек падыходзіць да палет і скануе яе SSCC з дапамогай ТСД. Сканар паказвае: "Везі ў А101-0001-002". Далей ён вязе туды і адзначае, што паклаў, тыкаючы сканарам у код на месцы. Сістэма правярае, што ўсё правільна, і зазначае. Нічога пісаць не трэба.
На гэтым першая частка працы з таварам заканчваецца. Далей магазін гатовы забіраць яго са склада. І гэта спараджае наступны працэс, пра які лепш раскажуць калегі з аддзела забеспячэння.
Такім чынам, у сістэме сцёк абнаўляецца ў момант прыёмкі замовы. А запас ячэйкі - у момант пастаноўкі палеты ў яе. Гэта значыць, мы заўсёды ведаем, колькі тавару ёсць на складзе разам і дзе які ляжыць канкрэтна.
Вельмі шмат патокаў працуе напрамую ў хабы (рэгіянальныя перавалачныя склады), таму што ў нас шмат мясцовых пастаўшчыкоў у кожным рэгіёне. Тыя ж кандыцыянеры з Варонежа зручней ставіць не на федэральны склад, а адразу ў хабы на месцах, калі гэта хутчэй.
Зваротныя патокі шлюбу таксама крыху аптымізаваныя: калі тавар на крос-докінгу, то пастаўшчык можа забраць яго са склада ў Маскве. Калі шлюб выявіўся ўжо пасля адкрыцця транспартнага пакавання (і звонку гэта было незразумела, гэта значыць ён з'явіўся не па віне транспартнікаў), гэта значыць зоны звароту ў кожнай краме. Шлюб можна закінуць на федэральны склад, а можна аддаваць пастаўшчыку прама з крамы. Другое здараецца часцей.
Яшчэ адзін працэс, які зараз мае патрэбу ў аптымізацыі, - гэта апрацоўка непрададзеных сезонных тавараў. Справа ў тым, што ў нас ёсць два важныя сезоны: Новы год і час саду-агарода. Гэта значыць, у студзені мы атрымліваем на РЦ нерэалізаваныя штучныя ёлкі і гірлянды, а да зімы - газонакасілкі і іншыя сезонныя тавары, якія трэба захаваць, калі яны вытрымаюць яшчэ год. Па ідэі, трэба распрадаваць іх цалкам у канцы сезону або аддаваць камусьці яшчэ, а не цягнуць назад на склад - вось гэта тая частка, куды ў нас яшчэ не дайшлі рукі.
За пяць гадоў мы скарацілі час прыёмкі тавару (разгрузку машыны) у чатыры разы і паскорылі шэраг іншых працэсаў, што ў агульнай складанасці палепшыла абарачальнасць крос-докінгу крыху больш, чым удвая. Наша задача - аптымізацыя, каб знізіць запас і не «замарожваць» грошы на складзе. І далі магчымасць магазінам атрымліваць патрэбны тавар крыху больш своечасова.
Па складскіх працэсах вялікія паляпшэнні складаліся ў тым, каб аўтаматызаваць тое, што раней было паперай, пазбавіцца ад лішніх этапаў у працэсе за кошт абсталявання і правільна настроеных працэсаў і злучыць усе ІТ-сістэмы кампаніі ў адзінае цэлае, каб замова з ERP (напрыклад, у краме чагосьці бракуе на трэцяй паліцы злева) у канчатковым выніку ператвараўся ў пэўныя дзеянні ў сістэме складскога захоўвання, замовы транспарта і гэтак далей. Цяпер аптымізацыя больш датычыцца тых працэсаў, да якіх мы яшчэ не дабіраліся, і матэматыкі прагназавання. Гэта значыць эпоха бурнага ўкаранення скончылася, мы зрабілі тыя 30% працы, якія далечы 60% выніку, і далей трэба паступова пакрываць усё астатняе. Або рухацца на іншыя ўчасткі, калі тамака можна зрабіць больш.
Ну і калі лічыць у выратаваных дрэвах, то пераход пастаўшчыкоў на EDI-парталы таксама шмат даў. Цяпер практычна ўсе пастаўшчыкі не тэлефануюць і не маюць зносіны з мэнэджэрам, а самі ў асабістым кабінеце глядзяць замовы, пацвярджаюць іх і вязуць тавар. Па магчымасці адмаўляемся ад паперы, з 2014 года ўжо 98% пастаўшчыкоў - на электронным дакументазвароце. У агульнай складанасці гэта захаваныя 3 дрэў за год толькі на адмове ад раздрукоўкі ўсіх патрэбных папер. Але гэта без уліку цяпла ад працэсараў, але і без уліку зэканомленага працоўнага часу людзей накшталт тых жа мэнэджэраў на тэлефоне.
За пяць гадоў у нас стала ў чатыры разы больш крам, у тры разы больш розных дакументаў, і, калі б не было EDI, у нас было б у тры разы больш бухгалтараў.
Мы не спыняемся на дасягнутым і працягваем падлучаць да EDI новыя паведамленні, новых пастаўшчыкоў да электроннага дакументазвароту.
У мінулым годзе мы адкрылі найбуйнейшы размеркавальны цэнтр у Еўропе – 140 тыс. кв. м - і ўзяліся за яго механізаванне. Пра гэта я раскажу ў іншым артыкуле.
Крыніца: habr.com