Perhaps no word gets tossed around more in supply chain than “optimization.”

In a general layman’s sense, it tends to mean “make it a lot better,” or “as good as we can achieve under the present circumstances.” As in, “We’re going to optimize our safety stock levels,” or “We optimized the layout in our distribution center.”

But there is also a mathematical notion of “optimization,” and whether the above examples really qualify under that concept depends on the tool sets used. This mathematical notion of optimization is at the heart of many – but not all – of the supply chain software applications that profess to “optimize” some process or decision, from supply chain network design to pick face slotting and a lot of situations in between.

On top of all that, there is renewed interest in supply chain “simulation” at multiple levels; and new concepts (for the supply chain) that straddle optimization and simulation approaches, such as “stochastic optimization" that add to the confusion for most of us.

So, we thought we’d try to sort out what’s what here. We won’t get it all finished this week, but think we can make some headway. Look for a longer report in a few weeks.

Improving Decisions

There are hundreds of places where supply chain software goes beyond automation of processes to helping users make better decisions. The most basic approach to this is the use of “heuristics,” in which business rules or algorithms are executed by the system to make or recommend a decision.

In a distribution center, for example, the decision about where to put a product in a storage location is made based on some algorithms that factor in the product type, velocity category, and other attributes. “Mathematical” optimality is not used, and is not required or likely even feasible. Optimization almost always takes at least some minutes to process (and in some cases hours), and hence isn’t generally usable in an execution environment. There can be gray areas, however. To use another distribution center example, “slotting” systems sometimes use heuristics, while a few use true optimization technology. There is no right and wrong, just make sure you understand the vendor’s approach. Each has its own trade-offs.

Relatedly, heuristics are often used as a pre-process, even in a true optimization-based program, to break the problem down a bit to make it easier for the optimizer to find a solution. Optimization-base programs, such as those usually found in supply chain network planning, transportation planning, inventory optimization, factory scheduling, etc. use well-known mathematical techniques such as linear programming and its cousin constraint-based optimization to scientifically determine the “best” result.

That “best solution” is usually defined as minimizing or maximizing a single, specific variable, such as cost or profit. Other factors, such as customer service, can be included, but as a “constraint” to the optimization run, eliminating certain answers from the potential solution set (e.g., if the highest profit design results in fill rates averaging below 95%, don’t include it).

When using optimization processing over a very large data set, such as a complex global supply chain network or huge transportation plan, heuristics are often used (as noted above) to reduce the size of the problem that the optimizer is working against. This enables it to complete faster, or to ensure it doesn’t produce theoretically optimal, but practically impossible solutions.

Software vendors will sometimes quibble about this, with one side claiming the other is using too much heuristics up front and not truly optimizing the solution. Operations research types recognize there are always trade-offs, and that there is no universal right or wrong, just what makes the most sense for the specific problem/decision that a company is trying to improve.

Supply Chain optimization technologies are in use in thousands of companies, and we’ve actually noted a bit of an upsurge in interest over the past year or so (more on that soon). But there are some things optimization isn’t so good at.

Optimization is generally based on some fixed estimate of demand over a given time frame. You can alter that demand estimate and run a different scenario to compare the impact on the recommended solution, but optimization in general is not good at handling highly variable demand or system inputs.

Optimization also tends to be a “black box” approach, taking inputs, crunching the numbers, and presenting a solution. It’s often hard for the user to really understand the interplay of various factors, and how the supply chain “system” (whether that’s a network or a factory) works as a whole.

That is where “simulation” can come into play. In simulation, a model of the system is built (again, whether it’s a conveyor system in a DC or a supply chain network). Rules are created (often still through programming, but increasingly with at least some level of system configuration) that describe how the system should work.

The key is that demand (or other key inputs) aren’t static, but are more dynamic. Demand can be estimated (or based on actual history) at a daily level. For individual plants or DCs, it could be on an almost minute- by-minute basis. It is also possible to use techniques such as “Monte Carlo” analysis to have demand or other variable populated more or less randomly over some period.

Running the simulation then allows the analyst to see the behavior of the supply chain system over time, as these inputs change. It may allow bottlenecks to be identified that would be missed in an optimization program that gives the best total answer but misses supply chain or operational glitches along the way. But to find the “optimal” answer, the analyst has to observe what has occurred, make some hypotheses about the dynamics of the “system,” change a factor (for example, add some more inventory, or another packing station), and see what happens.

The benefits: better ability to understand the impact of dynamic events, better total system understanding, and (increasingly important today) risk mitigation. But these benefits come at some cost, as we’ll explore next time.

Optimization and simulation can be used together, as is increasingly common in supply chain network design. In the next few weeks, we’ll also get into the pros and cons in more detail, and provide some additional examples of use cases and vendors.

Hope this clarified things a bit, and I would welcome your thoughts or improvement.

What are your thoughts on optimization versus simulation? Is this whole area something only for the Operations Research Experts, or should supply chain practitioners and execs get knowledgeable? How much so? Let us know your thoughts.