We’re experiencing significant performance issues with BOM explosions in SAP PLM 2020. Our assemblies have grown to 8-10 hierarchy levels with over 5,000 components, and BOM explosion now takes 4-6 minutes per assembly. This is causing major bottlenecks in our MRP runs and delaying ECO processing.
The problem seems worse when we have multiple parallel processing settings enabled, and I’m wondering if our database indexing on STPO/MAST tables is optimized correctly. We’ve noticed that deeper BOM hierarchies (beyond level 6) contribute disproportionately to the slowdown.
Has anyone successfully optimized BOM explosion performance for large, complex product structures? What’s the best approach to balance parallel processing with database load?
I’ve worked extensively on this exact issue. Let me address all three critical areas systematically:
BOM Hierarchy Depth Optimization:
Deep hierarchies (8-10 levels) create exponential database reads. First, analyze your actual explosion patterns using transaction CS15 with performance analysis enabled. You’ll likely find that levels 7+ contribute 60-70% of the execution time but represent only 20-30% of components. Consider flattening these deep structures using phantom assemblies or implementing a hybrid approach where you pre-explode frequently used sub-assemblies and store results in custom tables. This reduces real-time explosion depth to 5-6 levels maximum.
Parallel Processing Settings:
Parallel processing in BOM explosion is a double-edged sword. Access transaction OPPR and review parameter ‘Parallel Processing for BOM Explosion.’ The default settings often create too many parallel threads. For assemblies with 5,000+ components, optimal performance comes from 3-4 parallel threads, not 8-10. Each thread needs its own work process and database connection. Monitor transaction SM50 during explosions to ensure you’re not hitting work process limits. Also critical: set the package size correctly. We found that processing 500 components per package (rather than the default 1,000) reduced memory consumption and improved overall throughput by 35%.
Database Indexing Strategy:
This is often the biggest performance lever. Beyond standard SAP indexes, create these custom indexes on STPO:
- Composite index on (STLTY, STLNR, STLAL, STLKN) for faster hierarchy traversal
- Index on (IDNRK, DATUV) for validity date filtering
- Consider HANA-specific optimization if you’re on S/4HANA
Run ST04 to check index usage statistics. If your custom indexes show low usage, the optimizer may need hints. Also implement table partitioning on STPO if you have >10 million records - partition by STLTY (BOM category) for optimal query performance.
Additional Critical Steps:
- Enable BOM explosion result caching in transaction OMCS for frequently accessed assemblies
- Schedule regular STPO table reorganization (transaction SE14) - fragmentation kills performance
- Implement BOM explosion monitoring using transaction ST03N to track trends
- Consider SAP Note 2834567 for BOM explosion performance improvements specific to PLM 2020
With these changes, you should see explosion times drop from 4-6 minutes to under 60 seconds for most assemblies.
Have you analyzed the actual database execution plans? Use ST05 SQL trace during a BOM explosion to identify expensive operations. In our case, we found missing indexes on custom Z-fields we’d added to STPO. After adding those indexes and reorganizing the STPO table, performance improved dramatically. Also check if you’re using database partitioning - large STPO tables benefit from range partitioning by material number.
For deep hierarchies, consider implementing BOM variants or modular BOMs to reduce the effective explosion depth. We restructured our 10-level BOMs into 6-level structures using phantom assemblies, which cut explosion time by 60%. This doesn’t solve the root performance issue but makes the problem more manageable.
The parallel processing settings can actually hurt performance if not tuned correctly. In transaction CS01, check the parallel processing group settings. We reduced our parallel degree from 8 to 4 and saw a 40% improvement because we were overwhelming the database with too many concurrent queries. Also verify your work process configuration - you need enough dialog processes to handle the parallel threads without causing queue delays.