Run a Fit-Gap Against the Platform's Real Behavior, Not Its Brochure

Workflow area: Solution Evaluation · Tier: Core · Hands-on time: ~40 minutes

Fit-gap is where implementation budgets are won and lost. Call a gap a fit and you discover mid-build that "supported" meant a partner add-on and a six-figure customization; call a fit a gap and you fund custom work the platform did out of the box. AI collapses the clerical half — reading hundreds of capability pages against hundreds of requirements — but documentation lags releases, glosses over edition differences, and never mentions what the feature is like to actually use. The validation pass is the analysis.

When to use — and when not to

• Use it when evaluating a shortlisted COTS/ERP platform against a baselined requirements setthe classification pass structures the whole assessment and surfaces the questions that matter.
• Use it during implementation scopingthe config-vs-customize-vs-workaround options per gap are the raw material for the phasing and budget conversation.
• Use it on upgrade or re-platform assessmentsrun current requirements against the new version's docs to find where behavior you depend on changed.
• Skip it with unbaselined requirementsclassifying wishes against capabilities produces a confident matrix about nothing; stabilize the requirements first.
• Skip it as the final word on any high-stakes rowa fit that would change licensing, architecture, or a contract gets validated in a sandbox or a scripted demo, no exceptions.
• Skip mixed-edition documentationif you cannot pin docs to the exact edition and version being bought, the classification inherits the ambiguity.

The recipe

1. 1.

   Pin the documentation set. Collect capability docs for the exact product, edition, and version under evaluation — feature guides, configuration references, API docs, and the release notes for the current version. Record the doc versions and download dates. Reject the sales deck as a source; it is scope-free by design.

2. 2.

   Run the classification with forced honesty about evidence. Attach requirements and docs:

   Copy

   You are supporting a fit-gap analysis of [PLATFORM, EDITION,
   VERSION] against the attached requirements.
   
   For each requirement, output one row:
   REQ-ID | requirement summary | classification: FIT / PARTIAL
   / GAP / UNKNOWN | doc evidence (exact section/page cite +
   short quote) | confidence: HIGH (explicit doc statement) /
   MEDIUM (implied or inferred) / LOW (marketing-level wording)
   | for PARTIAL and GAP: closure options tagged CONFIG
   (standard settings), CUSTOMIZE (code/extension), WORKAROUND
   (process change), THIRD-PARTY (add-on required)
   | validation note: what a sandbox test or demo script would
   need to show to confirm this row.
   
   Rules: never classify FIT without a citable doc statement —
   use UNKNOWN if the docs are silent. Flag any row where the
   capability differs by edition or license tier. Do not infer
   capabilities from product names or marketing verbs like
   "seamless" or "powerful".
   

3. 3.

   Sort by consequence, not by classification. Good output looks like:

   Copy

   REQ-041 | approval limits per cost center | PARTIAL |
   Config Guide 7.3: "approval limits configurable per company
   code" — cost-center granularity not mentioned | MEDIUM |
   CONFIG (test granularity) else CUSTOMIZE | VALIDATE: build
   two cost-center limits in sandbox, confirm enforcement
   REQ-055 | retention hold on vendor records | UNKNOWN |
   no statement found in retention or ILM sections | — |
   VALIDATE: direct vendor question, in writing
   REQ-063 | duplicate vendor check on bank details | FIT |
   Master Data Guide 4.1: "duplicate check on configurable
   field sets including bank data" | HIGH | — | VALIDATE: demo
   with a near-match record
   

   Triage: every UNKNOWN and LOW-confidence row, plus every FIT on a requirement that is contractually or architecturally load-bearing, goes on the validation list.

4. 4.

   Validate against the product, not more documents. Three escalating methods: written vendor confirmation citing the requirement verbatim (weakest but contractual), a demo scripted by you where the vendor drives your scenario with your edge case, and a sandbox trial where your team configures it (strongest). Every validated row gets its evidence upgraded — "confirmed in sandbox 12 Aug, screenshot linked" — or its classification corrected. Expect corrections; a fit-gap where no FIT ever got demoted was not validated.

5. 5.

   Cost the gaps as options, not verdicts. For each PARTIAL/GAP, take the closure options to the implementation partner or technical team for rough sizing and to the business owner for tolerability — a WORKAROUND that adds a manual step to a 40-times-a-day task is not a workaround, it is a gap with better manners. The resulting matrix — requirement, classification, validated evidence, closure option, rough cost, owner decision — is the deliverable.

6. 6.

   Baseline it with its assumptions. Record doc versions, sandbox version tested, and validation dates in the matrix header. A fit-gap is a snapshot; the header is what makes it defensible in six months when the platform has shipped two releases.

Make it yours

• Claude long-context over vendor doc sets: attach whole configuration guides; the section-level citations make the audit trail nearly free.
• Platform copilots as a second opinion: SAP/Salesforce/Dynamics in-product assistants answer "can the system do X in this edition" grounded in current docs — useful to cross-check UNKNOWNs, never sufficient for FIT on their own.
• Signavio-class accelerators for process-level fit: where the platform vendor publishes best-practice process content, run process fit at the BPMN level first, then requirement-level fit inside the misfitting processes.
• Spreadsheet matrix as system of record: the classification table lives in the evaluation workbook with filters on classification × confidence × cost — the steering view is "high-consequence rows not yet validated."

Quality check

• Docs are pinnedproduct, edition, version, and download date recorded; no sales-deck citations anywhere in the matrix.
• No FIT without a quoteevery fit row carries a citable doc statement; silence was classified UNKNOWN, not optimistically.
• High-consequence rows validated against behaviorsandbox, scripted demo, or written vendor confirmation, with evidence linked and at least some classifications corrected.
• Edition and license-tier caveats surfacedrows that vary by tier are flagged against the tier actually being purchased.
• Workarounds were tolerability-testedthe affected business owner accepted each WORKAROUND at real volumes, in writing.
• The matrix is versioneddoc versions, test dates, and open validations in the header, so the next analyst knows exactly what this snapshot covers.