Why order matters
Organizations rarely centralize everything at once, and few should try. Each function brings its own people, systems and habits, and moving several at the same time stretches the team doing the work. Centralization sequencing is the practice of deciding which functions go first, which wait, and which may never move.
A poor first choice can be costly. If the first function is contentious and hard, the project may lose goodwill before it shows any benefit. If it is trivial, nobody learns anything useful. A reasoned ranking helps you choose a first step that is both achievable and worth taking.
Three lenses for ranking
A practical ranking looks at each candidate function through three lenses: how standardizable it is, how risky it is, and how much it varies locally.
Standardization potential
Some work is naturally uniform. Payroll runs, invoice processing and password resets follow similar steps in most units. When the work is already close to identical, a central team has little to reconcile and benefits from process standardization.
Work that depends on local relationships, local rules or individual judgment is harder to standardize. Forcing it into a single process often produces workarounds, which defeats the purpose.
Questions to ask:
- Do units already perform this work in broadly the same way?
- Could a written procedure describe it without many exceptions?
- Is the output meant to be the same everywhere?
Risk
Risk cuts both ways. Some functions carry risk that centralization reduces, such as security controls or financial reporting where inconsistency itself is a problem. Other functions carry risk if centralized badly, such as anything tied to urgent customer service or safety.
Consider two kinds of risk separately:
- The risk of leaving it as it is. For example, inconsistent controls or duplicated records.
- The risk of the change itself. For example, disruption while staff and systems move, or creating a dependency that is hard to recover from.
A function with high risk if left alone and manageable risk during the move is a strong early candidate. A function where the move itself is dangerous may need more preparation or a different approach.
Local variation
This lens asks how much legitimate difference exists between units. Different languages, regulations, customer types or product ranges are real reasons for variation. Differences that exist only because nobody ever aligned them are not.
The hard part is telling the two apart. A useful test is to ask the unit why it works that way. If the answer points to a customer, a rule or a market, the variation probably matters. If the answer is “it has always been done like this,” it may be a candidate for alignment.
A simple scoring illustration
Scoring can make the discussion more concrete, provided everyone remembers it is a conversation aid and not a formula that decides for you. The numbers below are invented for illustration.
Score each function from 1 to 5 on each lens, where a higher score means a stronger case for centralizing. For local variation, a high score means low legitimate variation.
| Function (illustrative) | Standardization | Risk benefit | Low local variation | Total |
|---|---|---|---|---|
| Payroll processing | 5 | 4 | 4 | 13 |
| IT help desk | 4 | 3 | 4 | 11 |
| Local sales promotions | 2 | 1 | 1 | 4 |
Adding the three scores gives 13 for payroll (5 + 4 + 4), 11 for the help desk (4 + 3 + 4) and 4 for local sales promotions (2 + 1 + 1). In this made-up example, payroll ranks first and sales promotions last.
You can weight the lenses if one matters more. An organization with serious control concerns might double the risk column. Whatever you choose, write the weights down and apply them to every function, so the ranking is something people can question.
Adding practical factors
Scores alone leave out things that affect whether a move will work.
- Readiness of people. A function with a willing, capable receiving team is easier than one with no obvious owner.
- Dependencies. Some functions rely on others. Moving a function that depends on unfinished data work may stall.
- Visible benefit. An early success that others can see builds support for later steps, which is useful when you later face change resistance.
- Reversibility. Prefer early moves that you could unwind without great damage, in case the result disappoints.
- Available capacity. Be honest about how much change the organization can absorb at once.
It also helps to talk to the people affected before the ranking is final. A stakeholder mapping exercise can reveal who gains, who loses and who needs convincing for each candidate.
Treating the first move as a test
Many organizations treat the first function as a pilot. They move it, measure what happened and adjust the approach before the next one. Setting a performance baseline beforehand makes it possible to judge honestly whether the move helped, rather than relying on impressions.
If results are mixed, that is useful information. It may suggest slowing down, changing the design, or deciding that a function suits a different model from the one you assumed. Some functions end up better left with the units, or shared in a lighter way, and that is a legitimate outcome rather than a failure of the plan.
Keeping the ranking alive
A ranking made at the start will age. Markets change, systems are replaced, and what looked uniform may turn out to have hidden local needs. Revisit the order as you learn, and be willing to drop or defer items. The aim is not to centralize as much as possible but to centralize what benefits from it, in an order the organization can manage.