The core question
When a business grows from one location to several, each site starts to develop its own habits. Some of that is healthy: the people at each branch know their customers and conditions. Some of it is wasteful or risky: five sites keeping five different customer lists, or each setting its own approach to security.
Multi-site operations call for a deliberate line between what is done the same way everywhere and what each site decides. Neither extreme works well. Total uniformity ignores real differences between sites; total independence duplicates effort and makes the business hard to see as a whole.
Criteria for deciding
Rather than asking “what should be central?” in the abstract, it can help to test each practice against a few questions.
Does inconsistency create risk for the whole business? Financial records, access to systems, safety rules and legal compliance are common examples. If one site’s mistake can harm the whole organization, there is a strong case for common rules.
Do we need to compare or combine information? If head office needs reliable group figures, sites must record things in compatible ways. Agreed metric definitions matter here; if “a completed sale” means different things at different sites, comparisons mislead.
Is there real saving from doing it once? Buying the same item separately at each site, or running separate copies of the same software, often costs more than doing it jointly. However, savings should be checked rather than assumed, because coordination also has costs.
Does the practice depend on local knowledge? Local hiring, community relationships, stock mix and opening hours often depend on conditions that head office cannot see well.
How quickly must decisions be made? If a manager must wait days for central approval to fix a customer issue, local autonomy usually serves customers better.
What happens if the shared thing fails? A shared system is convenient until it goes down for every site at once. Single points of failure should be weighed honestly.
Examples by function
These are illustrations of how organizations commonly think about it, not rules.
| Area | Often shared | Often local |
|---|---|---|
| Finance | Chart of accounts, month-end timetable | Day-to-day cash handling procedures |
| IT | Accounts, security settings, core software | Local devices and on-site troubleshooting |
| Data | Customer and product definitions | Local notes and context |
| Purchasing | Contracts for common items | Urgent or specialist local purchases |
| People | Core policies and legal compliance | Hiring decisions and rotas |
| Customer service | Standards for response and quality | How staff handle individual situations |
The same function can be split. For IT, one central team might manage identity and security while a person at each site handles day-to-day issues. For purchasing, a central agreement can set terms while sites order for themselves.
Sharing the platform, not necessarily the process
A useful distinction is between sharing a system and sharing a process. Sites can use the same software and still configure certain steps differently within limits. Conversely, they can follow the same process using different tools, if the output is comparable. Separating the two often removes needless arguments: head office may care about the data produced, while sites care about how they work.
Costs of getting the balance wrong
Too much centralization can lead to slow decisions, workarounds, and frustration among site managers who feel distrusted. Central teams may also lose sight of what actually happens at the sites, so their standards drift away from reality.
Too much local variation leads to duplicated effort, difficulty moving staff between sites, patchy security and unreliable group reporting. It can also make it hard to spot a problem at one site until it is large.
Making it work in practice
Some habits that help:
- Write down the decision. Keep a short list of what is shared, what is local and who owns each item. Decision rights are easier to follow when they are explicit.
- Give sites a voice. Involve site managers when standards are drafted and provide a route to ask for exceptions with reasons.
- Start narrow. Share a few things that clearly benefit from it, check how it goes, then extend if it helps.
- Review periodically. A line that suited three sites may not suit eight. Reassess as the business changes.
- Keep the shared parts reliable. If a central service is slow or unresponsive, sites will build their own, undoing the benefit. Central teams should treat sites as customers whose feedback matters.
When the sites are very different
Some multi-site organizations run branches that differ greatly, for example a retail shop, a workshop and an office under one owner. In such cases, a thin common layer covering finance, security and key policies may be sufficient, with most operational decisions left to each site. Others, such as chains with near-identical outlets, can standardize much more. The more alike the sites, the stronger the case for sharing; the more varied the needs, the stronger the case for local choice.
There is no formula that gives the correct line. The goal is to be able to explain, for each practice, why it is shared or local, and to be willing to move it when circumstances change.