Avoiding the ERP hangover

You have probably sat through the post-implementation review where everyone agrees the new enterprise resource planning system works, the data migrated cleanly and the invoices process on time. Then someone asks why the finance team still keeps a spreadsheet to reconcile what the ERP cannot see, or why the warehouse still prints pick lists because the mobile interface confuses the floor staff. The system went live. The organisation did not.

This gap between technical deployment and operational adoption defines what we might call the ERP hangover: the months or years of low-grade dysfunction that follow a platform rollout when leadership declares victory but the people who use the tools every day have quietly built workarounds. The technology functions. The capability does not transfer.

Target's experience illustrates the pattern. The retailer implemented an ERP system that met the technical specification, yet the organisation continued to rely on legacy processes because the new workflows felt foreign to teams who had not been equipped to think differently about their work. The system was installed. The mindset was not.

What happened

Target deployed an enterprise resource planning platform designed to integrate supply chain, inventory and financial operations across its retail network. The implementation followed a familiar arc: vendor selection, configuration workshops, data migration, user acceptance testing and a phased go-live. The project met its milestones. The software performed as specified.

What the project did not deliver was a workforce that understood why the new system required different habits. Store managers continued to manage stock levels using the mental models they had developed over years with the old tools. Finance teams reconciled discrepancies manually because they did not trust the automated controls. Warehouse supervisors printed reports the ERP made redundant because the digital dashboards did not match the way they scanned a floor.

The organisation had changed its software. It had not changed the way people made sense of their work.

The capability gap

Enterprise technology projects routinely confuse deployment with adoption. A system goes live when the servers run and the interfaces load. Adoption happens when a store manager stops checking the old spreadsheet because she trusts the new inventory forecast, or when a buyer changes her ordering rhythm because the demand signal is now real-time instead of weekly.

That shift requires more than training on where to click. It requires a conceptual reorientation: understanding what the system knows that the old process did not, why the new workflow produces a better outcome and what to do when the software behaves in a way that feels wrong. Most ERP programmes treat this reorientation as a change-management afterthought, a series of lunch-and-learn sessions scheduled after the technical build is complete.

Target's experience suggests the cost of that sequencing. When people do not understand the logic of the new system, they default to the logic of the old one. They build shadow processes that feel safer because they are familiar. The ERP becomes a compliance layer: something you update because IT requires it, not something you rely on to make decisions.

The result is a kind of organisational debt. The technology is in place, but the capability to use it well is not. Teams spend cognitive energy reconciling two systems instead of one. Managers lose confidence in data they do not understand. The promised efficiency gains evaporate because the organisation is running both the new process and the ghost of the old one.

What this means for digital transformation leaders

The ERP hangover is not unique to retail or to enterprise resource planning. It is the predictable outcome of any transformation that treats technology as the intervention and people as the recipients. If you install a new platform without building the mental models that make it useful, you get compliance without capability.

Avoiding that outcome requires a different centre of gravity. Instead of designing the training programme after the system is configured, design the learning architecture before the vendor is selected. Identify the conceptual shifts the new platform will demand: the buyer who will need to interpret a demand forecast instead of a sales history, the warehouse supervisor who will need to trust an algorithm instead of her memory of where stock usually sits, the finance analyst who will need to reconcile at the transaction level instead of the batch level.

Then build the capability development around those shifts. Not a user manual. Not a series of recorded demos. A structured programme that helps people understand what the system knows, why it knows it and how to act on that knowledge when it conflicts with their intuition. That programme should start months before go-live and continue months after, because the hardest learning happens when the system is live and the old workarounds stop being available.

It also requires a different definition of success. A successful ERP implementation is not one where the system processes transactions without errors. It is one where the organisation makes better decisions because the system surfaces information people could not see before. That only happens when the people using the system understand its logic well enough to trust it, question it and adapt it to the work they actually do.

The alternative is the hangover: a technically functional system that the organisation tolerates rather than relies on, and a workforce that has learned to work around the tools that were supposed to make them more effective.

Sources:

• CIO