Two Make-Store-Pack Scheduling Studies
A Bottleneck That Moves with Pack Format, and Storage Sizing Under Reblend
Two plants with the same Make-Store-Pack layout ran into two different scheduling problems. At a coffee plant, the bottleneck moved every time the packaging size changed. At a consumer products plant, reblend made the in-process storage requirement move, and undersizing it would mean shutting down expensive upstream processing.
How Make-Store-Pack works
In Make-Store-Pack, a making process runs more or less continuously into intermediate storage, and packing lines draw from that store into finished formats. The store decouples making from packing, so it sets how much each side can vary before it stops the other. Material moving through making and into a store is a rate, not a queue of items. Both teams modeled it with discrete-rate simulation, the approach ReliaSim packages today.
Coffee: the Shifty Bottleneck
A quality initiative required inserting a new production stage into an existing Make-Store-Pack coffee operation. The stage itself wasn’t the problem, but scheduling broke. As packaging sizes changed, the bottleneck moved, and an Advanced Planning System can’t schedule against a constraint that won’t hold still.
- Sector
- Coffee · Make-Store-Pack
- The decision
- Insert a new quality stage
- What broke
- The bottleneck moved with packaging size
- What it was worth
- A scheduling algorithm validated before deployment
- Evidence
- Project record · qualitative
The change
The quality initiative added a stage to the make-store-pack chain. Every stage inserted into a coupled system changes where material accumulates and where it waits.
Why the schedule broke
The system exhibited moving bottlenecks. When the packaging size changed, the constraint moved. Nothing had failed. A different format simply draws from the store at a different rate. The plant’s APS assumed a fixed constraint, so its schedules slipped, with no warning, whenever the mix changed.
What came out of it
The team’s model reproduced the moving bottleneck instead of assuming it away. With it, the team could conceive, test and verify an entirely new scheduling algorithm. They confirmed it held up across a range of demand scenarios, not just the current mix.
The plant replaced schedules built on a fixed-constraint premise with an algorithm validated against variation before it was deployed.
Evidence: ChiAha project record, reported qualitatively (the source carries no throughput or cost figure); client not named.
Consumer products: too little storage stops the expensive end
A CPG manufacturer found its in-process storage requirement wasn’t a fixed number. It changed with scheduling rules and with how much material was being recycled back through the process. Undersizing it wouldn’t just slow the line. It would mean shutting down expensive upstream processing.
- Sector
- Consumer products
- The decision
- How much in-process storage to build
- What the model found
- The requirement moves with reblend and scheduling
- Risk avoided
- Shutting down expensive upstream processing
- Evidence
- Re-implemented at a dozen factories
Why reblend makes storage hard to size
Reblend is material fed back into the process rather than thrown away. It’s ordinary practice and good economics. It also makes in-process inventory much harder to predict, because the flow into storage isn’t just the making rate anymore. It’s the making rate plus whatever is being recycled. The recycle stream in turn depends on what has been running and how it was scheduled.
That creates a loop. Scheduling changes the reblend volume, reblend volume changes the storage requirement, and the storage requirement limits what can be scheduled. Sizing that with a static calculation means picking one operating point and hoping the plant stays near it.
The two errors don’t cost the same. Oversized storage costs capital and floor space. Undersized storage backs up into the making process and stops it. When one error is much worse than the other, you want a distribution rather than a point estimate.
What the model showed
The team used discrete-rate simulation to study how in-process inventory actually behaved over time. They also studied how scheduling policy reshaped the utilization problem instead of just shifting it.
The result was a set of better scheduling strategies, developed and validated against the model before going into practice, along with much better in-process inventory management.
The model was reused at a dozen factories
A model that solves one plant is a consulting deliverable. This one was re-implemented at 12+ similar factories in the region. That shows the behavior it captured was structural rather than local. Once a rate-based problem like this is properly solved, the solution usually transfers to operations built the same way. That transfer is the strongest argument for modeling the mechanism rather than fitting one site’s history.
Evidence: ChiAha project record, replication count as it appears there; client not named.