Why the same work ends up done differently
Suppose five offices each process supplier invoices. Nobody sat down and designed five methods. One office checks invoices against purchase orders before entering them; another enters first and checks later. One uses a paper stamp for approval, another an email thread. Over time, each way of working made sense locally, but the combined result is variation that is hard to train for, hard to measure and hard to improve.
Process standardization is the practice of agreeing on one documented way to carry out shared work and then using it across teams and locations. Its promise is efficiency: less rework, fewer errors, quicker training and easier comparison. Its risk is rigidity. This article covers both, and it is about designing the process itself. How software platforms automate it is a separate topic, covered under workflow automation.
What standardizing involves
A typical sequence looks like this:
- Map the current process. Ask the people doing the work to describe what really happens, including the unofficial steps. A map based on what a manual says should happen often misses the real practice.
- Find the variation. Compare how the teams do it. Note which differences are essential, perhaps reflecting local rules or customers, and which are habit.
- Agree the standard. Choose a common method, borrowing the best elements from each. Involve people from several locations so that the result is not simply the head office version.
- Document it. Write the steps clearly enough that a new person could follow them. Standard operating procedures are the usual format and have their own article.
- Name an owner. Someone should be accountable for the process and for changing it when needed.
- Measure and refine. Track whether the new method delivers what was expected, and adjust.
An illustrative worked example
The numbers below are invented to show the arithmetic. They are not benchmarks, and real results will differ.
Imagine four offices handling expense claims. Each office handles 200 claims a month, so 800 claims in total. Before standardizing, suppose the average handling time varies between offices: 12, 10, 15 and 11 minutes per claim.
Because each office handles the same number of claims, the overall average is the simple average of the four figures:
(12 + 10 + 15 + 11) ÷ 4 = 48 ÷ 4 = 12 minutes per claim.
Total handling time is 800 × 12 = 9,600 minutes, or 160 hours a month.
Now suppose the offices agree on one method, and after a settling-in period the average falls to 10 minutes per claim. Total time becomes 800 × 10 = 8,000 minutes, or about 133 hours a month. The difference is 1,600 minutes, or roughly 27 hours a month.
Several cautions apply even to this simple example:
- Averages hide spread. Perhaps the office at 10 minutes was already efficient and the standard slows it a little.
- Setting up the standard has costs: time to design it, train people and document it. Those costs need to be weighed against the monthly saving.
- A faster average is not automatically a better outcome. If error rates rise because checks were removed, the saving may be illusory.
- Time saved does not turn into money saved unless the freed time is actually used differently.
The example is meant to show how to reason about a change, not to predict one.
Where standardization helps
Standard processes tend to pay off for work that is frequent, similar across locations and rule-based. They can:
- reduce rework by making the common steps predictable
- speed up training, because there is one method to learn
- make quality and speed comparable between teams
- allow staff to cover for each other across locations
- provide a stable base for later automation, since a messy process automated is still a messy process
They also help when the organization needs consistent results, for example so that every customer receives the same treatment under the same rules.
The cost of rigid processes
Standardization is not free of harm, and the downsides are often underestimated.
- Loss of useful local variation. Some local methods exist for good reasons: a different customer mix, a local rule, a different tool. Removing them can make the work worse.
- Slow exceptions. If a standard has no route for unusual cases, staff either wait for approval or break the rules quietly.
- Compliance on paper. People may follow the documented steps while doing the real work elsewhere, which leaves leaders with a false picture.
- Stagnation. If the process is hard to change, improvement stops. A standard should be a current best known method, not a permanent one.
- Over-engineering. Detailed rules for low-value work can cost more than the variation they remove.
A standards exception process addresses part of this problem by giving teams a recorded way to depart from the standard when they have a good reason. Local input mechanisms, such as regular feedback sessions, help the owner learn where the standard no longer fits.
Deciding how much to standardize
A useful approach is to separate the parts of a process that must be identical from those that can vary. Outputs, control points and data definitions are often worth fixing, because other teams or systems depend on them. The internal method for an individual task is often better left to the people doing it, provided the results meet the standard.
Questions worth asking before standardizing include:
- How many people and locations does this process touch?
- How much do the current methods really differ, and does the difference cause harm?
- What would be lost if local teams could not adapt?
- Who will own the standard, and how will it be kept up to date?
Starting with one or two high-volume processes, measuring the effect and learning from the result is usually safer than a sweeping program. Standardization is one lever among several, and it works best when combined with clear ownership, honest measurement and a willingness to change the standard when the evidence calls for it.