Process and Architecture Map: From Demand Signal to Capacity-Checked Supply Plan
A cross-cutting process and system architecture map showing how demand, MRP, capacity, and advanced planning components interact end-to-end, including integration points and where each child topic fits.
Explanation
This lesson builds the architecture-level mental map that ties together the child topics under Demand Management, MRP, Capacity and Advanced Planning. Rather than teaching configuration steps, it explains the runtime flow of data and decisions so that a consultant can reason about where a problem originates when something goes wrong in production support. The flow begins with demand capture. Independent requirements arrive either as planned independent requirements entered directly (forecast-driven planning) or generated from external demand sensing (statistical forecasting, or increasingly, integration with SAP Integrated Business Planning where deployed). These requirements are tied to a planning strategy on the material master, which determines how they interact with actual sales orders - whether consumption happens against the forecast, whether make-to-order segregates demand by sales order, or whether a mixed strategy blends both. This strategy choice is foundational and is covered in depth in dedicated child lessons on strategies and master data. Once independent and dependent requirements exist, MRP (executed via the MRP run, whether classic in ECC or MRP Live in S/4HANA) performs net requirements calculation per plant or MRP area: available stock, scheduled receipts (open purchase orders, existing planned orders, production orders) and safety stock are netted against gross requirements. Where a shortage exists, MRP creates a procurement proposal - planned order for in-house production, purchase requisition for external procurement - dated using backward or forward scheduling based on lead times from the routing (for in-house) or info records/source list (for external). For in-house production proposals, BOM explosion creates dependent requirements for components, cascading the same netting logic downward through the bill of material structure, potentially multiple levels deep. This is why MRP is normally run at low-level code order, processing the most deeply nested materials in later passes to ensure dependent requirements from higher levels have already been generated. Capacity enters the picture after supply elements exist. Each planned or production order carries an operation sequence from the routing, and each operation is assigned to a work center with defined capacity (shift patterns, available hours, efficiency factors). Capacity evaluation tools let planners view load against available capacity by work center, time bucket, typically identifying overload situations. Capacity leveling (manual or algorithm-assisted) allows shifting operations within their scheduling margin to smooth overloads - but classic MRP itself does not automatically enforce finite capacity; it is a subsequent, often manual or semi-automated, review step. This is a critical architectural distinction from PP/DS, where heuristics and optimizer runs can perform finite-capacity scheduling as an integrated part of the planning run itself, producing a schedule that already respects capacity constraints rather than requiring a separate leveling pass. Integration touchpoints radiate outward from this core flow: Materials Management for procurement proposal conversion to purchase orders, Quality Management for inspection-triggered stock restrictions affecting available quantity in MRP netting, Controlling for planned order costing previews, and Extended Warehouse Management or basic Warehouse Management for execution-level goods movement once orders are released. In S/4HANA, Predictive MRP allows simulation of MRP outcomes without committing changes to the live plan, useful for what-if analysis before actual execution - a capability with no direct classic ECC equivalent. For production support, understanding this architecture means that when a planner reports missing or incorrect planned orders, the diagnostic path should move from strategy/master data to MRP execution logs to BOM/routing validity to capacity constraints - not jump straight to assuming a bug. This lesson does not replace the detailed troubleshooting content in child topics but equips learners with the sequence of investigation.
Real project scenario
During hypercare after a S/4HANA go-live, a planning team escalated that certain finished goods were not generating planned orders despite clear demand. Root cause analysis, guided by the architecture map, revealed the issue was not MRP logic but a BOM validity date that had expired the week before cutover, meaning MRP could not explode dependent requirements even though the finished good's own demand was correctly netted. Tracing the issue required checking each layer in sequence - strategy, demand, MRP netting, BOM validity - rather than assuming the MRP run itself was defective.
Common mistakes
• Assuming a missing planned order is always an MRP configuration bug rather than checking upstream master data validity first • Treating capacity evaluation as automatically enforced by MRP rather than understanding it as a separate review or leveling activity • Overlooking low-level code sequencing when troubleshooting multi-level BOM explosion inconsistencies • Confusing Predictive MRP simulation results with committed planning data changes • Failing to identify which deployment (classic MRP, MRP Live, PP/DS) is actually running before diagnosing scheduling or capacity behavior
Best practices
• Diagnose planning issues by moving systematically through the layers: demand strategy, master data validity, MRP netting, capacity • Document low-level codes and BOM structures when troubleshooting multi-level shortages • Use Predictive MRP or simulation tools where available before committing disruptive changes to a live plan • Clearly identify which planning engine (classic MRP, MRP Live, PP/DS) is active before making behavioral assumptions • Maintain close coordination between master data owners and planning teams so capacity and BOM/routing changes are reflected before the next planning run
Interview angle
Interview questions at this level often probe whether a candidate can trace an end-to-end scenario: for example, describing what happens from the moment a planned independent requirement is created through to a capacity overload alert, naming each system component involved. Strong candidates explicitly note that classic MRP does not enforce finite capacity and can contrast that with PP/DS heuristics or optimizer-based finite scheduling, showing they understand the architectural boundary rather than treating all planning tools as interchangeable.