Как рассчитать количество товара на поставку и не заказать лишнего

Я ошибался с поставками, когда вычитал из потребности весь товар в пути, не проверяя дату его поступления. На бумаге запас сходился, а на складе товар мог закончиться раньше, чем следующая партия становилась доступна для продажи. Приходилось заново искать окно отгрузки и решать, оправдывает ли срочная перевозка свои расходы. С тех пор я начинаю расчёт с календаря движения товара, а не с количества коробок. Мне нужно понять, какой остаток будет доступен в каждый момент между решением о поставке и следующим пополнением.

Вопрос «сколько товара везти на Озон» поэтому не сводится к умножению средних продаж на срок доставки. В моих магазинах я отдельно смотрю на спрос, ожидание приёмки и уже отправленные партии. Затем проверяю, не скрывается ли за средним значением чередование спокойных дней и резких всплесков. Если этих деталей нет, расчёт выглядит аккуратно, но плохо помогает с закупкой. Ниже я покажу последовательность для одного товара без выдуманных тарифов и примерных остатков, которые легко принять за готовый норматив.

От какой скорости продаж считать поставку

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

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

Одних средних продаж недостаточно, даже когда исходные данные очищены. Одинаковая средняя скорость может получиться у товара с ровным спросом и у товара, который разбирают отдельными всплесками. Я смотрю продажи последовательными отрезками той длины, которую будущая поставка должна закрывать, и сравниваю их между собой. Так видно, сколько дополнительных единиц требовалось в напряжённые периоды относительно обычного сценария. Разовую распродажу без планов на повторение я не превращаю в постоянную потребность. А если впереди похожая акция, учитываю её в прогнозе спроса явно, чтобы затем не заложить тот же рост повторно в страховой запас.

Какой срок доставки нужен для расчёта

По 20 530 доставленным заказам моих магазинов за 90 дней медианный срок доставки составил 2 дня, а 80% заказов доехали за 4 дня и меньше. Медиана показывает середину распределения сроков, но не описывает более долгие доставки. Значение для 80% заказов уже помогает увидеть, что ориентироваться только на середину рискованно. Однако эти числа относятся к доставке заказов покупателям, а не к перевозке моей партии на склад. Подставлять 2 дня или 4 дня в расчёт пополнения на основании этих данных нельзя.

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

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

Разброс срока пополнения я оцениваю по истории сопоставимых поставок, отдельно от покупательских заказов. Смешивать прямую перевозку и маршрут через промежуточный склад без проверки условий я бы не стал. Для каждой партии нужны дата начала подготовки или другого выбранного стартового события и дата доступности товара, причём стартовое событие должно быть одинаковым. Затем я смотрю обычный срок и фактически встречавшиеся задержки, исключая только те случаи, которые могу содержательно объяснить. Незавершённые поставки тоже проверяю: если смотреть лишь на уже принятые партии, самые долгие зависания легко потерять. Когда истории нет, использую рабочую оценку по текущему маршруту и отдельно обозначаю сценарий задержки, не выдавая его за рассчитанную статистику.

Как рассчитать поставку на одном товаре по шагам

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

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

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

После этого получаю целевой запас сложением базовой потребности и страхового запаса. Из целевого запаса вычитаю доступный остаток и подтверждённые поступления, относящиеся к рассматриваемому горизонту. Полученная положительная разница — предварительное количество товара на новую поставку; если разница отрицательная, пополнять запас по этому расчёту не требуется. Это предварительный результат, потому что общее количество ещё ничего не говорит о своевременности каждой партии. После проверки дат я учитываю кратность упаковки и другие действующие ограничения выбранного способа поставки. Округление вверх увеличивает остаток, поэтому его стоимость проверяю отдельно, а не прячу внутри формулы.

Последним шагом раскладываю движение товара по календарю: из начального доступного остатка последовательно вычитаю прогнозируемый спрос, а поступления добавляю только в ожидаемые даты доступности. Если остаток становится отрицательным до прихода партии, увеличение этой же поздней партии разрыв не исправит. Проверка «на сколько дней хватит того, что уже в пути» состоит из разных вопросов: доживёт ли текущий запас до поступления и насколько поступивший товар продлит покрытие. Для ровного спроса деление количества в пути на суточную потребность показывает запас в днях после доступности, но не время, которое можно спокойно ждать от текущей даты. При меняющемся спросе я последовательно списываю дневной прогноз до исчерпания остатка. Такой календарь сразу показывает, где нужна более ранняя доставка, а где достаточно изменить объём.

Какая ошибка превращает запас в лишние расходы

Самая неприятная ошибка для меня — сложить доступный остаток со всем товаром, который где-то едет, и разделить сумму на средние продажи. Особенно опасно смешивать поставки на склад с заказами, уже отправленными покупателям: это разные направления движения товара. Заказ покупателя нельзя считать будущим пополнением, пока фактический возврат не сделал товар снова доступным. Такая путаница занижает потребность в поставке и создаёт дефицит, после которого появляется соблазн оплатить срочную перевозку любой ценой. Денежное последствие я оцениваю через вероятные несостоявшиеся продажи, умноженные на вклад с единицы после переменных расходов, а дополнительные расходы на ускорение считаю отдельно. Разницу между товаром в заказах и деньгами, доступными для закупки, я разобрал в статье про заказы в пути и средства, которые пока нельзя пустить в закупку.

Запрос «минимальная поставка на Озон» я разделяю на техническое ограничение и экономический смысл. Требования к конкретной поставке, упаковке и маршруту нужно проверять в актуальных условиях и при её оформлении, а не переносить из чужого примера. Универсальное минимальное количество для любых товаров и способов поставки я здесь назвать не могу. Мой расчёт отвечает на другой вопрос: какой объём нужен для покрытия спроса и оправдывает ли его отправка связанные расходы. Если расчётная потребность мала, сопоставляю цену отдельной отгрузки с последствиями ожидания до следующего пополнения. Набирать лишний товар только ради ощущения полноценной партии я не считаю достаточным основанием для закупки.

Когда нужно решить, какой объём поставки выбрать после расчёта, я перевожу отклонения от него в деньги. Лишние единицы умножаю на закупочную себестоимость, чтобы увидеть сумму, которая останется связанной в товаре. Это ещё не убыток, но эти деньги нельзя одновременно направить на пополнение другого ассортимента. Отдельно оцениваю дополнительные расходы на перевозку, хранение и возможное снижение цены по своим условиям, не подставляя усреднённые ставки из чужих расчётов. Если есть вероятность дефицита, сравниваю эти расходы с ожидаемым потерянным вкладом от продаж. При недостатке денег сокращаю объём осознанно и фиксирую риск нехватки, а не уменьшаю задним числом прогноз спроса.

Что проверить перед следующей отгрузкой

Перед отправкой я возвращаюсь к исходным данным, потому что даже верная формула не переживёт устаревшего остатка. Проверяю, не изменились ли цена, рекламная активность и доступность товара с момента оценки скорости продаж. Затем уточняю статус каждой ожидаемой партии и пересчитываю календарь, если дата её появления в продаже сдвинулась. Запас, который вчера защищал от задержки, после переноса приёмки может уже расходоваться на обычное ожидание. Если проблема связана с выбором места отгрузки, полезно отдельно сопоставить спрос и стоимость маршрутов — эту задачу я разбирал в статье про выбор складов Ozon без переплаты за близость.

Я сделал SellOps, потому что для своих магазинов не нашёл готовой аналитики, цифрам которой мог бы доверять без постоянных перепроверок. Но никакой сервис не должен подменять неизвестную дату приёмки уверенным прогнозом или смешивать разные виды остатков. Логику работы я описал на странице как устроен SellOps, а сам принцип расчёта можно сначала проверить в обычной таблице. Для каждого результата мне нужна возможность восстановить исходные продажи, остаток и предположения о сроках. Если я не могу объяснить, почему система предлагает именно такое количество, отправлять по этой рекомендации товар рано.

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