Fleet utilization — управление автопарком и загрузкой рейсов без потери SLA
Fleet utilization — система управления автопарком, которая считает всё, от чего зависит исполнимость рейса: загрузку по объёму и весу, смены, пустые пробеги, простои на точках и соответствие типа ТС спросу (fleet mix). INTEBRIX строит исполнимый план рейсов и позволяет сравнивать сценарии: сменность, закрепления, зоны, свой парк/подрядчик — с понятным эффектом по KPI (стоимость / сервис / utilization).
On-prem • Cloud • Пилот 2–6 недель • Интеграции: ERP / 1С / Excel / API
Когда использование автопарка «не сходится»
Типовые симптомы: парк большой, а «не хватает»; пробег растёт; SLA держится только за счёт переработок; диспетчеры постоянно «перекладывают» рейсы вручную.
Много рейсов с низкой загрузкой по весу/объёму — «возим воздух». Обычно лечится связкой load building + правила совместимости.
Пустые пробеги, ожидания на точках, несостыковка окон и сменности — из-за этого падает утилизация даже при «правильных» маршрутах.
Типы ТС не соответствуют спросу (объём/вес/условия), из-за этого нужен «лишний парк».
Сценарии «что-если» для управления автопарком
Сценарии под ваши ограничения и бизнес-правила: сменность, зоны, свой парк и подрядчик — каждый с дельтой по стоимости, SLA и utilization.
Добавить/снять смены, изменить графики, учесть ремонты и ограничения по времени рейса.
Балансировка кластеров между машинами/сменами для снижения пробега и роста SLA.
Где выгоднее отдать на подряд, а где — перестроить закрепления и режимы своего парка.
Какие данные нужны
Можно стартовать с минимума. Если часть данных в беспорядке — используем упрощения и уточняем по мере работы.
Заявки/точки, окна, парк и смены, базовые нормы времени и стоимости.
Вместимость/вес, совместимость, закрепления, лимиты по времени/дистанции, депо, правила «свой парк vs подрядчик».
Стартуем с оценок/диапазонов (время обслуживания, скорость, стоимость), затем уточняем по факту. Важнее быстро начать считать сценарии.
KPI fleet utilization: что оптимизируем и сравниваем
На пилоте фиксируем «как сейчас», затем сравниваем сценарии.
Вес/объём/паллеты, совместимость, доля недозагрузки по типам ТС.
Доля времени в работе, перегрузы/простой по сменам и направлениям.
Пустой пробег, лишние перегонки, неэффективные плечи и возвраты.
Соблюдение окон, штрафы, cost/км/час/рейс, подрядчик vs свой парк.
Материалы по теме
Показатели utilization, пустые км, простои на точках и что именно «лечить» в модели.
Как окна и штрафы меняют маршруты, стоимость и «потребность» в парке.
Совместимость, правила загрузки и компромиссы между cost и SLA.
Логика bottleneck и как мыслить про загрузку ресурсов, когда «не сходится».
Где появляются задержки, ограничения и почему «дешевле» иногда хуже для сервиса.
Вывоз лома: порожний выезд туда, куда уже идёт доставка
На металлургическом предприятии типична картина, которую не видно из отчётов по отдельным рейсам: машины уходят из парка порожняком специально за ломом, хотя в те же города в тот же день едет доставка проката. Пока вывоз и доставка планируются разными людьми в разных файлах, совпадение маршрутов просто некому заметить.
В разобранном случае за неделю 91 машина выехала порожняком только за ломом, и при этом 214 из 267 маршрутов доставки шли в города, которые одновременно являются источниками лома. Совпадение адресов и было незамеченным резервом.
Рычаг здесь не в том, чтобы «везти лом гружёной машиной», а в том, чтобы убрать сам отдельный выезд: рейс строится как депо → клиент → лом по пути → депо. Расчёт на фактических данных той же недели дал 71 порожний выезд вместо 91. Это расчёт на исторических данных заказчика, а не результат внедрения: у вас его повторяют на ваших цифрах в пилоте.
Контекст задачи
Порожний пробег и backhaul считает оптимизационное ядро: система подбирает обратную загрузку под уже запланированные рейсы и показывает, сколько порожних выездов остаётся после перепланирования. Порядок эффекта на промышленном парке виден из нашего пилотного расчёта по фактическим данным одной недели (металлургический холдинг, название не раскрываем): порожние рейсы за сырьём сократились с 91 до 71 за неделю, то есть на 20 рейсов или 22%, при этом оптимизированный план обошёл фактический в 6 из 7 дней. Это результат расчёта на реальных данных заказчика, а не достигнутая экономия в промышленной эксплуатации. Utilization улучшается только если ограничения зафиксированы честно: окна, сервис-тайм, смены, запреты, лимиты. Поэтому начинаем с правил — и только потом оптимизируем. Сценарии показывают вклад каждого фактора: fleet mix, несостыковка окон и сменности, закрепления и пустые плечи. Парк не оптимизируется в отрыве от рейсов: система управления перевозками (TMS) считает потребность в машино-сменах вместе с маршрутами, окнами и загрузкой.
FAQ
Fleet utilization — это просто «загрузка по объёму/весу»?
Почему «парк большой, а машин не хватает»?
Можно начать, если часть данных неточная?
Как интегрируемся с учётными системами?
Готовы оптимизировать?
Запустим пилот на ваших данных за 2–6 недель. Покажем базовую линию и измеримый эффект.
Запросить демо