Автоматизация транспортной компании: с какого процесса начать

Теоретический пример. Владелец экспедиторской компании с 12 логистами хочет «автоматизировать всё». Разбор одной недели показывает три главные потери времени: заявки из почты перепечатывают в 1С, документы от перевозчиков собирают звонками, клиенты по 30 раз в день спрашивают статус. Это три разных продукта. Если объединить их в обещание «вся логистика в одной программе», первый результат будет трудно проверить.

Сначала определите, какой бизнес автоматизируете

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

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

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

Разделите заявку, выполнение и расчёты

Предлагаемая модель состоит из клиентского заказа, конкретных этапов перевозки и финансово‑документального закрытия. Прямая перевозка может укладываться в один этап. При перегрузке или нескольких исполнителях этапов потребуется больше. Не обязательно реализовывать все варианты сразу, но нельзя терять связь между ними.

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

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

Выберите первую задачу по наблюдениям

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

Хорошие кандидаты для небольшой первой версии:

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

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

Матрица помогает отделить частую задачу с готовыми исходниками от привлекательной идеи, к которой пока нечего подключать. Положение каждого процесса определяет команда по своим наблюдениям. Разбор типовых заявок может стать первым продуктом, если письма доступны и результат проверяет логист. Частый сбор документов при неизвестных источниках сначала требует договорённости о данных. Редкий нестандартный расчёт может оставаться ручным, даже если исходники есть. Распределение учебное. Для своей матрицы возьмите конкретные обращения за рабочий период, отметьте повторяемость, доступ к источникам и владельца результата. ИИ добавляется там, где нужно читать свободный текст; статусы и назначение выполняются по правилам.

Пример границ пилота

Условный пример: экспедитор получает запросы постоянных клиентов по почте. Первая версия собирает их в очередь, хранит оригинал сообщения, показывает обязательные поля и напоминает о неподтверждённом сроке ответа. Логист проверяет карточку и вручную подтверждает готовность работать с запросом.

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

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

Надстройка над действующей системой

Если компания уже работает в TMS, начните с её настройки. Например, «1С:Транспортная логистика, экспедирование и управление автотранспортом КОРП» предусматривает управление заказами, рейсами и взаиморасчётами. Это возможности конкретного продукта, в другой установленной «1С» их может не быть.

Практичная связка пилота: почта → ИИ‑черновик и проверка логистом → подтверждённая карточка в действующем учёте. Если доступа для записи пока нет, начните с проверенной выгрузки или ручной передачи. Поддержку обмена в вашей конфигурации проверяют до обещания интеграции. Надстройка оправдана пробелом на входе; она не должна повторять функции TMS, которыми компания уже пользуется.

Опишите исключения до разработки

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

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

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

Доступы и передача данных

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

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

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

Где нейросеть поможет в первом продукте

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

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

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

Когда разработка пока не нужна

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

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

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

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

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

Когда машин не хватает

В конце августа 2026 года индекс ставок ATI.SU обновил рекорд: 2 281 пункт, плюс 33% с начала года и 7,4% за последнюю неделю. Индикатор баланса грузов и машин ATI.SU показал +73, близко к годовому максимуму: машин не хватает. Для экспедитора это значит, что поиск машины занимает больше времени, а ставка перевозчика меняется за несколько дней.

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

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

Что подготовить к обсуждению

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

Источники

• ATI.SU: API для работы с заказами, действующая документация, проверена 18.10.2026.
• CARGO.RUN: инструкция по работе платформы, описание сборных заявок; проверено 18.10.2026.

• 1С: возможности отраслевого транспортного решения, проверено 18.10.2026.
• ATI.SU: ставки на грузоперевозки обновили рекорд, 31.08.2026; проверено 19.10.2026.

Смежные разборы: Учёт заявок на перевозку: почта, сообщения и таблицы в одном месте; Бюджет международной перевозки: прогноз расходов и маржи в пути.