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

반응형

8.3.1항을 통해 설계와 개발을 할 때는 적절한 프로세스를 수립해야 한다는 내용 알아보았고,

8.3.2항을 통해 설계와 개발을 시작하기 전에 어떤 것들을 계획(Planning) 해야 하는지를 알아보았습니다.

​

이제, 8.3.3항을 통해 설계와 개발을 할 때 어떠한 입력값(inputs)들이 있어야 하는지 알아보죠 :)

​

8.3.3 설계와 개발 입력(Design and development inputs)

조직은 설계와 개발이 될 특정 형태의 제품 및 서비스에 필수적인 요구사항을 정하여야 한다. 조직

은 다음 사항을 고려하여야 한다.

설계/개발 프로세스를 운영하기 위해서는 입력값이 있어야 합니다.(입력→ 프로세스→ 출력)

본 요구사항은 설계/개발 프로세스의 입력값에 대한 내용이고, 입력사항을 결정할 때는 이제부터 언급되는 사항들이 고려되어야 하죠. 이러한 입력정보에서 가장 중요한 것은 모호하지 않고 명확하고 완전해야 한다는 것입니다.

​

a) 기능(functional) 및 성능(performance) 요구사항

8.2항을 통해서 우리는 고객이나 시장(market) 또는 조직에서 결정한 기능과 성능이 있을 겁니다.

(예를 들어, 일정량의 조명을 제공하는 램프 또는 일정시간 동안 제공되는 서비스, 안전한 방식으로 작동할 수 있는 기계 등)

​

b) 이전의 유사한 설계와 개발활동으로부터 도출된 정보

신제품을 개발할 때 이전에 우리 회사가 유사한 제품을 개발해 본 경험이 있다면 그 당시에 겪었던 실패나 성공에 대한 경험으로 인해 얻을 수 있었던 지식, 그리고 기술적인 내용이 있는지 확인해봐야 합니다.

(예를 들어, 갤럭시 시리즈는 S부터 현재의 S22까지 이전의 개발경험이 쭈욱 이어지고 있다고 볼 수 있죠)

이러한 과정은 신기술이나 성공요인을 다른 제품에도 적용 또는 유지시킬 수가 있어 성공의 연속성을 보장하기도 하고 실패를 미연에 방지하기도 합니다 (도출된 정보의 예: 도면, 기술사양서, 규격, 허용기준 등등)

​

이러한 기술적인 사항을 비롯하여 절차적인 즉, 설계/개발 프로세스 운용에 대한 실패도 있을 수 있습니다.

검증을 하기 전에 사전에 각각의 단위요소에 대한 검증하는 단계를 거친다던지, 설계나 개발단계를 조금 더 세부적으로 나눈다던지 하는 절차적인 경험요소도 필요하다면 사전에 검토해서 이번 개발의 입력에 반영해야 합니다.

다만, 절차적인 경험의 요소는 "설계와 개발입력"보다는 "설계와 개발의 기획"에 조금 더 어울릴 수도 있어요.

​

c) 법적 및 규제적 요구사항

8.2.3.1, d)항을 통해서 우리는 제품이나 서비스에 적용되는 법적 및 규제적 요구사항에 대해서 파악했습니다.

벅적/규제적 요구사항의 경우, 제품이나 서비스 자체에 직접적으로 적요되는 사항이 있고, 제품이나 서비스를 제공하는 과정에 적용되는 사항이 있을 수 있습니다.

- 제품이나 서비스 자체에 적용: 제품의 특성(재료, 색상, 형태, 유해성 등등) 관련

- 제품이나 서비스 제공에 적용: 제품의 포장(포장용기, 포장형태)이나 운송, 판매(판매시장 포함)와 관련

​

d) 조직이 실행을 약속한 표준 또는 실행지침

8.2.3.1, b), c)항을 통해서 우리는 조직에 의해서 스스로 결정하고 규정한 요구사항이 있습니다.

(고객이 명시하지 않은 사항을 포함해서 말이죠)

어느 산업규격을 따를 것인지(한국, 유럽, 일본, 미국 등등), 허용기준은 어떻게 가져갈 것인지 등이 예가 될 수 있습니다.

​

e) 제품 및 서비스의 성질에 기인하는 실패의 잠재적 결과

제품이나 서비스의 사용 중에 실패의 잠재적인 결과는 치명적인 것(사고로 이어질 수 있는)에서부터 고객만족을 저하시키는 문제까지 다양할 수 있어요.

성질에 기인하는 실패라는 것은 쉽게 말해 제품이 가지고 있는 특성 자체(잘 마모되거나, 잘 변색되거나, 잘 부서지거나 하는 성질)에 대한 문제도 있지만 사용환경에 대한 문제도 있을 수 있어요(사용/운송/판매환경 등)

이러한 실패의 잠재적 결과를 예측하여 설계부터 반영하는 일반적인 방법이 흔히들 알고 계신 FMEA입니다.

※FMEA : Failure Mode Effect Analysis 즉, 시스템에 영향을 미치는 전체 요소의 고장을 형태별로 분석하여 시스템 또는 서브시스템이 가동 중에 기기나 부품의 고장에 의해서 재해나 사고를 일으키게 할 우려가 있는가를 해석하는 방법

​

입력은 설계와 개발 목적에 충분하며, 완전하고 모호하지 않아야 한다.

a)~e) 가지 언급된 사항들은 서두에서도 언급했듯이 분명(unambiguous)하고 완전(complete) 해야 합니다.

​

상충(conflicting)되는 설계와 개발 입력은 해결되어야 한다.

서로 맞지 않거나 어긋나는 문제점들이 반드시 식별되어야 하고, 설계/개발 착수 전에 완전히 해소되어야 합니다만, 모든 것들을 계획단계에 예측할 수 없기에 만약 설계와 개발을 하는 도중에 상충되는 부분들이 생긴다면 반드시 해결하고 넘어가야 합니다. (이런 경우에는 책임자의 적극적인 개입이 필요하죠. 일명 "교통정리")

​

조직은 설계와 개발 입력에 대한 문서화된 정보를 보유하여야 한다.

계획(planning)에 따라 이행되었음을 객관적으로 검증하는 방법은 바로 각 단계마다 요구되는 사항을 적절하게 문서화하는 것입니다. 지나간 것은 다시 되돌 수 없기에 이전에 있었던 목표대비 실적에 대한 결과와 현재 진행상태가 적절함을 문서로서 확인할 수 있습니다.

이에, 설계/개발 입력값으로 어떤 사항들이 들어갔는지 a)~e)항에 따라 명시되어야 합니다.

---

설계와 개발에서 "입력(inputs)"이 중요한 이유는, 지금부터 이뤄지는 설계/개발 행위와 관리가 모두 입력값을 기준으로 하기 때문입니다. 8.2항에서 고객과 소통하고, 조직 스스로 뭐가 필요한지 검토하고, 법이랑 규제적인 요구사항이 없는지 검토해서 출력해 놓은 많은 요구사항들이 그대로 입력값으로 적용될 수 있도록 해야 합니다.

​

실무를 하다 보면 "그거 뭐 당연하고 아니냐"라고 말씀하실 수 있겠지만, 그 당연함이 여러 부서와 여러 단계를 거치다 보면 누락되는 경우가 허다합니다. 분명히 각 부서에서 검토결과를 줬는데, 누락돼서 설계/개발과정에 반영되지 않아 나중에 갈아엎는 경우가 종종 발생합니다.

​

그 때문인지, ISO에서 설계와 개발 입력값을 정할 때 앞에서도 계속 언급했던 a)~e)를 강요하는 것이 아닐까요?

​

그럼 이만,