|
ную глубину структур продуктов. Обычно рекомендуется производить запуск процедуры подобного пересчета не реже одного раза в неделю. Вызвано это бывает тем, что данный режим как бы «отодвигает» горизонт планирования в будущее на то время, которое истекло с момента последнего полного пересчета. Однако реализация данной функции сильно зависит от конкретного программного продукта. В том случае если системой понятие горизонта планирования как такового не поддерживается совсем, а при планировании обрабатываются все заказы, прогнозы и прочие источники спроса, занесенные в базу данных, естественной датой, ограничивающей горизонт планирования, полагается дата, которой записан наиболее удаленный заказ (прогноз и т. д.). Такой подход более характерен для MRP-систем без агрегирования потребностей. Если же в системе в качестве параметра поддерживается горизонт планирования, система формирует заказы для покрытия потребности в номенклатурных позициях на указанное количество дней вперед (например, горизонт планирования равен 90 дням), может быть, что только режим полного пересчета «отвечает» за те источники потребности, которые вновь вошли в сферу действия MRP в силу истечения с момента последнего пересчета, скажем, одной недели. Эта неделя «на конце» горизонта планирования в прежних вариантах плана не фигурировала, а следовательно, данные о потребности в изделиях, зафиксированные для этой недели, должны быть обработаны. Такая ситуация более характерна для MRP-систем с агрегированием потребностей. Впрочем, возможна реализация и неких «третьих» вариантов реализации указанного режима вплоть до отказа от его применения. Режим пересчета «по изменениям» применяется тогда, когда необходимо переработать план по тем номенклатурным позициям, для которых с момента последнего пересчета плана произошли изменения, отражающиеся на нем. Перечень этих изменений охватывает все входные данные, необходимые для работы MRP, и подробнее рассматривается ниже. MRP-система в подобном режиме проверяет для каждой номенклатурной позиции, имели ли место подобные изменения, и если да, переделывает плановые заказы на эту номенклатурную позицию. Конечно, сразу следует отметить, что, как и для режима полного пересчета, MRP не уполномочена корректировать подтвер |
Планирование производства и закупок в MRP II 201 потребность в номенклатурных позициях, двигаясь по структуре продукта сверху вниз с учетом сроков исполнения заказов на производство и закупку и уже имеющегося на дату прогнозируемого запуска заказа объема доступных складских запасов, 5.8.3. Режимы работы MRP MRP-системы могут работать в нескольких режимах, которые отличаются друг от друга механизмом выбора номенклатурных позиций, потребность в которых должна быть пересчитана. Режим полного пересчета потребности (Regenerate) используется тогда, когда необходимо осуществить перепланирование потребности для всех номенклатурных позиций, внесенных в базу данных, которые участвуют в построении структур продуктов и отмечены как планируемые при помощи MRP (об альтернативах MRP с точки зрения планирования пополнения запасов мы поговорим в главе, посвященной вопросам управления запасами). При данном режиме старый вариант плана полностью отбрасывается и строится новый вариант. То есть все неподтвержденные заказы на производство и закупку, не попадающие в рамки горизонта планирования, в пределах которого план запрещен к изменению, могут быть отменены, модифицированы по размерам и срокам, а также могут быть сформированы новые заказы. Естественно, что в этом режиме производится пересчет плана производства и закупок на полную глубину структур продуктов. Обычно рекомендуется производить запуск процедуры подобного пересчета не реже одного раза в неделю. Вызвано это бывает тем, что данный режим как бы отодвигает горизонт планирования в будущее на то время, которое истекло с момента последнего полного пересчета. Однако реализация данной функции сильно зависит от конкретного программного продукта. В том случае, если системой понятие горизонта планирования как такового не поддерживается совсем, а при планировании обрабатываются все заказы, прогнозы и прочие источники спроса, занесенные в базу данных, естественной датой, огра 202 Глава 5 ничивающей горизонт планирования, полагается дата, которой записан наиболее удаленный заказ (прогноз и т. д.). Такой подход более характерен для MRP-систем без агрегирования потребностей. Если же в системе в качестве параметра поддерживается горизонт планирования, система формирует заказы для покрытия потребности в номенклатурных позициях на указанное количество дней вперед (например, горизонт планирования равен 90 дням), может быть, что только режим полного пересчета «отвечает» за те источники потребности, которые вновь вошли в сферу действия MRP в силу истечения с момента последнего пересчета, скажем, одной недели. Эта неделя «на конце» горизонта планирования в прежних вариантах плана не фигурировала, а следовательно, данные о потребности в изделиях, зафиксированные для этой недели, должны быть обработаны. Такая ситуация более характерна для M RP-систем с агрегированием потребностей. Впрочем, возможна реализация и неких «третьих» вариантов реализации указанного режима вплоть до отказа от его применения. Режим пересчета «по изменениям» (net change) применяется тогда, когда необходимо переработать план по тем номенклатурным позициям, для которых с момента последнего пересчета плана произошли изменения, отражающиеся на нем. Перечень этих изменений охватывает все входные данные, необходимые для работы MRP, и подробнее рассматривается ниже. MRP-система в подобном режиме проверяет для каждой номенклатурной позиции, имели ли место подобные изменения, и если да, переделывает плановые заказы на эту номенклатурную позицию. Конечно, сразу следует отметить, что, как и для режима полного пересчета, MRP не уполномочена корректировать подтвержденные заказы и те плановые заказы, которые находятся в пределах горизонта планирования, для которого запрещены любые автоматические корректировки плана (в пределы так называемой границы во времени (time fence)). Пересчет плана производится на всю глубину структур продуктов по тем «веткам» структуры, для которых пересчет необходим, так как изменения на верхних уровнях структуры продукта сказываются на всех нижестоящих уров |