There’s no clear-cut answer to this question. At SIMUL8 Corporation, we have customers with experience of over 20 years who build massive simulation models (I’m talking 40,000 simulation objects – things like queues and activities, plus 1.4 million entities – things like products and people) and yet we also have equally experienced customers who nearly always build simulations of no more than 10 objects – and both groups have been successful.

However, what is definitely wrong, is to build a huge and/or complex simulation when a small one will work well for its purpose.

An example of a simulation that was too big

One day we received an Invitation to Tender (ITT) to build a simulation for a company in the defense business. It arrived in the mail and it was three inches thick! I sensed that it was a case of being asked to tender when they already knew who they wanted to do the work. Nevertheless, one of our team responded with a detailed description of how we would build the simulation with estimates of cost and runs speed and memory usage, etc – all the normal things customers need to know before they commit to a project.

To our surprise, we won the project. Over the next few weeks, we built a huge and complex simulation with many customized dialog boxes so the customer could use it easily, with links to databases, multiple animation views, etc. This was a 30 day project and as it neared completion, our consultant building the simulation invited the customer to our office to have some training in using the simulation.

When he arrived our consultant started by asking “Can you describe what you plan to use this simulation for?” The client talked about a buffer in the middle of the simulation and the huge variability around his supply chain and customer demand. Our consultant started sketching the process being described in SIMUL8. The client looked at this and added a couple of complications to his story, which were added to the simple model.

It was a useful animation (nothing more) that was purely supposed to help understand the bigger picture of the large and complex tool we had built for them. The client then asked “Can you just add a few numbers to this, we know that process takes 2 days most of the time. . . etc” and after an hour or so this ‘animation’ had become a simulation – albeit a very simple one compared to the one originally requested in the ITT. Working with this simple simulation, the client then said “I had not realized that it’s fairly obvious that whatever we do the buffer size has to be at least 5 and we don’t have space for anything more”.

Then he paused, put head his in his hands, and said “Oh no, you’ve just answered my main question in an hour without actually using the simulation I’ve paid you to build over the last 4 weeks!”

How did the customer get in to this situation?

1) Some people see building a simulation as an IT project. There are some cases where they should be, but mostly simulations are part of a rapidly changing series of management questions that are all about how to make a series of decisions. These questions will change over time as new ideas, information and results from the simulation become available. If you see the simulation building as being separate from the decision making process it will become an IT project. It then has a defined set of features and it is not ready until it is built with those features and tested.

2) Because it is seen as an IT project the client naturally says “What are all the questions we might want to ask with this simulation? I better make sure it can answer everything”. The simulation then becomes bigger and more complex than needed for the actual question that needs answering today.

3) The complexity of the simulation that’s now been designed means it is going to take longer to build and cost more, so the client has to get sign off from senior management who themselves add more questions they want the simulation to be able to answer. They say “If we are spending all this money can you check it can also answer questions for the paint department and also the dispatch department”. Now the simulation model is not only complex in depth it is also large in its breadth. It’s become even more costly and, worse still, it will probably be too cumbersome to use to easily to answer the original question! It will certainly be too late, because the original client’s thinking will have moved on by the time the simulation is ready.

So when is big and complex right?

There are cases where large and detailed absolutely does work. For example, where the organization has plenty of simulation experience and has an abundance of knowledge about how to simulate each part of its process. This is because they already have a history of building small simulations of each part or building simple simulations of the entire process at a high level – which was what the defense customer really needed – and will reuse simulation on a daily basis to re-make decisions that repeat themselves.

Good examples are contact centers that need to make staffing decisions each day or oil companies that use the same process repeatedly to design refinery configurations and the behavior of each part of a refinery is well understood. In this case, a large simulation with a lot of detail will be an excellent way to understand the behavior of the ‘whole system’ when all the components work together.

In addition to the defense company mentioned above, a really good example of a failed ‘large simulation’ was a simulation I built early in my career. I was involved right at the start of using simulation in British Leyland. Our team in the Operations Research Unit had great success with our first few projects. We had reduced assembly line inefficiency by showing how simple rule changes in a store could increase body shell availability and we also reduced the number of robots required for a new part of the plant by showing that the design would produce the same number of sub-assemblies with three less robots.

So the plant director came along and said “I want one of these dynamic videos of the entire plant” – we never persuaded him to call them simulations! We thought this was fantastic news because it proved the value of what we had been trying to introduce. I was the team member selected build this simulation. What could go wrong? The earlier projects had all had a specific purpose: “We can’t rebuild the store but some body shells are getting blocked in by other types of car – what can we do?” and “We have designed a robot cell, what will the throughput be?”.

The ‘Longbridge Big Model’, as it was called, had no defined purpose – except perhaps “Answer any question I have”. Once it was built we discovered every question thrown at it was either too specific so the relevant part of the big simulation had not been created with quite enough detail, or too general and the model was too cumbersome and detailed to be able to get a big-picture of strategy.

We kept coming back to that simulation, adding more and more to it, hoping the next enhancement would prove its value – but instead it was a very big lesson in how not to do simulation!

Tips to consider when planning the scale of your simulations:

• Only build a simulation when you know the question it should help you to answer
• Include only just enough detail and scope to give a robust answer to that question
• Aim to deliver an answer in half a day (I mean both build the simulation and do runs to get results) – you won’t achieve this when you first start – but that’s the aim
• When the client wants to know more either enhance the simulation in the next half day or build a new simulation (too many simulation become tough to maintain because they have too many purposes)
• Don’t accept projects like “build me a simulation” – only accept “help me solve this problem” projects
• Don’t wait for data because the insights from a simulation with “guessed data” will start to focus the mind of your client on what they need from the project and what data to provide