Hire SAP Fiori and UI5 Developers

Fiori is usually bought to fix a perception problem and then judged on an operational one. The pitch is that SAP will stop looking like SAP. The reality is that a warehouse supervisor will use the app four hundred times a shift and will notice every extra tap.

What good looks like when a screen is used four hundred times a shift

That changes what good looks like. The standard floorplans are worth using where the task fits them, because they carry accessibility, responsiveness and consistency for free. But a task that needs three fields and a barcode scan does not need an object page with six sections, and forcing it into one produces an app that is technically compliant and practically slower than the transaction it replaced.

The honest test is a count of interactions per completed task, measured against whatever the person does today. If the new app takes more taps than the transaction, the transaction wins, and no amount of visual improvement changes that outcome.

Why most disappointing Fiori apps are backend problems

The other half of the job is the service underneath. Most disappointing Fiori apps are not badly built front ends; they are front ends over an OData service generated from a table that returns everything. The list takes four seconds because the app fetches thirty fields to display four, and filtering happens in the browser because the service does not support it. Designing the entity set around what the screen needs — the right expands, the right annotations, aggregation done in the backend — is where the perceived speed comes from.

This is why CDS and RAP matter to a front-end conversation. A CDS view modelled for the screen, exposed through RAP with the behaviour definition doing the validation, gives the app server-side filtering, paging and draft handling that would otherwise be reimplemented badly in JavaScript. Where the service is wrong, the front end can only choose which symptom to show.

The environment the app is actually used in

Then there is the environment. Plant and warehouse users work on shared devices, on wifi that drops between racks, wearing gloves. An app that assumes a keyboard, a stable connection and a clean login is an app that gets abandoned in favour of the paper it was meant to replace. We staff people who have had to make that work, not only people who have completed the tutorial.

Shared devices in particular break assumptions that hold everywhere else. The session belongs to the shift rather than the person, a half-finished draft may be picked up by whoever is on next, and an authorisation model built around named users produces either a security problem or a queue at the terminal.

What we ask a Fiori developer to explain

• Which standard floorplan they rejected on their last app, and what they built instead
• How the list on their busiest screen is filtered, and where that filtering executes
• What the app does when the connection drops midway through a save
• How the roles behind the app were designed, and who can see what they should not

Freestyle SAPUI5 is a legitimate answer to several of these. It is the wrong answer when it is chosen because the floorplan was unfamiliar rather than because the task did not fit it, and the distinction is usually visible within one question.

When a Fiori app is not the right answer

If the task is done a handful of times a week by trained users who already know the transaction, a Fiori app is a rewrite with no return. The value of Fiori scales with repetition and with how untrained the user is, and where neither applies the existing screen is genuinely fine.

If the requirement is a report, a report is cheaper. A great many Fiori projects are really requests for a number that somebody currently exports to a spreadsheet, and an app is an expensive way to deliver a number.

And where the underlying process is disputed, the app will not settle it. Building a screen over an argument produces a screen that half the business refuses to use, which is a more expensive way to discover the disagreement than a workshop would have been.