超越对手——软件项目经理的18种实用技能.docx

精品齐鲁行业资料 欢迎下载 赵鲁宾编辑介绍公司有三点一定要讲到：业务讲到：要让客户清楚我们能为您提供什么，做什么，如何合作。实力谈到：要让客户明白和我们合作为什么可以放心。案例说到：要让客户知道我们不是在说大话，有很多用户和我们一起取得了成功，并有案可查。 只有和客户建立长期多次接触机会才能创造机会了解客户需求，拥有可能让客户逐渐认可公司的实力和能力的机会。 越是要做大项目，越是要让别人觉得你是一个值得交的朋友，而不是一个销售经理，所以未必要急于马上或者长篇大论介绍公司，要巧妙用自己推销公司，用公司推销自己。 2 案例 小李好不容易争取到一个潜在客户同意见面的机会，客户在谈话过程中想请小李介绍一下了解他们公司是做什么软件的，能解决什么问题。小李觉得这是一个激发客户购买兴趣的机会，就请允许客户给他10分钟时间，他借机把公司和产品做了全面介绍，结果滔滔不绝讲了20分钟，最后留下一份精美公司数据给客户。请问小李这样做对吗？ 点评： 象上例的小李可以在客户提出介绍要求时先感谢客户的关注，再用很简短时间（23分钟）介绍公司和产品，主要是说明企业有哪方面的业务问题是可以考虑上我们的软件系统，这个过程中最重要的是判断客户这里是否存在项目机会（预算），如果有项目则应该考虑建议客户安排时间做更长的交流或者业务沟通的机会，在客户不愿意配合的情况下必须制造再次接触的理由。例如这次故意送一份简单的数据，下次再送一份更精美的公司资料上门创造更多接触机会。 如果没有项目就和客户约定保持良性沟通方式，确保客户想上项目的时候想起通知我们的公司就可以了，不应该耽误客户太多时间，更没必要发送精美公司介绍材料浪费成本；除非客户真有兴趣，业务人员恰好也有多余时间，那可以多谈一谈，更深入了解情况。 2 案例 小李开始一个正式介绍时，才讲了五分钟，客户有人打断他的发言，说我们想看一些实际的内容，公司介绍还有一些虚的概念理念就不要讲了，你演示下软件让我们看看怎样解决我们实际问题。请问小李这时该怎样做？ 点评： 如果事先有产品演示的准备，此时小李可马上表示：“我接受企业的意见，但与会还有人好象从来没有见过，因此请企业给我们五分钟用最短时间让我们介绍完公司，然后马上进入技术交流，好吗？”， 这样企业一般不会反对。 在这段介绍公司时间内注意讲要点和一些案例应用，同时快速根据大家对一些应用案例反应重新再组织一次自己产品演示思路。经过一个简短精练、着重强化公司专业地位的介绍后，配合的技术人员也可以很顺利地进入演示状态，效果自然很不错。 如果介绍前完全没有意识到客户会要求演示，并做好相应的预案准备，这次演示效果很难做到有效，只能尽量要求安排专门时间演示，强调这次约定的公司交流，不过可以先把产品简单沟通一下，留下转圜的伏笔。 此外也可以说管理软件是个系统，很难简单通过操作来演示，一般管理软件也是重点谈解决问题思路，而不进行具体接口操作，不过我们可以结合一些企业问题和案例介绍我们是如何做的，解决问题过程和方法是什么，大家觉得这样可以吗？ 整个过程重在不慌不忙，沉着有序应对，给客户一个专业沉稳的印象。 一般客户对软件公司是很好奇的，又不生产物质产品，很难和其产品线比较，因此没有什么考察经验可以参照。要通过介绍让用户留下深刻印象并不容易，在总部介绍公司有“三讲” 窍门。u 讲故事 不要呆板的介绍公司，而是要讲故创业事。例如我们谈公司人数可以请用户看老照片，结合老照片讲公司创业艰辛到发展壮大历程，边讲边和客户互动，看着老照片，听着软件人创业的故事，客户就容易从心理上接受这个朴实认真的公司了。u 讲特色 特色主要指软件管理和业务上的特点。 一般管理上特色是结合组织机构介绍进行的，要给客户生动介绍公司的组织机构，介绍人可以和企业采用比方的方法，讲软件研发部就和客户比方成企业的生产车间，到测试组就和客户比方成企业的质检车间，这样企业就很快明白组织结构的作用和价值了。 业务特点是请客户看软件研发工具，例如请他们看源代码管理工具，看安全保密工具，请他们看软件自动测试工具，这些是客户很少见到，但见到后又很容易认可软件公司规范可靠的细节管理，而且有新鲜感。u 讲文化 在给客户在公司做介绍，不仅仅要介绍公司经历和管理特色，还要通过这些内容突出我们公司文化价值观，形成和客户的共鸣。 售前调研的目的 让客户认为调研者有足够能力了解企业业务流程问题所在和设计解决之道。 要随时给竞争对手制造门坎，了解竞争对手给我们设计的门坎。 调研获得的信息足够让后续工作开展。 售前调研和售后调研的不同 售前调研一般是为产品演示，技术交流做准备，同时在调研过程要注意突出自己强项，给竞争对手制造门坎。 售后调研一般是为解决方案，项目实施做准备，同时调研过程中要注意寻求项目价值点，利用价值点置换项目边界，尽量把项目边界最小化，项目才容易受控和成功。 售前调研一般没有确定正式合作伙伴，客户不太愿意配合，也不愿意投入太多时间精力。 售后调研有合同和目标约束，企业一般会花大力气配合启动。 售前调研一般由商务和客户协商时机，商务人员根据实际情况和客户协商确定是否需要调研，是先交流再调研还是先调研再交流，是在竞争对手之前调研还是之后调研。 售后调研在合同签定后必须尽快启动，而且应该在项目启动大会前后趁热打铁展开调研。 售前调研一般由于时机难以把握，不可控制因素太多，往往突发性强，客户也无法有足够精力和供货商沟通，因此对工作计划性要求不高，即使有计划安排更多也是形式上意义。 售后调研用户比较关注过程规范性，对工作计划性要求比较严格。 售前调研一般要协助商务攻关，所以不能轻易在现场不慎重地发表对业务或技术问题倾向性看法，要深入了解事实，策略性表达对问题的认识。 售后调研可以相对直接提出问题，摆事实，陈厉害，争取最大范围重视，进而获得管理支持。 售前调研一般很难见到企业高层，接触形式有限，时间有限，也不可能获得管理层明示支持。 售后调研前一般要和企业高管紧密接触，取得支持，可利用企业管理层力量要求企业人员配合进行。 售前调研结束后不一定需要给企业留下调研记录，往往是通过其它方式（交流，演示，方案）来验证调研质量。 售后调研每个阶段结束应有规范文文件记录每天调研工作，通过过程文文件来审核工作质量。 案例 客户经理小李向公司申请咨询顾问来一个重要客户现场调研，但公司比较好的顾问近期都有任务不能响应，但可以派一个经验不太丰富的顾问来配合小李，小李申请这个调研机会很不容易，而且客户项目快接近选型确认，不立即进行调研很可能导致后面工作被动，这个时候他该什么办？ 点评： 越是重要客户，时间压力大的售前调研越要想办法争取有足够经验的人去现场工作，不能用经验不足的人去完成所谓这项工作。 没有经验的人在现场呆得越久越耽误在现场做工作的时机。如果难以协调到合适的人，安排一个水平不足的人员先去调研，这种人往往只能按照公司提供的模板找一些人，问一些问题，不可能在很短时间内抓住企业的关注点，提出的问题都很概念化和范本化，这样的调研质量很难让客户建立我们和竞争对手差异化区分。 因此小李应该和客户沟通，说明申请一个好的顾问调研对项目成功是非常重要也是负责任的体现，争取客户理解并调整调研时间，如果客户时间实在不能调整，就必须根据项目重要性确保公司安排高水平顾问到现场工作，哪怕时间短一点或牺牲其它不重要的项目。 此外小李下次和客户约定调研时间时，一定要在内部先和顾问沟通时间行程安排，这样才能从根本上提前预防这类工作冲突。售前阶段不要轻易提供解决方案。解决方案难写在哪里？ 没有体系 没有个性 没有素材 没有时间不好的解决方案十个特点 只有厚度，没有质量 只有论点，没有论证 结构不清晰 业务解决方案成为功能列表 口语书面语混杂，遣词造句不严谨。 没有认真检查，存在大量硬伤。 过于突出自我 没有体现公司产品最新进展 文字太多，图表很少 没有评审方案检查清单（共61项）序号检查项审查人整改意见1. 是否用企业LOGO和产品设计有冲击力的封面和封底？ 可填写无整改项让步通过项（1、2、）需整改项（1、2、）2. 封面方案提交日期是否正确？ 3. 封面提供的公司位址、联系方式、邮件是否正确合理？ 4. OFFICES文文件属性是否填写正确？ 5. 目录是否超过5层？是否存在排版不清晰？ 6. 目录是否未刷新？是否有“未定义标签页”的错误？ 7. 页眉是否和正文内容及单位一致？ 8. 是否存在正文和首页页眉不一致？ 9. 页脚的页码是否存在封面，目录，正文排序不一致？ 10. 是否存在不连续页码？文档分多份时是否页码要衔接一致？ 11. 标题是否采用自动编号方式产生？编号是否和章节对应一致？ 12. 同级标题是否格式一致（字体，字体大小，段前段后行距，行间距）且符合公司规范要求？ 13. 正文中是否有无意义空行，孤行？ 14. 正文段落是否是否格式一致（字体，字体大小，段前段后行距，行间距）且符合公司规范要求？ 15. 正文字符字体、数字字体设置是否和汉字字体不协调，前后不统一？二零零年的零字是否格式正确？ 16. 正文标点，特别是逗号是否全半角一致？ 17. 正文中图片排列位置是否合理？ 18. 文文件图片是否有标题，且标题采用自动编号方式产生？是否在图片下方？ 19. 接口图片是否把桌面任务栏也抓屏，或者带拼音输入法等和接口无关内容？ 20. 图片格式是否全部统一？ 21. 图片大小是否存在不合理的裁减？例如大面积空白区域的软件接口应加以裁减保留主要内容？ 22. 图片中文字描述部分是否出现和企业方案内容不一致的地方？ 23. 文文件图片是否大量存在绘制风格不统一的地方？例如WORD、VISIO、图片、接口混合 24. 正文中表格是否出现一个表格分页断开格式？ 25. 表格格式是否统一或协调？ 26. 文文件表格是否有标题，且标题采用自动编号方式产生？是否在表格上方？ 27. 正文中是否有错别字？ 28. 正文中是否存在过于口语化内容？ 29. 企业称呼在文档中是否一致？ 30. 企业称呼是否和其正式资料一致正确无误？ 31. 从模板复制的企业名称是否替换完毕，且正确无误？（今后制作范本文文件可替换部分应用域管理） 32. 正文对项目产品描述是否部分用软件名称称呼，部分用企业项目名称称呼等不协调的地方？高级功能审查 33. 正文中是否大量出现软件公司，软件公司产品等无意义自我宣传的词语？高级功能审查 34. 正文中是否出现说客户存在严重的问题，业务失控等一类暗示企业管理水平不足的表达方式？高级功能审查 35. 客户关注的核心问题在正文中是否专门列醒目章节给予回答？高级功能审查 36. 业务解决方案是否只是软件功能和思路的列表，没有体现出对企业业务特色的支持？高级功能审查 37. 是否出现类似表达文字描述在部分章节反复出现的问题？高级功能审查 38. 是否列入一些企业根本不关注的功能，或者过多描述一些企业不关注的功能？高级功能审查 39. 方案中功能描述是否只是简单复制历史方案模板，复制软件界面？高级功能审查 40. 软件架构部分技术方案内容是否感觉过于抽象，没有清晰图表配合说明？术语过多，和正文解决方案没有逻辑关系？高级功能审查 41. 软件设计思想、架构等内容和公司标准文档不一致？高级功能审查 42. 实施方案中实施团队图是否引用过期结构？高级功能审查 43. 实施方案中实施结构图和未来实施人员承诺是否得到商务和实施团队认可？高级功能审查 44. 实施方案中实施周期和里程碑是否得到商务认可？高级功能审查 45. 有无清晰明了针对性强的配合实施方案的实施部署过程介绍？高级功能审查 好的方案应该设计一个好的封面，好封面的标准就是有视觉冲击力。 建议书的要求是简短紧凑，内容详实，目标规划清楚，便于客户高层决策，可以在一份建议书中形成几个可选技术方案，推动客户高管决策。 实施方案的要害是具不具备可操作性。这里面判断方法就是实施计划越是结合业务细化越具有可操作性。 投标书一定要坚决按照客户提供的招标书要求准备，客户如何要求就如何提供数据，不要任意发挥。 演讲更侧重对某一个问题看法的陈述，主要是交换观点，允许争鸣，听众可以不同意你的观点，但一定要捍卫你发言的权利。除了常见的演讲比赛外，很多时候演讲者是受邀请，以一种被尊重状态出场，是处于一种比较从容的心态下开始的。演讲的过程一般也是比较连续，不会被随意打断的。 答辩更侧重对话双方的交互，具有很强的考核目的，通过对答辩问题的反应，答辩主持方来主动判断他想获取的信息可靠程度。答辩的过程一般是不连续的，随时都可以中断响应不同的问题，答辩的节奏和压力也更为紧张，时间非常紧凑。 培训更侧重于传授操作，此时被培训者已经认可培训者所在公司和产品，在过程中更多的是教学相长，形式可以多种多样，根据不同培训层次灵活组织。 演示不然，演示是有极强的目的性。演示往往是要求在有限的时间内（但比答辩要舒展），面对一群不同心态或者不明心态的人，快速地把自己所在公司、公司产品和服务，包括自己最大范围推销出去。演示过程中还要随时准备开始各种技术答辩，应付各种刁难。演示是追求主动影响客户（用户）的过程，售前演示也是主动和竞争对手竞争的过程，演示更是个人魅力展现的过程。 整个演示就是一场复杂的脑力游戏，看看我们有什么办法在短短1到2个小时内更能抓住客户的心！ u 售前演示的目的Ø 介绍公司，通过自己的言行和产品介绍展示公司的形象；Ø 强化自己的优势，给竞争对手设置一定的进入门坎；Ø 分析自己能为客户做什么，解决什么问题，愈是客户关心的问题愈要主动沟通和交流，让客户对软件产品技术和实施能力放心；Ø 进一步判断客户关注的项目重难点，了解我们前期准备的不足，采取针对性后续行动。 u 售后演示的目的Ø 详细介绍公司和产品，让广大具体用户认可产品，取得最大范围业务认同，减少实施阻力；Ø 宣讲对企业问题的认识，提出自己的业务解决思路，主动控制项目边界；Ø 通过现场互动进一步判断客户关注的价值点是否在项目边界内，确认是否要调整项目边界，尽快回馈给实施团队或公司决策 2 案例 咨询顾问小李和客户经理一起首次拜访了一个客户，并应客户交流做了一个感觉不错的产品演示，企业也表示出很大兴趣。过了很久小李听说客户后来选择了另一家产品和能力都不如自己公司的供货商，为什么会这样呢？ 点评： 大部分客户一开始并不了解管理软件的全部概念内涵，并对自己的业务需求也没有清晰化认识，往往在经过供货商多轮技术攻关后，客户才能比较清楚一些理论概念和自己的业务需求之间的关系，才能逐渐看懂产品演示，此时的产品演示也能达到目的。 过早的演示往往是对客户进行启蒙式教育。一个共同的经验是，企业对于自己完全不理解的事情，无论演示者水平如何出色，总体效果不会太好；对自己有足够了解的事情，即使演示者水平一般，企业还是能听懂个七八分。 很多客户经理其实缺乏销售管理软件的经验和从容自信的心态。因此当发现一个项目需求信息后，他们要么被动地随着客户要求走，要么就过于积极主动创造调研和演示的机会，期望通过一次良好的演示或者用户考察达到商务成功的目的。 实际上一个周期很长的管理软件项目匆匆忙忙去调研演示，效果往往不好，反而造成工作被动。在需要长期跟踪的项目上，往往是早起的鸟儿没虫吃。因此演示最好在充分了解客户关注点的情况下开始，而且要充分考虑如何应对竞争对手的效果最佳。过早演示往往是一个无用的商务活动，还会为后续工作制造麻烦。 在大项目上是不会有太多的演示机会的，特别是在多竞争对手的情况下，宁可等到演示策划确定和准备就绪后，才和客户预约，哪怕耽误一些时间也不用担心，只要给客户解释清楚，客户一般都会理解的。 不要怕耽误一个月两个月时间，管理软件项目不在于跟进时间长短，而在于能否准确定位客户心理需求并给予良好解释。当然那些客户经理自己都没有跟踪，主动找上门来的紧急客户项目例外。u 充分利用信息不对称 为什么存在技术交流呢？就是因为在IT管理系统和应用企业之间存在着严重的信息不对称。技术交流的诀窍就是如何有效利用信息不对称的空间去交流。 信息不对称就是利用大家对全力配合和目标定义的理解不同，让项目可以先进行下去，如果直接告诉客户需求不合理，可能会导致很严重后果（直接出局）的情况下，可以考虑先策略性进行回复，以期获得再次沟通或合作的机会。但在取得机会后，一定要在后续沟通中逐步引导客户意识到这些目标的不合理性，逐步把项目往客观的方向靠近。 利用信息不对称并不是利用客户对行业和产品的不了解去欺骗客户，说服他们购买，然后让客户感觉到上当受骗。好的技术交流从理论上应该是针对客户的疑惑，依据业务现状和管理常识来解答，帮助客户得到一个合情合理，客观真实的解答。现在越来越多的用户趋于理性，只有用真诚的心态去交流，才能取得客户的信任和尊重。 2 案例 咨询顾问小李和客户经理一起参加一个客户技术交流，这个项目参加对手不少，小李他们是比较晚才进来的，客户告诉好几家供货商表示能够实现某功能和在三个月内完成实施，询问小李他们是否也能做到？ 小李认为这个项目实施难度很大，在三个月完成非常困难，至少要六个月时间，这个时候他该怎样回答客户呢？ 点评： 一个咨询顾问必须认识到目前在中国大部分项目上还多少都存在过度承诺，或者滥用信息不对称进行目的性很强的商业暗示的做法。 在项目中经常碰到客户要求供货商承诺做目前无法做到的功能，这种情况是非常难应对的局面，说能做好像是撒谎，说不能做好像是示弱，可能直接导致出局。有的项目对某些技术条件是硬性条款，拒绝就等于放弃。 有一些客户提出的要求本身就不具备合理性，例如有的客户要求无论出现怎么情况项目实施必须保证百分之百成功，有的客户要求项目实施周期必须在三个月内搞定，这些都是典型的不合理需求。 对不合理的技术要求，可以明白告诉客户“有所为，有所不为”的原则，争取深入沟通、了解这些不合理的技术要求到底是为了解决什么问题，这些问题是由哪些更根本的原因造成的，是否存在其它合理的解决手段。 如果是涉及实施周期问题，一般按实际需要理想周期介绍，如果客户对周期非常敏感，可以讲只要企业全力配合，合理定义项目目标，是可以在三个月内做到出成绩的。 其实大部分客户经过一段时间合作后都会趋于理性，可以接受项目边界和软件功能的调整，特别是真正进入合作后，谁也不愿意做一个没有成效但到处过度承诺的系统。如果大家都是追求成功，就一定能找到合理的妥协之道。 针对客户中不同性格的人，交流也要注意策略： 表现型的人要多让其发挥，我们只要因势利导即可，争取他认同我们的理念，并宣传他认同的观点； 对于控制型的人，我们要想一切办法让他认同我们专业性和灵活性，用比较恭敬的态度让其觉得利益上不会受到伤害； 对于友善型的人，我们一开始就要敢于宣讲，让其觉得我们的气势是建立在充分自信之上的； 对于分析型的人，这种人在技术交流时是最危险的，注意谨慎小心，言多必失的道理，话不在多，在于精确可验证。 针对感情上倾向支持自己的人，技术交流的目标是巧妙为其提供说法和炮弹以从内部打击对手； 对于感情上中立的人，技术交流的目标是说服其成为支持我们的人，至少是无偏向的人； 对于倾向于支持对手的人，技术交流的目标是让其在心理上对对手的技术难点和实施能力患得患失，最后可能在压力下成为骑墙派。 对于想法特别多，思维跳跃的人，要冷静分析其想法的合理性，对客户想法和自己想法的矛盾之处做出合理解释，并提出自己的处理意见，否则很容易陷入一种被动响应的局面，成为客户引导软件供货商的局面。 对于没有需求的人，技术交流不要谈功能细节，要更多帮助其建立业务能力信任，甚至是个人魅力信任，有了信任，自然能判断出有什么需求可以帮助其解决。 对关注细节的人，要主动谈理念，让他感觉到高度； 对关注理念的人，要主动谈操作，让他感觉到理念在细节层面上已经落实。 对关注技术的人，要主动谈实施，让他意识到管理系统并非是一个技术决定的系统； 对关注实施的人，要主动谈技术，让他意识到没有良好技术基础保障，仅仅空谈实施方法也是无用的。公司考察接待往往注意大的安排，但对细节落实关注不够，给客户留下不好的印象。 常见的考察细节错误举例： 1、没有通盘考虑每个行程的时间开销，及时通知每个活动负责人提前准备，按时启动，导致很多行程因为节奏拖沓被拉长，很多计划内重要交流内容被迫缩短，或者难以达到质量。在接待时，有经验的人应该预见到可能哪些环节要留足够时间余量，哪些环节可以挤出一些弹性时间，保证整体计划按进度来。 2、只注意安排有车接，没有注意告诉司机有几个人和多少行李（安排车过小），没有落实到具体司机，没有留司机联系方式，没有确认司机是否按时发车（特别是接早班火车或晚班晚点飞机时）； 3、住宿安排没有考虑客户报销要求，安排宾馆过贵或者票据不符合报销标准，客户住宿标准过低时没有想办法申请预算解决住宿问题； 4、早上或很晚接到客户时没有想好早餐或晚茶地点，临时又找不到合适地点； 5、接待所持的欢迎标语牌上企业名称不正确或者用简写称呼； 6、只注意落实每个接待环节负责人，没有和负责人沟通关于客户各方面的情况，导致各个配合接待的人心中无数； 7、没有亲自检查公司介绍材料中是否有和自己前期说法不一致的地方，并做好对策； 8、接待客户过程中在下车，交换名片，称谓，递水，入座等细节不注意商务礼仪； 9、没有提前规划餐饮，点菜时间长，菜样不好； 10、游玩安排不考虑天气因素，没有给客户准备好饮料食品和相机、伞具； 11、购买礼品没有考虑是否便于客户携带； 12、送客户走没有亲自送到站台，仅仅是到车站就走。如何确认典型用户？ 首先要将对公司市场工作最有利的典型用户筛选出来，这些用户其实在售前跟踪时就可以通过客户ABC分类加以明确，这样即使某些用户在第一次合作时项目金额并不大，也可以在在项目实施过程重点保障，重点投入。 一般选择典型用户名单考虑以下七个因素：1） 应用效果。 有三类用户可以做典型用户。 第一是成功进行了大量应用的用户，最好的典型用户应该是每天都有大量人员利用系统进行工作，而且在实施过程中有很好的参考作用。这样有实际应用效果的用户最能让其它客户相信软件公司的能力； 第二是一些应用面还不够大，但基础资料都基本录入，典型业务流都可以实现的用户； 第三是应用很一般，但在技术上有特点的用户也可以考虑作为典型用户。 2） 商务关系。 所谓典型用户，就是能够替公司提供宣传的用户。这些用户论高管还是中层干部或者基层操作人员应该认同软件公司产品，愿意推荐软件公司的产品。 如果没有好的商务关系，用户甚至对软件公司还存在意见，即使应用情况不错，也要考虑是否适合做典型用户。典型用户的商务关系应该一直有专人负责跟踪和维护，仅仅靠客户经理和实施经理（要考虑客户经理和实施经理的稳定性问题）维护是不够可靠的。 3） 行业影响力。 影响力越大越好，一般情况下行业影响力大的用户公司应在商务和实施时区别对待，重点投入，而不要简单受项目金额大小左右，否则可能造成服务资源不够，做坏一个，丢掉一片。 4） 业务应用丰富。 不是一个用户实施比较成功，参观就一定有好的效果，要选择一个业务应用尽量丰富的企业，这样的考察效果才能达到全面完整。一般随生产模式（单件，多品种小批量，大批量）不同，业务应用丰富的企业也要选择几种类型才能适应不同生产类型用户考察需要。 5） 地域辐射力。 典型用户的地理位置应该交通方便，不然会增加客户交通成本，也增加公司接待成本，而且无法起到长期辐射作用。一个全国性公司一定要考虑在全国建立可参观考察的典型用户网络，仅仅只有几个典型用户参观考察对用户本身也是一种巨大的骚扰，而且对很多不方便出省考察的地域性客户，没有当地典型用户是很难做到有效辐射。地域还应考虑到周边游玩餐饮等因素，这也是客户接待考察环节中可以充分利用的资源。 6） 服务资源。 典型用户并非一定是所有问题都解决了的用户，往往是经常性需要服务的用户。因为应用深入，反而新的需求比较多，合作机会比较多。但很多时候典型用户在协助软件公司做一些参观考察工作，往往提出软件公司帮助免费解决一些软件应用问题，这样典型用户如果完全没有服务资源往往会出问题，难以让典型用户长期保持一个良好的考察状态。 7） 介绍资源。 典型用户接待效果在一定程度上取决于用户有无能将把业务和信息化实施相关问题介绍清楚的人员，如果有一个这样业务能力比较突出，信息化理念清晰，又全程参与项目实施过程的企业人员能介绍项目实际情况是最好不过。 典型用户确认条件未必一定要以现在是否可以立即考察做依据，而是应该综合以上因素后确定名单，然后通过一系列工作努力让这些合适的用户成为可以参观考察的用户。 选择典型用户的最关键因素就是这个企业本身业务典型不典型，行业辐射力大不大，其次是综合考察成本是否最经济。 2 案例 客户经理小李的一个客户要求看一看他们的成功典型用户，正好小李公司有一个做得不错的用户，经公司同意后就推荐客户去这家用户去考察，这家用户和小李的客户业务不完全相同，但没有更方便的考察用户了。在陪同客户去用户路上，他一直在担心用户考察效果。最后考察完成了，小李感到尽管用户实施效果不错，但好象客户感觉和他们企业关心问题不相同，要求小李再安排一家已解决他们关心问题的用户去考察。 小李在这个考察过程中到底该如何做才能更好呢？ 点评： 很多软件公司感到困惑的一个问题就是管理软件项目实施效果往往和预期有一定差距，能全面应用软件全部功能的用户非常之少（这需要产品功能、性能、实施力量，业务客观需求，用户配合多方面因素成全），而很多选型客户总是希望看到一个自己需求类似、全面应用的用户，以放心选择合作伙伴。实际上不存在完美的典型用户。我们知道大部分情况下我们很难依据客户要求提供类似的考察用户。 客户经理总是把项目考察成功的希望寄托在让用户看到一个真实全面和类似应用的标杆上，对典型用户的考察效果全面寄托于样板客户的实施和应用水平。按没有同行业典型用户无法成交项目的逻辑，则任何行业供货商都应该没办法做新领域的第一个项目，因为他们都没有样板用户。 事实上，客户经理可以选择一个有影响力的用户，最好与客户的生产类型比较接近。在考察之前，客户经理最好是和用户介绍人面对面交流一次，听听他对一些关键问题的说辞，确保符合公司要求，防止说漏口或介绍自己认为是很得意的工作但恰恰是别的客户的忌讳的工作。 现场交流时客户经理可以安排用户主动问客户关心的问题，等客户说出自己的问题时可以根据情况要求用户立即强调这些问题在我们企业也存在，但通过上软件项目已经比较好的解决了难题，以此引发两家企业产生业务共鸣，让企业觉得的确考察的是类似行业性问题。 客户前来考察是提供脱离自己企业环境，可独立思考的机会，也是最容易接受别人思想的机会，整个考察工作如果精心准备和规划，自然能给客户留下深刻的印象，对项目成功起到关键的作用。在管理良好的企业一般是通过自下而上的流程去驱动基础业务，高管更多关注战略业务层面工作，然后安排执行。在管理不佳的企业一般是通过自上而下的流程去驱动基础业务，高管不得不投入精力在业务部门调停争论，使大家投入精力到解决问题中去。 因此需要高管来推动业务有两种，第一种是非常紧急和重要的业务，按照常规的业务流程评审过程将使事情复杂化，失去敏捷的回应能力；第二种是牵扯到多个部门利益的新问题，暂时无法通过流程达成一致处理方式，也就是中层无法决策或达成一致的事情，请高管决策。 大凡领导都喜欢处理正式的文档。 有四类报告高管是不注意或不能有精力真正重视的：过长的文档：给高管写的文字一定要在三四页纸甚至更短的页数内解决问题；只提出问题，却没有清晰解决思路的报告：除了给高管带来烦心感外还有什么大的价值呢？组织条理不清，逻辑结构混乱的文件：也是无法获得高管认同的。只从自己角度思考问题，没有站在全局角度思考问题的文档：高管会觉得信息量太小而无法决策，报告也就不了了之。 切记：理性、客观的汇报工作是任何一个明智高管欢迎的作风。不开启动大会的几种情况。弱势软件公司签下了严重过度承诺的合同 国内软件公司绝大部分都是弱势公司，即使是一些产值很高的公司都不见得比一个国外小公司产品有影响力。 弱势公司为了击败强势公司，往往会用较低项目金额承诺一些定制开发。而强势公司完全可以要求企业按照其产品进行业务流程重组，尽管很多时候依据国内外咨询公司建立的新流程也未必高明和实用，实施效果也未必好。 这种过度承诺的项目从实施角度来看风险很大，很可能在项目启动后很长一段时间内软件供货商都很难拿出合适的产品到现场实施。此时，必须低调处理项目启动大会，甚至暂时不召开启动大会，在项目找到可实施路径的时候再召开启动大会更合理。金额很小的项目可不召开启动大会 有的企业虽然签订了一个复杂的合同，但投入的费用其实很不合理，供货商出于种种原因还是签订了合同，此时指望供货商提供强大的后续支持不太现实，因此项目经理尽可能不扩大项目影响，这样可以在合理条件下尽量调整项目边界，使之可以达到可承受的成本范围内。 如果召开一个高调的启动大会，企业主管领导可能又号召大家动脑筋、提建议，发动面越广，项目需求越可能控制不住，此时高调的启动大会不但不能帮助项目顺利启动，反而很可能造成项目走不下去，企业的投入全部报废的后果。 在这种情况下项目经理完全可以和企业沟通，低调起步，取得一些成绩，得到企业各方面认同项目目标后，通过企业适当追加费用，把项目顺利完成。在这种情况下，低调反而是对项目的一种自我保护，会屏蔽掉很多不必要的干扰。工具化，产品化的项目可不召开启动大会 现在上三维设计软件的企业很多，花费达到几十万的也不少，很多时候远远超过管理系统的投入，这里不讨论这种投入比例是否合适，但一个奇怪的现象就是，很多企业并不为这些花费不小的项目开启动大会。 原因很简单，工具型培训掌握的软件是没有实施风险的，业务部门很清楚掌握这些工具对业务和个人的好处，会比较自觉按领导要求去接受培训，在截止日期之前掌握软件，根本就没有召开启动大会发动全员重视的必要。 同样如果我们应用的是非常成熟的业务和系统模块，也可以快速调研、快速安装、快速培训、快速见效，那么也不需要召开启动大会，最多只需要召开一个推广大会，业务部门强化培训一段时间即可。具备良好信息化实施经验和管理规范的企业不需要启动大会 如果企业的信息化工作已经成为一项日常工作，已经具备大量信息化项目实施经验，有良好的实施团队，信息化已经成为每个部门标准工具和日常流程中一部分的时候，再上一个新项目就不需要启动大会这种形式了。经过充分磨合的用户可不召开启动大会 有的项目是老用户追加，再增加比较大的投入合作新项目，和软件供货商队伍磨合已经完成，新项目只是扩大应用深度，可以看做是历史项目不断的深入，此时也可不召开启动大会。不过在新项目业务流程验证完成后可以召开一个新项目上线动员大会。无法摆平内部关系的项目可暂不召开启动大会 有的项目商务阶段过于复杂，选型结束后企业内部仍然存在矛盾，此时如果立即召开启动大会，很难快速化解矛盾各方，启动大会必然就流于形式了。这种情况下项目启动大会可以稍为缓一缓，创造出一些条件后再召开效果更好。 项目启动大会既约束企业，也约束软件供货商。企业对供应商专案组有合同约束手段，反过来软件项目组也一定要让企业项目组受到内部考核机制的约束，这样双方才能在启动阶段认识一致，同心同德完成项目实施。如果从启动阶段开始，企业项目组就变成软件供货商的监工，大部分时间用于检查软件供货商的工作，指责他们进度的拖延，而不配合软件供货商调度资源、推动进度的话，那么这个项目失败风险就增加了。2 案例 项目经理小李和一个客户项目负责人约定要启动调研了，他写了份计划，说明调研派出团队人数和计划天数，还说明了调研要了解的大概内容，请企业确认能否按计划时间启动和开始。小李在得到企业肯定答复后来到现场，这才发现企业这边根本没有配合好，无论是要求准备的数据还是要