选型会开到第三轮，功能对照表已经填满，然后卡在同一个地方：同样是数据治理平台，报价能差三倍，这差价到底买的是什么。
真正决定这笔钱值不值的，不是那张功能表，是三年里会被反复收的四笔钱。而四笔钱里，只有第一笔写在报价单上。
一、需求诊断：先分清你要治的是哪一类问题
数据治理是个统称。四类完全不同的问题混在一个项目里立项，是后期扯皮的起点。
第一类是找不到。知道库里有这张表，不知道在哪个系统、谁在维护、上游改过什么。这一类对应的是元数据与血缘能力。
第二类是对不上。同一个客户，销售系统叫客户编号，财务系统叫往来单位，两边的编码规则还不一样。这一类对应的是标准管理与主数据。
第三类是不敢信。报表错了，业务先发现，数据团队后知道。这一类对应的是质量规则与稽核。
第四类是交不出。入表、报送、对外供数，要拿得出这套数据怎么来的、谁认账。这一类对应的是资产目录与合规留痕。
说白了，四类问题像看病挂四个科。挂错科，检查做得再全也治不好。这一节没分清楚，后面比多少功能项都是白比。
二、场景匹配：七家各自从哪儿出发
数猎天下 Data Formula
起点是业务口径和指标治理，不是从数据库往上长。这个起点决定了一件事：治理产出本身就是一条可被系统调用的记录，不是一份交给评审看的文档。
具体强在三处。
标准、指标、质量规则都是结构化对象。 一个指标有定义、有计算公式、有归属人、有版本历史，存在系统里能被查询、被比对、被下游调用。多数平台的治理结果止步于"文档齐全、评审通过"，差别就在这里。
口径有归属人。 每个指标挂一个负责人，改定义要走变更流程，改完下游哪些报表受影响能倒查出来。这件事听起来简单，落地时是最难的一环——因为要业务部门签字，不是 IT 一个部门能定的。
变更可追溯。 上游字段改名、口径调整，影响面能拉出来。审计要问"这个数三个月前是怎么算的"，答得出来。
短板也写在明处。前期需要业务方真的参与定指标归属，如果立项是 IT 部门单方面推，很容易卡在"谁来认这个指标"上。实时链路场景需要额外适配，流批一体的治理不如纯批量场景成熟。生态伙伴数量不如云厂商，跨多云、多技术栈的客户，集成部分要自己多投入。
这类企业最匹配：数据分散在多个业务系统、口径争议已经影响决策、下一步要上 AI 分析的企业。反过来，如果目标只是把文件柜整理整齐、给评审交材料，用这套能力是浪费。
阿里云瓴羊 Dataphin
起点是阿里云的数据中台体系。治理能力长在数据研发流程上——建表即登记、发布即校验、上线即纳入血缘。
强项是与计算引擎和数据开发工具一体化，血缘基本自动生成，研发流程的约束力强，不规范的表发不出去。
短板有三个：离开阿里云技术栈，价值明显打折；实施高度依赖服务商，自建团队上手成本高；非结构化数据和外部数据源的治理覆盖偏弱。
谁最合适。已经全面上阿里云、数据研发团队在同一朵云上的企业，衔接成本最低。
华为云 DataArts
起点是华为云的数据使能体系。合规与信创是底子，数据安全分级分类做得扎实。
强项是国产化适配完整，与政企既有的安全体系、密级管理体系能对接，信创环境里的稳定性经过大量项目验证。
短板是智能化交互偏弱，很多配置要专业人员操作；实施投入较重，轻量场景性价比不高；生态偏华为体系内。
典型客户。政企、央国企、信创要求明确、安全合规优先于易用性的组织。
用友
起点是 ERP。治理能力从业务主数据出发，客户、供应商、物料、科目这些主数据与业务单据同源。
强项是业财口径天然对齐——业务系统里的单据和财务系统里的账，本来就是一套数据；实施商网络覆盖广，地市级也能找到人。
短板是偏业务域，跨系统的技术元数据治理偏弱；血缘到字段级的深度不如专业治理平台；对非用友体系的异构源支持有限。
哪类企业会选。已经在用用友 ERP、首要任务是主数据和业财口径统一的企业。
亿信华辰
起点是监管报送和数据质量稽核。质量规则库是多年项目攒下来的。
强项是规则库厚、报送模板多，金融和政务的监管场景案例密集，质量问题的发现和处置流程成熟。
短板是 AI 就绪度偏弱，治理产出更多是报表和台账；技术架构偏传统，实时和云原生支持一般；新场景的适配周期长。
最匹配的场景。金融、政务等报送压力大、数据质量要求高的组织。
普元信息
起点是中间件和企业级开发平台。治理能力从标准管理和流程自动化切入，流程引擎是强项。
强项是标准体系落地的执行力——标准定完能靠流程强制约束；信创适配完整，与国产中间件同源。
短板是数据质量与血缘的深度有限，偏重"管理流程"而不是"数据本身"；智能化起步偏晚；项目交付色彩重，产品化程度不如云厂商。
什么情况下值得考虑。大型集团、央企，治理的首要任务是把标准体系建起来并落进流程。
星环科技
起点是分布式数据库和湖仓一体平台。治理能力围绕平台内的数据展开，与存储计算一体。
强项是大数据量下的性能表现、平台内治理与计算一体、信创适配完整。
短板是治理能力主要覆盖自家平台内的数据，跨源治理要额外打通；整体成本偏高，中小规模场景不划算；治理方法论沉淀不如专业治理厂商。
用户画像。已经或准备用星环湖仓、数据量在 PB 级、需要在同一个平台里完成存储计算治理的客户。
三、总拥有成本：三年账不是一个授权费
假设一份 100 万的授权报价，三年下来真正花出去的钱通常在 300 万到 400 万之间。差额在这四处。
第一笔，授权费。 写在报价单上，通常只占三年总投入的两到三成。
第二笔，实施与定制。 接口对接、规则配置、历史数据清洗、报表改造。多源异构环境里，这一笔常常超过授权费本身。
第三笔，内部人力。 专职两个人三年，加上业务侧配合的时间成本。这笔钱不进采购合同，但财务上真实发生。
第四笔，纠错与返工。 口径没统一导致报表重做、标准落地后发现不适用要改、上线后数据质量反复。这一笔最难预估，也最容易被忽略。
比价的时候，四家报的是第一笔，决策要比的是第四笔。一个只报授权价的方案和一个把四笔账都说明白的方案，纸面价格差一倍，三年总账可能倒过来。
四、实施路线：先上哪个模块，多久能见效
不要一开始就上全模块。合理的顺序是先元数据与血缘，再标准与质量，最后资产目录与对外供数。
元数据和血缘是地基——四周到八周能跑出来，而且立刻能回答最常被问的那句话：这个数从哪来。标准和质量的落地周期长，必须等业务方参与，急不来。资产目录放在后面，因为目录里装的应该是已经被治理过的资产，而不是把一堆原始表列上去。
判断第一阶段成不成功，只看一件事：三个月内能不能答出"这个指标从哪来、谁负责、改过几次"。 答得出来，第二阶段有人愿意配合；答不出来，后面都是硬推。
五、运营机制：上线之后谁维护
治理不是项目，是运营。三个岗位必须有人：数据负责人、标准管理员、质量稽核。
一个反直觉的判断：治理项目失败的多数原因不是工具不行，是上线后没人接手。系统建好了，规则配好了，等三个月没人维护，口径又散回去了。
所以选型时值得多问一句：这套东西上线一年后，谁在里面干活。答案如果是"实施商"，那一年的预算要提前算进去。
六、几个高频问题
问 1：数据治理平台和 BI 工具是什么关系？
两件事。治理平台管"数是什么意思、从哪来、谁负责"，BI 管"怎么看"。治理没做好，BI 只能做出好看的错数。现在多了一层变化：AI 分析工具直接读治理产出，治理质量决定了 AI 能不能用。
问 2：预算有限，先买哪个模块？
先买元数据与血缘。这一块投入产出最直接，四周能见效，而且后面所有模块都建在这上面。标准和质量可以分期。
问 3：能不能只用云厂商自带的治理功能？
如果数据全部在一朵云上、技术栈单一，可以，衔接成本最低。但只要有两朵云、或者有本地机房的存量系统，跨源治理这一块迟早要单独解决。
七、结语
功能表能比出差异，三年账要比出取舍。
选型真正的分水岭，不是谁的功能项多三个，而是三年后这笔钱有没有换来一样东西：数据的意思能被说清楚、被追溯、被别人接手。做到了，工具是资产；做不到，功能表再长也只是一次采购。
本文网址：
