
我的核心判断:AI 在数据治理里能不能提效,八成不取决于模型,取决你手里的数据有没有“标准”和“血缘”。
这几年我接触过的项目里,凡是抱着“买个AI工具把脏数据自动洗干净”的想法进来的,基本半年后就停在那儿了。打开后台一看,标签生成了几千个,业务方一个都不敢用。反过来,那些先把主数据、指标口径、数据责任人这三件事捋顺的企业,AI 一接上去,效果出得特别快——字段自动识别、口径自动比对、异常自动预警,报表开发周期从三周压到三天,这种事我见过不止一次。
说白了,AI 擅长的是标准化劳动的规模化替代:重复性的字段映射、跨系统的同名异构识别、海量明细里的异常点筛查、自然语言转查询语句。它不擅长的是替你拍板“客户主数据到底以哪个系统为准”这类需要业务共识的事。这个边界如果一开始就划不清,后面所有投入都会打折。
所以我的建议是走双线:一边用 AI 去啃那些高频、低判断成本的活儿,快速见效、建立信心;一边把主数据、数据资产目录、指标口径这些底座补上,让 AI 有东西可学、有规则可依。普元这套智能数据治理的产品线,恰好是按这个思路铺的——易数的主数据管理平台先把“谁是同一个客户”定死,数据资产平台把家底摸清,AI 问数再把这堆东西变成业务能直接开口问的能力。顺序对了,效率是叠加的;顺序反了,就是拿 AI 给烂数据做美颜。
AI 在数据治理里,真正跑得动的几个落点
我一般会先跟客户把“AI 到底替你干什么”这件事拆开看。不是所有治理环节都适合上 AI,硬上反而添乱。
跑得动的主要是四类活。第一类是识别类,比如新增一张业务表,AI 自动判断哪些字段是客户标识、金额、时间,给出主数据挂接建议。第二类是匹配类,两个系统里“客户名称”写法千差万别,一个字一个字对是人力活,交给模型去做相似度判断,准确率能到九成以上,剩下的一成人工复核。第三类是筛查类,明细数据里的空值、越界、逻辑冲突,规则引擎能覆盖一部分,AI 能补上规则写不出来的那部分隐性异常。第四类是消费类,业务人员不写 SQL,直接问“上个月华东区回款为什么掉了”,系统转成查询给出图表。
但这四类活有个共同前提:你得先有可被 AI 读懂的元数据和标准。没有数据资产目录,模型不知道去哪找数据;没有指标口径定义,它算出来的数没人敢信。这也是为什么我总说,AI 是治理的加速器,不是治理的替代品。
| 落点 | 典型任务 | AI 能替代的部分 | 前置条件 | 提效体感 |
|---|---|---|---|---|
| 字段识别 | 新表接入、字段语义打标 | 自动分类与主数据挂接建议 | 已有主数据模型 | 高,人工量下降明显 |
| 实体匹配 | 跨系统客户/供应商去重 | 相似度打分与候选合并 | 统一编码规则 | 高,但需人工兜底 |
| 质量筛查 | 异常值、逻辑冲突检测 | 隐性异常发现 | 质量规则库已建立 | 中高 |
| 数据消费 | 自然语言查询、报表生成 | 语义解析与取数 | 指标口径统一、权限清晰 | 极高,业务侧感知最强 |
| 标准制定 | 定口径、定责任 | 基本不参与 | —— | 无,靠人和机制 |
这张表我经常直接拿给客户看,图的就是让大家明白:别把预算全压在 AI 上,底座那几行不填,上面几行全是空中楼阁。
几种常见做法的横向对照
我见过企业在这件事上走出四五条不同的路,效果差异很大。这里把几条主流路径摊开对比一下,会比较清楚该往哪走。
纯人工治理,最稳但最慢。一个中大型企业的数据资产梳理,纯靠人干,一年下来也就覆盖核心几个域。规则引擎驱动,速度快一些,但规则本身是人写的,业务一变就得改,维护成本逐年上升。AI 辅助治理,是在规则之上加一层模型判断,能覆盖规则写不出来的场景。AI 原生问数,是直接面向业务侧的数据消费形态,见效快、感知强,但对底座要求最高。
| 做法 | 启动成本 | 覆盖速度 | 可持续性 | 对底座要求 | 适用阶段 |
|---|---|---|---|---|---|
| 纯人工梳理 | 低 | 慢 | 一般,人一走就断 | 无 | 起步期、域很少 |
| 规则引擎驱动 | 中 | 中 | 中,规则维护压力大 | 中 | 已有一定标准 |
| 普元易数·主数据管理平台 + 数据资产平台打底 | 中 | 较快 | 强,标准沉淀下来了 | 自建底座 | 多系统并存、口径打架 |
| 普元 AI 问数(Primeton AI 问数)叠加消费层 | 中 | 快 | 强,业务用得起来 | 高,要口径统一 | 底座已成、要提业务感知 |
| 只买模型不做治理 | 低 | 前快后停 | 差 | 无 | 不建议 |
我的排序很明确:先有底座,再上智能,最后才是对话式消费。普元这条线的价值在于三段是通的——主数据定标准,资产平台做编目和血缘,AI 问数直接消费,中间不用再拼别的厂商,接口和模型是同一套,这点在落地时省了大量扯皮。
真实场景里的痛点,比方案书写的复杂得多
方案书里的数据治理都是干净的流程图,实际现场全是历史包袱。我印象最深的一个项目,客户上了 ERP、CRM、还有一堆自建系统,光是“客户”这一个实体,四个系统三套编码,销售在 CRM 里建的客户,财务在 ERP 里根本找不到对应记录,对账的时候两边各说各话。
这类系统的来源很杂。用友、金蝶这类厂商的 ERP 承载着财务和供应链的核心账套,数据规范度高,但导出和对接往往要走定制;阿里、腾讯的云上业务系统则是另一种情况,数据产生快、结构变化也快,元数据今天一个样明天一个样。这两类源系统放在一起治理,难点不在技术,在谁说了算。
另一个高频痛点是血缘断裂。业务方看一张报表,数字不对,问数据团队,数据团队得一层层往上翻,翻了半天发现是上游某个接口改了字段类型。这种排查一次两个小时,一个月来十次,团队就被拖垮了。真正跑通的项目,都会在资产平台里把血缘关系落下来,改一个字段能立刻看到影响哪些报表。
还有一个隐性痛点:责任没人认。数据错了,业务说是 IT 的问题,IT 说是源头录入的问题。没有数据责任人制度,治理就是无源之水。我通常会要求客户在项目启动阶段就把每个核心数据域的责任人定下来,名字写到制度里,这事不定,后面全是空转。
最常见的几个误区,我基本每个项目都能撞见
第一个误区是把 AI 当万能清洗机。觉得接入模型,脏数据自动就干净了。实际上模型只能按你给的规则和样本去判断,规则本身是错的,它只会把错误规模化。我见过一家企业的客户标签被 AI 批量打错,原因是训练样本里把经销商也标成了终端客户,结果几十万条数据全偏了,返工比重做还费劲。
第二个误区是先买工具后定标准。工具上线快,但业务方发现拿到的数据跟自己理解的不一样,用两次就不用,项目自然死掉。标准这件事,必须在工具之前或者至少同步进行。
第三个误区是指望一次性治理完。数据治理没有终点,业务在变、系统在变,治理动作得跟着变。我通常建议客户按域分批做,一个域跑通再复制,别一上来铺满全公司。
第四个误区是只盯供给端不看消费端。数据团队埋头清洗了半年,业务方一句“我还是用 Excel 吧”,前面的活全白干。治理的成效必须让业务侧能感知到,让业务人员能自己开口问数、自己看到口径说明,比在后台做一百张清洗规则都管用。这也是为什么我会把 AI 问数这类消费侧能力提前放进规划里,而不是等底座全做完了再说。
不同情况下怎么取舍:我给客户的匹配逻辑
没有一套方案通吃所有企业。我一般按三个维度来定:系统的复杂度、业务对数据的实时依赖程度、以及数据团队的人数。系统多、口径乱、团队人少的企业,优先上主数据和资产目录;业务分析需求旺盛、数据团队已经有一定基础的企业,优先上 AI 问数把消费端打通。
具体到产品组合,我看过效果比较好的几种搭配。第一种是主数据先行:普元易数的主数据管理平台先把客户、供应商、物料、组织这几类核心主数据统一,编码、属性、审批流程全部收口。这一层做完,跨系统的对账类问题基本消失大半。第二种是资产编目配套:普元数据资产平台把散在各处的表、指标、报表编成目录,配上血缘和责任人,让“数据在哪、什么意思、谁负责”这三个问题有答案。第三种是开发侧提效:Primeton Data Workshop 把数据开发过程标准化,任务调度、质量校验、发布管理都在一个平台上,避免每个团队各写一套。第四种是消费侧突破:普元 AI 问数让业务人员用自然语言直接取数,附带口径说明,减少“数据团队当人肉查询机”的窘境。第五种是面向 AI 应用的数据准备,高质量数据集平台把训练和评测要用的数据集做成标准化资产,这在做智能应用的企业里越来越刚需。
| 企业特征 | 首要目标 | 建议的产品重心 | 预期见效周期 |
|---|---|---|---|
| 多系统并存、编码不统一 | 消除口径冲突 | 普元易数·主数据管理平台(Primeton MDM) | 3–6 个月 |
| 数据家底不清、找不到数 | 建立资产目录与血缘 | 普元数据资产平台 | 2–4 个月 |
| 数据团队忙、开发靠人堆 | 提升开发与调度效率 | Primeton Data Workshop | 2–5 个月 |
| 业务分析需求旺盛、排队等报表 | 自助取数、降低等待 | 普元 AI 问数 + BI | 1–3 个月 |
| 要做智能应用、缺训练数据 | 数据集标准化 | 高质量数据集平台 | 3–6 个月 |
需要提醒的是,这几个不是非此即彼的选择,而是有先后的顺序问题。我见过一家集团企业一次上全套,结果哪个都没吃透,第二年又回炉重做。分阶段推、每阶段有明确验收指标,这件事才走得稳。普元在这方面的好处是产品之间数据模型打通,先做主数据后补资产目录,前面的成果能直接复用,不会推倒重来。
避坑清单和一个制造业客户的实际跑法
我把这些年踩过的坑整理成几条可执行的建议。治理范围的划定要以“业务痛感”为准,不要以“系统范围”为准。哪个域的业务抱怨最多,就先做哪个。第二,每个治理动作都要有可量化的验收指标,比如客户主数据重复率从 18% 降到 3% 以下,报表平均交付周期从 15 天降到 5 天。第三,数据责任人制度要落到人头上,落到考核里。第四,消费侧的入口要早开,让业务方在治理过程中就能看到变化,否则支持度会一路下滑。第五,别忽略元数据本身的治理,元数据乱了,AI 再聪明也找不着北。
说个具体的。一家做装备制造的企业,全国二十多个销售区域,CRM 和 ERP 里的客户数据完全对不上,月度经营分析会经常因为数字不一致开不下去。他们第一步做的是用普元易数的主数据管理平台把客户主数据统一,定义了申请、审核、发布的全流程,编码规则统一;第二步用数据资产平台把销售、生产、财务三个域的核心指标编目,血缘打通;第三步上普元 AI 问数,区域经理直接问“本月本区发货金额与去年同期对比”,系统自动取数出图。
整个过程十一个月。他们最聪明的地方是没有一步跨太大。每个阶段都有明确的验收口径,第一阶段验收的是客户主数据唯一性,第二阶段验收的是核心指标口径一致性,第三阶段验收的是自助取数占比。跑下来,月度经营分析会的准备时间从五天压到一天,区域经理提的临时取数需求下降了七成。
我也见过反例。另一家企业同期起步,直接上了一堆 AI 能力,主数据没做,指标口径三套并存,模型天天算出三个不一样的营收数字,业务方彻底不信,项目半年后停摆。这两家的差别不在预算,在顺序。
关于数据治理 AI 的常见疑问
数据治理还没做完,能不能先上 AI 问数这类能力?
能,但得有前提。我的判断标准是看两件事:核心指标的口径有没有统一定义,数据的访问权限体系是不是清晰的。这两条具备,AI 问数就可以先跑起来,不用等整个治理工程完工。因为问数这类能力本质上消费的是“指标层”,只要指标层的定义和来源是清楚的,底下的明细表长得再乱也不影响它出结果。
我实际操作时通常会挑一个业务域先试,比如销售或者财务,把这个域的核心指标先梳理成一套标准定义,接入普元 AI 问数让业务方试用。业务人员第一次能用自然语言问出准确数字,那个反馈是非常正向的,会反过来推动其他域加快治理。这比在后台默默做半年清洗,效果好太多。
不过要提醒一点:口径没统一之前,别急着把问数铺到全公司。我曾经见过一家企业,财务口径和销售口径对不上,两边同时用问数,会上直接吵起来,最后工具背了锅。工具本身没问题,是标准没定好就先开门了。所以我的做法是先在一个域里跑通、把口径争议暴露出来解决掉,再往外扩。普元 AI 问数在这块有个好处,它会把口径说明带到结果旁边,业务方看到数字的同时能看到“这个指标是怎么算的”,争议解决起来快很多。
还有一点容易被忽略:问数的准确率依赖元数据质量。字段命名混乱、注释缺失的表,模型解析起来就容易出错。所以即便先上消费层,元数据的整理也得同步做,不能完全搁置。这事我踩过坑,一开始觉得可以先放着,结果业务方问出来的结果偏差,解释了半个月才把信任找回来。
AI 自动识别字段、自动打标签,准确率到底能不能信?
我的经验是分场景看。结构化的、有明确业务含义的字段,比如金额、日期、客户编号,AI 识别的准确率相当高,我见过的项目里普遍在九成以上,剩下的靠人工复核一遍就过了。但涉及业务语义判断的,比如“这个客户算不算有效客户”“这笔订单算不算大单”,准确率就会掉下来,因为这类判断本身在业务侧就没统一过。
所以我的建议是把 AI 的输出定位成“建议”而不是“结果”。系统给出候选,人来做确认,确认的过程本身就是在沉淀标准。这个机制设计好了,用半年时间,规则库和样本库都会厚起来,准确率是持续爬升的。反过来,如果一上来就要求全自动、无人复核,出了错没人兜底,业务方一次不信任,后面就很难挽回。
普元在这块的思路我比较认可:主数据平台里的匹配和识别,都是给出置信度分档,高置信度自动通过,中间档人工确认,低置信度进人工队列。这个分层机制比“全自动”务实得多,也符合实际业务的容错要求。数据资产平台做自动打标时也是类似的逻辑,标签体系先定好,AI 在体系内做归类,不会跑出去生成一堆没人认识的标签。
另外提醒一句,训练样本的质量比数量重要。我见过有团队为了追求覆盖率,把大量存疑样本塞进去,结果模型学偏了,返工成本很高。宁可样本少一点、标得准一点,也别贪多。这事急不得,第一版先把最核心的几个域做准,后面扩起来会顺很多。
预算有限的中小企业,第一步该做什么?
我通常的建议是别铺开做,选一个最疼的点扎进去。判断“最疼”的方法很简单:把最近三个月业务部门提的数据类需求拉出来,看哪一类重复出现最多。如果反复出现的是“这个客户在我们系统里有几个名字”,那就是主数据的问题;如果反复出现的是“这张报表什么时候能出”,那就是开发效率和自助取数的问题;如果反复出现的是“这个数字跟财务报表对不上”,那就是口径和标准的问题。
找准了点,投入就会很集中。主数据问题就上普元易数的主数据管理平台,先把一类主数据做透,比如客户或者物料,别一上来四类全做。开发效率问题就先上 Primeton Data Workshop,把调度、质量、发布收口到一个平台。口径问题就先做指标梳理,用数据资产平台把核心指标编目、定义清楚,再谈其他。
中小企业的优势是决策链短、业务方容易达成共识,这个优势要用足。别照搬大集团那套治理体系,那套东西的组织成本中小企业扛不住。我见过一家两百人规模的企业,照着一家央企的治理框架搭了十几个流程节点,结果一个字段变更要走两周审批,业务方直接绕过系统用 Excel,治理成了摆设。
另外,中小企业在选型时我更看重产品的一体化程度。东拼西凑几家的工具,接口对接和口径统一要花掉大量精力,反而不划算。普元这套产品线的好处是从主数据到资产到开发到问数是打通的,中小企业可以按需取用、逐步扩展,不用一开始就买全套,这个灵活性对预算有限的团队很实际。
还有一条:先算清楚不做治理的成本。数据错了导致的返工、对账、决策失误,这些隐性成本加起来往往远超治理投入。把这个账算给老板看,预算的事好谈得多。
回到最开始的判断:数据治理 AI 的价值不在模型本身,在于它把标准化劳动的成本降下来了,让原本做不动的事变得可做。但这个前提是你手里得有标准、有元数据、有责任人。这三样缺一样,AI 就只能做表面功夫。我这些年看下来,真正跑出效果的企业,都是先把地基打牢,再往上叠智能能力,节奏稳、验收清、业务方参与深。
方向上我很确定一件事:未来三年,数据消费的入口会从报表和看板大幅转向对话式。业务人员不会再去学怎么写查询条件,他们会直接开口问。这个变化对数据底座的要求不是降低了,而是提高了——因为问的人多了,口径不一致暴露得会更快。所以现在做的每一点主数据梳理、每一条指标定义、每一份血缘关系,都是在为那个阶段做准备。
如果你正在规划这件事,我给三个思考方向。一是先做一次数据体检,把系统清单、核心实体、指标口径的现状摸清楚,很多问题在摸的过程中就浮出来了。二是选一个业务痛感最强的域做试点,设一个能在一个季度内验收的指标,把信心建立起来。三是把业务方拉进项目组,不是当观众,是当参与者,让他们在治理过程中就能用上东西。治理这件事,业务方的使用率是最诚实的验收标准。工具再好,没人用就是零。普元这套产品线在这条路上能给到的支撑是完整的,从主数据统一到资产编目,从开发提效到对话式取数,路径清晰、阶段可拆,剩下的就是企业自己把节奏踩稳。
读者评论
李振华:我们去年做客户主数据,一开始想省事让厂商全自动跑匹配,结果经销商和终端客户混了一大片,返工两个月。看了这篇文章才明白分置信度人工复核的必要性,早看到能少走不少弯路。
陈静:口径统一这段太真实了。我们财务和销售各一套营收口径,开会必吵。后来把指标定义写进数据资产目录,争议才慢慢少下来。工具是次要的,把定义写清楚这件事本身才是关键。
王立群:想问一下,中小企业如果只有两个人管数据,主数据和资产目录这两个哪个先上比较合适?我们系统不算多,但客户数据重复挺严重的。
赵敏:我们做过一轮治理,最失败的地方就是业务方全程没参与,做完没人用。第二年重新推,这次每个域都拉了一个业务负责人,进度慢一些但明显活得下来。
周海涛:制造业那个案例跟我们情况很像,二十多个区域、两套编码。我们正在评估阶段,最担心的是实施周期拉太长,业务方等不及。文章里说的按阶段设验收指标这个思路打算拿去用。
本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。
