KPI производства и ремонтных служб: учет простоев без журналов

Почему журналы и двойной ввод портят KPI

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

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

Двойной ввод быстро ломает доверие к отчетам. Если одни и те же данные попадают в два места (журнал и таблица, таблица и ERP), они неизбежно расходятся. На планерке начинают спорить не о том, как убрать потери, а о том, «чьи цифры правильные». Это особенно болезненно для KPI производства и ремонтных служб, где важна единая правда о доступности оборудования.

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

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

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

Какие данные нужны для KPI производства и ремонта

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

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

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

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

Чтобы убрать двойной ввод, заранее назначьте владельцев полей. Обычно работает простая логика:

• Производство отвечает за выпуск, брак, смену и номенклатуру.
• Ремонт отвечает за классификацию неисправности, выполненные работы и запчасти.
• Мастер смены (или диспетчер) подтверждает причины простоев и закрывает спорные записи.

Небольшой пример: линия встала на 18 минут. Производство фиксирует факт и смену, ремонт добавляет причину и время восстановления, мастер подтверждает запись. В отчете это один инцидент, а не три разные строки.

Карта данных: от оборудования до отчета

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

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

Как проходит путь данных

На практике это выглядит так:

• Оборудование отдает статус и счетчик (через контроллер, датчик, PLC).
• Система фиксирует событие «стоп» и считает длительность простоя.
• Оператор выбирает причину простоя на терминале/планшете.
• Ремонт добавляет отметку по работам, если был вызов.
• Отчет собирает смену: выпуск, простои, топ причин, время реакции.

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

Где фиксировать причины и как не утонуть в справочнике

Причину удобнее вводить там, где человек уже находится и видит проблему: у линии на простом терминале или на планшете мастера. Телефон тоже подходит, но только если связь стабильная, а формы максимально короткие.

Справочник причин должен быть небольшим и понятным. Хорошее правило: 10-20 причин на участок, не 200 на завод. Начните с крупных групп («поломка», «нет материала», «наладка», «ожидание контроля качества»), а детализацию добавляйте только там, где ею реально пользуются. Если люди постоянно выбирают «прочее», причины стоит упрощать, а не расширять.

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

Источники данных без ручных журналов

Логика простая: все, что машина может сообщить сама, должно приходить автоматически. Человек добавляет то, чего не знает контроллер: причину, пояснение, контекст.

Сигналы и счетчики от оборудования

Самый надежный слой - дискретные статусы и события от PLC, станка или линии. Из них получается честная картина по времени: работа, авария, ожидание материала, наладка. Важно заранее договориться о едином словаре состояний, иначе один и тот же простой в разных цехах будет называться по-разному.

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

Встроенные системы и данные от людей

Часть данных уже есть в ваших системах: SCADA хранит события и тренды, ERP знает план и номенклатуру, CMMS фиксирует заявки и ремонты, табели смен дают привязку к бригадам и времени. Важная задача автоматизации - не переносить эти данные руками, а связать их по общим ключам (оборудование, смена, заказ, партия).

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

Как внедрить сбор простоев и выпуска за 5 шагов

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

1) Выберите одну линию и короткий список причин

Берите линию или станок, где простои заметны и есть кому держать процесс. Для старта достаточно 5-10 причин (наладка, ожидание материала, отказ узла, отсутствие оператора, контроль качества). Если причин слишком много, люди начинают выбирать наугад.

2) Согласуйте правила времени

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

3) Настройте учет выпуска так, чтобы он совпадал с реальностью

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

4) Сведите справочники, иначе цифры не сойдутся

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

5) Делайте короткий ежедневный разбор расхождений

10-15 минут в конце смены: что не попало, где выбрали неверную причину, почему выпуск не совпал с фактом. Не ищите виноватых, ищите правило или кнопку, которую нужно упростить. Через 1-2 недели качество данных обычно растет заметно.

Частые ошибки и ловушки при автоматизации учета

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

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

Вторая типовая проблема - слишком длинный справочник причин. Когда в списке десятки вариантов, люди выбирают первое попавшееся. Данные формально есть, а анализ бесполезен.

Ошибки появляются и в выпуске: счетчик на линии считает все подряд, включая брак и пробные детали, а KPI ожидают только годные. Если заранее не договориться, что именно считается «выпуском» в системе, спор будет постоянным.

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

Помогают простые договоренности: кто и когда закрывает простои, как устроен справочник (10-20 основных пунктов плюс «прочее» с комментарием), как разделяются «всего/годные/брак» по выпуску, как синхронизируется время и как выглядит единый идентификатор события/заявки. И обязательно - прозрачные корректировки с историей изменений.

Кто и когда вводит данные: простые правила ответственности

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

Рабочее правило такое: каждый вводит то, что знает лучше всего, и делает это сразу, пока ситуация свежая.

Минимальная матрица ответственности

Чаще всего хватает трех ролей:

• Оператор выбирает причину простоя из короткого списка и отмечает запуск.
• Мастер смены подтверждает события смены (простои, выпуск, переработка, списания) и закрывает смену.
• Ремонт (механик/электрик) принимает заявку, фиксирует работы и закрывает ее итоговой причиной.

Чтобы не было «вчера вспомнили», задайте простой SLA на ввод причины: например, в течение 10 минут после начала простоя (или после его обнаружения системой). Если оператор не успел, событие попадает мастеру в список на подтверждение до закрытия смены.

Единые определения и право на корректировки

Одинаковые слова должны означать одно и то же. Заранее договоритесь, что считать аварией, переналадкой, микропаузой, ожиданием материала или тестовым прогоном.

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

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

Пример: линия встала на 18 минут. Оператор выбирает «ожидание сырья» в течение 10 минут. Если позже выяснилось, что датчик уровня давал ложный сигнал, мастер меняет причину на «авария (датчик)», а ремонт закрывает заявку с уточнением. Отчет остается честным и без поиска «виноватого по ощущениям».

Как связать KPI производства и ремонтных служб в одной картине

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

На уровне руководителя обычно хватает ядра метрик: OEE и доступность, доля аварийных простоев, MTTR и MTBF. Но ключевой мост между производством и ремонтом - связка «событие простоя -> заявка -> работы». Система фиксирует останов (или оператор подтверждает), затем создается заявка с узлом и причиной, а после ремонта она закрывается с действиями и временем.

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

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

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

Быстрый чеклист качества данных

Перед тем как спорить о KPI, стоит проверить, не ломают ли картину сами данные. Эти проверки занимают 10-15 минут и обычно находят главные проблемы учета.

5 проверок, которые стоит делать каждую неделю

• Смена должна сходиться по времени. Для каждой смены сумма «работа + простои + плановые остановки» должна давать 100% сменного фонда. Если не сходится, где-то пропали события или два события наложились.
• Выпуск должен быть логичным. Значения не могут быть отрицательными. Резкие скачки без смены номенклатуры, режима или состава смены обычно означают ошибку счетчика, ручную правку или пересчет после закрытия смены.
• Причины простоев должны быть понятны на месте. Топ-5 причин за неделю должен быть стабильным и сформулированным так, чтобы оператор и механик понимали одинаково. Если список постоянно «перетасовывается», справочник слишком дробный или люди выбирают наугад.
• События без причины почти исчезают. Отслеживайте долю простоев с пустой причиной или с «прочее» и разбирайте превышения сразу, пока детали еще помнят.
• Ремонт и простой должны совпадать по времени. Если в ремонте интервал 10:00-11:00, а линия по данным простояла 10:20-10:50, разные источники фиксируют одно и то же по-разному. Это влияет и на MTTR, и на «потерянное время» производства.

Маленький пример

Если линия показала простой 35 минут, а заявка на ремонт закрыта на 60 минут, проверьте, когда реально началась работа (прибытие), было ли ожидание запчасти и кто фиксировал начало и конец. Часто помогает правило: начало простоя фиксирует производство, а начало ремонта - ремонтная служба, но оба события должны быть синхронизированы по времени.

Пример из практики: линия с частыми простоями

Линия упаковки работает в 3 смены. Выпуск по плану обычно сходится, но в конце недели внезапно проседает OEE и растет время простоя. Остановки короткие: 30-90 секунд, по 50-80 раз за смену. В сумме это часы, но в суете их легко не заметить.

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

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

Через две недели изменились KPI. Доля «неизвестных» простоев резко упала, и стало видно, что причина топ-1 - частые остановки из-за ложного срабатывания датчика на подаче пленки, а не «поломки в целом». Раньше датчик попадал в «прочее», потому что каждая остановка была слишком короткой для записи в журнал.

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

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

Следующие шаги: пилот, масштабирование и инфраструктура

Логичный старт - пилот на одной линии или узком участке, где простои «болят» сильнее всего. Цель пилота: доказать, что данные по простоям и выпуску можно собирать без журналов, а отчет собирать в понятной витрине за 1-2 минуты.

Для пилота хватает минимума: сигнал «работает/стоит», счетчик выпуска (или такт) и короткий список причин простоя. Витрина отчетов тоже может быть простой: смена, линия, минуты простоя по причинам, выпуск, OEE или его базовые части.

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

Часть работ часто разумно отдать интегратору, чтобы не превращать производство в полигон: подключение к PLC/SCADA и чтение нужных тегов, настройка справочников (линии, изделия, смены, причины), правила расчета KPI и сверка с реальностью на участке, базовые отчеты и роли доступа.

Масштабирование обычно упирается не в датчики, а в единые правила. До расширения на другие цеха закрепите стандарт причин простоя, шаблоны отчетов и порядок подтверждения данных сменой. Иначе каждая линия начнет «говорить на своем языке», и сравнение KPI потеряет смысл.

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