Tags:
A group acquires a small company, or launches a new arm. Within a week someone says the obvious thing: put it on our ERP. It sounds tidy. One system, one set of reports, one vendor to call.
Then the plan arrives. Months of configuration, a template built for a business many times the size, and a list of processes the new unit will have to change to fit.
Two layers, one organisation
Two-tier ERP is a different way to set this up. The first tier is the core, the parent company's system. It carries group finance, consolidated reporting and the work done at the parent level. The second tier is a lighter system used by one subsidiary, acquired company or fast-growing unit for its own day-to-day work. The unit runs on its own system and sends summary numbers up to the core.
The core stays standard. The second tier takes on the work that does not belong in it.
Why one system for everything gets expensive
A fast-growing unit changes its mind often. A new pricing model, a new sales channel, a product line that did not exist last quarter. The parent's ERP was built to stay steady, with changes tested and controlled. Those two speeds rarely match.
Gartner's guidance, as summarised by NetSuite, is to check whether two tiers would serve better than one, particularly for small units that may grow quickly. A lighter second-tier system is usually simpler to put in and gives the unit more room to respond to change. It is also often cheaper than reshaping the corporate system so that it fits everyone.
Where it tends to come up
It tends to come up after acquisitions, when a company arrives with its own system and swapping it out would take longer than anyone wants. It comes up when a group starts a new line of business. And it comes up when a subsidiary in another country has local requirements the core was never designed to handle.
What it looks like in practice
Picture a manufacturing group with a large core ERP. It launches an online retail arm with a couple of dozen people. Web orders, returns, promotions and payment gateways are nothing like the factory's world. Bending the core system around them would take a long time and touch a lot of things that currently work. So the arm runs on a lighter system built for that kind of work. At month end it sends its figures to the core, and group finance sees one consolidated picture.
Or take a services firm that adds a new line of work billed by milestone, where the rest of the firm bills by the hour. The new line needs its own way of tracking projects and invoices. The firm's core finance system only needs to know the totals.
The price of having two
Two systems mean two sets of things to look after. Figures have to be reconciled. The same customer may exist in both places, spelled differently. And the lighter system can drift into a corner of the business that nobody at group level can see into.
Most of this is manageable if the handoff is agreed before anything is installed. Which numbers move up, how often, and in what format. Who owns the customer and vendor records. Who signs off on the monthly figures.
A quick test for fit
Is the unit changing fast? Do its processes differ from the parent's? Does the core only need summary numbers from it? If the answer to all three is yes, a second tier deserves a serious look. If the unit is stable and does much the same work as everyone else, the parent's system is probably fine.
The question worth asking before a rollout plan gets written is a simple one. Does this unit need the parent's system, or does the parent only need the unit's numbers?
