RFP 작성하기

아래는 LMS LCMS 강의 중, RFP 작성에 관한 내용을 정리한 것입니다.
강의 들으면서 정리하다보니, 유용한 정보인 듯 하여 공유해봅니다. 
저는 중소기업 다니며 프로젝트 따내느라 제안서 쓰는 일은 좀 해봤지만, 
그보다 중요한 뿌리는 한 발 앞서 있는 제안요청서라는 것을 느끼게 됩니다.  
조근 조근 잘 강의해주신 김순기 교수님께 캄싸~~~    
 
RFP란 무엇인가?

Request for Proposal, 제안 요청서.

발주 기관이 SW 사업을 성공적으로 수행하기 위해 입찰 공고를 통해 입찰대상자들에게 발주자의 요구사항을 알리는 문서.

발주 기관 내부에서 발주 계획서가 먼저 작성될 것이다. 이를 기준으로 제안요청서를 작성하고, 입찰공고를 하여 최초로 발주 행정행위를 하는 데 사용된다.

제안서 작성 및 평가의 기준이 되고, 프로젝트 수행 이후, 사업에 대한 검수 기준이 된다.

그러면 이 사업을 따내고 싶은 업체들은 RFP의 요구사항과 기준을 충족시켜 성공적인 프로젝트를 수행할 방안을 제안하게 된다.

제안서를 기반으로 최적의 업체가 선정되고 발주하여 계약 이후 프로젝트가 수행되게 된다.

 

SW 사업의 프로세스

 

발주 à 공급 à 개발 à 운영 à 유지보수

. 발주 세부활동 : RFP 작성, 제안서 평가, 계약 및 변경, 공급자 관리, 인수, 종료.

. 공급 세부활동: RFP를 검토하여 제안서를 작성, 계약 및 변경, 사업수행계획 수립, 실행 및 통제, 검토 및 평가, 납품, 종료.

. 개발 : 위의 공급 활동의 일부로, 요구사항 분석, 설계, 구현, 시험, 적용, 인도하는 활동.

. 운영 : 요구사항에 의해 공급된 시스템을 운영하여 사용자에게 서비스를 제공하는 활동.

. 유지보수 : 공급된 SW 제품을 발주자에게 인수하고 난 후 수정 및 보완 작업.

 

RFP의 구성 요소

1.     입찰 공고문

2.     제안 안내서 : 사업 목적, 제안 안내, 작성 요령, 서식.

3.     기술 제안 요청서 : 구체적인 내용을 밝혀 참여 기업이 기술적인 구체적인 내용을 제안하도록 알리는 문서. 참여자 입장에서 최종적으로 산출해야 할 목표 시스템이 무엇인지, 자원과 시간이 얼마나 들지, 어떤 기술력이 필요한지를 구체적으로 판단할 수 있는 근거가 된다.

 

RFP의 주요 내용

1. 제안 안내서 : 사업 개요(내용, 기간, 예산), 입찰 참가자격, 입찰 및 낙찰 방식, 계약 조건, 입찰 서류 및 제안서 제출 안내. 제안서의 효력과 제안서 목차, 세부 작성 지침, 서식.

* 예산 선정 방식 : 투입 인력 산정 방식(Man Month)에서 기능점수(function point) 산정방식으로 변화되는 추세.

* 참여 기업 입장에서 프로젝트를 따내기 위해서는 기술평가와 가격평가의 비율, 우선순위에 따라 전략을 세워야 한다.

 

2. 기술 제안 요청서

. 사업 개요 : (특히 기술적 측면에서) 추진 배경 및 필요성, 사업 범위, 정성적/정량적 기대효과.

. 현황 및 문제점 : 업무 현황(업무, 조직 등), 정보화 현황 등. 문제점 및 본 사업을 통한 개선 방향. :::: 이 내용은 참여 기업이 전략을 수립할 때 중요 (AS-IS è TO-BE 제시).

. 사업 추진 방안 : 추진 목표, (기술적/사업관리/표준화/확산 등) 추진 전략, 추진 체계 (연계 기관 및 담당 업무), 일정 (착수보고, 종료 보고, 장비 납품일 등, 일정 별 주요 이벤트 제시).

. 제안 요청 내용 (가장 구체적임) : 제안 요청에 대한 간략한 요약, 목표 시스템 (HW SW 구성도, 아키텍쳐 등), 목표 시스템 상세 (개발대상업무 내역, 구성요건, 도입할 장비, 구성요건, 표준화 요건, 보안 요건, 시스템 운용조건, 교육지원 요건, 기술지원 요건, 유지보수 요건 등 상세히 제시).

 

RFP의 구성 요소별 작성 요령 (주의 사항)

 

* 발주자와 공급자 간에 시각 차이가 크고 법정 분쟁 등이 발생할 때, 판단의 중요한 근거가 되는 것이 바로 RFP이다.

 

1.     요구사항이 명확해야 한다.

. 불명확한 요구사항은 SW 산업 분쟁의 1등 원인. 명확하게 표현하라.

. RFP 작성자가 발주 사업을 잘 이해하고 있어야 한다.

. SW와 HW의 의존성, 분리 발주할 때 그 책임 범위 등을 명확히 제시해야 한다.

. 요구하는 사항에 대해 어떤 결과가 나와야 할지 확실히 명시해야 한다.

. 현재 기술 수준으로 실현 가능한 내용을 제시해야 한다.

. 기술적인 검증이 가능하도록 제시해야 한다.

2.     (검수를 위한) 성능 및 검증 방법을 상세화해야 한다.

. 기능 검증을 위한 절차와 방법을 상술해야 한다.

. 기능의 만족 여부를 평가할 방법을 제시해야 한다.

. 기능뿐 아니라 요구하는 ‘성능’ 및 ‘품질’ 기준을 측정 가능한 형태로 기술해야 한다.

3.     구성 요소의 기술 수준을 명확히 해야 한다.

. 현재 기술 수준을 정확히 분석하고, 기술적 요구사항을 명확히 기재해야 한다.

. 이러닝 분야의 경우, SCORM 적용 여부, 버전, 인증 등급 등을 명확히 제시해야 한다.

4.     개방적인 표준에 근거한 요구조건이어야 한다.

. 표준에 적합한 개발이 대세. 그러나, 그 표준이 실제 필요한지 사업 분석이 필요하다.

. 기술적 요건이 중립적이라면, 특정 기업 제품이나 스펙, 특정 HW, SW 기술을 가진 사업자만 참여할 수 있게 RFP를 작성하는 것은 지양해야 한다. 단, 상호호환성 등의 이유로 꼭 필요한 경우, 그것에 대해 명시해야 한다.

. 표준 스펙 정보에 누구나 접근 가능하고 구현 가능한 개방적인 표준인지 확인해야 한다.

 

5.     관련 법규를 사전에 조사해야 한다.

. 공급자 선정을 위한 관련 법령을 제시해야 한다:

예를 들어, 보통 국가를 당사자로 하는 계약에 관한 법률에 저촉되는 블랙리스트 기업은 불가하므로 이를 확인하도록 밝혀주기, SW 사업 대가의 기준, 사업 규모에 따라 대기업 참여 제한되기도 함.

 

 

참고 사이트 :

. KISA (한국소프트웨어진흥원) : http://www.software.or.kr

. 한국IT서비스산업협회 : http://www.itsa.or.kr

. SW 사업 제안요청서 작성 매뉴얼 : 지경부 (정보통신부/2007.10)