In a previous post, I've already discussed the fact that SAP Fiori is not a mobile platform, but a user experience platform with a mobile-first framework. Understanding this is even more important once you move past the strategy and architecture steps, and into a deployment exercise.
Choosing proper use cases for SAP Fiori is critical. Fortunately AND unfortunately, Fiori provides standardized, out of the box feature sets delivered as standalone applications. At first blush this seems great, because you can deploy a new experience to users, already integrated with the backend, within days or weeks. The ability to achieve rapid success is realistic. However, doing so with the wrong use cases can lead to frustration, which breeds rejection.
You absolutely must select appropriate use cases for the standard apps, plan to extend the Fiori toolset when needed, and ensure the user communities you engage for early projects are up for the challenge.
- It is realistic to deliver Fiori solutions quickly with the right approach to delivery.
Use Cases for Standard Fiori Apps
In my earlier post on SAP Fiori strategy, I pointed out Fiori's core strengths:
- You can derive value quickly with standard apps
- No native development skill sets are needed in-house to support it
- Responsive/Multi-device is a cornerstone
- No need to deal with app submission
- Built to support extending the platform with minimal effort
When choosing which of the numerous standard apps (190 in all for waves 1 & 2) to deploy, it makes sense to adhere to the lightest, simplest use cases possible. So what does that mean? It means that to succeed with standard Fiori apps, you need to play to the solution's strengths. Consider this checklist when looking at use cases. Compare the projects you're considering to this criteria:
- First, can you boil the use case down to a task, rather than a comprehensive "set of functionality"?
- Are you addressing a task that should be simple and straightforward? (regardless of how SAP does it now)
- Does the task require minimal data moving back and forth? (field data, contextual data are okay)
- Is the user base always connected when they want to perform this task?
In order to succeed with a standard Fiori app, the project use case needs to be a "Yes" for every criterion I just listed. In addition - and this is the most important part - the standard features have to match up with the requirements for the use case. And if they don't - you will need to amend the use case or consider extending Fiori.
Extending SAP Fiori
Great news - SAP Fiori, as a user experience platform, was designed to be extended and enhanced. It's so much simpler to enhance than SAP Portal or any of the other past UI technologies that SAP or competitors have released. Most of our clients select at least a small amount of enhancement, if only to simplify a few fields or implement branding.
The most important thing to ask yourself when you begin a use case is: "Will the out-of-box functionality drive the users to do what they want to do?" The phrasing of this question is deliberate - because functionality is key, but Fiori is all about the User Experience. You want to equip the user, but also aid and encourage the user to use the new app. So, if the standard app doesn't completely pass muster because it's one screen too many or the fields aren't in the right order, you can make those changes without breaking the bank.
There are many ways to extend SAP Fiori, and we do them all. I'll talk more about customizing SAP Fiori and what it takes in the final post of this series.
User Groups
I'll define "User Groups" as the community of users that you will focus on for the deployment of any Fiori apps. Because Fiori is task-based, not a comprehensive "module", you have the opportunity to deploy multiple specific apps based on the user's identity context. This means a simpler, more relevant experience for each user, rather than muddying up their day with a bunch of confusing extra features that don't matter to their role.
That said, considering user groups is nearly as important as the use case itself. That's because SAP Fiori is so different than the traditional SAP applications some old school SAP users may be used to using, yet for other user groups, it's much more in-line with the marketplace (including Salesforce.com, and other tools).
At a very minimum, your target groups need to have a very well-defined role. This is imperative, as the solution is focused on tasks, so you have to be able to break down what you're delivering to one or a group of tasks rather than the traditional functionality mix.
Secondary to that, it will help if you decide if you want to deliver first to user communities with familiarity with SAP systems or new non-users. Accommodating the non-users allows you to bring in groups thatmay be "rogue" on other systems, but you may determine that with the early projects you want to serve the experienced staff who've been waiting for improvements.
It's also beneficial to look for user champions to help with the solution deployment, because though it should be simple to use, any project benefits from evangelism.
Finally, you need to be sure you educate users on the fact that the Fiori experience is one that can easily be enhanced over time. Unlike traditional SAP projects, this doesn't have to take months or years - enhancing or creating custom apps can be completed in just weeks. I'll cover that in my final post in this series [Removed by Moderator].
Looking for the entire SAP Fiori overview? Watch our video on SAP Fiori by SAP Mentor Pete Lagana here.
Message edited by Michael Appleby
- SAP Managed Tags:
