Отслеживание KPI в симуляции производства: честное сравнение сценариев

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

Отслеживание KPI в симуляции производства начинается с небольшого набора показателей, определённых так, как их определяет ваш завод. Узнайте, как запускать сценарии, читать результаты и составлять отчёты по ним.

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

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

Ключевые выводы

• Отслеживание KPI симуляции означает выбор нескольких показателей до построения модели и расчёт их точно так же, как их считает завод.
• ISO 22400-2 задаёт необходимую дисциплину: каждый KPI описывается своей формулой, элементами, временным поведением и единицей измерения.
• Один прогон симуляции — это одна выборка, поэтому используйте несколько повторов и отчитывайтесь о среднем значении с доверительным интервалом.
• Меняйте одну вещь в каждом сценарии, сравнивайте сценарии по одним и тем же определениям KPI и сначала проверьте базовый сценарий на реальном прошедшем периоде.
• Результаты симуляции не являются живыми данными, поэтому дашборд, который на них опирается, нужно обновлять после каждой серии прогонов и подписывать по сценариям.

Что такое отслеживание KPI в симуляции производства?

Модель симуляции выдаёт огромный объём сырых данных: каждую деталь, каждое ожидание, каждое состояние станка в смоделированном времени. Отслеживание KPI превращает эти данные в несколько чисел, которые можно сравнивать. Если симуляция производства отвечает на вопрос «что произойдёт, если мы это изменим?», то KPI показывают, насколько именно, в терминах, которые завод уже использует.

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

Решение в обоих случаях одно. Начинайте с решения, например: «Добавить вторую смену на сборочной линии или купить второй станок?», и спросите себя, какие числа заставят выбрать один вариант, а не другой. Это и будут ваши KPI.

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

Держите список коротким. Пяти-семи достаточно. Ниже приведены распространённые варианты, а то, какие из них важны, зависит от вашего вопроса:

1. Пропускная способность. Количество годных единиц продукции в час, смену или неделю.
2. Время выполнения (lead time). Сколько времени заказ или деталь проходят от запуска до завершения.
3. Незавершённое производство (WIP). Сколько материала находится в системе в данный момент. Часто оно меняется вместе со временем выполнения.
4. Загрузка ресурсов. Какую долю доступного времени заняты станки и люди. Смотрите на узкое место и на ресурс рядом с ним.
5. Время ожидания и длина очереди перед узким местом.
6. Своевременность поставок, если в модели учитываются сроки.
7. OEE, если ограничением являются потери на оборудовании.

Об OEE стоит говорить конкретно. Lean Enterprise Institute описывает общую эффективность оборудования как метрику всеобщего продуктивного обслуживания, которая перемножает коэффициенты доступности, производительности и качества, и отмечает, что обычно она учитывает шесть основных потерь: отказы, переналадки, мелкие остановки, снижение скорости, брак и переделку. OEE имеет смысл в симуляции только тогда, когда модель содержит эти потери: например, поведение при поломках, переналадки и процент брака. Если их нет, значение OEE из модели — это догадка с десятичной точкой. На многономенклатурной линии с длительной переналадкой OEE может также скрывать то, что определяет стоимость и срок поставки, поэтому его стоит дополнять временем выполнения заказа или показателем поставок в срок.

Не используйте KPI, на которые модель не может повлиять. Если ваши сценарии меняют график смен, оценка удовлетворённости клиентов в исследовании не имеет смысла.

Как определить KPI так, чтобы модель и производство говорили на одном языке?

Перед первым запуском составьте одностраничную карту KPI. Для каждого показателя укажите:

• название и вопрос, на который он отвечает,
• формулу и её элементы,
• временную базу, например на смену, на календарную неделю или на плановый час производства,
• единицу измерения,
• откуда на производстве берётся реальное значение,
• кто отвечает за определение.

Именно этой дисциплины придерживаются стандарты в данной области. Страница ISO по ISO 22400-2, which определяет ключевые показатели эффективности для управления производственными операциями, указывает, что каждый KPI описывается своей формулой и элементами, временным поведением, единицей измерения или размерностью, группой пользователей и производственной методикой, к которой он относится. Страница, которую я читал, описывает черновик второго издания, которое заменит версию 2014 года, поэтому перед ссылкой на стандарт проверьте действующую редакцию. Необязательно принимать весь стандарт, чтобы извлечь пользу из его подхода: одно точное определение на каждый KPI.

Большинство разногласий возникает из-за времени. Значение «доступности» меняется в зависимости от ответа на вопрос «доступно из чего?». В описании OEE от LEI простои из-за поломок и переналадок измеряются относительно запланированного времени, поэтому в вашей карте должно быть чётко определено запланированное время. Включает ли оно плановое техобслуживание? Перерывы? Смену, которая по календарю не рабочая? Решите это до построения модели, поскольку от этого зависит каждый результат.

Затем выполните проверку, которая придаёт карте ценность: рассчитайте те же KPI за реальный прошлый период по данным производства и сравните их с тем, что модель выдаёт при загрузке этого периода.

Как запускать сценарии и читать результаты?

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

1. Проверьте базовый сценарий. Запустите модель для известного вам периода и сравните KPI с реальностью. Если модель не воспроизводит прошлое в приемлемых пределах, исправьте модель, прежде чем тестировать какие-либо изменения.
2. Используйте репликации. Запускайте каждый сценарий несколько раз с независимыми потоками случайных чисел. В лекции MIT по планированию экспериментов с моделированием описано, как задавать число репликаций по целевой точности: продолжайте, пока доверительный интервал не станет достаточно узким относительно оценки. Там также отмечено, что при меньшем чем 30 числе репликаций для интервала используется распределение Стьюдента.
3. Учитывайте период разогрева. Для непрерывно работающего производства модель стартует пустой и нуждается во времени, чтобы выйти на нормальный режим. В той же лекции описано отбрасывание начальной части каждой репликации и упоминается метод Уэлча для выбора объёма отбрасываемых данных. Если ваш вопрос касается определённого периода, например одной партии заказов, запускайте модель в том состоянии, в котором находится производство на этот момент.
4. Меняйте одну вещь в каждом сценарии. Если сценарий B добавляет станок и одновременно меняет график смен и размер партии, вы не узнаете, какое из изменений что дало.
5. Указывайте диапазоны. «Пропускная способность вырастет на 4–9%» честнее, чем «вырастет на 6,5%». Если интервалы двух сценариев сильно перекрываются, прямо скажите, что данные не позволяют их различить.
6. Смотрите на весь поток. Прирост производительности на одной машине может переместить узкое место в другое место. Проверяйте загрузку и очереди по всему потоку, а не только на станции, которую вы изменили.

Ведите реестр сценариев: название сценария, что именно изменилось, допущения, количество повторов и дату. Без него через полгода никто не вспомнит, почему был выбран сценарий 7.

Как показывать KPI имитационного моделирования руководителям?

Руководителям нужно сравнение, а не сырые результаты. Хорошо работает простая страница: базовый сценарий и каждый сценарий рядом, для одних и тех же нескольких KPI, с диапазоном значений и примечанием о том, что меняет каждый сценарий.

В среде Microsoft распространённый вариант — загрузить таблицу результатов в Power BI. Каждая строка содержит сценарий, номер повтора, название KPI и значение, что позволяет построить сравнение и фильтровать данные по сценариям. Документация Microsoft по обновлению данных объясняет, что импортированные данные в семантической модели — это копия на определённый момент времени, поэтому для просмотра новых данных её нужно обновить. Для результатов моделирования это хорошо подходит: вы обновляете данные после пакета прогонов, а не раньше.

Из этого следуют два практических момента:

• Помечайте каждый визуальный элемент как результат сценария с датой последнего прогона. Прогнозные цифры рядом с живыми показателями производства провоцируют неверное прочтение.
• Позже, когда изменение уже внедрено, сравнивайте план и факт, используя те же определения KPI. Именно здесь лист KPI окупается.

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

Как поддерживать модель в актуальном состоянии со временем?

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

• Калибруйте заново. Сравнивайте KPI модели с фактическими KPI каждый квартал или после любого крупного изменения и корректируйте входные данные, если они расходятся.
• Назначьте владельца входных данных. Время цикла, время переналадки, поведение при отказах и сменные календари нуждаются в конкретном ответственном, который их обновляет. Относитесь к данным моделирования как к продукту, у которого есть сопровождающий.
• Учитывайте людей там, где это важно. Операторы влияют на результаты через отсутствия, навыки и разброс темпа работы. Моделировать усталость для этого не нужно: реалистичный разброс времени цикла и реальная укомплектованность по сменам дают большую часть эффекта. Спросите руководителей смен, правдоподобны ли допущения модели.
• Пересматривайте цели. Не переносите эталонный показатель с другого завода в модель, не проверив, подходит ли он к вашему ассортименту. Сначала используйте собственную базовую линию.

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

• Начинайте с дашборда. Сначала определите KPI и вопрос, на который должен отвечать дашборд.
• Слишком много KPI. Страницу с двадцатью цифрами никто не будет читать.
• Разные определения в модели и на производстве. Тогда никакое сравнение невозможно.
• Один прогон на сценарий. Случайность решит за вас, каким будет вывод.
• Пропуск проверки базовой линии. Если модель не воспроизводит прошлое, у её прогнозов нет основания.
• Изменение нескольких параметров в одном сценарии. Тогда вы не узнаете, что стало причиной.
• Выдача прогнозов за живые данные. Чётко помечайте результаты сценариев.
• Нет владельца входных данных модели. Устаревшие входные данные дают уверенные, но неверные ответы.

Где здесь Polaris

Для такого рода исследований iFAKT Polaris предлагает два модуля, на которые стоит обратить внимание. iFAKT описывает Polaris Simulator как инструмент, который виртуально проверяет производственную систему до принятия реальных решений: со сценариями мощности, укомплектованности и буферов. Он показывает узкие места и дисбаланс загрузки во времени. Polaris Analyzer предоставляет дашборды KPI по модулям и сравнивает плановые и фактические значения. Как и в случае с любым инструментом, проверьте, что определения KPI в нём совпадают с вашими, и сначала попробуйте его на одной линии.

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

• Иерархии KPI. Как значения по линии, смене, подразделению и заводу агрегируются, не пересчитываясь на каждом уровне.
• Источники данных для модели. Какие данные из ERP, с оборудования и ручные данные питают модель и как проверить их качество.
• Нормализация по площадкам. Как сравнивать площадки с разным уровнем автоматизации, не штрафуя заводы с высокой номенклатурной сложностью.
• Вариативность персонала в моделях. Какие эффекты операторов и смен стоит моделировать, а какие добавляют сложности без пользы.
• От плана к факту. Как сравнить выбранный сценарий с реальными KPI после запуска изменений.

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

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