CRM 与 ERP 集成：同步哪些数据、由谁负责、如何测试

CRM 与 ERP 集成把面向客户的工作与记录订单、库存、开票及其他运营事项的系统连接起来。难点在于决定哪些记录需要传输、哪个系统有权修改，以及传输失败时团队如何得知。

从一次业务交接入手。销售人员需要已受理的订单编号，财务需要可信的开票主体信息，服务团队需要当前的交付状态。每项需求都要落实为具体的数据契约。承诺同步一切无法代替这一步。

本文介绍如何编写这份契约，并在扩大范围前测试一条工作流。权责表和订单示例均为假设，用于说明设计方法。它们不代表 Qonnex 的客户案例、现成连接器，也不表示所有 CRM 和 ERP 都支持相同接口。

为 CRM 与 ERP 集成设定一个可衡量的任务

选择触发条件和终点都清晰的交接。比如，CRM 中获授权的销售订单请求，在 ERP 中生成一笔已受理订单，再由 ERP 将订单标识传回 CRM。这样的初始范围比“让两个系统保持一致”更容易落实。

明确谁对业务结果负责。销售运营可以负责请求质量，运营可以负责订单受理，财务可以负责开票控制。IT 负责技术运行，业务责任需与相关部门共同确定。

写下哪些方面应该改善，以及如何衡量。可衡量人工重复录入时间、请求被拒的数量、未解决传输事项的积压时长，以及对账发现的差异。开发连接前，确定每项指标的数据来源。

Qonnex 的人工操作成本指南介绍了重复录入和业务交接的成本。实施需要把诊断落实为一个明确命名的工作流、一位负责人和一项可核查的结果。

先确定业务需要，再承诺实时更新。夜间更新账户余额和确认订单前查询库存，时效要求不同。对每个值规定可接受的最大数据延迟，并说明如何提示数据已过时。

梳理完成任务所需的记录

CRM 和 ERP 可以共享客户、产品、订单和财务信息，但概念并不总能对应。潜在客户并不自动成为可开票客户，销售商机尚不是已受理订单，销售漏斗金额也未必构成已确认收入。

IBM 的集成概述列出了常见的共享类别，包括客户、产品、定价和销售数据。可用它整理候选数据，再按需求决定具体传输哪些字段。

对于首条工作流中的每种记录，明确：

• 它在源系统和目标系统中的稳定标识。
• 创建所需的字段，以及后续允许修改的字段。
• 必须事先存在的关联记录。
• 允许创建或更新的业务事件。
• 确认目标系统已受理的响应。

排出依赖顺序。例如，订单请求可能依赖已核准的客户标识和有效的产品标识。定义缺少其中一项时的处理方式。为了继续传输而创建占位记录，可能把不确定性带入开票和报表。

将业务键与显示名称分开。两家公司可能名称相似，公司改名也不意味着账户发生了变化。记录两套系统的标识如何映射，以及谁有权批准修正映射。

在字段层面划分管理权

“客户归 CRM 管”通常过于笼统。销售运营可能管理客户关系和联系偏好，财务则控制开票条款和已核准的法定开票主体信息。对交接所需的字段逐项明确管理权。

下表展示的是一家假设企业可采用的方案之一。各企业应根据自身情况划分责任。

预先制定冲突处理办法。若有人在 CRM 修改由 ERP 管理的开票字段，应用应该阻止修改、丢弃更新并提示，还是向财务发出请求？请选定明确的行为。静默覆盖会降低用户对两套系统的信任。

“以最后一次更新为准”无法替代管理权规则。时间戳较新，只能说明修改发生得更晚，无法证明编辑者有权操作或数据正确。若允许并发修改，请明确版本处理规则，并规定系统无法安全解决冲突时应由谁作出什么决定。

用业务语言编写数据契约

数据契约约定一次传输的含义。流程负责人应能读懂，实施团队也应能据此编写测试。

对订单请求，应列出源标识、已核准的客户映射、明细、数量、单位、币种、必填日期和适用的验证规则。按实际业务确定如何处理折扣、税费、运输信息及可选字段。空值和零可能有不同含义。

明确精度、时区和日期规则。数量在一个系统中可能按箱计量，在另一个系统中按件计量。要求的交付日期与事件时间戳用途不同。金额必须带有币种才完整。

以下虚构请求可用于规划研讨：

这些标识为虚构示例，并非真实系统记录或截图。示例中的数量和时间也并非测量结果。

与发出请求一样，详细记录结果回传路径。销售人员需要区分已提交、已受理、已拒绝和等待确认。传输成功只能证明数据已发送，ERP 是否受理还需要相应证据。

按业务需要选择同步方向和时效

当接收系统只需显示权威值时，可以采用单向传输。当两个系统各自管理流程的不同部分时，可以双向交换。共享字段的编辑权限仍应逐项确定。

Microsoft 的 dual-write 概述介绍了 Dynamics 财务和运营应用与 Dataverse 之间的一种特定集成，包括双向传输及运行控制。其他产品的能力需单独验证，也要逐项判断是否需要双向更新。

将架构决策和业务契约分开。直连 API、集成平台和受支持的原生功能各有限制。先确定数据、时效、管理权和恢复要求，再评估哪些受支持的方案能以可接受的运行成本满足要求。

询问与这条流程有关的限制，包括支持的对象、更新方法、速率限制、批次大小、处理顺序、可用的事件通知及错误信息。查阅实际系统的最新文档核实。连接器出现在目录里，并不能证明它支持所需交易。

明确计划内维护时的处理方式。如果 ERP 不可用，请求能安全排队吗？用户是否要停止确认库存可用性？由谁决定何时恢复连接？这些问题要在第一次中断前纳入运行方案。

让失败的更新可以恢复

有些失败原因很明确，例如缺少必需的客户记录而导致请求被拒。另一些结果难以判断，例如 ERP 已受理订单，但集成系统没有收到响应。这时，订单已经存在，CRM 却仍显示待处理。

用虚构请求 DEMO-ORD-104 演练第二种情况。恢复流程要保留原标识、核实目标系统实际受理了什么，并在接口支持时取回订单标识。如果无法安全确认结果，应先提交调查，再决定是否创建订单。

让实施团队说明为什么重放是安全的。幂等操作的设计目标是重复执行同一请求时，业务影响不会重复发生。要核实实际接口是否提供这项能力，以及保护能持续多久。

有些故障无法通过重发请求或恢复旧值解决。已受理的订单可能已经触发其他工作。Microsoft 的补偿事务指南解释了为何恢复可能需要按业务采取措施，有时还需人工介入。请明确谁可以撤销、修订或以其他方式处理已受理交易。

保留足够的调查证据，包括请求标识、事件时间、源端和目标端标识、处理状态、重试记录及错误类别。避免把完整客户记录或机密信息写入运行日志。给业务用户显示可据此采取行动的状态。

对账核查业务记录，同时检查任务状态

控制面板可能显示任务成功，业务记录却仍有错误。任务可能在客户映射错误、单位换算错误或遗漏明细的情况下完成。应独立核对业务结果和传输的技术状态。

对试点范围内的数据，使用保留的标识把源请求与目标端已受理记录进行比对。检查关键字段和明细数量。将所有未匹配项解释为已拒绝、待处理、已排除或需调查，并为未解决事项指定负责人和审查频率。

定义 CRM 中“当前”数据的含义。用户应该能分辨刷新时间过久的值与刚更新的值。规定何时显示过期提示，以及用户能否基于这些数据行动。

衡量成效时计入对账工作量。如果集成减少了重复录入，却增加大量人工核查，应把这部分工作纳入比较。Qonnex 的自动化回报衡量指南解释了为何需要计入完整运行成本。

扩大连接范围前测试契约

在受控测试环境中使用模拟记录或获得适当授权的记录。测试用例应按业务契约设计。验证凭据和 API 是否返回成功，只覆盖部分要求。

记录实际结果、证据和审查人员签字确认。约定哪些故障会阻止上线，以及修正后如何复测。开发人员能够事后手工修复，并不足以判定测试通过。

让负责业务交接的人员参与。请销售人员解释一笔待处理订单，请运营人员调查一项拒绝，并由财务验证它管理的字段。各团队能否处理例外，也是验收内容。

明确连接上线后的负责人

分别指定技术负责人和业务负责人。记录谁监控失败、维护映射、批准字段变更及在缺岗时顶替。制定应用升级和接口变更的审查流程。

将访问权限限制在集成所需的记录和操作。区分测试和生产凭据，规定如何更新凭据，并确保集成账户不依赖某位员工持续拥有权限。由组织的安全负责人审核实际控制措施。

上线前制定暂停及恢复程序。流程应保留排队任务，并识别已受理事项。恢复连接时应识别哪些事件需要重放，避免从中断开始盲目重发所有事件。

首次运营审查应查看未解决的记录、过期数据、修复工作量，以及目标是否得到改善的证据。只有明确另一类记录的依赖和控制后，才扩展到该类型。显示发票状态与新建开票记录所需权限和带来的风险不同。

带着数据契约讨论实施

Qonnex 现有的运营效率服务包含连接已有 CRM、会计及运营工具。适合的范围取决于现有接口与业务规则。通常可在保留现有系统的情况下开展集成，具体的 Qonnex 连接器是否可用仍需确认。

选择实施方案前，准备四份材料：记录管理权表、数据契约、故障处理及对账流程、验收矩阵。这样就能在讨论中逐项审查需要作出的决定。

将商业安排与技术测试分开。Qonnex 的成果导向咨询说明介绍了其按成果衡量的方法。即使连接已经运行，也要证明它通过验收，并就衡量业务结果的方式达成一致。

要评估特定交接，可在业务分析中描述触发条件、涉及的系统、负责人及当前例外。先找出反复录入的记录，以及必须等到这条记录才能作出的决定。