企业上AI为什么建议先做主数据？

不少企业发现，AI 进了公司之后回答并不准确。往下追问，原因往往不在模型，而在数据本身：同一个客户、同一款商品、同一个物料，在不同系统里有着不同的身份和编码。主数据没有定准，AI 读到的就是一套互相矛盾的事实。

同一个客户，在三套系统里是三个身份

这两年见客户，被问得最多的一句话是：AI 都这么强了，为什么一进公司，就答不准？

这里常用一个场景来回答。细节是示意的，但几乎每家企业都碰到过。

你让企业里的 AI 助手查：上个月哪个客户回款最慢？它去查 ERP 里的应收、CRM 里的客户、财务系统里的回款。可同一个客户，在 ERP 里是工商全称，在 CRM 里是销售录的简称，在财务系统里又挂在另一个编码下。三个系统，三个名字，三个编码。

AI 分不清这是同一家公司。它可能把一家客户的欠款拆成三笔，排名一下子靠后；也可能把两家名字相近的公司当成一家。答案有表格、有排序、有结论，看起来很完整，其实是错的。

更要紧的是，企业要 AI 做的事，正在从回答问题走向执行任务：催款、对账、下单、审批。答错一个问题，人还能纠正；按错的客户去催款，按错的物料去下单，就是实打实的损失。AI 越能干，错得越快。

AI 答不准，根源通常不在模型

大模型懂语言、懂常识，但不认识你的企业。它对企业的理解，全部来自系统里的数据。

企业的系统是一套一套建起来的：ERP、CRM、SRM、WMS、电商、门店收银，各有各的建设时间和负责部门。每个系统上线，都要建一遍客户、物料、供应商、组织。各建各的，就出现了三种情况：

• 一物多码。同一个物料，研发给一个码，ERP 给一个码，仓库再编一个码。
• 一户多名。同一个客户，全称、简称、曾用名、子公司名，散在不同系统里。
• 一个组织几棵树。财务的组织、人事的组织、业务的销售区域，各是一套。

过去这些问题靠人兜着。老员工知道“这两个其实是一家”，财务手里有一张 Excel 对照表，月底一行一行匹配。这些知识在人脑子里、在表格里，不在系统里。

AI 没有这张对照表，系统给它什么，它就信什么。所以企业 AI 答不准，多数时候怪不到模型头上。换一个更强的模型，三个编码还是三个编码。

一个判断：主数据应当排在 AI 落地之前

这两年我们陪不少企业做 AI 落地，看到的问题很一致：先选模型、搭知识库、做演示场景，演示效果都不错；一接真实业务数据，就答不准、对不上，项目卡在“数据要先整理一下”。

我们的判断是：企业做 AI，第一步先把主数据管好，再谈选模型。

主数据是企业经营里的“名词”：客户、供应商、物料、商品、门店、组织、人员、科目。订单、发票、库存、回款这些交易数据，是用这些名词写成的句子。名词不清楚，句子就读不懂。

把主数据放在第一步，还有三个实际的理由：

• 范围确定。主数据就那么几个域，边界清楚，可以列清单、排优先级，不会越做越大。
• 结果可验证。同一个税号是不是只剩一个客户编码，同一种物料是不是只剩一条记录，一查就知道。
• 一次投入，处处受益。主数据变化慢、复用多。管好一次，ERP、CRM、报表和 AI 场景用的都是同一份。

还有一点常被忽略：组织和人员主数据，决定了 AI 的权限边界。谁能看哪个事业部的数据，谁能审批哪类单据，AI 替谁办事、能办到哪一步，都要靠一棵准确的组织树和清楚的人员归属。企业要的是可控的 AI，这份可控，很大一部分建在主数据上。

主数据需要承担的四件事

目标只有一句话：客户、商品、物料、门店、组织，每一个都只有一个身份、一个编码。落到实处，要做到四件事。

一、每个实体只保留一个身份

一个客户、一家供应商、一种物料，在全企业只有一条主记录。先定唯一性规则：

• 客户、供应商：按统一社会信用代码或税号，判断是不是同一家。
• 物料：按“分类＋关键特征”判断。比如紧固件看规格、长度、材质、表面处理，特征都一样就是同一种物料，名字怎么写不算数。
• 人员：按工号，并和组织归属绑定。

规则写进平台，新增时自动查重，重复的提交不了。我们给一家零食量贩连锁做过：供应商不管从采购准入、合同管理还是财务内部转客商进来，都按税号查重，由平台统一赋码，再回写各个系统。

二、编码统一，老编码不必推倒重来

集团定一套统一的编码规则，新数据只按新规则在主数据平台申请。各系统里在用的老编码不强行推倒，建立映射，新老一一对应。

映射对 AI 格外重要。员工嘴里说的是老编码、老名字，系统里存的是新编码。有了映射和别名，AI 才能把“华东那家老客户”“那个老型号的零件”对到唯一的那条记录上。

一家汽车零部件集团有 13 套 ERP。他们定了集团统一的 13 位物料编码，由分类码、分段码和流水码组成；各套 ERP 的老编码建了四层映射；新物料只在主数据平台申请，审批通过再分发。现在这套主数据跑在生产环境里，覆盖 45 个主数据域，对接 75 个系统。

三、每类主数据都有源头负责人

数据由谁产生，就由谁负责：物料归研发，客户归销售，供应商归采购，科目归财务。谁负责，谁审批。

规则写进平台：哪些字段必填，哪些必须唯一，格式怎么校验，不合规的提交不了。数据质量按唯一性、一致性、完整性、准确性定标准，平台定期检查，自动出质量报告，发给负责人。

这一件最难，也最关键。平台上线一段时间又乱了，原因几乎都是没人对数据负责，平台成了又一个录入系统。

四、统一分发，下游只读、按需回写

主数据在平台审批、赋码之后，统一分发给 ERP、CRM、财务、仓储、门店等下游系统。下游只读不改，要新增就回平台申请；下游生成的信息，比如 ERP 里的内部号，再回写到平台，映射才完整。

一家运动品牌集团把门店、客户、商品、财务四个域的主数据收到一个平台。财务域先上线，13 个模型、21 条下游链路。门店、仓库一建档，平台自动生成对应的客户并统一编码。切换时下游分发同步切换，旧的主数据系统随后停用。

分发和回写靠集成能力。我们在某整车企业基于 Dolphin Integration 建了 100+ API 接口，打通数十个异构系统和设备。

四件事做到了，再让 AI 去问“上个月哪个客户回款最慢”，各系统里的客户指向同一个编码，答案才是对的。

我们在这件事上的经验来源

得帆智能成立于 2014 年，做企业应用开发、系统集成、数据和企业 AI 的平台软件。我们服务了 2100+ 家大型企业客户，落地了 2400+ 个项目；合作的客户里，有 202 家《财富》中国 500 强、195 家中国制造业 500 强。

项目做多了，有个规律很稳定：不管客户要做应用、集成还是报表，项目一开头往往都在对编码。主数据不理顺，后面的事都快不起来。

所以，我们把这些项目里管主数据的经验，做成了自己的主数据管理平台 Dolphin MDM（原 DeMDM）。它内置物料、人员、组织、客户、供应商等标准主数据模型，支持主表、子表、独立模型动态建模；从唯一性、一致性、完整性、准确性定义质量标准，定期自动清洗并生成质量监控报告；支持页面提交、数据导入、API 多种采集方式，记录版本、历史和日志。

主数据项目成不成，功能之外，更看规则定没定、负责人有没有、分发闭没闭环。上面几家客户的唯一性校验、按负责人审批、统一分发和回写，都已经在生产环境里跑起来了。

给信息化负责人的三条建议

如果你正在规划企业 AI，这里给三条建议，每一条下周一就能开始。

建议一：拿一个 AI 场景，倒查它用到的主数据。别从“全面治理”开始。挑一个业务最想让 AI 回答的问题，比如“哪个客户回款最慢”，倒推它用到的客户、组织、科目。下周一，把 ERP、CRM、财务系统的客户清单各导一份，按税号对一遍：同一个税号有几个编码，多少条没有税号。这张表一出来，AI 能不能答准，心里就有数了。

建议二：先定负责人，再谈系统。系统上线了没人对数据负责，是主数据项目最常见的失败。下周一开个短会，把客户、供应商、物料、组织、科目各自的负责部门写下来，每类只写一个。写不下来的，或者几个部门都说归自己的，就是第一批要解决的问题。

建议三：从一个域开始，跑通分发再扩。选一个痛点最明显、下游系统最多的域，定好唯一性规则、编码规则、审批节点和分发系统，跑通“申请、审批、赋码、分发、回写”整条链路，再扩下一个域。下周一，列出这个域要分发的系统，写清每个系统现在谁在建档、用什么编码。

建议	下周一做什么	谁牵头	产出
倒查一个 AI 场景的主数据	导出 ERP、CRM、财务系统的客户清单，按税号比对	IT 和财务	一张重复客户清单
先定负责人	开短会，给客户、供应商、物料、组织、科目各定一个负责部门	CIO	一张主数据负责人表
从一个域开始	选定一个域，列出要分发的系统和各系统现状	IT	一张分发系统清单

小结

模型会越来越强，也会越来越便宜。企业之间拉开差距的，是自己的数据能不能被读懂。客户是谁，物料是什么，组织怎么分，这几个问题，企业得自己先答清楚。

主数据，是 AI 读懂企业的第一步。这一步不神秘，要的是有人拍板，业务部门一起做。

说明：本文由得帆智能整理发布，文中提到的 Dolphin MDM 等产品为本公司产品。内容根据项目实施经验整理，仅作行业交流，不构成采购建议；文中提及的其他厂商信息以各家官网为准。