Understanding Telescopic Planning and Other Performance Considerations in SAP IBP Time Series

Objective

After completing this lesson, you will be able to telescopic Planning and Other Performance Considerations.

Telescopic Planning and Other Performance Considerations

The figure shows the adoption rules for Telescoping Planning.

On average, it speeds up optimizer planning by 70% less time, when you consider running for a year with mixed time buckets.

Some features are deactivated for performance reasons - trying to get to a lower time bucket (day) for precision in an aggregated time bucket (week) could offset any gains in performance improvement.

Better planning results can be expected towards the end of a long planning horizon, as there is not often much runway for a smoother production plan

The figure shows the use cases for Telescoping Planning and their description based on pros and cons..

There are many variations - the figure, Telescopic Planning Use Cases, shows some common ones.

Regardless of the modeling approach, there can be issues with aggregation and disaggregation. Oversimplifying data maintenance at the highest time bucket (such as month) could introduce discrepancies and deviations with planned results. This is true if you maintain values at higher buckets, disaggregate to plan at lower buckets, but once again aggregate to line up with the maintenance time level of month.

Careful design and additional configuration can mitigate many issues and ensure that tactical planning and operational planning can coexist.

The figure shows the Telescoping Planning Release of Demand from Monthly to Weekly based on a graphical example.

If the planning time buckets are in weeks and months, technical week is used internally by SAP IBP to split the calendar week into technical weeks, so that monthly aggregation is possible for calendar months.

If the demands are forecasted and collaborated at monthly levels, this can pose challenges later to align planned supply in similar fashion - for example, CW9 is made of TW9a and TW9b. Based on Feb and March values, these technical weeks are populated by disaggregating the monthly demand by the number of days in month.

Demand in CW9 = demand in TW9a + demand in TW9b = 2069 + 323 = 2392.

The average/day would be 2392 / 7 = 341.71

Any supplies planned for the CW9 of 2392 after optimizer plan would be split into the technical weeks based on number of days, that is:

TW9a supply = 341.71 x 6 = 2050.28 (less than demand of 2069)

TW9b supply = 341.71 (more than demand of 323)

To resolve such inconsistencies with smaller differences, it would be better to sum up the week, disaggregate by number of days in the week and adjust the monthly demand itself. This approach may be treated similar to when demand needs to be rounded to pallets or some rounding values.

The figure describes the Key Factors Affecting Run Times and Solution Quality for the Optimizer Performance.

Optimizer performance is a key consideration in modeling and stabilizing the solution to produce consistent planning results within the planning windows available. See also following blog on optimizer performance: https://blogs.sap.com/2018/06/08/time-series-based-supply-optimizer-notes-on-performance/

It is a critical measurement for operational planning processes, as the time bucket can be daily, in which case planners would need to review and publish the results in matter of hours for execution on the same day.

The figures shows an example to verify Optimization Problem Inputs.

Many advances in technology - both hardware and software - make it possible to improve performances. However, if you are dealing with large networks, special attention is necessary to get an acceptable solution gap in reasonable time.

The figure shows and describes the Approaches for Optimizer Parallelization.

Using a sub-network to segment a problem into smaller problems is a feasible approach; for example, plant.

When there are common constraints across sub-networks, this approach can become a bit cumbersome or impossible.

Product decomposition is a new technique that is available to customers for large and complex networks. It requires involvement with SAP expertise and services for modeling.

The figure shows an overview for structuring planning areas and version. Using different versions or planning areas enables concurrent planning processes not to impact each other. Although they may use common data models and sources of information, the granularity and timing would differ.

Planning processes have different timelines from start of an activity to end of that planning process and generating the desired planning results or outputs. This can often involve simulations, internal collaboration crossing teams across planning and involving multiple stakeholders.

Using different versions or planning areas enables concurrent planning processes not to impact each other. Although they may use common data models and sources of information, the granularity and timing would differ.

The figure shows and describes additional parameters for Planning Controls or Telescopic Planning enablement.

In addition to telescopic planning you can also try other performance improvement measures like Product Decomposition and Local Optimization of Discrete Problems. Both can be enabled in the Expert Settings of the S&OP optimizer profile. Product Decomposition tries to separate the optimizer problem into separate sub-problems and Local Optimization of Discrete Problems uses a Rounding Heuristic in combination with the optimizer.