Don't Just Simulate, Solve! (page 3)

FIVE "DON'Ts" OF DEVELOPING A SIMULATION:

1. Don't include too many or two few functions in your model.

When you start carving out that part of the world that you want to simulate, you have to draw an imaginary dotted line around those functions which will be included in your model.  It is important to avoid flinging this dotted line too far abroad, but you must be sure to include all necessary functions, processes, and resources.

How do you tell exactly how much of the real world must be modeled?  There are no hard and fast rules, but your best guideline is the question that you are trying to answer, as determined in Do #1.  Which machines, people, and policies affect that question?  Which, if changed, will alter the answer to that question?  Any function or resource that has no bearing on the given goal can safely be left out.

Our other guideline comes from Do #2, incremental development; if we leave out some essential part of our model, this will turn up in our developmental review, and we can make a course correction.  Similarly, if we include unnecessary elements, we will find that they are not exercised during our validation tests and we can eliminate them during model refinement.

2. Don't include too much or too little detail in your model.

This rule is similar to the previous one.  Just as the scope must be appropriate to the problem at hand, so must the depth of the model.  If there is insufficient detail in your simulation, the answers will be too crude to reflect reality and point out a solution; if there is too much detail, you will be wasting time and resources, and possibly obscuring the answers and insights that you would otherwise be able to draw.

The rule of thumb here is also the same as before: ask yourself which details are necessary for answering your given question.  Do I care how many parts arrive at this machine, or only how many pallets?  Do I need to know how many minutes a process requires, or can I live with production cycles per week?  Do I need to model first, second, and third shift separately, or can I use an average workload?  Keep your decision based on answering the key questions, solving the key problems, not on reproducing every function of the real system.

Here again, we have room to guess incorrectly the first time and recover later.  Our incremental model development will enable us to recover from too much or too little detail, in the same way that it helped us include all necessary functions.

3. Don't forget about boundary conditions.

A simulation starts and ends, but a real factory tends to run continuously.  Even if you shut down overnight or on weekends, the work in process is there waiting for you when the doors open again.  If a computer model begins empty and idle, this could bias your data and lead to erroneous conclusions.

On the other hand, a service organization does tend to reset to zero each day.  When they lock the doors of the bank at five p.m., they still finish up all the customers on the premises, count the money, and leave everything tidy for the morning shift.  They start empty and idle each morning, although there may be a line of customers waiting at the door.

The point is to make sure you understand how your real system works and model it accordingly.  If your system never reaches an empty and idle state, let your model "warm up" for awhile before you begin to collect statistics.  How long must it warm up?  Check statistics periodically until they stabilize (our old friend the ANOVA will help here).  In the same vein, your shutdown logic must follow the real life situation; either finish all parts currently in queues, or continue them on the next shift, as appropriate.