作者：小陆 说明：本文系基于Palantir官方技术文档、行业研究报告及公开媒体报道等公开资料，所做的综合性梳理与推演、探讨。 序章：历史性失败 2001年9月11日，美国梦破碎了，属于美国的20世纪画上了句号。 早晨，19名隶属于基地组织的恐怖袭击者劫持了4架民航客机，分别撞上了世贸中心双子塔、五角大楼，还有一架坠毁在宾夕法尼亚的田野。 这是一个屈辱的日子，文明灯塔骤然摇摇欲坠。然而主谋本·拉登未曾料到，他原以为联邦会在袭击后如苏联般支离破碎。9月14日，小布什总统站在废墟之上，喊出那句“那些推倒这些建筑的人，很快就会听到我们所有人的声音”，美国竟意外达成了前所未有的团结，总统支持率飙升至历史峰值。 历史的进程仿佛就此改写，美国正式开启了反恐战争。然而，这场战争并未如预期般速战速决。阿富汗战事绵延二十年，而那个名为奥萨马·本·拉登的元凶，却如同人间蒸发。 在美国情报系统的视野里，除了拉登偶尔发布的挑衅录像，他的名字变成了一堆散落的、难以追踪的碎片。这些碎片，如同双子塔倒塌时的尘埃，毫无意义，却日夜刺痛着美利坚最脆弱痛苦的神经。 2003年至2004年的911委员会听证会上，主席基恩与副主席汉密尔顿公开坦言：这或许本是一场可以避免的袭击。 一份迟来的报告——《911委员会报告》 *信息来源于《9/11commission report》 报告揭示了残酷的真相：由于情报处理系统的落后，美国多次错失良机。数据并非匮乏，而是无法拼接。911的预警信号如同写在白纸上的字迹，静静地躺在美国多个互不相通的数据库里，却无人能将它们拼凑成完整的情报。 致命的失误（五个场景） 场景一：明尼苏达的电脑 2001年8月，明尼苏达州潘姆飞行学院，教官们对一个名叫扎卡利亚·穆萨维的中东学员感到不安与怀疑——他几乎没有大型客机驾驶基础，却希望直接接受波音747模拟机训练。8月16日，穆萨维因签证违规被捕。当地FBI分局嗅到了危险，申请搜查其笔记本电脑，却两次被华盛顿总部驳回，理由是无法证实其与境外势力的联系。那台电脑，直至911之后才被解锁。 场景二：凤凰城的备忘录 一个月前的7月10日，FBI凤凰城分局探员肯尼斯·威廉姆斯写下内部通报，警告基地组织可能正批量派遣人员赴美学开客机，并附上了排查方案。然而总部大笔一挥，标为“不用跟进”。直到双子塔倒塌，那两位主管也未曾翻阅过这份文件。系统无法自动识别“大批中东人扎堆学开飞机”的危险可能，更无法在穆萨维落网时，将其与一个月前的预警自动匹配。 场景三：汉堡与圣地亚哥的割裂 2000年，阿塔、谢希、贾拉——三位未来的劫机者，属于同一密谋组织——汉堡细胞，持真名与旅行签证从容入境。美国的移民数据库与反恐名单完全割裂，三人甚至未触发任何警报。直到911后，SEVIS（学生与交流访问学者信息系统）这类联动机制才被迫催生。监控者与行动者，被隔在两个互不通话的房间里。 场景四：吉隆坡—曼谷—加州的断线 2000年1月，CIA在吉隆坡拍下了两名劫机者与“科尔”号爆炸案主谋哈拉德同时出现的照片。然而照片既未录入观察名单，也未通报FBI。1月15日，哈兹米飞抵洛杉矶，CIA知情却未声张。两人随后住进了圣地亚哥一名FBI线人的家中，而当地FBI对此毫不知情。直到2001年8月24日，两人才被列入观察名单，而搜查指令竟拖延至8月28日才发出，距灾难仅剩两周。系统缺乏“本体论”思维，无法将“吉隆坡参会者”、“外国入境旅客”、“线人的房客”归为同一实体。 场景五：亚丁港的爆炸事件 2000年10月，哈拉德策划了“科尔”号驱逐舰爆炸案，致17名美军丧生。他的名字早已在案，却未被关联到吉隆坡合影中的那两人。由于缺乏“本体”概念，系统无法将“参会者”与“炸舰者”合二为一，警报从2000年推迟至永远。 灾难当日 911当天，数据治理的缺失再次产生恶果。8:19，华裔空乘邓月薇报警，信息却未能高效同步。8:46，第一架飞机撞塔，白宫尚不知飞机被劫。布什总统在佛罗里达的小学里，听到的只是“小型飞机事故”。副总统切尼在办公室看着电视，眼睁睁目睹第二架飞机撞向南塔。FAA内部混乱不堪，局长甚至在电视画面之前对劫机一无所知。 结论 导致911的，不是情报收集的匮乏，而是数据治理的失败，是连接的失败。报告中美国认为的药方是“去中心化网络”，设立国家情报总监（DNI）与国家反恐中心（NCTC），打破部门壁垒。 在2004年12月17日，布什总统签署了《2004年情报改革与防恐法》。这是1947年以来情报界的最大变革：设立DNI统管各情报机构，成立NCTC作为跨机构中枢，并强制要求从“需要知道”转向“需要分享”。这套法律体系，正是治理层面的“本体化”雏形。 国家背后的帮手：Palantir *信息来源于 BBC 科技专题报道、行业大数据研究报告、《纽约杂志》2020 年深度调查，以及Palantir官方网站文章 Palantir 诞生于 2003 年，它的精神胚胎也就是 9·11事件，2003 年，蒂尔投入第一笔启动资金，联合亚历克斯·卡普、乔·朗斯代尔、斯蒂芬·科恩等人共同创立 Palantir。公司之名源自指环王的真知晶石，公司里有哲学和PayPal的复合血脉。 外界常将Palantir误解为一台输入“本拉登”即输出“阿伯塔巴德大院”的GPS定位仪。事实并非如此。Palantir的Gotham平台，做的是将散落在多系统的碎片，融合成“关系网+时间轴+地理空间”的复合画像。 根据 Palantir 官方文档定义，其核心技术被称为“本体论”（Ontology），即“对世界的分类”。官方将其定位为组织的数字孪生，这是一个位于集成数据集与模型之上的语义层（semantic layer）。该架构通过将数据映射为对象类型（object types）、属性（properties）、链接类型（link types）和动作类型（action types），构建出组织运营的完整图景。Palantir官方明确指出，Ontology 的设计初衷是表达企业复杂且相互关联的决策，而不仅仅是数据。值得注意的是，卡普拥有法兰克福大学新古典社会理论博士学位，福布斯等外界媒体亦指出产品名称“Ontology”与哲学术语存在关联，但 Palantir 官方从未公开声明其技术架构直接源于哲学理论。 2005年，CIA旗下投资机构向Palantir注资200万美元，使其成为CIA此后三年的唯一客户。随后，NSA与FBI也相继成为其客户。尽管CEO卡普对本·拉登行动细节避而不谈，但《纽约杂志》2020年的调查指出，Palantir被广泛认为在长达十年的追捕中提供了关键辅助。 本体论与数据：从哲学到实践 本体论源于哲学，研究存在及其范畴关系。互联网时代，计算机科学家借用了这一概念，用以描述如何将现实世界映射到数字空间。简而言之，它是构建结构化模型，让分散的数据能被理解、连接和使用，而非仅是孤立的堆积。而皮特和卡普都是哲学训练出身，Palantir 从一开始就不是一家普通的硅谷大数据公司，而是带着强烈的哲学气质 。他们从哲学本体论出发，建立出了自己的一套数据治理的本体理论——ontology，也就是我们常说的palantir的本体论。 Palantir的工程化落地 *信息来源：Palantir官方文档 Palantir所希望达成的，简单来讲是让按真实世界建模的虚拟世界模型反过来改变现实。其系统架构核心分为三层： 第一层：语义元素（Semantic Layer）——定义“是什么” 这是系统的地基。通过对象（Object）、属性（Property）和链接（Link）统一描述业务实体。 对象：人、组织、地点、设备等。 属性：姓名、国籍、经纬度等特征。 链接：隶属、发生于、驾驶等关系。 在情报工作中，这意味着“吉隆坡参会者”、“入境旅客”、“线人房客”不再是四条孤立记录，而是同一“Person”对象的不同面。 第二层：动力元素（Kinetic Layer）——定义“怎么做” 语义层定义了静态世界，动力层则赋予系统执行力，包含动作（Actions）和函数（Functions）。 如果说语义层是名词，动力层就是动词。它规定条件触发时的操作逻辑： 检测到可疑通话，自动发出追踪指令。 识别特定区域异常人员聚集，自动触发“潜在袭击”警报。 发现“吉隆坡参会者”入境，自动推送情报至分析师。 这使得系统从静态档案库变为实时作战图。 第三层：动态决策与四重集成 系统通过数据（Data）、逻辑（Logic）、行动（Action）、安全（Security）的四重集成实现动态决策： 数据：汇聚多源信息。 逻辑：运行业务规则与算法。 行动：执行工作流并回写系统。 安全：全程细粒度权限控制。 这构成了“组织的数字孪生”，将法律层面的“需要分享”转化为技术层面的“实时协同”。 关于“海神之矛”的推测 *基于公开能力的推演，非已证实事实 注：以下内容是基于Palantir公开技术架构的合理推演，非官方确认的事实。 本拉登在阿富汗躲过追捕以后，完全隐蔽了起来，反侦察能力强，使用信使物理传话，抓捕行动也因此一直推迟。 2010年，一个名为“科威特人”的信使犯下了致命失误——使用了电子设备通信，使其从抽象名字变为可追踪节点。这正是本体论发挥效用的时刻： Object（实体归一）：系统将CIA的吉隆坡记录、FBI的签证信息、NSA的加密通话记录、卫星影像中的白色铃木SUV，归并为同一“科威特”对象。 Property（刻画特征）：系统标记其静态属性（身份：核心信使）与动态属性（仅接听不呼出、活动半径超500公里、车辆夜间出行占比高）。每新增一条异常，系统自动上调其风险置信度。 Link（连点成网）：系统建立语义链接：科威特─接听─加密通话；科威特─驾驶─白色SUV；SUV─停靠─阿伯塔巴德大院；大院─焚烧─垃圾（异常）。通过贝叶斯逻辑持续修正，多条证据叠加，系统判定大院藏匿高价值目标的概率趋近于确定。 Action（从研判到行动）：当置信度达标，系统自动标记目标，同步至CIA与军方系统，生成侦察工单与突袭预案。经审批链核准后，指令下达，行动结果回传系统，沉淀为新研判规则。 *AI生成的模拟概念图（置信度都为虚构） 如图所示，从完整复杂网络里可以筛选出一个完整的事件，该事件是现实世界的映射，该事件的置信度可以通过统计学工具计算。 一个假设：假如十年前美国情报部门就用了本体论 假如2001年就有Palantir的本体论，改变的绝非仅是多抓几个恐怖分子，而是整个情报链路的重塑。回顾那些致命失误： 7月10日：凤凰城备忘录提交瞬间，语义层自动提取“飞行学校+极端分子属性”，关联全国注册记录，而非沉睡两月。 8月16日：穆萨维被捕瞬间，动力层函数识别”高风险+飞行学校+关联凤凰城“模式，自动触发紧急搜查申请，而非驳回申请。 8月23日：CIA通报嫌疑人入境瞬间，地理空间函数自动匹配圣地亚哥电话簿，快速派遣核查，而非任其在眼皮底下潜伏19天。 8月底：嫌疑人列入监视名单瞬间，动作类型自动生成禁飞名单条目提交到相关部门，而非遗漏登机。 911委员会认为事件并非不可避免。本体论的推演表明，至少5至6次错失的机会可被挽回。这并非魔法，而是“连接”的胜利。当吉隆坡的“Khalid”、FBI未知的“Khalid al-Mihdhar”、FAA空白的观察名单，在本体论的语义空间中相遇时，9·11报告中“连接的失败”才有了真正的工程化解药。IRTPA在法律层面要求连接，Palantir在技术层面实现连接，这便是本体论给予后世最深刻的教训。
采购计划员拿到两份报价单：供应商报的是"钛白粉R996"，仓库的领料单上写的是"R-996"，到了配方系统里，它又变成了"996"。同一个东西，三个名字。为了确认这三份单据指向同一种原料，他花了半小时打电话、翻台账——而这半小时，只是制造企业每天无数个"对名字"动作里的一个。 一物多码不是编码问题，是治理问题。物料编码是制造业数据的"身份证"，编码不统一，采购、库存、成本、质量、供应链分析全部对不上。对正在建设高质量数据集、推进AI应用的企业来说，这个问题更紧迫：实体标识不统一，数据集就无法构建，AI模型也无法稳定解析——把各系统数据"拉出来堆在一起"只是数据集建设的第一步。一物多码的背后，涉及物料分类、编码规则、数据责任、历史清洗、跨系统分发五个层面，任何一个层面缺位，治理都会落空。 一、一物多码：制造业数据治理的第一道坎 制造业是系统密度最高的行业之一。ERP管采购和财务，MES管生产执行，WMS管仓储，PLM管研发设计，配方系统管工艺……每个系统都有一份自己的物料档案，编码规则却各自为政。同一种物料，采购系统按供应商名称编，设计系统按图纸号编，车间按自己的习惯编。久而久之，"一物多码"与"多物一码"并存——前者是同一个物料对应多个编码，后者是不同物料共用一个编码，两条线都在污染数据。 三个场景能说明一物多码的代价。 集中采购推不动。 某大型综合制造集团的采购中心曾长期面临一个尴尬：各子公司报上来的采购需求用的是各自的物料编码，采购中心要先花大量时间"翻译"——哪些是不同的物料，哪些是同一个物料叫了不同的名字。等翻译完，采购窗口也过了。集中采购的规模优势，就这样被编码差异一点点吃掉。 成本核算对不上。 同一类原材料，A子公司记在"原材料-化工类"，B子公司记在"辅料-生产用"，C子公司干脆没分类。集团想做全集团的物料成本分析，第一步是"认谁是谁"，而这个工作量几乎是天文数字。 批次追溯难。 跨系统的物料批次无法自动关联，追溯靠人工映射。一家精细化工企业曾有类似的经历：一批产品出现质量波动，质量部门要把原料批次、工艺参数、检验记录手工串起来找原因，一次批次数据整理要花半天。 很多制造企业以为自己缺的是系统，实际最大瓶颈往往是数据无法形成统一链路。再先进的MES、再漂亮的看板，底层物料编码对不上，跨系统的数据就关联不起来。在数据管理能力成熟度评估（DCMM 2.0，GB/T 36073-2025）[1]中，数据标准域的能力项——业务术语、主数据、参考数据、数据元、指标数据——指向的正是这套基础工作；DAMA-DMBOK 2.0[3]也把参考数据与主数据管理列为数据管理的基础能力领域。行业里普遍把主数据管理归入治理体系的"管"阶段：物料、客户、供应商等核心实体统一了，数据才谈得上管得住、用得好。需要说明的是，制造业场景中数据管理能力看DCMM，智能制造能力看CMMM（GB/T 39116-2020），两者各有侧重，主数据治理属于前者。 对AI应用而言，这一关更关键。智能采购、供应链预测等场景的第一步，是跨系统关联数据——历史采购量、库存、价格、供应商、质量表现——而关联的前提，是所有系统对同一物料使用同一标识。一物多码不解决，AI读到的"同一个物料"是几个不同的名字，预测和推荐都会失真。GB/T 36344-2018[2]定义的六个数据质量评价维度中，规范性、一致性等维度直接决定模型能否稳定解析、跨系统能否准确关联，一物多码恰恰破坏了这些维度，使数据集达不到"可训"的标准。主数据与数据标准，是AI应用的数据底座。 二、一个典型场景：钛白粉的三个名字 具体到一家企业，一物多码长什么样？华东某精细化工企业（流程制造，年产能超20万吨，生产环保涂料、树脂及助剂）的经历很有代表性。 这家企业的同一原材料"钛白粉"，在采购系统里叫"钛白粉R996"，在配方系统里写成"R-996"，到了质检系统又被简化为"996"。三个系统，三个名字，数据源头各不相同。设备编号同样混乱：DCS里的反应釜编号，与MES工单里的设备字段对不上。主数据不统一，批次追溯时无法自动关联物料批次和设备参数，大量工作靠人工映射。前面提到的那次"半天整理一次批次数据"，就发生在这家企业。 龙石顾问进场后的第一判断很直接：流程制造的数据治理，必须从主数据开始。物料编码不统一、设备编号不一致，后续的批次追溯、工艺分析都会遇到严重障碍。企业需要先为每一类原材料、每一台设备、每一道工序建立统一的数字身份，才能谈批次关联、参数分析和智能优化。 这并非孤例。某大型综合制造集团的情况如出一辙：ERP物料主数据重复率高，"一物多码"与"多物一码"并存，采购、库存、生产、财务模块的数据因编码不一致无法关联。集中采购"翻译"各子公司清单、成本核算"认谁是谁"，问题比精细化工企业更大——几十套编码体系并存，物料数据总量达到数十万级。 三、怎么治：从标准、清洗到分发 治理路径说起来不复杂：统一标准、唯一标识、持续运营。做起来，每一步都有讲究。 先是梳理核心主数据实体。这家企业从原材料、中间体、成品、设备、工序、计量单位入手，制定统一的业务术语与编码规则，并明确每种主数据的归属部门——物料编码谁维护、改了通知谁、历史记录谁认，这些问题在项目一开始就要有答案。出乎意料的是，项目最大的障碍不在技术，而在"理"：跨部门认责。编码规则的技术实现很快，但让采购、生产、质检各自让渡一部分"命名权"，需要一轮轮沟通。 然后是清洗历史数据。采购、生产、质检系统中的记录被逐条比对，合并为唯一的"黄金记录"，并建立编码映射表，让新旧编码在过渡期内共存。这一步漫长且不可跳过。某大型综合制造集团在治理时专门走过四段：摸清家底、建标准定规则（覆盖数十个大类、数百个小类）、清洗数据（数十万条物料逐条比对、去重、重新编码）、系统固化。参与项目的负责人说过一句话："这一步不完成，后续所有工作都是空中楼阁。"同样走完这条路的华东某电子制造企业，其物料数据量已达百万级，清洗去重后采购、生产和财务才真正用上了"同一本账"。 再往后是跨系统分发。当技术部新增一种原材料时，编码自动同步至ERP、MES、LIMS，所有系统使用同一标识。数据在源头一次录入，向各系统分发，而不是每个系统各自维护一份——这正是"唯一数据源"原则的落地。 在统一主数据的基础上，企业建立了"原料批次—生产工单—反应工序—工艺参数—质量检验—成品批次"的六层数据模型，为每个中间体、每道工序、每个质量指标定义统一编码与计量单位。某批次产品出现质量异常时，通过批次ID即可一键关联所用原材料批次、各工序、操作人员和检验数据。 治理成果在这一步开始转化为AI可用的数据底座：统一编码加上标准代码集、六层模型，使每批产品的原料、工艺、质检数据可以跨系统一键关联。质量波动分析、配方优化、采购预测等AI应用，从此有了干净的训练与推理数据。 这个过程里，平台工具承担的是固化工作。主数据管理模块完成编码统一、数据清洗与映射、跨系统同步；数据标准管理维护代码集与属性模板；数据质量管理负责唯一性校验——新增物料时自动校验是否已存在类似物料，避免重复编码继续累积——并以旁路监测方式并行扫描存量数据，不影响业务系统正常运行。集团型企业还可以借助"一集团一中台、一公司一空间"的工作空间模型，在统一标准管控与子公司自治之间取得平衡。 配套的还有能力转移。项目采用"培训+陪跑"的方式：培训阶段在龙石公司集中进行，理论、模拟、实操三层递进；进入现场的陪跑阶段，顾问团队选定一个真实业务域，与客户团队一起跑——指导归指导，每一步都由客户团队自己动手完成。目标不是"帮你把数据治好了"，而是"你们自己能治了"。 四、效果：从"对名字"到"一物一码" 治理完成后的变化，可以用几组前后对比来说明： 批次数据整理：从半天到几秒。* 批次追溯不再需要人工映射，系统自动关联原材料批次、设备参数、检验记录。 批次间质量波动（粘度、固含量）：降低40%。* 工艺参数标准化后，同一配方不同批次的指标趋于稳定。 客户质量投诉率：下降60%。* 批次一致性提升，质量不稳定引发的投诉大幅减少。 新配方研发周期：从6个月到3个月以内。* 基于历史批次的工艺参数与质量结果建立相关性分析模型，工程师能快速找到最优工艺区间。 外部案例验证了同样的逻辑。某大型矿业集团完成主数据治理后，"一物多码"问题基本消除，建立起覆盖数万条物料、上万条客户供应商的标准化代码库，集团层面的经营统计与财务合并有了统一的基础数据支撑。前述综合制造集团的集中采购物料匹配效率明显提升，跨子公司的成本核算口径实现了统一。 客户原声最有说服力："过去我们的生产更多依赖经验，配方调优靠试错，质量波动难以解释。现在通过这套体系，把每一批产品的原料、工艺参数和质量结果都串联起来，很多问题可以用数据说清楚。" 治理成果还直接转化为AI场景的落地条件。智能采购：统一物料编码后，各系统、各子公司的采购需求按同一标识自动汇总，采购中心无需再"翻译"清单；基于统一的历史采购数据，价格比对、供应商评估、采购量预测有了可靠依据。供应链预测：六层模型打通原料批次—工单—质检链路后，历史消耗、库存、质量波动数据可跨系统关联，需求预测与排产预测不再是无源之水。此时再看高质量数据集建设：2024年初，《"数据要素×"三年行动计划（2024—2026年）》[4]把工业制造列为重点领域，高质量数据集正是该行动落地的基础工程——统一标识的物料主数据已成为智能采购、供应链预测等应用的可信底座，数据集建设从"拉数"进入"可信"阶段；数据治理成果（标准、质量、主数据）将原始业务数据转化为模型可直接使用的训练集，能节省70%以上的数据准备工作量。 五、三点启示 回顾这些案例，有三点启示值得同行参考。 先治主数据，再谈数据应用与AI。 物料编码不统一，上层分析是沙上建塔，智能采购、供应链预测更是无从谈起。主数据与数据标准是数据治理的第一道关口，也是AI应用的数据底座。很多企业急于建大屏、上AI，而底层编码尚未统一——先把基础打牢，后面的路会顺很多。 主数据管理的本质不是管控，而是服务。 它的核心价值是"唯一数据源"——让每个业务系统都能从一个可信源头获取标准数据。这个原则一旦确立，后续的系统集成和数据分析就能少走很多弯路。 一物多码的治理是持续运营，不是一次项目。 标准要有人维护，质量要持续校验，分发要形成闭环。组织与机制缺一不可：专责岗位、审批流程、校验规则，缺了任何一环，编码会重新乱回去。这也是为什么越来越多的企业把主数据治理纳入常态化运营，而不是当一次性项目做完就散。从实践看，"产品+培训+陪跑"的组合——平台负责固化规则，培训与陪跑负责让企业自己接得住——是让治理成果持续下去的一种稳妥方式。 治理之后，同一物料在所有系统中只有一个名字——这个"唯一名字"正是高质量数据集的最小单元。数据集建设从"数据汇总"走向"可信、可训"，AI应用才能从演示走向业务一线。对大多数制造企业来说，这一步从统一物料编码开始，是最稳妥的起点。 六、常见问题 Q1：一物多码和多物一码有什么区别？哪个危害更大？ 一物多码是同一个物料对应多个编码，表现为数据重复、对账困难；多物一码是不同物料共用一个编码，表现为数据混淆、统计失真。两者的危害侧重点不同：一物多码抬高对账和协同成本，多物一码直接扭曲成本与库存统计。都需要靠唯一性校验从源头控制——新增物料时自动比对是否已存在类似物料，把重复编码挡在入口之外。 Q2：治理应该从哪类物料切入？所有物料类型一起治吗？ 从业务影响最大的切入。原材料和关键物料通常最复杂，也最能见到效果，先跑通，再扩展到半成品、成品、备品备件。综合制造集团的经验是先治物料、再扩展客户、供应商、组织等其他主数据对象；矿业集团则选择优先做透对经营分析影响最大的几类主数据。小步快跑优于一步到位，用阶段性成果推动更大范围的覆盖。 Q3：存量数据清洗周期长，能不能先上系统再清洗？ 不建议绕开。清洗存量数据是系统上线的前提——很多企业绕开清洗直接上系统，结果系统上线后数据照样乱。把存量数据理清楚，看似慢，实则是唯一的快；配合编码映射表让新旧编码过渡期共存，可以降低清洗阶段对业务的影响。 Q4：主数据统一后，各业务系统要跟着改造吗？ 分阶段过渡。先建编码映射表，让新旧编码共存，再逐步推动各系统切换使用统一编码；分发机制确保新增数据源头唯一——源头一次录入，各系统同步获取，不需要每个系统各自维护一份编码档案。 Q5：单工厂、中小企业也需要做物料主数据治理吗？ 需要，只是颗粒度不同。只要有多个业务系统、有跨部门对账，就存在一物多码的风险。可以从一个核心物料大类、几条校验规则起步，不必一上来就搭全套体系；随着业务系统增多再逐步扩充。 Q6：一物多码治理和智能采购、供应链预测这些AI应用有什么关系？ 直接关系。AI场景的第一步是跨系统关联数据——历史采购量、库存、质量、供应商——而关联的前提是所有系统对同一物料使用同一标识。一物多码不解决，AI读到的"同一个物料"是几个不同的名字，预测和推荐都会失真，这正是GB/T 36344[2]一致性维度要解决的问题。主数据与数据标准治理的成果，就是AI应用的训练与推理底座。如果希望用工具把标准、清洗、分发、校验串成一条链路，部分数据治理平台已具备主数据管理能力（如龙石数据中台），可以从一个物料大类试点起步。 参考来源 [1] 国家市场监督管理总局、国家标准化管理委员会，《数据管理能力成熟度评估模型》（GB/T 36073-2025，DCMM 2.0），2025年发布，2026年7月1日实施 — openstd.samr.gov.cn [2] 国家市场监督管理总局、国家标准化管理委员会，《信息技术 数据质量评价指标》（GB/T 36344-2018）— openstd.samr.gov.cn [3] DAMA International. DAMA-DMBOK: Data Management Body of Knowledge (2nd Edition). Technics Publications, 2017. [4] 国家数据局等十七部门，《"数据要素×"三年行动计划（2024—2026年）》，2024年1月 — gov.cn
某企业数据治理项目立项，两份方案摆在了决策桌上：数据质量厂商推荐独立部署一套数据质量管理平台，数据中台厂商则说"中台自带质量模块，不需要重复采购"。预算有限，治理团队内部为此讨论了好几轮——质量团队担心模块能力不够深，中台团队担心重复建设。 这个场景在 DCMM 2.0（GB/T 36073-2025）[1] 实施后越来越常见。两类方案不是简单的"谁替代谁"，而是定位不同、能力边界不同、适用场景不同。选错带来的不只是预算浪费，后续治理的深度和运营方式都会受牵连。本文从六个维度给出对照框架，供读者结合自身情况判断。 一、DCMM 2.0 对数据质量的要求，先说清楚"要什么" DCMM 2.0 于 2026 年 7 月 1 日正式实施，在其九大能力域中，数据质量域包含四个能力项：数据质量需求、数据质量检查、数据质量分析、数据质量提升[1]。注意一个容易被忽略的细节——"检查"只是四个环节之一。 这意味着标准要求的质量管理是一个体系，而不是一个检测工具。只看"能不能检测问题"，与标准要求的差距是比较明显的。从企业实践看，很多质量项目恰恰卡在这里：规则配了不少，告警每天在出，但问题认领、根因分析和流程改进长期缺位，质量问题反复出现。 在定义"什么算好数据"时，GB/T 36344-2018《信息技术 数据质量评价指标》[2] 提供了起点：规范性、完整性、准确性、一致性、时效性、可访问性六个维度。六个维度除可访问性外，其余五个直接影响数据应用效果，也是质量需求定义时被引用较多的框架。 先谈标准，是因为选型的前提是明确目标：如果只是要"检测问题"，两类工具都能做到；如果要建的是覆盖需求、检查、分析、提升四环节的体系，评估重点就完全不同。截至 2025 年 11 月，全国已有超过一万家企业完成 DCMM 贯标评估[4]，贯标实践中数据质量域往往是差距较大的能力域之一，原因多半不是没有规则，而是规则与闭环之间存在断裂。另一个常被提及的判断是，数据质量是数据共享的第一前提——脏数据跨部门共享只会放大错误。 二、两类产品的定位差异 2.1 独立数据质量平台：质量为主业的"专精"型 独立数据质量管理平台把数据质量作为核心主业，能力围绕质量闭环展开：标准管理、规则创建、质量评测、问题闭环管理、质量评价。这类产品通常沉淀了可复用的规则资产——以龙石数据质量管理平台为例，内置标准库与规则库开箱即用，质量规则覆盖五大类，支持零代码可视化配置，采用旁路监测模式不侵入原始业务库，可应对百亿级数据量评测[5]。 更关键的是闭环深度：问题数据支持自动派发、源头修复、督办考核与审计追溯，全流程留痕。部分平台还提供 AI 智能评测，覆盖 DCMM 数据质量四个能力项、DAMA 数据管理知识体系与 GB/T 36344 的评价维度[5]。 独立平台的另一个特征是中立性。它以第三方视角开展质量评测，可以出具对外使用的评估报告，这在数据资产入表、数据交易挂牌、监管报送等场景中是硬需求。 2.2 数据中台质量模块：一体化治理中的"嵌入"型 数据中台质量模块是"理采存管用"方法论中"管"环节的子能力，与数据集成、标准管理、元数据管理、数据共享处于同一平台。质量不再是独立系统，而是随数据流转内嵌在治理链路里：数据标准定义了字段口径，质量规则校验数据是否符合标准，元数据记录了数据来源，质量结果又可以反馈给标准迭代。 其核心运行模式是旁路监测——数据正常入仓，质检规则并行扫描，发现问题打标记、发告警、生成整改工单，不拦截不阻断原有的数据链路。这种方式对业务系统无侵入，规则通过可视化界面配置，业务人员也可以参与。落标，即把已发布的数据标准关联到真实表字段上、检查实际数据是否符合标准，在中台里与标准管理模块天然联动。在多数中台产品中，质量规则同样支持完整性、准确性、一致性、时效性等多类检查，规则配置方式与独立平台类似，差异主要体现在规则资产的沉淀深度和问题闭环的组织方式上。 以龙石数据中台为例，质量模块作为"管"环节的一部分，随中台按需装配——可以单独启用，也可以与数据集成、标准、元数据等模块组合使用[5]。 2.3 两类形态的对照 对比项 独立数据质量平台 数据中台质量模块 定位 质量为主业的专精型系统 一体化治理中的嵌入型子模块 核心能力 标准-规则-评测-问题-评价全流程闭环 旁路监测 + 与集成/标准/元数据联动 规则体系 标准库、规则库沉淀与复用 常用质检规则，随标准管理联动 闭环深度 问题派发、源头修复、督办考核、审计追溯 检测、告警、工单、整改跟踪 中立性 第三方视角，可出具对外评估报告 内嵌于治理体系，服务于内部管理 部署成本 独立部署，需单独采购与运维 随中台装配，与现有平台共用底座 适用边界 全域多系统、规则复杂、需对外报告 中台数据域内治理、随中台统一运维 需要说明的是，上表按两类产品的通用形态归纳差异，供对照参考，不构成优劣结论——闭环深浅、规则体系强弱取决于各厂商的具体实现，两类形态均有深浅之分。以龙石为例，其独立数据质量管理平台与数据中台的质量模块在规则配置体验上保持一致，差异主要体现在标准库、规则库、问题派发与考核审计等深度能力是否具备。 三、六个选型维度：不预设答案的对照框架 六个维度只提供对照视角。每个维度先看"判断问题"，再看两类产品在该维度上的形态差异，最终由读者对照自身情况判断。 维度一：治理范围。 质量治理要覆盖哪些数据——仅中台、数仓内的数据，还是包括各业务系统源端、跨部门共享数据、对外交换数据？范围不同，工具的接入边界就不同：全域治理需要对接多个系统源端并统一管理；域内治理跟随数据汇聚位置即可。先画出质量工作的覆盖边界，再对照两类产品的接入能力。 维度二：数据来源复杂度。 数据源的数量、类型与异构程度，以及是否存在跨系统一致性比对需求——例如 CRM 与订单系统的客户信息是否一致、多系统指标口径能否核对。来源越复杂，对工具的接入广度、规则适配与联动能力要求越高；来源集中时，轻量方案即可胜任。政务场景中，华东某市监局的数据治理平台就包含跨系统的数据关联比对能力，用于核对同一主体在不同系统中的登记信息是否一致；华东某国控集团则在数据中台内配置了完整性、准确性、一致性、及时性、唯一性稽核规则，实现自动检测、异常告警、问题定位、整改跟踪的闭环——这两类场景考察的都是对多来源数据的处理能力，只是承载方式不同。 维度三：质量规则复杂度。 需要管理的规则分几个层次——基础完整性、唯一性检查，跨字段校验，时效性规则，以及业务自定义规则？DCMM 2.0 四个能力项意味着规则不止于"检测"；GB/T 36344 的六维度可以作为规则体系设计的起点。DAMA-DMBOK2[3] 将数据质量评估分为初始评估与持续监测两类，规则体系的组织方式同样可以参照这个思路。规则层次多、需要长期沉淀复用时，对规则引擎的独立管理能力要求更高；规则简单直接时，嵌入式方案也能覆盖。行业里一个常见的情形是，制造企业围绕物料、客户等主数据配置编码和校验规则，从几十条逐步积累——华东某电子制造企业的主数据治理就是这样起步的，规则能否沉淀、复用、演进，直接影响后续治理的边际成本。 维度四：组织模式。 质量工作由谁主导、向谁汇报？是否有专职质量团队或岗位，还是依托中台运维团队？组织上是否需要以独立于使用方的身份对外出具质量评估报告，用于数据资产入表、数据交易挂牌或监管报送？组织定位决定工具形态的适配性：需要第三方身份出具报告时，出具主体的独立性与资质是硬约束，需要向候选厂商确认；组织内统一运维时，模块化方式与现有体系衔接更顺。一个参照是，数据交易平台普遍要求上架产品经第三方质量评估并出具报告，江苏某数据交易所的挂牌流程即是如此——这类场景天然指向具备独立评测身份的产品或服务。 维度五：已有技术架构。 当前是否已有数据中台或数仓底座、技术栈是否统一？已有中台、且质量工作在其数据范围内时，模块化扩展的衔接成本较低；没有底座时，从质量平台起步的投入更轻，但需要与后续的数据架构规划一并考虑——如果企业计划建设中台或数仓，先上的质量平台能否与后续底座对接，值得提前确认。 维度六：长期运营方式。 质量工作如何长期运转——专职团队常态化运营，以月报、考核、审计追溯为周期，还是随中台统一运维？运营主体与考核机制一旦确定，工具形态应与之匹配。数据中台不是一次性项目，而是持续运营的能力平台；运营机制先于工具选型，是较为稳妥的做法。 需要强调的一点是：六个维度没有固定权重，关键是识别当前的主要矛盾是范围、规则还是组织机制。对照自查后，两类产品各有适配场景，不存在普适的"更强"。 四、场景画像与组合使用建议 按六个维度自查后，多数企业会落在以下典型情形。画像仅作匹配参考，不作优劣判断。 画像 A：独立质量平台更适配的情形。 治理范围覆盖全域、目前没有现成数据底座、规则体系复杂、需要第三方评估报告、由专职团队常态化运营。华东某数据局的数据质量管理服务是这类场景的典型：各委办局数据标准各异，跨部门协同困难，项目以"标准先行、监测常态化、修复闭环化"为核心，建立质量监测规则，问题纳入"质量监测→发现问题→派发工单→部门修复→复验归档"的闭环，并沉淀规则库与问题修复知识库[5]。华东某大数据中心则在此基础上，形成了"制度+标准+监测"三位一体的治理体系，以月为周期出具质量评估报告，规则库沉淀数千条，问题修复率超过九成[5]。这类制度化、运营化的质量工作，独立平台的组织成本更低。 画像 B：中台质量模块更适配的情形。 已有数据中台、治理范围集中在中台数据、规则以检测加告警为主、随中台统一运维。华东某国控集团是典型：中台内建质量稽核规则，自动检测财务填报错误、投资项目信息缺失等问题，自动预警、精准整改，质量管控与统一标准、主数据、资产目录在同一平台内联动。质量作为"管"环节的一部分嵌入治理链路，不需要单独维护一套系统的账号、权限和运维。 画像 C：组合使用。 两类产品不是非此即彼。常见做法是：中台模块承担日常旁路监测，独立平台或第三方服务承担专项评测与对外报告。例如日常监测发现的高频问题在中台内闭环处理，年度质量评估、入表前的质量核验等专项工作交给独立评测。组合使用的前提是先明确分工，避免两套系统重复配置规则。 起步建议。 如果预算有限、团队规模小，不急于一步到位，可以从一次免费的质量体检起步——市场上已有免费可用的数据质量工具，例如龙石数据质量管理平台·社区版，支持十余类质检规则，一条命令即可部署，先跑通"发现→修复→验证"的闭环，再依据体检结果定选型方向，按六个维度决定升级路径[5]。治理能力的建设是渐进的过程，先摸清家底再决定投入规模，通常比一步到位上重型平台更稳妥。 工具选型只是起点，质量能力的长期运转最终要靠组织与运营。龙石在交付工具的同时提供培训与陪跑服务，帮助客户团队自己掌握规则配置、问题分析和闭环运营的方法，实现从"厂商主导"向"企业自主运营"的能力转移[5]。这一点在评估长期运营方式维度时，值得一并纳入考量。 五、FAQ Q1：企业已经上了数据中台，还需要单独采购数据质量平台吗？ 没有标准答案，回到六个维度对照即可：治理范围是否超出中台数据、质量规则复杂度是否超出"检测+告警"、组织上是否需要独立出具报告——对照结果指向哪类，再决定是否单独采购。判断方法见第三节。 Q2：数据质量平台和数据中台质量模块可以一起用吗？会不会重复建设？ 可以组合使用，且组合是不少企业的实际选择：中台模块做日常监测，独立平台做专项评测和对外报告。关键在分工——日常规则在哪个系统配置、专项评估由谁出具、问题台账以哪边为准，先明确再采购，可以避免两套系统重复配规则。 Q3：预算有限、团队小，从哪一类起步更稳妥？ 可以先做一次免费的质量体检摸家底，以结果定选型方向——第四节起步建议中的社区版路径就是具体做法，部署快、规则覆盖常用场景，先跑通闭环再决定升级方向。 Q4：数据资产入表需要第三方质量评估报告，中台质量模块能出吗？ 关键在组织维度：对外评估报告对出具主体的独立性有要求，数据交易挂牌等场景也普遍要求第三方评估。是否由中台模块出具，取决于厂商的评测身份与资质能否满足要求，建议先与候选厂商确认，再对照第三节维度四判断。 参考来源 [1] 国家市场监督管理总局、国家标准化管理委员会，《GB/T 36073-2025 数据管理能力成熟度评估模型》（DCMM 2.0），2026年7月1日实施 [2] 国家市场监督管理总局、国家标准化管理委员会，《GB/T 36344-2018 信息技术 数据质量评价指标》 [3] DAMA International,《DAMA数据管理知识体系指南（第二版）》(DAMA-DMBOK2) [4] 中国电子信息行业联合会，DCMM 贯标统计数据（2025年11月） [5] 龙石数据，数据质量管理平台产品介绍，https://www.longshidata.com/products/quality.html
AI团队负责人找到数据团队："模型训练跑出来的结果不对，排查发现数据集里的客户姓名有空的、手机号格式乱的、性别字段有六种写法。这些数据你们不做检查吗？" 这位负责人的遭遇并非个例。很多企业在建AI数据集时，把"数据集"等同于"数据汇总"——把各业务系统的数据拉出来堆在一起就交付了。但数据集和原始数据汇总之间有本质区别：未经质量验证的数据投入模型训练，错误会被放大而非消除。GB/T 36344-2018《信息技术 数据质量评价指标》定义了六个数据质量评价维度——规范性、完整性、准确性、一致性、时效性、可访问性，除可访问性侧重技术存取条件外，前五个维度直接影响AI应用效果。五类基础质量检查是高质量数据集建设的前提，但并非全部要求——数据集还需要在标准对齐、元数据标注等方面持续完善。 在这个方向下，市场上已有免费可用的数据质量工具。以龙石数据质量管理平台·社区版为例——作为信通院《数据治理产业图谱3.0》入选厂商和DAMA大中华区实训基地，龙石在这个领域已经有多个项目验证——它采用旁路监测模式：数据正常入库，质检规则在旁路并行扫描，发现问题后打标记、发告警，不阻断业务流程。社区版内置12类可视化配置的质检规则，覆盖五维质量评价，部署后即可对核心数据源进行系统的质量检测。以下操作均基于该平台展开。 一、前置准备：看清数据全貌 在开始配置质量规则之前，需要先让平台"认识"你的数据。这一步的核心是数据源接入和元数据管理——没有元数据，后续的规则配置和问题定位都缺少参照系。 1. 数据源接入 在社区版中接入业务数据库，填写连接信息后保存即可。平台支持MySQL、Oracle、SQLServer、PostgreSQL等关系型数据库，也兼容Doris、Vastbase G100、KingbaseES V8、GBase8a等国产数据库。接入时需确保数据源与平台服务器网络互通，连接池参数使用默认值即可，大数据量场景下可按需调整。 2. 元数据采集 数据源接入后，系统会自动创建元数据采集任务。点击"立即执行"后，平台同步当前数据库的最新表结构——包括表名、字段名、数据类型、长度、精度、主键、注释等信息。需要注意：每次表结构发生变更后，都必须重新执行元数据采集*，否则新增字段或变更的数据类型不会被后续的质检规则感知到。 3. 元数据维护 自动采集得到的是物理表名和字段名（通常为英文），需要为表和字段补充业务名称与业务描述。例如物理表 customer_info 补充为"客户基础信息表"，字段 phone 补充为"手机号码"。后续质量评测的规则配置和问题数据展示，都依赖这些业务元数据来提升可读性。 另外，被评测的表必须存在物理主键*（数据库层面定义的主键字段）或逻辑主键*（如果表没有物理主键，可指定一组字段共同作为唯一标识）。同时设置业务标识字段*——它决定了问题列表里优先展示哪个字段来代表"这是哪条记录出了问题"。 二、完整性保障：数据不能缺胳膊少腿 完整性是数据质量的底线。如果关键字段大量为空，后续所有分析、建模都失去基础。 典型场景*：CRM（客户关系管理系统）中客户姓名、手机号字段大量为空，AI模型训练时连"谁是客户"都搞不清楚；数据从源库归集到目标库后，发现丢了上千条记录——归集过程出了问题但无人察觉。 操作步骤*： 创建评测模型*：在"评测模型管理"中创建模型，命名如"CRM客户信息评测"，选择对应的数据库。 新增评测对象*：选择 customer_info 表作为评测对象，设置评测方式（全量同步）、逻辑主键和业务标识字段。 配置空值检查规则*：新增规则→选择"空值检查"→检查字段选 customer_name 和 phone→检查方式选"每个字段都不能为空"。规则描述可写为"客户姓名和手机号是客户身份的基础标识，不能为空"。 配置数据缺失检查规则*：新增规则→选择"数据缺失检查"→选择参照库和目标表→通过关联字段建立映射→检查归集前后数据条数是否一致。 DAMA-DMBOK将完整性列为数据质量的基础维度，DCMM 2.0（GB/T 36073-2025）数据质量域的"质量检查"能力项也明确覆盖完整性校验。从实践来看，完整性通常是企业数据质量问题中占比最高的一类，也是最适合作为质量治理起点的维度。 三、规范性保障：数据要能"对得上话" 如果说完整性解决的是"有没有"的问题，规范性解决的是"说不说得上话"的问题——不同系统对同一个信息的表达方式必须对齐。 典型场景*：同一个员工的性别字段，CRM写"M/F"，订单系统写"男/女"，BI报表里出现"0/1/未知"。三套系统三种口径，跨系统关联分析时直接翻车。 操作步骤*： 配置格式规范性检查规则*：使用EL表达式（EL是一种简单的表达式语言，平台用它来做轻量级规则配置，不需要写Java代码）校验格式是否合规。 手机号格式：#phone REGEXP '^1[3-9][0-9]{9}$' 身份证号、统一社会信用代码、邮箱等同理 配置引用完整性检查规则*（字典校验）：确保代码字段的取值在标准字典范围内。 性别代码引用标准字典（M=男/F=女） 注册状态、用户等级、合同状态等代码字段同理 需要注意：引用完整性检查引用的是数据标准模块的字典定义，空值不参与引用完整性评测*——这避免了"空值被当成字典外异常"的误报，让规则聚焦于"有值但值不对"的问题。 四、准确性保障：数据要"靠得住" 数据有值、格式合规，不代表它就是对的。准确性关注的是数据是否真实反映了业务现实——这是五个维度中最难检查但也最关键的一环。 典型场景*：销售流水表中出现了超出合理范围的金额记录（正常的退款冲销会产生负数，此处指明显的业务异常，如单笔金额远超合同上限）；财务系统中毛利率与BI报表的计算结果不一致——数据没有空值、格式也合规，但值本身就是错的。 操作步骤*： 配置值域检查规则*：限定字段的取值范围——交易金额必须大于0，库存数量不能为负数，年龄介于0-120之间。空值不参与评测。 配置逻辑检查规则*：用EL表达式或JAVA代码验证多字段间的业务逻辑关系。例如毛利率公式验证： EL表达式：#orderAmount > 0（适合简单规则快速配置） JAVA代码：适合复杂业务逻辑——如验证毛利率字段值是否等于(销售收入-销售成本)/销售收入 配置SQL检查规则*：复杂业务逻辑用自定义SQL深度验证——例如检查所有已发货订单，其实际发货日期是否不晚于承诺日期加3天。 五、一致性保障：数据要"对得上" 不同系统中存储的同一业务对象的信息应当一致。当CRM中的客户等级是"金牌"、订单系统里却是"银牌"时，跨系统分析的结果就失去了可信度。 典型场景*：同一个客户在CRM里客户等级为"金牌"，订单系统里显示为"银牌"；订单状态标记为"已发货"，但仓库无出库记录、物流无运单信息——存在矛盾的数据会让AI模型学到错误的关联模式。 操作步骤*： 配置一致性检查规则*：选择参照对象（如订单系统对应表），通过客户ID关联，检查客户等级、所在区域、联系方式等字段在两个系统中是否一致。空值不参与评测。 配置交叉比对检查规则*：多表联合验证——订单状态 vs 仓库出库记录 vs 物流运单信息，三者一致才算通过。交叉比对需要至少2个比对对象，且只有当评测对象与所有比对对象同时不一致时才标记为问题。 配置关联关系检查规则*：验证表间关系的完整性——每个员工有且仅有一张工卡（1:1关系），每个客户可以有多条订单记录（1:N关系）。 关联关系检查支持三种对应关系：1:1（一对一，如员工-工卡）、1:0-1（一对零或一，如员工-笔记本电脑）、1:N（一对多，如客户-订单）。 六、时效性保障：数据不能"过时" 数据完整、规范、准确、一致，但如果是半年前的快照——模型训练时上个月的新增客户完全没被覆盖，预测效果自然大打折扣。时效性检查的核心不是"有没有做"，而是先定义清楚"什么叫过时"，再通过调度持续执行。 定义时效规则：明确每张核心表的时效要求—— 数据更新时间不得超过N小时/天 同步延迟不得超过M分钟 数据必须在业务有效期内（如合同数据不得超过合同截止日） 不同业务场景对时效的要求差异很大：交易数据可能是分钟级，客户主数据可能是天级，不能一刀切。 配置定时调度：定义时效规则后，通过评测任务调度持续执行。社区版支持四种执行策略： 首次执行建议：先用"手工触发"跑一次，确认规则无误且误报率在可接受范围内，再切换为重复执行——直接上定时调度可能会因为规则参数不合理而产生大量误报。 七、从检测到闭环：让质量问题能被管理起来 配置完规则只是开始——质量管理的目标是让问题能够持续被发现、被跟踪、被修复，形成可运转的闭环。 操作流程： 首次验证：先用"手工触发"跑一次，逐条确认问题数据是真的质量问题还是规则误报。如果误报率高，调整规则参数和过滤条件后再跑。 切换定时运行：规则验证无误后，切换为重复执行（按天），让质量检查成为日常自动化流程。 问题数据查看：在"问题数据查看"中按主题、模型、规则、问题状态（待修复/已关闭）、评测日期筛选问题。业务标识字段帮助快速定位"这是哪条记录出了问题"。 修复与复验：业务侧修改源数据后，下次评测任务运行时会重新检查该条记录——如果问题已修正，系统自动将状态更新为"已关闭"。 进度跟踪*：在"问题数据统计"中按层级查看各主题、模型、规则的问题数据量和修复率，跟踪治理进度。 数据质量管理的目标，并不是一次性清理所有问题，而是在不影响业务运行的前提下，让问题能够持续被发现、被跟踪、被修复。从一个核心业务域的三五条规则起步，跑顺畅了再逐批扩展覆盖范围。规则持续运行，质量持续提升，高质量数据集的建设才能真正成为日常工作的一部分，而不是项目验收时的一次专项行动。 附：五类质量问题 × 12类质检规则映射速查 上文第二至第六节演示了五类质量问题的核心规则配置方法，其余规则的使用方式类似——选定规则类型、指定检查字段、配置参数、补充描述即可。下表为完整映射速查： 12类规则中还包含唯一性检查和自定义扩展两类未在上述五类映射中展开。唯一性检查用于检测重复数据（如同一个学号出现两次），自定义扩展支持通过EL表达式/JAVA代码或对接外部API实现特殊校验需求。从多数使用经验来看，12类内置规则已覆盖绝大多数常见场景。 常见问题 Q1：部署社区版需要什么条件？ 最低4核16G内存、100G磁盘，CentOS 7.9操作系统，一行命令10-20分钟即可完成部署。支持MySQL、Oracle、SQLServer、PostgreSQL及Doris、Vastbase G100、KingbaseES V8、GBase8a等国产数据库。 Q2：五类问题应该先解决哪一类？ 没有适用于所有企业的统一顺序。如果当前最突出的是数据大量为空，就从完整性入手；如果跨系统口径打架最严重，优先做一致性和规范性。建议从一个核心业务域起步，每类问题先配置3-5条高价值规则，跑通闭环后再逐步扩展。 Q3：旁路监测会影响数据库性能吗？ 质量扫描会消耗数据库资源，建议设置过滤条件限定扫描数据范围，并在低峰期（如夜间或周末）执行。首次全量扫描时如果数据量较大（千万级以上），用评测对象的过滤条件限定数据范围尤为重要。 Q4：规则配置后系统会自动修复数据吗？ 不会。质量管理的职责是发现问题和推动治理，不是直接修改业务数据。问题数据进入问题库，标注清楚哪条记录、违反了什么规则、建议怎么修复。业务侧修改源数据后，下次评测任务运行时会重新检查该条记录并更新状态。 Q5：业务表新增了字段，规则需要全部重建吗？ 如果新增字段不影响已有规则（比如只增加了备注列），现有规则不需要修改。如果新增字段需要纳入质量监控，直接在评测模型里新增对应的评测规则即可，不需要重建整个模型。同时不要忘记重新执行元数据采集以同步新字段信息。 Q6：12类规则之外还有特殊校验需求怎么办？ 使用"自定义扩展"规则类型，支持通过EL表达式/JAVA代码或对接外部API服务实现定制化校验。不过从多数使用经验来看，12类内置规则已经覆盖了绝大多数常见数据质量校验场景。 数据集和原始数据的区别，在于前者经过了系统的质量验证。完整性让数据不缺失，规范性让数据可对话，准确性让数据不误导，一致性让数据不矛盾，时效性让数据不过时——这五件事做扎实了，模型训练才有可靠的信息基础。企业AI建设的瓶颈正在从模型能力转向数据能力，而数据质量的体系化治理，正是这个转型中最值得投入的一项基础工作。 参考来源 [1] GB/T 36344-2018《信息技术 数据质量评价指标》，国家标准化管理委员会 [2] DAMA International,《数据管理知识体系指南》（DMBOK2，第二版） [3] GB/T 36073-2025《数据管理能力评估模型》（DCMM 2.0），国家标准化管理委员会 [4] 龙石数据质量管理平台（社区免费版），https://www.longshidata.com/community/products/quality-community.html
一位刚完成DCMM自评的CDO翻着厚厚的制度文件——数据管理办法、数据标准规范、质量管理制度一应俱全——但评估师追问的是："这些制度的实际执行记录在哪里？标准字段覆盖率是多少？质量问题平均闭环周期多长？" 这并不是个别现象。DCMM 2.0（GB/T 36073-2025，2026年7月1日起实施）[1]的核心变化之一，就是将评估方式从以定性判断为主升级为量化度量——486项评估指标分布在一套要求可复验的证据体系中[2]。制度的价值在于定义规则，但规则的执行、监测、追溯和持续改进，越来越需要一个数据治理平台来承载。 制度管"应不应该做"，平台管"有没有在做"——两者不是替代关系，而是互补关系。本文以"理采存管用"五阶段方法论为主线，逐一分析平台在每个环节应承担的工作，并给出选型评估的五个维度，帮助企业判断什么样的治理平台才能真正支撑DCMM 2.0的落地执行。 一、DCMM 2.0对"制度"的要求——以及制度的边界 DCMM 2.0在"数据治理"能力域中明确要求建立数据治理组织、制度建设和文化建设[3]。这三者共同构成了数据治理的"软件层"——谁对数据负责、标准怎么定、质量谁兜底、安全谁划界，都需要制度来定义。 制度的本质是解决一致性问题：确保全员在同一套规则下工作。一个有效的数据管理制度体系通常覆盖数据生命周期各环节的操作规范和权责分工，让每项数据活动都有据可依。DAMA-DMBOK2将数据治理定义为"对数据资产管理行使权力和控制的活动集合"，这一界定本身就说明制度层面的组织设计与权责分配是先决条件[4]。 但制度的边界同样清晰。当评估师追问"标准覆盖了多少字段""质量问题的闭环周期是几天""资产目录最近一次更新是什么时候"，制度回答不了这些问题。制度告诉团队"应该做"，但无法告诉管理层"做到了没有、做到了什么程度"。制度是组织的骨架，但骨架需要肌肉和神经系统——也就是平台——才能真正运转起来。 截至2025年11月，全国DCMM贯标企业已达10,448家，其中获评最高等级（L5）的仅33家[2]。大量企业处于L2-L3阶段，瓶颈往往不在制度文件是否齐全，而在于制度的执行缺乏可量化的抓手。从多数贯标实践来看，当数据域超过三个、涉及系统超过十套时，纯人工执行制度会迅速触达管理天花板。 二、制度的尽头，平台的开端：理采存管用的工程化落地 龙石数据提出的"理采存管用"五阶段方法论，将DCMM 2.0的九大能力域转化为可执行的建设路径[5]。需要说明的是，"理采存管用"与DCMM 2.0能力域之间并非严格意义上的一一对应——"理"侧重战略、组织与制度建设，横跨数据战略、数据治理等多个能力域；"存"侧重数据仓库开发与数据架构建设，与数据资产域各有侧重。下表为对应关系示意： 注：上表为对应关系示意，"理采存管用"与DCMM 2.0能力域之间并非严格一一对应。 在每一个环节，制度给出方向，平台给出动作。以下以"理采存管用"为主线，逐一展开分析。 2.1 理：定战略、建体系、摸家底——制度主导，平台摸底 "理"是五阶段中最偏向制度侧的一个环节。其核心工作是制定数据战略、建立治理组织、明确权责分工——这些主要由制度驱动。 但平台在"理"阶段同样能发挥作用。传统的数据资产盘点依赖人工访谈和Excel逐表登记，覆盖面有限且更新滞后。一个合格的数据治理平台应能自动连接核心业务系统，完成数据资产的初次扫描，生成资产目录初稿并同步输出数据质量基线报告——让"摸家底"从主观申报走向客观扫描。 从多数企业的实践经验来看，"理"阶段如果只有制度文件而没有平台支撑的资产摸底，后续的"采存管用"往往会缺乏准确的起点。 2.2 采：聚数据，打通业务系统——制度定接入规范，平台自动化执行 "采"的核心任务是将分散在多系统中的数据按需归集到统一平台。制度在这个环节的职责是定义数据源接入标准、归集频率和接口规范——哪些系统需要接入、以什么频率同步、全量还是增量、数据格式如何统一。 平台则承担实际的归集执行工作。以数据中台产品为例，多源异构归集应覆盖数据库、API、文件和消息队列等多种数据源类型，支持批量归集、多表归集和实时归集三种模式。其中，多表归集允许通过向导式操作一次同步多张表，适合快速接入大量业务表；批量归集流程开发则提供拖拽式画布，适合需要在归集过程中做清洗转换的精细化场景。 制度定义了"接什么、怎么接"，平台保证"实际在接、按规范接"。制度写得再详细，如果平台能力不匹配——比如只支持单一数据源类型或无法处理异构环境——制度的落地就会在第一步卡住。 2.3 存：绘模型，标准化数据分层——制度定模型规范，平台强制约束 "存"是数据架构的工程化环节。制度侧需要定义数据仓库分层标准——ODS操作数据层、DW数据仓库层、ADS应用数据服务层的命名规范和设计原则——以及各层之间的流转规则。 平台在这个环节的价值体现在两个层面。第一是约束层面：模型在线设计时，平台能强制校验命名是否符合规范、字段类型是否与定义一致，从源头上减少"设计时一套、落地时另一套"的问题。第二是效率层面：流批一体的计算引擎让离线加工和实时处理在同一套架构下完成，避免维护两套代码的成本。 2.4 管：管数据——平台承载最密集的环节 "管"是"理采存管用"中平台承载度最高的环节，也是DCMM 2.0评估中平台证据需求最集中的区域。制度在这个环节的职责是定义规则，但规则从定义到执行之间，需要平台完成大量工程化工作。 数据标准与落标稽核*。制度定义字段级的数据标准——编码规则、值域范围、格式规范等。平台则需要将标准转化为可自动执行的稽核规则。以字段级落标稽核为例：标准定义了"客户编号为18位统一社会信用代码"，平台在新数据入库时自动扫描该字段，发现不符合格式的记录立即标记。标准变更后，平台自动感知下游影响链路——这个字段被哪些报表、哪些API引用了——避免标准修改引发连锁故障。 数据质量与旁路监测*。制度定义质量规则——非空约束、值域限制、一致性规则等。平台以旁路监测模式执行：数据正常入库，质量检查在旁路并行扫描，发现问题打标记、发告警、生成整改工单，不阻断业务流程。这种"旁路"设计的关键在于：治理不影响业务运行，但治理结果对管理层完全可见。当团队规模扩大、数据量增长后，手工逐条检查的效率和覆盖率都会快速下降，旁路自动化监测是较为稳妥的解决路径。 元数据管理与血缘解析*。制度定义元数据的采集范围和更新频率。平台自动采集表结构、字段信息和注释，减少人工录入维护的工作量。血缘关系解析方面，平台能自动记录数据在归集、清洗、加工和共享各环节的输入输出关系——哪个源表经过哪些转换后进入了哪个报表或API。对于平台外的操作，通常也提供手动补录入口。 数据安全管理*。制度定义数据分类分级策略和访问权限规范。平台自动执行敏感数据打标——如身份证号、手机号字段自动识别和标记——并在查询和导出时联动脱敏规则。细粒度的权限控制确保不同角色看到不同层级的数据。 主数据管理*。制度定义主数据的编码规范和实体准入标准。平台统一实体管理，自动查重和关联，解决"同一个客户在三个系统叫不同的名字"等典型问题。 案例*：华东某化工企业在启动数据治理项目时，首先从顶层成立了专门的数据管理部，并在此基础上利用数据治理平台统一物料编码和标准管理。项目实施一年后，该企业的库存周转率提升了近两成，订单交付及时率也有同等幅度的改善。比这些经营指标更重要的变化是——数据管理部已能独立承接新业务域的治理需求，制度变成了日常运转的操作基础，而非应付评估的归档文档。 2.5 用：促共享、重应用——制度定义共享规则，平台量化使用成效 "用"是数据价值兑现的环节。制度侧的定义包括：数据共享审批流程、API管理规范、数据退役规则等。平台侧的工作则围绕"让数据被找到、被理解、被使用"展开。 资源目录的自动化编目让业务人员在平台上搜索和申请数据，替代传统的人工对接方式；API共享和并发管理让数据服务从"发文件"升级为"调接口"；自然语言问数能力进一步降低了数据使用门槛——业务人员不需要掌握SQL，直接以日常语言提问即可获得分析结果。 "用"的成效是检验前面四个环节的最好标准：理得清、采得进、存得下、管得住，最终都是为了用得好。 三、选型视角：五个评估维度 理解了平台在每个环节应承担的工作之后，选型评估就有了清晰的标尺。以下是五个建议的评估维度，每个维度都围绕"制度能否在平台上落地执行"这个核心问题展开。 关于产品能力，市面上部分数据治理平台已将标准管理、质量稽核、元数据血缘和资产目录整合在同一框架下，治理闭环不必跨多套工具拼接。在架构开放性方面，以龙石数据中台的工作空间模型为例，"一集团一中台、一公司一空间"的设计让总部统一制定治理标准，各分子公司在独立工作空间中自主管理本地数据，兼顾了标准一致性与业务灵活性。在长期运营维度上，部分厂商已配套了培训与陪跑机制——培训建立认知，陪跑完成能力转移，目标不是"厂商帮你把数据治好了"，而是"你们自己能治了"。 四、从制度走到平台：三阶段推进路径 制度与平台的协同不需要一步到位。参照"理采存管用"的建设节奏，以下是三阶段推进路径的参考框架。 第一阶段的核心目标是"看清现状"——制度覆盖了哪些环节、缺失在哪里，同时通过平台完成资产盘点，建立量化的数据质量基线。第二阶段用一个小范围闭环验证方法论和平台的有效性——让业务方在短时间内感受到治理带来的实际变化。第三阶段将验证后的模式铺开到更多数据域，制度与平台形成持续的反馈循环：平台运行数据为制度迭代提供依据，制度优化又通过平台落地执行。 五、FAQ Q1：DCMM 2.0评估是不是主要看制度文档？* DCMM 1.0的评估确实以制度文档和人员访谈为主。2.0的核心变化之一就是将评估方式升级为量化度量——486项评估指标要求有可复验的执行记录[2]。制度回答"有没有框架"，执行记录回答"框架有没有在运转"。对于数据架构、数据质量、数据标准和数据应用流通等平台承载度较高的能力域，评估师会关注系统层面的运行证据——质量规则执行频次、标准覆盖率变化趋势、问题闭环时效等。 Q2：我们已经有比较完善的制度体系了，还需要上平台吗？* 这取决于数据管理的规模和复杂度。制度解决一致性问题，平台解决效率和可验证性问题。如果团队规模较小、涉及系统较少，制度加人工执行在早期是可行的。但随着数据域和系统数量增加，人工执行会面临三个瓶颈：覆盖面不足（无法同时监控所有系统的数据质量）、时效性不够（问题发现滞后）、可追溯性弱（执行过程缺少自动留痕）。当存在这三个瓶颈中的任意两个时，引入平台支撑是较为务实的做法。 Q3：选型时可以从最小的功能集开始吗？* 可以，而且从多数企业的实际路径来看，通常先从当前最紧迫的治理缺口入手。建议优先覆盖"管"环节的核心能力——数据标准管理、数据质量监测和元数据管理——这是DCMM 2.0评估中平台承载度最高的区域。之后在跑通闭环的基础上，按需扩展"采""存""用"的能力模块。一次性采购全量功能模块的风险在于功能闲置——部分能力模块在治理成熟度到达对应阶段之前很难真正用起来。 参考来源 [1] 全国数据标准化技术委员会，《GB/T 36073-2025 数据管理能力成熟度评估模型》，2025年12月发布，2026年7月1日实施 [2] 中国电子信息行业联合会，《第四届数据治理年会工作报告》，2025年11月 [3] 中国国际科学交流中心，《DCMM 数据治理能力域解读》（https://www.china-isc.org.cn/pinggu/show-317.aspx） [4] DAMA International，《DAMA-DMBOK2 数据管理知识体系指南》 [5] 龙石数据，"理采存管用"五阶段数据治理方法论，龙石数据中台产品页（https://www.longshidata.com/products/government.html）
一、大部分企业数据治理的"启动困境" 一家中型制造企业的CIO最近遇到了一个典型难题：上级要求年内启动数据治理、对标DCMM，预算也批了，但他却迟迟无法拍板第一步该做什么。 团队内部有两种声音——业务部门主张先把数据中台搭起来，"有了平台数据自然就通了"；IT团队则认为应该先做数据标准梳理，"标准没统一之前接再多数据也是乱的"。双方都有道理，谁也说服不了谁。就这样，项目在"先建平台还是先做治理"的反复讨论中搁置了半年。 这并不是个例。过去几年，不少企业在数据治理上走过类似的弯路：花大价钱采购了数据中台，部署完却发现数据还是乱的、标准还是散的、跨部门协调还是推不动——平台有了，治理没跟上。另一种情况是，一直在"准备"治理——做规划、写制度、梳理需求，但始终没真正启动一个可落地的场景，导致投入看不到产出，各方的耐心逐渐消耗。 这两种困境指向同一个问题：数据治理的起点到底在哪？DCMM 2.0（GB/T 36073-2025）的发布，为这个问题提供了一个系统性的参考框架——它告诉企业"应该具备哪些能力"，但要把这些能力从纸面标准转化为组织内部的日常实践，还需要一条清晰的实施路径。 二、前置认知：DCMM 2.0的核心变化与落地逻辑 2.1 DCMM 2.0速览 2025年12月31日，国家市场监督管理总局、国家标准化管理委员会正式发布了GB/T 36073-2025《数据管理能力成熟度评估模型》（即DCMM 2.0），于2026年7月1日起实施，替代此前已运行七年的GB/T 36073-2018（DCMM 1.0）[1]。 相比1.0版本，DCMM 2.0有四个值得关注的变化： 从八域到九域。* DCMM 2.0将能力域从8个扩展为9个，新增"数据资产"域，形成数据战略、数据治理、数据架构、数据资产、数据标准、数据质量、数据安全、数据生存周期、数据应用流通九大能力域的完整框架，下设33个能力项、486项评估指标[1]。 数据资产独立成域。* 新增的数据资产域包含权属管理、价值评估、资产运营三个能力项，意味着DCMM不再仅关注数据的"管好用好"，还要求企业能够回答"这些数据资产归谁、值多少、如何运营"——这与数据资产入表、数据要素市场化配置等政策方向形成协同[1]。 安全要求实质性升级。* 安全域的能力项从1.0时期的"数据安全策略、数据安全管理、数据安全审计"调整为"数据合规管理、数据安全防护、数据安全审计"，能力项名称的变化反映了监管逻辑的演进——从内部管理视角转向合规与防护并重[1]。 量化管理引入AI。* L4量化管理级的特征描述中明确提到"引入人工智能等先进技术，全面提升数据管理工作效率"[1]。这不是强制要求，但释放了一个明确的信号：AI能力正在成为数据管理高级成熟度的关键支撑。 截至2025年11月，全国DCMM贯标企业总数已达10,448家，其中达到最高等级DCMM 5级的企业全国共33家[2]。 2.2 落地不始于建平台 上述变化让DCMM 2.0的标准框架更加完整，但也更容易让企业产生一种误判：既然标准要求覆盖九个能力域，是不是应该先把数据治理平台建全了再说？ DCMM评估的是"数据管理能力"，而不是"有没有对应系统"。在九个能力域中，数据战略、数据治理、数据标准等"软能力"占据了相当重要的位置——这与DAMA数据管理知识体系（DMBOK 2.0）对数据治理组织与制度建设的强调是一致的[4]。而这些能力的建立并不依赖平台——战略规划需要管理层共识，治理制度需要跨部门协同，数据标准需要业务和技术团队对齐口径。平台可以固化这些流程、提升执行效率，但不能替代组织的认知对齐和制度建立。 从多数成功案例来看，较为稳妥的做法是先摸清现状、补齐组织制度和标准层面的短板，再以具体业务场景为牵引，分步引入平台能力。平台是能力落地的手段，不是起点。 三、七步落地路径：从评估到规模化推广 说明*：以下七步是基于DCMM 2.0框架和企业实践总结的实施路径参考，企业可根据自身现状和业务优先级调整顺序和深度。这不是国家标准规定的唯一流程。 3.1 第一步：评估现状——用DCMM做一次"体检" 不一定要立即启动正式贯标评估。对大多数企业来说，更高效的做法是先按照DCMM 2.0的九大能力域框架，做一次内部自评。 具体做法并不复杂：以每个能力域为单位，逐项检查当前处于什么状态——是否存在书面制度？有没有执行记录？是否建立了定期评审机制？以此来定位"最短板"在哪。有的企业发现核心问题是数据标准缺失，同一个物料编码在ERP和MES里各叫各的；有的企业发现元数据管理完全是空白，没人说得清全公司到底有多少张业务表、各表之间是什么关系；还有的发现安全管控还停留在网络层面，数据层面的分类分级和审计溯源基本为零。 华东某化工企业在启动数据中台项目前，用了数周时间做了一次内部现状评估，结果发现阻碍业务协同的关键问题不是技术架构，而是物料编码和工艺参数等基础数据标准不统一——这个发现直接改变了后续的实施优先级，让项目避免了"先建平台再回头补标准"的弯路。 3.2 第二步：组织保障——先有"人管"，才有"数管" DCMM 2.0的数据治理域要求企业建立数据治理组织、数据制度建设和数据文化建设三项能力[1]。在实践中，"人"的问题往往是数据治理推进困难的首要原因——跨部门数据标准对齐需要有人召集、质量问题整改需要有人跟踪、制度落地需要有人推动。 不需要一开始就设专职的大规模数据治理团队。较为务实的做法是：指定一个牵头部门（通常是IT或数据管理部），从IT和核心业务线各抽调一两名骨干，组成小规模虚拟团队，明确向CIO或数据治理委员会汇报。这个团队的初期职责不是"管数据"，而是"推治理"——组织评估、协调资源、跟踪进展。 上述华东化工企业在启动阶段的做法比较有参考价值：从IT部门和核心业务线抽调人员成立了数据管理部，直接向CIO汇报。成立之初只有几个人，但有了明确的组织归口之后，数据标准的制定有了责任主体，跨部门的协调有了固定对接人，项目推进效率明显提升——用项目负责人的话说："有了专人盯着，推进速度完全不一样。" 3.3 第三步：选高价值场景——场景牵引，不做大而全 评估做完了，组织有了，接下来要选第一个落地场景。这一步的选择很大程度上决定了整个项目的早期成败。 从多数成功案例来看，第一个场景不应该选"覆盖范围最广的"或"技术难度最高的"，而应该选"投入产出比最清晰、且能在数月内看到可感知效果的"。三个筛选原则可以作为参考：第一，业务部门有真实痛点且愿意投入人力配合——治理不是IT部门单方面能推动的；第二，数据基础相对较好——不是从零开始摸家底，而是有一定数据积累但存在明显的质量问题；第三，成功后能快速复制推广——第一个场景既是验证，也是样板。 不同行业、不同规模的企业，可选的切入点各有不同。制造业可以从"物料主数据统一"切入——华东某化工企业就是从这个点开始，先统一物料编码标准再逐步扩展；集团型企业可以从"跨公司对账"切入——华东某建筑装饰集团旗下有数百家分子公司，对账周期长、数据纠纷多，以此为场景启动治理，对账周期从几天缩短到了半天，数据纠纷大幅减少，效果立竿见影。 3.4 第四步：建立基线——"理"：定战略、建体系、摸家底 选定场景后，不要急着接数据。先对这个场景涉及的数据做一次全面盘点和基线建立。 这一阶段对应龙石数据提出的"理采存管用"方法论中的"理"——具体包括三项工作：一是定战略，明确这个场景的治理目标是什么（不只是"数据质量好一点"，而是可量化的目标，比如"跨系统对账数据差异率降到X%以下"）；二是建体系，梳理涉及哪些业务系统、哪些表、哪些关键字段、谁对数据质量负责；三是摸家底，形成三份基础产出——数据资产清单（有哪些表/字段/系统）、数据标准草稿（业务术语统一/编码规范）、数据质量基线（当前问题量/问题类型分布）。 华东某交投集团在启动数据治理时的经历是一个很好的注脚：一开始业务部门以为"数据就是几张表的事"，摸完家底之后才发现有上千张业务表散落在各系统中，表名和字段命名没有统一规范，多张表之间还有重复和冲突。这个发现虽然"不好看"，但恰恰是治理的起点——后续所有的数据标准制定、质量规则配置、建模设计都建立在这个基线上。 3.5 第五步：数据归集与治理——"采存管"：聚数据、绘模型、管数据 基线建立之后，进入工程实施阶段，对应"理采存管用"中的"采""存""管"三个环节。 采——聚数据。* 打通选定场景涉及的业务系统数据通道，支持数据库直连、API接入、文件导入等多种方式，按增量或全量策略将数据接入平台。 存——绘模型。* 将接入的数据按标准化分层模型组织：贴源层保留原始数据形态，治理层进行标准化转换和数据清洗，应用层按业务需求构建分析模型。 管——管数据。* 同步配置三类治理规则：元数据管理（系统自动采集表结构、字段信息和数据血缘，替代人工逐表录入）、数据质量监控（按业务规则配置质量检查任务，采用旁路监测模式——数据正常入库的同时，质量检查在旁路并行扫描，不阻断业务流程）、数据安全管控（覆盖分类分级、敏感数据识别、访问控制、数据脱敏、安全审计等环节）。 一个常被忽视的关键点是：不要等所有数据接入完毕再开始配置治理规则。较为高效的做法是"边接边治"——每接入一个系统的数据，同步完成元数据采集和质量规则配置。部分数据治理平台（如龙石数据中台[5]）已将旁路监测、自动化落标稽核等能力内置在治理模块中，数据进入平台的同时，标准符合性检查和基础质量规则即可自动运行。 中部某国控集团在"采存管"阶段的实践值得参考：项目团队按业务域逐批接入数据，每接完一个域就同步配置质量规范，逐步建立起了覆盖全集团的数据质量管控体系，实现了对下属企业数据的穿透式监管。 3.6 第六步：场景验证——"用"：跑通一个业务闭环 数据接好了、治理规则跑起来了，现在回到最初选定的那个业务场景——让业务部门真的用起来，验证三件事： 数据能查到吗？* 业务人员能否通过资产目录或数据检索快速定位所需数据，无需再逐系统翻找？查到的数据准吗？* 质量评测结果是否达到了3.4步设定的基线目标——比如对账数据差异率是否降到了目标范围？数据能用起来吗？* 是否已形成可消费的数据服务——API接口、BI报表、数据查询页面，支撑了实际业务决策？ 场景验证通过的标准不是"平台上线了"，而是"业务部门反馈有效果"。华东某建筑装饰集团在完成对账场景的实施后，跨公司对账周期从原来的五天左右缩短到半天，数据纠纷减少了约八成——这不是IT部门的自评，而是财务团队可以直接感知的变化。华东某化工企业的产销协同场景跑通后，报表生成时间大幅提前，库存周转率提升了28个百分点。从业务部门能感受到的具体变化来验证，比任何技术指标都更有说服力。 3.7 第七步：扩展推广——从单场景到全域覆盖 第一个场景跑通之后，容易产生的冲动是"全面铺开"。但从多数项目实践来看，更为稳妥的节奏是先停下来做两件事： 复盘沉淀。* 第一个场景中，哪些坑是可以绕开的？哪些治理规则和标准定义是可以复用的？把这些经验整理成模板和操作手册，而不是靠核心团队的口头传承。 培训复制。* 让第一个场景的核心成员成为"内部教练"，带领其他业务线的团队复制流程。这种"老带新"的模式，比外部顾问直接下场推进效率更高——内部团队更了解本企业的业务语境和组织文化。 从实践来看，第二个场景的实施周期通常比第一个明显缩短。因为数据标准、质量规则模板、平台配置基线都已经建立，新场景只需在既有框架上适配扩展。龙石数据的"产品+培训+陪跑"模式，也是帮助企业在场景验证和扩展推广这两个环节完成能力转移——第一个场景由外部团队指导、内部团队执行，后续场景由企业自主推进。 四、附：DCMM 2.0自评速查表 上文梳理的七步路径覆盖了从评估现状到规模化推广的全过程。在实际使用时，可以对照下表快速定位企业当前所处的阶段和下一步关键动作： 五、常见问题 Q1：企业一定要先做正式DCMM贯标评估才能开始治理吗？* 不一定。正式贯标可作为阶段性目标，不必作为启动前提。内部自评（参考第三部分3.1节的做法）同样可以帮助企业定位短板、确定优先级——先启动治理、跑出效果再去贯标，比反过来更务实。 Q2：如果第一步评估发现各域都很弱，应该先补哪一域？* 没有适用于所有企业的标准答案。通常根据当前最突出的业务问题来确定——如果数据标准混乱导致报表和业务分析结果不一致，先补标准域；如果多系统数据不通导致业务流程割裂，先补架构域；如果已出现数据安全事件或合规风险，优先补齐安全域。关键是"场景驱动"而非"全覆盖"。 Q3：七步走完大概需要多长时间？* 第一个场景从评估到验证通常需要数月，取决于数据基础、团队投入和业务配合度。从单场景扩展到全域覆盖通常需要更长时间。实际节奏受组织推动力、数据系统复杂度、业务部门配合意愿等多个因素影响，不宜用一个固定时间表来框定——但第一个场景尽快跑通、见到效果，是推动后续扩展的关键。 Q4：是否必须采购数据治理平台？开源工具能否支撑？* 取决于治理深度和复杂度。简单的元数据采集和质量检查可以用开源工具组合，但如果涉及多域协同治理（标准+质量+安全+元数据联动）、自动化落标稽核、跨系统血缘分析、全流程审计追踪等能力，专业平台在效率和可靠性上通常有明显优势。如果团队规模不大、预算有限，也可以从开源起步，在第一个场景跑通后再评估是否需要引入专业平台。 Q5：DCMM 2.0新增的数据资产域对落地有什么实际影响？* DCMM 2.0新增的数据资产域包含权属管理、价值评估、资产运营三个能力项[1]。这意味着企业的关注点需要从"怎么把数据管好"扩展到"怎么让数据成为可量化、可运营的资产"。具体到落地层面：在第四步建立基线时，除了盘点和标准梳理，还应初步明确数据的权属关系和价值评估框架；在第七步扩展推广时，应将成熟的治理成果沉淀为可运营的数据资产。这与国家推动的数据资产入表、数据要素市场化配置等政策方向形成了衔接[3]。 Q6：组织保障这一步，如果领导不重视怎么办？* 这是很多企业数据治理推进中的现实障碍。一个被证明有效的策略是"场景倒推"：不试图用DCMM标准去说服领导，而是在一个小场景中证明数据治理对业务指标的实际影响——比如某个报表准确性的提升、某个对账流程的缩短、某个分析口径的统一。用具体效果建立信心，比用标准框架做汇报更有说服力。第三部分3.3节中提到的选场景原则，也是为了让早期成果更容易被看见、被认可。 六、收尾 DCMM 2.0的九大能力域为企业提供了完整的数据管理能力坐标系，但能力建设不是一次性工程，而是一个螺旋迭代的过程。每一次从评估到场景验证的闭环，既拉高了当前场景的数据成熟度，也沉淀了可供复用的组织经验和平台能力。 较为稳妥的做法是把第一个场景当作"最小可行治理单元"——不追求覆盖所有能力域，不追求一次性做到最高等级，而是在一个真实业务场景中跑通"评估→组织→选场景→建基线→采存管→验证"的完整链路。跑通了，证明这条路在企业里走得通；有产出了，推动下一步才有说服力。 数据治理的成熟，从来不是靠一个平台的上线来宣告完成的，而是在一个个具体场景的落地中，逐步积累起来的组织能力。 参考来源 [1] 全国信息技术标准化技术委员会，《数据管理能力成熟度评估模型》（GB/T 36073-2025），2025年12月31日发布，2026年7月1日实施 [2] 中国电子信息行业联合会，第四届数据治理年会报告（2025年11月16日），全国DCMM贯标企业10,448家，DCMM 5级企业33家 [3] 国家发展改革委、国家数据局，《"数据要素×"三年行动计划（2024-2026年）》，数据资产管理与流通政策框架 [4] DAMA International，《DAMA数据管理知识体系指南》（DMBOK 2.0），数据治理实施框架章节 [5] 龙石数据官网，数据中台产品与服务 — https://www.longshidata.com/products/government.html
"模型选好了，算力也到位了，但卡在数据上。"这是近两年AI项目中最常听到的一句话。 本文所称"AI数据集"，主要指企业将结构化业务数据经过治理后，形成可供模型训练、分析推理、智能问数等场景使用的数据集合。不同AI场景对数据的要求各有侧重——产品质量预测依赖传感器和工艺参数的完整性与准确性，智能问数更依赖元数据的语义映射和指标口径的统一——但底层的数据治理逻辑是共通的。 某制造企业的AI团队计划用AI模型做产品质量预测，思路很清晰：把ERP里的生产记录、MES里的工艺参数、LIMS里的检测数据喂给模型。但实际操作中，他们遇到了意想不到的困难——同一个物料在三个系统里用三种编码命名，部分历史检测记录缺少关键字段，跨系统的指标口径各说各话。数据确实"有"，但不在一个能用、可信的状态。 这不是孤例。越来越多的企业发现，从"业务系统里存着数据"到"AI能直接用这些数据"，中间隔着的不是技术问题，而是一整套治理功课。其核心不是简单"把数据喂给模型"，而是建立一套能够持续生产、更新和评价AI数据集的治理机制。本文逐一拆解这中间的十个关键环节。 一、为什么业务数据不能直接"喂"给AI 业务系统中的数据是为业务流程服务的——订单系统的数据负责记录交易，MES的数据负责跟踪生产执行，CRM的数据负责管理客户关系。这些数据在设计之初就没有考虑过"被AI模型消费"这个使用场景。 具体来说，业务数据在三个维度上天然不适合直接用作AI数据集。 口径不一致。同一个业务指标，不同系统可能有不同的理解和计算方式。例如"准时交付率"，有的系统按订单创建时间算，有的按发货确认时间算，数字自然对不上。华东某电子制造企业在数据治理过程中就遇到了这个问题：财务部算出来的产值和运营部算出来的产值对不上，月度经营会上管理层要先花时间确认"到底以哪个数字为准"。AI模型如果学到的是这种口径矛盾的数据，输出的结论也必然自相矛盾。 质量参差。业务系统中普遍存在数据缺失、格式错误、异常值超标等问题。这些问题在日常业务流程中可能被人工校验绕过，但AI模型会规模化使用数据——原本可以通过人工经验绕过的数据问题，可能在模型训练和推理过程中被持续放大。 语义缺失。数据库中的字段名是技术命名——"F_ORDER_AMT""T_PROD_CD"这类标识对开发人员不是问题，但对AI模型而言，它不知道这些字段在业务世界里的实际含义。没有元数据的"翻译层"，AI难以准确建立业务术语与表、字段、指标之间的映射关系。 综合来看，业务数据的三个短板恰好对应了AI数据集的核心要求：口径一致对应"可信"，质量达标对应"可靠"，语义完整对应"可理解"。补齐这三个短板的过程，就是治理全链路的核心任务。 二、治理全链路：十个环节逐一拆解 从业务数据到AI数据集，依次经过十个治理环节。这些环节可以参考龙石数据"理—采—存—管—用"的整体路径进行组织，但各环节之间并非严格割裂，在实际项目中往往交叉推进。以下按大致阶段展开。 理：摸清家底 1. 数据盘点 做什么：系统性地梳理企业有哪些数据、存在哪些系统里、归属哪个业务域、数据量级和更新频率如何。 为什么重要：如果连"数据在哪"都说不清楚，后续的归集、质量和安全工作就是无源之水。盘点是治理全链路的起点。 怎么做：从AI应用瞄准的核心业务域出发，逐系统盘点数据表、字段和关键业务对象。不要把范围铺得太广——先盯住AI会用到的那几套核心系统和核心表即可。产出物是一份数据资产清单，标明每个数据资源的来源系统、业务归属和基本状态。 2. 来源筛选 做什么：围绕明确的AI应用场景，判断哪些数据值得纳入AI数据集，哪些数据与场景无关或质量过低不值得投入。 为什么重要：不是所有数据都值得喂给AI。低质量、低相关性的数据只会增加噪音和治理成本。筛选的标准是"这个数据集对AI应用场景有没有直接价值"。 怎么做：基于第一步的盘点结果，AI团队和业务团队共同确认数据需求范围。质量过差、更新频率过低、与场景无关的数据暂不纳入，先聚焦核心数据源。 采：汇聚数据 3. 多源归集 做什么：将分散在不同业务系统中的数据统一汇聚到治理平台或数据底座中。 为什么重要：数据不汇聚，后续的清洗、标准和质量工作就无法集中执行。归集是打通数据孤岛的第一刀。 怎么做：根据数据类型和时效要求选择归集策略——结构化数据采用批量归集，龙石数据中台对单表精细化的场景可通过拖拽式画布设计数据流转，对需要一次同步多张表的场景可采用向导式批量勾选；需要秒级响应的场景采用实时归集（基于数据库日志的变更数据捕获）。归集过程需要处理数据库异构适配、字符集转换、字段映射等常见工程问题。 存：数据存储 4. 清洗转换 做什么：对归集后的存量数据进行格式统一、异常值处理、空值标记和数据类型转换。 为什么重要：原始数据中的脏数据如果不清理，后续的质量检测和AI训练都会受到影响。清洗是"让数据进入可用状态"的必要工序。 怎么做：格式化处理（日期格式统一、数值精度对齐）、异常识别（超出业务合理范围的值标记或剔除）、缺失值处理（按业务规则填补或标记为空）。清洗规则应当在治理平台中配置为可复用的模板，而非每次手工处理。 管：治理保障 5. 标准统一 做什么：统一数据的编码规范、命名规则、业务术语定义和指标计算口径。 为什么重要：这是AI数据集可信度的关键底座。如果同一个指标在不同系统中代表不同的含义，AI模型学到的是矛盾的信息——输出结果可能在语言上流畅，但在业务逻辑上自相矛盾。 怎么做：从核心主数据对象（如物料、客户、供应商、科目、项目等）入手，制定统一的编码规则和命名规范。然后扩展到关键业务指标的计算口径统一——明确每个指标的取数来源、计算逻辑和更新频率。标准制定后需要沉淀到治理平台中，作为数据接入和使用的强制校验基准。 华东某电子制造企业在治理过程中，从核心业务对象入手，逐一盘点各系统中的存量数据，统一编码规则和校验规范，产出了覆盖全集团的数据标准体系。这个过程的经验是：如果基础编码都没统一，再先进的AI模型也难以产出可信的结果。 6. 质量检测 做什么：依据国家标准定义的质量维度，对数据进行系统性的自动化质量扫描。 为什么重要：质量检测把"数据能不能用"从主观判断变成可量化的客观评价。只有经过质量验证的数据集，AI模型的输出才有可信度。 怎么做：以GB/T 36344-2018《信息技术 数据质量评价指标》[1]为框架。该标准定义了六个评价维度——规范性、完整性、准确性、一致性、时效性和可访问性。除可访问性侧重技术条件外，前五个维度直接影响AI应用效果：规范性决定数据是否按统一格式被模型稳定解析，完整性和准确性决定模型推理的信息基础是否可靠，一致性和时效性决定跨系统关联分析的结论是否可信。 在实操层面，质量检测通常采用旁路监测模式——数据正常入库，质量规则并行扫描，发现问题打标记、告警或生成工单，不阻断业务流程。这种方式在保证质量可见性的同时，不影响业务系统的正常运行。对于希望先开展质量摸底的企业，也可以通过支持 GB/T 36344 评价框架的数据质量工具，对核心数据源进行基线检测，在不影响原有业务流程的情况下识别主要质量问题。 7. 语义补充 做什么：为技术字段补充业务含义说明，让AI能够"读懂"数据。 为什么重要：数据库字段名是给开发人员看的，AI模型需要的是一层业务语义的"翻译"。一个字段叫"F_STAT_CD"，AI不知道它代表"订单状态"还是"客户级别"——除非元数据告诉它。语义补充的本质，是把数据库从"技术字典"升级为"业务字典"。 怎么做：通过元数据管理，为每个字段补充中文名称、业务定义、取值规则、关联关系等信息。这一步在技术上不复杂，但考验的是业务语义的统一能力——同一个业务概念在不同部门之间可能存在隐性差异，需要逐一拉通。在实际项目中，核心数据资产的业务口径梳理往往是投入时间较多的环节，但这一步一旦完成，AI就可以基于一致的语义进行查询和分析。 8. 安全处理 做什么：对AI数据集中可能涉及的敏感信息进行分类分级和脱敏处理。 为什么重要：AI数据集一旦形成，通常会被多个团队使用和分发。如果原始数据中包含个人信息、商业秘密或其他敏感内容，未经脱敏就进入训练流程，不仅存在合规风险，而且一旦泄露几乎无法追溯。安全处理是AI数据集在"可用"和"合规"之间的平衡点。 怎么做：结合 DCMM 2.0（GB/T 36073-2025）[2]的数据安全能力要求，以及现行数据安全和分类分级相关规范，对数据实施分类分级——区分一般数据、重要数据和敏感数据。对敏感字段实施脱敏处理（支持静态脱敏和动态脱敏两种模式），配置按角色、按数据级别的访问控制策略。安全策略还需要支持场景化配置——同一个数据集在内部AI训练、跨部门共享、对外合作三种场景下，脱敏策略和访问权限应当有所不同。 用：应用与交付 9. 版本管理 做什么：对AI数据集的每一次变更进行版本记录，确保训练过程可追溯、可回滚。 为什么重要：AI模型的迭代本质上是在数据上迭代。如果数据集的版本没有记录，当模型效果出现波动时，排查方向就少了一个关键变量——不知道是模型参数的问题还是训练数据变了。版本管理解决的是"这个模型到底是哪批数据训出来的"这个朴素但关键的问题。 怎么做：对数据集建立版本号机制，每次数据更新（新增数据源、调整清洗规则、补充语义标注等）生成新的版本快照。版本信息应至少包含变更时间、变更内容、变更人和变更原因。在治理平台中，版本管理通常与数据资产目录联动——同一份数据集的历史版本在目录中保持可查询、可对比。 10. 服务发布 做什么：将治理完成的AI数据集以标准化形式交付给AI团队或应用系统。 为什么重要：治理的终点不是一份质量报告，而是数据真正被用起来。服务发布是治理全链路从"内部工程"转向"对外交付"的最后一环。 怎么做：根据使用场景选择合适的交付方式——批量训练场景以数据集文件或数据表形式输出，实时推理场景通过API接口提供数据服务（龙石数据中台已支持一键发布API并配置访问控制），探索分析场景通过数据资产门户让AI团队自助检索和使用。交付时需要附带元数据说明文档（数据字典、字段含义、质量评估结果、更新频率），让使用方在做AI训练之前就知道数据的特点和边界。 三、持续治理机制：AI数据集不是一次性交付 走完十个环节，并不意味着治理工作结束。AI模型会迭代，业务数据会更新，数据集的治理需要从"一次性工程"转向"持续运转的机制"。 质量基线的持续监控。以十个环节走完时的质量状态为基准线，配置自动化监控规则，当质量指标偏离基线时自动告警。这相当于把质量从"一次性体检"变成"持续监测"。 数据集的版本追踪。每次数据集发布新版本时，同步记录变更内容和变更原因，确保任何一次模型训练都能对应到确定的数据集版本。这对AI项目中的问题排查和同行评审尤为重要。 反馈闭环。建立从AI应用效果回传到数据集优化的反馈链路——模型在特定场景下的准确率下降、某些特征在实际推理中表现不稳定——这些信号反向驱动数据集的改进策略。闭环一旦建立，数据质量就从"靠人盯"变成了"靠机制走"。 四、以"理采存管用"为框架看AI数据集治理 "理采存管用"五阶段方法论为这十个环节提供了一个结构视角。在"理"阶段搞清楚数据家底，在"采"阶段打通系统间的数据流转，在"存"阶段建立标准化基础，在"管"阶段落实质量和安全要求，在"用"阶段以产品化方式交付——各阶段层层递进，构成了从业务数据到AI数据集的完整价值链。 从DAMA数据管理知识体系（DAMA-DMBOK2）[3]的视角来看，这十个环节覆盖了数据质量管理、元数据管理、主数据管理、数据安全管理和数据集成与互操作等多个核心知识领域。AI数据集的治理不是凭空创造一套新规则，而是将成熟的数据管理实践聚焦到AI这一特定消费场景上。 从多数项目的实践经验来看，在核心数据域完成基础治理后再启动AI应用，比"边用边治"更可控。正如前述电子制造企业的实践所示——如果底层编码都没统一，上层分析就缺乏可靠基础。数据治理的深度，直接决定了AI数据集的最终可信度。 FAQ *Q1：十个环节听起来很多，小团队怎么入手？* 不需要一开始就追求全量覆盖。选取AI应用瞄准的一到两个核心业务域，从数据盘点和质量基线做起，先跑通一条完整链路。企业可以优先从质量基线检测和核心数据语义补充入手，这两项工作通常更容易形成阶段性成果。如果希望先低门槛地摸清数据质量现状，也可以通过免费的质量检测工具做一次基线扫描——例如龙石数据质量管理平台·社区版，部署后即可对核心数据源进行 GB/T 36344 标准框架下的自动化质量检测。 *Q2：已经有数据中台了，还需要专门的AI数据集治理吗？* 两者并非相互替代。数据中台为数据归集、治理和服务提供基础能力，AI数据集治理则进一步面向具体AI场景，对语义、质量、版本和使用反馈提出针对性要求。简单来说：中台把路修好了，但AI需要的路标、信号灯和定期养护需要专门设计。 *Q3：语义补充和元数据管理是一回事吗？* 元数据管理是基础设施——采集技术元数据和业务元数据。语义补充是在元数据基础上的"AI定向增强"——重点是为AI模型提供结构化、可查询的业务语义字典，确保模型能够正确地将业务术语映射到具体的表和字段上。两者的关系是：元数据管理搭框架，语义补充做精装。 *Q4：数据安全和模型安全是什么关系？* 数据安全关注"数据本身的敏感信息保护"——分类分级、脱敏处理、访问控制。模型安全关注"模型输入输出层面的攻击防护"——提示词注入、越狱攻击等。两者是上下游关系：数据安全做不好，敏感信息进入训练数据，模型安全就成了无源之水。结合 DCMM 2.0[2]的数据安全能力要求及现行安全规范，数据脱敏和访问控制是两者之间的衔接点。 参考来源 [1] GB/T 36344-2018《信息技术 数据质量评价指标》，国家市场监督管理总局、中国国家标准化管理委员会 [2] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0），全国信息技术标准化技术委员会 [3] DAMA International，《DAMA数据管理知识体系指南（DAMA-DMBOK2）》，机械工业出版社 [4] 龙石数据，AI用数智能体，https://www.longshidata.com/products/aianalysis.html
8月12日（周三）晚8点，龙石数据创始人兼总经理练海荣应国际数据管理协会（DAMA）大中华区主席汪广盛邀请，围绕“AI赋能数据治理，重构数据价值新生态”主题，分享AI与数据治理融合发展的实践探索，拆解企业级AI数据中台的建设思路与落地路径。
三份重量级政策文件在两年内相继出台，从制度、财务、流通三个维度，一步步将数据中台的角色从"数据管道"推向了"资产管理基础设施"。 2022年12月，"数据二十条"（《关于构建数据基础制度更好发挥数据要素作用的意见》）率先发布，以数据资源持有权、加工使用权、产品经营权"三权分置"的框架，第一次在法律层面为数据被界定为"资产"扫清了制度障碍。2023年8月，财政部《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号）紧随其后，于2024年1月正式施行——数据入表进入实操轨道，数据治理不再是IT部门的内部事务，而是直接关联企业资产规模和财务表现的CFO议题。2024年1月，国家数据局发布"数据要素×"三年行动计划（2024—2026年），政策重心从"确权入表"进一步延伸到"合规流通"——数据不仅要管好入好，还要能在合规前提下对外共享和交易。 三份文件的发布时间线，清晰地勾勒出了政策演进的方向：先确权→再入表→后流通。而每一步对数据中台的要求都在升级——确权需要中台提供资产视图，入表需要中台提供质量依据，流通需要中台构建安全可控的数据服务能力。对于已经在数据中台上投入了大量资源的企业而言，这三份文件既意味着新的合规压力，也意味着前所未有的价值释放窗口。 一、三份政策叠加，数据中台的角色正在被重新定义 2022年底发布的"数据二十条"（《关于构建数据基础制度更好发挥数据要素作用的意见》）为数据资产的讨论建立了一个制度基础——数据资源持有权、加工使用权、产品经营权三权分置，让数据在法律层面第一次具备了被界定为"资产"的前提。在此之前，企业即便拥有海量数据，也无法在法律上清晰说明这部分资源的所有权和收益归属。三权分置框架解决了这一底层问题。 紧接着，财政部《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号）于2024年1月正式施行，让数据资产从理论探讨进入了实操层面。这份文件的核心意义不在于定义了某种新的会计科目，而在于让数据治理从一个IT部门的事情变成了CFO的需求——数据能不能入表，直接关系到企业的资产规模和财务表现。而要回答"能不能入表"这个问题，需要三个前置条件：数据范围明确、质量可审计、价值可评估。这三个条件中的每一条，都需要数据中台来承载。 2024年初，国家数据局发布"数据要素×"三年行动计划（2024—2026年），标志着政策从"确权"和"入表"进一步延伸到"流通"。数据不仅要管好、入好，还要在合规前提下对外共享和交易。这对数据中台提出了更高要求——不仅要管理内部数据，还要构建数据服务能力，支撑数据从内部资产向外部要素的转化。 三份文件叠加在一起，指向的是一个共同的信号：数据中台不能只做数据归集和加工的技术平台，它需要成为支撑数据确权、估值、质量保障、合规流通的资产管理基础设施。这个转变不是"锦上添花"的升级选项，而是政策推动下正在发生的角色重塑。 二、入表倒逼中台升级：三项核心能力必须补齐 数据资源入表看起来是财务操作，但实际上它反向倒逼企业补齐数据中台长期缺失的三项能力。 第一项是数据资产盘点——回答"有什么"。 入表的第一步是界定资产范围：哪些数据资源符合入表条件，哪些只是日常运营中产生的业务副产品？没有一套清晰的资产目录，入表范围就是一笔糊涂账。很多企业的数据中台存了大量的数据表，但从未从"资产"的视角做过梳理——这些数据分布在哪些系统、归属于哪些业务域、各自的数据特征和治理水平如何，一概不清楚。资产盘点的本质不是技术问题，而是管理问题：它需要企业建立一套从业务视角出发的数据资源分类和评估标准。 第二项是数据质量验证——回答"值不值钱"。 数据资产入表需要会计师事务所出具可审计的意见，而审计的前提是数据质量可以被验证。GB/T 36344-2018《信息技术 数据质量评价指标》定义了规范性、完整性、准确性、一致性、时效性、可访问性六个维度，为企业提供了标准化的质量评估框架。如果企业的数据中台无法基于这套框架输出结构化的质量评价结果，入表就缺乏量化依据——"凭感觉入表"在审计上走不通。 第三项是合规管理——回答"能不能流通"。 入表只是起点，数据资产后续的共享、交易和融资，都涉及安全合规。数据安全法和数据分类分级制度划定了底线：数据能不能对外提供、以什么方式提供、需要满足哪些安全条件——这些规则都需要在数据中台层面落实。中台如果缺乏统一的安全管控能力，数据资产即便入了表，后续的流通环节也会处处受阻。 这三项能力的共同特征在于：它们不是靠外部审计机构临时进场就能一次性解决的。资产目录需要持续维护、质量监测需要常态化运行、合规管控需要嵌入数据流转的每一个环节。数据中台必须把这些能力内建到平台架构中，而非依赖人工和Excel的临时补救。 三、DCMM 2.0释放的信号：国家标准层面，"数据资产"被正式确认 政策层面的推动，在标准层面很快得到了呼应。2025年发布的DCMM 2.0（GB/T 36073-2025，于2026年7月正式实施）对能力域进行了结构性调整：能力域数量从1.0版本的八个扩展到九个，其中最引人注目的变化是新增了"数据资产"能力域，排在九大域中的第四位。同时，"数据应用"域更名为"数据应用流通"，反映出了从内部应用到外部流通的能力延伸。 DCMM 2.0的九大能力域包括：数据战略、数据治理、数据架构、数据资产（新增）、数据标准、数据质量、数据安全、数据生存周期、数据应用流通。新增的"数据资产"域重点考察企业的三项能力：资产盘点（有没有清晰的资产视图）、价值评估（能不能量化数据资产的业务价值）、资产运营（数据资产能不能持续产生效益）。对照前面政策文件的要求，可以发现DCMM 2.0的"数据资产"域所考察的内容，恰好对应了数据资源入表和流通的前置条件。 从九大域与数据中台的关系来看，数据架构、数据资产、数据标准、数据质量、数据应用流通这五个域与数据中台高度相关，数据治理、数据安全、数据生存周期三个域有中等关联度，数据战略域偏组织层面。这意味着DCMM贯标评估中约有半数以上的能力域需要数据中台作为技术承载——数据中台的成熟度，在相当程度上决定了企业DCMM评估能达到的等级。 DCMM 2.0的意义在于，它把政策层面的"数据是资产"从宏观判断落地成了可评估、可分级的管理标准。政策说数据是资产，标准说怎么评估企业资产化管理的能力。在这两者之间，数据中台是最核心的技术承载平台。 四、理采存管用：在政策与标准之间架设工程落地路径 企业CDO在读完政策和标准之后，往往会面对一个更实际的问题：知道了"应该具备什么能力"、知道了"要达成什么结果"，但从哪里开始？分几步走？ 在这个问题上，龙石数据提出的"理采存管用"五阶段方法论提供了一套工程化的落地框架。它与DCMM标准、外部政策之间的关系可以概括为：DCMM是检查清单（定义了企业数据管理应具备哪些能力），政策是考核指标（规定了数据资产化的方向和目标），而理采存管用是施工图纸（告诉企业在不同阶段分别做什么）。 在数据资产化的语境下，理采存管用五个阶段分别获得了新的解读： 理（资产盘点）：入表前必须搞清楚企业拥有哪些数据资源，哪些具备资产属性。这是一个从"数据在哪里"到"资产有什么"的视角转换。 采（打通资产供应链）：数据分散在不同业务系统中，不汇聚到一处就无法形成统一的资产视图。采的作用就是把各系统的数据归集到一起，为后续的资产化管理提供数据基础。 存（建立资产统一量纲）：不同系统对同一业务实体的编码方式不同、口径不同。如果没有统一的数据模型和标准化的仓库分层，资产目录就会出现"看起来有资产、实际上对不上账"的问题。 管（保障资产可信度）：这是资产化最关键的环节。如果数据治理不到位，入表就只是账目改编。标准规范落标稽核、质量常态化监测、元数据持续维护——这些"管"的动作，决定了入表后的资产到底是"实打实的数据资产"还是"经不起审计的账面数据"。 用（释放资产价值）：入表是起点，用出价值才是终点。资产目录上线后，数据服务、API调用、智能分析等应用场景才能让数据资产真正产生业务回报。 理采存管用的核心价值在于，它把政策要求和标准框架翻译成了可执行的分阶段任务，让数据中台建设从"功能堆砌"变成了"目标导向的能力构建"。每一个阶段的产出，都对应了入表和DCMM贯标中的一个具体前置条件。 五、案例验证：一条已经走通的全链路路径 政策的窗口期不会一直敞开。在多数企业还在论证"数据能不能入表"的阶段，已有先行者完成了实践闭环。 福建某交投集团（企业名称已脱敏，下同）是负责城市数字化运营的核心主体，旗下拥有充电系统、调度系统、安防系统等多个业务系统，积累了大量数据资源。然而这些数据分散在上千张业务表中，家底不清、质量未知——这是多数企业在面对数据资产入表时的典型状态。 项目从资产盘点入手。团队花了数周时间梳理上千张业务表，依据资产入表条件划定边界，识别出充电订单、支付流水、用户档案、对账记录等核心数据资源，最终形成了一份标准化的《企业数据资产目录》。这一步解决的是"哪些数据能入表"的问题。 第二步转向质量保障。以GB/T 36344-2018六个维度为框架，对拟入表的数据资源进行全量自动化质量评价。通过问题清单协助完成了数据修复与整改，最终质量评价总评分达到99.53分，为会计师事务所提供了可审计的质量依据。这一步解决的是"数据能不能经得起审计"的问题。 第三步完成入表确认。律所依据质量报告和资产目录完成合规审查，资产评估机构基于治理成果进行估值，会计师事务所最终完成入表确认。企业资产负债表上新增了一笔数据资产，成为福建省某市首批完成数据资产入表的国有企业。 这个案例说明了一个关键判断：数据资产入表看起来是财务工作，但真正决定成败的环节全在数据治理。资产盘点（理）→ 标准建设（管）→ 质量评估（管）→ 入表确认（用），每一步都在验证治理能力是否到位。治理到位，入表就是水到渠成的产出。 六、窗口期不等人：给CDO的三个行动建议 政策推动的转变往往具有窗口期特征。早期入局者不仅能获得先发优势，还能在后续的数据交易、资产融资等环节占据更有利的位置。对于还在观望阶段的CDO和CIO，有三个动作可以立刻着手。 先摸清家底，不用等完美方案。 选1-2个核心业务域，先做一次数据资产盘点和质量基线评估。不一定现在就回答"数据值多少钱"，但至少要知道自己有什么、数据质量处于什么水平。很多企业卡在"全量入表"的宏大叙事中迟迟不启动，现实中从一两个业务域先跑通全链路，远比等待全局论证更务实。 把资产化能力建在数据中台上。 资产目录编目、数据标准落标、质量常态化监测——这些不是靠外部咨询机构进场一周就能持续运转的能力。它们必须内建在数据中台里，靠系统自动化执行，而非依赖人工维护。目前，部分数据治理平台已经遵循理采存管用方法论进行模块化设计，资产盘点、标准落标、质量闭环等功能可以按需装配，企业能从一个业务域先跑通全链路再横向扩展。 让治理跑在入表前面。 入表是结果而不是目的。把理采存管用的前四步——资产盘点（理）、数据归集（采）、统一模型（存）、质量保障（管）——跑扎实，入表自然水到渠成。反过来，如果跳过治理直奔入表，即便勉强完成，入表后的数据资产也未必经得起后续的审计和估值检验。从多数成功案例来看，较为稳妥的路径是让治理的进度始终领先入表一个身位。 常见问题（FAQ） Q1：做了数据中台，是否一定能满足数据资产入表？ 不一定。数据中台解决的是数据归集、加工和治理的技术支撑问题，而数据资产入表还需要额外的环节——资产范围确认、质量评估报告、合规审查和会计确认。中台提供了必要的数据基础，但入表本身是一个涉及多方专业机构协同的流程。关于入表的具体前置条件，可以参考本文第二节中三项核心能力的拆解。 Q2：DCMM贯标评估和资产入表是什么关系？ 入表依据的是财会〔2023〕11号，是财务侧的操作规范；DCMM 2.0（GB/T 36073-2025）是企业数据管理能力的评估标准。两者不直接等同，但存在高度关联——DCMM 2.0新增的"数据资产"能力域考察的资产盘点、质量评估和价值管理能力，恰好是入表所需的前置条件。完成DCMM贯标的企业，在入表过程中会发现很多前置工作已经就绪。 Q3：中小企业是否有必要做数据资产化？ 有。中小企业的数据体量虽然远不及大型国企，但核心业务数据的价值并不小。不需要追求全量入表，可以从核心业务域的数据资产目录和质量管理起步。如果预算有限，市场上有部分免费可用的数据质量工具——例如龙石数据质量管理平台·社区版，覆盖GB/T 36344六个维度中的核心检测项，可以作为入表前的数据质量核验工具，先摸清质量基线再做投入决策。 参考来源： [1] 中共中央、国务院，《关于构建数据基础制度更好发挥数据要素作用的意见》（"数据二十条"），2022年12月 [2] 财政部，《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号），2023年8月，2024年1月1日起施行 [3] 国家数据局，《"数据要素×"三年行动计划（2024—2026年）》，2024年1月 [4] 全国信息技术标准化技术委员会，《GB/T 36073-2025 数据管理能力评估成熟度模型》（DCMM 2.0），2025年发布，2026年7月实施 [5] 全国信息技术标准化技术委员会，《GB/T 36344-2018 信息技术 数据质量评价指标》，2018年发布 [6] 龙石数据，《数据治理实战指南》，— https://www.longshidata.com/lsdmaterial/dg-guide.html
龙石数据中台 V3.9.2 聚焦全链路安全加固、平台功能瘦身、运维体验精细化三大方向迭代升级。
