16. 성공하는 제안 (2/2)
이왕하는 제안, 제대로 하자!
16.2 제안서, 하나의 작품!
제안환경 분석 및 제안전략 수립이 끝났다면 이제 본격적으로 제안서를 작성할 차례이다. 구체적인 제안작업 계획은 제안팀의 구성(Team Building)과 제안일정 수립으로 시작한다. 제안팀은 사내/외의 가용인원을 최대한 활용하여 가장 적합한 인원들로 구성된 비용효과적인 팀을 구성해야 한다. IT시스템 구축 사업 제안을 예를 들면 사업의 복잡성과 규모에 따라 다를 수 있지만 영업대표 외 제안 PM, 응용소프트웨어 담당자. 인프라 담당자 등 최소 3명이 필요하다.
그림 III-8. 제안 계획
제안 일정은 제안 마감일을 기준으로 현실적인 일정을 수립해야 하며 각 단계별로 마일스톤(Milestone) 관리를 해야 한다. 투입인원과 일정이 수립되면 작업절차도(Work Breakdown Structure: WBS)를 작성하게 되는데 WBS는 작업 활동 및 프로세스, 일정 등이 전체적으로 반영되므로 이를 기반으로 반드시 비용 관점의 점검도 병행해야 한다. 이는 제안에 투입되는 각종 비용을 항목별로 정리하여 제안 종료 후 회계 처리하기 위함이다. WBS 작성까지 끝나면 RFP 분석 결과와 제안전략을 토대로 제안 프레임워크를 개발해야 한다. RFP를 통해 제안 목차가 고객으로부터 주어졌다면 제안 PM은 목차별 제안서 작성 담당자를 확정하고 포함되어야 할 주요 제안 키워드 등을 도출한다. 이는 영업 전략과 연계되어야 하며 셀링 포인트(USP)[1]로 확장될 수 있다. 반대로 목차가 주어지지 않은 제안서를 작성해야 할 경우, 창의적인 목차를 개발하는 것이 좋다. 제안서 전반에 걸쳐 메시지 전달을 위한 일관된 흐름[2]이 중요하며 각 장마다 강조점이 잘 나타나야 한다. 공공 제안의 경우, 정형적인 내용이 많으므로 한번 잘 만들어 놓으면 향후 재사용 가능한 부분도 많다. 이를 위해 제안서를 모듈 별로 잘 정리하여 지식 DB(Knowledge-Base)로 구축하여 활용할 수 있어야 한다. 제안서 작성은 워드나 파워포인트 같이 문서저작 소프트웨어를 많이 사용하므로 적합한 도구를 선정하고 폰트, 서식, 레이아웃, 칼라, 디자인 등을 결정하면 소위 말하는 '제안서 목업(Mock up)'이 완성된다. 단순한 문서 양식인 템플릿(Template)과 제안서 목업을 구분하는 것은 제안서 목업은 앞서 수행된 제안 전략의 내용 및 분석 정보들이 제안 목차에 따라 상당 부분 기술되게 되기 때문이다. 가설기반으로 작성된 것은 영업대표가 확보하는 정보나 사업정보가 업데이트되면서 확정되기도 하고 다른 내용으로 대체되기도 한다. 이러한 제안서 목업의 개발에 가장 큰 영향을 주는 사람은 제안을 주도하고 있는 제안 PM이다. 제안 PM은 해당 사업에 대한 지식과 경험, 통찰력을 가지고 제안의 모든 부분을 이끌어야 한다. 제안 계획이 모두 수립되면 제안서 목업 업데이트와 더불어 본격적인 제안서 작성 작업으로 돌입하게 된다. 스토리보드(Storyboard) 작성은 제안 작성의 좋은 방법이다. 스토리보드가 제안 목차와 같을 경우는 크게 고려되지 않을 수 있으나 제안 목차 자체를 새롭게 만들어야 할 경우는 제안서의 일관된 흐름을 전달할 수 있게 개발해야 한다.
그림 III-9. 제안서 개발또한, 스토리보드를 활용할 수 있다면 그 주요 내용은 제안설명회에서도 매우 유용하게 활용할 수 있다. 스토리보드는 제안의 아이디어를 논리적으로 구성하고 주요 특장점을 정의하여 주제어로 정해서 제안 목차에 반영되어야 하며 중언부언(重言復言)하지 않는 효과적인 문장으로 구성해야 한다. 여기서 효과적인 문장이란, 간결하고 명료한 문장이며 제안서를 읽는 독자를 고려한 문장이고, 논리적이며 정확한 사실을 전달하는 문장이어야 한다. 또한, 시인성(視認性. Visibility) 증대를 위해 차트(그림이나 표)를 삽입할 수도 있다. 그렇게 제안서 초안이 만들어지면 제안 PM을 포함하여 관계자들이 모여 제안서 검토를 한다. 제안서 검토는 일차적으로 오타 수정이라든가 표현이나 문구의 수정 등을 팀원들 상호 간의 검토(Peer Review)를 통해 진행하고, 전략적 측면이나 논리적 측면에서 제안 PM이나 관련 전문가들이 검토해나가는 것이 바람직하다. 제안 검토에 대한 명확한 방향이 사전에 합의되지 않으면, 일하면서 정말 배가 산으로 가기 때문에 신중해야 한다. 일반적으로 제안 검토는 아래 3가지 내용을 포함한다
스토리보드 상의 논리성
셀링포인트의 명료성
제안 구성의 적절성 (특히, Visualization)
제안 리뷰를 효과적으로 진행하기 위해서는 다양한 관점을 고려한 별도의 제안 리뷰팀을 구성하는 것이 좋다. 기업 규모가 큰 경우, 제안서 리뷰를 전문적으로 하는 레드팀(Red Team)[3] 등이 구성되기도 하는데 보통은 제안팀 리뷰와 제3자 리뷰가 진행된다.
o 제안팀 리뷰는 제안 PM이 주도하는 리뷰로 제안서 목업과 스토리보드 리뷰를 중심으로 진행되며
오탈자 수정부터 전체적인 제안 맥락을 제대로 전달하는 것을 목적으로 한다.
o 제3자 리뷰는 지원부서가 객관적인 입장에서 해주는 것이 필요한데 기술부서에서 제안의 내용 중
기술 부분의 오류나 강조 부분을 리뷰하여 보완한다던지 그 외 위험 관리 부서에서 전반적인 제안
이행사항에 대해 점검하고 피드백하면, 제안팀은 사업팀과 협업하여 위험 요인들을 보완한다.
보통, 재무, 법률, 품질 관련 리뷰가 진행된다.
o 사업 규모가 크거나 시장 진입 등을 위한 중요 사업인 경우, 경영진 리뷰가 특별히 있을 수 있는데
이는 보통 손익 중심이나 전략적 판단 차원에서 진행되며 제안의 가치를 잘 전달하는 것이 중요하다.
16.3 제안 제출 및 Wrap up
제안서가 작성되었다면 이제 제안서를 인쇄하고 패키징 하여 고객에게 전달해야 한다.
그림 III-10. 제안 제출제안서를 제작하는 과정은 일종의 상품화 과정과 같다. 수많은 고민이 담긴 파일들을 인쇄하여 책으로 만들어 제출하는데, 현란하기보다는 고객의 입장에서 깔끔하게 잘 정돈된 모습을 심어주는 것이 좋다. 인쇄물의 색상이나 종이의 질 등 인쇄의 품질도 중요하며 제본이나 바인딩의 섬세함도 보이지 않는 역량이다. 그런 이유로 제안 작업을 많이 하는 기업의 경우, 전문 인쇄소와 깊은 파트너십을 가지고 있다. 계약에 준하는 민감한 문서를 인쇄하고 인쇄 후 자료를 파기하고 보안을 지켜야 하기에 신뢰할 수 있고, 합리적인 가격을 제시하는 업체를 선정하는 것이 좋다. 제안서의 가치는 고객이 제안서를 받는 순간부터 경우에 따라서는 두고두고 그 개념이나 의미를 활용하기 위해 곁에 두고 볼 수 있다면 가장 빛날 것이다. 그러나 그렇지 못한 경우 책장 속에서 먼지와 함께 낡아가는 제안서도 많다. 그런 까닭일까 최근 일부 사업에서는 더 이상 제안서를 인쇄하지 말고 CD나 DVD로 제출할 것을 권하고 있다. 종이 낭비를 줄이자는 일차적 취지도 있겠지만 해외사업을 생각해보면 제안의 패턴이 많이 바뀌는 것 같다. 즉, 더 이상 문서를 통한 제한적인 표현을 하지 말고 해당 솔루션을 직접 시연하거나 적용 사례가 있다면 현재 운영 중인 라이브 시스템(Live System)을 보여달라고 하는 고객들도 증가하고 있다. 고객이 시연 현장에서 직접 보고 마음에 들면 사업 수주에 큰 영향을 끼치게 된다. 제안서 마감을 앞두고 최종 점검을 해야 하는 제안 PM은 아래 사항을 확인하는 것이 좋다.
고객의 요구사항이 충분히 반영되었는가?
제안사의 셀링 포인트(Selling Points)는 명확하게 드러나고 있는가?
업무적 관점에서 출발하였는가?
제안의 키워드가 제안서 전반에 지속적으로 언급되고 있는가?
차트(그림이나 표)가 의미 있게 표현되고 있는가?
제안서 내용 중 모호한 표현은 없는가?
제안사가 제시하는 솔루션에 대한 논리적 근거가 설득력이 있는가?
고객 문제 해결을 위한 솔루션은 타당성 있는 모든 대안들이 검토되었는가?
고객 이슈 해결을 위한 대안들은 기술적/업무적/법적 관점에서 타당한가?
제안서 평가 항목에 있는 모든 내용들이 기술되었는가?
제안서 패키징이 끝나면 제안서 제출, 즉 입찰에 들어간다. 앞서 설명한 것처럼 B2B 사업의 가장 큰 특징 중 하 나는 제품의 구매에 있어 입찰(Bidding) 행위가 있다는 것이다. 제안서와 함께 고객이 요구한 실적 자료 등 입찰 서류를 준비해서 기한 내 제출하면 제안 작업은 종료된다. 국내 공공조달 사업은 나라장터(www.g2b.go.kr)를 통해서 이루어진다. 국가종합전자조달 포탈인 나라장터는 국내 공공조달의 모든 업무를 온라인으로 처리할 수 있는 단일 창구(Single Window)로 156개 조달 정보를 연계하여 조달 기업은 별도의 문서, 증빙서류 제출 없이 입찰, 계약, 대금지급 등 전 조달 과정을 일괄 처리할 수 있다.
그림 III-11. 나라장터 입찰 프로세스
IT사업을 예를 들면 특히, 국내 공공IT사업과 해외 B2G 사업의 입찰은 표 III-6과 같이 많은 차이가 있다.
표 III-6. 국내 및 해외 공공 IT사업 입찰방식 비교[4]제안서 제출 후, 방대한 분량의 제안서를 검토하기 전에 전체적인 제안의 아웃라인(Outline)을 알고 싶어 하는 고객의 니즈는 '제안설명회'라는 후속 이벤트를 만든다. 제안설명회 시간은 제안서의 핵심 내용을 강렬하게 인식시킴과 동시에 솔루션이 준비되어있다면 직접 시연할 수 있는 좋은 기회이기도하다. 프레젠테이션(Presentation) 형식을 가지기 때문에 영업 전략을 고려한 제안 프레젠테이션 전략이 요구된다. 제안사의 제품을 구매해줄 고객의 이슈를 잘 파악하고 해결안을 제시했으며, 고객의 심사기준을 잘 반영한 제안서라면 좋은 결과를 얻게 될 것이다. 흔히 제안서를 제출하고 나면 제안팀의 역할은 종료되는 것으로 생각한다. 그러나 제안의 결과가 어떻게 되더라도 반드시 수행되어야 하는 것이 있는데 바로 포스트모템(Postmortem) 활동[5]이다. 포스트모템을 수행하는 주요 목적은 제안이나 프로젝트 종료 후 무엇을 배웠는지 교훈이나 시사점(Lesson learned)를 파악하고 공유하는 것인데 수주한 경우, 그동안의 노력과 고생의 대가로 기쁘게 여러 가지 이야기를 할 수 있겠으나, 실주한 경우 그 원인을 더욱 잘 파악해야 한다. 가장 경계해야 할 것은 실패의 결과가 사람으로 귀결되면 좋은 답을 찾지 못하게 된다. 왜 그런 일이 생겼는지 5번 질문해보고 답을 찾아보자. 이 방법을 통해 실패의 본질에 대해 여러가지 객관적인 입장의 해결안을 발굴할 수 있을 것이고 차기 사업부터는 그런 요인들이 재발하지 않도록 하는 것이 필요하다.
이상으로 제안에 대해서 살펴보았다. 다음 장에서는 B2B 영업의 절정의 순간인 제안설명회, 제안 프레젠테이션에 대해 좀 더 알아보도록 하자.
[1] Unique Selling Points
[2] 많이 사용하는 방법으로 부표(legend) 또는 흐름도를 페이지에 항상 표기하여 현재 읽고 있는 내용이 전체 맥락 중 어디쯤 와 있는지 알려주어 지속적으로 컨텐츠를 머리 속에 그릴 수 있도록 유도하는 방법도 있다
[3] Red Team은 미군의 모의 군사훈련에서 아군을 블루팀(Blue Team), 적군을 레드팀(Red Team)이라 부르면서 유래되었다. 군사적으로 레드팀은 크게 시뮬레이션, 취약점 발견, 대체 분석 등을 진행하므로 기업 경영에서는 특히, 주요 전략이나 사안의 리뷰 시에 반대되는 위치에서 여러 가지를 지적하고 발견하는 역할을 맡게 된다.
[4] World Bank 2 step 국제입찰(기술+가격) 기준
[5] Win-Loss 분석, After-Action Review 등 다양한 이름의 유사한 활동이 있음
Break #21. 포스트모템에서는 무엇을 다루는 것이 좋은가?
포스트모템의 목적은 ‘과거로부터의 경험(Learn from past experience)을 자산화’하는 것이다. 그러기 위해 제안이나 프로젝트의 전 과정을 중요한 단계 또는 순간마다 ‘잘 진행된 부분’ 또는 ‘치명적인 실수가 있었던 부분’ 등을 분석하여 시사점을 공유하고 향후 진행하는 제안이나 프로젝트에서 이를 경험 삼아 일을 보다 효과적으로 진행하고자 하는 것이다. 기업의 사정에 따라 다루어야 할 항목들은 달라질 수 있겠으나 보통 IT 프로젝트의 포스트모템은 다음 항목들을 점검해볼 수 있다. IT시스템 구축 사업을 예를 들어 살펴보면 아래와 같다.
프로젝트 참석자 - 직위보다는 역할별로 구분하는 것이 좋음. 예를 들어 PM, 업무 영역별 리더, 개발자 등
프로젝트 주요 지표 - 프로젝트를 파악할 수 있는 정량적 정보
(1) 프로젝트 기간
- 총 기간 : ### 일 (## 주) ; 프로젝트 작업일 : ###일 (## 주) ; 설계변경 작업일 : ###일 (## 주)
(2) 프로젝트 규모
- Function Points : ## fps ; Lines of Code : #,### loc
(3) 프로젝트 생산성
- Code Density : ## loc / fp ; 일일 생산성 : ##.# fp / day
(4) 프로젝트 ROI (Return On Investment)
- 총비용 : ## 일 x 8시간/일 x 시간당 임금 x 인원수 = 투입금액 ;
단순히 계산할 수도 있지만 기업의 관리 회계 원칙을 반영하면 각종 간접비를 포함할 수도 있음
- 손익분기(BEP) 및 연도별 ROI
- IT 프로젝트 대금은 보통 기성(Earn Value)으로 처리되기 때문에 구축 프로젝트 종료와 더불어 잔금을
받으면 ROI 평가는 종료될 수 있다. 다만, 5년 이상의 장기 구축 프로젝트 또는 운영이 병행되는 10년
이상 프로젝트의 경우, 현금흐름에 대해 잘 파악해야 한다.
(5) 프로젝트 계획
- 프로젝트 내 그룹별 업무 목표는 명확하였는가?
- 설계, 개발, 시험 등 각 단계는 어떤 조건으로 시작하여 어떻게 종료하였는가?
(6) 프로젝트 자원
- 자원은 적절하게 배정되었는가? 과도하게 또는 부족하게 배정되었는가?
- 주어진 자원은 효과적으로 관리되었는가?
(7) 일정계획
- 일정계획은 현실적인가? 마일스톤은 철저하게 준수되었는가?
- 일정관리에서 가장 큰 장애물은 무엇이었는가?
(8) 시험
- 각 단계별 시험 준비는 충실하였는가? (테스트 케이스 또는 시나리오, 도구, 인원 등)
- 시험 결과 에러/수정/재개발 현황은 충실하게 관리되었는가?
(9) 보고
- 이슈 등이 적시에 보고되었는가? 보고 양식과 기법은 효과적으로 정의되었는가?
(10) 조직
- 각 조직을 맡고 있는 리더/파트리더들은 업무를 이해하고 책임을 다하였는가?
- 각 팀 간의 협업은 원활히 진행되었는가?
- 조직 간 협업이 성공적이거나 문제가 있었다면 주요 요인은 무엇인가?
(11) 품질
- 시스템의 최종 품질에 대해 프로젝트 구성원들은 만족하는가?
- 준공된 시스템을 더 개선해야 한다면 어떤 부분을 개선하면 좋은가?
(12) 도구와 방법론
- 프로젝트를 지원하는 도구와 방법론이 업무에 얼마나 도움이 되었는가?
- 개선할 부분이 있다면 어떤 부분인가?
(13) 창의적 제언
- 프로젝트를 종료하면서 각자의 위치에서 제언하고자 하는 것이 있다면 무엇인가?
같이 읽어보면 좋은 책
Shipley Proposal Guide v4.0, Larry Newman, PPF.APMP, 2000
Franklin Covey Style Guide: For Business and Technical Communication, Stephen R.Covey, 2012
Prologue
Part I. B2B 사업, 무엇이 다를까?
1. 왜 B2B 사업인가? (1/2)
1. 왜 B2B 사업인가? (2/2)
2. B2B 마케팅/영업 맛보기 (1/2)
2. B2B 마케팅/영업 맛보기 (2/2)
3. B2B 마케터 vs. B2B 영업대표
4. 그래서 솔루션 사업 고민한다 (1/2)
4. 그래서 솔루션 사업 고민한다 (2/2)
5. 제4차 산업 혁명의 도래 (1/2)
5. 제4차 산업 혁명의 도래 (2/2)
6. B2B 해외사업
7. B2B에서 B2G로 ! (1/2)
7. B2B에서 B2G로 ! (2/2)
Part II. 이제 B2B 마케팅도 필요하다
8. 시장을 알아야 한다 (1/2)
8. 시장을 알아야 한다 (2/2)
9. 고객 이해하기 (1/2)
9. 고객 이해하기 (2/2)
10. 마케팅 전략 수립하기 (1/2)
10. 마케팅 전략 수립하기 (2/2)
11. B2B 사업과 GTM 전략
12. 마케팅의 성과는 무엇인가?
13. 비즈니스 모델을 만들자
14. 대관업무 이야기
17. 통하는 프레젠테이션
18. 협상과 계약
19. 핵심 어카운트 관리
20. 디지털 마케팅과 B2B 영업
21. 새로운 시대, 새로운 역할
#B2B영업, #제안, #RFP, #제안서_작성, #제안_검토, #공공입찰, #해외_공공입찰, #포스트모템, #제안서_인쇄
