Платформа данных в Леруа Мерлен — как мы победили масштабирование
Время на прочтение
10 мин
Количество просмотров 4.1K
Всем привет! Меня зовут Александр Токарев, я технический архитектор домена «Управление данными» в Леруа Мерлен. Год назад мы уже делали обзор нашей Платформы данных, сейчас же я расскажу про её развитие за последний год и про задачи, которые нам удалось решить.
Мы столкнулись с необходимостью масштабировать наш подход, когда количество источников, интегрированных в платформу, стало больше 150. Всего же мы планируем интегрировать данные из более чем 800 систем. Однако ETL‑инструменты, которые мы использовали на первых этапах развития дата платформы, не позволяли добиться эффективного масштабирования. Кроме того, сам процесс интеграции источников был достаточно трудоемким. Поэтому возник запрос на рефакторинг архитектуры процесса поставки данных, который, с одной стороны, позволил бы эффективно горизонтально масштабироваться, а с другой стороны, упростил бы сам процесс интеграции. В результате мы пришли к следующей схеме процесса.
Вкратце напомню структуру изначального процесса, который мы выстроили в ходе построения дата‑платформы. Источники данных отправляют CDC (Change Data Capture) сообщения в Kafka‑топики, которые вычитываются ETL (Extract‑Transform‑Load) процессом на NiFi, складывающим преобразованные CDC в БД GreenPlum в сырой слой (Raw). Затем по расписанию запускается загрузчик в Airflow, вызывающий хранимую процедуру в самом GreenPlum, которая делает свёртку сырых сообщений и преобразует их в табличный вид, который у нас называется ODS (Operational Data Store) слоем. Далее на основе ODS‑слоя можно построить слой витрин данных (Marts), но это не всегда является обязательным.
Кроме того, в нашей компании при работе с данными мы основываемся на подходе Data Mesh. Его суть заключается в том, что за интеграцию данных в дата‑платформу и обеспечение качества интегрируемых данных отвечают команды, являющиеся владельцами систем‑источников данных. В свою очередь, команда дата‑платформы отвечает за предоставление инструментов для проведения интеграции и за обеспечение работоспособности этих инструментов в процессе эксплуатации.
Данный подход был вполне эффективен на первых этапах развития дата‑платформы. Однако со временем в результате роста количества подключенных систем и объёма загружаемых данных мы столкнулись с рядом проблем.
1. Технологическая нагрузка по расчету ODS‑слоя из сырых данных выполняется на тех же мощностях, что и запросы пользователей. Из‑за этого мы регулярно получали жалобы на то, что запросы выполняются медленно. В качестве частичного решения этой проблемы мы поставили выполнение всех технологических процессов на ночь, но, во‑первых, это уже затрагивало наших потребителей в дальних часовых поясах, во‑вторых, ограничивало скорость поступления данных в ODS‑слой до одного раза в сутки.
2. В продуктовых командах, владеющих системами, которые должны быть интегрированы в дата‑платформу, не всегда есть дата‑инженеры с нужными компетенциями. Для небольших команд это не всегда экономически оправдано. Кроме того, дата‑инженер должен владеть сопутствующими технологиями, такими как NiFi и Airflow.
3. Около 75% источников используют однотипные системы для хранения данных — например, БД PostgreSQL или MSSQL. Соответственно процессы интеграции данных из таких источников выглядят однотипно. Каждый дата‑инженер просто копировал интеграционный ETL‑процесс в NiFi с похожего источника и слегка его модифицировал. Поэтому возникла потребность в создании универсального процесса под стандартные типы источников данных, которые просто конфигурировались бы под каждую интеграцию.
4. Необходимо было обеспечить резервирование всех данных на случай отказа основного кластера GreenPlum и их быстрое восстановление.
Концепция решения
Таким образом, мы приняли решение вынести всю технологическую нагрузку за пределы кластера GreenPlum. Все поступающие из Kafka‑топиков CDC‑сообщения сохраняются в персистентное хранилище на базе S3, с разделением по источникам, целевым таблицам и временным интервалам. Мы решили сделать единый процесс, читающий данные сразу из всех источников и обрабатывающий CDC‑сообщения в зависимости от их формата. Это позволило нам автоматически балансировать ресурсы между источниками в зависимости от нагрузки — вместо создания отдельных ETL‑процессов на NiFi под каждый источник. Также это дало возможность сделать универсальные конфигурируемые обработчики для часто встречающихся типов источников данных.
После сохранения CDC‑сообщений из Kafka на S3 мы запускаем процесс формирования ODS‑слоя, который также хранится на S3. Он представляет собой снимок таблицы (snapshot) на определенный момент времени и может служить для неё точкой восстановления. Таким образом, хранилище на S3 является первоисточником для данных ODS‑слоя, которые затем могут загружаться как в общий коммунальный кластер GreenPlum, где с ним могут работать все желающие, так и в другие специализированные кластеры и БД, которые работают с меньшим объёмом исходных данных для повышения производительности.
Ниже приведена логическая схема загрузки данных в дата‑платформу.
На данной схеме я показываю, что все CDC‑сообщения, приходящие из Kafka, сохраняются в неизменном виде на S3. При сохранении они разделяются по директориям в соответствии с названием таблицы и интервалом времени. Для определения интервала времени используется event‑time, содержащийся в самом сообщении. Это нужно для того, чтобы в случае так называемых late events мы могли доложить их в нужную директорию и пересчитать.
Далее на основе сохранённых CDC‑сообщений в Raw‑слое необходимо рассчитать приращение для основной таблицы — дельту. Дельта представляет собой последовательность операций, которые необходимо применить к предыдущему снимку таблицы для того, чтобы получить снимок таблицы на начало следующего периода. Таким образом, мы получаем серию снимков для таблицы с определённой периодичностью.
У данного подхода есть два недостатка. Первый заключается в том, что в случае большого объёма данных в снимке и малого — в дельте при расчёте следующего снимка будет расходоваться много ресурсов. Поэтому имеет смысл перестраивать снимки не после появления каждой новой дельты, а после появления нескольких дельт. Например, вместо S1 = S0 + d0 и S2 = S1 + d1 можно рассчитывать снимок через два интервала как S2 = S0 + d0 + d1 и т. д.
Второй недостаток заключается в том, что каждый раз загружать в GreenPlum полное состояние таблицы при появлении нового снимка также будет слишком затратным процессом. Поэтому мы разработали процедуру применения дельт к таблице непосредственно к данным, уже хранящимся в GreenPlum, что устраняет необходимость в постоянной перезагрузке данных. Таким образом, загрузка данных в GreenPlum из снимков таблицы необходима только в случае восстановления резервной копии, в штатном же режиме дельты применяются и к снимкам таблицы на S3, и к данным в самом GreenPlum. В случае штатной работы системы состояние таблицы после применения соответствующей дельты и состояние снимка на S3 должны быть эквивалентными.
Реализация
С учётом всех изложенных выше вводных мы пришли к следующей архитектуре системы.
Изображенные на схеме компоненты процесса интеграции источников в дата‑платформу взаимодействуют следующим образом. Точкой входа в контур дата‑платформы и механизмом передачи CDC‑сообщений от источников в дата‑платформу является Kafka. Как и в предыдущей реализации дата‑платформы, мы исходим из того, что данные от источников поступают в виде непрерывного потока CDC‑сообщений. Из неё данные вычитываются модулем CDC ingest, построенным на Apache Flink. Его основными задачами являются загрузка данных из Kafka‑топиков и сохранение их на S3 в партиционированном виде.
Кроме того, модуль CDC ingest определяет, завершилось ли заполнение директории или ещё в процессе. Для этого он использует оконные функции, входящие в состав Apache Flink. Для каждого интервала времени он собирает множество всех выходных директорий, в которые была запись за этот интервал. Затем при помощи скользящего окна мы сравниваем множества за последний и предыдущий интервалы, и если в предыдущем интервале есть пути, которых нет в последнем, то мы считаем, что запись в эти директории завершилась и их можно передавать на следующие шаги.
Для расчета приращений (дельт) ODS‑слоя служит модуль Raw to ODS, построенный на Apache Spark. Его задача заключается в свёртке CDC‑сообщений по натуральному ключу таким образом, чтобы в результате его работы по каждому ключу была только одна итоговая операция, которую нужно применить к предыдущему состоянию таблицы. Например, если по данному ключу была сначала операция delete, а затем insert, то он их преобразует в одну операцию update. Или наоборот, если по ключу было три операции, сначала insert, потом update, потом delete, то он просто исключит этот ключ из итоговой дельты, и т. д. Также этот модуль отвечает за построение снимков таблиц на определённые моменты времени.
За загрузку данных ODS‑слоя из S3 в GreenPlum отвечает модуль Upload coordinator. Сами данные на S3 подключаются как внешние таблицы по протоколу PXF и затем перегружаются во внутренние таблицы GreenPlum при помощи хранимой процедуры. Изначально планировалось делать его на Airflow, который просто бы вызывал хранимую процедуру, однако мы столкнулись со следующей проблемой. Нам было необходимо, чтобы от запуска к запуску у нас формировался разный DAG, структура которого зависела от состава и количества партиций, готовых к загрузке. Однако динамические DAGи на Airflow позволяют сформировать только одну форму DAGа, которая не меняется от запуска к запуску. Поэтому в качестве координатора загрузки был выбран Apache Spark, который может распараллелить задачи на загрузку. В отличие от предыдущего модуля, здесь Spark не занимается непосредственно обработкой больших объёмов данных, а просто вызывает хранимую процедуру с Executor`ов, поэтому здесь мы ему выделяем существенно меньше ресурсов, чем предыдущему модулю.
За координацию задач по расчёту и загрузке данных между тремя предыдущими модулями отвечает сервис Task Coordinator. После окончания записи сырых данных модуль CDC ingest делает в нём запись о том, что определённую директорию можно обрабатывать следующим модулем. В свою очередь, модуль Raw to ODS считывает из координатора список путей к директориям, готовым к обработке, и в результате создаёт следующий список уже из директорий ODS‑слоя, готовых к загрузке в GreenPlum. Аналогично работает и модуль загрузки данных ODS.
За управление параметрами конфигурации всех этапов процесса отвечает сервис Metadata. Ранее мы уже делали про него отдельную статью. Он позволяет, в частности, определить схему данных для каждой таблицы источника, указать, какие Kafka‑топики использовать для чтения CDC‑сообщений, настроить периодичность появления новых директорий на S3 и т. д.
Одним из преимуществ данного решения является то, что в целом процесс получился идемпотентным. На любом этапе в случае возникновения какой‑либо ошибки мы просто выполняем его заново, и это не приводит к дублированию или потере данных. Кроме того, идемпотентность процесса позволяет нам корректно работать в случае дублирования CDC‑событий или в случае запоздалых событий (late events). Из‑за того что мы используем для разделения на директории время самого события, они всегда попадут в одну директорию raw‑слоя и будут дедуплицированы и рассчитаны заново.
После запуска в эксплуатацию мы обнаружили следующий недостаток. Так как для обработки данных со всех источников использовался единый процесс, то в случае появления ошибок в структуре данных одного из источников он весь останавливался целиком. Кроме того, если по одному источнику начинают прогружать большой объём данных, то он влиял на скорость загрузки данных по другим источникам. В итоге было принято решение о разделении потоков по нескольким независимым экземплярам, или пулам. На каждый пул выделяется определенный объём ресурсов, прежде всего ядер процессора и памяти. В итоге мы сейчас работаем в 4 пулах: два из них выделены отдельно для систем с большим объёмом данных, один пул — для нестабильных источников (как правило, это такие источники, которые были недавно подключены) и ещё один — для всех остальных источников со стабильной структурой сообщений и небольшими объёмами данных.
Нагрузка
Вся технологическая нагрузка была вынесена на внешний кластер k8s. Как следствие, была существенно повышена производительность кластера GreenPlum для пользовательских запросов. В частности, для загрузки и расчёта самого большого источника раньше в среднем расходовалось порядка 15% вычислительных мощностей, а после переключения — около 1%.
Выводы
В итоге внедрение новой реализации позволило нам достичь следующих результатов.
1. Упрощён процесс интеграции источников в дата‑платформу. Для стандартных источников больше нет необходимости в создании отдельного ETL‑процесса. Достаточно просто добавить соответствующую конфигурацию в сервис метаданных. Время интеграции стандартного источника уменьшилось в ~2 раза.
2. Благодаря снижению нагрузки на кластер GreenPlum в ~10 раз, освободившиеся ресурсы были выделены для полезной работы пользовательских процедур и запросов.
3. Рассчитанные данные ODS‑слоя теперь доступны как в GreenPlum, так и на S3. Это, во‑первых, обеспечивает резервирование данных, а во‑вторых, позволяет работать с ними, используя различные инструменты для распределённой обработки данных, такие как Apache Spark, минуя GreenPlum.
Внешняя среда и поведение потребителя в ней меняются так быстро, что просто качественного товара или услуги сегодня уже недостаточно. Удобство и удовлетворенность на каждом этапе клиентского пути — вот то поле, на котором ведется борьба за лояльность и LTV. Какое место в этой борьбе отводится цифровым технологиям, рассказал Sostav Аркадий Юсупов, директор LM Tech, «Леруа Мерлен».
Что особенного в пути клиента в строительном ритейле?
По сравнению с food- или fashion-ритейлом у нас более низкая частотность покупки, но гораздо более длительный и сложный контакт с клиентом. Проекты по обновлению дома, дачи или сада связаны с планированием, инженерным и интерьерным проектированием, подбором материалов с учетом множества нюансов, необходимостью сопровождать клиента и предоставлять ему дополнительные сервисы, например сборку и установку. Для того чтобы это было возможно в любом из сотни с лишним магазинов от Калининграда до Владивостока, требуется сложная ИТ-инфраструктура и множество технологических решений. Они, с одной стороны, должны функционировать в существующей инфраструктуре, а с другой — быть достаточно гибкими, чтобы оставаться функциональными при ее изменении.
О каких именно решениях идет речь?
От самых очевидных, например мобильного приложения для клиентов, до таких сложных, как ERP-системы. Это могут быть как относительно изолированные системы, такие как портал поставщиков, так и связанные с сайтом, мобильным приложением для клиентов и мобильной платформой для сотрудников функции цены, оплаты, товарных остатков. Сложность заключается в том, что все процессы происходят параллельно. Около четырех лет назад мы инициировали переход от монолитной к микросервисной архитектуре, API-зации, использованию облачных технологий. Развитие e-com и омниканальности требовало от нас все больше новых сервисов и инструментов. Ряд наших систем, таких как управление заказами, корзина, CRM, не были готовы к переходу на микросервисную архитектуру и постоянно дорабатывались. Для того чтобы отвечать на запросы со стороны бизнеса, требовалось все больше технических специалистов. К концу 2019 года в ИТ-департаменте работали почти 500 специалистов, но их все еще было недостаточно. На рынке просто не хватало кадров нужной квалификации.
Как вы справились с этой проблемой?
Просто посмотрели на нее под другим углом. Если мы не можем изменить рынок труда, то что мы можем сделать с внутренним потенциалом? Задачей номер один было ускорение перехода на микросервисную архитектуру. С учетом нехватки разработчиков мы искали решение, позволяющее создавать микросервисы для сложных кейсов без участия бэкенд-разработчиков. Исследование привело нас к Netflix, который передал функцию создания микросервисов независимым командам фронтенд-разработчиков, то есть тем, кто отвечает за клиентскую сторону пользовательского интерфейса. Это позволило не привлекать к развертыванию каждого сервиса центральную ИT-команду и ускорить интеграцию сервисов.
Но, в отличие от стримингового сервиса с единой логикой, в нашем случае было множество разрозненных баз данных для организации внутренних процессов магазинов — база товарных запасов, база знаний и другие; сложная бизнес-логика; непрерывная разработка новых сервисов и адаптация существующих. Удовлетворить все наши потребности могла только платформа для запуска микросервисов.
В чем ее преимущества для вас?
Она бы избавила нас от необходимости писать отдельные коды для обращения каждого сервиса к базам данных. Было бы достаточно иметь возможность создавать сервисы в интерфейсе и указывать, к каким базам данных он должен обращаться. Платформа сама устанавливает связь между сервисом и нужными базами. Мы начали с создания интеграционного слоя (технологической связи между сложными бэкенд-системами и базами данных с фронтендами) для диджитал- и мобильных приложений. Следуя практике Netflix, мы решили, что штатные аналитики и фронтенд-разработчики могут запускать сервисы без привлечения центральной команды ИT, если дать им инструмент, способный «закрыть» бэкенд-разработку.
Так появилась концепция собственной Low-code-платформы, в которой создание и изменение микросервисов практически не требует написания программного кода. Платформа, которую мы назвали Platformeco, позволила нам разгрузить бэкенд-разработчиков и привлечь к созданию микросервисов аналитиков. Первым сложным продуктом со множеством сервисов стала корпоративная мобильная платформа с набором приложений и сервисов, которыми пользуются сотрудники для работы в магазине. Приложение заменило собой около 40 разных систем. При этом нам удалось почти втрое сократить time to market и снизить ФОТ за счет оптимального распределения задач в команде.
Следующим шагом стало создание еще одного мобильного приложения — на этот раз для клиентов. Благодаря возможностям новой платформы весь бэкенд для приложения написал один человек. Без Platformeco ту же работу выполняла бы команда из восьми человек в течение года. И тут нас накрыла пандемия.
Но проблема с нехваткой кадров вас уже не сильно волновала?
Нет, конечно. Она никуда не делась и даже обострилась, потому как борьба за специалистов за год перешла в стадию войны. Но Platformeco однозначно спасла от коллапса. Мы продолжали работать над развитием функционала платформы. Постепенно на ее основе уже можно было не только создавать мобильные приложения, системы управления заказами, подключать провайдеров к платформе услуг, но и решать интеграционные задачи — например, связывать облачные и наши внутренние решения. Чем больше продуктовых команд использовало Platformeco, тем шире становился функционал. Было создано более 40 ключевых модулей, включая графический интерфейс drag&drop, мониторинг хода реализации процесса и получения оповещений о сбоях, появились коннекторы, системы аутентификации и идентификации. Участники внутреннего сообщества, сформировавшегося за время тестирования платформы, также внесли ряд предложений, упростивших использование ключевого функционала — мониторинга, трассировки, развертывания микросервисов в облаке. Продукт получил единую авторизацию, единый интерфейс и другие улучшения.
Мы не так сильно зависим от бэкенд-разработчиков. Но, что более важно, Low-code позволяет аналитику выстроить логику процесса с помощью drag&drop-интерфейса, а Platformeco автоматически создает микросервис для решения задачи. То есть мы не просто понизили порог входа в ИТ «Леруа Мерлен», но максимально расширили возможности для решения бизнес-задач. Сегодня протестировать бизнес-идею, с изменением базовых процессов, можно за несколько дней, а не за несколько месяцев, как раньше. Можно создавать для разных групп пользователей параллельные процессы с разными сценариями в рамках одного проекта.
Но это все неочевидные для клиента улучшения. Что же получает клиент?
Клиент получает лучший сервис. Благодаря функциям трейсинга, мониторинга и алертинга Platformeco отслеживает работу сервисов. В любой момент времени видно, что происходит в работе каждого микросервиса, где возникла проблема, как ее решили и т. д. Теперь мы в 15 раз быстрее вносим изменения и в 20 раз быстрее локализуем инциденты.
Клиенты уже избалованы сервисом, они предъявляют требования к быстроте, комфорту, стабильности. Невозможно ускориться, если на разработку фичи уходит по шесть месяцев, а в бэклоге все это время пылится еще тонна нерешенных задач. В разных продуктах Platformeco сокращает time to market в 1,5−6 раз при соблюдении всех этапов разработки, тестирования и разворачивания продукта. Это именно то, что удовлетворяет требования клиента.
Звучит так, как будто это панацея?
Диджитализация — это наша объективная реальность. Технологии и продуктовые команды все глубже интегрируются с операционным бизнесом. Так возникает единый контекст, устраняется разрыв в коммуникации между постановщиками и исполнителями задачи. Сама граница между ними размывается. С помощью платформенных решений выстраивается общая логика, исключается дублирование, повышается скорость и управляемость изменениями. Подходы Low- и No-code возникли не просто так. Они не лекарство, но вполне эффективный инструмент для решения конкретных задач.
Мы можем с уверенностью говорить об этом, потому что Platformeco как платформа для создания и управления микросервисами работает не только в «Леруа Мерлен». У нас есть успешный опыт внедрения продукта на международном и российском рынке в компаниях из разных отраслей и с кардинально разными ИТ-инфраструктурами. Например, платформа используется в «Брикоман» (входит в группу «Адео»). При этом в «Адео» продукт стал стандартом для создания Anti-corruption layer, а в «Леруа Мерлен Франция» применяется по назначению — как платформа для управления API и микросервисами. То есть функционал и адаптивность платформы позволяют ее применять практически в любой компании, которая проходит диджитал-трансформацию.
Маркетплейс Leroy Merlin расположился на 16 строчке глобального рейтинга интернет-магазинов, составленного агентством Data Insight. И на третьем месте магазинов с товарами для дома, после «Петровича» и «Все Инструменты». Сеть принимает на борт новых поставщиков и продавцов, поэтому мы написали материал о том, как продавать на «Леруа».
В статье расскажем:
-
Кто может продавать на маркетплейсе.
-
Об условиях сотрудничества.
-
Какие товары можно продавать на «Леруа Мерлен».
-
Какие есть сборы и комиссии для продавцов.
-
По каким схемам доставки работает площадка.
-
Как зарегистрироваться на маркетплейсе и начать там продавать.
Leroy Merlin в цифрах
«Леруа Мерлен» сегодня это:
-
Годовая выручка — 49 900 миллионов рублей.
-
Годовое количество заказов — 5 320.
-
Число посетителей сайта — 30 миллионов человек.
-
Средний чек — 9 380 рублей (рост на 9 % по сравнению с 2020 годом).
-
Рост продаж в 2021 году — 30 %.
-
Рост количества заказов в 2021 году — 19 %.
Маркетплейс расположился на 16 строчке глобального рейтинга интернет-магазинов. Но среди продавцов товаров для дома Леруа — третьи. Источник Data Insight
Кто может стать партнером Leroy Merlin
Продавать на маркетплейсе могут только юридические лица и индивидуальные предприниматели. Самозанятые стать поставщиками не могут. Есть еще одно довольно жесткое условие: ИП, ООО или другой бизнес должен быть зарегистрирован не позднее, чем за 12 месяцев до подачи заявки на сотрудничество.
Читайте также: Как продавать на Ozon самозанятому
Что можно продавать на Leroy Merlin
Львиная доля каталога маркетплейса — товары для ремонта, строительства и отделки, а также сопутствующие товары: инструмент, хозтовары и так далее.
Вот что можно продавать:
-
Двери, крепеж, метизы, хозтовары.
-
Сантехнику, электрику.
-
Напольные покрытия, детали декора интерьера.
-
Садовые товары.
-
Плитку, товары для отделки потолка и стен.
-
Инструменты, хозтовары.
-
Товары для хобби и творчества.
-
Зоотовары.
-
Текстиль, посуду.
-
Мебель, бытовую технику.
Каталог маркетплейса
Условия сотрудничества с «Леруа Мерлен»
Начнем с того, что на момент написания статьи маркетплейс ищет продавцов только в нескольких регионах:
-
Москва.
-
Самара.
-
Новосибирск.
-
Нижний Новгород.
-
Санкт-Петербург.
-
Иваново.
Условия для продавцов:
-
Наличие собственного склада с товарами в наличии.
-
Возможность собирать заказы, упаковывать и маркировать товар.
-
Наличие документов на товар. Здесь стоит сделать небольшую сноску. Если при продаже на Ozon или Wildberries документы на товар никто не спросит и селлер просто декларирует их наличие, то при сотрудничестве с «Леруа» все сертификаты, декларации и отказные письма нужно предъявить на старте сотрудничества.
-
Возможность обмениваться данным в системе электронного документооборота. Обновление остатков и цен должно происходить в автоматическом режиме, через API.
-
Ассортимент товаров согласовывается с представителями маркетплейса.
-
Перед стартом продаж продавец должен пройти процедуру контрольной закупки, чтобы в тестовом режиме проверить бизнес-процессы.
-
Возможность принимать заказы и брать их в работу в течение часа после получения соответствующего уведомления.
-
Возможность передавать собранные и упакованные заказы в курьерскую службу маркетплейса по утвержденному сторонами графику.
-
Обмен данными, коммуникации и взаимодействие между продавцом и «Леруа Мерлен» происходит в системе MAS — Merchant Administration System. Продавец получает доступ к личному кабинету в MAS после регистрации в качестве партнера маркетплейса.
Читайте также: Где взять сертификаты и декларации на товар для маркетплейсов
Краткие условия для партнеров
Модели доставки
Согласно условиям договора, продавец (мерчант) может продавать товары только с собственного склада. Модель FBO с продажами со склада маркетплейса на момент написания этой статьи не доступна.
Продавать со своего склада партнер может по двум схемам:
-
С доставкой собственными силами. Как это устроено: после того, как покупатель оформил заказ на сайте, партнер получает уведомление об этом в личном кабинете MAS. В установленные договором сроки он обязан собрать и упаковать заказ, после чего доставить покупателю — собственными силами или при помощи подрядчиков.
-
С доставкой силами Leroy Merlin. После оформления заказа на сайте продавец в течение часа берет его в работу, а после упаковки и сборки передает курьерской службе маркетплейса. Либо подрядчиков маркетплейса: «Леруа» имеет право привлекать для осуществления доставки третьих лиц.
Комиссии и расходы Leroy Merlin, ценообразование
Маркетплейс работает по стандартной для таких площадок схеме. Продавец устанавливает на сайте свою розничную цену на товар, а Леруа берет определенный процент комиссии с каждой закрытой продажи. Само размещение товаров на витрине маркетплейса бесплатно. Leroy Merlin имеет право в одностороннем порядке предоставлять покупателям скидки на товар за свой счет. Поставщики также могут делать скидки, для этого через личный кабинет в MAS нужно передать информацию с обновленным каталогом и розничными ценами.
Читайте также: Сравнение размеров комиссий популярных маркетплейсов
Фиксированных комиссий нет. Размер ставок зависит от таких факторов, как категория товара, рейтинг продавца на площадке и так далее. Ставки рассчитываются под каждого поставщика индивидуально и прописываются в договоре.
Розничные цены и комиссии маркетплейса указываются в договоре с учетом НДС. Кроме комиссии, Leroy Merlin взимает с продавцов стоимость доставки, если ее делает сам маркетплейс.
Стоимость доставки зависит от веса и габаритов товара и того, куда и каким способом делается доставка. Если маркетплейс привлекает к этим работам сторонних подрядчиков, поставщик обязуется оплатить доставку по их расценкам.
Вот как это выглядит на примере крупногабаритных товаров:
Стоимость доставки крупногабаритных грузов по Москве и области
Как стать поставщиком «Леруа Мерлен»: пошаговая инструкция
Итак, у вас есть зарегистрированный в установленном порядке бизнес со «стажем» не менее года и вы хотите начать продавать на «Леруа Мерлен». Сперва нужно создать и заполнить заявку на сотрудничество. Для этого заходим в раздел для новых партнеров из футера официального сайта.
Для создания заявки переходим в раздел для новых поставщиков
И попадаем на страницу регистрации продавцов:
Компания предлагает несколько моделей сотрудничества, нам нужен пункт «Самостоятельная продажа на маркетплейсе»
Нажимаем кнопку «Начать продавать на маркетплейсе» и переходим на следующую страницу. Здесь кратко описаны условия сотрудничества, особенности доставки, а также есть образцы договоров, доступные для просмотра.
И самое главное — приглашение к партнерству:
Для того, чтобы оставить заявку, нужно нажать кнопку «Заполнить заявку»
Заполнение заявки состоит из 4 шагов. На первом выбираем товар, который будем продавать:
В разделе можно выбрать только одну категорию товаров
Жмем «Далее» и переходим к следующему этапу. Здесь нужно уточнить ассортимент и указать конкретные товары, которые будем поставлять:
На втором этапе можно выбрать несколько пунктов, хоть все сразу
Далее указываем, сколько артикулов в нашем каталоге.
Выбор количества товаров
Последний шаг — заполнение контактных данных и информации об организации. Указываем напименование ООО или ИП, номер телефона, город, ИНН и электронную почту:
Последний шаг регистрации продавца
Соглашаемся с условиями обработки персональных данных и нажимаем кнопку «Отправить». После этого заявка отправляется на рассмотрение. Входящие заявки на сотрудничество рассматривают в течение 3 дней.
Читайте также: Как начать продавать на Wildberries
Если заявку одобрили, идем дальше. Теперь нужно согласовать ассортимент, который мы собираемся разместить. Только после этого нам предоставят доступ в личный кабинет MAS и подключат обмен данными по API.
Так выглядит продажа товара через сайт маркетплейса
Далее все пойдет проще, чем на других маркетплейсах — например Wildberries или Ozon. Единственное, что требуется от продавца в этом ключе — своевременно передавать данные об ассортименте и ценах.
Последним этапом проверки продавца будет контрольная закупка — тестовая продажа товара. Она позволяет оценить готовность продавца к реальной работе. Проверяется срок реакции на уведомление о поступившем заказе, скорость его обработки и передачи на доставку.
Подведем итоги
Проверьте, все ли вы запомнили:
-
Leroy Merlin — маркетплейс товаров для ремонта, строительства, дома и сада. Интернет-магазин № 16 глобального рейтинга Data Insight.
-
Партнерами магазина могут стать ИП и юридические лица, зарегистрированные не менее, чем за 12 месяцев до даты подачи заявки на сотрудничество.
-
На маркетплейсе предусмотрены 2 модели работы: продажи со склада продавца с доставкой собственными силами или силами Leroy Merlin.
-
Маркетплейс работает по комиссионной схеме: продавец реализует товар по собственным розничным ценам, а площадка берет за это свой процент.
-
Интернет-магазин работает в Москве, Санкт-Петербурге, Иваново, Нижнем Новгороде, Самаре и Новосибирске.
Любому поставщику или продавцу Leroy Merlin и других маркетплейсов могут понадобится услуги складского хранения, упаковки и доставки. Такие работы лучше отдать на аутсорс подрядчику, чтобы спокойно заниматься развитием бизнеса.
Компания Кактус — это фулфилмент-оператор полного цикла: мы работаем по схемам FBO и FBS (DBS — в ближайшей перспективе). С нашими сервисами вы можете продавать на популярных маркетплейсах централизованно, с одного склада и в едином для всех площадок личном кабинете.
А еще мы помогаем селлерам в регистрации личного кабинета, создании карточек товара на Wildberries и других маркетплейсах, делаем видеосъемку процесса упаковки и продвигаем магазины на популярных площадках.
Все новости нашего блога и актуальную информацию о работе на маркетплейсах вы можете узнать в нашем Телеграм-канале, подписывайтесь и будьте в курсе.
«Леруа Мерлен» запустил микросервисную платформу. Теперь cотрудники компании справляются с разработкой микросервисов почти без привлечения бэкенд-разработчиков. Аркадий Юсупов, директор направления «ЛМ Тех», делится опытом создания такой платформы
Период с 2016-го по 2018-й был самым экстенсивным в истории «Леруа Мерлен» в России. За это время мы открыли 48 магазинов (сейчас в сети 111 гипермаркетов). Изначально мы были больше ориентированы на офлайн. Однако по мере развития электронной коммерции путь клиента изменился и взаимодействие с ним усложнилось. Границы между онлайн и офлайн размылись, люди перестали пользоваться только одним каналом для совершения покупки. Естественным шагом для нас стал фокус на развитие омниканальности. А это тот еще вызов для компании с сотней гипермаркетов, разбросанных по всей стране и обладающих высокой степенью автономности!
Чтобы добиться внешних изменений, нужно было начинать изнутри.
Создание мобильной платформы
Первое, что мы сделали: в 2017 году обеспечили всех сотрудников корпоративными смартфонами и разработали мобильную платформу с набором сервисов. Если раньше сотрудники были вынуждены пользоваться стационарным компьютером на инфостойке в отделе, используя для работы более 40 отдельных приложений, то теперь с помощью смартфона они мгновенно смогли предоставлять клиенту полную информацию о товаре, проверять его наличие в магазине, проводить инвентаризацию, управлять товарным запасом и делать многое другое в режиме «единого окна».
Переход от монолитных решений к разработке микросервисов
Параллельно мы начали переход от монолитных решений к микросервисной архитектуре. Наша потребность в создании новых сервисов неуклонно росла. Чтобы удовлетворить ее в рамках монолитной архитектуры (структура, в которой все сервисы объединены в одном решении), понадобилось бы привлечь к работе десятки новых специалистов. Это означало огромные временные и денежные затраты.