How is this different from an ERP audit?

An audit tells you what the system does. Root cause work tells you which decision produced it and who has the authority to change it. The second one is what actually unblocks a group; the first one usually produces a document.

What if the answer is that we should not build anything?

Then that is the deliverable, and it is a good outcome. The most expensive customisation is the one that works perfectly and answers a question nobody needed answered.

Do we need this before a migration?

It is the cheapest moment to do it. A migration forces every unmade decision into the open at once, usually late and usually as a technical ticket. Settling them first is the difference between a NAV to Business Central migration that lands and one that needs rescuing.

Our close takes two weeks. Is that a root cause question?

Almost certainly. A slow close is rarely an accounting problem in a multi-entity group. It is usually intercompany flows or a chart of accounts that diverged, both of which are unarbitrated decisions rather than system defects.

Will this create conflict internally?

It surfaces conflict that already exists and is currently being paid for silently, every period. Bringing it into a room where someone can settle it is the point, not a side effect. We are not telepathic though: be direct with us and we will handle the rest cleanly.

Root Cause Consulting for Business Central

Root Cause Consulting

In a single company, a bad process is annoying. In a group, it gets replicated per entity, and every year it stays it gets more expensive to unwind. That is why the same symptom costs ten times more here than the vendor’s case study suggests.

So we do not start with your system. We start with the question behind the request — the one that has usually never been asked out loud, which is exactly why the answer keeps costing you money.

We challenge the assumption, compare it against how groups in your industry actually operate, and follow the chain down until it stops moving. It normally stops three layers below where the ticket was written, and it is normally governance, not software.

Then we tell you what we found. Including when the honest answer is that you do not need us.

What you get in writing

A written diagnosis: the symptom, the chain beneath it, the cause
The decision that was never made, stated plainly enough for your board to argue with
What to fix, what to leave alone, what to stop paying for — per entity where it differs
A recommendation with a number against it, including “do nothing” when that is right

Start with clarity

What root cause work actually changes

The request is never the problem

Someone asks for a report. What they need is to stop reconciling two systems that disagree. Someone asks for a field. What they need is for one person to own a number that currently has three owners.

Take the request literally and you will deliver it correctly, on time, and change nothing. The system grows, the symptom stays, and in eighteen months the same person asks for a second report.

So the first move is to find the question behind the request, which is usually the one nobody has said out loud. That is uncomfortable work, and it is the reason it gets skipped.

In a group, a bad process is not annoying. It is multiplied

In a single company a clumsy process costs a few hours a month and everybody routes around it. Across eight subsidiaries the same process is replicated eight times, diverges locally, and every year it survives makes it more expensive to unwind.

That is why the same symptom costs an order of magnitude more here than in the vendor case study, and why group-level ERP problems resist the fixes that work fine at company scale.

It is also why the cause is so often a governance gap rather than a design flaw. Nobody decided the group would work one way, so each entity decided locally, and the ERP faithfully encoded eight answers to one question.

Symptoms that almost always mean something else

A close that takes fifteen days is rarely an accounting problem. It is usually intercompany flows that were never agreed, reconciled by hand at the end of every period because agreeing them would have required an arbitration nobody wanted.

A consolidation the CFO fixes manually in a spreadsheet is not a reporting gap. It is a chart of accounts that was harmonised on paper and left divergent in practice.

Five subsidiaries solving the same problem five different ways is not a training issue. It is the absence of a decision, made visible. The ERP is not the problem. It is the record of a decision nobody made.

What we do instead of writing a specification

We trace the symptom back to the decision that produced it, and then we do the part most consultants avoid: we name who owns that decision. Not a team, a person, at the level with the authority to settle it.

Then we get it settled before anything is configured. A decision taken in a steering committee costs a meeting. The same decision discovered in a configuration workshop costs a phase, and the same decision discovered after go-live costs a rescue.

Sometimes the outcome is that no software should be built at all. That is a successful engagement, and we would rather tell you that than sell you a build.

This is what Clarity Before Code means in practice

It is not a preference for less code. We know when to build a thousand objects and when to build zero, and most consultants get both decisions wrong in the same project.

It means the code you end up with is deliberate and correctly sized, because the question it answers was actually asked. If the need is not clear, the solution is necessarily wrong, however well it is built.

The test is simple. Six months after go-live, can someone name the rule each customisation encodes, and is that rule still true? If not, you did not build a system. You built a record of a conversation nobody finished.

Questions people ask before engaging

How is this different from an ERP audit?: An audit tells you what the system does. Root cause work tells you which decision produced it and who has the authority to change it. The second one is what actually unblocks a group; the first one usually produces a document.
What if the answer is that we should not build anything?: Then that is the deliverable, and it is a good outcome. The most expensive customisation is the one that works perfectly and answers a question nobody needed answered.
Do we need this before a migration?: It is the cheapest moment to do it. A migration forces every unmade decision into the open at once, usually late and usually as a technical ticket. Settling them first is the difference between a NAV to Business Central migration that lands and one that needs rescuing.
Our close takes two weeks. Is that a root cause question?: Almost certainly. A slow close is rarely an accounting problem in a multi-entity group. It is usually intercompany flows or a chart of accounts that diverged, both of which are unarbitrated decisions rather than system defects.
Will this create conflict internally?: It surfaces conflict that already exists and is currently being paid for silently, every period. Bringing it into a room where someone can settle it is the point, not a side effect. We are not telepathic though: be direct with us and we will handle the rest cleanly.

Why Asio for this

We only do Business Central, and we work almost exclusively in multi-entity landscapes. Depth in one system, in your shape of business, beats coverage of five.
We are not anti-customisation. We are anti-careless customisation — the kind that hides an absent process and breaks on upgrade, then breaks again in every subsidiary that copied it. We know when to build a thousand objects and when to build zero. Most consultants get both calls wrong.
Root cause work needs senior people. There is no junior version of telling a group CFO the problem is not the software.
We turn down projects we cannot do properly. A bad Business Central programme damages everyone, us included.

Start with clarity

Make Space for Growth – Not More Chaos

Whether you’re scaling with Excel, stuck in legacy systems, or buried in a broken ERP – we help you clear the fog.

Start the Clarity Form