TPM 이니셔티브가 때때로 실패하는 이유

최근 기사에서 저는 플랜트 신뢰성 관리 방정식에 운영자를 포함시키는 것에 대한 제 견해를 제시했습니다. 가장 좋은 출발점은 작업을 표준화하여 작업자가 정확하고 일관되게 작업하도록 하는 것이라고 제안했습니다.

다음 단계는 검사, 사전 작업 식별, 작업 우선 순위 지정 및 계획을 통해 작업자를 신뢰성에 참여시키는 것입니다. 그런 다음 상태가 좋아 보이면 운영자 참여 유지보수로 이동할 수 있습니다. 여기서 운영자는 기존 유지보수 대신 특정 유지보수 작업을 실제로 수행합니다.

린 제조 여정의 일부로 운영자 중심의 안정성을 구현하는 사람들은 아마도 이것을 TPM(총 생산 유지 관리)이라고 부를 것입니다. 일반적인 함정을 피하는 데 도움이 되도록 TPM 이니셔티브가 때때로 실패하는 이유에 대한 몇 가지 관찰을 제공합니다. 완전한 것은 아닙니다.

1) 운영(생산) 관리가 OEE를 소유하지 않음: 가장 중요한 요소라고 할 수 있습니다. 운영/생산 관리 팀이 전반적인 장비 효율성 또는 OEE(가용성 x 수율 x 품질)를 주도할 책임이 없는 경우 TPM이 작동하지 않습니다.

일반적으로 린 및 플랜트 안정성 관리 이니셔티브는 이러한 경우 작동하지 않습니다. 신뢰성과 OEE는 "유지 보수"에 관한 것이 아니며 결코 그렇지 않았습니다. 운영은 TPM이 어떻게 안정성을 주도하는지, 안정성이 어떻게 린을 주도하고 린이 수익을 창출하는지 인식해야 합니다. 운영자를 TPM 이니셔티브에 참여시키려면 긴박감을 가져야 합니다.

2) 팀이 TPM의 정의와 이유에 대해 교육을 받지 않았습니다. 위에서 언급했듯이 신뢰성은 일반적인 믿음에 반하여 단순히 유지 보수의 동의어가 아닙니다. 유지 보수는 장비를 작동 상태로 복원하는 것입니다. 신뢰성은 처음에 기능 손실을 방지하는 것입니다. 역사적으로 스스로를 "수리"라고 정의한 유지 관리 팀의 경우 신뢰성은 자기 인식에 도전합니다. 심리학은 강력한 것입니다.

그들은 "만약 실패하지 않는다면 나의 가치 기여는 무엇인가?"라고 생각합니다. 마찬가지로, 신뢰성 방정식에서 연산을 포함하는 것이 명백히 중요함에도 불구하고 운영자는 때때로 이것을 보는 데 어려움을 겪습니다. 우리는 양측의 소유권이 필요합니다.

3) 운영자 참여 유지보수 시작 실패: 종종 TPM 이니셔티브는 유지 관리 부서에서 주도하며 운영 및 운영자 관련 안정성 개선을 건너뜁니다. Leery 운영 감독자와 운영자는 종종 이것을 계략으로 간주합니다.

이니셔티브가 유지 관리 관리자 위에서 주도되더라도 운영은 자신의 책임을 회피하고 떠넘기려고 한다고 주장하면서 유지 관리를 비난하는 경향이 있습니다. 적절한 작업을 표준화하는 것으로 시작하는 것이 가장 좋습니다.

거기에서 작업자가 검사를 수행하고, 작업 완료 우선 순위를 설정하고, 장비를 청소하도록 하여 신뢰성에 작업자를 참여시킵니다(검사하기가 더 쉽습니다). 실제로 유지 보수 작업을 수행하는 운영자 참여 유지 관리로 점차 쉬워집니다.

4) 검사가 너무 기술적이고 너무 빨리 복잡해짐: 조직은 진동 분석, 열화상 측정 등과 같은 멋진 예측 유지 관리 기술에 매료됩니다. 따라서 기본적인 시각적 및 게이지 기반 검사를 건너뛰고 너무 빨리 첨단 기술로 이동합니다.

이것은 특히 운영자 수준에서 잘 작동하지 않습니다. 조직은 고도로 기술적인 자료에 운영자 교육에 막대한 돈과 시간을 낭비하게 됩니다. 그들은 압도되고 낙담합니다.

기본에 대부분의 노력을 집중하여 고도로 기술적인 모니터링을 쉽게 하는 것이 가장 좋습니다. 팁으로 모든 검사를 예 또는 아니오로 바이너리로 만드십시오. 정량적 데이터도 이런 식으로 처리할 수 있습니다. 예를 들어 "온도는 화씨 130도에서 135도 사이입니다. 예 또는 아니오입니다." 간단하게 유지하십시오.

5) TPM 배포는 피상적입니다. 종종 공장에서 TPM의 매우 피상적인 구현을 볼 수 있습니다. 따라서 전체 생산 유지 관리 대신 "완전히 도색된 기계"를 얻습니다(동료 신뢰할 수 있는 공장 칼럼니스트 John Schultz는 여러 번 말했습니다.

일반적으로 이러한 것들은 지속적인 가치를 제공하지 않고 조직을 해롭게 하는 단기적인 "윈도우 드레싱" 이니셔티브이므로 앞으로 TPM을 본격적으로 구현하려고 시도하면 조직에서 "우리는 TPM을 시도했습니다. 작동하지 않았습니다."

6) 검사 결과 및 사전 작업 식별은 어디에도 적용되지 않습니다. 팀이 작업자 수준에서 검사 및 작업 식별 프로세스를 배치하고 결과를 무시하는 것은 역효과입니다. 이것이 TPM 이니셔티브를 중단시키는 빠른 방법입니다. 교환원은 흥미를 잃고 작업을 완료하지 못하거나 "연필 채찍" 검사를 받게 됩니다.

정말 그들을 비난할 수 있습니까? 사실상 의미 없는 일을 하는 것을 좋아하는 사람은 아무도 없습니다. 검사에 따라 조치를 취하고 TPM 프로그램이 좌절되는 것을 방지하기 위해 운영자가 식별한 사전 예방적 작업을 완료할 수 있는 백엔드 기능이 있는지 확인하십시오.

7) 보상 구조의 불일치: 수십 년 동안 우리는 보상 시스템 문제와 불일치를 겪었습니다. 설계 팀은 최저 구매 가격으로 기능적 기능을 달성할 수 있는 보상을 받습니다. 운영 및 유지 관리 관리자에게 발생하는 다운스트림 문제와 실제 수명 주기 소유 비용은 신경쓰지 마십시오.

생산 팀은 제품에 대한 수요가 있든 없든 자신의 행동이 자산 상태에 미치는 영향을 존중하지 않고 생산 수에 도달하면 보상을 받습니다. 유지 관리 팀은 항상 신뢰성이 아니라 실패에 대한 보상을 받았습니다.

그들은 장비가 고장났을 때 추가 수당을 받고(시간외 근무) 불편한 시간에 수리를 하러 와 경영진으로부터 "아타보이"(물론 초과 근무 수당을 받는 동안)를 받습니다. 실패에 대한 보상을 받는다면 신뢰성을 원하십니까? 10% 또는 20%의 급여 삭감을 위해 자원 봉사를 하시겠습니까?

사람들은 리더가 행동으로 무엇을 하느냐만큼 리더가 말로 하는 말에 그다지 주의를 기울이지 않습니다. 리더십 팀이 그들이 신뢰성을 원한다고 말하지만 그들이 외적으로나 본질적으로 실패에 대한 대가를 치르고 있다면 당신은 실패를 얻게 될 것입니다. 시스템이 고장났고 고쳐야 합니다. TPM은 잘못된 보상 구조에서 살 수 없습니다.

이러한 통찰력이 린 제조 여정의 일부로 TPM을 구현하는 데 도움이 되기를 바랍니다.