CRM项目实施目标及成功要素

newmaker

欢迎访问e展厅 展厅 1 企业资源计划ERP展厅 企业资源计划ERP, 供应链管理SCM, 客户关系管理CRM... 在多个行业中，许多企业已经将客户关系管理设立为商业变革和技术革新的优先目标。Aberdeen研究机构认为CRM市场在2001年可以达到142.5亿美元。当前，企业正处于向着以客户为中心的方向演变的不同阶段。 有一些先行者已经成功实施CRM解决方案，而且创造了全新的、有效的收入增长机会，而同时，另外一些正在努力追赶，陷入了盲目的技术方案实施，期望技术可以完成优化客户价值的承诺。来自Giga信息中心的报告显示:因为没有充分和按部就班的计划，至少会有70%的CRM实施项目会失败。 在过去的六年里，我已经在通信业、金融服务业、高科技制造业主导了多个CRM项目，我发现在CRM项目开始之前有一些关键要素，可以提高成功的可能性。本文的目的在于提供一个CRM项目成功的框架。无论你正处于计划和实施你的CRM哪个阶段上，本文将有助于你建立"里程碑"，然后采用必须的步骤，走向成功的CRM实施。 明确CRM的目标 企业在建设CRM时应该具有非常明确的商业目标，这只能在详细考虑之后获得并以文档形式具体表现。这是一个找到难点并从中寻求答案的过程。如:最大的价值是否在实施销售自动化解决方案中?是否应该采用一套可靠的呼叫中心?服务部门是否需要提高他们的服务效率?竞争对手是否正以有效CRM的策略蚕食你的市场份额?在电子商务的时代你是否想以预见性的方式向"以客户为中心"的商业模式过渡?CRM应用是否会为企业创建一个与客户接触的"门户"?CRM中的伙伴关系管理是怎样的?无线集成的移动办公对企业是否有意义?这还只是一些在CRM目标成型之前需要回答的问题，这要求深思熟虑，并得到客观的内部运营能力分析，以及外部挑战分析，这样思考之后才能得到一个明确，组织需要的CRM远景。 虽然建立明确的CRM的目标是一个较大的挑战，这仅仅是将要面对的系列挑战中的第一个而已。让整个组织达成统一的认识是这个阶段对项目的未来至关重要的一点。我的客户中有一家高科技制造公司，在项目早期就很清楚地界定了CRM的目标，但达成公司统一认识的过程就很困难，因为项目主要参与人都不能认同目标的优先级，最终项目启动延迟了三个月。而一等项目启动，市场部与信息技术部的磨擦又继续迟滞了项目的进展，而此时，竞争对手却蚕食了他们的市场份额。最终利用了不少公司行政手段才克服了众多障碍，使项目通向了成功。 一旦你成功的确定了CRM的目标，就会有更多的问题被提出。公司的其他人是否认同这个CRM远景?CRM目标是否与公司发展战略同步?如果没有，差距在哪里，对高层战略会产生哪些影响?底层应用人员对这一目标接受到了什么程度?高层人员对这一目标接受到了什么程度?再一次提醒，可以提出的问题很多，而答案并不总让人感到振奋，但是，一定要问这些问题，这是十分关键的。这样就可以进行总体的实施准备性评估，了解现实状况，并且知道整个组织是否已经准备好。 类似上述的演习将有助于你剖析现存的商业目标并确定新的商业目标。这将帮助你列出核心商业目标的名单，这一名单是你实施CRM项目的基础。以书面形式将这些商业目标记录下来，并且一定要清楚地陈述它们，总结未来的推进过程和能够预期的收效。这种结论性的文档将对实施前、实施进程中和实施后期保障有着极大的指导意义。在实施之前，这可以作为一个启动总结文件，将底层和高层的认同锁定。实施之后，这可以作为衡量项目成功与否的一部分。 确保CRM项目的实施得到高层支持 一项针对十几个项目经理的调查发现，无论是什么项目，缺乏有效的高层支持都是最主要的风险因素。一个CRM项目如果要实施成功，也必须得到企业中主要执行经理的支持和认同。高层支持能够确保各级应用人员都能深入项目，保证项目的实施效果。没有了高层支持，还会引发其他的项目风险因素。因此，保证CRM项目所涉及的部门高层都可以提供支持是至关重要的。比如:实施SFA，执行支持者就应该是有远见的销售和信息技术人员。他们将会启动项目并公开表示支持以实现项目最终目标。他们也会演示商业案例，向各个应用小组的关键人员说明项目的原动力和最终目标，这些用户会与其他应用人员交流预期的实施效果，说明组织的领导已经要求项目必须成功，这样所有的用户都在正确的位置上来确保将在项目中精诚合作。 当项目费用超支的时候，高层认同是尤为重要的。在一个$200亿的庞大的金融服务机构，一个长达12个月的CRM项目超出了预算。因为项目小组在项目启动时已经锁定了高层对项目的最终效果的认同，他们从CIO那里获得了补充资金，最终项目成功了。没有高层支持，这个项目有可能半途而废。 确保高层的支持是一件易说而不易行的事，并没有什么独一无二的有效绝招。每个公司都有自己的企业文化，需要按照这个企业的惯例采用一些客户化的策略来确保高层的支持。这有可能带点公司行政手段，也可能意味着要超越一些旧有的框架，以各种方式量化指标创造性地推售你的观点，例如增加了百分比的客户保有率，或缩短了N天的销售周期。或者，这也可能是画出一个价值树，标明关键高层人员在其中的地位，一项成功的项目可以如何影响他们的奖金。如果企业的领导者非常清楚地知道CRM远景，那么这一目标可以更容易地渗透到其他层面，并获得认同。一旦你获得了高层支持，你就为成功奠定了坚实的基础，并已经赢得了一场主要战役，你也正在获得整场战斗的胜利的途中。 商业流程推动CRM的实施效果 CRM是一项为了建立"以客户为中心"的组织而采取的商业流程改进，技术只是一种实现手段。因此，一定要确保在优化商业流程与采用软件中寻求最佳的平衡点。同样，要利用CRM实施的机会来减少那些不能提升客户体验的不佳流程。众所周知，近几年来虽然在CRM方面的投资大幅增长，但客户满意度还在下降，这其中有一部分原因是组织只是将现有系统替换成新系统(整个流程保持不变)或者只是将现有的流程实现了自动化。实施新的功能改进后的CRM软件并不能保证客户体验的改善，因此，请利用CRM实施的机会来重新评估市场、销售和服务的流程、明确所有的客户接触点，无论这些接触是从哪些渠道进行，并且将精力集中在提升关系和优化每一个接触点上，以获得最大的客户价值。 实施CRM的一种风险表现在技术推动取代了商业流程推动，盲目地追求"客户的全企业视角"，夸大理解复杂的客户信息具有的无限潜力。虽然这些思想都有正确的地方，它也可能偏移了企业的独特的商业需求，这些需求可以增加近期的可见的价值，并直接影响利润。为了最大限度地得到CRM投资回报，需要自始至终地保持对商业目标的关注。这些目标应当是非常明晰的，而且衡量成功的指标应当在实施之前就确定。例如，如果你要实施一个销售自动化的解决方案，仅仅说"增加每个销售代表的创收"是不够的，应当有一些更量化的指标。 一个企业的CRM实施方法也同样会受到其所在行业的影响。许多系统供应商都正在或已经开发出有行业特点的CRM应用方案，然而，多数情况下，这些应用大多是一些在系统提供商的基础软件功能上增加一些有行业特征的"化妆"。不同的系统供应商所提供的包容在软件中的行业最佳应用有着很大的不同。系统供应商可以宣称他们已经树立的CRM典型，已经和本行业的最佳应用相结合，却常常使他们的用户陷入技术为中心的实施困境中。有一个单一的从盒子中拿出来就可以应用的软件就能够满足你的所有CRM目标，这种可能性不大。一定程度的客户化总是必须的。 "以技术为中心"的CRM实施的另一风险在于改变企业多年来形成的精良的特定的商业模式以适应软件所能提供的功能。要降低这种风险，在实施的设计和分析阶段，需要详细的差距分析，这种分析应当包括当前及未来的流程。这种分析会有助于保留有效的流程并抛弃一些无效率的流程，它同时也包含了提升未来流程和采用软件包含的最佳行业功能。 明智地选择技术合作伙伴 有至少500家以上的CRM提供商在市场上提供"最适合"的产品，这对企业来说，寻找到一家"最适合"自己的产品，的确是一种挑战，但也是一种机会。只有很少的幸运的企业能够找到一款真正适合他们需要的直接可用的产品。更可能的情况是，你必须坐下来，听完大量的产品演示汇报，在软件的细节方面来考验供应商。 可能会有一些提供商能够证明他们的软件是灵活的，可以轻易地根据商业需要进行客户化来适应商业需求。另外一些供应商则会提供有限度的客户化功能，但都会避而不谈良好的并易于扩展的行业应用方案。在升级方面，前者往往比后者更加困难，这更证明了其实并没有什么绝对好的方法来处理客户化问题。特点、功能、限制会因产品的不同而大相径庭。 始终关注你的商业目标，用这些标准来判断层出不穷的产品，选择那些最能充分满足这些目标的数据模型。清醒地认识到CRM实施中的客户化部分。因为这些部分有时会花费软件本身价值的5-10倍。要求提供商提供行业参考案例，从那些类似于你的企业中找到需要多少客户化。如果在这些工作都尽职地完成之后，你发现繁杂的客户化工作是不可避免的，那么就需要关注那些能够提供可靠的客户化能力得产品，不要选择需要多次升级的道路。 同样，一定要选择那些会持续支持你几年的技术合作伙伴。CRM软件行业正在快速合并的过程中。收购厂商有时会中止对已经收购的厂商的方案的支持。这会增加CRM应用的中期风险。如果你放弃寻找一个现成产品，那么一定要选择一家被客观证明具有实力的系统集成商了。这也会面临挑战，因为在系统集成商和软件提供商之间有着复杂的联盟策略。这样联盟关系有时会影响集成商，使它们成为了某个供应商的销售渠道。更有甚者，系统集成商有时会把在选择软件供应商作为通向一个更大的、更有利润的实施合约的起点，这会使他们的客观性模糊起来。 利用项目管理的最佳实践经验，你可以增加获得不包含偏见的产品推荐的胜算。把项目实施分成多个步骤。例如，步骤可能包括战略设计、需求定义、选择供应商、实施、培训和实施后支持。然后为每个阶段制定独立的、客观的系统集成方案。即使有些系统集成商可能看起来在每一个阶段上都具有较强的竞争实力，你会发现在每个领域中都一定存在着已建立的领导厂商。 组建精英的项目实施小组 这个要求说起来容易做起来难，CRM实施最主要的要求是有足够的人员以确保所有的任务和要求能按时完成并精确地执行到细节。然而，一般情况下，你能够具有所有的让实施成功的现成的专家经验几乎是不可能的。一个典型的CRM实施团队需要有项目经理、主要业务专家、应用和技术小组负责人、应用和技术分析员、开发人员、技术架构负责人、数据库管理员、培训和支持人员。不同的人员在实施的不同阶段介入，每个角色所需要的人手则因实施规模而异。那么，如何确定你具有适合的各类专家并安排了相应的角色?首先为每个角色确定关键的技能档案，从你的系统集成商那里获得足够的承诺，他们将派出可以匹配或超过这些要求的项目成员。技能档案可能涵盖广泛，有项目管理能力、过程控制能力、技术能力和变革管理能力。还可能包括某些专门的要求，例如获得过证书，有行业经验、产品经验和以前的项目经历。最理想的情况时你应当以标准的"请求服务表格"来填写，这样就可以从不同的系统集成商处轻易地对比各个实施人员。这可以看出那个系统集成商将最好的人员提供给了本次实施。 在提出方案时，系统集成商推出他们的专家，而在真正实施期间却派出一些稚手，这是一件可怕的事。他们推脱的借口是，实际上他们无法精确地预测在你的CRM项目周期的每个阶段所需要的资源。如果你能够为每一个特定的角色设立技能档案，并且按照这样的要求填写"服务请求单"，那么你为每个角色争取到有经验的项目成员的胜算会增加不少。 你的企业中某些关键的内部人员必须要全部地整时地投入到项目中。主要业务专家是一个好例子。他们每日的业务操作对企业来说固然重要，但是他们以全时参与项目的优先级可能应当更高。如果你只选择那些部分参与项目的人员，就要准备好问题解决可能会延期，项目的未来也不一定能得到保证。结果是这将影响总体的项目时间表和项目成果的质量。 项目小组的人员变动有时会对大型CRM实施产生很大的风险。如果人员变动在早期，新成员的加入不会有什么太大的影响，但随着项目实施的开展，人员变动的影响就会加剧。离开的小组成员会带走有价值的信息，例如新系统如何工作，或者为什么对于要决定这样的流程设计和系统设置。项目的整体质量也可能被不直接参与项目的人员拉入疑问之中。接替的项目小组成员往往要面临严峻的学习曲线，在承担项目报告的责任方面也会发生困难。所有这些因素都对实施产生负面影响。 为了将项目成员变动的风险降至最低，最好的做法就是对关键的项目小组成员提供特别的奖励。这些奖励可能多种多样，依据公司的文化和项目时长而各不相同。关键的项目小组成员可能获得期权，项目奖金或外出旅游。无论是哪种奖励，都必须足够可以减少项目成员的流动。另外，需要在项目的早期就设立相当的知识共享方式。 如果要在多个地点实施CRM解决方案，人员的增加，他们之间的交流不畅，都很可能会影响到项目交付的质量和进展。虽然项目经理可能希望在实施的全过程中都将所有小组成员集中在一地，但有时，这是不可能的。但是，交流不应当因此而受到影响。项目经理应当在实施初期就建立起覆盖所有方面的交流计划和程式。项目小组成员在热身的时候就应当了解交流计划，并受到鼓励在项目全过程中利用和执行这些交流方法。 有效地管理组织转变 CRM项目的实施一定会带来给企业带来许多变化。有时甚至需要建立新的结构。你的销售人员有可能会抵触新的销售自动化方案。你的服务组织可能会难以摆脱旧系统的工作模式。奖励机制有时会被改变。最终用户接受新系统的培训等等。变革管理在一个相对广泛地范围内引入这些变化，而且是以一种积极的态度。目的是从实施前的状态向实施后状态以一种有计划的有序的方式进行转变。 变革管理常常被看作为"软性"行为而被忽略。但请不要犯这个错误，再如何强调有效的变革管理对你的CRM实施的重要性都不过分。向所有的人通报CRM的带来的收效将会得到大家的合作和接受。将他们的认同确定下来。 例如，在一家入围财富500强的制造企业中进行销售自动化工程时，该公司的销售人员听说了业务流程的变化和相伴的新软件的时候产生了抵触。听到这些，该企业的销售执行副总给每一位销售经理打了电话，随后向所有销售人员发出电子邮件，向他们保证新的软件可以使他们获得更好的业绩，也就意味着更高的提成。在项目的后期，他们有机会可以看到试用版本，因此认同了这位副总的话。结果，销售人员高兴地接受了新的方法。 CRM实施初期当然需要考虑最终用户以确保CRM方案符合他们的需要并能提高他们的效率。向他们提供强有力的培训、评估奖励和团队结构都能使他们平滑过渡到新的流程中。根本点在于，一定要认真对待变革管理，否则这会在各个领域中挫伤已经取得的工作成效。(end)

文章内容仅供参考 (投稿) (如果您是本文作者，请点击此处) (10/19/2006)