Согласно исследованиям аналитического агентства Data Insight, почти все онлайн-покупатели (а это более 60 % россиян) для совершения покупок предпочитают маркетплейсы. Среди преимуществ маркетплейсов называют уровень цен, широту ассортимента, удобство получения заказов, скорость доставки и пр.

Однако каждая новая площадка для
производителя и продавца — это не только новые возможности, но и дополнительные
расходы: на изучение документации по площадке, дополнительные интеграции,
постоянный мониторинг изменений в политике маркетплейса, контроль актуальности
информации и т. д. В этой статье Андрей Путин, управляющий партнёр KT.Team,
рассказывает, как снизить расходы на работу с маркетплейсами и повысить
точность информации при помощи IT-инструментов. Рассматриваем применение этих
инструментов на примере кейса клиента KT.Team — производителя бытовой техники
Polaris.
Как рутинные ручные операции
затрудняют освоение новых маркетплейсов и усложняют работу с уже освоенными
Опустим чисто юридическую сторону вопроса
в части заключения договоров и сосредоточимся на техническом аспекте
сотрудничества.
Минимум, который требуется от продавца, —
корректно заполнить карточку товара и предоставить медиафайлы правильных
форматов и размеров (при условии, что все вопросы логистики вы передаёте
маркетплейсу). Максимум — вам предстоит настроить интеграции своих систем с
системами маркетплейса, чтобы передавать им информацию об актуальных ценах,
складских остатках, условиях доставки.
Выглядит как затратное, но всё-таки
одноразовое мероприятие. На самом же деле…
- У вас могут поменяться
характеристики товаров. Например, в 10 наборах чая вы замените «тегуаньинь» на
«луиньло». Вам придётся менять описания и карточки этих наборов, выгружать
новые медиафайлы, прикладывать новые инструкции, корректировать цены и т. д. - У маркетплейса могут поменяться
требования к карточке товара или медиафайлам. Например, вместо картинок с
соотношением сторон 3:4 теперь нужны только картинки с соотношением 1:1. Или
габариты товара нужно указывать не в одном общем поле, а в трёх отдельных — для
длины, ширины и высоты. Придётся перебирать вручную все карточки товаров и
проверять их на соответствие новым стандартам. - У вас могут поменяться или
обновиться системы, ответственные за какой-то аспект работы с маркетплейсом.
Например, обновится система WMS, и придётся исправлять связанные с ней
интеграции. Во время доработки и отладки интеграций информация об остатках на
маркетплейсе будет некорректной. - У самого́ маркетплейса могут
поменяться или обновиться системы, и вам вновь придётся корректировать
интеграции.
Масса рутинных ручных задач. И их
количество увеличивается пропорционально тому, на скольких маркетплейсах вы
размещаете свой товарный ассортимент.
Задача становится ещё более затратной,
если ваши цифровые активы и маркетинговые данные о товарах хранятся
нецентрализованно.
Как Polaris оптимизировали
работу с маркетплейсами с помощью двух внедрений
Polaris — швейцарский бренд бытовой
техники. В активной матрице компании — более 700 позиций (ассортимент — более 1
тыс. SKU). Polaris находится на первых строчках российского рейтинга
популярности в сегменте мелкой бытовой техники.
Техника бренда продаётся в торговых
сетях, через собственный интернет-магазин, а также на четырёх маркетплейсах:
OZON, «Яндекс.Маркет», Wildberries, AliExpress.
До того, как Polaris обратились в KT.Team
за IT-решением задачи, данные заполняли вручную через личные кабинеты на
маркетплейсах. В случае с каждой площадкой продуктовый менеджер прописывал
информацию для карточки по стандартам, диктуемым конкретно этим маркетплейсом,
затем менеджер маркетплейса проверял полученные данные и вносил их. Для каждого
маркетплейса нужна была своя команда.
Вся информация хранилась в «1С» в пяти форматах: для собственного интернет-магазина и для четырёх маркетплейсов. Как результат, «1С» была переусложнена, утяжелена и выполняла несвойственные ей функции PIM-системы.

Шаг первый: наведение
порядка в данных с помощью PIM-системы
Представьте, что жители пяти соседних
квартир дают разное описание, например, берёзе. Одни говорят, что у неё зелёные
листья, другие — что изумрудные. Одни указывают высоту в метрах, другие — в
сантиметрах. Все эти описания непротиворечивы, но назвать эталоном нельзя ни
одно из них.
То же самое происходило и с данными о
товарах Polaris на момент начала проекта: параллельно существовало не менее
пяти вариантов информации о каждом товаре. Ни один из вариантов не был
эталонным, поэтому все изменения параллельно вносились пятью
контент-менеджерами на основании пяти сигналов от продуктовых менеджеров.
Чтобы уменьшить число ручных операций, в первую очередь нужно было создать единый центр хранения золотого стандарта информации о товарах. В качестве такого центра мы выбрали
Каждому товару в Pimcore теперь
соответствует только одна, но максимально полная карточка. Здесь хранятся все
сведения о товаре: от цвета и габаритов до комплектации и технических
характеристик.
Карточка товара — это мастер-запись. Внутри неё есть и универсальные поля, необходимые на всех каналах продаж, и уникальные поля, данные из которых нужны только в Wildberries, «Яндекс.Маркете» или каком-либо другом маркетплейсе. Например, опции управления мультиваркой для карточки на OZON описаны с помощью четырёх полей, а на Wildberries — только одного. По смыслу эти записи непротиворечивы, но каждая из них соответствует требованиям «своего» маркетплейса.

Для каждого маркетплейса внутри PIM-системы формируется собственный набор атрибутов. Это дочерние карточки внутри мастер-записи. Контент-менеджер конкретного маркетплейса работает не со всем объёмом информации о товаре, а только с данными для «своего» канала продаж. Он же проверяет, дополняет и контролирует информацию на соответствие требованиям.

Шаг второй: автоматизация
передачи данных на маркетплейсы
Внедрив PIM-систему, мы устранили
проблему множественных эталонов. Но даже из единого источника информация как-то
должна попадать на маркетплейсы. И вариант «Ctrl + C, Ctrl + V» по-прежнему не
выглядел оптимальным: он слишком ёмок по времени и уязвим для ошибок.
Поэтому команда KT.Team предложила Polaris настроить
Почему мы не предложили прямую
интеграцию? На первый взгляд, разработка прямой интеграции между системами
занимает ненамного больше времени, чем разработка в графической студии ESB.
Точно так же предстоит продумать логику, конвертацию информации в нужный формат
и выгрузку в нужные поля.
Но в долгосрочной перспективе поддержка
прямых интеграций более трудозатратна. Любое изменение в требованиях,
структуре, коде связанных систем провоцирует долгий рефакторинг.
ESB выигрывает, во-первых, на этапе
разработки. Развитые ESB-продукты, такие как WSO2, используют графический интерфейс
построения интеграций. В них уже есть готовые коннекторы с IT-системами и
модули для перевода информации в различные форматы. Кроме того, в ESB-системах
предусмотрены встроенные и подключаемые сервисы мониторинга, которые
отслеживают, передана ли информация «по адресу» и — если нет — на каком этапе
возникла ошибка.
Во-вторых, на этапе поддержки WSO2, как и
другие ESB, позволяет экономить время разработчиков и быстрее реагировать на
изменения. Например, если меняются требования системы-получателя (маркетплейса),
команде ESB надлежит доработать только коннектор с маркетплейсом. Логика всех
остальных элементов интеграции не нуждается в правке.
Поэтому мы выстроили интеграции между
PIM-системой Polaris и маркетплейсами через ESB-слой. Система WSO2:
- забирает информацию о товарах из
PIM; - при необходимости переводит её в
формат, нужный для маркетплейса; - согласно маппингу (заданным
правилам) распределяет информацию из полей карточки товара в PIM по полям
карточки товара на маркетплейсе.
Бонус: уменьшение вложений
в интеграции
Внедрение ESB-системы означает не только
уменьшение объёма ручной работы для контент-менеджеров сегодня, но и более
прозрачную и экономичную работу с каналами продаж завтра.
Если характеристика товара изменится на
стороне Polaris, контент-менеджеру будет достаточно обновить её в PIM-системе.
ESB заберёт обновлённую информацию, доставит её на маркетплейс и распределит по
полям карточки товара.
Если на стороне маркетплейса изменится
структура карточки товара или сама система, разработчикам не придётся
переписывать сотни строк кода. В графическом интерфейсе ESB-системы достаточно
будет скорректировать один или два блока и заменить коннектор. Выигрыш по
времени, согласно опыту KT.Team, — как минимум в четыре раза.
Если Polaris решат продавать товары на ещё одном маркетплейсе или интернет-магазине, IT-команда сможет легко разработать новую интеграцию, используя логику уже готовых интеграций в WSO2.

Состояние на 2023 год
Сейчас Polaris перешли к стадии самостоятельной работы с ESB и технической поддержке. Ключевые менеджеры прошли обучение работе с новыми системами. Новые категории товаров размещаются на маркетплейсах через PIM-систему и сервисную шину. Все изменения в характеристиках продуктов автоматически отображаются на маркетплейсах в течение нескольких часов после публикации в PIM.
Подписывайтесь на наш канал в
Сообщение
[yuzo id=820442 ]