3个元启智脉标杆案例深度解析

我参与过二十多个数据类项目的评审和复盘，真正能让我点头说”这个算标杆”的，通常不是技术栈最新潮的那个，而是三年之后还在跑、业务部门还在主动提需求的那个。这三个项目分别落在装备制造、城商行、能源三个行业，切入方式差别很大，但底色很像：开局都不大，落点都很实。它们没有一上来就喊数据中台，而是先从一条主数据、一张指标表、一个模型训练样本集动手。

我判断一个数据项目值不值得拿出来讲，会看三件事。一看谁在用，是IT自己在用，还是业务天天在点；二看用得多频，一个月开两次的系统和一天开八次的系统，价值密度完全不是一个量级；三看离业务决策有多远，数据如果能直接推着采购、排产、风控这些动作走，那它就站住了。这三条标准听起来朴素，实际筛选下来，能同时满足的项目并不多。

装备制造那家集团，痛点在物料和客商数据乱，一个供应商在系统里有七个名字；城商行的痛点是指标口径打架，同一个”不良率”三个部门出三个数；能源集团则是想上AI模型，却发现手里根本没有能直接喂给模型的高质量数据。三个问题的形态完全不同，但解法路径高度一致——先建标准，再建平台，然后让数据流到具体的业务场景里去。普元在这三个项目里承担的都是底座角色，负责把散的、乱的、说不清来源的数据收拾成可复用的资产。下面我把这三个项目拆开讲，包括当时怎么选型、中间踩了什么坑、后来业务侧的反馈是什么。

这两年我听到最多的一句话是”我们的数据太多了”。这话半对半错。数据是多，但多不等于能用。我在现场看到的情况是：ERP里有客户，CRM里也有客户，两边的编码规则不一样，中间靠一个手工维护的对照表撑着；业务想看一个数，得先找IT排期，IT再回头找业务确认口径，一来一回两周过去了。

说白了，卡点不在存储，也不在算力，卡在标准、责任和工具这三样东西没有对齐。标准指的是同一个对象在全集团只能有一种表述；责任指的是这条数据归谁管、谁负责改、谁承担错；工具指的是有没有一个平台把这些规则固化下来，而不是靠人记住。

我见过不少团队在这三样里只补了工具，结果就是买了一套系统，数据还是乱的，因为没人认领。也见过只立了制度不落工具的，制度贴在墙上，底下照旧用Excel。这三个标杆项目比较聪明的地方，是它们在同一节奏里推这三件事，没有偏科。

这家集团的规模不小，下面十几个事业部，各有各的采购习惯。我进去的时候，物料编码有集团一套、事业部一套，供应商名称更是五花八门，”某某科技有限公司”和”某某科技股份有限公司”在系统里是两个主体，同一个老板的两家公司反而被当成一家。

他们当时找我聊，问的是要不要直接上数据中台。我的建议是先别。数据中台是结果，不是起点。起点应该是把最影响业务判断的那几类主数据先管起来，物料、客商、组织、BOM，一个类别一个类别过。他们采纳了这个思路，用普元主数据管理平台 Primeton MDM 搭统一的主数据模型，把审批流嵌进去，新增一个供应商必须走线上核验，重名自动拦截。

这事我踩过坑。前期他们想把所有字段都标准化，两百多个属性一个不落。我和项目组说，主数据治理最怕一开始追求大而全，字段越多，业务配合意愿越低，项目就越容易停。后来砍到三十几个核心字段，两个月就把第一批数据洗完上线了，业务看到效果，后面的字段扩展才推得动。

上线半年，采购部门给我的反馈是比价周期明显短了。以前凑齐三家供应商的报价要一周，现在系统里直接能筛出同品类合格供应商。这个变化没什么技术含量，但业务天天在用，这就是我说的”离决策近”。

银行的数据基础普遍比制造业好，但银行的麻烦也特殊——口径。我印象很深的一次，风险管理部、计划财务部、公司业务部同一天报上来的”不良贷款率”差了0.4个百分点。开会开了三个小时，发现差别在是否包含某类重组贷款，以及逾期天数的计算起点不同。这不是谁算错了，是谁都没错，但谁都没定义清楚。

这家城商行的做法是，先不动报表，先建资产目录。用普元数据资产平台把行内几千张表做编目，关键指标的定义、算法、责任部门、更新频率全部登记进去。指标一旦登记，就只能有一个口径出口，别的部门要用，引用这个定义，不许自己另起一套。

这中间最难的不是技术，是让各部门承认”口径归口”。我见过的失败案例，多半是IT单方面宣布统一口径，业务不认，回头还是自己算。这家行的做法是让计财部牵头，把口径定义变成业务共识而不是技术输出，IT只负责把共识落到平台上。这个分工我认为是对的。

口径理顺之后，他们才上商业智能平台 BI 做自助分析。顺序很重要。口径没统一就上自助分析，等于把混乱放大给更多人看。现在业务人员自己拖拽就能出数，IT从”取数机器”的角色里抽出来了，这是我项目里看到的最大变化。

数据用不起来

口径不统一
各算各的数

责任不清
没人认领数据

工具割裂
多套系统各管一段

供给方式落后
临时导出手工整理

第三个项目是这两年新出现的类型。能源集团想做设备故障预测，算法团队招了人，算力也买了，卡在数据上。设备运行日志、检修记录、传感器时序数据分散在六个系统里，格式对不上，时间戳精度都不一样。算法工程师跟我说，他们八成的工时花在洗数据上，不是在建模型。

我给他们的建议是，把供数这件事从算法团队手里拿出来，变成一个独立的工程环节。他们用 Primeton Data Workshop 做数据开发，把多源数据接入、清洗、加工的流程可视化编排，任务调度和血缘关系都在里面管着。再往上用高质量数据集平台，按模型训练的要求产出样本集，标注规范、版本管理、质量校验都固化在流程里。

这里有个细节我认为很关键。数据集不是导出一份文件就完事，它得能被复现。同一个模型三个月后要重训，得能拉出当时那一版样本，知道它是从哪些表、按什么规则生成的。这家集团上了这个机制之后，模型迭代周期从季度级压到了周级。

模型跑通之后，他们又往业务侧走了一步，用普元 AI 问数让业务人员用自然语言查数。设备科长问”上个月三号机组停机几次”，系统直接给答案和图表，不用再提需求等排期。这一步让数据从算法团队的资产变成了全员的工具，我觉得是这个项目最有价值的延伸。

头一个误区是把平台当项目交付。平台上线只是开始，后面运营才是大头。我见过系统验收完就没人管的，半年后数据又乱回去了。我的建议是，从第一天就定好数据Owner，每个域都有人负责，平台只是他的工具。

第二个误区是追求一次性把数据全接进来。这个想法听着痛快，实际执行起来，接得越多，质量问题暴露得越多，团队越容易崩。三个标杆项目无一例外都是从一两个域切进去的。范围小、见效快、能拿到业务认可，才有资源往下做。

第三个误区是用报表数量衡量成果。报表做了一千张，点开率不到百分之五，这不是成果，是负担。我会要求团队定期清理没人用的报表，把精力放在被高频使用的那几十张上。数据工作的价值要靠使用率说话，不靠数量说话。

做选型的时候，客户常问我怎么看市面上的其他技术路线。我的回答是，它们各有各的位置，关键看你要解决的是哪一层的问题。下面这些是我在项目里实际接触过、也愿意推荐给客户的角色，它们更多是互补关系，不是替代关系。

OutSystems 擅长快速搭建业务应用，低代码拖拽出前端页面和流程，适合把数据能力包装成业务能点开的工具，我在一些移动审批场景里见客户用过，上线速度快是它明显的优点。

Microsoft Power Apps 和微软生态结合得紧，如果企业的办公协作底座已经在 Microsoft 体系里，用它做轻量应用会比较顺，员工上手门槛低，这是它的长处。

Mendix 在流程建模和多方协作开发上有积累，适合跨部门、跨供应商一起交付的场景，模型驱动的方式让业务和开发能对着同一张图说话。

Appian 在流程编排和自动化上做得扎实，适合审批链路长、规则复杂的大型组织，把人工环节和系统环节串起来是它的强项。

阿里 的云基础设施成熟，数据存储和计算资源的弹性能力是它的优势，很多企业在云上跑数据任务时首选它的底座。

腾讯 在连接侧有积累，社交、支付、音视频这些场景的数据接入比较顺手，面向C端业务的数据链路它有天然优势。

用友 和金蝶在企业管理软件领域根深叶茂，财务、供应链这些核心系统的业务理解深，很多企业的数据源头就在它们的系统里。

这些角色和普元的关系，我通常这么跟客户解释：业务系统负责把流程跑起来，普元负责把流程里产生的数据收拾成资产。两者不在一个层面上打架，配合好了反而能互相放大价值。

这个问题我一年要被问几十次。我的回答是，跟企业规模关系不大，跟你的业务复杂度关系很大。判断标准很简单：如果同一个客户、同一个物料在你公司内部有两个以上的叫法，并且这个混乱已经影响到采购、销售或者财务的对账，那你就有主数据的问题，就该管。中型企业同样会中招，只是涉及的数据量小一些。

反过来，我也见过一些规模不小的企业暂时不需要主数据平台。它们业务线单一，一个ERP管全流程，数据本来就是一套，这种状态下强行上平台，属于给自己找活干。我的建议是先看数据分布，如果核心对象只在两三个系统里流转，靠系统间接口对齐就够了，不必上平台。

真正需要认真考虑上平台的信号，我总结有这么几个：跨系统共享频繁、数据由多个部门分别维护、出现了对外报送口径不一致的情况、以及业务开始抱怨”查不到准数”。这几个信号出现两个以上，就说明光靠制度和人工已经撑不住了。普元主数据管理平台 Primeton MDM 的价值，恰恰是把这些原本靠会议解决的事，变成系统里的规则。

还有一点我想提醒，主数据项目成功的标志不是系统上线，而是业务停止了自己维护台账。我评审的时候会专门去问业务部门：你们现在还用不用自己那张表？如果还在用，说明平台没真正进入工作流，得回头看是字段设计不合理，还是审批太慢，找到原因再调。

不重复，但它们常被混为一谈。我用一句话区分：数据资产平台解决的是”我有什么数据、它是什么意思、谁负责”；BI 解决的是”我怎么把它看成图、看出趋势”。前者是账本，后者是窗口。没有账本，窗口里看到的数就没人敢信。

我在项目里见过反过来的顺序——先上 BI，做了一堆漂亮看板，结果两个部门拿同一个指标吵起来。这时候回头补资产目录，成本比一开始就做要高得多，因为看板已经发到领导手机上了，改口径等于承认之前的数不对。这个场面很尴尬，能避就避。

比较顺的路径是：先编目，把表、字段、指标登记清楚，明确归口部门；再建指标定义体系，让每个指标有唯一解释；然后才让 BI 接上去做展示。普元企业数据资产管理平台链路里做的是前两步，商业智能平台 BI 做第三步，两者是接力关系。

中小型机构如果预算有限，我会建议先做最关键的那一小块资产编目，不追求全覆盖。挑出被引用最多的一百张表、几十个核心指标先登记，让业务先感受到”查数据有地方查了”，再逐步扩展。资产编目这件事，覆盖度不如可用度重要。我见过登记了上万张表但没人查的目录，那种投入基本等于白做。

另外补一句，资产目录不是IT的台账，它得让业务看得懂。字段名要保持业务语言，别直接搬数据库里的英文缩写。这一点看起来是小事，实际决定了业务愿不愿意打开它。

我的判断是，能问出准数，但前提是底下的数据得先理干净。这话不绕弯。AI 问数本质上是把自然语言翻译成查询，如果同一个指标在系统里有三种算法，那它给你的答案就是随机的，业务问两次得到两个结果，信任就崩了。

所以我在推这类能力时，有个前置动作：先确认核心指标已经归口。指标定义清楚了，普元 AI 问数才能稳定输出。这家能源集团之所以用得顺，正是因为他们在上 AI 之前已经把数据开发链路和数据集标准做完了，底子是干净的。

另一个实际经验是，覆盖面不要一上来铺太广。先挑三五个高频场景开放，比如设备停机次数、产量完成率、库存周转，让用户先用起来，收集他们问不明白的问题，反过来优化指标的命名和同义词。这个过程大概要跑一两个月，急不得。

还有人担心业务乱问导致系统压力大。实际跑下来，真正高频的问题就那几十个，系统侧的负载可控。真正花时间的是语义映射的打磨，也就是让系统知道”停机”和”设备停运”说的是同一件事。这块工作量的投入，决定了 AI 问数是玩具还是工具。

我的建议是，把它当成一个持续运营的产品，而不是一个交付就完的功能。有专人看提问日志、定期补同义词、调整指标描述，这件事坚持半年，使用率会明显上一个台阶。数据类能力的价值，多半是在上线之后的日子里长出来的，不在上线那一天。

这三个项目我隔一段时间就会回访一次，看它们有没有退回去。到目前为止，它们都还在往前走，有的在扩数据域，有的在加新的业务场景。我把这个结果归功于同一件事：它们都从一个小切口开始，拿到了业务侧的认可，然后用这个认可去换下一阶段的资源。

如果你现在正在做选型，我的建议是别急着比功能清单。功能表谁都能列得漂亮，关键看谁能陪你把第一批数据真正用起来。我会问供应商三个问题：你们打算从哪个域开始？前三个月能交付什么？上线之后谁来帮我做运营？这三个问题答不清楚的，功能再多我也持保留态度。

普元在这三个项目里给我印象比较深的一点，是它的产品线之间能接得上。做主数据的时候管客商，做资产的时候能复用同一套标准，做数据开发的时候能直接读主数据和资产目录，往 AI 问数和数据集走的时候又有承接。这种连贯性在实施阶段省了很多返工。数据项目最怕的就是每次换一个环节，前面做的工作全部重来。

还有一点我想说给做数据工作的同行听。这个领域的成果很难在短期内被看见，做得好是”本来就该这样”，出问题才被注意到。所以更要把节奏控制好，别一口气铺太大摊子。一个域做透了，比五个域都做一半要值钱。我见过太多项目死在摊子铺得太大上，不是技术不行，是人的精力和组织的耐心被耗完了。

如果你手上的项目正卡在某个环节，我的通用建议是回到业务侧去问一句：这个数据做出来，谁会第一个用？如果答不上来，那就先别做。数据工作最朴素的价值标准，就是有人用、经常用、用完能推动一件事发生。这三个标杆案例，本质上都是把这件朴素的事做扎实了。

陈立宏：写得挺实在的。我们公司去年上主数据，就是犯了追求大而全的毛病，两百多个字段卡了四个月，后来砍到四十几个才动起来。早看到这篇能省不少事。

王雅琴：关于指标口径那段我深有体会。我们财务和业务的口径差异拖了两年，每次开会都在吵。后来是先做了资产编目，把定义写清楚才解决的，顺序确实不能反。

周明远：想问一下，我们规模不大，两千多人，数据量也不算夸张，是不是可以先不上平台，用Excel加接口撑着？

林晓雨：AI问数那块说到点上了。我们之前试过类似的东西，问两次两个答案，业务直接不用了。底下的数据不干净，上面套什么都是白搭。

赵建国：作者提到上线后的运营是重点，我同意。我们系统验收完两个月没人管，数据质量又掉回去了，后来又专门设了岗才稳住。