Time-Series-Based Supply Optimizer: notes on performance

As stated in blog ”Supply Optimizer: the Mathematics behind” the optimizer transforms the business scenario into a mathematical model representation – a mixed-integer linear program (MILP). This MILP is then solved via one of the best solvers available on the market. As the performance of the underlying algorithms strongly depends on the model structure and constraints, it is nearly impossible to make any predictions on the runtimes. Since the model depends on the concrete supply scenario and the used features, it is essential to start early testing on a realistic data set to avoid any larger remodeling at late stages in a project.

This article shows the typical performance influencing aspects and possible mitigation options for the supply optimizer. We present some performance information from our customer base and close with a comparison to APO SNP Optimization and explain how your scenario can help to improve the optimizer performance.

Performance factors

The main factors are the size of the model, the used features and possible numerical difficulties:

(1) The size of a scenario is mainly defined by:

• the number of valid customer and product-combinations
• the number of valid location and product-combinations
• the number of periods in the planning horizon

For each period and location/product-combination one variable is required to represent the inventory level.
Additional variables represent the sourcing decisions, for example the transported or produced amounts.

Possible mitigation options: (4) + (5) + (6) in next section

(2) Some features require discrete decision variables which make the problem a lot harder to solve. They are used for these features:

• minimum lot-sizes
• incremental lot-sizes
• fixed costs

Especially incremental lot-sizes have a high impact as they require integer variables, for minimum lot-sizes and fixed costs ‘only’ binary variables are used.

Possible mitigation options: (1) + (5) + (6) + (7) in next section

(3) Some features require many additional variables.
The most prominent here is fair-share distribution, as there is one variable required for each segment for all the corresponding customer/products resp. location/products.
Late demand delivery is another candidate, as for each possible period of each demand that may deliver late an additional variable is required.

Possible mitigation options: (4) + (5) in next section

(4) Some features complicate the model by introducing constraints which cover many variables. Typical examples are widely used resources and aggregated constraints.

(5) Numerical difficulties arise when the range of related variables is very high and/or the range in the objective function is very high. Root cause is the floating-point representation: it has only a limited precision which yield in numeric issues due to the imposed inaccuracies. Often the solver requires a lot of time to cope with such inaccuracies and sometimes they can be seen in the results too.
For example, if some products are measured in kilograms and others in tons large coefficients can arise in production sources.
The range in the objective function is primarily defined via the costs. We see often very small values like 0.001 and in addition large values like 999999. With such a range the decisions based on the small coefficients have no significant relevance in the objective function and may therefore yield to unwanted results.
Large incremental lot-sizes have also a bad impact on the numerics as related constraint need to be scaled accordingly.

Possible mitigation options: (2) + (3) in next section

Best practices

If you encounter performance issues, typically these changes help the most:

(1) Reduce the discrete decisions as far as possible. The easiest way for this is to use the discretization horizons to limit them to the first n periods.
Configuration details can be found in TS-Based Supply Optimizer => Optimizer Parameters => Discretization.

(2) Limit the numeric ranges:

• Keep the cost coefficient range as low as possible, especially don’t use very high cost-values like 99999999. For decisions the optimizer should adhere with a very high priority, it is recommended to use a value based on the highest cost in the model. E.g. if the highest costs are 100 for production, use 10 * 100 = 1000 for such highly rated decisions.
• avoid high global cost factors in the optimizer profile
• avoid high incremental lot-sizes

(3) Avoid minimum and/or adjusted values that can’t be satisfied. They can make up a huge portion in the objective function and cause numerical difficulties.

(4) Reduce the model size as much as possible. Typical options are:

• restrict the planning horizon
• Use subnetworks to optimize possible independent or just loosely coupled parts separately. For example, different factories can often be planned individually.
• restrict the number of fair-share segments as far as possible
• avoid late delivery over many periods
• avoid periods of supply, and maximum coverage over many periods

(5) Use time aggregation. Especially if planning happens on daily periods.

(6) Use product decomposition. See Note 3099058 – Getting started with product decomposition for more information on how to use this feature.

(7) Use local optimization. See also Note 3250159 – Local optimization for discrete problems for more information.

(8) Use the optimization expert consulting service. See SAP note 2427153 for more information.

Performance numbers

The following table gives some examples from our customer base.

Clearly the optimization runtimes don’t necessarily depend on the model size, typically the number of discrete decisions and numerical challenges are the more impacting factors. Due to the various influencing factors it is very hard to make any estimations about performance without a proof of concept.

Comparison to APO SNP Optimization

We are often asked how the performance can be compared to the optimizer in APO SNP. In general, they perform relatively similar, in fact they share large coding parts. But due to different models and available features there are some differences. Some performance features of the SNP optimizer like decomposition techniques aren’t yet available in IBP. Due to the SAP HANA usage in IBP the necessary pre- and post-processing steps are usually a lot faster and the optimizer always has the latest performance improvements from us and our solver-provider.

Final remarks

We are working closely with the solver-provider to tune and improve the performance on our typical models. Additionally we constantly seek performance improvements via model refinements and/or additional pre-solving steps. For this we are depending on a large set of typical scenarios. Therefore customers who are willing to let us use their models in an anonymized way are always very welcome! We will use these data sets for regular performance tests. This ensures also an early detection in case of performance degradations on specific scenarios. Please open an incident on component SCM-IBP-SUP-OPT to give us your consent and access to the necessary data.