Как устроена TMS-система и что она автоматизирует в логистике

TMS — это не карта с красивыми линиями

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

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

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

Большая часть логистики происходит до маршрутизации

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

Подтверждение автоматизировали голосовым ботом. Ответ клиента менял состояние заказа, и маршрутизатор уже работал не со всем входящим потоком, а с фактически готовыми к доставке заказами.

На этом же этапе учитывались режимы складов, характеристики транспорта и связанные заказы. Это хороший пример того, почему TMS нельзя проектировать отдельно от клиентского сервиса и операционных правил: один ответ клиента способен изменить весь дальнейший расчёт.

Ограничения важнее алгоритма

Когда говорят про оптимизацию маршрутов, разговор быстро уходит в алгоритмы. Я бы начинал с другого списка: что делает маршрут невозможным.

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

Пока эти правила не представлены в данных, они существуют только как ручная корректировка после расчёта. Тогда оператор получает «оптимальный» маршрут и следующие двадцать минут чинит его руками.

• Какие заказы можно объединять в один рейс.
• Откуда физически может быть отгружен конкретный заказ.
• Какие ограничения есть у транспорта.
• Какие точки или заказы должны идти вместе.
• Что делать с неподтверждённой или изменившейся доставкой.

Геоданные тоже приходится приводить в порядок

Даже когда бизнес-ограничения формализованы, остаётся география. Адрес — ещё не координата, а расстояние по прямой почти никогда не равно реальному пути машины.

В нашем логистическом контуре использовались данные Яндекса и 2GIS для координат и матриц расстояний. Дальше уже можно было считать последовательность точек на нормальной дорожной основе, а не на условной геометрии.

Здесь быстро проявляются обычные инженерные проблемы: внешние API имеют лимиты, часть адресов неоднозначна, данные нужно кэшировать, а повторный расчёт не должен каждый раз заново спрашивать то, что уже известно.

TSP полезен, но только внутри правильной постановки

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

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

Чем сложнее парк и правила, тем быстрее задача уходит в более широкий класс маршрутизации. Но архитектурно принцип остаётся тем же: сначала получить выполнимый набор, потом оптимизировать его, а не пытаться одним алгоритмом исправить грязные входные данные.

Диспетчер не исчезает после появления TMS

Я не люблю обещание «система полностью исключит ручную работу диспетчера». В реальной логистике постоянно появляются вещи, которых не было в данных на момент расчёта: машина задержалась, клиент попросил перенести время, часть груза не готова.

Поэтому в проекте итоговый маршрут можно было проверить и скорректировать вручную. Это не костыль, а нормальная часть системы. Хорошая TMS убирает рутину и даёт диспетчеру понятную базовую версию маршрута, но оставляет человеку контроль там, где ситуация меняется быстрее справочников.

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

Когда готовой TMS достаточно, а когда нужна своя

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

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

В таком случае я бы не начинал с попытки переписать всю логистику. Обычно разумнее выбрать один сквозной сценарий: получить заказы, подготовить их, построить рейс, дать диспетчеру проверить результат и зафиксировать факт.

Что проверить до внедрения TMS

До выбора продукта или начала собственной разработки полезно проверить не список функций TMS, а качество исходного процесса. Если команда не может однозначно определить, какой заказ готов к доставке, откуда он должен ехать и какие ограничения обязательны, новая система сначала унаследует эту неопределённость.

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

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

• Есть ли единый источник заказов и их статусов готовности.
• Формализованы ли режимы складов и ограничения транспорта.
• Можно ли однозначно превратить адрес в координаты и дорожное расстояние.
• Известно ли, какие ручные изменения диспетчер делает после расчёта и почему.
• Можно ли проверить факт исполнения рейса теми же идентификаторами, что использовались при планировании.

В каком порядке я бы автоматизировал логистику

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

После запуска полезно собирать причины ручных изменений. Именно они обычно показывают, какие бизнес-правила система ещё не знает. Так TMS развивается не набором случайных функций, а вокруг фактических отклонений процесса.

• Собрать единый поток заказов и справочников.
• Зафиксировать состояния и правила готовности заказа к доставке.
• Формализовать ограничения склада, транспорта и связанных заказов.
• Нормализовать геоданные и матрицы расстояний.
• Добавить расчёт маршрута.
• Сохранить ручную проверку и анализировать причины корректировок.

Вопросы

Продолжить по теме

• Разработка TMS и автоматизация логистики
• Система автоматизации клиентского сервиса и логистики

Другие статьи

• Автоматизация бизнес-процессов: когда нужна своя система
• Как устроена BI-система: от источников до дашборда
• Прогнозирование спроса: почему модель в ноутбуке ещё не продукт