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



3. Do develop buy-in for your project as you develop your model.

Any organization sufficiently complex to warrant a computer simulation will undoubtedly have a large number of differing viewpoints and stakeholders, not always sharing the same agenda.  Chances are, the facility or department that you are simulating will see you as an outsider, and possibly as a threat.  I've always found that it is essential to develop buy-in and ownership of your project among the insiders if the results are to be accepted.

Ask for advice and insight from as many people as you can.  Most are willing to share their knowledge if asked respectfully.  Don't assume that you know better than they do, you probably don't!  Spend a lot of time on the floor, make sure they see you and know that you are not working from an ivory tower.  Get a feel for the dynamics of the operations, pick up the particular jargon they use, understand their perspectives and their problems.  Unless you are working with a completely roboticized facility, remember that the people involved are the greatest source of problems and of solutions.

I always like to ask the people on the shop floor how they would solve the current problem, not just for explanations of the status quo.  Many times, I've found that the solution eventually adopted was envisioned long ago by inside people who had no voice with the higher-up decision makers.  If you find yourself in this situation, you have a built-in ally and internal champion; make sure to get this person involved.  If possible, bring him in for your final presentation as a domain expert, name a scenario after him, make him the true hero.  This will go a long way toward getting your recommendations adopted and accepted.

4. Do make sure that your conclusions are statistically significant.

Once your as-is model is validated, you will be testing a variety of what-if scenarios and observing how they affect system performance.  Hopefully, one or more of these scenarios will result in improved performance.  But is the improvement significant?  Or is it just a pleasant but coincidental outcome due to the random numbers used in your simulation?  Remember that not all differences are significant differences, especially in a statistical sense.

The classical method for demonstrating statistical significance is with an ANOVA, or Analysis Of Variance.  This statistical tool is not too difficult to understand or to perform, and if you are not familiar with it, take a half a day and read up on it in your old college statistics text.  It can be performed with a hand calculator if necessary, or with a standard spreadsheet program such as Excel.  If you don't feel comfortable with this type of math, solicit the advice of a statistician or a more statistics-oriented engineer colleague.

The dangers of ignoring this "do" cannot be overemphasized.  Your recommended changes to the system will not come without a cost; even if no new equipment is purchased, the changes to policies and disruption to production while they are being rolled out will not be free.  If the anticipated improvements do not materialize, your project will be a failure, and your reputation will suffer severely.  Before you go out on a limb and suggest your solution be implemented, make sure that you are standing on sound statistical ground.

5. Do communicate your results effectively.

After you have finished your project, including testing of a variety of what-if scenarios, selecting the best alternative (or perhaps several candidates), and proving statistical significance, you must communicate your results within the organization.

I recommend that this take place in a presentation format, similar to the validation meeting we discussed in Do #2.  In most cases, your presentation will be too complex to simply write up and drop on someone's desk; also, it will most likely lead to discussions and trade offs, and the final decision regarding selection of alternatives will involve a number of different stakeholders.

The first thing to remember in preparing this presentation is that you have been living and breathing with the simulation for awhile, but your audience has not.  They are also unlikely to be as well versed in simulation technology and terminology as you are, so be careful to present your results in a language that they understand.  Use graphics and animations wherever possible.

Present the strengths and weaknesses of each of your alternatives in terms of labor savings, time savings, material savings, cost to implement, disruption during roll-out, repercussions to the rest of the organization, etc.  Also, remember to use the internal champions that you developed; invite them to attend, and bring them into the discussions as appropriate.  They will add credibility to your results, and will speed along the eventual implementation.