SAP Fit-Gap Analysis — When Business, IT and Finance Disagree

The workshop stalls in the same place almost every time. Finance wants a hard three-way match with no exceptions. Supply chain wants the workaround they have used for a decade because the hard match kills their delivery timelines. IT wants whatever is closest to SAP standard, because every deviation is something they maintain forever. Nobody in the room is wrong. That is exactly why it stalls.

Most facilitation advice treats disagreement like a fire to put out. Get everyone nodding, move to the next agenda item, write “aligned” in the minutes. That produces a design nobody actually believes in, and the disagreement resurfaces in Realize, at a much worse time to have it.

Fit-gap conflict is not a facilitation failure. It is information. Each function is optimising for something real, and the job is not to make the disagreement go away — it is to get underneath it fast enough that the workshop still produces a decision.

🔗 Before this post

This follows on from Running SAP Discovery Workshops That Produce Decisions, and feeds directly into SAP Blueprinting — Fit-Gap to Design Freeze, where the gap register this post’s decisions land in is covered in full.

Why fit-gap conflict is normal, not a red flag

Every function in the room has a legitimate, defensible reason for wanting what it wants. Finance owns the audit outcome if controls are weak. Supply chain owns the customer complaint if a shipment is late because of a rigid process. IT owns the support burden for every year the system is in production after this project team has moved on.

None of those concerns are illegitimate. Treating the loudest objection as the only one that matters, or treating disagreement as something to smooth over with a compromise nobody actually wants, produces the same outcome either way: a design that satisfies nobody and gets quietly reopened later.

📌 Key takeaway

Conflict at this stage is cheap. A disagreement surfaced in a fit-gap workshop costs a discussion. The same disagreement surfaced during user acceptance testing costs a rebuild.

Separate the disagreement from the decision

The single most useful facilitation move in a cross-functional fit-gap session is separating what someone is asking for from what they actually need. Almost every entrenched position collapses once you get underneath it, because the position was never really the point.

Finance asking for “a hard three-way match with zero tolerance” is a position. What finance actually needs is audit confidence and a clean paper trail for exceptions. Supply chain asking for “keep the manual override we have always used” is a position. What supply chain actually needs is the ability to receive goods without stalling the warehouse over a small quantity variance. Those two needs are not actually in conflict — the positions were.

💡 Practical tip — Ask the one question that reframes everything

Ask “what happens if you don’t get this” before evaluating any proposed solution. It is the fastest way to separate a real requirement from an inherited habit, and it almost always reframes the gap into something smaller and more solvable than the room started with.

A worked example — one gap, four functions

Take a real scenario: a three-way match exception for a purchase order where the delivered quantity does not exactly match the order. Finance’s position is zero tolerance — anything off, block the payment. Supply chain’s position is a manual override available to any warehouse clerk. IT’s position is stay on SAP standard tolerance settings and avoid a custom workflow. The business sponsor’s position is whatever makes the go-live date, which usually means whichever position was raised last.

Underneath those four positions, the actual needs are narrower than the positions suggest. Finance needs visibility into every exception and an audit trail, not a block on every exception. Supply chain needs speed on small, low-risk variances, not unlimited discretion on all variances. IT needs to avoid a fully custom workflow, not necessarily pure standard with zero configuration.

The gap that actually gets built is usually a tolerance threshold with tiered approval — small variances auto-approve with a logged exception, larger variances route to a named approver. That design did not exist as anyone’s opening position. It exists because the room stopped debating positions and started comparing needs.

Scoring gaps so the debate has a shared basis

Once the underlying needs are on the table, the room needs a way to evaluate the gap that is not just whoever argues longest winning. A simple, consistent scoring approach turns the conversation from opinion into criteria everyone agreed to in advance.

Scoring dimension	What it measures
Business impact	Cost of leaving the gap unresolved — delay, rework, customer or user friction
Implementation complexity	Effort and risk of closing the gap — configuration, custom build, or standard fit
Compliance or audit risk	Exposure if the gap is closed the wrong way, or not closed at all

None of this needs to be sophisticated — a low, medium, high scale per dimension is enough to force the conversation to be specific instead of emotional.

The value of scoring is not the score itself. It is that scoring forces each function to state its case in terms the other functions can actually evaluate, instead of in terms only that function understands. A compliance risk that finance rates high needs to be explained to supply chain in language supply chain can act on, not left as an unexplained veto.

When functions can’t agree — escalation that doesn’t stall the workshop

Some disagreements will not resolve inside the workshop, and pretending otherwise burns the room’s time on a conversation that needs different people to close it. The skill is telling the difference between a disagreement worth pushing on for another ten minutes and one that needs to leave the room immediately.

⚠️ Warning — “Offline” without a name and a date is where decisions go to die

If the underlying needs genuinely conflict — not just the positions, the actual needs — escalate it the same day, to a named decision owner, with a clear framing of the trade-off. “Let’s take it offline” without a name and a date attached is usually where decisions get quietly dropped, not resolved.

Park it visibly if it is not urgent enough to escalate immediately, using the same parking lot discipline that keeps any workshop moving. But a parking lot item still needs an owner and a date it will be revisited — an unowned parking lot is just a graveyard for decisions nobody wants to force.

Keeping architectural coherence when every function wins something

Here is the risk that does not show up until later: every function gets a reasonable outcome in its own workshop, and the four outcomes do not actually add up to one coherent system. Finance gets its tiered approval. Supply chain gets its fast path for small variances. IT gets to avoid a fully custom workflow. Each decision was locally sound. Together, they can still be a mess.

This is where the solution architect’s job stops being about any single gap and starts being about the seams between them. The tiered approval threshold finance wants has to work with the same master data supply chain’s fast path depends on. The configuration IT is comfortable maintaining has to actually support both, not just avoid being fully custom.

✅ Best practice — Check the seams before the freeze

Review every gap decision against the ones adjacent to it before the design freezes, not after. Ask explicitly: does this decision assume something about a process area decided in a different workshop? That single question catches most of the incoherence before it becomes a Realize-phase surprise.

📝 Note — This applies beyond SAP

The position-versus-need distinction, the shared scoring basis, and the seam check are general facilitation principles — they show up in any cross-functional requirements process, not just SAP fit-gap workshops. The three-way match example is SAP-specific; the underlying skill is not.

At a glance — facilitating fit-gap across competing functions

Concept	One-line summary
Position vs interest	What someone asks for is rarely what they actually need — ask what happens if they don’t get it
Conflict as information	Disagreement in fit-gap is cheap; the same disagreement in testing is expensive
Gap scoring	Business impact, complexity and compliance risk, scored consistently, turns opinion into criteria
Escalation	Genuine conflicts get a named owner and a date the same day, not an unowned “offline”
Parking lot	Non-urgent conflicts get parked with an owner and a revisit date, never left unowned
Seam check	Every gap decision reviewed against adjacent process areas before the design freezes
Architect’s role	Not picking a winner per gap — making sure the winners add up to one coherent system

What to take away

Cross-functional fit-gap conflict is not something to eliminate. It is the clearest signal in the whole discovery process about where a design will actually get tested once it is live, because the people arguing about it are the people who will live with the consequences.

The facilitation skill is not making everyone agree. It is getting underneath positions fast enough to find the narrower need each function actually has, scoring gaps on criteria everyone accepted in advance, and routing genuine conflict to a named decision maker instead of letting it die in a parking lot. Do that, and the design that comes out the other side is one people actually believe in, not one they quietly plan to reopen.

The architect’s real job in these sessions is not picking a winner in each individual argument. It is making sure the four winners still add up to one system that works.

🔗 Related posts on this site

Running SAP Discovery Workshops That Produce Decisions — the decision-log and pre-work discipline this post’s facilitation moves build on.

SAP Blueprinting — Fit-Gap to Design Freeze — where the decisions this post produces get captured in a gap register and frozen.

SAP Activate — The Methodology Behind Every S/4HANA Project — the Explore phase and Fit-to-Standard workshops this post assumes as context.

What Does an SAP Solution Architect Actually Do? — the role responsible for the seam check that keeps a design coherent.

SAP Architecture Decisions — Stakeholder Sign-Off — where the trade-offs resolved in this post get presented to the sponsor for sign-off.

Published on rakeshnarayan.com — Articles

URL: https://rakeshnarayan.com/articles/sap-fit-gap-analysis-when-business-it-and-finance-disagree/