Чтобы анализировать дефицит запасов с ИИ, восстановите доступность по SKU, месту и времени, выделите интервалы отсутствия, а затем сравните наблюдаемые паттерны без объявления причины. Продажи в период дефицита запасов могут быть лишь цензурированной нижней границей спроса, поэтому каждое объяснение остаётся гипотезой до различающей проверки.

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

Ключевые выводы

До расчёта фиксируются SKU, место, канал, временное зерно и часовой пояс.

Доступность восстанавливается из движений, а не только из продаж.

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

Потерянный спрос и замещение неизвестны без измеряющих их доказательств.

Для каждого объяснения нужна проверка, отличающая его от альтернатив.

Решения о пополнении или изменении процессов принимает ответственный владелец.

Что такое паттерны дефицита запасов?

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

Исследования запасов рассматривают спрос при отсутствии товара как цензурированный, то есть наблюдаемый не полностью: выполненные продажи не показывают все покупки, которые могли бы произойти при наличии.［1］ Работы по дискретным товарам также исследуют управление при неизвестном цензурированном спросе.［2］ Это различие предотвращает частую ошибку: низкие продажи во время отсутствия товара не доказывают низкий интерес покупателей.

Используйте схему строки, которая хранит наблюдения и интерпретации раздельно:

Поле	Назначение
SKU/location/time grain	Точная единица анализа
Opening/closing on-hand	Сверенное состояние
Receipts/transfers	Приход и перемещения
Sales/cancellations	Выполненный спрос и отмены
Stockout interval	Начало, конец и правило обнаружения
Availability flag	Доступно, недоступно, неизвестно или пробел
Lead time	Фактическое время до пригодного прихода
Reorder parameters	Версия настроек в рассматриваемый момент
Promotion/calendar	Подтверждённый контекст, не причина
Data-quality flag	Пропущенные, дублированные, задержанные или конфликтующие данные
Censoring status	Может ли наблюдаемая продажа занижать спрос
Hypothesis/check	Объяснение и различающий тест
Owner/evidence	Ответственность и результат

Цензурированный спрос и дефицит запасов

Шаг 1. Зафиксируйте зерно и происхождение

Выберите идентификаторы SKU, места, канала и времени. Запишите идентификатор снимка данных, исходные таблицы, запрос или отчёт, фильтры, соответствие статусов и ответственных владельцев. Для замены, комплекта, переименования или перемещения товара сохраняйте таблицу соответствий идентификаторов и даты её действия.

Дайте операционное определение дефицита запасов: нулевой физический остаток, отсутствие количества, доступного для обещания покупателю, запрет заказа или сообщение канала — разные состояния, и они не взаимозаменяемы.

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

Шаг 2. Восстановите временную шкалу

Начните с проверенного остатка на начало периода. В порядке событий примените приходы, продажи, возвраты, перемещения, корректировки, резервирование, снятие резервов, повреждение, карантин и отмены. Укажите, используется ли время заказа, отправки, приёмки, проводки или действия.

Сверьте вычисленный остаток на конец периода с независимым снимком учётных данных. Разница получает сумму, время обнаружения, затронутый интервал и владельца. Не превращайте отрицательный остаток в ноль без следа.

Физическое наличие не равно продаваемому: единицы могут быть зарезервированы, изолированы, сняты с публикации или выделены другому каналу. Храните оба состояния и правило преобразования.

Шаг 3. Отличите нулевые продажи от отсутствия

Каждому временному интервалу назначьте статус: доступно с продажами, доступно без продаж, недоступно, частично доступно, закрыто или неизвестно. Пропавший поток данных — не дефицит запасов, а закрытие магазина — не свидетельство спроса покупателей.

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

Шаг 4. Определите, где возникает дефицит запасов

Запишите воспроизводимую логику. Например, событие начинается при переходе утверждённого сигнала доступности в unavailable, а заканчивается при возврате пригодного запаса и возможности продажи. Определите короткие разрывы, задержки, частичную доступность и закрытые часы.

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

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

ИИ может оформить описание события по проверенным полям, но не может удостоверить событие.

Шаг 5. Группируйте без объявления причин

Агрегируйте только после проверки событий. Полезные разрезы: по SKU, месту, часу, маршруту поставки, диапазону фактического срока поставки, версии правил пополнения, акции, категории и длительности. Показывайте числитель и знаменатель: «12 из 80 недель по парам SKU–место» информативнее, чем «часто».

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

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

Шаг 6. Создайте различимые гипотезы

Просите ИИ предлагать объяснения только из утверждённого перечня типов гипотез и для каждого требуйте различающую проверку:

Гипотеза	Различающее доказательство
Спрос превысил утверждённый прогноз	Сравнить нецензурированные периоды, заказы, поиск или резервы по утверждённому методу
Приход состоялся позже плана	Сравнить время заказа поставщику, отгрузки, приёмки и готовности полученного товара к продаже
Параметр пополнения устарел	Пересчитать с действовавшей версией и известными входами
Учётный остаток был неверен	Сравнить журнал событий с выборочным пересчётом запасов или физическим подтверждением
Запас существовал, но не продавался	Проверить резервирование, карантин, публикацию товара и состояние канала продаж
Перемещение создало локальный дефицит	Проследить время и утверждения движения в обоих местах
Акция изменила спрос	Сравнить подтверждённую экспозицию и подходящий контроль, учитывая факторы, которые могут искажать сравнение

Используйте формулировки «согласуется с», «противоречит» или «не решено». Не превращайте связь в причину только потому, что объяснение модели звучит убедительно.

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

Шаг 7. Выполните проверки и сохраните опровержения

У проверки есть владелец, набор данных, метод, ожидаемый результат, различающий гипотезы, срок, результат и ссылка. Ищите данные, способные опровергнуть предпочтительную гипотезу.

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

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

Шаг 8. Передайте решение владельцу

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

Используйте анализ первопричины только когда доказательства связывают механизм с событием. Панель мониторинга дефицита сама по себе не заменяет анализ первопричины.

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

Шаг 9. Повторно отслеживайте дефицит запасов

Версионируйте определения, соответствия идентификаторов, логику доступности, правила событий, параметры и классификацию гипотез. Повторяйте анализ после исправления источника, изменения ассортимента, запуска нового канала или смены правил заказа.

Отдельно отслеживайте ошибку прогноза и ошибку обнаружения событий. Контролируйте долю интервалов со статусом «неизвестно» и событий с нерешёнными замечаниями к качеству данных. Улучшение модели объяснений не поможет, пока данные событий ненадёжны.

NIST AI RMF связывает Govern, Map, Measure и Manage.［4］ Назначьте владельцев решений, отобразите операционный контекст, измеряйте ошибки событий и выводов и управляйте нерешёнными гипотезами, не превращая их в факты.

Связывайте исторические результаты с породившими их входами и правилами. Не переписывайте прежние паттерны после изменения соответствий SKU или порогов событий.

Как проверить гипотезы причин stockout?

Итоги

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

Часто задаваемые вопросы (FAQ)

Доказывают ли нулевые продажи дефицит запасов?

Нет. Нулевые продажи возможны при отсутствии спроса, закрытии, сбое канала, пропуске данных или недоступности товара. Используйте утверждённый сигнал доступности и временную шкалу запасов.

Показывают ли продажи спрос в период дефицита запасов?

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

Должен ли ИИ оценивать потерянные продажи?

Цензурированный спрос может оценивать только утверждённый аналитический метод с подходящими доказательствами. ИИ не должен выдумывать число по соседним периодам или средним по категории.

Как учитывать замещение?

Только по наблюдаемым данным о корзинах, покупателях или каналах при соблюдении приватности. Рост другого SKU не доказывает замещение.

Какое временное зерно выбрать?

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

Доказывает ли акция причину?

Не только по совпадению во времени. Подтвердите фактический охват акции, найдите сопоставимую контрольную группу и учтите наличие товара, цены, ассортимент и календарь.

Что делать с отрицательным остатком?

Сохранить как исключение и проверить время, пропущенный приход, дубли, единицы измерения, соответствия идентификаторов и правила корректировки.

Когда утверждать изменение?

После проверки событий, гипотез, различающих данных, неопределённости, цены и побочных эффектов ответственным владельцем.

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

Источники

INFORMS, A Censored-Data Multiperiod Inventory Problem with Newsvendor Demand Distributions — https://pubsonline.informs.org/doi/10.1287/msom.1110.0340
Production and Operations Management, Discrete-item inventory control involving unknown censored demand and convex inventory costs — https://doi.org/10.1111/poms.13824
Journal of Business Logistics, The impact of stockout-based switching on fill rates — https://doi.org/10.1111/jbl.12359
NIST, AI Risk Management Framework — https://www.nist.gov/itl/ai-risk-management-framework

Sources checked 6 сентября 2026 г.

Как анализировать дефицит запасов с ИИ без догадок