个人项目记录好像总结

个人项目记录好像总结 序言 这个世界上写给项目经理的书很多，写给 IT 项目经理的书也不少，但写给从事管理软 件实施的项目管理书籍并不多。 而笔者在从事项目经理工作中感到一个很苦恼的问是，很多书其实非常经典，但都 有一个缺点:理论正确，实战指导作用不足。 不是亲身亲历的人是很难领悟到那些理论的精髓，而每个刚刚入行又立志成为一个 IT 实施的新人往往不是一开始就能从理论上武装自己， 在他们起步的时候， 每天要面临着各种 具体工作任务，例如做调研，写，写方案，写备忘录，做项目汇报，做演示，这些活动 与其说是项目管理发挥作用大，不如说这是具体业务技能的领域。 一个 IT 人如果没有经受专业的培训，在不能掌握这些技能之前，我个人体会是往往是努力 的把事情做砸。 目前的 IT 服务质量更大程度上取决于实施人员个人能力， 也许只有有一大批同等质量 服务的实施人员涌现，一个公司的才有可能顺利推进项目管理的思路。 因此笔者就有一个想法，想把自己在项目实施从售前到售后的体会和经验总结为一些 专项技能，并希望它具有可操作性，和大家一起交流总结，不断积累并臻于完善。 也希望各位朋友看后多评论，多留言，多给笔者提出改进意见，本人将结合大家意见 不断完善，将大家的想法变成业内智慧的结晶，让更多的人能在 IT 实施工作中做到游刃有 余。 前言 在 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 如何写业务调研报告 调研结束后第一个必须尽快整理出业务调研报告， 业务调研报告主体内容可以在业务分 析会上得到用户确认。 写业务调研报告应该结合软件供应商特点形成一个比较统一的汇报目录模板， 有了模板 整理起来就快，不同软件关心业务内容不同，模板也应该不一样。 一般而言业务调研报告目录可以分为三个大的部分， 第一部分是业务基本情况介绍， 第 二部分是企业业务流程图和数据流图，第三部分是项目关键价值点。 凡是不设计业务流和数据流，但必须要描述的内容，例如企业的一些基础数据情况，我 们把其作为企业的基本情况介绍，例如企业概况，企业设计数据统计情况，企业工艺数据统 计情况，企业标准化编码规定等等，做基本情况介绍时要把握两个原则: 第一是结构化，不要散乱，将相关性强的一组基本情况设计成表格填写，这样既方便填 写，又不容易遗漏。 第二是按照调研先后顺序组织，和业务流顺序尽量一致。这样不但层次清晰，而且可以 直接将每天调研日志内容复制修改就可以得到最终结果，大大提高工作效率。 业务流程图和数据流图有大量标准工具和方法指导， 建议这里大家去找相关专门知识学 习，本文不在这里展开。 第三部分项目关键价值点是非常重要的， 项目价值点组织也必须符合结构化层次， 不要 将很大的价值和很小的价值并列排放，应该将最大的价值，可以相互独立做为一层，然后将 小价值分别归类到不同大价值下， 形成一个价值支撑体系， 这个支撑体系也是解决方案的实 现思路。 2.12.2 业务调研报告完成后续工作 业务调研报告完成后必须赶紧去找后续工作同伴， 按照约定的工作计划把调研报告交给 他们，如果有时间，还可以安排一个内部业务分析会议，做一个全面的介绍。 帮助团队成员可以准确理解调研报告，启动后续工作才是一个调研的工作结束。 如果你能按照以上方法进行调研，相信你的调研质量一定很棒，这样的话，不管后续工 作是什么，我相信你都会得心应手的去完成，或者帮助你的团队成员去完成。 这也就是调研最大乐趣所在。 2.13 接口调研背景知识(上) 现在管理软件项目中接口需求很多， 很多项目接口实现得并不理想， 原因就在于接口协议质 量不高，而接口协议是和接口调研紧密相关的。一般接口调研和其它调研方法是一样的，但 要做好接口调研就必须具备一定的专业知识，这可能是能否做好接口调研的关键。 接口协议除一般性协议要素外，应该包括如下内容: 2.13.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.14 接口调研背景知识(下) 2.14.1 接口内容 接口方式一旦确定，就需要确定接口的内容。 接口内容首先要确定接口入口， 从哪里开始汇总接口数据， 接口数据每次包含多少对象， 这些对象是如何联系在一起的。 例如接口数据每次都从一个完整的产品上开始汇总， 或者从 一个完整的工程任务上开始汇总，或者从任意零部件上都可以发起汇总。 第二接口内容要确定接口时机，要明确哪些字段由数据提供方(其它系统)写，那些读， 在什么时候进行。 也就是约定当数据达到怎样的规定后才可以启动接口输出， 此时也可以约 定接口输出负责人员。例如当产品结构发布，相关工艺数据也发布后才能启动接口，如果有 明确接口时机要求，接口程序应适当做校验性判断，防止提供不正确的数据给下游系统。 第三接口内容要确定接口格式。 接口格式包括明确数据交换提交的方式: 是文件级还是数据库级， 然后明确交换文件的 名字，存盘路径。 明确文件的格式，包括文件或数据表包含的字段名，字段次序，字段类型，字段长度， 分隔符(如是文本文件)，是否必填，默认值，下游系统对应含义，实际数据样例，接口对应 数据来源，该字段在实际操作中填写规则。 第三接口内容要确定接口样例。 接口技术协议附件必须包括用户方提供的样例数据， 样例数据必须具备典型特性， 能够 覆盖企业各种可能的实际数据情况，保证验证样例数据对接口测试的完整性; 如果一个样例不能覆盖可以提供足够样例数据， 用户方可提供多个样例， 直到可覆盖各 种可能情况为止。 用户方要保证样例数据的规范性。 此时可能还需要针对接口样例提供数据规范性录入操 作说明。 依据所提供样例最终得到的接口中间文件将以完整实例作为验证标准依据。 如果有多个 样例， 则需提供多个完整的接口中间文件实例。 准备接口样例将大大加快验证时间和接口程 序调整反复时间，也有利于企业，供应商快速就接口协议达成一致性理解，是看起来慢，实 际上最快的有效接口方式。 2.14.2 接口数据一致性握手方式 接口数据的一致性通握手方式来保障。一致性分为静态一致性，动态一致性，双向一致 性。 静态一致性:如物料编码信息，原始工艺设计信息。 动态一致性:如设计更改信息，在一个系统内的数据更新后，要求另一个系统内的数据 也要进行相应的处理。握手方式即明确如何让对方系统得到要进行更改的信息(也可能是依 靠人员来进行手工操作)，这样对方系统对接口文件进行处理。 双向一致性:复杂的系统甚至要求，对方系统处理的数据结果要进行反馈。从而更新本 身系统的数据。这里面也要对反馈进行定义。 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 什么是演示, 什么是演示,入行五年，售前售后演示最少也有两百次，也算有一点经验了，今天把我个人做做产品 演示的体会做一总结，希望对所有想做好演示的人员提供一点帮助和指导。 产品演示不是演讲，也不是答辩，更不是培训。 尽管在很多表达和现场互动技巧上，演讲，答辩，培训和演示都有相通的地方。 演讲更侧重对某一个问题看法的陈述，主要是交换观点，允许争鸣，听众可以不同意你 的观点，但一定会捍卫你发言的权利。 除了常见的演讲比赛外，很多时候演讲者是受邀请，以一种被尊重状态出场，是处于一 种比较从容的心态下开始的。 演讲的过程一般也是比较连续，不会被随意打断的。 答辩更侧重对话双方的交互， 具有很强的考核目的， 通过对答辩问题的反应答辩主持方 来主动判断他想获取的信息。 答辩的过程一般是不连续的， 随时都可以中断响应不同的问题， 答辩的节奏和压力也更 为紧张，时间非常紧凑。 培训更侧重于传授操作， 此时被培训者已经认可培训者所在公司和产品， 在过程中更多 的是教学相长，形式可以多种多样，根据不 同培训层次灵活组织。 演示不然，演示是有极强的目的性。演示往往是要在有限的时间内(比答辩要舒展)，面 对一群不同心态或者不明心态的人快速把自己所在公司、 公司产品和服务， 包括自己最大范 围内推销出去。演示过程中还要随时准备开始各种技术答辩，应付各种刁难。 演示是主动影响客户(用户)的过程，售前演示也是主动和竞争对手竞争的过程，演示更 是个人魅力展现的过程。 整个演示就是一场复杂的脑力游戏， 看看我们有什么办法在短短 1 到 2 个小时内更能抓 住用户的心～ 4.2 演示的目的: 4.2.1 售前演示的目的 介绍公司，通过自己的言行和产品介绍展示公司的形象; 强化自己的优势，给竞争对手设置一定的技术门槛; 讲出自己能为用户做什么，解决什么问题，愈是用户关心的问题愈要主动沟通和交流， 让用户对软件产品技术和实施能力放心; 进一步判断用户关注的项目重难点，了解我们前期准备的不足，采取针对性后续对策。 如果是这个项目一定要解决的问题， 目前产品又无法实现的内容， 必须尽快反馈给公司决策。 4.2.2 售后演示的目的 介绍公司和产品，让广大具体用户认可公司，取得最大范围品牌认同，减少实施阻力; 宣讲对企业问题的认识，提出自己的业务解决思路，主动控制项目边界; 通过现场互动进一步判断用户关注的价值点是否在项目边界内， 确认是否要调整项目边 界，尽快反馈给实施团队或公司决策， 除了目的不同外，售前演示比售后演示更具有挑战性，用户更可能具备不合作性，演示 没有达到目的将可能导致不可挽回的局面。 一般在管理软件售前项目中， 产品演示效果不佳和典型用户考察效果不佳两个因素可以 导致直接出局，没有挽回的余地。所以产品演示一定要解决用户对我们技术能力上的顾虑， 保证得到进入下一轮筛选的机会。 所以本文重点将放在对售前演示工作的说明上，以下内容基本上都针对售前演示说明， 售后演示可以参考并简化部分内容进行即可。 4.3 售前演示为什么效果不好,(上) 坦率地说， 我们业内大部分管理软件演示总体来讲不是特别理想， 并没有深入打动用户。 它为什么不理想呢,我个人认为有六个大的原因。 4.3.1 第一是演示没有整体策划。 成功的演示绝对不仅仅是两个小时的精彩发挥， 要保证这个精彩发挥， 必须做大量的基 础工作才行。 好的演示一般都有一个人在精心进行整个演示活动的策划， 是整个项目商务活 动中必要的一环，而不是一个在孤立准备的活动。 商务人员往往期望有一个“高”人，到现场做一个精彩绝伦的演示，让竞争对手甘拜下 风，让用户眼前一亮，然后再四平八稳的把事情摆平，这种事情基本上不存在。 之所以某些人演示做的好一点， 只是因为他准备的比别人多得多， 如果演示者平时每天 花半小时去演示，三个月后水平将是非常厉害的。 而现在许多人因为有某个单子才想起要准备演示， 这个时候自己能演示什么呢,只好先 看看谁能搞定这个事。这样必然会导致某几个人水平越来越厉害，而大家都不厉害，业务肯 定做不好，都找这几个人，这几个人累死，而自己做业务总是束手束脚嘛，这不是一个很好 的方法。 只要做好准备，每个人都能成功的做演示。要做好演示就不要随意演示。 不要以为产品有几个亮点，商务人员就想给用户“镇”一把。想这样演示的，因为准备 不足，或者没有套路，结果用户第一眼就看不中，会不断的让你演示，反反复复。 结果干了一件什么事呢,不断给别人启蒙，摘桃子的是别人。 即使在一次演示中效果很好也不意味着项目就是你的， 而是在成功演示后安排大量后续 工作。一般管理软件项目周期很长，在短期之内，你不做太多投入把大单搞下来，但一定会 有一个很密集的时间，投入了密集的资源做一系列的事，让上上下下都认可你了，后面再按 部就班进行。 这就要求要提前规划演示， 一般商务人员要提高半年或一年判断大概在什么时候演示比 较合适。 策划什么呢, 第一要演示哪些东西让用户很接受。 如果要想知道这个事， 首先要通过接触对企业基本业务做个判断， 判断以后安排技术工 程师，或总部协调资源进行一次到位的调研，然后提前半年、一年准备，做一个相对来说比 较和企业个性化特征吻 合的配置，这叫技术准备。 第二，如果安排演示，一定要考虑演示达到目的了，后续最理想的工作安排是什么,是 不是可以马上安排用户和公司考察，这样他会在一个很高的情绪下不断认可公司实力。 一定要考虑，演示以后效果好怎么，效果不好怎么办,我们往往是演示了就完了，其实 这个事根本没完。 第三，演示给谁看，一定要保证这个人到位。 演示的时间宁可推迟，一定要保证你希望来看的人一定要到场，如果不在场，就不要演 示，没有意义。 4.3.2 第二是演示没有套路。 很多人对软件理解不同，喜欢按照自己的思路去发挥，每个人都进行发挥，结果导致整 个公司的演示没有统一的套路。 如果没有统一演示套路， 演示行为就无法标准化， 没有标准化的东西在管理上很难受控， 也就很难保证质量，很可能某几个人演示很不错，大部分人演示不到位，那就赶紧把这几个 人的套路标准化并推广。虽然企业有很多差异，但还是可以寻求共性，无非是针对不同类型 多准备几种统一的套路。 套路是一致的， 但并非是说所有的人都在背台词， 而是说所有的人用比较一致的思路去 讨论问题，谈问题的实现方案，特别是一些共性的问题。 4.4 售前演示为什么效果不好,(下) 4.4.1 第三是套话理念太多。 在策划演示套路时要更多考虑一个问题， 不是我们有什么功能， 而是这些功能按业务能 不能串起来。在考虑演示内容时，不要空谈理念，在讲到一个业务线的时候，把想法拔高一 下，在合适的时候自然地带出来。 如果大量在谈理念，一是低估了用户的知识面，二是提高了用户的期望值，三是大量时 间并没有让用户看到实在的东西， 谁也不会下决心购买概念， 用户特别是技术型用户更愿意 看到实际的内容，对于高管，在交流时谈谈理念可能更合适。 演示不能单调的只是将 PPT 的内容念出来而已，PPT 的内容要简单，主题明确，而演 讲者脑子里的东西则一定要充分口语化表达。 4.4.2 第四是演示时机不好。 过早演示往往是演示效果不佳的一个重要原因， 很多客户经理其实缺乏销售管理软件的 经验和从容自信，也缺少业务内涵，因此当发现一个项目信息后，他们往往不知道下一步可 以做什么，要么被动地随着用户要求走，要么就积极主动创造调研和演示的机会，期望通过 一次良好的演示或者用户考察达到他们想要的目的。 实际上一个大的管理软件项目售前周期是很长的， 匆匆忙忙去调研演示， 效果往往不好。 我本人发现在长期跟踪的项目上， 往往是早起的鸟儿没虫吃。 不要怕耽误一个月两个月时间， 可以按部就班进行， 当然那些客户经理自己都没有跟踪， 主动找上门来的紧急客户项目例外。 为什么呢,一般客户不可能一开始就完整知道这个概念和自己的业务需求， 经过很多供 应商多轮次攻关后， 客户才能比较清楚一些概念和自己的业务需求关系， 也就比较容易看懂 演示，演示也能达到目的。 大项目上是不会有太多的演示机会的， 特别是在多竞争对手情况下， 宁可等到公司准备 就绪，确定演示策划和实现计划后，才能客户预约，哪怕耽误一些时间也不用担心，给客户 解释清楚，一般都会理解的。越是急着演示越可能成为用户启蒙者，而不是签单者。 4.4.3 第五是演示人员能力不足。 演示这个工作不是谁都可以做的， 它对人员综合能力有极高的要求， 显然这种能力人员 在任何一个公司都是稀缺资源， 但是几乎每个大项目都需要进行演示， 在拥有能力的人员不 能到位的情况下，只好用能力不足的人员去做演示，自然效果不佳。 4.4.4 第六是演示准备周期太长 很多项目用户提出要求演示， 客户经理为了表示对项目的重视， 也为自己争取到一个表 现的机会，一定是满口应承。 应承过后很多客户经理就会陷入困境， 迟迟不能调度到演示人员去现场演示。 如果让自 己或技术支持去讲，肯定是讲不清楚，达不到效果。 如果让公司顾问来讲，顾问太少，单子太多，都不知道什么时候才能轮到自己这里，即 使来了一个顾问，也是没有什么准备，匆匆忙忙，效果也不一定好。 当用户发现供应商对答应的演示时间一拖再拖， 就容易怀疑供应商的组织能力和产品实 际 水平，最终演示时也不能足够重视，结果参与人员不足，自然难以达到效果。 所以作为一个软件企业要想办法让演示组织工作程序化， 演示套路标准化， 有一个团队 在全力支持演示各个环节工作。 软件企业让可能要进行演示的人员不断练习， 保证每个人演 示可以达到一个基本的质量， 保证企业随时具备四到五个可调度， 能清楚演示自己主导产品 人员是非常重要的基础工作。 4.5 售前演示工作应如何组织,(上) 一个好的演示是需要经过大量复杂精心准备的系统工程， 是团队合作的产物， 是反复演 练的产物。演示工作是有一定的内在规律的。 演示工作一般分为演示准备，演示，后续跟进三个环节，每个环节工作侧重不同，但应 该有一个总体演示工作组织策划人。 演示策划人未必一定就是演示者本人，但一定要是可以对项目可以长期跟踪负责的人， 而不是临时的外部成员(例如从总部借调的咨询顾问资源)。 很多时候总部顾问只是策划人达到演示目的可通过合理方式调度的资源，有了专人负 责，演示过程才能有策划，忙而不乱，进退有序。 很多项目跟进半年来， 还没有任何关于演示的策划， 一直要等到客户通知才匆忙通知准 备，一切都没有计划性，或者用客户工作突发性强为借口回避自己工作不到位。 从这个角度出发， 我个人认为演示策划人应该是一名有经验的商务人员， 在整个售前项 目生命周期内策划一次或几次(对于大型项目可能是必要的)成功的演示本来就是商务人员 的本职工作。对于没有经验商务人员接手的项目，其直接主管领导需要负责，并同时传授和 指导相关操作经验，以便下次其可以独立操作。 一般售前演示工作准备包括以下几个环节。 4.5.1 和客户建立比较紧密的商务联系 在进行演示工作之前，一般情况下应该建立了良好的商务工作基础。 例如了解企业组织结构，决策模型，和决策层建立比较充分的联系和良好的第一印象， 为演示工作创造一个良好的认同氛围，让大家可以带着认同和学习的心态去看演示。 也要了解是否有竞争对手进行了演示，效果如何，用户对哪些内容比较感兴趣，哪些感 觉不够展开，以便我们进行针对性准备。 我们在商务上容易犯的一个错误是客户经理不知道如何去打动用户， 面对用户提出来的 业务需求又无法满足，只好承诺先调研，后演示，通过这些工作驱动项目往有利于我们的方 向进行。 其实客户经理未必要有很好的技术背景，但在商言商，无论你卖什么，让客户信任你所 在公司才是商务工作的本质。 客户经理应该主动考虑我如何让用户建立对公司的信任， 演示 工作是整个信任工作中建立技术信任的一个环节。 在此之前， 客户应该对客户经理本人已经 建立基本的认同，才能进行后续工作。 4.5.2 申请有能力的人进行业务调研 好的演示是针对重点(业务流)和难点(用户极度关心的技术问题)演示，针对用户的痛处 演示，针对用户的层次演示，而不是罗列我们功能的演示。 要做到这点， 一定要安排时间做用户的需求调研和业务分析， 实际上大部分用户也会主 动要求我们做这个工作。 要得到能对演示起到指导作用的需求调研和业务分析， 关键就在于演示策划人一定要安 排具有相应能力的人，或者调研者在有相应能力的人指导情况下去做业务调研。 一个能力或经验不足的人调研结论对演示并没有实际意义，这个时候用户就会比较失 望，花费了大量时间调研但居然演示内容针对性不强，这样的演示效果可想而知。 所以成功演示前往往有一次比较到位的需求调研和业务分析过程。 业务调研有两个可选择的策略，如果客户提供的时间很短，一定要协调派能力强的人， 甚至就是演示者本人来调研; 如果时间比较充分， 人力资源又比较紧张的情况下， 可以派一般的技术工程师和实施工 程师多花一点时间， 按照公司调研套路和演示者要求将问题搞清楚， 再让演示者准备演示方 案。 4.5.3 进行内部沟通 好的演示是团队的产物，是群策群力的结晶。没有人是全能和面面俱到的，每次成功的 演示往往都经过了营销人员，咨询顾问、规划经理、公司高管、还有实施项目经理的充分交 流和讨论，形成对问题的共识后做到的。 一旦确定要给用户进行演示， 就有很多内部沟通工作要做， 第一件事情是按公司流程申 请到合适的资源进行演示准备，并安排足够的时间准备，且保证客户可以接受演示时间。 资源的协调和计划的落实是演示策划人的职责所在，这就是售前的项目管理重要内容。 如果是卖产品，销售经理能胜任，如果卖项目，就必须是懂项目管理和策划的人才能胜任。 要协调的资源可能很多，包括演示人员，配置人员，开发人员，甚至高管。这些都必须 在一个完整商务策划中体现，形成一个攻击波团，不要一下子来个演示，然后又没有跟进工 作安排，要在一个比较短的时间内给客户一些组合拳有力地打动他们。 落实资源后演示策划人要让公司上下人员对演示思路和准备工作达成共识。 共识包括三个方面: 第一选择怎样的产品线或模块组合， 很多管理软件系统是很复杂的， 在短时间内全面演 示是不现实的， 所以一定要合理选择产品线组合或功能模块组合， 争取在最短时间内让用户 明白我们产品能力边界。 并准备对应产品线的演示思路和说辞， 很多公司这些标准产品都有 标准的演示套路可借鉴，适当调整即可。 第二建立对产品能力的信心， 管理软件实施成功率不高， 很多客户经理在销售时心理是 发毛的，底气不足，这样的状态很难要求他充满自信的演示，一旦在演示过程中遇到一些刁 难， 心理素质不过硬的人可能就提前崩溃。 所以演示前要一定要让演示者充分看到产品能力， 建立共同的信心。 第三确定是否要协调资源快速开发某些功能点或者按照用户数据建立演示环境。 大部分演示就是按照标准套路进行， 毕竟很多企业存在共性的内容， 并不需要一个企业 准备一套东西，这样成本很高。 但对于一些重要的项目，在演示前一定花费时间做定制配置，不做样板化的介绍。用用 户的数据，用户的言语，用户的报表演示，还是值得的。 定制配置的要害就是一定要在项目资金允许的情况下， 公司决策层认可的情况下， 规划 方向认同的情况下，开发资源接受的情况下(这些都内部沟通的内容)，演示出用户最想看的 内容，而不是我们最有心得的内容。 要达成这些共识，不经过大量沟通是不可能的，没有沟通，很容易出现演示前后同一公 司不同人员说法口径不统一的情况，对项目并没有好处。 4.6 售前演示工作应如何组织,(下) 4.6.1 编制演示方案 内部沟通完成， 达成共识后就可以进行演示准备， 演示准备这个环节就是要按照共识来 准备一份演示方案。 有了演示方案，演示时才能心中有数，让别人提意见时也有了一个参考的依据，今后演 示方案也可以作为公司知识积累，和业务持续改进基础。 完整的演示方案应包括三个部分: 第一是演示产品线和其它软件环境， 包括操作系统数据库和演示时要调用的其它应用程 序或各种资源(例如动画，动态库等等); 第二是演示的思路，演示一定有一个整体思路贯穿，这个思路根据演讲的内容、听众的 特点和演讲的环境而且尽可能按照企业业务准备， 而且简明扼要说明了自己是如何按照业务 思路连串软件功能模块达到支撑业务模块的目的。 演示思路要考虑你想告诉听众什么,先要确定演讲的目的。 准备工作的每一个步骤始终 要围绕这个目的进行。只有这样，才能保证你的演示方案有针对性且高效率。 第三是演讲词和配套操作顺序， 要写清楚什么操作提供怎样的说辞， 操作的时间在哪里， 哪些需要提前操作或打开界面， 提高演示效率， 哪些操作可能需要较长时间等待(例如汇总)， 需要准备更充分的说辞，操作进入界面和数据位置，哪些操作在演示时不能做，这些都要逐 段落实写明。 一般认真准备了详细的演示方案，现场演示就不会失去思路，操作也不会零乱，往往可 以达到很好的效果。 演示方案的准备应该是公司级的行为， 经过长期积累完善的演示方案就是一份积累了全 公司业务经验和产品功能的解决方案， 可以成为实施标准配置， 产品规划需求和理念来源(准 备售前演示过程也经常可以发现软件不足和可以改进的地方);测试的标准业务测试大纲， 培训的标准软件平台， 咨询顾问部也可以按照这个演示套路定制解决方案， 形成几个精练友 好的业务解决方案范本。 这样的话软件公司可以通过演示方案把高管到基层员工， 从外部业务部门到内部业务部 门，从销售前期到实施后期，通过这个售前演示技术准备活动达成了高度统一， 大家的经验 和知识就有了一个共同的积累平台。 4.6.2 反复排练 如何在现场进行一个好的演示，我的建议只有一条:练习，练习，再练习～ 只有这一条没有别的捷径。 成功的演示无论演示者经过多少实战，必要的针对性练习还是非常重要的。 如果是理念演讲为主，没有太多的操作，排练 1~2 次，基本效果是有保障的，如果是产 品演示，特别是需要多人配合的话，至少要练习 3 轮以上。 如果是产品演示经验少于 10 次的人，建议至少在内部演练 5 次以上。 建议:为每小时的演讲作 10 小时的准备，随着你的经验日益丰富，你会发现所需准备 时间会逐渐减少。 试讲次数越多越好。如果你对自己有信心，听众就会相信你。 演讲的时间包括使用视听工具和回答听众提问的时间，因此试讲中要留出这些时间。 每次试讲都要逐渐脱离讲稿。 试讲过程可以对着镜子练习，而且尽量大声。 试讲练习到一定时间可以安排录音或旁听， 这样可以发现很多自我感觉良好下无法发现 的问题。 排练是一定要确认自己对所要介绍 PPT 的内容或者演示操作内容非常了解，起码要做 到看到一页(步)就能想到其后三页(步)所要演示的内容。 内部演练一定要有 2 个以上比较有经验的人站在用户角度上评点， 让他们充分提出改进 意见，根据意见马上调整。 内部评点还有一个工作是模拟真实用户问题刁难演示者， 对一些关键问题提前准备说辞 也是排练时要完成的工作。 怎么挑毛病呢,基本上你在讲时下面坐的想打瞌睡这种演示肯定是失败。 坐在下面眼睛 还能睁着，感觉你讲的有一二点收获，这种排练就比较有感觉了。 如果演示是定制配置，更由于可能存在新开发功能，产品稳定性还没有完整测试，此时 演示前一定要反复进行操作排练测试，确保不出意外。 内部排练有两个经验: 第一经过排练一定比没有经过排练强; 第二排练过的人现场讲演效 果一般比练习效果强，没有排练过的人现场讲演效果一般比练习效果差。 一个人经过反复排练以后往往有种压抑的欲望需要渲泄，把这种渲泄的欲望放到现场， 效果一般都不错。而不练习的人一到现场就畏惧感加重，最后也无法正常发挥。 如果一些相对演示经验比较丰富的人都认为这个演示方案有说服力， 演示效果没有大的 问题，对对手、企业各种情况都进行针对性预演答辩通过，就可以准备上战场。 4.6.3 约好演示时机和用户 产品演示是目的性极强的工作， 就是要通过演示打动用户， 促成其选择或实施我们的软 件。 产品演示一般也要经过大量时间准备，成本很高。如果参加演示的人不到位，演示再好 成效也不大，将不得不再次安排演示，这种反复将导致工作成本急剧增加，反复演示也未必 也能保证演示资源和效果。 因此产品演示对象一般要追求参加人尽可能多，让对软件选型有影响的人员尽量参加， 特别是技术类型人员，争取都能参加。 因此演示前演示策划人一定要和用户详细约定， 在商务工作做到一定基础之上后， 利用 相互的信任关系使得用户愿意配合， 调动一切应该来也可以来的人员参加产品演示会， 保证 演示的效果。 要做到这一点，就是在确定公司可安排的演示资源后，立即和用户做大量沟通，确定应 参加人员，可参加人员，比较合适的时间段，场地和设备，在这些条件都具备情况下安排演 示。 如果演示条件不具备，宁可和用户反复解释，也不轻易安排演示，演示讲得就是“一击 必中”，如果没有这个效果，就不如多花一些时间在预约工作上。 4.7 如何准备标准演示套路,(上) 4.7.1 售前演示工作要不要标准化, 有人认为演示时企业实际情况千变万化， 难有一定之规， 自然也很难准备标准化的演示 套路， 而且企业业务情况不同， 用标准化的套路去应对效果可能达不到， 应该采取定制演示。 这个说法看起来有道理，但实际上无法操作，定制演示的前提是比较详细的需求调研， 如果每个项目都做如此投入的话， 供应商根本无能力负担， 而且需求调研即使很到位也未必 能保证产品演示就能准备到位。 其次定制演示对演示者个人能力要求很高， 一个企业不可能大量存在这种强人能人， 定 制演示要么人力资源响应不到位，只能用比较低水平人员去演示，要么演示准备周期过长， 这两种情况都是无法接受的。 从另外一个角度看，企业业务虽然千差万别，但是以机械行业为例，生 产模式也不过是 单件、多品种小批量、大批量三类，设计模式往往也就是新产品研发、变型设计、系列化设 计几种常见类型， 完全可以用统一的平台来支持， 相应演示套路也可以针对不同企业类型标 准化。可以说业务是标准化的，定制一般也不过是数据是个性化的。 如果精心准备了完全按照实际典型企业业务运行的标准化演示套路有很多好处: 可以结合准备标准化演示套路工作将一个公司在不同行业企业业务经验有效总结和抽 象出来，形成指导产品发展的业务规划模型。 对营销工作而言， 我们业内的营销人员是不会去总结研究产品细节的， 也不太熟悉企业 的运做模式， 这样推销管理软件时有很多困难。 一旦公司层面准备一个条理分明， 思路清晰， 亮点突出，操作固定的演示套路，营销人员将大大降低对公司产品学习和掌握的成本，并能 够培养出一批能够按照公司要求介绍产品特色的人员，解决售前演示资源瓶颈问题。 售前演示准备必须根据企业业务走。演示套路内容应是从实际实施工作中总结出来的， 一般能在企业实施得很好的业务演示效果也不错，而且可以代表产品目前可实施的最高水 平。那么对实施工作而言，这样的演示套路对实施人员打开思路，提高配置水平有很强的导 向和示范作用。 对产品规划工作而言， 通过精心准备业务演示套路时就容易发现一般软件产品不是功能 过少， 而是很难连续串起来支撑某一方面的完整的业务。 在售前演示准备过程中由于按照完 整企业内在业务逻辑准备， 就可以提前发现产品在规划方面的问题， 可以及时和不断改进我 们产品中一些不足。 对产品测试工作而言， 测试也可以按照售前演示套路准备实际业务测试大纲， 提高功能 测试外的业务测试覆盖率， 可以解决很多实施人员抱怨测试人员不了解实际业务， 测试工作 和实际业务脱节的问题，而且可以在标准演示套路基础上编制自动化测试脚本。 对于咨询顾问部而言，定制解决方案时候可以按照标准演示套路支持的业务模式来准 备，这样售前方案和售后实施可以极大保持思路一致性，不至于售前一套说法，售后一套说 法，用户感觉上当受骗。 对培训工作而言， 企业所有培训也应围绕标准演示套路， 商务人员要能自如按照标准套 路操作和演示，实施人员要能结合业务调研完成标准套路配置、实施和培训，测试人员要能 理解演示套路中体现企业业务逻辑， 发现软件不友好的地方， 规划人员可以通过演示套路判 断产品对企业业务模型支持是否足够，应如何改进。这样培训平台就是全公司统一的。 这样的话一个公司从高管到基层员工， 从外部业务部门到内部业务部门， 从销售前期到 实施后期， 通过这个售前演示标准套路准备活动达成了高度统一， 大家的经验和知识就有了 一个共同的积累平台，企业对用户就真正具备了广泛的一致性。 有了这样的平台企业才可以真正积累公司层面的知识管理， 避免大量的发散性行为。 很 多公司并没有认识到一个可培训可操作的演示平台比大量繁复的文档更有利于工作， 更有利 于培训，更有利于产品进步，更有利于公司知识积累。 很多公司的策略是做产品， 既然是产品就应该可以形成相对固定的套路去服务不同类型 的客户，也就意味着公司可以形成相对固化的套路，这个对公司形成统一的认识非常重要， 公司往往不是缺想法， 而是这些想法不系统， 不深入， 更多的是灵光一现， 不能积累和继承。 个人以为标准售前演示套路准备意义重大， 需要一步步通过演示工作去强化公司层面的 工作导向，将其意义最大化，效益最大化，工作协同价值最大化，积累成本最小化，专人专 岗长期制度化负责。 4.8 如何准备标准演示套路,(下) 4.8.1 如何准备标准演示, 准备标准化演示并不难，不同公司产品不一样，演示套路和侧重也不会一样，但都可考 虑按照以下思路进行。 第一要成立专人负责的岗位和相应制度， 否则能准备一次不错的演示， 但总不能随着产 品发展和实施业务创新而不断更新演示套路。一般这个工作可以让咨询顾问兼任。 第二要清楚演示给谁看， 不同人员关心重点不太一样， 因此建立可以准备侧重政府领导， 专家教授，企业高管，技术人员四个层面的演示体系。 第三要让公司能力最强的人参与到标准演示套路中来， 直接准备演示套路的人应该是对 企业业务了解，配置水平最高的人，这样才能最快有效把公司知识积累到标准演示套路中， 并 定期请规划、开发、实施、测试、销售、咨询各方面精英人员参加内部组织的演示套路评 估，提出基于各类业务的改进要求，不断完善和改进产品功能和演示套路。 第四要形成和标准演示套路配套的标准演示方案和常见问题解答指南， 演示方案要口语 化，强调可操作性，类似于表演时的剧本。 第五要让演示准备工作和规划、开发、实施、测试、销售、咨询各个部门培训工作主动 衔接起来，定期根据标准演示套路进行不同侧重点的部门培训，快速把能力扩散出去。 第六要让咨询顾问和实施顾问根据标准套路准备标准解决方案和实施方案，形成一致 性。 个人以为完成以上六个方面的工作才是一个完整有质量可结束的标准演示工作。 4.8.2 不断结合实际情况总结演示套路 实际进行演示的时候演示者临场自由发挥成分还比较多，演示完全不发挥不可能。 首先应要求演示者能按照标准演示套路照本宣科进行，这样可以保证最基本演示质量， 然后在大量实际练习中把产品功能和企业业务能够融会贯通， 最后才能够在现场高度自由发 挥。这三个阶段不能逾越，否则现场一人一个样，总结标准套路的工作就会失去意义。 既然有发挥就有好也有不好， 所以公司还必须总结每次实际项目， 特别是售前演示效果， 无论成败总结得失，并将意见反馈到演示准备部门，持续完善，持续改进，每天都能进步 1%的对手才是最可怕的对手。 一般反馈意见可以从以下几个方面改进和考虑: 如果是功能上对手具有我们没有的特色，应反馈给产品规划部门跟踪业务规划改进; 如果是操作过程演示层次不清晰， 不连贯， 应考虑如何结合业务形成更有效演示方式和 表达语言; 如果是产品性能不足，导致演示时拖泥带水，应反馈给测试部门作为缺陷加以改进; 如果是人员表达不到位，导致产品特色没有清楚讲解出来，应考虑逐步加强培训，加 快知识扩散周期。 4.9 如何进行现场演示(一) 4.9.1 建立演示心态: 作为一个演示者，要有一个平和，自信，积极的心态。相信自己可以取得成功和得到用 户的认可。 好的演示心态天线在自我定位，重视和敢于挑战对手，临场发挥三个方面。 好的演示心态下演示者是不会心浮气躁，上来就攻击对手，指望一棍子打死别人，搞定 客户; 好的演示心态下演示者不会看到强手就害怕发虚， 看见对手实力不强就轻视， 是遇弱我 强，遇强更强，勇于面对压力和挑战，正常甚至超常发挥; 好的演示心态下演示者在演示过程中不会遇到一点挫折就心灰意冷， 会做好多次反复交 流的准备，这个多次反复交流就是客户对你还有兴趣的一种表现; 好的演示心态下演示者对自己精心准备的套路和功能也不会过于自信， 用一种平和的语 调和对事业执作的激情感染用户，打动用户，让客户相信我们是一帮想做事，肯做事，会做 事的人，演示时无论得分失分都不要高调，肚子没有货的人才喜欢炫耀; 好的演示心态下演示者在演示过程遇到设备和软件操作意外一定不会紧张， 紧张就让别 人看笑话。即使是出现很严重地低级软件错误，也会不慌不忙重新开始，不需要做太多没有 必要的解释，一定要解释也应该是幽默的方式。用自己的从容镇定感染用户，建立用户对自 己的信任，对公司的信心。 根据个人经验一个好的心态演示者往往是哪些对自己的公司， 对自己的团队， 对自己的 产品，对自己的能力有充分自信的人才能上阵，不要用那种对公司没有认同，对产品表示怀 疑的人去演示，他们在演示过程中抗击干扰和打击的能力往往不好。 很多人在第一次演示或者头几次演示时很难克服一种恐惧心理， 这种心理诱因很多， 但 往往是越害怕越想，越想越害怕，还没有开始讲，自己就先崩溃了。 对于恐惧心理最有效的方法就是转移注意力和积极的心理暗示。 把注意力集中在演示内 容本身上， 而不是别人对于你演示质量的评价上， 并不断提醒自己一定可以做到比对手更好。 这里有一些标准放松方法可以提供给大家使用: 对着镜子试讲，想象你面前是你的听众。 可能的话，在实际演讲会场进行试讲。 确保你一直可以清楚地看到你的笔记或小字条， 让自己觉得就算是忘词也可以看到下一 步该讲什么。 深呼吸，并保持微笑。 4.9.2 准备演示环境和检查设备 准备环境事先可考虑以下要点: 后勤方面:谁在组织者这次演讲,(了解详细情况) 交通如何安排,(计划并检查旅行安排) 会 场:会场大小和形状如何,(向组织者索取一份楼面布置图) 可用那些设备,(弄清你要用什么设备，避免用不熟悉的设备) 时 间 表:谁在你之前发言,(弄清你是否有机会听他们发言) 谁将把你介绍给听众,(一定要事先向介绍人做简要介绍) 实地检查:在演示前最好能够提前到演示场地检查，并提前调试设备。 场地和设备检查一般要注意这么几个环节，演示场地大小，座位分布，光线明亮度，由 此确定自己演示时应站的方位和投影的方位。 如果有扩音系统要提前测试一下，确定自己发音大小。 测试投影系统和网络连线是否正常，电源开关是否可用，线路长度是否足够，如果有问 题应提前解决。 如果现场有自己不熟悉的设备，尽量不要在演示时使用，或者提前请人调整好。 演讲位置光线是否充足，能方便为其它人所看到，没有视线阻挡物。必要时要调整座位 分布以有利于演示进行。 如果是有重要领导和专家检查的大型汇报演示还要注意这么几个环节: 给领导和专家设置贵宾座和领座牌; 在演示场地内外布置欢迎牌和标语; 在演讲桌上布置鲜花等修饰品，体现专业和隆重程度; 在主要就坐位提前放置饮料和相关资料，并且注意资料饮料排放前后左右一字对齐。 4.10 如何进行现场演示(二) 4.10.1 演示时要注意的一些细节 4.10.1.1 如何注意演示姿势 演示站位也有技巧，一定要正面面对大家，尽量看到最多的人。 如果围着一个圆桌，你应该靠在最前面，你能看到所有人，但是你应该站在主要人物的 对面。 听众的数量对你组织演讲的方法有很大影响。 听众人数少， 你和听众就有充分机会进行 交流。你可以边演讲边回答听众提问，也可以就有关问题征求听众的意见。听众人数多，你 与听众的沟通只可能以单向交流为主，发言方式就应完全不同。 有时候演示只来了二三个人，不一定要大张齐鼓的讲，可以考虑一下，是不是大家坐在 一个距离比较近的方式去沟通会更好一些。 人比较多的时候站起着讲， 人比较少的时候坐着讲， 站起来讲的比较容易观察每个人的 反应。 如果是选择站立姿势身体站直，两脚稍稍分开，体重均匀地分布在两脚上，手臂在身体 两侧自然下垂。 这是最无明确表态的姿势， 是中性的身体语言。 如果你了解不同姿势的含义， 你就可以在此基础上创造不同的印象。例如，身体稍微前倾，显得积极友好——好像你在邀 请、鼓励听众。反之，身体稍作后倾，就显得消极，还可能有点挑衅意味。 演示过程中可以恰当使用手势， 一般人使用手势最大问题是有一些不好习惯性动作会出 现，解决这种不良动作最有效方法是看演示过程录象。 4.10.1.2 要不要派发名片 演示前可以不派名片，要派就全部要派。 而且派发时由领导沿一定顺序分发， 不应跳过某人再分发， 也不应先发普通人再发领导。 领导没有入场之前可以先给其它人发，领导入场后根据情况决定是否分发名片。 4.10.1.3 演示前等待时间怎么办, 演示前等待时间是很尴尬的时间， 所以一般演示者可以请其它人去检查设备， 自己找一 个安静地方考虑思路，等到时间差不多时再入场，避免这段真空时间。 如果用户没有及时到场，主要演示者要体现一定专家身份，可以安静等待，人数不多时 可以适当交流。这个时候商务人员可以适当活跃气氛，让大家不觉得等待时间过于尴尬。 4.10.1.4 演示着装 演示衣服最好是正式的，特别是正式演示，而且所有人着装应该统一，最好是西装。 西装最好是一个颜色，灰色或者蓝色，这是标准职业装。 4.10.1.5 关闭手机 演示期间一定要保证无手机铃声， 最好的方法是直接关机。 所以应提前告诉你的同事你 的工作时间，防止干扰。 如果确实有紧急事情不能关机，请其它同事演示时间内代管。 4.10.2 演讲开始时紧张什么办, 即使是很有经验的演讲者， 每次开始演讲的时候都有一些紧张， 而且在演讲的时候必要 的紧张是需要的。必要的紧张会使人注意力高度集中，大脑 在快速紧张地思考，从而可以更 好的把演讲思路搜索出来，并根据用户反应进行内容和言语上的调整。 但是有的演讲者一紧张就忘词，结果开始时就有一些不流畅，结果越来越紧张。这种情 况就需要大量的进行演示练习和试讲。 练习和试讲可以消除演讲者由于对内容不熟悉造成的 紧张， 而且大量的试讲会累积一个人的发表欲望， 经过多次准备的人会逐步对自己演讲建立 一些信心，并有发言的欲望，整个过程就容易有激情，不那么畏惧。 很多时候紧张就是因为对自己讲演的内容不熟悉， 没有信心， 导致担心自己发挥不正常 影响整个计划，越怕鬼越闹鬼。 此外演讲开头人总是有些紧张的， 这个时候演讲者可以多注意观察会场， 通过目光交流 发现有兴趣的用户，看到用户有兴趣了，自己就逐步有一些信心，慢慢就不紧张了。 此外设计一个轻快有趣的开场白也是一个有效的手段， 如果在一开始用户对你的开场白 就有了兴趣或者发出了笑声， 这个时候演讲者一般都可以松弛下来， 进入一种良性的演讲状 态。 最后注意语速，用中等偏慢的语速介绍内容，也是逐步释放紧张的一种方式。很多人一 紧张，讲话就会无意识加快，一快听众就更不容易明白，不明白就没有兴趣，这种表现会反 馈到演讲者身上，进而形成演讲者的焦虑，焦虑的演讲者这个时候往往不自觉越讲越快，这 个过程陷入高度紧张恶性循环不能自拔。 4.11 如何进行现场演示(三) 4.11.1 演示过程中听众感觉厌烦或注意力不集中怎么办, 很多时候即使你做了精心准备， 到了实际上阵却发现好象感兴趣的听众并不多， 这个时 候演示者往往比较受打击，有的人就比较紧张，觉得用户对自己的内容不感兴趣，脑袋一紧 张就不灵光，能把事先准备的内容讲完就一头大汗。 一旦发现用户对内容不感兴趣， 演讲者要紧急判断是自己准备的内容对用户的针对性不 够还是演讲时间安排在一个比较容易疲惫的时间段， 如果是前者演讲者要立即改变演讲的话 题， 逐步将内容往用户感兴趣的方向上引， 如果是后者演讲者就要发挥语言技巧， 增加互动， 提供一些幽默的段子调动大家的兴趣。 本人曾经参加了一次国产软件鉴定会， 来的都是企业的领导和信息化负责人， 整个上午 领导和专家用学术性语言做了冗长的汇报，上午的会议一直 12 点半才开始吃饭，到了下午 1 点半就要开始我们的产品介绍会，这时来参加会议的人几乎全部都昏昏欲睡，我们前一个 介绍人员又座在椅子上讲了半个小时的理念，一看大家几乎都要睡了，也很机警，请我上来 讲。 我上来以后并没有就坐，而是站在离大家比较近的地方开始，第一句话就是说: “各位 上午开了一上午的会，肯定很疲劳了，我呢想结合我们实施工作讲一些比较实际的东西，谈 谈我实施工作中一些小故事”。 这里我就使用了两个技巧，第一是站立，当你近距离站立在别人面前的时候，由于别人 是坐着， 出于礼貌就不得不抬头看你， 一抬头精神就不一样了， 一勾头就肯定继续睡下去了; 第二一直在听各种理念，肯定很厌烦，我主动说将一些实际的故事，大家就有了一些兴趣， 有了兴趣，自然就容易进入听演讲的状态。 在后面的演讲中我就放弃了用技术语言介绍的原计划， 全部用一个又一个实施过程中的 酸甜苦辣的小故事和用户交流， 在用户一阵阵笑声中交流就取得很好的效果， 到了演讲结束， 用户纷纷主动索要我们的名片。 要避免出现用户厌烦的局面， 第一在演示准备前弄清楚对象， 确保你所讲的内容切题且 适合他们特点，不然就砍掉。 第二演讲者整个演讲过程要有激情， 很多时候用户并没有记住太多内容， 但记住了那个 演讲很不错的人， 和那个人所代表的公司。 这个时候听众记住的可能只是那个演讲者的精神 面貌状态而已。 你积极的态度、活力和热情将增强你演讲的说服力。演讲的具体内容或许会被忘记，然 而你的态度、活力和激情将深深地印在听众的脑海中。 第三演讲过程中语言要抑扬顿挫，千万别只有一个语调，并和听众保持目光接触，目光 接触要注意随时看到整个会场所有人员， 并保持微笑， 让他们感觉到你很重视他的表情反馈。 很多操作性演示者为了确保自己操作不失误， 往往花费大量时间看电脑进行操作， 这是不对 的，整个演讲过程中听众注意的中心只能是演讲者本人，不是软件操作，只有当演讲者觉得 用户需要看操作的时候才主动引导用户注意观看 软件操作。 特别是在一些需要大量时间操作 的环节，如果将注意力集中在操作上，会让用户产生软件很慢的感觉，其实在实际操作中速 度并不慢，但由于在这个特定的场合用户往往会形成这样一种心理印象。 第四演示过程中演示者不要经常无意识挪动鼠标，来回拖动界面，分散用户注意力。界 面不应反复切换， 应该一个界面一个界面把软件思路和业务流程配合关系讲透， 再切换下一 个界面或 PPT。 第五控制一次演示的时间。 成年人集中注意力的时间限度约为 45 分钟。 在这段时间内， 他们只能吸收演讲内容中的三分之一，最多七个概念。将演讲要点限制于三到四个，并在演 讲开始与演讲中加以强调，最后再加以重复。尽量用一个有吸引力的标题来概括你的演讲， 但不要太概括或太含糊。 4.11.2 演示过程气氛不积极怎么办, 演示者发现听众精神状态不够好的时候， 首先要把自己精神状态调整过来， 不要受影响。 我们许多人是很容易受打击的，很容易受环境的影响。一定把这个势气调动起来。演示者有 了精神状态就有激情，有了激情就会感染别人，哪怕你讲的不好，别人也认为这是个想做事 的人，他对你的演讲也会一定程度上认可。 此外为什么演示效果不好呢,让大家跟我互动的时候， 演示者经常会问一些问题， 很多 问题并不需要听众回答，而是让听众进入思考，让听众跟着演示者思路去思考: “我们企业 里有没有这个问题呢,这个事有没有解决呢,” 然后演示者再告诉听众怎么做，所以演示者不要光谈功能，谈概念，而是先谈企业的常 见问题是什么，原因是什么，如果解决了好处是什么，然后告诉听众怎么做，这时听众就会 有兴趣。要不断地问问题调动他，然后不断的讲好处，你的业务线自然就串起来了，因为你 是为了一个好处，解决一个问题，又带一个问题，又解决了。这就叫完整的解决方案。 在成功的演示里， 好处太多就没有重点， 一般只需要归纳出三个好处即可， 多了记不住。 演示时， 应该让观众有一种参与感， 就象讲相声一个吹、 一个捧一样。 不要一个人唱戏。 应该适当地在演示时向观众提一些问题，比如企业的产品、任务情况，对软件的了解情 况，是否使用过相关软件等。 也可以顺便拉几句家常，使气氛活跃起来。讲某些概念，比如对象、配置、参数化，要 把概念讲通俗一些，使观众能够听懂。 4.12 如何进行现场演示(四) 4.12.1 投影仪连不上什么办 在做演示之前， 一定要检查好硬件设施。 但即使这样也会出现无法提前检查或者意外发 现演示厅里的投影仪接不到笔记本上的情况。 此时关键是不能着急和冷场。 在演示时应准备一些公司的简介和客户关心信息， 并进行 口头介绍，将时间拖到投影仪接好。 然后在随后正式介绍中弱化这一部分的介绍，将耽误的时间赶回来。 本人就曾经遇到这么一次情况， 投影仪突然罢工， 结果就按照业务思路不慌不忙一口气 在没有电脑情况下做了一个小时交流， 客户听得很深入， 一个小时后投影仪修复， 再看软件， 客户理解得很快，对我们产品很认可。 4.12.2 演示中客户的主要负责人总接电话怎么办, 领导接电话，一定要等，人少时直接停下来表示尊重，或者继续用比较慢的速度讲，然 后等领导停下来说“某总，刚才我给大家介绍了一下什么内容，”快速补过，给足面子又不 冷场。 4.12.3 多个公司连续演示，你排在后面，此时客户已经开始听觉疲劳怎么办, 演讲很多时候不是你最先讲， 那么别人讲得好的内容要能立即化入你的过程中， 巧妙利 用别人烘托自己，也无形中让客户将别人亮点记到你的头上。 别人讲得大家昏昏欲睡时，可以先准备一个笑话和有趣的 PPT 给大家刺激一下，用一 个轻松的心态进入交流的氛围。 有一个有趣的开场白是很不错的选择， 不过如果讲一个大家都知道的笑话或者和演讲内 容没有关系的笑话却不是一个好的主意。 4.12.4 演讲过程准备好的配置突然死机或者不能出来怎么办, 第一不要紧张，继续进行你的陈述，就当操作是正常的。 第二马上同时手工调整，如果正常，可以继续说刚才我介绍的“***功能，现在大家可 以看一下” 第三如果实在问题严重，无法快速解决，解释一下 原因，例如机器中毒了，很多突发问 题。所以计算机安全很重要。 第四自我解嘲，进入下一个功能介绍，还是不当回事。你越紧张用户越怀疑。 打动用户更多的是你陈述， 而不是一时半会无法领会的界面和操作， 有点问题你不在乎， 用户也就不会认为是大问题，至少你的镇静可以为你捞回印象分 第五强调一下笔记本机器配置不好， 或者装了太多系统， 我经常拿着 3 年前本子做演示， 速度慢一点用户反而理解。 4.12.5 演示时有人打叉怎么办, 当你在演示时，频频有人打叉，问出各种各样的问题，有可能是某人非常迫切希望你跳 跃性介绍他关心的内容。 也有可能是提出对演示者非常不利的问题，甚至是攻击的问题。 因此在演示软件时， 要注意重点突出， 不重要的例子可以根据观众的要求适当调整或者 不演示。不管何种情况，您可以这样回答“请允许我花 20 分钟先介绍一下软件的基本功能， 再回答您关心的问题”来保持正常的演示顺序。 对于观众提出的问题，可以表示赞许“您这个问题提得很好，我们开目软件已经考虑到 了”，“您的建议非常好，我会向公司领导汇报，考虑您的建议”，“您可能有些小小的误 会，其实这个功能是有的”。 对于确实是刁难性的问题，可以说“关于这方面的问题，我们可以在演示完以后再详细 讨论”，“这方面的情况我不太清楚”，“这方面您是专家”，“软件的优势不是绝对的， 有些软件确实在某些功能上比我们方便一点，但在与***有关的主要功能上，我们是非常方 便的”等，再约私下进行讨论。 对于一些刁难的人，大多数情况他是想表现一下自己，多奉承一下，让他获得心理上的 满足即可，没有必要与之争论太多。当然，对于少数确实是故意为难的人，也可以明确作出 回答，争取大多数人的支持。对于关键的决策人，要始终保持温和的态度。 4.12.6 演示时用户临时表示时间不够怎么办, 演示时用户临时表示时间不够怎么办, “我没有时间，你不用演示了，我们这儿对软件熟悉的人很多，只要留套软件，留份资 料，我们看一看就行了” 可以回答“我的演示很快， 不会占用您太多的时间”， “我们这个软件与其他软件相比， 有很多优点，值得您花一些时间看一下”，“我可以简单地把功能和特点演示一下，相信您 会大开眼界的”。 不过，给领导留一份详细的资料的十分必要的。 4.13 如何进行现场演示(五) 4.13.1 演示过程用户要求改变主题怎么办, 演示者在演示的时候一定要有激情，有好的状态，但是千万别太自信，要能应变。 万一听众听着听着说:“这些东西我不想听，你直接讲是什么东西”，突然来这么一下 怎么办,可能听众里就有对手的钉子，故意难看你一下。 这种事情无法避免，只能预防，首先在排练的时候，自己人要给自己人发难，在内部排 练时尽量模拟真实极端情况。应变也是练出来，多经过几次实际演示也会积累很多经验。 真正有经验的演示者，在一个演示方案中可以从几个地方作为开始，多设计几条路，万 一客户不愿意听还可以从其关心的点切入， 等其接受了还是逐步展开我们完整的解决方案思 路。 4.13.2 演示过程如何答辩, 一般软件产品演示完成后用户会主动安排， 或者临时提出一些问题， 这个时候就比较考 验演示者的快速反应能力，也能体现一个公司的综合实力。 特别是在一些竞争性项目上部分听众会带有挑衅的口气向你提出责问， 这个时候如何有 效应对，从容自如完成答辩也是非常重要的演示得分环节。 本人的经验在演示过程中遇到疑问甚至是刁难都是正常的， 不要畏惧， 把这个工作当作 演示工作中的一种常态。 用户问得问题越多，是对你的产品有兴趣的一种表现，大家应该高兴的去解答问题，而 且这个解答过程中无论用户处于什么心态，我们要保持微笑和认真聆听的态度。 针对答辩有几个重要的技巧: 第一对于一些比较复杂的问题，或者一个用户提出了多个问题，首先不要急于解答，要 先用笔快速记下来，边记边寻求最合理的解释，也可以防止遗漏用户的问题，以免用户发现 你遗漏后再提一次，感觉你在回避问题，我们毕竟不是外交场合，是技术交流，技术问题不 应回避。 第二在回答问题前，可以把一些复杂问题或多个问题复述一遍，即请用户确认，又为自 己争取思考的时间，但对于有些很简单或者明确的问题，要立即肯定积 极自信的回答，例如 用户在演示时没有注意到他关心的一个内容， 这个功能有的确是软件常规功能， 我们可能就 没有重点介绍，这个时候要立即和肯定告诉他，这方面我们没有问题，不能犹豫磨蹭。 第三回答问题反应要快，针对问题本身不做发挥，言简意赅。一般答辩时间不会很长， 时间宝贵，不要对于某一个问题长篇大论，用结构化思路或回答套路，快速扼要让用户听到 答复， 并礼貌性问一问不知道这样回复您觉得满不满意之类结束。 如果对一个问题解释过多， 可能也不是一下子能解释清楚的，反而会越解释越怀疑，越觉得累。 第四有些用户问的问题可能带有恶意，或者的确是软件的软肋，此时不应回避，要迎着 问题解答， 可以通过介绍我们正在开发的产品或正在规划的思路来肯定性回答， 越是自己不 强的内容，越是要在演示时讲透我们的业务思路，反而用户会少在答辩时提问题，越是在演 示时回避越容易被提出来并刁难。 而且这个时候我们可以用: “你这个问题很好;你说出了很多用户关心的问题;你这个 问题的确很有难度，看来您对***很有了解,”之类开头缓和气氛，拉进距离，增加思考的 时间。 第五如果企业内部有我们的支持者， 不仿先设计一些有利于我们的问题让他们提问我们 和竞争对手，这样也是一个有力的武器。 最后对于一些纯技术性问题可以要求用户会后进一步单独交流， 避免出现不得不花费大 量时间解释一些大部分人不感兴趣的问题。 如果有条件，是多人参加演示的话，可以就个人专长对问题回答提前做一分工，准备一 些可能要回答问题清单并提前设计回复， 这样在演示现场时也可以互相配合， 快速有序完成 任务。 答辩考核的是一个公司和个人的综合能力， 所以真正答辩的精髓不在现场快速反应， 而 在平时对企业管理业务、产品规划、业务知识、实施理念多个环节的知识积累，答辩优秀的 人往往也是在知识面和深度上下工夫最多的人，这才是成功答辩的秘诀。 4.14 如何组织演示后工作 4.14.1 争取约见重要领导 演示结束后， 如果有机会演示团队一定要和参加演示主要领导， 甚至是没有参加的重要 领导。 不要放过这个有利的时机和重要领导沟通的机会， 建立印象分， 在演示过程中可能更多 用业务的思维讲产品技术能力，但和领导沟通的时候更多的用管理的思维讲产品技术能力， 这两种沟通往往不能在一次演示中兼顾到位，但可以主动创造机会在后续活动中实现。 当然和重要领导见面机会并非可以有软件供应商控制， 但和重要领导沟通的工作意识随 时保留，饭桌上就是很好的场合。 4.14.2 提供备忘，后续跟进 演示无论实际效果如何，一定要留专业的备忘录，一定要和用户约定后续工作计划，并 按照备忘的承诺推进后续工作。 所以重要项目现场演示过程中应安排专人记录， 将演示过程和过程中大家提出的问题和 回复逐一记录， 对于一些暂时无法清楚解释的问题约定后续解释工作安排。 这种专业备忘整 理能力是很能反映一个公司职业能力和职业水平的。 商务工作在演示达到目的的情况下， 就可以更加良性的运做， 包括马上根据这次情况和 对手反馈准备解决方案，公司考察，用户考察，选型方案，招投标方案和答标演示等等。 在没有达到目的的情况下，更要进行权衡，是否进一步加大投入，扭转局势，还是无力 回天，集中精力做其它项目。 4.14.3 总结演示得失，形成反馈文档 演示结束后，要针对演示实际效果形成反馈评估文档，针对演示者个人能力，针对标准 套路组织水平， 针对产品技术能力结合竞争对手和用户意见形成反馈意见， 这将形成有力的 产品规划动力和演示准备改进动力。 很多项目在一开始接触时就可以发现一些现有产品无法满足的部门， 如果在售前系统演 示后用户还坚持要实现的功能， 如果此时提前给公司评估和规划， 在未来实施时就赢得了时 间的主动权。 永远要比对手多走一步，才能赢得最终的胜利。 4.14.4 一流演示的效益 每次好的演示都可以培养出一个能战斗的领队型， 策划型人才， 每次都能让客户经理认 识到公司强大实力和产品能力，对自己未来工作充满信心。 每次通过售前充分的演示准备和排练可以培养团队作战的感觉，建立一个强有力的集 体，这样的项 目售前演示最容易凝聚人心，建立信心。 演示工作最失败的不是一个项目得失，而是内部成员对公司和产品信心丧失。 4.14.5 失败演示的特征 没有演示策划 没有进行需求调研，演示时无法用客户能理解语言沟通 过早的进行了演示 没有认真评估演示产品线或模块 演示没有套路 演示没有就用户可能的提问做准备 没有后续工作跟进 4.14.6 一流演示人员应有哪些素质 实际项目实施经验 良好的口头和书面表达能力 表现欲 丰富的知识面 快速业务调研能力 快速学习能力 快速反应能力 4.15 演示方案准备经常考虑的问题 4.15.1 听众分析会有多少人来听演示讲, 听众的平均年龄是多少, 听众的男女比例怎样, 听众了解你的主题吗, 听众是自愿来的还是别人要求他们来的, 听众有何共同点, 听众有何先入之见, 听众有何文化特点, 所有的听众或某一些听众是否认识你, 评估听众的可能对问题反应情况。 4.15.2 根据听众人数，调整演讲方法 根据听众人数， 4.15.3 演讲的结构类型与材料相适应 4.15.4 使用叙述法 叙述的基本技巧在于使发言有一个明确的开始、 中间部分和结束。 这种技巧最常用于讲 故事。你要成功地演示，遵循这一基本格式来组织演示是很重要的，演示的引言就是开始部 分，中间部分就是演示的中心主题和观点(用你认为最适合的结构类型提出)，而结束部分则 由你的结束语构成。在结束部分重提核心主题，如有必要，再回答听众的提问。记住:重要 的是在演示各阶段的开始时和结束时，向听众提供明确的有关线索。 4.15.5 编制简化提纲 准备一份书面的演示提纲是很有帮助的。 在书写提纲的过程中， 组织演示的方式会逐步 明朗起来。在演讲过程中，带可用提纲来提醒自己。将你的三四个要点标上“一”、“二”、“三” 和“四”，然后在它们下面分别写上二级标题(1、2、3)。如有三级标题，就用 A、B、C 标出; 如此等等。提纲要写得简单，使之一目了然。 4.15.6 设计开场白 要想在演示一开始就给听众留下好印象，最好的办法是你显得坚定而自信。 有经验的演示者总是每次设计开头的两句话， 这样就可以把注