Разработка и запуск нового продукта - это всегда риск. Зайдет, не зайдет. Все зависит от возможностей (люди, деньги), компетенций, опыта, да и в целом понимания, зачем все это делать. Даже самая детально проработанная стратегия может в итоге провалиться. Главное понимать, в чем реальная польза продукта, тогда и процесс разработки пойдет увереннее.
С таким подходом мы пришли в 2019 к разработке готового решения для автоматизации торговли на маркетплейсах - RDV Маркет. Сделали его на бессмертной системе 1С. Ее мы знаем от и до, и убеждены, что для запуска нового проекта с точки зрения бизнеса - это наиболее подходящий вариант. Но об этом позже. Пока расскажем, как все начиналось.
Что было в самом начале
В 2017 году крупный ритейлер М. Видео стал одним из первых мерчантов, подключившихся к маркетплейсу goods.ru.
Первые версии API, непонимание процессов работы с маркетплейсами - так начинают большинство продавцов при подключении. С М. Видео все процессы отладки и подключения к маркетплейсу прошли успешно. Мы выдохнули, и началось масштабирование. Начались массовые подключения продавцов к goods.ru. А дальше началось самое интересное…
Коммерческий отдел поддавал газу и отправлял всем описание API и документацию, вдохновленные мерчанты выделяли программистов и постоянно повышали приоритеты задач. В результате эта активная бурная деятельность вылилась в бесконечную бизнес и IT - поддержку мерчантов. В чем была проблема? Просто никто не понимал, что такое маркетплейс, и как с ним работать.
Уровень IT и бизнес-специалистов продавцов был разным, каждый начинал изобретать велосипед. В режиме бесконечных консультаций команда работала практически шесть месяцев. Проводились корректировки процессов, пересматривали документацию, развивали API, личный кабинет и биллинговую систему - над этим трудились команда goods.ru и RDV. Нам постоянно нужно было объяснять мерчантам, что такое программа лояльности, кто за нее платит, как правильно отражать операции в учете и почему сумма заказов именно такая, а не другая. Мы объясняли все нюансы по работе с НДС и бухгалтерией. А также отвечали на сотни одинаковых вопросов, заданных под разным соусом.
Был ли тогда FAQ? Да. Но там было настолько много вопросов и ответов, что в детали особо никто не погружался, и надо было все равно объяснять.
Мы поняли, что так долго продолжаться не может, поэтому решили, что нужны изменения. Мы знали, что все работают в системах 1С, нам все процессы понятны как на стороне маркетплейса, так и на стороне продавца. Почему бы не разработать готовое решение, чтобы научить рынок организовывать процессы и вести учет работы с маркетплейсами?
Именно так начался наш путь. Не было планов, перспективы были непонятны, мы ничего не просчитывали, просто начали делать. :)
Почему 1С?
Мы вплотную занимались вопросом упаковки интеграции в отдельную автоматизированную систему. Работали над ней в 1С.
Во-первых, с типовыми конфигурациями работает большинство компаний. Таким образом, им будет проще начать работу с нашим решением, так как все будет происходить в их привычной "среде обитания". Все операции в общем окне 1С!
Во-вторых, система надежна. Ее уровня нагрузки достаточно для работы крупных компаний с количеством пользователей > 1000. В 1С можно спокойно систематизировать и масштабировать процессы под потребности компании.
Еще один важный момент помимо технической оснащенности, что 1С оперирует понятиями бизнес-объектов. Для выстраивания рабочих процессов с маркетплейсами это только в плюс.
Да, сам интерфейс привлекательным не назовешь. Не ждите от нас крутых скринов :) Тут 1С себе не изменяет. Но для нас в данном случае важнее всего все-таки возможности системы, ее адаптивность и гибкость.
Начали работу над RDV Маркет
У нас была четкая цель - получить решение, которое встраивается в 1С и автоматизирует процессы торговли на маркетплейсе. Все просто.
Что делали.
Шаг 1. Собрали обратную связь от продавцов goods.ru, кто на какой учетной системе работает. Для этого сделали рассылку по базе и узнали, что у большинства установлены:
1С:ERP;
1С:Комплексная автоматизация;
1С:Управление торговлей.
Была еще 1С УНФ (управление небольшой фирмой), но так как у нее мало функций под расширенную автоматизацию складских процессов, то пока что ее не рассматривали. Но, возможно, придем к ней позже.
Шаг 2. Начали прорабатывать функционал и roadmap первой версии продукта. За основу взяли спринтовый вариант управления разработкой. И где-то в течение первого полугодия выпустили первый релиз системы.
В функционал первой версии заложили автоматическую выгрузку товарного ассортимента в каталог (YML). Мы понимали, что при увеличении количества товаров ручная работа с выгрузкой - это неэффективно, трата времени.
В планах было запустить 2 версии продукта. Взяли идею 1С про ПРОФ И КОРП. Собственно, отличия были соответствующие - в КОРП был шире функционал.
Помимо автоматической выгрузки фидов в первом релизе программы для ПРОФ было реализовано автоподтверждение заказов. До этого продавец мог только вручную пройтись по всем заказам. Да, если у него их всего 10 штук, то здесь проблемы нет. Но чаще всего компании работают с большим количеством заказов, либо к этому стремятся.
Также в первой версии мы вплотную подошли к реализации функционала по автоматизации процесса комплектации заказов и учета отгрузки товаров.
Проблема задержки товаров на складе встречается довольно часто. При нарушении сроков отгрузки происходит блокировка аккаунта продавца, соответственно, тормозится процесс продаж, и компания несет убытки. Нам было важно сделать так, чтобы подобные ситуации сводились к минимуму, поэтому настроили единое место комплектации и отгрузки (APM кладовщика), тем самым сэкономили время на сбор и отправку заказов.
Над чем работали дальше, попутно закрывая баги
Мы понимали, что с решением будет работать именно продавец, а не разработчик или аналитик. Поэтому старались максимально упростить любые процессы. Должна была получиться удобная система с понятной структурой: создание и загрузка товарного фида, автоматический прием и подтверждение заказа, отправка на комплектацию и отгрузку, дальнейшая доставка товара до клиента и учет платежных операций и закрывающих документов.
Долго пилили финансовый модуль. Контроль взаиморасчетов изначально был довольно поверхностным, и много что приходилось делать руками. Мы хотели связать все финансовые операции по маркетплейсам, чтобы пользователь мог в одном месте видеть полную информацию по проведенным платежам, отправленным актам, а также за пару кликов вносить изменения.
Помимо этого большой пул работ был по разработке функционала обновления остатков.
Это было действительно проблемой. Разберем на простом примере. Магазин отправил на витрину 5 позиций, которые заказали покупатели. Но в это время в оффлайн уже было продано 2 товара из отправленных. Из-за того что на витрине маркетплейса никто не обновил остатки (в системе отображались только примерные данные), с маркетплейса было продано 5 товаров, но по факту в оформление ушло 3. То есть остальные заказы пришлось отменить. А с этим частить нельзя.
Рост отмен заказов отрицательно влияют на работу магазина, т.к. может произойти блокировка аккаунта (как и при сдвигах сроков отгрузки заказов). На сегодняшний день в текущей версии RDV Маркет реализовано автоматическое обновление остатков, что позволяет снижать или минимизировать % отмен, не доводя до критического момента.
В процессе работы над проектом пришла идея о возможности загрузки инфомоделей для товарного ассортимента (характеристики товаров). Хотели сформировать в 1С инфомодели для каждого маркетплейса по всем категориям, чтобы была возможность продавцам оперативно готовить свои каталоги, и передавать их с минимум ошибок (в идеале - без) в маркетплейс. Но здесь не все так просто с получением подобного контента, поэтому идея пока поставлена в план на будущее.
Не goods.ru единым: с кем работаем сейчас
Маркетплейс развивался, привлекая все больше продавцов. А мы двигались дальше - хотели запартнериться с другими популярными маркетплейсами. На рынке уже активно вели свою деятельность Wildberries, Ozon и Беру (сейчас это Яндекс.Маркет). Мы начали с последнего. Причем начали довольно дерзко уверенно, сразу разместив информацию об интеграции с Беру у себя на сайте. Хотя на тот момент формального партнерства еще не было. Но так как их API была в открытом доступе, мы успели все протестировать и настроить полноценную интеграцию с маркетплейсом.
Далее нас заметил Wildberries, который пришел к нам, когда продавал только по модели FBO (продажа со склада маркетплейса). Не так давно на WB случился прорыв - он заработал по схеме FBS (продажа со склада продавца). Здесь можно посмотреть, как мы настроили работу по новой схеме в 1С.
Чуть позже к нам присоединился Ozon - маркетплейс с непростой системой резервов. Площадка работает таким образом, что товар резервируется сразу, как только покупатель оформил заказ. Допустим, клиент неверно ввел данные карты, чтобы все исправить и оплатить покупку, ему дается 30 минут.
Но дело в том, что если продавец работает с несколькими каналами продаж, и, допустим, на складе не так много остатков, то при большом потоке заказов, менеджер может "зависший" заказ отправить другому покупателю. Произойдет отмена. Мы настроили систему так, что таких потерь можно избежать - история резервов сохраняется в режиме онлайн, они формируются до того, как создался заказ, и продавец не превышает порог отмен.
Кликайте сюда, чтобы разобраться подробнее, как работает RDV Маркет.
Что дальше? Идей много. Например, хотим сделать запуск решения по одному клику на кнопку, чтобы сократить количество шагов в настройках. А также смотрим в сторону реализации мобильного приложения и ребрендинга продукта.
В общем, работаем.
Готовы ответить на вопросы, подробнее рассказать про функционал - welcome в RDV Маркет!