Fit-Gap Analysis
A fit-gap analysis systematically compares a company's requirements with the standard feature set of a software product, revealing which processes an ERP system already covers (fit) and where gaps remain that must be closed through customizing, process adjustment or additional development.
A fit-gap analysis is the systematic comparison between a company's requirements and the standard feature set of a software product under consideration. It answers the question of how well a system matches actual processes by assigning each requirement to one of two categories: a "fit" means the standard software already meets the requirement; a "gap" describes a shortfall for which the standard offers no solution or only an inadequate one. For every identified gap, the team then decides how to close it - for example through configuration, an adjustment to the company's own process, additional development or a third-party solution.
In the ERP context, the fit-gap analysis is a central tool both in system selection and at the start of a project. During selection it makes competing systems comparable and shows which product requires the least adaptation effort. During implementation it provides the reliable basis for effort estimation, project plan and budget, because every gap is a potential cost and risk driver. Its goal is not to close as many gaps as possible, but to consciously assess each one: often adapting the company's own process to the proven software standard is cheaper and lower-maintenance than expensive custom development.
At a glance
- Comparison of requirements against the standard feature set of a software product
- Each requirement is classified as a fit (covered) or a gap (shortfall)
- For every gap: configure, adjust the process, develop, or do without
- Basis for system selection, effort estimation and blueprint
- Fewer gaps mean less customizing, lower cost and less update risk
How does a fit-gap analysis work?
The starting point is a structured requirements list, usually derived from the requirements specification (Lastenheft) or from a capture of the target processes. Each requirement is checked against the system's standard functions, often in facilitated workshops with business departments and the vendor, supplemented by system demos and test scenarios. The result is documented in a traceable matrix that records the assessment, priority and planned solution for each requirement.
Fit, gap and the shades of grey in between
In practice, a pure yes/no rarely suffices. A finer scale is common: "full fit" (requirement covered by the standard), "partial fit" (achievable with configuration or a workaround) and "gap" (not present in the standard). This gradation matters because a partial fit can often be reached through parametrization without any programming, whereas a genuine gap forces a fundamental decision. In addition, each requirement is weighted by its criticality, so that a gap in a must-have process carries different weight than one in a nice-to-have.
Dealing with gaps: the four options
For every gap there are basically four ways forward. First, process adjustment: the company changes its workflow and follows the software standard - usually the cheapest and most update-safe option. Second, configuration and customizing within the possibilities the vendor provides. Third, genuine custom development or an extension, which causes the highest effort and the greatest maintenance burden. Fourth, deliberately doing without or an organizational workaround outside the system. The fit-gap analysis forces this decision to be made explicitly for each gap, rather than deferring it over the course of the project.
Why the fit-gap analysis matters for ERP projects
The fit-gap analysis is one of the most effective instruments for managing risk in ERP projects. Every unexamined gap that only surfaces during implementation leads to unplanned change requests, schedule slippage and budget overruns. Those who know the gaps early can estimate effort realistically, set priorities and, if in doubt, choose a better-fitting system before contracts are signed.
A second, often underestimated benefit lies in the cost logic over the entire life cycle. Every custom development not only increases one-time project costs but also burdens every future release update, because adaptations must be migrated and tested. A system with a high standard fit therefore significantly lowers the total cost of ownership. The analysis provides the factual basis for the strategic ground rule of modern ERP implementations: as much standard as possible, as much customization as necessary.
The fit-gap analysis in the ERP selection and implementation process
In terms of timing, the fit-gap analysis appears at two points. In the selection phase it serves as a filter: vendors answer the requirements catalogue, and the result feeds into the weighted evaluation matrix. Systems that meet central must-have requirements only with extensive development are eliminated or lose points. This way the decision is driven not by demo impressions but by reliable fit.
After the system decision, the analysis is deepened at the start of the project and culminates in the blueprint or functional specification (Pflichtenheft), in which the vendor describes how each gap is concretely solved. This detailed fit-gap analysis is the bridge between what the company demands and what is actually implemented. It defines the scope of customizing, prevents uncontrolled scope creep and creates an agreed baseline against which acceptances and tests are later checked.
Best practices and typical mistakes
A reliable fit-gap analysis presupposes clean prioritization: not every requirement is equally important, and a gap in a core process weighs more heavily than one in a peripheral function. It makes sense to treat genuine must-haves as knock-out criteria and to back up the assessment with real test scenarios rather than mere vendor assurances. Likewise, every gap should be documented with an effort estimate, a solution path and a responsible owner, so that the matrix remains action-guiding throughout the project.
Among the most common mistakes is the ambition to map every existing process one-to-one and thereby create unnecessarily many gaps - often a supposed gap is merely a cherished habit that the standard solves more elegantly. Just as risky is overlooking gaps because a demo only shows the sunny side, or recognizing them too late. Anyone who prematurely classifies partial fits as full fits systematically underestimates the configuration effort. The art lies in assessing every gap honestly and examining process adjustment as a full-fledged, usually superior option on an equal footing.
Example
Example: wholesaler evaluates two ERP systems via fit-gap analysis
A mid-sized wholesaler with 80 employees wants to replace its ageing system and has two vendors on the shortlist. From the requirements specification, a matrix of around 180 requirements is created, weighted by must, should and could. In facilitated workshops with the live system, the project team classifies each requirement as a full fit, partial fit or gap. System A achieves 92 percent full fit on the must-have processes but has a genuine gap in multi-level batch traceability; System B covers batches but has gaps in commission settlement and marketplace integration.
For each gap, the team weighs the four options. For batch traceability it decides against expensive custom development and in favour of System B plus a lean process adjustment for commissions. The documented analysis feeds directly into the effort estimation and blueprint - and prevents the critical batch gap from only becoming visible at go-live.
Frequently asked questions
Matching ERP systems
Related services
Questions about Fit-Gap Analysis in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.