Capacity Analysis: Size the Gain Before You Commit to a Pilot

Capacity Analysis does one job. It analyses current versus required capacity by resource to identify gaps and plan for demand. You list the resources that carry the work. You state what each one can do today. You state what demand requires. The tool calculates the gap and holds your intended action next to it.

The natural home for this tool is the Improve phase of RDMAICS. By the time you arrive here, you have already recognised a problem, defined its scope, measured the baseline and analysed the cause. You have a diagnosis. What you do not yet have is a change you can defend. Capacity Analysis is the bridge. It converts a cause into a sized change.

Reach for it when the cause you found is a throughput cause. If the analysis pointed at queues, backlogs, overtime or work that waits on one group, capacity is the language that explains it. Reach for it before a pilot, not after. The point is to know the size of the gain before you commit people and budget to testing it.

It also works as a planning tool for demand you expect rather than demand you have. If volume is going to rise, you can state the required capacity now and see which resources break first.

The case used throughout this guide is the sample data built into the tool. It is fictional. No real organisation, system or person is described. It is there so you can see the mechanics on a complete set of numbers before you load your own.

The scenario is an accounts payable process. Demand requires 90 invoices a day. That single figure sets the required capacity for every resource in the chain, because every invoice has to pass through each step. The worksheet lists four resources.

Two of them exist today. AP entry clerks handle 60 invoices a day. Approvers handle 40 a day. Two of them do not exist at all. An OCR system sits at 0. A match rules engine sits at 0.

That mix is deliberate and it is common. Real improvement cases usually contain a few resources that are stretched and a few that have not been built yet. Capacity Analysis is comfortable with both, because the arithmetic is the same either way.

The worksheet is editable and each row is one resource. Keep the resource specific enough that a single capacity figure makes sense for it. A row called AP entry clerks works. A row called the finance team does not, because the finance team does several different kinds of work at several different rates.

Use the same unit across every row. In this case the unit is invoices per day. Mixing units inside one worksheet is the fastest way to produce a gap figure that means nothing. If one resource is measured in hours and another in items, convert before you type.

Enter current capacity as what the resource actually delivers, not what it is rostered to deliver. For a resource that does not exist yet, enter 0. That is what the OCR system and the match rules engine show in the sample.

Enter required capacity as the demand the resource has to meet. In this example all four rows read 90 a day, because the demand is 90 invoices a day and all four steps sit in series. If your process branches, required capacity will differ by row, and that is fine.

The tool calculates the gap for each row. AP entry clerks show a gap of -30. They can do 60 and 90 is required. Approvers show -50. They can do 40 and 90 is required. The OCR system shows +90 and the match rules engine shows +90, because each one has to supply the full 90 a day that is currently supplied by nothing.

Read the negative figures as shortfall in existing resources. Read the positive figures as capacity you have to create. Both are gaps. The sign tells you which kind of problem you are holding.

Now compare the two shortfalls. Approvers are short by 50. Clerks are short by 30. The approver gap is the larger of the two. That ordering matters, because it tells you where a pilot has the most room to move. A change that fixes clerks and leaves approvers untouched still leaves a shortfall of 50 standing in the way of 90 a day.

The action column is where you record what you intend to do about each gap. In the sample, OCR automation covers the clerk gap. Auto-delegation for 70 percent of volume addresses the approver gap. The OCR deployment is listed with a capacity of 200 a day against a requirement of 90. The rules engine is simply listed for deployment.

The result view plots current capacity against required capacity for every row, labelled by the action you entered. The values are parsed from the editable worksheet and blanks are excluded, so what you see is built directly from what you typed.

The visual effect is the point. Two bars sit partway up the scale and two sit at zero, while the required line sits at 90 for all four. You do not have to read the arithmetic to see which resources are nowhere near demand. The two rows at zero are the two that do not exist yet.

The tool also offers an AI review of the result. Treat it as a second reader. It explains what the chart is showing. It does not replace your judgement about whether the actions you entered are the right ones.

Keep the chart with the worksheet when you present this. The chart carries the shape of the problem. The worksheet carries the detail that a reviewer will ask about.

The first decision is whether a pilot is worth running at all. You can answer that from the gap column. If every resource already meets demand, there is no capacity case and the cause you diagnosed lies somewhere else. In the sample, two resources are short and two do not exist, so there is clearly something to test.

The second decision is scope. You now know the pilot has to address the approver gap of 50 as well as the clerk gap of 30. A pilot that only automates entry does not reach 90 a day. The worksheet makes that visible before you write the pilot plan.

The third decision is headroom. The OCR deployment is recorded with a capacity of 200 a day against a requirement of 90. That is a specific, checkable claim about what the new resource gives you. Record it in the action column so the reviewer can test it rather than guess at it.

The fourth decision is sequence. Two of the four rows need a system that does not exist. Those rows carry build lead time that the two staffing rows do not. Reading the worksheet left to right tells you what has to be ready before the rest of the change can land.

The most common mistake is entering theoretical capacity as current capacity. If you write down what the roster says rather than what the process delivers, every gap in the sheet shrinks and the pilot looks smaller than it is. Use observed output.

The second mistake is leaving out the resources that do not exist yet. People sometimes list only the people and systems they already have. The sample does the opposite. It puts the OCR system and the rules engine on the sheet at 0, which is why their full requirement of 90 a day appears as a visible gap rather than an assumption.

The third mistake is writing vague actions. An action of improve throughput tells a reviewer nothing. Auto-delegation for 70 percent of volume tells them what is being changed and how much of the work it touches. Specific actions can be piloted. Vague actions cannot.

The fourth mistake is changing the required capacity figure to suit the answer you want. Required capacity comes from demand. If demand is 90 a day, every row in series reads 90, whether or not that is comfortable.

Capacity Analysis will not tell you whether your actions will work. It records that OCR automation is intended to cover the clerk gap. It does not verify that it will. That is what the pilot is for, and the pilot is a separate piece of work.

It will not tell you about cost. There is no price in the worksheet. A change that closes a gap of 50 may cost more than the gap is worth, and nothing on this screen will warn you.

It will not model time. Every figure here is a steady state rate. The sheet does not know that a system takes months to deploy while a delegation rule takes days. It does not handle peaks, seasonal spikes or the backlog that built up before you started.

It will not model dependency. The tool treats each row on its own. It does not know that the rules engine only helps if the OCR system runs first. You hold that knowledge, and you have to carry it into the pilot plan yourself.

Used inside its limits, it does the one thing the Improve phase needs. It takes a diagnosed cause and gives you a sized, visible, checkable gap. That is enough to decide what to pilot, and enough to know what good looks like when the pilot reports back.