Standardising everything costs as much as standardising nothing, and most organisations do not know which of their variations are deliberate. Some exist for a real reason, some are required, and the rest are accidents nobody revisited.
This guide covers how to collect the differences without correcting anybody, how to sort them into those three groups, and why the third group is the actual standardisation work.
Key takeaways
- Three piles, not two: Real local reasons, legal requirements, and differences that exist because somebody left and nobody checked.
- The third pile is the work: Removing variation nobody can justify is the standardisation; the rest is what the system must allow.
- Standardise the rules you will encode: Agreeing every variation before a project starts is how a programme spends a year in workshops.
- Over-standardising hides the cost: Staff build workarounds, the data describes the workaround, and the reporting that justified the standard breaks.
Define the decision before comparing options
Write down what the business is selecting: a custom build, a configurable product, a hybrid approach, or a delivery partner for a known direction. Then state the outcome, protected constraints, unresolved assumptions, and evidence required before the next commitment. Without that frame, proposals can appear comparable while solving different problems.
For business process standardization, the aim is to decide which rules need consistency and where human judgment or local flexibility should remain. Ask every option to address the same representative journey, operating workflow, integration boundaries, quality expectations, and ownership after launch.
Trace one valuable process across customer contact, employee action, systems, decisions, and management review. Mark recurring delays, duplicate records, policy choices, and exception routes before deciding which layer should change.
Compare the same four capabilities
1. Common Rule
Name the rules that have to be identical everywhere and the reason each one does: a legal requirement, a financial control, a safety matter, or a promise made to customers. A site manager will accept a rule with a reason attached and work around one without.
2. Local Need
List the variations that exist because a location genuinely serves different customers, works under different regulation, or depends on a different supplier. These are not deviations to be corrected; they are requirements the standard has to make room for.
3. Exception
Collect the differences nobody can explain. Somebody left, a system changed, a decision was never revisited. This is normally the largest group and removing it is the standardisation work, so count it before anyone writes a specification.
4. Governance
Decide who may approve a new local variation, on what evidence, and when it is reviewed. Without that, the three groups above drift back together within two years and the next project finds the same picture.
Normalize proposals before comparing price
| Area | What to compare | Warning sign |
|---|---|---|
| Outcome | The user and business result the work is meant to improve | Success is described only as shipping features |
| Scope | Complete journeys, roles, operations, and failure paths | A screen count hides backend or staff work |
| Evidence | Prototypes, working slices, tests, and readiness reviews | Progress is reported only through hours or tickets |
| Commercials | Assumptions, exclusions, change model, and payment points | A low total depends on unstated happy-path assumptions |
| Ownership | Access, documentation, data, deployment, and support | Handover is deferred until the end |
Ask for evidence of the delivery approach
Use the portfolio as one signal, then investigate how the team frames uncertainty, produces evidence, and operates. Ask to see anonymized examples of a journey map, scope boundary, architecture decision, risk log, quality plan, or release-readiness review. The goal is not to collect documents; it is to understand whether decisions become visible and testable.
For a connected-product example, review How to Build a Digital Operating Model for Your Business and use the same customer-plus-operations lens when testing proposals.
Make commercial and governance responsibilities explicit
Launch responsibility belongs in the selection conversation, not in an end-of-project handover. Store accounts, cloud environments, analytics, support access, incident response, dependency updates, and roadmap review all need a named home. A partner may operate some of them, but the business should retain appropriate visibility and exit options.
Review risks before commitment
| Decision area | Risk to expose | Evidence to request |
|---|---|---|
| Common Rule | Unclear priorities | Request the assumption, an early validation step, and the decision that follows. |
| Local Need | Process drift | Confirm inclusions, dependencies, exclusions, and the commercial change rule. |
| Exception | Adoption gap | Review a failure scenario, quality evidence, owner, and proposed response. |
| Governance | Weak evidence | Verify access, documentation, handover, support, and a workable exit path. |
Credibility comes from exposing and reducing uncertainty, not promising that none remains. It shows how uncertainty will be reduced and how the roadmap can change without losing control of the outcome.
Run one reference scenario before the final choice
Give every shortlisted option the same realistic scenario involving common rule, a failure or exception around local need, and a business decision tied to governance. Ask each team to talk through the user experience, staff response, data movement, evidence, and tradeoffs. The exercise does not need speculative design work. Its purpose is to reveal how the team structures ambiguity, notices operating consequences, and communicates a decision.
Use a weighted scorecard without hiding judgment
Build a short scorecard for business process standardization using Common Rule, Local Need, Exception, and Governance. Give each criterion a plain-language definition and a weight tied to the business outcome. Score evidence, not presentation quality: a clear assumption and validation plan may be stronger than an unsupported promise.
Add a confidence column. A high score based on limited evidence should remain visibly different from a high score supported by working examples, references, or a credible delivery artifact. Record the reason for each score so the final decision can be explained and revisited.
Do not let the total make the choice automatically. Review deal-breakers, concentration risk, team chemistry, commercial constraints, and the cost of changing direction. The scorecard organizes judgment; it does not replace accountable judgment.
Before approval, ask whether the selected option gives the business a believable route to decide which rules need consistency and where human judgment or local flexibility should remain. If the answer depends on a major assumption, make its early test a condition of the next commitment.
A 30-day validation plan: Business process standardization
Days 1 to 5: collect the variations without judging them. Ask each site or team how they run the process and write down every difference. Do not correct anyone at this stage. The list is longer than head office expects, and the surprise is usually that two places doing it differently both believe they are following the standard. Ask how long each difference has been in place, because one that predates the current system is describing a need rather than a lapse.
Days 6 to 15: sort them into three piles. Separate the differences that exist for a real reason, the ones required by law or finance, and the ones that exist because somebody left. The third pile is normally the largest, and removing it is the standardisation work. The first pile is what the system must be designed to allow. Put a name against each pile, since a classification nobody owns is revised informally by whoever disagrees with it most.
Days 16 to 30: standardise one rule and leave the rest. Pick a single difference from the third pile, agree the common version, and apply it everywhere for two weeks. Count the exceptions that come back. If the exceptions are few, you have your method for the rest, and if they are many, that rule belonged in the first pile after all. Ask the sites what it cost them to comply, as a standard that is cheap at head office and expensive locally is the kind that quietly stops being followed.
A practical worksheet: Business process standardization
Standardising everything is as expensive as standardising nothing. Take one process that runs differently in several places and complete a row for each kind of variation you find.
| Decision area | What to record |
|---|---|
| Common Rule | What must be identical everywhere because of law, safety, finance, or a promise made to customers |
| Local Need | The variation that exists for a real reason, such as a different customer base, regulation, or supplier |
| Exception | The variation that exists because someone left and nobody revisited it, which is usually the largest group |
| Governance | Who may approve a new local variation, on what evidence, and when it is reviewed |
| Measurement | The number of active variations per process, tracked over time, so drift is visible before the next project finds it |
Sort the variations into those three groups before writing any specification. Most teams find the third group is the biggest, and removing it is the standardisation work, while the second group is what the system has to be designed to allow.
Related guides
- For what this looks like in practice, see Digital Transformation Roadmap: A 7-Step Business Guide.
- A second perspective worth having is Paperless Workflow: How to Digitize Paper-Based Processes.
Should When Should You Standardize a Business Process Before Digitizing It? turn into a plan with owners and dates attached, Discuss Your Digital Roadmap.
Ali Boran Gazel