Do not answer the question as posed
Standardise or model the variation is a false choice, and the interviewer usually knows it. Standardising everything produces a to-be design that some branches cannot legally or practically follow, and they will revert to local practice within months while reporting compliance. Modelling all eleven produces a document nobody can maintain, a system with eleven configurations, and a change-impact analysis that takes a fortnight every time anything moves.
The answer that works is a common core with a small, named set of permitted variants, and the analytical work is deciding what goes in the core. That decision is made by classifying each variation by its cause, because cause determines whether the variation is legitimate.
Five causes, and only two survive
Regulatory or contractual difference is the strongest reason to keep a variant. A branch operating under a different jurisdiction, a different licence or a client contract with its own service terms is not being awkward. Confirm it against the actual rule rather than the manager's account of the rule, because "we have to do it this way" is sometimes a folk memory of an obligation that lapsed in 2019.
Genuine market or customer difference is the second legitimate cause. A branch serving corporate clients with a two-person team is not the same operation as one serving walk-in retail with fifteen, and forcing an identical process on both is how standardisation programmes get their reputation.
Workarounds for a defect elsewhere are the most interesting category, because the variation is a symptom. Two branches double-check a figure in a spreadsheet because a system field is unreliable in a way that only affects their product mix. Standardising the process without fixing the field removes the control and keeps the fault, which makes things actively worse. These variations should be recorded as the requirement they really are: fix the source, then the variation disappears on its own.
Historical accident and local preference is the largest category by volume and it has no defence beyond the fact that people are used to it. It is nearly always where the standardisation benefit lives.
Skill and capacity difference is the last. A branch with an experienced team skips a check that a branch of new joiners needs. That is not a process variation, it is a control that is being applied inconsistently, and it deserves an explicit answer about risk appetite rather than a modelling decision.
Check how much variation is actually there
Managers over-report their own distinctiveness, and system data will usually contract eleven processes into three. Do this before the workshops, because it changes what you are negotiating about.
A worked check, with the inputs stated. Take the case handling process and pull twelve months of case records: 33,000 cases across eleven branches. Count how many distinct sequences of recorded status transitions appear per branch. If nine branches share the same top three sequences covering 94 per cent of their cases, and two branches show a fourth sequence that accounts for 40 per cent of theirs, then the true picture is one core process, one genuine variant used by two branches, and a long tail of exceptions that everybody has. That is a much easier conversation than eleven, and you can put it on one page.
The measures worth pulling alongside are cycle time per branch, the proportion of cases that revisit an earlier step, and the number of distinct people touching a case. Those three tell you whether the variation costs anything, which is the question the sponsor will ask, and they occasionally show that the non-standard branch is the fastest one. That outcome is uncomfortable and it is the most valuable finding available, because it turns a standardisation programme into a rollout of the better practice.
Model the core and name the variants
The structure that survives is one core model with variation held at explicit, labelled decision points rather than smeared through the diagram. Concretely, the core process is modelled once, and at each point where legitimate variation exists there is a named branch with a stated condition and a stated owner. Something like: at the approval step, branches operating under the Scottish licence require a second authoriser, which is variant A-2, owned by compliance.
That form has three properties the alternatives lack. Change impact is answerable, because you can see which variants a change touches. The variants are countable, so the organisation knows it has four rather than a vague sense that everyone is different. And each variant has an owner, which means somebody has to defend its continued existence at the next review, and roughly half of them quietly will not be defended.
Keep the count low deliberately. A design with three variants can be trained, tested and configured. A design with nine is eleven processes with extra steps.
Say who loses
The failure that sinks standardisation is not analytical. It is that the model is correct and the benefit is entirely notional because nobody named the people it costs.
For each thing you propose to standardise, say who is worse off and by how much. A branch that currently batches its submissions once a day and will now submit per case gains nothing and takes on more interruptions. A branch manager who signs off locally and will now wait for a central team loses control over their own throughput and will be held to the same target. A team that has built its own spreadsheet loses a tool it prefers to the replacement. None of these are reasons not to standardise, and all of them are reasons the standard will not be followed if they go unaddressed.
The mitigations are usually small and specific: keep the batching where it costs nothing, give the central approval a service-level commitment the branch can hold you to, replicate the two features of the spreadsheet that mattered. Bringing those to the design conversation is what makes the difference between a design that is adopted and one that is complied with on paper. And with eleven branches, being able to say which two will resist and what would change their minds is worth more than the model itself.
Variation grows back
Eighteen months on, the variation reappears, because the conditions that produced it are still there: local pressure, an inflexible standard, and no route for a branch to get an exception approved. That last one is the real cause. A standard with no exception process forces branches to deviate silently, and silent deviation is exactly the state you were hired to fix.
So the design has to include the mechanism as well as the process: a way to request a variant, someone empowered to grant it, a register of granted variants, and a periodic review that removes the ones no longer justified. Proposing that unprompted is what separates a candidate who has run a standardisation programme from one who has drawn a to-be diagram.
Classify the variation by its cause before you judge it, and design a small core with named, owned variants. A standard with no way to request an exception does not remove variation, it makes it invisible.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).