sap commerce cloud что это
Кому рецепты для электронной коммерции? Для SAP Commerce и не только
Моё хобби ― автоматизация онлайн-ритейла. Уже много лет даже в свои выходные я не вылезаю из этого «болота». Да, наверное, это звучит дико и даже смешно. Как можно увлекаться таким скучным делом? — скажут одни. Что там увлекаться, это просто какая-то частная тема для уважающего себя архитектора ПО! — скажут другие.
Действительно, на первый взгляд, это, как говорится, недиссертабельная тема. Фактически, это сборная солянка из разных тем, тем или иным образом притащенных в e-commerce. И в итоге оказалась ровно тем, что я люблю: интеграция технологий.
И вот с 2016 я веду техноблог, hybrismart.com. Такая «хабра» в миниатюре, только на английском и с фокусом на близкую мне тему — разработку на SAP Commerce. У нас тут сформировалась небольшая компания из нескольких десятков тысяч авторов, но в блог пока что пишет только часть из них. Ну, хорошо, пишут пока немногие. Десяток. Но мы стараемся. В блоге уже накопилось под две сотни статей, преимущественно больших и очень больших на самые разные темы, тем или иным боком относящиеся к ecom. В существенной части это всё-таки персональный блог, поэтому отдуваюсь тут я, а не наша пиар-служба. Но это от души, правда.
Как легко догадаться из названия, hybrismart — про хайбрис (что это такое?). И почти все, кто его находит, знают о хайбрисе не понаслышке. Ну и наоборот: наверное, каждый разработчик на hybris хотя бы раз в блог заходил (конечно, не по доброй воли, нам гугл помогает!). Теперь вот и вы зашли. И чтобы вы там не потерялись, хочу провести небольшую экскурсию. Задавайте, пожалуйста, вопросы в самом конце.
ЖАЖДА ПОИСКА
Кто-то скажет, что где e-commerce, там шопинг карт, а где шопинг карт, там — e-commerce. Но эту шопинг-карт ещё нужно найти. Как и товары. И тут возникает тема, в которой число самодельных «велосипедов» зашкаливает: поиск по товарам.
Пожалуй, это самый «жирный» топик на моем блоге. В хайбрисе за поиск отвечает Apache Solr, один из двух крупных и повсеместно известных опенсорсных движков (вместе с ElasticSearch). Но как вы понимаете, специфики хайбриса в статьях про поиск — минимум. Просто потому, что у всех примерно одни и те же проблемы.
Вместе с Тимофеем Клюбиным мы сделали гигантский обзор текстового поиска на иероглифических языках, описали типичные сложности у компьютеров с этими значками и способы их решения в Solr. Также вы узнаете про различные культурные и языковые особенности и специфику оформления фасетного поиска в Японии и Китае.
Тимофей кроме хайбриса и всяких айтишних штук давно изучает японский. Мне хотелось бы написать тут «а я — китайский», но увы. У меня труд родился в процессе глубокого изучения темы, вызванного нуждой по работе и желанием раз и навсегда закрыть вопросы, которые меня мучали, а Тимофей просто занимался любимым делом.
Поиск на японском и китайском поднимает проблемы, о которых вы даже не догадывались. Например, всмотритесь в подсказки гугла по слову «とうきょうえ» (tōkyōe), на которое гугл дает «東京駅» (tōkyōeki) (станция Токио). В данном случае оба слова являются разным написанием одного и того же, и поисковая система это знает. У японцев свои знаки пунктуации, два алфавита, сложная система с числительными, важен контекст. Все это мы описываем в деталях.
А эта работа относится к фасетному поиску. Осторожно, там очень много букв, но есть удобное содержание с ссылками. Было бы концептуально сделать фасетный поиск по статье по фасетному поиску, но я вовремя себя остановил.
В статье предпринята попытка систематизировать знания и опыт в этой области и организовать эти знания в виде одной большой «простыни» с фактами, ссылками, и best practices. Наверное, она должна быть полезна тем, кто по роду работы связан с пользовательскими интерфейсами.
Несмотря на то, что фасеты — самая часто используемая концепция в екоммерс (после шоппинг карт), и всегда есть большой соблазн изобрести какое-нибудь колесо. Судя по тому, что мы видим на сайтах, очень многие этим пользуются, получая в результате много несостыковок и противоречий. Я постарался их собрать вместе с решениями, которые считаются общепринятыми.
Поскольку «поиски» сейчас пошли умные, и часто лучше пользователя знают, что он хотел найти, а устройства маленькие и неудобные, большое внимание уделяется Search Suggestions — способу сформулировать желаемый поисковый запрос за меньшее время, за минимальное число нажатий клавиш, кликов мыши или «тапов» по экрану.
В статье я делаю обзор темы, «лучших практик» и частых ошибок. Статья родилась, когда я проектировал систему умного автокомплита для одной крупной biotech-компании, делающего удобнее поиск по антителам и реагентам. «Умный автокомплит» предлагал завершение текущего слова в одно нажатие, опираясь на уже введённые слова, определённые правила сочетаемости и статистику запросов. Ближайший аналог из лингвистики — после ввода глагола с больше вероятностью идёет существительное, чем другой глагол.
Некоторые материалы представлены на блоге не в виде статей, а в виде видеороликов. Всего их там штук 40 наберется. К сожалению, такой формат пока ещё не прижился. Здесь я рассказываю про Search Analytics — механизм сбора и обработки статистики, имеющей отношение к действиям покупателей с вовлечением поиска по товарам. Я придумал этот механизм для большого продуктового магазина в Европе и перепроверил его ещё раз для той самой biotech-компании из предыдущего примера. Вкратце, идея сводится к тому, что действия покупателей могут много рассказать про то, как работает поиск, и где у него слабые места. Например, статистика показывает, что некоторые товары ищут часто, но кладут в корзину редко (высокая цена? Устаревшие модели?), а другие — кладут часто, но довольно плохо ищут (подсказки?), а за третьими готовы прокликивать несколько страниц результатов поиска (какие-то нерелевантные товары вылезают вперед?). В общем, это такой Google Analytics, но — для поиска.
Иметь свой блог удобно тем, что туда можно выгружать идеи и эксперименты и высвобождать мозги под что-нибудь более актуальное и новое. В этой статье я описал концепцию «многострочного поиска» для B2B-сайтов, которая когда-то в свое время была актуальна.
Идея в том, что часто удобно искать на сайте, скопипастив целую группу артикулов или названий товаров в поле для поиска, чем делать это одной строчкой за раз.
В этой статье я описываю поиск похожих товаров — по цвету или форме. Это довольно «классическая» тема, но на практике, по непонятной мне причине, редко реализуемая. Я сделал прототип и описал матчасть. Практически все статьи подобного характера сопровождаются видео, как работает прототип с SAP Commerce, и эта — не исключение. Для интеграции с Apache Solr я использовал Lire (https://github.com/dermotte/lire).
Если в прошлой статье мы искали похожие товары по цвету и размеру, то тут показываются похожие по чёрт знает чему. Система рассчитывает и упорядочивает товары по принципу похожести индексируемого контента — описаний товаров, названий, характеристик. Тем больше сходства, тем ближе товары будут в таких «кластерах» друг к другу. Для пользователя же мы можем вывести товары, находящиеся поблизости в таком «пространстве похожестей», которые, скорее всего, окажутся товарами-заменителями.
Здесь я тоже описываю интересный эксперимент и прототип: система выставляет фасеты самостоятельно, основываясь на введённом поисковом запросе. Например, если вы ищите что-то запросом «красное платьишко 39 размера», то вам надо показывать не товары, у которых все эти слова есть в описании или названии, а товары, отфильтрованные по тегу «красный», «платье» и «размер 39». Для русского языка понадобятся ещё танцы с бубнами, а с английским все работает уже сейчас. Внутри есть демка, показывающая разницу между тем, как работает дефолтный поиск и он же, но с моей логикой поверх. Называется, почувствуйте разницу. Однако, нужно отметить, что такой подход всё ещё блещет сайд-эффектами, и нужно очень тщательно настраивать систему, чтобы она удовлетворяла всех или почти всех.
Есть известная проблема в SOLR (и это не только с хайбрисом), что многословные синонимы работают очень криво. С однословными ещё кое-как работает, но тоже со своими сложностями. В блоге описано решение, позволяющее обойти эти проблемы и сделать поиск умнее. При отстутствии однозначности система перебирает разные варианты замен и выбирает наиболее «выигрышную» замену.
На блоге есть ещё пара десятков статей на тему поиска. А на этом прекрасном месте тема поиска уступает теме расчёта акций и скидок и прочей лояльности.
АКЦИИ ПО ПРАВИЛАМ
«Купи два пуховика по цене трёх и получи один в подарок!». Что только маркетологи не придумают, чтобы программисты не скучали. Делаешь полгода совершенный «движок» акций, который умеет вообще всё и ещё немножко, и тут приходит менеджер с очередной идеей, из-за которой нужно переписывать половину! В хайбрисе тоже было два поколения таких «движков». Разработчики решили не изобретать велосипед и использовали JBoss Drools, довольно мощную систему управления бизнес-правилами, которая интегрирована в хайбрис для темы акционных механик, темы узкой, но разнообразной в своей узости.
Если в двух словах, то Drools — это среда выполнения бизнес-правил. Механизм обрабатывает так называемые «факты» — входные данные, — и выдаёт результат в результате обработки правил и фактов. В хайбрисе для Drools сделали интерактивный редактор правил «в терминах e-commerce», а также представили API для расширения.
Если какое-то правило срабатывает, то накладывается скидка. Правила применяются к корзине. Мой эксперимент, в описанной статье, показывает, что правила могут применяться не к корзине, но к комбинации корзины и текущего товара. То есть ты ещё на кнопку «купить» не нажал, а уже видишь, какие райские сады и великолепные дворцы сейчас будут добавлены в корзину как подарок. Предполагается, что это должно сделать пользователя счастливее и увеличить продажи.
Так вот, этот самый Drools интегрирован в платформу. А она — монолит. Монолит — это когда весь код растёт из одного места. И вот когда пользователь тыкает иконочку на шопинг карт, на сервере миллионы маленьких гномиков начинают создавать контекст для Drools, потом заполнять его «фактами», куда входят товары, категории, свойства пользователя и всякое ещё разное, от чего может зависеть акция. И происходит это на той ноде в кластере, куда принесло пользователя лоад-балансером. И если там вдруг в это время перебои с процессорными ресурсами или памятью, то пользователь будет страдать. Затем, пользователю вручают скидку или подарок, а сервер всё это хозяйство подчищает. До следующего раза, когда оно опять начнёт создаваться. В статье я описываю свой эксперимент в вынесении Drools в отдельный кластер и вынос этапа этого конфигурирования Drools из запроса. Кроме того, что это повышает производительность, это ещё позволяет делать довольно сложные акции, где участвует, например, миллионы «фактов».
В этом примере я показываю, как можно устроить рекомендательную систему на основе правил, используя уже готовый механизм на основе Drools. В моём прототипе рекомендательной системы рекомендации можно создавать интерактивно, конструируя логику связей аксессуаров с товарами или похожих товаров между собой. Например, анчоусы к пиву, ментос — к коле, берёзовый сок — к буратино, мыло — к верёвке, розетку и фай-фай роутер — к чаю и кофе. Рекомендации — это всегда хорошо, когда они со смыслом.
Ну раз я уже построил этот кластер, я не мог его не домучить и построить на его основе штуку, которая обрабатывала бы события на лету, накладывая на них на том же лету правила. Мне удалось разобраться и подключить Drools Fusion + Drools Server последней версии к hybris. Эта штука правильно называется Complex Event Processing. Смысл в том, что если у вас есть поток каких-либо данных для обработки в реальном времени, Drools Fusion позволяет делать это быстро и гибко. Например, в случае e-commerceтаких данных много. Самые простые — это клики и переходы.
Я записал и публикнул демку, из которой понятно, как это работает. Логи выгружаются куда-то в хранилище, а оттуда попадают в drools fusion для обработки. На языке drools пишутся правила, которые вытягивают из логов какие-то новые знания. В моей демке это просто идентификация фотограф/не фотограф по характеру посещённых страниц и кликов. Например, пользователь уже просмотрел тучу моделей и мы делаем вывод, что он любит моделей. Или долго водит мышью по фотографии любимого штатива, из чего мы делаем вывод, что он любит не только модели, но и штативы. Результат правил возвращается обратно в хайбрис и как-нибудь там может использоваться. Баннер показать или цены чуть-чуть понизить на фототехнику.
Основная особенность всего этого, что обрабатывается поток событий в реальном времени. В моём примере — это нахождение как минимум пяти страниц одной тематической группы за последние 30 секунд для одного пользователя.
Второй важный пункт в том, что такая система очень масштабируема, ведь каждый сервер работает независимо. В то время ещё была жива встроенной в хайбрис персонализация. Её потом заменили на платный сервис. Она была жутко тормозная, и поэтому её мало кто использовал. Здесь же нагружаются серверы, софт которых не стоит ничего: он бесплатен. А в хайбрис потом пропихиваются уже готовые решения, которые нужно там тупо визуализировать.
Drools также можно использовать для автоматизации сложных форм, и в своём эксперименте я показываю, как это может быть достигнуто. В этом эксперименте я демонстрирую как можно реализовать многостраничную, многоэтапную форму, у которой состав и конфигурация полей и шагов меняется в зависимости от введённой информации в другие поля. Такая логика довольно сложно реализуется в стандартных подходах к формам, и её программирование значительно облегчается, когда для описания правил используется Drools.
Чтобы плавно закончить тему с Drools и начать тему про всякое разное в e-commerce и хайбрисе, я представлю ещё подробный обзор акционных механик.
Замечаете, почти все темы не совсем и про хайбрис. Там везде он каким-то боком есть, но в целом e-commerce— это не вещь в себе. Всё связано со всем.
Конечно, на сайте есть ещё десятки материалов, которые довольно сложно понять тем, кто вообще не разбирался с хайбрисом.
Например, в этой статье я описываю проблему объединения корзин после аутентификации. Это когда вы положили пятьдесят разных уточек в корзину, а потом авторизовались, а магазин туда подмешал выбранных с прошлого раза 50 зайчиков. Есть разные стратегии по тому, как разделять уточек и зайчиков в этом примере, и я их разбираю. Стратегии разбираю, не зайчиков.
Эта вот тема, наверное, полезна лишь для разбирающихся в хайбрисе. Привожу ее тут как пример статьи «для своих». Их меньшинство, но они занимают свою важную нишу.
В хайбрисе есть специальный формат для импорта и экспорта данных. Называется Impex и со стороны очень похож на обычный CSV. Там есть очень простой язык разметки, показывающий, что вот этот блок ниже — товары, а вот тот блок ещё — категории к ним. В целом, довольно удобно, но не тогда, когда у тебя двадцать почти одинаковых сайтов на разных языках, и каждый раз, когда добавляешь какой-нибудь интерфейсный компонент на все двадцать, нужно без ошибок скопипастить одно и то же двадцать раз и потом это поддерживать. У меня был такой проект, и я предложил решение с макросами на JSON, которые помогали создать импекс из импекса-с-макросами. Там не обычные макросы, а с циклами и параметрами.
Если вы ничего не поняли, то это нормально. У нас ещё и шутки есть, которые никто вне тусовки не понимает. Хотя они все грустные, не будем про это. У нас же серьёзная статья.
Я когда-то работал руководителем разработки в Chronopay, и с тех пор тема электронных платежей висела надо мной тёмной тяжёлой тучей, пока я её не приземлил вот в эту статью и освободил мозги под новые челенджи. Там собрано самое необходимое для понимания вопросов интеграции с платёжными шлюзами и сервисами, бест практисес и типичные недосмотры, которых нужно избегать (или использовать, если вы злой покупатель).
А ещё раньше, во времена зачёток и пейджеров, я работал дизайнером и верстальщиком (впрочем, в коломенском педуниверситете и пейджинговой компании Мобилтелеком я тоже работал. Да, я уже старый). Не тем верстальщиком, который HTML, а тем, который про книжки и журналы, а иногда даже православные газеты, телепрограммы и ноты. И, конечно, я не мог обойти стороной тему Postscript и PDF, которые пугают очень многих из-за туманных и плохо документированных внутренностей. В статье я показываю, что не так страшен чёрт, и делаю обзор инструментов под генерацию PDF.
В этой статье я описываю прототип авторизации по USB-ключикам, и последние (на момент статьи) продвиги в этом направлении на рынке, типа беспарольной авторизации, поддерживаемой браузерами. Удалось интегрировать с хайбрисом Yubikey, описываю как оно получалось (и получилось).
Очередной эксперимент: использование размеченных областей на карте Google для различных целей в e-commerce: поиска оптимального склада, поиска доступных магазинов для самовывоза или лучшего доставщика, а может и самого факта возможности продать товар или услугу покупателю из этой зоны.
Работает это так: покупатель вводит адрес, а система его определяет в одну или несколько крупных зон. Различные компоненты системы зависят уже от этих крупных зон, а не от мелких компонентов адреса, таких как почтовый индекс.
Заодно разобрался с разработкой на Google AppEngine. Дело в том, что определение многоугольника (зоны), в который входит точка на карте (где покупатель), для ситуации «много зон сложной формы» потенциально может быть довольно «тяжелой» вычислительной задачей. И если есть возможность, ее лучше сразу делать на кластере, который может легко масштабироваться, а лучше еще и сам. И вот этот кейс отличный для Google AppEngine, где задействован Google DataStore для хранения параметров многоугольников, и Google Memcache для хранения кэша.
В этих статьях я рассказываю про механизм умного кэширования частей страниц. Каждая из частей имеет составной ключ, говорящий о том, от чего она зависит. Например, для кэширования списка адресов доставки интернет-магазина (пример у меня есть в видео) составным ключом может быть идентификатор пользователя — тогда для разных пользователей будут использоваться разные кэши.
Механизм особо эффективен, если «тяжелый» функционал (в смысле использования памяти и процессора) вынесен из контроллеров страниц в компоненты, т.к. для кэширования контроллеров страниц описанная методика подходит не идеально.
Чтобы лучше понять идею, проще всего посмотреть на скриншоты шаблонов в середине статьи.
А тут много про миграцию данных: best practices, инструменты, архитектура моей самописной тулзы. Хоть тут и есть в названии слово «Hybris», но как и в прочих, эта статья не на 100% про хайбрис, не очень «гиковая», так что, надеюсь, будет понятна и интересна всем, кто знает, что такое «миграция данных в веб-проекте».
Также на блоге есть довольно подробно разобранные темы с чат-ботами (Facebook, Skype, кастом), вынесение хранения сессий за пределы хайбриса в отдельный сервис, разбор всего, что касается аутентификации и логин-форм, разбор особенностей реализации тревел-сервисов (заказ билетов, отели) — часть 1 и часть 2, а также собранные best practices по интеграции по product availability с внешними системами, и какие сложности этот процесс имеет, и много-много чего еще.
Какие еще темы вы бы хотели видеть разобранными подобным образом? По концепции блога они должны иметь отношение к ecommerce. Буду рад любым отзывам и предложениям.
Полтора года работы с 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-платформу?
Быстрый старт?
С одной стороны, использование платформы позволяет запустить магазин за считанные месяцы. 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 или внешнюю систему управления заказами.