«Да что тут делать? Три таблички»: как запустить бэкофис маркетплейса на бюджет стартапа

Нет, в итоге не три, и даже не тридцать. В финале получилось порядка 50 таблиц в базе данных, свой API, дополнительный B2B-портал и полная автоматизация обработки заказа. Делюсь нашим опытом кастомной разработки бэкофиса для платформы стриминг-шопинга. Рассказываю, на чем можно сэкономить, реально ли запилить продукт в продукте, как вырулить с автоматизацией доставки, не поддаться «чайка-менеджменту» и эффективно перестроить процесс без потери качества, если вы работаете в режиме стартапа.

Сразу оговорюсь, что стартап не мой. Нас пригласили в проект как команду разработки на аутсорсе. Началось все с того, что заказчику понадобилась внутренняя система управления заказами и остатками в онлайн-платформе для шоппинга во время онлайн-стримов. «Да что тут делать? Всего три таблички» – на этой фразе я согласился войти в проект. Селлеры, товары и заказы – из этих групп и должны были сложится три таблицы в базе данных по изначальной задумке. Итоговый «центр управления полетом» – бэкофис маркетплейса, включал 50 таблиц в базе данных и занял 500+ дней интенсивной работы с небольшими перерывами на кофе.

Чтобы этот «космолёт полетел», а сотрудники маркетплейса получали все необходимые для работы данные, нужно было разработать архитектуру системы с учетом мельчайших нюансов, автоматизировать обработку заказов и внедрить интеграции как минимум с 9 внешними и внутренними сервисами и веб-приложениями. Небольшая часть из того, что было необходимо встроить в бэкофис, интегрировалась «из коробки» вместе с amoCRM, которую мы тоже настроили.

Итого мы интегрировали с бэкофисом:

• отдельный выделенный колл-центр

• СберЛогистику (ex. Shiptor)

• Boxberry
• CloudPayments
  
• amoCRM
  
• sms.ru
  
• колл-центр
  
• отдельный B2B-портал для селлеров
  

• само приложение для покупателей на стримах

• еще планировалось разработать интеграции с Яндекс Доставкой и Почтой России, но это в итоге не пошло в продакшн.

Так выглядела верхнеуровневая схема процессов и технологий бэкофиса

Часть 1: про лицо бэкофиса – админку

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

Чтобы удешевить производство админки, решили не делать кастомный фронтэнд, а использовать автогенерируемое решение Sonata Admin Bundle на Symfony. Если бы мы «пилили» отдельный фронт, это бы удорожало проект как минимум в 1,5 раза – ведь нам бы пришлось сперва спроектировать и отрисовать дизайн, а затем привлечь отдельного фронтэнд-разработчика и тестировщика. С тех пор мы практикуем такой бережный подход к разработке и ресурсам и на других проектах и считаем его полностью оправданным. Ведь сам функционал админки остается гибким, что позволяет делать прямо в ней большинство правок, лишь изменив настройки, а экономия выходит существенная.

Часть 2: про отдельный B2B-портал для селлеров и свой API

Еще одной технической «фишкой» с учетом минимального бюджета стал отдельный B2B-портал для селлеров. Это сервис уже не для внутренних, а для внешних пользователей маркетплейса. Если для внутренних сотрудников мы где-то могли пренебречь UI и UX-решениями, то для внешних пользователей это было непозволительно и мы разработали удобный интерфейс со своим функционалом. Опять же, если бы мы это делали в одной админке с внутренними пользователями, то пришлось бы «расшарить» и другую чувствительную для бизнеса информацию, на это мы пойти не могли.

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

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

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

Вот несколько примеров, как она выглядела внутри.

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

Часть 3: про доставку в оба конца и заборы

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

Доставка была нужна на двух этапах – и в моменте забора товара со склада селлера (у маркетплейса не было своих складов), и на доставке конечному покупателю. Возможность отправки посылок – по всей России. Здесь синхронизация доставки с бэкофисом происходила по API, необходимые уведомления направлялись по СМС (через сервис sms .ru) и email. Но не все так просто. С доставкой до покупателей все было более менее понятно. Проблема была в том, что в Shiptor заборы никак не были связаны с доставкой. Вообще формирование забора от селлера стало одной из самых зубодробительных историй в настройках логистики в бэкофисе.

Забор полностью генерировался в нашей системе и создавался заранее по каждому отдельному складу. На старте мы определились с тем, сколько дней заказы генерируются на забор, чтобы не возить заказы по одному. В системе создавалась новая сущность «забор». Затем мы контролировали его наполнение. Все это синхронизировалось с данными заказов, учитывалось добавление новых или отмена. Так в бэкофисе мы полностью автоматизировали забор по каждому отдельному складу по всей России. Мы возили заказы через внешнего контрагента, селлеров было много, доступ в личный кабинет бэкофиса к провайдеру логистики мы дать не могли. Поэтому нам нужно было сгенерировать акт приема-передачи, на основании которого передавались посылки, и отправить его селлеру. А если случалось так, что все отправления в заборе отменялись, забор автоматически отменялся в системе.

Возвраты – еще одна отдельная песня. Shiptor забирал все из разных точек, а возвращать мог только паллетой и только в одну. Таким образом заказы всех продавцов приезжали в офис, сортировались руками и только после этого создавалось задание на забор.

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

Часть 4: про предоплату и ужасы маркировки

Мы стартовали с постоплатой заказов, как с самым простым вариантом обработки платежей. По мере развития пора было задуматься о предоплате. Как раз незадолго до этого вышел закон, обязывающий продавцов маркировать некоторые товары – сигареты, обувь, одежду и белье, парфюмерию и другие. Таким образом в бэкофисе появлялся еще один дополнительный атрибут – «маркировка». В модуле предоплаты и без нее нужно было учитывать такие моменты как «Поступление денег от клиента» → «Комиссия за получение денег от Cloudpayments» → «Комиссия за доставку» → «Комиссия мерча». Теперь предстояло понять – на чьи плечи и в каких ситуациях – пост-/ или предоплата – ложится обязанность по погашению кода маркировки товара – на селлера или на маркетплейс, и когда правильно отправить данные о маркировке в бэкофис и внешние системы. Чтобы корректно разработать архитектуру учета, к работе подключились юристы и бухгалтерия маркетплейса. Мы вместе перелопатили практически всю имеющуюся на тот момент информацию и выдали удобное для бизнеса решение. Все шаги для корректного внедрения учета маркировки мы описали в статье здесь, будем рады, если она вам пригодится.

Часть 5: про интеграцию с колл-центром

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

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

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

Еще немного о нашей внутренней кухне. С самого старта мы работали так, как будто мы внутренняя продуктовая команда. Все процессы были полностью открыты и мы не только принимали задачи в разработку, но и сами активно предлагали разные варианты решений для новых бизнес-задач. Управление проектом велось в Jira на связке с Confluence, где мы фиксировали задачи и документацию. Таким образом «таски» по итогу встреч или, если это была наша инициатива, мы ставили себе сами. Я как PM упаковывал это сразу в Jira. А еще они прилетали от сотрудников маркетплейса в чатах – чем дальше от старта, тем, конечно, таких задач было больше. Иногда таких «задач-из-чата» поступало очень много, их поток был волнообразным и местами хаотичным. Такие задачи вылавливали в чате наш бизнес-аналитик и тестировщик.

В разгар проекта бывали дни, когда нам сбрасывали по несколько мега-дико-очень-срочных-самых-приоритетных задач одновременно, но на деле они оказывались не такими уж срочными и важными. Все это касалось и нового функционала, и багов. Сперва для работы с багами мы предлагали бизнесу внедрить свой портал поддержки или альтернативные инструменты, чтобы структурировать работу с ошибками и их фиксами. На что мы получили напоминание о том, что мы работаем в режиме стартапа – порталы тут не сработают. Поэтому мы придумали еще одно решение: чтобы клиенту было абсолютно понятно – над чем конкретно мы работаем в моменте, а Project-менеджер перестал дергаться от ежеминутных алёртов и не поддался атмосфере «чайка-менеджмента», мы перестроили процессы работы в команде и внедрили не совсем стандартный для разработки флоу работы с задачами. Баги и эпики мы вынесли на одну доску в Jira. Вот, как это выглядело.

Под любой запрос мы заводили задачу, определяясь на старте – это эпик (все, что касалось нового функционала) или баг (ошибка), присваивали ей открытый статус. Затем «таски» попадали на доску со статусом OPEN. Если это эпик, то PM смотрел на запрос, первично описывал и оценивал сложность реализации, согласовывал с бизнесом приоритет и отправлял в бэклог. После чего задача проходила стандартный флоу разработки. Если это был баг, то PM валидировал его (не дубль ли, точно ли это баг а не фича и т.д.). Далее отдавал в анализ для сбора фактуры по проблеме – воспроизвести, понять что сработало не так, есть ли ошибка в приложении, частота кейса и т.п. Аналитик/QA собирал фактуру и отправлял в приоритезацию – баг подтвержден, чтобы решить насколько срочно это нужно чинить. Здесь важно, что появилась дополнительная проверка на случай мисклика и закрытия бага – так он мог снова вернуться на анализ, а не просто потеряться. После того как баг оброс фактурой, он снова возвращался на PM и дальше уходил либо в бэклог, либо миновал его и летел в работу.

Этот подход с эпиками и багами в одном флоу мы часто используем на проектах и сейчас. Доступ к задачам есть и у бизнес-заказчика, и у нашей команды. Это позволяет вести единую среду для запросов и сделать процесс разработки абсолютно прозрачным, что очень влияет на доверие ко всей команде и позволяет не тратить время на долгое разъяснение. Отдельная фишка нашего подхода – двухуровневая система построения информации – на уровне эпиков мы подробно описываем задачу для «бизнеса» – как правило, это продакт-менеджеры или CPO партнеров, а уже ниже по задачам идут описания и документация для команды разработки.

По сути бэкофис стал для нас боевым крещением в разработке кастомной системы для e-commerce со множеством интеграций. За 7 лет работы, в течение которых внедрили 250+ сервисов, мы пришли к выводу: любому продукту в B2B всегда приходится интегрироваться. Очень часто бизнес-оунеры либо не воспринимают это всерьез, либо считают, что это «приключение на 20 минут – зашли и вышли». Буду рад вашему отклику в комментариях, разделяете ли вы эту точку зрения или серьезно инвестируете в интеграции.

Спасибо, что добрались до конца! Пишите комментарии, задавайте вопросы здесь или присылайте в TG или ЛС ссылки на 2 API с коротким пояснением. Посмотрим, что можно сделать, и расскажем о вариантах настройки.

Другие наши статьи на VC:

Как выпустить виджет для CRM на маркетплейс

Как мы реализовали программу лояльности на Telegram-боте

Как внедрить систему учета маркировок для интернет-магазина

Почему «без ТЗ результат ХЗ». Разбираем на примере CRM-систем

#b2b #b2bпродукт #growth #growthхаки #ecommerce #маркетплейс #бэкофис #доставка #api #интеграции #процессы

Изображения в статье – скриншоты из мультфильма «Рик и Морти»