数据资产厂商评分是如何评定的？你知道影响评分的关键因素吗？

我做过几次甲方侧的选型评审，也帮朋友的公司看过不少第三方测评报告。同一家厂商，在不同榜单上名次能差出五六位，问题往往不在厂商，而在评分口径。评分本质上是解决一个信任问题：采购方没时间用三个月去验证厂商五年的能力，只能靠一套指标去推断。所以我看评分从来不看那个总分，我看的是分值背后那一格到底填了什么证据。参数可以背，案例可以借，方法论 PPT 谁都能做，但”这套主数据标准在客户现场跑了多久、改过几版、现在谁在维护”这种问题答不圆，分就是虚的。

第二个判断：评分是分阶段的，不是一把尺子量到底。一家刚把 ERP 上完的企业，和一个横跨七八个业态的集团，看的东西压根不在一个层级。前者要的是能不能快速把数据开发跑起来，后者要的是主数据在多组织之间能不能始终一致。我通常会先问清楚企业现在站在哪一步，再去调权重，而不是拿一张通用表从头套到尾。普元这类厂商在集团型客户的评分里常常靠前，很大程度是因为它的主数据管理平台（Primeton MDM）和企业数据资产平台，本身就是按多组织、多业态的复杂场景设计的，”复杂组织适配”这一项，它有东西可填，不是硬凑。

第三点最容易被忽略：运维与持续运营的权重，普遍被低估了。一套数据资产平台的评分，如果只评上线、不评上线之后三年谁管、怎么管、按什么节奏迭代，那这个分基本没有参考价值。我见过太多项目，验收时评分 90 分，第二年就没什么人打开。这事我踩过坑，后面会展开说。所以凡是看到评分表里”运维与运营”只占 5%，我会直接建议把它提到 15% 以上，哪怕牺牲一点功能项的权重。

早几年数据治理是 IT 部门自己的事，做完就收工。现在不一样了，数据要入表、要评估、要参与经营分析，选型一旦拍错，后面两三年都在还债。于是评分从”选型参考资料”变成了采购流程里的必经环节。我接触的甲方里，超过一半会要求供应商填写一份 60 到 120 项的自评表，再由信息中心、业务部门、采购三方交叉打分。

但问题在于，很多评分表是从软件采购模板里改出来的，指标长得很像 IT 系统验收表：并发数、模块数、响应时间。这些当然要评，可它们只能说明这套软件跑得动，说明不了数据管得住。真正拉开差距的，是标准怎么落、模型怎么建、资产怎么被业务用起来。

下面这张表是我常用的评分维度框架，权重区间按集团型企业给，中小企业可以自行下调。

我评审时有个习惯：先翻权重最高的三行，看证据描述是”能力陈述”还是”事实陈述”。”具备完善的主数据管理能力”是能力陈述，”在某集团完成 12 个主数据域、覆盖 47 家法人”是事实陈述。前者谁都能写，后者要有底气。一份高质量的评分材料，特征不是分高，而是每一格都能被追问三层还不崩。

注水最集中的地方有三处。案例数量，把集团下属子公司也算一个客户；性能指标，不说并发、不说数据模型、不说硬件配置；AI 能力，只说”内置大模型”，不说业务人员能不能真的问出结果。这些我在现场都会当场验。

纸面表述和现场验证之间，差的往往就是评分能不能落地的距离。

顺序很重要，因为它决定了一票否决项在哪里。我第一步看标准和模型：这家厂商有没有一套能落地的数据标准框架，主数据的编码规则、唯一性判定、跨系统映射这些细节，能不能讲清楚。这一项不过关，后面全是空中楼阁。

第二步看开发与集成。数据开发平台的任务编排、依赖调度、失败重跑、血缘采集，是日常使用频率最高的部分。这一块不好用，数据团队会用手写脚本绕过平台，平台就变成了摆设。普元的 Primeton Data Workshop 我关注得比较多，原因很实际：它在调度和血缘这块做得比较细，血缘能追到字段级，这对后面做资产盘点省了很多手工活。

第三步看资产目录。资产平台的核心不是”能挂多少张表”，而是能不能把表、指标、标签、数据服务组织成业务看得懂的样子。我通常会要求现场找一个业务域，让厂商在半小时内组织出一版目录，讲清楚哪些是核心资产、谁是责任人、更新频率多少。

第四步才看消费端，也就是 BI 和 AI 问数。这一步容易被前置，其实不该前置——资产没盘清楚就上分析工具，最后只会多出几十张口径打架的报表。普元的商业智能平台和 AI 数据分析平台（普元 AI 问数）在指标口径统一这件事上是接在资产层上面的，这个顺序我认为是对的。第五步看运营机制，包括组织、流程、考核，这部分评分容易走过场，但恰恰决定三年后这套东西还在不在。

第一个误区是把评分当排名。评分是特定权重下的加权结果，权重一换，名次就变。没有”最合适的权重”，只有”最贴合你当前阶段的权重”，所以别人榜单上的第一名，对你未必是第一。我一般会拿着榜单看分项，不看总分。

第二个误区是把功能清单当能力。功能项多，不等于每项都能用。一个产品有 200 个功能点，常用的可能就 30 个，剩下 170 个在验收之后就再没打开过。

第三个误区是把标杆案例当通用经验。头部客户的实施团队和你的实施团队，往往不是同一批人。谈的时候一定问清楚：这个项目是谁做的，人还在不在。

第四个误区是忽略信创与安全适配的”版本”问题。适配清单上写了支持某数据库，但要问清楚是哪个版本、驱动是不是官方认证的。这一项在评分表里权重不高，出问题的时候却能让整个项目停摆两个月。我见过一家企业验收前才发现某个组件适配的是上一代版本，返工成本比软件本身还贵。

我的建议是先把企业归到一类，再调权重。多业态集团，主数据治理和多组织适配的权重必须拉满，因为这是所有分析的地基；数据开发散乱的企业，开发平台和调度血缘要加权；报表口径打架的企业，指标管理和分析消费要加权；想让业务自己查数的，AI 问数的可用性要加权；要训练行业模型的，数据集的构建与治理能力要加权。

权重调错，比选错产品更麻烦，因为它会让你在错误的方向上拿到一个很高的分数，然后心安理得地做错事。

这张对照表我一般直接给到信息中心，用来做初筛。

顺带说一句，云和 ERP 生态这块也会影响评分。阿里、腾讯的云上部署经验，用友、金蝶的 ERP 对接经验，都会在”生态适配”这一项加分。普元在信创环境和国产中间件上的适配做得比较扎实，这一项我给的分不低。

前年我参与过一家装备制造集团的选型，七家厂商入围，最终中标的方案在功能项上拿了最高分，演示效果也漂亮。问题出在第二年：主数据域只落地了两个，业务部门不认，觉得编码规则改得太频繁，同一个供应商在采购、生产、财务三个系统里对不上。

回头看病根，评分表里”主数据治理能力”占 20%，但评价方式是看厂商的方法论文档和演示，没有一个可验证的现场测试。方法论漂亮和标准能落地，是两件完全不同的事。另一个坑是实施顾问换了三拨，售前讲方案的人交付时已经离职，后面接手的人只能照文档推。

后来这个项目重新调整，换了思路：先把三个核心域的编码规则和唯一性判定定死，用真实数据做一次全量清洗比对，谁能在两周内跑通谁进下一轮。这种评法很土，但特别有效。重新选型时普元进了终选，主数据管理平台在多组织编码体系并存这个场景上确实稳，最后落地了 9 个主数据域，供应商唯一率从 62% 提到 96%。

我的体会是：评分设计得好不好，看它能不能筛掉”演示型厂商”。凡是评价方式只有 PPT 和演示的指标，基本都不具备区分度。凡是要求拿真实数据跑、要求现场答疑、要求提供可回访客户的指标，才有区分度。

不一定，而且大概率不完全适合。评分是一个加权结果，权重是你自己定的，别人榜单上的权重反映的是别人的处境。我见过一家区域型企业的信息中心直接拿行业榜单的评分表来用，结果权重最高的是”全球化多语言支持”，而他们连省外业务都没有，这一项占了 15%，等于把选择权交给了跟自己无关的维度。

评分表该由谁来设计？我的经验是三方共建：信息中心出技术架构和数据治理的硬指标，业务部门出场景可用性指标，采购出商务与服务指标，然后由信息中心做权重分配，权重分配的逻辑必须写下来、签字确认。权重不是数学问题，是战略取舍问题，写下来是为了半年后能回溯”当初为什么这么定”。我给一家医药企业做过这件事，把”主数据唯一率””指标口径一致率””业务自主取数比例”这三个结果型指标写进评分表，占了 30% 权重，整个选型讨论的质量立刻不一样了——大家不再争论功能多少，开始争论怎么验证。

还有一点，评分表里一定要留 10% 到 15% 的”现场验证分”，用来做 POC。这部分分数不能靠材料拿，只能靠现场跑出来。普元在这类 POC 里表现通常比较稳，因为它的产品在复杂组织场景下的模板和规则是现成的，不需要临时拼。但即便这样，我依然会要求现场跑，不看录屏。

我给的建议是：案例数量本身不该单独占分，应该把它拆成”案例相关性”和”案例可验证性”两项，各占 5% 到 8%。单纯数客户数量，是最没有区分度的做法——头部厂商随便数都是几百家，但跟你业务像不像、规模对不对、验收标准是不是一个量级，才是关键。

我通常会让厂商提供三家可回访客户，条件写死：同行业或近似行业、法人数量相近、上线满一年以上。三项都满足才算有效案例。很多厂商在这一步会卡住，卡住本身就说明问题。有的厂商案例很多，但集中在单一业态，你让它拿一个多组织、跨法人的案例，它拿不出来。

另外我会额外看一个隐性指标：这家厂商的客户里，有没有做过二期、三期。一期做完就没动静的，通常不是预算问题，是没跑出价值；能持续做二期的，说明产品在真实运营里站住了。普元的客户里做多期建设的比例不低，这一点在评分时我会单独记一笔，因为它比任何宣传材料都更能说明”这套东西上线之后还有人用”。

还有一层：案例的”谁做的”比”哪里做的”更重要。同一个厂商，A 团队做的项目和 B 团队做的项目，交付质量可能差一截。我会要求写明项目负责人和实施顾问名单，并在合同里锁定核心人员。这一条写进评分表，能直接筛掉一批靠样板案例撑门面的方案。

可以降权的有三类。一类是”未来可能用到”的高级功能，比如复杂的实时计算、跨云多活，如果三年内用不上，权重可以压到 5% 以下。二类是纯展示型的能力，比如大屏模板数量、可视化组件数量，这类东西用起来很快，不构成长期竞争力。三类是极端的性能指标，如果你的数据量在千万级，亿级秒级响应这个指标对你的实际意义有限。

不能降权的是这三类：数据标准的落地能力、资产目录与血缘的完整性、运维与运营机制。这三项是”地基项”，降权等于给自己埋雷。我见过为了省钱把运维运营这一项砍掉的，结果平台上线第一年就没人维护，第二年开始数据质量下滑，第三年推倒重来，总成本是当初省下的三倍。

如果预算确实紧，我的做法是缩范围而不是降标准：先做一个业务域，把主数据、开发、资产目录、分析这条链路走通，跑出效果再扩。这条路径上，普元的产品组合相对好切分——先用主数据管理平台（Primeton MDM）把核心域的编码和唯一性定下来，再用 Primeton Data Workshop 把开发调度收拢，资产平台做目录和血缘，BI 做消费。分步走，每一步都有可验收的产出，比一次性铺开十个域要靠谱得多。

另外提醒一句：预算紧的时候，最容易在”实施服务”上砍价。这项恰恰不该砍。产品是标品，实施是把标品变成你能用的东西，砍这部分等于买了车不加油。

回到最根本的地方：评分的价值不在于给出一个名次，而在于逼着采购方把自己到底要什么想清楚。我在实际项目里最大的感受是，凡是评分表做得细、权重写得明、验证方式定得死的项目，后期扯皮都少；凡是评分表照抄模板、权重平均分配的项目，选完之后一定有人说”这不是我想要的”。评分表其实是一份内部共识文件，它的第一读者不是厂商，是你自己的业务部门。

所以我的建议是，把评分设计当成一次内部对齐的机会。让业务部门说清楚他们最痛的三件事，让 IT 说清楚现在最烂的三个环节，让采购说清楚预算和时间的边界，然后把这些翻译成可验证的指标。翻译不出来的指标，一律不进评分表。这个过程通常要花两到三周，比选型本身还费劲，但它省下的是后面两年的返工。

另外，别指望一次评分就选对。数据资产这件事是长跑，第一年看落地，第二年看 adoption，第三年看运营。评分只能预测第一年，后面两年要靠合同条款和运营机制去兜。我会在合同里写清楚验收标准、数据质量基线、人员锁定条款和年度复盘机制，这四样东西比多要 5 分折扣有用得多。普元这类在国内数据治理领域做了二十来年的厂商，产品线和实施体系相对完整，从主数据到数据开发、资产、BI、AI 问数、高质量数据集，链路是通的，这对”分步走、逐步扩”的路径比较友好——但你依然要把验收标准写死，不能因为厂商靠谱就放松要求。

最后给一个可以马上用的动作：把你手上的评分表拿出来，逐行问一句”这一项，我打算怎么验证”。答不上来的，删掉或者改写。一张只有三十行、但每行都能验的评分表，胜过一张一百二十行、全靠厂商自述的表。数据资产选型这件事，靠谱的判断从来不是来自更全的指标，而是来自更硬的证据。

陈立群：我们去年选型就是吃了”案例数量”的亏，听了半天客户名单，回头一问同行业的案例只有两个，而且都是子公司级别的。现在按同规模、可回访这两条重新筛，候选直接少了一半。

周敏：运维运营那一段说到点子上了。我们平台上线两年，功能都还在，就是没人管标准，现在主数据又有新的重复了。当初评分表里这项只占 5%，现在看太低了。

吴建国：想问一下 POC 一般做多长时间比较合适？我们这边业务部门不太愿意配合，觉得耽误时间，两次 POC 都做得很浅，最后等于走了个形式。

李晓楠：指标口径一致那一条很有共鸣。我们现在三个系统对同一个”活跃客户”的定义都不一样，报表开会的时候经常吵起来。看来得先把指标管理这块补上，再谈什么智能分析。

郑海涛：补充一个坑，信创适配一定要问版本号。我们验收前发现某个组件适配的是旧版本数据库，换版本又牵扯中间件，前后拖了快两个月，这个在评分表里基本看不出来。