[SI 프로젝트 전문가로 가는 길] C2. SI 프로젝트의 영업이야기

[David Jeong]

2. SI 프로젝트의 영업이야기

   - SI 프로젝트의 최초 시작

   - 제안서 작성 과정을 통해 많은 개발자들이 참여하고 있는 업무

   - SI 영업활동과 제안서 작성, 제안 심사 및 계약 등 프로젝트 착수 이전까지의 내용

2.1 프로젝트의 영업 환경

   - 영업은 수익을 추구하는 모든 회사의 핵심 역량

   - 기업 경영의 궁극적인 목표인 수익 달성은 영업의 역량에 달려 있기 때문

   - 고객의 확보를 위한 경쟁은 필수적

   - SI 사업 분야는 IT 분야의 기술 경쟁과 영업 경쟁이 가장 치열한 사업분야

      • 중대형 SI 프로젝트의 대부분은 경쟁입찰에 의해 사업자를 선정

      • 발주자의 요구사항을 담고 있는 RFP의 내용은 독점적인 사업자의 선정을 가능하게 하는 요소를 철저히 배제

      • 전체 사업의 수행 금액도 많은 비율이 저가 입찰의 논리를 따르고 있어 경쟁자들보다 낮은가격을 제시한 업체에게 최종

        사업권이 돌아가는 경우가 일반적
      • SI 프로젝트 입찰에서의 사업자 선정은 기술평가와 가격평가라는 두가지 기준으로 심사를 진행

         → 기술심사의 경우 기술심사 항목 및 평가기준이 대부분 입찰 참여자에게 공개되나 심사 기준들이 원칙적인 내용과 주

            관적인 내용을 담고 있을 뿐 심사 결과에 대한 세부 평가 결과는 공개하지 않아 결과에 대한 객관성 확보 어려움

         → 가격평가의 경우 수치화하여 평가하나 무조건적인 최저가 수주는 향후 사업 수행 시 부실 및 부정의 소지가 되며 전

             체적인 사업의 수익률을 저하시키는 근원이 되므로 무조건 낮은 금액을 제시할 수도 없다.

   - 민간 기업의 경우 그룹에 속해 있는 국내의 주요 대기업 군은 그룹 계열사 중에 SI 기업을 하나씩 보유하고 있는 경우가 대

      부분

      • 그룹내의 여러 기업에서 발주하는 SI 프로젝트는 우선적으로 그룹의 계열사인 특정 SI 업체가 수주하는 것이 일반적

      • 전체 시장에서 국내 주요 대기업의 SI 프로젝트는 경쟁 입찰이 아닌 수의계약 형태로 SI 계열사에 발주

         → 중소 SI 업체의 시장 축소와 경쟁력 상실을 의미

         → 대형 민간 프로젝트의 비용 상승으로 이어지게 되는 것

      • 공공 부문에서의 수주 경쟁으로 인한 수익성의 악화를 계열사 프로젝트 수주를 통해 어느 정보 보전할 수 있으며 안정

        된 지원 환경에서 새로운 정보시스템 패러다임을 적용해 볼 수 있고 계열사의 정보화를 일관되게 추진할 수 있는 장점

         → 대기업 SI 프로젝트의 내부 거래형식 프로젝트 수행은 중소 SI 전문 기업이 대형 SI 기업의 하청 업체 또는 협력 업체

             로 밖에 생존할 수 없도록 만드는 원인

         → 대형 SI 기업의 대외 경쟁력을 약화시키는 원인

   - 최근 국내에서는 국가 경제 발전과 국내 IT 산업의 발전을 위해 SI 사업의 해외 진출이 적극적으로 필요함을 느끼고 있다.       • 그룹 계열사라는 보호 울타리 내에서 프로젝트를 수행한 경험을 가진 우리나라의 주요 SI 기업은 해외의 치열한 수주 경

       쟁에서 IT 근본 기술력의 부족, 대외 영업력의 미흡, 해외 레퍼런스 사이트의 부족 등으로 고전

     • 국내의 SI 시장 규모만해도 2003년 6조원이 넘는 시장을 형성할것이라는 예측이 말해주듯 매우 큰 규모

     • SI 시장은 연 평균 10%이상의 성장률을 보일 것으로 예측

     • 최근 해외 SI 사업의 수주가 종종성공하고 있어 전체적인 SI 시장은 지속적인 성장이 예상
   - SI 프로젝트의 영업 시장은 전 산업 영역에 걸쳐 포함되지 않는 산업 분야가 거의 없다.

     • 영역을 구분하면 공공영역, 금융영역, 제조업을 중심으로 산업설비자동화 및 생산 설비 정보화를 위한 제조영역, 물류와

        지능형 교통시스템 등의 서비스 영역 등

   - SI 프로젝트 사업 영역 중 가장 큰 공공 SI 프로젝트 영역

      • 제조 및 서비스, 금융 분야 등의 민간기업 분야는 대기업의 경우 그룹의 계열사 형태인 경우가 많아 사실상 자유로운 영

        업 경쟁이 이루어 질 수 없는 사례가 많기 때문

      • 공공영역은 국가의 정보화 및 사회 간접 자본 성격의 시스템 구축 등 규모 면에서 민간기업의 정보화를 훨씬 능가하는

        초대형 프로젝트인 경우가 많다.

      • 영업 환경도 특정한 SI 기업에 유리하지 않은 비교적 공정한 환경에서 영업이 이루어지기 때문에 종합 SI 기업, 계열사

        SI사업의 수주를 제외하고 외부에서 수행할 수 있는 대형 SI 프로젝트를 원하는 대형 SI 기업에게는 가장 치열한 영업전

        을 펼쳐야 하는 대상

      • 공공 SI 프로젝트에서 대형 프로젝트 사례로 꼽을 수 있는 것으로서 전자정부 프로젝트의 일환으로 추진된 여러 행정 정

        보화 사업과 국방의 현대화를 위해 수행되었던 국방 자동화 프로젝트, 전국에 걸친 교통 흐름의 첨단화를 위한

         ITS(intelligent trafficsystems) 등 기업 내부 업무의 정보화와는 비교할 수 없는 초 대형 국가 인프라 구축 프로젝트들이

         많이 수행되었다. 이러한 이유로 공공 SI 프로젝트는 SI 프로젝트 영업의 핵심이라고 할 수 있다.
      • 공공 SI 프로젝트 영업에서 우위를 차지하여 프로젝트를 수주하기 위해 일년 이상의 영업을 펼쳐야 하는 경우도 드물지

        않으며 노력과 시간 및 비용을 쏟아 붓고도 최종 수주에 실패하는 사례도 많다.

      • 모 기업의 광고 문구로 사용되었던 1등이 아니면 아무도 기억해 주지 않습니다' 라는 말이 가장 잘 어울리는 분야

      • SI 프로젝트 수주 영업전에서 2위 최하위와 다를 바가 없는 것이기 때문에 SI 프로젝트 수주를 위한 사전 영업 단계에서

        부터 최선의 노력을 경주하여야 하는 것

         → SI 프로젝트 영업의 성공을 위해서는 영업사원만으로는 절대로 불가능

         → 정보시스템 기술분야 업무 프로세스 전문 분야, 제안서 디자인 등 여러 분야의 전문가가 함께 팀웍을 이루어야만 SI

             프로젝트의 성공적인 수주가 가능

      • 공공 부문에 대한 제안에 참여하고자 하는 업체 입장에서 보았을 때 불공정함을 느끼게 하는 사례

         → 프로젝트 제안에 참여할 수 있는 업체의 자격을 사전에 제한

         → 프로젝트에서 고객이 요구하는 내용에 특정 업체의 솔루션에게 유리한 요소가 포함

         → 제안서를 충분히 잘 작성하기에는 너무나도 짧은 시간이 주어지는 경우 등

      • 불공정하다고 느끼는 업체는 SI 프로젝트 영업의 전부를 알지 못하기 때문에 그러한 상황에 처하게 되는 것으로 SI 프로

        젝트의 영업은 고객이 프로젝트의 제안 요청 공고를 공지하기 훨씬 전부터 시작되는 것이기 때문

2.2 사전 영업

   - 고객이 정보화 시스템을 도입하고자 하는 필요성을 느껴 이를 추진하는 최초의 시작 단계에서부터 고객과 함께하는 것을

      의미

   - 때론 사전영업이 고객이 스스로 정보화 사업의 추진 필요성을 인지하지 못하고 있는 단계에서 시작하여 정보화 사업 추진

      의 필요성을 깨닫게 하는 것까지 포함하는 경우도 있다.
   - 구체화 되어 있지 않은 추상적인 영업 대상을 프로젝트 사업 추진으로 구체화 하는 것

      • 예) 교육기관에서 인터넷을 통한 온라인 교육 시스템의 필요성을 느끼도록 하고 동시에 온라인 교육 시스템을 구축하기

             위해 필요한 예산과 시스템이 가져야 하는 기능 정의 등을 도와서 고객이 고객 조직내부에서의 공감대를 형성하

             고 이를 최고위층의 추진 승인을 얻어 예산을 확보할 수 있도록 지원하며 프로젝트 추진을 위한 세부 시스템 사양

             등을 담은 제안 요청서 작성을 수행할 수 있도록 함으로써 구체적인 프로젝트로 이어질 수 있도록 여러 방면에서 지

             원하는 것

   - 고객의 현황을 정확히 알고 요구사항을 구체화할 수 있어야 하며 또한 고객의 담당자와 인간적인 신뢰 관계를 통해 갑과

      을의 관계를 넘어서는 공동 작업이 필요한 단계
   - 업무적인 특성으로 인해 물밑에서 작업이 이루어지는 경우가 대부분

      • 은밀하게 추진되다 보니 자칫하면 구설수에 휘말릴 수 있다.

      • 담당자와의 밀착이 필요하고 이는 다시 경쟁업체의 불만이 되어 논란의 여지를 만들 수 있으나, 사전영업은 궁극적으로

        SI 기업의 영업력과 직결되며 사전 영업의 정도에 따라 본격적인 제안 작업에 들어갔을 때 유리한 고지를 차지할 수 있

        거나 그 반대의 경우가 될 수 있으며 최종 제안심사 및 결과에 지대한 영향을 주는 경우도 있기 때문에 피할 수 없는 단

        계
   - '세상은 공정한 평가를 하는 곳이 아니라 공정한 기회를 제공하는 곳이다.' 세상에는 원리원칙에 따라 이루어져야 하는 일

      들이 그렇지 못하게 처리되는 경우가 많다. 사람들이 하는 일이어서 그런 것이겠지만 SI 프로젝트의 사전 영업단계에서는

      특히 많이 발견되곤 한다. 현실이 그렇다고 이를 비판만 하거나 도외시할 수 만은 없다. 치열한 경쟁의 현장에서 최종적으

      로 웃음짓는 이는 마지막에서 승리한 자이기 때문이다.

   - 사전영업단계에서는 아무도 최종 프로젝트 수주를 장담할 수 없다.

      • 고객이 영업담당자 자신의 의도에 따라 움직일지 확신할 수 없고 사전영업에는 정해진 기간이 없다.

      • 올해 발주될 것이라던 프로젝트가 있어 많은 시간과 노력을 투자하여 사전영업에 매달렸건만 프로젝트의 발주가 연기되

        는 경우도 있다.
      • 최악의 경우 추진하던 사전영업 대상 프로젝트가 고객의 갑작스러운 사건으로 최소되는 경우도 가능

      • SI 프로젝트 영업은 특성상 매우 오랜 기다림과 노력을 필요로 하는데 결과가 원하는 데로 될 확률은 매우 낮다.

      • 그렇다고 사전영업에 뛰어들어 그 판에 참여하지 않으면 제안요청서가 공식적으로 발표될 즈음엔 이미 주도적인 참여자

        가 되기에는 어렵게 된 이후이다.
   - SI 기업의 영업사원들은 자신의 영업 활동 중 사전영업에 대한 비율을 적절히 조정하여야 한다.

      • 사전영업의 성공 확률이 높지 않은 경우 판단에 따라 중도 포기도 가능하며 때로는 묻어둘 필요도 발생

      • 동시에 여러 개의 사전 영업을 진행하여 가시화가 우선적으로 되는 영업 대상에 대해 보다 높은 순위를 두고 영업 활동

        비율을 조정할 수도 있다.

      • 모든 판단은 영업사원의 현황분석 능력과 판단력 그리고 영업경험과 자신만의 직감 등이 필요

      • 영업을 잘 하는 사원은 사전영업에서부터 모든 것이 시작

   - 사전영업단계에서는 다음과 같은 일들이 진행된다.

2.2.1 고객과의 인간관계 관리
   - 향후 고객이 될 가능성이 높은 기업의 업무 담당자와 의사 결정권자에 대해 지속적인 관심과 방문 등을 통해 유대관계

      유지

   - 공공기관의 경우 대부분의 SI 프로젝트가 수의계약이 아닌 공개입찰 형식으로 추진되지만 민간기업의 경우에는 이러한

     인간관계를 통해 수의계약 형태로 프로젝트를 수주할 수도 있다.

      • 비록 공개입찰로 추진된다고 해도 고객과의 인간관계 관리가 잘 되어 있는 경우에 손해 볼 것은 없다.

2.2.2 정보입수
   - SI 프로젝트가 공식적으로 발주되기까지는 매우 오랜 기간이 소요되는 경우도 많다.

      • 발주처의 내부 기안에서 품의 및 승인, 예산확보, RFP 작성 등 여러 단계를 거쳐야 한다. 이 과정에서 여러 경로를 통해

        발주처의 프로젝트 정보가 입수될 수 있다.
      • 발주처의 프로젝트 정보 입수를 위하여 SI 기업이 가지고 있는 인적 네트워크를 통해 가장 가까운 인물을 찾아 접근을

        시도할 수도 있다. 대형 SI 기업의 경우 영업사원들이 보유하고 있는 인적 네트워크를 데이터베이스화하여 제공하는    

        이유가 여기에 있다.

   - 프로젝트 사업영업에 관련하여 입수하는 정보로는 프로젝트의 예산 규모, 발주주체, 수행기간, 수행 내역 등의 프로젝트

     기본 정보는 물론 의사결정권자, 실무자, 발주 형태, 예상 발주 시기 등 영업에 필수적인 정보들이 포함

2.2.3 협력업체 네트워크 구성
      - SI 프로젝트 수행은 대형 SI 기업의 경우에도 대부분 자사의 자원과 솔루션, 인력만으로 수행하기보다는 몇 개의 기업

        이 협력하여 수행

         . 사전영업에서도 필요한 경우가 많다. 각기 가진 사전영업력을 합하여 보다 확실하게 수주를 위한 영업을 전개할 필요

           가 있는 경우에 해당
      - 협력을 위한 업체는 프로젝트의 수주 후에 결정되는 경우도 있지만 대부분 사전영업단계에서 함께 노력한 업체가 프로

        젝트 수주 후 협력업체로 함께하게 된다.

         . SI 프로젝트에 참여하고자 하는 업체들은 사전영업을 위해 자사의 솔루션이나 영업력을 함께 할 동반자를 물색하고 조

           건을 평가하는 등의 작업이 수행

      - 협력업체 네트워크가 잘 구성되면 프로젝트의 영업에 강한 우위

         . 프로젝트가 성공적으로 수주되지 못하면 협력업체들은 참여 기회를 함께 잃게 되기 때문에 서로가 다방면에서 신중하

           게 협력 여부를 모색

      - 전체 프로젝트를 주관할 대형 SI 기업은 물론 영업 인맥을 보유한 기업, 분야별 솔루션을 보유한 기업, 각종 하드웨어 및

        소프트웨어 기업 등이 서로 이해관계를 가진다

         . 이들 기업들은 사전영업에 필요한 여러 작업을 함께 하기도 하고, 필요한 자금을 공동 투자하며 고객에게 필요한 여러

           자료들을 작성
      - 사전영업은 특별히 구체적인 대상을 가지지 않는 경우도 있다.

         . 예) 주변의 지인들을 지속적으로 만나고 관계를 유지해 나가는 것도 사전영업의 하나이기 때문

               SI 영업사원들을 가까이서 보면 한가해 보이나 결정적인 순간이 되면 모든 힘을 집중하여 강하게 추진해야 한다.

               이런 경우가 제안요청서 내용 작성단계이다.
      - 제안요청서(RFP, request for proposal)는 고객이 SI 업체에게 고객의 요구사항과 구현하고자 하는 시스템의 기능 및 내

        용, 하드웨어, 소프트웨어 사양, 프로젝트 수행 기간 및 조건, 금액, 수행방법 등의 프로젝트 수행이 필요한 구체적인 내

        용을 제시한 문서

         . SI 프로젝트의 영역에 따라 제안요청서 내용 차이(공공기관, 민간기업, 소프트웨어 개발, 하드웨어 시스템 납품)

      - 다음은 일반적인 제안요청서의 구성 내용이다. 상세한 내역은 제안서의 작성 부문에서 기술한다.

■ 일반적인 제안요청서의 구성 내용
   1) 추진배경 및 필요성
      - 프로젝트를 발주하는 발주처의 프로젝트 추진의 배경과 의의를 설명한다.
   2) 추진목표
      - 프로젝트 추진의 목표를 기술한다. 여기서는 프로젝트 완료 후 기대되는 효과가 서술된다.
   3) 구축 대상업무
      3-1) 구축개요
         - 구축할 시스템에 대한 구체적인 업무 내역 및 기능에 개요이다.
      3-2) 추진 범위
         - 본 RFP에 관련하여 제안사가 수행하여야 할 시스템 구축 범위와 업무 영역에 대해 상세히 기술한다.
      3-3) 세부 추진일정
         - 제안사가 수행할 프로젝트와 관련된 세부 추진 일정을 기술한다. 세부 추진일정에는 RFP의 공지에서부터 제안
           서 마감, 제안서 심사 및 최종 사업자 선정 일정과 함께 프로젝트의 착수 및 종료, 중간 검수 등의 추진 일정이
           함께 제시된다.
   4) 현재까지 추진현황
      프로젝트 발주를 위해 수행되었던 업무 내역을 소개한다. 규모가 큰 기업이나 공공기관의 경우에는 이전에 여러
      시스템 구축 프로젝트를 수행한 내역을 보유하고 있다. 지금까지 수행되었던 정보시스템 구축 프로젝트의 현황 정
      보를 통해 RFP에서 요구하는 시스템 구축 사항을 보다 명확하게 할 수 있다. 또한 기존에 사용하고 있는 시스템에
      대한 내용을 소개한다. 새로이 구축되어야 할 정보시스템이 기존의 시스템과 어떻게 인터페이스 되고 운영될 지에
      대한 요구사항을 설명할 수 있다.
   5) 제안요청 내역
      제안사가 제안서 작성 시 담아야 할 내용에 대한 구체적인 목차를 제시한다. 제안서가 제안 업체마다각기 다른 목
      차와 구성으로 되어 있다면 제안 심사 시 이를 비교평가하기가 매우 어렵다. 따라서 제안사가 제안서 작성시 반드
      시 포함하여야 할 내용을 목차로서 제시하여 제안서 평가를 용이하게 한다. 다음은 간략한 제안서 목차 내역이다.
      - 제안업체 일반현황 : 제안사의 소개를 담는다. 회사규모, 이력, 실적정보, 인력구성 및 품질인증현황 등 제안서 평
                                   가에 반영될 내용을 기술한다.
      - 기술부문 : 제안서의 제안 중심 내용으로 제안하고자 하는 시스템의 구축에 관련된 기술적인 내용을 여기에 기술
                      한다. 전체 제안서에서 가장 많은 내용 분량을 가진다. 제안 시스템 기능, 구성 및하드웨어, 소프트웨어
                      구성을 설명한다. 또한 전체 제안 시스템의 추진 일정도 포함한다.
      - 시스템 운영부문 : 시스템의 운영에 관련된 내용을 기술하는 부문이다. 고객이 제안요청서에서 시스템의 운영에
                                관한 제안 요청을 한 경우 이 부문이 필요하며 일반적으로는 시스템 구축 완료 후운영 방안에
                                대해 기술하게된다.
      - 사업관리부문 : 제안사가 제안하는 프로젝트의 수행과정에서 어떻게 프로젝트를 관리할 것인지에대한 내용을 기
                            술한다. 프로젝트 관리 방법, 업무 진행현황 보고 방법, 인력 관리방안 등을 포함한다. 또한 프로
                            젝트 수행 조직 및 업무분장, 프로젝트 투입 인력에 대한 이력사항과 프로젝트의 품질보증계획
                            등을 기술한다.
      - 지원부문 : 정보시스템을 구축하는 프로젝트의 수행과정에서 발주처에서 요구하는 지원 사항에 대한 제안사의
                      제안내용을 기술한다. 주 내용으로는 시스템 운영 담당자 및 사용자에 대한 교육훈련계획, 시스템 개
                      발 완료 후 유지보수 계획, 시스템 구축에 관련된 신기술에 대한 발주처 대상 기술이전계획 및 시스템
                      검수 계획 등을 포함한다.
      - 가격부문 : 제안사가 제안하는 내용에 관련된 하드웨어 및 소프트웨어, 인건비, 경비, 기타 비용을상세히 기술한
                       다.
   6) 제안 안내사항
      제안요청서에 반드시 포함되어야 하는 내용으로 제안사가 준수하여야 할 제안서에 대한 기본 원칙을규정한다. 주
      내용으로는 제안서 등록 마감일, 제안서 제출 방법, 제안참가자격, 제안서의 효력, 제안유의사항 및 제안서 평가 배
      점 등이다.
   7) 제안서 관련 서식
      제안서는 평가를 위해 작성하는 문서이다. 따라서 여러 제안서간의 비교평가가 용이해야 한다. 이를위해 제안요청
      서에는 제안서가 따라야 할 기본적인 문서 양식과 서식 등을 제시한다. 때로는 제안서에 제안사의 회사명을 포함
      하지 말 것을 요구하는 경우도 있다. 제안서는 상대적인 평가가 용이하도록 작성하면서 자사의 강점을 부각하는
      것이 중요하다.

   - 제안요청서 내용에서 사전영업 단계의 주요 공략대상으로는 제안요청서 기술부문에서 사전영업을 수행하는 기업에게 유

     리한 기능사양이나 제품 스펙을 반영하는 일

      . 제안서 평가 시 제안요청서에서 요구한 기술사양의 만족 여부가 심사 점수에 중요한 부분을 차지

      . 제안요청서의 기술사양에 자사가 원하는 내용을 포함할 수 있는 단계는 사전영업 단계뿐

      . 사전영업 단계의 성패를 결정하는 중요한 결과가 제안요청서의 내용인 것

      . 사전영업에서 중요한 요점은 제안서의 평가 방법 및 제안서 접수 일정 등 프로젝트 입찰 수행 과정에 대한 영향력

2.3 SI 프로젝트의 입찰 형태

   - 대규모의 공공 SI 프로젝트는 대부분 공개 입찰 방식을 통해 사업자를 선정

   - 민간기업의 경우 수의계약을 통하는 경우도 있으나 수의계약은 영업의 흐름이 단순하고 기업간의 특별한 관계 속에서 이

     루어지는 경우가 많다.

      . 수의계약은 발주자가 사업자를 지정하여 선정하기 때문에 특별한 제안서가 없는 경우도 있고 영업 형태도 각각의 경우

        마다 다름

   - 프로젝트 입찰은 공공기관의 경우 국가기관인 조달청을 통해 공개적으로 입찰을 수행하는 경우와 발주처에서 직접 입찰

     을 진행하는 경우로 구분

      . 조달청은 국가의 모든 정부기관 및 관련기관에서 필요로 하는 소모성 자재로부터 초대형 SI 프로젝트에 이르기까지 해

        당 기관의 요청을 받아 이에 대한 발주 및 사업자 선정을 대행해주는 기관

      . 조달청 홈페이지에 있는 입찰정보를 보면 하루에도 수백 건의 입찰 건이 등록
   - 국방 프로젝트의 경우에는 조달청을 통하지 않고 국방부 조달본부를 통하거나 또는 육군 중앙경리단을 통하는 경우 도 있

      다.

      . 주요 기능으로는 공공기관의 기자재 발주 및 구매업무와 SI 프로젝트 및 토목, 건설 등 프로젝트 형식의 사업 발주, 심사,

        사업자 선정 업무 및 계약 이후 이에 대한 집행과 감리 업무 등을 수행

   - 민간 기업의 경우는 대부분 발주처에서 직접 입찰을 진행

   - 발주처가 직접 입찰을 진행하는 경우는 입찰 과정 및 제안심사방법, 최종사업자 결정방식 등이 다양

   - 입찰방식으로 프로젝트의 사업자를 선정하는 경우 공정성과 객관성의 확보가 가장 중요하여 대부분의 프로젝트 입찰에서

      는 다음과 같은 단계를 거친다.

2.3.1 프로젝트 입찰공고 및 제안요청서 배포
   - 프로젝트를 발주하고자 하는 기관 또는 기업에서는 주요 일간지 또는 경제지 등에 해당 프로젝트의 입찰공고문을 반드

      시 개제

      . 입찰을 추진함에 있어 정보의 은폐를 통한 공정한 참여 기회의 박탈을 막기 위함

   - 국가기관인 조달청을 통한 입찰을 추진하는 경우에는 조달청의 웹사이트를 통해 해당기관의 프로젝트 입찰정보를 공지

      . SI 프로젝트에 영업을 담당하고 있는 부서 또는 영업담당자는 각종 신문의 입찰공고와 조달청 입찰 정보를 파악하고 있

        어야 한다.

      . 입찰공고는 납품 형식의 구매입찰, 건설과 토목 분야의 공사입찰, 전기/통신/소방 분야의 공사 및 설비 입찰과 정보시스

        템 구축 SI 프로젝트가 해당되는 용역입찰로 구분

      . 이러한 입찰에 대한 정보제공만을 전문으로 하는 서비스 기업을 통한 입찰정보의 파악도 가능

■ Note. 사전영업 비밀 1
입찰공고와 관련하여 사전영업을 펼치는 업체의 입장에서는 자사에 유리한 고지를 선점할 수 있는 방안을 마련하고자 할 것이다. 이러한 목적을 달성하기 위해 사전영업 단계에서 업체는 발주처와 제안요청서를 함께 작성하는 경우가 있다. 이는 공정한 입찰이라는 면에서 볼 때 문제점이 있는 것이다. 그러나 오직 승자만이 모든 것을 차지하는 입찰 영업의 현장에서 가능한 모든 수단을 동원하는 것이 현장의 현실이다.

제안요청서를 사전영업 업체에서 작성하거나 또는 작성을 도와주게 되면 해당 업체는 동시에 이에 부합하는 제안서의 작성 작업을 함께 병행할 수 있다. 또한 자사의 솔루션과 제품에 유리한 기술 사양을 제안요청서 기요구사항에 반영할 수 있다. 불공정하다고 생각하는가? 사전영업에서 공정성이란 누구에게나 사전영업을 할 수 있는 권한이 있다는 것뿐이다. 물론 공공기관의 프로젝트에서는 이러한 일이 벌어지기 어렵다. 향후 수주에 실패한 기업이 문제 삼을 소지가 있기 때문이다. 그러나 민간기업의 SI 프로젝트에서는 공공기관에 비해 향후 문제 발생 소지가 적어 사전영업이 더욱 활발하다. 그리고 공공기관의 경우에도 전혀 없다고는 할 수 없다.

또 한가지 사전영업 업체가 유리한 고지를 선점하는 방법으로 입찰공고를 가장 구독률이 낮은 신문에 아주 작게 공고하는 것이다. 최소한의 요건만을 충족한다는 것이다. 그리고 입찰공고가 난 이후 제안서 접수 기한까지의 기간을 최소로 하는 것이다. 예를 들면 비교적 완성도 높게 제안서를 작성하려면 최소 한 달의 기간이 필요하지만 입찰공고에는 2주일 정도의 기간을 주는 것이다. 그러면 제안요청서에 대한 내용을 사전에 알고 있는 업체의 경우에 경쟁자에 비해 완성도가 높은 제안서를 작성할 수 있게 된다.

   - 위 사례는 바람직한 경우라고 할 수는 없다. 그러나 사전영업이란 치열한 영업현장에서 어떻게 해서라도 경쟁자에 비해 우

      위에 설 수 있는 토대를 마련하는 것이 목적이다.

      . '전쟁과 사랑에 있어 공정한 것이란 없다'는 격언이 있다. 전쟁에서는 이기는 쪽이 정의이며 사랑에서는 원하는 사랑을

        얻는 것이 목적이다.
      . 오랜 기간 이러한 SI 프로젝트 입찰 영업을 담당했던 영업사원들은 프로젝트 입찰 공고가 나게 되면 직감적으로 해당 프

        로젝트가 사전영업 업체의 영향을 받았는지 알 수 있다고 한다.

      . 때론 입찰 과정이 진행되기 전에 프로젝트를 수행할 최종 사업자가 누구라는식의 이야기가 떠돌기도 한다. 그러나 어떠

        한 경우든 최종 승자를 결정하기 전 까지는 무수한 변수가 존재한다. 그리고 결국엔 한 기업만이 최종 사업자로 선정되

        는 것이다.

2.3.2 제안요청서

   - 제안요청서에는 발주처의 오랜 고민과 노력이 담겨 있다.

   - 제안요청서는 프로젝트에 대한 기초적인 구상에서부터 내부 검토 및 품의단계를 거치고 최종적으로 요구되는 시스템에 대

     한 기술적인 세부 사양을 확정하고 발주형식 및 프로젝트의 수행예산을 확보하고 제안요청서를 작성하기까지 오랜 시간

     노력한 결과물인 것이다.
   - 제안요청서의 문구 하나에는 발주처의 요구사항 또는 의도하는 바가 담겨 있기 때문에 제안서를 작성할 제안요청서는 완

      벽히 이해할 때까지 몇 번이고 다시 봐야 한다. 그리고 그 중에서 중요한 사항들은 거의 암기하다시피 알아야 한다.

   - 공공기관의 제안요청서는 대부분 아래한글 워드로 작성되기 때문에 아래한글워드를 읽을 수 있는 프로그램을 설치

      . 드문 경우이긴 하지만 제안요청서를 무상으로 배포하지 않고 유상으로 판매하는 경우도 있다. 이 경우는 쓸데없이 제안

        요청서를 받아가는 것을 막고 입찰에 참여하고자 하는 의지가 분명한 기업에게만 제안요청서를 주겠다는 의미가 포함
   - 제안요청서는 인터넷 등을 통해 공개하는 경우가 많으나 때론 특정 장소에서 제안요청 설명회라는 형식을 통하여 참여한

     업체에게만 배포되는 경우도 많다. 이러한 경우에는 제안요청 설명회에 참가한 업체에게만 제안서 제출 기회가 주어지기

     도 한다.

   - 제안요청서는 제안서를 작성하기 위해 필요한 유일한 공식 서류

      . 수백 페이지에서 천여 페이지에 이르는 제안서를 작성할 때 근거로 사용하는 문서가 제안요청서

      . 제안요청서에 부수적인 문서들을 첨부해 제공하는 경우도 있으나 대부분 백여 페이지 미만의 제안요청서만을 가지고 수

        백 페이지에서 천 페이지가 넘는 제안서를 작성하는 것은 대단히 어려운 일이다.

■ 우선협상대상자 선정 방식에 의한 사업자 선정 절차 사례
OO종합정보시스템 구축사업자는 다음의 절차에 의하여 선정한다.
1) 입찰공고: 참가자격 기준 및 입찰방식 공고
2) 사업설명회: 제안요청서에 대한 수요자 측의 설명회 실시
3) 제안서 접수: 제반 구비서류와 함께 제안서 제출
4) 기술제안서 평가: 제안서 기술평가위원회를 구성하여 제안서 평가기준에 의거 제안서 평가
   - 제안서 평가실시 이전에 입찰업체의 제안 설명회 실시
5) 가격제안서 평가: 기술평가 후 평가
6) 협상순위 결정 제안서 기술평가 결과와 가격평가 결과를 합산한 점수에 의거 협상 우선순위 결정
7) 협상 및 선정
   - 협상 우선순위 1위부터 일반, 기술사항 및 가격협상
   - 상위순위에서 협상이 이루어지면 하위순위와의 협상은 생략
8) 계약 협상이 이루어진 업체와 계약체결

제안서 일반 및 기술 심사 기준 예

제안서 일반 및 기술 심사 기준 예

2.3.3 제안서 작성하기

   - SI 프로젝트의 영업단계의 중심은 제안서 작성

   - 제안서는 발주처의 제안요청서에 대한 제안사의 대응 문서

   - 제안서는 발주처의 제안요청서에서 담고 있는 내용을 기반으로 작성

   - 제안서에는 프로젝트에 대한 제안사의 의지와 기술력, 경험 등을 주장하며 목표 시스템에 대한 구축 방안을 제안서에 기술

   - 제안서의 분량은 제안요청서에서 제한하는 경우와 제한하지 않는 경우가 있으나 대부분 제한이 없다고 보면된다.

   - 제안서 작성은 프로젝트 수주 시 수행하는 작업과는 달리 고객으로부터 직접적인 요구사항을 입수할 수 없으며 발주처의

      기존 정보시스템 및 인터페이스, 운영상의 문제점 등에 대한 정보를 적극적으로 구할 수 없기 때문에 비공식적인 정보의

      입수가 매우 중요

   - 국내 SI 영업 분야에서 제안서의 작성은 대부분 비용을 발주처로부터 제공받지 않는다.

      • 프로젝트의 수주에 실패한 경우 제안서의 작성에 소요된 노력과 비용은 회수할 수 없는 것

      • 제안서의 작성은 프로젝트 수행에 비해 여러 제약을 가진다. 이런 이유로 대형 SI 프로젝트 제안에 참가하였다가 수주에

        실패한 기업의 경우에 수억 원의 제안 비용을 물거품으로 만드는 경우가 종종 있어 이에 대한 개선 방향이 모색되고 있

         기도 하다.

      • 제안에 참가한 기업 중 일정 수준 이상의 평가를 받은 기업들에게는 비록 수주에 실패한 경우라도 제안서 작성을 위해

        소요된 실 경비를 발주처에서 지급하는 것이다. 그러나 아직까지 현실화 되지 않은 단계이며 SI 기업은 불확실한 수주를

        위해 제안서 인쇄 비용만 몇 천만 원을 하기도 한다.

2.3.3.1 제안서가 가지는 특성
   1) 제안서는 평가를 위한 문서
      - 제안서는 프로젝트 수행과정에서 작성하는 문서와는 달리 뚜렷한 평가 기준에 의거 평가자가 다른 제안사의 제안서와

         비교평가하기 위해 필요로 하는 문서

         • 비교평가가 가장 핵심적인 사항이므로 제안 심사자의 평가를 용이하게 구성하면 좋은 이미지를 준다.

         • 제안서 작성은 제안요청서의 흐름에 입각하여 작성

         • 제안요청서와 제안서의 내용에 대한 대비를 위해 조견표를 작성하여 첨부하는 것이 바람직

   2) 제안서는 설계 문서가 아니다
      - 제안서는 공식적으로 발주처의 현황 및 문제점, 요구사항을 분석할 수 있는 환경이 아닌 상황에서 작성

         • 기존 프로젝트의 경험과 노하우가 가장 중요한 자원

      - 제안서의 작성을 위해 필요한 정보는 영업담당을 통해 입수하여야 하겠지만 완성도 높은 제안서의 작성은 제안 참여팀

         의 수준에 달려있다.

      - 제안서에서의 중요한 포인트는 발주처에 대한 직접적인 대면이 없는 상황에서 발주처의 요구사항을 꿰뚫어 보고 핵심

         사항에 대한 제안사의 대책과 전략을 제시하여야 한다는 것

      - 시스템 설계 문서처럼 모든 사항에 걸쳐 깊이가 동일한 나열식의 서술로는 제안사의 의도를 명확이 드러내기 어렵다.

   3) 제안서는 기술서적이 아니다
      - 제안서의 작성 시 기술적인 측면에서의 강점과 경험을 부각시키기 위해 기술설명이 지나치게 비중을 많이 차지하게 되

         면 제안서의 전체적인 균형이 흐트러진다.

         • 제안서의 중요한 포인트를 파악하고 이를 부각시키도록 한다.
      - 제안서 작성은 상대적으로 짧은 기간 동안 최선의 노력을 경주하여야 하는 단계로 제안서 작성을 위한 별도의 제안팀

        을 구성하여 작성

2.3.3.2 제안팀의 구성
   - 제안팀은 해당 프로젝트의 업무 분야 전문가와 관련 시스템 기술 전문가로 구성된 팀

   - 대형 SI 기업의 경우에는 제안서 작성 시 필요한 각 분야의 전문가가 풍부하므로 제안서 작성이 필요하면 그 동안 수행했

     던 수 많은 프로젝트 수행 경험과 인력을 바탕으로 잘 짜여진 프로젝트 제안팀을 구성할 수 있다.

   - 제안서를 작성하기 위한 제안팀의 인력은 다음과 같다.

   1) 제안 PM(project manager)
      - 제안서 작성을 주관할 관리자 프로젝트 수행 경험이 풍부한 전문가로 제안 대상 업무에 대한 프로젝트 수행 경험이 많으

         면 유리

      - 제안 요청서만으로 완성도가 높은 제안서를 작성하기에는 정보 및 관련 자료가 부족한 경우가 대부분

      - 프로젝트 관리자 수행 경력이 많은 역전노장이 가장 이상적

      - 제안서의 납기 및 품질에 대한 최종 책임을 지며 제안서 작성을 위한 제반 환경 구축에 노력

      - 전체 제안 시스템의 가격을 영업 전략에 따라 영업팀과 함께 조정하여 최종 제안가를 산정하는데 실무 책임자로서 영업

        과 함께 가격제안서를 작성

   2) 영업 담당
      - 제안서 작성에서 고객의 정확한 요구사항 파악과 제안을 위한 고객 관련 정보의 입수는 중요

      - 발주처의 고객과 긴밀한 관계를 가지고 있는 영업담당이 제안팀에 참여

      - 제안팀은 항상 영업 담당과 지속적인 정보 교환 및 협의를 진행

      - 영업담당은 제안요청서의 배경 정보와 경쟁사의 제안서 작성 현황 정보를 제안팀에 전해주어야 한다.

      - 제안팀은 제안서 작성 시 제안요청서만으로는 고객의 숨은 의도가 무엇인지 정확하게 파악할 수 없는 경우 영업담당을

        통해 정확한 의도를 파악하고 이를 반영하여 제안서를 작성한다.

      - 영업담당은 제안팀의 분위기 전환을 통한 사기 진작의 역할도 수행
      - 제안작업은 비록 수행 기간이 프로젝트 수행에 비해 짧지만 작업 강도는 프로젝트의 수행의 막바지 단계에 버금가는 강

        도 높은 작업

         • 제안참여자들은 쉽게 피로가 누적되고 작업 능률도 저하

      - 영업사원은 내부 영업의 관점에서 제안팀이 항상 적극적이고 생산적인 분위기에서 작업할 수 있도록 물심양면으로 적극

         지원

   3) 제안 시스템 업무 전문가
      - 제안서 작성은 발주처의 제안요청서에 따라 제안사의 프로젝트 수행 계획 및 시스템구성 내용은 물론 업무의 개발을 위

         한 구체적인 방안을 제시

      - 해당 업무 분야의 전문가 참여는 필수적
      - 대형 SI 기업의 경우 자사의 인력에 대한 상세한 프로젝트 경력 관리 및 개인 기술 요소를 데이터베이스화 하여 언제든

         지 검색이 가능하도록 하고 있어 원하는 업무 분야의 전문가를 찾기 쉽다.

      - 중소 SI 기업이나 또는 전문 솔루션 기업의 경우 모든 분야의 업무 전문가를 보유하는 것이 어렵기 때문에 자사가 가능

        한 분야의 제안에 참여하거나 또는 여러 기업이 협력하여 제안서를 작성

      - 업무 전문가의 역할은 발주처의 해당 업무에 대한 상세한 기술 및 이에 대한 정보시스템 구현 전략을 담당

   4) IT 기술 전문가
      - IT 기술 전문가는 제안서의 기술 분야를 담당

      - 제안하는 시스템의 구성 및 기술 요소에 따라 다양한 분야의 기술 전문가 필요

      - 정보시스템의 구축을 위해 요구되는 IT 기술은 ITA(Information Technology Architecture) 정의에 따라 구분하면 가장 체

        계적으로 분류

      - 제안서 작성에서 IT 기술 전문가의 역할은 제안서에서 제안하고있는 정보시스템의 기술적인 타당성 및 안정성, 구현성

         등에 대한 제안 및 검증을 담당

   5) 품질 담당자
      - SI 프로젝트는 수 많은 문서와의 전쟁

      - 대형 SI 기업은 생산성 및 품질을 향상하기 위해 끊임없이 노력하고 있다. 이러한 노력의 주축이 되는 부서가 품질부서

      - 품질부서에서는 자사에서 수행하는 모든 프로젝트에 대한 품질을 책임지지만 프로젝트 착수 이후가 아닌 영업단계의 제

        안서 작성에도 참여하는 경우가 있다.

      - 제안서의 기본적인 문서 형식 및 내용 전개 방식, 구성 등에 대해 자사의 기본 가이드라인에 따르고 있는지 확인하고 자

        사의 제안서가 통일된 느낌으로 작성될 수 있도록 모든 제안서 작성 팀의 제안서를 검토

   6) 그래픽 디자인 전문가
      - 제안서는 필연적으로 경쟁을 위해 작성하는 문서

      - 내용의 충실성 및 완벽성은 물론이며 제안서의 서식이나 포함된 그림, 제안서의 표지 등의 디자인을 담당할 그래픽 디자

         인 전문가가 참여

      - 대형 SI 기업은 자체적으로 디자인실을 운영

        • 디자인실의 역할은 제안서 및 프리젠테이션 자료 등에 대한 디자인 템플리트 제공, 그래픽의 수정 및 보완 등을 담당

      - 중요한 제안의 경우에는 제안서 작성 후 인쇄 및 제본 등에만 수천 만원의 비용이 소요되기도 할 정도로 제안의 내적 품

        질은 물론 외적 품질에도 많은 관심을 쏟게 된다.

2.3.3.3 제안서 작성의 기본 원칙
   - 제안서는 영업 진행에 있어 충분 조건이 아닌 필요조건

   - 제안서가 아무리 잘 쓰여져도 영업이 성공하여 프로젝트를 수주하는데 있어 잘 작성된 제안서만으로 가능하지는 않다.

   - 아무리 영업이 성공적으로 진행되고 다른 조건이 충족되어도 경쟁 입찰에서 제안서의 품질에 문제가 있다면 프로젝트의

      수주에 실패할 가능성이 높다.
   - 제안서는 문자로 기록되어 인쇄되고 복사된 후 고객에게 공식적으로 전달되는 문서

   - 제안서는 여러 명의 제안 심사담당자들이 함께 검토하고 검증하는 문서

   - 결격사유가 있거나 품질에 문제가 있는 제안서가 통과되어 프로젝트를 수주하게 될 경우 경쟁사의 이의제기에 충분한 근

      거가 되는 것

   - 눈에 보이지 않는 사전영업이나 영업의 활동은 무리하게 하지 않는 한 경쟁사가 이의제기 할 근거가 없으므로 프로젝트의

      수주 후에 문제를 야기하지 않는다.

   - 제안서는 그렇지 않은 것이다. 이 점이 제안서 작성의 특성이다.

   - 제안서 작성 시 고려하여야 할 기본 원칙을 정리하면 다음과 같다.

   1) 제안서가 프로젝트 수주 성공을 보장하지는 못하나 프로젝트 수주 실패의 원인이 될 수 있다.
      - 제안서가 프로젝트 수주에 성공하려면 사전영업, 인간관계, 발주처 정보 입수능력, 제안 가격 등 여러 요인들이 우위에

         있어야 한다.

      - 제안서가 아무리 잘 작성되어도 그것만으로는 프로젝트 수주에 성공할 수는 없다. 그러나 만약 제안서에 문제가 있다면

         다른 나머지 조건들이 문제가 없어도 프로젝트 수주에 실패할 수 있다. 제안서 작성이 힘든 것은 단기간에 많은 작업을

         해야 하기도 하지만 이러한 심적인 부담도 큰 영향을 미친다.

      - 제안서의 우위는 제안심사에 들어가서 직접 평가를 받기 때문에 학교에서 시험을 치르듯 바로 결과가 나온다.

   2) 제안서는 양적인 면보다 질적인 면에 충실하여야 한다.

      - 학교에서 보고서를 쓰거나 또는 회사에서 사업계획서를 쓸 때 두꺼운 보고서나 사업계획서가 더 있어 보이는 느낌을 주

         는 것을 많이 경험했을 것이다.

         • 실전에서 제안서를 제출하는 것을 보면 제안사들이 수백 페이지 이상으로 두툼하게 제본하여 제출(별책 포함)

         • 우수 평가를 받은 제안서들의 경우에도 어느 정도 분량이 되는 것

            → 제안서를 얄팍하게 제출하는 것이 국내의 정서에는 잘 맞지 않는 것 같다.

            → 제안서의 양을 늘리느라고 의미 없는 내용들을 많이 담게 되면 심사위원들에게 좋은 평가를 받을 수 없다.

      - 제안서의 내용을 제안요청서와 관련하여 핵심적인 내용들로 기술하는 것이 필요

        • 제안서의 핵심적인 내용을 짜임새 있게 기술하고 부록을 활용

        • 제안심사위원들이 필요한 경우 세부적인 사항을 확인할 수 있도록 부록에 상세한 내용을 기술하면 좋은 평가

   3) 제안서 작성은 제안서 심사를 위한 것이다.

      - 제안서는 제안심사위원의 평가 기준에 맞추어 높은 평가를 받기 위해 작성하는 것

         • 제안서의 구성과 내용 작성은 철저히 제안서 평가에 맞추어져야 한다.

      - 제안 심사자의 입장에서 검토

      - 아래 점검사항들을 제안서 제출 전에 반드시 내부는 물론 외부의 인력을 통한 리뷰를 수행하나 제안서 내용의 사전 유출

        은 철저하게 방지하여야 할 것

         • 작성 내용이 너무 장황하지는 않은가?

         • 요점을 쉽게 파악할 수는 있는가?

         • 제안서에 적절한 그림과 도표가 포함되어 있는가?

         • 제안요청서의 충족여부를 용이하게 파악할 수 있는가?

         • 제안사의 입장에서 작성된 내용은 없는가?

         • 객관적인 사실이 아닌 주관적인 사실이 강조되지는 않았는가?

   4) 제안서 문구 하나 향후 프로젝트 수주 시 업무 수행 범위에 근거로 사용된다.
      - 제안서는 제안요청서에 따라 제안사에서 향후 프로젝트에 대한 수행 계획 및 업무 범위에 대해 제시한 금액 내에서 수행

        을 약속하는 공문서

      - 제안서는 프로젝트 수주 시 고객과의 계약서에 근거서류로 첨부

         • 제안서의 내용은 프로젝트 수주 후 실행을 염두에 두어야 한다.

      - 기술적인 우위나 업무적인 우위 평가를 위해 제안서 작성 시에는 적극적인 업무 범위의 확대나 최고의 기술을 제안할 수

        있으나 수주에 성공할 수는 있겠지만 프로젝트의 수행 단계에서 큰 어려움에 빠질 수 있다.
      - 많은 제안서 작성 사례에서 제안요청서 상의 요구사항 이상을 제안하게 되면 프로젝트 수행 시 손익문제가 발생하는 사

        례가 종종 있다.

         • 제안서 작성 시에는 프로젝트의 실행관점에서 제안서를 검토하고 평가할 인력의 참여가 필수적

         • 제안서가 가진 위험 요인을 발굴하고 제고할 필요

      - 제안 작성자가 인지한 상태에서 의도적으로 제안서에 포함시킨 위험 요인들은 그래도 문제가 적은 편이다. 더 큰 문제는

        업무적이든 기술적이든 제안서 작성자가 전혀 인지하지 못하고 있는 부분들이다.

         • 예를 들면 기술적으로 결함이 있는 제안이라던가 업무 범위에 대한 이해 부족으로 인한 부분, 프로젝트 수행 경험이

           부족하여 수행과정에서 있을 수 있는 위험 요인을 간과한 부분 등을 찾아내는 것이 더욱 중요하다.

         • 제안서 작성 시에는 외부 전문가의 리뷰 단계를 꼭 거치도록 한다.

      - 제안서의 내용 한 줄에 따라 프로젝트 수행 단계에서는 비용의 추가 지출 및 프로젝트 일정의 지연이라는 중대한 문제가

        발생할 수 있음을 명심

   5) 제안서는 최상의 시스템을 제안하는 것이 아니다.

      - 제안서 작성 시 실무 기술 담당자들은 제안서 평가에 우수한 점수를 얻고자 기술적으로 완벽한 안을 추구할 수 있다.

         • 제안서에 담기는 시스템의 품질은 향상될 수 있겠지만 제안서가 지켜야 할 다른 항목에는 나쁜 영향을 미칠 가능성이

          높다.
      - SI 프로젝트는 제한된 기간과 비용 및 자원을 가지고 수행

         • 제안서에 완벽한 시스템이 제안된 경우 수행 시 비용이나 기간 측면에서 당초 계획하였던 것을 초과

            → 제안서 작성만을 담당한 담당자는 모르겠으나 프로젝트 수행 팀은 큰 어려움을 겪게 된다.

      - 제안서에는 주어진 조건을 감안한 최적의 시스템이 제안되어야 한다.

         • 반드시 제안된 시스템에 대한 상호 검증 및 프로젝트 실행 담당과 협의

         • 정보시스템을 구축하는데 있어 최신 기술을 채택할 때는 항상 신중
      - 실무 기술자의 입장에서 해보고 싶은 최신기술을 프로젝트 제안에 포함할 때는 기술인력에 대한 수급 여부 확인, 기술

        을 구현한 제품의 안정성 및 기술지원 수준 확인, 타 프로젝트 또는 시스템에서의 적용 사례 연구 등을 통해 위험성을 최

        소화

      - 개발자 입장에서 관심이 높은 최신 기술이 제안서 작성 시 포함되어 있는 경우 프로젝트 수행 시 큰 어려움을 겪는 원인

        이 될 수 있다.
         • 초기 클라이언트/서버 기술과 객체지향 기술이 등장할 당시가 그러한 경우에 해당되어 일부 프로젝트에서 인력 확

           보 및 개발에 어려움

         • 신기술을 채택하여야하는 프로젝트의 경우에는 반드시 문제 발생시에 대비한 여유 기간과 자원을 감안

   6) 제안팀은 전문가들이 모인 특공대와 같다. 각자 담당한 영역에서 최고가 되어야 한다.

      - 제안서 작성은 짧은 기간 내에 경쟁에서 승리할 수 있는 제안서를 작성하는 것이 목표

      - 구체적인 경쟁 상대가 있으며 극복해야 할 과제가 분명하다는 점에서 치열한 전투와도 같다.

      - 프로젝트의 실행 시와는 달리 소규모의 인력으로 수행해야 하기 때문에 각 분야를 담당하고 있는 제안작성 담당자는 자

        신의 분야에 대한 전문성이 우수해야 할 뿐더러 최고가 되기 위한 노력을 아끼지 말아야 한다.
      - 제안서의 품질은 전체적으로 고르게 완성도가 높아야 하며 특정 부문의 완성도가 떨어지면 전체 제안서의 품질이 영향        - 제안서 작성기간에는 각 분야에 소홀히 하지 않는 유능한 팀원이 필요함은 물론 전체적인 팀워크를 중요시
      - 야간 근무 및 밤샘이 많은 제안서 작성 기간에 팀워크가 흐트러지게 되면 누적된 피로와 스트레스로 인해 갈등이 발생하

         거나 제안서 작성 효율이 급격히 떨어질 수 있다.

      - 든든한 팀워크와 각 분야에 능통한 전문가의 책임감 필요

   7) 제안서 템플리트 및 표준 도식은 많이 확보할수록 유리하다.

      - 제안서 작성 기간은 대체로 2주에서 한달 가량이 주어진다. 짧은 기간에 가장 효과적인 작성 전략은 기존의 제안서 및

        표준 도식을 최대한 활용하는 것이다.
         . 제안서의 작성에는 많은 그림과 도표 등이 포함

         . 제안 평가자의 이해와 관심을 높이기 위해 가능한 모든 내용을 그림으로 도식화 하고 표로 표현

      - 제안서 작성자가 임의로 매번 이러한 도식과 표를 작성하게 되면 전체 제안서의 통일성이 문제

         . 그림과 도식을 구상하느라 시간이 많이 소요

      - 제안서 표준 템플리트와 도식을 제안서 작성 팀원 모두가 공유하게 되면 시간적인 절약은 물론 제안서의 통일된 이미지

         구축을 통한 품질의 균일한 향상을 도모

      - 대형 SI 기업은 템플리트와 도식을 적극적 활용으로 일반화

         . 템플리트가 보편화 되지 않은 상황이라면 제안서 작성 초기에 제안팀에서 미리 정의하여야 할 것

         . 도식의 표준 샘플과 표의 표준 양식은 물론 제안서에 사용하는 색상 표준, 폰트 표준, 각 레벨의 표제 형식 및 단락의

           표준 등이 정의
      - 다음 그림은 제안서의 표준 템플리트 예제이다. 전체 제안서의 내용 구성은 그림과 같이 제목과 도식 및 도식을 설명하

        는 글로 구성된다. 도식을 설명하는 글을 리딩 메시지(leading message)라고도 하는데 리딩 메시지의 역할은 도식에서

        표현하고 있는 내용을 함축적으로 전달하는 것이다. 리딩 메시지는 각 페이지마다 5줄 내외로 기술되는 것이 바람직하

        며 내용 중에서 특히 강조하여야 할 1~2가지 포인트는 굵은 폰트체로 처리하여 강조한다.

제안서 표준 템플릿 예제 1

제안서 표준 템플릿 예제 2

   8) 유사한 부문의 제안서 및 타 업체의 제안서를 가능한 많이 참조하라.

      - 제안서 작성에 필요한 내용은 각 제안서마다 30%정도는 유사

      - 주로 회사소개, 방법론 소개, 추진 계획 및 일정의 주요 부분 등은 기존 제안서의 내용을 많이 재활용할 수 있는 부분

      - 제안서의 핵심 부분이라 할 수 있는 기술부분도 기존의 유사한 분야에 대한 제안서를 활용할 경우 매우 유용
         • 제안서의 전체 구성이나 목차는 제안 요청서에서 공통적으로 요구하고 있는 내용들로 구성되어 있어 재활용 시 유용

           한 부분이 많기 때문

         • 기존 제안서의 활용에서 가장 조심하여야 할 점은 마구잡이 식 복사-붙여 넣기는 때로 제안서의 내용에 어울리지 않

           는 내용을 포함하게 될 수 있을 뿐만 아니라 최악의 경우 다른 제안서에 포함된 고객사 명이나 시스템 명을 제안서에

           그대로 포함할 수 있다. 이것은 제안서의 작성에 있어 가장 치명적인 실수

         • 기존 제안서나 다른 제안서를 활용할 때에는 내용을 복사하기보다는 항상 다시 작성한다는 마음가짐으로 사용

      - 제안서 작성 시 타 업체의 제안서 작성에 대한 정보를 입수할 수 있다면 매우 귀중한 정보가 되겠지만 자칫하면 기업간

        분쟁이 발생할 수 있으므로 주의

         • 지난 제안서를 활용하는 것은 큰 문제가 없을 것이므로 경쟁 업체의 기존 제안서를 입수할 수 있다면 이를 최대한 분

           석하는 것은 도움

   9) 제안요청서와 제안서의 조견표를 만들고 철저히 검토하라.

      - 제안서는 평가를 위해 작성하는 문서이고 제안서 평가는 대부분의 제안요청서 공지 시 평가 방안이 함께 공지되는 경우

        가 많다.

      - 제안서가 어느 정도 완성되어가는 시점이 되면 제안팀에서는 제안요청서를 기준으로 제안서 평가 조견표를 작성

         • 제안서 평가조견표에는 제안서 평가 기준에 의거한 평가 항목 및 점수 배분율을 표시하고 각 평가 항목에 대한 세부

           사항을 제안요청서에 기술된 내용을 중심으로 하나의 표로서 작성
         • 표 항목에는 평가항목, 주 평가기준, 세부 평가기준, 해당 항목에 대한 제안요청서 페이지, 해당 항목에 대한 제안서 기

           술 내용 요약, 제안서 해당 페이지 등으로 구성

         • 조견표에는 제안요청서 상에 기술된 모든 내용을 빠짐없이 검토하여 제안서에 반영하여야 할 항목들을 나열하고 이

           를 주 평가항목의 분류에 따라 정리한 뒤 다시 평가기준의 주 항목 및 세부 항목으로 나누어 표에 기록

      - 작성된 제안서에서 평가기준에 해당하는 내용이 기술된 페이지를 찾아 이에 대한 대응 내용을 요약, 기록하고 해당 페이

        지를 기록
         • 이 과정을 통해 제안서 작성 시 미처 대응하지 못한 제안요청서 상의 요구사항을 찾아낼 수 있으며 제안서의 내용

            이 제안요청서의 요구사항을 어떻게 대응하고 있는지 일목요연하게 확인할 수 있다.

         • 일부 제안요청서에는 공식적으로 제안요청서 대비 제안서 조견표를 제출하도록 요구하는 경우도 있으므로 조견표는

            반드시 꼼꼼하게 작성

         • 제안서를 여러 협력 회사에서 분야별로 나누어 작성하는 경우에는 제안서 조견표를 통해 제안요청서 항목 중 모든 참

           여 회사가 작성하지 않은 누락 부분을 확인할 수 있으며 같은 제안요청서 요구사항에 대해 다른 방안을 제안한 중복

           제안 부분도 확인할 수 있으므로 꼭 철저히 검토

제안서 조건표

   10) 제안평가자의 입장에서 최종 점검하라.

      - 제안서의 내용도 다 작성되었고 제안서 조견표도 작성이 완료되었다면 제안서와 제안요청서를 바탕으로 작성된 내용에

         대해 제안 평가자의 입장에서 최종 점검이 필요

      - 제안평가자의 입장에서 각 부문별로 작성한 담당자 이외의 인원으로 하여금 다른 사람이 작성한 제안서에 대한 제안요

        청서 대비 검토를 실시

        • 제안평가자가 쉽게 이해할 수 있도록 작성되었는가?

        • 제안의 내용이 구체적인가, 제안서의 리딩 메시지와 도식간에 모순은 없는가?

        • 제안 평가기준에 부합하는가?

        • 제안 요청서에서 요구한 내용 중에 최종적으로 잘못되거나 누락된 부분은 없는가?

      - 영업 담당자가 제안 평가자 명단을 입수하였다면 제안평가자의 특성을 반영하여 검토하면 더욱 완벽한 검토가 될 것

   11) 사소한 오탈자, 제본 실수에 주의하라.
      - 제안서의 내용에 대한 최종 점검이 완료되면 이를 출력하고 복사, 제본하여 제출하는 일이 남아있다.

      - 대형 SI 기업은 자사와 전문적으로 협력하는 복사 업체를 보유하고 있어 해당 업체에 맡기면 인쇄에서 복사, 제본까지

        완벽하게 수행

         • 아무리 깔끔하게 인쇄되고 제본되었다고 해도 내용에 오탈자가 있거나 제본상에 실수가 있다면 제안서를 검토하는

           입장에서 옥의 티가 될 수 있다.

         • 내용에 대한 점검이 완료되면 가능한 여러 사람을 동원하여 최종적으로 내용에 대한 오탈자 점검을 실시
         • 복사업체에 제안서 파일을 전달하고 기다릴 것이 아니라 복사업체에서 함께 제본 내용을 확인하고 잘못된 경우 바로

           조치

         • 여러 번 검토할 때 발견되지 않던 오탈자가 보이는 경우 별도의 정오표를 첨부할 수도 있으나 심각한 문제가 아닌 경

           우에는 굳이 정오표를 배포하여 눈에 띄게 할 필요가 없을 수도 있다.

         • 내용이 제안서에 중요한 부분이거나 또는 일정, 금액, 요구사항의 수행에 관련된 부분이라면 반드시 정정하고 이를 제

           안서상에 스티커 등으로 덧붙이거나 정오표를 첨부
      - 제안서의 작성 시 작성기간의 후반부에 중요한 내용이 수정, 추가되었다면 이 부분과 관련된 부분에 대한 집중적인 오

        탈자 확인 및 내용 점검이 필요

         • 후반부에 제안서의 내용을 변경하거나 새로운 내용을 추가하게 되면 전체 제안서의 내용이 흐트러질 가능성이 높고

           급한 마음으로 작성하다 보면 오탈자가 많이 발생하기 때문

2.3.4 제안 비용의 산정

   - 하드웨어 및 소프트웨어 솔루션의 납품의 경우 구입한 금액이 명확하므로 이에 대한 비용 산정이 어렵지 않다.

   - 소프트웨어 개발의 경우 전체 개발 비용을 산정하는 것은 오랜 개발 경험을 필요

      • 고객이 요청한 소프트웨어의 요구사항을 제안서를 통해 세부 구현 기능으로 정의하면 이를 기반으로 전체 소프트웨어

        개발 비용을 산정하는데 여기에는 '정보통신부 고시 소프트웨어 사업대가의 기준'을 적용

      • 무형의 지식과 노동력을 소프트웨어 개발의 기본 비용으로 산정해야 하므로 국가에서 정한 원칙이 없다면 지나친 부풀

        림이나 또는 덤핑이 가능하기 때문
      • 사업대가 기준은 거의 매년 정보통신부 산하 소프트웨어 산업 연합회에서 공고하며 정보시스템의 구축에 소요되는 시스

        템 분석, 설계, 개발 및 테스트 전 과정은 물론 데이터 입력, 멀티미디어 자료 작성 및 편집 등 컨텐츠 작성에 소요되는 세

        부 작업내역에 대한 표준 단가표를 제공

   - 다음은 소프트웨어사업대가의 기준을 요약한 표이다.

■ 소프트웨어 사업대가의 기준
   1) 소프트웨어 사업비란 소프트웨어 개발비, 시스템운용 환경 구축비, 데이터베이스 구축비, 자료입력비, 정보전략계
       획 수립비 등을 말한다.
   2) 소프트웨어 개발비, 데이터베이스 설계비는 직접인건비, 제경비, 기술료 및 직접경비의 합계액으로 산정
      - 직접인건비 : 한국소프트웨어산업협회에서 매년 조사, 발표하는 소프트웨어 노임단가를 기준으로 작업에 소요되
                         는 인력의 등급과 인원수에 따라 계산한 순수 인건비, 직접인건비의 계산을 위해서는 소프트웨어의
                         전체 본 수와 스텝수를 산정하고 프로그램 유형별 난이도를 감안하여 전체 소요인력을 man/month
                         기준으로 산출
      - 제경비 : 턴키 방식의 일괄계약방식의 경우 직접인건비의 110%, 인력지원방식인 경우에는 직접인건비의 100%,
                    적정 수행기간보다 개발기간을 단축할 경우 추가로 3~10% 제경비 추가
      - 기술료 : 직접인건비 + 제경비 합산 금액에 20%, 품질보증기준 적용 및 개발 방법론 적용 시 각각 10% 비율 추가
      - 직접경비 : 프로젝트의 수행에 소요되는 출장비, 자료인쇄비 및 기타 직접 경비
   3) 시스템 운용환경 구축비, 데이터베이스 제작비, 정보전략계획 수립비 등은 총 비용을 일괄 산정
   4) 기타 자료입력비는 직접인건비와 제경비 및 이윤을 합산하여 산정
                                                                          <참고 : 정통부고시 소프트웨어사업대가의 기준 2003-14호>

2003년도 소프트웨어 노임단가 예

기술자 등급 부분 기준표(기술자격 기준)

기술자 등급 구분 기준표(학력 경험 기준)

   - 소프트웨어 개발 비용의 산정에 대한 자세한 절차와 내용은 정통부 홈페이지나 한국소프트웨어산업협회 홈페이지
     를 방문하여 '소프트웨어사업대가의 기준' 자료를 참조하면 상세히 알 수 있다.
   - 소프트웨어 개발비용의 산정은 제안요청서의 내용을 기준으로 정확한 개발대상 소프트웨어 규모를 산정하는 것으로 부터

      시작하기 때문에 소프트웨어 개발에 경험을 많이 보유한 인력이 필요

      • 유사한 정보시스템을 구축한 경험을 보유한 경우에는 보다 정확한 시스템 규모 산정이 가능

   - 2003년 상반기에 기존의 시스템 볼 수 및 스텝 수 등 소프트웨어의 양적인 규모를 기반으로 소프트웨어 개발비를 산정하

     는 방식이 오래된 정보시스템 개발 환경에서 비롯되어 인터넷 및 객체, 컴포넌트 기반의 새로운 정보시스템 개발 환경에는

     적합하지 않다는 의견이 대두되어 소프트웨어의 기능요소에 의한 개발비용의 산정으로 변환하려는 움직임이 있다.

      • 새로운 소프트웨어사업대가의 기준에 의거하여 소프트웨어 개발비용을 산정해야 할지도 모르겠다.

      • 소프트웨어 개발비용의 산정이 완료되면 제안서에 포함된 하드웨어 시스템과 외부에서 구매하거나 또는 자체적으로 개

        발한 패키지 형태의 소프트웨어 비용을 제안 가격에 포함

   - 하드웨어 시스템이나 소프트웨어 패키지의 경우에 반드시 제안 요청서에서 요구하는 무상유지보수 기간 및 조건에 대한

     검토를 수행하여 여기에 필요한 인력 및 자재비를 감안하여야 한다.

   - 제안요청서 또는 제안서에서 언급하고 있는 교육이나 해외 벤치마킹 등에 소요되는 비용과 외부에 아웃소싱을 하여야 하

     는 관련 비용을 모두 포함하면 전체 제안금액이 산출

프로젝트 개발비용 산정 절차

   - 원가분석에 의한 1차 제안 금액이 산출되면 입찰 전략에 따라 수시로 제안가격에 대한 시뮬레이션을 실시하며 입찰단계에

      서 제안가격이 최종 확정되어 제안된다.

2.3.5 제안서의 제출과 심사

   - 제안서의 작성이 완료되면 제안요청서에서 요구하는 부수와 제출 형태를 갖추어 우편 또는 직접 발주처에 제출

   - 제안서의 작성은 마감시한을 앞두고 여유 있게 완료되는 경우가 거의 없기 때문에 대부분 시간에 쫓기듯이 제출하게 된다.

      따라서 다음의 사항을 꼭 점검한다.

      • 제안요청서에서 요구하는 제안서의 부수 및 제본형태는 올바르게 되어 있는가?
      • 가격제안이 포함된 경우 제안가격의 금액은 정확한가?

      • 제안서가 여러 권으로 구성된 경우 부수가 세트 별로 정확한가?

      • 제안서 제출 마감 시한을 정확히 알고 있으며 제출할 곳의 위치를 정확히 알고 있는가?

        (지방의 경우 제출하러 가는 중에 불의의 사고가 발생할 수도 있으며 위치를 정확히 모를 경우 제출 마감 시한에 늦을

         수도 있음)
      • 제안서 제출 시 제출하는 사람이 가져가야 할 증명 서류가 있다면 이를 완벽하게 챙겼는가?

        (어떤 제안요청의 경우에는 제안서 제출자가 위임장 및 재직증명서를 제출할 것을 요구하는 경우도 있음)
   - 제안서 제출이 완료되면 이제 발주처에서 제안서의 기술심사 및 가격심사를 통해 우선협상 대상자 또는 최종 사업자를 선

      정, 발표하는 일이 남아있다.

   - 제안서의 제출 이후 가격 분리 입찰의 경우에는 자사와 경쟁사들의 제안서 결과 점수를 파악하여 가장 최적의 금액을 산출

      하여 가격 제안을 해야 하는 경우도 있으며 제안 발표가 필요한 경우에는 경쟁사 제안 내용을 사전에 입수하여 제안 발표

      시 적극적인 보완 자료를 작성할 필요가 있다.

   - 제안서의 심사 및 최종 사업자 선정 방식에는 이와 같이 몇 가지 대표적인 방법이 있다.

2.3.6 협상에 의한 계약 방식

   - 협상에 의한 계약 방식은 기술심사와 가격심사 점수를 합산하여 평가한 뒤 가장 우수한 성적을 받은 업체부터 우선적으

      로 협상에 들어가 계약을 추진하는 방식

   - 발주처에서는 초기 프로젝트를 발주할 때 전체 수행 예산을 산정하고 이를 바탕으로 실사를 실시

      . 자체적인 실사를 통해 전체 프로젝트 수행에 소요되는 예산을 확정한 뒤 이를 제안요청서와 함께 공고
   - 제안사는 제안서와 가격 내역서를 작성하여 발주처에 제출하며 발주처에서 이를 심사

      . 심사는 보통 기술심사와 가격심사로 나뉘며 100점 만점에 기술이 80점 내외, 가격이 20점 내외의 비율을 차지하나 발주

        처마다 고유한 비율로 변경할 수 있다.

      . 신기술의 적용이 필요하거나 프로젝트 수행이 용이하지 않다고 판단되는 경우 기술점수가 높게 배정되며 일반적인 내용

        이어서 수행이 어렵지 않다고 판단되면 가격점수가 높은 비율로 배정
   - 기술 및 가격 심사에서 가장 높은 점수를 획득한 업체를 우선협상 대상자로 지정하고 해당 업체와 최종 가격 및 계약 조건

      에 대한 협상을 시작

   - 우선협상 대상자로 지정된 업체가 최종사업 수행자로 결정되나 간혹 협상 과정에서 결렬될 경우가 발생할 수 있으므로 통

      상 2위와 3위 업체를 발표하여 만약의 경우 2위 또는 3위 업체로 협상을 전개할 수 있도록 준비
   - 협상과정에서는 제안서에서 제시한 내용에 대한 검증 및 각 제안 제품에 대한 가격 및 사양 검토를 실시하며 제안서 제출

      시에 제출한 가격에 대한 협상도 수행

   - 협상에 의한 계약방식은 기술적인 면에서 높은 평가를 받은 업체를 비교적 유리한 입장에서 가격 협상을 벌일 수 있으므로

      프로젝트 수행에 필요한 충분한 금액으로 계약할 수 있다.

   - 가격의 과다한 경쟁을 사전에 방지할 수 있어 덤핑 수주에 의한 프로젝트 수행의 부실을 비교적 양호하게 방지할 수 있는

      계약 방식

2.3.7 2단계 경쟁입찰(최저가 입찰) 방식

   - 발주처에서 필요로 하는 시스템에 대한 객관화된 성능치를 평가할수 있는 경우 정해진 수준의 조건을 만족하는 제품을 제

     안한 제안사를 1차로 선정한 후 그 중에서 최저의 가격을 제안한 업체에게 최종 사업권을 주는 방식
   - 국가 공공 프로젝트와 민간 프로젝트에서 그동안 많이 채택되었던 방식으로 '1원 입찰' 의 폐단을 가져오기도 하는 방식

   - '1원 입찰' 이란 최저가 입찰방식에서 최소 입찰 단위가 1원 단위로 되어 있을 때 가장 최저가인 1원을 제안가로 제출하여

      무조건 수주를 하고 보는 방식

      . 1원 입찰'이 나타나는 경우는 후속사업의 규모가 현 발주 프로젝트와는 비교할 수 없이 크면서 현 프로젝트를 수주한업

        체에게 유리한 면이 많은 경우에 발생 → 시범사업이나 국가핵심 사업의 경우가 많다.

      . 아무리 후속사업을 기대한다고 해도 '1원 입찰'은 중소규모의 SI 기업에게는 치명적인 타격을 주는 경우가 많다.
      . 대기업의 경우 출혈경쟁을 통한 수주의 우선권이 있으나 중소기업에게는 정당한 기술개발과 노력에 대한 대가를 받

       을 수 없게 하는 면이 있기 때문

      . 국가적으로 최저가 입찰 방식을 지양하고 기술평가에 의한 우선협상 방식이나 또는 최적가 입찰 방식 등을 택하는 것이

        바람직

2.3.8 최적가 입찰 방식

   - 최적가 입찰 방식은 최저가 입찰 방식과 동일하게 2단계에 걸쳐 수행

   - 차이점은 기술평가를 통과한 상위 몇 개의 업체의 제안 가격을 비교하여 발주처에서 사전에 선정한 예상 가격에 가장 근접

     한 가격을 제출한 업체가 최종 사업자로 선정되는 방식

      . 이 방식은 무조건 최저가로 입찰가를 제출하는 방식과는 달리 적정한 이윤을 보장

   - 보통 발주처에서 예정가격을 정한 뒤 예정가격에 85%에 가장 근접한 금액을 제출한 업체를 선정한다는 식으로 진행

      . 만약 발주처의 예상 가격을 사전에 알게 되면 어떻게 될까? 이러한 사전 담합을 방지하기 위해 발주처에서는 사전에 복

        수의 예정가격을 산정한 뒤 이를 추첨을 통해 몇 개의 가격을 고르고 이들 가격의 평균가를 예정가격으로 하는 방식을

        많이 취한다.

2.3.9 프로젝트 수주를 위한 멀고도 험한 길

   - 수개월에서 일년이 넘게 공들인 영업이 수주에 실패하는 경우가 비일비재

   - 성공적인 수행이 어렵고 힘든 과정임에는 분명하나 그 이전에 프로젝트의 수주가 없다면 모든 것이 의미가 없다.

      . 그만큼 SI 프로젝트 영업은 중요한 것임에 틀림없다.
   - 사전영업에서 제안요청서 작성 그리고 제안서의 작성 및 제출까지 이미 SI 업체에서는 많은 비용을 투자한 상태

      . 이러한 비용에는 사전영업 및 제안서 작성, 인쇄 및 제본 등에 소요된 직접경비는 물론 이를 위하여 투입된 인건비까지

        포함하게 되며 국가대형 SI 프로젝트의 경우 이렇게 제안단계까지 투입되는 비용이 수 억원 이상 소요되는 경우가 드물

        지 않다. 이렇게 많은 투자를 하는 기업이 대형 프로젝트의 경우 최소 3개사 이상은 되므로 최소 3대1 이상의 경쟁을 거

        쳐야 하는 것이다.
   - 국내에 손꼽는 대형 SI 기업으로는 상위 5~6개 기업이 있으며 이들 SI 기업은 국가적인 대형 프로젝트에는 거의 빠지지 않

      고 제안에 참여하고 있는 셈

   - 치열한 영업 경쟁을 피하기 위해 초대형 국책 사업의 경우에는 컨소시엄을 구성하기도 한다.
   - 컨소시엄은 두 개 이상의 기업이 협력하여 공동으로 SI 프로젝트의 영업 및 제안 작업을 수행하는 것으로 한 기업이 모

      두 감당하기엔 금액이 너무 크거나 또는 위험이 너무 클 때 선택

   - 발주처에서 하나의 기업에게만 프로젝트를 발주하기에 부담스러운 경우 채택하기도 하며 국내 업체만으로는 어렵다고 판

     단할 경우에 외국의 전문 기업을 컨소시엄에 포함하도록 제안요청서에 요구하는 경우에도 컨소시엄의 구성이 가능

   - 컨소시엄을 구성하게 되면 컨소시엄 구성 회사들은 전체 프로젝트에 대한 지분율을 정하게 된다.
      . 전체 프로젝트 금액에서 각 참여사가 담당하게 될 영역에 대한 금액 비율을 사전에 결정하여 프로젝트에 대한 위험을 분

        담

   - 하나의 컨소시엄은 이를 대표하는 컨소시엄 대표사가 선정되며 전체적인 계약과 총괄 책임은 컨소시엄 대표사가 가지게

      된다.

      . 이렇게 구성된 컨소시엄이 수행하는 프로젝트의 경우 수행과정에서 간혹 컨소시엄 구성 회사들 간의 분쟁이 발생하여

        프로젝트가 원만히 수행되지 못하는 경우가 발생하기도 한다.
   - 국내 SI 프로젝트의 경우 대부분의 대형 SI 프로젝트는 앞서 언급한 몇몇 대형 SI 기업의 몫

      . 사전영업 단계에서부터 제안서 작성까지 모든 과정을 이러한 대형 SI 기업이 단독으로 수행하는 경우는 많지 않다.

   - 대부분의 경우 사전영업과 제안서 작성단계에서부터 전문 기술을 보유한 협력사와 함께 작업을 수행하게 된다.
   - 때로는 사전영업을 수행하고 프로젝트 수행에 필요한 기술력을 보유한 업체의 경우 발주처가 대형 SI 기업을 선호한다

     는 이유나 입찰에 참가하는 기업에 대한 자격조건 등으로 인해 대형 SI 기업과 함께 협력하는 경우도 있다.

      . 이 경우 실질적인 작업은 제안에 참여하는 협력사가 많은 부분을 수행하였음에도 불구하고 최종 계약자로 나서는 것은

        대형 SI 업체가 된다.
      . 이러한 관행은 대부분의 건설 및 토목 분야의 입장에서 보면 오래된 현상들이다.

      . 차이점이라면 SI 프로젝트의 경우에는 IT 분야의 사업을 수행하는 것이므로 기술 중심적인 면이 많아서 특화된 솔루션을

        가지고 있는 업체라면 SI 프로젝트에서 대형 SI 업체와 대등한 관계를 형성할 수 있다는 것

      . 대부분의 경우 원청기업 (최종 고객과 직접 계약을 한 기업, 대형 SI 기업이 해당된다)과 하청기업의 관계는 우리나라의

        계약 관행상 상하 관계로 굳어지는 경우가 많아 중소 SI 기업의 경우 나름데로의 어려움이 있다.

   - SI 프로젝트에서 협력 업체는 사전영업에서 제안서 작성, 프로젝트 수행 단계까지 SI 프로젝트의 모든 단계에서 사업에 참

     여

   - 사전영업의 경우 발주처에 대해 특별한 관계를 가지고 있는 업체가 대형 SI 업체와 협력할 수 있으며 제안서 작성이나 프

      로젝트 수행 단계에서는 해당 SI 프로젝트에 필요한 특화된 솔루션 또는 전문 인력을 보유한 업체가 함께 협력

   - 대형 SI 기업의 경우에는 동시에 여러 개의 프로젝트 영업을 추진하기 때문에 기본적으로 년간 어느 정도의 프로젝트 수주

     가 이루어지나 협력 업체로 참여한 중소 솔루션 기업의 경우에는 해당 프로젝트의 수주 여부가 기업의 경영에 매우 중요한

     요소

   - 협력업체의 활용도가 높은 프로젝트 분야로는 신기술이 필요한 SI 프로젝트나 범용 기술 분야가 아닌 특화된 전문 분야의

      기술을 필요로 하는 프로젝트들

   - 중소 솔루션 기업의 경우 이러한 프로젝트의 사전 영업에서 제안서 작성까지 소요되는 비용이 상대적으로 부담이 크다.
   - 프로젝트 수주 이후에는 계약 단계에서 대형 SI 기업으로부터 일정부분의 이익을 제외한 금액으로 하청 계약을 맺게 되

      는 것이 관례화 되어 있어 프로젝트 수행에 따른 이익율이 저하되는 경우도 있다.

   - 국내 SI 산업의 발전과 IT 기술력의 발달을 위해서는 이러한 전문 솔루션기업에 대한 국가 프로젝트 직접 참여의 길이 보

      다 더 넓게 열려야 하겠지만 프로젝트 수행에 따른 위험부담과 수행능력 등을 감안하여 대형 SI 기업을 선호하는 분위기

      는 쉽게 바뀌지 않을 것이다.

   - SI 프로젝트의 영업은 시간과의 싸움이다. 짧으면 3개월 길면 3년씩도 소요되는 지루한 사전영업과 수많은 인력이 밤새

     워 작업을 하는 제안서 작성기간을 모두 견뎌낼 수 있는 영업력과 자원 및 투자 여력이 있어야 한다.

      . 이렇게 오랜 기간 고생과 투자를 하고도 결국 최종적으로 프로젝트를 수주하는 기업은 1등 기업뿐인 현실을 감내할 수

        있어야 한다.