The ERP is no longer the hard part. The organisation is.

For most of my career, an ERP was something only large organisations could afford. Not because the software licence was expensive, although it was, but because everything around it was expensive: the consultants, the months of blueprinting, the customisation budget that always ran over, and the long tail of change requests after go-live. A medium-sized trading company or a factory with two hundred people looked at that bill and, reasonably, decided to keep running on spreadsheets and a basic accounting package.

Open source ERP changed the first half of that equation. Platforms like ERPNext and the Frappe framework put a complete, integrated system (accounting, inventory, sales, purchasing, manufacturing, HR, projects, CRM) in the hands of anyone willing to deploy it, with no licence fee and no vendor lock-in. We have built more than fifty custom applications on this stack across agriculture, real estate, contracting, trading, education and healthcare, and I no longer believe there is an industry or a company size for which open source ERP is "not serious enough". The platform is a very powerful tool. The question was always who could afford to shape it.

What AI changed in the last two years

Even with open source, the cost of an implementation was dominated by human hours: understanding the business, mapping it onto the system, writing the custom doctypes, scripts, reports and integrations that make a generic ERP fit a specific company. That work was skilled, slow and, for a small business, often still out of reach.

AI-assisted development has compressed that cost dramatically. The parts of an implementation that used to take a developer days, such as building a custom module, generating a print format, writing a server script, wiring up an integration, producing documentation and training material, now take hours. Not because the thinking has been removed, but because the typing has. An experienced implementer working with modern AI tooling can deliver what previously needed a small team.

The practical result: it is now realistic to give a company a working, tailored ERP in two or three weeks, at a price that is a fraction of what even open source projects cost a few years ago. The economics that kept ERP out of the small and mid-sized business are gone.

When the system can be ready in three weeks, the organisation becomes the bottleneck. And unlike software, organisations do not accept a patch.

The problem that speed creates

Here is what I have learned, and it is less comfortable than the paragraph above. A long implementation was painful, but it had one hidden benefit: time. Over nine or twelve months, people in the business gradually absorbed the idea that things were going to change. Workshops, data migration, pilot runs and endless meetings acted, without anyone planning it, as a change-management programme.

A three-week implementation removes that buffer entirely. The software is ready before the organisation has decided it wants to change. And then the familiar symptoms appear:

• The storekeeper keeps a parallel notebook "just in case" and the system stock is wrong within a month.
• Sales continue to quote from a personal Excel file and enter the order in the ERP afterwards, if at all.
• The accountant posts month-end from outside the system because that is how the auditor is used to seeing it.
• Management asks for the old reports in the old format, which quietly re-creates the old process.

None of these are technology failures. They are the organisation's culture reasserting itself, because the implementation moved faster than the people did. The cheaper and faster the technology becomes, the heavier the load that falls on the initiative to change how the organisation actually works.

What this demands from an open source ERP provider

This is why I think the profile of a good open source ERP partner has changed. Technical competence on the platform is now the entry ticket, not the differentiator. What separates a successful implementation from an expensive, fast failure is two things.

First, real depth in business process management. Not "we know the ERP modules", but the ability to sit in a warehouse, a clinic or a construction site, understand how value actually flows, and redesign the process before configuring the system. An ERP implemented on top of a broken process simply makes the broken process faster and more visible. The provider must know BPM methodology and practice: process mapping, ownership, KPIs, controls, and the discipline to simplify before automating. After thirty years in operations management across industrial and commercial companies, I am convinced this is where most of the value of an ERP is created or destroyed.

Second, the ability to tackle the cultural challenge head-on. This means treating adoption as a deliverable, not an afterthought. Concretely, in our engagements it looks like:

• Securing a visible sponsor at the top who uses the system's numbers in management meetings from week one, so that the ERP becomes the only version of the truth.
• Naming a process owner inside the client for every core flow, with the authority to retire the parallel spreadsheets.
• Designing the first weeks around the few transactions that matter most, so people experience a win before they experience the full scope.
• Training people in their own process and their own data, not in generic screens.
• Staying present after go-live, because the culture is tested in month two, not in week one.

The technology has become generous: powerful, open, and now inexpensive to shape. What it cannot do is want to change on the organisation's behalf. That remains a human job, and it is the job that an ERP partner should be judged on.

If you are a growing business that has stayed away from ERP because of cost or time, those reasons are largely gone. The remaining question is whether your organisation is ready to work differently, and we are glad to help you answer it.