Best practices for segregation of duties in BOM management: balancing security and efficiency

PLM SAP PLM
, , , , , , , ,
1

I’m interested in hearing how other organizations handle segregation of duties (SoD) in BOM management within SAP PLM 2021. We’re redesigning our authorization concept and facing the classic tension between security requirements and operational efficiency.

Our audit team insists on strict separation: BOM creators cannot approve their own BOMs, and approvers cannot create BOMs. This makes sense from a control perspective, but it’s creating significant bottlenecks in our engineering workflow. Small changes that previously took hours now take days because we’re waiting for approvers from different departments.

We’ve implemented a workflow-based approval process, but it’s adding overhead. Some teams are pushing back, arguing that the risk level doesn’t justify the delays for minor BOM updates. I’d love to hear how others have balanced these competing priorities. Have you implemented risk-based SoD policies where different rules apply based on BOM value or complexity? What role design patterns work well? How do you handle emergency changes when the normal approval chain isn’t available?

system 2

Workflow-induced latency in BOM approval chains is a well-documented pain point when SoD controls are applied uniformly regardless of change risk.

Diagnostic Steps — Identify Where the Bottleneck Actually Lives

  1. Pull workflow instance runtimes from SWI5 or SWI6. Separate time-in-queue (waiting for human action) from processing time. Most organizations find >85% of elapsed time is queue wait, not system overhead.
  2. In CS02/CS03, review the BOM change master (ECM) linkage. Determine what percentage of changes are ECO-bound vs. direct BOM edits — these have different authorization paths and different SoD exposure.
  3. Check PFCG role assignments for your approver pool. Thin approver groups (1–2 people per BOM plant/type combination) are usually the structural bottleneck, not the policy itself.
  4. Run a SU10/SU53 analysis on declined or timed-out workflows to distinguish authorization failures from routing misconfigurations.
  5. Audit PLM Document Management linkage — if DMS document release is also gated, you may have dual-approval chains firing serially that could run in parallel.

Risk-Based SoD Design Patterns

The most effective pattern is tiered authorization by change classification, typically:

  • Tier 1 (cosmetic/non-functional): Description, unit of measure text, reference designators with no quantity impact — single-role self-approval with audit log. Authorization object C_STUE_BER with restricted activity scope (verify in your version).
  • Tier 2 (functional, low-impact): Quantity adjustments within tolerance, component substitutions on approved AVL — peer review, same department approver permitted.
  • Tier 3 (structural/safety-critical): New components, BOM level additions, changes to items with MARC MRP relevance — strict cross-functional SoD enforcement.

Classification can be driven via variant configuration attributes or a Z-table lookup triggered in the workflow start condition.

Emergency Change Handling

Implement a “break-glass” role — a time-limited authorization profile activated via SU01 with automatic expiry and mandatory post-hoc review. Log every activation in a dedicated audit table. This satisfies auditors without blocking production.

Monitoring / Verification Check

Schedule a weekly SU25/SUIM role comparison report and cross-reference against workflow completion SLAs from SWI5. Target metric: Tier 1/2 changes closed within 4 business hours. If Tier 3 average exceeds 2 business days, re-examine approver pool sizing before tightening policy further.

This draft is based on general SAP PLM knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

We implemented a tiered approach based on BOM impact. Class A BOMs (high value, safety critical) require strict SoD with dual approval. Class B and C BOMs allow same-day approval by designated deputies within the same department. This reduced our approval cycle time by 60% while maintaining control over critical items. The key is having clear classification criteria that audit accepts.

4

Risk-based SoD is definitely the way to go. We use material type and BOM usage to determine approval paths. Engineering BOMs for prototypes have relaxed controls, while manufacturing BOMs for production require strict separation. The classification is automated based on material master data, so there’s no manual intervention. Workflow routes accordingly. We also implemented an emergency approval process where two managers can jointly approve outside normal channels, but these trigger automatic audit reviews.

5

One pattern that works well is the “maker-checker” model with time-based flexibility. BOM creators can make changes, but they don’t become effective until a checker reviews and releases them. For low-risk changes, we have an auto-release after 24 hours if no issues are flagged. This gives oversight without creating bottlenecks. High-risk changes require explicit approval. The key is comprehensive audit logging so you can prove the control is working even when approval is automated.

6

Workflow automation is critical for making SoD practical. We built escalation logic into our approval workflow - if an approver doesn’t respond within defined SLAs, it automatically escalates to their deputy or manager. We also implemented batch approval capabilities where approvers can review and approve multiple similar low-risk BOMs at once rather than individually. This reduced approval time significantly. The workflow tracks everything for audit purposes, including escalations and batch approvals.

7

From an operational perspective, the biggest challenge is having enough trained approvers. We cross-trained engineers so each team has multiple people who can approve BOMs. This prevents bottlenecks when someone is on vacation or sick. We also created approval deputies in the system who automatically inherit approval authority during absences. The deputy assignment is managed through organizational management in SAP, so it’s always current.

8

Don’t forget about audit logging as a compensating control. Even with streamlined SoD, you need comprehensive logs. We track every BOM change with user ID, timestamp, change type, and approval status. These logs feed into our continuous monitoring system that flags suspicious patterns - like the same person creating and approving multiple high-value BOMs through emergency processes. The monitoring gives us confidence to allow more flexible approval paths.

9

Thank you all for the excellent insights. Let me synthesize what I’m hearing into a comprehensive approach:

SoD Policy Design: The consensus is clear - one-size-fits-all SoD is counterproductive. A risk-based approach balances control and efficiency. Here’s a framework that emerged from this discussion:

Tier 1 (High Risk): Safety-critical BOMs, high-value assemblies (>$100K), BOMs for regulated products. Require strict maker-checker separation with dual approval from different departments. No exceptions, full audit trail mandatory.

Tier 2 (Medium Risk): Standard production BOMs, moderate value assemblies. Single approver from different department than creator. Emergency approval allowed with post-approval review within 48 hours.

Tier 3 (Low Risk): Prototype BOMs, spare parts, low-value items. Automated approval after 24-hour review period if no flags raised. Same-department approval permitted with audit logging.

The classification should be automated based on material type, BOM usage, estimated value, and regulatory flags in the material master. This eliminates subjective decisions about which path to follow.

Workflow Automation: Manual approval processes create bottlenecks. Implement intelligent workflow with these capabilities:

  • SLA-based escalation (24 hours to primary approver, then auto-escalate to deputy)
  • Batch approval interface for reviewing multiple similar low-risk changes
  • Mobile approval capability so approvers aren’t tied to their desks
  • Out-of-office handling with automatic deputy assignment from organizational management
  • Emergency approval path requiring two concurrent approvals from management level

The workflow should be configurable by BOM tier without code changes. Use SAP Business Workflow with custom approval steps based on BOM classification.

Audit Logging: Comprehensive logging serves as a compensating control that allows more flexible approval processes. Log to custom table ZBOM_AUDIT_LOG:

  • All BOM changes (create, modify, delete) with before/after values
  • Approval actions (approved, rejected, escalated) with timestamps
  • Emergency approval usage with business justification
  • Auto-approval events for low-risk changes
  • SoD policy exceptions with approval chain

Implement continuous monitoring that flags patterns like:

  • Same user creating and approving multiple BOMs through emergency process
  • Abnormal volume of emergency approvals from specific users
  • BOM changes outside normal business hours
  • Approval SLA violations trending upward

These logs satisfy audit requirements while supporting a more flexible operational model. The key insight is that SoD isn’t just about preventing individual unauthorized actions - it’s about creating a system of checks and balances that includes preventive controls (separation), detective controls (logging), and corrective controls (reviews).

A mature SoD program uses all three layers rather than relying solely on rigid separation that creates operational friction. The goal is appropriate control, not maximum control. Risk-based tiering, intelligent workflow automation, and comprehensive audit logging together achieve that balance.