В логистике можно получить хорошие локальные KPI и всё равно не понимать, почему падает сервис или доставка съедает маржу. Склад показывает производительность, транспорт - сроки, перевозчик - закрывающие расходы, коммерция - рост заказов. Формально данных достаточно, но они описывают разные участки цепочки. Между тем, что клиент считает выполненным обещанием, корпоративным определением OTIF и реальной стоимостью сервиса часто нет прямой связи.
BI нужен именно для этой связи. OTIF отражает своевременность и полноту поставки, SLA - выполнение требований на этапах, cost-to-serve - фактическую стоимость обслуживания заказа или клиента. Вместе они образуют управленческий контур сервиса, процесса и экономики.
Хороший OTIF может сопровождаться ростом экспедирования, снижением NPS на пиках и постоянными срочными отгрузками. Ускорение отправки с РЦ способно увеличить расходы последней мили, а дешёвый километр - ухудшить сроки для маржинальных клиентов.
Поэтому выбирать нужно не между OTIF и стоимостью километра, а между уровнями сервиса и их реальной ценой для бизнеса.
Как определить OTIF для управленческого BI
В компании часто существует несколько OTIF. Склад считает своевременную сборку и отгрузку, транспорт - доставку до точки, продажи - выполнение обещания клиенту, финансы - закрытие реализации и документов. Это разные части процесса, их нельзя выдавать за одну метрику.
В BI нужно закрепить события начала и завершения. Стартом обычно служит исходное обещание клиенту, финишем - подтверждённая полная доставка по адресу, в срок и с корректными документами.
OTIF полезно раскладывать на on time, in full и причину отклонения. Тогда видно, где теряется показатель: на сборке, из-за дефицита, переноса окна или возврата документов.
SLA по этапам: где возникает задержка и сколько она стоит
Для клиента важен полный путь от заказа до получения. Внутри компании это цепочка этапов: принятие заказа, резервирование, сборка, упаковка, отгрузка, магистраль, сортировка, последняя миля, подтверждение доставки, возврат и закрытие документов. У каждого этапа есть собственный SLA. Провал одного участка часто компенсируют срочной работой и дополнительными расходами на другом.
BI по этапам отвечает на два вопроса: где появилась задержка и какова её стоимость. Так спор между складом и транспортом превращается в разбор конкретной очереди или операции.
Измерение только общего срока скрывает внутренние задержки. Практичнее выделить ключевые этапы и использовать события WMS, TMS и ERP. Если важное событие не фиксируется, причину нельзя надёжно увидеть.
Cost-to-serve: полная стоимость выбранного сервиса
Cost-to-serve искажают два распространённых упрощения. Первое - учитывать только транспорт и не включать склад, упаковку, возвраты, контакт с клиентом и повторные доставки. Второе - смотреть на среднюю стоимость и не замечать, что отдельные каналы, зоны или сегменты сервиса уже стали убыточными.
Расчёт нужен на уровне заказа, клиента, маршрута или сервиса. На стоимость влияют вес и габариты, зона, окно, подъём, число точек, обратная логистика, документы и оплата при получении.
Рубль на километр полезен для контроля маршрута и перевозчика, но не показывает стоимость выполнения конкретного обещания. На последней миле рост показателя может быть ценой узкого окна, вечерней доставки или повторной попытки.
BI должен разделять сам сервис и его экономические последствия. Тогда понятно, за какой уровень обслуживания платит компания.
Три слоя логистических метрик: сервис, процесс и экономика
Для управления показатели удобно объединить в три взаимосвязанных слоя.
Сервис: OTIF, попадание в обещанное окно, переносы слота, NPS после доставки и возвраты по вине логистики.
Процесс: SLA и время этапов, ручные операции, очереди на стыках, отмены из-за отсутствия резерва, пересорт и повторные отгрузки.
Экономика: cost-to-serve на заказ, технический показатель рубль на километр, стоимость ресурса, возврата, недовоза и потери маржи.
Раздельные отчёты провоцируют спор о цифрах. Единый контур переводит обсуждение в конкретные действия.
Например, OTIF доставки на следующий день сохраняется, но cost-to-serve растёт из-за повторных попыток. Причина - переносы слота после поздней сборки на РЦ. Воздействовать нужно на резервирование и сборку, а не только менять перевозчика.
Такая связь переводит команду от наблюдения за KPI к конкретному решению.
Какие события нужны из WMS, TMS и ERP
Построение BI стоит начинать с событий процесса. Большая часть данных уже есть в системах, но редко собрана в одну последовательность от заказа до подтверждения доставки.
ERP и OMS: создание заказа, обещанная дата и окно, изменения обещания, отмена и причина, реализация и корректировки.
WMS: резерв, начало и конец сборки, упаковка, готовность и отгрузка, расхождения, пересорт и возврат на склад.
TMS: планирование маршрута, перевозчик, выезд, прибытие, попытка и факт доставки, недоставка, перенос окна и подтверждение.
Дополнительный слой: обращения, жалобы, компенсации и повторные согласования доставки.
Заказ должен прослеживаться через всю цепочку от обещания до подтверждения доставки. Если идентификаторы и события ERP, WMS и TMS не связаны или фиксируются по-разному, BI не восстановит процесс и будет сравнивать несопоставимые записи. Поэтому единый ID заказа, единые временные метки и согласованные события на стыках систем - базовое условие управления, а не технический перфекционизм.
Ошибки в расчёте OTIF и SLA
Первая ошибка - подменять исходное обещание скорректированным. Тогда OTIF выглядит лучше, хотя срок для клиента ухудшился. В BI нужно хранить обе версии и долю переносов.
Вторая ошибка - считать OTIF по удобному событию, например по отгрузке со склада, а не по фактической доставке клиенту.
Третья ошибка - не учитывать возвраты и повторные доставки. Без стоимости довоза, повторной комплектации и возврата показатели сервиса остаются неполными.
Управленческий экран BI для логистики
Экран должен начинаться не с карты перевозчиков, а с вопроса: что происходит с цепочкой на этой неделе, где отклоняется сервис и сколько это стоит.
На верхнем уровне достаточно OTIF по исходному обещанию, cost-to-serve на заказ и сегментов сервиса: стандартного, ускоренного и премиального. Рядом - переносы окон и повторные доставки.
Ниже размещаются SLA и время ключевых этапов, а также WIP или очередь. Это даёт быструю диагностику причины.
Далее идут разрезы по зоне, типу доставки, перевозчику, РЦ, категории и каналу. Их нужно связывать с драйверами cost-to-serve, иначе видны только «виноватые», но не причины.
Отдельный блок показывает стоимость повторной доставки, переноса, возврата и недовоза. Он помогает решить, какой уровень сервиса экономически оправдан.
Зачем объединять BI для логистики и TMS
TMS хорошо отражает маршруты, загрузку и выполнение доставок. BI связывает эти данные с коммерцией и финансами, чтобы управлять всей цепочкой от обещания до экономического результата.
Без общего контура логистика компенсирует задержки дополнительными ресурсами, коммерция обещает трудновыполнимый сервис, а финансы замечают расходы постфактум. Связка OTIF, SLA и cost-to-serve создаёт общий язык.
Для первого этапа достаточно событий WMS, TMS и ERP, единого идентификатора заказа и согласованных формул. Несколько рабочих экранов уже показывают, где цепочка теряет время и деньги. Дальше можно добавлять детализацию по зонам, каналам и типам сервиса, а также стоимость конкретных отклонений. Зрелость определяется не числом графиков, а скоростью перехода от найденной причины к решению и проверке его эффекта.
.svg)