fit-gap-analysis — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited fit-gap-analysis (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
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.
| Agent Will Try To... | Why It Seems Reasonable | Why It Fails | Counter |
|---|---|---|---|
| Classify as Fit based on module familiarity | "We've done SD before — standard order-to-cash covers this" | Requirements vary by client. Client-specific pricing rules, approval workflows, or output formats routinely break assumed Fits. | Iron Law 1: Name the transaction or config path. If you cannot, it is not a Fit. |
| Leave a gap without resolution strategy | "We'll decide how to resolve it in Realize" | Unresolved gaps accumulate. By Realize, the backlog is so large that the resolution strategy defaults to custom development without proper evaluation. | Iron Law 2: Every gap row must have a resolution column populated at classification time. |
| Skip clean core assessment for Gap-Dev | "The client wants the custom report — just estimate it" | Custom code inside the core creates technical debt, blocks upgrades, and violates SAP's cloud roadmap. A side-by-side BTP extension may achieve the same result with zero core impact. | Iron Law 3: Every Gap-Dev must include a clean core impact rating (None / Low / Medium / High) and a justification. |
| Estimate effort before technical approach is defined | "The functional consultant can size it at a high level" | Without a technical approach, effort estimates have no basis. A BAdI-based extension might take 3 days; a full RAP object might take 15. The approach drives the number. | Iron Law 4: Technical approach column must be populated before the effort column. |
| Use only IT stakeholders for classification | "The business is too busy for workshops" | IT stakeholders may not know the actual business requirement. Process owners routinely override IT classifications in UAT. Surface the disagreement now. | Iron Law 5: Document the process owner who confirmed each classification. If unavailable, flag it as provisional. |
| Classify every variance as a gap | "If it requires configuration, it must be a gap" | Standard SAP configuration is not a gap — it is the mechanism for delivering Fit. Misclassifying configuration as a gap inflates gap counts and creates false urgency for custom development. | Classification rules: Gap-Config = achievable via standard configuration. Only Gap-Dev and Gap-Process represent true divergence from standard. |
| Ignore partial fits | "It's mostly covered — call it a Fit" | Partial fits carry hidden scope. The uncovered portion becomes a late-stage gap that is more expensive to resolve once design is locked. | Classification rules: Partial fit = its own category. Document what is covered and what is not. |
Watch for these phrases in your own reasoning — each one signals you are about to violate an Iron Law:
<HARD-GATE> DO NOT produce a fit-gap matrix until ALL of the following exist:
</HARD-GATE>
Before any classification begins, compile the complete requirement set:
Evidence: Numbered requirements list with source traceability and scope boundary confirmed. Gate: No classification begins until all in-scope requirements are identified and numbered.
Establish what "standard" means for this project:
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.
Apply the five-category classification to every numbered requirement:
Classification Definitions:
| Classification | Definition | Resolution Path |
|---|---|---|
| Fit | Requirement is fully met by SAP standard without any configuration or development beyond standard activation | No action required |
| Gap-Config | Requirement is met by SAP standard through configuration (org structure, settings, output types, pricing, etc.) | Configure in Realize |
| Gap-Dev | Requirement cannot be met by standard configuration — requires development (BAdI, extension, report, interface, BTP app) | Develop — assess clean core impact |
| Gap-Process | SAP standard delivers the outcome but via a different process than the client currently uses — no system change needed, business process change required | Process change management |
| Partial | Requirement is partially met by standard — some elements are Fit or Gap-Config, other elements require development or process change | Decompose into sub-requirements and classify each |
For every Gap-Dev, additionally record:
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.
For every non-Fit classification, define how the gap will be resolved:
Resolution Options:
| Resolution | Definition | When to Use |
|---|---|---|
| Configure | Use standard SAP configuration to meet the requirement | Gap-Config |
| Extend | Use SAP-endorsed extension points (BAdI, BTP, RAP) — no core modification | Gap-Dev where clean core can be maintained |
| Workaround | Use a different SAP process or combination of standard functions to meet the business outcome without development | Gap-Process or low-priority Gap-Dev |
| Accept | Business accepts that SAP will not meet this requirement as stated — either drop the requirement or re-define it | Low-priority requirements where cost of resolution exceeds value |
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.
Size the resolution effort for every Gap-Config and Gap-Dev:
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.
Review all Gap-Dev classifications as a portfolio:
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.
Conduct fit-gap review workshops with business process owners:
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.
# 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 |
|------|-------------------|-------|----------|This skill is complete ONLY when ALL of the following are true:
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.
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 gapsConditions 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.
project-kickoff — The project scope defined in kickoff determines which requirements are in scope for fit-gap analysisestimation — Gap effort estimates from the fit-gap matrix feed directly into the project effort estimateprocess-design — To-be process designs define the business requirements that are classified in the fit-gap matrixsolution-architecture — Architecture decisions determine which extension patterns are available for Gap-Dev resolutionsap-architect agent — Dispatch for complex gap resolution decisions involving BTP, integration, or clean core tradeoffs~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.