[컴포넌트 선정과 개발(2)] 공급자 관리

[컴포넌트 선정과 개발(2)] 공급자 계약관리

[컴포넌트 선정과 개발(2)] 시스템 통합

공급자 관리

공급자란 생산자(또는 주계약자)에게 제품, 컴포넌트, 자재, 서비스를 제공하는 광범위의 외부조직을 가리킨다. 공급범위는 넓게는 주요 하부시스템이나 형상품목에서부터 작은 컴포넌트 부품에 이르기까지 다양하다. 공급자가 제공해야 할 용역대상은 다음과 같다.

· 대상 시스템을 구성하고 있는 주요 요소에 대한 설계, 개발, 및 제조
· 이미 설계된 항목(제작 소스 제공)의 생산 및 분배
· 재고로 가지고 있는 상용 및 표준 컴포넌트 부품의 분배(다양한 공급 소스로 및 창고로부터 부품 제공)
· 기능적 요구사항에 대한 프로세스 적용

등을 들 수 있다. 수많은 시스템에 대하여 공급자가 시스템을 구성하고 있는 수많은 요소(어떠한 경우에는 거의 50%가 넘는다)를 제공하고 있다. 그림 1과 같이 대형 프로젝트의 경우, 형상 품목이나 주요 하부시스템 공급자에게 용역을 제공하는 하나 또는 그 이상의 컴포넌트 공급자로 구성된 공급자 계층구조를 볼 수 있다.

그림 1. 전형적인 공급자 계층구조

최근 들어 경제적인 측면에서 생산자 조직에서 수행하는 것보다 외부전문기관을 활용하거나 아웃소싱하는 경우가 늘어나고 있다. 더구나 글로벌 환경에 힘입어 여러 다른 지역 및 국가의 공급업체를 활용해 가고 있다.
수많은 상이한 공급자를 설계, 개발, 제작 및 지원활동 분야에 적용함에 따라 시스템 엔지니어링 프로세스와 기법의 필요성이 증가하고 있다. 설계 프로세스를 적용하는 공급자는 시스템 개발 초기부터 참여해야 한다.

공급자 기능과 활동을 위해 시스템 엔지니어링 관리계획서(SEMP)가 작성되어야 한다. 시스템규격서(A형)를 기능 베이스라인으로 작성한 다음, 이를 다양한 하위레벨 규격서를 작성하는 데 적용해야 한다. 결국, 주요 공급자는 초기 설계단계부터 하나의 설계팀 요원으로 참여하여 시스템 엔지니어링 프로세스를 적용해야 한다.

여기서는 앞서 논의한 공급자 업무와 활동 및 조직구조와 함께 공급자 선정 및 평가, 공급자 용역 계약, 공급자 조정, 그리고 통제활동을 살펴본다.

1. 공급자 활동사항
시스템 엔지니어링 프로세스는 고객 필요성이 식별된 다음 시스템 운용 요구사항 및 유지보수 개념 정의, 기술 성능 측정요소(TPM) 식별, 기능 분석 및 할당, 그리고 시스템 규격서(A형) 작성단계로 진행된다. 이를 기반으로 공급자를 선정하는 프로세스 단계는 그림 2와 같다.

그림 2에서 보면 먼저 대상시스템이 수행해야 할 기능(WHAT)을 식별한 다음, 이 기능을 평가하고 가장 잘 수행할 수 있는 방법(HOW)을 절충하여 선정한다.

그림 2. 공급자 선정 프로세스

이를 위해 기본적으로 살펴보아야 할 일은 다음과 같다.
식별된 기능의 수행방법을 장비, 소프트웨어, 인적자원, 또는 복합방식 등 어느 것으로 할 것인지를 선정해야 한다. 이와 같이 절충한 결과를 특정 자원 요구사항 형태로 제시하게 된다. 다음 단계는 이러한 자원이 어디에(WHERE) 있는지를 알아내야 한다. 이는 공급원을 알아내는 것이다. 장비설계, 제조, 소프트웨어 패키지 개발, 또는 프로세스 수행이 생산자 자체에서 개발할 것인지 아니면 외부공급 소스에서 수행할 것인지를 결정해야 한다.

대부분의 기업은 대안을 평가하고 더 좋은 방법을 선정하기 위해 별도의 개발/구매방법을 심의하는 획득위원회를 운영하고 있다. 이러한 획득위원회는 프로그램 관리, 엔지니어링, 로지스틱스, 제작, 구매, 품질보증 부서의 대표로 구성된다. 엔지니어링 부서는 시스템 엔지니어링 분야와 설계 엔지니어링 분야로 구성한다. 의사결정을 위해 소요시기, 시스템 복잡도, 기술 및 능력에 대한 내부 또는 외부 가용성, 연관된 사회 및 정치적 요소, 비용 등의 요소를 고려하여 결정한다.

시스템 엔지니어링 관점에서 상대적으로 복잡하고 신규 테크놀로지를 필요로 하며 전체 시스템개발에 치명적인 요소가 있을 경우, 가능하다면 내부에서 자체 개발하는 것이 바람직하다. 이러한 품목일수록 보다 엄격한 통제와 관리가 필요하기 때문에 먼 거리에 위치한 공급자와 함께 일하기가 매우 어렵다.

그림 2에 나타난 바와 같이 공급원을 내부적인 자체개발로 할 것인지 아니면 외부 공급자를 선정할 것인지를 획득위원회에서 추천해야 한다. 결국 수많은 요구사항을 유사한 방법으로 평가한 후 다양한 능력을 가진 여러 공급자를 활용하여 시스템 개발활동을 수행토록 한다. 그림 3과 같이 선정된 시스템의 아웃소싱 후보를 식별하게 된다. 주요 하부시스템 및 하위 레벨 컴포넌트의 설계 및 개발, COTS 상용부품 공급, 자재공급, 프로세스 수행을 위한 용역 제공 등에 관한 공급자로 구성되고 있음을 유의해야 한다.

2. 제안서 제출과 공급자 선정
그림 2의 획득위원회에서 구매로 결정되면 아웃소싱 공급자를 선정하기 위하여 수행해야 할 업무와 세부적인 시스템 규격서를 작성하게 된다. 그림 3에서와 같이 시스템 요소 설계 및 개발 규격서(B형), COTS 구매 규격서(C형), 용역 또는 프로세스 규격서(D형), 자재 획득 규격서(E형)를 준비한다.

규격서를 작성함에 있어서 계층구조로 작성해야 하며, 이는 상위레벨 시스템 규격서(A형)로부터 하위레벨 자재규격서(E형)까지 요구사항을 추적할 수 있어야 한다. 적절한 기술 성능 측정(TPM)요소 설정과 요구사항 할당 프로세스를 통해 모든 시스템 계층구조 요소, 즉 하부시스템 레벨, 형상품목 레벨, 유닛 레벨, 아셈부리 레벨에 대한 양적 및 질적 판단기준을 제시하게 된다. 따라서 이러한 판단기준은 개발, 생산, 프로세스, 자재규격서에 적절하게 제시해야 한다.

이러한 규격서를 완전하게 잘 작성하는 일은 입력과 출력사항, 성능관련 요구사항을 정의하는 데 필요할 뿐만 아니라 기능적인 인터페이스 요구사항을 정의하는 데에도 필요하다. 시스템을 설계하고 개발하는 수많은 프로젝트의 경우, 이와 같은 프로세스가 아닌 개별 컴포넌트를 개발하고 이를 조립하고 이를 하부시스템으로 통합하여 시스템을 생산 공장에서 조립하는 상향식 프로세스로 진행해 오고 있다. 

이러한 경우에 세계 여러 곳에서 공급된 다양한 부품을 생산 공장에서 하부시스템, 제품 및 프로세스를 통합해야 한다. 이는 적절한 통합이 효과적으로 잘 이루질 수 있도록 설계하는 데 그 목적이 있다.

따라서 과거에는 하위 레벨에서의 효율성이 중요하기 때문에 전체적인 시스템 통합과정에서 수많은 문제점을 낳게 된다. 다른 말로 하면 시스템 설계와 개발은 적절한 컴포넌트를 선정하여 이러한 컴포넌트가 제대로 기능할 수 있도록 최종적으로 통합하는 프로세스이다. 따라서 기능적 인터페이스를 분명하게 정의한 완전한 규격서를 준비하는 것이 바람직하다.

이와 같이 좋은 규격서를 준비한 다음, 다음 차례는 업무기술서(SOW)를 작성하고 입찰제안서(RFP)를 개발하며 가능 공급원을 찾아내고 원하는 업무를 수행할 수 있는 공급자를 선정하는 절차를 밟는다.
 
3. 입찰제안서 준비
대안비교 분석결과 구매토록 의사결정이 되면 곧 입찰제안서(RFP)를 마련해야 한다. 이를 작성하는 목적은 가용 공급자가 입찰에 참여할 수 있도록 필요한 데이터 패키지를 개발함에 있다.
일반적으로 RFP는 입찰자의 요청에 따라 계약자가 제품 또는 용역의 요구사항을 제안하는 공식적인 절차를 말한다.

시스템 컴포넌트에 대한 필요성이 식별되고 그 품목을 외부에서 입찰하도록 의사결정이 된 후 계약자가 이러한 요구사항을 보다 세부적으로 분명하게 제시하게 된다. 이러한 요구사항이 데이터 패키지로 기술되고 입찰제안서 부록에 첨부되어 RFP에 참여하는 대상 공급자에게 보내진다. 보내야 할 데이터 패키지를 보다 세밀하게 기술하면 다음과 같다.

· 제품·성능·효과도 특성, 물리적 특성, 로지스틱스 및 품질조항 등을 기술하고 있는 기술 규격서. 이러한 문서는 시스템 특정 요구사항에 따라서 B형, C형, D형, E형 규격서로 맞춤형으로 기술해도 좋다.

· 전반적인 프로그램 목적, 계약자 조직부서 책임 및 인터페이스, WBS, 프로그램 업무, 업무일정, 정책 및 절차 등을 기술하고 있는 약식 관리 계획서. 이러한 정보는 주로 계약자 활동과 연관되어 있지만, 개별 공급자가 이를 이해하고 전체 프로그램에 대한 역할을 수행해야 한다.

· 세부 활동, 업무일정, 제출 품목, 지원 데이터, 공급자가 제공할 보고서 등을 기술한 업무기술서(SOW). 규격서와 관리계획서를 통한 종합정보는 수행해야 할 업무의 요약과 공급자 제안서의 기초로 사용된다.
 
시스템 엔지니어링 목적을 충족시키려면 초기 공급자 선정, 차후 수행활동, 계약자로부터 부과된 업무수행 평가 및 조종통제 역할에 달려있다. 이 프로세스의 입력사항으로 기술 규격서가 모든 시스템 레벨 요구사항으로 제시되고 이를 획득해야 할 공급자 요소에 할당되어야 한다. 하향식 접근방법이 시스템 엔지니어링에서 가장 중요하고 기술 규격서가 가능한 범위까지 시스템 요구사항을 지원해야 한다.

하위레벨 규격서에 미치는 시스템 규격서의 영향 정도는 공급자 획득 품목에 달려있다. 예를 들면, 표준 품목, 상용 품목, COTS 컴포넌트는 상대적으로 단순히 ‘C형’ 규격서에 달려있지만 개발노력이 많은 품목일 경우에는 매우 광범위한 개발규격서 ‘B형’에 달려있다. 그리고 한 단계 아래로 진행하면서 규격서 계층구조를 따라 추적되어야 한다.

하향식 기술 요구사항이 규격서 추적에 의해 관리되지만 관리에 관한 요구사항은 공급자 관리계획서와 업무기술서(SOW)에 의해 부과되어야 한다. 조직부서의 연계성은 하향식으로 확인되어야 하고, 공급자 활동은 계약자에 의해 수행될 활동을 직접적으로 지원해야 한다.

일정이 잘 지켜져야 하며 WBS는 공급자와 계약자 활동 상호간의 관계를 잘 나타내야 한다. 달리 말하면, 계약자로부터 공급자에게 수행업무가 잘 전이되어야 한다. 예정 공급자 활동을 나타내기 위해 계약자에 의해 준비된 RFP 데이터 패키지는 상위 시스템 레벨 요구사항으로부터 최하 레벨 시스템 컴포넌트까지 필요한 연계성을 유지하는데 매우 중요하다.

시스템 엔지니어링 활동의 한 가지 중요한 활동은 시스템 통합이다. RFP를 개발하는 목적 중의 하나는 이러한 통합 활동이 잘 이루어질 수 있도록 하는 데 있다. 흔히 이러한 문서를 너무 조급하게 작성하고 제안서가 작성되며 계약협상이 이루어지는 반면에 필요한 시스템 통합 활동은 상당히 지연되는 경우가 많이 있다. RFP 데이터 패키지는 시스템 규격서 ‘A형’과 SEMP의 연장선에서 이루어져야 한다.

그림 3. 아웃소싱 후보 사례  

4. 공급자 제안서 준비
RFP 데이터 패키지가 준비된 다음 자격 있고 관심 있는 공급자로 하여금 입찰 참여 여부기회를 준다. 참여하기로 결정한 공급자는 제안서 준비팀을 구성하여 제안서 작성준비에 들어간다. 주요 하부시스템처럼 설계 및 개발이 요구되는 경우, 공급자 제안서 작성범위는 보다 광범위하다.

공식적인 프로젝트형 조직을 구성하여 특정 프로젝트 활동이 식별되고 시스템 개발과 유사한 프로젝트 수행노력이 요구된다. 이러한 대형 프로젝트의 경우, 설계 및 개발 요구사항이 있어야 한다. ‘B형’ 개발 규격서를 포함한 RFP의 경우, 주요 시스템 요소 설계가 필요하기 때문에 제안서 작성을 위한 실험시제를 제작해야 하는 경우도 있다. 설계 및 개발활동을 검증하기 위한 미니 프로젝트를 수행하기도 한다. 물리적 모델과 같은 그 결과물을 제안서와 함께 계약자에게 제시하기도 한다.

계약자 또는 고객에게 공급자의 능력과 설계 접근방법에 대한 확신을 줌으로써 보다 빨리 설계를 결정할 수 있다. 만약 그 공급자가 선정된다면 이미 제작된 시제가 다음 세부설계를 수행하는 베이스라인 형상으로 고려될 것이다.
이와 같은 절차를 밟게 되면 하부시스템 요구사항이 RFP의 한 부분으로 수행되고 설계 및 개발활동이 제안서 단계에서 종료되어 공식 설계검토가 계약자 검토 및 공급자 제안서 평가에 의해 수행된다. 

그리고 그 형상이 결정되어 설계변경 관리활동이 시작되기도 한다. 따라서 개발 기간이 단축된다. 이러한 시나리오 때문에 RFP를 잘 준비하는 것은 시스템 엔지니어링 관점에서 매우 중요하다. 나아가 제안서 준비단계에서 수행된 설계활동은 시스템 엔지니어링 목표를 지원하는 설계특성(예, 신뢰성 특성과 유지보수성 특성) 활동으로 고려되어야 한다.

최종적으로 공급자 제안서의 공식적인 평가는 획득될 품목 또는 용역이 시스템 엔지니어링 요구사항과 일치 여부를 마지막으로 검토해야 한다.
 
5. 공급자 평가와 선정
가용 공급자로부터 제안서를 받은 후 계약자는 검토와 평가 프로세스를 밟는다. 만일 경쟁 입찰 관계가 있을 경우, 계약자는 최적 공급자를 선정하기 위한 일반적인 평가절차를 수립한다. 먼저 제출된 제안서가 경쟁자가 제기한 RFP 적합 여부를 검토한다. 만일 불일치 사항이 나타나면 경쟁에서 제외하거나 또는 우선협상 대상자로 선정한 다음, 이 사항을 수정토록 한다.

둘 이상의 공급자가 RFP를 충족시키고 있을 경우, 각 제안서에 대하여 평가 기준을 적용하여 검토한다. 이는 다음 공급자 체크리스트를 사용해도 좋다. 식별된 평가항목은 일반적 평가 기준, 하부시스템 또는 획득 대상 품목의 설계특성, 시스템/품목에 대한 공급자 제안 유지보수 및 지원 인프라 구조와 공급자 품질인증 요소를 포함하고 있다. 이러한 항목은 시스템 전반에 걸친 요구사항 중요도에 따라 가중치를 결정하는 데 도움을 준다.

· 일반기준
· 제품설계 특성
-‌기술성능 인자/기술적용/물리적 특성/효과 요소 : 신뢰성, 유지보수성, 인간공학, 안전 요소, 지원 가능성과 서비스 가능성, 품질 요소
-생산성 요소/폐기 관련 요소/환경 요소/경제 요소
· 제품 유지보수 및 지원 인프라 구조
-‌유지보수 및 지원 요구사항/데이터/문서화/보증조항/고객서비스/경제 요소
· 공급자 품질인증
-‌계획 및 절차/조직 요소/가용 인력 및 자원/설계 접근방법/생산 제조 능력
-‌시험평가 방법/관리 통제/경험 요소/과거 업적/성숙도/경제 요소
 
계약자는 표 1과 같이 항목별로 가중치를 부여한다.

표 1. 제안서 평가 결과표

이는 공급자 품질인증, 제품설계 특성, 제품 유지보수, 지원 인프라 구조 및 일반 판단 기준 순으로 식별되었다. 부록 IV에 나타나 있는 공급자 평가 체크리스트를 고려하여 각 공급자의 제안서를 검토하여 어느 공급자가 각 고려요소를 보다 잘 충족하고 있는지를 반영한다. 표 1의 평가 기준에 나타난 제목은 그 중요도에 따라 점수를 부여하고 등급을 산출한다. E항의 보다 세부적인 고려사항은 표 2에 나타나 있다.

표 2. 공급자 제안서 세부 평가 기준 사례 (표 1의 E항)

개별 요소 점수가 합해지고 가장 높은 총계가 공급자로 선정된다. 이 경우는 공급자 B가 선정된다. 시스템 엔지니어링 관점에서 공급자 제안서를 평가할 때 다음과 같은 질문을 한다. 이는 하부시스템이나 컴포넌트 선정에도 동일하게 적용된다.

· 공급자 제안서는 RFP에 명시된 계약자 요구사항을 잘 반영하고 있는가?
· 공급자 제안서는 ‘A형’ 시스템 규격서에 명시된 시스템 요구사항과 SEMP에 적합하게 제시되어 있는가?
· 제안된 항목에 대하여 성과 특성이 잘 명시되어 있는가? 이러한 항목은 시스템 레벨 요구사항으로부터 측정 및 추적 가능한가?
· 효과도 요소(신뢰성, 유지보수성, 지원 가능성, 가용성 등)가 명시되어 있는가? 이러한 항목은 시스템 레벨 요구사항으로부터 측정과 추적이 가능한가?
· 신규 설계가 필요한 경우, 공급자 조직의 설계 프로세스가 잘 정의되어 있는가? 이 프로세스는 필요 시 CAD/CAM/CALS 기법과 잘 연계되어 있는가? 신뢰성, 유지보수성, 인간공학, 지원 가능성, 수명주기 비용 및 기타 연관된 특성을 설계에 절절하게 반영하고 있는가? 설계변경절차가 개발되어 있으며 설계변경을 통제할 수 있는 형상관리계획이 수립되어 있는가?
· 설계가 도면, 부품목록서, 보고서, 소프트웨어, 테이프, 디스크, 및 데이터베이스 등 적절한 문서로 정의되어 있는가? 필요한 데이터 획득이 가능한가? 데이터 권한이 언급되어 있는가?
· 공급자는 제안된 컴포넌트에 대하여 시험평가 요구사항을 제시하고 있는가? 과거에 수행된 시험이라면 시험결과가 문서화 되어 있으며 볼 수 있는가? 그리고 미래 시험계획은 시험평가종합계획(TEMP)에 적절하게 통합되어 있는가?
· 유지보수 자원 요구사항, 예비/수리 부품, 시험지원장비, 소요인력 및 기술레벨, 교육훈련, 설비, 데이터, 유지보수 소프트웨어 등 수명주기 지원 요구사항을 식별하여 제안하고 있는가? 이러한 요구사항이 설계를 통해 최소화될 수 있도록 제안하고 있는가?
· 설계형상이 지속적으로 성장 가능하도록 반영하고 있는가?
· 공급자는 생산/건설계획을 제시하고 있는가? 특성에 따라 주요 제조 프로세스가 식별되어 있는가?
· 공급자는 품질보증 프로그램을 제시하고 있는가? 통계적 품질관리 기법을 적용하는가? 공급자는 하자 품목에 대한 재 보수 계획을 가지고 있는가?
· 공급자 제안서에 다양한 관리 계획을 포함하고 있는가? 그 계획은 프로그램 활동, 조직구조 및 책임, WBS, 활동 일정계획, 프로그램 모니터링 및 통제절차 등을 포함하고 있는가? 시스템 엔지니어링 활동 책임이 부여되어 있는가?
· 공급자 제안서는 획득비용, 운용 및 지원비용, 수명주기 비용 등 전체적인 비용을 제시하고 있는가?
· 공급자는 제안된 제품과 유사한 설계, 개발 및 생산 경험을 가지고 잇는가? 이러한 경험을 통해 계획된 일정 및 비용으로 고품질 제품으로 개발할 수 있다고 보는가?
 
이러한 질문은 공급자 제안서를 평가하는 데 도움주지만, 특정 획득방법을 추천하기 전에 다음 몇 가지 사항을 추가적으로 고려하는 것이 바람직하다.

단독입찰 공급자인지 아니면 RFP를 충족하는 둘 또는 그 이상의 공급자가 있는가? 상대적으로 시스템 요소가 크고 부분적인 설계 및 개발활동이 필요한 프로젝트의 경우 이를 둘 이상의 공급자가 개발하게 되면 비용이 많이 들게 된다. 반면에 소규모 표준 상용 컴포넌트의 경우 여러 공급원이 있을 수 있다. 하나의 공급원이 없어졌을 때 필요성을 충족시키는 공급원을 확보하는 일이 중요하다.

생산 전후, 전 수명주기 동안 필요한 지원을 공급자가 수행할 수 있는가? 특히 중요한 사항으로써 초기 생산이 끝난 다음 유지보수 요구사항을 충족시킬 수 있도록 예비/수리부품 소스 지원이 가능해야 한다. 만약 지원이 어렵다면, 충분한 예비/수리부품을 미리 생산단계에서 확보해야 한다.

공급자가 정치적, 사회적 및 경제적 요인에 의해 선정해야 하는가? 특히 글로벌 환경에서 특정 국가로부터 컴포넌트 또는 서비스를 획득하는 정치적 압력이 있을 수 있다. 반면에 지형적 위치와 경제적 요인에 의해 미래지향적으로 공급자를 선정할 수도 있다. 경우에 따라 전체의 X%의 물량을 하청 계약할 수도 있다. 어떠한 경우든 정치적, 사회적, 경제적 요인을 고려한다.
 
공급자 제안서 평가는 표 1을 기반으로 여러 가지 추가적인 요소를 고려해서 판단해야 한다. 즉, 단독 또는 다수 공급원, 생산 이후 지원 가능성, 공급자 선정 시 정치, 경제, 사회적 요인 등이다. 이러한 평가활동은 작성된 제안서를 검토할 뿐만 아니라 때에 따라 현장이나 공급자 설비 방문 실사를 통해 이루어지기도 한다. 추천이 되고 계약자와 공급자 간에 계약협상이 시작된다.

공급자 평가와 선정 결과는 프로그램 성패에 지대한 영향을 주기 때문에 시스템 엔지니어링 부서에서 이에 대한 프로세스를 수립하는 것이 바람직하다. 공급자 활동을 전체적인 엔지니어링 설계와 개발에 적절하게 통합하고 협력하는 활동이 필수적이다.