Multi-site, multi-company: what standard software gets wrong

The same software, bought once for the whole group, ends up looking like a different tool at every site. Each one added its own fields, ignored the ones it didn't need, and worked around whatever didn't fit how it operates. At month end, the management report gets rebuilt by hand in a spreadsheet, because two sites don't quite count things the same way.

What holds on one site doesn't hold on ten#

Off-the-shelf software is built for one scope: one entity, one master data set, one way of approving a purchase order. On a single site, that holds. Across ten sites and three companies, every starting assumption turns into a local exception.

The first site with different rules (a lower approval threshold, a different unit of measure, a specific supplier relationship) faces two choices: force its reality into fields that weren't built for it, or build a workaround in a spreadsheet next to the system. Both are costly, but only the second shows up right away.

This isn't a question of which software you bought. It's that nobody, when setting the tool up, decided in advance what had to stay identical everywhere and what could vary. Without that decision, each site makes the call on its own, and each one makes it differently.

What has to stay common, what can stay local#

One question settles half the problem: if two sites count the same thing two different ways, can you still add them together? If the answer is no, that element has to be common. If the answer is yes, it can stay local.

This grid isn't something you discover while configuring an off-the-shelf package: it has to be built with the sites, before the tool is chosen. It's a question of method, not a configuration setting.

The cost of fragmentation#

When that grid doesn't exist, each site ends up adding its own tool around the central software: one spreadsheet for what the software can't do, a second for what it does badly, a third to connect the first two back to group reporting. At a distributor with several hundred people, we have seen more than fifteen such tools stacked around the in-house system, and four of them, off-the-shelf, cost €190,000 a year between them, not counting the spreadsheets nobody invoices but someone maintains every month.

The simplest sign to watch for: two sites giving a different figure for the same question, on the same day. When that happens, the group report stops being a number and becomes a negotiation between two versions of it.

What changes with an application built for the group#

An application built for the group starts from the opposite direction: the common/local grid is settled before the first screen is written. The definition of a figure (a margin, a delivery lead time, a service rate) is single, written once, and shared by every site. A director opens the reporting screen on a Monday morning and sees a group figure that genuinely adds up, not a cube that only three people know how to rebuild.

What stays local stays local, explicitly: one site keeps the warehouse layout that suits it, another keeps a two-step approval flow because its organisation is different. Nothing gets imposed by copying one site's screen onto every other one. And because there is no per-user license to multiply across sites, opening a new site or absorbing an acquired company doesn't push the software bill up at the same pace as headcount.

What not to do#

Forcing an identical screen on every site, in the name of consistency, produces the opposite of what it's meant to achieve. The site whose real organisation doesn't fit the imposed screen builds its own spreadsheet next to it, exactly as it would with off-the-shelf software. The consistency that matters is in the definitions and the group figures, not in the screens.

Multi-site, multi-company: the key takeaways#

Standard software doesn't break because it's bad: it breaks because it assumes a single scope, and a group has several. The grid between what must stay common and what can stay local gets built before the tool is chosen, not while it's being configured.

Built once, that grid holds over time: it tells a new site what to follow from day one, and what it keeps for itself. That grid, more than the software, decides whether group reporting stays a number or turns back into a monthly negotiation.

See also what changes with a custom-built application, what a custom application changes for a group, and the supply chain and transport section for topics specific to multi-site distribution.