Shared Systems, Local Customers
A useful way to design a group of operating companies is to sort every capability into two boxes: what the customer notices, and what they do not.
Integration debates usually start with the organisational chart. We think that is the wrong end. A better starting point is the customer, and a single question: would they notice, and would they mind?
What customers care about
- Who answers the phone
- Who understands the property
- Who visits the site when something goes wrong
- Who solves the problem, and how quickly
- Whether the salesperson speaks the local language
- Whether the relationship feels personal rather than administered
These are the capabilities that should sit as close to the customer as possible. Centralising them creates distance and rarely produces an offsetting advantage.
What customers do not care about
- Whether finance runs on a shared reporting system
- Where data infrastructure is hosted
- How cybersecurity is managed
- Whether supplier information is held centrally
- Which business intelligence tools the group uses
- How certain administrative processes are standardised
- Where specialist expertise physically sits
These are candidates for shared capability, because their quality improves with scale and their effectiveness does not depend on proximity.
The principle
Centralise where distance from the customer does not destroy value. Stay local where proximity creates it.
Stated that way it sounds obvious. In practice, most integration plans violate it, because organisational tidiness is easier to argue for than customer intimacy is to defend.
The exception worth naming
Reporting is the one area where decentralisation should not win. Information should be consistent, timely and comparable across the group — not because headquarters needs it, but because without it nobody, including local management, can see clearly.
Better information is not the same thing as more control. Confusing the two is how good decentralised groups slowly become bad centralised ones.
