It’s the journey that counts

You might have heard in other contexts that the journey is as important, if not more, than the destination. This is also true with process and operations simulation as there are many steps involved in building simulation models and they each have their own unique value.

Every one of these steps involves questioning what we know about the system we want to improve.

Step 1 – Precisely defining the problem and the questions that need answering

Determine system boundaries, performance goals, KPIs. All these things need to be done first to guarantee that we will be working on the right thing in the right way.

• Why do we want to simulate instead of using traditional methods of analysis?

• What exact questions are we trying to answer?

• What do we want to measure?

• Where does the model start and where does it end?

• What alternate scenarios could we analyze?

Step 2 – Collecting the data and information required to build the model

We list resources and elements to be modeled and the parameters that they require. Then we find, obtain, extract, clean, structure and format the data to make it usable in the simulation model. This step leads to a better understanding of the system and its components as it forces us to organize the information about it.

Step 3 – Building a base scenario simulation model

When building the model logic to reproduce a real or a newly designed system, we raise questions about the system that had not been asked before because the system had not been looked at from this perspective and had not been looked at from the ground up.

By measuring the performance of the base scenario and comparing it to the real system performance (or to expected results in the case of a new system) we find discrepancies which allow us to identify improvement opportunities and identify alternate scenarios to simulate in addition to the ones we might have listed in step 1.

Step 4 – Building alternate scenarios

Some alternate scenarios had been identified at the start and others we identified during the previous steps. In any case, this is where there are simulated and compared based on KPIs. And again, those scenarios might generate other scenarios or variants. That iterative process is where a lot of the value of the project is created.

Most simulation projects end after this step. There is no need to go further because questions have been answered and objectives are met. The model might be reused later to answer other questions, or it might not be reused at all and that is fine too.

Traditionally that is what simulation has been used for, and those steps describe most of the simulation projects I did in my career. I call these models “one-shot deal” model.

Step 5 – Using the model as a management tool

This step is gaining popularity as it uses the power of simulation to run what if scenarios of production or operation plans. For example, a production planner runs next week’s production plan in the virtual factory model to see its performance and make adjustments before using it in the real physical factory. This requires creating a user interface and setting up a method of easily importing and exporting data from the model.

At this step, the simulation model generates recurring value by assisting management decisions. But it also requires the model to be maintained and updated to continuously reflect the real physical system when it undergoes changes. If the value is greater than the cost, this type of model is worth it.

I call these models “management tools”.

Step 6 – Converting the model to a digital twin

Here we need to integrate real-time data streams to the model to exchange information with the physical system and synchronize the model with reality. Consider that this is one order of magnitude more difficult than the previous model type.

One of the dangers in building that type of model is to want to build an exact replica of reality. And, as we know, the devil is in the details. So, the model can work well with 95% of reality but wanting to model the last 5% might make it exponentially difficult. Do we really need to model every exception to reach our goals? The answer is usually no but the pull to try to do so is great.

The term digital twin lends itself to these expectations so maybe it should be called “digital semi-twin”. But that is a lot less evocative.

If you hope to get close to a digital twin, it must, or course, be planned right from the start. Step one needs to be much more exhaustive than for a “One-shot deal” model or a “Management tool” model. In fact, every step is more detailed.

Conclusion

What is important to remember is that the concept of digital twin is neither the ultimate solution nor is it the only outcome when it comes to simulation of processes and operations.

Every step of building a simulation model creates value and most situations require only reaching step 4 to have a perfectly good one-shot deal model that answers our complex questions.

Others clearly benefit from going to step 5 to have a management tool. And others might benefit from going to step 6 to have a digital semi-twin.

And any type of model can be a good model. A more complex or developed model is not necessarily a better model. It all depends on your goals and objectives. Sometimes simpler is better.

And in any case, the journey is as important as the destination.