“Don’t leave money on the table.” Some version of that line comes up again and again in meetings where simulation is presented. Most systems are complex enough that finding the right solution is far easier said than done. To land on the exact combination of conditions that delivers the best possible performance, you have to examine many scenarios.
Every situation can call for some change to your model, and the sheer number of parameters and combinations can produce thousands, even hundreds of thousands, of possible experiments.
That leaves you facing an impractical task, and real improvements go unrealized simply because there was never enough time to experiment. “Great presentation. Are you sure you’ve found the best solution for our business?”
With ProcessModel the task becomes far easier. The optimization tool, SimRunner, automates the work of creating, running, and analyzing scenarios. You give SimRunner a goal, or an objective, and it adjusts the parameters of the model to meet it. Set a goal of the highest throughput with the fewest resources and the lowest work in progress, and SimRunner runs scenarios, changes the parameters, compares the output, and shows you the best settings to reach your goal, all while you work on something else.
When to use process optimization
When should you optimize? You need it once the number of choices exceeds the number of experiments you are willing to run by hand. A natural starting point is around 15 experiments. Past that, set the model up for optimization. It takes only a few minutes to configure, and you can do other things while the computer runs the experiments. When the numbers get large, let the optimizer run while you go to lunch or head home for the night, and the best solution will be waiting when you return.
How many experiments might be needed
It depends on the number of factors and the number of choices for each. To find the count, multiply the options for one choice by the options for the next. If there are 3 job functions and the staffing for each can vary by 5 (say, from 15 to 20), the number of possibilities is 125.
Think of it this way: 5 choices for the first factor, and for each of those, 5 choices for the second, which is 5 x 5 = 25. For each of those 25 combinations, 5 choices for the third, and so on, giving 125. It is easy to see how fast this gets out of hand. With just 6 factors at five choices each, you are at nearly 16,000 experiments. Add two more factors and the count exceeds 390,000.
Design of experiments
In a complex system, design of experiments is used to limit the number of trials to save time and money. That means some experiments are never run, because of an arbitrary decision not to try those combinations. Rather than cut possibilities artificially, why not let the computer eliminate trials based on the responses it actually sees? That is what simulation optimization does. It performs a smart design of experiments and evolves as it goes.
It works a little like natural selection for the tsetse fly: the weak ones die off and the strong ones reproduce. In an optimization with over 400,000 possible experiments, the intelligent search in ProcessModel may find a great solution after running just 270. That is automated design of experiments at work.
There is another catch. Classic design of experiments was not really built to handle a range of possibilities for each factor (such as 15 to 20). Use a range and the number of experiments grows dramatically, and you are back to sifting through huge result sets to decide which is best, doing the analysis yourself. In a complex system that can mean hundreds of hours poring over data to find the best result.
How to do optimization
It is really not that hard.
- Prepare a validated model
- Insert scenario parameters
- Run the model and launch SimRunner
- Set the goals for optimization
- Select the parameters to adjust
- Optimize
- Plug the optimization values into the model
Prepare a validated model
This article is not about validating models, so I will keep this short, but do not optimize unless the model is validated. Optimizing an unvalidated model is a gamble, with a high chance the outcome is wrong. A few simple checks go a long way: watch the animation to confirm the model performs every intended function, make sure the input data is correct, test all distributions, export the model data and check each time value, time unit, capacity, queue size, and move time (I use a red pen to tick off each entry), and compare both the overall output and the critical parts against real data from company systems. Building a model of the as-is system this way is exactly how you gain confidence in its predictive power before you start making changes.
Insert scenario parameters
With a validated model in hand, create scenario parameters for each part of the model you want to change. To make the steps easy to follow, we will use a very simple model, though the same procedure applies to complex ones.
In this model, items arrive every 20 minutes. The first activity, Process1, takes 60 minutes, and the second, Process2, takes 180 minutes. The goal is to maximize throughput with the minimum resources. You could work out in your head that three workers are needed at the first activity and nine at the second. You would not normally simulate a model whose answer you already know, but this simple example makes the steps clear.
Now define the scenario parameters for the elements that will change. Scenario parameters are like control levers for the number of resources, or any other value you want to vary. With the optimizer, they are adjusted automatically across a range you specify. The scenarios dialog lives in the simulation menu.
We add one scenario parameter for each worker type. Here is a useful tip: always start scenario parameter names with “s_” so you can spot them at a glance and know they are scenario parameters rather than a variable or attribute.
The default value acts as a starting point for the optimizer. Even though we know the answer, I will pretend I do not and set the defaults to 2 and 8.
Each scenario parameter then has to be placed where the adjustment will be made. Since we are changing the quantity of resources, go to the resource dialog, delete the contents of the quantity field, right-click in that field, and use the keywords selection to choose the appropriate scenario parameter.
Because Worker1 is assigned to Process1, the capacity of that activity has to be large enough to hold the assigned workers. Without changing the capacity of the activity, it is as if you have plenty of resources but no workspace for them. Delete the contents of the capacity field, right-click, and select the appropriate scenario parameter.
Repeat the procedure for Worker2 and the activity it is assigned to.
Run the model and launch SimRunner
With the scenario parameters in place, simulate the model and click No so you do not stop to view the results. This matters, because simulating the model creates and saves the output, which builds a map of the things the optimizer can compare. That map lets us set a target for the optimizer to hunt for. Then launch SimRunner from the Tools menu.
Set the goals for optimization
The objective function is an expression used to quantitatively evaluate the model’s performance. In other words, you create a target that SimRunner will intelligently aim for. By measuring various performance characteristics, and weighing them the way you tell it to, SimRunner can judge how well your system operates.
SimRunner only knows what you tell it through the objective function. If the function measures just one variable, Total_Throughput, that is all SimRunner optimizes. Leave out a term telling it to also minimize the number of workers and it assumes you do not care how many you use. Because the objective function can hold multiple terms, include every response statistic you care about.
In our example we maximize the items processed while minimizing the number of resources. In the Response Category field, select Entity, and the statistics that can be used appear in the Response Statistic field. Double-click “Item, Qty Processed” to move it into the objective function. Weighting can be added to adjust the relative importance of each statistic.
We will not change the weighting factors in this example, but a brief explanation helps. Weights are a way of load-balancing statistics that might otherwise bias the objective function. Models produce a mix of large and small values, so weighting keeps the function from unintentionally favoring one. Suppose a run returns a throughput of 0.72 and an average WIP of 4.56. Maximize throughput and minimize WIP with the same weight (W1 = W2) and you bias the function toward WIP:
Maximize (W1)(Throughput) = 0.72 Minimize (W2)(WIP) = 4.56
To give both statistics equal weight, apply 6.33 to throughput (W1 = 6.33) and 1.0 to WIP (W2 = 1.0):
Maximize (W1)(Throughput) = 4.56 Minimize (W2)(WIP) = 4.56
When you do want to favor one statistic over another, balancing them first makes the bias easier to control. Apply a weight of 12.67 to throughput (W1 = 12.67) and 1.0 to WIP (W2 = 1.0), and the function treats throughput as twice as important as WIP.
The other two statistics in the objective function are the worker counts. In the Response Category field, select Resource, then double-click “Worker1, Units” and “Worker2, Units.” Both need to be minimized. Click the line in the objective function that needs changing, select the Min radio button, and click Update.
Do the same for Worker2.
Select the parameters to adjust
With the target identified, set the range each scenario parameter is allowed to move through. All scenario parameters appear in SimRunner as macros; throughout this article we call them scenario parameters. SimRunner uses them to improve the value of your objective function.
Setting the range matters for two reasons. First, limiting the range reduces the number of experiments, so the search finds a result faster. Second, the real system may have physical limits that cannot be exceeded. If floor space restricts you to three machines, letting the count vary from 1 to 5 is pointless unless building changes are on the table; the conservative range would be 1 to 3.
Select the Define Inputs button and choose the scenario parameters to adjust in this optimization.
Select each scenario parameter in turn, set a lower and upper bound, and click Update.
Worker1, lower bound 1, upper bound 4. Worker2, lower bound 7, upper bound 10. Set the bounds as shown.
There are many capabilities this tutorial will not cover. The whole area of pre-analysis to determine warm-up length and the number of replications is covered in the Basics II training class.
Optimize
With a few final settings, the optimizer is ready. Select the Optimize button on the top toolbar.
Optimization profile. SimRunner offers three profiles: Aggressive, Moderate, and Cautious. The profile reflects how many possible solutions SimRunner examines. The cautious profile considers the most, searching more thoroughly for the optimum. Moving from aggressive to cautious usually gives better results, because more solutions are examined, though not always; for a difficult problem you may get equally good answers. If you are pressed for time or using few input factors, the aggressive profile may be the right call.
Convergence percentage. With every experiment, SimRunner tracks the objective function value for each solution. By recording the best and the average, it monitors the algorithm’s progress. Once the best and the average are at or near the same value, the results have converged and the optimization stops. The convergence percentage controls how close the two must be before it stops. A high value stops the search early, while a very small value runs until the points converge. The remaining options are largely self-explanatory.
The next step is to hit Optimize and then Run.
SimRunner tries to maximize the objective function. In this case it found the best result on experiment number 1, which will not happen often; the problem was simple, with a limited number of experiments, and the algorithm guessed right. It is easy to see how the objective function was reached here. It was given 108 points, one for each entity that exited the model, and lost a point for each worker (minus 3 for Worker1 and minus 9 for Worker2), leaving a final objective function of 96. Notice that experiment number 8 processed the same number of items but lost one additional point for using an extra worker.
Plug the optimization values into the model
The optimization should not be the final run of the model. Take the time to enter the results into the model, turn on the animation, and watch it run. That gives you added assurance the model is working correctly with the new values, and a chance to spot other improvement areas that were not part of the objective function.
SimRunner reliably seeks the optimal solution to your problem based on feedback from your simulation model, using some of the most advanced search techniques available. Its method is based on evolutionary algorithms, a class of direct search techniques drawn from the theory of evolution. The algorithms mimic that process: poor solutions fade away while good ones continue to evolve toward the optimum. Techniques built on this idea are remarkably robust and have solved a wide variety of difficult problems, and they are especially useful because they hand you not just a single optimized solution but many strong alternatives.
If you want to stop leaving money on the table, see what ProcessModel and SimRunner can do or explore plans and pricing.
