Put your data at the centre, not your software
When an AI project stalls, the usual suspects are the model, the vendor or the use case. More often the problem is lower down: the AI cannot reach the data it needs, because the data is locked inside the application that created it. The fix is not a better model. It is a different arrangement of the layers underneath.
How most companies are wired
At the bottom: servers and network. Above them: the ERP or the management software, which holds the data inside its own structure. On top: a few reports. And last, the AI, connected through connectors that reach down through layers never designed to let data out. Each connector is fragile. When the software is updated, connectors break. When a new question needs a field nobody exposed, the project waits.
The line between the AI and the data is long and frayed. That line is where most projects die.
The inverted arrangement
Keep the servers and network. Above them, put a data layer that belongs to the company, not to any single application. Each record carries its meaning with it: what it is, where it came from, how it may be used. On top of that layer, the business processes run as separate modules that can be replaced one at a time. The AI works inside those processes, with a short, direct line to the data.
Electrification offers the precedent. Factories that bolted electric motors onto the old steam-era drive shafts gained little. The gains came when factories redesigned the floor around the motor. The AI model is the motor. The data layer is the floor.
Keep the ERP, change its role
This does not mean throwing out the ERP. A data layer cannot post an accounting entry, reserve stock or run payroll with the guarantees those operations need. The ERP keeps doing what it does best: recording transactions correctly. What changes is that it stops being the centre of everything. It becomes one consumer of the data among several, not its owner.
The order of operations
Rebuilding everything at once is the most expensive mistake in business software. Do it in this order. First, set up the independent data layer for the few processes you want to improve, and route their data into it with its meaning attached. Second, move those processes one at a time, running old and new side by side before switching. Third, let the ERP settle into its narrower role. Every step delivers something on its own and can be reversed.
Start with one question: for each important process, which application holds its data hostage? That list is your plan.