Why SAP S/4HANA Migration Needs Clean Process Mapping First
S/4HANA migrations fail on process clarity more often than on technology. Before any system conversion, an organisation needs a documented map of…
What Fiori changes and what it does not
Fiori changes how a user reaches a task and how much irrelevant information they see while doing it. A warehouse supervisor confirming goods receipts gets an app that does that, on a phone, with the four fields that matter. The same person in SAP GUI navigates a transaction built to serve fifteen different scenarios, most of which do not apply to them.
Fiori does not change what the underlying process requires. If the goods receipt process demands a batch number that the supervisor does not have at the point of receipt, that problem exists in both interfaces. This is the distinction that separates Fiori projects that deliver value from ones that deliver screenshots.
Choosing which transactions to move to Fiori
The candidates that repay the effort share a profile: high volume, performed by people who are not SAP specialists, error-prone in their current form, or needed away from a desk. A transaction executed forty times a day by warehouse staff on the floor is a strong candidate. A configuration transaction executed twice a year by a consultant is not.
Occasional users are a particularly good case. Someone who submits three purchase requisitions a month never becomes fluent in the GUI transaction, retrains themselves every time, and makes errors that someone downstream corrects. A focused app removes most of that cost.
| Characteristic | Strong candidate | Weak candidate |
|---|---|---|
| Frequency | Many times daily | A few times a year |
| User type | Non-specialist or occasional | Trained SAP specialist |
| Location | Shop floor, warehouse, field | Desk-based |
| Error rate | High, with downstream correction cost | Low |
| Field count needed | Small subset of the transaction | Most of the transaction |
| Process stability | Stable and understood | Under active redesign |
Standard apps versus custom development
SAP ships a large catalogue of standard Fiori apps, and the first question on any app request should be whether one already covers it. Standard apps are maintained through upgrades; custom SAPUI5 apps are your responsibility forever, and that maintenance cost is routinely underestimated at approval time.
Custom development is justified when the process is genuinely specific to your organisation and high-value enough to warrant a permanent maintenance commitment. It is not justified because a standard app is 80 percent right and someone prefers a different field order.
- Check the SAP Fiori apps reference library before scoping custom work
- Extension of a standard app is usually cheaper than replacement
- Custom apps need an owner, a test plan and an upgrade regression budget
- OData service design determines performance more than front-end code
- Launchpad and role design is where most rollouts actually stall
Where Fiori rollouts stall
Two places, consistently. The first is role and catalogue design: deciding which apps appear for which role sounds administrative, but it requires a clear view of who does what, and organisations that never documented that struggle to produce it under time pressure.
The second is backend performance. A Fiori app is only as fast as the OData service behind it, and services built by extending an existing report often perform acceptably in test with a small dataset and unacceptably in production. Load-test the service, not the interface.