Классификатор причин простоев для OEE: реестр и правила

Зачем нужен единый реестр простоев для OEE

Когда в каждом цехе простои называют по-своему, сравнение превращается в спор. В одном месте пишут «нет материала», в другом - «ожидание склада», в третьем - «логистика». Формально причины разные, а по сути это один и тот же тип потерь. В итоге отчеты между линиями и участками несопоставимы: непонятно, где проблема больше и почему.

Для расчета OEE это особенно болезненно. OEE нужен не ради цифры, а чтобы понимать, какие потери съедают выпуск. Но если значимая часть остановок уходит в «прочее» и «неизвестно», картина искажается. Кажется, что причины мелкие и разрозненные, хотя на деле там часто прячется одна большая повторяющаяся проблема. Тогда решения становятся случайными: сегодня «боремся с дисциплиной», завтра «покупаем запчасти», а реальная причина может быть в планировании или настройке.

Единый реестр простоев дает общий язык для всех. Он помогает строить одинаковые отчеты по сменам, линиям, участкам и изделиям, не переписывая причины вручную и не «переводя» их между цехами. Когда категории и правила выбора одинаковые, можно честно сравнивать потери, видеть топ-3 причин и проверять эффект от действий.

Бизнесу обычно нужны простые ответы: где теряется больше всего времени, на каких линиях, в какие смены, на каких изделиях, и что именно происходит. Единый классификатор позволяет быстрее находить повторяющиеся причины, приоритизировать работу по времени потерь (а не по эмоциям), назначать владельцев и сроки по конкретным типам остановок и отслеживать, уменьшаются ли потери после изменений.

Простой пример: два цеха теряют по 40 часов в месяц. Без стандарта один показывает «прочее 60%», другой - «ремонт 50%», и кажется, что проблемы разные. С едиными кодами может выясниться, что у обоих главный вклад дает «ожидание наладчика» или «ожидание материала». Тогда вы решаете одну общую задачу и получаете эффект сразу на нескольких площадках.

Что считать простоем, чтобы OEE был честным

OEE обычно раскладывают на три части: доступность (сколько времени оборудование реально работает), производительность (с какой скоростью работает) и качество (сколько годной продукции выходит). Ошибка начинается там, где любой сбой автоматически записывают в простой. Тогда доступность падает, а производительность выглядит лучше, чем есть.

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

Практичное правило для реестра: фиксируем событие как простой, если выпуск в этот момент равен нулю и оператор может назвать причину остановки. А если выпуск идет, но ниже нормы, причина должна попадать в потери скорости (например, «работаем на 70% из-за нестабильной подачи»).

С микропростоями сложнее. Короткие остановки по 10-30 секунд легко теряются, но суммарно дают большой минус. Задайте порог, например 1-2 минуты: все, что короче, копится в одну запись за смену или за час с причиной «микропростои» и короткой подсказкой, что чаще всего было (залипание, датчик, ручная подача). Если микропростой повторяется сериями и съедает заметное время, его уже стоит фиксировать отдельными событиями.

Чтобы причины были сопоставимы между цехами, в классификатор сразу заложите границы ответственности. На верхнем уровне обычно хватает таких групп:

• Производство (переналадка, ожидание оператора, отсутствие задания).
• Ремонт (аварийная неисправность, плановое обслуживание).
• Снабжение и логистика (нет сырья, нет тары, нет инструмента).
• Качество (остановка на контроль, блокировка партии).
• Внешние условия (электричество, сеть, температура, безопасность).

Пример: в одном цехе «ожидание наладчика» записывали как ремонт, а в другом - как производство. В отчете это выглядело как разные проблемы. Договоренность о границах сразу убирает такие перекосы.

Данные реестра: какие поля обязательны

Чтобы реестр работал для расчета OEE и сравнения между цехами, начните с одинакового набора полей. Если каждый участок пишет по-своему, спорят не о проблемах, а о форматах.

Минимум, без которого данные теряют смысл: время начала и конца простоя, длительность (лучше считать автоматически), участок/линия, конкретное оборудование, причина из классификатора. Эти поля дают сопоставимость и позволяют ловить ошибки (например, если длительность не равна разнице времени).

Дальше решите, к чему привязывать событие. Обычно нужны три разреза: событие (каждый факт простоя), смена (для оперативной ответственности) и заказ/партия (для анализа потерь в выпуске). Практичный вариант: реестр хранит события, а смена и заказ/партия подтягиваются как атрибуты, если они известны. Тогда один и тот же простой анализируется и по цеху, и по заказу, без ломки структуры.

Комментарий полезен, но его важно держать в рамках. Причина выбирается только из классификатора, а комментарий отвечает на вопрос «что именно случилось в рамках этой причины». Например: причина «Ожидание наладчика», комментарий «наладчик на соседней линии, пришел через 12 минут». Если в комментариях постоянно всплывает другая причина, это сигнал уточнить определения или расширить словарь.

Отдельно зафиксируйте правила времени. Они снимают половину споров:

• один часовой пояс для всех цехов и отчетов;
• единое правило округления длительности (например, до минуты);
• запрет пересечений (у одного оборудования не может быть двух простоев в одно и то же время);
• понятный порог, с какого момента пауза считается простоем.

Когда поля и правила одинаковые, классификатор становится общим языком, а не набором «местных» трактовок.

Структура классификатора: уровни, коды и названия

Хороший классификатор нужен не для красоты. Он нужен, чтобы один и тот же случай в разных цехах назывался одинаково. Тогда реестр становится пригодным и для сравнения, и для расчета OEE без постоянных споров.

Оптимальная глубина - 3-4 уровня. Больше обычно превращается в «энциклопедию», где люди теряются. Меньше - не дает полезной аналитики.

Рекомендуемые уровни

1. Категория (верхний уровень): что это по типу. Часто хватает четырех корзин: плановые, неплановые, внутренние, внешние.

2. Подкатегория: в какой области причина. Например: «оборудование», «материал», «персонал», «качество», «логистика/склад», «энергия/инфраструктура», «ИТ/системы».

3. Конкретная причина: коротко и однозначно. Например: «поломка привода», «нет заготовок», «ожидание наладчика», «переналадка по плану», «нет электроэнергии».

4. Уточнение (опционально): то, что помогает действовать, но не ломает сравнимость. Например: «узел: шпиндель», «поставщик материала», «смена», «код заявки в ремонт».

Коды и названия

Причину лучше выбирать по коду, а не вводить свободным текстом. Коды стабильнее при переименованиях, их проще искать и связывать с отчетами. Удобно делать коды читаемыми, например NP-EQ-010 (неплановый - оборудование - конкретная причина). Название держите коротким: 2-6 слов, без «в процессе», «по причине», «не работает».

Чтобы 80% случаев покрывались коротким списком, держите на третьем уровне 15-30 самых частых причин для цеха или типа оборудования. Редкие события лучше вести в общем справочнике с обязательным уточнением на 4 уровне. Так классификатор остается удобным в смене и при этом дает точные срезы для OEE.

Словарь причин: определения и правила выбора

Словарь причин - это не просто список слов. Для каждой причины нужна короткая понятная формулировка и границы: что относится к причине, а что нет. Тогда реестр сопоставим, и расчет OEE не «плавает» от смены к смене.

Удобная структура описания для каждой причины: (1) определение, (2) включаем, (3) исключаем, (4) пример. Например, «Наладка (плановая)»: включаем переналадку под новый продукт и проверку первой детали; исключаем ремонт после поломки и ожидание наладчика (это другая причина).

Правило выбора должно быть простым: на одно событие ставится одна основная причина - та, которая реально запустила остановку. Вторичную причину допускайте только в двух случаях: если есть отдельное поле «влияющий фактор» или если простой состоит из двух этапов с разными причинами и вы делите его на два интервала. Не смешивайте «что случилось» и «почему затянулось»: поломка - основная причина, а «ожидание запчасти» - причина длительности, ее лучше учитывать отдельно.

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

При переходе со старых списков сделайте таблицу соответствий «старое -> новое»: старые причины, их частота, новый код и правило переноса. Если старое значение было расплывчатым (например, «ремонт»), заранее решите, как его распределять: по типу заявки, по ответственному подразделению или по ключевым словам в комментарии. Это помогает сохранить историю и не получить всплеск «неизвестно» после запуска.

Пошагово: как внедрить классификатор в нескольких цехах

Начните с фактов, а не с «идеального» справочника. В разных цехах одни и те же события часто называют по-разному, поэтому цель внедрения - договориться о едином языке и закрепить его в ежедневной работе.

1) Подготовка и согласование

Выгрузите историю простоев за 1-3 месяца (если данных нет, подойдут сменные журналы) и посчитайте, какие причины дают основное время. Обычно достаточно сфокусироваться на топ-20, чтобы быстро получить сопоставимость.

Дальше проведите короткую рабочую сессию с представителями всех цехов: мастер, наладчик, механик/энергетик, технолог, ОТК. На ней согласуйте словарь: что значит каждая причина, где границы между похожими, и кто имеет право менять выбранную причину.

2) Пилот, тиражирование и цикл улучшений

Сделайте пилот на одном участке с активным мастером. На 1-2 недели включите быстрый разбор сменных записей: где путают причины, какие формулировки не работают, какие поля пропускают.

Затем тиражируйте на остальные цеха и закрепите ритм: ежедневная фиксация, еженедельный разбор топ-5, ежемесячная правка справочника по фактам. В отчетах по расчету OEE показывайте долю «прочее» и «неизвестно» отдельно - как индикатор качества данных, а не «вины» смены.

Пример: в механическом цехе писали «нет заготовок», а в сборочном - «ожидание комплекта». После пилота это становится одной причиной «Ожидание материалов» с разными уточнениями. Так классификатор начинает работать одинаково в разных цехах и дает честный общий отчет.

Как снижать долю «прочее» и «неизвестно» без давления на персонал

«Прочее» и «неизвестно» появляются не потому, что люди ленятся. Обычно не хватает вариантов выбора, формулировки непонятны, или на линии нет времени разбираться. Цель не наказать, а сделать так, чтобы правильную причину было проще выбрать, чем поставить «прочее».

Хорошая база - мягкие правила:

• «Прочее» допустимо, но только с коротким комментарием (что случилось и где).
• «Неизвестно» выделено отдельной причиной и требует минимума: роль (оператор/наладчик/мастер), время начала и статус расследования (открыто/в работе/закрыто).
• Списки выбора различаются по цеху и по конкретному оборудованию, чтобы не искать в длинном справочнике.

Раз в неделю делайте короткий разбор только записей «прочее/неизвестно». Обсуждайте не людей, а формулировки и отсутствие подходящей причины. Рабочий порядок простой: перекодировать 10-20 самых частых записей в конкретные причины; если одна формулировка повторяется часто (например, 5+ раз или 60+ минут в неделю), добавить новую причину и определение; «неизвестно» закрывать в течение 48 часов, иначе оставлять статус «в расследовании».

Так доля «прочее» падает сама: людям легче выбрать точную причину, а руководству проще видеть, где реально теряется время.

Контроль качества данных: кто отвечает и что проверять

Хороший реестр держится не на «идеальных людях», а на понятных ролях и простых проверках. Тогда классификатор работает одинаково в разных цехах, а расчет OEE не превращается в спор.

Кто за что отвечает

Распределите ответственность так, чтобы у каждого была короткая, выполнимая задача:

• Оператор фиксирует событие: время старта и конца, оборудование, первичную причину и короткий комментарий.
• Мастер смены подтверждает: корректность причины, что простой действительно был, и что событие закрыто.
• Инженер качества данных (или диспетчер/аналитик) раз в день проверяет логику записей и возвращает ошибки на уточнение.
• Служба ремонта подтверждает ремонтоориентированные причины по факту работ (по заявкам и нарядам).

Важно: оператор не должен угадывать «правильный код». Его задача - выбрать максимально близкую причину и оставить факт в комментарии. Точность можно доводить позже.

Что проверять автоматически

Автопроверки ловят большую часть мусора без ручной рутины. Минимальный набор:

• пустые обязательные поля (оборудование, время старта, причина);
• нулевая или отрицательная длительность;
• пересечения событий по одной единице оборудования;
• «висящие» простои без времени окончания дольше заданного порога;
• несоответствие причины и статуса (например, «ремонт» без заявки).

Плюс нужен простой ручной аудит. Раз в неделю возьмите 10-20 записей и сравните с тем, что уже есть в цехе: сменный рапорт, журнал ремонта, сигналы датчиков. Если в отчете стоит «неизвестно 45 минут», а по рапорту видно, что ждали наладчика после смены оснастки, значит, людям трудно выбрать нужную причину или определение слишком размыто.

Чтобы качество было видно, держите 3-4 метрики: доля «прочее», доля записей без комментария, среднее время закрытия причины, процент записей, исправленных после проверки.

Типовые ошибки при расчете OEE по реестру простоев

Самая частая причина «кривого» OEE - не формула, а то, как люди фиксируют простой. Если реестр ведется по-разному, итоговые цифры выглядят точными, но сравнивать их нельзя.

Ошибка 1: слишком детальный классификатор

Когда справочник раздувают до сотен причин, оператор тратит время на поиск и в итоге выбирает «прочее» или «неизвестно». Лучше начать с короткого набора (20-40 причин) и добавлять новые только после того, как стало ясно, что текущих не хватает.

Ошибка 2: «симптом» вместо причины

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

Ошибка 3: разные названия одного и того же

Дубли вроде «нет материала», «нет сырья», «отсутствие заготовок» разбивают статистику на кусочки. Результат - нет управляемых «топ-причин». Правило простое: одна причина - одно название - один код. Остальные варианты уходят в синонимы в описании, но не в отдельные строки справочника.

Ошибка 4: путаница плановых и неплановых простоев

Если плановое ТО, переналадка или обед попадают в неплановые простои, «Доступность» в OEE падает без реальной проблемы. Заранее закрепите: что относится к запланированному времени, что к потерям, и как отмечать сменные задания, переналадки и регламентные работы.

Ошибка 5: сравнение цехов без калибровки правил

Один цех считает ожидание наладчика как «поломка», другой - как «организация работ». В итогах первый выглядит хуже, хотя работает так же. Перед сравнением договоритесь о единых правилах учета, проведите короткую проверку на 1-2 неделях данных и только потом стройте общие рейтинги.

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

Перед тем как включать реестр в KPI и сравнивать цеха, проверьте базовые вещи. Это помогает избежать ситуации, когда цифры «красивые», но причины простоев не сопоставимы.

• Утвержден классификатор: есть коды, названия и короткие определения, а для спорных случаев - понятное правило выбора.
• В реестре стабильно заполняются минимум: участок (цех, линия), оборудование, начало и конец простоя, причина. Комментарий обязателен только при отклонениях: длинный простой, ручная правка времени, выбор «прочее» или «неизвестно».
• «Прочее» и «неизвестно» ниже вашего порога (например, 5-10% по времени), и есть план снижения: какие формулировки уточнить, какие причины добавить, кого дообучить.
• Настроен регулярный разбор: кто смотрит топ потерь, кто владелец действий, где фиксируются решения и сроки. Цель - убрать повторяющиеся остановки, а не найти виноватого.
• Правила расчета OEE одинаковы во всех цехах: что считается плановым временем, как учитываются микропростои, переналадка, ожидание материала, тестовые запуски. Любые исключения оформлены как единые правила.

Если по любому пункту есть сомнения, лучше потратить 1-2 недели на доводку стандарта. Потом тиражирование пройдет быстрее, а отчеты будут сравнимыми и полезными.

Пример: два цеха, единый отчет и понятные причины

В цехе А оператор пишет в реестр «ремонт». В цехе Б в похожей ситуации мастер фиксирует «поломка датчика». В отчете это выглядит как разные причины, хотя по сути это один и тот же тип потери. Из-за этого сводка по заводу распадается, а топ причин «скачет» от месяца к месяцу.

Решение дает общий классификатор: одна запись - один код, а текст остается в комментарии. Например, оба случая приводятся к одному коду: категория «Неплановый ремонт», подкатегория «Электрика/датчики». Тогда не важно, как именно люди написали в поле «описание», в отчете причина будет одна.

Чтобы не путать ремонт с ожиданием, разделяйте «что сломалось» и «почему стоим прямо сейчас». Простое правило: если работа уже не идет, но ремонт еще не начался, это не ремонт.

Например, «ожидание наладчика» оформляйте как отдельную причину: категория «Ожидание персонала», подкатегория «Наладчик/электрик». А когда специалист приступил и выполняет работы - переключайте событие на «Неплановый ремонт».

После стандартизации меняется и расчет OEE: потери становятся сопоставимыми между цехами, и руководство видит честный топ-3. Дальше проще принять точечные меры: сократить время реакции, держать запас датчиков, пересмотреть график дежурств, а не спорить о формулировках в реестре.

Следующие шаги: закрепить стандарт и поддержать внедрение

Когда классификатор согласован и первые отчеты по OEE получились, важно не «отпустить» тему. Без закрепления правил через 2-3 месяца цеха начнут трактовать причины по-своему, и сопоставимость снова потеряется.

Зафиксируйте стандарт в коротком регламенте на 2-3 страницы: что считать простоем, как выбирать причину, когда допустимы «прочее» и «неизвестно», кто и как исправляет ошибки. Документ должен быть понятен мастеру и оператору.

Обучение лучше делать не лекцией, а сценариями на 5 минут. Например: «станок встал из-за отсутствия задания», «ждем наладчика», «брак инструмента», «нет заготовок». Один сценарий - одна правильная причина и одно правило выбора.

Чтобы не утонуть в деталях, начните с 20-30 причин. Дальше расширяйте только по фактам из «прочего»: раз в неделю просматривайте частые записи, которые туда попали, и либо уточняйте формулировки, либо добавляйте новую причину с четким определением.

Параллельно подготовьте инфраструктуру. Если оператору неудобно фиксировать простой, он будет чаще ставить «неизвестно».

Минимум, который стоит обеспечить

Нужны удобные рабочие места или терминалы у линии (чтобы внесение занимало пару кликов), стабильная сеть и единый доступ для смен, надежное хранилище для данных с резервными копиями и простые отчеты по доле «прочее/неизвестно».

Если вы планируете внедрять реестр, отчетность по OEE и интеграции с действующими системами на уровне предприятия, такие проекты логично делать вместе с системным интегратором. Например, GSE.kz (gse.kz) работает как производитель и интегратор: можно закрыть и инфраструктуру (терминалы, серверы), и поддержку, чтобы стандарт не держался на отдельных людях и спокойно масштабировался на новые цеха.