FIORI Implementation Simplified, Part 4

This is the 4th and last blog in the series “FIORI Implementation Simplified”.

Part 1 was about  landscape and usability of standard apps, and can be accessed by clicking here.
Part 2 was about development environment and can be accessed by clicking here.
Part 3 was about FIORI development and custom app client and can be accessed by clicking here.

In this part we will discuss user roles, security, printing from FIORI and a sample project plan and timeline.

User Roles and Security

SAP does provide role templates for each of the app, but they are very broad and will need to be refined, especially if you have GRC. Creating roles is the easier part, but what takes more effort is rolling out the roles and security to all the users, which will usually be in hundreds at least, since the idea of implementing FIORI is to empower all the users, especially the ones who are doing day to day transactions.

Our security requirements were very brief but they ended up giving sleepless nights to GRC folks! They were

1. Associate access to view across a region (for example by sales organization) and count in assigned location only. Can be a general account
2. Manager access to view across a region (for example by company code) and count, post stock movements in an assigned location. Must be a named account.
3. Regional Manager access across all locations/regions. Must be a named account.

Here’s the process we settled on to figure out roles and security,

1. Half way through the development, when you can create documents in SAP via FIORI, create a brand new user with the authorization SAP documentation recommends. This can usually be found in the FIORI apps repository.
2. If yours is a completely customized app then you can use the role specified with the app you are using as a template or can start with a brand new role.
3. Set up a working session with the SAP security folks, log on with the new user id and work through the business process. This way you can share the SU53 screens with them and they can keep adding the required authorizations.
4. You may have to recommend some security yourself even though it may not be required. Most common elements for limiting security we used were store, plant, Sales Organization and Company code.

Here’s a screenshot of one of the role for a stock movement app we developed. Please note the new roles we had and how they are being restricted by what movement type is allowed in what plant/site.

Printing from FIORI

Printing from FIORI can be very tricky, reason being how do you determine printer for a user if that user is going to have access only to a mobile device and not SAP GUI. Normally SAP users have a windows device, where they can maintain their printer in user properties in SAP GUI, but in our case mobile was the way to go, with no access to SAP GUI.

So we settled on following strategy for determining printer for a user

• User Id should default to a printer, that meant changing paperwork that people will fill when they are hired. It also meant users who are coming to FIORI now can not have printer set to LOCL in their SAP user profiles.
• All of the printers that FIORI users will be printing to, should be set up in SAP print server
• In most cases, we ended up naming printers same as the location name, to make work easy for security and GRC folks.

Timeline

There are at least 3 elements that will help you decide the timeline of a FIORI implementation. I have put these three elements in a decision chart to make it clearer.

This is a very generalized timeline so take it with a pinch of Salt!

Very First Mobile/FIORI implementation

If this is the first mobile implementation then whole mobile infrastructure needs to be put in place. A mobile/networking specialist can tell you more about it but I guess it should take a good one month and lots of planning before it. Since this is not a core SAP area I will leave it out of discussion.

Even if you have mobile infrastructure in place i.e. a mobile app is already being used, FIORI infrastructure needs to be set up. You will need a Basis resource for 3-4 weeks to set up the environment.

Custom FIORI clients

If you plan to use a third party scanner in the apps, you will need to do a customize client. This should be about 2 weeks of development per development environment.

FIORI development

After you have setup the environment and have the (optional) custom FIORI client ready. you are ready for development. Development timeline will differ based on how complex/customized are your Apps, but here is a generalized plan. You may have a mix of apps with different complexities, so we will discuss a sample timeline based on those assumptions.

In any case, here’s the decision chart for time it will take to do development.

Sample Project Plan

For the sample project plan, I’ll assume that this is the first FIORI implementation but mobile infrastructure exists. I have assumed that there is only one resource available for each skill set and Java Script/ Jquery resource will be able to do iOS or Android development.

For apps, I have assumed following three apps will be implemented. You can click on the name of the app to see more detail of our implementation.

1). Retail product look up (meets 80% requirements, only 20% development required)
2). Stock movement app (meets 40% requirements, rest are mostly backend enhancements)
3). Web order fulfillment app (meets 20% requirements, custom development)

With this mix and synergies, preparation and infrastructure should take about 4 weeks, custom FIORI client about 2 weeks, development about 12 weeks and 2 weeks for testing etc. for a go live at the end of 18th week.

Solution architect and networking oversight will still be required throughout the implementation, but that should not be much. Oh by the way, i assumed you will have business process and requirements documented before you begin 🙂

Good luck and happy FIORIing….