简介这是一份面向SAP顾问、数据治理人员与IT架构师的SAP MDG 9.0中央治理能力概览文档由官方PPT转存为PDF。内容从主数据管理普遍挑战切入梳理销售效能降低、采购决策次优、新品上市延迟、业务决策失效四类典型问题并据此展开SAP MDG的解决路径统一平台管控客户、供应商、物料等核心主数据实施审批、版本控制与审计跟踪支撑跨部门、跨系统数据同步强化变更管理并提供监控分析工具。资源仅有1个PDF文件压缩包大小约2.54MB篇幅精炼但覆盖完整框架适合快速建立对SAP MDG的认知。当前已有669人学习下载对正在了解数据治理方案、准备售前演示或规划MDG项目的读者可作为入场读物与培训参考。1. SAP MDG Overview它解决的从来不是“装个新模块”的问题「SAP MDG Overview」这类标题在项目启动会的 PPT 里出现的频率远高于它被正确理解的频率。MDG 是 SAP 主数据治理Master Data Governance的缩写它解决的是同一家集团里物料、供应商、客户在不同系统各写一份的问题S/4 是一套编码MES 里是另一套采购平台的供应商档案和财务的又对不上审批靠邮件来回几十封。MDG 做的事是把主数据的创建和变更收口到一个统一入口配上一套可管控的流程、校验规则和分发机制再推送给下游各系统。它适合已经有 SAP ERP 或 S/4、主数据被 MES/MOM/SRM 等多方消费且审计和对接需求逼着集团必须统一编码口径的组织。下面从数据模型、落地配置、分发验证到踩坑按一条真实交付路径展开。2. 先把对象认全MDG 的数据模型、变更请求和流程怎么配合很多人第一次接触 MDG容易被一堆以 USMD 开头的事务码和一个陌生的 Web 界面吓住。其实 MDG 的核心只有三样东西数据模型、变更请求、流程。把这三者的关系想清楚后边的配置和排障基本就顺了。2.1 数据模型物料、客户、供应商之外MDG 还能管什么MDG 预置了几套标准数据模型物料MDG-M、客户MDG-C、供应商MDG-S、财务主数据MDG-F比如成本中心、利润中心这类。注意一个常见误解这不是四个独立安装的产品而是在同一个 MDG 平台上的四套标准模型每套模型针对一类主数据对象定义了它的实体、属性和层级关系。以物料为例。物料主数据在 ERP 里物理上分散在若干张表里MARA 是基本数据MARC 是工厂层视图MARD 是存储视图此外还有销售视图、采购视图对应的表。MDG 的数据模型做的事情就是把这些散落的字段重新组织成一张逻辑上的“物料信息网”让业务人员在一个界面里看到完整的物料主数据而不是去记哪张表在哪个视图里填。这张网同时也是后续所有功能的骨架界面显示哪些字段、校验规则作用在哪个属性、激活时写回哪些表、分发时传给下游什么内容全部由数据模型定义。这也是为什么实施 MDG 的第一步通常是“建模型”而不是“配流程”。标准模型可以直接用但你几乎总要扩展它比如给物料加上一个集团自定义的“质量等级”字段或者给供应商模型配上“准入状态”属性。扩展的方式是在标准模型上附加字段和关系而不是另起炉灶重建一套。这里给你一个实操中的判断标准如果业务需求里出现了“我们想管一个标准模型之外的新对象”才考虑自定义数据模型如果只是给现有对象加几个字段老老实实用附加字段成本低得多后续升级也安全。2.2 变更请求与流程编排一条主数据从申请到生效的完整路径有了数据模型接下来要回答的问题是一条主数据怎么被创建或修改。MDG 的答案是变更请求Change Request简称 CR。业务用户在 MDG 的工作台里发起一个 CR填物料属性、传附件、提交然后这条 CR 开始走流程各级审批、数据校验、激活、分发。CR 不只是电子审批单它把申请内容和数据变更绑定在一起审批通过后数据才进入激活环节。流程定义是 CR 的路线图谁先审、谁后审、哪些步骤并行、哪些条件分支。MDG 的流程支持串行和并行任务也能接 SAP 的工作流引擎做更复杂的组织审批。配置上变更请求类型承载这一切——一个 CR 类型关联一个数据模型、一套界面配置、一条流程定义、一组激活规则。比如“物料新建申请”和“物料批量修改申请”可以配成两个类型走不同审批链。落地时值得先确认好这几个配置项否则后面返工概率很高配置对象作用常见的坑变更请求类型编码决定 CR 的编号规则和归类编码规则没规划批量导入时编号混乱激活模式激活到 MDG 活动区还是直接写目标底表选错导致下游提前看到未定稿数据重复检查开关是否在提交/激活时触发查重服务开着但没配查重规则形同虚设流程定义分配指定该 CR 类型走哪条审批链一个类型挂错流程审批人全乱分发规则激活后推送哪些字段给哪个下游系统没配过滤条件整包数据全量下发讲个最容易忽略的点激活和分发是两回事。激活是把数据正式写入 MDG 或目标系统的底表分发是把这个变更推送给下游。很多项目初期把两者绑在一起激活即分发省事但灵活性差。我一般建议至少在概念上把两步分开想——激活解决“数据合法生效”分发解决“下游何时看到什么”。后面第 4 章会展开这里先记住这个边界。流程跑起来之后的日常操作其实不复杂业务用户在 MDG 工作台建 CR填数据提交审批人在收件箱里看到待办任务审完数据激活系统按规则分发。你不需要理解每次激活底层写了哪些表但出了问题能查看 CR 的处理历史包括激活日志和分发状态这是基本能力。实践里 80% 的 MDG 运维问题都发生在这个环节之外——不是不懂操作而是模型和流程的配置边界没搞清楚。3. 从零落地在 S/4 旁边把 MDG 环境跑起来的配置清单Overview 看得再多不如在一个测试集团把最小流程跑通。MDG 落地的第一步不是写代码而是选部署结构、规划集团、然后在一套干净的测试环境里做配置闭环。3.1 部署选型与集团规划独立系统还是和 S/4 同栈部署方式上MDG 可以是独立系统也可以与 S/4 同栈部署取决于你的许可证、系统规模和治理边界。常见做法是独立一套 MDG 系统作为主数据源S/4 和外围系统作为消费方。好处是变更请求的审批流、去重服务和激活逻辑都在 MDG 侧完成不会因为 S/4 的日常业务负载拖慢治理流程坏处是多一套系统要维护、多一跳传输和接口链路。集团规划是另一个容易被小项目忽略的点。MDG 至少要分三个集团开发配置集团做模型和流程配置、测试集团跑验证和用户验收测试、生产集团正式业务使用。配置对象——数据模型、流程定义、界面配置、分发规则——都通过传输请求传递走 STMS 的常规传送链。很多项目在开发集团配好了流程往测试集团一传发现激活环节报错原因往往是传输漏掉了数据模型或 UI 配置对象只传了流程定义。这里给你一张最小落地检查清单照着过一遍能省去大量联调时间检查项入口要点业务功能激活SPRO 里激活 MDG 相关业务功能没激活后边一堆配置节点是灰的数据模型维护SPRO → Master Data Governance → General Settings确认标准模型已复制、附加字段已定义变更请求类型SPRO → MDG → Change Request新建类型并挂接数据模型流程定义SPRO → MDG → Process配好审批节点和人员解析分发配置SPRO → MDG → Distribution定义目标系统和出站服务权限角色PFCG 维护角色按数据范围分配别用 SAP_ALL 顶着这张表的顺序就是实施顺序先有模型才有 CR 类型才有流程最后才是分发和权限。跳步走后边一定要回来补。3.2 配置与试运行三个入口和一个最小闭环下面这组入口可以贴在 SAP GUI 的命令框里直接调出它们是配置阶段最高频用到的事务码# 配置主入口SPRO 里按项目结构找 MDG 相关 IMG 节点 SPRO # 业务用户实际操作 MDG 工作台时常用事务码以 USMD 开头 # 例如变更请求列表、数据模型维护等不同版本前缀有差异以你系统文档为准 USMD* # 查看底表数据验证激活是否写入目标表只读别在 SE16N 里直接改数 SE16N参数说明SPRO 是整个配置的根入口USMD 开头的是一族事务码具体到哪个功能要看你系统装的具体组件所以这里给了通配写法而不是某一个码能少走“照着网上的码一敲发现不存在”的弯路SE16N 是查底表和验证数据的通用入口但记住它是维修工具不是数据维护工具改数据应当回到 MDG 流程里改。配置完成后真正验证配置是否成立的是最小闭环在 MDG 工作台创建一个测试物料的 CR填写基本视图和工厂视图字段提交审批人通过激活然后在 S/4 侧用 MM03 查看这条物料是否已经可见工厂视图扩展是否生效关键字段值是否正确。如果这一步通了主链路就通了剩下的都是分支和边界。跑这个闭环时建议用一条你手工创建的测试物料不要用批量导入的数据否则出了问题不好判断是流程问题还是数据问题。这个闭环里最值得关注的是激活日志。激活失败时日志会告诉你具体卡在哪个字段、哪条校验规则、哪个底表写入失败。第一次跑时遇到激活失败很正常多数原因是附加字段没映射到底表或必填字段没填全。把这些问题记下来它们是你第 5 章要看的踩坑清单的素材。4. 数据分发与全链路验证MDG 不把数据送进业务系统就是白干MDG 里数据治理做得再漂亮如果下游系统迟迟收不到、或者收到的是错的字段业务照样不认账。分发是整个 MDG 落地里最容易被当成“玄学”的部分因为分发日志常常被视为黑匣子——配置点在 SPRO 里看着都配了可真到联调就有一堆意外。4.1 分发机制选型RFC 直连、中间件与云集成怎么选MDG 向 S/4 或外围系统分发数据常见的有三条路RFC 直连、Web Service 走企业服务基础设施、以及经 SAP PO/CPI 这类中间件做异步分发。分发方式适用场景注意点RFC 直连同步/异步地端 S/4 与 MDG 同网络链路简单同步调用要控超时大批量慎用同步模式Web ServiceSOAP异构系统、第三方平台对接字段映射得提前逐字段对齐接口变更成本高PO/CPI 中间件云上 S/4、跨网络隔离、多处转发多一跳就多一个故障点消息重跑机制必须设计好选择时要看你的下游到底是谁如果只发到本地 S/4RFC 直连通常最简单如果下游是 MOM/MES 这类制造执行系统接口往往落在 MM 的物料主数据上最常见的做法是 MDG 激活后通过 RFC 或 API 把物料主数据推送给 MOM这时候要特别确认字段口径——MOM 通常只需要物料编码、描述、单位、批次策略等有限字段没必要全视图下发。如果下游在云端链路多半走 CPI 这类中间件那就得把重试和消息确认机制设计进接口里不能指望网络永远稳定。分发配置里另一个高价值参数是过滤条件。你可以在分发规则里定义“哪些字段、哪些工厂的数据需要推给哪个系统”避免每次任何字段变化都触发全量推送。很多项目初期为省事不做过滤结果下游系统收到大量无关变更接口日志爆炸排查问题时谁也说不清哪条消息是有效变更。过滤条件建议一次配到位宁可先严后松不要先松后严。4.2 验证方法从变更文档看到下游底表分发配完后验证不能只盯着 MDG 一侧的“分发成功”状态那个状态只代表消息发出去了不代表下游表真的更新了。我习惯用三层验证先看 MDG 侧分发日志再看下游接口日志最后直接查下游底表。查底表是最硬的证据。下面的 ABAP 代码演示了怎么快速核对一条物料在目标系统的写入情况和变更文档PARAMETERS: p_matnr TYPE mara-matnr OBLIGATORY. 1. 查基本数据是否已写入目标系统底表 SELECT SINGLE matnr, ernam, laeda, mtart FROM mara INTO DATA(ls_mara) WHERE matnr p_matnr. IF sy-subrc 0. WRITE: / 基本视图已存在最近修改日期, ls_mara-laeda. ELSE. WRITE: / MARA 无此物料分发可能未生效. ENDIF. 2. 查变更文档确认 MDG 激活留痕 SELECT changenr, udate, utime, uname FROM cdhdr UP TO 5 ROWS WHERE objectclas MATERIAL AND objectid p_matnr ORDER BY udate DESCENDING, utime DESCENDING. LOOP AT cdhdr. WRITE: / 变更单, cdhdr-changenr, 时间, cdhdr-udate, cdhdr-utime. ENDLOOP.逻辑说明第一段读 MARA 确认物料基本视图在目标系统是否可见第二段读 CDHDR 变更抬头表看最近几条变更留痕。CDHDR 配合 CDPOS 明细表就是常说的“物料变更底表”——很多人以为物料变更只写 MARA/MARC实际上 MDG 每次激活都会在变更文档里留一笔这是审计时最有用的表。参数说明p_matnr 是你要核对的物料号laeda 是最后修改日期字段objectclas 用 MATERIAL 过滤物料相关的变更文档对象实际项目里 CDHDR 数据量很大查询时务必按物料号和日期范围过滤否则性能很难看。查完底表建议再做一个业务侧验证改一条影响 MRP 的字段比如采购类型或批量规则走完 MDG 流程后去 S/4 里用 MD04 这类物料需求清单界面看结果是否刷新。这个验证的意义在于底表更新了不代表业务算对了只有 MRP 运行结果和你预期一致分发才算真正闭环。5. 避坑指南MDG 实施里最常翻车的 5 个实际问题这一章是我最想让你先看的部分。MDG 项目里翻车的往往不是配置本身而是配置背后那些没人提前说的边界。以下 5 个坑来自实际交付中的高频问题每条都按现象、原因、解决给到你可以直接对照排查。5.1 坑一初始导入绕过 MDG直接拿 LSMW 刷底表现象上线前用 LSMW 批量导入物料主数据导得又快又顺。结果上线后新起的 MDG 变更流程在激活时频繁报错或者激活后旧字段被覆盖数据对不上。原因MDG 有自己的一套激活逻辑要求数据先经过它的模型映射、校验和去重服务。绕过 MDG 直接写底表等于两套写入逻辑并行MDG 侧对这批数据完全没有认知激活时自然冲突。解决初始导入必须回到 MDG 的轨道上来。常见做法是使用 MDG 的数据导入功能把清洗后的数据文件上传成变更请求批量处理或者通过 BAPI/IDoc 把数据包成 CR 再走流程。这么做看起来多了一步但换来的是数据在治理体系里有完整留痕后续审计和变更追溯才不会变成一笔糊涂账。如果你已经用 LSMW 导了一部分唯一体面的处理是把这批数据作废重导不要试图在底表上打补丁那样迟早要还。5.2 坑二激活即分发下游收到半成品数据现象MDG 侧流程尚未完全结束下游系统已经收到数据变更或者审批还没走完数据就出现在业务报表里。原因分发配置里选了“激活后立即分发”的模式而激活时机设在审批完成之前的数据更新环节。激活和分发被绑死在了一起失去了分发的可控性。解决把分发模式改为审批通过并激活后再触发或者把激活拆成“预激活检查”和“正式激活”两段。配置分发时注意区分“数据更新的时机”和“对外发布的时机”两者的解耦是 MDG 分发设计的核心。改完配置后用一条测试数据走完整个流程确认下游接收时间点落在审批完成之后。5.3 坑三附加字段没做底表映射激活后字段神秘消失现象在 MDG 界面里明明填了自定义字段审批也过了激活日志显示成功但到 SE16N 一查底表字段值是空的。原因自定义字段只加在了 UI 层和模型层没有配置到底表字段的映射。激活逻辑按映射写表映射缺失时字段自然不会落库。解决每次新增附加字段后不要只做界面验证配完字段映射立刻用测试账号走一遍激活闭环直接查底表确认值已写入。把这一步写进团队的配置验收清单比靠记性靠谱得多。另外字段映射配置的变更属于传输对象记得通过 STMS 传到测试和生产集团否则开发环境好好的生产环境又丢字段。5.4 坑四流程卡在“无审批人”任务没人接现象CR 状态停在等待审批审批人收件箱里却看不到任何待办流程日志里提示找不到审批人。原因流程定义里的人事解析步骤没有正确配置——没有关联到组织单位、职位或个人用户。开发环境测试时用的是超级用户能绕过解析传到测试或生产集团后组织数据不同解析失败就卡住了。另一个常见原因是传输请求漏传了流程定义配套的组织分配数据。解决先查流程日志里人员解析步骤的输出确认是没拿到用户还是拿错了角色再到组织管理里核对审批人所在的组织节点。同时对照传输请求清单确认流程定义和人员分配对象都进了同一个请求。经验是别把流程配置留在最后测试集团要在上线前完整模拟一遍真实的组织审批链哪怕多花半天也比上线当天发现没人审单强。5.5 坑五权限给得太粗或太细业务用户两头受气现象业务用户登录后要么一片空白什么都看不到要么能看到全集团所有主数据——后者还经常被审计点名批评。原因MDG 的权限不只是事务码和角色的事还叠加了数据范围和组织级别的控制。有些项目为省事先发 SAP_ALL 让用户能操作流程是跑通了但合规上站不住也有项目只配了角色没配数据范围用户进来界面空白干着急。解决按变更请求类型、数据模型、组织范围三个维度去分角色。比如某分公司的物料管理员只能看到和维护自己工厂的数据而集团主数据专员可以看到全部工厂。授权时先在测试集团把每个角色对应的界面和可见数据范围验一遍确认符合业务需求再发放到生产。权限这种事前期多花一小时配后期少受一个月的审计折磨。6. 进阶玩法用规则引擎和用户出口把 MDG 变成治理平台MDG 跑通基础流程后很多团队会误以为“能建单、能审批、能分发”就结束了。实际上 MDG 真正的价值在于把治理规则沉淀在系统里而不是靠人盯着。这里讲两个常用的进阶手段。6.1 BRFplus 规则把校验从“靠人盯”变成“规则拦”MDG 的校验支持用 BRFplus 规则实现。常见做法是把过去写在 Excel 检查清单里的逻辑搬过来比如物料净重大于 0、供应商税号满足格式正则、工厂视图必填字段非空、多个字段间的联动校验。我一般建议把跨字段校验比如“采购类型为外购时必须有采购视图”优先做成规则因为这类校验靠人眼最容易漏。规则配好后提交和激活环节都会自动拦截问题数据拦截信息直接返回给业务用户省去来回打回的沟通成本。注意测试时要把所有规则都触发一遍看提示文案是否清晰含糊的报错文案只会让用户更困惑。6.2 用激活增强做流程外处理但守住边界如果规则满足不了才考虑用用户出口做激活前后的增强。比如激活后自动创建一条下游系统的附加记录这个场景用增强实现很顺手。下面是激活增强方法的示意骨架CLASS zcl_mdg_activate_exit IMPLEMENTATION. METHOD on_activate. 入参里通常是对象类型和对象键比如物料号或供应商号 注意这里只做读和写下游附加数据的动作 不要再改 MDG 主数据本身否则会和激活逻辑打架 SELECT SINGLE matnr FROM mara INTO DATA(lv_matnr) WHERE matnr iv_object_key. 下游附加表写入例如写一条到自定义表 zt_mdg_log INSERT zt_mdg_log FROM ( VALUE #( matnr lv_matnr act_time sy-datum sy-uzeit ) ). IF sy-subrc 0. 记录错误日志但不要让异常直接中断激活 * RAISE EXCEPTION TYPE zcx_mdg_activate_failed. ENDIF. ENDMETHOD. ENDCLASS.逻辑说明on_activate 是示意方法名实际项目按你所在系统提供的 BAdI 定义来替换接口名。这段代码的核心意图是演示边界在激活增强里只做“读 MDG 数据 写附加数据”不要去修改 MARA/MARC 原本由激活逻辑管理的字段否则异常行为很难排查。参数说明iv_object_key 是传入的对象键如物料号INSERT 语句里的日志表要先在 SE11 建好注释掉的那行异常抛出是提醒你增强里的逻辑异常最好记录日志而不是直接中断激活否则主数据流程会因为一个非关键日志而卡死。这个方向做完MDG 就不再只是一个审批盒子而是一个能承载你公司主数据规则的治理平台。回到我自己的习惯上现在每接手一个 MDG 项目第一件事永远不是看配置文档而是先找一张已经走通的测试数据从头到尾点一遍看每一条校验和分发是否真的落在该落的地方。数据不会说谎配置和人都会。希望这个习惯对你也有一点参考价值希望帮到你。本文还有配套的精品资源点击获取