解决方案调研

一、解决方案难写在哪里？很多人对写方案非常没有信心，一涉及到方案的事情，就束手无策，到处求人。作为一个公认的方案打手，意思是写方案就象打字员一样，我觉得我在这方面确实是有绝活。我基本上都是在方案提交前一两天接到写方案的任务，而我自己的事情一般又比别人多一点，也不能不做，只好心里大骂一句，骂完后就打电话搞清楚别人的要求，边问就边构思整个方案的推导思路和结构提纲。因为你不敢让你的同事知道你只能用很少的一点时间写方案(基本上我真正动笔写方案的时间都在2~4个小时以内)，让他们担心方案的质量和进度保证，进而对自己的后续工作质量没有信心。所以我其实也特别紧张，注意力也特别集中，大脑也高速反应，基本上几分钟电话或面谈完思路基本就有了，然后该干嘛干嘛，找一些零散的小时间把思路不断推导一下，然后到了一个比较安静和完整的时间段前才开始写，这个时候基本上要写的话都想清楚了，只需要不断敲字，敲字的时候也是注意力也特别集中，大脑也高速反应，越写思路越开，很快也就完工了。写方案不难，知道怎么写才难。关于写方案我只总结一点，结构化地去组织你的思想。有结构就有思路，有思路就有方案。另外真正写方案的人，对自己写过的方案是永远不会满意的，只有这样，每次都会进步一点点，解决方案水平质量就会随公司能力不断增长。当然我曾经问过很多人，你到底为什么写不出好的方案呢？基本上原因可以归为四类：1.1第一种是没有体系一旦用户要求提供关于PDM的方案，很多人大脑是一片空白，完全不知道从哪里下手。很多人说起自己的产品来，好象知道不少卖点，不过真要写出来，又觉得无从下笔。这种情况一般是写方案者不熟悉自己产品体系造成的，知道一两个甚至的产品卖点不难，但难就难在成体系，知识就是成体系的点构成的，而不是一句一句离散的说法构成的。因为我们这个行业从业人员说句不客气的话，大部分对所销售实施的管理系统并没有很深入的研究，都是半路出家，从头开始，在学习过程中熟悉，在熟悉过程中领悟。所以一下子去驾驭一个整体方案是很痛苦的。只有当一个人对一个产品思路有体系以后，才能够写出完整的方案，否则就是一个单元也要费尽脑汁。所以一个人要想写好一个方案，首先要把自己产品的来龙去脉，功能模块，适应领域，典型客户实施情况有一个全面的了解，这样才能建立一个完整的知识体系，然后逐步补充竞争对手知识和一些技术性知识，不断深化自己的知识体系。1.2第二种是没有思路有很多用户看多了模板化的方案以后，想看一些针对他们自己的业务的个性化内容，这个时候有的人按照标准方案模板修改还勉强能对付，但对于个性化内容针对性方案就速手无策了。这种情况从根本上讲还是写方案者不熟悉企业业务造成的，写方案，特别是针对性方案不仅仅要求了解企业的需求，而且要知道这些需求是在何种业务需求下产生的，用户提出这样的要求到底想解决什么问题，把这个问题找出来，一般针对性解决思路就有了，有了思路，自然可以很好的写方案。所以一个人要写好方案，还需要了解下游客户的业务，了解业务最有效的方法就是亲自做几次详尽的业务调研，有了业务调研做基础，在调研过程中把握用户关注重难点问题，自然可以比较好的确定方案的个性化内容思路。解决方案就是把客户的利益和产品特性之间建立一个逻辑性的桥梁。1.3第三种是没有素材一般不经常写方案的人，在写一个方案的时候，即使有想法，有思路，但往往也会很累，就是因为缺少足够的素材。很多项目现在都是投标，不同用户可能有不同投标的要求，这样很难用一个方案去适应所有的用户，因此在每个方案中都有一些需要准备的内容。这些内容基本上是通用的，但如果没有足够积累每次编制方案就需要花费大量时间去准备，造成方案完成周期过长。所以写好方案必须具备这三个条件，第一方案编制者对企业业务要很熟悉，或者有相关业务调研经验，第二方案编制者对产品非常熟悉，至少对自己产品功能模块作用很清楚，第三方案编制者手上有大量可公用的素材库。1.4第四种是没有层次很多人刚和用户接触没有多久，为了表现自己对客户的重视，马上表示要提供方案，当然有的客户刚刚开始选型，也不知道到底要什么搞，也要供应商马上提供一个方案。结果拍胸脯容易，写方案难，自己写不出来只好求公司，公司没有安排专人了解情况，只好按模板制作一个，用户一看几个供应商内容都差不多，觉得不好，又总结出一些个性化要求，于是大家有开始折腾第二轮方案。其实方案编制在不同阶段有不同策略，不要轻易提供方案。刚开始接触是可以提供项目合作建议书，类似可行性报告，项目需要考察软件技术，可以提供标准的产品技术白皮书，到了经过售前调研，有所准备，在演示前后阶段和其它竞争对手刺刀见红的时候，才在知己知彼的基础上提供解决方案或者投标书。过早提供方案只能匆匆了事，时间紧急，质量自然不高，自然也就觉得方案难写。想急就又能解决问题的事情，本来就是一般人做不来的。方案想要写得好，一定要用心，用心就一定要耗时间，指望用几个小时写出一个高质量的方案是不可能的。如果你做了精心调研，你写不出一个好方案唯一缺的是技巧。写方案是一种技巧性工作，明白了这一点，大家都可以经过练习写出好的方案。二、坏的解决方案有那些特征2.1第一个容易犯的错误：只有论点，没有论证不好的解决方案粗看起来非常厚重，其实都是功能罗列，象产品手册摘要版，不象方案书。不好的方案是一大堆内容，淹没在一堆纸里面，也不知道想说什么，给你一个厚度，证明我们的工作质量很高。我们国内许多的企业客户特别是大型企业都很在乎这点，认为可以从方案厚薄中看出对项目重视程度。如果你做了精心调研，你写不出一个好方案唯一缺的是技巧。写方案是一种技巧性工作，有个金字塔式的写做原理，也就是说文章一定是有结构的。所以真正好的方案，不一定厚，但能看出你用心，你认真。现在的解决方案一个不好的倾向是“长、厚、全”，看起来面面俱到，其实对决策者没有帮助。所有的方案无差异性，每家供应商都说自己能解决这些问题，而且都有成功案例。结果所有的方案都无法给决策者简明的判断依据，不得不费更大劲去做产品演示和用户考察。其实很少有企业高管不知道自己的毛病，在企业你随便去找一个人，对问题都能讲一通，在企业你费很大劲可能都找不到一个人能告诉你这些问题可以怎样去解决。通观这个方案并没有研究为什么企业会产生这么多问题？问题是这些问题是什么产生的？为什么出这么多问题？而是不断说“我能！我能！选我，选我！”。如果不能找到解决这些问题的原因，简单地去解决这些现象，就象治病不能治根一样。这样一个模板化，自我膨胀化的方案想打动用户的心是非常困难的。不好的解决方案最大的问题就象写一篇议论文，能够发现问题(这个也是模板化的，可惜中国企业大部分没有意识到自己很多问题并不少见，总以为自己是特殊的一类企业)，提出答案(搞信息化)，但没有论证(为什么搞信息化和企业管理进步有联系呢？)。没有论证的东西不管内容陈列得多么繁复，名词多么吓人，但是无法打动用户，特别是那种理性的用户。看到方案时候，其实很多用户下不决心，他会感觉每家都差不多。如果从没看过方案的人，突然看到这几个方案，你为什么会感觉某个方案写得好呢，关键是有的方案图画的好，通过图，通过表，会感觉这个公司还不错，很规范。但对内容认可程度并不高，实际上没看懂。2.2第二个容易犯的错误：业务解决方案成为功能列表解决方案省事的一种方法就是将产品功能描述作为技术方案内容进行罗列，或者参照软件用户手册罗列，这种解决方案不是按照用户业务去准备的内容，而是按照软件商自己的喜好去编制的解决方案是很难得到用户认可的。大凡按照功能列表组织的解决方案用户会有一个体会，庞大而庸长，但要看到自己想看到的部分非常困难。而且这种方案还有一个特点，一个问题反反复复的提，在业务背景中指出某个问题，讲一通，在价值分析中又重点解释一通，到了功能介绍时又将某个问题来龙去脉概要说明一下，给用户感觉是一堆资料的堆积，哪里体现出了方案的针对性呢？按功能列表准备方案的做法在很长一段时间内不会消失，这和我们普遍是4P销售人员，还缺少SPIN(顾问式)销售人员有关，在资源不足的情况下，要保证效率就只能提供功能列表方案了。2.3第三个容易犯的错误：结构不清晰不好的解决方案最共性的毛病是结构不太好，没有清晰的思路。没有思路的方案质量很低，用户在审阅过程中也不会体会到和一个专人人士通过文字交流的乐趣，他不得不从供应商混乱的思路中发掘亮点，看看到底是谁能解决企业的问题，真是一件痛苦的工作。一种常见的方案结构毛病就是重复的内容在不同的章节反复出现例如在第一章介绍了对某个问题的分析，提出企业的需求，这第二章介绍方案价值的时候又用不同语句组织类似内容，到第三章解决方案描述中还是要把问题描述一遍，给人感觉思路不连贯，结构臃肿。这里有一个方案提纲的提纲，我们以这个提纲为例子说明结构不清晰的方案。1公司简介及资质文件1.1公司简介 1.2自有产品及代理产品情况 1.3重点工程介绍 1.4公司资质复印件 2分项标价表 3 ***PDM系统技术解决方案 1 ***PDM系统技术解决方案 2 ***PDM系统具体功能模块 3报表及明细汇总 4应用工具及封装接口 5用户及权限管理 6拼图打印 7编码管理 4实施计划 4.1实施步骤 4.2实施计划 5培训计划 3.1系统培训对象 3.2主要培训内容 3.3培训方式 6实施人员资质 6.1实施人员组成及工作职责 6.2实施人员资质说明 7质量保证及售后服务 7.1质量保证 7.1.1工程技术力量的研发水平 7.1.2工程技术力量的实践经验 7.1.3管理水平7.2售后服务承诺 7.2.1技术支持与服务的内容和承诺7.2.2技术支持与服务的保障 8开目典型用户 9有关技术秘密的声明 10附件这个方案第一部分、第二部分是用户投标要求，必须如此，但第三部分技术解决方案应该是重点，这个部分结构就很奇怪。一般好的方案结构标题就是论点，内容就是用事实进行论证，子目录是上级总目录论点的分论点，逐层论证下来，方案显得逻辑性结构性很强，看看目录就能看出方案的逻辑推导体系。这就是所谓金字塔文档体系。这个方案显然不是这样的，看起来一大堆内容，有经验的人一看就知道是内容的罗列。例如第三部分总标题是技术解决方案，结果第一个子标题还是技术解决方案，撞车！一定层次感都没有。而且第一子章节技术解决方案后马上是功能模块，技术解决方案理论上包括功能模块，不是一个层面的东西，技术解决方案应该和实施策略，服务策略平级的内容，所以一定要谈谈自己技术解决方案，不如用技术解决方案思路或者特色来表达，和功能模块也就是一个层次分论点，统一支持技术解决方案这个大题目。具体功能模块后面跟着一大堆章节就更奇怪，里面每个都是具体的功能模块，为什么成为和具体功能模块平级的内容？应该设置为具体功能模块子章节为妥。很多人可能觉得用户对这个点很关心，要重点突出，所以一定要单独立一个章节，其实不必然，结构清晰的方案用户看起来才不费心，反而想这个方案，将具体功能模块，报表及明细汇总、应用工具及封装接口、用户及权限管理、拼图打印、编码管理列为同一层面内容，反而叫人看不出排列的思路，在厚厚一大本方案中寻找对应关心内容并不容易。其实不如把技术解决方案分为两大部分，一部分介绍整个方案的实现思路，对于工作比较忙的人可以看这块中对企业业务和逻辑的分析是否到位，相当于整个方案的精华版；一部分介绍整个方案的技术支撑模块，对于项目具体负责人就可以深入研究技术支撑和业务思路之间是否存在合理的组织关系。在第二部分技术支撑模块中根据业务逻辑或业务顺序设计功能模块的介绍。例如一般企业是首先考虑静态技术资料的受控管理，在受控的基础上要求尽可能集成设计软件中的信息，然后要对设计过程建立严密的动态控制体系，此外还希望得到一些设计过程的专业支持，例如变型设计，二级工艺路线管理等等，最后要求提供一些编码，企业资源库等等辅助工具。这就是我们实现企业需求的一个大的业务思路，在这个业务思路下我们可以将技术支撑模块分为相应的五个部分。到这里，整个方案大的框架就有了，我们需要设计一下分标题，使用户一看就可以进入自己关心的内容，而且每个部分都是对所属总标题的呼应支持，在业务环节上也是“相互独立，彼此穷尽”的环节。在标题的设计上不要过于简单，例如技术资料管理，应该说有效的技术资料管理，因为有效才成为技术支撑模块，进而呼应前面业务实现思路中的描述。1业务实现思路 2技术支撑模块 2.1有效的技术资料管理 2.2深入的数据集成 2.3严密的过程控制 2.4灵活的设计支持 2.5辅助设计工具在上面这个思路基础上，我们就开始结合企业业务和产品功能进行考虑分标题下级的结构，我们用第一有效的技术资料管理为例子。有效的技术资料管理到底要解决哪些业务问题才算完整呢？我们现在就开始将企业管理技术资料的业务进行罗列，在业务思路中逐步说明。企业管理技术资料是以产品为线索区分的，所以第一要说清楚产品资料如何管理；产品下所有零部件是以特征为线索区分的，所以第二要说清楚零部件资料如何管理；有些零部件还具有共图共工艺的特征，所以第三要说清楚系列零部件资料如何管理；进一步有的企业还有系列产品，所以第四要说清楚系列产品资料如何管理；系列产品可能存在大量配置关系，所以第五要说清楚各种规则下产品配置资料如何管理；有的企业产品配置型号在生产中还存在批次关系，所以第六要说清楚不同产品批次资料如何管理；有的企业已经存在了大量历史设计资料，所以第七要说清楚历史产品资料如何入库管理；在资料入库时有个问题每个人管理资料习惯不太一样，全部统一成一种管理方式是必要的，但可能失去一些灵活性，所以第八要说明为个人自组织资料提供哪些支持；最后要说清楚产品资料为什么入库管理后是安全的；我们现在总结一下，这些技术资料管理手段如果都提供了，应该是完整而且层次清晰的，这样的话，第一个子标题下的分标题又有了。2.1有效的技术资料管理 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深入的数据集成 2.2.1主流CAD的集成 2.2.2 CAPP的集成 2.2.3和其它常用工具软件的集成 2.2.4数据挖掘统计工具 2.2.5和其它PDM/ERP系统的集成 2.3严密的过程控制 2.1审核管理 2.2发布管理 2.3更改管理 2.4项目管理 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.1动笔前先打一个电话一般情况下方案撰写人只是按照别人要求提供方案，并非直接利用方案的人，所以在写方案之前，问问需要方案的同事，甚至是用户，听听他们对方案的想法和建议，对自己写方案会有很大帮助。很多时候方案准备完成方案接受者并不满意方案的组织，需要返工修改，所以动笔前先打几个电话，问问别人要什么，不但可以提高方案准备命中率，甚至可以获得大量现成的思路建议，对自己写方案大有好处。3.2一定要努力按业务逻辑去写。一般写方案最简单的方式就是按照软件自己的思路和功能模块组织，因为有大量现成的材料可用。但这样方案对用户并非是一种最佳选择，因为客户要转换到供应商的思维才能看懂方案字句之间的含义。如果从以客户为中心角度出发，方案应尽量让用户容易看懂，好理解，自然也就取得了几个印象分。我们方案就是要先仔细探讨企业业务，不是将调研结论一罗列，而是从业务分析得出业务需求，最后描述技术实现手段。从这个意义上讲，解决方案要按照简明的操作手册来准备。3.3按标准套路写方案不同类型的方案都有自己的套路，例如可行性报告，解决方案，建议书等等都有标准的套路，我们应尽量按照标准套路准备方案，不要自成体系，在套路下发挥，套路就体现了一种结构化体系化的思维模式。关于常用套路我们另有一章说明。3.4先构思提纲，经过讨论，最后动笔很多时候方案准备时间并不充分，很多人接到任务，压力之下立即开始动手，这往往是不好的工作习惯，有时候有模板，的确可以快速出活，但时间长了就养成一种惰性，替换方式抄方案还勉强，真要遇到有个个性化问题，因为在平时写方案过程中思维始终不经过结构化思考的练习，真到方案模板没有覆盖的情况，就没有办法应付。好的方案特点是：标题就是论点。结论做为标题马上拿出来。好的方案是观点鲜明，立场明确，有理有据，有血有肉。所以有方案要写，一定不要急着写，而是想自己的提纲，这个完整提纲目录之间的逻辑联系和业务衔接自己在心里面推导得比较有力和充分了，才开始动笔快速拿出提纲，有了提纲写起来思路就不会断电，写起来才快。

软件企业会有。 已经安装ERP的公司有。 你可以根据这个线索，找一下，你需要。 推荐百度文档。 

　　调查报告一般由标题和正文两部分组成。　　（一）标题。标题可以有两种写法。一种是规范化的标题格式，即“发文主题”加“文种”，基本格式为“××关于××××的调查报告”、“关于××××的调查报告”、“××××调查”等。另一种是自由式标题，包括陈述式、提问式和正副题结合使用三种。　　（二）正文。正文一般分前言、主体、结尾三部分。　　1．前言。有几种写法：第一种是写明调查的起因或目的、时间和地点、对象或范围、经过与方法，以及人员组成等调查本身的情况，从中引出中心问题或基本结论来；第二种是写明调查对象的历史背景、大致发展经过、现实状况、主要成绩、突出问题等基本情况，进而提出中心问题或主要观点来；第三种是开门见山，直接概括出调查的结果，如肯定做法、指出问题、提示影响、说明中心内容等。前言起到画龙点睛的作用，要精练概括，直切主题。　　2．主体。这是调查报告最主要的部分，这部分详述调查研究的基本情况、做法、经验，以及分析调查研究所得材料中得出的各种具体认识、观点和基本结论。　　3．结尾。结尾的写法也比较多，可以提出解决问题的方法、对策或下一步改进工作的建议；或总结全文的主要观点，进一步深化主题；或提出问题，引发人们的进一步思考；或展望前景，发出鼓舞和号召。

首先，你要明确你所要调研的对象。其次，你要牢牢把握住该对象的特征，特点再其次，根据其特点，寻找合适的解决方案最后，进行统一的总结和规划~~~~希望对你能有所帮助……

去百度文库，查看完整内容>内容来自用户:李云西XXXXXX平台需求调研方案XXXXXX公司2016年11月序号｜调研对象｜相关系统｜调研内容方向｜1｜2｜3｜4｜5｜6｜项目调研采用的主要方式有一下几种，具体调研时，会根据实际情况灵活采用：1.收集客户相关的文档资料，如工作概况、主要业务、业务流程、管理制度、岗位职责，可以从客户的日常工作表单、报表、文书、网站中获取，也可以直接要求客户方提供。2.问卷调查，如事先准备好问卷表，发给相关的业务部门，由业务人员分别填写后收回。3.个别交流，就某一具体问题和业务流程处理和相关的业务代表直接交流。4.开会讨论，对跨部门、跨岗位的业务，可以把相关的业务人员请到一起，了解业务的协作流程情况。5.随公工作调研，跟随办公工作人员，以一次业务任务为头绪，从头到尾，跟随一起工作，深入、细致、具体地了解工作人员的业务真实工作实践情况，从中发现本项目建设目标的细节需求。调研工作的总体时间计划，根据项目合同书和《项目工作说明书》中对项目总体时间周期阶段而制定的细节调研任务计划：职能部门｜时间｜具体调研内容｜调研组员｜客户配合人员｜1、对管理层进行业务架构和主体业务流程汇报和交流确认后，形成业务流程差异及解决方案（或需求规格说明书）。

转载以下资料供参考从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。狭义上理解需求分析指需求的分析、定义过程。原因需求分析就是分析软件用户的需求是什么。如果投入大量的人力，物力、财力、时间，开发出的软件却没人要，那所有的投入都是徒劳。如果费了很大的精力，开发一个软件，最后却不满足用户的要求，从而要重新开发过，这种返工是让人痛心疾首的(相信大家都有体会)。比如：用户需要一个for linux的软件，而你在软件开发前期忽略了软件的运行环境，忘了向用户询问这个问题，而想当然的认为是开发for windows的软件。当你千辛万苦地开发完成向用户提交时才发现出了问题，那时候你是欲哭无泪了，恨不得找块豆腐一头撞死。需求分析之所以重要，就因为他具有决策性、方向性、策略性的作用，他在软件开发的过程中具有举足轻重的地位，大家一定要对需求分析具有足够的重视。在一个大型软件系统的开发中，他的作用要远远大于程序设计。任务简言之，需求分析的任务就是解决“做什么"的问题，就是要全面地理解用户的各项要求，并准确地表达所接受的用户需求。过程需求分析阶段的工作,可以分为四个方面：问题识别、分析与综合、制订规格说明、评审。问题识别：就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求(做什么)、性能需求(要达到什么指标)、环境需求(如机型、操作系统等)、可靠性需求(不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求(软件运行是所需的内存、CPU等)、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。分析与综合： 逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。制订规格说明书： 即编制文档，描述需求的文档称为软件需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。评审： 对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作,否则重新进行需求分析。方法需求分析的方法有很多，这里只强调原型化方法，其它的方法如：结构化方法、动态分析法等，从来没用过这些方法在此不讨论。原型化方法是十分重要的，原型就是软件的一个早期可运行的版本，它实现了目标系统的某些或全部功能。原型化方法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能。但是这个系统可能在可靠性、界面的友好性或其他方面上存在缺陷。建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性、技术的可行性或考察是否满足用户的需求等。如：为了考察是否满足用户的要求，可以用某些软件工具快速的建造一个原型系统，这个系统只是一个界面，然后听取用户的意见，改进这个原型。以后的目标系统就在原型系统的基础上开发。原型主要有三种类型：探索型、实验型、进化型。探索型：目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。实验型：用于大规模开发和实现前，考核方案是否合适，规格说明是否可靠。进化型：目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。在使用原型化方法时有两种不同的策略：废弃策略、追加策略。废弃策略：先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想，据此设计出较完整、准确、一致、可靠的最终系统。系统构造完成后，原来的模型系统就被废弃不用。探索型和实验型属于这种策略。追加策略：先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，发展成为最终系统。进化型属于这种策略。需求分析20条法则客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。1、 分析人员要使用符合客户语言习惯的表达需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。2、分析人员要了解客户的业务及目标只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下旧系统，有利于他们明白系统是怎样工作的，其流程情况以及可供改进之处。3、 分析人员必须编写软件需求报告分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。4、 要求得到需求工作结果的解释说明分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。5、 开发人员要尊重客户的意见如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。6、 开发人员要对需求及产品实施提出建议和解决方案通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。7、 描述产品使用特性客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。8、 允许重用已有的软件组件需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。9、 要求对变更的代价提供真实可靠的评估有不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。10、 获得满足客户功能和质量要求的系统每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。11、 给分析人员讲解您的业务分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。12、 抽出时间清楚地说明并完善需求客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。13、 准确而详细地说明需求编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。14、 及时作出决定分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。15、 尊重开发人员的需求可行性及成本评估所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。16、 划分需求的优先级绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。17、 评审需求文档和原型客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。18、 需求变更要立即联系不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。19、 遵照开发小组处理需求变更的过程为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。20、 尊重开发人员采用的需求分析过程软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。“需求确认”意味着什么在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。 　需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人ONT>

网络调查是指在互联网上针对调查问题进行调查设计，收集资料及分析咨询等活动。网络调查主要有两种方式：一种是利用互联网直接进行问卷调查，收集第一手资料，可称为网上直接调查；另一种是利用互联网的媒体功能，从互联网收集第二手资料，称为网上间接调查（一）明确问题与确定调研目标   明确问题和确定调研目标对使用网上搜索的手段来说尤为重要，不要为之付出了时间和上网费的代价。   因此，在开始网上搜索时，头脑里要有一个清晰的目标并留心去寻找。一些可以设定的目标是：   谁有可能想在网上使用你的产品或服务？  谁是最有可能要买你提供的产品或服务的客户？  在你这个行业，谁已经上网？他们在干什么？  你的客户对你竞争者的印象如何？  在公司日常的运作中，可能要受哪些法律、法规的约束？如何规避？   （二）制定调查计划   网上市场调研的第二个步骤是制定出最为有效的信息搜索计划。具体来说，要确定资料来源、调查方法、调查手段、抽样方案和联系方法。下面就相关的问题来说明：  资料来源：确定收集的是二手资料还是一手资料（原始资料）。  调查方法：网上市场调查可以使用专题讨论法、问卷调查法和实验法。  (1)专题讨论法是借用新闻组、邮件列表讨论组和网上论坛（也可称BBS，电子公告牌）的形式进行。  (2)问卷调查法可以使用E-mail（主动出击）分送和在网站上刊登（被动）等形式。 (3)实验法则是选择多个可比的主体组，分别赋予不同的实验方案，控制外部变量，并检查所观察到的差异是否具有统计上的显著性。这种方法与传统的市场调查所采用的原理是一致的，只是手段和内容有差别。 51调查网，让你的调查更简单方便！

落实调研措施，主要强调（公共关系调研的进度安排、公共关系调研的经费预算和公共关系调研人员的选择）方面。

需求调研是为需要说明书做前期工作，可以说需要说明书说是从需求调研表中得到或抽取而出。需求调研是要了解现实世界中做实际工作的人们真正需要什么样的程序的过程，再把这些需求开进细节整理由设计部开发，再由销售部销售给用户。前期准备1. 确定工具没有什么工具是好还是坏的问题，问题是关键是如何使用它们，无论是什么工具也只是一个辅助工具，也不是生成工具。工具的选取要求是自己（本组）熟悉的工具，不能是一件最新时髦工具而自己对它了解很少，结果大部分时间化在学习工具上，而不是使用它为你工作。工具最好也是要求是普通流行的，因为要考虑交流的问题。2. 要做什么就要先了解什么如果做的项目是你所不了解的一个行业（专业）同组有要最好有要专家----最终用户做为这个专家是最好的，最少你有了解这个专业，不是要你成为专家，但最少要了解一定的专业知识（最少专来词汇你要知道），不然您甚至不知道去问什么问题或者如何去问他们，甚至于人家在说什么你也不知道。相应的专业资料是必须的，最少要有专业入门书籍和对应的资料，也需要求更深入的一些资料。当然有专家的参入就另当别论。如果行业的难度不是很大，可以通入分析人员的自我学习在短时间内了解行业，也许可以不用专家，否则专家是必须的。3. 建立设计环境一定建立一个专门的设计环境来为本项目服务，进行一定的资源分配，进行必要的文件管理。4. 真正了解自己和用户那些是用户可能明确要达到的目地要知道那些是自己能做到的，那些是自己不能做的。对于不能做的处理方法，如拒绝，转包等那些是用户想要做到的5. 列出人员分配表和所有工具列表明确项目人员分工统一项目所用的工具统一项目文件模版其它资源列表（资料，相关网站，资询电话。。。）第3章调研过程3.1. 搜集需求得到需求说明书注意：虽然最终必须要编成基于计算机解决方案的描述，但到目前为止，我们关注的焦点的文档在相应领域方面的部分。记住这里没有计算机方面的行话，如果是编写一个会计软件，那么一位会计师都应该清楚地理解程序员写的会计方面的问题说明书需求说明书问题中，不要太正式。只要描述能表达您想要做的事情就行了，就和另外一个人在说话一样就可以。对于客户或相应人员了解问题时，一定要有记笔记的习惯，谈上几个小时，很多细节是记不住的。整理，检查和细化需求说明书对于客户的需要进行必要的整理和分类有进从用户那里会得到很多信息，不行进必要的整理就不能从中进行合理的分析分清有用功能、可选功能用、无用功能及不可实现功能对于用户来讲他可以说出他想要的很多功能，但这些功能间的关系有时是清晰的，但对于很多用户来讲想通过计算机或新系统实现他以前没有的功能，在这时他所提出的新需求的可行性和与其它模块之间的关系就已经不清，所以对于分析员来讲，要从用户的需求中分清有用功能和无用功能和可选功能，进行分别区分处理，比如不可实现功能请用户放弃。不要忽略明显的错误用户倒是不经常提及他需要的东西，而这些东西对问题来说都是很基本的，要细化检查一定有注意这个问题。你认为的也许不是对的对于系统分析员对需求分析的自认为的情况要加以注意，对于一个行业来说，有些规则可以不是最合理，但它就是那样存在和使用，所以对于每一个非明确确定的需求，要由专业人员来审定。除非你就是专家。改进最初的第一次需求在分析，细化一定有不明及不确定之处，那么就把整理出一份问题细化问询表，对发现的问题进行整理，列出不明之处，可根椐以下格式问询人： 问题： 业务不清问题列表（业务描述不清）： 1 ….是什么含义？ 2 …..与XX是什么关系？ 多种选择可以列表（请用户进行选择）： 1 ……有多个可能，那么现在我们使用 A …… B……. C…….. D …… 把问询表提交用户，根据反馈对需求再分析，这个步骤可重复多次，最终了解需求，确定需求说明书审核需求自我审枋把自己从用户的角度来考虑是否合理，是否可以提高效率，是否可以达到目的，是否有完整由用户来评价由最终用户来评价你所列的需求是否达到了用户要求（用户人数1-3人，再多也没有什么益处）。重复过程，最终通过审核完成需求说明书