When the Standard Fiori App Covers 80% — and the Missing 20% Kills Adoption

The fit-to-standard workshop went well. The standard app from the Fiori Apps Reference Library demoed beautifully, the analyst ticked the requirement list, and the summary slide said what it always says: 80% coverage, remaining gaps to be addressed in a later wave.

Six months after go-live, the approvers export the worklist to Excel because the one field they actually decide on is not on the object page. The clerk who releases two hundred documents before lunch has quietly gone back to the GUI transaction. The Thursday exception travels by email.

Here is the paradox: the standard Fiori apps that fail hardest are rarely the ones that clearly didn't fit. An obvious misfit gets rejected early and cheaply. An app that covers 80% gets approved, trained, and celebrated — then fails silently, because coverage percentages hide a fact every fit-gap spreadsheet ignores: not all requirements weigh the same.

Why "Adopt Standard First" Is Still the Right Instinct

The position deserves its steelman, because it is largely correct.

Fit-to-standard is the accumulated lesson of two decades of ERP landscapes buried under Z-transactions: the system where an upgrade takes eighteen months because ten thousand custom objects need regression testing, and where the custom code now dictates how the process works.

The clean core principle is the sane response. Standard Fiori apps come with something no custom development fully delivers: SAP maintains them, tests them against every release, and ships them integrated with the business objects and authorizations. When a standard app genuinely fits, adopting it is the correct engineering decision.

The critique that follows is aimed at two other things: how "fits" gets determined, and the underestimated cost of closing the gaps it leaves behind.

Why "80% Coverage" Is a Meaningless Number

A typical fit-gap analysis produces a list: forty requirements, thirty-two covered, eight gaps. Coverage: 80%. The number looks rigorous. It is arithmetic performed on a category error.

Requirements are counted as interchangeable units. They are not. "The app shows the document currency" and "the approver can see the vendor's open disputes" both count as one line — but one is decoration and the other is the reason the approval step exists. If the missing 20% includes a step the user cannot skip, adoption collapses regardless of how polished the rest is.

The question that predicts adoption is different: can every user complete their real daily work, including the ugly cases, without leaving the app? That is a yes/no question per role, and averaging it into a percentage is how rollouts fail politely. Coverage is a chain, not a pile: one broken link, and the user experiences the break.

A Taxonomy of the Missing 20%

The missing fifth clusters into five families.

Missing data on screen. The object page shows the header data SAP considered universally relevant — but this approver decides on the contract reference and the spend against the framework agreement, and neither appears. So they open SAP GUI in a second window, and soon skip the Fiori step entirely. One missing field makes a 95% complete screen 0% sufficient.

Missing validations and compliance checks. The control framework requires a four-eyes check above a threshold. The standard app has no place for it, and a policy asking users to "remember to" is not something auditors accept.

Missing mass operations. The clerk who processed batches in an ALV grid — select all, apply, F8 — meets a list report designed for reviewing items one by one. Twelve minutes becomes an hour.

Missing exception paths. The real process includes reject with reason and route back, request clarification, reassign because the approver is on leave. Without a vocabulary for the exception, the exception moves to email.

Missing integration with the adjacent step. The output must land somewhere the app doesn't reach — an attachment in another module, a notification the next role never receives — so the user performs a second, manual task to make the first one count.

Each looks small in a fit-gap row. Each is fatal on the critical path.

Why the Gap Survives the Project — and How Adoption Quietly Collapses

If these gaps are so predictable, why do they reach production? Four structural mechanisms.

Demos show happy paths. The workshop runs the vanilla scenario with clean data. Nobody demos the Thursday exception.

Workshops sample the wrong users. Attendees are functional leads and consultants who understand the process but do not execute it two hundred times a day. The clerk who knows which field matters is represented by proxy.

Coverage is validated against documentation. The documented process rarely includes the informal validations, side-lookups, and exception handling that make up real work.

"Wave 2" is a fiction with a project code. After go-live the team disperses, the budget closes, and users have already built workarounds. The workaround becomes the process.

And the collapse is quiet. Nobody files a ticket titled "I refuse to use the app." The GUI transaction is still reachable, the Excel export becomes the real worklist, and approvals get pre-agreed in email and merely recorded in the app afterward — so the audit trail documents a fiction. Launch counts stay respectable, because users still open the app for the final click. That is why the missing 20% is more dangerous than a missing 100%: total failure is visible at the workshop; partial failure is invisible until the audit.

The Extensibility Spectrum: Where Each Tool Stops

None of this means gaps can't be closed. SAP offers a genuine spectrum of options, and honest evaluation requires knowing where each one ends.

Key user extensibility — the Custom Fields and Custom Logic apps in S/4HANA — lets a trained business expert add custom fields to a business context, expose them on the standard UI, and attach constrained logic through released BAdIs. The ceiling is exactly where SAP drew it: released extension points. One centimeter outside what SAP exposed, the tool simply ends — and the blocking adjustment requires a developer nobody budgeted for.

UI adaptation — runtime adaptation by key users, or adaptation projects in SAP Business Application Studio for upgrade-stable variants of standard SAPUI5 apps — fixes arrangement problems: the important field buried three sections down. It moves furniture; it does not add rooms. A missing compliance check is not a layout problem.

Developer extensibility — RAP-based extensions, released BAdIs, custom CDS views — implements real logic, validations, and new actions in a clean-core-compatible way. Side-by-side extensibility on SAP BTP goes further: a separate application consuming S/4HANA through APIs and events, free to build what the standard app never modeled. Both are, unambiguously, development projects: scarce RAP or CAP skills, transports, upgrade regression, and an owner for the next ten years.

The question was never can the 20% be closed. It is what it costs — and who carries that cost after the project ends.

The Cost Curve Nobody Draws

The cost of coverage is not linear. The first 80% came essentially free — SAP built it, tests it, upgrades it. The last 20% is bespoke work, and it is entirely normal for closing "just" the missing fifth to cost more than the covered functionality would have cost to build — because you are paying for integration into someone else's application, at professional-services rates, with lifecycle obligations attached.

And the cost recurs. Every S/4HANA upgrade means extension compatibility testing. Extensions on released contexts are designed to survive upgrades, and mostly do — but "stable by contract" still means "test it every time."

This is not an argument against extending. It is an argument for pricing the decision honestly. When the true lifecycle cost is on the table, alternatives that sounded like defeat start sounding like engineering.

Two Honest Alternatives: Keep SAP GUI, or Redesign the Process

The first alternative is coexistence. For the mass-processing role, the mature question is not "how do we get them onto Fiori" but "what problem would that solve, and for whom?" If the extension to make the app fast is a significant build and the GUI transaction is supported and mastered, keeping SAP GUI for that role is a correct allocation of effort. Fiori earns its place where it is genuinely better — approvals on mobile, self-service for occasional users, analytical list pages. The honest version of coexistence names the decision, scopes it to the role, and revisits it; the dishonest version is discovering it in an audit.

The second alternative is redesigning the process. Sometimes the missing 20% is not a deficiency of the app but a fossil of the process: the side approval born of an incident in 2017. Before funding an extension to encode an exception, ask whether the exception should exist. "Just simplify" can be as glib as "just extend" — but process redesign belongs on the same options list as extension.

A Decision Framework: Weigh Gaps, Don't Count Them

First, weigh each gap on three axes:

• Severity: blocking (the user cannot complete the task correctly without it) versus inconvenient.
• Frequency: how often the gap is hit, by how many users.
• Blast radius: who is affected — a core operational role, an occasional user, an auditor.

A blocking gap hit fifty times a day outweighs any number of cosmetic gaps. Score the gaps; do not average them. Then choose a path per gap — not one path for the app:

1. Accept the gap — low-severity, low-frequency items.
2. Adapt the UI — arrangement and screen-fit problems.
3. Key user extension — missing fields and constrained logic within released extension points.
4. Developer extension (RAP/BAdI) — real logic, validations, and actions, priced as a development project.
5. Side-by-side on BTP — gaps big enough to be their own application.
6. Keep SAP GUI for the role — power-user workflows the app serves worse.
7. Redesign the process — exceptions that deserve elimination.

For whichever path is chosen, name the maintenance owner. An extension without an owner is technical debt with a delivery date.

How to Run Fit-Gap So This Doesn't Happen

The cheapest place to catch the fatal 20% is before go-live, and the standard workshop format is structurally bad at it. Four adjustments change the odds:

Validate with the real operators. Put the highest-volume user of the current transaction in front of the standard app and have them perform their actual Tuesday with production-like volumes. The field they silently check will surface in ten minutes.

Test the ugly cases explicitly. Script the rejection with rework, the delegation, the month-end spike. An app validated only against the happy path has been validated against a process that doesn't exist.

Run a timed day-in-the-life test. A 5x slowdown found here is a design input; found after go-live, it is a workaround already in progress.

Write the gap list in severity language. Replace "80% coverage" with a sentence per role: "Role X can / cannot complete daily work in the app; the blocking gaps are A and B; the chosen path is Y, owned by Z." That sentence survives contact with reality.

Gap-Closing Options Compared

Frequently Asked Questions

What is key user extensibility in SAP S/4HANA?

It lets trained business experts extend standard S/4HANA apps without a development project — adding custom fields via the Custom Fields app and constrained logic through released BAdIs in the Custom Logic app. It works strictly within the extension points SAP has released.

What is the difference between in-app and side-by-side extensibility?

In-app extensibility runs inside the S/4HANA stack (key user tools, RAP, BAdIs), extending standard objects directly. Side-by-side builds a separate application on SAP BTP that consumes S/4HANA through released APIs and events. In-app is cheaper for small gaps; side-by-side suits larger capabilities, at the cost of a second application to operate.

Why do users go back to SAP GUI after Fiori rollouts?

Because a specific, high-frequency part of their work is worse in the app: a decision-critical field missing from the screen, mass operations slower than the old ALV workflow, or exception paths the app doesn't model. Since GUI transactions remain reachable, users quietly return to them.

How do you evaluate whether a standard Fiori app fits your process?

Weigh gaps instead of counting them. Have the real highest-volume users execute their actual daily workload, exceptions included, in a sandbox, and classify each gap as blocking or inconvenient. The decisive question is whether every role can complete real work without leaving the app.

Do Fiori extensions survive S/4HANA upgrades?

Extensions built on released extension points — key user extensions, adaptation projects, developer extensions against released APIs — are designed to be upgrade-stable, and generally are. "Stable" still means "regression-test it each upgrade," and anything touching unreleased objects is a standing risk.

Is it better to extend a standard Fiori app or build a custom one?

One or two field-level gaps within released extension points favor extending. A cluster of blocking gaps around logic, mass processing, or exception flows can make a purpose-built app — via RAP or side-by-side on BTP — cheaper across its lifecycle than stacking extensions onto a floorplan designed for a different job.

The Most Expensive Gap Is the One Your Users Find

Standard SAP Fiori apps deserve first consideration — that part of the conventional wisdom survives intact. What does not survive is the way coverage gets measured. An 80% figure produced by counting requirements answers no question that matters; what predicts adoption is whether each role can complete its real daily work, ugly cases included, without leaving the app.

Teams that weigh gaps one by one, before go-live, and name an owner for each closing path get what fit-to-standard promises. Teams that mark "80% — covered by standard" and move on get an app that reports respectable usage while the actual work quietly moves to Excel, email, and the transaction that never went away.

The cheapest gap is the one you close in a workshop. The most expensive is the one your users discover after go-live — because by then, they have already solved it without you.