|
рактер системы поддержки принятия решений, хотя и в весьма ограниченном объеме, ибо MRP не предлагает полномасштабных сценариев развития событий при тех или иных вариантах решений. Необходимо отметить, что MRP работает исходя из следующих посылок: все операции осуществляются в границах одной производственной площадки, т. е. не поддерживается территориально распределенная структура предприятий; производственные ресурсы не ограничены, поэтому MRP не заботится об их достаточности для выполнения сформированного плана. Явным недостатком на данном этапе развития технологии MRP была невозможность обновить результатную информацию, получаемую в ходе работы MRP, т. е. подстроиться под изменения, возникающие в случае открытых заказов. Из-за этого первые MRP-системы, как отмечают Ландватер и Грей [72], называли «запустил и забыл»). Однако возможность обновления очень важна, так как среда, в которой используется MRP, весьма динамична, а частые изменения размеров заказов и сроков их выполнения не являются редкостью. Отсюда вытекает необходимость отслеживать текущее состояние открытых заказов. Данная фаза развития стандарта MRP имела место при преобладающем характере пакетной обработки информации на удаленных вычислительных центрах (кустовых или корпоративных). Тогда интерактивные технологии развития еще не получили. Если учесть, что в настоящее время, при современном уровне развития вычислительной техники, один запуск процедуры MRP в режиме полного пересчета, согласно статистическим данным, занимает от 3 до 8 часов (в среднем), можно представить, насколько возможности для оперативного моделирования ситуации были ограничены тогда, и становится ясно, что анализ «а что будет, если?..» практически не проводился. По сути MRP просто фиксировала ситуацию в «развернутом» виде. so |
История развития стандарта управления. 23 держки принятия решений. Тем самым MRP помогает руководящим работникам находить наиболее эффективные способы управления бизнесом в целом. APICS подчеркивало, что для успешного внедрения программ MRP необходимы понимание со стороны менеджмента и тотальное обучение персонала. Роль же математических методик оптимизации принимаемых решений была APICS уменьшена. Подчеркивалось, что реальными проблемами являются проблемы дисциплины, образования, понимания и коммуникаций. MRP формирует два массива сообщений: плановые заказы (planned orders) и рекомендации (action messages). Плановые заказы предлагают размер заказа, дату запуска (release date) и дату выполнения заказа (due date) как результат работы MRP в том случае, когда MRP встречается с наличием нетто-потребности (net requirements). Плановые заказы, как отмечает APICS [1], создаются компьютерной системой, существуют только в компьютерной системе и могут быть изменены или удалены компьютерной системой при последующем запуске MRP при изменении исходных данных. Рекомендации —это результат работы системы, определяющий тип действий, необходимых для устранения текущих или потенциальных проблем. Примерами рекомендаций в системе MRP могут служить «запустить заказ», «перепланировать заказ», «отменить заказ». Рекомендации придают MRP характер системы поддержки принятия решений, хотя и в весьма ограниченном объеме, ибо MRP не предлагает полномасштабных сценариев развития событий при тех или иных вариантах решений. Необходимо отметить, что MRP работает исходя из следующих посылок: 1)все операции осуществляются в границах одной производственной площадки, т. е. не поддерживается территориально распределенная структура предприятий; 2) производственные ресурсы не ограничены, поэтому MRP не заботится об их достаточности для выполнения сформированного плана. Явным недостатком на данном этапе развития технологии MRP была невозможность обновить результатную информа 24 Глава 1 цию, получаемую в ходе работы MRP, т. е. подстроиться под изменения, возникающие в случае открытых заказов. Из-за этого первые MRP-системы, как отмечают Ландватер и Грей [9], называли «запустил и забыл» (launch and forget). Однако возможность обновления очень важна, так как среда, в которой используется MRP, весьма динамична, а частые изменения размеров заказов и сроков их выполнения не являются редкостью. Отсюда вытекает необходимость отслеживать текущее состояние открытых заказов. Данная фаза развития стандарта MRP имела место при преобладающем характере пакетной обработки информации на удаленных вычислительных центрах (кустовых или корпоративных). Тогда интерактивные технологии развития еще не получили. Если учесть, что в настоящее время при современном уровне развития вычислительной техники один запуск процедуры MRP в режиме полного пересчета, согласно статистическим данным, занимает от 3 до 8 часов (в среднем), можно представить, насколько возможности для оперативного моделирования ситуации были ограничены тогда , и становится ясно, что анализ «а что будет, если?..» практически не проводился. По сути MRP просто фиксировала ситуацию в «развернутом» виде. 1.3. MRP I/CRP Очевидно, что с ростом возможностей в области обработки данных присущие MRP ограничения перестали удовлетворять менеджеров и плановиков. Поэтому следующим шагом стала возможность обрабатывать ситуацию с загрузкой производственных мощностей и учитывать ресурсные ограничения производства. Эта технология известна как CRP (Capacity Requirements Planning). Она представлена на рис. 1.3, приведенном Робином Гудфеллоу [6]. Для работы механизма CRP необходимы три массива исходных данных: 1. Данные о главном календарном плане производства. Они являются исходными и для MRP. Стоит отметить, что запуск CRP возможен только после того, как отрабо |