제품 및 공정의 개발 계획 수립

지난번 포스팅에서 말씀드린 것처럼 오늘은 제품과 공정의 개발 계획 수립에 대하여 포스팅하고자 합니다.

 

고객 요구 사항 확보

 

일단 개발 계획을 수립하기 위해서는 개발하고자 하는 부품에 대한 모든 요구사항을 알고 있어야 합니다.

이러한 요구사항은 도면과 더불어 고객의 SOR 또는 SQR로 접수되며 품질에 대한 요구사항뿐만 아니라 법적, 환경적 요구사항까지 확보하여야만 차질 없는 개발계획을 수립할 수 있을 것입니다. 특히 해외 수출이 요구되는 부품의 경우 이러한 법적, 환경적 요구사항이 추가로 발생할 수 있습니다. 

 

개발계획 수립 전에 설계와 품질, 물류 및 생산, 기타 전 영역의 고객 요구사항을 확보하고 검토할 수 있어야 합니다.

일례로 도면에 기재된 규격과 성능을 만족하는 부품을 제조하였으나 고객에게 제품을 인도하는 물류과정에서 해당 부품이 손상되거나 영향을 받았다면 물류적인 측면에서 검토가 부족했다고 할 수 있으며 고객의 요구사항을 만족했다고도 할 수 없을 것입니다. 

 

제품 및 공정 개발 검토

 

개발 계획을 수립하기 위하여 중요하게 확인되어야 할 사항중 하나가 이전 경험에서 습득한 제품 및 공정에 관한 요구사항들이 확인되고 적용되었는가 하는 점입니다. 

 

과거차 문제점 (Lessons Learned) 검토

 

이른바 과거차 문제점 (Lessons Learned)라고 불리는 이 과정을 위하여 조직은 사내뿐 아니라 필요하다면 고객의 과거차 문제점들을 확보하여야 합니다. 과거차 문제점은 기존에 부품을 개발하면서 발생하였던 문제점들을 정리해 놓은 것으로서 해당 문제를 개선한 내용을 포함하고 있습니다. 

 

수많은 부품들을 개발 및 양산하면서 설계, 생산, 검사, 물류등 개발 전반에 걸쳐 발생하는 여러 문제점들은 조직의 한 개인이 모두 알기 어려우며 발생 당시 리스트업되지 않는다면 습득되지 못하고 일회성 이슈로 끝나게 되어 다시 동일한 문제가 발생할 수도 있을 것입니다.

 

그렇기 때문에 과거차 문제점은 매월 업데이트되어 유사 부품의 신규 개발이 검토될 시 그 조직 구성원들에게 교육되어야 합니다. 조직은 과거차 문제점을 검토하여 도면 확정 전 설계부문에 불합리한 부분을 개선할 수 있고 공정 FMEA에 반영하여 현 공정의 문제점을 도출하고 개선안을 수립할 수 있습니다. 

 

또한 조직 내부가 아닌 고객에게서 발생된 과거차 내용을 확보함으로써 유사한 문제가 발생하지 않도록 공정 계획을 수립할 수 있는지 검토할 수 있습니다.

 

Lessons Learned 예시

위의 예시 양식은 다음과 같은 항목으로 이루어져 있습니다.

 

과거차 문제점 발생 내용

└ 발생장소 : 고객 수입검사, 고객 In Line, 또는 사내, 또는 자동차

└ 발생차종 : 프로젝트명

└ 내용 및 원인 : 문제 발생 현상 및 원인 파악

└ 조치사항 : 해당 문제에 대한 조치사항 (임시 대책, 근본대책)

 

신차종 개선 계획

└ 과거차 문제를 교훈 삼아 신차종에 적용할 개선 계획

└ 완료 책임자 : 담당자명

└ 완료 예정일 : 계획 일정

└ 완료일 : 실제 완료된 일자

└ 완료 현황 : G (Green-완료), Y (Yellow-진행 중), R (Red-미완료)

 

개선 내용을 그림 및 사진 등의 자료를 활용하여 정기적으로 업데이트하면 조직의 큰 자산이 될 것입니다.

 

고객 요구사항 검토

 

고객의 요구사항은 Technical Rieview 전에 검토되어야 합니다. 기 확보된 고객 요구사항 (도면, SOR, SQR 등)을 검토하였는데 고객의 요구사항을 충족할 수 없는 경우도 있을 수 있을 것입니다. 이러한 경우에는 반드시 고객에게 해당 내용을 알리고 개발 착수 전에 Deviation(이탈)에 대한 고객의 허용 또는 승인을 득해야 합니다. 만일 개발 착수 전 Deviation 고객 승인이 어렵다면 승인 시점을 고객과 협의하여 문서화하고 해당 시점 내 승인되어야 합니다. 

 

또한 고객이 지정한 재질 또는 Sub-supplier 가 있을 수 있습니다. 이러한 요구사항은 문서로 확보하여야 하며 개발 시 가용 가능 여부에 대하여 확인하여 Technical Review시 그 결과를 고객에게 전달하여야 합니다.  

 

결국 모든 이슈들은 문서화되어야 하며 Open Issue List에 등재되어 관리되어야 할 것입니다.

실무에서 기억해야 할 사항 한 가지는 기록으로 남겨져 있지 않다면 그 행위는 하지 않은 것과 다를 바 없다는 것입니다.

 

다음 포스팅에서는 제조 타당성 검토에 대하여 다뤄보도록 하겠습니다.

감사합니다.