Введение

Аннотация.

Курс посвящён проектированию, настройке и эксплуатации TMS систем для эффективной маршрутизации доставки на этапе последней мили в сегменте доставки бутилированной воды. Ежедневные рейсы с тяжёлыми паллетами, возвратом пустой тары, жёсткими временными окнами клиентов и переменным спросом создают высокую операционную нагрузку. Без специализированной системы планирования маршрутов компании теряют до 25–35 % пробега, увеличивают число машин и получают жалобы на опоздания. Материал даёт полный цикл знаний — от выбора архитектуры TMS до внедрения алгоритмов оптимизации и контроля KPI — и позволяет сразу применять полученные навыки в реальных диспетчерских процессах.

Цель курса.

После прохождения курса вы сможете самостоятельно спроектировать, настроить и ежедневно эксплуатировать TMS систему для маршрутизации доставки бутилированной воды на последней миле, обеспечивая снижение пробега не менее чем на 18 % и выполнение временных окон не ниже 95 %.

Для кого этот курс.

Курс предназначен для логистов, диспетчеров, руководителей транспортных подразделений, специалистов по внедрению TMS и владельцев бизнеса, занимающихся доставкой бутилированной воды или аналогичными bulk-поставками (напитки, молочная продукция). Особенно полезен тем, кто уже использует Excel-планирование или простые GPS-трекеры и готов перейти на промышленную систему.

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

Основы TMS и их роль в last-mile логистике

TMS система — это программный комплекс, который планирует, исполняет и контролирует перевозки. В контексте последней мили ключевые модули включают: управление заказами, геокодирование точек, построение маршрутов с учётом ограничений, диспетчеризацию в реальном времени, мобильное приложение водителя и аналитику. Для доставки бутилированной воды критичны модули учёта веса и объёма паллет, возврата пустой тары и работы с временными окнами клиентов. Без TMS диспетчер тратит 3–4 часа ежедневно на ручное построение рейсов в Excel; с TMS это занимает 15–20 минут. Рекомендуемые промышленные решения: Oracle Transportation Management, SAP TM, Manhattan Active Transportation Management. Для среднего бизнеса часто выбирают облачные Route4Me, OptimoRoute или российские «Яндекс.Маршрутизация» и «Логист.Про».

Архитектура современной TMS системы строится по принципу микросервисов или модульного монолита. Ядро состоит из: Order Management (приём и валидация заказов), Master Data (справочники клиентов, транспорта, ограничений), Optimization Engine (алгоритмы VRP), Execution Layer (мобильное приложение и телематика), Analytics. Для маршрутизации доставки воды особенно важен слой Constraints Engine, где задаются правила: максимальный вес на ось, совместимость грузов, обязательный возврат тары, запрет ночных доставок. Практика показывает, что 70 % неудачных внедрений происходят из-за отсутствия качественных мастер-данных. Перед запуском оптимизации необходимо очистить адреса, привести координаты к единому формату WGS-84 и заполнить временные окна. Используйте сервис Nominatim или коммерческий Geocoder API для массового геокодирования.

Разница между TMS и простыми системами трекинга принципиальна. GPS-трекер показывает, где машина, но не говорит, каким должен быть оптимальный порядок точек. TMS системы решают задачу Vehicle Routing Problem с ограничениями. В доставке бутилированной воды типичная задача — Capacitated VRP with Time Windows (CVRPTW) плюс Pickup-and-Delivery для возврата тары. Без учёта этих ограничений маршрут может выглядеть коротким на карте, но водитель не сможет физически загрузить все бутыли или опоздает к клиенту с фиксированным окном 09:00–11:00. Анти-паттерн: пытаться «подогнать» Excel-маршрут под реальность после выезда. Правильный подход — полный цикл «планирование → симуляция → утверждение → исполнение → факт-анализ» внутри одной системы.

Выбор между облачной и on-premise TMS системой зависит от объёма и требований к безопасности данных. Облачные решения (Route4Me, OptimoRoute, «Яндекс.Маршрутизация») дают быстрый старт за 2–4 недели и масштабируются автоматически. On-premise или частное облако (Oracle, SAP, собственная разработка на OR-Tools) требуется, когда данные о клиентах и маршрутах являются коммерческой тайной или когда нужна глубокая кастомизация под возврат тары и сложные тарифы. Для компании с 15–40 машинами и 300–800 точками в день оптимален гибридный вариант: облачный движок оптимизации + собственный слой бизнес-правил. Стоимость владения (TCO) за три года для среднего парка обычно составляет 1,2–2,8 млн рублей при облаке и 4–7 млн при on-premise с учётом лицензий и поддержки.

Особенности логистики последней мили

Последняя миля — самый дорогой и наименее предсказуемый участок цепочки поставок. В городской доставке бутилированной воды она занимает 40–55 % общей стоимости логистики. Основные драйверы затрат: простой в пробках, поиск парковки, ожидание клиента, ручная разгрузка тяжёлых бутылей 19 л, возврат пустой тары. Классическая магистральная логистика оптимизирует длинные плечи; last-mile требует высокой плотности точек, коротких плеч и гибкости. Ключевой показатель — стоимость одной доставки (Cost per Drop). Хороший уровень для воды — 180–280 рублей при среднем пробеге 12–18 км на точку. Превышение 350 рублей сигнализирует о плохой маршрутизации или неверной зонировании.

Основные типы ограничений на последней миле: временные окна клиентов, грузоподъёмность и объём кузова, совместимость грузов, доступность точек (дворы, шлагбаумы, этажность), навыки водителя (работа с тарой, подъём на этаж). Для воды добавляются: обязательный обмен тары (полный/пустой), ограничение по весу на этаж, запрет доставки после определённого часа в жилых комплексах. В TMS системах эти ограничения кодируются как hard constraints (нарушение невозможно) и soft constraints (штраф в целевой функции). Практика: начинайте с 5–7 hard-ограничений, иначе оптимизатор не найдёт допустимое решение за разумное время. Инструмент: в Google OR-Tools используйте AddDimension и SetCumulVarSoftUpperBound для мягких окон.

Плотность точек — критический параметр эффективности. При плотности менее 8 точек на км² в городе маршрут становится невыгодным. Для доставки бутилированной воды целевая плотность в жилых районах — 12–25 точек на км². Если плотность ниже, рассмотрите микро-хабы или кросс-докинг из ближайшего склада. В TMS системе зонирование территории выполняется заранее: каждая зона закрепляется за фиксированным парком машин или динамически перераспределяется ежедневно. Анти-паттерн — «свободное плавание» машин по всему городу. Это увеличивает пробег на 22–30 %. Лучшая практика: фиксированные утренние зоны + динамическая догрузка во второй половине дня.

Реальное время и динамическая перестройка маршрутов — обязательный элемент современной последней мили. Заказы поступают в течение дня, клиенты отменяют или переносят окна, машины ломаются. TMS система должна поддерживать continuous optimization или re-optimization каждые 15–30 минут. Технически это реализуется через event-driven архитектуру: событие «новый заказ» или «отмена» запускает частичный пересчёт только затронутых маршрутов. Для воды важно учитывать, что уже загруженная машина не может принять дополнительный объём без возврата на склад. Поэтому алгоритм должен различать «ещё не выехавшие» и «в пути» рейсы. Инструмент: Route4Me Dynamic Routing или собственный сервис на базе OR-Tools + Redis для очереди событий.

Специфика доставки бутилированной воды

Доставка бутилированной воды обладает уникальным набором ограничений, которые редко встречаются в e-commerce или food-доставке. Основной SKU — бутыль 19 л весом около 20 кг. Средний заказ — 2–6 бутылей, но встречаются и паллетные поставки в офисы (24–48 бутылей). Кузов должен выдерживать высокий вес при относительно небольшом объёме. Возврат пустой тары создаёт задачу Pickup-and-Delivery: в каждой точке водитель одновременно разгружает полные и забирает пустые. Если не учесть возврат, машина переполнится раньше времени. В TMS системе это моделируется как два связанных запроса: delivery и pickup с одинаковым location_id и общим временным окном.

Временные окна клиентов в сегменте воды жёстче, чем в среднем по last-mile. Частные лица предпочитают 09:00–13:00 или 17:00–20:00, офисы — 10:00–16:00 без обеденного перерыва. Нарушение окна приводит к отказу принять товар и повторному выезду. В целевой функции оптимизации штраф за опоздание должен быть высоким (в 5–8 раз выше стоимости километра). Практика: введите мягкие окна ±15 минут и жёсткие ±30 минут. Для VIP-клиентов (сети ресторанов, крупные офисы) используйте fixed appointment. В маршрутизации доставки воды рекомендуется оставлять 12–15 % «воздуха» в расписании на непредвиденные задержки.

Учёт тары — отдельный бизнес-процесс. Каждая бутыль имеет статус «полная у клиента», «пустая у клиента», «пустая на складе», «в ремонте». TMS система должна синхронизироваться с системой учёта тары (часто это отдельный модуль или 1С). При планировании маршрута алгоритм проверяет, сколько пустых бутылей ожидается к возврату, и резервирует место в кузове. Если клиент «забыл» подготовить тару, водитель фиксирует это в мобильном приложении, и система автоматически создаёт задачу на следующий день. Анти-паттерн: игнорировать возврат тары при оптимизации — через 3–4 дня парк машин будет ездить полупустыми из-за скопления тары на точках.

Сезонность и пиковые нагрузки в доставке бутилированной воды выражены сильно. Летом спрос растёт на 40–70 %, зимой падает. Кроме того, есть недельные пики (понедельник и пятница) и внутридневные (утро). TMS система должна поддерживать сценарии «высокий сезон» с увеличенным парком и изменёнными зонами. Практический приём: храните исторические данные плотности заказов по часам и дням недели и используйте их как input для прогнозной модели спроса. Даже простой скользящий средний за 4 недели уже даёт точность 85–90 % и позволяет заранее выводить дополнительные машины.

Алгоритмы маршрутизации и математические основы

Классическая задача маршрутизации — Vehicle Routing Problem (VRP). В базовой формулировке есть депо, набор клиентов с известным спросом и парк одинаковых машин. Цель — минимизировать суммарный пробег при посещении всех клиентов. Для доставки бутилированной воды используется расширение CVRPTW (Capacitated VRP with Time Windows) плюс Pickup and Delivery. Математически целевая функция выглядит как $\min \sum_{i,j,k} c_{ij} x_{ijk}$, где $c_{ij}$ — стоимость дуги, $x_{ijk}$ — бинарная переменная использования дуги машиной k. Ограничения: каждая точка посещается ровно один раз, нагрузка не превышает ёмкости, время прибытия укладывается в окно.

Точные методы (branch-and-cut, column generation) работают только до 50–70 точек. Для реальных задач 200–800 точек применяют метаэвристики: Large Neighborhood Search, Genetic Algorithms, Tabu Search, Adaptive Large Neighborhood Search (ALNS). Google OR-Tools реализует мощный constraint programming + local search solver, который справляется с 500–1000 точками за 2–5 минут. В коммерческих TMS системах (Route4Me, OptimoRoute) используются собственные гибридные алгоритмы, часто с элементами машинного обучения для выбора операторов разрушения и ремонта. Рекомендация: для пилота начните с OR-Tools на Python, затем переходите на промышленный движок.

Матрица расстояний и времён — фундамент любой маршрутизации. Никогда не используйте евклидово расстояние для города. Применяйте OSRM (open-source), GraphHopper или коммерческие Google Maps Distance Matrix / HERE. Для воды важно учитывать запрет проезда грузовиков по некоторым улицам и ограничения по высоте/весу. Обновляйте матрицу не реже одного раза в сутки, а в часы пик — каждые 2 часа. Анти-паттерн: строить маршруты по статичной матрице ночного времени — утром в пробках план развалится. Лучшая практика: использовать traffic-aware матрицу и добавлять 15–20 % буферного времени на каждый сегмент в час пик.

Мастер-данные и подготовка к оптимизации

Качество TMS системы на 80 % определяется качеством мастер-данных. Минимальный набор: точные координаты клиентов (широта/долгота), временные окна, средний и максимальный объём заказа, тип точки (частный дом / офис / склад), наличие грузового лифта, ограничения по подъезду, история возврата тары. Для доставки бутилированной воды добавьте поля: «ожидаемое количество пустых бутылей», «этаж», «нужен ли подъём на этаж», «контактное лицо и телефон». Без этих данных оптимизатор будет строить красивые, но неисполнимые маршруты. Процедура очистки: раз в квартал проводите аудит адресов силами водителей через мобильное приложение.

Геокодирование и нормализация адресов — отдельный проект. Используйте несколько провайдеров: сначала Яндекс.Геокодер или 2GIS, затем уточнение через Nominatim и ручную проверку спорных точек. Для массовой обработки напишите скрипт на Python с библиотекой geopy. После геокодирования рассчитайте «кластеры плотности» — группы точек, которые логично обслуживать одной машиной. В TMS системе эти кластеры становятся базой для зонирования. Практика: если две точки находятся ближе 400 метров и имеют пересекающиеся окна, алгоритм должен предпочитать их посещение подряд.

Справочник транспорта должен содержать: грузоподъёмность по весу и по количеству бутылей, объём кузова, тип кузова (тент / фургон / рефрижератор), среднюю скорость в городе, стоимость километра и часа работы, наличие гидроборта, навыки экипажа. Для воды критичен параметр «максимальное количество бутылей» — он часто жёстче, чем вес. Также укажите «время на обслуживание одной точки» (обычно 8–15 минут для частного клиента и 20–40 минут для офиса с подъёмом). Эти значения используются в dimension времени. Анти-паттерн: ставить одинаковое время обслуживания для всех — это ломает расписание.

Правила бизнес-логики (business rules) вводятся поверх математической модели. Примеры для воды: «не смешивать в одном рейсе заказы с подъёмом на этаж и паллетные поставки», «VIP-клиенты обслуживаются только водителями со стажем >1 года», «после 18:00 запрещены доставки в жилые комплексы с шлагбаумом». В промышленных TMS системах эти правила пишутся на внутреннем DSL или через визуальный конструктор. В OR-Tools они реализуются через дополнительные constraints или через штрафы в целевой функции. Рекомендация: начинайте с 8–10 правил, иначе система станет слишком жёсткой и будет оставлять много нераспределённых заказов.

Построение и утверждение ежедневных маршрутов

Типичный цикл планирования в TMS системе для доставки бутилированной воды: 1) загрузка заказов из CRM/1С до 18:00 предыдущего дня; 2) автоматическая проверка полноты данных; 3) запуск оптимизации на 3–5 минут; 4) визуальный контроль диспетчером (карта + список); 5) ручная корректировка 5–10 % точек; 6) утверждение и отправка маршрутов водителям в мобильное приложение; 7) печать путевых листов и этикеток. Весь цикл должен укладываться в 40–50 минут. Если диспетчер тратит больше часа — процесс требует пересмотра.

Визуальный контроль маршрутов — обязательный этап. Даже лучший алгоритм может предложить решение, которое выглядит странно человеку (например, дважды проезжать одну улицу). Диспетчер проверяет: нет ли пересечений зон, не превышена ли загрузка, соблюдены ли окна VIP, достаточно ли времени на возврат тары. В интерфейсе TMS системы должны быть доступны слои: пробег, загрузка по весу/объёму, временная шкала, карта с цветовой индикацией нарушений. Практика: если после автоматической оптимизации требуется править более 15 % точек — либо данные плохие, либо настройки алгоритма неверны.

Балансировка нагрузки между машинами. Оптимизатор стремится минимизировать общий пробег, но на практике важно равномерно загружать водителей по времени и километражу. Иначе одни заканчивают в 14:00, другие работают до 21:00. В целевой функцию добавляют вторичный критерий — минимизация дисперсии времени работы. В OR-Tools это реализуется через soft upper bound на dimension времени. Для воды дополнительно балансируют количество возвращаемой тары, чтобы ни одна машина не ехала на склад переполненной.

Сценарное планирование. Перед высоким сезоном или при запуске новой акции создавайте несколько сценариев: «базовый», «+20 % заказов», «одна машина в ремонте», «перекрыта ключевая магистраль». TMS система должна позволять быстро клонировать план и пересчитывать. Это даёт руководству понимание, сколько дополнительных машин потребуется и где появятся узкие места. Инструмент: в Route4Me и OptimoRoute есть функция «What-if analysis»; в собственной разработке можно запускать параллельные экземпляры solver-а.

Исполнение маршрутов и мобильное приложение

Мобильное приложение водителя — глаза и руки TMS системы на последней миле. Минимальный функционал: список точек в оптимальном порядке, навигация, отметка о прибытии/убытии, фиксация количества сданных полных и принятых пустых бутылей, фотофиксация (если требуется), кнопка «проблема» с выбором причины, чат с диспетчером. Для воды особенно важна возможность изменить количество тары «на лету» — клиент может отдать больше или меньше пустых бутылей. Приложение должно работать offline и синхронизироваться при появлении сети.

Телематика и контроль исполнения. Интеграция GPS/ГЛОНАСС-трекеров позволяет в реальном времени видеть отклонение от плана. Если машина стоит дольше планового времени обслуживания — система поднимает алерт. Если водитель пропустил точку — диспетчер получает уведомление. Для доставки бутилированной воды полезен контроль температуры в кузове (если есть требования) и контроль открытия дверей. Современные TMS системы строят «цифровой двойник» рейса и автоматически сравнивают план/факт по каждой точке.

Управление исключениями. Типовые ситуации: клиент отсутствует, отказ принять товар, поломка машины, ДТП, перекрытие дороги. В TMS системе должен быть настроен сценарий для каждой ситуации: автоматический перенос заказа на другой рейс, вызов подменной машины, уведомление клиента. Диспетчер видит очередь исключений и принимает решение за 1–2 минуты. Анти-паттерн: решать всё «по телефону» без фиксации в системе — через неделю невозможно понять, почему KPI просели.

Обратная связь от водителя. После каждой точки водитель может оставить комментарий: «плохой подъезд», «нужен пропуск», «клиент просит другое окно». Эти данные накапливаются и используются для улучшения мастер-данных. Раз в месяц аналитик выгружает топ проблемных точек и инициирует их корректировку. Это замкнутый цикл непрерывного улучшения маршрутизации доставки.

KPI, аналитика и непрерывное улучшение

Ключевые показатели эффективности последней мили для воды: Cost per Drop (стоимость одной доставки), On-Time Delivery Rate (процент доставок в окно), Average Drops per Route (среднее число точек на рейс), Empty Kilometers Ratio (доля холостого пробега), Vehicle Utilization (загрузка по весу/объёму), Return Rate of Empties (процент возвращённой тары). Целевые значения: OTD ≥ 95 %, Cost per Drop ≤ 250 руб., Drops per Route ≥ 18, Empty km ≤ 12 %. Все эти метрики должны автоматически считаться в TMS системе и отображаться на дашборде.

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

Бенчмаркинг и внешние сравнения. Сравнивайте свои KPI с отраслевыми. По данным открытых исследований, средний Cost per Drop для бутилированной воды в крупных городах России — 220–320 рублей. Если у вас 400 — есть потенциал оптимизации. Используйте данные Ассоциации компаний интернет-торговли и отраслевые отчёты по last-mile. Внутри компании сравнивайте зоны и водителей между собой — это выявляет лучших практик и проблемные участки.

Цикл PDCA в логистике. Plan — построили маршруты; Do — исполнили; Check — проанализировали KPI; Act — внесли изменения в правила, данные или алгоритм. Этот цикл должен работать еженедельно. Раз в квартал проводите более глубокий review: пересмотр зонирования, обновление матрицы расстояний, тестирование новых параметров solver-а. Документируйте все изменения — иначе через полгода никто не вспомнит, почему система работает именно так.

Интеграция TMS с экосистемой компании

TMS система не работает в вакууме. Основные интеграции: CRM / 1С (заказы и клиенты), WMS (остатки и комплектация), система учёта тары, бухгалтерия (путевые листы и затраты), телематика, мобильное приложение. Для доставки бутилированной воды критична двусторонняя синхронизация с учётом тары: TMS сообщает, сколько пустых ожидает, система тары подтверждает наличие. Используйте REST API или шину данных (Apache Kafka, RabbitMQ). Избегайте файлового обмена через CSV — он ненадёжен и не масштабируется.

Интеграция с WMS. Когда маршрут утверждён, TMS передаёт в WMS список заказов и порядок комплектации. Склад собирает товар в последовательности, удобной для загрузки машин (последняя точка грузится первой). После отгрузки WMS подтверждает фактическое количество, и TMS обновляет данные. Это устраняет расхождения «план/факт» уже на старте рейса. Для воды дополнительно передаётся информация о возвратной таре, которую нужно принять на складе.

Интеграция с CRM и уведомлениями клиентов. За 2 часа до приезда клиент получает SMS или push с точным ETA. Если водитель опаздывает более чем на 20 минут — автоматическое уведомление. После доставки — запрос оценки. Эти данные возвращаются в CRM и влияют на рейтинг точки. Хорошая практика повышает лояльность и снижает количество повторных звонков в контакт-центр на 30–40 %.

API и открытость. При выборе TMS системы обязательно проверяйте наличие полноценного REST/GraphQL API и webhooks. Закрытые системы с «только через поддержку» усложняют развитие. Для собственной разработки на базе OR-Tools сразу проектируйте API-слой (FastAPI или NestJS). Это позволит в будущем подключать внешние каналы заказов, маркетплейсы и партнёрские сети без переписывания ядра.