凯哥:5WH模型组织高质量的解决方案建议书
解决方案架构师(Solution Architect)的核心工作就是将自己的产品和服务转化成能够解决用户问题的解决方案,所以,编写解决方案建议书,是解决方案架构师(Solution Architect)的核心工作之一。
此文是《解决方案架构师特训营》一个课题的片段内容,通过5WH模型能够帮助大家结构化的组织售前材料。
1.写一个高质量解决方案建议书(Proposal)越来越难
在10年以前,我们用“攒片子”三个字来形容写Proposal的工作,是因为基本上很多项目需求都类似,问题也差不多,所以解决方案雷同是很正常的。比如说做ERP,做MES这类的企业基础应用架构,那时大部分企业处于人财物集成,生产管理的基础应用建设阶段,大家的需求都是类似的。所以一套方案出来后,到别的客户那边,基本上拷贝拷贝,改改客户名称,调整调整结构就差不多了。
到了现在一个好的PROPOSAL攒起来越来越难,片子好凑,思路难理,主要原因如下:
客户的需求差异化增大
客户都在强调创新,都在强调差异化,即使是同行业的客户在面对同样的问题的解决方案和方法都是不一样的,差异化很大,所以靠拷贝微调,凑片子已经不能满足客户的细分的差异化需求了。
客户和实施方的知识差距缩小
现在是一个典型的知本时代,信息透明,知识分享经济盛行,所以原来的给个白皮书,吊吊客户胃口,然后把干货的内容在实施的时候再拿出来的传统套路已经不足以应对客户的需求。我们和客户方所了解的知识差距越来越小,而落地的经验和深入定制客户的解决方案才是最具价值的内容
2.成功的PROPOSAL的三个特质
一个成功的Proposal,以下三个特质是必须的:
故事完整
Proposal就像是讲故事,作者就是导演,需要有一个整体的顶层设计来保证这个故事是完整的,是能够完整地阐述一个故事。
逻辑严密
一般来说,Proposal的主要目的就是为了要说服对象接受你的观点,同意你的结论,从而让他采取某些行动。整个Proposal的组成是一个逻辑严密的推理,让受众在阅读整个内容的过程中,一步步的相信和引导出你希望他们的结论。
卖点突出,主线清晰
一定要有清晰地差异化,突出Proposal的卖点,突出你希望表达的特点,而不能让手中看了半天,似乎都听懂了,但是什么都没记住,所以,核心差异化的点一定要多次重复,要突出。售前方案最忌讳的就是看上去啥都讲了,最后用户啥都没记住,或者自相矛盾,自己逻辑有问题。世界上没有一定的1+1=2的道理,Proposal就是在有限的时间内,利用自身的强大逻辑,自证自说,如果你的逻辑够严谨,论据够充分,用户完全会推翻自己以前的假设,认为1+1=3。
所以,整个解决方案一定要围绕一个主线,主线是什么?是我们的业务方案+技术方案+实施方法,每一个方案都必须有我们差异化的,特别强调的能力。每一页片子都必须能够为证明这个主线产生价值。凯哥曾经见过很多的技术方案,前面讲业务还没讲透呢,突然就进入技术方案,然后贴了几个微服务、DevOps的图,感觉很突兀,和用户的业务需求完全没有关系,没有承接。
所以,一定要围绕一条主线,从上到下推理,从下到上支持这个主线以及卖点。
多年的Proposal经验,凯哥总结了5WH的漏斗模型,可以帮助大家打造一个高质量的Proposal。
3.利用5WH FUNNEL MODEL优化你的PROPOSAL

要构造一个高质量的Proposal,可以从用户和自身两个视角出发,研究5个W,一个H。像一个漏斗一样,从上至下,理解客户的需求,将客户的需求引导到你希望的目标一方面从下至上,梳理清楚你的优势和特点,对应到你的目标,从而上下拉通。
1. WHO
要理解客户是谁,他所在的行业背景,当前面临的挑战和机遇,这一部分的主要目的是体现你对客户的重视程度,你对他的理解,以及你的研究和学习能力。
一般来讲我们会去研究一下公开的客户基本信息,公司战略,领导讲话等信息,同时要去研究一下这个行业的其他竞争对手,尽可能的了解清楚客户和其他竞品的差异化,从而将WHO这个画像更加清晰的描述出来。让客户感觉到你们花了很多时间在研究他们,很重视他们,从而产生同理心。如何让客户产生同理心:全方位的查询客户的官网和相关资料。
比如凯哥写方案的时候,第一件事情一定会去上网了解客户公司的背景,业务目标,营收情况,然后利用用户网站的一些图片做售前方案的图例,让客户感觉,这个供应商很认真,对我们很重视,还专门上网了解了我们的情况。
如果做完方案,你还没上过客户的官网,那么这个方案一定是可以被优化的。
查领导讲话,是非常有用的杀手锏,解决方案中,会突出“我们认为业界的趋势是 集约化发展,精益化管理”,然后讲完了,客户竖着大拇指,说“我们王董事长前面的讲话和您说的这两个观点一模一样!”
当然一模一样了,这就是你们王董事长说的。
2. WHY (DO)
在理解客户的信息和行业的基本信息的时候,很自然的就需要分析客户所面临的挑战,行业面临的变革,那么这些挑战和变革和当前客户的需求的关系是什么?
这一段就是要深入理解客户的需求和客户的战略、挑战的关系,也就是为什么客户要做这个事情/项目的原因。这一个章节至关重要,需要我们将客户这个需求拆解并且尽可能分别对应到客户的战略愿景、行业竞争、现状问题,挑战及风险四个角度,从而全面理解为什么会有这个需求的原因。
最好的情况是,我们如果发现一些当前客户所理解的需求的不足或者我们能够给出的建设性的意见,那么将是非常好的在客户心目中建立信任的方式。
前面两个步骤, 我们从客户的视角,深入的理解了客户为什么要做这个项目的需求,接下来,让我们切换一下角色,从我们自身的角度出发
3. WHY (DO IT)
我们为什么要做这个项目(解决方案)?之所以要思考这个问题,是因为这个问题是我们这个解决方案的目标,当然大部分情况只是在投标的时候,我们希望赢得这个项目或者机会。但是,我们同样要梳理出技术层面我们的诉求,比如有的情况下,我们会为了建设某一方面的能力,那么我们定义出来这个诉求后,就要在解决方案中设计一个场景来满足我们的诉求。
4. WHY (US)
这个WHY,指的是为什么是我们(WHY US),也就是我们的差异化优势在哪里。必须找到差异化的优势,当然有时候我们找不到我们自身的差异化优势,那么也可以从竞争对手的弱项上来体现我们的优势。总结出来的差异化的优势要和前面第二个模型中,客户的挑战有所呼应,这样,我们的独特疗效,刚好对症于客户的挑战。
5. WHAT
当我们梳理清楚我们的差异化的优势能力后,就继续回到客户视角,来理解一下,针对客户的这个需求的解决方案应该是什么样子,应该做什么。当然,由于前面我们已经知道了自己在这个需求中差异化的优势,我们在解决方案初步预设中,就需要把我们的优势(WHY US)和解决方案呼应起来。
6. HOW (TO DO IT)
最后,详细的介绍我们将会怎么做。
很多的解决方案,在前面介绍了业务需求后,很突然的就落到了技术解决方案,两者对应不起来,感觉后面的技术方案是凭空而降的,放到任何一个别的解决方案中,也不会感觉到突兀,这就是因为怎么做和前面的为什么要做,我们的差异化优势,没有形成协同的效应。
比如说,我们分析,在一个软件实施项目中,我们的技术差异化优势是微服务,那么我们在前面理解客户的需求和痛点的时候,就需要用业务的语言描述出微服务适合的业务场景和价值,比如说这个系统的业务要求来看需要重视敏捷性,需要具备很强的可扩展性,引导客户理解,那么在后面的技术方案中,提出微服务就是行云流水,很自然的了。
4.一个典型的应用系统投标解决方案TOC模板
成功解决方案有一个总体原则,不要围绕用户的应用系统的名字写方案,而是围绕用户的业务目标写方案。
有时候客户发标的时候会给这个系统起个名字,比如“XX管理系统”。
很多童鞋就会围绕这个“XX管理系统”去写方案,满脑子盯着的就是这个管理系统,而失去整个森林。回到初心,我们要理解客户做这个系统的目的,不是为了做这个系统而做这个项目,而是为了解决客户的业务问题。
所以不要被客户的标书名字所迷惑,很多时候客户的思考没有那么深入,很多时候客户可能是被别人引导的,我们要找到背后真实的问题,给出我们的解决方案。
在这个基本了解后,一个典型的投标类解决方案的目录模板可以按照如下章节组织:
对于客户的理解
对行业的理解。
对客户企业的理解。
对客户企业挑战的理解。
对于客户项目的理解
项目背景的理解。
项目目标的理解。
项目的挑战及成功关键因素。
公司介绍
关于我们
在讲标的时候,如果你自信气场足够强大,能够控住全场,就把公司和案例介绍放到这里。前面刚刚讲完挑战,引导用户要重视和正视这个问题。这时进行公司以及案例介绍的效果就像一个美女陷入了泥潭,前面有悬崖,后面有追兵,进退两难,花容失色..... 这个时候,镜头推出一个白马骑士,从天而降,来拯救这个美女......
案例介绍
这里一般重点介绍一个和本项目类似的案例,让客户产生同理心,其实就是这个项目的解决方案的实现,但是又不说是这个项目的解决方案,降低风险。
解决方案
接下来白马王子要开始施展手段解救美女了。解决方案一般分为业务方案,技术方案和实施方案,业务方案体现我们对客户业务的理解,技术方案体现我们的技术卓越,实施方法体现我们是老司机,替客户想的周到,管理水品高。
业务解决方案
这一部分一般要包括以下内容:
对客户业务的理解
客户业务流程等理解
业务挑战和解决方案
对客户业务挑战的理解以及我们的核心业务解决方案。
业务蓝图及演进路线 (Optional)
这一章在很多大型的应用系统投标中很加分,在当前应用需求的理解上,加入远期的规划是很体现解决方案能力的。
对于技术的要求
这一节很多售前方案没有,所以讲完业务方案后直接就进入技术方案,客户很奇怪,前后完全没关系,前面还在讲业务,后面就生搬硬套进了微服务。
技术解决方案
响应第一章的关键成功因素以及业务方案中的对技术的要求,这就是我们的技术方案,这里很重要的是理解出这个系统的技术的难点,以及我们的解决方案。
实施方法
项目实施挑战及应对
一般来讲,系统间集成、项目的进度、质量这些都是项目实施的挑战,我们要重点阐述。
实施计划
编写我们的实施计划,包括短期的项目计划,以及未来的远期规划团队构成,我们的团队人员的简历,案例,体现是老司机。
实施方法
好的解决方案没有定式,但是思维模式和模型是可以借鉴的。
可能大家觉得我是做技术开发的,这个和我没关系。
但是这个5WH模型,不仅适用于写标书,解决方案,其实它就是一个销售自我的售前模型,能够很好的帮助客户提高说服别人的能力。
喜欢这篇文章的,可以看看随机推荐的以下原创文章哦: