Сравнение платформ электронной коммерции

⟶ Сравнили популярные платформы для создания и развития электронной коммерции в России.

Содержание

О платформах электронной коммерции

  • «Платформа — это архитектурный фреймворк для создания приложений и набор компонент, позволяющий получать готовые и разрабатывать собственные стандартизированные сервисы.»
    Алексей Липчанский
    Сбербанк
  • «Традиционная платформа появляется для реализации групп приложений (продуктов, сценариев для разных групп пользо- вателей и т. п.) на основе общего набора компонент.»
    Максим Смирнов
    Консультант, автор и преподаватель курсов по ИТ-архитектуре
В электронной коммерции под платформой понимается система или набор систем, автоматизирующих основные процессы, связанные с товарами, клиентами и заказами. Такие комплексные решения могут одновременно содержать функциональность целых классов систем: PIM, CRM, OMS, CMS и других.

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

В исследовании не оцениваются бизнес-функции каждой из платформ. В ритейле, какой бы функциональной ни была платформа, существенная часть ресурсов тратится на ее кастомизацию и адаптацию к бизнес-процессам конкретной компании. Наличие той или иной фичи может как сокращать, так и увеличивать time-to-value, поскольку нередко требуется преодолевать заложенную в платформу бизнес-логику при кастомизации.
✨ PIM (Product Information Management)
Система для централизованного управления большими массивами данных о товарах. Подробнее
✨ CRM (Customer Relationship Management)
Система управления взаимоотношениями с клиентами.
✨ OMS (Order Management System)
Система для работы с заказами. Подробнее
✨ CMS (Content Management System)
Система управления контентом сайта или мобильного приложения.

Таблица сравнения платформ

Технологический стек

Рассматриваемые платформы распространены и актуальны. В том числе это касается и технологического стека, на котором они написаны. Конечно, каждый из языков и фреймворков — PHP 8, Java, .Net и др. — имеют свои важные особенности. Но ни одна из их характеристик не является существенным препятствием для использования в e-commerce платформах любого масштаба.

Языки важны не только своими техническими свойствами. Стоит также рассматривать стек с точки зрения рынка труда и подрядчиков. Ключевые вопросы:
  • 1
    Достаточно ли на рынке компаний, специализирующихся на избранном стеке?
  • 2
    Соответствуют ли эти компании вашему ценовому сегменту?
  • 3
    Развит ли рынок труда специалистов на этом стеке?
  • 4
    Готовы ли вы к конкуренции за разработчиков, если решите
    развивать собственную команду?
Некоторые решения, популярные в других странах, в России внедряются всего парой компаний. Это существенно повышает риск попасть в зависимость от подрядчиков или просто остаться без поддержки и возможности развивать решение на такой платформе.

А вот медианные значения зарплат разработчиков на популярных языках в зависимости от грейда:
Разные внутренние и внешние статусы заказов в OMS
Зарплаты бэкенд-разработчиков по данным калькулятора зарплат Хабр Карьеры на 15 июня 2023
Мы не стали уделять внимание технологическому стеку фронтовой части платформ. Вместо этого мы говорим об API-изации и Headless-подходе, то есть о характеристиках, которые в том числе помогают выделить фронт в отдельное приложение.

Особенности стека Ensi в сравнении с конкурентами

  • Производительность PHP последних версий (8.х) выросла в разы, по сравнению со старыми версиями, когда формировалась репутация языка. Да, в некоторых аспектах PHP все еще проигрывает в производительности node. js, Go и даже Java (стек SAP CC). Но этот проигрыш не является критическим, к тому же для таких случаев давно разработаны решения.
  • PHP и Laravel делают Ensi доступной и бизнесу, и разработчикам. Первые могут обращаться к огромному и доступному комьюнити, а разработчики получают удобный, современный open source фреймворк, на котором они могут автоматизировать процессы екома.
  • PHP дает возможность быстро реализовывать и затем качественно поддерживать разнообразную бизнес-логику.

Кто может поддерживать и развивать

Ensi — самая молодая и наименее известная из сравниваемых платформ. Это в том числе означает, что рынок пока не накопил достаточного опыта решения типовых задач на этой платформе.

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

У остальных платформ есть свои особенности поддержки:
  • SAP СС требует глубоких знаний платформы. Поддерживать решения могут в основном enterprise-интеграторы высокого ценового сегмента. Практика работы с небольшими внешними или внутренними командами не так распространена, в том числе из-за политики самого вендора.
  • Magento — более открытая по сравнению с SAP платформа с развитым международным комьюнити. Но так как она из коробки обладает очень широкой функциональностью, развитие решений на ее базе так же требует опыта работы именно с этим продуктом. В России всего несколько компаний специализируются на Magento, из-за этого выбор исполнителей довольно узкий.
  • Битрикс Управление сайтом — чрезвычайно распространенное решение среди разработчиков. Но некоторая технологическая отсталость и достаточность компетенций невысокого уровня для работы с ним приводят к тому, что внедренное решение не всегда легко поддерживать. К тому же, в сообществе разработчиков у Битрикса не очень хорошая репутация, и лучшие специалисты и интеграторы имеют тенденцию переходить в другой стек.

Архитектура

Архитектура платформы — ключевой фактор, определяющий подход к развитию IT ритейлера. Диапазон возможных вариантов здесь лежит между двумя крайними положениями:
  • Замкнутая на себе монолитная коробка
  • Мелко гранулированные микросервисы
Рассмотрим каждый из пунктов подробнее.

Замкнутая на себе монолитная коробка (Monolith)

В этом случае платформа — это единое приложение, где функциональность всех классов систем (PIM, CRM, OMS, CMS и т. д.) зашита внутрь коробки так, что отделить одну группу функций от другой невозможно или очень сложно.

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

Мелко гранулированные микросервисы (MSA)

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

Такой вид архитектуры подразумевает рассинхронизацию между бизнес-командами и командами IT. Чтобы реализовать бизнес-идею, нужно привлекать к разработке и тестированию множество микросервисов и их команды поддержки.

Сервисный подход (SOA)

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

Итого

Границы между разными типами архитектур размыты. Строго говоря, микросервисы — это подвид сервисной архитектуры. Одновременно с этим монолитные системы могут быть частью сложного SOA-ландшафта IT-систем, особенно, если они API-изированы из коробки или в рамках конкретного внедрения. Этот важный аспект мы рассмотрим ниже.

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

Но и монолиты с полным покрытием API и поддержкой headless могут быстро стать частью сервисной архитектуры, то есть перейти на другой уровень сложности. Это относится к решениям SAP и Magento. Битрикс требует создания API с нуля, и это большая работа. Зато для внедрения MVP он зачастую подходит больше.

Расширение функциональности

Рассмотрим концепцию компании Gartner Pace-layered Application Strategy — удобную модель эволюции систем в организации.
Разные внутренние и внешние статусы заказов в OMS
Простое изложение концепции Максима Смирнова
В ритейле и электронной коммерции большая часть систем относятся к группе инноваций или конкурентных отличий. То есть, это либо зона быстрых экспериментов с минимальным time-to-market (например, в клиентском опыте или маркетинге), либо зона уникальных, а не универсальных процессов, которые являются конкурентным преимуществом одного ритейлера над другими (например, скорость обработки заказов или процессы доставки).

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

Особенности расширения функциональности Ensi в сравнении с SAP CC, Magento и Битрикс

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

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

Концепция Ensi предлагает противоположный подход: предоставляет фреймворк для разработки функциональности на основе сформулированных бизнес-требований. То есть не система определяет реализацию, а наоборот процессы определяют то, какой должна быть система.

Лицензия

Затраты на первичное внедрение — существенная часть CapEx. Другой заметной частью таких затрат может быть стоимость лицензии. Но в некоторых случаях затраты на лицензию могут быть и частью постоянных затрат OpEx. Особенно, если она привязывает платформу к SaaS-инфраструктуре вендора и/или к объему продаж ритейлера. Кроме финансов, лицензия может влиять и на другие аспекты:
  • Ограничивать распространение внедренной платформы на другие филиалы и представительства;
  • Запрещать развертывание на определенной конфигурации серверов;
  • Создавать риск блокировки из-за санкций.

Итого

  • 1
    SAP Commerce CC и платные версии Magento (Adobe Commerce) требуют постоянных и заметных затрат на продление лицензии.
  • 2
    Использование Битрикса так же требует ежегодных платежей, правда, значительно более низких даже в случае enterprise-лицензии. Однако, на рынке распространена практика непродления лицензии, что ведет только к потере возможности обновляться.
  • 3
    Ensi и комьюнити-версия Magento распространяются бесплатно по open source лицензии.

API-изация

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

Отдельно стоит отметить важность покрытия API для выделения в отдельное приложение фронтов. Витрины и административные интерфейсы — наиболее кастомизируемые и часто меняющиеся части IT-систем.

Итого

Ensi использует API-first подход к разработке, а в SAP Commerce и Magento API реализовано как часть богатой функциональности. Битрикс долгое время не имел покрытие функций API, и разработчики каждый раз были вынуждены писать его с нуля. Но с какого-то момент модуль API, ранее появившийся в «Битрикс24», есть и в «Битрикс Управление сайтом».

Headless

Headless-приложения не имеют собственного человеческого интерфейса. Функциональность такого ПО доступно по API. Для того, чтобы пользователи могли работать с функциями headless-сервиса, нужно предварительно вывести их в какой-то интерфейс, то есть создать frontend-приложение.

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

Реализация Headless в Ensi в сравнении с другими платформами

Ensi — headless платформа. Составной частью системы является API Gateway и фронтовые фреймворки для быстрого создания административного интерфейса, рабочего места менеджера и клиентских витрин.

В Magento и SAP Commerce — административный интерфейс является частью монолита. Клиентские витрины — выделены в модули. Полное покрытие функциональности API позволяет создавать и собственные клиентские фронтовые приложения.

В Битриксе и административный, и клиентский фронт является частью монолита.

Безопасность

☞ Безопасность — это зона ответственности прежде всего команды внедрения. Причем не только в вопросах разработанной функциональности, но и в зоне программно-аппаратных средств, на которых работает внедренное решение, а также общей организации процессов внедрения.
Платформы могут придерживаться определенных подходов к безопасности, но то, насколько следуют им команды в каждом случае внедрения, больше зависит от самих команд и того, насколько вендор жестко регулирует процесс внедрения. Open source платформы могут внедряться как угодно, тогда как облачные enterprise-решения реализуются в строго определенных вендором рамках.

Подход к обновлениям

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

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

Внедрение обновлений в Ensi в сравнении с другими платформами

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

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

Статус в России

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

Полностью безопасным с точки зрения лицензионных и санкционных рисков можно считать только Ensi, Битрикс, и отчасти комьюнити версию Magento. SAP Commerce и enterprise-продукцию Adobe официально приобрести в России нельзя, а уже внедренные решения находятся под угрозой блокировки, особенно SaaS-варианты.
Поэтапный перенос элементов витрины
26 сентября 2023
В статье использованы материалы Кусочков екома, Николая Воробьева

Автор статьи

  • Сергей Мелихов
    Директор новых проектов
Мини-книга «Сравнение платформ электронной коммерции»
Нажимая на кнопку «Скачать», вы соглашаетесь с условиями обработки персональных данных.

подписывайтесь и будьте в курсе

Факты из жизни электронной коммерции
Новости от разработчиков платформы
Официальный новостной канал платформы
Блог в расширенном формате