Should a Portfolio Company Automate Before or After the ERP Consolidation?

The freeze nobody voted for

The sponsor has signed off on a single ERP across four operating companies. The systems integrator has a plan, the plan has a go-live date, and somewhere in the kickoff deck is a line about minimizing change to in-scope processes during the program.

Nobody argued with that line. It sounds like discipline.

Then the controller at the largest operating company asks whether she can put a tool in front of supplier invoices, because two people are keying them by hand and one of them is leaving in November. The answer comes back: wait for the new system. That answer gets repeated to the order desk, to the credit team, and to whoever asks next.

The median ERP project runs about nine months, and mid-market implementations are commonly quoted at six to twelve with another two or three months of stabilization after go-live. Call it a year and a half from kickoff to the point where anyone is comfortable touching it. The freeze was never presented as a decision to run known-broken processes for eighteen months. That is what it is.

Why the search results cannot help you

Search this question and every result on the first page is written by someone who implements ERP. They all give the same answer, which is that you should fix your processes before you configure the system, because configuring around a bad process bakes it in. Ensure data integrity first, they say, or automation will amplify poor data quality.

That advice is correct. It is also not an answer to the question being asked.

"Optimize before you configure" is about process design inside the implementation. The operator's question is about the eighteen months of operating that happen alongside it, while volume keeps arriving and people keep quitting. The implementer has no commercial reason to answer that, and some reason not to: every parallel change is a variable in their project plan and a potential line in their change order.

So the ERP vendor is not a neutral party in the sequencing call. Neither is the integrator. That is not an accusation, it is a description of where they sit. Ours is different. We do not implement the ERP and we do not sell the automation platform, which is the only reason our read on the order is worth anything.

The base rate argues against the freeze

The freeze is a bet that the new system arrives roughly on time and works. That bet has a public track record.

Panorama's 2025 research puts the overall ERP failure rate, defined as failing to meet stated objectives, at 68 percent. Average cost overruns run 189 percent. Roughly 30 percent of projects land on time and on budget. Across broader industry analyses the failure band sits somewhere between 55 and 75 percent depending on how the question is worded, and discrete manufacturing is worse than average on both dimensions.

Read those numbers the way an underwriter would. You are not choosing between automating now and automating on a known date. You are choosing between automating now and automating on a date with a wide distribution behind it, where the left tail is a go-live that slips two quarters and the far tail is a program that gets restructured and starts its clock again. The freeze prices that risk at zero.

The other half of the arithmetic is what the frozen process costs while you wait. That is usually knowable inside a week: transaction volume, touches per transaction, minutes per touch, loaded hourly cost, error and rework rate. We walk through how that calculation actually gets built in what an automation ROI calculation should include. If nobody has run that number, the freeze is not a judgment call. It is an unpriced default.

Two kinds of automation, and only one of them waits

Here is the distinction that decides the answer, and it is not the one the implementation decks make.

Some automation is a bet on the current system. Anything that reaches into a specific screen, a specific field layout, a specific report, a specific login. Screen-scraping bots. Macros against a legacy export. An integration built to one company's chart of accounts. That work dies at cutover and it often dies badly, because bots built against a system under active change break quietly and keep posting stale data until something downstream surfaces the failure. Build that now and you have bought eighteen months of relief and a disposal cost.

Some automation is a bet on the process. Capturing an invoice or an order from a PDF or an email and turning it into structured data. Routing an approval by role instead of by a person's inbox. Validating a customer record against an external source before it enters any system. Those things describe work, not screens. The destination field changes at cutover. The judgment encoded in the rule does not, and neither does the cleaned-up data, which arrives at the migration in far better shape than it would have otherwise.

The test we use is one question, asked about each candidate. If the ERP project were cancelled tomorrow, would you still want this? If yes, it is a bet on the process and it should not wait. If the only reason it exists is that the current system is painful, it is a bet on the system and the freeze is doing its job.

That question sorts more of a portfolio company's automation backlog than any governance framework we have seen, and it can be answered in a room with the controller and the operations lead in about an hour.

The second-order reason to move on the process bets

Most of what makes an ERP consolidation go badly is data. Duplicate supplier records across two companies. Customers that exist three times with different terms. Item masters that were never reconciled because nobody had a reason to. Underestimated staffing and data issues are two of the three leading causes of ERP budget overruns, cited by roughly a third of projects each.

A process-level automation built during the freeze forces that reckoning early and at a smaller scale. You cannot automate supplier invoice capture without first agreeing what a supplier record is, and that agreement is a migration deliverable you have now paid for twice, once in cash and once in avoided overrun. The work is the same work. Doing it in month three against one company is materially cheaper than doing it in month fourteen against four companies with a go-live date behind it.

This is the same pattern we described for manufacturers weighing quoting automation against standardized routings. The sequencing question usually resolves when you notice that one of the two options is a prerequisite for the other rather than a competitor to it.

What the sponsor should actually be asking

If you are the operating partner, three questions get you most of the way.

Ask which automations on the list are bets on the process and which are bets on the system, and make the operator defend the sort rather than accepting it from the integrator. Ask what the frozen processes cost per month, in dollars, and compare that to the disposal cost of anything you would throw away at cutover. Ask what happens to the freeze if the go-live slips two quarters, because on the published base rates it probably will.

There is a fourth one that matters more at the deal stage. The capacity constraint that makes this decision urgent is usually visible before you own the business, and it is usually not in the financial diligence. We wrote about that gap in what operational diligence finds that a quality of earnings report cannot.

We are not arguing for automating everything during an ERP program. Half of a typical backlog genuinely should wait, and a sponsor who lets the operator build a bot farm against systems that are being retired has funded a demolition project. We have told clients to hold, and we will tell you to hold where the work is a bet on a system you are about to switch off. Turns out you can be too quick on the draw and still shoot yourself in the foot.

The part that does not survive contact with a generic answer is the sort itself. Which of your specific automations is process and which is system depends on how your data actually sits, how far along the implementation is, and what your November staffing looks like. That takes a look at the real backlog, not an article.

If you are staring at an eighteen-month freeze and a process that is already failing, book a consult. We will go through the backlog with you and tell you which items to build now, which to kill, and which to hand to the implementation team as a configuration requirement instead.