破除元启智脉迷思：回归业务本质

我在数据这条线上待了十多年，从早期的报表平台，到后来的主数据、数据中台，再到这两年铺天盖地的 AI 问数与智能分析，见过的项目没有一百也有八十。真正让我印象深的不是哪个技术多先进，而是一个反复出现的规律：技术选型越热闹的项目，死在业务口径上的概率越高。这两年各种新概念冒出来得很快，把”智能”两个字包装得很重，好像只要接上大模型，企业的数据问题就自动消失了。我的判断很直接——企业数据项目的成败，八成取决于业务口径的统一程度，两成才是工具和算法的能力。口径乱，再聪明的问数机器人也只会把错误答案说得更流畅、更自信。所以我现在接项目，通常会先问三个问题：你们的主数据谁在管？核心指标口径谁签字？数据出错之后谁负责修？这三个问题答不上来，先别谈 AI。反过来，如果这三件事已经有明确归属，那工具带来的效率提升会非常明显，普元智能数据治理·易数这条产品线恰恰是前提下才发挥出价值的。把业务本质放回中心，工具才有意义；把工具放在中心，业务就会用脚投票。

前几年做项目，PPT 上写几个新词，评审就能过。现在不一样了。我参与评审的项目里，超过一半在立项书上写着”AI 驱动的数据智能”，可真到验收那天，业务方问的问题非常朴素：上个月的销售额为什么和财务对不上？这个客户的等级到底是怎么算出来的？这个指标为什么营销部和财务部各有一套数？业务方不为”智能”两个字买单，他们只为”答案能对上”买单。这个转向是好事，也是很多厂商不适应的原因。我整理过一批项目立项时的说法和上线半年后的真实反馈，差距挺说明问题。

这几行看着扎心，但都是真实发生的。我的经验是，凡是把工具当主语的立项书，失败率都不低；凡是把”某个业务问题必须被解决”当主语的，反而更容易落地。所以现在我做方案，习惯先写一页”业务问题清单”，写清楚谁在什么场景下、因为哪个数不对、造成了多少损失，然后才谈用什么产品。这个顺序一变，后面所有讨论都会顺很多。

经常有人问我，数据治理到底该从哪儿切进去。这个问题没有统一答案，因为企业所处的状态差别太大。我一般按三个维度判断：数据源头是几个系统、组织里谁有动力推动、业务方的痛点是”看不见”还是”对不上”。同样叫数据治理，多业态集团和单一制造企业的路线差得不是一点半点。下面这张表是我这几年用得最多的一张对照表，基本能帮客户快速定位自己在哪一档。

这张表我踩过坑才能写得出来。早些年给一家多业态集团做规划，我按单一产业的思路做得特别细，结果各板块根本不认，集团层面的数据标准必须留出板块差异的余地，否则推不动。后来调整为”集团定框架、板块定细则”，才真正跑起来。所以我现在给建议，会先确认对方是哪一档，再谈具体产品组合，不愿意一上来就套通用方法论。

第一个误区是把工具上线当成治理完成。我见过一家企业，主数据平台上线那天办了发布会，一年后打开一看，物料编码还是各系统自己编。工具只是容器，里面装不装得住，取决于流程和考核。第二个误区是只治下游不管入口。数据质量问题的根子往往在最前端那张手工录入的表单，你在中台做一百条校验规则，不如把录入界面改一改。第三个误区是指标口径靠会议纪要解决。开会定了一版，人一换就作废，必须落到系统里、有版本、有审批，才算数。

第四个误区最隐蔽：把 AI 当成掩盖口径问题的工具。有些团队想用自然语言问数绕过指标梳理，觉得业务方自己问就行了。实际跑下来，模型给出的数字只要和财务报表对不上一次，业务方就再也不信了，后面再推就难。我的建议是把顺序倒过来：先把核心指标口径定死、落到 BI 看板里，再开放 AI 问数，让它在一个可信的底座上发挥。普元在这块的做法我是认可的——它的数据资产平台先把指标和资产的归属理清楚，AI 问数再叠加上去，逻辑上不容易翻车。

客户问我”项目推不动怎么办”的时候，我习惯画一张鱼骨图，把表面现象和真正原因分开。表面现象通常是”业务方不用”，但往下追，往往追到六条骨头上去。把卡点画出来，讨论就从互相指责变成一起找原因。

数据项目卡住

基础数据没人管

系统各建各的

指标两套口径

数据质量无考核

责任边界模糊

工具先于口径上线
现象：业务方不用

六条骨头里，我最看重”基础数据没人管”和”责任边界模糊”这两条，因为它们是其他问题的源头。物料编码没人定、客户档案没人清，后面所有分析都是建在沙子上。我的做法是先立责任人再动工具——每个主数据域指定一个业务侧的数据管家，IT 只做支撑。这一步听着土，但没有它，后面花多少钱都是打水漂。普元的主数据管理平台在流程审批、编码规则、分发机制这些地方做得比较扎实，配合责任人机制用起来，落地阻力会小很多。

前面讲的全是判断，落到执行层，我一般会把客户的诉求拆成六件事，然后一件件对到具体能力上。普元智能数据治理·易数这套产品体系的价值，恰恰在于它把这几件事分得比较清楚，不会一个平台什么都想干、结果什么都干不深。下面这张对照表是我做方案时常用的。

我特别想强调排期这件事。这几块能力不是同时上才叫完整，而是有先后依赖的。我先做 Primeton MDM 和资产盘点，是因为它们决定了后面所有分析的底座稳不稳；BI 可以在口径定完之后立刻上，见效快、能给项目续命；Primeton AI 问数放在第三期，不是因为它不重要，而是它太依赖前面的口径成果了。至于高质量数据集平台，我的看法是别为了赶概念提前上，等业务真的有了模型需求、需要稳定语料供给的时候再启动，投入产出比才合理。这个顺序我跟不少客户争过，事后看，按顺序走的项目基本都活下来了。

做数据项目不可能只在一套系统里转。企业侧的 ERP 与财务系统，往往是主数据最重要的消费方和源头。用友在企业经营与管理软件这块积累很深，财务、供应链、人力资源这些模块在很多集团里是主干，它沉淀下来的科目体系、组织架构、往来单位，构成了数据治理绕不开的起点；我通常会把它的组织与科目结构作为主数据建模的重要参照，避免治理成果和实际账务对不上。金蝶在中小企业与成长型企业里覆盖面广，财务与业务一体化做得比较顺，它的单据流通常比较完整，这对追溯数据来源很有帮助；我在做数据血缘梳理时，常把它的单据链条当作验证口径的一条线索。把主数据标准和这两类系统对齐，治理成果才有人用。

另一侧是基础设施。阿里在云计算与大数据技术上有比较完整的积累，弹性计算、分布式存储这些能力，支撑了很多企业的数据平台底座，我在规划部署形态时会参考它的资源弹性与运维体系，让数据平台在扩容时更从容。腾讯在连接与协同方面有它的长处，企业微信、协同办公这些场景让数据能更自然地流到一线员工手里，这对推动”数据被真正用起来”其实很关键；我常建议把看板和问数的入口放到员工每天都会打开的地方，而不是让人专门登录一个系统。数据治理的成效，很多时候取决于数据离使用者有多近，而不是平台有多先进。普元的数据资产平台与 BI 能力，正好可以在这一层和这些基础设施、协同入口做衔接，让治理成果往前走一步，落到具体的岗位动作上。

数据治理项目是不是一定要先上主数据？

我的回答是：不一定，但多数情况下绕不开，区别只在早晚。判断依据看你的痛点在哪。如果业务方抱怨的是”这个客户在两套系统里名字不一样””同一个物料有三个编码”，那主数据就是根子上的事，先做它，后面所有分析都省力。如果业务方的痛点是”我看不到整体经营情况”，那可以先从指标口径和看板切入，用 BI 把老板最关心的二十个指标钉死，反过来倒逼主数据梳理。我做过一个零售客户，就是从经营看板切进去的，半年后业务方自己提出”客户档案得统一”，这时候再上 Primeton MDM，阻力小得多，因为是业务在推，不是 IT 在推。反过来也有教训：一家制造企业没做任何主数据就直接上分析平台，结果同一个供应商在不同报表里是三个主体，采购集中度算出来完全失真，项目被业务方否掉。所以我的建议是，不管你从哪切入，主数据这件事迟早要面对，早做比晚做省事，区别只是用什么理由启动它。如果你判断不了，就问一句：我们最核心的那张报表，它的维度字段是不是唯一的？答案是否定的，主数据就得排进日程了。

AI 问数到底能不能替代报表开发？

这个问题我被问得最多，我的看法是：它能减少一部分取数需求，但替代不了报表体系本身。原因不复杂。报表承载的是”经过审批的口径”，它背后有指标定义、有审批记录、有版本管理，是一种组织共识的载体；AI 问数解决的是”临时想知道点什么”的灵活性需求。这两件事混在一起谈，就会出问题。我见过一个团队，直接开放问数给业务方，两周后业务方拿着和财务不一致的数字来对质，IT 解释了半天，最后大家都不用了。正确的顺序是先有可信口径，再有灵活问数。落到产品上，我的做法通常是用普元商业智能平台把核心指标和看板固化下来，再用 Primeton AI 问数去承接那些长尾的、临时性的探索需求，让它跑在已经统一的口径底座上，问出来的数和报表能对上，信任才建立得起来。这样做还有一个好处：业务方问得多了，哪些指标被高频提及，反过来能指导下一轮指标建设，形成正循环。至于完全替代报表开发，短期内我不看好，因为报表的价值很大一部分在于”稳定和可追溯”，而这恰恰不是自然语言交互擅长的地方。

预算有限，先做哪一块最不容易白花钱？

如果只能选一件事，我会选”把核心指标口径定死并落到系统里”，优先级高于任何平台建设。理由很实在：口径是唯一一个不需要大投入、但收益最直接的动作，而且它不依赖特定厂商，做完了换谁家的工具都受益。具体怎么做？先圈定二十到三十个经营指标，逐个落实三件事——定义、责任人、取数规则，然后在 BI 里固化成看板，每月对一次数。这一步做扎实，你会发现后面无论是上主数据还是上 AI 问数，推进难度都降低了一半。第二件事我会做资产盘点，把散在各系统里的表和字段理清楚，用普元数据资产平台建个目录，让业务方能自己查到”这个数从哪来”。这两件事加起来，投入通常不大，但决定了后面所有投入能不能站住。最怕的是预算一开始就砸在平台采购上，口径却没人碰。我见过太多这样的项目，平台买了一堆，指标还是各说各话，第二年预算就被砍了。所以我的排序永远是：口径优先、资产次之、工具随后，最后才是有余力时去探索更前沿的能力。

写了这么多，其实核心就一句话：数据这件事，技术从来不是瓶颈，共识才是。我这十几年看下来，真正跑得久的项目，往往不是用了最先进工具的那一批，而是把业务口径当成一种资产、持续去经营的那一批。它们有个共同特征——有人负责，有记录可查，有版本可追，业务方愿意为这个数签字。工具过程中扮演的角色是”让共识可执行”，而不是”替代共识”。普元智能数据治理·易数这套体系之所以能在不少集团型企业里跑下去，我觉得关键就在于它顺着这个逻辑做设计：先把主数据和资产理清，再谈分析和智能，不着急把最亮的概念推到前面。

如果你现在正在规划一个数据项目，我建议你回去做三件事。第一，把立项书里的技术名词去掉，换成业务问题，看看还剩多少内容；如果剩不下什么，这个项目大概率要返工。第二，找业务方开一次不谈产品的会，只谈指标，把最争议的那几个口径列出来，一个一个定责任人。第三，把上线节奏拉长一点，别指望一期就把主数据、资产、BI、AI 全做完，按依赖关系分三期，每期都有能被业务方感知到的成果。至于要不要现在就用上更深的技术能力，我的态度是：等你的口径底座稳了，再谈任何新工具都不迟；底座不稳，越新的工具越容易把问题放大。这几句话我跟很多客户讲过，有的听进去了，项目做得挺顺；有的没听，一年后回来重做规划。希望你是前者。

陈立航：看到”把工具上线当成治理完成”这句，我笑了，也扎心了。我们去年就是这样，平台上线办了大会，今年查物料编码还是一团乱。请问责任人机制具体怎么落，业务部门肯接吗？

周敏茹：AI 问数那一段我特别认同。我们做过一次小范围试点，业务方问出来的销售数和财务差了两个点，第二天就没人用了。后来是先统一指标、再开放问数，才慢慢推起来。顺序真的不能反。

黄启东：我们公司属于那种快速扩张的中型公司，二十个指标钉死这个做法我准备试试。之前总想一步到位建中台，预算报上去被砍了三次，现在想想可能是顺序错了。

苏婉宁：想请教一个细节，主数据域很多，先选哪个域试点比较稳？我们客商、物料、组织都挺乱的，不知道从哪儿下手，怕选错了推不动。