Для следующей закупки мне нужна дата появления продаваемого остатка, а не дата разгрузки машины. Если товар уже приехал на склад, а покупатель ещё не может его заказать, запас для торговли у меня от этого не увеличился. Деньги в товар вложены, перевозка состоялась, но старый остаток продолжает заканчиваться. Поэтому в своих магазинах я разделяю события «груз передан» и «товар доступен для продажи». Между ними находится время, которое легко потерять в расчёте пополнения.
На вопрос «приёмка поставки на Озон сколько длится» я не могу честно ответить одним количеством дней для любого склада и маршрута. У меня нет подтверждённого актуального норматива, который подходил бы ко всем поставкам, и подставлять срок по памяти я не буду. Сначала нужно понять, от какого события считать ожидание и каким событием его заканчивать. Для проверки работы склада нужен один интервал, для планирования закупки — другой, более длинный. Ниже я покажу, как отделяю эти интервалы и превращаю историю поставок в расчёт следующего заказа поставщику.
Сколько идёт поставка на Ozon от отгрузки до продажи
Я начинаю отсчёт пути поставки с фактической передачи груза перевозчику или выезда своей машины, а не с создания заявки в кабинете. До этого товар может ждать готовности документов, упаковки или подходящего окна отгрузки. После выезда появляется отдельный участок — перевозка до места передачи Ozon. Затем следуют обработка груза на стороне площадки, учёт товара и появление доступного для заказа остатка. Для закупки понадобится ещё и время до отгрузки: сколько поставщик готовит товар и сколько я трачу на подготовку отправления.
Маршрут тоже меняет смысл слова «приехало». При прямой поставке машина направляется к складу назначения, а при маршруте через промежуточную точку передача груза там ещё не означает завершения всего пути. Я отдельно фиксирую этот участок, иначе время перемещения начинает ошибочно выглядеть как долгая приёмка. Сам порядок операций и доступные варианты маршрута нужно проверять для конкретной поставки в кабинете. Если выбираю между схемами, использую подход из статьи о том, как сравнить кросс-докинг с прямой поставкой: сопоставляю расходы вместе со временем, на которое товар выпадает из оборота.
Финишем для планирования продаж я считаю появление пригодного для заказа остатка по конкретному артикулу. При этом отдельно проверяю, что сама карточка доступна к покупке: завершённая обработка поставки не устраняет другие возможные причины недоступности товара. Дата закрытия документов полезна для сверки, но она не обязана совпадать с первым моментом продажи. Бывает и обратная задача: часть товара уже доступна, а со всей поставкой ещё остаются вопросы. Поэтому я не стараюсь описать весь путь одной датой, если фактические события различаются.
Что показывают статусы поставки Ozon и почему ожидание затягивается
Статусы поставки Ozon я использую как подсказки о ходе обработки, а не как замену проверке остатков. Здесь я не привожу названия кнопок и статусов как действующую инструкцию: интерфейс и формулировки могут меняться. По смыслу мне нужны подтверждения разных событий — заявка оформлена, груз передан, обработка началась, количество учтено, товар можно заказать. Возле каждого такого события я ищу дату и источник подтверждения. Если вижу только текущий статус без истории переходов, восстановить точное время предыдущего этапа по нему нельзя.
Когда меня спрашивают, сколько дней принимают товар на Озон, я сначала уточняю границы заявленного срока. Он может относиться к отдельной операции, тогда как продавец считает всё время от выезда машины до доступности товара. Такое сравнение даст расхождение даже без нарушения обозначенного срока. Чтобы проверить именно задержку, я сохраняю условия, действовавшие для моей поставки, и смотрю, какое событие запускает отсчёт и что считается завершением. Затем сравниваю обещанный и фактический интервалы с одинаковыми границами, а не просто две похожие даты из разных документов.
Если фактическое ожидание оказалось длиннее, я ищу участок, на котором возникла разница: перевозка, передача груза, обработка или появление остатка. Очередь, изменение маршрута, расхождения по количеству и проблемы с маркировкой рассматриваю как возможные причины, но не объявляю доказанными без подтверждения. Например, фотография короба и документы помогают проверить подготовку отправления, однако сами по себе не объясняют всё время ожидания на складе. Проверку упаковки я выношу до отгрузки; подробнее этот порядок описан в статье о том, как подготовить и промаркировать короба без путаницы на приёмке. В обращении по зависшей поставке я указываю последнее подтверждённое событие, нужные артикулы и конкретное расхождение, а не только пишу, что товар долго принимают.
Как измерить срок на своих поставках
Для начала мне достаточно таблицы, где есть идентификатор поставки, маршрут, склад назначения, артикул и отправленное количество. Рядом я записываю фактическое время отгрузки, подтверждённой передачи на соответствующей точке маршрута и первого появления доступного остатка. Отдельно сохраняю дату, когда доступным стало всё количество, которое удалось сопоставить с поставкой, и отмечаю расхождения. У каждой записи должен быть источник: документ, история события или сохранённая выгрузка остатков. Если остаток проверялся периодически, я так и помечаю результат — доступность обнаружена при проверке, а точный момент её появления неизвестен.
Одна строка на всю поставку удобна для общего контроля, но для закупки её часто недостаточно. Я смотрю артикулы отдельно, потому что появление части ассортимента не делает доступными остальные позиции. Если доступное количество растёт постепенно, сохраняю эту последовательность, а не присваиваю всей партии дату первого появления товара. При этом сверяю движения: продажи могут уменьшать остаток одновременно с обработкой поступления, поэтому простая разница остатков не всегда равна принятому количеству. Там, где не получается уверенно связать движение с конкретной поставкой, я оставляю отметку о неопределённости вместо красивого, но неподтверждённого срока.
Не подставляйте срок доставки заказа покупателю вместо срока поступления товара на склад. Это разные участки движения товара, с разными началом и концом отсчёта. Быстрая доставка покупателям ничего не доказывает о скорости обработки вашей следующей поставки. Для закупки нужен измеренный путь от заказа поставщику до доступного остатка, а для оценки приёмки — отдельно выделенный складской участок.
По моим магазинам есть подтверждённые данные о 20 864 доставленных заказах за 90 дней: медианный срок доставки составил 2 дня, а 80% заказов доехали за 4 дня и меньше. Медиана описывает середину распределения сроков доставки, а показатель 80% показывает границу, в которую уложилась большая часть этих заказов. Это полезные числа для анализа пути заказа к покупателю. Но в этих данных нет измеренного срока приёмки входящих поставок, поэтому назвать на их основании время пополнения я не могу. Именно такую подмену я проверяю в расчётах: число может быть настоящим и точно посчитанным, но отвечать совсем на другой вопрос.
Сколько дней заказ едет до покупателя
Доля доставленных заказов по сроку доставки
Как посчитать следующую закупку с учётом приёмки
Сначала я собираю полный срок пополнения для выбранного артикула и маршрута. Из даты фактической отгрузки вычитаю дату заказа поставщику и получаю время подготовки; из даты доступности товара вычитаю дату отгрузки и получаю оставшийся путь до продажи. Складываю эти интервалы, проверяя, чтобы между ними не было пропуска или повторно учтённого участка. Если у меня уже измерен весь путь от заказа до доступности, дополнительно прибавлять к нему приёмку нельзя. Для будущей поставки выбираю ориентир по сопоставимым завершённым поставкам, отдельно учитывая известные изменения условий. В результате получаю ожидаемый срок пополнения, а не обещание, что следующая партия обязательно уложится именно в него.
Следующим шагом я определяю расход товара на этот срок. Для базового ориентира делю продажи в штуках за выбранный период на время, когда товар действительно был доступен, а затем корректирую ожидания под известные изменения спроса. Полученный темп умножаю на срок пополнения и вижу, сколько товара потребуется до доступности новой партии. Чтобы определить размер закупки, добавляю к горизонту период продаж, который хочу обеспечить уже после её поступления. Затем прибавляю страховой запас в штуках, выбранный с учётом колебаний спроса и срока поставки. Это отдельная надбавка: если запас на задержку уже включён через удлинённый горизонт, я проверяю, не страхую ли один риск повторно.
После этого из рассчитанной потребности вычитаю текущий доступный остаток и подтверждённые поступления, которые успеют стать доступными в рассматриваемом горизонте. Товар из новой закупки в эти поступления не включаю, иначе расчёт начнёт вычитать собственный результат. Если получается отрицательная потребность, дополнительная закупка по этому расчёту пока не требуется; если положительная — проверяю ограничения поставщика и допустимый объём размещения. Но итогового количества недостаточно: раскладываю расход и поступления по датам, последовательно прибавляя доступные партии и вычитая ожидаемые продажи. Так видно, не закончится ли товар раньше ближайшего пополнения, даже когда суммарно запаса хватает. Момент следующего заказа определяю по прогнозной дате исчерпания остатка, отнимая полный срок пополнения и учитывая выбранную страховку.
Ошибка, из-за которой товар есть в пути, а продавать нечего
Самая опасная для этого расчёта ошибка — прибавить всю отгруженную партию к доступному остатку сразу после отправки. На бумаге запас увеличивается, следующая закупка откладывается, хотя покупатели продолжают расходовать только старый товар. Если он заканчивается раньше появления новой партии, образуется разрыв продаж. Денежную оценку такого разрыва я начинаю с ожидаемого спроса за время отсутствия и вычитаю фактически исполненные продажи. Полученное количество умножаю на вклад продажи в покрытие расходов и прибыль: из выручки предварительно вычитаю себестоимость и связанные с продажей переменные расходы по своим фактическим данным. Это оценка недополученного вклада, а не гарантированный убыток: часть покупателей могла перенести покупку, и без дополнительных данных я не могу знать их поведение.
Другая крайность — увидеть одну долгую обработку и навсегда заложить такой срок во все закупки. Тогда в товаре может остаться больше денег, чем требуется для выбранного уровня запаса, а расходы на его содержание нужно будет проверять отдельно. Поэтому я сравниваю поставки по маршрутам и складам, учитываю масштаб отправления и не смешиваю явно проблемные случаи с обычными без пояснения. Мне нужна и середина распределения сроков, и понимание того, насколько растягиваются медленные поставки. Если наблюдений мало, я прямо считаю ориентир предварительным, а не называю его устойчивой статистикой.
Есть ещё искажение, которое появляется уже после дефицита: продажи за календарный период падают, и расчёт предлагает заказать меньше. Но товар мог плохо продаваться просто потому, что часть времени его нельзя было купить. Поэтому я сначала проверяю доступность и только потом использую историю продаж для прогноза расхода. Одновременно смотрю, не изменились ли цена, продвижение и другие условия, которые делают прошлый период несопоставимым с будущим. Если нехватку товара принять за снижение спроса, следующая закупка закрепит ошибку, и даже нормальная по срокам приёмка не устранит новый разрыв.
Что я предлагаю проверить перед следующей отгрузкой
В нескольких магазинах ручная сверка быстро превращается в поиск дат по разным выгрузкам, поэтому для себя я сделал SellOps, когда не нашёл готовой аналитики, которой мог бы доверить расчёты. При этом сам по себе сервис не превращает неизвестную дату в известную и не заменяет проверку исходных событий. О том, как устроен SellOps, можно прочитать отдельно, а начать измерение срока поставки вполне можно в обычной таблице. Я сначала добиваюсь понятного смысла у каждой даты и каждого количества, а уже затем думаю об автоматизации. Иначе она лишь быстрее размножает ошибку, например приравнивает передачу груза к появлению продаваемого остатка.
Завтра откройте недавнюю завершённую поставку и восстановите для нужного артикула путь от заказа поставщику до доступности товара. Рядом запишите текущий доступный остаток, ожидаемый расход и даты поступлений, которые уже подтверждены. Затем проверьте, хватает ли остатка до следующего появления товара в продаже, не прибавляя груз в пути раньше его предполагаемой доступности. Если разрыв уже виден, пересмотрите дату закупки, маршрут или план продаж, опираясь на реально доступные варианты. После этого заведите такие же записи для новых отправлений: тогда вопрос «когда приходит поставка на Озон» превратится из ожидания статуса в проверяемый прогноз для вашего магазина.
Хотите увидеть эти цифры по своим товарам?
Попробовать SellOps бесплатно