Дані для симуляційної моделі: звідки вони беруться і якими мають бути

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-11

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

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

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

Головне

• Симуляційна модель потребує продуктів і маршрутів, часів обробки, ресурсів, зупинок, замовлень і правил укомплектування персоналом; кожен елемент береться з системи, вимірювання або від експерта.
• Дані надходять із первинних джерел, таких як хронометражні дослідження та спостереження, а також із вторинних джерел, зокрема систем ERP, MES і CAD, та прогнозів.
• Типові прогалини: часи в ERP, задані наперед, відрізняються від фактичних; дубльовані записи; дані відстають від реальності; відсутній розкид значень.
• Вхідні дані мають бути достатньо якісними для питання: перевірте, які параметри найбільше змінюють результат, і докладайте зусиль саме там.
• Використовуйте розподіли та фактичні записи, а не лише середні значення, бо саме розкид створює час очікування, який ви хочете перевірити.

Дані для побудови симуляційної моделі: що потрібно моделі

Модель потоку лінії потребує шести видів вхідних даних. Цей перелік є нашим власним узагальненням поширеної практики, а не стандартом.

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

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

Звідки беруться вхідні дані для симуляції: збір даних на практиці

У статті Майї Берінг та її колег на Зимовій конференції з симуляцій 2018 джерела поділено на дві групи за попередніми роботами Андерса Скоу та його колег.

• Первинні дані збирають спеціально для дослідження: вимірювання, хронометражні дослідження та спостереження на лінії.
• Вторинні дані вже існують. До них належать зовнішні джерела, такі як галузеві стандарти та експерти предметної області, корпоративні бізнес-системи, зокрема ERP, MES, PDM і CAD, а також дані, специфічні для проєкту, наприклад прогнози обсягів виробництва.

Для менеджера з безперервного вдосконалення збір даних на практиці виглядає так. Система виконання виробництва зберігає фактичний час циклу, події зупинок і кількості по кожній станції. ERP містить замовлення, маршрути та планові часи. Система CAD або PDM зберігає структуру виробу. Графіки змін ведуть планування або HR. Часи переналагодження та реальний спосіб роботи операторів часто можна дізнатися лише шляхом спостереження та розмов із керівниками змін.

Чому даних часто недостатньо

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

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

Автори також зазначають, що ERP-системи роблять наголос на детермінованих значеннях, а не на стохастичних, тому часто бракує варіативності, яка потрібна для імітаційного моделювання. У другому випадку автоматизоване отримання даних дозволило уникнути п'яти з восьми викликів, які вони перелічують. Серед іншого, стаття рекомендує призначати відповідальних за дані серед функцій всередині компанії. Опитування Скууга, Перери та Йоганссона, опубліковане в Simulation Modelling Practice and Theory, показало, що близько 80 відсотків користувачів імітаційного моделювання досі покладаються на переважно ручні процедури підготовки вхідних даних.

Маршрут і специфікація матеріалів в імітаційній моделі

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

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

Наскільки якісними мають бути дані для імітаційного моделювання?

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

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

1. Категорія A: виміряно й перевірено. Використовуйте її для вхідних даних, які найбільше впливають на результат, наприклад для часу циклу на вузькому місці та шаблону зупинок перед ним.
2. Категорія B: взято із системи й перевірено на вибірці. Використовуйте її для вхідних даних із помірним впливом.
3. Категорія C: експертна оцінка. Використовуйте її для вхідних даних з незначним впливом і обов'язково запишіть припущення.

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

Приклад: маршрутний час проти фактичного часу

Це ілюстративний приклад із припущеними числами, а не виміряний кейс. Лінія випускає один виріб. Маршрут ERP передбачає 42 секунди на деталь на вузькому місці. MES показує медіанний фактичний час циклу 47 секунд за чотири тижні.

• Випуск за годину за маршрутним часом: 3 600 ÷ 42 = 85,7 деталі.
• Випуск за годину за фактичним часом: 3 600 ÷ 47 = 76,6 деталі.
• Маршрутизація завищує швидкість приблизно на 12 відсотків: 85,7 ÷ 76,6 ≈ 1,12. За 8-годинну зміну це about 686 проти 613 деталей, тобто різниця становить 73 деталі.

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

Та сама логіка стосується зупинок. Припустімо, MES фіксує сім зупинок тривалістю 2, 3, 3, 4, 5, 6 і 40 хвилин. Сума становить 63 хвилини, отже середнє дорівнює 9 хвилинам, тоді як медіана дорівнює 4 хвилинам. Модель із сталою зупинкою в 9 хвилин ніколи не показує зупинки в 40 хвилин, яка спустошує буфер, і показує більше середніх зупинок, ніж насправді є на лінії. Побудуйте графік зафіксованих тривалостей, розрахуйте їх розкид і використовуйте їх безпосередньо або статистичний розподіл, підігнаний під них. Оцініть його параметри за записами.

Робота з даними: план у шість кроків

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

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

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

Як може допомогти програмне забезпечення

Граф знань, що пов'язує продукти, кроки процесу та ресурси, може зменшити дублювання й суперечливі дані, адже кожен факт зберігається один раз. Polaris Designer від iFAKT є модулем iFAKT Polaris, який будує граф знань «продукт – процес – ресурс» (PPR) як єдине джерело правди про продукти, кроки процесу та ресурси. Він не замінює перевірку за фактичними часами, призначення власників чи валідацію моделі. Який би інструмент ви не використовували, запитайте, як він імпортує дані з вашої ERP і MES та як відстежуються зміни.

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

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