SAP Fiori and UI5 Development
SAP Fiori is the design system and SAPUI5 is the framework it is built on. Together they replace transaction screens with role-based applications that run on a browser or a phone. The work is worth doing where transaction volume is high and the people performing it are not SAP specialists.
Applications scoped by transaction profile, not appearance
Fiori work is usually requested as a modernisation of how SAP looks. That framing produces disappointing results, because appearance is not what makes a transaction slow or error-prone. The useful question is which transactions are performed often, by whom, and where those people lose time or make mistakes.
On that basis the candidates are consistent across most estates: high-volume approvals, goods movements, time and expense entry, and anything performed away from a desk. Specialist configuration transactions used by a handful of trained people are almost never worth rebuilding.
OMAV checks standard Fiori apps before proposing custom development, because a custom app carries a permanent upgrade regression cost that a standard app does not. Where a standard app covers most of the need, adapting the process is usually cheaper over five years than owning the code.
What a Fiori engagement covers
Six workstreams. The first two decide whether the rest are needed.
Transaction profile analysis
Usage data pulled from the system to establish which transactions are run, how often, by which roles, and where errors and reworks concentrate. Candidates are selected from evidence rather than from opinion.
Standard app fit assessment
Every candidate checked against the standard Fiori app catalogue for the installed release, with the gap stated plainly so that build-versus-adapt is a costed decision.
OData service development
The service layer that exposes SAP data to the application, built or extended with attention to payload size and response time rather than only correctness.
Application build
Fiori Elements where the pattern fits, freestyle UI5 where it does not, with accessible and keyboard-reachable controls and a tested offline or poor-network position where the app is used in the field.
Launchpad and role configuration
Catalogues, groups, spaces and pages configured so that each role sees the small set of tiles it needs rather than an undifferentiated wall of applications.
Upgrade regression position
The maintenance cost of each custom application stated at handover, with the objects it depends on documented so that the next upgrade is a task rather than an investigation.
How a Fiori engagement runs
Profile
Usage analysis across the estate to rank transactions by volume, user population and error rate, producing a candidate list with reasons attached.
Assess fit
Standard app catalogue checked for each candidate, with the functional gap and the cost of closing it stated per app.
Prototype one
A single application built end to end and put in front of the people who will use it, before a programme is committed.
Build and configure
The agreed set delivered, with OData services, launchpad configuration and role assignment handled together rather than sequentially.
Hand over
Source, documentation and the upgrade regression list, with a walkthrough for whoever will maintain it.
The three build routes
Choosing between activating standard, Fiori Elements and freestyle UI5.
| Dimension | Standard app | Fiori Elements | Freestyle UI5 |
|---|---|---|---|
| Effort | Configuration only | Low to moderate | Moderate to high |
| Flexibility | Fixed | Pattern-bound | Unconstrained |
| Upgrade cost | Carried by SAP | Low | Carried by you |
| Fits | Standard process | List and object pages | Genuinely bespoke tasks |
| Time to first app | Days | 2 to 4 weeks | 4 to 8 weeks |
| Recommended when | It covers the need | The pattern matches | Neither of the above fits |
What Fiori will not fix
A Fiori application does not repair a broken process. If purchase approval takes four days because the approval matrix routes through people who are not in the office, a faster screen changes the fourth day into the fourth day. The interface removes friction from a sound process; it cannot compensate for an unsound one.
Nor does it reduce training need to zero. Role-based applications are markedly easier to learn than transaction screens, but the underlying business rules still have to be understood by the person performing the task. Where the rules themselves are the difficulty, the answer is documentation and training rather than another application.
- Select candidates from usage data, not from which screens people complain about most loudly.
- Check the standard app catalogue before proposing any custom build.
- Every custom app carries a permanent upgrade regression cost. State it before it is bought.
- Prototype one application with real users before committing to a programme.
Questions buyers ask about this
Which transactions are worth rebuilding as Fiori apps?
High-volume transactions performed by non-specialists, transactions with high error or rework rates, and anything that has to be done away from a desk. Specialist configuration transactions used by a few trained people are rarely worth the build and maintenance cost, and we will usually advise against them.
What is the difference between Fiori and SAPUI5?
Fiori is the design system: the guidelines, patterns and interaction rules. SAPUI5 is the JavaScript framework that implements them. In practice, Fiori describes what the application should behave like and UI5 is what it is built with.
Should we use Fiori Elements or freestyle UI5?
Fiori Elements where the task fits a standard pattern such as a list report or object page, because far less code is written and far less has to be maintained. Freestyle UI5 where the task genuinely does not fit a pattern. Choosing freestyle for a task that fits a pattern is the most common avoidable cost in this work.
Can we re-skin our whole SAP estate to look like Fiori?
Technically yes, and we will usually advise against it. Rebuilding specialist configuration transactions used by four people rarely returns the build and maintenance cost, and every custom app added to the estate is another object to regression test at the next upgrade.
What is the ongoing cost of a custom Fiori app?
Regression testing at each upgrade, dependency maintenance as OData services and underlying tables change, and the knowledge cost of somebody having to understand it. We state that cost per application at handover, alongside the documented dependency list, so it is a known number rather than a discovery.
Marked up as FAQPage structured data, matching the visible text exactly.
Still not sure this is the right service?
Answer four questions and we will tell you which one fits — or that none of them do.
Tell us what you are trying to fix.
A short conversation about the objective, the constraints and the timing. If we are not the right fit, we will say so.