Приказ "меньше списывать" может снизить списания в отчете. Но не всегда снижает потери.
Иногда он просто учит магазин прятать проблему в остатках.
В одном retail / FMCG контуре списания были одним из показателей магазина. Если торговая точка превышала допустимую норму, это било по KPI. На бумаге логика выглядела правильно: магазин должен следить за товаром, сроками, ротацией, хранением и дисциплиной списаний.
Но в реальной рознице любой KPI влияет на поведение. Если показатель настроен грубо, люди начинают управлять не потерями, а самим показателем.
Часть магазинов старалась не списывать все в текущем месяце, чтобы не пробить допустимый процент. Товар мог физически уже быть проблемным, но в системе продолжал жить как нормальный остаток. В отдельных разборах находили совсем странные истории: в феврале всплывали списания черешни и вишни прошлого года.
Я не буду додумывать точный механизм, почему это не поймала инвентаризация. Насколько помню, полная инвентаризация была не частой, и внутри этого периода магазин мог достаточно долго жить с таким остатком. Для этой статьи важнее другое: списания не исчезали. Они уходили из видимости.
А дальше начиналась более дорогая проблема.
Система видела товар на остатке. Заказ считал, что товар есть. Магазин понимал, что товар уже не нормальный. Клиент на полке его не видел или видел товар, который нельзя нормально продавать. В результате грязный остаток бил не только по списаниям, но и по заказу, OOS, выкладке и будущим потерям.
Так стало понятно: управлять только процентом списаний опасно. Можно получить красивый KPI и слепую систему.
Списание - это последний документ, а не первая причина
На уровне отчета все выглядит просто: магазин списал товар. Значит, надо спросить с магазина.
Но когда начинаешь разбирать цепочку, картина часто оказывается другой. Товар могли заказать в объеме выше реального спроса или привезти поздно. Иногда проблема приходила от поставщика - короткий срок, качество, повреждение. Иногда изнутри - промо не сработало, товар не выставили вовремя, нарушили ротацию, появилась недостача или кража.
Магазин в этой схеме часто последним оформлял результат. Но причина могла родиться за несколько шагов до него.
И вот здесь была главная развилка. Можно было продолжать давить на торговые точки: списывайте меньше, объясняйте больше, согласовывайте каждый случай, не превышайте норматив. Такой подход почти гарантированно создал бы еще больше ручного шума и еще больше желания прятать проблему.
Мы пошли в другую сторону: начали приводить остаток в системе к реальности.
Не к красивому отчету. К реальности.
Что изменили в процессе
Мы сделали простой документ коррекции запаса. По смыслу это был быстрый способ для магазина показать, что физическое состояние товара не совпадает с тем, как он сейчас живет в системе.
В строке документа было три главных поля: товар, количество и причина. Для магазина операция была максимально короткой: на ТСД сканируешь штрихкод, вводишь количество, выбираешь причину.
Все.
Причины сделали не академическими, а понятными для работы: разбит или испорчен, истек срок годности, кража или недостача, карантин качества.
Этого было достаточно, чтобы магазин не писал объяснительную на каждый случай, а быстро фиксировал факт.
Задача была не в том, чтобы усложнить жизнь магазину. Наоборот, мы хотели убрать письма, чаты, объяснительные и долгие согласования там, где нужна быстрая фиксация факта.
Если товар нельзя продавать, система должна узнать об этом быстро. Если товар есть физически, но находится на карантине качества, он не должен участвовать в логике доступного остатка так же, как нормальный товар на полке.
Это важный нюанс: мы не подменяли комиссионное списание и инвентаризацию. Физическое изменение остатка происходило по установленным процедурам - через списание, инвентаризацию, КРО и другие контрольные механизмы. Но до этого момента магазин получал простой способ изменить профиль остатка: показать, что часть товара есть физически, но уже не является нормальным доступным Stock on Hand.
Для управления это критично. Бизнесу недостаточно знать, что товар где-то числится. Надо понимать, можно ли его продать.
Почему магазину разрешили "находить" и "терять" товар
На первый взгляд это выглядит опасно: дать магазину возможность самому отражать такие движения. Но реальная альтернатива была хуже.
Если магазин не может быстро показать, что с товаром что-то не так, он начинает жить в серой зоне. Товар есть в системе, но его нельзя продавать. Товар испорчен, но списывать сейчас нельзя, потому что KPI. В результате учет выглядит спокойнее, чем реальность.
Поэтому магазин не ограничивали в самой возможности коррекции. В течение дня он мог один и тот же товар найти и потерять. Главное - не прятать факт и указывать причину.
При этом коррекция не была свободным списанием. Каждое движение оставляло след: кто сделал, когда, по какому товару, на какое количество и с какой причиной. Если появлялся странный паттерн - частые потери по одному SKU, массовые корректировки по поставщику, резкий рост недостач - СБ ставила это на контроль или начинала разбор.
Это создало двойную мотивацию. С одной стороны, точный остаток помогал магазину: меньше неверного заказа, меньше ложного OOS, меньше претензий за товар, который система видит, а клиент не может купить. С другой стороны, точная причина защищала магазин от чужой ответственности. Если проблема пришла из поставки, логистики или промо, это становилось видно.
Процент списаний при этом оставался показателем магазина. Но дальше он раскладывался по вкладу причин. Магазин отвечал за то, что реально находилось в его зоне: своевременную выкладку, ротацию, хранение, корректность отражения товара и дисциплину исполнения. За короткий срок, качество поставки, ошибочный объем промо, логистическое повреждение или неправильный заказ отвечал тот контур, где причина возникла.
Это был принципиальный сдвиг. Мы перестали делать магазин единственным виновником последнего документа.
От коррекции остатка к сигналам
Сам по себе документ коррекции еще не снижает списания. Он только начинает показывать реальность. Снижение появляется тогда, когда по этим данным начинают работать.
Мы смотрели, какие коррекции повторяются, по каким товарам, поставщикам, магазинам, регионам, категориям и периодам. Сигналы могли приходить из разных источников. Магазин мог сам отразить факт. Система могла поставить задачу на проверку остатка по заданным критериям. Аналитика по OOS могла показать провал продаж при наличии остатка. СБ могла инициировать проверку по своим основаниям.
Простой пример: один товар одного поставщика начали массово списывать в нескольких магазинах. Это уже не похоже на случайность отдельной точки. Значит, нужно проверить остальные магазины, где есть этот товар, и понять, что происходит: качество, срок, поставка, хранение, логистика, спрос или ошибка в данных.
В связке с ежечасным контролем OOS это давало еще более полезную картину. Если по товару появлялся провал продаж, потом магазин делал коррекцию, а затем возникало списание, мы видели не отдельный документ, а цепочку событий. Когда товар перестал продаваться. Когда магазин это заметил. Когда изменил доступный остаток. Какую причину выбрал. Кто получил сигнал. Что было сделано до финального списания.
Раньше в конце цепочки был факт потери. Теперь появлялись следы, по которым можно было понять, где эта потеря родилась.
Где вскрылись реальные причины
Один из показательных случаев был в регионе, где списания происходили в первые 1-2 дня после поставки со склада. Причина в документах выглядела простой: товар физически разбит или испорчен.
Если смотреть только на магазин, можно спорить с директором: плохо приняли, плохо хранили, плохо контролировали. Но паттерн повторялся в нескольких точках и был привязан ко времени после поставки. Это уже другой сигнал.
Начали разбираться и увидели, что причина была раньше. Товар повреждался в логистике при сборке или доставке.
Для магазина это было списание. Для бизнеса - сигнал, что потери рождаются еще до полки.
Именно такие ситуации меняют качество управления. Потому что без данных магазин остался бы крайним. С данными стало видно, что магазин только оформляет финансовый финал ошибки, которая появилась на предыдущем участке цепочки.
Такие разборы пошли по разным направлениям. Если причина повторялась по поставщику - разговор уходил в закупки и категорийный контур. Если проблема была в коротком остаточном сроке годности - разбирали условия поставки и приемки. Если товар не успевал продаваться до критичного срока - смотрели заказ, спрос, промо и скорость выбытия. Если товар числился, но не был доступен клиенту - разбирали корректировки, выкладку, хранение и работу магазина. Если появлялись подозрительные расхождения - подключалась СБ.
Важное отличие от обычного разбора списаний было в том, что обсуждали не "кто плохо списал". Обсуждали "где возникла причина, из-за которой товар дошел до списания".
Что это дало поставщикам, заказу и промо
Коррекции начали работать не только как операционный инструмент магазина, но и как база для решений выше.
В следующую договорную кампанию с поставщиками добавили требования по остаточному сроку годности и право магазина отказаться от приемки, если товар с таким сроком объективно не успеет продаться без риска списания. Это уже не было спором на уровне ощущений. У категорийных менеджеров появились цифры: по каким товарам поставщика возникали проблемы, какие причины повторялись, где были повреждения, где срок, где качество, где спрос не соответствовал объему.
Такие данные усиливают переговорную позицию. Не "у нас с вашим товаром проблемы", а "вот что происходило с вашим товаром в сети, вот причины, вот магазины, вот сроки, вот потери".
Отдельно улучшилась работа с вероятностью списания. Когда структура коррекций стала нормальной, стало проще настраивать анализатор риска. Если простая математика показывала, что товар не успевает продаться до критичного срока, можно было вмешиваться раньше: запускать скидку, распродажу, локальное промо, менять объем следующего заказа, перераспределять товар или блокировать приемку с плохим сроком.
Раньше компания часто констатировала потерю после факта. Теперь она видела, что товар движется к потере.
Это разные уровни управления.
Почему это не готовая "идеальная модель"
Здесь легко сделать ошибку и продать решение как волшебную систему. На практике это был не готовый продукт, а процесс.
У него была цена. Нужны нормальные причины коррекции. Нужна дисциплина магазина. Нужна работа с паттернами. Нужен код, который будет ловить повторяющиеся сигналы и отдавать их профильным службам. Нужны люди, которые будут не просто смотреть отчет, а разбирать причины и менять процесс. Нужна готовность признать, что часть списаний рождается не в магазине, а в заказе, поставке, промо, логистике или данных.
Но именно поэтому модель и была рабочей. Она не требовала от магазина длинных писем и ручных объяснений. Она переводила проблему в простую операцию: отсканировал штрихкод, указал количество, выбрал причину. Дальше система искала паттерны, а профильные службы получали сигналы.
Когда списание все-таки случалось, был след. Когда товар стал проблемным. Кто это увидел. Какая причина была выбрана. Был ли OOS. Был ли сигнал. Куда он ушел. Что сделали. Где в цепочке возникла первичная причина.
По таким разборам следующие списания уже снижались. Не потому, что кто-то сильнее кричал на магазин. А потому, что компания начинала исправлять источник.
По смыслу это близко к FinOps-логике в широком смысле. Не про облака и серверы, а про управление деньгами внутри операционного процесса.
Деньги теряются не в момент отчета. Они теряются раньше - в заказе, поставке, сроках, выкладке, промо или грязном остатке. Отчет только показывает потерю позже.
Результат
Списания снизились на 25%.
Но для меня главный результат был не только в этой цифре. Мы получили более точные остатки и более честную картину того, что происходит с товаром внутри магазина. У магазина появилась мотивация показывать реальность, а не прятать ее до инвентаризации или следующего периода. У категорийных менеджеров появились данные для переговоров с поставщиками. У логистики - сигналы по повреждениям. У операционного контура - причины проблем с выкладкой, ротацией и доступностью. У ИТ и аналитики - база для ранних предупреждений.
И самое важное: KPI магазина стал справедливее.
Да, итоговый процент списаний оставался показателем магазина. Но теперь его можно было профилировать. Если причина была в магазине - магазин отвечал. Если причина была в поставке, логистике, промо, сроках или заказе - ответственность возвращалась туда, где она возникла.
Это и есть нормальная управляемость. Не найти крайнего в конце цепочки, а увидеть, где бизнес сам создал будущую потерю.
Вывод для собственника
Списания нельзя снижать только приказом. Особенно если этот приказ заставляет магазин бояться честно показывать проблему.
Плохой KPI может сделать отчет красивее, а бизнес - слепее. Магазин не списывает вовремя, система видит грязный Stock on Hand, заказ рассчитывается на неверных данных, OOS становится хуже, а потери просто переезжают из одного периода в другой.
Списания снижаются не запретом. Они снижаются тогда, когда товар в системе начинает соответствовать реальности, а причина потери возвращается туда, где она возникла.
Списание - это место, где ошибка стала видимой в деньгах.
Управлять надо раньше.