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