М.Видео-Эльдорадо продолжает развивать собственный маркетплейс бытовой техники и электроники, на котором уже представлено более 100 партнёров. Сегодня на онлайн-площадках и в магазинах 160 000+ товаров, что втрое больше, чем годом ранее. Быстрое расширение ассортимента, ИТ-поддержка, логистика, доставка, прием платежей и документация по всем процессам стали возможны благодаря проекту «Бесконечная полка» и созданию веб-платформы для поставщиков. По мере ее развития, мы будем рассказывать о ключевых технологических решениях.



Как любой театр начинается с вешалки, так и маркетплейс начинается с входной двери. Ей можно считать платформу, которую мы создали для управления ассортиментом и взаимоотношениями с партнерами — все необходимые этапы взаимодействия они проходят в Личном кабинете поставщика (ЛКП).

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

В перспективе через ЛКП партнеры смогут подать заявку на участие в рекламе, получать информацию по заказам, записываться на склад, отслеживать поставки, получать операционную и бухгалтерскую отчетность.

Фактически ЛКП станет единым окном (входной точкой), где помимо поставщиков работают все специалисты Группы, связанные с мерчантами: категорийные менеджеры, логисты, сотрудники поддержки, специалисты по онбордингу и работе с претензиями. Регистрируясь в ЛКП, контрагенты получают простой инструмент продаж через маркетплейс Группы.

Мы же получаем возможность значительно расширить ассортимент (потенциально до 1,5 млн позиций от 2 тыс. продавцов). Благодаря использованным решениям мы можем в несколько раз масштабироваться в короткие сроки и при текущих ресурсах.

Что такое «бесконечная полка»? Глобальная задача

Стратегическая цель М.Видео-Эльдорадо — быть местом #1 для покупок бытовой техники и электроники. Для достижения этой цели мы ставим задачу по кратному расширению ассортимента (до 500 тыс. в перспективе 2023 г.). Эта задача, в свою очередь, может быть эффективно реализована через модель маркетплейса.

Мы приняли решение развивать закрытый маркетплейс, на котором могут размещаться поставщики, продающие комплементарные (сопутствующие) нашему ассортименту товары и соответствуют нашим критериям в отношении уровня клиентского сервиса.

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

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

Группы товаров

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

Регулярный ассортимент — основная часть ассортимента. Товары, которые мы предварительно закупаем в сток. Именно их в основном видят покупатели розничных магазинов.

Вендор-каталог — товары, которые М.Видео-Эльдорадо заказывает у поставщиков только после оформления клиентского заказа, строго в заказанном покупателями количестве и конфигурации.

Агентские товары — схема, при которой М.Видео-Эльдорадо оказывает поставщикам услуги по продаже, доставке и возврату товаров, получая за это комиссионное вознаграждение. Сами товары всегда остаются в собственности поставщика, при этом физически могут находиться на объектах М.Видео-Эльдорадо.

Товары маркетплейса могут продаваться по двум схемам — FBM (fulfilment by Mvideo) и FBS (fulfilment by Seller). В первом случае товары хранятся на объектах компании (ответственное хранение) и отгружаются с него, во втором — товары хранятся у поставщика, и он привозит их к нам под заказ для последующей отгрузки клиенту.

Исходные данные

На момент принятия решения о запуске маркетплейса взаимодействие поставщиков с нашими ИТ-системами проходило через SAP-портал. Туда партнёры грузили квоты на товары (количество, которое они резервируют под Группу для последующей отгрузки после оформления заказа покупателем).

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

В то время данные передавали через разнообразные xls-файлы и сообщения электронной почты. Например, чтобы стать партнером Группы и добавить новые товары в каталог М.Видео и Эльдорадо, поставщику нужно было сделать запрос менеджеру коммерческой дирекции. Он оценивал предложенные товарные позиции и, если принимал положительное решение, проводил регистрацию поставщика во внутренних системах.

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

При этом обновление цен проходило через менеджера коммерческой дирекции (КД) и постоянную коммуникацию с отделом ценообразования.
Полученные файлы перепроверяли. Процесс занимал в лучшем случае 2-3 недели, обычно около месяца. О скорости и автоматизации речи не шло.

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

С отчетностью тоже было непросто. Одни бухгалтерские группы обменивались данными по товарам, другие – по расчетам. До унификации нам и сейчас пока далеко, но мы начали разрабатывать биллинг, чтобы это исправить. Забегая вперед, в ЛКП в будущем появится модуль операционной и бухгалтерской отчетности, благодаря которому поставщик сможет не только оперативно получить информацию о своих продажах на площадке, но также узнать сроки оплат и контролировать взаиморасчеты. Кроме того, будут уведомительные счета, чтобы поставщик знал, что скоро в ЭДО придет заявка на оплату.

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

Написать своё или купить уже готовое?

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

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

Общая архитектура проекта

После того, как мы сформулировали требования для нашего маркетплейса задача для проекта была разделена на 2 технических блока:

● Разработка «Личного кабинета поставщика».
● Реализация интеграционных потоков и синхронизация основных систем нашего контура систем.



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

К примеру, сайт М.Видео переживал редизайн, некоторые старые системы выводили из эксплуатации, а о мобильном приложении Эльдорадо на старте проекта многие участники даже не слышали. А не учесть одну из систем означало фактический провал, т.к не работали бы ключевые процессы для маркетплейса.

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

Личный кабинет поставщика

Команда разработки
Новая система выстраивалась с «нуля» и 75% работ были связаны с интеграциями с другими системами, а их на момент запуска проекта «Бесконечная полка» было более 15. Иногда нам приходилось подстраиваться и выбирать не самые популярные/очевидные методологии. К примеру, на старте разработки мы начинали с формирования двух back-end команд (По составу: 1 dev-lead и 2-3 back- разработчика) и одной продуктовой команды (С составом: продакт, бизнес-аналитик, Lead front-end, 2 front-end разработчика, 2 QA engineer manual, QA automation, UX-дизайнер, DevOps).



Такое разделение на команды позволило нам не «тормозить» в сложных интеграционных задачах и быстро поднимать необходимые в конкретный момент сервисы. Мы получили гибкость, чтобы выводить маленькие кусочки функционала каждые две недели. И при этом избежали простоя команд, т.к. back-end уходил далеко вперед, работая по Kanban-методологии, тем самым обеспечивая продуктовую команду необходимым бэклогом для запуска двухнедельных спринтов.

Далее по мере развития продукта и появления основного функционала мы провели трансформацию, дополнили наши команды необходимыми специалистами и перешли на SCRUM. Так получились три полноценные «продуктовые» команды, которые обеспечивают выпуск функционала каждые 2 недели.



Мы вошли в более плотный релизный график и увеличили количество поставляемых полезных изменений в продуктивную систему. Если рассматривать наши SCRUM-команды, то на наш взгляд, нам удалось приблизится к канону. Каждая команда может приносить пользу и покрывает все необходимые компетенции для поставки готовой функциональности. Они состоят из 8-9 человек, имеют все канонические ритуалы: Stand-up, Gromming, Planing, Retro и Demo. Каждая команда четко понимает цель каждого изменения, которое поставляет в продукт.

Настройка процессов поставки — это только 30% от общего успеха внедрения изменений. Есть другой важный блок — подготовка бизнес-требований, описание HLD, описание бизнес-процессов и архитектуры. Эти шаги вынесены за рамки поставки решений и подготавливаются по Kanban. Их выполняют продакт-оунеры, аналитики, системный и функциональный архитекторы.



По процессу оунер формирует требование, готовит описание в виде схемы и текста и создает epic в jira. После epic попадает на функционального архитектора и кросс-системного Delivery-менеджера, которые определяют системы, в которых нужно внести изменения, формируют верхнеуровневое описание технических задач и архитектурную схему для данного epic. После чего задача попадает к аналитикам, которые описывают и разбивают ее на story. Системный архитектор, в свою очередь, описывает техническую US и декомпозирует ее на подзадачи. По итогу US попадает в бэклог продуктовой команды и после ритуалов команды grooming и planing — в спринт.

Помимо процессных мероприятий в продукте используются практики knowledge-sharing. Команды на регулярной основе обмениваются знаниями по новым технологиям, разбирают реализованные/запланированные сервисы, а также делятся опытом по практикам написания кода и тд. Результатом одного из таких мероприятий стал переход всего продукта на Trunk Based Development. Возможно, об этом расскажем в одной из наших будущих статей.

Технологии Личного кабинета поставщика

Основным языком разработки является Java 11+ с точки зрения бэкенда и TypeScript — с точки зрения фронтенда. Также используем популярные фреймворки Spring Framework 5.3+ (Core, Data, Security), Spring Boot 2.4+ (Cloud, Security), hibernate, querydsl на бэкенде, на фронтенде используем Angular. В качестве хранилища используем базы данных Couchbase, PostgreSQL, для полнотекстового поиска внедрили ElasticSearch

С точки зрения инфраструктуры у продукта 4 контура — Dev, QA, Preprod и Prod. Все контуры развернуты в Yandex Cloud. Архитектурная схема продукта «Личный кабинет поставщика» представлена ниже.

Что сделано?

В рамках проекта мы создали web-портал, к которому партнёр подключается, авторизуется и далее работает в формате личного кабинета. Для того, чтобы поставщик имел возможность полноценно работать на портале, необходима предварительная проверка и одобрение заявки поставщика внутренними службами М.Видео-Эльдорадо.

В личном кабинете поставщику уже доступны:
● Регистрация и принятие оферты;
● Передача квот;
● Передача цен товаров;
● Управление участием в ценовых акциях (!);
● Получение базовой отчетности;
● Формирование заказа (уведомление о сделанном заказе)

Все эти возможности были разбиты на отдельные микросервисы. Все онлайн-фронты наших брендов получили новый атрибут «Маркетплейс» на уровне товарной номенклатуры. На сайте такие товары маркируются плашкой «Товар партнера» или «Товар размещен магазином-партнером». Офлайн-системы FOBO (торговая система М.Видео), TradeService (торговая система Эльдорадо), мобильные приложения для клиентов и продавцов также обрабатывают атрибут «Маркетплейс».

Атрибуты для партнерских товаров добавили и во все внутрикорпоративные системы. Тут важно заметить, что в контуре компании находится около 200 ИТ-систем. Часть из них — это Legacy-системы. Для нас было важно обеспечить работу как новых, так и старых сервисов. Мы создали динамический атрибут, чтобы каждая система точно понимала, что этот товар относится к процессу Маркетплейс, и подключала отдельную логику.

К примеру: в ERP данный атрибут разграничивает «схему проводок», по которой идут взаиморасчеты с поставщиками, определяет, какую информацию о поставщиках необходимо распечатать в чеках и какую информацию необходимо передать на онлайн и офлайн-фронты. Другие бэк-системы, к примеру, CIS, отвечающий за работу с браком, при получении этого признака научился определять схему работы поставщика, а соответственно более качественно и быстро обрабатывать такие материалы.

После того, как мы научили все системы различать агентские товары и товары вендор-каталога, нам необходимо было решить вопрос с прогрузкой таких цен из ЛКП и ERP во все системы-потребители.

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

В итоге цены маркетплейса в SAP ERP и всех фронт-системах передаются отдельным потоком в рамках двух технических объектов. Первый – для М.Видео, второй – для Эльдорадо. Ограничения на среднее число товаров, для которых будут выгружаться розничные цены, было определено на уровне 15 тыс. SKU в день, пиковое — примерно 30 тыс. SKU в день. До настоящего момента действовало ограничение в 5 тыс. SKU в день.

Ближайшая перспектива

Наша цель — в этом году обеспечить партнерам в ЛК все возможности для полноценного ведения бизнеса. Постепенно мы переходим от договоров поставки и старых схем сотрудничества к формату оказания услуг маркетплейса.

В частности, запустим услуги по ответственному хранению, логистике и т.д. Мы будем учиться работать не с фиксированными договорами, а с видами услуг. У нас должна появиться новая система биллинга. Это ещё один отдельный проект.

С точки зрения нагрузки личный кабинет способен работать с 2 000 активных поставщиков при общем объеме зарегистрированных продавцов в 5 000. В общей сложности такие партнеры смогут продавать около 500 тыс. SKU.

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

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

У нас должны появиться новые процессы, такие как Мультикарточка (мультиофер), когда на стороне фронт-систем клиенты будут видеть по факту один товар, но этот товар может быть продан по нескольким схемам и несколькими разными поставщиками. У товара может быть разная цена, разные условия доставки, разные форматы промо.

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

Stay tuned!

P.S. Интересные проекты, задачи и вакансии для разработчиков здесь.