Как производителю мебели управлять данными о товарах до внедрения PIM

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

Проблема усиливается, когда данные распределены между Excel, Google Sheets, 1С, сайтом, Bitrix24, личными кабинетами маркетплейсов и знаниями отдельных менеджеров. В такой схеме бизнес теряет не только время контент-менеджеров: покупатель видит неполный ассортимент, менеджер не уверен в наличии цвета, карточка на marketplace собирается руками, а производство получает уточнения после заказа.

Для производителя мебели удобно разделить данные на три слоя.

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

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

Канальная логика определяет, какие атрибуты и тексты нужны сайту, маркетплейсам, дилерам, B2B-порталу или будущей отраслевой площадке.

Если смешать эти слои, PIM-проект превращается в попытку сделать одну систему «за всё».

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

Когда PIM спроектирован как товарный центр, компания получает не только «красивые карточки».

Новая модель мебели заводится через справочники и шаблоны, а не через ручное копирование десятков карточек. Контент-менеджер видит, какие поля не заполнены до публикации.

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

Сайт и маркетплейсы получают карточку в своем формате.

Эти примеры важны не как «возьмите такую же систему».

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

Первый этап - не установка коробки, а короткая диагностика данных и процессов. На ней нужно пройти путь товара от идеи до продажи:

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

Где хранятся материалы, ткани, фурнитура и ограничения по комбинациям.

Какие данные нужны производству, продажам, складу, бухгалтерии и маркетингу.

Что сейчас является источником цены и остатка.

Какие каналы продаж нужно подключить в первой очереди.

PIM-проект в мебельном производстве почти всегда затрагивает несколько систем.

Поэтому важно не превращать PIM в центральный монолит, в котором пытаются хранить все данные компании.

Практичная архитектура строится как слабосвязанный контур: PIM/DAM управляет товарным контентом, медиа, вариантами и правилами готовности карточек; 1С/ERP отвечает за учет, цены, закупки, документы и финансовые процессы; WMS или складской контур отвечает за фактические остатки и движения; API/ESB/events связывают системы и фиксируют ошибки обмена; сайт, marketplace и B2B-портал получают уже подготовленные карточки.

Такой подход дает отчуждаемость: систему можно поддерживать внутренней командой или передать другому подрядчику, потому что границы понятны, обмены описаны, а бизнес-логика не спрятана в случайных Excel-файлах. В наших кейсах похожая логика применялась в интеграциях с 200+ системами 1С, в eCommerce-интеграции с marketplace через WSO2 ESB и в проекте мебельного холдинга, где point-to-point обмены заменялись слабосвязанным контуром на Kafka.