Как уменьшить затраты на поддержание актуальной информации о товарах на маркетплейсах с помощью ESB

Согласно исследованиям аналитического агентства 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 на момент начала проекта: параллельно существовало не менее пяти вариантов информации о каждом товаре. Ни один из вариантов не был эталонным, поэтому все изменения параллельно вносились пятью контент-менеджерами на основании пяти сигналов от продуктовых менеджеров.

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

Каждому товару в Pimcore теперь соответствует только одна, но максимально полная карточка. Здесь хранятся все сведения о товаре: от цвета и габаритов до комплектации и технических характеристик.

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

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

‍

Шаг второй: автоматизация передачи данных на маркетплейсы

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

Поэтому команда KT.Team предложила Polaris настроить передачу информации о товарах на маркетплейсы с помощью интеграции через систему-посредник — ESB.

Почему мы не предложили прямую интеграцию? На первый взгляд, разработка прямой интеграции между системами занимает не намного больше времени, чем разработка в графической студии 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.