ERP Gap Analysis
ERP gap analysis costs every deviation from standard three ways — build it, configure around it, or change the process — so that the build-versus-change decision becomes arithmetic rather than opinion. Gap lists without costs are how customisation estates are born.
Turning a gap list into arithmetic
Every ERP implementation produces a gap list. Most gap lists are a column of requirements marked fit, partial or gap, and a recommendation. What they omit is the cost of each option, which is the only information that makes the decision decidable.
A customisation is not a one-time cost. It is a build cost, plus regression testing at every upgrade, plus the knowledge cost of somebody having to understand it, for as long as the system runs. Stated over five years, a substantial share of requested customisations lose to changing the process — and the conversation becomes straightforward once the number is on the page.
You remain free to buy the customisation. The point is that you buy it knowingly, with the reasoning recorded, so that a reviewer in three years can see why.
What a gap analysis covers
Six workstreams. The costing is the deliverable.
Requirement-by-requirement assessment
Each requirement tested against standard capability in the specific release you are implementing, rather than against the product in general.
Three-way costing
Every gap costed as build, as configuration workaround, and as a process change — including the organisational cost of the third, which is real and frequently understated.
Five-year ownership cost
For each proposed customisation: regression testing per upgrade, expected maintenance, and the knowledge dependency it creates. This is the number that changes decisions.
Standard capability challenge
A deliberate examination of whether the requirement is genuinely a requirement or an inherited habit — usually a productive conversation and occasionally an uncomfortable one.
Prioritised recommendation
A recommendation per gap with the reasoning, including what we ruled out and why, so the analysis is auditable rather than assertive.
Decision log
The record of what was decided, by whom, on what basis — written to be readable by someone who was not in the room, three years later.
How a gap analysis runs
Establish the baseline
Standard capability in your target release confirmed, so gaps are measured against what you will actually have.
Assess requirements
Each requirement tested against that baseline, with fit, partial fit and genuine gap distinguished properly rather than collapsed.
Cost each option
Build, configure and change-the-process costed per gap, with five-year ownership cost attached to every proposed customisation.
Challenge and recommend
Requirements tested for whether they are genuine, then a recommendation per gap with the rejected options recorded.
Log decisions
Decisions recorded with owner, date and basis, in a form a later reviewer can follow without context.
The three ways to close a gap
What each costs, and where the cost falls.
| Option | Upfront cost | Ongoing cost | Upgrade risk | Best when |
|---|---|---|---|---|
| Build a customisation | High | Testing every upgrade | You own it | No alternative exists |
| Configuration workaround | Low to moderate | Minor | Low | Standard nearly fits |
| Change the process | Low in money | Organisational effort | None | The requirement is habit |
| Accept the gap | None | Manual effort forever | None | Volume is genuinely low |
What the analysis will say
The recommendation is often to change the process, and that is harder than it sounds — it requires someone with authority to tell a department that a practice of fifteen years is stopping. We provide the arithmetic; we cannot provide the mandate, and an analysis whose recommendations require a mandate nobody holds will sit unimplemented.
We also cannot cost a requirement that has not been stated properly. "Reporting must be flexible" is not a requirement and cannot be assessed against standard capability. Part of this engagement is forcing vague requirements into testable ones, which occasionally reveals that the requirement does not survive being written down precisely.
- A gap list without costs is not an analysis; it is a column of opinions.
- Cost every customisation over five years, including upgrade regression.
- Challenge whether the requirement is genuine or an inherited habit.
- Record the decisions and the rejected options — an auditor will read them.
Questions buyers ask about this
What if the recommendation is to change our process?
It often is, and we will state it with the five-year cost of not doing so. You remain free to buy the customisation; the difference is that you buy it knowingly. The recorded reasoning also protects the decision, because in three years nobody will remember why it was taken.
Is this only for SAP?
No. The method is the same for any ERP, and the arithmetic is the deliverable rather than product knowledge. We work most often on SAP because that is where our depth is, but the discipline transfers directly.
How is this different from a fit-gap in an implementation?
Scope and independence. An implementation fit-gap is run by the party who will be paid to build whatever it identifies. A standalone gap analysis costs the process-change option properly, which is the option a build-oriented engagement has least incentive to recommend.
When should a gap analysis happen?
Before the implementation commits — ideally before the software decision is final, because a large volume of genuine gaps is itself evidence about product fit. Run after design has started, it becomes a change-request exercise, which is a considerably more expensive way to reach the same conclusions.
How long does it take?
Three to eight weeks depending on requirement count and how well the requirements are already articulated. Poorly stated requirements extend it, because turning them into testable statements is prerequisite work rather than optional refinement.
Marked up as FAQPage structured data, matching the visible text exactly.
Still not sure this is the right service?
Answer four questions and we will tell you which one fits — or that none of them do.
Tell us what you are trying to fix.
A short conversation about the objective, the constraints and the timing. If we are not the right fit, we will say so.