Данные для имитационной модели: откуда они берутся и каким должно быть их качество

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, а также данные, относящиеся к конкретному проекту, например прогнозы объёма производства.

Для менеджера по непрерывному совершенствованию сбор данных на практике выглядит так. В системе управления производственным исполнением (MES) хранятся фактические времена циклов, события остановок и количество продукции по каждой станции. В ERP хранятся заказы, маршруты и плановые времена. В системе CAD или PDM хранится структура изделия. Графики смен находятся у planning или 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 детали.
• Маршрутизация завышает темп на 85,7 ÷ 76,6 = примерно 12 процентов. За восьмичасовую смену это около 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 за последние четыре недели. Если они различаются, вы нашли первый пробел в данных для построения имитационной модели и знаете, с чего начать.