Gap Analysis Working Skill

What this skill is for

Projects fail when they assume the current state is "mostly fine" and the target state is "well understood." This skill forces a structured comparison: what exists today with evidence, what is required with source, and what is missing with classification. The output is a Gap Analysis Note and Gap Register that tell decision-makers exactly what to build, buy, configure, or train — and who must do it.

When to use this skill

• A project scoping phase needs to move from "we need a new system" to "we need these 17 specific capabilities."
• A post-merger integration must reconcile two different processes, data models, or system landscapes.
• A regulatory compliance assessment asks whether current controls meet new requirements.
• A system replacement evaluation needs to know which current customizations are essential and which are obsolete.
• A process redesign starts and no one has documented what the current process actually produces.
• A data governance maturity assessment shows the organization is at level 1 and needs to reach level 3.

Real work situations

SAP S/4 migration: customizations vs clean core

An organization plans to migrate from SAP ECC to S/4HANA. The target state is "clean core." The gap analysis must compare: current custom transactions, user exits, modified tables, and Z-programs against standard S/4 functionality. Gaps are classified as: retire (standard covers it), refactor (custom still needed but must be compliant), or replace (custom must become extension). Without this classification, the migration either carries dead code or breaks critical processes.

New VAT reporting requirement

A new regulation requires additional fields on every invoice for VAT reporting. The gap analysis compares current invoice structures (header fields, line item fields, tax calculation logic) against the regulatory mandatory fields. Gaps are classified as: missing field, incomplete logic, or ungoverned data source. The closure plan identifies which fields need to be added to the billing document, which tax procedures need updating, and which master data fields need validation.

Integration with new e-commerce platform

A retailer wants to connect a new e-commerce platform to SAP. The gap analysis compares current API capabilities (order creation, stock check, pricing, customer lookup) against required volume and response times. Gaps are classified as: missing endpoint, insufficient throughput, or missing error handling. The closure plan identifies whether to extend existing APIs, build new middleware, or reconfigure SAP.

Inputs required

• Current state documentation, system configuration exports, or Process Analysis Notes.
• Target state requirements with a clear source: regulation, project scope, best practice, or stakeholder decision.
• System configuration exports or screenshots showing current settings.
• Stakeholder interviews confirming current state and target state.
• Regulatory documents or compliance frameworks (if applicable).
• Previous gap analyses or audit reports for the same area.
• Effort estimation guidelines or historical data from similar closures.

Questions to ask

• What exists today that must stop, and what is missing that must be built?
• Which gaps are blocking progress and which are cosmetic or nice-to-have?
• Who owns the current state, and who will own the target state?
• What is the business cost of not closing this gap: money, time, compliance, reputation?
• Is the target state a requirement or an aspiration? What is the source?
• Which gaps share a common root cause, and can be closed together?
• What must happen first before this gap can be closed?

Working method

1. Define current state with evidence. Document what exists today using system exports, screenshots, process notes, or user demonstrations. Do not rely on memory.
2. Define target state with source. State what is required and where that requirement comes from: regulation, project charter, stakeholder decision, or best practice.
3. Compare and list gaps. For each target element, ask: does the current state have it? If not, that is a gap. If partially, that is also a gap.
4. Classify each gap type. Use: missing (does not exist), incomplete (exists but insufficient), inconsistent (exists but contradicts target), outdated (exists but obsolete), ungoverned (exists but no owner).
5. Assess business impact. For each gap, state what happens because of it: blocked orders, delayed invoices, compliance violation, manual rework.
6. Identify closure approach. Choose from: build, buy, configure, process change, training, or retire. Justify the choice.
7. Assign owner and estimate effort. Every gap must have a person who is responsible for closure and a rough sizing.
8. Document in Gap Analysis Note. One note per major gap area. Link related gaps. Include dependencies and risks.
9. Validate with stakeholders. Confirm that the current state is accurate, the target state is still required, and the closure plan is feasible.

Decision rules

• If current state cannot be verified with evidence, do not assess the gap — verify first.
• If target state is vague or unsourced, the gap is a requirements problem, not a current-state problem.
• If gap type is "missing," check whether it is truly missing or just undocumented before classifying.
• If closure approach is "build," verify that "buy" or "configure" was considered and rejected with reason.
• If many gaps share the same root cause, group them and fix the root cause first.
• If gap closure has no owner, the gap stays open — effort estimates without owners are fiction.
• If a gap closure depends on another gap, sequence them and flag the dependency.

Deliverables

• Gap Analysis Note — One per major gap area. Contains current state, target state, gap description, type, impact, closure approach, effort, owner, dependencies, risks. See template below.
• Gap Register — Consolidated table of all gaps with status, priority, owner, and target date.
• Closure Plan — Sequenced actions with dependencies, grouped by root cause where applicable.
• Risk Register updates — New risks identified during gap analysis: unowned gaps, unverified current state, conflicting target states.

Templates

Gap Analysis Note (compact)

---
artifact: Gap Analysis Note
id: GAP-001
date: YYYY-MM-DD
scope: Process | System | Data | Organization
---

## Current state


## Target state


## Gap description


## Gap type


## Business impact


## Affected stakeholders


## Closure approach


## Effort estimate


## Owner


## Dependencies


## Risks


## Related gaps

Quality checklist

• Every gap has a verified current state with evidence.
• Every gap has a specific target state with a documented source.
• Gap type is classified using the defined taxonomy.
• Business impact is stated in operational or financial terms.
• Closure approach is selected and justified.
• Every gap has a named owner.
• Effort is estimated, even if rough.
• Dependencies between gaps are identified and sequenced.

Common mistakes

• Comparing against an ideal instead of a required state. Consequence: scope inflation. The project tries to reach perfection instead of compliance.
• Assessing gaps without verifying current state. Consequence: gaps are imaginary. Time is spent closing gaps that do not exist.
• Failing to classify gap type. Consequence: wrong closure approach. A missing field is treated as a configuration change when it needs custom development.
• Not assigning owners. Consequence: gaps remain open. The gap register becomes a list of wishes.
• Ignoring dependencies between gaps. Consequence: sequence errors. A team starts building before the data model is ready.

Agent instructions

AI agents should use this skill to produce structured gap assessments before recommending solutions or estimating effort.

• Verify current state with system evidence or user demonstration before writing any gap. Do not rely on documentation alone.
• Separate "missing" from "incomplete" from "outdated." The closure approach depends on the classification.
• Always state the source of the target state. If the source is unclear, flag it as a requirements gap first.
• Group gaps by root cause when possible. Fixing one root cause is cheaper than treating ten symptoms.
• Assign an owner to every gap. If no owner exists, flag a governance gap.
• Produce a Gap Analysis Note per major gap area. Link related notes. Do not bundle unrelated gaps.
• Do not compare against ideal states. Compare against required states with documented sources.
• Link to Atlas diagnostics when gaps relate to SAP processes. For example, invoice verification gaps should reference Invoice Verification Three-Way Match Delays.

Related skills

• Process Analysis Working Skill
• Requirements Elicitation Working Skill
• Change Impact Analysis Working Skill

Related Atlas pages

• SAP Process Audit — Diagnostic context for process gaps.
• Master Data Issues Blocking Sales Orders — Scenario with current/target state gaps.
• Invoice Verification Three-Way Match Delays — Gap scenario in P2P.

Verification status and limitations

This skill is a public working interpretation of gap analysis practices. It is not official BABOK, TOGAF, or SAP documentation. It focuses on practical enterprise and system migration contexts.

Known limitations: the skill requires access to current system evidence and clear target state sources. In environments with poor documentation or shifting requirements, gap analysis becomes a continuous activity rather than a one-time exercise. The skill does not cover formal capability maturity modeling or enterprise architecture gap frameworks.