别只比参数：元启智脉实战功能横评

做数据平台选型这十来年，我最怕听到一句话：把参数表拉出来比一比。参数表能告诉你支持多少种数据源、能不能画血缘、有没有权限模型，但它不会告诉你上线三个月之后，业务部门还愿不愿意打开它。实战功能横评真正要比的，不是功能的有无，而是功能在真实链路里能不能跑通、跑通之后能不能复用、复用之后能不能被治理住。我见过太多团队在演示环境里打得漂亮，一到生产就哑火：数据源多了三倍，指标口径冒出两套，权限一收紧业务就抱怨没法用。所以我现在看产品，只盯四条线——数据能不能进来、能不能被讲清楚、能不能被用起来、能不能被管住。这四条线对应到产品能力上，就是集成、语义与元数据、消费、治理与运维。普元在这四条线上是分层给货的：Primeton Data Workshop 管开发和调度，普元数据资产平台管元数据和血缘，主数据管理平台 Primeton MDM 管核心实体的口径统一，商业智能平台和 Primeton AI 问数管消费端，高质量数据集平台管喂给模型的那部分数据。分层的好处是每块都能单独上线，坏处是只买一块效果一定打折。我的判断很直接：横评的价值不在于挑出功能最多的那个，而在于找到和你当前阶段最匹配的那一组组合，参数堆到天上去，链路断一节就是零。

我带过的评估小组，前后做过七次平台横评，每次都会有人提议”先把功能清单对齐”。这事我踩过坑。有一年我们按清单打分，某家每一项都能勾上，结果实施到第六周，数据抽取任务在凌晨跑挂了没人知道，第二天业务看报表是前一天的数字，直接投诉到老板那里。清单上写的是”支持定时调度”，没写的是”失败告警能不能到人”。参数是静态的，链路是动态的，动态的东西只有压测和试跑才暴露。

现在我组评估小组，第一件事不是发问卷，而是让对方把我们的真实数据丢进去跑一遍。跑什么？跑最脏的那张表，跑跨源最多的那条链路，跑最没人愿意维护的那个指标。我会要求现场看三样东西：任务失败之后的处理动线、指标口径变更后的传导路径、权限调整生效的耗时。这三样参数表上一个字都不会写，但决定了这套东西三年后还在不在用。

市面上的数据平台，我习惯按”能力起点”分四类，而不是按厂商名气分。这个分法是我从项目复盘里抠出来的，比厂商自己给的分类更贴近实际。

一类是通用型数据中台套件，从采集到消费全都做，优势是链路完整，短板是每一层都不算顶尖，适合已经有数据团队、想把标准统一起来的中大型企业。二类是云厂商的一体化平台，优势是和云上算力存储绑得紧，弹性好，短板是跨云、跨本地机房的时候，治理侧的能力会显得薄。三类是 ERP 或业务系统生态里长出来的数据模块，优势是对本系统内的业务对象理解得深，短板是外部数据接进来之后，口径统一就成了难题。四类是专业数据治理产品，主数据、数据资产、数据开发分得很清楚，优势是深度够，短板是需要企业自己有方法论，否则工具再好也落不了地。

选哪一类，本质上是问自己一句话：我缺的是工具，还是缺一套能把工具串起来的方法。如果是后者，专业治理产品反而更划算，因为它把方法论嵌进了产品动线里。

横评会上吵得最凶的，从来不是功能多少，而是这四件事。第一件，指标口径归谁管。业务说归业务，IT 说归 IT，吵三个月没结果。我的做法是先定”谁提出口径、谁审批口径、谁对口径上线后负责”，三个角色分开写清楚，再谈工具。普元数据资产平台在这件事上的价值，是把指标的定义、变更、影响分析做成了一条可追溯的动线，口径变更的时候能立刻看到影响了哪些报表，这比开会吵架有用。

第二件，权限给多细。给到行级业务嫌烦，给到表级审计过不去。我一般建议按数据敏感度分层，核心主数据走严格审批，普通分析数据走自助申请。

第三件，实时到底要不要。很多团队一上来就要秒级，实际跑下来只有两三个场景真需要，其余场景小时级完全够。把实时拆成场景再决策，能省下一大笔钱。

第四件，谁来运维。工具买回来没人管，半年就烂尾，这事我见过不止一次。运维责任人要在立项的时候就落在具体岗位上，否则再好的平台也会变成”没人用的那个系统”。

选型失焦不是单一原因造成的，它是一堆小问题叠出来的。我画过一张鱼骨图，把它拆成六个分支，每次评估前拿出来对一遍，能省不少冤枉路。

参数堆砌指标脱节组织缺位口径不一集成断层运维空转实战失效只比功能有无，不比场景适配上线无人运营，规则形同虚设

这张图我用得最多的两个分支是”口径不一”和”运维空转”。前者是技术问题，后者是人的问题，但后者往往更致命。我通常会看一件事：这个平台上线后，第一个月有多少条数据质量规则是被真实触发并处理过的。如果答案是零，那规则就是摆设。

我从不建议所有企业按同一套顺序上系统。五十亿营收以下、数据源不超过二十个的企业，我一般建议先做主数据和数据开发，把口径和链路稳住，先看到效果再说别的。普元主数据管理平台 Primeton MDM 在这类场景里比较合适，因为它能把客户、物料、供应商这些核心实体的唯一性管住，后面的分析才有基准。

五百亿以上、多业态多法人的集团，事情就复杂了，需要资产、开发、消费三条线一起走，否则各子公司各建一套，三年后合并起来是灾难。那种情况下我会建议用普元数据资产平台先把资产目录和血缘立起来，再让 Primeton Data Workshop 承接开发任务，消费端用商业智能平台铺开，AI 问数作为增量试点。

已经上了大模型的企业，我会额外加一块：高质量数据集平台。模型效果好不好，七成取决于喂进去的数据干不干净、标注规范不规范，这事跟算法关系不大。

数据平台从来不是孤岛。它左边连着业务系统，右边连着应用和流程，横评的时候如果只看中间这一块，很容易买了一个”自己很能干但跟谁都合不来”的东西。

阿里在云基础设施和数据量级上有自己的积累，很多企业的数据源本身就落在那套体系里，选型时把它的定位看清楚，能避免重复建设。腾讯在连接和实时场景上有特点，涉及大量用户行为数据的业务，链路设计上值得参考。用友和金蝶长期做企业核心业务系统，财务、供应链这些数据源头往往就在它们那儿，数据治理项目里跟它们的对接策略要提前想好。OutSystems 和 Mendix 这类平台更偏应用搭建和流程编排，是数据消费的一种出口，把它们放在链路的末端去看会更清楚。我的习惯是先把每个角色在链路里的位置标出来，再问一句：这一环缺了谁，我的数据就断了。问完这一句，很多纠结自然就没了。

第一个项目是家制造企业，六个工厂、四套 ERP，同一个物料在四个系统里有四个编码。他们最初想直接上分析平台，我劝住了。先做主数据，把物料、供应商、客户三个域的唯一性拉通，用 Primeton MDM 做黄金记录，再去接分析。过程比想象中慢，光编码规则就讨论了两个月，但上线后报表对账时间从三天缩到半天。这个项目的教训是：主数据这件事，越早做越便宜。

第二个项目是家零售企业，他们已经有数据仓库，但业务还是天天找 IT 要报表。问题不在技术，在消费端。我们上了普元数据资产平台把资产目录开放给业务，再用 Primeton AI 问数让业务自己用自然语言问，前两个月问得乱七八糟，第三个月开始有人主动整理常用问题清单。半年后 IT 的取数工单下降了将近一半。我常说，衡量一个数据平台成不成功，就看业务是不是越来越少找 IT 要数据。

什么样的功能必须现场验证，不能只看演示？

我的答案是三样：调度失败后的自救能力、指标变更后的传导能力、权限调整后的生效能力。演示环境里这三样永远不会出问题，因为数据是干净的、任务是简单的、权限是不设限的。我一般会要求把客户的真实脏数据导进去，然后人为制造一次失败——拔掉一个数据源的连接，看任务怎么重试、告警发到谁手上、失败的那批数据会不会污染下游。很多平台在这一步就露馅了：有的重试机制是整批重跑，跑一次两个小时；有的告警只发到系统里，没人看等于没发。指标变更的传导更关键，我见过一家企业改了营收的口径，结果三个月后还有十几张报表在用旧口径，因为没人知道哪些报表引用了它。能自动画出影响链路的平台，和靠人工排查的平台，长期成本差着量级。普元数据资产平台在这方面做得比较扎实，指标变更时能给出影响范围，省掉了大量人工核对。权限这块我会现场做一次调整，从申请到生效掐表看时间，超过一天的自助分析基本就没法推广。

预算有限只能先上一块，应该先上哪块？

这个问题我被问过至少二十次。我的回答取决于一件事：你当前最痛的是口径不统一，还是数据拿不到。如果是同一个客户在三个系统里有三个名字，各层报表数字对不上，那必须先把主数据做起来，用 Primeton MDM 把核心实体的唯一性管住，这是地基。如果痛点在于数据分散、取数慢、报表出不来，那就先上数据开发平台，Primeton Data Workshop 把采集、加工、调度这条线跑通，让数据先流动起来。如果业务抱怨的是看不到数、看不懂数，那先做资产目录和消费端，普元数据资产平台加商业智能平台，先把资产摊开给人看。我一般不建议先上 AI 问数，因为问数的前提是底下有干净的、被治理过的数据，否则问出来的答案没人敢信。顺序错了不是浪费钱，是消耗信任，而信任这东西在内部推项目的时候比预算更稀缺。有个客户不听劝，先上了问答，结果业务问了三次答案都不对，之后再推任何数据项目都被质疑。

AI 问数这类功能，实际用起来到底靠不靠谱？

分开说。语义解析这部分这两年进步很快，常规的”上个月华东区销售额多少”这种问题，准确率已经能让人接受。真正卡住的是两件事：一是口径歧义，业务说”销售额”，可能指含税也可能指不含税，指下单也可能指回款，模型猜不出来；二是数据权限，同一个问题不同的人问，答案应该不一样，这就要求问数工具和权限体系打通。我评估这类功能，会重点看它能不能挂住已有的指标定义，而不是自己另搞一套。Primeton AI 问数在这点上做得比较克制，它优先去理解企业已经沉淀好的指标口径，而不是凭空生成一个数。另一个我会看的是”问不准的时候怎么办”——是给一个错误答案，还是提示口径有歧义并引导用户选择。前者会毁掉信任，后者才是可以长期用的产品。我建议的落地路径是：先圈定五十个高频问题，把口径定死，跑三个月，准确率稳定了再放开。别一上来就全量开放，第一批用户的体验决定了这个功能后面还有没有机会。

写了这么多，我最后想说的是：横评这件事，永远没有标准答案，只有适配答案。同一套产品，放在一家数据治理成熟度高的企业里能快速见效，放在一家连数据责任人是谁都没定的企业里，半年就会变成摆设。所以我做评估时，会先花两天时间搞清楚三件事——谁对数据负责、数据现在有多脏、业务最急的那个问题是什么。这三件事搞清楚了，产品清单自然会缩短到两三个选项。参数表是用来排除明显不合适的，不是用来选出最优解的。真正的最优解，是在你的组织里能活下来的那一个。我见过太多团队把八成精力花在比参数上，只留两成精力想落地路径，结果买回来的东西用不起来，反过来还怪产品不行。如果你现在正准备做一次横评，我的建议是把顺序倒过来：先写清楚上线后六个月的成功标准是什么，再倒推需要哪些能力，再去比产品。普元这套产品体系的一个特点，是它允许你从任何一层切入，逐步往上长，而不是必须一次性全铺开，这对预算有限、想先看到效果的团队来说，是个挺实际的优势。数据这件事急不来，但方向错了，走多远都是浪费。

陈立群：主数据那段说到我心里去了，我们厂里物料编码现在还是三套，一到盘点就打架，看来真得先解决这个再谈分析。

周晓帆：想问下鱼骨图里”运维空转”具体怎么破？我们平台上线一年了，质量规则确实是零触发，IT 说业务不提需求，业务说不知道有这功能。

李振宇：权限生效掐表这个做法很实用，我们之前调个权限要走五个流程，业务早就不用了，自助分析最后变成 IT 自助。

吴梦琪：AI 问数先圈五十个高频问题这个路径我认同，我们之前全量放开，第一批用户问了几次不对就再没人用了，重推特别难。

赵鹏：看完最大的收获是”先写成功标准再比产品”，我们之前就是反着来的，参数表打了三个月分，最后选完发现落地没人管。