# Fit-Gap Analysis: [Package name and process scope]

> Vendor-neutral fit-to-standard and fit-gap analysis for adopting a
> packaged business application (ERP, CRM, HCM, ITSM or another SaaS
> suite). It records how the standard product was demonstrated against
> the in-scope business processes, classifies every requirement as a
> fit, a configuration fit or a gap, evaluates each gap against an
> ordered set of resolution options (adopt the standard, configure,
> extend, integrate, buy, defer or reject), captures effort, risk and
> upgrade impact, records the decisions of the design authority and
> hands the approved items to the delivery backlog. The workshop
> pattern follows the "fit-to-standard" concept of packaged-application
> delivery methods (SAP Activate Explore phase; the fit-to-standard and
> fit-gap analysis guidance in the Microsoft Dynamics 365 implementation
> guide). Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Write one analysis per package and release, with one register that
  grows wave by wave. Do not start a separate file per workshop: the
  value is a single list that the design authority can sort, count and
  decide.
- Start from the standard product, not from the legacy system. The
  question in every workshop is "can the business run this step the way
  the package does it?", not "how do we rebuild what we have?".
- Fill sections 1 to 3 before the first workshop, section 4 during the
  workshops, sections 5 to 8 straight after each wave, and sections 9
  and 10 at the design authority meeting.
- Every gap needs a business owner, a quantified impact and an explicit
  decision. A gap without a decision is a hidden scope increase.
- Related documents: Discovery Workshop Plan
  (`requirements/discovery-workshop-plan`), SAP S/4HANA Solution Design
  (`architecture/sap-s4hana-solution-design`), WRICEF Object
  Specification (`architecture/wricef-object-specification`), Build vs
  Buy Analysis (`architecture/build-vs-buy-analysis`), Architecture
  Decision Log (`architecture/architecture-decision-log`), Solution
  Estimate (`project/solution-estimate`), Traceability Matrix
  (`requirements/traceability-matrix`).
-->

## Document control

<!-- Guidance: Identify the package, its release and the deployment model, because a fit in one release can be a gap in another. A new release baseline or a new process area is a new major version. -->

| Field | Value |
|---|---|
| Document ID | [FGA-001] |
| Programme | [Programme name] |
| Package and edition | [Product, edition] |
| Release baseline demonstrated | [Release or version, for example 2602 (SAP), 2026 release wave 2 (Dynamics 365), Winter '27 (Salesforce), Zurich (ServiceNow)] |
| Deployment model | [Public SaaS / Private cloud / On-premise] |
| Delivery phase | [Explore (SAP Activate) / Initiate (Success by Design) / Analysis / Design], wave [n] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@solution-architect] |
| Approvers/reviewers | [@business-process-owner], [@product-owner], [@design-authority-chair], [@enterprise-architect] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |
| Related documents | [Solution design], [Requirements register], [Backlog tool and project key] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Business sponsor | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Process owner, [area] | [@name] | [Decision] | YYYY-MM-DD |
| Design authority chair | [@name] | [Decision] | YYYY-MM-DD |
| Solution architect | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft: scope, rules and workshop plan |
| 0.5 | YYYY-MM-DD | [@name] | *Example:* Wave 1 results (finance, procurement) added |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* All waves complete; decisions approved by the design authority |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Purpose, scope and baseline](#1-purpose-scope-and-baseline)
2. [Principles and classification rules](#2-principles-and-classification-rules)
3. [Workshop plan and participants](#3-workshop-plan-and-participants)
4. [Standard demonstration results](#4-standard-demonstration-results)
5. [Fit-gap register](#5-fit-gap-register)
6. [Gap assessment](#6-gap-assessment)
7. [Gap resolution options](#7-gap-resolution-options)
8. [Effort, risk and upgrade impact](#8-effort-risk-and-upgrade-impact)
9. [Decisions](#9-decisions)
10. [Backlog handoff](#10-backlog-handoff)
11. [Traceability and metrics](#11-traceability-and-metrics)
12. [Risks, issues and open points](#12-risks-issues-and-open-points)
13. [Sign-off](#13-sign-off)
14. [Glossary and references](#14-glossary-and-references)

## 1. Purpose, scope and baseline

<!-- Guidance: State what the analysis must decide and which processes it covers. Questions: which release did we demonstrate, in which system, with which preconfigured content? Pitfall: scope defined by legacy transactions instead of business processes, which drags legacy design into the workshops. -->

### 1.1 Purpose

This analysis determines how far the standard [Package name] supports
the in-scope business processes of [Organisation], which differences
remain, and how each difference will be resolved. Its outputs are an
approved fit-gap register, a decision record for every gap and a
prioritised list of backlog items for the build phase.

### 1.2 Process scope

Scope is expressed as a process hierarchy. Level 1 is the end-to-end
value chain, level 2 the process group, level 3 the business process
that is demonstrated in a workshop.

| Process ID | Level 1 | Level 2 | Level 3 process | Owner | Wave |
|---|---|---|---|---|---|
| PRC-010 *(Example)* | Source to pay | Purchasing | Purchase requisition to purchase order | [@procurement-lead] | 1 |
| PRC-011 *(Example)* | Source to pay | Invoicing | Supplier invoice with three-way match | [@ap-lead] | 1 |
| PRC-020 *(Example)* | Order to cash | Sales | Standard sales order with credit check | [@sales-ops-lead] | 2 |
| PRC-021 *(Example)* | Order to cash | Billing | Periodic billing for service contracts | [@billing-lead] | 2 |
| PRC-030 *(Example)* | Record to report | Close | Month-end close and intercompany reconciliation | [@controller] | 1 |
| [PRC-NNN] | [Level 1] | [Level 2] | [Process] | [@owner] | [n] |

### 1.3 Out of scope

| Item | Reason | Where it is handled |
|---|---|---|
| *Example:* Payroll for country [X] | Remains on the current provider | Interface only, see integration design |
| *Example:* Data warehouse reporting | Separate analytics programme | Analytics roadmap |
| [Item] | [Reason] | [Document] |

### 1.4 Baseline

| Item | Value |
|---|---|
| System used for demonstrations | [Starter, sandbox or trial tenant name] |
| Preconfigured content activated | [Vendor best-practice content, industry template, partner template] |
| Localisation versions | [Countries] |
| Data used | [Vendor sample data / sample of client data] |
| Known release changes before go-live | [Next vendor release dates and what they may change] |

## 2. Principles and classification rules

<!-- Guidance: Agree these rules with the sponsor before the first workshop and read them out at the start of each one. Pitfall: no rule on who carries the burden of proof, so every legacy habit becomes a requirement. -->

### 2.1 Principles

| ID | Principle | Consequence |
|---|---|---|
| FGP-001 *(Example)* | Adopt the standard process unless a gap is justified by regulation, a quantified business case or a differentiating capability | The requester of a deviation proves its value; the standard needs no justification |
| FGP-002 *(Example)* | Change the process before changing the product | Process change is evaluated first for every gap |
| FGP-003 *(Example)* | No modification of vendor code or vendor data structures | Only vendor-supported extension points are allowed (section 7) |
| FGP-004 *(Example)* | One global process with local variants only where law requires them | Local variants carry a legal reference in the register |
| FGP-005 *(Example)* | Reports are met first by standard analytics and self-service | A custom report is accepted only after the standard analytics content is shown to fail |
| [FGP-NNN] | [Principle] | [Consequence] |

### 2.2 Classification scheme

| Class | Code | Meaning | Typical evidence |
|---|---|---|---|
| Fit | FIT | Standard process works as demonstrated with the preconfigured content | Demonstrated step accepted by the process owner |
| Fit with configuration | CFG | Standard process works after setting values, rules or master data the product already provides | Configuration item named, values listed |
| Gap, process change | GPC | The business adopts the standard and changes its own way of working | Change impact noted and accepted by the owner |
| Gap, extension | GEX | A capability is missing and is added through a supported extension, integration, report, form or workflow | Resolution option selected in section 7 |
| Gap, third-party | GTP | A certified add-on or marketplace product closes the gap | Product and licence named |
| Gap, deferred | GDF | Valid gap that is moved to a later release or phase | Target release named |
| Gap, rejected | GRJ | Request declined; the standard stands | Reason recorded and communicated |

### 2.3 Decision tree

Apply the questions in this order for every requirement raised in a
workshop. The value threshold is the weighted score from section 6.

```mermaid
flowchart TD
    A[Requirement from workshop] --> B{Standard step demonstrated and accepted?}
    B -- Yes --> FIT[FIT]
    B -- No --> C{Product setting or rule closes it?}
    C -- Yes --> CFG[CFG]
    C -- No --> D{Mandatory by law or contract, valued at or above threshold, or approved in the middle band?}
    D -- No --> E{Will the owner accept the standard process?}
    E -- Yes --> GPC[GPC process change]
    E -- No --> GRJ[GRJ rejected, escalate if disputed]
    D -- Yes --> F{Certified add-on available at acceptable cost?}
    F -- Yes --> GTP[GTP third-party]
    F -- No --> G{Needed for first go-live?}
    G -- Yes --> GEX[GEX extension]
    G -- No --> GDF[GDF deferred]
```

## 3. Workshop plan and participants

<!-- Guidance: Plan workshops by end-to-end process, not by module, so hand-offs between teams are demonstrated. Questions: who can decide in the room? Is the system prepared and the script rehearsed? Pitfall: a demonstration on an unprepared system, which turns into a configuration session. -->

### 3.1 Waves and sessions

| Session ID | Wave | Processes | Date | Duration | Facilitator | Demonstrator | Recorder |
|---|---|---|---|---|---|---|---|
| WS-01 *(Example)* | 1 | PRC-010, PRC-011 | YYYY-MM-DD | 2 x 3 h | [@lead-consultant] | [@procurement-consultant] | [@analyst] |
| WS-02 *(Example)* | 1 | PRC-030 | YYYY-MM-DD | 3 h | [@lead-consultant] | [@finance-consultant] | [@analyst] |
| WS-03 *(Example)* | 2 | PRC-020, PRC-021 | YYYY-MM-DD | 2 x 3 h | [@lead-consultant] | [@sales-consultant] | [@analyst] |
| [WS-NN] | [n] | [Processes] | YYYY-MM-DD | [h] | [@name] | [@name] | [@name] |

### 3.2 Roles and RACI

| Activity | Process owner | Key users | Functional consultant | Solution architect | Product owner | Design authority |
|---|---|---|---|---|---|---|
| Prepare scripts and system | I | C | R | C | A | I |
| Run demonstration | C | C | R | C | A | I |
| Classify requirement | A | C | R | C | C | I |
| Propose resolution option | C | I | R | A | C | I |
| Estimate effort and risk | I | I | R | A | C | I |
| Decide on gap | C | I | C | C | R | A |
| Add item to backlog | I | I | C | C | A | I |

R = responsible, A = accountable, C = consulted, I = informed. For gaps
under the threshold in section 9.2 the product owner is accountable for
the gap decision and the design authority is informed.

### 3.3 Preparation checklist

- [ ] Process scope and level 3 process list confirmed for the wave.
- [ ] Demonstration system refreshed, users and sample data prepared.
- [ ] Test script or storyboard rehearsed end to end by the demonstrator.
- [ ] Participants briefed on the principles in section 2 and the classification scheme.
- [ ] Pre-reading sent: current pain points, volumes, legal constraints per country.
- [ ] Decision makers for each process confirmed as attending.
- [ ] Capture tool ready (this register or the backlog tool), with ID ranges agreed.

## 4. Standard demonstration results

<!-- Guidance: Record each demonstrated step and the reaction, even when it fits. A complete record of fits is what protects the scope later. Pitfall: recording only gaps, which makes the fit rate unknowable. -->

| Step ID | Process | Standard step demonstrated | Outcome | Notes | Register IDs |
|---|---|---|---|---|---|
| DEM-010-01 *(Example)* | PRC-010 | Create requisition from catalogue | FIT | Accepted as shown | FG-001 |
| DEM-010-02 *(Example)* | PRC-010 | Approval of requisition by cost centre owner | CFG | Approval levels by amount and category needed | FG-002 |
| DEM-010-03 *(Example)* | PRC-010 | Convert requisition to purchase order automatically | FIT | Source list needed in master data | FG-003 |
| DEM-011-01 *(Example)* | PRC-011 | Supplier invoice with three-way match and tolerance | CFG | Tolerances per company | FG-004 |
| DEM-011-02 *(Example)* | PRC-011 | Invoice capture from PDF | GEX | Current scanning provider must deliver into the package | FG-005 |
| DEM-020-01 *(Example)* | PRC-020 | Sales order with credit check | GPC | Business will drop the manual credit override list | FG-006 |
| DEM-021-01 *(Example)* | PRC-021 | Periodic billing plan | GEX | Usage-based price component not supported in the standard plan | FG-007 |
| DEM-030-01 *(Example)* | PRC-030 | Intercompany reconciliation | FIT | Standard matching rules accepted | FG-008 |
| [DEM-NNN-NN] | [PRC] | [Step] | [Class] | [Notes] | [FG-NNN] |

## 5. Fit-gap register

<!-- Guidance: This is the master list. One row per requirement, one ID for life, never reuse IDs. Questions per row: what exactly is needed, why, for whom, how often, and what happens if we do nothing? Pitfall: solution-shaped requirements ("add a field to screen X") instead of need-shaped ones ("record the customs tariff number per line"). -->

### 5.1 Register

| ID | Process | Requirement (need, not solution) | Source | Class | Priority | Driver | Resolution option | Owner | Status |
|---|---|---|---|---|---|---|---|---|---|
| FG-001 *(Example)* | PRC-010 | Requesters choose items from supplier catalogues | WS-01 | FIT | Must | Efficiency | Standard | [@procurement-lead] | Closed |
| FG-002 *(Example)* | PRC-010 | Requisitions above set amounts need a second approver per category | WS-01 | CFG | Must | Internal control | RO-02 configuration | [@procurement-lead] | Approved |
| FG-003 *(Example)* | PRC-010 | Approved requisitions become orders without manual work when a source exists | WS-01 | FIT | Should | Efficiency | Standard plus master data | [@procurement-lead] | Closed |
| FG-004 *(Example)* | PRC-011 | Price and quantity tolerances differ per company | WS-01 | CFG | Must | Internal control | RO-02 configuration | [@ap-lead] | Approved |
| FG-005 *(Example)* | PRC-011 | Scanned invoices arrive as draft supplier invoices | WS-01 | GEX | Must | Efficiency | RO-05 integration | [@ap-lead] | Approved |
| FG-006 *(Example)* | PRC-020 | Sales staff override credit blocks without approval | WS-03 | GPC | Could | Habit | RO-01 adopt standard | [@sales-ops-lead] | Approved |
| FG-007 *(Example)* | PRC-021 | Service contracts bill a fixed fee plus monthly metered usage | WS-03 | GEX | Must | Revenue | RO-04 side-by-side extension | [@billing-lead] | In assessment |
| FG-008 *(Example)* | PRC-030 | Intercompany balances are matched before close | WS-02 | FIT | Must | Compliance | Standard | [@controller] | Closed |
| FG-009 *(Example)* | PRC-030 | Statutory report for country [X] in the local format | WS-02 | GTP | Must | Law | RO-06 certified add-on | [@controller] | In assessment |
| FG-010 *(Example)* | PRC-020 | Order confirmation shows the legacy layout | WS-03 | GRJ | Could | Habit | Rejected, standard form with logo | [@sales-ops-lead] | Rejected |
| [FG-NNN] | [PRC] | [Need] | [WS] | [Class] | [Must/Should/Could/Won't] | [Driver] | [RO-NN] | [@owner] | [Status] |

### 5.2 Field definitions

| Field | Rule |
|---|---|
| Requirement | One need per row, written as an outcome the business must achieve; no screen or table names |
| Source | Workshop session ID, regulation, policy or stakeholder interview |
| Priority | MoSCoW, set by the process owner; "Must" needs a stated consequence of not meeting it |
| Driver | Law or regulation, contract, internal control, revenue, cost, customer experience, efficiency, habit |
| Status | New, In assessment, Approved, Rejected, Deferred, Closed (delivered or confirmed standard) |

## 6. Gap assessment

<!-- Guidance: Score every gap with the same rubric so the design authority compares like with like. Questions: what does it cost not to close the gap? Who is affected and how often? Pitfall: scoring done by the consultant alone; the owner must agree the business value score. -->

### 6.1 Scoring rubric

| Criterion | 1 (low) | 3 (medium) | 5 (high) | Weight |
|---|---|---|---|---|
| Business value | Convenience only | Measurable saving or revenue in one area | Material saving, revenue or customer impact across areas | 30% |
| Mandatory driver | None | Internal policy | Law, regulation or signed contract | 25% |
| Frequency and reach | Rare, few users | Weekly or one department | Daily, many users or customers | 15% |
| Workaround available | Simple workaround exists | Workaround with manual effort | No workaround | 15% |
| Strategic differentiation | Commodity process | Some advantage | Core differentiator | 15% |

Weighted score = sum of (score x weight). *Example* threshold: gaps
scoring 3.5 or more proceed to resolution design; gaps below 2.0 are
proposed for rejection; the band in between is decided case by case.

### 6.2 Scored gaps

| Gap ID | Value | Mandatory | Frequency | Workaround | Differentiation | Weighted score | Recommendation |
|---|---|---|---|---|---|---|---|
| FG-005 *(Example)* | 4 | 1 | 5 | 3 | 1 | 2.80 | Proceed: middle band, decided on high volume and low cost |
| FG-007 *(Example)* | 5 | 5 | 3 | 5 | 3 | 4.40 | Proceed |
| FG-009 *(Example)* | 2 | 5 | 1 | 5 | 1 | 2.90 | Proceed: legal obligation overrides score |
| FG-010 *(Example)* | 1 | 1 | 3 | 1 | 1 | 1.30 | Reject |
| [FG-NNN] | [n] | [n] | [n] | [n] | [n] | [n.nn] | [Recommendation] |

*Example* arithmetic for FG-007: 5 x 0.30 + 5 x 0.25 + 3 x 0.15 + 5 x
0.15 + 3 x 0.15 = 1.50 + 1.25 + 0.45 + 0.75 + 0.45 = 4.40.

## 7. Gap resolution options

<!-- Guidance: Evaluate the options in this order and stop at the first one that is acceptable. The order is the policy: it pushes work towards options that survive vendor upgrades. Pitfall: jumping straight to custom code because the team knows how to build it. -->

### 7.1 Ordered options

| Option | Name | Description | Upgrade risk | Typical use |
|---|---|---|---|---|
| RO-01 | Adopt the standard | The business changes its process to the standard one | None | Habit-driven requests |
| RO-02 | Configure | Use product settings, rules, master data or workflow configuration | Very low | Approval levels, tolerances, document types |
| RO-03 | Key-user or low-code extension | Add fields, logic or simple apps with vendor tools for business administrators | Low | Extra attributes, validation rules |
| RO-04 | Developer extension on supported points | Code on published extension points, in the platform or side by side on the vendor's extension platform | Low to medium | Missing calculations, new apps, complex workflows |
| RO-05 | Integration | Connect a system that already does the job through supported interfaces | Low to medium | Scanning, tax engines, payment providers |
| RO-06 | Certified add-on | Buy a marketplace product certified for the release | Medium (depends on vendor) | Country reports, industry functions |
| RO-07 | Report or analytics | Meet an information need with standard or self-built analytics | Low | Management views, operational lists |
| RO-08 | Defer | Accept the gap for the first release and plan it later | None now | Valid but not urgent |
| RO-09 | Reject | Decline the requirement | None | Low score, habit |
| RO-10 | Modify vendor code | Change delivered code or data structures | High, often unsupported | Not allowed under FGP-003; needs a waiver |

### 7.2 Option equivalents by product family

Use these names to translate the neutral options. Product names change
often: check the vendor's current documentation.

| Neutral option | SAP S/4HANA family | Microsoft Dynamics 365 | Salesforce | ServiceNow |
|---|---|---|---|---|
| RO-02 Configure | Configuration in the implementation or customising tools | Parameters and setup forms | Setup and declarative settings | Configuration of forms, rules and catalogues |
| RO-03 Key-user or low-code | Key user extensibility apps | Power Platform (Power Apps, Power Automate, Copilot Studio) | Salesforce Flow and other declarative tools | Workflow Studio (Flow Designer) and App Engine Studio |
| RO-04 Developer extension | ABAP Cloud on-stack or side by side on SAP BTP | X++ extensions (finance and operations), plug-ins and PCF controls (customer engagement), Azure services | Apex and Lightning Web Components | Scoped applications |
| RO-05 Integration | SAP Integration Suite with released APIs | Dataverse and Azure integration services | Platform APIs, events and integration products | Integration Hub and REST APIs |
| RO-06 Certified add-on | SAP Store partner solutions | Microsoft AppSource | AppExchange | ServiceNow Store |

### 7.3 Options analysis per gap

| Gap ID | Options considered | Preferred | Reason | Rejected options and why |
|---|---|---|---|---|
| FG-005 *(Example)* | RO-05, RO-06 | RO-05 | Current scanning provider has a certified connector; no new contract | RO-06: second capture product duplicates the current one |
| FG-007 *(Example)* | RO-01, RO-04, RO-06 | RO-04 | Usage pricing is a commercial differentiator; side-by-side keeps the core standard | RO-01: loses revenue model; RO-06: no add-on supports the tariff structure |
| FG-009 *(Example)* | RO-06, RO-07 | RO-06 | Certified add-on is maintained for legal changes | RO-07: team would own legal change monitoring |
| [FG-NNN] | [Options] | [RO-NN] | [Reason] | [Why not the others] |

## 8. Effort, risk and upgrade impact

<!-- Guidance: Estimate with ranges and record the run cost, not just the build cost. Questions: what does each extension cost per vendor release? Who maintains it after go-live? Pitfall: counting build days only, which makes custom work look cheaper than it is over five years. -->

| Gap ID | Size | Build effort (person-days) | Run effort per year | Licence or subscription | Upgrade impact | Delivery risk | Dependency |
|---|---|---|---|---|---|---|---|
| FG-005 *(Example)* | S | 8 to 12 | 3 | Existing contract | Low: standard API | Low | Provider sandbox access |
| FG-007 *(Example)* | L | 45 to 70 | 20 | Extension platform runtime | Medium: depends on billing API stability | Medium | Metering data from the network platform |
| FG-009 *(Example)* | M | 10 to 15 | 2 | Add-on subscription | Vendor-maintained | Low | Add-on certified for target release |
| [FG-NNN] | [XS-XL] | [range] | [n] | [Cost item] | [Impact] | [Risk] | [Dependency] |

Size bands (*Example*): XS under 3 days, S 3 to 15, M 15 to 40, L 40 to
100, XL over 100 person-days. Any XL item is split or escalated before a
decision.

### 8.1 Five-year cost view for material gaps

| Gap ID | Build cost | Run cost x 5 years | Licence x 5 years | Total | Value over 5 years | Decision support |
|---|---|---|---|---|---|---|
| FG-007 *(Example)* | USD 46,000 | USD 65,000 | USD 25,000 | USD 136,000 | USD 900,000 | Value exceeds cost by a wide margin |
| [FG-NNN] | [Amount] | [Amount] | [Amount] | [Amount] | [Amount] | [Note] |

*Example* inputs for FG-007: 57.5 build days and 20 run days per year
at USD 650 per day give 37,375 plus 65,000; build includes USD 8,625
for testing and documentation, so build is USD 46,000. Licence is USD
5,000 per year.

## 9. Decisions

<!-- Guidance: Present gaps to the design authority in batches with the recommendation, the score and the cost. Record the decision, conditions and the date. Pitfall: decisions taken in corridors and never recorded, so the same gap returns in every steering meeting. -->

### 9.1 Decision log

| Decision ID | Gap IDs | Decision | Conditions | Decided by | Date | Recorded in |
|---|---|---|---|---|---|---|
| FGD-001 *(Example)* | FG-006, FG-010 | Rejected; adopt standard | Owner to communicate the process change | Design authority | YYYY-MM-DD | Minutes DA-04 |
| FGD-002 *(Example)* | FG-005 | Approved RO-05 | Connector version certified for target release | Design authority | YYYY-MM-DD | Minutes DA-04 |
| FGD-003 *(Example)* | FG-007 | Approved RO-04 for release 1 | Business case signed by sales director; architecture decision record raised | Steering committee | YYYY-MM-DD | ADR-012 |
| [FGD-NNN] | [FG-NNN] | [Decision] | [Conditions] | [Body] | YYYY-MM-DD | [Reference] |

### 9.2 Escalation path

```mermaid
flowchart LR
    W[Workshop team] -->|classification disputed| PO[Product owner]
    PO -->|cost over threshold or cross-process| DA[Design authority]
    DA -->|scope, budget or policy waiver| SC[Steering committee]
    SC -->|decision| DA
    DA -->|decision recorded| R[Fit-gap register]
```

Escalation rules (*Example*): the product owner decides gaps under 15
person-days inside one process; the design authority decides larger or
cross-process gaps and every RO-04 to RO-06 option; the steering
committee decides waivers to principle FGP-003 and any change to budget
or go-live date.

## 10. Backlog handoff

<!-- Guidance: Convert each approved item into a backlog item the build team can estimate and test. Questions: is the acceptance criterion testable? Is the item typed so the right specification template is used? Pitfall: handing over the workshop notes instead of items that meet a definition of ready. -->

### 10.1 Item mapping

| Gap ID | Backlog item | Type | Specification | Acceptance criteria | Release |
|---|---|---|---|---|---|
| FG-002 *(Example)* | CFG-PUR-014 | Configuration | Configuration workbook | Requisition of USD 12,000 in category IT routes to the cost centre owner and the IT category manager | R1 |
| FG-005 *(Example)* | INT-AP-003 | Interface | WRICEF Object Specification (`architecture/wricef-object-specification`) | Scanned invoice appears as a draft within 5 minutes with supplier, amount and order reference filled | R1 |
| FG-007 *(Example)* | EXT-BIL-001 | Enhancement | WRICEF Object Specification | Monthly invoice shows fixed fee plus usage at the contracted tariff; totals equal the metering file | R1 |
| FG-009 *(Example)* | ADD-FIN-002 | Add-on | Vendor installation guide | Statutory report for period YYYY-MM validated by the local accountant | R1 |
| [FG-NNN] | [Item ID] | [Type] | [Spec] | [Criteria] | [Release] |

### 10.2 Definition of ready for gap items

- [ ] Linked to an approved decision (FGD-NNN) and a process ID.
- [ ] Requirement written as a need with a measurable acceptance criterion.
- [ ] Resolution option and target technology recorded.
- [ ] Estimate range and run cost agreed by the build lead.
- [ ] Test data and test owner named.
- [ ] Security, data protection and audit needs noted.
- [ ] Dependencies (interfaces, master data, other items) listed.

## 11. Traceability and metrics

<!-- Guidance: Trace every requirement from source to test so nothing is lost between the workshop and go-live. Track the metrics per wave and show them to the steering committee. Pitfall: measuring the number of workshops held instead of the fit rate and the decision backlog. -->

### 11.1 Traceability matrix

| Requirement | Process | Session | Decision | Backlog item | Design document | Test case | Status |
|---|---|---|---|---|---|---|---|
| FG-002 *(Example)* | PRC-010 | WS-01 | Standard config | CFG-PUR-014 | Configuration workbook | TC-PUR-031 | Built |
| FG-005 *(Example)* | PRC-011 | WS-01 | FGD-002 | INT-AP-003 | WRICEF spec INT-AP-003 | TC-AP-012 | In test |
| FG-007 *(Example)* | PRC-021 | WS-03 | FGD-003 | EXT-BIL-001 | WRICEF spec EXT-BIL-001 | TC-BIL-005 | In build |
| [FG-NNN] | [PRC] | [WS] | [FGD] | [Item] | [Doc] | [TC] | [Status] |

### 11.2 Metrics

| Metric | Definition | Wave 1 | Wave 2 | Total | Target |
|---|---|---|---|---|---|
| Fit rate | (FIT + CFG) / all requirements | *Example:* 80% (24 of 30) | [n%] | [n%] | [n%] |
| Gap rate | (GEX + GTP) / all requirements | *Example:* 10% (3 of 30) | [n%] | [n%] | [n%] |
| Process change rate | GPC / all requirements | *Example:* 7% (2 of 30) | [n%] | [n%] | [n%] |
| Rejection rate | GRJ / gaps raised | *Example:* 17% (1 of 6) | [n%] | [n%] | [n%] |
| Decision latency | Median days from raise to decision | *Example:* 9 | [n] | [n] | [n] |
| Extension count by type | Count per WRICEF type | *Example:* I 1 | [n] | [n] | [n] |

*Example* check for wave 1: 30 requirements, of which 24 are FIT or
CFG, 3 GEX or GTP, 2 GPC and 1 GRJ; 6 gaps were raised (all except FIT
and CFG), so the rejection rate is 1 of 6.

## 12. Risks, issues and open points

<!-- Guidance: List what could invalidate the analysis: a vendor release changing a fit, an absent decision maker, an unconfirmed legal need. Link major risks to the project RAID log. Pitfall: open points with no owner or date. -->

| ID | Type | Description | Impact | Owner | Due | Status |
|---|---|---|---|---|---|---|
| FGR-001 *(Example)* | Risk | Next vendor release changes the standard billing plan, which may close or widen FG-007 | Rework of the extension | [@solution-architect] | YYYY-MM-DD | Open |
| FGR-002 *(Example)* | Issue | Tax owner absent from WS-02; tax requirements unconfirmed | Late gaps in close process | [@controller] | YYYY-MM-DD | Open |
| FGR-003 *(Example)* | Open point | Legal confirmation that the country [X] report format is mandatory | Could change FG-009 to deferred | [@legal-counsel] | YYYY-MM-DD | Open |
| [FGR-NNN] | [Type] | [Description] | [Impact] | [@owner] | YYYY-MM-DD | [Status] |

Major items are copied to the RAID Log (`project/raid-log`).

## 13. Sign-off

<!-- Guidance: Each process owner signs for their area: they confirm the fits, accept the process changes and agree the decisions on their gaps. Pitfall: sign-off by the programme manager on behalf of the business. -->

| Process area | Process owner | Fits confirmed | Process changes accepted | Gap decisions agreed | Date |
|---|---|---|---|---|---|
| *Example:* Source to pay | [@procurement-lead] | Yes | Yes | Yes, with condition on FG-005 | YYYY-MM-DD |
| *Example:* Record to report | [@controller] | Yes | Not applicable | Pending FGR-003 | YYYY-MM-DD |
| [Area] | [@owner] | [Yes/No] | [Yes/No] | [Yes/No] | YYYY-MM-DD |

## 14. Glossary and references

<!-- Guidance: Define the classes and methods used. List the method and product documentation consulted with the date checked. -->

### 14.1 Glossary

| Term | Meaning |
|---|---|
| Fit-to-standard | Workshop method that demonstrates the preconfigured product and asks the business to adopt it, recording only the differences |
| Fit-gap analysis | Classification of each requirement against the standard product and the resolution of each difference |
| Delta requirement | Requirement not met by the standard product as demonstrated |
| Clean core | Design policy that keeps vendor code and data structures unmodified so upgrades stay predictable (term popularised by SAP; other vendors speak of upgrade-safe or supported extensions) |
| Design authority | Body that decides on design questions and deviations from principles |
| WRICEF | Workflows, Reports, Interfaces, Conversions, Enhancements, Forms: the object types that close gaps in packaged-application projects |
| Definition of ready | Conditions a backlog item meets before the build team accepts it |

### 14.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| SAP Activate methodology, Explore phase overview, learning.sap.com | Checked 2026-10-23 | Fit-to-standard workshops, delta requirements, backlog |
| Dynamics 365 implementation guide, "Optimize your implementation with a fit-to-standard and fit-gap analysis", learn.microsoft.com | Page dated 2026-01-30, checked 2026-10-23 | Fit-to-standard and fit-gap practice |
| MoSCoW prioritisation (DSDM Agile Project Framework, Agile Business Consortium) | Check current edition | Priority field |
| SAP S/4HANA Solution Design (`architecture/sap-s4hana-solution-design`) | This library | SAP-specific use of this analysis |
| [Internal design principles] | [Version] | [Use] |

## Standard and licence note

Structure aligned with the fit-to-standard concept used in packaged
application delivery methods, in particular the Explore phase of SAP
Activate and the fit-to-standard and fit-gap analysis guidance in the
Microsoft Dynamics 365 implementation guide.
Only method, phase and product names are used; no workshop materials,
accelerators, checklists or text from those methods are reproduced.
The classification scheme, resolution options, scoring rubric and all
other text are original and written for this collection. Check the
current vendor documentation before use. SAP, SAP Activate, SAP
S/4HANA, SAP BTP, Microsoft, Dynamics 365, Power Platform, Salesforce
and ServiceNow are trademarks of their owners; this template is not
affiliated with or endorsed by them. Template licence: MIT.