Diagnosing the causes of ERP problems

What does “the ERP is not working well” actually mean?

It can describe several different situations.

For example:

• the system produces an incorrect result;
• data is unreliable;
• too much manual intervention is needed;
• employees regularly bypass ERP;
• the same data is entered in several places;
• the process is too slow;
• ERP does not support an important business case;
• it could support it, but is not configured correctly;
• or the business has changed while the system has not kept pace.

These should not be grouped into one category.

A software defect, incorrect master data, a flawed business rule and a poorly designed process each require a different solution.

The first task is to separate the causes.

1. Start with a specific business case, not a general complaint

“The stock is wrong” is not yet an investigable statement.

Choose a specific case instead.

For example:

For a particular order, ERP showed 120 units available, but only 80 could actually be issued.

You can then identify:

• the product involved;
• the affected order;
• when the event occurred;
• the expected stock status;
• what the system actually showed;
• who used or changed the data;
• and which events preceded the discrepancy.

A traceable business event is needed in place of a general complaint.

2. Define the expected and actual results

Every investigable problem needs two clear statements:

What should the correct result have been?

and

What actually happened?

Unless this difference is defined precisely, you cannot establish whether a subsequent fix has resolved the problem.

For example:

Expected result:

The remaining quantity on a partially delivered order stays reserved.

Actual result:

The partial delivery releases the entire reservation.

This is a specific, reproducible operational deviation.

3. Trace the complete data journey

Incorrect data displayed in ERP may not have originated there.

Trace:

data creation → recording → modification → processing → integration → business rule → display → user decision

Different errors can arise at each point.

For example, investigate:

• where the original data came from;
• when it entered the system;
• who recorded or modified it;
• which business rule processed it;
• whether import or integration occurred;
• which configuration applied;
• whether there was manual intervention;
• and which system or data source is authoritative.

An incorrect result on screen is often the consequence of an earlier event.

4. Compare a failed case with a successful one

Comparing a failed business case with one that completed correctly is a powerful investigation method.

If two apparently similar orders behave differently, that difference is valuable information.

Compare, for example:

• master data;
• customer or product settings;
• order type;
• permissions;
• timestamps;
• integration events;
• pricing and discount rules;
• stock status;
• user actions;
• and the exceptions applied.

The question is:

which condition distinguishes the failed case from the successful one?

5. Separate the possible causes

Kyntrax examines the “ERP is not working well” problem across several distinct layers.

Process

Is the system doing what was requested, but the process itself is flawed?

For example, an unnecessary approval point or unjustified manual step may slow operations.

Data

Is the system processing correctly, but using incorrect, incomplete or late data?

For example:

• wrong unit of measure;
• incorrect price;
• missing supplier lead time;
• outdated customer data;
• inaccurate stock information.

Business rule

Is it clearly defined what the system must do under which conditions?

Two employees may give different “correct” answers to the same business situation.

That is not necessarily a technical problem.

Configuration

Could ERP support the required behaviour if it were configured correctly?

This matters because a configuration problem may not justify launching an entire system project.

Permissions and roles

Can the right person access the right function and information at the right time?

Permissions that are too narrow or too broad can both cause operational problems.

Integration

Does data pass correctly from one system to another?

Check for:

• missing events;
• delays;
• duplication;
• incorrect event order;
• incorrect data mapping;
• failed processing.

User activity

Does system usage match the intended operating model?

This is not about automatically blaming users.

When employees repeatedly use the same workaround, there is usually a reason.

The workaround itself is operational evidence.

Software limitations or defects

Of course, the system itself may:

• malfunction;
• be unable to support the required process;
• be technologically obsolete;
• fail to scale;
• or no longer be reasonably adaptable.

But this should be demonstrated rather than assumed.

Not every spreadsheet signals ERP failure — but every workaround deserves investigation

A company managing key processes in Excel alongside ERP is an important signal.

It does not, on its own, prove that ERP is inadequate.

Ask:

• Why was this spreadsheet created?
• What function does it serve?
• Which data does it contain that ERP does not?
• Who maintains it?
• Which data source is authoritative?
• What would happen if the spreadsheet disappeared?
• Does it bypass a genuine system limitation or keep a flawed process alive?

Such parallel solutions often show precisely where the official system and actual operations have diverged.

Which evidence should you rely on?

Memory and user impressions alone are insufficient when investigating ERP problems.

Look for specific operational records.

The aim is not simply to find evidence that “ERP is bad”.

It is to identify which cause best explains the actual deviation.

Illustrative example

Suppose the same order appears twice in ERP.

The symptom is clear:

a duplicate order.

But several causes are possible.

1. Integration problem

The external system sent the same event twice.

2. Faulty processing logic

ERP processed the same event twice.

3. User re-entry

The user did not see the initial import result in time and created the order again manually.

4. Process problem

There is no clear rule for when an imported order is considered accepted.

All four cases can look identical on screen:

two orders instead of one.

Yet the required fix is completely different.

Therefore:

the same symptom does not imply the same cause.

Why is it risky to blame ERP too quickly?

An expensive solution may address the wrong problem.

For example, stock information may be inaccurate because:

• physical movements are recorded late;
• several parallel stock records exist;
• reservation rules are unclear;
• or order changes do not reach the warehouse in time,

in which case a new ERP alone may not solve the problem.

A company may replace its system while moving the same operational defect onto a new platform.

This is one of the most expensive mistakes an ERP replacement can involve.

When is repair justified, and when might replacement be justified?

Replacement becomes a sound option when there is evidence of a gap between a critical operational requirement and ERP's realistic capabilities that cannot reasonably be closed.

For example, where the system:

• cannot adequately support a critical business process;
• cannot reliably handle a necessary integration;
• requires disproportionate cost for business-critical changes;
• has technological limitations that obstruct operations;
• or presents a greater business risk to retain than to replace.

By contrast, an isolated case of:

• incorrect master data;
• poor configuration;
• an unclear process;
• a permissions problem;
• or a repairable integration fault

does not establish that a new ERP is needed.

ERP replacement should be based on a demonstrated operational gap, rather than dissatisfaction alone.

How can you verify that the cause has really been found?

A plausible explanation is not yet a proven root cause.

The suspected cause must be tested.

Ideally:

1. the original problem can be reproduced;
2. the triggering condition can be identified;
3. a controlled change to that condition removes the problem;
4. the original business case completes correctly;
5. related exceptions remain valid;
6. and the fix creates no new problem elsewhere.

This distinguishes root-cause investigation from “we changed a setting and it seems to work now”.

When can an ERP problem be considered resolved?

The disappearance of an error message is not enough.

You should be able to identify:

• the symptom;
• the expected behaviour;
• the actual behaviour;
• the cause of the deviation;
• the change made;
• how it was checked;
• and the result demonstrating that the problem is gone.

If the cause is unknown, the symptom may have disappeared while the problem remains unresolved.

The Mirror assessment: is it a software debugging service?

No.

The Kyntrax Mirror is not a source-code debugger and does not replace technical fault investigation by the ERP vendor or developer.

The Mirror has a different purpose:

uncovering the connections within business operations.

It examines, among other things:

• processes;
• information flows;
• data sources;
• roles and responsibilities;
• decision points;
• work outside the system;
• exceptions;
• and workarounds that have developed around ERP.

If the investigation suggests a technical system fault, detailed source-code, database or infrastructure analysis becomes a separate technical task.

The important distinction is:

the Mirror assessment does not try to prove that ERP is at fault.

It seeks to identify the real cause of the operational problem.

What does an operational diagnosis of ERP problems provide?

A thorough investigation can distinguish:

• genuine software defects;
• configuration problems;
• data problems;
• integration faults;
• process problems;
• responsibility or rule issues;
• and genuine gaps in system capability.

This supports a decision on whether the next step should be:

• process improvement;
• data correction;
• configuration;
• integration repair;
• training;
• system development;
• or ERP replacement.

The Kyntrax approach

Kyntrax does not assume that a complaint has already identified the cause.

When a company says:

“the ERP is bad”

the next question is not:

“what should we replace it with?”

It is:

“what exactly is not working, where does the deviation arise, and what establishes its cause?”

The Kyntrax Mirror looks for connections across the business's operations.

It examines ERP as part of an operational system in which people, processes, data, rules and other technologies work together, rather than as isolated software.

This allows the next decision to move beyond assumptions.

Establish the cause first. Then decide what should change.