Contact Info
Gap Analysis
What does an ERP gap analysis consultant do?
An ERP gap analysis consultant compares your agreed requirements with what a specific ERP does out of the box, and decides how each gap should be handled. I build a fit-gap matrix, classify every gap as configuration, customization, workaround or process change, and size the effort and risk of each. The result shows you the real shape of an implementation before you commit.
Last reviewed by Vikas Saroj
Every ERP fits some of your requirements out of the box and misses others. The question is not whether gaps exist, but which ones matter, how they will be closed and what that costs in effort, risk and future maintenance. As an ERP gap analysis consultant, I answer that question requirement by requirement.
I test your prioritized requirements against the platform you are considering or have already chosen, using real scenarios rather than feature lists. Each gap gets a decision: configure it, customize it, work around it, or change the process so the gap disappears.
That last option is often the most valuable. Your ERP should fit your business, but sometimes the best fix is to stop doing something the old way.
What I Do
Gap analysis can be run during selection, to compare platforms, or after selection, to shape the implementation scope.
A structured matrix listing every requirement, its priority, the fit status on the target platform, the proposed resolution and the owner, so the whole picture fits on one working document.
I test requirements through end-to-end business scenarios in a demo or trial environment, not by asking the vendor yes-or-no questions. Scenarios reveal gaps in the handoffs between modules.
For each gap, a recommendation between configuration, customization, workaround or process change, with the reasoning and trade-offs explained in plain language for business owners.
Each gap is rated for effort, complexity, risk and long-term maintenance impact, so you can see which gaps are trivial and which ones will shape the budget and timeline.
An independent second opinion on customizations proposed by an implementer: whether each is truly needed, whether standard features could do the job, and what it means for upgrades.
Running the same fit-gap exercise across shortlisted platforms gives a fair, like-for-like view of which ERP needs the least bending to fit your business.
My Consulting Journey
Business first, technology second. You can hire me for one step - a BRD, a gap analysis, a vendor shortlist - or for the whole journey.
How I Work
Set the baseline for comparison
Confirm prioritized requirements
Build end-to-end test scenarios
Agree platform and edition
Set up demo or trial access
Test each requirement in context
Scenario walkthroughs
Fit, partial fit or gap
Evidence for each rating
Vendor clarification questions
Choose the right fix per gap
Resolution option per gap
Effort and risk sizing
Process change proposals
Final fit-gap report
The biggest surprises in ERP projects rarely come from the features a platform clearly has. They come from requirements that were assumed to be standard and turned out not to be: a particular approval chain, a pricing rule, a way of costing production, a statutory report, an integration nobody priced. By the time those gaps appear in testing, they are expensive to fix and hard to negotiate.
ERP gap analysis brings those surprises forward. It answers three questions for each requirement:
The answers shape almost everything that follows: the implementation scope, the proposal you should expect from a partner, the number of customizations you will carry for years, and the realistic timeline. A platform that looks cheaper on license cost can become the more expensive choice once its gaps are sized honestly.
Gap analysis only works if the requirements are clear and prioritized. If yours are not yet, start with ERP requirements gathering or a BRD.
The fit-gap matrix is the central artifact of the analysis. It is a working document, usually a structured spreadsheet, that every stakeholder can read. Each row is one requirement, and the columns typically include:
| Column | What it records |
|---|---|
| Requirement ID and description | Taken from the BRD or requirement log |
| Process area and owner | Who is accountable for the decision |
| Priority | Must, Should, Could or Won't |
| Fit status | Fit, partial fit or gap |
| Evidence | How the rating was confirmed: scenario, demo, documentation |
| Resolution | Configure, customize, workaround or process change |
| Sizing | Relative effort, complexity and risk |
| Open questions | Items still to confirm with the vendor |
I rate fit by testing scenarios in a demo or trial environment wherever possible. A vendor's "yes, we do that" is recorded, but it is not treated as evidence until it has been seen working with your kind of data and your process steps. Partial fits get the same scrutiny as gaps, because a feature that covers most of a requirement can still break the process at the step that matters.
Once a gap is confirmed, the important work begins: choosing how to close it. I assess four options for each gap, and the right answer depends on the requirement's priority and the business value behind it.
I discuss process change openly with process owners rather than assuming the software must bend. Many gaps disappear once someone asks why the business does it that way. The design decisions that follow from this step are then written into the ERP solution design.
Not all gaps are equal. A missing field on a form and a missing costing method are both gaps, but one takes minutes and the other can reshape the project. Sizing makes that difference visible.
I size each gap on a relative scale across four dimensions:
The sizing is relative, not a price. It tells you where the weight of the implementation sits and gives you a sound basis for questioning partner estimates. If one partner treats a large gap as trivial, that is worth a conversation before you sign. If two platforms have similar license costs but very different gap profiles, the sizing makes the long-term difference clear, which is why I often run gap analysis as part of an ERP evaluation or vendor selection.
When the implementation partner runs the gap analysis, there is a structural tension. Too many gaps may make the project look risky before the contract is signed, and gaps that need custom development are also billable work. Neither pressure means anyone acts in bad faith, but both can quietly influence how gaps are rated and resolved.
As an independent ERP gap analysis consultant, I have no license or development hours to sell. I can tell you that a proposed customization is unnecessary because a standard feature already covers it, or that a gap the vendor called minor will in fact touch costing, inventory and reporting at once. I can also tell you when the platform is simply the wrong fit.
Gap analysis is equally useful for a live system. If your ERP is running on a pile of customizations and workarounds, a fresh fit-gap review against your current processes often shows what can be returned to standard. See my ERP health check for that angle, or contact me to scope a gap analysis for a platform you are considering.
Tell me about your business and current systems. I’ll suggest the most sensible first step.
Book a Consultation
Not sure which ERP you need?
Share your business requirements with me and I will help you understand the right process, architecture and platform before implementation.
FAQ
A fit-gap analysis compares each business requirement with what a specific ERP platform does as standard. Each requirement is rated as a fit, partial fit or gap, and every gap gets a resolution: configuration, customization, a workaround or a change to the business process, along with an estimate of effort and risk.
Ideally twice. A lighter version during selection helps compare shortlisted platforms fairly. A detailed version after selection, before the implementation contract is finalized, sets the real scope. Doing it only after signing leaves you with less room to negotiate or change direction.
No. Customization makes sense for processes that genuinely differentiate your business or for legal requirements a platform cannot meet. The problem is unnecessary customization that copies old habits. Each one adds build, testing and upgrade effort, so it should be a deliberate choice with a clear business reason.
I size gaps on a relative scale for effort, complexity, risk and maintenance impact rather than quoting prices. That sizing gives you a sound basis to challenge or compare implementation partner estimates, which will depend on their own rates and delivery approach.
Yes. A fresh fit-gap review of a live ERP against your current processes often shows customizations that can be retired, standard features nobody is using, and gaps that are still being covered by spreadsheets. It is a useful input before an upgrade or optimization project.
Every business is different. Share where you are today and what you want to fix, and I’ll tell you honestly whether and how I can help.
Book a Consultation
Insights
Book a Consultation
Book a consultation to talk through your processes, systems and goals. I’ll reply with practical next steps - no obligation.
