How To Implement Multiple Calls To The Same Submodel

During a process improvement project for an aircraft engine repair facility, I have learned an interesting lesson that I would like to pass along. It feels like this lesson can be used in a broad range of industries. I am simulating the facility so that I can see how the impacts of changes in one department effect other departments.

While creating the simulation model, I observed that each department sends parts to non-destructive testing (NDT) area to determine if the parts can be reused or need replacement. Once in the NDT department, all parts follow the same path. On completing the NDT, the part is returned to the department of origin. I had anticipated using one submodel to call from 12 separate departments, but I was unsure how to accomplish this in ProcessModel simulation software. Below are the lessons that I have learned:

Yes, it was possible to call the same submodel from many areas of a model, it saved me a ton of time and the limitations of the NDT were exposed. The model behaved like the real system. When more areas were sending parts to NDT, the response time slowed. Healthcare process improvement made in one area had a significant impact on the others. Process changes to one department won't provide real changes to the entire system because the problem simply moves to another department. From using the process simulation model I identified four required changes to allow the system to be improved. When the four changes were implemented in the same project, it would allow an additional unit to be produced each month. That equates to $5 million additional revenue per month for dollars of investment per day.

A few simple rules needed to be followed to implement calls to the same submodel in ProcessModel. The rules are easy to follow and set up. Below are the rules:

1) Activities in the main model that call the same submodel need to have at least one activity separation.

2) All routes going into the common submodel can use the same linking name.

3) All returns from the submodel need to originate from a common activity in the submodel. If the submodel requires exits from several areas then create a dummy activity with zero time and have all routes point to the dummy activity.

4) When developing the simulation model, tag all entities exiting the main model with their activity of origin.

5) Use conditional routings to steer entities back to the proper activity in the main model.

This process improvement project has provided me with incredible insight into the interrelationships between departments. Using the multiple calls to the same submodel allowed me to finish the project and analysis quickly.