如何写解决方案.docx

如何写解决方案.docx

《如何写解决方案.docx》由会员分享，可在线阅读，更多相关《如何写解决方案.docx（7页珍藏版）》请在冰豆网上搜索。

如何写解决方案

如何写解决方案

一旦用户要求提供建设方案，很多人大脑是一片空白，完全不知道从哪里下手。

很多人说起自己的产品来，好象知道不少卖点，不过真要写出来，又觉得无从下笔。

写出一篇好的技术文档是一个专业软件工程师的必要素养！

我们必须抛弃那种软件工程师只要能写出漂亮的代码就行了的思想，而是要将“写好每一篇技术文档是专业软件工程师的必要素养”这一句话深入到我们的骨髓当中去，只有这样，我们所写的技术文档才会越来越好、才会越来越专业。

一、文档格式

文档的格式上存在不一致性的问题。

格式有时是这样，有时是那样。

一篇好的文档我想不光是内容写得好，其格式是很重要的一部分。

试想，如果我们拿到了一篇格式上写得乱七八糟的文档，这一第一印象会影响我们的阅读心情吗？

好的文档应当是从头到尾保持格式的一致性，这不仅仅是一种美，更是专业性的一种表现。

1）对于格式问题，找一篇自己觉得格式不错的文档进行模仿，并将其做成一个模板，每次写作时以这一模板为基础。

二、文档的面向对象

你写给谁看？

2）写文档的作者不能很好的站在读者的角度去思考。

要写出一篇好的支持文档，作者应当站在读者的角度上去写。

这简单的一句话，要操作起来，将其做好，还真不是一件容易的事。

在写文档时，如果不站在读者的角度去思考，很容易写出一篇“自己一看觉得清清楚楚，别人一看却糊里糊涂”的文档。

2）写完以后，假设自己是读者多次阅读自己的文档。

这一点要做好还是很难的，因为，我们很难完全站在读者的角度去读自己写的文档，我们不知道自己所知的哪些东西是读者所不知的，即很难界定与读者知识不对称的分界点。

为了提高这一点，我想我们写文档时，应当多问自己一些问题，比如，读者具有与我一样的知识和经验吗？

如果没有，我应当写哪些以弥补这种信息的不对称性呢？

我写的这篇文档是基于一定的假设吗？

如果是，是否应当将这一假设在文档中交代清楚呢？

我所写的内容是否都在支持文档的主题呢？

是否存在正交问题（即答非所问的问题）？

等等。

除了你所提供的内容，对方还有什么额外关注的地方？

三、长度？

3）文档求长不求精。

一说到写文档，我不知是否有人将“文档应当长”当作是文档的必要属性。

对于这一点，我想正确的态度是：

求精不求长。

一篇好的文档，应当写得简练易懂。

写文档的目的是什么？

是为了让别人明白我们所要说明的问题，要说明问题，并不需要一定将其写得长。

一篇精炼的文档也意味着效率，即读者花很少的时间就明白我们想要表达的问题是什么。

当然，从作者的角度来看，要写一篇精炼的文档，那得花更多的时间去斟酌。

3）在文档写完后多问一问自己，这篇文档还能写得更简单吗？

是否可以将一些文字省去并用一幅图取而代之以达到使其简练的目的呢？

不防时刻对自己说，简单也是一种美！

四、表现方式

4）图太少。

有图不是一篇好文档的必要条件，但在不少情况下，用一幅图能很好的表达我们的思想，不是有那么一句话吗“好图胜过千言万语”，适当的采用一些图，一方面能为文档增色，另一方面也能更好的向读者传达我们的意图。

4）学习（并精通）一些行业所需的图形语言和工具，并加以运用。

比如，我们软件行业的UML就是很好的一种表达语言，且随着UML的发展，其表达能力更加的强大。

目前，业内有很我UML的工具，找一个不错的就行了，比如VisualParadigm的UML工具就不错，工具其实只是一种工具，关键是掌握UML。

只有我们很好的掌握一种图形语言，我们才有可能随时加以运用，从而为我们的技术文档服务。

当然，像Microsoft的Viso也是不错的绘图工具，这要看我们想表达的是什么，从而加以灵活运用各种工具。

五、先做厚，再做薄

一般不经常写方案的人，在写一个方案的时候，即使有想法，有思路，但往往也会很累，就是因为缺少足够的素材。

很多项目现在都是投标，不同用户可能有不同投标的要求，这样很难用一个方案去适应所有的用户，因此在每个方案中都有一些需要准备的内容。

这些内容基本上是通用的，但如果没有足够积累每次编制方案就需要花费大量时间去准备，造成方案完成周期过长。

第一方案编制者对企业业务要很熟悉，或者有相关业务调研经验，第二方案编制者对产品非常熟悉，至少对自己产品功能模块作用很清楚，第三方案编制者手上有大量可公用的素材库。

六、文档结构

有些事情，能说清楚，不代表能写清楚；写清楚，一定是你能说清楚。

其实，就是个思路的问题。

有结构就有思路，有思路就有方案。

我曾经问过很多人，你到底为什么写不出好的方案呢？

基本上原因可以归为四类：

1、第一种是没有体系

这种情况一般是写方案者不熟悉自己产品体系造成的，知道一两个甚至更多的产品卖点不难，但难就难在成体系，知识就是成体系的点构成的，而不是一句一句离散的说法构成的。

要想写好一个方案，首先要把项目的来龙去脉，功能模块，适应领域，典型客户实施情况有一个全面的了解，这样才能建立一个完整的知识体系，然后逐步补充竞争对手知识和一些技术性知识，不断深化自己的知识体系。

2、第二种是没有思路

有很多用户看多了模板化的方案以后，想看一些针对他们自己的业务的个性化内容，这个时候有的人按照标准方案模板修改还勉强能对付，但对于个性化内容针对性方案就束手无策了。

写方案，特别是针对性方案不仅仅要求了解企业的需求，而且要知道这些需求是在何种业务需求下产生的，用户提出这样的要求到底想解决什么问题，把这个问题找出来，一般针对性解决思路就有了，有了思路，自然可以很好的写方案。

了解业务最有效的方法就是亲自做几次详尽的业务调研，有了业务调研做基础，在调研过程中把握用户关注重难点问题，自然可以比较好的确定方案的个性化内容思路。

解决方案就是把客户的利益和产品特性之间建立一个逻辑性的桥梁。

3、第四种是没有层次

很多人刚和用户接触没有多久，为了表现自己对客户的重视，马上表示要提供方案，当然有的客户刚刚开始选型，也不知道到底要什么搞，也要供应商马上提供一个方案。

方案编制在不同阶段有不同策略，不要轻易提供方案。

刚开始接触是可以提供《项目合作建议书》，类似可行性报告，项目需要考察软件技术，可以提供标准的产品技术白皮书，到了经过售前调研，有所准备，在演示前后阶段和其它竞争对手刺刀见红的时候，才在知己知彼的基础上提供解决方案或者投标书。

过早提供方案只能匆匆了事，时间紧急，质量自然不高，自然也就觉得方案难写。

想急就又能解决问题的事情，本来就是一般人做不来的。

方案想要写得好，一定要用心，用心就一定要耗时间，指望用几个小时写出一个高质量的方案是不可能的。

如果你做了精心调研，你写不出一个好方案唯一缺的是技巧。

写方案是一种技巧性工作，明白了这一点，大家都可以经过练习写出好的方案。

容易犯的错误：

1、只有论点，没有论证不好的解决方案粗看起来非常厚重，其实都是功能罗列，象产品手册摘要版，不象方案书。

不好的方案是一大堆内容，淹没在一堆纸里面，也不知道想说什么，给你一个厚度，证明我们的工作质量很高。

我们国内许多的企业客户特别是大型企业都很在乎这点，认为可以从方案厚薄中看出对项目重视程度。

真正好的方案，不一定厚，但能看出你用心，你认真。

现在的解决方案一个不好的倾向是"长、厚、全"，看起来面面俱到，其实对决策者没有帮助。

所有的方案无差异性，每家供应商都说自己能解决这些问题，而且都有成功案例。

结果所有的方案都无法给决策者简明的判断依据，不得不费更大劲去做产品演示和用户考察。

其实很少有企业高管不知道自己的毛病，在企业你随便去找一个人，对问题都能讲一通，在企业你费很大劲可能都找不到一个人能告诉你这些问题可以怎样去解决。

通观这个方案并没有研究为什么企业会产生这么多问题？

问题是这些问题是什么产生的？

为什么出这么多问题？

而是不断说"我能！

我能！

选我，选我！

"。

如果不能找到解决这些问题的办法，简单地去解决这些现象，就象治病不能治根一样。

这样一个模板化，自我膨胀化的方案想打动用户的心是非常困难的。

不好的解决方案最大的问题就象写一篇议论文，能够发现问题，提出答案（搞信息化），但没有论证（为什么搞信息化和企业管理进步有联系呢？

）。

没有论证的东西不管内容陈列得多么繁复，名词多么吓人，都无法打动用户，特别是那种理性的用户。

看到方案时候，其实很多用户会感觉每家都差不多。

如果从没看过方案的人，突然看到这几个方案，你为什么会感觉某个方案写得好呢，关键是有的方案图画的好，通过图，通过表，会感觉这个公司还不错，很规范。

但对内容认可程度并不高，实际上没看懂。

2、解决方案成为功能列表解决方案省事的一种方法就是将产品功能描述作为技术方案内容进行罗列，或者参照软件用户手册罗列，这种解决方案不是按照用户业务去准备的内容，而是按照软件商自己的喜好去编制的解决方案是很难得到用户认可的。

大凡按照功能列表组织的解决方案，用户会有一个体会---大而庸，但要看到自己想看到的部分非常困难。

而且这种方案还有一个特点，一个问题反反复复的提，在业务背景中指出某个问题，讲一通，在价值分析中又重点解释一通，到了功能介绍时又将某个问题来龙去脉概要说明一下，给用户感觉是一堆资料的堆积，哪里体现出了方案的针对性呢？

按功能列表准备方案的做法在很长一段时间内不会消失，这和我们普遍是4P销售人员，还缺少SPIN（顾问式）销售人员有关，在资源不足的情况下，要保证效率就只能提供功能列表方案了。

售前售后解决方案培训售前售后难点是做一个专业的通用方案（这个方案估计一个月你都写不出），所以每个方案需要提供2到3种技术配置方案，而且都是可行的，这样可以拿几个方案吃通某个行业用户了，但是，不是说售前售后有了方案就完了，方案只是开始，里面庞大的技术细节（功能，原理，系统，演示），及产品知识是售前售后必须掌握的。

一般要为客户撰写的售前售后方案分为：

项目建议书、项目解决方案、项目投标书。

项目建议书用于动员客户启动项目，为客户启动项目提供何行性建议分析，或者用于客户初步选型阶段，获得调研机会后再编制解决方案。

解决方案用于恰谈技术协议和合同之前产品技术交底，或者用于议标阶段，重在介绍软件供货商的技术能力和实施服务能力等方面的优势。

投标书用于客户的招标文档，按照客户要求的格式进行发挥，要充分说明公司各个方面的综合实力，以战胜对手。

项目建议方案基本结构：

1引言2企业业务现状分析3项目目标规划3.1项目规划原则3.2项目总体目标和分阶段目标3.3项目预期周期规划4项目必要性分析5项目可行性分析5.1相关技术的发展现状介绍5.2软件公司相关产品的能力分析5.3企业具备的管理、硬件、组织和技术基础6项目的经济效益分析7结束语建议方案的要求是简短紧凑，目标规划清楚，便于高层决策，可以在一份建议书中列出几个可选技术方案，推动客户高层决策。

同时可以加些图片介绍等生动感官。

主要用于初次拜访、以领导决策对象为主。

解决方案的参考结构：

1引言2业务现状分析3系统架构规划3.1总体目标3.2指导思想3.3总体功能框架3.4硬件部署体系……4系统业务技术解决方案

4.1关键业务问题解决方案（可多个）4.2关注重点技术问题介绍4.3其他标准功能介绍……5系统实施方案5.1实施管理方法5.2实施团队构成5.3实施计划5.4各阶段双方工作配合说明5.5风险分析及对策（针对不同情况可选择）5.6沟通和质量保证5.7培训计划5.8系统预期阶段效益……6服务内容及措施7典型案例8结束语（合作建议）9附件（软件公司介绍）售前阶段不要轻易提供解决方案要充分了解客户需求搞清楚、问明白。

解决方案难写在哪里？

1.没有体系2.没有个性3.没有素材4.没有时间不好的解决方案十个特点1.只有厚度，没有质量2.只有论点，没有论证3.结构不清晰4.业务解决方案成为功能列表5.口语书面语混杂，遣词造句不严谨。

6.没有认真检查，存在大量硬伤。

7.过于突出自我8.没有体现公司产品最新进展9.文字太多，图表很少10.没有评审好的方案应该设计一个好的封面，好封面的标准就是有视觉冲击力。

建议书的要求是简短紧凑，内容详实，目标规划清楚，便于客户高层决策，可以在一份建议书中形成几个可选技术方案，推动客户高管决策。

实施方案的要害是具不具备可操作性。

这里面判断方法就是实施计划越是结合业务细化越具有可操作性。

投标书一定要坚决按照客户提供的招标书要求准备，客户如何要求就如何提供数据，不要任意发挥。

解决方案写法交流方案框架（以下是简单写法）：

一、引言主要讲信息化趋势，企业所属行业，特别是竞争对手的信息化动向。

二、企业现状分析主要是问题分析，问题是指信息化可以解决的问题，无关的问题不要谈。

这些问题有共性，比如：

信息孤岛无法集成和共享，企业流程效率低下，成本无法有效控制等等，同时，也要分析本企业及所属行业的一些特殊性问题，比如：

安全审计行业在不同行业的不同需求。

这些问题的写法可以借鉴一些公司的方案，尤其是问题的表达，很多公司的方案还是比较典范。

三、信息化如何解决这些问题。

本部分是重中之重，一般说来，要分成以下小章节。

1。

关键业务流程，信息化功能实现（重点，用流程图，说明信息化功能实现，特别是如何解决企业现在面临的问题）2。

流程优化。

3。

企业最佳业务实践复制。

四、实现的价值和收益要区分可以计量的，和不可以计量的，可以计量的，甚至可以细化到资产负债表事项。

五、项目实施初步规划可以用图作简单描述，说明时间，阶段，成果，参与人员等。

六、项目资金概算。

软硬件投资，咨询费用，新增的项目组人员薪资等。

这个概算，也是作为一个初步报价的过程，具体价格要慎重，不可多写，也不要少写，摸清对方心理底线。

七、一些建议。

如，尽快启动项目，要注重项目组成员的福利待遇等等。

文字尽量控制在100页以内比较好，同时，一定要出一个简化版本，将方案浓缩在3页，5页A4纸上，这样便于领导查看主要数据。