ERP fit-gap analysis: how to run one with process flows
How to run an ERP fit-gap analysis for SAP, Oracle, Dynamics 365 or NetSuite: walk each process flow against the standard system, classify fits, gaps and workarounds, and get the decisions signed off.
A fit-gap analysis compares how your business needs to work with how the ERP works out of the box, one process at a time, and turns every difference into a recorded decision: adopt the standard, change the process, or build.
The short version
- Start from the standard process, not from the legacy system.
- Walk the flow step by step and stop at every decision point.
- Classify each difference as fit, configuration, process change or extension.
- Put a business reason and an owner on every extension.
- Get the classified gap list signed off before build starts.
A gap is a decision, not a requirement
Most fit-gap analyses fail in the same way. Workshops collect every difference between the legacy system and the new ERP, each difference becomes a requirement, and the gap list grows to several hundred items that the project then tries to build. The ERP ends up customised to look like the system it replaced.
The better approach treats each gap as a decision with three possible outcomes: change the business process to fit the standard, use a configuration or workaround the standard already allows, or build an extension because the difference is genuinely worth money. SAP calls this fit-to-standard, Microsoft's business process catalog and Oracle's methods take the same line, and it works for NetSuite too.
A process flow makes the analysis concrete. Instead of asking 'do you need approvals?', the team walks the standard flow step by step and stops at each decision point: does this release strategy, this matching rule, this credit check work for us? The example below is the SAP procure-to-pay flow, walked the way a fit-gap workshop would walk it.
Fit-gap on SAP procure-to-pay
The standard SAP P2P flow, walked one stage at a time. At each stage, the question is what differs from your current process and which of the four outcomes it gets.
Requisition and release
The first fit question is the release strategy: can your approval rules be expressed as value, material group, plant or account assignment? Almost always yes. A request for approvals by project role or matrix manager is a real gap and needs a decision, not an automatic build.
Sourcing and the purchase order
Source determination and PO release. Typical findings: the business wants buyers to see every requisition (a process change, since standard can auto-create POs from contracts) or needs a PO approval the standard release strategy already covers (a configuration fit).
Goods receipt and quality
Receipt with MIGO and the optional inspection lot. Ask which materials really need inspection and whether services use service entry sheets. Gaps here are often about mobile receiving and labels, which usually have standard or partner answers.
Invoice verification
MIRO and tolerance keys. This is where legacy workarounds surface: manual price corrections, invoices paid without receipts. Most should become process changes, because the standard three-way match is the control the auditors expect.
Payment
F110 and clearing. The fit questions are payment methods, bank formats and approval of the payment run. Bank file formats are configuration; a request to approve each payment individually is a process change worth challenging.
How it works
Choose the processes and their standard flows
List the end-to-end processes in scope (procure-to-pay, order-to-cash, record-to-report and so on) and start each workshop from the vendor's standard flow, not from a drawing of the legacy system.
Invite the people who do the work
Each workshop needs the process owner, two or three key users who do the work daily, and the functional consultant who knows the standard. Without key users the gaps are guesses; without the consultant, every difference looks like a gap.
Walk the flow decision by decision
Go through the flow in order and stop at each decision and handoff. Ask what is different in your business today and why. Record the difference on the step where it occurs, so the gap list stays tied to the process.
Classify every difference
Give each difference one of four outcomes: fits as standard, fits with configuration, process change (the business adapts), or extension (something is built). Record who decided and why.
Challenge every extension
For each extension, write down the business value and the cost to build and maintain it. If nobody can state the value, it becomes a process change. This review is where most of the savings in an implementation are made.
Sign off the gap list
Send the classified gap list and the updated process flows to the process owners for approval before build starts. The signed version is what scope changes are measured against later.
Mistakes to avoid
Starting from the legacy system
Drawing the as-is process in detail and asking the ERP to match it guarantees a long gap list. Map the as-is only as far as you need to understand pain points, then work from the standard.
Every difference becomes a requirement
Without the four-way classification, the gap list turns into a build list. Make 'process change' the default answer and require a reason for anything else.
No owner on decisions
A gap marked 'to be discussed' at the end of the workshop is usually still open at go-live. Give each one an owner and a date.
Gaps recorded away from the process
A spreadsheet of gaps without the step they belong to loses context. Keep each gap as a note on the step in the process flow.
Open the SAP P2P flow for your workshop
Open the SAP procure-to-pay flow as your own chart, add your gaps as notes on each step, and send it to the process owner for sign-off.
Related guides
Frequently asked questions
What is a fit-gap analysis in an ERP implementation?
It is the structured comparison of the business's requirements with the standard functions of the ERP. Each requirement is classified as a fit, a fit with configuration, a gap closed by changing the process, or a gap closed by building an extension. The result is a signed-off list of decisions that sets the scope of the build.
What is the difference between fit-gap and fit-to-standard?
Fit-to-standard is SAP's name for the same activity in SAP Activate, with a stronger default: show users the standard process in a preconfigured system first and treat the standard as the answer unless there is a clear business reason. Traditional fit-gap often started from documented requirements instead. The fit-to-standard emphasis is now common across ERP vendors.
Who should attend fit-gap workshops?
The process owner who can make decisions, key users who do the work every day, the functional consultant for the ERP module, and for some processes someone from finance controls or IT integration. Keep the group small enough to work through the flow in detail.
How long does a fit-gap analysis take?
For a mid-size implementation, typically four to eight weeks of workshops across all process areas, with one to three sessions per end-to-end process. The length is driven less by system complexity than by how quickly decisions are made.