Почему непрерывному улучшению нужны более качественные данные

Непрерывное улучшение должно создавать знания, которые накапливаются со временем. Однако на многих производствах работа по улучшениям по-прежнему во многом опирается на семинары, таблицы, разрозненные отчёты и то, что люди помнят со прошлой смены. Мероприятие Kaizen может дать видимый результат, но через несколько недель та же потеря часто возникает снова, только в немного других производственных условиях. Дело не всегда в качестве идеи улучшения. Более серьёзная проблема в том, что команды часто не могут доказать, сработало ли корректирующее действие, где именно оно сработало и при каких условиях перестало работать.

ПОЧЕМУ УЛУЧШЕНИЯ KAIZEN ЧАСТО ИСЧЕЗАЮТ
Семинар создаёт фокус на несколько дней. Команды картируют процесс, выявляют потери, назначают действия, переставляют инструменты, меняют чек-листы или корректируют передачу работы. Затем возвращается обычное производственное давление. У мастера появляется очередной срочный заказ, у ремонтной службы очередная неисправность, планирование меняет последовательность, а отдел качества снова ставит партию на удержание. Корректирующее действие остаётся где-то в Excel-файле или трекере проектов, вместо того чтобы стать частью операционного ритма. Поэтому важен не вопрос, было ли действие выполнено, а вопрос, действительно ли улучшилось производственное условие.

PDCA НУЖДАЕТСЯ В НАСТОЯЩЕМ ШАГЕ ПРОВЕРКИ
Plan, Do, Check, Act звучит просто, но многие организации фактически работают по схеме Plan, Do и Move On. PLAN должен определить проверяемую проблему, текущее состояние, ожидаемое улучшение и гипотезу, лежащую в основе корректирующего действия. DO означает проверку действия в реальных производственных условиях с фиксацией достаточного контекста, чтобы понять, что именно произошло. CHECK означает сравнение ожидаемого результата с реальными производственными данными. ACT означает стандартизацию изменения, когда доказательства это подтверждают, либо адаптацию, сужение или отмену изменения, если они не подтверждают эффект.
• Действительно ли снизилась потеря?
• Не переместилась ли проблема в другое место?
• Не улучшилась ли доступность оборудования ценой ухудшения качества?
• Работает ли решение для разных изделий, бригад и смен?
• Повлияли ли на результат ремонт, материалы, планирование или изменения в другом процессе?
Один успешный производственный прогон не является доказательством. Непрерывному улучшению нужно достаточно данных, чтобы отделить воспроизводимое улучшение от удачной смены.

GEMBA И ДАННЫЕ НУЖДАЮТСЯ ДРУГ В ДРУГЕ
Данные не заменяют Gemba. Операторы, мастера, техники, планировщики и специалисты по качеству понимают производственные условия, которые системы часто не способны зафиксировать. Запись станка может показывать остановку на десять минут, в то время как оператор знает, что остановка произошла потому, что компонент работал не так, как надо, нормальный маршрут материала был заблокирован или предыдущая смена оставила рабочее место в необычном состоянии. В то же время одно наблюдение показывает лишь одну смену, одно событие или одну версию проблемы. Связанные производственные данные позволяют проверить, повторяется ли наблюдение в разных заказах, изделиях, станках, сменах, партиях материала и на более длинных временных интервалах.

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

НАЧИНАЙТЕ С ВОПРОСА ОБ УЛУЧШЕНИИ
Одна из самых серьёзных ошибок в аналитике производства состоит в том, чтобы начинать с тех данных, которые оказались доступны. Современная производственная линия может генерировать огромные объёмы информации из PLC, датчиков, MES, ERP, систем качества, приложений технического обслуживания и электронных таблиц. Больше данных само по себе не создаёт лучших решений. Полезный процесс улучшения начинается с производственного вопроса, на который команде действительно нужно ответить.

Вместо вопроса «Какие данные у нас есть?» задавайте вопрос «На какой производственный вопрос мы пытаемся ответить?». Формулировка «переналадки занимают слишком много времени» всё ещё слишком широка. Лучший вопрос звучит так: почему время переналадки заметно варьируется для одного и того же семейства изделий на одной и той же производственной линии? Это сразу помогает определить контекст, который имеет значение.
• Предыдущее изделие
• Следующее изделие
• Производственный заказ
• Ресурс или линия
• Конфигурация инструмента
• Материал
• Смена или бригада
• Начало переналадки
• Время перезапуска
• Первая приемлемая единица продукции
• Стабильное производство
• Результаты контроля качества
• Аварийные сигналы станка
Цель не в том, чтобы собрать всё. Цель в том, чтобы собрать минимальный набор фактов, способных изменить решение об улучшении.

ERP ОБЪЯСНЯЕТ ПЛАН
ERP даёт коммерческий и плановый контекст вокруг производства. Он может показать плановые количества, маршрутизацию, обязательства перед клиентами, потребность в материалах, приоритет заказов и намеченную производственную последовательность. Этот контекст важен, потому что производственные условия постоянно меняются. Корректирующее действие может реально сократить время переналадки, в то время как показатели поставок ухудшаются, поскольку изменилась производственная номенклатура или планировщики ввели более частые переходы между изделиями.
Поэтому ERP помогает объяснить, что должно было работать, в какой последовательности, на какой спрос, с каким маршрутом и материалами. Но ERP в первую очередь описывает намерение. Он не обязательно описывает то, что физически произошло на производственном участке.

MES ОБЪЯСНЯЕТ, ЧТО РЕАЛЬНО ПРОИЗОШЛО
Производственная система исполнения (MES) закрывает часть этого пробела. MES может предоставить историю исполнения заказа, включая фактическое начало и окончание операции, выпущенное количество, брак, удержания, доработку, ресурсы, операторские транзакции, расход материалов, прослеживаемость и коды причин. Это позволяет командам улучшения связывать потери с реальными заказами и операциями, а не полагаться на память или средние дневные значения.

Данные MES всё равно требуют интерпретации. Транзакции могут вноситься с опозданием, разные бригады могут по-разному использовать коды причин, а метка времени может отражать момент, когда оператор подтвердил событие, а не точный физический момент его наступления. Система даёт доказательства, но смысл этим доказательствам придаёт процесс.

ДАННЫЕ СТАНКОВ И IOT ОБЪЯСНЯЮТ ФИЗИЧЕСКИЙ ПРОЦЕСС
Когда командам нужно понять, что происходило внутри операции, важными становятся данные оборудования. Сигналы PLC и IoT могут показывать состояния станка, время циклов, аварийные сигналы, скорость, температуру, давление, блокировки, нагрузку двигателя, поведение при перезапуске и время выхода на стабильный режим. MES может показать, что операция перезапустилась в определённое время, а данные станка объясняют, что происходило в минуты до возвращения стабильного выпуска.
• Повторяющиеся аварийные сигналы
• Сниженная скорость после перезапуска
• Восстановление температуры
• Ручные корректировки
• Блокировки
• Нестабильное время циклов
Данные станка без производственного контекста всё равно могут вводить в заблуждение. Аварийный сигнал становится гораздо полезнее, когда его можно связать с рабочим заказом, изделием, операцией, ресурсом, состоянием инструмента, материалом и результатом контроля качества, сопровождающим событие.

ЦЕХ ДОБАВЛЯЕТ СМЫСЛ
Операторы, техники по обслуживанию, мастера и специалисты по качеству заполняют пробелы, которые автоматизированные системы не могут закрыть. Код причины вроде «проблема с материалом» может описывать на практике очень разные ситуации. Материал мог прийти с опозданием, вести себя иначе, иметь неверную маркировку, быть повреждённым или создать проблему на последующем этапе, которая стала видна только позже.

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

НУЖЕН ОБЩИЙ ПРОИЗВОДСТВЕННЫЙ ЯЗЫК
ERP, MES, системы технического обслуживания, historian и электронные таблицы могут описывать одно и то же производственное событие по-разному. Одна система может называть ресурс «Линия 3», другая — «LINE03», служба ремонта может отслеживать несколько отдельных активов внутри линии, а historian может всё ещё использовать старый тег PLC. Общий справочник ресурсов, кодов причин и идентификаторов заказов нужен, чтобы данные можно было сопоставлять и сравнивать.