변화 관리에 대한 8가지 일반적인 오해

공장 직원의 변경 관리를 언급할 때마다 일반적으로 몇 가지 예측 가능한 응답 중 하나를 얻습니다. 지식이 있는 사람은 OSHA 1910.119(a)(2) 규정을 인용하고 "적용되는 프로세스"가 아니므로 적용되지 않는다고 말합니다. 일반적으로 크게 안도의 한숨을 쉬게 됩니다. 또 다른 빈번한 응답은 다음과 같습니다. "도면 관리 절차가 있지만 너무 뒤처져 있어 따라잡을 필요가 없는 몇 년과 리소스가 필요합니다." 다른 사람들은 여전히 ​​그들의 관리자가 작은 프로젝트와 변경 사항을 승인할 수 있는 완벽하게 훌륭한 절차가 있다고 나에게 말할 것입니다. 그리고 몇몇 사람들은 자동차의 재떨이를 채우는 동전과 동전에 대해 소심하게 생각할 것입니다.

그렇다면 변화 관리(MOC)란 무엇일까요? 출처로 돌아가서 OSHA 1910.119(l)(1)은 MOC에 대한 요구 사항을 다음과 같이 설정합니다. 절차; 및 해당 프로세스에 영향을 미치는 시설 변경."

그 짧은 설명은 많은 영역을 다루지만 공정 안전을 강화하기 위해서만 공표되었기 때문에 "해당 공정"에 대한 법적 적용을 제한합니다. 시설이 "해당 프로세스"의 OSHA 요구 사항을 충족하는 독자는 MOC의 세부 요구 사항을 잘 알고 있습니다. 그렇지 않으면 여전히 작동하지 않을 것입니다. 그리고 최근 역사상 최악의 산업재해 중 상당수가 MOC 프로세스 실패의 근본 원인이라는 사실을 여러분 모두가 알고 있기를 바랍니다. 일부 소식통에 따르면 산업계의 중대 사고 중 80%가 통제되지 않은 변화와 관련이 있습니다. 따라서 MOC는 사고를 예방함으로써 보상을 받는 일종의 생명보험이라고 생각할 수 있습니다.

그러나 이 기사는 대상 프로세스에 대한 MOC의 복잡성에 초점을 맞추지 않습니다. 그리고 이것은 안전만을 위한 것이 아닙니다. 그렇다면 귀하의 산업에 "필수"가 아닌 경우 MOC에 대해 논의하는 이유는 무엇입니까? 요컨대, 법적 요구 사항에 관계없이 모든 비즈니스가 잠재적 손실을 통제해야 하기 때문입니다. 그리고 적절하게 적용된 MOC는 거의 모든 비즈니스를 위한 우수하고 비용 효율적인 손실 방지 프로세스입니다. 손실 제거 프로세스를 완벽하게 보완하는 프로세스입니다. 그리고 우리 모두는 안전하고 환경 친화적이기를 원합니다. 그렇죠?

MOC는 현재 존재하는 것들에 대한 변경 사항만 다룬다는 점에 유의하십시오. 새로운 프로세스나 시설의 설계는 완전히 또 다른 문제입니다. 그리고 MOC 논의의 목적을 위해 기존 시스템의 성능 수준이 적절하지 않더라도 최소한 친숙하고 잘 알려진 장점과 단점이 있다고 가정해야 합니다.

그렇다면 비규제 용어로 MOC는 무엇이며 실제로 누구에게 적용됩니까? 이 간단한 정의로 작업해 보겠습니다. MOC는 시설이나 프로세스를 구성, 운영, 관리 또는 수리하는 방법의 변경 결과로 발생하는 안전, 건강 또는 환경 저하를 포함한 비즈니스 손실을 예방하거나 완화하기 위한 프로세스입니다. 규제 요구 사항을 제외하고, 적절한 MOC 프로세스를 마련하지 않을 수 있는 경쟁력을 유지하려는 기업은 없습니다. 요컨대, MOC는 안전에 대해 의미가 있고 재정적으로도 의미가 있습니다. MOC 프로세스가 귀하의 비즈니스에 적합합니까?

'변경'이란 무엇인가요?
"변화 관리에서 가장 어려운 부분은 변화를 인식하는 것입니다." 프로그램의 가장 중요한 출발점은 관리하려는 "변화"를 구성하는 요소를 조직에 명확하게 정의하는 것입니다. 또는 더 간단하게 MOC 프로세스에 해당하는 변경 사항과 그렇지 않은 변경 사항은 무엇입니까? 명확한 정의가 없으면 MOC 프로그램의 효율성을 효과적으로 저해하여 불필요한 분석 마비를 유발하고 프로세스를 우회하려는 사람들에게 허점을 만듭니다.

다양한 출처로부터의 변화에 ​​대한 많은 정의가 있습니다. 비즈니스 이해 관계 및 규제 선례와 일치하는 용어로 변경을 정의하는 것은 현장 리더의 책임입니다. 통제하고 싶은 위험은 무엇이며 통제되지 않는 경우 이러한 위험을 증가시키는 변화의 종류는 무엇입니까? 그래야만 합리적으로 "변경"으로 정의될 수 있는 활동을 명확하게 식별할 수 있으며, 일단 식별되면 가능한 가장 간단하고 직접적인 언어로 전달해야 합니다.
다소 지저분하지만 목록이나 예 표를 사용합니다. 포인트를 얻기 위해 종종 필요합니다. 자격을 갖추기 위해 하드웨어에서 "변경"이 발생할 필요는 없습니다. 소프트웨어, 절차 및 프로세스 매개변수는 모두 종종 엄격하게 제어되어야 하는 비하드웨어 변경의 예입니다.

하드웨어를 다룰 때 OSHA 1910 소스 문서는 "현물 교체"(RIK)가 아닌 변경을 비스듬히 언급하고 추가로 RIK를 "설계 사양을 충족하는 교체"로 정의합니다. RIK는 일반적으로 형태, 맞춤 및 기능이 동일한 장비 또는 구성 요소(F3이라고 함)를 나타냅니다. 그러나 이 매우 좁은 하드웨어 기반 접근 방식보다 더 많은 변경 사항이 있습니다. 변경에 대한 OSHA 정의는 기술, 절차 및 화학 물질(보다 광범위하게는 원자재로 해석됨)을 의미하기도 합니다. 분명히 "변경"의 정의에는 하드웨어 이상의 의미가 포함됩니다. MOC 프로세스에서 "변경"에 대해 사용되는 가장 공식적인 정의는 OSHA 3313에 게시된 설명에서 찾을 수 있습니다. "변경은 기존 시스템 내의 구성 요소, 변수 또는 속성에 대한 변경 또는 조정입니다. 명확하게 정의된 경계 또는 책임).”

모든 비즈니스는 위험 노출 영역이 다르고 바람직하지 않은 결과에 대한 내성이 다르기 때문에 위험을 평가하고 통제되지 않은 변경에 대한 내성을 정의하는 것은 각 비즈니스에 달려 있습니다. 비즈니스에서 관리할 수 있는 변경 유형의 몇 가지(그러나 모든 것을 포함하지는 않음) 예는 다음과 같습니다.

<울>

새로운 프로세스 장비 또는 중요 비즈니스 시스템(소프트웨어 포함) 추가

"현물이 아닌" 공정 장비 또는 부품 교체

공정 장비의 수정 또는 약간의 추가

중요한 비즈니스 시스템(절차 또는 소프트웨어)에 대한 수정 또는 사소한 추가

기반 시설/비공정 장비에 대한 수정 또는 사소한 추가

프로세스 제어 및/또는 도구 변경(제어 전략 포함)

기술 MRO의 사양 또는 소싱 변경

주요 공정 매개변수 작동 한계의 변경(표준 작동 절차[SOP]에 지정된 범위를 벗어남)

안전 시스템 변경(인터록, 차단, 화재 또는 폭발 진압 등)

표준 운영 절차 개정(비상 절차 포함)

사이트 수준 조직 구조의 변경

유지 관리 절차 변경

원자재/부품 사양 또는 소싱 변경

유틸리티 시스템(공기, 전기, 가스, 물, 증기 등)에 대한 변경 또는 새로운 연결.

중요한 데이터 네트워크에 대한 변경 또는 새로운 연결

QA 절차 또는 중요 테스트 장비 변경

귀사의 비즈니스에 적합한 정의와 예를 개발하기 위해 프로세스 설계 초기에 여러 분야의 팀이 양질의 "만약에" 브레인스토밍을 하면 엄청난 이익을 얻을 수 있습니다.

'일시적인' 변경은 어떻게 됩니까?
MOC를 구현할 때 적용해야 할 다음 중요한 개념을 기억하십시오. 세상에 일시적인 세금만큼 영구적인 것이 없듯이 MOC 프로세스를 벗어난 "일시적인 변경"보다 더 영구적인 변경은 없습니다. 경험에 따르면 원래 상태로 복원될 때까지 일시적으로 의도된 영구적인 변경 사항만 있습니다. 발생하는 모든 통제되지 않은 변화 중에서 "일시적인" 변화는 사고 및 사건의 가장 해롭고 가장 빈번한 원인입니다. 따라서 제어 시스템의 "일시적인" 변경은 MOC 프로세스에서 면제되어서는 안 됩니다.

따라서 다음과 같은 일상적인 업무를 수행하기 위해 수행해야 하는 일시적인 변경을 처리하려면 어떻게 해야 정기 유지 보수를 수행하기 위한 인터록 바이패스? 그것이 진정으로 일상적이라면 SOP에서 주기적으로 벗어나는 영구적인 상태를 갖게 됩니다. 이에 대처하는 올바른 방법은 상황을 영구적인 변화로 간주하여 적절한 보호 장치가 있는 승인된 절차에 통합하는 것입니다. 무언가가 비일상적인 일시적 변경으로 의도된 경우 변경으로 처리하십시오. OSHA 3133은 "MOC 절차는 일시적인 변경이 끝나면 장비와 절차가 원래 상태로 돌아가도록 해야 합니다."라고 설명합니다. 역사와 신중함은 "일시적인" 변경이 귀하의 비즈니스에 가장 큰 위험을 초래하기 때문에 MOC 절차에 특별한 주의를 기울여 "영구적"으로 관리해야 한다고 제안합니다.

MOC에 대한 8가지 일반적인 오해
1) “하지만 실제 수정은 하지 않습니다. 나는 단지 그것을 조금 더 좋게 만들고 있을 뿐입니다.”
부품/장비/비즈니스 시스템을 작업을 시작하기 전의 상태로 그대로 두고 있지 않은 경우(물론 수리의 대상이었던 손상이 없는 경우) 변경을 수행한 것입니다. . 변경 사항이 MOC 프로세스 범위에 속하는지 여부는 절차에 설정된 기준에 따라 결정됩니다. 기본 접근 방식은 구성, 형태, 적합성, 기능, 재료 또는 절차의 모든 변경이 절차의 기준을 검토하여 달리 입증될 때까지 MOC에 포함된다고 가정하는 것입니다.

통제되지 않은 "일시적 변경"에 이어, 의도된 사소한 개선이 MOC 실패 범주에 속하는 사고의 다음으로 큰 원인입니다. 전체 운영 상황과 환경에 대한 철저한 평가 없이 어떤 면에서 "더 나은" 것이 다른 면에서 훨씬 더 나쁘다고 말할 수 있는 사람은 누구입니까? 한 환자에게 동일한 약을 투여해도 강력한 치료제가 될 수 있습니다. 다른 사람에게는 치명적인 독이 될 수 있습니다. 의도는 좋았지만 통제되지 않은 사소한 "개선", 특히 위험한 재료 대체에도 동일하게 적용됩니다. 모든 직급의 직원에게 이 일반적인 함정을 인식하고 피하도록 교육한 다음 엄격하게 시행하십시오. 규칙을 어긴 사람들을 징계하는 것을 좋아하는 사람은 아무도 없습니다. 특히 그들이 개선 정신을 실천할 때 그렇습니다. 그러나 오늘 밤 누군가가 집에 오지 않을 것이라고 가족에게 말해야 하는 것은 한없이 나쁩니다.

2) “너무 늦어서 MOC를 시작할 수 없습니다. 수정되지 않은 모든 그림을 따라잡지 않겠습니다.”
문서 제어는 잘 설계된 MOC 프로세스를 보완하는 프로세스이며 사람들이 MOC를 언급할 때 가장 먼저 떠올리는 경우가 많습니다. 문서 업데이트의 필요성은 확실히 MOC의 빈번한 결과이며 프로세스 및 시설의 장기적인 무결성을 위해 필요하지만 MOC는 아닙니다. 그것은 단지 빈번한 결과일 뿐입니다.

문서 제어 프로세스와 함께 MOC를 구현할 때 도면 없음, 부정확한 도면, 오래된 문서 등 이전의 사람들로부터 상당한 혼란을 상속받는 경우가 많습니다. . 원하는대로 말만 해. 상황이 심각한 경우 시스템의 중요도를 기반으로 하는 시정 조치의 우선 순위를 지정해야 할 수 있습니다. 일부는 필요하지 않을 수 있으며 절대 수정되지 않습니다. 중요한 정보가 발견되었을 때 이를 수정하는 방법은 확실히 작업 관리 절차에 쉽게 통합될 수 있고 또 그래야 합니다. 그러나 나쁜 습관을 계속해서 과업에 추가하지 마십시오.

과거에 일어난 일은 바꿀 수 없습니다. 과거의 실수를 수정하거나 완화하기 위한 비즈니스 사례가 있다면 그렇게 하십시오. MOC는 미래의 손실 방지에 관한 것입니다. 따라서 모든 조직이 할 수 있는 한 가지는 지금 바로 MOC 구현을 시작하는 것입니다. 오늘은 내일을 위해 더 이상 문제를 일으키지 않는 날입니다. 간결한 민속학은 이렇게 말합니다. 열악한 MOC로 인한 격차에도 동일하게 적용됩니다. 더 크게 만들지 마세요.

3) “MOC 평가를 기다릴 시간이 없습니다. 긴급 상황입니다!”
비상시에는 잘 확립된 MOC 프로세스에 의해 부과된 자기 훈련이 가장 필요한 때입니다. 여객기에 기내 문제가 발생하면 조종사는 가장 먼저 떠오르는 일을 하지 않습니다. 오히려 그들은 체크리스트를 꺼내 생각하고 행동합니다. “비상”이 있을 때, 당신도 그래야 합니다. 교체를 허용하기 위한 이 "사소한 수정"이 올바른 부품을 얻는 것과 비교하여 실제로 그렇게 많은 가동 중지 시간을 절약할 수 있습니까? 사소한 변경은 예상보다 훨씬 많은 시간이 소요되는 경우가 많습니다.

이 "빠른 해결"이 실제로 소요되는 시간, 비용 및 위험 증가에 대해 현실적이어야 합니다. 비상시에 낙관하는 것이 좋습니다. 최악의 상황에 대비하는 것이 가장 좋습니다. “저 멀리 바다에 새는 배를 탄다면 하늘을 향하여 기도하되 해안을 향하여 노를 젓는 것이 좋다”는 말이 있습니다. "일시적인" 우회와 관련된 비즈니스 위험이 시간을 절약할 가치가 있습니까? "특별한 운영 절차"를 통해 위험을 수용 가능한 수준까지 제어할 수 있습니까?

사고 보고서에 따르면 균형 잡힌 평가 없이 압박을 받고 내린 성급한 결정이 많은 심각한 문제의 근원이 되어 왔습니다. . 훈련된 방식으로 생각하는 시간은 낭비되는 시간이 아닙니다. 그리고 MOC 프로세스가 효율적이라면 드문 경우지만 진정한 비상 상황인 경우 진행을 ​​과도하게 방해하지 않을 것입니다. 필요할 때 긴급 작업 지시를 승인하고 발행하는 절차가 있는 것처럼 좋은 MOC 절차에는 실제 긴급 상황을 처리할 수 있는 메커니즘이 있습니다. 그러나 그 메커니즘이 MOC를 무시해서는 안 됩니다. 더 크고 더 심각한 두 번째 비상 사태에 대비하기 위해 한 번의 "비상" 중에 편의를 허용하지 마십시오. 지뢰를 설치하기 위해 폭탄을 해체하지 마십시오.

처리해야 할 해결 방법이 필요한 잦은 고장, 예상치 못한 고장을 복구하기 위해 자정에 부품 교체를 계속해야 하는 경우, 또는 지속적으로 발생하는 경우 불안정한 구성 요소 또는 원자재를 수용하기 위한 공정 변경? 그렇다면 당신의 도전은 MOC를 무시하거나 무정부 상태를 지원하는 MOC 프로세스를 설계하는 것이 아닙니다. 오히려 효과적인 RCFA(근본 원인 고장 분석) 프로세스와 예방 유지 관리/예측 유지 관리 프로그램을 구현하여 만성 장애를 제거함으로써 이러한 상황을 제거하는 데 노력을 집중해야 합니다. 다음으로, 항상 올바른 부품을 사용할 수 있도록 MRO 프로세스의 결함을 수정하는 데 중점을 둡니다. 그리고 마지막으로 표준 작업 절차와 자재 공급업체 자격 프로그램을 통해 프로세스를 안정화해야 합니다.

4) "승인을 위해 이 양식을 전달하는 데 시간이 너무 오래 걸리므로 아무 것도 할 수 없습니다."
효과적인 MOC 프로세스를 위해서는 적절한 수준의 승인과 커뮤니케이션이 필요합니다. 잘못 설계된 MOC 승인 절차는 변경 사항이 발생한 후 알려야 하는 필요성과 변경 사항이 발생하기 전에 승인해야 하는 필요성을 혼동합니다. 필요한 승인 수준은 변경 및 이와 관련된 잠재적 위험 모두에 적절해야 합니다. 또한 당면한 상황에 맞출 수 있도록 충분히 유연해야 합니다. 승인자의 수를 최소화하고 올바른 승인자를 만드십시오. 그러면 MOC 프로세스가 안전하게 간소화될 수 있습니다.

5) "하지만 내 지역 관리자는 이미 변경 자금을 승인해야 합니다."
결정을 내리는 데 필요한 지식의 소유와 결정을 내릴 수 있는 권한을 혼동하지 마십시오. 모든 변경 사항과 종종 가장 중요한 변경 사항이 자금 지원 승인을 통과하는 것은 아닙니다. 종종 변경의 위험이나 변경의 기술적 타당성을 가장 잘 평가할 수 있는 사람은 지역 관리자가 아니라 가장 잘 알고 있는 운영자, 정비사, 감독자 또는 엔지니어입니다.

관리자는 매우 유능하며 한 사람이 주어진 변경의 모든 측면 또는 결과에 대해 유능한 경우는 드뭅니다. 효과적인 MOC 프로세스에서 적절한 지정된 리소스가 제안된 변경 사항에 대한 균형 잡힌 평가에 참여하도록 하는 것은 관리자의 책임입니다. 승인 권한은 평가 능력에 이차적이며 균형 잡힌 팀은 똑똑한 한 사람에게 의존하는 것보다 일관되게 더 좋은 결과를 줄 것입니다.

6) “저희는 창고/경공업/데이터입니다. 센터 / 수리 시설. ... 위험할 수 있는 것은 없습니다."
MOC는 변경과 관련된 모든 잠재적 자해 비즈니스 손실을 예방하거나 완화하기 위한 프로세스임을 기억하십시오. 공정 안전 외에도 다른 손실이 있습니다. 통제되지 않은 프로세스 변경으로 인해 오염되거나 결함이 있는 제품으로 인해 소중한 고객을 잃게 되는 경우 손실입니다. 데이터 센터가 다운되고 전기 도면이 변경 사항을 따라가지 못하기 때문에 문제 해결에 몇 분이 아닌 몇 시간이 걸린다면 손실입니다. 자동 스태커가 다운되어 "조금 수정"이 필요한 심야 부품 교체로 인해 재고가 있는 유일한 교체 부품이 더 이상 맞지 않아 제품을 배송할 수 없는 경우 손실입니다. 제어 소프트웨어에 대한 문서화되지 않은 수정으로 인해 최신 보안 패치가 설치될 때 자동 테스트 기계가 실패하면 손실입니다. 이것들은 모두 실제 예이며 목록은 끝이 없습니다. 귀하의 환경에서 위험한 상황을 초래할 수 있는 변화의 가능성은 작지만, 우리 시설이나 프로세스가 주요 임무에서 실패하면 우리 모두는 잃을 것이 있습니다.

7) “하지만 MOC는 이겼습니다. 가능한 모든 문제를 파악하지 못하는 이유가 무엇입니까?”
당신이 절대적으로 옳습니다. 최선의 노력에도 불구하고 일부 문제는 감지되지 않고 지나칠 수 있습니다. 하지만 MOC를 하지 않으면 얼마나 많은 사람들이 지나칠까요? 위험 관리는 확률을 더 유리하게 변경하는 것입니다. 이 주장은 근거가 없습니다. 일부 사람들이 에어백에 대해 사용하는 주장에 지나지 않습니다. 통계는 MOC가 없다는 것을 지지하는 것 이상으로 그러한 사고 방식을 지지하지 않습니다.

의도하지 않은 결과를 놓치면 어떻게 될까요? 복잡한 시스템에서 MOC의 귀중한 추가 이점은 RCFA를 수행할 때입니다. 변경으로 인한 부정적인 결과가 있고 원인을 즉시 식별할 수 없는 경우 수행한 모든 고의적 변경 목록이 있으면 RCFA가 훨씬 더 빨리 진행됩니다. 그리고 그 시간은 실제 돈이 될 수 있습니다. 한 경우에는 MOC 기록을 조사함으로써 일련의 공정 플랜트 고장의 근본 원인을 찾는 데 필요한 시간을 몇 주나 단축할 수 있었습니다. 가동 중지 시간 손실을 방지하기 위해 하루에 $250,000를 지출하는 MOC 노력은 문제를 예방하지는 못했지만 상당한 투자 수익을 거두었습니다.

8) “이것은 소프트웨어/절차 변경일 뿐입니다. 우리가 파이프를 바꾸거나 그런 것이 아닙니다. 승인하거나 문서화할 필요가 없습니다."
MOC 대상이 아닌 소프트웨어 또는 절차 변경으로 인해 여러 산업 분야에서 일부 극도로 심각한 사고와 심각한 손실이 발생했습니다. 또한 문서나 코드가 변경되어 변경 사항을 반영한다고 해서 변경 사항이 문서화되는 것은 아닙니다. 나는 문서의 코드와 개정 플래그의 주석을 통해 검색자가 변경 사항을 찾을 수 있다는 것을 알고 있습니다. 하지만 소프트웨어나 절차 변경에 대한 검토가 제대로 이루어지지 않아 예상치 못한 문제가 발생했을 때, 그게 무슨 소용이겠습니까?

수천 줄의 코드를 찾아 헤매고 필사적으로 검색하다가 생산 라인이 다운된 적이 있습니까? 제어 엔지니어가 다른 직장으로 떠나기 두 달 전에 변경한 사항은 무엇입니까? 특히 프로그래머와 제어 엔지니어는 MOC에 대한 적절한 고려 없이 소프트웨어를 "장난"하는 경향이 있습니다. 이는 프로세스 제어뿐만 아니라 중요한 비즈니스 시스템 소프트웨어에도 적용됩니다. 잠재적인 위험이 존재하고 이를 정당화하는 경우 코드 줄 변경을 안전 차단 시스템을 다시 배선하는 것과 동일하게 취급하십시오. 동일한 수준의 조사와 통제를 받아야 합니다.

결론
결론적으로 잘 설계된 MOC 프로세스는 모든 비즈니스에 필수적인 손실 방지 도구입니다. 특정 위험 산업에만 해당되는 것은 아닙니다. 이 프로세스는 오늘의 변화로 인한 미래의 손실을 피하고자 하는 모든 회사에 적용됩니다. MOC는 변화를 억제할 정도로 압도적이거나 사용하기 어려울 필요가 없습니다. 과거의 누락을 쉽게 보상할 수 없으며 미래의 위험을 줄일 뿐입니다. 따라서 효과적이고 효율적인 MOC 프로세스를 개발하고 구현하기 시작할 때입니다.

이 기사는 Life Cycle Engineering의 뉴스레터인 RxToday 7월호에 처음 실렸습니다.

저자 정보:
Sam McNair는 LCE(Life Cycle Engineering)의 수석 컨설턴트입니다. 전문 엔지니어이자 공인 유지보수 및 신뢰성 전문가인 Sam은 개별 제조, 화학 공정 산업, 광업, 기계 공정, 자동화, 항공, 건설 및 유틸리티 분야에서 32년 이상의 경험을 보유하고 있습니다. Sam은 유지보수 및 제조 기능의 통합에 중점을 둔 신뢰성 엔지니어링을 전문으로 합니다. [email protected]으로 Sam에게 연락할 수 있습니다. 라이프 사이클 엔지니어링에 대한 자세한 내용은 www.LCE.com을 참조하십시오.