ERP or separate tools?

Separate tools create silos and re-keying. An ERP unites operations around shared data — but you can get there brick by brick, without replacing everything at once.

Is an ERP only for large companies?

No. Prototyping makes bespoke accessible to smaller companies, without the budget or timeline of a traditional ERP. The criterion is not size but how much double entry you put up with.

How long to put an ERP into service?

A vendor ERP is measured in months, sometimes years. A useful brick prototyped on a precise perimeter is measured in weeks. That is exactly why we do not deliver it in one block.

Do we have to replace our accounting?

Not necessarily, and usually not first. Accounting is the area best served by existing tools; an ERP is better started where disorder costs most — generally stock or production.

What if our processes are not written down?

That is the most common case, and the ERP will reveal them anyway. Better to map them at the start of the project — often the step that produces the most value, before a single line of code.

Can we go back if it does not work?

Brick by brick, yes: each perimeter stays reversible as long as the old system is not switched off. That is the main argument against a global rollout, where going back is in practice impossible.

Operations · Middleware

ERP — Integrated management

The operational core of your company — sales, purchasing, stock, finance — orchestrated around your real processes.

What is it?

An ERP (Enterprise Resource Planning) brings the company’s key functions into one system: sales, purchasing, stock, finance, production. Data entered once flows everywhere.

The founding idea of the ERP is single-instance data. An order entered once commits stock, triggers purchasing, prepares the invoice and feeds accounting, without any information being retyped. All the benefit comes from that, and so does all the difficulty: for data to flow, departments must accept a common definition.

That is why an ERP project is first an organisational project. The software merely sets in stone decisions that, more often than not, had never been made explicitly: who creates an item, when an order is firm, who may change a price.

Market ERPs already carry those decisions, made for someone else. Adopting them means adopting a vendor’s processes; departing from them means paying for configuration. That trade-off is the real decision in an ERP project, well before the choice of product.

Signs you need it

The same information is entered into two different tools by two people.
Theoretical stock and actual stock diverge permanently.
Invoicing means gathering information from three places.
Nobody can say where an order stands without calling someone.
Every month-end takes several days of manual reconciliation.

What is it for?

To hold everything together: the ERP is the frame that links operations, removes double entry and gives a single view of the business. Fewer errors, more time.

The measurable gain is the disappearance of double entry, and with it the discrepancies it produces. These are expensive errors because they surface late: at invoicing, at stock count, or at year end.

The structural gain is traceability. Being able to answer “where does this order stand” in seconds changes the customer relationship, and lets you commit to lead times you used to avoid promising.

It is worth being clear about the cost, though: an ERP constrains. It forbids shortcuts that used to save one person time, in favour of collective reliability. That transfer is the heart of the resistance to change on this kind of project.

Not to be confused with

A CRM: The CRM manages the relationship before the sale — exchanges, opportunities, follow-ups. The ERP manages execution after: order, stock, invoice, accounting. The two connect around the customer.
BI: The ERP produces data as operations happen. BI reads and cross-references it to support decisions. An ERP without BI stays hard to read; BI without reliable operational data has nothing to show.
Accounting software: Accounting records entries. The ERP manages the operations that produce them. Many smaller companies start from an accounting tool and extend it: that works until stock or production becomes the issue.

How it works

01We start from your real processes, not a vendor’s — and note explicitly which ones will have to change.
02We prototype first the modules that hurt most, measured in time lost.
03We make data flow between those modules before adding others.
04We connect them progressively, with no risky big bang, keeping a way back at every step.

The mistakes that cost the most

Launching one global, single-shot project

The ERP “big bang” is the configuration in which projects fail most often: everything changes at once, and the slightest problem becomes blocking for the whole company. Brick by brick, a failure stays local.
Configuring the tool to preserve every existing habit

Reproducing every historical exception produces an ERP that cannot be maintained or evolved. Some habits must change; the task is choosing which, not avoiding all of them.
Underestimating data migration

Duplicate items, obsolete customers, wrong stock: an ERP started on dirty data amplifies the disorder instead of correcting it. Migration is a project in its own right, to be costed as such.
Treating training as an adjustable budget line

An ERP nobody masters gets worked around, and the workarounds recreate exactly the silos you set out to remove. It is the first saving people make, and the most expensive.

What it costs, how long it takes

On an ERP, the licence is almost always the smallest visible part of total cost. The dominant items are configuration, data migration, integration with the tools you keep, and training.

The variables that weigh: how many modules you activate, how far your processes diverge from the tool’s, and how many systems you keep and therefore have to connect. The number of users mainly affects the licence, rarely the implementation.

The decisive lever is scoping. Tool one perimeter, measure adoption, then extend: longer on paper and much shorter in practice, because you do not start over. A traditional ERP is measured in months or years; a useful brick is measured in weeks.

When you don’t need it

If your operations fit in two tools that talk to each other properly, an ERP is a disproportionate answer. The need comes from the number of re-keyings and the number of systems that each claim to hold the same information — not from company size.

With Meridian

Market ERPs impose their processes and cost a lot. We prototype yours in useful bricks, adopted step by step — without the multi-year project.

Frequently asked questions