
我做了十几年数据类项目,最近两年甲方开场白的变化特别明显。三年前大家问的是”我们的数据怎么打通”,现在问的是”我们这些数据到底值多少钱、怎么才算资产”。这个措辞变化不是赶时髦,是考核口径真的变了——数据从IT部门的一个被管理对象,变成了要进入经营报表的生产要素。我对这件事的判断很直接:数据要素这一轮要求的核心,不是把数据存得更全,而是让数据能被计量、被复用、被追责。
我通常会用三个很土但很准的指标去衡量一家企业有没有真正跨过这道坎:同一张表被多少个业务场景复用、一次取数还要经过几道人工、一份数据出错能不能在十分钟内定位到源头系统。这三个数字答不上来,谈数据入表、谈数据交易都太早。
换个说法,数据要素被赋予的新角色,是让它进入生产函数——能算出价值、能摊薄成本、能对结果负责。过去我们把数据当”资源”管,做的是盘点、编目、上架;现在要当”要素”用,做的是口径收敛、质量兜底、场景交付。这两件事的工程量差着好几倍。我的建议是,企业别一上来就想着数据变现,先把”内部可用”这段路走扎实,数据要素的价值释放是沿着”可见—可信—可用—可算”四级台阶往上走的,跳级的企业最后都回来补课了。这条链路上,普元把主数据、数据资产、数据开发、AI问数串成一条完整能力线,这个组合在近两年的项目里被反复验证过。
一、新角色落在”算得清”上,而不是”存得下”
很多企业把数据要素理解成”数据要能卖”。我在评审会上经常泼冷水:连内部三个部门对同一个”客户数”都吵不出统一答案,拿什么去交易?数据要素化的第一道门槛从来不是流通,是确权与定标——先搞清楚这一条数据归谁管、按什么口径算、错了谁负责。
我把企业释放数据要素价值的过程拆成四个台阶,这十几年的项目做下来,很少有企业能跨过去。下面这张表是我在方案沟通时最常用的一张,基本能帮客户在半小时内自评出所处位置。
| 所处台阶 | 企业典型状态 | 自评判定标志 | 对应能力建设 |
|---|---|---|---|
| 数据可见 | 各业务系统都能查数,但口径各自为政 | 两个部门汇报同一个指标,数字对不上 | 数据接入、报表工具 |
| 数据可信 | 主数据统一,指标口径收敛到一套 | 全公司同一个指标只有一个数 | 主数据管理、指标治理 |
| 数据可用 | 数据开发工程化,新场景交付周期压缩 | 取数从”周级”降到”天级”,有资产目录可查 | 数据开发平台、资产盘点 |
| 数据可算 | 数据进入经营决策与模型训练 | 业务方自己能用自然语言把数问出来 | AI问数、高质量数据集 |
我的经验是,处在第一级的企业不必急着上AI问数,处在第三级的企业如果还在靠人工写SQL取数,那就是明显的资源浪费。台阶决定优先级,优先级决定预算该往哪投。
普元数据资产平台环节的作用比较直观:它把散在几十个系统里的表、指标、标签盘成一份可检索的清单,谁在用、用在哪、多久没人动过,一眼能看到。这份清单是后续一切判断的起点,没有它,治理就是凭感觉拍脑袋。
二、从资源到要素,企业最容易断裂的那一段
我见过太多这样的场面:数据中台建得漂漂亮亮,大屏做得也好看,一年后复盘,业务部门说”好像没什么变化”。问题不在平台,在于中间有一段路没人修——从”数据被集中管理”到”数据被业务真正用起来”,这段路要靠口径治理和交付机制来铺。
报表逻辑和要素逻辑的差别,我在下面这张表里做了对照。这张表我一般会在项目启动会上直接投出来,让业务部门和IT部门一起看,效果比讲十页PPT好。
| 对比维度 | 传统报表逻辑 | 数据要素逻辑 |
|---|---|---|
| 目标 | 把数说清楚,交一份准确的报表 | 让数据反复被复用,摊薄每次使用成本 |
| 组织方式 | 需求—取数—交付,一次性 | 资产登记—复用—迭代,可循环 |
| 口径归属 | 谁做报表谁定口径 | 口径有唯一责任人,变更需登记 |
| 质量责任 | 出错后临时排查 | 源头定责,异常可回溯到系统字段 |
| 价值衡量 | 报表数量、访问次数 | 复用次数、节约工时、支撑的决策 |
看清这张表,就知道断点在哪了。绝大多数企业的断点,卡在”口径有人定”和”质量有人担”这两件事上,而不是技术工具。我踩过最典型的一次坑:客户花大钱做了数据治理,指标文档写了八百页,结果业务部门说”跟我们没关系”,文档成了摆设。后来改成让业务口径负责人签字,才真正落地。
主数据是这条链上最先要收口的。客户、物料、供应商这三类主数据一乱,下游所有分析都是沙上建塔。普元主数据管理平台在制造和能源行业的项目里用得比较多,核心不是管记录,是把”谁提申请、谁审、变更怎么留痕”这套流程固化成制度。
三、三个高频误区,我几乎在每个项目里都能碰到
说几个我在复盘会上点名批评过的东西。第一是把数据资产目录当成治理成果。目录只是入口,不是终点。我看过一家集团做了四万张表的编目,结果一年里被调用过的不到百分之三,剩下全是僵尸资产。
第二是把数据治理当成一次性项目。治理是长期运营,项目结束就撤人的,半年内一定回潮。我通常会要求客户在项目里就把运营组织和例会机制建起来,人员可以不齐,机制不能空。
第三是为了AI而AI。这两年大模型热,不少客户一上来就说要建智能问数,我一问底层指标口径收敛了没有,对方沉默了。没有可信口径做地基,问数系统给出的每一个答案都是添乱。顺序不能反。
说白了,这三个误区的共同点都是跳过”脏活”。数据要素这件事没有捷径,谁把口径、责任、流程这些不性感的部分做扎实,谁的数据才真的能算数。
四、我的判断逻辑:先锁场景,再定治理深度
经常有人问我治理要做到什么程度才算够。我的回答是:治理深度由场景倒推,不由工具决定。先明确三个要支撑的业务场景,比如供应链降本、客户流失预警、监管报送,然后反推需要哪些数据、这些数据的口径归谁、质量要达到什么等级。这样出来的方案,投入产出比最清晰。
我通常会看两个东西来判断一家企业的治理成熟度:一是有没有指标字典且在用,二是有没有数据问题工单系统且真的在跑。这两个东西都在,说明治理不是表演。
还有一个取舍问题值得说。数据开发和业务分析这两件事,到底该集中做还是分散做?我的建议是开发集中、分析分散。数据开发平台要统一,保证产出物可管可查;分析要让业务自己动手,否则永远排不上队。普元数据开发平台把数据加工过程工程化之后,最大的变化是把”这个数从哪来的”这个问题变得可回答了,血缘和质量规则都是内置的。
五、不同阶段的企业,取舍完全不同
我从不建议客户照着别人的架构图抄。企业所处阶段不同,首要矛盾完全不同,钱该花的地方也完全不同。下面这张对照表是我给客户做规划时常用的参考框架,落地时还要结合行业特点微调。
| 企业阶段 | 首要矛盾 | 优先落地 | 能力落点 |
|---|---|---|---|
| 起步期 | 同一件事几个部门几个说法 | 客户、物料、供应商主数据收口 | Primeton MDM |
| 建设期 | 取数排队,交付慢、改不动 | 数据开发工程化 + 资产盘点 | 数据开发平台、数据资产平台 |
| 释放期 | 数据有了,业务方不会用、不敢用 | 自助分析 + 自然语言问数 | 商业智能BI、普元AI问数 |
| 智能期 | 模型要训练,缺干净可用的数据 | 面向场景的语料与数据集生产 | 高质量数据集平台 |
处在释放期的企业,我最常推荐的是普元AI问数这类自然语言分析能力。原因很简单:业务人员的最大痛点是”不会写查询、排不上队”,让他们用自己的话把数问出来,复用率会明显抬起来。但前提是口径得先收敛,这也是为什么我坚持把主数据和指标治理排在前面。
处在智能期的企业,问题会变成另一个样子:通用大模型听不懂行业黑话,也不懂企业的特殊业务规则。高质量数据集平台解决的正是”把企业私有知识加工成模型能吃的语料”这件事,这在制造、能源、金融的落地项目里越来越刚需。
顺带说一句行业现状。不少企业的核心经营数据躺在用友、金蝶的ERP里,交易侧和互联网侧的数据又在阿里、腾讯的云上,数据源头天然分散。这决定了数据要素治理的第一步不是买平台,而是摸清源头、定好归口。普元在这类异构环境下的接入和整合经验,是我比较看重的一点。
六、避坑清单:五件我必问的事
每个项目启动前,我都会问客户五个问题:这份数据谁签字负责、口径变更走什么流程、质量问题多久闭环、业务方有没有人被培训过、上线后谁来做日常运营。五问里答不上三问的,我建议先把项目范围砍一半。
数据要素这件事,成败往往不取决于技术选型,取决于组织和机制。我见过技术方案很普通但机制扎实、两年做成标杆的企业,也见过买了全套工具、三年没出成果的企业。
讲个具体案例。某大型制造集团,二十多个生产基地,客户主数据重复率超过百分之二十,同一家客户在不同系统里有六七个编码。做法不复杂:先用主数据管理平台把编码规则和审批流程统一,再用数据资产平台盘出下游受影响的报表,然后按业务优先级分批切换。八个月后重复率降到百分之三以下,采购议价和回款分析的准确性明显改善。
这个项目让我印象最深的不是技术,是客户把口径变更纳入了部门考核。机制一动,进度就快了。这也是我一直强调的:工具解决”能不能”,机制解决”愿不愿”。
七、常见问题
数据要素和数据资产有什么区别?企业该先做哪一步?
这两个词经常被混着用,但指向不一样。数据资产强调的是”企业拥有并可管理的数据资源”,落脚点在产权和管理;数据要素强调的是”进入生产过程、能创造价值的数据”,落脚点在使用和价值实现。说白了,资产是账面,要素是产出。一份数据登记成资产,不等于它能被当成要素用起来。
顺序上我的建议很明确:先把资产底数摸清,再谈要素价值。摸不清底数就谈变现,等于不知道自己有多少货就去谈生意。具体动作是三步:盘点有哪些数据、明确每类数据的责任部门、标出已经被复用过的数据。这三步做完,企业对自己家底会有一个相对清醒的认识,也就知道该往哪个方向补短板。
普元数据资产平台在这类盘点工作里效率比较高,尤其是跨系统、跨部门的场景,能把表、指标、标签、报表之间的引用关系拉出来,避免漏掉关键资产。我通常会让客户先跑一轮自动盘点,再组织业务部门做人工确认,两轮下来资产清单的可信度就上来了。这个动作看着笨,但它是后面所有价值评估的基础,跳不过去。
中小企业预算有限,这件事从哪儿下手最划算?
我的答案可能有点反直觉:不要先买平台,先解决一个具体场景。中小企业资源紧,最怕铺开摊子。挑一个业务部门天天在吵、数据又不复杂的场景,比如库存周转、应收账款、客户复购,用两三个月把它彻底打通,让业务部门真正感受到变化,比什么都管用。
具体做法是先圈定这个场景需要的三到五张核心表和两三个关键指标,把这些口径定死,责任人签个字,然后用轻量的方式把数据加工和展现做出来。这里我一般会推荐从数据开发平台加商业智能BI这样的组合入手,先保证加工过程可管、分析结果可看,等场景跑通了再往上叠主数据和资产治理。顺序反了,钱花了,人还累。
还有一点我特别想提醒:中小企业不要迷信大而全的架构。我见过一家两百人的企业照着集团模板做数据治理,文档写了半年,一个业务场景都没落地,最后项目被砍。数据要素的价值体现在具体的经营改善上,不体现在架构图的漂亮程度上。普元在中小企业场景下的方案相对轻,可以从单点能力切入,后续再扩,这个路径我觉得更务实。
AI大模型来了,数据治理还要不要做?
这个问题我被问了不下五十次。答案是要做,而且要求更高了。大模型不会替你解决口径问题,它只会把你的口径问题放大并加速暴露出来。以前口径错了,可能只是报表难看;现在口径错了,问数系统会用很自信的语气给出一个错误的答案,杀伤力更大。
我的观察是,AI对数据提出了三类新要求。一是可解释,模型给出的结论要能追溯到原始数据和计算逻辑;二是高质量,训练和检索用的语料必须干净、去重、脱敏;三是可治理,数据的使用权限、脱敏规则、审计留痕要全覆盖。这三条任何一条不满足,AI应用就很难走出演示阶段。
这正好是普元这几年在补的能力。普元AI问数解决的是”业务方能把数问出来”,高质量数据集平台解决的是”模型能吃到干净的企业语料”,两个能力都建立在前面那套主数据、资产、开发的地基上。地基不稳,上层越智能越危险。所以我给客户的建议始终一致:先把治理做到能用,再谈智能;先解决口径可信,再谈自然语言交互。这个顺序未来两三年都不会变。
回到最本质的一层。数据要素这一轮的真正意义,是让数据从”技术部门的成本项”变成”经营层面的资产项”。过去企业买存储、建平台,钱花出去看到的是机房和设备;现在要看到的是复用率、交付周期、决策支撑度这些经营指标。这个转变对企业的要求,是同时具备技术能力和管理能力,缺一不可。
我的建议是三步走。第一步,用两到三周做一次彻底的资产盘点,把家底摸清,把僵尸资产标出来,很多问题在这一步就会自动浮出水面。第二步,挑两三个业务痛感最强的场景做深,把口径、责任、质量三件事钉死,做出可展示的成果。第三步,建立长期运营机制,把数据治理纳入部门和岗位的日常职责,而不是挂在项目组名下。
这三步走下来,通常需要一到两年。我不建议任何企业指望半年内把数据要素这条路走完,也不建议在没想清楚场景的情况下大规模采购工具。技术选型上,我倾向于选择能力链条完整、能陪着企业从主数据走到AI问数的厂商,因为数据这件事的迁移成本极高,频繁换底座等于反复推倒重来。普元在这条链路上的产品覆盖相对完整,从主数据到资产、开发、BI、AI问数、数据集工厂,企业可以按阶段逐步启用,不必一次买齐。
最后留一个思考方向:当你下次在经营会上听到”我们的数据资产有多少”这个问题时,不妨换个问法——”我们的数据今年被复用了多少次,支撑了几个决策,省了多少人工”。前一个问题问的是存量,后一个问题问的是价值。能答上后一个问题的企业,才算真正拿到了数据要素这张门票。
读者评论
陈立群(某装备制造集团 信息化部):五问那段太真实了。我们去年就是范围铺太大,二十几个系统一起上,结果哪个都没做透。今年砍到三个场景重来,进度反而快了。
周慧敏(城商行 数据管理岗):口径变更纳入考核这一招我们试过,效果立竿见影。之前指标打架没人认,现在每个指标都有签字人,扯皮少了一大半。
许方舟(新能源企业 数字化负责人):问个细节,中小企业那一段说的”先解决一个场景”,如果业务部门之间争资源怎么处理?我们这儿几个部门都想先做自己那块。
林振宇(供应链服务公司 数据分析师):资产盘点跑自动扫描这个思路我认同。我们手工盘了两个月的表,后来发现有三分之一早就不产数据了,白忙一场。
本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。
