You Didn't Fix the Bottleneck: How AI Predicts Where It Moves Next
You fix the bottleneck everyone's yelling about.
Two weeks later, everyone's yelling about something else.
That's not bad luck. That's constraint migration. It just found a new address.
Last time, your test confirmed it: the changeover signoff step on Line 4 is getting skipped. That's what's been driving the failures. If you missed how we got there, catch up here. LINK: The 5 Whys Are Broken: How AI Helps You Track Multiple Root Causes.
So, fix it, right?
Not yet.
Before you touch that changeover procedure, you need to know what fixing it does to everything downstream.
Speed up one station. The next one over inherits a problem it didn't have yesterday.
Fixing One Bottleneck Just Moves It
This isn't a new idea. You already know a version of it.
Every operations manager who's run a floor for more than a few months has watched it happen. Fix the thing everyone's currently mad about. Give it two weeks. Now everyone's mad about something else.
That's not bad luck. The Theory of Constraints built an entire framework around this one fact.
A system only moves as fast as its slowest point. The moment you speed up that point, some other point becomes the new slowest one.
Fix the bottleneck. You haven't solved your problem. You've relocated it.
Line 4's changeover fix is a textbook case. Right now, the signoff gap is quietly limiting how fast that line can run.
Close the gap and Line 4 speeds up. Something else in the line now has to catch up. Or it becomes the new drag on the whole system.
What Constraint Migration Looks Like on the Floor
Here's the question worth asking before you fix anything. If Line 4 gets faster, what happens to everything it feeds into, and everything that feeds it?
● Does WIP start piling up in front of the next station, because it can't absorb Line 4's new pace?
● Does labor become the real constraint, because the crew downstream was sized for the old, slower Line 4?
● Does dock capacity turn into the bottleneck, because product is now arriving faster than trucks can move it out?
● Does something upstream start sitting idle, starved for work, because it was calibrated to Line 4's old rhythm?
These aren't abstract questions. Piling up, starving, and getting stuck are three distinct failure patterns, with three different fixes.
Speeding up one station can trigger any of them, somewhere else in the line.
A faster Line 4 that just shifts the pain to receiving, or to the loading dock, hasn't improved your operation. It's moved the fire to a room with no extinguisher.
Here's what that looks like, with real numbers attached. Illustrative ones. Not a promise of what your line will see.
Say the signoff fix saves eleven minutes every changeover. Line 4 changes over four times a shift. That's close to forty-five minutes of extra running time, freed up every day.
Forty-five minutes of extra output has to land somewhere.
If the station right after Line 4 was already running close to its own capacity, that's exactly where it lands. As a growing pile of WIP. Or a labor shortage nobody budgeted for.
Three Ways a Bottleneck Can Move
A constraint doesn't just relocate. It relocates in one of three specific ways. Each one needs a different fix:
● Piling up: Work backs up in front of a station that can't absorb the new pace. You'll see WIP inventory growing where it didn't used to.
● Starving: A station upstream sits idle, waiting on work that isn't arriving fast enough anymore, because the whole line's rhythm just shifted underneath it.
● Getting stuck: Output has nowhere to go. A downstream buffer fills up. Everything behind it, all the way back through the line, grinds to a halt.
Knowing which of the three you're about to trigger changes what you do next.
A piling-up problem needs more buffer or more downstream capacity. A starving problem needs a scheduling fix. A getting-stuck problem needs you to look even further downstream, sometimes all the way to the loading dock.
Modeling the Ripple Before You Spend the Money
You can't walk the entire value stream in your head. Not reliably enough to predict where the next constraint lands.
Too many moving parts. Too much interaction between them.
This is where AI earns its keep.
Give it your process data. Cycle times, WIP limits, labor allocation, dock throughput, whatever you track station by station. Then ask a specific question: if Line 4's changeover time drops by however many minutes the fix saves, what happens everywhere else in the line, over the next shift, the next day, the next week?
This is sensitivity analysis. A standard tool in financial modeling that works just as well on a production line.
Change one input. Hold everything else constant. See what breaks.
AI can run that test across every downstream station in minutes, instead of the days it would take to model by hand. It can run it before you've spent a dollar changing the actual procedure.
The output you want isn't a single prediction. It's a ranked list: which stations are close to their own limit already, how much slack each one has left, and which one runs out of room first once Line 4 speeds up.
The Prompt: Model the Downstream Impact
Pull together the process data for Line 4 and every station immediately upstream and downstream of it. Hand it to an AI tool that can read files and run calculations, not just chat: Claude, ChatGPT with data analysis enabled, or similar. Adapt this prompt to your line.
1. Describe the Change, Not Just the Line
● State exactly what's improving, and by how much.
● Name the specific fix, the specific time or capacity gain, and which station it happens at.
2. Map the Flow
● List every station directly upstream and downstream of the one you're changing.
● Include each one's current cycle time, capacity, and any WIP or buffer limits between them.
3. Ask for the Failure Mode, Not Just the Number
● Don't just ask for a new throughput figure.
● Ask which specific station becomes the next constraint.
● Ask whether it fails by piling up WIP, running out of labor, or starving for input.
● Example instruction: “If Line 4's changeover time drops by 12 minutes, tell me which downstream station becomes the new limiting factor, and whether it's a WIP, labor, or dock capacity problem. Don't just give me a new throughput number.”
4. Test More Than One Scenario
● Ask for the same analysis at a partial version of the fix, and a best-case version.
● A constraint that migrates gently at a small improvement can migrate violently at a larger one.
5. Ask What Would Need to Be True to Avoid the Migration
● Have it identify the minimum change needed downstream to absorb the new pace without creating a fresh bottleneck.
● That could be an added shift, more buffer space, or a labor reallocation.
6. Rank the Risk, Not Just the Impact
● Ask it to flag which downstream station has the least slack today.
● That's the one most likely to become the next fire, regardless of exactly how the numbers land.
Run all six, and you'll know where to look before you spend a dollar changing anything.
What AI Can't Model for You
AI can run the math on cycle times and buffers faster than you ever could by hand.
It cannot see the informal workaround your receiving crew already runs to cover for Line 4's current slowness. The one that's not written down anywhere. The one that disappears the moment Line 4 speeds up.
It cannot walk the dock and notice that the real limit isn't truck capacity. It's one forklift operator who's been covering two roles since March.
The model tells you where to look. Your floor knowledge tells you what's there when you get there.
Next Up in the Series
Say the model shows dock capacity becomes the new limit, once Line 4 speeds up.
Before you roll the changeover solution out permanently, you need to prove that prediction holds up in the real world. Not just on paper.
Next up, we design the pilot test that does exactly that. Baseline, control variables, and a stop condition. So you know whether the fix worked, before you've committed to it everywhere. LINK: Your Pilot Isn't a Test: How AI Builds One that Actually Proves Something.
Subscribe to The Daily Constraint. It'll land in your inbox the day it goes live.
Run this model against your own line? Comment below. Tell me where the constraint landed. Not where you expected it to.
