龙石数据中台 V3.9.1 聚焦 Doris 内核适配、增量同步标准化、任务熔断容错、流程可视化编排四大场景，针对性解决数据丢数、任务阻塞、建表异常、编排低效等关键问题，全面提升平台运行稳定性与数据集成效率。

一家制造企业去年同时启动了两个项目：数据中台二期和AI智能分析平台。数据中台团队负责接系统、建标准、做资产目录，AI团队负责选模型、调参数、搭推理服务。两个项目各有预算、各有排期、各有汇报线。一年后，数据中台的资产目录做得很漂亮，AI平台的功能演示也很炫——但当你问"帮我分析一下上个月的库存周转异常"，答案只有一句："数据还没对接好。" 这不是孤例。过去两年，大量企业在数据中台和智能中台上分别投入资源，两个中台各自运转良好，但中间那条缝，正在成为AI落地最大的卡点。 一个越来越清晰的趋势是：数据中台和智能中台不再应该分开建设。不是"数据中台给智能中台供给数据"这种上下游关系，而是两层能力深度融合，最终让AI用数成为企业里像用邮箱一样自然的标配能力。 一、两个中台，两种逻辑，一个断层 分开建设不是没有理由。数据中台的逻辑是"把数据管好"——统一标准、保障质量、管理元数据、建设资产目录。智能中台的逻辑是"把模型用好"——训练、部署、推理、监控。组织上，数据中台归数据团队，智能中台归AI团队，两边汇报给不同的领导，拿不同的预算。 问题出在交接区。数据中台的治理产出——标准文档、质量报告、元数据清单——本质上是给人看的。AI读不懂一份PDF格式的数据标准说明，也不理解"这个字段在ERP里叫客户名称，在CRM里叫签约主体"意味着什么。AI团队只能从数据湖里直接拉原始数据，花大量时间做数据清洗和特征工程。而这些工作，本该在数据中台层面就已经完成。 Data-Centric AI 的理念[1]已经被反复验证：AI效果的上限取决于数据质量，而不是算法。DCMM 2.0（GB/T 36073-2025）[2]将数据质量和数据标准列为核心能力域，从国家标准层面确认了一个判断：数据治理不是AI的"前置准备工作"，而是AI基础设施的组成部分。当企业发现调优了几个月的大模型，在实际业务场景中的表现还不如一个数据治理到位的中小模型时，把治理嵌入AI pipeline就不再是选择题。 分开建设的本质，是把"治理"和"使用"拆成了两段接力赛。数据团队跑完第一棒交出去就完事了，AI团队拿到第二棒发现交接过来的数据并不是自己想要的格式和粒度。交接区，就是故障区。 二、合流的三个方向 数据中台与智能中台的合流，不是要在技术层面做平台合并，而是在能力层面打通三个关键环节。 方向一：治理能力从"人可读"变成"机器可读" 传统数据治理的产出是给人用的——标准文档是PDF、质量报告是Excel、元数据清单是一个网页目录。AI用不到这些东西。 合流的第一步，是把治理能力变成AI基础设施。元数据管理不只是给数据管理员看的目录，而是AI理解数据含义的前提——"这个表叫sales_order，但它的实际业务含义是客户签约后的正式订单，不包括意向单和草稿单"，没有这一层语义标注，AI永远读不懂企业数据。数据标准不只是规范文档，而是AI跨表关联的翻译层——当ERP的订单状态是数字编码、CRM的订单状态是中文描述时，标准层负责统一语义。数据质量管理不只是出质检报告，而是AI输出可信度的基础——模型给出的分析结论是否可靠，取决于输入数据的质量水平。 方向二：资产目录从"汇报材料"变成"AI导航地图" 多数企业的数据资产目录定位是"给领导看的数据资产全景图"——展示了有多少张表、多少个字段、分布在哪些系统，但没人真的用它来找数据。 合流之后，资产目录的角色变了：它是AI用数的导航地图。当业务人员用自然语言问"帮我分析上个月的库存周转异常"，AI智能体要做三件事：理解"库存周转"这个业务概念；在资产目录中定位相关数据和指标；评估这些数据的质量是否满足分析要求。这三步的完成度，直接取决于资产目录的质量——目录里有没有这些数据、元数据描述是否准确、质量标注是否可信。 市场上已有部分产品在实践这个逻辑。以龙石数据中台的AI用数智能体为例，它基于语义检索和模糊检索双模引擎理解用户意图，背后依赖的就是数据中台层建立的资产目录和元数据体系。没有"理"和"管"打下的基础，"用"的体验就是空中楼阁。 方向三：用数能力从"专业特权"走向"企业标配" 今天在企业里用数据做分析，仍然是专业门槛很高的事——你得会SQL，或者至少会用BI工具拖拽。业务人员查一个数据的典型路径是：找IT提需求→等排期→IT写查询→返回结果→不对→再沟通→再等。一个简单问题来回好几天。 当数据中台和智能中台合流后，这个路径被压缩成：打开对话窗口→自然语言提问→AI理解意图、定位数据、生成查询、返回结果。整个过程不需要SQL、不需要等排期、不需要猜测数据在哪。龙石AI用数智能体的实际运行数据显示，简单场景下自然语言问数的准确率可达100%，全场景综合准确率超过95%。基础咨询工单量显著下降，用户检索耗时大幅缩短。 当用数能力像发邮件一样简单时，它才能真正成为企业标配——不是数据团队的特权，而是每个业务人员的日常工具。 三、一个已经落地的样本 江苏某国企数科运营着数据要素流通平台，汇聚了大量公共数据与市场化数据资源（企业名称已脱敏，下同）。平台上线后面临一个典型问题：数据有了、功能全了，但用户用不起来——找数靠关键词硬搜、用数靠自己摸索、运营需求难以系统收集。 龙石数据为平台构建了一个"感知-匹配-演进"三位一体的AI用数智能体。不是简单加一个问答界面，而是把智能体深度嵌入数据中台的治理成果之上。技术层面，智能体基于语义检索和模糊检索双模引擎理解用户意图，自动引导从查找到申请的全流程。运营层面更值得关注——智能体分析用户的搜索失败记录和浏览中断点，自动识别潜在需求并生成需求洞察报告，直接驱动数据产品的上架、优化和迭代。 运营团队的一位成员说得直白："以前推数据产品像蒙着眼睛打靶，智能体给了我们一杆瞄准镜。" 这个案例的启示不在于技术本身，而在于验证了一个逻辑：当智能中台不是独立于数据中台之外的另一个项目，而是基于数据中台的治理成果（资产目录、元数据、质量标准）来构建，合流就不是口号，而是可验证的效果。 四、给企业的三个行动建议 先理后AI。 如果还没有数据资产目录和元数据体系，在启动AI项目之前先把这些基础建起来。不需要追求完美覆盖，但至少让AI知道有哪些数据、在哪、是什么意思。这是AI不翻车的底线。 把用数入口做简单。 不要让用数据成为IT部门的专属能力。衡量标准很简单：一个业务人员能不能在不看说明书的情况下，3分钟内查到他想要的数据。自然语言问数、智能检索、自动可视化——这些能力今天已经可以在现有数据中台之上快速叠加。 管用一体。 如果数据治理团队和AI团队还在分开汇报、分开预算、分开考核，合流只会停留在PPT里。管和用是一件事的两个面，组织设计上应该先解决这个断裂。 五、常见问题 Q: 数据中台和智能中台合流，是不是意味着要推倒重建？ 不需要。合流是能力打通，不是平台合并。如果现有数据中台已经有资产目录、元数据和质量管理体系，智能中台可以直接基于这些能力构建用数入口。如果治理基础薄弱，合流的过程本身就是倒逼治理升级的契机——不是"等治理完美了再上AI"，而是"AI用数的需求反过来驱动治理加速"。 Q: 中小企业没有专门的AI团队，怎么推进合流？ 中小企业反而是合流模式更容易落地的场景——团队小，数据团队和AI团队可能本来就是同一拨人，不存在组织上的割裂。关键是选一个业务价值最高的用数场景，把资产目录做扎实，叠一个轻量级的AI用数入口，先跑通再扩展。如果对数据质量心里没底，龙石数据质量管理平台社区版免费可用，覆盖GB/T 36344主要维度，可以先做一次数据质量体检。 Q: AI用数准确率能到100%吗？ 做不到，也不需要。业务场景下的AI用数追求的不是实验室里的完美准确率，而是"可用的准确率+可解释的错误"。简单场景（如按条件查询统计）准确率可以做到接近100%，复杂场景（如跨多表关联推理）会有误差。关键是当AI出错时，用户能理解为什么错了、原始数据是什么、正确结果该怎么得到。治理到位的元数据和数据质量标注，正是支撑这种"可解释性"的基础。 参考来源 [1] Andrew Ng et al., Data-Centric AI, https://datacentricai.org/ [2] DCMM 2.0（GB/T 36073-2025），数据管理能力成熟度评估模型，九大能力域

"我们数据中台两年前就验收了，但现在的情况是——项目组解散了，实施厂商撤走了，业务部门也不怎么用那个平台了。ETL任务还在后台跑着，但没人说得清那些数据资产现在是什么状态。" 这是去年在一场数字化沙龙上，一家制造企业的CIO描述的真实处境。他不是个例。过去五年，国内大量企业完成了数据中台的"上半场"——建平台、接系统、做报表、搞大屏。但验收会开完、项目归档之后，故事往往就结束了。 一个被反复验证的现实是：数据中台建好不难，难的是让它持续产生价值。这不是平台功能的问题，而是认知的问题。数据中台的下半场，本质是认知的升级——从"建设一个平台"转向"运营一种能力"。 一、上半场跑不通的三个原因 回顾上半场的普遍路径：企业立项数据中台项目，选型采购，实施团队进场，花半年到一年把平台搭好、数据接进来、应用做出来。验收通过，项目结项。然后呢？ 第一个原因：项目思维害了中台。 数据中台在很多企业里被当作一个IT项目来管理——有明确的开工日期、验收标准和结项时间点。项目制的逻辑适用于盖楼、上ERP，但数据中台不是一次性的建设工程。它是一个需要持续运转的能力平台。当项目组解散、厂商撤场，随之消失的不仅是人，还有在建设过程中积累的理解、经验和判断。留下的平台变成了一个没有人真正懂、也没有人真正管的"数据盒子"。 第二个原因：组织机制没有跟上平台建设。 平台上线了，但没有人对"数据资产健康状况"负责。没有数据管理部、没有常态化的质量巡检机制、没有明确的数据责任人。业务部门的数据问题不知道该找谁，IT部门觉得"平台建好我的任务就完成了"。平台和业务之间出现了一个巨大的真空地带——没有人去想"这个平台今天还在产生价值吗？" 第三个原因：治理被当成了一次性运动。 建平台的时候搞过一轮数据标准、做过一批质量规则、补过一次元数据。建完之后，标准没有再更新过、质量规则没有再校准过、元数据没有再补充过。业务在变、系统在变、数据在变，但治理停留在验收那一刻。一年后，当初梳理的数据资产目录，已经和实际的数据状况对不上了。 这三个原因指向同一个根本问题：上半场用工程逻辑做数据中台，但数据中台的成功条件不是工程交付，而是持续运营。 二、下半场需要三个认知转变 从"建中台"到"用中台"，不是工作量的叠加，而是逻辑的重构。 转变一：从"项目"到"能力" 数据中台不是有明确终点的工程项目，而是企业需要长期维持的一项数据能力。这听起来像是文字游戏，但落到组织行为上区别巨大。 当一个企业把数据中台当项目做，它关心的指标是"按时上线""功能验收通过""预算执行率"。当一个企业把数据中台当能力建，它关心的指标变成了"数据资产的使用频次""数据质量问题的收敛速度""业务部门自助用数的比例"。前者的终点是验收，后者的起点是验收。 从多数成功案例来看，能够持续产出数据价值的企业有一条共同的成长路线：认知建立→体系建设→平台建设→运营落地→组织自驱。平台建设只是五个环节中的第三个，而不是全部。 转变二：从"工具"到"机制" 上半场的核心投入在工具上——选哪家的平台、买多少个节点、配置哪些模块。下半场的核心投入在机制上——谁来管数据、怎么管、管得好不好谁说了算。 机制至少包含三个层面的建设。一是组织层面：成立数据管理部或类似职能机构，明确各部门的数据责任人，建立数据治理委员会或类似的跨部门协调机制。二是流程层面：把数据标准、质量检查、元数据更新、资产目录维护从"专项活动"变成"日常作业"——不是每个季度突击搞一轮，而是嵌入到数据流转的每一天。三是评估层面：定期做数据资产健康度评估，用可量化的指标回答"我们的数据中台今天还在创造价值吗"。 "理采存管用"方法论之所以被越来越多的企业采纳，不是因为它提出了什么新概念，而是因为它把数据治理从一个模糊的方向变成了五个可操作、可检查、可迭代的环节——理清家底、采进数据、存好模型、管住质量、用出价值。这五个字不是一张静态的蓝图，而是一个需要持续转动的闭环。 转变三：从"依赖厂商"到"组织自驱" 上半场的常见模式是"厂商驻场→厂商实施→厂商交付→厂商撤走"。双方都省事，但代价是——厂商一走，能力也跟着走了。 下半场的模式逻辑完全相反。以行业中的部分实践为例，一些数据中台厂商（如龙石数据）采用"产品+培训+陪跑"的三位一体模式。培训分三层：理论培训建立认知框架——DCMM、DAMA、"理采存管用"方法论；实施培训掌握落地方法——怎么启动、怎么推进、怎么持续；实战培训在真实场景中练出来——数据归集、标准建设、质量管理、AI用数。陪跑分三步：先在客户现场选一个真实业务域做样板工程，龙石指导但客户团队自己动手操作；样板跑通后形成可复用的内部模板；后续持续提供远程技术支撑。成长路线很明确：认知建立→体系建设→平台建设→运营落地→组织自驱。 目标不是"厂商帮你把数据治好了"，而是"你们自己能治了"。数据治理的终局不是供应商持续驻场，而是企业自身具备可持续的数据治理能力。 三、下半场长什么样：两个样本 上海某大型国有化工企业在数据中台建设过程中，同步做了一件容易被忽视的事：成立数据管理部。在龙石团队协助下，企业不仅打通了DCS、MES、LIMS、ERP等系统的数据壁垒，建成了贯通OT与IT的工业数据湖，更关键的是把数据治理的组织机制建立了起来——明确了生产、设备、质量、经营各领域的数据责任分工，数据标准和质检规则嵌入日常业务，不再是一次性运动。 成果不仅体现在数字上——库存周转率提升28%、订单交付及时率提升至91%。更值得关注的是机制层面的变化：数据管理部成为企业的常设机构，数据质量问题有人跟进、数据标准有人维护、数据资产有人盘点。企业的数据能力不再依附于某个项目组或某家厂商。 另一个样本来自高校。江苏某211大学原有的数据平台超期服役，系统不稳、运维高度依赖原厂、师生用数需要跨多个系统申请。升级为新一代数据中台后，学校实现了从"功能上线"到"持续数据运营"的跨越——跨部门数据申请从"天/周级"缩至"分钟级"在线自助获取。但比效率提升更重要的是，学校建立了自己的数据运营团队，不再"等着厂商来修"，而是自己持续迭代数据服务。 两个样本的共同点：平台建设是手段，组织机制的建立才是下半场的胜负手。 四、给CDO的行动建议 先建机制，再上平台。 如果你正在规划数据中台，把组织设计放在技术选型之前——谁是数据责任人？质量巡检谁来做？资产目录谁维护？这些问题不回答，平台买回来也是摆设。 做能力转移，不做长期外包。 如果你已经有中台但运营乏力，检查一下你的团队是否真正掌握了治理能力。如果每次出问题都要等厂商解决，说明上半场的模式还没结束。培训+陪跑的核心逻辑是：让你的人学会跑，而不是雇人替你跑。 让治理日常化。 数据标准和质检规则不是"建平台那半年"的任务，而是"中台活着的每一天"的例行作业。把它嵌入数据流转的每个环节，而不是等出了问题再追认。 五、常见问题 Q: 上半场已经建了中台，下半场怎么转？ 先做三件事：一是盘点现状——平台还在跑吗、数据还在用吗、治理机制还在运转吗；二是补组织——如果没有数据管理部或类似职能，尽快建立，哪怕先设一个兼职的数据责任人；三是跑一个样板——选一个业务价值最高的场景，用下半场的逻辑重新跑通一遍（治理嵌入日常、业务团队参与、形成可复用模板），而不是试图全线铺开。 Q: 中小企业也需要建数据管理部吗？ 不一定需要一个独立的部门，但必须有一个明确的角色或岗位对数据资产负责。中小企业可以从"兼职数据责任人"起步，关键是让这个人有明确的责任边界和可量化的评估指标——数据质量趋势、资产使用率、业务部门满意度——而不是一个虚衔。 Q: "产品+培训+陪跑"模式适合什么类型的企业？ 适合那些希望建立长期数据能力、不想长期被厂商锁定的企业。培训和陪跑的前期投入比单纯的"买平台+驻场实施"要高一些，但三年下来总成本往往更低——因为能力建在了自己组织里，不需要持续付费维持运转。当然，如果企业只是想快速上线一个数据看板，不需要深入的能力建设，那这种模式就显得重了。选择哪种模式，取决于你对数据中台的定位：是一个短期项目，还是一项长期能力。 参考来源 [1] DCMM 2.0（GB/T 36073-2025），数据管理能力成熟度评估模型，九大能力域 [2] DAMA International, DAMA-DMBOK 2.0, 数据管理知识体系

"我们数据中台已经跑了两年多，但今年启动的AI项目还是在数据环节反复翻车——数据质量不过关、元数据缺失、跨系统的字段对不上。我明明有中台，为什么AI还是用不起来？" 这是今年初一家制造企业CDO在行业闭门会上的困惑，当场引发了一圈共鸣。数据中台建设的浪潮过去后，一个尴尬的现实浮出水面：平台搭好了，数据也确实在跑了，但离"AI就绪"还差着一大截。 2026年，数据中台正站在一个新的十字路口。三股力量同时作用在它身上——政策端持续加压、标准体系加速升级、AI落地的数据需求从"最好有"变成了"必须有"。这三股力量叠加在一起，正在重新定义数据中台的演进方向。 一、三股力量正在重塑数据中台 政策端的推动已从鼓励走向倒逼。国家数据局"数据要素×"三年行动计划（2024—2026年）[1]进入收官年，财政部《企业数据资源相关会计处理暂行规定》[2]已施行两年，数据资产入表从试点走向扩面——企业不再被"建议"把数据管好，而是被"要求"把数据当资产管。当数据要上资产负债表，中台就不只是技术平台，而必须成为能支撑数据确权、估值、质量验证的资产管理基础设施。 标准端的演进同样在提速。DCMM 2.0（GB/T 36073-2025）[3]将能力域从8个扩展为9个，新增"数据资产"能力域——这是一个信号：数据管理能力的评判标准已从"有没有治理"升级为"能不能资产化"。企业对标DCMM时，不再只是盘点元数据和数据质量，还需回答"你的数据资产在哪里、值多少、能不能用"。 技术端的推力最为直接。Data-Centric AI 的理念[4]在过去两年被反复验证：与其花80%精力调模型参数，不如花80%精力提升数据质量——因为AI效果的上限取决于数据，而不是算法。当企业发现花了几百万调优的大模型，在实际业务场景中的表现还不如一个治理到位的中小模型时，数据治理在AI战略中的优先级自然被重新排列。 二、中台建好了，为什么数据还没"AI就绪"？ 回到开篇那个CDO的困惑。问题的根源不在平台本身，而在于大多数数据中台在建设时，数据治理被当成"附加模块"而非"默认配置"。 第一个症结：治理是"事后追认"。 典型场景是：平台先搭起来，数据先接进来跑起来，等业务反映"数据不对"了，再回头补标准、补质量规则、补元数据。事后的治理本质上是在给已经流转的数据"打补丁"——打上了还好，打不上的就变成技术债。而当AI项目启动时，这些债集体到期：训练数据中夹杂着不同口径的字段、缺失的元数据让模型理解不了业务语义、跨系统的数据不一致让AI输出互相矛盾。 第二个症结：管和用是两条平行线。 在很多企业里，数据治理团队和AI团队各自为战。治理团队产出的数据标准文档、质量报告、资产目录，AI团队看不到也用不上；AI团队从数据湖里直接拉原始数据训练，治理团队不知道他们在用什么数据、数据质量如何。两个团队用同一套数据底座，却活在两个信息孤岛里。 第三个症结：组织认知仍然滞后。 不少企业仍然把数据中台当作一个IT项目来管理——上线验收、结项归档、团队解散或转岗。但数据中台本质上是一个持续运营的能力平台，不是有明确终点的工程项目。当组织机制没有跟上——没有数据管理部、没有常态化的质量巡检、没有人对"数据资产健康状况"负责——中台建得再好，也只是一个技术空壳。 三、2026年的三个趋势深化 在上述挑战的倒逼下，数据中台正在经历一轮深层次的演进。不是功能列表的扩充，而是架构逻辑的重构。三个趋势方向正在从概念走向常态。 趋势一：AI原生——治理能力嵌入AI pipeline 过去两年行业逐渐达成一个共识：数据治理不是AI上线前的"准备工作"，它应该是AI基础设施的一部分。 传统的思路是"先治理再AI"——先花半年把数据标准建好、质量拉上来、元数据补全，再启动AI项目。这套逻辑在纸面上说得通，在实践中往往走不通：半年后业务需求变了，治理的优先级被重新调整，AI团队等不了那么久。 2026年更务实的路径是"治理即AI基础设施"——不是治理完了再给AI用，而是在AI用数的过程中，治理能力实时生效。具体来说：元数据管理不只是给数据管理员看的目录，而是AI理解数据含义的前提——"这个字段叫'客户名称'，但在ERP里指签约主体，在CRM里指联系人"，没有元数据层，AI永远读不懂数据。数据标准不只是规范文档，而是AI跨表关联的"翻译层"——当ERP的"订单状态"是数字编码、CRM的"订单状态"是中文描述时，标准层负责统一语义，让AI能正确关联。数据质量管理不只是出质检报告，而是AI输出可信度的基础——模型给出的分析结论是否可靠，取决于输入数据的质量水平。 这不是理论推演。Data-Centric AI 的研究和实践反复验证了一个朴素逻辑：在数据治理上投入的每一分精力，最终都会在AI效果上体现出来。 趋势二：数据编织——从"集中式仓库"到"智能编排层" 数据中台在很长一段时间里被理解为一个"超级数据库"——把所有系统的数据都搬进来、存起来。但在企业系统日益复杂、数据量持续膨胀的背景下，"全量搬迁"的成本和时效越来越难以承受。 数据编织（Data Fabric）的理念为这个问题提供了新思路：不要求所有数据物理集中，而是通过元数据自动发现、虚拟集成、智能编排，在逻辑层打通异构数据源。对于数据中台而言，这意味着从"存数据"向"连数据"的范式升级——不是所有数据都要进中台的仓库，但所有数据都应在中台的治理视野内。 落到"理采存管用"框架里，这个变化是根本性的。"采"不再只是物理归集，还包括虚拟接入和联邦查询；"存"不再追求全量存储，而是智能分层——高频热数据本地化、低频冷数据按需获取；"管"的治理规则需要在逻辑层覆盖所有数据源，而不仅仅是中台内部的数据。 趋势三："理采存管用"从串行流水线走向智能飞轮 "理采存管用"作为数据治理的工程落地框架，过去常被理解为五步串行：先理清家底、再把数据采进来、存好、管住、最后用起来。但在2026年的语境下，五个环节之间的关系正在被重新定义。 它不再是一根接力棒，而是一个相互驱动的闭环飞轮。"理"的产出——数据资产目录——直接成为"用"的起点，让AI用数智能体有据可依。"用"过程中发现的质量问题和数据缺口，自动反馈到"管"的质量规则迭代和"采"的接入策略调整。"存"的数据模型设计，为"用"的智能分析提供业务语义层。五个字之间是双向的信息流，而不是单向的接力传递。 这个转变的关键在于：数据中台从"工具集成"走向"智能驱动"。不是把采集、存储、治理、服务的工具集成到一个平台上就算完成，而是让治理逻辑在数据流转的每一个环节实时生效、自动反馈、持续优化。以市场上已有的部分产品（如龙石数据中台）为例，其"理采存管用"方法论已从概念框架落地为产品模块间的自动化贯通——标准规范驱动采集策略、资产目录驱动共享服务、质量规则在数据流转中旁路并行扫描，五个环节之间的信息流动不再依赖人工衔接。 四、一个落地样本：当智能体成为数据中台的"用"的入口 前面讲的是趋势，下面看一个已经发生的事情。 江苏某国企数科运营着一个数据要素流通平台，汇聚了大量公共数据与市场化数据资源（企业名称已脱敏，下同）。平台建设完成后，运营团队很快撞上了三个断层：找数难——资源丰富但检索粗放，用户往往需要多次筛选才能定位所需数据；用数难——功能完备但缺乏引导，新用户不知道从哪里开始；运营难——需求存在但难以系统收集，数据产品迭代缺乏依据。 龙石数据为平台构建了一个"感知-匹配-演进"三位一体的AI用数智能体。在技术层面，智能体基于语义检索和模糊检索双模引擎理解用户意图，通过自然语言即可完成数据资源的查询和流程引导。在运营层面，智能体不只是一个问答机器人——它通过分析用户的搜索失败记录、浏览中断点、未完成订单等行为，自动识别潜在需求并生成需求洞察报告。 更值得关注的是机制层面的变化。平台运营团队从"凭感觉安排数据产品上架"转变为"依据智能体需求报告召开数据产品决策会"，数据产品迭代周期明显缩短。运营团队的一位成员说了一句很形象的话："以前推数据产品像蒙着眼睛打靶，智能体给了我们一杆瞄准镜。" 这个案例的启示不在于技术本身——智能问答、语义检索都不是新技术。它真正的价值在于验证了一个逻辑：当"理"（资产目录）、"管"（数据标准和质量规则）、"用"（智能体）被打通成一个闭环，"用"不再是数据中台链条的末端，而是驱动整个飞轮旋转的起点。 五、给CDO的行动建议 面对2026年的趋势变化，三条行动路径值得关注： 先理后AI。 在启动AI项目之前，把数据资产目录和元数据先建立起来。不是要求"完美治理"，而是要求"最小可用治理"——AI至少要知道有哪些数据、数据在哪里、数据是什么意思。这是AI项目不翻车的底线。 管用一体。 不要把数据治理和AI应用分成两个团队、两个项目、两个预算线。治理能力要嵌入AI pipeline，治理团队的产出要对AI团队可见、可用、可验证。管和用是一件事的两个面。 机制比平台重要。 数据中台建好不是终点。成立数据管理部、建立常态化的质量巡检机制、明确数据资产健康度的责任人——这些组织层面的动作，往往比平台功能升级更能决定中台的长期价值。从多数成功案例来看，能够持续产出数据价值的企业，不是平台最先进的那批，而是组织机制最扎实的那批。 六、常见问题 Q: "理采存管用"和数据编织（Data Fabric）是替代关系吗？ 不是替代，是互补。"理采存管用"是数据治理的工程落地框架，数据编织是一种数据架构理念。"理采存管用"的五个环节中，"采"和"存"两个环节天然适合融入数据编织的虚拟集成和智能分层思路——不要求所有数据物理集中，但要求所有数据在治理视野内。 Q: AI原生数据中台和传统数据中台的核心区别是什么？ 核心区别在于治理能力的定位。传统数据中台把数据治理当作一个独立的功能模块，你可以用也可以不用。AI原生数据中台把数据治理能力——元数据、数据标准、数据质量——内化为AI用数的基础设施，没有这些治理能力，AI就无法正确理解和使用数据。两者不是"功能多少"的差异，而是架构逻辑的根本不同。 Q: 中小企业预算有限，怎么跟上这些趋势？ 中小企业不一定需要"全面跟上"，更需要"精准切入"。优先做三件事：一是建一个最小版本的数据资产目录，搞清楚自己有什么数据；二是选一两个业务价值最高的场景做数据质量治理，不追求全覆盖；三是利用市场上已有的轻量化工具——例如龙石数据质量管理平台社区版免费可用，覆盖GB/T 36344数据质量评价指标的主要维度，可以帮助团队先做一次数据质量体检，再根据体检结果决定下一步投入方向。 参考来源 [1] 国家数据局，《"数据要素×"三年行动计划（2024—2026年）》 — https://www.gov.cn/ [2] 财政部，《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号），2023年8月 — https://www.gov.cn/ [3] DCMM 2.0（GB/T 36073-2025），数据管理能力成熟度评估模型，九大能力域 [4] Andrew Ng et al., Data-Centric AI, https://datacentricai.org/

为什么很多企业的大模型项目最终卡在数据治理？ 一家制造企业（企业名称已脱敏，下同）去年部署了大模型，内部试点时效果不错——问"本月华东区销售情况"，能自动拉数据、出图表、给分析。正式上线后，业务部门第一天就投诉："它告诉我华东区上月销售额 3200 万，但我们财务系统里是 2800 万。差 400 万。" 技术团队排查后发现：不是模型的问题。大模型调用的数据来自三个不同的业务系统，每个系统对"华东区"和"销售额"的定义都不一样。模型只是忠实地汇总了它能找到的数据——而这些数据本身口径就不统一。 类似的情况正在越来越多的企业上演。过去一年，大模型部署进入加速期，但很多团队发现，模型效果从"惊艳"到"翻车"往往只有一个环节的距离：数据。 AI 效果的上限，取决于数据质量 国际 AI 学者吴恩达（Andrew Ng）提出的 Data-Centric AI 理念[1]，核心观点很直接：与持续优化模型相比，持续提升数据质量和数据治理能力，往往能获得更大的业务收益。 这个判断对企业的意义在于：如果数据本身存在问题，再好的模型也无法给出可靠的输出。而且大模型对数据质量的容错率比传统 BI 更低——传统报表出现一个数字偏差，可以人工核查、修正解释；但大模型输出的是一段完整的分析结论，一个数据错误就可能导致整体判断偏差，而业务人员往往难以逐句验证。 当企业的数据治理存在短板时，这些短板会在大模型场景下被集中放大。以下四个方面最为突出。 1.数据质量问题：脏数据直接导致输出不可信 数据质量是大模型落地中最先暴露的问题，也最容易被误判为"模型不行"。 大模型的工作机制决定了它不会主动质疑数据的准确性。输入数据中存在的缺失字段、错误取值、重复记录，会被模型当作事实接受，并在此基础上生成流畅但可能错误的回答。传统 BI 报表中一个字段为空最多显示"null"，但在大模型的自然语言输出中，空值可能在上下文推理中被补全为一个不确定的数值，用户难以判断该数值的来源依据。 更隐蔽的问题是数据的一致性。当同一个业务指标在多个系统中存在不同数值时，模型可能在回答不同问题时引用不同来源的数据，导致前后输出矛盾。用户发现"同一个问题，问了两次答案不一样"，第一反应是模型不可靠，而根因是底层数据口径不统一。 问题排查同样消耗大量资源。一次数据质量问题导致的大模型输出错误，往往需要回溯多个数据源、对比多套口径、跨部门确认数据归属，排查周期可能长达数天。这意味着数据质量管理的缺失，在大模型时代会带来比传统场景更高的修复成本。 2.数据标准缺失：大模型无法跨系统理解业务 如果数据质量是"数据准不准"的问题，数据标准就是"数据能不能被理解"的问题。 大模型需要理解不同业务系统中的数据含义才能给出可靠的回答。但在很多企业中，同一个业务概念在不同系统中使用了不同的字段名、编码规则和取值口径，这使得大模型难以建立跨系统的语义一致性。 举例来说，一个用户问"分析去年各产品线的毛利率"，大模型需要从多个系统中获取收入、成本、产品分类等数据。如果不同系统对"产品线"的划分逻辑不同——财务系统按核算科目分类、生产系统按工艺路线分类、销售系统按渠道分类——大模型就无法自动判断应该以哪个口径为准。它可能混合了不同系统的数据，输出一份看似完整但实际上口径混乱的分析。 数据标准的缺失不仅影响大模型的输出质量，还增加了持续的运维成本。每接入一个新的业务场景，治理团队需要额外梳理数据映射关系、编写清洗规则、处理口径差异。这些重复性工作占据的时间越长，团队能够投入到真正治理工作上的精力就越少。 3.元数据割裂：训练数据变成黑箱 元数据是数据的"使用说明书"——它记录了数据从哪个系统来、经过了哪些加工、字段含义是什么。在企业级大模型部署中，元数据的完整性和可追溯性直接决定了数据治理团队对模型行为的掌控能力。 当大模型给出一个错误或不当的回答时，治理团队必须能够快速追溯到问题数据的源头。但在缺乏有效元数据管理的情况下，这个追溯过程效率很低。团队需要翻阅 ETL 脚本、询问开发人员、对比多套文档来定位数据来源，而熟悉历史系统的人可能已经调离岗位。追溯周期从"分钟级"延长到"天级"，治理团队被绑定在被动响应中。 另一个问题是训练数据的透明度。大模型的微调和 RAG（检索增强生成）往往依赖企业自己的数据，但如果这些数据的来源、加工过程和质量状况缺乏元数据记录，模型的行为就缺乏可解释性。当监管或审计要求说明"这个大模型的训练数据来源是什么"，企业可能无法给出完整的回答。 Data-Centric AI 理念强调的"系统性提升数据质量"，前提就是元数据管理——只有先搞清楚数据从哪来、经过了什么处理，才能有针对性地进行优化。没有元数据的治理是盲目的。 4.安全合规：大模型场景下的数据泄露风险 大模型的数据安全问题相比传统信息系统有其特殊性。 首先，大模型对训练数据有记忆能力。如果原始数据中包含个人身份信息、商业秘密或敏感业务数据，这些信息可能在模型训练过程中被编码进模型参数，并在特定提示词下被提取出来。在传统 BI 系统中，敏感数据的访问可以通过权限控制精确到字段级别，但在大模型的自然语言交互中，权限和输出的边界更难被精细控制。 其次，大模型容易放大数据的流通范围。过去，包含敏感信息的数据库表只有少数授权人员可以查询；接入大模型后，任何有权限使用该模型的用户都可能通过自然语言提问触及这些数据。如果敏感数据没有经过预先的分类分级和脱敏处理，大模型的使用会显著扩大敏感信息的潜在暴露面。 数据安全合规的底线是：在数据进入大模型之前，必须完成分类分级、脱敏处理和权限管控。这不是大模型本身能解决的问题，而是数据治理体系必须覆盖的范围。 解法：数据治理是大模型的地基 以上四个问题虽然表现不同，但解决路径指向同一个方向：需要在大模型接入之前，建立覆盖标准、质量、元数据和安全管理的数据治理体系[2][3]。 在数据标准方面，统一核心业务实体的编码规则和口径定义，使大模型在跨系统查询时有统一的语义基础。在数据质量方面，建立接入环节的质量基线——完整性、准确性、一致性校验在数据流转中自动执行，问题数据在源头被标记。在元数据管理方面，实现自动化的元数据采集和血缘追踪，使数据来源和加工过程可追溯。在数据安全方面，完成数据分类分级和脱敏处理，确保敏感数据在大模型交互中的访问边界可控。 这四个维度构成了大模型场景下的"数据就绪"体系。治理底座越牢固，大模型输出的可信度越高。 目前已有部分数据中台产品按照这种治理前置的理念设计。例如龙石数据中台以数据治理为核心，将标准管理、质量稽核、元数据管理和安全管理作为平台的基础能力，与数据集成和服务层协同运作。治理规则在数据流转中自动执行，减少了人工干预的成本和滞后性。 对于还不确定从哪个环节切入的团队，一个低成本的起步方式是先做数据质量评估。市场上也有部分免费的数据质量工具，例如龙石数据质量管理平台·社区版，部署后可对核心数据源进行 GB/T 36344 标准框架下的质量检测。先摸清数据现状，再根据结果确定治理优先级——标准混乱的从标准入手，质量问题突出的从质量基线入手，元数据缺失严重的先做元数据采集。 常见问题 Q1：已经在使用大模型了，还能回头补治理吗？ 可以。建议先对当前大模型使用的核心数据域做一次质量评估，确定最突出的问题维度。增量的治理规则——如质量校验和元数据采集——可以在不中断大模型运行的情况下逐步建立。存量数据的标准化和清洗按优先级分批推进。 Q2：大模型项目要不要等治理做完再启动？ 不需要。两者可以并行，但建议在模型正式面向业务用户开放之前，至少完成核心数据域的标准统一和质量基线建立。内测阶段可以先用受控数据集验证模型效果，治理工作同步推进。 Q3：怎么判断是模型能力问题还是数据质量问题？ 一个简单的判断方法：选取一个已知数据质量的业务域做测试。如果在该域中模型输出准确度明显高于其他域，说明问题更可能出在数据而非模型。可以借助数据质量评估工具对输入数据做系统检测，将检测结果与模型输出效果做对照分析。 结语 大模型代表了企业 AI 应用的前沿方向，但它的效果并不完全取决于模型本身的能力。标准不统一、质量不可控、元数据不透明、安全不到位——这些问题在大模型时代会被快速放大。企业 AI 建设的瓶颈正在从模型能力转向数据能力，数据治理的成熟度直接决定了大模型能走多远。 参考来源 [1] Andrew Ng et al., Data-Centric AI — https://datacentricai.org/ [2] GB/T 36073-2025《数据管理能力成熟度评估模型》(DCMM 2.0) https://openstd.samr.gov.cn/bzgk/std/newGbInfo?hcno=22559F9C7BF9EAC6A3927223FE33CE20 [3] DAMA International,《数据管理知识体系指南》(DMBOK2) https://dama.org/learning-resources/dama-data-management-body-of-knowledge-dmbok/

数据治理团队的周报里，有两类工单越来越密集：一类是字段映射和口径对齐，另一类是数据质量问题的投诉排查。 团队配置并不弱——DCMM 评估师、DAMA 认证的数据管理专业人员都在[1][2]。但这些人的日常正在被大量重复性、追溯性工作占据，真正该投入的数据治理体系建设和资产化推进反而一推再推。 问题出在哪里？我们把工单拆开看，会发现根源不在运维层面，而在更早的阶段——平台建设时被跳过的数据治理工作，现在以运维成本的形式回流了。主要集中在三个方面。 一、数据标准缺失带来的重复性投入 一个建筑装饰集团（企业名称已脱敏，下同）的情况很能说明问题。该集团旗下有两百余家分子公司，同一根"镀锌方管 40×60"，在采购系统、项目管理系统和财务系统中分别为三种编码和命名。每月底对账时，财务和项目团队需要人工核对一周。 这还只是一种物料。当几千种物料、数百个供应商、数十个项目部的数据缺乏统一的主数据标准时，每接入一个新系统、每出一个新报表，治理团队都要做一轮手工映射和清洗。 原因并不复杂：平台建设阶段采取了"数据先进来再说"的策略，数据标准没有前置定义，主数据没有统一。短期看，平台确实通了，但后续每增加一个数据源、每扩展一个业务场景，标准不一致带来的重复投入都会同步放大。团队不是在用标准化手段管理数据，而是在用人填补标准缺失的缺口。 二、数据质量问题造成的排查成本 数据质量问题的影响不止于"结果不准"，更在于它带来的排查链条。 华东某化工企业（企业名称已脱敏）在中台上线初期，将 MES 和 ERP 的数据接入平台后，业务部门很快就反馈数据与源系统不一致。治理团队排查后发现，同一个物料在两边系统中的编码体系完全不同——物料编码、批次号、供应商代码，几乎所有主数据都涉及口径问题。前三个月的集成成果大部分需要重做，调整主数据标准并建立质量规则后，交付及时率才有明显改善。 而排查本身消耗的资源往往比返工更多。一次"数据不准"的反馈，可能涉及三四个源系统的日志回溯、十几张表的数据比对、多个部门的联合对账。根因可能是数月前某个字段的映射规则设置问题。排查周期长不是因为团队能力不足，而是因为缺乏前置的数据质量基线——问题数据在接入时没有被拦截，等下游发现时影响范围已经扩散。 三、元数据缺失导致的管理成本 相比标准和质量的显性问题，元数据缺失的影响更隐蔽，但同样持续消耗治理团队的精力。 当数据出现问题，治理团队需要回答几个基本问题：这个字段来源是哪个系统？经过哪些加工步骤？最近一次变更是什么时候？在没有自动化的元数据采集和血缘追踪的情况下，回答这些问题的方式往往是翻阅 ETL 脚本、查找工单记录、询问相关开发人员。熟悉历史代码的人一旦离开，追溯难度还会进一步上升。 这种状态持续下去，治理团队的核心工作会逐渐被"数据追溯"占据。他们被组织赋予的职责——设计治理体系、建设数据资产目录、推动数据服务化——反而被挤到了次要位置。 四、治理能力前置是降低长期成本的关键 以上三类问题的共同特征，是治理被放在了数据流转之后，而非嵌入流转之中。标准在接入之后才补映射脚本，质量在投诉之后才开始排查，元数据在问题发生后才去翻代码——这些都属于事后补救式治理。 调整的方向很明确：将治理能力作为数据平台的原生组成部分，而非后期叠加的修正层。 在标准管理方面，主数据标准和字段映射规则如果能在定义阶段建好，后续接入可自动对齐，减少人工映射工作量。在质量管理方面，前置的质量规则——非空校验、值域约束、跨表一致性检查——在数据接入时即可执行，问题数据在源头被标记，不向下游扩散。在元数据管理方面，自动化的元数据采集和血缘构建，可以将问题定位从"翻代码"级缩短到字段级。 市场上已有部分数据中台产品按照这种"治理内建"逻辑设计，例如龙石数据中台将标准管理、质量稽核和元数据管理模块与数据集成、存储、服务层协同运行，标准定义后作用于接入链路，质量规则在流转中旁路执行，元数据自动采集并生成血缘。这种模式下，治理团队的人工投入可以从重复追溯转向体系建设和资产运营。 需要指出的是，治理前置并不是一个一次性的项目。已经处于运行状态的中台，可以按照当前最突出的问题确定优先级——元数据缺失严重的先做元数据治理，质量问题频发的先做质量基线，标准混乱的先做核心数据域的标准化。任何一个维度的改善，都会直接体现在治理团队日常工作的效率变化上。 五、常见问题 Q1：运维成本高，是不是平台选型有问题？ 不一定。很多情况下，成本增长的主要原因是前期跳过治理导致后续工作以人工方式回流，而不是平台技术架构本身。建议先排查当前运维工作的类别分布——标准相关、质量相关、元数据相关各占比多少——再判断问题在治理还是平台。 Q2：已经在大量人工运维的状态下，应该从哪里入手？ 没有适用于所有企业的统一顺序。如果当前最突出的问题是质量投诉频繁，就从质量基线入手；如果数据追溯困难是主要瓶颈，就先做元数据治理。另外需要区分存量问题和增量问题：增量的质量规则和元数据采集可以在短期内在新接入域中建立，存量数据则按优先级逐步清理。 Q3：治理前置需要多长时间才能看到效果？ 元数据治理通常在 1-2 个月内即可改善数据追溯效率。质量基线在新接入域中可以同步建立，增量问题在建立规则后即可拦截。核心数据域的标准化周期取决于数据域数量和复杂度，3-6 个月可以完成主要域的统一。关键是建立机制确保新增数据域不再重复跳过治理环节。 六、结语 数据中台运维成本高的背后，往往不是运维团队能力的问题，而是更早阶段的数据治理工作没有到位。标准、质量和元数据——这三项能力如果在平台建设阶段被跳过，最终会以人力投入的形式持续消耗治理团队的精力。 如果治理团队长期将主要精力投入排障和数据追溯，说明平台建设阶段的治理能力仍有较大补齐空间。补齐的时机越早，后续的隐性成本越低。 参考来源 [1] DAMA International,《数据管理知识体系指南》(DMBOK2) https://dama.org/learning-resources/dama-data-management-body-of-knowledge-dmbok/ [2] GB/T 36073-2025《数据管理能力成熟度评估模型》(DCMM 2.0) https://openstd.samr.gov.cn/bzgk/std/newGbInfo?hcno=22559F9C7BF9EAC6A3927223FE33CE20

张总的会议室里，这是第三次讨论数据中台建设方案了，依旧没有结论。 "我的建议很明确，"技术负责人老李敲了敲桌子，"先把平台搭起来，数据能接的先接进来。老板要看的是成果，咱们治理做了大半年还拿不出东西，怎么交代？" 数据治理经理小王立刻摇头："不行。标准没定、质量规则没建，数据接进来就是一团乱。上次我和你说过，物料编码到现在还没统一，接进来的数据口径都对不上，后面全是返工。" "那你说怎么办？治理治理，治了半年还在写标准文档，老板不会等我们的。" 会议室陷入沉默。张总知道两边的担心都有道理，但他需要一个能落地的时间表和路线图。 这不是一个团队的问题。几乎每一个正在筹备数据中台的企业，都在这道"先有鸡还是先有蛋"的选择题前犹豫过。 一、为什么这是个真问题 表面上是"顺序之争"，底层是两种完全不同的建设逻辑。 平台派的逻辑是一条直线：快速出平台 → 数据接入 → 跑通几个报表 → 让领导和业务看到价值 → 拿到更多预算后再补治理。他们的焦虑很真实——数据中台投入不小，如果前几个月什么都没"亮相"，项目可能直接被砍。 治理派的逻辑也是一个闭环：先定标准 → 清理数据 → 建质量规则 → 梳理元数据和资产目录 → 再上平台承载。他们见过太多"平台建好了但数据不可信"的失败案例，知道一旦跳过治理这一步，后续的成本是指数级的。 两派的对错都不能简单判定——他们只是看到了同一枚硬币的不同面。真正的问题是：有没有一条路，既能避免"先建后治"的返工，又能避免"只治不建"的尴尬？ 先看看两边各自踩过的坑。 二、平台先行派：数据接进来了，但没人敢用 "先建平台再补治理"最大的诱惑是快。但快完之后的问题，往往比想象中大得多。 华东某大型化工企业（企业名称已脱敏，下同）的教训很有代表性。他们的中台项目启动后，团队决定先跑通数据集成——把 MES 和 ERP 的数据接入中台。三个月后，集成的确跑起来了，但业务部门一看就发现问题：同一个物料，ERP 里的编码是"MAT-00123"，MES 里是"RM-20231205-01"，两边根本对不上。 问题出在源头——数据标准没统一、主数据没治理，集成工作全部基于错误的映射关系。最终，前三个月的集成成果几乎全部推倒重来。调整路径后——先统一主数据编码标准、建立数据质量规则——交付及时率从不足 70% 提升到了 91%，库存周转率提升了 28%。 这不是个例。很多项目都踩过同一个坑：在"理"之前就做"采"。数据资产还没盘点、标准还没定、治理组织还没建，就开始写 ETL 脚本接数据。结果是接进来的数据口径不一致，后面全是返工。 另一种常见的情况更隐蔽：在"管"之前就做"用"。平台接入了数据，团队迫不及待开始做报表和可视化大屏。但业务部门很快发现，同一个"销售额"，BI 页面上显示的和财务系统的数字差了上百万。谁还敢用？数据标准没统一、质量没管控、元数据没梳理，再漂亮的看板也只是"假数据"。 平台先行的本质问题是——它在没有地基的情况下开始盖楼。楼能盖起来，但用不了多久就得修补裂缝。 三、纯治理派：标准写了大半年，领导等不及了 治理派的困境是另一个极端。 "先做治理"的思路本身没错，但执行层面容易出现一个问题：治理被做成了学术研究。团队花了大量时间对标 DAMA[1]、DCMM[2]，写了厚厚的数据标准文档，组织架构图改了又改，但始终没拿出一个让业务领导"看得见、摸得着"的东西。 三个月过去了，领导问："数据中台建得怎么样了？"答："我们在做数据治理体系的顶层设计。"领导再问："能让我看一下吗？"答："现在还在文档阶段。"——这种对话一旦发生，项目就已经处于危险之中。 治理先行不等于治理独行。治理的价值需要通过平台来放大，标准和规则只有在真实的系统里跑起来才有意义，停留在文档里的治理体系和没有一样——不对，更糟：它还消耗了团队的信心和领导的耐心。 纯治理派踩的坑本质上是：把"先做治理"理解成了"只做治理"。它忽略了一个关键事实：治理本身也依赖平台的承载，没有平台的数据质量规则是纸上谈兵。 四、第三种路线：螺旋迭代，但起点通常是治理 两边都踩过坑之后，答案其实已经清晰了。不是二选一，是分步走。从多数成功案例来看，治理通常应先于大规模平台建设启动。 这套思路可以用龙石数据的"理、采、存、管、用"方法论来落地——它将治理工作与平台能力建设同步推进，目标是快速见效、持续迭代。 第一阶段：以"理"为起点，建立基线（4-6周） 此阶段聚焦于"理清家底、建立规则"，为核心数据的规范化管理奠定基础。 主要任务： 盘点数据资产：系统梳理核心业务系统（如ERP、CRM）的关键数据表与核心字段，形成一份清晰的数据资产清单，明确"我们有什么数据"。 构建核心标准：针对最关键的实体（如物料、客户、供应商），制定统一的主数据编码标准，解决"一物多码"等根本问题。 设定质量基线：为核心字段定义最基本的数据质量规则，如非空约束、值域范围、格式校验，建立可量化评估的数据质量基线。 核心产出与价值：产出数据资产清单 + 核心主数据标准 + 数据质量基线评估报告。目标不是"治好"，而是"看清"和"管起"——向决策层清晰呈现数据现状，明确治理的起点与规则。 第二阶段：以"采、存、管、用"形成验证闭环（6-8周） 选择1-2个业务痛点最明显的数据域（如"客户域"），利用轻量化的治理平台，完整跑通数据价值生产的全链路。 主要任务： 数据采集（采）：将选定数据域相关的多源异构数据（数据库、文件、API等）按需归集至中台。 建模与存储（存）：依据第一阶段制定的标准，对该数据域进行数据模型规划与设计，并在数据仓库中规范存储。 落地治理（管）：在数据入库及加工过程中，嵌入并执行第一阶段制定的数据质量规则与清洗转换逻辑，保障数据可信。 场景化应用（用）：基于治理后的高质量数据，快速构建并交付1-2个业务价值明确的场景，如客户360°视图、精准营销标签等，让业务方直接感受到数据治理的效用。 核心产出与价值：产出一个可运行的数据治理流程 + 一个已验证的数据应用场景。验证方法论与平台的有效性，证明治理后的数据能够切实被业务所使用，建立团队信心，形成可复制的样板。 第三阶段：以"用"促"治"，螺旋扩展（持续运营） 将第二阶段已验证的"小闭环"经验与模式，复制推广到更多的业务域，实现治理广度与深度的螺旋式上升。 主要任务： 横向扩展：将成功的治理模式（标准、流程、平台用法）复制到产品、供应链等其他数据域。 纵向深化：基于业务反馈，持续迭代和深化数据标准、质量规则；拓展更丰富的数据应用形式，如可视化报表、指标分析、API服务共享等。 体系完善：随着覆盖域的扩大，逐步完善元数据管理、数据安全、资源目录编目等管理体系，形成可持续发展的数据运营机制。 核心产出与价值：产出覆盖多域的企业级数据资产体系 + 常态化、制度化的数据运营能力。每一个新域的接入都反向驱动治理体系的完善和平台能力的增强，让数据治理真正成为业务创新与决策的核心驱动力。 通过以上"理（定规则）→ 采存管用（跑闭环）→ 用治协同（扩体系）"的路径，数据治理不再是抽象的蓝图，而是一个目标清晰、节奏可控、价值可期的可执行计划。 江苏某自动化控制企业的实践印证了这个路径。他们的做法可以总结为一句话：治理先行，不急于上应用。先统一主数据标准、建立数据质量规则——就像在数据进场之前先把"安检通道"搭好。不是等所有数据都治理完再建平台，而是让治理规则自然嵌入平台的运行逻辑中。 在这个路径下，市面上已有产品能够支撑这种"治理内建而非外挂"的模式。以龙石数据中台为例，它的治理模块——数据标准管理、质量稽核、元数据管理和资产目录——并不依赖平台完全建好才能使用。团队可以先做标准定义和质量规则配置，产出质量报告，这些治理成果本身就是阶段性交付物；之后平台建设时直接继承，无需重复投入。 五、给 CDO 的内部沟通框架 如果你现在正面临团队内部的"先建还是先治"之争，下面这个框架可以帮助你把争论转化为行动： 第一：做方法论对齐（1 周）。 不要试图说服哪一方，而是让两派用自己的语言描述对方的担忧。平台派说说"治理派担心什么"，治理派说说"平台派担心什么"。你会惊讶地发现，两边的底层目标其实一致——都希望中台能真正用起来。差异只在对"怎么走到那里"的想象不同。 第二：选 1 个最痛的数据域先跑（第 2 周确定）。 不要在"全部数据域"的层面争论。选一个业务每天都痛的数据域——比如客户域，销售天天因为客户信息不一致而扯皮。搁置全面铺开的争论，先在这个域上验证螺旋迭代模式。 第三：设交替里程碑。 不要让治理派和平台派"等对方先完成"。每月都有治理产出（标准文档、质量报告、资产清单）和平台产出（接入新域、上线新报表）交替出现。两边都有阶段性成果可汇报，团队士气和管理层信心才能维持。 六、FAQ Q1：治理先行是不是等于"先别建平台"？ 不是。两者的关系是同步推进而非先后排队——第四节的三阶段路径中，"理"阶段就开始建立标准基线，同时轻量平台也在搭建。区别在于平台不追求"大而全"，先只承载已治理好的数据域。治理扩到哪，平台跟到哪。 Q2：团队只有 5 个人，怎么搞？ 选最痛的数据域，花 2 周定核心标准和质量规则，再花 4 周搭轻量平台跑验证。5 个人不要铺开，集中力量把一个域跑通、跑透。跑通了一个域，你就有了模板，也拿到了说服领导和业务部门的证据。 Q3：领导要 3 个月出成果，治理来得及吗？ 治理的成果不只有"平台建好了"这一种。第一个月你可以交付：数据资产清单（"我们家有哪些系统、哪些表、哪些数据"）+ 数据质量评估报告（"这些数据目前的质量状况如何"）。告诉领导"我们家数据原来是这个状况"——这份报告本身就是成果，而且是后续所有工作的决策依据。 七、结语 数据中台真正的分歧，从来不是"要不要做治理"，而是"治理什么时候做"。 先建平台再补治理，相当于在没打地基的地方盖楼——盖得越快，隐患越大。只治不建，相当于画了一张完美的图纸但永远不开工——等图纸画完，信心也耗尽了。 答案是：治理在前，不是因为它比平台重要，而是因为它决定平台能走多远。先治理再平台，不是多走一步，是少走弯路。 当团队下一次在会议室争论"先做什么"的时候，不妨把问题换一换——不是"先建平台还是先做治理"，而是"我们选哪个数据域先跑通整套流程"。从争论顺序，到验证模式。这一步，才是真正走出纠结的开始。 参考来源 [1] DAMA International,《数据管理知识体系指南》(DMBOK2) https://dama.org/learning-resources/dama-data-management-body-of-knowledge-dmbok/ [2] GB/T 36073-2025《数据管理能力成熟度评估模型》(DCMM 2.0) https://openstd.samr.gov.cn/bzgk/std/newGbInfo?hcno=22559F9C7BF9EAC6A3927223FE33CE20

"我们数据治理做了两年，制度出了一摞，标准定了上百条。上个月业务部门开会，销售总监当着所有人的面说：'你们那套东西跟我们没关系，我们该用Excel还是用Excel。'" 这话来自一位制造业CDO。不是治理没做——做了。不是中台没建——建了。但业务部门不认。 这是典型的"治理与业务两张皮"：治理团队觉得自己在做正确的事，业务部门觉得你们在给我添麻烦。怎么破？ 国家标准GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0）将"数据治理"列为核心能力域之一，要求建立数据治理组织架构与制度体系[1]。标准提供了骨架，但治理能否落地、能否与业务共振，取决于组织如何把制度转化为业务可感知的价值。 根因1：认知偏差——业务觉得"被管"而非"被帮" 大多数数据治理的出发点是对的：统一标准、管控质量、规范流程。但落地方式出了问题——当治理以"管控"的姿态出现，业务的反应一定是抵触。 比如数据标准推行时，治理团队拿出一套命名规范，要求各业务系统按新标准改造。对业务部门来说，这意味着额外的工作量、系统改造风险，以及——"改完了对我有什么好处？"这个问题没人回答。 治理的本质不应该是管控，而是赋能。赋能的意思是：你不需要额外做什么，但你能得到更好的结果。 国际数据管理协会（DAMA）在《DAMA数据管理知识体系指南（DMBOK2）》中强调，数据治理必须遵循"业务驱动"（Business-driven）原则——数据治理是一项业务管理计划，其战略应由企业业务战略驱动，并嵌入到业务流程之中，而非作为独立的管理层级叠加于业务之上[2]。 根因2：流程脱节——治理动作和业务操作是两层皮 更常见的问题是：治理团队制定了一套完整的数据标准和质量规则，但这些规则停留在文档里、平台上，跟业务人员的日常操作毫无关系。 业务人员每天还是在ERP里录入数据，在CRM里跟进客户，在Excel里做报表。他们的数据行为没有受到治理体系的任何正面影响——反而可能因为标准变更被要求重新填表。这时候治理对业务来说就是纯负担。 根因3：价值滞后——投入看不到短期回报 治理的成果通常体现在"未来"：数据质量提高了、跨部门协作更顺畅了、分析结果更可信了。但业务部门等不了"未来"——他们要的是这个季度的数字、下周的报表、明天的订单。 当治理投入短期内只带来"约束"而不带来"收益"，业务部门自然会认为"这是IT部门的事，跟我没关系"。 解法：让治理服务化，业务无感接入 核心思路是：治理不应该是业务需要"配合"的事，而应该是业务"感觉不到但实际受益"的基础设施。 数据资产目录让业务自助找数。 业务人员最常遇到的困境不是"数据不准"，而是"不知道有什么数据"——跨部门要一份数据需要走审批、找人、等排期。如果有一个清晰的资产目录，业务人员可以直接检索、浏览、申请，把"找数"从天级降到分钟级，治理的价值立即可见。 质量管控用旁路监测，不给业务添负担。 数据质量规则在后台并行扫描，发现问题自动定位到具体字段和记录，生成整改工单推送给对应责任人。业务人员不需要改变任何录入习惯，但数据问题被发现和修复的周期从"等出事才知道"变成了"还没用就修好了"。 数据标准统一口径，减少跨部门扯皮。 同一个"客户名称"在不同系统里叫法不同，每次跨部门对数据都要先"翻译"。标准统一之后，业务部门之间的协作摩擦自然减少——这个收益是业务能直接感受到的。 两个实践案例 一家面料贸易企业（企业名称已脱敏，下同）面临的就是典型的"两张皮"问题：PLM、ERP、MES、仓储系统各自为政，跨境工厂数据割裂。他们没在治理制度上花太多时间，而是先把订单相关的数据通路打通，用数据标准统一字段口径，质量规则持续监控。系统间数据自动流转后，跨境业务协同效率显著提升。业务部门感受到了价值，治理推动就不再是阻力。 另一家国控集团在建设数据中台后，统一数据视图让国有企业运营全貌清晰可见，自动化质量管控杜绝数据错漏，项目统计显示业务人员工作量明显下降。同样——不是在管业务，而是在帮业务。 打破"两张皮"的钥匙不在治理本身做得多深，而在能不能让业务先用起来、先感受到价值。龙石数据中台等产品正是围绕这套逻辑——资源目录配套的大数据门户让业务自助找数，旁路监测在后台无声运行，标准统一消灭口径分歧——治理是一张安全网，不是一道关卡。 常见问题 1. 业务部门就是不愿意配合，怎么办？ 不要让他们"配合"——找一个他们正在痛的点（比如跨部门找数据慢、报表数据对不上），先把这个痛点解决掉。让业务部门先尝到甜头，再谈体系。 2. 治理服务化需要多大的技术投入？ 不需要一步到位上重型平台。可以先从两个关键能力切入：数据资产目录让业务能自助检索和申请数据，旁路监测模式在后台做质量扫描不干扰业务系统。市面上成熟的治理平台已普遍具备这些能力——例如龙石数据中台的数据资产管理模块支撑资产编目和自助检索，数据质量模块以旁路监测方式运行，可以先从核心业务域做起。 3. 怎么衡量治理对业务的贡献？ 不用宏大的ROI框架。几个直接指标：跨部门数据申请周期缩短了多少、数据质量问题修复率、业务自助用数比例。这些是业务能直接感知的。 治理不是为了管住数据，而是为了让数据更好用。让业务部门觉得"这个东西确实帮到我了"——这才是打破两张皮的重要标准之一。 参考来源： [1] GB/T 36073-2025《数据管理能力成熟度评估模型》(DCMM 2.0)，国家标准化管理委员会。https://openstd.samr.gov.cn/bzgk/std/newGbInfo?hcno=5D3F6F6B8C7AD3DB5EBDD2F5A9B0B8C9 [2] DAMA International,《DAMA数据管理知识体系指南（DAMA-DMBOK2）》,第3章 数据治理。https://www.damadmbok.org/

"中台建好半年了，业务部门反馈就八个字：数据不准，不敢用。" 这是一位制造业CDO的原话。不是中台技术不行——数据集成跑通了，报表能出了，可视化大屏也亮了。但财务说"你的数和ERP对不上"，销售说"客户信息全是重复的"，运营说"算了我们还是用Excel吧"。 根源只有一个：数据质量不过关。 中台的价值是让数据可复用。但如果数据本身是脏的，复用的不是资产，而是错误——而且越复用，错得越远。下面用五个最常被问到的问题，聊聊数据质量这件事到底怎么落地。 Q1：数据质量问题到底有多普遍？ 比大多数人以为的严重得多。 华东某数据局在引入数据质量管理服务之前，做过一次摸底：各部门提交到数据资产平台的目录，初始合格率只有6.34%。这不是说数据"有点小毛病"，而是说94%的目录存在命名随意、描述缺失、字段类型错误等基础问题。业务数据里的问题更触目惊心——教育系统里"同一个学籍号对应多个学生姓名"，司法系统里"结案时间早于立案时间"。 制造企业的情况也好不到哪去。同一物料在不同系统里有三个叫法，订单表的客户名称字段有几百条空值，BOM版本号和ERP里的对不上。这些都不是偶发问题，而是系统性地存在。 结论很简单：数据质量问题不是"有没有"，是"有多严重"。大多数企业严重低估了自己数据的脏乱程度。 Q2：为什么建中台之前没发现？ 因为建中台时的关注点全在"接数据"上，没人在"验数据"。 数据集成的工作逻辑是：把ERP、MES、CRM等系统的数据搬到中台来。搬的过程解决了"通不通"的问题，但没解决"对不对"的问题。集成只管搬，搬完之后数据准不准、全不全、有没有重复——没人检验。 等业务部门实际用的时候才发现不对劲，但这时候数据已经进了中台，随下游任务扩散了好几轮。更麻烦的是，因为缺少元数据记录，出问题之后连"这数据从哪来的、被谁改过"都追溯不清楚。 Q3：怎么判断数据质量过不过关？ 国家标准 GB/T 36344-2018《信息技术 数据质量评价指标》[1]定义了六个评价维度：完整性、准确性、一致性、唯一性、时效性、可访问性。除可访问性外，其余五个维度直接影响数据的可用程度。 落到实操层面，可以这样理解： 完整性：该有的字段有没有？比如订单表里客户名称不能为空。 准确性：数据对不对？比如"结案时间"不能早于"立案时间"。 一致性：同一个数据在不同系统里是否一致？比如CRM里的客户名和ERP里的是否相同。 唯一性：有没有重复记录？比如同一张订单不能出现两次。 时效性：数据是不是最新的？比如库存数据是今天的还是上周的。 实践中，对这些维度的检查可以通过旁路监测的方式来做——质检规则不对数据入库做任何拦截，数据正常入库，质检任务并行扫描，发现问题后打标记、发告警、生成整改工单。既保证了数据流转的效率，又确保了问题可发现、可追溯。 Q4：发现问题之后怎么修？ 关键是闭环，不是打地鼠。 华东某数据局的实践提供了一个完整参考。他们的做法是建立"质量监测→发现问题→派发工单→部门修复→复验归档"的闭环流程： 常态化扫描全域数据，自动生成问题台账 点对点推送至责任部门，明确"哪个表、哪个字段、什么问题" 部门修复后自动复验，通过后归档 沉淀为问题修复知识库，同类问题不再从头摸索 经过多轮治理，各部门修复率超过93%，目录合格率从6.34%提升至94.74%，累计沉淀1000余项质量监测规则。关键是这套机制融入了日常运维，不再是"一次性运动"。 Q5：有没有轻量级的起步方案？不想一上来就上重型平台。 有。数据质量不需要重型平台起步。 如果团队规模不大、预算有限，或者只是想先摸清家底，可以先从数据体检开始——用轻量工具扫描核心业务表，看看到底有多少字段缺失、多少格式错误、多少重复记录。知道问题在哪，才知道下一步该投入多少。 龙石数据质量管理平台社区版就是为此设计的：免费可用，一行命令部署，10到20分钟就能跑起来。内置12类质检规则（空值检查、唯一性检查、格式规范性检查、一致性检查、逻辑检查等），全部可视化配置，不需要写SQL。四步完成一次完整的数据质量评测：接入数据源→自动采集元数据→配置评测规则→查看问题统计。 先做一次体检，摸清底数再决定后续投入。这条路不重，但能让你第一次真正看清自己的数据到底有多"脏"——或者多"干净"。 数据质量不是大厂的专利。目录合格率能从6.34%做到94.74%，说明只要方法和机制对，数据的"脏乱差"是可以治的。关键是先迈出第一步——先做一次体检，知道问题在哪，就成功了一半。 参考来源 1.GB/T 36344-2018《信息技术 数据质量评价指标》，国家市场监督管理总局、中国国家标准化管理委员会，2018年6月7日发布，2019年1月1日实施。https://std.samr.gov.cn/gb/search/gbDetailed?id=71F772D82DFCD3A7E05397BE0A0AB82A

"我们中台搭了快两年，ERP和MES的数据到现在还没跑通。" 这话来自一家制造业企业的CDO，说的时候他苦笑了一下。不是缺工具——Kettle、DataX都在用，开发团队也不弱。问题是每接一个新系统，光接口适配就要耗掉半个人月，而且"接完只是开始"——数据对不上、字段含义靠猜、出问题不知道从哪追。 这不是个例。在参与过的项目中，异构数据集成几乎每次都是中台建设的第一道坎，也是耗时最长的一道。 一、不是技术不够，是"接不住" 数据中台建起来，第一件事就是往里面接数据。理论上有数据集成工具就行，但现实比理论复杂得多。 首先是数据源类型多。数据库不只是MySQL，还有Oracle、SQL Server、PostgreSQL，不同版本接口行为各异。加上API对接的SaaS系统、文件交换的遗留系统、消息队列流转的实时数据——一个企业少则三五套系统，多的十几套。然后是对接技能要求高。ERP里的"客户名称"、CRM里的"客商名称"、财务系统里的"往来单位"，指向同一个东西，但集成人员得一个一个去对应。这还只是一个字段。实际情况是，一个核心业务表可能有几十上百个字段，全靠人工逐个映射，工作量极大。 江苏某自动化制造企业在建设数据中台时，光是把ERP、PLM、MES、SCADA、质量系统五套核心业务系统打通，就花了好几个月。不是技术方案复杂，而是各系统的数据字典差异太大——同样的"订单号"，在不同系统里长度、格式、含义都不完全一致。 二、接进来了，然后呢——三个根因 数据集成常见的困境是：第一阶段把数据接进来了，以为大功告成，但很快发现接进来的数据用不了。这才是真正的问题。 根因1：标准前置缺失，映射全靠人工 如前所述，字段名称不统一只是表层。更深层的问题是缺乏统一的数据标准体系——字段的业务含义、格式规范、取值范围、编码规则，如果不在集成前定义清楚，集成就变成了"硬接"。[1] 某跨区域运营的多元化产业集团旗下覆盖多个业务板块，同一个物料在不同板块间能有三种叫法，同一个供应商在多个业务系统中有独立编码。在没有统一主数据标准的情况下做集成，数据汇聚之后口径打架，报表分析全是错的。跨板块对账需要数天，数据纠纷常年不断。 根因2：元数据不跟进，血缘一片空白 比字段映射更隐蔽的问题是元数据缺失。很多人理解的集成就是把数据从一个系统搬到另一个系统——但搬的过程做了什么转换？原始数据是什么？被谁在哪一步改过？这些信息如果没有记录，后续出了任何问题都无法溯源。 没有元数据管理的数据中台，就像一个没有库存清单的仓库：东西都放进去了，但不知道放了什么、从哪来的、什么时候入库的、有没有被人动过。数据量的增长反而加剧了混乱——仓库越大越找不到东西。 根因3：质量校验缺位，数据进来了却没人管质量 这是最典型却最容易被忽略的问题。集成只管"搬"，搬完之后数据对不对、全不全、重不重——没人检验。字段缺失、格式错误、逻辑矛盾这类问题在集成阶段没有被发现，等业务部门用数据做分析时才发现结果离谱，回头追溯已经过了好几手。[2] 江西某国控集团在建设中台前，10余套业务系统的数据缺乏统一的质量管控——财务数据填报错误、投资项目信息缺失、指标口径不一致，监管决策的依据本身就不可信。这些问题不解决，集成的数据越多，错误放大的范围就越大。 三、四个常见误区 误区1：把集成当纯技术活。 认为选对工具就能搞定——DataX不行换Kettle，Kettle不行换Flink。但实际上异构数据集成的瓶颈不在传输性能，而在业务语义的对齐。没有数据标准的集成工具，就像一个翻译软件只懂语法不懂语境。 误区2：等全接完了再治理。 不少团队的思路是先把所有系统的数据汇聚进来，后面再统一治理。问题在于，数据一旦入库，错误就会随着下游任务扩散——等发现的时候已经分不清哪些数据是干净的、哪些经过了污染。集成和治理更适合并行推进，而非先后串行。 误区3：追求"一键接入"。 任何做过系统对接的人都明白，现实中没有真正的一键接入。每个系统都有自己的历史包袱和业务特殊性，对接过程必然需要业务人员参与确认语义、校验口径。工具可以减少重复劳动，但不能替代业务对齐。 误区4：忽视元数据。 规模越大越需要元数据。如果不知道数据从哪来、谁改过、给谁用，数据中台很快就会变成一个巨大的"黑箱"——所有人都在往里放数据，没有人知道里面到底有什么。 四、解决路径：集成与治理并行 核心思路一句话：数据的采集和治理不是先后关系，而是并行关系。[3] 数据集成负责归集，不拦截数据。 数据中台通常不建议在采集链路中修改或拦截数据——数据原样入库是行业实践中较为稳妥的做法，便于后续审计追溯。如果在采集链路里做格式转换或校验阻断，出了问题难以排查：是源端数据本来就有问题，还是中间转换环节改了数据？ 治理在入仓后立即启动。 数据进入中台后，数据标准模块做字段到业务语义的映射对齐——不是在采集链路中硬性转换，而是在治理层建立标准与源数据的对照关系。同时元数据自动采集，让每张表、每个字段都有来源、有去向、有变更记录。 质量管控用旁路监测模式。 这是关键。质检规则不对数据入库做任何拦截——数据正常入库，质检任务并行扫描，发现问题后打标记、发告警、生成整改工单，定位到具体表、具体字段、具体记录。比如你发现某张订单表的"客户名称"字段有300条缺失，系统告诉你是哪300条，而不是阻塞整张表不让入库。这种模式既保证了数据流转的效率，又确保了质量问题可发现、可追溯。 质量前置是可选的增强做法。 如果你想更早发现问题，可以在集成前对源端数据做一轮检测——摸清源系统数据的质量底数，有问题的先让源头系统修复再进入中台。这不是必需的步骤，但对数据质量要求高的场景非常有效。 五、实践中怎么落地 江苏某面料贸易企业在做数据集成共享时就采用了这样的思路。这家企业的PLM、ERP、MES、外贸订单、仓储系统各自为政，跨境工厂数据割裂。他们没有追求一步到位，而是先解决核心链路——把订单相关的数据通路打通，同时部署数据标准管理统一字段口径，用质量规则持续监控数据完整性和一致性。系统间数据开始自动流转后，跨境业务协同效率显著提升。 这种做法和龙石数据中台的产品逻辑是一致的：数据通过集成模块归集后，数据质量模块以旁路监测方式对入库数据做质量扫描——不需要改采集链路，质检规则可视化配置，发现问题自动告警。标准管理模块统一数据口径，元数据自动采集构建血缘，资产目录让数据资产可查可用。也可以在数据进中台前，先对源端做一轮质量检测，复核数据质量修复效果。 简单说就是八个字：数据照进，质量并行。 六、常见问题 1. 我们已经有了ETL工具，还需要数据中台的集成能力吗？ 工具能搬数据，但不能管数据。中台的价值不在"搬"，而在搬完之后——数据质量有没有保障、标准是否统一、血缘能不能追溯。如果只是想先摸清手头数据质量到底怎么样，龙石数据质量管理平台社区版免费可用，一行命令部署十来分钟就能跑起来，先做一次数据体检。 2. 异构数据集成的最大成本在哪里？ 不是工具采购，是人力和时间。每个新系统的字段映射需要业务人员参与确认语义，这无法自动化。统一数据标准能从根本上降低每次集成的对接成本。 3. 实时集成和批量集成怎么选？ 看业务需求。监管报表可以T+1生成，但订单交付状态追踪需要准实时。关键是中台要能同时支持两种模式，而不是二选一。 4. 集成完数据后发现质量不行怎么办？ 这正是旁路监测要解决的问题——数据正常入库，质检规则并行扫描，发现问题定位到具体表、具体字段、具体记录。可以打标记、发告警、生成整改工单，而不是简单粗暴地拦截入库。 参考来源 [1] 国家标准化管理委员会，《数据管理能力成熟度评估模型》（GB/T 36073-2025，DCMM 2.0），https://std.samr.gov.cn/gb/search/gbDetailed?id=71F772D82C6CD3A7E05397BE0A0AB82A [2] 国家标准化管理委员会，《信息技术 数据质量评价指标》（GB/T 36344-2018），https://std.samr.gov.cn/gb/search/gbDetailed?id=71F772D82DFCD3A7E05397BE0A0AB82A [3] DAMA International，《DAMA数据管理知识体系指南》（DAMA-DMBOK），https://www.dama.org/learning-resources/dama-data-management-body-of-knowledge-dmbok/