В «Леруа Мерлен» запустили сервис «Светофор 3.0», использующий возможности машинного обучения для поиска ошибок и для экономии ресурсов при приемке товаров. Это самообучающаяся на исторических данных модель, которая помогает сотруднику приемки магазина сократить время на пересчет товаров от прямых поставщиков путем определения поставок, в которых, вероятнее всего, есть ошибки. В результате удалось вдвое сократить время на пересчет товаров при приемке в магазинах сети, при этом затраты на приемку снижены на 12%.
Проект реализован командой «Прозрачность операций», которая занимается в «Леруа Мерлен» ad-hoc-аналитикой, анализом данных, продуктами data science и совершенствованием процессов в целом. Об истории проекта рассказали руководители продуктов, номинанты на премию Data Award.
– Какая задача решалась в ходе создания продукта «Светофор»?
Михаил Гариянц: Требовалось сократить трудозатраты при приемке товаров. Нужно было уменьшить число заказов от прямых поставщиков: в этих заказах проводится внутритарный пересчет. Доля поставщиков, которые напрямую доставляют товары в магазины, составляет около 37% от всех поставок. Мы хотели сократить внутритарный пересчет и перераспределить освободившиеся ресурсы на другие зоны в магазине. При этом качество принимаемых товаров не должно было ухудшиться, а магазины не должны были столкнуться с проблемами в процессе реализации таких товаров.
– Почему это важно для компании? Как раньше были выстроены процессы приемки?
М.Г.: Еще несколько лет назад у нас появилась важная цель — минимизировать логистические операции в зоне приемки в магазинах и направить максимум усилий сотрудников на работу с клиентами. Идея заключалась в том, что магазины должны принимать все поставки без внутритарного пересчета, ограничиваясь лишь пересчетом грузовых мест. Таким образом, пропускная способность приемки товаров должна была кратно повыситься, а зона приемки — высвободиться за счет последующего размещения товаров либо в других зонах склада, либо в торговом зале. Да и сам процесс приемки должен был упроститься. Конечно же, это позволит снизить затраты нашей компании, потому что внутритарный пересчет — это самая длительная операция на приемке. Однако, чтобы реализовать такую концепцию и избавить магазин от пересчета входящих поставок, нужно выполнить два условия. Во-первых, обеспечить качество, чтобы магазины не принимали на баланс излишки и не сталкивались с недостачами. Во-вторых, убедить сотрудников приемки в том, что такие товары можно не проверять.
Это совсем не простая задача. В распределительных центрах (РЦ) нам пришлось организовать разные процессы для разных логистических потоков, что привело к необходимости вводить дополнительные процессы контроля качества товаров после сборки или в процессе приемки, чего раньше не требовалось. Это привело к дополнительным затратам для РЦ и в то же время стало большим шагом к завоеванию доверия и обеспечению качества. Мы даже теперь ставим печать «Проверено на складе».
В случае же прямых поставок нет возможности что-то проверить в РЦ. Первой инстанцией контроля товаров здесь являются магазины, поэтому вопрос нужно было решать иным способом.
– Что не устраивало?
М.Г.: Конечно, магазины и раньше пытались не пересчитывать абсолютно все товары. По результатам инвентаризации каждая торговая точка самостоятельно решала, продукцию каких поставщиков нужно пересчитывать, а каких — нет, используя собственную логику. У нас более 100 магазинов, и везде с этой проблемой справлялись самостоятельно. Одному и тому же поставщику в одном магазине доверяли, а в другом — нет. И такая ситуация могла сохраняться достаточно длительное время. Естественно, очень многое зависело от опыта сотрудников, непосредственно работающих в магазине. И требовалось максимально точно определить, нужно пересчитывать конкретную поставку или нет.
– Как подошли к решению задачи?
М.Г.: Мы, как продуктовая команда, занимающаяся управлением данными в составе домена логистики, изучали «боли» наших внутренних клиентов. Ситуацию с приемкой товара мы тоже анализировали и по результатам интервью сформулировали задачу: помочь магазинам выявлять больше расхождений, но при этом просчитывать меньше заказов. Понимая, что эту задачу можно решить через алгоритмы машинного обучения, мы исследовали реальные процессы в магазинах, изучили используемые там данные, оценили готовность команд к реализации проекта. Создав локальную модель, успешно проверили гипотезу и защитили кейс, и после этого началась полноценная реализация проекта.
– В чем заключалась сложность реализации задачи? В чем ее нетривиальность?
М.Г.: Продукт, который мы создавали, имеет огромное количество потребителей, и в связи с этим требовалось полностью синхронизировать команды, которые участвовали в проекте. Они хорошо знают бизнес-процессы и понимают, какие методы коммуникации лучше использовать, для того чтобы магазины приняли изменения максимально лояльно. Вообще, процесс развертывания любых решений с таким охватом весьма сложен.
Кроме того, сам проект по сути уникален. У нас не было возможности провести референс-визит, посоветоваться с другими компаниями. Однако нам помогло то, что у нас был реализован похожий проект на складах и какие-то базовые технические нюансы мы могли переиспользовать.
– Какие данные использовались?
Михаил Измайлов: Если говорить о начальном исследовании и первичном анализе, то мы использовали историю приемки заказов со всевозможными деталями, накопленную в корпоративном озере данных. Смотрели на то, как магазины принимают заказы, какие из них принимаются доверительно, какие — недоверительно, пытались найти в этом определенную логику. Оценивали, как влияют на решение о доверительной или недоверительной приемке тот или иной ассортимент и артикулы, история самого поставщика, количество товаров в заказе. Уже на стадии анализа мы создали тестовую модель, чтобы понять, «выстрелит» ли продукт.
Если говорить о «боевой» модели, то для ее обучения мы берем скользящие 140 дней истории приемки заказов всей сети. Сейчас у нас основными факторами, влияющими на скоринг, являются поставщик, количество товаров в заказе, ассортимент заказа, его стоимость и заявленное количество палет. При этом мы переобучаем модель один раз в день, подпитывая ее новыми историческими данными. У нас очень большая сеть, и если в какой-то магазин пришла проблемная поставка, мы можем это обнаружить и с большей вероятностью рекомендовать ее для пересчета в других магазинах. То есть если у поставщика была какая-то бракованная партия, мы можем превентивно это отследить на основе данных первой приемки и дальше снизить такой риск для остальных магазинов сети.
– Как долго шел проект, кто в нем участвовал?
М.Г.: Проект был реализован за 7 месяцев, и еще полтора месяца потребовалось на масштабирование на все магазины сети. Таким образом, мы уложились в достаточно короткие сроки, причем масштабирование за полтора месяца — действительно отличный результат. В нашу проектную команду входили дата-сайентист, дата-инженер и дата-аналитик. Со стороны WMS-системы также задействовались аналитик и разработчик, чтобы немножко адаптировать ее под процесс приемки. И конечно же, принимали участие люди из бизнеса: лидер процесса приемки по всем магазинам и сами специалисты приемки в пилотном магазине.
– С какими проблемами столкнулись при разработке решения?
М.И.: Наверное, ключевыми стали проблемы, связанные с верификацией данных и их качеством. Видя какие-то неадекватные результаты, мы начинали разбираться и понимали, что проблема в данных, с которыми мы работаем: в дата-сетах дублируются строки, в каких-то местах обнаруживаются нули, которых не должно быть, и т. п. На проверку данных и обеспечение их качества пришлось потратить достаточно много времени. В принципе, мы подозревали, что такое может быть: на текущий момент у нас каждый из 115 магазинов имеет свой отдельный сервер, на котором работает WMS. Требовалась очень аккуратная работа, чтобы точно понимать, что обучение проводится на ровных данных и с ними все хорошо.
– Как теперь выглядит процесс приемки?
М.Г.: Изменения в работе сотрудников должны были быть минимальными, поскольку наши действия затрагивали достаточно большое количество людей. В целом добавился один системный шаг. Сразу после получения информации об отгрузке складская система передает данные в модель машинного обучения, которая выполняет скоринг. Таким образом, еще до прибытия товара WMS-система «знает», надо ли пересчитывать этот заказ. Сотрудники сканируют штрихкод палеты, и, если она не подлежит пересчету, выводится соответствующее сообщение.
– Каких результатов удалось достичь? Как они соотносятся с ожиданиями?
М.И.: У нас были три ключевые метрики. Первая из них — это доля доверительных приемок. До начала проекта она составляла 49% — то есть практически половину заказов магазин принимал доверительно. Мы поставили цель за несколько месяцев дойти до показателя 85%, и на текущий момент имеем цифру 86%. Данную метрику нам удалось «пробить», на это ушло около трех месяцев.
Вторая метрика — это стоимость поиска одного рубля расхождений. Чтобы продукт обеспечивал финансовый эффект, на поиск одного рубля расхождения нужно тратить менее рубля, что логично. Нам удалось сократить этот показатель практически в 2,5 раза, но пока он еще немножко больше рубля. Задача решена не полностью, но здесь мы тоже прогрессируем.
И последняя метрика — это отношение числа найденных расхождений к общей сумме проверенных заказов. Она говорит о том, насколько хорошо мы в принципе находим расхождения в тех заказах, что проверяем. До старта проекта этот показатель был 0,46%, а зафиксированный результат сейчас — 0,55%. То есть нам действительно удалось сделать процесс несколько эффективнее.
Если отвлечься от метрик, то важно отметить, что наша цель — высвободить персонал и перераспределить его на выполнение более полезных операций. На текущий момент эффект от запуска продукта — возможность перераспределить порядка 115 FTE (эквивалентов полной занятости сотрудника) по сети, то есть убрать их с приемки и направить на другие активности.
Наконец, нельзя не сказать о том, что использование машинного алгоритма при принятии решения о проверке более эффективно, нежели работа на основе интуиции сотрудников. Разумеется, магазин может принять самостоятельное решение о той или иной форме приемки. Мы разделили полученные оценки в соответствии с тем, кто принимал решение — магазин или алгоритм. В итоге у нас получилось, что доля проверенных заказов по результатам рекомендаций алгоритма — всего 2%, а остальные 13% магазин проверял по своей инициативе. Среди нашей меньшей части проверок доля найденных расхождений в рублях составила 1,38%, а у магазина при гораздо большем объеме проверок — всего 0,11%. Получается, что алгоритм позволяет пересчитывать намного меньше поставок и находить гораздо больше расхождений.
В принципе, расхождений выявляется не очень много. Отчасти поэтому и появилась идея использовать машинное обучение: именно оно способно на больших массивах данных искать иголки в стоге сена лучше человека, ловить то, что человек, скорее всего, пропустит.
– Сколько «Светофор» уже сэкономил компании?
М.И.: За полных 3–4 месяца функционирования продукта, когда он применялся уже во всей сети, система сэкономила около 12% затрат на процесс приемки. Это достаточно неплохо, хотя мы рассчитывали на несколько большее. Но и период времени должен быть больше.
— В каком направлении может развиваться решение, частью каких других дата-сервисов оно может стать?
М.Г.: Мы хотели бы развивать рекомендательные алгоритмы в логистике. «Светофор 3.0» — уже второй продукт, который позволяет сократить количество проверок и пересчетов. В ближайшем будущем мы начнем создавать новые продукты, которые с учетом различных факторов будут решать задачи уменьшения пересчетов в магазинах.