Програми для планування виробництва: від таблиці до APS-системи за чотири етапи

Майже кожен завод проходить ті самі чотири етапи планування. Усе починається з однієї тямущої людини та електронної таблиці, потім переходить в ERP-систему, далі до ERP-системи прикручують інструмент календарного планування, і врешті матеріали, потужності й цех працюють за одним спільним планом. Більшість заводів не обирають наступний етап самі. Їх штовхає туди зірвана поставка.

Програмне забезпечення для планування виробництва — це будь-яка система, яка вирішує, що виготовляти, коли, на якому ресурсі та з яких матеріалів, і перевіряє, чи ця відповідь справді здійсненна. Під це визначення підпадає багато чого: від добре побудованої електронної таблиці до повноцінної APS-системи (розширене планування та складання розкладу). Корисне запитання — не «який продукт найкращий?», а «на якому ми етапі і скільки це нам коштує?»

Чотири етапи програмного забезпечення для планування виробництва

Етап 1: електронна таблиця. Один планувальник веде робочу книгу, де замовлення — у рядках, а тижні — у стовпцях. Це швидко, гнучко й безкоштовно. Ламається, коли завод виростає більше, ніж може вмістити одна голова. У статті планування виробництва в Excel наведено сім ознак того, що таблиця перестала працювати.

Етап 2: ERP-система. Замовлення, запаси та специфікації переїжджають в облікову систему, і планування потреб у матеріалах (MRP) починає розраховувати, що закуповувати. Дані стають чистішими. Але більшість ERP-систем планують із фіксованими термінами виконання і вважають, що потужність кожної машини безмежна. Саме тому ERP-система вважає, що кожне замовлення триває 10 днів, хоча в цеху знають краще.

Етап 3: ERP-система плюс APS-система. Інструмент календарного планування читає замовлення з ERP-системи та вибудовує їхню послідовність на реальних машинах із реальними календарями. Тепер видно, яке замовлення коли завершиться. Слабке місце — стик двох систем: нічні вивантаження, дві версії правди, матеріали плануються в одному місці, а потужності — в іншому.

Етап 4: один спільний план. Замовлення клієнтів створюють виробничий попит, MRP-розрахунок і перевірка потужностей працюють на тих самих даних, розклад показує результат, а підтвердження з цеху оновлюють запаси й хід виконання. Коли клієнт переносить дату, планувальник бачить вплив на матеріали й обладнання в одному місці.

Це схоже на перехід від паперового настінного календаря до спільного онлайн-календаря. Паперовий цілком годиться для сімʼї з трьох людей. А команді з сорока потрібен календар, який попередить, коли двоє забронюють ту саму переговорну.

Приклад: один тиждень, три етапи

Ваша лінія екструзії працює у три зміни пʼять днів на тиждень: 3 × 8 × 5 = 120 годин. Планове технічне обслуговування забирає 8 годин, тож доступно 112 годин. Відділ продажів бере на цей тиждень три замовлення: на 38, 46 і 52 години роботи лінії. Сумарне завантаження — 136 годин.

• В електронній таблиці число 136 стоїть у клітинці. Якщо ніхто не написав формулу, що порівнює його зі 112, ніхто нічого не помітить.
• В ERP-системі кожне замовлення отримує стандартний термін виконання 10 днів, і всі три дати виглядають нормально. ERP-система так і не спитала, скільки годин має лінія.
• В APS-системі або в спільному плані лінія перевантажена на 24 години. За 24 робочих годин на добу це цілий день. Третє замовлення завершується в понеділок замість пʼятниці — і ви дізнаєтеся про це в день, коли його приймаєте, а не в день, коли воно запізнилося з відвантаженням.

Ті самі дані — три різні відповіді. Уся різниця лише в тому, чи перевіряє програма потужності.

Сценарій демонстрації для будь-якого постачальника

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

1. Завантажте реальний тиждень. Візьміть замовлення минулого місяця для вашого найзавантаженішого ресурсу. Чи показує інструмент перевантаження?
2. Додайте термінове замовлення. Які замовлення зсуваються і наскільки? Чи видно чому?
3. Вимкніть машину. Заблокуйте 8 годин під поломку. Розклад перебудовується сам, чи хтось вручну перетягує смуги?
4. Створіть дефіцит. Приберіть компонент із запасу. Чи повʼязує інструмент дефіцит із замовленням клієнта, якому він шкодить?
5. Підтвердьте виробництво. Позначте 70 % замовлення як виконані, а 5 % — як брак. Що оновлюється в плані?

Якщо постачальник не може виконати це з вашими даними за двогодинну сесію, підписаний контракт цього не виправить. Чому кроки 1 і 3 перевіряють різні речі, пояснено у статті планування виробництва та календарне планування: у чому різниця.

Міф: «Краще планування — це заміна ERP-системи»

Майже ніколи. ERP-система добре робить те, для чого її створено: фінанси, документи закупівель, оцінку запасів, облік замовлень. Чого їй зазвичай бракує — це обмежених потужностей і швидкого способу перевіряти сценарії. Більшість заводів на етапі 3 або 4 зберігають свою ERP-систему і підключають до неї шар планування. Справжня робота — домовитися, яка система володіє якими даними: номенклатурою, замовленнями, запасами, підтвердженнями.

Коли електронної таблиці ще достатньо

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

Де тут місце штучному інтелекту

Асистенти на основі штучного інтелекту (ШІ) тепер зʼявляються на кожній демонстрації систем планування. Вони можуть бути корисними, але лише поверх даних етапу 4. Мовна модель не скаже, які замовлення затримає поломка, якщо вона не може прочитати розклад і результати MRP-розрахунку. Як виглядає добра відповідь, показано у статті ШІ-агенти у виробництві.

Як це виглядає у factory.online

У платформі factory.online наведений вище приклад працює на одному наборі даних. Замовлення клієнтів створюють виробничий попит, MRP-розрахунок перевіряє матеріали через багаторівневі специфікації, укрупнене планування потужностей (RCCP) і календарне планування з урахуванням обмежених потужностей перевіряють години лінії, а діаграма Ганта показує, що третє замовлення потрапляє на понеділок. Планувальник може скопіювати план у сценарій, спробувати перенести 38-годинне замовлення на інший тиждень і порівняти варіанти, перш ніж щось змінювати в робочому плані. Інтеграції з SAP і Dynamics 365 дозволяють ERP-системі залишатися обліковою системою.

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