ERP-система — нет, микросервисный подход — да, подойдет для создания маркетплейса. Давайте разбираться, что к чему

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

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

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

Не используйте для разработки ERP-систему

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

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

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

То есть, грубо говоря, система управления заказами (OMS) сама маршрутизирует потоки (подборы товаров, идентификация позиций товаров по конкретным поставщикам и т.д.). Должны быть автоматизированы все процессы системы: управление каталогом, программы лояльности, витрина и т.д.

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

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

Да, и в целом на рынке IT еще нет комплексных решений, которые бы могли покрывать функционал, связанный с операционной деятельностью маркетплейса. 

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

И в конечном итоге компания жалуется на результат, потому что ожидания не совпадают с реальностью. Ждали резкого взлета в продажах, а получили не более 10% от общего оборота. Все это довольно грустно. Но выход есть. 

Сделайте выбор в пользу микросервисного подхода

Как раз его используют крупные торговые площадки. 

Суть микросервисной архитектуры состоит в том, что каждая отдельная функция (набор функций) выделяется в самостоятельную систему. То есть OMS (управление заказами), PIM (управление товарным каталогом), система биллинга, транспортная система, личный кабинет, программа лояльности, склад и т.д. - все это отдельные системы в единой архитектуре. 

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

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

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

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

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

Таким образом, если компания хочет выйти на рынок с настоящим маркетплейсом, то его нужно создавать на микросервисной платформе и становиться одним из его продавцов. Это и будет правильное архитектурное решение. Нет необходимости ломать текущие системы ERP, WMS, с которыми привычно работать в своей специфике бизнеса. 

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

Как начать работу с проектом по запуску маркетплейса

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

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

  • формирование ключевых систем автоматизации маркетплейса в формате “To be”;

  • построение общей архитектуры компонентов маркетплейса с определением потока данных и нагруженности систем;

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

  • формирование ключевых требований к инфраструктуре. 

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

Источник: https://habr.com/ru/company/rdv-it/blog/543290/


Интересные статьи

Интересные статьи

Всем привет, последние 2-3 года у меня было интересное хобби, интересное для меня - предоставление аналитических услуг компаниям в Канаде и США. В этой статья я хочу поде...
Продвижение свободы слова за счет изменения экономической и цифровой инфраструктуры интернета БУДУЩЕЕ СВОБОДЫ СЛОВА Серия статей, для переосмысления Первой поправки ...
Аннотация, или о досуге молодых ученых Последние несколько недель мы с коллегами заканчиваем рабочий день тем, что соревнуемся в точности прогноза развития эпидемии COVID-19 в России, используя ...
Для многих людей опенспейсы — символ корпоративного ада. Противники открытой планировки говорят об ощущении переполненного муравейника, который населяют не люди, а производственные единицы. Разбе...
Самый первый транзистор был биполярным и германиевым, но подавляющее большинство современных интегральных микросхем сделаны из кремния по технологии КМОП (комплементарный металл-оксид-полупроводн...