一份数据中台与数据治理服务方案，通常由四层内容组成：诊断与规划、标准与制度、平台与治理实施、运营与验收。对应到交付物，会同时出现报告、制度、平台配置、数据资产、数据服务和运营记录，平台只是其中一部分。判断方案是否完整，拿这四层去对照，比逐页数功能模块更有效。下面按服务内容、交付清单、验收与裁剪顺序拆开。
一、数据治理服务方案包括什么
四层之间是承接关系。诊断决定先做哪些场景，标准决定口径和责任，平台把标准固化成规则与流程，运营决定上线后能不能持续。项目可以从任何一层切入，但交付物要能接上下一层。只做咨询，路线图要能指导后续实施；只做平台，治理规则和运营交接不能缺。涉及平台分层与能力衔接时，可对照数据中台整体架构确认边界。
| 服务层次 | 要解决的问题 | 典型服务内容 | 主要交付物 |
|---|---|---|---|
| 诊断与规划 | 治什么、先治哪、值不值得治 | 业务与系统调研、数据资产盘点、成熟度诊断、场景筛选、实施路线图 | 现状评估报告、差距分析、数据蓝图、场景清单、实施路线图 |
| 标准与制度 | 口径怎么统一、责任怎么落 | 数据标准、指标口径、主数据、资产目录、管理制度、责任矩阵 | 数据标准、数据字典、指标目录、资产目录、管理制度、责任矩阵 |
| 平台与治理实施 | 标准怎么写进系统 | 数据集成、存储计算、开发调度、元数据与血缘、质量规则、安全权限、数据服务 | 平台环境、数据模型、作业与调度、元数据与血缘、质量规则库、权限矩阵、API 或数据集 |
| 运营与验收 | 上线后怎么持续运转 | 运营机制、SLA、质量巡检、培训、交接、验收 | 运营手册、SLA、培训材料、试运行报告、验收报告 |
图1：服务层次与交付物（示意）
服务范围可以组合为咨询、实施和运维，但三者的验收对象不同：咨询要能指导后续建设，实施要把标准与质量规则落入系统，运维要明确问题闭环与交接。采购时应将每类服务对应到具体交付物，最终以项目合同为准。
二、诊断与规划如何确定范围
1. 现状调研与成熟度诊断
调研至少覆盖业务、数据、系统三条线。业务侧看目标和痛点，数据侧看资产分布、质量、口径和数据量，系统侧看数据源、接口、权限和现有平台。诊断可以借用 DCMM 2.0 的能力域做检查表。DCMM 2.0 指 GB/T 36073-2025《数据管理能力成熟度评估模型》。
国家标准全文公开系统显示，GB/T 36073-2025 于 2026 年 7 月 1 日实施。制定检查表时，应以现行标准正文确认能力域、能力项和证据要求，再结合本期业务范围裁剪；不能直接沿用旧版清单。
交付物通常包括现状评估报告、差距分析、问题清单、成熟度评分和访谈记录。验收时看两点：问题是否有数据证据，结论是否能对应到具体场景和责任人。
2. 场景选择与实施路线图
把所有问题一次做完，项目很容易拖长。可以先以2～3个业务价值清楚、数据基础可用的场景为试点示例，写清基线指标、目标、数据来源、口径负责人和交付时间。路线图按阶段拆：诊断与蓝图、首批场景、推广与运营。每个阶段有里程碑和验收证据。
交付物包括数据蓝图、场景清单、实施路线图、投入与组织建议、业务案例。这一层容易被写成厚厚一本报告。判断它有没有用，看后续项目能不能直接拿它排期、定范围、算资源。
三、标准与制度服务包含什么
1. 数据标准与指标口径
数据标准覆盖数据元、数据字典、命名规则、编码规则、值域和格式。指标口径要写清业务定义、技术计算逻辑、时间口径、统计维度、过滤条件和负责人。指标目录里同一个指标只保留一处权威定义，变更要走版本和审批。
交付物包括数据标准、数据字典、指标目录、指标口径说明书、指标变更流程。验收时可按风险选取核心指标，例如先抽3～5个，沿业务定义追到源表、加工逻辑和报表或 API，确认同一业务含义、版本和统计条件下的结果一致。数据标准的具体编写方法，可参考数据标准怎么制定和执行？。
2. 主数据、资产目录与责任体系
主数据先做客户、供应商、物料、组织等关键实体，明确唯一源头、匹配规则、合并策略和变更审批。资产目录按业务域分层编目，写清资产名称、负责人、来源、更新频率、使用权限和消费方。
交付物包括主数据标准、数据资产目录、数据责任矩阵、管理制度和流程、考核办法。制度要能落到三件事：谁提变更、谁审批、谁维护。只写原则不写角色和时限，执行时容易停在纸面。
四、平台与治理实施包含什么
1. 数据集成与平台底座
平台底座通常包括数据接入、存储计算、开发调度、数据服务和统一门户。接入方式按数据源和时效选择批处理、变更数据捕获 CDC、API 或文件交换；模型按贴源、标准、主题、服务等分层组织；调度要能监控依赖、失败重试和告警。
交付物包括平台环境、集成方案、数据模型、抽取、转换、加载 ETL 或作业、调度配置、数据服务接口、部署与配置文档。企业已有数据平台时，这一层可以裁剪为集成、治理配置和服务发布，但要写清现有平台与新增部分的接口、权限和运维责任。
2. 元数据、血缘与数据质量
元数据管理要采集技术元数据、业务元数据和操作元数据，形成数据地图和字段级血缘。血缘的价值在于影响分析：上游表变更时，能定位到受影响的指标、报表和接口。
质量规则按完整性、准确性、一致性、及时性、唯一性、有效性设置，绑定到具体字段、表或指标。规则要能跑、能告警、能生成报告，还要有人处理。
交付物包括元数据清单、血缘图、质量规则库、质量监控配置、质量报告、问题整改台账。验收时不要只看规则数量。抽一条问题，走完发现、派单、修复、复核的闭环，才能判断质量机制是否在运行。平台建设失败时常见的治理、业务场景与运营问题，也适合在验收前逐项排查。治理体系如何搭建，可参考企业级数据治理体系怎么搭？。
3. 数据安全与权限
数据安全从分类分级开始。《中华人民共和国数据安全法》自 2021 年 9 月 1 日起施行。中国政府网公布的法律文本显示，第二十一条要求建立数据分类分级保护制度，按数据的重要程度和危害程度实施保护。落到项目里，要识别敏感数据，配置脱敏、加密、行列级权限、访问审批和审计留痕。
交付物包括数据分类分级清单、敏感数据清单、权限矩阵、脱敏规则、审计报告、安全管理制度。验收时看权限是否按角色配置、敏感数据是否可见可控、操作是否留痕、离职和外部合作场景是否有回收机制。
4. 数据服务与场景应用
治理后的数据要能被业务调用。常见形态包括指标、标签、API、数据集和数据产品。每个服务写清消费者、口径、刷新频率、服务等级约定 SLA、权限边界和版本。
交付物包括数据服务目录、API 文档、数据集说明、指标或标签清单、数据产品说明、场景验收报告。这一层决定治理成果能不能被看见。业务部门能自助取数、能把指标接进报表或运营动作，才算形成使用闭环。
五、服务交付清单如何验收
| 交付类别 | 典型交付物 | 验收时看什么 | 是否可裁剪 |
|---|---|---|---|
| 规划类 | 现状评估报告、成熟度诊断、数据蓝图、实施路线图、场景清单 | 问题是否有数据证据，场景是否有负责人和基线指标，路线图是否有里程碑 | 可按项目范围裁剪，现状与场景不能省 |
| 标准制度类 | 数据标准、数据字典、指标口径、主数据标准、资产目录、管理制度、责任矩阵 | 标准是否可执行，口径是否有唯一负责人，制度是否覆盖变更与考核 | 标准与责任不能省，制度形式可裁剪 |
| 平台与数据类 | 平台环境、数据模型、ETL 或作业、元数据、血缘、质量规则、权限配置 | 平台是否可用，模型是否覆盖场景，血缘是否可追，质量规则是否上线 | 已有平台时平台建设可裁剪，治理配置不能省 |
| 服务类 | 数据服务目录、API、数据集、指标或标签、数据产品说明 | 服务是否有明确消费者、SLA、权限边界和版本说明 | 可按场景裁剪，至少要有可被业务调用的服务 |
| 运营类 | 运营手册、SLA、巡检记录、培训材料、交接清单、验收报告 | 是否有人负责，是否有例会与巡检，是否能独立运维 | 不能省，至少要有交接和试运行 |
图2：交付物与验收证据（示意）
这张表可以直接拿去对照供应商方案。交付物数量不等于交付质量。一个项目可以把文档写得很厚，核心指标仍然对不上；也可以平台功能很多，没有人负责质量规则。验收要回到场景、责任和证据。
具体阈值，例如质量合格率、接口可用性、问题修复时长，应在合同和验收方案中约定。不同数据基础、不同场景的合理值不一样，把某个项目的指标直接套到另一个项目，容易产生争议。
六、服务范围如何裁剪
| 服务组合 | 适合谁 | 包含内容 | 交付重点 |
|---|---|---|---|
| 轻咨询 | 刚起步，先统一认知和方向 | 诊断、蓝图、标准框架、实施路线图 | 报告与路线图 |
| 治理加平台建设 | 有明确场景，需要落地 | 标准、平台、治理实施、数据服务 | 平台、规则、资产目录、服务 |
| 持续运营托管 | 已上线，缺运营人手 | 巡检、质量报告、需求响应、培训 | SLA、运营报告、问题闭环 |
可以裁剪的内容包括：已有平台时的平台建设、行业模板的本地化程度、培训形式和频次、报表数量。不能省的内容包括：业务场景和责任人、核心指标口径、元数据与血缘、质量规则与问题闭环、权限与审计、运营交接。缺了这些，平台上线后很难持续。
判断方案是否适合当前起点，可以检查三个问题：
- 现有平台能否复用： 哪些能力已经具备，哪些需要补齐？
- 业务场景是否明确： 是否有具体消费者、指标和验收任务？
- 上线后谁负责运营： 谁维护规则、处理问题和安排变更？
这些答案共同决定项目从哪一层开始。
七、Agent应用需要增加哪些交付物
AI 与 Agent 进入数据场景后，服务方案的交付清单会增加几类内容。理解这类应用的能力边界，可参阅《什么是企业级 AI Agent？》。
- 语义层与统一口径：Agent 需要结构化、可调用的知识。指标定义、业务术语、实体关系要有一处权威定义，否则同一个问题会得到不同答案。
- 知识库：把文档、报表、指标定义加工成可检索、可追溯、可版本化的知识。
- 数据产品与接口：Agent 通过 API 或数据集调用数据，权限、SLA、审计要写清。
- 高质量数据集与评测：训练和评测数据要有来源、标注规则、版本和适用范围。
- 权限与审计：Agent 能访问哪些数据、能执行哪些动作、调用是否留痕，要在方案里明确。
ThinkingAI 的企业级知识库可将指标定义、业务术语和规则文档编译为 Agent 可读取、检索与引用的知识，为分析提供业务上下文。统一口径仍需业务负责人审核并持续维护；具体权限、审批和版本管理能力，应按目标部署版本逐项确认。
Agentic Engine 支持私有化部署，可结合企业已有数据基础验证分析与运营场景。ThinkingAI 已服务全球超 1500 家企业，接入产品超 8000 款。
这里要区分三件事：行业通用能力、厂商已核实能力和项目确认能力。行业通用能力说明方向，厂商资料说明其公开能力，项目确认能力才决定你的场景能不能落地。
常见问题
1. 数据中台服务方案一定要包含平台建设吗？
不一定。已有数据平台，或者当前只需要顶层规划、标准体系和治理咨询时，可以把平台建设裁剪掉，保留诊断、标准、治理实施和运营。合同里要写清平台边界、现有系统的接口责任，以及治理规则由谁配置和维护。
2. 交付清单里的文档和数据资产，验收时看什么？
看三件事：文档与系统一致，数据与标准一致，责任与运营能接住。选 2～3 个核心场景做穿行测试，从源表追到指标，再追到报表或 API；同时检查资产目录、血缘和质量报告能不能对应到同一条链路。
3. 服务方案和单纯的数据治理方案有什么区别？
数据中台与数据治理服务方案通常同时包含平台建设、治理实施和数据服务输出；单纯的数据治理方案可以只做治理体系、标准和治理实施。两者的范围、交付物和验收对象不同，采购前要先定清楚是否需要平台和数据服务。
4. 项目一般做多久？
没有统一周期。场景数量、数据源复杂度、现有平台基础、客户配合程度都会影响进度。常见做法是分阶段推进：诊断与蓝图、首批场景、推广与运营。每个阶段设里程碑，避免把全部范围压在一次上线里。
5. 没有专职数据团队，能不能做？
可以启动，但需要业务负责人和数据 Owner 参与。服务商可以承担方法、工具和实施，业务口径、优先级和责任人仍要由企业确认。运营阶段至少要有人接住例会、需求和质量问题，否则上线后容易退化。
6. 怎么判断供应商的交付清单是否完整？
对照四层服务内容和五类交付物，要求供应商提供样例交付物、验收证据和交接方案。把上线后谁维护、出问题谁处理、SLA 怎么算写进合同。服务商怎么选，可参考8家值得考虑的数据分析实施服务商。
参考资料
- 国家标准全文公开系统：《GB/T 36073-2025 数据管理能力成熟度评估模型》，2025-12-31 发布，2026-07-01 实施。https://openstd.samr.gov.cn/bzgk/std/newGbInfo?hcno=22559F9C7BF9EAC6A3927223FE33CE20
- 腾讯云开发者社区：《腾讯云联合毕马威以“咨询+实施”模式夯实企业数据基座》，2026-04-13。https://cloud.tencent.cn/developer/article/2653596
- 中国政府网：《中华人民共和国数据安全法》，2021-06-10。https://www.cac.gov.cn/2021-06/11/c_1624994566919140.htm
