Разработка e-commerce-платформ на заказ

Когда запускают интернет-магазин, первым делом спрашивают, на какой платформе его строить. Важнее другой вопрос: умещаются ли ваши бизнес-правила в готовую платформу. Цена может зависеть от клиента, дилера или объема заказа. Остатки могут храниться на нескольких складах и в ERP. На вашем собственном маркетплейсе могут продавать другие продавцы. В каждом из этих случаев границы платформы становятся границами вашего бизнеса. Для таких задач мы разрабатываем индивидуальное ПО для электронной коммерции. Оно работает на вашем коде, ваших данных и вашей инфраструктуре.

Что такое индивидуальное ПО для электронной коммерции

В индивидуальном решении магазин, панель управления и бизнес-правила за ними пишутся с нуля под ваши задачи. Репозиторий кода находится в вашем аккаунте. От готовой платформы такое решение отличается тремя вещами. Первая вещь: код. Логика корзины, акций и цен принадлежит вам. Чтобы изменить правило, не нужно ждать разрешения платформы. Вторая вещь: данные. Записи о товарах, клиентах и заказах лежат в вашей базе, и вы можете выгрузить их в любой момент. Третья вещь: инфраструктура. Сервер, база данных и домен работают в аккаунтах, оформленных на вас. Где размещать систему, как делать резервные копии и как масштабировать, решаете вы.

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

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

Готовая платформа или индивидуальная разработка?

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

• Цена рассчитывается по дилеру, группе клиентов, объему заказа или договору. Такие правила не помещаются в таблицу, для них нужен алгоритм.
• Остатки хранятся на нескольких складах и в ERP. Магазин должен обмениваться данными с этими системами мгновенно и в обе стороны.
• Кроме магазина нужен дилерский портал, кабинет поставщика или маркетплейс, где товары размещают другие продавцы.
• Данные о товарах и заказах должны храниться на вашей инфраструктуре или строиться по вашей модели данных.
• Размер каталога, нагрузка в период акций или ваши рабочие процессы выходят за возможности готовой платформы.

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

Состав работ по бизнес-моделям

Одна и та же основа подходит для трех бизнес-моделей. В каждой из них свои экраны и свои правила. Чаще всего проект строится вокруг одной модели, а вторую оставляют на следующий этап. Основа розничного магазина (B2C) такая: каталог, поиск и фильтры, корзина, оплата, отслеживание заказа, правила акций и купонов, личный кабинет клиента. Преимущество индивидуального решения обычно видно не на витрине, а за ней. Например, сложные правила акций, учет остатков для товаров с вариантами, особый расчет доставки или мгновенный обмен данными магазина с ERP.

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

B2B и дилерский портал

В дилерском портале покупает не случайный посетитель, а известный клиент. Вход возможен только после проверки личности. Цены зависят от дилера, группы дилеров или договора. Такие условия, как минимальный заказ, кредитный лимит и срок оплаты, учитываются прямо в корзине. Экраны быстрого и повторного заказа экономят время дилера. Запрос коммерческого предложения и согласование тоже могут быть частью этой модели. На готовой платформе большинство этих правил либо временно решают плагинами, либо не могут выполнить совсем. Если заказ дилера записывается обратно в ERP, один и тот же заказ не приходится вводить дважды.

Программное обеспечение для маркетплейса

В маркетплейсе продавцы сами добавляют свои товары. Вы управляете заказом, оплатой и комиссией. В систему входят кабинет продавца, одобрение товаров, остатки и цены по каждому продавцу, разделение заказа между продавцами, расчет комиссии и учет выплат продавцам. Кабинет поставщика, процесс одобрения и видимость остатков по нескольким складам мы собрали на единой модели данных для платформы продажи запчастей, рассчитанной на рынок США.

Интеграции и бизнес-правила

Система электронной коммерции не работает сама по себе. Основная часть работы состоит в обмене данными с соседними системами. Чаще всего мы делаем такие интеграции:

• ERP и бухгалтерия: заранее записываем, в какой системе возникают данные о товарах, ценах, остатках и контрагентах, и какая система главнее при расхождении.
• Склад и остатки (WMS): остатки по нескольким складам, резервирование и статус отгрузки.
• Маркетплейсы: передача товаров, остатков и цен на внешние маркетплейсы и получение заказов обратно.
• Оплата: выбор провайдера, рассрочка, возвраты и сверка платежей.
• Доставка: расчет стоимости, создание этикеток и передача клиенту данных для отслеживания.

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

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

От чего зависит стоимость?

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

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

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

Процесс и передача проекта

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

1. Исследование: фиксируем бизнес-модель, действующие системы, правила и приоритеты. В конце вы получаете письменное предложение.
2. Проектирование: на ваше согласование выносим модель данных, сценарии экранов и схему работы интеграций.
3. Разработка: результаты сдаются короткими циклами. В каждом цикле вы видите работающую версию.
4. Интеграции и перенос данных: подключаем внешние системы, переносим данные старого магазина и проверяем их.
5. Тестирование и запуск: проверяем высокую нагрузку, сценарии оплаты и возврата. Запуск проходит с планом отката.
6. После запуска: мониторинг и исправления в первый период.

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