Как рассчитать поставку на Озон по скорости продаж и фактическим срокам
Перед отправкой партии на Озон я сначала проверяю, когда товар закончится в нужном кластере, а уже потом смотрю, сколько помещается в коробки. Обратный порядок удобен для сборки, но плохо связан со спросом. Можно отправить большую партию и всё равно получить провал продаж, потому что доступной она станет слишком поздно. Можно привезти товар заранее и заморозить деньги в запасе, который пока никому не нужен. Поэтому для меня вопрос «сколько поставить» начинается с календаря движения товара, а не с количества на моём складе.
В моих магазинах я разделяю скорость продаж, срок пополнения и запас на отклонения от плана. Если смешать их в одной приблизительной оценке, потом трудно понять, почему расчёт не сработал. При этом у доставки есть разные часы: одни отсчитывают путь заказа до покупателя, другие — путь новой партии до доступного остатка. Для расчёта поставки нужны именно вторые, а первые помогают проверить, насколько разумно товар размещён относительно спроса. Ниже я покажу, какие данные беру, что последовательно вычитаю и где оставляю поправку на неопределённость.
Что реальные заказы говорят о доставке до покупателя
По 19 294 доставленным заказам моих магазинов за 90 дней медианный срок доставки составил 2 дня. При этом 80% заказов доезжают за 4 дня и меньше. Медиана показывает середину распределения сроков, но не описывает его более медленную часть. Если смотреть только на неё, можно решить, что доставка почти всегда укладывается в привычный короткий срок. Граница, в которую попадает 80% заказов, уже показывает, почему одного среднего ориентира для планирования недостаточно.
Но из этих данных нельзя сделать вывод, что новую поставку нужно отправлять за 2 дня до обнуления остатков. Здесь измерена доставка покупателю, а не время подготовки партии, перевозки, приёмки и появления товара в продаже. Это разные процессы, даже если в обоих случаях я использую слово «доставка». Кроме того, приведённые значения относятся к общей выборке моих магазинов, а отдельных значений по кластерам в этих фактах нет. Я не стану приписывать конкретному направлению общий срок только потому, что он получился по всем заказам вместе.
Для анализа размещения я смотрю на направление спроса и на то, откуда фактически отправлялся заказ. Быстрая доставка в общей выборке может соседствовать с медленным обслуживанием отдельного кластера, если товар лежит далеко от покупателей. При детализации я также проверяю, хватает ли наблюдений, чтобы случайная задержка не превратилась в постоянную норму расчёта. А выборка только доставленных заказов не показывает, сколько ещё едут незавершённые заказы, поэтому по ней нельзя без оговорок оценивать текущие задержки. Этот график для меня — повод исследовать разброс, а не готовый норматив для следующей поставки.
Сколько дней заказ едет до покупателя
Доля доставленных заказов по сроку доставки
0 дн.11,6 %
1 дн.31,4 %
2 дн.22,4 %
3 дн.12,1 %
4 дн.7,0 %
5 дн.4,1 %
6 дн.3,1 %
7 дн.2,1 %
8 дн.1,4 %
9 дн.1,0 %
10 дн.0,8 %
11 дн.0,6 %
12 дн.0,5 %
13 дн.0,5 %
14 дн.0,5 %
Половина заказов доезжает за 2 дня, восемь из десяти — за 4 дня. Именно на этот срок деньги за товар уже потрачены, а выручки ещё нет. Собственные магазины автора, 19 294 доставленных заказов за 90 дней
Как получить скорость продаж без занижения спроса
Поставку я считаю по конкретному товару и направлению спроса, а не по общей выручке магазина. Мне нужно количество единиц, которое покупатели обычно заказывают за день, пока товар доступен. Для начала беру сопоставимый период без резкой смены цены, рекламной активности и условий продажи. Затем отделяю время нормальной доступности от дней, когда остаток закончился или предложение фактически перестало участвовать в продаже. Иначе отсутствие заказов из-за пустого склада ошибочно превращается в доказательство отсутствия спроса.
Базовую скорость я получаю делением количества проданных единиц на продолжительность доступности товара в днях. Считать только доставленные заказы за самый свежий период рискованно: часть уже оформленного спроса ещё находится в дороге. Поэтому я сверяю заказы, отмены и доставленные единицы, не складывая разные статусы одного заказа между собой. Возвраты тоже не превращаю автоматически в будущий доступный остаток, пока товар не вернулся и не подтверждено его пригодное для продажи состояние. Если надёжной истории доступности нет, я помечаю оценку как приблизительную, а не выдаю её за точный прогноз.
Спрос кластера я стараюсь определять по направлению заказов покупателей, а не только по складу отгрузки. Иначе склад, который обслуживает чужие направления из-за отсутствия местного запаса, будет выглядеть самостоятельным источником повышенного спроса. Дальше проверяю, сохранится ли найденная скорость после поставки: не заканчивается ли продвижение, не меняется ли цена, нет ли сезонного спада. Когда ожидается изменение, отдельно записываю базовый сценарий и причину поправки, чтобы потом сравнить ожидание с фактом. Простой перенос вчерашних продаж в будущее работает только при достаточно похожих условиях.
Какой срок подставлять в расчёт поставки
Срок пополнения я отсчитываю от момента, когда принимаю решение отправить товар, до момента, когда партия становится доступной для продажи в выбранном кластере. Внутри могут оказаться подготовка, ожидание подходящей возможности отгрузки, перевозка, разгрузка и приёмка. Если товар ещё надо закупить, к этому же пути добавляется ожидание закупки, иначе расчёт начинается слишком поздно. Справочный срок перевозки покрывает лишь часть этой цепочки и потому не заменяет историю фактического пополнения. Для каждой завершённой партии я сохраняю сопоставимые даты начала и конца процесса, чтобы измерять одно и то же.
Сначала нахожу базовую скорость спроса в единицах за день для товара и кластера. Проверяю доступность товара в выбранном периоде и отдельно учитываю ожидаемое изменение спроса.
Затем определяю фактический срок пополнения по сопоставимому маршруту и способу поставки. Беру время до доступности для продажи, а не до прибытия машины.
К сроку пополнения добавляю интервал до следующего планового решения о поставке. Получается горизонт, который должен покрыть запас, если я пересчитываю пополнение периодически.
Умножаю ожидаемую дневную скорость на этот горизонт. Так получаю базовую потребность в единицах товара без страхового запаса.
Добавляю запас на разброс сроков и, если есть основания, на колебания спроса. Для каждой добавки записываю причину, чтобы одна задержка не была учтена повторно.
Из целевого запаса вычитаю текущий доступный остаток и пригодный товар в пути, который ожидаю получить в пределах расчётного горизонта. Уже созданную поставку учитываю здесь, а новую рассчитываемую партию ещё не вычитаю.
Отрицательный результат заменяю отсутствием потребности в новой партии. Положительный проверяю по календарю поступлений, после чего согласую с фактическими ограничениями упаковки, отгрузки и бюджета.
В короткой записи мой расчёт выглядит так: поставка равна спросу за срок пополнения и интервал пересмотра, плюс страховой запас, минус доступный остаток, минус подходящие поступления в пути. Интервал пересмотра нужен потому, что следующее решение об отправке принимается не обязательно сразу после текущего. Если я контролирую остатки непрерывно, использую другую логику: точка заказа должна покрывать спрос до поступления и страховой запас, а размер партии определяю отдельно. Смешивать эти схемы неудобно, потому что легко добавить один и тот же период ожидания повторно. Для ручного планирования по расписанию я предпочитаю явно видеть весь горизонт покрытия.
После общего расчёта я раскладываю остаток по датам: начальный запас плюс ожидаемые поступления минус накопленный прогноз спроса. Это проверка на ситуацию, когда суммарного товара вроде хватает, но первая партия приезжает уже после обнуления. Такой разрыв нельзя исправить увеличением поставки, которая поступит ещё позже. Придётся отдельно искать более раннее пополнение, доступное перемещение или менять план продаж до прихода товара. При этом текущий остаток и спрос должны быть согласованы: если резерв уже исключён из доступного количества, я не вычитаю те же зарезервированные заказы повторно.
Как заложить запас на задержки и не купить лишнего
Запас на срок поставки и запас на разброс сроков я считаю разными частями потребности. Первый расходуется, пока партия идёт обычным для этого маршрута путём, второй нужен, когда фактическое пополнение оказывается медленнее принятой базы. Для понятного ручного расчёта выбираю по истории более осторожный срок и нахожу его превышение над базовым. Затем умножаю это превышение на ожидаемый дневной спрос и получаю добавку в единицах товара. Если наблюдений мало, вместо уверенного норматива использую явно обозначенный сценарий задержки и пересматриваю его после новых поставок.
Не подставляйте срок доставки покупателю вместо срока появления новой партии в продаже. Мои 2 дня медианной доставки и 80% заказов в пределах 4 дней не измеряют пополнение склада. Если осторожный срок уже заложен в основной горизонт расчёта, повторная добавка на то же самое удлинение завысит поставку. Страховой запас должен покрывать конкретный риск, а не маскировать путаницу в исходных данных.
Конкретная ошибка — взять продажи за календарный период, включающий отсутствие товара, и умножить эту заниженную скорость на справочный срок перевозки. Здесь одновременно уменьшаются обе части потребности: предполагаемый спрос и время, которое надо пережить до пополнения. Следующая партия снова заканчивается раньше ожидаемого, а недополученные заказы ещё сильнее портят историю продаж. Денежное последствие я оцениваю через вероятно потерянные единицы спроса и маржинальный доход с единицы после переменных расходов, а не через всю несостоявшуюся выручку. Обратная ошибка тоже стоит денег: повторный запас на одну задержку увеличивает закупку, связывает оборотные средства и может добавить расходы на хранение.
Что проверить перед отправкой следующей партии
Перед подтверждением поставки я сравниваю расчётную потребность с деньгами, которые партия заберёт из оборота. Даже обоснованный запас может оказаться слишком дорогим, если одновременно пополнять весь ассортимент без приоритетов. Тогда я не уменьшаю все позиции одинаково, а смотрю, где вероятнее разрыв доступности и какой вклад даёт продажа товара. Отдельно проверяю медленные позиции: большой остаток в одном кластере не означает, что им можно вовремя закрыть спрос другого. Товар становится частью покрытия только тогда, когда понятны возможность, срок и затраты его перемещения.
Чтобы повторять такой расчёт, я держу рядом скорость спроса, доступный остаток, ожидаемые поступления, срок пополнения и основание для страхового запаса. В нескольких магазинах ручное сведение этих данных быстро становится отдельной работой. Я сам сделал SellOps, потому что не нашёл готового сервиса аналитики, которому доверял бы при принятии решений по своим магазинам. Подход к работе с ним описан на странице как устроен SellOps, но исходную механику расчёта я всё равно проверяю самостоятельно. Сервис не должен подменять неизвестный срок красивым числом, если по маршруту ещё нет надёжной истории.
После появления партии в продаже я возвращаюсь к записи, сделанной перед отправкой, и сравниваю прогноз с фактом. Проверяю, насколько отличались спрос и срок пополнения, был ли разрыв доступности и понадобился ли страховой запас. Если задержалась приёмка, меняю оценку соответствующей части пути, а не автоматически увеличиваю дневные продажи в модели. Если продажи выросли из-за изменения условий, пересматриваю прогноз спроса и не записываю этот рост в транспортный риск. Такое разделение помогает понять причину ошибки и не наращивать следующую поставку просто из осторожности.
Завтра я бы начал с товара, который уже собираюсь отправлять, и выбранного кластера, а не с переделки всей системы учёта. Выгрузил бы заказы и историю доступности, собрал даты завершённых пополнений и выписал текущие партии в пути. Затем посчитал бы базовую потребность, отдельно добавил запас на задержку и вычел остатки, не смешивая будущую поставку с уже отправленной. Последняя проверка — календарь: останется ли товар доступным до каждого ожидаемого поступления. Если на каком-то участке данных нет, я бы зафиксировал допущение рядом с расчётом, чтобы следующая реальная поставка помогла его уточнить.