Advanced Material Governance: Architecture, Integration and Production Design (Part 4)

At senior and architect level, Material Governance should be understood as an end-to-end design problem rather than a list of isolated features.

Core design map
Foundations of Material Governance: Why Centralized Control Matters: Understand the business problem Material Governance solves, the core MDG data model concepts for material, and how governed processes differ from direct table maintenance.

Configuring Change Request Types and Workflow for Material Governance: Learn how to design change request types, assign workflow steps, and configure processing for material create and change scenarios in SAP MDG.

Validation and Derivation Rules for Material Governance: Learn how validations and derivations enforce data quality and reduce manual effort during material change requests, including where rules execute in the change request lifecycle and how to design them for maintainability.

Architecture and production criteria

• Always explain the active/inactive staging concept to business users early so they understand why changes are not instantly visible downstream.
• Avoid duplicating standard consistency checks already enforced elsewhere in the material master logic
• Confirm the specific deployment model's data model extensibility limits before promising business users custom fields or entities.
• Design at least two change request type tiers: lightweight for low-risk edits and full multi-step approval for creation or valuation-relevant changes.
• Document each rule's business justification and owning process area so future maintenance does not remove rules without understanding their purpose
• Document the full status lifecycle and who can act at each status to support audit and troubleshooting later.
• Document which material entities and views are in scope for governance versus which remain under direct maintenance, to avoid scope confusion.
• Enforce segregation of duties by ensuring requesters cannot also be final approvers on the same change request.
• Map business activities (create, change, mark for deletion) explicitly to the change request types your project will use before starting configuration.
• Run automatic validations before any human workflow step to protect approver time.
• Scope every rule as narrowly as necessary to the correct entity type and organizational level to avoid false positives or gaps
• Stage validations progressively across change request steps, allowing flexibility early and enforcing completeness before activation
• Test rules against single-material, multi-material, and mass change request scenarios before go-live
• Use rule-based agent determination keyed on material type, plant, or business unit instead of fixed named approvers.
• Verify the actual rule configuration and extensibility depth available in the target deployment (on-premise, private cloud, or public cloud) before finalizing design

Failure analysis and operational risk

• Allowing the same user role to both create and give final approval on a change request, violating segregation-of-duties expectations.
• Assuming a material is live in operational tables as soon as it is entered in the MDG UI, without realizing it stays inactive until the change request completes.
• Assuming the same rule configuration approach and depth of extensibility exists identically across on-premise, private cloud, and public cloud deployments
• Assuming workflow configuration flexibility is identical across every SAP deployment option without confirming with the project's technical team.
• Attaching rules to the wrong change request step, so they either allow bad data too far downstream or block legitimate early-stage incomplete entries
• Confusing the material data model configuration (what fields/entities exist) with the process configuration (change request types and workflow).
• Duplicating checks already enforced by standard material master consistency logic, adding unnecessary processing overhead
• Expecting identical governance flexibility across every SAP deployment option without validating what is actually licensed and configured for the specific project.
• Failing to test rules against mass change requests, leading to unacceptable performance when many materials are processed together
• Hardcoding a single fixed approver instead of rule-based agent determination, creating a bottleneck when that person is unavailable.
• Not restricting validation rule scope to the correct business activity, causing rules intended only for changes to also block valid new material creation.
• Scoping a validation or derivation at the wrong organizational level, causing it to fire too broadly or not at all
• Treating MDG governance as optional overhead rather than explaining its business value (duplicate prevention, cross-functional validation) to stakeholders early in the project.
• Using a single change request type and workflow for both trivial edits and full material creation, causing unnecessary approval delays.

A strong production design connects functional or analytical semantics to integration boundaries, security, performance, transport/change control, observability, recovery and ownership. Trade-offs should be justified with evidence such as volume, latency, data quality, user behavior, operational SLA and downstream dependencies. Avoid treating a technically successful configuration or interface as complete until the business result is reconciled end to end.

A manufacturing company running S/4HANA had plant buyers creating materials directly in the operational system, resulting in duplicate materials with slightly different descriptions and inconsistent base units of measure across three plants. The project introduced MDG Material Governance so that every new material request went through a single change request process with a central data steward reviewing classification and units of measure before the material became active. This reduced duplicate material creation significantly and gave the data steward a single point of control instead of chasing corrections across plants after the fact.

During an S/4HANA MDG rollout, the project team initially configured a single change request type for all material creates and changes, routing everything through the same two-step approval. Business users complained that trivial text corrections took days to approve because they queued behind full material creation reviews. The team redesigned the process into a lightweight change request type for minor non-valuation edits with only automatic validation, and a full multi-step approval type for creation and valuation-relevant changes, which significantly reduced average cycle time for routine edits while keeping strict control over higher-risk changes.

A global manufacturing client governing materials centrally in MDG found that plant-level procurement teams were repeatedly creating materials with missing or inconsistent MRP controller assignments, causing downstream MRP run failures in S/4HANA. The project team introduced a validation rule scoped to the plant-specific MRP entity that blocked change request submission when the MRP controller field was blank for any plant marked as 'production relevant' in a custom classification. They also added a derivation that defaulted the MRP type based on the material type and plant combination for the majority case, only requiring manual entry for exceptions. This reduced MRP-related support tickets significantly and shortened average change request cycle time because specialists no longer had to manually chase missing MRP data during review.

• Allowing the same user role to both create and give final approval on a change request, violating segregation-of-duties expectations.
• Assuming a material is live in operational tables as soon as it is entered in the MDG UI, without realizing it stays inactive until the change request completes.
• Assuming the same rule configuration approach and depth of extensibility exists identically across on-premise, private cloud, and public cloud deployments
• Assuming workflow configuration flexibility is identical across every SAP deployment option without confirming with the project's technical team.
• Attaching rules to the wrong change request step, so they either allow bad data too far downstream or block legitimate early-stage incomplete entries
• Confusing the material data model configuration (what fields/entities exist) with the process configuration (change request types and workflow).
• Duplicating checks already enforced by standard material master consistency logic, adding unnecessary processing overhead
• Expecting identical governance flexibility across every SAP deployment option without validating what is actually licensed and configured for the specific project.
• Failing to test rules against mass change requests, leading to unacceptable performance when many materials are processed together
• Hardcoding a single fixed approver instead of rule-based agent determination, creating a bottleneck when that person is unavailable.
• Not restricting validation rule scope to the correct business activity, causing rules intended only for changes to also block valid new material creation.
• Scoping a validation or derivation at the wrong organizational level, causing it to fire too broadly or not at all
• Treating MDG governance as optional overhead rather than explaining its business value (duplicate prevention, cross-functional validation) to stakeholders early in the project.
• Using a single change request type and workflow for both trivial edits and full material creation, causing unnecessary approval delays.

• Always explain the active/inactive staging concept to business users early so they understand why changes are not instantly visible downstream.
• Avoid duplicating standard consistency checks already enforced elsewhere in the material master logic
• Confirm the specific deployment model's data model extensibility limits before promising business users custom fields or entities.
• Design at least two change request type tiers: lightweight for low-risk edits and full multi-step approval for creation or valuation-relevant changes.
• Document each rule's business justification and owning process area so future maintenance does not remove rules without understanding their purpose
• Document the full status lifecycle and who can act at each status to support audit and troubleshooting later.
• Document which material entities and views are in scope for governance versus which remain under direct maintenance, to avoid scope confusion.
• Enforce segregation of duties by ensuring requesters cannot also be final approvers on the same change request.
• Map business activities (create, change, mark for deletion) explicitly to the change request types your project will use before starting configuration.
• Run automatic validations before any human workflow step to protect approver time.
• Scope every rule as narrowly as necessary to the correct entity type and organizational level to avoid false positives or gaps
• Stage validations progressively across change request steps, allowing flexibility early and enforcing completeness before activation
• Test rules against single-material, multi-material, and mass change request scenarios before go-live
• Use rule-based agent determination keyed on material type, plant, or business unit instead of fixed named approvers.
• Verify the actual rule configuration and extensibility depth available in the target deployment (on-premise, private cloud, or public cloud) before finalizing design

Senior interviews should test whether the candidate can connect the individual lesson areas, diagnose cross-layer failures, explain trade-offs and design a supportable production operating model.

Interviewers commonly ask candidates to explain the difference between active and inactive data areas in MDG and why this separation exists. Be ready to explain the change request lifecycle in plain business terms, not just technical jargon, and to connect it to a concrete pain point like duplicate material prevention.

Expect scenario-based questions such as 'how would you design approval workflow for material creation versus a minor text change' or 'how do you prevent a single approver bottleneck.' Strong answers reference rule-based agent determination, differentiated change request types by risk level, and segregation-of-duties controls rather than a one-size-fits-all workflow.

Interviewers assess whether a candidate understands the difference between validation (blocking) and derivation (defaulting) rules, can explain how rule scope and change request step selection affect governance behavior, and can describe a real example of designing a rule tied to a specific business data quality problem rather than reciting generic rule engine theory. Be ready to discuss trade-offs between strict early validation versus staged validation across workflow steps.