Configuring and Executing an LTP Planning Scenario: Versions, Evaluation, and Transfer

Explanation

Executing Long-Term Planning in a real project involves several coordinated steps that a PP consultant must configure and run correctly to produce trustworthy results. The process generally follows this sequence: create a simulative independent requirements version, populate it with demand quantities, define a planning scenario that references that version along with the relevant plants and MRP areas, execute the LTP planning run, evaluate the results (material requirements and capacity load), and optionally transfer selected outcomes into operative planning. The first step is creating the simulative version of planned independent requirements. This is functionally similar to maintaining operative PIRs, but the planner selects a simulative version number (a version other than the operative version, commonly 00) so the demand exists in isolation. This version can be populated manually, copied from an existing operative or another simulative version and then adjusted, or loaded from an external planning tool such as a spreadsheet-based S&OP process. It's important to scope the version to only the materials and periods relevant to the scenario being tested, since overly broad versions increase processing time and complicate result interpretation. Next, a long-term planning scenario is created. The scenario acts as a container defining which simulative requirements version drives the run, which plants and MRP areas are in scope, the validity period, and planning parameters such as whether BOM/routing alternatives should follow standard selection rules or specific overrides for the scenario. Multiple scenarios can exist simultaneously, each isolated from the others, which allows planners to compare, for example, an 'optimistic growth' scenario against a 'conservative growth' scenario side by side. Once the scenario is defined, the planner executes the LTP run. Functionally this behaves like an MRP run: it explodes BOMs, applies routings, calculates dependent requirements down through the BOM structure, and creates simulative planned orders and purchase requisitions confined to the scenario. Unlike operative MRP, no actual procurement documents, capacity reservations, or shop floor activities result from this run; everything remains simulative and scoped to the scenario's own data set. Evaluation is where the real business value emerges. Capacity evaluation reports show projected load at work centers or resources over the planning horizon, based on the routing operations attached to the simulative planned orders. Planners compare this load against available capacity to identify bottlenecks, underutilized resources, or the need for overtime, subcontracting, or capital investment. Material requirements evaluation shows whether raw material or component sourcing can support the simulated demand, which is valuable input for procurement negotiations and safety stock planning discussions. A critical decision point is whether and how to transfer LTP results into operative planning. In some implementations, only the demand plan itself (a refined simulative PIR version) is transferred into the operative independent requirements version once business stakeholders approve the scenario, effectively updating the operative sales and operations plan. In other cases, no direct transfer occurs at all; LTP is used purely as an analytical exercise, and any resulting business decisions (capacity investment, headcount changes, sourcing negotiations) are executed manually outside the SAP transactional flow. Consultants must clarify this transfer strategy with business stakeholders during design, because building automated transfer logic without a clear approval and governance process can introduce operative planning changes that were never properly vetted. On S/4HANA, the underlying LTP concepts (simulative versions, planning scenarios, capacity evaluation) remain functionally similar to ECC, though the reporting and evaluation experience may leverage embedded analytics and Fiori-based capacity and material views where available, offering faster aggregation over large data volumes due to the HANA architecture. Organizations using SAP IBP or other cloud planning tools for demand and S&OP may reduce reliance on classic LTP altogether, using it selectively for detailed capacity confirmation rather than as the primary demand planning simulation tool. Consultants should confirm with the specific project which planning tools own which parts of this process to avoid duplicate or conflicting simulative planning efforts.

Code example

Representative LTP process outline (functional steps, not exact transaction codes for this project's SAP version - confirm actual navigation with your project's configuration): 1. Create/maintain simulative independent requirements version (e.g., version 'LT1') with forecast quantities by material, plant, and period.2. Create a long-term planning scenario referencing version 'LT1', scoped plants/MRP areas, and the validity horizon.3. Execute the LTP planning run for the scenario (BOM/routing explosion produces simulative planned orders and purchase requisitions confined to the scenario).4. Evaluate capacity load per work center/resource against available capacity for the horizon.5. Evaluate material requirements/coverage for critical components against the simulated demand.6. If approved by stakeholders, transfer refined demand quantities from the simulative version into the operative independent requirements version (a deliberate, controlled step - not automatic).7. Archive or retain the scenario for audit/comparison against future planning cycles.

Real project scenario

During an annual budgeting cycle, a consumer goods manufacturer needed to compare three demand scenarios (base, optimistic, pessimistic) against finite capacity at a bottleneck packaging line. The PP consultant built three separate simulative requirements versions and three corresponding LTP scenarios, ran each independently, and produced capacity evaluation reports for the operations leadership team. After review, leadership approved the base scenario's demand numbers, and the consultant transferred that simulative version's quantities into the operative PIR version ahead of the new fiscal year, giving operative MRP an updated, vetted demand baseline without ever exposing procurement or production to the untested optimistic or pessimistic scenarios.

Common mistakes

• Scoping a planning scenario too broadly (all plants, all materials) which dramatically increases run time and makes bottleneck identification harder. • Forgetting to align the scenario's validity period with the actual business planning horizon, producing results that don't match the decision timeframe stakeholders care about. • Transferring simulative demand into operative independent requirements without a formal business approval step, effectively letting an unvetted scenario drive real procurement and production. • Ignoring routing and work center master data changes that occurred after the scenario was built, causing evaluation results to reflect outdated capacity assumptions. • Failing to document which scenario version was ultimately approved, causing confusion in later audits or repeat planning cycles.

Best practices

• Scope each LTP scenario as narrowly as possible to the plants, MRP areas, and materials actually relevant to the business question being answered. • Keep a naming convention for simulative versions and scenarios that reflects their business purpose (e.g., growth case, conservative case, capacity study) for traceability. • Require explicit stakeholder sign-off before transferring any simulative demand into operative independent requirements. • Refresh routing and work center master data checks before major LTP runs feeding executive decisions, since stale master data undermines credibility of results. • Retain historical scenarios for comparison across planning cycles to support trend analysis and governance audits.

Interview angle

Interview questions at this level often probe whether a candidate can describe the practical sequence of setting up and running an LTP scenario, and critically, how results get (or intentionally do not get) transferred into operative planning. Strong candidates emphasize the deliberate, governed nature of any transfer step and can explain the difference between using LTP purely for capacity/material analysis versus using it to refresh the operative demand plan.