Multi-org vs single-org configuration management for demand planning: pros, cons, and real-world tradeoffs

We’re designing our demand planning implementation and debating between multi-org versus single-org configuration management approaches. Our company has three business units with distinct product lines but shared manufacturing facilities. The multi-org approach would give each BU independent demand planning processes with their own item masters and forecasting hierarchies, providing better data visibility control. However, single-org configuration with segmented access might simplify master data management and reduce integration complexity. I’m interested in hearing experiences from teams who’ve implemented either approach - what were the key trade-offs you encountered with org structure configuration and access control policies? How did your choice impact forecast collaboration and planning performance across business units?

The shared manufacturing facilities aspect is crucial to your decision. If your BUs frequently share capacity or have product transfers, single-org makes integration much easier. Multi-org requires you to set up inter-org transfers and maintain separate supply plans that then need consolidation. We learned this the hard way after going multi-org - the overhead of managing cross-org planning data became significant.

Don’t underestimate the access control complexity in single-org. Yes, you can segment data using planning dimensions and role-based security, but it requires very careful configuration of data security policies. Every demand planning object - forecasts, planning profiles, dimensions - needs explicit security rules. We’ve seen cases where a misconfigured policy exposed one BU’s forecast data to another. Multi-org gives you inherent data isolation without relying on security configuration.

From a master data management perspective, consider your item numbering strategy. If your three BUs use completely different item numbering schemes and have no overlap in product portfolios, multi-org makes sense. But if there’s any chance of product sharing or consolidated reporting needs, single-org with item categories and planning dimensions to segment by BU is cleaner. The org structure configuration decision also impacts your upgrade and patching strategy - single-org means simpler testing cycles.