Flow Improvement: Turn a Diagnosed Cause Into a Change Worth Piloting

Flow Improvement does one job. In the product's own words, it helps you identify flow improvements, including batch size reduction, FIFO lanes and pull mechanisms, to smooth the future state. It is a worksheet for the Improve phase of RDMAICS, and it assumes you already know what is wrong.

That assumption matters. Recognise told you the problem was worth attention. Define scoped it. Measure gave you the baseline. Analyse named the cause. Flow Improvement is the first place in the cycle where you commit to a change, and it asks you to name the mechanism that will carry the change rather than the intention behind it.

Reach for the tool when your diagnosed causes are structural rather than behavioural. If work sits in queues, piles up between steps, gets expedited past other work or loops back for rework, you have a flow problem. If the issue is a single defective input or a one-off supplier failure, a different tool will serve you better.

Every example here comes from the sample data that loads with the tool. The case is fictional. It exists so you can see the shape of a completed worksheet before you build your own.

The sample describes a process with four flow issues. Large batch approvals create a long queue and variability. Push-based dispatch causes work in progress to build up. Mixed priority flow produces starvation at some steps and expedite chaos at others. Rework loops disrupt flow wherever they land.

Four issues is a sensible size for a first worksheet. It is enough to show how the mechanisms relate to each other. It is small enough that a team can hold the whole picture in one conversation.

The worksheet has six columns. You number the row, name the flow issue, state its current impact, describe the improvement, name the flow mechanism and record the expected result. The discipline sits in the last three columns.

The improvement column is what you will do. In the sample, the four improvements are continuous flow approval, pull on demand, tiered lanes and an in-line quality gate. Each one is a change to how work moves, not a change to how hard people work.

The flow mechanism column is how the improvement is enforced. The sample pairs continuous flow approval with a FIFO pull lane, pull on demand with a kanban signal, tiered lanes with priority lanes and the in-line quality gate with stop-the-line. Naming the mechanism is the step most teams skip. Without it, an improvement is a wish.

The expected result column is where you size the gain before you commit. The sample records lead time down 50 per cent, work in progress down 60 per cent, on-time delivery up 20 percentage points and rework down 40 per cent. These are expectations, written down before the pilot, so the pilot can test them.

Consider row one. The flow issue is large batch approvals. The current impact is a long queue plus variability. A weak worksheet would stop at the improvement, continuous flow approval, and leave it there. The sample does not. It names a FIFO pull lane as the mechanism.

That one entry changes what you pilot. You are no longer piloting an intention to approve things faster. You are piloting a lane with a defined order, a defined entry point and a defined exit. You can observe whether the lane holds under load.

The same logic applies down the sheet. A kanban signal makes pull on demand observable. Priority lanes make tiered lanes a physical arrangement rather than a policy memo. Stop-the-line makes the in-line quality gate something with teeth.

The tool produces an improvement design flow from the worksheet. It lays the four improvements out in sequence, each one carrying its expected result, and links them with arrows. The output is labelled as built from the worksheet, and the sequence is taken from the current editable worksheet order.

That last point is worth pausing on. The order you type is the order you get. The tool is not optimising the sequence for you. It is making your implied sequence visible so you can argue about it.

In the sample, the chain reads continuous flow approval at lead time down 50 per cent, then pull on demand at work in progress down 60 per cent, then tiered lanes at on-time up 20 percentage points, then the in-line quality gate at rework down 40 per cent. The tool also offers an AI review that explains the result if you want a second read on the design.

The first decision is what to pilot first. The sequence gives you a default, but the expected results give you a basis to challenge it. Work in progress down 60 per cent is the largest single number in the sample. A team might argue that pull on demand should lead because it caps the system quickly.

The second decision is scope. Four rows is four pilots. You rarely have the capacity to run four at once. The worksheet lets you defend a decision to run one or two and park the rest without losing the analysis behind them.

The third decision is what evidence the pilot has to produce. Each expected result is a testable claim. If you pilot continuous flow approval through a FIFO pull lane and lead time does not move toward 50 per cent, you have learned something specific. You either implemented the mechanism poorly or the diagnosis was wrong.

The fourth decision is a handover to Control. The mechanisms you name here become the things Control has to hold in place. A kanban signal needs a rule for who replenishes it. A priority lane needs a rule for who assigns work to it.

The most common mistake is writing an improvement without a mechanism. Rows that say improve approvals or reduce work in progress look complete and are not. The sample avoids this in all four rows, and that is the standard to hold.

The second mistake is stacking expected results that depend on each other without saying so. In the sample, the rework reduction and the on-time improvement both affect flow at the same steps. If you pilot one, your baseline for the other moves. Record the order you intend to test in.

The third mistake is treating the expected results as commitments to a sponsor. They are hypotheses written before the pilot. Presenting lead time down 50 per cent as a promise rather than a target to test will damage trust when the pilot comes in lower.

The fourth mistake is skipping Analyse. Flow Improvement will accept any flow issue you type. It has no way to check that the issue you named is the cause of the problem you measured.

Flow Improvement does not validate your numbers. The expected results in the sample, including lead time down 50 per cent and work in progress down 60 per cent, are values a user typed. The tool arranges them. It does not model them, test them against your measured baseline or check whether they are achievable in your process.

It does not choose the sequence. The output states plainly that the order comes from the worksheet. If you type the rows in the order you thought of them, you will get a design flow in the order you thought of them, which may not be the order you should implement in.

It does not cost anything. There is no effort estimate, no resourcing view and no implementation calendar. A change that delivers rework down 40 per cent may take two weeks or two quarters, and the worksheet treats both the same.

It does not run the pilot and it does not hold the gain. Those belong to the later phases. What Flow Improvement gives you is a short, honest page that names four problems, four changes, four mechanisms and four sized expectations. That is enough to start an argument about what to pilot first, which is exactly the argument the Improve phase is for.