📅 · 4 хв читання · Команда Meta Smart Factory
MRP відповідає на одне питання — що купити чи виготовити, скільки й до якого часу. У теорії просто, у таблицях — нестерпно. Ось як MRP працює насправді, де воно ламається на практиці та чим відрізняється від APS і SCP.
Планування потреби в матеріалах — найстаріша ідея у виробничому програмному забезпеченні й досі найбільш неправильно зрозуміла. У своїй суті вона робить майже механічну річ: бере те, що ви пообіцяли виготовити, розкладає це через специфікацію, віднімає те, що вже є на складі й уже замовлено, а решта — це те, що треба купити або виготовити. Усе інше в MRP — деталі поверх цього розрахунку.
Вхідних даних три, і якість кожного визначає, буде результат корисним чи відверто шкідливим. Головний виробничий графік каже, яка готова продукція потрібна й коли. Специфікація каже, з чого складається кожен виріб, рівень за рівнем. Облік запасів каже, що фізично є в наявності й що вже в дорозі. Помилка в будь-якому з трьох — і MRP упевнено видасть хибну відповідь у масштабі. Саме тому заводи зі слабкою дисципліною специфікацій часто вирішують, що MRP не працює, тоді як не працюють їхні дані.
Час виконання замовлення — те, що перетворює розрахунок з простої арифметики на прив’язаний до часу. Знання, що вам потрібно 400 одиниць компонента, не дає підстав діяти; знання, що вони потрібні на 12-му тижні, а постачальнику потрібно п’ять тижнів, каже замовити на 7-му. MRP іде назад крізь кожен рівень специфікації, застосовуючи термін кожної позиції, і формує графік замовлень на закупівлю та виробництво, а не список покупок. Саме цю частину електронні таблиці відтворюють погано, бо багаторівнева специфікація з різними термінами на кожному рівні — не той розрахунок, який хтось має робити вручну.
Класична вада — припущення про нескінченну потужність. Стандартний MRP каже, що вам потрібно і коли, але не питає, чи здатен ваш завод це виготовити у відведене вікно. Він спокійно поставить три замовлення на один верстат в один тиждень і не побачить проблеми, бо потужність ніколи не була частиною його моделі. Це не стільки дефект, скільки межа сфери застосування — і саме на цій межі підхоплює розширене планування та диспетчеризація.
Цю різницю варто озвучити точно, бо три абревіатури у вендорських матеріалах вживають як синоніми, а вони різні. MRP визначає потребу в матеріалах — що і коли. APS визначає виконуваний графік — який верстат, яка послідовність, з урахуванням обмеженої потужності, переналагоджень і обмежень. SCP розширює план назовні — на постачальників, закупівлі та дистрибуцію. Завод може працювати з самим лише MRP. Але завод із самим лише MRP зазвичай виявляє свої проблеми з потужністю в цеху, а не в плані.
Нервозність системи — практична проблема, яка дивує нових користувачів. Оскільки MRP перераховує весь ланцюг залежного попиту, одна дрібна зміна нагорі — клієнт зсунув замовлення на три дні раніше — каскадом породжує десятки змінених пропозицій на закупівлю кількома рівнями нижче. Без демпферів на кшталт часових меж планування, зафіксованих планових замовлень і розумного визначення розміру партій система генерує більше метушні, ніж відділ закупівель здатен переварити, — і його починають ігнорувати. Ігнорований результат MRP гірший за відсутність MRP, бо створює ілюзію контролю.
Політика розміру партії — там, де вступає практичне судження. Замовляти рівно стільки, скільки потрібно в кожному періоді, мінімізує запаси й максимізує трансакційні витрати та роздратування постачальника. Замовляти великими економічними партіями — навпаки. Реальні конфігурації змішані: партія в партію для дорогих, малосерійних позицій із довгим терміном постачання; фіксовані чи економічні обсяги замовлення для дешевого кріплення, яке ніхто не хоче перезамовляти щотижня. Універсально правильного налаштування не існує — саме тому це рішення про конфігурацію, а не значення за замовчуванням.
Сучасний MRP відрізняється від оригіналу 1970-х передусім тим, з чим він з’єднаний. Коли цифра запасів приходить із WMS, яка контролює комірки, а не з періодичного перерахунку, вихідні дані заслуговують на довіру. Коли фактичне споживання та брак повертаються наживо з MES, план відображає те, що сталося, а не те, що мало статися. Коли підтвердження постачальників надходять із шару SCP, картина вхідних постачань реальна. Сам розрахунок не змінився — змінилася надійність його вхідних даних, і саме це перетворює MRP з теоретичної вправи на робочий інструмент.
Для заводу, який зараз планує матеріали в Excel, чесна відправна точка — не вибір програмного забезпечення. Це точність специфікацій і точність обліку запасів, бо MRP лише підсилить ту дисципліну, яка у вас уже є. Заводи, що спершу виправляють ці дві речі, зазвичай отримують віддачу вже в першому циклі планування. Ті, що їх пропускають, зазвичай витрачають рік на звинувачення системи.
Обговорити це з нашими експертамиЦю різницю варто озвучити точно, бо три абревіатури у вендорських матеріалах вживають як синоніми, а вони різні. MRP визначає потребу в матеріалах — що і коли. APS визначає виконуваний графік — який верстат, яка послідовність, з урахуванням обмеженої потужності, переналагоджень і обмежень. SCP розширює план назовні — на постачальників, закупівлі та дистрибуцію. Завод може працювати з самим лише MRP. Але завод із самим лише MRP зазвичай виявляє свої проблеми з потужністю в цеху, а не в плані.
Нервозність — практична проблема, яка дивує нових користувачів. Оскільки MRP перераховує весь ланцюг залежного попиту, одна дрібна зміна нагорі — клієнт зсунув замовлення на три дні раніше — каскадом породжує десятки змінених пропозицій на закупівлю кількома рівнями нижче. Без демпферів на кшталт часових меж планування, зафіксованих планових замовлень і розумного визначення розміру партій система генерує більше метушні, ніж відділ закупівель здатен переварити, і його починають ігнорувати. Ігнорований результат MRP гірший за відсутність MRP, бо створює ілюзію контролю.
Політика розміру партії — там, де вступає практичне судження. Замовляти рівно стільки, скільки потрібно в кожному періоді, мінімізує запаси й максимізує трансакційні витрати та роздратування постачальника. Замовляти великими економічними партіями — навпаки. Реальні конфігурації змішані: партія в партію для дорогих, малосерійних позицій із довгим терміном постачання; фіксовані чи економічні обсяги замовлення для дешевого кріплення, яке ніхто не хоче перезамовляти щотижня. Універсально правильного налаштування не існує — саме тому це рішення про конфігурацію, а не значення за замовчуванням.