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

Логотип компании
Сквозная видимость запасов. Почему цифры сходятся, а товара на полке нет
Изображение AI
Когда в компании говорят, что у них есть сквозная видимость запасов, обычно это звучит весьма уверенно. ERP показывает остатки, WMS видит склад, магазины работают в своей системе, логистика отслеживает перемещения, BI собирает все это в понятные отчеты.
Каналы и подписка
IT-World там, где вам удобно

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

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

Я много раз видел одну и ту же сцену. Мы садимся с командой разбирать конкретную проблему. Коммерческий блок говорит: товар должен быть в наличии, система его видит. Логистика отвечает: со склада все ушло вовремя. Магазин говорит: на полке пусто, покупатель ушел. Финансы при этом смотрят на отчет и не понимают, откуда вообще взялся конфликт, если цифры в системе вполне нормальные. Именно в этот момент становится ясно, что видимость запасов и управляемость запасов - не одно и то же.

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

Где на самом деле находится источник правды

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

ERP отвечает за учетную и финансовую логику. WMS видит складскую фактуру.

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

На одной из диагностик у нас была показательная ситуация. ERP показывала остаток 120 единиц, складская система 98, а магазин фактически жил с наличием 64. Когда начинаешь разбирать это глубже, выясняется, что никто специально не искажал данные. Просто ERP считала один контур, склад другой, а магазин существовал в третьей реальности, где часть товара уже была в операционном обороте, часть еще не выложена, а часть формально числилась, но не была доступна клиенту.

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

Почему данные устаревают быстрее, чем бизнес успевает это заметить

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

На совещаниях это редко звучит драматично. Обычно говорят что-то вроде: «у нас остатки обновляются каждые полчаса» или «данные приходят пакетно, но этого хватает». На бумаге это может выглядеть приемлемо. Но в реальной операционной среде этих получаса иногда достаточно, чтобы потерять продажи, принять неверное решение по пополнению или не увидеть локальный out-of-stock.

Я видел кейсы, где товар уже продан, а система еще считает его доступным. И обратную ситуацию тоже: товар уже приехал в магазин, но в системе он все еще «в пути». Для клиента разницы нет. Он просто видит пустую полку. Для бизнеса это уже не вопрос точности, а вопрос потерянной выручки.

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

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

Где цепочка ломается чаще всего

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

Первый типичный разрыв находится между системами. ERP, WMS, POS, TMS и магазинный контур редко имеют одинаковую модель данных и одинаковую скорость обмена. На этих переходах появляются задержки, ошибки маппинга, дубли и расхождения в статусах. Пока компания растет медленно, это маскируется ручными корректировками. Когда скорость операций возрастает, проблема начинает бить уже по бизнесу.

Второе слабое место - между процессами. Продажа могла пройти, но списание еще не произошло. Поставка приехала, но приемка не завершена. Перемещение оформлено, но фактическое состояние объекта не совпадает с учетным. Это тот самый слой, где операция в реальном мире и операция в системе идут параллельно, но не синхронно.

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

Именно поэтому out-of-stock нельзя честно анализировать только как проблему поставки или закупки. Очень часто проблема возникает уже после того, как товар фактически доехал.

Почему out-of-stock часто ошибочно считают проблемой поставок

У компаний почти всегда есть соблазн объяснить отсутствие товара самым очевидным образом. Поставщик сорвал срок. Логистика не довезла. Склад не отгрузил. Иногда это правда. Но когда начинаешь разбирать out-of-stock не по ощущениям, а по причинам, картина обычно становится менее удобной.

В одном из проектов с розничной сетью разбор показал, что только около 10% случаев out-of-stock были связаны с реальным дефицитом товара. Все остальное находилось внутри самой компании. Около 40% случаев были связаны не с поставкой как таковой, а с тем, что цепочка не отрабатывала отклонение вовремя. Еще около 30% относились к проблемам выкладки и внутреннего движения в магазине. Примерно 20% давали ошибки и задержки в данных. И только небольшая доля действительно означала, что товара не было физически.

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

Почему красивые BI-дашборды не спасают

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

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

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

Иногда даже хуже: он создает ощущение контроля там, где управления по факту нет.

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

Почему центр не может управлять всем в одиночку

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

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

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

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

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

Поставщики, логистика и контроль отклонений

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

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

Рабочая модель выглядит иначе. Заказ, подтверждение, факт отгрузки, приемка, расхождение, замена, эскалация и новое решение должны быть связаны в один живой контур. Именно здесь становится видно, насколько поставщик управляем, насколько зрелы внутренние процессы и насколько данные помогают бизнесу, а не просто лежат в системе.

Какие метрики действительно показывают зрелость, а какие только успокаивают руководство

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

По моему опыту, по-настоящему полезны те показатели, которые отражают управляемость, а не только состояние. Например, время от возникновения отклонения до реакции. Доля out-of-stock, которые система не увидела заранее. Доля расхождений между системным и фактическим наличием на уровне полки. Объем ручных корректировок, без которых отчетность перестала бы сходиться. Доля инцидентов, где компания узнала о проблеме не из системы, а от магазина, сотрудника или клиента.

Эти метрики часто неприятны для руководства. Но именно поэтому они полезны. Они показывают не то, насколько красиво устроен учет, а то, насколько компания реально управляет потоком товара.

Заключение

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

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

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

Именно в этот момент сквозная видимость перестает быть отчетом и становится деньгами.

Опубликовано 22.04.2026

Похожие статьи