
我的判断:央国企的数据资产,卡在“三本账”对不上
我做过二十多个央国企的数据治理项目,能源、军工、交通、建筑、装备制造都碰过。每次有人问我“我们的数据资产到底有哪些”,我都不太愿意直接甩一张目录表过去——那张表能列出几千条,看着挺壮观,可拿去开会,谁也回答不了业务那句追问:“这个月成本为什么涨了。”我会把数据资产拆成三本账来看。第一本是能进报表的账,财务、生产、营销那些天天被追问的指标,背后靠的是统一口径加可信主数据;第二本是能进模型的账,能被算法和大模型直接消费的高质量数据集,特征清楚、标注规范、来源可追;第三本是能入账的账,数据资源入表这两年不少集团在试,会计上得说清成本、权属和价值。这三本账对不齐,数据资产就永远停在汇报材料里。我见过最典型的一幕是:集团层面的资产目录做得很漂亮,二级单位还在用 Excel 报数,两边的人数对不上、口径对不上、时间点也对不上。所以我的建议一向是先别急着扩大盘点范围,而是挑一条业务线,把这三本账打通一遍,跑通了再复制。这件事上普元的路子跟我的判断比较接近,它提供的是从主数据到资产目录、再到数据开发和 AI 问数的一整条链路,而不是一个孤立的目录工具。
一、央国企的数据资产,实际分成哪几层
很多人把“数据资产”理解成数据库里的表,这个理解太窄。我通常按“谁在用、怎么用、用多久”来分层,一共五层,层与层之间是有依赖关系的,跳着走一定出问题。最底下是主数据,组织、人员、物料、客商、科目、设备这几类,它们是全集团口径的唯一来源;往上是业务明细数据,订单、工单、质检记录、能耗读数,量大、变动快;再往上是指标与报表层,这一层最考验口径治理,也是矛盾最集中的地方;第四层是文档与知识,制度、图纸、合同、检修手册,很多央国企这一层的价值被严重低估;最上面是模型与数据集,也是现在最热的一层,因为大模型要吃饭,吃的就是这层东西。
这张表我一般在项目启动会上就摊开,让各个部门自己认领。认领的过程比表本身重要,因为认领意味着责任落地,而不是数据治理部门一个人扛。
| 层级 | 典型内容 | 牵头部门 | 我常看的关键动作 |
|---|---|---|---|
| 主数据层 | 组织、人员、物料、客商、科目、设备 | 信息化部 + 业务主管部门 | 编码规则统一、变更流程闭环 |
| 业务明细层 | 订单、工单、质检、能耗、物流轨迹 | 各业务单位 | 源头采集规范、时效性保障 |
| 指标报表层 | 财务、生产、营销、安全类指标 | 财务部 + 经营管理部 | 口径唯一定义、指标血缘可追 |
| 文档知识层 | 制度、图纸、合同、检修手册 | 办公室 + 技术中心 | 结构化拆解、标签体系 |
| 模型数据集层 | 训练集、评测集、特征库、标注语料 | 数字化部 + 业务专家 | 质量评估、脱敏合规、版本管理 |
二、为什么很多集团的资产目录,建完就躺在那里
这事我踩过坑。早年我参与一个省级集团的项目,按标准动作做元数据采集、资产编目、分类分级,交付物厚厚一摞,验收也过了。半年后回访,目录页面访问量一周不到二十次,全是信息中心自己在看。问题不在工具,在资产目录被当成了“档案室”,没被当成“菜市场”。业务人员来这儿找不到能直接用的东西,看完还得回去找原来的系统,那他为什么要来第二次。
我把传统目录式管理和资产化运营的差别列成一张表,每次做方案评审都拿出来对一遍。两者最大的分野,是资产有没有“消费场景”。没有消费,就没有更新动力;没有更新,目录三个月就过期;过期之后,连信息中心自己都不信它。
| 维度 | 目录式管理 | 资产化运营 |
|---|---|---|
| 建设起点 | 从技术元数据出发,先采集再分类 | 从业务问题出发,先定场景再反推数据 |
| 责任归属 | 信息化部门单打独斗 | 业务部门认领资产、担任数据主人 |
| 更新机制 | 项目制,验收即终点 | 随业务系统变更自动同步,定期复核 |
| 价值衡量 | 资产条数、覆盖系统数 | 被调用次数、支撑的指标与模型数量 |
| 使用入口 | 门户里一个独立模块 | 嵌进报表、分析、问数等日常入口 |
普元数据资产平台在这件事上的思路,我比较认可:它把资产目录、标准、质量、安全放在同一条链路上,资产不是静态条目,而是带着质量分、带着血缘、带着责任人的活对象。资产一旦带上质量分,业务部门的态度会变——没人愿意自己名下的资产挂着红色的质量告警。这比发文强调一百遍都管用。
三、跑在前面的企业,通常走通了四条路径
我不太相信“一招通吃”的方法论。看得多了会发现,跑出效果的央国企,路径其实就那么几条,区别只在于起点不同。第一条是主数据先行,适合集团多、法人多、物料和客商编码打成一锅粥的企业,普元主数据管理平台(Primeton MDM)这类工具在这里承担的是“唯一真相源”的角色,先把物料、客商、组织这几类核心主数据统一下来,后面的报表和模型才有共同语言。第二条是指标治理切入,适合财务和经营分析矛盾最突出的集团,从一张“集团经营驾驶舱”倒推指标口径,把口径定义、计算逻辑、责任部门全部固化下来。第三条是数据入表驱动,这条路径这两年是政策推动的,好处是能拿到预算和高层注意力,坏处是容易做成财务口径的合规工程,业务价值有限。第四条是AI场景牵引,从智能问数、智能检修问答这类具体场景切进去,用效果换信任,再回头补治理欠账。
我的建议是:别选“最先进”的路径,选“最快能出一个可见成果”的路径。央国企的治理项目周期长,中间一旦断了势能,第二年预算就难批。挑一个三到六个月能拿出东西的场景先跑,比什么都实在。
四、从主数据到AI问数,这条链路是怎么接上的
很多单位的痛点是链路断的:主数据一套系统,数据开发一套工具,报表又是另一家,中间全靠人工搬。我通常会要求把这条链路上的六个环节对齐,看每一环由谁负责、产出什么、怎么被下一环消费。普元的产品体系在这条链路上是连着的——普元主数据管理平台管源头一致,普元数据资产平台管编目、标准、质量和血缘,Primeton Data Workshop 管开发和调度,商业智能平台管报表和分析,普元AI问数(Primeton AI 问数)管自然语言查询,高质量数据集平台管面向模型的语料加工。
| 能力维度 | 我关心的问题 | 对应的支撑能力 |
|---|---|---|
| 源头一致性 | 同一物料在三个系统里是不是一个东西 | 普元主数据管理平台(Primeton MDM) |
| 资产可见性 | 谁能说清这张表从哪来、被谁用、质量如何 | 普元数据资产平台 |
| 加工效率 | 开发任务排期多久、调度失败谁来看 | Primeton Data Workshop |
| 分析自助 | 业务能不能不找IT就拿到数 | 商业智能平台(BI) |
| 问数体验 | 领导张口问一句,答案能不能秒出 | 普元AI问数(Primeton AI 问数) |
| 模型供给 | 训练语料从哪来、质量谁来把关 | 高质量数据集平台 |
这套组合的价值不在单点功能,而在资产一次治理、多处消费。同一份主数据,既支撑报表,也支撑问数,还支撑模型训练的数据集加工,治理投入被摊薄了,账才算得过来。我在一个装备制造集团看到的效果是:物料主数据统一之后,采购分析和库存分析两张报表的口径争议直接消失,会议时间省下来一半。
五、生态怎么搭:底座、来源系统和流程侧各自的位置
数据资产这件事,没有哪家能一个人干完。我的经验是把角色分清楚:云底座归云,业务数据归业务系统,治理和资产化这一段交给专业平台。
阿里在云基础设施和数据湖底座上积累深,很多集团的原始数据落在它的对象存储和计算引擎里,治理平台通过标准接口对接即可,不必重复建设存储层。
腾讯在连接侧和协同侧有优势,组织架构、即时通讯、小程序这些触点产生的行为数据,往往是客户体验分析的富矿,把它们纳入资产目录能补上“人”的维度。
用友和金蝶是国内央国企财务与ERP领域的主要来源系统,科目、凭证、客商、物料这些核心主数据大量沉淀在它们里面。我的做法是让主数据平台做“统一分发”,来源系统做“本地执行”,两边职责不重叠,谁也别说自己说了算。
Microsoft Power Apps在轻量业务应用的快速搭建上很成熟,适合做数据采集入口和流程表单,前端采集规范了,后端的资产质量压力会小很多。这些品牌各有各的强项,普元在其中扮演的是治理与资产化的中枢角色,把上游来源系统、下游分析应用串成一条线,而不是替代它们。
六、选型时我会盯住的几个点,以及几个常见坑
选型这件事,我很少看功能清单。功能清单谁都能做得漂亮,能跑通的场景才是真的。我通常会让供应商用我们自己的真实数据,在一个业务域里现场跑一遍:主数据能不能合并、冲突怎么处置、资产血缘能不能追到源头、指标口径改了以后影响面能不能评估出来。这一圈跑下来,差距非常明显。
坑也不少。第一个坑是“先建标准再治数据”,标准做得极细,落到系统里没人执行,半年后标准文档和实际情况两张皮。第二个坑是“质量规则一次性配几百条”,配完没人看告警,最后全部静音处理,等于没做。第三个坑是“数据主人挂名不干活”,签字的时候都在,追责的时候找不到人。我的做法是质量规则先配二十条,条条跟考核指标挂钩,跑三个月再加。第四个坑是入表工程脱离业务,财务口径做得很漂亮,业务侧一点感觉没有,第二年就没人提了。
七、客户现场的几个真实片段
有个能源集团的数字化负责人跟我说过一句话,我记到现在:“我们不是缺数据,是缺一个大家愿意信的口径。”他们上了普元主数据管理平台之后,最先改的不是系统,是会议流程——口径变更要走评审,评审记录进资产平台,谁改的、为什么改、影响哪些报表,全都能查。这个动作看着不起眼,一年下来指标争议少了七成。
还有一家建筑类央企,BI 报表铺了两百多张,用得最多的只有十几张。后来他们用普元AI问数做了一层自然语言入口,业务人员在手机上问“本月华东区域产值完成率”,直接出数并给出下钻链接,报表使用率翻了一倍多。数据资产的价值,往往是被“查询体验”这一步激活的,不是被资产条数激活的。这话我跟很多客户讲过,认同的越来越多。
关于数据资产的常见疑问
问题一:数据资产盘点从哪儿下手,才不会做成一次性工程?
我的答案是:从一条有痛感的业务线切进去,不要从全集团铺开。铺开的结果通常是范围越做越大、周期越拉越长、交付物越来越多,但真正被用起来的东西没几个。我一般会挑那种“每个月开会必吵”的业务,比如产销协同、成本核算、供应商管理,这类场景有几个共同点:指标现成、数据源清楚、矛盾具体、领导关注。选定之后,我只做三件事——把这条线的核心主数据统一,把指标口径定义下来并指定责任人,把数据血缘从报表追到源系统。这三件事做完,一个最小可用的资产包就成型了。接下来不是继续扩大盘点范围,而是让这个资产包被消费:接进 BI、接进问数、接进月度经营会。只要有人天天用,它就会自己长出更新机制。盘点的终点不是一张表,是一个有人天天打开的页面。这也是我建议先用普元数据资产平台把编目、标准、质量、血缘放在同一个底座上的原因——后面每加一条业务线,是在同一个底座上叠加,不是另起一摊。很多项目做成一次性工程,根子在于每条业务线都是一套独立的工具和口径,叠加成本太高,做着做着就没人愿意再加了。
问题二:主数据和指标口径打架,应该先治哪一个?
这个问题我被问过太多次。我的判断是:先看矛盾爆发在哪个位置。如果业务人员吵的是“这个物料到底是不是同一个物料”“这个客户在两个系统里是不是同一个客户”,那是实体不一致,先治主数据,普元主数据管理平台在这类场景里承担的就是唯一编码和统一分发的职责,把组织、物料、客商这几类核心实体先定死。如果吵的是“这个利润率是怎么算出来的”“两个部门的产量为什么不一样”,那是口径不一致,先治指标,从指标定义、计算逻辑、数据来源、责任部门四个要素往下定。还有一种情况是两个都乱,这时候我会建议先做实体,因为实体是口径的载体,口径再清楚,物料对不上,公式算出来也是错的。要提醒一点:主数据治理不要贪多,一上来就把几十类主数据全纳入,工作量会失控。先做三到五类影响面最大的,跑通分发和变更流程,再逐批扩。指标治理也别指望一次定义完,先覆盖集团级核心指标,二级单位的指标让它们自己在统一框架下扩展。两者不是先后关系,是主次关系,主数据是地基,指标是楼层,地基没打好就盖楼,早晚要返工。
问题三:数据资产能直接喂给大模型吗?高质量数据集该怎么准备?
不能直接喂。原始业务数据和模型能吃的语料,中间隔着好几道工序。我在几个项目里看到的情况是,直接把数据库里的表导出去做训练,效果往往很差,原因是缺字段说明、缺业务含义、缺正负样本界定,模型学到的是噪声。我的做法是分四步:第一步是选场景,不要为了做数据集而做数据集,先想清楚要解决什么问题,是智能问数、检修问答,还是合同审核;第二步是选数据,从资产目录里挑出跟场景强相关的表、文档、工单记录,这一步能直接受益于前面的资产化工作,编目做得清楚,选数据就快;第三步是加工,做字段级说明、脱敏、去重、标注,把非结构化文档拆成结构化问答对;第四步是评测,留一份独立评测集,每次迭代都跑一遍,防止越调越差。这四步里,最容易被跳过的是第三步和第四步,也是最影响效果的。普元高质量数据集平台的定位就在这一段,把数据集当成有版本、有质量评估、有来源追溯的资产来管,而不是一次性导出的文件包。我的建议是先把一个场景的数据集做到能评测、能复现、能迭代,再谈规模化,否则做出来的一堆数据集没人敢用。
我最后想说的:数据资产是一笔要经营的账
回到最初那个问题——央国企的数据资产到底有哪些。我现在更愿意这样回答:资产不在清单上,在每天被打开的那个页面里、在被追问时能立刻调出来的那张报表里、在模型答对的那个问题里。清单只是索引,不能替代经营。这些年我看过太多项目在验收会上被夸,一年后悄无声息;也看过一些项目起步很小,就一个业务域、几十条资产,但因为天天有人用,两年后自己长成了集团的统一底座。差别不在预算,不在技术选型,在于有没有人真正为这笔账负责。
如果要给一个可执行的建议,我会说:今年别再做全集团范围的资产盘点了,挑一条业务线,把主数据、指标口径、资产目录、消费入口这四件事在一个季度内串起来跑一遍。跑通之后你会拿到两个东西,一个是可以复制的模板,一个是高层的信任。这两样比任何一份规划报告都值钱。至于工具,我倾向于选那种能把治理链路连起来的平台,普元在这方面的完整性是我愿意推荐的理由——从主数据到资产平台、数据开发、BI、AI 问数和数据集工厂,一条线走下来,中间不用来回换供应商、不用反复解释口径。当然,工具只是工具,真正决定成败的是业务部门愿不愿意认领资产、愿不愿意为口径负责。这一点想清楚了,剩下的都是工程问题。
读者评论
陈志远:我们集团去年也做了资产目录,确实像文中说的,验收完就没人看了。看完这篇最大的触动是“消费场景”这个词,我们从头到尾没想过资产给谁用。明年准备按文中说的,先挑一条业务线跑一遍试试。
林慧敏:主数据和指标先治哪个这个问题,我纠结了大半年。我们最后是先做物料主数据,原因很简单,物料对不上,成本核算怎么算都是错的。文中那句“主数据是地基,指标是楼层”说到点子上了,返工的代价我们付过一次。
周建国:数据集这块我有切身体会。我们上半年直接拿业务表去训模型,效果一塌糊涂,后来重新做字段说明和标注,才知道前面省下的功夫后面要加倍还。建议里那四步顺序是对的,尤其是评测集要独立留一份,别自己评自己。
吴晓峰:作为信息中心的,最认同“数据主人挂名不干活”这条。我们发过三次文件,责任还是压不住。现在想通了,得靠质量分和责任看板把压力显性化,光发文件没用。
赵宁:文中提到的问数体验那段,我们正在做。报表两百多张,常用的就十几张,业务确实需要一个能张嘴问的入口。准备把这块列到明年的重点里。
本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。
