普元数据中台如何在企业案例中发挥关键作用？你是否了解成功企业的实践经验？

我做过不少数据相关的项目，也旁听过很多次“验收会”。有个现象反复出现：大屏做得挺漂亮，指标口径对不上，业务部门开着会，转头还是回去拉 Excel。这事我踩过坑。真正让数据中台在企业里站住脚的，往往不是技术架构有多先进，而是它有没有把“业务能不能直接用”这件事放在设计的第一位。我的判断是：数据中台的价值不体现在建成了多少张表、接入了多少个系统，而体现在业务人员愿意打开它、敢用它做决策。我通常会从三个角度去看一个中台项目到底成没成：第一，取数的路径有没有变短，业务提个需求是不是还要等两周；第二，同一个指标在不同部门是不是只有一个答案；第三，平台上的数据资产有没有人真的在查、在引用、在反馈。这三条里只要有一条不成立，架构图画得再完整，也只是个展示工程。

在普元的实践里，我看到过一条比较务实的路径：先把数据标准和主数据这两件“脏活”做扎实，再用数据开发平台把加工链路固化下来，用资产平台把“有什么数据、谁负责、怎么用”讲清楚，等这些底座稳定了，BI 和 AI 问数这类面向业务的前端才有意义。顺序错了，前端再花哨也会被数据质量问题拖垮。下面我按自己实际参与过的项目节奏，把这套逻辑拆开讲讲，包括我见过的好做法和走过的弯路。

我接触过的企业中，数据中台上线后陷入停滞的大致有三类。第一类是平台闲置型，数据仓库里堆了几百张表，业务侧却没人知道该从哪查起。第二类是口径打架型，财务算的营业收入和业务算的对不上，开会先花半小时对数字。第三类是人力瓶颈型，数据团队七八个人，一大半时间在写临时 SQL 应付取数需求，真正的建模工作一拖再拖。

把这三类摊开看，根子其实不在技术选型上。我做过一次复盘，发现项目立项时讨论最多的是“用什么引擎、接多少系统、TPS 多少”，几乎没有人认真回答“谁在用、用来干什么、用完怎么评价”。数据中台不是一个交付物，它更像一条持续运转的产线，产线的价值由下游订单决定，而不是由机器参数决定。

这张表我一般会拿给客户的项目组看，让大家先对号入座。对不上号的很少，对上了又肯承认的，项目往往还有救。因为一旦知道问题出在“资产没人管”还是“口径没统一”，投入的方向就清楚了，不用再盲目加机器、加人力。

我的经验是，只要企业有多个业务系统，客户、供应商、物料、组织这几类核心实体就一定会有重复和冲突。销售系统里叫“XX科技有限公司”，ERP 里叫“XX科技”，财务那边还挂着一个带括号的简称。上了中台之后，这些脏数据被集中起来，反而放大成大问题——指标算不准，报表不敢发，业务自然就不信了。

在普元的项目里，主数据管理平台（Primeton MDM）通常是最先被推上去的那一块。它的价值不在“能建模型”，而在于把申请、审核、分发这套流程跑通了，让新增一个客户不再是各个系统各录一遍。主数据治理最难的不是技术，是让业务部门接受“录一次、全网用”的规则，这件事必须靠流程和责任人扛住，光靠工具推不动。

下面这张表是我常用来向业务方解释差别的方式，左边是很多企业现在的状态，右边是主数据管理跑起来之后的状态。

先把“一个客户只有一个身份”这件事做成，中台后面所有的分析才有意义。我见过跳过这一步直接上报表的项目，做出来的客户数比实际多出两成，最后整批报表推倒重来。

第一个信号是取数时长。项目启动前我会问业务部门：你现在要一份数据，从提出到拿到手要多久？如果答案是“三天到两周”，而半年后还是这个数字，那这个中台基本没生效。取数时长是衡量数据中台最诚实的一个指标，它骗不了人。

第二个信号是资产被引用的次数。普元的企业数据资产管理平台会把表、指标、报表都登记成资产，谁建的、谁负责、被谁用过，一目了然。我会调出这份使用记录看，如果大量资产半年来零调用，说明资产目录只是做了个“登记动作”，没有形成消费闭环。

第三个信号是数据开发平台上的作业是否收敛。过去每个项目组各写各的脚本，逻辑散落各处，一旦人员流动就没人维护。用 Primeton Data Workshop 把加工链路统一管起来之后，作业有版本、有依赖、有调度记录，这属于典型的“不出事看不出价值，出事时救命”的基础设施。

第四个信号是业务侧有没有自发的使用行为。这个最难伪造。当销售自己打开 BI 看区域达成，当管理层直接用自然语言问“上个季度华东区的回款为什么掉了”，而不是让人去做 PPT，才说明数据真的进入工作流了。自发的使用行为，是数据中台从“项目”变成“工具”的分水岭。

第一个误区是把中台当成一个“大而全”的一次性工程。规划做了三年，第一期就要把所有系统全接进来，结果工期一拖再拖，业务等不及，自己又拉起了 Excel 队伍。我的建议是把首期范围压到“一个业务域、三条核心链路、五个关键指标”，先跑出一版能用的东西。

第二个误区是先买 BI 后治数据。工具好不好用是一回事，数据准不准是另一回事。我见过一家企业，BI 平台的采购做得很早，上线三个月使用率极低，原因不是界面难用，是业务发现查出来的数是错的，从此不再打开。

第三个误区是把数据治理当成 IT 部门自己的事。数据标准不是技术文档，它是业务规则。客户怎么定义、订单怎么算有效、退货算不算收入，这些必须业务拍板。IT 能提供工具和流程，但定不了业务口径，这个边界一开始就要讲清楚，否则项目会卡在无数个“这个字段到底什么意思”的会上。

第四个误区是忽视人员的延续性。中台不是交付完就结束的系统，它需要有人持续维护标准、审核主数据、优化作业。我通常会建议客户在项目验收的同时，把数据治理的组织和例会机制一起定下来，哪怕只是每月一次的口径评审会。

我不太相信“一招通吃”的建设路径。集团型企业和单体工厂，需要的顺序完全不一样。集团型企业的痛点在多业态、多法人，主数据和标准必须先立起来，否则各板块各算各的；单体企业的痛点常常是数据分散在几个系统里，先做集成和统一开发平台更划算。

我在普元的项目里看到的组合方式，大体可以按阶段拆成下面这张对照表。它不是标准答案，但能帮项目组少走一年弯路。

阶段判错，投入就会打水漂。我在一个客户那里看到过很典型的错配：主数据还没统一，就先上了一套自助分析，业务查出来的客户数是重复的，用了两周就没人再登录。反过来，另一个客户先把 MDM 跑通，再上 BI，业务第一次打开就发现数据对得上，一个月内活跃用户自己涨了起来。

这家客户年营收几十亿，下面有十几个事业部，ERP、MES、CRM 各有一套，客户主数据重复率我印象里超过三成。项目组一开始想直接做经营分析驾驶舱，我建议先缓一缓，把客户和物料这两类主数据统一了再说。

第一阶段的动作很朴素：梳理客户编码规则，把申请审批流程搬到 Primeton MDM 上跑，历史数据做清洗合并。这个过程花了差不多四个月，业务部门抱怨不少，但做完之后，重复客户从三成降到个位数。第二阶段才把加工链路收敛到 Primeton Data Workshop，把原来散落在各事业部的脚本统一管起来，作业负责人和调度依赖都登记清楚。第三阶段上线 BI，先做五个管理层最关心的指标，跑了一个季度没问题，才逐步放开到业务自助分析。

后面他们还多做了一步，我觉得挺有价值：把一些常见的口头提问整理出来，用 Primeton AI 问数接进去，管理层直接在移动端问“上月哪几个事业部毛利下降”，系统给出结果和明细。这件事的意义不在于工具多先进，而在于它把“问数据”的门槛降到了不需要培训的程度。至于后面要为模型准备训练语料，他们也在评估高质量数据集平台，考虑把设备维保记录这类文本整理成可用的数据集。我的看法是，这条路走得稳，因为底座已经在那里了。

这两件事在概念上确实分得开，但在落地时我从来不会把它们当成两个独立项目来做。数据中台解决的是“数据怎么汇聚、加工、服务出去”，主数据管理解决的是“核心实体是不是唯一、准不准”。前者是管道，后者是水源。水源浑的，管道修得再漂亮，流出来的还是浑水。

顺序上，我的建议是看企业当前最痛的点在哪。如果各系统客户、物料重复严重，报表口径天天打架，那就先把主数据做起来，用 Primeton MDM 把编码规则、申请审批、分发流程立住；如果数据本身还算干净，只是取数慢、链路散，那先做统一的数据开发平台更见效。也有不少企业是两条线并行，主数据负责核心实体的治理，数据开发平台负责加工链路，两边共用一套数据标准。需要提醒的是，主数据治理一定要有业务部门参与定规则，IT 只负责工具和流程，这个边界一开始就要谈清楚，否则项目会在无数场口径评审会里耗尽耐心。另外主数据的范围别铺太大，先做客户、供应商、物料这三类，跑顺了再扩，我见过一上来铺十个域的，两年都没收口。

能不能替代，取决于你把“问数”用在什么场景。如果是固定口径的经营指标，比如区域达成、库存周转，我仍然建议用 BI 的固定报表，因为它是确定的、可审计的；如果是临时性的、探索式的提问，比如“上个月哪几个客户回款异常”，那自然语言问数的效率提升非常明显。它替代的不是 SQL，而是“提需求—排队—等数据团队写—改口径—再等”这条冗长的链路。

我要提醒的是，问数工具的效果高度依赖底层的语义层和数据质量。指标定义如果没统一，问出来的结果照样会飘。所以在普元的方案里，Primeton AI 问数通常是建立在已经治理过的数据资产和统一指标之上的，而不是直接怼到原始库上。这种做法的好处是答案可解释，能点开看明细和口径来源，业务敢用。实施上我会建议先挑二三十个高频问题做验证，确认准确率达标再全面放开，同时保留人工复核的入口。这件事急不得，一旦业务问出一次明显错误，信任重建要花很久。

这个问题我在每次立项评审上都会被问到。我的答法是把收益拆成可观察的行为变化，而不是去算一个虚幻的 ROI 数字。具体看三条：取数需求的人工工时下降多少、报表重复开发减少了多少、业务决策的周期缩短了多少。这三条都能在数据资产平台上找到痕迹，比如资产调用记录、需求工单量、报表上线周期。能拿出行为数据的项目，才谈得上算收益。

避免变成成本中心，关键在“有人用”。我的经验是设立数据产品经理这类角色，把数据当成产品来运营：定期看使用情况，没人用的资产就下线或重构，高频需求就做深。普元的数据资产平台在这件事上帮得上忙，因为它把资产的使用情况记录下来了，运营有了抓手。另外一点，别指望一步到位地把平台铺满所有业务域，按业务域分批推进，每个域都跑出几个被真实使用的场景，比一次性铺开十个域却没人用要划算得多。至于预算分配，我通常建议把治理、开发、消费三块的投入按大致四三三来排，很多项目的问题恰恰是开发占了八成，治理和消费各留一成，结果就是数据进去了、没人用。

回到最初那个问题——数据中台怎么在企业里发挥关键作用。我这些年的体会是，它从来不是一个靠技术方案就能解决的命题。真正的分水岭在于，企业有没有把“数据能不能被用起来”当成验收标准，而不是把“系统有没有上线”当成终点。

我见过跑得好的项目，几乎都遵循相似的节奏：先用主数据把核心实体统一，让业务第一次感受到“数是对的”；再用统一的数据开发平台把加工链路固化，让数据团队从救火里解放出来；然后用资产平台把家底讲清楚，让业务知道有什么、能找谁；基础上，BI 和 AI 问数才有真正的用武之地。这套路径不惊艳，但稳。数据能力的积累是复利型的，前期慢，后期会加速。

我也见过不少企业卡在“要不要先做大平台”的纠结里。我的建议是把问题换个问法：未来半年，你希望哪三个业务场景因为数据而变得不一样？把这三个场景写下来，倒推需要哪些数据、哪些标准、哪些加工链路，范围自然就收敛了。普元这套产品体系的组合方式，本质上也是围绕这个逻辑展开的——不是让企业一次买齐所有能力，而是按阶段把该补的短板补上。

还有一点我想强调：数据治理是长期活，没有终点。企业在推进过程中一定会遇到业务不配合、口径反复、数据回流的各种情况，这都正常。关键是建立一个能持续运转的机制——有责任人、有例会、有评价。工具能解决效率问题，机制才能解决持久问题。把机制建起来，平台才不会在验收后慢慢冷掉。如果读者正在为某个具体场景发愁，比如主数据清洗的历史包袱怎么处理，或者自助分析的推广怎么破冰，欢迎在下面留言，我看到会尽量给些具体建议。

陈立群（制造业信息化负责人）：我们去年就是踩了“先上 BI 后治数据”的坑，报表上线两个月没人点开，后来回头补主数据才缓过来。文中说的取数时长这个指标很实在，我准备拿它去跟老板汇报。

周敏华（集团数据治理岗）：主数据那块深有同感，最难的真不是工具，是让各事业部接受统一编码。我们推了半年，现在重复客户从两成多降到个位数，过程确实磨人。

许文博（零售行业数据分析师）：问数工具那段说到点上了。我们试过直接怼原始库，业务问两次答案不一样，就再也没人用了。现在改成基于治理过的指标层，准确率高了不少，但前期梳理指标确实费功夫。

高振宇（能源企业架构师）：想请教一下，多个子公司数据标准不一致但业务又不想动，这种情况从哪个域切入比较容易破冰？我们现在卡在这儿。