清理电脑,十数年来,无数资料,近来每天抽空好好整理整理, 做IT的特别是整ERP的,四个字形容:命苦可怜.发现本给IT项目经理的好书.内容简介
这个世界上写给项目经理的书很多，写给IT项目经理的书也不少，但写给从事管理软件实施的项目管理书籍并不多。
而笔者在从事项目经理工作中感到一个很苦恼的问题是，很多书其实非常经典，但都有一个缺点：理论正确，实战指导作用不足。
不是亲身亲历的人是很难领悟到那些理论的精髓，而每个刚刚入行又立志成为一个IT实施的新人往往不是一开始就能从理论上武装自己，在他们起步的时候，每天要面临着各种具体工作任务，例如做调研，写计划，写方案，写备忘录，做项目汇报，做演示，这些活动与其说是项目管理发挥作用大，不如说这是具体业务技能的领域。
一个IT人如果没有经受专业的培训，在不能掌握这些技能之前，我个人体会是往往是努力的把事情做砸。
目前的IT服务质量更大程度上取决于实施人员个人能力，也许只有有一大批同等质量服务的实施人员涌现，一个公司的才有可能顺利推进项目管理的思路。
因此笔者就有一个想法，想把自己在项目实施从售前到售后的体会和经验总结为一些专项技能，并希望它具有可操作性，和大家一起交流总结，不断积累并臻于完善。
也希望各位朋友看后多评论，多留言，多给笔者提出改进意见，本人将结合大家意见不断完善，将大家的想法变成业内智慧的结晶，让更多的人能在IT实施工作中做到游刃有余
目 录
前言2 如何做业务调研？ 2.1 调研工作如何组织？
2.2 调研准备阶段容易犯哪些错误？2.3 调研准备阶段容易犯哪些错误？)2.4 调研准备阶段容易犯哪些错误？2.5 现场调研阶段容易犯哪些错误？2.6 现场调研阶段容易犯哪些错误？ 2.7 现场调研阶段容易犯哪些错误？2.8 现场调研阶段容易犯哪些错误？)2.9 现场调研阶段容易犯哪些错误？2.10 现场调研阶段容易犯哪些错误？2.11 调研工作方法推荐2.12 接口调研背景知识(上)2.13 接口调研背景知识(下)2.14 调研后续工作落实阶段3 如何写解决方案？
3.1 解决方案难写在哪里？(连载十五)3.2 坏的解决方案有哪些特征？(上)(连载十六)3.3 坏的解决方案有哪些特征？(中)(连载十七)3.4 坏的解决方案有哪些特征？(下)(连载十八)3.5 写好方案心得(上)(连载十九)3.6 写好方案心得(下)(连载二十)3.7 方案分类及用途(连载二十一)4 如何做产品演示？
4.1 什么是演示？(连载二十二)4.2 演示的目的
4.3 售前演示为什么效果不好？(上)(连载二十三)4.4 售前演示为什么效果不好？(下)(连载二十四)4.5 售前演示工作应如何组织？(上)(连载二十五)4.6 售前演示工作应如何组织？(下)(连载二十六)4.7 如何准备标准演示套路？(上)(连载二十七)4.8 如何准备标准演示套路？(下)(连载二十八)4.9 如何进行现场演示(一)(连载二十九)4.10 如何进行现场演示(二)(连载三十)4.11 如何进行现场演示(三)(连载三十一)4.12 如何进行现场演示(四)(连载三十二)4.13 如何进行现场演示(五)(连载三十三)4.14 如何组织演示后工作(连载三十四)4.15 演示方案准备经常考虑的问题(连载三十五)5 如何做用户考察？ 5.1 前言(连载三十六)5.2 典型用户有什么意义？
5.3 典型用户应如何管理(上)(连载三十七)5.4 典型用户应如何管理(下)(连载三十八)5.5 用户现场考察应如何组织？(上)(连载三十九)5.6 用户现场考察应如何组织？(中)(连载四十)5.7 用户现场考察应如何组织？(下)(连载四十一) 6 如何做公司介绍？ 6.1 前言(连载四十二) 6.2 哪些情况下需要公司介绍 6.3 正式陈述时常见错误？
6.4 口头和会面介绍时常见技巧(连载四十三) 6.5 在客户处进行公司介绍三个要点
6.6 如何对在公司考察客户做介绍(连载四十四) 6.7 做好总部公司介绍的三个决窍
6.8 公司总部接待考察客户要注意的细节
7.1 培训工作在项目实施中作用(上)(连载四十五) 7.2 培训工作在项目实施中作用(中)(连载四十六) 7.3 培训工作在项目实施中作用(下)(连载四十七) 7.4 培训工作应如何组织？(连载四十八) 7.5 培训注意事项(连载四十九) 7.6 总部培训
8 如何做现场推广? 8.1 现场推广工作可进行条件？(连载五十) 8.2 现场推广工作为什么进展慢？
8.2.2 要推广的业务流不完整(连载五十一) 8.2.4 没有激发用户的主动性(连载五十二) 8.2.6 边界总在变更(连载五十三) 8.3 现场推广工作如何才能做好？(连载五十四) 9 如何做项目验收? 9.1 验收工作应如何组织？(连载五十五) 9.1.3 主动沟通(连载五十六) 9.1.4 写好备忘录(连载五十七) 9.2 如何催款？
10 如何做项目团队管理 10.1 前言(连载五十八) 10.2 好的项目团队构建要求
10.3 好团队的两个特征(连载五十九) 10.4 如何看待项目经理在团队中作用 10.5 团队建设心得和误区(连载六十) 1 前言
在IT行业，特别是管理软件实施行业能够成为一个成功的项目经理是非常困难的一件事情，一个成功的IT经理，被要求熟悉计算机软硬件知识，精通企业业务背景，拥有良好的沟通技巧和说服能力，当然在项目团队中还必须具有威信和执行力，这样的人才简直是完人。
一般人即使努力也不可能达到这样的一个完美的项目经理的境界，如果相信自己努力就可以做到可能是受哪些成功书籍的毒害太深。
更多的项目经理是拥有岗位并非拥有岗位技能，但可笑的是，往往是一个人刚刚被发现具备这样的潜质就会没有多少机会实施项目，而是陷入另一种疲于奔命的状态。
因为一个具有丰富实战经验的人对企业最有价值的场合不是深入实施某个具体的项目，而是进入售前。
管理软件销售是最合适顾问式销售技术，但很难想象一个没有实际实施项目经验的顾问可以有效把握企业需求和打动对软件供应商本质上都保持狐疑的潜在客户，这些都只有通过经验丰富的项目经理才可以做到。
如果一家软件公司的问题还是生存的问题，这样优秀的实施顾问最合理的选择就是售前咨询顾问。很多用户往往在合作后感觉到售前和售后交流时存在巨大落差，就是因为售前你看到的是已经证明过自己的顾问，售后你看到的就是还需要证明自己的顾问。
笔者自己也是走过了这么一条路，所以现在想一想，做项目经理难，做管理软件的项目经理尤其难，五年下来，忙得不亦乐乎。常常笑言自己是职业“三陪”，陪客户交流，陪客户考察，陪客户吃饭。
不过和大量客户交流也的确从另一个角度丰富了本人的阅历，也对整个管理信息化事业的建设从另一个角度(售前)增加了新的认识，在本文本人将自己售前售后一些工作心得分为九种技能(业务调研，解决方案，产品演示，用户考察，公司介绍，用户培训，现场推广，项目验收，团队管理)，分别整理成文，希望能给在这个行业内拼搏的同道一些启发。
2 如何做业务调研？
2.1 调研工作如何组织？
很多人认为调研工作极难，水平最高的人才能做好一次调研，软件工程中也强调需求获取是最难的事情。有的人要么认为不过如此，甚至是一个普通技术支持都可以做的工作。
现在有很多企业上管理软件之前都希望软件公司派人来了解情况，提出针对性建议。这其实给很多软件公司销售经理出了个难题，自己亲自上企业不信任，而且也不专业，请公司派咨询顾问过来资源难以协调，响应不及时用户也不满意，而且贻误商机，随便来一个技术支持又不能保证调研质量，在后续工作中也难以让用户信服。
其实难和不难，在于是否用正确的方法做事，经常用正确的方法做事人，眼里是没有难事的。
虽然说调研工作质量和调研个人能力是直接相关的，有丰富经验的人在很短时间内就可以完成高质量的调研，取得被调研用户的认可，没经验的人花费大量时间在现场了解情况可能还是给用户一个不懂行的印象。
但最有经验的人也不可能了解所有的行业，他们对于一些陌生的行业一样可以将调研工作完成得很好，我发现有经验的调研人员和没有经验调研人员最大的区别是他们是否按照正确的过程组织调研工作，按照正确的方式做事自然会更容易取得成功，有无其它行业经验只是成功调研的一个积极因素而已。
在一个有调研经验的业务人员眼里，调研决不是现场调研这么简单，无论是售前还是售后调研工作本身都可以分为三个阶段。
第一个阶段叫调研准备阶段，这个阶段要完成调研计划的确认，调研背景资料的准备两方面的工作。这个阶段工作质量将对能否顺利开展调研工作起到关键保障作用。
第二个阶段就是现场调研阶段，根据调研计划完成各项调研工作，并取得用户认同。
第三个阶段就是调研后续工作落实阶段，调研结束后往往要准备产品演示，技术交流，解决方案等工作，所以调研结束后一定要趁热打铁，把后续工作落实到一定程度才能再做其它工作，此时调研工作才能算结束。
这是很多人忽视的一点，以为调研成功事情就结束了，其实调研工作和后续工作往往不是同一个人准备，高质量调研信息如果不能及时有效完整传递到后续工作者头脑中，调研工作实际上是更大的机会成本丧失。
从商务的角度来讲，售前调研还存在一个时机问题，调研本身应该是商务策划中的一个环节。
很多商务人员和用户接触以后，技术讲不清楚，业务谈不清楚，只好给一个模板化的方案给用户，结果这种方案又没有说服力，大家的方案高度雷同，用户无法鉴别，往往提出一个请求：是否请安排贵公司业务人员做一个调研，然后再提供一个针对性方案？
有经验的销售人员还应该明白，调研是一个适当实际要去做的工作，不应该被用户牵着走，应该是整个商务策划中的一部分，不过这不是本文阐述重点，本文将重点介绍业务调研需要的技能。 2.2 调研准备阶段容易犯哪些错误？
一般接到一个调研工作任务后，大家都会去编制一个调研工作现场工作计划，同时进行一些调研准备工作。
根据我的观察，在调研准备阶段大家常常存在这么几个错误。
2.2.1 第一个容易犯的错误：不清楚调研的的目的
很多人编制计划，写本次现场工作目的时往往是这样写的：“完成项目现场调研工作”。
其实完成现场调研工作不是计划本次活动的目的，而恰恰是完成本次调研目的的有效手段。
那么调研的目的到底是什么呢？
真正的调研目的有三条：
对用户：让用户认为调研者已经非常了解或者有足够能力了解企业现有业务流程。
对竞争对手：如果是售前调研，还要随时制造给竞争对手的门槛，了解竞争对手给我们设计的门槛。
对公司：调研获得信息足够让后续者进入下一阶段工作。
我们很多人认为调研时一定要搞清楚企业业务，可是一定要切记，能够评价你是否了解企业业务的人不是你公司的成员，而是用户。
如果用户都认为调研者非常或者有能力了解他们的业务，他们自然也比较相信这个调研者的后续的解决方案或产品演示。
如果用户都认为调研者非常或者有能力了解他们的业务，调研者说服或者高质量帮助公司的同事进行后续工作自然不在话下。
明白这个目的的人，在调研阶段就会设计大量的机会不断强化用户对调研者的认同感。如果最终用户认同了调研者，或者大量的用户认同了调研者，无论是对售前打单还是售后实施就开始取得了最广泛的支持，项目成功的机会就在不断的增加。
有的企业业务非常复杂，企业用户自己都可能搞不太清楚，不太可能在短期内了解全部业务细节，特别是售前调研阶段，用户不太可能有积极性花费大量时间配合进行调研工作，这个时候调研工作目的就是要能让用户充分信服调研者所在公司或团队是有能力了解企业业务。有了这个信任基础，后面很多工作也容易推进。
有的项目用户同时安排几家供应商在同一时间段，或者在很紧凑的一个时间段安排几家供应商都用两三天的时间做一个调研，此时所有供应商恐怕都很难立即对项目情况有一个完备的了解，这个时候与其说调研目的是搞完全清楚企业业务流程，不如说是让用户认为我们在这个领域最有经验，最有可能搞清楚企业业务流程，进而给竞争对手制造进入门槛。
所以在调研工作中要通过规范的业务程序让用户感觉到我们作为一家大公司的风范，通过业务交流让用户认可我们在这个领域的专业知识和技能，通过业务需求确认突出我们强项，给竞争对手制造压力，同时了解竞争对手给我们制造了哪些门槛，灵活化解，或者为后续技术交流工作提供可利用的信息。
我们调研工作质量越高，认同程度越高，对手压力就越大。一般对手在压力下出错的机会就越多，我们了解充分准备也容易充分，这样我们项目成功的概率就越大。
调研一旦结束，调研者还要清楚一个环节，调研后要做什么？是做解决方案还是做技术交流，还是做产品演示，还是做实施方案？
不管进行什么工作，特别是在后续工作是公司其它同事配合完成的情况下，调研者有责任有义务确认自己调研工作信息明确被需要获知这些信息的同事收到并理解，并能很好开展后续工作。
做到这一点，调研工作才能算结束，否则调研者个人认为其调研工作质量很高，后续者如果对调研情况不认同或者对调研业务报告不理解，后续工作质量还是没有保障，这个时候调研工作并没有发挥作用，所以调研者就是从尊重自己工作的角度而言，也要安排时间让后续人员认同和理解自己的业务调研内容。
实际上有效的团队在调研过程中会随时收集团队成员对调研记录的意见，不断动态调整调研过程，而不是在最后调研结束时一骨脑让团队成员吸收大量信息。同样有经验的人员在规划一个项目时也一定会考虑调研工作和后续工作的协同，提前要求各个阶段人员及时沟通和配合。
2.2.2 第二个容易犯的错误：计划不够细致
很多人调研计划落实具体活动的时候，往往只有这么简要的几句，某年某月某日，在某地某部门进行业务调研。
这样写计划要么是不清楚调研从哪里下手，只好先这样写着，到现场再走一步看一步，要么就是自以为有一些调研经验，知道如何处理，所以在写计划时为了糊弄内部分管领导，好歹也写了，质量上偷工减料。
实际上我们写一个计划写给谁看？计划是我们给用户分管领导确认的，用户领导对你的工作内容了解越清楚，他帮助你安排工作就越方便。
用户领导或者有时候是用户协调人也一定希望我们在现场的工作紧凑合理，不浪费彼此的时间。但用户并不清楚如何做这种调研，他们能做的就是按照我们意见尽量安排合适人员配合。
如果你的调研是某几天要来你们这里调研的话语，实际上用户领导可能会回答，拿你们先来，来了再说。结果现场大部分时间都在协调调研资源和等待上，大量时间都无价值的浪费掉。
所以一份好的计划应该是可操作，可执行的，也可以让用户看明白的。
我个人建议计划不妨细化到每天的上午下午分别调研哪个部门，需要怎样资历人员配合，需要配合多长时间，将了解哪些方面的业务问题，需要准备哪些相关资料。这样也便于用户领导配合安排。
而且一份详细的计划做为开始，正是恰到好处的体现了我们的专业背景和职业素养。还有什么比这更划算的呢？我们只需要做一份合理的模板，每次多写几个字，就可以换来一个好的印象。
还有一点必须要明确的是，写一份详细的计划并非一定要让计划时间变得很长。任何调研工作都不可能把所有情况搞清楚，调研并不是一次就可以结束的事情。
实际上在一个项目中要随时有调研的意识，一旦发现新的事实和历史调研不符合，我们马上可以重新完善我们的调研结论，进行相关调整。
所以知道这一点我们每次调研都有一个成本的概念，调研的目的对内只是获得可以进入下一阶段工作的足够质量信息即可。
有时候一两天的调研也可以达到这个目的，调研同样可以结束。
即使是一天的调研计划同样可以认真细致地准备。 2.3 调研准备阶段容易犯哪些错误？
2.3.1 第三个容易犯的错误：计划没有在内部沟通
很多人接到调研任务，将计划写好，立即就开始和用户沟通，工作精神很好，是不折不扣的行动派。
但是前面已经强调过，调研工作不是一个单独的业务行为，调研是承上启下的一个工作。所以我们的调研计划一定要征求客户经理，参与过调研其它人员意见，一些重点项目甚至是公司高管的意见，看看是否还值得推敲。
最关键的是，内部沟通计划的过程是和其它部门约定后续工作配合的过程，通过内部沟通在完善调研合理性基础上实际上确定如果调研工作结束，如何将我的工作移交给其它人，便于其安排后续工作。
调研者不要匆匆忙忙搞完一个调研，提交一份文档，就投入另外一个项目。然后客户经理过了一段时间又要求演示，然后演示准备者看着业务调研报告云里雾里的时候，又无法和调研者当面深入沟通一下业务，无法高质量开展工作。
所以做内部沟通的时候实际上也是调研者的一个自我保护，和别人约定阶段工作的输入输出文档和质量要求，那么做完这份工作，后续同事也就能够独立开展工作，而是是纠缠不清。
例如有的项目在调研阶段就要同步准备演示方案，那么调研者最好在调研阶段就清楚谁负责这个演示配置，并在调研期间约定和其有效沟通方式，便于在调研进行时可以考虑如何准备。
如果很明确要进行这类工作，但又没有安排演示准备人员。调研者作为一个职业人员，我们至少要尽到提醒客户经理去申请资源提前准备的责任。
帮助自己团队成员少犯低级错误也是一个成熟职业经理人的心态，不管你的工作岗位有多么重要或者不重要。
此外在内部沟通时，如果是售前项目，要考虑和客户经理沟通一个很重要的问题：调研的切入时机。
一般情况下不要轻易的做第一个调研者，做第一个调研者一定要安排能力强的人，在用户关系不错的情况下，经过调研做好工作，给后续对手制造压力。
因为用户如果发现后续者能力不强或者不够职业会加强对第一个调研者的认同感。
但是如果你派的人能力不足，那就给对手超越的机会此时再次安排调研，已经很难挽回第一印象分。
不做第一个调研者除了规避这方面的风险之外，还有一个比较大的好处：不做栽树人，要做栽果子的人。
很多用户往往并不清楚他们要购买的软件到底是什么东西，所以第一批调研者很多精力要花费在灌输概念的工作上，如果基本概念不清楚，用户往往不能提出有价值的需求，调研时往往没有边际。
第二个调研者再进行调研时用户就会清楚很多事情，回答问题质量就比较高，同时我们也可以有机会了解对手的牌，进行针对性准备，后发制人。
当然何时切入调研应该更多程度上是客户经理考虑的工作，我们调研者至少要知道客户经理对这个问题是如何考虑的。此外调研一般要客户经理到现场配合，所以调研计划行程安排也一定要得到客户经理确认，防止出现意外变化。
不过说实话在这个行业内，基本上客户经理是很幼稚的，调研工作往往是盲目启动，草草收尾。
2.3.2 第四个容易犯的错误：计划没有得到用户确认
我们有的人把调研计划做好，告诉用户形成，就准备按计划去现场了，这样的调研者不及格。
有的人会提前发邮件或传真给用户，然后电话确认收到，然后确认时间无问题，然后再去，这样的调研者60分。
有的人不但会确认计划时间，还会认真了解计划内容是否认同和有相关业务人员配合，得到肯定承诺后再去，这样的人80分。
有的人还会准备一些前期调研文卷和资料准备清单，让客户经理配合落实后再去调研，这样的人100分。
我们至少要做到80分！
计划发给用户后用户一般是不会认真看和落实的，这是中国人做事的习惯，特别是一些地位不高的联系人，可能连为这个事找领导这个协调的胆都没有。
所以打电话确认的时候一定要请用户确认是否可以按计划进行，得到肯定答复后再出发，这样第一计划执行保障性会高一些，第二也给别人留下一个认真的印象。
这个计划落实的工作也可以和客户经理沟通后，请其利用其在企业的人脉落实。
最近我有一个同事就犯了一个这样的错误，代理在合同签订后非常着急催促我们去现场落实调研工作，这位同事就立即制定计划，并发送给代理，同时电话确认收到计划，然后就立即按计划动身。
结果到了现场，代理说用户还没有准备好，你怎么就来了？我们的同事也很郁闷，计划上说如果有问题就打电话，没有问题就不用打电话，既然没有打电话反对当然是按计划执行。结果双方的开始很不愉快，这就是不了解中国人的办事特点造成的，中国人是预期性的事情一定要口头沟通确认，担责任的事情一定要书面沟通确认。
2.4 调研准备阶段容易犯哪些错误？
2.4.1 第五个容易犯的错误：没有认真进行准备
调研要认真准备，但说来容易做来难，很多人调研前的准备工作其实都是很随意的。
没有经过认真准备的调研，到了现场很可能对各种突发情况措手不及。
从应付各种用户刁专古怪的问题的角度而言，调研准备永无止境。
好的调研准备工作可以包括这么18个方面：
1、如果有的话，一定要认真阅读商务合同和技术协议。
2、阅读前期技术方案和各类备忘录。
此点非常重要，不仅仅要阅读，还要保证自己工作质量和规范和前期保持一致，一个行为高度一致性的公司是核心竞争力很强的公司。
此处有一个很重要的工作一定要向前期参加工作人员了解是否已经收集了一些资料，并想办法获得，已经搜集的资料和问题尽量避免重复询问，这对用户会造成巨大不满。如果万一前期资料不能获得，也要另外提前准备好说法避免这种情况出现。
3、和项目前期人员(咨询顾问、客户经理和平台主管)充分沟通。
听取他们的建议，使自己调研更有针对性。
4、熟悉公司已实施的相近项目的情况。
他们企业业务调研报告和解决方案将对我们现在工作很有帮助，甚至在调研过程中给我们很多思路上的启发。
5、熟悉相关软件产品的功能及发展方向。
很多人在工作中不注意和规划人员的沟通，其实在调研前确认自己了解产品的发展方向，现有和近期可实现的功能对调研时遇到一些很难回避的技术问题就可以做到心中有数，提前想好说法。当然最好的说法是这个功能我们已经实现了，在某某项目上也是这样要求的。
6、了解企业所处行业的行业特点、竞争态势、产品研发特点。
这些要从公司，特别是网上查询资料分析，建立一个基本的业务原型，这样在调研时可以让用户感觉到我们还是做了很多工作，对项目很认真。
7、准备同用户交流时的软件原型或交流PPT。
有的时候用户在调研过程中提出要我们做一个培训和软件演示的要求，一般情况下我们应该避免在售前调研阶段做这个工作，因为这些要经过精心调研仔细准备后再进行质量更高。
但在售后实施调研时我们可能要先主动做这个软件演示和理念培训工作，收敛用户的思路，引导项目边界，所以调研者也应提前对这些方面工作做一准备。即使是售前也很难完全避免这个情况，不但要准备，而且在语气上还要有所区分。
8、准备企业业务调研问卷。不一定要给用户，但一定可以让自己不遗漏该问的问题。
9、设计业务调研方案。业务调研方案可以将自己调研经验不断积累，形成体系化的经验，大家现在看到的文字就是我不断完善业务调研方案的结果。
10、设计业务调研计划。计划一定要用心，用心才能做好。
11、准备业务调研培训材料。
到现场调研时需要让用户知道我们的调研方法和思路，用户才好配合，也认可我们的专业化程度，这个应该结合公司流程和自己体会进行准备。
12、软件安装盘和加密狗。有备无患。
13、电脑笔记本。IT农民的必备劳作工具，如果没有就用笔记本解决问题，没有电脑前麦肯锡一直是手记录问题，现在他们还是提倡手记录，因为方便。
14、WINDOWS2000/SQL SERVER/ORACLE安装盘等常用工具软件安装盘。有时候很有用。
15、别的项目常用样例及标准配置，用户很难提供明确需求的时候，让他们看看我们在别的企业成功样例，有助打开思路，也体现我们给用户带去先进管理方式和成功经验的合作初衷。
16、公司各种流程管理文档。对于一些用户了解我们公司内部问题的时候，如果搞不清楚该什么讲的时候不要信口开河，翻翻资料再说。
17、可能涉及业务难点培训资料和问题集。
用户的问题千奇百怪，多准备一点没错，不断积累这些问题就是一个个人知识完善的过程。
18、公司小礼品。
调研完成后送给调研对象一个小礼品是很容易给对方留下好印象的机会。如果有政策，一定不要浪费。
实际上我们每个做过调研的人扪心自问，调研准备18条我们到底做了几条？
也许认真不认真就是我们一个工作到底有没有质量的根本原因。 2.5 现场调研阶段容易犯哪些错误？
调研计划确认，抵达现场就需要进行调研工作。在调研工作阶段我们常常容易犯以下错误。
2.5.1 常见错误一：立即进入调研状态
很多人非常努力，一到现场，就开始按计划进行调研工作。
其实调研计划到现场第一件事情不是启动调研，而是再次确认调研计划。
这样做的理由有三点：
第一虽然很多企业和你电话口头认同了计划，但只有调研者到现场了才会真的重视，所以我们必须要重新确认计划，保证我们的计划需要的调研配合资源已经落实；
第二确认调研计划往往不是和协调人确认，要主动通过这个机会见一见企业负责的高管，很多时候企业也会安排这个一次见面。和高管见面要做好三件非常重要的事情：
一、汇报我们的计划，请其再次确认，并请其协调资源安排人员配合。
记住给领导沟通最有效方式之一就是“多请示，多汇报”。根据我个人的经验，一般领导看过的东西不如口头汇报的东西印象深刻，汇报也是建立领导对我们认同的手段。
很多时候被调研人员不愿意配合我们进行调研，因为这样可能会影响他们正常工作或者有其它顾虑，所以当调研工作是领导的工作任务安排，他们配合积极性就高了。
很多时候领导也不能立即协调完所有的工作，特别是这个时候可以要求领导配置一个专门的联络人，由他出进行联络工作，可能的话，也要求其全程参与调研，这样的人会给调研带来极大方便。
二、汇报我们的调研工作方法，让高管觉得我们做事很有套路，同时请其提出意见，做相应客户化调整。
在汇报计划的同时要顺便告诉高管我们调研工作方法，先做什么，后做什么，每天需要如何开始，要花费多少时间调研，花费多少时间在整理，是否要开一次业务分析会，需要哪些人参加。
领导明白你思路了，也就知道我们这些天工作量都会很饱满，很有组织性，也就对调研工作有信心并积极支持。
此外领导可能提出一些要求，例如进行培训或者其它要求，我们可以根据实际情况确定是否要进行或者不进行。此时就有可能需要调整计划内容和时间。
三、借汇报机会领导了解他们上项目的初衷。
很多时候领导看待一个项目角度和高度和我们进行下层调研人员理解是不同的，这个时候和领导交流其对项目的想法，是有助于我们在调研工作进行时判断一些业务需求是否真的符合企业领导的构思，并可以寻求更好的方案。
从调研的角度，了解不同人员对同一个项目的需求也是调研工作的一个内容。领导层往往是管理性思维，业务层往往是技术性思维，两种思维达成一致才能设计一个好的方案。这些都需要通过调研获得。
第三和高管见面要约定如何汇报工作的机制。
调研如果有一段时期，不可能天天找领导汇报，也不能不汇报，那么这个时候就可以请示领导每几天安排一次当面汇报还是书面汇报。
多和领导见面，多用肯定语气沟通，就会让领导不断强化对我们积极的印象，逐步将感情的天平倾斜到对我们有利的方面。
不过有一点，首次和高管汇报工作原则一定要言简意赅，不要表现自己。
让领导建立对自己个人专业认同感就可以说达到目的了，对于一个领导认为有专业技巧的人，见面的机会他是一定会继续提供的，所以不要追求一次搞定，这都是极为有害的冒进思想。
低调切入，等调研过程中收集足够事实了再根据情况确定是否逐步抬高调门，表现自己的思路，是更稳妥和合理的策略。
和高管见面可能存在一个时间不确定因素。所以在调研准备阶段计划确认时尽量先保证这个时间，如果到现场时间不能保证，必须留机动调整的可能，一般情况下可以进行企业历史，企业现状，网络硬件，组织机构等方面的业务调研，也可以为领导见面提供沟通的素材。
此外高管并非一定是企业的最高领导，高管是依据企业规模和项目规模动态确定的，一般选择汇报高管对象的原则是对项目直接负责的人上级或以上级别的人。
企业大了，高管并非只有一位，有的汇报必要时该重复就重复，不要给别人不尊重的感觉。
2.5.2 常见错误二：匆忙地进入调研状态
计划一旦得到领导确认很多人就立即着手调研，这个时候容易犯的错误就是匆忙地进入调研状态。
进行具体调研业务前首先是和企业调研协调人确定今天一天的调研计划和资源可以到位，如果万一今天计划所在配合资源不在，给企业调研协调人几个替代性调整方案，其负责落实到位后才能放心的开展调研。这就避免出现上午调研完了发现下午没有人配合了的情况。
这个提前预约时间，即尊重被调研用户又让被调研用户有所准备，保证质量。
那么安排用户配合调研工作在可能情况下一定还要得到其直接主管领导的确认，让访谈者上司出面安排会面会保证调研者的积极性，他就不必担心调研影响正常工作而导致直接领导不满。
这些工作完成后还不以开始调研，而是针对所访谈的对象，再一次回顾自己要问的问题，理清发问的思路，不要想到什么说问什么。
想清楚后就可以开始调研了，但和被调研对象见面不要三句话不到就立即进入主题，必须有一点点铺陈才能展开调研。
这个铺陈包括三个方面，第一是自我介绍，有时候还包括公司介绍，调研者也是公司的活名片，第二是了解被调研者的背景，对其配合调研表示感谢，顺便奉承一下，例如说能得到您这样有经验人员配合是我们非常高兴的事情，让其有一个好心情开始配合调研工作，第三是对调研总体内容和时间有一个说明，说明我们想通过调研能为其业务设计好的信息化支持手段，让其配合时做到心中有数，乐于协助。
做完这些工作才不是匆忙展开调研工作。 2.6 现场调研阶段容易犯哪些错误？(二) 2.6.1 常见错误三：不断地问问题，唱独角戏
很多人在开始进行调研的时候准备了一份业务调研问卷，所以在调研的时候就按照调研问卷开始提问，这个方法对刚开始做调研的人是很有用的，可以帮助他在对业务不熟悉的时候不至于无话可问。
但这样调研的后果就是调研者在唱独角戏。调研者不停的提出问题，被调研者不断的再回答，好象成了一种审问和被审问的关系，这样的调研状态虽然可以收集大量信息，但从调研角度而言，不是最佳的选择。
真正有经验的调研者首先是先向用户了解整个业务过程，在具体业务过程中顺便了解我们想重点关心的问题。
被调研的用户如果没有经过精心准备是无法回答很多具体的问题的，他也不知道你为什么要问这些问题，这样的问题问多了，用户一定很厌烦，也会产生一些戒备心理。
但是所有用户一定很熟悉自己每天进行的业务，并知道业务中他感觉比较痛苦的一些问题。所以调研的方式应该是站在用户的角度了解业务，有了一个对业务的总体认识，再了解细节也就更深入和细致。
所以好的调研者要充分的让用户讲话，自己只是在提话题，让用户有兴趣有心情把自己知道的事情完整有序地讲明白。
举一个例子，我们做PDM调研的很多关心你用什么设计软件，产生哪些格式，每月设计几个项目，产生多少图纸，但如果是一个个问题这样问下去，对用户而言的确是一种折磨。还不如问他你每天设计任务是如何获得的，如何开始，需要哪些资料参考，做完了以后形成什么文档，交给谁？在这个过程中您觉得什么地方不太方便？在整个业务调研过程不断顺便问一句，这样的任务你每个月大概接多少，多的时候多少，少的时候多少，每次出图量多少，用什么软件设计为主之类的问题。
这样交流的好处是用户对熟悉的业务可以很自如的进行表达和沟通，而不至于让整个交流变成一个单向的信息收集，交流的气氛会越来越好，问题也会越谈越深入，而不仅仅停留在一些准备的表面问题上。
而且很多问题在一次业务沟通中就交流完成了，不需要反复去问，增加被调研者的工作强度，也节约了调研者的时间。
一个小块业务问题问完后立即要做的一个工作，也是很重要的工作：立即主动复述用户所讲的业务和过程，让用户确认你明白他所说的内容。
当用户发现他说讲的内容你可以理解并接受的时候，是很高兴的，第一觉得自己没有白讲，第二他就开始认为你也是比较熟悉业务或者有能力熟悉业务的人员了，第三如果发现复述有什么不对，可以立即纠正。
所以调研不是调研人员的独角戏，而是用户为主介绍，我们只要起到引出话题，复述内容的作用即可。一个滔滔不绝的用户应该是一个成功调研的特征。
调研结束后一定不要忘记的一句话就是感谢！
感谢之余还要请用户有时间审核我们的调研记录。
根据麦肯锡的建议，有些人在快结束会谈时可以再提出一个相对敏感的问题，这个时候问题人容易放松，会有心情回答一些一开始不愿意回答的问题，这个办法有时候可以试一试。
2.6.2 常见错误四：不注意收集异常的事实，挖掘背后的需求
很多人做调研，问问题很积极，沟通也很有技巧，但是就是缺少一些职业敏感，很多很有价值的信息用户已经说出来了，就是不注意。
一般多次调研的人很容易发现很多业务在不同的企业都是一样的，渐渐在调研中失去新鲜感，其实调研不是简单了解企业业务流程，而是要找到业务流程中问题。用户请我们来就是准确发现问题，然后再提供解决方案的。
可以如何发现问题呢？
问题往往是隐藏在意外事故之中的，如果听到一件和流程不符合的事情，或者和管理预期不符合的事情，这些事实就是异常的事实，值得我们高度重视，深挖穷究。
为什么会产生这个事实？原因是什么？这个原因到底是什么产生的？一层一层了解下去，就象拨笋一样，最后把事情分析得很透彻和明白了，问题的解决思路也就出来了。
比如有的企业更改非常多，很多调研人员就写上一句，更改管理业务很重要。或者更改管理是要重点解决的问题，可以为什么企业有这么多更改呢？这样一查下去，就会发现不同企业造成更改的原因是不同的，不同的原因自然要用不同的药去诊疗，才能收效。
如果我们不关注细节，不收集大量支持我们的事实，等我们真有机会见高管的时候，我们又怎么让企业领导相信我们这些相对年轻的人可以找到企业的病根，并有好的解决思路呢？
唯有事实，大量的事实会帮助我们说服企业的领导支持我们。
所以在调研过程中要随时分析现有流程存在的问题，而且一定要找到事例证明问题存在，并事后分析可能存在的改进点。
打动用户的力量就在在于你对其业务了解的程度！ 2.7 现场调研阶段容易犯哪些错误？(三) 2.7.1 常见错误五：每天调研工作时间太长
有的人有一个习惯，喜欢把调研工作都完成后才开始写调研报告，认为这样有整体感。有的人每天从早调研到晚，用个把小时整理下调研记录。这些都是不好的调研习惯。
其实每天调研的时间一般不要超过四个小时！
对每个个体一次访问的时间也不要超过两个小时！
四个小时的调研内容是需要用同等长度甚至更长时间整理才能成型成体系的，所以在每天的调研计划中，必须要和企业沟通好我们自己的工作方法，保障我们整理调研内容的时间。不要让用户以为我们每天没有调研的时间没有在工作，实际上为了整理四个小时的调研内容往往要用掉八个小时。
如果要想控制每次调研时间又不至于遗漏关键信息，比较好的方法有两个。
第一是将要调研的问题结构化，建立结构化的问题可以方便自己快速把调研信息转换成调研记录，也容易防止遗漏问题。
问题结构化就是针对一类业务将一组相关问题形成一个开放性和封闭性的问题引导区，这样在短时间内可以把一个业务快速搞清楚，被调研者也容易顺着业务思路解释。
第二就是尽量不要一个人调研，应该两个人调研，如果两个调研者中有一个是企业项目组成员就更好，因为大家可以一起在调研中互相补充可能会遗漏的问题。而且可以一个主问，一个主记，合理分工，提高单位时间内的调研生产率。
调研完成后要及时迅速把调研内容转化成文字，而且要转化为结构化文字，不是用户说什么我们写什么。这样做有很多好处：
第一避免遗忘，好记性不如烂笔头，调研过程中不停把信息记录在本子上，但可能还是有一些遗漏，必须用一些时间趁着大脑有印象，赶紧补记下来。
第二写记录的过程就很容易发现一些自己感觉清楚但实际上并不清楚的内容，这些内容马上可以形成第二天的问题进一步确认，把调研逐步推向深入。
第三每天写清晰完整的调研记录，可以立即反馈给用户确认修改，用户也会认可我们的职业精神和专业水准，而且每天都看到具体的工作内容记录，工作成果也容易得到确认。
第四可以反馈给公司相关同事，让他们立即提供反馈意见调整调研进程。
第五整理的过程就是对企业问题深入思考的过程，这是一个很有趣的脑力劳动。
有的人想在这些方面偷懒，不随时注意整理调研信息，最终调研报告质量就不会太高，缺少深入的分析，也就不能为后续工作提供有价值的信息。
2.7.2 常见错误六：聆听，而不是提供解决方案
有的人在用户提出一个疑难点的时候，很希望把自己的产品特色展示出来，花了大量时间讲自己的卖点和特色，给用户做了大量启蒙工作。
当然有些用户还会对一些特色功能念念不忘，并拿来要求其它供应商提供。
其实在调研过程不是做解决方案的过程，调研就是为解决方案奠定基础的，过早在调研过程中提供问题的答案有如下坏处。
没有经过精心准备的演示可以有几个亮点，但很难形成整体打动别人决定性力量，反而浪费了调研的时间，影响了为有价值解决方案制作的调研时间。
提供解决方案往往是临时思考没有经过全面分析，难免偏颇，为了表现能力而承诺一定可行的内容发现实际上并不是那么容易，导致后期实施骑虎难下。
做项目不是一个人在做，而是一个团队在做，如果没有沟通就向用户提供了自己的思路，可能会给整个团队的思路带来干扰，解决方案一定要在内部达成一致才能提供给用户。
一些的确非常成熟有特色的业务解决方案可能会提前泄露给竞争对手，对手可以针对性进行准备，导致杀手锏失灵。
所以调研过程中不要过多花费精力介绍我们的产品，而是做一个好的发问者和聆听者，用耳朵去听，用心去想，用大脑去分析用户的信息，去发现有价值的内容。
2.8 现场调研阶段容易犯哪些错误？(四) 2.8.1 常见错误七：没有开业务分析会
很多人做完调研，就按计划打道回府，准备后续工作，其实有经验的调研人员还会多做一个工作，就是开一个针对企业领导、项目负责人和主要业务层面的调研工作汇报会。
我们说调研目的是让用户让用户认为调研者已经非常了解或者有足够能力了解企业现有业务流程。
单个用户是否建立这种认识我们是通过复述技巧实现的。但对于企业领导又如何知道我们了解企业业务呢？
有人说这些将在解决方案中完整体现，不过说实话，有几个人相信我们这些管理供应商写的多达百页的文档企业里会有三个以上的人看一遍？
都是在浪费纸张而已！
所以在调研完成之前，在调研计划中调研者应主动安排或者创造这么一次汇报的机会，专门陈述我们对企业业务和要解决关键问题的认识，这个认识陈述好了，企业自然对供应商刮目相看，就算有一些偏差，也可以立即得到纠偏的机会。
这个汇报会时间不一定要很长，但可以让企业领导真切感到我们调研工作的成效，我们对事实把握可靠程度，我们对企业业务了解深入程度，我们对问题分析细致程度，我们在该领域的专业程度即可。
有了这个阶段性总结，调研工作就可以说顺利完成了，可以进入下一阶段准备工作了。
不过在业务分析会上一定要注意一点，不能用过高的姿态切入。
有的人经过调研确实发现了企业一些问题，也想到一些很好的解决思路。于是其在业务分析会上企图指点天下，痛陈不足，确有严加改进必要的时候，就有可能犯一个大错误的时候。
有了表现欲，就容易昏头。
业务分析会一个铁的原则就是不要轻易说自己用户的不足，即使要说，也应用一种委婉的方式表达；指出可进步的地方，而不是指出落后的地方。指出不受控的地方，而不是失控的地方，指出实现不方便的地方，而不是指出无业务管理覆盖的地方。
这些都是做业务分析会要替自己客户考虑到地方，不要随意批评别人不足，也不要以为企业没有人知道这些毛病，更不要以为他们不知道这些毛病该如何解决，有时候无非是外来的和尚无牵挂，好念经而已。 2.9 现场调研阶段容易犯哪些错误？(五)
2.9.1 常见错误八：只重视正式沟通，不重视非正式沟通
调研工作特别是在正式调研活动中有些问题并不方便了解，所以调研工作还包括一些非正式场合，这些场合适合调研者问一些相对敏感或者自己有看法但没有把握的问题。
所以调研不仅仅在工作计划中所列走访，座谈，会议等形式中，也在和用户一起聚餐等非正式沟通活动中。
只要调研计划没有结束，所有的时间都是为调研而准备的，走路，闲谈，吃饭都是可以进行调研的机会，不一定要正式场合才能开始调研。
这种非正式沟通信息一样很重要，而且往往是真实运行企业的信息，和正式调研得到的信息正好可以互相印证。
在非正式沟通中调研者还可以和企业一些人建立友好的关系，为今后工作也奠定了良好的基础。
所以好的调研者不仅仅是一个专业人员，在非正式场合也是一个可以让别人说话的人，这样的调研行为才是完整的。
2.9.2 常见错误九：关键业务只询问了个别人意见
一些业务在整个调研工作中是占据很重要分量，而且涉及多个业务部门，这个时候调研就要记住“兼听则明，偏听则暗”，一定要把业务涉及不同部门意见都听到，也要把不同人对同一业务描述进行对比调研，从中能发现很多错误。
此时不可因为觉得调研内容很饱满或者时间紧张而只做单点调研，关键业务一定要从其它人那里不断得到印证。
不过再问第二个人的时候，就可以用主动复述业务的方式，请其重点指出不对的地方，加快调研进度。
2.9.3 常见错误十：调研时有选择问问题
有的调研者在调研阶段就非常小心，特别是在其对自己软件不足的地方有足够了解的时候，总想在调研阶段引导用户，接受自己的系统，绕过这些自己产品不足的地方，这也是一种错误的做法。
首先如果调研发现用户迫切需要很有价值的问题是公司目前不能解决的问题，并不等于不调研就可以回避，无论将来在技术答辩还是售后实施，这个问题总是要冒出来，与其回避，不如主动搞清楚，汇报给公司，看看到底有什么办法可以解决。
真正的问题都是回避不了，绕不过去的。
我个人意见，越是有公司明显不能解决的问题，越要调研清楚，搞清楚来龙去脉，为公司今后产品发展提供完整的需求建议，作为一家负责任的软件公司，首先要承认自己的软件不可能解决所有的问题，但一定要在发展过程中逐步解决更多的问题，调研时都回避了，不就失去了公司产品发展的机会了吗？
其次如果有选择性问问题，就会遗漏一些关键性业务，这样对调研整体质量有影响，在后续工作中容易被动。
至于不想将用户一些天马行空问题，或者的确不想引发他们高度兴趣的问题回避的方法，不是不通过调研，而是认真记录，但不提供在正式文档的方式规避。
很多人很多需求都是一时灵感，没有经过认真思考，所以口舌之快，过了也就过了，不形成文字记录，他自己也不记得自己说过什么了。如果是真的关键问题，在后续复述，确认调研记录还有业务分析会上还会提出来的，这个时候再确定写入正式文件也不迟。
对于这些暂时不能满足的需求和超出范围的需求，可以另外整理一份内部文档给公司分析。
2.10 现场调研阶段容易犯哪些错误？(六) 2.10.1 常见错误十一：一次调研就企图锁定需求
很多项目启动后轰轰烈烈进行了一次深入调研，然后开始配置开发实施，忙得不亦乐乎。好象把企业问题搞清楚了，就应该是实现和解决的阶段。
实际上很少有人能够在短短几天内把企业的问题搞清楚，即使你努力进行了半个月甚至一个月的调研，在实施过程中你还是会发现对很多问题认识我们依然不够深入，不够完整。
这个时候我们应该意识到，我们依然还需要进行调研，切不可因为是大规模调研完成了，对此时的调研就随意了，不留记录，不进行确认了。
事实上这些调研信息要随时记录确认并最终完善到项目解决方案中，可以这样说，信息化项目中始终要有随时开始调研的意识，如果我们承认信息化需求是无止境的话，那么调研也是无止境的。
为什么不能通过一次调研锁定需求呢？
正确的需求是系统成功的关键。预先锁定需求的假设前提是用户不经过系统上实践的过程，用户就能预先精确的提出所有的系统需求。
某些简单软件或者具有极高技术水平的用户可能可以，但是一般情况是用户只对其目标和需求最初只有模糊笼统的认识，许多细节都不清楚。要求一个只有初步设想的用户或个别用户负责人准确无误地说出全部需求，显然是不切实际的。
用户为了证实和细化他们的设想，往往需要在某个系统上持续不断学习和实践的过程。特别是在大型管理系统软件上。
即使经过深入细致的预先锁定需求的工作，当人们实地观察和使用了目标系统以后，也常常会改变原来的某些想法，对系统提出一些新的要求，以使系统更加符合他们要求，事先锁定需求的方式其实也会经过多次反复，甚至完全失败。
大型软件的开发需要系统分析员、软件工程师、程序员、实施经理、用户领导、用户负责人、具体用户等众多各类不同层次不同技术水平人员的一致协调努力，因此良好的通信和相互理解对于保证工程成功至关重要，传统的需求锁定方法假设使用适当的文档可以做到项目参加者之间清晰、准确、有效的沟通。但是各种文档本质上是被动、静止的通信工具，通过它们来理解一个动态系统是困难的。
用户变更需求是正常的，用户没有实际操作过软件之前无论你怎样描述都会有对软件功能理解不一致的地方，可能是技术协议上书面文字表达一致但对实际软件操作理解不一致，可能根本就是不用不知道哪里不适合自己的需求。
打个比方，就象买衣服，无论别人怎样推销，客人一般都会试一试觉得合身再买，我们一般比较大的项目都没有让用户体验过而且在推销时说了很多动听的话，自然期待高，失望也高，而且用户为适应ISO认证或PDM/ERP系统必然伴随组织机构和业务流程重组，这里面有很多反复的过程，对应的文档，设计流程，对软件操作提出变更是正常的。
我们的问题不再于要用户不变更需求，而在于找到一种方法让用户认识到我们的软件能发挥作用，当有新的需求时通过使用我们软件建立的信任关系重新形成新的业务，这也是调研时要保持一种理念。
2.10.2 常见错误十二：调研工作表现不职业
有的调研人员工作很努力，但在现场很难得到用户的认可，就是因为经常表现出一些职业不成熟的缘故，甚至有的表现是不道德的。
常见不成熟职业表现有：
1、不征求用户同意就翻看其资料(如果有的竞争对手敏感资料想获得，也一定不要给别人看到)；
2、调研过程中电话短消息不断；
3、在用户现场上网工作时顺便聊天看和工作无关的内容；
4、没有征求用户同意使用用户电话；
5、用户同意使用电话讲起来没完没了；
6、对用户现有各方面状态流露轻视的态度，例如认为用户条件不成熟，管理不到位，表现出眼界高人一等的想法。 2.11 调研工作方法推荐 2.11.1 每日调研流程
1、提出调研内容，请企业项目组成员配合预约人员时间安排访谈；
2、访谈
3、当场复述内容，确认理解对方表达的问题
4、立即将整理访谈结果形成文档记录，确认需要继续了解的内容和未清楚的内容
5、如果需要，安排时间请被访谈对象确认访谈文档记录，特别是一些关键名词定义部分
6、和企业项目组成员配合约定下一时间段访谈安排。
2.11.2 访谈成功的九个要点
让访谈者上司安排会面
调研前应向调研者介绍调研内容和时间大概安排，让其心中有数
聆听，不要发表指导意见，要靠和用户交流发现问题核心所在
随时收集和记录事实，寻找异常现象，发掘管理改进需求，认真记录并探讨原因
尽量两个人一起采访，最好一个是企业项目组的成员
复述、复述再复述
一次不要问得太多
在结束会谈后又提出一个问题
访谈结束后一定要表示感谢
2.11.3 良好的结构化调研顺序
先了解企业基本情况和项目组成员情况，由此建立对企业初步认识，对项目有个初步判断；
再了解企业组织结构和岗位设计，由此确定访谈对象；
再逐个按照业务口了解业务流，业务流要关心业务可以划分为哪些阶段，每个阶段应该是相互独立，彼此穷尽的。
每个业务阶段要问清楚业务目的，输入数据和输出数据，过程步骤，每个步骤的负责人，什么时候开始，什么时候结束。
输入数据其什么作用，有哪些信息传递到输出数据中。输出数据又起什么作用，是指导下游还是反馈上游。
业务流程调研质量评判标准就是能否清晰简明画出企业业务流程图和数据流程图。
2.11.4 售前和售后调研的不同
售前调研一般是为产品演示，技术交流做准备，同时调研过程要注意突出自己强项，给竞争对手制造门槛。
售后调研一般是为解决方案，项目实施做准备，同时调研过程中要注意寻求项目价值点，利用价值点置换项目边界，尽量把项目边界最小化，项目才容易成功和受控。
售前调研一般由商务主动和用户协商时机，根据实际情况确定先调研还是后调研。售后调研必须尽快启动，而且应该在项目启动大会后展开调研。
售后调研前一般要和企业高管亲密接触，取得支持。在启动大会上对调研方法和需要取得支持告诉企业配合人员后进行。
售前调研一般要协助拿项目，所以不要轻易发表对问题倾向性看法，要了解事实，用比较文饰的语言表达对问题的认识，通过对事物认识深度获取支持。售后调研可以相对直接提出问题，摆事实，陈厉害，争取最大范围重视，进而获得支持。
2.11.5 如何写调研日志
调研日志有三个要求：工作过程清晰化，调研内容结构化，不明内容有后续计划。
首先调研日志上要看出本日你调研了哪些部门，走访了哪些人，用了多少时间，获取了哪些业务的信息，这就叫工作过程清晰化。
然后调研内容不能是流水帐记录，必须将被调研者的话组织成一个个合理的单元，这些单元独立可以反映某个业务层面的情况，然后整体上构成一个业务调研报告的部分。
不同的信息结构化方法可能不太一样，有的适合用表格，有的适合用文字段落，有的适合绘制图形(例如框图，鱼骨图等等)。
调研日志最后要说明今天调研中还有哪些问题，需要进一步明确，并有认真记录。
2.11.6 如何写调研备忘录
调研备忘录一般情况下并不是把自己调研日志的内容汇总重新罗列，因为调研日志和业务调研报告就是做这个工作的。
调研备忘录和一般的备忘录一样，主要是说明本次现场工作进行了哪些工作内容，达到了怎样的目的，和企业约定的下一步工作安排是什么，并得到企业负责人签字认可。
备忘录主要让用户看到我们做事的规范性，而且在今后合作中将不断用同一格式备忘录强化我们在规范上的一致性，同时备忘录要让用户感觉到我们本次现场调研工作时间紧凑，内容丰富，层次清晰，让用户对我们形成良好的印象。 2.12 接口调研背景知识(上)
现在管理软件项目中接口需求很多，很多项目接口实现得并不理想，原因就在于接口协议质量不高，而接口协议是和接口调研紧密相关的。一般接口调研和其它调研方法是一样的，但要做好接口调研就必须具备一定的专业知识，这可能是能否做好接口调研的关键。
接口协议除一般性协议要素外，应该包括如下内容：
2.12.1 接口技术实现方式
接口方式最高级一种是主动式。
即通过直接对其它软件的数据库进行操作。这种方式因为涉及到对用户数据读写操作，对于对方软件而言，安全性是最大的问题，验证的复杂程度也最高。主动式基本有两种方式：
1)DATA方式，通过数据库语言对数据库进行直接读写。这种情况要求对对方数据有详细认识。需要对方的人员可以提供数据库的详细资料。为了保障数据的安全，要界定对读写要求。一般和用户自行开发的系统会比较多出现此类要求，商品化ERP很少提出这种方式。
2)利用其它软件提供的工具。除了直接对数据进行读写外，有些软件也提供了一些工具(可能是控件，函数，脚本等)。可以通过这些工具对数据库进行操作。例如现在神州数码易飞ERP就全部采用控件方式接口。
这种情况下要提供这些工具的详细使用说明。
接口方式相对主动式的就是被动式开放。
同主动式对应，即开放软件商自己的数据库或开发接口给其它供应商读取数据。这种方式涉及到软件商提供的数据或开发程序。对方要我们的哪些数据，将成为了解需求的重点。按提供方式的不同可以分为以下四种。
1)DATA方式。即开方我们的文件或数据库格式给对方。由对方软件直接读取数据。这样的情况一般在企业有开发能力，而且只需要信息提取(不是写入)时才使用。这种情况很少。
2)脚本方式。早期的脚本语言，多是一种专用高级编程语言。实现了基本的程序流程语句，简单的数据结构，在此基础上，提供访问软件内部数据的语句。通过这类专用语言，用户可以对程序进行界面配置，实现简单的功能扩展，给用户提供了一定的灵活性。而只需用户懂一点程序设计知识即可。这类语言的缺点是没有通用性，功能有限，由于解释执行，速度受到很大限制，并且应用软件开发商实现专用编程语言及调试环境有较大难度。对于应用程序，需实现三个要求，就可拥有脚本语言编程接口：
A)应用程序的对象模型
B)适合应用程序对象模型的对象
C)脚本语言编程引擎
前面两个方面，需要应用程序用组件对象模型的方式构造。采用组件方式，是软件开发的发展方向，提供对象模型是一件很自然的事情。第三个方面，有通用脚本语言编程引擎供选择，微软的ActiveX脚本编程引擎可以免费使用，VBA脚本引擎需要购买。ActiveX脚本引擎实现了基本功能，没有调试环境。VBA是一种通用编程语言，其核心就是应用广泛的VB，拥有大量函数支持，窗口编辑能力，强大的调试环境。很明显，微软希望VBA成为应用软件二次开发的通用语言。例如CAPP和国外PDM的接口就属于这种开放方式。
3)链接库方式。基于结构化的软件，可以提供软件内部使用的动态连接库，供用户使用。动态连接库是速度最快的接口，应该说是一种很好的选择，CAPP目前的二次开发接口就属于动态连接库方式。
但是动态连接库在接口升级时会遇到麻烦，用户程序难以和正在运行的应用程序进行数据交换。用户也难以使自己的模块(用户实现的动态连接库)嵌入应用程序。因为动态连接库的通常首先实现的(至少要定义输出函数接口)，而后才能使用动态库。但应用软件开发时，用户实现的动态库根本不存在，AutoCAD的ObjectARX用一种特殊的机制，才使AutoCAD可以使用用户开发的动态库。目前国内很多AutoCAD二次开发软件，就是使用ObjectARX开发的，可以完全的嵌入AutoCAD。
4)COM组件方式。COM对象接口：基于组件对象模型的软件，可以提供软件的COM对象接口。组件应用程序由多个组件打包而成，组件之间的联系是一种松散耦合，使其中某个组件的改变不影响其他组件，应用程序修改，改进变得方便。这就如同一台复杂的机械设备的各种零部件用螺栓连接起来，零部件可以轻易更换。而传统应用程序就像所有零部件都通过焊接连接的，如果要改进，只能重新做一个新的。组件程序由于由许多具有位置透明性(无需知道组件的位置)的组件构成，可以很容易实现分布式应用。组件架构强调实现对象模型，开发接口是基于对象的，符合用户的思维方式，比动态库提供的API，更易于理解，使用。组件是完全与语言无关的,任何过程性语言够可以用来开发组件，根据不同的需求，可以轻易的用不同语言开发应用程序的不同部分，用户可以选择任何过程性语言做二次开发。通过COM的底层机制，可以访问运行中的应用程序对象，实现与运行中程序交换数据。用户组件也可以易于嵌入应用程序中。COM的主要问题是，运行速度比动态库慢，特别是自动化接口；对系统稳定性要求高于动态库，要求系统的COM平台能正常工作。
最常用也是最安全，成本最低的接口方式是中间文件接口。
双方的数据交流通过中间文件进行。这种方式由于比较灵活，接口双方都比较明确工作。而且重要是的，接口双方的软件升级，对于接口本身(对方软件本身)可以说没有影响。是目前采用较多的接口方式。
如果是中间文件的还需要确定是全量式接口还是增量式接口。
接口本身是为了双方数据可以保持交流和数据一致性进行的。一方提供数据，另一方根据对方的数据来更新自己的系统的数据。所以对于哪些信息是新加，哪些是删，哪些是更新要进行判断。从数据提供方而言可以提供以下几种：
全量：按软件数据内的数据提供全部的数据，不进行区分哪些是增，哪些是删。这种方式需要用户对比自己内部的数据进行区分哪些是增，哪些是删。
增量：由数据提供方进行对比后，区分哪些数据是要更改的，哪些是要删除的。对方软件根据数据提供方提供的文件直接更新数据库。这种方式的重点是要掌握同什么数据对比，得出增减记录。另外，对不不同的记录(增/减记录)是提供不同的文件，还是在同一文件内对于不同的记录做上标记也是要定义的。此时可能就要在接口字段上定义更改标识，更改单号，版本号等信息。 2.13 接口调研背景知识(下) 2.13.1 接口内容
接口方式一旦确定，就需要确定接口的内容。
接口内容首先要确定接口入口，从哪里开始汇总接口数据，接口数据每次包含多少对象，这些对象是如何联系在一起的。例如接口数据每次都从一个完整的产品上开始汇总，或者从一个完整的工程任务上开始汇总，或者从任意零部件上都可以发起汇总。
第二接口内容要确定接口时机，要明确哪些字段由数据提供方(其它系统)写，那些读，在什么时候进行。也就是约定当数据达到怎样的规定后才可以启动接口输出，此时也可以约定接口输出负责人员。例如当产品结构发布，相关工艺数据也发布后才能启动接口，如果有明确接口时机要求，接口程序应适当做校验性判断，防止提供不正确的数据给下游系统。
第三接口内容要确定接口格式。
接口格式包括明确数据交换提交的方式：是文件级还是数据库级，然后明确交换文件的名字，存盘路径。
明确文件的格式，包括文件或数据表包含的字段名，字段次序，字段类型，字段长度，分隔符(如是文本文件)，是否必填，默认值，下游系统对应含义，实际数据样例，接口对应数据来源，该字段在实际操作中填写规则。
第三接口内容要确定接口样例。
接口技术协议附件必须包括用户方提供的样例数据，样例数据必须具备典型特性，能够覆盖企业各种可能的实际数据情况，保证验证样例数据对接口测试的完整性；
如果一个样例不能覆盖可以提供足够样例数据，用户方可提供多个样例，直到可覆盖各种可能情况为止。
用户方要保证样例数据的规范性。此时可能还需要针对接口样例提供数据规范性录入操作说明。
依据所提供样例最终得到的接口中间文件将以完整实例作为验证标准依据。如果有多个样例，则需提供多个完整的接口中间文件实例。准备接口样例将大大加快验证时间和接口程序调整反复时间，也有利于企业，供应商快速就接口协议达成一致性理解，是看起来慢，实际上最快的有效接口方式。
2.13.2 接口数据一致性握手方式
接口数据的一致性通握手方式来保障。一致性分为静态一致性，动态一致性，双向一致性。
静态一致性：如物料编码信息，原始工艺设计信息。
动态一致性：如设计更改信息，在一个系统内的数据更新后，要求另一个系统内的数据也要进行相应的处理。握手方式即明确如何让对方系统得到要进行更改的信息(也可能是依靠人员来进行手工操作)，这样对方系统对接口文件进行处理。
双向一致性：复杂的系统甚至要求，对方系统处理的数据结果要进行反馈。从而更新本身系统的数据。这里面也要对反馈进行定义。 2.14 调研后续工作落实阶段 2.14.1 如何写业务调研报告
调研结束后第一个必须尽快整理出业务调研报告，业务调研报告主体内容可以在业务分析会上得到用户确认。
写业务调研报告应该结合软件供应商特点形成一个比较统一的汇报目录模板，有了模板整理起来就快，不同软件关心业务内容不同，模板也应该不一样。
一般而言业务调研报告目录可以分为三个大的部分，第一部分是业务基本情况介绍，第二部分是企业业务流程图和数据流图，第三部分是项目关键价值点。
凡是不设计业务流和数据流，但必须要描述的内容，例如企业的一些基础数据情况，我们把其作为企业的基本情况介绍，例如企业概况，企业设计数据统计情况，企业工艺数据统计情况，企业标准化编码规定等等，做基本情况介绍时要把握两个原则：
第一是结构化，不要散乱，将相关性强的一组基本情况设计成表格填写，这样既方便填写，又不容易遗漏。
第二是按照调研先后顺序组织，和业务流顺序尽量一致。这样不但层次清晰，而且可以直接将每天调研日志内容复制修改就可以得到最终结果，大大提高工作效率。
业务流程图和数据流图有大量标准工具和方法指导，建议这里大家去找相关专门知识学习，本文不在这里展开。
第三部分项目关键价值点是非常重要的，项目价值点组织也必须符合结构化层次，不要将很大的价值和很小的价值并列排放，应该将最大的价值，可以相互独立做为一层，然后将小价值分别归类到不同大价值下，形成一个价值支撑体系，这个支撑体系也是解决方案的实现思路。
2.14.2 业务调研报告完成后续工作
业务调研报告完成后必须赶紧去找后续工作同伴，按照约定的工作计划把调研报告交给他们，如果有时间，还可以安排一个内部业务分析会议，做一个全面的介绍。
帮助团队成员可以准确理解调研报告，启动后续工作才是一个调研的工作结束。
如果你能按照以上方法进行调研，相信你的调研质量一定很棒，这样的话，不管后续工作是什么，我相信你都会得心应手的去完成，或者帮助你的团队成员去完成。
这也就是调研最大乐趣所在。
3 如何写解决方案？
3.1 解决方案难写在哪里？ 3 如何写解决方案？
3.1 解决方案难写在哪里？
很多人对写方案非常没有信心，一涉及到方案的事情，就束手无策，到处求人。
作为一个公认的方案打手，意思是写方案就象打字员一样，我觉得我在这方面确实是有绝活。
我基本上都是在方案提交前一两天接到写方案的任务，而我自己的事情一般又比别人多一点，也不能不做，只好心里大骂一句，骂完后就打电话搞清楚别人的要求，边问就边构思整个方案的推导思路和结构提纲。
因为你不敢让你的同事知道你只能用很少的一点时间写方案(基本上我真正动笔写方案的时间都在2~4个小时以内)，让他们担心方案的质量和进度保证，进而对自己的后续工作质量没有信心。所以我其实也特别紧张，注意力也特别集中，大脑也高速反应，基本上几分钟电话或面谈完思路基本就有了，然后该干嘛干嘛，找一些零散的小时间把思路不断推导一下，然后到了一个比较安静和完整的时间段前才开始写，这个时候基本上要写的话都想清楚了，只需要不断敲字，敲字的时候也是注意力也特别集中，大脑也高速反应，越写思路越开，很快也就完工了。
写方案不难，知道怎么写才难。关于写方案我只总结一点，结构化地去组织你的思想。
有结构就有思路，有思路就有方案。
另外真正写方案的人，对自己写过的方案是永远不会满意的，只有这样，每次都会进步一点点，解决方案水平质量就会随公司能力不断增长。
当然我曾经问过很多人，你到底为什么写不出好的方案呢？
基本上原因可以归为四类：
3.1.1 第一种是没有体系
一旦用户要求提供关于PDM的方案，很多人大脑是一片空白，完全不知道从哪里下手。很多人说起自己的产品来，好象知道不少卖点，不过真要写出来，又觉得无从下笔。
这种情况一般是写方案者不熟悉自己产品体系造成的，知道一两个甚至更多的产品卖点不难，但难就难在成体系，知识就是成体系的点构成的，而不是一句一句离散的说法构成的。
因为我们这个行业从业人员说句不客气的话，大部分对所销售实施的管理系统并没有很深入的研究，都是半路出家，从头开始，在学习过程中熟悉，在熟悉过程中领悟。所以一下子去驾驭一个整体方案是很痛苦的。只有当一个人对一个产品思路有体系以后，才能够写出完整的方案，否则就是一个单元也要费尽脑汁。
所以一个人要想写好一个方案，首先要把自己产品的来龙去脉，功能模块，适应领域，典型客户实施情况有一个全面的了解，这样才能建立一个完整的知识体系，然后逐步补充竞争对手知识和一些技术性知识，不断深化自己的知识体系。 3.1.2 第二种是没有思路
有很多用户看多了模板化的方案以后，想看一些针对他们自己的业务的个性化内容，这个时候有的人按照标准方案模板修改还勉强能对付，但对于个性化内容针对性方案就速手无策了。
这种情况从根本上讲还是写方案者不熟悉企业业务造成的，写方案，特别是针对性方案不仅仅要求了解企业的需求，而且要知道这些需求是在何种业务需求下产生的，用户提出这样的要求到底想解决什么问题，把这个问题找出来，一般针对性解决思路就有了，有了思路，自然可以很好的写方案。
所以一个人要写好方案，还需要了解下游客户的业务，了解业务最有效的方法就是亲自做几次详尽的业务调研，有了业务调研做基础，在调研过程中把握用户关注重难点问题，自然可以比较好的确定方案的个性化内容思路。
解决方案就是把客户的利益和产品特性之间建立一个逻辑性的桥梁。
3.1.3 第三种是没有素材
一般不经常写方案的人，在写一个方案的时候，即使有想法，有思路，但往往也会很累，就是因为缺少足够的素材。很多项目现在都是投标，不同用户可能有不同投标的要求，这样很难用一个方案去适应所有的用户，因此在每个方案中都有一些需要准备的内容。
这些内容基本上是通用的，但如果没有足够积累每次编制方案就需要花费大量时间去准备，造成方案完成周期过长。
所以写好方案必须具备这三个条件，第一方案编制者对企业业务要很熟悉，或者有相关业务调研经验，第二方案编制者对产品非常熟悉，至少对自己产品功能模块作用很清楚，第三方案编制者手上有大量可公用的素材库。
3.1.4 第四种是没有层次
很多人刚和用户接触没有多久，为了表现自己对客户的重视，马上表示要提供方案，当然有的客户刚刚开始选型，也不知道到底要什么搞，也要供应商马上提供一个方案。
结果拍胸脯容易，写方案难，自己写不出来只好求公司，公司没有安排专人了解情况，只好按模板制作一个，用户一看几个供应商内容都差不多，觉得不好，又总结出一些个性化要求，于是大家有开始折腾第二轮方案。
其实方案编制在不同阶段有不同策略，不要轻易提供方案。刚开始接触是可以提供项目合作建议书，类似可行性报告，项目需要考察软件技术，可以提供标准的产品技术白皮书，到了经过售前调研，有所准备，在演示前后阶段和其它竞争对手刺刀见红的时候，才在知己知彼的基础上提供解决方案或者投标书。
过早提供方案只能匆匆了事，时间紧急，质量自然不高，自然也就觉得方案难写。想急就又能解决问题的事情，本来就是一般人做不来的。
方案想要写得好，一定要用心，用心就一定要耗时间，指望用几个小时写出一个高质量的方案是不可能的。如果你做了精心调研，你写不出一个好方案唯一缺的是技巧。写方案是一种技巧性工作，明白了这一点，大家都可以经过练习写出好的方案。
3.2 坏的解决方案有哪些特征？(上)
3.2.1 第一个容易犯的错误：只有论点，没有论证
不好的解决方案粗看起来非常厚重，其实都是功能罗列，象产品手册摘要版，不象方案书。
不好的方案是一大堆内容，淹没在一堆纸里面，也不知道想说什么，给你一个厚度，证明我们的工作质量很高。我们国内许多的企业客户特别是大型企业都很在乎这点，认为可以从方案厚薄中看出对项目重视程度。
如果你做了精心调研，你写不出一个好方案唯一缺的是技巧。写方案是一种技巧性工作，有个金字塔式的写做原理，也就是说文章一定是有结构的。
所以真正好的方案，不一定厚，但能看出你用心，你认真。
现在的解决方案一个不好的倾向是“长、厚、全”，看起来面面俱到，其实对决策者没有帮助。
所有的方案无差异性，每家供应商都说自己能解决这些问题，而且都有成功案例。
结果所有的方案都无法给决策者简明的判断依据，不得不费更大劲去做产品演示和用户考察。
其实很少有企业高管不知道自己的毛病，在企业你随便去找一个人，对问题都能讲一通，在企业你费很大劲可能都找不到一个人能告诉你这些问题可以怎样去解决。
通观这个方案并没有研究为什么企业会产生这么多问题？问题是这些问题是什么产生的？为什么出这么多问题？而是不断说“我能！我能！选我，选我！”。
如果不能找到解决这些问题的原因，简单地去解决这些现象，就象治病不能治根一样。这样一个模板化，自我膨胀化的方案想打动用户的心是非常困难的。
不好的解决方案最大的问题就象写一篇议论文，能够发现问题(这个也是模板化的，可惜中国企业大部分没有意识到自己很多问题并不少见，总以为自己是特殊的一类企业)，提出答案(搞信息化)，但没有论证(为什么搞信息化和企业管理进步有联系呢？)。
没有论证的东西不管内容陈列得多么繁复，名词多么吓人，但是无法打动用户，特别是那种理性的用户。
看到方案时候，其实很多用户下不决心，他会感觉每家都差不多。
如果从没看过方案的人，突然看到这几个方案，你为什么会感觉某个方案写得好呢，关键是有的方案图画的好，通过图，通过表，会感觉这个公司还不错，很规范。但对内容认可程度并不高，实际上没看懂。
3.2.2 第二个容易犯的错误：业务解决方案成为功能列表
解决方案省事的一种方法就是将产品功能描述作为技术方案内容进行罗列，或者参照软件用户手册罗列，这种解决方案不是按照用户业务去准备的内容，而是按照软件商自己的喜好去编制的解决方案是很难得到用户认可的。
大凡按照功能列表组织的解决方案用户会有一个体会，庞大而庸长，但要看到自己想看到的部分非常困难。
而且这种方案还有一个特点，一个问题反反复复的提，在业务背景中指出某个问题，讲一通，在价值分析中又重点解释一通，到了功能介绍时又将某个问题来龙去脉概要说明一下，给用户感觉是一堆资料的堆积，哪里体现出了方案的针对性呢？
按功能列表准备方案的做法在很长一段时间内不会消失，这和我们普遍是4P销售人员，还缺少SPIN(顾问式)销售人员有关，在资源不足的情况下，要保证效率就只能提供功能列表方案了。 3.3 坏的解决方案有哪些特征？(中) 3.3.1 第三个容易犯的错误：结构不清晰
不好的解决方案最共性的毛病是结构不太好，没有清晰的思路。
没有思路的方案质量很低，用户在审阅过程中也不会体会到和一个专人人士通过文字交流的乐趣，他不得不从供应商混乱的思路中发掘亮点，看看到底是谁能解决企业的问题，真是一件痛苦的工作。
一种常见的方案结构毛病就是重复的内容在不同的章节反复出现例如在第一章介绍了对某个问题的分析，提出企业的需求，这第二章介绍方案价值的时候又用不同语句组织类似内容，到第三章解决方案描述中还是要把问题描述一遍，给人感觉思路不连贯，结构臃肿。
这里有一个方案提纲的提纲，我们以这个提纲为例子说明结构不清晰的方案。
1 公司简介及资质文件
1.1公司简介
1.2 自有产品及代理产品情况 1.3 重点工程介绍 1.4 公司资质复印件 2 分项标价表
3 ***PDM系统技术解决方案 3.1 ***PDM系统技术解决方案 3.2 ***PDM系统具体功能模块 3.3 报表及明细汇总 3.4 应用工具及封装接口 3.5 用户及权限管理 3.6 拼图打印 3.7 编码管理 4 实施计划 4.1 实施步骤 4.2 实施计划 5 培训计划
5.1 系统培训对象 5.2 主要培训内容 5.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 附件
这个方案第一部分、第二部分是用户投标要求，必须如此，但第三部分技术解决方案应该是重点，这个部分结构就很奇怪。
一般好的方案结构标题就是论点，内容就是用事实进行论证，子目录是上级总目录论点的分论点，逐层论证下来，方案显得逻辑性结构性很强，看看目录就能看出方案的逻辑推导体系。这就是所谓金字塔文档体系。
这个方案显然不是这样的，看起来一大堆内容，有经验的人一看就知道是内容的罗列。
例如第三部分总标题是技术解决方案，结果第一个子标题还是技术解决方案，撞车！一定层次感都没有。而且第一子章节技术解决方案后马上是功能模块，技术解决方案理论上包括功能模块，不是一个层面的东西，技术解决方案应该和实施策略，服务策略平级的内容，所以一定要谈谈自己技术解决方案，不如用技术解决方案思路或者特色来表达，和功能模块也就是一个层次分论点，统一支持技术解决方案这个大题目。
具体功能模块后面跟着一大堆章节就更奇怪，里面每个都是具体的功能模块，为什么成为和具体功能模块平级的内容？应该设置为具体功能模块子章节为妥。
很多人可能觉得用户对这个点很关心，要重点突出，所以一定要单独立一个章节，其实不必然，结构清晰的方案用户看起来才不费心，反而想这个方案，将具体功能模块，报表及明细汇总、应用工具及封装接口、用户及权限管理、拼图打印、编码管理列为同一层面内容，反而叫人看不出排列的思路，在厚厚一大本方案中寻找对应关心内容并不容易。
其实不如把技术解决方案分为两大部分，一部分介绍整个方案的实现思路，对于工作比较忙的人可以看这块中对企业业务和逻辑的分析是否到位，相当于整个方案的精华版；一部分介绍整个方案的技术支撑模块，对于项目具体负责人就可以深入研究技术支撑和业务思路之间是否存在合理的组织关系。
在第二部分技术支撑模块中根据业务逻辑或业务顺序设计功能模块的介绍。
例如一般企业是首先考虑静态技术资料的受控管理，在受控的基础上要求尽可能集成设计软件中的信息，然后要对设计过程建立严密的动态控制体系，此外还希望得到一些设计过程的专业支持，例如变型设计，二级工艺路线管理等等，最后要求提供一些编码，企业资源库等等辅助工具。这就是我们实现企业需求的一个大的业务思路，在这个业务思路下我们可以将技术支撑模块分为相应的五个部分。
到这里，整个方案大的框架就有了，我们需要设计一下分标题，使用户一看就可以进入自己关心的内容，而且每个部分都是对所属总标题的呼应支持，在业务环节上也是“相互独立，彼此穷尽”的环节。
在标题的设计上不要过于简单，例如技术资料管理，应该说有效的技术资料管理，因为有效才成为技术支撑模块，进而呼应前面业务实现思路中的描述。
3.1 业务实现思路 3.2 技术支撑模块
3.2.1有效的技术资料管理 3.2.2深入的数据集成 3.2.3严密的过程控制 3.2.4灵活的设计支持 3.2.5辅助设计工具
在上面这个思路基础上，我们就开始结合企业业务和产品功能进行考虑分标题下级的结构，我们用第一有效的技术资料管理为例子。
有效的技术资料管理到底要解决哪些业务问题才算完整呢？我们现在就开始将企业管理技术资料的业务进行罗列，在业务思路中逐步说明。
企业管理技术资料是以产品为线索区分的，所以第一要说清楚产品资料如何管理；
产品下所有零部件是以特征为线索区分的，所以第二要说清楚零部件资料如何管理；
有些零部件还具有共图共工艺的特征，所以第三要说清楚系列零部件资料如何管理；
进一步有的企业还有系列产品，所以第四要说清楚系列产品资料如何管理；
系列产品可能存在大量配置关系，所以第五要说清楚各种规则下产品配置资料如何管理；
有的企业产品配置型号在生产中还存在批次关系，所以第六要说清楚不同产品批次资料如何管理；
有的企业已经存在了大量历史设计资料，所以第七要说清楚历史产品资料如何入库管理；
在资料入库时有个问题每个人管理资料习惯不太一样，全部统一成一种管理方式是必要的，但可能失去一些灵活性，所以第八要说明为个人自组织资料提供哪些支持；
最后要说清楚产品资料为什么入库管理后是安全的；
我们现在总结一下，这些技术资料管理手段如果都提供了，应该是完整而且层次清晰的，这样的话，第一个子标题下的分标题又有了。
3.2.1有效的技术资料管理 3.2.1.1 产品资料管理 3.2.1.2 零部件资料管理 3.2.1.3 系列零部件管理 3.2.1.4 系列产品管理 3.2.1.5 产品配置管理 3.2.1.6 产品批次管理 3.2.1.7 资料入库管理 3.2.1.8 个人资料管理 3.2.1.9 资料安全管理
再看看这个标题和业务思路，这里面体现的一个结构化方式恰恰是“一句话一个意思，一层意思推动一层意思”，到最后就象剥笋一样，层层剥开，问题解决思路也就步步清晰了，企业看起来也就很明白。
那么我们还可以继续细分用户提出的各种业务需求，把企业各种业务要求对号入座，例如下面有一组需求：
有的企业要求用户访问控制；有的企业要求提供角色权限管理；有的企业希望按产品目录授权；有的企业要求全部存放在服务器的数据库中；有的企业希望支持多数据库独立访问； 有的企业要求提供备份工具等等。
我们现在看看这些业务是否都应该是关心资料安全的？所以应该放在资料安全管理目录下，而且这些需求也可以分为不同层次，一些是和权限有关的，一些是和存储和备份有关的，这样很快又可以把子标题和分子标题设计出来了。
同样我们可以推导出如下另外几个部分的提纲：
3.2.2深入的数据集成 3.2.2.1 主流CAD的集成 3.2.2.2 CAPP的集成
3.2.2.3 和其它常用工具软件的集成 3.2.2.4 数据挖掘统计工具
3.2.2.5 和其它PDM/ERP系统的集成 3.2.3严密的过程控制 3.2.3.1审核管理 3.2.3.2发布管理 3.2.3.3更改管理 3.2.3.4项目管理 3.2.4灵活的设计支持
3.2.4.1 变型设计业务支持
3.2.4.2 二级工艺管理业务支持
„ „
3.2.5辅助设计工具 3.2.5.1 编码管理
3.2.5.2企业资源管理器 „ „
这个结构化体系一旦出来后，整个方案的思路是否清晰明了，下笔容易了呢？
结构化体系最大的好处是不乱，今后用户提出任何业务需求，或者产品功能如何扩充，都很容易对号入座，或者扩充子标题。这也是体现了一种分类管理的思想。
当然这个分类思路根据不同业务特征允许存在多种可能，而且分类层次应不超过5级标题，否则文章的可读性不佳。
如果一定要超过5层，就可以采取其它排版方式体现。 3.4 坏的解决方案有哪些特征？(下)
3.4.1 第四个容易犯的错误：口语书面语混杂，遣词造句不严谨。
不好的解决方案还有一个毛病就是口语书面语混杂，遣词造句不严谨。
有的人写作时顺着思路走，口语化成分很多，例如本人的行文基本是口语化的，也体现了这个毛病。当然大师级人物的确可以将文章写得明白如话，但是对我们这些人而言方案是代表公司正式对外的文档，一定不要出现口语和书面语混杂的情况。
例如太多的儿，的，我们，你们等等都是口语化语言，不应该大量出现在正式方案中。
有的人写方案比较图表现，喜欢指出用户的不足，这个时候喜欢用很激烈的语言。例如缺少管理，业务失控，后果很严重等等语句，这样的遣词造句是不严谨的，方案用语不要追求“语不惊人誓不休”。而是理性分析，认真推导，句句讲逻辑。
实在要用一些事实说明企业的问题，不要用刺激性强的语言，例如说企业业务存在问题，可以说业务有可改进的地方，例如说企业管理失控，可以说管理上存在很难受控的环节。
这样的表达企业反而容易接受，不出问题。
3.4.2 第五个容易犯的错误：没有认真检查，存在大量硬伤。
不好的解决方案制造过程往往是找一个同类方案，然后主要工作是“CTRL+C”+“CTRL+V”。
很多人就图快，省事，没有很好的核对，结果往往容易出现如下几种错误：
第一有些企业在一个方案中用了不同的称呼(这个也要养成一个习惯在一篇方案中一个企业用一个简称和一个全称)，替换不完整，结果在方案中出现了其它企业的名称，非常不礼貌；
第二有时候替换过头，把一些案例中类似的话也替换成为给用户名称，闹出笑话。
第三只注意了文字替换，不注意图形中的替换，结果文字是一个用户的，图片是另一个用户的，感觉不尊重。
第四是只注意了文字替换，忽视了页眉页脚的替换，特别是注意了首页或目录的页眉页脚，没有注意正文的页眉页脚。
第五是案例不对，明明是汽车行业的用户，案例全部都是其它行业的，感觉在这个行业没有经验。
第六是联络方式不对，很多时候将别的营销区域方案拿过来用，服务信息都没有更正过来。
第七是存在大量技术硬伤，有时候为了突出软件技术实力，将大量专家都不一定看得懂的词汇大量堆砌，其实连软件公司自己都搞不清楚采用了哪些。
企图通过让用户对概念和名词发晕进而对软件产生信赖的方式已经过时，解决方案应该实事求是说明业务问题，不要在名词上忽悠。.3.4.3 第六个容易犯的错误：过于突出自我
很多人写方案大量出现“**软件公司”内容，甚至每个产品都恨不得加上自家标识。在很多地方行文造句都是“我能，我行，我有„”等语气。
这种方案很容易给用户过度营销的感觉。我们给用户写的方案在售前建议尽量用用户做前缀，例如说某某企业PDM项目，不要总在说某某供应商PDM的话，给用户一种相对的针对性，感觉这个方案的确是为用户准备的。
在售后实施方案中软件公司的名字只需要出现一次，后面就不需要反复出现，因为大家都知道是你的产品，何必反复体现，我们更应该把用户的注意力集中到产品本身就应该具备的功能和支撑业务上，而不要形成某某可以，某某不可以的印象。
3.4.4 第七个容易犯的错误：没有评审。
方案提交给客户之前，一定要经过评审。
没有开发点的方案，一般经过自评和互评即可，自评时，要重新审视整个方案的结构、问题描述、遣词造句等方面，特别是用替换修改的企业名称和营销平台等方面的内容，尽量减少低级错误。
自己评审过的方案一定要给一个其它的人评审。
互评时，要重新审视整个方案的结构、遣词造句等方面的内容。
对于有开发点的方案，要经过公司的评审。提交给公司评审的方案，一定是已经过自评和互评的方案，而且要注明主要看哪些部分，以及编写这些部分的背景知识。
3.4.5 第八个容易犯的错误：没有体现公司产品最新进展。
一般人写解决方案首先不是想着如何说清楚用户的业务，如何在公司产品中体现出对业务的支持，而是想赶紧找一个模板，把这一关走过去再说，其实很多时候就是对每个阶段工作没有质量意识最后导致工作处处被动。
所以写解决方案一定要根据公司最新产品功能认真组合功能实现企业业务，甚至可以考虑利用未来半年内会发布的功能认真组合，因为解决方案离正式实施往往需要半年甚至更长的周期。
很多时候解决方案一抄再抄，都是一两年前的模板，自然缺少竞争力和说服力。
这个问题的核心是公司有没有专人专岗负责对标准解决方案的维护和更新发布机制，其实比较好的一种做法结合典型项目技术公关推动解决方案水平不断完善和提高。
3.5 写好方案心得(上) 3.5.1 动笔前先打一个电话
一般情况下方案撰写人只是按照别人要求提供方案，并非直接利用方案的人，所以在写方案之前，问问需要方案的同事，甚至是用户，听听他们对方案的想法和建议，对自己写方案会有很大帮助。
很多时候方案准备完成方案接受者并不满意方案的组织，需要返工修改，所以动笔前先打几个电话，问问别人要什么，不但可以提高方案准备命中率，甚至可以获得大量现成的思路建议，对自己写方案大有好处。
3.5.2 一定要努力按业务逻辑去写。
一般写方案最简单的方式就是按照软件自己的思路和功能模块组织，因为有大量现成的材料可用。但这样方案对用户并非是一种最佳选择，因为客户要转换到供应商的思维才能看懂方案字句之间的含义。
如果从以客户为中心角度出发，方案应尽量让用户容易看懂，好理解，自然也就取得了几个印象分。
我们方案就是要先仔细探讨企业业务，不是将调研结论一罗列，而是从业务分析得出业务需求，最后描述技术实现手段。从这个意义上讲，解决方案要按照简明的操作手册来准备。
3.5.3 按标准套路写方案
不同类型的方案都有自己的套路，例如可行性报告，解决方案，建议书等等都有标准的套路，我们应尽量按照标准套路准备方案，不要自成体系，在套路下发挥，套路就体现了一种结构化体系化的思维模式。
关于常用套路我们另有一章说明。
3.5.4 先构思提纲，经过讨论，最后动笔
很多时候方案准备时间并不充分，很多人接到任务，压力之下立即开始动手，这往往是不好的工作习惯，有时候有模板，的确可以快速出活，但时间长了就养成一种惰性，替换方式抄方案还勉强，真要遇到有个个性化问题，因为在平时写方案过程中思维始终不经过结构化思考的练习，真到方案模板没有覆盖的情况，就没有办法应付。
好的方案特点是：标题就是论点。结论做为标题马上拿出来。
好的方案是观点鲜明，立场明确，有理有据，有血有肉。
所以有方案要写，一定不要急着写，而是想自己的提纲，这个完整提纲目录之间的逻辑联系和业务衔接自己在心里面推导得比较有力和充分了，才开始动笔快速拿出提纲，有了提纲写起来思路就不会断电，写起来才快。
好的方案一定是做了论点。
论点是假设的，例如说搞PDM有价值。
你说价值有三个方面，能降低成本，提高质量，能缩短交货期。这都是你的假设。
你怎么知道成立？就要找些事实去证明它。
我们现在都喜欢找什么事实呢？你用了这个功能，所以你的论点就成立，因为你有这个功能，所以你的效率提高了。
这都是扯蛋！为什么用了PDM企业就能做到这几点。根本没逻辑推导。
不是还有大把企业用了ERP，用了PDM还不是该咋的咋的，钱都打水漂了。
假如你有好多论点，论点怎么组织呢？你比如我要搞信息化，信息化有大价值，小价值对不对？你要把它都列出来，列出后你还要想一想这个价值和那个价值是不是包容的关系？
好处一定是每个好处都是独立，它是有层次，每层上的好处是平级的，大好处包含多个小好处，这些好处倒推出来就响应支持你的论点，这种方案看了以后别人就会理解并支持你。然后每个好处一定是在前一个好处的基础上往前推动一步，最好得出一个强有力的论证过程。
所以好的方案必须是金字塔型的，论据论证最后构成坚实的基础。
如果有条件的话，这个思路还应该和大家讨论，特别是一些重要方案，一定要先反复讨论提纲，大家各种意见和思路在提纲中统一了，再动手写。这样就不至于遇到写了一半被人否定，推倒重来的痛苦了。
3.5.5 找一个安静的地方和完整的时间段开始
写方案最怕中间不停被人打断，这样思路连贯性会很差。所以我无论接到多么紧急的方案编制任务，也不会急着去写，而是把手头该处理的小事情处理干净，然后保证开始后的时间相对安静和完整，这样才能保证方案的质量。
而且写方案一定要保证在一个时间段内初步拿出完整的推导思路和结构提纲才能结束去干别的事情，这样以后就是逐步补充和丰富内容，不至于还在为结构苦恼，不清楚从哪里下笔， 3.6 写好方案心得(下)
3.6.1 认真准备阅读提示和摘要
一个方案往往厚厚一本，更多是充点门面，领导是不会真看的。万一要看，也就是看看包装是否精美，和头几页文字。
所以方案可以单独附一份摘要，这是关于整个方案业务分析和解决思路的精华部分，当然也可以带一点实施方法和典型用户的介绍。
这样就可以让自己方案思路在短短几页纸中清晰描述和表达出来，这种提炼过的语言和文字往往更能打动人心。
一般写一份厚方案只需要一天，写一份薄方案需要一周，要求在三页纸内说明问题需要一个月！能把书读薄是能力的体现。
对于方案也一定要提供一份阅读指引，告诉不同的人其关心的内容可以在哪些章节直接获得，方便其阅读。实际上我们观察很多论文和书籍序言都有一段来说明这个文字的结构，其实这也是一个标准做法。
3.6.2 注意排版
方案一定要注意排版，印刷要干净，封面要隆重，装订要精美，方案就是一个公司的脸面，虽然不是说一份方案可以决定项目，但一份看上去都不好的方案一定很让人怀疑公司的能力。
我们很多人见过外企的文字，一般都非常精美，排版很漂亮，大家一看就觉得是专业人士所为。
所以方案的文字和图表内容最好请专门的美工设计一套标准的排版体系，对方案整体可读效果会起到极大促进作用。
现在很多方案都是密密码码，内容是多，可以有什么用？
不如取巧，少写一些文字，多在排版上动脑筋，实在想不出好的排版是什么回事的，去买基本畅销书，你会发现可读性好的书往往有一个技巧叫“留白”。
方案文字段落边框之间保持适当距离，特别是边框合理留白会让一份方案可读性大大提高。
象本文这样的文字如果加上留白设计可读性就会很不错。
3.6.3 注意积累素材
写方案无论如何按照企业业务组织，基本上90%内容是相同的，不过是根据不同思路进行组织而已，毕竟软件功能不会在短期内发生巨大改变，方案涉及功能也没有理由发生大的改变，所以方案中很多素材是可以通用的。
包括一些公司通用素材，更是要随时积累补充完善和归类存档，这样在写方案时才不会因为寻求这些基本素材浪费大量时间。
基本素材收集还要注意随时和公司公开宣传口径保持一致，防止引用过期素材。当然标准素材最好由公司统一维护。
获取其它素材的途径比较多，主要有：
现场初步需求调研与交流
与熟悉类似项目的销售经理、技术支持工程师、实施工程师沟通、了解
营销平台交流
企业网站
相关行业资料介绍
书刊
„„
一般可以从企业网站获取企业介绍。从网站获取的企业介绍需经“角色转换”和“内容筛选”，角色转换是指站在公司的立场描述该企业的情况介绍，要把第一人称改为第三人称。内容筛选是指主要介绍企业信息化的基础，包括企业的经济实力、管理水平、已完成和正在进行的信息化项目等内容。 3.7 方案分类及用途 3.7.1 方案的种类
目前，公司为客户撰写的方案分为：建议书、解决方案、投标书。技术白皮书应作为统一的资料提供。
建议书是用于动员客户启动项目，或者用于客户初步选型阶段的技术支持，以入围；
解决方案是用于洽谈技术协议和合同之前的技术交底，或者用于议标阶段以技术和实施服务等优势战胜对手；
投标书是用于客户招标的技术交底，以综合实力战胜对手。
3.7.2 方案的基本结构
3.7.2.1 建议书的基本结构
建议书的侧重点是分析客户实施某项目的宏观和微观形式、现存的诸多问题，提出实施该项目的必要性和紧迫性，再介绍相关产品和技术的发展现状公司的产品特点和优势，落脚点是公司已具备相当的实力，与公司合作成功率最大、风险最低。建议书的基本结构如下：
引言
现状分析与诊断
相关技术的发展现状
公司相关产品的特点
公司具备的实力和基础
结束语
各个部分撰写技巧如下：
引言部分
从全国、行业的信息化现状分析入手，说明信息化是大势所趋，再从本行业的产品特点出发分析信息化需要注意的关键问题，最后介绍企业的情况，特别是信息化的已有基础，包括企业的经济实力、管理水平、已完成和正在进行的信息化项目等，说明该企业已具备实施本项目的基础。
引言部分可分为：
制造业信息化现状
本行业信息化特点分析
信息化的基础
现状分析与诊断部分
从本项目所涉及部门的业务现状描述和分析入手，找出问题，并提出相应的解决办法。
现状分析与诊断部分可分为：
业务现状描述
问题分析与诊断
相关技术的发展现状部分
主要介绍本项目所涉及的PDM/CAPP/CAD等技术产生背景、发展过程，以及发展趋势等内容，并说明这些技术已是成熟的实用性技术。
相关技术的发展现状部分可按软件产品类别分别介绍，最后有一个小结。
公司相关产品的特点部分
主要介绍公司相关产品的主要特点，说明公司相关产品是符合其发展趋势的先进和成熟的产品。
公司相关产品的特点部分可按软件产品类别分别介绍，最后有一个小结。
公司具备的实力和基础部分
主要从公司简介、完整产品线、研发能力、实施与服务体系等方面，说明公司已有足够的能力承接本项目，并以成功案例证明与公司合作成功率高、风险最低。
公司的实力部分可分为：
公司简介
完整产品线
雄厚的研发能力
科学的实施与服务保障体系
成功案例
结束语部分
阐明公司愿与企业强强联手，结为(战略)合作伙伴关系，共同推进企业乃至本行业的信息化建设。
在结束语部分要明确提出合作建议内容，对于一些战略合作伙伴关系不能轻易宣讲和承诺，一定要经报公司批准之后方可承诺。
建议书的要求是简短紧凑，内容详实，便于用户决策，可以在一份建议书中形成几个可选方案，推动用户决策。
3.7.2.2 解决方案的基本结构
解决方案的侧重点是分析现存问题，提出功能需求及相应技术实现手段，并辅以实施保障措施，说明用户需求是可以实现的。解决方案的基本结构如下：
引言
现状分析与诊断
系统规划与设计
系统技术方案
系统实施方案
服务内容及措施
典型案例
结束语
引言部分
从全国、同行业的信息化现状分析入手，说明信息化是大势所趋。再从本行业的产品特点出发分析信息化需要注意的地方。接着介绍企业的情况，特别是信息化的已有基础，包括企业的经济实力、管理水平、已完成和正在进行的信息化项目等，说明该企业已具备实施本项目的基础。最后通过公司介绍说明有能力承担该项目。
引言部分可分为：
制造业信息化现状
某行业信息化特点分析
信息化的已有基础
公司介绍
现状分析与诊断部分
从本项目所涉及部门的业务现状描述入手，分析出问题，并提出改进建议，得出实施系统的必要性和紧迫性，以及需要解决的问题
现状分析与诊断部分可分为：
业务现状描述
问题分析与诊断
系统规划与设计部分
根据现状分析提出的需求，对本系统从总体目标、指导思想、总体框架等方面进行总体规划与设计。总体目标，是从企业已有明确的总体目标中，结合用户需求提炼出来的，不能简单照抄，还需适当调整与补充。总体框架包括体系架构、运行模式，以及其它企业关心的问题等。
系统规划与设计部分可分为：
总体目标
指导思想
总体框架
体系架构
运行模式
„„
系统技术方案部分
从基本功能介绍、关键问题解决方案两个层面介绍具体的技术方案。基本功能介绍是对本项目所涉及的产品，在标准模块功能基础上适当补充各模块的新增功能或用户的特殊功能。关键问题解决方案是就企业特别关心的问题(包括管理和技术两个方面)、企业特殊需求中有一定难度的问题，以及管理方面需要改进的问题等提出解决方案和建议。
系统实施方案部分
从本项目的预期效益入手，分析项目实施存在的风险，接着介绍公司规避风险的实施保障措施，最后给出初步实施进度计划和培训计划。实施规划要结合用户的实施打算，如果系统规模比较大，可以结合用户的需求适当进行目标分解，分期完成。
系统实施方案部分可分为：
预期效益
风险分析及对策
指导思想
指导方法
实施管理
实施规划
实施进度计划
系统培训
服务内容及措施部分
从公司能为客户提供全方位服务承诺入手，阐述公司技术支持与服务的保障措施，让客户无后顾之忧。
服务内容及措施部分可分为：
服务内容及承诺
技术支持与服务保障
典型案例部分
用公司典型用户的案例进一步证明，公司提供的技术方案是先进的、实用的，形成一套科学的、可操作的实施方案。典型案例选择的针对性表现在：行业、特殊需求、项目类型等方面有相似之处。
结束语部分
阐明公司愿与企业强强联手，达成合作伙伴关系，共同推进企业乃至本行业的信息化建设。
解决方案注意业务分析，系统规划，技术方案三部分不要反复出现重复的内容，或者为了表达自己技术方案是扣着业务需求而在系统规划和技术方案中再次反复描述需求，如果发现有这样的问题就要精心去组织方案提纲。
此外解决方案要避免浮夸和务虚的内容，要尽量让用户看到可操作的内容，例如在实施方案中用户最关心的是在实施分几个阶段？每个阶段相互配合工作是什么？谁去做合适？阶段结束的标志是什么？每阶段工作需要多长时间？根据企业实际情况有哪些风险？如何规避？基础数据如何准备？历史数据如何录入？工作流程应用前后有何变化？这些是用户真正关心的内容。
所谓实施方法论，实施原则，实施指导思想，实施团队结构等看起来饱满，其实是务虚的内容少写，写得越多用户越不得要领，实施方案的要害是具备不具备可操作性。这里面的原则就是计划越细化越具有可操作性。
3.7.2.3 投标书的基本结构
投标书是针对标书的解决方案，包含解决方案的全部内容，再增加公司优势和相关附件。投标书总是原则是按照用户提供的招标书要求准备，用户要求如何提供资料就如何提供，不要任意发挥。
常见投标书的基本结构如下：
引言
现状分析与诊断
系统规划与设计
系统技术方案
系统实施方案
服务内容及措施
开目公司的优势
典型案例
结束语
相关附件
开目公司的优势
相关附件
相关附件按照招标书的规定组织附件。
3.7.3 方案的针对性
为使方案具有鲜明的开目特色，方案必须具有一定的针对性。不同类别方案的针对性有不同的体现。
建议书的针对性体现在同行业的信息化特点分析，本企业已有的信息化基础、本企业的现状描述与问题分析等方面。
解决方案和投标书的针对性有相同的表现，主要体现在：同行业的信息化特点分析、现状分析与诊断、总体目标、关键问题解决方案、实施规划与进度计划、典型案例等。
现状分析与诊断部分、实施规划与进度计划部分，不能简单把客户名称更改就变成另外一家的情况。
总体目标部分，有企业的个性，如果需要可以分解成近期、长期、远期目标。
解决方案中可单独把企业关心的关键问题单列为一部分，紧密结合企业的需求特点，不能简单套用标准说法，必要时可以通过定制配置实现。
解决方案中的关键问题与投标答辩PPT中的关键问题有区别。投标答辩PPT中的关键问题主要是展示我们优势部分，以攻击对手的劣势部分，但一定要有绝对的把握。
4 如何做产品演示？
4.1 什么是演示？
入行五年，售前售后演示最少也有两百次，也算有一点经验了，今天把我个人做做产品演示的体会做一总结，希望对所有想做好演示的人员提供一点帮助和指导。
