RFP 문서 작성

RFP(Request For Proposal)는 제안 요청서 이다.

이렇게 만들어 주세요 라는 컨셉 정의서 이다.

제안 업체가 제안 참여를 위해서 어떠한 기준에 부합한 지표를 제시하여, 구체적이고 정확히 정리가 되어야 내가 원하는 의도에 맞는 제안을 받을 수가 있다.

RFP 내용에는 4가지가 있다.

1. 개요

2. 구축컨셉

3. 제안요청사항 정의

4. 제안서 작성가이드 정의 

출처 : http://www.yamestyle.com/230

개요

프로젝트 사업명을 정확히 기재 한다.

명명 규칙은 직관적이며, 노멀한 수준으로 작성 한다.

하고자 하는 서비스의 이름이나 형태를 명확히 기재 해야 한다.

형식상으로 의례 넘어가는 부분이나, 실상 RFP 요소 중 중요한 내용이다.

이유는 이 정의를 통해서 '우리가 원하는 서비스는 이러한 겁니다.' 라고 말할수가 있다.즉 목적이 정확하므로, 제안업체에 제안 했을때 단기프로젝트가 될지, 장기 프로젝트가 될지 파악 할수가 있다.

제안시 "왜 만들어야 되는가"를 꼭 이야기 해야 되는가 물어본다면,

돈들여서 왜 만드세요? 라고 반문이 가능하다.

회사가 만드는 이유는 분명 목적이 있을 것이고 이를 통해서 얻고자 하는것이 무엇인지 정의 해주어야 제안 업체가 원하는 목적에 맞게 방향을 잡고 제안 할수가 있다.

예를 들어 목적이 아래와 같다고 해보자.

오프라인 상에서 확고하게 자리 잡은 회사의 브랜드 이미지를 온라인 영역으로 확장하여, 브랜드인지도 및 가치를 확보하고, 대고객 친화적 환경 구축을 통해 " 고객 중심의 기업"이란 부가적 이미지를 심어주는데 그 목적을 가진다.

위 내용에서 주목해야 할 포인트는 아래와 같다.

Point 1. 오프라인에 비해 온라인 인지도가 낮다

Point 2. 고객과의 직/간접적인 접점 필요 하다

이러한 목적이 정의가 되었다면 프로젝트의 방향성 정리가 필요하다.

방향성 정리는 주요 핵심 키워드만을 뽑고, 이 키워드 내에서 전개해 나간다.

예를 들어 "운영관리 최소화" 키워드가 있다면, "관리체계의 자동화를 통해 적은 운영인력의 효율적 서비스 운영체계마련" 으로 정리 하면 된다.

그 다음 프로젝트의 개발 일정을 정리 하면 된다.

앞서 말한 개요가 사업의 정보전달 의미라면, 구축컨셉과 타깃 정의는 언급한 이슈들을 세분화하여, 구체적으로 정리 해준다.

예를 들어 "직관적이고 간결한 사용자 환경 " 키워드를 바탕으로,

사용자가 핵심 컨텐츠를 이용하는데 최소의 클릭으로 목적을 달성 할 수가 있어야 하며, 사용자가 표현 문구를 쉽게 이해할수 있어야 한다. 구체적인 요구사항을 제시하여야 기획컨셉이 명확해 진다.

서비스의 주요타깃은 제안 전에 이미 나와있을수 있지만, 그렇지 않은 경우 사용자 층을 구분하기 어렵다. 이럴떄  만들고자 하는 서비스와 유사한 서비스의 디자인적 분위기나 유사 서비스들의 현황을 살펴보고, 서비스에 근접하는 연령대와 성별을 기재 한다, 가능하면 리서치를 이용하거나, 사전 타깃 조사, 라이프 사이클 조사등도 좋은 방법이다.

레퍼런스 부분은 서비스의 롤모델을 제공함으로, 나아가야 하는 방향을 제시하는 부분 이다.

제안요청 사항 정의는 구체적일 수록 아주 좋다.

만들고자 하는 서비스의 사용자 페이지와 관리자 페이지에 대한 사이트 맵 및 유의사항을 정리 해야 한다.

개발환경에 대한 포괄적인 제안도 받아야 하며, 금액제한을 걸기전에 최적환경을 제안하고 금액을 조율하는것이 좋다.

가능한 원하는 개발언어나 권장서버환경등 가이드라인을 제시하면 좋다.

출처 : http://www.yamestyle.com/230

하자보수 및 교육

차후 하자보수 과정에서 갑과 을의 이견이 발생하지 않도록 세세한 정의와 검토가 필요하다. 일반적인 하자보수 조건은 아래와 같다.

1. 유/무상 기간

2. 범위

3. 장애 발생시 대처 방식과 시간

4. 잘못된 하자 보수로 인한 책임 소지

5. 해당 운영하기 위한 교육 일정 및 가이드 자료의 제출

사전 설정된 하자 보수 기간에 요청 할수 있는 사항은 잘못된 내용에 한하여 가능하지만, 추가적인 개발은 하자보수 범주에 포함되지 않으며, 필요한 경우 충분히 협의가 필요하다.

"하는김에 이것도 해주세요" 에 대한 요소는 추가개발요소일수도 있는 만큼 RFP 작성시 좀더 명확하게 정의하고, 분쟁이 발생하지 않도록 주의 한다.

* 유지보수와 하자보수의 차이는?

 유지보수는 운영의 개념으로 사이트내 발생 하는 서비스 기획, 디자인, 개발 운영을 대행 해줌.

 하자보수는 출시 이후 발생하는 오류를 일정기간동안 개선 해줌.

하자보수에 대한 정의가 마무리 되면 장애에 따른 업체의 대처형태 작성 한다.

즉, 고객이 장애 확인 후, 업체 측에 통보한 시점으로부터 12시간 이내 수정 후 담당자에게 통보와 같이 장애요소 처리 프로세스도 정리 해야 한다.

이러한 가이드 라인이 없거나 명확하지 않을 경우, 의뢰업체와 개발업체간 분쟁이 생길수 있다.

만들어진 사이트의 내부교육 과 메뉴얼 제출을 요청한다.

내부관리자를 대상으로 한 교육 일정과 횟수 그리고 운영에 필요한 내부 메뉴얼들을 제출 요청한다.

기재 내용은 가안의 성격을 지니며, 실 계약과정에서는 변경될수있음을 인지 해야한다. 산출물 제출과 인력 상주 여부 기재 한다. 산출물은 제안서, 착수보고서,주간보고서,완료보고서가 여기에 해당된다. 해당 보고서를 어떻게 받을 것인가 하는 내용을 기재 한다.

제안서는 이렇게 하겠다 문서.

착수보고서나 중간보고서는 각 진척사항을 보고하는 문서.

완료보고서는 기능구현 테스트 여부 체크리스트 정리하며 올바르게 구현 하였다 문서.

파견근무와 같은 상황이 필요한 경우는 분명히 명시하여, 의뢰 회사와 개발회사의 충돌을 피하도록 한다.

제안서 작성 가이드 - 이렇게 작성해서 주세요.

개발업체 측에 "어떤 식으로 제안서를 써야 한다" 에 대한 가이드를 제시한다.

제출일정, 스케줄 기타 등등

예시는 아래와 같다.

출처 : http://www.yamestyle.com/230

그 다음으로 제안서에 수록되어야 할 내용을 정리 한다.

예시는 아래와 같다. 사이트마다 다르지만 대략 아래 내용이 포함 된다.

출처 : http://www.yamestyle.com/230

위는 상당히 러프한 목록이며, 세부적으로 필요한 요건들을 넣어줘야 한다.

위의 제안요건이 정리 된 후 의뢰업체의 제안서 검토 후 평가 항목, 제출된 제안서를 바탕으로 한 선정 기준을 정리 해야 한다.

보통 공기업은 기준이 각 부분별로 정량화되어 있다.

필수항목은 아니며 평가기준을 정량화 하기 어렵다면, 자체평가 기준에 따름과 같이 간략 표기 해도 된다.