Разработка системы маршрутизации курьеров и оптимизации доставки

Что такое система маршрутизации курьеров и кому она нужна

Система маршрутизации курьеров — это бэк-сервис, который в реальном времени решает задачу: «есть N заказов и M свободных курьеров, разные точки забора и доставки, окна выдачи и горящие блюда — как распределить заказы и построить маршруты, чтобы доставить максимум за смену с минимальным временем в пути?». Без неё операционка работает на интуиции диспетчера и движется со скоростью человеческой реакции: это терпимо на 30–50 заказах в день, но ломается на 200+.

Академически класс задачи известен как Vehicle Routing Problem (VRP) — обобщение задачи коммивояжёра на множество машин с ограничениями. В чистом виде она вычислительно неразрешима за разумное время и в реальных проектах решается приближёнными методами: эвристики ALNS, библиотека OR-Tools от Google, готовые сервисы вроде Yandex.Routing API для российского рынка.

Кастомная система маршрутизации оправдана, когда:

• В сети 50+ заказов в смену, и диспетчер физически не успевает балансировать вручную.
• Несколько источников (рестораны, dark kitchen, магазины) и десятки курьеров — задача распределения, недоступная ручной диспетчеризации.
• Бизнес теряет 10–30% курьерочасов на неоптимальных маршрутах — это десятки миллионов рублей в год на крупной сети.
• Курьеры жалуются на хаотичные перегоны, а бизнес — на жалобы клиентов по опозданиям.
• Уже используется простая маршрутизация в составе POS-платформы, но её ограничений не хватает.

Если сеть только запускается и в день 10–50 заказов — лучше начать с ручной диспетчеризации и подключения Yandex.Routing API как готового сервиса. Кастомная разработка имеет смысл, когда уже есть данные и понятны ограничения готовых решений.

Какие задачи маршрутизации решаем

«Маршрутизация» — собирательное понятие: под разные задачи нужны разные алгоритмы, интеграции и бюджет. Под бизнес обычно выбирают 1–2 приоритетных типа для MVP, остальные добавляют поэтапно.

Чем foodtech-маршрутизация отличается от общей логистики

Маршрутизация для доставки «последней мили» в e-commerce (посылки, документы) и для foodtech — разные классы задач, хотя на первый взгляд похожи. Если применить «логистическую коробку» к еде, продукт ломается в часы пик.

Если задача — доставка еды, а не пакетов из интернет-магазина, маршрутизатор должен учитывать готовность блюд, разделение горячего и холодного и часы пик кухни. Это полноценный foodtech-продукт, а не «коробка под доставку». Базовая логистика — на странице приложений для логистики.

Связь маршрутизации с готовностью блюд на кухне

Главное, чем foodtech-маршрутизация отличается от любой другой. В обычной логистике груз ждёт на складе — здесь он готовится прямо в момент маршрута. Если курьер приехал за 5 минут до готовности, он стоит и теряет минуты; если на 10 минут позже — блюдо остыло и клиент недоволен. Что закладываем в архитектуру:

• Прогноз времени готовности. Модель на истории конкретной кухни в конкретный час оценивает, во сколько блюдо будет готово, — с учётом текущей загрузки, типа блюда (пицца / суши / коктейль) и числа параллельных заказов.
• Синхронизация с POS. Интеграция с POS даёт реальный статус: «начато → готовится → готово к выдаче». Маршрутизатор подбирает курьера так, чтобы тот подъехал ровно к моменту готовности.
• Окно ожидания на точке. Если прогноз ошибся, курьер не стоит больше 5–7 минут: иначе заказ возвращается в очередь, а курьер берёт следующий.
• Разделение горячего и холодного. Если в маршруте пицца + мороженое + кофе, система группирует заказы так, чтобы холодное и горячее не ехали вместе долго.
• Связь с computer vision на кухне. На зрелых проектах камера на станции выдачи определяет «блюдо готово» и сама меняет статус заказа — меньше зависимости от ручной отметки повара.

Без этого слоя система работает «как для пакетов» и теряет 10–15% эффективности из-за рассинхронизации с кухней.

Перераспределение заказов в реальном времени

Заказы в foodtech приходят непрерывно, а не пачкой утром. Курьер уже выехал на адрес — и тут появляется новый заказ из соседнего дома: нужно решить, передать его этому курьеру или назначить другому. Что делает система:

• Динамический пересчёт. Каждый новый заказ запускает пересчёт планов всех активных курьеров — добавить заказ тому, кто рядом и с лёгким маршрутом, или придержать до следующего свободного.
• Прогноз будущих заказов. ML-модель оценивает, сколько заказов придёт в ближайшие 15–30 минут, — чтобы понимать, можно ли загрузить свободного курьера сейчас.
• Разбор сложных ситуаций. Курьер застрял в пробке — его последний заказ переназначается ближайшему свободному; курьер не выходит на связь — заказ передаётся другому без потери времени.
• Балансировка нагрузки. Не «один курьер делает 80% заказов, остальные стоят», а равное распределение в течение смены.

Это двухфазный подход: на старте смены — статичное планирование, в течение смены — оптимизация в реальном времени. Готовые сервисы (Yandex.Routing API в чистом виде) такую задачу не закрывают — нужна кастомная обёртка под специфику foodtech.

Архитектура системы маршрутизации

1. Бэк-сервис маршрутизации

Сердце системы: принимает заказы, координаты и состояние курьеров, выдаёт оптимальный план. Три модели реализации — поверх Yandex.Routing API (простые сценарии), OR-Tools на своей инфраструктуре (гибкие ограничения) или собственное ядро на ALNS (очень сложные задачи). В реальных проектах часто гибрид: OR-Tools или ALNS как ядро плюс Yandex.Maps API для геокодирования и матриц расстояний.

2. Приложение курьера

Мобильное приложение (Flutter) с назначениями и оптимальным маршрутом: встроенный навигатор, связь с клиентом и оператором, учёт смены. Подробнее о классе задач — на странице приложения для службы доставки.

3. Кабинет диспетчера

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

4. Интеграции

POS-системы (iiko / R-Keeper / Poster) — заказы и готовность блюд; CRM — приоритеты VIP и история жалоб; платёжный шлюз — закрытие заказа после доставки; push-сервисы — уведомления курьерам и клиентам; Yandex.Maps API — геокодирование, маршрутизация, аналитика пробок.

5. ML-слой (опционально)

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

Кейсы Surf

Мы создаём foodtech-продукты для лидеров рынка — от стартапов до федеральных сетей. Несколько релевантных проектов из портфеля (полный — на странице foodtech-практики):

Юнит-экономика маршрутизации

Кастомная система маршрутизации — инвестиция от 8–15 млн ₽. Окупаемость считаем по четырём направлениям.

• Рост числа доставок за смену. В кейсе Лабиринта — +20% доставок за смену благодаря оптимальным маршрутам. На сети с 1 000 курьеров и средним доходом сети 500 ₽ с доставки это десятки миллионов рублей дополнительного оборота в месяц.
• Снижение курьерочасов на тот же объём. Оптимальные маршруты сокращают время в пути на 15–30%; на фонде оплаты курьеров в десятки миллионов рублей это многомиллионная экономия в месяц.
• Меньше опозданий и компенсаций. Опоздание — это промокод, компенсация или возврат. Каждый процент опозданий — десятки тысяч рублей потерь в месяц на средней сети; качественная маршрутизация снижает опоздания в два-три раза.
• Удержание курьеров. Курьер с хаотичным маршрутом устаёт и уходит. Прозрачная нагрузка снижает текучесть на 10–20%, а каждый удержанный курьер — это десятки тысяч рублей сэкономленного найма и обучения.

На сети из 200+ курьеров кастомная система маршрутизации окупается за 6–12 месяцев. Точную финансовую модель готовим на этапе Discovery.

Кастомная разработка, Yandex.Routing, OR-Tools или готовая платформа

На рынке три-четыре пути решения задачи.

Тонкость: даже кастомная система обычно использует Yandex.Maps API как нижний слой (геокодирование, координаты, матрицы расстояний, пробки). Мы строим кастомный солвер поверх — с интеграцией готовности кухни, разделением горячего и холодного, динамикой в реальном времени.

Процесс разработки

Стек технологий

Команда: продакт, закреплённый тимлид-архитектор с опытом VRP-проектов, VRP-инженер (ядро OR-Tools / ALNS / Yandex.Routing), 2–3 backend-разработчика, ML-инженер, mobile-разработчик (приложение курьера), frontend-разработчик (кабинет диспетчера), QA, DevOps. Параллельно — обучение курьеров и диспетчеров новому инструменту; эта часть пересекается с LMS для линейного персонала.

Стоимость и сроки

Что влияет на бюджет: сложность задачи (тип из четырёх выше), объём заказов в час пика, наличие исторических данных для обучения моделей, глубина интеграций (одна POS или мультистек), пересчёт в реальном времени или ночные расчёты, стек (Flutter или нативная пара iOS+Android). Если нужно проверить узкую гипотезу за 2–3 месяца — стартуйте с MVP foodtech. Ценовой ориентир по курьерскому приложению — в гайде «сколько стоит приложение для курьеров», сроки — в гайде по срокам разработки.