УДК 004.62

Общая архитектура микрозаказов для электронной коммерции

Шишкин Андрей Геннадьевич – технический директор Группы компаний «ИксКом» (ООО «М-Инвест»)

Аннотация: Современный рынок электронной коммерции все более тесно переплетает между собой всех участников рынка. Маркетплейсы, интернет-магазины, поставщики, перекупщики, дистрибьютеры, поставщики трафика – все взаимодействуют между собой в совершенно разных плоскостях. Один из видов взаимоотношений лежит в области маркетинга и затрагивает понятие покупки и продажи готовых заказов. В данных отношениях требуется провести прямую интеграцию (обмен) заказами между участниками отношений. Однако большое количество вариантов корпоративных систем учета заказов создает проблему при интеграциях. Самый сложный вариант, когда понятие «заказ» у разных систем имеет разную архитектуру, уровень детализации, вложенности и статусы. В данной статье автор разбирает проблематику обмена заказами и предлагает решение на основе архитектуры микрозаказов как промежуточное или комплексное решение.

Ключевые слова: электронная коммерция, интернет-магазин, корзина товаров, заказ товаров, CPA, маркетплейс.

Введение

Развитие рынка электронной коммерции во многом происходит эмпирическим путем, никто заранее не знает, как именно нужно строить систему каждого участника рынка. Это же справедливо и для потребителей (клиентов) – клиент не может сам сказать какую систему он хочет видеть, он лишь может оценить уже существующую систему продавца. Современные участники рынка должны с одной стороны позаботиться о простоте своих систем, чтобы новые клиенты, которые только начали делать первые шаги в онлайн покупках, не испугались и не запутались, и смогли совершить заказ, с другой стороны они должны развиваться в попытках удовлетворить запросы опытных клиентов и получить преимущество в конкурентной борьбе [1, 2].

Подобная «гонка» технологий привела к появлению маркетплейсов и схожих моделей, где клиент в рамках одного заказа может купить товар сразу от нескольких поставщиков, находящихся в разных уголках страны [3]. Подобные системы являются авангардом в современной электронной коммерции, однако подобная сложность выглядит избыточной для простого интернет-магазина, который продает товары только со своего склада.

Современный рынок требует современного маркетинга. Один из значимых каналов привлечения трафика (продаж) является CPA (cost per action), в некоторых сегментах рынка этот канал может генерировать десятки процентов от общего объёма продаж интернет-магазина [4]. В данном канале продаж есть разные варианты для “action”. В данной статье рассматривается только действие «оформление заказа». В зависимости от типа маркетингового сотрудничества, оформление заказа может быть как в системе покупателя трафика (легкий сценарий), так и во внешней для него системе (сложный сценарий).

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

Ключевая проблема текущих «стандартных» корзин – их моноархитектура [5]. Корзина и сам заказ – это единая сущность с описанием статусов, товаров, поставщиков, покупателей и т.п. Тут невозможно как-либо дробить заказ на микрозаказы, что часто требуется современным поставщикам трафика. Именно отсутствие понятия микрозаказ создает большое количество проблем.

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

Подробное описание проблематики

Микрозаказ – это самостоятельная часть заказа, обладающая всеми признаками заказа. Иными словами – это полностью самостоятельный заказ, который сгруппирован с другими микрозаказами по некоторым признакам. Как правило такими признаками для группировки являются данные о заказчике. Остальные признаки могут быть как общими, так и раздельными.

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

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

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

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

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

Общая (моно) система заказа уже сейчас довольно сложная. Однако рынок диктует требование к ее усложнению. Все это неизбежно приводит к проблемам интеграций системы магазина с внешним партнером. Как описано выше, CPA канал рекламы может давать десятки процентов прибыли для магазина. И если поставщик CPA трафика работает по модели микрозаказов, то магазин без такой системы не сможет провести интеграцию, а значит теряет деньги, проигрывает конкурентную борьбу.

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

Самым распространенным вариантом полумеры является изначальное дробление входящего заказа по требованию поставщика заказа. Тогда в системе магазина создается нужное число заказов, визуально одинаковых, от одного заказчика. Формальное требование поставщика заказа выполнено, деньги получены. А далее начинаются другие проблемы с заказам, в основном по части доставки, гарантии, замены товара и т.п. Но это уже «привычные» проблемы для магазина, т.к. ровно такие же проблемы он получает в работе его текущей системы заказа с сайтов.

Т.о. магазины подстраиваются под рынок, но остаются в роли догоняющих.

Архитектура системы микрозаказов

Ключевая особенность системы микрозаказов – любой заказ можно разбить на микрозаказы в любой момент времени, при этом детализация дробления может быть до единиц товаров. Минимальным требованием микрозаказа является наличие одной единицы товара в количестве одной штуки, точнее допускаются и дробные величины единиц товара при условии, что это физически возможно к продаже (пример, весовой товар). При этом процесс дробления может быть обратим.

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

 

Рисунок 1. Схема создания заказа и распределения данных.

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

Детально описывать логические блоки состава заказа не имеет смысла, т.к. в общей практике эти данные известны и применяются для классической моноструктуры работы с заказами. Но в качестве пояснения следует раскрыть суть блока «оффер» – это описание товаров, работ, услуг, которые покупаются у конкретного поставщика, с конкретного склада, за конкретную цену. Т.е. это фиксация условий сделки для клиента.

Регистрация нового заказа. На входе рекомендуется установить модуль быстрой регистрации заказов. Его задача только в одном – присвоить заказу некий номер, данные заказа записать «как есть» в хранилище. Рекомендуется состав заказа записывать текстом в виде JSON. Сам заказ при этом получает статус «создан». Для клиента это еще не значит, что его заказ принят и будет исполнен.

Модуль регистрации позволяет обрабатывать все входящие заказы крайне быстро, без замедлений. Известный факт – любая задержка в процессе онлайн продажи крайне негативно влияет на конверсии сайта. Помимо этого, быстрая регистрация позволяет решить проблему DDoS-атак, которые нацелены на «заваливание» системы приема заказов с целью нанесения прямого убытка компании [6].

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

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

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

Управление может быть реализовано как внутренним интерфейсом к системе управления заказами, так и внешним (через API).

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

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

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

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

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

Для организации связи заказ → микрозаказ оба этих элемента должны находиться в одной таблице списка заказов. Разница лишь в том, что микрозаказ имеет ссылку на родителя, т.е. на заказ. А сам заказ такой ссылкой не обладает (это поле будет null). Теоретически, такая структура позволяет делать бесконечное число уровней дробления заказа. Однако автор статьи при проведении опытной разработки подобной системы для крупного российского представителя электронной коммерции не нашел ситуаций, когда подобное дробление имело бы смысл. Но это не значит, что такой подход не верный. Допускается наличие особых условий для некоторых ниш рынка, где многоуровневое дробление будет оправдано.

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

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

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

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

Также крайне рекомендуется модуль валидации сделать восприимчивым к каналу заказа. Т.е. по-разному настраиваться в зависимости от источника заказа. Это не значительная доработка в базе данных позволит кратно увеличить гибкость всей системы. Например, у компании два поставщика заказов: собственный сайт с управляемой формой создания заказа, и поставщик CPA заказав с минимальными данными о заказе (часто, в таких заказах все поля текстовые, требующие ручной проработки сотрудниками отдела продаж). Соответственно, валидация заказа для сайта и для CPA будет разная, процесс обработки заказа со стороны сотрудников магазина тоже разный, представление данных о заказе также отличаются. 

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

Опытная эксплуатация

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

Этап 1. Оценка текущей состояния ИТ платформы магазина. В общем и целом, важно определить, насколько текущая система работы с заказами плотно перевязана со всеми другими системами компании.

В общем плане тут можно выделить два крайних положения:

• Модуль работы с заказами является полностью самостоятельной системой и общается с другими системами компании через API;
• Система заказов является неотъемлемой частью всей системы магазина, элементы модульности отсутствую полностью.

Этап 2. Разработка алгоритма миграции старой архитектуры на новую. Если старый модуль в компании отделим от общей экосистемы, то алгоритм перехода строится на основе имеющегося API. Если модуль не отделим, то потребуется провести работы по написанию API.

Этап 3. Разработка модуля микрозаказов на основе согласованного API.

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

Этап 5. Опытная эксплуатация новой архитектуры, но в монорежиме.

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

Этап 7. Опытная эксплуатация всех систем в режиме монозаказа при условии, что все они теоретически готовы работать и с микрозаказами. Проведение закрытых тестирований работы микрозаказов.

Этап 8. Запуск работы микрозаказов, опытная эксплуатация.

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

Заключение

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

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

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

Список литературы

1. Бебрис А. О. Оценка эффективности деятельности интернет-магазинов // Производственный менеджмент: теория, методология, практика. – 2014. – № 1. – С. 61-64.
2. Таран В. Н., Туманов Е. В. Сравнение информационных систем интернет-магазинов, исследование их достоинств и недостатков // Дистанционные образовательные технологии. – 2019. – С. 320-325.
3. Кордина И. В., Хлебович Д. И. Маркетплейс как бизнес-модель электронного посредничества //Известия Байкальского государственного университета. – 2021. – Т. 31. – № 4. – С. 467-477.
4. Катаев А., Катаева Т., Названова И. Digital-маркетинг. – Litres, 2022.
5. Круглик Р. И. Создание корзины товаров для интернет-магазина // Постулат. – 2020. – № 1 январь. Противостояние.
6. Афанасьев А. DDOS: как происходят атаки, и как их отражать //Системный администратор. – 2013. – № 1-2. – С. 59-61.
7. Аблятипова Н. А., Кравцова А. А. Обмен и возврат товаров надлежащего качества, приобретенных дистанционным способом: правоприменение и воля законодателя // Legal Concept. – 2019. – Т. 18. – № 1. – С. 123-130.