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

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

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

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

Андрей Путин, управляющий партнёр KT.Team, рассказывает, как снизить расходы на работу с маркетплейсами и повысить точность информации при помощи IT-инструментов.

Рассматриваем применение этих инструментов на примере кейса клиента KT.Team - производителя бытовой техники Polaris.

У вас могут поменяться характеристики товаров. Например, в 10 наборах чая вы замените «тегуаньинь» на «луиньло».

Вам придётся менять описания и карточки этих наборов, выгружать новые медиафайлы, прикладывать новые инструкции, корректировать цены и т. д. У маркетплейса могут поменяться требования к карточке товара или медиафайлам. Например, вместо картинок с соотношением сторон 3:4 теперь нужны только картинки с соотношением 1:1.

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

Придётся перебирать вручную все карточки товаров и проверять их на соответствие новым стандартам. У вас могут поменяться или обновиться системы, ответственные за какой-то аспект работы с маркетплейсом. Например, обновится система WMS, и придётся исправлять связанные с ней интеграции.

Во время доработки и отладки интеграций информация об остатках на маркетплейсе будет некорректной. У самого́ маркетплейса могут поменяться или обновиться системы, и вам вновь придётся корректировать интеграции.

Задача становится ещё более затратной, если ваши цифровые активы и маркетинговые данные о товарах хранятся нецентрализованно.

Техника бренда продаётся в торговых сетях, через собственный интернет-магазин, а также на четырёх маркетплейсах: OZON, «Яндекс.Маркет», Wildberries, AliExpress.

До того как Polaris обратились в KT.Team за IT-решением задачи, данные заполняли вручную через личные кабинеты на маркетплейсах. В случае с каждой площадкой продуктовый менеджер прописывал информацию для карточки по стандартам, диктуемым конкретно этим маркетплейсом, затем менеджер маркетплейса проверял полученные данные и вносил их.

Для каждого маркетплейса нужна была своя команда.

Вся информация хранилась в «1С» в пяти форматах: для собственного интернет-магазина и для четырёх маркетплейсов.

Как результат, «1С» была переусложнена, утяжелена и выполняла несвойственные ей функции 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 надлежит доработать только коннектор с маркетплейсом.

Логика всех остальных элементов интеграции не нуждается в правке.