ERP projects: what's decided before installing anything

An ERP project is an organisational project that uses software

Most ERP projects fail to meet their goals, and almost never for technical reasons. The software, for its part, worked.

The causes are always the same: the teams weren't brought on board, the migrated data was wrong, and nobody on the project had been through it before. What fails is the day everyone has to work differently.

So the first question to ask isn't "which tool", but "who will have to change the way they work, and what are we doing to prepare them".

Every line of custom code is a bill that comes back with every version

Adapting the tool to the way you work seems to be the goal. Except that with every new version, custom developments have to be reviewed, tested and often rewritten, and the more there are, the more the upgrade becomes a project.

So the question to ask about each request isn't "is it feasible" but "is it worth paying for again every year".

In practice, that means starting with what the tool already does, configured on your real processes, and looking at the gaps instead of filling them with code. Some make the cut. Others are solved by changing a habit.

Your data is dirtier than you think

Duplicate clients, items created in triplicate, balances that don't add up, spreadsheet columns that meant something else six years ago.

As long as this data lives in separate tools, nobody notices. The day it all has to go into the same system, everything surfaces at once, at the switchover, when there's no margin left.

The only known remedy is to start early: extract the data before configuration is finished, while there's still time to decide.

• What can be migrated as is
• What must be cleaned first
• What's better not migrated at all

You can own your whole system and still be stuck with your provider

The lock-in is almost never in the contract. It's in the accounts opened in the integrator's name, the connections running through their tools, the settings nobody else can read.

The test comes down to one question: if you changed provider next month, how long would the next one take to understand your system?

What makes the answer acceptable isn't a clause, it's documentation: why this field, why this flow. That's what is always missing when someone else takes over.

• Are the accounts and access in your name?
• Does the code of the modules developed for you belong to you?
• Are the settings and decisions written down somewhere other than in someone's head?