Управленческий учет на маркетплейсах. Как мы планировали сделать за месяц, а делали восемь месяцев
TL; DR. Нужно понимать, что приносит деньги, и на что они уходят. Анализировать данные нужно регулярно, в идеале — каждый день. Для этого процесс нужно автоматизировать. Обсудим, как построить систему аналитики, какие данные потребуются, как их аггрегировать и какие выводы из них можно сделать. Как мы планировали уложиться в месяц, а потратили восемь, сколько это стоило, и как повлияло на финансовые показатели — под катом.
Сначала позволю себе небольшое теоретическое отступление.
Теоретическое отступление
Управленческий учет — это система, задача которой — максимально увеличить эффективность предприятия. То есть, можно придумать и реализовать что угодно, можно строить прогнозы, учитывать не подтвержденные документами операции, делать допущения. Эти данные предназначены для внутренних пользователей и не регламентируются. Это не то же самое, что финансовый, бухгалтерский или налоговый, где есть стандарты и регулирование, хоть они и тесно связаны, На начальных этапах управленческий учет может базироваться на бухгалтерском, но со временем данных бухгалтерсокого учета становится недостаточно.
Главное требование к управленческому учету — оперативность, точность не так важна. Знать, что рентабельность сегодня составляет примерно 12% важнее, чем узнать через месяц о том, что она составила 12.11% . Точность не стоит путать с достоверностью. Если система говорит, что рентабельность составляет примерно 16% , а через месяц выясняется, что она была 12.11% — это негодная система.
Думаем над требованиями к системе
Давайте пойдем с конца: что мы хотим получить? Потом будем разбираться, как это получить, и сколько это будет стоить.
- Нам нужна доска с аггрегированными значимыми показателями и их динамикой. Желательно — с индикаторами "стало хуже”, “стало лучше”, "не изменилось”
- Система должна уведомлять о проблемах. Сообщения должны быть релевантными: маркетолога стоит уведомлять о неэффективной рекламной кампании, закупщика — о том, что товар заканчивается. О критичных проблемах следует уведомлять активно: слать сообщения в мессенджеры, слать смс, звонить на телефон в крайнем случае.
- Нужно уметь соотносить все затраты, в том числе затраты на продвижение с конкретным заказом, если это возможно. Если нет — хотя бы с товаром. Тогда можно собрать адекватную модель для юнит-экономики.
- Система должна уметь работать с себестоимостью товаров, учитывать её в экономических показателях.
- Показатели должны быть представлены наглядно, график + таблица лучше таблицы, график + таблица + подсветка выявленных проблем + рекомендации, как их устранить — ещё лучше.
- Аггрегированые показатели должны давать возможность посмотреть детализацию вплоть самого атомарного уровня. В нашем случае чаще всего это транзакции, связанные с определенным заказом с детализацией, за что именно была списана или начислена эта сумма. Например, покупатель оплатил 1000 рублей, 120 рублей составила комиссия, 140 рублей — доставка со склада до ПВЗ, 50 рублей — услуги ПВЗ, 20 рублей — эквайринг, 600 рублей — закупочная цена, при этом у нас возникло обязательство оплатить НДС за доставку — 28 рублей, и за эквайринг — 2 рубля. Нам осталось 40 рублей, маржинальность продаж — 4% . С этих 40 рублей останется 32 после уплаты НДС.
- Нужно учитывать особенности площадок. Например, маркетплейс может предложить покупателю скидку за свой счет, а может не предложить. А потом поди разберись без этих данных, почему вчера товар продавался сотнями, а сегодня продажи на нуле.
- Нужно уметь прогнозировать поставки. Желательно — экономически обоснованно, а не просто когда заканчивается товар. Если товар продается в минус, не нужно его закупать, нужно сначала разобраться, почему. Если товар выпадал из наличия, нужно это учесть при подсчете оборачиваемости. Нужно уметь распределять поставку по складам, учитывая текущее наличие на складах, чтобы снизить затраты на логистику.
- Желательно уметь подсказывать перспективные ниши.
- Система должна уметь объединять данные с разных площадок.
- Оперативность — это важно. Данные должны быть максимально актуальными, насколько это позволяет площадка.
Так почему план был сделать за месяц, а ушло восемь?
Мы развиваем PIM — систему. И все чаще от клиентов стали появляться запросы на аналитику по маркетплейсам, но не внешнюю — уже есть качественные сервисы для внешней аналитики, а внутреннюю, задача которой — дать картину, что приносит деньги и на что они тратятся, чтобы принять меры и начать больше зарабатывать и меньше тратить.
Ну у нас и созрел план, сделаем графики по каждому товару, как менялась цена, как она влияла на продажи, сколько составила выручка, сколько было возвратов. Добавим фильтрацию, пару отчетов — и нормально будет.
В процессе поняли, что ненормально. Во первых, возникли технические трудности, в совсем дебри вдаваться не буду, но если кратко, то можно выделить такие пункты:
- У озона на один товар 5 идентификаторов: sku, fbo_sku, fbs_sku, product_id, order_id. В API они появляются в случайном порядке, склеить данные — тот еще квест. А когда кажется, что все уже работает, на следующий день опять появляются расхожтения в пару десятых процента.
- И на Озоне, и на Вайлдберриз мы встречались с ответом техподдержки “этот метод может возвращать некорректные результаты”. Естественно, прежде чем получить такой ответ, нужно написать вопрос, описать проблему. А перед этим нужно понять, что проблема существует, и она не заключается в кривизне наших собственных рук. И осложняется это тем, что метод может возвращать правдоподобные результаты, просто потом числа не сходятся.
- У API есть ограничения на количество запросов. С этими API работают и другие сервисы, нам на тестирование выделено 10%. С этим можно жить, но разработка идет медленнее.
- Фактическая работа API не соответствует документации. На первый взгляд этого не видно, и кажется, что все идет нормально, но со временем выясняется, например, что в документации описаны 33 типов расходов, а на практике их 52.
Во-вторых, мы поняли, что запрос пользователей — не такие графики, а система управленческого учета. Графики — один из инструментов, и просто графики мало кому нужны. По этим графикам можно сделать много разных выводов, но это смотреть и вникать нужно, и делать это регулярно. Естественно, у пользователей появляется запрос на автоматический анализ этих данных, чтобы если все хорошо — то и прекрасно, пусть так и дальше будет. А если что-то подозрительное на графике — то уведомление и объяснение, что не понравилось системе.
Поэтому концепция поменялась, и мы пришли к необходимости сначала доски с аггрегированными данными, потом к необходимости учитывать себестоимость — без нее картина не получалась полной и приносила мало пользы. Тогда же мы поняли, что и без PIM это может быть полезно, начали упрощать интерфейсы, чтобы этот модуль мог работать отдельно от PIM. Кстати, на сложность интерфейсов PIM до сих пор новые пользователи жалуются, так что оставить как есть мы не могли.
Отдельно стоит упомянуть задачу собрать все показатели товара в одном месте. Сложнее всего пришлось с рекламными компаниями и связанными с ними расходами. Сейчас все сходится, но в отладке мы провели не один день. Кстати, иногда по отчету маркетплейса показов бывает меньше, чем переходов. Этим решили пока пренебречь, на общую картину сильно не влияет. Главное — сошлась денежная часть. Кстати, а что значит сошлась? Под этим я подразумеваю, что если за определенный период мы соберем все расходы на продвижение, распределенные по товарам, то их сумма будет такой же, как сумма списаний на продвижение с баланса аккаунта. То есть, информация о деньгах нигде не потерялась.
Потом выяснили, что бывают разные системы налогооблажения. Точнее, мы это и так знали, просто думали, что нас это не сильно касается, мы даем суммы, которые вы заработали, суммы, которые вы потратили, раскладываем их на составляющие, подсвечиваем проблемные места. Но, как оказалось, не все так просто. Сумма налогов на общей системе налогооблажения зависит не только от итоговой суммы, но и от структуры затрат. Если, например, доставку выполнял не маркетплейс, а подрядчик на упрощенке, то у продавца на ОСН возникает обязательство учесть это в исходящем НДС. И это, пусть и не коренным образом, но меняет общую картину.
Потом столкнулись с тем, что наш интерфейс тормозит. На нашем аккаунте — работает сносно, у одного из клиентов 42 тысячи товаров и 60 тысяч заказов за месяц — и тут можно чаю заварить, пока страница грузится. Это, конечно, это было следствием функционала, можно выбирать любой период для анализа, почти как угодно фильтровать и сортировать результаты. На то, чтобы все ускорить без потери в функциональности, ушло еще 3 недели.
Еще осознали, что важны не просто графики и дашборды, а их анализ и проактивная позиция. Выявили проблему — нужно заявить о ней и предложить решение. Не просто на странице сервиса, а активно. Добавили телеграм-бота, сделали возможность настроить, о чем и кого следует уведомлять.
Еще поняли, что нужна мобильная версия. Мы заявляем, что нужно быстро реагировать на события, и даем для этого инструмент, но с десктопным интерфейсом этого инструмента работать с мобильного крайне сложно. Делать нечего, адаптировали большинство функций для мобильного. Не так чтобы прям вау, но пользоваться с телефона стало можно без страданий.
А потом в Вайлдберрис решили переделать API. Внезапно и без объявления войны. Точнее, официально дали месяц на то, чтобы все переделать все на новые API, потому что старые будут отключены. Фактически — некоторые старые методы уже не работают, некоторые новые — ещё не работают. С новыми вообще интересная ситуация, некоторые методы появились, просуществовали два дня в документации и исчезли без следа. Ну а что, могут себе позволить. За время, которое мы потратили на то, чтобы приспособиться к новому API, только я придумал больше трех сотен новых оскорблений. Впрочем, это коснулось не только нас, пострадали все, кто так или иначе с API взаимодействует.
Кажется, у нас получилось сделать так, чтобы все снова заработало. Думаю, в ближайшее время что-нибудь опять в API изменится, и мы опять будем материться и приспосабливаться, но сейчас оно с кучей костылей, но работает.
В общем, мы проделали колоссальную работу.
Сколько это стоило?
Грубо, это стоило 8 месяцев работы команды из четырех человек. При этом, у нас уже была инфраструктура для работы с маркетплейсами, была реализована синхронизация контента по API, управление пользователями, просмотр и фильтрация каталога и многие другие функции, которые уже были в PIM системе.
А пользу-то принесло?
Если посмотреть на процесс в ретроспективе, то методология была гибче некуда. Каждую новую функцию мы показывали клиентам, тестировали вместе с ними на их данных, интересовались отзывами и финансовыми результатами. Лучший результат — это увеличение маржинальности с 5% до 11% и выручки с 70 миллионов до 90 миллионов за три месяца у одного из клиентов. Конечно, это не только наша заслуга, вся команда работала на этот результат. С другой стороны, благодаря нашей системе команда смогла принимать правильные для бизнеса решения, и делать это своевременно. До этого анализировали показатели мая в середине июня, когда уже поздно что-то предпринимать.
А теперь ложка дегтя. На самом деле, мы находимся в некотором информационном пузыре. Мы общаемся с бизнесами, которые уже дошли до внедрения PIM-системы, у которых процессы более-менее налажены и есть стратегия. Но есть мнение, что 90% продавцов на маркетплейсах не используют экономическое планирование, и большинство из них — не планируют использовать.
Давайте представим, что вам такая или похожая система нужна. Давайте подумаем, какие инструменты позволят это реализовать, и сколько это может стоить. Можно пойти разными путями, в зависимости от требований, не связанных с функционалом системы.
Мы не хотим давать доступ к нашим данным никому за пределами компании.
Что же, тогда есть два варианта: реализовать все внутри или купить готовую систему, которая будет работать на вашем оборудовании.
Компании, которые реализуют все самостоятельно, исходя из моего опыта, проходят такие шаги:
- Затянем данные в 1С, там все сопоставим, склеим, сделаем нужные отчеты, настроим уведомления. Тем более, 1С-разработчик, а то и отдел в штате есть.
- Система в 1С закрывает 2-3 пункта из списка тех требований, к которым мы пришли в начале статьи. Это уже приносит пользу, но аппетит приходит во время еды. Теперь хочется наглядности и больше отчетов.
- Нанимается аналитик, 1С выгружает данные, отчеты конструируются в PowerBI. Выясняется, что данных не хватает: самое банальное, нет информации, когда товар был в наличии на складах FBO. Без этого планировать поставки бесполезно.
- Создается база для хранения сырых данных за каждый день. Добавляются Python скрипты, которые регулярно забирают данные из различных API и складывают в базу, потом готовят их для PowerBI.
- Выясняется, что результаты не сходятся. Ошибка — процента два от оборота. Причины могут быть разными, возможно, при обращении к API баг, возможно, какие-то транзакции не учли. Скорее всего, все сразу. Из нашего опыта — как минимум два месяца потребуется, чтобы все сошлось. Кстати, это время зависит от особенностей вашей работы. Если вы работаете, например, только по схеме FBO и у вас небольшой ассортимент, будет быстрее. Точнее, вы много чего не учтете, но и не столкнетесь с этим на ваших данных.
- Выясняется, что код для доступа к API делали в соответствии с документацией. Оказывается, помимо 32 документированных типов транзакций есть два десятка недокументированных. Встречаются нечасто, при тестировании прошли незамеченными. Когда встречаются, портят всю логику.
- Данные, наконец, сходятся в рамках 0.1 — 0.2% . Добавляются новые отчеты.
- Повторяем пункты с 4 по 7 для другой площадки.
- Выясняется, что мы распределили затраты на перемещение товаров на склад FBO на текущие заказы. Сейчас сентябрь, отгружали новогоднюю тематику. Отчеты показывают, что просела маржинальность всего, включая школьную форму.
- Думаем, как данные из разных площадок объединить.
При самом благоприятном раскладе это занимает полгода и 6 миллионов рублей (на практике так не бывает, потому что через полгода поменяется API) . При реалистичном — два человека в штате на постоянной основе на все время работы бизнеса. При этом система получается сложной: тут 1С, тут Python, тут PowerBI, между ними обмены, никто не знает на 100%, как это работает, и что учитывается, а что оставили на потом.
Если что, купить готовую можно у нас.
Мы хотим построить систему управленческого учета с минимальными затратами
Для работы с маркетплейсами есть довольно большое количество сервисов. И они действительно закрывают большое количество задач.
mpstats.io и moneyplace.io дают качественную внешнюю аналитику. По сути, позволяют выбрать перспективные ниши, сравнить свои показатели с показателями конкурентов, отследить сезонность спроса.
marketpapa.ru облегчает управление рекламой на Wildberries
indeepa.com помогает следить за ценами конкурентов на Wildberries
Мы делаем catalog.app. И поставили цель дать пользователям полную картину того, что происходит с бизнесом. Для этого пришлось реализовать все то, что мы заявили в требованиях к нашей системе. Цель бизнеса — зарабатывать деньги, и поэтому в вопросах аналитики мы делаем акцент на экономических показателях. А самое интересное — что это только одна из функций PIM системы. Помимо этого у нас есть управление каталогом, библиотека характеристик и изображений товаров (там уже 71 миллион товаров и 200 миллионов изображений) , и искуственный интеллект, который помогает с рутинными задачами.
У нас нет и в ближайшее время вряд ли появится внешняя аналитика, но для работы с ней уже существуют хорошие сервисы.
Думаю, совместное использование перечисленных сервисов позволит закрыть 90% потребностей в инструментах для маркетплейсов даже для зрелого бизнеса. Мне кажется, это и есть ответ на вопрос, как наиболее эффективно построить работу с маркетплейсами.
Из плюсов — вы получите весь набор инструментов максимально быстро. Вы, скорее всего, не столкнетесь с досадными багами, сервисы уже протестированы тысячами пользователей. Функционал будет шире, чем получится реализовать внутри компании, над ним в сумме работает не один десяток, а то и сотни человек. Интерфейс будет дружелюбнее, чем PowerBI, или, прости господи, 1С.
Из минусов — вы получите только то, что позволяют сервисы. Вам придется дать доступ к своим данным этим сервисам. Кстати, в случае с catalog. app это не обязательно, мы можем поставить систему на ваше оборудование.
В следующий раз поговорим про то, как распределить затраты по заказам на Ozon, если вы решите это реализовать самостоятельно. Подписывайтесь, будет скучно, но полезно.
Чувствую сарказм в ваших словах, но не понимаю, что стало поводом для него.
Предположу, что вы сталкивались только с компаниями, где все по уму реализовано и работает, и приносит пользу. За вас, в таком случае, можно порадоваться.