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

Класичний MRP в ERP використовує фіксовані терміни постачання та необмежену потужність. MSF MRP спирається на графік APS з обмеженою потужністю, тому терміни реалістичні.

Система створює пропозиції, які затверджують ваші закупівельники. Затверджені пропозиції передаються в ERP як замовлення на закупівлю.

Так, повністю підтримуються субпідрядні операції та матеріали, що постачаються субпідрядникам.

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

Не в тому вигляді, який вам потрібен. MRP віднімає від потреби наявні залишки та відкриті постачання, тож якщо залишок хибний, відповідь хибна одразу в обидва боки: система замовляє матеріал, який у вас уже є, і мовчить про матеріал, якого немає. Циклічну інвентаризацію по позиціях, що несуть основну частину вартості, треба провести ще до старту, не відкладаючи на наступний етап проєкту.

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

Так, окремо, у зв’язці лише з вашою ERP. Залишаються багаторівневе розгортання BOM, віднімання наявних залишків і відкритих постачань, календарі постачальників і мінімальні обсяги замовлення. Втрачаєте ви дати, що спираються на графік: потрібні дати рахуються через фіксований зсув на термін постачання, тобто вони рівно настільки точні, наскільки точні терміни, які хтось вніс у довідник, і вони не зсуваються, коли цех відстає.

Не ухвалює комерційних рішень. Він пропонує кількості й дати; він не торгується про ціну, не обирає між постачальниками поза тими даними, які ви налаштували (пріоритетний постачальник, цінові пороги, термін постачання, мінімальний обсяг замовлення, календар), і не прогнозує попит, бо прогноз має прийти з вашого плану продажів. Він також не бачить матеріал, який списали в цеху фактично, але не провели в системі, і саме це найчастіше стоїть за пропозицією, яка виглядає неправильною.

Це щоденний прохід по списку винятків, обсяг якого залежить від кількості планованих позицій і ширини горизонту винятків. Запуск видає повідомлення про прискорення, уповільнення та скасування, і вся цінність полягає в тому, що хтось вирішує, які з них справді важливі, і діє того самого дня. Там, де цей крок пропускають, список росте, поки його перестають відкривати взагалі, а систему починають називати надто шумною.

Дати чинності керують лише тим, що підставиться в нові розгортання; уже відкрите вони не змінюють. Випущене замовлення несе той перелік компонентів, з яким його видали, і повторно не розгортається, тож щоб внести зміну в нього, замовлення треба перевипустити або відкоригувати вручну. Перевірте, яка саме дата бере участь у перевірці чинності (створення, випуску, планового старту чи потрібна дата), бо від цього вибору залежить, чи зміна взагалі потрапить у конкретне замовлення.