Производство редко страдает от нехватки данных — чаще от их разобщенности. Когда показатели простоев, скорости и качества попадают в разные системы, руководитель видит лишь обрывки информации. В итоге решения принимаются по фрагментам, а не на основе цельной картины. OEE (Overall Equipment Effectiveness) закрывает этот разрыв: сводит эффективность оборудования в один показатель через три компонента — доступность (Availability), производительность (Performance) и качество (Quality). В статье разберем, как выстроить аналитику по ключевым метрикам, чтобы рост эффективности был управляемым, а не случайным.
Что такое OEE
OEE — интегральный KPI эффективности оборудования. Он показывает, какая доля планового производственного времени превращается в выпуск годной продукции с нормативной скоростью. OEE показывает, что потери есть и в каком классе — простои, скорость или качество. Но почему именно так происходит, он не объясняет. Чтобы найти причину, нужны данные: что случилось с оборудованием, сколько времени оно должно было работать, почему остановилось и какую продукцию считать годной.
ГОСТ Р ИСО 22400-2-2019 (актуализированная версия, заменила издание 2016 года) описывает OEE как произведение трех составляющих:
OEE = A × P × Q
Здесь A — доступность (Availability), P — производительность (Performance), Q — качество (Quality). ISO 22400-2 использует термин Effectiveness для компоненты, которую на производстве называют Performance.
Три компонента OEE
A (Availability) — доля планового времени, когда оборудование работало. Плановые остановы из расчета исключают.
P (Performance) — отношение фактического темпа к идеальному. Потери возникают из-за микростопов и работы ниже нормативной скорости (ideal cycle time по номенклатуре).
Q (Quality) — доля годной продукции в общем выпуске. Правило «что считать годным» фиксируют до старта.
Что дает OEE
Видимость потерь в разрезе A/P/Q
OEE — метрика, а не система. Практическую пользу дает контур учета и мониторинга, который собирает события, счетчики и данные о качестве, а затем считает A, P и Q. Для этого строят контур из трех элементов.
- Первый — сбор данных: состояния оборудования, счетчики выпуска, время цикла, признаки качества. Оператор и диспетчер видят текущую картину.
- Второй — сменные и суточные дашборды для мастера и руководства с разбором потерь по A/P/Q.
- Третий — алерты. Система срабатывает, когда параметры выходят за заданные границы: длительный простой без причины, рост микростопов, снижение скорости, всплеск брака. Это сокращает время реакции по сравнению с ежедневным отчетом.
Дисциплина данных
Цифровой контур фиксирует, кто, когда и что изменил. Это снижает риск правок задним числом и помогает быстро найти источник аномалии — лаборатория, интеграция или ручной ввод.
Например, лаборатория передала влажность сырья 312%. Система сразу отметила значение как аномальное. Оказалось, что сотрудник ввел данные в неправильных единицах. Без аудит-лога эта цифра ушла бы в сменный отчет, и мастер принял бы решение на основе неверных данных.
Меньше ошибок в техпроцессе
Там, где операторы работают по бумажным техкартам и вручную переносят параметры, риск ошибки высок. Практика — перевести техкарты и рецептуры в электронный вид, формировать на их основе сменное задание и передавать параметры в АСУ ТП как управляющее задание. Это снижает простои из-за ошибок операторов и потери качества.
Обоснование ремонтов и переход к предиктиву
OEE не делает предиктивную аналитику сам по себе. Но история по событиям, простоям, скорости и браку дает базу для обоснования ремонтов, корректировки графиков ТОиР и выявления трендов по логистике и сырью.
OEE — индикатор, а не цель
OEE работает как температура на термометре. Если у человека 39°C, понятно, что что-то не так. Но что именно — грипп, ангина или воспаление — термометр не скажет. Нужно смотреть глубже.
Так же и с OEE. Показатель упал с 72% до 65% — сигнал, что стало хуже. Но причина может быть разной: оборудование чаще ломалось, линия работала медленнее нормы или вырос брак.
Дональд Уилер, специалист по статистическому управлению процессами, описывал эту проблему так: составной показатель смешивает несмешиваемое. Рост OEE с 65% до 72% может означать что угодно — стало меньше поломок, операторы начали занижать нормативную скорость или ОТК стал мягче принимать продукцию. Внешне — улучшение, внутри — ничего не изменилось или стало хуже.
Поэтому OEE — верхний индикатор. Чтобы реально снижать потери, смотрят на составляющие: где именно упала доступность, производительность или качество, строят Pareto причин и разбирают конкретные потери. Когда OEE становится целью — люди начинают его «рисовать»: корректируют нормативы, переклассифицируют простои, закрывают глаза на брак.
OEE на примере: одна смена на горячем прокатном стане
Смена длится 8 часов, то есть 480 минут. Из них 30 минут — плановый останов на передачу смены и регламентное обслуживание. Плановое производственное время (Planned Production Time, PPT) = 450 минут.
Доступность (A). За смену три внеплановых простоя: поломка валка — 35 минут, ожидание слябов из нагревательной печи — 20 минут, аварийная замена проводки — 15 минут. Итого внеплановый простой 70 минут. Время прокатки (Run Time) = 450 − 70 = 380 минут. A = 380 / 450 = 84,4%.
Производительность (P). Нормативная скорость стана — 45 т/ч. За 380 минут прокатки (6,33 ч) при нормативном темпе стан должен прокатать 45 × 6,33 = 285 т. Фактически прокатали 240 т: на части рулонов температура металла ушла ниже нормы, стан снижал скорость, чтобы не допустить трещин. P = 240 / 285 = 84,2%.
Качество (Q). Из 240 т проката 220 т прошли контроль с первого раза. 12 т отправили на правку (передел), 8 т списали в брак. Q = 220 / 240 = 91,7%.
Итого OEE = 0,844 × 0,842 × 0,917 = 65,2%.
Перевод в деньги (допущение: считаем потери как недовыпуск годного в смену по цене продукции). При нормативной скорости 45 т/ч за 450 минут PPT стан мог прокатать 45 × 7,5 = 337,5 т. Годного с первого раза получили 220 т. Потери — 117,5 т за смену. При цене 45 000 ₽/т это 117,5 × 45 000 = 5,29 млн ₽ за смену. За месяц при 22 сменах — 116,3 млн ₽.
Потери
- Потери доступности: 70 минут простоя = 1,167 ч × 45 т/ч = 52,5 т (≈ 2,36 млн ₽).
- Потери скорости: 285 − 240 = 45 т (≈ 2,03 млн ₽).
- Потери качества (брак + передел в этой смене): 12 + 8 = 20 т (0,9 млн ₽).
Подготовка к внедрению
1. Организационная подготовка
До старта пилота нужно договориться о процессах и ответственности. Иначе автоматизация закрепит разночтения: один мастер считает простоем одно, другой — другое, цифры будут несопоставимы.
Минимум для старта:
- Граница пилота — станок, линия или участок с понятными потоками.
- Владельцы данных: мастер (простои и причины), технолог (нормативы и режимы), ОТК (правила годности), ремонт и энергетики (отказы и ТОиР), ИТ/АСУ ТП (источники данных).
- Регламент учета — как фиксируют простои, качество и выпуск, кто и когда вносит причины.
- Единые определения терминов.
2. Данные для старта пилота
Временная модель (для Availability)
Согласуйте и закрепите:
- календарь: смены, окна регламентов, простои по графику;
- что считается плановым временем производства (Planned Production Time) и как его получаете из графика;
- что относите к плановым остановам (ТОиР по графику, плановые переналадки и т. п.);
- что относите к внеплановым (аварии, ожидание сырья/персонала, сбои снабжения, незапланированные переналадки).
Учет выпуска и качества (для Quality)
Разведите и зафиксируйте правила:
- Total — все произведенное (включая брак/передел);
- Good — годное с первого раза (FPY-база);
- Rework — передел (и как учитываете повторный выпуск);
- Scrap — окончательный брак/отход.
Обязательно определите момент и единицу учета: штуки/тонны/партии, где проверяете качество (на выходе линии, после лаборатории, после упаковки).
Норматив скорости / идеальный цикл (для Performance)
Нужны нормативы по номенклатуре/рецепту/режиму:
- идеальная скорость (шт/час) или норматив времени цикла (Ideal Cycle Time);
- условия, при которых норматив применим (режим, сырье, оснастка).
Типичная ошибка — занижать идеальную скорость (или, то же самое, завышать идеальное время цикла). Это искусственно улучшает Performance и OEE, но не отражает потери скорости.
Справочник причин простоев
Нужен классификатор и дисциплина кодирования:
- кодов мало, но они покрывают 80% потерь;
- детализируете сначала самые дорогие причины (Pareto);
- правило «нет причины — нет данных»: доля простоев с причиной должна расти, иначе анализ не работает.
3. ИТ-контур и оборудование
Контур OEE обычно строится в три слоя.
Стандарт ISA-95 (IEC 62264) делит архитектуру на уровни:
- управление и диспетчеризация (PLC/SCADA/HMI),
- MES и управление производственными операциями,
- ERP. ISA-95 формализует интерфейсы между уровнями 3 и 4 и снижает разрывы в данных.
Для обмена в цехе используют OPC UA — протокол защищенного подключения разнородного оборудования. На практике рядом работают и Modbus, Profibus, Profinet — их приводят к единой модели данных на уровне MES или историка.
4. KPI на период внедрения
На пилоте OEE — верхний индикатор. Управляют драйверами потерь. Минимальный набор:
- Доля и длительность внеплановых простоев.
- Время переналадки (setup time) и его разбивка.
- Микростопы: количество в час и суммарное время.
- FPY (First Pass Yield).
- Доля scrap и rework.
- MTBF (Mean Time Between Failures) и MTTR (Mean Time To Repair) — при корректном учете отказов.
- Дисциплина регистрации: доля простоев с указанной причиной и доля выпуска с качественным статусом.
Пошаговое внедрение OEE
1. Диагностика и выбор пилота
Выберите одно оборудование, одну линию или одну производственную ячейку, где потери дорогие и это можно подтвердить фактами.
Зафиксируйте границы учета: объект (что считают — станок, линия, участок); период и календарь (смены, плановые остановы, окна регламентов); Planned Production Time — что входит в плановое производственное время; что относят к плановым и внеплановым остановам.
2. Метрики и классификация потерь
На старте используйте крупные категории и единый справочник причин. Каркас — Six Big Losses (методология TPM, Сэйити Накадзима):
• Breakdowns — аварийные простои и поломки.
• Setup & Adjustments — переналадки и настройки.
• Idling & Minor Stops — микростопы и кратковременные остановы.
• Reduced Speed — снижение скорости относительно норматива.
• Process Defects — дефекты в процессе (брак, передел).
• Reduced Yield / Startup — потери запуска (разгон, вывод режима, пусковой брак).
• Setup & Adjustments — переналадки и настройки.
• Idling & Minor Stops — микростопы и кратковременные остановы.
• Reduced Speed — снижение скорости относительно норматива.
• Process Defects — дефекты в процессе (брак, передел).
• Reduced Yield / Startup — потери запуска (разгон, вывод режима, пусковой брак).
Детализацию ведите по Pareto: сначала кодируйте и дробите самые частые и дорогие причины.
3. Подключение данных
Для быстрого старта используйте гибридную схему.
Автоматизируйте сразу: состояние оборудования (работа/останов/авария) из PLC/SCADA; счетчики выпуска (total) из контроллеров, весов и счетчиков; базовые технологические параметры для разборов.
На пилоте можно использовать ручной ввод: причины простоев (код и комментарий) через терминал или MES-форму; качество (good / rework / scrap) — если нет автоматического контроля.
Параллельно автоматизируйте ручные операции с высоким риском ошибки. Пример — электронные рецептуры и сменные задания, которые система формирует и передает в АСУ ТП. Это убирает переписывание параметров с бумаги.
4. Валидация расчетов
Пока расчет не прошел валидацию, не используйте OEE как управленческий KPI.
Сверьте время работы и остановов с первичными источниками — SCADA-тренды, журналы событий, сменные отчеты. Проверьте логику времени: нет ли двойного учета остановов, корректны ли границы смен и переналадок. Введите правила обработки аномалий и пропусков. Ограничьте правки задним числом — корректировки разрешайте только с указанием причины и следом в аудите. Обучите смену кодировать остановы и трактовать качество: good, rework, scrap.
Цель этапа — чтобы цифрам доверяли мастер, технолог и руководитель участка.
5. Первые улучшения на основе данных
Правильная цепочка:
• Pareto по потерям: время, штраф по скорости, брак.
• RCA (5 Why, диаграмма Исикавы, разбор по фактам).
• Мероприятия: TPM, SMED (быстрая переналадка), стандарты работы, обучение, корректировка режимов, устранение повторяемых отказов.
• Контроль эффекта: сравнение «до/после» по конкретным драйверам потерь.
6. Масштабирование
Команда тиражирует решение на однотипное оборудование и адаптирует справочники и нормативы. Расширяет интеграции: MES ↔ ERP, склад, логистику, лабораторию. Добавляет аналитику: ранние признаки деградации, прогноз отказов, оптимизацию графика ТОиР.
Масштабирование редко бывает копированием: «похожие» цеха отличаются потоками, складами, составом оборудования, рецептурами и регламентами. Доработки при тиражировании неизбежны.
Пример плана внедрения
Сроки ориентировочные. На практике их определяют зрелость данных, состояние АСУ ТП и готовность производства.
Типовые проблемы и их решения
1. Нетипичные случаи ломают архитектуру
На производстве встречаются нештатные ситуации: обходные схемы потоков, нестандартные партии сырья, ручные операции не по регламенту, аварийные остановы. Если их не зафиксировать со сменным персоналом и не заложить в модель учета, система даст искаженную картину. Потом придется переделывать логику.
Что делать:
- проводить интервью не только с технологами и руководством, но и со сменой;
- фиксировать нетипичные сценарии в регламенте учета и справочниках причин;
- прогонять кейсы на данных — как они отразятся в A/P/Q и отчетах.
2. Качество данных и человеческий фактор
Частая картина: в данных аномалия по качеству или скорости, а в причинах — «прочее» или пусто. Аудит-лог показывает, кто, когда и что изменил. Привязка записи простоя к контексту — линии, заказу, партии, режиму — помогает восстановить ситуацию.
Что делать:
- Автоматизируйте рутинный ввод.
- Упростите интерфейс: справочники, подсказки, минимум полей.
- Обучите смену.
- Проблему дисциплины решайте управленческими методами, а не доработкой системы.
3. Сопротивление и барьеры интеграции
Главный риск — система есть, но ею не пользуются. Причины:
- нет общей модели потерь и единой трактовки времени;
- старое оборудование сложно интегрировать;
- смена получает дополнительную нагрузку; люди не доверяют цифрам.
Что делать: запустите пилот на одном объекте с измеримым эффектом и прозрачными правилами учета. Сначала автоматизируйте факт — статусы и события, ручной ввод оставьте для причин и качества. Используйте минимальный справочник причин и контролируйте заполнение. Обучите мастеров и технологов работать с A/P/Q, а не следить за процентом OEE. Валидируйте расчеты на первичных данных.
Вывод
OEE не снижает потери сам по себе. Его задача — показать, где они есть и сколько стоят. При правильном внедрении вы получите полную картину потерь в деньгах по каждой смене, приоритеты для ремонтов и улучшений на основе данных, и обоснование инвестиций — покупать новое оборудование или поднять отдачу от существующего.
