Insights / Checklist / Business process reengineering (BPR)
ChecklistA four-week plan from diagnosis to redesign
Process redesign need not take months. A tight four-week plan keeps momentum, involves the people who do the work and ends with a tested flow.
Redesign need not take months. Long programmes lose sponsors, tire the people involved and often end with a report rather than a change. A tight four-week plan keeps momentum, engages the people who do the work and ends with something tested on real cases.
This checklist suits a single, bounded process: order to invoice, supplier onboarding, claims handling, month-end close. It assumes a small core team of three to five people who can give a few hours each day, a sponsor who can make decisions quickly and access to the systems and data the process touches.
Before you start: set the frame
Most redesigns that stall do so because the boundaries were never agreed. Spend a day before week one on scope, so the four weeks are spent on the process rather than on arguing about it.
- Name the process and its start and end points in one sentence.
- Agree one or two outcomes that matter, such as cycle time, error rate or cost per case.
- Appoint a sponsor who can approve changes within days, not weeks.
- Pick a core team that includes at least two people who do the work every day.
- Book the week-four pilot slot and the final review now, so the deadline is real.
Week one: understand
The aim this week is a shared, honest picture of how the process runs today. Not the version in the procedure manual, but the one people actually follow, including workarounds and spreadsheets on the side.
- Walk the process end to end with the people who do each step.
- Draw the current flow on a wall or whiteboard, one sticky note per step.
- Mark every handover, approval, wait and rework loop.
- Pull basic data: volumes, cycle times, error or rejection rates for the last three months.
- Collect five to ten real cases and trace them through every step.
Basic data is enough. If the systems cannot produce cycle times, sample twenty cases by hand and time-stamp them. A rough number that everyone trusts is worth more than a precise one that arrives in week six.
Week two: find causes
With the map in place, the team turns to why the process is slow, costly or error-prone. The trap here is to jump straight to solutions. Keep asking why until you reach something you can change.
- List every delay and error the map and data reveal.
- Estimate the impact of each: time lost, cost, customer effect.
- Rank them and pick the top three to five to address.
- For each, ask why at least five times to find the root cause.
- Separate policy causes, system causes and habit causes, because each needs a different fix.
- Share the ranked list with the sponsor and confirm the focus.
A typical finding is that a large share of the elapsed time is waiting, not working. Cases sit in queues between teams or wait for an approval that adds little. These are often the cheapest gains to capture.
Week three: design
Design the new flow with the team, not for them. People who helped shape a process are far more likely to make it work, and they will spot the practical problems a designer misses.
- Sketch the future flow, removing steps, handovers and approvals that do not add value.
- Decide who owns each step and what triggers it.
- Define the few measures that will show whether the new flow works.
- Note what must change in systems, forms or policies, and what can wait.
- Prepare simple one-page instructions for the pilot group.
Design for the pilot, not for perfection
If a change needs a system release, find a manual way to test the idea first. A shared tracker or a revised form can prove the logic before anyone writes code.
Week four: test
Pilot the new flow on a small set of cases, with a team that is willing to try it. Watch closely, fix what breaks and record the results against the baseline you set in week one.
- Run the pilot on a defined slice: one team, one region or one case type.
- Hold a short daily check-in to capture problems and adjust.
- Measure the same things you measured in week one.
- Gather feedback from the people running the pilot and from anyone downstream.
- Present results, open issues and a rollout recommendation to the sponsor.
What to expect at the end
Four weeks will not deliver a finished, fully automated process. It will deliver a tested design, evidence that it works on real cases, a list of system and policy changes and a team that owns the result. That is a far stronger starting point for rollout than a long diagnostic report.
Start by booking the sponsor review for the end of week four. Then work backwards, and protect the core team’s time as firmly as you protect the deadline.
Source: Intelliversal analysis.
