Build and Test Models Faster

Build and Test Models in a Fraction of the Time

In an Oregon Hospital, a modeler has learned a technique to build accurate models in 2 days. Not models of one interaction, but models of an entire department, such as Surgery, Maternity or the overall flow of a hospital. In this article, you will learn three concepts to speed modeling. And, you will see how to be 100% confident in the model and the results.

Article Summary

The usual method of developing a simulation model requires extensive time to analyze data, verify operation and validate the statistical characteristics of the model.

This article shows an alternate technique called “Real Data Modeling.”  This method uses actual product or patient records to drive the model. Each record contains routing, duration, resource requirements, etc. The required data is pulled from company systems and is read-in to ProcessModel.

It sounds difficult but is not. Building a real data model can be accomplished in a fraction of the normal modeling time. Testing is simple because known inputs are required to give known outputs. A past production schedule can be input and checked against the resulting production reports.

Faster modeling means quicker decisions which mean improvements for things still the focus of management. And that means…

Get to the Decision

The most common reason for building a model is to answer a question. We want to know an answer with certainty. We use modeling because the entire interaction can be included and understood. We want to be certain, so we build a model.

Statistical models are built by analyzing past data to create predictions of what could happen in the future. All statistical models must go through a rigorous and time-consuming process to verify the model.

An Alternate Approach

Alternatively, use actual data from a previous period to drive the model. For a surgical suite, a real patient record is used to find the date, time in preop, suite needed, surgical time, post-op time, etc. For a manufacturing facility, actual orders provide quantity, routing, setup time, batch size, work time, etc. There are no distributions needed for this modeling technique.

Some of the advantages of Real Data Modeling include:

• Lightning-fast model builds
• Simple and quick validation – you can compare actual inputs with known outputs
• Model accuracy is very high
• Change the model by changing the input

What is the Theory?

Keep it simple. When using actual times and requirements, see the performance possible from proposed changes. If proposed changes would have made a difference last year, then those changes can be projected on this year. For example, you could stop the simulation when the production orders complete, recording the hours required. After making changes, run the model again and compare the needed hours alongside the previously recorded hours. Calculate the improvement. Keep it simple.

An Indiana manufacturing company produces 170 different products on a single production line. Each product had unique routings and workstation times. The routing, setups, and station times come from the company database. This information is “read in” through Excel. Historical records give past production schedules. The schedule is also “read in” from Excel. In days, the company was answering questions such as:

• What products should be close to one another in production sequence?
• What products should far apart in production sequence?
• What were optimal batch sizes?
• What products should move to another line?
• What will increase production?
• Where are the best investments to increase production?

The model became a fast method of performing a kaizen study. Imagine, ideas becoming experiments and tested within minutes. That’s what they did. As a result, they improved production by more than 40%. The project cost was low.

How to Build a “Real Data” Model

There are three main steps in developing a “Real Data” model.

1. Build the model to handle any order of routing.
2. Build the logic to extract the routing information from entity attributes.
3. Prepare the arrivals to carry attribute information.

Build the Model to Handle Any Order of Routing

Think of the model as being generic. Build it to handle any routing order. Send all entities to a common location where they will pick up the information needed to route “to” the first activity and pick up how much processing time will be required. When finished at the first activity go back to the common location and pick up the information for the second location, and it’s associated processing time.

The structure of the model has all entities entering into the common location. Conditional routes are used to read a common attribute to steer entities to the next location. Once at the activity, the processing time is another common attribute. When finished at the activity all entities are routed back to the common activity to pick up the next location and next time. A simplified healthcare example is used below to illustrate.

Routes depicted in blue are percentage routings. The black box is a dummy activity used to consolidate all blue routes from the locations so that only a single route goes back to the director. Routes depicted in red are conditional routings. See the example conditional route to the ED below:

In a healthcare environment, the number of locations might expand to 20, but this technique is useful in any industry. The base model could be expanded to hundreds of locations if needed. When changing the model to match your locations, the following will need to be modified: change the names of the activities; change the conditions in the conditional routes; and change the logic described below.

Build the Logic to Extract Information From Entity Attributes

All the logic for the model is in the Director activity. The logic is simple. Every time an entity enters the director, it’s counter attribute is incremented. If it is the first time through the Director, then the location is read from the first location attribute and the processing time from the first time attribute. If it is the second time through the director, the location and time are read from the second set of attributes. Below show example logic

INC a_Loc_Count
IF a_Loc_Count = 1 THEN
{
a_Next_Loc = a_Loc1
a_Next_Time = a_Time1
}
ELSE IF a_Loc_Count = 2 THEN
{
a_Next_Loc = a_Loc2
a_Next_Time = a_Time2
}
ELSE IF a_Loc_Count = 3 THEN
{
a_Next_Loc = a_Loc3
…etc.

The attribute a_Next_Loc is used in every red (conditional) route to steer the entity to the next location. The attribute a_Next_Time is used at every location to determine the processing time at the activity.

Every location uses the same attribute for processing time. See the example dialog below:

Additional attributes are added to account for other aspects of the system, such as setup time or batch size.

Prepare the Arrivals to Carry Routing Information

The last step in using Real Data in the model is to structure the scheduled arrival input sheet. A complementary input sheet resides in the Arrivals Category of Model Objects. Example information populates the sheet:

Prepare the input so that the first location goes into the attribute a_Loc1 and the associated time goes into attribute a_Time1. The good news, a company database usually contains all the information needed. If you need help converting your data to this format, please contact support. We have done this many times.

Show the Entity How to Exit

How does the entity know when it has completed it’s routing? The entity goes back to the director and sets the attribute a_Next_loc to the next value. If the attribute (a_next_loc) equals zero (0), the entity leaves the simulation. See the example below:

The logic from this example can be expanded to handle as many locations as needed.

Using the technique of “Real Data Modeling” allow you to build and experiment with models in a fraction of the time normally required. Faster modeling and analysis means quicker decisions which mean improvements for things still the focus of management. And you know what that means.

You might have a few questions. If you would like to discuss Real Data Modeling and it’s implications, please feel free to contact me: