Имитационное моделирование производства при сбоях и изменении товарного микса

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 в теорию ограничений утверждает, что после воздействия на ограничение нужно повторно оценить, не переместилось ли оно в другую часть системы. Сбой делает то же самое без вашего разрешения. Сначала проиграйте это в модели.

Какие сбои стоит моделировать?

Не все. Начните с короткого списка и выбирайте по двум вопросам: как часто это происходит и сколько это стоит, когда происходит?

Типичные кандидаты:

• Остановки станков. Смоделируйте частоту остановок и длительность ремонтов. Средние значения скрывают долгие ремонты, а именно они наносят наибольший ущерб. Если в журнале технического обслуживания есть реальные длительности остановок, используйте их разброс, а не только среднее значение.
• Персонал. Отсутствие сотрудников, нехватка нужного навыка на одной смене, ограничения на сверхурочную работу.
• Материалы. Поздняя поставка, недопоставка, карантин входящей партии из-за качества.
• Потери качества. Брак или доработка, из-за которых детали возвращаются на предыдущую операцию.
• Срочные заказы. Срочный заказ, который опережает очередь и вызывает дополнительные переналадки.
• Сдвиги спроса. Другая доля вариантов или резкий скачок объёма.

Чтобы ранжировать эти сбои, опирайтесь на собственные данные. Посмотрите журнал простоев за прошлый год, сменные отчёты и список опоздавших заказов. Если сбой повторяется каждый месяц, смоделируйте его. Если он случился один раз за пять лет, запишите его и пока не включайте в модель.

Как смоделировать изменение товарной структуры?

Товарная структура — это доля каждого варианта в потоке заказов. Она важна, потому что варианты редко занимают общие станки одинаково долго. Когда структура меняется, нагрузка на каждый ресурс тоже меняется, даже если общее количество единиц остаётся прежним.

В статье с 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 единиц. Два безобидных на вид изменения отняли примерно пятую часть выпуска.

Этот расчёт — хорошая первая проверка, и делать его стоит до построения любой модели. Чего он не покажет, так это очередей, переналадок, правил формирования партий, случайных остановок и каскадного эффекта на следующей операции. Именно это и добавляет симуляция.

Какие данные нужны для сценариев?

Сценарии сбоев требуют нескольких данных, которых может не быть в обычной модели. Проверьте этот список, прежде чем обещать результаты.

• История остановок по каждому станку: как часто он останавливается и how долго длится каждая остановка, по журналу обслуживания или простоев.
• Рабочие календари и навыки: кто может работать на каком участке и что происходит при укороченной смене.
• Время наладки и переналадок между вариантами, а не только время обработки.
• Данные о заказах и сроках отгрузки, чтобы видеть, какие заказы срываются, а не только то, что что-то сорвалось.
• Правила, которым линия реально следует сегодня: правила очерёдности, ограничения на сверхурочные, условия перехода задания на другой станок.

Если какой-то строки не хватает, укажите это в описании сценария. Результат, построенный на предположительной длительности остановки, — это догадка в красивой диаграмме. Попросите команду линии проверить цифры. Они часто за две минуты скажут, какая из них неверна.

Как проводить исследование сбоев?

Шаги те же, что и в любом проекте моделирования, но для сбоев несколько моментов важнее.

1. Сформулируйте вопрос. Например: «Если цех стоит целую смену, какие заказы срываются и какой ответ самый дешёвый?»
2. Проверьте базовую линию. Сравните результаты модели с прошлым периодом. Если расхождение велико, исправьте данные, прежде чем добавлять хоть одно нарушение.
3. Определите небольшой набор сценариев. Трёх-пяти достаточно. Назовите каждый сценарий и запишите, что меняется и на какой срок.
4. Запускайте каждый сценарий несколько раз. Поломки случайны, поэтому один прогон может выглядеть лучше или хуже обычного. Сравнивайте диапазон результатов, а не одно число.
5. Проверьте варианты реагирования. Сверхурочные работы, перенос работ на другой станок, изменение последовательности, использование запасов. Исследование сбоев без вариантов реагирования показывает только то, что things go wrong, то есть что проблемы случаются.
6. Согласуйте правило принятия решения. До запуска решите, какой результат заставит вас действовать. Иначе цифры просто будут обсуждаться.

Храните сценарии в коротком списке, который можно перезапустить при изменении процесса. Библиотека сценариев ценнее любого отдельного исследования.

Где здесь инструменты Microsoft?

Обычно ERP-система хранит маршруты, спецификации и производственные календари. Поэтому она естественный источник базовых данных для модели. Сама модель, как правило, реализуется отдельным программным обеспечением.

Для визуализации результатов Power BI хорошо подходит для сравнения сценариев бок о бок. В документации Microsoft Learn также описаны параметры «что если»: настраиваемая переменная, которую зритель отчёта меняет с помощью слайсера, после чего отчёт пересчитывается. Это полезно для простой арифметики, как в примере выше, например для изменения доли в ассортименте и наблюдения за изменением показателя мощности. Microsoft указывает, что такие параметры предназначены для расчётных показателей в визуализациях. Они не моделируют очереди, поэтому не принимайте ползунок «что если» за симуляцию.

Распространённые ошибки

• Моделирование всего подряд. Слишком много сценариев делают модель медленной, а результаты трудно объяснимыми.
• Использование только средних времён ремонта. Основной ущерб наносят длинные простои.
• Проверка только конечного состояния изменения ассортимента. Узкое место часто смещается по ходу процесса.
• Пропуск проверки базовой линии. Если модель не может воспроизвести прошлый месяц, её результаты по сбоям — это догадки.
• Доверие одному прогону. При случайных событиях один прогон может ввести в заблуждение.
• Забытые люди. Отсутствия, навыки и ограничения по сверхурочным должны входить в модель, если сбой связан с укомплектованностью персоналом.
• Разовая разработка. Модель, которую никто не обновляет после следующего изменения процесса, устаревает через несколько месяцев.

Где здесь Polaris

Если ваши вопросы касаются мощности, укомплектованности персоналом, буферов или структуры выпуска, стоит рассмотреть iFAKT Polaris. iFAKT описывает Polaris как ИИ плюс цифровой двойник производства, объединяющий данные ERP с цифровым двойником производства. Модуль Polaris Simulator виртуально тестирует производственную систему, включая сценарии мощности, персонала и буферов, а также динамической структуры выпуска на общих ресурсах. Модуль Polaris Optimizer выявляет узкие места и при сбоях анализирует их влияние и переоптимизирует план. Подойдёт ли решение, зависит от ваших данных и вашего вопроса, поэтому сначала проверьте его на одном узком кейсе.

Смежные темы для изучения

• Питание модели живыми данными. Цифровой двойник поддерживает связь модели с производством. Сначала решите, нужен ли вашему решению живой поток данных или достаточно хорошей модели.
• Моделирование человеческой реакции. Задержки реакции и смены influence на то, как долго длится сбой, поэтому учитывайте их, когда в вопросе речь идёт о персонале.
• Восстановление и перезапуск. После окончания сбоя накопившийся объём работ обрушивается на линию. Смоделируйте перезапуск, включая ограничения по сверхурочным.
• Замыкание контура с планированием. Как только сбой становится реальностью, график нужно менять. Продумайте, как результат симуляции попадает в перепланирование.

Следующий шаг

Сбои в производственной симуляции легче всего разбирать, если начать с собственного журнала простоев. Выберите один сбой, который обошёлся вам дороже всего в прошлом году, опишите его одним предложением с указанием длительности и затронутого ресурса и проверьте в модели, пусть даже грубой, до следующего совещания по планированию.