如何撰写项目的解决方案文档格式.docx
《如何撰写项目的解决方案文档格式.docx》由会员分享，可在线阅读，更多相关《如何撰写项目的解决方案文档格式.docx（17页珍藏版）》请在冰豆网上搜索。
一般不经常写方案的人，在写一个方案的时候，即使有想法，有思路，但往往也会很累，就是因为缺少足够的素材。
很多项目现在都是投标，不同用户可能有不同投标的要求，这样很难用一个方案去适应所有的用户，因此在每个方案中都有一些需要准备的内容。
这些内容基本上是通用的，但如果没有足够积累每次编制方案就需要花费大量时间去准备，造成方案完成周期过长。
所以写好方案必须具备这三个条件，第一方案编制者对企业业务要很熟悉，或者有相关业务调研经验，第二方案编制者对产品非常熟悉，至少对自己产品功能模块作用很清楚，第三方案编制者手上有大量可公用的素材库。
1.4
第四种是没有层次
很多人刚和用户接触没有多久，为了表现自己对客户的重视，马上表示要提供方案，当然有的客户刚刚开始选型，也不知道到底要什么搞，也要供应商马上提供一个方案。
结果拍胸脯容易，写方案难，自己写不出来只好求公司，公司没有安排专人了解情况，只好按模板制作一个，用户一看几个供应商内容都差不多，觉得不好，又总结出一些个性化要求，于是大家有开始折腾第二轮方案。
其实方案编制在不同阶段有不同策略，不要轻易提供方案。
刚开始接触是可以提供项目合作建议书，类似可行性报告，项目需要考察软件技术，可以提供标准的产品技术白皮书，到了经过售前调研，有所准备，在演示前后阶段和其它竞争对手刺刀见红的时候，才在知己知彼的基础上提供解决方案或者投标书。
过早提供方案只能匆匆了事，时间紧急，质量自然不高，自然也就觉得方案难写。
想急就又能解决问题的事情，本来就是一般人做不来的。
方案想要写得好，一定要用心，用心就一定要耗时间，指望用几个小时写出一个高质量的方案是不可能的。
如果你做了精心调研，你写不出一个好方案唯一缺的是技巧。
写方案是一种技巧性工作，明白了这一点，大家都可以经过练习写出好的方案。
二、坏的解决方案有那些特征
2.1
第一个容易犯的错误：
只有论点，没有论证
不好的解决方案粗看起来非常厚重，其实都是功能罗列，象产品手册摘要版，不象方案书。
不好的方案是一大堆内容，淹没在一堆纸里面，也不知道想说什么，给你一个厚度，证明我们的工作质量很高。
我们国内许多的企业客户特别是大型企业都很在乎这点，认为可以从方案厚薄中看出对项目重视程度。
写方案是一种技巧性工作，有个金字塔式的写做原理，也就是说文章一定是有结构的。
所以真正好的方案，不一定厚，但能看出你用心，你认真。
现在的解决方案一个不好的倾向是“长、厚、全”，看起来面面俱到，其实对决策者没有帮助。
所有的方案无差异性，每家供应商都说自己能解决这些问题，而且都有成功案例。
结果所有的方案都无法给决策者简明的判断依据，不得不费更大劲去做产品演示和用户考察。
其实很少有企业高管不知道自己的毛病，在企业你随便去找一个人，对问题都能讲一通，在企业你费很大劲可能都找不到一个人能告诉你这些问题可以怎样去解决。
通观这个方案并没有研究为什么企业会产生这么多问题？
问题是这些问题是什么产生的？
为什么出这么多问题？
而是不断说“我能！
我能！
选我，选我！
”。
如果不能找到解决这些问题的原因，简单地去解决这些现象，就象治病不能治根一样。
这样一个模板化，自我膨胀化的方案想打动用户的心是非常困难的。
不好的解决方案最大的问题就象写一篇议论文，能够发现问题（这个也是模板化的，可惜中国企业大部分没有意识到自己很多问题并不少见，总以为自己是特殊的一类企业），提出答案（搞信息化），但没有论证（为什么搞信息化和企业管理进步有联系呢？
）。
没有论证的东西不管内容陈列得多么繁复，名词多么吓人，但是无法打动用户，特别是那种理性的用户。
看到方案时候，其实很多用户下不决心，他会感觉每家都差不多。
如果从没看过方案的人，突然看到这几个方案，你为什么会感觉某个方案写得好呢，关键是有的方案图画的好，通过图，通过表，会感觉这个公司还不错，很规范。
但对内容认可程度并不高，实际上没看懂。
2.2
第二个容易犯的错误：
业务解决方案成为功能列表
解决方案省事的一种方法就是将产品功能描述作为技术方案内容进行罗列，或者参照软件用户手册罗列，这种解决方案不是按照用户业务去准备的内容，而是按照软件商自己的喜好去编制的解决方案是很难得到用户认可的。
大凡按照功能列表组织的解决方案用户会有一个体会，庞大而庸长，但要看到自己想看到的部分非常困难。
而且这种方案还有一个特点，一个问题反反复复的提，在业务背景中指出某个问题，讲一通，在价值分析中又重点解释一通，到了功能介绍时又将某个问题来龙去脉概要说明一下，给用户感觉是一堆资料的堆积，哪里体现出了方案的针对性呢？
按功能列表准备方案的做法在很长一段时间内不会消失，这和我们普遍是4P销售人员，还缺少SPIN（顾问式）销售人员有关，在资源不足的情况下，要保证效率就只能提供功能列表方案了。
2.3第三个容易犯的错误：
结构不清晰
不好的解决方案最共性的毛病是结构不太好，没有清晰的思路。
没有思路的方案质量很低，用户在审阅过程中也不会体会到和一个专人人士通过文字交流的乐趣，他不得不从供应商混乱的思路中发掘亮点，看看到底是谁能解决企业的问题，真是一件痛苦的工作。
一种常见的方案结构毛病就是重复的内容在不同的章节反复出现例如在第一章介绍了对某个问题的分析，提出企业的需求，这第二章介绍方案价值的时候又用不同语句组织类似内容，到第三章解决方案描述中还是要把问题描述一遍，给人感觉思路不连贯，结构臃肿。
这里有一个方案提纲的提纲，我们以这个提纲为例子说明结构不清晰的方案。
1
公司简介及资质文件
1.1公司简介
自有产品及代理产品情况
重点工程介绍
公司资质复印件
2
分项标价表
3***PDM系统技术解决方案
1***PDM系统技术解决方案
2***PDM系统具体功能模块
3
报表及明细汇总
4
应用工具及封装接口
5
用户及权限管理
6
拼图打印
7
编码管理
实施计划
4.1
实施步骤
4.2
培训计划
3.1
系统培训对象
3.2
主要培训内容
3.3
培训方式
实施人员资质
6.1实施人员组成及工作职责
6.2实施人员资质说明
质量保证及售后服务
7.1
质量保证
7.1.1
工程技术力量的研发水平
7.1.2
工程技术力量的实践经验
7.1.3
管理水平7.2
售后服务承诺
7.2.1
技术支持与服务的内容和承诺
7.2.2
技术支持与服务的保障
8
开目典型用户
9
有关技术秘密的声明
10
附件
这个方案第一部分、第二部分是用户投标要求，必须如此，但第三部分技术解决方案应该是重点，这个部分结构就很奇怪。
一般好的方案结构标题就是论点，内容就是用事实进行论证，子目录是上级总目录论点的分论点，逐层论证下来，方案显得逻辑性结构性很强，看看目录就能看出方案的逻辑推导体系。
这就是所谓金字塔文档体系。
这个方案显然不是这样的，看起来一大堆内容，有经验的人一看就知道是内容的罗列。
例如第三部分总标题是技术解决方案，结果第一个子标题还是技术解决方案，撞车！
一定层次感都没有。
而且第一子章节技术解决方案后马上是功能模块，技术解决方案理论上包括功能模块，不是一个层面的东西，技术解决方案应该和实施策略，服务策略平级的内容，所以一定要谈谈自己技术解决方案，不如用技术解决方案思路或者特色来表达，和功能模块也就是一个层次分论点，统一支持技术解决方案这个大题目。
具体功能模块后面跟着一大堆章节就更奇怪，里面每个都是具体的功能模块，为什么成为和具体功能模块平级的内容？
应该设置为具体功能模块子章节为妥。
很多人可能觉得用户对这个点很关心，要重点突出，所以一定要单独立一个章节，其实不必然，结构清晰的方案用户看起来才不费心，反而想这个方案，将具体功能模块，报表及明细汇总、应用工具及封装接口、用户及权限管理、拼图打印、编码管理列为同一层面内容，反而叫人看不出排列的思路，在厚厚一大本方案中寻找对应关心内容并不容易。
其实不如把技术解决方案分为两大部分，一部分介绍整个方案的实现思路，对于工作比较忙的人可以看这块中对企业业务和逻辑的分析是否到位，相当于整个方案的精华版；
一部分介绍整个方案的技术支撑模块，对于项目具体负责人就可以深入研究技术支撑和业务思路之间是否存在合理的组织关系。
在第二部分技术支撑模块中根据业务逻辑或业务顺序设计功能模块的介绍。
例如一般企业是首先考虑静态技术资料的受控管理，在受控的基础上要求尽可能集成设计软件中的信息，然后要对设计过程建立严密的动态控制体系，此外还希望得到一些设计过程的专业支持，例如变型设计，二级工艺路线管理等等，最后要求提供一些编码，企业资源库等等辅助工具。
这就是我们实现企业需求的一个大的业务思路，在这个业务思路下我们可以将技术支撑模块分为相应的五个部分。
到这里，整个方案大的框架就有了，我们需要设计一下分标题，使用户一看就可以进入自己关心的内容，而且每个部分都是对所属总标题的呼应支持，在业务环节上也是“相互独立，彼此穷尽”的环节。
在标题的设计上不要过于简单，例如技术资料管理，应该说有效的技术资料管理，因为有效才成为技术支撑模块，进而呼应前面业务实现思路中的描述。
业务实现思路
技术支撑模块
2.1有效的技术资料管理
2.2深入的数据集成
2.3严密的过程控制
2.4灵活的设计支持
2.5辅助设计工具
在上面这个思路基础上，我们就开始结合企业业务和产品功能进行考虑分标题下级的结构，我们用第一有效的技术资料管理为例子。
有效的技术资料管理到底要解决哪些业务问题才算完整呢？
我们现在就开始将企业管理技术资料的业务进行罗列，在业务思路中逐步说明。
企业管理技术资料是以产品为线索区分的，所以第一要说清楚产品资料如何管理；
产品下所有零部件是以特征为线索区分的，所以第二要说清楚零部件资料如何管理；
有些零部件还具有共图共工艺的特征，所以第三要说清楚系列零部件资料如何管理；
进一步有的企业还有系列产品，所以第四要说清楚系列产品资料如何管理；
系列产品可能存在大量配置关系，所以第五要说清楚各种规则下产品配置资料如何管理；
有的企业产品配置型号在生产中还存在批次关系，所以第六要说清楚不同产品批次资料如何管理；
有的企业已经存在了大量历史设计资料，所以第七要说清楚历史产品资料如何入库管理；
在资料入库时有个问题每个人管理资料习惯不太一样，全部统一成一种管理方式是必要的，但可能失去一些灵活性，所以第八要说明为个人自组织资料提供哪些支持；
最后要说清楚产品资料为什么入库管理后是安全的；
我们现在总结一下，这些技术资料管理手段如果都提供了，应该是完整而且层次清晰的，这样的话，第一个子标题下的分标题又有了。
2.1.1
产品资料管理
2.1.2
零部件资料管理
2.1.3
系列零部件管理
2.1.4
系列产品管理
2.1.5
产品配置管理
2.1.6
产品批次管理
2.1.7
资料入库管理
2.1.8
个人资料管理
2.1.9
资料安全管理
再看看这个标题和业务思路，这里面体现的一个结构化方式恰恰是“一句话一个意思，一层意思推动一层意思”，到最后就象剥笋一样，层层剥开，问题解决思路也就步步清晰了，企业看起来也就很明白。
那么我们还可以继续细分用户提出的各种业务需求，把企业各种业务要求对号入座，例如下面有一组需求：
有的企业要求用户访问控制；
有的企业要求提供角色权限管理；
有的企业希望按产品目录授权；
有的企业要求全部存放在服务器的数据库中；
有的企业希望支持多数据库独立访问；
有的企业要求提供备份工具等等。
我们现在看看这些业务是否都应该是关心资料安全的？
所以应该放在资料安全管理目录下，而且这些需求也可以分为不同层次，一些是和权限有关的，一些是和存储和备份有关的，这样很快又可以把子标题和分子标题设计出来了。
同样我们可以推导出如下另外几个部分的提纲：
2.2.1
主流CAD的集成
2.2.2CAPP的集成
2.2.3
和其它常用工具软件的集成
2.2.4
数据挖掘统计工具
2.2.5
和其它PDM/ERP系统的集成
2.1审核管理
2.2发布管理
2.3更改管理
2.4项目管理
2.4.1
变型设计业务支持
2.4.2
二级工艺管理业务支持……
2.5辅助设计工具
2.3.1编码管理
2.3.2企业资源管理器……
这个结构化体系一旦出来后，整个方案的思路是否清晰明了，下笔容易了呢？
结构化体系最大的好处是不乱，今后用户提出任何业务需求，或者产品功能如何扩充，都很容易对号入座，或者扩充子标题。
这也是体现了一种分类管理的思想。
当然这个分类思路根据不同业务特征允许存在多种可能，而且分类层次应不超过5级标题，否则文章的可读性不佳。
如果一定要超过5层，就可以采取其它排版方式体现。
2.4第四个容易犯的错误：
口语书面语混杂，遣词造句不严谨。
不好的解决方案还有一个毛病就是口语书面语混杂，遣词造句不严谨。
有的人写作时顺着思路走，口语化成分很多，例如本人的行文基本是口语化的，也体现了这个毛病。
当然大师级人物的确可以将文章写得明白如话，但是对我们这些人而言方案是代表公司正式对外的文档，一定不要出现口语和书面语混杂的情况。
例如太多的儿，的，我们，你们等等都是口语化语言，不应该大量出现在正式方案中。
有的人写方案比较图表现，喜欢指出用户的不足，这个时候喜欢用很激烈的语言。
例如缺少管理，业务失控，后果很严重等等语句，这样的遣词造句是不严谨的，方案用语不要追求“语不惊人誓不休”。
而是理性分析，认真推导，句句讲逻辑。
实在要用一些事实说明企业的问题，不要用刺激性强的语言，例如说企业业务存在问题，可以说业务有可改进的地方，例如说企业管理失控，可以说管理上存在很难受控的环节。
这样的表达企业反而容易接受，不出问题。
2.5第五个容易犯的错误：
没有认真检查，存在大量硬伤。
不好的解决方案制造过程往往是找一个同类方案，然后主要工作是“CTRL+C”+“CTRL+V”。
很多人就图快，省事，没有很好的核对，结果往往容易出现如下几种错误：
第一有些企业在一个方案中用了不同的称呼（这个也要养成一个习惯在一篇方案中一个企业用一个简称和一个全称），替换不完整，结果在方案中出现了其它企业的名称，非常不礼貌；
第二有时候替换过头，把一些案例中类似的话也替换成为给用户名称，闹出笑话。
第三只注意了文字替换，不注意图形中的替换，结果文字是一个用户的，图片是另一个用户的，感觉不尊重。
第四是只注意了文字替换，忽视了页眉页脚的替换，特别是注意了首页或目录的页眉页脚，没有注意正文的页眉页脚。
第五是案例不对，明明是汽车行业的用户，案例全部都是其它行业的，感觉在这个行业没有经验。
第六是联络方式不对，很多时候将别的营销区域方案拿过来用，服务信息都没有更正过来。
第七是存在大量技术硬伤，有时候为了突出软件技术实力，将大量专家都不一定看得懂的词汇大量堆砌，其实连软件公司自己都搞不清楚采用了哪些。
企图通过让用户对概念和名词发晕进而对软件产生信赖的方式已经过时，解决方案应该实事求是说明业务问题，不要在名词上忽悠。
2.6第六个容易犯的错误：
过于突出自我
很多人写方案大量出现“**软件公司”内容，甚至每个产品都恨不得加上自家标识。
在很多地方行文造句都是“我能，我行，我有…”等语气。
这种方案很容易给用户过度营销的感觉。
我们给用户写的方案在售前建议尽量用用户做前缀，例如说某某企业PDM项目，不要总在说某某供应商PDM的话，给用户一种相对的针对性，感觉这个方案的确是为用户准备的。
在售后实施方案中软件公司的名字只需要出现一次，后面就不需要反复出现，因为大家都知道是你的产品，何必反复体现，我们更应该把用户的注意力集中到产品本身就应该具备的功能和支撑业务上，而不要形成某某可以，某某不可以的印象。
2.7第七个容易犯的错误：
没有评审。
方案提交给客户之前，一定要经过评审。
没有开发点的方案，一般经过自评和互评即可，自评时，要重新审视整个方案的结构、问题描述、遣词造句等方面，特别是用替换修改的企业名称和营销平台等方面的内容，尽量减少低级错误。
自己评审过的方案一定要给一个其它的人评审。
互评时，要重新审视整个方案的结构、遣词造句等方面的内容。
对于有开发点的方案，要经过公司的评审。
提交给公司评审的方案，一定是已经过自评和互评的方案，而且要注明主要看哪些部分，以及编写这些部分的背景知识。
2.8第八个容易犯的错误：
没有体现公司产品最新进展。
一般人写解决方案首先不是想着如何说清楚用户的业务，如何在公司产品中体现出对业务的支持，而是想赶紧找一个模板，把这一关走过去再说，其实很多时候就是对每个阶段工作没有质量意识最后导致工作处处被动。
所以写解决方案一定要根据公司最新产品功能认真组合功能实现企业业务，甚至可以考虑利用未来半年内会发布的功能认真组合，因为解决方案离正式实施往往需要半年甚至更长的周期。
很多时候解决方案一抄再抄，都是一两年前的模板，自然缺少竞争力和说服力。
这个问题的核心是公司有没有专人专岗负责对标准解决方案的维护和更新发布机制，其实比较好的一种做法结合典型项目技术公关推动解决方案水平不断完善和提高。
三、写好方案的心得
动笔前先打一个电话
一般情况下方案撰写人只是按照别人要求提供方案，并非直接利用方案的人，所以在写方案之前，问问需要方案的同事，甚至是用户，听听他们对方案的想法和建议，对自己写方案会有很大帮助。
很多时候方案准备完成方案接受者并不满意方案的组织，需要返工修改，所以动笔前先打几个电话，问问别人要什么，不但可以提高方案准备命中率，甚至可以获得大量现成的思路建议，对自己写方案大有好处。
一定要努力按业务逻辑去写。
一般写方案最简单的方式就是按照软件自己的思路和功能模块组织，因为有大量现成的材料可用。
但这样方案对用户并非是一种最佳选择，因为客户要转换到供应商的思维才能看懂方案字句之间的含义。
如果从以客户为中心角度出发，方案应尽量让用户容易看懂，好理解，自然也就取得了几个印象分。
我们方案就是要先仔细探讨企业业务，不是将调研结论一罗列，而是从业务分析得出业务需求，最后描述技术实现手段。
从这个意义上讲，解决方案要按照简明的操作手册来准备。
按标准套路写方案
不同类型的方案都有自己的套路，例如可行性报告，解决方案，建议书等等都有标准的套路，我们应尽量按照标准套路准备方案，不要自成体系，在套路下发挥，套路就体现了一种结构化体系化的思维模式。
关于常用套路我们另有一章说明。
3.4
先构思提纲，经过讨论，最后动笔
很多时候方案准备时间并不充分，很多人接到任务，压力之下立即开始动手，这往往是不好的工作习惯，有时候有模板，的确可以快速出活，但时间长了就养成一种惰性，替换方式抄方案还勉强，真要遇到有个个性化问题，因为在平时写方案过程中思维始终不经过结构化思考的练习，真到方案模板没有覆盖的情况，就没有办法应付。
好的方案特点是：
标题就是论点。
结论做为标题马上拿出来。
好的方案是观点鲜明，立场明确，有理有据，有血有肉。
所以有方案要写，一定不要急着写，而是想自己的提纲，这个完整提纲目录之间的逻辑联系和业务衔接自己在心里面推导得比较有力和充分了，才开始动笔快速拿出提纲，有了提纲写起来思路就不会断电，写起来才快。
好的方案一定是做了论点。
论点是假设的，例如说搞PDM有价值。
你说价值有三个方面，能降低成本，提高质量，能缩短交货期。
这都是你的假设。
你怎么知道成立？
就要找些事实去证明它。
我们现在都喜欢找什么事实呢？
你用了这个功能，所以你的论点就成立，因为你有这个功能，所以你的效率提高了。
这都是扯蛋！
为什么用了PDM企业就能做到这几点。
根本没逻辑推导。
不是还有大把企业用了ERP，用了PDM还不是该咋的咋的，钱都打水漂了。
假如你有好多论点，论点怎么组织呢？
你比如我要搞信息化，信息化有大价值，小价值对不对？
你要把它都列出来，列出后你还要想一想这个价值和那个价值是不是包容的关系？
好处一定是每个好处都是独立，它是有层次，每层上的好处是平级的，大好处包含多个小好处，这些好处倒推出来就响应支持你的论点，这种方案看了以后别人就会理解并支持你。
然后每个好处一定是在前一个好处的基础上往前推动一步，最好得出一个强有力的论证过程。
所以好的方案必
升级会员 