В 2 раза больше заказов для интернет-магазина детских товаров после интеграции с маркетплейсами

1. Вводная задача от заказчика, проблематика, цели

Магазин для будущих мам и малышей «Олант» обратился с запросом — автоматизировать процесс взаимодействия интернет-магазина с маркетплейсами.

До этого маркетолог вручную подключал, настраивал и выгружал товары на площадки:

— Добавлял единицы товаров в excel-файл и загружал его через личный кабинет маркетплейса.

— Вносил в таблицу данные о товаре. Один товар — 10 минут, а на каждом маркетплейсе размещается по 3000+ товаров.

— Вручную актуализировал цены и информацию об остатке товара.

— Вручную отслеживал поступающие заказы, переносил их в 1С и менял статус.

При этом у маркетплейсов жесткие условия по срокам сборки и отмене заказов поставщиком. Превышение одного из показателей влечет бан.

2. Описание реализации кейса и творческого пути по поиску оптимального решения

Этапы интеграции

Проанализировав технические возможности и принцип работы маркетплейсов, мы приступили к разработке интеграционного решения. Стоит отметить, что ввиду особенностей каждой площадки схема будет отличаться. Например, для работы с Wildberries не требуется автоматизация процесса, поэтому «Олант» успешно работает с площадкой вручную.

1. Написание ТЗ

Написали техническое задание и сделали декомпозицию объемных задач для оценки сроков.

Синхронизацию каталога разбили на подзадачи:

• описание методов API;
• функционал экспорта товарных позиций;
• функционал синхронизации данных у товаров;
• синхронизации цен и остатков.

2. Разработка

На этапе разработки мы описали методы взаимодействия с API, а также написали функционал взаимодействия между системами.

Рассмотрим на примере маркетплейса Ozon, какие работы были проведены на данном этапе:

1. Написали функционал для работы с API маркетплейса;

2. Создали классы для выборки и обработки данных из интернет-магазина для последующей отправки в маркет;

3. Создали API-сервисы для обработки запросов на новые заказы от маркета и предоставления данных ERP-системе;

4. Внедрили функционал логирования и информирования о критичных ошибка при обменах. Если произойдет сбой, мы будем знать где произошел сбой, при каких данных и быстро отреагируем;

5. Создали отчеты для сверки данных по товарным позициям в маркетплейсе и интернет магазине. Отчет представлен в 2-х вариантах: в виде отчет-таблицы для менеджеров и сверки данных в автоматическом режиме каждые 2 часа.

3. Тестирование и отладка процесса

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

В результате тестирования на основе данных логов и обратной связи от клиента у нас получился следующий список для доработок:

• некорректная передача данных при отрицательных остатках;
• API OZON не отдавала результат при печати маркировки с первого раза;
• некорректное SKU товара (1С может менять артикул на своей стороне);
• ошибка от API — too many requests, которая возникла с увеличением размера каталога;
• некорректная отработка загрузки изображений.

4. Развитие интеграционного решения

После отладки решения мы перешли к доработке процесса интеграции. Ниже рассказываем, что сделали на данном этапе.

1. Поменяли время вызовов узлов системы и доработали функции для удобства взаимодействия с ERP-системами.

2. Реализовали новые фичи: печать маркировки, работа с премиум-ценами, web-сервис получения трек-номера DPD ERP-системой. С увеличением размера каталога перенастроили запуск скриптов обмена.

3. Внедрили очереди выполнения и оптимизировали нагрузку, изменив фильтры выборки по дате изменения данных товара, а также разделив выгрузку на регулярную (на основе изменения товара в каталоге) и общую. Часть статичных данных перенесли на хранение в кэш. К такому решению пришли потому, что при увеличении количества товарных позиций в каталоге возникли проблемы со временем выполнения скриптов и превышением максимального количества запросов.

Технические нюансы интеграции с маркетплейсами

При разработке интеграционного решения нужно учитывать реальное количество товаров, которое будет представлено в каталоге. Например, вы тестировали код на 600 единицах, а выгрузили 6000. В результате недопустимое количество товаров в системе влечет некорректное отображение остатков и отмену заказов, что в свою очередь может вызвать санкции со стороны маркетплейса. Совет: максимально продумайте архитектуру и тестируйте код на реальном количестве товаров.

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

3. Результаты сотрудничества

Разработка интеграционного решения заняла 4 месяца, в проекте приняли участие 5 специалистов: 2 с нашей стороны и 3 со стороны «Олант».

В результате мы минимизировали ручной труд, реализовав функционал бесперебойного экспорта товара. Теперь достаточно пометить нужные товары в 1С и они автоматически загрузятся на маркетплейс за 3–5 минут. Взаимодействие с 2 системати одновременно больше не требуется.

До автоматизации маркетологу приходилось составлять excel-файл и загружать его на площадку через личный кабинет. Чтобы внести одну позицию в документ требовалось 10 минут, в среднем на одной площадке размещено 3500 товаров. Таким образом работа, которую один сотрудник выполнял бы в течении 2,5 месяцев (для одного маркетплейса) теперь занимает 5 минут в автоматическом режиме.

Повысили скорость обновления данных: каждые 8–10 минут в автоматическом режиме за 5 минут актуализируется информация по остаткам и ценам каталога — по 3500 товаров в среднем в каждом маркете. Работы по улучшению этих показателей продолжаются. Для сравнения — в ручном режиме на эти действия уходило 30–40 минут на один маркетплейс. Таким образом мы в 40 увеличили скорость обновление данных, освободив для маркетолога 3,5 часа рабочего времени ежедневно.

Синхронизировали заказы между маркетплейсом, 1С-Битрикс и ERP-системой. Это позволило сократить влияние человеческого фактора и минимизировать время реакции на заказ с 30 до 5–10 минут.

Анатолий Тесля

Основатель и директор по развитию, Сеть «Олант»

Благодаря автоматизации в мае наш показатель отказов составил 1,7%, почти 100% заказов собираются в срок. Текущий показатель просрочки по сборке — 0,26%.