Полтора года работы с sap hybris: полет нормальный. самое важное, что вам надо знать о разработке на ecommerce-платформах

Posted on by riasevastopol

Так оказалось, что последние полтора года я хорошо тружусь с SAP hybris. В Российской Федерации к eCommerce-платформам отмечается громадной интерес, и я решил данной статьей на базе моего опыта поведать легко и доступно об данной теме.

На сегодня все веб-магазины в Российской Федерации на SAP hybris сделаны нами.

Всю разработку ведем в Москве, без привлечения западных партнеров. Программиста на SAP hybris мы готовим за два месяца «с нуля» (ну не с нуля как минимум ему необходимо знать стек Java/J2EE/Spring). И до сих пор мы не встретили задачи, каковые «мы пока не знаем, как делать». Ни документации, ни дистрибутивов в свободном доступе нет, исходя из этого знания передаются по крупицам, а сама тема окружена ореолом тайны.

Самое ответственное о eСommerce-платформах

Фундамент. Для любого сложного ПО необходимо подготовить «фундамент», что потом сделает разработку управляемой, а всю совокупность обозримой и понятной для архитектора. Данный фундамент представляет собой «многослойный пирог» из универсальных, стандартных и прекрасно зарекомендовавших себя разработок и продуктов. Верный выбор этого комплекта во многом определяет развитие совокупности на ближайшие годы.

Примеры составляющих для того чтобы «пирога» — ORM, CMS, PCM, Search Engine, из конкретных разработок — Hadoop, Apache ServiceMix, NodeJS и другие.Полтора года работы с sap hybris: полет нормальный. самое важное, что вам надо знать о разработке на ecommerce-платформах Комплект этих разработок обычно определяется опытом команды разработчиков, а не только и не столько потребностями бизнеса, исходя из этого довольно часто возможно встретить совокупности на Scala,Erlang либо Haskell. В eCommerce-платформах часто видится таковой зоопарк разработок — Java, C++, Perl, C#.

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

Так, eCommerce-платформа представляет собой органичный, подготовленный, настроенный, отлаженный, упакованный и документированный комплект таких разработок. Под многие обычные задачи в e-commerce вендором созданы готовые блоки, каковые требуют только маленькой «подгонки» под задачу, а кое-какие реализованы на абстрактном уровне и требуют «допиливания напильником». Чем органичнее переплетены между собой технологии, чем продуманнее архитектура, тем легче будет расширять ее под собственные задачи все ближайшие годы.

Напишем все сами? Само собой разумеется, возможно создать магазин и без промышленной платформы, собрав «пирог» самому (здравствуй, ENTER!). Вопрос в том, сколько это займет времени и удастся ли сохранить через год-два хорошую архитектуру, масштабируемость, производительность, безопасность, расширяемость, надежность, документированность. Хороший и редкий пример, в то время, когда это удалось для большого e-commerce — Amazon.com.

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

Нужна ли вам eCommerce-платформа? Обладателям вебмагазинов перед принятием ответа о платформе стоит поразмыслить о том, где им видится их бизнес через лет пять. В случае если в этом будущем имеется слова «мультирегиональность», «мультиязычность», «мультивалютность», «громадный ассортимент», «громадный траффик», «персонализация», «много складов», «много сотрудников в ходе», то уже сейчас необходимо искать платформу, поддерживающую все перечисленное.

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

Сроки. Нереально назвать кроме того среднее время, но возможно назвать минимальное по собственному опыту. У отечественной команды имеется успешный опыт, в то время, когда совокупность выведена в продакшн через 3 месяца по окончании подписания договора. Первый релиз в «продакшн» был через два месяца по окончании начала работ — каталог без возможности заказа товара.

Команда на таком проекте насчитывала шесть человек, включая меня. Имеется и другие примеры, где сроки и команда больше.

Для e-commerce срок проекта крайне важен. В случае если имеется возможность расширить команду, сократив сроки — это нужно делать (как говорил Ф.Брукс, так не всегда). До тех пор пока мы разрабатываем новый сайт, развитие существующего клиент останавливать ни при каких обстоятельствах не будет.

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

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

Как выбирать ecommerce-платформу?

Дабы не совершить ошибку с выбором eCommerce-платформы, стоит обратить внимание на:

  • западные успешные проекты. Из-за чего на западные? По причине того, что они существуют продолжительнее российских, и они в далеком прошлом прошли тот путь, по которому идет сейчас российский e-commerce.
  • число внедрений в Российской Федерации за 2-3 последних года. Многие платформы в мире взяли большой рейтинг вследствие того что они созданы весьма в далеком прошлом, и собрали за историю собственного существования большое количество внедрений. Другие показались сравнительно не так давно. Богатая история возможно показателем как хорошего накопленного опыта, так и громадного количества кода «из девяностых». Из-за чего в Российской Федерации? eCommerce в Российской Федерации резко отличается от западного.
  • «доступность» и открытость составляющих «пирог» разработок. Не хорошо, в то время, когда у клиента нет вторых альтернатив, чем обратиться к вендору либо партнеру за помощью запущенного сайта. Прекрасно, в то время, когда имеется быть выбор — собрать и научить собственную команду либо трудиться с умелым партнером.
  • число специалистов и компаний на рынке. Оценить потенциал, сколько их будет с учетом существующего темпа развития через год либо два.
  • частоту выпуска предположений вендором. В случае если платформа обновляется всего раз в год либо реже, необходимо задуматься, каков у нее приоритет среди других продуктов вендора.
  • стандартные механизмы интеграции. В случае если платформа имеет API, это весьма облегчает работу по интеграции.
  • стоимость и сложность масштабирования. Увеличьте все собственные цифры по объёму и траффику SKU раз в сто и оцените, сколько будут стоить лицензии, сколько необходимо будет серверов, и справится ли платформа с этим по большому счету. Будьте уверены, ну не в сто, но вдесятеро ваш бизнес возрастет по этим показателям лет через пять. В случае если нет таких амбиций, вам вряд ли нужна платформа)
  • уровень качества документации. Принципиально важно, дабы документация включала как блок для бизнес-пользователей, так и для программистов, отражала отличие в предположениях, была актуальной, полной, дешёвой и прекрасно структурированной.
  • рейтинги Gartner и Forrester. Эти компании являются признанными фаворитами, точке зрения которых на рынке доверяют.

Я бы не рекомендовал обращать большое количество внимания на:

  • Готовые модули. eCommerce в Российской Федерации такой разный и такой динамичный, что готовые модули больше головная боль, чем благо. Лучше искать готовые «фреймворки» под задачу + документированные прототипы ответа конкретных задач на них. К примеру, модуль интеграции с платежными совокупностями «в общем» с примером для одной ПС лучше, чем комплект разрозненных модулей интеграции с какими-нибудь конкретными платежными совокупностями.
  • Готовые дизайн-шаблоны. Внешний вид в большом e-commerce ни при каких обстоятельствах не есть расширением демо-магазинов, он постоянно заменяется новым, специфичным под клиента. Брать за базу стандартные визуальные шаблоны неизменно сложнее, неправильнее, да и продолжительнее, чем создавать их заново под конкретный дизайн и конкретные функциональные требования. Но таковой подход требует большего опыта, чем доработка готовых шаблонов.

Стремительный старт?

С одной стороны, применение платформы разрешает запустить магазин за считанные месяцы. Отечественный рекорд — полтора месяца на пилот 1Платформа (http://1platforma.ru).

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 либо внешнюю совокупность управления заказами.

Заключение

Само собой разумеется, сейчас на рынке мало умелых экспертов по eCommerce-платформам, но их число быстро растет последние годы. В отечественном проекте «1Платформа» (http://1platforma.ru) мы научили команду разработчиков со стороны Клиента как поддерживать и развивать проект на SAP hybris, и с того времени они собственными силами сделали многое самостоятельно. Делиться знаниями — верно.

Случайные статьи:

SAP Hybris Commerce Customer 360° View


Подборка похожих статей:

riasevastopol

More Posts