Two important Fiori definitions

Note: Fiori is any app that follows the Fiori Design Guidelines and is using SAP technology like UI5, Fiori Elements, MDK, native Fiori SDK or Analytics.

I attended the SAP Fiori Innovation Day in Heidelberg. One topic that was discussed there was how to implement Fiori at customers. There are several approaches like: lighthouse apps, involve key users, let the Fiori UX let speak for itself, lower costs or boost productivity. To have these approaches work best, a happy scenario serves as the starting point. That is: a standard app that works or can easily adjusted and users that gain instant benefit from Fiori UX. Normally the happiness generated here is spreading through to other processes, apps and organizations, driving Fiori adoption as a whole and leads to a wider adoption. A common app for this could be an inbox app (for managers) or a time reporting app (for employees). These apps address a common pain point to a certain user: managers can approve workflows from their smartphone, employees can book their time with less clicks. App access may even include SSO and directly from a smart phone instead of having to use a laptop and manually starting VPN. As a result, users are more than happy to use Fiori and they act as ambassadors for other Fiori projects. This is a proven and working approach. SAP is supporting this approach. The Fiori App Library contains a top level entry for lighthouse apps and scenarios.

Lighthouse app

The problem is: it does work very nice at the beginning but does not scale very well. The limit is reached when the broader range of processes, users and apps is targeted. When you leave the “happy” world of light house apps and reach the apps that are part of a common process. There are simply not enough lighthouse apps to cover all processes and tasks. Focusing on a few lighthouse apps leads in the beginning to a fragmented user experience. The user might end up having to work with different technologies. Sometimes, they get Fiori for a nice, but not critical use case for them.

Process A and B are SAP Gui based in SAP system A and B and are what the user must work with daily. The Fiori app is available in a new S/4HANA system with access via SAP Build Work Zone. The user has no direct benefit from the Fiori app regarding their daily work done in processes A and B. Instead, a new system and client (web browser vs. SAP Gui) was introduced. The user might be able to run the app from a central launchpad, like SAP Build Work Zone. For running process A the user must still use SAP Gui and log on to system A, while for process B a logon to system B is needed. Resulting in the fact that the user has 3 systems to use to run all apps.

While employees can e.g. report their time using a Fiori app, working with SAP in their daily work from processes A and B is still untouched: working with orders, materials, notifications, etc. The lighthouse app is parallel to the other apps. The Fiori app stands out, just not necessarily as intended. It is isolated: as a system, access and technology. The Fiori implementation approach with lighthouse apps might even create additional workload for the user. Instead of being able to use an SAP Gui transaction in their SAP system to do time reporting, they might now have to use a browser. Switching clients, environments and UX. While the Fiori app might still offer a superior UX, in the first place it is an additional disruption for the user.

Process extension

The negative feeling of having a separate, isolated Fiori app can be targeted by having an app that can be part of a process. Such an app might not be an integral part of a process, rather offering functionality that can be reused. For instance, an app for workflows. A generic feature is offered to a wide range of users, and not just in a specific context / process. The benefit: Fiori gets introduced and offers direct value to the users working on tasks across processes. Taking care of app adoption is important. The problem of different clients and environments is not removed. In case the Fiori app is rather optional, maybe only offering additional information, it might not be even actively used by the user.

This approach might even prevent Fiori adoption. For process B, with a mandatory Fiori app, the user must now leave their usual client and switch to a web browser and a different system.

Fragmented Fiori UX

Isolated Fiori apps still do not solve the overall adoption problem. It is not the whole process that is transformed. In fact, actions must be taken to ensure that this approach is not turning into a bad practice: implementing Fiori without taking the users and their processes into consideration. Such a case happens when individual Fiori apps are implemented. Here the user has several Fiori apps available, which are not connected, nor offer benefit when executing a process.

A Fiori app for ordering equipment might be available but may have nothing to do with the process A or B. The user might order a new laptop maybe only once every 3 years. In total, the app might offer benefit to the company. Just not for the individual user.

From a management or Fiori implementation project lead view the given targets and KPIs might be fulfilled. There are several Fiori apps which are used by enough users. Knowledge on how to work with Fiori is generated. The report to management is a success. For the users too?

While selected Fiori apps can – and should – be used to start the Fiori journey, the end-to-end perspective is important. Companies buy and use SAP to be able to run their business. And that means that employees can focus on their tasks. To ensure employees can focus on their work, customers implementing Fiori should take two definitions into consideration:

Fiori Readiness

The Fiori Readiness indicates if a process can be executed fully using Fiori apps.

Fiori Completeness

The Fiori Completeness indicates if the Fiori apps used are fully aligned with the current Fiori Guidelines.

Taking both into consideration should help getting Fiori implemented in a way that offers enough benefit to get the most out of Fiori. From both an end user as well as from the business perspective. I’ll go into further detail for both definitions in upcoming posts.