CRM与其它应用系统的集成和协调

AMT CRM研究小组（编译）2002/03/25

尽管最初的ERP提供商努力去将不断出现的应用领域包括在其系统内，但是快速发展起来的CRM应用系统仍将对G2000的用户产生一个的较大的影响。因为它们必须要将现有的ERP主体系统与那些更新的应用程序良好的结合起来。

在以前Delta的关键客户关系管理（CRM）接口的观点中（请看ADS Delta 811, 29 Dec 1999），我们描述了运营性的CRM在营销、销售和客户服务方面的活动对后端办公室或是供应链功能的影响。Delta强调了当前这种运营性的CRM过程与现有的后端办公室和供应链流程的分离状态，并且指出了一些关键的领域来协调这一问题，从而保证在多客户接触的渠道中，最终实现实时的客户可见性和需求/拉动形式的运行。这些分离状况的解决超出了一般的运营性CRM在销售自动化、营销自动化和客户服务等方面的功能范围，而需要更为广阔的包括运营、分析和合作应用程序在内的CRM大系统来得以解决。并且解决这一问题的复杂性还会因组织问题（例如，文化问题、多项/协同应用程序开发）和CRM/ERP（企业资源计划）/SCM（供应链管理）解决方案及优先权的重复而有所增加。这样一来，就使得各个应用程序广泛分离并降低了客户集成努力的效果。

2000年1月，尽管CRM将从一个相对独立的应用程序逐渐发展成一个CRM的系统框架，但是许多公司仍旧会通过从多个供应商那里获得解决方案，并使用各种各样的EAI(企业应用集成)技术来集成（大多在一个特定的基础上）它们的方法，来继续建设它们的CRM大系统。到2002年3月，很多公司将集成不同的应用环境，来建设综合性的流程大系统，从而与它们的客户建立起多渠道的无缝合作。到2003年4月，尽管ERP的使用将进一步扩大，但随着管理多样化的、大规模的应用环境的复杂性的增加，在面向外部的（如CRM、SCM、电子商务）应用程序上的大量投资，将会推动主体应用程序的重复性问题产生一个合理的解决办法。

1. 作为一个整体的CRM大系统

建立一个CRM大系统需要利用多种产品供应商的解决方案，并且要同时借助于中间件及EAI技术的使用，来将运营性的、分析性的和合作性的组成部分联系起来。由于供应商们已经在自动化、集成和销售、营销及客户服务/客户交互中心（CIC）管理流程等方面构建了广泛的解决方案，所以运营性的CRM组件（例如，Clarify，Siebel）在过去的两年内已经相当的成熟。而分析性的CRM组件（比如像Broadbase, E.phipany, Quadstone）已经超出了数据仓库发展的范围并且正迅速地发展到与运营性的CRM部分相集成(随着合并与收购活动持续地扩大)。尤其是在营销自动化方面，在这方面运营性的（例如像活动的执行和管理）和分析性的（比如像市场细分、分析）能力是同等的重要。最近的主要事件包括Broadbase收购Rubric和Siebel收购Paragren。最后，合作性的CRM部分（例如像IVR/ACD、移动技术、e-mail管理、聊天、电子布告、网络会议），将会随着在多样化的POIs（points of interaction ——交互点，例如像e-mail、网络、直接邮件、传真、电话、移动代表、分支机构等）中获得无缝客户交互的关键技术的发展，逐渐与运营性的CRM组件相连接。

当组织不能够从一个来源处获得它们的CRM大系统的时候，就需要用一个整体的、战略性的方法来获得CRM，从而在CRM应用范围内，降低客户集成努力的成本和复杂性。并且现有的后端办公室/供应链功能在客观上也要求这么做。采用相互独立的、单一功能/单一渠道（例如，为一个地区销售力量而实施的销售自动化）的CRM配置，是当前在许多公司内的一个通常的做法，它也许能够解决短期的、操作方面的难题，但是如果这些配置没有从更广阔和更具战略性的角度来经过仔细考虑的话，它便可能会导致一种内在的分离状况。因此，在运营性的、分析性的和合作性的功能之间构造一个综合性的CRM框架结构或是以顾客为中心的主体系统，对维持组织的健全，最终推动多流程运作和跨功能的前后端办公室/供应链管理的集成来说，是相当关键的。

2.主体应用系统的重复问题

在过去的几年当中，ERP组件作为企业内部流程自动化的一个事实上的主要部分，已经在许多企业里出现了。随着ERP领域的不断的向上（包括购买方，供应链功能）和向下的扩张（包括卖方，CRM功能），人们就对是否需要一套包括全部的CRM、ERP、SCM、电子商务在内的单一来源的企业内部主体系统产生了争论。尽管这一提法对许多IT公司极具诱惑力，但是直到2001年2月之前，现有的ERP提供商所提供的产品仍将继续限制在当前的这些应用领域内，因此也就必然会导致组织内现有的CRM/SCM/电子商务战略和应用程序的配置产生一定的分离。相应地，大多数公司在2003年4月之前所面临的一项关键的挑战，也就是尽力去减轻应用程序、功能和流程重复的状况，尤其是关于CRM的重复问题。这在客观上就要求公司去建立和集成多样的、连锁的应用框架来支持内外部的多项功能与流程。

就像快速发展的CRM、SCM和电子商务市场所反映的那样，很多公司并没有一直在等待它们的ERP供应商们来为将要出现的应用程序提供的所谓支持。尤其是正处于快速扩张阶段的CRM，它超出了传统的销售和服务自动化的范围，并将电子商务、营销自动化、分析性的应用程序和电话授权等功能囊括进来。部分来自于ERP供应商方面的灵活性的缺乏，正不断地影响到许多公司的内部管理，这种状况就迫使他们来配置非ERP基础的应用程序，使得外部/电子商务的交易或流程完全自动化并进行相应的管理，同时利用基于ERP的订单管理（因此能够了解到如库存、订单状态和ATP等的后端信息）来进行服务，并以此作为应用程序集成的一个关键的结合点。尽管复杂性会随着多样化的开发环境、体系结构、建模工具等而有所增加，但不断要求进步的公司会通过计划管理、彻底的自我评估和有效的计划来管理这些复杂性，并最终通过成功的实施案例来证明应用程序中心的可取之处。（请看ADS Delta 729, 29 Mar 1999）。相反的，为了集成和协调多样化的应用程序结构，所采取的那些没有经过仔细考虑、权宜性的特别措施将不会有效。

3.评论与总结

商业冲击：不断发展的客户关系管理和其它出现的快速发展的独立的企业应用程序，将会引导许多公司去集成多样性的、共存的应用程序的主体系统。

概要：IT公司们应该去仔细地评估它们那些快速发展的应用程序配置所产生的影响。尽管推向市场的速度是至关重要的，但具有前瞻性的程序管理和集成计划将会大大减少与集成多样的、分离的应用程序主体系统相关的许多令人头疼的问题。

www.AMTeam.org