简介：SAP MDG Overview是一份面向SAP顾问、数据架构 师及企业数据治理人员的PDF文档，系统介绍SAP Master Data Governance 9.0的中央治理功能。文档从销售效能降低、采购决策次优、新品上市延迟、业务决策无效等维度剖析主数据质量挑战，并针对主数据维护成本高、多系统分散管理、供应商与客户数据不透明等痛点，给出通过统一治理平台集中管理客户、供应商、物料等核心主数据，配合审批流程、版本控制与审计跟踪来解决的思路。资源仅1个PDF文件，压缩包大小2.54MB，内容为2016年SAP官方英文原版概述，重点覆盖中央治理能力，同时明确合并与批量处理不在此范围，便于读者快速把握学习边界。目前已有660人学习下载，适合需要了解SAP MDG整体价值、实施方向或进行内部培训的人员参考。 SAP MDG这东西，圈内人讨论得不少，但真正能讲清楚的并不多。我最早接触MDG是在一个制造业客户的物料主数据项目上，那时候SAP还没有把MDG作为独立产品线推得那么猛，很多企业还在用自研的Excel加ABAP报表硬扛主数据管理，结果就是料号重复、供应商信息各系统不一致、财务和供应链对同一个物料的不同描述吵得不可开交。后来主数据治理这个概念被炒热，MDG逐渐成了SAP生态里绕不开的关键词。我写这篇文章，就是想以我自己的实施经验为线索，把SAP MDG从概念到落地聊透，适合正在评估MDG价值的架构师、准备上手MDG开发的顾问，以及被主数据问题折磨得焦头烂额的业务方参考。
- 先搞清楚MDG到底在解决什么问题
1.1 主数据混乱的本质是流程问题，不是IT问题
很多企业上了ERP 之后，发现数据反而更乱了。原因很简单：一个料号在SAP里是501，但在老旧的OA系统里是MAT-501，在MES里又变成了M501。业务人员为了能让系统间对上账，不得不手工维护对照表。表面上这是系统集成问题，实际上这是主数据创建、变更、审批、分发这条链路缺乏统一管控的流程问题。MDG（Master Data Governance）的核心价值就在这里------它不是简单地给你一个维护界面，而是把主数据的生老病死管起来：谁创建、谁变更、谁审批、变更影响哪些系统、数据质量是否达标，全部纳入一套可追踪、可审计的机制里。
1.2 MDG管的是哪几类数据
SAP MDG支持的治理范围覆盖了企业最头疼的几类黄金数据：
物料主数据（Material）：包括基本视图、工厂视图、采购视图、MRP视图等，解决料号唯一性和字段扩展问题。
供应商主数据（Supplier）：涵盖通用数据、采购数据、财务数据，治理的核心是防止重复建户和银行账户信息错误。
客户主数据（Customer）：销售视图、开票视图、公司代码视图的统一管理，常见痛点是信用额度维护流程混乱。
财务主数据（Finance）：成本中心、利润中心、总账科目、内部订单等，治理重点在于科目表统一和成本中心负责人变更审批。
自定义对象（Custom Objects）：MDG允许通过建模工具扩展，管理企业特有的数据，比如设备主数据、合同主数据。
这里我想特别强调：不要一上来就想着把五种数据类型全部纳入MDG。我见过不少项目，客户雄心勃勃要做全领域治理，结果范围失控、进度延误。务实的做法是先挑业务痛点最大、影响范围最广的一类数据做试点，比如先把供应商治理跑顺，再逐步推广到物料和客户。
- MDG的部署形态与技术架构：从Hub到Embedded
2.1 Hub部署和Embedded部署怎么选
MDG有几种典型的部署方式，选错后续会很被动。
Hub部署（集中式治理） ：MDG系统独立于业务系统，主数据的创建和变更在MDG里完成，审批通过后通过后处理框架分发到下游的ERP、SRM、CRM等系统。优点是职责清晰，MDG是主数据的唯一源头；缺点是需要额外的系统授权和管理成本。
Embedded部署（嵌入式治理） ：MDG直接装在生产ERP系统里，业务流程在同一系统内闭环，不需要经过分发，实施效率高、成本低。缺点是会和业务系统共用一个环境，如果ERP本身性能压力大，需要评估峰值影响。
从我多次项目实践看，中大型企业如果有明确的数据治理组织，而且涉及多套异构系统，选Hub更有长期价值；如果只是想先解决内部的流程规范化问题，而且SAP系统本来就比较统一，Embedded是性价比更高的选择。
2.2 MDG的三个关键技术机制
聊到架构，MDG里头有几个机制是理解它的钥匙。
流程建模（Process Modeling） ：MDG基于BPM（业务流程管理）框架定义主数据变更流程。你可以用SAP Fiori界面配置一个变更场景，比如"供应商创建申请"，定义需要填哪些字段、由谁发起、走哪条审批链、数据预校验规则是什么。流程建模最大的优势是底层数据模型 （比如供应商的BP模型）和界面、规则是分离的，业务调整流程时不需要动底层数据表。
数据复制与分发（Data Replication） ：Hub部署下，MDG通过DRF（Data Replication Framework）把治理好的数据推送到目标系统。这个机制很强大，可以按对象类型、按变更场景、按目标系统灵活配置。实战中，最需要注意的是映射规则的维护------源系统字段和目标系统字段往往不是一一对应的，比如MDG里的"联系电话"字段可能需要拆成多个字段推到下游，这些映射规则必须在DRF里提前定义好。
数据质量管理（Data Quality Management） ：MDG内置了数据质量打分机制，在创建和变更流程中实时校验字段完整性、格式合规性、去重检查等。这块在国内项目实施中经常被低估，实际上它才是主数据治理能否落地的关键。没有质量规则，主数据就只是多了一个录入界面而已。
2.3 UI层：SAP Fiori是标配
现在MDG的操作界面基本是基于SAP Fiori的。比起传统的SAP GUI，Fiori的界面更灵活，可以按角色自定义页面布局，比如"供应商数据申请者"看到的是申请表单，"采购经理"看到的是审批任务和变更历史。这里给初次接触的人提个醒：Fiori的配置相对于SAP GUI那套菜单树是完全不同的逻辑，不要用SAP GUI的习惯去理解Fiori的Tile和应用组，MDG项目里专门配一个Fiori顾问往往能省出大量联调时间。
- 一个典型的MDG实施项目要做哪些事
3.1 项目启动前的领域梳理
不要急着配流程。MDG实施最关键的前置工作是主数据治理模型的梳理。这一步需要业务方和数据Owner深度参与。
以我做过的一个供应商治理项目为例，我们在项目准备阶段用两周时间做了三层梳理：
第一层：理清供应商的字段清单。从采购申请、采购订单、发票校验各环节收集业务人员实际在用的字段，包括一些非SAP标准字段（比如"供应商企业性质"、"是否高新技术企业"）。
第二层：字段的填写责任人和审批规则。这一步特别花时间，因为企业内部对"客户经理维护销售范围还是信用专员维护"经常有分歧，需要组织多次跨部门评审。
第三层：数据质量标准和分发逻辑。比如供应商的税号必须符合18位校验规则，银行账号不能为空且要通过银行代码校验，供应商创建后什么情况下需要分发到SRM。
这套梳理产出的"数据契约"是所有后续配置和开发的基础，它的质量直接决定MDG项目上线后的业务接受度。
3.2 数据迁移：从老系统搬到MDG
MDG上线前，肯定要把原有的主数据清洗进MDG。这块工作远比想象中耗时。清洗过程通常要从多套系统导出数据，用数据质量工具或者写ABAP程序做去重和补全，最后导入MDG。
有几个实战建议：
一定要提前做数据抽样分析，掌握脏数据的比例和分布。有些供应商户头在老系统里重复建了四五次，直接在MDG里合并比迁移后再合并省事得多。
迁移过程中必须保留数据血统（Data Lineage），也就是能从MDG里的每条数据追溯它来自哪个老系统、清洗修改了什么。这不仅是审计需要，也是业务人员信任新系统的基础。
迁移脚本建议用ABAP或者SAP Data Services来写，分批次导入，每导入一批就要做一轮字段完整性和流程发起的验证。
3.3 去重合并：MDG最有价值的功能之一
MDG的去重不仅仅是"跑一遍相似度算法出个报告"那么简单。在供应商治理场景下，MDG会基于名称、地址、税号、银行账号等字段做相似度匹配，然后列出候选重复对，由数据管理员逐条审核合并。
这里有个坑要提醒：自动合并风险很大。供应商数据往往有历史采购记录和未结订单，如果合并不当，会引发财务对账问题。建议上线初期采用"仅提醒不合并"的策略，让数据管理员熟悉匹配逻辑后再逐步放开自动合并。
- 常见坑位与应对策略
4.1 变更流程跑不通，问题多半出在职责矩阵
MDG流程报错、审批卡住，大多数时候不是系统问题，而是职责矩阵没定义清楚。我见过一个项目，供应商地址变更流程定义了三级审批，结果一线业务员每次提交都要打几个电话才能走完流程------因为没有人知道这个字段变更为什么要部门经理、采购总监、财务总监三级都签字。
如果流程设计阶段就能从"这个变更影响哪些模块"的角度反推审批链，很多问题是可以避免的：地址变更一般到采购主管就足够了；付款条件的修改才需要财务确认；银行账号变更还要加一道风控复核。
4.2 接口分发失败的经验教训
Hub部署下，MDG要往多个下游系统分发数据，接口失败的场景非常常见。比如ERP里启用了销售范围，而MDG的客户数据模型里没配对应的销售范围映射，导致分发到一半报错。
这类问题的排查思路很机械但有效：先从DRF的监控报表里看是哪一步报错，是序列化失败、映射缺失还是目标系统接口返回错误。再针对性地调整映射规则或目标系统的接口接口实现。关键是一定要在上线前把下发链路的端到端测试做透，尤其是涉及自定义增强字段的场景，很多项目就是栽在这里。
4.3 别忽略Fiori性能优化
MDG的Fiori界面在数据量大了之后会出现卡顿，这在用户量超过一定规模时需要提前考虑。前端可以把请求改成批量加载模式，后端则要针对MDG的核心表（比如主数据变更请求对象表）做适当索引优化。不要等到用户开始抱怨了才去排查。
- MDG与其他SAP主数据相关技术的边界
5.1 MDG和MDM的区别
很多老顾问熟悉SAP的MDM（Master Data Management）解决方案，MDG出来后，不少人搞不清两者关系。MDM是偏技术的集中式数据管理平台，重点在于系统间数据同步和整合，流程治理能力弱；MDG则是基于NetWeaver、内置在工作流和数据模型之上的治理平台，强调的是"在流程中管数据"。如果说MDM是水泵，负责把水抽到各个水管，那么MDG就是水厂，负责沉淀、净化、分配全流程。现在新项目建议直接考虑MDG，MDM的新增投入意义已经不大。
5.2 MDG和SAP HANA SLT的关系
有些人会不自觉地把MDG和SLT（System Landscape Transformation）扯到一起，觉得都是做数据同步的。SLT是数据库层面的实时复制技术，常用于把ECC数据同步到S/4的转型项目中，它不关心字段的业务含义，也不管审批流程。MDG关心的是数据如何被正确创建和变更，至于技术层面的复制实现，它会用到DRF和相关的接口技术，但和SLT完全是两码事。做架构设计时，如果把它们放在同一层讨论，很容易给开发团队带去错误的方向。
5.3 MDG和主数据接口开发的取舍
不少企业的第一反应是找几个ABAP工程师开发一套主数据维护事务码，再加几个增强表。这种自研方案在短期内确实能顶一阵，但长期来看，业务部门对主数据的诉求会从"能录入"升级到"可追溯、可管理、可分析"，自研系统的成本会急剧走高。MDG的强项是它把成熟的治理流程、数据模型、复制框架都打包好了，不需要从零搭建。当然，如果企业主数据量级不大、业务形态稳定、流程非常简单，自研也是可选项，这需要自己的架构师做深入评估。
- 从实施顾问角度给团队的实战建议
6.1 MDG项目团队的角色配置
一个健康的MDG实施团队，除了项目经理和业务分析师，至少要有这样几种角色：
数据建模顾问：负责数据模型扩展、字段增强和UI建模，精通MDG的数据建模工具。
流程集成顾问：负责DRF配置、PI/CPI接口开发和错误处理设计。
数据迁移专家：熟悉数据清洗和导入，有SAP Data Services经验更佳。
Fiori开发顾问：负责MDG Fiori应用的配置、增强和性能调优。
ABAP开发顾问：处理增强实现、BADI编写和复杂的后端逻辑。
如果团队配置里少了流程集成顾问，BI方向的顾问容易被分发问题拖住整个项目进度。如果少了数据迁移专家，上线初期的数据质量风险会非常高。
6.2 测试环节必须覆盖业务闭环
MDG项目的测试不能只有功能测试。我做过的项目里，最有效的测试方式是组织业务方模拟端到端的业务闭环：从发起申请、审批、质量检查、发布、分发到下游系统，再到在ERP里跑一遍采购流程验证数据是否正确命中。这种测试能验证的不只是MDG本身，还包括主数据变更会引发的业务连锁反应。
6.3 上线前后的运营机制设计
最后想说，MDG上线不是结束，而是治理的起点。系统之外，还需要设计一套运营机制：主数据管理员的日常维护职责、变更请求的服务水平协议（比如供应商创建申请要在两个工作日内审批完毕）、数据质量的月度评估报告等。没有这套运营机制，MDG很快就会沦为一个效率低下的录入工具。
在实际项目中体会最深的一点是：MDG的真正门槛不在产品功能，而在于企业是否愿意把主数据当作一种组织能力去建设。系统只是工具，流程和运营才是灵魂。 你可以在设计阶段花大量时间去理解业务，但千万不要在业务梳理上省时间，这一块省下来的时间迟早会在上线后的故障和业务投诉中加倍补回来。