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

Логистическая компания (3PL), 150+ единиц техники, 8 регионов доставки. До проекта не было единой картины по загрузке флота и срокам доставки — данные собирались в Excel и отчёты готовились вручную. После внедрения кастомной панели мониторинга — +12% OTIF, -8% пустых рейсов, управленческие решения за минуты вместо дней.

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

Данные в разных системах, решения принимались "по ощущениям".

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

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 по неделям/месяцам), финансовый (стоимость/км по маршрутам, маржинальность по клиентам). Доступ через веб — руководство, диспетчеры, коммерческий отдел.

Результаты

Измеримые улучшения за первые 3 месяца после запуска панели мониторинга.

+12% OTIF

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

-8% пустых рейсов

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

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

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

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

Архитектура панели мониторинга проектировалась с учётом двух ограничений: данные обновляются ежедневно (не 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.

Метрики до и после: детальное сравнение

Данные собирались в течение первых 3 месяцев после запуска. Базовые показатели зафиксированы за 2 месяца до начала проекта.

OTIF (On-Time In-Full)

До: 78% (замер раз в месяц, ручной расчёт в Excel, точность +/- 3%). Основные причины снижения: опоздания из-за неоптимальных маршрутов (40%), неполная загрузка / пересортица (25%), отмены и переносы клиентами (35%). После: 90% через 3 месяца. Рост обеспечен ежедневным мониторингом: диспетчеры видят отклонения в текущий день и перераспределяют транспорт. Коммерческий отдел получил данные по клиентам с систематическими переносами и пересмотрел условия SLA.

Пустые рейсы

До: ~22% рейсов возвращались пустыми (обратный рейс без груза). Коммерческий отдел не имел данных о регулярных маршрутах и не мог предложить попутную загрузку. После: 14% пустых рейсов (-8 п.п.). Панель мониторинга визуализировала паттерны: регулярные маршруты с пустым обратным рейсом стали видны, и коммерческий отдел начал подбирать попутные грузы. Экономический эффект: ~1,2 млн руб./мес. экономии на топливе и амортизации.

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

До: месячный отчёт готовился 3-5 дней, доставлялся руководству к 10-15 числу. Решения по убыточным маршрутам принимались с задержкой 4-6 недель. После: руководство видит текущую ситуацию в панели мониторинга ежедневно. Убыточный маршрут выявляется за 1-2 дня (финансовый экран), решение принимается в течение недели. Среднее время от обнаружения проблемы до корректирующего действия сократилось с 4-6 недель до 3-7 дней.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Красивая панель мониторинга с плохими данными — хуже, чем простая панель мониторинга с правильными. 80% усилий — на ETL, валидацию и quality gates. 20% — на визуализацию.

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

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