一个合格的售前要懂产品、懂技术、懂业务、懂商务、懂需求、懂分析,概况起来就是“能说会做、能写会练”。所谓“会写”是根据与客户沟通交流的结果达成一定程度的意向后,着手编撰方案、意见书、规划书等,形成文字性、演示性的资料。
如何才能会写、写好方案,特别是政府项目方案呢?首先,要明确标准,知道什么样方案才算优秀;其次,要找原因,为什么写不好;最后,找方法,明白写好方案的技巧有哪些。从这三个层面来解析,掌握方案设计的思路,把握方案设计的要点,使方案设计更规范、更专业。
一份合格方案是怎样的?
首先让我们对方案下一个定义。方案,是针对客户某些已经出现的或者可以预期的问题(技术、业务、管理等)、不足、缺陷、需求等,所提出的一个解决性计划,同时确保其能有效执行。方案的本质是在客户利益和产品以及产品的特性之间建立逻辑桥梁。
根据项目的不同阶段,方案又可分为初步设计方案(通用型方案)、深化设计方案(针对性方案)、投标方案、实施方案(落地方案)等,不同阶段的方案侧重点不同。按照方案格式不同,可分为word版方案、ppt版方案、原型方案等。本文的目标是梳理方案设计的基本思路、要点,使方案设计更加规范、专业。
一篇优秀的方案应该有三个评判标准:拿得出手、谈得下去、落得了地。“拿得出手”指方案应该内容完整、逻辑明确,能够给客户明确方向、建立信心和路径指引;“谈得下去”指方案有吸引客户的地方,有继续谈下去的可能;“落得了地”指方案中所建设内容要实事求是,有操作性,不能沦为空谈。
为什么写不好方案?
优秀方案各有各的亮点,不符合要求的文案其缺陷可以归为以下几类。
第一种,用“CV大法”做出的千篇一律的方案。所谓“CV大法”,就是写方案时主要使用Ctrl-C和Ctrl-V,将分散在各个项目中的功能模块,简单地东拼西凑,组合成一个方案。用“CV大法”做出来的方案,几乎很少谈到客户的现状、困难及需求,没有针对性,无法解除客户心中的顾虑与疑虑。
也就是说,拼凑成的方案,缺少对客户自身业务的针对性/个性化内容。这种情况的根本原因是思路不清晰。一方面是素材的短缺,难以助其梳理思路;另一方面是针对性方案没有通用型方案那么标准,导致撰写时不知道从何写起,在时间紧、任务重的情况下,翻阅众多素材也没找到思路,只能先攒一版交差。
第二种,存在需求偏差或脱离业务的方案。在项目中,尤其是政府项目,对需求的理解、展现,是客户最在意的重点内容,也是撰写方案时需要重点突出的部分。如果对客户需求分析理解不到位,出现需求理解偏差、需求把握不足、需求梳理混乱或需求缺乏扩展延伸等情况,就会导致方案在需求实现上偏空、不落地,没有进入实际业务场景,难以与客户形成共鸣,客观上也无法打动客户。
第三种,缺乏逻辑、没有层次的方案。有些硬着头皮完成的方案,撰写过程中过于注重条条框框,缺少逻辑梳理,害怕不够全面,资料中任何与需求相关的东西全部借鉴,造成方案导入过于冗长、内容杂且乱,展示片之间衔接较差等现象。
如何才能写好方案?
写方案是一个发现和揭示的过程,即按照说明问题--分析问题--解决问题这样一个流程,一步步推导,梳理出来的。简单地说,就是销售带着客户的需求(问题)而来,我们通过方案来聚焦问题,再进一步进行分析和研究,梳理出真正的痛点/需求,最终给出解决方案。
1、前期准备——说明问题
说明问题,顾名思义就是做好把问题说清楚的准备。这个前期准备,包括两个方面,一是了解项目信息,二是资料的查找,这些工作有助于捋清思路。
了解哪些项目信息呢?要了解清楚这个项目的来龙去脉,以及方案给谁看、呈现方式、客户需求痛点等。
(1)项目的来龙去脉
主要了解:客户是谁、行业政策背景、当前处于哪个阶段等信息。
项目不同阶段,输出的方案类型和内容是不一样的。前期接触阶段,主要是让客户了解公司情况、实力以及方案可行性。初步交流阶段,主要让客户对公司的产品/方案有初步认识。初步意向阶段,就要提供通用型方案,从大方向、概念、解决了客户什么问题等方面去阐述。售前调研阶段,主要体现产品方案的功能、性能等方面阐述,来体现公司的技术能力、专业能力、实施能力、服务能力等优势。用户考察阶段,主要从影响客户,充分说明公司各方面的综合实力以战胜对手,并制定有利于自己的打分标准等方面努力。
(2)方案汇报的对象、需求及呈现方式
需要了解清楚方案的呈现方式(是Word,还是ppt,是否需要演示产品等)、汇报对象及其所在的岗位、需求等情况。
如果是向领导汇报,就要在第一时间抓住领导兴趣点,侧重于建设效果、价值方面,特别是政府项目,如果能体现突出的政绩,那就更有吸引力了。如果是管理层或者业务层使用人员,要侧重产品的建设内容,实现该功能后能给对方带来诸如提高效率、减少工作量等实际帮助。如果是信息中心的领导,他们的关注点多为信息资源的整合利用、打破信息孤岛、实现数据共享等功能。如果是给集成商汇报,他们一般对方案/产品功能点是否多而全、产品有多少市场以及项目的收益、优势等方面比较关注。
很多情况下,方案的需求来自于领导或销售,接触的都是加工过的二手信息,撰写者就要尽量问清情况,明晰他们对方案的想法和建议,这样对下一步写方案会有很大帮助。有条件的,尽量同需求提出人/客户沟通一下,问清楚客户需求,以掌握一手需求。这样不但可以提高方案的针对性,也可以获得大量的解决思路、写作线索,对写方案大有好处。
了解需求的过程中,要关注用户有没有特别要求的需求。多数情况下,需求方都会有一些自己的思路,我们要先听一听他们的思路,把握用户关注的重点难点问题,并将其关注的问题体现在方案中。此外,明确用户有没有不需要的内容,不做什么是对方的边界,我们无需浪费时间去赘述。
(3)查找资料
查找政策文件、竞品资料、行业研究报告、产品白皮书等等,找寻思路的火花并记录下来,为后面整理形成一个自己的思路大框架(提纲),结构化地去组织解决方案的思路和框架奠定基础。
2、分析问题
分析问题的目的是为了构思提纲和框架,然后再动笔,没有结构化的思维,写出来的方案就是一盘散沙。建议用“3W1H”(“WHY-WHAT- HOW- WITH ”)方法来梳理方案的思路。
WHY:
该项目的驱动因素是?
项目目标是?
有哪些人会参与到业务流程中?
……
WHAT:
方案的目的(用来做什么)?
提供什么样的产品/服务,给谁?
汇报对象最关注的是什么?
……
HOW:
系统需要哪些功能?
功能之间有无依赖?
需要哪些应用和数据?
系统的架构怎么构建?
……
WITH:
需要哪些产品可以实现这些功能?
需要哪些组件来建立系统?
系统如何开发和部署?
……
3、解决问题——谋篇布局
总结一个比较通用的方案设计思路供大家参考。我们从客户的需求或者说目标出发,分析发现需求的根本点,围绕这个根本点逐步推导出我们的方案设计,并在最后用原型或者系统截图,向客户展示这个方案的最终效果。这种结构化思维方法,即定义→发散→聚合的思路来阐述方案,会让方案整体逻辑更加清晰。
下面我们以PPT版方案的设计过程来看下这个构思方法。
遵循上述设计思路,我们先将目录简单定为:项目背景—需求分析—总体设计思路—功能设计—实施方案(效果)—总结(问题/建议)。同时根据项目涉及的业务,在采取工作流程串联整个方案介绍的前提下,各模块采取也采用“总-分-总”的结构,后续可根据具体情况进行调整。
构建了整体框架后,再提取方案总体架构,再逐步细化,最终抽象出具体的支持的功能模块,接下来再按由下而上的流程,对流程进行验证、修改,保证各层在数据源、数据结构及业务逻辑上的统一性,最后对每个模块的特点、亮点做详细描述。
在项目背景分析环节,主要从政策层面上点出师出有名、政策引导的重点,并在功能设计方面与之呼应,向听众阐明建设该项目/系统(上能交差,下能形成政绩等)的社会价值。
在需求分析环节,主要从战略层面向听众阐明该项目的用户及其需求,并梳理用户的详细需求痛点,从而挖掘出系统需要建设的功能点。
在总体设计思路环节,主要梳理出总体的概要业务流程,明确告知整个系统业务运转过程,然后结合前面需求分析的梳理,引入系统总体架构,明确系统建设目标。
在需求分析阶段,梳理的功能点是分散且未细化的。总体设计环节,搭建出系统架构,将功能归集。设计环节将逐个讲解系统对应的功能架构,细化功能模块,设计需求具体实现点。
功能设计介绍时,应先介绍系统功能结构图,再对单个功能模块进行介绍,细化到功能点。功能设计是方案中的重点,其内容要详略得当。整个项目细化的内容有很多,但并非所有内容都需详细呈现或说明,全部呈现容易让人抓不住重点。所以对重点功能、核心需求应予以详细阐述,其他的功能点简单梳理、点到为止。
实施方案(效果)部分,视项目阶段及汇报对象的不同而有所区别。如果是前期接触,一般在这部分会针对系统自身特色、公司擅长业务,作为亮点结合效果图/系统图进行阐述,这是个加分点。如果是已经达成初步意向,这部分将侧重项目工期、项目主要工作流程、落地计划以及项目风险等方面内容。
在最后的总结环节,先简单地回顾前面主要业务流程,再提出针对本次功能建设的相关建议,并再次阐述该方案的优势(或价值)所在等。
这样,整体方案按照“总-分-总”结构进行,开头总体阐述背景、需求及建设思路,篇幅不宜过长,中间将具体解决方案细化分解,方案末尾再次切入整体架构,总结之前所讲内容,为客户梳理加深印象。形成初稿之后,还需要细致的复盘检查,将自己定位在演绎者的位置,试着模拟宣讲一遍,检查衔接是否顺畅,符合逻辑。
在此,附上PPT方案的检查表,可对照复盘检查。
本文转载自:[微信公众号]TC星球
作者:张艳
原文链接:https://mp.weixin.qq.com/s/f_BvO_NNAYE8txuy-AopnA
推荐阅读