FIORI Implementation Simplified, Part 1
Disclaimer: This is not a technical discussion, but rather a wholesome discussion incorporating all the elements you will need to integrate to implement a FIORI solution.
This blog is based on our experience of implementing FIORI and is divided in 4 parts.
We have been implementing SAP solutions for quite a few years and thought of writing this paper because FIORI feels like a game changer for SAP. In addition, we had to struggle a lot on understanding how FIORI environment is set up, development was rather easy. So I decided to share our experiences, which shall give prospective leaders/users and developers an idea of what it takes to implement a FIORI solution.
Overall we implemented 9 business processes in FIORI in logistics, sales and purchase functions, which I will publish in another blog series.
First of all, as we all know, FIORI is a new way of accessing/looking at SAP. For an ordinary user, SAP screens are overwhelming; to add to the pain, contrast that to what a user may see on her mobile device. FIORI is SAP’s way of making user interface very easy and it helps free the user of SAP GUI on her computer. A user can access SAP anywhere, anytime on any device! And that is FIORI for me.
What this also means is that SAP has built quite a bit of security in the landscape architecture it proposes. You may or may not need all of the elements that SAP recommends, all depends on your answers to following questions.
- Will the FIORI UI/apps be used outside your corporate environment? This will affect whether you will set up http or https access to FIORI url! (it’s a big thing for network gurus)
- Will you be using FIORI App on a mobile? If not, then you do not need to worry about having a FIORI client and worrying about publishing and distributing that client.
- If you plan to use FIORI apps on a mobile, do you want to be able to track all the mobile devices using the FIORI app? If yes, then you need SMP, otherwise not.
In our case, answers were
Of course there were lots of challenges when it came to implementing this “simple” architecture. My suggestion is that if you are implementing FIORI for the first time, have first 2-3 weeks dedicated to setting up the landscape and testing some standard apps like “Product look up”, which should work direct out of box.
Following diagram depicts the landscape we had in one of our implementations. The reason I have mentioned this landscape is that this was the simplest of all the landscapes we worked in.
Usability of Standard FIORI UI/App
If you have reached this stage, you have set up the landscape and you have got an app or two working. Now comes the challenging part of implementing what business wants and managing expectations based on what they have been sold.
Surprise, surprise! Most of the folks I talked to felt FIORI is all drag and drop where standard functionality will work. And it’s just not business folks, many SAP consultants have this notation too. So let’s break this myth, if you want to do custom work then you will need programming resources. (more on that in next blog in series).
To understand how you can make standard FIORI functionality work, think of “SAP best business practices templates”, these are the templates which you use to design your solution. If your implementation is quite a standard one and very much based on these templates, only then you can assume a very fast tracked FIORI go live with least customization. If your actual implementation is far away from a standard template, you need to give extra time to implement any of the apps.
So the first rude wakeup for a FIORI delivery team is that they will have to either
- Modify current functionality or
- Develop brand new functionality because standard functionality won’t work with current business processes.
Some apps may work right out of the box, but even then they will require customization (configuration), which is still not easy to do because there is not enough documentation or seasoned resources available.