Карточка товара в пяти системах: когда e-commerce нужна PIM, а не ещё одна интеграция

Менеджер меняет материал товара в учётной системе. Контент-менеджер через час правит описание на витрине. На маркетплейсе остаётся прежняя характеристика, а в фильтре магазина товар всё ещё попадает в старую группу. Формально у бизнеса одна карточка. В работе их уже несколько, и каждая считает себя главной.

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

Привет, я Антон Фокин — CEO Qtim

Эта статья даёт способ отличить две задачи: навести порядок в существующих системах или выделить управление товарной информацией в отдельный контур PIM — Product Information Management. PIM здесь означает не «главную базу всего бизнеса», а место, где команда ведёт модель товара, обогащает её, проверяет и готовит к публикации в каналы.

Почему одна карточка распадается на пять рабочих объектов

Карточка на витрине выглядит цельной. Внутри неё живут артикул, категория, характеристики, варианты, фотографии, документы, переводы и правила показа. В документации Microsoft такой набор тоже описан как несколько видов продуктовых данных, а не как поле «название и описание».

Поэтому у одной карточки часто появляются пять контуров:

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

Интеграция передаёт данные. Управление данными задаёт правила

Интеграция отвечает на вопрос: как передать значение из системы А в систему Б. Это необходимая работа. Она не отвечает сама по себе на другой вопрос: кому разрешено изменить значение и что произойдёт, когда два канала требуют разное представление одного свойства.

Возьмём свойство «материал». В учётной системе оно может быть техническим справочником. На витрине — читабельным описанием. Маркетплейс может требовать значение из закрытого списка. Без согласованной модели команда начинает хранить три варианта одного смысла и вручную следить, какой из них куда отправлять.

В нашем кейсе HOTZ была мультибрендовая e-commerce-витрина автоэмалей и сопутствующих материалов. Наша команда спроектировала сквозной каталог и интеграцию с 1С, поэтому витрина опиралась на единую товарную матрицу; этот механизм показал, почему до выбора PIM важно определить ядро каталога и границы обмена.

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

Диагностика: пять вопросов до выбора платформы

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

1. Где создаётся поле и кто имеет право его менять?
2. Какая запись считается верной при конфликте двух значений?
3. Какие варианты наследуют свойства товара, а какие требуют собственных значений?
4. Какие поля обязательны для каждой витрины и как проверяется их полнота до публикации?
5. Где виден журнал: что, кем и в какой канал было отправлено?

Это практический критерий: пока на любой вопрос отвечают названием человека в чате или папки с таблицами, сначала стоит описать процесс и владельцев. Когда правила уже есть, но их невозможно поддерживать в нескольких системах, появляется основание проектировать PIM-контур.

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

Что меняется, когда каналов становится больше

Каждый новый канал приносит свою таксономию, обязательные атрибуты и формат. В отчёте GS1 по Индии описано, как одинаковый SKU приходится повторно сопоставлять для маркетплейсов, сервисов быстрой доставки (q-commerce) и прямых интернет-магазинов бренда (D2C). Это не статистика про Россию, но механизм узнаваем: канал проверяет свою форму данных, а не внутреннюю логику компании.

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

Полнота данных важна и для покупателя. В исследовании Syndigo более 8 500 респондентов из нескольких стран участвовали в опросе; 44% сообщили, что отказывались от покупки из-за недостатка информации о товаре. Это не измерение российского рынка и не обещание эффекта от PIM. Оно объясняет, почему вопрос о заполненных атрибутах нельзя оставлять только технической команде.

Когда отдельный PIM-контур пока не нужен

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

Возражение «сначала поставим PIM, потом разберёмся» тоже понятно: хочется быстро закрыть накопившиеся расхождения. Но платформа не выберет владельца цены, не договорится о словаре атрибутов и не определит, что считать готовой карточкой. Эти решения должен принять бизнес вместе с командой, которая ведёт каталог.

Признаки для проектирования PIM-контура

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

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

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

Если карточка сейчас живёт в нескольких системах, соберите для одной категории матрицу полей и владельцев. В Qtim мы поможем проверить эту карту, определить границы интеграций и решить, оправдан ли PIM-контур.