Standardizing a Roll-Up: One Operating System Across Eight Acquired Companies.
A holding company buys eight operating companies in three years. Each came with its own accounting system, its own sales tool, its own way of taking an order and closing a month. The group now needs one close, one customer view and one set of numbers it can show a lender, and the obvious answer is one ERP for everyone, migrated in a programme.
We have watched that programme stall at company three more than once. The reason is not the software. It is that the eight companies disagree about what a customer is, what an order is and what the chart of accounts means, and moving them onto one system before settling those disagreements moves the disagreement into one database, where it is harder to see and more expensive to fix.
This post is the sequence that works, and it puts the ERP decision last.
Three definitions before any system.
Every roll-up has three things the group needs to be identical across companies, and almost nothing else that has to be.
The customer. Who is a customer, how one is identified, and which system issues the identifier. Eight companies have eight customer lists with overlaps nobody has measured: the same distributor is a customer of three of them under three names. Until the group decides that one system issues a customer id and the others receive it, there is no group customer view, whatever software runs. We described the mechanism for one company in the piece on which system owns the customer; a roll-up multiplies it by eight.
The chart of accounts. Not identical ledgers, which is a mistake, but a group mapping: each company's accounts mapped to a group chart so that revenue, cost of sales and operating expense mean the same thing in the consolidation. Company four books freight in cost of sales and company six books it in operating expense, and the group margin is wrong until someone decides.
The order. What the unit of sale is, and when revenue is recognised. A services company and a distribution company in the same group will never have the same order process, and they should not. But the group needs to agree what an order is for the pipeline report, and that is a definition, not a system.
These three take a quarter of workshops with the operating companies' controllers and sales leads. They produce three documents and no software. They are the whole foundation.
One layer over eight systems, so the close works now.
With the definitions settled, the group has a choice that most integrators present as no choice at all: migrate everyone to one suite, or put a reporting and integration layer over the eight systems and leave them running.
The layer is usually right first, for a reason that has nothing to do with software preference. The group needs a consolidated close now, this quarter, and a migration programme delivers it in eighteen months if it goes well. A layer that pulls each company's ledger into a group model through the chart mapping, and each company's customers through the shared id, delivers the group close in a quarter. The operating companies keep their systems, their people keep their screens, and the group gets its numbers.
The layer also answers the question the migration cannot: which companies actually run the same process. Once the eight ledgers and eight pipelines are visible side by side, it becomes obvious that companies one, two and five take orders the same way and could share a system, while company seven is a different business that happens to share a shareholder. The migration plan writes itself from the data instead of from the integrator's proposal.
Zoho's accounting application handles a group of entities up to a point, and that point is worth knowing before you choose it as the layer; we mapped it in the piece on where Zoho accounting stops. Beyond it, the layer is a reporting model fed by connectors, and that is a perfectly good shape for a group of eight.
Migrate company by company, only where the process is the same.
Now the ERP question, in its proper place. Some of the eight companies will share a system. Which ones is decided by the layer's evidence: same order process, same fulfilment, same close. Those migrate together, one at a time, each onto the already-running configuration, each carrying the shared customer id and the group chart mapping it already has.
Companies with a genuinely different operating model keep their system behind the layer. This is the part that offends the consolidation instinct and saves the programme. A services firm forced onto a distributor's ERP does not become more standard; it becomes a services firm running workarounds in a distributor's ERP, and its controller starts a spreadsheet. The group has standardized the three things that matter and left the rest alone, which is what standardization should mean.
Each migration is then small: one company, a known configuration, a customer list already reconciled to the group id, a chart already mapped. The cutover is weeks, not quarters, and the group close never stops working, because the layer kept reporting through it.
What the big-bang programme gets wrong.
The consolidation programme that stalls makes the same three errors in the same order.
It chooses the suite first, because a licence negotiation is a visible milestone and a definition workshop is not. It then discovers the customer and chart disagreements inside the migration, where they become data cleansing tasks on the critical path. And it migrates everyone, because the business case assumed one system, so the services firm and the distributor end up in the same configuration, and the configuration serves neither.
By company three the programme is six months late, the group close still runs on spreadsheets because the migrated and unmigrated companies cannot be consolidated, and the operating companies have learned that the group's systems make their jobs harder. The remaining five companies resist, and they are right to.
The sequence, in one place.
Quarter one: the three definitions, with the operating companies in the room. Quarter two: the layer, delivering the first consolidated close. Quarters three onward: migration company by company, grouped by evidence, with the layer running throughout. The ERP licence is signed in quarter two at the earliest, for a known number of companies, against a known configuration.
That is slower to the licence and faster to the outcome, which is the group running on numbers it trusts while its operators keep operating. A roll-up is a business decision made eight times; the systems should follow the decisions, not force them.
We build the standardization map and the layer, and we run the migrations where the evidence says to. Discovery is no-risk: we read the eight estates, show you which three definitions are unsettled, and you pay only if you go ahead.
Know whether your business is ready for an ERP before you sign for one.
The ERP Readiness Review is a 90-minute working session plus a written scorecard across master data quality, documented exceptions, integration scope and data ownership. Fixed scope, no obligation. Or see how we approach it.
More on the same problem:
Comments