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.

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 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.

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.