Для поставщика продуктов спор по OTIF обычно начинается в момент, когда товар уже доставлен, а сеть всё равно фиксирует сбой. Машина приехала в тот же день, но вышла за окно приёмки. Количество совпало по накладной, но сеть считает полноту по другой единице. Один заказ закрыли двумя поставками, а в отчёте каждая прошла как отдельное нарушение. В итоге проблема возникает не только в логистике, но и в том, как именно сеть считает показатель.

OTIF — не про сам факт приезда машины на РЦ или в магазин. Это On-Time In-Full: доля поставок, выполненных точно в срок и в полном объёме, от общего числа заказов. Для зачёта нужны сразу два условия: поставка попала в согласованное окно приёмки, а объём приняли по методике, зафиксированной в SLA. Если хотя бы одно условие не выполнено, заказ обычно выпадает из числителя.

Главный источник конфликтов один: одну и ту же поставку можно посчитать по-разному. Если заранее не закрепить окно приёмки, единицу расчёта In-Full и статус частичных поставок, у сети и поставщика получатся разные цифры при одних и тех же фактах. Поэтому OTIF в продуктовом ритейле — одновременно контрактный и операционный показатель. Его защищают не общими словами про сервис, а точной методикой, документами и сверкой данных.

Что такое OTIF и почему по нему так часто спорят

OTIF — это On-Time In-Full: доля поставок, выполненных точно в срок и в полном объёме, от общего числа заказов. Для продуктового ритейла показатель важен потому, что сеть связывает с ним доступность товара на полке, планирование приёмки и штрафные механики. Для поставщика смысл другой: по OTIF оценивают качество исполнения заказа и часто принимают решения по претензиям, переговорам и условиям работы.

Спор возникает из-за того, что OTIF требует одновременного выполнения двух условий. On-Time — это выполнение поставки в согласованное окно приёмки, указанное в договоре, слоте или ASN. In-Full — полнота поставки по методике, зафиксированной в SLA: по заказу, строкам заказа или количеству единиц. Поставка, которая приехала вовремя, но с недостачей, OTIF не выполняет. Аналогично не засчитывается полный заказ, если он пришёл вне окна.

Расхождение начинается там, где стороны по-разному понимают единицу расчёта. Одни сети считают OTIF по заказам целиком, другие — по строкам, позициям, штукам или паллетам; без фиксации в SLA возникают споры. При расчёте по заказу целиком даже небольшая недопоставка может обнулить вклад всего заказа. При расчёте по строкам картина другая: часть заказа может пройти, а часть — нет.

На практике из-за этого рождается миф, что OTIF — просто процент вовремя приехавших машин. Для продуктовой сети такой подход слишком грубый. Машина может приехать без опоздания, но выгрузить не тот объём, не ту комплектацию или товар с неподходящим остаточным сроком. Формально транспорт сработал, а OTIF у заказа всё равно не выполнен.

Как рассчитать OTIF: формула и логика показателя

Базовая формула одна: OTIF = (число заказов с доставкой «точно в срок» и «полностью») / (общее число заказов) × 100%. В знаменателе — все заказы, попавшие в базу расчёта за период. В числителе — только те, где одновременно выполнены оба условия: поставка пришла в окно приёмки и принята в полном объёме по согласованной методике.

Логика расчёта жёстче, чем кажется в отчёте. Если у вас было десять заказов и только восемь прошли и по времени, и по полноте, в OTIF попадут именно эти восемь. Два заказа, где было опоздание или недопоставка, не дают частичного зачёта, если сеть считает показатель по заказу целиком. Поэтому внутренний комментарий «почти всё доехало» для расчёта обычно ничего не меняет.

Ошибку поставщики допускают в двух местах:

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

Средний показатель за месяц или квартал может не совпадать с расчётом сети, если она оценивает каждый заказ отдельно.

Короткий пример показывает, почему цифры расходятся. Допустим, за период было несколько заказов, и по внутреннему учёту почти все машины приехали в день отгрузки. Но часть из них попала на приёмку позже слота, а в одной поставке не хватило нескольких коробов. Для логистики движение выглядит нормальным, а в формуле сети такие заказы не проходят в числитель. Поэтому считать нужно только по правилам сети и по тем событиям, которые сеть признаёт фактом исполнения заказа.

Что сеть считает On-Time: окно приёмки, ASN и переносы

В OTIF время считают не по календарной дате и не по ощущению, что машина прибыла без критической задержки. On-Time обычно определяют по окну приёмки, указанному в договоре или ASN. Если слот был с утра, а фактическая приёмка прошла позже, заказ может получить сбой даже тогда, когда товар привезли в тот же день и склад его принял.

Для поставщика здесь важны три опорные точки:

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

В одних схемах это регистрация на воротах, в других — время первого скана или начало приёмки. Если этот момент не сверить заранее, одна сторона будет считать прибытие по GPS или отметке водителя, а другая — по времени в WMS. Дальше разница превращается в формальное опоздание.

Особенно часто спор возникает при переносах. Любой перенос окна должен быть подтверждён письменно или в системе; устные договорённости повышают риск спора по On-Time. Если менеджер сети согласовал сдвиг по телефону, а в слоте осталось старое время, в отчёте почти наверняка останется просрочка. Для оспаривания потом придётся собирать переписку, скриншоты и журналы событий.

Типовой конфликт выглядит так: сеть меняет окно приёмки за сутки или в день поставки, поставщик перестраивает маршрут, но подтверждение в системе не появляется. Машина приезжает по новой договорённости, а отчёт сравнивает её со старым окном. Другой частый случай — товар привезли в тот же день, но за пределами слота, и поставщик считает это допустимым, потому что полка не пострадала. Для OTIF этого обычно недостаточно: выход за согласованное окно приёмки считается сбоем, даже если товар привезли в тот же день.

Рабочее правило простое: спорить нужно не о том, «мы же приехали сегодня», а о подтверждённом окне и признанном времени события. Если сеть использует ASN, проверяйте именно тот слот, который действует в системе на момент поставки. Если перенос согласован, добивайтесь следа в переписке, тикете, EDI или ином канале, который можно приложить к претензии.

Что считается In-Full: заказ, строки, штуки и паллеты

Вторая половина OTIF ломается чаще и тише. Поставщик видит, что основная масса товара доехала, и считает заказ почти исполненным. Сеть смотрит на методику SLA и принимает решение по другой единице. In-Full может считаться по заказу, строкам заказа или количеству единиц; методика должна быть зафиксирована в SLA.

Разница между заказом, строкой, штукой, коробом и паллетой влияет на итог сильнее, чем сам размер недопоставки. Если сеть считает по заказам целиком, даже минимальная недопоставка может обнулить вклад заказа в числитель OTIF. Если расчёт идёт по строкам, недостача в одной позиции не всегда валит все остальные. Если база построена по паллетам, расхождение в нескольких коробах внутри паллеты могут трактовать иначе, чем при учёте по штукам.

Отдельный слой споров связан с частичными поставками. В одной сети заранее согласованная недопоставка может считаться допустимой, в другой тот же сценарий уйдёт в провал по In-Full. Здесь нет противоречия: одно и то же свойство даёт разный результат не само по себе, а из-за разной базы расчёта и договорных правил. Если эти правила не закрепить заранее, одинаковый фактический сценарий даст разные цифры OTIF.

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

Для скоропорта критерий полноты иногда выходит за рамки количества. In-Full иногда оценивают с учётом остаточного срока годности на момент приёмки. Формально коробки и штуки совпадают, но сеть может не принять поставку как полную, если товар не проходит по сроку. В результате заказ будет выглядеть закрытым по объёму в накладной и проблемным в OTIF.

Есть и недооценённый нюанс — операционные требования склада. Даже при полном количестве поставка может не пройти так, как ожидал поставщик, если нарушены маркировка паллет, очередность выгрузки или состав транспортной единицы. Это не всегда меняет In-Full напрямую, но часто влияет на приёмку и на то, какие данные попадут в систему как принятый объём.

Где поставщики теряют OTIF не по факту, а из-за методики и данных

Часть потерь по OTIF происходит не на маршруте и не на складе отгрузки, а в точке фиксации данных. Методика расчёта OTIF часто прописана в приложениях к договору мелко и может меняться без явного уведомления. Если команда опирается на старую версию SLA, внутренний учёт будет показывать одну картину, а отчёт сети — другую. Поэтому проверять нужно не только KPI, но и текст приложения, по которому KPI считают.

Вторая зона риска — автоматический расчёт. Во многих системах OTIF считают автоматически по сканам и данным WMS, а ошибки сканирования оспаривать трудно. Поставщик может видеть прибытие машины вовремя, но система сети зафиксирует событие позже: например, по первому скану после ожидания на воротах. Формально просрочка уже появилась, хотя с точки зрения транспорта машина приехала в слот.

Если не хранить собственный таймлайн событий по каждой машине — прибытие, регистрация на РЦ, подача к воротам, начало выгрузки, первый скан, завершение приёмки, — нормальная поставка легко превращается в просрочку на стороне сети, и оспаривать её потом почти нечем.

Отдельно стоит следить за расхождениями между WMS сети и вашей ERP. Частая ошибка — не сверять данные WMS сети и своей ERP перед подписанием актов приёмки. Если в системе сети принят иной объём, другой состав строк или другое время события, исправление потом затягивается. А пока идёт разбор, спорный заказ уже влияет на отчётный период.

Есть и более тонкие искажения. Один заказ могут разделить на несколько поставок, и тогда важно понимать, что именно попадает в базу расчёта: весь заказ или каждая отгрузка отдельно. В некоторых моделях OTIF считают раздельно по распределительным центрам и по магазинам, а поставщик видит только агрегат и не понимает, где именно просадка. Наконец, проблемы с маркировкой, очередностью выгрузки и идентификацией паллет иногда выглядят как складская мелочь, но в отчёте дают просрочку или недовложение.

Как защитить свой OTIF: что закрепить в договоре и в операционке

Защита OTIF начинается не с претензии, а с формулировок в договоре и SLA. Целевой OTIF в продуктовом ритейле часто находится в диапазоне 95–98%, но конкретный порог зависит от контракта и категории товара; в реальных контрактах встречаются значения от 90% до 99%. Сам по себе порог ещё ничего не решает. Критична методика: по какой базе считают показатель, какое событие признают временем поставки и в каких единицах оценивают полноту.

В договорных приложениях стоит закрепить не общие слова, а конкретные правила расчёта:

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

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

Операционная часть не менее важна. Нужен единый маршрут доказательств: подтверждение слота, ASN, переписка о переносе, отметки прибытия, данные GPS, регистрация на РЦ, акты и результат приёмки. Чем раньше команда сверяет свои события с данными сети, тем меньше шансов, что ошибка скана или неподтверждённый перенос уйдут в закрытый отчёт. Это особенно важно для скоропорта и поставок с частичной заменой объёма.

Штрафной блок тоже нужно читать буквально. В отдельных крупных сетях РФ встречается практика штрафных баллов за каждый процент ниже порога OTIF, но единого отраслевого стандарта нет. Поэтому полезнее спорить не с самим KPI как с идеей, а с базой расчёта, составом исключений и доказательствами по конкретным заказам. Там, где методика прозрачна, спор быстро становится предметным. Там, где в приложении много лакун, OTIF превращается в постоянный источник ручных конфликтов.

Хороший рабочий минимум выглядит так:

• зафиксировать событие, по которому считается On-Time;
• прописать единицу расчёта In-Full: заказ, строка, штука, короб или паллета;
• описать правила для частичных поставок, дозаказов и дробления заказа;
• согласовать исключения из базы расчёта, включая форс-мажор и подтверждённые переносы;
• назначить регулярную сверку данных сети и внутренних систем до закрытия периода.

Часто задаваемые вопросы

Ниже — пограничные случаи, на которых OTIF чаще всего расходится между поставщиком и сетью. Именно в них лучше заранее закреплять правила в SLA, а не разбирать конфликт после закрытия месяца.

Как считать OTIF, если один заказ привезли несколькими машинами?

Ответ зависит от базы расчёта, и её нужно закрепить заранее. Если сеть считает OTIF по заказу целиком, то несколько машин обычно рассматриваются как один заказ с единым результатом: он пройдёт только тогда, когда весь объём будет доставлен в срок и в полном объёме по правилам SLA. Если сеть считает каждую поставку отдельно, дробление может ухудшить показатель, потому что каждая машина получает собственную оценку по окну и полноте.

На практике это один из самых опасных пограничных кейсов. В договоре стоит прямо указать, что считают объектом расчёта: заказ, поставку, ASN или отдельную отгрузку. Там же полезно прописать, допускается ли плановое дробление и как учитывают довоз остатка. Иначе одна сторона будет считать логистически один заказ, а другая — несколько сбоев.

Можно ли не включать в OTIF поставки, сорванные из-за форс-мажора?

Можно только тогда, когда исключения из базы расчёта описаны в договоре или SLA и подтверждены документами. Само по себе объяснение про аварию, поломку рефрижератора или дорожную ситуацию редко срабатывает автоматически. Для сети важно не объяснение, а формальное основание исключить заказ из расчёта.

Рабочий порядок такой: сразу фиксировать событие, собирать подтверждения и направлять уведомление в согласованный канал. Если есть правило об исключениях, спор строится вокруг применимости этого правила к конкретному заказу. Если правила нет, заказ чаще остаётся в базе OTIF, даже когда причина сбоя для поставщика очевидна и объективна.

Как считать OTIF для скоропортящихся продуктов с остаточным сроком годности?

Для скоропорта одного совпадения по количеству недостаточно. In-Full иногда оценивают с учётом остаточного срока годности на момент приёмки. Поэтому поставка может выглядеть полной по штукам и коробам, но не пройти по In-Full, если остаточный срок не соответствует правилам сети или категории товара.

Здесь полезно сверять три вещи ещё до отгрузки:

• требования сети к остатку срока;
• фактический срок по партии;
• то, как сеть фиксирует отклонение при приёмке.

Если правило о сроке связано с методикой OTIF в документах, позже появится спор: сеть сочтёт поставку неполной, а поставщик — полной, но с отдельным качественным замечанием.

Что делать, если сеть и поставщик видят разный OTIF по одним и тем же заказам?

Начинать нужно не с общего процента, а с уровня конкретного заказа. Сначала сопоставляют идентификатор заказа, ASN, окно приёмки, фактическое время события, принятую единицу измерения и объём по строкам. Потом проверяют, какое событие дало статус On-Time и по какой единице считался In-Full: по заказу, строкам, штукам или паллетам. Во многих случаях источник расхождения находится уже на этом этапе.

Для претензии или акта разногласий лучше собирать пакет в одной логике: договор и SLA, подтверждение слота, переписку о переносе, накладные, акт приёмки, данные WMS сети и данные вашей ERP. Если проблема во времени, ключевыми будут журналы прибытия, регистрации и сканов. Если спор по объёму, важнее состав строк, единицы измерения и документы, где видно согласованное изменение заказа. Такой порядок обычно быстрее приводит к исправлению, чем спор о месячном KPI целиком.