Точка заказа: когда и сколько заказывать
При каком остатке размещать заказ? Связываем порог со скоростью продаж и реальным сроком поставки, разбираем объём партии, классы ABC и настройку уведомлений.
Четверг, 9:20 утра. Звонит заведующий складом: на полке не осталось ни одной единицы SKU-3388. При этом в панели маркетплейса видно, что накануне вечером продали четыре штуки и ещё две ждут сборки. Закупщик набирает поставщика и слышит: «десять рабочих дней». Потом кто-то вспоминает, что в прошлом месяце была ровно та же история, но точную дату назвать никто не может. Настоящая проблема здесь не в сроке поставщика и не во внимательности склада. Ни у кого нет письменного и общего для всех ответа на простой вопрос: при каком остатке мы размещаем новый заказ по этой позиции?
Эта статья — о том, как такой ответ построить. Сначала разберём, что на самом деле измеряет точка заказа, откуда берётся каждый член формулы, как честно измерить срок поставки и от чего защищает страховой запас. Затем перейдём к вопросу «сколько заказывать»: ограничения, которые задают объём партии, какие позиции заслуживают отдельного порога, что должно происходить в момент срабатывания, какие ошибки в данных тихо ломают расчёт и как всё меняется, когда вы продаёте сразу в нескольких каналах.
Что на самом деле измеряет точка заказа?
Точка заказа — это не тот остаток, который вы хотите держать на складе. Это триггер: как только доступное количество опускается ниже этого числа, пора размещать заказ поставщику. И измеряет она, по сути, не штуки, а время — это вопрос «сколько я продам, пока едет новая партия», переведённый в единицы товара.
Упустить это различие легко. Команды записывают «минимальный остаток» и держат его неизменным независимо от того, насколько быстро расходится позиция. Поставьте один и тот же минимум товару, который уходит по сорок штук в неделю, и товару, который уходит по три штуки в месяц: первый будет постоянно заканчиваться, а во втором деньги замрут на полке. Одно и то же число означает для двух позиций совершенно разное, потому что триггер завязан на скорость продаж.
Вторая сторона идеи: порог — это напоминание, а не решение. Он говорит «закажи сейчас» и ничего не говорит о количестве. «Когда» и «сколько» считаются отдельно, и смешивать их — самый быстрый способ вылечить дефицит, забив склад неликвидом.
Откуда берётся каждый член формулы?
Базовый вид простой: точка заказа = средние дневные продажи × срок поставки в днях + страховой запас. Первое произведение показывает, сколько вы израсходуете, пока товар в пути. Страховой запас — это допуск на те дни, когда оценка не сработала. Все три величины берутся из разных источников, и каждая из них может оказаться неверной сама по себе.
Средние дневные продажи считаются по выбранному окну потребления — например, по фактическим расходным движениям за последние 60 или 90 дней. Короткое окно — и одна акционная неделя вытягивает среднее вверх; длинное — и вы поздно заметите смену сезона. По сути вы занимаетесь прогнозированием, и оценивать, насколько прогноз сбылся, здесь нужно так же, как отдел продаж проверяет, насколько его прогноз совпал с фактом: если отклонение нигде не фиксируется, исправить его невозможно.
Числовой пример — цифры ниже придуманы для демонстрации арифметики, это не отраслевой ориентир. Допустим, средние дневные продажи 8 штук, срок поставки 12 дней, страховой запас 30 штук. Порог получается 8 × 12 + 30 = 126 штук: заказ уходит в тот момент, когда доступное количество падает ниже 126. Если у того же поставщика срок вырастает с 12 дней до 18, порог поднимается до 174. Со стороны ничего не изменилось, но 126 штук — уже слишком тонкая подушка.
Сколько дней на самом деле длится поставка?
Срок, который поставщик называет по телефону, — обычно только его собственное время подготовки. В ваш расчёт должен входить срок не «от двери до двери», а «от решения до полки»: внутреннее согласование заявки, отправка её поставщику, сборка и упаковка, перевозка, таможня, приёмка и пересчёт и, наконец, момент, когда товар становится доступным к продаже. Двухдневная задержка согласования в середине этой цепочки — тоже часть срока поставки и должна попасть в порог.
Поэтому срок поставки должен быть измеренным числом, а не тем, что помнится. Экран «Эффективность поставщиков» в модуле управления складом ровно это и делает: хранит количество заказов и поставок, суммарные расходы и среднее время доставки в разрезе поставщика. Смутное ощущение «этот поставщик обычно опаздывает» превращается в количество дней, которое можно записать в порог. Логика измерения та же, что и когда отдел продаж отслеживает, сколько на самом деле длятся его сделки: без среднего значения ни одно планирование не будет реалистичным.
Кроме среднего смотрите на разброс. Если девять заказов из десяти пришли за 10 дней, а один — за 25, среднее само по себе вводит в заблуждение. На практике полезно держать два числа: типовой срок для умножения и худший сценарий для расчёта страхового запаса.
От чего защищает страховой запас?
Страховой запас — не расплывчатая подушка «на всякий случай». Он покрывает два конкретных риска. Первый — колебания спроса: за срок поставки вы продали больше, чем ожидали. Второй — колебания самого срока: товар не приехал в обещанный день. Когда оба срабатывают одновременно, дефицит почти неизбежен, потому что у вас нет ни запасных дней, ни запасных штук.
Простой и защищаемый подход выглядит так: страховой запас = (максимальные дневные продажи × максимальный срок поставки) − (средние дневные продажи × средний срок поставки). То есть вы держите в виде запаса разницу между плохим и нормальным сценарием. Это менее точно, чем статистическая модель уровня сервиса, но все исходные данные уже лежат в вашем учёте.
Само решение — это размен между уровнем сервиса и замороженными деньгами. Чем выше страховой запас, тем ниже вероятность дефицита и тем больше средств лежит на полке. Поэтому подушку стоит масштабировать по критичности позиции, а не назначать одинаковой для всего каталога. Рассуждение здесь то же, что и при расчёте, сколько сделок в воронке нужно для выполнения плана: без достаточного буфера попадание в цель — везение, а избыточный буфер просто расходует ресурс впустую.
Сколько заказывать: что ограничивает объём партии
Когда порог срабатывает, многие команды заказывают ровно столько, чтобы снова его перешагнуть, — и получают поток мелких закупок. Здоровее требовать, чтобы партия закрывала сразу два периода: и срок поставки, и интервал до следующего пересмотра. Иначе вы снова окажетесь ниже порога почти сразу после приёмки.
Дальше вступают практические ограничения: минимальная партия поставщика, кратность коробам и паллетам, порог бесплатной доставки, срок годности и место на складе. Здесь помогает «Конвертация единиц измерения»: остаток хранится в одной базовой единице, а заказывать можно коробами или упаковками, поэтому расчёт «нужно 126 штук» аккуратно округляется до целых коробов и никто не пересчитывает единицы вручную.
У объёма есть и стоимостная сторона. Когда перевозка, пошлины и сопутствующие расходы распределяются на единицу товара, себестоимость крупной партии снижается; функция Landed Cost выполняет это распределение и показывает реальную себестоимость единицы и маржу. Как именно попадают в учёт мелкие закупочные расходы — отдельная тема: понимание того, когда оформляется расходная квитанция, не даёт этим суммам потеряться в бухгалтерии.
Каким позициям нужен собственный порог?
Отдельно измерять срок поставки и считать страховой запас для каждой из нескольких сотен SKU нереально. Практичный путь — классифицировать запасы по стоимости и направить усилия туда, где они окупаются. ABC-анализ делит склад на классы A/B/C по стоимости и показывает, где заперт ваш капитал; приоритет работы с порогами вытекает прямо из этого ранжирования.
Таблица ниже — пример рабочего ритма, а не отраслевая норма; её нужно подстроить под количество ваших SKU, число поставщиков и возможности команды.
| Класс | Типичное положение | Пересмотр порога | Подход к страховому запасу |
|---|---|---|---|
| A | Большая часть стоимости, малая доля SKU | Раз в месяц | Считается по каждой позиции, срок поставки измеряется по поставщику |
| B | Средняя стоимость, средняя доля SKU | Раз в квартал | Среднее по категории, ручная правка при заметном отклонении |
| C | Низкая стоимость, много SKU | Дважды в год | Фиксированный порог, редкие крупные заказы |
| Новинка | Истории потребления нет | Еженедельно первые три месяца | Стартуют от похожей позиции, обновляют, когда продажи устоятся |
У классификации есть и вторая выгода — инвентаризация. Когда ведомость пересчёта можно построить по складу и классу ABC, позиции класса A вы считаете часто, класса C — редко, и точность учёта растёт без остановки всего склада. Расчёт порога всё равно опирается на корректные остатки: если в системе 40, а на полке 26, качество формулы уже не имеет значения.
Что должно происходить при срабатывании порога?
Порога, записанного в таблице, недостаточно: кто-то должен вовремя увидеть пересечение границы. «Складские уведомления» проверяют критический остаток, отсутствие товара и затоваривание каждые пятнадцать минут и отправляют оповещение в приложении и на почту. Тонкость здесь не в наличии уведомления, а в том, кому и как часто оно приходит.
Уведомление, которое уходит всем и повторяется по несколько раз в день, перестают замечать за пару недель. Помогает направить пороговые оповещения закупщику, собирать дешёвые позиции в ежедневную сводку и подавлять повторы по одному и тому же SKU — это та же логика, которую применяют, когда заново настраивают уведомления в CRM, перенесённая на складскую сторону.
Путь от уведомления к действию должен быть коротким. Экран «Запасы под риском» строит приоритизированную очередь на основе скорости спроса, доступного количества, срока поставки и допущений о страховом запасе: какая позиция закончится через сколько дней и какая уже опустилась ниже точки заказа. Прямо из строки очереди открывается черновик заказа поставщику, а фильтры по складу и допущениям сужают выборку. Работает порог или нет, чаще всего решает именно количество шагов между уведомлением и заказом.
Какие ошибки в данных тихо ломают расчёт?
Даже верная формула на испорченных входных данных даёт неверный ответ, и такие сбои обычно происходят бесшумно. Самый частый — путаница между доступным и физическим остатком. Штуки, которые лежат на полке, но зарезервированы под другой заказ, продать нельзя, поэтому сравнивать с порогом нужно доступное количество за вычетом резервов. Панель «Здоровье запасов» сводит доступный остаток, резерв, потребление и признаки неподвижности в одну таблицу и отдельно помечает строки, где доступный остаток ушёл в минус.
Вторая частая ошибка — неясность, какой документ списывает товар. В схеме, где отгрузка привязана к накладной, остаток меняется в момент проведения накладной, а выставленный позже счёт формирует только учётную запись и не трогает склад повторно. Экран сверки склада и учёта показывает места, где две книги разошлись, и когда записей «счёт выставлен, товар не списан» накапливается много, пороги тоже срабатывают невпопад. Всё это неотделимо от того, как в целом устроен процесс управления заказами.
Третья группа ошибок идёт от структуры товара. У комплектов доступное количество зависит от остатков компонентов; если держать отдельный порог для компонента и отдельный для набора, не связывая их, один и тот же товар посчитается дважды. Возвраты тоже требуют аккуратности: возврат должен превращаться в приход только на фактически отгруженное количество, иначе несуществующий товар поднимает порог. Надёжное лечение — инвентаризация: если после открытия сессии пересчёта по строке прошло законное движение, корректировка, которая применится при завершении, показывается отдельно, и расхождение между замороженной ведомостью и текущим остатком не исчезает молча.
Как меняется порог в мультиканальных и B2B-продажах?
Когда вы продаёте с одного склада в один канал, порог — это одно число. Откройте тот же остаток нескольким маркетплейсам, и картина меняется: скорость спроса складывается из каналов, а цена дефицита у каналов разная. Если синхронизация остатков отстаёт, показанное в канале количество расходится с фактическим и порог срабатывает поздно, поэтому в мультиканальной схеме часть страхового запаса существует исключительно для компенсации этой задержки.
В B2B колебания жёстче: один дилерский заказ способен съесть месячное среднее одной строкой. Смотреть только на средние дневные продажи здесь опасно — известные дилерские программы и повторяющиеся схемы закупок нужно разбирать отдельно. Когда портал заказов, открытый вашим дилерам, делает такой спрос видимым заранее, расчёт порога опирается на план, а не на сюрприз.
Сам канал приёма заказа тоже источник данных. Клиент может оформить заказ через форму, портал или переписку, и форма и оформление заказа прямо внутри чата — один из способов поймать спрос в момент его возникновения. И терять заказ целиком при нехватке товара не обязательно: модуль работы с отложенным спросом фиксирует неудовлетворённую потребность и автоматически закрывает её при поступлении партии, так что реальный спрос дефицитных дней тоже попадает в данные.
Понимание того, где спрос рождается, тоже питает планирование. Отслеживание того, какая кампания и какая точка контакта превращается в заказ, — работа по картированию пути клиента — окупается на складской стороне не меньше, чем в маркетинге: команда, которая знает о приближающемся спросе, размещает заказ, не дожидаясь порога.
С какой периодичностью пересматривать пороги и с чего начать?
Порог, посчитанный один раз, устаревает за несколько месяцев. Сроки поставки смещаются, товар входит в сезон, акция удваивает спрос. Поэтому порог — не задача внедрения, а календарный пересмотр: дорогие позиции раз в месяц, остальные реже, по классу. На каждом пересмотре проверяют три вещи: были ли за период дефициты, сместилось ли среднее время поставки, не накопилось ли запаса больше ожидаемого.
Акции стоит выделить отдельно, потому что они искажают спрос так, как история продаж предсказать не может. Когда планируется кампания по реактивации остывших клиентов, пороги по участвующим позициям нужно поднять вручную до старта и вернуть на прежний уровень после. Экран старения запасов и оборачиваемости держит другой конец цикла: какая позиция сколько дней лежит на полке, а какая оборачивается быстро. Если неликвид пойман рано, порог снижают и высвобождают деньги.
Начинать не нужно со всего каталога. Возьмите десять позиций, которые заканчиваются чаще всего; по каждой выпишите средние дневные продажи за последние 90 дней и фактический срок доставки по последним пяти заказам, посчитайте порог по простой формуле страхового запаса и направьте уведомление одному ответственному. Через месяц посмотрите, сколько дефицитов случилось по этим десяти позициям, и скорректируйте числа. Если хотите попробовать здоровье запасов, очередь рисков и закупочный процесс в одном месте, откройте бесплатный аккаунт Rocketly и соберите небольшой пилот на собственном каталоге.
Частые вопросы
Точка заказа и минимальный остаток — это одно и то же?
Нет. Минимальный остаток обычно фиксированная нижняя граница, которая не учитывает скорость продаж. Точка заказа включает потребление, ожидаемое за срок поставки, плюс страховой запас, поэтому это число обязано меняться, когда товар начинает уходить быстрее или поставщик замедляется.
Как часто обновлять порог?
Вместо единого правила лучше ритм по классам: раз в месяц для дорогих и быстро оборачивающихся позиций, раз в квартал для средней группы, дважды в год для длинного хвоста дешёвых SKU. Смена поставщика, переход сезона или запланированная акция требуют пересмотра, не дожидаясь календаря.
Как считать средние дневные продажи по сезонным товарам?
Годовое среднее для сезонной позиции обманчиво. До начала сезона опирайтесь на скорость продаж того же периода прошлого года, а внутри сезона — на короткое окно, например последние 14–21 день. Не забыть снизить порог в конце сезона — самый дешёвый способ не остаться с неликвидом.
Если складов несколько, порог должен быть по каждому складу?
Если между складами возможны перемещения, смотреть нужно и на общий остаток, и на остаток по каждому складу: запас, которого суммарно хватает, но который лежит не там, для отгрузки всё равно что отсутствует. При быстрых перемещениях пороги складов держат низкими и подпитывают их из центра; при медленных каждый склад несёт свой порог сам.