ERP与Salesforce集成为什么会失败，以及如何补救

SAP与Salesforce的集成，失败通常出于业务原因，而不是技术原因。同步在运行，但数据对用户正在做的决策来说太旧了；两个系统对哪条客户记录才对意见不一；或者更新把数据流弄坏时，没有人负责。补救的办法是，从用户的决策倒推来设计，先清理数据，选择与您规模相匹配的中间件，并让每条数据流都有负责人和失败预案。

本文写给正在把Salesforce连接到SAP的CIO、销售运营负责人和集成负责人。内容包括四种失败模式、集成方案、一个可靠的集成需要什么，以及一份规格说明模板。

我合作过一些企业，系统之间哪怕只有一小时的滞后，也造成了报价错误，进而丢掉了订单。通常的原因是，没有人问过，库存数据要多新，销售代表才能据此报价。

一个集成可以在技术上运转正常，在商业上却是坏的。从这个区别出发。

同步频率与决策不匹配

批量同步对某些数据没问题。对可承诺库存、价格或订单状态则不行，因为客户期望立刻得到答案。

失败的模式：集成团队按对数据量在技术上方便的方式来构建，并依据技术理由设定批量间隔。业务方没有人去核对这个频率是否支撑用户正在做的决策。

在定下任何规格之前，先问一个问题：数据最旧能旧到什么程度，仍然有用？客户主数据的更新，每天一次也许就行。对于B2B销售中的库存可用性，超过十五分钟就是问题。

1. 01客户主数据SAP到Salesforce，24小时
2. 02价格表SAP到Salesforce，1小时
3. 03库存可用性SAP到Salesforce，15分钟
4. 04赢单商机Salesforce到SAP，即时
5. 05订单状态SAP到Salesforce，15分钟
6. 06发票与付款SAP到Salesforce，24小时

报价、订单和发票保持一致

数据质量不匹配

如果Salesforce里的公司名称格式与SAP中的客户主数据不同，每一次同步都会产生需要手工修复的不匹配。

我合作过的团队，每周都要花上数小时，在Salesforce和ERP之间核对最基本的客户信息；我也见过一些项目，光是映射客户层级就花了数周，因为两个系统对“账户”的定义不同。这两个系统各自维护了很多年，在无人映射过的地方渐行渐远。

集成之前先清理数据。这听上去显而易见，却是最常被跳过的一步。

架构与规模不匹配

点对点集成适用于两个系统、少数几条数据流和稳定的流程。这是成本最低的起步方式。

它无法扩展。增加一个SAP模块、一个新的Salesforce业务单元或第三个系统，连接就会成倍增加。每一个连接都得单独维护、测试和排障。

中间件（SAP Integration Suite、MuleSoft、Boomi或类似产品）给您一个受治理的统一层，带有集中监控和错误处理。代价是在架构和治理上的前期投入。部署了中间件却没有指定负责人的企业，最后遇到的问题与点对点相同，外加一个没人看得懂的平台。

没有集成治理

每一次Salesforce发布和每一个SAP支持包，都可能破坏一条数据流：API变更、新的校验规则、字段改动、新的认证要求。建好就被遗忘的集成，会在第一次没有做过回归测试的升级时失败。这是我见过最常见的上线后失败。

SAP Integration Suite。 SAP在SAP BTP上的集成平台，也是以SAP为中心的系统环境里的自然之选。它擅长处理IDoc、BAPI、OData和SAP消息格式，并为常见的SAP场景提供预置内容。复杂的业务流程仍然需要定制的集成流和真正的集成技能。如果您仍在使用SAP PI/PO，请注意它的主流维护将于2027年底结束，所以不要在上面构建新的Salesforce数据流。在RISE上，购买更多之前，先查一下您的合同已经包含哪些SAP BTP权益。

MuleSoft。 自2018年起归Salesforce所有，拥有丰富的连接器库、官方的SAP S/4HANA连接器，以及面向SAP订单到收款的加速器模板。如果您已经拥有它，是个不错的选择。对于SAP占主导的组织，有一个问题：MuleSoft是另一套技能，运行您SAP项目的团队，大概不是该设计您的MuleSoft架构的团队。

Boomi。 一个云集成平台（自2021年起独立于Dell），带有SAP和Salesforce连接器，入门门槛比MuleSoft低。适合想要受治理的中间件、又不想承担MuleSoft的成本或复杂度的中型市场组织。

点对点API。 在Salesforce与SAP之间直接调用REST或SOAP，可以省去中间件的成本。但它们需要严格的API版本管理、每次发布都做回归测试，以及一支同时理解两个系统的团队。对简单、稳定的情形没问题。对任何复杂的场景，它都是债务的累积器。

我的SAP CPI与Integration Suite指南更深入地介绍了SAP一侧的平台，而SAP的五种CRM选择则对这些CRM本身做了比较。

1. 每条数据流的规格说明： 字段、方向、频率、键映射，以及两个系统不一致时会发生什么。
2. 明确的失败设计。 同步失败时，传输中的数据会怎样？重试几次？谁收到告警？手工恢复怎么做？大多数集成在这里设计不足。
3. 每次升级之前的回归测试。 Salesforce每年发布三个主要版本，SAP也有自己的支持包和更新。每次发布之前，都应运行一套覆盖关键数据流的自动化测试。
4. 带告警的监控。 悄无声息的失败，比大张旗鼓的失败更糟。积压数日的错误，比几分钟内发现的错误难修得多。
5. 一位负责人。 一个人，知道这个集成做什么，能看到它何时出问题，并且有权限和权力去修复。

在任何人动笔写规格说明文档之前，每条数据流先填一行。如果有哪个单元格是空的，这条数据流就还没准备好构建。下面的数值只是示例；请与使用这些数据的人一起商定您自己的数值。

数据流	方向	触发与频率	可接受的最旧数据	记录系统	失败时	负责人
客户主数据	SAP到Salesforce	变更时	24小时	SAP	重试，然后提醒数据管家	客户主数据负责人
库存可用性	SAP到Salesforce	按请求或近实时	15分钟	SAP	显示“请向运营部门确认”标记	供应链系统负责人
价格表和条件	SAP到Salesforce	变更时	1小时	SAP	价格过期时阻止报价	定价经理
赢单商机到销售订单	Salesforce到SAP	关闭时	即时	订单创建前为Salesforce，之后为SAP	排队，并提醒销售运营	销售运营负责人
订单与交货状态	SAP到Salesforce	每个里程碑	15分钟	SAP	重试，然后提醒集成支持	集成负责人
发票与付款状态	SAP到Salesforce	每日	24小时	SAP	提醒财务系统	财务系统负责人

“可接受的最旧数据”这一列，是大多数团队从来不填的那一列。要与做决策的用户一起商定，而不是只与集成团队商定。如果您已经落后于进度，SAP Integration Suite交付延误一文讲了常见的原因。

客户记录对不上。 原因：两份客户主数据从未对齐。对策：上线前先核对，让SAP成为客户数据的记录系统，并在集成中强制执行映射。

订单状态在Salesforce里不更新。 原因：集成覆盖了报价到订单，却没有覆盖状态回传。对策：在每个订单里程碑，把状态更新从SAP SD发回Salesforce。

报价价格与发票价格不同。 原因：价格在Salesforce里是手工维护的，与SAP的定价条件渐行渐远。对策：让SAP成为价格主数据，并通过集成把价格拉入Salesforce。

SAP更新之后集成坏了。 原因：升级计划里没有集成回归测试。对策：把集成回归测试纳入每一次SAP更新的范围。

Salesforce能与SAP集成吗？

能，可以通过SAP Integration Suite、MuleSoft、Boomi、其他集成平台，或直接使用API。典型的数据流包括客户主数据同步、赢单商机到销售订单、订单与交货状态回传Salesforce、把价格带入Salesforce用于报价，以及发票和付款状态。客户主数据同步很简单。带有复杂定价、多个公司代码和实时库存的完整报价到收款，则是一个重大项目。

Salesforce是ERP还是CRM？

是CRM。它管理销售管道、商机、客户互动、营销和服务。它不过会计分录，也不管理库存。SAP才是负责财务、采购、库存和生产的ERP。集成得好，销售代表在Salesforce里就能看到库存和付款状态，财务在SAP里就能看到交易金额。

ERP与CRM集成失败的主要原因是什么？

需求是从技术出发定义的，而不是从用户的决策出发。集成按照一份本身就错了的规格说明被正确地构建出来：数据滞后四小时，价格与发票对不上，状态更新迟迟不到。在撰写技术规格说明之前，先记录每个用户群体用这些数据做什么决策，以及数据需要多新。

如何长期维护ERP与Salesforce的集成？

在每一次Salesforce发布和每一次SAP更新之前，对关键数据流运行自动化回归测试。用在失败时立即触发的告警来监控每条关键数据流，而不是等到日终报告。指定一位能访问监控、并参与两个系统变更规划的负责人。

什么时候该用SAP Integration Suite做Salesforce集成？

当SAP是主导系统、您能使用SAP BTP、并且数据流涉及IDoc、BAPI或SAP消息格式等SAP特有内容时。如果您已经在MuleSoft或Boomi上投入很大、团队缺乏SAP集成技能，或者SAP只是以非SAP为主的数据流中的次要参与者，它就是个较弱的选择。对于把Salesforce纳入范围的新RISE项目，它是自然的起点。

ERP与Salesforce的集成项目需要多长时间？

标准范围（客户主数据同步、报价到订单和基本的订单状态）使用预置内容，从范围界定到上线，通常需要8到16周，前提是数据干净、且有一名专职的集成开发人员。带有复杂定价、多个法人实体、信用管理和实时库存的完整报价到收款，通常需要4到9个月。项目中途发现的数据问题和构建期间新增的数据流，是超期的常见原因，所以在构建开始之前，先做一次数据质量评估。