Запас на складе почти всегда выглядит безопасно, пока его считают только в штуках. В магазине это защита от пустой полки, в закупках - выгодная цена, ретробонус или возможность взять товар дешевле рынка, в операциях - спокойствие.
Но для собственника это деньги, которые уже ушли из оборота: лежат на складе, занимают место, требуют хранения, стареют, ухудшают оборачиваемость и могут закончиться скидками или списаниями.
В этой статье я смотрю на запас не как на складскую строку, а как на капитал собственника. Он либо оборачивается и возвращается деньгами, либо лежит, стареет и требует дополнительных расходов.
Выгодная закупка, которая стала проблемой
В одной розничной сети FMCG - 700+ магазинов - я увидел типовую для розницы логику: если товар можно купить заметно дешевле обычного, его берут с мыслью "потом продадим".
На бумаге такая закупка выглядит разумно: большая скидка, хорошие условия, возможный ретробонус, поставщик готов отдать объем, коммерческий блок видит экономию на закупочной цене. Проблема в том, что закупочная скидка сама по себе ничего не гарантирует. Сеть еще должна этот товар нормально хранить, успеть продать и вернуть деньги в оборот.
Один показательный случай был с древесным углем. В ноябре в Сибири купили два вагона с огромной скидкой. Формально сделка выглядела выгодной, но склад не был предназначен для такого хранения, а зимой в Сибири древесный уголь покупают редко. В итоге товар лежал, занимал место, портил экономику хранения и частично ушел в списания.
В другом контуре закупили посуды на 81 год продаж. Это уже не ошибка прогноза и не запас "на всякий случай", а фактически замороженный капитал: возвращать товар было некому, место он занимал, продаж почти не было, но в учете он продолжал числиться нормальным запасом.
Проблема была даже не в самой закупке, а в том, что учет продолжал показывать обычный остаток. Система видела товар, но не показывала, что при текущей скорости продаж он уже давно перестал быть рабочим запасом.
Формально на складе был товар. По сути - там лежали деньги собственника, которые перестали работать.
Почему избыточный запас сложно остановить
Избыточный запас редко выглядит как проблема в момент закупки. Обычно он маскируется под хорошую цену, запас прочности, ретробонус, сезонную возможность или аргумент "вдруг не хватит". Поэтому его сложно остановить до того, как он попадет на склад и начнет требовать места, обработки, хранения и будущей уценки.
Пустая полка видна сразу. Клиент пришел, товара нет, продажа потеряна. А избыточный запас не кричит. Он просто лежит. Но каждый день у него есть цена: хранение, перемещение, обработка, место на складе, потери качества, уценка, списание, замороженный капитал и альтернативная стоимость денег, которые могли работать в другом месте.
Для первичной оценки я использую простую формулу стоимости владения запасом:
Стоимость владения запасом =
Средний запас в закупочных ценах × ставка владения запасом × период / 365
В управленческих расчетах по supply chain часто используют ориентир 15-30% от стоимости среднего запаса в год. В базовых расчетах можно брать 25% как быстрый ориентир, но в FMCG и товарах с коротким сроком годности фактическая ставка может быть выше: там к хранению добавляются уценка, порча, списания и требования к условиям хранения.
Даже если взять нижнюю границу - 15% годовых, товар, который лежит без движения, за 80 месяцев накапливает расходы владения, сопоставимые с его закупочной стоимостью. При 25% годовых этот срок сокращается до 48 месяцев.
Речь не про бухгалтерскую себестоимость единицы товара, а про управленческую стоимость владения запасом: хранение, обработку, стоимость капитала, уценку, списания и риск потери качества.
В ставку владения запасом должны попадать не только аренда склада. Туда входят складская обработка, персонал, оборудование, страхование, потери качества, уценка, списания и стоимость капитала. Если запас профинансирован кредитными деньгами - это стоимость обслуживания долга. Если деньгами собственника - альтернативная стоимость капитала / WACC.
Именно поэтому скидку и ретробонус нельзя считать отдельно от стоимости владения запасом. Иначе компания видит выгоду на входе, но не видит цену, которую платит после приемки.
Проблема не в складе
При разборе стало понятно, что общий объем запасов сам по себе ничего не объясняет. В одном остатке смешались три разные сущности: живой запас, страховой запас и мертвый капитал.
Живой запас продается, двигается и превращается в деньги. Страховой запас защищает продажи там, где есть понятный риск нехватки. Мертвый капитал лежит, стареет, требует хранения и продолжает выглядеть как нормальный товарный запас, хотя уже не работает.
Важно не сводить эту проблему к складу. Склад в таком кейсе чаще показывает последствия решений, которые были приняты раньше: в закупках, заказе, планировании, ассортименте, мотивации, правилах приемки и контроле сроков годности.
Если товар лежит без движения, склад не всегда виноват. Иногда виноват прогноз. Иногда - заказ по прошлой истории, которую никто не пересмотрел. Иногда - категория, которую продолжают считать живой только потому, что она есть в ассортиментной матрице. Иногда - ретробонус, который посчитали отдельно от хранения, оборачиваемости и риска списания.
Конфликт был сквозной. Операции нужно наличие, закупкам - выгодная цена и бонус, магазину - защита от пустой полки, складу - место и нормальные условия хранения. Собственнику при этом нужны оборачиваемость, маржа и живые деньги. Каждая функция права внутри своей логики, но бизнес платит за общий результат.
Почему нельзя просто урезать заказ
Самый опасный способ снижать запасы - просто урезать заказ. На бумаге это быстро дает красивую цифру: остатки падают, склад освобождается, деньги вроде бы возвращаются. Но дальше можно получить out-of-stock, потерянные продажи, раздражение покупателей, ручные переброски между магазинами, срочные поставки и рост операционного шума.
Поэтому снижение запасов - это не приказ держать меньше товара. Это пересборка модели заказа, приемки и контроля. Надо понять, какой запас действительно нужен бизнесу, а какой просто лежит, потому что система не умеет отличить его от нормального.
В этом месте ИТ, данные, закупки, склад и операции должны работать вместе. Не как отдельные функции, а как один контур управления капиталом.
Идеальная модель почти никогда не существует
Идеальная модель выглядит просто: у каждой партии есть срок годности, а при продаже на кассе точно понятно, какой товар с каким сроком вышел. Тогда можно видеть партию, остаточный срок годности, скорость продаж, риск списания и момент, когда нужно останавливать заказ или включать распродажу.
В реальной рознице такие чистые данные есть не всегда, особенно в большой сети с исторически разными учетными контурами. Поэтому использовали два режима расчета: где партии были - считали по партиям; где партийный учет был неполным - использовали расчетную модель риска.
Мы не пытались изображать идеальную точность там, где ее не было. Брали остаток, скорость продаж, срок хранения и контроль остаточного срока годности, а дальше оценивали объем под риском. Полноценный партионный учет такой расчет не заменяет, но позволяет увидеть проблему раньше, чем она превращается в уценку или списание.
Для каждого товара проставили срок хранения в днях и допустимый остаточный срок годности.
ОСГ - это остаточный срок годности товара.
Например, майонез провансаль с температурой хранения до 10 градусов: срок хранения 90 дней. Для него можно задать допустимый ОСГ при приемке 70%, а контроль ОСГ - 30%. В простом виде это означает, что при приемке у товара должно оставаться не менее 63 дней срока годности, а при снижении остаточного срока до 27 дней товар попадает в контроль.
Пример расчетной логики:
| Товар / ситуация | Что задано | Что проверяет система |
|---|---|---|
| Майонез провансаль, хранение до 10 градусов | Срок 90 дней, приемка не ниже 70% ОСГ, контроль на 30% ОСГ | Успеем ли продать текущий и заказанный объем до контрольной точки |
| Товар без полного партийного учета | Срок задан в карточке товара, риск считается расчетно | Система оценивает объем под риском по остатку, скорости продаж и сроку хранения |
| Медленный товар с большим остатком | Продажи, текущий остаток, срок хранения, контроль ОСГ | Не станет ли новый заказ будущей уценкой или списанием |
Ключевой вопрос был не "сколько товара есть", а "успеем ли мы продать этот объем до момента, когда товар станет проблемой".
Котловой метод и сигнал риска
Там, где не было точного партийного учета, считали котловым методом: брали остаток товара в месте хранения, скорость продаж, срок хранения и контроль ОСГ. Дальше система отвечала на простой вопрос - успеем ли мы продать этот остаток до контрольной точки.
Если не успевали, появлялся сигнал не "много товара", а конкретный объем под риском. После этого принимали решение: снизить цену, запустить распродажу, перераспределить товар, остановить дозаказ, вывести позицию из активного пополнения или разобрать ошибку закупки.
Задача стояла иначе: увидеть проблему до того, как она превратится в списание.
Как фильтр встроили в заказ
При формировании заказа система проверяла количество к заказу против текущего остатка, расчетной скорости продаж, срока хранения, ОСГ, контрольной точки и объема, который сеть успеет продать. Если расчет показывал, что товар не успеют распродать, менеджеру выводилось предупреждение.
Решение оставалось за менеджером. Это было важно: система не заменяла коммерческое решение там, где есть контекст - промо, сезонный пик, федеральная акция или осознанный риск. Но она убирала ситуацию, когда риск вообще никто не увидел. После предупреждения менеджер принимал решение с видимой ценой.
Это меняет качество управления. До предупреждения можно было сказать: "Мы не знали". После предупреждения решение уже принималось осознанно.
Где система должна была сказать "нет"
На приемке предупреждения было недостаточно. При приемке на складе вводился срок годности товара, после чего система проверяла, успеет ли сеть продать его с учетом текущего остатка, скорости продаж и контрольной точки ОСГ. Если расчет показывал, что товар не успеет продаться, принять его было невозможно: отказ стоял на уровне системы.
Такие правила не начинают работать только потому, что их настроили в системе. Их приходится защищать управленчески. Особенно в момент, когда система блокирует сделку, которая на входе выглядит выгодной.
После включения фильтра коммерческий и операционный контур нашли несколько паллет пирожных: хорошая закупочная скидка, большой ретробонус, на первый взгляд - выгодно. Но расчет показывал, что сеть не успеет это продать, а товар с высокой вероятностью превратится в уценку, списание, хранение и операционный шум.
Фильтр не приняли как очевидное улучшение. Для коммерческого блока это выглядело как блокировка выгодной сделки: скидка есть, ретробонус есть, поставщик готов отгрузить. Поэтому разговор быстро ушел к CEO.
И это был правильный момент. Спор нужно было переводить из плоскости "нам не дают купить" в экономику: сколько сеть реально успеет продать, сколько будет стоить хранение и какой объем с высокой вероятностью уйдет в уценку или списание.
CEO сел с коммерческим и операционным блоком и посчитал экономику. Вывод был простой: фильтр сработал правильно, приемку блокируем. После этого стало понятно, что компания защищает не только закупочную цену, но и капитал, маржу и оборачиваемость.
Ретробонус не должен жить отдельно от полной экономики
Ретробонус сам по себе не проблема. Он становится проблемой, когда его считают отдельно от оборачиваемости, ОСГ, стоимости владения и риска списания.
После пересборки модели бонус перестал быть самостоятельным аргументом для закупки. Если товар не успевал выйти в продажу до контрольной точки, скидка уже не спасала сделку. Менеджер сохранял право принять коммерческий риск, но теперь принимал его с видимой ценой.
Это меняло ответственность: решение переставало быть просто "выгодной закупкой" и становилось управленческим выбором с понятным риском.
Что изменилось в модели управления
Запасы не резали одинаковым процентом по всем категориям. Сначала разделили их по смыслу: что защищает выручку, что является страховым запасом, что лежит без движения, а где срок годности уже создает риск.
Дальше изменили правила: выделили позиции без движения, связали заказ с фактическими продажами, остатками и скоростью движения, разобрали категории по ABC, частотности и оборачиваемости, задали срок хранения, ОСГ и контроль ОСГ, настроили сигналы по объему под риском, встроили предупреждения в заказ и запрет на приемку там, где товар уже на входе был экономически опасен.
Отдельно зафиксировали, кто принимает решение по корректировке заказа. Пока решение размыто между закупками, операцией, складом и магазином, избыточный запас всегда можно объяснить заботой о продажах или хорошей закупочной ценой. Но если у решения есть владелец, вопрос звучит иначе: почему эти деньги должны лежать здесь, если товар не успеет превратиться в продажу.
Почему отчет сам по себе ничего не меняет
Отчет сам по себе ничего не меняет. Можно показать ABC, оборачиваемость, дни запаса, медленные SKU, ОСГ и динамику продаж, но без владельца решения это останется витриной.
Управление начинается там, где понятно, кто разбирает сигнал, меняет правило заказа, принимает решение по распродаже, блокирует приемку, спорит с поставщиком и проверяет результат через месяц. Поэтому данные нужно связывать не только с отчетностью, но и с управленческим контуром: владелец, решение, срок, контроль результата.
Для собственника это принципиальное различие. Ему не нужна таблица ради таблицы. Ему нужно, чтобы деньги перестали застревать в товаре, который не работает.
Где был риск
У такого проекта есть неприятная развилка: если действовать слишком мягко, запас не снизится; если слишком жестко - можно получить пустую полку. В FMCG ошибка по наличию быстро превращается в потерянную продажу: покупатель не обязан ждать, пока компания разберется со своим заказом, он просто купит в другом месте.
Поэтому мы не продавали снижение запасов как самоцель. Целью было отделить нужный запас от замороженного капитала. Снижение ради снижения бьет по продажам. Снижение через качество заказа возвращает деньги в оборот и сохраняет доступность там, где она действительно нужна.
Именно поэтому в такой работе нельзя смотреть только на общий остаток. Нужно одновременно держать несколько показателей: оборачиваемость, продажи, OOS, списания, частотность, скорость движения, срок хранения, ОСГ, корректность заказа и реакцию магазина. Иначе можно красиво снизить запасы в отчете и незаметно ударить по выручке.
Результат
После пересборки изменился сам вопрос. Раньше смотрели, сколько товара есть. Теперь смотрели, какая часть этого товара работает: что поддерживает продажи, что нужно как страховой запас, что требует ограничения, что нужно распродавать или выводить, а какие поставки нельзя принимать даже при хорошей закупочной цене.
В результате запасы снизились на 20%. Но смысл был не в самой цифре, а в способе: снижение не делалось слепым урезанием. Мы не резали наличие там, где оно защищало продажи, а убирали из модели тот запас, который перестал работать как капитал.
Для собственника общий остаток мало что говорит. Ему нужен профиль запаса: сколько денег находится в распределительном центре, в магазине, в пути, в товаре под риском ОСГ, в медленных SKU, в страховом запасе и в товаре, который уже требует управленческого решения.
Еще важнее видеть изменение этого профиля. Общий запас может выглядеть спокойно, но внутри него может расти доля денег, которые почти не работают.
Пока таких вопросов нет, компания может чувствовать себя безопасно: полки вроде не пустые, склад вроде заполнен, система вроде показывает наличие. Но это спокойствие может быть дорогим. Избыточный запас часто выглядит не как проблема, а как безопасность. Просто очень дорогая.
Финальный вывод
Запас нельзя оценивать только по наличию товара. Его надо оценивать по скорости превращения в деньги.
Все, что не движется, не успевает продаться или идет под списание, уже перестает быть запасом.
Это капитал, который перестал работать.