8.3.1항에 따라 설계와 개발을 위한 프로세스가 만들어졌고,
여기에 8.3.3항에 따라 우리가 만들고자 하는 제품과 서비스를 만들기 위해 입력값을 정했습니다.
이제 그 입력값이 프로세스에 입력되어, 의도한 출력값이 나올 수 있도록 관리가 필요하겠죠?
"8.3.4 설계와 개발관리"에는 프로세스가 의도한 출력값을 만들 수 있도록 하는 관리에 대한 요구사항입니다.
하나씩 살펴보시죠 :)
8.3.4 설계와 개발관리(Design and development controls)
조직은, 설계와 개발 프로세스에 다음 사항을 보장하기 위하여 관리/통제하여야 한다.
입력값(inputs)이 결정되면 "프로세스가 효과적이다(=즉, 우리가 의도한 출력값이 나온다)"이라는 것을 보장하기 위해 8.3.2항 기획단계에서 결정된 사항에 따라 설계/개발 활동이 이행되고 관리되어야 합니다.
이러한, 설계/개발 프로세스의 관리에서 "검토(review)와 검증(verificaiton) 활동"이 필수적입니다.
그래서 설계/개발 프로세스에는 이 "검토/검증"의 단계가 반드시 설정되어 있는 것이 중요한데, 프로세스 안에 직접적으로 포함되어 있지 않더라도 개별적인 프로세스에 의해서 충분히 이행될 수 있습니다.
(단, 검토/검증의 프로세스와 설계/개발 프로세스가 연관되어 있다는 표시는 서로의 프로세스에 반드시 표시가 필요합니다)
조직에서는 이러한 검토와 검증을 비롯하여 기획단계에서 결정된 사항이 적합하게 이행되고 있는지 관리해야 합니다.
a) 달성될 결과의 규정(the results to be achieved are defined)
설계와 개발에 참여하는 모든 인원들이 다음의 내용을 완벽하게 이해(understand)하고 인식(aware)하고 있어야 합니다.
- 고객이나 최종사용자(end user)의 요구사항과 우리가 최초부터 의도한 최종결과물이 무엇인지
- 최초 요구사항 대비 변경(deviation)은 무엇인지
(변경사항은 예를 들어, 비용이나 사용편의성 등을 고려하거나 제품성능 향상하기 위해 기존대비 바뀐 요소들)
b) 설계와 개발 결과가 요구사항을 충족하는지의 능력을 평가하기 위한 "검토(review)" 시행
설계와 개발을 계획하는 단계에서의 검토와 각 단계마다(또는 최종단계) 지정된 검토를 이행하는 것은 입력사항을 잘 반영하였는지, 문제는 없는지를 확인하고 문제가 있는 경우 즉시 해결할 수 있는 기회를 조직에게 부여하죠.
그리고 이러한 검토는 각 단계별로 담당자와 해당 조직에 의해서 이뤄질 수도 있지만, 설계와 개발의 복잡성(complexity)을 고려하여 반드시 직접적으로 설계나 개발단계에 참여하는 인원이 아니더라도 간접적인 이해관계자들을 참여시켜 공식적인 미팅자리를 만들어서 같이 검토할 수 있습니다.
(예를 들어, 관련된 고객들, 최종사용자(end user), 사외협력업체(소재공급) 등등)
그리고, 검토 이행여부에 대한 관리를 위해서는 검토 후에 검토자가 서명하고 날짜를 기입하는 행위가 필요합니다. 일부 간단한 검토의 경우에는 그러한 과정을 거치지 않을 수 있지만, 일반적으로는 검토이행에 대한 표식이 필요합니다. 예를 들어, 보고서에 검토/승인란에 각각의 서명과 날짜가 기입됨으로 인해 해당 내용이 검토/승인되었음을 인식할 수 있습니다.
위에서 언급한 이해관계자들과의 검토 기록은 회의록을 통해서 남길 수 있겠죠?(뒤에 참석자 명단 서명받고..)
c) 설계와 개발의 출력이 입력 요구사항에 충족함을 보장하기 위한 "검증활동(verification)" 시행
검증(verification)은 설계/개발 프로세스 초기에 식별된 모든 요구사항이 충족되고 있음을 보장하기 위해 시행되어야 합니다.
(예. 도면을 검도하는 행위, 대체계산수행, 엔진 각각의 부품이 요구사항에 따라 만들어졌는지 검사 등)
d) 결과로 나타난 제품 및 서비스가 규정된 적용에 대한, 또는 사용 의도에 대한 요구사항을 충족시킴을 보장하기 위한 "실현성 확인 활동(validation)"의 시행
실현성 확인은 최종 제품 또는 서비스가 특정 용도 또는 의도한 용도에 대해 고객 또는 최종사용자의 요구를 충족하도록 보장하기 위해 수행됩니다.
(예. 각 부품을 전부 조립해서 엔진을 시운전, 사용자 환경에서 직접 작동시험, 일부고객에게 제품 보내서 테스트 등)
이렇게 보면, 검증(verification)과 실현성 확인활동(validation)은 결국 똑같은 개념으로 이해될 수 있습니다.
하지만, 엄연히 시점과 어떠한 것에 대한 충족함을 확인하기 위한 활동인지가 구분됩니다.
자세한 내용은 [용어설명]에 게시판 하기 글을 참고하시기 바랍니다.
e) 검토 또는 검증 및 실현성 확인 활동 중 식별된 문제점에 대해 필요한 모든 조치의 시행
b)~d)에서 검토, 검증, 실현성 확인 활동을 이행하게 되고, 이때 각각의 목적에 부합하지 않거나 예기치 못한 문제가 발생한 경우, 이는 반드시 해결을 하고 다음단계로 넘어가야 합니다.
그리고, 현재단계에서 식별된 문제에 대한 조치의 유효성에 대한 평가는 다음단계 있을 검토 때 반드시 확인해야 합니다. (모든 조치의 시행뿐만 아니라 시행된 조치가 효과적이었는지도 챙겨야 함)
f) 이들 활동에 대한 문서화된 정보의 보유
설계와 개발 활동이 계획대로 수행되었음을 그리고 모든 요구사항과 목적에 충족하는지를 입증하기 위한 증거로 a)~e)까지 이행된 활동은 모두 문서로써 남아 있어야 합니다.
(회의록, 검사 및 시험보고서, 고객의 승인서명 등)
[비고] 설계와 개발 검토, 검증 및 실현성 확인에는 별개의 다른 목적이 있다. 설계와 개발 검토, 검증 및 실현성 확인은 조직의 제품 및 서비스에 적절하도록 별도로 또는 조합하여 시행될 수 있다.
앞서 확인해 본 각각의 활동인 검토, 검증, 실현성 확인은 각각의 목적마다 구분되어 사용되어야 합니다.
별도로 [용어설명]에서 검토/검증/실현성 확인의 의미와 차이점을 다루기는 했는데, 조금 더 쉬운 이해를 돕기 위해 시점과 내용들을 예시로 작성해 보았습니다. 참고하시기 바라요 ^^
그럼 이만,
'ISO9001 품질경영시스템 > ISO9001 요구사항' 카테고리의 다른 글
| ISO9001 [8.3] 제품 및 서비스의 설계와 개발 Part.5 (0) | 2024.07.15 |
|---|---|
| ISO9001 [8.3] 제품 및 서비스의 설계와 개발 Part.4 (0) | 2024.07.15 |
| ISO9001 [8.3] 제품 및 서비스의 설계와 개발 Part.2 (0) | 2024.07.14 |
| ISO9001 [8.3] 제품 및 서비스의 설계와 개발 Part.1 (0) | 2024.07.13 |
| ISO9001 [8.2] 제품 및 서비스 요구사항 Part.2 (0) | 2024.07.13 |
