Деталь снимают с производства: как проверить план последней закупки

Сначала установите предмет решения

Ниже — самостоятельная учебная проверка, а не предложение приобрести конкретный товар. Все даты, количества и потребности вымышлены. Они заданы для проверки баланса; мы не рассчитываем вероятность отказов оборудования и не выводим срок обслуживания из закона или договора.

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

Например, Texas Instruments в описании прекращения выпуска отдельно указывает последнюю дату заказа, последнюю дату поставки, затронутые изделия и возможную замену. Это пример правил конкретного производителя. Его сроки нельзя переносить на другого поставщика; упоминание замены не подтверждает её пригодность для вашего применения.

Нарисуйте три даты и отдельную границу расчёта

В нашем примере заказ возможен до 20 октября 2026 года, последняя поставка — 10 ноября, потребность продолжается до 15 января 2027 года. Это разные точки решения. Дополнительно обычный рабочий план заканчивается 31 декабря: его техническая граница не должна незаметно стать концом потребности.

В старой документации Oracle Service Parts Planning, раздел Lifetime Buy расчёт охватывает оставшийся сервисный период, включая потребность и возвраты за обычным горизонтом планирования, с вычетом доступных деталей. Здесь этот принцип проверяется своим календарным примером, без повторения формулы Oracle и без заявления о функции SABSUS.

Конец потребности подтверждает её владелец. В карточке должно быть видно, какие площадки, изделия и сценарии включены, а какие исключены. Если после января остаётся неизвестный объём, отметьте неизвестность явно. Запись «после января ноль» допустима только как отдельное проверенное допущение, а не как следствие пустой выгрузки.

Разложите источники по датам пригодности

Нужно 20 деталей 15 ноября, 15 деталей 15 декабря и 10 деталей 15 января: всего 20 + 15 + 10 = 45. На складе доступны 12. Открытая закупка ещё восьми подтверждена к 25 октября. В этой модели обе группы свободны от чужих резервов и подходят по исполнению.

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

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

Проверьте два сценария, не смешивая их

Сценарий А не опирается на неподтверждённый ремонт. Из 45 требуемых деталей уже обеспечены 12 + 8 = 20. Расчётный недостающий объём равен 45 − 20 = 25. Это результат заданных предпосылок, а не рекомендация оформить закупку на 25.

Сценарий Б можно рассматривать, если пять ремонтных единиц до принятия решения стали подтверждённым будущим источником: 45 − 12 − 8 − 5 = 20. Их декабрьская доступность подходит, поскольку ноябрьский расход покрывается без них. Если ремонт не состоится, после декабрьской выдачи останется пять, а январская потребность десять даст нехватку пяти.

Не усредняйте варианты до «22,5 детали» без отдельной модели риска. Здесь нет вероятностей, стоимости нехватки и оценки излишка. Для другого вопроса, выбора объёма при заданном распределении спроса, есть разбор одноразовой закупки newsvendor.

Проверьте две ошибки, которые прячет общий итог

Если взять только ноябрь и декабрь, спрос составит 35, а после вычета 20 обеспеченных останется 15. При таком добавлении январских десяти не будет. Ошибка возникла в границе данных, хотя вычитание выполнено правильно.

Теперь оставим общий объём 25, но перенесём его получение на 20 декабря. Ноябрьские 20 выдаются из исходных 12 и октябрьских восьми. К 15 декабря запас равен нулю, поэтому из требуемых 15 не обеспечена ни одна. Поступление 25 после этого дня исправит общий итог периода, но не прежний срок.

Контрпример важен: перенос на 20 ноября в данном наборе ещё не создаёт нехватку, потому что первая выдача уже обеспечена. Поэтому проверяют остаток на каждой нужной дате, а не автоматически объявляют любую позднюю относительно первого расхода поставку непригодной. Похожая временная проверка разобрана в многоуровневом MRP.

Что предъявить владельцу на утверждение

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

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