Как снизить затраты на логистику на «Озоне»? Кейс на 400 тысяч в месяц

Логистика — одна из основных статей затрат на маркетплейсах. Например, для случайного аккаунта, по которому у меня есть информация, сумма выручки за месяц за выкупленые заказы составила 36 млн рублей, при этом услуги логистики обошлись в 4 с лишним миллиона, или 11 % от выручки. Нам удалось снизить их стоимость на 10 %, получилось 400 тысяч плюса к прибыли компании каждый месяц. Давайте разбираться, как это сделано.

Способ крайне простой по своей сути. Но мало кто так делает, потому что на реализацию нужно потратить время, и при этом хорошо владеть Экселем (лучше меня, по крайней мере, я бы это в Экселе провернуть не смог). Думаю, оптимальнее это делать на каком-нибудь языке программирования. Или иметь программиста, которому можно поставить задачу. Мы это реализовали, сейчас поделимся опытом.

К сути. Нужно взять все ваши заказы за определенный период, для них есть возможность получить регион, в который производилась доставка. Далее необходимо эти регионы сопоставить с кластерами Озона. Информация, какой регион к какому кластеру относится, доступна по ссылке: https://seller-edu. ozon. ru/fbo/warehouses/table-klastery.

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

Еще нам потребуется информация о том, что и в каком количестве уже есть на складах Озона. Эту информацию можно взять из личного кабинета или из API. А вот что взять не получится, при этом оно нам потребуется — это информация о том, когда эти товары были в наличии. Эту статистику можно только накопить, день за днем, маркетплейс её не даст в готовом виде. Эти данные нам потребуются для расчета средних продаж за день. Ведь если двух товаров было продано по сто штук, при этом первый был в наличии 30 дней, а второй — 6 дней, то второй продается в пять раз быстрее. Возможно, пока не совсем очевидно, зачем нужны значения средних продаж в день, ведь можно разделить поставку пропорционально количеству заказов из соответствующих кластеров, и на этом все. Но на самом деле нужны, об этом будет чуть ниже.

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

Дальше просто: для товаров, которые нужно распределить, считаем средние продажи в день для каждого из кластеров. Умножаем на количество дней, и получаем оптимальное количество товара на складе в каждом кластере.

Но не всегда оптимальное количество удается обеспечить, бывает так, что товара для распределения доступно меньше, чем оптимальное число. Тогда распределяем доступный товар так, чтобы с учетом уже имеющихся складских остатков распределение товаров по кластерам соответствовало соотношению спроса в соответствующих кластерах. Это тоже не всегда возможно, бывает, что на складе уже остаток больший, чем нужно. Тогда остается минимизировать разницу между идеальной и реально достижимой картиной.

Бывает и так, что предлагается распределить больше товара, чем то количество, которое покроет спрос на указанный период. Тогда мы предлагаем два варианта: распределить оптимальное количество, либо распределить весь доступный товар. Что делать оставляем на усмотрение менеджера.

Как правило, не на все товары есть история продаж. Тогда соотношение спроса по кластерам можно посчитать по соответствующей категории. Но не всегда есть история и в рамках категории, тогда мы учитываем продажи аккаунта в целом.

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

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

Получается, от менеджера требуется только загрузить один файл в систему, подождать 30 секунд, и потом пробежаться по результатам.

В нашем случае документ выглядит так (фрагмент) :

С одной стороны, статья получилась немного в духе капитана очевидности, “этот простой рецепт позволит вам экономить круглую сумму”.

С другой стороны, это только концептуально просто, но на практике — данные нужно регулярно собирать и складывать куда-нибудь в базу данных, потом их анализировать не самыми тривиальными алгоритмами. В экселе я бы не справился.

С третьей стороны, мы в catalog. app это реализовали и сделали доступным всем желающим. И это, дай бог, 5% от доступного функционала.