What an ERP Budget Has to Cover (And What Gets Discovered Too Late)

By Steve Leadbeater 

There's a conversation I've never once enjoyed. It happens a few months into a project, and it opens with somebody saying, "Nobody told us this would be part of it."

Sometimes that's fair, and sometimes it isn't. But the underlying cause is nearly always the same: the budget was anchored to the software price, because the software price is the only number that arrives as a formal quote. Everything else is effort — and effort is easy to underestimate when you haven't done it before.

Here's what sits below the waterline for a manufacturer specifically.

Data 

This is the big one, and it's consistently underestimated because it looks like a technical task. It isn't. Part masters, bills of material, routings, open orders, open purchase orders, on-hand balances, cost history — all of it has to come across, and all of it has to be right, because it becomes the foundation everything else stands on.

The reason this can't be delegated to IT is that the hard questions aren't technical. When there are three near-identical part numbers in the legacy system, only your engineers know which one is live. When a bill of material hasn't been touched in six years, only production knows whether it reflects how the thing is actually built now. Data migration is a business exercise wearing a technical costume, and it needs your subject matter experts' time, which is the scarcest resource in the building.

Reporting 

Every report anybody relies on has to exist in the new world, and the list is always longer than the one you're given at the start. There's the official reporting pack, and then there's the spreadsheet the production manager built that half the plant quietly runs on, the one nobody mentions until week two after go-live.

In Visibility, a good deal of this is IQ Plus work, and IQ Plus is capable enough that most requirements land without any application change at all. But it's still effort, it needs someone who knows the underlying tables, and it's almost always discovered late, which is exactly when effort is most expensive.

Integration 

Whatever has to talk to the ERP, in either direction. Each interface is small on its own. The set of them is not.

People, and the Backfill Nobody Costs 

The team you want on the project is exactly the team the business can't spare, because both lists are drawn from the same short roster of people who understand how things actually work. If you don't plan for that, one of two things happens: the project gets the B team, or the business runs short-handed for nine months and nobody admits it.

Backfill costs money. So does not backfilling, it just costs it somewhere less visible.

The Stabilization Quarter 

Budget the three months after go-live explicitly, as a phase with a name and an allocation. Reports get refined against real data instead of test data. Configuration gets tuned now that people know what they actually need. Habits get corrected while they're still forming.

Teams that plan for this get a system that improves after launch. Teams that don't get a project that's declared finished on the go-live date, a team that disperses the following week, and a set of small imperfections that harden into permanent workarounds, because there's nobody left with a mandate to fix them.

My Honest View  

The expensive implementation isn't the one with the biggest number on the contract. It's the one that arrives at go-live under-resourced, needs rescuing, and spends the following year buying back credibility with its own users.

That project costs more than the thorough version. It just costs it in a currency that's much harder to recover.

Thinking about what your own implementation budget is missing? Talk to us about where the hidden costs tend to hide in manufacturing ERP projects - before they show up in yours.