MRP у Business Central: як працює планування потреби

Що таке MRP і навіщо він

Формально — планування потреби в матеріалах. Практично система відповідає на одне питання: що і коли треба замовити або виготовити, щоб вистачило.

Розрахунок бере три складові:

• Потреба: замовлення клієнтів, потреба виробництва, прогноз, страховий запас.
• Наявність: залишок на складах з урахуванням резервів.
• Очікуване: відкриті замовлення постачальникам і виробничі замовлення з датами.

Різниця між першим і сумою другого й третього — дефіцит. Система пропонує його покрити з урахуванням термінів постачання, мінімальних партій і кратності.

Кому це потрібно. Компанії з десятком позицій обійдуться точкою замовлення. MRP виправданий там, де позицій сотні, терміни різні, а частина потреби залежить від інших позицій — тобто у виробництві й складній дистрибуції.

Методи поповнення

Найважливіше налаштування картки. Метод визначає саму логіку розрахунку, а не його параметри.

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

Параметри, які визначають результат

Після методу — шість полів, які роблять розрахунок реалістичним або марним.

• Термін постачання. Головний параметр. Якщо в картці 14 днів, а фактично приходить за 25, план не спрацює тихо й щоразу.
• Страховий запас. Буфер на коливання попиту й затримки.
• Мінімальна партія й кратність. Умови постачальника. Без них система запропонує замовити 7 штук там, де продають коробками по 50.
• Період накопичення потреби. За скільки днів потреби об'єднуються в одне замовлення. Один день дає щоденні дрібні замовлення, тридцять — рідкі великі.
• Час оброблення — скільки часу займають ваші власні дії до розміщення замовлення.
• Основний постачальник — від нього беруться терміни й ціни.

Практична порада. Термін постачання варто ставити не номінальний із договору, а фактичний із історії надходжень. Порахувати середнє відхилення фактичної дати від підтвердженої по кожному постачальнику — робота на кілька годин, яка дає більше, ніж будь-яке інше налаштування планування.

Що відбувається під час розрахунку

Спрощено, по кроках. Це корисно розуміти, щоб читати результат.

1. Система збирає потребу за горизонтом планування.
2. Віднімає наявність і те, що вже очікується.
3. Визначає дефіцит по датах.
4. За методом поповнення формує пропозиції потрібного обсягу.
5. Відраховує назад від дати потреби на термін постачання — отримує дату розміщення.
6. Для виробничих позицій розкладає потребу на компоненти й повторює для кожного.

Крок 5 пояснює найчастіше питання: «чому пропозиція має дату в минулому». Це означає, що замовляти треба було вже вчора — потреба виникає раніше, ніж встигне прийти поставка. Система не помиляється, вона повідомляє про проблему.

Горизонт і частота розрахунку

Два параметри, які задають на старті й рідко переглядають, хоча вони сильно впливають на результат.

Горизонт планування має покривати найдовший термін постачання плюс запас. Якщо найдовше везуть 60 днів, горизонт у 30 днів гарантує, що система не побачить потреби вчасно. Занадто довгий горизонт теж шкодить: пропозиції на пів року вперед будуються на прогнозі, якому немає підстав вірити.

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

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

Чому пропозиції виглядають дивними

П'ять причин, які покривають майже всі випадки.

Разовий сплеск сприйнято за попит. Клієнт узяв річний обсяг однією поставкою — система вирішить, що це нова норма. Найчастіша причина надлишків.

Термін постачання нереальний. План будується на цифрі з картки, а не на фактичній.

Не задані мінімальні партії. Пропозиції на дробові кількості, які постачальник не прийме.

Залишки не відповідають дійсності. Планування рахує неіснуючий товар. Причини — чому залишки не сходяться.

Резерви не враховані. Товар фізично є, але зарезервований під інше замовлення.

Загальне правило: перш ніж міняти налаштування розрахунку, перевірте картку. Механізм майже завжди рахує правильно за наданими даними.

MRP і виробництво

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

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

Ширший контекст — виробництво в Business Central.

З чого почати

1. Візьміть двадцять позицій, які найчастіше створюють проблеми.
2. Перевірте по них фактичні терміни постачання за історією й порівняйте з картками.
3. Задайте методи поповнення за характером позиції, не однаково для всіх.
4. Заповніть мінімальні партії й кратність за умовами постачальників.
5. Прогоніть розрахунок і перегляньте пропозиції вручну, не приймаючи автоматично.
6. Розберіть кожну дивну пропозицію до причини — це і буде налаштування.
7. Розширюйте на решту номенклатури після того, як на двадцяти позиціях результат став передбачуваним.

Крок 6 і є основна робота. Як цей процес можна доповнити аналізом фактичних термінів і структури попиту — у статті про AI-агента для запасів.

Часті запитання