Master Data Governanceadvanced

Advanced MDG Change Request Lifecycle and Parallel Governance (Part 7)

Key takeaway

Design change requests around business risk, parallel review and restartable workflow so governance stays controlled without creating unnecessary cycle time.

Explanation

A change request is the governance envelope around proposed master-data changes. Different request types should represent materially different business processes, not every minor field variation.

Advanced workflow can route parallel reviewers for tax, finance or compliance while still preserving one coherent change-request outcome. Agent determination should be rules-driven and support organization changes.

Rejected or withdrawn requests need clear semantics. Rework should return to the right step without forcing users to rebuild the request from scratch.

Cycle time is a control metric. A process with too many approval layers can drive users to bypass governance entirely.

Design SLA, escalation and substitution rules so absence of one approver does not block critical master data indefinitely.

Real project scenario

A vendor change required both tax and procurement review, but sequential approvals doubled cycle time. Parallel review shortened turnaround without reducing control.

Common mistakes

Creating too many request types.
Hard-coding approvers.
Losing context after rejection.
Using serial approval where reviews are independent.
Measuring only completion, not turnaround.

Best practices

Keep request types meaningful.
Use rules for agent determination.
Parallelize independent controls.
Support rework cleanly.
Monitor SLA and bottlenecks.

Interview angle

Explain change request as governance lifecycle plus workflow, not merely a form.

Practice this lesson

Quick check

1. Scenario — A vendor change required both tax and procurement review, but sequential approvals doubled cycle time. In this Change Requests situation, which response best addresses the underlying design risk?

2. A senior review of Configuring Workflow Steps and Agent Determination for Change Requests finds this failure pattern: "Assigning one workflow template to multiple unrelated CR types, causing approval logic that fits one scenario poorly for another". Which corrective action is strongest?

3. When a Change Request in SAP MDG is rejected by an approver during the workflow, what typically happens to the staged data changes?

Interview questions

1. A senior architect is reviewing Change Requests. The project situation is: A vendor change required both tax and procurement review, but sequential approvals doubled cycle time. What design changes, validation evidence and production controls would you require before approving the solution?

Answer it in your own words first, then compare.

2. Using this SAP project situation — A retail company implementing MDG for material master governance found that store managers were used to editing materials directly in the legacy system — explain What a Change Request Is and Why MDG Uses It. What should happen, which concepts or process steps matter, and what common mistake would you avoid?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.