How to Find Production Bottlenecks Before They Happen
To find a production bottleneck before it happens, run the planned line in a simulation model with real cycle time ranges, stops, transport and order mix, then look for the place where work queues up in front and the stations behind it wait. That place limits your output. Then change something, run the model again and check where the bottleneck moves. A few days of modeling before go-live costs far less than finding the constraint through lost output and overtime after it.
Why bottlenecks show up only after go-live
Most lines are planned with average cycle times. If every station is faster than takt on average, the line looks balanced. Then production starts, and a queue builds in front of one station while another waits for parts.
There are three reasons this happens:
- Variation. Take a station that averages 50 seconds and, in this illustrative case, sometimes needs 75. One slow cycle is harmless. Several slow cycles in a row fill the buffer in front and starve the stations behind.
- Interaction. Stations share forklifts, operators, buffers and changeover teams. A resource that is free on average can be busy exactly when it is needed.
- Transport and waiting. Material has to move between stations and warehouses, and time spent waiting for pickup appears on no cycle time sheet.
The bottleneck is also not always a machine. It can be an operator who serves two stations, a forklift shared by three lines, a buffer that is too small, or a picking route in the warehouse. A spreadsheet that lists machines will never point to those.
What a bottleneck looks like in simulation output
A simulation model runs the line over a shift, a day or a week, with cycle times as ranges and stops taken from historical behavior, and shows where time is lost. These are the signals to read:
| Signal in the model | What it usually means |
|---|---|
| Long queue in front of a station | That station, or the transport feeding it, limits the flow |
| Station after it often starved (waiting for parts) | The constraint is upstream |
| Station before it often blocked (cannot pass parts on) | The constraint is downstream or the buffer is too small |
| High utilization of a forklift, cart or operator | A shared resource is the bottleneck, not a machine |
| Long waiting time between processes | Material waits for pickup or transport |
| Output drops sharply in some runs, not in others | The line is sensitive to variation, so the constraint shifts |
One signal alone can mislead. A station with high utilization and no queue in front of it is busy without limiting the line. Look for the combination: a queue in front, starved stations after it, and lower line output when that station slows down.
A step-by-step method
- Model today's line first. Use your layout, routings, cycle times, transport speeds, shifts and a typical order mix.
- Check the model against reality. Compare its output and the place where queues form with what the shift leaders see on the floor. If they disagree, find out why before going further: the gap between nominal values and the real floor often points to the real bottleneck, and closing it gives you inputs you can trust.
- Add variation. Replace single average values with ranges based on historical behavior. A stochastic model then shows the bad days next to the average one.
- Run the planned change. New layout, new product, higher volume, a robot or an extra shift.
- Read the signals. Find the place with a queue in front and waiting behind it.
- Test a fix and run again. Add a buffer, move an operator, add a cart, change the release rule. Then check where the constraint moved, because it usually moves somewhere.
Step 6 is where most of the value lies. Removing one bottleneck often creates the next one, and the model shows it before you buy anything.
See where your line will wait
Think of the line change you are least sure about. The demo shows how DBR77 Digital Twin points to the station, operator or forklift that holds a flow back, and where the constraint goes after a fix.
Example: a manual step that held back the whole line
A plastic injection molding company in central Poland, working three shifts for the household appliances industry, wanted to automate several stations on one line. DBR77 built a digital twin of that part of the plant, with material flows and cycle times for each task, and produced efficiency, productivity and working-time reports for each variant.
The analysis found the bottleneck at a manual step by the first operator: 90 seconds of activity and 98 seconds of waiting. More than half of that operator's time was waiting. Replacing that operator with an autonomous cart increased efficiency by over 100%, which created the conditions for the investment to be economically viable. The variant analysis took only a few days.
A cycle time study would have rated this step as fine, because it measures working time. The loss sat in the waiting.
Example: when the bottleneck is waiting for pickup
A car lamp manufacturer in southern Poland, with 270 people on two shifts, needed a new line layout. DBR77 modeled the material flow, including transport speeds and the acceleration and braking of the trucks, and compared three layout variants.
In the results, the layouts that lost efficiency did so because semi-finished products waited for pickup between processes. The winning layout placed a buffer warehouse in the central area between production and assembly. Its average material flow time was not the shortest, yet its daily productivity was on average 6% higher than a linear layout without an intermediate warehouse.
In the weaker variants, the constraint sat in the gap between processes. How to Compare Layout Variants Without Guesswork shows how to run such a comparison.
After go-live: check the model against machine data
A model shows where the bottleneck should appear, and machine data shows where it does. Once the line runs, compare the two. Does the queue form where the model said it would? Are stop times and cycle time ranges close to the inputs?
Where they differ, update the base model to match the line as it really runs, so the next decision starts from the real plant. Live machine data from DBR77 IIoT is the next stage of that learning, because the comparison then runs on real data every day instead of occasional checks; What to Measure in the First 90 Days of IoT describes which measures to start with.
Bottlenecks also move when demand changes. A line that is balanced for today's mix can choke on next year's. Testing that in advance is covered in How to Test Capacity Before the Next Demand Shift.
FAQ
Can a bottleneck be something other than a machine?
Yes. Operators, forklifts, autonomous carts, buffers and warehouse picking routes are common bottlenecks. A simulation shows them because it tracks the utilization and waiting of every resource, people and vehicles included.
Why does the bottleneck move after we fix it?
Because the next slowest step or resource becomes the limit. A faster station can flood the next buffer or overload a shared forklift. Run the model again after each fix to see where the constraint goes.
Do we need live machine data to find bottlenecks in a model?
No. A first model can run on routings, measured cycle times, stop histories and the order mix. Live data is the next stage, once the model is used regularly: it shows the gap between model and line every day and tells the model owner when the base model needs an update.
How long does a bottleneck analysis take?
It depends on the scope. In DBR77's published case studies, an automation variant analysis took a few days and a multi-variant line layout analysis took about a week.
Conclusion
Start with the model check on a line you already run. Ask the shift leaders where queues form today and check whether the model, fed with ranges instead of averages, puts them in the same place. Once it does, you can trust it on the planned change.
Bottlenecks in real projects
In both examples above, the constraint was waiting time that no cycle time sheet recorded. The use cases show how DBR77 Digital Twin found it in line design, automation and warehouse picking.
Sources
- DBR77, Case study: Development of an automation concept (summary on this site)
- DBR77, Case study: Production line design (summary on this site)
- DBR77 Digital Twin, Deterministic vs stochastic simulation
- DBR77 IIoT, What to Measure in the First 90 Days of IoT
Want to test a decision from your plant?
Book a demo and we will show how DBR77 Digital Twin compares the options on output, waiting time and transport load.