普元天辰中台案例复盘：如何通过数据分析提升运营效率？您是否想了解成功背后的关键策略？

中台项目的价值不在上线那天，而在上线之后的第六个月，还有多少人每天打开它。我做过几个数据中台相关的咨询和落地陪跑，见过太多“上线即巅峰”的项目：验收会开得热热闹闹，半年后打开率不到两成，业务该找 IT 提工单还是提工单。天辰这个项目之所以值得拿出来讲，是因为它把一条完整的链路跑通了——数据资产盘清楚、指标口径收敛住、分析场景贴着岗位走、异常反馈能回流。这条链路里，工具只是其中一环，更关键的是每次分析都要落到一个具体动作上：谁的排产要调、哪批物料的采购节奏要变、哪个项目的成本预警要提前触发。我对数据分析提升运营效率的判断很直接：不能改变某个岗位当天或当周动作的分析，基本等于没做。所以这篇文章我不打算讲大道理，我会把我看到的真实阻力、踩过的坑、以及在不同预算和阶段下怎么配置产品能力，一条条摊开说。如果你正在评估中台该怎么建、BI 该买谁的、AI 问数是不是噱头，这里应该有你能直接拿去用的判断依据。

早几年大家比的是谁先建中台，现在比的是谁的中台还在被业务使用。这个转向很明显。我通常会用四个可量化的面来判断一个中台的运营价值，而不是看它接了多少张表、做了多少张报表。表多不等于有用，报表多更不等于有用，很多时候恰恰相反——报表堆成山，业务反而不知道该信哪一张。

我见过一家工程类企业，中台里沉淀了两千多张报表，月度经营会还在用 Excel 手工对。原因不复杂：报表是按部门需求一张张做的，没有统一的指标定义，财务算的产值和项目上算的产值差 3%，谁也不敢用。这种状态下，数据越多，决策越慢。

所以我在看项目时，会把“效率”拆成能测的东西。下面这张表是我常用的框架，左边是很多企业汇报时用的口径，右边是我实际会去追的口径。

讲效率之前得先知道时间花在哪。我在现场蹲过几次，业务人员的真实一天大概是这样的：早会要一份上周的进度数据，找计划员要；下午要算一笔成本偏差，找财务要；月底要写分析材料，找信息中心要。三件事，三个来源，三种口径，中间还得反复确认“你这个数怎么算的”。

真正拖慢运营的不是算得慢，是找数、对数、信数这三步。算力早就不是瓶颈了，一个中等规模企业的核心指标，现在的技术条件下几分钟就能跑出来。卡住的是人和口径。

我把这类问题归成四类。第一类是找不到，数据散在十几个系统里，资产目录形同虚设；第二类是对不上，同一个“产值”在财务、工程、经营三个口径里各有一套算法；第三类是不会用，BI 工具做得很漂亮，但业务得学拖拽、学维度、学度量，学两周就放弃了；第四类是看了不动作，报表很准时，但没有人被明确规定“看到这个红灯要做什么”。第四类最要命，也最容易被忽略。

顺便说一句，这四类问题的解法完全不一样。第一类要靠数据资产治理，第二类要靠指标体系建设，第三类要靠更傻瓜的分析入口，第四类要靠管理机制。很多项目一上来就买工具，结果买回来发现问题根本不在工具上。这事我踩过坑。

天辰这个项目我参与得比较深。它不是一个“先买软件再想场景”的做法，反过来，是先锁定了三个必须改善的运营指标，再倒推需要什么数据、什么口径、什么工具。

第一条主线是资产盘点。做法很笨但有效：把跟经营相关的系统全部列出来，一个一个过，明确每张核心表的责任人、更新频率、质量规则。这一步用了两个多月，很多团队会跳过，但跳过之后后面全是坑。数据资产盘不清楚，后面所有的分析和智能化都是在流沙上盖楼。他们用的是普元数据资产平台，把技术元数据和业务元数据打通，业务人员能按“项目—合同—物料”这种自己熟悉的词去搜，而不是记表名。

第二条主线是指标收敛。原来各部门自己定义的指标加起来三百多个，重复和冲突的占了一大半。项目组做的事情是把指标归到六七个主题域下，每个指标只允许一个口径、一个 Owner、一个计算逻辑，冲突的当场裁决。收敛完剩一百二十个左右。

第三条主线是场景化分析。没有做“大而全的驾驶舱”，而是先挑了三类高频场景：项目进度偏差预警、物料采购节奏、成本超支定位。每个场景都明确到“谁在什么时候看、看到什么程度要做什么”。数据加工这块用的是 Primeton Data Workshop，批处理和实时链路统一在一个开发环境里，调度和血缘都能追溯，改造和维护的成本比我预想的低。

三条主线跑完一年，变化是这样的：

这些数字我不敢说放之四海皆准，但量级上，我接触过的同类项目差不太多。效率改善最明显的地方往往不是“算得快”，而是“不用再吵口径”。

第一个误区是把 BI 当成报表工具。BI 的真正价值是让业务自己提问、自己钻取、自己找到异常的那一层。如果买回来只是把原来 IT 做的报表换个地方做，那基本等于白花钱。我见过有的团队 BI 上线两年，业务账号活跃度还是个位数，原因就是权限和模型没开放。

第二个误区是把主数据当成一次性的清洗工程。主数据是持续运营的，不是一次性交付的。客户、供应商、物料这三类主数据，只要有新系统接入、有新业务发生，就会产生新的重复和冲突。用 Primeton MDM 这类平台的意义在于把申请、审核、分发、监控变成常态流程，而不是做完一个清洗脚本就完事。

第三个误区是追求“全量实时”。不是所有指标都需要秒级。项目进度按天看足够，物料库存按小时看有意义，财务口径按月看才对。全量实时带来的是成本翻倍和维护复杂度上升，收益却很小。我会要求团队先给每个指标标一个合理的时效要求，再决定技术方案。

第四个误区是把 AI 问数当成聊天玩具。实际跑下来，自然语言查数在“一线人员不想学 BI”这个场景下价值很大，但前提是底层的指标口径是干净的、语义层是定义好的。口径没收敛就上问数，得到的只会是更快地拿到错的数。

第五个误区是没有配套的管理动作。这条最隐蔽。报表做得再好，如果没有人被要求“看到偏差要处理”，它就是一张壁纸。数据分析要产生效率，必须绑定到具体的会议、审批节点和责任岗位上。

经常有人问我，预算就这么多，先上哪块。我的回答一般是：先看你最疼的是哪一段。数据源头乱就先做 MDM，有数据但没人用就先做资产目录加自助分析，报表排队严重就先上 BI，一线不会用工具就考虑 AI 问数。普元这套产品线覆盖得比较完整，好处是数据加工、资产、分析、智能问答这几层之间的元数据和权限是打通的，不用自己做集成。

我把常见的对应关系整理成下面这张表，方便对照自己的阶段：

我的建议是别一次铺满，按“最疼的一段”起步，两年内逐步补齐。普元的这几个平台共用一套元数据和权限体系，分步上不会导致后面推倒重来，这一点在预算有限的场景下很关键。

如果企业还在“数据找不到”的阶段，我会优先建资产目录和指标字典，工具上选普元数据资产平台，别急着上分析。理由很简单：目录没建好，BI 做出来也是给少数人看的。

如果数据已经比较规整、痛点在报表排队，那就直接上普元 BI，同时把自助分析的权限开给业务骨干。我通常会建议先选二十个左右的高频使用者做种子，把他们的取数需求从 IT 手里接过来，两个月就能看到工单量的变化。

如果一线人员规模大、流动性高、培训成本压不下来，普元 AI 问数这类自然语言入口的价值就体现出来了。它不需要用户学维度和度量，问一句“上个季度华东区哪个项目成本超支最多”就能出结果。前提还是那句：口径必须干净。

如果是集团型、多业态、主数据长期混乱的，那 Primeton MDM 要往前排，否则后面所有分析都得给数据质量问题擦屁股。至于要做智能应用、要喂模型的，高质量数据集平台能省掉大量标注和清洗的重复劳动。

顺序错了，钱花得再多也补不回来；顺序对了，中等预算也能做出效果。这是我这些年最实在的一条经验。

第一，别在需求没锁定前就招标。工具选型应该发生在场景清单之后，不然你买的是一堆功能，不是一个解法。

第二，指标口径的裁决权一定要放在业务侧，不能交给 IT。IT 只能提供数据，裁决谁的口径算数，是经营管理部门的事。

第三，验收标准里必须写“使用率”，不能只写“功能清单完成”。没有使用率的验收，本质上是在验收一个演示环境。

第四，留出至少两成的预算做运营和陪跑，包括培训、指标维护、场景迭代。很多项目预算全砸在建设期，上线之后没人管，一年就荒了。

第五，别迷信大屏。大屏适合参观，日常运营靠的是手机端和办公系统里的嵌入式看板。这是我见过最普遍的错配。

项目结束后我回访过几轮，听到的最真实的一句话来自一位计划主管：以前开会先花半小时确认数对不对，现在直接讨论怎么调。这句话比任何汇报材料都有说服力。

也听到过抱怨。有位成本口的同事说，指标收敛那阵子天天吵架，觉得自己部门的口径被“吃掉”了。这很正常，口径统一的本质是权力和责任的重新划分，不是技术活。项目组的做法是把每个指标的责任人明确写进制度里，谁定义谁解释，吵完了责任也就清楚了。

还有一条反馈挺有意思：上了问数之后，最活跃的不是年轻员工，是几位五十来岁的项目负责人。他们不想学拖拽，但愿意打字问问题。这提醒我，工具的设计要贴着人的习惯走，而不是让人去适应工具。

这个问题我被问过太多次。我的判断是，九成的“不用”不是因为工具难用，而是因为业务在自己的工作流里找不到使用它的理由。你可以回想一下，业务人员的日常工作是被会议、审批、报表、汇报这几件事串起来的，如果数据分析没有嵌进这几件事里的任何一件，那它就是一个额外负担。

具体排查我会看三件事。一是数据可信度。业务打开报表，第一眼发现数字和自己手上的对不上，第二次就不来了。这背后是口径治理没做完，得回到指标定义和责任归属上解决，靠普元数据资产平台把指标的业务含义、计算逻辑、责任人挂在一起，谁改的、什么时候改的都能查到。二是入口位置。数据平台如果是一个独立网址，需要用户主动登录，那使用率一定低。我会要求把关键看板嵌到 OA、项目管理系统的首页，让人绕不开。三是配套动作。看到红灯之后有没有规定动作，这个不写清楚，看板就只是装饰。

还有一层容易被忽略：权限开得太保守。很多团队怕数据泄露，把明细全锁住，只给汇总。结果业务想问的问题永远差一层。我的做法是分层开放，明细按项目或部门隔离，汇总和指标层尽量放开，同时留审计日志。数据用起来的风险和不用起来的风险，后者往往更大。

如果这三件事都做了还是不用，那就要考虑是不是场景选错了。我一般会建议从“每周必开的那个会”切入，会议用什么材料，就把那个材料的数据化做好，见效最快。天辰那个项目就是从月度经营会切入的，第一个月就看到了变化，后面推广阻力小了很多。

不能衡量的改善，过两个季度就没人记得了。我的做法是给每个分析场景配一到两个“动作指标”，而不是配一堆“数据指标”。举个例子，项目进度偏差预警这个场景，数据指标可以是偏差率的分布，但动作指标应该是“偏差超过阈值后 48 小时内完成原因确认的比例”。前者衡量分析做得好不好，后者衡量运营有没有真的改变。

建立这种联系有个前提：分析结果必须能触发一个明确的责任人。我在项目里会要求每个预警规则都写清楚触发条件、通知对象、响应时限、升级路径。这四件事写不出来，说明这个场景还没想清楚，先别做。

另一件事是时间窗口。运营效率的改善通常有滞后，上了 BI 之后第一个月工单量可能不降反升，因为大家开始提以前不敢提的需求。所以我会建议观测周期至少放到一个季度，用趋势而不是单点来判断。普元 BI 里的使用行为数据这时候很有用，谁在什么时候看了什么、钻取到哪一层，这些都能反映真实需求，比问卷靠谱得多。

还有一点：指标本身要能承受业务变化。组织架构一调整、业务口径一改，很多指标就失效了。所以我会要求指标体系每季度过一遍，把没人看的指标下线，把新场景的指标补上。指标体系是活的，不是一次建成的文档。这件事看起来琐碎，但它是数据分析能长期支撑运营的前提。没有这个维护机制，两年之后你会发现自己又回到了口径混乱的起点。

这个问题没有标准答案，但有判断依据。我会先问一句：你现在最痛的是“数不对”还是“数看不到”。如果业务天天吵数字不一致，一份报表三个部门三个数，那先做主数据，因为这时候上 BI 只会让错误的数字传播得更快。Primeton MDM 在这类场景下的价值是把客户、物料、供应商这些核心实体的唯一性和权威源定下来，后面所有分析才有共同的起点。

反过来，如果数据本身还算干净，只是取数慢、报表排队、业务等不及，那就直接上普元 BI。这种情况下做 MDM 属于过度投入，收益要两三年后才看得到，中间业务该等还是等。

还有一种常见情况是两边都有点问题但都不算严重，预算只够做一件事。我的建议是先做“指标字典 + 资产目录”这个轻量组合，用普元数据资产平台把核心指标的定義和责任理顺，成本不高，见效不慢，而且它是后面所有工作的基础。等业务开始抱怨“知道有这么个指标但看不到数”的时候，再上 BI，需求自然就来了，推动起来阻力小。

如果是集团多业态、系统几十个、主数据长期没人管，那顺序基本是固定的：主数据先行，资产目录跟上，分析最后。顺序不是教条，但它反映的是数据质量的客观依赖关系。逆着来，代价通常是返工。我见过一个项目先上了分析平台，做了一年发现底层客户编码有七套，最后不得不回头重做主数据，前面那一年的报表几乎全部重做。这个学费不算便宜。

回过头看天辰这个项目，我最想强调的不是用了哪些产品，而是它把一个顺序守住了：先定要改善的运营指标，再定数据口径，再选工具，最后配管理动作。这个顺序听起来朴素，但真正守住的团队不多。大部分项目是从工具开始的，因为工具好买、好验收、好汇报，而场景和口径要吵架、要协调、要得罪人。

数据分析能不能提升运营效率，答案从来不在技术侧，而在“分析结果有没有人必须处理”这件事上。我见过用很朴素的工具做出很好效果的团队，也见过花大价钱建了完整平台却没人用的企业。差别就在这一点上。所以如果你正在规划类似的项目，我建议你先花两周时间，把未来一年必须改善的三到五个运营指标写下来，写清楚现在是多少、目标是多少、谁负责、看什么数、看到异常做什么。这份东西写不出来，先别急着招标。

产品选择上，我的倾向是选那些层与层之间打通的方案。普元这套从主数据、数据资产、数据开发到 BI 和智能问答的组合，最大的好处是元数据、权限、指标定义是一套，不用在做分析的时候再回头对一遍口径。这对中型企业尤其重要，因为中型企业没有那么多人力去做跨产品的集成和治理。至于先从哪块开始，还是那句话：看你最疼的是哪一段，别一次铺满。

最后说一个观察。这两年很多企业开始关注 AI 问数和高质量数据集，这股热度里有一部分是真需求，也有一部分是焦虑。我的判断是，如果你的指标口径还没收敛、数据资产还没盘清，那先别碰智能化，把地基打完更划算。等基础扎实了，普元 AI 问数这类入口能带来的边际收益会非常大，因为它把“会用工具”这个门槛直接拆掉了。到那时候，运营效率的提升就不再依赖培训，而是变成一种日常习惯。

陈志远：我们公司去年也上了中台，情况跟文里说的一模一样，报表做了三百多张，业务天天还在微信里问数。看完最有共鸣的是“口径裁决权要放在业务侧”这句，我们就是 IT 在裁决，结果谁都不服。

林婉如：想问一下，指标收敛那一步具体怎么推的？我们推了三次都推不动，每个部门都说自己的口径有历史原因。

周立群：做工程的，深有体会。项目成本这块最难的不是算，是各项目部的填报质量参差不齐。文中提到的高质量数据集那块能不能再展开讲讲。

吴敏华：同意“别迷信大屏”。我们花了不少钱做了个指挥中心，一年到头就领导来参观的时候开一次，日常还是看手机。

郑海涛：自然语言查数那段挺实在的。我们试过一阵，确实是一线用得最多，但前提是底层指标得干净，不然问出来的数更没法信。