When is Fiori Not Fiori?

When is Fiori not Fiori? SAP provides a variety of tools for the delivery of enhanced user experiences, and although consistent styling can be achieved through each approach, it is important to understand what does and does not constitute a Fiori UX.
Customers beware: Not all companies who offer “Fiori” software solutions are offering something that is truly Fiori. As SAP continues to guide its customers towards Fiori as the standard user experience, organisations which have invested in alternative approaches might find their choices to be costly in the long term.
SAP Fiori is both a UX paradigm and a technological approach.
As a UX paradigm, Fiori offers a simplified experience of SAP, with personalisation options, in order to interact with SAP products through responsive web apps on any device. Typically the design is template-driven, ensuring a limited number of clicks to access information. Reports are graphical, transactional data entry is easy. Whereas in the traditional model a ‘simple’ user interface was recommended only for occasional users, with the Fiori paradigm this simplification is extended to regular users.
As a technological approach, Fiori is the combination of SAPUI5 apps, developed through the SAP Web IDE, communicating to the SAP back-end systems using oData via SAP Gateway. Each app is then deployed to a Fiori LaunchPad, either on premise or in the cloud. The Fiori LaunchPad is a crucial component, and can be deployed stand-alone or embedded into the SAP Enterprise Portal or HANA Cloud Portal. S/4 HANA relies on Fiori LaunchPad.
All roads lead to Fiori LaunchPad
Developing Fiori apps: The typical customer journey
Although the number of pre-delivered ‘library’ apps available from SAP now approaches 1000, customers will find that:
- Many of the library apps have very high specification application and database pre-requisites, e.g. CRM EHP3, ERP EHP7 or SAP HANA. This means that the number of usable apps can be very restricted for many customers.
- Library apps can be ‘extended’ to meet business requirements, but the scope of the extensions is tightly defined.
- Despite the size and scale of SAP’s library, the number of apps relevant to individual functional areas can be relatively limited. As of April 2016 there are only 18 HR apps, for example, compared with 288 Finance apps.
Customers who embrace SAP’s UX strategy, will therefore quickly see the need to develop their own custom Fiori apps.
Fiori journey: From library app to custom app
Of course, the Fiori approach does not satisfy every user interaction, and organisations may find that using Personas with the SAP Business Client, for example, can satisfy many of their UI requirements. But where Fiori is the chosen model, a custom build involves:
- App design is template-based(e.g. ‘list/detail’)
- App is designed with a small number of navigational clicks
- App is designed to do one thing well, not many different things
- App is intuitive; ideally no user training is required
- App fields are mapped into SAP Gateway services for back-end communication
- App client-side styling and logic is developed using the SAP Web IDE
- App is published to Fiori LaunchPad
The result is a portfolio of role-based ‘tiles’ available for users to launch apps that support the execution of SAP transactions, data collection, data retrieval and reports. Each user can personalise his/her own LaunchPad view, including or excluding tiles, such that their LaunchPad is self-managed and not cluttered.
It should be noted that a necessary effect of adopting a Fiori approach is that instead of delivering a highly complex app, capable of triggering many updates, the result will be a group of apps, each designed for a single update: it may require more than one Fiori app to replace a SAP transaction or web dynpro.
Not Fiori
Applying stylesheets to ABAP web dynpro or BSP applications to give them the same look and feel as Fiori apps does not make the solution Fiori. For example, HR Renewal is not Fiori.
SAP HR Renewal: Not Fiori
If you build a multi-functional SAPUI5 web application, which of course is perfectly possible and sensible, then it is not Fiori. In fact, Arch delivers a SAPUI5 e-forms portal which is rich in functionality. The portal can be launched from Fiori LaunchPad and specific functions within the portal can be launched with separate tiles on the LaunchPad. But it isn’t a Fiori app, just SAPUI5.
Arch Form Manager: Fabulous, but Not Fiori
Further, delivering single-purpose SAPUI5 apps does not make the solution Fiori without full integration with SAP Web IDE and SAP Gateway. For example, Neptune’s app generator allows ABAP developers to build HTML5 apps which can look like Fiori apps.
Neptune applications: Not Fiori either!
So Fiori relies on a few core components, and if any are missing then customers should not be lulled into believing that they are investing in an SAP-recommended approach. As SAP enhances the Fiori offering and drives all user interactions through the LaunchPad, then support for alternative approaches may wane, and apps delivered using non-standard methods may need to be re-worked or entirely redeveloped.
SAP UI technologies
Building custom apps in Stelo: 100% Fiori
The Stelo approach is 100% Fiori. Stelo provides an ABAP framework for the accelerated generation of SAPUI5 apps.
Fiori apps generated by Stelo are created and edited using SAP Web IDE and can be published to Fiori LaunchPad in exactly the same way as Fiori library apps. This means that there is a seamless experience for the users: Stelo Fiori apps can sit alongside Fiori Library apps and those built manually utilising exactly the same infrastructure.
Stelo app: 100% Fiori
Another enormous benefit of Stelo is that the SAP Gateway services are pre-defined so that there is no need to build and maintain a library of Gateway services in support of your Fiori apps. This means that custom Fiori apps are much faster and easier to develop, and to maintain when changes are required.
Stelo also provides a host of out-of-the-box functionality such as audit trail capture, attachment support, save as draft and Inbox for approvals and multi-step processes.
Summary
The growing acceptance of Fiori is driving up demand and the requirements of customers hungry for a better SAP UX. The wise approach is to invest in tools and techniques that conform 100% to SAP’s definition of a Fiori UX. Customers should ensure that their partners are using tools like Stelo rather than ‘Fiori-like’ solutions. Not to do so risks missing out on benefits from the millions of dollars SAP has committed to Fiori but also a seamless experience whether the app was off the shelf, extended or generated.
More information
- SAP UI overview: http://go.sap.com/developer/front-end.html
- SAPUI5: http://openui5.org
- SAP Fiori Design: https://experience.sap.com/fiori-design/
- Stelo: https://www.arch-global.com/products/stelo/