Разработка TMS для рейсов: статусы, план-факт, документы

Какие задачи должна закрывать TMS для рейсов

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

Первая базовая задача - единая система статусов рейса. Без нее невозможно быстро ответить на простые вопросы: где груз, кто отвечает за задержку, когда ждать прибытие. Важно, чтобы статусы были не «для красоты», а привязаны к событиям и ответственности: кто переводит статус, при каких условиях, какие поля обязательны.

Вторая задача - план-факт и прозрачные отклонения. План часто живет в заявке, а факт - в звонках и бумагах. Затем появляются споры: «мы же приехали вовремя», «но на воротах стояли 3 часа». TMS должна хранить и плановые, и фактические времена по ключевым точкам (подача ТС, начало и конец погрузки, выезд, прибытие, выгрузка) и считать отклонения по понятным правилам.

Третья задача - работа с несколькими перевозчиками без хаоса. Когда у каждого перевозчика свои форматы, водители, телефоны и названия, ломаются справочники и отчетность. Нужны единые карточки контрагентов, ТС и водителей, правила доступа и история изменений, чтобы было видно, кто и почему поменял данные.

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

В минимальном варианте TMS для рейсов закрывает:

• единый журнал рейсов со статусом, ответственным и последним событием;
• план-факт по контрольным точкам и причины отклонений;
• распределение рейса по перевозчикам (основной, субподряд) и роли пользователей;
• реестр документов (ТТН/CMR, акт, счет) со статусами проверки;
• блокировки: нельзя «закрыть рейс» или отправить на оплату без обязательных подтверждений.

Пример: рейс поставили «прибыл», но фактически водитель еще ждет на КПП. Если факт берется только из звонка, в отчете будет «вовремя», а склад и клиент получат неверный ETA. Если TMS требует событие «проход КПП» с временем и подтверждением, расхождение видно сразу, и спор превращается в данные, а не в переписку.

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

Минимальная модель данных: что хранить с первого дня

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

Базовые сущности

В MVP не пытайтесь описать весь мир логистики. Хватит набора объектов, которые не конфликтуют между собой и легко расширяются:

• Рейс (trip): номер, даты, текущий статус, ответственный.
• Заказ (order): клиент, условия, связь с рейсом (1 рейс - много заказов).
• Остановка (stop): адрес, окно времени, тип (погрузка/разгрузка), порядок.
• Груз (cargo): места/вес/объем, опасность, температура, привязка к заказу.
• ТС, водитель, перевозчик: идентификаторы, контакты, документы допуска.

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

События и документы как отдельные объекты

Факт почти всегда приходит кусками: звонок водителя, GPS, отметка на КПП, интеграция с подрядчиком. Поэтому события рейса лучше хранить отдельно от статуса. Событие - это запись с временем, местом и источником (например, диспетчер, мобильное приложение, телематика). Тогда статус можно пересчитывать или подтверждать, не теряя историю.

Документы тоже храните как объекты, а не как «файл в поле рейса». Минимально нужны: тип (ТТН/CMR/акт), номер, даты, связанные рейс/заказ/остановка, файлы (оригинал/скан) и статус проверки (ожидает, принят, отклонен) с причиной.

Чтобы всем было удобно работать, заложите роли и права на уровне данных. Например, диспетчер создает рейсы, правит остановки и фиксирует события. Бухгалтерия проверяет документы и закрывает рейсы к оплате. Служба безопасности видит водителя/ТС и допуски, блокирует несоответствия. Клиент смотрит статусы и подтверждающие документы без прав на редактирование.

Пример: водитель загрузился в 10:05, диспетчер занес событие «погрузка завершена», а бухгалтерия позже принимает скан ТТН. Рейс не уходит в оплату, пока у документа статус не «принят».

Статусы рейса: как сделать простую и надежную схему

Статусы в TMS ломаются не из-за редких кейсов, а из-за путаницы уровней. Первое правило: статус рейса и статус заказа (или отгрузки) - разные сущности. Рейс описывает движение транспорта и факт выполнения маршрута. Заказ описывает обязательства перед клиентом: что именно, куда и в каком объеме должно приехать.

Если смешать уровни, появляется хаос: один заказ может быть частично доставлен, а рейс при этом еще в пути. Или наоборот, рейс завершен, но часть позиций по заказу списали как недопоставку. Поэтому в карточке рейса держите только то, что относится к рейсу, а состояние заказа считайте отдельно (на основе факта по точкам, сканов документов и исключений).

Хорошая схема статусов должна быть однозначной: одно действие - один статус. Не делайте статусы вида «В пути/ожидает» или «Почти доставлено». Пользователь должен понимать, какое событие уже произошло, а какое еще нет.

Обычно хватает короткой цепочки, которая отражает реальные этапы жизни рейса:

• Запланирован
• Назначен перевозчик
• Выехал
• Прибыл в точку
• Завершен

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

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

• кто изменил статус (пользователь или интеграция);
• когда изменил (точное время);
• откуда пришел факт (ручной ввод, GPS, EDI, скан документа);
• причину, если это не стандартный переход (например, «перенос по погоде»).

Пример: рейс с двумя точками (склад и магазин). Диспетчер создал рейс и назначил перевозчика - статус «Назначен перевозчик». Водитель отметил старт в мобильном приложении - «Выехал» с источником «мобильное приложение». На магазине приемщик загрузил скан ТТН - рейс получает «Завершен», а заказ внутри рейса может стать «Доставлен» или «Частично доставлен» в зависимости от фактических позиций. Так вы не спорите о словах: видно действие, источник и время.

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

План-факт: как считать отклонения и не спорить о цифрах

План-факт в TMS часто становится причиной споров не из-за «плохих водителей», а из-за разных правил подсчета. Поэтому заранее зафиксируйте, что считается планом, что считается фактом и какие события влияют на KPI.

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

Факт складывается из событий. Важно отделять «прибыл» от «начал работу» и «выехал», иначе вы смешаете опоздание и простой. На практике помогает короткий набор фактов, которые можно получать из GPS, мобильного приложения или вручную: прибытие на точку, начало работ, окончание работ, выезд с точки и причина ожидания (если есть).

Отдельная проблема - повторные заезды. Для одной точки маршрута разрешите несколько наборов фактов (например, «заезд 1», «заезд 2»), но задайте правило выбора «основного» набора для KPI. Частый вариант: основной - тот, который привел к закрытию точки, а остальные помечаются как дополнительные и не влияют на штрафы, если есть подтвержденная причина.

Чтобы не спорить о цифрах, KPI должны считаться по понятным формулам и показывать расшифровку. Например: «опоздание» = max(0, время прибытия - конец окна), «простой» = max(0, (начало работ - прибытие) - допустимое ожидание), «выполнение в срок» = да, если прибытие попало в окно.

Пример: по плану склад принимает с 10:00 до 12:00, норма ожидания 20 минут. Машина приехала в 11:50, работы начали в 12:40. В отчете должно быть видно: опоздание 0 минут (в окне), простой 30 минут (50 минут ожидания минус 20 допустимых). Когда пользователь видит разложение на события, споров становится меньше.

И еще одно: факты должны иметь источник и историю изменений (кто и когда поправил), иначе любые KPI будут восприниматься как «нарисованные».

Несколько перевозчиков: правила, права и единые справочники

Когда в рейсах участвуют разные перевозчики, споры обычно начинаются не с цены, а с данных: у одного «тент 13.6», у другого «еврофура», регионы названы по-разному, водитель записан как «Сергей» без документов. Поэтому при разработке TMS для рейсов важно заранее договориться о едином языке и о правилах, кто и что может менять.

Единая карточка перевозчика

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

Обычно в карточке нужны: договор и статус (активен, на паузе, заблокирован), ставки и условия (по маршрутам, типу ТС, допуслугам), ограничения (регионы, типы грузов, температурный режим, допуски), контакты и роли (диспетчер, бухгалтерия, руководитель), требования к документам и срокам предоставления.

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

Единые справочники и сопоставление

Если вы даете перевозчикам доступ в систему, не заставляйте их каждый раз «переводить» свои данные под ваши названия. Лучше заведите внутренние справочники (типы кузова, регионы, единицы измерения, статусы ТС и водителей) и таблицу сопоставления: «как у нас» и «как у перевозчика». Тогда отчеты и план-факт будут считаться одинаково, даже если партнер присылает свои коды.

Права доступа здесь критичны: перевозчик может добавлять ТС и водителей, но не должен менять справочники, ставки и правила приемки. Практичный вариант: все новые ТС, водители и реквизиты попадают в статус «на проверке», а после подтверждения становятся доступными для назначений.

Контроль качества без ручной охоты

Качество перевозчиков лучше вести не в заметках, а в показателях, которые система считает сама. Достаточно базового набора: пунктуальность (опоздания на загрузку и выгрузку), инциденты (повреждения, недостачи, штрафы), возврат подтверждающих документов в срок, отмены и срывы назначенных рейсов, доля рейсов без замечаний.

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

Подтверждающие документы: сбор, проверка, блокировки

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

Какие документы требовать и когда

Набор зависит от типа перевозки, но логика по этапам почти всегда одинакова. До выезда обычно нужны договорные и разрешительные вещи (заявка, маршрут, доверенность, данные ТС и водителя). В пути важны подтверждения событий (например, отметки о погрузке, акты простоя, фото пломб). После доставки нужны закрывающие документы: подтверждение получения, акт выполненных работ, товаросопроводительные документы с отметками.

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

Статусы и проверка

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

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

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

Пример: перевозчик загрузил фото накладной после доставки, но номер рейса в штампе не совпал. TMS ставит «Отклонен», просит перезагрузить, а рейс не дает закрыть, пока документ не будет «Принят».

Блокировки: связь с оплатой и закрытием рейса

Главное правило простое: деньги и закрытие рейса зависят от статусов документов. Заранее задайте, что именно блокирует:

• выставление счета (нет принятого подтверждения доставки);
• начисление допуслуг (нет акта простоя);
• закрытие рейса (не принят ключевой комплект).

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

Интеграции и события: откуда берется факт и кому он нужен

Факт в рейсе почти никогда не появляется в одной системе. Важно заранее договориться, какие источники считаются доверенными, как они приводятся к единому формату и кто подтверждает спорные моменты. Если это не сделать в начале, план-факт будет постоянно «плыть», а разборы займут больше времени, чем сама перевозка.

Откуда берется факт

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

• GPS/телематика: координаты, скорость, геозоны (прибытие/убытие по факту пересечения зоны).
• Ручные события: диспетчер или водитель отмечает «прибыл», «загрузка завершена» с комментарием.
• Подтверждение от перевозчика: статус и время от партнера в личном кабинете или через файл/сообщение.
• События склада/производства: «готово к отгрузке», «принято на рампу», если эти системы есть.
• Скан документов: время создания/загрузки подтверждения как косвенный факт.

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

Документы, уведомления и аудит

Обмен документами лучше строить так, чтобы перевозчику было удобно: загрузка файлов в карточку рейса, прием вложений через e-mail шлюз, и EDI - только если объем и требования оправдывают сложность. Важнее не канал, а контроль: обязательные типы документов, читаемость, соответствие дат и номеров, понятные блокировки (например, нельзя закрыть рейс без подтверждения доставки).

Уведомления должны получать конкретные роли, а не «всем подряд». Обычно сигналят только отклонения: опоздание к окну погрузки/разгрузки, отклонение от маршрута или простой выше нормы, отсутствие обязательного документа к дедлайну, расхождение веса/мест или адреса в документе, попытка закрыть рейс при незаполненных полях.

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

Пошаговый план разработки: от MVP до тиражирования

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

Как не расползтись по требованиям

Начните с набора реальных кейсов. Возьмите 10-15 типовых рейсов и столько же «неудобных» ситуаций: перенос погрузки, частичная отгрузка, замена машины, опоздание, отказ получателя, доп. точка. Эти истории станут тестом для модели статусов, план-факта и документов.

Дальше двигайтесь шагами, но с четкими критериями готовности:

• Зафиксировать сценарии и исключения так, чтобы их можно было разыграть по шагам (кто, когда, какой факт появляется и где подтверждается).
• Утвердить статусную модель рейса и правила переходов, включая «кто имеет право» и что делать с откатами и исправлениями.
• Описать план-факт: какие времена и километры считаем планом, что считаем фактом, и какие 3-5 отчетов реально смотрят логисты и бухгалтерия.
• Запустить MVP на одном направлении и одном перевозчике, где понятные правила и есть мотивация работать в системе.
• Подключить подтверждающие документы: что обязательно, что опционально, как проверяем (визуально или по данным) и в каких случаях оплата блокируется.

Простой пример для MVP: направление Алматы - Астана и один перевозчик. Достаточно статусов «запланирован», «назначен», «в пути», «доставлен», «закрыт», плюс один «проблема». План-факт считать по двум точкам (погрузка и доставка), а документами закрывать только базовый набор: накладная и акт.

Когда пора тиражировать

Тиражирование начинайте, когда в MVP нет ручных обходов: статус меняется по правилам, план-факт сходится в отчетах, документы действительно загружаются, а блокировка оплаты работает без «договорились в чате». После этого подключайте остальных перевозчиков и филиалы: вводите единые справочники (типы ТС, документы, причины отклонений), роли и минимальные SLA по подтверждениям, чтобы разные команды не считали «факт» по-разному.

Типичные ошибки при разработке TMS и как их избежать

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

1) Слишком много статусов и ручных вариантов

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

Держите схему короткой и однозначной. Хорошее правило: каждый статус отвечает на один вопрос и имеет понятные условия входа и выхода. Если хочется добавить новый статус, сначала проверьте, не решается ли задача отдельным признаком (например, «ожидается документ», «есть спор по сумме») без поломки всей цепочки.

2) Нет источника факта и доверия к данным

Если непонятно, откуда берется «факт прибытия» или «факт выгрузки», спорить будут бесконечно: водитель говорит одно, склад другое, бухгалтерия третье. И каждый прав по-своему.

Заранее определите, что является первичным источником для каждого факта: событие от перевозчика, отметка сотрудника на точке, интеграция с системой склада, GPS, скан документа. И фиксируйте в карточке рейса не только значение, но и «кто/что его поставило» и «когда». Это снижает конфликты и упрощает разбор инцидентов.

3) Документы хранятся как файлы без структуры

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

Сделайте документ сущностью, а не вложением: тип (ТТН/CMR/акт/счет), номер, дата, сторона, статус проверки, кто проверил, комментарий, связанный рейс и этап. Файл остается, но контроль строится вокруг данных.

4) Не разделены права и роли

Частая проблема при работе с несколькими перевозчиками: перевозчик может исправлять то, что должен только подтверждать. Например, менять плановые даты, километраж или стоимость, а потом «все само поменялось».

Разведите права по принципу: кто создает, кто предлагает изменения, кто утверждает. Введите простую механику согласования: «запрос на изменение» вместо прямого редактирования. И обязательно сохраняйте историю: что изменили, кем и по какой причине.

5) Нет аналитики по отклонениям

Без план-факт аналитики TMS быстро превращается в архив: рейсы закрыты, документы прикреплены, но понять, где система теряет деньги и время, нельзя.

Заложите минимум метрик с самого начала:

• отклонение по времени (прибытие/выгрузка/закрытие рейса);
• отклонение по стоимости (договор vs факт);
• отклонение по расстоянию или маршруту (если применимо);
• доля рейсов без полного комплекта документов;
• причины отклонений (короткий справочник).

Если в разработке TMS для рейсов заранее закрыть эти пять зон, система будет не «табличкой для учета», а инструментом, которому доверяют диспетчеры, перевозчики и финансовый блок.

Быстрый чеклист перед стартом и следующие шаги

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

Чеклист, который стоит пройти за 30 минут

Ответьте на вопросы ниже и зафиксируйте решения письменно. Это сэкономит недели на спорных кейсах и переделках.

• Разделены ли статусы рейса, заказа и документа? Если все живет в одном статусе, потом трудно понять, что именно «застряло».
• Определены ли обязательные события для закрытия рейса (например: выезд, прибытие, начало разгрузки, завершение) и кто их подтверждает?
• Есть ли единые правила план-факт: какие поля считаются планом, откуда берется факт, одна формула опоздания (с учетом таймзон и округления времени)?
• Настроены ли блокировки оплаты или закрытия, если нет подтверждений (сканы, ЭДО, подписи, отметки), и кто может снять блокировку с понятной причиной?
• Согласованы ли два примера отчета: один для диспетчера (оперативный контроль), второй для бухгалтерии (закрытие и оплата)? Если примеров нет, требования будут «плавать».

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

Следующие шаги после чеклиста

Когда правила готовы, переходите к практическим шагам. Делайте так, чтобы каждый шаг давал измеримый результат.

• Соберите 10-20 реальных рейсов из разных сценариев: один перевозчик и несколько, частичная доставка, возврат документов, задержки. На них и проверяйте статусы, план-факт и закрытие.
• Определите источники факта: вручную (диспетчер), от перевозчика, из GPS, из склада, из ЭДО. Для каждого источника назначьте «владельца данных».
• Решите вопрос с инфраструктурой: где будет работать TMS (офис, филиалы), сколько пользователей, нужна ли отказоустойчивость, какой объем документов хранить. От этого зависит выбор серверов и рабочих мест.
• Запланируйте поддержку: кто отвечает ночью и в выходные, кто чинит интеграции, кто обновляет справочники.

Если нужна помощь с подбором и развертыванием инфраструктуры под вашу нагрузку, можно привлечь интегратора. Например, GSE.kz (gse.kz) как системный интегратор может помочь с серверной частью и рабочими местами, а также с организацией поддержки, чтобы TMS не останавливалась в пиковые дни закрытия рейсов.