Which digital layers must wait for ERP harmonization?

Fewer than most transformation plans assume. A top-3 global brewer runs 43-45 different ERP instances, more recently framed as 70-plus — the residue of decades of local decisions, not a database you migrate over a weekend. Harmonizing them into one financial backbone genuinely takes years. But statutory consolidation and cross-market planning are the only layers that must wait. Order capture, delivery, loyalty and returnables can move now.

Why does one company hold 43-45 ERP instances?

Not incompetence. A top-3 brewer is the sum of decades of acquisitions and semi-autonomous operating companies, each of which bought or built its own ERP to match local tax, deposit and returnable-container rules, trade-term structures and route accounting. Every one of those systems encodes choices that were correct locally and incompatible globally. The reporting describes the result bluntly:

non-harmonised process, non-harmonised data

That phrase is the whole problem in four words. The instances are not redundant copies of one system; they are forty-odd genuinely different systems that happen to share a category label. The 70-plus figure quoted more recently is not sprawl that accumulated through neglect — it is what a truly federated business looks like once someone finally counts it. Which is also why the count keeps moving: nobody quite agrees where one instance ends and the next begins.

Why do these programs run for years, not quarters?

Because harmonization is renegotiation, not migration. Collapsing many ERPs into one means agreeing a single chart of accounts, one material master, one customer master and one set of process definitions across markets that have each run their own way for a generation. The technical data move is the easy part. The hard part is getting dozens of markets to accept someone else's definition of a "case," a "credit," or a "delivery" — and to give up the local workaround that has quietly balanced their books for fifteen years.

The comparators set the scale. Unilever ran 250-plus ERP instances before it began consolidating. Mondelez approved a $1.2B ERP and supply-chain program running to the end of 2028. These are not slow teams; this is the physics of the problem. And the timeline compounds, because you cannot see every dependency in advance. Each market surfaces its own local integration, its own regulatory quirk, its own reason the standard template does not fit — and each surfaces it after the plan is signed. We have written before about how every discovered dependency generates an invoice; on a program this size, discovery is the schedule, and the schedule is measured in years.

Which layers actually depend on harmonization?

This is the question that decides whether the rest of your digital estate ships this decade. The instinct is to treat everything as downstream of the backbone — freeze order capture, loyalty, delivery and analytics until finance is one system. For most of them that instinct is wrong. The test is simple: does the layer need one harmonized ERP, or does it only need a stable, well-defined contract to whatever ERP happens to sit behind a given market?

Read the table as a boundary, not a checklist. Everything marked "no" shares a single property: it consumes and produces operational events — an order placed, a truck loaded, an empty keg returned — and those events are local by nature. They never needed the finance core to agree with itself. The layers that genuinely must wait are the ones that roll up: a group close, a consolidated demand plan. Confusing the two is the most expensive mistake in the program, and it is almost always made in the planning phase, on a slide, years before anyone writes code.

What actually freezes if you make everything wait?

Two things, and both are costly. First, budget. An estate of forty-plus ERPs is already a keep-the-lights-on machine; if the harmonization program also becomes the gate for every customer-facing change, discretionary spend trends to zero for the duration. This is how organizations arrive at the ratio we unpack in reading an 80% keep-the-lights-on IT budget honestly — not because nobody wants to innovate, but because one program has claimed the option to, and everything else queues behind it.

Second, and worse, relevance. A multi-year backbone tends to deliver customer- and field-facing tooling as a late, monolithic phase: specified years earlier, shipped to reps who have long since changed how they sell. That is precisely how a company writes off a system its own field force refuses to open — we walked through one in the $125M order system reps refused to use. Making the edge wait for the core does not de-risk the edge. It ages it into irrelevance before launch.

So where does that leave the plan?

Let the financial core harmonize on its own multi-year clock — the consolidation onto a single ERP is real work, and the SAP core should stay exactly where it is. But put the route-to-market layers on a shared event bus that speaks a stable contract to whatever ERP is live in each market, so order capture, delivery, loyalty and returnables ship in months and simply re-point as markets migrate underneath them. The backbone becomes something the edge reads from, not something it waits for.

The interesting number was never how many ERPs a brewer runs today, or how many more years the backbone needs. It is how many product decisions get quietly deferred to "after harmonization" — and whether, a few years from now, the markets that decoupled their customer-facing layer are simply operating while the rest are still waiting to begin. That gap, not the ERP count, is what the next transformation review will actually measure.