Root cause analysis: Digging to find effective solutions (with examples)

'문제의 근원에 접근해보자'는 해결책을 찾을 때 흔히 사용하는 관용구입니다. 이 관용어는 표면 아래 나무 뿌리의 양식으로 시각화할 수 있습니다. 나무 뿌리는 보이지 않지만, 지상에서는 나무가 자라는 것이 분명하게 보입니다. 때때로 이 성장은 긍정적이고 아름다운 나무로 이어지기도 하지만, 때때로 부정적이고 보도와 기초를 손상시키기도 합니다. 

일부 문제가 발생하는 이유를 처음에 이해하지 못할 수 있으므로 근본 원인을 이해하는 것이 매우 중요합니다. 피시본 다이어그램과 5가지 Why 방법과 같은 툴을 사용하여 RCA를 수행하면 복잡한 문제를 명확히 하여 효과적이고 지속 가능한 해결책으로 이어질 수 있습니다. 이 글에서는 근본 원인 분석을 수행하는 방법에 대해 논의하고 프로세스 개선을 위한 문제 해결 전략을 제공합니다. 

근본 원인 분석이란 무엇인가요?

근본 원인 분석(RCA)은 문제의 근본 원인을 찾아 해결책을 식별하고 구현하는 것을 포함합니다. RCA는 문제 자체의 표면적 증상 대신 문제의 근본 원인을 다룹니다. 

예를 들어, 회사의 리텐션이 낮은 경우 더 많은 팀원을 채용하는 것이 빠른 해결책입니다. 그러나 RCA를 사용하면 팀원이 회사에 머무르지 않는 이유를 대신 발견하여 장기적으로 리텐션을 높일 수 있습니다. 리텐션률이 낮은 근본 원인은 다음과 같습니다.

• 전문성 개발 기회 부족

• 팀원 복지 혜택 부족

• 시장 범위와 비교할 때 낮은 급여

• 팀의 사기 저하

가능한 근본 원인을 고려한 후 조사를 사용하여 하나 이상의 근본 원인을 결정할 수 있습니다. 이러한 근본 원인을 이해하면 솔루션을 쉽게 구현할 수 있습니다. RCA는 문제를 임시방편으로 해결하고 문제가 다시 발생할 위험을 감수하는 대신 문제를 체계적으로 해결합니다. 

RCA의 핵심 원칙

근본 원인 분석은 반복되는 프로젝트 문제나 비즈니스 프로세스 내의 더 큰 병목 현상을 해결할 수 있습니다. 이 방법의 고유한 이점을 누리려면 RCA의 핵심 원칙을 염두에 두세요.

• 문제의 증상을 수정하는 대신 근본 원인에 집중하세요.

• 누가 문제를 일으켰는지보다는 문제가 어떻게 그리고 왜 발생했는지에 더 집중하세요.

• 식별한 근본 원인을 뒷받침할 수 있는 인과관계의 증거를 찾으세요.

• 솔루션을 지원하기 위한 유익한 실행 계획을 수립합니다.

• 향후 근본 원인이 재발하지 않도록 하는 방법을 고려하세요.

문제의 근본 원인이 여러 개일 수 있으며, 이는 비정상적인 일이 아닙니다. 가장 정확하다고 생각하는 근본 원인으로 마무리하고 강력한 해결책으로 대처할 준비를 합니다. 

근본 원인 분석 수행 방법

RCA에서 근본 원인을 식별하는 데 사용할 수 있는 다양한 전략이 있습니다. 아래 단계에 따라 팀을 RCA 프로세스로 안내하세요. 

1. 문제를 정의합니다

근본 원인 분석을 수행하려면 명확하게 정의된 문제가 필요합니다. 해결하고 싶은 문제가 여러 개인 경우, 한 가지 문제부터 시작하여 여러 RCA를 수행하여 각 문제에 대한 해결책을 찾는 것이 가장 좋습니다. 한 번에 하나의 문제를 해결하면 각 문제의 원인을 찾아 신속하게 해결할 수 있는 가능성이 높아집니다.

문제를 정의하는 것은 모두가 동일한 이해를 바탕으로 업무를 수행하도록 하는 것과도 관련이 있습니다. 예를 들어, 팀의 생산성이 낮다고 생각하기 때문에 RCA를 수행하고 싶을 수 있습니다. 그러나 팀이 생산성이 낮다고 느끼지 않는다면, 더 이상 나아갈 수 없습니다. 생산성은 주관적이므로 문제를 보다 측정 가능한 방식으로 정의하고 2단계로 넘어가 증거를 사용하여 문제에 대해 자세히 알아보아야 할 수 있습니다. 

2. 데이터 수집

이제 문제가 존재한다는 생각을 뒷받침할 증거를 수집해야 합니다. 회사 리서치를 활용하여 문제의 증상을 더 잘 이해할 수도 있습니다. 이 단계에서 해야 할 질문은 다음과 같습니다.

• 문제가 얼마나 오래되었나요?

• 이 문제로 인해 고통을 겪고 있는 사람은 누구인가요?

• 이 문제의 단기적, 장기적 영향은 무엇인가요?

• 이 문제의 주요 증상은 무엇인가요?

• 문제가 있다는 생각을 뒷받침할 수 있는 증거는 무엇인가?

이 문제가 회사와 팀에 미치는 영향에 대해 자세히 파악하면 문제의 잠재적 원인을 브레인스토밍할 수 있습니다. 

3. 가능한 근본 원인을 식별합니다

가능한 근본 원인을 식별하는 것은 근본 원인 분석 프로세스에서 가장 중요한 부분입니다. 이 단계에서 발견한 원인은 결국 해결책과 실행 계획으로 이어집니다. 일반적인 문제 해결 전략은 다음과 같습니다.

• 인과 관계 흐름도: 아래에 제공된 무료 근본 원인 분석 템플릿에는 인과 관계 흐름도가 있습니다. 이 흐름도는 논리적 해결책을 찾기 위해 문제를 증상, 가능한 원인, 실제 원인으로 세분화합니다. 

• 5가지 이유 접근법: 5가지 이유 접근법을 사용하여 문제의 근본 원인을 파악할 수도 있습니다. 문제를 그대로 받아들이는 대신, 의도한 대로 작동하지 않는 프로세스나 시스템을 발견할 때까지 "왜"인지 물어보세요. 5가지 이유 템플릿을 사용하면 프로세스를 구성할 수 있으므로 첫 번째 답변에 만족하지 않고 즉시 눈에 띄지 않는 문제의 계층을 발견할 수 있습니다.

4. 근본 원인을 판단합니다

문제의 근본 원인을 파악하기 위해 가능한 한 많은 근본 원인을 살펴보아야 합니다. 모든 가능성을 다 사용한 후에는 다음과 같은 질문을 하세요.

• 내가 식별한 근본 원인 사이에 유사점이 있나요?

• 이러한 가능한 근본 원인을 제거해야 하는 이유가 있나요?

• 어떤 근본 원인이 가장 문제가 되는 것 같나요?

가능한 근본 원인을 찾을 때 사용한 전략과 유사하게, 실제 근본 원인을 파악하는 데 사용할 수 있는 전략이 있습니다. 이러한 전략에는 다음이 포함됩니다.

• 고장 모드 및 영향 분석(FMEA): FMEA는 리스크 분석과 유사한 도구로, 식별한 가능한 근본 원인을 살펴보고 나중에 고장으로 이어질 가능성이 가장 높은 원인을 제거합니다. 

• 영향 분석: 영향 분석을 사용하여 식별한 각 가능한 근본 원인의 긍정적 및 부정적 영향을 평가합니다. 각 원인에 대해 이러한 가상의 장단점 목록을 만들면 목록을 좁히는 데 더 자신감을 가질 수 있습니다.

문제의 단일 근본 원인을 파악하는 데 어려움을 겪을 수 있으며, 이는 괜찮습니다. 문제에 기여하는 요인이 여러 개라고 생각되면 해결할 요인을 하나만 선택해야 한다는 부담감을 느끼지 마세요. 실행 계획을 간소화하는 것은 좋지만, 문제를 해결하기 위해 여러 계획을 세워야 할 때도 있습니다.

5. 해결책 구현

확인한 근본 원인에 자신감이 생기면 이제 이러한 원인에 대한 해결책을 찾고 조치를 취할 차례입니다. 도출한 해결책은 근본 원인을 해결해야 하지만, 결과적으로 이러한 해결책은 체인을 거꾸로 따라 올라가서 초기 문제를 해결할 것입니다. 

솔루션을 개발할 때 다음과 같은 질문을 스스로에게 해보세요.

• 이 솔루션을 선택하면 어떻게 구현할 것인가?

• 이 솔루션을 구현할 때 직면하게 될 장애물은 무엇인가요?

• 이 솔루션을 구현하는 데 얼마나 걸리나요?

• 누가 이 솔루션을 구현할 것인가?

• 이 솔루션을 구현하면 다른 문제가 발생할 수 있나요?

실행 계획을 작성할 준비가 되면 모든 이해관계자가 볼 수 있는 툴에서 공유해야 합니다. 프로젝트 관리 소프트웨어를 사용하면 팀이 필요에 따라 결과물을 손쉽게 협업하고 조정할 수 있습니다. 계획을 실행하는 데 몇 주가 걸릴 수 있으며, 이는 일부 목표가 다른 마일스톤에 종속될 수 있음을 의미합니다. 간트 차트를 사용하여 프로젝트 종속성을 확인하고 실시간의 협업을 수행합니다.

근본 원인 분석 템플릿 및 예시

RCA 템플릿을 사용하면 플로 차트 양식으로 문제와 근본 원인을 시각화할 수 있으므로 근본 원인 분석을 더 간단하게 수행할 수 있습니다. 나무의 뿌리와 마찬가지로, 이 인과 관계 흐름도는 초기 문제와 다른 방향으로 확장됩니다. 

아래의 근본 원인 분석 예시를 따르면 템플릿이 하나의 문제로 시작하여 문제가 표시하는 증상으로 세분화되는 방식을 확인할 수 있습니다. 근본 원인 분석 템플릿은 증상에서 실제 근본 원인을 확인하고 해결책을 찾기 전에 가능한 근본 원인을 판단하는 데 도움이 됩니다. 

이 예시에서 회사는 웹사이트 조회수가 감소하고 있습니다. 근본 원인 분석은 다음과 같은 흐름으로 진행됩니다.

문제:

• 웹사이트 조회수가 감소했습니다

증상:

• 브랜드 가시성 감소

• 온라인 구매 부족

• 낮은 도메인 권한

가능한 근본 원인:

• 웹사이트 기술적 문제

• SERP에서 경쟁사 순위가 더 높음

• 약한 CTA

• 고객이 제품을 좋아하지 않음

• 고객이 구매할 웹사이트를 찾을 수 없음

• 품질이 좋지 않은 내용

• 관련 없는 백링크

실제 근본 원인:

• SEO 내용 부족

• 웹사이트가 SERP에 순위가 없습니다

• 관련 키워드 부족

해결책:

• 콘텐츠 개선

아래에서 무료 근본 원인 분석 템플릿을 다운로드하여 직장에서 겪고 있는 문제의 가능한 원인과 해결책을 식별하는 데 사용할 수 있습니다. RCA 템플릿을 사용하면 처음에 명확하지 않을 수 있는 근본적인 문제를 해결하는 데 도움이 됩니다.

근본 원인 분석 툴 및 방법

근본 원인 분석은 지속적인 개선과 리스크 관리 작업량의 초석이 됩니다. 문제 또는 사건의 실제 근본 원인을 찾아내는 체계적인 프로세스를 제공합니다. 

근본 원인 분석 툴은 증상을 뛰어넘어 RCA 팀이 문제의 근본 원인을 더 깊이 파고들 수 있도록 지원합니다. 이러한 심층 분석은 일시적인 해결책으로 이어질 뿐만 아니라, 더 효과적이고 장기적인 해결책으로 이어져 도전을 지속적인 개선의 기회로 전환합니다.

파레토 차트

80-20 법칙으로도 알려진 파레토 법칙에 기반한 파레토 분석은 가장 큰 보상을 주는 작업이나 문제 영역을 식별하는 데 도움이 되는 의사 결정 기법입니다. 파레토 분석은 단일 효과로 이어지는 여러 가지 원인이 있을 때 특히 효과적입니다. 이 방법은 다양한 비즈니스 및 조직 부문에서 널리 적용되어 가장 큰 영향을 미치는 조치의 우선순위를 정하는 데 도움이 됩니다.

5 Whys

5 Whys 방법은 특정 문제의 근본에 있는 인과 관계를 분석하는 데 사용되는 반복적인 질문 방법입니다. 이 방법에서는 '왜?'라는 질문을 반복적으로 던져 문제의 실제 근본 원인으로 이어지는 증상의 층을 벗겨내는 것입니다. 5가지 Why 기법은 문제를 해결하고, 비용을 절감하고, 품질을 개선하기 위해 린(Lean) 방법론에서 널리 사용됩니다.

이시카와 피시본 다이어그램

이시카와 다이어그램이라고도 하는 피시본 다이어그램은 인과 관계를 시각적으로 보는 방법입니다. 문제의 잠재적 근본 원인을 감지하기 위한 브레인스토밍에 도움이 되며 제품 디자인 및 품질 관리에 사용됩니다. 이시카와 다이어그램은 물고기 입구에 효과나 문제를 표시하고, 잠재적인 원인은 작은 "뼈대"에 추가됩니다.

고장 트리 분석

고장 트리 분석은 시스템 수준의 고장의 원인을 판단하기 위해 모든 질문에 대한 답변이 '예' 또는 '아니요'인 부울 논리를 사용하는 그래픽 도구입니다. 제약, 항공우주, 소프트웨어 엔지니어링과 같은 산업 분야의 리스크 평가에 적합합니다. 이 도구는 이벤트를 순서대로 정렬하고 논리 기호를 사용하여 이벤트 간의 종속성을 표시합니다.

고장 모드 및 효과 분석(FMEA)

FMEA에는 구성 요소, 하위 시스템 및 어셈블리를 검토하여 시스템의 약한 링크와 그 원인 및 영향을 찾는 작업이 포함됩니다. 1950년대 후반에 개발된 이 방법은 제품, 프로세스 또는 서비스를 설계하고 새 프로세스 또는 수정된 프로세스에 대한 제어 계획을 수립하는 데 사용되는 정량적 및 정성적 분석 방법입니다.

산점도

산점도(散點圖)는 각 축에 하나의 변수가 있는 수치 데이터 쌍을 플롯하여 이들 사이의 관계를 검토하는 그래픽 툴입니다. 변수가 상관관계가 있을 때, 점은 직선 또는 곡선을 따라 정렬됩니다. 점들이 선 주위에 얼마나 밀집되어 있는지는 상관관계의 강도를 나타냅니다. 이 근본 원인 분석 도구는 7가지 기본 품질 도구 중 하나로 간주되며 근본 원인 분석에서 서로 다른 변수 간의 관계를 결정하는 데 필수적입니다.

DMAIC 템플릿

DMAIC(Define, Measure, Analyze, Improve, Control)는 프로세스를 최적화하기 위해 식스 시그마에서 사용되는 구조화된 접근 방식입니다. 이는 개선에 대한 정량화 가능한 증거를 제공하며 문제를 감지하고 솔루션을 개발하기 위한 반복 가능하고 이해하기 쉬운 방법입니다. 이 템플릿은 프로젝트 매니저와 RCA 팀에 적합합니다.

8D 보고서 체크리스트 템플릿

8D 보고서 템플릿은 문제 해결의 8가지 분야를 기반으로 하는 상세한 근본 원인 분석에 사용됩니다. 자동차 및 의료 부문과 같이 고객 피드백의 영향을 받는 산업에서 널리 사용됩니다. 이 템플릿은 문제가 처음 발견되지 않은 지점을 나타내는 "이탈 지점"에 초점을 맞춰 문제를 식별하고 근절하는 데 도움이 됩니다.

이벤트 및 인과적 요인 분석

이벤트 및 인과적 요인 분석은 문제로 이어진 일련의 이벤트와 인과적 요인을 식별합니다. 이 분석은 사건의 시간적 순서와 문제에 기여한 특정 조건 또는 조치를 이해하는 데 중점을 둡니다. 인과 관계 다이어그램은 여러 요인이 상호 작용하여 문제를 일으키는 복잡한 상황에서 특히 유용합니다. 

변경 분석

변경 분석은 특히 품질 관리 및 지속적인 개선 작업에서 효과적인 근본 원인 분석의 핵심 구성 요소입니다. 이 방법은 문제 발생 전후의 상황이나 시스템을 조사하고 비교하는 것을 포함합니다. 

변경된 사항을 식별하면 인과 관계를 더 정확하게 분리할 수 있습니다. 변경 분석은 프로세스, 자재, 인력 또는 장비 변경 후 문제가 발생한 시나리오에서 유용하며, 문제의 실제 근본 원인을 신속하게 파악하는 데 도움이 됩니다.

장벽 분석

장벽 분석은 사고를 방지하기 위해 마련된 통제 및 장벽과 이러한 안전 점검이 실패한 이유를 조사하는 문제 해결 프로세스입니다. 근본 원인 분석 팀은 이러한 장벽의 고장이나 부재를 분석하여 인적 오류, 시스템 결함 및 기타 잠재적인 근본 원인을 식별할 수 있습니다. 장벽 분석은 더 강력한 시스템과 프로세스를 개발하여 향후 유사한 문제가 발생하지 않도록 하는 데 도움이 됩니다.

효과적인 근본 원인 분석을 수행하기 위한 팁

문제를 해결할 뿐만 아니라 문제가 재발하지 않도록 방지하는 방법에 대해 궁금해한 적이 있나요? 근본 원인 분석 방법이 핵심입니다. 이러한 방법은 문제의 핵심에 접근하고 근본 원인을 해결하며 지속적인 개선을 위한 길을 닦습니다. 

이 접근 방식은 일시적인 해결책을 제공할 뿐만 아니라 동일한 문제가 다시 발생하지 않도록 하여 프로세스와 결과의 지속적인 개선을 촉진합니다.

팀 협업 장려

팀 협업을 촉진하면 근본 원인 분석의 효과를 크게 높일 수 있습니다. 다양한 관점과 전문 지식을 통해 문제를 보다 포괄적으로 이해하고 효과적인 해결책을 개발할 수 있습니다.

예: 장비 고장이 빈번한 제조 회사를 생각해 보세요. 엔지니어링, 유지 보수 및 운영 부서의 멤버로 교차 기능 RCA 팀을 구성하면 인사이트를 수집하여 근본 원인을 식별할 수 있습니다. 

엔지니어는 설계 결함을 정확히 찾아낼 수 있으며, 유지 보수 작업자는 마모 및 파손 문제를 식별할 수 있으며, 운영자는 운영 오류를 강조할 수 있습니다. 이러한 협업 방식은 포괄적인 문제 진술을 도출하여 다면적이고 효과적인 해결책으로 이어집니다.

개방형 질문하기

개방형 질문은 근본 원인 분석에서 핵심입니다. 질문을 하면 문제에 대해 자세히 탐색할 수 있어 팀원들이 다양한 가능성을 고려하고 근본 원인을 더 깊이 파고들 수 있습니다.

예: 의료 환경에서 환자 재입원이 증가하는 경우, "이러한 재입원 중 공통적인 요인은 무엇인가요?"와 같은 개방형 질문을 던집니다. 또는 "재입원 환자의 퇴원 프로세스는 어떻게 달라지나요?"와 같은 개방형 질문을 하면 더 깊은 문제를 드러낼 수 있습니다. 

이러한 질문은 특정 퇴원 절차가 일관되게 준수되지 않는다는 사실을 드러낼 수 있으며, 이는 퇴원 시 환자 교육이 충분하지 않은 근본 원인이 될 수 있습니다.

비난을 피하세요

성공적인 근본 원인 분석의 핵심은 개인의 잘못을 탓하기보다는 프로세스에 집중하는 것입니다. '누가' 책임이 있는지가 아니라 문제의 '왜'와 '어떻게'에 집중하는 것은 진정한 문제 해결과 개선에 도움이 되는 환경을 만듭니다.

예: 프로젝트 지연이 빈번한 소프트웨어 개발 팀에서는 개인을 비난하기보다는 프로세스에 집중하는 것이 더 생산적일 수 있습니다. '왜'와 '어떻게'를 분석하여 '왜 이러한 지연이 발생하는가?' 또는 또는 "프로젝트 관리 전략을 어떻게 최적화할 수 있을까요?"라고 질문하는 것과 같습니다. 근본 원인이 개인의 무능력이 아니라 비현실적인 타임라인이나 불분명한 커뮤니케이션 채널이라는 것을 발견할 수 있습니다. 

비난에서 프로세스 지향적 사고로의 이러한 전환은 보다 효과적이고 조화로운 문제 해결 환경을 조성하는 데 도움이 됩니다.

워크플로로 솔루션을 실행으로 옮기기

RCA는 즉각적인 결과를 제공하지 않지만, 문제의 근본 원인을 파악하면 문제를 완전히 해결할 수 있습니다. 효과적인 해결책을 찾은 후에는 계획을 실행에 옮겨야 합니다. Asana 워크플로는 목표를 설정하고, 진행 상태를 추적하고, 실시간의 문제 해결을 위한 단일 정보 소스를 제공합니다.