张总的会议室里，这是第三次讨论数据中台建设方案了，依旧没有结论。
"我的建议很明确，"技术负责人老李敲了敲桌子，"先把平台搭起来，数据能接的先接进来。老板要看的是成果，咱们治理做了大半年还拿不出东西，怎么交代？"
数据治理经理小王立刻摇头："不行。标准没定、质量规则没建，数据接进来就是一团乱。上次我和你说过，物料编码到现在还没统一，接进来的数据口径都对不上，后面全是返工。"
"那你说怎么办？治理治理，治了半年还在写标准文档，老板不会等我们的。"
会议室陷入沉默。张总知道两边的担心都有道理，但他需要一个能落地的时间表和路线图。
这不是一个团队的问题。几乎每一个正在筹备数据中台的企业，都在这道"先有鸡还是先有蛋"的选择题前犹豫过。
一、为什么这是个真问题
平台派的逻辑是一条直线：快速出平台 → 数据接入 → 跑通几个报表 → 让领导和业务看到价值 → 拿到更多预算后再补治理。他们的焦虑很真实——数据中台投入不小，如果前几个月什么都没"亮相"，项目可能直接被砍。
治理派的逻辑也是一个闭环：先定标准 → 清理数据 → 建质量规则 → 梳理元数据和资产目录 → 再上平台承载。他们见过太多"平台建好了但数据不可信"的失败案例，知道一旦跳过治理这一步，后续的成本是指数级的。
两派的对错都不能简单判定——他们只是看到了同一枚硬币的不同面。真正的问题是：有没有一条路，既能避免"先建后治"的返工，又能避免"只治不建"的尴尬？
先看看两边各自踩过的坑。
二、平台先行派：数据接进来了，但没人敢用
"先建平台再补治理"最大的诱惑是快。但快完之后的问题，往往比想象中大得多。
华东某大型化工企业（企业名称已脱敏，下同）的教训很有代表性。他们的中台项目启动后，团队决定先跑通数据集成——把 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/
