Multi-entity ERP rollouts are sold as template stories. Most aren't — and the moment it shows is always the same.
PONTURA INSIGHTS · 5 JULY 2026
The first entity is slow because everything is new. The second is slow because everything turns out to be different. By the third, someone in a steering committee asks the question that names the pattern: why are we designing from scratch again?
Multi-entity rollouts are justified on a template promise: design once, roll out many times, each entity cheaper and faster than the last. The business case is usually drawn as a curve that bends down.
In troubled rollouts, the curve doesn't bend. Each entity costs roughly what the previous one did — sometimes more, because the people are more tired and the decisions more entangled. The reason is rarely the software. It is that entity one delivered one good local solution wearing a template's name.
The configuration you shipped first is not the template. The template is the set of decisions behind it — which processes are core, who owns which master data, how interfaces reconcile, what an entity may change and what it may not — written down with their reasons.
In most rollouts those decisions exist in three places only: in the configuration itself, where nobody can read the why; in slide decks, which record the what but never the why-not; and in the heads of the people who made them. Then the integrator's A-team rotates to the next client, and the heads leave the building.
From that moment, every new entity re-triggers the same conversations — not because people are difficult, but because nothing remembers. Every design workshop becomes a renegotiation with the past, held without the people who were there.
The most valuable document in a multi-entity rollout is also the most boring one: the rulebook that says which parts of the model are core — changing them requires a template decision that all entities inherit — and which are controlled local variants, where an entity decides within agreed boundaries.
Without that rulebook, a rollout doesn't have variants. It has forks. Every local exception granted in a hurry at go-live becomes precedent, and precedent compounds: by entity three, "the template" describes nothing that actually runs anywhere.
First: can anyone produce the list of template decisions, with reasons — or only the configuration? Second: when entity two wanted something different, was there a boundary to decide against, or just a negotiation? Third: are the people who designed entity one still the people designing entity three?
If the answers are uncomfortable, the honest next step is small: a short, fixed-price diagnostic of where the template actually stands — which decisions are load-bearing, which forks exist, and a re-plan you can defend. That is how a rescue starts; it is also how one is avoided.
Pontura designs and delivers multi-entity ERP rollouts on Infor M3 CloudSuite — one continuous engagement has carried a template across European entities for 30 months and counting. How we work with M3 →