How to standardize a business process
How to standardize a business process across teams or sites: map the variants, separate real differences from habit, agree one flow with defined exceptions, and control the version.
Standardising a process means mapping how each team really does it, separating genuine differences from habit, and agreeing one documented flow with named, permitted exceptions.
The short version
- Map the variants before designing the standard.
- Separate required differences from habitual ones; only the second kind is free to remove.
- Standardise the exception too: an undocumented workaround becomes the real process.
- One documented version, approved, with the differences recorded as named variants.
- A standard nobody can follow under pressure is not a standard.
Variation is not the same as disagreement
Standardisation usually starts from a real observation (three sites run the same process three ways, and the numbers differ) and then fails for a specific reason: it treats all the variation as waste. Some of it is. Some of it is a site with a different regulator, a different customer contract, or a genuine constraint the standard would break. Rolling out one process without separating those two kinds of difference is how a standard gets published, ignored, and quietly worked around.
So the first job is not designing the standard, it is mapping the variants side by side. Once they are drawn against the same steps, the differences fall into three piles: things that are genuinely required to differ, things that differ because of a local constraint that could be removed, and things that differ because somebody set it up that way in 2019. The third pile is usually the largest, and it is the only one that standardises for free.
The example below is a purchase requisition process, one of the most variation-prone processes in any multi-site organisation: everyone raises requisitions, and everyone has a different threshold, a different urgent route and a different opinion about what procurement needs to see. It contains an explicit fast-track branch, which is the right way to standardise an exception rather than pretend it does not happen.
A process built to vary
A purchase requisition flow with thresholds, a fast-track route and a specification loop: the three places variation hides.
The common trunk
Need identified, requisition raised with a specification, cost centre and GL code added. Almost every variant agrees on this much, and finding the shared trunk first is what stops standardisation becoming a negotiation over everything at once.
Where the thresholds live
Budget check, manager approval, then a value threshold routing to a second approver. Thresholds are the single most variable element between sites, and standardising them is a delegation-of-authority decision rather than a process one.
The specification loop
Procurement reviews and can return a requisition for clarification. Sites that skip this step have not removed the work: they have moved it to a phone call that leaves no record, which is exactly the kind of variation worth eliminating.
Standardise the exception, do not deny it
The urgent branch has its own justification decision, an emergency authorisation and a recorded fast-track rationale. Every organisation has an urgent route; the ones that pretend otherwise have an unrecorded one.
How it works
Map each variant as it is actually run
One chart per site or team, drawn from the people who do the work, not from the local procedure document. Variants documented from paperwork all look identical, because everyone copied the same template: the differences are in the practice.
Line the variants up against a common spine
Identify the steps every version shares and lay each variant against them. The comparison is what turns a general sense that "we all do it differently" into a specific list of differences, which is a much shorter and less contentious conversation.
Sort each difference into required, constrained, or habitual
Required means a regulator, contract or law makes it necessary. Constrained means a local system or resource forces it for now. Habitual means nobody remembers why. Get the owning site to justify each one: the sorting exercise usually resolves half the differences without a decision from anyone.
Design the standard around the required differences
Build one flow with explicit variant branches where the difference is genuine. A standard that ignores a legal requirement in one region will be broken in that region and will discredit the whole exercise elsewhere.
Document the exception route
Every process has an urgent path. Draw it, put criteria on it, name who authorises it, and require the justification to be recorded, as the example does with its fast-track branch. Undocumented exception routes expand until they are the process.
Publish one approved version and review the variance
Keep a single approved chart with the variants named on it, and review after a few months for the divergence that will have appeared. Standardisation is not a project that finishes; it is a version that has to be maintained, and the first sign of failure is a site with its own updated copy.
Mistakes to avoid
Standardising from the documents
Local procedures are usually copies of the same original. The variation is in what people do, which only interviews and observation will surface.
Treating all variation as waste
Some differences are required. Removing them produces a standard that one site cannot legally follow and everyone else stops trusting.
Ignoring the urgent route
Refusing to document the exception does not remove it. It removes the criteria and the record, which is the worst of both.
Publishing without a version
A standard with no approved current version becomes several standards within a year, each locally edited and each believed to be the one.
Standardize your own process
Open the requisition example as your own chart, then map each variant against it and mark what genuinely has to differ.
Related guides
Frequently asked questions
How do I standardize a process across multiple sites?
Map how each site actually runs it, compare the variants against a common spine, then sort every difference into required, constrained or habitual. Design the standard around the required differences and remove the habitual ones. The order matters: teams accept a standard that visibly accounts for their genuine constraints and reject one that appears to have been designed elsewhere and imposed, regardless of how good the design is.
What is the difference between standardization and centralization?
Standardisation means everyone follows the same process; centralisation means one team performs it for everyone. They are independent choices and are frequently confused, which makes the conversation harder than it needs to be. You can standardise a process that each site continues to run locally, and that is often the better first move: it captures most of the consistency benefit without the disruption and the loss of local knowledge.
How do I handle a site that genuinely needs to differ?
Draw the difference into the standard as a named variant branch rather than granting an exemption. A branch stays visible, gets reviewed with the rest of the process, and can be removed when the underlying constraint goes away. An exemption is invisible, unreviewed, and permanent, and it also invites every other site to ask for one.
How do you stop a standardized process drifting back?
One approved version people can reach, a named owner, and a periodic check for divergence. Drift is not usually rebellion; it is a local fix to a real problem that never made it back into the standard. Give sites a route to propose changes and act on it, or they will make the change locally and the standard becomes a document about the past.