동시 공학 [concurrent engineering, 同時工學]

CE/ PDM

  

동시공학(Concurrent Engineering)의 정의

 

 

동시공학은 제품설계단계에서 제조 및 사후지원업무까지도 함께 통합적으로 감안하여 설계를 하는 시스템적 접근방법이다. 이 방법은 제품개발담당자로 하여금 개발 초기부터, 개념 설계단계에서 해당 제품의 폐기에 이르기까지의 전체 라이프사이클상의 모든 것 (품질, 원가, 일정, 고객요구사항 등)을 감안하여 개발하도록 하는 것이다. - 미국 국방성 IDA(1986년)

 

Concurrent Engineering is a systematic approach to the integrated, concurrent design of products and their related processes, including manufacture and support. This approach is intended to cause the developers, from the outset, to consider all elements of the product life cycle from concept through disposal, including quality, cost, schedule, and user requirements.

 

 

동시공학 추진 배경

 

 

1980년대에 들어서면서 여러 제조 기업들은 그들의 신제품개발 업무를 근본적으로 과거와는 다른 방식으로 수행해야 한다는 필요성을 느끼게 되었다. 이러한 배경에는 신제품의 수명이 점점 짧아지는 추세와 함께 각종 기술(제품기술, 생산기술, 관리기술)이 급속히 발전하면서, 각 기업은 조직규모가 거대화되어지고, 글로발화됨에 따라 새로운 형태의 제품개발업무가 나타나기 시작했기 때문인 것으로 보인다. 이러한 상황에서 1982년 미국 국방성 산하의 DARPA(Defense Advanced Research Projects Agency)는 제품개발과정에서의 동시성(Concurrency)향상을 위한 방법을 모색하기 시작하였으며, 그 후 1986년 미국 IDA(the Institute for Defense Analyses)에 의하여 동시공학(Concurrent Engineering)이라는 단어가 탄생하게 되었다. 동시공학에 대한 여러 정의가 있지만, 흔히 많이 인용되는 IDA의 용어 정의에 의하면 동시공학은 제품설계를 할 때, 제조 및 사후지원 업무까지도 함께 통합적으로 감안하여 설계를 하는 개념이라고 하겠다. 이러한 동시공학 개념의 설계에 의하면 제품개발 담당자는 개발 초기 시점부터, 그 후속 공정이라고 할 수 있는 생산, 판매, A/S 및 폐기에 이르는 전체 과정을 감안하여 제품개발업무를 수행해야 한다고 하겠다. 흔히, 이러한 후속공정에 대한 고려가 사전에 이루어 질 수 있기만 하면, 여러 가지 설계 대안중에서 최적의 답을 발견하는데 큰 도움이 될 수 있다고 하겠다. 즉, 설계 초기단계에서는 개발 담당자가 비교적 다양한 선택대안을 가지고 있지만, 시간이 흐르면서 양산단계로 옮아갈수록 선택의 대안은 점점 줄어들면서, 그와 함께 변경에 따른 비용도 막대하게 소요된다. 그러므로, 기본적으로 동시공학에서 추구하는 사상은 선택의 폭이 넓은 개발 초기단계에서 제품의 생산성, 품질, 원가 등에 대한 검토과정을 거치도록 함으로써, 가능하면 설계변경이라는 시행착오를 줄이면서 경쟁력 있는 제품을 개발해 보고자 하는 것이라고 하겠다.

  

동시공학의 성공요인

 

역사적으로 동시공학 개념이 발전되어 온 과정에서 본 바와 같이, 동시공학 개념이 실제로 구현되는 모습은 시대적 상황에 따라 변하고 있다고 하겠다. 특히, 최근 정보기술의 발달과 함께, 각종 기법들의 개발은 과거의 동시공학 체제에서는 불가능했던 부분에 대해서까지도 지원이 가능한 체제로 가고 있다.

오늘날, 동시공학 개념을 성공적으로 도입하기 위해서는, 위 그림에서 보는 바와 같이 네가지 과제가 효과적으로 다루어 져야 한다. 그 첫째는, 엔지니어링 프로세스의 혁신으로 이는 최근의 BPR (Business Process Reengineering)개념을 엔지니어링 프로세스에도 적용시켜야 한다는 것으로 특히, 최근 제품개발기간의 단축이 기업경쟁력의 핵심요인으로 등장함에 따라, 이에 대한 많은 시도가 여러 기업에서 진행되고 있다고 하겠다. 두번째는 그동안 컴퓨터의 발달과 함께 새로운 기법과 도구 (예:CAD) 들이 최근 많이 소개되고 있는데, 이러한 기법들과 도구들을 충분히 활용할 수 있어야 한다는 것이다. 즉, 이들 기법들과 도구들을 잘 활용하는 경우, 경쟁기업과 비교하여 제품개발 프로세스 측면에서 전략적 우위를 줄 수 있는 신무기 역할을 할 수 있다고 하겠다. 한편, 이들 기법과 도구들이 보다 효과적으로 활용될 수 있기 위해서는 엔지니어링 프로세스 재정립 업무가 선행되는 것이 보다 바람직하다고 하겠다. 이는 마치, 자동차를 사용하여 이동 속도를 높히려고 할 때, 그 전의 구불구불한 상태의 길에서는 자동차의 효과를 충분히 기대할 수 없기 때문에 먼저 가능한 직선으로 새로운 길을 만드는 것이 필요한 것과 같은 이치라고 하겠다. 이러한 기법과 도구들을 선정할 때에도 기업의 환경에 맞는 것을 찾는 것이 필요한데, 이는 마치 자동차를 구입하는 경우에도 그 용도에 따라 다양한 사양이 있어서, 자신의 경제적 능력 내지는 사용목적에 맞추어 선택하는 것과 마찬가지라고 하겠다. 세 번째 동시공학의 성공요인은 동시공학 조직의 구성 및 운영 문제인데, 이는 그동안의 동시공학의 역사를 볼 때 가장 오래 전부터 고려되어 왔던 과제라고 하겠다. 여기서 문제가 되는 것은 제품개발 단계에 어떻게 다른 기능(생산, 판매, A/S등)의 조직들을 조직적으로 참여시키느냐 하는 것으로, 이는 기본적으로 그 강도의 차이는 있겠지만 어떤 형태로든 오늘날 대부분의 기업에서 진행되고 있다고 하겠다. 한 예로, 어느 기업은 제품개발 조직과 제조담당 조직간의 원활한 교류 -그것이 공식적이건, 비공식적이건-를 위해서 이들 두 조직을 가능한 같은 건물에 위치시키려고도 했으며, 어느 기업은 신제품개발이 완료되어, 양산체제가 되면 그 신제품을 개발하는데 참여했던 제품개발엔지니어를 공장으로 발령을 내서 해당 신제품의 양산단계까지 참여시켜서, 제품개발 엔지니어들과 생산 보다 담당자들과의 연결고리 역할을 하도록 하는 제도를 운영하기도 하였다. 그동안의 경험으로 보아 『skunk work 패러다임』에서와 같은 복합적인 기능을 갖춘 제품개발팀 (multi-disciplinary team)을 운영하는 것이 매우 효과적인 것으로 인정받고 있지만, 이러한 조직체계는 기업환경에 따라 조금씩은 다른 모습을 갖아야 할 것으로 보인다. 마지막으로 90년대 이후의 동시공학 개념을 운영하는데 있어서 정보기술의 효과적인 활용 문제는 빼놓을 수 없는 문제라고 하겠다. 엄청난 규모의 엔지니어링 데이터를 관련 조직간에 어떻게 효율적으로 효과적으로 공유하도록 할 것인가 하는 문제가 미국 국방성에 의해 제기된 것이 사실상 오늘날의 CALS 및 동시공학 탄생 배경이었다는 것만 보더라도 이의 중요성을 인정할 수 있다고 하겠다. 특히, 최근 기업들이 세계화전략 및 virtual company 등의 새로운 전략을 도입하기 시작하면서, 엔지니어링 정보를 관련 조직간이 효율적으로 공유하는 문제는 한층 더 복잡해지고 어려워질 것으로 전망되기 때문에, 이를 지원하는 정보시스템 기반구축은 성공적인 동시공학체제를 위해 더욱 중요한 요소로 인식될 것으로 보인다.

지금까지 소개한 동시공학의 네가지 성공요인은 모두가 유기적인 연관관계를 갖고 있기 때문에, 어느 하나만을 갖고서는 우리가 원하는 수준의 동시공학체제를 운영하기 어려울 것으로 보인다. 즉, 엔지니어링 업무의 프로세스혁신을 위해서는 당연히 정보기술의 전략적 활용이 필요하며, 새로운 기법 및 도구들의 사용도 고려되어야 할 것이며, 결과적으로 조직 형태에도 변화가 있게 된다는 것이다

 

동시공학 성공요인 1: 엔지니어링 프로세스의 혁신

 

● 업무의 동시진행(Overlap)에 의한 개발기간 단축

 

( 인용 : Developing Products in half the time by P.G.Smith, D.G. Reinertsen )

 

 

오늘날의 엔지니어링 프로세스 혁신에서 가장 중요한 과제 중의 하나는 업무의 동시진행에 의한 개발기간 단축이라고 하겠다. 이를 단순화시켜 본다면, 제품 개발 프로세스상의 선행업무에서 지속적으로 정보가 생성/누적되다가 그것이 끝나는 시점에서 모든 정보가 후행업무로 이관된다고 할 수 있을 것이다. 그러므로 선.후행업무의 동시진행을 위해서는 지금까지와는 다른 형태로, 정보를 축적시키거나 후행공정에 넘겨 주어야 한다고 하겠다. 위 그림에서 패턴 1은 전통적인 순차적 진행 절차를 보여 주고 있다. 즉, 선행업무가 완료되어야만 후행업무가 시작되는 환경을 보여 주고 있다고 하겠다. 패턴 2와 패턴 3에서는 선.후행 업무가 동시진행되는 상황을 보여 주고 있다. 이들 패턴이 패턴 1의 경우와 차이가 나는 점은 패턴 1에서는 완전한 전체정보가 선행업무에서 후행업무로 주어지기 때문에 선.후행 업무간의 커뮤니케이션이 비교적 한 방향(선행→후행)으로 분명하다고 하겠으나, 패턴 2,3의 형태에서는 부분적인 정보가 전달되기 때문에 선.후행 업무간의 커뮤니케이션 체제가 보다 원활해져야 한다고 하겠다. 특히, 패턴 3의 경우는 선.후행업무가 거의 동기화(synchronize)되어야만 가능한 체제라고 하겠다. 실제로 많은 기업들은 신제품 개발과정에서, 아직 확정되지 않은 검토단계의 부품도면 등을 협력업체에 송부하여 공급가격에 대한 견적을 받고 있는데, 이러한 것이 바로 동시업무진행의 한 예라고 하겠다.

이렇듯 동시진행의 정도를 높히기 위해서는 선.후행업무의 담당자들을 한 팀에 소속시키는 것이 가장 바람직한 것으로 보이며, 바로 이점이 복합기능을 갖춘 팀의 운영이 동시공학의 성공적인 운영에 매우 중요하다고 강조하는 이유라고 하겠다. 업무간 동시진행의 정도를 높히기 위해서는, 후행공정을 착수하기 위해서 필요한 선행업무로부터의 최소정보량이 무엇이며, 이러한 정보를 선행업무에서 가능한 빠르게 생성시킬 수 있는 시점은 언제인가에 대해서 상세한 검토가 필요하다고 하겠다.

 

동시공학 성공요인 1: 엔지니어링 프로세스 혁신의 효과

 

엔지니어링 프로세스 혁신과제에서 기본적으로 모든 기업들이 추구하는 과제는 첫째, 제품 라이프사이클에서 나타나는 여러 문제를 어떻게 개발/설계 단계에서 검토시킬 것인가 하는 것이다. 즉, 종전방식에서는 일단 최초설계가 완료되어 제조에서 양산이 되기 시작하면 그때부터 제조생산성, 품질, 제조 원가 등의 문제가 발견되면서, 많은 설계변경요구가 있게 된다. 마찬가지로 판매가 이루어져서, 소비자들이 실제 그 제품을 사용하기 시작하면서 내구성문제, 유지보수문제 등이 발생하게 되면, 이러한 정보가 제품개발엔지니어에게 피이드백 되어지고, 이에 대한 조치가 설계변경으로 나타나게 된다. 이러한 종전방식을 시행착오방식이라고 한다면, 기업들이 현재 재구축하려고 하는 동시공학방식에서는 개발/설계단계에서 가능하면, 이러한 후행 단계에서 나타나는 문제를 충분히 검토함으로써 양산단계 및 판매단계에서 나타나는 변경 요구 사항을 최소화 하려고 하는 것이라고 하겠다. 예를 들어, 최근 여러 기업들은 개발/설계단계에서 재조성 (또는 조립성)을 검토하여, 어느 점수 이상을 받지 못하면 재개발/재설계하는 시스템을 운영하고 있다. 물론 이러한 방법을 도입하게 되면, 초기 개발/설계단계에서 당연히 종전보다 많은 시간과 노력이 필요하게 되나, 결과적으로 보면, 전체 라이프 사이클상에서는 시간과 노력을 줄이는 효과가 있음을 보게 된다. 미국 공군보고서에 의하면 동시공학개념 도입으로 제품개발기간이 단축되는 양상을 분석한 결과 전체적으로는 종전대비 40% 절감효과를 가져오는데, 오히려 개념설계 단계에서는 종전의 3%에서 20%로 증가하는 것을 발견할 수 있다. 바로, 이러한 초기 단계에서의 집중적인 검토가 나중에 발생하는 많은 설계변경을 줄일 수 있는 계기가 되는 것이라고 하겠다 (55% → 22%).

 

동시공학 성공요인 2: 새로운 기법 및 tool 도입

 

QFD (Quality Function Deployment) DFX (Design For X = Assembly, Manufacturing, Test, Maintenance) CAPP (Computer Aided Process Planning) CAD (Computer Aided Design) CAE (Computer Aided Engineering) CAM (Computer Aided Manufacturing)

 

동시공학이란 이미 앞에서 설명한 바와 같이 하나의 개념이라고 하겠다. 하나의 개념을 구현하는 데에는 여러 가지 방법이 있을 수 있으며, 그러한 방법은 시대적 환경에 따라 변한다고 하겠다. 특히, 새로운 기법(technique)이나 도구(tool)의 등장은 특정 개념을 구현하는 방법 자체에 커다란 영향을 준다고 하겠다. 예를 들어, 전쟁을 수행하는 전략과 전술은 새로운 무기체계의 발달에 따라 급격한 변화를 해오고 있는데 이는 그 좋은 예가 된다고 하겠다. 동시공학의 경우도 앞에서 이미 설명한 바와 같이 그 발전과정을 돌이켜 볼 때, 초창기에는 주로 조직 관리적인 측면에서 복합기능을 갖는 전담팀 구성을 통한 동시공학 형태가 추진되어 왔다고 한다면, 최근 들어서는 정보기술의 발달에 따른 새로운 기법 또는 도구의 도입이 전략적 차원에서 이루어지고 있다고 하겠다. 현재 많은 기법과 도구가 소개되고 있는데, 그 중에서 몇 가지를 고객요구의 정의단계에서부터 개발, 설계, 생산의 라이프사이클 흐름에 따라 소개하기로 한다.

 

 QFD(품질기능 전개법)

 

이 기법은 고객의 요구사항을 제품의 설계특성으로 변환하고, 이를 다시 부품특성, 공정특성, 그리고 생산을 위한 구체적인 사양으로까지 변환시키는 방식이다. 이렇게 고객의 요구사항을 체계적으로 정리하고 그에 대한 해결방안을 모색함으로써 각각의 고객 요구사항을 누가, 어떻게 만족시킬 것인가 하는 것에 대한 조직간의 명확한 업무분담이 가능해 진다고 하겠다. 그러므로 QFD기법을 성공적으로 도입하기 위해서는 당연히 여러 관련조직이 적극적으로 참여해야 한다고 하겠다.

 

DFX (Design For Assembly, Manufacturing, Test, Maintenance)

 

이러한 용어가 공식적으로 만들어지기 이미 오래 전부터, 사실 제품개발단계에서 조립성 내지 제조성에 대한 검토가 이루어져 왔다고 해야 할 것이다. 즉, 이미 제품개발 태스크 포스팀에 참여하고 있는 제조기술 엔지니어 및 제조 담당자들은 설계과정에 참여하여 조립성 및 제조성에 대한 의견을 제시해 왔던 것이다. 그러나 70년대 초부터 이러한 개념들이 체계적으로 정리되어지면서, 제품설계를 하는 시점에서, 후행업무(제작, 조립, 테스트, 유지보수 등)에 대한 고려까지 해주어야 한다는 사상이 확산되게 되었다. 최근에는, 조립성, 제조성을 평가해 주는 소프트웨어도 많이 이용되고 있는데, 특히 CAD작업과 연계하여 이러한 조립성, 제조성을 신속하게 평가해 주는 전문가 시스템도 등장하고 있다.

 

CAPP (Computer Aided Process Planning)

제품설계 업무가 완료되면, 생산기술 팀에서는 그러한 제품을 어떻게 효율적으로 생산할 것인지에 대해서 검토를 하게 되며, 그 결과로 얻게 되는 것이 공정계획(process plan)이다. 일반적으로 최종적인 공정계획을 결정하기전까지 많은 가능한 공정계획을 놓고, 검토를 하게 되는데, 이러한 부분을 지원하는 것이 CAPP라고 하겠다. 즉, 가능한 여러 공정계획들을 생성시켜서 각각의 공정계획에 대한 검토를 통해 최적의 공정계획을 얻도록 지원해 주는 기법이라고 하겠다.

 

Digital Mock-up/Rapid Prototype

 

제품설계가 완료되면, 일반적으로 mock-up을 제작하여, 관련자들로 하여금 각종 검토를 하게 된다. 그러나, 이러한 mock-up을 제작하는 과정에 상당한 시간과 돈의 투자가 소요되어, 그 동안 문제점으로 지적되어왔는데, Digital Mock-up과 Rapid Prototype은 이러한 문제점을 개선시키는 새로운 개념으로 부각되고 있다. Digital mock-up은 컴퓨터 화면상에서 관련 부품들을 가상 조립하여 만드는 것으로 실제 현장에서 부품과 부품의 조립과정에서 발생할 수 있는 문제를 컴퓨터 화면상에서 검토할 수 있다는 장점을 갖고 있다.

Rapid Prototype은 Digital Mock-up이 화면 속의 mock-up 이어서 실제 만져 볼 수 없다는 단점을 극복 할 수 있는 것으로서, 3차원 CAD를 이용하여 모델링을 하는 경우 그 데이터를 이용하여 흔히 수지를 이용하여 짧은 시간에 Physical Mock-up을 제작해 내는 것을 의미한다. 특히, 보잉 777프로젝트에서 Digital Mock-up을 이용하여 컴퓨터 화면상에서 부품간의 간섭문제를 사전 점검함으로써, 설계변경건수의 대폭 절감과 함께 최종 조립장에서의 생산성 향상을 가져 올 수 있었던 사례는 성공사례로서 흔히 인용되고 있으며, 최근 국내 대기업들의 benchmarking 대상이 되고 있다.

  

동시공학 성공요인 3: 동시공학 조직도입

 

  1) 기능별 조직 형태

 2) 약한권한을 갖는

 3) 균형있는 형태, 팀 조직형태 의 팀조직형태

 4) 강한 권한을 갖는 5) 기능조직과 분리된 형태의 팀 조직형태, 팀 조직형태 (인용: Developing Products in half the time by

P.G. Smith & D.G. Reinertsen)

 

전통적으로 기업들은 기능중심의 조직 형태(그림1)를 유지하여 왔으나 이러한 조직형태는 동시공학의 핵심 성공요소인 기능간의 협력체계(cross-functional activities) 구축에 적합치 않은 것으로 인식되고 있다. 즉, 이러한 조직 체계하에서는 신제품개발 업무가 여러 기능 조직에 독립적으로 나뉘어져 맡겨지기 때문에, 관련 조직들이 업무를 동시, 병행으로 진행시키고, 관련 업무를 인수/인계하기 위해서는 별도의 조정작업이 필요하게 되는 문제가 있다. 이러한 이유 때문에 동시공학 개념을 도입하려고 하는 기업들은 일반적으로 앞으로 설명하게 될 팀 중심조직을 채택하는 경향이 있다.

두번째 조직 형태는 그림 2 에서와 같이 약한 권한을 갖고 팀제를 운영하는 모습인데, 이러한 조직형태에서 팀의 책임자는 실질적인 권한을 부여받지 못하기 때문에, 단지 기능 조직들이 주도적으로 업무추진계획을 수립하면, 이를 수동적으로 수행하는 역할밖에 할 수 없게 된다. 이러한 문제에도 불구하고, 팀의 책임자가 전담하여 관련업무를 추진하기 때문에 그림 1의 기능중심조직보다는 효율적으로 신제품 개발업무를 추진할 수 있다고 하겠다. 그러나, 이러한 조직형태에서는 팀의 책임자에게 충분한 권한이 부여되지않은

관계로 제품개발의 여러 의사결정과정에서 각 기능의 책임자들과 많은 마찰을 일으킬 소지가 있다고 하겠다.

이러한 문제를 보완한 형태가 그림 3의 균형 잡힌 형태의 팀 조직이라고 하겠다. 이러한 조직 형태에서는 기능조직 책임자와 팀조직 책임자에게 어떻게 권한을 나누어 줄 것인가 하는 것이 문제가 되는데, 한 예로 팀 책임자는 팀 소속 구성원들의 man-hour 사용계획에 대해 권한을 갖는다면, 기능조직의 책임자는 해당 기능 조직 구성원들의 전문성 제고 및 업무추진의 표준방법 제시 등에 대한 권한을 갖는다는 것이다. 즉, 기구설계를 담당하는 기능조직의 책임자가 전사적으로 똑같은 Stress Analysis 방법을 쓰거나, 또는 전사적으로 표준화된 특정 부품 사용을 의무화 한다는 것이다.

그림 4는 오히려 팀의 책임자가 더 많은 권한을 갖는 경우라고 하겠다. 즉, 프로젝트에 관한 모든 권한을 팀의 책임자가 갖도록 함으로써 그림 2나 3에서와 같은 조직간의 모호한 관계를 분명히 하여 개발업무의 효율화를 도모하기 위한 것이다. 그러나, 어디까지나 팀 구성원들에게는 각 기능조직에 소속감을 부여함으로써 전문 업무별로의 유대감을 지속시키고, 또 프로젝트 완료 후에 그들이 다시 속하게 될 조직에 대해 확신을 줄 수 있다는 이점이 있다고 하겠다. 마지막으로 그림 5는 기존 조직과는 완전히 분리된 형태의 독립된 팀제의 모습으로서, 그림 4의 조직과 비교하여 보다 더 독립적이며 기업가적 환경(entrepreneur environment)을 불어 넣어 주는 조직 형태라고 하겠다. 특히, 이러한 팀제는 신제품 개발업무가 긴박한 상황에서 효과가 있는 형태라고 하겠다.

 

동시공학 성공요인 4: 정보기술 기반구축 (IT enabler)

 

Engineering data와 Workflow 관리의 중요성   -.Engineering data 제품데이타(Product data) + 프로세스데이타 여러관련조직에서 생성되고 사용됨/공유필요성 매우 높음 여러 장소에서 보관되며, 여러 형태유지   -.Engineering Workflow 제품규격정보 → 제조정보 → 고객 복잡한 업무흐름도 변경이 빈번하여, Version 관리 중요

 

동시공학개념을 성공적으로 도입하기 위한 요인가운데 빼놓을 수 없는 것이 엔지니어링 데이터와 워크플로관리라고 하겠다. 엔지니어링 데이터는 제품개발 과정에서 발생하는 모든 데이터를 의미하는 것이며, 엔지니어링 워크플로는 엔지니어링 업무의 진행과정에서의 데이터 흐름을 관리/통제 하는 것인데, 그 흐름은 반드시 엔지니어링 조직에 국한되지 않는다. 즉, 엔지니어링 데이터를 필요로 하는 조직 (예: 영업, 생산, 고객 등)에 까지 확장된 개념으로 인식되어야 한다. 먼저 엔지니어링 데이터는 크게 제품 데이터와 프로세스 데이터로 나누어 볼 수 있는데, 다음의 표 1은 이러한 엔지니어링 데이터의 예라고 하겠다.

 

표 1) 엔지니어링 데이터 종류

● Functional specification ● Engineering Drawings ● Assembly Drawing ● Parts List ● Tool & Fixture design ● NC Program ● Spare part 정보 ● 표준시간/표준원가

● Process plan ● BOM ● QA 데이터 ● Test Result ● 구매 단가/업체 ● Field Failure report ● Facility drawing

 

이러한 엔지니어링 데이터의 속성중 하나는 이러한 데이터가 여러 조직에서 생성되어 지면서, 또한 여러 조직에서 공유되어야 하기 때문에, 그 체계적인 관리가 매우 어렵다는 것이다. 특히, 그 저장형태가 다양하기 때문에 정보관리 입장에서도 매우 어려운 속성을 지니고 있으며, 또 데이터 양이 막대하기 때문에 관리상의 복잡도를 증가시킨다고 하겠다.

 

한편 엔지니어링 워크플로에서 관리해야 하는 업무도 고객의 요구정의에서부터 제품의 유지보수업무에 이르기까지 매우 다양한데 표 2가 그러한 업무를 보여주고 있다.

 

표 2) 엔지니어링 워크플로에서 다루는 업무

● 마아켓팅 ● 타당성 조사 ● 개념설계 ● 프로토타입 제작 ● 구매

● A/S 지원 ● 프로젝트관리 ● 상세설계 ● 프로세스 설계 ● 생산(조립/검사)

 

엔지니어링 워크플로의 경우, 업무간 관련 엔지니어링 데이터를 교환하여야 하는데 앞에서 이에 설명한 바와 같이 엔지니어링 데이터의 종류와 양이 많기 때문에 어려움이 많다고 하겠다. 특히 엔지니어링 데이터는 그 속성상, 매우 빈번하게 변화하기 때문에 데이터 Version 관리상의 어려움을 주고 있는데, 이러한 점도 엔지니어링 워크플로관리를 어렵게 만드는 요인이라고 하겠다.

 

동시공학 성공요인 4: 정보기술 기반구축

 

일반적으로 제조기업의 경우, 엔지니어링 데이터와 엔지니어링 워크플로 관리가 제대로 이루어지지 않고 있는 것으로 보이는데, 만약 다음과 같은 현상이 자주 관찰되는 경우, 그러한 업무가 제대로 이루어지지 않고 있다고 하겠다..

 

-. 데이터 분실이 잦다.

-. 데이터를 찾는데 많은 시간이 걸린다.

-. 데이터 공유가 잘 안되며, 데이터 관리의 책임자가 불분명하다.

-. 관련조직들이 서로 다른 데이터를 보유하고 있다.

-. 조직간에 데이터를 교환하는 속도가 느리다.

-. 설계변경 관리 속도가 느리다.

-. 프로젝트 책임자가 최근 현황을 제대로 파악치 못하고 있다.

-. 자료의 version 관리가 안된다.

-. 기술 매뉴얼등이 맞지 않는다.

 

이러한 문제들이 나타나는 원인은 여러가지가 있겠지만, 대부분의 경우 엔지니어링 데이터와 워크플로관리가 제대로 이루어지지 못하기 때문인 것으로 분석되고 있다. 특히 위에서 보는 것과 같은 현상 때문에, 제품개발 엔지니어의 man-hour 중 단지 20~30% 정도가 도면작성 및 부품개발 등 엔지니어링 고유업무에 사용되며, 나머지 시간은 문서 및 매뉴얼 작성, 자료조사, 회의 등의 업무에 사용하는 것으로 되어 있다. 결국 이렇게 제품개발 엔지니어들이 비효율적으로 시간을 활용하기 때문에 제품개발기간이 길어지고, 제품개발비용이 상승한다고 하겠다. John stark는 그의 저서 “Engineering Information Management Systems” 에서 엔지니어링 데이터관리와 워크플로관리를 잘하면 적어도 엔지니어링 비용의 10%, 제품개발기간의 20%, 설계변경 소요시간의 30%, 설계변경 건수의 40%를 절감할 수 있다고 소개하고 있다. 엔지니어링 데이터 관리와 워크플로관리를 효율적으로 하기 위해서는 이를 지원하는 정보시스템 구축이 반드시 필요하다고 하겠다. 이러한 업무를 지원하는 정보시스템이 종전에는 엔지니어링 데이터베이스 개념으로 소개되다가 점차 발전하여, 최근 PDM (Product Data Management)시스템으로 확산단계에 이르고 있는데, 이에 대해 보다 상세한 내용은 뒤에서 소개하기로 한다.

 

동시공학 성공요인 4. 정보기술 기반구축

 

(동시공학 IT 응용발전단계)

동시공학개념을 성공적으로 도입, 운영하기 위해서는 정보시스템 지원측면에서 엔지니어링 데이터가 체계적으로 관리되어야 하고, 이러한 데이터가 관련 엔지니어들간에 자유롭게 교환될 수 있는 환경이 구축되어야 한다. 그러나, 이러한 환경의 정보시스템 구축이 단기간에 이루어 질 수 있는 것은 아니므로, 단계적인 추진 전략이 필요하다고 하겠다. 위의 그림에서는 크게 이러한 정보화 추진과정을 네 단계로 보여주고 있다.

 

우선, 현재의 환경이 각 기능단위로 독자적으로 정보화가 이루어진 상태라고 가정하였을 때, 우선적으로 진행되어야 하는 업무는 각 단위조직별로 설치되어 있는 컴퓨터 및 데이터베이스들이 상호연계 운영될 수 있는 환경을 조성하는 일이다. 보다 구체적으로 이러한 환경하에서의 정보시스템 운영모습을 묘사한다면 다음과 같다고 하겠다.

 

-. 컴퓨터 지원을 받는 각종 Tool들과 데이터베이스가 네트워크로 연결되어 공유된다.

-. 동일한 하나의 데이터를 전 조직이 이용함으로써 데이터 일치성이 유지된다.

-. 정보교환의 절차 및 포맷을 표준화하여 전 조직이 이용한다.

 

결국 이러한 업무들이란 엔지니어링 업무분야에서 그동안 산발적으로 그리고 비통합적으로 정보화가 추진되어온 결과로 나타나는 정보의 섬(Islands of Automation) 현상을 개선하여 하나의 통합된 환경으로 만드는 일이라고 하겠다. 이러한 환경을 구축하게 되면, 엔지니어링 데이터가 체계적으로 생성되고 저장되어지는 기반이 마련되어진다고 하겠는데 이러한 인프라 환경하에서 그 다음으로 진행되어야 할 부분은 각종 엔지니어링 데이터의 활용 문제라고 하겠다. 즉, 관련 조직간에 어떻게 신속하고 정확하게 필요한 정보를 상호 교환하는 체제를 구축할 것인가를 고려하는 단계라고 하겠다. 특히 설계변경 등으로 변화되는 정보를 정확하게 version관리를 해가면서, 변화된 정보를 관련되는 조직과 담당자들이 신속하게 공유할 수 있도록 하는 것이 이 단계에서의 중요한 업무라고 하겠다. 세 번째 단계는 프로세스 관리단계로서, 엔지니어링 워크플로 업무를 지원하는 단계라고 하겠다. 즉, 프로세스의 흐름에 따라 담당자가 해야 할 일을 자동으로 통보하고 수행할 수 있도록 하며 특히 여러 작업자가 동시에 병렬 업무처리를 하는 것이 가능해지는 체계라고 하겠다. 마지막 단계는 의사결정 지원단계로서, 이는 작업자들의 의사결정 과정을 일차적으로 컴퓨터가 지원해 주는 체계라고 하겠다. 예를 들어, 최근 많은 기업이 도입하는 CAD시스템의 digital mock-up 기능 또는 rapid prototype은 설계 단계에서 해당제품의 조립성 또는 외관 등을 용이하게 검토할 수 있도록 지원하는 대표적인 의사결정 지원 도구라고 하겠다.

 

동시공학 성공요인 4

 

PDM도입에 따른 전산환경의 변화

 

앞장에서 제품 데이타와 워크플로관리를 위한 정보시스템 개념을 총칭, PDM(Product Data Management)시스템이라고 소개하였다. 이제 PDM시스템의 주요기능을 보다 상세하게 설명하기에 앞서 이러한 시스템을 도입할 때 엔지니어링 분야의 정보화 환경이 전반적으로 어떻게 달라지는가에 대해 알아보기로 한다. PDM시스템이 도입되기 이전에 엔지니어링 데이터의 관리는 각 업무별로 종속적으로 관리되어 왔었다. 예를 들어, 특정 부품에 대한 도면정보, 각종 기술문서, 업체정보, 품질정보 등을 얻고자 하면, 관련되는 각 팀의 데이터베이스를 조회하여야만 종합적인 정보를 취합할 수 있었던 것이다. 이렇게 팀단위로 정보관리가 되는 경우, 흔히 특정정보가 복제되어 여러 곳에서 활용되면서 각 팀이 보유하는 데이터가 일치하지 않아 혼선을 빗는 문제를 겪게 되는데 지금도 많은 기업들이 이러한 상황에 있다고 하겠다. 이 문제의 해결을 위해 소위 엔지니어링 데이터베이스 구축을 통해 부품에 대한 각종 정보를 집중 관리하려는 시도가 있었는데, 여전히 각 기능단위로 엔지니어링 데이터베이스의 구축이 이루어짐으로써 주요 기능간의 정보교환 과정에서 문제점은 여전히 남아 있어왔다.

 

PDM개념은 과거의 엔지니어링 데이터베이스 개념을 발전시켜서, 부품관련 모든 정보 - 도면, 매뉴얼, 실험결과 등 - 를 체계적으로 관리할 수 있도록 하는 기능과 함께, 과거의 엔지니어링 데이터베이스가 단순한 자료 저장과 조회등의 정적인 기능을 하였다고 한다면, PDM 시스템은 워크플로관리와 같은 정보의 동적 흐름에 대한 지원기능까지 포함시킴으로써 엔지니어링데이터의 일치성 문제는 물론, 엔지니어들간의 정보교환 생산성을 대폭 향상시킬 수 있는 기능을 보유하고 있다고 하겠다.

PDM은 제품의 개념정의 단계부터 설계, 개발, 제조, 출하 그리고 고객서비스에 이르기까지, 제품의 전 라이프 사이클에 걸쳐 발생하는 각종 데이터와 정보의 흐름을 효율적으로 제어하고 관리하는 시스템으로, 그 주요 기능은 데이터 저장 및 문서관리, 제품구조관리, 워크플로우 관리와 분류 및 검색기능 등으로 구분할 수 있는데, 이들 기능을 각각 소개하면 다음과 같다.

 

자료 저장 및 문서관리(Data Vault & Document Management)

 File Check-in/Check-out

모든 전자문서는 물리적으로 File 형태로 보관된다. 보관된 File은 O/S 수준에서 적절한 보안 처리를 고려하지 않으면 네트워크상 어떠한 클라이언트에서도 참조 또는 복사, 변형될 수 있으며 하나의 파일을 여러 사용자가 동시에 변경할 수도 있다. 여러 사용자가 공동으로 저장하고 동시에 참조하는 일련의 상황을 고려하여 저장 용량이나 파일 분류를 함에 있어 가장 최적의 상태로 파일을 보관하고 저장된 파일이 외부로 참조될 때에는 적정한 상태 관리를 통해 접근을 제어하기 위한 기능이 File Check-in/Check-out 기능이다.

Check-in은 파일을 저장할 때 개정 또는 버전을 관리하는 것이 주목적이며 사용자의 결심에 따라 별도 파일로 저장(Create)할 수도, 덮어 쓰거나(Overwrite) 저장을 취소할 수도 있다.

Check-out은 검색을 원하는 사용자의 접근 권한을 확인하여 적절한 보안을 유지하는 기능으로, 자격있는 사용자의 요청에 따라 파일을 해당 클라이언트로 복사하며 이때 파일의 상태를 관리함으로써 다른 사용자가 해당 파일을 동시에 참조하지 못하도록 할 수 있다.

문서의 저장 상태는 Draft/To check/Checked/Approved/Release 등으로 나눌 수 있으며 각각의 의미는 아래와 같다.

·         Draft : 초안으로써 파일이 처음으로 작성되어 저장될 때 무조건 주어진다.

·         To check (검토의뢰): 작성된 초안을 검토 권한이 있는 사용자(이 경우 본인 포함)에게 의뢰한 상태를 말한다.

·         Checked (검토완료): 검토 의뢰된 파일을 검토자가 검토했을 경우 파일은 이 상태로 바뀐다. 이때 필요한 경우 검토자의 의견이 첨부될 수 있다.

·         Approved (승인완료): 검토가 완료된 파일(승인 조건에 의해 검토가 완료되지 않은 상태에서도 승인될 수 있다)에 대해 승인권자가 승인을 마친 상태를 말한다.

·         Release (배포): 승인이 완료된 파일은 최초 기안자(또는 시스템)에 의해 적절한 배포선에 따라 수발될 수 있다.

·         Meta-Data

저장소(Data Vault)에 파일을 보관하는 것은 단순히 저장 장소를 지정하는 것 뿐만 아니라, 저장된 파일의 관리 항목과 응용프로그램 사이에 상호 연관성 등을 별도의 속성으로 관리하는 것까지 포함한다. 

[Metadata와 Vault의 개념 ]

·         파일 분산

저장소는 물론 저장되는 파일 역시 물리적으로 여러 곳에 분산될 수 있다. 이와 같은 경우에도 논리적으로 하나의 저장소처럼 관리되는 기능이 필요하다. 파일이나 저장소가 분산된 경우 동일 내용에 대한 동기화가 주요 과제이며 이를 위해 복제(Replication)를 이용한 동기 유지가 하나의 방법일 수 있다.

 

업무절차관리(Workflow & Process Management)

  

제품개발활동과 관련하여, 개발에 직간접으로 기여하는 인력들 사이에 업무절차를 정의하고 정해진 절차에 따라 업무를 수행함으로써, 동시 개발활동을 보장하려는 기능이다. 반복적인 업무 또는 절차가 정해진 업무를 자동으로 처리토록 하며, 이 과정에서 필요한 제품정보를 연계 처리한다.

·         설계변경

엔지니어링 업무에서 업무절차를 관리하는 주된 목적중의 하나는 설계변경을 체계적으로 관리하자는 것이다. 한건의 설계변경은 하나의 특징적인 이벤트로 표현될 수 있으며 이러한 이벤트는 ECR (Engineering Change Request)을 시작점으로 ECO (Engineering Change Order), ECN (Engineering Change Notification)으로 진행되는 동안 일관성 유지를 위한 키워드(구분자)로 이용된다.

 

Engineering Change Request

 

제품 개발 또는 제조, 판매 현장에서 제품 트러블이 발생되었거나 새로운 개선 사항이 발생하면, 해당 담당자는 제품 개발 엔지니어에게 자신의 의견을 일반적인 문장으로 서술하여 설명하거나 보다 구체적으로 기술적인 변경 대상을 지적하여 기술적 검토 및 조치를 요구한다. 이와 같은 요구는 업무처리 절차상 하나의 태스크를 발생시킨다.

ECR에는 요청자 정보와 요청 내용, 조치 요망일 등이 포함된다.

 

Engineering Change Order

ECO은 접수된 ECR을 검토하고 이에 대한 기술적 조치 사항을 서술하는 것으로, 통상 부품, 조립품 단위의 추가, 삭제, 변경과 함께 관련된 각종 기술문서의 변경, 첨부 등을 포함한다. 여기에 변경 조건(예를 들면, 적용일자, 적용 LOT 등)이 부가될 수 있다. 변경 대상과 범위, 조건 등이 결정되면 최종적으로 승인이나 검토를 위한 Routing 정보 (누가 검토하고 승인할 것인가 하는 정보)가 부가된다.

 

Engineering Change Notification

ECO에 포함된 Routing 정보에 따라 해당 검토자 또는 승인권자에게 ECO의 승인 또는 검토를 요청하는 기능이다. 승인된 ECO는 두가지 기능을 수행한다.

먼저 변경 내용과 변경 범위, 조건 등을 실제로 시스템에 반영하는 기능이다.

 이때 부품이나 BOM 등은 MRP/ERP와 밀접한 관련이 있기 때문에 데이터 밸런스 측면에서 MRP/ERP Interface에 기반을 둔 보다 복잡한 동기화 과정을 거친다.

다음으로 관련된 인원에게 ECO를 배포하는 기능으로 통상 ECO 내용에 미리 배포선을 지정하거나 승인 후 ECO 담당자가 배포선을 지정한다.

·         절차정의

프로세스 정의

프로세스는 입력과 출력, 수행 조건, 수행 주체를 포함한 업무 처리 단위를 말한다. 프로세스는 통상 전후 프로세스를 갖게 되며 이때 다음 단계로의 진행 조건이 부가된다. 또한 필요에 따라 각종 Engineering Resource가 배정될 수 있다.

 

분기조건

프로그램(프로젝트)을 구성하는 경우 프로세스간 선후행이 지정되고 이때 선형 순차 흐름을 포함하여 비선형 병렬 처리 등 다양한 조건 분기를 갖을 수 있다. 여기에서 분기 기준은 선행 프로세스의 수행 결과이며 진행, 기각(Feedback), 조건부 진행, 다자간 선택 등의 조건이 있다.

 

의사결정방식

회의체를 운영하는 경우나 검토자가 1인 이상인 경우 필요에 따라 의사 결정을 표결에 의존할 수 있다. 이런 경우 내장된 Rule 정의 기능을 통해 적절한 의사 결정 방법을 선택할 수 있다.

 

통지 및 배포

모든 프로세스 수행 과정과 결과는 관련된 모든 사람에게 전자적으로 통지 또는 배포되어야 한다. 설계변경에서 설명된 바, 통지 및 배포를 위해 메시지 통제 기능은 필수이며 통상 프로세스 관리자와 메시지 관리자, 별도의(또는 내장된) 메시지 브라우져를 통해 이 기능을 달성한다.

 

프로세스 통제

프로세스는 필요에 따라 강제 종료되거나 수행될 수 있다. 모든 프로세스는 프로세스 관리자를 통해 모니터링되며 필요한 경우 개별 사용자 또는 단위 프로세스 사용을 제한할 수 있다.

제품구조 관리( Product Structure Management)

 

제품을 구성하고 있는 부품의 선.후행 조립 및 부품.문서 관계를 정의하고, 설계변경에 의한 version이나 옵션(option), 유효성등을 통합 관리하는 기능으로 MRP, CAD등과 같은 computer-aided tool과의 동기화 연결을 포함한다. 

·         구성(Configuration)

모든 제품은 부품 대 부품 또는 부품 대 조립품과 같이 조립품을 구성하고 있는 단위 부품으로부터 특정 기능을 수행하는 많은 조립품으로 이루어져 있다. 제품 구성은 크게 표준 구성을 정의하는 것과 구성된 표준에 맞춰 실제 부품을 채택하는 것이다. 조립품의 경우 공정 정보를 포함할 수 있으며 공정 정보는 다시 공정 그 자체로 유효한 것과 관리를 목적으로 조립품이 될 수 있다.

구성 대상으로는 앞에서 언급한 부품, 조립품 뿐만 아니라 모든 “목적물”을 포함한다. 따라서 각종 기술문서나 도면 등 제품을 구성하는데 필요한 제 요소들이 모두 연결될 수 있다.

·         버전

제품을 구성하고 있는 부품, 조립품은 개발 과정을 통해 설계 사양이 수시로 변경될 수 있으며 일단 변경된 사양은 관리 목적에 따라 버전 관리된다. 통상 제품구조에 있어 버전은 설계변경 기능을 통해 이루어진다.

·         옵션

옵션은 광범위한 대치 또는 판단, 공용 사양을 의미한다. 제품을 구성하고 있는 모든 부품, 조립품 그리고 이와 관계있는 각종 문서는 초기 구성과 호환 또는 대치될 수 있는 품목이 존재할 수 있다.

 

공용

부품의 기능이나 규격이 동일하여 호환될 수 있는 모든 경우를 말한다.

 

대치

통상 공용과 유사하며 보다 좁은 의미에서 100% 호환을 보장하는 경우에 해당한다.

  

판단

부품의 기능이나 규격이 동일 또는 유사한 경우로 반드시 제품 개발자의 판단에 따라 채택해야 한다.

 

바이어선택

표준이 되는 제품을 기준으로 바이어의 요구에 따라 차이가 나는 사양을 별도로 표기, 반영한다.

 

기능선택

보다 고도화된 옵션 기능으로 제품을 구성하고 있는 조립품 중 모듈화가 가능한 조립품에 대해 특징있는 기능별로 분류한 다음 이들 모듈을 제품 요구 사양에 맞게 선택한다.

·         유효성

때로 제품 구성상 동일한 구성 위치에 한 개 이상의 부품이 채택될 수 있으며 이런 경우 新舊의 차이에 의해 적용 범위 또는 기간이 각기 다를 수 있다. 또한 설계변경시 변경 조건을 부여함으로써 발생될 수 있다.

·         설계변경

제품정보에 있어 설계변경은 최소 설계변경 요구에서부터 설계변경 처리, 통지에 이르는 전 과정을 말한다. 대상 정보로는 제품 사양과 조립품 사양, 부품 사양 등이 있으며 관련된 기술문서 등도 포함된다. 설계변경은 단독으로 실행되는 경우도 있고, 설계 과정에서 수시로 발생되는 정보 변경 사항을 바로 획득함으로써 미리 정해진 업무처리 절차에 따라 데이터 저장 기능과 상호 작용하여 처리되는 것이 일반적이다.

·         MRP/CAX Interface

MRP/ERP Interface

제품 개발 과정에서 발생한 제품정보 중 부품정보, BOM정보, 설계변경정보, 공급자, 개발원가 그리고 도면같은 주요 기술문서는 제품 생산을 위한 기본 정보가 된다. MRP/ERP Interface는 PDM 시스템과 ERP/MRP 사이에 상호 교환이 필요한 제품 정보를 끊김없이 전달하는 수단이며 Push나 Pull 방식 또는 API, Gateway 방식 등 다양한 연결 방식이 존재한다.

제품 개발자와 생산자 사이에는 제품을 바라보는 관점에 차이가 있다. 제품구조에 있어서도 기능 중심의 계층구조는 개발자의 입장에서 본 것이며 생산자는 공정 중심으로, 서비스는 수리 중심으로 판단하게 된다. 이런 다양한 관점을 제품구조에 반영해야 한다.

 

CAX Interface

제품 개발자는 부품 또는 제품 설계의 대부분을 CAD에 의존하고 있다. 이런 의존도는 향후 더욱 심화할 것이며 제품정보와 상호 정보 교환 역시 그 중요도가 날로 증대되고 있다. CAX Interface는 그 수준에 따라 Encapsulation, Interface, Integration Level로 나눌 수 있으며 요구 수준이 높을 수록 그에 따른 비용, 기간, 공급업체와의 제휴관계가 중요해진다.

 

부품(목적물) 분류 및 검색(Part/Object Classification & Retieval)

  

부품(목적물)과 관련된 제반 정보의 분류 체계를 정의하고 부품(목적물) 종류별로 서로 다른 기술(목적) 특성을 고려하여, 각종 규격을 정의, 관리할 수 있는 기능이다. 또한 이미 등록, 관리되고 있는 부품(목적물) 정보를 기술적 관점에서 다양하게 검색할 수 있으며 항목별로 비교 검토할 수 있는 기능을 포함한다.

 

• 분류체계 정의

모든 부품이나 관리 대상이 되는 목적물은 나름대로 일정한 분류 체계를 갖는다. 이러한 분류체계는 과거 분류코드에 의존하는 단순한 분류 방식에서 벗어나 분류 체계 자체를 직관적으로 관리할 수 있게 되었다

 

[부품 분류 및 규격관리 예]

 

계층구조를 표현하고 계층구조 상하 관계를 직관적으로 정의할 수 있는 Tree View 형태의 Software Component를 활용한 이와 같은 기능은 전문가를 필요로 했던 축약된 분류코드를 자연어 중심으로 옮겨놓고 있다.

·         특성 항목 정의

부품 또는 목적물은 그 종류별로 관리 대상이 되는 특성치가 서로 다르다. 이런 서로 다른 특성치를 제대로 표현하기 위해서는 분류 체계별로 고유 특성치를 정의할 수 있어야 한다. 현재 대부분의 부품 규격 관리 체계는 부품코드를 기반으로 하여 일정 자리수의 품명 또는 규격 등으로 표현되고 있으며 규격 항목을 표현하기 위해 축약된 형태의 규격 표기가 대종을 이루고 있다. 이 경우 부품 종류별로 특이 항목을 표현할 수 없음은 물론이다. 이를 해결하기 위해서는 목적물을 정의할 때 해당 목적물만의 고유 특성을 정의할 수 있어야 하며 특성치 하나하나의 속성까지도 표현 가능해야 한다. 이 기능은 Parametric 검색과 연관되어 상호 기능 수행이 가능토록 구현되어야 하며 특히 검색 속도에 유의해야 한다.

·         Parametric 검색

일정한 분류 체계를 갖고 분류 체계별로 서로 다른 특성관리가 가능한 상태에서는 특성치에 따른 검색 기능이 필수적이다. 이는 과거, 코드와Database에 의존한 단순 SQL 명령어 방식에서 탈피하여 고유 특성치를 항목별로 반영함으로써 기술적인 내용을 보다 쉽고 빠르고 직관적으로 검색할 수 있음을 의미한다.

·         특성항목 비교

Parametric 검색이 완료된 상황에서 하나의 부품(목적물)을 기준으로 차이가 나거나 동일한 특성 항목을 비교하는 기능으로 제품 개발자로 하여금 공용 또는 대치, 판단을 신속하게 내리게 함으로써 재사용을 도모한다.

 

PDM구축 절차

  

PDM시스템을 도입하기 위한 일반적인 절차로 다음과 같다.

우선적으로 진행되어야 할 업무는 기존 엔지니어링 업무에 대한 BPR업무라고 하겠다. 즉, 현재의 업무 진행방법을 그대로 놓아두고, PDM시스템만 도입하는 경우, 본래 PDM시스템의 기능을 충분히 활용하지 못할 가능성이 높기 때문에, 새로운 엔지니어링 프로세스를 정립하는 작업이 선행되어야 한다. 이러한 엔지니어링 프로세스 재구축 단계에서는 엔지니어링부문이 달성해야 하는 전략적 목표를 달성할 수 있도록 프로세스가 설계되어야 한다. 그러나, 급진적인 프로세스의 변화와 함께 처음부터 PDM시스템을 전사적으로 전체기능을 확대 보급하는 것은 오히려 실패할 가능성이 높기 때문에 일단 시범적인 적용 프로젝트를 통해, 국부적으로 시험/운영해보고 단계적으로 이를 확대하는 전략이 바람직 하다고 하겠다. 또한 이미 앞에서 설명한 바와 같이, PDM시스템의 응용수준을 몇 단계로 나누어 볼 수 있는데, 첫 시도부터 완벽한 적용을 기대하기 어려우므로, 단계적인 적용전략이 필요하다고 하겠다. PDM시스템에서는 여러 종류의 자료와 컴퓨터 기술이 이용되기 때문에 가능하면 세계 및 국가표준을 채택(CALS표준)해 주는 것이 바람직하다고 하겠다.

 

PDM후의 기업활동

 

PDM을 도입한 후의 엔지니어링 분야의 업무모습이 어떻게 변화할 것인가에 대해서 알아보기로 한다. 먼저, 한 번 생성되어 입력된 자료가 여러 부서에서 공유되어지게 됨으로써, 데이터의 무결성이 이루어지고 (Single data, multi-use), 또한 연결되는 업무간의 정보교환 및 공유가 쉽게 이루어짐으로써 비부가가치 업무가 대폭 축소된다. 즉, 현재 70% 수준을 넘는 準(semi) 또는 非(non)엔지니어링 업무시간 (예: 기술매뉴얼 작성, 자료 조사, 회의) 의 대폭 간축이 가능해진다고 하겠다. 그 대표적인 예로서 설계변경이 불가피하게 발생하는 경우 즉시, 그 변경정보가 관련 조직 및 담당자에게 통보될 수 있음으로써, 필요한 조치를 신속하게 할 수 있도록 지원해 준다고 하겠다. 또한, 모든 데이터가 디지탈화되어 체계적으로 저장됨으로써 그동안 필요한 데이터가 분실되거나, 또는 필요한 데이터를 발견하는데 장시간 소요되던 현상을 대폭 개선할 수 있는 계기가 되었다고 하겠다. 더 나아가서, 이러한 각종 자료 (도면, 매뉴얼, 업체정보, 단가정보 등)가 부품중심으로 묶여서 관리되기 때문에 사용자 입장에서는 매우 쉽게 필요한 정보를 획득할 수 있게 된 것이다. 그러므로, 이러한 PDM환경하에서는 기존의 제품개발 프로세스가 일대 혁신을 가져올 수 있을 것으로 기대된다. 한 예로, 현재 점차 확대되고 있는 추세이지만, 국내외 여러 엔지니어링 팀들이 특정제품 개발에 동시에 참여하여, 공동으로 개발작업을 진행시키는 경우, 관련 팀간의 정보교환에 엄청난 인력과 시간을 소모 낭비하고 있는데, PDM시스템을 구축하게 되면 이러한 부분의 비효율을 대폭 제거할 수 있으리라고 기대한다.

[출처] 동시공학의 정의|작성자 레스큐