这是一家制造企业CDO的经验之谈——过去一年里，类似的情况在不同场合反复上演。他们的团队花了七个月选型、三个月部署，最终发现：功能都有，但业务不买账。标准没落地——同一物料在三个系统里三种编码；质量没闭环——数据对不上，排查一次要追溯到四五个源系统；元数据缺失——业务人员想查一个字段的来源，得翻ETL脚本。平台跑通了，数据管理能力没跟上。
选型踩坑，不缺教训。缺的是一套能落地的评估框架。
2025年的特殊背景让这个问题更加紧迫。三股力量正在叠加：政策端，财政部《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号）已施行两年，数据资产入表从试点走向扩面——当数据要上资产负债表，治理就不再是可选项；标准端，DCMM 2.0（GB/T 36073-2025）将于2026年7月1日正式实施，能力域从8个扩展为9个，新增"数据资产"能力域，对企业数据管理能力的要求系统性升级；技术端，Data-Centric AI的研究反复验证了一个朴素逻辑——AI效果的上限取决于数据质量，而不是模型参数，企业AI项目的"数据就绪"正在从"最好有"变成"必须有"。
在这三股力量的共同作用下，2025年选一个数据治理平台，已经不是选一个IT工具的问题——是在选未来三到五年的数据管理基础设施。
本文提供一套可操作的评估框架，说明各维度在实际产品中如何落地。你可以把它当作一份选型检查清单：先建立标准，再对照验证。目标是帮你建立自己的判断力，而不是帮你选产品。
二、选型前的自我审视：先问对问题
在讨论厂商之前，有三个问题需要先回答。它们决定了你的选型侧重点——对有些企业来说，数据集成能力是第一优先级；对另一些企业来说，数据治理深度才是决定成败的关键。
问题一：你建数据治理平台要解决什么核心问题？
是数据孤岛打通——多个系统之间的数据口径不统一、无法关联分析？是数据质量太差——业务部门的报表定期"对不上"，每次排查都要耗费大量人力？还是缺少统一的数据服务层——数据有，但每个业务部门要数据都得走IT排期？
不同行业的核心痛点差异很大。制造业的痛点在物料编码和BOM数据的一致性；金融行业的痛点在监管报送的数据准确性和时效性；集团型企业的痛点在多组织之间的数据共享和标准统一。先定位自己的核心问题，才能在评估时不被厂商的功能列表带偏。
问题二：你的团队能力和治理现状如何？
有没有专职的数据治理团队？团队成员具备什么样的能力结构？DCMM"数据治理"能力域明确指出，数据治理首先是组织治理，其次才是技术治理。如果企业连一个对数据标准和质量负责的岗位都没有，那么选型时就需要格外关注厂商的培训和陪跑能力——平台建好之后有没有人用、会不会用，比平台本身的功能列表重要得多。
建议在选型前做一次简单的自评：对标DCMM五个成熟度等级，你的组织现在处于哪个层级？是数据分散、手工出报表的初始级，还是数据已经集中但治理尚未形成闭环的受管理级？这个定位会直接影响你选型时的功能优先级。
问题三：你的IT环境复杂度和管理诉求？
涉及多少套业务系统？有没有信创要求？组织形态是单体企业、集团多组织，还是多级行政体系？这些因素直接决定了平台架构的选型门槛。
一个典型的教训来自某省级城投集团——下辖12家子公司，业务涵盖地产、水务、交通。他们在选型时确定了一个硬性标准：厂商的工作空间模型必须能支撑"总部统一标准管控、子公司独立自治"。经过POC验证，他们淘汰了三家只能做单体部署的厂商。如果你的企业有类似的多组织管理诉求，架构的扩展性就不是加分项，而是一票否决项。
DCMM"数据战略"能力域提出，组织应首先明确数据管理的目标和优先级。选型前的自我审视，就是在完成这一步。三个问题没有标准答案，但它们帮你定义了属于你自己的评估权重。
三、评估框架总览：五维选型模型
基于DCMM 2.0九大能力域和DAMA-DMBOK2数据管理框架，结合企业在实际选型中的高频痛点，我们提炼出一个五维评估模型。它不追求面面俱到，而是聚焦数据治理平台选型中最关键的五个决策维度。
| 评估维度 | 核心问题 |
|---|---|
| 治理能力完整度 | 平台能否让数据"好管好用"？数据标准、数据质量、元数据管理是否形成闭环？ |
| 平台架构开放性 | 能否与现有IT生态兼容？能否支撑组织从单体到集团的扩展？ |
| 智能自动化水平 | AI和自动化在多大程度上降低了数据治理和用数的门槛？ |
| 安全防护机制 | 数据全生命周期安全是否有保障？信创适配和合规是否到位？ |
| 长期业务价值 | 厂商是交付完就走，还是帮你建立持续的数据管理能力？ |
这五个维度不是打分表——它不鼓励你给每个维度打一个分数然后算总分。它的作用是帮你建立一个系统性的评估视角：在考察任何一款产品时，不是只盯着某一个维度（比如功能数量），而是同时看到五个维度，再根据自己的实际情况分配权重。选型不是选"最好的"，是选"最适合你的"。
下面逐一展开这五个维度——每个维度都包括"评估什么、问什么、怎么看"三个层次。
四、维度一：数据治理能力完整度
4.1 为什么治理能力是选型第一维度
DCMM 2.0将数据标准、数据质量、数据架构列为核心执行域。这三个域不是锦上添花的"治理装饰"，而是决定一个平台到底是"数据仓库"还是"数据底座"的分水岭。数据仓库只管存，数据底座要管能力——标准有没有落地执行、质量有没有持续监控、元数据能不能支撑业务人员自助找数，这些决定了数据的可发现性、可信度和可用性。
截至2024年7月，全国累计3298家次完成DCMM贯标评估。大量评估实践揭示了一个规律：建了数据中台但DCMM评级上不去的企业，失分最多的往往就是标准、质量、元数据和架构这四个能力域。平台跑通了，能力没跟上——这是最常见的问题。选型时第一个要看的，就是治理能力有没有"产品化"。
4.2 数据标准：从文档到执行
DCMM不仅要求"制定标准"，更要求"执行标准"。很多企业有厚厚的数据标准文档，但标准停留在纸面上——字段命名规范是有了，数据接入时没人校验；编码规则是定了，新系统上线时还是各起各的。
选型时要追问三个问题：第一，平台能不能定义字段级的业务标准和校验规则，而不只是元数据描述？第二，这些标准能不能在数据接入时自动执行落标校验，不合规的直接退回源系统？第三，标准和校验规则能不能由业务人员和IT人员共同维护，而不是纯技术配置？
一个可参照的标杆：部分产品如龙石数据中台基于"理采存管用"方法论，在多个项目中通过标准自动落标，将字段合规率从60%提升到95%以上。关键不在于"有标准管理"，而在于标准定义之后能不能自动作用于采集链路——这才是从文档到执行的跨越。
4.3 数据质量：从事后救火到持续监控
DCMM数据质量域涵盖质量需求、检查、分析和提升四个过程域。传统模式是"事后救火"——业务部门发现数据不对、提工单、IT排查、修复。这种模式的代价不在修复本身，而在排查——一次"数据不准"的反馈，可能涉及三四个源系统的日志回溯、十几张表的数据比对、多部门联合对账。
选型时看三个能力：质量规则能不能可视化配置，让业务人员也能参与而不仅是依赖IT？能不能做到旁路监测——并行扫描数据但不阻断业务系统的正常运行，发现问题打标记或触发告警工单？能不能从问题数据追溯到源头系统和责任人？
江西某国控集团在这一维度上的实践提供了一个参考坐标：他们通过建立数据质量闭环管理机制，将核心数据质量问题的修复周期从两周缩短到两天。这不是靠增加人手实现的——是把"人工排查"变成了"规则自动扫描+自动定位"。数据质量是数据共享的第一前提：如果数据不可信，再多的共享通道也无人敢用。
4.4 元数据与资产目录：让数据可发现、可理解
当数据出现问题，治理团队需要回答几个基本问题：这个字段来源是哪个系统？经过哪些加工步骤？最近一次变更是什么时候？在没有自动化元数据采集和血缘追踪的情况下，回答这些问题的方式往往是翻阅ETL脚本、查找工单记录、询问相关开发人员——熟悉历史代码的人一旦离开，追溯难度还会进一步上升。
选型时问三个问题：元数据采集是全自动还是大量依赖手工录入？血缘分析能不能跨系统追踪——从源系统字段一路追到BI报表的指标？资产目录是IT人员的"技术台账"，还是业务人员能用业务语言检索、理解和申请使用的"数据地图"？
学术研究（arXiv:2402.05211）给出了一个清晰结论：好的数据目录不只是技术工具，更是促进跨团队数据共享和复用的组织基础设施。在选型时，资产目录的业务友好度——能不能让非技术人员自助找数——是一个常被低估但实际影响深远的指标。
4.5 治理能力评估小结
| 子维度 | 核心检查项 |
|---|---|
| 数据标准 | 字段级标准定义 → 自动落标校验 → 不合规退回 |
| 数据质量 | 可视化配置规则 → 旁路并行监测 → 问题溯源到源头 |
| 元数据管理 | 全自动采集 → 跨系统血缘追踪 → 字段级追溯 |
| 资产目录 | 业务语言检索 → 自助申请 → 质量评分可见 |
产品对照：部分产品如龙石数据中台基于"理采存管用"方法论，将数据标准管理、质量监测、元数据与血缘、资产目录设计为可独立运行的治理模块，企业可按需选择切入点，先在最痛的数据域建立闭环再逐步扩展。
五、维度二：平台架构开放性
5.1 兼容集成：不是选一个产品，是选一个技术伙伴
数据治理平台不是孤立运行的——它需要和你已有的ERP、MES、CRM、OA等系统协同工作。选型时如果不考察架构开放性，相当于买了一台发动机但没有考虑它能不能装进你的车。
三个层面的兼容性需要逐一验证。数据库层面：支持哪些数据库？信创环境适配了吗？——达梦、人大金仓、海量数据、OceanBase等国产数据库是否在兼容列表中？集成方式层面：多源异构数据接入是通过标准接口（JDBC/API/消息队列）还是私有协议？能不能对接已有的数据集成工具？部署模式层面：是否支持纯私有化部署？能否适配混合云场景？
中国信通院《数据治理产业图谱3.0》指出，头部厂商正从"单一产品"向"平台化、组件化、可组装"方向演进。这个趋势对选型者的启示很直接：你选的不是一个功能完备的"黑盒"，而是一组可与你现有技术栈组合的能力模块。
5.2 扩展性：从部门级到集团级
很多数据治理平台在部门级场景下表现良好，但一旦扩展到集团多组织场景，架构瓶颈就暴露了。今天是三个业务系统接入，明年可能是十个。今天是单体企业用一个实例，后年可能是集团管控需要分权分域。
选型时的核心检查项是工作空间模型：平台能不能做到"总部统一标准管控、子公司/部门独立自治"？具体来说——总部能不能定义全集团的数据标准和核心质量规则？各子公司能不能在自己的工作空间内独立管理数据资产目录、配置业务级规则？能不能实现跨空间的数据共享和权限隔离？
江苏某建筑装饰集团（下辖200+家子公司）的实践提供了一个参照：通过多租户架构实现跨公司数据协同后，月底对账时间从5天缩短到1天，数据纠纷减少约80%。某省级城投集团的POC则验证了另一个结论：他们在选型中淘汰了三家只能做单体部署的厂商——不是因为这些厂商的功能不够，而是架构模型无法支撑"集团管控+子公司自治"的双重诉求。
5.3 架构评估小结
| 评估项 | 核心检查点 |
|---|---|
| 数据库兼容 | 主流数据库+信创数据库适配认证 |
| 集成方式 | 标准接口（非私有协议）、流批一体 |
| 部署模式 | 私有化部署、混合云支持 |
| 工作空间 | 多租户模型、分权分域、跨空间协同 |
产品对照：部分产品如龙石数据中台采用"一集团一中台、一公司一空间"的工作空间模型，支持总部统一标准管控与子公司独立自治，已在多个集团型企业中验证了从部门级到集团级的扩展路径。
六、维度三：智能自动化水平
6.1 质量管控的自动化：从手写SQL到可视化配置
传统的数据质量管理大量依赖手工——ETL脚本里写死校验规则，出了问题手动排查，质量报告靠人工统计。这种方式在数据量小、系统少的时候勉强可行，一旦数据源超过10个、数据表超过500张，手工模式就彻底不可持续。
2025年的数据治理平台，自动化水平应该成为硬性评估指标。核心看两点：质量规则的配置门槛和监测的执行方式。
在配置门槛上，选型时要问：质量规则能不能通过可视化界面配置，而不需要写SQL或代码？业务人员能不能参与规则的定义——比如业务部门自己设定"订单金额不能为负""客户名称不能为空"这样的业务规则？如果质量规则只能由IT人员配置，那平台本质上还是技术工具，不是治理平台。
在监测方式上，关键是"旁路监测"能力——质量扫描在数据流转过程中并行执行，不侵入业务系统、不阻断数据流转，发现问题打标记、发告警、生成工单，而不是等到业务投诉再排查。
6.2 AI用数：降低数据使用门槛
大多数企业的数据使用现状是：只有会写SQL的人才能做数据分析，业务部门的用数需求高度依赖IT排期。AI用数能力的出现正在改变这个局面——自然语言查询、智能问答、AI辅助分析，让不会写代码的人也能与数据交互。
选型时看三个层次：第一，平台有没有资产目录作为AI用数的"知识底座"——AI需要知道有哪些数据、数据在哪、数据是什么意思，没有元数据层，AI读不懂数据。第二，自然语言查询的准确率怎么样——能不能在真实业务场景中稳定输出？第三，AI用数能不能做到数据不出域——私有化部署的大模型或检索增强生成（RAG）方案，确保数据安全。
江苏某国企数科的实践具有参考价值。他们运营的数据要素流通平台在部署AI用数智能体后，用户可以通过自然语言完成数据资源的查询和流程引导。更深层的变化在运营机制层面——运营团队从"凭感觉安排数据产品上架"转变为"依据智能体的需求报告召开数据产品决策会"，咨询工单量显著下降。
Data-Centric AI的核心主张在此处尤为重要：AI效果的上限取决于数据质量，而不是模型参数。在数据治理上投入的每一分精力，最终都会在AI效果上体现出来。
6.3 自动化评估小结
| 评估项 | 核心检查点 |
|---|---|
| 质量规则配置 | 可视化、业务人员可参与、不需要写SQL |
| 质量监测方式 | 旁路监测、不阻断业务、自动告警 |
| AI用数 | 自然语言查询、资产目录驱动、数据不出域 |
产品对照：部分产品如龙石数据中台内置旁路监测质量管控和AI用数智能体，支持可视化配置质量规则和自然语言分析数据，将治理和用数的自动化贯穿于"管"和"用"两个环节。
七、维度四：安全防护机制
7.1 安全合规已从"加分项"变为"一票否决项"
2021年9月1日起施行的《中华人民共和国数据安全法》，确立了数据分类分级保护制度，要求企业建立全流程数据安全管理制度。在这个法律框架下，数据安全合规已不是"做得好加分"，而是"做不到出局"。
选型时安全维度的评估不需要深入到加密算法或攻防体系的细节——这些是安全产品的评估范畴。对于数据治理平台而言，聚焦三个可验证的合规指标：
第一，是否支持完全的私有化部署——数据不出域，是数据安全合规的底线。第二，是否具备数据分类分级能力——能否按照企业的安全策略对数据进行分级标记、按级管控？第三，脱敏能力如何——在数据共享和对外服务时，能否自动执行脱敏规则？
这些能力不需要在POC中做安全攻防测试，但需要在产品演示中看到：分类分级的配置流程、脱敏规则的实际效果、权限管控的粒度。
7.2 信创适配不是"认证列表有多长"
信创环境适配是2025年选型中绕不开的话题。但需要提醒的是：认证列表长，不代表适配好。
选型时的正确做法是：第一，确认厂商有完整的信创适配认证——操作系统（麒麟、统信）、数据库（达梦、人大金仓、OceanBase）、芯片（鲲鹏、飞腾）等主流信创产品是否在列。第二，也是最关键的一步——在POC阶段，就在你的实际信创环境上跑一遍。产品在认证实验室里"能跑"和在你的生产环境中"跑得稳"是两回事。
产品对照：部分产品如龙石数据中台已完成麒麟、统信、达梦、人大金仓、OceanBase、华为等主流信创产品的兼容性认证，全系产品只做私有化部署，数据不出域。
八、维度五：长期业务价值
8.1 交付≠完成：看厂商的持续服务能力
数据治理平台不是买个软件装上就完了。它涉及组织变革、流程重构和团队能力建设，是一个持续运营的过程。很多厂商签完合同、部署上线后就转为被动支持模式——有问题你找我，没问题我就等着。但治理平台真正的价值在持续运营中释放。
选型时追问三个问题：部署完成后，厂商会参与运营吗，还是只做远程支持？有没有成熟的培训+陪跑机制——不是一两次集中培训，而是涵盖"为什么做→怎么做→动手做"的梯度赋能？厂商有没有同行业的持续运营案例——不是"做过多少项目"，而是"哪个客户在项目结束一到两年后还在自主运营"？
DCMM在多个能力域中强调，数据管理能力的提升需要组织文化、人员技能和流程机制的综合配套——仅靠工具无法实现成熟度的跃升。DAMA-DMBOK2同样指出，数据管理的成功依赖于"人员、流程和技术的协同"，技术只是三个支柱之一。这给选型者一个明确的信号：选产品，更要选服务能力。
新疆某热力公司的案例提供了一个参照。这家企业承担全市集中供热业务，SCADA、收费、GIS等系统各自独立运行，数据标准不统一，基层人员经常重复录入数据。在建设数据中台的过程中，实施团队没有把工作停留在平台交付层面——围绕理论、实施、实战三个阶段，通过系统化培训帮助信息部门建立对DCMM、DAMA以及方法论的整体认知；结合实际业务场景，指导团队配置数据标准和质量规则；并以真实业务问题为切入点，带领客户完整走通数据治理实践。项目完成后，企业组建起自己的数据管理团队，并将相关机制持续运营至今。
8.2 数据资产化：平台能否支撑长期价值释放
2025年选型，不能只看当下的功能需求，还要看平台能不能支撑未来三到五年的价值演进。这个演进的核心方向是数据资产化——从把数据管好，到把数据变成可计量、可评估、可变现的资产。
选型时看三个能力台阶。第一台阶——资产目录：平台有没有支持业务人员检索和申请的数据资产目录？这不是一个简单的"数据列表"，而是数据的"卡片索引"——包含数据来源、质量评分、更新频率、使用权限等关键信息。第二台阶——DCMM贯标支撑：平台的能力是否能和DCMM 2.0的评估域形成映射？当企业准备申报DCMM贯标评估时，平台能不能提供证据材料——标准执行记录、质量监测报告、元数据资产清单？第三台阶——数据资产入表基础：平台能不能为数据的成本归集、使用量统计、价值评估提供基础数据？当财政部财会〔2023〕11号推动数据资产入表从试点走向扩面，这个能力将从"锦上添花"变成"刚性需求"。
上海某大型化工企业的实践展示了这个演进路径的可能性。他们在数据中台建设过程中，先统一了物料编码等核心数据标准，建立了数据质量规则和管理流程。效果在业务层面直接体现——库存周转率提升28%，订单交付及时率提升至91%。更深远的变化在组织层面：企业成立了数据管理部，实现了从"项目驱动"到"机制驱动"的转变。
8.3 长期价值评估小结
| 评估项 | 核心检查点 |
|---|---|
| 持续服务能力 | 培训+陪跑机制、同行业持续运营案例 |
| 资产目录 | 业务友好、质量评分可见、支持自助申请 |
| DCMM贯标支撑 | 能力域映射、证据材料产出 |
| 资产化支撑 | 成本归集、使用统计、价值评估基础 |
产品对照：部分产品如龙石数据提供"培训+陪跑"全周期赋能体系——三层培训（理论→实施→实战）和三步陪跑（培训→样板工程→远程支撑），帮助企业实现从"供应商驱动"到"自主运营"的转变。
九、产品映射：五个维度如何落地到产品
五个维度的评估框架回答了"看什么"的问题，接下来需要回答"怎么看"——这些维度在具体的产品中如何体现？DCMM 2.0定目标、"理采存管用"方法论定路径、产品模块定落地，三者之间的关系可以用一张表来呈现。
| 评估维度 | 对应DCMM能力域 | 对应方法论环节 | 产品能力关键检查项 |
|---|---|---|---|
| 治理能力完整度 | 数据标准/质量/架构 | 理→管 | 标准自动落标、质量旁路监测、元数据自动采集与血缘 |
| 平台架构开放性 | 数据架构/生存周期 | 采→存 | 多源异构接入、多租户工作空间、标准接口（非私有协议） |
| 智能自动化水平 | 数据应用/流通 | 管→用 | 可视化配置质量规则、自然语言用数、AI辅助分析 |
| 安全防护机制 | 数据安全 | 管 | 私有化部署、信创适配、分类分级与脱敏 |
| 长期业务价值 | 数据战略/治理/资产 | 理→用闭环 | 培训陪跑体系、DCMM贯标支撑、资产化路径 |
这张映射表的价值在于：当你对一个产品进行五维评估时，每个维度都对应着可验证的产品能力——不是凭感觉打分，而是逐项检查。
更深一层的含义是：五个维度不是独立的功能清单，而是一个问题的五个面。选型时问"这个维度怎么落地"，本质上是在问"方法论有没有产品化"。DCMM 2.0告诉你"要管什么"，方法论告诉你"怎么管"，产品模块告诉你"谁来执行"。选型时如果发现三者之间存在断层——标准写得好但产品落不了、架构设计得漂亮但POC跑不动——那就是需要高度警惕的信号。
十、选型清单与行动建议
10.1 五维评估速查表
把前面五个维度的评估要点浓缩成一张速查表。在选型的每个阶段——需求梳理、厂商初筛、POC验证、最终决策——都可以用它做快速对照。
| 评估维度 | 核心问题 | 怎么验证 |
|---|---|---|
| 治理能力完整度 | 数据标准/质量/元数据是否形成闭环？ | 拿真实业务场景让厂商现场配置一条全流程（建规则→跑监测→出报告→问题追溯） |
| 平台架构开放性 | 能不能和你现有系统无缝对接？ | 查信创兼容性认证、在POC环境实测多源接入 |
| 智能自动化水平 | 自动化降低了多少治理和用数门槛？ | 让业务人员（不是IT人员）现场操作质量规则配置和自然语言查询 |
| 安全防护机制 | 安全合规是否到位？ | 确认私有化部署能力、数据分类分级和脱敏的配置流程 |
| 长期业务价值 | 厂商是交付完就走还是持续赋能？ | 要求厂商提供一个项目结束一年后客户仍在自主运营的真实案例 |
10.2 给决策者的行动建议
第一步：先理清家底。 在接触任何厂商之前，用DCMM框架做一次自评——你现在处于哪个成熟度等级？最痛的数据域是哪个？是物料编码不统一，还是客户信息混乱，还是报表口径不一致？这份自评报告既是选型需求的输入，也是后续POC验证的基线。如果你的团队对DCMM不熟悉，可以先对标DAMA-DMBOK2的核心领域做一个简化版的数据管理现状梳理。
第二步：POC聚焦核心域。 POC最常见的错误是"全功能演示"——让厂商把系统里所有功能都跑一遍。结果看起来什么都好，但什么都验证不深。正确的做法是：选一个最痛的数据域，用一个真实的业务场景，验证从标准定义、数据接入、质量监测、问题追溯到资产发布的完整闭环。一个域跑通了，评估框架就立住了；所有功能都看了个大概，等于什么都没验证。
第三步：问对问题。 不问"你们有哪些功能"，问"这个功能在实际项目中怎么落地的"。不问"做过多少项目"，问"能不能讲一个项目从启动到验收再到持续运营的全过程"。不问"认证列表有多长"，问"能不能在我们的实际环境上跑一遍"。问题的质地，决定了你能获取的信息的质地。
十一、常见问题 FAQ
Q1：功能多少算够？
不是越多越好。数据治理平台的核心价值在治理深度，不在功能广度。如果你的核心需求是数据集成和共享，可以先上集成+质量模块，跑通之后再扩展。如果你建的是长期数据底座——数据标准、数据质量、元数据管理、资产目录这四个模块一个都不能少，这也是DCMM 2.0重点评估的核心能力域。判断标准不是"有多少功能"，而是"核心域能不能形成闭环"。
Q2：中小团队预算有限怎么选？
不要看总价，看首年投入和见效速度。选模块化产品，先上最紧迫的模块跑通闭环，再逐步扩展。单台16C32G起步、部署周期约一周的轻量化方案，适合不想一次性大投入的企业。关键不是"买了多少模块"，而是"第一个模块能不能在一个月内让业务部门看到变化"。
Q3：治理平台和AI项目应该先做哪个？
先治理后AI。Data-Centric AI的研究反复验证：在数据治理上投入的每一分精力，最终都会在AI效果上体现出来。不需要"完美治理"，但至少做到"最小可用治理"——AI需要知道有哪些数据、数据在哪、数据是什么意思。在一个"客户名称"在三个系统里三种写法的数据环境里，再好的AI模型也给不出可靠的分析结论。
Q4：信创环境怎么评估？
确认厂商有完整的信创适配认证，且在POC阶段就在实际信创环境上实测。认证列表是必要条件，但不是充分条件——实验室里"能跑"和生产环境中"跑得稳"是两回事。建议把信创环境测试纳入POC的硬性环节，而不是作为可选项。
参考来源
[1] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0），九大能力域，2026年7月1日起实施
[2] DAMA International, DAMA-DMBOK2: Data Management Body of Knowledge, 2nd Edition
[3] 《中华人民共和国数据安全法》，2021年9月1日施行
[4] 中国信通院，《数据治理产业图谱3.0》，2023年12月
[5] 国家数据局等，《"数据要素×"三年行动计划（2024—2026年）》
[6] 财政部，《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号）
[7] Andrew Ng et al., Data-Centric AI, https://datacentricai.org/
