고객을 사로잡는 매력적인 제안서와 창의적인 제안팀 이야기

 

고객을 사로잡는 매력적인 제안서와 창의적인 제안팀 이야기 국내도서>컴퓨터/인터넷 저자 : 류현주,박민영 출판 : 한빛미디어 2009.03.03 상세보기

---

수주하고 싶다면? 수주할 만한 사업에 참여하는 것이 답

 

제안을 하기 전에 따질 것: 돈 되는 제안인가를 따져라

 

 

꼭 참여해야 한다면 이길 승률을 높여 참여하라(약점, 상대적 약점 보완)

사업참여 결정표 참조

---

 

팀 구성, 가용 인력이 아니라 적임 인력으로 구성할 것!

 

1) 제안PM을 선정하는 순서

1순위. 사업 경험과 제안 경험을 모두 갖춘 사람

2순위. 제안 경험을 갖춘 사람

3순위. 사업 경험을 갖춘 사람

→ 제안PM의 제안 품질에 미치는 영향은 막대하므로 제안PM만큼은 가장 적합한 인력을 산정할 것!, 권한 위임!

 

2) 제안PL은 PM과 역할을 상호 보완할 수 있는 사람으로!

 

3) 제안인력을 선정하는 순서

첫째, 사업의 개요 파악

둘째, 이번 사업에 필요한 요소기술을 파악

셋째, 누가 그 요소 기술을 가지고 있으며 제안 솔루션을 도출할 수 있는지 파악

넷째, 그 인력을 제안에 참여시킴

 

요소기술=아키텍처

아키텍트: 아키텍처를 설계하고 수행하는 인력

BA(비즈니스), SA(소프트웨어), DA(데이터), TA(인프라)

 

4) 품질을 관리하는 자, 제안에도 필요

품질을 관리하는 이의 역할

-제안서의 기본 요건 관리 : 문서 형식의 일관성, 작성 내용의 일관성

-제안서의 작성 내용 검증 : 작성 내용의 정확성, 작성 내용의 가독성

-제안 버전 관리 : 파일 버전과 파일 생성 규칙 관리

-제안 일정 관리 : 일 단위 진척 점검과 관리

 

---

 

일 단위, 꼼꼼한 일정 계획을 수립하라

 

꼼꼼≠빡빡

 

1) 제안의 프로세스

Think - Write- Present

 

 

 

 

제출일을 기준으로 거꾸로 산정하라

제안 일정 수립

1)제안서 작성 일정 계획

2)제안 발표 일정 계획

 

- 제안 일정은 日단위로 꼼꼼하게 + 여유기간까지 확보

- 계획 대비 진척사항은 일 단위로 관리

  (그날 발생한 이슈는 그날 해결하고자 하는데 목적)

  (진척사항, 일정 지연 이유 파악, 해결책 모색)

 

제안서, 요약서, 발표자료 일정을 중첩시켜 각 산출물 기획 일정을 확보하라!!!

 

 

 

 

 

 

---

고객 마음에 남길 단 하나의 메시지를 찾아라

 

설득은 무엇인가?

어떻게? 논리, 감성? 

→ 구구절절하게 싸워야 하는 이유를 설명하는 것이 아니라 단 하나의 메시지로 강력하게 붙잡을 수 있는 것.

쉽게 그리고 강력하게, 고객이 바라던 것을!

 

제안의 메시지는 '왜 우리를 선택해야 하는가?'에 대한 답이다

제안의 메시지가 갖추어야 할 조건

고객(Customer), 자사(Company), 경쟁사(Competitor)

 

 

 

 

 

메시지를 만들었으면 메시지로 제시하라

 

 

메시지는 메시지를 만들어내는 것이 끝이 아니라 이를 고객에게 효과적으로 전달하는 것까지를 포함

 

---

고객으로부터 출발하라. 고객 마음을 사로잡겠다면...

 

RFP(Request For Proposal, 제안요청서) 이해부터 시작한다

제 1장 사업의 개요 : 사업을 추진하는 배경을 이해하고 사업 타당성을 검토한다.

제 2장 제안 요청 내용 : 고객의 상세 요구사항을 파악하고 해결안을 도출한다.

제 3장 제안 작성 요령 : 제안서 작성의 지침을 확인하고 따른다.

제 4장 입찰 안내 : 제출 시기와 입찰 방법, 평가 항목을 확인하고 따른다.

(평가 항목의 강조점을 보고 그것에 포인트를 맞춘다.)

 

RFP만으로는 충분하지 않다.

고객 요구의 진의를 본질적으로 파악한다.

1) 먼저 고객 내부를 들여다보자.

2) 다음은 고객이 처한 시장환경을 살펴보자.

3) 마지막으로 고객의 고객입장을 살펴보자.

 

 

 

 

고객의 숨겨진 요구를 찾아낸다.

고객을 직접 만나 물어본다. 질문을 잘하면 고객이 스스로 알려줄 것이다.

 

1) "왜?"라고 질문하라.

2) 꼬리에 꼬리를 물어라.

질문을 왜 하고 있는지 무엇을 얻고자 하는지를 항상 염두에 두고 고객의 답이 충분치 않거나 구체적이지 않을 때

그 답에서 추가되는 질문을 하라.

 

-사업의 본질을 파악할 때면 고객사의 홈페이지와 관련 기사를 뒤져라.

고객의 비즈니스에 대한 이해가 가능하고 고객의 비즈니스가 궁극적으로 지향하는 목표와 고객사의 비전을 확인할 수 있다.

-신문기사도 참으로 유용하다.

 유사한 사업에 관한 기사를 찾아보아라. 사업의 본질을 어떻게 바라볼 것인지에 대한 힌트를 찾을 수 있을 것이다.

 

 

---

언제 어디서나 경쟁을 의식하라

 

우리가 뛰고 있을 때 누군가 날고 있을지 모른다는 것을 항상 염두하자.

 

경쟁자의 이름보다 경쟁자의 역량을 파악하고 대응하라

-경쟁자의 강점과 약점을 파악할 것(고유의 강점과 약점이 아닌, 이번 사업에 대한 경쟁사의 강점과 약점을 파악)

-경쟁사의 역량에 대응할 것

-경쟁사의 제안 메시지를 예상하고 우리의 메시지를 차별화할 것

  ⓐ경쟁사의 메시지에 대항: 경쟁사의 메시지와 반대가 되는 메시지를 제시하는 것

  ⓑ경쟁사의 메시지를 무시: 경쟁사와 동일한 범주에서 경쟁하는 것이 아니라 완전히 새로운 범주에서 메시지를 제시

  ⓒ물타기: 경쟁사의 강점을 무력화 시키기 위해 경쟁사의 강점에 물을 타는 방법

 

메시지를 강하게 만드는 환경을 조성하라

-사업 참여의 구도

-가격 경쟁력을 높이기 위한 수익 포기

-제안 기술의 우수성을 높이기 위한 과감한 투자를 통한 추가 제안

→ 확실한 근거를 갖추어서 우리의 메시지가 힘을 받고 고객에게 신뢰를 줄 수 있도록 한다.

 

실행 가능한 메시지를 선정하라

-우리의 메시지 실행 가능한가?

-우리의 메시지 비용 부담은 없는가?

-우리의 메시지 고객의 관심에 부합하는가?

 

---

고객의 진짜 Pain Point를 찾아라. 제안을 차별화하겠다면...

 

고객 요구의 진의를 파악하라

-드러난 현상과 실제 문제는 다르다.: 고객 요구의 진짜 문제를 찾아 해결해 줘야 한다

-Yes-Answer를 피하라

 

고객 요구를 구체화하라

-고객이 처한 환경을 먼저 보라: 현재 고객의 업무와 시스템에 관한 현황을 분석- 고객의 요구사항이 왜 나왔는지 이해

     1) 업무 현황 분석

     2) 현행 시스템 분석          : 문제점/개선방안

     3) 외부 변화 요인 분석

-고객을 만나보라.

     사업설명회 : 섣부른 질문으로 우리의 제안 방향을 노출할 위험도 있음, 질문 선별

                         때로는 답을 얻는 것보다 고객의 신뢰를 얻는 방편으로 질문

                         (사업에 대한 전반적인 이해 없이는 할 수 없는 질문)

                         경쟁사의 질문에도 주의를 기울일 필요가 있음

     비공식 인터뷰 : 사전분석한 고객 요구에 대한 확인, 고객 성향 파악, 고객에게 얼굴도장을 찍으려고

     질의서를 보내 답을 받으라.

     유사한 사업에서는 어떤 요구가 있었는가?

 

고객 입장에서 검증하고 우선순위화하라

     1) 업무 현황 분석 결과 개선 방안

     2) 시스템 현황 분석 결과 개선 방안     : 분석 결과 종합, 요구사항 리스트

     3) 외부 변화 요인 분석 결과 시사점

-고객 요구 중에서 가장 중요한 요구가 고객의 고민점이다.

     1)고객이 여러 번 언급한 것이 중요한 요구이다.

     2)RFP, 사업계획서 등 사업과 관련한 여러 자료에서 자주 다루고 있다면 중요한 요구이다.

     3)다른 요구들을 해결하는 데 실마리가 되는 것이라면 이는 중요한 요구이다.

     4)요구를 해결했을 때 그 파급효과가 크다면 이는 중요한 요구이다.

 

가장 중요한 요구부터 과제화하라

 

#현황을 분석하는 데는 고객사의 정보화 전략계획(ISP) 산출물이 유용하다.

 

#RFP만 보고도 고객 요구의 중요도를 판단할 수 있다

1) 중요한 것은 반드시 맨 처음 '개요'에 언급되어 있다.

2) 중요한 키워드는 여러 페이지에서 '자주' 언급되어 있다.

3) 한국 사람은 1번이 제일 중요하다고 생각한다.

4) RFP의 가장 많은 페이지를 차지하는 내용이 가장 중요하다.

 

#고객 요구 분석은 한 줄 단위가 아니라 한 그룹 단위로 묶어 분석하라

 

---

해결안은 다방면에서 구하라

 

회의를 통해 아이디어를 구하라

-창의적인 발상이 필요하다면 회의를 소집할 것: 다양한 경험을 가진 사람들로 소집

-회의는 양날의 검일수도 있다: 효율적인 회의 진행이 필요

1) 회의 주제를 명확히 할 것

2) 회의 시작 시간을 엄수할 것(늦으면 벌금이라도)

3) 회의는 가급적 짧게 할 것(소요 시간을 미리 정할 것)

4) 꼭 필요한 사람만 부를 것

5) 회의 결과는 문서로 정리하여 공유할 것

6) 회의 시간에는 주제에만 집중할 것

7) 긍정적으로 참석할 것

 

Lessons learned(경험 지식)을 구하라: 검증된 지식

 

전문가에게 답을 구하라

-해결안을 알고 있는 '그'를 찾아라

인적네트워크 구축

1) E-mail 주소록을 분류한다. 가술 인력과 영업 인력으로

2) 기술 인력은 기술 요소별로 다시 분류한다.

3) 명함관리는 소속 회사별로 한다.

4) 외부 인력 네트워크 관리에 더 집중한다. 내부보다 찾기 어려우므로...

 

-전문가인 '그'를 참여시켜라

장점

1) 해결안에 대한 신뢰성이 높아진다

2) 전문가가 참여로 투입인력 우수성이 높아진다.

3) 전문가가 보유하고 있는 인적 네트워크가 가동된다.

단점

1) 전문가와 내용에 대하여 논의하다가 시간을 낭비할 수 있다.

2) 의도하지 않은 많은 전화로 인하여 시간을 낭비할 수 있다.

3) 혹은 저녁시간에 만나면 늦은 술자리로 인해 시간 손실을 야기할 수도 있다.

 

-참여한 '그'에게서 유용한 정보를 캐내라

1) 고객의 문제와 요구사항을 파악하게 할 것

2) 그에 대한 해결책을 제시하게 할 것

3) 해결안을 구체화하도록 할 것

4) 다른 분야와 조율하도록 할 것

5) 이전에 경험한 사례에서의 Lessons learned를 제시토록 할 것

 

정보의 바다에서 답을 구하라

: 공개된 정보를 활용할 경우 정보의 출처를 밝혀 그 신뢰성을 높이는 것이 중요

 

-이론보다는 사례 중심으로 수집할 것

 

해결안을 검증하고 선택하라

1) 이 해결안을 실행할 역량이 되는가?

2) 이 해결안은 예산과 시간 범위 안에서 가능한가?

3) 이 해결안은 경쟁사보다 우월한가?

4) 이 해결안의 기술적 난이도는 적정한가?

5) 이 해결안의 원가는 적정한가?

6) 이 해결안이 유일한 해결안인가? 대안이 존재하는가?

7) 이 해결안의 적용사례는 있는가?

8) 이 해결안을 적용해본 경험이 있는가?

9) 이 해결안을 적용해본 인력을 보유하고 있는가?

 

#공인기관의 자료를 활용할 때라도 최신의 자료를 언제나 확인하라

 

---

제안서 작성, 준비 없는 시작은 뒤로 반걸음 가기

 

스토리 보드: 미리 보는 제안서(콘티)

 

미리 보는 제안서, 스토리 보드를 작성해야 하는 이유: 어떻게 제안할 것인가

- 사전에 방향을 정하지 않으면, 뒷수습하느라 더 힘들 것이기 때문에

- 제안은 혼자 쓰는 것이 아니라 팀으로 쓰는 것이기 때문에...

- 작성 분량에 치여 자칫 방향을 잃어버릴 수 있기 때문에...

 

RFP를 기준으로 기본 목차를 만들어라 : 주어진 목차를 그대로 옮겨 적기

 

작성해야 하는 항목을 빠짐없이 확인하라: 손에 잡힐 만한 구체성을 갖춰야 함

-RFP의 세부 작성 지침을 확인한다. : 작성방법에 기술된 문장을 해석하고 작성해야 하는 항목으로 도출함

-RFP 본문의 부문별 요구 사항을 확인한다. : 사업 수행의 핵심인 Ⅱ. 개발부문- 다른 어떤 부분보다 구체적으로 스토리보드를 구상해야 한다

-RFP의 평가 항목을 확인한다.: RFP의 '세부 작성 지침'이나 '제안 요청 내용'에는 언급되어 있지 않으나 평가요소 항목에 제시된 항목이라면 이 또한 제안서에는 작성 항목으로 도출해야 한다.

-고객 요구에 대한 우리의 답을 확인한다.

 

작성 항목을 배열하라

-먼저, 논리 구조를 잡아라.: 제안의 스토리에는 우리의 주장이 담겨야 한다. 주장만을 담는 것이 아니라 그 주장을 왜 신뢰해야 하는지, 그 주장이 왜 나은 것인지를 설득할 수 있어야 한다. 그렇기에 제안의 스토리는 '논리성'을 기본 바탕으로 한다. 논리적인 스토리 구성이란 '주장과 근거'를 말한다.

-고객이 알고 싶어하는 것을 앞세워라.: 주장하는 것보다 먼저 앞세워야 하는 것이 바로 고객 요구에 대한 답

 

무엇을, 어떻게 작성할 것인지 손에 잡힐 만큼 상세화하라: Summary부분 상세화

-What: 무엇을 담을 것인가? : 구체적으로!

-Key Point : 강조하고 싶은 우리의 주장은 무엇인가? :  고객의 요구사항과 맞아 떨어지며 우리 제안이 차별성을 갖추고 있다는 점을 강조, 세분화

-Source: 이 부문을 채울 자료는 어디서 가져올 것인가? : 누구에게 요청하면 되는 것인지를 언급해둠

-Deliever: 어떻게 전달할 것인가? : 표? 프로세스? 개념도? 삽화?

-Issue : 아직 결정되지 않은 요소는 무엇인가? : 스토리보드는 제안초기에 작성 따라서 미진한점을 기록해두는 것이 필요

 

제안의 메시지에 맞춰 강약을 조절하라

-제안 메시지에 따라 부문별 작성 분량을 조절한다.: 제안 메시지를 직접적으로 담고 있는 부문일수록 많이 작성

-각 부문의 세부적인 논리에 반영한다.: 제안의 각 대상 과제를 전개할 때도 메시지를 대변할 수 있는 항목이 무엇인가를 생각해 보고 세부적인 논리에 반영

-별도의 항목으로 뽑아내 제시하기도 한다.: 제안의 각 부문에 메시지를 담긴 했으나 흩어져 있어 메시지 전달의 힘이 오히려 떨어진다는 생각이 든다면, 제안의 메시지만을 담은 별도의 항목을 뽑는다. 그리고 새로운 스토리로 만들어라.

(한 제안에서 딱 한번만 사용해야 한다.)

 

검증하라

-빠뜨린 것은 없는가?(조견표 작성/제출) : ①빠뜨린 것이 없는지 검토 ②고객이 우리제안을 쉽게 평가토록 안내하는 역할

     고객 요구에 대한 해결안은 모두 배치했는가?

     평가 항목에 대해서는 모두 대응 가능한가?

-중복은 없는가? : 

     목차의 중복, 작성항목의 중복

-논리적 일관성은 유지하는가?

-강조해야 할 점은 강조하였는가?

     제안의 메시지는 스토리에 반영되었는가?

     스토리보드 각 부문의 Key Point는 명확하게 작성되었는가?

     Why를 제시하고 있는가? : 주장에 대한 논증을 하고 있는가를 검토하라(논리 구조를 검토)

-손에 잡힐 정도로 구체화하였는가?

     스토리보드를 보고 누구라도 같은 해석이 가능한가?

     스토리보드를 보고 누구라도 같은 내용으로 작성이 가능한가?

     스토리보드를 보고 이슈사항을 쉽게 파악할 수 있는가?

-팀원에게 배분하라(역할 배분:수평적 배분, 수직적 배분)

     수평적 배분 : 작성해야 하는 과제별로 그 역할을 배분(글의 작성 및 비주얼화를 책임짐, 해당 과제에 전문적 지식 갖추어야 함)

     수직적 배분 : 역량 수준별로 역할을 배분(한 과제를 작성하기 위해 소단위 팀을 구성하고 그 팀안에서 역량 수준별로 역할을 다시 배분)

 

팀원과 공유하라 : 스토리 보드를 팀원간 커뮤니케이션의 도구로 활용

 

제안서와 요약서 및 PT의 스토리보드는 같지 않다

제안 산출물	특징	스토리보드 구성시 유의사항
제안서	-고객 요구에 대한 모든 해결안을 담은 문서 -제안 요청서(RFP) 기준으로 작성	-필요 항목을 쉽게 찾을 수 있도록 구성
요약서	-제안서의 요약을 담은 문서 -대체적으로 제안의 핵심 내용을 담아 별도 구성 -평가 시 제안서보다 우선순위	-핵심 내용과 이에 대한 근거 위주로 구성
제안발표(PT)	-제안발표(Presentation)의 보조자료 -대체적으로 제안의 메시지 중심으로 별도 구성 -산출물 중 가장 중요한 우선순위를 가짐	-제안의 메시지 위주로 구성 -말로 하는 발표의 보조자료로서,   발표자의 말하는 습관 고려

 

# 스토리보드는 PM이 만들거나 사업을 가장 잘 아는 사람이 만들어라

# 아키텍처 부문의 스토리보드에도 주장과 근거를 담을 것

# 스토리보드는 파워포인트로 만들기도 한다

 

 

---

스타일을 통일하라. 공통 템플릿의 제작

 

공통 템플릿은 어떻게 만들 것인가?

-먼저, 동일한 스토리가 반복되는 부문을 골라낸다.

-해당 부문의 상세 스토리보드에 따라 작성 페이지를 설계한다.: 동일한 스토리가 반복되는 과제 중 하나를 기준으로 삼아 페이지 단위로 스토리 보드를 구체화한다. 작성 페이지 한 장 한 장을 설계하는 것이다.

-모든 대상 과제에 적용 가능한 지 검증한다.

-작성 가이드와 작성 사례를 붙여 배포한다.(충분한 설명)

 

---

초안을 빨리 뽑고, 점핑하라

 

제안서 초안: 스토리보드에 따라 작성한 첫번째 제안서(가닥은 잡힌 제안서, 첫번째 통합본)

 

제안서 초안을 빨리 뽑는 만큼 제안서 품질을 높일 수 있다. 왜?

-제안서의 실제 모습이므로 허점을 찾아낼 수 있다.

-진척은 잘 되는지, 어느 부분이 문제인지 중간 점검을 할 수 있다.

-제안서 품질 향상은 제안서 초안에서 드러난 문제를 해결함으로써 가능하다.

 

제안서 초안, 제안 시작 일주일 내에 뽑아라. 어떻게?

-300페이지 제안이라면 300페이지짜리 파일을 만들어라

-모든 페이지에는 적어도 목차와 메시지가 작성되어야 한다.

-제안서 작성을 위한 원천 자료들을 갖다 붙여라

-작성을 다 하지 못해도 좋다. 그러나 작성 계획에 대한 설명은 남겨라.

 

일의 순서를 바꾸지는 말 것

-아키텍트가 초안 작성 시 제일 먼저 할 일은 구성도 그리기가 아니다

 

# 팀원간 커뮤니케이션의 도구가 되기도 하는 제안서 초안

 

 

---

모든 페이지는 설득적이어야 한다

 

솔직하게 말해보자. 평가의 진실

-첫 페이지부터 마지막 페이지까지 정성을 다하여 읽는 평가자는 없다.

-평가자가 누구냐에 따라 관심항목이 달라진다.

-짧게는 30분만에 평가가 끝나기도 한다.

 

그래서 제안서가 갖추어야 할 조건

-쉽게 읽히는 제안이어야 한다.

-단숨에 전달할 수 있는 제안

-전달 내용이 명확한 제안이어야 한다.

 

제안서의 모든 페이지는 논리적이어야 한다.

 

# 기술자는 고집쟁이, 고집을 꺽어라(고객 입장에서 제안서를 작성할 수 있도록 바꿔줘라)

 

---

제목, 읽고 싶게 만들어라