05.21.08
The “Worst Case” Trap
One of the biggest problems with most simulation projects is the availability of good data. The phrase Garbage-In-Garbage-Out gets tossed around liberally. However, this is a double-edged sword. As an analyst, villifying the existing data is meant to prompt your customer to go get better data. Many times poor project timing or the lack of a convienent comparable system leads to the project team to take the easy way out. That easy way is to look for the worst case scenario on the data and use that as an input. The logic behind the decision is that if the system can handle the worst case, it will be sufficient for any production goals that have been set.
The phallacy in that approach is twofold. First, using worst case data can easily lead to a system that is over-designed. Too much capacity is required to support the wild variations introduced by worst case data. Second, if your goal is something other than production (say inventory reduction), your worst case data may have the opposite effect.
I ran into this problem on a recent engine-chassis marriage project. The engine-chassis marriage operation at an auto plant involves ”stuffing” the powertrain for a car into the shell of the car and fastening it in place. Usually the power train is moved up into place while the car body moves overhead. A separate build-up line is used to assemble the powertrain component and the sequence of the engines and transmissions matches the sequence of cars being built on the main production line. A picture of a vehicle that “stuffs” the powertrain in place is shown below.
For this project, there were two main car styles that were produced by the plant. Each “style” required different tooling for the cart shown. the time to change the tooling was several job cycles so extra carts with a mixtures of tooling options were used to allow time to switch plates without interrupting production. The key to sizing the system was how often these tooling plates would need to change. This is driven by the sequence of cars going down the line. Getting this sequence proved to be a challenge because the vehicle sequencing program at an assembly plant is quite complex. Initially, we tried a completely random mix of jobs. The rationale was that this would be the worst case. While it truly was a very bad case for the system, it would have driven us to expensive changes to the system had we not tried to find a more realistic solution. By spending the time to get an accurate reflection of the sequence, we were able to proceed comfortably with a system that had a lower capital investment.
In short, the competitive landscape of the manufacturing does not allow us to take the easy road and protect for the worst case scenarios. We need to be diligent about gathering the appropriate data. An error to the side of caution can be as damaging to a company as an error that causes a system to be undersized.
05.06.08
Estimating Project Time
When starting a simulation project, one of the more difficult things to do is estimate the expected time required. If you are part of an internal group, this is critical to the usefulness of a model. If it is not ready in time, the conclusions may be moot. Decisions will need to be made and often those decisions will not be postponed while waiting for a simulation to be completed. As a consultant, our profit is usually tied to our ability to estimate. On long term projects, it may be possible to provide an hourly rate and work as part of a team. While this allows your profit margin to remain in tact, your ability to estimate well and deliver models on time will dictate whether or not you get the next project.
So what are the issues? I have an acronym that I use when looking at a project to determine the time required. I need to look at the F-A-C-T-S
F- FOCUS
Why are we building this model? What questions need to be answered and what questions do NOT need to be answered. It is easy to assume that the model needs to do everything. In a rush to make the end customer happy it is easy to say, “I can model anything”. While it might be true, this leads to complicated models that take too long to build, too long to change, and ones that are not nimble enough to be part of a team decision making process. Use a rifle approach to defining the scope of the model, not a shotgun. Be clear with the end customer that the model is designed for specific purposes. Its like designing a car. You are not going to bolt a trailer hitch on a sub compact at the last minute because you have decided you want to tow a boat. If they need an SUV model, decide that early on and let the customer decide.
A - Assumptions
I am not referring to the assumptions that are made as part of the model building process. Once a project begins you can collect cycle times and understand how decisions are made. I am referring to project level assumptions like - “the timing on this project is tight” or “animation is important” or “there are a lot of variables to test” or “we want to have a scripted video file as an output” or “we have complex 3D data that needs to be filtered and included in the project”. These are game changing expectations that the customer has. You need to ask as many relevant questions as you can. These can be very generic questions but they will strike at the heart of why the model is being built and what will be considered a successful outcome. Even if you write a scope that says the model will not do X and not do Y, the customer’s satisfaction will win out in the end. For the most part they do not know what is easy and what is difficult to model. It is common for customers to assume that all their changes are minor. You need to tell them up front what will be difficult to change later so they can make decisions about how the model will be used.
C- Confidence
Confidence in the model to be built. Have you built or supervised the building of a model like this in the past? If not, you better leave some time for the unknown. The first time I build a new type of model, I add 20-30% to the time for the unexpected. It is hard enough to deal with the changing landscape of a typical engineering project. This time is useful for researching the most effective way to model a particular aspect of the system or simply for extra model verification to be sure that the new model you built is functioning correctly.
T - Training
Does the end user want to use this model later? Does the model need a friendly interface to make is accessible to others? Are you supervising someone else building the model? Do you need training on a specific aspect of the software that you have not used before?
S- Software
Does the model need to be built in a specific software package? What version of the software? Have you used that specific version of the software? Do you know what bugs are published for that specific version? Is there a reason to lobby for a different software package? How fast will experimentation run? Will the animation requirements place an undue burden on the software? Do you have the proper hardware to run the model in the allotted project schedule?
In summary - interview the customer to find out what they know about the project. Treat it as an interrogation without the bright lights. Your organization and methodology will give the end customer confidence that they have placed the project in the right hands.
