The delay is not the work. It is the waiting.
Measure almost any business process and the same thing shows up: the work takes hours and the process takes days, because most of the elapsed time is a document sitting in somebody's inbox. This programme goes after the waiting rather than the working.
Measured before and after·Approvals by rule·Exceptions reach people
What this is for.
Choose this when the systems are broadly right but the process between them is not — when the delay is structural rather than technical.
Elapsed time dwarfs working time
Four days to approve something that takes eleven minutes to check, and nobody can say where the other three days went.
The process lives in inboxes
Approvals are emails, the status is a reply-all, and finding out where something is means asking three people.
Rekeying between systems
The same figures typed into two systems by a person whose actual job is something else.
Month end takes a fortnight
Not because the work is hard, but because it is sequential and every step waits on the one before.
How the work runs.
Short and evidential. The measurement at the start is what makes the argument at the end, and it is the step most often skipped.
- 01Weeks 1–2
Measure
Instrument the process as it runs today and find where the elapsed time actually goes. It is almost never where people expect, which is exactly why this phase is not optional.
What exists at the end of it
- Cycle time and touch time, separated and measured
- Every handoff and queue in the process, counted
- Rework rate and its causes, ranked by frequency
- The three steps carrying most of the delay, named
- 02Weeks 2–3
Redesign
Remove steps before automating them. An automated approval that should not exist is still a step, and automating waste makes it permanent.
What exists at the end of it
- Steps eliminated, listed with the reasoning
- Approval thresholds set by value and risk, not by habit
- Parallel paths where the process was needlessly sequential
- The target design, with the expected cycle time stated
- 03Weeks 3–6
Build
Workflow, routing, escalation, and the integrations that stop the rekeying. Rules act on the document itself rather than sending a notification about it.
What exists at the end of it
- Multi-step workflow with conditions and escalation
- Routing by value, dimension, and role
- Integrations replacing every rekeying step found
- Exception handling that reaches a named person
- 04One period after go-live
Prove
Re-measure against the phase-one baseline on the same process and the same definitions. The result is a number rather than a view.
What exists at the end of it
- Cycle time re-measured against the original baseline
- Exception volume and where it concentrates
- The remaining delay, named and attributed
- The next process, scoped from the same evidence
The processes this usually starts with.
Ordered by how much elapsed time they typically carry, and by how easy it is to prove the change. The first one is chosen to be provable, not to be impressive.
Purchase to pay
Requisition, approval, order, receipt, and the three-way match. Usually the longest chain in the business and the easiest to measure.
Order to cash
Quotation, credit check, order, delivery, and invoice — with the delay usually sitting in credit release and in delivered-but-unbilled.
The employee processes
Leave, expenses, timesheets, onboarding, and offboarding. Individually small, collectively enormous, and universally disliked.
Period close
Reconciliation, accruals, deferrals, and the checklist. Made parallel where it was sequential, and prepared before the period ends rather than after.
What you get.
The measurable ones are first, because they are what the programme is actually judged on.
- Before and after, on the same definitions
- Cycle time, touch time, handoff count, and rework rate, measured the same way at both ends.
- Workflow acting on documents
- Approvals, routing, and escalation running on the record itself rather than as notifications about it.
- Thresholds set by value and risk
- So that the routine passes straight through and attention goes to the things that need it.
- The rekeying gone
- Integrations replacing each place where a person was retyping the same figures into a second system.
- Exception handling with owners
- Every exception route ends at a named person with the context already assembled, not at a shared mailbox.
- A repeatable method
- Your team measuring and redesigning the next process, using the same approach on their own.
The terms this programme runs on
- Baseline
- Measured before any change, on the live process
- Order
- Steps removed before anything is automated
- Approvals
- By value and risk, acting on the document itself
- Exceptions
- Routed to a named person with the context attached
- Proof
- Re-measured one period after go-live, same definitions
- Handover
- The method transferred, not just the configuration
What this programme is usually pointed at first.
Next step