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

Изучили наиболее популярные ecom-платформы в России и подготовили удобную сравнительную таблицу. В статье рассмотрены Ensi, SAP Commerce Cloud, Magento и «1С-Битрикс: Управление сайтом».

В электронной коммерции под платформой понимается система или набор систем, автоматизирующих основные процессы, связанные с товарами, клиентами и заказами. Такие комплексные решения могут одновременно содержать функциональность целых классов систем: PIM, CRM, OMS, CMS и других.

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

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

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

Языки важны не только своими техническими свойствами. Стоит также рассматривать стек с точки зрения рынка труда и подрядчиков. Ключевые вопросы здесь такие:

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

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

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

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

Стек, используемый в платформе Ensi, имеет важные преимущества: он популярен, доступен и эффективен.

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

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

Технологический аспект поддержки мы рассмотрели в предыдущем пункте. Здесь отметим организационные моменты.

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

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

У остальных платформ есть свои особенности поддержки:

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

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

• Замкнутая на себе монолитная коробка;
• Мелко гранулированные микросервисы;

Рассмотрим каждый из пунктов подробнее.

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

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

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

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

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

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

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

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

Битрикс требует создания API с нуля, и это большая работа. Зато для внедрения MVP он зачастую подходит больше.

Рассмотрим концепцию компании Gartner Pace-layered Application Strategy — удобную модель эволюции систем в организации.

В ритейле и электронной коммерции большая часть систем относятся к группе инноваций или конкурентных отличий. То есть, это либо зона быстрых экспериментов с минимальным time-to-market (например, в клиентском опыте или маркетинге) , либо зона уникальных, а не универсальных процессов, которые являются конкурентным преимуществом одного ритейлера над другими (например, скорость обработки заказов или процессы доставки) .

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

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

Затраты на первичное внедрение — существенная часть CapEx. Другой заметной частью таких затрат может быть стоимость лицензии.

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

Кроме финансов, лицензия может влиять и на другие аспекты:

• Ограничивать распространение внедренной платформы на другие филиалы и представительства;
• Запрещать развертывание на определенной конфигурации серверов;
• Создавать риск блокировки из-за санкций.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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