How to Replace the Optimizer in SNP and PP/DS

Executive Summary

  • The real story on SNP and PP/DS is considerably different than what SAP proposes.
  • The optimizer cannot be made to run correctly in either application. This is why we recommend turning the optimizer off and using an external optimizer with the APO database.
  • SAP support is misleading many customers into continuing down a path that will never work.

Introduction to the SAP Optimizer

SAP has had long-term problems with its optimization projects. This includes both the optimizer in SNP and the optimizer in PP/DS. You will learn these issues in this article.


The SNP optimizer is designed to create a plan for the initial supply plan (usually the MRP run in ERP) and the deployment plan (generally called the DRP run in ERP).

The PP/DS optimizer is designed to create a production plan and production schedule.

Both optimizers use the ILOG optimizer to perform the optimization.

The Real Story with SNP and PP/DS

PP/DS: There is an optimizer in SAP’s production planning and scheduling module (PP/DS), but no client I have ever seen or heard of actually uses it.

SNP: Within SNP, the same optimizer does two different things.

  1. The Network Optimizer Run: It plans the initial network supply (production and purchase orders)
  2. The Deployment Optimizer Run: It produces stock transport orders to move material through the supply network.

I have performed quite a lot of work in troubleshooting these optimizers. This includes reviewing the output and pulling data out of the log file to chart the time it takes to run the optimizer and explain the results to management.

I have concluded that the 2nd optimization run, the deployment optimizer makes no sense in its output under any circumstances, and should not be used.

This is covered in the following article.

Real Word Recommendations on the Optimizer

I told this client to disable the deployment optimizer and the COPT 10 parameters that were supposed to improve the output (that SAP sold them for $50,000) — was not usable. The IT director did not appreciate the research that I did as he wanted me to use my credibility to tell the business that the output was good, and they needed to start using it. Just two months ago, I was contacted by a recruiter representing that same company, and they are still looking for someone to come in and help them fix the deployment optimizer. This is because IT does not want to admit that they made an error when selecting the optimizer many years ago.

The network deployment optimizer does produce usable output. But it is probably the most challenging procedure to test that I have run into since I started working in advanced planning back in 1998.

SAP had a specialist in the optimizer in Germany, or at least he was working there several years ago. SAP charged something like $400 per hour for him, and mostly what he did was say that the optimizer was working as it should. At multiple accounts, I saw the same thing. Typically IT would hire him; he would say everything looked great to him, and then IT would go and tell the business to stop complaining because the optimizer has been blessed by SAP’s top Ph.D. on the topic.

The State of ILOG

SNP uses the ILOG optimizer. ILOG was an independent company, but IBM purchased it. And like most IBM acquisitions, their profile declined a great deal after the purchase. Now no one talks about ILOG. Most software vendors do the same thing. They buy an off the shelf optimizer and then write parameter controls and user interfaces for configuration around it. When I usually tell my clients that SNP uses ILOG, they typically are stunned. SAP does not communicate anywhere that it uses an off the shelf optimizer.

Pulling the Optimization out of SAP

One way of interpreting is whether there is an off the shelf optimizer that can be found. The answer to that question is there certainly is. I have never participated in a project like this, so I can’t say how it would work exactly. But it could be possible to switch out the ILOG optimizer for another off the shelf optimizer — and then have that optimizer adjusted by the people that specialize in it. I can reach out to a colleague who has a recent start-up and is at a level of detail below me as he has written code around optimizers.

The second question is whether there is another optimization application that performs supply planning. There certainly is. However, since SNP was developed, the industry has moved away from cost optimization for supply planning. Let’s take a short diversion into cost optimization.

What is Cost Optimizer?

This means that the objective function of the system costs. That is one places the cost of transportation, the cost of storage, the cost of production, etc.. in the system. The optimizer minimizes those costs.

This is what I refer to as a first generation optimizer. SAP copied their design from i2, my old employer. But the approach never really made much sense. I cover this in the following The Rise and Decline for Supply Chain Optimization.

This design harkened back to the mid-1990s and attempted to take the same approach from cost optimization that had been applied to production scheduling. Cost optimizers never really worked very well for supply planning applications. I have thought that perhaps a better approach to optimization is optimization around service levels, and which can treat locations as interdependent stocking locations. The category of software is called inventory optimization and multi echelon planning. These are two different technologies or sets of mathematics in one application. The definition of each is listed here and here.

However, there is a catch….the implementation of these optimizers take a significant amount of time. It would mean throwing away the logic that a company had invested in developing its costs. So recommending them would, at least at first blush, not seem to be a good option.

DemandWorks has greatly simplified optimization in its product Smoothie. Overly complex optimization has dramatically damaged the reputation of optimization. But DemandWorks has brought they’re easier to use design optimization.


I can say with a relatively good confidence level that SAP is not providing much value in the updates they are providing the optimizer. Most likely, SAP is keeping hope alive by promoting the idea that just more tweaks are required, and the company will finally get what they want. There is a way of finding out, but it means reviewing the output of their system.

Regarding providing them with a recommendation, we need to know more about their history with the optimizer. It may be as simple as finding them an optimizer replacement, but there may be more to it.

SAP’s software has a low ability to support any supply or production planning business with an effective optimization solution. Paying $400 per hour to resources from Germany in SAP does not lead to good outcomes.

Replacing the optimizer with an external solution is the way to go.

For companies interested in replacing the optimizer from SAP can reach out to Brightwork for more details.