Your quotes live in one piece of software, your stock in a spreadsheet, your accounts somewhere else, and someone types the same information three times a week. Then comes the moment of choosing an ERP, a single system to tie it all together. The market is full of offers for SMEs, every vendor has a flawless demo, and you have no IT department to help you sort through them.
I am not an integrator and I do not rebuild ERPs. I work on the client side, on specifications and on integrations between systems. What follows is what I prepare before any vendor shows anything, and what I look at afterwards to decide between offers.
01Before the ERP, write down how the business really works
When an ERP project goes wrong, the software is rarely the first culprit, and the vendors say so themselves. In one of its webinars, Odoo's implementation team lists among the main causes of failure thin requirements gathering and poorly defined processes: the stated requirements are wrong because the business has never written down how it works. The integrator understands the request, but the request does not describe reality.
So I start with one page, not with a comparison grid. For each workflow (a quote becomes an order, an order leaves the warehouse, an invoice goes out, a supplier gets paid), I write who does what, in which tool today, and where it gets stuck. I do this with the people who pick orders and keep the books, not just with the managing director.
This page changes quickly, and that is normal. On an integration between an ERP and an online shop, the specification moved at almost every meeting. I versioned it, so that everyone was talking about the same document. I explain this approach in my method for writing an integration specification.
In my content machines, writing does not start until the brief is complete: the tool answers "refused" and lists what is missing. I do the same here. Until the workflows are written down, I do not ask for a demo.
02What an SME's ERP must cover, and what it can leave to other tools
France Num, the French government service that helps small businesses go digital, sums up the scope well: purchasing, finance, sales, logistics, human resources. It also states the trade-off: an ERP is often less complete than the specialist software it replaces, and it can force the business to adapt to the tool.
So I do not look for an ERP that does everything. I look for the one that handles the core of the business well, and I keep whatever already works alongside it. If your payroll software or your online shop suit you, the question becomes: will the ERP exchange data with them, and which system is the master of each piece of data? For an online shop, I described these decisions in the article on connecting Odoo and PrestaShop.
You will not be alone with the question. According to Eurostat, 41% of small enterprises in the EU used an ERP in 2025, against 89% of large ones. Many SMEs are therefore on their first ERP, with no in-house team to choose it.
03The ERP selection criteria that really separate offers
Criteria lists are long. France Num's has about ten, all of them legitimate. In practice, I see six that really make the difference between two offers.
- Coverage of your priority needs, out of the box. I rank needs on three levels: must have, useful, nice to have. An ERP that needs development for a must-have need starts with a handicap.
- Data exchange with your other tools. I ask which API, on which subscription plan, and who writes the connector. With Odoo, for example, the documentation states that access to the external API is limited to Custom plans, not One App Free or Standard. It is the kind of detail people discover too late.
- Standard rather than bespoke. The same Odoo webinar sets staying as standard as possible as its first principle, and describes the drift caused by one small customisation after another, which stretches the project out with no end in sight.
- Hosting and where the data lives. France Num advises favouring data hosted in the European Union, given the GDPR.
- The cost of upgrades, which I cover below.
- The integrator as much as the software. That is who you will call when an invoice will not go out. France Num notes that with an open source product, it is easier to change integrator if things go wrong.
Usability matters too, but I judge it during the demo, with the future users in the room.
04Make vendors run your own cases in the demo
A vendor demo shows the path that works. That is not dishonest, it is their job. Yours is to make them run your cases, with your data.
Prepare about ten real cases
From the workflow page I pick about ten real situations, at least three of them awkward: an order delivered in two parts, a partial credit note, an item sold by the carton and stocked by the unit. That last kind of case deserves special attention. On one project, a mix of centimetres and millimetres between two tools distorted an entire render. Since then, I ask for the reference data to be explicit, units included.
Run them on your data, not the demo database
I send the cases and an extract of real data a week ahead. I ask each candidate to walk through them in front of the person who will do that work every day. I note what runs out of the box, what needs configuration and what needs development.
The idea comes from work at Moonworkers, my own company. A test oracle written from the official texts replayed several hundred payroll contribution cases and found four one-penny errors caused by a rounding rule. No demo would have shown them. I tell that story in the article on test oracles.
Keep the cases for acceptance testing
These cases are not only for the selection. They become the basis of user acceptance testing, the moment when, as the Odoo webinar puts it, the client tests their edge cases before signing off. My acceptance testing and go-live checklist starts from the same principle: you check things as a real user would, not as the team that built the tool.
05The costs that are not in the quote
The quote shows the subscription and the initial set-up. France Num warns about the hidden costs of "all-inclusive" plans: training, maintenance, version upgrades. I add three items that I have costed separately.
Upgrades first. Odoo's documentation states that each major version is supported for three years, and that a database containing custom modules cannot be upgraded until those modules exist for the target version. Every bespoke development today is therefore a migration job tomorrow. I ask who will carry it, and how often.
Data migration next. The Odoo webinar puts it plainly: an ERP fed with bad data gives bad results. Cleaning up customer records, items and stock takes time, and that time is rarely in the quote.
Training last, and your team's time. Odoo's team trains a few key users, who become the internal reference. It is good practice, but those people then spend days on the project instead of their usual work. You need to plan for it.
An honest limit: this preparation takes internal time, often several weeks, before the first demo. For a very small business with one simple workflow, that is too much. A free trial and a day of testing are often enough. And if your project looks like a heavy rebuild across dozens of sites, you need an integrator and a dedicated team, not just a scoping exercise.
06Where to start on Monday
Take a sheet of paper and list your five main workflows. For each one, note who does it, in which tool, and where it gets stuck today. Do it with the people who do the work. Then pick three awkward cases you will want to see running in the demo. If you are writing a tender document, the structure of my specification template adapts fairly well to an ERP.
You do not need to know the vendors to get started. You need to know how your business works. If you would like someone to write these workflows with you, prepare the cases and follow the selection on the client side, my project direction and technical direction services are described on the site, and the portfolio shows the rest. We can talk about it.