Как уменьшить среднее время доставки на Ozon и не потратить на поставки больше, чем заработать
Я сокращаю доставку через размещение запаса ближе к покупателям и контроль отгрузок FBS, а не через поставки на все доступные склады. Расскажу, как найти проблемные товары и регионы, отделить задержки продавца от остальных и проверить экономику дополнительной поставки.
Дополнительную поставку я чуть не отправил туда, где уже лежал товар, — просто потому, что туда было удобно везти. В кабинете меня раздражало долгое время доставки, и казалось, что пополнение знакомого склада должно помочь. Но проверка направлений заказов показала другую проблему: покупатели находились далеко от запаса, который я собирался ещё увеличить. При этом часть нужных им товаров на более подходящих складах заканчивалась. Я остановил подготовку поставки и сначала пересобрал список товаров, а уже потом стал выбирать направление.
С тех пор вопрос, как уменьшить среднее время доставки на Ozon, я начинаю не с поиска свободного места на складе. Сначала выясняю, какая часть пути растягивается и на каких заказах это происходит. Для FBO часто приходится разбираться с расположением и доступностью запаса, для FBS — ещё и со своей обработкой заказа до передачи площадке. Но сокращённый путь сам по себе не делает поставку выгодной. Мне нужно понимать, сколько стоит приблизить товар к покупателю и за счёт чего эти расходы вернутся.
Сначала нахожу товары и регионы, которые растягивают доставку
Среднее время доставки до покупателя Ozon я смотрю вместе с составом заказов, иначе показатель легко понять неправильно. Если выросла доля покупателей из удалённых регионов, общее среднее может увеличиться даже без ухудшения работы на прежних направлениях. Поэтому я выбираю сопоставимые периоды и разделяю заказы по схеме работы, товару, региону получения и складу отправления, где эти данные доступны. Рядом ставлю количество заказов и доступный запас, а не оставляю время доставки единственным столбцом. Так становится видно, где находится повторяющаяся проблема, а где среднее изменилось из-за состава продаж.
В Ozon Seller среднее время доставки и собственный расчёт по выгрузке могут относиться к разным наборам заказов, поэтому я не объявляю расхождение ошибкой площадки. Сначала проверяю описание показателя в кабинете: какие события начинают и заканчивают отсчёт, какой период используется и какие заказы включены. Мой диагностический расчёт проще: для заказов с известными датами считаю длительность от оформления до получения, затем усредняю её внутри выбранной группы. Незавершённые заказы проверяю отдельно по возрасту, иначе самые долгие доставки временно выпадут из анализа. Где искать показатель и как проверять его смысл, я подробнее разобрал в статье о том, как рассчитывается среднее время доставки Ozon.
По каждому складу видно доступный остаток, резерв и то, что уже едет, — с датой прибытия. Ozon эту дату не сообщает: она считается по заявке на поставку и реальному сроку доставки в кластер, а если срок вышел, а товар всё ещё в пути, дата подсвечивается.
Везу в кластеры спроса, а не просто на свободные склады
После группировки я ищу сочетания товара и региона, где одновременно есть заметный поток заказов и долгое ожидание. Самое большое время доставки ещё не означает самый полезный объект для работы: редкое направление может почти не влиять на общий результат. Для приоритета я оцениваю количество заказов вместе с разницей между текущим сроком и достижимым ориентиром по похожим направлениям. Это рабочая оценка, а не формула показателя Ozon и не обещание будущего ускорения. Затем проверяю, можно ли разместить нужный товар ближе к этому спросу и есть ли подтверждённые ограничения по выбранной поставке.
Близкий склад помогает лишь тогда, когда товар на нём действительно доступен к продаже в момент заказа. Я сопоставляю продажи по направлению, текущий остаток, товар в пути и ожидаемый момент доступности новой партии, а не только дату её отправления. Потребность в запасе оцениваю на время до следующего пополнения с учётом колебаний спроса; уже доступный товар и ожидаемые поступления из этой потребности вычитаю. Если продажи недавно ограничивались отсутствием остатков, использую их осторожно: они могут занижать реальный спрос. Почему высокая локализация не оправдывает любое распределение товара, я объяснил в разборе индекса локализации Ozon и поставок без лишнего запаса.
На FBS сначала убираю задержку до передачи заказа
Для FBS я разделяю путь на обработку у себя, передачу отправления и дальнейшее движение до покупателя. Из доступных событий собираю цепочку: заказ появился, товар подготовлен, отправление передано, передача подтверждена. Если значимая задержка возникает до фактической передачи, поставка на другой склад не исправит работу упаковки и сборки. Я проверяю, почему заказы ждут: нет упаковки под рукой, остаток существует только в учёте, сборщик поздно получает задания или выбран неудобный маршрут сдачи. Сроки и условия передачи сверяю с текущими настройками и требованиями кабинета, а не с тем, как процесс был устроен раньше.
После этого я меняю конкретное место задержки: готовлю расходники заранее, сверяю остатки, переношу сборку относительно доступного времени сдачи или пересматриваю точку передачи. При этом статус готовности не считаю доказательством, что посылка уже попала в дальнейшую обработку. Мне нужно подтверждение фактической передачи, иначе красивый внутренний отчёт скрывает ожидание на моём участке. Если заказ передан вовремя, а задержка возникла позже, собираю историю событий и обращаюсь в поддержку по конкретному отправлению. Ускорение своей сборки на таком заказе не устранит уже возникшую задержку перевозки.
Не отправляйте дополнительную партию только ради снижения среднего времени доставки. Товар может оказаться ближе к покупателю, но продаваться слишком медленно, чтобы окупить перевозку, хранение и замороженные деньги. Сначала проверьте спрос именно на этот товар в выбранном направлении и посчитайте сценарий без прироста продаж. Сокращение срока — результат для покупателя, а прибыльность поставки нужно проверять отдельно.
Лист сборки: что и в каком количестве везти в каждый кластер, со штрихкодами. Печатается на бумагу — сборщик отмечает фактическое количество прямо в нём.
Как я считаю окупаемость дополнительной поставки
Я сравниваю два сценария на одном горизонте: оставить размещение как есть или переместить часть запаса ближе к покупателям. Горизонт выбираю под оборот партии и план пополнения, чтобы не сопоставлять расходы всей поставки с выгодой случайного отрезка продаж. В расчёт попадает разница между сценариями, а не вся выручка региона. Заказы, которые и без переноса состоялись бы, не становятся дополнительными только потому, что теперь едут с другого склада. Если данных о влиянии срока на продажи нет, основной расчёт делаю без прироста заказов, а возможный рост оставляю отдельной гипотезой.
Порядок расчёта на своих данных
1
Зафиксировать исходный сценарий
Выберите товар, направление и горизонт расчёта. Запишите ожидаемые продажи, расходы и остатки при сохранении текущего размещения.
2
Посчитать дополнительную маржу
Из выручки только дополнительных заказов вычтите себестоимость проданного товара и связанные переменные расходы. Используйте одинаковую базу выручки и учёта расходов в обоих сценариях, включая применимые налоги.
3
Добавить подтверждённую экономию
Прибавьте сокращение расходов на заказы, которые состоялись бы и без переноса. Разницу проверяйте по актуальным условиям и своим начислениям, не считая близкий склад автоматически более дешёвым.
4
Вычесть дополнительные затраты
Вычтите разницу в расходах на поставку, подготовку, хранение и финансирование запаса. Учтите ожидаемые потери от зависшего товара, не дублируя расходы, уже включённые в маржу.
5
Проверить неблагоприятный сценарий
Повторите расчёт без прироста продаж и с более медленным оборотом. Если результат держится только на неподтверждённом росте спроса, рассматривайте поставку как проверку гипотезы, а не как гарантированную экономию.
В таблице я разделил результат без роста заказов и сценарий, где дополнительный спрос действительно появился. Все суммы условные: здесь нет действующих тарифов Ozon или прогноза для конкретного магазина. Расходы на поставку и хранение показаны именно как увеличение относительно исходного размещения, а не как полная стоимость работы. Строка переменных расходов включает себестоимость дополнительных продаж и связанные с ними расходы, поэтому повторно вычитать их не нужно. Итог получается из дополнительной маржи и экономии за вычетом всех строк дополнительных затрат.
Пример расчёта дополнительной поставки — числа условные
Одинаковый горизонт, суммы в рублях; расходы указаны положительными величинами
Статья
Без прироста продаж
С приростом продаж
Дополнительная выручка
0 ₽
10 000 ₽
Переменные расходы дополнительных продаж
0 ₽
7 000 ₽
Дополнительная маржа после переменных расходов
0 ₽
3 000 ₽
Экономия на прежнем объёме заказов
1 000 ₽
1 000 ₽
Дополнительные расходы на поставку
1 500 ₽
1 500 ₽
Дополнительное хранение
500 ₽
500 ₽
Дополнительное финансирование запаса
500 ₽
500 ₽
Ожидаемые дополнительные потери от залеживания
500 ₽
500 ₽
Результат относительно исходного размещения
−2 000 ₽
1 000 ₽
Пример, числа условные. Это сценарный расчёт, а не тарифы Ozon.
В примере из таблицы экономии на существующих заказах недостаточно, и положительный результат появляется только при дополнительном спросе. Значит, перед отправкой мне нужно проверить именно предположение о росте продаж, а не ещё раз убедиться, что склад расположен ближе. Возможное изменение логистических начислений я считаю отдельно, опираясь на условия для своих товаров и направлений. В статье про наценку за нелокальные продажи и выбор направления поставки я подробнее разобрал эту часть решения. Если подтвердить экономию пока нельзя, я исключаю её из базового сценария, а не подставляю удобную оценку.
Локальность: сколько товара уехало покупателям из того же кластера, где он лежал, а сколько — через всю страну. Нелокальная доставка дороже, и в юнит-экономике это видно.
Ошибка, из-за которой быстрая доставка выглядит выгоднее, чем есть
Самая неприятная ошибка в таком расчёте — записать в пользу новой поставки всю маржу заказов из выбранного региона. Допустим, покупатели уже заказывали товар, просто получали его дольше, а после переноса продолжили покупать примерно так же. Маржа этих продаж существовала и раньше, поэтому она не оплачивает дополнительные расходы в сравнении сценариев. В пользу переноса можно записать подтверждённую экономию и маржу действительно дополнительных заказов, а не весь региональный оборот. Иначе я увижу прибыльный отчёт о поставке, хотя общий результат магазина ухудшится из-за новой перевозки и хранения.
Есть и обратный перекос: вычесть всю закупочную стоимость отправленной партии как расход периода, хотя часть товара осталась на складе. Для оценки прибыли я отношу себестоимость к проданным единицам, а непроданный запас рассматриваю отдельно через потребность в деньгах, хранение и риск потерь. Проверку денежного потока при этом не отменяю: прибыльная на бумаге поставка всё равно может оставить меня без средств на следующее пополнение. Ещё я учитываю, не забрал ли товар с направления, где он продавался быстрее и с лучшим результатом. Потерянная маржа там способна перекрыть пользу от ускорения доставки здесь.
Что я проверю перед следующей поставкой
Завтра я бы начал с выгрузки заказов и остатков, а не с бронирования очередной поставки. Из неё выбрал бы товар с повторяющимимся спросом в направлении, где доставка заметно дольше, и проверил бы его доступность на подходящих складах. Затем сравнил бы исходное размещение с переносом части запаса по расчёту выше. Для FBS вместо перемещения товара сначала проверил бы задержку до передачи и возможность убрать её без изменения складской схемы. Такой порядок даёт конкретное решение: что менять, какую причину устранять и какие расходы допустимы.
После изменения я сравниваю доставку внутри того же направления и товара, а затем смотрю на общий показатель магазина. Рядом проверяю наличие, продажи, маржу и расходы, чтобы ускорение не оказалось куплено чрезмерным запасом. Изменения цены, рекламы и сезонного спроса фиксирую отдельно: иначе рост заказов легко приписать новой поставке без достаточных оснований. Для регулярной работы с экономикой своих магазинов я сделал SellOps, потому что не нашёл готового решения, расчётам которого доверял бы; описание подхода есть на странице как устроен сервис. Но инструмент не заменяет проверки исходных данных и не доказывает, что именно короткая доставка принесла новые продажи.
До отправки партии я записываю ожидаемый результат и условие, при котором не стану повторять поставку. Это может быть отсутствие сокращения срока внутри выбранного направления, слишком медленный оборот или дополнительные расходы, которые съели экономию. Для проверки выбираю объём под подтверждённый спрос и доступные условия поставки, а не заполняю склад ради запаса на всякий случай. После появления сопоставимых данных решаю, пополнять направление дальше, изменить состав партии или отказаться от переноса. Начать можно с конкретной пары «товар — регион» и расчёта без роста продаж: он быстрее всего показывает, где ускорение доставки имеет экономический смысл.