Fit-gap analysis, done properly

Whoever writes the gap column writes your bill. The fit-gap document is not an analysis, it is a budget and a decision about how your company will work, and it is normally drafted by the party paid to close the gaps.

Guide  ·  updated 2026-10-17

Every published description of fit-gap analysis ends at a classification: fit, partial fit, gap, not applicable. None of them says who assigns the bucket, how a dispute is settled, or what any bucket costs. So the artefact that is in fact a multi-year budget comes out as a spreadsheet of adjectives, and the number arrives later as a change order.

The pen rule

The conflict of interest sits in plain sight and goes unmentioned. The party that bills for closing gaps is the party that classifies them. In the standard sequence the implementation partner runs the workshops, demonstrates the product and fills in the fit column, and “fit, with a small customisation” is revenue on their side of the table.

Split the pen. The partner may mark Fit, Partial fit or Gap, because that is a statement about their own product and they know it better than you do. You mark what you are going to do about it and who pays. The disposition column never leaves your side of the table, and it is not a column a supplier should be invited to recommend into.

Two controls make the split hold. Require the partner to state a fit percentage in writing, per module, over a register you wrote. And require every Fit claim to cite the demo step or the pilot script that proved it. An unproven Fit is a gap you have not found yet, and it will be found during testing, which is the most expensive place to find one.

What makes a requirement admissible

Pages say “gather requirements”. The reason gap registers are unusable is that nobody says in what form. A line enters the register only if it can be written as five parts:

• Role  who does it
• Trigger  the event that starts it
• Volume and frequency  how often, how many
• Required output  what has to exist afterwards
• Consequence if absent  what the business does instead, and what that costs

Worked, with one company's own measured figures in it rather than any benchmark: AR clerk, on a single cheque covering fourteen invoices across two legal entities, applies the cash in one pass; sixty times a month; without it, three hours a week of manual splitting and a month-end reconciliation break. That line can be estimated. “Cash application must be flexible” cannot.

The form does two jobs at once. It separates a gap from a preference, because a preference cannot be written this way. And it supplies the only inputs a cost estimate can use: frequency, hours, and the failure being avoided. Anything that will not fit the form goes on a wish list, not in the register.

The scar-tissue audit

Before classifying any line, ask for its business reason. If the only answer is “that is how we do it in the old system”, you are looking at a workaround for the previous ERP that has been codified into a process and is now being presented as a requirement. Buying a gap to support it pays twice for the same limitation: once in the old system's licence, once in the new system's build.

Run this pass before the partner sees the register, and expect lines to die in it. Budget time for the argument, because the people defending those lines tend to be the ones who invented the workaround and kept the business running with it. The honest framing is that their workaround was the right answer to the old constraint, and the constraint is what is being removed. The distinction between a process problem and a software problem is the whole subject of outgrown QuickBooks, or outgrown your process, and it is worth settling before you start pricing gaps.

Six dispositions, not four

The standard list offers configure, customise, change the process, and sometimes a workaround. Two resolutions are missing from it, and both are real options a buyer is entitled to take. Each disposition has its own cost shape, and the shape matters more than the quote.

The vendor quote prices the first two. The other four are where the operating model is decided, and none of them appears on an invoice.

The five-year rule

Nobody prices anything. That is the central failure of the published approach, and it is fixable with one arithmetic rule applied to every gap.

For each gap, total: the one-off build, plus the expected number of releases over five years multiplied by the regression hours each release costs, plus the annual manual hours multiplied by a loaded hourly rate, plus the cost of any control weakness being introduced. Then choose the lowest five-year number, not the lowest quote. They are routinely different options.

Do the manual line on the back of an envelope before the meeting, because it is the one people carry in their heads as free. One hour a week is about fifty hours a year and roughly two hundred and fifty over the horizon. Multiply by your own loaded rate, put the result beside the configuration quote, and the comparison is finished: arithmetic, not judgement. The asymmetry is that the manual line keeps accruing after the programme closes and the configuration line stops. Which is also the thing no cost model captures, and the reason this disposition needs a name in the register: a workaround outlives the person who invented it, and by the time anyone asks why the spreadsheet exists, the gap it was built for has been forgotten.

The register, and the six columns that matter

Published templates stop at business requirement, current capability, desired capability, gap, proposed resolution, owner, priority, dependency. Columns, no numbers, no dates, no signature. Use these instead.

That last column deserves its own sentence. Without a trace from gap ID to configuration decision to the test script that proves it, a gap can be agreed in a workshop, forgotten in build, and discovered by a clerk in week one of live running. The register is the index to the test plan, not a document that is filed when design closes.

The order of operations

Fit-gap is said to be done twice: once during selection to compare vendors, once after contract in design workshops. True, and never operationalised. Here is what changes between the passes, and what to do when the second pass contradicts the first.

Step four is the cheap one and the one nobody does. During selection, log every occurrence of “we can do that with a small customisation”, with the date, the person and the requirement. That log is the gap register the vendor will not write, and at contract time it is the most useful document in the room. The demo discipline that produces it, including grading each step Native, Configured or Promised rather than scoring it out of five, is set out in how to run a scripted ERP demo on your own data.

Step six is contractual, not analytical. The second pass will contradict the first, because real data behaves differently from a sandbox and because some Fit claims will not survive a pilot. The contract has to permit scope to be re-negotiated at pilot exit, or the contradiction becomes a change order instead of a correction. Where the pilot sits relative to everything else is the subject of the six stages of erpification, including the bill that arrives at cutover when a stage is skipped.

The spreadsheet test

For every gap marked workaround, ask three questions and write the answers in the register. Who runs it. On which day. What happens when that person is on holiday, or leaves.

No name and no day means the gap is deferred, not resolved. Then count the workarounds. That count is your real operating model after go-live, and it belongs in the business case rather than in an appendix. A programme justified on efficiency that ships with a long list of named manual routines has not been costed, it has been described.

Workarounds are also the disposition with no approval gate. Configuration needs a budget, an extension needs a statement of work, a process change needs a department to agree. A workaround needs nobody, so it wins by default whenever a decision is uncomfortable. That is why it is the one disposition that has to be counted out loud.

The Phase 2 test

“Phase 2” is never named as what it is. A gap moved to Phase 2 without a budget line, a date and an owner has been declined, not deferred. The mechanism is administrative rather than mysterious: Phase 2 has no budget holder, so nothing on it competes for money, and the next planning round is written against next year's priorities rather than last year's deferrals. A list nobody is funded to clear does not get cleared.

The test is a single administrative act. Relabel every such line “declined”, circulate the list to the departments whose requirements they were, and see who signs. The signatures that do not come back, and the objections that come back instead, are the conversation you needed before signing the contract rather than eighteen months into live running.

Count interfaces, not apps

A gap closed with a third-party add-on is routinely recorded as a fit. It is not. It brings a second vendor, a second renewal date, a second release cadence that will not align with the first, at least one data flow, that flow's error handling, and a reconciliation that someone has to own by name.

So count interfaces, not applications. Then give the add-on its own gap register and its own five-year total, because the add-on has gaps too and they are now yours. A bolt-on exempted from this treatment is not a resolution, it is the same gap moved to a different ledger. The data flows and the reconciliations that have to tie are the same ones described in the data migration checklist, and the chart that both systems have to agree on is covered in a chart of accounts you will not regret.

What a fit percentage has to state

Fit percentages are quoted as benchmarks and derived from nothing. The defect is the denominator. A fit score over an unweighted list of requirement lines says nothing, because the lines are not equal: three processes that generate most of the revenue outrank two hundred administrative conveniences, and a high fit score can sit comfortably on top of a gap in all three.

So weight the register before computing anything. Mark the processes the money moves through, score those separately, and state the denominator alongside any number you quote. If the denominator cannot be stated, do not quote a number, and treat a supplier's number without one the same way.

Baseline, then change orders

Scope creep and change orders are treated as a separate topic on separate pages, which is odd, because the fit-gap document is what generates them. Join them up with two rules.

Freeze the register on a dated version at the end of the pilot, signed. Everything added after that is a change order, and a change order is priced with its five-year number attached, not with a number of hours. Then review each one against the Must cap. If a new Must displaces nothing, it was never a Must, and the cap has quietly stopped working. This is the mechanism behind the claim that minimising gaps reduces cost, which otherwise gets asserted with no mechanism at all.

§

No failure statistics here, and why

Competing pages on this query open with a number: a share of ERP projects that miss their targets, a share of features that go unused, a share of companies that customise. This page uses none of them, and the absence is deliberate.

Try to trace one before you quote it, with three questions: who was surveyed, how many of them, and whether the original report can still be retrieved and read. A figure that fails the third question cannot be checked by anyone, which is also how two pages quoting the same number come to disagree about what it measured. Some of these figures measure something that has stopped existing: the share of code modified is not a meaningful quantity in cloud ERP, where extension happens outside the code base by design. The widely quoted “eighty to eighty-five per cent fit” benchmark has no stated denominator, which by the argument above makes it unusable even if it were measured. Where another page would cite a number, this one describes the mechanism instead, because the mechanism is what you can act on. The failure modes themselves, traced to the gate where each was decided and with no failure rate attached, are in why ERP implementations fail, without the statistics.