Bottleneck Elimination: Size the Gain Before You Commit to the Fix

Bottleneck Elimination sits in the Improve phase of RDMAICS. In the product's own words, it helps you identify and eliminate process bottlenecks through capacity, routing, and automation improvements. That is a narrow job, and the narrowness is the point.

By the time you open this tool, the hard diagnostic work should already be done. Measure told you where time piles up. Analyse told you why. Bottleneck Elimination is the step where a diagnosed cause becomes a proposed change, and where that change gets a number attached before anyone commits resources to it.

Reach for it when you have more candidate fixes than you have capacity to run. Teams rarely fail because they cannot think of improvements. They fail because they start four at once, finish none, and cannot tell afterwards which one moved the result. This tool forces a sequence.

Everything below is built on the sample data that ships with the tool. The case is fictional. It describes an invoice handling process with four known constraints, each already traced to a root cause.

The four bottlenecks are manual data entry, approval routing, the three way match, and filing and archival. Each row carries a root cause, a proposed elimination action, an estimated throughput gain, and a status. One row is already piloting. The other three are planned.

That shape matters. The tool is not a brainstorm sheet. Every line already has a cause behind it and an action in front of it. If you cannot fill both columns for a row, that row is not ready for this tool yet. Send it back to Analyse.

The worksheet asks for five things per row, and each one does work. Leave any of them vague and the ranking loses its meaning.

Look at how the sample rows are built. Manual data entry has the root cause recorded as staff capacity below volume. The elimination action is OCR automation. The estimated throughput gain is plus 300 per cent, and the status is piloting. That is a complete row. Cause, action, size, state.

Approval routing follows the same discipline. The root cause is a single approver working manually. The action is auto delegation plus thresholds. The gain is plus 150 per cent and the status is planned. The three way match row records manual verification as the cause, a rules engine as the action, plus 200 per cent as the gain, and planned as the status. Filing and archival records physical filing, auto archive on payment, plus 500 per cent, and planned.

Notice that the actions fall into the three categories the tool names. Capacity, routing, and automation. Auto delegation with thresholds is a routing change. OCR, the rules engine, and auto archive are automation changes. Naming the category helps later, because the risk profile of a routing change is different from the risk profile of a new automation.

The tool builds a chart from the worksheet and labels it bottleneck throughput gain. The highest quantified throughput gain is shown first, and status is retained in the worksheet rather than in the chart.

On the sample data the order runs filing and archival, then manual data entry, then the three way match, then approval routing. The scale runs from zero to 600. That ordering is the whole output. It reflects the plus 500 per cent estimate on filing and archival, the plus 300 per cent on manual data entry, the plus 200 per cent on the three way match, and the plus 150 per cent on approval routing.

The reordering is useful precisely because it does not match the worksheet order. In the table, manual data entry is row one and is already piloting. In the result, filing and archival comes first. The tool has no opinion about what you started. It only sorts by the size of the estimated gain.

An AI review is available alongside the chart to explain what the result shows. Use it as a second reading, not as a decision.

The first decision is sequence. You have four planned or piloting changes and limited attention. The chart gives you a defensible order to argue from. If you want to start somewhere other than the top of the chart, you now have to say why out loud, which is a healthy conversation to have before work begins.

The second decision is scope of the pilot. Manual data entry sits at plus 300 per cent and is already piloting. The pilot exists to test whether that estimate survives contact with real volume. Set the pilot up so it can answer that one question. If the measured lift lands well short of plus 300 per cent, you learn something about your estimating, which improves every row that follows.

The third decision is whether to proceed at all. A row with a small estimated gain and a large build effort is a candidate for deletion, not deferral. The tool does not hold effort, so you bring that judgement. Approval routing at plus 150 per cent is the smallest estimate in this set. That does not make it wrong to do. It makes it the one that has to justify itself hardest.

The fourth decision is about the Control phase that follows. Whatever you pilot, you will need a measure that proves the gain held. Deciding that measure while the change is still planned is far easier than retrofitting it later.

The most frequent error is treating the chart as a forecast of total process improvement. It is not. Each percentage describes a lift at one step. Removing the largest constraint moves the limit somewhere else. The second bottleneck does not disappear because the first one did.

The second error is filling the gain column with guesses dressed as estimates. If the plus 500 per cent on filing and archival came from a conversation rather than from observation, record that. An estimate you cannot trace is not evidence, and the chart will present it with exactly the same confidence as a measured one.

The third error is running every planned row at once. Three of the four sample rows sit at planned. The temptation is to start all three because they all look worthwhile. Resist it. Parallel changes contaminate each other's results.

Bottleneck Elimination will not validate your estimates. The plus 300 per cent on manual data entry and the plus 500 per cent on filing and archival are inputs. The tool reads them, orders them, and draws them. It has no way to check whether they are sound. The ranking is only as honest as the numbers you typed.

It will not weigh cost, build time, risk, or dependency. A rules engine for the three way match and an auto archive trigger on payment may differ enormously in effort, and nothing in the chart reflects that. It also will not tell you whether two actions conflict, or whether one must land before another can work.

It will not tell you where the constraint moves next. Once OCR automation removes the data entry limit, the process will have a new slowest step. Finding it means returning to Measure with fresh observations. The tool models the removals you have listed, not the ones you have not yet discovered.

Finally, it will not make the decision. The chart is an argument, well ordered and easy to read. You still choose what to pilot, you still decide what good looks like, and you still own the result. Use the tool to make the trade off visible, then take the choice yourself.