근본 원인 분석
근본 원인 분석(root cause analysis)은 무언가가 왜 잘못되었는지, 답이 더 이상 움직이지 않을 때까지 묻는 일입니다. 뿌리를 고치면 그 위의 증상도 함께 사라지고, 증상만 고치면 다시 돌아옵니다. 품질 관리, IT 장애 대응, 환자 안전, 항공 분야는 모두 실패 뒤에 근본 원인 분석을 요구합니다. 방법들은 주로 이 점에서 다릅니다: 누가 추론하는가.
방법들
5 Whys(왜를 다섯 번 묻기)실패에 대해 ‘왜’를 묻고, 그 답에 대해 다시 묻기를 다섯 번 합니다. 한 사람이나 작은 팀이 합니다. 빠르고 비용이 적게 들며, 원인의 사슬 하나를 찾아냅니다 — 묻는 사람이 이미 의심하던 사슬입니다. 원리가 하나뿐인 단일 사고에 좋고, 원인들이 서로 얽혀 있으면 약합니다.
피시본(이시카와) 다이어그램원인을 사람, 공정, 장비, 자재, 환경 같은 범주로 나누어 등뼈에서 뻗은 가시처럼 그립니다. 진행자가 그룹의 제안을 받아 채웁니다. 깊기보다 넓습니다. 후보는 나열하지만 어떤 원인이 어떤 원인에 영향을 주는지는 말해 주지 않습니다.
결함 나무 분석실패에서 출발해 AND/OR 게이트를 거쳐 기본 사건까지 내려가는 하향식 논리 나무입니다. 구성 요소와 그 고장 방식이 알려진 공학 시스템에는 엄밀합니다. 분석가가 만들며, 사회 문제에서는 좀처럼 구할 수 없는 데이터가 필요합니다.
파레토 분석사고를 범주별로 세고, 대부분을 차지하는 범주를 고칩니다. 어디가 아픈지는 말해 주지만 무엇이 원인인지는 말해 주지 않습니다 — 원인을 찾는 도구가 아니라 우선 처리할 곳을 가리는 도구입니다.
구조화된 민주적 대화(Structured Democratic Dialogue)문제를 겪고 있는 사람들이 후보 원인을 쓰고, 명확히 한 다음, 각 원인이 다른 원인에 크게 영향을 주는지 한 번에 한 쌍씩 75% 기준으로 판단합니다. 알고리즘(해석적 구조 모델링)이 답을 모아 영향 지도를 만들고, 지도 맨 아래에 있는 원인이 근본 원인입니다. 50년의 실천과 기록된 대화 수백 건이 있습니다. 이 사이트가 진행하는 방법이 바로 이것입니다.
그룹이 분석가보다 나은 경우
질문 하나로 정해집니다. 그 원인을 아는 사람이 방 안에 있는가? 기계가 고장 났다면 로그를 가진 엔지니어가 투표하는 열다섯 명보다 빨리 원인을 찾을 것입니다. 배송이 늦어지거나, 환자가 기다리거나, 학교에서 교사가 떠나거나, 마을이 신뢰를 잃고 있다면, 원인은 관련된 사람들에게 흩어져 있습니다 — 야간 근무조가 하나를 알고, 배차 담당자가 또 하나를, 고객이 세 번째를 압니다 — 그리고 그 모두를 쥔 분석가는 없습니다. 그렇다면 방법은 모두에게서 원인을 모으고 모두가 연결을 판단하게 해야 합니다. 그렇지 않으면 분석가가 이미 믿던 것만 찾게 됩니다.
일반적인 그룹 토론으로도 이것이 안 되는 이유는 연구 결과 두 가지로 설명됩니다. 원인 사이의 연결을 따져 보기 전에 중요도에 따라 원인의 순위를 매기라고 하면 사람들은 순위를 잘못 매깁니다 — 이것이 잘못된 우선순위 효과(erroneous priorities effect)입니다 — 또 그룹에 생각을 물으면 생각이 너무 넓게 흩어져 어느 것도 과반을 얻지 못합니다 — 이것이 생각 흩어짐(spreadthink)입니다. 구조화된 대화는 이 둘을 염두에 두고 만들어졌습니다. 연결을 판단하기 전에는 순위를 매기지 않고, 연결은 하나씩 압도적 다수로 판단합니다.
좋은 근본 원인 분석이 내놓는 것
- 지도: 목록이 아니라, 어떤 원인이 어떤 원인에 영향을 주는지 보여 주고 근본 원인이 맨 아래에 놓입니다.
- 각 연결과 그 연결을 뒷받침하는 동의 수준. 읽는 사람이 무엇이 확정되었고 무엇이 아닌지 볼 수 있습니다.
- 이견이 평균으로 지워지지 않고 기록에 남습니다.
- 가장 요란한 증상이 아니라 근본 원인에 비추어 판단한 대책.
일곱 단계 템플릿 ·
실제 숫자로 보는 예시 ·
그룹이 몇 개든 이 사이트가 진행하는 방법