When we start simulation projects the first thing we usually want to know is the purpose of the study.  What’s the question?  What’s the motivation?  This tells us a lot about the level of detail and scope of the project.  I’ve come up with five typical classes of questions.  Each type of question tells us something about the system before we even start the project. 

Will It Work?

This question is often asked on projects where someone is trying something for the first time or it is very early in the process of designing the system.  Intitially we have concerns about how fluid the design will be.  We have expect to build a very flexible model because its bound to have a lot of changes.  By “work” the customer often is referring to throughput or some other key metric like on time delivery.  You can always drill down and find out the source of the concern.  That should be the focus of the model because its probably the first thing the customer will look for when you are presenting conclusions.  These types of binary questions are a bit dangerous estimate the total project time because customers will often continue to change the system until it works and that could be a lengthy road.

How Many Do I Need?

Many systems are based on past implementations but they are resized or reconfigured to fit a new product volume or a new space.  Simulations are often used to figure out the details for this particular instantiation of the concept.  Some example of questions might be “How many carriers are needed in the paint shop?”, “How many AGVs does this assembly system need?”  How many forklifts do I need to support material arrival at the docks?”.   In each case, the customer has seen this type of system work in the past they just don’t know the capital required to apply the solution.  These are usually cut and dry situations that revolve around the quality of the input data.  You will spend a lot of time learning about the details for the system and the model should be relatively stable in terms of concept. 

One warning though.  People will often think that System B is just like System A.  Take for example an AGV assembly loop.  At facility A, the customer is building a popular vehicle and they have an assembly loop dedicated to a portion of the vehicle.  At their new facility, they may decide on a similar loop but it is going to handle two lower volume vehicles on the same loop or maybe a series of specialized variations of a single vehicle.  These systems can operate very differently and its not just a line balancing issue.  Assuming you can balance the workload on each station, there are still issues that can impact the loop design as the project progresses.  For example, if you are assembling an axle you might have different key points where the axle rests on the AGV.  This could dictate different tooling plates for each part type.  The management of these plate swaps might dictate a completely different design idea that does not include AGVs.  The morale of the story is to decide for yourself if two systems are similiar and use the information to decide how the model should be constructed.

Why is THIS happening?

This type of question often comes from an existing system.   The operation is up and running but the system does not always behave as expected.  These projects will have a high “forensic” component.  You will spend time in the facility trying to figure out why a system is presenting a particular symptom.  An example of this would be a automotive paint shop.  Whenever a paint shop goes to lunch or break, cars cannot be left in the paint oven or even the spray booths.  The loading of the paint oven stops and the jobs in the oven continue to move forward during the break.  When the break ends, the oven starts to load again and the “hole” created by the break is closed by staggering the break schedule of a downstream operation.  Almost every paint shop I have seen handles these issues very well but it is an example of a systemic timing issue that can cause problems because its hard to see the big picture.  Innocent changes to an operating schedule or the ressignment of material handling personnel can impact an entire system without leaving “smoking gun” evidence.  Simulations are great at deciphering these kinds of mysteries but the key is what is actually happening in the system not what someone “thinks” is happening.  Get out there and watch the system to confirm all of the assumptions.

When Does IT Break?

Systems that are more mature or customers that are more forward thinking will often want to know what is the maximum capabilities of their system.  In other words, if we turned up the demand when would our system fail to deliver results?  This is really bottleneck identification with a twist.  We are trying to understand how close the system is to maximum capacity so we can make better decisions about how to handle future increases.  These simulations are usually straight forward and the questions are often coupled with questions about where to build a new product or whether another shift is required at a current facility.  One note, most systems will incur higher downtimes as you approach their maximum capacity due to less maintenance and the fact that fixed size buffers are a lower percentage of average production rates.  Downtime senstivity analyses often make sense in this case to see how much time you should spend refining MTTR and MTBF distributions.

How often will THAT Happen?

When people design systems they like to think in absolutes.  I don’t ever want THAT to happen.  Sometimes you can design systems to avoid specific events like a mismatch of assembled parts or two trucks competing for the same unloading dock.   More often though you are forced to decide on your level of service.  Airlines design baggage handling systems to route a certain percentage of the bags incorrectly (i.e. “lose them”).   They do this because the cost of a system that never loses a bag would be astronomical.  In the same vein, facilities are often faced with rare events that need to be either “designed out of the system” or “lived with”.  The decision to spend the incremental dollars on the redesign  often hinge on the frequency of the event.  Simulations are an excellent way to blend random events to count how often a combination of events cause these bad conditions. 

 An example of this happened on a past project.  We were analyzing traffic patterns around an automtoive facility.  During the last stages of manufacturing design, the building size was expanded due to a new buffer that was required inside the facility.  This made the building an odd shape and one road around the plant had two extra curves to accomodate the change.  This road was the main route to one of the sets of delivery docks.  Vendors would use this road sporadically to both enter and exit these docks.   The problem was that the road was relatively narrow.   The question was “should the road be widened?”.  If trucks travelling opposite directions would cross on this road once every few days, then the problem could be managed without widening the road.  If it was more frequent, it would be necessary to widen the road.  None of us could just look at the data and estimate how often it would happen.  The simulation showed that it was a very frequent occurrence (6-7 times per shift) and the road was widened.  None of us had a gut feel for this and the simulation was key to the decision.