У нас в Леруа есть много товаров, которые хотелось бы поставить на полки. Например, побольше видов обоев. Или профессиональное оборудование. У нас есть материалы для отделки спален, но нет кроватей и постельного белья. И так далее. 16 миллионов человек ежемесячно посещают сайт при населении России 146,8 миллиона человек. Поверьте, нашим покупателям хочется много чего, кроме 40 тысяч товаров основного ассортимента.

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

Это космос. Это почти как закупить товар и продать его клиенту, только без закупки. В смысле: чего клиент хочет, мы показываем ему сразу наличие у поставщика, он покупает, транспортная компания везёт с нашими документами напрямую (как если бы это было куплено у нас), а если вдруг надо вернуть по гарантии или обменять — это делается через любой наш магазин.

В случае успеха это такое резкое изменение бизнес-модели, что можно гордиться ещё года три. А внедрять всё пару месяцев. Как нам поначалу показалось.

Как это всё работает?

Вы покупаете у нас что-то для спальни и хотите купить к ней не совсем привычное бельё:



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



А вот строительные пылесосы:



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

У наших поставщиков в линейках все товары из примеров есть. Скорее всего, мы берём у таких поставщиков штук по 50 лучших товаров при том, что общий ассортимент у него будет в 300-2000 позиций. И ещё доставляем от других поставщиков маркетплейса, которые не работают с нами на рознице.

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

Когда вы покупаете постельное бельё или что-то ещё подобное не с полки, вам формируется отдельная доставка со склада поставщика. Мы рассчитываемся с поставщиком — как бы покупаем у него этот товар, даём свои документы на него и отправляем к вам. Но физически товар едет напрямую от поставщика.



Вы получаете товар с документами от нас.

В случае проблем с товаром (поломок или обмена) возвращаете нам.

Потом эта же модель была расширена до поставщиков, товаров которых ещё нет на наших полках: например, в регионах очень много ИП и небольших ООО, продающих сопутствующий ассортимент, но с ними просто нет времени и возможности заморачиваться на заключение договоров поставки. Это для большой розницы огромная задача: для правильного соблюдения договора при работе с сетью нужно иметь собственный отдел, следящий только за таким договором.

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

Теперь такие товары можно тестировать на маркетплейсе. И если на них есть большой спрос — сразу ставить в сеть. То есть мы получили испытательный полигон.

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

В общем, это всё надо было делать. Глаза у нас горели.

Это была верхушка айсберга

По третьей причине из списка выше мы решили обособить маркетплейс от остальной логики бизнеса Леруа Мерлен для снижения издержек бизнеса за счёт автоматизации. Ведь именно для этого нужен ИТ-отдел в компании – уметь решать задачи, которые требуют гибкости.

Мы создали отдельный бизнес-юнит рядом с традиционной розницей и e-commerce. Начали с материалов для декора — их реально миллионы SKU, и их всегда не хватает клиентам в духе: «А есть такой же, только полиловее?»

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

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

Потом оказалось, что в регионах много локальных поставщиков, которые ради того, чтобы хорошо продавать на новом канале, где очень просто продать довольно много товара, по их меркам, стали опускать цены. Точнее, опускать цены на аналоги наших товаров, которые в основном ассортименте. А поскольку наша политика — самые доступные цены, то пришлось делать модель пересчёта цен на товары розницы, если в маркетплейсе появляется игрок с аналогичным товаром.

В общем, примерно полгода мы работали на MVP и делали всё чуть ли не макросами Excel (на самом деле — нет, но многое было на костылях и синей изоленте). Задача была дособрать требования.

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

Реальность и подводные камни

Во-первых, мы стараемся соединить три части коммуникации (розницу, традиционный e-commerce и нашу площадку) в один общий канал продаж. Это называется омниканал, он выглядит как расширенное приложение в онлайне. Например, как терминал в магазине, где можно заказать обои нужного рисунка, если его нет в основном ассортименте.

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



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

Операционная часть — трекинг и управление, раздача партнёрам, подготовка документа к приезжающей службе, трейсинг и контроль отклонений.



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

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

Систему проектировали в двух приоритетах:

1. Идеально в срок доставленный заказ.
2. Обрабатываемые заказы на количество партнёров (мощность потока).

Пример проблемы: посчитали одну отправку, приехали логисты за коробкой, а она другого размера. Поменялись характеристики заказа «на лету».

В-четвёртых, ассортимент. Вопрос: если есть два аналогичных товара в нашем ассортименте и в ассортименте поставщика — надо ли падать в цене до минимума? Да, по политике цен Леруа Мерлен в том же городе — надо. А если это другой город? Тогда, наверное, нет: кто-то готов менять 8% скидки на четыре дня ожидания.

Ещё вопрос: два поставщика занесли на маркетплейс рабочие рукавицы. У нас их в ассортименте 40 видов, они добавили ещё по 50 каждый. По 10 из них — пересечения, и цены на них разные. Оставим обоих? Наверное, да. Клиента интересует скорость доставки, а тут она пойдёт из разных мест и по разной цене.

В-пятых, обмен актуальными складскими остатками и ценами. Поставщики должны выгружать это всё регулярно, либо отправлять реквесты нам при изменениях у себя. Мы решили использовать автоматические модули к их ERP — чаще всего это 1С, и решений много. А сложность вот в чём: чтобы поставщик правильно вёл учёт в 1С, нужно, чтобы он был более-менее крупный. А когда он более-менее крупный, его 1С иногда представляет собой месиво из костылей. В итоге получается, что каждую связь надо поддерживать. Немного, но надо. Поэтому пока мы решили ограничиться средним бизнесом в списке поставщиков в Москве и экспериментировать с крупными ИП в регионах.

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

В-шестых, возврат. Чтобы возвращать товары в магазин, нужно:

1. Договориться с магазином, что там принимают возвраты. Это значит поменять систему обучения продавцов, потому что, разумеется, не все из них понимают, что это такое и как с ним работать.
2. Сделать процедуры проверки в IT-системах продавцов: поначалу они не знали, где смотреть чеки, и не проверяли сроки возвратов.
3. Настроить финансовые процессы возврата (это было относительно быстро).
4. Сделать переупаковку в транспортную тару, потому что часто возврат выполняется без коробки.
5. Сделать сервис замены (ещё одна петля на доставку): мы не чиним товары в сервисе, а просто отдаём их назад поставщику и отправляем новый при обмене. Фактически любой инцидент по товару заканчивается возвратом.

Договоры. Сначала мы думали, что придётся искать локальных поставщиков, но ситуация оказалась обратной. Все лезут на свет и хотят в маркетплейс, потому что рассматривают это как выход на дистрибуцию (что для многих победа) либо как дополнительный канал продаж. Возникла сложность на входном контроле. Сейчас мы автоматизировали всё напрашивающееся на автоматизацию, но всё равно остаётся долгий процесс юридической проверки. Почему это нужно — потому что если поставщик пропадёт, то мы, конечно, решим вопрос с клиентом, но сами попадём на НДС.



Сейчас большие планы по скорингу и рейтингу: например, если не отгрузил вовремя, то деградировал в звёздности. На выдачу будут влиять точность описания, уровень цен, скорость комплектации и так далее. Рейтинг падает ниже тройки — можно отказываться от поставщика.

Ещё особенность маркетплейса — это война за поисковое продвижение. Фактически нужно больше контента. А контент требовать от поставщиков сложно. Поэтому нужен был процесс по продуктовым описаниям и изображениям. Мы аутсорсим фотосъёмку в студии в регионах: предлагаем поставщику услугу фотосессии его товара. Он оплачивает и получает картинки (часто первые в своей жизни на товар) — мы грузим их на маркетплейс, в частности. Описания товаров делаются примерно по такой же схеме.

Над приведением к однообразию атрибутов товаров для облегчения поиска в маркетплейсе еще придется поработать.

И последняя важная особенность проекта — нам было крайне важно скоординироваться в периметре легаси-систем головного Леруа Мерлен (точнее, «материнской» группы компаний ADEO) во Франции. Потому что любое изменение, тестирование, согласование и имплементация — довольно длительные процессы. Поэтому кое-где мы продублировали процессы по новой. Мы выбрали API-centric-архитектуру на микросервисах, на прото описываем все апишечки каждого сервиса, а дальше — Go (для скейлинга и нагрузок) либо Node.js. В качестве базы — MongoDB и PostgreSQL. Для части разработок привлекали аутсорсеров, поиграли в метод гибридной команды. На этом проекте аутсорс находится в Челябинске, но 30% команды — у нас. При успехе проекта планируем постепенно уменьшать аутсорсинговые ресурсы и увеличивать свои. Тем не менее аутсорс помог нам осуществить быстрый старт проекта плюс показал некоторые неочевидные для команды особенности API-centic-подхода на практике.

Итог

Аналогичный маркетплейс стартовал в Бразилии чуть позже, чем у нас. Они меньше, и там есть проблемы с логистикой, которые мы сразу решили ещё на стадии продумывания архитектуры. Во Франции маркетплейс старше нашего, но там, скорее, особенность «длинного хвоста» — того, что принадлежит Леруа, но не находится в конкретном магазине. Там особенность была в том, что покупатели обучили продавцов продавать оттуда, поскольку были очень требовательны по товару.

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