Process Redesign: Turn a Diagnosed Cause Into a Change Worth Piloting

Process Redesign is an Improve phase tool. In its own words, it exists to document the redesigned process logic, decision rules, and exception handling for the future state. That is a narrow job, and the narrowness is the point. The tool does not help you find a cause. It helps you turn a cause you have already confirmed into a described change that somebody can build, test and measure.

You reach for it after Analyse has closed. By then you should know which step carries the delay, which step carries the defect, and why. If you are still arguing about the cause, the redesign will be a wish list. Every row you write will be a guess dressed up as a design.

The second signal that you are ready is that you can state a benefit for each change in the units your measurement system already uses. Minutes. Percentage points. Hours. If you cannot express the benefit in a unit you are already tracking, you will not be able to tell whether the pilot worked. The tool pushes you towards this by giving every row a benefit field and nothing else to hide behind.

Used well, Process Redesign produces the document you take into a pilot scoping conversation. It shows the current state, the proposed state and the expected benefit side by side, so the person approving the pilot can see exactly what changes and what is claimed for each change.

The example 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 shape of a completed worksheet before you attempt your own.

The case covers an accounts payable process with five elements. Invoice receipt. Data entry. Three-way match. Approval. Exception handling. That sequence is familiar enough that you can follow the logic without domain knowledge, and it is broad enough to show four different change types in one worksheet.

What makes it a useful teaching case is that the five rows are not all the same kind of change. One step is automated. One step is eliminated entirely. One step is streamlined. One step is standardised. A redesign that only ever automates is usually a technology project wearing a process improvement badge. A redesign that uses four change types across five steps is far more likely to have been thought about.

The worksheet asks for five things per row. The process element, the as-is state, the to-be state, the change type, and the benefit. Keeping every row to that discipline is what makes the output readable later.

In the sample, invoice receipt moves from email plus manual entry to a portal with OCR auto-ingest. The change type is Automate and the benefit is cycle time reduced by 23 minutes. Data entry moves from manual keying to auto-populate from OCR. The change type is Eliminate, because the keying step disappears rather than being done faster, and the benefit is an error rate reduction of 27 percentage points.

Three-way match moves from manual verification to an automated rules engine, typed as Automate, with match time reduced by 14 minutes. Approval moves from manual routing to tiered auto-delegation, typed as Streamline, with approval delay reduced by 3 hours. Exception handling moves from ad-hoc to a queue with SLA routing, typed as Standardise, with the benefit recorded as visibility and accountability.

Note what the as-is column is doing. It is short. It is factual. It is not a complaint. Write the current state the way an observer would describe it, not the way a frustrated user would. The redesign case is made by the comparison, not by loading the language in the left-hand column.

The tool builds the result directly from the worksheet. It presents each element as a current state, an arrow, a future state and the expected benefit underneath. The header labels it as built from worksheet, which is a reminder that nothing in the output has been added for you.

Read it in two passes. The first pass is vertical. Scan only the benefit lines. You will see cycle time down 23 minutes, error rate down 27 percentage points, match time down 14 minutes, approval delay down 3 hours, and visibility and accountability for exception handling. Four quantified benefits and one qualitative one. That ratio tells you how much of this case can be defended with numbers.

The second pass is horizontal. Take each row and ask whether the stated future state can plausibly produce the stated benefit. Auto-populating from OCR removing manual keying producing an error rate change of 27 percentage points is a claim you can test. A queue with SLA routing producing visibility and accountability is a claim you can observe but not count in the same way. Both are legitimate entries. They are simply different kinds of evidence.

The tool also offers an AI review that explains the result in narrative form. Treat it as a second reader rather than as a verdict. The value of the review is that it reads the worksheet as a whole, which is something you stop being able to do once you have written it yourself.

Sizing is the step most teams skip. They design the future state, like it, and go straight to build. The worksheet makes sizing possible because the benefit sits on the row rather than on the project.

Start with the quantified rows. Three of them are time based. Invoice receipt saves 23 minutes. Three-way match saves 14 minutes. Approval saves 3 hours of delay. Those are not the same kind of number. The first two are handling time, which is effort you can redeploy. The third is elapsed delay, which improves the experience of the process without necessarily freeing anyone up. Keep those two categories separate when you build the case, because mixing them produces a saving figure that will not survive scrutiny.

Then take the quality row. An error rate reduction of 27 percentage points is a defect claim, not a time claim. Its value flows through rework avoided downstream. You cannot convert it into hours without a rework cost you have measured separately, so leave it stated as it is rather than guessing at a conversion.

Finally, size the pilot itself. You have five elements and four change types. You do not have to pilot all five at once. The exception handling row, with its qualitative benefit, is often the cheapest to stand up and the fastest to show behaviour change. The automation rows usually need the longest lead time. Sequencing the pilot by cost and lead time rather than by row order is a decision the worksheet makes visible.

Process Redesign is a decision document, not a record. The decisions it is built to support are specific, and it helps to know them before you start filling cells.

The first is scope. Looking at the five rows together, you can decide which belong in the pilot and which wait. The second is sequence. Automating three-way match before data entry auto-populates would mean the rules engine reads keyed data, which weakens the match benefit. The worksheet makes that dependency visible because both rows sit on the same page.

The third is the measurement plan. Each quantified benefit implies a measure you must be able to capture before and after. Cycle time. Error rate. Match time. Approval delay. If you cannot capture one of those today, that is a Measure phase gap you need to close before the pilot, not after.

The fourth is the control plan handover. The exception handling row, with its queue and SLA routing, is already describing a control. Rows like that flow naturally into the Control phase because they create the visibility the control will rely on.

The most common mistake is writing a to-be that names a technology rather than describing behaviour. Portal plus OCR auto-ingest works because it says what happens to the invoice. A row that only names a platform tells you nothing about the process logic you are supposed to be documenting.

The second mistake is mislabelling change type. Teams label almost everything Automate because it sounds decisive. In the sample, data entry is typed as Eliminate, and that is the honest label, because the manual keying step ceases to exist. Eliminate and Automate carry very different risk and very different benefit profiles. Getting the label right changes how the pilot is designed.

The third mistake is inventing a number to fill the benefit field. The exception handling row records visibility and accountability rather than a figure. That is the correct behaviour. A qualitative benefit stated plainly is more useful than a fabricated percentage, and it is far easier to defend when somebody asks where the number came from.

The fourth is leaving exception handling out altogether. A redesign that only describes the happy path will fail the first time reality deviates. The tool asks for exception handling explicitly for that reason.

Process Redesign will not tell you whether your diagnosis was right. Every row inherits the quality of the Analyse phase that preceded it. If the cause was wrong, the worksheet will describe a well-formed change to the wrong step, and nothing in the output will warn you.

It will not validate your benefit figures. Cycle time down 23 minutes, error rate down 27 percentage points, match time down 14 minutes and approval delay down 3 hours are estimates you entered. The tool arranges them. It does not check them against data, and it does not test whether they are achievable. Treat every one of them as a hypothesis the pilot exists to confirm.

It will not cost the change. There is no field for implementation effort, licence cost, training load or lead time. A row that saves 14 minutes and a row that saves 3 hours look equally weighted on the page even if one takes a week to build and the other takes six months. You need a separate costing conversation before you choose what to pilot.

It will not sum the benefits for you, and you should be cautious about doing that yourself. The time figures mix handling time with elapsed delay, and the quality figure is in a different unit entirely. Adding them produces a headline number that misrepresents all three.

Finally, it will not manage the change. Documented process logic is necessary and not sufficient. People have to be told, trained and supported, and the exception queue has to be staffed. The worksheet gives you the design. The rest of the Improve and Control phases give you the adoption.