Fiori Tracker – Fiori at scale tooling that cuts deployment time

Update from 19 October 2020: Fiori Tracker has new release (2020 FPS01)

The challenge

Fiori Tracker came to life as a result of the struggle that we faced on our S/4 HANA project, with 800 applications enabled through Fiori launchpad. Agreeing with Functional experts on how apps should be grouped and then exposed through roles set by Basis experts was taking way too long. Massive Excel spreadsheets (separate for each of 8 streams) with lists of apps and, each made in its way, requirements coming from Functional experts to Basis in different formats, same apps installed by different people, and those were only some of the issues that were making the whole technical process a nightmare.

At first, we managed to merge all the requirements into one XLS file. The resulting Excel was a large vlookup-driven set of tabs. To keep it consistent when adding or changing content was almost a full-time job. Only this way we finally started getting functional requirements in line with what Basis could do in the system. Lastly, Basis could prepare the roles for the testing users, getting us closer to project goals.

Scope changes

Even if you are not iterating in an agile way, the change into the initial design of catalogs will eventually reach you. After each round of tests, the contents of the groups and catalogs will need adjustments. Moving and adding apps is a vital part of any project stage and gets more and more intensive with closing to go-live. It became critical for a technical team to know what are the already tested and approved apps and what is a late addition that the team has not yet verified.

In the described case we have started from scratch but also in case of starting with copies of standard roles and catalogs (which is the current SAP recommendation) at some point, the content of you copied groups will differ from what you started with, so the need to document changed contents is still there.

Move to the app

Seeing the effort needed, we knew that instead of spending the time to keep massive Excel consistent, we could develop an app that does the same for us automatically. We moved all apps and their assignments into tables and exposed them with the Fiori app. Now all project members got one, always up to date, central view on the “to-be” state. It was clear which apps are new arrivals that still need testing and which the team tested already. We also gained clarity on responsibility. It became clear which Functional areas are ready and which are still in preparation. Plain decomposition of the status tuned out to be a crucial factor in the project’s accomplishment.

Year after the first version

Once a central repository of all Fiori launchpad apps, catalogs and roles were in one place, the additional needs around them voiced by customers, set path for other functions:

• Data on apps usage
• Roles to users assignment
• Status on open issues
• Change requests
• URL reference from documentation in Solution manager
• URL reference from reported problems
• Registry of test users
• Reports for the audit team
• Reports for PMO (Project manager) on Functional area preparation progress, and controlling project scope (separately on app types)

We ended up with a set of apps that are now called Fiori Tracker. Those apps automate the daily work and save the time of not only for UX lead (Fiori developers), Basis and Functional experts but also:

• Testers
• Support experts
• PMO members (Project manager)

Feature overview

Fiori Tracker allows you to document and review both “to be” and “as is” state. By “to-be,” we understand what is the planned setup of your applications as a result of decisions taken by functional experts in the “Prepare” phase. “To be” state serves as a reference for your provisioning during the “Realize” and “Deploy” phases. In case there are issues with apps, “To-be” allows you to make sure what applications are in the scope of the solution and how the project team should configure them.
We gathered the main functionalities in role-based Fiori apps. The main ones are:

• Applications
• Catalogs
• Roles

All three have similar architecture and start with the lists supported with As-you-type suggestions and filters on functional area and application type. From the lists you can drill down into specific Fiori content object details and type-specific information. On this level each object has three tabs:

• “To-be”
• “As-is”
• Info records

Wherever the data is system-specific, you can read it separately for each of the chosen “managed systems.” UX lead defines the “managed systems” as a Fiori Tracker configuration activity. For example, you can review a specific application usage separately for your development, quality, and production system.

Here is the summary of available functions for Applications:

Catalogs:

Roles:

The same set of records is used to support usage records collected in the “Application usage” app.

Feature highlights

“Applications” app lets the user drill down from app-level to its details and catalogs that UX lead assigned it. In contrast to Excel spreadsheets, it is easy to navigate even if apps belong to many catalogs.

Info records provide additional information like:

• History
• Sign offs
• Provisionings
• Comments
• Change request
• Test users (separately for each managed system)

“Catalogs” app in a similar way as “Applications” lets the user drill down to applications and roles. Same “Info records are available.

“Roles” app also gives links to the list of catalogs, applications, and users. Fiori Tracker presents the “To-be” user to role assignment separately for each of the “managed systems.”

You can install Fiori Tracker by downloading the transports from GitHub and following the installation steps described in the readme.

If you are interested in more details on Fiori Tracker functionality, please check the manual at http://help.firoritracker.org and the description of some of the use cases at https://fioritracker.org.

Let me know in the comments if you think that Fiori Tracker could be useful in your project and what other functions you see as valuable in the context of managing SAP Fiori launchpad content.