OTIF кажется однозначным показателем: поставка должна быть выполнена вовремя и в полном объёме. На практике логистика, продажи и финансы могут честно рассчитать три разных значения, потому что используют разные события, временные окна и требования к полноте.
Спор нельзя решить одной формулой, выбранной сверху. Сначала нужно описать назначение каждой версии показателя, её источник данных и управленческий вопрос. После этого разные значения перестают быть ошибкой и становятся согласованной системой контроля цепочки поставок.
Дальше — три практические версии OTIF, которые можно встретить в ритейле, производстве и дистрибуции. Задача не в том, чтобы выбрать одну «правильную». Важно понять, какая версия нужна для управления цепочкой поставок, какая отражает выполнение обещания клиенту, а какая помогает контролировать финансовое закрытие. Тогда разные значения OTIF перестают противоречить друг другу: каждое отвечает на свой управленческий вопрос.
Версия 1. Операционный OTIF логистики измеряет работу цепочки, а не опыт клиента
Для логистики OTIF прежде всего показывает, насколько управляем сам процесс: выдерживают ли склад, транспорт и планирование заданные условия поставки. Поэтому в расчёте используют событие, которое цепочка может объективно зафиксировать и на которое способна влиять. Это может быть завершение поставки или доставка товара, а в некоторых B2B-сценариях — передача перевозчику или отгрузка со склада. Логика проста: склад и транспорт опираются на события в своих системах и отделяют их от того, как и когда клиент оформляет приёмку.
Окно on time в такой модели тоже связано с операцией: это может быть слот, день или допустимое отклонение по времени. Например, если доставка назначена на 10:00–14:00, она считается своевременной, когда машина приезжает в этот интервал и соответствующее событие фиксируется в системе. Если документы клиент подпишет позже, это уже отдельное отклонение, которое не обязательно должно менять операционный OTIF. Такая версия помогает принимать конкретные решения: перераспределять маршруты, менять cut-off — предельное время приёма заказа в обработку, разгружать узкие места на сборке или корректировать график отгрузки.
Правило in full в операционном OTIF обычно связано с тем, что фактически выходит со склада: строками заказа, SKU и количеством. Но и здесь правила могут различаться. В одной компании полнота означает 100% заказа без замен, в другой допустимы эквивалентные замены или частичная поставка с последующей допоставкой. Формально обе компании считают OTIF, но измеряют немного разную дисциплину процесса. Поэтому само правило полноты должно быть зафиксировано так же явно, как событие и временное окно.
Конфликт возникает, когда операционный OTIF начинают использовать как универсальный показатель для логистики, продаж и клиентского сервиса. Логистика говорит: «мы доставили вовремя по согласованному слоту», а продажи отвечают: «клиент не получил товар к запуску промо, значит поставка была несвоевременной». В своей логике правы обе стороны. Просто они измеряют разные события и разные обещания. Поэтому ситуация, когда внутренний OTIF высокий, а оценка поставки со стороны клиента заметно ниже, не обязательно означает ошибку в расчёте. Сначала нужно проверить, одинаково ли определены событие, окно и полнота.
Версия 2. Клиентский OTIF продаж измеряет обещание, а не факт движения по складу
Продажи и коммерция смотрят на OTIF иначе. Для них важно не столько то, насколько стабильно работает цепочка поставок сама по себе, сколько выполнено ли обещание конкретному клиенту: к открытию магазина, запуску промо, старту производства или поставке в сеть. Поэтому on time в этой версии обычно привязан к дате из заказа, договора или клиентского календаря. Это может быть не точный слот, а день или неделя. В B2B такая дата нередко связана со штрафами и удержаниями, в ритейле — с выходом товара на полку или запуском промо.
Событие «доставлено» в клиентском OTIF должно быть максимально близко к тому, что сам клиент считает фактом выполнения поставки. Это может быть приёмка на распределительном центре, подтверждение по EDI или подписанный документ. Причём такое событие не всегда находится в логистической системе. Оно может фиксироваться в CRM, EDI или другом контуре. Отсюда и возникает типичный разрыв: у логистики есть GPS и статус «доставлено», а у продаж — информация, что клиент не принял поставку из-за неполного комплекта документов. Для склада и транспорта операция завершена успешно, а с точки зрения клиента обещание не выполнено.
Правило полноты здесь тоже может отличаться от складского. Клиент оценивает не только то, все ли строки заказа физически приехали, а может ли он решить свою задачу: запустить полку, производство или продажу. В одном случае критична полная комплектация, в другом важнее наличие конкретных SKU, а часть позиций допустимо довезти позже. Поэтому клиентский OTIF может учитывать критические позиции, допустимые замены и допоставки. Расчёт становится сложнее, но лучше отражает реальный риск для клиента.
Если компания оценивает удержание клиентов и штрафные риски, но считает OTIF только по логистическому слоту и складским строкам, легко получить ситуацию, когда внутренний показатель зелёный, а клиент недоволен. Здесь не нужно искусственно «снижать OTIF». Нужно отдельно зафиксировать клиентскую версию и определить её как KPI выполнения обещания клиенту. Тогда логистика продолжает использовать операционный OTIF для управления процессом, а коммерция — клиентский OTIF для управления рисками в отношениях с клиентом.
Версия 3. Финансовый OTIF измеряет закрытие периода и признание выручки
У финансов другой фокус. Для них важно, чтобы отгрузки и поставки корректно закрывались в учёте и не требовали постоянных ручных исправлений. Поэтому в финансовой логике OTIF может быть связан не столько с клиентским опытом или работой склада, сколько с предсказуемостью закрытия периода. Здесь важны дата реализации, момент перехода права собственности, наличие закрывающих документов, корректность цены и количества. Там, где логистика видит «успешно доставлено», финансы могут видеть незакрытую операцию из-за неподписанного документа или расхождения в данных.
On time в такой версии обычно привязан к календарю финансового закрытия. Если операция не закрыта в нужном периоде, появляются корректировки, переносы выручки и дополнительная ручная работа. Поэтому отдельно имеет смысл смотреть как минимум два типа отклонений: задержки документов и расхождения в данных. По сути вопрос остаётся тем же: удалось ли закрыть операцию вовремя и полностью.
Полнота здесь означает уже не только количество товара. Важна и полнота учётных данных: корректный договор, цена, единицы измерения, накладные, подтверждения EDI и другие обязательные реквизиты. Поэтому финансовая версия OTIF может частично пересекаться с показателями качества данных. Если события и документы фиксируются неполно или с ошибками, это превращается в ручные корректировки и проблемы при закрытии периода.
Если смешать финансовый и клиентский OTIF в одном показателе, снова появляется ложный конфликт. Клиент мог получить товар вовремя и быть доволен поставкой, а финансовый контур останется красным из-за неподписанного акта или расхождения по цене. Это не обязательно проблема логистики или продаж. Это отдельная зона управления — качество данных, документов и учётного закрытия.
Почему OTIF расходится: событие, окно поставки и полнота
Когда у логистики, продаж и финансов получается разный OTIF, причина обычно в одном из трёх параметров: событии, временном окне или правиле полноты.
Первое — событие. Что именно считается фактом поставки: отгрузка со склада, прибытие машины, приёмка клиентом или закрывающий документ. Если подразделения используют события из разных систем — ERP, WMS, TMS, EDI или учётного контура, — один и тот же заказ закономерно получает несколько дат. Проблема не в самих датах, а в том, что за ними стоят разные смыслы, которые не были заранее зафиксированы.
Второе — окно. Для логистики это может быть конкретный слот или день доставки. Для продаж — дата обещания клиенту, связанная с запуском промо, производства или другой бизнес-задачей. Для финансов — срок закрытия операции в отчётном периоде. Если окна отличаются, различаться будет и OTIF. Попытка свести их к одному универсальному правилу часто только ухудшает ситуацию: логистика теряет инструмент управления процессом, продажи — сигнал клиентского риска, финансы — контроль закрытия.
Третье — полнота. В операционном OTIF она может означать полный заказ по строкам и количеству. В клиентском — наличие всех критически важных позиций. В финансовом — совпадение количества, цены и закрывающих документов. Это разные правила, и каждое отвечает на свой управленческий вопрос.
Если эти различия не описаны в модели, BI начинает компенсировать их на уровне отдельных отчётов. Появляются исключения, ручные корректировки, особые правила для отменённых строк, замен и допоставок. В итоге формула OTIF живёт внутри конкретного отчёта, а не в общей модели показателей. Тогда обсуждение снова сводится к тому, кто и как посчитал цифру, вместо разговора о причинах отклонения.
Как построить единую модель OTIF для логистики, продаж и финансов
Единая модель OTIF начинается не с дашборда, а с определения того, какие версии показателя действительно нужны бизнесу и для каких решений они используются. Базово можно разделить операционный, клиентский и финансовый OTIF. При необходимости могут появляться и дополнительные версии, например для планирования цепочки поставок. Важно другое: каждая из них должна отвечать на конкретный управленческий вопрос, а не существовать просто потому, что её можно посчитать.
Для каждой версии нужно зафиксировать три вещи: событие, окно и полноту.
Событие важно описывать не общими словами вроде «дата доставки», а через конкретный бизнес-факт и источник данных. Например: «дата приёмки товара клиентом на распределительном центре, подтверждённая через EDI» или «дата выпуска отгрузки из WMS». Чем точнее определено событие, тем меньше пространства для спора о том, какую дату считать правильной. Оставшиеся разногласия уже касаются не самой цифры, а того, какое событие действительно отражает ответственность конкретной функции.
Окно нужно определить так же явно. Для операционного OTIF это может быть согласованный слот с допустимым отклонением по времени, для клиентского — дата из заказа или договора, для финансового — срок закрытия операции в отчётном периоде. Эти окна не обязаны совпадать: у каждой версии своя задача.
Полнота тоже должна быть превращена из общего выражения «в полном объёме» в конкретное правило. Для одной версии это может быть полный заказ без замен, для другой — наличие всех критических SKU с возможностью последующей допоставки остальных позиций, для третьей — полный комплект документов и отсутствие расхождений по цене и количеству. Когда событие, окно и полнота формализованы для каждой версии, OTIF перестаёт быть спорной цифрой и становится управляемой системой показателей.
Как избежать споров о расчёте OTIF
Есть несколько типовых ошибок, из-за которых OTIF быстро превращается из управленческого показателя в предмет споров.
Первая — смешивать разные версии в одном числе. Если в один KPI одновременно попытаться включить логистический слот, дату обещания клиенту и финансовое закрытие периода, показатель теряет управленческий смысл. Он может стать красным из-за неподписанного документа, хотя сама поставка прошла без сбоев, или остаться зелёным, хотя клиент получил заказ позже нужной даты. Поэтому лучше разделить несколько понятных версий OTIF, чем пытаться собрать один универсальный показатель.
Вторая — хранить правила расчёта в Excel или внутри отдельного отчёта. Тогда формула постепенно обрастает исключениями: сегодня убрали отменённые строки, завтра добавили особое правило для замен, потом изменили допустимое отклонение по времени. В итоге разные подразделения получают свои версии расчёта. Чтобы этого не происходило, правила OTIF должны быть зафиксированы в единой модели показателей и одинаково использоваться во всех управленческих отчётах.
Третья — смешивать ответственность за процесс и ответственность за качество данных. Факт доставки может существовать в логистической системе, но не фиксироваться корректно в ERP. В продажах может быть дата обещания клиенту, но она заполняется не всегда. У финансов есть правила закрытия периода, но нет надёжного события приёмки. В такой ситуации OTIF расходится не обязательно из-за проблем самого процесса, а из-за того, что события фиксируются по-разному или не синхронизированы. Здесь нужны понятные требования к качеству данных: какие поля обязательны, где фиксируется событие и в какой момент оно должно появиться в системе.
Четвёртая — пытаться сразу построить идеальное правило полноты. Для точного расчёта могут понадобиться качественные мастер-данные, единые справочники, корректные единицы измерения, история статусов и изменений заказа. Если такого уровня зрелости пока нет, лучше начать с более простой версии полноты, явно описать ограничения и постепенно уточнять правила. Сложная формула, которая по-прежнему требует ручных корректировок, управляемости не добавляет.
Как это выглядит на одном дашборде, без подмены смысла
Когда для каждой версии OTIF зафиксированы событие, окно и правило полноты, их можно показывать рядом, не пытаясь свести к одному числу. Важно, чтобы каждый показатель отвечал на свой управленческий вопрос.
Операционный OTIF показывает, насколько стабильно работает цепочка поставок. Рядом полезно видеть причины отклонений, на которые логистика может влиять: например, долю заказов с нарушением cut-off — предельного времени приёма заказа в обработку — или задержками на сборке. Тогда показатель не просто фиксирует результат, а помогает понять, где именно нужно вмешательство.
Клиентский OTIF показывает, выполняет ли компания обещание по срокам и полноте поставки для клиента. Здесь важны разрезы по клиентам, каналам, типам заказов или другим признакам, которые помогают увидеть, где риск выше. Для коммерции это уже основа для решений: какие клиенты требуют внимания, где нужно пересмотреть обещанный срок или условия поставки.
Финансовый OTIF показывает, удаётся ли закрывать операции в нужном периоде без лишних ручных корректировок. Рядом можно анализировать долю заказов с незакрытыми документами, расхождениями по цене, количеству или другим обязательным данным. Это помогает отделить проблемы физической поставки от проблем учёта и документооборота.
Три версии OTIF на одном экране часто полезнее одного универсального показателя. Вместо спора о том, чья цифра «правильная», становится видно, на каком участке возникло отклонение и какая функция должна на него реагировать.
Что делать, если бизнес требует один KPI для мотивации
Иногда топ-менеджмент по-прежнему хочет видеть один OTIF в системе мотивации. Логика понятна: чем проще показатель, тем легче его использовать. Но здесь важно не свести разные управленческие смыслы в одну формулу.
Один из рабочих вариантов — выбрать клиентский OTIF как основной KPI обещания. Он ближе к бизнес-риску, удержанию клиента и выполнению договорённостей по поставке. Операционный и финансовый OTIF при этом можно оставить как управляющие метрики с владельцами, порогами и отдельными зонами ответственности. Тогда один показатель используется для мотивации, а остальные помогают понять причины отклонений и управлять процессом.
Другой вариант — разделить мотивацию на внешний результат и внутреннюю дисциплину. Например, использовать OTIF обещания вместе с показателем качества фиксации событий и данных. Такой подход особенно полезен, если проблема возникает не только в самой поставке, но и в том, что даты, статусы или документы фиксируются неполно и потом становятся причиной споров.
Главное правило здесь простое: мотивация не должна создавать стимул «выиграть формулу». Если показатель можно улучшить за счёт новых исключений и ручных корректировок, со временем именно это и начнёт происходить. Управленческий KPI должен меняться прежде всего тогда, когда меняется сам процесс.
Почему это важно именно сейчас
Проблема с единым OTIF становится особенно заметной, когда цепочка поставок усложняется: появляется несколько каналов продаж, промо, разные правила работы с B2B и e-commerce, сокращаются горизонты планирования и меняются клиентские обещания. В такой системе одна универсальная версия показателя всё хуже описывает реальность. У логистики, коммерции и финансов закономерно появляются свои события, сроки и правила.
Поэтому единая модель OTIF нужна не для того, чтобы заставить всех смотреть на одну цифру. Она нужна, чтобы подразделения одинаково понимали, что именно измеряет каждая версия показателя, и обсуждали причины отклонений, а не спорили о датах и формулах.
Единая модель OTIF не обязана сводить всё к одной цифре. Она должна объяснять, что измеряет каждая версия, на каких событиях основана и какое решение поддерживает. Тогда подразделения обсуждают причины отклонений, а не спорят о формулах.
.svg)