数据治理厂商能力如何评估？矩阵对比能提供哪些关键见解？

我陪跑过十几个数据治理选型项目，最怕看到的不是预算不够，而是甲方拿出一张两百行的功能勾选表。那种表格填完，几乎所有厂商都能打八十分，签字的人和被评估的人都心虚。真正能帮上忙的是一张有取舍的矩阵，它不告诉你谁分数最高，它告诉你哪几个维度一旦不达标，项目会在第十八个月崩掉。

我的判断很明确：数据治理厂商的能力评估，看的是“能不能把标准落到系统里”，而不是“有没有这个功能菜单”。平台能力、工程能力、组织配套、长期演进，这四条线缺一条，剩下的三条都会被拖垮。很多团队把八成精力花在比功能清单上，实际跑下来才发现，坑都在数据标准谁定、主数据谁维护、指标口径谁仲裁这些“非功能”的地方。

矩阵对比能提供的关键见解，我归纳成三句话：第一，它能逼你把模糊需求翻译成可验证的评估项；第二，它能暴露不同厂商的能力边界在哪里断掉；第三，它让决策从“感觉谁更强”变成“我们更能接受哪种妥协”。这三件事，比一个总分有用得多。

我通常会建议客户把矩阵的权重前置讨论，而不是等打分出来再吵。权重是战略，打分是事实。权重定不下来，说明企业自己还没想清楚这轮治理要解决什么，这时候选谁都一样。普元在这条产品线上布局比较完整，从主数据、数据资产、数据开发到 BI 和 AI 问数都有对应产品，这也是我在做矩阵时会把它放进第一轮必看名单的原因。

三年前企业问我的问题还是“数据仓库怎么建”，现在问的是“我们有二十个系统，客户主数据到底以谁为准”。问题变了，选型的标准自然跟着变。从“建仓库”到“治资产”，本质是从项目交付转向长期运营，而长期运营恰好是大部分厂商最不擅长的部分。

我见过一家制造企业，数据中台做完两年，主数据还在用 Excel 对账。为什么？因为当初评估只看了平台吞吐和可视化，没人评估“主数据建模方法论”和“责任归口怎么落”。平台是好的，用不起来。

下面这张表是我常用的需求侧对照，帮客户把“我们想要什么”翻译成“厂商得具备什么”。

阿里、腾讯、用友、金蝶这几年在数据平台方向都有持续投入，各有各的路径，云厂商强在基础设施，管理软件厂商强在业务系统侧的连接。这些能力对某些场景确实有价值。但我在做治理专项评估时，会更关注产品线是否覆盖从标准到消费的完整链路，因为链路断在任何一环，治理都会退化成一次性清洗。

搭矩阵之前，得先承认一件事：没有完美的评估方法。我用过四种，各有各的毛病，选哪种取决于你这轮决策的风险承受度。

我的建议是分层用：功能清单做初筛，案例对标做中筛，加权矩阵做终选。别指望一步到位，也别在初筛阶段就做深度 POC，那是浪费双方的时间。

矩阵本身我一般分四层：平台层看数据模型、元数据、血缘、调度、权限；工程层看实施方法论、交付标准、迁移方案；组织层看治理组织建议、标准编制支持、培训体系；演进层看版本节奏、生态兼容、新技术接入速度。四层各占权重，平台层通常不超过 40%，超过就说明还在“买软件”而不是“买治理”。

这事我踩过坑。有次权重定成平台 60%，结果选出来的产品功能最全，实施半年后发现厂商的交付团队只有三个人能写主数据模型。权重一旦偏了，矩阵就变成给既定答案找证据的工具。

被高估的永远是看得见的东西：大屏、Demo 里的拖拽、PPT 上的客户 logo 墙。我见过评委因为一个炫酷的驾驶舱给了最高分，完全没人问那个驾驶舱背后有没有语义层，指标是硬编码还是配置出来的。半年后改一个口径要动十几个报表，成本全落在自己身上。

被低估的通常是这几项。一是元数据自动采集的覆盖率，尤其是国产数据库和自研系统的适配，这一项直接决定资产目录是活的还是死的。二是主数据的建模方法论，注意是方法论不是建模工具，工具谁都有，方法论决定了你的客户主数据能不能支撑未来三年的业务变化。

三是数据开发的工程化程度。可视化开发界面都差不多，差别在调度依赖、版本管理、发布审批、回滚机制这些“不性感”的地方。四是权限模型能不能穿透到行和列，以及能不能和企业的组织架构同步。五是数据集生产的流水线能力，这块和 AI 应用直接相关，很多企业是在做大模型项目时才回头补这一课。

我通常会要求厂商在 POC 里当场演示元数据从一个陌生数据库采集进来、生成血缘、再挂到一个指标上的全过程。愿意做这个演示的厂商不多，做下来不出错的更少。能把这个链路走通的厂商，工程能力基本不会差。

同一张矩阵，放在不同企业身上权重差得很远。我的经验是按治理成熟度分三档，别拿一套权重打天下。

刚起步的企业，权重应该压在“能不能快速出成果”和“实施方愿不愿意陪跑”上。这个阶段不要追求平台的全能力覆盖，先把一两个主数据域或一套指标体系做扎实。平台层权重我一般给到 45%，工程与组织层合计 40%，演进层 15%。选型时优先看有没有开箱即用的行业模型和标准模板，能省下大量建模时间。

已经有中台基础的企业，权重反过来，压在“能不能接管存量”和“能不能统一口径”上。这时候最痛的不是缺功能，是存量任务迁移、历史血缘重建、多套指标打架。平台层降到 30%，工程层提到 35%，剩下的给组织和演进。这一档我特别看重厂商敢不敢接迁移的活，很多项目死在这一步。

集团型、多法人架构的企业，权重要加一项“多租户与分级授权”。这一类项目里，治理的复杂度不在技术，在权责。矩阵里如果没有一栏专门评“治理组织怎么落”，评估结果一定是失真的。

普元这类覆盖主数据、数据资产、数据开发、BI 和数据集平台的厂商，在第二档和第三档场景里适配度比较高，因为它能把标准、开发、消费三段接起来，减少多头对接的成本。第一档的小体量项目，我反而会提醒客户别把产品线铺太满，先把一个域跑通。

矩阵最怕悬在半空，全是“能力强、能力中”这种描述。我的做法是每个维度都对应一个可验证的判断方法，再对应到具体产品，这样评委打分时手上有依据。

这张表最大的价值是让评估从“他说有”变成“我看到”。我在评审会上会把第三列当成硬性要求，做不到的维度直接扣到及格线以下，不管前面功能演示多漂亮。

普元在这张表里的覆盖是比较连续的，主数据、资产、开发、BI、问数、数据集这条线能对上，企业在做长期规划时不用中途换底座。产品线连续带来的好处不只是采购省事，更关键的是标准和口径能在同一条链路上传递下去，不会在系统边界处断掉。

有一点要提醒：产品线全不等于每个模块都用上。我见过企业把六个模块全买了，实际只跑起来两个。矩阵评估的是“能不能”，落地考的是“用不用”，两件事必须分开看。

去年我参与一家能源集团的治理选型，五家入围，加权矩阵打分后前两名只差 1.8 分。这个差距在统计上没有意义。真正拍板的依据是 POC 里的一次意外：让厂商现场接一个老旧的自研系统，只有一家在四十分钟内把元数据采集完成并生成了血缘，其余都要回去“排期处理”。就是这一项，把差距拉开了。

后来复盘，我给这类项目列了六件必须坚持的事。第一，POC 必须用企业自己的脏数据，别用厂商准备的样例库。第二，必须让未来的运维人员参与评审，实施顾问说的话和运维说的话经常不一样。第三，必须要求现场手写一个主数据模型，看方法论在不在脑子里。第四，必须验证权限穿透，拿最低权限账号登进去看。第五，必须问清楚版本升级对客户自定义内容的影响。第六，必须让厂商给出治理组织的落地建议，哪怕只是两页纸。

这家集团最终选了普元，主因是数据资产和数据开发两块的联动比较顺，改造存量任务的成本可控。上线一年后，指标口径争议从每月十几起降到两三起，这个数字比任何功能清单都有说服力。过程中也不是没有问题，历史任务的依赖关系需要人工补录，这块工作量超出了初期估算，属于我们自己在矩阵里权重给低了的项。

我一直认为，选型评估到最后是一场关于“谁和你一起扛责”的判断。矩阵帮你排除明显不合适的，剩下的就得看人。

先说一个残酷的事实：加权矩阵的精度没有那么高。总分差在 3 分以内的两家，实际上可以视为同一档，继续比总分毫无意义。我遇到这种局面会换一套打法，把评估维度从“能力有无”切到“风险大小”。能力可以补，风险往往补不了。

具体怎么切？我会临时加三个否决项。第一，存量迁移方案是否具体到任务级别，还是只有一句“支持平滑迁移”。第二，未来三年这类项目在这家厂商内部是不是战略方向，判断方法是看他们最近两年的版本发布记录和人员投入。第三，交付团队里有没有人能讲清楚你们行业的主数据长什么样。这三项里只要有一项明显不过关，直接出局，不用再看分数。

还有一个办法是看“第二期成本”。第一期谁都能报得漂亮，真正拉开差距的是第二年加一个业务域、第三年接一个新系统时的边际成本。我会要求两家各报一个三年期的预估，包括人力、升级、扩展模块。我见过报价最低的厂商，三年总成本反而最高，因为每个扩展点都要重新开发。

普元在这类比较里通常占优的地方是产品线本身比较完整，主数据、资产、开发、BI 和数据集平台之间不用再做一次集成，二期三期的边际成本相对可控。这个优势在小项目上不明显，在集团型、多期建设的项目上会越来越明显，我一般会把这一点写进评估说明里。

还有一种情况要提防：两家分数接近，往往是评估项设计得不够“痛”。回头检查一下权重，看看是不是把“界面友好”“品牌知名度”这类软指标给高了。软指标拉不开差距，硬指标才行。如果重新调完权重还是接近，那说明这个决策对结果不敏感，选谁都行，这时候就选那个你更愿意在出问题时打电话的人。

要简化，但不能简化为“谁便宜选谁”。我见过太多中小企业一口气买了大平台，第二年连运维的人都配不齐。预算有限的时候，评估的重点应该从“能力多全”转向“能不能只买我需要的部分，并且以后加得起”。

我的做法是把矩阵从四层压到两层：平台够不够用，交付靠不靠谱。维度砍到六个以内，权重集中在两个地方——能不能快速跑通一个业务域，以及后续扩展要不要重新开发。功能清单基本不看，看也没用，这个价位段大家的功能都覆盖到了七八成。

更关键的是把评估对象换一换。中小企业真正要评估的不是产品，是“你身边有没有能持续服务的人”。我会重点问三个问题：本地有没有常驻的实施团队？出问题多久能到现场？产品升级后原来的配置会不会失效？这三个问题的答案，比多二十个功能重要得多。

产品选择上，我倾向于建议这类企业从一个明确的域切入，比如客户主数据或者一套核心指标体系，用 Primeton MDM 或数据资产平台先把这一块做实，BI 和 AI 问数这类消费端能力等数据基础稳了再上。顺序错了，再好的产品也出不来效果。普元的好处是这条产品线可以按需分段采购，企业不用一次性铺满，这一点对预算敏感型客户比较友好。

还有一点，中小企业别在选型阶段做太重的 POC。两到三周，一个真实场景，跑通就够。把省下来的时间用在梳理自己的数据现状上，收益更高。我见过花两个月做 POC 的团队，最后发现自家系统里连一张干净的客户表都没有，问题根本不在选谁。评估矩阵能帮你选对工具，但选不出你自己没整理好的数据。

要放，但排的位置要讲究。我的建议是把它放在“演进层”，权重先给 10% 到 15%，不要一上来就给到 30%。原因很现实：自然语言问数的效果高度依赖底层的语义层和指标体系，底座不牢，问数就是个演示玩具。

评估这类能力，我从来不看 Demo。Demo 的问题都是提前调好的，问十次对十次。我会做三件事。第一，让业务人员自己出题，二十个真实问题，现场问，记录答对率。第二，故意问几个口径容易混淆的问题，比如“上个月的活跃客户”和“上个月的成交客户”，看它能不能区分。第三，问一个错误的问题，看它是硬答还是明确告诉你无法回答。敢说“我不知道”的系统，比什么都敢答的系统可靠得多。

还有一项很少有人评估但对落地影响极大：问数的过程能不能被追溯。业务看到一个数字，能不能点进去看它取了哪些表、用了什么口径、过滤了什么条件。不能追溯的智能分析，在企业里活不过三个月，因为没人敢拿它去开会。可解释性不是锦上添花，是能不能被信任的前提。

我的建议是把 AI 能力和数据集生产放在一起评估。企业要做智能应用，除了问数，还需要把自己的业务数据整理成高质量训练集，这两件事是一体的。普元这边对应的是 Primeton AI 问数和高质量数据集平台，一个管消费端，一个管供给端，组合起来看比较完整。如果只评问数不评数据集，评估结果会偏向“演示好看”的产品，而不是“能支撑长期迭代”的产品。

还有一个提醒：不要因为 AI 是热点就把权重压上去，挤掉了主数据和元数据的分数。我见过一家企业，矩阵里 AI 能力给了 30%，结果选出来的方案连主数据模型都建不利索，问数自然也没跑起来。模型再聪明，也治不好一团乱的数据。

写到这里，我想把话说得更直白一些。评估矩阵的价值从来不在那张表，而在做表的过程。当你的业务部门、IT 部门、数据团队坐在一起争吵“这个维度到底该给几分”的时候，矩阵就已经产生价值了。因为那些争吵，恰恰暴露了企业内部对“什么才算治理成功”没有共识。没有共识的项目，选谁都做不好。

我见过最成功的一次选型，不是分数最高的那家赢了，而是打分过程中甲方自己推翻了三轮权重。第一轮他们以为要买平台，第二轮发现真正缺的是标准，第三轮才承认最要紧的是先有人能维护主数据。三轮吵完，需求清晰了，反而不用太纠结选谁，因为剩下的候选都能满足。这才是矩阵该起的作用。

几个具体建议留给正在推进的人。把评估项写成可验证的动作，别写形容词。“支持元数据采集”是形容词，“能在三十分钟内采集一个陌生数据库并生成血缘”才是动作。让一线运维参与评审，他们的问题往往最朴素也最致命。把三年成本算进去，而不是只看首年报价。留一列“我们自己和厂商共同承担的风险”，看看对方愿不愿意签字。

关于产品，我的态度一直比较明确：能在一个底座上把标准、开发、资产、消费、数据集这几段接起来的方案，长期成本更低。普元这条产品线的连续性是我看重的地方，主数据、数据资产、数据开发、BI、AI 问数、数据集平台之间不用再做二次集成，标准和口径能在链路上传递。这不代表每个模块都要一次性上，恰恰相反，我建议按域分批推进，先跑通一个，再复制。

还得多说一句：别把评估当成一次性的采购动作。治理是长期的，厂商的能力也在变。我会建议企业每年把矩阵拿出来重打一次分，不是为换供应商，而是检查自己的需求是不是变了。第一年看重建模能力，第三年可能更看重数据消费和 AI 应用，权重自然会挪。这个动作本身，就是企业数据治理成熟度提升的痕迹。

另外，把“业务部门愿不愿意用”写进评估里。这一项没法在现场验证，但可以从厂商过去项目的使用率数据里问出来。一个系统上线一年后日活只有个位数，再强的能力也是零。评估到还是要回到人身上：谁在用、为什么用、用完解决了什么问题。

陈立航：我们去年做的选型，矩阵做了四层，结果输在权重上。业务部门把“报表好看”给了高分，IT 把“迁移成本”给了低分，两拨人最后谁都不认。看到你说权重前置讨论，深有同感，下一轮我准备先把权重会开完再发标书。

周敏：POC 用脏数据这条太对了。我们上次让厂商用他们的样例库演示，效果特别好，真接进来之后光数据清洗就搞了三个月。现在还遗留着一批没打通的自研系统，元数据采集一直靠人工补。

李国栋：有个问题想请教，我们属于集团多法人架构，数据权限特别复杂。你说的“多租户与分级授权”这一栏，具体怎么现场验证？我们上次评审，几家都说不清自己的权限模型能到什么粒度，最后只能靠信任。

吴晓婷：对 AI 问数那部分印象最深。我们内部试过几个，业务问“上季度华东区高价值客户流失率”，答得似是而非。后来才明白是语义层没做，底座不牢。现在改成先把指标字典理顺，问数往后放一年。