Так получилось, что последние полтора года я плотно работаю с SAP hybris. В России к ecommerce-платформам наблюдается большой интерес, поэтому я решил данной статьей на основе своего опыта рассказать просто и доступно об этой теме.
Самое важное о eСommerce-платформах
Фундамент. Для создания любого сложного ПО нужно подготовить «фундамент», который впоследствии сделает разработку управляемой, а всю систему обозримой и понятной для архитектора. Этот фундамент представляет собой «многослойный пирог» из универсальных, стандартных и хорошо зарекомендовавших себя технологий и продуктов. Правильный выбор этого набора во многом определяет развитие системы на ближайшие годы. Примеры составляющих такого «пирога» — ORM, CMS, PCM, Search Engine, из конкретных технологий — Hadoop, Apache ServiceMix, NodeJS и другие. Набор этих технологий зачастую определяется опытом команды разработчиков, а не только и не столько потребностями бизнеса, поэтому часто можно встретить системы на Scala, Erlang или Haskell. В eCommerce-платформах нередко встречается такой зоопарк технологий — Java, C++, Perl, C#. Так выходит, когда вендор приобретает различные компоненты у третьих компаний или сами компании целиком. Нам с платформой повезло — там только Java.
Таким образом, eCommerce-платформа представляет собой органичный, подготовленный, настроенный, отлаженный, упакованный и документированный набор таких технологий. Под многие типичные задачи в e-commerce вендором разработаны готовые блоки, которые требуют лишь небольшой «подгонки» под задачу, а некоторые реализованы на абстрактном уровне и требуют «допиливания напильником». Чем органичнее переплетены между собой технологии, чем продуманнее архитектура, тем легче будет расширять ее под свои задачи все ближайшие годы.
Напишем все сами? Конечно, можно разработать магазин и без промышленной платформы, собрав «пирог» самому. Вопрос в том, сколько это займет времени и удастся ли сохранить через год-два хорошую архитектуру, масштабируемость, производительность, безопасность, расширяемость, надежность, документированность. Хороший и редкий пример, когда это удалось для крупного e-commerce — Amazon.com. Опыт говорит о том, что при сегодняшних требованиях к качеству, безопасности, функциональности и темпам развития писать все «с нуля» в итоге выходит очень дорого, долго и рискованно.
Нужна ли вам eCommerce-платформа? Владельцам интернет-магазинов перед принятием решения о платформе стоит подумать о том, где им видится их бизнес через лет пять. Если в этом будущем есть слова «мультирегиональность», «мультиязычность», «мультивалютность», «огромный ассортимент», «большой траффик», «персонализация», «сотни складов», «сотни сотрудников в процессе», то уже сегодня нужно искать платформу, поддерживающую все перечисленное.
При использовании платформы грандиозная задача по построению большого интернет-магазина становится вполне обозримой и управляемой. На передний план выходят особенности автоматизации бизнеса, интеграция с внутренними системами, специфичные бизнес-процессы, пользовательский интерфейс, особенности товаров и услуг. Стоимость разработки и внедрения складывается в существенной части из этих компонентов.
Сроки. Невозможно назвать даже среднее время, но можно назвать минимальное по собственному опыту. У нашей команды есть успешный опыт, когда система выведена в продакшн через 3 месяца после подписания контракта. Первый релиз в «продакшн» был через два месяца после начала работ — каталог без возможности заказа товара. Команда на таком проекте насчитывала шесть человек, включая меня. Есть и другие примеры, где команда и сроки больше.
Для e-commerce срок проекта очень важен. Если есть возможность увеличить команду, сократив сроки — это надо делать (как рассказывал Ф.Брукс, так не всегда). Пока мы разрабатываем новый сайт, развитие существующего заказчик останавливать никогда не будет. Поэтому каждый дополнительный месяц создает огромные риски того, что проект так и не будет запущен.
Стоимость. Грубо оценить стоимость такого проекта можно, перемножив планируемую длительность проекта, средний размер команды и среднюю стоимость человеко-дня специалистов. Стоимость лицензий обычно ниже, чем альтернативная стоимость покупки, разработки и интеграции в единый комплекс сопоставимого по функциональности ПО.
Как выбирать ecommerce-платформу?
Чтобы не ошибиться с выбором eCommerce-платформы, стоит обратить внимание на
- западные успешные проекты. Почему на западные? Потому что они существуют дольше российских, и они давно прошли тот путь, по которому идет сегодня российский e-commerce.
- число внедрений в России за 2-3 последних года. Многие платформы в мире получили высокий рейтинг потому, что они разработаны очень давно, и собрали за историю своего существования много внедрений. Другие появились недавно. Богатая история может быть признаком как хорошего накопленного опыта, так и большого объема кода «из девяностых». Почему в России? eCommerce в России сильно отличается от западного.
- «открытость» и доступность составляющих «пирог» технологий. Плохо, когда у заказчика нет других альтернатив, чем обратиться к вендору или партнеру за поддержкой запущенного сайта. Хорошо, когда есть быть выбор — собрать и обучить свою команду или работать с опытным партнером.
- число компаний и специалистов на рынке. Оценить потенциал, сколько их будет с учетом существующего темпа развития через год или два.
- частоту выпуска версий вендором. Если платформа обновляется всего раз в год или реже, стоит задуматься, каков у нее приоритет среди прочих продуктов вендора.
- стандартные механизмы интеграции. Если платформа имеет API, это очень облегчает работу по интеграции.
- сложность и стоимость масштабирования. Увеличьте все свои цифры по траффику и объему SKU раз в сто и оцените, сколько будут стоить лицензии, сколько нужно будет серверов, и справится ли платформа с этим вообще. Будьте уверены, ну не в сто, но в десять раз ваш бизнес должен вырасти по этим показателям лет через пять. Если нет таких амбиций, вам вряд ли нужна платформа)
- качество документации. Важно, чтобы документация включала как блок для бизнес-пользователей, так и для программистов, отражала разницу в версиях, была актуальной, полной, доступной и хорошо структурированной.
- рейтинги Gartner и Forrester. Эти компании являются признанными лидерами, мнению которых на рынке доверяют.
Я бы не советовал обращать много внимания на:
- Готовые модули. eCommerce в России настолько разный и настолько динамичный, что готовые модули больше головная боль, чем благо. Лучше искать готовые «фреймворки» под задачу + документированные прототипы решения конкретных задач на них. Например, модуль интеграции с платежными системами «в общем» с примером для одной ПС лучше, чем набор разрозненных модулей интеграции с какими-нибудь конкретными платежными системами.
- Готовые дизайн-шаблоны. Внешний вид в крупном e-commerce никогда не является расширением демо-магазинов, он всегда заменяется новым, специфичным под клиента. Брать за основу стандартные визуальные шаблоны всегда сложнее, неправильнее, да и дольше, чем создавать их заново под конкретный дизайн и конкретные функциональные требования. Но такой подход требует большего опыта, чем доработка готовых шаблонов.
Быстрый старт?
С одной стороны, использование платформы позволяет запустить магазин за считанные месяцы. C другой стороны, ни одна e-commerce-платформа не представляет собой готовый шаблон магазина, который сегодня купили, галочки в «админке» покликали и — запустили. То есть, технически это можно, конечно… Но в 100% случаев нужно допрограммирование под особенности — как внутренние информационные системы клиента, его процессы, нашего рынка, нашего пользовательского опыта, автоматизацию миграции данных и т.д.
Что представляет собой проект на ecommerce-платформе?
eCommerce-система включает в себя взаимодействие с покупателем по разным каналам — от колл-центра и веб-витрины до мобильного приложения и киосков.
Управление мастер-данными e-commerce. Сюда входит набор ПО по управлению мастер-данными интернет-коммерции — контентом, акциями и другими важными объектами e-commerce. Некоторые компоненты этого блока, как управление товарами, могут использоваться вне интернет-магазина как самостоятельная система. Проект по внедрению платформы включает настройку и расширение этого ПО.
Веб-витрина. С одной стороны, интернет-магазин — это пусть и большой, но веб-сайт. Дизайн-концепция, дизайн-макеты, бэкофис, фронтэнд — HTML-верстка, javascript-автоматизация, обмен данными с внутренними системами, информационное наполнение — типичные этапы, привычные для любого проекта веб-сайта.
Бизнес-процессы и документооборот. С другой стороны, это бизнес-процессы по автоматизации интернет-торговли. Сюда входит и работа с каталогом товаров, и маркетинг, склады, логистика и колл-центр. Когда в процессе продажи товара участвует много людей, важно обеспечить прозрачную и надежную систему документооборота.
Прочие каналы взаимодействия с клиентом. Мобильное приложение поставляется в виде рабочего прототипа и набора API. Версия для киосков и версия для мобильных устройств представляют собой дополнительные версии веб-витрины, использующие почти тот же функционал и те же данные, что и основной веб-сайт, но в другой «обертке».
Специальная функциональность. Сюда же входят такие важные темы как возвраты, бракованный товар, частичная оплата, системы лояльности, расчет сроков, стоимости и возможности доставки, триггерные и массовые рассылки.
Поиск. В области электронной коммерции поиск — один из важнейших компонентов системы, так как прямо влияет на конверсию посетителей в покупателей.
Архитектура
Каждая из вышеперечисленных тем имеет в платформе «заготовку» разной степени проработанности, это может быть готовый к подключению модуль, а может быть «полуфабрикат». У готовых модулей есть минус в том, что их не всегда можно легко изменить под специфичные требования, да и изучать их сложнее — неясность и непрозрачность логики требует большего времени на изучение и прототипирование. У «полуфабрикатов» этой проблемы нет, но они требуют большего времени на настройку и доработку. Зато у них есть плюс в том, что система получается стройнее, безопаснее и надежнее за счет более цельной и масштабируемой архитектуры.
На основе одного «полуфабриката» можно сделать сотни различных вариантов реализации функционала, и только один из них может быть реализован в демо-магазине, который презентуют клиентам на первых встречах. Именно поэтому нельзя называть увиденное в демо-магазине «best practice», так как это всего лишь одна из возможных реализаций очень гибкого механизма.
Профессионализм архитектора eCommerce-системы заключается в том числе и в понимании этой гибкости, ограничений и возможностей. Мы почти никогда не говорим клиентам «нет, это сделать нельзя», потому что на современных ecommerce-системах можно сделать абсолютно всё той или иной ценой.
В состав eCommerce-платформы входит набор инструментов бэкофиса, автоматизирующих работу специалистов, вовлеченных в процессы eCommerce со стороны интернет-магазина — операторов колл-центра, маркетолога, контент-менеджера, продукт-менеджера и других. Поскольку многие из этих компонентов часто дорабатываются под конкретные процессы, в идеале они должны быть реализованы на единой технологии, с едиными интерфейсами и подходами к расширению.
Крупные платформы изначально спроектированы на большие объемы данных, на сложные бизнес-процессы, на высокую посещаемость, производительность и доступность. Например, кластеризация и кэширование в них выполнены на промышленном уровне.
Основные принципы разработки
Платформа имеет тысячи мест, куда можно «вклиниться» программисту со своей логикой, переопределить или расширить стандартное поведение системы. Разработка интернет-магазина представляет собой проектирование, разработку и тестирование таких модулей отдельно и в составе платформы. Как видно, тут есть два граничных варианта — заменить всю бизнес-логику на свою или использовать поставляемую в дистрибутиве.
В разработке используются известные технологии типа JSP/Spring/Java, что упрощает подключение к проекту программистов без опыта с конкретной eCommerce-платформой.
Поиск
С точки зрения интернет-покупателя поиск — это получение товаров или страниц сайта в ответ на указанные им ключевые слова. Чем ближе результаты поиска к его запросу, тем выше вероятность, что он купит у вас, а не у конкурентов. Поэтому над улучшением поиска непрерывно работают все крупные интернет-магазины.
Можно написать поиск самим «с нуля». Так делает подавляющее большинство интернет-магазинов с маленьким ассортиментом и траффиком. Но с ростом товарной базы и траффика поиск работает медленнее, интернет-магазин теряет покупателей, и, начиная с какого-то момента, становится ясно, что нужно полностью переписывать механизм на более сложный или подключать внешний «поисковый движок» (search engine).
Упрощенно, «поисковый движок» — это специализированная база данных, которая укладывает информацию о товарах и страницах так, что ее потом можно вынимать быстро и часто, используя при надобности довольно сложные запросы. Эта возможность позволяет применять «поисковые движки» не только для поиска по ключевым словам, но и для поиска, например, по характеристикам товаров или для отображения списка товаров выбранной рубрики. Поиск с постепенным уточнением запроса через удобный интерфейс покупателя — must have для любого крупного магазина. Для «неплатформенных» магазинов эта функциональность — одно из самых узких мест с точки зрения производительности и гибкости.
Среди «поисковых движков» в области e-commerce пользуются уважением Apache SOLR, ElasticSearch, Endeca, Sphinx. Подключение к интернет-магазину поискового движка может быть достаточно трудоемкой процедурой, если все делать как следует. В e-commerce-платформах обычно этот вопрос решен с одним из продуктов в версии «из коробки».
Например, во всех наших проектах используется Apache SOLR, и все листинги товаров также построены на запросах к нему. Такой подход позволяет иметь громадный запас по производительности.
Управление товарами
Каталог товаров — основное, с чего начинается интернет-магазин. Данные о товарах могут быть использованы, например, на ценниках в магазине или в печатном каталоге. Хорошей практикой является хранение т.н. «обогащенных данных о товарах» — изображений, технических характеристик (в т.ч. динамических), приложенных файлов — в отдельной системе, специализированной базе знаний по товарам. Такие системы могут являться отдельным продуктом, а могут поставляться в составе платформ.
Общеупотребительное название для таких систем — PIM (Product Information management) или PCM (Product Content Management).
Прямого отношения к интернет-магазину эти системы не имеют, т.к. их назначение — автоматизация управления информацией о товарах и их группах. Если планируется отображать их на веб-сайте, то это уже дело системы управления контентом (CMS), о которой я расскажу в следующем разделе.
В типичный проект по разработке интернет-магазина на eCommerce-платформе входит настройка и внедрение PIM/PCM, а также интеграция с внутренними учетными системами. Обычно разработка каталога — это первое, с чего начинается проект.
Например, в интернет-магазине РИВ ГОШ часть товаров имеет единицу измерения «граммы», есть варианты по цвету и объему, товар может быть привязан к нескольким рубрикам из различных иерархий рубрик, часть из которых не являются навигационными. Товары могут быть сложно связаны друг с другом, а часть информации может подгружаться из различных источников автоматически.
Система управления контентом
За компоновку и отображение страниц отвечает система управления контентом. Это тоже обязательный компонент любой eCommerce-платформы, так как, как уже говорилось выше, интернет-магазин — это еще и просто большой сайт. Такие задачи, как размещение баннеров, добавление пункта меню, добавление страницы с информацией, персонализация отображения отдельных блоков и многие другие выполняются в CMS.
В eCommerce-платформу уже входят многие готовые компоненты («виджеты»), которые очень вероятно пригодятся в любом магазине, такие как «корзина», «листинг товаров», «карточка товара» и другие. Также с помощью CMS управляют и триггерными рассылками, и страницами мобильной версии.
В CMS входит также персонализация страниц и компонентов. Система будет по-разному компоновать страницы для разных пользователей, точно следуя логике. Для покупателя, поставившего бренду лайк в фейсбуке, при заходе на сайт будет отображен соответствующий баннер, главная страница будет брендирована, а в меню появится новый пункт.
В типичный проект по разработке интернет-магазина на eCommerce-платформе входит разработка, переработка или настройка перечисленных выше компонентов-виджетов.
Например, в проекте 1Платформа для компании Технониколь CMS выдает разные шаблоны страниц и компонентов-виджетов для мобильной версии / версии для десктопа, при этом функциональность страниц и компонентов идентична.
Фулфилмент и бизнес-процессы, связанные с заказом
Это самая eCommerce-часть платформы. После того, как заказ был оформлен и, возможно, оплачен покупателем, запускается цепочка его обработки. В каком-то смысле это документооборот: заказ может быть разбит на несколько, по каждому должны сформироваться поручения на конкретные склады, должны обрабатываться нештатные ситуации вида «ой, товара уже нет» или «заказ подозрительный — надо проверить перед отгрузкой».
Это самая «абстрактная» часть платформы, содержащая много того, что практически невозможно показать на демонстрации, т.к. без интеграции это работать не будет. Здесь как у айсберга — немного видимых пользовательских интерфейсов, но очень большая и массивная «подводная» часть.
В типичный проект по разработке интернет-магазина на eCommerce-платформе входит проектирование или изучение бизнес-процессов, настройка логики обработки заказа, интеграция с WMS, с платежными шлюзами, выгрузка заказа в ERP или внешнюю систему управления заказами.
Автор: raliev
