Точка заказа и страховой запас: когда покупать и сколько оставить на неопределённость

Решение владельца: какой риск дефицита приемлем

Порог заказа отвечает на вопрос «когда начать пополнение». Размер партии отвечает на вопрос «сколько заказать». Страховой запас покрывает неопределённость поверх ожидаемого расхода. Смешивание этих величин приводит к закупке лишнего товара: сотрудник прибавляет резерв и к минимуму, и к рекомендуемому количеству.

В документации Business Central точка заказа связана со спросом за время поставки, а количество определяется отдельной политикой и ограничениями заказа. При переносе расчёта в программу нужно проверить значение каждого поля: универсального соответствия названий экранов нет. Источник: Microsoft Learn.

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

Согласуйте данные до расчёта

Для каждой пары «SKU — склад» подготовьте:

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

Продажи в дни отсутствия товара занижают спрос. Нулевой чек не доказывает, что никому ничего не требовалось. Помечайте такие дни; используйте зарегистрированные отказы или отдельно оценивайте пропуски. Акцию, сезонный скачок и смену ассортимента нельзя автоматически считать обычным случайным колебанием.

Срок поставки измеряйте до момента доступности, а не до прибытия машины. Согласование, разгрузка и проверка качества могут добавить дни. Microsoft отдельно описывает временные буферы до заказа и перед выдачей; календарь определяет фактические даты. Источник: Safety margins.

Учебный пример: постоянный срок поставки

Все числа ниже вымышлены. Рассматриваем одну позицию без сезонности, замен и срока годности. Средний дневной спрос d = 40 штук; стандартное отклонение дневного спроса σd = 15 штук. Срок L строго равен четырём календарным дням. Спрос разных дней независим, распределение суммарного спроса допускает нормальное приближение. Контроль непрерывный, заказ отправляется сразу при достижении порога.

Выбранная цель: примерно 95% циклов пополнения без дефицита. Для одностороннего нормального квантиля используем z = 1,645. Это не обещание выполнить 95% заказов или отгрузить 95% единиц: для них нужны другие показатели. Различие объясняется в материале APICS и в статье о fill rate и OTIF.

Расчёт:

1. Ожидаемый спрос за поставку: d × L = 40 × 4 = 160 штук.
2. Отклонение спроса за поставку: σd × √L = 15 × 2 = 30 штук.
3. Страховой запас: z × σd × √L = 1,645 × 30 = 49,35; округляем вверх до 50 штук.
4. Точка заказа для этой модели: ожидаемый спрос + страховой запас = 160 + 50 = 210 штук.

Порог 210 не означает, что нужно закупать ровно 210. Утверждённая партия может составлять 240 штук, если это подходит обороту, бюджету и упаковке. Её экономическое обоснование делается отдельно.

С каким остатком сравнивать порог

Для примера используем позицию запаса: пригодный физический остаток + подтверждённые открытые поступления − просроченные невыполненные обязательства. Это явно выбранная модель, а не описание алгоритма конкретной программы.

На складе 150 штук, из них 20 заблокированы. Пригодно 130. В пути 60, невыполненный просроченный спрос 10. Позиция равна 130 + 60 − 10 = 180 штук. Она ниже 210: возникает предложение заказать утверждённую партию 240. После регистрации заказа позиция становится 420. Повторный запуск без новых событий не должен создать второй такой же заказ.

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

Что меняется при плавающем сроке

Теперь средний срок остаётся четыре дня, но его стандартное отклонение σL = 1 день. При независимости срока и дневного спроса используем приближение:

Страховой запас = z × √(L × σd² + d² × σL²).

Получаем 1,645 × √(4 × 225 + 1600 × 1) = 1,645 × 50 = 82,25. Округлённый резерв — 83 штуки; порог — 160 + 83 = 243 штуки. Дополнительная неопределённость срока увеличила резерв на 33 штуки относительно первого примера.

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

Если закупщик проверяет склад раз в неделю

Непрерывный порог нельзя без изменений применять к понедельничному заказу. Между проверками может пройти ещё семь дней. В отдельном сценарии с постоянным сроком четыре дня период защиты составляет L + R = 4 + 7 = 11 дней.

При тех же допущениях целевой уровень позиции на момент проверки: 40 × 11 + 1,645 × 15 × √11 = 440 + 81,84 ≈ 522 штуки после округления резерва вверх. При позиции 180 потребность равна 342. Поставщик отгружает коробками по 24: нужно 15 коробок, то есть 360 штук. Позиция после заказа станет 540; дополнительные 18 штук объясняются кратностью. Это модель периодического пополнения до уровня, а не новая точка непрерывного заказа.

Ошибки, которые обнаруживает пилот

Самые дорогие сбои — календарные: продажа каждый день, поставка только по будням, проверка раз в неделю, но в формуле везде стоит «4». Другие причины: дубли открытых заказов, использование заблокированного товара, игнорирование недопоставки, смешение коробок со штуками и сохранение старого среднего после изменения спроса.

Не меняйте резерв после каждого неудачного дня. Сначала разберите причину: неверный прогноз, задержка поставщика, пропущенный заказ или ошибочный остаток. Увеличение параметра не исправляет потерянную накладную.

Приёмочный чек-лист

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

При обсуждении складского модуля и закупок используйте эти сценарии как требования к демонстрации. Поддержку конкретного расчёта и правил согласуйте для выбранной конфигурации SABSUS.

Частые вопросы

Можно поставить страховой запас равным нулю?

Да, если бизнес осознанно принимает риск или работает под заказ. Нулевой резерв сам по себе не означает, что риск исчез.

95% обслуживания означает 95% выполненных заказов?

Нет. В этом примере это доля циклов без дефицита при допущениях модели. Выполнение заказов и объём отгрузки измеряются отдельно.

Как часто пересчитывать параметры?

Назначьте регулярный пересмотр и внеплановые триггеры: новый поставщик, изменение спроса, календаря или упаковки. Частоту выбирайте по скорости изменений и доступной истории.

Источники

Проверено 9 октября 2026 года: Microsoft Learn — политики пополнения, APICS / Peter L. King — модели страхового запаса, Microsoft Learn — временные буферы. Числовые примеры и приёмочные сценарии подготовлены для этой статьи.