Почему одометру и GLONASS/GPS нельзя верить? “Честный рейс” определяет накрутку пробега в автопарке.
Пробег – это базовая метрика, на которой держится вся экономика автопарка. Через параметр километража происходит расчет практически всего, начиная от топлива, заканчивая оплатой подрядчиков.
Но если эти данные можно “накрутить”, то компания платит за то, чего не было.
Лишние километры приводят к неоправданным тратам, перерасходу топлива, искажению отчетности и ошибкам в управлении.
И проблема в том, что такие потери редко выглядят как аномалия. Они выглядят как «нормальная работа».
Финансовые потери автопарка из-за некорректного учета
В операционной модели завышение пробега прежде всего приводит к прямым финансовым потерям. Во многих автопарках дорожная наработка служит базой для расчетов с подрядчиками, начисления зарплаты водителям и биллинга в логистике или аренде. Завышенный километраж вынуждает компанию платить за «воздух». Хотя расходы и выглядят корректными, но не приносят выручки и постепенно увеличивают нагрузку на бюджет.
Кроме того, нарушается контроль над топливными затратами. Они всегда рассчитываются исходя из дистанции, и «лишние» метры формально объясняют перерасход. Но становится невозможно отличить реальные отклонения от манипуляций, а нормы теряют свою ценность. По оценкам отрасли и нашей практике внедрений, до 14% затрат на горючее приходится на ошибки учета, манипуляции и несанкционированные действия, а в крупных корпоративных структурах может достигать 15–19%.
Еще один эффект связан с восприятием загрузки транспорта. Накрученный путь создает иллюзию высокой активности. Техника выглядит задействованной, маршруты – выполненными, показатели – достигнутыми. При этом часть машин может простаивать или использоваться неэффективно. Одна грузовая машина может «съедать» сотни тысяч рублей в год, а в масштабах всего автопарка потери достигают миллионов.
На уровне управления последствия становятся менее очевидными, но более значимыми. Километраж служит опорой для стоимости километра, расхода топлива на 100 км, загрузки, SLA и эффективности водителей. Неправильные данные не позволяют выявить проблемные процессы и отклонения сглаживаются. Ошибка в отдельных KPI может достигать 10–20%, что напрямую влияет на точность управленческих действий.
В стратегическом плане это приводит к системным ошибкам планирования. На основе фиктивного пробега принимаются решения о расширении транспортной базы, увеличении закупок топлива, изменении логистики и распределении нагрузки. В результате компания масштабирует не реальную потребность, а ее деформированное отражение, что увеличивает операционные затраты и снижает эффективность.
Почему автопарки не могут выявить накрутку пробега
На первый взгляд контроль пройденного расстояния в автопарке давно должен быть решенной задачей. У компаний есть системы мониторинга, ведутся путевые листы, фиксируются цифры на одометре, собираются метрики с датчиков. Объем информации достаточный, чтобы считать ситуацию управляемой.
Проблема в том, что наличие данных не равно их достоверности.
Длина маршрута отмечается сразу в нескольких источниках – одометре, GPS/ГЛОНАСС, CAN-шине, учетных системах. Но всё существует разрозненно и практически не сверяется между собой. Каждый источник воспринимается как отдельный и условно надежный, а возникающие расхождения остаются вне системного контроля.
Даже телематические системы, на которые обычно делают основную ставку, решают смежную задачу. Они позволяют видеть движение транспорта, маршруты и поведение техники, но не дают ответа, соответствует ли зафиксированный путь реальной эксплуатации. GPS показывает, где была машина, но не проверяет корректность итогового километража. При этом ранее точность оценки пробега по GPS могла достигать около 90%, однако в последнее время она снизилась примерно до 50% из-за влияния внешних факторов.
Ситуацию усложняет зависимость от ручного ввода. Показания одометра записываются сотрудниками, путевые листы заполняются и корректируются, сведения переносятся между системами. В такой модели любые изменения выглядят как часть операционной работы, и отличить ошибку от намеренной корректировки без дополнительного анализа практически невозможно.
Контроль при этом остается фрагментарным. Проверки носят выборочный характер – сверяются отдельные документы, проводятся точечные аудиты. При масштабировании автопарка это неизбежно приводит к тому, что значительная часть фактов остается вне проверки, а повторяющиеся отклонения не формируют единой картины.
Выявление накрутки требует другого уровня работы со сведениями – постоянного сопоставления источников, анализа отклонений и фиксации нетипичных сценариев. Вручную такая задача не решается, количество факторов слишко велико.
Возникает парадоксальная ситуация. У бизнеса есть всё необходимое, но нет инструмента, который проверил бы согласованность и достоверность. Поэтому накрутка не устраняется.
Отдельный фактор, который дополнительно усложняет контроль, – нестабильность GPS. В ряде регионов сигналы могут искажаться или временно пропадать из-за внешних воздействий. В таких зонах данные о маршрутах становятся неполными или неточными. И даже при наличии систем мониторинга компании фактически теряют возможность объективно отслеживать движение транспорта на отдельных участках и в определенные периоды времени.
“Честный рейс. Пробег” от Ноософт
Решение задачи истинного учета километража требует не увеличения количества данных, а изменения подхода к работе с ними. Важно не просто фиксировать показатели, а проверять их согласованность между собой.
Именно на этом принципе построен модуль «Честный рейс. Пробег» от NooSoft. Он встраивается в существующую инфраструктуру автопарка и добавляет уровень верификации. Он не заменяет системы мониторинга или учетные решения, а использует уже накопленную статистику, чтобы проверить их подлинность и выявить расхождения.
В основе сервиса – постоянное сопоставление наблюдений из разных источников. Пробег, запротоколированный в одометре или учетной программе, сравнивается с фактическим движением. Если между ними возникает несоответствие, алгоритм фиксирует это как аномалию и выносит на уровень контроля.
Анализ выполняется автоматически и непрерывно. Система агрегирует сведения, очищает их от шумов и погрешностей, нормализует и сопоставляет между собой. За счёт этого становится возможным выявление нетипичных сценариев эксплуатации, например, когда транспортная наработка увеличивается без движения или противоречит другим параметрам работы машины.
Модуль работает с несколькими источниками одновременно. Он подключается к системам мониторинга транспорта (таким как Wialon, GlonasSoft, Omnicomm, СКАУТ и другим) и получает GPS/ГЛОНАСС-записи, информацию о скорости, оборотах, напряжении, ускорениях, торможениях и других параметрах.
Дополнительно используется база с CAN-шины и датчиков транспортного средства. Она позволяет восстанавливать реальную модель эксплуатации автомобиля.
Все материалы объединяются в единую систему без изолированной обработки и проверяются в связке, формируя целостную картину. Именно за счёт такого подхода выявляется накрутка пробега в формате несоответствия между зарегистрированными значениями и фактическим поведением техники.
На выходе бизнес получает не массив сырых показателей, а уже отфильтрованный результат: скорректированный объем перемещений, зафиксированные расхождения, признаки манипуляций и готовые выводы для учета. Результаты автоматически передаются в учетные системы, включая 1С и другие ERP-решения, и использоваться в ежедневной операционной работе без дополнительной ручной проверки.
Технически решение построено как масштабируемый модульный сервис. Бэкенд реализован на Python, Django и с асинхронным выполнением задач через Celery, что позволяет охватывать большие объемы в фоновом режиме. Для хранения и анализа задействовали PostgreSQL и in-memory хранилища, а вычисления и аналитика производятся с применением библиотек работы с данными.
Внедрение “Честный рейс. Пробег”
Внедрение модуля контроля пробега не требует перестройки существующей ИТ-инфраструктуры. Он работает поверх уже запущенных систем отслеживания, телематики и учета, дополняя их функцией верификации.
Внедрение начинается с подключения к источникам данных. Система интегрируется с платформами мониторинга транспорта (Wialon, GlonasSoft, Omnicomm, СКАУТ и другими) через API и получает доступ к информации о движении и состоянии автомобилей. Это не требует изменений в текущих системах и не влияет на их работу.
Далее настраивается поток метрик с датчиков, необходимых для анализа. Здесь важно обеспечить корректность и полноту передаваемого потока, поскольку от этого зависит точность выявления отклонений.
После подключения выполняется калибровка алгоритмов под конкретный бизнес. Учитываются особенности эксплуатации: типы техники, характер маршрутов, режимы нагрузки. Это позволяет адаптировать систему под реальные условия и снизить вероятность ложных срабатываний.
Затем проводится тестирование. Проверяется корректность сопоставления источников, логика выявления аномалий и стабильность системы. Параллельно команда клиента получает базовое понимание того, как интерпретировать результаты и применять их в операционном контуре.
После запуска система работает в автоматическом режиме, анализируя весь автопарк. Зафиксированные отклонения и сопутствующая информация передаются в учетные платформы, включая 1С и другие ERP, и могут использоваться при закрытии путевых листов и формировании отчетности.
Срок внедрения зависит от масштаба компании и готовности инфраструктуры, но в среднем занимает от двух недель. При этом участие со стороны клиента минимально и сводится к предоставлению доступа к системам и согласованию параметров работы.
Что получает бизнес в цифрах
Эффект от внедрения сервиса контроля пробега проявляется в первые месяцы работы, поскольку затрагивает сразу несколько источников потерь.
Практика внедрений показывает, что удаётся выявить до 75% случаев накрутки. Иными словами, большая часть ранее незаметных манипуляций выходит из «серой зоны» и становится прозрачной для анализа и управления.
В результате общий объём неучтённых перемещений снижается в среднем на 10–15%. Автопарк начинает работать на основе фактических данных, что напрямую повышает точность расчетов и уровень затрат.
Сокращаются и холостые пробеги в среднем на 12–18%. Это выявляет неэффективные маршруты, избыточные перемещения и фактический простой техники, который ранее маскировался под рабочую загрузку.
Более точные значения меняют и подход к эксплуатации транспорта. Корректный учет позволяет планировать техническое обслуживание по реальной нагрузке, что в среднем снижает затраты на ремонт до 15% и уменьшает риск внеплановых поломок.
Снижается и операционная нагрузка на персонал. Процесс закрытия путевых листов, который ранее требовал ручной сверки и занимал значительное время, автоматизируется. Система передаёт корректные записи о километраже сразу в учётные контуры, сокращая обработку до нескольких секунд и минимизируя человеческий фактор.
В совокупности это формирует ощутимый экономический результат. Для средней компании с парком из 50 машин при расходе топлива на 100 км, цене 60 рублей за литр без НДС и среднем суточном пути 200 км экономия составляет около 530 000 рублей в месяц или порядка 6 240 000 рублей в год.
Как снизить затраты и выявить накрутку?
Если коротко ответить на вопрос, то начинать нужно не с оптимизации маршрутов или сокращения расходов, а с восстановления контроля над базовым показателем: пробегом.
Через него формируются практически всё в автопарке. Мониторинг фактического пути – это инструмент управления затратами.
С решением от НооСофт для первичной оценки ситуации не требуется сложных внедрений или перестройки процессов. Достаточно начать с простой диагностики текущих данных. Наша команда поможет сравнить источники информации, выявить расхождения, посмотреть на аномалии и определить основные зоны потерь.
Дальше возможны разные сценарии – от точечной настройки процессов до внедрения автоматизированного контроля.
И если нужен практический ориентир, следующий шаг обычно выглядит просто – пилотный анализ транспортной базы. А как его провести, расскажем уже вам лично.
