The problem
Where the time was going
The task was to recommend the production configuration for a low-volume, high-variability assembly line running 500 to 700 units a month. The product was a data storage unit that housed information captured from the internet, and customers could order it across a wide range of configurations.
That range was the whole problem. Assembly times and quality acceptance rates swung widely depending on how a unit was configured, and the standard tools that had always been enough for steadier products could not capture the intricacy. They produced inaccurate predictions and poor resource allocation, and guessing at the resources and times instead would have risked delays, quality issues, and cost overruns.
What we modeled
Mapping the process, then testing the fix
The line was mapped station by station. It ran 14 stations, each able to add zero to eight sub-assemblies to the enclosure: a chassis might take one to four power supplies at station one, one of two motherboards at station two, one to eight disk drives at station three, and so on, with a zero requirement letting the chassis slide straight through. The line ended in two large test chambers, one heating and one cooling, both adding vibration, with failed units routed to a separate repair line and sent back through testing.
The model defined the product configuration on the chassis itself, using distributions to represent how many of each part a customer would request and which configurations market research expected, which made the wide range of orders simple to capture. Failure rates that rose with configuration complexity were entered with spreadsheet-style formulas.
With a product-mix forecast from sales, the team load-balanced the line and sized staffing to monthly demand, then ran a mini Kaizen event over two days with production, scheduling, and management. Ideas were tried immediately in the model, where months of simulated time played out in minutes. Some logical-looking ideas simply did not work, and others only paid off when several were applied at once, and watching the animation made it clear why.
The result
The proof, and the payoff
The real test came at implementation, and the model held up unusually well. It had predicted system performance within 7 percent of the actual line, an accuracy that stands as strong evidence the model truly reflected the floor.
The account is honest about what the model did not foresee. Operators physically carried product between parts of the line, which neither the model nor production management had anticipated, and one real assembly time came in lower than modeled because of an equipment change. Even with those differences, the ability to test improvement ideas in the computer first gave a real boost in confidence before committing to the configuration.
Part of our work in manufacturing.