张总的会议室里，这是第三次讨论数据中台建设方案了，依旧没有结论。 "我的建议很明确，"技术负责人老李敲了敲桌子，"先把平台搭起来，数据能接的先接进来。老板要看的是成果，咱们治理做了大半年还拿不出东西，怎么交代？" 数据治理经理小王立刻摇头："不行。标准没定、质量规则没建，数据接进来就是一团乱。上次我和你说过，物料编码到现在还没统一，接进来的数据口径都对不上，后面全是返工。" "那你说怎么办？治理治理，治了半年还在写标准文档，老板不会等我们的。" 会议室陷入沉默。张总知道两边的担心都有道理，但他需要一个能落地的时间表和路线图。 这不是一个团队的问题。几乎每一个正在筹备数据中台的企业，都在这道"先有鸡还是先有蛋"的选择题前犹豫过。 一、为什么这是个真问题 表面上是"顺序之争"，底层是两种完全不同的建设逻辑。 平台派的逻辑是一条直线：快速出平台 → 数据接入 → 跑通几个报表 → 让领导和业务看到价值 → 拿到更多预算后再补治理。他们的焦虑很真实——数据中台投入不小，如果前几个月什么都没"亮相"，项目可能直接被砍。 治理派的逻辑也是一个闭环：先定标准 → 清理数据 → 建质量规则 → 梳理元数据和资产目录 → 再上平台承载。他们见过太多"平台建好了但数据不可信"的失败案例，知道一旦跳过治理这一步，后续的成本是指数级的。 两派的对错都不能简单判定——他们只是看到了同一枚硬币的不同面。真正的问题是：有没有一条路，既能避免"先建后治"的返工，又能避免"只治不建"的尴尬？ 先看看两边各自踩过的坑。 二、平台先行派：数据接进来了，但没人敢用 "先建平台再补治理"最大的诱惑是快。但快完之后的问题，往往比想象中大得多。 华东某大型化工企业（企业名称已脱敏，下同）的教训很有代表性。他们的中台项目启动后，团队决定先跑通数据集成——把 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/
某制造企业投入数百万建设数据中台。ERP、MES、CRM全接进来了，数仓建了，BI也跑起来了。半年后项目复盘，业务部门的使用数据让所有人沉默了——日均活跃用户不到5个。 调查发现不是技术问题。业务人员说得很直接："同一个客户在三个报表里三个名字，我信哪个？"数据质量问题没有人在入职时就被告知要负责，编码标准没有人在项目启动时参与制定。项目验收了，问题留下了。最终业务部门回归Excel——至少自己填的数自己信。 很多中台项目的失败不是发生在建设阶段，而是发生在上线之后——没有治理的数据平台，和没建之前唯一的区别是：以前数据散在各系统里，现在散在一个更大的系统里。 为什么很多中台项目都卡在这五个地方 复盘下来，大多数项目出问题不是因为技术架构不行，而是五件事没做透。这五件事恰好对应DAMA-DMBOK知识体系（共11个知识领域，详见DAMA International《DAMA-DMBOK 2.0》）中数据中台建设最易出现短板的五个领域： 关键环节 对应DAMA领域 没做透的表现 数据模型没人维护 数据架构 模型在PPT里，实际跑的还是老结构 编码规则没人统一 主数据管理 同一物料三个系统三种叫法 数据问题没人跟进 数据质量 规则配了几十条，告警没人处理 数据资产没人编目 元数据管理 业务想查数，得在群里@IT"帮我找一下" 系统接口没人对口径 数据集成 这边传过去了，那边说格式不对 DAMA把这五个领域系统化为知识框架，不是让你背下来去考试，是让你在项目启动前就知道——这些坑你不填，后面一定踩。 理采存管用 × DAMA：知识框架如何工程化 很多企业理解DAMA时关注的是知识体系，理解数据中台时关注的是技术平台。但项目现场真正需要回答的是：数据应该怎么建设？治理应该如何落地？ 龙石数据在大量政企项目实践中发现，DAMA解决的是能力框架问题——告诉你"该管什么"；理采存管用解决的是工程路径问题——告诉你"怎么管"。两者是地图和施工图的关系。 理采存管用 对应DAMA领域 中台动作 理 数据战略→数据架构 摸家底、建体系、定蓝图 采 数据架构→数据集成 打通系统、汇聚数据 存 数据架构→数据标准 标准化模型、统一口径 管 数据治理/标准/质量/主数据 元数据+标准落标+质量监控 用 数据应用 资产目录、数据服务、分析报表 真正决定项目成败的往往不是技术选型，而是建设顺序。先治理体系后技术平台，先价值验证后规模推广，先解决业务问题再扩展技术能力——这套思路龙石总结为"理采存管用"建设路径。 四个领域的工程落地 数据架构：模型不在PPT里，要在系统里跑。 某211大学原来的数据模型只存在架构师的文档里，没有人按分层存数据。龙石团队把模型直接落地为ODS-DW-ADS分层架构——模型从设计文档变成运行实体。同步建设数据探查编目系统与数据超市，跨部门数据申请从"天/周级"变成"分钟级"在线自助获取，实现"一站式"数据服务。 主数据管理：同一个东西不能有三种名字。 江苏某建筑装饰集团200余家子公司，同一材料苏州叫"大理石A级"，南京叫"A类石材"。围绕物料、供应商、项目建立黄金记录后，跨公司对账从5天缩到1天，数据纠纷减少80%，项目平均工期缩短10%。客户反馈："以前经营分析会数据全靠各分公司人工报送，真假难辨且滞后严重。现在坐在总部就能看清全国上百个项目的实时成本与合规情况。" 数据质量：配了规则不等于解决了问题。 很多企业质量规则配了几十条，告警堆在那里没人处理。问题不在规则不够，在缺少"发现→定位→修复→验证"的闭环。上海某大型化工企业通过数据中台建设统一物料编码、打通OT与IT数据后，库存周转率提升28%，订单交付及时率提升至91%，报表出具周期提前4天。同步成立数据管理部，将数据治理纳入绩效考核体系，实现从"项目驱动"向"机制驱动"的转变。 元数据管理：别让IT变成人肉数据目录。 化工企业的生产主任从来不看中台——一堆技术表名根本不知道代表什么。龙石通过自动采集+血缘解析形成全企业数据地图后，业务人员在资产门户自己检索，IT团队的数据答疑工作量显著下降。 常见问题 Q：不学DAMA能建好中台吗？ 能建，但大概率漏掉关键能力域。DAMA是数据管理的"全景地图"，不看地图也能走，容易迷路。 Q：为什么懂DAMA的项目更容易成功？ DAMA本质上在回答三个问题：数据归谁负责、按照什么标准管理、出了问题上谁解决。很多中台项目失败不是缺技术，是缺这三个答案。技术平台解决流动问题，治理解决可信问题，两者结合数据才转化为业务价值。 Q：理采存管用和DAMA冲突吗？ 不冲突。DAMA是知识框架，理采存管用是工程路径。一个是地图，一个是施工图。 Q：DCMM和DAMA是什么关系？ DCMM（GB/T 36073-2018《数据管理能力成熟度评估模型》，2025版DCMM 2.0将于2026年7月施行）是中国在数据管理领域首个国家标准，划分八大能力域（数据战略/治理/架构/标准/质量/安全/应用/生存周期）和五级成熟度（初始→受管理→稳健→量化管理→优化级）；DAMA是国际数据管理协会发布的《DAMA-DMBOK数据管理知识体系指南》（最新为2.0修订版，共11个知识领域）。DCMM评估"你做到了什么程度"，DAMA回答"你应该做什么"。 企业建数据中台，真正需要回答的不是"用什么技术栈"，而是"数据管理能力建设到了什么程度"。DAMA-DMBOK给出了全景地图（11个知识领域），DCMM（GB/T 36073-2018）给出了评估标准（八大能力域、五级成熟度），龙石数据理采存管用给出了工程落地路径。地图决定方向，标准决定高度，路径决定结果。 参考资料： 1.DAMA International. DAMA-DMBOK: Data Management Body of Knowledge (2nd Edition, Revised). 11个知识领域涵盖数据治理、数据架构、数据建模与设计、数据存储与操作、数据安全、数据集成与互操作、文档与内容管理、参考数据与主数据、数据仓库与商务智能、元数据管理、数据质量。 2.GB/T 36073-2018《数据管理能力成熟度评估模型》（DCMM），我国首个数据管理领域国家标准，八大能力域、五级成熟度。DCMM 2.0（GB/T 36073-2025）将于2026年7月1日起施行，能力域扩展至九个。 3.案例数据来源：龙石数据官网案例库（longshidata.com/cases），含上海某大型化工企业、江苏某建筑装饰集团、江苏某211大学等真实项目数据。
中台不是数字化建设的终点。它是企业从有数据走向用数据的起点。
"中台项目投了 500 万，ROI 在哪？" 这是今年被问到最多的问题。Gartner 的数据更让人睡不着：超过 60% 的数据中台项目未能达到预期目标[1]。数据接进来了、大屏跑起来了、报表也出了。但老板问一句"值不值"，CDO 回答不上来。 不是项目没做，是做了没算账。投入产出比低，本质是四个核心痛点没解决。龙石数据在服务政企客户的过程中，反复验证了这四个痛点的杀伤力——以及解法。 痛点一：数据质量不敢用。 低质量数据每年给企业造成平均 1290 万美元的损失[2]。这不是技术问题，是财务问题。数据接进来了，但业务部门打开一看——手机号是空的、客户名三种写法、同一个指标三个口径。谁敢用？ 龙石在某化工企业的项目里，上线第一步就是建立质量监测机制。在集成环节配置完整性检查和准确性校验规则，数据入库时自动校验，不合规的打回源系统修正。项目上线后，核心数据的质量合规率从不到 60% 提升到 95% 以上。质量有保障了，业务部门才敢把数据用到经营分析里。 痛点二：业务部门不买账。 Gartner 预测，到 2027 年，80% 的数据治理项目将因缺乏业务驱动力而失败[3]。中台做了大半年，业务部门还是自己导出 Excel——不是平台不好用，是他们根本不知道平台能帮他们做什么。 龙石的做法不是在项目初期要求业务部门"配合治理",而是先帮他们解决一个具体的痛点。某建筑装饰集团的 CDO 在龙石建议下，成立数据治理委员会，由业务副总裁挂帅、IT 负责执行。先把采购、库存两个核心域的治理做透，业务部门第一周就看到了准确的数据报表。半年后平台使用率翻了三倍。 痛点三：建设周期太长不出成果。 动辄 12-18 个月的交付周期，半年不出成果老板就没了耐心。很多团队一上来就想覆盖所有系统，越做越大、越做越慢。艾瑞咨询的数据中台行业报告指出，"重投入、低成效"是行业核心困境[4]。 龙石的方法是"理采存管用"闭环推进——不串行等待，而是选一个核心业务域快速打透。理完资产就能看目录，采完数据就能出报表，管好质量就能建立信任。某 211 大学按这个节奏推进，教务和学生两个域 3 个月就看到效果——跨部门数据申请从"天/周级"缩短到"分钟级"。 痛点四：价值无法量化。 "提升了数据能力""支撑了数字化转型"——这些目标无法验证。没有一个业务数字是因为中台改善的，中台就永远是成本项。信通院的研究表明，数字化投入每提升 1%，成本费用利润率提高 6.71%[5]——但前提是"业务真正在用"。 龙石在项目中从第一天就建立价值锚点：不是汇报接了多少系统、建了多少模型，而是汇报"客户响应速度提升了多少""人工对账时间缩短了多久""库存周转加快了几天"。上海市某化工企业的预测性维护项目，把设备运行数据和工艺参数结合后，非计划停机减少了 37%——这个数字，老板听懂了。 四个痛点的根因是同一个：中台建成 ≠ 价值实现。 但为什么有些中台项目能做出 ROI，有些做不出来？差距不在产品功能上——数据集成、数据治理、数据质量这些模块，主流中台厂商基本都有。真正的差距在建设方法和运营思路上。 第一，理采存管用不是产品模块划分，是价值落地路径。 很多团队把中台建设理解成"先理完、再采完、再存完"的串行工程，等所有步骤走完才让业务部门用。但龙石在大量项目中验证的经验是：理采存管用应该是一个闭环——每个阶段都有业务产出。理完一个核心域，业务人员就能通过资产目录看到自己有什么数据；采完第一批高价值系统，就能出第一张业务报表；管好一个核心指标的质量，业务部门就开始建立信任。 企业不需要等项目全部结束才能看到成果。每完成一个阶段就产生一次业务价值——这是 ROI 提升的关键。 第二，中台项目的问题往往不是不会建设，而是不会运营。 很多中台上线之后就没有然后了——元数据没人维护了、质量标准没人更新了、业务部门的问题没人响应了。龙石的答案是能力转移：项目交付不是终点，而是客户自主运营的起点。 具体做法是三层培训和三步陪跑。理论培训帮团队建立 DCMM、DAMA 等标准的共同语言；实施培训让团队掌握项目推进和持续运营的方法；实战培训手把手带团队完成全流程实操。陪跑阶段从集中培训到样板工程建设再到远程技术支撑——不是替客户做治理，而是帮客户建立自己持续做治理的能力。项目结束后，客户团队能自主推进数据标准迭代、质量规则优化和资产目录更新。 第三，让业务部门主动用起来，比任何技术指标都重要。 龙石项目的价值衡量标准不是接了多少系统、建了多少模型，而是业务部门是否在主动使用数据、是否有业务指标因为中台而改善。数据质量合规率、业务自助申请率、核心指标修复周期——这些才是真正该看的数字。当客户能说出"这个数据帮我们减少了几天对账时间""那个指标帮我们提前发现了供应链风险"，ROI 就不再是 PPT 上的估算，而是每个季度都能回顾的真实成果。 常见问题 Q：中台 ROI 怎么算？ 不要追求精确的财务数字。先找一个业务域，看中台带来的改变能不能用业务指标描述——时间缩短了多少、成本降低了多少。有至少一个能说的数字，ROI 就有了起点。 Q：业务部门不配合怎么办？ 不要用治理规范去要求，用业务价值去吸引。帮他们解决一个具体痛点——数据找不到、报表太慢——他们自然就来了。 Q：怎么让老板看到价值？ 不要让老板看技术指标，让老板看业务数字。建立"中台价值看板"，每月呈现数据调用量、支撑业务场景数、每个场景的可量化收益。 参考来源 [1] Gartner, "Over 100 Data, Analytics and AI Predictions Through 2030," June 2024 [2] Gartner, "Data Quality: Why It Matters and How to Achieve It," 2020 [3] Gartner, "Gartner Data & Analytics Summit 2024 — Top D&A Predictions," 2024 [4] 艾瑞咨询，《2024年中国数据中台行业研究报告》，2024年7月 [5] 中国信息通信研究院，《中国数字经济发展研究报告（2025年）》，2026年3月
DCMM 2.0 即将实施的窗口期，每一个正在建设或已经建成数据中台的企业，都值得用 DCMM 的框架重新审视自己的建设思路——你建的到底是平台，还是能力？企业未来竞争的核心，不是拥有多少数据，而是能否把数据变成持续创造价值的资产。
失败的数据中台，真正的问题往往不在技术，而在于它们从来没有真正进入过业务流程。数据只有被使用，才能产生价值；价值被验证，才能形成投入；持续投入，才能形成能力。数据中台最终比拼的，不是谁接入的系统更多，而是谁更快把数据转化成业务成果。
数据要素市场化只是起点。谁能率先建立资源化→资产化→价值化的闭环，谁就更有机会把数据真正转化为生产力。数据中台不再只是技术平台——它是企业数据资产运营体系的核心基础设施。
