What are business improvement techniques, and which one should you use first?

Most teams asking what business improvement techniques are are dealing with the same problems. 

Slow approvals. Duplicated work. Recurring errors. Unclear handoffs. 

Now, business improvement techniques are structured ways to find where work is unnecessarily slow, duplicated, inconsistent, or unclear, then make targeted changes to fix it. They range from simple methods like process mapping and root cause analysis to more established frameworks like Lean, Kaizen, PDCA, and Six Sigma.

The point is not change for its own sake. It is to make work easier to run, easier to measure, and easier for teams to follow.

This article is a decision guide. It does not just list methods. It helps you decide which one to use first, based on the problem you are facing.

What are business improvement techniques?

Business improvement techniques are structured approaches used to identify and fix inefficiencies, waste, duplication, poor handoffs, and unclear work. 

The more established concepts underneath it are business process improvement, continuous improvement, and process improvement methodologies.

And different techniques fit different problems. Process mapping helps when work is unclear. Root cause analysis helps when the same issue keeps returning. PDCA helps when you want to test a change safely. Lean helps when waste and waiting dominate. Six Sigma helps when a measurable process has unstable quality. SOPs and KPIs help when execution varies too much. These are not competing ideas. They are tools for different situations, and the best starting point depends on the friction in front of you.

The decision guide: which business improvement technique should you use first?

The best place to start is with the problem, not the method. That sounds obvious, but it is where many teams go wrong. They pick a framework because it sounds rigorous, or they buy software because it looks efficient, before they have defined what is actually slowing work down.

Start with visibility, recurring errors, bottlenecks, inconsistency, lack of measurement, or adoption problems. Then choose the method that matches that issue.

The UK Government's SME Digital Adoption Taskforce found in 2025 that UK SMEs invest less in technology and management than G7 peers, and that many firms overrate their readiness while still facing gaps in time, cash, and know-how. It also points to a pattern worth remembering: automating a broken process usually makes existing errors move faster rather than fixing them.

A simple way to think about the decision is this:

That is not a rigid formula. It is a practical starting sequence for teams with limited time and limited tolerance for disruption.

If the problem is slow or unclear workflow, start with process mapping

Process mapping is the best first move when work feels slow, inconsistent, or hard to follow across teams. It makes responsibilities, decision points, dependencies, and hidden delays visible. Many problems that look like poor performance are really poor visibility.

It is also a strong first step before automation or software changes. If you do not understand how work moves now, you are likely to automate confusion rather than remove it. Process mapping is especially useful when handoffs are weak, onboarding is difficult, or teams are preparing to adopt technology.

A practical example: a business discovers that customer orders take longer than they should because two manual approval steps still exist for low-value orders. The real issue is not speed in general. It is an outdated rule buried in the workflow. Once the process is mapped, the unnecessary step becomes obvious.

The main limitation is that process mapping can turn into an exercise in documentation rather than improvement. Over-mapping creates diagrams nobody uses. That is why it works best when tied to one important process and one clear decision.

If the problem keeps coming back, start with root cause analysis

Use root cause analysis when the same issue returns again and again, even after teams have "fixed" it. Symptoms are what you keep noticing. Root causes are what make those symptoms recur. The point of RCA is to stop treating repeated failure as a series of isolated incidents.

The two most relevant tools are 5 Whys and Fishbone. 5 Whys pushes a team to keep asking why until the likely cause becomes clearer. Fishbone helps when the issue is more complex and might involve several contributing factors. Both are useful. Neither proves anything on its own. RCA still needs evidence, data, or observation to confirm what is really happening.

One example: a finance team repeatedly correcting invoice errors. It looks like staff error until a root cause exercise shows that the real problem is a CRM field allowing free-text entry where a controlled dropdown should exist. Better checking was not the answer. Better process design was.

This is why RCA is a strong first technique for recurring issues. It helps teams stop spending energy on repeated cleanup.

If you need a low-risk way to test change, start with PDCA

PDCA stands for Plan, Do, Check, Act. It is a practical cycle for testing improvements on a small scale before rolling them out more widely.

This makes it useful when a team knows something needs to improve but does not want to commit to a full redesign before it has seen the result. You plan a change, try it, review what happened, and then either standardise it or adjust and test again. The method is disciplined without being heavy.

A simple example is piloting a new onboarding process with a small group before making it the default for everyone. That gives the team a baseline, a trial, and a review point. It also reduces the chance of scaling a flawed solution.

The risk is not the method itself. It is incomplete use of the method. Teams often rush through Check and Act, then call the pilot a success without enough evidence. That weakens the value of the cycle.

If the issue is waste, waiting time, or rework, start with Lean

Lean is best when work is full of waiting, excess steps, repeated checking, duplicated effort, or rework. In plain terms, it helps teams remove non-value-adding activity so more of the process actually contributes to the result. Lean is highly relevant to UK SMEs, though much of the strongest outcome evidence still comes from manufacturing.

A University of Liverpool systematic review of Lean in SMEs found it reduced flow time and improved on-time delivery. In one UK aerospace SME example, a Lean technique reduced build time by 20.5% and non-value-added time by 44.5%. Those are strong results, but they should be applied carefully, because they come from specific contexts rather than all SMEs everywhere.

A service-based illustration: a reporting workflow where most of the elapsed time is not work at all, but waiting for approvals, data, or sign-offs. That is a Lean problem. The team is active, but value is stuck in the queue.

The caution here is worth mentioning. Lean can be misapplied when it becomes a narrow efficiency exercise. Employee empowerment as a critical success factor in Lean for SMEs. If the method ignores the people doing the work, it can improve metrics while making work harder to sustain.

If you want steady improvement without a big programme, start with Kaizen

Kaizen is a good fit when the real goal is not one major redesign, but a steady habit of small improvements over time. It is built around regular, practical changes, often driven by the people closest to the work. Kaizen is practical, accessible, and well suited to teams that want progress without the weight of a formal transformation programme.

One example is a logistics team running a short weekly stand-up where staff can raise recurring friction points. Over time, small changes get tested and some are standardised. That is the strength of Kaizen. It lowers the barrier to improvement and helps teams build momentum through visible progress.

Kaizen can also help where resistance to large change is high. Smaller changes are easier to explain, easier to test, and easier to reverse. That makes them easier to adopt.

Still, Kaizen is not self-sustaining. It needs leadership consistency, feedback loops, and follow-through. Without those, it becomes a series of one-off suggestions rather than an improvement system.

If the process is measurable and quality is unstable, start with Six Sigma or DMAIC

Six Sigma and its core problem-solving model, DMAIC, are best used when a measurable process has repeated defects, inconsistent outputs, or too much variation. This is not usually the first method for every business. It is more useful when the process is stable enough to measure and important enough to justify a more data-heavy approach.

Consider an order-shipping process where 8% of orders go out with errors. DMAIC helps define the problem, measure the baseline, analyse likely causes, improve the process, and then control the new standard. In that example, most errors came from a single data-entry point. That made the case for a focused process fix rather than generalised training or more checking.

This technique is more resource-intensive than process mapping, RCA, or PDCA. It also fits process-heavy environments better than low-volume bespoke work. Six Sigma may be less appropriate for very small firms or project-based contexts with limited repetition. There is also mixed evidence on whether performance gains always translate into broader end outcomes.

That does not make Six Sigma a poor method. It just means it should be matched to the right kind of problem.

If the problem is one choke point slowing everything else, start with Theory of Constraints

Theory of Constraints is useful when one bottleneck is clearly limiting output. Its logic is simple. If one point in the system is constraining throughput, improving other areas first will not change much. TOC is a focused way to direct attention where it will have the greatest effect.

A practical example: a workflow that keeps backing up at senior approval. The team may be working hard everywhere else, but the bottleneck is still the bottleneck. In that case, the right first question is not how to optimise the whole process. It is how to reduce or redesign the choke point.

TOC is especially useful when the main constraint is obvious and measurable. Its limitation is that it can oversimplify businesses where several problems interact. There is not always one dominant issue in every system. That makes it a focused tool, not a universal answer.

If the issue is inconsistent execution, start with SOPs and KPI review

When work quality varies by person, when onboarding is slow, or when knowledge sits in people's heads rather than shared processes, SOPs are often the right place to start. Standard operating procedures help make routine work more consistent and easier to repeat. They are especially useful when the business wants to reduce variation without redesigning the whole system.

KPI review sits alongside that. If a team cannot see whether performance is improving, it cannot judge whether a change worked. The CIPD's People Management and Productivity report found that employers who measured productivity were 9 percentage points more likely to rate their productivity highly. The ONS Management and Expectations Survey also found that firms with below-median management scores were four times more likely to use little or no analysis in decision-making.

One example: a business where onboarding differs depending on who handles it. A short SOP reduces missed steps and shortens training time. Another is a retailer reviewing a few operational KPIs, then spotting that complaint resolution is being slowed by one approval bottleneck. Those are good examples because they show the value of consistency and measurement without turning either into a bureaucratic exercise.

The warning is that both tools can be overdone. Over-documentation creates manuals nobody reads. Too many KPIs create noise rather than clarity. The aim is enough structure to improve work, not paperwork for its own sake.

Start with one process, then build from there

The most useful conclusion from the evidence is that businesses do not need a large transformation programme to begin improving work. In fact, the evidence points the other way. A pilot study by The Productivity Institute and Be the Business tested whether a light-touch intervention could build a productivity habit in SMEs, and found that focused, practical approaches can be effective when they are tied to a real problem, a measurable baseline, and a practical test.

That means the first step is usually not to launch a company-wide initiative. It is to choose one high-friction process. Map the current state. Identify the likely cause of the issue. Measure a baseline. Test one change. Review the result. Standardise what worked. Then repeat. That sequence is a much more realistic way for most teams to improve than trying to fix everything at once.

So, which business improvement technique should you use first?

Start with the problem that creates the most friction. If you cannot see the workflow, map it. If the issue keeps returning, diagnose it. If the change feels risky, test it on a small scale. If work is full of waste and waiting, remove what is not adding value. If one bottleneck controls output, focus there. If execution varies too much, standardise and measure.

The right first technique is the one that helps your team understand the work clearly enough to improve it. That is usually where better operations begin.

If you are looking for a structured way to identify where operational friction is costing your team time and confidence, we can help you find the right starting point.


More Articles