We have been hearing the same sentence for years: "We implemented the system, but nobody uses it." Or: "The consultancy walked away, the project stalled halfway, and now we don't know what to do." In that situation, the first idea most companies have is to start again from scratch.
In our experience that is usually unnecessary and expensive. A stalled project generally contains a lot that works. The real problem is telling what works from what is broken.
Why is the diagnosis so hard?
A stalled F&O project can consist of thousands of objects. Customisations written by different teams at different times, undocumented integrations, development work abandoned halfway. Going through all of that by hand takes weeks. And the people who wrote the code are often no longer around.
We used to do this diagnosis entirely by hand. An experienced consultant would spend days inside the system, taking notes and slowly building up a picture. That is still needed. But we can now do the first and most laborious part much faster with AI.
What does the AI do?
We run Claude in the project's development environment. In short, this is what it does:
- It scans the customisations and lists which standard objects they touch.
- It compares the code with Microsoft's standard approach and flags places that look non-standard or risky.
- It finds development work that was left unfinished, is never called, or duplicates something else.
- It documents integration points and data flows.
The output is a diagnosis document an analyst can read. Not a general verdict like "the system is bad", but a concrete list along the lines of "in this module, this object is a problem, for this reason".
Where do people come in?
The diagnosis document is a starting point, not a decision. Code that looks technically "wrong" is not necessarily wrong for the business. Sometimes a non-standard customisation was built that way on purpose, to meet a real need of the company.
So after the diagnosis we always go on site. We talk to users, process owners and management. Which problems actually stop the work, and which can wait? Those conversations set the priorities.
There is one more thing we are careful about: we do not use the customer's existing code as a template for new development. Carrying an approach that the diagnosis found to be a problem into new code just reproduces the old problem. For new development, our guide is Microsoft's standard.
Repair and what comes after
Once the priorities are clear, the repair starts: missing development is completed, faulty work is fixed, data is cleaned up. In this phase too, Claude writes the code, and our team approves, builds and tests it.
The last step is perhaps the most important one: documentation. One of the most common reasons a project stalls is that the knowledge sits with a single person. When that person leaves, the project has no owner. That is why we finish every repair with user and technical documentation.
Before you write it off
A stalled ERP project is often not a failed project but a badly managed one. Before throwing away the effort and investment in it, it is worth taking a careful look at the state it is in. AI speeds up that look. Making the right decision is still down to people and experience.
If you would like to assess where your project stands today together with us, have a look at our ERP rescue and improvement page, or write to us.