Fit Gap Analysis

SAP Fit-Gap Analysis

This skill enforces evidence-based classification of every business requirement against SAP standard capability so that no gap is accepted without a resolution strategy, no fit is assumed without proof, and no custom development is committed without assessing clean core impact.

Iron Laws

1. NEVER CLASSIFY AS FIT WITHOUT PROVING STANDARD COVERS IT. "SAP probably handles this" is not a Fit classification. A Fit requires a named standard transaction, configuration path, or Best Practice process that demonstrably covers the requirement without modification.
2. NEVER ACCEPT A GAP WITHOUT A RESOLUTION STRATEGY. Every gap — whether configuration, development, process, or partial — must carry an explicit resolution: configure, extend (BAdI/BTP), workaround, or accept. An unresolved gap is a project risk, not a classification.
3. ALWAYS ASSESS CLEAN CORE IMPACT. Every Gap-Dev classification must be evaluated against SAP's clean core principles. Custom code inside the core (Z-programs, modifications) must be challenged. Side-by-side BTP extensions are preferred.
4. NEVER ESTIMATE GAP EFFORT WITHOUT A TECHNICAL APPROACH. A gap effort estimate without a named technical approach (configuration path, BAdI, BTP service, interface) is a guess. Do not produce numbers without first defining how the gap will be resolved.
5. INVOLVE THE PROCESS OWNER IN EVERY CLASSIFICATION. Business requirements classified without process owner confirmation are consultant assumptions. Classifications must be reviewed and signed off by the accountable business stakeholder before the matrix is baselined.

Rationalization Table

Red Flags

Watch for these phrases in your own reasoning — each one signals you are about to violate an Iron Law:

• "SAP standard handles this..." → Name the transaction or config path. If you cannot, stop.
• "We can decide on the resolution later..." → Every gap needs a resolution strategy now.
• "The client wants custom code for this..." → Have you assessed the clean core impact? Stop.
• "Let me estimate this gap at roughly X days..." → What is the technical approach? Define it first.
• "The IT team confirmed this as a Fit..." → Did the process owner confirm it? Flag as provisional until they do.
• "This is a minor gap, we can absorb it..." → Minor gaps have effort and risk. Classify and size it.
• "We'll just build a workaround..." → Workarounds must be documented with effort, owner, and risk rating.
• "This gap is the same as the last project..." → Requirements vary by client. Validate it here.

Hard Gates

Checklist

Step 1: Gather and Number All Requirements

Before any classification begins, compile the complete requirement set:

• Source documents: Workshop outputs, RFP, AS-IS process documentation, stakeholder interviews
• Numbering convention: Assign a unique ID to every requirement (e.g. FGA-SD-001)
• Traceability: Record the source document and page/section for each requirement
• Scope boundary: Confirm which requirements are in-scope vs. out-of-scope for this project

Evidence: Numbered requirements list with source traceability and scope boundary confirmed. Gate: No classification begins until all in-scope requirements are identified and numbered.

Step 2: Define SAP Standard Baseline

Establish what "standard" means for this project:

• SAP Best Practice Scope Items: Which scope items are activated? Which are the baseline processes?
• SAP Release: S/4HANA version — on-premise, RISE, or Public Cloud (determines available configuration options)
• Country version: Localization requirements (tax, legal, payments) that are standard vs. country-specific
• Industry solution: Any SAP industry add-ons that extend the standard baseline

Evidence: Scope item list with SAP release and country version documented. Gate: No requirement is classified as Fit against functionality that is not confirmed to be in scope for activation.

Step 3: Classify Every Requirement

Apply the five-category classification to every numbered requirement:

Classification Definitions:

For every Gap-Dev, additionally record:

• Technical Approach: BAdI / BTP Side-by-Side / RAP Extension / CDS View / Interface / Report / Modification (flag modifications as high risk)
• Clean Core Impact: None / Low / Medium / High
• Clean Core Justification: Why this approach was selected over a cleaner alternative

Evidence: Every requirement has a classification, and every Gap-Dev has a technical approach and clean core impact rating. Gate: No Gap-Dev row has an empty technical approach column.

Step 4: Define Resolution Strategy Per Gap

For every non-Fit classification, define how the gap will be resolved:

Resolution Options:

Evidence: Every gap has a named resolution strategy with justification. Gate: "TBD" is not a valid resolution strategy. Any requirement with an unresolved strategy is flagged as a project risk.

Step 5: Estimate Effort Per Gap

Size the resolution effort for every Gap-Config and Gap-Dev:

• Gap-Config: Estimate configuration days (Design + Configure + Unit Test)
• Gap-Dev: Estimate development days by phase (Design, Develop, Unit Test, Integration Test) — use three-point (O/R/P)
• Gap-Process: Estimate change management effort (process documentation, training, communication)
• Priority: Assign each gap a priority (Must Have / Should Have / Could Have) — this drives sequencing in Realize

Evidence: Effort estimate per gap with three-point values for Gap-Dev items. Gate: No single-point estimates for Gap-Dev. Complexity and technical approach must justify the estimate.

Step 6: Assess Clean Core Risk Portfolio

Review all Gap-Dev classifications as a portfolio:

• Modification count: How many requirements require core modifications (highest risk)?
• BTP extension count: How many can be resolved via side-by-side BTP extensions?
• Upgrade risk: Which custom developments will be affected by future SAP upgrades?
• Clean core score: Calculate the ratio of clean extensions to total Gap-Dev items

Evidence: Clean core portfolio summary with modification count, BTP extension count, and upgrade risk items flagged. Gate: Any core modification must be escalated to the solution architect and client IT lead before classification is baselined.

Step 7: Review and Sign Off with Process Owners

Conduct fit-gap review workshops with business process owners:

• Walk through each requirement classification with the accountable process owner
• Record agreement or challenge for every classification
• Update classifications based on process owner input
• Obtain sign-off on the baselined fit-gap matrix before Realize begins

Evidence: Sign-off record with process owner name, date, and any classification changes made. Gate: No fit-gap matrix is baselined without process owner review documented.

Deliverable Template

# SAP Fit-Gap Analysis Matrix

## Header
- **Project:**
- **SAP Release / Deployment Model:** [S/4HANA version, On-Premise / RISE / Public Cloud]
- **Analysis Date:**
- **Prepared By:**
- **Process Owner Sign-Off:** [Name, Role, Date]

## Scope Baseline
- **SAP Best Practice Scope Items Activated:**
- **Country Version:**
- **Industry Solution (if applicable):**

## Classification Summary

| Classification | Count | % of Total | Est. Effort (days) |
|---------------|------:|----------:|-----------------:|
| Fit | | | N/A |
| Gap-Config | | | |
| Gap-Dev | | | |
| Gap-Process | | | |
| Partial | | | |
| **Total** | | 100% | |

## Fit-Gap Matrix

| Req ID | Requirement Description | Source | Module | Classification | Resolution | Technical Approach | Clean Core Impact | Priority | Est. Effort (d) O/R/P | Process Owner |
|--------|------------------------|--------|--------|---------------|-----------|-------------------|------------------|----------|-----------------------|---------------|
| FGA-[MOD]-001 | | | | | | | | | / / | |

## Clean Core Portfolio

| Item | Count | Notes |
|------|------:|-------|
| Core Modifications (High Risk) | | |
| BTP Side-by-Side Extensions | | |
| BAdI / Enhancement Spot | | |
| RAP Extensions | | |
| Standard Config Only | | |
| **Clean Core Score** (non-modification Gap-Dev / total Gap-Dev) | | |

## Gaps Requiring Escalation

| Req ID | Issue | Escalation To | Due Date |
|--------|-------|--------------|----------|
| | Core modification proposed | Solution Architect, Client IT Lead | |

## Open Items

| Item | Risk if Unresolved | Owner | Due Date |
|------|-------------------|-------|----------|

Verification

This skill is complete ONLY when ALL of the following are true:

• Every in-scope requirement has a unique ID and source reference
• Every requirement carries one of the five classifications (Fit / Gap-Config / Gap-Dev / Gap-Process / Partial)
• No Fit classification is made without a named standard transaction or configuration path
• Every Gap-Dev has a named technical approach and a clean core impact rating
• Every gap (non-Fit) has an explicit resolution strategy — no TBD entries
• Effort estimates for Gap-Dev are three-point (O/R/P) — no single-point estimates
• Core modifications are flagged and escalated — none accepted without justification
• Process owner sign-off is documented with name, role, and date
• Classification summary totals are complete and consistent with the matrix

Evidence required: Completed fit-gap matrix with all columns populated, clean core portfolio summary, and documented process owner sign-off.

If any verification item is not met, the skill is NOT complete. Do not claim completion.

Next Skill

After completing this skill, invoke:

• solution-architecture — When the fit-gap matrix is baselined and the team moves to designing the solution that resolves confirmed gaps

Conditions for handoff: Fit-gap matrix is signed off by process owners, all gaps have resolution strategies, and Gap-Dev items have technical approaches defined. The solution architect uses the gap portfolio to design the overall solution blueprint.

Cross-References

• project-kickoff — The project scope defined in kickoff determines which requirements are in scope for fit-gap analysis
• estimation — Gap effort estimates from the fit-gap matrix feed directly into the project effort estimate
• process-design — To-be process designs define the business requirements that are classified in the fit-gap matrix
• solution-architecture — Architecture decisions determine which extension patterns are available for Gap-Dev resolution
• sap-architect agent — Dispatch for complex gap resolution decisions involving BTP, integration, or clean core tradeoffs