7 ошибок автоматизации перевозок и во что они обходятся

Проекты автоматизации в перевозках проваливаются не из-за плохого софта. Они проваливаются в семи одинаковых местах, и все семь видны уже на втором месяце — если знать, куда смотреть. Ниже каждая ошибка разобрана как измеримая потеря: механизм, признак и цена в рублях для модельного перевозчика на 40 машин, 560 заявок в месяц и двух диспетчеров.

Вводные модели — те же, что в остальных материалах раздела: полная стоимость часа диспетчера 650 ₽, час простоя машины 1 150 ₽, переменная часть себестоимости километра 26,29 ₽, средний пробег 9 000 км в месяц на машину, топливо 62 ₽ за литр, стоимость денег 24 % годовых. Все цифры модельные, но арифметика прозрачная: их можно пересчитать на своих числах за полчаса.

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

Ошибка 1. Начали с маршрутизации, а не с заявок

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

Признак на втором месяце: контур маршрутизации работает, диспетчеры его не открывают. Планы строятся, а рейсы всё равно распределяются вручную, потому что в системе половины заявок нет. Цена — не расходы, а неполученный эффект: 5 заявок в месяц теряются между каналами и ещё 8 рейсов уходят к конкуренту из-за медленного ответа, по 12 000 ₽ маржи каждый. Это 156 000 ₽ в месяц, к которым добавляется 9 600 ₽ стоимости 480 000 ₽, замороженных в неработающем контуре при ставке 24 % годовых.

Правильный порядок — реестр заявок, потом документы рейса, и только потом маршруты. Мы подробно разбирали состав реестра и то, что машина умеет вытащить из письма, в материале про автоматизацию транспортной компании. Ориентир для перехода к маршрутизации простой: 90 % заявок попадают в систему структурированными и существует справочник адресов.

Ошибка 2. Водитель как оператор ввода

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

Устойчивая величина из практики — 4–6 отметок за рейс, если каждая укладывается в два касания и приходит вопросом от системы, а не требует открыть приложение самому. Всё, что сверх этого, не заполняется. Дальше включается компенсаторный механизм: диспетчер начинает звонить и спрашивать голосом то, чего нет в системе.

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

Ошибка 3. Справочник адресов ведёт кто попало

Один и тот же склад существует в системе как «Химки, Ленинградское ш. 16», «ТК Химки склад 3» и «Химки (новый адрес!)». Каждый диспетчер заводит свой вариант, потому что так быстрее, чем искать чужой. Через полгода в справочнике полторы тысячи точек, из которых реальных — четыреста.

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

Ошибка 4. Телематика поставлена ради ловли сливов

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

Между тем отчёт по сливам — один из трёх, и не самый денежный. Два других — перерасход относительно нормы с учётом условий рейса и стиль вождения — дают экономию тихо и постоянно. Топливный счёт модельного парка: 40 машин по 9 000 км при норме 34 л на 100 км — это 122 400 литров и 7 588 800 ₽ в месяц при цене 62 ₽ за литр. Один процент от этой суммы — 75 888 ₽ ежемесячно, и это ровно то, что лежит непросмотренным.

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

Ошибка 5. Мессенджер как система учёта

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

Ежедневная цена ошибки видна раньше. Два диспетчера тратят примерно по 40 минут в день на поиск в переписке: где мы договорились про эту ставку, кто согласовал простой, куда прислали скан. Это 29,3 часа в месяц и 19 067 ₽. К этому добавляется амортизированная цена смены диспетчера: два ухода в год, каждый обходится примерно в 120 000 ₽ повторных согласований и потерянных договорённостей, то есть ещё 20 000 ₽ в месяц. Вместе — 39 067 ₽.

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

Ошибка 6. Интеграция с биржей без правил по марже

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

Модель: 18 % заявок приходят с бирж — это 101 рейс в месяц, из них 22 берутся с маржой ниже целевой, недобор в среднем 3 400 ₽ на рейс. Итого 74 800 ₽ в месяц, и характерно, что в отчётности эти рейсы выглядят прибыльными: они действительно покрывают переменные расходы. Убыток виден только в сравнении с целевой маржой, а такого отчёта обычно нет.

Лечится одним правилом в системе: рейс ниже порога маржи требует подтверждения руководителя, и подтверждение фиксируется с причиной. Через месяц у вас появляется список причин, а вместе с ним — понимание, где порог задан неверно, а где диспетчер просто торопился. Механику работы с биржами и то, какие данные оттуда приходят структурированными, разбирали в материале про грузовые биржи и автоматизацию заявок.

Ошибка 7. Со стороны компании нет ответственного

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

Цена считается просто: примерно 16 часов инженера в месяц уходит на выяснение того, что должен был назвать заказчик, — 48 000 ₽ по ставке 3 000 ₽ за час. Это оплаченное время, потраченное на переписку. Вторая, невидимая часть — сдвиг запуска на два месяца, то есть два месяца неполученного эффекта от всего проекта целиком.

Ответственный — не проектный менеджер и не айтишник. Это человек, который знает, как компания возит, и имеет право сказать «делаем так». Обычно это руководитель перевозок или старший диспетчер, и ему нужно освободить 4–6 часов в неделю на время проекта. Если такого человека выделить нельзя, проект надо не начинать, а отложить: это дешевле, чем начать и остановиться на середине.

Сколько это стоит вместе и что чинить первым

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

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

Порядок исправления: от бесплатного к дорогому

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

1. 1Назначить ответственного. Стоит ноль рублей и один разговор, а без него дальше не работает ничего. Освободить человеку 4–6 часов в неделю на время проекта.
2. 2Ввести правило по марже. Одно ограничение в системе плюс подтверждение с причиной. День работы, 74 800 ₽ в месяц.
3. 3Назначить владельца справочника и почистить дубли. Три дня, 64 912 ₽ в месяц, и это же условие для любой будущей маршрутизации.
4. 4Ввести регламент разбора отчётов телематики. Полчаса в неделю у руководителя перевозок. Железо уже куплено, платить не нужно.
5. 5Сократить отметки водителя с четырнадцати до пяти. Две недели работы, 51 480 ₽ в месяц, плюс отметки наконец начинают появляться.
6. 6Собрать реестр заявок и перенести учёт из чата. Это уже проект на 6–8 недель, но именно он даёт самую крупную строку — 156 000 ₽ в месяц — и открывает дорогу ко всему остальному.
7. 7И только теперь маршрутизация. Когда 90 % заявок структурированы и справочник в порядке. Разбор того, где алгоритм систематически врёт, — в материале про планирование рейсов и маршрутизацию.

Когда проект лучше не начинать

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

• Некому выделить 4–6 часов в неделю. Без человека, который отвечает за решения, проект превращается в переписку. Лучше отложить на квартал, чем начать и остановиться на середине: остановленный проект стоит денег и портит отношение сотрудников к следующему.
• Поток заявок ниже порога. У перевозчика с 8–10 машинами и полусотней заявок в месяц шесть из семи потерь просто не набирают величины: 6 % рейсов с неточным адресом — это три рейса, а не тридцать четыре. Пороги мы разбирали отдельно в материале про то, когда перевозчику автоматизация не окупится.
• Проблема в одном человеке, а не в процессе. Если весь учёт держится на одном диспетчере, который не хочет ничего менять, софт ситуацию не изменит. Здесь решается кадровый вопрос, и делать это надо до проекта, а не в его середине.

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

В перевозках ломается не система, а места, где она рассчитывала на человека вне её периметра.