1、只有论点，没有论证
现在的解决方案一个不好的倾向是“长、厚、全”，看起来面面俱到，其实对决策者没有帮助。所有的方案无差异性，每家供应商都说自己能解决这些问题，而且都有成功案例。结果所有的方案都无法给决策者简明的判断依据，不得不费更大劲去做产品演示和用户考察。
通观这个方案并没有研究为什么企业会产生这么多问题？问题是这些问题是什么产生的？为什么出这么多问题？而是不断说“我能！我能！选我，选我！”。
如果不能找到解决这些问题的原因，简单地去解决这些现象，就象治病不能治根一样。这样一个模板化，自我膨胀化的方案想打动用户的心是非常困难的。
不好的解决方案最大的问题就象写一篇议论文，能够发现问题，提出答案(搞信息化)，但没有论证(为什么搞信息化和企业管理进步有联系呢？)。没有论证的东西不管内容陈列得多么繁复，名词多么吓人，但是无法打动用户，特别是那种理性的用户。
2、业务解决方案成为功能列表
解决方案省事的一种方法就是将产品功能描述作为技术方案内容进行罗列，或者参照软件用户手册罗列，这种解决方案不是按照用户业务去准备的内容，而是按照软件商自己的喜好去编制的解决方案是很难得到用户认可的。大凡按照功能列表组织的解决方案用户会有一个体会，庞大而庸长，但要看到自己想看到的部分非常困难。
而且这种方案还有一个特点，一个问题反反复复的提，在业务背景中指出某个问题，讲一通，在价值分析中又重点解释一通，到了功能介绍时又将某个问题来龙去脉概要说明一下，给用户感觉是一堆资料的堆积，哪里体现出了方案的针对性呢？
3、结构不清晰
不好的解决方案最共性的毛病是结构不太好，没有清晰的思路。
没有思路的方案质量很低，用户在审阅过程中也不会体会到和一个专人人士通过文字交流的乐趣，他不得不从供应商混乱的思路中发掘亮点，看看到底是谁能解决企业的问题，真是一件痛苦的工作。
一种常见的方案结构毛病就是重复的内容在不同的章节反复出现例如在第一章介绍了对某个问题的分析，提出企业的需求，这第二章介绍方案价值的时候又用不同语句组织类似内容，到第三章解决方案描述中还是要把问题描述一遍，给人感觉思路不连贯，结构臃肿。一般好的方案结构标题就是论点，内容就是用事实进行论证，子目录是上级总目录论点的分论点，逐层论证下来，方案显得逻辑性结构性很强，看看目录就能看出方案的逻辑推导体系。这就是所谓金字塔文档体系。
4、口语书面语混杂，遣词造句不严谨
不好的解决方案还有一个毛病就是口语书面语混杂，遣词造句不严谨。
有的人写作时顺着思路走，口语化成分很多，当然大师级人物的确可以将文章写得明白如话，但是对我们这些人而言方案是代表公司正式对外的文档，一定不要出现口语和书面语混杂的情况。
例如太多的儿，的，我们，你们等等都是口语化语言，不应该大量出现在正式方案中。
有的人写方案比较图表现，喜欢指出用户的不足，这个时候喜欢用很激烈的语言。例如缺少管理，业务失控，后果很严重等等语句，这样的遣词造句是不严谨的，方案用语不要追求“语不惊人誓不休”。而是理性分析，认真推导，句句讲逻辑。
实在要用一些事实说明企业的问题，不要用刺激性强的语言，例如说企业业务存在问题，可以说业务有可改进的地方，例如说企业管理失控，可以说管理上存在很难受控的环节。
5、没有认真检查，存在大量硬伤。
很多人就图快，省事，没有很好的核对，结果往往容易出现如下几种错误：
第一有些企业在一个方案中用了不同的称呼(这个也要养成一个习惯在一篇方案中一个企业用一个简称和一个全称)，替换不完整；
第二有时候替换过头，把一些案例中类似的话也替换成为给用户名称，闹出笑话。
第三只注意了文字替换，不注意图形中的替换，结果文字是一个用户的，图片是另一个用户的，感觉不尊重。
第四是只注意了文字替换，忽视了页眉页脚的替换，特别是注意了首页或目录的页眉页脚，没有注意正文的页眉页脚。
第五是案例不对，明明是汽车行业的用户，案例全部都是其它行业的，感觉在这个行业没有经验。
第六是联络方式不对，很多时候将别的营销区域方案拿过来用，服务信息都没有更正过来。
第七是存在大量技术硬伤，有时候为了突出软件技术实力，将大量专家都不一定看得懂的词汇大量堆砌，其实连软件公司自己都搞不清楚采用了哪些。
企图通过让用户对概念和名词发晕进而对软件产生信赖的方式已经过时，解决方案应该实事求是说明业务问题，不要在名词上忽悠。
6、过于突出自我
很多人写方案大量出现“**软件公司”内容，甚至每个产品都恨不得加上自家标识。在很多地方行文造句都是“我能，我行，我有…”等语气。
这种方案很容易给用户过度营销的感觉。我们给用户写的方案在售前建议尽量用用户做前缀，例如说某某企业PDM项目，不要总在说某某供应商PDM的话，给用户一种相对的针对性，感觉这个方案的确是为用户准备的。
7、没有评审
方案提交给客户之前，一定要经过评审。
没有开发点的方案，一般经过自评和互评即可，自评时，要重新审视整个方案的结构、问题描述、遣词造句等方面，特别是用替换修改的企业名称和营销平台等方面的内容，尽量减少低级错误。
自己评审过的方案一定要给一个其它的人评审。
互评时，要重新审视整个方案的结构、遣词造句等方面的内容。
对于有开发点的方案，要经过公司的评审。提交给公司评审的方案，一定是已经过自评和互评的方案，而且要注明主要看哪些部分，以及编写这些部分的背景知识。
8、没有体现公司产品最新进展
一般人写解决方案首先不是想着如何说清楚用户的业务，如何在公司产品中体现出对业务的支持，而是想赶紧找一个模板，把这一关走过去再说，其实很多时候就是对每个阶段工作没有质量意识最后导致工作处处被动。所以写解决方案一定要根据公司最新产品功能认真组合功能实现企业业务，甚至可以考虑利用未来半年内会发布的功能认真组合，因为解决方案离正式实施往往需要半年甚至更长的周期。
很多时候解决方案一抄再抄，都是一两年前的模板，自然缺少竞争力和说服力。这个问题的核心是公司有没有专人专岗负责对标准解决方案的维护和更新发布机制，其实比较好的一种做法结合典型项目技术公关推动解决方案水平不断完善和提高。
更多内容：
微信号：方案智库
