Lean and Six Sigma Applied to Transaction Processing

Lean and Six Sigma arrived in finance departments in 2008 wearing a factory uniform, and the reception was predictable. Accountants pointed out that an invoice is not a piston, that no two vendor queries are identical, and that measuring defects per million opportunities in a process involving human judgement was a category error. They were wrong, but not for the reason the consultants said. The methods did transfer. What did not transfer was the assumption that the work being measured was necessary in the first place — and the programmes that failed in this period almost all failed by optimising activity that should have been deleted.

Why Transaction Processing Was Ready for This

By 2008, shared service centres had concentrated high volumes of repetitive finance work into single locations for the first time. That concentration created the precondition for industrial method: enough volume to measure, a single management chain, and a cost base visible enough that a board could see it. And the processes were genuinely defective in the manufacturing sense. Invoices arrived in multiple formats through multiple channels. Approval routing depended on tribal knowledge. Purchase orders did not match receipts. Data entry errors propagated into payment runs. Exceptions were handled by whoever noticed them. Cycle times varied enormously between identical transactions, which is the textbook signature of an unstable process. All of that is measurable, and once measured, most of it is fixable.

What the Methods Actually Contributed

Lean supplied the language for waste. Waiting, rework, over-processing, unnecessary movement of information, over-production of reports nobody read. In an accounts payable operation, waiting is usually the largest single component of cycle time, and almost none of it is caused by the finance team — it sits in approval queues. Making that visible changed the conversation from "the AP team is slow" to "forty percent of elapsed time is a manager not clicking approve." Six Sigma supplied variation control. The useful question is not the average processing time but the spread. A process with a three-day average and a twenty-day tail is two processes: one that works and one that does not. Finding what distinguishes them — usually a missing purchase order, an unregistered vendor or an unclear approval path — is where the improvement lives. Both supplied measurement discipline. Baseline first, change one thing, measure again. Finance functions were surprisingly unused to this; improvements were typically asserted rather than demonstrated. The documented results in finance operations are consistent rather than spectacular: lower cost per transaction, shorter and less labour-intensive processes, fewer errors and faster reporting. Unglamorous, compounding, and real.

The Failure Mode: Optimising the Unnecessary

The most instructive finding from this era came from peer research into shared services, which examined a capital planning and fixed asset process and discovered that roughly seventy percent of capital requests represented low-value spend running through the full approval process. The fix was not a faster approval workflow. It was two workflows — a light path below a threshold and the full process above it. That pattern repeats everywhere in back-office work:

• Three-way matching applied to every invoice regardless of value, when the cost of matching a small invoice exceeds the risk it carries
• Multi-level approval hierarchies that add signatures without adding scrutiny, because the fourth approver has never rejected anything
• Monthly reconciliations of accounts that have not moved in two years
• Reports produced on a schedule set by someone who left in 2014 A Lean project that makes each of these faster delivers a fraction of the value of simply stopping them. Ask what would break if the step disappeared before asking how to speed it up.

Where the Programmes Went Wrong

Belt inflation. Organizations trained large numbers of people in methodology and measured success by certifications awarded and projects opened. Neither is an outcome. The number that matters is validated savings or error reduction, confirmed by finance, twelve months later. Projects chosen for measurability rather than value. Teams gravitated to processes with clean data because they were easier to analyse, not because they mattered. Improvements that did not stick. Without a control plan, an owner and a metric on somebody's objectives, processes revert within two quarters. Reversion is the default state. Method theatre. Full statistical rigour applied to problems whose solution was obvious from a process walkthrough on day one. If a two-hour session with the people doing the work reveals the answer, do not spend eight weeks proving it. Improvement without the system. Redesigning a process that the ERP cannot support produces a documented ideal and an unchanged reality.

Doing This Well Today

The AI era has raised the stakes on exactly the same discipline, because automation multiplies whatever you point it at. Automating a fourteen-step approval chain preserves the fourteen steps permanently and removes the human friction that would eventually have forced someone to question them.

• Measure before you improve. Cost per transaction, cycle time distribution rather than average, first-pass yield, exception rate by cause, rework volume. Most finance functions cannot produce these today.
• Eliminate, then simplify, then automate — in that order. Deleting a step is free and permanent. Automating one is neither.
• Attack variation, not the mean. Work the tail. Find what the slow twenty percent have in common.
• Fix the upstream cause. Nearly all AP exceptions originate in procurement and vendor master data. Improvement work inside the finance team alone hits a ceiling quickly.
• Apply thresholds and risk-based controls. Different treatment for different value bands is not a control weakness; it is proportionate control design, and it usually releases the largest single block of capacity.
• Name an owner and a control metric. Every change needs someone accountable for the number staying improved, reviewed monthly.
• Keep the analysis proportionate. Walk the process, talk to the people doing it, use data to confirm rather than to discover the obvious.

The Durable Lesson

The methods outlasted the branding. Very few organizations now run formal belt programmes in finance, but the underlying practices — baseline measurement, variation analysis, root cause in the upstream process, control plans — are exactly what separates a shared service centre that improves every year from one that simply processes at a lower wage. And the central insight is the one that predates both methodologies: the fastest transaction is the one that never had to happen.

Common Questions

Do Lean and Six Sigma work in finance processes?

Yes. High-volume transaction processing has measurable cycle times, error rates and variation, and documented outcomes include lower cost per transaction, fewer errors and faster reporting. Judgement-heavy work benefits less.

What should we measure first?

Cost per transaction, first-pass yield, exception rate by root cause, rework volume, and the distribution of cycle time — not just the average.

Why do process improvements revert?

Because no one owns the metric after the project team leaves. Sustained improvement requires a named owner, a control measure and a regular review.

Should we automate or improve first?

Eliminate unnecessary steps, simplify what remains, then automate. Automating an unexamined process locks in its inefficiency and makes it much harder to question later.

---

Process Improvement Program — Outpace baselines your transaction processes, removes the steps that should not exist, and automates what remains — with control measures that keep the gains after the project ends.