Catalogues Matter-a-lot - Or How to Build an App Finder Catalogue for your S/4HANA Implementation

[MattHarding]

TL;DR Version

1. The App Finder/Catalogue for your business/customer is possibly the hardest but most important deliverable of an S/4HANA conversion for your users and future innovations!


2. This content may date quite quickly though not as quickly as home page design which I recommend keeping to relatively blank slates that can be personalised.


3. Be prepared for the functional team to do laborious and time consuming work to create a company specific App Finder/Catalogue - This is a significant, and I consider mandatory, portion of work to move to S/4HANA.


4. You need a process to do this - Included below is a template example process that should work for most businesses/customers.


5. Engage End Users often for design review


6. Not using Fiori Launchpad for everything in S/4HANA is not an S/4HANA implementation in my opinion.


7. Tiles are only a small part of the puzzle - Target Mappings (with or without Tiles) are the secret sauce of UX in an S/4HANA world.

If you get past this TL;DR section; just realise that this is written for those about to do these steps as it’s going to be quite a hard read. My recommendation - Get the time put in your project plan for these steps, and then wait for your sandpit S/4HANA system to be set-up before truly reading the rest.

The Importance of Catalogues within S/4HANA

Ever seen an S/4HANA demo? They show you home pages with around 20+ groups with 8+ tiles in each group and you wonder how a user would ever find what they need.

They also may show you aspects such as enterprise search, links to object detail pages, plus all the relevant links to apps within search and the apps themselves.

All of this is driven by the App Finder/Catalogues available to end users.

Now while SAP business roles out of the box will quickly let you see what is possible, it is a long way off being able to just give to a business, especially if you are doing a conversion from Business Client or SAP GUI Menus where users just know a thousand transaction codes.

This post is to highlight an approach to delivering catalogues that are easy to maintain, are role-based, avoid duplicates, and take true advantage of the integrated nature of the Fiori Launchpad and Fiori experience. This is based on an experience where we tried to get the UX  right the first time, and the lessons learned, at least from my perspective (which does not necessarily relate to my customer’s perspectives).

BE WARNED - Catalogues are a Team Effort, and a Significant Part of the Project

Do you have a UX person or two tagged for your project? Maybe someone in security responsible for Catalogues.

Great!

But they can’t do this alone - Not by a long shot.  The biggest goal a UX person can achieve is to get the project team across how to use Fiori, how Catalogues work and an approach to get everyone to deliver a consistent, focused experience that makes sense to the business.

It’s like understanding that Target Mappings are the real authorisations for end users, not the tiles themselves; and that Target Mappings and Semantic Object groupings are how related apps are found and described to end users. What are Business Catalogues, what are Technical Catalogues, what are back-end catalogues, what comes out of the box, what doesn’t, what are grey listed transactions, etc.

Then, just as importantly, make sure they let go of their past, and really try leverage search and related apps in their testing. If they rely on tiles that contain the transaction code in the aliases; and treat Fiori Launchpad as a slow version of Business Client or SAPGUI - Then what they will have when they go live is…

A slow version of Business Client or SAPGUI!

Especially if you use WebGUI to render SAPGUI transactions.

I’m not going to attempt to describe all of this in the post, but without this fundamental understanding, the work will be cut out for the UX/security person/people.

The Info Needed for this Post (Very Simplified)

Back-End Catalogue:

This could be considered the library of tiles and target mappings for transactions and web Dynpro applications with or without Personas flavours. SAP provides a lot of content here ready for users. They also provide a lot of content, not ready for use. E.g. Tiles without icons, tiles that will not work on Desktop, Tablet or Mobile (e.g. Nothing).

A program is used to copy Back-End Catalogues into read-only Front-End Technical Catalogues. If you have a Hub or Central Fiori Launchpad, this can be published to that Fiori Launchpad.

Front-End Catalogue:

Let’s simplify this definition as any catalogue available to be seen in the Fiori Admin Tool.

Technical Catalogue:

This is just a front-end catalogue that is used to hold all tiles/target mappings that can then be referenced in Business Catalogues. A Technical Catalogue should never be added to a role/user.

Business Catalogue:

This is a front-end catalogue that will be assigned to role(s) and hence users; providing users access to Target Mappings and Tiles.

Business Roles:

Jocelyn Dart just released a Post about this,

Note - I completely disagree with one of the FAQ, so have added my response to this one:

• Can I use the delivered SAP Business roles as-is? In my opinion - Only if you dislike your users!

Semantic Object/Action & Target Mappings:

How do we work out related apps in Fiori? By the Semantic Object.  All Purchase Order transactions begin with the semantic object PurchaseOrder.  The action describes what you are doing with the PurchaseOrder (always starts with lowercase).  A Target Mapping is made up of both of these and looks like this for example:

• PurchaseOrder-raisePOForMattToGiveMoney

This example would obviously be a very valuable but quite specific action for everyone to implement.

What Makes a Tile Visible to an End User

I’m going to ignore Tiles that don’t use Target Mappings as in general, you should not use these as it limits the possibilities. So a typical tile will contain a target mapping reference.

The Target Mapping itself will be what holds the App to be called.

So if I am assigned a Tile via a Catalog/Role, but not the Target Mapping, I do not see the tile.

If I am assigned a Target Mapping, but not the tile; related apps may show this as an option for me, but search will not show this target mapping, and if I knew the target mapping, I could add it to the browser URL and get to the app.

It’s only when you have both tile and target mapping, that you will see the tile in the App Finder.

It’s important to understand that the tile and target mapping can be in different catalogues.

Brain Dump Begins

Limitations of FLP Today

• Sorting of Tiles in the App Finder is pretty random for end users.


• Catalogues with the same name will be combined into 1 catalogue for an end user (important)


• If a Tile appears in 2 different catalogues, when you get access to the associated Target Mapping, you will see both tiles.


• Tiles are not smart enough to be merged in the one Catalogue name (important)


• Not related to the App Finder, but assigned Home Groups will display, even if there are no tiles within the group! No idea why this has not been fixed yet and one of the reasons behind my recommendation to not create many Home Groups.

How to Build an App Finder Catalogue from Scratch

Down to the crux of this Post now. Let me start first by summarising some high level steps*:

1. Make sure you’ve been monitoring Transaction/Web Dynpro/other usage in your environment for at least a year


2. Analyse the existing apps/role based security and how users navigate today for all users


3. Analyse the before/after app usage for your S/4HANA go-live


4. Design and mock-up the App Finder for candidate users with the help of the functional owners


5. Get User-Feedback


6. Get Requirements for your FLP Solution


7. Build your Company Specific Technical Catalogues


8. Build your Business Catalogues


9. Get User-Feedback


10. Application AND Security Testing

*There are lots more security related tasks that are very customer dependent to do which are not described above and your UX/Security people should take care of them (e.g. Leveraging the roles generated within the task lists, and ensuring search authorisations are dealt with better than just “*” access).  Also, this is by no means linear, so treat this as such. You’ll be jumping back and forth all over the shop potentially!

1. Make sure you’ve been monitoring Transaction/Web Dynpro/other usage in your environment for at least a year

Unless you are doing a full process remodelling exercise with your upgrade, there are like a trillion strange transactions that someone in Finance or Procurement will use maybe once a year - e.g. Did you know there is no standard functionality to change the requester for a PO once they’ve been terminated, so you need to run this very bizarre snote transaction (or be the champion of clean termination processes)!

So with Solution Manager, there are ways of capturing the use of transactions, and, to a lesser degree, Web Dynpro Apps. If this job is not running and capturing this information; stop reading this right now and get it working. Oh - And then check it is actually working (Trust but Verify).

This is really important as you then need a functional owner for every used app to identify whether it’s still required/works in S/4HANA, or whether it has a new App in your implementation (which leads to you notifying change management of this change).

2. Analyse the existing apps/role based security for all users and how users navigate today for all users

How well your security is set-up, will dictate how hard this is. At my customer, we already had Business Client deployed with a menu structure for all Apps with well structured assignment to roles, grouped by process roles (in IdM), which could also be grouped by business roles (also in IdM).  It looked like we just needed to simply map all menus and Object Based Navigation targets into the new world, meaning we had a concise list to work with.

Not quite!

It’s surprising how over time, transactions get added to authorisations without the menus being updated so while this assessment of menus broken down by role got us 80% of the way of mapping the old to the new; there was still quite a bit of work to get to 100% (or close enough).  But moving on...

All apps need to be assessed. Understanding how the role assignment works, etc. If you have an Identity Management solution that uses some kind of Process Role grouping, then that will help a lot.  For example, we have an “Everyone” role that is a great dumping ground for all the stuff for everyone needs, plus an “Employee” role, “Contractor” role, etc. And company specific versions also.

At this point, it’s an assessment of functionality and understanding how to get to the point of replicating all the existing functionality in order to design the Fiori Launchpad, but you will need to understand how to combine this info with the info from step 1 and take this into Step 6. I really don’t get into much detail here as there really is an art to do that.

3. Analyse the before/after app usage for your S/4HANA Go-Live.

Maybe you are implementing SuccessFactors alongside S/4HANA - In that case, maybe your whole Employee Self-Service experience changes, and you have to figure out whether to put SuccessFactor Tiles into the Launchpad, or a single tile which launches SuccessFactors (or use the new Product Switcher preferably).

At my customer, we made some philosophical changes to move FLP away from more a content and application portal to just an application portal. We also had to understand how to deal with Business Client Favourites (change management), and apps that may not work in modern browsers (forcing them to open in IE or Business Client which is a post for another day).

Just a side note - Dealing with multiple browsers is a pain; so one of the go-forward positions we had was to create a shortcut on the desktop which opened Fiori Launchpad within Chrome (and probably in the future Chromium based Edge because of the benefit of it’s IE fallback mode). This was a compromise to not force the users default browser to be changed, but allow us to reduce testing of SAP to 1 browser (there are actually 2 browsers if you count the Business Client browser which for us uses IE as the rendering engine though looking forward to Chromium Edge being an option in Business Client).

There is so much more that could be covered if you have time - Strategy for BI Tools (SAC, PowerBI, Overview Pages, Analytical List Pages) - Mobility - External Facing scenarios - etc. This section should be done before you hit the implementation phase so that’s usually where you have time to explore this stuff. Don’t leave it till Implementation!

4. Design and mock-up the App Finder for candidate users with the help of the functional owners

So with the information at hand, we need to think what this could look like for end users, and what the transaction will be like.  I’d suggest focusing on a specific user that is not your most advanced user, and building a mockup with non-working apps of how the FLP will hang together.

Some aspects we used:

• Taking the 3 level Business Client Menu Navigation Structure we had and using that for the basis of the Catalogue Names. E.g. If you navigate to Maintenance->Orders->Create Order - maybe we call the Catalogue Maintenance - Orders - Then we use Maintenance or Orders as the subtitle in the Tile to help differentiate the tile on the home page from similar tiles named close to Create Order. (purely theoretical and bad example above)


• All Tiles need icons


• We used the User Menu option as a temporary fallback to find tiles that may have been missed in the conversion (remember you can’t just run any transaction in FLP without hacking it a little) - Very important to highlight this in Change Management as something we don’t want them to do and to raise a ticket if they need to.


• The Home Page had a permanent Overview group (locked down), and locked down Employee Services group (at least in the initial mockup - we made Employee Services group personalisable before go-live)

Interesting side note: We used spaces in front of the catalogue name to make Overview come before Employee Services - e.g. 2 spaces in front of Overview, 1 space in front of Employee Services. This kept them both originally at position 1 and 2 on the home page. Hopefully sorting of the home page groups is improved soon though I do worry how Pages will be handled by consultants without the UX Treatment being applied.

5. Get User-Feedback

In short, we created business scenarios; walked all sorts of people through the process; and we did change a lot of quick and simple stuff that made a big difference. Even adding the alternative aliases for Credit Card such as Purchase Card - make a difference when people search for apps.

I think we focused too much on Tiles to be honest, so if you can get Search (including analytic scenarios), Target Mapping examples, etc. sorted; I’d recommend it. E.g. This would be a good way to show people a totally different way of working.

BTW - For this reason, keeping Search as a really fast option is important. If the user has to press Enter when they type in the search bar, you need to look at performance tuning search.

6. Get Requirements for your FLP Solution

There are a lot of requirements hidden in the SAP Business Roles you should be aware of.  E.g. Lots of Target Mappings that are linked to Search. Parameter passing for deep linking scenarios as well.

Let’s assume you are across what needs to be done - The key deliverable I’m going to focus on is a central shared spreadsheet that everyone now needs to fill in.

This is not quite what we did, but what I would do if I had to do it all again (hint - Do not volunteer to configure all the Catalogues after this step - or get a pay rise if you do!)

The goal should be:

• To not have duplicate tiles in different catalogues


• To ensure Target Mappings are semantically linked correctly


• To get consistency with Icons and Tile/App naming


• To make it easy for the very time consuming job of building the catalogues and minimise user mistakes in configuration


• To break up Catalogues when they start to get too big


• To make sure you have a relatively stable set of requirements before building your catalogue (> 80%)

So let’s assume I’m a functional lead looking at the transaction IW32.

First step is to search the Fiori Apps Library for IW32.

You review the Fiori app and Web Dynpro app that come up and maybe say - We’ll stick with the old IW32 for now.

Next step would be to run transaction /ui2/flpcm_cust in your S/4HANA Sandpit system set-up with all your data on the version you are going live with.

• This is the Fiori Launchpad Content Manager app which is useful for looking at catalogues, tiles and target mappings; and the associated PFCG roles involved.

On the 2nd tab, you search for IW32, and find that the Semantic Object is MaintenanceOrder and the action is change. If you’re a really good functional consultant, you might even find the catalogue and role it belongs to; assign it to yourself and check it out in Sandpit…

So with that info in hand, you go to the spreadsheet:

First column is Functional Grouping - This is just something to help with ownership. Let’s go with EAM (Enterprise Asset Management)

Second column is Catalogue Name - Based on our quick and dirty naming guideline above, we say “Maintenance - Orders”

Third column is a list of all PFCG Roles/Business Roles/Process Roles (depends on how your company assign roles) that should have this App

Next is Semantic Object - So we have it easy here, we just enter MaintenanceOrder.

Next is Semantic Action - change

Tile name: This can possibly be the same as what SAP have said, or might need adjusting to suit your standards. Will just say Change Order.

Sub-Title Name: Let’s go with a portion of the catalogue name for consistency: “Maintenance”

Type of App: This could be URL, Web Dynpro, Fiori App, Transaction, etc - In our case - we enter Transaction

Icon: Now a good place to look for icons is the Fiori Icon Explorer - let’s go with sap-icon://eam-work-order (Handy hint it to type the search term and not push enter - In this exact example, the SAP catalogue may have a predefined icon, but I haven’t found an easy way for Functional people to get the icon name - feel free to respond with ideas in the comments below)

Target Mapping Only?: No in this case

Existing SAP Tile/Target Mapping: Yes in this case

Target Details: Separate headings for transaction, web dynpro (WD), WD config, Persona Flavours, Fiori ID - We obviously fill in the transaction as IW32

Additional Parameters?: In our example, it makes sense to support deep linking (e.g. Go to Maintenance order from search, and the standard TM will support that but if the functional person knows additional details are required, this would be the place to put that info. Probably only makes sense to fill this if they answered no to “Existing SAP Tile/Target Mapping”

Sound laborious - Yes it is - but now let’s look at other scenarios briefly:

• Another functional area needs to use IW32 for non-traditional maintenance orders so want it in a different catalogue - In this case, we need to explore potentially creating a custom semantic object so that the 2 apps are treated separately. Probably means we need another column to suggest “Supported Duplicate Tiles”


• Someone identifies the same transaction but for a different PFCG role - They simply update the one tile with the additional role requiring the access.


• Maybe there is a piece of custom functionality in your business - You need to identify the corresponding Semantic Object that should be used. Is there anything that matches correctly; do you need to register a new semantic object for that such as ZGoLiveParty.


• You find yourself wanting to add another Tile to a catalogue that has grown to 20 tiles - This is the opportunity to discuss how to break up the catalogue and move Tiles around.

While this is happening, your UX and Security lead(s) need to review what is being put in to ensure consistency (All names and icons are correct,including spelling and centre instead of center), and that you’re not introducing SoD or other simply security issues. They should also be there to help the functional team get across this, as this is very technical, detailed and fundamental to get > 80% right.

BTW - We’re dealing with English in Australia, but more work on the above would be required for translation.

7. Build your Company Specific Technical Catalogues (Implementation Time!)

The first recommendation here is to break up this work (by functional area perhaps for this step) and assign it to multiple people. You should all use the same transport to keep things simple.  Probably a good idea for developers, security, project manager, functional team, Change Management and your UX people to all work on this (In other words, anyone that understands how to do these steps would be great so you can rapidly turn it around remembering you can’t really test the S/4HANA functionality completely in your dev environment till till this is all done).

Technical catalogues are very important - They give us a central location to manage all Tiles and Target Mappings, wherever they are used.

So for all the apps identified in Step 6, we need to first reference all Tiles in the SAP provided technical catalogues in your own customer technical catalogues - We went with technical catalogues grouped by functional area - e.g. Z_TC_<CUST>_HCM.

The reason for doing this step (which for reference, I did a different way on the project I was on) is that very rarely, will the SAP standard match your own standard. If it does - then you can skip this step for the tiles that line up - but even then, many still won’t line up (missing icons or random subtitles) so why skip it!  Target Mappings are less of a concern, provided the Target Mapping name is inline with the Title.

With the references now in your custom catalogues, we then go through and update any aliases, subtitles, titles, etc to be consistent - This will remove the reference FOREVER!

Note - If you don’t want transactions working on Tablets, you might want to turn this flag off in your customer version of a Target Mapping.

For the Transactions and Web Dynpros that are not in the SAP technical catalogues already; we create backend Technical Catalogues. This is ironically actually much easier to do with the bulk upload facility than handling the references above though SAP Technical Catalogues contain the tricky parameters that may be required for a Target Mapping.

For custom Fiori Apps, URL’s, or any other “odd” things - They can be set-up in your front end customer technical catalogues.

Side Note - I have not discussed aliases here, especially for non S/4HANA links to SRM or GRC as an example. Please consider this also.

8. Build your Business Catalogues

In reality, you will probably build your business catalogue in parallel with your technical catalogues, but it just depends how your project is timed.

With the technical catalogues in perfect shape, this step becomes quite easy. The trick here is understanding security.

My recommendation - Create a Business catalogue named after the Catalogue title. E.g. Maintenance - Orders might be Z_BC_MAINT_ORDER.  Put all tiles into this catalogue by adding the reference from the corresponding Technical Catalogue.

In addition, if a Target Mapping is for everyone, also add it to this catalogue.

Now let’s assume Change Order is for the role Z_MAINTENANCE_TEAM and Z_MAINTENANCE_ADMIN (which we got from the spreadsheet).  What we do next is create a catalogue for each role. So respectively we have:

Z_BC_MAINT_ORDER_MAINTTEAM and

Z_BC_MAINT_ORDER_MAINTADMIN

e.g. We’re limited with space so the standard is to combine the Role name as some kind of concatenated reference.

We then add the relevant TM reference for IW32 to both of these Catalogues.  

Final step is to add Z_BC_MAINT_ORDER and Z_BC_MAINT_ORDER_MAINTTEAM to the role Z_MAINTENANCE_TEAM and Z_BC_MAINT_ORDER and Z_BC_MAINT_ORDER_MAINTADMIN to the role Z_MAINTENANCE_ADMIN.

An alternative to this is to add Z_BC_MAINT_ORDER to the everyone role but I’m not sure of the performance impact of doing this.

By doing it this way, if you have both roles, you will only see the 1 tile.  Also, if you have the catalogue Z_BC_MAINT_ORDER, but not the other 2 catalogues, you will not see the Tile.

Side Note - It is also useful to add all Catalogues to a “test all tiles” role which you can assign to yourself to see what the complete set of tiles looks like in your organisation.

Side Note 2 - There are several options to how you handle the associated authorisations to explore - so worth understanding how you are handling authorisation changes on your project.  For example, you will typically get all the Transaction based template authorisations offered to you after adding a catalogue to a role - If you have your existing authorisations elsewhere, you need to consider what you do here.

Side Note 3 - It’s probably better to create all catalogues and sort out the security before adding a single Tile/Target Mapping.

9. Get User-Feedback

Another good opportunity to fix lots of silly bugs or misguided UX decisions like names of Catalogues (Copying Catalogues is pretty easy at this point still because of the use of the references to the Technical Catalogues).

At this point, end users should log into the system with their own role assignment and see if they can do their day job.  Good way to find simple enhancements that improve UX, or missing Tiles/Features that would prevent UAT from going well. You need friendly users who understand that they may hit issues doing their daily job since the implementation is still being performed.

10. Application AND Security Testing

S/4HANA implementations are not a project where you should test with SAP_ALL.  Running S/4HANA as user-like as possible is critical to understanding if it works.  

Another key aspect is if you use SAP Business Client in Fiori Launchpad mode - it might behave differently to when used in Chrome (obviously WebGUI and SAPGUI are completely different, but even web based apps).   For example: file upload/downloads, PDF display, differences with punch-out catalogues (due to HTML frame issues), different behaviour due to SAP code checking for IE or Chrome.

Perfect testing would involve every app identified in S/4HANA in the catalogues, being tested in all clients, as the users who will use them. In reality, only a good percentage will be really tested (there are so many weird and wild Finance apps used once a year for example) - but the more end user application testing of apps you can do; the more smooth your go-live will be for the end user.

Another important aspect is to challenge the functional team to work differently at this point. It’s very easy to just go to the App Finder, search on IW32 and run it, and complain that it takes you 30 seconds to get to your first transaction; but if they search on an order number (even better yet, by some obscure fact of the order), and jump straight to change on it; then as they demo with end users, they and the end users may see some real UX benefits early on.

Brain Dump Ends

Wrap Up

Getting S/4HANA working for your customisation/configuration is and should be the key deliverable for your project (plus on time and budget with high quality of course), but I do hope the above is a close second in terms of priority. By doing the above; adding new Fiori apps or doing upgrades and not disrupting end users personalisation, or understanding/familiarisation of search/App Finder, will be a breeze.

Lack of Images

Apologies for the lack of images - I wanted to post this while relatively fresh in my head and historically, SCN has been very cumbersome with images so until I can paste an image into SCN, I’m going to limit posts to mainly “tiring to read” and verbose text.

Also - I apologise for the Title (it sounded catchier in my head) 😉

 

Late Addition Related to Enterprise Search

So I'm looking at ensuring Search is working perfectly at the moment, and realised that when we used the Mass Maintenance tool for Back End Catalogs, the program to copy it to the front end (/UI2/GET_APP_DESCR_REMOTE_DEV) was incorrectly concatenating the Title and Subtitle to the Target Mapping.  This means that in Search Results or Related Apps, they were seeing the Subtitle in the actions like this "Manage Purchase Order - SCM Purchase Orders", instead of just "Manage Purchase Orders". Just exploring this fix, but a quick mod to /UI2/CL_AD_REMOTE_UTIL->method get_catalog_from_ads_remote will fix this (just end both areas where it checks for subtitle and appends it to the title).

In short, we should recommend SAP to add a flag to /UI2/GET_APP_DESCR_REMOTE_DEV to optionally exclude subtitle from Target Mapping titles.