capa beginner s guide corrective action preventive action
실제 애플리케이션에 대한 몇 가지 예 및 사례 연구를 포함하여 시정 조치 예방 조치 (CAPA)에 대한 모든 것을 살펴보십시오.
시정 조치와 예방 조치 (통칭 CAPA라고 함)라는 용어가 같은 의미로 사용되는 경우가 많지만 실제로는 동일하지 않습니다. 이러한 각 작업의 정의와 의도는 응용 프로그램에서 매우 구체적입니다.
학습 내용 :
시정 조치 예방 조치 (CAPA) 란 무엇입니까?
이 기사에서는 시정 조치 및 예방 조치에 대해 더 자세히 논의 할 것입니다. 각각의 예를 사용하여 정의하고, 세부 사항을 심층 분석하고, 실제 응용 프로그램에 대한 몇 가지 사례 연구를 살펴 봅니다.
탐험하자 !!
시정 조치
Merriam-Webster 사전에 정의 된대로 교정이라는 단어는 '수정하려는 의도 (올바르게 만들거나 설정하기 위해)'로 정의됩니다. 따라서 정의에 따라 수정 조치는 현재 진행중인 문제 또는 문제를 수정하거나 수정하기 위해 식별되는 작업입니다.
소프트웨어 개발 및 제공 팀의 일원 인 독자에게는 가장 일반적인 예 수정 조치는 최신 프로덕션 배포로 인해 발생한 프로덕션 사고를 수정하기 위해 프로덕션에 핫픽스를 배포하기로 결정하는 것입니다.
예방 조치
Merriam-Webster 사전에 정의 된 바와 같이 예방이라는 단어는 '(발생하거나 존재하지 않도록) 방지하는 것'으로 정의됩니다. 따라서 예방 조치는 가까운 미래 또는 먼 미래에 발생할 문제 또는 문제를 방지하기 위해 식별 된 작업으로 정의됩니다.
예를 들어 , 영향을받는 영역을 테스터에게 제공하는 프로세스는 특히 요구 사항 계획 중에 범위를 벗어난 것으로 간주되는 구성 요소에서 의도하지 않은 버그가 프로덕션에 발생하는 것을 방지 할 수 있습니다.
시정 조치와 예방 조치의 차이점
| 시정 조치 | 예방 조치 |
|---|---|
| 현재 문제를 해결합니다. | 미래 (근거리 또는 원거리)에 발생할 수있는 문제를 해결합니다. |
| 여기서의 의도는 문제를 수정 / 해결하는 것입니다. | 여기서의 의도는 앞으로이 문제가 발생하지 않도록하는 것입니다. |
CAPA 유사점
#1) 예방 및 시정 조치는 모두 과거, 현재 또는 미래의 문제를 처리하기 위해 만들어집니다.
# 2) 예방 또는 시정 조치의 시작은 다음과 같은 기본 프로세스에서 시작됩니다.
- 위험 분석 및 관리 프로세스
- 근본 원인 분석 프로세스
- 회고전 과정
- 배운 역사적 교훈 등과 같은 조직 프로세스 자산 검토
다음 섹션에서 이러한 프로세스에 대해 자세히 설명합니다.
각각을 언제 사용합니까?
식별 된 각 문제 또는 위험에는 해당 CAPA가있을 수 있습니다. 결과 조치가 시정인지 예방인지 확인하는 동안 여기에서 이해해야 할 경험 법칙은이 조치의 의도입니다.
- 의도가 본질적으로 수정 인 경우, 즉 의미가 현재 문제를 수정하도록 설계된 경우이를 수정 조치라고합니다.
- 의도가 예방 적이라면, 즉 의미가 미래에 그러한 문제가 발생하지 않도록 설계된 경우이를 예방 조치라고합니다.
식별 할 프로세스시정 및 예방 조치
# 1) 리스크 분석 및 관리 프로세스
위험은 본질적으로 부정적인 발생 가능성입니다.
위험 분석을 수행하는 동안 프로젝트 또는 활동을 평가하여 관련 위험과 해당 위험이 프로젝트 / 활동에 미치는 영향을 식별합니다. 이 분석은 전반적인 위험 관리의 일부로 수행되며,이 위험이 발생할 가능성과 영향을 기반으로 적절한 완화 전략이 만들어집니다.
식별 된 각 위험은 이와 관련된 예방 또는 시정 조치가있을 수도 있고 없을 수도 있습니다. 식별 된 위험은 영향과 발생 가능성에 따라 매핑되고 그룹화됩니다. 영향이 높고 발생 확률이 높은 버킷에 해당하는 위험에 우선 순위가 부여됩니다.
이것을 더 이해하기위한 예를 고려해 보겠습니다.
팀이 새 웹 사이트를 출시하려고하고 해결되지 않은 버그와 짧은 배송 일정을 기반으로하여 출시 될 경우 팀이 프로젝트에 대해 다음과 같은 위험을 식별했다고 가정 해 보겠습니다.
- 위험 # 1 : 웹 사이트의 검색 기능은 응답하는 데 너무 오래 걸리고 결국 시간 초과됩니다. 고객에게 시간 초과를 나타내는 오류 메시지가 표시됩니다.
- 위험 # 2 : 문의하기 페이지의 로고는 모바일 반응이 없습니다.
- 위험 # 3 : 계정 등록 프로세스가 작동하지 않습니다. 신규 사용자는 가입 할 수 없습니다.
- 위험 # 4 : IE9 고객 (모든 고객 중 4 % 미만)은 홈 페이지 아이콘을 클릭 할 수 없습니다.
해결 우선 순위를 지정하기 위해 팀은 식별 된 위험을 아래와 같이 위험 매트릭스에 매핑합니다.
실제로 위험 # 1 및 3은 발생 가능성과 영향이 높기 때문에 위험 # 2 및 4보다 우선 순위가 높습니다.
이제 식별 된 위험에 대한 위험 완화 전략을 개발하겠습니다!
위험 # 1에 대한 위험 완화
예방 조치:
- 2 초 이내에 결과를 반환하도록 검색 저장 프로 시저를 최적화합니다. 릴리스 전에 추가 개발 리소스를 할당하거나 리소스를 재 할당하여이 작업을 완료하세요.
시정 조치 :
- 검색 결과 페이지에 페이지 매김을 추가하여 기준과 일치하는 25 개의 제품 만 한 번에로드하여 서버의로드를 줄입니다.
위험 # 2에 대한 위험 완화
C ++ 대 자바 차이점
예방 조치:
- 없음
시정 조치
- 개발 리소스를 사용할 수있는 경우 결함을 수정합니다.
위험 # 3에 대한 위험 완화
시정 조치
- 개발 리소스를 할당하거나 리소스를 재 할당하여이 결함을 수정합니다.
위험 # 4에 대한 위험 완화
예방 조치:
- 없음
시정 조치
- 개발 리소스를 사용할 수있는 경우 결함을 수정합니다.
# 2) 근본 원인 분석 프로세스
근본 원인 분석은 과거 또는 기존 문제의 근본 원인을 식별하기 위해 수행됩니다. 근본 원인을 파악하는 데 가장 좋아하는 방법은 5-Why 방법입니다.
5-Why 방법이란 무엇입니까?
5-Why 방법은 '왜'라는 질문을 반복하여 근본 원인을 식별하는 일반적인 의문 기법입니다. 이 기술은 제조 업계에서도 매우 인기가 있으며 처음에는 제조 관행을 진행하는 동안 Toyota Motor Corporation에서 사용되었습니다.
이 예를 살펴 보겠습니다.
문제점 : 프로덕션에서 빌드가 실패하여 롤백해야했습니다.
왜?
고객이 장바구니에있는 항목을 결제에 추가 할 수 없습니다.
왜?
빌드 배포 문제 : 필수 저장 프로 시저 중 하나가 배포되지 않았습니다. 이것은 장바구니에 추가 기능에 영향을 미쳤습니다.
왜?
이 특정 저장 프로 시저를 배포하기위한 지침이 매니페스트에 누락되었습니다.
왜?
해당 저장 프로 시저 개발을 담당하는 개발자가 매니페스트에 지침을 추가하는 것을 잊었습니다.
시정 조치 :
- 빌드 배포를 위해 매니페스트에 정확하고 정확한 지침을 추가합니다.
- 다른 테스트 환경에서 매니페스트의 지침에 따라 전체 빌드 패키지의 배포를 테스트하고 회귀 테스트를 수행하여 빌드가 제대로 작동하는지 확인합니다.
예방 조치:
- 개발 리드를위한 프로세스를 도입하여 프로덕션 릴리스 최소 1 일 전에 전체 배포 패키지와 매니페스트를 검토합니다.
# 3) 회고전 프로세스
회고전은 과거 사건에 대한 검토이며 이러한 사건을 통해 배울 수있는 기회로 사용합니다. 소프트웨어 개발 및 프로젝트 관리와 관련하여 소급은 메이저 릴리스가 끝날 때나 스프린트가 끝날 때 또는 프로젝트의 모든 마일스톤에서 수행 될 수 있습니다.
검토를 기반으로 유사한 향후 프로젝트와 관련된 위험을 완화하는 데 도움이되는 여러 관련 예방 또는 시정 조치가 식별 될 수 있습니다.
# 4) 배운 역사적 교훈으로 조직 프로세스 자산 검토
여기에서의 설명은 위의 회고전 프로세스에 대한 설명과 동일합니다. 여기서 아이디어는 과거의 실수 나 문제에서 배우고 확인 된 개선 사항을 유사한 미래 프로젝트에 적용하는 것입니다.
CAPA의 기본 과정
시정 조치 또는 예방 조치를 식별하는 데 사용 된 프로세스에 관계없이 기본 프로세스 또는 접근 방식은 동일하게 유지됩니다. 일상 생활의 예를 들어 단계별로 기본적인 과정을 논의 해 보겠습니다.
이제이 프로세스를 실제 사례에 적용 해 보겠습니다. .
설거지를 할 때마다 설거지 비누를 떨어 뜨립니다. 즉, 넘쳐서 비눗물이 바닥 전체에 있습니다. 비눗물은 청소하기 쉽지 않고 지루합니다!
폐쇄에 대한 수정 또는 예방 조치 추적
조치를 취한 후 교정 또는 예방에 대해 확인 된 후에도 작업은 아직 끝나지 않았습니다. 작업은 여전히 실행되고 최종적으로 완료되고 닫혀 야합니다.
폐쇄에 대한 조치 지점을 추적하는 것은 팀이 종종 어려움을 겪는 문제입니다.
다음은 식별 된 작업의 추적 및 실행에서 귀하와 귀하의 팀에 도움이되는 몇 가지 유용한 팁입니다.
- 항상 식별 된 조치 지점을 실행할 책임이있는 사람과 전체 이니셔티브를 추진할 책임이있는 사람을 식별하십시오. 예: 작업이 소프트웨어 프로젝트에 대한 것이라면 실행하는 사람이 개발자가 될 수 있고이를 주도하는 사람이 프로젝트 리더가 될 수 있습니다.
- 작업의 진행 상황을 추적 할 수있는 방법이 있는지 확인하십시오. 조직에 따라 추적 방법은 Excel의 광고 항목에서 모든 진행중인 작업을 추적하기위한 전용 라이선스 소프트웨어 사용에 이르기까지 다양 할 수 있습니다.
- 기한이 지난 작업 항목을보고하기위한 지침을 만듭니다. 기한에 합의한 날로부터 7 일 이내에 조치가 완료되지 않으면 이에 대한 공식 보고서가 경영진에 전송되고 프로젝트 팀이 정당성을 제공하도록 요청되는 것처럼 지침은 간단 할 수 있습니다. 규정 된 기간 내에 조치가 완료되지 않은 이유. 조직의 계층 구조에 따라이 규칙에 더 많은 계층을 추가 할 수 있습니다.
딸깍 하는 소리 여기 , 샘플 데이터가있는 시정 및 예방 조치 계획 템플릿에 액세스합니다.
테스터의 관점
테스터로서 우리는 여러 가지 방법으로 프로젝트의 성공에 기여합니다. 위험을 식별하고 CAPA를 식별하는 데 기여하는 능력은 우리가 개발하고 우리의 이점을 위해 사용할 수있는 중요한 기술입니다.
편안한 웹 서비스를 테스트하는 도구
시정 및 예방 조치는 테스트 프로세스에도 쉽게 적용 할 수 있으며 테스트 효과와 전반적인 품질을 개선하는 데 도움이 될 수 있습니다. 이러한 작업은 테스트 리드, QA 리드, 프로젝트 관리자 등이 식별 할 수 있으며 테스터와 다른 팀 구성원이 실행할 수 있습니다.
결론
수정 조치는 현재 진행중인 문제 또는 문제를 수정하거나 수정하기 위해 식별 된 작업입니다. 예방 조치는 가까운 미래 또는 먼 미래에 발생할 수있는 문제 또는 문제를 방지하기 위해 식별 된 작업으로 정의됩니다.
의도는 둘 다 다르지만 과거, 현재 또는 미래의 문제를 처리하기 위해 예방 및 시정 조치가 만들어집니다.
위험 분석, 근본 원인 분석, 회고 등은 예방 및 시정 조치를 식별하는 데 사용할 수있는 모든 프로세스입니다. 조치를 취한 후 시정 조치인지 예방 조치인지 확인 된 후에도 작업은 아직 끝나지 않았습니다. 작업은 여전히 실행되고 최종적으로 완료되고 닫혀 야합니다.
위험을 식별하고 시정 및 예방 조치를 식별하는 데 기여하는 능력은 테스터가 개발하고 우리의 이점을 위해 사용할 수있는 중요한 기술입니다.
이 기사가 시정 조치 및 예방 조치 (CAPA)에 대한 모든 질문을 명확히 해주 었으면합니다 !!