简介：这份PDF面向企业架构师、数据治理负责人与信息化项目管理者，系统梳理麦肯锡关于数据治理与数据架构总体设计的咨询方法论，帮助读者回答业务能力如何支撑IT要求、现状架构差距何在、目标架构如何演进等核心问题。内容围绕业务能力架构、IT架构现状诊断与目标设计、企业架构治理、数据治理方向性建议及ARIS模型说明展开，并给出数据督导、数据建模师/架构师、数据库管理员三类角色的职责划分与团队配置思路，强调以“所有者”制度实现业务与IT多层级数据负责制。资源包共1个PDF文件，约1.78MB，单文件即完整方案，便于通读与检索。已有172人学习，适合需要搭建数据治理体系、制定数据KPI与生命周期管理方法的团队参考借鉴。

1. 数据治理：为什么“买了最贵的数据库”依然治不好数据

很多团队在数据治理上翻过车：花大价钱上了数据中台、买了主数据管理工具，结果半年后业务部门还是拿着三份口径不同的报表开会。问题不在工具，而在于没人回答一个更底层的问题——这个数据对象到底归谁负责，从产生到消亡的每一步谁签字。这份企业架构咨询方案给出的反直觉结论是：数据治理的第一性原理不是技术平台，而是“所有制”。它把数据当成资产来确权，要求每个数据对象同时有业务侧和 IT 侧两组责任人，并且分企业级、能力板块级、系统模块级三层落实。搞懂这套“所有者 + 要素 + 流程”的三维结构，你才能明白为什么很多治理项目会烂尾，也才能看懂这份方案里那些角色表和 RACI 矩阵到底在解决什么。

2. 数据所有制：为什么“业务与 IT 配合”不能只停在口号

2.1 单一责任人为什么必然失效

绝大多数企业的数据治理起步动作是“指定一个数据管理员”。这个做法在方案里被明确否定，原因很实在：数据管理员如果是业务部门的人，他不懂系统里字段怎么落库、ETL 怎么跑；如果是 IT 部门的人，他又没有权力改业务口径、压业务部门整改数据质量。方案给出的解法是双责任人制——每个数据对象配一组业务责任人（定义口径、质量 KPI、SLA）和一组 IT 责任人（物理建模、性能容量、备份恢复）。这两组人不是上下级，而是同一数据对象在“概念层”和“物理层”的两个锚点。

常见的实现思路是把这种双责任落到 RACI 矩阵里。方案里那张职责分工表就是典型：数据定义这一行，企业数据管理委员会是 A（最终负责），能力板块数据督导是 R（执行），企业级数据建模师是 C（顾问），数据库管理员是 I（知会）。注意这里 A 和 R 是分开的——委员会拍板但不干活，督导干活但不独自背锅。这种拆分的好处是，当数据质量出问题时，追责路径是清晰的：口径错了找督导，落库错了找 DBA，而不是所有人一起说“这不是我负责的”。

2.2 三层所有制怎么落到组织上

方案把所有制分成三层，对应三种角色，这个分层逻辑值得细看：

这张表背后有个容易被忽略的设计动机：能力板块级督导的归属，取决于数据源和数据使用程度。方案里举的例子很具体——营销数据、客户数据归营销部督导；物资和供应商数据归物资部；财务数据归财务部。但对于跨多个能力板块共享的数据（比如设备台账既被运维用又被规划用），就要看数据源在哪个板块、哪个板块用得最重，由此决定督导来自哪个部门，或者由两个部门共同督导。这个规则的实质是把“谁产生、谁受益”作为确权依据，而不是按组织架构图硬切。

我一般会这么理解：这套三层结构解决的是“数据治理的颗粒度和组织层级不匹配”这个老问题。企业级管政策，板块级管定义，项目级管落地，每一层只做自己够得着的事，避免了“企业级督导去管某个字段的长度”这种越位，也避免了“项目组自己定企业数据口径”这种缺位。

2.3 数据督导助理：一个被低估的衔接角色

方案里有个细节很容易被跳过：信通中心设 3 名数据督导助理，每人负责承接 2-3 个业务部门数据督导的需求和日常协调。这个角色的存在，恰恰暴露了双责任人制最大的落地难点——业务督导和 IT 建模团队之间语言不通、节奏不同。业务督导说“客户数据要准”，IT 建模师问“准的定义是什么、阈值多少、什么时候校验”。助理就是那个把业务语言翻译成数据规格、再把 IT 约束反馈回业务的人。

从 FTE 配置看，这个角色投入是 100%，而业务督导只有 30%。这个比例说明方案作者很清楚：治理的瓶颈不在决策层，而在执行层的协调成本。很多企业治理失败，不是没人拍板，是拍完板之后没人跟到底。助理这个岗位就是“跟到底”的载体。

3. 数据治理要素：从定义到 KPI 的七段链条怎么咬合

3.1 七个要素不是并列的，是有依赖顺序的

方案把治理要素拆成七项：数据定义、概念建模、逻辑建模、物理建模、数据使用者建模、数据技术平台、数据生命周期、数据治理 KPI。表面看是八个并列项，实际上它们有严格的依赖链：

数据定义（对象+属性+负责部门） ↓ 概念建模（数据源+引用流向） ↓ 逻辑建模（实体+关系+主键） ↓ 物理建模（表空间+索引+存储） ↓ 使用者建模（CRUD 权限） ↓ 技术平台 + 生命周期 + KPI（贯穿支撑）

这个顺序不能乱。方案里明确写了：数据定义以业务对数据的需求为输入，由数据督导团队负责；概念建模由督导团队和建模团队一同完成；逻辑建模由项目团队建模人员负责。也就是说，定义权在业务侧，建模权在 IT 侧，但概念层是双方共同产物。这个分工的巧妙之处在于，概念模型是业务和 IT 唯一必须坐在一起画的图，画完之后业务管定义、IT 管实现，各走各的流程。

3.2 数据定义模板：一个物资主数据对象的解剖

方案给了一个物资主数据的定义模板，这个模板的结构值得逐字段拆解，因为它就是“数据所有制”的最小落地单元：

数据对象：物资主数据 相关能力板块：物资管理 主数据来源：ERP-MDM 业务负责部门：物资部 可能数据引用：ERP-MM、生产运维(PMS)、项目管理系统、ERP-FICO 关键属性（已有）：物料号、物料描述、物料类型、基本计量单位、物料组、采购类型、批次管理…… 关键属性（需要增加）：由业务部门提出

这里有几个设计取舍值得说。第一，主数据来源单独列一项，而不是混在“相关系统”里，因为主数据的核心特征就是“一处产生、多处引用”，来源系统必须唯一且明确。第二，关键属性分“已有”和“需要增加”两栏，这等于把“现状梳理”和“需求提出”拆开，避免业务部门在梳理阶段就把需求混进来导致范围失控。第三，属性列表里出现了 MRP 组、评估类、移动平均价这些 ERP 术语，说明这个模板不是通用模板，而是贴着具体系统（ERP-MDM）的字段结构设计的——治理模板必须和落地系统对齐，否则定义完了没法映射到物理表。

方案还给了属性表示方法的规范，比如物料号是 12 位数字编码、第一位代表物料类型，计量单位有 205 个。这种规范看起来琐碎，但它是数据质量 KPI 能算出来的前提——没有编码规则，你没法校验“物料号是否合法”；没有计量单位枚举，你没法发现“同一物料两个单位”的脏数据。

3.3 概念建模：企业信息模型是“唯一数据源”的载体

概念建模的目标，方案写得很直白：保证全企业内部操作系统或分析系统的共享数据的一致性。实现手段是建一张企业信息/数据模型，明确每个数据对象在哪个业务板块产生、被哪些板块引用。方案给了一张按能力板块展开的表，横向是板块（市场营销、计量装置管理、规划/资产管理、物资供应、人力资源、财务），纵向是主数据和事务型数据。

这张表的关键不在内容，而在它的用法：它是各信息化项目“唯一数据源”的指导。也就是说，任何新系统要建客户表，先查这张表——客户主数据产生于营销板块，你只能引用不能另建。这个规则听起来简单，但执行难点在于“引用流向”要画清楚。方案里专门用一页举例市场营销板块的数据引用流向，说明哪些数据被哪些板块共享。没有这张流向图，“唯一数据源”就是一句空话，因为没人知道该找谁要数据。

3.4 逻辑建模与物理建模：范式化和落库的分界线

逻辑建模的要点，方案强调了三件事：范式化的实体、完整的主键方案、多对多关系通过关联实体拆解。这三点是逻辑模型的“合格线”。物理建模则明确“与所实施的数据库管理产品系统紧密相关”，涉及索引构建、替代键、参考完整性模式、表空间。

这两层的分工，本质上是逻辑模型管“对不对”，物理模型管“快不快”。逻辑模型要求范式化，是为了消除冗余、保证一致性；物理模型允许反范式、加索引，是为了查询性能。方案用 ARIS 的 ER 图举例逻辑模型，用 Barker notation 举例物理模型，这个工具选择本身也说明问题：逻辑模型是给业务和架构师看的，物理模型是给 DBA 看的，两种 notation 服务两种读者。

3.5 使用者建模：CRUD 是权限治理的最小粒度

数据使用者建模这一节，方案给的定义很克制：按组织/部门内业务角色的活动模式和信息需求，制定数据用户的角色及操作权限，输出 CRUD 模型。C 是创建、R 是读取、U 是更新、D 是删除。

CRUD 看起来是最基础的权限模型，但方案把它放在治理要素里，用意在于：权限不是 IT 安全部门单方面配的，而是业务角色定义的。哪个岗位能创建客户、哪个岗位只能读、哪个岗位能删，这些是业务规则，不是技术配置。把 CRUD 建模归到数据治理要素，等于要求业务督导对自己板块的数据权限签字，而不是让 DBA 按“最小权限原则”拍脑袋配。

4. 治理流程与团队：九大核心流程和四层团队怎么对应

4.1 九大核心流程覆盖督导、建模、日常管理

方案提到数据治理的九大核心流程，分三类：数据督导（方向、政策、角色分配、争端解决）、数据建模（概念、逻辑、物理）、日常管理（质量监控、SLA、备份恢复）。这三类流程对应三个团队：数据督导团队、数据建模/架构团队、数据库管理团队。

这个“流程—团队”的对应关系，是治理能运转的关键。很多企业有流程没团队，或者有团队没流程，结果就是流程挂在墙上、团队各干各的。方案的做法是让每个流程都有明确的 RACI 归属，比如“数据服务水平制定”这一流程，企业数据管理委员会是 A、数据督导是 R、建模团队是 C、DBA 是 I。这样流程走不动的时候，你知道卡在哪个角色。

4.2 团队与现有架构管理团队的映射

方案专门用一页讲数据治理团队和企业架构（EAM）团队的对应关系，分了“原有角色、改进角色、新增角色”三类。这个分类很务实：不是所有治理角色都要新设，有些是现有角色加职责。

比如业务架构师，原有职责是业务架构设计，改进后要兼企业层面数据督导的职责；项目软件架构师，改进后要在项目层面设计数据逻辑架构；新增的是数据督导助理、企业级数据架构师、数据库管理团队。这种“能复用就复用、不能复用才新增”的思路，背后是对组织变革成本的考量——每新增一个编制都要走流程、要预算，能通过职责扩展解决的就不新设岗位。

4.3 FTE 测算：治理团队到底要多少人

方案给了一张 FTE 测算表，总计需要 17.4 FTE，其中现有 FTE 加上体改增加 FTE 补缺口。这个数字的构成值得看：企业级数据督导 0.5、八个能力板块督导各 0.3（合计 2.4）、信通中心督导助理 3、企业级数据架构师 1、系统/项目级建模师 2.5、数据库管理团队 7（备份、权限、管理、数仓、质量监控、IDP 各 1）、物理建模员 2。

注意数据库管理团队占了 7 个 FTE，是最大的一块。这说明方案作者认为治理的日常运维成本主要落在 DBA 侧，而不是建模侧。这个判断和很多企业的直觉相反——大家总觉得治理就是建模型，实际上模型建完之后的备份、权限、性能、质量监控才是持续消耗人力的地方。另一个细节是能力板块督导只给 30% 投入，意味着这是兼职角色，不设专职，这也符合“治理是业务附带职责而非独立职能”的定位。

5. 避坑：数据治理落地时最容易翻车的五个地方

现象一：概念模型画完了，项目组还是各建各的表。原因：概念模型没有和项目立项流程绑定，新项目启动时不强制查企业信息模型，建模团队也没有否决权。 解决：把“概念模型符合性检查”设为项目立项和设计评审的强制 gate，建模团队在评审中有 C（顾问）甚至 R（执行）角色，不符合唯一数据源原则的设计不予通过。

现象二：数据督导定了，但业务部门不认。原因：督导是 IT 部门指定的，没有走业务部门负责人的确认流程，导致督导在业务侧没有权威。 解决：能力板块督导的任命要由该板块业务负责人确认，并在部门职责文件里写明，同时把数据质量 KPI 纳入该部门考核，让督导有考核抓手。

现象三：主数据来源标了 ERP-MDM，但实际还有系统在自建客户表。原因：存量系统的数据没有做引用关系梳理，新系统又没被约束，导致“唯一数据源”只对新项目生效。 解决：先做一次全量数据源盘点，把每个数据对象的产生系统和引用系统列全，对违规自建的系统排迁移计划，迁移完成前在概念模型里标注“例外”并设截止日期。

现象四：CRUD 权限配了，但没人维护，半年后全乱了。原因：权限模型没有和岗位变动、系统变更联动，业务角色调整后 CRUD 没更新。 解决：把 CRUD 模型的维护挂到数据督导的日常职责里，和岗位说明书变更流程绑定，每次组织调整触发一次权限复核。

现象五：KPI 定了完整性、准确性、及时性，但算不出来。原因：KPI 定义时没有落到具体字段和校验规则，比如“准确性”没有说清是哪个字段对哪个源系统校验。 解决：每个 KPI 必须绑定到具体数据对象的具体属性、具体校验规则、具体责任团队，算不出来的 KPI 不上线。

6. 设计取舍：为什么这套方案选择“重组织、轻工具”

把整份方案读完，会发现一个明显的倾向：它在组织角色、RACI 矩阵、FTE 测算上花了大量篇幅，而在技术平台、工具选型上着墨很少，数据技术平台甚至只写了“已在 IT 架构设计章节中介绍”。这个取舍不是疏漏，而是有意的设计判断——数据治理的失败模式，绝大多数不是工具不行，而是责任不清。

这个判断可以从方案的要素排序看出来：数据定义排第一，技术平台排第六。如果作者认为工具是核心，排序会反过来。再看团队配置，数据库管理团队 7 个 FTE 里没有一个是“工具管理员”，全是备份、权限、质量监控这些职责性岗位。这说明方案把治理当成一项持续的运营职能，而不是一次性的工具部署。

但这个取舍也有代价。重组织意味着变革阻力大，每个角色的职责调整都要动到部门利益；轻工具意味着短期内看不到“上线一个系统”的成果，治理效果要靠 KPI 慢慢体现。对于习惯了“买个平台就完事”的企业，这套方案的落地难度其实更高。反过来说，如果企业已经试过工具路线失败，这套组织先行的思路反而是对症的。

验证这套方案是否适合自己，我一般会看三个信号：一是企业是否有跨部门的数据争端需要裁决（有，则委员会和督导机制有用）；二是存量系统是否已经出现同一数据多口径（有，则概念模型和唯一数据源是刚需）；三是业务部门是否愿意派人兼职做督导（不愿意，则所有制落不了地，再好的模型也是纸上谈兵）。

从那以后我每次看数据治理方案，都先翻它的 RACI 矩阵和 FTE 表，而不是先看架构图——因为架构图可以画得很漂亮，但谁在什么流程里负什么责、投多少人，才是这套东西能不能转起来的黑匣子。希望帮到你。

本文还有配套的精品资源，点击获取