There is a pattern we see repeatedly when a business asks us to look at an ERP that is not working. The software runs. The reports generate. The licences are paid. And yet half the company is still working from a spreadsheet, and the numbers in the system stopped matching reality about four months after go-live.
The failure is almost never technical. It is that the system asked people to work in a way that does not match how the work actually happens.
The exceptions are the process
Every requirements document describes the happy path. Material arrives, it is inspected, it is issued to production, it comes back as finished goods. What the document leaves out is the twenty exceptions the floor deals with every week: the urgent job that jumps the queue, the partial receipt against a purchase order, the lot that goes out for rework and comes back short, the customer who takes delivery before the paperwork exists.
If the ERP cannot express those, people do not stop doing them. They do them outside the system, and reconcile later — or never. That is the moment the data starts drifting.
A perfect implementation that the storekeeper will not use is a failed implementation.
Adoption is a language problem too
In a Gujarat manufacturing business, the person entering the goods receipt may not work in English. If the interface, the training and the support line all assume they do, you have introduced friction at the exact point where your data quality is determined.
This is not a nicety. Local-language interfaces and on-site, in-person training are among the highest-return decisions in an implementation, and they are usually the first things cut when a budget gets tight.
What we do differently
- Business analysts spend time on the floor before anything is designed, documenting the exceptions people work around.
- We go live with a narrow scope that works completely, rather than a wide scope that works partially.
- Training is role-based and delivered in the language the team actually works in.
- We build super-users inside your team, so the system survives our engagement ending.
- Hypercare runs through the first full reporting cycle — the point at which most drift starts.
None of this is clever. It is just the part of the work that gets skipped when a project is priced as software rather than as change.