OEE часто внедряют быстро, а потом спорят о цифрах на планерке: «почему у нас 78%, если линия еле дышит?». Проблема обычно не в формуле, а в данных и дисциплине причин потерь. Если причины простоев собираются вручную «как получится», а структура потерь не привязана к действиям, OEE превращается в витринный KPI без управленческой пользы.
Ниже - практический подход: какие данные нужны, как правильно собирать причины простоев, как строить структуру потерь и как связать OEE с ежедневными действиями команды.
Короткий ответ
Полезный OEE начинается с трех вещей: достоверные статусы оборудования, единый классификатор потерь, регламент реакции по каждой группе потерь. Считать процент недостаточно - нужно разбирать, что съедает Availability, Performance и Quality, и кто конкретно устраняет корневую причину. Иначе OEE показывает «температуру по больнице», но не улучшает выпуск.
Формула OEE и где обычно начинается самообман
Классически:
OEE = Availability * Performance * Quality
Где: - Availability - потери времени (простои, переналадки, ожидания); - Performance - потери скорости (работает, но медленнее номинала); - Quality - потери качества (брак и переработка).
Самообман появляется, когда: - часть простоев не фиксируется или «прячется» в универсальную причину; - микростопы не учитываются; - номинальная скорость завышена или занижена; - брак учитывается не на том этапе.
Какие данные нужны, чтобы OEE был рабочим
1) Статусы оборудования в реальном времени
- run / stop / idle / fault / setup;
- переходы состояний с точным timestamp;
- длительность каждого состояния.
2) Счетчики выпуска
- total count, good count, reject count;
- привязка к партии/заказу/рецепту;
- фиксация переработки отдельно от первичного годного.
3) Скоростные данные
- фактическая скорость vs плановая/номинальная;
- признаки ограничения по сырью, персоналу, узкому месту;
- время в режиме «работает ниже целевой скорости».
4) Контекст производства
- смена, линия, продукт, операторская бригада;
- план/факт по заказу;
- сервисные события (чистка, смена оснастки, тест).
Принцип: минимум ручного ввода, максимум автоматической фиксации из АСУ ТП/SCADA/MES.
Корректный сбор причин простоев
Причина простоя должна фиксироваться не «когда вспомнили», а по регламенту: - автоматическое открытие события при переходе в stop/fault; - обязательная классификация причины при закрытии (или в лимит времени); - разделение первичной причины и вторичного эффекта; - контроль «прочее/другое» (доля не выше оговоренного порога).
Плохой и хороший подход
Плохо: 40% событий с причиной «прочее».
Хорошо: фиксированный справочник с 2-3 уровнями детализации и владельцем каждой ветки.
Структура потерь: как не утонуть в деталях
Рабочая структура обычно 3-уровневая:
Правило: детализация должна помогать действию, а не раздувать отчеты.
Связка OEE с действиями (главное)
Для каждой топ-потери должен быть: 1. владелец (роль, не «все вместе»); 2. срок устранения; 3. метрика проверки эффекта; 4. статус на ежедневном разборе.
Если этих четырех пунктов нет, OEE останется красивым отчетом без результата.
Типовые ошибки при внедрении OEE
- Считают только итоговый процент, не разбирая компоненты A/P/Q.
- Нет единого словаря причин, каждая смена пишет по-своему.
- Игнорируют микростопы, теряя значительную долю Performance-loss.
- Подгоняют «идеальную скорость», чтобы цифра выглядела лучше.
- Не связывают OEE с планом работ, поэтому причины повторяются.
- Слишком поздний цикл обратной связи (разбор раз в месяц вместо ежедневного).
Шаблон ежедневного разбора по OEE
Используйте на ежедневной сменной/утренней планерке (15-30 минут).
Блок 1. Факт за сутки/смену
- OEE общий и по линиям.
- Availability / Performance / Quality по каждой линии.
- Топ-3 потерь по времени и по деньгам.
Блок 2. Причины и подтверждение
- Проверка корректности классификации простоев.
- Доля «прочее» и событий без причины.
- Сверка с журналом аварий и ремонтов.
Блок 3. Решения на сегодня
- 3-5 действий с владельцем и сроком.
- Что закрываем до конца смены.
- Что уходит в недельный план (RCA/кайдзен/ТО).
Блок 4. Контроль эффекта
- Какие действия вчера дали снижение потерь.
- Какие не сработали и требуют пересмотра.
- Обновление статуса открытых инициатив.
Табличный формат (готовый шаблон)
KPI, которые стоит смотреть вместе с OEE
- доля простоев с подтвержденной причиной;
- доля «прочее»;
- MTBF/MTTR по критичным узлам;
- скорость закрытия action items;
- повторяемость одинаковых причин за 7/30 дней.
Это защищает от «косметического улучшения» OEE без реального прогресса.
Где уместен СТАБУР в контуре OEE
Качественный OEE невозможен без стабильного нижнего уровня данных: корректные статусы линий, единая семантика тегов и надежный сбор событий. Поэтому на практике успех OEE часто зависит от зрелости АСУ ТП-стека и стандартизации проектов. Для части российских предприятий это проще реализуется на платформенном подходе, в том числе с решениями СТАБУР.
Заключение
OEE становится полезным только тогда, когда каждая цифра ведет к действию. Достоверные данные, дисциплина причин потерь и ежедневный разбор с владельцами решений превращают метрику из «отчетной» в управленческую. Начинайте с прозрачности потерь и ритма принятия решений - и OEE начнет работать на выпуск, а не на презентации.
FAQ
Какой OEE считать «хорошим»?
Универсального числа нет. Важнее тренд и способность команды стабильно снижать потери.
Можно ли считать OEE без MES?
Можно, если есть надежный сбор статусов и счетчиков, плюс дисциплина причин простоев.
Что делать с большой долей «прочее»?
Пересмотреть классификатор и сделать обязательное уточнение причины в течение смены.
Как часто проводить разбор OEE?
Ежедневно для операционных действий и еженедельно для системных улучшений.
Что главное для старта?
Согласованный словарь причин потерь и автоматический сбор базовых статусов линии.