Остаток есть. Продаж нет. Где сеть уже теряет деньги

Товар числится на остатке.Продаж нет.

Для FMCG это плохой сигнал.

Деньги уже вложены в закупку, логистику, приемку, хранение и место в магазине. Но обратно в выручку они не возвращаются.

В отчете товар есть. Для покупателя его нет.

В одном FMCG-контуре на 700+ магазинов мы разбирали именно такой разрыв. Не как бухгалтерскую ошибку. Не как проблему аккуратности данных. А как управленческий сигнал: где сеть уже теряет деньги, но еще не видит этого как проблему.

Я для себя называл этот подход «правилом банана».

Почему банан стал хорошим датчиком

Банан - удобный пример.

Не потому что это особенный товар. А потому что на нем хорошо видна логика частотного SKU.

Он понятен покупателю.Он быстро оборачивается.По нему видно, есть обычная частотность продаж или она сломалась.

Если в магазине бананы числятся на остатке, но продаж с обычной частотностью нет, первая версия не должна быть сложной.

Не надо сразу строить гипотезу про сезонность, изменение спроса или поведение покупателей.

Сначала нужно проверить физику магазина.

Товар выложен?Его достаточно?Он в нормальном товарном виде?Его вообще нашли?Он доступен покупателю, а не лежит в подсобке, в коробке, в неправильной зоне или в состоянии, в котором его уже нельзя нормально продавать?

Так появился рабочий принцип.

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

Остаток в системе и управленческий остаток

В таких историях главная ловушка - верить остатку как окончательной правде.

В учетной системе товар может быть.

Но для бизнеса имеет значение не только учетный остаток. Для бизнеса имеет значение управленчески верный остаток.

Учетный остаток отвечает на вопрос: сколько товара числится.

Управленчески верный остаток отвечает на другой вопрос: сколько товара реально доступно покупателю в нормальном товарном виде.

В FMCG между этими двумя величинами может лежать вся экономика потерь.

Товар может быть принят, но не выложен.Может лежать в торговом зале, но выглядеть так, что покупатель его не возьмет.Может быть в магазине, но сотрудники не могут его найти.Может числиться после пересорта, ошибки приемки, порчи или фактической потери.

Для отчета остаток есть.Для P&L продажи нет.

И дальше ошибка расходится по всей цепочке.

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

А собственник в итоге видит другое: деньги вложены, место занято, продаж нет.

Что мы сделали

Мы не начинали с большого проекта по переустройству всех процессов учета.

Сначала взяли частотные SKU и построили простую связку:

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

Не написать «все нормально».Не поставить формальную отметку.Не объяснить падение продаж общими словами.

Проверить.

Сначала количество: есть ли товар там, где покупатель может его увидеть и взять.

Потом качество: можно ли этот товар продавать в таком виде.

Для бананов это было особенно наглядно. Товар может быть формально в наличии, но по факту уже не быть товаром для продажи. Его можно посчитать. Но нельзя нормально монетизировать.

После проверки магазин делал коррекцию запаса.

Но сама коррекция не была главным элементом модели.

Главной была причина.

Не товарный вид.Не найдено.Пересорт.Ошибка приемки.Фактическое отсутствие.Другая операционная причина.

Причина превращала исправление остатка в управленческий сигнал.

Без причины это просто минус в учете.С причиной это информация для операционного департамента, категорийного управления, логистики и СБ.

Как мы проверяли, что сигнал живой

Отдельно проверяли, не является ли это шумом аналитики.

Точной статистики по количеству таких сигналов уже не сохранилось. Но когда мы тестировали сам механизм, логика была простой: получили сигнал - подключились к камерам и проверили физическую реальность магазина.

И сигнал подтверждался.

Товар действительно был не там, не в том виде, не в том количестве или фактически не был доступен покупателю.

Для меня это был момент, после которого спор закончился.

Пока сигнал живет только в отчете, к нему можно относиться как к аналитической гипотезе. Когда через камеру видно, что остаток в системе и реальность магазина разошлись, это уже не гипотеза.

Это место, где сеть теряет деньги.

После таких проверок «правило банана» стало рабочим инструментом. Не для того, чтобы красиво объяснять прошлые потери. А для того, чтобы находить фантомный остаток раньше, чем проблема растворится в недоборе продаж.

Почему причина важнее самой корректировки

Одна корректировка запаса сама по себе мало что доказывает.

В рознице всегда есть операционный шум. Ошиблись при приемке. Не туда поставили коробку. Не успели выложить. Товар потерял вид. Сотрудник не нашел. Такое бывает.

Но повторяемость уже показывает систему.

Если один магазин регулярно корректирует остатки по частотным товарам, это вопрос к управлению магазином.

Если корректировки идут по одной категории, нужно смотреть приемку, хранение, выкладку, качество поставки и срок реакции.

Если часто появляется причина «не найдено», это сигнал для операционного департамента и СБ.

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

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

В этом была ценность модели.

Мы смотрели не только на остаток. Мы смотрели на поведение остатка.

Обычный отчет показывает число.Управленческая модель показывает отклонение, причину и повторяемость.

Где здесь деньги

В таких задачах я не люблю обещать точный эффект от одного сигнала.

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

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

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

Первое - в замороженном запасе. Товар числится, но не превращается в выручку.

Второе - в месте на полке. Полка занята или должна быть занята товаром, который не работает как продажа.

Третье - в логистике и операциях. Компания уже оплатила путь товара до магазина, но не получила нормальный оборот.

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

Пятое - в искаженных решениях. Система видит остаток и может не заказать товар, хотя для покупателя его фактически нет.

Это не одна строка потерь. Это цепочка.

И чем больше сеть, тем опаснее такой дефект. В одном магазине это может выглядеть как мелочь. В 700+ магазинах это уже управленческий шум, который каждый день влияет на заказ, продажи, списания, контроль и работу магазина.

Что изменилось для операционного департамента

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

До этого разговор легко уходил в споры.

Продажи просели, потому что спрос упал.Нет, магазин плохо выложил.Нет, поставка пришла не так.Нет, товар был, но его не нашли.Нет, товар потерял вид.

Каждая функция могла защищать свою версию.

После «правила банана» разговор стал предметнее.

Есть товар на остатке.Есть нормальная частотность продаж.Есть провал продаж.Есть физическая проверка.Есть причина коррекции.Есть повторяемость по магазину, товару или категории.

Такой набор фактов меняет разговор с директором магазина.

Не «почему у вас плохо».А «вот товар, вот остаток, вот отсутствие продаж, вот причина, вот сколько раз это повторилось».

С этим сложнее спорить. И с этим можно работать.

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

Это уже не жалоба и не субъективная оценка.

Это маршрут проверки.

Что изменилось для службы безопасности

Для СБ этот контур тоже полезен.

Но здесь нужно было не сломать модель.

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

Поэтому логика была другой.

Один случай - операционный шум.Повторяемость - повод смотреть глубже.

Если по магазину регулярно идет причина «не найдено», это уже не случайность.

Если отклонения концентрируются в одной категории, это нужно разбирать.

Если корректировки появляются после провалов продаж, значит проблема уже успела ударить по выручке.

Если магазин резко отличается от похожих магазинов, СБ получает не поток подозрений, а нормальный фильтр для проверки.

Операционный департамент отвечает за процесс.СБ смотрит на повторяющиеся аномалии.ИТ и аналитика дают сигнал, маршрут и прозрачность.

Так фантомный остаток перестает быть технической проблемой учета и становится частью управления риском.

Почему без верного остатка сеть принимает слабые решения

В распределенной сети ошибка остатка почти никогда не остается локальной.

Она уходит дальше.

В заказ.В планирование.В категорийное управление.В работу магазина.В оценку директора.В контроль потерь.В P&L.

Категорийный менеджер видит наличие и может не понимать, почему товар не продается.

Система заказа видит остаток и может не довезти товар.

Операционный директор видит магазин без формального нарушения.

CEO видит недобор продаж, но не видит конкретное место разрыва.

Собственник видит итоговую экономику: товар закуплен, деньги заморожены, логистика оплачена, место занято, продаж нет.

Это неприятный тип потери.

Не авария.Не очевидный сбой.Не ситуация, где все сразу побежали чинить.

Система показывает, что товар есть. Бизнес в это время теряет продажу.

Почему продажи могут начать расти

Я не стал бы формулировать это грубо: «исправили остатки - продажи выросли».

В рознице продажи редко растут от одной кнопки.

Они растут, когда покупатель чаще находит нужный товар в нужном месте, в нормальном виде и в нужное время.

«Правило банана» влияло именно на это.

Мы начали видеть ситуации, где товар числится, но не продается. Начали проверять физическую реальность товара. Начали корректировать запас с причиной. Начали смотреть не только на единичные случаи, а на повторяемость.

После этого часть скрытых потерь стала видимой.

А видимая потеря уже управляется.

Если товар не найден - это один маршрут работы.Если товар потерял вид - другой.Если товар не выложен - третий.Если неверный остаток мешает заказу - четвертый.Если один магазин регулярно корректирует одну группу - пятый.

Сеть начинает не просто лучше считать товар. Она начинает лучше управлять доступностью товара для покупателя.

В FMCG это напрямую связано с продажами, особенно на частотных SKU. Поэтому корректная формулировка результата такая: OOS снижался, продажи росли, а часть скрытых потерь стала видимой и управляемой.

Без грубой атрибуции. Но с понятной логикой причин и следствий.

Где подход может сломаться

У этой модели есть цена.

Первый риск - формальные проверки. Магазин получает сигнал, но не идет в реальность. Просто выбирает удобную причину и закрывает задачу.

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

Третий риск - свободный текст в причинах. Через месяц там появятся «прочее», «разное», «уточнить», «не знаю». Такой справочник причин управленчески мертв.

Четвертый риск - СБ начнет видеть нарушение в каждой корректировке. Тогда магазины перестанут показывать правду.

Пятый риск - ИТ сделает отчет, но не встроит его в процесс. Тогда появится еще один экран, на который все смотрят, но никто не обязан действовать.

Поэтому модель работает только при нескольких условиях.

Нужен список частотных SKU.Нужна нормальная частотность продаж для сравнения.Нужен маршрут реакции.Нужен закрытый справочник причин.Нужна регулярная работа с повторяемостью.Нужен владелец процесса.

Без владельца «правило банана» быстро превращается в красивую аналитику без управленческого эффекта.

Вывод для собственника

Для собственника вывод простой.

Если товар есть на остатке, но не продается, это не всегда проблема спроса.

Это может быть проблема выкладки, качества, учета, приемки, хранения, дисциплины магазина, безопасности или управления запасом.

Но в P&L итог один: деньги вложены, продаж нет.

Поэтому сильная розничная сеть должна управлять не только продажами и закупками. Она должна управлять достоверностью остатка как частью коммерческого результата.

Пока остаток в системе не совпадает с реальностью магазина, компания принимает решения по искаженной картине.

Вывод для CEO

Для CEO это история не про бананы.

Это история про управляемость распределенной сети.

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

Частотный товар на остатке без продаж - один из таких сигналов.

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

Если этот сигнал встроен в процесс, он показывает не только проблему товара. Он показывает качество управления магазином.

Главный вывод

Фантомный остаток опасен тем, что выглядит как порядок.

Товар есть в системе.Деньги уже потрачены.Продаж нет.Заказ может не сработать.Магазин может не увидеть проблему.Собственник может получить искаженную картину бизнеса.

У нормальной розничной сети остаток должен быть не только учетным фактом. Он должен быть рабочей правдой для заказа, полки, продаж, СБ и P&L.

Если товар числится, но не продается, это не мелкая аномалия.

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