So you have completed your Arena simulation project. You slaved over input data and extracting the system description from the experts. You developed a detailed functional specification to guide you through the model development. You developed the Arena model in sections so you could easily verify it. You spent several hours with the system experts to validate the Arena model to make sure it had the correct fidelity. And you ran several scenarios to find the best of several alternatives to achieve the objective stated in your functional specification. Now you're finished and you feel really good!!

I am sorry to say that is the way most simulation projects go, if you are lucky and good. And it may be that is what you wanted from the project. One and done!

But is there a way to make your model a living breathing part of your company’s decision process? It can be done – and in many cases it should be done. You have invested too much time and money on the model to just let it become shelfware.

So what does it take to turn this model into a solution that can be used with “Live Data”?   This is what we call an operational model. A model that will be used on a periodic basis with the current status of the system to make decisions for that periodic time period.

To get started we need to consider the following:

• Did we include the possibility of turning the strategic model into an operational model during the functional specification phase for the strategic model?
• Does the logic need to be revisited?
• How often we are going to run this operational model?
• What “Live Data” will we be loading into the model to make it an operational tool?
• How will “Live Data” be maintained and updated?  And by whom?
• What about validation of the operational model?

Review and Refine the Functional Specification

This really takes us back to the definition stage of a model. I would like to say that during the functional specification phase of the initial model (and here I am assuming you had a functional specification phase), we considered the possibility of turning the strategic model into an operational one but in most cases that is probably not true. We might have been too busy and under too many time and cost constraints related to the strategic model to even begin to think of what we could do with the model later. So we need to go back to the functional specification and make sure we have a plan as to how we are going to take our current model and turn it into the operational one. This would entail the usual suspects as posed in the list above.

Review the Model Logic

First of all, will the logic of the model need to be modified? There might need to be more detail in the operational model than in the strategic model. So the assumptions you made for the strategic model need to be revisited. In addition, the strategic model might have logic that is used to “warm-up” the model. But now we no longer need that because the model will be starting with the current status of the system. And this might require a new piece of logic. Therefore, we must revisit the model logic in detail.

Determine Model Execution Frequency

Next, how often are we going to run the model? This question would have been answered for the strategic model when we developed the functional specification for the strategic model. But we must look at that again. Our operational model will more than likely be used in a shorter time frame. You might run every hour, every shift, every day or every week to see what will happen for the next given time period. This will lead us into the next requirement.

Define the Live Data Requirements

What needs to be loaded into the model? From a modeling viewpoint, we need the “stuff” that is in the system either currently being processed or in queue waiting to be processed. This may be a little overwhelming because it may take some time to determine where this “Live Data” resides, in what format it resides, and in what format my Arena model will want it. But the goal is to get the current status of your system and use that as the starting point for the model. In Arena, we can do this by reading the current status into input variables and by placing entities into queues. And the strategic model will more than likely have these status variables and queues defined. It may take a bit of time to expand these to incorporate the current status.

Once we know what data we need, we must delve deeper into this requirement. As we stated above, where does it reside? In fact the “Live Data” may be in more than one location. So someone in the organization will have to determine where the data resides and how to get it into the format we need. In addition, we will need to develop an “automatic” way of retrieving this data and populating it into the format required. Someone within your organization will need to be named the data “Czar” and be ready to perform this task based upon the time period for which we wish to run the model. That is, if we are going to run on a weekly basis, then we will need to have the “Live Data” ready on that weekly basis.

Validate the Model

And finally, just like we did for the strategic model we will need to validate this model. For example, if we are going to run on a weekly basis and the run time will be for the next 26 weeks, what should we do to validate the model? We should look back at our system and take a 26 week period in the near past that represents what might be happening today. We start the model with the first week of that period and run for the 26 weeks. Then we compare the outputs of the model with the outputs of the actual system just as we would with a strategic model. And we should be “close enough” that everyone agrees that the operations model is representing our system.

There is a lot to consider when going from the strategic model to the operational model.  However, the benefits to gained from an operational model can far outweigh the benefits from a one-off strategic simulation model.