Как стать автором
Обновить
0

Успеть за 12 минут: как мы научились прогнозировать время доставки товаров из Утконос ОНЛАЙН

Время на прочтение 8 мин
Количество просмотров 3.6K

Всем привет! Меня зовут Лера, и я Data Scientist компании Утконос ОНЛАЙН. Мы 20 лет доставляем продукты и товары для дома нашим клиентам. За последние два года требования к скорости доставки и качеству обслуживания сильно выросли. Время в нашем бизнесе — самый важный и критический фактор. Этот показатель, как и другие процессы, нужно постоянно улучшать, иначе сервис не выдержит конкуренции.

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

Что такое время обслуживания клиента 

Доставка заказов клиентам — один из важнейших процессов в компании. Для простоты объяснения, что такое обслуживание клиента, разделим весь процесс доставки заказов курьером на две части: время, затраченное на дорогу, и время на финальной точке — у клиента. Время на финальной точке — это и есть время обслуживания клиента, или service time. В этот момент курьер доставляет заказ от автомобиля до двери и выполняет все сопутствующие действия: собирает заказ в автомобиле, проверяет состав заказа вместе с клиентом, принимает оплату и так далее. 

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

19 минут на доставку заказа — слишком много?

Раньше мы считали время обслуживания клиента константным, равным 19 минутам. Но на все ли заказы требуется именно 19 минут, а не, например, 12 или 25?

Кто-то живет на первом этаже, а кто-то на двадцатом. Кто-то знаком с Утконосом многие годы, принимает 15 пакетов продуктов, 20 литров воды и говорит: «Спасибо, я вам доверяю». А кто-то сделал свой первый заказ и хочет убедиться, что у всех йогуртов действительно нормальный срок годности. Каждому из этих клиентов требуется разное время на то, чтобы принять заказ, а курьерам требуется разное время на то, чтобы эти заказы доставить. 

Зная это, мы решили построить сервис, который по каждому заказу позволяет спрогнозировать время, требующееся на доставку. Если в каком-то заказе есть риск не уложиться в 19 минут, мы не будем брать в рейс больше заказов, а сконцентрируемся на более качественной доставке, чтобы у клиента было время спокойно проверить свой заказ. И наоборот, если на доставку заказа можно заложить 12 минут — добавляем больше заказов в рейс.

Собираем данные о времени доставки 

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

С одной стороны, у нас было множество готовых таймстемпов: отметки курьеров о прибытии на точку и отъезде, данные из систем построения маршрутов, время пробития чека и прочее. Но на деле эти данные нередко было сложно совместить друг с другом. Например, по системе мы могли видеть, что курьер доставил третий заказ в рейсе, а по GPS-трекам мы видим, что в этот момент курьер находился у клиента пятого заказа.

Тогда мы пошли другим путем. Большая часть наших автомобилей оборудована датчиками, которые передают различные показания, в том числе GPS-координаты нахождения автомобиля в тот или иной момент времени. Мы решили, что попробуем на основе этих данных построить “честную” оценку service time, не зависящую от человеческого фактора или каких-либо прогнозов других систем.  

Исследовав данные и обсудив все решения с бизнесом, мы подготовили расчет актуального service time. Теперь мы определяем данный показатель, используя и GPS-треки автомобилей, и время пробития чека, и адрес клиента, комбинируя все это воедино с помощью несложных эвристик. 

В простом случае расчет service time приведен на схеме ниже. В некотором радиусе от дома клиента мы определяем остановки автомобиля — те точки, на которых по GPS-трекам автомобиль стоял на месте не менее 2 минут. Остановки, если их было несколько, соединяем воедино и получаем время обслуживания клиента.

На протяжении всего процесса работы над задачей мы тесно сотрудничали с нашей командой TMS (система управления транспортом): обсуждали с ними бизнес-постановку, советовались, как и что лучше делать, показывали промежуточные и итоговые результаты. Для валидации построенного service time использовали один из разработанных TMS сервисов — визуальное отображение положения автомобиля на карте во время рейса. В данном сервисе мы выборочно проверяли некоторые рейсы и убеждались, что в рассчитанное время курьер действительно находился у клиента, а не в дороге.

Также в проверке наших расчетов нам очень помогла Академия склада и курьеров*. 

(*Академия Утконоса отвечает за обучение и развитие коллег - курьеров и специалистов склада. Обучает с первого дня работы в компании и технологиям работы и кодексам поведения с помощью как онлайн инструментов, так и практического наставничества на рабочем месте.)

Коллеги согласились выполнить для нас экспериментальный рейс. В этом рейсе курьер отмечал свои действия и затраченное на них время: подъезд к дому, время завершения парковки и т.д. Благодаря такой детализации рейса мы смогли убедиться, что наши расчеты хоть и не идеальны, но достаточно близки к истине, и их можно использовать. 

Что показали цифры 

Итак, мы:

  • рассчитали время обслуживания;

  • проверили точность на практике;

  • убедились в том, что на разные заказы требуется разный service time, и это время имеет достаточно большой разброс. 

Что самое интересное, медианное значение service time оказалось равным 13 минутам. Это значит, что нам есть, что оптимизировать. 

По полученным данным мы построили дашборд и передали его коллегам из TMS. Так в компании появился новый инструмент для мониторинга качества нашего сервиса, анализа и поиска точек для развития.

Строим модель 

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

Наша модель имеет 8 параметров, самым важными из которых оказались вес и объем заказа, этаж клиента и тип оплаты. 

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

Для сравнения использовались метрики MAE (средняя абсолютная ошибка), MedAE (медианная абсолютная ошибка) и MAPE (средняя абсолютная ошибка в процентах). Также мы ввели такую метрику как уровень сервиса — это доля заказов, для которых прогнозируемый service time не превышает фактический service time. Для нас это была основная метрика, от которой мы отталкивались и под которую подстраивались. При построении модели было важно, чтобы показатели качества сервиса остались на изначальном уровне.  

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

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

Но для тестирования в продуктиве все-таки остановились на модели в сыром виде, без сдвига на константу и штрафа за недопрогноз. При анализе данных о доставке заказов со склада «Бутово» (всего у нас 4 склада), где мы собирались проводить тестирование прогноза, мы обнаружили, что модель со штрафом выдает слишком большие прогнозные значения service time. Модель в сыром виде выдавала не такие большие значения, имела меньшую MAE, а уровень сервиса был лишь немного ниже, чем у старого подхода. Поэтому остановились на ней. 

В итоге новая прогнозная модель по сравнению со старым подходом показала снижение MAE с 8 до 5.5 минут, MAPE с 43% до 38%. Наш “запасной” вариант с кастомной функцией потерь показал метрики MAE 6.8 минут, MAPE 39%. 

На этапе построения модели нам уже интересно, какой бизнес-результат может принести построенный прогноз. Для оценки мы проделали достаточно простой расчет: взяли исторические рейсы и посмотрели, сколько времени можно сэкономить/потратить, если вместо прогноза старого подхода (констант) мы ставим новый прогноз. Дальше посчитали, сколько заказов в среднем поместилось бы в сэкономленное время или наоборот, пришлось бы убрать из рейса, если бы времени оказалось мало. В итоге, по нашим данным при использовании этой модели можно было доставить на 1.5% заказов больше теми же ресурсами. 

Выкатываем в прод 

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

Обращение к модели прогноза service time происходит на этапе построения маршрута для курьера.   

Для тестирования модели в продуктиве мы выбрали определенный склад и определенный тип доставки — B2C клиентам на дом или в офис. Для прогноза наши логисты задали некоторые ограничения: service time был ограничен снизу (12 минут) и сверху (18 минут), исходя из актуального распределения времени обслуживания клиентов по заказам с данного склада. На момент начала тестирования до внедрения построенной модели service time на данном складе уже составлял либо 15, либо 17 минут.

Итог и планы на будущее 

Модель тестировалась несколько месяцев. За время тестирования уровень сервиса не упал, количество жалоб на опоздания в доставке не выросло. Число слотов доступных для заказов увеличилось на 1.5% и среднее время обслуживания клиентов снизилось на 8%.

И конечно же у нас есть план на будущее — улучшение модели. 

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

Быстрая доставка и мини-склады в компании появились только в 2020 году, и на момент построения модели (конец 2020 года) данных по этим складам было накоплено не очень много. Сейчас, имея больше информации, мы можем правильнее учесть склад доставки и повысить эффект для мини-складов. 

Также есть еще большой простор для работы над параметрами для обучения. Например, больше поработать над координатами заказа, добавить данные из открытых источников по адресам. Погрузиться больше в описание клиента: мы пробовали добавить банальные параметры вроде общего количества заказов и времени регистрации, но они не имели значимости в модели. Кроме этого, появляются новые параметры доставки — например, возможность оставить заказ у двери. Со временем данной возможностью пользуется все больше клиентов, и этот параметр также должен уменьшать service time. 

Проведение такого пилота — большой успех для всей нашей команды. Это был первый проект Data Science в компании, который был интегрирован в действующую систему, да к тому же такую важную как TMS.

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

Надеюсь, что статья была интересной. Пишите ваши вопросы, а я постараюсь ответить. Кстати, мы сейчас ищем новых коллег в дата офис, подробности и описание в нашем ТГ-канале.

Теги:
Хабы:
+15
Комментарии 2
Комментарии Комментарии 2

Публикации

Информация

Сайт
t.me
Дата регистрации
Численность
1 001–5 000 человек
Местоположение
Россия
Представитель
dianabars

Истории