Почему инициативы TPM иногда терпят неудачу

В недавней статье я изложил свои взгляды на вовлечение операторов в уравнение управления надежностью станции. Я предположил, что лучше всего начать с того, чтобы операторы работали правильно и согласованно, стандартизируя операции.

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

Для тех, кто реализует управляемую операторами надежность как часть пути бережливого производства, вы, вероятно, называете это Total Productive Maintenance (TPM). Чтобы помочь вам избежать распространенных ошибок, я предлагаю несколько своих наблюдений о том, почему инициативы TPM иногда терпят неудачу. Это ни в коем случае не является исчерпывающим.

1) Оперативное (производственное) управление не владеет OEE: Это, пожалуй, самый важный элемент. Если группа управления производством / производством не отвечает за общую эффективность оборудования или за OEE (доступность x выход x качество), TPM не работает.

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

2) Команда не осведомлена о том, что и почему TPM: Как указывалось выше, надежность, вопреки распространенному мнению, - это не просто синоним технического обслуживания. Техническое обслуживание - это восстановление оборудования до рабочего состояния. Надежность - это прежде всего предотвращение потери функции. Для группы технического обслуживания, которая исторически называла себя специалистами по ремонту, надежность бросает вызов их самовосприятию. Психология - сильная сторона.

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

3) Невозможность начать техническое обслуживание с участием оператора: Часто инициативы TPM инициируются отделами технического обслуживания, и они упускают из виду улучшение операций и надежность с участием оператора. Руководители и операторы с осторожностью часто видят в этом уловку - техническое обслуживание пытается заставить работу выполнять свою работу.

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

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

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

Это не очень хорошо работает, особенно на уровне оператора. В итоге организация тратит огромные суммы денег и времени на обучение операторов высокотехнологичным материалам. Они ошеломлены и разочарованы.

Лучше всего перейти к высокотехнологичному мониторингу, сосредоточив большую часть усилий на фундаментальных принципах. В качестве совета сделайте все ваши проверки двоичными - да или нет. Таким образом можно обрабатывать даже количественные данные. Например, «температура от 130 до 135 градусов по Фаренгейту - да или нет». Будьте проще.

5) Развертывание TPM поверхностное: Часто на предприятиях мы видим очень поверхностные реализации TPM. Таким образом, вместо полного производственного обслуживания мы получаем «полностью покрашенные машины» (как я слышал от товарища Надежный завод обозреватель Джон Шульц так много раз повторял).

Обычно это краткосрочные инициативы, которые не приносят долгосрочной пользы и портят организацию, так что в будущем, если вы всерьез попытаетесь внедрить TPM, организация будет сопротивляться, заявив:«Мы пробовали этот TPM. прочее, и это не сработало ".

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

Вы действительно можете их винить? Никто не любит заниматься бессмысленной работой. Убедитесь, что у вас есть серверная возможность действовать при проверках и выполнять проактивную работу, которую определяют операторы, чтобы избежать остановки программы TPM из-за разочарования.

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

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

Они получают дополнительную оплату, если оборудование сломано (сверхурочные), и «атташе» от руководства за то, что приходили и ремонтировали его в неудобное время (при этом, конечно, им платили сверхурочные). Если бы вас вознаграждали за неудачу, хотели бы вы надежности? Вы бы выступили и добровольно согласились бы на сокращение заработной платы на 10 или 20 процентов?

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

Я надеюсь, что эти идеи помогут вам при внедрении TPM в рамках вашего пути к бережливому производству.