After implementing both approaches across multiple organizations, I can offer some comprehensive insights on the centralized vs distributed debate, governance requirements, and user adoption challenges.
Centralized vs Distributed Change Control:
The fundamental tension is between control and agility. Centralized approaches using a single module (typically lifecycle management) provide unified visibility and consistent governance, but can become bottlenecks. Distributed approaches using both modules offer flexibility but risk creating silos and inconsistent practices.
The optimal solution depends on your product portfolio complexity and organizational maturity. If you have clear product lifecycle stages with distinct characteristics (R&D vs production vs legacy support), a distributed model with lifecycle management for NPI and sustainment management for mature products makes sense. However, if your products frequently transition between states or you have hybrid scenarios, a centralized model with intelligent routing is more maintainable.
Key success factor: Define explicit transition criteria. In our most successful implementation, products automatically moved from lifecycle to sustainment management when they achieved ‘production release’ status, triggering different workflow templates and approval chains. This eliminated ambiguity about which process to follow.
Governance and Audit Requirements:
Regulatory compliance drives architecture more than most organizations initially recognize. Medical device, aerospace, and automotive companies need complete traceability regardless of product maturity. You can’t have ‘lightweight’ processes for NPI if those products might eventually need regulatory submission.
The solution is layered governance: core audit requirements (change documentation, approval evidence, effectivity tracking) apply universally, but approval depth varies. Configure sustainment management as your audit system of record, but create streamlined approval paths for pre-production changes. Use workflow agents and organizational assignments to automatically route based on product classification and change impact.
Critical insight: Audit requirements focus on ‘what changed and who approved it,’ not ‘how many people approved it.’ You can have fast, compliant processes if you properly classify changes and assign appropriate authority levels. We reduced average approval time from 8 days to 2 days while improving audit scores by implementing risk-based routing.
User Adoption and Training:
This is where most implementations fail. Technical configuration is only 30% of success - the other 70% is organizational change management and training.
Role-based training is essential but insufficient. You need process-based training that shows users their complete workflow from start to finish. Engineers don’t care about ‘SAP PLM change management capabilities’ - they care about ‘how do I get my design change approved quickly.’
Our most effective approach: Create persona-based journey maps showing exactly what each role does in common scenarios. For example, ‘NPI Mechanical Engineer releasing first article’ vs ‘Sustaining Engineer implementing field fix’ vs ‘Change Coordinator managing regulatory submission.’ Each persona gets targeted training, custom transaction variants, and specific quick reference guides.
Implement progressive disclosure: Show users only the fields and options relevant to their scenario. Use transaction variants (SHD0) to hide complexity and create role-specific entry points. This dramatically improves adoption because the system appears simpler even though full capability exists underneath.
Practical Recommendation:
For your SAP PLM 2021 environment with mixed NPI and sustaining needs, I recommend a unified technical platform (sustainment management as the system of record) with differentiated process execution:
- Use material lifecycle status to automatically determine workflow complexity
- Implement fast-track approval paths for pre-production changes with automatic escalation for high-risk items
- Create role-specific training and interfaces so each user community sees ‘their’ process
- Establish clear governance policies that satisfy audit requirements without bureaucracy
- Monitor adoption metrics and iterate - if people are bypassing the system, your process is wrong regardless of how ‘correct’ it is technically
The goal isn’t choosing between centralized or distributed - it’s creating a flexible governance framework that provides appropriate control without impeding business velocity. Users should experience simplicity while auditors see comprehensive traceability.