TMS система на заказ: рейс виден, водитель не пропадает

TMS система на заказ это контур рейса целиком: задание из заказа, слот и окно, водитель, факт доставки и возврат в одном экране, а не в звонках. Headline, IT-компания headln.ru, наращивает TMS поверх мониторинга доставки: Telegram-бот закрывает статус, TMS планирует машины, склады и окна.

На сайте уже есть слой мониторинга доставки: Telegram-бот, уведомления клиенту, Node.js, Redis. TMS: следующий слой, когда появляются машины, склады, окна и возвраты, а не только кнопка «доставил». Код, деплой, On-Premise, сопровождение.

Кому своя TMS оправдана

Службе с собственным парком или постоянными подрядчиками. Опту, у которого отгрузка и доставка уже один день. Селлеру с прямым каналом, которому площадка больше не прячет последнюю милю за комиссией 30–48%. Не компании без рейсов: программа не создаст логистику из слайда.

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

Склад без адреса ячейки TMS не вылечит. Машина уедет не с тем. Сначала или рядом: WMS для склада. Учёт и маркировка: сопровождение 1С. В Петро-Проекте боль была в доступности учёта и ЕГАИС, не в «красивом TMS». Слои разные.

• Рейсы есть каждый день, диспетчер тонет в чатах и звонках.
• Склад, водитель и клиент видят разные окна.
• Возвраты и опоздания разбирают по памяти.
• Маршруты и телефоны нельзя отдать чужому облачному трекеру.

Когда коробка, когда бот, когда TMS на заказ

Коробка TMS уместна типовому перевозчику, который готов жить в чужих справочниках и лицензиях. Свою TMS заказывают, когда окно, сборка рейса и стык со складом свои, а обходы уже ежедневные. Headline не пишет код ради кода. Если готовое дешевле по итогу, его внедряют. База: разработка ПО на заказ.

Бот как первый срез: честный путь. Курьер и так в Telegram. Кнопки статуса быстрее лички. Затем рейсы, слоты, несколько точек отгрузки. Не стыдно вырасти из мониторинга. Стыдно сразу обещать «как у магистрального перевозчика» без парка и без хозяина рейса.

Узкий пилот: один тип рейса, один склад, одно окно. Формат: MVP за 14 дней. Биржа водителей, оптимизация города и ИИ-маршруты в этот срок не входят.

Для селлера TMS часто всплывает вместе со своим магазином. Сначала заказ на вашем домене, затем рейс. Сценарий: интернет-магазин для селлеров и ecommerce. Иначе вы построите логистику для пустой витрины.

Как Headline делает TMS систему на заказ

Сначала карта рейса. Где заказ становится заданием, кто комплектует, кто назначает машину, какие статусы видит клиент, что считается опозданием, где возврат, где акт расхождения. Без этого TMS станет ещё одной таблицей.

Затем роли. Диспетчер, склад, водитель, клиент, руководитель. Не одна учётка «логистика». Водительский контур может остаться ботом, если хватает кнопок. Отдельное приложение: когда нужны камера, подпись, офлайн. Тема: мобильное приложение на заказ.

Деплой On-Premise, мониторинг 24/7, сопровождение. Можно принести чужую TMS. Не останавливаем рейсы ради красивого переписывания. Тема: сопровождение после запуска.

Что обычно входит в первую очередь

1. Задание на рейс из заказа, один номер, не два учёта.
2. Слот и окно, которые видят склад и клиент одинаково.
3. Назначение водителя или подрядчика, статус в одном месте.
4. Факт: выехал, на адресе, доставил, проблема, возврат.
5. Простая аналитика смены: опоздания, закрытые адреса, пустые пробеги, если вы их уже считаете руками.
6. Сервер, журнал, копии. Разбор спора не должен идти по памяти.

Документы B2B-отгрузки TMS не обязана верстать. КонтрактПРО: пакет 5–15 минут вместо 1–2 часов. Периметр телефонов и адресов: On-Premise и 152-ФЗ.

Риски «сделаем как у агрегатора»

Риск скопировать чужие статусы и штрафы. У агрегатора своя сетка. У вас: своё окно и свой клиент. Нужны ваши эскалации, не чужой скриншот.

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

Риск оставить чат как основной канал. Если водителю быстрее написать «ок», TMS умрёт. Кнопка должна быть быстрее лички. Диспетчер не принимает статус из двух мест.

Риск большого скоупа. Оптимизация, биржа, ИИ-прогноз пробок, своя мобильная витрина в первой версии. Контур не взлетает. Сначала рейс и окно. ИИ: когда журнал рейсов живой. Тема: внедрение ИИ.

Риск склада в конце. Планируют рейсы по вранью остатка. Сначала правда на рампе, затем красивый маршрут. Производству рядом часто нужен заказ и ячейка, не TMS: автоматизация производства.

• Нет хозяина рейса: статусы плодит каждый как хочет.
• Нет критерия опоздания: аналитика будет спором.
• Нет связи с 1С или магазином: два номера одного заказа.
• Нет мониторинга сервера: пик убивает статусы.

Как встроить TMS в уже живые рейсы

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

Клиенту не обещают «как у маркетплейса», если окна другие. Обещают тот статус, который контур умеет. Ложное «водитель рядом» разрушает доверие быстрее честной задержки.

Стык со складом рисуют сразу. Собранный заказ становится грузом рейса один раз. Два списка: снова звонки. Если ячейка врёт, чинят WMS, не рисуют карту.

Инфраструктура: бот, кабинет диспетчера и база рейсов не живут на ноутбуке. Копии, VPN, мониторинг. Статья: обслуживание серверов. Для Петербурга часто один подрядчик: IT-компания в Санкт-Петербурге.

Замена западной TMS без остановки рейсов: параллельный контур на одном типе поездок, затем перевод. Тема: импортозамещение ПО. Цель: заменить контур, не оставить город без машин на неделю.

Если водитель уже пропадает в чате, в письме достаточно: сколько рейсов в день, сколько складов, чем сейчас ловите статус, и что должен видеть клиент.

Как считать рейс, чтобы аналитика не стала спором

Договоритесь, что считается опозданием, до кода. Окно клиента, окно склада, факт «на адресе». Если три часовых пояса правды, TMS будет рисовать красивую ложь. Критерий пишут на бумаге и дают диспетчеру, не разработчику «на усмотрение».

Считают после пилота простые числа. Доля рейсов без звонка водителю. Доля окон, которые склад и клиент видели одинаково. Число возвратов с причиной, а не с «ну не взяли». Без чисел вы будете спорить, удобна ли карта.

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

Для селлера рейс имеет смысл, когда прямой заказ уже идёт. Комиссия площадок 30–48% не вернётся от красивого TMS на пустой витрине. Сначала канал, затем машина. Страница: headln.ru/ecommerce.

Частые вопросы

01

Чем TMS система на заказ отличается от мониторинга доставки?

Мониторинг закрывает статус и уведомление. TMS планирует рейс, слот, машину, склад, возврат. Часто начинают с Telegram-бота, затем растят TMS, если таблица рейсов уже не выдерживает.

02

Что уже есть на сайте по логистике?

Мониторинг доставки: Telegram API, Node.js, Redis, уведомления клиенту, аналитика. Отдельного имени перевозчика и тарифов мы не выдумываем.

03

Можно начать с бота, не со всей TMS?

Да. Это честный первый срез. Полный контур слотов и нескольких складов в 14 дней не входит. Один тип рейса: входит.

04

Данные адресов и телефонов останутся у нас?

Да. On-Premise: базовый вариант. Облачный трекер: только если вы так решаете и понимаете выход.

05

TMS заменит склад и 1С?

Нет. Склад даёт факт комплектации. 1С даёт учёт. TMS возит то, что уже собрано и проведено. Границы проектируют сразу.

06

Возьмёте чужую TMS?

Да. Аудит, узкие места, плавный переход. Рейсы не останавливаем ради красивого переписывания.

07

Как поставить задачу?

Число рейсов, число складов, где сейчас таблица, что видит клиент. Письмо: welcome@headln.ru.

Если рейс уже в пути, а статус собирают звонками, напишите на welcome@headln.ru: сколько рейсов, сколько точек отгрузки и что должен видеть клиент сам.