История о том, как мы на 1С запилили продукт для интеграции с goods и не смогли остановиться28.01.2021 22:48

Разработка и запуск нового продукта — это всегда риск. Зайдет, не зайдет. Все зависит от возможностей (люди, деньги), компетенций, опыта, да и в целом понимания, зачем все это делать. Даже самая детально проработанная стратегия может в итоге провалиться. Главное понимать, в чем реальная польза продукт, тогда и процесс разработки пойдет увереннее.

С таким подходом мы пришли в 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 Маркет!