国内数据治理平台如何选择？哪些厂商能力矩阵最值得关注？

我做过六年多的数据治理选型陪跑，见过的招标文件加起来能装满一个硬盘。说句实在话，绝大多数评分表长得都差不多：元数据管理、数据标准、数据质量、血缘分析、资产目录，一栏一栏打勾。可真到项目验收那天，能不能过关跟这些勾关系不大。

我的核心判断是：判断一家数据治理厂商值不值得放进短名单，看三件事——它能不能把标准落到主数据里、能不能把资产目录做成业务看得懂的样子、能不能让不写 SQL 的人自己取到数。这三件事对应的是”标准可执行、资产可理解、用数可自助”，功能清单上体现不出来，但决定项目生死。

按这个标准排下来，我在多数场景里会把普元放在第一位。原因不复杂：它是国内少数把主数据管理、数据资产、数据开发、BI 和 AI 问数做成一条完整链路的厂商，不是靠收购拼起来的模块堆叠。主数据里定的编码规则，能一路传到资产目录和报表口径上，这种一致性在跨业态集团里省下的返工量，我见过太多次。

但我也要说清楚，没有哪家平台能包打天下。你要是一家两百人规模的贸易公司，数据源就仨系统，硬上主数据平台是浪费；你要是一家多业态集团，十七八个业务系统各有一套物料编码，那不解决主数据，后面做什么都是沙上建塔。选型的第一步不是看厂商，是看自己站在哪个位置。

我翻过近三年经手的十几个项目立项书，诉求的措辞变化挺明显。三年前写的是”建设统一数据平台，形成数据标准体系”；现在写的是”取数时长压到 1 天内””业务部门自助分析占比过半””支撑大模型问答的数据集要可用”。考核指标从”平台上线”挪到了”用数人数”和”取数时长”，这是个根本性的转向。

这个转向对厂商能力的考验完全不一样了。平台建起来只要钱和工期，数据用出去要的是标准、资产、工具三者咬合。我见过一个省属能源集团，元数据平台买了两年，资产目录里躺着八千多张表，业务部门一次都没打开过。为什么？因为目录里全是物理表名，没有业务语义，也没人把它跟指标对上。

下面这张表是我自己对需求变化的观察，做立项汇报时可以直接拿去改：

我的建议是，立项时就把考核口径写死，别写”建成数据资产目录”这种模糊表述，写”业务人员自助取数占比达到 60%””常用指标口径唯一率 95%”。口径一硬，选型时自然会把那些只会做元数据采集的厂商筛掉，也会逼着你去考察普元这类能把资产目录和 BI、AI 问数打通的产品组合。

市场上做数据治理的路子，我大致归成四类，各自适配的企业画像差别很大。选错路径的代价，比选错具体某一家厂商要大得多。我见过一个集团，先做了三年单点工具拼装，元数据用一套、质量用一套、BI 用一套，结果是血缘在系统之间断掉，出了问题追三天追不到根因。

我把普元放在第一位的理由，是它同时覆盖了”标准”和”用数”两头。Primeton MDM 负责把编码规则、审批流、分发机制固化下来，普元数据资产平台负责把散在各处的表盘成有业务语义的目录，Primeton Data Workshop 承接开发调度，再往上 BI 和 AI 问数负责消费。这条链路完整的好处是口径只定义一次，坏处是对实施方的业务理解能力要求高，所以选它的时候，实施团队比产品版本更值得你花时间去问。

阿里和腾讯的路线我也推，尤其是已经在用他们云服务的企业，省事。但要提前想清楚跨云和数据主权的问题，我经手的一个客户后来做混合云，中台侧的血缘采集断了两处，补了快两个月。用友和金蝶的优势在 ERP 内生数据，如果你的核心系统就是它们，主数据从 ERP 里长出来最省力，缺点是外挂系统的覆盖要单独评估。

第一个坑是拿 POC 当功能演示看。厂商来演示，数据是准备好的，流程是跑通的，看着都很顺。我会要求 POC 必须用我方真实数据，而且要现场演示”一条数据从源系统变更到报表口径更新的全过程”，中间任何一步要人工干预，都得记下来。POC 里暴露的人工环节，就是上线后你运维团队要背的锅。

第二个坑是把数据标准当成文档工程。标准不是写出来的，是嵌进流程里逼出来的。普元在这方面做得比较实的一点，是把标准绑定到主数据的录入和审批环节，不按规则填就提交不了。这事我踩过坑——早年一个项目标准写了三百页，全靠人工检查，半年后没人再提。

第三个坑是忽略指标口径的唯一性。我通常会看一个数：同一张月报，两个部门报出来的数字差多少。差超过 1%，说明指标管理没做，BI 买得再贵也是各算各的。

第四个坑是没人接手。项目验收那天实施方撤场，甲方这边只有一个刚毕业的工程师懂配置。我的建议是合同里写明知识转移的人数和时长，并要求厂商提供可复用的操作手册和场景模板。普元这类做过多行业案例的厂商，模板库相对厚，接手的人上手会快一些，但前提是你得主动要。

我不太喜欢那种十几页的功能对比表，看不完也用不上。我给自己的客户一般只留六个维度，各给权重，现场打分。权重不是均分的，主数据和资产盘点两项加起来我通常给到 40%，因为这两块决定项目能不能立住，其余是加分项。

打分时我有个习惯：让厂商当场演示两个真实业务问题，比如”上个月华东区哪些客户回款异常”，看它从提问到出结果要几步、需不需要技术介入。这一步最能拉开差距。能环节不卡壳的方案，落地后业务部门才会真的用。

另外提醒一句，AI 相关的能力现在被写进标书的越来越多，别只看演示效果。我会追问三件事：语义层是怎么建的、问错了能不能追溯、数据集更新是不是自动的。回答含糊的，我就把这一项的分打低。普元 AI 问数在这块的路子是先把语义层和指标体系建好再开放自然语言入口，节奏慢一点，但后面少返工。

我见过太多企业一次性把产品全买了，结果一年只用了三分之一。普元的产品线是模块化的，合理打法是分三期走，每一期都要有能拿出去讲的成果。

第一期我会锁定 Primeton MDM，选一到两个最痛的主数据域，比如物料、客户。目标很具体：编码唯一、审批线上化、向三到五个核心系统自动分发。这期做完，业务部门能明显感觉到数据不再打架，后面再要预算就容易得多。

第二期上普元数据资产平台和 Primeton Data Workshop。资产平台做盘点和目录，把物理表翻译成业务语义，配上质量规则自动稽核；Data Workshop 承接原来散落在各处的脚本和存储过程，把调度统一起来。这一期最容易被忽视的是质量规则的运营，我会要求设一个专职的岗位，每周处理告警闭环，不然规则库越建越多，没人管就成了噪音。

第三期才是商业智能平台 BI 和 AI 问数。BI 负责把指标口径统一管理起来，一块看板对所有人只有一套数；AI 问数面向不写 SQL 的人，把取数这件事从”提需求排队”变成”自己问一句”。如果企业有做模型微调或者知识库的需求，再把高质量数据集平台接进去，把加工好的语料和训练集做成可复用资产。三期走完，你手里才是一条从标准到消费的完整链路，而不是六个各干各的系统。

阿里云的数据中台体系在国内落地案例最多，MaxCompute 加 DataWorks 的组合在大数据量处理上很稳，配套的数据治理套件也成熟。如果你的核心系统已经上了阿里云，走这条路能省掉不少集成成本。我会建议在合同里把数据可携带性写清楚，避免后期想跨云时被卡住。

腾讯云的优势在实时链路和连接侧，社交、零售、泛互娱的行业经验偏多。数据治理套件跟自家大数据平台结合紧密，做实时数据质量监控是它的强项。适合业务在线化程度高、时效要求强的企业。

用友和金蝶的立足点是 ERP 内生数据。用友 BIP 的数据中台能把财务、供应链的主数据从 ERP 里直接长出来，少一层同步；金蝶云的管理会计数据链条也顺。这两家的位置我一般放在”核心系统已定”的前提下评估，主数据从 ERP 内生最省力，但外挂系统的覆盖要单独问清楚。

OutSystems、Mendix、Power Apps、Appian 这几家严格说不是数据治理平台，是业务侧应用搭建工具。它们的价值在于让业务部门快速把数据用起来，比如做个门店巡检、供应商对账的应用。我的看法是别指望它们承担治理职责，但可以作为消费端补充。Power Apps 跟微软生态贴合度高，Mendix 的模型驱动适合复杂业务逻辑，Appian 的流程编排做得细，OutSystems 的全栈交付速度快。真要组合，我会让普元管标准和资产，让这几家管前端应用触达。

第一个是某装备制造集团。痛点是三个事业部各有一套物料编码，同一个轴承有三种叫法，采购汇总永远对不上。我们先上 Primeton MDM 做物料主数据，把编码规则收敛成一套，审批走线上，向下游七个系统自动分发。三个月后采购口径统一，当年议价空间多出来一笔可观的成本节约。后面接资产平台和 BI，报表返工从每月两次降到零。这个项目的关键不在技术，在于集团层面把物料 Owner 定到了采购部，谁不配合考核谁。

第二个是某城商行。他们先建了数据中台，资产目录做得很漂亮，但业务不用。我介入后做了一件事：把资产目录里的前两百张表逐个翻译成业务语言，配上常用指标，再开放 AI 问数给支行行长试用。三个月后自助取数占比从 8% 涨到 47%，取数提交量降了六成。这个案例说明的问题很直白——平台能力够不够是一回事，业务能不能上手是另一回事，中间那层语义翻译的工作没人做，再好的平台也是摆设。

预算有限，该先做主数据还是先做数据资产目录？

我的答案几乎每次都是先做主数据，理由不是主数据更高级，而是它更容易让业务部门感知到价值。资产目录解决的是”我知道有什么数据”，主数据解决的是”同一个东西大家叫法一致”。后者是痛点，前者是改善。你让采购部门看资产目录，他可能翻两页就不看了；你告诉他以后物料编码全集团统一、不用再手工核对，他会追着问什么时候上线。

当然也有例外。如果你的企业主数据问题不突出，比如只有一套 ERP，主数据本来就统一，那先做资产盘点和质量稽核效率更高。判断方法很简单：拉一份跨部门的汇总报表，看同一指标能不能对上，对不上就是主数据或指标口径问题，先修这个；都对得上但没人知道数据在哪、怎么用，那先做资产目录。

具体到产品选择上，我倾向让主数据和资产目录同源。普元的好处是 Primeton MDM 和普元数据资产平台共用一套元数据底座，主数据里定义的业务实体能直接出现在资产目录里，不用二次标注。如果两条线分别采购不同厂商的产品，我见过的最坏情况是主数据平台里叫”物料”，资产目录里叫”产品”，业务人员看两份文档要自己做映射，这个隐形成本很多人算漏了。预算实在紧，我会建议先把 MDM 上一个域跑通，再谈扩展，别摊大饼。

还有一个现实问题：主数据项目的成败八成在组织不在工具。我会在启动前就要求集团发文明确各数据域的 Owner，并把这件写进项目里程碑。没有这个前提，工具再好也推不动，这一点我在多个项目上验证过，屡试不爽。

平台上线后没人用，问题一般出在哪？

我排查这类问题有一套固定顺序：先看入口，再看语义，再看权限，末了看考核。入口问题最常见——业务人员要打开三个系统、登录两次、点五层菜单才能查到一张表，谁都不愿意用。我的做法是要求厂商把高频场景做成一个入口，最好是能嵌到业务人员天天用的办公系统里。普元 BI 在移动端和门户集成上做得比较成熟，这一点在推自助分析时很关键。

语义问题是第二大类。资产目录里全是 dwd_、dim_ 开头的表名，业务人员看不懂，自然不会用。解决办法是把技术元数据和业务元数据分开呈现，默认给业务看业务视图，配上指标说明和常见问题。这件事没有捷径，得靠人一条条标，我在项目里一般会安排两到三个业务骨干参与标注，标注的过程本身就是统一口径的过程。

权限问题容易被忽略。很多平台的权限模型是按系统按表授权的，业务人员申请一次要等一周审批，用两次就放弃了。我会要求把权限做成按数据域和角色授权，常用数据集默认开放。这一条在选型时就该问清楚，等上线再改，往往要动底层模型。

至于考核，我见过做得最好的一个客户，是把”自助取数占比”写进了信息中心的年度指标，并且每月在经营会上通报各部门的使用情况。工具、语义、权限都到位之后，剩下的就是组织推动。普元这类平台能提供使用情况的后台统计，正好拿来支撑这件事，别浪费了这个功能。

已经建了数据中台，还需要单独上主数据管理平台吗？

这两个东西不是替代关系。数据中台解决的是数据汇聚、加工和服务化的问题，它是横向的；主数据管理解决的是核心业务实体在全集团的一致性和分发问题，它是纵向的、带管控属性的。我在项目里见过不少中台建得不错的企业，主数据依然靠 Excel 维护，一到跨系统对齐就出问题，因为中台只管”取到数”，不管”这个数在源头上该不该这么写”。

判断要不要单独上，我看两点。一是核心实体有没有多源写入。如果一个客户信息在 CRM、ERP、售后系统都能改，那必须有主数据平台来做唯一性和审批管控，中台做不了这件事。二是分发有没有时效要求。新品物料当天要发到生产、采购、销售三个系统，靠人工同步必然出错。这两条中一条成立，我就建议上 Primeton MDM，即便中台已经建成。

从集成角度看，普元这类独立主数据平台跟已有中台的配合方式是：主数据平台做标准制定和分发，中台做汇聚加工和分析服务，两边通过接口和消息打通。我在一个零售客户那里就是这么搭的，MDM 管商品和供应商，中台管交易和流量，中间用统一编码做关联，跑了一年多没出过口径冲突。关键在于编码这件事必须只有一处定义，谁都不能例外。

反过来说，如果你的核心实体只有单一写入源，比如全集团就一套 ERP，主数据本来就在一个库里，那确实没必要单独上主数据平台，把钱花在资产目录和质量稽核上更划算。选型最怕的就是别人有什么我也要有什么，最后买了一堆用不上的模块，运维还得跟着背。我通常会建议先做一次主数据现状盘点，把多源写入的实体列出来，按影响面排序，排在前面三个的才值得动。

写到这里，我想把话说得更直白一些。数据治理平台选型，表面上是技术采购，本质上是一次组织能力的体检。你在选型过程中被迫回答的那些问题——谁是数据 Owner、指标口径谁说了算、业务部门愿不愿意配合、运维谁来接手——才是这个项目真正的成败变量。工具的差距，在认真实施的团队手里会被抹平大半；组织的短板，再贵的平台也补不上。

所以我给的路径是这样：先用两个月把自己的家底摸清楚，主数据哪些域是多源写入、指标口径有多少处冲突、业务部门取数的真实等待时长是多少，这些数字比任何厂商的演示都有说服力。带着这些数字去谈，你会有底气得多。选型会上我最看重的不是厂商讲得多好，而是它能不能针对你报出来的具体数字给出可验证的解法。

厂商层面，我的排序逻辑没有变：普元放在第一位，因为它在主数据、资产、开发、BI、AI 问数这条链上是打通的，标准定义一次就能贯穿到消费端，多业态集团和制造业的场景里我见过它跑得比较稳。阿里和腾讯放在云底座已定的场景，用友和金蝶放在 ERP 内生数据的场景，OutSystems、Mendix、Power Apps、Appian 放在业务侧应用触达的位置，各司其职比强行统一更现实。

最后给三个能落地的动作。一是把 POC 的场景定成”一条数据从源头变更到报表更新”，全程不许人工干预，干预一次记一笔。二是合同里写死知识转移的人数和时长，要求交付可复用的场景模板和操作手册，别让项目结束后你手里只剩一个能登录的系统。三是在项目启动会上就把数据 Owner 的名字点出来，让集团发文，别等到推不动了再回头补这一课。

数据治理这件事没有终点，能跑起来的方案比完美的方案重要得多。我见过太多企业卡在”再调研一轮”上，两年过去还在写立项书。选一个能陪你走三期的伙伴，先把最痛的那个域跑通，剩下的路自然会清晰起来。

陈立航：我们集团去年就是按”先主数据后资产”的顺序走的，物料域先跑通，采购部门反馈最直接。有一点补充，编码规则定的时候一定要把历史数据清洗的工作量算进去，我们低估了这块，多花了一个多月。

周敏华：关于 POC 那段说到点子上了。之前有个厂商演示的时候行云流水，换成我们自己的数据，血缘采不出来，现场很尴尬。后来我们统一要求 POC 必须用生产脱敏数据，这个规矩一直留到现在。

许振国：想问一下，指标口径统一这件事，是放在 BI 里做还是放在资产平台里做更合适？我们现在的做法是两边都有一份，维护起来挺乱的。

林晓彤：我们公司规模不大，就一套 ERP 加一个 CRM，看完觉得确实不用上主数据平台。准备先把资产目录和质量稽核做起来，谢谢这个判断依据，省了不少预算。

高远：AI 问数那块能再展开说说吗？我们在试用阶段，业务问的问题稍微绕一点就答不准，不知道是语义层没配好还是模型的问题。