Симуляція виробництва для збоїв і змін асортиментного пулу

Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.

By Mirko Peters · 2026-11-12

Симуляція збоїв у виробництві: перевірте поломки, відсутність персоналу, затримку матеріалів і зміни товарного асортименту в моделі, перш ніж вони вдарять по вашій лінії. Практичний посібник.

Automatically translated with AI from the original post. Read the English original

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

Головне

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

Що симуляція може показати щодо збою?

Збій — це будь-що, що робить план хибним: менша потужність, ніж планувалося, матеріал, якого немає, або попит, який виглядає інакше, ніж прогноз. План відповідає на питання «що має статися». Симуляція фабрики відповідає на питання «що станеться, якщо це піде не так».

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

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

Вона також допомагає побачити, що вузьке місце може переміщуватися. Вступ Lean Enterprise Institute до теорії обмежень говорить, що після дій над обмеженням потрібно повторно оцінити, чи не перемістилося воно в іншу частину системи. Збій робить те саме, але без вашого запиту. Спочатку запустіть це в моделі.

Які збої варто симулювати?

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

Типові кандидати:

• Зупинки верстатів. Змоделюйте, як часто вони стаються і скільки тривають ремонти. Середні значення приховують довгі ремонти, а саме вони найбільше шкодять. Якщо у журналі технічного обслуговування є реальні тривалості зупинок, використовуйте їхній розкид, а не лише середнє.
• Персонал. Відсутні працівники, брак потрібного навику на одній зміні, ліміти понаднормових.
• Матеріали. Пізня поставка, недопоставка, карантин на вхідній партії через якість.
• Втрати якості. Брак або доопрацювання, через які деталі повертаються на попередню станцію.
• Термінові замовлення. Терміновий замовлення, яке обганяє чергу й вимагає додаткових переналаштувань.
• Зміни попиту. Інша частка варіантів або різкий стрибок обсягів.

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

Як змоделювати зміну продуктового міксу?

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

Стаття з Winter Simulation Conference про інтерактивне моделювання виробництва показує цей ефект на дільниці пакетних печей. Вироби можуть потрапляти в одну партію лише за певними правилами поєднання, тож порядок виробів впливає на використання печей, а вузьке місце зміщується разом із міксом. Це стара стаття і окремий випадок, але висновок справджується для більшості спільних ресурсів.

Ось як можна пройти цей шлях:

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

Приклад: орієнтовна перевірка на льоту (гіпотетичні числа)

Цей приклад вигаданий, щоб показати логіку. Це не виміряний результат.

На дільниці є один фрезерний верстат. Варіант A займає там 6 хвилин, варіант B — 10 хвилин. Сьогодні 70% замовлень припадає на A і 30% на B. Середній час на одиницю становить 0,7 × 6 + 0,3 × 10 = 7,2 хвилини. За зміну тривалістю 450 хвилин фрезерний верстат може виготовити приблизно 62 одиниці.

Тепер мікс змінюється до 50% A і 50% B. Середній час стає 8 хвилин, і за ту саму зміну виходить приблизно 56 одиниць. Це близько 10% меншого випуску лише через зміну міксу, без жодного простою.

Додамо зупинку на 45 хвилин. Верстату тепер доступно 405 хвилин, і за зміну виходить приблизно 50 одиниць. Дві, на вигляд нешкідливі, зміни відняли близько п'ятої частини випуску.

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

Які дані потрібні для сценаріїв?

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

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

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

Як проводити дослідження збоїв?

Кроки такі самі, як у будь-якому проєкті симуляції, з кількома моментами, які для збоїв важать більше.

1. Запишіть питання. Наприклад: "Якщо млин стоїть цілу зміну, які замовлення не встигнуть до дати і яка найдешевша реакція?"
2. Перевірте базовий сценарій. Порівняйте результати моделі з минулим періодом. Якщо розбіжність велика, спершу виправте дані, а вже потім додавайте хоча б одне збурення.
3. Визначте невеликий набір сценаріїв. Достатньо трьох-п'яти. Назвіть кожен і запишіть, що змінюється і на скільки часу.
4. Запускайте кожен сценарій кілька разів. Поломки відбуваються випадково, тож один запуск може виглядати краще або гірше за звичайний результат. Порівнюйте діапазон результатів, а не одне число.
5. Тестуйте реакції. Понаднормові, перенесення роботи на іншу машину, зміна послідовності, використання запасів. Дослідження збоїв без варіантів реагування показує лише те, що щось піде не так.
6. Узгодьте правило прийняття рішення. Перед запуском визначте, який результат змусить вас діяти. Інакше цифри просто обговорюватимуть.

Зберігайте сценарії у короткому списку, який можна повторно запустити, коли процес зміниться. Бібліотека сценаріїв цінніша за будь-яке окреме дослідження.

Де тут інструменти Microsoft?

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

Для відображення результатів Power BI добре підходить для порівняння сценаріїв поряд. Microsoft Learn також описує параметри «що, якщо»: змінну, яку користувач звіту змінює за допомогою слайсера, після чого звіт перераховується. Це зручно для простої арифметики, як у прикладі вище, наприклад коли змінюєте частку асортименту і бачите, як змінюється показник потужності. Microsoft зазначає, що ці параметри призначені для мір у візуалізаціях. Вони не імітують черги, тож не плутайте повзунок «що, якщо» із симуляцією.

Типові помилки

• Симуляція всього підряд. Забагато сценаріїв робить модель повільною, а результати важкими для пояснення.
• Використання лише середнього часу ремонту. Найбільшу шкоду завдають довгі простої.
• Перевірка лише кінцевого стану зміни асортименту. Вузьке місце часто переміщується по ходу процесу.
• Пропуск перевірки базового сценарію. Якщо модель не може відтворити минулий місяць, її результати щодо збоїв є припущеннями.
• Довіра одному запуску. За наявності випадкових подій один запуск може ввести в оману.
• Забування про людей. Відсутність працівників, навички та обмеження понаднормових мають бути в моделі, коли збій пов'язаний із персоналом.
• Створення разового проєкту. Модель, яку ніхто не оновлює після наступної зміни процесу, застаріває за кілька місяців.

Де тут Polaris

Якщо ваші питання стосуються потужності, персоналу, буферів або асортименту, варто розглянути iFAKT Polaris. iFAKT описує Polaris як ШІ плюс цифровий двійник виробництва, що поєднує дані ERP з цифровим двійником виробничого процесу. Модуль Polaris Simulator тестує виробничу систему віртуально, зокрема сценарії потужності, персоналу і буферів, а також динамічний асортимент на спільних ресурсах. Модуль Polaris Optimizer виявляє вузькі місця і, коли виникають збої, аналізує їхній вплив і перeоптимізує план. Чи підійде він, залежить від ваших даних і питання, тож спершу випробуйте його на одному вузькому кейсі.

Пов'язані теми для вивчення

• Живі дані для моделі. Цифровий двійник тримає модель пов'язаною з виробництвом. Спершу вирішіть, чи потрібен вашому рішенню живий потік даних, чи достатньо хорошої моделі.
• Моделювання реакції людей. Затримки реакції та зміни змін впливають на тривалість збою, тож додавайте їх, коли персонал є частиною питання.
• Відновлення та перезапуск. Після завершення збою на лінію обрушується накопичене відставання. Змоделюйте перезапуск, включно з обмеженнями понаднормових.
• Замикання циклу з плануванням. Щойно збій стався, графік доведеться змінити. Подумайте, як результат симуляції передається в перепланування.

Наступний крок

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