Business process redesign, from first principles.

Why redesign comes first

Most processes were designed around the limits of their time. Forms existed because context was missing. Handoffs existed because systems did not talk to each other. Queues existed because nobody could see the whole workload at once.

Those limits have changed. Systems can now read a request written in plain language, check it against the rules of the business, carry out a bounded action and evaluate the result. If you automate the old process step by step, you keep the costs and delays that the old limits created, only faster.

Business process redesign starts from a different question. Not "how do we make these steps quicker?" but "which of these steps should exist at all?"

What business process redesign is, and is not

Business process redesign means rebuilding one recurring piece of work around the outcome it exists to produce. It is practical and bounded: one function, one owner, one measurable result.

It is not the same as:

• Automation. Automation makes existing steps faster. Redesign decides which steps deserve to survive. The two work best in that order.
• A new software tool. A tool can support a redesigned process. It cannot tell you what the process should be.
• A company-wide program. Large reengineering efforts tried to change everything at once. Redesign works one function at a time, so each change can be measured and trusted before the next.

This is the method behind what we build at vSplash.

The five steps

The method follows one sequence: know the work, rethink the work, run the work, prove the result, improve the work.

1. Know the work

Start with real transactions, not the official process map. Pull a few dozen recent cases and trace each one from start to finish.

For every case, write down:

• what started the work, and in what form it arrived
• which decisions were made, and on what information
• where information was missing, wrong or conflicting
• which handoffs added judgment or control, and which only moved information
• what "done" meant, and who checked it
• what the work cost in time, rework and attention

The aim is to describe the job independently of how it is organized today. This is the slowest step and the most valuable one. Our Feluda case study began here: years of close knowledge of production quality checking came before any system was designed.

2. Rethink the work

Now question every step against the outcome. For each one, ask:

• Does this step create value for the customer?
• Does it protect the business from a real risk?
• Or does it only exist to move or re-enter information?

Steps that only move or re-enter information are candidates to remove. Then ask the harder question: if you were designing this function today, with today's systems, what would it look like? Often the answer has fewer steps, fewer handoffs and a clearer point where a person makes the decision that matters.

Keep the controls that protect the business. Separation of duties, approvals for consequential actions and audit trails are part of a good design, not friction to remove.

3. Run the work

A redesigned process has to run every day, not just look good on a diagram. Decide explicitly:

• which actions the system can complete on its own
• which need a person's approval
• which must be escalated, and to whom
• what happens when information is missing or conflicting

Treat exceptions as part of the design from the start. Real operations are defined as much by the cases that do not fit as by the ones that do; we explore this in The exception is the real process.

4. Prove the result

Measure the old process before you change it. Without a baseline, there is no proof, only opinion.

Then compare the redesigned process on consistent measures:

• time from request to completed work
• share of work completed without intervention
• exception and rework rates
• errors that customers can see
• cost per successfully completed unit of work

Report the failures as well as the successes. A process that completes thousands of tasks but hides its failure modes has not earned trust yet.

5. Improve the work

Redesign is not a single project. Review the exceptions regularly: each recurring exception is either a rule to add, a decision to give to a person, or a sign that an earlier step needs to change. Over time the process gets simpler, not more complicated.

Choosing the first process

The best first candidate is not the most visible problem. It is the one where the result can be proved. Look for work that is:

• Recurring. It happens often enough that improvement compounds.
• Measurable. You can count volume, time, errors and cost today.
• Painful. It slows customers, distracts leaders or limits growth.
• Accessible. The inputs, systems and data can be reached.
• Owned. One person is responsible for the outcome and the budget.
• Bounded. A mistake can be caught and corrected before it causes serious harm.

Customer requests, intake, order handling, scheduling, quality checking and routine service updates often meet these tests.

An illustrative example

Consider a service business that receives change requests from customers by email. Today an account manager reads each request, rewrites it as a ticket, a production team makes the change, and a reviewer checks a sample before the customer is told it is done. Requests bounce back and forth when details are missing.

A redesign might interpret each request once, turning it into a structured instruction; check it against the customer's account and the business's rules; ask the customer a precise question when something is missing; make the change; check every change rather than a sample; and send only genuine exceptions to a person.

This is an illustrative pattern, not a prescription. The right design depends on the work, the risks and the economics of each business, which is why the first step matters most.

Common mistakes

• Automating the map instead of the work. The official process is rarely what actually happens.
• Skipping the baseline. Without "before" numbers, nobody can show the change worked.
• Measuring activity instead of outcomes. Tasks completed is not the same as problems solved.
• Removing judgment where it matters. Some decisions should stay with accountable people.
• Trying to redesign everything at once. One function, proved, earns the right to do the next.

Where AI changes the method

The steps are not new. What has changed is what the "rethink" step can now consider. Systems can interpret messy inputs, apply business rules, act within defined limits and evaluate every case instead of a sample. That makes it realistic to remove steps that previously existed only because people had to read, route and re-enter information.

It does not remove the need for judgment, accountability or evidence. The businesses that benefit most will be the ones that redesign the work first and then let intelligent systems run it, not the ones that attach AI to yesterday's process. For the companion argument, read What if the process itself is the problem?