Единый контроль остатков WB/Ozon/Яндекс Маркета: как выстроить систему, если вы продаёте на нескольких площадках

Мультиплощадочность почти всегда начинается как рост. А потом превращается в рутину: три кабинета, разные статусы и отчёты, разные модели FBO/FBS, плюс свой склад или фулфилмент. В какой-то момент команда перестаёт отвечать на простой вопрос: "Сколько товара у нас реально есть и где он доступен к продаже?"

И это уже не вопрос удобства - это деньги. Потому что при мультиплощадочности происходят две крайности одновременно:

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

В этой статье мы покажем систему, которая помогает держать остатки под контролем, даже если вы продаёте на WB, Ozon и Яндекс Маркете одновременно. Без сложной математики, но с проверяемыми точками контроля и регламентом, который реально внедряется.

Почему остатки "разъезжаются" именно при мультиплощадочности

На одной площадке можно держать процесс в голове. На трёх - уже нет, потому что у каждой площадки свои особенности:

• разные понятия "остатка" (всего / доступно / в пути / резерв),
• разные циклы обновления данных,
• разные сценарии возвратов и переупаковки,
• разные правила доступности по регионам и срокам доставки,
• разные требования к складу продавца (FBS) и складу маркетплейса (FBO).

В итоге один и тот же товар одновременно может быть:

• "в наличии" в кабинете,
• "в резерве" под заказ,
• "в транзите" между узлами,
• "в возвратах" и временно недоступен,
• "в учёте" в 1С как остаток,
• "на полке" физически на складе.

Точка проверки: любая система контроля остатков должна различать минимум 4 состояния: доступно к продаже / в резерве и обработке / в транзите / физическое наличие. Если у вас один показатель "остаток", мультиплощадочность всегда будет давать хаос.

Что такое "единый контроль остатков" на практике

Единый контроль - это не "одна таблица на всё". Это единая логика и один управленческий ответ.

Минимально в системе должны быть:

1. Единый справочник SKU (одна позиция = одна сущность, с вариантами).
2. Единая карта складов (ваш склад, FBO-склады, FBS-склады, фулфилмент).
3. Единый статусный контур (доступно / резерв / транзит / возвраты / карантин).
4. Регламент сверки (кто, когда и что проверяет).
5. Пороговые правила (когда нужно пополнять и когда стоп пополнений).

Точка проверки: если разные люди в команде отвечают на вопрос про остаток разными цифрами - у вас нет единого контроля. Даже если все "вроде считают правильно".

Главная ошибка мультиплощадочности: путаница SKU и вариантов

До того как говорить про сверки, надо назвать самую частую причину расхождений: один и тот же товар живёт в разных системах под разными артикулами/штрихкодами/вариантами.

Например:

• на WB это один артикул с вариациями,
• на Ozon - несколько SKU с разными атрибутами,
• в учёте - общий номенклатурный элемент без вариантов.

И тогда любое движение остатка становится "неподтверждаемым".

Точка проверки: если вы не можете за 30 секунд ответить "какой SKU в учёте соответствует карточке WB и карточке Ozon", система будет разъезжаться при любом росте.

Как построить основу: единый SKU-справочник за 1-2 недели

Шаг 1. Определите "главный SKU" в учёте

Это ваш внутренний идентификатор, который не меняется, даже если карточка на площадке меняется.

Шаг 2. Привяжите к нему все площадочные карточки

Для каждого SKU фиксируем:

• соответствующий артикул/идентификатор на WB,
• на Ozon,
• на Яндекс Маркете,
• плюс вариантность (размер/цвет/комплектация).

Шаг 3. Введите правило "вариант = отдельная управленческая единица"

Если вы продаёте размеры/цвета - планировать и пополнять нужно по вариантам, иначе будет "вроде товар есть", но нужного варианта нет.

Шаг 4. Зафиксируйте стандарт названий

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

Точка проверки: успешный SKU-справочник - это когда вы можете выгрузить отчёт по остаткам/продажам и без ручных правок собрать единую картину по всем площадкам.

Единая карта складов: какие склады вы должны видеть в одной модели

В мультиплощадочности обычно есть 3-6 "мест хранения":

1. ваш склад (или фулфилмент),
2. FBO-склады маркетплейсов,
3. FBS-склады (если вы отгружаете со своего склада),
4. транзит/перемещения,
5. возвраты/карантин,
6. иногда - "буфер" (резерв под сборку).

Важно не просто перечислить склады, а разделить их по ролям:

• продаваемый остаток (доступно к заказу),
• непродаваемый остаток (резерв, транзит, возвраты, карантин),
• физический остаток (что реально лежит).

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

Регламент контроля на неделю: что реально проверять, чтобы не жить в кабинетах

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

Ежедневно (10-15 минут)

• список SKU в красной зоне по дням до нуля (по продаваемому остатку),
• контроль доступности по 10-20 ключевым SKU,
• фиксация "что в пути" и когда станет доступно.

Раз в неделю (60-90 минут)

• сверка расхождений по остаткам (учёт ↔ кабинеты ↔ факт склада),
• контроль лагов пополнения (сколько дней реально проходит до доступности),
• обновление точки заказа и страхового запаса по топ-SKU.

Раз в месяц (1-2 часа)

• пересмотр ассортимента: что стало балластом,
• стоп-лист пополнений,
• корректировка риск-запаса по сезонности.

Точка проверки: если сверка занимает 4-6 часов каждую неделю - у вас нет стандарта, и вам нужна автоматизация или структурирование источников данных.

Как предотвратить две ключевые потери: out-of-stock и избыточный завоз

1) Защита от out-of-stock

В мультиплощадочности out-of-stock чаще всего "рождается" так:

• товар уходит в резерв на одной площадке,
• остаток не обновился на другой,
• продажи ускорились из-за акции,
• поставка ещё в приёмке/размещении.

Решение: правило "дни до нуля" + лаг пополнения + риск-запас.

2) Защита от избыточного завоза

Избыточный завоз появляется, когда вы:

• пополняете хвост "по привычке",
• не учитываете возвраты и сезонность,
• не ведёте стоп-лист по балласту.

Решение: горизонты покрытия по группам товаров + стоп-лист пополнений.

Точка проверки: если у вас одновременно "ноль на ходовом" и "склад забит хвостом", причина почти всегда одна: нет разделения ассортимента на режимы (локомотивы / средние / хвост).

Таблица 1: "Слои остатка" - что считать, чтобы цифры не конфликтовали

Таблица 2: как найти расхождение за 15 минут (по симптомам)

Типовые ошибки мультиплощадочности (которые лучше исправить до роста)

1. Нет единого SKU-справочника.
2. Сверяют "всё" вместо контрольных SKU.
3. Считают план по "остатку всего", игнорируя доступность.
4. Не учитывают лаг до доступности.
5. Пополняют хвост по тем же правилам, что локомотивы.
6. Рекламу запускают без привязки к доступному остатку.

Точка проверки: если вы не можете назвать 10 SKU, которые кормят ваш бизнес, и держать по ним отдельный режим контроля - мультиплощадочность будет "ломать" прибыль при каждом росте.

Вопросы и ответы

TotalCRM как "центр правды" для мультиплощадочности: что меняется в управлении уже в первый месяц

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

TotalCRM помогает выстроить единую систему:

• сводит остатки и доступность по всем площадкам в управленческий формат;
• поддерживает единый SKU-справочник и сопоставление вариантов;
• показывает риски out-of-stock заранее (по контрольным SKU);
• помогает внедрить регламент сверки и планирования поставок;
• снижает ручную нагрузку: меньше "сводных таблиц", больше решений по факту.

Если вы хотите, чтобы мультиплощадочность стала ростом, а не хаосом, команда TotalCRM поможет настроить контур контроля: остатки → доступность → лаги → план пополнения → финальная сверка.