Kpi по логистике: как выстроить стоимость/тонна, cost-to-serve и Sla по срокам и простоям

KPI в логистике стоит строить как связку из 4 контуров: unit-cost (стоимость перевозки за тонну), прибыльность по клиентам через расчет cost to serve, качество сервиса через SLA по срокам доставки и потери времени через KPI по простоям транспорта. Дальше задайте единые правила данных, частоту расчёта и действия при отклонениях.

Что важно помнить при построении KPI в логистике

• Один KPI должен иметь одного владельца, один источник данных и заранее описанное управленческое действие при отклонении.
• Не смешивайте в одном показателе качество сервиса и себестоимость: это приводит к ложным решениям и конфликтам между подразделениями.
• Перед внедрением зафиксируйте определения (что считается доставкой, опозданием, простоем) и границы ответственности.
• Всегда делайте разрезы: клиент/маршрут/тип ТС/склад/перевозчик - иначе KPI в логистике будет слишком усреднённым.
• Контролируйте качество исходных данных: пропуски и неверные статусы событий дают более сильные искажения, чем сама формула.

Выбор метрик: стоимость на тонну и её ограничения

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

Когда не стоит делать основной. Если сильно различаются плотность груза, паллетность, требования к температуре/временным окнам, доля возвратов и ожиданий, то стоимость/тонна начнёт поощрять неправильные решения (например, отказ от сложных, но маржинальных клиентов).

Примеры формул для стоимости на тонну (с допущениями)

1. Базовый вариант (перевозочная часть). Стоимость/тонна = (сумма затрат на рейсы за период) / (сумма отгруженных тонн). Допущение: в затрат включены только переменные перевозки (фрахт, топливо, платные дороги), без складских и административных.
2. С разнесением на плечо. Стоимость/тонна-км = затраты / (тонны × км). Допущение: корректно измеряются фактические км (не плановые), иначе KPI будет наказывать за ошибки маршрутизации в данных.
3. Для сборных/паллетных грузов. Стоимость/условную единицу = затраты / (паллето-места или куб.м). Допущение: у вас стабильно и одинаково учитывается объём/паллетность, иначе сравнение периодов будет некорректным.

Контрольные точки риска для unit-cost метрик

• Проверьте, не "едят" ли KPI возвраты и холостые пробеги: если они не попадают в знаменатель, себестоимость будет выглядеть лучше, чем есть.
• Отделите внешнего перевозчика от собственного парка: смешение скрывает рост затрат на ремонты/простои.
• Заранее решите, как учитывать частично выполненные рейсы и отмены (иначе будет манипулирование списаниями).

Метрика	Упрощённая формула	Частота	Источник данных	Риск искажения	Управленческое влияние
Стоимость/тонна	Затраты на перевозку / тонны	Неделя/месяц	TMS, финучёт, акты	Смешение плеч/типов грузов, невключённые возвраты	Тарифы, выбор перевозчика, оптимизация маршрутов
Cost-to-Serve	Выручка − (перевозка + склад + обработка + возвраты)	Месяц/квартал	ERP, WMS, TMS, CRM	Неверные драйверы аллокаций, неполные косвенные	Сегментация клиентов, условия сервиса, минимальные партии
SLA по срокам доставки	Доля доставок в обещанный срок	День/неделя	TMS, статусы POD/сканы	Нечёткое обещание срока, ручные статусы, отсутствие исключений	Корректировка расписаний, буферы, эскалации
Простои	Минуты ожидания на точках / рейс (или % рейсов с простоем)	День/неделя	TMS, телематика, тайм-слоты, охрана/КПП	Нет точек входа/выхода, разное понимание прибыл	Договоры слотов, штрафы/мотивация, перепланирование

Cost-to-Serve: методика расчёта и сегментация клиентов

Cost-to-Serve нужен, чтобы видеть не "среднюю логистику", а прибыльность обслуживания конкретных клиентов/каналов/ассортимента. Практически это управляемая модель распределения затрат по драйверам: заказы, строки, паллеты, километры, возвраты, ожидания.

Что понадобится (доступы, инструменты, требования)

• Данные. Заказы и отгрузки (ERP/OMS), операции склада (WMS), рейсы и статусы (TMS), претензии/возвраты, прайсы и скидки, фактические затраты (финучёт).
• Единые справочники. Клиент, точка доставки, маршрут/зона, номенклатура, тип сервиса, перевозчик, тип ТС.
• Модель аллокации. Правила разнесения: какие затраты прямые (по рейсу/перевозчику), какие косвенные (склад, планирование, диспетчеризация) и их драйверы.
• Инструмент. На старте достаточно BI+выгрузок, но критично: версионирование правил и возможность пересчёта периода при изменении драйверов.

Примеры расчёта Cost-to-Serve для управленческих решений

1. CTS по клиенту как P&L обслуживания. CTS(клиент) = выручка − (перевозка + складская обработка + упаковка + возвраты/рекламации + премиальный сервис). Допущение: выручка берётся после скидок, а логистика - по факту, а не по плану.
2. CTS на заказ (для управляемых рычагов). CTS/заказ = (перевозка по рейсу × доля заказа) + (складские операции × ставка за операцию) + (обработка претензий × ставка). Допущение: доля заказа в рейсе определяется корректно (по весу/объёму/паллетам - фиксируете одно).
3. Сегментация для решений. Сегментируйте клиентов по двум осям: маржинальность после CTS и уровень сервиса (частота доставок, окна, возвраты). Допущение: сервисные атрибуты измеряются одинаково для всех каналов.

Контрольные точки риска при аллокации затрат CTS

• Не начинайте с "идеальной" детализации: сначала 5-10 драйверов, затем уточняйте, иначе модель станет недоверенной и неиспользуемой.
• Отдельно фиксируйте "исключения" (форс-мажор, закрытие дорог, сезонные ограничения) - но по правилам, а не вручную.
• Сверяйте сумму распределённых затрат с финучётом на период (контроль полноты и двойного учёта).

SLA по срокам доставки: формулировка и контроль показателей

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

Риски и ограничения перед настройкой SLA

• Разные определения "доставлено": по POD, по скану на воротах, по закрытию рейса в TMS - выберите одно.
• Срок "в днях" без cut-off и календарей (выходные/праздники) создаёт систематические ложные просрочки.
• Ручные статусы без логов исправлений приводят к подгонке KPI под премию.
• Нет классификации причин отклонений: тогда нельзя отделить управляемые сбои от внешних.

1. Зафиксируйте обещание срока (объект SLA).
   Опишите, что именно обещаете: дата/время доставки, интервал, "D+N до конца дня", и для каких типов заказов.
   • Определите cut-off времени заказа (например, до какого часа заказ попадает в отгрузку текущего дня).
   • Задайте календарь: рабочие/нерабочие дни и правила переносов.
2. Определите точки измерения времени.
   Минимум: время подтверждения заказа, время выезда, время прибытия на точку, время подтверждения доставки (POD).
   • Закрепите, откуда берётся таймстамп (TMS/телематика/сканер) и приоритет источников при конфликте.
3. Согласуйте допустимые исключения и коды причин.
   Составьте список исключений, которые выводятся из SLA (или учитываются отдельно): запрет проезда, закрытие склада клиента, неверный адрес, перенос по просьбе клиента.
   • Запретите свободный текст без справочника причин: иначе аналитика становится бесполезной.
4. Выберите показатель и правило агрегации.
   Практика: доля доставок в срок и отдельно распределение опозданий по "корзинам" (например, до X часов, более X часов - задайте X сами).
   • Сразу решите, как считать частичные доставки и повторные попытки.
5. Настройте контроль качества данных.
   Введите проверки: пропущенные статусы, доставки без POD, отрицательные интервалы времени, дубли рейсов.
   • Определите, кто исправляет данные и за сколько времени после события.
6. Опишите действия при отклонениях (runbook).
   Для каждого типа нарушения SLA назначьте владельца и действие: эскалация перевозчику, корректировка расписания, пересмотр буферов, изменение тайм-слотов.
7. Запустите пилот и зафиксируйте базовую линию.
   2-4 недели в одном регионе/канале, затем расширение. На пилоте не "улучшайте" метрику ручными правками - улучшайте процесс и данные.

Примеры формулировок SLA (шаблоны)

• D+1 до 18:00 при заказе до cut-off. Подходит для региональных доставок с предсказуемым плечом. Допущение: на складах соблюдаются окна отгрузки.
• Интервал 2 часа для городской доставки. Подходит для B2C/ритейла. Допущение: есть система тайм-слотов и подтверждение прибытия.
• OTIF отдельно от сроков. Если у вас частые недопоставки, разделяйте: "в срок" и "в полном объёме". Допущение: есть корректные данные по факту приемки.

KPI по простоям и простоям техники: как измерять потерянное время

kpi по простоям транспорта измеряет потери времени на точках погрузки/разгрузки и в пути, которые превращаются в прямые затраты (смена, топливо, штрафы, недовыпуск рейсов) и косвенные (срыв SLA). Начните с минимально проверяемой модели: прибытие → начало операции → окончание → выезд.

Примеры расчёта простоев транспорта (с допущениями)

1. Простой на точке. Простой = (время начала операции − время прибытия) + (время выезда − время окончания операции). Допущение: фиксируются 4 таймстампа, иначе делайте упрощение и явно его обозначайте.
2. Доля рейсов с превышением норматива. % рейсов, где простой > норматив по точке/типу операции. Допущение: нормативы различаются по складам и типам ТС, а не один "средний".
3. Потерянная производительность парка. Потерянные часы = сумма простоев; конверсия в управленческий эффект - через недовыполненные рейсы/смены (без жёстких коэффициентов, если нет проверенной модели).

Проверка результата: чек-лист качества метрики

• Есть единое определение "прибытия" и "выезда" (геозона/КПП/скан) и оно одинаково для всех площадок.
• Норматив простоя задан по типу точки (погрузка/разгрузка), типу ТС и режиму (слот/без слота).
• Простои в пути отделены от простоев на точке (иначе вы лечите не тот процесс).
• Есть справочник причин простоя и правило, какие причины считаются управляемыми.
• Данные защищены от "задним числом": виден лог правок статусов или используется автоматическая телематика.
• Отчёт строится в разрезе: склад/клиент/перевозчик/смена/ворота.
• При отклонении известен следующий шаг: кого уведомлять, какие слоты/ресурсы менять, какие санкции/бонусы применять.
• Метрика не конфликтует со SLA: улучшение простоя не должно ухудшать срок (например, за счёт отказа от раннего прибытия при очередях).

Связь операционных KPI с финансовыми целями и рисками

Операционные показатели должны переводиться в деньги через понятные рычаги: тарифы, загрузка ТС, повторные доставки, возвраты, производительность склада. Иначе KPI в логистике становятся "спортом ради отчёта" и создают скрытые потери.

Типовые ошибки, которые ломают управляемость

• Премирование за один KPI без ограничителей (например, снижение стоимости/тонна любой ценой) приводит к падению SLA и росту возвратов.
• Смешение плановых и фактических данных в одной формуле: KPI становится нечестным и не повторяемым.
• Нет классификации причин отклонений: подразделения спорят, а процесс не улучшается.
• Слишком редкий расчёт (только месяц) для показателей, где нужна ежедневная реакция (SLA, простои).
• Метрика без владельца и без RACI: "все отвечают" = не отвечает никто.
• Единый норматив на разные сегменты (маршруты/клиенты): вы наказываете сложные, но прибыльные сценарии.
• Усреднение по периоду без учёта сезонности/кампаний: "ухудшение KPI" может быть нормальным эффектом бизнеса.
• Отсутствие контроля качества данных: KPI отражает дисциплину статусов, а не работу логистики.

Практические привязки к финансовым решениям (примеры)

• Cost-to-Serve → условия сервиса. Если сегмент убыточен после расчет cost to serve, корректируйте частоту доставок, минимальную партию, тайм-слоты, платность срочности.
• Простои → пропускная способность. Если простои концентрируются на 1-2 площадках, финансовый эффект чаще достигается изменением расписания/окон и процессом на воротах, а не сменой перевозчика.
• SLA → штрафы/бонусы и буферы. Разделяйте нарушения по вине перевозчика и по вине склада/клиента, иначе штрафная модель будет разрушать партнёрство и ухудшать доступность транспорта.

Внедрение, мониторинг и корректировка KPI: практический план

Внедряйте KPI как управленческий цикл: определения → данные → отчёт → действие → аудит. Это снижает риск "рисования" показателей и делает метрики инструментом, а не спором о цифрах.

Базовый план внедрения (безопасная последовательность)

1. Словарь метрик. Для каждой метрики: цель, формула, разрезы, период, владелец, источник, правила исключений, действие при отклонении.
2. Проверка данных. Минимальные тесты: полнота событий, дубли, крайние значения, согласование справочников.
3. Пилотный контур. Один регион/склад/канал, фиксированные правила, еженедельный разбор отклонений с конкретными задачами.
4. Согласование мотивации. Сначала прозрачность и доверие к данным, затем - привязка к бонусам с защитными ограничителями (например, SLA как гейт).
5. Регулярная корректировка. Раз в квартал пересматривайте нормативы, драйверы CTS и перечень исключений; изменения версионируйте.

Альтернативные варианты, когда уместны

• Если данных мало или они "грязные". Начните с 2-3 метрик, которые можно автоматизировать (SLA по событию POD и простои по геозонам), а Cost-to-Serve делайте укрупнённо по зонам/каналам.
• Если высокий аутсорс перевозок. Делайте акцент на SLA и простоях как на управлении поставщиком, а стоимость/тонна используйте для переговоров и тендеров (в разрезе сопоставимых плеч).
• Если много индивидуального сервиса клиентам. Ставьте Cost-to-Serve в центр и формируйте "меню сервиса"; SLA фиксируйте по уровням сервиса, а не одной нормой на всех.
• Если основной узкий участок - склад. Углубляйте драйверы складской обработки в CTS и вводите отдельные операционные метрики склада, а транспортные держите как контрольные.

Разбор типичных сомнений и рисков при KPI-метриках

Можно ли ограничиться только стоимостью перевозки за тонну расчет?

Можно для базового контроля перевозок, но вы не увидите влияние сервиса и сложности клиента. Для управленческих решений добавьте хотя бы SLA и простои, а для коммерческих - cost-to-serve.

Почему расчет cost to serve часто вызывает споры с коммерцией?

Обычно из-за непрозрачных драйверов распределения и разного понимания уровня сервиса. Лечится фиксированными правилами аллокации, версионированием и разбором на конкретных заказах.

Как задать sla в логистике по срокам доставки, если клиент постоянно переносит окна?

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

Что делать, если KPI по простоям показывает рост, а команда уверена, что стало лучше?

Проверьте качество таймстампов (смена источника, геозоны, ручные правки) и разрезы (на каких точках рост). Часто "ухудшение" - это просто более честные данные после настройки фиксации событий.

Как избежать подгонки статусов под KPI?

Минимизируйте ручной ввод, ведите лог правок и вводите проверки аномалий (отрицательные интервалы, статусы задним числом). Плюс разделяйте KPI для мониторинга и KPI для мотивации на этапе внедрения.

Нужно ли привязывать бонусы к KPI сразу?

Нет: сначала добейтесь стабильности определений и данных на пилоте. После этого вводите мотивацию с защитными ограничителями, чтобы не "убить" SLA ради себестоимости.