BI для логистики: где компания теряет деньги на доставке и как найти утечки с помощью аналитики

Стандартная отчетность по логистическим процессам чаще всего формируется в 1С и затем выгружается в Excel. Готовый отчет показывает итоговые показатели, но для полноценного управления затратами нужна более глубокая детализация:

• какой заказ, клиент, товар или маршрут сформировал затраты;
• сколько стоил конкретный рейс и отдельная доставка;
• где возникли простой, перепробег или недозагрузка;
• насколько фактический тариф перевозчика соответствует договорному;
• сколько компания потеряла на возвратах и повторных доставках;
• как логистические затраты повлияли на маржинальность заказа.

Получить такую картину сложно из-за разрозненности данных. Информация о заказах может находиться в ERP, о маршрутах — в TMS, о складских операциях — в WMS, а тарифы перевозчиков — в договорах или отдельных таблицах.

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

Рассмотрим основные зоны, в которых возникают такие скрытые потери.

Перечисленные выше потери возникают на разных этапах логистического процесса. Чтобы увидеть полную картину, определить причины отклонений и оценить их влияние на прибыль, необходимо объединить эти этапы в едином аналитическом контуре.
Рассмотрим, как связка DWH и BI помогает решить эту задачу.

Корпоративное хранилище данных (DWH) объединяет разрозненные данные из логистических и учетных систем в единую основу для аналитики.
Источниками могут выступать:

• ERP-системы — заказы, продажи, себестоимость, договоры и другие финансовые и учетные данные.
• TMS (Transportation Management System) — рейсы, маршруты, перевозчики, плановый километраж и стоимость перевозок.
• WMS (Warehouse Management System) — складские остатки, комплектация заказов, погрузка и разгрузка, складские операции.
• GPS/ГЛОНАСС и телематика — фактические маршруты, пробег, скорость, расход топлива и данные датчиков транспорта.
• CRM — данные о клиентах, рекламациях, требованиях к доставке и истории взаимодействия.
• SRM (Supplier Relationship Management) — тарифы, результаты тендеров, данные о перевозчиках и истории сотрудничества.
• SCP (Supply Chain Planning) — прогнозы спроса, планы поставок, запасы и другие данные для планирования цепей поставок.
• ЭДО и электронные перевозочные документы — транспортные документы, статусы их оформления и подтверждения операций.

BI-система становится пользовательским уровнем аналитического контура: представляет подготовленные в DWH данные в виде наглядных визуализаций на интерактивных дашбордах.
Вместо статичного отчета с общей суммой транспортных расходов руководитель может детализировать показатели и последовательно анализировать:

• Стоимость доставки и маржинальность

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

• Возвраты и обратная логистика

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

• Работу с перевозчиками и 3PL

BI позволяет сравнить договорные условия с фактическими операциями и счетами и определить перевозчиков, тарифы и условия сотрудничества, которые приводят к дополнительным расходам.

• Использование транспорта

Аналитика помогает контролировать загрузку транспорта, долю порожнего пробега, стоимость километра и сравнивать эти показатели по маршрутам, типам транспорта и перевозчикам.

• SLA и качество доставки

BI позволяет выявить клиентов, по которым штрафы существенно снижают маржинальность, или проанализировать связь между качеством доставки и оттоком клиентов.

Следующий уровень развития аналитики для логистической компании — переход от ретроспективного анализа к прогнозной аналитике (Predictive Analytics).
Прогнозные модели в связке с BI позволяют решать несколько задач:

• Прогнозирование рисков доставки

На основе истории перевозок можно выделить заказы с повышенным риском опоздания и настроить алерты в BI, чтобы диспетчер мог заранее оптимизировать проблемные маршруты.

• Прогнозирование объемов перевозок

Анализ исторических данных, сезонности и планируемого спроса помогает оценить будущую потребность в транспорте по направлениям и периодам.

• Прогнозирование загрузки транспорта и складов

Сопоставление планируемых входящих и исходящих потоков позволяет заранее выявлять возможный дефицит транспортных мощностей или пиковую нагрузку на склады.

• Предиктивное обслуживание транспорта

Данные телематики о пробеге и состоянии узлов могут использоваться для оценки риска неисправности и планирования технического обслуживания (ТОиР) до ее возникновения.

Набор показателей, анализируемых в BI, зависит от модели бизнеса. Базовый дашборд может включать четыре группы метрик.

OTIF (On-Time In-Full) — ключевой логистический KPI, который показывает, какой процент заказов был доставлен:

• On-Time — вовремя (в согласованную дату и время)
• In-Full — в полном объеме (без недопоставки, пересортицы или частичных поставок)

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

Дополнительно можно оценивать финансовые последствия нарушения OTIF: штрафы, возвраты, повторные доставки и потерянную маржу.

Для комплексной оценки эффективности цепочки поставок можно использовать SCOR (Supply Chain Operations Reference Model) — референтную модель, которая систематизирует процессы и показатели управления цепями поставок.

SCOR объединяет показатели эффективности в пять ключевых категорий:

• Reliability (Надежность) — способность выполнять заказы вовремя, в полном объеме и с требуемым качеством. Основные метрики: POF (Perfect Order Fulfillment), OTD (On-Time Delivery), In-Full и другие.
• Responsiveness (Оперативность) — скорость выполнения заказов. Метрики: OFCT (Order Fulfillment Cycle Time), OPT (Order Processing Time), Picking Time и другие.
• Agility (гибкость) — способность цепочки поставок адаптироваться к изменениям спроса и сбоям. Оценивается, например, через Upside и Downside Supply Chain Adaptability — адаптивность цепи поставок к росту и спаду.
• Costs (затраты) — общие расходы на управление цепочкой поставок, включая планирование, закупки, производство, доставку и возвраты.
• Asset Management (управление активами) — эффективность использования запасов, оборотного капитала и основных средств. Основные метрики: Cash-to-Cash Cycle Time, Inventory Days of Supply, Asset Turn, Return on Supply Chain Fixed Assets и Return on Working Capital (ROWC).

В BI показатели SCOR можно объединить на одном дашборде и анализировать в разрезе периодов, подразделений, клиентов, маршрутов и других параметров.

Метрика Cost-to-Serve (CTS) демонстрируют реальные затраты на обслуживание конкретных клиентов, сегментов, каналов сбыта или товарных групп. В CTS могут входить:

• транспортировка;
• складская обработка;
• комплектация;
• возвраты;
• повторные доставки.

Сопоставление Cost-to-Serve с выручкой и маржой помогает обнаружить клиентов и направления, которые выглядят прибыльными по данным продаж, но становятся низкомаржинальными после учета логистики.

Для комплексного анализа затрат на логистику в BI также можно отобразить:

• стоимость доставки в разрезе клиентов или заказов;
• стоимость километра и тонно-километра;
• долю транспортных расходов в выручке;
• загрузку транспорта по весу и объему;
• долю порожнего пробега;
• среднее время простоя;
• процент возвратов и повторных доставок;
• план-факт стоимости перевозок;
• показатели перевозчиков и соблюдение SLA.

Этап 1. Предпроектное обследование и сбор требований
Определяем задачи аналитической системы, изучаем источники данных, существующую отчетность и требования пользователей.

Этап 2. Развертывание инфраструктуры DWH и BI
Разворачиваем и настраиваем СУБД, инструменты ETL/ELT и BI-платформу. В результате создается технологическая среда для разработки DWH, загрузки данных и создания отчетности.

Этап 3. Проектирование архитектуры и модели данных
Проектируем архитектуру DWH, определяем бизнес-сущности, связи между ними и правила обработки данных.

Этап 4. Построение DWH и аналитических витрин
Подключаем источники, настраиваем загрузку, очистку, трансформацию и хранение истории данных. Создаем аналитические витрины для BI.

Этап 5. Внедрение BI и разработка отчетности
Подключаем BI к витринам, настраиваем модель данных, обновление и ролевой доступ. Разрабатываем дашборды и отчеты под задачи пользователей.

Этап 6. Тестирование и запуск
Проверяем работу DWH и BI, тестируем пользовательские сценарии и устраняем замечания. После приемки система и BI-приложения переводятся в промышленную эксплуатацию.

Этап 7. Документация и обучение
Готовим техническую и пользовательскую документацию, проводим обучение ключевых пользователей и передаем систему в эксплуатацию.