모든 템플릿

근본 원인 분석 - 원인 매핑

265보기
3사용
1좋아요

보고하기

근본 원인 분석 – 원인 매핑

개요

근본 원인 분석 – 원인 매핑은 팀이 문제를 체계적으로 조사하도록 돕는 구조화된 시각 도구입니다. 조직의 목표에 미친 영향에서 출발해, 이 방법은 각 단계에서 반복적으로 "Why?"를 물어 왼쪽에서 오른쪽으로 원인을 추적합니다. 여러 개의 독립적인 원인이 적용되는 지점에서는 맵이 분기되어 문제가 발생한 전체 과정을 드러냅니다. 해결책은 통제 가능한 특정 원인에 직접 연결되어, 팀이 단일한 “근본 원인”만 쫓지 않고 가장 효과적이고 비용 효율적인 개입을 선택할 수 있도록 합니다.

사용 가능 대상

이 템플릿은 사고, 결함, 장애 또는 반복 발생 문제를 조사하는 모든 팀에 유용합니다. 안전팀은 부상 및 근접 사고 조사를 위해 사용합니다. 운영 관리자는 프로세스 중단과 생산 지연을 조사할 때 사용합니다. 품질 엔지니어는 결함의 근원을 추적합니다. 프로젝트 매니저는 일정 지연과 예산 초과를 진단합니다. IT 및 DevOps 팀은 시스템 장애와 성능 문제를 맵으로 도식화합니다. 인사팀은 직장 내 갈등과 이직 패턴을 조사합니다. 부서 간 공통 이해를 형성하는 시각적이고 증거 기반의 구조는 교차 기능 팀에 특히 유용합니다.

사용 방법

  • (a) 문제 개요 작성 – 문제 내용과 발생 시점 및 장소, 영향을 받은 조직 목표를 기록하세요.

  • (b) 영향 식별 – 어떤 목표가 영향을 받았는지 명시하세요: 안전, 고객 만족도, 비용, 일정, 품질.

  • (c) 원인 맵 작성 – 영향에서 시작해 각 노드에서 "Why?"를 묻고 왼쪽에서 오른쪽으로 진행하세요. 한 단계에서 독립적인 원인이 여러 개인 경우 맵을 분기하세요.

  • (d) 증거 기록 – 각 원인을 뒷받침하는 로그, 기록, 사진, 인터뷰, 또는 데이터를 문서화하세요. 증거 없는 원인은 추측에 불과합니다.

  • (e) 가능한 해결책 식별 – 해결책 섹션에서 각 해결책을 제어하는 특정 원인에 연결하세요. 소유자, 기한, 결정 상태(승인됨, 평가 중, 거부됨)를 지정하세요.

  • (f) 올바른 조합 선택 – 재발을 확실히 방지하는 가장 비용 효율적인 솔루션 조합을 선택하세요. 맵에 있는 모든 원인을 고칠 필요는 없습니다.

예제 설명

이 예제는 창고에서 발생한 미끄러짐 및 낙상 부상을 조사합니다. 한 직원이 7월 14일 14시 20분 교대 변경 중 4번 통로에서 미끄러져 발목을 삐끗했고, 이로 인해 유급 결근이 발생한 안전사고와 45분간의 가동 중단이 발생했습니다.

원인 맵은 두 개의 독립적인 원인으로 갈라지며, 둘 다 동시에 존재해야 했습니다. 하나는 배관 이음부가 마모되어 누수가 발생했는데 검사 일정이 없었고, 다른 하나는 유출이 40분 동안 보고되지 않아 젖은 바닥 표지판이 게시되지 않았습니다. 증거로는 유지보수 기록, 청소 일정표, CCTV 타임스탬프, 씰 검사 보고서가 포함됩니다.

세 가지 해결책이 식별되었으며, 각 해결책은 서로 다른 원인을 겨냥합니다: 씰을 교체하고 분기별 파이프 점검을 도입합니다(시설팀, 승인됨, 기한 9월 5일); 각 통로 끝에 젖은 바닥 표지판을 비치합니다(운영팀, 승인됨, 기한 8월 25일); 각 교대 전환 시 15분간 바닥 점검을 실시합니다(교대 리더, 검토 중, 기한 9월 1일). 이 예시는 맵이 하나의 사건에서 여러 기여 원인으로 분기되는 방식과, 해결책들이 단일 근본 원인만을 찾는 대신 맵의 서로 다른 지점을 어떻게 다루는지를 보여줍니다.

감사합니다

Khawaja Rizwan

Rizwan Khawaja

ICT Solution Architect @ NUST

I hold master's degrees in computer science and project management along with trainings and certifications in various technologies. All this is coupled with 25+ years of industry experience.


카테고리

유사한 템플릿