Автоматизация грузоперевозок: заявки, рейсы, документы

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

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

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

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

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

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

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

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

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

Третий разрыв — документы, и он самый дорогой. Рейс выполнен, деньги заработаны, а оплата не придёт, пока заказчик не получит комплект: транспортную накладную, акт, счёт. Оригинал едет в кабине, потом лежит в папке, потом отправляется почтой, потом теряется, и перевозчик узнаёт об этом из вопроса «а где документы?» через три недели. Доходит и до прямых потерь: без накладной перевозку сложно подтвердить в споре. Поэтому возврат оригиналов должен быть не привычкой, а задачей в системе с ответственным и сроком, а комплект по каждому рейсу — видимым списком, в котором отмечено, чего не хватает. С привлечённым транспортом это особенно больно: подрядчик уже получил деньги, а документы вам ещё не отдал.

Про вопрос «где мой груз» стоит сказать отдельно. Самый частый звонок в диспетчерскую — не о цене и не о претензии, а о статусе. Его закрывают двумя способами: автоматическим уведомлением на каждом ключевом статусе и личным кабинетом, где заказчик сам видит свои перевозки. Механику такого кабинета — роли, доступ только к своим документам, актуальные данные из учётной системы без ручной выгрузки — мы подробно разбирали в статье журнала про B2B-кабинет для оптовой компании: отрасль другая, а устройство то же.

Автоматизируется всё, что сегодня держится на памяти диспетчера и на его готовности помнить о десяти рейсах одновременно. Расчёт по шаблону, статусы заказчику, задачи водителю, напоминания о документах и о сроке оплаты. Основной контур мы чаще всего собираем в CRM — в Битрикс24 это воронка заявок плюс рейс как отдельный объект учёта со своими стадиями.

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

Готовиться стоит в любом случае, даже если конкретно вас переход пока не затронул. Электронные перевозочные документы — это та же транспортная накладная, путевой лист, заказ-наряд, только в юридически значимом электронном виде: подписанные электронной подписью и переданные через оператора электронного документооборота в государственную информационную систему электронных перевозочных документов (ГИС ЭПД). Смысл перехода простой: документ перестаёт быть бумагой, которая едет в кабине.

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

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

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

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

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

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

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

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

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

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

Порядок работ мы рекомендуем такой. Сначала единый приём заявок и воронка со стадиями расчёта и подтверждения — это быстрый результат и не требует трогать рейсы. Затем карточка рейса со статусами, назначением машины или подрядчика и фактическими датами. Затем документы: комплект по рейсу, контроль возврата оригиналов, напоминания по оплате. Затем статусы и личный кабинет для заказчика. Интеграции — обмен с учётной системой, оператором ЭДО, телематикой — последними, когда понятно, какие данные и в какую сторону передавать.

Обратный порядок — начать с интеграций — мы не советуем. Это самая трудоёмкая часть работ, и без выстроенных процессов она даёт обмен данными между двумя беспорядками. Типовой контур заявок, рейсов и документов мы собираем на CRM, а то, чего в CRM нет по природе — кабинет заказчика со статусом груза, расчёт по сложным тарифным сеткам, специфический обмен с учётной системой, — закрываем заказной разработкой поверх того же контура: один подрядчик и один договор вместо трёх.

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