ISO9001 [8.3] 제품 및 서비스의 설계와 개발 Part.5

반응형

앞서 우리는 설계를 기획(8.3.2)하고, 요구사항을 입력(8.3.3)해서 제대로 된 출력물이 나오는 과정을 엄격하게 관리(8.3.4)하고 결국에 후속 프로세스들을 위해 출력(8.3.5)까지 해냈습니다.

​

이번 글에서는 설계/개발 과정에서 또는 이후에 발생하는 변경사항을 어떻게 다뤄야 하는지에 대해 알아보죠.

---

8.3.6 설계와 개발 변경

조직은 제품 및 서비스의 설계와 개발 과정, 또는 이후에 발생된 변경사항을 요구사항의 적합성에 부정적 영향이 없음을 보장하는데 필요한 정도까지 식별, 검토 및 관리하여야 한다.

​

변경사항의 범위는 8.3.1항부터 8.3.5항까지의 과정에서 발생할 수 있는 모든 것으로 생각하시면 되겠습니다. 설계/개발 프로세스에 변경이 있을 수도 있고, 설계와 개발 기획단계에서 결정하는 여러 항목 중에서도 발생할 수 있습니다. 또한 입력값이 변경될 수도 있죠.

그래서, 설계와 개발변경이라고 해서 굳이 입력사항의 변경이다, 출력값에 대한 변경이다 이렇게 한정 짓지 마시고 프로세스, 활동, 입력값, 출력값, 검토, 검증, 실현성 확인까지 모든 설계와 개발의 범주안에서의 어떠한 것이든지 변경(changes)이 발생하면, 그로 인한 영향이 8.2항을 통해 식별한 제품 및 서비스의 요구사항을 만족시키는데 나쁜 영향을 주지 말아야 한다라고 생각하시면 되겠습니다.

​

설계/개발 프로세스의 경우, "8.3.1 일반사항"에 따라, 조직은 제품 및 서비스의 설계와 개발 이후의 공급을 보장하기에 적절한 설계와 개발 프로세스를 수립, 실행 및 유지하도록 되어 있습니다. 프로세스가 사실 다른 활동 간의 상호작용이라는 의미를 포함하고 있기 때문에 우리가 만든 프로세스는 여러 프로세스와 서로 상호작용을 하죠.

그래서, 변경이 발생하면 설계/개발 프로세스의 출력값을 받아가는 여러 프로세스들의 입력값도 동시에 바뀌는 상황이 생기게 됩니다.

​

그래서 우리는 설계/개발 프로세스의 운용과정에서 변경이 필요하면, 어떠한 프로세스에 영향을 줄지 나아가 어떠한 이해관계자(타 부서, 고객, 인증기관 등등)에게 영향을 줄지를 사전에 고려해야 합니다.

설계/개발 프로세스 내에 여러 Sub-process에 영향을 줄 수도 있고, 프로세스 내 활동(activities)들 간에도 영향을 미치기도 합니다.

​

그럼 이러한 변경은 어느 시점에서 생겨나는 것일까요? 몇 가지만 살펴보죠.

​

첫 번째, 설계/개발 프로세스를 운영하는 도중

설계와 개발을 기획하고 프로세스를 만들어서 운영하는 도중에 절차, 기준, 입력사항 등등 그 모든 것에서 변경사항이 발생할 수 있습니다.

​

두 번째, 설계/개발 프로세스 운영이 끝난 후 출력하는 시점

우리가 생각하기에는 고객요구사항, 우리의 스스로의 요구사항 등을 모두 만족하는 제품을 개발했다고 생각했는데, 8.3.5항의 어느 한 개로도 충족하지 못하거나 곧 양산에 착수하려고 할 때 내/외부의 상황이 바뀌거나(예를 들어 대내/외 규제가 새로 생기거나, 시장의 트렌트가 변하거나, 회사의 경영악화로 인해 낮은 제작비가 드는 제품을 만들어야 한다거나 등등), 뒤늦게 제품을 시장에 내놓기 어려운 문제가 발생하는 등의 문제가 식별되어 변경이 필요할 수 있습니다.

​

세 번째는, 외주처리한 프로세스나 제품이 우리가 원하는 만큼 성과가 나오지 않을 때

외주처리되는 프로세스나 제품은 사실 우리회시가 만들기 어렵기 때문에 외주를 준 만큼 그것에 대한 결과를 통제하는 것도 쉽지 않습니다. 그렇기 때문에 우리 때문이 아니라, 외주업체의 성과에 따라서도 변경이 발생할 수 있습니다.

​

마지막은, 고객이 만족하지 않을 때입니다.

그냥 다 필요 없고 물건을 살 사람이 마음에 들지 않는다면 팔 수 없습니다. 프로세스를 바꾸든지, 검증방법을 바꾸던지 아니면 입력값(디자인, 사양, 냄새, 색깔 등)을 바꾸든지 결국에는 변경이 필요합니다.

​

위에 언급된 것 이외에도 여러 상황이나 단계에서 변경은 발생할 수 있습니다.

다만 중요한 것은 그 변화로 인해서 발생할 수 있는 영향성에 대한 검토가 필요하다는 거죠.

​

앞서 우리가 품질경영시스템 자체에 변경이 필요할 때 "6.3 변경의 기획"과 같이 변경의 목적, 잠재적 결과 그리고 품질경영시스템의 온전성에 대해서 고려를 했듯이, 설계와 개발의 변경 역시 동일한 고려가 필요합니다. :)

(작은 의미에서의 변경의 기획이라고 보면 되겠네요 ㅎㅎ)

​

​

조직은 다음 사항에 대한 문서화된 정보를 보유하여야 한다.

설계와 개발에 변경사항이 발생하는 경우, 다음에 대해서 반드시 문서화된 정보를 남겨놔야 합니다.

​

a) 설계와 개발 변경

어떤 사항이 변경되는지 명확하게 해야 합니다. 8.3.1~8.3.5 중 어떠한 것이 바뀌는지 그리고 각 요구사항마다 문서화된 정보를 보유하도록 되어 있으니, 그 문서에 변경이력을 반드시 기입하면 됩니다.

​

b) 검토 결과

변경사항을 인해서 연관되어 있는 프로세스, 활동 그리고 이해관계자에 어떠한 영향을 미치는지 그리고 제품 및 서비스의 요구사항을 만족하는 것을 저해하는 결과는 초래하지는 않는지 확인해야 합니다.

또한 그 범위는 이미 출시되어 고객에게 제공되거나 후속프로세스에서 사용되고 있는 경우에도 그 영향성에 대한 평가 결과를 포함해야 합니다. (자동차 리콜 같은 것도 같은 맥락이라고 볼 수 있겠죠?)

검토 결과에 대해서는 각 문서화된 정보에 그 내용을 기입해도 되겠지만 변경의 경위, 변경필요성, 변경사항, 변경의 영향, 결론 등으로 별도의 문건을 만들어 보고/승인될 수도 있습니다. (보고서가 더 깔끔하겠죠?)

​

c) 변경의 승인

8.3.2 설계와 개발 기획에서 우리는 설계와 개발 프로세스에 수반되는 책임 및 권한을 설정했습니다. 또한, 5.3 조직의 역할, 책임 및 권한을 통해서 각 조직에 권한을 부여하였죠.

그 부여된 책임과 권한에 따라서 모든 변경사항은 담당자 혹은 해당되는 사람이 스스로 결정해서 반영하는 것이 아니라 a)~b)항을 바탕으로 결정권자에 의해서 승인되도록 합니다.

내부적인 승인을 비롯해서 외부의 승인을 득해야 하는 경우도 있죠? 각종 규제에 대한 승인기관, 고객 등 외부의 승인도 정해진 절차에 따라 실시되어야 합니다.

​

d) 부정적 영향을 예방하기 위해 취한 조치

a)~c)까지의 항목이 유관부서 및 이해관계자들에 제대로 의사소통되지 않거나 식별되지 않으면 변경사항이 제대로 반영되지 않을 수 있습니다. 이러한 부정적 영향을 예방하기 위해서 다음의 조치가 있을 수 있겠네요.

- 검토, 검증, 실현성 확인을 위한 절차서/기준서에 변경사항에 대한 구체적인 내용을 추가로 기입

- 영향을 받는 후속프로세스(구매, 생산, 검사, 납품 등)에 변경사항과 그로 인해 필요한 조치를 전달

(적절한 의사소통을 해야 하겠죠? 이메일, 공문 등)

- 그리고 변경사항이 임의로 반영되지 않았다는 것을 증빙하기 위해 누가 승인했는지가 명확하게 문서에 표기

---

자 지금까지 설계와 개발에 변경사항에 대한 요구사항을 알아보았습니다.

​

"8.3 제품 및 서비스의 설계와 개발"을 최대한 구체적으로 설명하기 위해서 이글까지 총 5개의 글을 작성했는데요.

이해하시는데 많은 도움이 되셨길 바랍니다. :)

​

그럼 이만,

​