CFO在企业微信上@了数据团队负责人："财务部在推进数据资产入表，需要一份集团现有数据资产的清单——下周五之前能给出来吗？" 数据团队负责人打开手头的系统看了看：充电、支付、调度……几十个系统上散落着上千张表，同一类充电桩数据在三个系统里有三种命名规则。他回了一句："我尽量。" 这不是虚构场景。华东某交投集团启动数据资产入表时，面临的第一个问题就是这个——"家底"到底是什么。 一、入表的第一个关口：不是会计处理，是资产盘点 很多企业把"数据资产入表"理解成一个会计问题——财务部牵头，审计师确认，年底前走完流程就行。但从实际执行来看，入表的全流程六个环节中，前三个——资产盘点、资产登记、质量评价——本质上都是数据治理工作，和会计分录几乎无关。 一个基础判断逻辑是：元数据能不能自动采集、数据标准有没有统一、质量问题能不能量化、资产目录编不编得出来——这四个条件加起来，基本决定了企业距离"入表就绪"还有多远。四个条件少一个，到了审计环节就可能被退回。 这个判断逻辑也和政策走向一致。DCMM 2.0（GB/T 36073-2025）[1]将"数据资产"新增为独立能力域——从"有没有治理"到"能不能资产化"，标准本身也在跟进企业的实际需求。配合财政部财会〔2023〕11号《企业数据资源相关会计处理暂行规定》[2]的落地，入表已不再是政策空转，而是国企财务合规的实质要求。 但在讨论"怎么入表"之前，需要先回答一个更基础的问题：企业的数据家底到底是什么样的。 二、家底一团乱：入表之前的三道坎 华东某交投集团的IT基础设施并不差——充电系统、支付系统、调度系统、用户服务平台，几十个业务系统常年运行，积累了海量数据。但启动入表时，项目组发现要迈过的坎不在会计技术上。 坎一：资产底数不清。 上千张业务表分散在不同数据库中，没有一份完整的资产清单。充电桩数据分散在三个系统里，各自有不同的命名规则——有的叫"桩状态"，有的叫"充电设备信息"，有的沿用开发文档里的内部代号。没人能对着CFO说清楚：集团到底有哪些数据、分布在哪里、哪些具备资产属性。 坎二：质量参差不齐，无从量化。 这批数据一直在支撑业务运转——支付系统跑着、充电桩运营着，表面上没什么问题。但从来没有做过系统性质量评估。哪部分"干净"、哪部分存在缺陷，只能靠经验判断。会计师事务所提出的要求是明确的：入表数据需要有可审计的质量依据。企业拿不出来。 坎三：流程复杂，缺乏统筹经验。 资产盘点、合规审核、质量评价、价值评估、会计确认——这五个专业领域横跨IT、法务、财务、评估多个部门。此前集团从未完整跑通过一次全流程，各部门之间的衔接标准和工作语言都不统一。 顾问团队进场后的第一个判断是："先不谈入表，先把家底盘清楚。" 三、从翻Excel到自动扫描：资产盘点的完整过程 "家底盘清楚"这句话听起来简单，但落到操作层面，是从上千张表中梳理出"一本清账"的系统工程。 全量扫描：不是从零开始手工整理。 如果靠人手工打开每个数据库，逐一登记表名、字段、数据量，上千张表的盘点周期可能要以月计。项目组借助数据中台的元数据自动采集能力，对各业务系统做全量扫描——上千张表、数万个字段，系统自动识别表结构、字段类型、数据量、更新频率。很多企业在这个过程中第一次发现：同一个充电桩的数据，在三张表里以三种结构共存。 业务规则筛选：划定入表边界。 自动化扫描解决了"有什么"的问题，但入表需要的不是一张全量清单，而是"哪些具备资产属性"。项目组和业务部门逐一确认：充电订单数据——直接产生收入，纳入入表候选；系统运行日志——运维辅助，暂不入表；用户支付流水——可量化、可估值，纳入入表。最终从上千张表中识别出充电订单、支付流水、用户档案、对账记录等核心数据资源。 形成资产目录：给出"一本清账"。 筛选完成后，项目组将每一项数据资产标准化——业务含义、覆盖范围、更新频率、质量状态逐一明确。最终产出一份《企业数据资产目录》，让业务人员用业务语言就能理解数据资产，也让CFO和审计师有了一份可以审阅的正式资产清单。从"IT部门自己维护的Excel"变成了"管理层可以讨论的资产台账"。 四、有了目录还不够：质量评价为入表"上保险" 资产目录给企业提供了一个清晰的盘点结果，但入表还需要一个更严格的步骤——让数据质量变得可以量化、可以被第三方审计。 项目组以GB/T 36344-2018《信息技术 数据质量评价指标》[3]为框架，对拟入表数据进行全量自动化质量扫描。标准定义了六个评价维度：规范性、完整性、准确性、一致性、时效性、可访问性——直接影响入表数据的可信度。 扫描结果并不意外：订单状态字段存在不规范填写，部分时间字段与实际业务操作存在偏差，不同系统的支付渠道代码不一致……这些问题在日常业务中可能不影响使用——订单照付、充电桩照常运营——但在审计师眼里，任何质量缺陷都可能成为"数据不可信"的依据。 借助自动化质量评价工具，项目组对发现的问题分类打标、推动修复。修复后的数据再次扫描，最终质量评价总评分达到99.53分（满分100分），会计师事务所据此确认质量符合入表要求。从"从来没评估过"到"99.53分"，这一步为后续估值和会计确认提供了量化底线。 五、生态协同：入表不是一家能做完的事 数据质量评价只是入表链条中的一个环节。完整的入表需要六个专业角色协同作业：资产盘点→资产登记→质量评价→合规审核→价值评估→会计入表，各环节成果相互印证。 在这个项目中，康桥数据承担了质量评价环节，同时联合律所和会计师事务所、资产评估机构，以生态协同的方式提供全链条服务——律所依据质量报告完成合规审查，资产评估机构基于质量和合规结果进行价值评估，会计师事务所最终完成入表确认。 这种模式回应了一个行业现实：企业推进入表时，最头疼的问题之一就是"找不到能一站式完成的单一服务商"。数据质量评价、法律合规审查、资产评估、会计确认分属四个专业领域，任何一个环节缺失或脱节，链条就断了。生态联合的意义不在于"一家公司什么都做"，而在于"各环节有人兜底、成果互认"。 六、首批入表之后：资产化管理才刚开始 经过全流程推进，华东某交投集团成功将符合条件的支付类数据资源纳入企业资产负债表，数据资产首次获得了合法的会计身份。这也是该省某市首批完成数据资产入表的国有企业实践。 比"入进去了"更重要的，是"能持续"——形成《企业数据资产目录》和筛选标准之后，这套方法和工具可以直接复用到其他业务线，大幅降低未来的重复投入。入表不是一次性的突击任务，而是资产管理能力的一次检验。 从更长的周期看，入表后的数据资产具备了可量化价值，为质押融资、资产证券化等金融创新提供了基础。企业的角色，从"数据持有者"向"数据资产经营者"演进。 复盘整个项目，有一个结论值得留意：入表最终能顺利通过，不是因为评估方法有多精妙，也不是因为会计处理有多复杂——而是前面的资产盘点和标准统一走扎实了。这一步没人能代劳，也没人能跳过。 结语 入表不是会计部门的独角戏，但也不意味着每个企业都需要像案例中的交投集团那样一步到位全量铺开。对于还在观望的企业，有三个思路可以参考。 先盘点，再谈标准。 如果还不知道自己有什么数据，定标准容易做出一堆没人用的规范。用资产盘点先把范围画出来，后续的标准建设、质量治理才有明确的靶子。 选一个高价值域先跑通。 不需要像上千张表的规模——从一到两个核心业务域起步，产出一份小范围的资产目录和质量基线。跑通一个闭环，比在全量维度上反复论证更有说服力。 把能力建在平台上，不是Excel里。 资产盘点、质量评价、目录管理——这些工作如果每次入表都靠手工从头做一遍，入表的常态化就无从谈起。市场上已有部分数据中台产品（如康桥数据中台）将这些能力沉淀为平台级的核心功能，元数据自动采集、质量自动化扫描、资产目录管理不再是"入表项目专属"，而是可以持续运作的治理基座。 FAQ Q1：数据治理做到位了，就一定能入表吗？ 不一定。治理是必要条件但不是充分条件。数据质量不过关，估值无从谈起；标准不统一，资产边界就划不清——这些取决于治理扎实程度。但入表本身还需完成资产确认、合规审核和价值评估。准确的理解是：治理到位是入表的前提，入表是治理成果在财务层面的确认。 Q2：中小企业资源有限，怎么启动数据资产盘点？ 不需要全量铺开。选一到两个核心业务域，花几周时间做资产盘点加质量基线。关键是先把家底摸清楚——这和企业规模无关。如果缺少工具，可以先用免费的数据质量评估工具做一次全量扫描，了解数据的质量基线再做规划。 Q3：资产盘点和数据治理应该先做哪个？ 先盘点。用盘点先摸清家底，再判断哪些数据值得投入治理资源。如果反过来——还不知道自己有什么数据就开始定标准、建模型——容易做出一堆没人用的规范。从多数成功案例来看，较为稳妥的做法是盘点先行、治理跟进、入表自然接续。 参考来源 [1] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0） — openstd.samr.gov.cn [2] 财政部，《企业数据资源相关会计处理暂行规定》（财会〔2023〕11号），2023年8月 — gov.cn [3] GB/T 36344-2018《信息技术 数据质量评价指标》 — openstd.samr.gov.cn [4] 康桥数据，数据中台产品，government.html
一所211大学的老师想做一个简单的跨部门数据分析——比如学生成绩与图书馆借阅记录的关联——需要走纸质申请、找多个处室盖章审批，周期按天计算。这不是个例。在相当多的高校，数据不是"资产"而是"孤岛"——它们被锁在各个业务系统里，彼此隔绝，取之不易。 很多高校以为自己缺的是新系统，实际上缺的是一个能让数据流动起来的中台底座。 一、高校信息化的"繁荣"与"割裂" 经过多年信息化建设，一所普通高校通常积累了数十个业务系统：教务、科研、人事、学工、资产、一卡通……每个系统都有自己的数据库，建的时候各管各，跑起来互不相通。表面上看系统齐全，但跨部门的数据协作往往退回到最原始的方式——手工导出Excel，邮件传来传去，一个口径能对出三四个版本。 这种"繁荣"下的"割裂"，集中体现在三个层面。 不通。 各系统数据独立存储，跨部门的分析需求靠人工拼接。教务想知道各学院经费使用效率，科研处想评估实验室设备利用率，都需要找人、等审批、对口径——周期动辄数天甚至数周。 不准。 同一个学生在教务系统、一卡通系统、学工系统中的学号、姓名、院系字段可能不一致。缺乏统一的数据标准，跨系统数据关联时"对不上号"是常态。 不全。 大量线下行为数据——实验室使用情况、校园能耗、图书馆入馆记录——没有被系统化采集和沉淀，游离在数据资产之外。 更棘手的是老旧平台的困境。不少高校的早期数据平台已超出原厂维保期，核心组件超期服役。系统偶发的同步异常可能直接影响一卡通充值、财务结算、教务选课等核心业务。运维高度依赖原厂，学校信息化部门面对新需求响应迟缓，智慧校园的蓝图卡在了数据底座的"老化"上。 二、从"功能上线"到"数据运营"：一个211大学的破局之路 江苏一所211大学面临的就是这样的局面。该校原有的公共数据平台建成多年后，逐渐从"支撑者"变成了"绊脚石"——核心组件超出原厂维保期，系统稳定性下降，同步异常直接影响一卡通、财务、教务等核心业务的顺畅运行；架构封闭导致运维高度依赖原厂，故障处置滞后；数据资源分散、缺乏统一的资源地图，师生申请和使用数据的流程繁琐、体验割裂。 2023年，项目启动后，康桥顾问团队进场做了全面诊断。核心判断并不复杂：学校不是缺业务系统，而是缺一个架构开放、运维自主、服务敏捷的新一代数据基座。旧平台的"黑盒式"交付模式，让信息化部门既管不住数据、也接不住需求。 围绕"平滑迁移、能力升级、体验革新"三个目标，项目团队制定了四步方案。 架构重构与平滑迁移。 方案采用分层解耦的五层架构——基础设施层、业务来源层、贴源汇聚层、数据治理层、数据应用层——确保系统高内聚、低耦合，易于扩展维护。经充分评估，保留了承载海量核心业务且运行稳定的 GaussDB 200 数据库，规避大规模数据迁移风险；同步替换升级了原有的数据集成与治理平台，新建数据探查编目、数据超市等核心能力模块。迁移不走"一步到位"——数据、流程、接口按优先级分批推进，每批次迁移后设置一至两周监控观察期，确保核心业务零感知、无中断。 全域数据探查与标准化治理。 通过数据探查与编目系统，自动盘点各院处的业务数据，形成全校统一的数据资源清单，彻底摸清家底。利用多表归集和批量归集流程开发，将教务、科研、人事、学工、资产、一卡通等分散异构数据规范高效地汇聚到统一数据资源中心。再借助可视化数据开发套件——涵盖清洗、加工、流程编排——对入仓数据进行标准化治理，沉淀为高质量、可复用的核心数据资产。这一过程对标 DCMM（GB/T 36073-2025）[1]数据标准与数据质量域的能力要求，确保治理成果可评估、可复现。 数据服务化与自助消费。 建设面向全校的数据超市与数据网关：数据超市以"商品货架"形式清晰陈列可共享的数据资源、API服务与产品，师生通过菜单点选或API调用即可自助申请标准化数据；数据网关提供API的自动化配置、生成与全生命周期管理，支撑跨部门服务高效流通与安全管控。数据从"找人审批"变成"即取即用"。 智能化运维保障。 监控中心实现从主机、数据库到数据归集与开发任务的全景一体化监控，支持自定义CPU、内存、任务耗时、记录数等关键阈值。异常发生时，系统通过微信、短信、邮件等多渠道自动告警并附带详细原因，运维模式从被动应对转向主动保障。 实施分三个阶段推进：底座搭建与平稳迁移→能力建设与体验提升→深化运营与持续赋能。每一阶段验收通过后才进入下一阶段，不求快，求稳。 项目中一段插曲值得记录。康桥顾问进场后发现，最大的阻力出人意料地不在技术上——各部门对"数据共享"的顾虑才是第一道坎。教务处担心数据被"拿去考核"，后勤处疑虑"数据出去了还能不能管得住"。项目组没有硬推，而是先以校领导最关心的几个跨部门指标为牵引——各学院经费使用效率、跨部门审批平均耗时——用数据超市的第一个试点让各部门看到共享的价值。数据摆出来、效果看见了，阻力自然消解。 三、从"数据中台"到"一表通"：让数据服务师生 数据底座建好之后，变化是具体且可量化的。 跨部门数据申请从"天/周级"协调缩短为"分钟级"在线自助获取。过去老师申请一个跨域数据集，平均需要跑 3 至 5 个处室、填若干张表、等各级审批——周期按天算，短则 3 个工作日，长则超过两周。现在登录数据超市，搜索、申请、审批、获取，全程在线，平均 10 分钟内即可完成。 更深层的变化体现在"一表通"场景的落地。项目上线运行一年后，"一表通"已覆盖学生奖助学金申请、教师职称评审、新生入学信息核验、毕业生离校手续等 12 个高频业务场景。过去学生申请一项奖学金需先后跑学工处、财务处、后勤处开具 5 份证明，现在系统自动调取成绩、消费、宿舍等数据，一键生成申请表。教师职称评审时，科研成果、教学课时、社会服务数据自动汇聚，填报从平均 3 天的重复劳动变成半小时的核对确认。据学校信息化部门统计，"一表通"上线后，师生对信息化服务的满意度较之前提升了超过 40 个百分点。 信息化部门的角色也发生了根本转变。用该校项目负责人的话说："过去老师申请个数据，得跑断腿、磨破嘴、盖遍章；现在数据底座升级成了'超市'，动动鼠标就像逛淘宝，几分钟搞定。这不光是系统的焕新，更是我们这帮人从数据存储仓库升级为数据资产运营平台。" 四、启示：高校数据治理的三条经验 回看这个211大学的建设历程，有三条经验对面临类似问题的高校具有普遍参考意义。 不贪多求全。 一所高校几十个业务系统，不可能一口气全部打通。较为务实的做法是先挑教务和学生两个核心域——与教学和人才培养直接相关的数据，覆盖面最广、业务价值最高。把核心域的数据跑通、用起来、见到效果之后，再逐步扩展至科研、人事、资产等其他域。一上来就铺大盘子，容易在漫长的建设周期中消耗掉各方的耐心。 数据服务化是关键。 建数据中台不是为了"存数据"，而是为了让数据流动起来、被师生用起来。数据超市和API网关的价值不只在技术上统一了出口，更在于降低了用数门槛——从"找人审批"到"自助获取"，这个体验上的跨越，是数据中台被学校各部门真正接纳的分水岭。这一理念与教育部《教育信息化2.0行动计划》[2]中"推动从教育专用资源向教育大资源转变、从提升师生信息技术应用能力向全面提升信息素养转变"的方向一脉相承。 组织协同比技术更硬。 高校的组织架构是典型的条块分割，每个处室、每个学院都有自己的数据主权意识。技术平台搭得再好，如果各部门不愿意把数据拿出来共享，中台就是空壳。从这个211大学的经验看，以校领导关注的跨部门指标为牵引，让各部门在共享中先看到收益，比用行政命令"硬推"有效得多。IT部门搭台、业务部门唱戏，数据治理才能真正从项目变成常态。 高校智慧校园建设的下半场，比拼的不是上了多少系统，而是数据能不能真正"跑起来"。当数据从孤岛走向融合、从成本中心走向数字资产、从IT部门走向每一位师生，智慧校园的承诺才算落了地。"数据二十条"[3]明确的数据产权结构性分置和数据要素市场化配置方向，为高校数据资产的激活与流通提供了制度性指引——数据不仅需要被治理，更需要被作为资产进行管理和运营。 常见问答（FAQ） Q1：高校数据中台与传统的共享数据中心有何本质区别？ 传统共享数据中心的核心逻辑是"把数据搬到一个库里"，解决的是存储集中问题。数据中台的核心逻辑是"让数据可治理、可复用、可服务"，解决的不只是"存"的问题，更是"治"和"用"的问题。具体差异体现在三个层面：一是中台自带数据治理能力（标准管理、质量稽核、资产编目），传统中心库通常不具备；二是中台通过数据超市和API网关实现"数据服务化"，师生可自助获取而非依赖IT部门手工导出；三是中台采用分层解耦架构，可在不中断业务的前提下完成平台升级和组件替换——这正是本案例中江苏某211大学能够平滑迁移旧平台的关键。 Q2：一表通服务的建设需要哪些前提条件？周期通常多久？ 一表通不是孤立的应用功能，而是数据治理成果的自然产物。其前提条件包括：① 核心业务域数据已完成标准统一和入仓（教务、学工、人事、科研等）；② 跨系统数据已建立关联映射（学号/工号作为主键打通各系统）；③ 数据质量已达到可自动汇聚的水平。在本案例中，以上前提条件的建设耗时约 6 个月（含平台迁移），一表通首批场景（学生奖助学金申请）在底座上线后 2 个月内投入使用。整体从项目启动到一表通覆盖 12 个场景，周期约 12 至 14 个月。 Q3：高校数据治理如何平衡数据共享与隐私保护？ 这是高校数据治理中最敏感的议题，也是本案例中项目推进的最大阻力来源。该校的做法提供了三层防护：一是明确数据分级分类——涉及师生个人身份、成绩、消费等敏感数据的共享须经脱敏处理，仅限特定角色在审批后访问；二是数据网关的权限管控——每条数据服务的调用都需经过认证、授权和审计，可追溯到每一次访问记录；三是"最小必要"原则——一表通场景中仅调取与该业务直接相关的数据字段，不过度汇聚。这三层机制让各部门在"看得到管控"的前提下愿意共享数据，是在高校体制内推进数据融合的现实路径。 Q4：老旧高校数据平台迁移有哪些关键风险？如何规避？ 老旧平台迁移的最大风险不是技术兼容性，而是核心业务中断。本案例的应对策略是"分批迁移+监控观察期"：数据按业务域分批迁移，每批次上线后设置一至两周监控观察期，确认一卡通、教务选课、财务结算等核心业务无异常后再推进下一批次。此外，保留运行稳定的底层数据库（本例中为 GaussDB 200）作为过渡，避免一次性大规模数据搬迁引发不可逆风险。对于承载核心业务的老旧组件，建议保留至少一个完整学期的并行观察期后再执行下线。 参考来源 [1] GB/T 36073-2025《数据管理能力成熟度评估模型》（DCMM 2.0） — openstd.samr.gov.cn [2] 教育部，《教育信息化2.0行动计划》，2018年4月 — moe.gov.cn [3] 中共中央、国务院，《关于构建数据基础制度更好发挥数据要素作用的意见》（"数据二十条"），2022年12月 — gov.cn [4] 康桥数据，数据中台产品，government.html
采购计划员拿到两份报价单：供应商报的是"钛白粉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自评的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] 康桥数据，"理采存管用"五阶段数据治理方法论，康桥数据中台产品页（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] 康桥数据官网，数据中台产品与服务 — government.html
数据集成不需要半夜爬起来改脚本。康桥数据中台将多源异构数据归集标准化为可视化操作——拖拽组件或向导式勾选，三步完成配置，此后每天自动运行。从手工脚本到自动化集成的转变，不是工具的升级，而是把数据工程师的时间从维护脚本中释放出来，去做更有价值的事情。
引言 今年的AI领域，堪称“神仙打架”。两周前，Google突然发布Gemini3，其基准测试成绩断档领先，迅速引爆科技圈，公司股价也应声大涨。 此前Gemini系列—直低调，风头被ChatGPT和Claude占据；而Gemini3的横空出世，让业界重新审视这位AI“老大哥”——无论是Vibe Coding的准确度与审美，还是Nano Banana Pro的精度，都展现出“六边形战士”般的全面能力。 AI浪潮已不可避免地席卷数据行业。最近几周，我们收到不少客户咨询，希望搭建“ AI 数据中台” ，并构建多个 AI 用数场景。然而深入沟通后我们发现，很多企业的基础数据状况并不乐观：信息化系统零散、缺乏统—数据底座……在这样的基础上推进AI，注定困难重重。 类似情况在行业中十分普遍。不少企业过去几年投入大量预算做AI POC（概念验证），却始终难以规模化落地。问题往往不在模型本身，而在于数据治理的根基尚未夯实。无论是AI应用、智能分析，还是行业模型微调，都离不开工业级、可复用、可信赖的数据底座——而这，正是数据治理工作的核心目标。 本文将从数据广度、数据质量、业务理解三个维度，阐述为什么“要做AI，先做数据治理”。 一、如果跳过数据治理，AI的致命缺陷 1.1 数据孤岛 AI=数据+算法+算力， AI应用必须先获取数据才能做场景化处理。真正有价值的AI，需要全方位的数据，而非零散的“单—视角 ”。 大多数企业的信息化建设是离散进行的。客户数据存储在CRM系统中，用户行为数据散落在各类日志中，财务数据则位于ERP系统内。这些数据天然形成隔离，导致唯—标识难以建立，模型无法准确关联用户在跨业务场景中的行为轨迹。 AI模型只能基于单—系统的碎片化数据进行训练，无法关联用户的跨业务行为。 这就是缺少数据治理工作支撑的典型问题：数据广度和深度不足，AI无法形成对业务的全面认知。而系统化的数据治理，正是通过“数据归集+统—建模”，为AI提供全景数据支撑： 数据归集：通过数据集成平台实现跨源数据的汇聚。 数仓规划：基于数仓规划和主题域设计，构建宽而全的数据。 康桥数据中台提供多源异构数据集成、实时与批量同步、低代码可视化配置、多协议转换、高可靠容错及信创适配能力，全面支撑高效、安全、灵活的数据集成需求，打通数据孤岛。 1.2 垃圾进、垃圾出 “垃圾进、垃圾出”由来已久，在AI时代被进—步放大，输入数据的质量，直接决定模型输出的价值。劣质数据喂给再先进的大模型，也只能产出—本正经的“高科技垃圾”。 有些企业认为： “不做数据治理，用开源ETL工具把数据抽出来不就行了？ ” 这是—个典型误区： 数据归集 ≠ 数据治理 。 某零售企业曾试图跳过数据治理，用AI助手统计销售额。由于底层数据中存在大量未剔除的测试订单，且金额单位（元/万元）混乱不统— ，AI输出了严重虚高的业绩，误导了管理层决策。 真正的数据治理除了实现数据汇聚，更关键的是构建全链路的数据治理体系，从源头保障数据质量，为AI项目规避“垃圾进、垃圾出” 的风险。 数据治理：数据标准管理、质量校验、数据血缘。 资产沉淀：指标中心、标签中心、清洗/加工流程标准化。 康桥数据中台-数据治理模块，基于智能化数据探查与大数据旁路监测技术，提供可视化规则配置、自动化质量评测（支持百亿级数据5分钟内完成千万级评测）、问题闭环管理及多维度精细化质量报告，构建不侵入原系统的统—、高效、智能的数据质量管理体系，从源头减少 “垃圾数据”的产生。 1.3 AI不懂业务 无论是中台、 BI还是AI，技术的终极目标都是服务业务。脱离业务理解的AI，即便技术指标再优秀，也难以创造实际价值。数据治理的关键作用之—，就是完成企业业务知识的数字化沉淀，为AI提供“业务认知”基础。 当业务人员用自然语言向AI提问时，使用的是业务术语；而AI底层运行依赖的是技术语言。 例如，电商运营人员问 AI ：“神仙水上周的销量是多少？ ” “神仙水”是消费者端的俗称，实际产品名是“SK-II 护肤精华露”。 如果数据中台未建立业务术语与产品之间的映射关系，AI 在底层就找不到“神仙水”这—字段，自然无法返回准确销量。 有效的数据治理不仅是提供一个技术平台，更是助力企业沉淀业务知识，构建“业务语义层”的管理工程： 业务驱动建模：模型结构与业务流程对齐。 指标/标签体系沉淀：让模型直接使用业务语义。 数据 + 业务知识的双重监督：减少“黑盒错误”。 康桥数据中台-AI用数智能体，通过汇聚多源异构数据并进行清洗、转换与集成，确保数据准确—致；同时依托元数据增强技术构建企业级知识图谱，实现数据语义标注与业务含义补全，让系统更懂业务、更准查询，为智能分析与决策提供高质量、可理解的数据基础。 二、总结 梳理下来，我们可以清晰地看到： AI与数据治理并非“替代关系”，而是 “协同共生”的关系。 AI=数据+算法+算力，数据提供 AI 学习的基础信息；算法决定加工数据的步骤，以及以产生智能的决策；算力支撑算法高效地处理海量数据。 跳过数据治理做AI的代价是惨痛的，短期看似乎节省了数据治理的成本，但长期看，每个AI项目都将陷入重复的数据清洗泥潭，架构越来越乱，维护成本呈指数级上升，最终沦为烂尾工程。 本文仅基于当前小编的行业实践和观察整理，期盼与大家一起深入探讨。康桥数据长期专注于数据管理能力的输出，我们正在将多年实战经验整理成书，新书内容即将在各大平台分享，希望能更好地助力大家的数据治理工作。
引言 在本系列前面的文章中，我们分别介绍了《什么是数据中台》和《为什么数据治理是持续性的？》 也为大家介绍了康桥数据“理采存管用”的数据治理方法论。 不少读者反馈，对“数据仓库”这个词还不太清楚：它和数据中台到底是什么关系？数据中台既然覆盖“理采存管用”，那数据仓库又在其中扮演什么角色？ 在深入探讨“理”（梳理）和“采”（采集）之前，我们可以先把“存”（存储）这个环节讨论一下。 数据中台和数据仓库的区别与联系 数据仓库为什么需要分层 业界常用的分层思路有哪些 康桥数据在实战中总结的分层模型是怎样的 一、数据中台 vs 数据仓库 数据中台：是一个承载“理采存管用”全流程的“工具与管理平台” ，核心是让数据能力可复用、可服务化。 数据仓库：是中台体系中负责 “存”的 “数据地基”。 它们的关系是： 数据经过中台的治理（理）和采集（采）后，存入数据仓库；再通过中台的调度和管理（管），最终以服务形式（用）支撑业务应用。 通俗来讲，数据中台操作数据，负责把数据治好。数据仓库存储数据，负责把数据存好。 二、数据仓库为什么一定要分层？ 数据仓库的命名源于“仓库”的概念，其设计核心在于解决数据管理中的混乱与低效问题。若将原始数据、加工数据及应用数据混杂存储于单一存储层，将导致数据定位困难、管理复杂、查询性能低下。数据仓库分层设计正是为应对这一挑战，通过结构化组织实现数据的高效治理与利用，数据仓库有以下优点： 结构清晰：像“俄罗斯套娃”一样，采用分层架构（如ODS、DWD、DWS、ADS），每层职责单一，将复杂数据流程简化为可管理的模块化处理，复杂问题简单化。 数据复用：沉淀公共指标和宽表，避免“重复造轮子”，极大提升下游开发效率。 任务解耦：复杂任务拆成多个步骤，便于运维和重跑，一层失败不影响全局。 查询加速：空间换时间，通过预处理和汇总，让上层应用（AI用数、BI、大屏）查询更快。 水平扩展：多数数仓基于分布式架构支持弹性扩容，无缝适配数据量增长场景，确保系统在高负载下保持高性能与高可用性。 三、业界主流的分层思路 3.1 经典两大流派 Inmon（自顶向下）： 主张先建企业级数据仓库（EDW），再建数据集市。 Kimball（自底向上） 主张先围绕业务过程建数据集市，再通过一致性维度整合成企业视图。 Inmon（自顶向下）就像先建一个巨型中央仓库，把所有货物标准化后，再分发给各部门小店； 而Kimball（自底向上）则像先为各部门开专业零售店，但使用统一的商品编码和会员体系，让这些店能轻松连锁成一个大超市。 前者强调整合与统一，后者追求速度与实用。现代数据平台通常结合两者思想。 3.2 当前共识：五层模型 融合了经典思想，互联网和大厂普遍采用五层结构： ODS（贴源层） 贴源层顾名思义是从源头粘贴数据，同城使用数据集成工具（ETL），将源头业务系统数据进行归集，保持数据的原貌，不做任何修改，隔离源头业务系统，不影响原系统的运行。 DWD（明细层） 当原始业务数据进入ODS层时，会对数据进行标准、治理的检查，将问题数据进行清洗、转换、去重、标准化等动作，实现数据的自优化。 DWS（服务层） DWS服务层，更多地贴近业务场景，在DWD明细层的基础上进行汇总加工和聚合计算，例如将事实表中的聚合度量值和维度表中的数据进行汇总聚合，借助DIM公共维度层的不同维度，计算分析出多维度的业务信息。 ADS（应用层） ADS层为数据产品、报表和分析服务提供可直接使用的数据，支撑业务决策的数据应用和报表分析。 DIM（维度层） DIM贯穿于ODS、DWD、DWS、ADS，确保各层数据计算中维度的一致性和准确性。提供通用的维度属性，常见的维度包括，时间维度：年、季度、月、日、时等；空间维度：物理位置、网络地址等。 五层结构相互独立又协同工作，形成高效的数据处理与分析体系，支持智能化的业务应用。 数据流向：ODS → DWD → DWS → ADS DIM 贯穿所有层次，确保维度一致性 这种架构兼顾高内聚、低耦合的数据仓库建设思路，但对团队建模能力要求较高，不少中小企业在落地时感到吃力。 四、康桥数据的实战分层模型 如果说 3.2 的五层模型是学院派，康桥数据的数仓分层就是实战派。康桥数据中台目前支持多种常见数仓，也对信创数据库（如达梦、人大金仓）做了良好适配。无论底层选Doris、StarRocks还是PostgreSQL，都将分层思想内嵌到平台中，提出一套更实战、易用、低门槛的分层模型： SRC（来源层） → ODS（贴源层） → DW（治理层） → ADS（应用层） → DS（共享层） 4.1 设计思路：让数据好管好用 1. 可行性与易用性 架构不是为了“炫技”，而是为了更快更好地实施和使用。考虑到数据工作未来会引入更多业务人员，以及“中国式速度”的要求，我们的模型必须“开箱即懂”。 2. 强化“理采”与“用”的映射： 将「SRC-来源层」纳入： 明确映射“理采存管用”中的“理”和“采”的起点，方便从源头理解数据。 将「DS-共享层」纳入： 明确映射“用”的出口，让数据提供者和消费者清晰知道“数据成品”在哪。 3. 降低“存”与“管”的门槛： 弱化DW细化分层： 将业界DWD（明细）和DWS（汇总）合并简化为「DW-治理层」。 解耦DIM维度层： 将「DIM-维度」的管理从数仓ETL中剥离，交由康桥中台的“数据标准、数据清洗”模块进行维护。 让实施人员无需精通复杂的Kimball建模，大幅降低数据工作的门槛。 4. 确保规范（前提）： 简化不等于随意。没有规范的敏捷是“灾难”。康桥模型通过中台工具将规范（如标准、质量等）“嵌入”到数据的归集、清洗、共享流程中，确保“简化”后的数据质量。 4.2 康桥五层模型详解 第 0 层：SRC（来源层） 逻辑层，不存实际数据。作用是梳理数据资产，比如“CRM系统-客户表”，这是数据治理的起点。 第 1 层：ODS（贴源层） 物理层，把源系统数据原样同步过来，只做轻微格式处理，不做业务加工。作用是可回溯、解耦业务库压力。 第 2 层：DW（治理层） 核心层，融合了明细和汇总功能。在这里执行数据清洗、标准化、关联和轻度汇总，产出可信、可复用的数据。 第 3 层：ADS（应用层） 面向具体业务场景做深度加工，比如大屏数据、报表数据、算法样本等。DW 层保持稳定，ADS 层灵活响应需求。 第 4 层：DS（共享层） 逻辑层，将 ADS 的数据包装成 API 或数据目录，供业务系统或人员直接调用。使用者无需关心数据存在哪里。 五、康桥数据的实战分层模型 数据中台是平台，数据仓库是地基。分层是为了让数据更清晰、可复用、易治理。 业界有 Inmon、Kimball 等经典思路，也有通用的五层模型，但对实施能力要求高。康桥数据在此基础上，提出更注重实战的五层模型（SRC/ODS/DW/ADS/DS），通过中台工具降低建模门槛，能更快落地“存好、管好、用好”数据的目标。 本文基于小编当前实践经验整理，数据仓库领域发展迅速，数据湖等新概念也不断涌现，但分层管理的核心思路始终未变。康桥数据长期专注于数据管理能力的输出，目前我们正在将多年实战经验整理成书，未来也会在书中更系统地介绍数据仓库相关内容，希望能更好地助力大家的数据治理工作。
在之前的文章中，我们探讨了什么是数据中台。数据中台本质上是实现数据“汇聚整合”与“服务化输出”的核心载体。
数据标准的宗旨在于为业务、技术及管理提供全方位的服务与支持。数据标准构成了实现数据驱动管理和数据驱动创新的坚实基础，数据治理必须要过数据标准管理这一关！ 一、三个方面认识数据标准 1.业务方面 数据标准是解决数据不一致、不完整、不准确等问题的关键基础。各业务部门对数据形成统一的认知和理解，消除数据的“二义性”，从而提升业务的规范性，降低因数据不一致而产生的沟通成本，进而提高业务处理效率。 2.技术方面 统一标准化的数据及其结构是信息共享的基石。标准的数据模型和标准数据元为新建系统提供有力支撑，显著提升应用系统开发及信息系统集成的实施效率。此外，数据标准为数据质量规则的建立和稽核提供了重要依据，是数据质量管理不可或缺的输入。 3.管理方面 通过对业务术语、主数据、参考数据及指标数据等定义统一的标准，为精准数据分析奠定坚实基础。统一的数据标准使业务人员能够轻松获取数据，从而为数据分析和数据挖掘创造可能。 二、数据标准的四项内容 一套完善的数据标准体系是数据管理和应用的基础，有助于实现数据底层的互联互通，提升数据的可用性，消除数据业务中的歧义。数据标准通常涵盖四个方面的内容： 1.数据模型标准 数据模型标准对每个数据元素的业务描述、数据结构、业务规则、质量规则、管理规则及采集规则进行详尽的定义，以确保数据具备可理解性、可访问性、可获取性和可用性。数据模型不仅体现了对业务的理解和定义，还能有效构建组织内部及组织间的沟通桥梁。此外，数据模型有助于识别缺失和冗余数据，并在ETL过程中精准记录数据映射。 在设计数据模型标准时，需重点考虑以下方面： 首先，是否符合设计规范，如遵循统一命名规则、确保元数据与数据的一致性； 其次，实体和属性的含义是否定义清晰且准确； 第三，术语和标准是否与实际情况相符，包括数据名称、属性和规则等； 最后，是否便于查阅，布局是否合理。 2.基础数据标准 基础数据构成系统的数据字典。在系统初始化阶段即已嵌入系统数据库，扮演着结构性和功能性支撑的角色。基础数据标准通常涉及国际标准、国家标准及行业标准。在定义数据实体或元素时，可引用相关标准，并依据组织部门实际需求持续补充完善、更新优化和积累，从而更有效地支撑业务应用开发、信息系统集成及企业数据管理。 基础数据标准包含业务、技术和管理三大属性： 业务属性:描述基础数据业务信息，供业务人员理解，包括标准主题、分类、编码、中英文名称、业务定义、规则、引用标准、来源及依据等； 技术属性:描述技术信息，支持系统实现，涉及数据类型、格式、长度、编码规则、取值范围等； 管理属性:描述管理信息，便于数据管理操作，涵盖定义者、管理者、使用者，以及版本、应用领域、使用系统等。 3.主数据与参考数据标准 主数据是用于描述核心业务实体的数据，如教师、学生、财务、教学、资产等。它具有高业务价值，能在学校内跨业务部门重复使用的“核心数据”。 参考数据则是用于将其他数据进行分类或目录整编的数据，规定了数据属性的域值范围。主数据标准包括主数据分类、主数据编码和主数据模型。主数据分类依据主数据的属性或特征，按照一定原则和方法进行区分和归类，建立相应的分类体系和排列顺序。主数据编码是为事物或概念（编码对象）赋予具有规律性、易于计算机和人识别处理的符号，形成代码元素集合。 4.指标数据标准 学校各业务域和部门设有业务指标，部分指标名称相同但业务含义不同，部分指标名称差异大却指向同一内容。若不进行指标数据标准化处理，同一指标在不同系统统计结果可能不同且难辨准确结果，构建或变更分析主题时需重新定义指标，耗费大。此外，当前大数据分析倡导业务人员自助分析，若无指标数据标准，业务人员难从不同系统获取所需数据，自助式分析难以实现，数据分析报告沦为空谈！ 指标数据标准是基于实体数据，通过增加统计维度、计算方式、分析规则等信息加工而成的数据。它对业务指标所涉及的指标项进行统一定义和管理。指标数据标准与基础数据标准相似，同样涵盖业务属性、技术属性和管理属性三部分： 业务属性:包括编码、中英文名称、主题、分类、类型、业务定义、业务规则、数据来源、取数规则、统计维度、计算公式、显示精度及相关基础数据标准等。 技术属性:涵盖来源系统、使用系统、数据源表、数据类型、度量单位、取值范围、生成频度、计算周期、取数精度等。 管理属性:涉及归口管理部门、业务和技术负责人、权限范围等。指标数据标准化适用于业务数据描述、管理、分析和可视化，促进业务部门间、业务与技术间形成共识。 三、推进数据标准的六个阶段 数据标准管理从需求发起到落地执行，通常需经过标准梳理、标准编制、标准审查、标准发布和标准贯彻及管理办法的发布六个阶段。 1.数据标准梳理 根据行业标杆经验和本校实际确定实施范围，制定数据标准优先级和难易度。梳理和定义数据标准步骤如下： 首先，依业务划分业务域，识别关键业务活动并梳理定义，处理活动输入输出的业务单据和用户视图，梳理其数据对象； 其次，分析数据对象，明确所含数据项，提炼业务域的数据指标和数据项，定义数据元标准，详尽描述业务逻辑； 第三，梳理抽象数据实体和指标的关联关系，定义数据间关系，明确数据对象的数据关系； 第四，经上述梳理分析定义，确定企业数据标准管理主体范围，基于系统逻辑归纳抽象，形成数据标准模型，此过程可能涉及数据对象的合并或拆分。 2.数据标准编制 数据标准编制是依业务需求和数据管控要求，对数据对象及其数据项明确定义的过程，涵盖数据项名称、编码、类型、长度等方面。编制可参考国际、国家或行业标准，也可依本校业务需求制定校级标准。数据标准制定分三步实施： 标准制定推进会：召集相关干系人开会推进数据标准制定，讨论标准定义，标识记录数据对象、业务术语和关键指标，得出精确定义以达成共识。该方法有助于识别对象、定义标准、提升效率，解决含义不清和歧义问题。 标准差异专项分析：先查询数据标准是否已有定义，若有则结合需求确定附加信息或修改定义，形成完整可接受的元数据定义和规范。若存在多对象标准，分析是否一致，接受、修改或创建定义以达成共识，删除多余定义。 标准影响风险评估：数据标准管理易出现新旧系统、部门和业务冲突，处理不当会致标准化失败。落地时要做好影响评估和干系人沟通，通过业务影响分析识别对业务的影响范围、程度、价值及风险，确定业务人员可接受范围和程度，为后续沟通做准备。 3.数据标准审查 审查数据标准初稿，评估其是否符合应用、管理需求及数据战略要求，直至满足发布条件。数据标准审查从需求符合性、实用性等方面综合判断是否契合需求与管理现状。 数据标准征集意见：拟定初稿广泛征集意见，降低不可用或难落地风险，包括初步培训和宣贯。征求意见设期限（依业务范围定），规定时间无意见则默认接受。 数据标准专家评审：标准制定和执行依赖专家团队，成员需深入了解业务领域，提供权威定义建议、解决歧义。执行中协调解决部门争议，完善标准体系。 4.数据标准发布 数据标准意见征集工作完成后，经过严格审查，正式发布数据标准。数据标准一旦发布，各部门及各业务系统必须严格遵循执行。对于遗留系统的存量数据，存在一定风险，应进行全面的影响评估，以妥善应对潜在问题。 5.数据标准贯彻 数据标准的贯彻是将已发布的数据标准应用于信息系统建设和改造，消除数据不一致性。将数据标准与业务系统映射，明确标准与现状关联，识别受影响应用。对于新建系统，直接采用已定义的数据标准；旧系统则建立数据映射关系、进行转换，逐步落地标准。同时，要加强对业务人员的数据标准培训和宣贯。宣贯方法有： - 文件传阅：以正式文件发布数据标准供各部门传阅，作为数据维护参考。 - 集中培训：制定培训计划，落实场地等开展宣贯培训，学员反馈心得，老师总结经验。 - 专题培训：针对不同业务领域开展专题培训，通过上机实操强化效果，推动标准落地。 6.数据标准管理办法 数据治理应结合实际情况，制定科学的数据标准管理办法。该办法旨在提供规范性的指导和约束，保障前期数据标准的顺利落地与有效执行。 一份完整的数据标准管理办法通常涵盖但不限于以下内容：数据标准的目的、适用范围及具体细则，数据标准的管理组织架构、管理流程、执行要求、考核机制以及附则等。 四、数据标准的四个常见误区 数据标准管理核心目标是确保信息系统建设和集成遵循标准，保障数据标准完整适用并有效执行。贯彻数据标准要在业务部门和信息系统逐步推行，争取管理层与系统开发部门支持配合。 1.业务驱动，不可一意孤行：数据标准源于业务、归于业务，本质是管理问题，应从业务层面解决。建立数据标准是为促进系统数据互通和业务部门共识，制定时要逐个业务域梳理，靠业务人员努力，技术工具用于固化执行。 2.循序渐进，不可急于求成：从价值链和业务流程角度分段实施数据管理标准，结合业务需求、系统改造和新系统建设契机，选合适落地范围和层次，优先解决紧迫问题，明确业务部门数据职责，确保数据与业务流程匹配。 3.动态管理，不可一劳永逸：数据标准管理要保持定义、设计和使用一致，但标准并非固定不变。新业务需增标准，无价值标准要废弃，数据变化时标准要与时俱进、有前瞻性，建立更新体系和治理平台，有序管理版本。 4.应用为王，不可断章取义：数据标准化是信息化建设基石，工作要着眼信息系统规划、应用方向和需求，做到标准统一。高质量标准化为后续分析建模奠基。建设标准要服务业务、提升效率，结合IT 系统现状，以应用为目标，以国标、行标为基础，减少对现有系统影响，确保标准实用有效，回归业务应用。 五、小结 数据治理的成功很大程度上取决于数据标准的合理性和统一实施程度。数据标准体系构建的过程是信息化部门推进技术与管理深度融合的过程，不仅考验信息化部门的专业化水平，更考验工作人员沟通协调能力。 来源（公众号）：数智转型洞察
