A combination of the Fiori Launchpad, Fiori apps, and Personas is a big part of the the future for your SAP Enterprise software; however the journey is not a simple one for a customer. There's really two common ways an existing, non S/4 customer will get into Fiori which are:
The problem with the first step is you may feel you are stepping into Fiori carefully, but realistically, you're not going to be prepared and the ROI on your investment is going to be far from ideal.
Why you may ask?
Well it's because the dependencies just to get started efficiently are not there. See every Fiori app will typically require:
And on top of this; how does the Fiori Launchpad and/or Fiori app you want to deploy fit into your current user experience? Do people expect this to work on Mobile devices like SAP advertise it does with no changes (business interpretation of messaging)?
In short, you get the TCO that supports a new User Experience but only receiving a single Fiori app deployment. That and you'll probably take short cuts since it doesn't make sense, for example, to set-up the HANA Cloud Connector or the Git repository for a single app; which leads to an environment less than ideal to implement more Fiori apps in.
But taking the 2nd approach, things can play out quite differently.
First, you have a plan to understand how Fiori will, over time, fit into your users' UX. This will include understanding where mobility fits in, which will hit the hurdles that your security & governance hoops you need to jump through. You can also get your licenses in place early (there's actually a free 10 user/developer license that can be used for WebIDE which takes a bit over a week to get which can drive setting up HANA Cloud Connector too (which is another security & governance hoop for you to jump through).
Your developers can also start taking open.sap.com courses to get up to speed because they know Fiori is coming. And if you're outsourced, it does not mean you can't suggest strongly that you are expecting them to start upskilling in this area. BTW - Starting this week is Developing Web Apps with SAPUI5 - which should be a really good follow up to Build Your Own SAP Fiori App in the Cloud - .
While there's lots more to state about the benefits of having a vision, including ratifying the vision with peers within the SAP ecosystem before realising you've gone down a rabbit hole of unsupported scenarios, the important point I wanted to make is:
If you do do this, and have some of the other pieces in place also, then within a single day, you can test out 15-20 Fiori apps in a single day with very little effort and see how well they actually work "out of the box".
The only catch to this is the pace of change within the Fiori space so unlike with Support Packs, 6 months is a long time so you may want a newer release than you have installed, but it doesn't mean the version you have is not supported still so not all is lost.
Now how to know what Fiori apps to prepare for? Well that's what the Fiori Apps Library and the Fiori Trial is for. You obviously have to filter out the incompatible apps but send these out to your SME's or SAP minded functional owners to review; get their input; then use the installation information for each app to identify the prerequisites for your Support Packs which you pass to your Basis team to take care of during support packs.
So just to come from a different angle to wrap this post up; the following is what I'd like to see if asked to implement a few Fiori apps at a customer:
Feel free to add further "perfect customer" requirements below in the comments as I'm sure there are many learnings out there...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
6 | |
5 | |
5 | |
5 | |
5 | |
4 | |
4 | |
4 | |
3 | |
3 |