In our experience, only a small portion — say 10 percent to 15 percent — of projects produce results that are unexpected, perhaps counter-intuitive and that have a significant impact on the project. But the reason we simulate these systems is that there is no way ahead of time to know which ones will result in these findings. We've chosen 10 projects that produced some of these results.

1. Maintain involvement with the decision-makers throughout the project. We had a most interesting simulation project which involved determining the correct spacing between stations in a distribution center filling orders for cosmetics and related supplies for the women's beauty industry. Orders would arrive from field representatives. These orders were started in one tote on a conveyor that passed by some eight stations each with an array of approximately 50 products that were pulled from "pigeon hole" storage locations and placed in the tote. If and when a tote was filled, but the order had not been completed, another tote was added. So, one order might consist of three totes, for example. The conveyor acted as queueing space for the totes.

We had a great meeting with the manager of the distribution center to start the project. He met our data needs and provided access to his staff. At the halfway mark, we called for the distribution manager so that we could discuss our progress. The response was, "He's not here today." We called again the next day and received the same response. We asked when he would return. We were told, "He's in New York on a special reorganization assignment. He's only here on Fridays." We asked if we could meet on Friday. The answer was, "No, he has a full schedule every Friday that he is here."

We finished the project about two weeks later. We sent the final report to the distribution center manager. We sent an invoice. We were paid. But, we never saw the distribution center manager again and thus were unable to explain the simulation results. We seriously doubt that our design was ever implemented.

2. Make sure that you know all of the assumptions. One of our largest consulting projects was the redesign of a port and the railroad depot at the port terminal. This port was in Western Australia. The port received iron ore by rail and it was dumped to form two gigantic piles. From these piles, ships bound for Japan were loaded with iron ore according to a recipe.

We were actually sub-contractors on this project. The contractor was a consulting firm that provided service to port operations throughout the world. The contractor was located in the Northeastern United States. The contractor had some simulation capability, but the people there could only model the most basic of systems.

The port in Australia didn't realize at the outset that we were the ones actually building the simulation model. All of our communication went through the contractor, then to the port. This arrangement became cumbersome, so the contractor revealed that we were actually doing the modeling. The port was not upset. In fact, they asked that one of us come to Australia and take a look at the system. After many hours of flying one of us arrived in Sydney, followed by a long flight to Perth in Western Australia. Next there was a two-hour train ride. The port operator insisted that we take a one-hour ride and visit the port. Immediately, we realized there were three gigantic piles, not two. This caused some remodeling activity on our part. We built the model on the wrong assumptions, the assumptions that were provided to us by the intermediary consulting firm.

3. Think outside of the box. A major manufacturer in the Southeastern United States suffered a catastrophe that stopped their production capability. The plant manager of the production facility asked the engineers how long it would take to rebuild the plant. The engineers' response was 18 months.

"I want production in 12 months," said the plant manager.

Eighteen months later, production began, and it built up to normal within two years. The plant made a claim to the insurance company for lost profits. The insurance company said that the reconstruction could have been completed within 12 months and began negotiating with the plant. The plant called on the project management company that had developed an intricate network of activities with time estimates to control the reconstruction. The project management company asked if we could help convince the insurance company of the timeliness of the reconstruction.

Recalling a homework exercise in a simulation book by Alan Pritsker, we built a simulation model that generated a distribution of completion times. Thus, the plant was able to argue that in only a small percentage of the cases could the facility have been rebuilt faster than 12 months.

4. Simulation is an analysis tool, not a design tool. We had a project with a consulting firm in California whose actual client was a manufacturing facility in Ohio. There was a throughput requirement that was set as a goal by the facility in Ohio. We completed our analysis, but reported to the consulting firm in California that the throughput could not be met. They revised the system and sent it back to us. We performed another analysis, but the throughput could not be met by the revised system.

The consulting firm said to us, "If you are so smart, you make it work."

We insisted to the consulting firm that we aren't system designers, but that we had noticed some possible improvements based on our experimentation with the system. We made those changes in the design. Still, the throughput requirements could not be met.

5. Understanding a client's expectations is the first project task; resetting them may be your second task. This problem is something we see often — little or no understanding of simulation. This can lead to unrealistic expectations for the project, expectations that you may not be able to meet. It's critical to test the level of understanding and expectations before you commit to a project. Most decision-makers have simply not come in direct contact with simulation technology before, and they tend to either underestimate or, worse, overestimate what simulation does and what is involved.

In an industrial automation project, the client expected that the model would be able to automatically design an optimal layout and equipment configuration by simply being fed the right data and requirements. When we explained that this is not how simulation models normally work and that this would be very costly, if even possible, they decided they had the wrong consultant! That is, they assumed we did not know what we were doing and informed us that they would look for someone else. We suspect they are either still looking, having been through many consultants who could not deliver on this expectation.

Luckily, we found this out at the beginning of the project rather than after we had spent the time and money to build a model that would never satisfy them.

6. The "perceived" cause and the real cause of a problem can be quite different. The client for this project — a large on-line grocery delivery service in a large metropolitan market — had already completed initial simulation modeling to help design the facility. Orders received via the internet by 11 p.m. were organized, released, picked, packed in the large and highly automated facility and delivered by a fleet of vans according to guaranteed time windows the next day. After two years of operation, the facility appeared to hit a peak throughput at about 50 percent of what the initial simulations said it should be able to achieve. The client had a list of proposed changes which they thought would address the underlying problems: more conveyer accumulation space, additional shipping lanes, changing conveyer diverters, changing the order batching rules — mostly physical changes to address congestion that was easily observed.

The initial model was updated to the "as built" status of the facility, and the proposed changes were added and readied to test before they spent the money on upgrades.

During our data collection activity to confirm the operator productivity rates, we noticed that a lot of "expediting" was going on — people running around to manually complete orders — something that had not been discussed before. After investigating the reason and adding these elements to the model, we were able to demonstrate that most of the congestion, and thus capacity limitation, was due to simple operator pick errors. The client had assumed an accuracy rate that the workforce (which had a very high personnel turnover rate) just didn't achieve. The model clearly showed that pick errors resulted in downstream problems that compounded as the day wore on. The final simulation project results showed the need for very few physical changes, but a new focus on adding automated verification steps for picking, and on recruiting and training to improve operator efficiency and accuracy.

7. The simulation results speak for themselves. As analysts hired to help ensure a successful project, our role is to present the data or simulation results, no matter where they lead. This project, in which we modeled a new, highly automated order picking and packing system for a major shoe distribution facility, almost led to playground behavior. An early modeling phase prior to construction confirmed the operation of the system design, given a series of assumptions at that time.

Sometime after the system went live and showed serious congestion problems, we were asked to come back into the project and update the model to see if we could identify where the problems lay. There were several equipment vendors involved, each with different ideas and stakes in the project. The client, with a very demanding project manager, was withholding payment to everyone until satisfied that the simulation results clearly pointed out what changes were needed, and who would be responsible to implement and pay for them.

Unfortunately, no one was contracted with management or systems integration responsibility, so they all felt that fixing the system should not be their responsibility. When the updated model clearly showed the same problems as the real system, it resulted in serious finger-pointing and yelling and screaming among the team members before order was maintained. We had to be very careful to manage how the data was presented and interpreted.

Working methodically through a series of simulation experiments, we were able to show that no single vendor was significantly at fault, but rather that the problems were the compound result of many factors, not the least of which was that the data the client initially provided for order size and frequency information (profiles) was incorrect. A series of suggested fixes was tested, including showing the effect of increasing the productivity of the operators, and a solution was finally proposed, proved and successfully implemented.

8. Leave time in the project schedule for the simulation results to have an impact. This project involved a new automated material handling system and control logic to organize, pick, pack and ship orders for a large North American book publisher. Expecting higher throughput to meet projected expansion, the design was based on using a series of horizontal carousels to store the inventory, and conveyers to link the picking stations to each other and to the other processing areas. Several equipment vendors were involved. One contracted us to "verify our design." Assuming that this would be a simple, final step in the design process, we were given only a few weeks to complete it, as "construction of the new system is scheduled to begin very soon."

The results of the simulation clearly showed that the new system would not achieve even half of the total order processing capacity it was required to deliver. We were able to demonstrate that, among other issues, the base problem was related to the order profiles, which were simply not appropriate for this type of automation. The order profiles resulted in many more (largely empty) order totes moving through the system than were expected.

After initial disbelief and challenging of the results, things got interesting. The project was put on hold while the original design firm was challenged to fix the problem. When they were unable to come up with a fix, the design was scrapped and replaced by a completely different approach, requiring many more months to complete than what the original project schedule had allowed.

9. Don't reach too far. Large complex models can become cumbersome and useless. This project, for a major government agency with a large network of facilities, was meant to highlight their new technologies in a showcase facility that was supposed to operate in a "lights out" mode (all manual activities replaced by automation that could run in the dark). The simulation was to be the early centerpiece of promoting the new automated handling and robotic technologies and how they would operate together.

The modeling activity was started before all the major components of the system were well defined or even known. With no ability to see the entire design and start with a simple "top down" approach, we had to start building detailed models for only parts of the facility. This process went on for over a year, taking on one major subsystem after another as they were defined. During this time, we learned a lot about how the system was expected to work. We learned details that were not available at the outset and realized that this would impact the model architecture and underlying assumptions. Each subsystem model had to be connected with the others, resulting in a complex system architecture and database. When all the subsystem models were finally completed and connected, the result was disappointing; a very slow running set of connected models that were difficult to set up and run. Ultimately, the model was set aside and never really met its intended use. We learned a lesson the hard way about understanding the complete modeling requirements first, then properly designing and building the simulation model.

10. Focus on what should be built, not what can be built. We've been involved with a number of projects simulating transportation infrastructure, such as rail switching yards and port intermodal cargo facilities, which can illustrate a different way to employ simulation analysis. In this project, a new rail staging yard near a major port, the objective was to determine which of the alternative layouts would produce the greatest capacity for arriving, staging, inspecting, assembling and departing railcars.

In working through the model requirements with the engineering team designing the rail yard, we found that they were developing several alternate designs to be simulated. These designs attempted to achieve the maximum number and length of tracks that the physical space would allow. We then took a step back to ask what the expected throughput or demand on this facility would likely be, and found that it was less than the total capacity of the final designs. Using the simulation model, we were able to show that the anticipated demand could be met with less infrastructure than the "maximum capacity" design that was being considered.

The simulation results were used to justify a reduced final design, saving the client significant investment for rail infrastructure that would not have been needed. Had we just used the model to answer the question, "Which design has maximum capacity?" we would have missed a key point that the real goal was to answer the question, "Which design best meets the requirements?"

Conclusion


Baseball is often used as an analogy to life. It is said in baseball that "sometimes you win, sometimes you lose, and sometimes you are rained out." In providing simulation services, we will say, 85 percent of the time it's something that you have already seen; 10 percent of the time, it's something entirely new; and the remainder of the time things don't go at all as planned. This article talks about some examples in the last two categories. Our problem was not in creating these examples, but in winnowing the list to just 10.



Jerry Banks (atljerry@earthlink.net) holds the title Academic Leader at Tecnológico de Monterrey in Monterrey, México. Previously, he retired from the faculty of the School of Industrial and Systems Engineering at Georgia Tech in Atlanta and then he was Senior Simulation Technology Advisor at Brooks Automation (now Applied Materials).

Randall Gibson (randall.gibson@me.com) is an independent consultant based in Solana Beach, Calif. Previously, he was Principal and Senior Vice President in the Management and Supply Chain Consulting group at TranSystems Corporation, where he managed the Simulation and Analytical Modeling Practice Area. He was founder and president of Automation Associates, which was acquired by TranSystems in 2005. He has over 20 years experience in simulation modeling and consulting.

Table of Contents

OR/MS Today Home Page


OR/MS Today copyright © 2009 by the Institute for Operations Research and the Management Sciences. All rights reserved.


Lionheart Publishing, Inc.
506 Roswell Rd., Suite 220, Marietta, GA 30060 USA
Phone: 770-431-0867 | Fax: 770-432-6969
E-mail: lpi@lionhrtpub.com
URL: http://www.lionhrtpub.com


Web Site © Copyright 2009 by Lionheart Publishing, Inc. All rights reserved.