There is growing interest, and even excitement, about SAP Fiori, as this represents an opportunity to begin wholesale replacement of SAPGUI, the 25-year-old technology used by most SAP users.
The journey begins with the SAP Library apps: A growing library of ready-to-use Fiori apps that can be deployed on premise or in the cloud. At the time of writing there are hundreds; almost 1,000 off-the-shelf library apps representing a new standard SAP user interface.
Using the on-line explorer, organisations can search for library apps based on application or role, view screenshots and find out any pre-requisites. They quickly find that there are many! Taking ERP as an example, the number of apps which require the latest version of Business Suite and a recent enhancement pack is significant, as is the number of apps requiring a HANA database: To the average cynic it would appear that SAP is driving HANA sales through the provision of free Fiori apps.
The SAP drive for simplification means that the library apps are much easier to use that their equivalent SAPGUI transactions. However of course this means that they are typically less powerful and flexible than the SAPGUI transaction: It is likely, therefore, that organisations moving to Fiori may find key fields missing from the Fiori app that they rely upon. Library apps are never going to be a 100% fit for most companies.
Organisations wishing to use the vanilla apps may need to change their business process, and of course it sounds like a dumb idea to design the process around the app: Clearly the app should be designed around the business process instead.
So library apps provide a great introduction to Fiori, but most commonly represent the ‘starting line’ rather than a realistic working solution.
The great news about library apps is that they can be ‘extended’; there are delivered ‘extension points’ with which the apps can be tailored to suit particular business requirements. This means that fields can be added (or, potentially, removed) in order for the app to better match the need. Typically, the apps call SAP BAPIs through Gateway Services, so the change should be relatively straightforward if the required field is available in the BAPI.
However, there are still limitations in fit, particularly when the required data fields are not available out-of-the-box, and the level of development required to extend the app may get painful. So extending the library apps may not be the best approach.
Moreover, having established that best practice is to design an app around a business process, it seems like a backward step to be constrained by a BAPI: This approach merely replaces a SAPGUI transaction with no consideration for the wider business process. There is more value in Fiori when the apps form part of optimised business process steps, rather than when they are like-for-like replacements with SAPGUI transactions.
Consider a master data process, or a new joiner process, a purchasing process or a service management process. These multi-step, collaborative business processes involve multiple touch-points, notifications and updates. Modelling the Fiori app on a SAPGUI transaction code designed over 25 years ago isn’t necessarily going to provide the best solution for current and future needs.
Inevitably, organisations will come to the realisation that it is necessary to build custom apps to exploit Fiori: The question is not whether organisations come to this realisation, but how quickly. This ensures a much better business fit, and can be designed around new business processes.
This is completely normal and the SAP Web IDE is delivered with templates for building custom Fiori apps.
Also inevitably, in order to deliver that better business fit, the custom apps are more likely to be relatively complicated: Despite the drive for simplification, we can expect real business requirements to remain stubbornly complex.
In practical terms, this means that each app will consist of 3 parts:
The need arises for solutions to accelerate delivery of custom Fiori apps. Solutions are emerging to tackle this. Some of these focus on UX design whilst others focus on the process integration. Fundamentally these are simplifying the SAP process of app design and build.
Organisations embarking on their Fiori journey should consider what value they can derive from the library apps, then the enhancement of them, followed lastly by the custom apps.
Neil ran his first SAP transformation programme in his early twenties. He spent the next 16 years working both client side and for various consultancies running numerous SAP programmes. After successfully completing over 15 full lifecycles he took a senior leadership/board position and his work moved onto creating the same success for others.