Клиент стоит перед пустой полкой. Директор магазина говорит: «Все продали».
Коммерческий директор открывает остатки и видит другое: в системе еще числится около 100 кг куриной грудки.
Так выглядит одна из самых дорогих иллюзий в рознице: для учета товар есть, для клиента его нет.
Эта сцена произошла во время обхода магазина, куда приехали CEO, коммерческий директор и операционный директор. На полке не было куриной грудки. Для FMCG это не мелочь: товар частотный, спрос регулярный, клиент не будет долго разбираться, почему полка пустая. Он просто не купит.
Директор магазина объяснил, что товар продали. Коммерческий контур показал остаток. Директор ответил, что магазин много раз писал о плохом качестве, товар убрали в морозилку и оставили разбираться на инвентаризации.
Я не буду здесь додумывать, почему товар не вернули поставщику. Важнее другое: в этой точке разошлись сразу несколько реальностей. Система видела остаток. Магазин видел товар, который нельзя нормально продавать. Коммерческий блок видел расхождение между учетом и полкой. CEO видел потерянную продажу, которую компания создала сама.
Пока заказ верит формальному остатку, он не привезет новый товар. Для системы потребность еще не появилась.
Так out-of-stock воспроизводится каждый день. Не потому что один директор магазина плохо работает, а потому что заказ, остатки, полка и реальность живут в разных версиях одной картины.
Классический OOS показывал проблему, но не показывал время потерь
Контур был крупный: 500+ магазинов и более 35 000 товарных позиций. Сначала OOS считали классически - по количеству товарных позиций, которые отсутствуют или недоступны для продажи. Такой расчет полезен для общего контроля: можно смотреть категории, магазины, динамику, сравнивать сеть и отдельные точки.
Но у классического подхода есть ограничение. Он показывает, что проблема есть, но плохо показывает, как именно сеть теряет продажи внутри дня. Товар мог быть на остатке утром, потом быстро продаться, а дальше несколько часов полка стояла пустая. Вечером товар мог приехать или остаток мог быть скорректирован. В сводном расчете часть проблемы сглаживалась, а клиент в конкретный час все равно видел пустую полку.
В какой-то момент стало ясно: считать только количество проблемных позиций недостаточно. Нужно считать время, в течение которого товар был недоступен для покупки. Для бизнеса OOS - это не только строка в отчете. Это часы, когда сеть не может продать товар, который клиент готов купить.
Сначала мы полезли в остатки
Первый слой проблемы был очевиден: остатки часто не отражали реальность. Если товар физически лежит в магазине, но не может продаваться из-за качества, размещения или учетной ошибки, система продолжает считать его доступным. Для заказа такой товар существует. Для покупателя - нет.
Поэтому первым шагом сделали для магазина нормальный инструмент коррекции остатка. Не письмо, не звонок, не сообщение в чат, а документ корректировки с причиной: не найдено, найдено, потеря товарного вида, ошибка размещения и так далее. Задача магазина была простая - оперативно привести системный остаток к реальности и зафиксировать, почему возникло расхождение.
Это сработало как дисциплина процесса. Стало меньше писем, чатов, звонков и споров. Магазины перестали каждый раз объяснять проблему заново. Появились причины, которые можно было анализировать. Но качественного скачка по OOS это не дало. Остатки стали чище, ручного шума стало меньше, но полка все равно иногда пустела внутри дня.
Значит, проблема была не только в остатках.
Потом перешли к часовому контролю
Следующий шаг был в изменении самой логики измерения. Мы начали смотреть не просто факт отсутствия товара, а долю времени, когда товар был недоступен для покупки в течение дня или недели.
Формула простая:
OOS % = время отсутствия товара / общее рабочее время x 100%
Если магазин работает 12 часов, а популярный товар отсутствовал на полке 3 часа, OOS по нему за день составляет 25%.
На практике по кассовым данным мы смотрели периоды нулевых продаж. Здесь есть важное ограничение: нулевая продажа сама по себе еще не доказывает пустую полку. Для редкого товара это может быть нормальным поведением спроса. Поэтому такой подход имеет смысл прежде всего для частотных SKU, где продажа идет регулярно и провал в течение часа уже выглядит как отклонение.
Внутри команды эту логику можно было объяснить через «правило банана». Банан - частотный товар. В нормальном магазине в течение любого рабочего часа обычно есть хотя бы один чек с бананом. Если час прошел, а банан не продался, это еще не обвинение магазина, но уже повод проверить полку. При 12-часовом рабочем дне один такой час - это 1/12 дневного окна продаж, два часа - 2/12, три часа - 3/12.
Так мы перестали видеть OOS только как количество отсутствующих позиций и начали видеть потерянное время продаж.
Что происходило после сигнала
Дальше было важно не утонуть в отчетах. Сам по себе сигнал ничего не исправляет. Поэтому для разных ситуаций нужен был разный маршрут.
Если остаток в системе был, но продаж по частотному товару не было, задача уходила в магазин. Магазин проверял полку, физическое наличие, качество товара и при необходимости делал корректировку остатка с причиной.
Если остатка не было, но корректировки по товару или группе повторялись, это уходило супервайзеру. Там уже надо было смотреть дисциплину учета, приемку, выкладку и работу с товаром внутри магазина.
Если остатка не было, корректировок не было, а товар регулярно проваливался по продажам, подключались заказ и товародвижение. В этом случае разбирали параметры пополнения, график поставки, распределение, недовоз или ошибку в логике заказа.
Так OOS перестал быть общей фразой «пустая полка». Он стал набором разных причин с разными владельцами. Это не выглядело как красивый проект. Скорее как тяжелая операционная настройка. Зато у сигнала появился маршрут, а у причины - владелец.
Что стало видно внутри дня
После перехода к часовому OOS вскрылись вещи, которые не были видны в дневной отчетности.
В одном случае товар приезжал, быстро продавался в ноль, а дальше полка стояла пустая до следующей поставки. В другом - директор магазина заказывал осторожнее, чем требовал спрос, потому что боялся списаний. Еще в части точек товар был физически в магазине, но его не выкладывали вовремя. Отдельно всплыли графики поставок: машина приезжала уже после пика спроса.
Формально все это можно было назвать одним словом - OOS. По сути это были разные болезни: остатки, выкладка, заказ, поставка, качество товара и мотивация магазина.
Если директор магазина сильнее боится списаний, чем пустой полки, он будет заказывать осторожно. Формально он защищает показатель. Фактически сеть теряет продажу. Поэтому OOS нельзя разбирать отдельно от правил оценки списаний и управленческих сигналов, которые получает магазин.
То же самое с поставками. Если товар приезжает после пика спроса, формально логистика может быть права: машина приехала, поставка выполнена. Но клиент пришел раньше. Для него товара не было. Значит, проблема уже не только в заказе, а в связке спроса, графика поставки и выкладки.
Главным было не показать OOS, а вернуть причину в процесс.
Почему сравнение магазина с сетью оказалось полезным
Отдельно хорошо работало сравнение конкретного магазина с сетью. Если по сети частотный товар продавался стабильно, а в одном магазине появлялись регулярные провалы, это был повод смотреть именно на эту точку. Не в логике «найти виновного», а в логике «найти место, где процесс перестал работать».
Например, если сопоставимые магазины нормально продают банан, молоко или товар из куриной категории, а в одной точке внутри дня возникает тишина, проверять надо не только заказ. Надо смотреть полку, выкладку, приемку, корректировки, время поставки, действия директора магазина и работу супервайзера.
На этом уровне OOS перестает быть задачей одной функции. ИТ показывает отклонение. Магазин проверяет реальность. Супервайзер смотрит повторяемость. Заказ и товародвижение меняют параметры, если проблема выше магазина. Операционный контур контролирует, чтобы причина не возвращалась снова.
У решения тоже была цена
Такой контур не появляется после запуска одного отчета.
Нужно было дисциплинировать корректировки, договориться о причинах, убрать свободный текст из переписок, заставить магазины работать через документ, а не через чат. Нужно было регулярно смотреть повторяемость сигналов и не давать им зависать на уровне «посмотрели отчет».
Это была дополнительная нагрузка на операционное управление. Магазину нужно было быстрее приводить остаток к реальности. Супервайзеру - разбирать повторы. Заказу и товародвижению - смотреть не только свои параметры, но и обратную связь с полки. ИТ - держать данные в форме, в которой ими можно пользоваться, а не просто выгружать в отчет.
Если такой контур не поддерживать, он быстро превращается в еще одну витрину. Дашборд есть, красные зоны есть, на совещании их показывают. Но полка не меняется.
Поэтому отчет ничего не снижает. Он только показывает, где смотреть.
Снижение появляется в другом месте: когда сигнал превращается в проверку, проверка - в причину, причина - в изменение процесса, а изменение процесса - в контроль повтора.
Что изменилось в заказе
Заказ после этого начал получать не только формальный остаток, но и обратную связь из реальности: товар числится, но не продается; товар быстро уходит в ноль; магазин часто корректирует одну группу; конкретная точка хуже сети по часовому OOS; поставка приезжает после пика спроса.
Задача была не в том, чтобы автоматически увеличить заказ по всем проблемным позициям. Это быстро приводит к запасам, списаниям и замороженным деньгам. Задача была в том, чтобы дать заказу более точную картину реальности.
Где-то нужно было поправить остаток. Где-то - изменить параметры пополнения. Где-то - пересмотреть время поставки. Где-то - разобрать выкладку. Где-то - остановить практику недозаказа из страха списаний. Здесь я оставляю несколько «где-то» сознательно: в реальном проекте не было одной причины, которую можно красиво назначить корневой. Был набор разных причин, и каждая требовала своего владельца.
Дефицит и избыточный запас - две стороны одной слабой управляемости. В первом случае бизнес теряет продажу. Во втором - замораживает деньги и получает списания. Сильный заказ должен видеть оба риска.
Результат
В целевом контуре OOS удалось сократить в 2 раза. На отдельных участках, где причина была локальной - внутридневная выкладка, график поставки, осторожный заказ магазина или дисциплина корректировок, - улучшение составляло около -30%.
Это разные срезы. «В 2 раза» - результат по целевому контуру. «-30%» - отдельные локальные улучшения по конкретным причинам и участкам процесса. Их нельзя смешивать как максимум и минимум одного показателя.
Я сознательно не перевожу этот результат в рубли. В сетевой рознице такая цифра слишком зависит от категории, маржи, частоты покупки и масштаба контура. Безопаснее и честнее говорить о механике: OOS перестал быть общей претензией к магазинам и стал измеряемым временем потерянных продаж с понятным маршрутом ответственности.
Результат появился не после приказа «лучше заказывайте» и не после запуска еще одного отчета. Он появился после того, как сеть связала данные, заказ, остатки, внутридневной OOS, корректировки, графики поставок и маршрут ответственности.
До этого компания видела симптом. После этого начала видеть, где именно процесс воспроизводит потерю.
Для собственника OOS - это проверка того, умеет ли компания связывать данные, процесс и ответственность. В магазине может быть сильный директор, в закупках - опытная команда, в ИТ - нормальная отчетность, в supply chain - рабочий график поставок. Но если каждый видит только свой участок, сеть продолжает терять продажи на стыках.
Для CEO вывод еще жестче: OOS нельзя снизить фразой «разберитесь с магазинами». Такой приказ обычно усиливает ручное управление, но не чинит механизм воспроизводства ошибки. Нужно смотреть, кто увидел сигнал, кто проверил полку, кто исправил остаток, кто указал причину, кто разобрал повтор, кто изменил заказ и кто отвечает, если тот же SKU снова проваливается внутри дня.
Пока причина пустой полки не возвращается в заказ и маршрут ответственности, сеть каждый день воспроизводит одну и ту же потерю.