Communicating ideas.  In addition to the statistical merits of simulation, models provide an opportunity to bring people together very early in a project. 

There are many ways to discuss the merits and challenges of a proposed system — written specifications, spreadsheets,  CAD models,  physical models, etc.  These things all provide a perspective on a system and a forum to discuss how well the system will live up to our expectations.  

• Can the bids from competing vendors be compared fairly? (specifications)   
• Can the system meet the proposed targets on a gross or average level? (spreadsheets). 
• Will the material for an assembly line fit by its designated station? (CAD models) 
• Do the end users of the system have feedback about the design of the system and how it will impact them from an ergonomic standpoint? (physical models)

The bottom line is communication.  When a large project involves disparate groups of people, one main goal for any effort has to be to improve communication within the team.  Almost every project has changes during its evolution.  Often these changes are required when the group realizes that the system design is lacking in some key area.  The reason for this oversight is often communication.   The earlier these changes can be found in a system, the cheaper the changes.

So how does simulation fit into this conversation?  I would say that time and visualization.  We all think of statistical output when presented with simulations. 

• Am I going to make throughput even after my expected downtime? 
• What percent utilization will my workforce have? 
• What is the average wait time for a vehicle trying to make a left turn? 
• How long will it take to evacuate a crowded train station?

But what about the unspoken aspects of a system?  Simulation provides a way to appreciate a system over time.  Most other analyses are static.  Simulation gives life the system and shows its ebb and flow.  This is especially true at the boundaries of a model.  For example, when modeling an automobile factory the modeler has to consider the arrival of parts.  The modeler could assume that parts are always available.  Or the line could be drawn at the modeling of the unloading process.  Or maybe a detailed arrival schedule for trucks from various vendors.  The challenge is that somewhere a portion of a process is modeled and the rest is assumed.  Getting these assumptions right is one key to a successful model. 

During the validation and verification of a model, bring in as any people as practical on the project.  During the specification process, you do your best to extract estimates, collect data, and detail the exact proposed operation of a system.  Many people do not work well with numbers.   Visual simulations over time bring out the critic in every one.  You need this critic.  When you show your model running the proposed system, people will point out what you didn’t model.  While this seems negative, it really is a positive because it brings out a conversation earlier and helps find the system design problems that are not statistical. 

A worker unloading trucks might point out that he has paperwork to do for each truck that is unloaded.  While you considered the time for him to operate the forklift, you failed to consider the time for paperwork.  Another example could be ergonomics related.  In collecting downtime data for a system you find comparable equipment in a factory that is running today.  You have plenty of samples and you have fit the MTTR and MTBF to distributions for use in your model.  It is isn’t until you invite the operators into a meeting that you realize that the layout of the line in the new factory means that operators have to walk a lot further (maybe even cross a line via a stairway) than they did in the other factory due to line layout.  This will lengthen their response times and change your expected availability.

A simulation project specification or review is often the first time that a large team gets to hear the concerns of others on the project.  It is an excellent forum for discussing the competing interests in a system.  Having a visual rather than a numeric view of the system engages people in these conversations.  You don’t have to model the Coke machine in the break room but it might be useful to show where the break room is on the layout.  Empirically, I think that communication provides 50% of the benefit on any simulation project.  Just like most things in life, the journey is more important than the destination.  If you communicate throughout the process, the customers for the model will feel like owners and you will have a better chance of implementing the ideas that arise.

——-

FYI -

Google’s main page today has a tribute to the 50^th anniversary of the Lego Block.  I guess that’s another way to model a system.  About 8 years ago I worked on a project with a company that used Legos to building a miniature version of a production line.  They then hooked up the Lego model to a real world control system and used it to train workers on how to interface with the proposed plant floor systems (data entry, RFID scanners, error handling, shipping procedures, etc).  It was a very effective way to introduce a new process without the footprint of a traditional factory.