실제 재료 또는 장비가 어떤 식으로든 고장난 경우(예: 데스크톱 컴퓨터가 작동을 멈추거나 타사 공급업체의 구성 요소가 표준 이하의 성능을 제공하는 경우).

사람들이 실수를 하거나 필요한 작업을 완료하지 못한 경우(예: 직원이 장비에 대한 정기적인 유지보수를 수행하지 않아 고장이 발생한 경우).

사람이 의사 결정을 내릴 때 사용하는 시스템, 프로세스 또는 정책에 결함이 있는 경우(예: 회사가 팀원들에게 사이버 보안 프로토콜에 대한 교육을 실시하지 않아 회사가 사이버 공격 에 취약해지는 경우).

근본 원인 분석을 실시하기로 했다면, 해당 부서 또는 조직에서 어떤 종류의 심각한 문제를 겪고 있거나 적어도 특정 프로세스를 실질적으로 개선하고자 하는 것일 가능성이 높습니다. 그러므로 근본 원인 분석 프로세스의 첫 번째 단계는 해결하려는 문제를 파악하고 정의하는 것입니다. 문제가 정확하게 정의되지 않으면 근본 원인을 올바르게 파악하는 것이 불가능합니다.

부서에서 문제를 명확하게 파악했다면 이제 RCA에 도움을 줄 모든 사람을 위해 문제를 설명하는 문제 설명서를 작성할 차례입니다.

문제를 파악하고 모든 관련 당사자에게 명확하게 전달한 후에는, 경영진이 프로젝트 헌장을 작성하여 팀을 구성하고 분석을 완료해야 합니다. 팀에는 분석을 통해 팀을 이끌 진행자와 조사할 시스템, 프로세스 및 사고에 대한 개인적 또는 전문적 지식을 갖춘 팀원이 포함되어야 합니다.

데이터 수집은 문제 해결 프로세스의 근간입니다. 이 단계에서는 문제에 기여한 요인 및 궁극적으로는 문제의 근본 원인을 파악하는 데 도움이 되는 모든 정보를 찾는 것이 중요합니다. 사진 및 사건 보고서 수집, 영향을 받은 당사자와의 면담, 기존 정책 및 절차 검토 등이 여기에 포함될 수 있습니다. 데이터를 수집하는 동안 다음과 같은 질문을 하세요.

• 문제는 언제 시작되었으며 얼마나 오래 지속되었는가?
• 팀이 어떤 증상을 관찰했는가?
• 조직 또는 부서에서 문제가 존재한다는 것을 증명하려면 어떤 문서가 필요한가?
• 이 문제가 직원 및 기타 이해 관계자에게 어떤 영향을 미치는가?
• 이 문제의 존재로 인해 피해를 보거나 영향을 받은 사람은 누구인가?

이는 RCA 프로세스에서 가장 중요한 단계입니다. 이 단계에서 팀은 필요한 모든 정보를 수집하고 원인 요인을 찾기 위한 브레인스토밍을 시작합니다. 근본 원인 분석을 효과적으로 실시하려면 문제의 모든 잠재적인 근본 원인에 대해 개방적인 태도를 취해야 하므로 RCA 팀원 모두가 열린 마음으로 브레인스토밍 단계에 참여해야 합니다. 모든 가능성을 확인하고 검증하기 전에 근본 원인을 결정하려고 해서는 안 됩니다. 선입견을 가지고 사고 조사 과정을 시작하면 결과가 편향되고 실제 근본 원인을 파악하기가 더 어려워질 수 있습니다.

RCA 팀이 가능한 원인과 기여 요인을 모두 정리했다면 이제는 문제의 근본 원인을 파악해야 할 때입니다. 가능한 모든 원인을 분석하고 각 원인이 실제로 미치는 영향을 조사하여 어떤 가능성이 가장 문제가 되는지, 어떤 가능성이 유사한지, 어떤 가능성을 완전히 제거할 수 있는지 알아냅니다. 문제의 근본 원인이 여러 개일 가능성에도 대비해야 합니다.

가능한 원인을 목록으로 추린 후에는 영향과 문제의 근본 원인일 가능성을 기준으로 나머지 잠재적 근본 원인의 순위를 매깁니다. 경영진은 각 가능성을 조사 및 분석하고 RCA 팀과 협력하여 실제 근본 원인을 파악합니다.

팀은 근본 원인을 파악하고 문제의 모든 세부 사항을 식별한 후에 솔루션 브레인스토밍을 시작해야 합니다. 솔루션은 근본 원인을 직접적으로 해결해야 하며, 솔루션을 실행하는 과정에서 발생할 업무량과 팀이 직면할 수 있는 잠재적인 장애물을 고려해야 합니다. 이러한 요소는 팀이 현재 문제를 해결하고 재발을 방지하는 데 도움이 되는 실행 계획에 포함됩니다.

''왜?'라고 5번 묻기' 접근 방식은 '왜?'라는 질문을 다섯 번 던지면 모든 문제의 근본 원인을 파악할 수 있다는 생각에 뿌리를 두고 있습니다. ''왜?'라고 5번 묻기'는 문제를 해결하려는 사람이 섣불리 가정하지 않고 문제의 근본 원인을 파악할 때까지 계속해서 '왜'라고 묻도록 유도합니다. 공식화된 조직에서 근본 원인 분석을 실시하는 경우 팀은 근본 원인을 찾기 위해 '왜?'를 세 번만 물어보고 끝날 수도 있고, 50~60번 물어봐야 할 수도 있습니다. ''왜?'라고 5번 묻기'의 목적은 팀이 정답을 찾는 데 필요한 만큼 많은 질문을 하도록 유도하는 것입니다.

장애 모드 및 영향 분석은 근본 원인 분석에 대한 가장 엄격한 접근 방식 중 하나입니다. 위험 분석과 마찬가지로 FMEA는 시스템/프로세스 장애의 모든 가능성을 식별하고 각 가상 장애의 잠재적 영향을 조사합니다. 이를 통해 조직은 장애를 일으킬 수 있는 모든 근본 원인을 해결합니다.

파레토 차트는 막대형 차트와 꺾은선형 차트의 특징을 결합하여 조직의 가장 일반적인 근본 원인에 대한 빈도를 보여줍니다. 가장 자주 발생하거나 가능성이 높은 것부터 시작하여 근본 원인을 빈도 내림차순으로 확인할 수 있습니다. 그러면 팀은 솔루션을 적용했을 때 조직이 가장 큰 이점을 확인할 수 있는 근본 원인을 해결합니다.

조직은 영향 분석을 통해 각 근본 원인의 긍정적인 영향과 부정적인 영향을 모두 평가할 수 있습니다.

변경 분석은 시스템 또는 프로세스의 성능이 크게 변경된 경우에 유용합니다. 이러한 유형의 RCA를 수행할 때, 부서는 문제 또는 인시던트를 둘러싼 상황이 시간이 지남에 따라 어떻게 변화했는지를 검토합니다. 개인, 정보, 인프라, 데이터 등의 변화를 조사하면 조직에서 어떤 요인이 성과 변화를 일으켰는지 파악하는 데 도움이 될 수 있습니다.

이벤트 분석은 일반적으로 기름 유출 또는 건물 붕괴와 같은 한 가지의 주요한 이벤트 문제의 원인을 파악하는 데 사용됩니다. 이벤트 분석은 인시던트를 초래한 일련의 이벤트를 재현하기 위해 신속하면서도 철저한 증거 수집 프로세스를 활용합니다. 타임라인을 확인하고 나면 조직이 원인과 기여 요인을 더 쉽게 식별할 수 있습니다.

인과 관계 분석이라고도 하는 인과 관계 트리 분석을 통해 조직은 특정 문제에 영향을 미친 모든 의사 결정, 이벤트 또는 행동을 기록하고 인과 관계 트리를 사용하여 시각적으로 표시할 수 있습니다.

이시카와 다이어그램(또는 피시본 다이어그램)은 문제를 둘러싼 상황을 시각화하는 인과 관계 스타일의 다이어그램입니다. 물고기 골격과 비슷하게 생긴 이 다이어그램은 수많은 원인 목록을 관련 하위 카테고리로 그룹화합니다.

DMAIC는 정의(Define), 측정(Measure), 분석(Analyze), 개선(Improve), 제어(Control)의 약자입니다. 이 데이터 기반 프로세스 개선 방법론은 조직의 식스 시그마(Six Sigma)에 포함되어 사용됩니다.

이 RCA 방법론은 4단계 문제 해결 프로세스를 통해 문제의 근본 원인을 찾습니다. 이 프로세스는 상황 분석으로 시작하여 문제 분석 및 솔루션 분석으로 이어지며, 마지막 단계인 잠재적인 문제 분석으로 끝납니다.

조직은 FTA를 통해 잠재적인 인과 관계를 시각적으로 매핑하고 부울 논리를 사용하여 근본 원인을 식별할 수 있습니다.

방지벽 분석은 적절한 방지벽이 문제와 인시던트를 예방할 수 있다는 생각에 기초합니다. 위험 관리에 자주 사용되는 이러한 유형의 RCA는 적절한 방지벽이 없음으로 인해 인시던트가 발생하게 된 관계를 조사하고, 문제가 재발하지 않도록 도와 줄 방지벽을 제시합니다.