SAP Fit-Gap Analysis Template and Disposition Rules

Decision context

A fit-gap log becomes a custom code backlog when the disposition column is missing or optional. Every gap recorded without an explicit decision about how it will be met defaults to development, because development is the path that requires no argument.

So the template's job is to force the disposition. There are five honest answers: the standard already does this, configuration does this, an extension does this, custom development is required, or the process changes. The fifth is the one that gets skipped and the one that saves the most.

The second job is to attach a cost and an owner to each gap before it is approved, because a gap approved without either becomes a commitment nobody sized.

Columns for the gap log

Keep it to what a scope decision needs. A log with thirty columns is maintained by nobody and read at approval only.

• Gap ID and the business process it belongs to, using the same process identifiers as the test scope, so traceability is possible later.
• Requirement, in business terms, describing the outcome rather than the desired screen.
• Why the standard does not meet it, which is the field that most often reveals the requirement is really a preference.
• Business impact if the gap is not closed, stated concretely. If this cannot be answered, the gap is a preference.
• Disposition: standard, configuration, extension, custom development, or process change.
• WRICEF classification where development is chosen, since workflow, report, interface, conversion, enhancement, and form have very different effort and testing profiles.
• Effort estimate and the estimator, so the number can be challenged.
• Requested by, decided by, and the decision date. A gap with no decider is an open request.
• Priority: required for go-live, or after. This column removes more scope than any other.
• Test reference, so a delivered gap has a case that proves it.

Disposition rules worth writing down

Agree these before the workshops rather than during them, when the room contains the person who wants the gap closed.

• Process change is considered before development, every time, and the reason for rejecting it is recorded. This is the rule that keeps a clean core achievable.
• An extension is preferred to a modification without exception, because a modification returns at every upgrade.
• Development that replicates a standard function that behaves slightly differently is refused by default. Slightly differently is where custom code portfolios come from.
• Anything not required for go-live is deferred, and deferred means it is not in the go-live test scope either.
• Reporting gaps are checked against delivered analytical content before development is agreed, since reporting requests are the largest single category and the one most often already met.
• Every approved development carries an owner who will maintain it, named at approval rather than at handover.

What the log feeds afterwards

The fit-gap log is not a workshop artifact. It is the source for several downstream deliverables, and it only serves them if the identifiers stay stable.

• The development backlog, with the WRICEF classification driving the estimate and the technical design.
• The test scope, since each approved gap needs at least one case and the process identifier is what links them.
• The custom code inventory, which is the input to the clean core discussion after go-live.
• The training and change impact analysis, particularly for every gap dispositioned as a process change.
• The authorization design, where the gap introduces a new activity or a new separation requirement.
• The deferred list, which should be reviewed after go-live rather than quietly inherited by support.

What the workflow must cover

• Traceable dispositions. Keep the link from requirement to disposition to the object that implements it and the test that proves it.
• Custom code inventory from day one. Build the custom object inventory as scope is decided rather than reconstructing it from the system years later.
• Deferred visibility. Keep deferred gaps as a reviewable list with owners rather than as items that disappear into the backlog.
• Coverage check. Report approved gaps that have no test case, which is the most common gap between scope and evidence.

Implementation workflow

Start with a bounded customer scenario and explicit acceptance criteria. Preserve native SAP permissions and accountable review while the software creates a repeatable evidence chain.

1. Agree the disposition rules before the fit-to-standard workshops.
2. Record gaps with business impact, not with a desired solution.
3. Force a disposition and a priority on every gap before approval.
4. Name an owner and an effort estimate for every approved development.
5. Link each approved gap to a test case and review the deferred list after go-live.

Evidence to require

A transformation claim should resolve to observable artifacts, decisions, and execution receipts. Ask for the following evidence in a representative evaluation:

• Gap log with dispositions
• Reason the standard does not meet the requirement
• Business impact statement
• WRICEF classification
• Effort estimate and estimator
• Decision maker and date
• Test case reference
• Deferred list with review date

Boundaries and non-claims

Adranum separates analysis, proposal, human review, package creation, customer-local validation, and production execution. A later state never rewrites the evidence that supported an earlier decision.

• A template cannot stop scope creep. Disposition rules agreed in advance, and a priority column that is actually used, can.
• Effort estimates at fit-gap stage are early and wide. Treat them as ordering information rather than as commitments.
• Whether a requirement is genuinely a business need or a preference is a judgement that belongs to the process owner.

Buyer checklist

• Does every gap have a disposition and a decider?
• Was process change considered and why was it rejected?
• Which gaps are required at go-live and which are deferred?
• Does each approved gap have a named maintenance owner?
• Which approved gaps have no test case?