근본 원인 분석(RCA) 이해하기
‘효율성 향상’은 기업이 끊임없이 추구하는 목표 중 하나입니다. 반복되는 문제와 비효율적인 프로세스는 리소스를 낭비하고, ROI를 낮추고, 사기를 떨어뜨립니다. 하지만 오랫동안 지속되어 온 뿌리 깊은 문제를 해결하고 기존 시스템을 개선하는 일은 생각만큼 쉽지 않습니다. 그래서인지 많은 관리자는 지금 당장 눈에 보이는 문제 해결에 집중합니다. 이는 근본적인 해법이 될 수 없습니다.
근본 원인 분석(RCA, Root Cause Analysis)은 명칭에도 포함되어 있듯 문제의 근본을 파악하기 위한 방법론으로, 효과적인 변화를 이끄는 전략이기도 합니다.
진정한 변화를 주도하는 근본 원인 분석에 대해 다음 내용을 중심으로 살펴봅니다.
근본 원인 분석이란?
근본 원인 분석(RCA)은 문제나 비효율성의 핵심을 파악하여 이를 해결하는 가장 좋은 방법을 찾는 체계적인 접근 방식입니다. 이 방법론은 표면적인 증상이 아닌, 원인에 집중합니다. 근본 원인을 파악하고 해결함으로써 반복되는 문제를 방지하고, 기존 프로세스를 개선한다는 개념을 기반으로 합니다.
근본 원인 분석은 크고 작은 사고, 유지 관리 및 제조 문제, 의료 실수, 환경 방출(밀폐된 환경에서 재배하던 생물을 자연계로 내보내는 행위), 생산성 문제, 인적 과실로 발생하는 일상적인 사고 등 다양한 상황의 문제를 해결하고, 필요한 예방 조치를 기술하기 위해 사용됩니다.
근본 원인 분석 방법
다양한 접근 방식이 있지만 프로세스는 모두 동일합니다.
1. 문제 또는 목표 정의
첫 단계는 해결 문제나 개선 사항을 정의하는 것입니다. 문제를 명확하고 구체적으로 이해하는 것이 중요합니다.
문제나 개선 목표를 완전히 파악한 다음에는 관련 데이터를 수집하고 분석을 문서화합니다. 이때 다음을 고려합니다.
- 문제가 비즈니스 전반에 미치는 영향
- 문제가 발생하는 빈도 또는 비효율성이 느껴지는 빈도
- 문제 또는 프로세스를 측정하는 방법
예를 들어, 신제품 출시가 자주 늦어진다고 느끼는 운영 관리자가 있다고 가정해 봅시다. 이런 경우 운영 관리자는 데이터와 인사이트를 취합하여 제품 출시가 일정보다 얼마나 자주 지연되는지 정확하게 확인하고, 문제를 구체적으로 기술합니다. 그뿐만 아니라 출시가 지속적으로 늦어진다면 고객 경험과 고객 신뢰도가 떨어져 이탈률이 증가하고 수익에 부정적인 영향을 주므로, 비즈니스와 관련된 전반적인 문제에 대해서도 논의할 수 있습니다.
2. 가능한 근본 원인 브레인스토밍
문제를 파악했다면 그 문제의 원인이 될 수 있는 모든 이슈나 이벤트를 나열합니다. 효율성을 높이기 위해 프로세스를 개선하고자 한다면 현재 워크플로우의 모든 단계를 자세히 기술합니다. 근본 원인을 알아내야 한다는 중압감이나 걱정은 버리고 떠오르는 모든 것을 브레인스토밍하세요.
그런 다음 가능성이 있는 각 이슈나 이벤트가 미치는 실제 영향을 분석합니다. 원인처럼 보이지만 실제로는 그렇지 않은 것은 제외합니다. 이를 위해 추가 조사가 필요할 수도 있습니다. 그런 다음 마지막으로 남은 원인의 우선순위를 정하여, 가장 많이 영향을 미치는 것과 가장 적게 영향을 미치는 것을 파악합니다.
제품 출시가 늦어지는 것을 걱정하는 운영 관리자의 예로 다시 돌아가 보겠습니다. 이 경우 설계 게시판이나 다른 제품 개발 프로세스에서 시작하여 모든 단계에서 가능한 근본 원인을 브레인스토밍할 수 있습니다. 이 과정에서 운영 관리자는 다음과 같은 가능성을 나열할 수 있습니다.
- 아이디어가 ‘할 일’ 목록에 너무 오래 머무르거나 기한 내에 시작되지 않는다.
- 작업이 팀원에게 빠르게 할당되지 않는다.
- 승인이 너무 오래 걸린다.
- 사용자 피드백이 너무 오래 걸린다.
- 사용자 피드백이 손실된다.
운영 관리자는 가능성이 있는 근본 원인을 적은 전체 목록을 놓고 하나하나 분석합니다. 이 과정에서 팀원에게 질문을 하거나 디지털 업무 설계 정보를 검토하여 팀이 사용자 피드백을 받는 데 걸리는 시간과 그 피드백이 내부적으로 공유되는 방식을 파악해야 할 수도 있습니다.
3. 해결책 마련
문제의 근본 원인 즉, 시스템이나 프로세스의 성능을 저하시키는 근본 원인을 파악하고 자세히 기술했다면 이제는 문제를 해결할 수 있는 솔루션을 브레인스토밍합니다. 이때 업무와 관련된 부서 직원들과 인터뷰하여 의견과 제안을 수집하는 것도 좋습니다.
앞에서 소개하고 있는 운영 관리자의 예에서, 사용자 피드백이 제품 출시를 지연시키는 주요 원인이라고 가정해 보겠습니다. 그렇다면 관리자는 가능한 해결책을 마련하기 위해 팀원들과 함께, 사용자의 피드백을 수집하기 위해 사용하고 있는 채널과 피드백 수집 전략, 팀과 공유하는 방법 등을 논의합니다. 가능한 해결책으로는 피드백을 요청하는 프로세스를 개발하고, 의견과 아이디어가 수집되는 대로 이를 관리할 담당자를 지정하는 것이 있습니다.
4. 해결책 구현
해결책을 설계하고 검증했다면 새로운 프로세스와 해결 방법이 실패하지 않도록 전략적으로 구현합니다. 해당 문제와 관련된 팀원들의 승인이나 경영진의 지원을 받아야 할 수도 있습니다. 팀을 꾸렸다면 해결책이 잘 구현되도록 담당자나 프로젝트 관리자를 지정합니다.
앞에서 든 예에서, 운영 관리자는 더 나은 피드백 요청 프로세스를 개발하기 위해 팀원을 지정하고, 수집되는 피드백을 감독할 팀원을 지정할 수 있습니다. 관리자는 해결책이 잘 구현되었는지 확인하기 위해 해당 팀원과 반복적으로 검토해야 합니다.
5. 결과 모니터링
구현된 해결책에 따라 모니터링 기간은 몇 주, 몇 달이 걸릴 수 있습니다. 제안된 해결책이 효과적이지 않다면 조정해야 합니다. 반복적으로 조정해도 효과적이지 않다면 파악한 다른 주요 원인의 해결책을 브레인스토밍하고 구현합니다.
다시 예로 돌아가 보면, 운영 관리자는 적어도 몇 번의 제품 출시 주기 동안 새로운 사용자 피드백 프로세스를 모니터링합니다. 먼저, 팀이 더 많은 피드백을 받거나 적어도 이전보다 빠르게 피드백을 받는지 검사하여 새로운 피드백 요청 프로세스가 효과적인지 확인합니다. 또한, 수집되는 피드백이 이전보다 빠르게 팀과 공유되도록 합니다. 그리고 마지막으로 제품 출시 일정을 검토하여 고객 피드백을 반복하여 반영한 개선 사항이 전반적으로 출시 시간을 단축했는지 확인합니다.
그 피드백이 빠르게 수집되지 않거나 팀이 제품 출시 일정을 맞추는 데 도움이 되지 않는다고 느낀다면, 운영 관리자는 가능성이 있는 근본 원인 목록으로 돌아가 다른 가능한 원인의 해결책을 개발합니다. 피드백이 빠르게 반복적으로 반영되어 적시에 제품이 출시되더라도 다른 가능한 원인을 선택하고 프로세스를 개선할 수도 있습니다.
근본 원인 분석의 다양한 방법과 접근 방식
근본 원인 분석은 문제나 이벤트에 영향을 주는 요인을 파악합니다. 근본 원인 분석 프로세스가 유연한 것처럼, 근본 원인 분석 방법과 접근 방식도 다양합니다.
- 변화 분석 — ‘변경 영향 분석’이라고도 하는 이 접근 방식은 편차의 근본 원인을 파악하기 위해 편차를 표준과 비교합니다. 시스템 성능에 영향을 줄 수 있는 사람과 장비, 인프라, 정보 등 다양한 기여 요인의 변화를 탐색합니다.
- 인과적 요인 분석 — ‘인과적 요인 트리 분석’이라고도 하는 이 기법은 특정 문제 이벤트를 유발한 모든 동작과 조건(인과적 요인)을 기록하고, 시각적으로 보여줍니다.
- 이벤트 분석 — 때때로 인과적 요인 분석과 함께 진행되는 이 방법은 문제 이벤트로 이어지는 동작과 조건의 타임라인 을 설정하기 위해 증거를 빠르게 수집합니다. 그런 다음, 팀은 인과적 요인과 기여 요인을 파악합니다. 이벤트 분석은 ‘갑작스러운 증가’와 같은 일회성 문제 해결에 사용됩니다.
- 장벽 분석 — 안전 사고의 원인 파악에 사용되는 장벽 분석은 적절한 장벽이 놓여 있다면 문제를 감지하고 방지할 수 있다는 전제를 바탕으로 한 접근 방식입니다. 장벽 분석은 특정 위험으로 인한 다양한 영향을 확인하고, 장벽이나 통제가 사고를 방지하지 못한 방법을 조사합니다.
- 5 Whys 분석 — 1970년대 자동차 전문기업인 토요타(Toyota)가 개발한 5 Whys 분석은 최대 5번의 질문을 통해 문제의 근본을 빠르게 파악할 수 있는 기법입니다.
- 이시카와(피시본) 다이어그램 — ‘인과관계 다이어그램’으로도 불리는 이시카와 다이어그램은 문제를 발생하게 한 이벤트의 원인을 확인하는 분석 툴입니다. 물고기 뼈대처럼 설계되어 ‘피시본 다이어그램’이라는 별칭이 있으며, 긴 원인 목록을 관련된 하위 범주로 그룹화합니다. 이 구조는 어떤 근본 원인이 주요 문제일 가능성이 가장 높은지 파악하는 데 도움이 됩니다.
- 케프너-트레고(Kepner-Tregoe)의 근본 원인 분석 — ‘KT 방법’이라고도 하는 이 방법은 상황 분석, 문제 분석, 솔루션 분석, 잠재 문제 분석이라는 4단계의 문제 해결을 통해 의사 결정에서 문제를 분리합니다.
- 파레토 분석 — 파레토 원리(문제의 80%가 원인의 20%에서 발생한다는 원칙)를 따서 명명된 파레토 분석 프로세스는 가장 중요한 이점을 제공하는 솔루션을 선택합니다.
이러한 방법과 기법 중 일부는 요인의 근본 원인을 파악하고 가능한 시정 조치를 나열하므로 ‘트리(tree) 다이어그램’ 또는 ‘트리 분석’이라고도 합니다. 예를 들어, 변화 분석은 트리 다이어그램을 사용하여 변화의 원인과 결과를 설명할 수도 있으므로 ‘변화 트리 분석’이라고도 합니다.
근본 원인 분석 리소스
다음 리소스를 클릭하여 근본 원인 분석에 대해 더 자세히 알아보세요.
- 5 Whys. 5 Whys 분석의 A부터 Z까지 모든 것을 소개합니다.
- 2022년 데이터 분석과 비즈니스를 차별화하는 방법에 대한 완벽 가이드. 수집된 데이터를 사용하여 비즈니스 경쟁력을 갖추는 방법을 소개합니다.
- 근본 원인 분석: 문제 해결 및 시정 조치의 핵심. 문제를 해결하는 과정에 중점을 둔 문서입니다.
시작하기
근본 원인 분석은 기업이 문제의 근본 원인을 파악하도록 함으로써 문제가 반복적으로 발생하는 것을 예방합니다. 오랫동안 계속되어온 프로세스를 개선하는 데도 아주 유용합니다.
근본 원인 분석은 그리 어렵지 않습니다. 다만, 큰 문제를 분석하거나 임베드된 프로세스를 개선하려면 많은 데이터와 분석이 필요하므로 이 작업에 적합한 툴을 사용해야 합니다. Adobe Workfront는 작업을 전략과 연결하고 긴밀한 협업을 도모하여, 측정 가능한 비즈니스 결과를 제공하는 작업 관리 소프트웨어입니다.
무료 데모를 신청하여 Adobe Workfront의 다양한 기능을 살펴보세요.