Типовой сценарий: панель мониторинга логистики для 3PL-оператора

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

Профиль: логистическая компания (3PL), 150+ единиц техники, 8 регионов доставки. Единой картины по загрузке флота и срокам доставки нет — данные лежат в Excel, отчёты собираются вручную. Кастомная панель мониторинга сводит их в один контур, и управленческие решения принимаются за минуты вместо дней. Что именно меняется и на сколько — считается на пилоте на ваших данных.

Задача: нет единой картины по логистике

Данные в разных системах, решения принимаются «по ощущениям».

Данные в разных местах

TMS (транспортная система) хранит маршруты и статусы, бухгалтерия — затраты, диспетчеры ведут свои Excel-файлы с загрузкой. Единого источника истины нет.

Нет KPI в реальном времени

OTIF (On-Time In-Full) считается вручную раз в месяц. Загрузка флота оценивается «на глаз». Стоимость километра не отслеживается по маршрутам и клиентам.

Медленные решения

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

Подход: от данных к панели мониторинга

ETL-пайплайн + кастомная панель мониторинга с ключевыми метриками логистики.

Этап 1. Аудит данных и метрик (1 неделя)

Определяем ключевые KPI: OTIF, fleet utilization, стоимость/км, доля пустых рейсов, среднее время доставки по регионам. Фиксируем источники данных и частоту обновления.

Этап 2. ETL-пайплайн (3 недели)

Python-скрипты забирают данные из TMS (API), бухгалтерии (1С выгрузки) и диспетчерских файлов. Трансформация, валидация, загрузка в аналитическое хранилище. Обновление — ежедневно в 6:00.

Этап 3. Панель мониторинга (4 недели)

Три экрана: операционный (текущий день — статусы, загрузка, отклонения), аналитический (тренды KPI по неделям/месяцам), финансовый (стоимость/км по маршрутам, маржинальность по клиентам). Доступ через веб — руководство, диспетчеры, коммерческий отдел.

Что меняется (величину считаем на пилоте)

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

Доставка в срок

Ежедневный мониторинг OTIF позволяет реагировать на отклонения в тот же день: перераспределение транспорта, корректировка маршрутов. Видно не средний показатель за месяц, а конкретный рейс, который выпадает из срока, и причину.

Порожние рейсы

Визуализация загрузки флота вскрывает паттерны пустых обратных рейсов. У коммерческого отдела появляется основание подбирать попутные грузы на регулярных маршрутах.

Решения за минуты

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

Технический стек подробнее

Архитектура панели мониторинга проектируется с учётом двух ограничений: данные обновляются ежедневно (не real-time), а пользователи — не аналитики, а диспетчеры и руководители, которым нужны готовые ответы, а не инструмент для исследования.

ETL: Python + pandas + SQLAlchemy

Пайплайн состоит из 4 этапов: extract (забираем данные из TMS API, 1С выгрузок и диспетчерских Excel-файлов), transform (нормализация, расчёт KPI, агрегация по маршрутам/клиентам/регионам), validate (quality gates — полнота, консистентность, пороги), load (загрузка в PostgreSQL). Запуск — cron, ежедневно в 6:00. Полный цикл — 8–12 минут на ~15 000 записей в день. Отдельный скрипт генерирует «снимок» предыдущего дня для сравнения тренда день-к-дню.

Фронтенд: React + Recharts + Leaflet

Панель мониторинга — SPA на React с тремя экранами. Операционный экран: карточки KPI (OTIF, загрузка, пустые рейсы, среднее время доставки) + таблица активных маршрутов с цветовой индикацией статуса. Аналитический экран: графики трендов (Recharts) — OTIF по неделям, загрузка по регионам, топ-5 проблемных маршрутов. Финансовый экран: стоимость/км по маршрутам, маржинальность по клиентам, сравнение периодов. Карта маршрутов — Leaflet с кластеризацией точек доставки. Авторизация — JWT, три роли: диспетчер (операционный экран), коммерческий менеджер (все экраны), руководитель (все экраны + экспорт).

Инфраструктура

Разворачивается на внутреннем сервере компании (Ubuntu, Docker). PostgreSQL — хранилище, nginx — reverse proxy, certbot — SSL. Бэкенд (FastAPI) отдаёт данные через REST API с кэшированием (Redis, TTL 1 час для агрегатов). Мониторинг — Prometheus + Grafana для отслеживания здоровья пайплайна (время выполнения, количество обработанных записей, ошибки). Алерты в Telegram при сбоях ETL или недоступности API TMS.

Что замеряем на пилоте: базовая линия → изменение → KPI

Baseline берём за 2 месяца до старта и по тем же определениям метрик, что и после запуска. Значения «после» — ожидаемые, а не наши замеры у клиента: их считаем на пилоте.

OTIF (On-Time In-Full)

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

Пустые рейсы

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

Скорость принятия решений

Как сейчас: месячный отчёт готовится 3–5 дней и попадает к руководству к 10–15 числу, решения по убыточным маршрутам запаздывают на 4–6 недель. Что меняется: текущая ситуация видна ежедневно, убыточный маршрут всплывает за 1–2 дня на финансовом экране, а цикл «увидел — исправил» сжимается с 4–6 недель до 3–7 дней. KPI: время от отклонения до корректирующего действия.

Совет. Добавьте на операционный экран «красную зону» — маршруты, где OTIF ниже 80% за последние 7 дней. Диспетчеры привыкают к зелёному цвету и перестают замечать проблемы. Красная зона работает как принудительный фокус внимания.

Типичные ошибки при создании логистических панелей мониторинга

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

Ошибка 1: слишком много метрик на одном экране

Соблазн первой итерации — вывести на операционный экран все 12 KPI сразу. Через неделю диспетчеры перестают в него смотреть: «слишком много цифр, непонятно, что делать». Рабочая раскладка — 4 ключевых KPI (OTIF, загрузка, пустые рейсы, время доставки) с цветовой индикацией (зелёный/жёлтый/красный), остальные метрики уходят на аналитический экран. Правило: операционный экран должен отвечать на один вопрос — «всё ли в порядке прямо сейчас?».

Ошибка 2: данные TMS неполные или запаздывают

TMS обновляют водители вручную (статусы «выехал», «доставлено»), и часть статусов приходит с задержкой 2–4 часа или не приходит вовсе. Панель показывает «опоздание», хотя доставка выполнена вовремя, — и доверие к ней рассыпается за пару недель. Решение: «буфер достоверности» — если статус не обновлён более 2 часов, запись помечается как «данные устарели» (серый цвет). Параллельно — KPI для водителей по своевременности обновления статусов в TMS.

Ошибка 3: не учитывать сезонность

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

Совет. Перед запуском панели мониторинга проведите «тест на действие»: покажите каждый экран будущему пользователю и спросите — «Что вы сделаете, увидев эти данные?». Если ответ «ничего» или «не знаю» — экран нужно переделать.

Уроки и рекомендации

Что важно учесть при создании аналитической панели мониторинга для логистики.

Начните с 3–5 метрик

Не пытайтесь визуализировать всё сразу. Определите 3–5 ключевых KPI, которые влияют на решения. Остальное добавите после первого месяца использования.

ETL важнее визуализации

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

Вовлекайте пользователей

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