ERP Implementation: On Time, On Budget, Fully Adopted, and Still Not Delivering

By Steve Leadbeater 

The hardest conversations I have are not about failed projects. They are about successful ones.

The pattern goes like this. An implementation lands more or less on schedule and more or less on budget. Users are trained, they are logging in, transactions are flowing. By every measure the project team was given, it worked. And then somewhere around the six-month mark, leadership starts asking a question that nobody on the project has an answer for: so where is the improvement?

Inventory accuracy is still not what it should be. Planning is still reactive. Margins are still harder to predict than anyone would like. Executives are still being pulled into operational decisions that ought to be settled two levels below them. The system works. The business does not work noticeably better.

Why This Happens

An ERP system executes the processes you give it, faithfully and at speed. That is the entire proposition, and it cuts both ways. If accountability for a decision was ambiguous before go-live, it is still ambiguous afterwards, only now the ambiguity resolves faster and leaves an audit trail.

A system cannot decide who owns a process. It cannot settle whether operations or finance sets a cost. It cannot make two departments that have never agreed on a definition start agreeing. Those are organizational decisions, and if the program did not make them, go-live does not make them either.

A Concrete Example: WIP 

Work in process is where I see this most clearly, because WIP reporting is unusually honest about the process behind it.

In Visibility ERP, WIP is not a figure the system calculates on request. It is the accumulated result of move tickets and labor tickets posting against work orders as jobs progress. Quantity moves through operations, labor and overhead charge to the order, and what you get out is a real-time picture of what is in flight and what it has cost so far.

Which means it is real-time exactly to the extent that the shop floor records transactions in real time. If moves get entered in a batch on Friday afternoon, then WIP is accurate weekly, not hourly. The system is not wrong. It is reporting precisely what it was told, when it was told. But the manager who was promised real-time shop floor visibility during the sales cycle looks at a stale figure on a Wednesday and concludes the software has failed them.

Nothing in configuration fixes that. It is a change to how a shop floor works, which is a supervision and habit question, and it needs an owner, a target, and somebody prepared to have the same conversation four weeks running.

What Has To Be Built Alongside The System 

If you want the business outcome and not just the system, three things need to exist by go-live:

• Decision rights. Who can approve an exception. Who authorizes a cost change. Who arbitrates when the shop floor and finance disagree about whether a job is finished. Write them down; the ambiguity is invisible until it is expensive.
• A measurement cadence. Somebody looking at the same handful of numbers every month from the first month, so that drift is visible while it is still small.
• A named owner per end-to-end process, not per module. Order to cash crosses four departments and belongs to none of them, which is precisely why it degrades.

The Reframe 

Go-live is not the moment the business improves. It is the moment the business starts being told the truth about how it currently operates, in more detail and faster than before. That is genuinely uncomfortable, and it is also the whole value of the exercise. The organizations that get the most out of their systems are the ones that treat that first uncomfortable year of visible imperfection as the start of the work, rather than as evidence that something went wrong.

If your implementation checked every box and you're still waiting on the improvement, we'd be glad to talk it through. Contact the Visibility team.