如何写好政府项目解决方案?

首先让我们对方案下一个定义。方案，是针对客户某些已经出现的或者可以预期的问题(技术、业务、管理等)、不足、缺陷、需求等，所提出的一个解决性计划，同时确保其能有效执行。方案的本质是在客户利益和产品以及产品的特性之间建立逻辑桥梁。

根据项目的不同阶段，方案又可分为初步设计方案（通用型方案）、深化设计方案（针对性方案）、投标方案、实施方案（落地方案）等，不同阶段的方案侧重点不同。按照方案格式不同，可分为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方案的检查表，可对照复盘检查。