[SI이야기] 제안요청서(RFP) 읽는 방법 - 군산시 공공배달앱 CASE (2)

어제 포스팅에 이어서 오늘은 제안요청서(RFP)의 내용을 하나씩 뜯어보도록 하겠다. 지난 포스팅의 입찰공고문이 도움이 되고 이번 포스팅도 유용한 정보이기를 바란다.

<지난 포스팅>

2020/06/02 - [슈르의 오피스라이프/SI 이야기] - [SI이야기] 제안요청서(RFP) 읽는 방법 - 군산시 공공배달앱 CASE (1)

[SI이야기] 제안요청서(RFP) 읽는 방법 - 군산시 공공배달앱 CASE (1)

 

---

표지다. 제안요청서는 표지부터 살펴봐야 할 정보가 있다. 그건 바로 프로젝트의 이름, 그리고 담당자의 정보다. 프로젝트의 이름은 제안서에 수십 번 적게 될 이름이다. 제안요청서에 오타가 있어도, 띄어쓰기가 틀려도 그대로 적어서 제안서에 적어야 할 정도로 프로젝트명은 절대적이다.

 

그리고 담당자... 놀라운 것은 이 한 사람의 이름, 소속, 전화번호, 이메일이 모두 다 공개된다. 그 이유는 아주 간단하다. 이 사업과 관련한 문의는 이 한 사람에게 연락하라는 것이다. 따로 아는 사람이 있어도, 영업이 있더라도 그건 중요하지가 않다. 여기에 정한 담당자에게만 질문을 해야 하고, 질문자는 정해진 프로세스를 거쳐서 문의 내용에 답변을 해줄 것이다. 그게 개별 답변일 수도 있지만, 경쟁입찰이고 공정성에 신경을 많이 쓰는 회사라면 모든 회사에게 Q&A사항을 일괄 공유해주기도 한다. 어디까지나 고객이 하기 나름인데, 중요한 것은 어느 경우에서든 정해진 담당자에게만 모든 연락을 취할 수 있다는 것이다.

 

목차를 보겠다. 다행스럽게도 이 제안요청서는 목차가 한 장에 다 들어간다.(^^) 심지어 제안 안내 사항을 제외하면 35페이지짜리 제안요청서다. 이 정도면 아주 간단한 수준의 프로젝트다. 물론 제안서를 쓰기 용이하다 용이하지 않다를 논하기는 어렵지만, 그래도 목차가 깔끔한 제안요청서는 제안서도 대체로 깔끔하게 나온다.

 

위의 목차 순서대로 중요한 내용을 하나씩 짚어보도록 하겠다.

 

1. 사업개요

사업개요를 보겠다.

 

1.1 사업명

제안요청서 표지에도 있었던 사업명이 다시 나온다. 만약 제안요청서의 표지와 제안서 안의 내용이 다를 경우 더 간결한 사업명으로 고르거나 나머지 제안요청서에서 더 많이 언급된 사업명으로 적자. 중요한 건 제안서에 사업명을 통일성 있게 적어줘야 한다는 것이다. 여러 명이서 작업하는 거라면 약속을 하고 작업하도록 하자.

 

1.2 사업기간

공고문과 동일하다. 120일(4개월).

 

1.3 사업비

공고문과 동일하게 1.5억 원이라고 적혀있다. 

 

1.4 사업범위

우선 개발해야 하는 내용이 크게 4개인 것을 알 수 있다. 소비자 대상의 『모바일 공공배달앱』, 그 모바일 앱을 관리할 수 있는 『PC용 종합관리시스템 구축』, 사업자가 사용할 『공공배달앱 전용 사업자 지원시스템』 그리고 『공공배달앱 전용 사업자 모바일앱』.

 

여담이지만, 배달의 민족이 한 일이 앱 하나 제공해준 거라고 오해하는 사람들이 있다. '앱 하나 만드는 게 뭐가 어려워?', '앱 하나 만들면 독과점도 막을 수 있는 거 아냐?'라고 생각하곤 하는 것이다. 하지만 이해관계자가 많을수록, 그리고 그 이해관계자가 일하는 환경의 다양성에 따라 상당히 복잡해지는 게 이 사업이다. 이 사업도 앱 하나를 만드는 것 같은 이름이지만 관리용 앱까지 합해서 크게 4개의 앱 또는 시스템을 만들어야 하는 사업이다. 

 

1.5 사업자 선정방식

공고문과 동일하다. 협상에 의한 계약, 기술 평가 기준, 하도급 불허.

 

 

2. 추진배경 및 방향

2.1 추진배경 및 목표

2.2 추진방향

 

이 두 개의 내용은 참여하는 사업자에게 참고하라고 주는 내용이다. 실제로 내부적으로 이렇게 보고가 되었던 사업이라고 이해하는 것이 맞고, 사업을 수행할 때 이 목표가 중요한 영향을 줄 것이다. 실제 이 내용은 제안서에도 유용하게 쓰인다.

 

 

3.추진체계

31. 추진체계

쉽게 말하면 조직도다. 제안하는 우리 회사의 위치가 어디에 있는지 가늠하기 좋기도 하고, 나의 고객이 누가 될지도 알 수 있는 좋은 기회다. 여기 조직도를 보면 용역사업자는 담당부서의 아래에 있고, 협조지원부서와는 직접적 관련은 없는 것으로 나온다. 즉, 담당부서의 말만 잘 들으면 된다~ 정도일까나? 

 

추가 포인트는 담당부서가 Biz. 영역의 부서라는 것이다. IT에 대한 이해가 얼마나 있느냐에 따라 프로젝트가 순탄하냐 아니냐가 결정된다고 생각해도 과하지 않을 것이다. 다행인 것은 이 협조지원부서가 IT부서이기 때문에 여기서 필요한 중재를 해줄 것으로 보인다는 점이다.

 

3.2 주요역할

조직도에 나온 조직별로 역할이 다 있다. 여기에선 예상대로 총괄부서 '지역경제과'가 담당하고 그들의 역할이 나온다. 역시 관리에 대한 내용과 예산. 회계처리와 같은 일이다. 

 

전담사업자가 제안하는 용역사업자다. 역할은 시스템 구축, 보고, 운영자 교육 및 기술이전 등이다. 제안하는 회사가 전형적인 SI회사라면 여기에 적혀있는 일을 수행하기에 어려운 점은 하나도 없어 보인다. 

 

 

4. 주요 사업 내용

4.1 공공배달앱 및 POS 시스템 구축

위에서 적었던 개발해야 하는 내용이 4개의 내용이 다시 나온다. (『모바일 공공배달앱』, 『PC용 종합관리시스템 구축』, 『공공배달앱 전용 사업자 지원시스템』, 『공공배달앱 전용 사업자 모바일앱』.) 

 

4.2 소비자 및 사업자 지원 방안 마련

이건 정확히 시스템 구축의 내용이 아니다. 아래에 적혀있는 내용 중 기능 개발로 처리할 수 있는 부분(포인트 지급)도 있고, 별도 예산과 조직을 편성해서 준비해야 하는 부분(사업자 매장 방문 설치 지원, 전담 CS 조직 구성)도 있다. 이 부분은 제안서를 작성할 때 필요한 부분에 적어두면 좋을 것 같다. 그리고 제안 내용에 따라 별도 예산도 확보할 필요가 있어 보인다.

 

4.3 사업자 고객환원 제도

이 내용은 다 개발 기능 레벨로 처리할 수 있어 보인다.

 

4.4 공공배달앱의 종합쇼핑몰 확장

이 내용은 '향후 확장성을 감안한 시스템이다'를 어디선가 보여줄 수 있으면 되는 내용이다. 실제로 프로젝트에서 향후 확장 방안이나 시스템 구성을 달라고 하는 경우가 생길 수 있다. 이 부분을 가볍게 생각하기만 해선 안된다는 것이다. SI회사의 입장에서 후속사업이 될 수도 있는 중요한 부분이다.

 

 

5. 추진일정

전형적인 SI 프로젝트의 일정이다. 특징은 일정은 언제나 왼쪽에서 오른쪽으로, 위에서 아래로 진행한다는 것이다. 병렬적으로 진행해봤자 1, 2주가 고작이다. 그렇기 때문에 더더욱 이 구조를 잘 숙지하는 것이 중요하다. 모두가 암묵적으로 통용하고 있는 이 형식은 일정을 그리기 위한 대표적인 템플릿이다. PPT에 표를 삽입해서 그리고 셀 서식을 채우면 되는 단순한 구조기 때문에 왼쪽의 추진업무만 정해지면 쉽게 그릴 수 있다. 

 

그리고 M, M+1, M+2... 이런 내용이 있는데, 이건 계약일이 아직 미정이기 때문에 그 기준으로부터 한 달, 두 달 등을 표시하기 위해 쓴다. 월 단위면 M을 사용하고, 주 단위면 W, 일단위면 D를 사용한다. 참고로 프로젝트가 계약일로부터 4개월인데 위의 표는 5개월이 있는 걸 볼 수가 있다. 이는 한주가 5주인걸 감안해서 늘어난 건지, 착오가 있었던 건지 확인이 필요해 보인다.

 

추가로, 보고 일정은 이미 명시가 되어있다. 착수보고, 중간보고, 최종보고. 매월 1회.... 4개월짜리 프로젝트에 월 1회 보고는 다소 과하다는 게 개인적인 생각이다. 착수보고, 중간보고, 최종보고 그리고 주간보고 정도가 부담이 적을 듯하다. 왜냐? 사실 저 표를 보면 월마다 보고할만한 내용이 크지 않기 때문이다. 그저 진행되는 내용에 대한 공유가 필요하다면 주간보고가 더 적합하다. 더 자주 하는 게 이상하게 들릴 수 있지만, 주간보고 없이 월 보고만 할 수는 없다. 자칫 잘못하다간 이슈가 많이 커질 수 있기 때문에 특별한 내용이 없어도 주간보고를 하는 게 낫다.

 

 

6. 제안요청 내용

1. 제안요청 개요

가. 요구사항 구분

나. 요구사항 목록

위의 내용을 일일이 캡처하진 않겠다. 중요한 것은 요구사항 구분이 11가지이고 요구사항 목록은 그 11개를 세분화한 내용이라는 것이다. 

 

2. 요구사항 상세

가. 시스템 장비구성 요구사항

나. 기능요구사항

다. 성능 요구사항

라. 인터페이스 요구사항

마. 데이터 요구사항

바. 테스트 요구사항

사. 보안 요구사항

아. 품질 요구사항

자. 제약사항

차. 프로젝트관리 요구사항

카. 프로젝트지원 요구사항

 

여기에 기술되어 있는 내용이 사실 제안요청서의 핵심이다. 구축해야 하는 시스템의 내용을 가장 자세하게 적어놓은 부분이다. 이 제안요청서의 경우 사전에 컨설팅을 받았을 것 같은 느낌이 들 정도로 구체적으로 정의가 잘 되어있다. (항상 이런 사업을 할 수 있다면 얼마나 좋을까)

 

대표적인 요구사항 하나를 보겠다.

나. 기능요구사항의 내용이다. 

'음식별 카테고리 세부 기능 정의'라는 요구사항 명칭이 있고, 필수로 사업자가 구축해야 하는 기능이다. 세부 내용을 보면 이미 음식의 카테고리를 다 정의해두었고(10가지) 이 카테고리는 GPS에 따라 위치별/음식별/가맹점 상호별로 정렬이 변경된다고 한다. 그리고 기타 등등으로 음식 카테고리를 보여주는 것부터 결제까지의 프로세스를 다 정의해둔 내용이다.

 

사실 이런 내용은 공공기관이나 공개하지 사실 사기업은 제안요청서를 공개하지 않는다. 이는 곳 그 회사의 내부 로직을 다 공개하는 것과 마찬가지가 되기 때문이다. 예를 들면 A회사에서 뭔가 하나 만들 때 RFP를 공개하면, B회사에서 그대로 다 갖다가 쓸 수 있게 되는 것이다. 그래서 사기업 RFP는 전달/복사가 금지되어 있고 이를 적발하게 되는 경우 엄청난 불이익을 받기도 한다. 이전 포스팅에도 적었지만 회사별로 누가 유출했는지 확인하는 별도의 조치가 있을 정도로 민감한 사항이다.

 

기능 요구사항을 이렇게까지 상세하게 적어주는 이유는 뭘까? 간단하다. 이 내용을 읽고 제안서에 각각의 요구사항을 어떻게 구현할 건지 설명하라는 것이다. 아무리 세세하게 정의를 했어도 저건 종이 위의 글일 뿐이다. IT가 그걸 해석하고 설계하는 건 별개의 일이다. 어떤 프로세스로 어떤 구조를 갖고 진행할 건지 제안서에 하나하나 다 작성을 해야 한다.

 

 

7. 제안안내 사항

7.1 입찰안내

협상에 의한 계약이라고 다시 적었다. 입찰일시와 장소는 공고문을 참조하라고 나온다. 공고문의 내용은 어제 포스팅을 참고하기 바란다.

 

7.2 입찰 참가자격 및 S/W납품

가. 입찰 참가자격

나. 시스템 및 컨텐츠

다. 저작권 및 지식재산권

 

같은 이야기다. 대기업은 참여할 수 없고, 해당 사업자여야만 참여할 수 있다는 내용. 그리고 납품 솔루션 및 커스터마이징 비용은 사업자가 부담한다는 것(즉, 사업자가 견적에 충분히 반영을 해야지 나중에 관련 비용을 따로 줄 계획은 없다는 뜻이다.). 저작권 및 지식재산권은 군산시청과 계약상대자가 공동으로 소유한다는 내용이다.

 

사실 개인적으로 흥미로운 내용이다. '공공기업이라서 그런 건가?' 싶은 호기심이 있는데, 사실 사기업 제안요청서에는 모든 저작권 맟 지식재산권이 고객사의 소유라고 명시되어 있다. 개발하고 나오면 무엇하나 우리 회사 자산이 없는데 공공사업은 그렇지 않은 것 같다.

 

7.3 제안서 평가방법

제안서 평가방법이다. 구체적으로 표까지 공개하는 건 공공 제안서는 대부분 그렇고, 사기업은 이렇게 구체적으로 적어서 주는 곳은 없었던 것 같다. PM이나 특정 의사결정자들은 이 표만 하루 종일 쳐다보고 이 표를 기준으로 제안서를 만들고 설명회 PT자료를 만들기도 한다. 당연히 중요한 부분이다. 배점이 크면 그 부분에 집중해야 하는 게 맞다.

 

하지만 이러나저러나... 프로젝트는 기술/기능의 배점이 항상 높고, 결과는 가격에서 결정 나게 된다. ^^

 

 

7.4 제안서 제출안내

주요 내용은 다 입찰공고문 참조라고 적혀있다. 그 외의 중요한 내용을 보도록 하겠다. 

제안설명회에는 PM이 직접 발표를 해야 한다고 명시되어 있다. 이는 제안하고 발표하는 사람 따로, 수행하는 사람이 따로 있는 경우를 방지하기 위한 조치다. 이 조치가 없는 경우 발표 잘하는 사람이 PM을 해서 완벽하게 설명하고 대답을 하는데 실제 수행하는 PM은 아무것도 모르고 들어와서 프로젝트가 어그러지기도 하기도 한다. 발표하지 않을 경우 제안서 서면평가로 진행한다고 하는데 실제 그렇게 놔둔 적은 한 번도 본 적이 없다. 서면을 한다는 건 수주를 포기하는 것 밖에 되지 않는다. 무조건 PM을 찾아서 발표를 해야 한다.

 

참고로 PM이 항상 사업관리자는 아니다. 여기서는 그렇게 쓰였지만 PM 외에 '사업관리'를 전담으로 하는 사업관리 역할의 인력이 따로 있다. 사업관리의 Role이 뭔지는 나중에 시간이 되면 써보겠지만 큰 프로젝트는 둘이 따로 있는 편이다. 작으면 PM이 사업관리도 해야 하기 때문에 통합/일원화된다.

 

7.5 기타 사항

(설명 생략한다)

 

 

7.6 제안서 작성 안내

여기가 나름 하이라이트다. 내용을 아무리 잘 써도 이걸 못 지키면 안 된다. 제안서를 쓰기 시작하기 전에 이것부터 확인해야 한다. 하이라이트 한 내용을 차례대로 보자. 

 

1) 제안서에 작성한 내용은 계약서와 동일한 효력을 가진다.

  PPT라고 즐겁고 예쁘게 썼다가 단어 하나, 화살표 하나 잘못 그리면 계약서에 준하기 때문에 그걸 무조건 지켜야 하는 상황이 발생할 수 있다. '당연히 이게 아닌 걸 알겠지'라고 생각할 수도 있지만 지나친 긍정은 금물이다. 고객은 귀걸이로 만들고 싶으면 그렇게 우길 것이고, 코걸이로 만들고 싶으면 그렇게 우길 수 있다. 절대 여지를 주면 안 된다.

 

2) 제안요청서의 요구 항목들이 제안서의 어느 부분에 기술되었는지 참조표를 제시하여야 한다.

이게 뭐냐? 예를 들어 제안요청서의 요구사항 S001라는 게 있다고 가정해보자. 이 내용을 나는 200페이지 제안서에 잘 써서 고객에게 전달하면, 고객은 그걸 찾는 게 엄청 힘들 것이다. 더군다나 경쟁업체마다 다른 위치에 쓰고 다르게 해석해서 제출을 할 것이기 때문에 이걸 명시해주지 않으면 평가하기가 어려워진다. 이를 위해서 참조표 또는 조견표라는 것을 만드는데 '요구사항 S001이 51페이지에 있다'라는 걸 알려주는 표다. 책을 치면 맨 뒤의 색인과 비슷한 기능을 하는 것이다. 간단할 거라고 생각하기 쉽지만 제안서 마무리할 때 한 번에 만들기도 하고, 틈틈이 만들다가 페이지 엇나가면서 엄청 힘들게 맞춰야 하는 내용이다.

 

3) 제안서 및 요약서는 A4, 3 hole 바인더, 200페이지 이내, 양면/단색으로 인쇄, 종방향 작성

엄청나게 디테일한 작성지침이다. 놀랍게도 거의 모든 RFP에 이런 내용이 있다. 컬러로 인쇄를 해야 하면 그렇게 알려주고, 단색을 좋아하면 그렇게 알려준다. 제안서를 인쇄하는 인쇄소는 이런 내용에 매우 익숙해서 요청 내용을 칼같이 맞춰서 잘해주신다. 

 

참고로 공공기관은 주로 종방향이고, 사기업은 거의 다 횡방향이다. ^^

 

4) 명확한 용어 사용

'할 예정', '할 수 있다' 이런 건 작성하는 사람 입장에선 당연히 할 건데 실제로 한 건 아니니까 '예정'이라고 쓴다든지, 한 번도 해본 적은 없지만 기술적으로 할 수 있으니까 '할 수 있음' 이렇게 쓰는데 그런 표현으로 적지 말라는 것이다. 고객사에서 요청하는 표현은 '구축함', '구현함' 이런 단언/확언의 표현이다. '관리 페이지를 개발함' 이렇게 해야지 '개발할 예정' 이렇게 쓰면 없는 거나 마찬가지로 간주한다는 뜻이다. 조금의 연습만 있으면 어렵지 않은 부분이다.

 

이 역시 거의 모든 요청서에서 동일하게 이야기하는 내용이다.

 

5) 한글작성 원칙

이 부분이 다소 놀라울 수 있을 것 같아서 부연 설명을 조금 하겠다. '한국인데 당연히 한글 아냐!?'라고 생각할 수 있다. 하지만 한국에 들어온 외국계 회사의 제안요청서를 받으면 영어/한글 2부를 작성하라는 요청사항이 오기도 한다. 이는 이들 회사가 한국에 법인이나 지사로 들어와 있기 때문에 어떤 시스템을 구축할 때 글로벌에 보고를 하거나 승인을 받아야 하는 경우가 있다. 아니면 회사 내부적으로 영어 문서 보고가 익숙한 사람들인 경우도 있다. 그런 경우 한영 두 가지를 다 요청하는 것이다. 이런 회사에서 설명회를 하면 어떤 경우에는 두 개의 빔프로젝터로 두 개의 슬라이드를 띄워놓고 PT를 하기도 한다.

 

6) 제안에 소요되는 일체의 비용은 제안 업체가 부담한다.

사실 이게 제안에 있어서 개인적으로 제일 싫어하는 부분이다. 제안요청서를 받아서 제안업체는 인력과 시간을 들여서 제안서를 맞춤형으로 작성하는데 그 모든 비용을 업체가 부담해야 하는 것이다. 인쇄비도 주지 않고, 간식비도 나오지 않는 것이다. 이렇게 요청하고 사업을 안 하겠다고 선언하면 이기는 회사 하나 없이 고객사만 좋은 제안서, SI회사의 내부 자산이나 마찬가지인 정보를 공짜로 다 가져가는 것이다.

 

개인적으로 국민 청원에 올려서라도 돈을 받아야 한다고 생각하지만... 그로 인한 폐해가 걱정되어 (정치인들이 당을 계속 찍어내는 이유와 같은 후폭풍이 예상된다. '일단 제안비용 주니까 아무 제안서나 내자' 이런 식의...) 조용히 있지만. 개선되어야 하는 문화라고 생각하는 바이다. (흥!)

 

 

제안서 목차다.

보통 제안요청서에는 제안 목차가 정해져서 온다. 서로 편한 방법인데 상위 레벨까지만 있으니 하위는 업체별로 자유롭게 구성해서 작성하면 된다. 제안서 목차별로 세부 작성지침도 있는데 이는 직접 열람해서 보는 걸 추천한다.

---

이상으로 붙임을 제외한 모든 제안요청서의 내용을 살펴보았다. (붙임은 주로 작성해서 제출해야 하는 서식들의 템플릿이다. 이력이라든지, 실적이라든지, 회사의 재무성과라든지 등등 양식에 맞춰서 제출하라는 내용들이다.)

 

모든 제안요청서는 이 제안요청서의 긴 버전과 짧은 버전이다. (물론 이렇게까지 깔끔하게 정리된 제안요청서를 받는다면 땡큐지만 아무리 읽어도 뭔지 모르겠는 제안요청서들도 있긴 하다.) 쨌든, 중요한 건 제안요청서 하나를 볼 줄 알면 나머지는 다 대동소이하다는 것이다.

 

제안서는 제안요청서를 정독한 후에 작업을 시작해도 늦지 않다. 정독을 하고, 적절한 제안서 템플릿을 선정하고(여기선 종형에 고객사에서 요청한 페이지 번호 형식 포함), 목차를 뽑고, 세부 목차를 적고, 거기에 작성할 담당자를 나눠서 작업을 하면 된다. 3주를 달리면 제안서와 설명회 자료가 만들어지는 것이다.

 

상당히 어려워 보이고 어쩌면 비효율적으로 보일 수 있지만, 직접 해보면 체계적인 느낌이 들기도 하고 피할 수 없는 부분이라는 생각이 들 때가 있다. 서로 하는 일에 대한 구체화 단계라고 보면 되지 않을까. (그래도 1.5억 들이는 사업인데!)

 

오늘의 포스팅이 앞으로 제안서를 작성해야 하는 사람들에게 많은 도움이 되었으면 한다. (페이지 장수에 기죽지 말자!)

 

 

* 참고 : 슈 과장은 이 사업과 무관합니다. 제안서를 제출한 적도, 사업에 참여한 적도 없습니다. 혹시 이 제안요청서의 내용을 포스팅하는 것이 문제가 된다면 바로 내리도록 하겠습니다. :)