某制造企业投入数百万建设数据中台。ERP、MES、CRM全接进来了，数仓建了，BI也跑起来了。半年后项目复盘，业务部门的使用数据让所有人沉默了——日均活跃用户不到5个。 调查发现不是技术问题。业务人员说得很直接："同一个客户在三个报表里三个名字，我信哪个？"数据质量问题没有人在入职时就被告知要负责，编码标准没有人在项目启动时参与制定。项目验收了，问题留下了。最终业务部门回归Excel——至少自己填的数自己信。 很多中台项目的失败不是发生在建设阶段，而是发生在上线之后——没有治理的数据平台，和没建之前唯一的区别是：以前数据散在各系统里，现在散在一个更大的系统里。 为什么很多中台项目都卡在这五个地方 复盘下来，大多数项目出问题不是因为技术架构不行，而是五件事没做透。这五件事恰好对应DAMA-DMBOK知识体系（共11个知识领域，详见DAMA International《DAMA-DMBOK 2.0》）中数据中台建设最易出现短板的五个领域： 关键环节 对应DAMA领域 没做透的表现 数据模型没人维护 数据架构 模型在PPT里，实际跑的还是老结构 编码规则没人统一 主数据管理 同一物料三个系统三种叫法 数据问题没人跟进 数据质量 规则配了几十条，告警没人处理 数据资产没人编目 元数据管理 业务想查数，得在群里@IT"帮我找一下" 系统接口没人对口径 数据集成 这边传过去了，那边说格式不对 DAMA把这五个领域系统化为知识框架，不是让你背下来去考试，是让你在项目启动前就知道——这些坑你不填，后面一定踩。 理采存管用 × DAMA：知识框架如何工程化 很多企业理解DAMA时关注的是知识体系，理解数据中台时关注的是技术平台。但项目现场真正需要回答的是：数据应该怎么建设？治理应该如何落地？ 龙石数据在大量政企项目实践中发现，DAMA解决的是能力框架问题——告诉你"该管什么"；理采存管用解决的是工程路径问题——告诉你"怎么管"。两者是地图和施工图的关系。 理采存管用 对应DAMA领域 中台动作 理 数据战略→数据架构 摸家底、建体系、定蓝图 采 数据架构→数据集成 打通系统、汇聚数据 存 数据架构→数据标准 标准化模型、统一口径 管 数据治理/标准/质量/主数据 元数据+标准落标+质量监控 用 数据应用 资产目录、数据服务、分析报表 真正决定项目成败的往往不是技术选型，而是建设顺序。先治理体系后技术平台，先价值验证后规模推广，先解决业务问题再扩展技术能力——这套思路龙石总结为"理采存管用"建设路径。 四个领域的工程落地 数据架构：模型不在PPT里，要在系统里跑。 某211大学原来的数据模型只存在架构师的文档里，没有人按分层存数据。龙石团队把模型直接落地为ODS-DW-ADS分层架构——模型从设计文档变成运行实体。同步建设数据探查编目系统与数据超市，跨部门数据申请从"天/周级"变成"分钟级"在线自助获取，实现"一站式"数据服务。 主数据管理：同一个东西不能有三种名字。 江苏某建筑装饰集团200余家子公司，同一材料苏州叫"大理石A级"，南京叫"A类石材"。围绕物料、供应商、项目建立黄金记录后，跨公司对账从5天缩到1天，数据纠纷减少80%，项目平均工期缩短10%。客户反馈："以前经营分析会数据全靠各分公司人工报送，真假难辨且滞后严重。现在坐在总部就能看清全国上百个项目的实时成本与合规情况。" 数据质量：配了规则不等于解决了问题。 很多企业质量规则配了几十条，告警堆在那里没人处理。问题不在规则不够，在缺少"发现→定位→修复→验证"的闭环。上海某大型化工企业通过数据中台建设统一物料编码、打通OT与IT数据后，库存周转率提升28%，订单交付及时率提升至91%，报表出具周期提前4天。同步成立数据管理部，将数据治理纳入绩效考核体系，实现从"项目驱动"向"机制驱动"的转变。 元数据管理：别让IT变成人肉数据目录。 化工企业的生产主任从来不看中台——一堆技术表名根本不知道代表什么。龙石通过自动采集+血缘解析形成全企业数据地图后，业务人员在资产门户自己检索，IT团队的数据答疑工作量显著下降。 常见问题 Q：不学DAMA能建好中台吗？ 能建，但大概率漏掉关键能力域。DAMA是数据管理的"全景地图"，不看地图也能走，容易迷路。 Q：为什么懂DAMA的项目更容易成功？ DAMA本质上在回答三个问题：数据归谁负责、按照什么标准管理、出了问题上谁解决。很多中台项目失败不是缺技术，是缺这三个答案。技术平台解决流动问题，治理解决可信问题，两者结合数据才转化为业务价值。 Q：理采存管用和DAMA冲突吗？ 不冲突。DAMA是知识框架，理采存管用是工程路径。一个是地图，一个是施工图。 Q：DCMM和DAMA是什么关系？ DCMM（GB/T 36073-2018《数据管理能力成熟度评估模型》，2025版DCMM 2.0将于2026年7月施行）是中国在数据管理领域首个国家标准，划分八大能力域（数据战略/治理/架构/标准/质量/安全/应用/生存周期）和五级成熟度（初始→受管理→稳健→量化管理→优化级）；DAMA是国际数据管理协会发布的《DAMA-DMBOK数据管理知识体系指南》（最新为2.0修订版，共11个知识领域）。DCMM评估"你做到了什么程度"，DAMA回答"你应该做什么"。 企业建数据中台，真正需要回答的不是"用什么技术栈"，而是"数据管理能力建设到了什么程度"。DAMA-DMBOK给出了全景地图（11个知识领域），DCMM（GB/T 36073-2018）给出了评估标准（八大能力域、五级成熟度），龙石数据理采存管用给出了工程落地路径。地图决定方向，标准决定高度，路径决定结果。 参考资料： 1.DAMA International. DAMA-DMBOK: Data Management Body of Knowledge (2nd Edition, Revised). 11个知识领域涵盖数据治理、数据架构、数据建模与设计、数据存储与操作、数据安全、数据集成与互操作、文档与内容管理、参考数据与主数据、数据仓库与商务智能、元数据管理、数据质量。 2.GB/T 36073-2018《数据管理能力成熟度评估模型》（DCMM），我国首个数据管理领域国家标准，八大能力域、五级成熟度。DCMM 2.0（GB/T 36073-2025）将于2026年7月1日起施行，能力域扩展至九个。 3.案例数据来源：龙石数据官网案例库（longshidata.com/cases），含上海某大型化工企业、江苏某建筑装饰集团、江苏某211大学等真实项目数据。

中台不是数字化建设的终点。它是企业从有数据走向用数据的起点。

"中台项目投了 500 万，ROI 在哪？" 这是今年被问到最多的问题。Gartner 的数据更让人睡不着：超过 60% 的数据中台项目未能达到预期目标[1]。数据接进来了、大屏跑起来了、报表也出了。但老板问一句"值不值"，CDO 回答不上来。 不是项目没做，是做了没算账。投入产出比低，本质是四个核心痛点没解决。龙石数据在服务政企客户的过程中，反复验证了这四个痛点的杀伤力——以及解法。 痛点一：数据质量不敢用。 低质量数据每年给企业造成平均 1290 万美元的损失[2]。这不是技术问题，是财务问题。数据接进来了，但业务部门打开一看——手机号是空的、客户名三种写法、同一个指标三个口径。谁敢用？ 龙石在某化工企业的项目里，上线第一步就是建立质量监测机制。在集成环节配置完整性检查和准确性校验规则，数据入库时自动校验，不合规的打回源系统修正。项目上线后，核心数据的质量合规率从不到 60% 提升到 95% 以上。质量有保障了，业务部门才敢把数据用到经营分析里。 痛点二：业务部门不买账。 Gartner 预测，到 2027 年，80% 的数据治理项目将因缺乏业务驱动力而失败[3]。中台做了大半年，业务部门还是自己导出 Excel——不是平台不好用，是他们根本不知道平台能帮他们做什么。 龙石的做法不是在项目初期要求业务部门"配合治理",而是先帮他们解决一个具体的痛点。某建筑装饰集团的 CDO 在龙石建议下，成立数据治理委员会，由业务副总裁挂帅、IT 负责执行。先把采购、库存两个核心域的治理做透，业务部门第一周就看到了准确的数据报表。半年后平台使用率翻了三倍。 痛点三：建设周期太长不出成果。 动辄 12-18 个月的交付周期，半年不出成果老板就没了耐心。很多团队一上来就想覆盖所有系统，越做越大、越做越慢。艾瑞咨询的数据中台行业报告指出，"重投入、低成效"是行业核心困境[4]。 龙石的方法是"理采存管用"闭环推进——不串行等待，而是选一个核心业务域快速打透。理完资产就能看目录，采完数据就能出报表，管好质量就能建立信任。某 211 大学按这个节奏推进，教务和学生两个域 3 个月就看到效果——跨部门数据申请从"天/周级"缩短到"分钟级"。 痛点四：价值无法量化。 "提升了数据能力""支撑了数字化转型"——这些目标无法验证。没有一个业务数字是因为中台改善的，中台就永远是成本项。信通院的研究表明，数字化投入每提升 1%，成本费用利润率提高 6.71%[5]——但前提是"业务真正在用"。 龙石在项目中从第一天就建立价值锚点：不是汇报接了多少系统、建了多少模型，而是汇报"客户响应速度提升了多少""人工对账时间缩短了多久""库存周转加快了几天"。上海市某化工企业的预测性维护项目，把设备运行数据和工艺参数结合后，非计划停机减少了 37%——这个数字，老板听懂了。 四个痛点的根因是同一个：中台建成 ≠ 价值实现。 但为什么有些中台项目能做出 ROI，有些做不出来？差距不在产品功能上——数据集成、数据治理、数据质量这些模块，主流中台厂商基本都有。真正的差距在建设方法和运营思路上。 第一，理采存管用不是产品模块划分，是价值落地路径。 很多团队把中台建设理解成"先理完、再采完、再存完"的串行工程，等所有步骤走完才让业务部门用。但龙石在大量项目中验证的经验是：理采存管用应该是一个闭环——每个阶段都有业务产出。理完一个核心域，业务人员就能通过资产目录看到自己有什么数据；采完第一批高价值系统，就能出第一张业务报表；管好一个核心指标的质量，业务部门就开始建立信任。 企业不需要等项目全部结束才能看到成果。每完成一个阶段就产生一次业务价值——这是 ROI 提升的关键。 第二，中台项目的问题往往不是不会建设，而是不会运营。 很多中台上线之后就没有然后了——元数据没人维护了、质量标准没人更新了、业务部门的问题没人响应了。龙石的答案是能力转移：项目交付不是终点，而是客户自主运营的起点。 具体做法是三层培训和三步陪跑。理论培训帮团队建立 DCMM、DAMA 等标准的共同语言；实施培训让团队掌握项目推进和持续运营的方法；实战培训手把手带团队完成全流程实操。陪跑阶段从集中培训到样板工程建设再到远程技术支撑——不是替客户做治理，而是帮客户建立自己持续做治理的能力。项目结束后，客户团队能自主推进数据标准迭代、质量规则优化和资产目录更新。 第三，让业务部门主动用起来，比任何技术指标都重要。 龙石项目的价值衡量标准不是接了多少系统、建了多少模型，而是业务部门是否在主动使用数据、是否有业务指标因为中台而改善。数据质量合规率、业务自助申请率、核心指标修复周期——这些才是真正该看的数字。当客户能说出"这个数据帮我们减少了几天对账时间""那个指标帮我们提前发现了供应链风险"，ROI 就不再是 PPT 上的估算，而是每个季度都能回顾的真实成果。 常见问题 Q：中台 ROI 怎么算？ 不要追求精确的财务数字。先找一个业务域，看中台带来的改变能不能用业务指标描述——时间缩短了多少、成本降低了多少。有至少一个能说的数字，ROI 就有了起点。 Q：业务部门不配合怎么办？ 不要用治理规范去要求，用业务价值去吸引。帮他们解决一个具体痛点——数据找不到、报表太慢——他们自然就来了。 Q：怎么让老板看到价值？ 不要让老板看技术指标，让老板看业务数字。建立"中台价值看板"，每月呈现数据调用量、支撑业务场景数、每个场景的可量化收益。 参考来源 [1] Gartner, "Over 100 Data, Analytics and AI Predictions Through 2030," June 2024 [2] Gartner, "Data Quality: Why It Matters and How to Achieve It," 2020 [3] Gartner, "Gartner Data & Analytics Summit 2024 — Top D&A Predictions," 2024 [4] 艾瑞咨询，《2024年中国数据中台行业研究报告》，2024年7月 [5] 中国信息通信研究院，《中国数字经济发展研究报告（2025年）》，2026年3月

DCMM 2.0 即将实施的窗口期，每一个正在建设或已经建成数据中台的企业，都值得用 DCMM 的框架重新审视自己的建设思路——你建的到底是平台，还是能力？企业未来竞争的核心，不是拥有多少数据，而是能否把数据变成持续创造价值的资产。

失败的数据中台，真正的问题往往不在技术，而在于它们从来没有真正进入过业务流程。数据只有被使用，才能产生价值；价值被验证，才能形成投入；持续投入，才能形成能力。数据中台最终比拼的，不是谁接入的系统更多，而是谁更快把数据转化成业务成果。

数据要素市场化只是起点。谁能率先建立资源化→资产化→价值化的闭环，谁就更有机会把数据真正转化为生产力。数据中台不再只是技术平台——它是企业数据资产运营体系的核心基础设施。

市场部要拉一份客户画像，用来做下周的精准营销。数据中台已经接入了 CRM、ERP 和客服系统，按理说拖几个字段就能出结果。分析同事在 BI 里配好筛选条件，点下查询，出来的结果让人心里一凉： 客户姓名一列，1,200 行是空的 手机号 4,000 多条缺失，800 多条明显是错的（8 位、12 位都有） 性别字段里出现了"M""F""男""女""未知""0"——六种写法，根本没法分组统计 数据接进来了，流转也正常，但问题是——数据本身是脏的，下游谁敢用？ 这不是个别现象。很多团队建数据中台，精力全花在"能不能接进来"和"能不能跑通"，很少有人关注"接进来的数据对不对"。等到业务部门真要用的时候，才发现数据只能看、不能用。 为什么传统质检方式不够用 常见的做法是两种。 第一种，强校验。 在数据入库前做检查，不合格就拦截。逻辑上没问题，但实际项目里风险很大：一条字段格式的规则配错了，可能把整个管道卡住。凌晨三点的 ETL 任务如果因为一个质量规则报错而中断，运维会被电话叫醒——而且大概率是误报。 第二种，旁路监测。 数据正常同步，质量检查并行运行。发现问题后单独记录到问题库，不阻塞主链路。你可以在白天慢慢修复，不影响任何生产流程。 多数项目里，旁路监测比强校验更实际——这也符合 DAMA 数据管理知识体系中"数据质量管理应优先保障业务连续性"的原则。龙石数据中台的质量管理模块就是这么干的——用"评测模型"管规则，支持 MySQL、Oracle 到 Doris、GaussDB 等一堆数据库，配规则不用写 SQL。作为 DAMA 大中华区实训基地和信通院《数据治理产业图谱 3.0》入选厂商，龙石在这个领域已经有多个项目验证。 上手配置：从零搭建一条质量监控链路 拿最常见的客户基础信息表来跑一遍。customer_info 每天从 CRM 增量同步，要盯三件事：姓名和电话不能空、手机号格式得对、性别代码得在标准字典里。 第一步：创建评测模型 评测模型就是按业务域把规则分组——客户域一个模型、产品域一个、订单域一个。进入「数据质量 → 评测模型管理」，点击新增，填写模型名称"客户信息质量评测"，选择评测数据库为治理库（DW），保存。 第二步：添加评测对象 在模型详情页点击新增评测对象，选择 customer_info 表。如果表没有物理主键，需要指定一个逻辑主键来唯一标识每行数据，方便后续问题追溯。 第三步：配置完整性检查 最常见的问题是字段为空，比如客户姓名和电话缺失。新增一条「空值检查」规则： 配置项 填写 规则名称 客户姓名与电话非空检查 检查字段 customer_name，phone 检查方式 每个字段都不能为空 规则权重 高 错误描述 客户姓名或电话存在空值，影响标签生成和营销触达 修复建议 核对 CRM 客户基础信息是否完整录入 第四步：配置准确性检查 字段有值不代表值是对的——手机号是 11 位的吗？年龄在合理范围内吗？性别代码是标准值吗？ 格式规范性检查（手机号格式）： 规则类型选「格式规范性检查」，检查字段选 phone，EL 表达式写 #phone REGEXP '^1[3-9][0-9]{9}$'。不符合 11 位手机号格式的，自动标记。 值域检查（年龄范围）： 规则类型选「值域检查」，检查字段选 age，值域范围设为介于 0 和 120。超出这个区间的数据会被捕获。 引用完整性检查（性别代码标准化）： 规则类型选「引用完整性检查」，检查字段选 gender。前提是数据标准模块里已经定义了"性别代码"字典表（M=男/F=女），质检规则直接引用标准定义，不需要重复维护值域。标准改了，规则自动同步。 第五步：创建评测任务 规则配好后，需要建一个评测任务来触发执行。进入「评测任务管理」，选择"客户信息质量评测"模型。首次建议用"手工触发"先跑通验证，确认规则无误后再改为定时策略——比如每天早上 6 点自动跑。 第六步：看结果 任务执行完成后，进入「问题数据查看」。首次扫描 86 万条客户数据，通常能看到类似这样的结果： 问题类型 数量 占比 手机号缺失 4,200 条 0.49% 客户名称缺失 1,200 条 0.14% 手机号格式异常 800 条 0.09% 性别编码不在标准范围 3,500 条 0.41% 合计问题率 1.03% 每条问题都能点开看详情——哪个字段、违了什么规则、当前是啥值、什么时间发现的。修好之后下次跑评测，问题状态自己就关了。 项目里最容易踩的 4 个坑 坑一：规则越多越好。 不是。第一次做数据质量的团队，上来就配几十条规则，觉得覆盖面越广越好。结果每天几千条告警涌进来，没人看得完，也没人处理。两周之后，所有人把告警通知关了。正确做法：从一个核心业务域开始，先配 3-5 条高价值规则，等团队习惯了处理节奏，再逐批加。规则不在多，在有人盯。 坑二：把低价值字段当核心字段。 手机号缺失，值得告警——影响短信触达。备注字段为空，不值得——本来就可空。但很多项目里两者权重设成一样，重要问题淹没在一堆"备注为空"里。区分方法很简单：问自己"这个字段如果错了，下游哪个业务会受影响？"答不上来的，就设低权重或者不配。 坑三：一上来就设定时任务。 评测任务刚建好就设定时，凌晨自动跑——听起来很规范。现实是：第一条规则配错了，半夜产生几千条误报，没人发现，第二天打开系统直接懵了。正确做法：先手工触发跑一次，对着问题清单一条条确认"这是真问题还是误报"，确认规则没问题了，再切定时策略。 坑四：错误描述技术部门都看不懂。 见过一个真实案例：规则错误描述写的是"phone 字段不满足 EL 表达式 REGEXP"。业务部门看不懂，技术部门看不出业务影响，这条告警在两个部门之间转了三天没人认领。错误描述应该回答三个问题：什么问题（业务语言）、影响什么（下游场景）、怎么修（可操作的步数）。比如别写"gender 不在值域范围"，写"性别字段存在非标准值，影响客户画像分组统计，请在数据标准模块确认标准字典后批量修正"。 真正难的不是发现问题，是把问题推回去 项目做久了会发现一个规律：大部分质量问题并不是系统故障造成的，而是业务过程产生的。客服录入时图省事，手机号随便填。老系统迁移时历史数据没清洗，脏数据原封不动搬过来。ERP 和 CRM 对"客户类型"各有各的编码规则，合到一起全乱了。质量规则能扫描出来的，只是冰山浮在水面上的部分。 更棘手的是：你标记了 4,000 条手机号缺失，谁来补？客服部说"这是历史数据，不是我录的"，IT 说"数据已经同步完了，源系统不改我们也没办法"。一圈下来，问题清单躺了一个月没人动。 所以旁路监测真正的价值，不是发现问题——发现很容易，配几条规则就够了。真正的价值是给一个持续推动的抓手：每周把问题清单按来源系统分类，谁产生的谁认领。一次不行两次，两次不行拉上业务负责人一起看数据。质量管理要解决的不是一次性清洗，而是让问题回到业务源头的能力。 常见问题 Q1：旁路监测会影响数据同步性能吗？ 一般不会。质量评测是数据同步完之后另外跑的，跟主链路不打架。头一回跑的时候留意下耗时，千万级往上的大表可以用分区评测或者增量评测，别一次扫全表。 Q2：发现问题数据后，系统会自动修复吗？ 不会。质量管理的任务是发现问题和推动治理，不是直接改业务数据。问题数据进问题库，标清楚哪条记录、谁负责、怎么修。等业务侧改好了，系统会自动把这条问题关掉。 Q3：什么时候用旁路监测，什么时候用强校验？ 不冲突。身份证号、统一社会信用代码这种核心交易数据，强校验合适。客户信息、设备信息、业务标签这些，用旁路监测更稳——别因为几条破数据把整个流程卡了。 Q4：质量规则应该一次性全部配完吗？ 别。先盯核心字段，把 80% 的高价值问题干掉，跑顺了再慢慢加。上来就全配，告警多到自己都不想看。 Q5：数据质量问题主要来自哪里？ 很多团队第一反应是同步任务出了问题。其实大部分质量问题是业务侧搞出来的：录入的时候图省事、老系统迁移过来的脏数据没洗、不同系统对同一个字段各有各的编码。所以数据质量治理，治的不是数据，是业务过程。 很多人以为数据质量就是上线前集中洗一轮，洗完就干净了。实际上数据质量跟产线质检差不多——每天都有新料进来，质检得一直跑着，不是搞一次就收工。 评测模型和定时任务搭好之后，每周扫一眼问题修复率就行。主要看三样：问题数是在涨还是在降、高权重问题从发现到关闭用了几天、新接的数据源有没有同步建质检规则。 说到底，数据质量不是要把所有问题都干掉——那不可能。是得有一个"一直在查、查出来有人修"的机制。旁路监测做的就是这件事。 截至 2026 年，越来越多的企业数据中台项目从"建设期"进入"运营期"，数据质量的持续管理正在成为新的焦点。

"我们选了一家厂商，演示很漂亮，功能列表拉出来两百多项。但上线半年后，业务部门还是用不起来。" 这是过去一年里，我第三次听到类似的话。说这话的是一家制造企业的 CDO，他们花了大半年选型、三个月部署，最终发现——功能都有，但业务不买账。 选型踩坑，不缺教训。缺的是一套能落地的评估框架。 一、选型前先问自己三个问题 在讨论厂商之前，先想清楚自己的需求： 你建数据中台要解决什么核心问题？ 是数据孤岛打通？是数据质量太差？还是缺少统一的数据服务层？ 你的团队能力和投入预期是什么样的？ 有没有专职的数据治理团队？预算是一次性项目还是按年持续投入？ 你的 IT 环境复杂度如何？ 涉及多少套业务系统？有没有信创要求？集团多组织还是一个单体企业？ 这三个问题不搞清楚，看再多彩页和 Demo 都没用。它们决定了你的选型侧重点——对有些企业来说，数据集成能力是第一优先级；对另一些企业来说，数据治理深度才是决定成败的关键。 DCMM 国家标准（GB/T 36073-2018）将数据管理能力划分为 8 个能力域，其中"数据战略"域明确提出组织应首先明确数据管理的目标和优先级——选型前的自我评估实质上就是在完成这一步。DAMA-DMBOK2 同样将数据管理战略列为顶层指导域，强调先定义目标再匹配工具。 二、维度一：功能——避开"大而全"的陷阱 选型时最容易犯的错，就是看功能列表长短。 功能多≠能落地 很多厂商的演示系统里什么都有：数据集成、数据开发、数据治理、BI 报表、AI 智能问数……列表能拉满三页。但真正上线后你会发现：数据质量规则要手动配置上百条，元数据采集跑一次要半天，主数据合并冲突处理逻辑想改？对不起，那是标准产品不支持。 选型建议：不要问"你们有哪些功能"，要问"这个功能在实际项目中怎么落地的"。 一个实用的测试方法：拿一个你真实的业务场景让厂商现场配置。比如"我们想监控 ERP 系统里物料主数据的重复率和空值率，能不能现在演示一下从建规则到出报告的全流程？" 核心能力应该关注什么 数据治理是数据中台区别于传统数据仓库的核心。一个中台选得好不好，最终要看数据是否"好管好用"。以下是几个必须深挖的点： 数据标准管理：能不能定义字段级的业务标准和校验规则？还是只支持简单的元数据描述？ 数据质量管理：质量规则是只能技术配置，还是支持业务人员参与？能不能做旁路监测（不影响业务系统运行）？错误数据能不能追溯到源头？ 元数据与血缘：元数据采集是全自动的还是需要大量手工录入？血缘分析能不能跨系统追踪？ 这些能力直接决定了中台能不能从"工具"变成"底座"。DAMA-DMBOK2 将数据质量、元数据、主数据列为数据管理的核心领域——质量应覆盖"定义、测量、分析和改进"四个环节，元数据应支持全生命周期管理。DCMM 同样要求质量问题追溯到源头。 另外，数据资产目录虽然属于"用"的环节，但在选型时也值得一并考察：资源目录能不能让业务人员自助找数、申请用数？还是只是一个 IT 人员看的列表？这直接关系到中台上线后业务部门能不能真正用起来。 以实际项目验证过的方法论为参照——龙石数据中台基于"理采存管用"框架，把数据治理能力拆解为标准管理、质量监测、元数据与血缘、资产目录等可独立使用的模块。这种模块化设计让企业可以按需选择，不用一开始就为用不到的功能买单。 怎么测：选型时别光听讲 PPT，让厂商在你的实际业务场景里配一个质量规则全流程——从建规则、跑监测、出报告到问题数据追溯——能不能半小时内搞定？比如可以先上数据质量旁路监测，看到效果再逐步扩展。 一个典型的教训：某中型汽车零部件企业（年营收约 15 亿）被某厂商的"一站式 AI 数据平台"吸引，合同金额超过 200 万。部署后三个月内，数据质量模块仅配置了不到 20% 的规则——因为大量规则需要手工梳理业务逻辑，而团队根本没有专职数据治理人员。最终该企业转向模块化方案：先上数据集成+质量旁路监测，两月内数据问题率从 18% 降到 5% 以下，再逐步扩展。这个案例说明一个朴素道理：功能广度在团队能力不足时不是优势，而是负债。 三、维度二：架构——兼容集成，避免技术锁定 和现有系统的关系 选型不只是选一个产品，是选一个未来几年的技术伙伴。核心问题是：这个中台能不能和你们已有的系统和平共处？ 数据库兼容：支持哪些数据库？信创环境适配了吗？（达梦、人大金仓、海量数据等） 集成方式：多源异构数据接入是通过标准接口还是私有协议？能不能对接已有的 ETL 工具（如 DataX、Kettle）？ 部署模式：支持私有化部署吗？支持混合云吗？ 架构的扩展性 今天是三个业务系统接入，明年可能是十个。今天是单体企业用一个实例，后年可能是集团管控需要分权分域。 一个好的选型判断标准：工作空间模型。龙石数据中台的"一集团一中台、一公司一空间"架构，就是一种典型的可分可合的架构设计——总部统一标准和安全管控，子公司或部门在独立工作空间内自治，既保证了一致性又兼顾了灵活性。 信通院《数据治理产业图谱 3.0》指出，头部厂商正从"单一产品"向"平台化、组件化、可组装"方向演进。国家数据局"数据要素×"三年行动计划明确要求推动数据跨部门、跨层级、跨区域流通——这意味着中台架构必须具备分权分域和跨组织协同能力。 一个选型中的实战经验：某省级城投集团（下辖 12 家子公司，业务涵盖地产、水务、交通）在选型时，核心痛点是"总部要统一管，但子公司各自有自己的业务节奏"。他们确定了一个硬性评估标准：验证厂商的工作空间模型能否在总部统一标准的同时，允许子公司独立管理自己的数据资产目录和权限。经过 POC，他们淘汰了三家只能做单体部署的厂商。这个选择让后续推广从"总部推不动"变成了"子公司主动接入"。 四、维度三：服务——不只是一次性交付 数据中台不是买个软件装上就完了。它涉及组织变革、流程重构、团队能力建设，是一个持续运营的过程。 交付≠完成 很多厂商签完合同、部署上线后就转为被动支持模式——有问题你找我，没问题我就等着。但数据中台的真正价值是在持续运营中释放的。 要问的问题： 部署完成后，厂商会参与运营吗？还是只是远程支持？ 有没有定期的巡检和健康度评估？ 如果业务需求变了，能不能快速调整配置而不是等版本升级？ 让团队真正用起来 中台最终是要交给你自己的团队来运营的。如果厂商的交付方式是"我们帮你把系统建好，然后你自己摸索"，那大概率用不了多久就会回到原样。 一个务实的判断标准：厂商有没有成熟的培训+陪跑机制？ 龙石数据的"产品+培训+陪跑"模式是一个参考标杆——理论培训（DCMM/DAMA/方法论）让团队知道"为什么做"；实施培训让团队知道"怎么做"；实战陪跑让团队在真实项目中"动手做"。这种三级培训+实战体系确保企业在项目完成后，具备独立的数据治理能力，而不是永久依赖厂商驻场。 新疆某热力公司的案例就很有代表性。 这家企业承担着全市集中供热业务，长期以来，SCADA、收费、GIS 等系统各自独立运行，数据标准不统一，地址信息缺乏规范，基层人员经常需要重复录入同样的数据。 在建设数据中台的过程中，龙石团队并没有把工作停留在平台交付层面，而是同步推进数据管理能力建设。围绕理论、实施、实战三个阶段，通过系统化培训帮助信息部门建立对 DCMM、DAMA 以及"理采存管用"方法论的整体认知；结合实际业务场景，指导团队配置数据标准、数据质量规则和管理流程；并以真实业务问题为切入点，带领客户完整走通数据治理实践。 项目建设完成后，龙石团队继续通过陪跑服务，指导客户团队独立开展数据治理工作，逐步将项目成果转化为组织能力。 如今，热力公司已经组建起自己的数据管理团队，并将相关机制持续运营至今。回顾这段经历，客户曾这样总结： "以前这些系统更像是各自运转的孤岛，现在不仅连起来了，我们也知道该怎么管理、怎么维护、怎么持续优化了。" 这样的变化，不只是多了一个数据平台，更重要的是企业逐步建立起了自主开展数据管理和持续运营的能力。 DCMM 在多个能力域中强调，数据管理能力的提升需要组织文化、人员技能和流程机制的综合配套——仅靠工具无法实现成熟度的跃升。DAMA-DMBOK2 同样指出，数据管理的成功依赖于"人员、流程和技术的协同"，技术只是三个支柱之一。 五、选型清单：一张表帮你理清思路 评估维度 核心问题 怎么看 功能深度 数据治理能力是否扎实？（标准/质量/元数据/资产目录） 用真实业务场景验证，不看功能列表 架构兼容 能不能和你现有系统无缝对接？信创适配？ 查兼容性认证、看是否支持标准接口 扩展性 能不能从部门级扩展到集团级？ 看工作空间模型和多租户支持 服务模式 厂商是卖完就走还是持续陪跑？ 看有没有培训+陪跑体系 案例验证 同行业有没有真实落地案例？ 不问"做过多少"，问"能不能讲一个真实过程" 六、常见问题 Q1：功能多少算够？ 不是越多越好。一个数据中台的核心价值在于数据治理深度，而不是功能广度。如果你主要用数据集成和 BI 报表，那很多治理类模块可以先不上。但如果你要建的是长期数据底座，标准、质量、主数据、元数据这四个模块一个都不能少——这也是 DCMM 重点评估的核心能力域。 Q2：开源的能用吗？ 看团队能力。如果你们有 5 人以上的专职数据工程团队、愿意花半年以上做二次开发和集成，开源方案可以探索。但如果团队以业务人员为主、希望尽快看到效果，建议选商用的——省下的不是 license 费，是时间成本和试错成本。 Q3：中小企业预算有限怎么选？ 不要看总价，看首年投入和见效速度。选一个模块化的产品，先上最紧迫的模块（比如数据集成 + 质量），跑通之后再逐步扩展。龙石数据中台的特点是所有功能模块可独立部署、按需装配，单台 16C32G 就能起步，部署周期约一周。这种轻量化启动模式适合不想一次性大投入的企业。 Q4：信创环境怎么选？ 必须确认厂商有没有完整的信创适配认证。龙石数据中台已完成麒麟、统信、达梦、人大金仓、OceanBase、华为等主流信创产品的兼容性认证。不过认证列表长不代表适配好——最好在 POC 阶段就在你的实际信创环境上跑一跑。 参考来源 [1] DAMA International，《DAMA-DMBOK2: Data Management Body of Knowledge》 [2] GB/T 36073-2018《数据管理能力成熟度评估模型（DCMM）》 [3] 中国信通院，《数据治理产业图谱 3.0》（2023年12月） [4] 国家数据局等，《"数据要素×"三年行动计划（2024—2026年）》 [5] Gartner，《Market Guide for Data Management Solutions》 [6] 国务院，《"十四五"数字经济发展规划》《数字中国建设整体布局规划》

早上八点，无锡一家自动化控制企业的生产调度打开微信，消息已经攒了十几条。 "昨晚客户又改交期了，这个订单得插进来。" "BOM 还得再调一下，采购那边到货也晚了三天。" "机加工那台设备又停了，不知道什么时候能修好。" 这家企业是国内工业自动化控制阀领域的头部企业，产品覆盖石油化工、电力、冶金等行业，多个生产基地年产控制阀数十万台，客户遍布国内外大型工业集团。但规模越大，数据的"散"和"变"就越突出——订单、设计、物料、设备状态每时每刻都在变化，信息却散落在 ERP、PLM、MES 和一堆纸质流转单里。 项目启动初期，龙石顾问团队对企业的 ERP、PLM、MES、SCADA 等核心系统进行了全面调研，发现了一个典型的离散制造困局： 很多制造企业认为自己缺的是 MES，但实际上在服务离散制造客户时发现：企业最大的瓶颈往往不是系统数量不足，而是订单、工艺、设备、质量数据无法形成统一链路。尤其在按单设计、多品种小批量的模式下——订单变更会影响 BOM，BOM 变化会影响采购，采购延迟会影响排产，设备停机会影响交付。如果这些数据分散在多个系统中，管理层几乎不可能实时掌握真实情况。 当管理层想回答"某个订单现在做到哪了""为什么这个批次老出问题""那台设备到底停了多少次"时，往往要等半天甚至几天。 这不是个案。离散制造企业的数据之困，几乎都集中在四个环节。 一、四个痛点：看得见的效率损耗 计划排产难。 销售订单频繁变更交期，设计 BOM 常需修改，采购到货不准时，车间设备突发故障——任何一个环节的变动都会打乱生产计划。排产结果与实际执行严重脱节，准交率持续承压。 过程不透明。 一个控制阀要经过机加工、装配、测试、喷涂等多道工序，每道工序的在制品数量、进度、质量状态主要靠纸质流转单。管理层想知道"做到哪了"，半天也拿不到准确答案。 质量追溯慢。 客户投诉某批次产品存在泄漏，质量部门需要追溯该批次的原材料批次、加工设备、操作人员、检验记录。数据散落在不同工位的纸质记录和 Excel 中，追溯一次耗时数天，还容易遗漏。 设备管理弱。 车间数控机床、加工中心等设备众多，但运行状态、故障记录、OEE 等数据未系统采集。设备科只知道"坏了"，不知道"坏在哪、停了多久、根因是什么"，预防性维修无从谈起。 顾问的诊断很直接：离散制造的问题本质不是缺系统，而是缺一套实时汇聚全要素数据、自适应业务变化的数据底座。解决路径就是——理、采、存、管、用。 项目实施中最大的挑战，出人意料地不在技术上，而在"理"这个环节。 同一个零部件——比如一台控制阀的阀体——在 ERP 系统里用采购编码，在 PLM 里用设计图号，在 MES 里又有一套车间自编号。三个部门各说各话，同一个东西对不上。项目团队联合采购、设计、生产三个部门，把核心物料逐一拉出来对账：这个编码对应哪个图号、那个图号在车间叫啥名。前后花了近三周，最终统一形成了企业级主数据标准。 这正是龙石多年来坚持"产品+培训+陪跑"模式的原因——不是替客户做完就走，而是让客户自己具备持续治理的能力。 具体分两步： 第一步，培训。 在项目启动阶段，企业信息部门的核心团队集中学习，内容包括三个层次：理论层覆盖 DCMM 和 DAMA 框架，帮团队建立数据治理的整体认知；模拟层用沙盘案例演练"理采存管用"的完整流程；实操层直接在数据中台上手，从配置数据标准到跑通质量规则，把"听的"变成"会的"。 第二步，陪跑。 培训结束后，顾问进入客户现场，选一个真实业务域——比如这次的生产域——和客户团队一起跑。但跑法很明确：顾问指导，客户操作。从归集 MES 数据到配置在制品跟踪看板，每一步都是客户团队动手完成，顾问在旁边把关。目标不是"帮你把数据治好了"，而是"你们自己能治了"。 正是这套"先培训、再陪跑"的打法，让下面的落地过程不只是实施记录，而是企业自己逐步建立数据能力的过程。 二、落地：从统一主数据到三个核心应用 项目最先做的不是建模型，而是统一主数据。因为在前期调研中发现：同一个零件在设计部门、采购部门、生产部门可能对应三套不同编码。数据不统一，后面所有分析都会失真。团队带着三个部门的业务骨干，把订单、物料、BOM、工序、设备等核心主数据逐一拉通，制定了企业级的编码规范。针对离散制造"订单—工单—工序—设备—人员—物料"的六层结构，抽象出一套行业数据模型，让不同系统说起同一种"业务方言"。 主数据统一后，项目组开始打通 ERP、PLM、MES、SCADA、质量系统，将订单、BOM、工艺路线、工序报工、设备状态、质量检验等数十张核心业务表全部接入数据中台。基于六层主数据模型，围绕计划排产、在制品跟踪、质量追溯、设备 OEE 四个主题构建了关联模型——通过统一的订单号、物料编码、设备编号，跨系统数据首次实现了按需关联。 数据接入的同时落地治理规则：物料主数据去重与合并、工序编码标准化、质量检验项字典统一。元数据自动采集和血缘分析——遵循 DAMA 数据管理知识体系（DMBOK2）的最佳实践——让数据"从哪里来、经过了什么处理"一目了然。 在此基础上，项目组交付了三个核心应用： 在制品跟踪看板：通过集成工序报工、设备状态等数据，自动计算每个订单在各工序的完成数量、在制数量、合格数量，关联工艺路线中的标准工时，自动生成订单进度看板。管理层点击任一订单，即可下钻到该订单当前所在工序、预计完成时间、已延误原因。 质量追溯查询：建立"原材料批次—加工设备—操作人员—检验记录"的关联模型。当遇到质量问题时，通过订单号自动关联出所用原材料的采购批次、各工序的加工设备与操作人员、每个检验项目的实测值。 设备 OEE 分析：通过设备运行信号与停机记录等数据，计算每台设备的 OEE（时间开动率、性能开动率、合格品率），并按故障、换型、待料等维度分类统计停机原因。设备科据此制定预防性维护计划。 三、效果：五个可量化的改变 1. 准交率：从"靠电话催"到"看屏幕知"。 项目建设前，订单进度全靠电话和微信沟通，计划调度每天花大量时间追问车间，准交率长期徘徊在 70% 左右。在制品跟踪看板上线后，管理者点击任一订单即可看到当前工序、完成进度和预计延误风险。准交率从约 70% 提升至 86%，客户投诉率下降 40%。 2. 质量追溯：从"两三天"到"几分钟"。 过去遇到客户投诉，质量部门要翻遍纸质流转单和散落的 Excel，追溯一个批次的完整记录通常需要两到三天。现在输入订单号即可一键获取原材料批次、加工设备、操作人员、检验记录的全链路数据。质量追溯从 2-3 天缩短到几分钟，一次客户审计中 1 小时内即完成全部资料导出。 3. 设备管理：从"说不清"到"可量化"。 项目前设备科只知道设备"坏了"，停机多久、根因是什么、影响了多少产出——全凭经验估算。现在 OEE 自动计算，停机原因按故障、换型、待料等维度分类统计。设备科据此制定预防性维护计划，非计划停机时间减少 35%。 4. 数据标准：从"各说各话"到"一套语言"。 项目前，同一个物料在 ERP、PLM、MES 里各有各的编码，生产、采购、财务三套口径经常对不上。现在物料编码、BOM 结构、工序名称在全公司统一，大幅消灭了"账实不符"的差异项，跨部门沟通不再需要反复核对口径。 5. 数据资产：从"散落各处"到"持续沉淀"。 项目前，订单、设备、质量等核心数据散落在各个系统中，既不可见也不可用。现在这些数据已沉淀为企业的数字化资产，成为后续推进预测性维护、智能排产等 AI 应用的基础数据底座。 四、启示：离散制造的数字化路径 这个案例的经验可以总结为三点： 治理先行，不急于上应用。 正如 DAMA 在《数据管理知识体系指南》（DMBOK2）中反复强调的：数据治理是数据价值实现的基石。先统一主数据标准、建立数据质量规则，再谈报表和分析。很多人一上来就想做大屏看板，但数据没理清楚、标准没统一，看板上的数字再漂亮也是"假数据"。 用真实场景倒逼落地。 在制品跟踪、质量追溯、设备 OEE 这三个场景不是因为"功能列表上有"，而是因为企业每天都被这三个问题困扰。用最痛的点驱动治理，比按部就班推进更有效。 六层数据模型是离散制造的关键。 "订单—工单—工序—设备—人员—物料"这套模型，把离散制造的核心要素串成了一个可计算、可追溯的数据链。这一思路与国际自动化学会（ISA）发布的 ISA-95（IEC 62264）标准不谋而合——该标准将制造企业划分为企业层、车间层、设备层等功能层次，强调各层级数据的标准化建模与互操作。不同类型的企业需要构建自己行业的数据模型——化工行业的"批次—配方—工艺参数"，建筑行业的"项目—标段—分项"——但思路是一致的。

国际数据管理协会（DAMA International）是全球最具影响力的数据管理专业组织之一。其发布的《DAMA-DMBOK（Data Management Body of Knowledge）》被广泛视为数据管理领域的基础知识体系。 DAMA 对数据管理给出了经典定义： "Data Management is the development, execution, and supervision of plans, policies, programs, and practices that deliver, control, protect, and enhance the value of data and information assets throughout their lifecycles." —— DAMA International 即 数据管理是围绕数据和信息资产全生命周期开展规划、执行和监督的一系列制度、流程与实践活动，其目标是交付、控制、保护并持续提升数据资产价值。 在此基础上，DAMA-DMBOK 将数据管理拆解为多个知识领域，覆盖治理、架构、质量、安全、元数据、主数据等核心能力，构建了一套完整的数据管理理论框架。 但在实际项目中，很多企业都会遇到同一个问题： DAMA 告诉我们应该做什么，却没有直接告诉我们应该从哪里开始，以及具体如何推进。 尤其是在数据中台建设过程中，企业真正需要的往往不是一套知识体系，而是一套能够指导项目实施的工程化方法。 经过大量项目实践可以发现，龙石数据提出的“理采存管用”方法论，恰好能够将 DAMA 的理论框架转化为可执行的落地路径。 一、DAMA 的 11 个知识领域：一张全景图 先快速过一遍 DAMA-DMBOK 的核心领域，为后续的映射做铺垫： 领域 核心关切 在中台建设中的含义 数据治理 谁决策、谁负责、制度怎么定 治理组织和制度建设 数据架构 数据怎么组织、怎么流动 数据模型和集成架构设计 数据建模与设计 概念模型、逻辑模型、物理模型 数仓分层和模型设计 数据存储与操作 数据存在哪、怎么管 存储选型和运维 数据安全 谁能看、谁能改 权限和脱敏 数据集成与互操作 不同系统的数据怎么通 多源异构数据汇聚 文档与内容管理 非结构化数据怎么管 文档和知识库 参考数据与主数据 核心实体的统一编码 主数据管理 数据仓库与 BI 分析怎么支持 报表和可视化 元数据管理 数据从哪来、什么意思 元数据采集和血缘 数据质量 数据准不准、全不全 质量规则和监控 从内容覆盖范围来看，DAMA 已经回答了企业数据管理“应该建设哪些能力”的问题。 但对于很多企业而言，更现实的问题是： 这些能力应该如何组织？ 哪些先做？ 哪些后做？ 如何形成建设闭环？ 二、DAMA 与 DCMM：国际理论与中国标准 在国内数据治理领域，除了 DAMA，还有一个经常被提及的标准——DCMM。 DCMM（Data Management Capability Maturity Model）即《数据管理能力成熟度评估模型》，是我国首个数据管理领域国家标准（GB/T 36073-2018）。 注：DCMM 2.0（GB/T 36073-2025）已正式发布，将于 2026 年 7 月 1 日起实施。相较 1.0 版本，能力域从 8 个扩展为 9 个，新增"数据资产"能力域。本文以现行 GB/T 36073-2018 为基础论述，实际引用时建议参考 2.0 版本。 标准指出： “帮助组织运用先进的数据管理理念和方法，建立和评价自身数据管理能力，持续完善数据管理组织、程序和制度，充分发挥数据在促进组织战略达成方面的价值。” DCMM 将数据管理能力划分为八大能力域： 数据战略 数据治理 数据架构 数据标准 数据质量 数据应用 数据安全 数据生命周期 同时建立了五级成熟度评价体系： 一级：初始级 二级：受管理级 三级：稳健级 四级：量化管理级 五级：优化级 从本质上看： 体系 关注重点 DAMA 数据管理知识体系 DCMM 数据管理成熟度评价 数据中台 数据能力平台建设 理采存管用 数据治理实施路径 三者并不冲突，而是关注点不同。 DAMA 解决的是：应该建设什么能力 DCMM 解决的是：能力建设达到什么水平 而数据中台项目需要解决的是：如何把这些能力真正建设出来 三、理采存管用：DAMA 的工程化落地 如果说 DAMA 是"理论教材"，那龙石数据的"理采存管用"就是"落地手册"。 五阶方法论不是对 DAMA 的简化，而是按照工程落地顺序对 DAMA 各领域的重新编排： 可以看到，DAMA 的知识体系被系统性地分配到了五个阶段中。其中"管"阶段承载了最多的治理职能——质量、元数据、主数据、安全，多个领域在这一环节集中落地。 这不是简单的分类对应。关键在于顺序——DAMA 告诉你"要做什么"，理采存管用告诉你"先做什么、后做什么、怎么串起来"。 四、为什么顺序很重要？ 很多中台项目失败，不是因为某个领域没做，而是顺序错了。 典型错误一：在"理"之前就做"采"。 数据资产还没盘点、标准还没定、治理组织还没建，就开始写 ETL 脚本接数据。结果是接进来的数据口径不一致，后面还得返工。上海某化工企业的教训很典型——中台项目启动后直接开始接 MES 和 ERP，三个月后发现物料编码在两边完全对不上，之前的集成工作全部重来。而正确的顺序是先做"理"：统一主数据标准、建立数据质量规则，再进入采集环节。该企业调整路径后，交付及时率从不足 70% 提升到了 91%。 典型错误二：在"管"之前就做"用"。 数据标准没统一、质量没控制、元数据没采集，就开始做报表和 AI 分析。一个常见的后果是：同一个销售额，BI 页面和财务系统差了几百万，业务部门再也不敢用。 典型错误三："管"只做技术检查，不做业务治理。 DAMA 强调数据治理首先是组织治理——要有明确的权责和考核机制。如果质量规则只在技术层面跑，没有人对业务口径负责，那数据问题永远不会从源头解决。 五、AI时代，为什么更需要数据治理？ 随着大模型快速发展，越来越多企业开始建设：AI问数、AI分析助手、AI数据助手、企业知识库。但实践证明：AI效果的上限往往取决于数据质量。 近年来兴起的 Data-Centric AI 理论认为： 与持续优化模型相比，持续提升数据质量和数据治理能力，往往能够获得更大的业务收益。 原因很简单，如果指标定义不统一、主数据不统一、元数据缺失、数据质量不可控，那么AI只会把错误答案生成得更快。 因此，AI时代并没有削弱数据治理的重要性，反而进一步提高了数据治理的战略价值。对于企业而言：数据治理是AI的基础设施。 理采存管用中的"管"，本质上是在为未来的AI应用打基础。而"用"阶段中的智能问数、智能分析，则是治理成果的集中体现。 这一趋势已在政策层面得到印证。2026年，江苏省数据局统筹启动了高质量数据集建设先行先试项目，依据国家"人工智能+"部署及《江苏省发展数据标注产业建设高质量数据集实施方案（2025—2027年）》要求，全省共 147 个项目入选省级试点。龙石数据联合江苏省市场监督管理局数据中心、苏州大学共同申报的"高质量数据集智能底座"项目顺利入选平台搭建类试点——这意味着高质量数据集建设正在从政策驱动走向工程落地，而数据治理能力是这一进程的核心基础设施。 六、怎么落地？一个实操路径 结合 DAMA 框架和理采存管用方法论，建议按以下路径推进： 第一步：用 DAMA 做成熟度评估。 在启动中台建设之前，对照 DAMA 的 11 个领域做一个快速自评：哪些领域已经有基础？哪些是空白？这一步只需要一周，但能避免后面几个月的方向性错误。 第二步：用"理"阶段建治理基础。 根据评估结果，优先建立治理组织和数据标准。DAMA 讲的"数据治理"领域对应到实践，就是在这一阶段完成——明确谁对数据质量负责、统一核心主数据编码、建立变更管理流程。 第三步：采、存、管螺旋推进。 不追求一步到位。选 1-2 个高价值数据域（比如客户域、产品域），走通"采集→建模→治理"的闭环，形成可复用的模板后再扩展。 第四步："用"推动持续迭代。 治理的目的是用。把治理后的数据通过 API 共享、BI 报表或 AI 智能问数等方式推向业务端。业务使用中产生的新需求，反馈回"理"阶段，启动新一轮规划。 七、常见问题 Q1：DAMA 和 DCMM 是什么关系？ DAMA 是国际数据管理协会发布的知识体系（DMBOK），DCMM 是中国国家标准（GB/T 36073-2018）。DCMM 参考了 DAMA 的框架，但增加了成熟度等级评估（1-5 级）。两者的核心思想一致：数据治理首先是组织治理，其次才是技术治理。2026 年 7 月起 DCMM 2.0（GB/T 36073-2025）将正式实施，能力域从 8 个扩展为 9 个，新增"数据资产"能力域。 Q2：中小企业需要关注 DAMA 全部 11 个领域吗？ 不需要。建议重点关注数据治理、数据质量、主数据、元数据这四个基础领域，先把数据"管明白"再扩展。四个领域跑通后，数据仓库和 BI、数据安全的优先级自然上升。 Q3：理采存管用和 DAMA 冲突吗？ 不冲突。DAMA 是知识框架，理采存管用是工程落地方法。可以把理采存管用理解为"DAMA 的施工版"——它保留了 DAMA 的核心思想，但按照工程实践重新编排了顺序和重点。 Q4：治理能力建设需要多长时间？ 取决于起点。如果已经有一定的数据基础（系统建设、团队配置），可以在一个数据域内快速验证： 短期（3 个月）：完成一个数据域的盘点、标准和治理闭环，跑通"理→采→存→管→用"全流程，让业务看到效果 中期（6-12 个月）：将成功模式扩展到 3-5 个核心数据域，建立治理运营常态机制 长期（1-2 年）：形成全企业的数据治理文化，治理活动从"专项项目"变成"日常习惯" 关键在于不要追求一步到位。先跑通一个域，用效果争取更多资源，比一开始就铺开更有可持续性。 参考来源 [1] DAMA International，《What is Data Management?》 [2] DAMA International，《DAMA-DMBOK2 Data Management Body of Knowledge》 [3] GB/T 36073-2018《数据管理能力成熟度评估模型（DCMM）》 [4] GB/T 36073-2025《数据管理能力成熟度评估模型（DCMM 2.0）》，2026 年 7 月 1 日起实施，能力域扩展至九个，新增"数据资产" [5] 国家数据局，《"数据要素×"三年行动计划（2024—2026年）》 [6] Andrew Ng 等，《Data-Centric AI Resource Hub》 [7] 中国电子信息行业联合会，《DCMM标准解读与实施指南》