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