- PVSM.RU - https://www.pvsm.ru -
Терминал сбора данных Zebra WT-40 со сканером-кольцом. Нужен для того, чтобы была возможность быстро сканировать товар, при этом укладывать физически короба на паллету (свободные руки).
На протяжении нескольких лет мы очень быстро открывали магазины и росли. Закончилось это тем, что сейчас наши склады принимают и отправляют порядка 20 тысяч паллет в день. Естественно, сегодня у нас уже больше складов: два больших в Москве — 100 и 140 тысяч квадратных метров, но есть и небольшие в других городах.
Каждая сэкономленная секунда в процессах приёмки, сборки или отправки товара в таких масштабах — это возможность сберечь время на операции. А ещё это огромная экономия.
Именно поэтому два главных множителя эффективности — это продуманный алгоритм действий (процесс) и настроенные ИТ-системы. Желательно «как часы», но «работающие чуть менее, чем идеально» тоже вполне подойдёт. Всё же мы в реальном мире.
История началась шесть лет назад, когда мы присмотрелись к тому, как именно поставщики разгружают фуры у нас на складе. Это было настолько нелогично, но привычно, что сотрудники даже не замечали неоптимальности процесса. Более того, в тот момент у нас не было промышленной системы управления складом, и в основном логистические операции мы доверяли 3PL-операторам, которые использовали свой софт и опыт в построении процессов.
Как мы уже говорили, наша компания на тот момент (как, в принципе, и сейчас) стремилась открыть много магазинов, поэтому пришлось оптимизировать складские процессы для увеличения пропускной способности (больше товаров за меньшее количество времени). Это непростая задача, и решить её, просто увеличив персонал, было нельзя хотя бы потому, что все эти люди будут друг другу мешать. Таким образом, мы начали думать о внедрении информационной системы WMS (warehouse management system). Как и полагается, мы начали с описания целевых складских процессов и уже в самом начале обнаружили непаханое поле для улучшений в процессе приёмки товара. Нужно было отработать процессы на одном из складов, чтобы потом накатить их на остальные.
Приёмка — это одна из первых больших операций на складе. Она бывает нескольких типов: когда мы просто пересчитываем количество грузовых мест и когда нам необходимо, помимо этого, посчитать, сколько и каких артикулов лежит на каждой паллете. Большая часть товаров у нас проходит по потоку кросс-докинг. Это когда товары приезжают на склад от поставщика, а склад выступает в роли роутера и старается тут же переотправить их на конечного получателя (магазин). Есть и другие потоки, например, когда склад выступает в роли кэша или в роли накопителя (нужно положить поставку в сток, разделить на части и постепенно вывозить в магазины). Наверное, про работу со стоком лучше расскажут мои коллеги, которые занимаются математическими моделями оптимизации остатков. Но тут сюрприз! Проблемы стали возникать чисто на ручных операциях.
Процесс выглядел так: грузовик приезжал, водитель менялся документами с администратором склада, администратор понимал, что там приехало и куда его отправить, потом направлял грузчика забирать товар. Всё это занимало около трёх часов (конечно, во многом время приёмки зависит от того, какой логистический поток мы принимаем: где-то необходимо делать внутритарный пересчёт, а где-то — нет). Большее количество людей на один грузовик направить нельзя: будут друг другу мешать.
Какие были потери? Их было море. Во-первых, работники склада получали бумажные документы. Они ориентировались и принимали решения, что делать с поставкой, по ним. Во-вторых, они считали паллеты вручную и в этих же товарных накладных отмечали количество. Потом заполненные бланки приёмки относились к компьютеру, где данные забивались в XLS-файл. Данные из этого файла затем импортировались в ERP, и только тогда наше ИТ-ядро по факту видело товар. Мы имели очень мало метаданных о заказе вроде времени прибытия транспорта, либо эти данные были неточными.
Первое, что мы сделали, — это начали автоматизировать сами склады так, чтобы у них появилась поддержка процессов (понадобилось поставить кучу софта, железа наподобие мобильных сканеров штрихкодов, развернуть инфраструктуру для всего этого). Потом связали эти системы с ERP через шину. В конечном итоге информация о наличии товара обновляется в системе, когда грузчик проводит сканером штрихкода по паллете на приехавшем грузовике.
Стало так:
В старом процессе паллеты перемещались зачастую в специальную буферную зону, где уже с ними работали: считали, регистрировали брак и так далее. Нужно было это для того, чтобы освободить док для следующей машины. Сейчас все процессы настроены так, что эта буферная зона просто не нужна. Есть выборочные пересчёты (один из примеров — процесс выборочного внутритарного пересчёта для кросс-докинга на складе, реализованный в проекте «Светофор»), но большая часть товара обрабатывается сразу по факту приёмки и именно из дока едет на оптимальное место на складе или сразу в другой док для погрузки, если транспорт на отгрузку со склада уже прибыл. Знаю, для вас это звучит немного обыденно, но пять лет назад на огромном складе возможность обработать поставку сразу на конечные точки вроде дока погрузки для другого грузовика — это нам казалось чем-то вроде космической программы.
Дальше, если это не кросс-докинг (и товар уже не уехал в буфер перед отправкой или прямо в док), то его нужно положить в сток на хранение.
Нужно определить, куда этот товар пойдёт, в какую ячейку хранения. В старом процессе нужно было зрительно определить, в какой зоне мы храним товары данного типа, и потом выбрать там место и отвезти, положить, записать, что положили. Сейчас у нас настроены маршруты размещения по каждому товару по топологии. Мы знаем, какой товар в какую зону и в какую ячейку должен попасть, знаем, сколько ячеек занять дополнительно рядом, если это негабарит. Человек подходит к паллете и сканирует её SSCC с помощью ТСД. Сканер показывает: «Вези в А101-0001-002». Дальше он везёт туда и отмечает, что положил, тыкая сканером в код на месте. Система проверяет, что всё правильно, и отмечает. Ничего писать не нужно.
На этом первая часть работы с товаром заканчивается. Дальше магазин готов забирать его со склада. И это порождает следующий процесс, про который лучше расскажут коллеги из отдела снабжения.
Итак, в системе сток обновляется в момент приёмки заказа. А запас ячейки — в момент постановки паллеты в неё. То есть мы всегда знаем, сколько товара есть на складе итого и где какой лежит конкретно.
Очень много потоков работает напрямую в хабы (региональные перевалочные склады), потому что у нас много местных поставщиков в каждом регионе. Те же кондиционеры из Воронежа удобнее ставить не на федеральный склад, а сразу в хабы на местах, если это быстрее.
Обратные потоки брака тоже слегка оптимизированы: если товар на кросс-докинге, то поставщик может забрать его со склада в Москве. Если брак вскрылся уже после открытия транспортной упаковки (и снаружи это было непонятно, то есть он появился не по вине транспортников), то есть зоны возврата в каждом магазине. Брак можно забросить на федеральный склад, а можно отдавать поставщику прямо из магазина. Второе случается чаще.
Ещё один процесс, который сейчас нуждается в оптимизации, — это обработка непроданных сезонных товаров. Дело в том, что у нас есть два важных сезона: Новый год и время сада-огорода. То есть в январе мы получаем на РЦ нереализованные искусственные ёлки и гирлянды, а к зиме — газонокосилки и другие сезонные товары, которые нужно сохранить, если они выдержат ещё год. По идее, нужно распродавать их полностью в конце сезона либо отдавать кому-то ещё, а не тащить обратно на склад — вот это та часть, куда у нас ещё не дошли руки.
За пять лет мы сократили время приёмки товара (разгрузку машины) в четыре раза и ускорили ряд других процессов, что в общей сложности улучшило оборачиваемость кросс-докинга чуть больше, чем вдвое. Наша задача — оптимизация, чтобы снизить запас и не «замораживать» деньги на складе. И дали возможность магазинам получать нужный товар чуть более вовремя.
По складским процессам большие улучшения заключались в том, чтобы автоматизировать то, что раньше было бумагой, избавиться от лишних этапов в процессе за счёт оборудования и правильно настроенных процессов и соединить все ИТ-системы компании в единое целое, чтобы заказ из ERP (например, в магазине чего-то не хватает на третьей полке слева) в конечном итоге превращался в конкретные действия в системе складского хранения, заказа транспорта и так далее. Сейчас оптимизация больше касается тех процессов, до которых мы ещё не добирались, и математики прогнозирования. То есть эпоха бурного внедрения закончилась, мы сделали те 30 % работы, которые дали 60 % результата, и дальше надо постепенно покрывать всё остальное. Либо двигаться на другие участки, если там можно сделать больше.
Ну и если считать в спасённых деревьях, то переход поставщиков на EDI-порталы тоже очень много дал. Сейчас практически все поставщики не звонят и не общаются с менеджером, а сами в личном кабинете смотрят заказы, подтверждают их и везут товар. По возможности отказываемся от бумаги, с 2014 года уже 98 % поставщиков — на электронном документообороте. В общей сложности это сохранённые 3 000 деревьев за год только на отказе от распечатки всех нужных бумаг. Но это без учёта тепла от процессоров, но и без учёта сэкономленного рабочего времени людей вроде тех же менеджеров на телефоне.
За пять лет у нас стало в четыре раза больше магазинов, в три раза больше различных документов, и, если бы не было EDI, у нас было бы в три раза больше бухгалтеров.
Мы не останавливаемся на достигнутом и продолжаем подключать к EDI новые сообщения, новых поставщиков к электронному документообороту.
В прошлом году мы открыли крупнейший распределительный центр в Европе — 140 тыс. кв. м — и взялись за его механизацию. Об этом я расскажу в другой статье.
Автор: MikhailGariyants
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/razrabotka/354991
Ссылки в тексте:
[1] Источник: https://habr.com/ru/post/510828/?utm_source=habrahabr&utm_medium=rss&utm_campaign=510828
Нажмите здесь для печати.