Рисунок 1.7 – Принципиальная схема планирования по точке заказа

Данная система основывается на сборе статистики, обработке и загрузке данных в систему следующих существенных параметров номенклатуры:

1. значение текущего запаса продукции на складе;

2. значение точки перезаказа для продукции;

3. время пополнения запаса (плановые сроки поставки);

4. объём заказа.

Ежедневно, чаще всего в ночные часы, на складе выполняется замер текущего уровня запаса продукции. Если значение запаса ниже точки перезаказа, запускается процедура пополнения, допустим, через закупку от поставщика или же заказ в производство.

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

ТочкаПерезаказа = ПотреблениеВДень / ПлановыеСрокиПоставки, где ПотреблениеВДень характеризует объём потребляемой продукции за 1 день, ПлановыеСрокиПоставки – сроки поставки материалов от поставщика на склад в днях.

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

На следующем этапе развития предприятия начали автоматизировать процессы формирования, учета и отслеживания календарной потребности в готовой продукции (заказы клиентов, прогнозы продаж и т. д.). Следующим шагом стал анализ плана выпуска готовых изделий с целью определения календарной потребности в комплектующих изделиях, сырье и материалах, деталях и сборочных единицах с учетом наличного складского запаса. Эта задача была решена в компьютерном варианте в начале 60-х гг. и получила название MRP (Material Requirements Planning) – планирование потребности в материалах. Термин был введен в употребление Орлицки (Orlicky), который осознал потенциал применения вычислительной техники для решения задачи управления производственными запасами. Ранние компьютерные приложения MRP были построены на основе процессора спецификаций (Bill of Material Processor – BOMP), преобразовавшего дискретный план производства родительских номенклатурных позиций в дискретный план производства и закупки номенклатурных позиций-компонентов.

Основой системы стали данные о составе изделий и нормах расхода сырья, материалов и компонентов на единицу измерения готовой продукции. В теории MRP эта информация получила название BOM (Bill of Material) (спецификация) [49]. BOM может быть одно- или многоуровневым, обычным или плановым. Одно- или многоуровневый ВОМ означает, что для описания структуры продукта используется обычный список или многоуровневое древовидное описание. Чем глубже эта древовидная структура, тем более жесткие требования предъявляются к точности данных о номенклатурных позициях, включаемых в эту структуру (рисунок 1.8).

Рисунок 1.8 – Пример представления древовидной спецификации в 1С ERP

Результатом вышеперечисленных действий является описание потребности предприятия в производимых и закупаемых номенклатурных позициях, выраженное в виде календарного плана. Причем особо следует отметить, что сам механизм MRP не делает различия между способами получения номенклатурных позиций (закупка или производство), предоставляя решать этот вопрос ответственным лицам, хотя всегда существует возможность задать способ получения той или иной, покрывающей потребность предприятия, номенклатурной позиции по умолчанию (обычно закупаемая или же обычно изготавливаемая).

С начала 70-х гг. популярность MRP поддерживается APICS (American Production and Inventory Control Society) [45], начавшей свою деятельность в области продвижения MRP с попытки убедить людей в том, что MRP является решением многих проблем, ибо дает возможность сформировать интегрированные системы налаживания коммуникаций внутри компании и поддержки принятия решений. Тем самым MRP помогает руководящим работникам находить наиболее эффективные способы управления бизнесом в целом. APICS подчеркивала, что для успешного внедрения программ MRP необходимы понимание со стороны менеджмента и тотальное обучение персонала. Роль же математических методик оптимизации принимаемых решений была APICS уменьшена. Подчеркивалось, что реальными проблемами являются проблемы дисциплины, образования, понимания и коммуникаций.

Явным недостатком на данном этапе развития технологии MRP была невозможность обновить результатную информацию, получаемую в ходе работы MRP, т. е. подстроиться под изменения, возникающие в случае изменений открытых заказов. Из-за этого первые MRP-системы называли «запустил и забыл» (launch and forget). В свою очередь, возможность обновления очень важна, так как среда, в которой используется MRP, весьма динамична, а частые изменения размеров заказов и сроков их выполнения не являются редкостью. Отсюда вытекает необходимость отслеживать текущее состояние открытых заказов.

Данная фаза развития стандарта MRP имела место при преобладающем характере пакетной обработки информации на удаленных вычислительных центрах (кустовых или корпоративных). Тогда интерактивные технологии развития еще не получили. Если учесть, что в настоящее время при современном уровне развития вычислительной техники, один запуск процедуры MRP в режиме полного пересчета, согласно статистическим данным, занимает от 3 до 8 часов (в среднем), можно представить, насколько возможности для оперативного моделирования ситуации были ограничены тогда, и становится ясно, что анализ «а что будет, если?..» практически не проводился. По сути, MRP просто фиксировала статический план в «развернутом» виде.

Очевидно, что с ростом возможностей в области обработки данных присущие MRP ограничения перестали удовлетворять менеджеров и сотрудников служб планирования. Поэтому следующим шагом стала возможность обрабатывать ситуацию с загрузкой производственных мощностей и учитывать ресурсные ограничения производства – CRP (Capacity Requirements Planning). Процедура CRP запускается после завершения процедуры MRP, так как исходными данными для CRP являются также результаты работы MRP в виде плановых заказов на номенклатурные позиции производства. Задачей CRP является проверка плана производства на выполнимость.

Для работы механизма CRP необходимы три массива исходных данных:

1. Данные о главном календарном плане производства (MPS). Они являются исходными и для MRP.

2. Данные о рабочих центрах. Рабочий центр, как отмечает APICS [45], – это определенная производственная мощность, состоящая из одной или нескольких машин (людей и/или оборудования), которая в целях планирования потребности в мощностях (CRP) и подробного календарного планирования может рассматриваться как одна производственная единица. Можно сказать, что рабочий центр – это группа взаимозаменяемого оборудования, расположенная на локальном производственном участке. Для работы CRP необходимо предварительное формирование рабочего календаря рабочих центров с целью вычисления доступной производственной мощности.