Business Process Improvement: How to Improve Efficiency Without Optimizing the Wrong Things
Updated: Sep 22
A purchasing team lowers its transaction cost while operations waits longer for materials. A customer-service group shortens calls while repeat contacts rise. An approval process gets faster, yet customers still wait days for a result.
Those improvements are real. The purchasing team may genuinely have reduced its cost per transaction. The service center may have measurably shortened calls. The approval step may really be faster than it was before.
The problem is that improving part of a process does not guarantee that the process itself will perform better.
This is one of the harder problems in business process improvement because organizations naturally focus on what they can see. A backlog appears in one department, so the department looks understaffed. A step takes too long, so someone proposes automation. Errors surface in one part of the workflow, so they add new controls there.
Sometimes those responses are exactly right. But the place where poor performance becomes visible is not necessarily the place creating it, and even the cause of a visible problem may not be what is materially holding back the result that matters.
That distinction changes how process improvement should begin.
Before deciding what to fix, it helps to answer four questions: What needs to improve? Where is the process breaking down? What is actually holding the result back? And what would we expect to change if our intervention is right?
Those questions are simple. Keeping them separate is harder.
In this article, I use the word constraint in a broad operational sense: a condition that materially limits the result being pursued. A process may contain dozens of frustrations, defects, delays, and inefficiencies, but they do not all matter equally. Some make work unpleasant or unnecessarily complicated. Others influence lead time, throughput, quality, reliability, cost, or customer experience enough that changing them could materially change the result.
The job is to tell the difference.
Start With What Actually Needs to Improve
Suppose an internal approval takes ten days.
The natural response is to speed up the approval. The organization might automate routing, escalate overdue requests, add another approver, or impose a tighter turnaround target.
Any of those interventions could be useful. But they assume the approval itself is the problem worth solving.
Before redesigning it, there is a more basic question: what is the approval there to accomplish?
Perhaps it controls a serious financial risk. Perhaps regulation requires it. Perhaps it was introduced after a costly failure. Or perhaps it was added years ago to solve a problem that no longer exists and has simply remained in the workflow.
Those situations look similar on a process map, but they call for very different responses.
If the approval is necessary, its design may need attention. The approver may receive incomplete information. Requests may arrive in batches. Authority may be concentrated in one person. The approval may simply take too long.
If the approval no longer serves a useful purpose, however, making it faster only makes unnecessary work more efficient.
This is why business process improvement should begin with the result rather than the activity. Is the organization trying to reduce lead time, increase throughput, improve reliability, lower cost, reduce errors, strengthen risk control, or improve the customer experience?
Without that clarity, almost any local metric can look like success.
A process can become faster while becoming less reliable. It can become cheaper while creating more rework. One department can become more efficient while another absorbs the workload it shed.
Until the desired result is clear, improvement is difficult to judge.
Follow the Work, Not Just the Process Map
Once the result is clear, the next step is to understand where performance is actually breaking down.
Most organizations have a formal process and an operating process.
The formal process is captured in policies, procedures, workflow diagrams, system configurations, and training materials. The operating process is what people actually do to get the work through: extra emails, side conversations, shadow spreadsheets, informal approvals, duplicate data entry, reminders, workarounds, and calls to the person who knows what to do when the normal process fails.
People often treat those activities as exceptions to the real process. In many organizations, they are part of the real process.
Research on organizational routines has long examined the difference between formal descriptions of work and the patterns that develop in practice. A related problem, described by Robert Heath and Nancy Staudenmayer as coordination neglect, is the tendency to pay close attention to how work is divided while underestimating what it takes to integrate those pieces again.
That matters because many process problems emerge at the boundaries between activities, systems, and groups.
A department with a backlog may be receiving incomplete work from upstream. A team that appears slow may be spending much of its time correcting errors it did not create. Customer service may be handling exceptions generated by a policy established somewhere else.
The backlog or delay is still important. It tells you where to look. It doesn't tell you, by itself, what to change.
That is why useful process analysis follows the work from beginning to end. Where does it wait? What information is missing when it stops? Which handoffs create questions? Which exceptions consume disproportionate effort? Where is the same information entered twice? Which steps exist mainly because another part of the process cannot be trusted?
The people doing the work are especially valuable here. They know which approvals routinely stall, which reports no one uses, which inputs arrive incomplete, and which workaround prevents the process from falling apart.
Their experience is evidence, not the final answer. But ignoring it means ignoring much of the process that actually exists.
Find What Is Holding the Result Back
Now consider a request that requires twenty minutes of actual processing.
Before anyone touches it, the request waits four days for missing information. After someone processes it, it waits another two days for approval. An error then sends it backward for another day of correction.
Management reduces the twenty-minute processing step to fifteen minutes.
That activity is now 25 percent faster.
The customer still waits about a week.
The calculation is correct. Management genuinely improved the task. It simply improved a part of the process that contributed very little to the total delay.
This is the difference between processing time and lead time. Processing time measures the time spent actively doing the work. Lead time measures how long the work takes to move from beginning to end.
In administrative and service processes, a large share of elapsed time may sit outside the task itself: in queues, handoffs, approvals, missing information, batching, rework, and exceptions.
That changes the central question.
Instead of asking, “What can we improve?” ask, “What is materially holding back the result we care about?”
Almost everything in a process can be made better. That does not make everything equally important.
A condition deserves attention at the constraint level when three things are true. It has a credible connection to the result, its effect is large enough to matter, and it matters to the process as a whole rather than only to one local activity.
A confusing form, for example, is a problem. If it causes enough incomplete submissions to create substantial rework and delay, it may become part of what is limiting the process.
A slow employee may be a performance issue. That employee becomes a process constraint only when that person's capacity materially restricts what the process can produce.
An approval may be irritating without being important. It becomes more consequential when its timing, design, or authority begins to determine how quickly work can move.
This is also where constraint and root cause need to be separated.
A constraint answers one question: What is holding the result back?
Root-cause analysis answers another: Why is that happening?
Suppose incomplete purchase requests are materially delaying procurement. The incomplete requests may be the condition holding back lead time. But that still leaves a second question. Why are so many requests incomplete?
Perhaps the form is poorly designed. Perhaps employees do not understand the requirements. Different departments may use different standards. The software may allow required information to be skipped.
Those are possible root causes.
The distinction matters because it determines the order of the investigation. First establish what appears to be materially affecting the result. Then investigate why that condition exists deeply enough to determine what should change.
Otherwise, an organization can spend a great deal of effort fixing a legitimate problem that was never particularly important to the result it was trying to improve.
Treat the Change as a Test
Even a convincing explanation is still only an explanation until the intervention produces the expected effect.
Every process change contains an implicit prediction.
If staffing capacity is holding back throughput, adding capacity should increase throughput or reduce the relevant queue. If incomplete information is delaying approvals, improving that information should shorten the delay. If manual data transfer is generating errors, automation should reduce both the errors and the correction work they create.
That means one of the most useful questions to ask before implementation is: If we are right, what should change?
Answering that in advance prevents a common mistake: measuring whether the changed activity improved rather than whether the process improved.
Average call time can fall while repeat contacts rise. Utilization can increase while queues become longer. Cases closed per employee can increase while downstream rework grows.
Each of those measures may be accurate. None proves that the result that mattered actually improved.
The same issue appears frequently in automation.
Suppose employees manually copy information between two systems because the systems do not communicate. Automating the transfer may reduce delay and error, and that may be a worthwhile improvement.
But suppose the information is being entered only to support a report nobody uses. The organization may have successfully automated work that should have been eliminated.
Or consider an approval that takes three days. If the delay occurs because the approver overlooks requests, automated reminders may help. If the approver is waiting for missing information, reminders only speed up the notification system while leaving the real delay intact.
Implementation success and process improvement are not the same thing.
The test is whether the result improved and whether the burden declined, rather than shifting elsewhere.
A Purchase Request That Takes 12 Days
Consider a simple example.
A mid-sized organization takes an average of twelve business days to turn a purchase request into a purchase order. Because requests appear to be sitting in procurement, leadership concludes that procurement is overloaded.
The obvious options are to hire another buyer, establish tighter turnaround standards, or automate more of the purchasing workflow.
Instead, the organization follows the work from submission to purchase order.
The desired result is clear: reduce purchase-to-order time without weakening necessary financial and compliance controls.
The visible problem is also easy to find. Procurement has a large queue.
But when the team looks at what is actually happening inside that queue, the picture changes. Many requests arrive without information buyers need to process them: accounting information, supporting documentation, a sufficient statement of need, a complete vendor quote, or the appropriate approval.
A buyer opens the request, identifies what is missing, sends it back, waits for a response, and reviews it again. Some requests repeat that cycle more than once.
The procurement backlog is real. What it does not prove is that the organization needs more buyers.
When the team examines how the twelve days are spent, it finds that complete requests require relatively little buyer time. Much of the elapsed time comes from repeated review, correction, and waiting on incomplete submissions.
That makes incomplete requests important enough to investigate as a possible constraint on lead time.
Now root-cause analysis becomes useful.
Why are so many requests incomplete?
The review finds that requirements are scattered across different instructions. Employees interpret some fields differently. Departments have developed their own submission practices. The system also allows users to submit requests without several pieces of information procurement eventually requires.
That explanation points toward a different intervention than the one leadership initially considered.
The organization clarifies its requirements, simplifies guidance for common purchase categories, requires critical fields before submission, and changes the intake system so obviously incomplete requests do not enter the buyer queue as ready work.
Before implementing those changes, the team defines what it expects to happen. More requests should arrive complete. Returns for clarification should decline. Buyer rework should fall. Most importantly, purchase-to-order time should improve without adding buyer capacity.
If completeness improves but lead time does not, then the explanation was incomplete. Buyer capacity, approval authority, vendor response time, or another factor may still be governing performance.
The organization also has to watch for displacement. A cleaner procurement queue is not an improvement if employees now spend excessive time navigating a much more complicated submission process.
That is the framework in practice. The organization began with the result, traced the visible problem, identified what appeared to be holding performance back, investigated why it was happening, and defined what should change if the intervention worked.
That is a stronger basis for action than seeing a backlog and immediately hiring another buyer.
What This Adds to Business Process Improvement
None of the individual ideas in this article are new.
Lean has long emphasized flow and waste. Six Sigma provides structured problem-solving and measurement. Theory of Constraints focuses attention on what limits system performance. Root-cause analysis examines why problems occur. Process mapping and process mining help reveal how work actually moves.
The useful contribution here is the sequence.
Many process improvement methods become most valuable after an organization has already decided which problem deserves attention. The framework described here focuses on the decision just before that: how do we decide what is actually worth improving?
It separates several questions that often collapse in practice.
What result matters?
Where is the problem appearing?
What is materially holding that result back?
Why is that condition occurring?
What evidence would show that the intervention worked?
That separation matters because an observation can quickly turn into a solution.
A backlog becomes “we need more people.” A delay becomes “we need automation.” An error becomes “we need another approval.”
Sometimes those conclusions will be right. The point is to establish why before committing resources.
That is the framework's practical value. It sits between noticing that something is wrong and deciding what to do about it.
The standard at the end is equally straightforward: did the change make the process perform better in the way that mattered?
If it didn't, improving part of the process wasn't enough.
Comments