The question is not just:
How much does the ERP cost?
It is also:
Compared with what will we say things have improved?
What is a baseline?
A baseline is the starting position before a change, measured in a defined way.
It is not a single number.
A usable baseline defines:
what is measured;
how it is measured;
from which data source;
over which period;
at what frequency;
using which definition;
and who is accountable for the reliability of the measurement.
For example, if one goal of an ERP project is faster order processing, “it will be faster” is not a measurable objective.
First, you need to know:
what is the current order lead time?
Where does measurement start?
Where does it end?
Are we using a mean or a median?
Does it include waiting time?
What happens with partial deliveries?
How are exceptions handled?
The measurement definition matters at least as much as the number itself.
Why is the project budget not enough?
The costs of implementing ERP can be added up relatively easily:
licences;
implementation;
integration;
data migration;
consultancy;
internal working time;
training;
infrastructure;
operations.
Benefits, however, rarely appear on a single line.
They may appear as:
shorter lead times;
less manual work;
less rework;
more accurate inventory;
fewer errors;
faster financial closing;
more reliable delivery;
lower inventory levels;
fewer urgent interventions;
or greater business volume that can be processed.
But these can only meaningfully be interpreted as changes if we know the starting position.
ROI and benefits realisation are not the same
The ROI calculated in a business plan is a forward-looking estimate.
The business outcome actually achieved can be measured afterwards.
The two must not be confused.
At the start of a project, we might estimate that automation will save 3,000 working hours a year.
After implementation, we need to measure:
whether working time actually fell;
in which processes;
by how much;
what happened to the released capacity;
and whether the change can actually be attributed to the ERP.
The PMI Benefits Realization Management framework therefore emphasises metrics, KPIs, measurement procedures, responsibilities and subsequent verification of realised benefits, alongside the planned benefits.
What should be measured before implementation?
There is no single ERP metric set for every business.
Measurement should follow from the goals of the particular project.
In a trading company, relevant measures might include:
order lead time;
on-time delivery;
inventory accuracy;
inventory turnover;
number of manual data entries;
manual interventions per order;
rework;
incorrect invoices;
orders changed because of stock shortages;
or complaint handling time.
A manufacturer may need other measures too:
production lead time;
planned versus actual variance;
waiting caused by material shortages;
work order or operation errors;
scrap;
rework;
machine and human waiting time.
The question is always the same:
what business outcome do we expect from the change, and what observable measure would demonstrate that it actually happened?
Hidden cost often matters more than a conspicuous error
Suppose an employee spends five minutes after every order comparing the data in two systems.
Five minutes seems insignificant.
At 100 orders a day, however, that becomes:
500 minutes.
More than eight working hours.
Every working day.
The problem may not appear as a separate cost line.
The business pays for it nonetheless.
The same applies to rework, waiting, manual checks, repeated data entry and error correction.
A baseline should therefore contain more than financial measures.
It should also make the time and resources consumed by operations visible.
An illustrative example
A company implements a new ERP to speed up order-to-cash.
A year later, management asks:
Was it worth it?
The system works.
Invoices are produced.
Employees use it.
But nobody measured the previous lead time.
We do not know how many manual interventions there were before.
We do not know how many there are now.
We do not know the previous error rate.
In this situation, people can give an opinion.
Satisfaction can be measured.
But a reliable claim about operational return on investment is much harder to substantiate.
This is an illustrative example, not a customer result.
Go-live is not the end of measurement
This is particularly important.
ERP's impact changes over time.
Performance may even deteriorate immediately after implementation:
people are learning the system;
errors surface;
data problems may emerge;
processes need refinement.
Gerhard Jurasek's 2026 ERP benefit management research examined four industrial companies. Its qualitative component involved interviews with 44 end users and ERP consultants, while its quantitative component analysed monthly values for 12 KPIs over 24 months after go-live. One important finding is that ERP benefits realisation is time-dependent, and go-live alone cannot be treated as the endpoint of benefits realisation.
A single “before and after” snapshot can therefore also be misleading.
A baseline alone does not prove causation
This is an important limitation.
Suppose delivery punctuality improves by 15% after ERP implementation.
That does not automatically mean:
The ERP improved delivery punctuality by 15%.
Other changes may have happened meanwhile:
organisational restructuring;
a change of supplier;
higher stock levels;
a new logistics partner;
a change in the product portfolio;
a change in staffing;
or lower market demand.
A baseline is therefore necessary for a credible comparison, but not always sufficient for causal attribution.
The measurement plan should also document significant changes happening in parallel.
When should the measurement system be established?
Not at the end of the project.
And preferably not immediately before go-live.
Relevant business measures should be defined while the company is still operating in its current state.
This allows observation of:
normal variation;
seasonality;
different order types;
exceptions;
and data quality.
There is no universally valid baseline period for every company.
The required duration depends on process frequency, variability and seasonality.
How does this connect to Kyntrax?
Kyntrax Mirror investigates current operations.
It looks not only at what happens, but also at where there is:
waiting;
rework;
a manual step;
an information gap;
repeated data entry;
an error;
or a measurable operational loss.
Kyntrax Compass can use these findings to establish a target state and priorities.
Tunnel provides a way to make changes in controlled steps rather than all at once.
The question is therefore not merely:
Is the ERP finished?
It is:
Have the company's operations improved according to the defined measures?
What does this article establish?
An ERP return on investment claim cannot be assessed reliably without an appropriate starting measurement.
However, a baseline neither proves causation on its own nor guarantees a positive ROI.
Its role is to relate the outcome of a change to predefined, verifiable operational measures, rather than impressions alone.
Related Kyntrax Insights: Process assessment before ERP implementation or replacement · Diagnosing the causes of ERP problems · Business diagnostics before digitalisation · Process diagnostics for trading SMEs
Professional background
Project Management Institute: Benefits Realization Management Framework. The framework links planned benefits to measurable KPIs, measurement procedures and responsibilities. Framework
Jurasek, G. (2026): Benefit Management for ERP systems, Journal of Universal Computer Science, 32(6), 826–850. DOI: 10.3897/jucs.165524