推荐一本写给IT项目经理的好书

这个世界上写给项目经理的书很多，写给IT项目经理的书也不少，但写给从事管理软件实施的项目管理书籍并不多。
　　 而笔者在从事项目经理工作中感到一个很苦恼的问题是，很多书其实非常经典，但都有一个缺点：理论正确，实战指导作用不足。
　　 不是亲身亲历的人是很难领悟到那些理论的精髓，而每个刚刚入行又立志成为一个IT实施的新人往往不是一开始就能从理论上武装自己，在他们起步的时候，每天要面临着各种具体工作任务，例如做调研，写计划，写方案，写备忘录，做项目汇报，做演示，这些活动与其说是项目管理发挥作用大，不如说这是具体业务技能的领域。

一个IT人如果没有经受专业的培训，在不能掌握这些技能之前，我个人体会是往往是努力的把事情做砸。
　　 目前的IT服务质量更大程度上取决于实施人员个人能力，也许只有有一大批同等质量服务的实施人员涌现，一个公司的才有可能顺利推进项目管理的思路。
　　 因此笔者就有一个想法，想把自己在项目实施从售前到售后的体会和经验总结为一些专项技能，并希望它具有可操作性，和大家一起交流总结，不断积累并臻于完善。
　　 也希望各位朋友看后多评论，多留言，多给笔者提出改进意见，本人将结合大家意见不断完善，将大家的想法变成业内智慧的结晶，让更多的人能在IT实施工作中做到游刃有余

 

目   录

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 什么是演示？

入行五年，售前售后演示最少也有两百次，也算有一点经验了，今天把我个人做做产品演示的体会做一总结，希望对所有想做好演示的人员提供一点帮助和指导。

　　产品演示不是演讲，也不是答辩，更不是培训。

　　尽管在很多表达和现场互动技巧上，演讲，答辩，培训和演示都有相通的地方。

　　演讲更侧重对某一个问题看法的陈述，主要是交换观点，允许争鸣，听众可以不同意你的观点，但一定会捍卫你发言的权利。

　　除了常见的演讲比赛外，很多时候演讲者是受邀请，以一种被尊重状态出场，是处于一种比较从容的心态下开始的。

　　演讲的过程一般也是比较连续，不会被随意打断的。

　　答辩更侧重对话双方的交互，具有很强的考核目的，通过对答辩问题的反应答辩主持方来主动判断他想获取的信息。

　　答辩的过程一般是不连续的，随时都可以中断响应不同的问题，答辩的节奏和压力也更为紧张，时间非常紧凑。

　　培训更侧重于传授操作，此时被培训者已经认可培训者所在公司和产品，在过程中更多的是教学相长，形式可以多种多样，根据不同培训层次灵活组织。

　　演示不然，演示是有极强的目的性。演示往往是要在有限的时间内(比答辩要舒展)，面对一群不同心态或者不明心态的人快速把自己所在公司、公司产品和服务，包括自己最大范围内推销出去。演示过程中还要随时准备开始各种技术答辩，应付各种***难。

　　演示是主动影响客户(用户)的过程，售前演示也是主动和竞争对手竞争的过程，演示更是个人魅力展现的过程。

　　整个演示就是一场复杂的脑力游戏，看看我们有什么办法在短短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 设计开场白

　　要想在演示一开始就给听众留下好印象，最好的办法是你显得坚定而自信。

　　有经验的演示者总是每次设计开头的两句话，这样就可以把注意力集中在如何打动听众上，而不必过于关注该说些什么。

　　一个成功的开场白会概略地说明你将作的演示，简要地告诉他们你将提出的观点。讲些趣闻轶事，以亲切友好的方式来活跃气氛，并吸引听众的注意力。但要牢牢记住：在演示刚开始时，听众的注意力并不最集中，因此要在演讲开始几分钟之后再提出你最有力的观点。

　　4.15.7 听众注意力的持续时间

　　以45分钟的演讲为例，听众在演示刚开始时注意力很集中，10分钟后达到顶峰，到30~35分钟，注意力消退。最后，当演示快结束时，注意力又增强。所以演示方案中要设计关键内容和听众注意力之间的对应关系。

　　4.15.8 设计过渡词

　　用清晰的线索来贯串演示是很重要的。安排好观点与主题思想的逻辑顺序，让听众轻松地跟上你的演示。当介绍新的内容时，要将前后观点紧密地联系起来。

　　因此不同演示点之间一定要设计易于接受的过渡词，帮助听众把思路联接起来。

4.15.9 运用重复

　　演示时作扼要的重述，是强调要点的有效方法。组织演示内容时，在每个要点的结束部分及在整个演示的结束部分安排一些重复。但是，简单地重复你前面讲过的话是不够的。要用不同的措词，使你的观点听起来既新鲜又熟悉。

　　4.15.10 难忘的结尾

　　一个好的结束的重要性不亚于一个好的开头。示意听众演示已近尾声，是十分重要的。用“我要讲的最后一点是……”或“总而言之……”等使听众注意到你就要总结你所说的话了。他们会很高兴有机会补听他们可能漏听的观点。

　　4.15.11 强调观点

　　强调演示的要点相当重要。强调要点的方法可以是：先向听众提供演示“目录”资料，然后讨论你所提出的问题，最后通过作总结来结束。

　　4.15.12 撰写口语化讲稿

　　要注意，把书面材料以口头方式告诉听众时，听起来会有很大不同。要学习以自然的口语方式写讲稿，这样，你的讲稿就符合平时的说话习惯，并适合作口头演示。

　　4.15.13 将演讲方案浓缩为提示卡

　　如果你想使用提示来演示，首先要写出完整的演示稿，包括所有要点和用来阐释、说明这些要点的例子。以这个稿子为起点，你可以将演讲内容浓缩为提示。将从稿子中选出的关键词或短语清楚地写在编过号的卡片的一面。一张卡片上不要写得太多，要保证住处的简洁和明确。

　　准备讲稿：确定了演示的结构，而且组织好了收集到的材料后，将发言完整地写出(或打印出)。编辑、修改这个稿子，直到读起来觉得通顺而有节奏时为止。

　　准备提示卡：从最后一稿中抽出要点，写到编过号的卡片上。为清晰起见，每张卡片上的提示应不超过两个。

　　可以用黑墨水写绝对必要的内容，而可以删除的内容则用其他颜色的墨水写。

　　4.15.14 注明演讲的节奏

　　想一想是什么因素促使演讲成功，那通常是时间的安排。演讲的无声部分即停顿在传达演讲内容的过程中与说出来的话同样重要，因为它们是听觉上的标点符号。在撰写讲稿时，要考虑听众听起来会感到怎样。不管你演讲时用提示卡还是完整的稿子，在你觉得必要的地方，例如在需要强调的观点旁边或在两个完整的观点之间，写上“停顿”两字。试讲时也要使用这些停顿。使用沉默需要有勇气：一个注明的停顿应持续三秒左右，这比平时说话时的停顿要长一些。

5 如何做用户考察？

5.1 前言

5.1   前言

　　入行五年，做了一些相对成功的项目，而且所做项目离公司总部比较接近，因此经常有机会接待客户提出的典型用户考察请求。其实每个业内成功的项目经理都有一些售前的经验，甚至在售后出色的人才会主动被抽调到售前，也许是有经历的人的话更能打动客户的心。今天把我个人做典型用户考察接待的体会做一总结，希望给大家提供一点帮助。

　　5.2 典型用户有什么意义？

　　一个项目在技术上决定成败有两个重要环节，一是产品演示，二是用户考察。两个环节都很重要，而且往往在很短一个时间段内完成(相对整个项目跟踪周期)，所以典型用户考察工作不能不认真对待，甚至要作为售前售后最关键的工作来对待。

　　现在很多用户非常怕被软件供应商忽悠，对考察工作尤为重视，甚至不通过供应商引见，自己去打电话暗访明查，有的担心我们提供电话是经过事先联系形成默契的，还主动多打电话问几个人，了解软件应用情况到底怎么样。

　　因为无相关行业用户应用示范，或者因为典型用户考察效果不好导致项目无法拿下的情况是非常常见的。

　　好的典型用户对售前项目有多大的辐射意义，并不需要去强调，做商务的人都明白这一点，但典型用户不仅对售前有意义，对实施规划都有更大的意义。

　　一般典型用户应用比较深入，往往累积了很多成功的经验，这些经验往往是比较成熟的套路，可以总结推广到其它相关类似用户身上，获得比较快的实施效益。应该说每个典型用户身后都对应一套完整可推广业务实现实施模型，值得很好总结。

　　典型用户应用比较深入，往往能提出更多更有价值的需求，这些需求对产品发展有很好促进作用，典型用户一般又愿意和我们长期合作，通过详细解剖典型用户需求和业务模式，可以缩短软件供应商了解行业业务的时间，形成有效产品规划指导产品发展。

　　典型用户还是一个公司营销开发团队是否有信心的关键，一般公司开发人员无法直接关心用户，但营销和实施不一样，如果一个公司到处都找不到典型用户的话，这个公司营销和实施工作开展也不会顺利，人员流动将非常频繁，大家对公司也没有足够的信心。如果一个公司拥有一批成功用户，所有员工基本上就会把精力更投入到业务中，因为大家会觉得既然别人能成功，我应该也有机会成功，而不是一致责怪公司这里不行，那里不到位，导致事情没法做。

5.3 典型用户应如何管理(上)(

和产品演示一样，典型用户管理也是一个系统工程，不是通过突击就可以实现的。要想管理好典型用户，就应该在公司层面有专人定岗定责进行管理，没有专人管理典型用户信息，业务一定会出问题。

　　典型用户管理应该经过三个层次：

　　5.3.1 典型用户确认

　　首先要将对公司市场工作最有利的典型用户筛选出来，这些用户其实在售前跟踪时就可以通过客户ABC分类加以明确，这样即使某些客户在第一次合作时项目金额并不大，也可以在在项目实施过程重点保障资源，重点投入。

　　一般选择典型用户名单考虑以下七个因素：

　　1) 应用效果，有三类用户可以做典型用户。第一是成功进行了大量应用的用户，最好的典型用户是实际业务每天都要大量人员利用系统进行工作的用户，而且在实施过程中有很好的参考作用的用户，这样有实际应用效果的用户最能让其它用户相信软件公司的能力；第二是一些应用面还不够大，但基础数据都基本录入，典型业务流都可以实现的用户，第三是非常有特色的用户也可以作为典型用户。当然实际应用效果是选择典型用户首要因素。

　　2) 商务关系，所谓典型用户，就是希望能够替公司提供宣传的用户，这些用户论高管还是中层干部或者基层操作人员应该认同软件公司产品，愿意推荐软件公司的产品，如果没有好的商务关系，用户甚至对软件公司还存在意见，即使应用情况不错，也要考虑是否适合做典型用户。典型用户的商务关系应该一直有专人负责跟踪和维护，仅仅靠客户经理和实施经理维护是不够可靠的。

　　3) 行业影响力，影响力越大越好，一般情况下行业影响力大的用户公司应在商务和实施时区别对待，重点投入，而不要简单受项目金额大小左右，否则可能造成服务资源不够，做臭一个，丢掉一片。

　　4) 业务应用丰富，以技术信息化软件而言，要考虑典型用户至少能覆盖有设计有工艺，无设计只有工艺两种研发模式，有设计无工艺的可以直接看有设计有工艺的类型。否则用户考察时会提出感觉没有看到自己想要的内容。有设计的用户应该覆盖到一种三维软件，一种二维软件。这样的考察效果才能达到全面完整，业务类型丰富，而不是一个用户实施比较成功，参观就一定有好的效果，要选择一个业务应用尽量丰富的企业。一般随生产模式(单件，多品种小批量，大批量)不同，业务应用丰富的企业也要选择几种类型才能适应不同生产类型用户考察需要。

　　5) 地域辐射力，典型用户地理位置应该交通方便，不然会增加客户交通成本，也增加公司接待成本，而且无法起到长期辐射作用。一个全国性公司一定要考虑在全国建立可参观考察的典型用户网络，仅仅只有几个典型用户参观考察对用户本身也是一种巨大的骚扰，而且对很多地域性用户，不方便出省考察的客户是很难做到有效辐射。

　　6) 服务资源，典型用户并非一定是所有问题都解决了的用户，往往是经常性需要服务的用户，因为应用深入，需求比较多，而且系统不能停，一停就容易出问题，但很多时候典型用户要协助软件公司做一些参观考察工作，这个时候往往需要提前解决一些软件应用问题，以便让典型用户在考察前有一个好的状态，这样典型用户如果完全没有服务资源往往会出问题。

　　7) 介绍资源，典型用户接待客户参观时效果一个重要因素是企业有无能交流，并把业务和信息化实施过程问题介绍清楚的人员，如果有一个这样业务能力比较突出，又全程参与项目实施过程的人员能介绍项目实际情况是最好不过。

　　典型用户确认未必一定要以现在是否可以立即参考考察做依据，而是应该综合以上因素以后确定名单，然后通过一系列工作努力让这些用户成为可以参观考察的用户。

5.3.2 典型用户分级，确定服务模式

　　典型用户名单确定后立即要根据典型用户可考察参观实际效果情况对典型用户分级。

　　第一类典型用户是可以随时安排参观考察的典型用户。

　　第二类典型用户是可公开宣传，但不方便或不愿意接待参观的典型用户。

　　第三类是可以在售前非公开资料和口头介绍的用户。

　　第四类是千万不能公开介绍和宣传的用户，一些典型应用不佳用户。

　　第一类用户应加强商务联系，签订宣传合作协议，保障定期走访服务，让典型用户和我们长期合作，心情舒畅；

　　第三类、第二类典型用户要根据情况确定是否可投入资源使其向第一类，第二类用户逐步转化，一个公司第一类典型用户多了，市场口碑就起来了，甚至服务价格就可以提高了。

　　一、二、三类用户都要明确详细的服务模式，并落实到具体实施部门或区域团队管理，并定期检查服务工作是否完成和质量，这样才能形成一个闭环的管理体系，不至于口头重视，实际上因为没有利益(国内目前大部分项目服务是无法收费的)保障而无资源投入。

　　第四类用户也很重要，有些用户在业内或当地知名度极高，但软件公司在这里遭遇了滑铁卢，所以公司一定要动态审查在方案、公司介绍、对外提供典型用户名单上尽量不要出现此类用户名单，避免被潜在客户咨询或提出参观要求时被动。

5.4 典型用户应如何管理(下)(

　5.4.1 宣传模式规划

　　典型用户的辐射效力体现在四个领域：

　　售前主动介绍(文字和口头介绍)

　　客户现场参观考察

　　媒介(新闻性媒介和专业期刊)

　　行业或政府主办经验交流会议

　　所以典型用户分级后，应根据这四个辐射效力领域分别设计相应的套路，针对不同典型用户提供组合管理方案。

　　首先要为典型用户提供在公司网站介绍材料，公司宣传手册，公司各种方案材料，公司售前PPT，公司内部培训材料保持一致的宣传介绍材料。

　　完整的典型用户宣传介绍材料应包括以下几个内容：

　　企业LOGO

　　企业厂区或典型产品照片

　　企业概述(有地位突出地位，无地位突出业务特色)

　　企业应用软件情况介绍

　　企业应用现场或鉴定现场照片

　　企业高管或项目负责人对项目一句简短而经典的评价

　　企业应用效益

　　项目获奖情况(是否获得国家省部市级信息化建设项目奖励，或者进入863主题计划)

　　其次典型用户现场参观考察工作需要组织的第二个方面，下文专门另文介绍。

　　第三典型用户媒介报道也非常重要，第一种是商业性媒介报道，主要是重要客户签单，取得阶段性验收，最终结项，通过重要机构鉴定和获奖应及时在公司网站，合作媒体上发布新闻材料，这类消息软件公司要有很强的主动宣传意识。

除了直接商业报道外，还有一种软媒介报道，就是和典型客户项目负责人合作就项目实施特色应用或者实施经验发表专业学术性文章在专业刊物上，扩大知名度同时也为很多企业项目负责人解决很多实际问题。

　　最后应用良好的典型用户经常有机会参加政府行业或者集团内部主办的经验交流会或者鉴定会，软件公司在申报项目的时候也经常需要请典型用户合作作为项目用户单位，并需要配合盖章，因此我们应建立典型用户的资料库，随时备双方做汇报材料准备用。

　　如果有，以下材料一般都应保留：

　　详细的企业情况介绍(企业概况、行业地位、产品系列、人员组成、联系方式)

　　企业信息化总体规划方案

　　企业项目招标书(选型评分表)

　　企业项目投标书或者项目售前解决方案

　　企业实施解决方案

　　企业对外项目实施经验总结或成果汇报材料(文字和PPT)

　　软件公司内部实施经验总结(突出业务特点和功能应用特色)

　　项目双方主要负责人员简历(应每年保持更新)

　　其它值得管理的资料

　　完成这三个层次的工作，典型用户管理应该说就是比较完整业务过程。

5.5 用户现场考察应如何组织？(

一般信息化项目用户都会提出现场考察典型用户的要求，那么如何组织用户现场考察工作呢？

　　典型用户考察组织有三个层面：

　　5.5.1 第一是公司层面

　　软件企业对于已明确可以现场考察的用户应要求建立考察模式，并由专人负责维护，一般就是项目实施团队负责设计项目现场考察行程地点，业务介绍套路，实施应用介绍套路和相关PPT，并和企业接待人员充分沟通，就交流必须向潜在客户讲到的亮点，保证前来参观用户可以看到项目实施过程中的功能特色或实施特色，不虚此行，也是对潜在客户的一种尊重。

　　公司还要提前和典型用户沟通，确认现场实施状态，评估项目可考察性，确定是否需要一些服务资源投入或者请典型用户进行专门准备。

　　公司还要注意和典型用户约定考察参观方式和考察频率，了解典型用户安排方式是现场参观，还是投影集中介绍，还是在某个业务地点集中介绍；典型用户一个月希望接待几批考察对象，本月是否有重要任务，不方便接待考察等情况。这些情况要提前通知到各地客户经理知情，方便对潜在用户进行介绍。

　　公司还要收集整理不同考察用户关注的针对性问题或者考察评分表，形成问题集和参考评分表备案，这些内容将可以成为公司规划产品发展，了解用户功能需求和实施要求的重要渠道，也是向其它潜在用户提供如何考察的素材资料，对于一些共性问题还可以形成公司级标准解决方案，有利于各个方面人员和客户沟通。

　　最后公司要协调项目实际负责实施人员，或者对项目情况比较熟悉，业务能力很强的顾问型人员在考察期间全程陪同，至少要保证现场有软件商的实施人员陪同。

　　这些工作一般有公司或者级别较高主管部门协调组织落实。

　　5.5.2 第二是客户经理层面

　　具体到某个项目考察，这是客户经理应该负责的工作。

　　首先客户经理接触到一个项目，应该要主动判断是否安排用户考察，用户考察是否和公司考察放在一起进行，还是在本地典型客户处安排考察，在什么时候进行为妥。

　　根据这个判断客户经理再根据企业业务特点和需求和公司提前沟通，确定可参观用户对象，请公司相关典型用户负责人员提供若干典型用户相关资料，以备用户查问。

一旦客户提出考察要求，要提前和典型用户或通过公司和典型用户预约时间。注意尽量避开用户负责人不在，公司陪同参观介绍人不在，企业休息日，或者拉闸限电(这个是近年中国特色)等情况，紧急响应，安排行程和场地，并把前来考察用户详细情况(人数，性别，级别，行程，关注点)形成文档提交公司。

　　客户经理还需要了解潜在客户关注的问题，很多用户会提前设计一系列针对性考察问题，这些问题要提前发送公司典型用户负责人准备，并通过公司或亲自和典型用户沟通，介绍前来企业情况，前来人数和时间，希望考察内容，可能要问的问题，以便让典型用户自我介绍时更清楚情况，能够达到较好的考察效果。

　　考察过程原则上客户经理应全程陪同，客户经理在陪同过程中要做三件事情：

　　1、随时和公司内部沟通，通报情况和提醒注意

　　一般前来考察的客户需要通过客户经理介绍给相关人员，并单独和相关考察接待人员沟通，说明一些文字描述可能遗漏或者不容易写清楚的情况。整个考察过程中要随时注意进行这类沟通，保持公司一致性。

　　2、亲自安排好客户的衣食住行

　　客户经理让客户感到亲切认同就是成功，这些都是通过接待细节中体现，所以客户经理要亲自做好这些工作，为今后商务工作奠定感情基础。

　　3、写备忘录

　　客户经理全程陪同最重要目的是随时了解客户在考察过程中交流思路，判断项目技术或商务侧重点应该是什么，便于进行下一阶段商务和技术公关策划，很多交流内容不是当事人是无法清楚表达和了解的。因此一定要利用这个机会充分了解用户想法，甚至趁热打打边鼓，促进客户下决心。

　　考察完成后客户经理要主动帮助用户准备一份考察备忘录。一般企业出来考察回去是要写汇报材料的，但大部分人出来考察因为行程紧张并没有立即组织材料，只是简单记录，这样一轮考察下来，再去组织准备工作量也不小，而且信息遗忘可能很大。其实很多人并不擅长写文档，如果这个时候有一份可参考的资料对这些用户该是多么方便的事情。

　　所以客户经理要主动在用户考察完成后写一份记录考察过程的备忘录，备忘录可以分这么几个内容，考察日程安排，考察用户情况介绍和应用情况介绍，考察过程交流关键内容及回复记录。这样的备忘录将非常有利于我们后续工作，有这样现成的素材在，难免用户会直接引用，一引用汇报给领导就给我们增加了成功概率，特别是当竞争对手都没有做这个工作，就体现了我们的用心。

　　认真做事只能把事做对，用心做事才能把事情做好，就是这个道理。

　　备忘录体现了我们对考察后工作的间接控制，保证考察印象能有效传递，但备忘录有一个原则，客观中立，可以回避弱点，但不能夸大粉饰。

5.6 用户现场考察应如何组织？(中) (连载四十)

5.6.1 第三是考察顾问层面

　　一般情况下客户考察应安排一个顾问型人员在考察期间全程陪同，因为用户在考察期间是最容易进入实际环境感受，容易看到别人实施过程，思索自己项目规划的时机，如果能得到高水平咨询顾问交流和指点的机会，会给软件公司增加很多印象分。实际上考察走马观花能看到什么？有的企业比较有经验，能深入了解一些情况，大部分企业考察看不出太深的内容，只能说在考察过程中谁能在短短几个小时内了解到客户的担心和疑惑，并合理通过考察行程展现出来

　　此外很多典型用户自己用得不错，但缺少系统的总结，介绍时没有层次，而且他们一般也不太清楚参考企业到底关注侧重点是什么，介绍时容易突出自己的特色，但没有考虑参观企业到底想看到什么，这个时候顾问就要巧妙利用自己丰富实施经验和判断力，以及和典型用户良好人际关系引导介绍交流思路，让参观用户看到东西，学到东西。

　　无论能否成功合作，潜在用户花费成本考察，我们就应该尽力让他们了解项目实施效益和风险，以后他们在信息化建设过程中可以少走一些弯路。

　　所以一个好的考察顾问往往是整个用户考察的真正灵魂，有没有一个这样的高水平顾问对整个考察效果质量是两个档次，明白这一点客户经理也应该清楚要让自己的考察达到效果，有没有这样的一个人是非常重要的，一定要尽量协调好时间，让考察顾问有充分时间陪同，如果公司没有这样的人员，考察过程就只能听天由命，让典型用户自己发挥。

　　但这样的考察最大的可能问题是，很多项目业务和潜在用户实际不一样，潜在用户总觉得和自己类型不相似，总是想看到一个和自己一样的企业而且成功实施，这样就比较放心。

　　且不论用户这样的认识是否正确，但的确一个软件供应商也很难让若干典型客户代表所有的企业业务情况。如果一个软件商有如此足够实力拥有全面可考察的典型用户自然最好，但实际上这是理想情况，而且很多用户行程安排又决定他们没有足够时间去考察其它类型用户，所以很多用户考察完后总有顾虑，觉得自己想看到内容没有看到，这个问题如果有经验丰富顾问弥补介绍是一个补救的办法。

　　当然作为公司尽量在各个地区培养不同类型的用户是非常重要的工作。

5.6.1.1 考察顾问应该注意的三个环节

　　考察顾问和客户在一起一般要完成三陪工作，第一是陪交流，第二是陪考察，第三是陪吃饭。

　　客户在去考察典型用户之前，一般会先安排和公司顾问做一个交流，那么这个时候顾问要充分介绍自己产品特点，回答用户关心的问题，了解用户关注问题，快速判断是否可以在要考察的典型用户里看到和说明，如果看得到自然最好，如果看不到，就要考虑相应说辞，从而能够很好地在考察时候让用户得到一个满意的回复。

　　这个时候顾问要低调亲切沟通，给客户建立一种专业沉稳的可信赖印象，在现场考察的时候才容易发挥出彩。

　　顾问和用户交流往往存在几个难题，第一是原来不认识，比较陌生，如何快速让客户进入状态；第二是顾问对企业往往也比较陌生，如何快速了解企业情况，进而合理提供建议。对于顾问应在用户来之前做一些案头工作，查看售前相关资料和上网了解企业产品是很好的办法。

　　能否快速让客户进入状态一是顾问应有一定商务知识，善于制造沟通气氛，最重要的是顾问能很快让用户觉得自己比较专业，进而有沟通的兴趣。

　　要做到这点一般顾问应该也是一个实施经验很丰富的人员，否则顾问只是名义上的顾问而已。

　　一个有丰富经验的顾问，在陪同考察和吃饭时才能有效说服用户，建立信任。而且一个有丰富经验的顾问，不仅仅是业务经验丰富，还应该有一些杂的知识面，例如在行车路上，顾问就是一个导游，讲环境，讲发展，讲文化，让用户可以先轻松一下，也建立一个好的气氛。

　　5.6.1.2 现场考察三原则

　　尽量让用户自己介绍，顾问只在关键时候点题，或者在局面不利时候出马，不要喧宾夺主；

　　介绍情况不可任意夸大，实事求是，不要怕客户看到不好的方面，应该真诚和客户户探讨如何才能实施好项目，取得用户的信任。甚至在客户来到现场之前多铺垫一些低调的话。

　　只介绍功能，不介绍实施。有的用户对技术非常感兴趣，对实施难度不够重视，这样的用户要在技术上让其放心后，合理感觉到实施方面的难度，进而认同找到一家好的供应商合作才能成功的道理。

5.7 用户现场考察应如何组织？(下)(连载四十一)

　5.7.1.1 现场考察介绍技巧

　　用户用得不好，看功能。不好就是不好，可以不主动谈，但可以通过功能介绍说明软件应有的能力。

　　用户用得好，看应用，看每天有多少人建立多少数据，事实比任何数据都有说服力。

　　介绍软件功能要用讲效益的方式去讲，用比较精练的话去引发用户的兴趣。

　　例如我介绍一个用户用KMCAPP编制工艺的好处用了一句话，在这个企业80%工艺数据不是手填的。很多用户就很感兴趣，这样我就有充分时间展开如何合理规划工艺数据，建库查表自动计算广播等等，通过实地演示让用户感受到信息化的好处。

　　讲实施过程要用讲故事的方式去讲，例如我介绍一个用户实施过程，用了四上四下，说同志搞革命三上三下，本人做这个项目四上四下，通过介绍四上四下说明项目一把手作用如何体现，项目团队应该有怎样品质人组成，一个项目成功最重要的要素是什么，这样用户在听故事的同时就不知不觉接受了你的理念。

　　讲故事还要追求轻松幽默。例如我和客户讲企业实施磨合痛苦的过程，就用了一个方轮的故事。

　　有一个用户给我讲，原来没有用电脑，好象每天走路上班，感觉也很好；后来上了电脑，就象骑自行车，每天轻松了许多；现在单位上了这个先进的ERP/PDM，高兴得不得了，因为开上汽车了，车型款式还特别漂亮，一看仪表系统就知道是进口货，各种驾驶信息一目了然，原来自行车是没法比，但一摸方向盘，一踩油门，就是无法启动，下车一看，天啊，咱们这车轮子是方的！

　　这样客户就很轻松在笑声中明白就跟两口子新婚一样，所谓实施，关键在磨合。所以搞信息化一定要做好长期磨合的心理准备，没有这个准备，离婚率一定会大大上升。

　　再如我讲实施上线的难度，就提了一个走不完的20米，说我们企业系统管理员，在项目上线最繁忙的时候，每天从办公室走到厕所这20米是无法走完的，每次还没有到厕所就被两边部门人员喊进去解决问题，只能等别人下班吃饭赶紧冲到厕所去解决问题，这样的故事在笑声中就把很多不好说也不容易说清楚的事情和意思表达出来了。

　　但是讲实施风险的话题要慎重，体现难度大的事情也可能打消用户实施积极性，要慎重讲，到了气氛再讲。

讲故事还要将一些具体实施思路和做法体现出来，让用户对我们经验和专业水平表示认可。有的用户对信息化软件基础数据录入不够重视，也不清楚如何推广软件，这个时候我就会讲一个三毛钱的故事。

　　我讲我们开始软件安装到位，大家都不愿意用，说是软件不能用，结果企业就下令3毛钱一条数据，结果就有人开始录，还真得到了钱。这个时候我往往开玩笑说我们当时开发人员要求去现场实施，协助录入数据，以我们水平一天录入1000条数据很容易，这可就是300元的收入了！

　　大家一看有钱拿，就纷纷录入数据，这个时候领导就把政策停了，大家刚想责问，领导说，原来各位说产品不能用，所以不能录入数据，现在发现你们都可以录入数据了，总不是各位给钱就配合信息化工作，不给钱就不配合信息化工作吧？

　　这样在大家都掌握基本操作后进行一次考试，考试过90分的企业每人奖励500，过80分奖励300，这下子大家积极性都调动起来了，一个月后领导宣布进行第二次考试，这次80分以上都奖300，并宣布两个月还要进行考试，不及格要处分。果然两个月后再考试，90分以上奖300，不及格罚200。

　　通过三次考试，就达到了拔尖，鼓劲，鞭策的目的，而且将软件操作和应用一层层扩散出去，最终形成大面积使用的不可逆转的趋势。

　　很多人听了这个故事对项目管理，目标驱动，激励效应就有了更深的认识，自然也对顾问，对顾问所在公司多了一份信任。

　　5.7.1.2 饭桌上再烧一把火

　　一个好的顾问在陪同考察完毕，一定记得如果安排一同就餐，在饭桌上还得根据客户情况继续烧一把火。

　　不过既然到了吃饭时间，工作就不应该是主题，这个时候比较好的方式是可以从介绍公司文化逸事或者发展思路方式尝试用更高的思维层次和客户沟通，不要再纠缠过多在技术细节上，这样客户可以比较轻松边吃边聊，将一些感兴趣问题又提出来和我们交流，进而继续获得影响客户的机会。

　　记住：客户前来考察是最脱离自己企业环境可独立思考的时间，也是最容易接受别人的时间，整个考察工作如果精心准备和规划，自然能给客户留下深刻的印象，对项目成功起到关键的作用。

6.1 前言(连载四十二)

入行五年，经常碰到需要和各种人等介绍公司的情况，特别是在公司总部接待重要贵宾考察，积累了一些经验，今天把我个人做公司介绍的体会做一总结，希望对所有需要介绍公司人员提供一点帮助和指导。

　　6.2 哪些情况下需要公司介绍

　　公司介绍是用比较短时间内让客户对公司业务能力有一定了解，甚至是深刻印象，为今后合作开一个好头。

　　一般公司介绍有这么几种类型：

　　第一是正式陈述，在重大招投标答辩场合，产品演示场合，一些公开会议上，这个需要很正式地介绍公司基本情况和实力。

　　第二是口头介绍，在商务和实施工作中，碰到一些人关注或者不了解，在没有特意安排的情况下进行口头介绍。

　　第三是会面介绍，一般是和客户约定会面时间，在会面的机会介绍自己的公司和产品。

　　第四是参观介绍，客户或客户到总部来参观，在参观过程中介绍公司文化和发展等各方面情况。

　　不同情况下介绍公司的要求是不一样的，所以下面我分开介绍。

　　6.3 正式陈述时常见错误？

　　6.3.1 反复介绍原来介绍过的内容

　　正式介绍是一个很正规和重要的场合，而且是在双方进行各种接触到了一定程度的时候才有机会进行的工作，因此可能有很多人对软件公司已经有很多了解，因而来听陈述的重点内容不是软件公司基本情况，而是软件功能或者项目实际情况。但对一部分人可能对软件公司不太了解，因此在正式介绍时根据已经介绍过的内容确定取舍，不要反复讲以前很多次介绍过的内容，而是要突出公司竞争优势点，其它内容在没有明确要求的情况下尽量一带而过，不要挤占重点内容介绍时间。

　　我个人经验介绍内容一定要结合客户关心部分强调几个点，一般就是三点公司优势，例如可以介绍的内容一般是规模，地位，实力，客户数，行业经验，规范性，服务能力，研发能力，完整的解决方案，自主版权，公司发展速度，最新情况通报等等内容，但不要面面俱到，效果反而不好，要选择最能打动人的关键点组织。

　　把力量集中反而印象深刻。

　　6.3.2 介绍速度过快

　　正式介绍一般有时间限制，公司介绍又必须首先进行，有的人很想在正式介绍时把公司情况尽量完整进行说明，又担心用时不够，为了解决此问题，就用比较快的节奏介绍公司。

　　但参与正式介绍场合的人往往也是有一定级别的人，习惯用一种比较舒缓平稳节奏听取汇报，而且用很快的语速开始会给人留下紧张，不够大气的印象，进而对公司印象也不佳，而且短时间内的灌输也不见得有效果。

　　所以宁可裁剪内容，也不要介绍公司内容时过快。

　　6.3.3 一些细节用时过多

　　有的人在介绍公司时觉得有一些很重要的内容，例如公司历年获奖情况，一张张把证书慢慢放给客户看，如果不是客户要求的话，这样的介绍方式并不好。

　　站在客户的角度，这是一种包装手段，不是实质性内容，这些内容介绍多了容易给人不实在印象。

　　此外大家可能都有一个经验，看电影的时候片头时间越长越烦，最终让我们记住电影名字的还是电影本身内容。

　　在做公司介绍时没有重点，把一些自认为重要的细节讲得过多，都是对客户时间的浪费。

　6.3.4 资料无更新

　　我经常看到很多人不注意和公司相关部门沟通，总是用自己习惯的PPT或者材料去介绍公司，到了2005年了，公司材料上的成就和案例还是停在2003年，这样给用户的感觉是不是这两年你们公司没有什么发展了？

　　所以一定要注意资料更新，而且资料一定要保证所有公开资料的一致性，特别是介绍内容和公司宣传资料一致性。

　　为了弥补资料不够及时的问题，在介绍时可采用一个技巧，可以用通报方式补充说明，例如可以在介绍时非常自豪的讲：“下面我向大家通报一个好消息，我们刚刚在***”，简短说明意思即可。

　　6.3.5 介绍定位过于自恋

　　很多公司自我介绍一个典型感觉不象是写给客户的，倒象是写给公司老总的自我陶醉的文字。

　　公司介绍材料充满自我炫耀，自我膨胀，自我肯定，就是没有站在公司能为客户提供什么产品和服务内容的角度去组织材料。

　　好的介绍是告诉客户我能为你做什么，不是因为我有多么好，快来选择我吧，同样的内容用不同的方式组织介绍效果也自然不一样。

　　6.3.6 没有激情

　　特别是对于经常正式介绍公司的人，还有一种情况，可能因为讲的次数过多，对重复的内容没有感觉，缺少激情。

　　一个人介绍公司时没有自信，没有一种在此从业引以为荣的自豪，又如何让客户从你个人身上感觉到你所在公司的成就？

　　从容自信，充满感情介绍公司是一个职业人必须能调整自己情绪做到的一点基本素质。

　　6.3.7 采用危险的表达

　　有的商务人员对一些内容不太清楚，在介绍时犯一些常识性错误，例如把CMM说成是通过三级认证，ISO存在认证，CMM没有认证，只有评估，对内行这是错误说法。

　　例如过于强调我们人员多，有360多人，可能现在正式提供给公司手册上人员已经是260人了；

　　又例如习惯性强调我们的EAIP平台和电子政务等内容，其实这些部门或业务已经整合调整不再进行了。

　　这些介绍硬伤是一种危险表达，会让用户觉得我们不真诚或不专业。

　　另外就是为了获得竞争优势，采用一些危险的提法，例如强调我们国内第一，我们实施成功率最高，我们最有行业经验，我们可以现场开发等等说法。谁能证明你是第一或是最优秀呢？

　　在用户没有实际了解之前，不过是虚夸，用户实际了解后，可能更认为你言过其实，更加不信任你。

　　我们有个项目例如强调我们某个产品发展历史很悠久，但实际上发展时间只有三年，版本升级很快，结果客户私下打电话了解相关用户，有的用户告诉他用的版本很老，一直没有升级，有的用户告诉他用的是新版本，刚发行但不稳定，很快客户决定放弃我们这家公司。

　　没有诚信，不会长久。

　　6.3.8 没有专人管理正式材料

　　有的商务人员说我也不想有介绍硬伤，我也想知道公司的最新进展，但哪里去找呢？

　　因此随时更新公司介绍材料，提供标准说法并下发应该有专门人员负责和维护，否则很容易在细节上吃亏出问题。

　　6.3.9 着装随意，不统一

　　参加正式介绍人员着装正式统一应该是个很基本要求，也是对客户的尊重。

　　一旦一个人要介绍公司，就一定要注意，不可在随意和过于放松情况下介绍自己的公司，因为过于放松状态下介绍公司难免给人一种对公司不太认同的印象，既然谈到公司，无论在什么时候，都不是私事，就应该打起精神开始。

　　6.3.10 随时练习

　　有人以为自己介绍公司很多次，经验一定很好，就不注意准备，但在现场就发现要么容易冲口而出，要么罗里罗嗦讲个没完，又抓不住重点。

　　练习，练习，不断改进，这才是真理。

6.4 口头和会面介绍时常见技巧(连载四十三)

口头和会面介绍一般都是在一种相对非正式场合进行，例如办公室面对面进行一些汇报时寒暄内容之一。

　　这个时候介绍公司内容和正式介绍类似，但要注意时间不要太长，一般三分钟内为佳，用户有兴趣再展开。

　　但这个时候交流往往有很多意外情况，所以我觉得自己事先一定要有准备几个版本的说法，应付不同情况，同时保持自己的不卑不亢。

　　6.4.1 不知道型

　　例如有的时候你一讲我是**公司某某某的时候，客户来一句：“**公司，没有听说过，干什么的？”。

　　没听说型的客户是很正常的，这个时候可以说：“*工，请允许我用三分钟简单给您介绍一下，具体内容略”。

　　6.4.2 反感型

　　比不知道的情况更糟糕的时候客户会说“听说你们在某某项目上很不成功，是不是这么回事？”

　　面对这种用户的挑战，千万不要急于否认，只会增加反感，也不要紧张，失败的案例大家都有，不要因为拿出一个不成功的例子就觉得没有希望。

　　我们可以先承认，后化解，“看来*工了解过一些我们的情况，的确我们有一些项目没有做到位，在很多行业，其它地区，我们还是有很多成功的合作，例如在某某，如果您不反对的话，我想介绍一下我们公司最近的一些情况。”

　　6.4.3 我知道型

　　有的用户一听我们公司名号就说你们不就是那个做CAD的吗，这个时候我们就要顺藤摸瓜，夸奖客户：“看来*先生对我们公司很有一些了解，不如我给您介绍一点最新情况”，也可以用化解误解方式进行“看来*先生对我们公司很有一些了解，其实我们不但CAD做得有很大影响，这几年我们发展得还不错，在CAPP/PDM领域我们也是国内最好的供应商之一，所以今天希望有机会给您详细介绍一下”。

6.4.4 领导型：

　　有的用户很忙，也很紧张，根本没有时间听你讲太多东西，我们可以开门见山：“我们是国内最有经验的CAD/CAPP/PDM供应商，听说您的企业有****问题，我们正好有这方面的经验，所以过来和您一起沟通一下，看看有什么我们可以帮上忙的地方”不过这样举问题有一定风险，所以可能的话应有所调研了解。

　　6.5 在客户处进行公司介绍三个要点

　　无论是正式陈述还是口头介绍公司，有三点一定要讲到：

　　业务讲到：我们能为您提供什么，做什么，如何合作。

　　实力谈到：和我们合作为什么可以放心。

　　案例说到：我们不是在说大话，有很多用户和我们一起取得了成功，并有案可查。

　　这三点没有说到，就不是一个完整清晰的公司介绍，换句话说无论介绍时间长短和场合，都可以介绍完成这三点内容就是好的公司介绍。

　　建议公司介绍思路组织可以用以下顺序组织：

　　1)公司业务面—2)产品体系—3)组织架构和服务体系—4)合作建议—5)成功案例—6)发展历程和荣誉

　　对于公司业务面介绍可以设计一些具体问题，引发兴趣；

　　对产品体系介绍要突出重点，强调完整解决方案，可以用案例说明我们在具体项目上给用户成功的解决方案，包括自己的产品，也包括和别人产品的集成；

　　组织结构用图说话，强调研发体系和服务体系的规范管理，可以列举一些数字，例如我们软件测试人员和开发人员比例关系，我们某些产品自动化测试覆盖率，我们每年一个工程师服务工作日等等。

　　合作建议关键是要有针对性，不要泛泛而谈，让客户感觉客户经理只是在讲套话。

　　成功案例一突出用户多，二突出合作双赢效益，三突出我们和用户长期合作，共同发展的服务思路。

　　发展历程介绍要快速精练，给人感觉蓬勃向上，富有朝气，对于公司历史荣誉重点显示最新荣誉，其它一带而过，可邀请客户访问公司网站，了解公司最新动态和文化。

6.6 如何对在公司考察客户做介绍(连载四十四)

　对来公司参观考察型客户介绍公司是有技巧的，一般这样的客户对公司基本情况都有所了解，而且都是公事公办的正规介绍，来到公司，很多人又不清楚客户的来路，别的不敢讲，只好把公司情况又热情介绍一遍，甚至接待人，主管领导轮番轰炸，客户碍于情面，心理上其实已经反感了。

　　其实客户到总部来了，反而要少谈公司，少介绍产品(一般技术问题还有专门交流时间)，多看特色。一般客户对软件公司是很好奇的，又不生产物质产品，很难和其产品线比较，因此没有什么考察经验可以参照。要通过介绍让用户留下深刻印象并不容易。

　　我个人经验这个时候介绍公司有三讲：

　　第一是讲故事，我们这个时候不要呆板的介绍公司，而是要讲故事，例如我们谈公司人数可以请用户看老照片，结合老照片讲公司创业艰辛到发展壮大历程，边讲边和客户互动，看着老照片，听着开目人创业的故事，客户就容易从心理上喜欢这个朴实认真的公司了，而不是简单被一个漂亮装潢的大楼打动。

　　第二是讲特色，特色主要指公司管理上特点，一般管理上特色是结合组织机构介绍进行的，要给用户生动介绍我们的组织机构，我们可以和企业类比的方法，一般我讲研发部就和用户说这是我们的生产车间，请他们看源代码管理工具，看安全保密条例，到测试组就和用户说这是我们的质检车间，请他们看软件自动测试工具，这些是客户很少见到，但见到后有很容易认可软件公司规范可靠的细节，而且有新鲜感。

　　第三是讲文化，我们给客户在公司做介绍，不仅仅要介绍公司经历和管理特色，还要通过这些内容突出我们公司积极向上，勤恳努力的文化。

　　在发展上获得用户认可，在管理上获得用户赞赏，在文化上和客户形成共鸣，这就是在总部进行公司介绍的目的。

　　6.7 做好总部公司介绍的三个诀窍

　　根据公司的发展历程和组织布局设计标准套路的介绍词，保证每次介绍质量。

　　精心设计介绍流程和路线，让用户在每个部门都可以看到他们关注的内容，例如在实施部看项目管理体系，在研发部看规范代码控制过程，在质控部看软件质量保障体系，在营销部看公司获奖荣誉。

　　找一个熟悉公司的人员专门接待，熟能生巧，并定期请其汇报介绍工作改进意见。

　　6.8 公司总部接待考察客户要注意的细节

　　准备热情的欢迎牌，注意欢迎牌一定不要把几个客户单位并在一起，宁可多写几张纸；

　　如果总部不能抽烟，提前告诉用户，请求理解；

　　一定尽量安排高管接待，以表重视，高管如果忙，可以事先说明，接待时间短一点；

　　和客户交流时准备精美的宣传资料，记录交流问题的纸和笔；

　　请客户参观我们的获奖陈列室；

　　安排一次体现当地特色的餐饮；

　　如果时间充足，安排到旅游点参观；

　　临走记得送用户一些土特产礼品；

　　全程安排好用车计划，不要出现用户长时间等车的情况；

　　整体接待不要过于殷勤，要在用户关心考察内容上下工夫，接待工作原则是得体大方亲切，不犯低级错误。

 

7.1 培训工作在项目实施中作用(上)(连载四十五)

7.1.1 培训工作的目的

　　在IT管理软件实施项目中，培训是贯穿整个项目过程中，从一开始介入项目，就有培训，在业务调研阶段，我们可能要答复用户一些概念性问题，在现场验证推广阶段，可能我们要花费大量时间传授软件功能，在辅导上线阶段，更是要随时解答用户疑难问题。

　　好的培训可以让用户熟练掌握实施方法，自主推动项目，增强对项目认同感，可以大大减少软件公司现场服务难度和时间，效益十分显著。

　　作为一个IT项目经理，一个很现实的问题就是，很难一个人在一段时间内只负责有限个项目，越是商务能力强，单子越多的公司，这个问题越突出。

　　很多IT项目经理或实施人员不得不周旋于多个用户，忙得焦头烂额，疲于奔命，用户并不领情，因为用户觉得你对他不够重视，服务质量并不高。

　　一个很有意思的情况就是，很多用户强烈要求我们要保证项目的人力投入，要求派实施人员长驻现场，我们很多实施人员也的确长期在用户现场蹲点，但事实上这样效果好象也不明显，很多项目推进依然并不顺利。

　　要是一个人同时负责两个在进行项目，蹲点必然是治一经损一经。往往因为不能经常性服务一个项目，导致一些小问题会积累成大问题，最后即使去现场推动成本也很高。

　　一个项目经理或实施人员，应该强迫自己考虑这么一个问题：一个人到底可不可以同时负责3~6个项目？到底有没有办法做到这一点？

　　如果一个人负责多个项目思路可行，而且服务质量还能被认可，大概在目前业内你才有可能获得相对理想的收入，否则实施生涯就是一场痛苦混乱的经历。

　　有的人说：当然可以，你给我配置3~6个人，我就可以同时负责3~6个项目。

　　没错！这个思路实质上是说如果你在一个项目中有替代者，通过替代者帮你行使一些相对容易的工作，你就可以集中精力多做一些复杂的工作。这几乎是唯一的办法，至于形成一个团队，三个盖子五个杯，通过调度让每个杯子都能盖一会只是一种补救管理调度手段。

　　这种调度能力会随着盖子和杯子绝对数量增加而变得脆弱不堪。而且一个项目人员如果经过不具备稳定性，信息沟通失灵，信息不对称现象将非常突出。

　　如果软件公司不能给你配置或调度替代者的话，怎么办？

　　答案就只有一个出路，在企业培养替代者。

　　如果我们充分重视用户培训工作，让用户也成为可以独立实施我们软件的人，不也就一样达到了配置人员进行实施的目的？这样就象我仅仅只需要给我的替代者一定时间指导，前期可能现场多一些，后期可能电话多一些，有了替代者，同样可以达到管理项目的目的。

　　所以我个人经验就是在项目中培训工作的根本目的是让用户在很短时间内可以自己独立实施项目，而不是仅仅会用某些操作。

　　如果仅仅是会用某些操作，当项目遇到大量困难的时候，用户还是会找软件公司，希望通过软件公司的手推动很多事情，但是别忘了，当企业自己本身没有或者找不到推动一件事情的动力的话，很难想象软件公司有多大的作用。

　　不过有意思的就是，很多用户高管非常赞同我的想法，培训的目的就是让企业可以自己推动信息化工作，不能总是依赖软件公司某个人或软件公司。

　　一个实施人员和用户系统管理员的差别到底是什么？

　　我们强在软件技术全面，而用户系统管理员只需要知道和他们相关内容部分维护即可；

　　我们强在靠体系化方法推进项目，而用户系统管理员更善于利用企业实际潜规则推进项目；

　　我们强在一些思路理念比较清晰，但用户系统管理员更了解企业实际情况和业务特点。

　　所以如果我们能把我们的技术、方法、理念传递给用户核心成员，或者是系统管理员的话，我们就可以在企业培养一个有效的替代者，这个替代者如果有足够动力被激发，能发挥作用和能量可能比我们自己都要大。

　　让用户控制项目，我们提供软件工具和智力帮助，这将是现阶段中国IT服务的有效生存之路，如果服务可以收费，用户且愿意外包，才可以主动替代用户实施推进项目。

　　实施人员对培训目的要有一个清楚的认识：帮别人就是帮自己。

　　要想少出差，就得让用户在现场能独立工作。

　　实施工程师最好的选择就是让用户可以自己实施常规功能，而且要灌输一个重要理念软件公司的工作只是保障项目所运行业务需要的产品功能完整可用，而不是帮助企业利用软件做业务录入数据，那是企业自己的事情，而且只有企业自己也可以独立实施维护软件了，软件的实施才是真正成功和有保障。

7.2 培训工作在项目实施中作用(中)(连载四十六)

7.2.1 用户能不能培养成替代者？

　　有的人说，用户怎么可能在很短时间内就具有独立实施项目的能力？

　　第一用户不象我们有专门时间学习和培训，第二用户不象我们有足够动力和压力。

　　我自己个人在项目实施中体会是不要低估用户的智力和毅力，的确不是所有项目用户都具有被培养的潜力，但在很多项目中，从来就不缺乏能够培养成为一个好的实施者的用户，而且这样的人只要一个就足够了，只是我们自己并没有花时间去找到一个大家认可这样的一个人而已。

　　用户虽然没有太多时间学习培训，但衡量我们培训工作的质量标准，就是看培训有没有做到在很短时间内将一个人快速培养成材，可独挡一面。

　　我们很多培训并没有达到这个目的，那说明我们还需要在培训工作上想办法，动脑筋，而不是简单将事情归结为复杂，只会说一件事情复杂的人不如说自己无能更妥当一些。

　　更何况在单个项目上用户对很多操作可以不必知道，学习工作量并不象完整培训一个实施人员那么大。

　　第二用户也有业务上压力，项目上压力，也有自我突破，学习新技术的动力，未必不愿意配合我们工作，何况我们只是找一些核心的用户，有心的用户进行高强度培训，不是要求所有的人都有同等能力。

　　我们再看一看一个软件公司新进人员在多长时间内必须独立去现场工作？最多三个月。短短三个月为什么他就可以去现场工作呢？就是因为培训。

　　另外再想一个问题，这三个月他一直在接受培训吗？显然不是，好象只是简单培训了一段时间，可以入门了，然后就通过查阅资料和请教方式去自我成长。

　　其实学习软件很少有靠人手把手教出来的，基本上高手都是摸出来的。而且在摸的过程中往往是在一段时间内高密度的研究一个软件，直到明白。以后即使这个软件功能上有什么扩展和发展，学习成本将非常低。

　　在最短的时间内做最大量的事情，这就是成功将用户培养成替代者的秘诀。

　　成功的培训周期一定不长，一定是在最短时间内不断反复强化某些业务环节操作，形成习惯。

　　不要指望用户自己会自动自发地在一段时间后掌握操作，而是在一段时间内大量练习，强化掌握后再逐步琢磨如何应用，逐步熟练后达到一个很高的境界。

　　很多用户并不缺乏IT知识，只是不太清楚具体软件操作和对框架的理解，由于熟悉业务，对软件和业务工作结合点价值点的认识和理解可能比我们自己还要强。

　　对这样的用户，换句话说我们已经弄懂的东西传授给用户恐怕并不需要三个月。我们一个项目实施周期短的话也要半年，长的话要两三年，这么长的一个周期内，居然一个实施人员安排不出来时间给用户培训，而且培训到可以达到独立实施的能力。

　　这种现场自我反省，更多的是我们在工作意识上，工作方法，甚至我们自己对软件理解操作熟练程度上有欠缺，所以导致我们软件能力无法传递给用户，也得不到认可。

　　就我本人实施工作实际体会，无论是国营企业还是民营企业，无论是大企业还是小企业，绝大部分都可以培养用户实施者。的确有的企业做这件事情难度大些，成本高些。

　　但无论怎么样，我们有无极强烈意识在企业建立一个项目团队，让项目团队得到资源保障，让项目团队关键人员推动项目实施，一旦发现项目中这种情况和局面不存在，就想千方百计去做到这一点？

　　这就是我们能否培养替代者的关键意识。你认为可以，可行，你就会去做。

7.3 培训工作在项目实施中作用(下)(连载四十七)

7.3.1 培训工作为什么质量不高？

　　坦率的说，我们现在整个行业培训工作质量是不高的，至少是参丝不齐的。我个人认为主要原因有四：

　　第一缺少高质量的按业务组织的培训教材。

　　很多软件公司，特别是管理软件公司并没有一套完整的结合业务的培训教程，更多的是功能手册和配置手册，这样的内容很难理解，更不能传授能力。

　　很多对软件有兴趣的人并不需要太多时间指导，但一定要给他很容易上手的教程。所以国内很多人都可以自学复杂的CAD软件或三维设计软件，坦率的说这些软件操作比任何一个管理系统还要复杂，但很多人就是可以自学，和教材丰富有关。

　　第二培训者的能力缺少验证。

　　我们很多软件实施工程师强在技术能力，弱在业务理解力和表达能力，到对得上一句俗语，茶壶煮饺子，有货倒不出。对于技术型人员主动培训用户在心理上也是一种挑战。

　　可能有的人是心里明白，就是说不清楚，让人看着着急。

　　心里明白，表达能力不足还好，更糟糕的是很多人心里也不明白，或者是半瓶醋，在那里装明白，典型的小黑蒙大黑，最后用户说天下乌鸦一般黑。

　　在标准业务教程没有到位的情况下，要对培训者培训工作进行主动考核和管理，才能保证培训质量。

　　其实办法很简单，学校招老师是如何进行的？试讲！如果你还没有准备好手册，并不等于不可以传授知识，那么就请你讲内部公开课，没有达到清晰明白讲清楚软件功能和业务的人员首先自己加强培训。

　　第三不重视培训工作。

　　很多实施人员总觉得培训很多细节给用户很麻烦，我把所有配置都调整到位，系统到了一个可用的状态，然后你要掌握的操作就是那么几步，我把这些都教给你，不就完了？然后我再提供一个业务手册，你参考看看，不就行了？干吗要花费大量时间和精力在现场培训，又不是没有事情做？

　　甚至有的人可能还在想，软件还有问题，我精力应该放在解决问题上，而不是培训。

　　结果无论人在现场不在现场，大量时间都是一个人在忙碌的配置调试，然后请用户检查验证。然后好早点走人，去下一个现场解决问题。

　　欲速而不达，这样的项目越是到了大规模推广时实施人员越头痛，根本不能走开，一走开就出问题，大量的出问题，别的项目要是同时推广，实施人员的行程几乎就是难以兼顾，自己就不要做任何休息了。

　　是否重视软件培训，千方百计想办法让用户会用，好用，爱用软件，是一个好的实施人员的价值。

　　第四忽视软能力培训。

　　很多软件培训工作，特别是管理软件培训工作不仅要培训功能，还要传授实施方法。

　　要告诉用户遇到问题如何分析，是需求还是缺陷？分别如何处理？

　　要告诉用户如何判断实施阻力，软件实施到哪一步可能会有什么困难，如何化解？

　　要告诉用户你应该如何培训其它的同事，如何将能力传递扩大？

　　如何界定一个项目边界和近期目标，并逐步实现，所有实施人员都应具备的软能力，这都是要传授给用户的，这样用户才可以真正起到一个管理控制者的作用，这样的用户才能独挡一面，也会通过项目实施得到在企业内部的肯定和认可，也就有实施的动力。

 

 

7.4 培训工作应如何组织？(连载四十八)

要准备一次成功的培训，要考虑一下几个工作，首先是培训内容策划，然后培训计划编制和确认，然后是具体培训组织工作，最后是培训考核和反馈。

　　7.4.1 培训内容策划

　　培训前要根据不同培训对象，不同培训内容，不同培训阶段，不同培训师资进行内容策划。

　　要针对用户层次，实施阶段设计培训主要内容。

　　想好每个阶段目标用户应掌握的内容，作为自己实施目标中一部分，并通过相关培训活动达到。

　　一般培训内容可分为：

　　业务调研培训，重点在告诉用户我们工作方法和相互沟通配合方式；

　　解决方案培训，重点在告诉用户我们软件业务模型和整体实现思路；

　　功能验证培训，重点让项目组或系统管理员掌握软件基本操作，进行功能验证；

　　辅导上线培训，重点在让一般用户掌握相关部分业务操作，让系统管理员可以掌握常见配置和维护工作。

　　培训策划还包括选择培训对象，不是企业每个用户你都要培训的，而是选择一个或几个重点用户培训，确定其掌握基本能力，然后辅导重点用户培训别的用户，逐步扩大影响。

　　如果企业比较大，还需要策划分几批培训，分别培训什么内容。

　　培训策划还包括如果将培训工作成果汇报给企业，并形成共识。

　　而且一旦有重点用户可以在实施人员辅导下独立培养别的用户操作了，或者进行了大面积普及操作培训并达到目的，要立即给企业领导汇报，除了汇报成绩确定项目进入一个新的里程碑外，汇报一方面要求企业主管领导表扬这样的用户，保护其积极性，一方面也要企业领导知道，我们是真的来做好项目，所以我们不但提供软件，还在真正为企业培养自己的信息化实施人才，别忘了这是很多项目招标时的要求。

　　这里面通过汇报也对企业领导进行了培训，灌输了我们是工具，我们是智力支援者，不是实施主体的理念，如果软件有问题，我们来解决，如果软件没有问题，企业要自己用软件功能在我们指导下主动解决问题。

　　而且让领导知道了如果遇到问题可以请企业自己中谁负责解决，实际上也帮重点用户提高了在领导面前的曝光率，肯定有好处。

　　培训策划还要考虑培训的地点和成本，包括人力成本和时间成本，一定要合理安排，高效紧凑。

　　7.4.2 培训计划

　　培训策划的阶段成果是培训计划，培训前要将培训计划制定好并通知到最终参加培训的用户，这是很重要的工作。

　　培训计划应该先在内部经过大家确认，落实资源后才能提交用户。

　　一份完整的培训计划要确定培训目标，详细分解培训时间、培训内容、培训师资，说明培训地点、签到方式和考核方式，让用户提前做到心中有数，方便准备。

7.4.3 培训组织

　　培训计划编制前要和相关培训资源进行沟通，确认是否可按时间进行培训工作，同时要检查培训场地是否足够，是否有足够资源上机练习，是否有其它必要设备，等这一切就位后还要和用户确认最终培训人数，时间安排和其它相关可能工作。

　　如果用户是到软件公司培训，还要落实用户的餐饮安排，住宿安排，接送安排，参观安排，订票安排，礼品安排，并列计划报公司批准认可后执行，这些都是一次成功培训组织中要考虑的工作。

　　培训组织要特别重视培训环境的质量，高质量的培训环境应提前准备好相关软件环境，并调试通过，不要等用户开始上机才进行安装。

　　培训组织中最重要的工作是完成培训教材的编制，并提交审核或主动安排审核。

　　审核培训教材的方法有两点，一是确认教材思路是否清晰，细节是否完整，二是看培训者讲解是否易懂，和教材一致。其中对讲解能力的验证要更强于教材的验证，没有教材一样能做好培训，没有好的辅导讲解能力，很难做好培训。

　　基本上很多公司对这个工作是忽视的，也是没有人负责的，这是一个很大的问题，这种事情验证成本并不高，因为可以采用认证资格的方式进行，一个好的培训人员，对其培训能力的验证在一段时间内只需要验证一次就行，而这个能力至少可以在一年内发挥巨大的作用。

　　本人亲自检查过很多对软件的讲解，说个不中听的话，这样的培训能让用户明白我们是干什么的都难，别说让他跟着你走，按共同的意图推进项目。

　　此外培训教材中数据录入规范也是培训重点内容，这个讲解倒不难，实施人员要结合企业实际精心准备是关键。

　　数据录入规范准备要点有三条：

　　1、 习惯填写方式说明及样例

　　2、 正确填写约定及样例

　　3、 常见问题处理方法

　　7.4.4 培训考核和反馈

　　培训效果如何要从两个方面去验证，一是对用户掌握程度的了解，这就要通过培训考核去完成。

　　一方面要了解我们培训的质量，这就要通过培训学员的反馈来了解。

　　任何集中完整培训工作都要提前结合企业实际业务准备适当难度培训考题，这也是培训审查工作内容之一。

　　培训成绩原则上要反馈给个人和企业相关组织单位，这样才能形成一个反馈激励机制，我们可以采用“优秀鼓励，落后不提，以先进示范带动整体提高”的策略促进培训深入开展。

　　第二培训完成后，要请学员填写培训效果反馈表，这样对培训老师形成一个反约束，为了让培训学员有一个好的效果反馈，就不得不精心准备培训工作，而不是敷衍了事。

　　考虑到实现成本和实际能力及企业情况，考核和效果反馈表可能不太容易操作，但从长远来看，有没有培训考核和反馈的培训工作质量一般是两个档次以上的差距，这也是一个客观规律。

　　培训效果反馈表要提交给培训老师和公司相关培训管理部门，由其安排进行培训改进工作。

　　7.4.5 好的培训行为习惯

　　随时随地随人随事的培训

　　培训的工作并非一定要专门的时间专门的地点进行，实施人员要利用一切机会用各种易于接受的方式将思路、操作或配置传递给用户，并随时从用户处获得反馈，改进内容。

　　在培训中互相学习

　　培训过程一方面注意传授内容给用户，也要抓住一切机会向用户学习业务知识，业务知识越多，今后培训准备也就越到位，培训内容也就越生动。

　　随时记录培训中发现的问题

　　培训过程中会经常出现一些用户提出的问题，很多都是很好的改进建议，要立即记录，并反馈给公司对软件进行持续改进。

 

7.5 培训注意事项(连载四十九)

　一定要事先准备好业务手册或者培训教材，没有教材的培训工作质量无法保障；

　　培训过程中比较好的讲解思路是：

　　先讲业务后讲思路

　　先讲思路后讲操作

　　先讲操作后讲配置

　　先讲配置后讲维护

　　培训过程中如果没有投影可以充分利用各种工具软件实现同步教学，例如“NETMEETING”工具实现多台电脑同步放映。

　　上机辅导一定要有人陪同，主动答疑。

　　培训操作要先手把手操作示范一次，示范后立即要求用户练习几次，确定用户掌握后才能结束一次培训辅导。

　　在培训中要及时大胆诚恳鼓励用户的每一个进步，在培训过程中完成软件思路和管理理念灌输和培训方法的灌输。

　　传授用户如何记录软件缺陷和分析缺陷的方法，让用户可以按照要求提供此类数据，减少自己为了一个小问题去现场的概率。

　　传授用户用各种远程协助工具进行软件辅导的方法，让用户适应在线辅导，减少出差成本。

　　7.6 总部培训

　　7.6.1 为什么要考虑到总部安排培训？

　　有的时候现场培训用户经常受工作干扰，无法连贯进行培训活动，有的时候用户主动希望到软件公司进行培训，总部培训也是培训策划中一个内容，是安排到总部培训还是在现场培训，是要根据用户重要程度和效益来评估的。

　　对于一些大型项目，特别是用户执行力不够，现场培训效果不佳的项目，安排一次紧凑合理的总部培训会收到很好的效果。比起在现场反复培训，每次培训效果都不到位，一次紧张有序的总部培训往往成本更低。

　　而且在软件公司培训用户换了环境，可以协调更多人和用户交流，用户此时更容易接受我们的管理思路，并达成一致，有利于后续工作推进。

　　在总部培训还可以和商务进行协同，搞好接待工作，有利于建立个人交情，用户也愿意在后续工作中配合我们开展工作，了解我们工作流程，按照我们制度配合，而不是简单埋怨责怪。

　　所以总部培训是很好的一个培训组织方式。

　　7.6.2 总部培训经验

　　很多用户要求到总部培训，实施人员或者客户经理只给公司一个通知，人就送过来了，用户到总部培训，至少要做好三个准备工作：

　　和公司培训负责人事先排好计划，沟通资源，确保到位

　　和客户经理一起安排好接待工作，尽管很多用户我们不负责住宿餐饮游玩，但从中国实际情况出发，在成本接受范围内，适当安排一些招待游玩，根据用户报销水平落实好用户宾馆和订票，这些细节会极大提高用户对我们认可程度。

　　确保培训工作有实施项目组成员参加，总部培训一个重要目的不是简单让用户掌握操作，而是让用户变成项目主体实施者，也就是自己人，所以无论是现场培训还是总部培训，项目组一定要有人和用户泡在一起，只要用户还没有走，就必须时刻有人辅导和培训。

　　我们有的项目培训实施人员没有亲自参与，或者晚上用户上机练习，自己因为远就先回家，都是因小失大，你如何对待别人，将来在项目中用户也是如何对待你。

　　总部培训结束后，一定要做好培训备忘录，让用户回去对其公司负责人有个明确交代，至少要说明我们的工作质量是没有问题的。

 

8.1 现场推广工作可进行条件？(连载五十)

　如何通过现场推广让用户项目快速上线，是很多实施工程时关注的问题。如果一个项目非常简单，和以往工程基本类似，那么辅导上线就非常轻松，根据企业业务和产品特点做好业务手册和应用规范，直接安装调试，验证无误就可以大面积推广，实施周期可以大大缩短。但对于很多大型项目，有很多不确定性或个性的内容，要进入现场推广阶段需要做很艰苦的工作。

　　在一个项目实施过程中，如果要想让现场推广工作快速有效进行，其实是需要做大量高质量的前期工作，现场辅导系统上线应用不过是一个很自然的结果。

　　现场推广工作可以进行在具备四个条件情况将非常顺利：

　　1) 经过充分现场功能验证，确定产品功能基本能连串起一个或几个基本业务流，并得到用户项目组书面认可；

　　2) 产品的稳定性和性能在可预见并发环境下性能能达到可使用要求；

　　3) 针对基本业务流的业务操作手册全部编制完成，并对相关用户完成培训；

　　4) 用户和软件公司都可以投入一定资源，主要是用户方有可独立推广资源。

　　软件功能能不能支撑一个业务是进行现场推广的最必要条件，很多人为了项目交差或者应付用户，匆忙装机、配置和辅导，最终用户发现用起来不是很顺利，经常出现BUG，或者对业务支持并不能达到要求，对软件就失去信心，再来推广，阻力就大，非常困难。

　　功能可以支持的情况产品稳定性和性能也很重要，如果产品稳定性和性能不足，项目往往也容易陷入停滞。

　　至于业务手册和用户推广资源也是顺利进行现场推广的必要条件。

　　实际项目实施过程中，往往是这些条件都不能满足的情况必须进行现场推广，否则无法将项目推进到一个阶段，得到用户认可，以便验收回款，但实际上效果并不见得容易达到。

我个人体会现场推广顺利不顺利，其实不在现场时间长短，而是你为现场推广准备工作细致程度关联性更强。要想出差少也能控制项目，就必须寻求合理的项目控制策略。

　　8.2 现场推广工作为什么进展慢？

　　很多项目在快速完成业务调研和基本配置之后，就好象进入了一个平淡期，业务已经似乎清楚了，配置也按要求完成了，但用户好象就是没有什么用，大部分人也没有积极性，项目进入了一个僵持期，为了推动项目企业项目组或信息化负责人不断催促我们实施人员进入现场，推动项目。

　　而我们的实施人员也非常努力地在现场推动，推动，再推动，直到推不动，项目成为一个胡子工程或者是拉面工程。

　　项目现场推广时间无限延长对用户，对软件商，对实施人员都是一种极大的伤害和折磨，我们认为项目推广时间无法确定或者确定后无法结束恰恰是一个项目失控的症状。

　　泡现场其实是典型的项目失控特征之一。

　　我们可以分析为什么经常出现用户要求实施人员来泡现场？

　　从实施的角度来看，无非是以下几种原因或原因的综合。

8.2.1 软件总是出问题

　　很多项目从一开始到现场推广是一段痛苦的经历，在推广过程中简直就是软件捉虫记。不断往前进一步，不断发现新的严重影响使用的BUG，导致项目停滞，去解决BUG，往往要耗费大量时间，然后再费尽力气再进一步，再发现BUG，再暂停，再去解决BUG，如此形成一个恶性循环，项目走走停停，周期不断延长，用户失去信心，而且觉得我们工作质量太低，慢慢不相信我们，对我们充满抱怨。

　　软件存在问题是客观的，没有不存在BUG的软件，无非是多少严重程度的问题。这应该是一个理智实施人员开始工作的限定条件：用可能存在BUG的系统解决问题。

　　但是我们往往犯的一个错误，人总是有意识无意识假定软件就应该是没有问题的。无论是用户还是实施人员都有这样的心态。

　　如果软件总是存在BUG，规划在干什么？开发在干什么？测试在干什么？那么多管理流程和制度为什么不能保障？在我们的宣传往往又是稳定可靠的情况下很多人对这些事情就有了一种反感和抵触的情绪，进而认为自己现场工作不顺利，都是公司的错，都是软件的问题，我是无能为力的，出现这样的心态才是最大的问题。

　　其实我们现在已经明确了，软件发现BUG是肯定，这是我们可以预见的项目风险。我们作为一个实际项目控制者，必须采取主动的项目控制对策，才能有效管理项目。

　　这个时候最有效的方法就是加强对软件的验证，根据自己项目业务过程，不断测试，发现是否存在严重问题，并采取相应的对策解决。

　　如果不是严重问题，可以先寻求替代方案(寻求替代方案可以是群策群力的过程)，不影响项目实施进度，然后让公司规划部门将其纳入可接受的版本规划时间，如果公司响应能力不足，我们将要把其作为项目风险提前和用户沟通，寻求支持和理解。

　　如果存在严重问题，肯定影响项目进展，就应该全力在公司推动解决BUG，然后再去现场更合适。

　　否则到了现场问题响应不及时，被用户指责之下非常容易被动，失去对项目的控制权。这个时候实施人员要么只好无原则承诺我们开发会解决来转移自己的压力，然后让公司承担大量开发响应申请，要么只好表示我们一定来解决问题，大量时间在现场推动一些无关重要的细节。

　　真正明智的实施人员一定会自觉花费大量时间做业务流验证，确保项目功能可用够用，能够支撑一个或几个完整业务流，没有重大程序隐患才会去现场推广。

　　在软件某些业务存在极大问题的时候项目团队不应该去现场，而是推动这些问题解决完成才能去现场，去现场时间多少不会成为用户是否认同我们的标准，去了能否解决问题才是用户是否认同我们的最后标准。

　　可以少去不去，但是每次去之前一定很清楚自己能解决什么问题，哪怕是很小的一个问题，解决问题完成培训，落实用户自我计划就可以回来。

　　如果软件发现还有问题却一定要去现场，前提就是你还有其它可选择的业务方案或管理行为要去解决，这些问题可以和发现的问题独立存在，无关紧要。

　　有的实施人员可能抱怨，为什么一定要我在公司推动这些事情，其实这倒未必，一个好的实施人员发现一个项目存在问题，可以及时反应到公司，通过软件配置管理和开发流程解决，但一定要按照配置管理要求把项目情况反映到位，如果反映不清楚才需要到公司协助，多出来的时间就可以多响应一些项目，这样一个实施人员同时响应两到三个项目是很容易做到的。

 

8.2.2 要推广的业务流不完整(连载五十一)

很多项目也做了一些验证工作，到了现场随着业务的展开，还是不断发现BUG。这就说明我们并没有建立一套可独立推广的完整的业务流，只能说在项目实施过程中我们只就部分业务流进行了验证，到了现场才发现实际业务情况并非如此，因而又陷入困局。

　　而能否拿出完整的可操作业务流推广方案是项目调研质量紧密结合在一起的，项目调研完成后，一定要可以拿出完整实现的业务流实施思路和方案，这也是自我评判实施调研工作是否完成的一个尺度。如果调研完成了，只有一堆细节信息，却没有完整的业务流框架，这个调研对实施而言就不能算成功，这个阶段工作也就不能算结束，还要花时间搞清楚为止。

　　但我们在调研过程中未必一定要搞清楚所有业务流和实现方案才能往下走，我们可以先解决完一个业务环节再往下走，把企业复杂的业务流程化整为零，形成相对完整的部分，用一个清晰效益目标牵引或做为愿景，促成企业一个业务流程一个业务流程不断前进。

　　但对于单个业务流程而言，配置一定要完整，一定可以看到用这个系统把企业实际中哪一件事情真正走完了，然后还比较方便，甚至是前期不方便，但可以完整实现。

　　如果实施不能得到这样的几个业务流方案，并反复站在用户的角度推想可能存在哪些问题，验证的质量就不会高，也不可能在现场顺利推广。

　　如果每个项目都能做成一个完整业务流，只要有10个成功的项目，软件在很多方面就会达到非常优化好用的状态，再进行推广经验的移植效益将极大发挥。

　　8.2.3 和用户就推广实施方案没有达成一致

　　有的时候，实施工程师也拿出来一些业务实施方案，但一进入推广，用户并不认可，要求按自己的思路来，这样经常是边推广，边争论，然后不断调整推广目标，下面的人就等待观望，我们不得不调整部署，重新开始实施过程，甚至是软件配置和功能验证过程。

　　这样看来有清晰的业务实施方案也未必就能顺利推广，业务推广还必须和用户项目组达成一致意见。要和用户达成一致，并非是某个业务可用不可用，而是我们是否可以找准用户也可以认可的价值点。

　　举一个例子，我们很多项目要求用户入库数据，以方便今后图档的管理和查询。很多用户一实施就不认同，反而要我们上工作流或项目管理。这样就项目推广目标没有达成一致，结果就容易反复，反复后用户可能发现没有基础数据工作流和项目管理也跑不好，最后还是搞基础数据录入，但一上一下的折腾过程中，大部分用户可能已经不看好项目实施。

　　为了让用户认可推广目标对应的业务流，我们往往要想好关于业务价值的说辞，这个说辞推导要有力，而且有数据事实证明，而且有可清晰看到的价值，这样的业务才可能有人跟着走。

　　换句话说，你想让别人做什么事情，一定要有一个可以看得到或者想象得到的效益可期待，否则业务推广目标很难达成一致，即使用户同意按你的思路去做，最终也一定反悔。

　　就以我们说图纸是否可以方便查询是很重要价值点为例，如果仅仅强调这一点用户开始可能还不觉得，一旦录入数据开始就觉得怎么信息化尽是干苦力活？积极性很快就会演变成阻力。

　　所以要推广自己的业务流一定要和用户项目组就推广目标达成一致，达成一致才能快速推广。

　　事实上我们要先和用户分析如果图纸不好找有什么后果？能举几个真实的事例吗？如果好找真的有效益吗？为了这些效益值得我们投入这么大成本去做吗？如果遇到阻力领导会支持我们吗？

　　这些效益和目标经过反复设身处地的换位思考，和用户项目组达成一致了，才能成为项目推广顺利进行创造条件。

　　目标明确了只能说是大方向的事情落实了，和用户项目组要达成一致的事情还包括具体的策略，如何做才能保障这个目标实现？这个思路也要达成一致。

　　还以图档管理为例子，原来的图纸不好找，需要解决，这个目标认同了，不等于事情可以启动了，还要和用户组就如何管理的方案达成一致。

　　那么在系统如何管理图纸呢？我们可以以产品结构建立树状视图，我们可以根据各种特征建立分类视图，我们可以根据阶段建立项目阶段输入输出视图，我们可以根据文件类型建立关联视图等等，这些思路也要先和用户项目组达成一致，让他们觉得这些思路和方案不但能够解决问题，而且以往管理上的一些优点也可以被继承，这样的方案才比较有推动力。

　　管理的思路明确了，如何去做也要考虑清楚，而不是走一步看一步。

　　我们是安排专人录入数据，大家去利用，还是安排每个人都录入一些数据，逐步积累，我们是从新产品开始积累，还是把老产品数据也立即录入系统，我们每个人每天可分配工作时间大概是多少，这个时间段经过培训可以录入的数据量是多少，这样按一周数据录入量计算全部图纸录入完成大概需要多长时间，能否在系统实施可接受周期内，如何保障每个人的数据录入时间，如何组织培训，确保每个人都可以掌握操作。

　　这些工作细节都需要沟通确认，而且计划分解得越详细，执行力越强。因为所有最复杂的事情都变成了很简单很小的独立工作，每个工作完成需要的技能都很单纯、时间很小，在落实时阻力就小。

　　如果思路得到确认，我们就可以和用户项目组一起建立一个计划，落实我们的设想，再发动大家按计划运行。

　　一旦计划确定，要立即行动，我们应按计划高质量完成工作，然后就是催促用户项目组按照计划完成他们的任务，并提供技术支持，这个阶段我们要明确技术支持阶段我们就不需要大面积现场工作，除非有系统不能解决的问题

　　如果用户按计划在执行，我们还需要不断主动了解进度，形成一种进度反馈，根据进度快慢采取适当措施保障项目目标在实施周期内实现。

　　实际上通过和用户就实施方案达成一致，我们也就传授了一个很重要的项目管理套路：认同目标，明确策略，建立计划，立即行动，不断反馈。可以说任何事情只要这样做，就很难失败。

8.2.4 没有激发用户的主动性(连载五十二)

一般情况下现场推广很多用户认为主要是靠软件公司来落实，的确在很多企业由于体制观念的原因，在这些方面需要软件公司多做很多工作。

　　但实际上一个项目大量依赖软件公司人员推动，这个项目失败概率会比较高，越是成功的项目，用户主动性越强，用户才应该是项目实施的主体。用户自己的项目不是用户自己实施，却要依赖我们实施，这样的项目我们如何成功？

　　我们之所以推广失败往往是我们把自己思路给用户一描述，甚至没有什么描述，就闷头大干，用户不知道如何参与我们工作，只好去监督我们，成为项目的监工，而他们又不清楚系统的思路和实施套路，只能按照领导意图来给我们施加压力，而不是和软件公司一起分担压力，这样进行的项目自然难以受控。所以我们这样做的都是事倍功半的工作。

　　把用户，至少是用户项目组变成可实施的力量，并帮助他们推广实施项目，而不是依赖个人力量推动实施，把他们由项目监工变成项目执行者，我们成为监工和顾问，这样的实施才轻松有趣。

　　让用户真正参与项目实施工作，虽然用户累一些，但大家有了团队的感觉，心情反而更愉快，说个套话：往往在这个阶段和用户建立了战斗的情谊，为今后验收回款参观都奠定了牢固的基础。

　　所以我们在项目推广方案中要反复强调和贯彻这一思路，并得到用户认可，在实际工作中落实，而且用户掌握的技能要清晰写进备忘录，这样就可以请他们中具有相关技能的人去解决问题。

　　例如软件安装，我们可以和用户约定，我只示范装3台，然后安排用户方面的人装3台，我们在旁边看，如果连续三次都成功，我们认为基本上问题不大，其它的都可以交给用户处理，我们只需要处理意外问题。

　　又例如进行某个业务操作培训，我们先要经过讲解示范，确定用户项目组明白，立即请用户项目组操作，确定他们掌握了操作，那么后面的培训可以主动邀请用户项目组成员讲解，我们提供技术咨询，今后培训工作策划组织都可以逐步传授给用户项目成员负责，最后一般问题基本不需要我们出马，大面积基层用户都习惯和自己人交流解决问题，我们只负责解决软件的疑难杂症，而且某个业务被大部分人熟练掌握后，我们的工作主要就是新的业务流推广方案验证设计规划，还有保障项目进度的相关管理活动。

　　这样一轮轮循环，就可以让用户项目组慢慢成为实施的主体，而且在这个过程中用户项目组成员可以得到极大能力成长和进步，他们也会感谢我们的帮助。

　　一到现场工作，任何时候都要确定这个游戏规则：

　　实施推广以项目组为主，我们负责技术支持，负责推广实施能力的传帮带；

　　一旦实施能力转移了，我们并不需要经常来现场工作，因为我们来现场工作成本极高；

　　一般情况下我们只需要在现场解决问题，培训技能，达成后续工作计划，完成本次业务目标就必须返回。

　　我们不能解决问题的时候，我们会全力促成问题解决，一旦解决我们第一时间安排现场响应，但如果我们解决不及时不顺利我们会第一时间通报，也请用户理解支持。

　　不过坦率的说，很多实施工程师本身也不知道如何做这件事情，思路也是乱的，也不会做计划，这样的话去激发用户就缺少个人魅力和行动能力，就只好亲力亲为，被动响应，这个时候为自己能力不足付出代价也是没有办法的事情。

　　8.2.5 光打雷不下雨，缺少高管支持

　　很多时候仅仅和用户项目组达成一致意见还不够，还要和用户高管达成一致。否则在项目遇到阻力的时候，得不到更多资源响应。

　　达成一致的实施方案要给用户高管汇报，汇报要点不在软件功能实现和配置细节，而在于目标是否认同，资源投入计划是否可行，可能会有哪些风险，采取了哪些措施保障，如果出现一些项目阻力，需要提前得到领导哪些授权或政策支持。

　　特别是要向领导汇报取得认同的工作就是，将和信息化相关的基础工作(例如数据录入，业务执行)变成有制度保证的岗位要求和流程要求，这样信息化工作推进才有制度保障。

　　取得高管支持最有效手段是建立和高管的汇报机制，这样才能够让高管清楚知道项目进展和需要给予的支持，项目组成员也会因为可以经常得到高管授权和肯定而努力推动项目。

　　给高管汇报要注意的是，每次汇报应该准备一些积极的内容，值得肯定的内容，的确有进步的内容为好，否则仅仅是诉苦汇报，是不用指望高管对一个无能的团队给予更多的支持的。

8.2.6 边界总在变更(连载五十三)

有的项目实施过程中，用户不断提出一些新的要求，希望我们能够给予解决。

　　这个时候我们有的实施人员顶不住用户的压力，被迫承诺答应解决，结果就导致项目的边界总在变更，项目目标在一次次变更中不断变形偏离游离，最终模糊不清，项目也就陷入不断开发，不断提出新问题的循环之中。

　　用户提出需求要进行分析，一般用户需求有三种情况：

　　第一种的确是软件规划没有合理解决的问题，而且无法绕过去，或者绕过去对用户项目就没有什么合理的价值了。

　　这类需求在业务调研阶段就要主动思考和确认，在功能内部验证配置业务流时就要发现，并向公司反馈，强力推动解决，不要等到现场推广时让用户去发现，然后再去改，这样可能浪费了好几个月宝贵的时间。

　　第二种是软件易用性和稳定性或者性能方面的问题，但的确有替代方案或者暂时可以接受。

　　对于这些需求我们应该给予解决，但要和用户解释这些需求必须纳入统一版本规划实现，不可能今天提出要求，明天就改好，这样开发管理快是快，但长远可维护性一定很差，所以在功能验证阶段要主动和用户项目组提出项目推广过程中哪些功能可能会产生问题，需要大家提前做好沟通工作和说辞，一旦出现应用者不满意的情况，我们还可以想办法提前打预防针，心里有数的处理疑问，不至于被动响应，甚至自己都没有发现用户提出的缺陷或者种种问题。

　　如果处理得好，在一个长周期项目内(例如半年或者一年)，如果能够提前识别这些需求，纳入规划开发响应，那么最终项目验收的时候这些问题也就比较顺利地得到解决。

　　第三种是用户应用后产生一些新的业务思想，希望也通过计算机加以解决，这些业务需求可能包含很有预见的需求，也可能是灵光一现，也可能是将其它系统需求要求我们系统也加以实现。

　　这类需求对内我们可以反馈给公司相关规划人员去合理讨论，但坚决不能给用户任何承诺，超出合同边界的需求在一个项目中是绝对不可以轻易响应的，否则开个一个口子，就无法拒绝用户各种合理不合理，但都不在本项目边界内的需求，项目也就越做越长，无法收场。

　　这种需求最简单的方法是以合同为准，按合同办事。

　　比较好的处理流程如下：

　　a) 先要详细搞清楚用户业务需求到底是什么，核心要解决的问题是什么？很多用户表达的问题和要解决的手段往往是分离的，我们不要把解决问题的手段和问题混淆在一起，另外有时候要解决的问题是因为另一个问题不方便造成的，要先分析清楚；

　　b) 和用户项目组沟通协调，确定问题的确存在，且需要解决，且能确定解决的需求；

　　c) 和项目经理沟通，判断该问题是否在方案价值点覆盖范围内，而且影响主导业务正常运行，如果是提交需求建议和缺陷报告给公司规划评审；如果不是先要和用户沟通，看其是否愿意作为后续合作内容，或者另外追加费用解决，不和本项目目标混淆在一起；

　　d) 如果用户坚持要开发，要及时向公司汇报，并坚决执行公司意志。

　　8.2.7 做人不好

　　有的项目存在严重人员沟通问题，用户对我们不放心，宁可把我们关在现场不回来，生怕我们走了不再来了。

　　这种原因就是实施人员没有建立足够诚信，往往是一个阶段工作没有做完，没有确定到应完成的里程碑点，就不得不做其它工作，甚至就是不够认真负责，敷衍了事。

　　用户听信实施人员下次来解决问题的承诺回家，结果实施人员在多个项目现场奔波中并没有投入精力解决软件问题，或者促进公司解决问题，下次不得不被迫过来又没有真正解决问题，用户并不满意。

　　有的时候调度周转不灵，版本发布推迟，用户不能看到我们按计划兑现承诺，也会不相信我们的工作，采取要求派人现场长期遵点解决的要求。

　　其实如果问题不能解决，遵点是没有用的，如果问题能够解决，往往是双方沟通协调后在软件公司先解决然后再到现场解决的，软件公司资源一般都很紧张，将人压在现场，几乎让自己问题陷入无人催动的境地。

　　所以我们一定要做好最坏的打算，和用户慎重承诺，说到做到，有问题全力保障问题及时解决，给用户两个印象，第一我们很认真守信，第二我们时间珍贵，我们每次只能解决关键问题，实施还是靠用户自己解决。

8.3 现场推广工作如何才能做好？(连载五十四)

作好现场推广工作关键在于前期各项工作质量。

　　8.3.1 第一要组织高质量的业务调研

　　业务调研阶段在产品比较熟悉的情况下，可以边调研边建立原型测试，这样在现场调研时对可推广业务设计和验证，构思业务流程操作手册，数据规范手册和各种样例，到了真正推广的时候思路早就经过反复推敲，非常可靠；

　　8.3.2 第二要对关键用户组织成功的培训

　　培训就是让用户自我进行推广，我们软件公司协助配合，要相信用户的积极性，主动性和能力，要不断激发他们在这些方面的潜力。

　　a) 从一开始到现场工作就要反复安排大量精心组织的培训活动，让用户理解我们的思路；

　　b) 项目解决方案或思路一定要组织各种类型会议在现场反复讲解，达成一致，非常关键问题不要回避或模糊化，例如产品管理的思路。但一些技术细节可以淡化，例如表格格式或者汇总时一些小要求，不要纠缠这些细节；

　　c) 培训的时候在操作上应该准备实例化的内容，应该让主导用户操作后自我评价掌握程度，直到熟悉为止；

　　d) 培训思路站在业务流的高度规划，让用户相信你对他们业务理解和描述非常准确到位，打消用户顾虑忧。

　　8.3.3 第三要提前做充分的内部业务验证

　　内部业务验证一定要自己亲手测试，而不是等测试部门结论。

　　因为我们通过业务验证推导我们业务流程实施思路是否可行的过程，这个工作别人是无法取代的。

　　测试部门只能按照功能验证，不能按照业务验证，可能有一些业务上操作瓶颈无法覆盖，但我们到现场用户一定会发现，因此造成用户满意度下降，进而要返工开发，导致公司管理成本上升。

　　而且验证过程中我们要发现软件是否有易用性，性能和功能上问题，要尽快提供给公司相关部门，直到寻求到替代解决方案或者列入可接受的版本实现计划中，这样才能保证在现场出现任何我们心中有数，即使是承诺可实现周期也比较有底，不会乱跳水。

　　此外作为项目经理和实施工程师必须对自己拿到现场实施产品功能了如指掌才能说是在业务上合格，不可能想象一个对新功能，新版本不熟悉的人去现场指导用户实施；这个只能通过内部验证来保证操作熟练程度，以及准备新功能培训教材和升级数据等相关指导教材。

　　在内部验证不是要让产品没有缺陷才能去现场，而是通过自己验证充分评估产品对主要业务线的支持程度，有多少是可以通过沟通克服的，有多少是无法克服的，必须解决后才能去现场的，有多少是必须解决但可以暂时忍受的。并及时和规划开发沟通，达成一致的解决意见，才有面对用户的智慧。

　　最终做到在现场用户发现缺陷之前，我们心中有底，有对策，有替代方案，可以承诺用户我们大致解决时间，并按时间兑现，进而建立用户对我们来现场工作的期待感和信任感，而不是抱怨我们拿着有问题的版本来，只会引发新的麻烦，进而导致项目失控。

　　8.3.4 第四要做现场验证。

　　现场验证就是让用户项目组充分评估新版本的好处和不足之处，确定是否升级，一旦升级出现用户不满就可以事先采取对策克服，而不是到处救火；

　　如果验证结论是不能满足要求，就千万别到处装机推广，那是自寻死路，宁可回去改好再来，也不能强行压。

　　现场验证过程也就完成对用户的培训，让用户项目组承担起实施责任，软件功能是否满足要求是软件商的责任，通过验证实施就是用户的责任，这个工作要做得好还需要建立和用户项目组充分信任的关系。

　　所以现场验证要做好推广风险评估，提前采取对策，此外要找到用户实施推动人，协助他们推广项目，最后验证通过给领导汇报，取得支持，召开项目推广启动会，这个时候再进行推广工作就很容易了。

　　8.3.5 选择适当的推广边界

　　一般情况下推广应用要考虑解决完一个业务环节再往下走，把繁复的企业业务化整为零，设计为相对完整的几个部分，一个部分一个部分实现。

　　而且每个部分一定要有一个清晰效益牵引或做愿景，这样大家才有跟随实施的信心和热情，并在一个台阶达到以后，再上一个台阶，逐步扩大应用范围，每个阶段实施难度实际上就降低了。

　　记住：只要某个业务流用起来了，往往就可以验收了，此时项目推广内容和合同边界未必等同。

　　8.3.6 建立和用户的个人友情

　　为了推广顺利实施人员也可以和用户一起吃饭娱乐，增进感情，也是有效的团队建立策略。

　　当然建立友情未必就是靠请客吃饭造就的，请客吃饭一般不会建立深厚的友情，友情是项目中同甘共苦中建立的。

9.1 验收工作应如何组织？(连载五十五)

实施项目最快乐的事情就是项目验收，可是经常是没完没了的信息化，不见不散的项目组，验收之路何其漫漫。

　　我在整个项目经理技巧中都反复强调任何工作达到成效，并不在一时一地事情做到位，而是在平时工作积累中将事情细节做完善，做到位，很多想要的结果就自然达到了。

　　项目验收就是我们最想要达到的结果，一旦项目验收对很多人还意味着一件现实的事情就是，我们可以回款了，可以获得项目提成收入了，同样项目验收也是一系列细致工作完成到位的结果，而不是某个点的成功或者个人能力就可以促成的事情。一个项目的验收，未必是一次性活动，而是由一系列验收准备工作组成的，在最终验收之前，我们已经将很多阶段工作细化并得到认可执行，项目验收就是一个水到渠成的事情。

　　下面我们就一起讨论一下如何进行项目验收。

　　9.1.1 项目验收的条件

　　很多人会奇怪，这个问题还需要谈吗，肯定是按照合同和技术协议验收。

　　其实在业内目前项目合同和技术协议现状是一个项目，不管金额大小，个性化开发多少，软件功能模块，几乎是一个不少，用户要求我们承诺的服务内容也是一个不少，供应商在竞争压力下的营销过渡承诺很难完全避免杜绝，如果要以完成合同和技术协议为标准进行验收，业内的大部分项目个人以为达到预期要求的可能非常之少。

　　当然这和技术协议架构方式有关，一般最开始技术协议只谈服务内容和实现目标，很笼统，结果在实施过程中很容易出现业务需求爆炸的情况，软件商难以应付。

　　这种情况下软件商就开始逐步细化产品功能点，按功能点确定软件细节，只要功能点满足，理论上就应该满足用户业务需要，用户就应该验收，至于业务能否运行，更多的是用户的责任，这里面更多的体现了软件商的自我保护。

　　实际运做时无论技术协议多细致，对用户而言根本没有太大的参考价值，用户只会考虑其业务是否真的在运做，并以此作为检验我们项目是否可以验收的标准，当然有的项目可以通过商务运做，在业务实现不太好的情况下也能验收。

　　所以现在一般的模式管理软件项目是按照服务内容分几个业务目标，完成一个业务目标就完成一阶段验收，收取一部分实施费用。

　　所以项目验收的最小条件是一个或某几个基本业务面能够开始大面积的应用。

　　这些基本业务面是不是很简单，或者是不是很稳定，或者人员是不是一定全部都上线，或者业务面上功能是否存在可改进功能都不一定，但只要用户看到这些基本业务面可以运行并承认这个可预期的结果就可以了。

　9.1.2 确定里程碑

　　我们现在知道如果要真做好一个项目，完成项目验收条件，是以业务是否可用为考量角度。不是一定得实现所有用户的需求，也不是只有将一些所谓的技术难点解决用户就可以用起来并验收，而是我们可以完成一定的阶段应用业务目标。

　　所以要想成功验收，不是我们什么都承诺，什么技术问题都实现项目才能做好，而是和用户沟通，代表公司和用户就项目业务实施目标达成一致。

　　因此我们从进行业务调研的时候就要主动控制项目的业务边界，将一个一个业务流根据企业实际情况合理组织实施顺序，形成我们项目实施计划中的里程碑点，明确达到里程碑点的条件，并得到双方一致正式认可。

　　在中国管理软件售前工作和用户还无法建立长期合作关系，面对不是很成熟的用户和疯狂的竞争对手，我们在生存压力下可以先和用户建立合作关系，一旦能合作，就相对容易和用户建立信任关系，有了信任就可以慢慢教育用户，用户一旦理解很多事情的复杂性不是软件单方面可以控制的，反而会理性地和我们一起解决问题。

　　因此我们要相信用户是理性的，他一定会坐下来和我们一起谈：那到底怎样解决问题呢？最终可以达成合理的结果，然后我们全力去冲刺每个里程碑。

　　里程碑的好处第一是将复杂的业务目标分解为一系列简单的目标，即降低了难度，又使每个阶段实施重点突出，精力集中在一点上，自然可以更有效解决问题。第二里程碑界定目标包含了一个一个相对独立应用台阶，可以促进用户项目一个台阶一个台阶往上走，用户只要达到了一个里程碑，项目在这个业务实现台阶上就可以进入不可逆转的状态，不会走走停停，经常从头开始。

　　在具体项目中，这些里程碑内容都可以设计，在每个项目中成功设计里程碑的关键就是最小化项目边界，然后和用户高管和中层干部，甚至在某些项目上还要和基层达成一致。

　　我们控制边界的前提是我们自己要有可置换的因素，这就是用价值换边界。

　　我们必须在深刻了解用户业务基础上提出我们的业务目标，阐明项目价值所在，让用户接受业务目标，并按照这个业务目标去实施，而不是纠缠在有什么功能没有什么功能。

　　功能很重要，但考虑用功能如何支撑业务流程更重要。

　　所以一个人在项目中最大的力量往往源自对业务深刻而理性的把握。

　　成功项目验收的核心就是边界的确定。

　　没有双方高度达成一致的里程碑认可，也就是没有项目目标约定，没有目标约定的项目实施计划一定会经常变更内容、变更初始设定目标，导致计划不可控制，更谈不上验收。

　　很多人希望通过详细解决方案来定义项目要实现的内容和业务目标，这是很有必要的，但解决方案得到认可并非是通过用户审核就可以的结果，应该想办法让用户一起参与解决方案思路思考，变成用户自己推导出来的业务实施目标，未来才不容易变形。

　　因此我们建议在确定里程碑的时候和不同层面人员大量沟通目标，确定达成一致，在产品比较成熟的情况下，能否就项目边界达成一致是最关键的工作，一旦这个目标达成，就很容易制定计划执行和落实。

　　确定每个里程碑后续工作可以参考下面的标准流程。

9.1.3 主动沟通(连载五十六)

一般项目业务目标清晰后，就可以按照业务目标分解相应工作，逐步落实，在落实过程中有一个很重要的工作是很多实施人员会忽视的，就是主动沟通。

　　项目中一定要有沟通策略，和高管如何汇报工作进展，取得支持？和中层如何就业务目标不断确认，逐步清晰？和基层如何就项目应用操作模式达成一致，持续改进？都需要通过沟通反馈完成。

　　沟通的作用对于高管是让他们清楚我们一直按照项目目标前进，每个阶段工作进展是否顺利，影响项目正常运做原因是什么，需要哪些资源帮助。和高管沟通比较多的话，第一个好处高管经常听汇报就知道项目进展程度，可以安排反馈检查，看是否具备象我们所说进展，这样一旦认可了各个阶段目标后，最终要求高管签字结项也就顺理成章。

　　第二个会哭的孩子有奶吃，一把手工程核心就是高管支持项目运行，而做到这一点关键就是通过合理汇报让高管对一个逐步前进的工作进行业绩的承认，高管一旦认为某个事情比较容易成功了，反而容易追加资源保障完成，这就是信息化的：“马太效应”。

　　一个工作高管经常性不知道进展，怎么会支持呢？当然谁去汇报可以在项目中界定是企业还是我们软件实施商，但一定要和高管主动汇报。

　　给高管汇报技巧就是简洁明了，真实客观，有理有据分析问题，提出对策建议请其决策即可。

　　中层往往是项目主要的推动力量和实际执行者，也往往是对具体业务需求最主要要求者，他们对企业实际运做过程最清楚，提出要求最具体，而且项目验收与否没有中层的同意往往也是不太容易做到的。

　　要达到项目的目标没有中层的配合也是非常困难的，和中层的沟通往往是不断动态调整项目目标，逐步清晰化项目目标和细节的过程。

　　往往通过前期业务调研只能对企业项目目标有一个大的，宏观的认识，但如何细化并最终落实并非是一步到位的过程。因此在整个项目过程中，双方项目组要不断沟通，特别是企业中层沟通，才能逐步认识越来越深刻，最终达成一致。

　　和基层的沟通主要体现对最终用户的关怀，定期主动和最终用户沟通，消除一些怨气，让用户能坚持用下去，这个时候我们往往发现很多用户真的是非常可爱，尽管软件还有很多值得改进的地方，但他们一旦认可我们团队，反而会尽心尽力帮助我们推动。

　　个人以为一般在项目中要坚持每个月到一个半月写一份详尽《情况简报》，分别通报企业项目负责人，部门负责人，项目组成员。

　　《情况简报》应先发邮件，然后一定电话落实收到并口头简要汇报，特别是高管层，千万不要以为发了就等于别人会去看，一定要口头跟进汇报一次，保证企业各方面负责人对项目进展做到心中有数。

　　另外实施工程师无论是否在现场，保证每周至少和操作用户、系统管理员沟通一次，主动和用户接触，不要等到用户有问题再来找我们解决。

　　这样反而可以逐步释放用户一些火气，真要救火的时候我们反而有一些从容周转的时间，一回生，二回熟，到了验收的时候也好说话。

9.1.4 写好备忘录(连载五十七)

　在一个漫长项目周期中，很多工作做了也就做了，认可了也就认可了，时间一长也就忘记了很多承诺和约定，到了验收的时候就翻出来重新要，这种事情很多人可能都经历过，明明说得可以先不做的内容最终验收的时候又成了必要条件。

　　所以在一个项目中要顺利验收，一定要写好备忘录，把平时项目过程中重要阶段点双方达成的共识详细记录下来，以备查询。

　　项目组在每次现场工作都必须要写备忘录，备忘录必须注明现场工作天数，按时间段写清楚工作内容，性质和时间长度。

　　例如培训工作要写清楚培训人员名称，培训内容，培训小时数，培训掌握效果；

　　例如装机工作要写清楚装机软件，装机台数，是否可正常使用等等细节。

　　每次备忘录要口头交流认可后才打印签字确定阶段性工作成果。下次工作则根据前次备忘录的双方约定继续进行，保障项目在每次工作基础上不断前进，并用备忘录约束双方的行为。

　　备忘录标准的写法是先简要汇报阶段工作中内容，要用积极肯定性的文字给自己前一段工作或者一些提法给出正面结论，这样大家看了才有信心。

　　这个工作内容往往是上一阶段约定要解决的内容，而且在这次现场工作中得到解决的内容，要考虑和上一次备忘录约定工作内容的呼应，很多人写备忘录，纯粹是为了备忘而备忘，备忘录三大功能，第一是备忘，第二是缴功，第三是约定后续工作安排，推动事情继续前进。

　　所以写备忘录首先要讲上一次我们约定什么工作，这次是否完成，完成质量如何，没有完成是什么原因造成的，是否纳入下一次解决的内容，这样的文档才有体系，也能体现出一个人整个项目过程中的脉络，否则写这么多备忘有什么用？

　　结论出来后后备忘录要详细描述自己所做工作细节，细节越详细越好，让项目组彼此认可工作内容和质量，而且对服务工作量可以有一个客观的评估。

　　而且在写备忘录时发现自己大量时间并非在有效沟通或者在推动项目实施上，那么意味着项目已经是在失去控制路上，应该立即引起警觉并采取措施解决。

　　备忘录最后还要约定下一阶段双方工作安排，在后续工作中严格按照备忘录设计自己的工作计划，了解企业项目组进展，如果企业项目组方面配合出现问题，在下次备忘录中要明确指出责任承担方，给用户形成一定的压力，从而更好推动项目走向前进。

　　一些重要的项目目标约定或者验收意见可以单独写备忘录，在最终验收时可以作为依据。

　　这样一个备忘录一个脚印推动项目向目标前进，每个备忘录都在前一阶段工作上有一点点进步，最终项目验收就是水到渠成的事情。

　　除了实施备忘录外，实施人员最好给每天工作做详细记录，实施备忘录个人认为只是一个工作进度大概描述，而且可能会有水分，因而需要有一个每天工作的详细记录用于自己或者团队成员准确把握项目脉搏，及时发现问题，个人也能随时做项目回顾，用户的反复也能随时记录在案，如果出现项目延误，也能有理有节和用户应对。

　　9.1.5 精心准备一次成功的汇报

　　如果项目准备验收了，一般要安排一次验收鉴定，这个鉴定可能是要请专家来看，可能是企业内部组织，也可能就是几个人认可签字即可。

　　因此如果要验收，最后鉴定这个工作质量要高。

　　要准备好一套模拟现场环境的演示环境，要有足够真实的数据，要设计一套体现应用特色介绍流程，要准备一套详实汇报材料和相应PPT。

　　要保证验收大会顺利通过，其实是在验收大会前将相关汇报工作和现场应用情况和企业领导做过汇报，并得到充分认可。

9.1.6 平时做人的积累

　　对于项目一个实施人员要为公司考虑节约成本，同时也兼顾客户利益，是比较难以决策的。

　　特别是在一个多可能同时负责多个项目的时候，想每个项目都应该全力以赴是很困难的。这样难免让用户觉得我们响应不及时，有问题不解决，特别有些问题不是我们一个个体能够解决的，长期下来用户可能会积累很多的怨气。

　　因此实施人员平时做人要讲诚信，讲原则，无非是三条：

　　做不到的事情千万别随意承诺；

　　承诺的事情一定要努力做到；

　　每次做到的事情都进步一点点。

　　有这三条用户会慢慢接受稍微长一点的响应周期，也会用更多积极性眼光看现在的问题，也相信问题一定有人响应，也一定可以得到解决。

　　我们很多人做项目遇到困难在公司内部没有想尽办法去解决，认为我自己这么努力，承受这么大的压力，而别的同事好象没有什么压力，心理不平衡，就容易回避放弃。拖，拖，拖，拖到无法再拖的时候在用户那里就没法抬头，只能被动挨打。

　　如果按照以上三条原则做事，反而简单，不做做不到的，当然这个做到做不到不是个人判断，而是和公司内部协调达成一致后的意见，做得到的一定按承诺做好，项目就会简单。

　　实施过程中可以留一手，有些好功能或者便利的地方，可以不全部告诉用户，毕竟在合同边界中没有涉及，在验收前可以作为条件和用户去置换。

　　9.2 如何催款？

　　首先要主动提出回款要求，这是很多实施人员最难做到的一点，不知道如何开口，担心开口后被动。

　　其实要钱这个事情最难的就是开口要，开口要了就简单了，为公司催款是天经地意的事情，你是在为公司生存催款，也是为了有钱才能提供更好的服务，要理直气壮的去要钱。

　　就象很多人催别人还自己借给他的钱一样，难就难在自己的心理顾虑上。

　　不管项目实施地好不好，一开头要钱，用户马上就会提出不合适，这个时候我们要趁机了解，现在不合适，具备什么条件就是合适？立即和用户约定回款条件，有了回款条件，等于给自己清晰约定了双方工作目标，那么这个回款条件马上写进备忘录，达成一致意见。

　　所以项目中只要觉得具备一定条件，就要主动提出验收，验收速度取决于对验收目标是否达成一致。

　　不断提出验收要求，就可以不断就项目目标进行清晰定位，反复三次后，验收目标就清楚了，这个时候双方项目组就该解决的问题就尽快解决，不能解决的就想办法，例如进行价值置换，或者追加资源投入，或者紧急开发，或者变更合同等等。

　　回款条件也不要立即写成备忘录，先不断提出各种可行回款条件，，逐步选择最合理的条件以加深印象，并不断利用各种汇报的机会 明确，最终写到备忘录中成为未来验收工作开展依据文件。

　　一旦目标一致清晰后，实施团队要全力保障回款条件实现，一旦达到回款条件，还别忘了请商务人员做去商务工作，个人也不是万能的，搞技术的可以催钱，但不要去要钱。

10.1 如何做项目团队管理之前言(连载五十八)

入行五年，做了一些项目，现在最大的体会发现目前整个管理信息化实施尽管每家公司都提供了很多方法去指导，提供了很多流程去约束，但效果不大。

　　为什么呢？因为管理软件实施需要一个人在四个方面都必须很强才能顺利推动，这四个方面是企业业务，管理理念，软件功能，人际沟通。实际上一个好的实施人员必须是一个能力非常强的知识复合型，精通项目管理技巧的人才。

　　在产品基本成熟后，一个成功的项目是靠个人能力去保障的，流程和方法论只能给有潜力的人行动启发，而不是指南。这就是目前的现状。

　　而这种人才的获得是非常偶然或者是需要长时间积累的，但整个IT行业是一个年轻人的事业，大量不足30岁又没有多少行业经验的人活跃在一线，项目服务整体质量不高在所难免。

　　IT人注定是奔波劳碌命，一个现场赶往另一个现场的奔波中，知识的更新和积累非常缓慢，不如说是吃老本更合适，而IT公司为了应付用户需求也是招架不及，成本难以控制，更不可能在业务培训上下功夫，结果就是一大批有潜力不职业的实施人员在IT业浪费了青春。

　　通过高薪吸引高水平的项目管理型人才或实施人员进入IT管理软件实施工作，其实是一个伪命题。毫无疑问当前一个具备以上技能的人员在IT业可以获得的回报是远远少于其它行业，是不可能吸引多少人才加盟的，可能每家公司都有一些高人，与其说是为利益最大化，不如说是和爱好重叠，在工作中有乐趣。

　　但一个公司高人是有限的，不可能让这个高人去应付所有的工作，否则这个高人只能给每个项目一点点精力，还不如一个花费大量精力在某个项目上的能力低一点的人的效果。我们在高度竞争的情况下，不太可能引进高人去实施，成本无法承受，也不能让一个高人去面对所有的项目，让高人崩溃。

　　根据我的观察业内很多忙人，共同的特点是售前售后一肩挑，几乎是一个突发事件跟一个突发事件，没有喘气的机会，最终的结果只能是黯然引退。

　　所以解决这个矛盾必须寻求另外的出路。

　　我个人的建议是，公司第一要做好知识管理，并通过IT产品为核心整理自己的知识，将对企业业务和管理理念支持通过连贯的功能体现在产品中，并形成售前售后一致的标准实施和演示方案，并不断完善。

　　此外就是建立项目团队，通过团队能力组合去弥补个人能力不足，在团队中建立学习型文化，通过亲自示范传递很多软能力技巧，也许是目前摆脱困境的办法。

10.2 好的项目团队构建要求

　　一个好的项目团队绝对不是一种性格一种单一能力的人的组合。任何一个人想做项目经理，实际上从一开始就要考虑如何构造你的项目团队。这些考虑包括如何建立实施能力的合集，形成共同的价值观和行为模式等方面。

　　项目经理在建立项目团队时容易发生两种误区，第一要求别人有团队精神；第二是指望别人有为项目目标牺牲自己时间的精神。

　　这样建立团队只能说是期望值过高，最终团队很难一起长期合作。

　　个人有没有团队精神不是关键，而是你建立的团队对不同的人是否有包容精神，发挥他们的长处，抑制他们的短处。

　　要做到这点就是通过合理的利益机制去保障，不要指望用什么精神力量去长期维护一个团队的斗志。

　　要知道很少有能在半年内结束的管理软件项目，所以也不要指望个人一开始就愿意为了项目成功去牺牲自己的利益。

　　个人认为建立好的团队把握住两个方面就容易，第一是团队成员价值观接近；第二是团队具有合理的利益分配机制。

　　一个能成功合作的团队最好的方式是选择具备同样价值观的人加入团队。

　　国内项目很难做好的一个重要原因就是信息化长期艰巨性和企业需要立竿见影的效益之间的矛盾。

　　这个时候无论个人能力多么强，恐怕都无法立即满足很多用户的期望值，因此团队必须要有长期抗战的心理准备，这个时候肯承担责任的人非常适合加入团队。

　　作为一个管理软件实施项目，一定要选择那些有耐心，有韧劲，有担待的人去负责项目，这样的人才能把项目做好。

　　因为一个人肯担责任，就会努力去解决问题，在解决问题过程中其技能一定会在很短时间内得到很大提高，这个人业务能力怎么样是可以解决的问题。

　　但一个人不肯承担责任，不肯努力解决问题，问题就永远停留在原处不被解决，即使开始技能不错，后来也不能适应项目需要。

很多项目往往因人而成，因人而废。这个现实告诉我们很多时候我们必须花费足够精力去选择这样的人。个人认为现在中国这么大，选择40~50个认同这样价值观，对待遇要求也可以接受的人员一定有，只是我们没有去发现，总是通过一大堆其它条件去选择人员有关。

　　例如我们总是要求一个实施人员有计算机软硬件知识，良好制造业背景，对信息化管理软件实施有深刻认识，对软件功能熟练掌握。

　　这些都是对人硬能力硬指标的要求，但是无法衡量一个人的软能力，而在项目实施中软能力是最重要的。所以我们在选择成员的时候要和人力资源部门有力协调，不要选择大量硬指标的人，第一是难找，第二是不好管理，难以协调一致和产生认同感。软能力的衡量要考虑最大方面就是价值观，而不是现成的业务技能。

　　根据个人观察，能够快速在项目中独立担负责任的人，从一开始他对这个行业一无所知到可以独立完成任务，在有人指点的情况下一般只需要半年，甚至更短。

　　所以完全不必担心这些新员工能否成长，而是应该担心新员工能否得到良好的指点。

　　选择好团队人员只是一个开始，一个团队一起协同工作一定是可以通过工作获得相应的回报，这个回报一定要有一个大家认可的合理分配机制。没有这个合理的机制，团队也会因为失去激励和公平而人心涣散。

　　做到合理的分配机制在项目控制过程中非常难，因为国内同样规模和难度的项目，有的企业金额80万，有的企业40万，甚至有20万，软件公司为了解除现金流压力，最后都会承诺去做。这些项目要做好都需要消耗同样的项目人力资源。

　　如果一个人做了一个80万的项目，一个人做40万的项目，可能工作量差不多，但项目提成收入可能差距就是一倍。这个问题也就是存在所谓“肥单瘦单”的说法。

　　即使两个人做的同样是40万的项目，项目复杂程度可能差别很大，工作量差距也是好几倍，提成收入又差不多。

　　就算是两个项目金额复杂程度差不多，付款条件不一样也会对可预期收入产生直接影响。根据不同公司的政策往往实施人员更乐意或者不乐意选择首期款比例高的项目。

　　还有一种常见情况，一个项目大家一起做才能完成，两个人在项目中花费工作量不一样，解决问题难度也不一样，这个时候如何平衡两个人的提成收入分配也很关键。

　　开始合作的时候大家往往比较容易齐心协力解决问题，但如果到了利益分配的时候大家觉得受到不公平待遇，估计你的团队也就开始瓦解。

　　解决这个问题的办法我觉得很难，从两个方面入手也许容易做一点，一是在团队内公平透明，优先奖励符合我们价值导向的人，第二是必须认识到这个是一个项目经理管理团队最需要花费精力的地方，必须保证时间去思考和解决这个问题。我们中国人一不缺智商，二不缺情商，但比较缺钱商，孟子说：民不患寡而患不匀，大概是我们可以参考的一个思路。

　　实际上我认为建立一个实施团队不要照搬那些管理理论的理想描述去做，关键就是这两个问题，有没有一致的人，有没有合理的分配机制。

10.3 好团队的两个特征(连载五十九)

一个好的团队一定是分工明确的团队。

　　很多IT管理软件项目，要么是一堆人泡现场，要么是孤胆英雄。

　　因为遇到事情的时候用户的感觉是没有人真的去负责，这就说明在项目中没有真正的项目经理，

　　这就是在一个团队中没有明确谁对项目负责，如何负责，技术问题谁负责，商务问题谁负责，管理问题谁负责，到了真有事情，每个环节都忙，但响应和处理效率并不高。

　　实际上用户愿意选择能够解决问题的人，而且愿意解决问题的人合作。但这个人往往是项目经理，因为项目经理一般实战经验丰富，技能不错，而且对项目最终负责，压力最大，结果项目经理就成为这样的人。但项目经理一般要负责多个项目，每个用户都喜欢他，他很快就在多个项目中变成每个用户都不喜欢的人，这就象一个人的情人不能太多，太多也难应付。

　　所以合理分工的原则是帮助项目经理充分发挥自己价值，让团队成员能力能充分体现。一般项目经理应该强在对企业业务把握能力，能快速发现项目的价值点，进而通过良好的沟通技巧在团队内和用户处就项目目标达成一致，并形成可执行的后续计划。

　　这也就是所谓计划，组织，控制三步曲。

　　项目经理不应该让用户认为是一个技术很强的人，当然项目经理技术可以很强，否则用户会不认可实施人员的能力，反过来要求项目经理到位，而团队成员技术能力也会因为没有足够实践机会而成长缓慢。

　　不能成功让用户接受自己团队成员能力的项目经理，注定是疲累不堪和失败的项目经理。

　　此外项目经理技术性比较强，而且在管理软件实施过程中要带一些顾问的性质，这样的角色最好不要和回款直接挂钩，可以出面提醒用户按期支付款项，但不应该直接去要钱，这些工作应该通过商务经理完成。一个人上来谈目标，下来谈收钱，会给用户一种不真实的感觉，是否你为了回款而设置比较低的目标？

　　所以一般在一个团队中应该有项目经理，实施经理，客户经理三种角色。

　　项目经理，项目经理最大的作用是控制项目边界，代表项目组和用户就项目目标达成一致，然后组织资源保障项目得以实现。项目经理要保证为了达到预定时间内的目标，可以配置资源和时间去完成这件事情，而不是到处救火，亲自去解决问题。

　　实施经理主要是从技术上保障项目顺利运行的配置实现，并保证让用户可以独立应用并推广软件，在积累一定经验后可以独立完成解决方案编写和产品完整演示。

　　客户经理是当项目达到合同约定条件时，负责催款和回款相关的商务工作。

　　个人认为实施经理和项目经理最大区别不就在于一个同时只能搞定一两个项目，项目经理可以同时搞定5~6个项目。

项目中三种角色缺一不可，每个角色在自己能力范围内发挥作用，互相协调配合一致非常重要。而且项目经理要让用户清晰知道遇到何种问题可以如何和我们项目组联系，我们会如何解决，大概需要多长的时间。

　　这样的团队最大的问题是是否遵守同样的行动规则，也可以理解为对外是否具有一致性。这也是一个好团队的特征。

　　有的项目商务经理为了便于回款或者签单，容易过度承诺，给后期实施制造极大障碍，有的实施人员在现场发现一些新的问题，容易犯个人英雄主义，自己去承诺解决，但并不先和项目经理沟通，有的实施人员如果不是特别安排，基本上不会去主动和用户交流，有的实施人员几乎每天都和用户电话联系，有的项目经理经常和用户联系，实施人员反而不去联系，这些都是行动规则不一致的表现。

　　在一个团队是否遵守同样的行动规则，首先是价值观一致。

　　例如我们是否都认为如果用户现场出现各种问题，我们应该先全力促进解决问题，再来谈问题的责任，而不是一开始就说这不是我的错，这个不归我管？

　　我们是否认为为了让用户满意我们必须随时准备牺牲自己的时间和精力？

　　这些都是很重要的问题。

　　第二是养成事先沟通的习惯。不要自己去决定所有的事情，也许你的决定没有错，比别人去做也会效果更好，但是在没有得到明确授权范围内的事情，一定要先在内部达成一致后行动，否则容易出现做了别人也不领情的情况。

　　很多事情也很难一开始就形成规范或者文件指导，但只要我们清楚这些事情应该先内部达成一致，总是有办法，对于一些规律性的东西就慢慢形成惯例，可以减少沟通的成本，这也就是所谓团队默契的形成。

　　第三是每个人的沟通频率在一个项目中各个阶段保持一致，关键沟通信息应互相清楚，不同角色沟通频率节奏要合理搭配。

　　第四是对项目边界和不同角色责任承诺对用户说法要一致，这个是通过内部沟通达成一致后要和用户明确的。

　　10.4 如何看待项目经理在团队中作用

　　IT业流动率高，做实施的流动率相对开发可能更高一些，一个项目最怕中途换人，但这种情况在业内非常常见，用户非常担心自己的项目出现这种情况，往往要求在合同前期指定项目实施人员，这是一种无奈也无用的做法。

　　所以软件公司应该将自己业务上比较优秀的人提拔出来，给予项目经理的职责，培养其管理意识，而不仅仅是技术意识，给个人比较大的成长空间和较好的待遇，这样有利于核心员工的稳定，再由核心员工带领团队去做一个项目，这样项目因为人员流失造成项目中断的风险就最低。

　　所以对于公司而言项目经理不能是一个一般性岗位，是一个具备能力核心员工才能担任的岗位，这个岗位能让核心员工在比较长时间内稳定开展工作，并通过项目经理带领团队实施，促进团队能力提升，保持团队队伍稳定。这对于一个项目可能是非常重要的一点。

　　从项目实施角度来看努力去负责一件项目是很不容易的事情，特别是这种管理软件实施，所以一个项目团队中必须有一个项目经理。

　　项目经理就是无论是其责任心还是职责规定都是那种寻找努力促进事情发生，从不轻易放弃的人。

　　项目经理是一个团队的精神领袖，他的言行直接对团队起到一种示范作用。

　　一般认为项目经理未必一定是一个团队的技术领袖，但实际在目前国内要想成功控制管理软件项目项目经理至少得是一个业务精通者。

　　一个对企业业务不熟悉，对管理软件不熟悉的人担任项目经理更大的可能是造成一场灾难，尽管也许他具备很好的项目控制能力。

　　总之项目经理要成为一个让用户和团队成员都信任和放心的人，这种精神领袖的地位是靠项目经理能力和个人魅力逐步得到大家认可后在一个集体中放大和加强的。

10.5 团队建设心得和误区(连载六十)

10.5.1 加强沟通保持一致

 

　　项目管理强调团队达成一致再行动，但达成一致的关键是先在内部广泛达成一致，再对外沟通。

 

　　这个原则有两点在操作中很容易出现问题的地方，第一是项目经理事无巨细都需要了解和沟通，协商成本太高，导致沟通效率很低。

 

　　内部沟通非常必要，但也没有必要事事沟通，反而打击团队成员工作积极性。项目经理应该实现和团队成员约定不同类型事件沟通方式和频率，保护团队成员工作主动性，同时保障项目始终受控。

 

　　第二项目经理自认为能力很强，按照一些项目管理理论说法项目经理先和客户达成一致目标，然后协调资源完成目标，内部资源不听调度就非常恼火。

 

　　现在一个出色的项目经理一般都无法专心做一个项目，所以项目中主要实施工作还是要依赖其它团队成员完成，因此在一个团队中对于软件实施有不同认识和意见是很正常的，项目经理一定要先多花一些时间在内部沟通，千万不要以为内部一致性很容易达成。

 

　　我们员工更习惯的思维模式是既然你都已经决定了，我照你的做就是，还问我意见干什么？如果员工觉得项目经理思路不对，他们可能不是优先考虑执行，而是想证明自己是对的，这也是知识型员工的特色。所以宁可先多花一些时间告诉项目经理自己的判断，最后和用户会谈达成的结论会比较顺利地传递成为团队共同认识。

 

　　10.5.2 参与和顾问式领导方式

 

　　很多项目管理书籍告诉我们领导有方的项目经理从来不教人如何工作，由项目成员自己决定怎样完成任务。

 

　　我个人认为项目经理工作恰恰是要给新员工示范正确的做事方式，只要条件许可，还要亲自示范，在项目需要受控的时候多一点独断专行，少一点成员自由发挥是非常重要的事情。

 

　　项目经理的示范只需要一次，通过示范让项目成员感觉到正确的做事方式可以有效达到目的，这也是项目经理建立权威的自然时机。

 

　　在中国缺少职业教育的高学历人群比比皆是，如果相信这些拥有高智商的人能够顺利完成工作就大错特错，高学历的人把很多简单的事情搞得无比复杂的情况到处都是，很多人自以为是，自作聪明，最后还是要别人去开屁股。

 

　　也许在国内项目经理不需要过于精细的管理，但在国内不能确定团队成员工作方式和能力之前，项目经理还是要多做示范，保证团队成员工作方式是按照基本的职业方式进行后才能让他们自主发挥。

 

　　10.5.3 控制过程还是目标管理

 

　　很多管理理论总是强调不要仅仅重视结果，要注意过程，没有过程质量的保障，最终的结果输出也是偶然的，不可靠的。

 

　　这个理论一点都没错，不过问题是实际上项目经理在过程控制上花费的时间越多，花费的精力越大，项目反而越难以控制。

 

　　因为管理软件实施对人的综合能力要求太高，当一个人的能力还不能达到业务要求的标准的时候，最需要的是培训和示范，而不是责问为什么你的工作不到位？

 

　　就象本人写前八章一样，能够把这些事情正确执行方法知道的人都不多，有实际经验的人更少，对能力不足的人去控制过程，还有控制的必要吗？

 

　　这个时候最重要的是建立业务规范，在业务规范大家有能力执行的情况下，再去考察业务规范符合度，加强过程控制才有效。

 

　　我们很多软件企业不断强调自己的流程和方法论，但员工经常流失，很多新员工在现场工作的时候，什么方法论都不管用，他们充满恐惧的想：我到底该做什么，我该什么做。

 

　　过于强调过程管理最大的一个体现就是汇报多，层次复杂，增加了很多管理活动，但又看不出这些管理活动的价值。结果是很容易重复汇报或者多头汇报。口头汇报完成的工作还要书面汇报，日常汇报过的工作还要专门总结汇报，现场记录的工作还要单独汇报。

 

　　经常反复汇报在项目管理的理论中也有说明：这是打击团队士气的有效方法。

　本人建议汇报突出两点，坏消息先汇报，例如不能按照计划完成的工作要汇报，需要紧急协调资源的消息要汇报，这些随时发生，随时搞清楚原因，随时汇报，随时采取行动。

 

　　第二与其反复了解进展，不如提供清晰的目标管理。

 

　　也就是说项目经理接受和交代任务的时候，一定要清楚自己任务的范围，质量要求，进度要求。

 

　　对任务理解是否达成一致的最简单方法就是请任务接受人当场复述。任务接受人如果不清楚任务的内容，进度和质量要求，一定要问清楚才能去执行，如果不清楚怎么做，也要立即沟通请教，不能先好好好，回头告诉别人我搞不定。

 

　　本人曾经给一个员工布置一个修改方案的任务，电话里说了6点修改意见，问他清楚了吗，非常自信的回答，我知道了，放心。

 

　　本人很不放心的又问一句，给我复述一遍。很流利的说了四条，然后问我，哎呀，还有两条呢？

 

　　所以在接受任务的时候还要一个职业习惯：好记性不如烂笔头。

 

　　在国内目前项目实施水平现状下，个人以为目标管理，严格的目标考核机制远远比过程控制更能达到管理目的，只有当大面积的人可以按照目标完成项目的时候，过程管理才能发挥不可替代的优势。

 

　　10.5.4 信任团队成员

 

　　项目经理一般都是业务能手，很多时候看到项目成员做一些很简单工作都做不好，马上亲自动手，先搞定问题，否则项目耽误不起，但常此以往，项目经理就是眉毛胡子一把抓，活该累死。

 

　　项目经理要信任和授权成员独立完成任务，既然都在一个团队就要用人不疑，疑人不用。坚决大胆要求团队成员努力学习独立掌控局面，项目经理逐步演变为对目标进度的控制者。

 

　　当然这个时候项目经理要加强对员工工作的指导，但项目成员往往分布在不同的现场，项目经理要结合不同项目拜访计划的时机采用走动式管理。在现场不断并亲自验证成员的工作方式，立即指正和改进，加以示范。

 

　　信任不是放任自流，以信任的名义对团队成员的工作放任自流是项目经理失职和偷懒。

 

　　而且项目经理要时时考虑让让用户成为团队中的一份子，从一开始就全力培训用户是减少实施成本的最有效方式。

 

　　团队成员一个比较共性的问题就是：很多人会问没有资源没有人我怎么开展工作。这样的团队成员可能会辜负项目经理的信任。

 

　　这是很大的一个误区，一个人有能力的表现就是能做别人认为很难做到的事情，如果事事有资源你才能把工作做好能说明什么？这种事情谁都能做。

 

　　而实施工作就是在各种缝隙里寻求合理的答案，项目经理在信任团队成员的时候也要让团队成员建立承受压力，迎接挑战的心态，也就是所谓情商吧。

 

　　10.5.5 建立向上的团队文化

 

　　项目经理一般都是个性很强的人，不太可能用同样的方式约束项目经理的做事方法，当然越是成功的项目经理，行事方法越具有共性。

 

　　而项目团队成员和项目经理的互相认同对一个团队成长非常重要，也是工作能否快速进展的关键。

 

　　项目经理要及时认可成员工作，随时用进展鼓舞团队士气。对很多人而言，物质奖励的预期是很清楚的一件事情，国内的项目经理一般也没有多大空间去对项目成员工作进行物质奖励，因此在这样的边界条件下我们更要寻求利益机制以外的团队合作方式。