The question before the conclusion.
- Lens
- governance
- Journey
- 10 decision points
- Reading
- 8 min
The meeting is held at headquarters. The directors of three subsidiaries sit around the table. The agenda reads: ‘harmonise our systems’.
Each arrives with an implicit position. Headquarters wants a single foundation for management. The subsidiaries want to keep what works for them, because it took them three years to make it work. No one is wrong. And if the meeting has no analytical framework, it will end in a vague compromise: ‘a shared foundation, with local adaptations’—a formula that decides nothing.
The question is not whether to harmonise. It is what to harmonise.
Three things that are constantly confused
Before making any trade-off, three concepts that everyday language blends together must be separated.
Multiple sites are not a governance issue. A company with four warehouses and one operations management team has a sizing issue, not a governance issue. It decides once and applies the decision everywhere.
Multiple business activities are an architecture issue. A company active in industry, distribution and transport needs different systems that communicate. It is a question of interfaces, not authority.
Multiple entities with genuine autonomy are the only real governance issue. There are separate management teams, separate budgets and sometimes separate countries—and therefore decisions that can legitimately diverge.
The framework: decide domain by domain, never as a whole
The structural mistake is to ask a single question—‘centralised or decentralised?’—when the answer should differ by domain.
Our working framework distinguishes four levels, and every domain must be placed in one of them:
Mandatory common standard. What must be identical everywhere, with no possible exception. Typically: item coding, indicator definitions, and security and access rules. This level should remain small—every item placed in it creates a permanent coordination cost.
Common by default, exception with justification. The group standard applies; a subsidiary may depart from it if it documents why and someone approves. This is the most useful level, and the one least often formalised.
Common framework, local implementation. The group sets the objective and vocabulary; each entity chooses its means. For example: ‘every entity must be able to trace a batch end to end’—how it does so is its concern.
Entirely local. What has no impact outside the entity. More subjects belong here than people think, and acknowledging them explicitly saves considerable time.
Placing the fifteen or twenty information-system domains in this framework takes half a day. It is the most valuable half-day of the project.
Master data: the only truly non-negotiable issue
If only one domain must be a ‘mandatory common standard’, this is it.
As long as the same product has three different codes in three subsidiaries, consolidation is impossible. You can build the finest dashboards: they will add together things that are not comparable. Corrections will be made manually in a spreadsheet by someone for whom it has become a full-time job.
This is not an IT project. It is political and organisational:
who is authorised to create an item?
under what naming and coding rules?
who approves it, and within what time?
what happens to divergent existing data—migrate it, map it, or freeze it?
One observation from experience: mapping—keeping local codes and maintaining a translation table—looks like an elegant compromise. It is almost always debt. The mapping table becomes a critical object that no one maintains, and errors accumulate silently.
Flows between entities: the blind spot
When two entities in the same group sell goods to each other, transfer inventory or provide services, they enter a field that almost no specification addresses properly.
Questions to ask:
is an inventory transfer between entities a sale or an internal movement? The answer changes everything, both in accounting and operations;
who owns the inventory while it is in transit?
how do the two movements—the issue on one side and receipt on the other—correspond? What happens when they do not?
are services provided between entities invoiced, and on what basis?
These flows are often managed by habit between people who know each other. They work—until one of the two people changes roles.
Consolidated does not mean real time
The assumption must be defused, politely but clearly. A real-time consolidated view requires all source systems to be permanently accessible, their data to be defined consistently and the exchange frequency to support it. In a group whose subsidiaries have different systems, that requires substantial investment—for often limited value.
The right question is: what decision do you want to make with this information, and how often do you make it?
If the decision is weekly, daily consolidation is more than enough. If it is monthly, weekly consolidation is comfortable. Real time is justified only where action happens in real time—which is rare at group level and common at site level.
Above all, harmonise definitions before consolidating. Consolidating figures that do not mean the same thing produces a false result to decimal precision. That is worse than having no figure, because it inspires confidence.
Deployment: the question of pace
A group that decides to harmonise has three possible strategies.
The big bang—everyone switches together. Appealing on paper, but very risky: a problem in one entity blocks everyone, and no one has experience to pass on.
A representative pilot site—one entity starts, the group learns and corrects, then deploys. This is the strategy we recommend in most cases, on one condition: the pilot must be representative, not easy. Choosing the simplest subsidiary produces a successful pilot that teaches nothing.
Waves by family—group similar entities together, by business activity, maturity or country, and deploy family by family. This is relevant when the entities are genuinely heterogeneous.
The choice depends on one thing: how alike your entities are. If they share the same processes, the pilot is enough. If they differ profoundly, waves prevent the same failure from being repeated several times.
One last point about acquisitions
A group that grows by acquisition regularly inherits systems it did not choose.
The temptation is to replace everything immediately ‘to standardise’. That is often the wrong sequence: a newly acquired entity is already going through a period of change, and imposing a systems change in the same year adds risk where there is already plenty.
The model that works is to define at the outset what every new entity must provide to the group—which data, in what format and at what frequency—then give it time to decide how. Tool harmonisation comes later, once the human integration has taken place.
