Сколько это действий

120 артикулов по пять размеров дают 600 SKU. Четыре канала превращают их в 2 400 карточек или вариантов, каждую из которых кто-то завёл руками или загрузил таблицей. Смена цены на половину коллекции делается четыре раза. Каждое изменение остатков на складе должно попасть в четыре места, и если одно из них отстало на час, покупатель на площадке оформит заказ на размер, которого уже нет.

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

Почему копирование карточки не работает

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

У каждой площадки своё дерево категорий и свой набор обязательных характеристик: то, что на одной площадке называется «Джинсы», на другой лежит в другой ветке и требует других полей. На своём сайте нужны заголовки и описания, написанные для поиска, на площадке действуют её правила оформления. Цены разные, потому что комиссии разные. Ассортимент разный: распродажные размеры можно оставить только на площадках, новинку показать сначала на сайте.

Копия карточки всё это теряет в момент копирования. Дальше у вас четыре независимых объекта, и каждое изменение нужно помнить внести в четыре места. Инструмент стал быстрее, а проблема осталась прежней.

Один товар, несколько публикаций

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

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

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

Откуда берутся данные

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

Сопоставление делается один раз. Когда в 1С появляется новое значение или новая категория, оно попадает в очередь: завести у себя или связать с существующим. Новые товары из учётной системы можно сразу публиковать в выбранные каналы, без ручного шага. Цены и остатки после этого обновляет обмен, менеджер в этом не участвует.

Где этот подход не спасает

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

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

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

Как это устроено в Skuby

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

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

Про границы. Чистку номенклатуры в учётной системе система за вас не сделает, её мы разбираем на аудите и закладываем в план. И модерация площадок остаётся на стороне площадок.

Что посчитать у себя

  • Число SKU, умноженное на число каналов. Это количество карточек, которые вы сейчас ведёте, даже если так о них не думаете.
  • Сколько действий нужно, чтобы изменить цену одного товара во всех каналах, и сколько раз за последний месяц это делали.
  • Где сейчас живёт главная версия описания товара. Если ответ «в каждом кабинете своя», расхождения уже есть.
  • Сколько времени проходит между изменением остатка на складе и его появлением на каждой площадке.

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