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

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

등을 들 수 있다. 수많은 시스템에 대하여 공급자가 시스템을 구성하고 있는 수많은 요소(어떠한 경우에는 거의 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을 기반으로 여러 가지 추가적인 요소를 고려해서 판단해야 한다. 즉, 단독 또는 다수 공급원, 생산 이후 지원 가능성, 공급자 선정 시 정치, 경제, 사회적 요인 등이다. 이러한 평가활동은 작성된 제안서를 검토할 뿐만 아니라 때에 따라 현장이나 공급자 설비 방문 실사를 통해 이루어지기도 한다. 추천이 되고 계약자와 공급자 간에 계약협상이 시작된다.
공급자 평가와 선정 결과는 프로그램 성패에 지대한 영향을 주기 때문에 시스템 엔지니어링 부서에서 이에 대한 프로세스를 수립하는 것이 바람직하다. 공급자 활동을 전체적인 엔지니어링 설계와 개발에 적절하게 통합하고 협력하는 활동이 필수적이다.

공급자 계약관리
 
공급자 평가 및 선정과정을 통해 추천되고 나면 공급자와 공식계약을 성사시키기 위한 매우 세부적인 계약자 활동이 시작된다. RFP가 제시되었고 공급자 제안서를 평가했다. 이제 계약 형태를 설정해야 할 시기다.
협상된 계약형태는 공급자 업무수행에 매우 큰 영향을 끼친다. 특히 설계 및 개발활동을 포함한 대형 시스템 컴포넌트 획득 시 더욱 그러하다. 계약협상의 목적은 기술 요구사항 관점, 산출물, 가격, 계약형태, 지급계획 등 가장 유리한 계약을 달성함에 있다. 분명히 계약자와 예정공급자 간에 각각 가용한 대안과 위험을 고려하여 입장을 정리하게 된다.
하나의 극단적인 계약형태는 프로그램 위험이 일차적으로 공급자에게 부여된 확정 고정가격(FFP) 계약형태이다. 다른 극단적 계약형태는 계약자가 모든 위험을 책임지는 비용 추가고정비(CPFF) 계약형태이다. 이 두 가지 극단적인 계약 사이에 수많은 계약형태가 있다. 계약형태 협상은 공급자 성과에 많은 영향을 주기 때문에 매우 중요하다. 또는 주어진 기간에 주어진 요구사항을 충족시키기 위한 시스템을 개발과 생산해야 하는 계약자 활동에 영향을 준다.
대형 하부시스템을 개발할 공급자 성과는 시스템 엔지니어링 목적을 성공적으로 달성하는 데 치명적이다. 나아가 협상된 계약형태에 따른 위험은 SEMP에 기술된 위험관리계획 수립에 영향을 준다. 이를 염두에 두고 시스템 엔지니어는 계약형태 협상뿐만 아니라 협상 프로세스에 영향을 주고 있기 때문에 계약을 잘 이해해야 한다. 고정가격 계약은 대부분의 위험을 공급자가 지기 때문에 까다롭게 통제해야 한다. 엔지니어링 설계가 매우 잘 정의되어야 한다. 만약 변경이 발생하면 이는 매우 비싼 대가를 지급해야 한다.
한편 비용을 추가하는 CPFF나 CPIF 계약은 초기 계약협상 후 변경 발생에 융통성이 있다. 그리고 대부분 위험이 계약자에게 있다. 어느 경우든지 시스템 엔지니어는 다양한 계약형태에 따라 무엇을 할 수 있고 무엇을 할 수 없는지를 구분하고 설계정의 범위를 분명하게 해야 한다.
추가적으로 시스템 엔지니어는 계약협상에 이르는 초기 RFP 준비과정(개발규격 준비, 관리 계획, SOW 등)에 기술 및 비용추정 관점에서 참여해야 한다. 실제 협상이 시작되면 다시 한 번 규격서와 업무수행 기술요소에 관여해야 한다. 협상 프로세스를 통해 업무 범위가 변경될 수 있고 이를 다른 시스템 설계 및 개발에 미치는 영향을 검토한다. 보다 구체적인 이해를 돕기 위해 몇 가지 주요 계약형태를 다음과 같이 요약해서 제시한다.

· 확정(FFP)계약 : 계약자에 의해 공급자 제품이 수락될 때 계약된 금액을 지불하는 법적 동의를 말한다. 계약 이후 공급자의 실제비용이 추가되어도 가격조정이 되지 않는 계약형태이다. 약정된 가격에서 공급자는 모든 재정상의 위험을 감당해야 한다. 이윤은 초기 추정비용, 협상 및 비용통제 능력에 달려 있다. 이러한 계약형태를 적용할 때는 주어진 컴포넌트 설계가 적절한 규격에 의해 매우 잘 설정되어 있는 경우이다.
· 확정상승(Fixed-price-with-escalation)계약 : FFP와 유사한 계약인데 어쩔 수 없는 가격 인상 또는 하락이 발생할 경우 이를 추가해 주는 상승조항을 삽입한 계약형태이다. 이러한 상승 정도를 추정함에 있어서 불확실성이 있을 경우, 상승 한도를 공급자와 함께 설정하고 그 한도까지 계약자가 서로 분할하는 계약형태이다. 설정된 한도 이상의 예기치 못한 비용은 공급자 부담이다.
· 확정인센티브(Fixed-price-incentive)계약 : 불확실한 비용이 있는데 공급자관리와 공급자에게 어느 정도의 인센티브를 제공함으로써 비용감소가 이루어 질 수 있는 경우이다. 목표비용, 최소비용 및 가격한도를 이윤조정 공식에 따라 협상토록 한다. 초기 목표이윤으로부터 이윤조정은 전반적인 비용 성과에 기초하여 이루어진다.
· 확정추가 보상비용(CPFF)계약 : 공급자가 프로젝트와 연관해서 모든 정당한 비용에 대한 상환이 필요한 경우, 비용을 보상하는 계약이다. 예를 들면 추정비용의 10%와 같이 협상 고정 수수료가 업무종결 시 공급자에게 지불한다. 이러한 수수료가 총비용의 일정비율로 결정되어 있을지라도 업무범위와 계약내용이 변경되면 그 비율을 조정할 수 있다. 이는 공급자 측에서 초기 계약 범위를 넘어 요청된 엔지니어링 변경 제안을 계약자가 흔쾌히 수락할 때 적용할 수 있다.
· 확정 추가 인센티브비용(CPIF)계약 : 프로그램에 불확실성이 존재할 경우에 적용하는 계약이다. 불확실한 요소의 달성 결과에 따라 추가된 인센티브와 함께 정당한 비용이 공급자에게 지불된다. 협상 시점에서 일정에 따른 특정 성과측정 개별요소를 식별하여 인센티브 지불방법을 결정한다. 구체적인 협상 내용은 목표비용, 목표 수수료, 최소 및 최고 수수료, 수수료 산정공식 등이다. 계약종료 시 공급자가 달성한 성과가 수수료 지불결정의 기초가 된다. 이러한 계약형태의 적용은 시스템 TPM요소를 획득 항목으로 고려할 경우, 이에 대한 협상을 포함한다.
· 비용 분담(Cost sharing)계약 : 주로 교육기관 및 비영리 기관에 의해 수행되는 연구개발 사업에 적용된다. 이러한 활동은 상호간에 스폰서가 되고 공급자에 대한 배상은 기 결정된 분담계획에 따라 이루어진다. 한편 공급자가 특허, 기술 노하우, 우수 논문 등 기타 이득을 초래할 경우 지불되는 수수료는 없다.
· 시간 및 자재(Time and Material)계약 : 지정된 업무를 달성하기 위하여 실제로 지출된 자재와 서비스에 대한 지불계약이다. 이러한 계약은 업무수행 기간과 범위가 미리 결정할 수 없거나 비용이 추정될 수 없을 때 적용한다. 이러한 사례는 하부계약으로 수행된 연구개발 활동, 유지보수 수리 및 분해검사 서비스 등이다.
· 업무 동의서(Letter Agreement) : 일종의 공급자가 즉시 프로젝트를 수행해야 할 때 이를 시작할 수 있도록 동의를 해 주는 예비계약문서이다. 이러한 문서는 식별된 요청에 빠른 응답을 제공하는 중간수단이다. 협상 후 확정계약을 수행하려면 그 시기를 놓치게 된다. 업무 동의서는 전체적인 가격정보를 포함하고 있지 않지만 과도한 지출을 예방하기 위하여 최고 한도를 설정한다. 이러한 동의문서의 경우, 업무수행을 위해 지출된 모든 경비를 계약자가 배상해야 한다.
 
그림 4는 시스템 설계검토, 주요장비/소프트웨어 설계검토, 최종 설계검토 등 공식 검토시기에 맞추어 성공적인 업무수행 정도에 따라 비용 지불일정을 나타내고 있다.

그림 4. 계약 지불 일정계획 사례

이러한 계약형태와 연관하여 주요사항은 지불일정이다. 언제 공급자에게 성공적인 계약활동 결과에 대한 배상이 이루어 질 것인가? 그리고 예상 지불 금액은 얼마인가? 인센티브 계약의 경우, 어떠한 인센티브/벌과금 계획을 적용하는가? 이러한 사항들은 특히 대형 프로젝트의 경우 매우 중요하다. 왜냐 하면, 계약자는 특정 예산 사이클에 달려 있고 공급자는 너무 많은 부채가 발생하기 전에 운용비용을 정산해야 하기 때문이다. 따라서 지불 일정계획이 미리 수립되어야 한다. 이러한 특정 설계검토는 공급자 활동과 이를 지불계획과 연계시킴으로써 공급자로 하여금 계약이행을 성공시키기 위한 동기를 부여한다.
만일 인센티브 계약일 경우, 인센티브/벌과금 계획이 지불 일정계획과 함께 수립되어야 한다. 이는 프로젝트 일정과 주어진 시스템 성과 효과에 따라 인센티브와 벌과금에 대한 계획이 수립된다. 앞서 시스템 레벨에서 주어진 TPM이 하부시스템에 할당되거나 공급자 품목에 할당된다. 획득품목에 적용되는 성과측정은 공급자 인센티브/벌과금 계획수립요소로 고려되어도 좋다.
인센티브/벌과금 지불계획을 수립함에 있어서 이는 인센티브 또는 벌과금을 적용해야 하는지를 식별해야 한다. 많은 경우 하나이상의 인자가 다중으로 고려된다. 각 인센티브의 단순합산으로 이를 결정하기가 어렵다. 이는 컴포넌트의 형태와 인센티브가 적용되는 항목의 중요도에 따라 다르다. 선정된 모든 인센티브 인자의 중요도가 다르기 때문에 각 인자에 대한 ‘중요가치’ 또는 ‘가중치’와 인센티브/벌과금 가치 정도를 추정하는 것이 중요하다. 두 가지 컴포넌트 특성을 포함하고 있는 다중 접근방법 사례가 그림 5에 나타나 있다.

그림 5. 다중 인센티브 및 벌과금 계획 사례

목표 가치는 규격서 요구사항에 기초하여 설정된다.
이는 또한 ‘계약 가치’로 고려해도 좋다. 시험평가 이후 만약 목표가치보다 실제 가치가 향상되고 있다면 인센티브 수수료가 공급자에게 그림 5에 나타난 지정된 시기에 지불된다.
보다 구체적으로 측정된 MTBF가 그림 5의 약 238시간 상한 유의수준을 넘게 되면 주어진 수수료는 계약자에게 20%, 공급자에게 80%로 나누어진다. 역으로 MTBF가 목표보다 떨어지면 지정된 벌과금의 50%를 공급자가 지불해야 한다. 이와 같이 주요 인자에 대한 계약된 인센티브/벌과금이 부과된다.
다양한 계약형태가 있기 때문에 특정 획득활동에 적합한 계약구조를 적용토록 노력해야 한다. 만일 설계 및 개발활동이 공급자에게 주어지는 경우, 고정수수료 추가비용(CPFF)계약이나 인센티브 추가비용(CPIF)계약을 활용하는 것이 바람직하다. 융통성을 고려할 때 계약자는 공급자가 원하는 시기에 업무를 종료할 수 있도록 보다 까다로운 모니터링과 통제를 해야 한다. 동시에 계약자는 공급자에게 영향을 줄 수 있는 설계변경을 될 수 있는 한 배제해야 한다. 만일 계약자가 공급자 품목에 향상을 제시하거나 업무방향을 변경하게 되면 공급자는 당연히 업무범위에 따른 계약변경을 요청하게 된다.
한편 공급자가 계약 초기에 가격을 줄이기 위해 ‘최소 활동’으로 제안서를 제출하여 낙찰 받았다고 해 보라. 공급자는 동시에 초기 제안서에 포함된 항목을 이후에 추가하거나 변경토록 계획하게 된다. 이러한 변경활동은 개별 엔지니어링 변경제안서(ECP)로 수행되고 궁극적으로 비용이 올라간다. 이러한 상황에서 시스템 엔지니어는 일반적인 계약방법에 익숙해야 할 뿐만 아니라 제안된 항목, 기술적 접근방안 및 시스템 계층통합방안, 다양한 인터페이스 및 지원 요구사항을 철저하게 숙지해야 한다. 다른 경우로써 추가적인 설계활동이 없거나 잘 정의된 컴포넌트를 획득할 경우를 생각해 보라. 이러한 경우, 확정고정비용(FFP)계약이 적용된다.
한편, 유지보수 및 수리활동과 같은 서비스 성과를 달성하려면 기본적으로 시간과 자재(time and material)계약형태가 유용하다. 최종 계약 항목과 조건(term and condition)을 달성하려면 계약자와 공급자 간 공식협상을 통해 이루어진다.
최종 협상은 일반적으로 요구사항을 토의하기 위하여 주어진 일자에 각 사이드에서 여러 대표자가 함께 모여 보다 단순하게 절충한다. 그러나 상대적으로 큰 하부시스템이나 주요 시스템 컴포넌트일 경우 계약협상절차는 더욱 복잡하다. 보다 공식적인 협상테이블에서 계약자는 공급자 제안서의 기술접근방법, 관리방법 및 가격을 확인하기 위해 공급자에게 질문한다.
기술계통 질문을 통해 제안된 공급자 기술접근 방법이 최선책(설계절충연구결과 참조)인지를 확인한다. 그리고 제안된 품목을 개발 및 생산하기 위하여 경험과 필요한 기술자가 충분한지를 검토한다. 비용에 관해 공급자가 제안한 가격이 공정하고 타당한지를 검토하고 논리적인 비용분석이 이루어졌는지를 확인한다. 공급자 입장에서 초기 협상은 계약자에게 제출한 제안서를 토대로 공급자의 방어 자세에 놓여 있게 된다.
공급자는 계약자에게 철저하고 정직하며 최선의 제안서임을 입증하기 위한 관련문서를 최대한 제시한다. 협상은 일반적으로 양쪽에 전략을 세우고 요청하는 하나의 기술이다. 초기에 협상 위치를 파악하고 회의 일정과 회의 내용을 식별하여 계획을 수립한다. 계약자와 공급자는 서로 누가 협상 장소에 참여할 것인지를 식별한다. 기술 및 행정요원을 포함하여 시스템 엔지니어는 시스템 관련 요구사항에 대한 토의자료를 제시한다. 충돌이 발생하면 짧은 전략회의를 통해 조정하고 상대방의 양해를 구한 다음 최종 협의를 통해 상호동의가 이루어지도록 한다.
이러한 프로세스는 여러 번 반복된다. 때에 따라 많은 시간이 소요된다. 그러나 최종 목표는 계약자와 공급자 간 최종 계약 사인이 이루어지는 것이다.

1. 공급자 모니터링 및 통제
공급자 식별, 승인 및 공식계약과 함께 계약자는 프로그램 협조, 평가, 통제 활동을 수행한다. 이러한 활동이 필요한 이유는 다음과 같다.

· 주어진 시스템에 대하여 공급자 활동량과 제품 및 컴포넌트 수가 광범위하다. 어떠한 경우에는 계획된 개발 및 생산 활동의 50~70%가 공급자 수행활동이다.
· 시스템 획득에 참여하고 있는 공급자가 많을 뿐만 아니라 공급자의 지역적인 분포가 범세계적이다. 수많은 시스템이 환태평양, 유럽, 아프리카, 캐나다, 멕시코, 남아메리카 등 여러 곳에서 만든 컴포넌트를 사용한다. 따라서 시스템 획득 요구사항이 실로 국제적인 커뮤니케이션과 분배 네트워크가 필요하다.
· 상대적으로 대형 시스템 획득 시 상이한 컴포넌트 공급자가 있을 뿐만 아니라 다양한 활동이 필요한 시기에 다른 지점에서 광범위하게 수행된다. 어떤 공급자는 설계 및 개발활동을 수행하고 또 다른 공급자는 제조 및 생산 활동을 하며 또한 일상적인 구매활동을 통해 일반 상용 표준제품을 공급하는 사람도 있다. 시기적으로 단절되거나 연속성이 없는 경우도 있고 장기간 연속성을 유지해야 하는 경우도 있다. 그림 6에 이러한 공급자 프로젝트 활동 사례를 보여주고 있다.

그림 6. 공급자 프로젝트 활동 사례

다양한 공급자와 다양한 지역에서 서로 상이한 기능을 수행하는 환경에서 계약자는 엄청난 도전적인 업무를 수행해야 한다. 공급자의 특정 요구사항이 조심스럽게 개발되어야 하고 초기부터 분명하게 제시되어야 한다. 그리고 그 요구사항이 충족될 수 있는 적절한 계약구조가 형성되어야 한다. 물론 계약형태가 공급자 활동에 알맞게 맞춤화해야 한다. 그림 6에서 공급자 A, C, D, F, G는 부분적인 설계 및 개발활동을 포함한 프로젝트에 참여한다. 이러한 프로젝트는 절충 분석이 수행되고 신뢰성 및 유지보수성 예측 보고서가 준비되며 설계검토 일정이 수립되고 시험평가 기능 등이 수행된다.
앞서 논의된 시스템 엔지니어링 프로세스의 수많은 활동이 공급자 프로그램에 따라 줄어든다. 공급자 프로그램 평가 및 통제에 관하여 계약자는 전반적인 설계검토 프로세스에 공급자 활동을 접목해야 한다. 대형 설계와 개발 프로그램의 경우, 이러한 설계검토가 공급자 설비에서 수행된다. 그 결과는 더 상위레벨 계약자 검토사항에 반영된다. 소형 프로그램의 경우, 검토 프로세스는 검토 프로세스는 공식적인 활동이 아니라 시스템의 더 큰 요소에 통합하여 평가된다.
제조 및 생산 컴포넌트일 경우, 계약자의 주 활동은 검사와 품질관리활동이다. 또한, 상용표준제품도 반드시 통제해야 한다. 결국, 공급자 평가와 통제는 고객에 의해 수행되거나 계약자에게 부과된 프로그램 검토 및 통제활동의 연장선에서 이루어진다. 계약자는 차례로 공급자에게 적합한 요구사항을 부과해야 한다. 여러 하부 공급자를 지니고 있는 대형 공급자는 이들을 통제해야 한다. 이러한 목적은 (1) 시스템 레벨 요구사항이 하향식으로 적절하게 할당되어 있는지를 확인, (2) 이러한 요구사항에 알맞게 상향식으로 통합되는지를 확인한다. 공급자 활동과 연계된 필요한 절차와 기술검토 등을 포함한 SEMP가 준비되어야 한다.
 
시스템 통합
 
시스템 엔지니어링 개념에 포함된 내용 중 하나가 통합 기능이다. 초기 개념설계 단계에서의 주요활동은 시스템 요구사항을 정의하고 시스템 규격서 ‘A형’과 SEMP를 개발하면서 요구사항을 통합한다. 그다음 예비시스템 설계단계에서 필요한 통합이 계속된다. 기술적 관점에서 하부시스템, 유닛, 어셈블리, 모듈, 소프트웨어, 데이터, 설비, 시험지원 장비, 인력, 기타 요소들의 적절한 인터페이스로 통합된다. 소프트웨어는 하드웨어와 통합하고 시험지원 장비는 주 장비에 통합되며 인력은 장비 및 소프트웨어와 통합된다. 다양한 설계활동과 기타 프로그램 활동이 적절하게 통합될 수 있도록 관리를 해야 한다.
최종적으로 고객 필요성에 부합된 시스템을 얻기 위해 다양한 시스템 컴포넌트를 복합하는 주요 통합기능이 수행된다. 설계 초기 단계에서 주로 하향적 원칙이 강조되었다. 시스템 요구사항이 정의되고 기능 분석이 수행되며 상위 시스템 레벨 요구사항이 설계지침에 알맞게 필요한 범위까지 하향적으로 할당된다. 설계가 진행됨에 따라 절충 분석이 수행되고 시스템 컴포넌트가 선정된다. 설계조합을 통해 설계 개념이 검증되고 컴포넌트가 시스템의 요소를 복합해 간다. 이 단계에서 그림 7과 같이 상향적 활동으로 이전되어 간다. 최저 레벨의 컴포넌트가 식별되고 하부 어셈블리로 통합되며 하부 어셈블리는 어셈블리로, 어셈블리는 유닛으로 통합되어 간다.

그림 7. 시스템 통합(상향적 접근방법)

그림 7에서 통합 목적은 컴포넌트 1, 2, 3, …… 및 8이 각각 독립적이지만 공차와 상호운용성의 요구사항에 맞추어 하부 어셈블리 G로 통합된다. 이러한 목표는 뚜렷하지만, 그 결과를 얻기란 그리 쉽지 않다. 역사적으로 시스템은 상위 구조를 정의하지 않고 상향적으로 통합해 왔다. 대부분 시행착오를 통해 통합 프로세스가 적용됐다.
컴포넌트 통합은 그리 쉽지 않다. 컴포넌트의 대체가 어느 시기에 일어날 뿐만 아니라 이에 따른 낭비와 비용증가가 초래됐다. 이러한 과거 시스템 통합 및 시험의 경험 때문에 초기에 하향적 시스템엔지니어링 방법을 적용하는 것이 필수적이다. 시스템 설계에 초기 요구사항 정의와 할당을 통해 과거에 경험해 온 수많은 문제점이 미래에 해결될 것이다. 잠재된 문제를 초기에 식별하고 이를 제거함에 따라 시스템 통합 프로세스는 매우 쉽게 잘 진행될 것이다. 모든 문제점을 시스템 통합 및 시험에서 해결하는 것 대신 시스템설계의 상향적 방법이 초기 하향적 프로세스에 의해 설정된 요구사항을 따라가면 된다.
초기 단계의 시스템 통합에 대한 적절한 고려 없이 수행하게 되면 과거 최종 통합 및 시험활동에 연관된 문제점은 지속적으로 나타나게 될 것이다. 이를 염두에 두고 전반적인 시스템 통합 및 시험계획이 수립되고 SEMP에 포함되어야 한다. 이를 수립하는 목적은 그림 7에 나타난 상향적으로 시스템 컴포넌트 통합에 연관된 업무 흐름 프로세스와 활동을 기술함에 있다.
이러한 활동은 설계 및 개발단계 전반에 일어나며 컴퓨터 응용 설계 방법을 활용한 시뮬레이션 기법을 사용하여 컴포넌트 통합을 수행한다. 컴포넌트가 식별되고 선정됨에 따라 이를 시스템으로 통합하고 시스템 시험평가 활동을 통해 최종적으로 검증된다. 시스템 통합 흐름 프로세스는 그림 8에 나타나 있다.

그림 8. 시스템 통합 및 시험

설계 초기에 컴포넌트가 식별되고 상위레벨 시스템 요소로 복합되고 통합된다. 그리고 최종시스템 시험 및 평가활동이 시험평가종합계획(TEMP)에 따라 수행된다. 이러한 통합 활동은 일련의 컴포넌트 시험과 개별평가 및 분석방법에 의해 왼쪽에서 오른쪽으로 단계적으로 수행된다. 이러한 통합 활동의 목적은 모든 컴포넌트가 요구사항에 잘 대응되어 있는지, 다음 상위 단계로 적합한지, 상호 호환성이 있는지, 그리고 원하는 대로 기능을 수행하고 있는지를 확인하는 데 있다.
요약하면, 시스템 엔지니어링 수행부서는 완전한 시스템 통합 활동이 미리 계획되어 있으며 다양한 통합 활동이 전반적인 시스템 설계 및 개발활동을 통해 수행되었는지를 확인함에 있다. 컴포넌트를 납품하고 이를 시스템에 통합하는 등의 공급자 활동이 계약자 시스템 통합 및 시험계획에 포함되어 있어야 한다.

 

원칙

요약해서 앞서 논의된 내용은 실무 개발과 연관된 원칙을 설정하기 위한 기본지침을 제공해 주고 있다.

· 원칙 1 : 시스템 설계는 개체 요구사항을 충족시키기 위하여 재사용, COTS, NDI 또는 AFE 컴포넌트를 식별하기 위해 모든 실무 노력을 수행한 후 최종적인 옵션이어야 한다.

· 원칙 2 : COTS/NDI 품목을 조달할 때, 철저한 개발 및 수명주기 비용과 지원 사항을 조사하고 이해를 해야 한다. 그렇지 않으면 큰 문제를 일으키게 된다.
 

요약

일반적으로 COTS/NDI 솔루션은 당신과 당신 애플리케이션에 알맞아야 한다. 다른 경우에 그들은 적합하지 않을 수도 있다. 선정절차를 선도하는 시스템 엔지니어로서 다음과 같은 내용에 근거하여 의사를 결정해야 한다.

· 사실
· 요구사항 충족, 개발, 수명주기 비용 최소화, 수용 가능한 레벨까지 리스크 감소 상호간의 절충
· 다른 사용자의 애플리케이션 경험

COTS 제품은 개발 및 수명주기 비용을 감소시키는 매우 강력한 도구일 수 있다. 잘못하면 큰 문제를 일으킬 수도 있다. COTS를 고려할 때 가장 좋은 길은 유사분석을 수행하는 것이다.
당신이 이해하고 있는 가상 이미지를 그 제품이 충족되고 있다고 생각할 때 당신이 모든 것을 발견하고 있는지를 분명하게 하라. 그 어떠한 결정을 하더라도 당신은 당신의 조치와 그 결과에 대한 책임을 져야 한다. 컴포넌트 선정과 벤더를 조심스럽게 그리고 철저하게 을 연구하라. 그리고 위기계획을 수립한 다음 지혜롭게 선택하도록 하라. 최소 라인은 항상 구매자로서의 책임을 다해야 한다는 것이다.

민성기  시스템체계공학원장(sungkmin0@gmail.com)