Планирование потребности в материалах (MRP)

Классический MRP в ERP использует фиксированные сроки поставки и неограниченные мощности. MSF MRP основан на графике APS с учётом реальных ограниченных мощностей, поэтому сроки реалистичны.

Система создаёт предложения, которые утверждают ваши закупщики. Утверждённые предложения передаются в ERP как заказы на закупку.

Да, операции по субподряду и материалы, поставляемые субподрядчикам, полностью поддерживаются.

Нужно пять вещей: спецификации (BOM), которые совпадают с тем, что реально собирают в цехе; остатки на складе, которые совпадают с полкой; сроки поставки, которые измерены, а не унаследованы из старой системы; открытые заказы на закупку и производственные заказы с датами, в которые кто-то ещё верит; и правила по браку, выходу годного и размеру партии. Самое незаметное здесь зависшее открытое снабжение: оно закрывает потребность, которая на самом деле не закрыта. Перед запуском выгрузите все открытые заказы со сроком в прошлом и по каждому примите решение: перенести или закрыть.

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

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

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

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

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

Даты вступления в силу управляют новыми разузлованиями. На уже открытые заказы они не действуют. Запущенный в производство заказ несёт тот состав компонентов, с которым он был выпущен, и повторно не разузловывается. Чтобы протащить в него изменение, придётся перевыпустить заказ или поправить состав вручную. Проверьте, какая именно дата участвует в проверке вступления в силу (создания, запуска, планового старта или потребности), потому что от этого выбора зависит, попадёт ли изменение в конкретный заказ вообще.