ERP与CRM的整合知识

9/10ERP与CRM的整合迈向电子商务的三个步骤越来越多的电子商务的先行者们发觉，“传统”企业对网络的理解和应用通常要走过几个时期。不管企业属于何种行业、接触网络或早或迟，这几个时期都会成为被普遍认可的经验总结。Intel公司董事长Grove在最近同意《华尔街日报》的采访①时把这三个时期总结为：电子小册子时期、电子交易时期和电子化决策时期。如此的总结能够讲与我们正在全球范围内开展的上千个CRM咨询项目所获得的体会不谋而合。所谓“电子小册子”时期，确实是公司仅仅把自己的介绍性信息放在网页上。这也是目前95%号称“差不多触网”的中国企业的网页形式。这种网页通常分成几个目录：公司组织结构、新闻中心、产品目录、客户联络、合作伙伴等等。这种网页与书面的“公司简介”等小册子从内容到排版都特不相象，因此被称为“电子小册子”。要把如此的介绍书搬上网，加上一个网址，编写起来并不难，硬件上也不必专门购置服务器，只要挂在某个网络公司的虚拟主机上即可，人员方面也不需要配备专门的网页维护更新人手。能够讲，建立如此的网页投资少，见效快。只是这种见效最多体现在公司差不多注册了自己的域名，能够在职员的名片上加印一个http://www的地址而已，不管是现存客户依旧合作伙伴，登录之后都会发觉如此的网页对与该公司进行交易并没有什么关心。“新经济”不是如此的“电子小册子”的集合。第二个时期，也确实是北美在过去的两年中方兴未艾的CRM热潮开始让企业从“电子小册子”走向实现“前端办公自动化”。在那个时期中，需要重组业务流程和融合内部应用软件，需要把互联网功能与企业内部网功能实现交互。最需要变化的通常是定单治理模块、供应链系列模块、财务治理模块和客户服务模块。我们在那个地点所讲的重整有两种实现方式，一种是从“前端办公软件”开始，向“后端”推进，即首先建立销售人员能够迅速学习和掌握的机会治理、定单输入和服务要求输入的界面，然后把收集到的数据向后台ERP传送，或者实现这两个数据库的同步更新；另一种方式是从“后端”的企业资源数据库（ERP）中向前端推进，保持ERP的服务器/客户端的差不多架构，而且“客户端”能够采纳以扫瞄器为主的“瘦客户端”（thinclient），也确实是讲，后台数据库能够直接同意网络上传入的数据，用户从扫瞄器上输入用户名和密码后，赶忙就能够查询、更新后端数据库里的信息。不是所有企业都情愿赶忙把它的后台数据库向世界各地的网民公开。因此，在那个时期，即使数据库用户差不多超出了“内部范围”，内部网和外部网的严格界限正在打破，能够login的用户仍然是有选择的，他们通常是企业现存的分销商、差不多建立了交易关系的“老客户”以及长期的合作伙伴。在那个时期中，CRM与ERP的整合势在必行。具体的模块整合过程下面还会详细介绍。第三个时期，Grove把它称为“电子化决策时期”。实际上，那个时期究竟应该如何定义还存在着相当的不确定性。我们只能从目前差不多完成的电子化网络化工程中揣测一二。这也涉及到电子商务当前的重点话题：B2B垂直整合。在那个时期中，不仅仅是一个企业把自己的资源数据库向客户或供应商延伸，而且是许多企业的数据库相互联接，满足一定规则的交易，比如常规性购买，将由计算机自动完成；一个企业的库存数量将依照其交易伙伴的定单自动更改；每个客户将以最短的时刻获得按他的要求定制的产品。在零部件供应高度标准化的电子产品行业、医疗用品行业、办公用品购买中，我们会首先看到不同企业的资料库，包括价格、规格和库存量一起展示在同一个网络平面上，搜寻、比较和下定单变得快速、易如反掌。慢慢地，其他行业会加入进来，庞大的跨国跨行业的数据网络中心将逐步形成，成为工商业资源调配中心枢纽，真正实现“网络革命”。只是，罗马不是一天建成的，要达到全社会的资源安全共享，没有前面的步骤是不可能的。在企业内部数据库运用比较成熟的国家和行业中，这种变化会先于其他的国家和行业发生。我认为，中国目前的国情决定了大部分的企业还将在以后的一两年内建立和保持他们的“电子小册子”；然而在中国的通信行业、金融业和消费品行业中的佼佼者差不多有能力也有动力进入“前端办公自动化”的实验期；当他们的实验获得回报的时候，其他的具备相当规模和全球性战略眼光的中国企业才会随风而动；而至少要在四、五年之后，我们才能更清晰地看到中国是否可能开始同行业的企业与企业间的数据库联合，跨行业的数据交流可能需要更长的时刻才能实现。同步更新的ERP与CRM前面我们提到在实现与后台整合的“前端办公自动化”的时候，最经常需要考虑的通常是CRM软件与定单治理模块、供应链治理模块、财务治理模块和客户服务模块之间的数据交换。在北美进行的某些CRM项目中，由于预先对这种前后整合的设计不够细致，以致出现某些极为挠头的问题，需要不断地追加投资来加以更正。弗吉尼亚州的一家名为ValueAmerica的公司②最近在他们的CRM工程中遇到了下面的问题——这家公司采纳SAP的R/3系统作为他们ERP的后台架构，并安装了Siebel99.5作为前端进行销售、市场推广和客户服务的IT平台。由于安装时没有采纳标准的Siebel和SAP接口的中间软件，在系统运行之后发觉有如此两个大的问题：1．为了保持两个系统之间数据（尤其是顾客信息方面的数据）的同步更新，在一个系统运行过数据更新之后，必须人工启动另外一个系统的数据更新，否则在两个系统中有关同一个顾客的信息就有了差异。了解数据库运行的DBA们明白，这种人工运作几乎是不可能长时刻维持的。2．另一个问题是反应时刻的差不。比如讲“定单状态”那个数据在SAP中生成并随着定单处理的各个步骤而变化，假如数据更新不是同步的，那么SAP中的“定单状态”可能差不多更改为“完成”，而前端数据库能够查询到的却依旧“未批准”。假如在CRM设计中就充分考虑到了哪些数据需要不断和ERP进行同步更新，上述苦恼就会大大减少。这也是什么缘故像Siebel如此的行业领先的前端办公软件开始提供与SAPR/33.1以上版本的ERP进行完全兼容的中间软件（middleware）。在那个名为SiebelEnterpriseConnector的中间软件中，这种整合通过两个方法来实现。一是通过中间文件（IntermediateDocumentIDoc）实现的整合（图示一），它能够把SAP中的差不多信息输入到Siebel中，其中IDocs接收器接收从SAP服务器中存储的关于客户户口、联系人、产品和价格等信息，然后把这些信息存入IDocs界面中，那个界面是Siebel的整合治理（EnterpriseIntegrationManager，EIM）的一部分，因此这些信息就能够完全传入到Siebel中。如此的整合不仅在CRM最初启动的时候能够用来进行数据转化，而且在ERP和CRM的同步运行中还能不断地把最新调整的产品目录、价格和折扣等信息输入到前端软件中，让销售人员能够及时地给出正确的报价。第二种整合是通过BAPI进行的即时数据支持。在这种整合中，Siebel运用SAP提供的即时界面，包括BAPI（BusinessAPI）和远程功能呼叫RFC界面（RemoteFunctionCall）组合成即时整合治理器，通过它能够把同一时刻在Siebel中生成的定单立即传输到SAP中。假如在SAP中运行SAPBAPI处理器，还能够完成同期的多个请求的并行处理。假如前端软件和后端软件需要进行如此精细的整合，而市场上提供的中间软件又不能完全满足需要的话，那么以Oracle为代表的ERP提供商们则是在它们原有的ERP客户基础上努力推动CRM的进展。与Siebel不同，OracleCRM并不需要另外增设服务器，而是在原有的OracleERP服务器上增设一个或多个CRM模块。像定单号码如此的数据，Oracle的CRM能够直接到ERP的定单治理模块（OrderManagement）中取得而不需要苦恼的转接或同步更新的程序。关于差不多运用了OracleERP的客户来讲，这一优势无疑是其他CRM提供商所不具备的。不管通过中间软件依旧在原有基础上增设模块，只要企业内部的前后端整合能够无缝进行，实现网络化的定单输入和报价也就容易多了。因为这只相当于原来对销售人员开放的前端软件延伸到了网络上而已。企业的现存或潜在客户只要能够从网络界面上获得如下信息：产品目录、单价、折扣率和库存信息之后，就能够决定是否下定单。而客户从网络上输入的定单正如销售人员输入的定单一样，这些信息能够赶忙传输到后台ERP，后台ERP在同意之后通过计算，把定单总价、定单号码和折扣金额等信息再传回到网络界面上，客户记录下这些信息，就能够随时通过呼叫中心，或与销售人员联系，接着追踪这笔定单。现在，国内的网络公司多数能够提供的仅仅是建立“电子小册子”式的网页，因而在谈到实现即时互动的双向数据流的时候就会心存顾忌。这不难理解。网络公司通常是凭借网络概念和基础的html语言、java语言建立的，要实现与ERP的联合，还要求他们必须了解后台数据库的设计和安装。而每个行业，每个企业的后台数据库都有着自身的复杂性和规范，一个航空公司的信息系统和一个银行的信息系统就可能大相径庭。能够把个人网页做得专门漂亮的技术人员，不一定能够把一个银行的所有客户余额查询实现网络化。网络经济的所有后台支撑点在于大规模的数据整合，在那个基础上，通过“网络化”的改造，“传统”企业因为本身差不多具备大规模物流、生产线和客户服务的“水泥”设施，将比那些完全依靠“虚拟经济”生存的“纯网络公司”具有更强大的竞争实力。当企业对网络的理解突破了“电子小册子”的时期，能够主动把单