We recently migrated our supply planning to SAP S/4HANA Cloud 2020 and experiencing significant MRP Live performance issues. Material requirements planning runs that completed in 45 minutes on-premise now take 2.5-3 hours in cloud environment.
Our setup includes 85,000 active materials across 12 plants with multi-level BOMs. We’re using MRP Live with HANA planning configuration, but haven’t optimized parallel processing settings yet. The planning delays are impacting our production schedules and causing bottlenecks in procurement.
I’ve checked basic HANA memory allocation and it seems adequate. Is there specific MRP Live optimization we should focus on? Has anyone dealt with similar performance degradation after cloud migration?
Based on your diagnostics showing BOM explosion and availability check bottlenecks, here’s a comprehensive optimization approach addressing all three focus areas:
MRP Live Optimization:
First, increase parallel processing threads to 12-16 for your material volume. Access this via transaction OMDU or directly in MRP Live configuration. Enable mass processing mode which batches materials by planning characteristics. Set up planning segmentation using material groups - run critical A-items separately from B/C items.
HANA Planning Configuration:
Ensure you’re leveraging HANA-optimized planning tables. Run transaction DB02 to verify your planning-relevant tables (MDKP, MDVM, MDTB) are on HANA column store. Enable HANA planning calculation engine by setting parameter MRP_HANA_OPTIMIZATION = ‘X’ in transaction RZ11. This activates push-down processing for BOM explosions directly to HANA layer.
For availability checks causing delays, implement ATP check scope reduction. Configure checking rule ‘B’ (reduced scope) instead of ‘A’ (full scope) for non-critical materials via transaction OVZG. This cuts availability calculation time by 60-70%.
Parallel Processing Enhancements:
Implement these specific settings:
Set MRP_PARALLEL_PLANTS = ‘X’ to enable plant-level parallelization
Configure planning file entries to group by material type using transaction MD20
Enable background job parallelization with 8-10 concurrent jobs for large planning runs
Use planning horizon reduction: 180 days for A-items, 90 days for B-items, 60 days for C-items
Implement net change planning (transaction MD02) for daily runs instead of regenerative planning. Reserve full regenerative runs (MD01) for weekend batch processing.
Finally, schedule regular planning file reorganization using transaction MDRE to prevent bloat. We’ve seen similar environments reduce MRP runtime from 3 hours to 55 minutes with these optimizations. Monitor via transaction /SAPAPO/AMON weekly to track improvements.
This draft is based on general SAP S/4HANA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
Check your MRP Live parameter profiles first. Default cloud settings often have conservative parallel processing limits. Navigate to transaction MD01N and review the processing mode - you probably need to enable parallel processing for planning runs.
Thanks for the pointer. I checked MD01N and parallel processing is enabled but set to only 4 threads. Given our material volume, this seems low. What’s the recommended thread count for 85K materials? Also, should I be looking at HANA-specific planning parameters beyond the standard MRP settings?
Beyond thread count, verify your planning horizon settings. Excessive planning horizons cause unnecessary calculations in MRP Live. We reduced ours from 365 to 180 days for fast-moving items and saw 40% improvement. Also check if you’re using planning time fence correctly - it prevents unnecessary replanning of near-term requirements. The HANA planning configuration should leverage column-store tables, but SAP usually handles this automatically in cloud deployments.
One often overlooked aspect is the MRP Live simulation mode vs. background processing. Are you running full regenerative planning each time? Consider switching to net change planning for daily runs and reserve regenerative for weekly cycles. This dramatically reduces processing scope. Also, segment your materials into ABC categories and apply different planning strategies - not everything needs the same processing intensity.
Have you analyzed the actual bottleneck using transaction /SAPAPO/AMON or the planning monitoring tools? Without proper diagnostics, you’re guessing. Check if the delay is in BOM explosion, availability checks, or lot-size calculations. Each requires different optimization approaches.
Good point about diagnostics. I ran /SAPAPO/AMON and found most time spent in availability check and BOM explosion phases. Planning horizon is indeed set to 365 days globally, which now seems excessive.