The problem
Where the time was going
A new arthritis medication was set to be one of the largest pharmaceutical launches the industry had seen, and the plant tasked with producing it would have to double its output from about 2 billion to 4 billion units. The launch had been planned in great detail, marketing and conventions were timed to the release, and production was confident it had the process and the people in place to meet demand.
The team lead was not so sure. He had an uneasy feeling that something about production was not right, the kind of feeling that does not go away just because the spreadsheets look fine. Static Excel calculations said one shift of testing could cover 24 hours of production, which implied the plant could make and test product around the clock with no delay.
An ad-hoc readiness team was assembled to manage the launch, with the hard goal of shipping on time. The challenges were to set the right delivery schedule for raw materials, to find the cycle time and equipment the process needed, and to work out how many employees and shifts the manufacturing, packaging, and laboratory areas required, all early enough to buy equipment and train people before the launch.
What we modeled
Mapping the process, then testing the fix
Given the short timeline, the team took a top-down approach in ProcessModel, modeling the whole process at a macro level first and then adding detail where the bottlenecks were. The first area modeled was warehouse receiving, where the material agent in charge of procurement, Esteban Perez, built static inventory models that were then tested in the model to confirm they could guarantee supply for the new product.
Once the warehouse results fed into a single model of the entire process, a problem appeared that the spreadsheets had hidden. A long queue of capsule samples built up at the entrance to the analytical laboratory, the last step before a drug can ship, while the lab ran at maximum utilization. The team verified the model repeatedly and everything else looked right, which left one question: why was the queue growing so large?
The laboratory had been scheduled for two shifts, six days a week, sized with static Excel math that assumed a fixed average arrival rate of samples. The model instead accounted for the random variability of real arrivals, the downtimes, schedule delays, and absenteeism that bunch sample deliveries together and then leave gaps. That difference was the whole story, and it was the point the static analysis had missed.

If capacity calculations and resource needs estimates are based on averages you are missing the point since averages just mean that you will not get your average number close to 50% of the time and it proved to be crucial in this analysis invalidating static analyses.
The result
The proof, and the payoff
The simulation showed the lab was short two shifts. The single planned testing shift could not keep up, and without the change the process would have run at a fraction of its planned capacity. Once the model made the true requirement clear, the team concluded the laboratory needed three shifts of chemists working seven days a week to hold the queue down and meet cycle-time requirements, and management hired and trained an entire extra shift in time for the launch.
Output doubled from about 2 billion to 4 billion units, and the launch became the most successful prescription-drug launch in the industry's history, breaking numerous records. The plant went on to be the primary worldwide supplier of the medication, consistently meeting demand on time, and the company made simulation a standing part of how it tests a production process before committing to it.
Part of our work in healthcare.


