Simulation software is a great boon to the modern engineer; cheap, abundant, easy to learn and to use. The flipside of this accessibility is that engineers are often called upon to solve problems using a simulation, but without the benefit of years of experience, libraries of past models, and departments full of grizzled veterans to dispense advice. We end up working by the seats of our pants, often misusing this powerful but subtle tool, and sometimes coming up with irrelevant or even erroneous results.
The purpose of this article is to share some hard-won experience from one of those grizzled veterans, with some practical tips for ensuring that your simulation really addresses the needs of your situation and of your organization. With this in mind, I have assembled five essential "Dos" and "Don'ts" for ensuring that a simulation is useful, practical, and efficient; that it solves the problems for which it was developed, and that the overall experience is a positive one for the engineer and for the organization.
FIVE "DOs" OF DEVELOPING A SIMULATION:
1. Do take the time up front to decide what your goal really is.
Often the phrasing of your nominal assignment will not describe the real problem, so be sure to do some homework before you start assembling your simulation. What are the real problems, and what are the real goals? Remember that you can't get what you want until you know what you want, so spend some time on properly defining the problem.
For instance, many plant managers will complain that an expensive machine tool or processing line is underutilized, and will want you to find ways to get more work through it. But this is probably not the real problem, and solving it may only increase work in process inventory or cause other disruptions. The real problem is more likely to be an upstream bottleneck, a lack of sales, or maybe that the machine wasn't really needed in the first place!
Also, beware of conflicting objectives. There are many metrics of plant efficiency, and you cannot optimize them all at once. For example, you cannot simultaneously minimize inventory levels and backorder waiting time with the same policy; they usually involve a tradeoff. By the same reasoning, you will rarely be able to maximize machine utilization while maximizing flexibility of production mix; they require different approaches to lot sizing. Similarly, a long-term rigid production schedule will maximize purchasing and scheduling efficiency, but will not optimize your responsiveness to customer demand. The trick to resolving these kinds of conflicting objectives is to realize that they are really only intermediate objectives; you really want to maximize sales, minimize production costs, or optimize some other bottom-line metric.
2. Do use an incremental approach to model development.
Start with a rough outline, with minimal detail, and simulate your system in broad strokes. Remember that the odds are good you will be going off in the wrong direction at first, or at least not in the ideal direction. Spend a few days on this rough model, and then solicit feedback from experts who live with the real system day in and day out. Ask the plant manager if your rough model resembles the way the line really functions. Ask the production supervisor if you have reproduced the releasing policies correctly. Ask the foremen if this is the way decisions are made and implemented.
I like to schedule a meeting for this type of discussion about a third of the way into model development. Get the appropriate personnel involved, explain to them all of your assumptions, show them your output and some rough statistics, and see if they agree with how your model is behaving. Not only will they be able to point out deviations from reality, they will help ensure that you are asking (and answering) the appropriate questions. Animated output is a big help at this meeting, since you will often be dealing with people new to the simulation concept.
You might want to plan on some "what if" tests for this meeting as well. For example, shut down one machine in a production line and see what it does to output statistics. Your production manager should have a good feel for what the real effect would be, and can help validate your model and its results. Alternately, your foreman probably has a workstation or two where he frequently needs overtime labor; see if doubling resources at this location has the expected effect.
After a meeting of this sort, you can proceed with much more confidence on the detailed development of the model. If it is a very complex or involved model, you might want to schedule several of these tweaking meetings, just to make sure you stay on the right track.
