How to assess whether an ERP is premature

This guide helps an SME answer an expensive question before signing: will this ERP, CRM, MES or WMS solve our problems, or will it freeze them into the system? The core principle is simple: software does not create order. It requires order.

What this guide is for

An ERP codifies processes, data ownership, responsibilities and decision rules. If those elements are clear and stable, the system can accelerate and protect them. If they are ambiguous or different by department, the implementation forces decisions under pressure, with consultants waiting, deadlines running and the organisation tired.

“Premature” does not mean the company does not deserve the tool. It means buying it now may cost more than waiting, because part of the price will be paid as codified confusion.

When to use it

Use this guide when an ERP, CRM, MES or WMS is under consideration, ideally before vendor demos. Demos tend to shift the question from “when?” to “which one?”.

Use it when the argument sounds like “we need order, the system will give it to us”. That is the warning sign. A system can support order, but it rarely creates it.

Use it retrospectively when a system already implemented did not deliver. Often the diagnosis is not only a bad vendor or bad configuration, but premature implementation: missing process decisions, unclear ownership or poor master data.

Before starting

The assessment only works if “not yet” is an acceptable outcome. If the decision has already been made and the company only wants validation, the test will feel irritating.

Put the full cost on the table: licences, implementation, customisations and internal time. Internal time is often not in the vendor quote, but it can match the external cost. This is the number against which missing prerequisites must be weighed.

Operational sequence

Step 1 — Write the problems without naming the system.

Write one sentence per problem: “we do not know margin by job”, “orders get lost between sales and production”, “inventory is unreliable”.

If the list cannot be written and the only statement is “we need to be more structured”, stop. The company may be buying a symbol of order rather than a tool.

Step 2 — Run the process test.

For each problem, ask three questions.

Does the process exist in one version? If sales and production describe different flows, the system will have to choose one or customise around several. Lightweight mapping of the two or three involved flows gives the real answer.

Are responsibilities clear at handoff points? Every ERP field needs someone to feed it and answer for it. Where RACI is unclear, data will be born dirty. An ERP with dirty data is a dirt multiplier.

Is the process stable or changing? Codifying a process under redesign means paying twice: configuration now and reconfiguration later.

Step 3 — Run the data test.

ERP lives on master data: items, bills of material, price lists, customers, suppliers, routings, cost centres.

Ask directly: do these master data exist, are they clean, and does someone own them?

If the answer is “we will clean them during implementation”, translate it: the project will include months of rushed data-cleaning not priced properly, or it will start dirty. Master data work can often be done before the system, on the current tools, and it already creates value.

Step 4 — Test whether the problem is really a tool problem.

For each problem, ask: is this a software problem, or a process and governance problem wearing a software mask?

“We do not know margin” may mean the current system cannot calculate it. Or it may mean nobody records actual hours and costs.

“Orders get lost” may mean the tool is inadequate. Or it may mean nobody owns the sales-to-production handoff.

A useful test is this: could we solve the problem tomorrow with a shared sheet and one rule? If yes, the problem is not primarily technological. The shared sheet can also become a pilot: if the organisation cannot sustain the sheet, it will not sustain an ERP with ten times more required fields.

Step 5 — Summarise in three lists.

Green: problems with one process version, clear responsibilities and ready data. These are good candidates for the first system scope.

Yellow: problems with prerequisites that can be fixed in 60 to 90 days, such as a RACI to clarify, master data to clean, or a flow to unify.

Red: problems with unstable processes, unresolved governance or unclear ownership. Here the system is premature. The red list is as valuable as the green list because it states what not to implement yet, and why.

Step 6 — If proceeding, go small and in sequence.

Start with the green scope. Decide process rules before the consultant arrives. The implementer should configure decisions the company has already made, not make those decisions under pressure.

Treat customisation with suspicion. Each customisation may be a process confusion refusing to be solved. Customisation is sometimes necessary, but it should be justified, not default.

Run one module to stable use before loading the next. Big bang implementations are often failures with a printed calendar.

Expected output

The expected output is the three-list assessment, especially the red list: what not to implement yet, and why doing it now would cost more than postponing it.

Usually the assessment also produces a 60 to 90 day prerequisite plan: process maps, RACI decisions, master data cleaning, and one or two pilots on existing tools. That work is valuable even if the ERP is later postponed.

Mistakes to avoid

Do not buy the system to buy order.

Do not let the implementer make process decisions because the company avoided them.

Do not start with a big bang.

Do not leave master data cleaning to the implementation phase.

Do not treat customisation as the default answer.

Do not use this guide to postpone forever. When the lists are green and the pain is real, premature can become late.

Example

A 45-person metalworking company is about to sign a 140,000 euro ERP project, plus implementation. The pain points are unknown job margins, lost orders between sales and production, and unreliable inventory.

A two-week pre-signature test changes the decision.

Margins are yellow-red: actual hours are not recorded because nobody owns the recording. This is a RACI and behaviour issue before it is a software issue.

Lost orders are red: mapping finds three versions of the order flow, one per salesperson. The ERP would either force one version under pressure or customise all three. The flow is unified first in six weeks, with a handoff owner and a shared module that already removes the lost orders.

Inventory is green: master data are decent, the process is stable and the owner is clear.

The final decision is reduced scope: inventory and purchase cycle first. The rest waits for verified prerequisites. Eight months later, when the job-costing module starts, the data are already alive.

MARTRO connection

In MARTRO’s reading, sequence is a principle. First legibility: one process version, clear responsibilities, data ownership. Then codification.

Software amplifies what it finds. If it finds clarity, it scales clarity. If it finds ambiguity, it makes ambiguity more rigid and expensive. This is why diagnostic reports often include not only what to implement, but what not to implement yet.

The same logic applies to AI: automation above weak governance collapses latency without resolving decision ownership.

Next step

If the test is yellow on flows and responsibilities, continue with process mapping and RACI.

If the doubt concerns tools that automate decisions, continue with decision rights and decision architecture.

If the system is already in place and underperforming, apply the same three lists retrospectively to identify the missing prerequisite.

Frequently asked questions

What does premature ERP mean? It means the company may need an ERP eventually, but the current processes, responsibilities or data are not ready to be codified.

Can an ERP force discipline? It can enforce fields and workflows, but it cannot decide ownership, process sequence or governance for the company without cost. If those decisions are missing, the implementation becomes the place where they are made under pressure.

Should we stop all ERP projects until everything is perfect? No. The point is not perfection. The point is sequence. Start where process, ownership and data are ready; prepare the rest.

What is the most common red flag? “We will clean the data during implementation.” That usually means hidden work, rushed decisions and a dirty start.

Can a shared spreadsheet be a serious pilot? Yes. If a shared sheet plus one rule solves the problem, it tests whether the organisation can sustain the behaviour before paying for a full system.