История о том, как мы сделали крутейшее решение вокруг PIM Akeneo, а потом отказались от него, начав все с нуля.
Все началось пару лет назад, в период активного роста Hubber Online — площадки для взаимодействия интернет-магазинов и поставщиков товаров в Украине. Мы построили успешную платформу, которой заинтересовались Leroy Merlin Vostok. Они захотели подобную платформу для себя, и по итогам знакомства мы создали новый IT-продукт, который позволяет развернуть маркетплейс индивидуально под клиента, учитывая особенности бизнес-процессов.
С этим ритейлером мы прошли путь самурая — построили бОльшую часть системы маркетплейса. Выделили 30 человек из действующей команды, которые сейчас составили основной штат Scаllium. Продукт обошелся в себестоимости несколько сотен тысяч долларов, плюс бюджет на поддержку.
После этого мы решили создать новую технологическую платформу, которая бы решала сразу несколько задач.
В итоге у нас получился некий баланс между Service Oriented Architecture (SOA) и микро-сервисами, ландшафт которого состоит из десятков подпродуктов и систем, каждая из которых тоже состоит из целой группы сервисов.
Мы переписывали систему с нуля. Не буду останавливаться на том, что лучше — постепенно избавиться от всего старого или резко переписать все заново. Мы остановились на постепенном выпиливании.
Важно, что потребности новой платформы отличались от того, что мы делали для Leroy Merlin. Они были шире и решали задачу максимальной применимости для других типов маркетплейсов и бизнесов из онлайн-торговли. В первую очередь, появились новые требования в плане устойчивости к нагрузкам, количеству транзакций и исходящие из этого условия architectural runway. Раньше было достаточно содержать десятки миллионов SKU, теперь счет пошел на миллиарды. Плюс новая платформа должна выдерживать сотни тысяч заказов.
PIM (Product information management) — это часть системы маркетплейса, которая может быть независимым продуктом. Мы даже сейчас подумываем, не продавать ли его отдельно, так как он подходит не только маркетплейсу, но и онлайн-продавцам, поставщикам, дистрибьюторам и оффлайн бизнесу. PIM содержит кабинет контент-менеджера, систему валидации, заведения и хранения товаров и быстрого доступа (кеширования).
В тот момент мы решили не изобретать велосипед, а приобрести PIM у Akeneo, поскольку это одна из самых популярных систем PIM с открытым кодом. Сразу обнаружили, что Akeneo концентрируется только на холодном хранении данных: грубо говоря, хорошо записывала, но медленно читала. При больших объемах данных скорость ответа системы на запрос могла иногда измеряться секундами. Akeneo обладает отличным функционалом, но медленная скорость нас не устраивала. Поэтому мы сделали обвязку вокруг их PIM, создали около 20 дополнительных сервисов, задачей которых было кеширование и ускорение работы данных. Это выглядело так (3-й уровень архитектуры):
Здесь выделено Akeneo, а все остальное — сервисы, которые мы написали, чтоб ускорить PIM. Вся архитектура в одну картинку не влезет, но вот для понимания приближенная часть схемы, чтоб можно было разобрать названия блоков:
Была проделана колоссальная работа, в результате которой мы практически стали партнерами-интеграторами Akeneo… И вдруг осознали, что для нашего бизнеса (платформа из 6 блоков, как на первом рисунке) PIM — это сердце. И, получается, мы это сердце отдаем другому (пусть и ключевому) партнеру, от которого будем сильно зависеть.
После этого осознания стало понятно, что нужно писать свой PIM. И мы написали не хуже с точки зрения архитектуры. С точки зрения фич, конечно, нужно было много работать. Мы собрали команду из 65 человек, и постепенно начали догонять и по функционалу.
Сейчас мы понимаем, что продуманная архитектура дает выигрыш уже на поздних этапах разработки. Нам это сильно помогло ускориться через год работы.
Возвращаясь к функционалу, подчеркну, что наша цель — это максимальная эффективность работы маркетплейса: большое количество товаров, удобное и быстрое заведение товаров командой контент-менеджеров, возможность делать это конкретными мерчантами с условием валидации контент-менеджерами.
Например, мы сделали в нашем PIM мастер-данные и умный каталог. И, если первый уже был в определенном виде у Akeneo, то умный каталог появился уже после того, как мы сделали свой.
Как это работает: когда мерчант вводит “айфон 10”, система ему подсказывает: “Ты IPhone X имеешь в виду?” Мерчант нажимает “Да”, и система подтягивает все характеристики модели. С помощью мастер-данных удобно работать с аналитикой — например, сравнивать цены и подсказывать мерчанту: “У тебя слишком высокая цена на IPhone X”.
Или еще пример. Когда мерчант вводит “IPhone 33 гб”, система скажет: “Извини, но такой модели нет. Выбирай: 32 гб/64 гб или создавай новый товар”. Такие подсказки помогают значительно ускорить процесс работы.
Важны также более продвинутые офферы. Ведь все понимают, что у маркетплейса на витрине отображается не товар, а оффер — предложение конкретного мерчанта. Или даже связка товаров, карточка со всеми предложениями. Можно выбрать из всех предложений необходимое. Мы на этом не остановились, а добавили к офферам вариант каналов и специальный преобразователь канала: веб-витрина, мобайл-витрина, кросс-бордер (если товар продается через Shopify или др) — разные каналы требуют разного формата контента, иногда разной структуры каталога и т д. Соответственно, этот контент должен иметь возможность отображаться по-разному в каждом из каналов.
Преобразователи в канал — важная штука, потому что обычно у маркетплейса их несколько: есть партнеры, есть разные витрины, и каждый работает еще с дополнительными дистрибьюторами, блоггерами и партнерскими продажами. Мир меняется каждый день, и завтра понадобится выход на тысячи витрин партнеров. Это делается довольно быстро с помощью каналов трансформации при помощи тех же самых данных.
Мы также поработали над маппингом дерева каталогов. Представьте, что у вас бритва Brown находится в категории электробритв, а Электробритвы находятся в Электроинструментах. А теперь представьте, что у вашего мерчанта, который заливает свои товары, совершенно другие категории. У него бритва Brown находится в дереве под брендом Brown. А, кроме мерчанта, есть еще витрины партнеров, у которых третья классификация. Проблему решает мастер каталог с обильным набором данных (характеристики и т.д.). Маппинг на этот каталог — это соотношение вашего универсального каталога с другими каталогами. Его нужно один раз настроить, и дальше все работает автоматически.
То есть, мы сильно продвинули систему с точки зрения бизнес-процессов конкретно для маркетплейса. По сути, у нас получилась PIM + DAM (Digital Asset Management) + MDM (Master Data Management) + TCM (Transformations and Channels Management) системы, которые идут в связке. И это сложнее, чем устроено большинство современных PIM.
Повторюсь, некоторые из озвученных фишек в том или ином виде у Akeneo тоже есть, и довольно хорошо реализованы. Однако нам нужно было заточить систему под бизнес-процессы маркетплейса, и сделать так, чтоб эта система работала быстрее и стабильнее за счет группы дополнительных сервисов и современной архитектуры.
Отказ от использования Akeneo дал толчок проекту и в части создания модели для работы с интеграторами и партнерами в будущем. Допустим, интегратор инсталлировал наш продукт и кастомизировал его, а мы можем обновлять платформу, не затрагивая те доработки, которые были при интеграции. Здесь была выбрана модель работы с интеграциями, аналогичная Jira.
Итак, все 6 модулей с первой схемы сейчас являются нашей собственной разработкой. Есть другие компоненты, которые мы всегда берем извне. Например, CRM, BI (система для анализа данных) — существуют отличные продукты на рынке, и нет смысла с ними конкурировать. Также мы не собираемся бороться на рынке создания витрин. Но вот эти 6 модулей, ядро маркетплейса (бэк-офис) мы делаем сами.
Для маркетплейса главное — гибкость. Один наш клиент, магазин электроники, вдруг начал продавать велосипеды. Он был спец в велосипедах? Нет. Но он быстро и максимально дешево протестировал эту новую категорию. Просто добавил новый товар на свою витрину, и увидел, что люди готовы покупать велосипеды из Польши, ждать товар 3 недели и при этом еще и предоплату делать.
Это один из принципов Agile. Я всегда говорю, что маркетплейс — это Agile способ ведения бизнеса. Тестирование гипотезы с помощью быстрого выведения предложения на рынок — очень важно в наши дни. Это значит, что маркетплейс должен максимально быстро завести новую категорию товаров, в которой он не обязательно разбирается, посмотреть спрос и дальше расширять эту категорию или отменить выбор. Для бизнеса с правильной платформой эти эксперименты дешевле, и они же дают маркетплейсу конкурентное рыночное преимущество — скорость. А когда важна скорость, нельзя полагаться на экспертизу. Только на эксперименты!
Все началось пару лет назад, в период активного роста Hubber Online — площадки для взаимодействия интернет-магазинов и поставщиков товаров в Украине. Мы построили успешную платформу, которой заинтересовались Leroy Merlin Vostok. Они захотели подобную платформу для себя, и по итогам знакомства мы создали новый IT-продукт, который позволяет развернуть маркетплейс индивидуально под клиента, учитывая особенности бизнес-процессов.
С этим ритейлером мы прошли путь самурая — построили бОльшую часть системы маркетплейса. Выделили 30 человек из действующей команды, которые сейчас составили основной штат Scаllium. Продукт обошелся в себестоимости несколько сотен тысяч долларов, плюс бюджет на поддержку.
После этого мы решили создать новую технологическую платформу, которая бы решала сразу несколько задач.
- Закрыть потребности нашей существующей платформы для поставщиков и интернет-магазинов, которые хотят стать маркетплейсами;
- Создать конструктор маркетплейсов, который можно максимально настраивать под клиентов, не дописывая;
- Решить задачу модульности. Мы не хотели делать микро-сервисную архитектуру, а искали баланс между SOA и бизнес-ценностью, пытаясь при этом учесть предыдущий опыт.
- Решить задачу экстремальной стабильности и высокой нагрузки
В итоге у нас получился некий баланс между Service Oriented Architecture (SOA) и микро-сервисами, ландшафт которого состоит из десятков подпродуктов и систем, каждая из которых тоже состоит из целой группы сервисов.
Мы переписывали систему с нуля. Не буду останавливаться на том, что лучше — постепенно избавиться от всего старого или резко переписать все заново. Мы остановились на постепенном выпиливании.
Важно, что потребности новой платформы отличались от того, что мы делали для Leroy Merlin. Они были шире и решали задачу максимальной применимости для других типов маркетплейсов и бизнесов из онлайн-торговли. В первую очередь, появились новые требования в плане устойчивости к нагрузкам, количеству транзакций и исходящие из этого условия architectural runway. Раньше было достаточно содержать десятки миллионов SKU, теперь счет пошел на миллиарды. Плюс новая платформа должна выдерживать сотни тысяч заказов.
PIM (Product information management) — это часть системы маркетплейса, которая может быть независимым продуктом. Мы даже сейчас подумываем, не продавать ли его отдельно, так как он подходит не только маркетплейсу, но и онлайн-продавцам, поставщикам, дистрибьюторам и оффлайн бизнесу. PIM содержит кабинет контент-менеджера, систему валидации, заведения и хранения товаров и быстрого доступа (кеширования).
В тот момент мы решили не изобретать велосипед, а приобрести PIM у Akeneo, поскольку это одна из самых популярных систем PIM с открытым кодом. Сразу обнаружили, что Akeneo концентрируется только на холодном хранении данных: грубо говоря, хорошо записывала, но медленно читала. При больших объемах данных скорость ответа системы на запрос могла иногда измеряться секундами. Akeneo обладает отличным функционалом, но медленная скорость нас не устраивала. Поэтому мы сделали обвязку вокруг их PIM, создали около 20 дополнительных сервисов, задачей которых было кеширование и ускорение работы данных. Это выглядело так (3-й уровень архитектуры):
Здесь выделено Akeneo, а все остальное — сервисы, которые мы написали, чтоб ускорить PIM. Вся архитектура в одну картинку не влезет, но вот для понимания приближенная часть схемы, чтоб можно было разобрать названия блоков:
Была проделана колоссальная работа, в результате которой мы практически стали партнерами-интеграторами Akeneo… И вдруг осознали, что для нашего бизнеса (платформа из 6 блоков, как на первом рисунке) PIM — это сердце. И, получается, мы это сердце отдаем другому (пусть и ключевому) партнеру, от которого будем сильно зависеть.
После этого осознания стало понятно, что нужно писать свой PIM. И мы написали не хуже с точки зрения архитектуры. С точки зрения фич, конечно, нужно было много работать. Мы собрали команду из 65 человек, и постепенно начали догонять и по функционалу.
Сейчас мы понимаем, что продуманная архитектура дает выигрыш уже на поздних этапах разработки. Нам это сильно помогло ускориться через год работы.
Возвращаясь к функционалу, подчеркну, что наша цель — это максимальная эффективность работы маркетплейса: большое количество товаров, удобное и быстрое заведение товаров командой контент-менеджеров, возможность делать это конкретными мерчантами с условием валидации контент-менеджерами.
Например, мы сделали в нашем PIM мастер-данные и умный каталог. И, если первый уже был в определенном виде у Akeneo, то умный каталог появился уже после того, как мы сделали свой.
Как это работает: когда мерчант вводит “айфон 10”, система ему подсказывает: “Ты IPhone X имеешь в виду?” Мерчант нажимает “Да”, и система подтягивает все характеристики модели. С помощью мастер-данных удобно работать с аналитикой — например, сравнивать цены и подсказывать мерчанту: “У тебя слишком высокая цена на IPhone X”.
Или еще пример. Когда мерчант вводит “IPhone 33 гб”, система скажет: “Извини, но такой модели нет. Выбирай: 32 гб/64 гб или создавай новый товар”. Такие подсказки помогают значительно ускорить процесс работы.
Важны также более продвинутые офферы. Ведь все понимают, что у маркетплейса на витрине отображается не товар, а оффер — предложение конкретного мерчанта. Или даже связка товаров, карточка со всеми предложениями. Можно выбрать из всех предложений необходимое. Мы на этом не остановились, а добавили к офферам вариант каналов и специальный преобразователь канала: веб-витрина, мобайл-витрина, кросс-бордер (если товар продается через Shopify или др) — разные каналы требуют разного формата контента, иногда разной структуры каталога и т д. Соответственно, этот контент должен иметь возможность отображаться по-разному в каждом из каналов.
Преобразователи в канал — важная штука, потому что обычно у маркетплейса их несколько: есть партнеры, есть разные витрины, и каждый работает еще с дополнительными дистрибьюторами, блоггерами и партнерскими продажами. Мир меняется каждый день, и завтра понадобится выход на тысячи витрин партнеров. Это делается довольно быстро с помощью каналов трансформации при помощи тех же самых данных.
Мы также поработали над маппингом дерева каталогов. Представьте, что у вас бритва Brown находится в категории электробритв, а Электробритвы находятся в Электроинструментах. А теперь представьте, что у вашего мерчанта, который заливает свои товары, совершенно другие категории. У него бритва Brown находится в дереве под брендом Brown. А, кроме мерчанта, есть еще витрины партнеров, у которых третья классификация. Проблему решает мастер каталог с обильным набором данных (характеристики и т.д.). Маппинг на этот каталог — это соотношение вашего универсального каталога с другими каталогами. Его нужно один раз настроить, и дальше все работает автоматически.
То есть, мы сильно продвинули систему с точки зрения бизнес-процессов конкретно для маркетплейса. По сути, у нас получилась PIM + DAM (Digital Asset Management) + MDM (Master Data Management) + TCM (Transformations and Channels Management) системы, которые идут в связке. И это сложнее, чем устроено большинство современных PIM.
Повторюсь, некоторые из озвученных фишек в том или ином виде у Akeneo тоже есть, и довольно хорошо реализованы. Однако нам нужно было заточить систему под бизнес-процессы маркетплейса, и сделать так, чтоб эта система работала быстрее и стабильнее за счет группы дополнительных сервисов и современной архитектуры.
Отказ от использования Akeneo дал толчок проекту и в части создания модели для работы с интеграторами и партнерами в будущем. Допустим, интегратор инсталлировал наш продукт и кастомизировал его, а мы можем обновлять платформу, не затрагивая те доработки, которые были при интеграции. Здесь была выбрана модель работы с интеграциями, аналогичная Jira.
Итак, все 6 модулей с первой схемы сейчас являются нашей собственной разработкой. Есть другие компоненты, которые мы всегда берем извне. Например, CRM, BI (система для анализа данных) — существуют отличные продукты на рынке, и нет смысла с ними конкурировать. Также мы не собираемся бороться на рынке создания витрин. Но вот эти 6 модулей, ядро маркетплейса (бэк-офис) мы делаем сами.
Для маркетплейса главное — гибкость. Один наш клиент, магазин электроники, вдруг начал продавать велосипеды. Он был спец в велосипедах? Нет. Но он быстро и максимально дешево протестировал эту новую категорию. Просто добавил новый товар на свою витрину, и увидел, что люди готовы покупать велосипеды из Польши, ждать товар 3 недели и при этом еще и предоплату делать.
Это один из принципов Agile. Я всегда говорю, что маркетплейс — это Agile способ ведения бизнеса. Тестирование гипотезы с помощью быстрого выведения предложения на рынок — очень важно в наши дни. Это значит, что маркетплейс должен максимально быстро завести новую категорию товаров, в которой он не обязательно разбирается, посмотреть спрос и дальше расширять эту категорию или отменить выбор. Для бизнеса с правильной платформой эти эксперименты дешевле, и они же дают маркетплейсу конкурентное рыночное преимущество — скорость. А когда важна скорость, нельзя полагаться на экспертизу. Только на эксперименты!