ERP 管账，CRM 管客户：两套系统到底该怎么分工、怎么打通

ERP 管账，CRM 管客户：两套系统到底该怎么分工、怎么打通

一家做工业设备的公司，销售在 CRM 里做完报价，导出 PDF 发邮件给客户；客户确认后，商务把同一批明细手工录进 ERP 生成销售订单；发货之后财务在 ERP 里开票，回款到账了，再回头到 CRM 里把那条商机改成"赢单"。这条链上有四个人、三个系统、两次重复录入。

月底对账的时候问题就出来了：CRM 显示本月赢单 320 个，ERP 只有 298 张订单。差的 22 个，销售说是"客户还在走流程"，财务说是"没收到订单"，商务说"我录了但被退回了"。谁也拿不出证据。

这不是个案。几乎所有既上了 CRM 又上了 ERP 的 B2B 企业，都会在第二年撞上同一堵墙：两套系统各自都还算好用，连在一起却是一笔糊涂账。

一、两套系统打架，通常打在四个地方

客户主数据有两份。 CRM 里叫"某某汽车零部件（苏州）有限公司"，ERP 里是"某某汽车零部件公司"；一个用 8 位流水编码，一个按地区加序号。同一家客户在两个系统里有两个身份，销售的跟进记录和财务的应收账款永远对不上。集团客户更麻烦：一个集团下面五个法人，CRM 里是一个大客户，ERP 里是五个核算主体，到底按哪个口径统计营收，销售和财务能争一整个季度。

产品与价格有两套口径。 ERP 的产品主数据是为成本核算和库存服务的，字段是物料编码、BOM、标准成本；CRM 的产品目录是为销售服务的，需要的是可售配置、阶梯价、渠道价、报价单位。两边各维护一份，结果就是销售报出去的价格和财务核算的价格不是一回事，毛利率算出来永远比预期低几个点。

单据断链，靠人抄。 报价在 CRM、订单在 ERP、发货在 ERP、开票在 ERP、回款也在 ERP，唯独"客户当时为什么选我们""他在意的是交期还是账期"这类信息留在 CRM。单据流是通的，信息流是断的——财务看得到一张 87 万的订单，看不到这单是打了 12 个点折扣才拿下来的。

权限与责任模糊。 客户名称谁能改？信用额度谁定？价格谁能破？两个系统都能改，就等于没人负责。等到出了一笔坏账去追责，发现三个部门都有操作权限，谁也说不清是哪一步松的口。

安费诺（Amphenol）亚太渠道业务经理 Jessica Tan 谈选型时说得非常直接："ERP 虽然能够满足我们一定的业务需求，但无法承载销售职能。"这句话点出了分工的本质——ERP 记录"发生了什么"，CRM 记录"为什么发生"。

二、先划清边界，再谈打通

很多企业一上来就谈"打通"，做接口、做同步、做双向写入，结果越打通越乱。原因很简单：边界没划清的系统，连得越紧，错得越快。先把每个业务对象的主责系统定下来，接口才有意义。

业务对象 / 动作	主责系统	判断依据
客户与联系人关系、跟进记录、商机	CRM	关系与过程数据只在这里产生
客户开票信息、信用额度、应收余额	ERP / 财务	涉及核算与合规，以财务账为准
产品可售目录、报价、折扣审批	CRM	销售口径，随市场变化快
物料编码、BOM、标准成本、库存	ERP	生产与核算口径，变化慢但要严谨
报价单、销售订单	CRM 起草，ERP 承接	单向流转，不来回改
发货、开票、回款	ERP	结果状态回写 CRM
设备档案、服务工单、保修记录	CRM / 服务系统	客户侧服务数据，销售与客服共用

一句话概括：凡是"关系"和"过程"，放 CRM；凡是"钱"和"物"，放 ERP。 中间用"单据"连接，不要用"字段"连接——单据是有业务含义的完整凭证，字段只是数据碎片，前者可以追责，后者只会制造歧义。

三、四条打通原则

第一，主数据只能有一个主权方。 客户主数据建议以 CRM 为主权方（因为客户关系是在销售侧建立的），ERP 只读同步、不反向修改名称；而开票主体、税号、信用额度以 ERP 为准，回写 CRM。产品主数据反过来，以 ERP 的物料编码为准，CRM 只维护可售属性。主权定错，后面所有对账都是白费力气。

第二，单据单向流转，状态只回写不反写。 报价单从 CRM 流向 ERP 生成订单，订单一旦生成，明细就在 ERP 里改，CRM 只接收"已确认/已发货/已开票/已回款"的状态。允许两边同时改同一张单据，等于允许两个账本。

第三，编码映射表必须是显性的。 CRM 客户 ID 与 ERP 客户编码的对应关系，要有一张看得见、查得到、可导出的映射表，而不是藏在某段接口代码里。这张表是排查所有同步问题的入口。

第四，同步失败要有归属。 接口一定会失败——网络、字段超长、必填缺失、ERP 端审核未过。失败不能只是写进日志然后没人看，必须有失败队列、有责任岗、有重试机制、有超时告警。没有兜底方案的集成，第一次失败就是最后一次成功。

四、在 Zoho 里怎么落地

CRM 侧先把主数据管住：客户去重规则（按名称相似度 + 税号 + 电话组合判重）、必填与格式校验、角色权限控制谁能改客户名称与信用额度、报价模块的明细行与折扣审批（Approval Process）分级授权。商机阶段用 Blueprint 约束，避免销售在订单还没确认时就把商机推到"赢单"。

Books 与 Inventory 承接财务与实物：Books 管客户账套、发票、多币种与应收账龄，Inventory 管销售订单、库存与发货。CRM 的报价确认后生成订单，订单发货后开票，回款状态回写——这条链在 Zoho 体系内是原生的，不需要额外开发接口。

Flow 与 Creator 处理跨系统部分：如果 ERP 是用友、金蝶或 SAP，用 Flow 做触发式编排（订单创建、状态变更、定时对账），用 Creator 搭两张小应用——一张是前面说的客户编码映射表，一张是同步日志与失败队列，让运维同事能在界面上点"重试"，而不是去翻服务器日志。

Analytics 做最后一道校验：把 CRM 的商机金额、Inventory 的订单金额、Books 的开票与回款金额放在同一张看板上按周对齐，差异单自动按责任岗分派。三方一致率是这套集成最诚实的健康指标。

五、一个改造样本

某工业设备制造企业，年订单约 1.2 万单，销售 110 人、财务 9 人，此前是"CRM 管销售 + 国产 ERP 管账"的两套并行状态。改造时只做了四件事：把客户主数据收敛到 CRM 并建立编码映射表；把报价与折扣审批搬进 CRM 并设置分级授权；用接口把报价单向推成 ERP 订单、状态回写；用一张三方一致性看板做周度对账。

指标	改造前	改造后
客户档案重复率	18%	2%
订单录入人工环节	6 步	2 步
报价到开票平均周期	5.5 天	1.2 天
月度对账差异单	320 张	18 张
应收账款逾期率	21%	9%

值得注意的是，最后一项改善并不是集成本身带来的，而是集成之后"折扣—订单—回款"三者终于能对上号，财务才敢把账期规则真正执行下去。系统打通的价值，往往不在效率，而在让规则变得可执行。

总结： CRM 与 ERP 的关系不是"谁替代谁"，而是"谁记录过程、谁记录结果"。先把边界划清（关系与过程归 CRM，钱与物归 ERP），再守住四条原则（主数据单一主权、单据单向流转、映射表显性化、异常有归属），最后才谈接口。顺序反了，投入越多，混乱越大。