SNP Optimizer - Long runtime in solution calculation

[Former Member]

Hi guys

We are having problems with the SNP optimizer. Itu2019s taking long runtime in solution calculation (more than 15 hours). We are running with:

Model information:

u2022 4500 product/location.

u2022 7 production plants

u2022 9 DCs

SNP optimization profile:

u2022 Discrete optimization method.

u2022 Production capacity.

u2022 Handling capacity.

u2022 Transportation capacity.

u2022 Integral PPM  90 Days

u2022 Min Transportation Lot size  365 days

u2022 Integral transportation lots size  365 Days

u2022 Integral means of transport  365 days

Please someone let me know some tips to improve the performance of the SNP optimizer

Regards

David

[Former Member · Accepted solution]

That's a tough question. Many of the performance tweaks are based upon experience and knowing how manipulating certain values affect the results.

Ken Snyder

[Former Member · Accepted solution]

Hi Ken

One of the things that we found out, it´s that the suppliers could be causing the long runtime, because most has rounding and minimum lot size values. but i think this isn´t the first time that someone is using suppliers to model a minimum lot size for procurement (i´m taking about external procurement).

please let me know is you have more information about what can cause the long runtime.

Regards

David

[Former Member · Accepted solution]

Hi David,

For a planning scenario it is a good idea to use only the discrete options that are needed. A rule of thumb is that more active discrete options in more buckets make it harder to find a good solution or even an optimal solution. That means if it isn't necessary to have all buckets discrete, don't do it. If your planning scenario doesn't need all discretization options listed above, don't activate all. Run optimizer with different descrete constrains and check the solution as well as performance by keeping some bench mark and then finalize the best method (Constaints to be select) to follow.

Please Check the consulting Note: 454433 and also chech note: 1039508, 1329597

Regards,

Kishore Reddy.

[Former Member · Accepted solution]

Hi David,

As mentioned in the other message, please try the following points:

1. Split your optimiser run in small independant run

2. Check the decomposition methods

3. Define a maximum duration that will give you a close to optimal solution, within a reasonable timefram

4. contact SAP optimiser team to fine tune your optimiser settings (they will help with othe rpoints too)

I actually forgot to mention, but other did: try to keep the discete horizon as small as possible! what is required for short term might not be for longer term, and you can save a lot here.

Thanks and Regard

Julien

[Former Member]

David,

As with any calculation process it might be simply a matter of floating point (small -but not too small - changes can cause huge % variations in values). Most algorithms have problems handling this type of problem.

Translating this to real-life application, you might have two (or more) conditions on your optimisation process that 'contradicts' each other causing the floating point issue.

My suggestion is to try break the large optimisation problem into smaller ones. Probably only one hierarchy only across all plants and see how this compare with 15 hours. Alternatively if you do have the time go through a decision tree exercise (or even better clustering) to check if there is any modelling issue. I often found the devil in the details.

Other than that, it could simply be a case of a 'slow' or 'overworked' server which could require a much simpler solution.

Please let me know if you that helps you.

Good luck,

Rodrigo