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.
A worked example, stage by stage
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.
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.