企业官网建设流程全解析

1. 先说清楚：MDG 的工作流为什么不能拿普通 WF 知识硬套

我最早接触 MDG 工作流的时候，脑子里装的是以前做采购申请释放、做 HR 审批那一套逻辑：找个单据类型、挂个状态、配个 WF 模板，完事。结果在 MDG 项目里第一次联调就被打脸了——变更请求提交之后，工作流压根没有按我想象的方式触发，代理也永远解析不对。后来把 MDG 的触发机制、绑定关系和代理逻辑捋清楚之后，才发现这套东西和普通 SAP 工作流长得像，内核完全是另一套玩法。

先给没接触过 MDG 的读者补个底：SAP MDG（Master Data Governance）是 SAP 的主数据治理平台，物料、供应商、客户、财务科目这些主数据的创建和更改，都要通过“变更请求（Change Request）”来完成。举个例子，业务人员在 MDG 界面里发起一条“新建供应商”的申请，这条申请会走一段审批流，审批通过之后，数据才真正落库或者发到下游系统。这个审批流，就是我们要配的工作流。

MDG 工作流和普通工作流最核心的区别在于：它既不是挂在事务代码的事件上，也不是挂在某个单据的状态转换上，而是挂在“变更请求”这个特殊的业务对象上，并且由 MDG 框架在特定节点触发。你在标准 WF 里玩得再熟，如果不懂 MDG 在哪个节点触发、往工作流容器里塞了什么参数，配置起来就只能靠猜。

这篇内容适合三类人看：刚接手 MDG 项目的业务顾问，正在被“代理解析不对”折磨的 WF 开发，以及要给主数据团队搭审批体系的管理人员。我会从“为什么 MDG 要单独设计工作流”讲起，然后走一遍从复制标准模板到代理分配的完整配置过程，最后把我踩过的坑和排查思路一起倒出来。

2. 触发源头与绑定关系：MDG 工作流是怎么被“激活”的

2.1 变更请求：MDG 工作流的唯一入口

MDG 工作流的触发对象只有一个，就是变更请求。这个请求可能对应主数据的创建，也可能对应更改或删除。在 MDG 的系统里，每个变更请求至少带着三个关键属性：

• 变更请求类型：比如“供应商变更”“物料变更”，本质上是基于某个 MDG 对象类型（Supplier、Material）生成的请求类型。
• 流程类型（Process Type）：描述这个请求属于哪一类流程，比如标准审批流程、简化流程。
• 编辑类型（Edit Type）：这个请求是创建（Create）、更改（Change）还是删除（Delete）主数据。

这三个属性决定了它该走哪条工作流。什么意思呢？同一种变更请求类型，你可以让“创建”走三级审批，“更改”只走一级审批，“删除”走一个单独的删除审批流程。这是 MDG 工作流配置的底层逻辑，也是和普通 SAP 工作流的根本差异——普通工作流的触发条件通常是状态变化，而 MDG 是根据“请求类型+流程类型+编辑类型”这个组合去找工作流模板的。

还有一个容易忽略的点：MDG 工作流触发不是靠你在 SWDD 里手动“启动”，而是 MDG 框架在变更请求保存或提交的事件里自动广播出来的。具体来说，当用户在 MDG 界面点了保存/提交，框架会发出一个工作流相关事件，事件参数里带着变更请求编号、流程类型、编辑类型这些信息。你在工作流模板里做的容器绑定，本质上就是把这些事件参数接进工作流内部，后续代理规则、消息文本都靠这些参数计算。

2.2 工作流分配表：MDG 工作流的“路由表”

MDG 工作流配好之后，怎么告诉系统“哪种请求该用哪个工作流”？靠定制里的分配表。在 SPRO 里走：

SPRO → 主数据治理 → 通用主数据治理 → 更改请求 → 设置工作流 → 分配工作流到流程类型

对应的配置视图常见的是 V_TUSMD111。这张表是关键中的关键，它的作用就是把“变更请求类型+流程类型+编辑类型”这个组合映射到一个具体的工作流模板上。维护的时候有几点必须注意：

• 这里分配的是工作流模板（Workflow Template），不是单个任务。标准模板编号一般在系统里是 WS 开头的，复制出来的自定义模板会变成 Z 开头。
• 同一组条件只能分配一个工作流模板。如果同一个请求类型、同一个流程类型、同一个编辑类型你维护了两条记录，系统会取哪条？这取决于你系统的版本和选择顺序，但无论如何这都属于配置冗余，我强烈建议不要这么干，排查问题的时候你会疯掉。
• 没有维护工作流模板的话，变更请求不会触发审批流，数据可能直接就通过了。很多人测试的时候说“怎么没走审批”，第一反应是去查 WF 日志，最后发现是这表压根没配。

从项目实践看，这步是 MDG 工作流配置里最简单也最容易漏的：因为 SPRO 节点路径有长有短，不同版本还略有差异，顾问如果只是照着上一家项目的截图找菜单，很容易找错位置。建议直接事务代码查这个视图，省时省力。

2.3 为什么推荐“复制标准模板”而不是从零建

接 MDG 项目的时候，我见过有同事打开 SWDD 直接新建模板，一个节点一个节点地拖，最后配出来的工作流不是容器绑定缺胳膊少腿，就是业务对象类型选错导致事件参数接收不到。MDG 工作流这个领域，从零开始建模板的代价远高于复制标准模板。

标准模板是 SAP 官方维护好的，里面已经把业务对象类型、容器元素、事件绑定、消息映射都预设好了。拿常见的单级审批场景来说，标准模板里已经有“处理人确定”“审批处理”这类节点，你只需要在上面改代理规则、调整审批层级。基于标准模板复制修改，可以把低级错误的概率压到最低。

我习惯这样做：进入 SWDD，找到系统里标准的 MDG 工作流模板（不同版本编号不同，但通常以 WS 开头，名字带 MDG 或 CHANGE 关键词），用“复制”功能生成一个 Z 开头的自定义模板，再在这个副本上做调整。20 分钟能完成的事情，不要花半天从零搭还提心吊胆。

3. 第一套能跑的审批流：模板、任务、步骤的搭建顺序

3.1 任务与步骤：别把这两个概念搞混

很多第一次配 MDG 工作流的人会被“任务（Task）”和“步骤（Step）”绕晕。简单说：

• 步骤是工作流模板流程图里的一个节点，它代表流程走到哪一步了。
• 任务是步骤背后真正执行的东西，分为手动任务和自动任务。手动任务会生成一个待办事项，需要有人在 SAP 收件箱（或者 MDG 的 UI）里点审批；自动任务则由系统后台执行，比如更新状态、发消息。

常规做法是：在流程图里放一个步骤，步骤指向一个手动任务，代理就配在这个手动任务上。这样职责清晰：换审批人只需调整任务上的代理规则，不用动流程图结构。

用 SWDD 建任务/步骤的入口分别在事务代码 SWDC（维护任务）和 SWDD（维护工作流模板）里。任务建好后要激活，模板建好后也要激活——这两个对象相互独立，很多人只激活了模板，忘了激活任务，测试时一直看不到待办，查半天才发现任务处于“已修改/未激活”状态。

3.2 容器绑定：事件参数怎么进工作流

容器是工作流的数据交换中枢。MDG 框架触发工作流时，把变更请求号、流程类型、编辑类型等信息放到事件参数里，你要在模板的容器绑定里把这些参数接到工作流自身的容器元素上。常见需要绑定的元素至少包括：

• 变更请求编号（Change Request Number）
• 流程类型（Process Type）
• 编辑类型（Edit Type）
• 如果需要按主数据字段（比如金额、工厂）做分支或代理判断，还得看 MDG 在事件里是否传了相关字段，没传的话要自己在工作流里读取。

上个月我给别人做代码评审还见过一种低级错误：模板里用了一个容器元素叫“LV_REQUEST”，事件里传的参数叫“IV_CHANGENUMBER”，绑定关系没建，工作流启动后容器元素全是空的，代理规则直接解析失败。这种问题查起来其实不难，但步骤错了会浪费大量时间。绑定关系在 SWDD 的容器/绑定页签里检查，多花两分钟看一眼，能省两个小时的排查。

3.3 最小可用配置：从复制到激活的完整动作

我建议你第一次配 MDG 工作流时，按下面的顺序走一遍，先别想着复杂的层级审批，就把一条“创建→一级审批→生效”的链路跑通再说。

1. 打开 SWDD，查看标准 MDG 工作流模板，确认当前系统里事件触发的业务对象类型和参数。
2. 复制标准模板为 Z 开头的新模板，重命名时带上用途后缀，比如 ZWF_MAT_CREATE，后续维护一目了然。
3. 在 SWDC 中复制/新建一个手动任务，命名规则同上，代理先临时配一个自己的用户名，保证能跑通。
4. 回到 SWDD，把模板里原来的审批步骤指向新任务；调整流程线路，确保开始事件之后能够到达这个步骤。
5. 检查容器绑定：把事件参数和任务需要的容器元素一一对上，特别是变更请求编号，后续代理规则和消息里都要用到。
6. 激活任务和模板，在 SWDD 里保存并激活模板，在 SWDC 里激活任务。
7. 到 SPRO 的“分配工作流到流程类型”视图，为对应的变更请求类型、流程类型、编辑类型分配这个新模板。
8. 回 MDG 界面发起一条测试请求，提交之后到 SWIA 里看工作项是否生成。

整个流程走下来，快的话半天时间。第一次跑通之后，你才算真正理解了 MDG 工作流的骨架，后面加层级、加条件、换代理规则，都属于在这个骨架上做增补。

4. 代理分配详解：三种落地方式与适用场景

4.1 代理分配为什么是 MDG 工作流的“事故高发区”

代理分配是整个 MDG 工作流配置里最值得花时间琢磨的地方。原因很简单：模板、任务、绑定这些属于“一次性配置”，配好之后基本不用动；代理规则却和组织的岗位体系、人员主数据、甚至是主数据的归属强相关，只要组织结构一变、人员一换、审批策略一调，代理就会出问题。

在任务或步骤的代理页签里，你通常有三条路可以走：直接指定用户、通过组织管理解析、通过规则（比如 BRF+ 或 MDG 的责任范围）确定。选哪条路，决定了你未来维护工作流的成本。

我把三种方式放在一个表里对比：

4.2 直接指定用户：只配用来“把链路跑通”

在实际项目中，我见过不少项目上线前还在用这种方式，直接把审批人写成某个人的用户名。这样做短期内确实省事，但隐患很大：一旦这个人离职或者调岗，审批流就断了，工作项卡死在那里，业务人员不停地打电话问“为什么没人审批”。

我的建议是：这种方式只配在开发环境，目标就是把工作流链路跑通、验证事件触发和待办生成逻辑。到了测试环境或生产环境，尽早切换到组织管理方式或规则方式。如果你已经上线了还在用直接指定用户，建议把这件事列进技术债务清单，尽早处理。

4.3 组织管理解析：生产环境中我最推荐的方式

用组织管理（OM）做代理解析，是 SAP 工作流里最成熟、也最符合长期维护需求的方案。核心思路是：不直接指定“张三审批”，而是指定“这个组织单位的负责人审批”或“这个职位的任职者审批”，人员变动时改组织管理就行，工作流模板和任务本身不用动。

在具体配置时，你要先保证几个前置条件：

• 在 PPOME（组织管理维护）里建好组织单元、职位，并把人员分配给职位。
• 确定“审批人”对应的关系类型。SAP 组织管理里常用关系 8 表示“负责人”，关系 007/B-002 之类的表示其他岗位关系，具体用哪个要看项目的组织架构设计。
• 在任务/步骤的代理页签里选“表达式”，然后按系统支持的规则写：比如“确定组织单位的负责人”“查找职位任职者”等。

说到这必须提一个常见坑：组织数据没同步。MDG 项目里经常出现的情况是，工作流配置完全正确，但代理解析出来是空的，查到最后发现是 PPOME 里这个组织单位下面根本没有挂职位，或者职位上的分配有效期已经过期。这类问题不属于工作流本身，但工作流会把锅背了。排查时一定要先确认组织管理的基础数据。

使用 OM 方式还有一个设计上的好处：审批链可以跟着组织结构走。比如你先配一个“二级主管审批”的规则，将来组织调整、汇报线变化，只需要在 PPOME 里调整“负责人”关系，审批流自动跟着新汇报线走，完全不需要碰工作流配置。这才是生产系统该有的姿态。

4.4 规则/责任范围：面向“数据归属”的治理思维

如果你觉得按组织单位审批还不够灵活，MDG 还提供了一条更贴近主数据治理本质的路：按主数据本身的归属关系决定审批人。

这个概念在 MDG 里叫“责任范围（Responsibility）”。举例来说：一张物料主数据属于工厂 1000，创建这条物料的审批请求，就应该由“工厂 1000 的物料负责人”来审批；如果这条物料同时属于工厂 2000，可能还得追加工厂 2000 的负责人一起会签。在这个逻辑下，审批人不是按单据类型定死的，而是按主数据的关键属性动态算出来的。

实现上会用到 BRF+ 应用（比如 MDG 规则相关的应用场景）或 MDG 的规则配置功能。你需要在规则里定义：当流程类型=XX、主数据字段=YY 时，返回哪些代理。这种方式的学习成本和配置成本都明显高于前两种，但它在复杂组织架构、多组织协同审批的场景里，带来的维护收益也最大。

我对社区里读者的建议是：如果项目刚开始，代理分配能按组织管理走的，就先按组织管理走；等业务语义复杂到“按组织管不动了”，再考虑上规则。不要一上来就炫技，BRF+ 里的判断逻辑一旦写复杂，后续维护的人会很想骂人。

4.5 多代理时的分配模式：会签和或签要分清

任务配了多个代理之后，还要决定“几个人怎么批”。工作项里通常有两种模式：所有代理都必须处理（会签）和任一代理处理即可（或签）。这两个概念 MDG 工作流里也同样适用。

会签场景：比如“所有工厂负责人同意后，变更请求才能生效”，你在任务代理页签里把分配模式设为“所有代理”，每个人都会生成工作项，全部处理完才进行下一步。

或签场景：比如“任一部门经理审批即可”，设为“任一代理”，尽管多个候选人都能看到工作项，但只要有一个人审批，该节点就算完成了。

我见过最典型的问题是理解了这两个概念，却没理解系统默认行为。有些配置里把代理配成了一个职位，这个职位上有两个人，或签模式下合情合理；但如果你期待的是两个人分别审批，配置时就要明确选择会签。还有一点：当代理是“按组织单位解析”时，同一个组织单位解析出多个人，系统的分配模式依然受这个设置控制，别以为组织单位解析出来的人会自动都算会签。

5. 测试与排错：工作流没走对，该怎么定位问题

5.1 三个事务代码定位 80% 的工作流问题

MDG 工作流测试时，我常用的入口只有三个：SWIA、SWI1、SWI2_FAVL。大部分问题用这三个就能定位，不需要去啃 ABAP 调试。

• SWIA：看工作项列表。你提交一个变更请求之后，正常应该能在这里看到对应的工作项。看不到？那就说明工作流可能压根没触发，或者 V_TUSMD111 里没有分配模板。
• SWI1：看工作流日志。这里能看到工作流实例运行到哪个节点、事件有没有收到、代理解析结果是什么。代理解析失败、容器参数为空这类问题，日志里一般都有线索。
• SWI2_FAVL：看错误工作项。有工作项但报错了，在这里能看到具体错误消息。很多代理解析不到人的错误会集中出现在这里。

排查思路按顺序来：先确认模板有没有触发（SWI1），再确认工作项有没有生成（SWIA），最后确认代理对不对（SWI1 日志/工作项属性）。别上来就点进错误工作项里看半天，从源头往外推，效率更高。

5.2 高频问题排查表

我把项目里遇到的高频问题整理成一张表，每一条都对应一个“现象→原因→排查入口”，方便你以后直接对号入座：

5.3 一个让我印象深刻的项目坑：代理解析成功但审批人没有待办

说一个真实经历。之前某个项目，测试环境里工作流日志显示代理已经成功解析到了一个用户，但那个用户登录系统后，收件箱里就是看不到待办。查了两天，最后发现原因是：

• 这个用户在 SU01 里被设置为“已锁定”，系统不给他生成有效工作项。
• 代理解析出来的不是一个人，而是三个人，但工作项分配模式是“任一代理”，其他两个人没维护邮箱，导致通知没有发出去。

这类问题的本质是：工作流配置没问题，但用户主数据和通知基础数据有问题。我后来养成了一个习惯：每次排查 MDG 工作流问题，先让 Basis 同事确认解析出来的用户是否健康（未锁定、有邮箱、有角色），再回头查工作流本身。很多时候，你以为的“工作流配置问题”，其实是主数据问题。

6. 代理策略设计建议：让工作流少“动手术”

6.1 按“变化频率”决定代理配置方式

这个思路也是我做了几个项目之后总结出来的：什么样的代理信息变化频率低，就优先把它固化下来；变化频率高的，就让它动态解析。

• 用户名变化频率最高（离职、调岗、请假），所以直接指定用户只适合临时场景。
• 组织结构和汇报线变化频率中等，用组织管理解析能扛住大部分调整。
• 主数据属性归属（某个工厂归谁负责）变化频率相对低，但关系复杂，适合用规则/责任范围管理。

按这个原则去设计代理策略，基本不会出大错。反过来，如果你发现某个工作流代理“总在改”，十有八九是当初选错了代理方式——比如本来应该挂在组织管理上的，结果直接写死了用户名。

6.2 上线前的最后检查清单

工作流传输到生产环境之前，我会跑一遍自检清单：

• V_TUSMD111 中目标环境的模板编号正确。
• 任务和工作流模板都处于激活状态。
• 容器绑定齐全，变更请求编号等关键元素非空。
• 代理解析出来的用户，在 SU01 里有有效邮箱、未被锁定。
• 生产环境的组织管理数据已导入，职位和负责人关系有效期正确。
• 至少在生产环境预演一次完整的“创建→审批→拒绝→重新提交”流程。

这七项都过了，MDG 工作流才敢说具备上线条件。其中第一项和第五项是最容易在生产环境翻车的——因为开发/测试环境和生产环境的配置数据、组织数据是两份，很多项目在传输的时候漏了分配表或者忘导入组织数据，上线当天才手忙脚乱。

6.3 后续可以扩展的方向

如果这篇基础配置你已经完全吃透了，后续可以往这几个方向做扩展：

• 多层审批与条件分支：按金额或者主数据属性（比如影响公司代码数量）判断走几级审批。
• 超时提醒与升级：用 SAP 工作流的时间管理功能，审批超过 N 天自动发提醒给上级。
• 通过 BRF+ 重构代理逻辑：把代理判断从工作流配置文件里抽出来，放到业务规则里统一管理。
• 操作日志与审计：结合 MDG 的变更文档功能，为每条变更请求保留完整的审批痕迹。

这些方向每一个都能单独展开写一篇。但不管扩展到多复杂，底层还是离不开今天讲的这些基础逻辑：模板绑定、任务代理、容器参数、事件触发。

7. 最后分享一点实战感悟

MDG 工作流上线后，真正消耗运维时间的问题，一半以上不是工作流配置本身，而是组织和用户主数据没维护好。代理解析不到人、审批人收不到通知、待办没生成，大概率是 PPOME 里职位没人、SU01 里没邮箱、分配表里漏配这类基础事情。配置工作流本身只需要小半天，但要把代理策略和组织的岗位体系对齐，才需要真正花时间。

如果你现在正被 MDG 工作流搞得焦头烂额，我的建议是：先把一条“创建→一级审批→生效”的链路跑通，不要急着做多层审批和复杂分支。链路通了之后，再逐步加条件、加层级，每加一层就做一次完整回归。这样看起来慢，实际上是最快能稳定上线的路径。工作流这种东西，越简单越可靠，复杂逻辑带来的维护成本，会在你上线后的每一个深夜以“生产报错”的形式还回来。