Organisations implementing Fiori LaunchPad, with or without S/4 HANA, are embarking on a fantastic new journey. Moving away from traditional menu-driven navigation provides an enormous opportunity to design new user experiences, providing information to drive user behaviour. This is, in effect, the delivery of new business processes, which is what SAP digital transformation is all about.
But it doesn’t happen for free, and organisations with long histories of planning SAP projects have never had to budget for this type of user experience design before. The practices and thought processes are new, so your existing team members don’t know how to do it. They might be fast learners and superbly talented, but delivering transformation through Fiori Launchpad is more than switching things on, and more than asking users what they need – much more. So if the benefits are potentially enormous, do you really want to use beginners?
From a standing start there are many questions. What is involved to design Fiori LaunchPad? Can we do this ourselves? What does SAP provide out-of-the-box? Should we use the pre-delivered SAP catalogs and roles? How do we decide which of the 10,000 apps we need? How do we best deliver the benefits of Fiori while making things easy to maintain in the future?
Making A Start
In your sandbox turn everything on: All the SICF nodes, all the Gateway Services. Turn on Fiori Search, turn on the pieces of BW inside S/4HANA that we need to drive analytics apps. You won’t figure out what you need by perusing the Fiori Apps Library but only by seeing things for yourself.
At this stage use the pre-delivered catalogs, groups and business roles – it’s way too soon for you to start building your own. But don’t give your users every role as this has a big impact on performance. So define functional users for your analysts with a mapping to the SAP roles.
Now you’re ready to start looking at the 10,000+ apps, and the good news is that you don’t need to review 10,000 apps. Firstly, 80% of these apps are in fact SAP transactions running in HTML GUI with a Fiori theme: They are exactly the same transactions available in SAPGUI. Of the remaining 20%, some you clearly won’t need – perhaps you are not running HCM or PLM etc., and some clearly you will need – such as FactSheets and Reuse Components. Of the rest, a large number are required for Simple Finance and the others are split between different functions in manageable quantities. So at this stage, your analysts should be able figure out what apps are definitely out of scope.
The second task is to determine what is needed: it’s not likely that you will need all 8,000 t-code apps, but analysts should be able to design what SAP transactions are required alongside the Fiori apps.
Catalog Design
Catalogs can be used for different purposes but can all be maintained in the same way, so it’s really essential to be precise about the different types of catalog:
[1] Technical Catalogs. These are provided by SAP, typically in the back-end server and replicated to the front-end server. They contain the basic tile definition and the related target mappings.
[2] Business Catalogs. These catalogs are more aligned to user’s roles, and reference the tile definitions from the technical catalogs. The SAP-delivered business catalogs contain both the tile definition and all the related target mappings required by the tile/app.
The first step is to define your own business catalogs. These suit two purposes:
Since the target mappings are closely related to the users’ technical roles it can be useful from a security point of view to manage these at a more granular level. In this case you need to define business catalogs with tile definitions and no target mappings, together with security catalogs which store the target mappings but no tile definitions. In this way the roles on the front-end server can match those on the back-end server at a more granular level.
All this takes some design, but really it involves an exercise of defining what the business catalogs will be and then adding the tile definitions and target mappings by referencing the definitions from the technical catalogs.
TIP: Carefully design a naming convention for your custom catalogs and you will be rewarded down the line.
Additional Transactions
Using the pre-delivered t-code apps isn’t enough: You will require additional tiles to call transactions that SAP does not provide a tile for. In reality there could be hundreds of these – there are many, many SAP transactions with no pre-delivered tile. In addition you will require tiles for any custom transactions you have built and want to launch through the LaunchPad. On top of that you might want to define tiles for specific persona flavors. And finally you might have delivered your own custom apps using Stelo, Fiori Elements or other app development tools.
All this is achieved by defining your own technical catalog using the ‘App Descriptors’ tool, and then you can reference the tile and target mappings into your business catalogs in exactly the same way as for the pre-delivered tiles. It is an easy task, but one that you might spend a lot of time on: If there are, say, 500 tiles required then just choosing 500 icons for those tiles is very time-consuming!
TIP: Where possible don’t maintain texts on the tiles themselves in a multi-language scenario, but reference the text from the transaction, so you don’t need to translate all the tile texts.
Group Design
So far everything has been driven by functional scope. From now on, the design turns to user experience. This is something that you can easily get wrong without serious consideration, and it’s where all the benefit lies.
The first thing to do is to abandon the SAP-delivered groups: SAP does not deliver anything remotely useful. Secondly, don’t allow group design to be influenced by security design or catalog design. The groups are not lists of similar tiles, but form part of a launchpad experience for a particular user role or persona. It’s difficult to choose terminology that hasn’t already been used for something technical here, but the point is that we are designing for a particular {person/role/team}. Clearly we can’t design a personal launchpad for every single user, but we do need to deliver something that’s granular enough to add value.
So we must begin with a list of personas that we are designing for, and then design the logical groupings and arrangements for the tiles needed by the persona. Consider:
What we find is that for many tiles that are calling SAP transactions we don’t need separate tiles for create, change and display in the groups. This takes up too much space. Often just ‘Change’ will suffice, and from there the user can change to ‘display’ or ‘create’ within the SAP transaction.
Tiles clearly add most value when they contain dynamic content such is KPI data and microcharts. Here’s an example of the Purchasing Analytics group in S/4 HANA. It’s powerful to have this information at our fingertips, but terrible design to hide these tiles away in a ‘Reporting’ group that users need to navigate to. Instead the key information should be front-and-centre, hitting the user between their eyes in order to drive their behaviour.
There are plenty of SAP analytics tiles that contain this type of content, and many more that don’t. Consider Production Engineering. In S/4 HANA we are provided with the group shown below. The tiles are not presented in a sensible order. 12 out of 22 tiles have the same icon, which renders the icon useless. Simply by putting tiles in a group falls way short of delivering a transformational user experience.
Custom Tiles
Building dynamic tiles and custom tiles can dramatically improve the launchpad design. This might be as simple as adding an image instead of an icon to bring the launchpad to life, or it might involve adding value through KPI and microchart information.
Some tiles lend themselves easily to the addition of microcharts:
Where there’s no useful chart or KPI to show, you can get creative with images. Here is the same Production Engineering group as above, but now with tile images and links.
Design Process
With Fiori LaunchPad the analytics should always come first. When we design the user’s launchpad we are designing their job: focusing on key business drivers and ensuring that they have the right information to make fast, informed decisions. So don’t only use analytical tiles with analytical apps; instead put key information in front of every user, making use of the Fiori LaunchPad home page and Overview Screens.
You won’t have the time to design a user experience that is 100% fit for every user, so that’s where personalisation is essential: You must allow your users to be show, hide, create and change their groups, and to add or remove tiles from their groups. This should begin at UAT: That’s the first chance you will get to see how users interact with their launchpads. After UAT you have a chance to make changes to the pre-delivered groups to make them a better fit for go-live.
After go-live give your users 3-6 months and then review again. See how they have personalised their own launchpads and this will inform how you can amend the groups when changes are introduced. Because changes will come: You have entered a Fiori world now, where more Fiori apps will be introduced and SAP transactions retired, where analytics will become the normal driver for many business processes, where more is automated and where the drive to simplify the user experience will continue. It’s going to be an exciting ride, with huge benefits for those who take it seriously.
But it doesn’t happen for free, and organisations with long histories of planning SAP projects have never had to budget for this type of user experience design before. The practices and thought processes are new, so your existing team members don’t know how to do it. They might be fast learners and superbly talented, but delivering transformation through Fiori Launchpad is more than switching things on, and more than asking users what they need – much more. So if the benefits are potentially enormous, do you really want to use beginners?
From a standing start there are many questions. What is involved to design Fiori LaunchPad? Can we do this ourselves? What does SAP provide out-of-the-box? Should we use the pre-delivered SAP catalogs and roles? How do we decide which of the 10,000 apps we need? How do we best deliver the benefits of Fiori while making things easy to maintain in the future?
Making A Start
In your sandbox turn everything on: All the SICF nodes, all the Gateway Services. Turn on Fiori Search, turn on the pieces of BW inside S/4HANA that we need to drive analytics apps. You won’t figure out what you need by perusing the Fiori Apps Library but only by seeing things for yourself.
At this stage use the pre-delivered catalogs, groups and business roles – it’s way too soon for you to start building your own. But don’t give your users every role as this has a big impact on performance. So define functional users for your analysts with a mapping to the SAP roles.
Now you’re ready to start looking at the 10,000+ apps, and the good news is that you don’t need to review 10,000 apps. Firstly, 80% of these apps are in fact SAP transactions running in HTML GUI with a Fiori theme: They are exactly the same transactions available in SAPGUI. Of the remaining 20%, some you clearly won’t need – perhaps you are not running HCM or PLM etc., and some clearly you will need – such as FactSheets and Reuse Components. Of the rest, a large number are required for Simple Finance and the others are split between different functions in manageable quantities. So at this stage, your analysts should be able figure out what apps are definitely out of scope.
The second task is to determine what is needed: it’s not likely that you will need all 8,000 t-code apps, but analysts should be able to design what SAP transactions are required alongside the Fiori apps.
Catalog Design
Catalogs can be used for different purposes but can all be maintained in the same way, so it’s really essential to be precise about the different types of catalog:
[1] Technical Catalogs. These are provided by SAP, typically in the back-end server and replicated to the front-end server. They contain the basic tile definition and the related target mappings.
[2] Business Catalogs. These catalogs are more aligned to user’s roles, and reference the tile definitions from the technical catalogs. The SAP-delivered business catalogs contain both the tile definition and all the related target mappings required by the tile/app.
The first step is to define your own business catalogs. These suit two purposes:
- To provide users with an understandable library of similar apps (tile definitions)
- To provide users with the authorisation to use the apps (target mappings)
Since the target mappings are closely related to the users’ technical roles it can be useful from a security point of view to manage these at a more granular level. In this case you need to define business catalogs with tile definitions and no target mappings, together with security catalogs which store the target mappings but no tile definitions. In this way the roles on the front-end server can match those on the back-end server at a more granular level.
All this takes some design, but really it involves an exercise of defining what the business catalogs will be and then adding the tile definitions and target mappings by referencing the definitions from the technical catalogs.
TIP: Carefully design a naming convention for your custom catalogs and you will be rewarded down the line.
Additional Transactions
Using the pre-delivered t-code apps isn’t enough: You will require additional tiles to call transactions that SAP does not provide a tile for. In reality there could be hundreds of these – there are many, many SAP transactions with no pre-delivered tile. In addition you will require tiles for any custom transactions you have built and want to launch through the LaunchPad. On top of that you might want to define tiles for specific persona flavors. And finally you might have delivered your own custom apps using Stelo, Fiori Elements or other app development tools.
All this is achieved by defining your own technical catalog using the ‘App Descriptors’ tool, and then you can reference the tile and target mappings into your business catalogs in exactly the same way as for the pre-delivered tiles. It is an easy task, but one that you might spend a lot of time on: If there are, say, 500 tiles required then just choosing 500 icons for those tiles is very time-consuming!
TIP: Where possible don’t maintain texts on the tiles themselves in a multi-language scenario, but reference the text from the transaction, so you don’t need to translate all the tile texts.
Group Design
So far everything has been driven by functional scope. From now on, the design turns to user experience. This is something that you can easily get wrong without serious consideration, and it’s where all the benefit lies.
The first thing to do is to abandon the SAP-delivered groups: SAP does not deliver anything remotely useful. Secondly, don’t allow group design to be influenced by security design or catalog design. The groups are not lists of similar tiles, but form part of a launchpad experience for a particular user role or persona. It’s difficult to choose terminology that hasn’t already been used for something technical here, but the point is that we are designing for a particular {person/role/team}. Clearly we can’t design a personal launchpad for every single user, but we do need to deliver something that’s granular enough to add value.
So we must begin with a list of personas that we are designing for, and then design the logical groupings and arrangements for the tiles needed by the persona. Consider:
- Which tiles are used most often?
- Which tiles should be available by searching but not always on the screen?
- Which apps I should have links for, but don’t necessarily need tiles?
- What do we want the user to see when they first log in?
- What are the important KPIs this user should be aware of?
- What key information can we show the users on tiles to prioritise work and drive their behaviour?
What we find is that for many tiles that are calling SAP transactions we don’t need separate tiles for create, change and display in the groups. This takes up too much space. Often just ‘Change’ will suffice, and from there the user can change to ‘display’ or ‘create’ within the SAP transaction.
Tiles clearly add most value when they contain dynamic content such is KPI data and microcharts. Here’s an example of the Purchasing Analytics group in S/4 HANA. It’s powerful to have this information at our fingertips, but terrible design to hide these tiles away in a ‘Reporting’ group that users need to navigate to. Instead the key information should be front-and-centre, hitting the user between their eyes in order to drive their behaviour.
There are plenty of SAP analytics tiles that contain this type of content, and many more that don’t. Consider Production Engineering. In S/4 HANA we are provided with the group shown below. The tiles are not presented in a sensible order. 12 out of 22 tiles have the same icon, which renders the icon useless. Simply by putting tiles in a group falls way short of delivering a transformational user experience.
Custom Tiles
Building dynamic tiles and custom tiles can dramatically improve the launchpad design. This might be as simple as adding an image instead of an icon to bring the launchpad to life, or it might involve adding value through KPI and microchart information.
Dynamic tile
Microchart
Small image
Full-tile image
Some tiles lend themselves easily to the addition of microcharts:
Where there’s no useful chart or KPI to show, you can get creative with images. Here is the same Production Engineering group as above, but now with tile images and links.
Production Engineering group with full-tile images
Building custom tiles can be very powerful but expensive, so tools like Stelo Tile Builder provide great value by driving down the cost of delivery.
Design Process
With Fiori LaunchPad the analytics should always come first. When we design the user’s launchpad we are designing their job: focusing on key business drivers and ensuring that they have the right information to make fast, informed decisions. So don’t only use analytical tiles with analytical apps; instead put key information in front of every user, making use of the Fiori LaunchPad home page and Overview Screens.
You won’t have the time to design a user experience that is 100% fit for every user, so that’s where personalisation is essential: You must allow your users to be show, hide, create and change their groups, and to add or remove tiles from their groups. This should begin at UAT: That’s the first chance you will get to see how users interact with their launchpads. After UAT you have a chance to make changes to the pre-delivered groups to make them a better fit for go-live.
After go-live give your users 3-6 months and then review again. See how they have personalised their own launchpads and this will inform how you can amend the groups when changes are introduced. Because changes will come: You have entered a Fiori world now, where more Fiori apps will be introduced and SAP transactions retired, where analytics will become the normal driver for many business processes, where more is automated and where the drive to simplify the user experience will continue. It’s going to be an exciting ride, with huge benefits for those who take it seriously.
- SAP Managed Tags:
5 Comments
