«Курс на онлайн»: чек-лист по выбору e-commerce платформы
Многие компании на старте не придают должного значения проработке трех важных вопросов: исследование целевой аудитории и доли рынка, бизнес-кейса и технологической архитектуры будущего бизнеса. Торговля онлайн – не просто еще один канал продаж, а отдельный бизнес, который требует проработанной на несколько лет вперед стратегии.
Бизнес-кейс – это понимание, как будет генерироваться прибыль. E-commerce бизнес живет благодаря трафику: необходимо планировать и понимать, откуда он придет. Доход должен быть больше расходной части. Расходная часть должна включать все, что входит в общую стоимость продукта (total cost of ownership): технологию, на которой будет выстроен e-commerce бизнес, затраты на техобслуживание и наем дополнительного ИТ-персонала, в том числе с расчетом индексации, повышения зарплат и т.д.
Также необходимо выстроить детальное понимание бизнес-процессов. Классическая тройка в e-commerce: продуктовый каталог, блок управления заказами и управление контентом. За пределами онлайн-части нельзя забывать о логистике: по какой модели будет выстроена доставка и возврат товаров. Понимание бизнес-кейса и детальное описание процессов позволит создать дорожную карту. При текущей ситуации в бизнесе enterprise-уровня точка безубыточности должна быть не дальше, чем через два года, в малом бизнесе – раньше.
Дорожная карта бизнес-процессов
Когда вы уже определили свою долю рынка, построили гипотезы – время проверить все на пилотном проекте. Чтобы запустить пилот, нужно решение, которое можно запустить быстро и с небольшими затратами. Это позволит проверить гипотезы с минимальным time2market.
Выбор e-commerce решения стоит начинать только после того, как пилотный запуск показал состоятельность. И здесь есть бизнес-параметры, с которыми нужно четко определиться до того, как приступить к решению вопросов с ИТ-архитектурой:
Объем данных и нагрузка. Количество SKU (продуктовых позиций в каталоге), количество клиентов сейчас и сколько ожидается в онлайне, планируемый рост. Если на пилоте бизнес работал с 1–2 продажами в день, через полгода он должен ждать 10, а через год 1000: эти цифры должны уже сейчас влиять на выбор платформы и решения. Рекомендуем считать рост этих показателей от нескольких месяцев до трех лет.
Функциональность. Определитесь, какой набор функций вам необходим. Заранее продумайте: как будет выглядеть карточка товара, какие способы доставки и оплаты будут доступны клиенту, в каком формате загружать данные на платформу, какие программы лояльности вы планируете запустить и т.д. Подробное описание всех процессов поможет вам лучше составить технические требования.
Интеграции. Как именно e-commerce система будет взаимодействовать с существующей ИТ-архитектурой и бизнес-процессами: какая потребуется обвязка, откуда, как и какую информацию система будет получать. Как правило, первой интегрируют CRM. Далее выстраивается интеграция с продуктовым каталогом и системой управления контентом. И конечно, надо предусмотреть, какие каналы коммуникации и каким образом будут задействованы в системе.
Инфраструктура. Где будут расположены серверы – на своей площадке или на аутсорсе. Как правило, небольшим бизнесам лучше работать с подрядчиком, крупные же компании имеют свою инфраструктуру. Также популярна гибридная схема, когда часть мощностей своя, а часть арендуется в облаке и используется, например, для преодоления периодов пиковых нагрузок во время сезона распродаж.
Технический чек-лист
После проработки бизнес-процессов рекомендуем пройти по детальному техническому чек-листу для бизнеса enterprise-уровня.
Хедлесс или не-хедлесс решение. Хедлесс-архитектура позволяет сокращать стоимость и сроки разработки, повышать качество решений из-за возможности независимой разработки клиентских приложений и backend-сервисов. Это возможно благодаря отделению фронта от основной системы, который связывается с ней через интеграционный (API) интерфейс. Также использование этого архитектурного шаблона позволяет строить омниканальные коммуникации и создавать множество пользовательских интерфейсов на едином бэкенд-решении, быстро запускать и тестировать новые каналы коммуникаций независимо от технологий и доработок backend, что существенно сокращают time2market.
Монолит или микросервисная архитектура. Выбирая между подходами к построению архитектуры, необходимо взвесить все плюсы и минусы того или иного подхода. Выбор монолитного решения оправдан, если:
- Бизнес не ожидает существенных изменений в решении на протяжении срока его эксплуатации.
- Решение нацелено на какой-то операционный процесс или на внутреннего лояльного клиента.
- К решению не предъявляются требования по высокой доступности сервисов, высокой скорости работы и способности к дешевому и гибкому масштабированию.
Однако, если бизнес нацелен на внешнего клиента, потребности и потребительское поведение которого имеют склонность к изменениям, и есть необходимость постоянно проверять бизнес и UX-гипотезы, менять продукт под потребности рынка, плюс к продукту предъявляются требования по высокой доступности сервисов, производительности и масштабируемости, то лучший выбор в этом случае – микросервисная архитектура. Причем если ранее серьезным аргументом при принятии решения была цена реализации микросервисных решений, то современные инструменты CI/CD и облачная инфраструктура практически свели эту разницу на нет.
Технологический стек. Значительное число e-commerce решений для малого и среднего бизнеса разрабатывается на языке PHP. Он удобен для быстрой реализации веб-порталов, но у этого языка есть ряд архитектурных ограничений, которые при высокой нагрузке и увеличенном трафике приводят к снижению скорости обработки. А также этот язык является интерпретируемым, что требует высокой культуры процессов разработки и внимательного подхода к качеству технологических решений, так как интерпретируемые языки по своей сути менее защищены от накопления технического долга и кратного роста стоимости поддержки и развития с течением времени. Поэтому если бизнесом предъявляются к решению высокие требования по производительности, масштабированию и качеству, то стоит обратить внимание на стек языка Java. Этот язык более требователен к чистоте кода и инженерной культуре в целом. А современные инструменты CI/CD удешевили использование этого стека при сохранении всех его преимуществ, что открыло новые возможности не только в enterprise, но и для среднего бизнеса. Другое решение – язык Go, из-за его относительной простоты на нем быстро и легко разрабатывать, что обеспечивает быстрый time2market при сохранении преимуществ компилируемого языка.
Обе технологии неограниченно масштабируются, работают под большими нагрузками без потери скорости и обеспечивают лучшую отказоустойчивость. Важно, что это также более надежная защита информации. Например, SQL-инъекции невозможны в Java стеке как класс, как и большинство других популярных способов похитить персональные и коммерческие данные.
Ниже приведена сравнительная таблица популярных на рынке решений с указанием наиболее важных параметров. Мы также добавили к сравнению собственную разработку – DC Commerce, российское микросервисное headless-решение нового поколения для крупных ритейлеров, которое импортозамещает платформы иностранных производителей – SAP Hybris, Magento (Adobe Commerce) и Oracle ATG Commerce.
Данные собраны из открытых источников и подготовлены компанией Digital Chief.
Команда специалистов. По данным сервиса DevJobsScanner за 2023 год, Java входит в топ-3 востребованных языков программирования. PHP также вошел в первую десятку. И специалистов, владеющих этими языками программирования, на рынке достаточно. Но общее количество резюме и открытых вакансий на hh.ru говорит о том, что Java-специалистов больше и спрос на них продолжает превышать предложения рынка (количество соискателей). Поэтому и стоят они ненамного, но дороже PHP. Объясняется это тем, что большинство высоконагруженных систем в индустриях, где превалирует крупный бизнес, банки, телеком и финтех, используют преимущественно Java-стек. Однако за последние несколько лет разница в уровне компенсации этих специалистов почти сравнялась. Что касается языка Go: он считается сравнительно простым, но таких разработчиков на рынке пока очень мало, поэтому платить им приходится еще больше.
В рамках общей стоимости необходимо учитывать не только текущий уровень оплаты труда этих сотрудников, но и рост компенсации в будущем, чтобы удержать их в штате в условиях большой конкуренции. Сейчас стоит закладывать как минимум 20% в год (15% из которых инфляция) на рост зарплат этих специалистов.
Модель поставки ПО. Будет платформа развернута в облаке или у вас на сервере, либо вы выберете гибридную модель. Если решение с открытым исходным кодом: сколько будут стоить работы по его развертыванию и поддержке, сколько на рынке есть подрядчиков с достаточной экспертизой для таких работ? У закрытого ПО бывают различные форматы лицензий: на количество аккаунтов, на объем занятого дискового пространства, на количество часов в системе, на конкретную функциональность и т.д. От модели поставки зависит общая стоимость владения решением.
Возможности интеграции. Многие относительно старые монолиты потребуют доработок для взаимодействия с более современными платформами, используемыми внутри бизнеса. Здесь речь идет уже об актуальности интерфейсов (API) конкретного решения. Это главный параметр, на который надо обращать внимание при выборе микросервисной архитектуры, поскольку вся ее работа строится на API․
Зависимость от вендора: открытый или закрытый код. Закрытый код не позволяет бизнесу самостоятельно дорабатывать ядро системы и, по сути, создает зависимость от поставщика. За всеми дополнительными решениями придется обращаться к производителю или к авторизованному партнеру. Для максимальной независимости от вендора бизнес вынужден развивать собственную экспертизу, чтобы поддерживать решения с закрытым кодом.
Open Source решения – главный современный тренд у крупного бизнеса, особенно на российском рынке, откуда ушли западные монолиты – SAP и Oracle. Открытый код обеспечивает независимость от поставщика решения. Систему можно поддерживать и развивать силами сравнительно небольшой команды. Минус открытого кода – отсутствие гарантированной поддержки и авторизованных партнеров, которые могли бы поставлять обновление кода по графику, также разработка дополнений силами инхаус-команды может занимать значительное время.
Техническая поддержка: как, кем оказывается и что в нее входит. Как часто выходят новые релизы, какие есть варианты сервисной поддержки, что должно быть прописано в SLA. Поддержка может быть как 24/7 с реакцией в течение 30 минут, так и только в рабочее время, но в ответ на заявку по электронной почте со скоростью решения в несколько дней. Этот параметр зависит от потребностей бизнеса и влияет на общую стоимость владения.
Статус решения в РФ. Тренд на импортозамещение и работа с госструктурами делают вопрос включения в реестр российского ПО краеугольным. С уходом западных вендоров на рынке появились альтернативные отечественные e-commerce решения, большинство из которых одобрено реестром.
заявка на сотрудничество
Хотите обсудить возможности по внедрению ecom-платформы?
Или получить консультацию с оценкой и анализом текущего технологического ландшафта вашего бизнеса?