Ячейка пикинга на первом этаже стеллажа
Вы берёте один из смесителей для кухни у нас в магазине и уносите его под мышкой к кассе. На кассе вам делают документ о продаже, и в этот момент уменьшается количество этого товара на остатках в системах и на сайте.
Ночью каждый магазин считает прогноз по заказам на следующий период. Точнее, каждую неделю просчитывается прогноз на один год вперёд, а из него каждую ночь рассчитываются заказы для управляющего магазина. Скрипт видит, что кто-то купил смеситель, и если продажи пойдут такими темпами (тут целый блок сложной модели, что считать «такими темпами» и на каком периоде), то смесители закончатся через семь дней. Это значит, что нужно сформировать следующий заказ, чтобы их привезли.
Большая часть товаров едет в магазины либо по потоку кросс-докинга (склад перебрасывает паллеты, не открывая и не сохраняя их у себя на стоке), либо напрямую от местных поставщиков. Частично мы эти процессы уже разбирали в прошлом посте. Рассмотрим сложный случай, когда магазину смесители нужны из паллеты, которая лежит на складе в Москве.
Сложность в том, что паллета — это довольно много смесителей. А в магазин нужно привезти 50 штук, скажем. Не везти же её целиком? И вот появляется процесс пикинга, когда паллета снимается с ячейки, кладётся вниз, а потом из неё достаётся вложенная тара. Это может быть транспортный короб, иннер и штука. Штуками распределительный центр почти никогда не оперирует, за исключением редкого и дорогого оборудования. Для единиц нужны фулфилмент-центры, но это уже немного другая часть логистики, и в этом посте про них не будет.
В конечном итоге, когда магазину нужен товар, потребность считается в системе прогнозирования GOLD GWR, а в ERP (Oracle RMS) появляется итоговый документ с тем, сколько чего нужно привезти и куда. Он попадает в систему управления складом (WMS) в виде задания «Отгрузить туда-то» и в систему управления транспортом (TMS) в виде директивы «Забрать это на складе таком-то и отвезти в магазин такой-то». Дальше задача TMS — обеспечить транспорт (для этого отправляется заявка логистам), а задача WMS — обеспечить начало загрузки в момент открытия дока под приехавший грузовик.
Товар может быть отгружен целой паллетой или вложенной единицей хранения. Самое удобное для склада — конечно, грузить целую. Потому что, когда нужна вложенная единица хранения (короб), это требует времени и ручных операций. То есть стоит каких-то денег и снижает оборачиваемость товара (не даёт использовать склад под что-то другое).
Склад уместно сравнить с базой данных. Она должна как можно быстрее давать ответ приложениям, которые её дергают. Часть её in-memory — это процессы кросс-докинга, которые вообще не требуют «записи» в сток. Ещё часть — кеш: это специальные буферы, где товар может немного полежать перед следующей операцией. И ещё часть — хранилище, сток, где товар лежит для дальнейшей обработки.
Задача склада всегда — уменьшить сток и увеличить его оборачиваемость (т. е. уменьшать срок его хранения). Чем меньше товара лежит без дела, тем выгоднее для компании. Но при этом, когда нужный товар кто-то запросил, а склад его дать не может, — это тоже провал. Между двумя этими крайностями и работает вся математика.
Так что с моим смесителем?
Идеальный процесс с точки зрения оптимизации стока — использовать склад только как роутер. Идеальный процесс с точки зрения доступности — сохранить весь товар в мире на складе и выдавать по мере надобности.
В конечном итоге компромисс для смесителей выглядит так: выделяется математический оптимум того, как их везти. Иногда бывает выгодно вообще не закупать конкретно эту модель (потому что есть прямой аналог), иногда действительно выгодно закупить и привезти целую паллету и медленно её распродавать со склада магазина. Но чаще всего бывает выгодно везти транспортный короб. Если в коробе 52 единицы, а система магазина подсчитала, что нужно 50, то решение очевидно: будет заказано чуть больше — 52. А вот если магазину нужно три единицы, а короб — 100 единиц, то уже встаёт вопрос о целесообразности минимума.
Мы не используем алгоритм минимакс для магазинов, но сейчас его разрабатываем и будем применять в основном для малых форматов, т. к. он хорошо подходит, когда нет или мало места на складе магазина и нужно пополнять сразу полку. Для малого формата будет: максимум — вместимость полки, минимум — количество «триггер» для заказа, если сток опускается на меньшее или равное значение — мы делаем заказ до максимума полки.
Формирование потребности у нас работает по принципу покрытия заказа и каждый заказ покрывает товарным запасом до даты доставки следующего заказа.
Например, делаем заказ сегодня, 01.01.2021 года, и у нас на остатке 18 штук. Дата доставки такого заказа будет 07.01.2021 (поставщик возит за одну неделю). Дата следующего заказа — 14.01.2021, доставки — 21.01.2021.
Представим, что мы продаём по две штуки в день всегда.
Значит, мы должны заказом 01.01.2021 покрыть запасом аж до 21.01.2021, иначе нам нечего будет продавать.
Поэтому до 21.01.2021 нам потребуется 21 * 2 = 42 штуки.
18 штук у нас на остатках есть, поэтому заказываем 24 штуки 01.01.2021.
Конечно же, в каждом заказе есть ещё и доля страхового запаса.
Дальше данные заказа вписываются в тарность. То есть если нужно 45, 48 или 49 штук — заказывается минимальный короб в 50. Если нужно 55 штук — нужно заказать два короба или оптимизировать модель. Как видите, чем меньше квантование (чем чаще поставки и чем больше управляемых единиц вложенности в таре), тем точнее оптимизация. Поэтому поставки в магазины делаются как можно чаще, и поэтому появляются подкороба в коробах.
Как короб попадает в грузовик?
Итак, из магазина задание поступает в ERP, а оттуда — на склад. Склад должен обеспечить упакованный товар в доке, когда туда подъедет машина, заказанная TMS-системой, и заберёт его в магазин.
На складе все заказы кластеризуются, чтобы затем оптимизировать маршруты заданий каждому отдельному грузчику. Для каждого погрузчика считается маршрут, где он быстрее всего заберёт весь нужный товар и не будет мешать другим. Функция — общее счастье, то есть снижение общего времени выполнения всех операций в целом.
Дальше люди получают конкретные координаты целей (паллет в ячейках) и действия с ними в виде алгоритма. И выполняют их. Разбивается это на шаги в духе: «Езжай в ячейку такую-то, возьми паллету». Человек едет, сканирует там её штрихкод, система проверяет, что всё правильно, и даёт следующее действие: «Вези туда-то». И так — всё время. Мы управляем мобильными терминалами, а грузчики их слушаются. Так мы имеем своего рода API к людям на складе. Следующий шаг, конечно, — убрать людей, но про это в другой раз.
Когда нужно разобрать паллету, происходит отдельный процесс пикинга. Мы берём её с ячейки хранения вверху и спускаем в нижнюю ячейку. Оттуда берём два короба смесителей, из другой — три короба другого товара (пускай будут гвозди, они интересны тем, что упакованы на развес) и так далее. Всё это с терминалами сканируется и проверяется на каждом шаге. В итоге всё равно получается одна паллета для дока, только уже с разными коробами.
Когда она готова, на неё печатается отдельная этикетка на терминале, и она теперь учитывается в системе как отдельное место. Можно класть в буфер отгрузки или прямо на док.
Ячейки пикинга — это буфер, поэтому после выемки товара из паллеты пикинга часто надо поднимать исходную паллету обратно вверх. Потому что внизу ячейка нужна будет для чего-то другого.
Тот, кто кладёт паллету сверху вниз, и тот, кто берёт из ячейки пикинга короба, — это два разных человека. Пикинер только набирает товар, а другой человек на погрузчике только жонглирует паллетами.
Откуда взялся грузовик?
Из инструмента TMS, который пару раз в день консолидирует все потребности всех магазинов и нарезает потребности в грузовиках. Там считается не только заказ на каждый узел графа, но и оптимальный маршрут по графу разного транспорта. Магазин размещает заказы один раз в неделю, планирование транспорта начинается за два дня до поставки. За два дня уже понятно, какой конкретно транспорт подойдёт к доку, что и в каком порядке в него класть и как он поедет. Эта автоматизация касается всего: когда этот грузовик только приедет на склад, система по номеру скажет, к каким воротам ему ехать и когда, то есть мы управляем ещё оптимизацией движения транспорта у доков.
Мы учитываем при этом не только фактическое наличие товара на складе, но и тот товар, который на него только едет, — это тоже важная часть оптимизации.
Как принимается решение, что товар нужно пополнить на такое-то количество?
Сначала мы смотрим, будет ли ещё закупаться этот товар. Для каждого магазина есть матрицы того, что в нём продаётся, а что — нет. Это региональные особенности из-за местных поставщиков, регионального спроса (очень дорогая профессиональная техника для ремонта чаще всего нужна только в Москве), культурных особенностей (в Казахстане — огромная зона ковров для декора) и так далее.
Товар может перестать закупаться в магазин из-за окончания сезона: мало кому нужны газонокосилки зимой и ёлочные игрушки летом.
Если товар будет закупаться — считаем, сколько его нужно на следующий период. Это довольно интересная модель, которая учитывает историю продаж товара (это главный весовой коэффициент) и учитывает профиль сезонности семейства, в которое входит этот товар. Когда по товару есть большая история продаж в этом и других магазинах, модель строится гладко и попасть можно с точностью до штуки.
Когда товар новый, истории нет. Её нужно либо откуда-то взять, либо управлять товаром вручную. В случае когда это прямой аналог чего-то известного, можно просто указать ему товар-пару в карточке. Были перчатки рабочие одного производителя, пришли другого (или просто артикул либо модель поменялись) — указываем пару прошлую, и модель опирается на историю другого товара. Через шесть недель (это магическая константа) товар автоматически отвязывается и у него начинает считаться только собственная история.
Когда товар совсем новый и вообще неясно, что с ним делать, привозится какое-то количество в магазины по ручному прогнозу. Дальше набирается история. У коллег из моды про это есть огромная математика, а у нас нет: мы всё же — про ремонт, и у нас мода только-только начала появляться в области дизайна кухонных линеек и вообще декора. В остальном спрос плавный почти на все группы товаров. Сезонные изменения учитываются довольно легко: для нового товара — по группе, для старых — по их большой истории.
Поскольку мы пока умеем правильно считать далеко не всё и система может ошибаться, итоговый документ отправляется на утверждение администратору магазина (или человеку, который отвечает за поставки товара). Точнее, обычно это делают менеджеры отделов (в магазине 15 отделов: инструменты, скобянка, сантехника и т. п.). Им выводятся все позиции без исключения, которые могут быть поставлены в рамках отдела, и их количество. То есть если в заказе 0, то там есть позиция и стоит ноль.
Мы сейчас уже тестируем автозаказ для некоторых поставщиков. Т. к. есть случаи, когда система предлагает к заказу количество, а менеджеры магазинов подтверждают параметры без изменений и продолжительное время, то пользователю незачем обрабатывать такие заказы в ERP и мы автоматически отправляем их поставщикам. Но есть группа координаторов, которые поддерживают магазины и отслеживают корректность таких заказов.
По согласованию можно убрать товар (если заканчивается сезон Нового года, то не нужно дозаказывать ещё 100 искусственных ёлок) или добавить тот, который до этого не продавался. Это требует участия ещё человека из офиса.
В 99,9 % случаев всё решается на месте в магазине, и администраторы только увеличивают количество того товара, который, по их мнению, продаётся больше и быстрее, чем система может предсказать. Всё же 50–60 тысяч SKU очень сложно обрабатывать только вручную. В итоге они вносят минимальные изменения, которые помогают увеличению продаж, чувствуют контроль, но не вносят человеческие ошибки. Всё делается децентрализованно, то есть каждый магазин управляет своим заказом сам за исключением редких случаев.
Есть товары, управляемые вручную. Например, нестандартные душевые кабины. Есть товары на полуавтоматическом пополнении: система по таким товарам считает предложение к заказу и количественно отображает, сколько заказать. Менеджеры магазина видят прогнозы продаж, историю продаж и при необходимости корректируют количество. Мы занимаемся уменьшением количества корректировок к предложенному заказу, чтобы пользователи делали меньше ручных операций и система формировала «идеальные» предложения к заказу.
Мы хорошо понимаем сезонные коэффициенты, когда один и тот же товар продаётся весь год с разной скоростью. Но при этом товары, которые часть сезона продаются много, а часть — нет, обрабатываем пока не очень точно. Модель заточена под плавные сдвиги, а не резкие колебания.
Для расчёта заказа система учитывает среднюю задержку поставщика. Если мы видим, что поставщик регулярно опаздывает на пять дней, то помимо штрафов, GOLD учтёт это в формировании заказа и закажет больше страхового запаса, чтобы учесть возможные опоздания. Дополнительно мы надстроили анализ ежедневных остатков: если товар отсутствовал на полке большое количество дней в неделе и если эти дни имели значительную вероятность продаж, то система видит это и понимает, что такую неделю для учёта истории продаж нужно исключить, а не понижать прогноз.
Откуда склад знает, сколько товара взять и откуда? Теперь вы знаете, как магазин определяет свои потребности. Вы знаете, как это консолидируется и отправляется на склад, а склад должен достать транспорт и отгрузить всё это. Но есть ещё слой: складу нужно всё это обработать.
Прогноз продаж по каждому магазину и прогноз логистики с учётом маршрутов и использования разных видов транспорта (рефрижераторов, бортов, боковых и так далее) даёт понимание, сколько товара потребуется и где. И к каким датам его нужно достать.
Дальше — ещё слой оптимизации: где его выгоднее достать к этому времени? Какой партией? Некоторые поставщики ставят минимальный объём отгрузки (килограмм гвоздей заказать не выйдет), некоторые дают объёмные скидки, ретробонусы и прочие спецусловия. Надо считать, как везти товар и откуда. Эту тему мы только начали прорабатывать, пока она в довольно простом виде. Думаю, через год будет что рассказать.
Иногда товар выгоднее складировать большой партией, чем покупать несколько маленьких, иногда выгоднее разбивать поставку на десять локальных партий у разных поставщиков. И так далее.
Надо знать процент брака, чтобы не было такого, что товар приехал, а продать его не получается. Склад за счёт больших чисел сглаживает все эти колебания.
Если не прогнозировать всё точно, то уменьшается маржинальность категории товара (накапливается ненужный сток). Чем больше ассортимент — тем больше вещей надо отслеживать. Когда речь идёт про десятки тысяч позиций на рынке, где есть глобальные изменения (а они есть), то без хорошей автоматизации просто не обойтись.
