Production line: where is the constraint?
A line isn't hitting its target output, and the client is deciding where to spend. Before they buy a second machine, use Quodsi to find what limits the line and test the fix.
There's no published production line model yet, so you'll build this one yourself. This page covers the setup and what to look for. It has no sample figures: every number should come from your client's data.
The business question
Your client asks: "Which station limits our output, and what happens to WIP and throughput if we change it?"
A value stream map shows you the steps and the cycle times. It won't show you how breakdowns, scrap and small buffers interact over a shift. Simulation does.
How a production line maps to Quodsi
| On the line | In Quodsi | View needed |
|---|---|---|
| Parts or units | Entity | Basic |
| Work released to the line | Generator | Basic |
| Each station | Activity, with its capacity set to the units it can work on at once | Basic |
| Space between stations | Inbound Queue Capacity and Outbound Queue Capacity on the Activity | Basic |
| Operators shared between stations | Resource | Intermediate |
| Machine breakdowns | The Activity's Failure tab, with MTBF (mean time between failures) and MTTR (mean time to repair) | Advanced |
| Scrap at inspection | A Dispose action, with a State to count what's scrapped | Advanced |
| Rework or repeat passes | A Loop action | Advanced |
Set it up
- Draw the line, one shape for each station, with arrows between them.
- Convert the diagram to a model. See Quodsi for draw.io.
- On the Generator, enter how often work is released.
- On each Activity, enter the processing time. Use a range if it varies.
- Set each station's capacity, and each buffer's size if buffers are limited.
- Run the baseline, and check it against what the line really does. See Check the model.
- Add operators, breakdowns and scrap one at a time, and check again after each.
Two small examples show the patterns you'll need: Dispose: scrap a bad part at inspection and Loop: three coats of paint. See how to open an example.
Data to ask your client for
- Cycle time for each station, as a range or a full history
- Release schedule or demand
- Buffer sizes between stations
- Breakdown history: time between failures and time to repair
- Scrap and rework rates by station
- Operators per shift, and which stations they cover
What to change
- Capacity at the suspected constraint. Add a machine in a scenario, and see whether output rises or the constraint moves.
- Buffer sizes. Test larger and smaller buffers, and watch WIP against throughput.
- Reliability. Improve MTBF or MTTR at a station, and compare that with buying capacity.
- Scrap rate. Test what better quality at one station gives you downstream.
- Operator count. Put a lever on the Resource's capacity, and sweep it in a study.
What to look for
- Throughput. This is usually the headline number. Check it across replications, not just from one run.
- Where queues build. Work piles up in front of the constraint. Flow Analytics is the place to look.
- WIP and cycle time. A change that raises output but also raises WIP may not be the win it looks.
- Whether the constraint moved. After each change, find the constraint again.
- The start of the run. If the line starts empty, early results will look better than normal running. See Warm-up.