특정 개인을 탓하지 않고 근거가 뒷받침된 프로세스상의 원인 추적하기

소규모 프로젝트에서 “근본 원인”이란 무엇을 의미할까요?

미국품질협회(ASQ)는 근본 원인을 부적합을 유발하였으며 시정 조치를 통해 해결해야 하는 요인으로 정의합니다. ASQ는 근본 원인 분석을 문제가 발생한 이유를 밝혀내는 방법으로 설명하며, 사건 및 인과 요인 분석(event-and-causal-factor analysis)이 근거와 타임라인을 사용하여 인과적 요인과 기여 요인을 규명한다고 언급합니다. 이러한 개념들은 다음과 같은 간단한 실무적 정의를 뒷받침합니다. 근본 원인이란 진술된 문제가 어떻게 발생했는지 설명해주고 실질적인 개선을 통해 해결할 수 있는, 근거로 뒷받침된 프로세스의 한 부분입니다. ASQ의 근본 원인 분석 지침

“근본(Root)”이라는 단어는 원인이 단 하나만 존재한다는 인상을 줄 수 있습니다. 하지만 실제 프로세스 문제에서는 여러 요인이 복합적으로 작용할 수 있습니다. ASQ 자체도 인과적 요인과 기여 요인을 함께 언급하고 있으므로, 신중한 기술을 통해 근거가 뒷받침되는 여러 원인을 밝혀낼 수 있습니다. 단순히 누군가가 가장 먼저 제시했다는 이유로 편한 설명을 섣불리 선택하지 마세요.

증상, 기여 조건, 원인은 어떻게 다른가요?

이러한 레이블은 짧은 문제 진술서를 더욱 명확하게 만드는 데 도움이 됩니다. 이는 작성을 돕는 도구일 뿐, 실제로 일어난 일을 조사하는 과정을 대신할 수는 없습니다.

어떤 조건은 전체 메커니즘을 온전히 설명하지 못한 채 문제 발생에 기여할 수 있습니다. 예를 들어 워크숍이 매우 바빴던 상황이 업데이트 지연과 겹쳤을 수 있지만, 단순히 “바빴다”는 사실만으로는 왜 두 번째 예약 확인이 가능했는지를 설명하지 못합니다. 원인에 대한 설명은 프로세스와 결과를 연결해야 하며, 타임스탬프, 예약 기록, 예약 단계에 대한 단계별 검토 등 확인할 수 있는 근거로 뒷받침되어야 합니다. 그러한 근거가 없다면 확인되기 전까지는 해당 설명을 '가능성 있는 원인'으로 보아야 합니다.

근거 있는 원인을 찾기 위한 짧은 일련의 질문들

사람에 대한 판단보다는 사건 자체에서부터 시작하십시오. ASQ는 체계적으로 타임라인을 수립하고 인과 관계를 분석할 것을 권장합니다. 다음 질문들은 이러한 접근 방식을 소규모 예약 문제에 적용한 것입니다. ASQ의 근본 원인 분석 개요

이는 "5 Whys(5가지 왜)" 조사와 유사하지만, 반드시 다섯 번이어야 하는 것은 아닙니다. 사건을 설명하고 해결책에 대한 테스트를 안내할 수 있는 구체적이고 확인 가능한 프로세스 설명이 확보되면 멈추십시오. 질문에서 증거가 아닌 추측이 나온다면, 불확실성을 표시하고 해당 답변을 확정된 것으로 취급하기 전에 기록을 찾거나 프로세스를 관찰하십시오.

과장하지 않고 발견점 작성하기

간결한 보고서에는 다음 패턴을 사용할 수 있습니다:

> 증상: [관찰 가능한 결과.] 기여 요인: [발생 가능성을 더 높인 상황.] 증거로 뒷받침되는 원인: [프로세스 메커니즘 및 이를 뒷받침하는 증거.]

위의 예시 시나리오에 적용한 결과:

이 예시는 가상의 사례이며, 제시된 증거는 실제 워크숍에 대한 보고서가 아니라 이해를 돕기 위한 설명의 일부입니다. 실제 조사에서는 가상의 순서 대신 직접 확인한 기록을 반영하십시오. 전화 예약이 두 번째 확인보다 먼저 이루어졌는지 또는 온라인 목록에 여전히 해당 좌석이 공석으로 표시되었는지 아직 입증할 수 없다면, “가능한 원인”으로 기재하고 확인해야 할 사항을 명시하십시오.

되돌릴 수 있는 해결책을 선택하고 해당 메커니즘을 해결하는지 확인하십시오

위험 부담이 적은 테스트를 위해 워크숍의 모든 예약 채널에서 하나의 공유 예약 가능 대장을 사용할 수 있습니다. 직원은 요청이 전화로 접수되든 온라인으로 접수되든, 예약을 확정하기 전에 예약을 기록하고 좌석을 예약 불가로 표시합니다. 이는 영구적인 시스템 변경 없이도 서로 다르거나 최신화되지 않은 화면을 통해 두 채널에서 예약이 확정되는 원인 메커니즘을 직접적으로 해결합니다.

시작과 종료 시점을 명확히 설정하여 향후 예정된 일부 세션에 한해 이 절차를 적용해 보십시오. 각 예약 확인 건을 공유 대장과 대조해 보고, 예약을 담당하는 직원들이 해당 순서를 일관되게 준수할 수 있었는지 확인하십시오. 중복 예약 확인이 지속되거나 확정 전에 대장이 안정적으로 업데이트되지 않는다면, 이번 테스트로는 이 조치가 원인을 통제한다는 사실을 입증하지 못한 것입니다. 단계와 증거를 다시 검토하십시오. 동일한 조치를 반복한다고 해서 다른 메커니즘이 해결될 것이라고 단정하지 마십시오.

따라서 훌륭한 정의는 문제를 단순히 명명하는 것 이상의 역할을 합니다. 다른 사람이 무엇이 관찰되었는지, 어떤 조건이 영향을 미쳤을 수 있는지, 증거가 어떤 프로세스적 설명을 뒷받침하는지, 그리고 되돌릴 수 있는 작은 변화를 통해 그 설명을 어떻게 검증할 수 있는지를 명확히 이해할 수 있도록 돕습니다.

출처 및 범위

원래의 이중 예약 예시는 증거를 바탕으로 되돌릴 수 있는 프로세스 테스트를 도출합니다. 명시된 출처는 제시된 사실 관계를 뒷받침하며, 예시와 실습 내용은 독창적으로 구성된 편집 적용 사례입니다.

이 주제 더 살펴보기