简介这份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 三层所有制怎么落到组织上方案把所有制分成三层对应三种角色这个分层逻辑值得细看层级角色核心职责典型配置企业级企业数据督导副总信息师级定数据政策、分配治理角色、裁决争端1 人50% 投入能力板块级各业务部门数据督导科/副科级本板块数据分类定义、质量 KPI、SLA每板块 1 人30% 投入系统/项目级数据建模师、物理建模员逻辑模型设计、物理落库实施建模师 5 人、物理建模 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 表而不是先看架构图——因为架构图可以画得很漂亮但谁在什么流程里负什么责、投多少人才是这套东西能不能转起来的黑匣子。希望帮到你。本文还有配套的精品资源点击获取
