The Part of an ERP Project Nobody Budgets Enough For

Ask a manufacturer why their last ERP project ran late and you get a familiar list. Data migration. Testing. Scope creep etc.

You rarely hear the real answer.

Gartner says 70% of ERP initiatives fail to achieve their original business goals. It is worth being honest about why. It is almost never the software. The software works. What takes the time is turning a working system into Your System, one setting at a time, by hand.

That work has a name. Configuration. It is one of the largest part of most rollouts and the least discussed, and almost nothing about how the industry does it has changed in twenty years.

Configuration is the quiet chunk of the work

A new ERP arrives ready to run. It just does not know anything about your business yet.

It does not know your warehouses. Or your item groups, your order types, your price lists, your planning rules, your working calendars, your approval limits, your tax codes. Every one of those is a small decision followed by a small piece of data entry. None of them is hard but there are thousands of them.

That is the project. Not the install. Not the license. The thousands.

The work has an order, and the order is invisible

The thousands are not independent.

You cannot set up an item before its item group exists. You cannot run a price list before the currency and the calendar are in place. You cannot test an order flow before the warehouse, the customer, the item and the pricing all exist and agree with each other.

So the work is a chain. Long chains, joined to other chains, and a mistake near the start does not surface until something far down the line behaves oddly.

Nobody has that chain written down. It lives in the experience of a handful of consultants who have done this before and know, almost without being able to fully explain it, what has to come first. That knowledge is real and valuable. It is also fragile, undocumented, and walks out of the building at the end of the engagement.

This is the root of most of what follows.

Between the decision and the config setting, actual meaning leaks

Watch how a single configuration decision actually travels through a project.

A workshop happens. The business explains how they want returns handled. A consultant captures it in a requirements document, in prose, in a form that made sense in the room.

Three weeks later somebody else opens that document and has to turn one paragraph of English into a specific set of values in a specific set of screens. They were not in the room. They interpret. Mostly they interpret correctly.

Mostly.

Every one of those translations is a chance for the system to end up doing something slightly different from what the business asked for. Multiply that by thousands of decisions and several months and potentially a rotating team, and the gap between what was agreed and what was built is not a possibility. It happens way to often. The only question is how big the drift is and when you find it.

When a setting is wrong, nothing tells you

Here is what makes configuration different from the rest of the project, and worse.

When code breaks, it tells you. It throws an error, the build goes red, somebody gets paged. When a setting is wrong, it does none of that.

A wrong setting sits there looking completely correct. The screen shows a value. Somebody ticked it off the list. The project plan says that step is green.

You find out months later, in a test cycle if you are lucky, or on the first Monday after going live if you are not, when an order takes a route nobody expected. Then somebody spends a week working backwards through the chain to find which of the thousands of small entries caused it.

We have spent a long time looking closely at exactly how this happens, setting by setting. It is more common than the industry admits, and it is not carelessness. It is the predictable result of asking people to do thousands of small things by hand with no feedback when one of them is wrong.

Testing finds less of it than you think

The usual reassurance is that testing will catch it.

Testing catches what somebody thought to test. That is the whole limit.

Test scripts get written from the same requirements documents, by people working from the same assumptions, covering the paths everyone already had in mind. A configuration error hiding in a path nobody considered might pass every test you wrote and then wait.

This is why so many ERP problems appear in the first month of real use rather than in the test phase. Real users do things test scripts do not. The system was never wrong in an obvious way. It was wrong in a way nobody thought to look at.

Adding more consultants does not fix it

The standard response to a slow configuration phase is more people.

It rarely works, for two reasons.

The knowledge is not written down anywhere, so it does not transfer by adding headcount. The new consultant has to be taught the order of the work by the one person who already knew it, which slows that person down at exactly the moment you needed them going faster.

And the work does not divide cleanly. Two people configuring related areas at the same time make assumptions that quietly conflict. You do not discover the conflict when they make it. You discover it in testing, or later.

So the phase stretches. The go live date moves. Everyone agrees to work weekends.

Nobody can say when configuration is finished

Ask a project manager whether the build is done and you will probably get a percentage.

Ask what the percentage means and it gets vague. It usually means how many items on a checklist have been marked complete by the person who did them. It does not mean the settings are correct. It does not mean they agree with each other. It does not mean they match what the business asked for in the workshop.

There is no accepted definition of done for configuration. There is no equivalent of a passing build. That is remarkable for something that consumes a big part of the budget, and it is why configuration status reporting is optimistic almost by default. Not dishonest. Just measuring the wrong thing, because the right thing was never measurable.

What actually changes the number

Configuration gets faster when three things become true at the same time.

The order is known before the work starts. Not remembered by an individual. Written down as a plan the whole project can see, generated from the target system itself rather than from a spreadsheet somebody kept from the last rollout.

The repetitive entry stops being human work. Not all of it. A great deal of it. The decisions still belong to your people. The typing does not.

Every change proves itself. The system reads the setting back after it writes it and confirms the result is what was asked for. A step is green because it was checked, not because somebody said it was.

That third one is the one that matters most, and it is the one that gets left out. It is the difference between a fast project and a fast project you can trust. It also, finally, gives you a real answer to when configuration is done.

The test of all of this is the second site

Here is a simple way to judge any claim in this area, including ours.

Roll out to one site. Then roll out to a second site, in another country, on the same core design.

Today the second site costs most of what the first one cost. Think about how strange that is. All the thinking has been done. Every decision was made a year ago. The design is signed off. And yet the work is nearly as expensive the second time, because that configuration knowledge only ever existed as work that people did, not as anything you can pick up and use again.

It should be a fraction of the first implementation. When configuration is captured properly, as a plan rather than as a period of human effort, going live at a second site becomes a matter of days rather than another full project. We have done that. One customer's rollout went live in 150 man days, including ERP, WMS and automation by reusing what had been built for the first implementation.

That is the real argument for taking configuration seriously. Not that it shaves a few weeks off one project. That it turns the most expensive and least repeatable part of an ERP rollout into something you can do again, and again, at a fraction of the cost each time.

For a manufacturer with eight plants, that is a different business case entirely.

What this means for the people doing the work

None of this removes the consultant. It removes the typing.

The valuable thing a good ERP consultant does is know what the configuration should be, and why, and in what order. That judgment is the scarce part. The hours spent entering the results of that judgment into screens are not scarce. They are just where the time goes.

Take that away and the same person covers more ground, on more projects, with the part of the job they were actually hired for. We have written before about how the consultant role is changing. This is the specific mechanism.

What this means for the people doing the work

We cut rollout timelines by more than half, from fifteen to seven months, by going after the parts of an implementation that were never really designed to be done by hand.

Configuration is the biggest of those parts. It is what we have spent this year building for, and it is the piece we are most careful about, because getting configuration wrong quietly is worse than getting it wrong slowly.

More on that soon.

If your next rollout has a configuration phase that nobody has been able to shorten, we would like to show you what we have. Book a demo with Johan or me.