Модуль 15. BI-системы в логистике и цепочках поставок
Картина домена: из чего складывается логистика
Системы и роли данных
- WMS (склад): приемка (ASN), хранение, отбор/укладка (picking/packing), отгрузка, ячейки и slotting, возвраты/разукомплектация.
- TMS (транспорт): заказ перевозки, план маршрута/окон, рейсы (FTL/LTL), планирование загрузки, статус перевозки, ИД перевозчика/ТС/водителя.
- YMS (двор/ворота): прибытие/очередь, назначение ворот (dock assignment), дворовые простои и «ворота открыто/закрыто».
- Telematics/Driver App/IoT: GPS-пинги, CAN-параметры, температуры (cold chain), POD (proof of delivery).
- ERP: заказы, позиции/EDI, календарь клиентов, тарифы, штрафы.
Цепочка событий (минимум «ног» цепочки)
Supplier → Port/Ingate → Long Haul → DC (cross-dock/putaway) → Line Haul → Store/Client (Last Mile).
BA фиксирует событийную модель: что является «планом» и «фактом», какие окна SLA (тайм-виндо, ±минут).
Схема данных для витрин WMS/TMS/YMS
Факты
- fact_leg_plan — план по «ноге» (order/stop): leg_id, order_id, stop_seq, planned_arrive_ts, planned_depart_ts, service_window_from/to, distance_km, mode (FTL/LTL), carrier_id.
- fact_leg_actual — факты событий: arrive_ts, depart_ts, gate_in_ts, gate_out_ts, pod_ts, reason_code.
- fact_telemetry_ping — сырьё GPS: vehicle_id, ts, lat, lon, speed, odo, signal_quality.
- fact_dwell — простои: yard_dwell_min, gate_dwell_min, door_dwell_min.
- fact_shipment_line — «полнота» (In-Full): ordered_qty, shipped_qty, delivered_qty, damage_qty.
- fact_wms_task — операции склада: task_type(pick/putaway), start_ts, end_ts, from_loc, to_loc, sku_id.
- fact_co2_activity — активность перевозок: mode, weight_ton_km, distance_km, fuel_liters.
Измерения
- dim_order, dim_stop, dim_vehicle, dim_carrier, dim_dock_door, dim_yard_slot, dim_customer (windows/penalties), dim_product (weight/volume/KVI), dim_reason_delay (код-иерархия), dim_geofence (polygon).
Агрегаты/витрины
- mart_otif_day_carrier — OTIF по дню/перевозчику.
- mart_delay_reasons — Pareto причин с привязкой к «ногам».
- mart_dwell_by_facility — простои двор/ворота.
- mart_slotting_velocity — slotting (ABC/XYZ) и качество размещения.
- mart_co2_route — CO₂e по маршрутам/перевозчикам.
Ключевые метрики и их формулы (без двусмысленностей)
OTIF / On-Time / In-Full
- On-Time = 1, если actual_arrive_ts ∈ [window_from, window_to] (или допускаем ранний/поздний с буфером ±X минут).
- In-Full = 1, если delivered_qty ≥ ordered_qty - allowed_shortage.
- OTIF = доля заказов, где On-Time=1 и In-Full=1.
Важно: On-Time можно считать по прибытию (arrival) или POD — зафиксируйте единый вариант per-customer.
Service Level (Fill Rate)
- Order Fill Rate = (# заказов без недопоставки) / (# заказов).
- Line Fill Rate = (# строк без недопоставки) / (# строк).
- Cycle Service Level — вероятность отсутствия дефицита в цикле пополнения (для планирования — из статистики спроса).
План-факт по рейсам
- Отклонение прибытия = actual_arrive_ts − planned_arrive_ts (мин, со знаком).
- Отклонение выезда — аналогично.
- Transit time фактический vs плановый — на уровне «ноги».
FTL/LTL
- FTL (целиком машина): KPI — OTD/OTIF, загрузка (load factor), dwell, Damage rate.
- LTL (догруз): KPI — OTIF по окнам стыков, точность консолидации, «доп. перегрузы».
Cross-dock / Yard
- Yard dwell = gate_in → door_start.
- Door dwell = door_start → door_end.
- Throughput по воротам/часам, turn time по прицепам.
Slotting (склад)
- Velocity (pick frequency) по SKU/ячейке.
- Slot quality index (SQI): штраф за «плохое» размещение (далеко от экспедиции/горячей зоны; превышение веса для уровня/ячейки).
- Travel distance per pick — метрика улучшения.
CO₂-метрики
- Activity-based: CO₂e = distance_km × emission_factor_mode + (payload_factor); факторы — per-mode (truck/van/rail/air/sea), корректировка по загрузке и обратным пустым пробегам.
- Spend-based — по затратам (грубее, как fallback).
- Scopes: фиксируйте, что именно покрывается (обычно Scope 3 «Upstream/Downstream transport & distribution»).
- Guardrails: показывайте интенсивность: gCO₂e/тонно-км, gCO₂e/посылку.
Событийная модель и геоданные: как «добыть» факты
Источники событий: телематика (GPS), приложение водителя (чек-ин/чек-аут + фото POD), скан-штрихкод, геозоны (геофенс), YMS (ворота), WMS (статусы).
Derive-события через геозоны
- Geofence entry/exit по полигонам склада/клиента/хаба.
- Двор/ворота — вложенные геозоны: Yard ⊃ DockDoor.
- Порог стоянки для dwell: speed<3 km/h и в геозоне.
Тайм-зоны и часы
- Сохраняйте event_time в UTC + tz локации; показывайте в локальном времени склада/клиента.
Пример SQL (упрощено): обнаружить прибытие по геозоне
-- последняя точка до входа в геозону клиента
WITH ordered AS (
SELECT t.vehicle_id, t.ts, t.lat, t.lon,
g.customer_id,
ST_Contains(g.polygon, ST_SetSRID(ST_Point(t.lon, t.lat), 4326)) AS inside,
ROW_NUMBER() OVER (PARTITION BY t.vehicle_id, g.customer_id ORDER BY t.ts) rn
FROM fact_telemetry_ping t
JOIN dim_geofence g ON g.type = 'CUSTOMER'
WHERE t.ts BETWEEN :from AND :to
),
arrivals AS (
SELECT vehicle_id, customer_id, MIN(ts) AS actual_arrive_ts
FROM ordered
WHERE inside = TRUE
GROUP BY vehicle_id, customer_id
)
SELECT * FROM arrivals;
Расчёт дистанции по Haversine — используйте для sanity-check «отставания» от плана.
Map-matching (сопоставление дороги) — nice-to-have, но на практике достаточно очищенного GPS + геозон.
Политика свежести (latency) по «ногам» цепочки
|
Нога |
Источник |
Ожидаемая свежесть |
Допуск/режим «черновик» |
|---|---|---|---|
|
Yard (YMS) |
чек-ин/чек-аут, ворота |
≤ 2 мин |
нет dwell — баннер «данные двора задерживаются» |
|
Cross-dock (WMS) |
операции ворот/скан |
≤ 5 мин |
блок экспорта OTIF по кросс-доку |
|
Line Haul (TMS/telematics) |
GPS пинги |
1–5 мин |
«последняя точка» + вектор, флаг «ETA по модели» |
|
Last Mile (Driver App) |
POD/фото/подпись |
≤ 1 мин |
«POD отсутствует» → On-Time=N/A |
|
ERP план |
заказы/окна |
D-1 20:00 |
при изменениях — MAJOR (влияет на OTIF) |
В SRS/NFR BA фиксирует Freshness per leg + реакцию: баннеры, блоки экспорта, алерты.
План-факт по рейсам: FTL vs LTL и «мульти-стоп»
FTL: одна отправка → один получатель (или краткий мульти-стоп). Планируем «ноги» и сверяем окна.
LTL: консолидация — важно сверять стыковочные окна хабов и «внутренние» OTIF (между хабами), иначе «усреднение» скроет проблемы.
Пример (план-факт по «ноге»)
SELECT leg.leg_id, o.order_id, s.stop_seq,
planned_arrive_ts, actual_arrive_ts,
EXTRACT(EPOCH FROM (actual_arrive_ts - planned_arrive_ts))/60 AS dev_min,
CASE WHEN actual_arrive_ts BETWEEN window_from AND window_to THEN 1 ELSE 0 END AS on_time
FROM fact_leg_plan p
JOIN fact_leg_actual a USING (leg_id)
JOIN dim_stop s USING (leg_id)
JOIN dim_order o USING (order_id);
Slotting: как BA формулирует задачу склада
Данные:
- Спринт-период: 13 недель продаж/отборов по SKU.
- Ограничения локаций: размеры/вес/уровень/доступность для техники.
- Точки отбора/экспедиции, «горячие зоны» (коридоры).
Метрики:
- Velocity SKU (отборов/неделю), ABC/XYZ классы.
- SQI (штрафы за «плохое» место), travel distance per pick.
Решение: ранжирование SKU по velocity × штраф за ограничения, перенос в ближние ячейки; контроль эффектов: −X% путь/отбор, −Y% время.
Cross-dock: где промахиваются чаще всего
- События: gate-in → очередь → назначение ворот → unload/load → gate-out.
- KPI: door dwell, yard dwell, missed cross-dock (перешло на хранение), throughput ворот (подд/час).
- BA-решение: обязательность причин задержек (причина/ответственный), политика тайм-аутов автоклассификации.
CO₂-метрики: практический минимум
- Формула: CO₂e = distance_km × EF_mode × load_factor × (1 + empty_return_share); для rail/sea — свои EF.
- Данные: расстояние (план/факт), масса/объём (тонно-км), загрузка, доля пустых пробегов.
- Показывать: абсолют (тонн CO₂e) и интенсивность (gCO₂e/тонно-км, gCO₂e/доставку).
- Распад по причинам: выбор более «грязного» режима, недогруз, пустые возвраты — видим поля улучшения.
Дашборд «OTIF & Delay reasons» (скелет + NFR)
Цели: видеть просадку OTIF по «ногам», перевозчикам, клиентам; быстро находить причину (двор, ворота, дорога, клиент).
Верхние KPI: OTIF %, On-Time %, In-Full %, среднее отклонение прибытия (мин), Top-1 причина задержки, gCO₂e/посылку (опционально).
Зоны:
- Воронка «Ноги цепочки»: Supplier→Port→Line Haul→DC→Line Haul→Client — цветом On-Time.
- Pareto причин задержек (иерархия): погрузка/ворота/двор/дорожная/клиент/документы/тех.
- Тепловая карта: Carrier×Region (OTIF).
- Карта рейсов: фактический трек vs план, отклонения и ETA.
- Таблица заказов: окно клиента, фактическое прибытие, on_time, in_full, причина, штраф.
- DQ/латентность: свежесть телематики, доля рейсов без POD, без геособытия.
Фильтры: период, клиент, регион/хаб, carrier, FTL/LTL, «нога», тип причины, окно.
NFR: p95 ≤ 5 сек; Freshness телематики ≤ 5 мин; RLS: по региону/перевозчику; гео-слой кэшируется.
Приемка: 10+ acceptance-кейсов
- On-Time по окну: заказ с окном 10:00–12:00 и прибытие 11:15 → On-Time=1.
- Буфер: окно 10:00–12:00, прибытие 09:57, буфер −5 мин → On-Time=1.
- In-Full: заказ 100, поставка 98, allowed_shortage=2 → In-Full=1.
- OTIF композит: On-Time=1, In-Full=0 → OTIF=0.
- Cross-dock dwell: gate-in 09:00, door_start 10:10 → yard_dwell=70 мин.
- Geofence-arrival: GPS внутри полигона клиента → actual_arrive_ts установлен, On-Time пересчитан.
- LTL стыковка: пропущен хаб-срез → причина «Hub miss».
- POD отсутствует: On-Time=N/A, заказ попадает в DQ-виджет.
- CO₂ интенсивность: маршрут 200 км, 5 т, EF=90 g/т-км → 90×200×5=90 000 g = 90 кг CO₂e.
- Latency-черновик: телематика>5 мин → баннер «ETA по последней точке», блок экспорта.
Риски и анти-паттерны
|
Риск |
Симптом |
Меры |
|---|---|---|
|
Несогласованные окна |
Споры «во сколько было поздно» |
Хранить окно клиента на уровне order_id, freeze на релиз, MAJOR при изменении |
|
Дыры GPS/офлайн |
«Телепорты», пропуски |
Фильтрация по hdop/скорости, интерполяция, fallback на чек-ин |
|
Тайм-зоны |
Неверные on-time |
Все факты — UTC + tz; отчёты — локализация по складу/клиенту |
|
Нет нормальной иерархии причин |
«Другая»/«Прочее» 60% |
Принудительная классификация + автоподбор по паттернам событий |
|
OTIF «средний по больнице» |
Разные режимы смешаны |
Срезы per-leg, per-mode, per-carrier; guardrails |
|
CO₂ «на глаз» |
Недоверие |
Activity-based по тонно-км, EF задокументирован, owner метрики |
|
«Свежести нет» |
Решения на старых данных |
Freshness-виджеты, алерты, режим «черновик» |
|
RLS ломает итоги |
Разные суммы у ролей |
Тесты ролей, итоговые витрины под RLS |
Вопрос–ответ (FAQ)
Q: Что считать «ранним прибытие» — это хорошо или плохо?
A: Для многих клиентов раньше окна — тоже нарушение. Фиксируйте политику: ранний допуск ±Х минут или On-Time=0.
Q: На чём считать On-Time — на arrival или POD?
A: Если важна встреча окна, берите arrival; если штрафы по факту передачи — POD. Делайте обе метрики и указывайте «официальную».
Q: Как корректно мерить In-Full в LTL?
A: На уровне строк и посылок. Часто строки частично доставляются — используйте Line Fill Rate и санкции по контракту.
Q: Почему CO₂е «прыгает», хотя километры те же?
A: Из-за загрузки/пустых пробегов/режима/рельефа. Показывайте интенсивность (на тонно-км) и разложение по факторам.
Q: Можно ли без телематики, только TMS-статусами?
A: Можно, но с худшей точностью и свежестью. Для Last Mile телематика/driver app сильно повышают доверие и скорость реакции.
Практика (что сдать по итогу модуля)
A. Дашборд «OTIF & Delay reasons» (макет + NFR)
- KPI, зоны, фильтры и DQ-виджет из §10.
- Acceptance-кейсы из §11.
- Паспорт дашборда: цель, метрики, методология вер. X.Y, владельцы, Freshness per leg.
B. Политика свежести по «ногам» цепочки
- Таблица из §5 адаптированная под вашу сеть: источники, целевая свежесть, допуски, реакции (баннер/алерты/блок экспорта), владельцы.
C. Схема событий и словарь причин задержек
- Иерархия Level 1–3 (Дорога/Двор/Ворота/Клиент/Документы/Техника/Погода).
- Мэппинг статусов TMS/телематики/скана → унифицированные события (arrive/depart/gate-in/out/door-start/end/POD).
D. Быстрые победы
- Геозоны клиентов/складов и автоматический arrive/depart.
- Yard/door dwell-дашборд.
- Pareto задержек per-carrier.
- CO₂-интенсивность по маршрутам (activity-based).
Чек-листы готовности
Метрики/Методология
- On-Time (окно/буфер) и In-Full (уровень строки/заказа) определены и задокументированы.
- OTIF формула едина; версия методики в шапке.
- CO₂e: метод (activity/spend), EF и coverage описаны.
Данные
- Геозоны заведены (склады/клиенты/хабы); GPS очищается.
- События arrive/depart/door/yard/POD восстанавливаются из источников.
- Reason codes обязательны; «Прочее» < 15%.
- Тайм-зоны и DST учтены.
NFR
- Freshness per leg соблюдается; режим «черновик» при срыве.
- p95 страницы ≤ 5 сек; карты кэшируются.
- RLS по региону/перевозчику протестирован.
Вы проектируете витрины и метрики для WMS/TMS/YMS, привязываете GPS и события к «ногам» цепочки, задаёте политику свежести, считаете OTIF/On-Time/In-Full, dwell, slotting, CO₂e, и упаковываете всё в дашборд «OTIF & Delay reasons» с понятными реакциями при срывах. Это переводит «где груз?» и «почему штраф?» в измеримую операционную дисциплину и устойчивые улучшения.
