Привет, Хабр! Меня зовут Артём Селихов, я Product manager в команде СберМаркета, и я отвечаю за управление программными продуктами для операционных процессов, которые мы разрабатываем для наших партнеров — курьеров и экспертов по закупке.
В первом посте мы уже рассказывали о, том, что за последние месяцы СберМаркет вырос в несколько раз, а доставка продуктов превратилось в сервис для жителей всей страны. Сегодня же я хочу рассказать о том, что у нас «под капотом», какие мы используем подходы, чтобы своевременно обнаруживать проблемы и балансировать процессы. Этот пост будет полезен для тех, кто разрабатывает системы взаимодействия с партнерами, а также интересуется сложными задачами в области Marketplace efficiency. Желающих почитать про наши многочисленные задачи в области Data Science приглашаем под кат.
СберМаркет начинал работу как стартап в сфере eGrocery под названием Instamart. Мы изначально взяли за образец операционную модель североамериканской компании Instacart и создали свое видение работы сервиса доставки. И СберМаркет, и Instacart покупают за вас продукты с полок выбранного магазина, а потом привозят их к вам домой. При этом Instacart успешно конкурирует с Amazon, Wallmart и Target в США. А СберМаркет, соответственно, с Утконосом, Перекрестком и другими российскими онлайн-ритейлерами, предоставляющими сервис доставки.
Однако самое интересное с точки зрения разработчика в том, что доставка с полки магазина — это не только доставка. Такой бизнес был бы невозможен без активного вовлечения специалистов по закупкам, которые каждый день бережно собирают десятки тысяч заказов в магазинах ритейлеров в более чем 100 городах России. При этом нам приходится брать на себя роль маркетплейса, решая проблемы выравнивания спроса и предложения.
Мы разработали собственные методы, которые позволяют достигнуть баланс между количеством поступающих заказов от клиентов и наличием исполнителей, обеспечивая непрерывную операционную деятельность. При этом мы стремимся гарантировать максимальное удобство для клиента, одновременно оптимизируя затраты. В этом посте мне хочется поговорить о наших проектах, которые помогают создавать качественный сервис для клиентов, сохраняя эффективность бизнеса. Какие-то из них уже реализованы, а другие — находятся в стадии развития и ждут своих героев, которые помогут воплотить перспективные концепции в коде.
Когда клиент СберМаркета делает заказ на сайте или в приложении, он видит временные слоты, в которые он может получить свой заказ. Некоторые интервалы могут быть недоступны для выбора. Это происходит потому, что в это время нет свободных ресурсов для сборки и доставки. Для клиента это серьезное ограничение, ведь если удобного времени доставки не будет, он может и вовсе отказаться от заказа, чего мы, естественно, не хотим.
Чтобы решить эту проблему, мы решили выстроить полноценную систему Marketplace efficiency. Вопрос балансировки спроса и сервиса нужно решать на трех разных уровнях:
Общая схема Marketplace efficiency
Мы пользуемся следующими метриками для оценки ситуации:
Чтобы разобраться во всей системе, нужно понять, как именно работает каждый ее сегмент. Для этого мы рассмотрим сначала Marketplace forecasting.
Долгосрочное планирование является критически важной задачей. Чтобы обеспечить клиенту возможность заказа в любое время, нужно спрогнозировать наш спрос на предстоящие пару месяцев и привлечь достаточное количество партнеров к обработке заказов. В состав этого сегмента входит сразу несколько модулей:
Demand forecast отвечает за прогнозирование спроса. Система учитывает % доступности слотов для заказа конкретном магазине и прогнозирует, каким был бы спрос, если бы доступность была выше. То есть, модуль определяет, какой процент временных слотов был доступен клиенту из всех возможных. Так мы получаем метрику Ideal demand level — это восстановленный спрос, с учетом клиентов, не нашедших удобное время доставки и бросивших корзину.
OPS hiring подсказывает нам, сколько FTE (full-time employee, эквивалент одного полностью занятого работника) нам нужно в каждой точке под наш идеальный спрос. Эта система также помогает определить, какой именно нам нужен специалист: курьер, специалист по закупкам, кладовщик зоны самовывоза, упаковщик. Привлечение специалистов происходит на контрактной основе как самозанятых. Таким образом, для организации работы сервиса мы выбрали нечто среднее между схемой почасового привлечения как в Instacart/Delivery Club и полного найма. При этом мы работаем с партнерами как на долгосрочной основе, так и для выполнения конкретных заказов. Например, в некоторых случаях компания Ситимобил может отвезти любой заказ вместо нашего курьера-партнера, помогая нам перекрывать пики спроса.
Distant learning помогает нам решать стратегическую задачу расширения сети партнеров. Ведь, в конечном счете, мы стремимся к тому, человек мог начать работать с нами как можно быстрее. В идеале мы хотим прийти к тому, чтобы обучение происходило прямо внутри нашего мобильного приложения для партнеров (т.н. Shopper App).
Прямо сейчас эта система находится в стадии разработки, но ее задачи уже ясны. Мы хотим, чтобы небольшой тест мог показать, готов ли партнер собирать или развозить заказы клиентам. Идея заключается в том, чтобы обеспечить постоянное обучение наших партнеров для повышения качества их работы. А если мы понимаем, что партнер не смог сразу усвоить все тонкости выбора, например, авокадо, система должна попросить его пройти пройти этот курс еще раз.
Основная задача сегмента Supply planning — спланировать привлечение такого количества партнеров на каждый день недели, чтобы полностью закрыть предполагаемый спрос. На этом горизонте система Demand forecasting планирует уже не по дням, а в том числе и по часам дня, чтобы привлечение правильного количества партнеров позволяло компенсировать дневные колебания спроса. Как правило, учитывать приходится утренний и вечерний пики.
Workforce management system (WMS) подсказывает нам, сколько партнеров и в каких ролях должны выйти и приступить к работе над заказами в каждый конкретный день недели. Ключевая метрика для этого сегмента — Staff utilisation (соотношение доступных нам партнёров по доставке и сборке к необходимому уровню). Если показатель оказывается ниже 100%, то мы сталкиваемся с ситуацией нехватки людей (understaffed). Если больше 100%, то мы выводим людей с запасом (overstaffed). И то, и другое — плохо для бизнеса, поэтому WMS должна постоянно стремиться приблизиться к идеальному уровню загруженности команды. Для решения этой задачи можно использовать системы известных вендоров. Как раз сейчас мы взвешиваем все «за» и «против», чтобы сделать выбор между адаптацией готового решения и самостоятельной разработкой.
Capacity planning system проводит математические расчеты для управления доступностью. Чтобы сделать их проще, мы используем понятие Timeslot limit (максимально возможное количество «усредненных» заказов, которое мы можем на себя взять в данный интервал времени, чтобы не нарушить обязательства перед клиентом). Этот показатель определяется исходя из количества партнеров, которых мы смогли спланировать и привлечь за счет работы Workforce management system, и их усредненной производительности. Сейчас система Capacity planning находится в состоянии модели (sql-based model), и мы как раз ищем талантливого разработчика, который смог бы «отлить» ее в коде.
На протяжении каждого дня в работе сервиса доставки возникают дополнительные переменные, и здесь от нашей команды требуется особая гибкость, потому что изменять планы приходится в режиме реального времени.
Например, нередко бывает так, что:
Метрика Actual supply отражает реальную доступность количества курьеров и экспертов по закупкам. Партнеры могут выйти на работу раньше или позже назначенного времени, а могут и не выйти вовсе. Могут сообщить об этом или оказаться «вне зоны действия сети». Мы учитываем все варианты, и реальная доступность людей всегда отличается от запланированной. Она начинается и заканчивается фиксацией выхода на смену и завершением смены.
Real-time orders dispatch — это самое сердце нашего сервиса. Система состоит из двух взаимосвязанных модулей, каждый из которых решает свою задачу, чтобы вместе обеспечить максимальную автоматизацию бизнес-процессов:
Vehicle route planning обеспечивает маршрутизацию заказов. Как правило, наш курьер отвозит 1-2 заказа на легком транспорте (велосипед, самокат), до 7 заказов на легковом автомобиле и до 20 — на грузовом. Во главу угла при планировании ставится логистическая эффективность рейса и минимизация опозданий. Для этого система умеет учитывать множество факторов реальной логистики, и вот лишь основные из них:
Пример маршрутного листа с точками на картах Яндекс
Assembly real-time dispatch (диспетчеризация сборки заказов) выполняет задачи полностью аналогичные маршрутизации заказов, только с точки зрения их сборки и упаковки. Основываясь на информации о запланированных рейсах система предлагает оптимальную последовательность сборки заказов, с учетом опыта работы каждого конкретного партнера. И прямо сейчас мы работаем над развитием этой системы.
Маршруты рейсов и последовательность сборки пересчитывается несколько раз в час, чтобы своевременно учесть все произошедшие изменения в системе и информацию из окружающего мира. При этом рейсы ближайших погрузок фиксируются, чтобы гарантировать своевременную сборку и отгрузку. Маршруты будущих доставок постоянно оптимизируются, а основной задачей системы диспетчеризации сборки (как зависимой системы) остается обеспечение максимально эффективной и своевременной сборки заказов ко времени отправки рейсов.
Рейсы магазина METRO Ижевск.
Open hour = (Available capacity — Order processing time > 0? true: false)
Концепция Marketplace efficiency объединяет в себе три составляющих, которые помогают нам прогнозировать спрос, планировать привлечение партнеров, а также реагировать на ситуацию в реальном времени. С ростом потока заказов задачи, решаемые в рамках развития этих систем, становятся все более сложными и нетривиальными. При, казалось бы, очевидной задаче доставки с полок магазинов, для построения действительно оптимальных бизнес-процессов при более чем 20К заявок в сутки, от разработчиков требуются в том числе навыки в области AI и ML. Именно поэтому мы продолжаем набирать разработчиков, способных решать сложные задачи, связанные с планированием, прогнозированием и обработкой больших данных в области операций.
Конечно, обо всех модулях Marketplace Efficiency можно поговорить подробнее, равно как и о подводных камнях, которые всплывают на разных этапах развития системы и ее интеграции с другими ИС в СберМаркете. Поэтому я буду рад, если вы поделитесь своими вопросами и мнениями в комментариях.
В первом посте мы уже рассказывали о, том, что за последние месяцы СберМаркет вырос в несколько раз, а доставка продуктов превратилось в сервис для жителей всей страны. Сегодня же я хочу рассказать о том, что у нас «под капотом», какие мы используем подходы, чтобы своевременно обнаруживать проблемы и балансировать процессы. Этот пост будет полезен для тех, кто разрабатывает системы взаимодействия с партнерами, а также интересуется сложными задачами в области Marketplace efficiency. Желающих почитать про наши многочисленные задачи в области Data Science приглашаем под кат.
СберМаркет начинал работу как стартап в сфере eGrocery под названием Instamart. Мы изначально взяли за образец операционную модель североамериканской компании Instacart и создали свое видение работы сервиса доставки. И СберМаркет, и Instacart покупают за вас продукты с полок выбранного магазина, а потом привозят их к вам домой. При этом Instacart успешно конкурирует с Amazon, Wallmart и Target в США. А СберМаркет, соответственно, с Утконосом, Перекрестком и другими российскими онлайн-ритейлерами, предоставляющими сервис доставки.
Однако самое интересное с точки зрения разработчика в том, что доставка с полки магазина — это не только доставка. Такой бизнес был бы невозможен без активного вовлечения специалистов по закупкам, которые каждый день бережно собирают десятки тысяч заказов в магазинах ритейлеров в более чем 100 городах России. При этом нам приходится брать на себя роль маркетплейса, решая проблемы выравнивания спроса и предложения.
Мы разработали собственные методы, которые позволяют достигнуть баланс между количеством поступающих заказов от клиентов и наличием исполнителей, обеспечивая непрерывную операционную деятельность. При этом мы стремимся гарантировать максимальное удобство для клиента, одновременно оптимизируя затраты. В этом посте мне хочется поговорить о наших проектах, которые помогают создавать качественный сервис для клиентов, сохраняя эффективность бизнеса. Какие-то из них уже реализованы, а другие — находятся в стадии развития и ждут своих героев, которые помогут воплотить перспективные концепции в коде.
СберМаркет — механизм работы с заказами
Когда клиент СберМаркета делает заказ на сайте или в приложении, он видит временные слоты, в которые он может получить свой заказ. Некоторые интервалы могут быть недоступны для выбора. Это происходит потому, что в это время нет свободных ресурсов для сборки и доставки. Для клиента это серьезное ограничение, ведь если удобного времени доставки не будет, он может и вовсе отказаться от заказа, чего мы, естественно, не хотим.
Чтобы решить эту проблему, мы решили выстроить полноценную систему Marketplace efficiency. Вопрос балансировки спроса и сервиса нужно решать на трех разных уровнях:
- Marketplace forecasting – долгосрочное планирование (месяц и более);
- Supply planning – краткосрочное планирование (ближайшая неделя);
- Real-time capacity – оперативное планирование внутри дня.
Общая схема Marketplace efficiency
Мы пользуемся следующими метриками для оценки ситуации:
- Доступность (Availability) − количество часов до ближайшего доступного временного интервала
- Утилизация слотов (Time-slot utilization) − заполненность выделенной емкости для временных интервалов
- Упущенные поставки (Lost deliveries) − % брошенных корзин по причине недоступности слотов
Чтобы разобраться во всей системе, нужно понять, как именно работает каждый ее сегмент. Для этого мы рассмотрим сначала Marketplace forecasting.
Marketplace forecasting
Долгосрочное планирование является критически важной задачей. Чтобы обеспечить клиенту возможность заказа в любое время, нужно спрогнозировать наш спрос на предстоящие пару месяцев и привлечь достаточное количество партнеров к обработке заказов. В состав этого сегмента входит сразу несколько модулей:
Demand forecast отвечает за прогнозирование спроса. Система учитывает % доступности слотов для заказа конкретном магазине и прогнозирует, каким был бы спрос, если бы доступность была выше. То есть, модуль определяет, какой процент временных слотов был доступен клиенту из всех возможных. Так мы получаем метрику Ideal demand level — это восстановленный спрос, с учетом клиентов, не нашедших удобное время доставки и бросивших корзину.
OPS hiring подсказывает нам, сколько FTE (full-time employee, эквивалент одного полностью занятого работника) нам нужно в каждой точке под наш идеальный спрос. Эта система также помогает определить, какой именно нам нужен специалист: курьер, специалист по закупкам, кладовщик зоны самовывоза, упаковщик. Привлечение специалистов происходит на контрактной основе как самозанятых. Таким образом, для организации работы сервиса мы выбрали нечто среднее между схемой почасового привлечения как в Instacart/Delivery Club и полного найма. При этом мы работаем с партнерами как на долгосрочной основе, так и для выполнения конкретных заказов. Например, в некоторых случаях компания Ситимобил может отвезти любой заказ вместо нашего курьера-партнера, помогая нам перекрывать пики спроса.
Distant learning помогает нам решать стратегическую задачу расширения сети партнеров. Ведь, в конечном счете, мы стремимся к тому, человек мог начать работать с нами как можно быстрее. В идеале мы хотим прийти к тому, чтобы обучение происходило прямо внутри нашего мобильного приложения для партнеров (т.н. Shopper App).
Прямо сейчас эта система находится в стадии разработки, но ее задачи уже ясны. Мы хотим, чтобы небольшой тест мог показать, готов ли партнер собирать или развозить заказы клиентам. Идея заключается в том, чтобы обеспечить постоянное обучение наших партнеров для повышения качества их работы. А если мы понимаем, что партнер не смог сразу усвоить все тонкости выбора, например, авокадо, система должна попросить его пройти пройти этот курс еще раз.
Краткосрочное планирование (Supply planning)
Основная задача сегмента Supply planning — спланировать привлечение такого количества партнеров на каждый день недели, чтобы полностью закрыть предполагаемый спрос. На этом горизонте система Demand forecasting планирует уже не по дням, а в том числе и по часам дня, чтобы привлечение правильного количества партнеров позволяло компенсировать дневные колебания спроса. Как правило, учитывать приходится утренний и вечерний пики.
Workforce management system (WMS) подсказывает нам, сколько партнеров и в каких ролях должны выйти и приступить к работе над заказами в каждый конкретный день недели. Ключевая метрика для этого сегмента — Staff utilisation (соотношение доступных нам партнёров по доставке и сборке к необходимому уровню). Если показатель оказывается ниже 100%, то мы сталкиваемся с ситуацией нехватки людей (understaffed). Если больше 100%, то мы выводим людей с запасом (overstaffed). И то, и другое — плохо для бизнеса, поэтому WMS должна постоянно стремиться приблизиться к идеальному уровню загруженности команды. Для решения этой задачи можно использовать системы известных вендоров. Как раз сейчас мы взвешиваем все «за» и «против», чтобы сделать выбор между адаптацией готового решения и самостоятельной разработкой.
Capacity planning system проводит математические расчеты для управления доступностью. Чтобы сделать их проще, мы используем понятие Timeslot limit (максимально возможное количество «усредненных» заказов, которое мы можем на себя взять в данный интервал времени, чтобы не нарушить обязательства перед клиентом). Этот показатель определяется исходя из количества партнеров, которых мы смогли спланировать и привлечь за счет работы Workforce management system, и их усредненной производительности. Сейчас система Capacity planning находится в состоянии модели (sql-based model), и мы как раз ищем талантливого разработчика, который смог бы «отлить» ее в коде.
Real-time capacity
На протяжении каждого дня в работе сервиса доставки возникают дополнительные переменные, и здесь от нашей команды требуется особая гибкость, потому что изменять планы приходится в режиме реального времени.
Например, нередко бывает так, что:
- Клиент хочет разместить заказ на ближайший час. В этом случае нужно дать ему возможность заказа, если у нас есть ресурсы, чтобы его выполнить.
- Перенос времени заказа также является типовым событием, и в этом случае нужно спланировать разбор заказа и сборку его в другое время, а значит — найти для этого необходимые ресурсы.
- Всегда существует вероятность, что один или несколько партнеров не выйдут на работу к запланированному времени. Мы должны создать план действий и на этот случай :)
- А иногда партнер чисто физически не может отвезти именно такой заказ (по габаритам, весу, удаленности и т.д.), и подобные ситуации нужно решать максимально оперативно.
Метрика Actual supply отражает реальную доступность количества курьеров и экспертов по закупкам. Партнеры могут выйти на работу раньше или позже назначенного времени, а могут и не выйти вовсе. Могут сообщить об этом или оказаться «вне зоны действия сети». Мы учитываем все варианты, и реальная доступность людей всегда отличается от запланированной. Она начинается и заканчивается фиксацией выхода на смену и завершением смены.
Real-time orders dispatch — это самое сердце нашего сервиса. Система состоит из двух взаимосвязанных модулей, каждый из которых решает свою задачу, чтобы вместе обеспечить максимальную автоматизацию бизнес-процессов:
Vehicle route planning обеспечивает маршрутизацию заказов. Как правило, наш курьер отвозит 1-2 заказа на легком транспорте (велосипед, самокат), до 7 заказов на легковом автомобиле и до 20 — на грузовом. Во главу угла при планировании ставится логистическая эффективность рейса и минимизация опозданий. Для этого система умеет учитывать множество факторов реальной логистики, и вот лишь основные из них:
- выбранное окно доставки заказа;
- приоритетность заказа (с выделением заявок, по которым мы точно не хотим опоздать);
- во сколько будет собран заказ (с учетом того, опаздывает ли сборка или работает на опережение);
- каким видом транспорта лучше отвезти заказ (легкие, обычные и тяжелые заказы);
- какой объем и вес у каждого заказа, в какой автомобиль он входит;
- где находится водитель, когда заканчивается забронированное время аренды автомобиля.
Пример маршрутного листа с точками на картах Яндекс
Assembly real-time dispatch (диспетчеризация сборки заказов) выполняет задачи полностью аналогичные маршрутизации заказов, только с точки зрения их сборки и упаковки. Основываясь на информации о запланированных рейсах система предлагает оптимальную последовательность сборки заказов, с учетом опыта работы каждого конкретного партнера. И прямо сейчас мы работаем над развитием этой системы.
Маршруты рейсов и последовательность сборки пересчитывается несколько раз в час, чтобы своевременно учесть все произошедшие изменения в системе и информацию из окружающего мира. При этом рейсы ближайших погрузок фиксируются, чтобы гарантировать своевременную сборку и отгрузку. Маршруты будущих доставок постоянно оптимизируются, а основной задачей системы диспетчеризации сборки (как зависимой системы) остается обеспечение максимально эффективной и своевременной сборки заказов ко времени отправки рейсов.
Рейсы магазина METRO Ижевск.
Open hour = (Available capacity — Order processing time > 0? true: false)
Единая система
Концепция Marketplace efficiency объединяет в себе три составляющих, которые помогают нам прогнозировать спрос, планировать привлечение партнеров, а также реагировать на ситуацию в реальном времени. С ростом потока заказов задачи, решаемые в рамках развития этих систем, становятся все более сложными и нетривиальными. При, казалось бы, очевидной задаче доставки с полок магазинов, для построения действительно оптимальных бизнес-процессов при более чем 20К заявок в сутки, от разработчиков требуются в том числе навыки в области AI и ML. Именно поэтому мы продолжаем набирать разработчиков, способных решать сложные задачи, связанные с планированием, прогнозированием и обработкой больших данных в области операций.
Конечно, обо всех модулях Marketplace Efficiency можно поговорить подробнее, равно как и о подводных камнях, которые всплывают на разных этапах развития системы и ее интеграции с другими ИС в СберМаркете. Поэтому я буду рад, если вы поделитесь своими вопросами и мнениями в комментариях.