Как попадает товар в магазины «Леруа Мерлен» с точки зрения математики заказа

    image
    Ячейка пикинга на первом этаже стеллажа

    Вы берёте один из смесителей для кухни у нас в магазине и уносите его под мышкой к кассе. На кассе вам делают документ о продаже, и в этот момент уменьшается количество этого товара на остатках в системах и на сайте.

    Ночью каждый магазин считает прогноз по заказам на следующий период. Точнее, каждую неделю просчитывается прогноз на один год вперёд, а из него каждую ночь рассчитываются заказы для управляющего магазина. Скрипт видит, что кто-то купил смеситель, и если продажи пойдут такими темпами (тут целый блок сложной модели, что считать «такими темпами» и на каком периоде), то смесители закончатся через семь дней. Это значит, что нужно сформировать следующий заказ, чтобы их привезли.

    Большая часть товаров едет в магазины либо по потоку кросс-докинга (склад перебрасывает паллеты, не открывая и не сохраняя их у себя на стоке), либо напрямую от местных поставщиков. Частично мы эти процессы уже разбирали в прошлом посте. Рассмотрим сложный случай, когда магазину смесители нужны из паллеты, которая лежит на складе в Москве.

    Сложность в том, что паллета — это довольно много смесителей. А в магазин нужно привезти 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 штук — нужно заказать два короба или оптимизировать модель. Как видите, чем меньше квантование (чем чаще поставки и чем больше управляемых единиц вложенности в таре), тем точнее оптимизация. Поэтому поставки в магазины делаются как можно чаще, и поэтому появляются подкороба в коробах.

    image

    Как короб попадает в грузовик?


    Итак, из магазина задание поступает в ERP, а оттуда — на склад. Склад должен обеспечить упакованный товар в доке, когда туда подъедет машина, заказанная TMS-системой, и заберёт его в магазин.

    На складе все заказы кластеризуются, чтобы затем оптимизировать маршруты заданий каждому отдельному грузчику. Для каждого погрузчика считается маршрут, где он быстрее всего заберёт весь нужный товар и не будет мешать другим. Функция — общее счастье, то есть снижение общего времени выполнения всех операций в целом.

    Дальше люди получают конкретные координаты целей (паллет в ячейках) и действия с ними в виде алгоритма. И выполняют их. Разбивается это на шаги в духе: «Езжай в ячейку такую-то, возьми паллету». Человек едет, сканирует там её штрихкод, система проверяет, что всё правильно, и даёт следующее действие: «Вези туда-то». И так — всё время. Мы управляем мобильными терминалами, а грузчики их слушаются. Так мы имеем своего рода API к людям на складе. Следующий шаг, конечно, — убрать людей, но про это в другой раз.

    Когда нужно разобрать паллету, происходит отдельный процесс пикинга. Мы берём её с ячейки хранения вверху и спускаем в нижнюю ячейку. Оттуда берём два короба смесителей, из другой — три короба другого товара (пускай будут гвозди, они интересны тем, что упакованы на развес) и так далее. Всё это с терминалами сканируется и проверяется на каждом шаге. В итоге всё равно получается одна паллета для дока, только уже с разными коробами.

    Когда она готова, на неё печатается отдельная этикетка на терминале, и она теперь учитывается в системе как отдельное место. Можно класть в буфер отгрузки или прямо на док.

    Ячейки пикинга — это буфер, поэтому после выемки товара из паллеты пикинга часто надо поднимать исходную паллету обратно вверх. Потому что внизу ячейка нужна будет для чего-то другого.

    Тот, кто кладёт паллету сверху вниз, и тот, кто берёт из ячейки пикинга короба, — это два разных человека. Пикинер только набирает товар, а другой человек на погрузчике только жонглирует паллетами.

    image

    Откуда взялся грузовик?


    Из инструмента TMS, который пару раз в день консолидирует все потребности всех магазинов и нарезает потребности в грузовиках. Там считается не только заказ на каждый узел графа, но и оптимальный маршрут по графу разного транспорта. Магазин размещает заказы один раз в неделю, планирование транспорта начинается за два дня до поставки. За два дня уже понятно, какой конкретно транспорт подойдёт к доку, что и в каком порядке в него класть и как он поедет. Эта автоматизация касается всего: когда этот грузовик только приедет на склад, система по номеру скажет, к каким воротам ему ехать и когда, то есть мы управляем ещё оптимизацией движения транспорта у доков.

    image

    Мы учитываем при этом не только фактическое наличие товара на складе, но и тот товар, который на него только едет, — это тоже важная часть оптимизации.

    Как принимается решение, что товар нужно пополнить на такое-то количество?


    Сначала мы смотрим, будет ли ещё закупаться этот товар. Для каждого магазина есть матрицы того, что в нём продаётся, а что — нет. Это региональные особенности из-за местных поставщиков, регионального спроса (очень дорогая профессиональная техника для ремонта чаще всего нужна только в Москве), культурных особенностей (в Казахстане — огромная зона ковров для декора) и так далее.

    Товар может перестать закупаться в магазин из-за окончания сезона: мало кому нужны газонокосилки зимой и ёлочные игрушки летом.

    Если товар будет закупаться — считаем, сколько его нужно на следующий период. Это довольно интересная модель, которая учитывает историю продаж товара (это главный весовой коэффициент) и учитывает профиль сезонности семейства, в которое входит этот товар. Когда по товару есть большая история продаж в этом и других магазинах, модель строится гладко и попасть можно с точностью до штуки.

    Когда товар новый, истории нет. Её нужно либо откуда-то взять, либо управлять товаром вручную. В случае когда это прямой аналог чего-то известного, можно просто указать ему товар-пару в карточке. Были перчатки рабочие одного производителя, пришли другого (или просто артикул либо модель поменялись) — указываем пару прошлую, и модель опирается на историю другого товара. Через шесть недель (это магическая константа) товар автоматически отвязывается и у него начинает считаться только собственная история.

    Когда товар совсем новый и вообще неясно, что с ним делать, привозится какое-то количество в магазины по ручному прогнозу. Дальше набирается история. У коллег из моды про это есть огромная математика, а у нас нет: мы всё же — про ремонт, и у нас мода только-только начала появляться в области дизайна кухонных линеек и вообще декора. В остальном спрос плавный почти на все группы товаров. Сезонные изменения учитываются довольно легко: для нового товара — по группе, для старых — по их большой истории.

    Поскольку мы пока умеем правильно считать далеко не всё и система может ошибаться, итоговый документ отправляется на утверждение администратору магазина (или человеку, который отвечает за поставки товара). Точнее, обычно это делают менеджеры отделов (в магазине 15 отделов: инструменты, скобянка, сантехника и т. п.). Им выводятся все позиции без исключения, которые могут быть поставлены в рамках отдела, и их количество. То есть если в заказе 0, то там есть позиция и стоит ноль.

    Мы сейчас уже тестируем автозаказ для некоторых поставщиков. Т. к. есть случаи, когда система предлагает к заказу количество, а менеджеры магазинов подтверждают параметры без изменений и продолжительное время, то пользователю незачем обрабатывать такие заказы в ERP и мы автоматически отправляем их поставщикам. Но есть группа координаторов, которые поддерживают магазины и отслеживают корректность таких заказов.

    По согласованию можно убрать товар (если заканчивается сезон Нового года, то не нужно дозаказывать ещё 100 искусственных ёлок) или добавить тот, который до этого не продавался. Это требует участия ещё человека из офиса.

    В 99,9 % случаев всё решается на месте в магазине, и администраторы только увеличивают количество того товара, который, по их мнению, продаётся больше и быстрее, чем система может предсказать. Всё же 50–60 тысяч SKU очень сложно обрабатывать только вручную. В итоге они вносят минимальные изменения, которые помогают увеличению продаж, чувствуют контроль, но не вносят человеческие ошибки. Всё делается децентрализованно, то есть каждый магазин управляет своим заказом сам за исключением редких случаев.

    Есть товары, управляемые вручную. Например, нестандартные душевые кабины. Есть товары на полуавтоматическом пополнении: система по таким товарам считает предложение к заказу и количественно отображает, сколько заказать. Менеджеры магазина видят прогнозы продаж, историю продаж и при необходимости корректируют количество. Мы занимаемся уменьшением количества корректировок к предложенному заказу, чтобы пользователи делали меньше ручных операций и система формировала «идеальные» предложения к заказу.

    Мы хорошо понимаем сезонные коэффициенты, когда один и тот же товар продаётся весь год с разной скоростью. Но при этом товары, которые часть сезона продаются много, а часть — нет, обрабатываем пока не очень точно. Модель заточена под плавные сдвиги, а не резкие колебания.

    Для расчёта заказа система учитывает среднюю задержку поставщика. Если мы видим, что поставщик регулярно опаздывает на пять дней, то помимо штрафов, GOLD учтёт это в формировании заказа и закажет больше страхового запаса, чтобы учесть возможные опоздания. Дополнительно мы надстроили анализ ежедневных остатков: если товар отсутствовал на полке большое количество дней в неделе и если эти дни имели значительную вероятность продаж, то система видит это и понимает, что такую неделю для учёта истории продаж нужно исключить, а не понижать прогноз.

    Откуда склад знает, сколько товара взять и откуда? Теперь вы знаете, как магазин определяет свои потребности. Вы знаете, как это консолидируется и отправляется на склад, а склад должен достать транспорт и отгрузить всё это. Но есть ещё слой: складу нужно всё это обработать.

    Прогноз продаж по каждому магазину и прогноз логистики с учётом маршрутов и использования разных видов транспорта (рефрижераторов, бортов, боковых и так далее) даёт понимание, сколько товара потребуется и где. И к каким датам его нужно достать.

    Дальше — ещё слой оптимизации: где его выгоднее достать к этому времени? Какой партией? Некоторые поставщики ставят минимальный объём отгрузки (килограмм гвоздей заказать не выйдет), некоторые дают объёмные скидки, ретробонусы и прочие спецусловия. Надо считать, как везти товар и откуда. Эту тему мы только начали прорабатывать, пока она в довольно простом виде. Думаю, через год будет что рассказать.

    Иногда товар выгоднее складировать большой партией, чем покупать несколько маленьких, иногда выгоднее разбивать поставку на десять локальных партий у разных поставщиков. И так далее.

    Надо знать процент брака, чтобы не было такого, что товар приехал, а продать его не получается. Склад за счёт больших чисел сглаживает все эти колебания.

    Если не прогнозировать всё точно, то уменьшается маржинальность категории товара (накапливается ненужный сток). Чем больше ассортимент — тем больше вещей надо отслеживать. Когда речь идёт про десятки тысяч позиций на рынке, где есть глобальные изменения (а они есть), то без хорошей автоматизации просто не обойтись.
    Леруа Мерлен
    Ритейлер — технологическая компания платформа.

    Комментарии 36

      0
      Узнал новое русское слово — пикинг. Именно русское, потому что по-английски это
      pickup.
        +6

        Пикинг, это когда штрих-коды сканируют. Стоит тётя, и приборчиком "пик", "пик", пиик". Вот и называется "пикинг".

          0
          У нас (оптовые поставки продуктов, год 2007 примерно) это называлось «чирикать».
          «Чирикнутые коды» :)
          0
          Есть английское order picking, которое про «the process of taking goods that have been ordered from the place where they are stored and sending them to customers»
            +2
            Если не придираться к транслитерации и заимствованию, то речь ведь о «pallet picking»? в чём тут проблема?
              0
              проблема наверное как раз в транслитерации и заимствовании к месту и не к месту.
              пикинг (и еще круче — пикинер), иннер, фулфилмент, кросс-докинг, сток — вся статья набита диковатым рунглишем.
            +1
            А WMS и TMS у вас от каких вендоров, если не секрет?
            +6

            Это все, конечно, хорошо и здорово, прям отлично.
            Но скажите, как тогда получается, что на странице товара на сайте "наличие в магазине Леруа Мерлен *** — много" а на полках в этом же магазине — 0? В тот же самый момент времени.

              0
              Это «Товар Шредингера».
                0
                мне на месте объясняли, что это «потому что воруют»
                  0

                  Ещё у меня был случай с грунтовкой: «потому что срок годности кончился».

                  0

                  Мб товар "ходит" по магазину?

                    0

                    Один раз в такое совпадение поверить можно, но регулярно — навряд.

                    0
                    скорей всего товар лежит на складе в магазине, но просто не выложен на полки
                      0

                      Насколько я понимаю во-первых явно выраженного большого склада в магазинах типа Леруа-Мерлен нет.
                      Во-вторых консультанты были бы в курсе (не исключаю, что некоторые из их — ленивые сволочи, но все же по моим наблюдениям большинство весьма отзывчивые)
                      Ну и в третьих — зачем для товара, который на складе недоступен к покупке писать наличие в интернетиках

                      0
                      Да, это боль. Мы изо всех сил стараемся сократить количество факторов, вызывающих подобную трудность. К сожалению, такое всё ещё случается из-за нескольких причин: например, товар может лежать на внутреннем складе магазина, либо могла произойти пересортица с другим очень похожим товаром и стоки (количество товара в запасе) не успели скорректировать. В любом случае, консультанты в магазине или колл-центре будут рады вам помочь найти товар или предложить достойную альтернативу.
                        0

                        Ага, особенно если альтернатива раза в 2-3 дороже. Может в этом и кроется истинный смысл таких несоответствий?
                        P.S. Притом, как мне объясняли на информационной стойке, внутренний склад магазина даже не находится в самом магазине, а где-то у черта на рогах.

                      +1

                      Скажите, а почему некоторые позиции — в одном магазине полно (десятки, судя по сайту), а в другом никогда не бывает?

                        0
                        Это последствия неправильного составления товарной матрицы для конкретного магазина. Если в матрице товар не указан, то он никогда не появится в конкретном магазине.
                        0
                        Скрипт видит, что кто-то купил смеситель, и если продажи пойдут такими темпами, то смесители закончатся через семь дней. Это значит, что нужно сформировать следующий заказ, чтобы их привезли.

                        Делал так в 1996 году для розничной продуктовой сети. Правда через РРЦ (розничный распред центр). Рабочий вариант.
                          +2

                          image

                          +2

                          Вот кто эти люди по другую сторону парсинга. :))


                          Пару лет парсила сайты Леруа по всем магазинам. Отслеживала продажи, спрос, цены на товары, выручку… Плохо, что в разных городах разный шаблон сайта. Всего их три разновидности. Прошу поправить, а то очень не удобно, приходится сначала детектить, какой шаблон используется, а потом уже парсить. :)) Или лучше скажите, как подключиться к API.


                          И вообще с Леруа в этом смысле гораздо больше возни, чем с Петровичем, ОБИ и Касторамой. Моё сердце принадлежит ОБИ. А вот наиболее прикольно с Максидомом. Он не показывает количество товара в наличие. Поэтому приходится "пытаться положить" в корзину какое-то количество товара, и смотреть хватит его или нет. Вот так и выцарапываю данные о количестве у них.

                            0
                            не три, а четыре. А если быть вообще честным, то пять) Но, как говорится, «должен остаться только один»
                              0

                              Вообще у меня нет объяснений, почему у Леруа разный шаблон сайта у разных городов. По "ту" сторону у них Битрикс.


                              С Леруа ещё проблемка была в том, что открываются новые магазины. Сначала каждый месяц "прокликивала" сайт по всем городам, сравнивая магазины с имеющими. Но потом задолбалась и дописала обнаружитель новых магазинов, который автоматом включал их в мою базу, и тоже начинал в них парсить наличие товара по артикулам.

                                0
                                исторически так сложилось, при попытке смены стека примерно 3 года назад. в меньшей степени битрикс, я бы сказал, что он доживает свое.
                            0
                            А если товар купят и вернут через неделю?
                              0
                              Если товар купят и вернут через неделю, то наша система увидит увеличенный доступный сток в магазине и сделает следующий заказ поставщику с меньшим количеством, т.к. товар уже есть в магазине.
                              0

                              Кстати, давно мучал вопрос, а тут как раз статья от самих Леруа, и началась со смесителя… Не смог удержаться не задать. Как получается, что фото товара абсолютно не соответствует товару? Покупал я раковину и сайт предложил мне смеситель с переливом, с пробкой — вот это вот всё. Причем на фото выглядит прилично, пробка-решетка металлическая, сливная часть тоже металл. Ну я и заказал. А по факту мне пришел полностью пластиковый смеситель, с пластиковой пробкой-решеткой, с пластиковой сливной частью, и даже формы деталей абсолютно не те, что были на фото… До сих пор обида на ваш магазин, но как так получается, мне все равно интересно. Это ошибочка вышла или маркетинговые штучки?

                                +2
                                Это ошибочка вышла или маркетинговые штучки?
                                Вы реально сейчас ожидаете ответа типа «да, мы это сделали чтобы специально вас обмануть, ха-ха-ха»)
                                  +1
                                  Вы действительно уверены, что данный вопрос уместен в рамках текущего топика, а не должен быть адресован службе поддержки ЛМ?
                                  А вообще, от ошибки человека не застрахована ни одна система. Тут явно она.
                                    0
                                    А поддержка ЛМ в случае с тайной продажей страховки недвижимости при покупке кухни отравляет в банк или страховую, все взятки — гладки.
                                      +1
                                      я не знаю, так это или нет. Возможно следует обратиться в компетентные органы. Но на мой взгляд, хабр — это тех ресурс, а статья имеет определенную тематическую направленность. Для того, чтобы пожаловаться, что вас каким-либо образом обманули, есть другие ресурсы и каналы.
                                      Смысл сюда с этим идти, если проблема, с которой вы столкнулись, не может быть решена автором поста?
                                    +1
                                    Как получается, что фото товара абсолютно не соответствует товару?

                                    Адекватные фото товаров — больное место любого товарного сервиса, т.к. фото товара, особенно качественные, крайне трудозатратная процедура, отчего ей все пренебрегают.
                                    Начиная с производителя — только самые крутые делают нормальный "product information pack" для реселлеров\конечных покупателей; и то он не всегда доходит до покупателя — полностью или частично. Если же производитель фото не прислал, повезёт, если на месте его кто-то сделает, и при размещении ничего не перепутает. Часто для нескольких похожих товаров используется дженериковое фото одного из них. В общем, бардак, решается лишь тоталитаризмом.


                                    Примерно то же с описаниями товаров. Может показаться странным, но нормальные описание товара, особенно с подробными ТТХ, крайне сложно администрировать.

                                    0
                                    Если интересно разобраться с предсказанием спроса, то копайте в сторону доверительных интервалов. Я был немало удивлен, когда понял, что даже для единичного товара можно построить вполне приемлемые оценки спроса на него.
                                      0
                                      А учитывается ли такое, что товар в рамках оного артикула может быть разным? Простейший пример — плитка, у которой есть тон и калибр, и клиент (как правило) хочет получить одинаковую плитку?
                                      Пример жизненный — я как-то заказывал плитку, три разных артикула, и когда она приехала — в каждом артикуле было минимум два разных тона. Естественно, от заказа я отказался и попросил нормальную, одинаковую. И выяснилось, что одной из позиций одинаковой ни в одном магазине города нет — пришлось выбирать другую плитку.

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                      Самое читаемое